kernel/drivers/usb/isp1760/isp1760-core.c, branch linux-6.9.y

usb: isp1760: Fix out-of-bounds array access

2022-05-19T16:10:59Z

Running the driver through kasan gives an interesting splat: BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c Read of size 20 at addr f1db2e64 by task swapper/0/1 (...) isp1760_register from isp1760_plat_probe+0x1d8/0x220 (...) This happens because the loop reading the regmap fields for the different ISP1760 variants look like this: for (i = 0; i < HC_FIELD_MAX; i++) { ... } Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long. However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[], isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] are dynamically sized during compilation. Fix this by putting an empty assignment to the [HC_FIELD_MAX] and [DC_FIELD_MAX] array member at the end of each array. This will make the array one member longer than it needs to be, but avoids the risk of overwriting whatever is inside [HC_FIELD_MAX - 1] and is simple and intuitive to read. Also add comments explaining what is going on. Fixes: 1da9e1c06873 ("usb: isp1760: move to regmap for register access") Cc: stable@vger.kernel.org Cc: Rui Miguel Silva Cc: Dietmar Eggemann Reviewed-by: Rui Miguel Silva Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220516091424.391209-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: isp1760: otg control register access

2021-08-27T14:11:39Z

The set/clear of the otg control values is done writing to two different 16bit registers, however we setup the regmap width for isp1760/61 to 32bit value bits. So, just access the clear register address (0x376)as the high part of the otg control register set (0x374), and write the values in one go to make sure they get clear/set. Reported-by: Dietmar Eggemann Tested-by: Dietmar Eggemann Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210827131154.4151862-6-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: isp1760: clean never read udc_enabled warning

2021-08-26T11:30:39Z

When CONFIG_USB_ISP1761_UDC is not enabled the udc_enabled variable is never used since it is short circuited before in the logic operations. This would trigger the following warning by clang analyzer: drivers/usb/isp1760/isp1760-core.c:490:2: warning: Value stored to 'udc_enabled' is never read [clang-analyzer-deadcode.DeadStores] udc_enabled = ((devflags & ISP1760_FLAG_ISP1763) || ^ drivers/usb/isp1760/isp1760-core.c:490:2: note: Value stored to 'udc_enabled' is never read Just swap the other of the operands in the logic operations. Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210819180929.1327349-6-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: isp1763: add peripheral mode

2021-05-21T18:05:32Z

Besides the already host mode support add peripheral mode support for the isp1763 IP from the isp1760 family. Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210513084717.2487366-10-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: isp1760: add support for isp1763

2021-05-21T18:05:32Z

isp1763 have some differences from the isp1760, 8 bit address for registers and 16 bit for values, no bulk access to memory addresses, 16 PTD's instead of 32. Following the regmap work done before add the registers, memory access and add the functions to support differences in setup sequences. Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210513084717.2487366-8-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: isp1760: use dr_mode binding

2021-05-21T18:05:32Z

There is already a binding to describe the dual role mode (dr_mode), use that instead of defining a new one (port1-otg). Update driver code and devicetree files that use that port1-otg binding. Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210513084717.2487366-7-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: isp1760: hcd: refactor mempool config and setup

2021-05-21T18:05:32Z

In preparation to support other family member IP, which may have different memory layout. Drop macros and setup a configuration struct. Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210513084717.2487366-6-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: isp1760: move to regmap for register access

2021-05-21T18:05:31Z

Rework access to registers and memory to use regmap framework. No change in current feature or way of work is intended with this change. This will allow to reuse this driver with other IP of this family, for example isp1763, with little changes and effort. Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210513084717.2487366-3-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: add a HCD_DMA flag instead of guestimating DMA capabilities

2019-08-21T17:03:35Z

The usb core is the only major place in the kernel that checks for a non-NULL device dma_mask to see if a device is DMA capable. This is generally a bad idea, as all major busses always set up a DMA mask, even if the device is not DMA capable - in fact bus layers like PCI can't even know if a device is DMA capable at enumeration time. This leads to lots of workaround in HCD drivers, and also prevented us from setting up a DMA mask for platform devices by default last time we tried. Replace this guess with an explicit HCD_DMA that is set by drivers that appear to have DMA support. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20190816062435.881-4-hch@lst.de Signed-off-by: Greg Kroah-Hartman

usb: isp1760: Replace mdelay with msleep in isp1760_init_core

2018-04-22T13:49:42Z

isp1760_init_core() is never called in atomic context. The call chains ending up at isp1760_init_core() are: [1] isp1760_init_core() <- isp1760_register() <- isp1760_plat_probe() [2] isp1760_init_core() <- isp1760_register() <- isp1761_pci_probe() isp1760_plat_probe() is set as ".probe" in struct platform_driver. isp1761_pci_probe() is set as ".probe" in struct pci_driver. These functions are not called in atomic context. Despite never getting called from atomic context, isp1761_pci_probe() calls mdelay() to busily wait. This is not necessary and can be replaced with msleep() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai Signed-off-by: Greg Kroah-Hartman