| Message ID | 1449980278-19881-2-git-send-email-stefan.bruens@rwth-aachen.de |
|---|---|
| State | Superseded |
| Delegated to: | Marek Vasut |
| Headers | show |
On Sunday, December 13, 2015 at 05:17:53 AM, Stefan Brüns wrote: > flush_dcache_range may access data after priv->aligned_buffer end if > len > DWC2_DATA_BUF_SIZE. > memcpy may access data after buffer end if done > 0 > > Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Acked-by: Marek Vasut <marex@denx.de> Best regards, Marek Vasut
On 12/12/2015 09:17 PM, Stefan Brüns wrote: > flush_dcache_range may access data after priv->aligned_buffer end if > len > DWC2_DATA_BUF_SIZE. > memcpy may access data after buffer end if done > 0 Acked-by: Stephen Warren <swarren@wwwdotorg.org> Uggh; icky bug:-( > @@ -823,12 +823,13 @@ int chunk_msg(struct dwc2_priv *priv, struct usb_device *dev, > (*pid << DWC2_HCTSIZ_PID_OFFSET), > &hc_regs->hctsiz); > > - if (!in) { > - memcpy(priv->aligned_buffer, (char *)buffer + done, len); > + if (!in && xfer_len) { Do zero-length memcpy or flush_dcache_range actually cause an issue?
On Wednesday, December 16, 2015 at 03:58:48 AM, Stephen Warren wrote: > On 12/12/2015 09:17 PM, Stefan Brüns wrote: > > flush_dcache_range may access data after priv->aligned_buffer end if > > len > DWC2_DATA_BUF_SIZE. > > memcpy may access data after buffer end if done > 0 > > Acked-by: Stephen Warren <swarren@wwwdotorg.org> > > Uggh; icky bug:-( > > > @@ -823,12 +823,13 @@ int chunk_msg(struct dwc2_priv *priv, struct > > usb_device *dev, > > > > (*pid << DWC2_HCTSIZ_PID_OFFSET), > > &hc_regs->hctsiz); > > > > - if (!in) { > > - memcpy(priv->aligned_buffer, (char *)buffer + done, len); > > + if (!in && xfer_len) { > > Do zero-length memcpy or flush_dcache_range actually cause an issue? I believe they should not, based on how they are implemented. Best regards, Marek Vasut
On Wednesday 16 December 2015 11:29:14 Marek Vasut wrote: > > > + if (!in && xfer_len) { > > > > Do zero-length memcpy or flush_dcache_range actually cause an issue? > > I believe they should not, based on how they are implemented. I think that's correct, it is just a minor optimization. Kind regards, Stefan
diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 541c0f9..5ef6deb 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -823,12 +823,13 @@ int chunk_msg(struct dwc2_priv *priv, struct usb_device *dev, (*pid << DWC2_HCTSIZ_PID_OFFSET), &hc_regs->hctsiz); - if (!in) { - memcpy(priv->aligned_buffer, (char *)buffer + done, len); + if (!in && xfer_len) { + memcpy(priv->aligned_buffer, (char *)buffer + done, + xfer_len); flush_dcache_range((unsigned long)priv->aligned_buffer, (unsigned long)((void *)priv->aligned_buffer + - roundup(len, ARCH_DMA_MINALIGN))); + roundup(xfer_len, ARCH_DMA_MINALIGN))); } writel(phys_to_bus((unsigned long)priv->aligned_buffer),
flush_dcache_range may access data after priv->aligned_buffer end if len > DWC2_DATA_BUF_SIZE. memcpy may access data after buffer end if done > 0 Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> --- drivers/usb/host/dwc2.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)