[PATCH v4 2/2] usbip: Fix implicit fallthrough warning
GCC 7 now warns when switch statements fall through implicitly, and with
-Werror enabled in configure.ac, that makes these tools unbuildable.
We fix this by notifying the compiler that this particular case statement
is meant to fall through.
Reviewed-by: Peter Senna Tschudin
Signed-off-by: Jonathan Dieter
---
tools/usb/usbip/src/usbip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/usb/usbip/src/usbip.c b/tools/usb/usbip/src/usbip.c
index d7599d9..73d8eee 100644
--- a/tools/usb/usbip/src/usbip.c
+++ b/tools/usb/usbip/src/usbip.c
@@ -176,6 +176,8 @@ int main(int argc, char *argv[])
break;
case '?':
printf("usbip: invalid option\n");
+ /* Terminate after printing error */
+ /* FALLTHRU */
default:
usbip_usage();
goto out;
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] usbip: Fix-format-overflow
The usbip userspace tools call sprintf()/snprintf() and don't check for
the return value which can lead the paths to overflow, truncating the
final file in the path.
More urgently, GCC 7 now warns that these aren't checked with
-Wformat-overflow, and with -Werror enabled in configure.ac, that makes
these tools unbuildable.
This patch fixes these problems by replacing sprintf() with snprintf() in
one place and adding checks for the return value of snprintf().
Reviewed-by: Peter Senna Tschudin
Signed-off-by: Jonathan Dieter
---
Changes since v3
* Cast sizeof to long unsigned when printing errors to fix building for 32-bit
architectures
tools/usb/usbip/libsrc/usbip_common.c | 9 -
tools/usb/usbip/libsrc/usbip_host_common.c | 28 +++-
2 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/tools/usb/usbip/libsrc/usbip_common.c
b/tools/usb/usbip/libsrc/usbip_common.c
index ac73710..1517a23 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -215,9 +215,16 @@ int read_usb_interface(struct usbip_usb_device *udev, int
i,
struct usbip_usb_interface *uinf)
{
char busid[SYSFS_BUS_ID_SIZE];
+ int size;
struct udev_device *sif;
- sprintf(busid, "%s:%d.%d", udev->busid, udev->bConfigurationValue, i);
+ size = snprintf(busid, sizeof(busid), "%s:%d.%d",
+ udev->busid, udev->bConfigurationValue, i);
+ if (size < 0 || (unsigned int)size >= sizeof(busid)) {
+ err("busid length %i >= %lu or < 0", size,
+ (long unsigned)sizeof(busid));
+ return -1;
+ }
sif = udev_device_new_from_subsystem_sysname(udev_context, "usb",
busid);
if (!sif) {
diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c
b/tools/usb/usbip/libsrc/usbip_host_common.c
index 9d41522..6ff7b60 100644
--- a/tools/usb/usbip/libsrc/usbip_host_common.c
+++ b/tools/usb/usbip/libsrc/usbip_host_common.c
@@ -40,13 +40,20 @@ struct udev *udev_context;
static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
{
char status_attr_path[SYSFS_PATH_MAX];
+ int size;
int fd;
int length;
char status;
int value = 0;
- snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
-udev->path);
+ size = snprintf(status_attr_path, sizeof(status_attr_path),
+ "%s/usbip_status", udev->path);
+ if (size < 0 || (unsigned int)size >= sizeof(status_attr_path)) {
+ err("usbip_status path length %i >= %lu or < 0", size,
+ (long unsigned)sizeof(status_attr_path));
+ return -1;
+ }
+
fd = open(status_attr_path, O_RDONLY);
if (fd < 0) {
@@ -218,6 +225,7 @@ int usbip_export_device(struct usbip_exported_device *edev,
int sockfd)
{
char attr_name[] = "usbip_sockfd";
char sockfd_attr_path[SYSFS_PATH_MAX];
+ int size;
char sockfd_buff[30];
int ret;
@@ -237,10 +245,20 @@ int usbip_export_device(struct usbip_exported_device
*edev, int sockfd)
}
/* only the first interface is true */
- snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
-edev->udev.path, attr_name);
+ size = snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
+ edev->udev.path, attr_name);
+ if (size < 0 || (unsigned int)size >= sizeof(sockfd_attr_path)) {
+ err("exported device path length %i >= %lu or < 0", size,
+ (long unsigned)sizeof(sockfd_attr_path));
+ return -1;
+ }
- snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+ size = snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+ if (size < 0 || (unsigned int)size >= sizeof(sockfd_buff)) {
+ err("socket length %i >= %lu or < 0", size,
+ (long unsigned)sizeof(sockfd_buff));
+ return -1;
+ }
ret = write_sysfs_attribute(sockfd_attr_path, sockfd_buff,
strlen(sockfd_buff));
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [usb] bea5b158ff WARNING: CPU: 0 PID: 25 at drivers/usb/core/urb.c:338 usb_submit_urb
On Sun, Feb 26, 2017 at 06:19:59PM +0800, Fengguang Wu wrote: > [Sorry, resend to correct Felipe's email address] > > Greetings, > > This debug patch possibly discloses some USB/I2C bugs. Since the USB > warning shows up earlier in dmesg, it might also be the root cause of > the I2C bug. The attached reproduce-* script may help debug them. > > [9.260542] hub 1-0:1.0: 1 port detected > [9.261049] hub 1-0:1.0: USB hub found > [9.261458] hub 1-0:1.0: 1 port detected > [9.262388] kobject (cf9188bc): tried to init an initialized object, > something is seriously wrong. > [9.263589] CPU: 1 PID: 1 Comm: swapper/0 Not tainted > 4.8.0-rc4-3-gbea5b15 #2 > [9.264595] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.9.3-20161025_171302-gandalf 04/01/2014 > [9.265922] c0047db4 c11aec39 cf9188bc c1c1ba9c > c0047dcc c11b0616 > [9.267073] c1ab0c68 cf9188bc cf9188b4 cf918868 c0047dd8 c13090ec > cf9188b4 c0047de4 > [9.268230] c130a49e ce6a8000 c0047e04 c1402216 ce69300c 00200246 > cf9188b4 cf918000 > [9.269388] Call Trace: > [9.269720] [] dump_stack+0x58/0x72 > [9.270312] [] kobject_init+0x27/0x71 > [9.270929] [] device_initialize+0x1b/0xbd > [9.271599] [] device_register+0xb/0x15 > [9.272236] [] usb_add_gadget_udc_release+0x85/0x215 > [9.273036] [] usb_add_gadget_udc+0xa/0xc > [9.273700] [] dummy_udc_probe+0x130/0x168 > [9.274377] [] platform_drv_probe+0x44/0x80 > [9.275047] [] driver_probe_device+0xfe/0x297 > [9.275748] [] __device_attach_driver+0x65/0x71 > [9.276481] [] bus_for_each_drv+0x3a/0x67 > [9.277130] [] __device_attach+0x86/0xdb > [9.28] [] ? driver_allows_async_probing+0xc/0xc > [9.278561] [] device_initial_probe+0xd/0xf > [9.279235] [] bus_probe_device+0x25/0x67 > [9.279895] [] device_add+0x341/0x497 > [9.280517] [] ? dev_set_name+0x14/0x16 > [9.281154] [] platform_device_add+0x117/0x161 > [9.281879] [] init+0x20d/0x2f4 > [9.282431] [] ? usb_udc_init+0x3f/0x3f > [9.283075] [] do_one_initcall+0x7e/0xfc > [9.283725] [] ? parse_args+0x19b/0x26f > [9.284362] [] ? kernel_init_freeable+0x147/0x1eb > [9.285100] [] kernel_init_freeable+0x163/0x1eb > [9.285826] [] kernel_init+0x8/0xd0 > [9.286417] [] ret_from_kernel_thread+0xe/0x24 > [9.287118] [] ? rest_init+0xa5/0xa5 > [9.288532] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at > 0x60,0x64 irq 1,12 > [9.290663] serio: i8042 KBD port at 0x60,0x64 irq 1 > [9.291372] serio: i8042 AUX port at 0x60,0x64 irq 12 > [9.293351] serio: i8042 KBD port at 0x60,0x64 irq 1 > [9.294031] serio: i8042 AUX port at 0x60,0x64 irq 12 Fengguang, thanks for reporting it, I can also reproduce it using unbind/bind interface for dummy_udc. The reason for it is that the memory region of struct usb_gadget at dummy_udc is from the platform data of platform device dummy_udc, so this memory region will not be released after the resources for device dummy_udc are released. The below diff can fix my problem, would you mind testing it: diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c index c60abe3..a358cb9 100644 --- a/drivers/usb/gadget/udc/dummy_hcd.c +++ b/drivers/usb/gadget/udc/dummy_hcd.c @@ -1031,6 +1031,7 @@ static int dummy_udc_probe(struct platform_device *pdev) int rc; dum = *((void **)dev_get_platdata(&pdev->dev)); + memzero_explicit(&dum->gadget, sizeof (struct usb_gadget)); dum->gadget.name = gadget_name; dum->gadget.ops = &dummy_ops; dum->gadget.max_speed = USB_SPEED_SUPER; Peter > > The attached dmesg has more follow up errors. > > git bisect start v4.9 v4.8 -- > git bisect bad 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942 # 00:43 18- > 30 Merge branch 'linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 > git bisect bad d8ea757b25ec82687c497fc90aa83f9bcea24b5b # 01:11 4- > 6 Merge tag 'xtensa-20161005' of git://github.com/jcmvbkbc/linux-xtensa > git bisect bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c # 01:17 6- > 11 Merge tag 'usb-4.9-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb > git bisect good 1a4a2bc460721bc8f91e4c1294d39b38e5af132f # 01:32 52+ > 0 Merge branch 'x86-asm-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect good 3ef0a61a467639cf7def299309cd9ea524c3e1c1 # 01:50 52+ > 0 Merge branch 'x86-boot-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect bad e6dce825fba05f447bd22c865e27233182ab3d79 # 02:02 17- > 27 Merge tag 'tty-4.9-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty > git bisect good 597f03f9d133e9837d00965016170271d4f87dcf # 02:34 55+ > 0 Merge branch 'smp-hotplug-for-linus' of > git://git.kernel.org/
Re: [PATCH v5] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver
On Di, 2017-02-21 at 15:57 +0100, Richard Leitner wrote:
> >>> This is a lot of properties. Are you really finding a need for all of
> >>> them? Is this to handle h/w designers too cheap to put down the EEPROM?
> >>> Maybe better to just define an eeprom property in the format the h/w
> >>> expects.
> >>
> >>
> >> I need about 15 of these properties. I just exposed them all to dt because
> >> I
> >> thought they could be useful for somebody.
> >>
> >> Yes, these are a subset of the settings which can be configured via an
> >> external EEPROM (By strapping some pins of the hub you can select if it
> >> loads its configuration from an EEPROM or receives it via SMBus).
> >>
> >> My first thought was also to define only a byte array in dt, but IMHO these
> >> options are much more readable and convenient for everybody. I'd also be
> >> fine with removing the properties I don't need from dt. But that may lead
> >> to
> >> future patches where somebody needs some of the options not already exposed
> >> to dt.
> >
> > Okay. It's really a judgement call. If this is most of the settings,
> > then it's fine. If it was only a fraction of them, then maybe we'd
> > want to do just a byte array. Sounds like it is the former.
>
> In fact there are 6 more parameters available according to the
> datasheet. So how should I proceed here? Remove the one's I'm not using
> at the moment, leave them as they are or add the missing 6 too?
Rob, several of these properties look more like configuration rather
than HW description ('skip-config', '*-id', 'manufacturer', 'product',
'serial'). Is DT the right place for this? I would expect userspace to
provide the configuration.
Regards,
Jan
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3: Fix incorrect type for utmi mode
The utmi mode is unsigned according the dt-bindings.
Fix sparse issue (-Wtypesign):
drivers/usb/dwc3/dwc3-omap.c:391:50: warning: incorrect type in argument 3
(different signedness)
drivers/usb/dwc3/dwc3-omap.c:391:50:expected unsigned int [usertype]
*out_value
drivers/usb/dwc3/dwc3-omap.c:391:50:got int *
Signed-off-by: Franck Demathieu
---
drivers/usb/dwc3/dwc3-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 2092e46..4a59577 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -392,7 +392,7 @@ static void dwc3_omap_set_utmi_mode(struct dwc3_omap *omap)
{
u32 reg;
struct device_node *node = omap->dev->of_node;
- int utmi_mode = 0;
+ u32 utmi_mode = 0;
reg = dwc3_omap_read_utmi_ctrl(omap);
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/20] mlx5: Replace PCI pool old API
On Sun, Feb 26, 2017 at 08:24:11PM +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API.
>
Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Romain Perier
> ---
> drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++-
> include/linux/mlx5/driver.h | 2 +-
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> index caa837e..6eef344 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> @@ -1061,7 +1061,7 @@ static struct mlx5_cmd_mailbox *alloc_cmd_box(struct
> mlx5_core_dev *dev,
> if (!mailbox)
> return ERR_PTR(-ENOMEM);
>
> - mailbox->buf = pci_pool_zalloc(dev->cmd.pool, flags,
> + mailbox->buf = dma_pool_zalloc(dev->cmd.pool, flags,
> &mailbox->dma);
> if (!mailbox->buf) {
> mlx5_core_dbg(dev, "failed allocation\n");
> @@ -1076,7 +1076,7 @@ static struct mlx5_cmd_mailbox *alloc_cmd_box(struct
> mlx5_core_dev *dev,
> static void free_cmd_box(struct mlx5_core_dev *dev,
>struct mlx5_cmd_mailbox *mailbox)
> {
> - pci_pool_free(dev->cmd.pool, mailbox->buf, mailbox->dma);
> + dma_pool_free(dev->cmd.pool, mailbox->buf, mailbox->dma);
> kfree(mailbox);
> }
>
> @@ -1696,7 +1696,8 @@ int mlx5_cmd_init(struct mlx5_core_dev *dev)
> return -EINVAL;
> }
>
> - cmd->pool = pci_pool_create("mlx5_cmd", dev->pdev, size, align, 0);
> + cmd->pool = dma_pool_create("mlx5_cmd", &dev->pdev->dev, size, align,
> + 0);
> if (!cmd->pool)
> return -ENOMEM;
>
> @@ -1786,7 +1787,7 @@ int mlx5_cmd_init(struct mlx5_core_dev *dev)
> free_cmd_page(dev, cmd);
>
> err_free_pool:
> - pci_pool_destroy(cmd->pool);
> + dma_pool_destroy(cmd->pool);
>
> return err;
> }
> @@ -1800,6 +1801,6 @@ void mlx5_cmd_cleanup(struct mlx5_core_dev *dev)
> destroy_workqueue(cmd->wq);
> destroy_msg_cache(dev);
> free_cmd_page(dev, cmd);
> - pci_pool_destroy(cmd->pool);
> + dma_pool_destroy(cmd->pool);
> }
> EXPORT_SYMBOL(mlx5_cmd_cleanup);
> diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
> index 2fcff6b..13a267c 100644
> --- a/include/linux/mlx5/driver.h
> +++ b/include/linux/mlx5/driver.h
> @@ -284,7 +284,7 @@ struct mlx5_cmd {
> struct semaphore pages_sem;
> int mode;
> struct mlx5_cmd_work_ent *ent_arr[MLX5_MAX_COMMANDS];
> - struct pci_pool *pool;
> + struct dma_pool *pool;
> struct mlx5_cmd_debug dbg;
> struct cmd_msg_cache cache[MLX5_NUM_COMMAND_CACHES];
> int checksum_disabled;
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/20] scsi: lpfc: Replace PCI pool old API
On Sun, Feb 26, 2017 at 08:24:15PM +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API. It also updates
> some comments, accordingly.
>
Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Romain Perier
> ---
> drivers/scsi/lpfc/lpfc.h | 12 ++---
> drivers/scsi/lpfc/lpfc_init.c | 16 +++
> drivers/scsi/lpfc/lpfc_mem.c | 105
> -
> drivers/scsi/lpfc/lpfc_nvme.c | 6 +--
> drivers/scsi/lpfc/lpfc_nvmet.c | 4 +-
> drivers/scsi/lpfc/lpfc_scsi.c | 12 ++---
> 6 files changed, 76 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
> index 0bba2e3..29492bc 100644
> --- a/drivers/scsi/lpfc/lpfc.h
> +++ b/drivers/scsi/lpfc/lpfc.h
> @@ -934,12 +934,12 @@ struct lpfc_hba {
> spinlock_t hbalock;
>
> /* pci_mem_pools */
> - struct pci_pool *lpfc_sg_dma_buf_pool;
> - struct pci_pool *lpfc_mbuf_pool;
> - struct pci_pool *lpfc_hrb_pool; /* header receive buffer pool */
> - struct pci_pool *lpfc_drb_pool; /* data receive buffer pool */
> - struct pci_pool *lpfc_hbq_pool; /* SLI3 hbq buffer pool */
> - struct pci_pool *txrdy_payload_pool;
> + struct dma_pool *lpfc_sg_dma_buf_pool;
> + struct dma_pool *lpfc_mbuf_pool;
> + struct dma_pool *lpfc_hrb_pool; /* header receive buffer pool */
> + struct dma_pool *lpfc_drb_pool; /* data receive buffer pool */
> + struct dma_pool *lpfc_hbq_pool; /* SLI3 hbq buffer pool */
> + struct dma_pool *txrdy_payload_pool;
> struct lpfc_dma_pool lpfc_mbuf_safety_pool;
>
> mempool_t *mbox_mem_pool;
> diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
> index 0ee429d..b856457 100644
> --- a/drivers/scsi/lpfc/lpfc_init.c
> +++ b/drivers/scsi/lpfc/lpfc_init.c
> @@ -3151,7 +3151,7 @@ lpfc_scsi_free(struct lpfc_hba *phba)
> list_for_each_entry_safe(sb, sb_next, &phba->lpfc_scsi_buf_list_put,
>list) {
> list_del(&sb->list);
> - pci_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
> + dma_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
> sb->dma_handle);
> kfree(sb);
> phba->total_scsi_bufs--;
> @@ -3162,7 +3162,7 @@ lpfc_scsi_free(struct lpfc_hba *phba)
> list_for_each_entry_safe(sb, sb_next, &phba->lpfc_scsi_buf_list_get,
>list) {
> list_del(&sb->list);
> - pci_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
> + dma_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
> sb->dma_handle);
> kfree(sb);
> phba->total_scsi_bufs--;
> @@ -3193,7 +3193,7 @@ lpfc_nvme_free(struct lpfc_hba *phba)
> list_for_each_entry_safe(lpfc_ncmd, lpfc_ncmd_next,
>&phba->lpfc_nvme_buf_list_put, list) {
> list_del(&lpfc_ncmd->list);
> - pci_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
> + dma_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
> lpfc_ncmd->dma_handle);
> kfree(lpfc_ncmd);
> phba->total_nvme_bufs--;
> @@ -3204,7 +3204,7 @@ lpfc_nvme_free(struct lpfc_hba *phba)
> list_for_each_entry_safe(lpfc_ncmd, lpfc_ncmd_next,
>&phba->lpfc_nvme_buf_list_get, list) {
> list_del(&lpfc_ncmd->list);
> - pci_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
> + dma_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
> lpfc_ncmd->dma_handle);
> kfree(lpfc_ncmd);
> phba->total_nvme_bufs--;
> @@ -3517,7 +3517,7 @@ lpfc_sli4_scsi_sgl_update(struct lpfc_hba *phba)
> list_remove_head(&scsi_sgl_list, psb,
>struct lpfc_scsi_buf, list);
> if (psb) {
> - pci_pool_free(phba->lpfc_sg_dma_buf_pool,
> + dma_pool_free(phba->lpfc_sg_dma_buf_pool,
> psb->data, psb->dma_handle);
> kfree(psb);
> }
> @@ -3614,7 +3614,7 @@ lpfc_sli4_nvme_sgl_update(struct lpfc_hba *phba)
> list_remove_head(&nvme_sgl_list, lpfc_ncmd,
>struct lpfc_nvme_buf, list);
> if (lpfc_ncmd) {
> - pci_pool_free(phba->lpfc_sg_dma_buf_pool,
> + dma_pool_free(phba->lpfc_sg_dma_buf_pool,
> lpfc_ncmd->data,
> lpfc_ncmd->dma_handle);
> kfree(lpfc_ncmd)
Re: [PATCH v3 07/20] wireless: ipw2200: Replace PCI pool old API
On Sun, Feb 26, 2017 at 08:24:12PM +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API.
>
Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Romain Perier
> ---
> drivers/net/wireless/intel/ipw2x00/ipw2200.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> index 5ef3c5c..93dfe47 100644
> --- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> +++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> @@ -3211,7 +3211,7 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8
> * data, size_t len)
> struct fw_chunk *chunk;
> int total_nr = 0;
> int i;
> - struct pci_pool *pool;
> + struct dma_pool *pool;
> void **virts;
> dma_addr_t *phys;
>
> @@ -3228,9 +3228,10 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8
> * data, size_t len)
> kfree(virts);
> return -ENOMEM;
> }
> - pool = pci_pool_create("ipw2200", priv->pci_dev, CB_MAX_LENGTH, 0, 0);
> + pool = dma_pool_create("ipw2200", &priv->pci_dev->dev, CB_MAX_LENGTH, 0,
> +0);
> if (!pool) {
> - IPW_ERROR("pci_pool_create failed\n");
> + IPW_ERROR("dma_pool_create failed\n");
> kfree(phys);
> kfree(virts);
> return -ENOMEM;
> @@ -3255,7 +3256,7 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8
> * data, size_t len)
>
> nr = (chunk_len + CB_MAX_LENGTH - 1) / CB_MAX_LENGTH;
> for (i = 0; i < nr; i++) {
> - virts[total_nr] = pci_pool_alloc(pool, GFP_KERNEL,
> + virts[total_nr] = dma_pool_alloc(pool, GFP_KERNEL,
>&phys[total_nr]);
> if (!virts[total_nr]) {
> ret = -ENOMEM;
> @@ -3299,9 +3300,9 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8
> * data, size_t len)
> }
> out:
> for (i = 0; i < total_nr; i++)
> - pci_pool_free(pool, virts[i], phys[i]);
> + dma_pool_free(pool, virts[i], phys[i]);
>
> - pci_pool_destroy(pool);
> + dma_pool_destroy(pool);
> kfree(phys);
> kfree(virts);
>
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/20] scsi: csiostor: Replace PCI pool old API
On Sun, Feb 26, 2017 at 08:24:14PM +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API. It also updates
> the name of some variables and the content of comments, accordingly.
>
Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Romain Perier
> ---
> drivers/scsi/csiostor/csio_hw.h | 2 +-
> drivers/scsi/csiostor/csio_init.c | 11 ++-
> drivers/scsi/csiostor/csio_scsi.c | 6 +++---
> 3 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/csiostor/csio_hw.h b/drivers/scsi/csiostor/csio_hw.h
> index 029bef8..55b04fc 100644
> --- a/drivers/scsi/csiostor/csio_hw.h
> +++ b/drivers/scsi/csiostor/csio_hw.h
> @@ -465,7 +465,7 @@ struct csio_hw {
> struct csio_pport pport[CSIO_MAX_PPORTS]; /* Ports (XGMACs) */
> struct csio_hw_params params; /* Hw parameters */
>
> - struct pci_pool *scsi_pci_pool; /* PCI pool for SCSI */
> + struct dma_pool *scsi_dma_pool; /* DMA pool for SCSI */
> mempool_t *mb_mempool;/* Mailbox memory pool*/
> mempool_t *rnode_mempool; /* rnode memory pool */
>
> diff --git a/drivers/scsi/csiostor/csio_init.c
> b/drivers/scsi/csiostor/csio_init.c
> index dbe416f..292964c 100644
> --- a/drivers/scsi/csiostor/csio_init.c
> +++ b/drivers/scsi/csiostor/csio_init.c
> @@ -485,9 +485,10 @@ csio_resource_alloc(struct csio_hw *hw)
> if (!hw->rnode_mempool)
> goto err_free_mb_mempool;
>
> - hw->scsi_pci_pool = pci_pool_create("csio_scsi_pci_pool", hw->pdev,
> - CSIO_SCSI_RSP_LEN, 8, 0);
> - if (!hw->scsi_pci_pool)
> + hw->scsi_dma_pool = dma_pool_create("csio_scsi_dma_pool",
> + &hw->pdev->dev, CSIO_SCSI_RSP_LEN,
> + 8, 0);
> + if (!hw->scsi_dma_pool)
> goto err_free_rn_pool;
>
> return 0;
> @@ -505,8 +506,8 @@ csio_resource_alloc(struct csio_hw *hw)
> static void
> csio_resource_free(struct csio_hw *hw)
> {
> - pci_pool_destroy(hw->scsi_pci_pool);
> - hw->scsi_pci_pool = NULL;
> + dma_pool_destroy(hw->scsi_dma_pool);
> + hw->scsi_dma_pool = NULL;
> mempool_destroy(hw->rnode_mempool);
> hw->rnode_mempool = NULL;
> mempool_destroy(hw->mb_mempool);
> diff --git a/drivers/scsi/csiostor/csio_scsi.c
> b/drivers/scsi/csiostor/csio_scsi.c
> index a1ff75f..dab0d3f 100644
> --- a/drivers/scsi/csiostor/csio_scsi.c
> +++ b/drivers/scsi/csiostor/csio_scsi.c
> @@ -2445,7 +2445,7 @@ csio_scsim_init(struct csio_scsim *scm, struct csio_hw
> *hw)
>
> /* Allocate Dma buffers for Response Payload */
> dma_buf = &ioreq->dma_buf;
> - dma_buf->vaddr = pci_pool_alloc(hw->scsi_pci_pool, GFP_KERNEL,
> + dma_buf->vaddr = dma_pool_alloc(hw->scsi_dma_pool, GFP_KERNEL,
> &dma_buf->paddr);
> if (!dma_buf->vaddr) {
> csio_err(hw,
> @@ -2485,7 +2485,7 @@ csio_scsim_init(struct csio_scsim *scm, struct csio_hw
> *hw)
> ioreq = (struct csio_ioreq *)tmp;
>
> dma_buf = &ioreq->dma_buf;
> - pci_pool_free(hw->scsi_pci_pool, dma_buf->vaddr,
> + dma_pool_free(hw->scsi_dma_pool, dma_buf->vaddr,
> dma_buf->paddr);
>
> kfree(ioreq);
> @@ -2516,7 +2516,7 @@ csio_scsim_exit(struct csio_scsim *scm)
> ioreq = (struct csio_ioreq *)tmp;
>
> dma_buf = &ioreq->dma_buf;
> - pci_pool_free(scm->hw->scsi_pci_pool, dma_buf->vaddr,
> + dma_pool_free(scm->hw->scsi_dma_pool, dma_buf->vaddr,
> dma_buf->paddr);
>
> kfree(ioreq);
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 18/20] usb: host: Remove remaining pci_pool in comments
On Sun, Feb 26, 2017 at 08:24:23PM +0100, Romain Perier wrote: > This replaces remaining occurences of pci_pool by dma_pool, as > this is the new API that could be used for that purpose. > Reviewed-by: Peter Senna Tschudin > Signed-off-by: Romain Perier > --- > drivers/usb/host/ehci-hcd.c | 2 +- > drivers/usb/host/fotg210-hcd.c | 2 +- > drivers/usb/host/oxu210hp-hcd.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > index ac2c4ea..6e834b83 100644 > --- a/drivers/usb/host/ehci-hcd.c > +++ b/drivers/usb/host/ehci-hcd.c > @@ -597,7 +597,7 @@ static int ehci_run (struct usb_hcd *hcd) > /* >* hcc_params controls whether ehci->regs->segment must (!!!) >* be used; it constrains QH/ITD/SITD and QTD locations. > - * pci_pool consistent memory always uses segment zero. > + * dma_pool consistent memory always uses segment zero. >* streaming mappings for I/O buffers, like pci_map_single(), >* can return segments above 4GB, if the device allows. >* > diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c > index 1c5b34b..ced08dc 100644 > --- a/drivers/usb/host/fotg210-hcd.c > +++ b/drivers/usb/host/fotg210-hcd.c > @@ -5047,7 +5047,7 @@ static int fotg210_run(struct usb_hcd *hcd) > /* >* hcc_params controls whether fotg210->regs->segment must (!!!) >* be used; it constrains QH/ITD/SITD and QTD locations. > - * pci_pool consistent memory always uses segment zero. > + * dma_pool consistent memory always uses segment zero. >* streaming mappings for I/O buffers, like pci_map_single(), >* can return segments above 4GB, if the device allows. >* > diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c > index bcf531c..ed20fb3 100644 > --- a/drivers/usb/host/oxu210hp-hcd.c > +++ b/drivers/usb/host/oxu210hp-hcd.c > @@ -2708,7 +2708,7 @@ static int oxu_run(struct usb_hcd *hcd) > > /* hcc_params controls whether oxu->regs->segment must (!!!) >* be used; it constrains QH/ITD/SITD and QTD locations. > - * pci_pool consistent memory always uses segment zero. > + * dma_pool consistent memory always uses segment zero. >* streaming mappings for I/O buffers, like pci_map_single(), >* can return segments above 4GB, if the device allows. >* > -- > 2.9.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/20] Replace PCI pool by DMA pool API
On Sun, Feb 26, 2017 at 08:24:05PM +0100, Romain Perier wrote: > The current PCI pool API are simple macro functions direct expanded to > the appropriated dma pool functions. The prototypes are almost the same > and semantically, they are very similar. I propose to use the DMA pool > API directly and get rid of the old API. > > This set of patches, replaces the old API by the dma pool API, adds > support to warn about this old API in checkpath.pl and remove the > defines. > > Changes in v3: > - Rebased series onto next-20170224 > - Fix checkpath.pl reports for patch 11/20 and patch 12/20 > - Remove prefix RFC > Changes in v2: > - Introduced patch 18/20 > - Fixed cosmetic changes: spaces before brace, live over 80 characters > - Removed some of the check for NULL pointers before calling dma_pool_destroy > - Improved the regexp in checkpatch for pci_pool, thanks to Joe Perches > - Added Tested-by and Acked-by tags Tested the series with checkpatch and compiling with allyesconfig. > > Romain Perier (20): > block: DAC960: Replace PCI pool old API > dmaengine: pch_dma: Replace PCI pool old API > IB/mthca: Replace PCI pool old API > net: e100: Replace PCI pool old API > mlx4: Replace PCI pool old API > mlx5: Replace PCI pool old API > wireless: ipw2200: Replace PCI pool old API > scsi: be2iscsi: Replace PCI pool old API > scsi: csiostor: Replace PCI pool old API > scsi: lpfc: Replace PCI pool old API > scsi: megaraid: Replace PCI pool old API > scsi: mpt3sas: Replace PCI pool old API > scsi: mvsas: Replace PCI pool old API > scsi: pmcraid: Replace PCI pool old API > usb: gadget: amd5536udc: Replace PCI pool old API > usb: gadget: net2280: Replace PCI pool old API > usb: gadget: pch_udc: Replace PCI pool old API > usb: host: Remove remaining pci_pool in comments > PCI: Remove PCI pool macro functions > checkpatch: warn for use of old PCI pool API > > drivers/block/DAC960.c| 36 - > drivers/block/DAC960.h| 4 +- > drivers/dma/pch_dma.c | 12 +-- > drivers/infiniband/hw/mthca/mthca_av.c| 10 +-- > drivers/infiniband/hw/mthca/mthca_cmd.c | 8 +- > drivers/infiniband/hw/mthca/mthca_dev.h | 4 +- > drivers/net/ethernet/intel/e100.c | 12 +-- > drivers/net/ethernet/mellanox/mlx4/cmd.c | 10 +-- > drivers/net/ethernet/mellanox/mlx4/mlx4.h | 2 +- > drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 +-- > drivers/net/wireless/intel/ipw2x00/ipw2200.c | 13 ++-- > drivers/scsi/be2iscsi/be_iscsi.c | 6 +- > drivers/scsi/be2iscsi/be_main.c | 6 +- > drivers/scsi/be2iscsi/be_main.h | 2 +- > drivers/scsi/csiostor/csio_hw.h | 2 +- > drivers/scsi/csiostor/csio_init.c | 11 +-- > drivers/scsi/csiostor/csio_scsi.c | 6 +- > drivers/scsi/lpfc/lpfc.h | 12 +-- > drivers/scsi/lpfc/lpfc_init.c | 16 ++-- > drivers/scsi/lpfc/lpfc_mem.c | 105 > +- > drivers/scsi/lpfc/lpfc_nvme.c | 6 +- > drivers/scsi/lpfc/lpfc_nvmet.c| 4 +- > drivers/scsi/lpfc/lpfc_scsi.c | 12 +-- > drivers/scsi/megaraid/megaraid_mbox.c | 33 > drivers/scsi/megaraid/megaraid_mm.c | 32 > drivers/scsi/megaraid/megaraid_sas_base.c | 29 +++ > drivers/scsi/megaraid/megaraid_sas_fusion.c | 66 > drivers/scsi/mpt3sas/mpt3sas_base.c | 73 +- > drivers/scsi/mvsas/mv_init.c | 6 +- > drivers/scsi/mvsas/mv_sas.c | 6 +- > drivers/scsi/pmcraid.c| 10 +-- > drivers/scsi/pmcraid.h| 2 +- > drivers/usb/gadget/udc/amd5536udc.c | 8 +- > drivers/usb/gadget/udc/amd5536udc.h | 4 +- > drivers/usb/gadget/udc/net2280.c | 12 +-- > drivers/usb/gadget/udc/net2280.h | 2 +- > drivers/usb/gadget/udc/pch_udc.c | 31 > drivers/usb/host/ehci-hcd.c | 2 +- > drivers/usb/host/fotg210-hcd.c| 2 +- > drivers/usb/host/oxu210hp-hcd.c | 2 +- > include/linux/mlx5/driver.h | 2 +- > include/linux/pci.h | 9 --- > scripts/checkpatch.pl | 9 ++- > 43 files changed, 318 insertions(+), 332 deletions(-) > > -- > 2.9.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 19/20] PCI: Remove PCI pool macro functions
On Sun, Feb 26, 2017 at 08:24:24PM +0100, Romain Perier wrote:
> Now that all the drivers use dma pool API, we can remove the macro
> functions for PCI pool.
>
Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Romain Perier
> ---
> include/linux/pci.h | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 282ed32..d206ba4 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1281,15 +1281,6 @@ int pci_set_vga_state(struct pci_dev *pdev, bool
> decode,
> #include
> #include
>
> -#define pci_pool dma_pool
> -#define pci_pool_create(name, pdev, size, align, allocation) \
> - dma_pool_create(name, &pdev->dev, size, align, allocation)
> -#define pci_pool_destroy(pool) dma_pool_destroy(pool)
> -#define pci_pool_alloc(pool, flags, handle) dma_pool_alloc(pool, flags,
> handle)
> -#define pci_pool_zalloc(pool, flags, handle) \
> - dma_pool_zalloc(pool, flags, handle)
> -#define pci_pool_free(pool, vaddr, addr) dma_pool_free(pool, vaddr,
> addr)
> -
> struct msix_entry {
> u32 vector; /* kernel uses to write allocated vector */
> u16 entry; /* driver uses to specify entry, OS writes */
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API
On Sun, Feb 26, 2017 at 08:24:25PM +0100, Romain Perier wrote:
> pci_pool_*() functions should be replaced by the corresponding functions
> in the DMA pool API. This adds support to check for use of these pci
> functions and display a warning when it is the case.
>
I guess Joe Perches did sent some comments for this one, did you address
them?
Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Romain Perier
> ---
> scripts/checkpatch.pl | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index baa3c7b..f2c775c 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -6064,7 +6064,14 @@ sub process {
> WARN("USE_DEVICE_INITCALL",
>"please use device_initcall() or more appropriate
> function instead of __initcall() (see include/linux/init.h)\n" . $herecurr);
> }
> -
> +# check for old PCI api pci_pool_*(), use dma_pool_*() instead
> + if ($line =~
> /\bpci_pool(?:_(?:create|destroy|alloc|zalloc|free)|)\b/) {
> + if (WARN("USE_DMA_POOL",
> + "please use the dma pool api or more
> appropriate function instead of the old pci pool api\n" . $herecurr) &&
> + $fix) {
> + while ($fixed[$fixlinenr] =~
> s/\bpci_pool(_(?:create|destroy|alloc|zalloc|free)|)\b/dma_pool$1/) {}
> + }
> + }
> # check for various structs that are normally const (ops, kgdb, device_tree)
> if ($line !~ /\bconst\b/ &&
> $line =~ /\bstruct\s+($const_structs)\b/) {
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/20] scsi: megaraid: Replace PCI pool old API
On Sun, Feb 26, 2017 at 08:24:16PM +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API.
>
Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Romain Perier
> ---
> drivers/scsi/megaraid/megaraid_mbox.c | 33 +++
> drivers/scsi/megaraid/megaraid_mm.c | 32 +++---
> drivers/scsi/megaraid/megaraid_sas_base.c | 29 +++--
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 66
> +
> 4 files changed, 77 insertions(+), 83 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_mbox.c
> b/drivers/scsi/megaraid/megaraid_mbox.c
> index f0987f2..7dfc2e2 100644
> --- a/drivers/scsi/megaraid/megaraid_mbox.c
> +++ b/drivers/scsi/megaraid/megaraid_mbox.c
> @@ -1153,8 +1153,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>
>
> // Allocate memory for 16-bytes aligned mailboxes
> - raid_dev->mbox_pool_handle = pci_pool_create("megaraid mbox pool",
> - adapter->pdev,
> + raid_dev->mbox_pool_handle = dma_pool_create("megaraid mbox pool",
> + &adapter->pdev->dev,
> sizeof(mbox64_t) + 16,
> 16, 0);
>
> @@ -1164,7 +1164,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>
> mbox_pci_blk = raid_dev->mbox_pool;
> for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
> - mbox_pci_blk[i].vaddr = pci_pool_alloc(
> + mbox_pci_blk[i].vaddr = dma_pool_alloc(
> raid_dev->mbox_pool_handle,
> GFP_KERNEL,
> &mbox_pci_blk[i].dma_addr);
> @@ -1181,8 +1181,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>* share common memory pool. Passthru structures piggyback on memory
>* allocted to extended passthru since passthru is smaller of the two
>*/
> - raid_dev->epthru_pool_handle = pci_pool_create("megaraid mbox pthru",
> - adapter->pdev, sizeof(mraid_epassthru_t), 128, 0);
> + raid_dev->epthru_pool_handle = dma_pool_create("megaraid mbox pthru",
> + &adapter->pdev->dev, sizeof(mraid_epassthru_t), 128, 0);
>
> if (raid_dev->epthru_pool_handle == NULL) {
> goto fail_setup_dma_pool;
> @@ -1190,7 +1190,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>
> epthru_pci_blk = raid_dev->epthru_pool;
> for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
> - epthru_pci_blk[i].vaddr = pci_pool_alloc(
> + epthru_pci_blk[i].vaddr = dma_pool_alloc(
> raid_dev->epthru_pool_handle,
> GFP_KERNEL,
> &epthru_pci_blk[i].dma_addr);
> @@ -1202,8 +1202,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>
> // Allocate memory for each scatter-gather list. Request for 512 bytes
> // alignment for each sg list
> - raid_dev->sg_pool_handle = pci_pool_create("megaraid mbox sg",
> - adapter->pdev,
> + raid_dev->sg_pool_handle = dma_pool_create("megaraid mbox sg",
> + &adapter->pdev->dev,
> sizeof(mbox_sgl64) * MBOX_MAX_SG_SIZE,
> 512, 0);
>
> @@ -1213,7 +1213,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>
> sg_pci_blk = raid_dev->sg_pool;
> for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
> - sg_pci_blk[i].vaddr = pci_pool_alloc(
> + sg_pci_blk[i].vaddr = dma_pool_alloc(
> raid_dev->sg_pool_handle,
> GFP_KERNEL,
> &sg_pci_blk[i].dma_addr);
> @@ -1249,29 +1249,26 @@ megaraid_mbox_teardown_dma_pools(adapter_t *adapter)
>
> sg_pci_blk = raid_dev->sg_pool;
> for (i = 0; i < MBOX_MAX_SCSI_CMDS && sg_pci_blk[i].vaddr; i++) {
> - pci_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
> + dma_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
> sg_pci_blk[i].dma_addr);
> }
> - if (raid_dev->sg_pool_handle)
> - pci_pool_destroy(raid_dev->sg_pool_handle);
> + dma_pool_destroy(raid_dev->sg_pool_handle);
>
>
> epthru_pci_blk = raid_dev->epthru_pool;
> for (i = 0; i < MBOX_MAX_SCSI_CMDS && epthru_pci_blk[i].vaddr; i++) {
> - pci_pool_free(raid_dev->epthru_pool_handle,
> + dma_pool_free(raid_dev->epthru_pool_handle,
> epthru_pci_blk[i].vaddr, epthru_pci_blk[i].dma_a
Re: [PATCH v3 17/20] usb: gadget: pch_udc: Replace PCI pool old API
On Sun, Feb 26, 2017 at 08:24:22PM +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API.
>
Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Romain Perier
> ---
> drivers/usb/gadget/udc/pch_udc.c | 31 +++
> 1 file changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/pch_udc.c
> b/drivers/usb/gadget/udc/pch_udc.c
> index a97da64..84dcbcd 100644
> --- a/drivers/usb/gadget/udc/pch_udc.c
> +++ b/drivers/usb/gadget/udc/pch_udc.c
> @@ -355,8 +355,8 @@ struct pch_udc_dev {
> vbus_session:1,
> set_cfg_not_acked:1,
> waiting_zlp_ack:1;
> - struct pci_pool *data_requests;
> - struct pci_pool *stp_requests;
> + struct dma_pool *data_requests;
> + struct dma_pool *stp_requests;
> dma_addr_t dma_addr;
> struct usb_ctrlrequest setup_data;
> void __iomem*base_addr;
> @@ -1522,7 +1522,7 @@ static void pch_udc_free_dma_chain(struct pch_udc_dev
> *dev,
> /* do not free first desc., will be done by free for request */
> td = phys_to_virt(addr);
> addr2 = (dma_addr_t)td->next;
> - pci_pool_free(dev->data_requests, td, addr);
> + dma_pool_free(dev->data_requests, td, addr);
> td->next = 0x00;
> addr = addr2;
> }
> @@ -1539,7 +1539,7 @@ static void pch_udc_free_dma_chain(struct pch_udc_dev
> *dev,
> *
> * Return codes:
> * 0: success,
> - * -ENOMEM:pci_pool_alloc invocation fails
> + * -ENOMEM:dma_pool_alloc invocation fails
> */
> static int pch_udc_create_dma_chain(struct pch_udc_ep *ep,
> struct pch_udc_request *req,
> @@ -1565,7 +1565,7 @@ static int pch_udc_create_dma_chain(struct pch_udc_ep
> *ep,
> if (bytes <= buf_len)
> break;
> last = td;
> - td = pci_pool_alloc(ep->dev->data_requests, gfp_flags,
> + td = dma_pool_alloc(ep->dev->data_requests, gfp_flags,
> &dma_addr);
> if (!td)
> goto nomem;
> @@ -1770,7 +1770,7 @@ static struct usb_request *pch_udc_alloc_request(struct
> usb_ep *usbep,
> if (!ep->dev->dma_addr)
> return &req->req;
> /* ep0 in requests are allocated from data pool here */
> - dma_desc = pci_pool_alloc(ep->dev->data_requests, gfp,
> + dma_desc = dma_pool_alloc(ep->dev->data_requests, gfp,
> &req->td_data_phys);
> if (NULL == dma_desc) {
> kfree(req);
> @@ -1809,7 +1809,7 @@ static void pch_udc_free_request(struct usb_ep *usbep,
> if (req->td_data != NULL) {
> if (req->chain_len > 1)
> pch_udc_free_dma_chain(ep->dev, req);
> - pci_pool_free(ep->dev->data_requests, req->td_data,
> + dma_pool_free(ep->dev->data_requests, req->td_data,
> req->td_data_phys);
> }
> kfree(req);
> @@ -2914,7 +2914,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
> void*ep0out_buf;
>
> /* DMA setup */
> - dev->data_requests = pci_pool_create("data_requests", dev->pdev,
> + dev->data_requests = dma_pool_create("data_requests", &dev->pdev->dev,
> sizeof(struct pch_udc_data_dma_desc), 0, 0);
> if (!dev->data_requests) {
> dev_err(&dev->pdev->dev, "%s: can't get request data pool\n",
> @@ -2923,7 +2923,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
> }
>
> /* dma desc for setup data */
> - dev->stp_requests = pci_pool_create("setup requests", dev->pdev,
> + dev->stp_requests = dma_pool_create("setup requests", &dev->pdev->dev,
> sizeof(struct pch_udc_stp_dma_desc), 0, 0);
> if (!dev->stp_requests) {
> dev_err(&dev->pdev->dev, "%s: can't get setup request pool\n",
> @@ -2931,7 +2931,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
> return -ENOMEM;
> }
> /* setup */
> - td_stp = pci_pool_alloc(dev->stp_requests, GFP_KERNEL,
> + td_stp = dma_pool_alloc(dev->stp_requests, GFP_KERNEL,
> &dev->ep[UDC_EP0OUT_IDX].td_stp_phys);
> if (!td_stp) {
> dev_err(&dev->pdev->dev,
> @@ -2941,7 +2941,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
> dev->ep[UDC_EP0OUT_IDX].td_stp = td_stp;
>
> /* data: 0 packets !? */
> - td_data = pci_pool_alloc(dev->data_requests, GFP_KERNEL,
> + td_data = dma_pool_alloc(dev->data_requests, GFP_KERNEL,
> &dev->ep[UDC_EP0OUT_IDX].td_data_phys);
> if (!t
Re: [PATCH v3 13/20] scsi: mvsas: Replace PCI pool old API
On Sun, Feb 26, 2017 at 08:24:18PM +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API.
>
Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Romain Perier
> ---
> drivers/scsi/mvsas/mv_init.c | 6 +++---
> drivers/scsi/mvsas/mv_sas.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
> index 8280046..41d2276 100644
> --- a/drivers/scsi/mvsas/mv_init.c
> +++ b/drivers/scsi/mvsas/mv_init.c
> @@ -125,8 +125,7 @@ static void mvs_free(struct mvs_info *mvi)
> else
> slot_nr = MVS_CHIP_SLOT_SZ;
>
> - if (mvi->dma_pool)
> - pci_pool_destroy(mvi->dma_pool);
> + dma_pool_destroy(mvi->dma_pool);
>
> if (mvi->tx)
> dma_free_coherent(mvi->dev,
> @@ -296,7 +295,8 @@ static int mvs_alloc(struct mvs_info *mvi, struct
> Scsi_Host *shost)
> goto err_out;
>
> sprintf(pool_name, "%s%d", "mvs_dma_pool", mvi->id);
> - mvi->dma_pool = pci_pool_create(pool_name, mvi->pdev, MVS_SLOT_BUF_SZ,
> 16, 0);
> + mvi->dma_pool = dma_pool_create(pool_name, &mvi->pdev->dev,
> + MVS_SLOT_BUF_SZ, 16, 0);
> if (!mvi->dma_pool) {
> printk(KERN_DEBUG "failed to create dma pool %s.\n",
> pool_name);
> goto err_out;
> diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
> index c7cc803..ee81d10 100644
> --- a/drivers/scsi/mvsas/mv_sas.c
> +++ b/drivers/scsi/mvsas/mv_sas.c
> @@ -790,7 +790,7 @@ static int mvs_task_prep(struct sas_task *task, struct
> mvs_info *mvi, int is_tmf
> slot->n_elem = n_elem;
> slot->slot_tag = tag;
>
> - slot->buf = pci_pool_alloc(mvi->dma_pool, GFP_ATOMIC, &slot->buf_dma);
> + slot->buf = dma_pool_alloc(mvi->dma_pool, GFP_ATOMIC, &slot->buf_dma);
> if (!slot->buf) {
> rc = -ENOMEM;
> goto err_out_tag;
> @@ -840,7 +840,7 @@ static int mvs_task_prep(struct sas_task *task, struct
> mvs_info *mvi, int is_tmf
> return rc;
>
> err_out_slot_buf:
> - pci_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
> + dma_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
> err_out_tag:
> mvs_tag_free(mvi, tag);
> err_out:
> @@ -918,7 +918,7 @@ static void mvs_slot_task_free(struct mvs_info *mvi,
> struct sas_task *task,
> }
>
> if (slot->buf) {
> - pci_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
> + dma_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
> slot->buf = NULL;
> }
> list_del_init(&slot->entry);
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 12/20] scsi: mpt3sas: Replace PCI pool old API
On Sun, Feb 26, 2017 at 08:24:17PM +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API.
>
Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Romain Perier
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 73
> +
> 1 file changed, 34 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index 5b7aec5..5ae1c23 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -3200,9 +3200,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
> }
>
> if (ioc->sense) {
> - pci_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
> - if (ioc->sense_dma_pool)
> - pci_pool_destroy(ioc->sense_dma_pool);
> + dma_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
> + dma_pool_destroy(ioc->sense_dma_pool);
> dexitprintk(ioc, pr_info(MPT3SAS_FMT
> "sense_pool(0x%p): free\n",
> ioc->name, ioc->sense));
> @@ -3210,9 +3209,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
> }
>
> if (ioc->reply) {
> - pci_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
> - if (ioc->reply_dma_pool)
> - pci_pool_destroy(ioc->reply_dma_pool);
> + dma_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
> + dma_pool_destroy(ioc->reply_dma_pool);
> dexitprintk(ioc, pr_info(MPT3SAS_FMT
> "reply_pool(0x%p): free\n",
> ioc->name, ioc->reply));
> @@ -3220,10 +3218,9 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
> }
>
> if (ioc->reply_free) {
> - pci_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
> + dma_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
> ioc->reply_free_dma);
> - if (ioc->reply_free_dma_pool)
> - pci_pool_destroy(ioc->reply_free_dma_pool);
> + dma_pool_destroy(ioc->reply_free_dma_pool);
> dexitprintk(ioc, pr_info(MPT3SAS_FMT
> "reply_free_pool(0x%p): free\n",
> ioc->name, ioc->reply_free));
> @@ -3234,7 +3231,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
> do {
> rps = &ioc->reply_post[i];
> if (rps->reply_post_free) {
> - pci_pool_free(
> + dma_pool_free(
> ioc->reply_post_free_dma_pool,
> rps->reply_post_free,
> rps->reply_post_free_dma);
> @@ -3246,8 +3243,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
> } while (ioc->rdpq_array_enable &&
> (++i < ioc->reply_queue_count));
>
> - if (ioc->reply_post_free_dma_pool)
> - pci_pool_destroy(ioc->reply_post_free_dma_pool);
> + dma_pool_destroy(ioc->reply_post_free_dma_pool);
> kfree(ioc->reply_post);
> }
>
> @@ -3268,12 +3264,11 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER
> *ioc)
> if (ioc->chain_lookup) {
> for (i = 0; i < ioc->chain_depth; i++) {
> if (ioc->chain_lookup[i].chain_buffer)
> - pci_pool_free(ioc->chain_dma_pool,
> + dma_pool_free(ioc->chain_dma_pool,
> ioc->chain_lookup[i].chain_buffer,
> ioc->chain_lookup[i].chain_buffer_dma);
> }
> - if (ioc->chain_dma_pool)
> - pci_pool_destroy(ioc->chain_dma_pool);
> + dma_pool_destroy(ioc->chain_dma_pool);
> free_pages((ulong)ioc->chain_lookup, ioc->chain_pages);
> ioc->chain_lookup = NULL;
> }
> @@ -3448,23 +3443,23 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER
> *ioc)
> ioc->name);
> goto out;
> }
> - ioc->reply_post_free_dma_pool = pci_pool_create("reply_post_free pool",
> - ioc->pdev, sz, 16, 0);
> + ioc->reply_post_free_dma_pool = dma_pool_create("reply_post_free pool",
> + &ioc->pdev->dev, sz, 16, 0);
> if (!ioc->reply_post_free_dma_pool) {
> pr_err(MPT3SAS_FMT
> - "reply_post_free pool: pci_pool_create failed\n",
> + "reply_post_free pool: dma_pool_create failed\n",
>ioc->name);
> goto out;
> }
> i = 0;
> do {
> ioc->reply_post[i].reply_post_free =
> - pci_pool_alloc(ioc-
Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API
On Mon, 2017-02-27 at 12:22 +0100, Peter Senna Tschudin wrote:
> On Sun, Feb 26, 2017 at 08:24:25PM +0100, Romain Perier wrote:
> > pci_pool_*() functions should be replaced by the corresponding functions
> > in the DMA pool API. This adds support to check for use of these pci
> > functions and display a warning when it is the case.
> >
>
> I guess Joe Perches did sent some comments for this one, did you address
> them?
> Reviewed-by: Peter Senna Tschudin
> > Signed-off-by: Romain Perier
> > ---
> > scripts/checkpatch.pl | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index baa3c7b..f2c775c 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -6064,7 +6064,14 @@ sub process {
> > WARN("USE_DEVICE_INITCALL",
> > "please use device_initcall() or more appropriate
> > function instead of __initcall() (see include/linux/init.h)\n" . $herecurr);
> > }
> > -
> > +# check for old PCI api pci_pool_*(), use dma_pool_*() instead
> > + if ($line =~
> > /\bpci_pool(?:_(?:create|destroy|alloc|zalloc|free)|)\b/) {
> > + if (WARN("USE_DMA_POOL",
> > +"please use the dma pool api or more
> > appropriate function instead of the old pci pool api\n" . $herecurr) &&
> > + $fix) {
> > + while ($fixed[$fixlinenr] =~
> > s/\bpci_pool(_(?:create|destroy|alloc|zalloc|free)|)\b/dma_pool$1/) {}
> > + }
> > + }
> > # check for various structs that are normally const (ops, kgdb,
> > device_tree)
> > if ($line !~ /\bconst\b/ &&
> > $line =~ /\bstruct\s+($const_structs)\b/) {
> >
This is nearly identical to the suggestion that I
sent but this is slightly misformatted as it does
not have a leading nor a trailing blank line to
separate the test blocks.
Also, I think none of the patches have reached lkml.
Romain, are you using git-send-email to send these
patches? Perhaps the patches you send also contain
html which are rejected by the mailing list.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API
Hello,
Le 27/02/2017 à 12:22, Peter Senna Tschudin a écrit :
> On Sun, Feb 26, 2017 at 08:24:25PM +0100, Romain Perier wrote:
>> pci_pool_*() functions should be replaced by the corresponding functions
>> in the DMA pool API. This adds support to check for use of these pci
>> functions and display a warning when it is the case.
>>
> I guess Joe Perches did sent some comments for this one, did you address
> them?
See the changelog of 00/20 (for v2). I have already integrated his
comments :)
>
> Reviewed-by: Peter Senna Tschudin
>> Signed-off-by: Romain Perier
>> ---
>> scripts/checkpatch.pl | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>> index baa3c7b..f2c775c 100755
>> --- a/scripts/checkpatch.pl
>> +++ b/scripts/checkpatch.pl
>> @@ -6064,7 +6064,14 @@ sub process {
>> WARN("USE_DEVICE_INITCALL",
>> "please use device_initcall() or more appropriate
>> function instead of __initcall() (see include/linux/init.h)\n" . $herecurr);
>> }
>> -
>> +# check for old PCI api pci_pool_*(), use dma_pool_*() instead
>> +if ($line =~
>> /\bpci_pool(?:_(?:create|destroy|alloc|zalloc|free)|)\b/) {
>> +if (WARN("USE_DMA_POOL",
>> + "please use the dma pool api or more
>> appropriate function instead of the old pci pool api\n" . $herecurr) &&
>> +$fix) {
>> +while ($fixed[$fixlinenr] =~
>> s/\bpci_pool(_(?:create|destroy|alloc|zalloc|free)|)\b/dma_pool$1/) {}
>> +}
>> +}
>> # check for various structs that are normally const (ops, kgdb, device_tree)
>> if ($line !~ /\bconst\b/ &&
>> $line =~ /\bstruct\s+($const_structs)\b/) {
>> --
>> 2.9.3
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API
On Mon, 2017-02-27 at 13:26 +0100, Romain Perier wrote:
> Hello,
>
>
> Le 27/02/2017 à 12:22, Peter Senna Tschudin a écrit :
> > On Sun, Feb 26, 2017 at 08:24:25PM +0100, Romain Perier wrote:
> > > pci_pool_*() functions should be replaced by the corresponding functions
> > > in the DMA pool API. This adds support to check for use of these pci
> > > functions and display a warning when it is the case.
> > >
> >
> > I guess Joe Perches did sent some comments for this one, did you address
> > them?
>
> See the changelog of 00/20 (for v2). I have already integrated his
> comments :)
Not quite. You need to add blank lines before and after
the new test you added.
I also wonder if you've in fact converted all of the
pci_pool struct and function uses why a new checkpatch
test is needed at all.
Also, it seems none of these patches have reached lkml.
Are you sending the patch series with MIME/html parts?
> > Reviewed-by: Peter Senna Tschudin
> > > Signed-off-by: Romain Perier
> > > ---
> > > scripts/checkpatch.pl | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > > index baa3c7b..f2c775c 100755
> > > --- a/scripts/checkpatch.pl
> > > +++ b/scripts/checkpatch.pl
> > > @@ -6064,7 +6064,14 @@ sub process {
> > > WARN("USE_DEVICE_INITCALL",
> > >"please use device_initcall() or more appropriate
> > > function instead of __initcall() (see include/linux/init.h)\n" .
> > > $herecurr);
> > > }
> > > -
> > > +# check for old PCI api pci_pool_*(), use dma_pool_*() instead
> > > + if ($line =~
> > > /\bpci_pool(?:_(?:create|destroy|alloc|zalloc|free)|)\b/) {
> > > + if (WARN("USE_DMA_POOL",
> > > + "please use the dma pool api or more
> > > appropriate function instead of the old pci pool api\n" . $herecurr) &&
> > > + $fix) {
> > > + while ($fixed[$fixlinenr] =~
> > > s/\bpci_pool(_(?:create|destroy|alloc|zalloc|free)|)\b/dma_pool$1/) {}
> > > + }
> > > + }
> > > # check for various structs that are normally const (ops, kgdb,
> > > device_tree)
> > > if ($line !~ /\bconst\b/ &&
> > > $line =~ /\bstruct\s+($const_structs)\b/) {
> > > --
> > > 2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver
On 02/27/2017 10:48 AM, Jan Lübbe wrote:
> On Di, 2017-02-21 at 15:57 +0100, Richard Leitner wrote:
> This is a lot of properties. Are you really finding a need for all of
> them? Is this to handle h/w designers too cheap to put down the EEPROM?
> Maybe better to just define an eeprom property in the format the h/w
> expects.
I need about 15 of these properties. I just exposed them all to dt because
I
thought they could be useful for somebody.
Yes, these are a subset of the settings which can be configured via an
external EEPROM (By strapping some pins of the hub you can select if it
loads its configuration from an EEPROM or receives it via SMBus).
My first thought was also to define only a byte array in dt, but IMHO these
options are much more readable and convenient for everybody. I'd also be
fine with removing the properties I don't need from dt. But that may lead
to
future patches where somebody needs some of the options not already exposed
to dt.
>>>
>>> Okay. It's really a judgement call. If this is most of the settings,
>>> then it's fine. If it was only a fraction of them, then maybe we'd
>>> want to do just a byte array. Sounds like it is the former.
>>
>> In fact there are 6 more parameters available according to the
>> datasheet. So how should I proceed here? Remove the one's I'm not using
>> at the moment, leave them as they are or add the missing 6 too?
>
> Rob, several of these properties look more like configuration rather
> than HW description ('skip-config', '*-id', 'manufacturer', 'product',
> 'serial'). Is DT the right place for this? I would expect userspace to
> provide the configuration.
Jan, on the one hand you're right, some (most) of the properties are
configuration parameters for the hub chip. On the other hand setting
these parameters (and therefore configuring the hub) avoids an
additional EEPROM chip and IMHO that's some kind of describing an
"imaginary HW". Isn't it? :-)
If DT is not the right place for it: Which userspace tool/procedure
would be appropriate for it? In my case the hub needs to be available
(in a configured state) when the initramfs gets executed.
Thanks for your feedback & regards,
Richard L
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API
Hello,
Le 27/02/2017 à 13:38, Joe Perches a écrit :
> On Mon, 2017-02-27 at 13:26 +0100, Romain Perier wrote:
>> Hello,
>>
>>
>> Le 27/02/2017 à 12:22, Peter Senna Tschudin a écrit :
>>> On Sun, Feb 26, 2017 at 08:24:25PM +0100, Romain Perier wrote:
pci_pool_*() functions should be replaced by the corresponding functions
in the DMA pool API. This adds support to check for use of these pci
functions and display a warning when it is the case.
>>> I guess Joe Perches did sent some comments for this one, did you address
>>> them?
>> See the changelog of 00/20 (for v2). I have already integrated his
>> comments :)
> Not quite. You need to add blank lines before and after
> the new test you added.
Ok
>
> I also wonder if you've in fact converted all of the
> pci_pool struct and function uses why a new checkpatch
> test is needed at all.
That's just to avoid futures mistakes/uses.
>
> Also, it seems none of these patches have reached lkml.
> Are you sending the patch series with MIME/html parts?
Normally no. I use git send-email for all my patches.
Regards,
Romain
>
>>> Reviewed-by: Peter Senna Tschudin
Signed-off-by: Romain Perier
---
scripts/checkpatch.pl | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index baa3c7b..f2c775c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6064,7 +6064,14 @@ sub process {
WARN("USE_DEVICE_INITCALL",
"please use device_initcall() or more appropriate
function instead of __initcall() (see include/linux/init.h)\n" .
$herecurr);
}
-
+# check for old PCI api pci_pool_*(), use dma_pool_*() instead
+ if ($line =~
/\bpci_pool(?:_(?:create|destroy|alloc|zalloc|free)|)\b/) {
+ if (WARN("USE_DMA_POOL",
+ "please use the dma pool api or more
appropriate function instead of the old pci pool api\n" . $herecurr) &&
+ $fix) {
+ while ($fixed[$fixlinenr] =~
s/\bpci_pool(_(?:create|destroy|alloc|zalloc|free)|)\b/dma_pool$1/) {}
+ }
+ }
# check for various structs that are normally const (ops, kgdb,
device_tree)
if ($line !~ /\bconst\b/ &&
$line =~ /\bstruct\s+($const_structs)\b/) {
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
BENEFIT
You are a recipient to Mrs Julie Leach Donation of $3 million USD. Contact(julieleac...@gmail.com) for claims. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] "HC died; cleaning up" and have to reboot
Hi On 24.02.2017 17:01, s...@free.fr wrote: Hello, I have a BUG on USB xhci. The trace here : [11518.982950] xhci_hcd :07:00.0: Stopped the command ring failed, maybe the host is dead [11519.027106] xhci_hcd :07:00.0: Host halt failed, -110 [11519.027108] xhci_hcd :07:00.0: Abort command ring failed [11519.027215] xhci_hcd :07:00.0: HC died; cleaning up [11519.027230] xhci_hcd :07:00.0: Timeout while waiting for setup device command [11519.442303] usb 3-1: device not accepting address 15, error -108 [11519.442324] usb usb3-port1: couldn't allocate usb_device After this error happens, I have to reboot Linux. Without reboot the USB port doesn't work for any devices. We're waiting for the device to respond to a setup device. It doesn't respond, so we have to cancel the command. (stop the command ring, skip the command, and restart the command ring) We first fail in stopping the command ring, then we fail in halting the entire host controller. The situation. uname -a : Linux shal 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:04:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux 4.10 contains changes in exactly this area to prevent a race that might re-start the command we check if it stopped Do you have an older kernel available to check if its a regression in 4.10? Part of lspci: 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) 07:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller Do you have a host from another vendor to try this on? Log show that host controller becomes really unresponsive after we try to abort the command ring. # lsusb Bus 002 Device 004: ID 0582:0044 Roland Corp. EDIROL UA-1000 Bus 002 Device 003: ID 046d:c52e Logitech, Inc. MK260 Wireless Combo Receiver Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Note that I have booted with the GRUB Option : GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.old_scheme_first=1" I work with an old Android smartphone in fastboot mode. The smartphone is connected with a long USB cable (5m). In fastboot mode (and only with this mode), the devices is not reachable . There is error like this : usb 3-1: device not accepting address 12, error -71 So, I had "usbcore.old_scheme_first=1" in kernel command option and then I can reach the device in fastboot mode. But I performs some operation on the smartphone and sometime the device hung . Does the host always hang after a command times out?, i.e is there ever a timeout message: "xhci_hcd :07:00.0: Timeout while ..." without the host dying messages: xhci_hcd :07:00.0: Stopped the command ring failed, maybe the host is dead xhci_hcd :07:00.0: Host halt failed, -110 xhci_hcd :07:00.0: Abort command ring failed xhci_hcd :07:00.0: HC died; cleaning up In this case, my USB port hung too and it is impossible to connect any devices on it (smartphone or usb key for e.g). I have to reboot my Linux, in order to have USB port working again Note that, during operation the entire Linux freeze few seconds... My question : - There is a method to avoid that my USB port hung You could try if the EHCI usb controller works. 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller - If not, there is a method to have a working usb port without rebooting ? Try reloading xhci, might do the trick, unless controller is really stuck. Thank More traces: [11466.611552] usb 3-1: USB disconnect, device number 11 sudden disconnect [11468.957608] usb 3-1: new high-speed USB device number 12 using xhci_hcd [11470.878811] usb 3-1: Device not responding to setup address. [11486.881738] usb 3-1: Device not responding to setup address. So there are already a couple transaction errors when trying to address the device [11487.088447] usb 3-1: device not accepting address 12, error -71 [11487.532378] usb 3-1: new high-speed USB device number 14 using xhci_hcd [11487.559735] usb 3-1: unable to get BOS descriptor [11487.564929] usb 3-1: New USB device found, idVendor=18d1, idProduct=d00d [11487.564932] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [11487.564934] usb 3-1: Product: Android [11487.564935] usb 3-1: Manufacturer: Google [11489.585534] usb 3-1: USB disconnect, device number 14 sudden disconnect [11491
Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API
On Mon, 2017-02-27 at 13:52 +0100, Romain Perier wrote: > > I also wonder if you've in fact converted all of the > > pci_pool struct and function uses why a new checkpatch > > test is needed at all. > > That's just to avoid futures mistakes/uses. When all instances and macro definitions are removed the check is pointless as any newly submitted patch will not compile. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] "HC died; cleaning up" and have to reboot
Hi Thank to try to help me. Responses below. > From: "Mathias Nyman" > > Hi > > On 24.02.2017 17:01, s...@free.fr wrote: > > Hello, > > > > I have a BUG on USB xhci. > > The trace here : > > [11518.982950] xhci_hcd :07:00.0: Stopped the command ring > > failed, maybe the host is dead > > [11519.027106] xhci_hcd :07:00.0: Host halt failed, -110 > > [11519.027108] xhci_hcd :07:00.0: Abort command ring failed > > [11519.027215] xhci_hcd :07:00.0: HC died; cleaning up > > [11519.027230] xhci_hcd :07:00.0: Timeout while waiting for > > setup device command > > [11519.442303] usb 3-1: device not accepting address 15, error -108 > > [11519.442324] usb usb3-port1: couldn't allocate usb_device > > > > After this error happens, I have to reboot Linux. Without reboot > > the USB port doesn't work for any devices. > > We're waiting for the device to respond to a setup device. It > doesn't respond, so we have to cancel the command. > (stop the command ring, skip the command, and restart the command > ring) > > We first fail in stopping the command ring, then we fail in halting > the entire host controller. OK, I have the same conclusions > > > > > > > The situation. > > uname -a : > > Linux shal 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:04:59 UTC > > 2017 x86_64 x86_64 x86_64 GNU/Linux > > 4.10 contains changes in exactly this area to prevent a race that > might re-start the command we check if it stopped > > Do you have an older kernel available to check if its a regression in > 4.10? I have tested also with a 4.9.0-15-generic #16-Ubuntu SMP. Messages are not exactly the same but globally it is the same error With the 4.9 (and active xhci debug) [ 55.015537] xhci_hcd :07:00.0: Command timeout [ 55.015540] xhci_hcd :07:00.0: Abort command ring [ 76.729790] xhci_hcd :07:00.0: Stopped the command ring failed, maybe the host is dead [ 76.729798] xhci_hcd :07:00.0: // Halt the HC [ 76.772864] xhci_hcd :07:00.0: Host not halted after 16000 microseconds. [ 76.772865] xhci_hcd :07:00.0: Abort command ring failed [ 76.772917] xhci_hcd :07:00.0: HC died; cleaning up [ 76.772926] xhci_hcd :07:00.0: xHCI host controller is dead. [ 76.772957] xhci_hcd :07:00.0: Timeout while waiting for setup device command [ 77.188037] usb 3-1: device not accepting address 2, error -108 [ 77.188049] xhci_hcd :07:00.0: Endpoint 0x0 ep reset callback called [ 77.188063] xhci_hcd :07:00.0: xHCI dying or halted, can't queue_command [ 77.188064] xhci_hcd :07:00.0: FIXME: allocate a command ring segment [ 77.188066] usb usb3-port1: couldn't allocate usb_device The FIXME can perhaps help you. See also at the end of email for full trace on 4.10 kernel > > Do you have a host from another vendor to try this on? > Log show that host controller becomes really unresponsive after we > try to abort the command ring. I have no other PC but if needed I can retrieve one (or a arm board). But see below the ehci test. > > > > I work with an old Android smartphone in fastboot mode. The > > smartphone is connected with a long USB cable (5m). > > In fastboot mode (and only with this mode), the devices is not > > reachable . > > There is error like this : > > usb 3-1: device not accepting address 12, error -71 > > > > So, I had "usbcore.old_scheme_first=1" in kernel command option and > > then I can reach the device in fastboot mode. > > > > But I performs some operation on the smartphone and sometime the > > device hung . > > Does the host always hang after a command times out?, i.e is there > ever a timeout message: > "xhci_hcd :07:00.0: Timeout while ..." without the host dying > messages: > > xhci_hcd :07:00.0: Stopped the command ring failed, maybe the > host is dead > xhci_hcd :07:00.0: Host halt failed, -110 > xhci_hcd :07:00.0: Abort command ring failed > xhci_hcd :07:00.0: HC died; cleaning up Yes, the error always happens Sometime traces are not the same but always : - xhci_handle_command_timeout - HC died; cleaning up - usb usb3-port1: couldn't allocate usb_device > You could try if the EHCI usb controller works. > 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series > Chipset Family USB Enhanced Host Controller On this EHCI USB controler : [ 13.900683] usb 2-1.4: new high-speed USB device number 5 using ehci-pci [ 19.332599] usb 2-1.4: device not accepting address 5, error -71 [ 19.412611] usb 2-1.4: new high-speed USB device number 6 using ehci-pci [ 24.960558] usb 2-1.4: device not accepting address 6, error -71 [ 25.040533] usb 2-1.4: new high-speed USB device number 7 using ehci-pci [ 30.252452] usb 2-1.4: device descriptor read/64, error -110 [ 35.636399] usb 2-1.4: device descriptor read/64, error -71 [ 35.819488] usb 2-1.4: new high-speed USB device number 8 using ehci-pci [ 40.845551] usb 2-1.4: device descriptor read/64, error -110 [ 46.141461] usb 2-1.4: device des
Re: dwc2 gadget issues
Hi, On 02/23/2017 08:27 PM, Heiko Stuebner wrote: Hi Francesco, Am Donnerstag, 23. Februar 2017, 19:11:37 CET schrieb Francesco Lavra: I'm having trouble getting the RK3288 OTG controller (the one at ff58) to work in peripheral mode. I'm using a Firefly Reload board, and I know the hardware is fine because I can successfully use the port in device mode with U-Boot's mass storage gadget driver. Under Linux, the OTG port works fine when used in host mode, but fails to work in device mode: nothing happens when the a USB host is plugged into the OTG port, not even a single interrupt is generated by the controller. I'm using the latest device tree definitions from git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git. you shouldn't use my tree as base for any real work :-) . Best to use the regular mainline kernel or alternatively try linux-next to get all recent usb changes schedules for the next release. Thanks for your inputs. I was actually using the mainline kernel (4.8.1), in which the dwc2 driver wasn't working, that's why I went to your tree to pick up any fixes or new features that might have been done. I also went to the linux-usb tree for the same reason. Anyway, today I tried with the latest mainline release 4.10.0, and also with linux-next. Unfortunately, still no luck: I can load a gadget driver, which gets correctly bound to the OTG controller, but then nothing happens if a USB host is connected to the OTG port. I'm pasting below the dmesg contents (obtained with 4.10.0, with verbose debugging enabled for the dwc2 driver) when a gadget driver is loaded, in case you might spot something suspicious: [ 1147.035367] dwc2 ff58.usb: bound driver g_audio [ 1147.041203] dwc2 ff58.usb: dwc2_hsotg_pullup: is_on: 1 op_state: 3 [ 1147.041250] dwc2 ff58.usb: dwc2_core_reset() [ 1147.041345] dwc2 ff58.usb: FIFOs reset, timeout at 100 [ 1147.041405] dwc2 ff58.usb: EP0: DIEPCTL0=0x8000, DOEPCTL0=0x8000 [ 1147.041447] dwc2 ff58.usb: gsintmsk now 0xd08c3cc4 [ 1147.041554] dwc2 ff58.usb: DCTL=0x0002 [ 1147.041631] dwc2 ff58.usb: dwc2_hsotg_enqueue_setup: queueing setup request [ 1147.041692] dwc2 ff58.usb: ep0: req ee241680: 8@ee241198, noi=0, zero=0, snok=0 [ 1147.041757] dwc2 ff58.usb: dwc2_hsotg_start_req: DxEPCTL=0x80008000, ep 0, dir out [ 1147.041799] dwc2 ff58.usb: ureq->length:8 ureq->actual:0 [ 1147.041896] dwc2 ff58.usb: dwc2_hsotg_start_req: 1@8/8, 0x00080008 => 0x0b10 [ 1147.041975] dwc2 ff58.usb: dwc2_hsotg_start_req: 2e243000 pad => 0x0b14 [ 1147.042014] dwc2 ff58.usb: ep0 state:0 [ 1147.042055] dwc2 ff58.usb: dwc2_hsotg_start_req: DxEPCTL=0x80008000 [ 1147.042097] dwc2 ff58.usb: dwc2_hsotg_start_req: DXEPCTL=0x80008000 [ 1147.042169] dwc2 ff58.usb: EP0: DIEPCTL0=0x8000, DOEPCTL0=0x80008000 Thanks, Francesco -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: usb251xb: dt: add unit suffix to oc-delay and power-on-time
On Tue, Feb 21, 2017 at 09:56:18AM +0100, Richard Leitner wrote:
> Rename oc-delay-* to oc-delay-us and make it expect a time value.
> Furthermore add -ms suffix to power-on-time. These changes were
> suggested by Rob Herring in https://lkml.org/lkml/2017/2/15/1283.
>
> Signed-off-by: Richard Leitner
> ---
> Documentation/devicetree/bindings/usb/usb251xb.txt | 9 +++---
> drivers/usb/misc/usb251xb.c| 32
> +-
> 2 files changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt
> b/Documentation/devicetree/bindings/usb/usb251xb.txt
> index a5efd10..4d6bd73 100644
> --- a/Documentation/devicetree/bindings/usb/usb251xb.txt
> +++ b/Documentation/devicetree/bindings/usb/usb251xb.txt
> @@ -31,7 +31,8 @@ Optional properties :
> (default is individual)
> - dynamic-power-switching : enable auto-switching from self- to bus-powered
> operation if the local power source is removed or unavailable
> - - oc-delay-{100us,4ms,8ms,16ms} : set over current timer delay (default is
> 8ms)
> + - oc-delay-us : microseconds over current timer delay, valid values are 100,
> + 4000, 8000 (default) and 16000. All other values are rounded up.
> - compound-device : indicated the hub is part of a compound device
> - port-mapping-mode : enable port mapping mode
> - string-support : enable string descriptor support (required for
> manufacturer,
> @@ -40,9 +41,9 @@ Optional properties :
> device connected.
> - sp-disabled-ports : Specifies the ports which will be self-power disabled
> - bp-disabled-ports : Specifies the ports which will be bus-power disabled
> - - power-on-time : Specifies the time it takes from the time the host
> initiates
> - the power-on sequence to a port until the port has adequate power. The
> - value is given in ms in a 0 - 510 range (default is 100ms).
> + - power-on-time-ms : Specifies the time it takes from the time the host
> + initiates the power-on sequence to a port until the port has adequate
> + power. The value is given in ms in a 0 - 510 range (default is 100ms).
Okay for the binding, but...
>
> Examples:
> usb2512b@2c {
> diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
> index 3f9c306..58b887a 100644
> --- a/drivers/usb/misc/usb251xb.c
> +++ b/drivers/usb/misc/usb251xb.c
> @@ -375,18 +375,24 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
> if (of_get_property(np, "dynamic-power-switching", NULL))
> hub->conf_data2 |= BIT(7);
>
> - if (of_get_property(np, "oc-delay-100us", NULL)) {
> - hub->conf_data2 &= ~BIT(5);
> - hub->conf_data2 &= ~BIT(4);
> - } else if (of_get_property(np, "oc-delay-4ms", NULL)) {
> - hub->conf_data2 &= ~BIT(5);
> - hub->conf_data2 |= BIT(4);
> - } else if (of_get_property(np, "oc-delay-8ms", NULL)) {
> - hub->conf_data2 |= BIT(5);
> - hub->conf_data2 &= ~BIT(4);
> - } else if (of_get_property(np, "oc-delay-16ms", NULL)) {
> - hub->conf_data2 |= BIT(5);
> - hub->conf_data2 |= BIT(4);
> + if (!of_property_read_u32(np, "oc-delay-us", property_u32)) {
> + if (*property_u32 < 100) {
What does the time control? A protection mechanism or just to filter
notifications? For the former, it seems like you would want the time
specified to be a maximum. So for example if the user says 150us, then
you want to make sure the OC condition doesn't exceed that time and
therefore set it to 100us.
Or you could require exact values and set a default if the value doesn't
match.
> + /* 100 us*/
> + hub->conf_data2 &= ~BIT(5);
> + hub->conf_data2 &= ~BIT(4);
> + } else if (*property_u32 < 4000) {
> + /* 4 ms */
> + hub->conf_data2 &= ~BIT(5);
> + hub->conf_data2 |= BIT(4);
> + } else if (*property_u32 < 8000) {
> + /* 8 ms */
> + hub->conf_data2 |= BIT(5);
> + hub->conf_data2 &= ~BIT(4);
> + } else {
> + /* 16 ms */
> + hub->conf_data2 |= BIT(5);
> + hub->conf_data2 |= BIT(4);
> + }
> }
>
> if (of_get_property(np, "compound-device", NULL))
> @@ -433,7 +439,7 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
> }
>
> hub->power_on_time = USB251XB_DEF_POWER_ON_TIME;
> - if (!of_property_read_u32(np, "power-on-time", property_u32))
> + if (!of_property_read_u32(np, "power-on-time-ms", property_u32))
> hub->power_on_time = min_t(u8, be32_to_cpu(*property_u32) / 2,
This is a bug. property_u32 is already in cpu endianness.
> 255);
>
> --
> 2.1.4
>
--
To unsubscribe from this lis
Re: [PATCH v2 5/6] DT bindings documentation for Broadcom IPROC USB Device controller.
On Tue, Feb 21, 2017 at 05:13:03PM +0530, Raviteja Garimella wrote:
> The device node is used for UDCs integrated into Broadcom's
> iProc family of SoCs'. The UDC is based on Synopsys Designware
> Cores AHB Subsystem USB Device Controller IP.
For subject:
dt-bindings: usb: Add Broadcom IPROC USB Device controller
>
> Signed-off-by: Raviteja Garimella
> ---
> Documentation/devicetree/bindings/usb/iproc-udc.txt | 21
> +
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/iproc-udc.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/iproc-udc.txt
> b/Documentation/devicetree/bindings/usb/iproc-udc.txt
> new file mode 100644
> index 000..c2ce803
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/iproc-udc.txt
> @@ -0,0 +1,21 @@
> +Broadcom IPROC USB Device controller.
> +
> +The device node is used for UDCs integrated into Broadcom's
> +iProc family (Northstar2, Cygnus) of SoCs'. The UDC is based
> +on Synopsys Designware Cores AHB Subsystem Device Controller
> +IP.
> +
> +Required properties:
> + - compatible: Add the compatibility strings for supported platforms.
> + For Broadcom NS2 platform, add "brcm,ns2-udc".
> + For Broadcom Cygnus platform, add "brcm,cygnus-udc".
> + - reg: Offset and length of UDC register set
> + - interrupts: description of interrupt line
> + - phys: phandle to phy node.
> +
> +Example:
> + udc_dwc: usb@664e {
> + compatible = "brcm,ns2-udc", "brcm,cygnus-udc";
This doesn't look right?
> + reg = <0x664e 0x2000>;
> + interrupts = ;
> + phys = <&usbdrd_phy>;
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] usb: of: add functions to bind a companion controller
On Tue, Feb 21, 2017 at 07:59:47PM +0900, Yoshihiro Shimoda wrote: > EHCI controllers will have a companion controller. However, on platform > bus, there was difficult to bind them in previous code. So, this > patch adds helper functions to bind them using a "companion" property. > > Signed-off-by: Yoshihiro Shimoda > --- > Documentation/devicetree/bindings/usb/generic.txt | 1 + > drivers/usb/core/of.c | 23 > +++ > include/linux/usb/of.h| 5 + > 3 files changed, 29 insertions(+) Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase
On Tue, 21 Feb 2017, Baolin Wang wrote: > On 17 February 2017 at 16:04, Felipe Balbi wrote: > > > > Hi, > > > > Baolin Wang writes: > (One possible approach would be to have the setup routine return > different values for explicit and implicit status stages -- for > example, return 1 if it wants to submit an explicit status request. > That wouldn't be very different from the current > USB_GADGET_DELAYED_STATUS approach.) > >>> > >>> not really, no. The idea was for composite.c and/or functions to support > >>> both methods (temporarily) and use "gadget->wants_explicit_stages" to > >>> explicitly queue DATA and STATUS. That would mean that f_mass_storage > >>> wouldn't have to return DELAYED_STATUS if > >>> (gadget->wants_explicit_stages). > >>> > >>> After all UDCs are converted over and set wants_explicit_stages (which > >>> should all be done in a single series), then we get rid of the flag and > >>> the older method of DELAYED_STATUS. > >> > >> (Sorry for late reply due to my holiday) > >> I also met the problem pointed by Alan, from my test, I still want to > >> need one return value to indicate if it wants to submit an explicit > >> status request. Think about the Control-IN with a data stage, we can > >> not get the STATUS phase request from usb_ep_queue() call, and we need > > > > why not? wLength tells you that this is a 3-stage transfer. Gadget > > driver should be able to figure out that it needs to usb_ep_queue() > > another request for status stage. > > I tried again, but still can not work. Suppose the no-data control: > (1) SET_ADDRESS request: function driver will not queue one request > for status phase by usb_ep_queue() call. Function drivers do not handle Set-Address requests at all. The UDC driver handles these requests without telling the gadget driver about them. > (2) SET_CONFIGURATION request: function driver will queue one 0-length > request for status phase by usb_ep_queue() call, especially for > mass_storage driver, it will queue one request for status phase > later. > > So I am not sure how the Gadget driver can figure out that it needs to > usb_ep_queue() another request for status stage when handling the > no-data control? Gadget drivers already queue status-stage requests for no-data control-OUT requests. The difficulty comes when you want to handle an IN request or an OUT request with a data stage. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 8/8] dt-bindings: phy-mt65xx-usb: add support for new version phy
On Wed, Feb 22, 2017 at 04:55:05PM +0800, Chunfeng Yun wrote: > add a new compatible string for "mt2712", and move reference clock > into each port node; > > Signed-off-by: Chunfeng Yun > --- > .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 93 > +--- > 1 file changed, 80 insertions(+), 13 deletions(-) Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver
On Mon, Feb 27, 2017 at 3:48 AM, Jan Lübbe wrote:
> On Di, 2017-02-21 at 15:57 +0100, Richard Leitner wrote:
>> >>> This is a lot of properties. Are you really finding a need for all of
>> >>> them? Is this to handle h/w designers too cheap to put down the EEPROM?
>> >>> Maybe better to just define an eeprom property in the format the h/w
>> >>> expects.
>> >>
>> >>
>> >> I need about 15 of these properties. I just exposed them all to dt
>> >> because I
>> >> thought they could be useful for somebody.
>> >>
>> >> Yes, these are a subset of the settings which can be configured via an
>> >> external EEPROM (By strapping some pins of the hub you can select if it
>> >> loads its configuration from an EEPROM or receives it via SMBus).
>> >>
>> >> My first thought was also to define only a byte array in dt, but IMHO
>> >> these
>> >> options are much more readable and convenient for everybody. I'd also be
>> >> fine with removing the properties I don't need from dt. But that may lead
>> >> to
>> >> future patches where somebody needs some of the options not already
>> >> exposed
>> >> to dt.
>> >
>> > Okay. It's really a judgement call. If this is most of the settings,
>> > then it's fine. If it was only a fraction of them, then maybe we'd
>> > want to do just a byte array. Sounds like it is the former.
>>
>> In fact there are 6 more parameters available according to the
>> datasheet. So how should I proceed here? Remove the one's I'm not using
>> at the moment, leave them as they are or add the missing 6 too?
>
> Rob, several of these properties look more like configuration rather
> than HW description ('skip-config', '*-id', 'manufacturer', 'product',
> 'serial'). Is DT the right place for this? I would expect userspace to
> provide the configuration.
Configuration can be okay. The test I use is more who needs to
set/control these properties? Would an end-user want to control them?
If so, then they should be sysfs controls. If they are configuration
for a particular design, then DT is fine. Given these are all
typically EEPROM properties, then they aren't really end-user controls
and belong in DT.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb-storage: Add ignore-residue quirk for Initio INIC-3619
This USB-SATA bridge chip is used in a StarTech enclosure for optical drives. Without the quirk MakeMKV fails during the key exchange with an installed BluRay drive: > Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - > KEY NOT ESTABLISHED' > occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:2' Signed-off-by: Tobias Jakobi --- drivers/usb/storage/unusual_devs.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index 16cc183..9129f6c 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -2071,6 +2071,20 @@ UNUSUAL_DEV( 0x1370, 0x6828, 0x0110, 0x0110, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE ), +/* + * Reported by Tobias Jakobi + * The INIC-3619 bridge is used in the StarTech SLSODDU33B + * SATA-USB enclosure for slimline optical drives. + * + * The quirk enables MakeMKV to properly exchange keys with + * an installed BD drive. + */ +UNUSUAL_DEV( 0x13fd, 0x3609, 0x0209, 0x0209, + "Initio Corporation", + "INIC-3619", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_IGNORE_RESIDUE ), + /* Reported by Qinglin Ye */ UNUSUAL_DEV( 0x13fe, 0x3600, 0x0100, 0x0100, "Kingston", -- 2.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] usb: host: ehci-platform: fix usb 1.1 device is not connected in system resume
On Tue, Feb 21, 2017 at 07:59:48PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that a usb 1.1 device is not connected in
> system resume and then the following message appeared if debug messages
> are enabled:
> usb 2-1: Waited 2000ms for CONNECT
>
> To resolve this issue, the EHCI controller must be resumed after its
> companion controllers. So, this patch adds such code on the driver.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/usb/host/ehci-platform.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-platform.c
> b/drivers/usb/host/ehci-platform.c
> index a268d9e..3214300 100644
> --- a/drivers/usb/host/ehci-platform.c
> +++ b/drivers/usb/host/ehci-platform.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ehci.h"
>
> @@ -297,6 +298,7 @@ static int ehci_platform_probe(struct platform_device
> *dev)
> goto err_power;
>
> device_wakeup_enable(hcd->self.controller);
> + device_enable_async_suspend(hcd->self.controller);
> platform_set_drvdata(dev, hcd);
>
> return err;
> @@ -370,6 +372,7 @@ static int ehci_platform_resume(struct device *dev)
> struct usb_ehci_pdata *pdata = dev_get_platdata(dev);
> struct platform_device *pdev = to_platform_device(dev);
> struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
> + struct device *companion_dev;
>
> if (pdata->power_on) {
> int err = pdata->power_on(pdev);
> @@ -377,6 +380,10 @@ static int ehci_platform_resume(struct device *dev)
> return err;
> }
>
> + companion_dev = usb_of_get_companion_dev(hcd->self.controller);
> + if (companion_dev)
> + device_pm_wait_for_dev(hcd->self.controller, companion_dev);
> +
> ehci_resume(hcd, priv->reset_on_resume);
> return 0;
Reviewed-by: Peter Chen
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] "HC died; cleaning up" and have to reboot
On Fri, Feb 24, 2017 at 04:01:38PM +0100, s...@free.fr wrote: > Hello, > > I have a BUG on USB xhci. > The trace here : > [11518.982950] xhci_hcd :07:00.0: Stopped the command ring failed, maybe > the host is dead > [11519.027106] xhci_hcd :07:00.0: Host halt failed, -110 > [11519.027108] xhci_hcd :07:00.0: Abort command ring failed > [11519.027215] xhci_hcd :07:00.0: HC died; cleaning up > [11519.027230] xhci_hcd :07:00.0: Timeout while waiting for setup device > command > [11519.442303] usb 3-1: device not accepting address 15, error -108 > [11519.442324] usb usb3-port1: couldn't allocate usb_device > > After this error happens, I have to reboot Linux. Without reboot the USB port > doesn't work for any devices. > > > The situation. > uname -a : > Linux shal 4.10.0-8-generic #10-Ubuntu SMP Mon Feb 13 14:04:59 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > > Part of lspci: > 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family > DRAM Controller (rev 09) > 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core > Processor Family PCI Express Root Port (rev 09) > 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family > USB Enhanced Host Controller #1 (rev 05) > 07:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host > Controller > > # lsusb > Bus 002 Device 004: ID 0582:0044 Roland Corp. EDIROL UA-1000 > Bus 002 Device 003: ID 046d:c52e Logitech, Inc. MK260 Wireless Combo Receiver > Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > Note that I have booted with the GRUB Option : > GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.old_scheme_first=1" > > > I work with an old Android smartphone in fastboot mode. The smartphone is > connected with a long USB cable (5m). Would you tell us why you need to use a long USB cable? Why not 1m or 2m? Peter > In fastboot mode (and only with this mode), the devices is not reachable . > There is error like this : > usb 3-1: device not accepting address 12, error -71 > > So, I had "usbcore.old_scheme_first=1" in kernel command option and then I > can reach the device in fastboot mode. > > But I performs some operation on the smartphone and sometime the device hung . > In this case, my USB port hung too and it is impossible to connect any > devices on it (smartphone or usb key for e.g). > I have to reboot my Linux, in order to have USB port working again > > Note that, during operation the entire Linux freeze few seconds... > > My question : > - There is a method to avoid that my USB port hung > - If not, there is a method to have a working usb port without rebooting ? > > > Thank > > > More traces: > [11466.611552] usb 3-1: USB disconnect, device number 11 > [11468.957608] usb 3-1: new high-speed USB device number 12 using xhci_hcd > [11470.878811] usb 3-1: Device not responding to setup address. > [11486.881738] usb 3-1: Device not responding to setup address. > [11487.088447] usb 3-1: device not accepting address 12, error -71 > [11487.532378] usb 3-1: new high-speed USB device number 14 using xhci_hcd > [11487.559735] usb 3-1: unable to get BOS descriptor > [11487.564929] usb 3-1: New USB device found, idVendor=18d1, idProduct=d00d > [11487.564932] usb 3-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [11487.564934] usb 3-1: Product: Android > [11487.564935] usb 3-1: Manufacturer: Google > [11489.585534] usb 3-1: USB disconnect, device number 14 > [11491.748090] usb 3-1: new high-speed USB device number 15 using xhci_hcd > [11518.982950] xhci_hcd :07:00.0: Stopped the command ring failed, maybe > the host is dead > [11519.027106] xhci_hcd :07:00.0: Host halt failed, -110 > [11519.027108] xhci_hcd :07:00.0: Abort command ring failed > [11519.027215] xhci_hcd :07:00.0: HC died; cleaning up > [11519.027230] xhci_hcd :07:00.0: Timeout while waiting for setup device > command > [11519.442303] usb 3-1: device not accepting address 15, error -108 > [11519.442324] usb usb3-port1: couldn't allocate usb_device > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [usb] bea5b158ff WARNING: CPU: 0 PID: 25 at drivers/usb/core/urb.c:338 usb_submit_urb
On 02/27, Peter Chen wrote: >On Sun, Feb 26, 2017 at 06:19:59PM +0800, Fengguang Wu wrote: >> [Sorry, resend to correct Felipe's email address] >> >> Greetings, >> >> This debug patch possibly discloses some USB/I2C bugs. Since the USB >> warning shows up earlier in dmesg, it might also be the root cause of >> the I2C bug. The attached reproduce-* script may help debug them. >> >> [9.260542] hub 1-0:1.0: 1 port detected >> [9.261049] hub 1-0:1.0: USB hub found >> [9.261458] hub 1-0:1.0: 1 port detected >> [9.262388] kobject (cf9188bc): tried to init an initialized object, >> something is seriously wrong. >> [9.263589] CPU: 1 PID: 1 Comm: swapper/0 Not tainted >> 4.8.0-rc4-3-gbea5b15 #2 >> [9.264595] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >> 1.9.3-20161025_171302-gandalf 04/01/2014 >> [9.265922] c0047db4 c11aec39 cf9188bc c1c1ba9c >> c0047dcc c11b0616 >> [9.267073] c1ab0c68 cf9188bc cf9188b4 cf918868 c0047dd8 c13090ec >> cf9188b4 c0047de4 >> [9.268230] c130a49e ce6a8000 c0047e04 c1402216 ce69300c 00200246 >> cf9188b4 cf918000 >> [9.269388] Call Trace: >> [9.269720] [] dump_stack+0x58/0x72 >> [9.270312] [] kobject_init+0x27/0x71 >> [9.270929] [] device_initialize+0x1b/0xbd >> [9.271599] [] device_register+0xb/0x15 >> [9.272236] [] usb_add_gadget_udc_release+0x85/0x215 >> [9.273036] [] usb_add_gadget_udc+0xa/0xc >> [9.273700] [] dummy_udc_probe+0x130/0x168 >> [9.274377] [] platform_drv_probe+0x44/0x80 >> [9.275047] [] driver_probe_device+0xfe/0x297 >> [9.275748] [] __device_attach_driver+0x65/0x71 >> [9.276481] [] bus_for_each_drv+0x3a/0x67 >> [9.277130] [] __device_attach+0x86/0xdb >> [9.28] [] ? driver_allows_async_probing+0xc/0xc >> [9.278561] [] device_initial_probe+0xd/0xf >> [9.279235] [] bus_probe_device+0x25/0x67 >> [9.279895] [] device_add+0x341/0x497 >> [9.280517] [] ? dev_set_name+0x14/0x16 >> [9.281154] [] platform_device_add+0x117/0x161 >> [9.281879] [] init+0x20d/0x2f4 >> [9.282431] [] ? usb_udc_init+0x3f/0x3f >> [9.283075] [] do_one_initcall+0x7e/0xfc >> [9.283725] [] ? parse_args+0x19b/0x26f >> [9.284362] [] ? kernel_init_freeable+0x147/0x1eb >> [9.285100] [] kernel_init_freeable+0x163/0x1eb >> [9.285826] [] kernel_init+0x8/0xd0 >> [9.286417] [] ret_from_kernel_thread+0xe/0x24 >> [9.287118] [] ? rest_init+0xa5/0xa5 >> [9.288532] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at >> 0x60,0x64 irq 1,12 >> [9.290663] serio: i8042 KBD port at 0x60,0x64 irq 1 >> [9.291372] serio: i8042 AUX port at 0x60,0x64 irq 12 >> [9.293351] serio: i8042 KBD port at 0x60,0x64 irq 1 >> [9.294031] serio: i8042 AUX port at 0x60,0x64 irq 12 > >Fengguang, thanks for reporting it, I can also reproduce it using >unbind/bind interface for dummy_udc. The reason for it is that >the memory region of struct usb_gadget at dummy_udc is from the >platform data of platform device dummy_udc, so this memory region >will not be released after the resources for device dummy_udc are >released. The below diff can fix my problem, would you mind testing >it: I've queued jobs to verify your fix, I'll post the result once I get it. Thanks, Xiaolong > >diff --git a/drivers/usb/gadget/udc/dummy_hcd.c >b/drivers/usb/gadget/udc/dummy_hcd.c >index c60abe3..a358cb9 100644 >--- a/drivers/usb/gadget/udc/dummy_hcd.c >+++ b/drivers/usb/gadget/udc/dummy_hcd.c >@@ -1031,6 +1031,7 @@ static int dummy_udc_probe(struct platform_device *pdev) > int rc; > > dum = *((void **)dev_get_platdata(&pdev->dev)); >+ memzero_explicit(&dum->gadget, sizeof (struct usb_gadget)); > dum->gadget.name = gadget_name; > dum->gadget.ops = &dummy_ops; > dum->gadget.max_speed = USB_SPEED_SUPER; > > >Peter >> >> The attached dmesg has more follow up errors. >> >> git bisect start v4.9 v4.8 -- >> git bisect bad 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942 # 00:43 18- >> 30 Merge branch 'linus' of >> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 >> git bisect bad d8ea757b25ec82687c497fc90aa83f9bcea24b5b # 01:11 4- >> 6 Merge tag 'xtensa-20161005' of git://github.com/jcmvbkbc/linux-xtensa >> git bisect bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c # 01:17 6- >> 11 Merge tag 'usb-4.9-rc1' of >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb >> git bisect good 1a4a2bc460721bc8f91e4c1294d39b38e5af132f # 01:32 52+ >> 0 Merge branch 'x86-asm-for-linus' of >> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip >> git bisect good 3ef0a61a467639cf7def299309cd9ea524c3e1c1 # 01:50 52+ >> 0 Merge branch 'x86-boot-for-linus' of >> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip >> git bisect bad e6dce825fba05f447bd22c865e27233182ab3d79 # 02:02 17- >> 27 Merge tag 'tty-4.9-rc
Re: [PATCH v2 1/2] usb: of: add functions to bind a companion controller
On Tue, Feb 21, 2017 at 07:59:47PM +0900, Yoshihiro Shimoda wrote:
> EHCI controllers will have a companion controller. However, on platform
> bus, there was difficult to bind them in previous code. So, this
> patch adds helper functions to bind them using a "companion" property.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> Documentation/devicetree/bindings/usb/generic.txt | 1 +
> drivers/usb/core/of.c | 23
> +++
> include/linux/usb/of.h| 5 +
> 3 files changed, 29 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> b/Documentation/devicetree/bindings/usb/generic.txt
> index bfadeb1..0a74ab8 100644
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ b/Documentation/devicetree/bindings/usb/generic.txt
> @@ -22,6 +22,7 @@ Optional properties:
> property is used if any real OTG features(HNP/SRP/ADP)
> is enabled, if ADP is required, otg-rev should be
> 0x0200 or above.
> + - companion: phandle of a companion
> - hnp-disable: tells OTG controllers we want to disable OTG HNP, normally
> HNP
> is the basic function of real OTG except you want it
> to be a srp-capable only B device.
> diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
> index 3de4f88..d787f19 100644
> --- a/drivers/usb/core/of.c
> +++ b/drivers/usb/core/of.c
> @@ -18,6 +18,7 @@
> */
>
> #include
> +#include
> #include
>
> /**
> @@ -46,3 +47,25 @@ struct device_node *usb_of_get_child_node(struct
> device_node *parent,
> }
> EXPORT_SYMBOL_GPL(usb_of_get_child_node);
>
> +/**
> + * usb_of_get_companion_dev - Find the companion device
> + * @dev: the device pointer to find a companion
> + *
> + * Find the companion device from platform bus.
> + *
> + * Return: On success, a pointer to the companion device, %NULL on failure.
> + */
> +struct device *usb_of_get_companion_dev(struct device *dev)
> +{
> + struct device_node *node;
> + struct platform_device *pdev = NULL;
> +
> + node = of_parse_phandle(dev->of_node, "companion", 0);
> + if (node)
> + pdev = of_find_device_by_node(node);
> +
> + of_node_put(node);
> +
> + return pdev ? &pdev->dev : NULL;
> +}
> +EXPORT_SYMBOL_GPL(usb_of_get_companion_dev);
> diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
> index 5ff9032..4031f47 100644
> --- a/include/linux/usb/of.h
> +++ b/include/linux/usb/of.h
> @@ -18,6 +18,7 @@ int of_usb_update_otg_caps(struct device_node *np,
> struct usb_otg_caps *otg_caps);
> struct device_node *usb_of_get_child_node(struct device_node *parent,
> int portnum);
> +struct device *usb_of_get_companion_dev(struct device *dev);
> #else
> static inline enum usb_dr_mode
> of_usb_get_dr_mode_by_phy(struct device_node *np, int arg0)
> @@ -38,6 +39,10 @@ static inline int of_usb_update_otg_caps(struct
> device_node *np,
> {
> return NULL;
> }
> +static inline struct device *usb_of_get_companion_dev(struct device *dev)
> +{
> + return NULL;
> +}
> #endif
>
> #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
Acked-by: Peter Chen
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: usb251xb: remove max_{power,current}_{sp,bp} properties
On Tue, Feb 21, 2017 at 09:56:17AM +0100, Richard Leitner wrote:
> Remove the max_{power,current}_{sp,bp} properties of the usb251xb driver
> from devicetree. This is done to simplify the dt bindings as requested
> by Rob Herring in https://lkml.org/lkml/2017/2/15/1283. If those
> properties are ever needed by somebody they can be enabled again easily.
>
> Signed-off-by: Richard Leitner
> ---
> Documentation/devicetree/bindings/usb/usb251xb.txt | 20 --
> drivers/usb/misc/usb251xb.c| 24
> --
> 2 files changed, 4 insertions(+), 40 deletions(-)
Acked-by: Rob Herring
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LKP] [usb] bea5b158ff WARNING: CPU: 0 PID: 25 at drivers/usb/core/urb.c:338 usb_submit_urb
On Tue, Feb 28, 2017 at 12:32:55PM +0800, Ye Xiaolong wrote: > On 02/28, Ye Xiaolong wrote: > >On 02/27, Peter Chen wrote: > >>On Sun, Feb 26, 2017 at 06:19:59PM +0800, Fengguang Wu wrote: > >>> [Sorry, resend to correct Felipe's email address] > >>> > >>> Greetings, > >>> > >>> This debug patch possibly discloses some USB/I2C bugs. Since the USB > >>> warning shows up earlier in dmesg, it might also be the root cause of > >>> the I2C bug. The attached reproduce-* script may help debug them. > >>> > >>> [9.260542] hub 1-0:1.0: 1 port detected > >>> [9.261049] hub 1-0:1.0: USB hub found > >>> [9.261458] hub 1-0:1.0: 1 port detected > >>> [9.262388] kobject (cf9188bc): tried to init an initialized object, > >>> something is seriously wrong. > >>> [9.263589] CPU: 1 PID: 1 Comm: swapper/0 Not tainted > >>> 4.8.0-rc4-3-gbea5b15 #2 > >>> [9.264595] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > >>> BIOS 1.9.3-20161025_171302-gandalf 04/01/2014 > >>> [9.265922] c0047db4 c11aec39 cf9188bc c1c1ba9c > >>> c0047dcc c11b0616 > >>> [9.267073] c1ab0c68 cf9188bc cf9188b4 cf918868 c0047dd8 c13090ec > >>> cf9188b4 c0047de4 > >>> [9.268230] c130a49e ce6a8000 c0047e04 c1402216 ce69300c 00200246 > >>> cf9188b4 cf918000 > >>> [9.269388] Call Trace: > >>> [9.269720] [] dump_stack+0x58/0x72 > >>> [9.270312] [] kobject_init+0x27/0x71 > >>> [9.270929] [] device_initialize+0x1b/0xbd > >>> [9.271599] [] device_register+0xb/0x15 > >>> [9.272236] [] usb_add_gadget_udc_release+0x85/0x215 > >>> [9.273036] [] usb_add_gadget_udc+0xa/0xc > >>> [9.273700] [] dummy_udc_probe+0x130/0x168 > >>> [9.274377] [] platform_drv_probe+0x44/0x80 > >>> [9.275047] [] driver_probe_device+0xfe/0x297 > >>> [9.275748] [] __device_attach_driver+0x65/0x71 > >>> [9.276481] [] bus_for_each_drv+0x3a/0x67 > >>> [9.277130] [] __device_attach+0x86/0xdb > >>> [9.28] [] ? driver_allows_async_probing+0xc/0xc > >>> [9.278561] [] device_initial_probe+0xd/0xf > >>> [9.279235] [] bus_probe_device+0x25/0x67 > >>> [9.279895] [] device_add+0x341/0x497 > >>> [9.280517] [] ? dev_set_name+0x14/0x16 > >>> [9.281154] [] platform_device_add+0x117/0x161 > >>> [9.281879] [] init+0x20d/0x2f4 > >>> [9.282431] [] ? usb_udc_init+0x3f/0x3f > >>> [9.283075] [] do_one_initcall+0x7e/0xfc > >>> [9.283725] [] ? parse_args+0x19b/0x26f > >>> [9.284362] [] ? kernel_init_freeable+0x147/0x1eb > >>> [9.285100] [] kernel_init_freeable+0x163/0x1eb > >>> [9.285826] [] kernel_init+0x8/0xd0 > >>> [9.286417] [] ret_from_kernel_thread+0xe/0x24 > >>> [9.287118] [] ? rest_init+0xa5/0xa5 > >>> [9.288532] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at > >>> 0x60,0x64 irq 1,12 > >>> [9.290663] serio: i8042 KBD port at 0x60,0x64 irq 1 > >>> [9.291372] serio: i8042 AUX port at 0x60,0x64 irq 12 > >>> [9.293351] serio: i8042 KBD port at 0x60,0x64 irq 1 > >>> [9.294031] serio: i8042 AUX port at 0x60,0x64 irq 12 > >> > >>Fengguang, thanks for reporting it, I can also reproduce it using > >>unbind/bind interface for dummy_udc. The reason for it is that > >>the memory region of struct usb_gadget at dummy_udc is from the > >>platform data of platform device dummy_udc, so this memory region > >>will not be released after the resources for device dummy_udc are > >>released. The below diff can fix my problem, would you mind testing > >>it: > > > >I've queued jobs to verify your fix, I'll post the result once I get it. > > The dummy_udc WARN is gone with this patch for 100+ times of boot tests. > > Tested-by: Xiaolong Ye > > Thanks, > Xiaolong > Thanks, Xiaolong. I will submit a patch for it. Peter > > > >Thanks, > >Xiaolong > >> > >>diff --git a/drivers/usb/gadget/udc/dummy_hcd.c > >>b/drivers/usb/gadget/udc/dummy_hcd.c > >>index c60abe3..a358cb9 100644 > >>--- a/drivers/usb/gadget/udc/dummy_hcd.c > >>+++ b/drivers/usb/gadget/udc/dummy_hcd.c > >>@@ -1031,6 +1031,7 @@ static int dummy_udc_probe(struct platform_device > >>*pdev) > >>int rc; > >> > >>dum = *((void **)dev_get_platdata(&pdev->dev)); > >>+ memzero_explicit(&dum->gadget, sizeof (struct usb_gadget)); > >>dum->gadget.name = gadget_name; > >>dum->gadget.ops = &dummy_ops; > >>dum->gadget.max_speed = USB_SPEED_SUPER; > >> > >> > >>Peter > >>> > >>> The attached dmesg has more follow up errors. > >>> > >>> git bisect start v4.9 v4.8 -- > >>> git bisect bad 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942 # 00:43 18- > >>> 30 Merge branch 'linus' of > >>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 > >>> git bisect bad d8ea757b25ec82687c497fc90aa83f9bcea24b5b # 01:11 4- > >>> 6 Merge tag 'xtensa-20161005' of > >>> git://github.com/jcmvbkbc/linux-xtensa > >>> git bisect bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c # 01:17 6- > >
Re: [LKP] [usb] bea5b158ff WARNING: CPU: 0 PID: 25 at drivers/usb/core/urb.c:338 usb_submit_urb
The dummy_udc WARN is gone with this patch for 100+ times of boot tests. Tested-by: Xiaolong Ye Thanks, Xiaolong Thanks, Xiaolong. I will submit a patch for it. Thank you Peter! We've been noised by this warning for quite some time. Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LKP] [usb] bea5b158ff WARNING: CPU: 0 PID: 25 at drivers/usb/core/urb.c:338 usb_submit_urb
On 02/28, Ye Xiaolong wrote: >On 02/27, Peter Chen wrote: >>On Sun, Feb 26, 2017 at 06:19:59PM +0800, Fengguang Wu wrote: >>> [Sorry, resend to correct Felipe's email address] >>> >>> Greetings, >>> >>> This debug patch possibly discloses some USB/I2C bugs. Since the USB >>> warning shows up earlier in dmesg, it might also be the root cause of >>> the I2C bug. The attached reproduce-* script may help debug them. >>> >>> [9.260542] hub 1-0:1.0: 1 port detected >>> [9.261049] hub 1-0:1.0: USB hub found >>> [9.261458] hub 1-0:1.0: 1 port detected >>> [9.262388] kobject (cf9188bc): tried to init an initialized object, >>> something is seriously wrong. >>> [9.263589] CPU: 1 PID: 1 Comm: swapper/0 Not tainted >>> 4.8.0-rc4-3-gbea5b15 #2 >>> [9.264595] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >>> 1.9.3-20161025_171302-gandalf 04/01/2014 >>> [9.265922] c0047db4 c11aec39 cf9188bc c1c1ba9c >>> c0047dcc c11b0616 >>> [9.267073] c1ab0c68 cf9188bc cf9188b4 cf918868 c0047dd8 c13090ec >>> cf9188b4 c0047de4 >>> [9.268230] c130a49e ce6a8000 c0047e04 c1402216 ce69300c 00200246 >>> cf9188b4 cf918000 >>> [9.269388] Call Trace: >>> [9.269720] [] dump_stack+0x58/0x72 >>> [9.270312] [] kobject_init+0x27/0x71 >>> [9.270929] [] device_initialize+0x1b/0xbd >>> [9.271599] [] device_register+0xb/0x15 >>> [9.272236] [] usb_add_gadget_udc_release+0x85/0x215 >>> [9.273036] [] usb_add_gadget_udc+0xa/0xc >>> [9.273700] [] dummy_udc_probe+0x130/0x168 >>> [9.274377] [] platform_drv_probe+0x44/0x80 >>> [9.275047] [] driver_probe_device+0xfe/0x297 >>> [9.275748] [] __device_attach_driver+0x65/0x71 >>> [9.276481] [] bus_for_each_drv+0x3a/0x67 >>> [9.277130] [] __device_attach+0x86/0xdb >>> [9.28] [] ? driver_allows_async_probing+0xc/0xc >>> [9.278561] [] device_initial_probe+0xd/0xf >>> [9.279235] [] bus_probe_device+0x25/0x67 >>> [9.279895] [] device_add+0x341/0x497 >>> [9.280517] [] ? dev_set_name+0x14/0x16 >>> [9.281154] [] platform_device_add+0x117/0x161 >>> [9.281879] [] init+0x20d/0x2f4 >>> [9.282431] [] ? usb_udc_init+0x3f/0x3f >>> [9.283075] [] do_one_initcall+0x7e/0xfc >>> [9.283725] [] ? parse_args+0x19b/0x26f >>> [9.284362] [] ? kernel_init_freeable+0x147/0x1eb >>> [9.285100] [] kernel_init_freeable+0x163/0x1eb >>> [9.285826] [] kernel_init+0x8/0xd0 >>> [9.286417] [] ret_from_kernel_thread+0xe/0x24 >>> [9.287118] [] ? rest_init+0xa5/0xa5 >>> [9.288532] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at >>> 0x60,0x64 irq 1,12 >>> [9.290663] serio: i8042 KBD port at 0x60,0x64 irq 1 >>> [9.291372] serio: i8042 AUX port at 0x60,0x64 irq 12 >>> [9.293351] serio: i8042 KBD port at 0x60,0x64 irq 1 >>> [9.294031] serio: i8042 AUX port at 0x60,0x64 irq 12 >> >>Fengguang, thanks for reporting it, I can also reproduce it using >>unbind/bind interface for dummy_udc. The reason for it is that >>the memory region of struct usb_gadget at dummy_udc is from the >>platform data of platform device dummy_udc, so this memory region >>will not be released after the resources for device dummy_udc are >>released. The below diff can fix my problem, would you mind testing >>it: > >I've queued jobs to verify your fix, I'll post the result once I get it. The dummy_udc WARN is gone with this patch for 100+ times of boot tests. Tested-by: Xiaolong Ye Thanks, Xiaolong > >Thanks, >Xiaolong >> >>diff --git a/drivers/usb/gadget/udc/dummy_hcd.c >>b/drivers/usb/gadget/udc/dummy_hcd.c >>index c60abe3..a358cb9 100644 >>--- a/drivers/usb/gadget/udc/dummy_hcd.c >>+++ b/drivers/usb/gadget/udc/dummy_hcd.c >>@@ -1031,6 +1031,7 @@ static int dummy_udc_probe(struct platform_device *pdev) >> int rc; >> >> dum = *((void **)dev_get_platdata(&pdev->dev)); >>+ memzero_explicit(&dum->gadget, sizeof (struct usb_gadget)); >> dum->gadget.name = gadget_name; >> dum->gadget.ops = &dummy_ops; >> dum->gadget.max_speed = USB_SPEED_SUPER; >> >> >>Peter >>> >>> The attached dmesg has more follow up errors. >>> >>> git bisect start v4.9 v4.8 -- >>> git bisect bad 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942 # 00:43 18- >>> 30 Merge branch 'linus' of >>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 >>> git bisect bad d8ea757b25ec82687c497fc90aa83f9bcea24b5b # 01:11 4- >>>6 Merge tag 'xtensa-20161005' of git://github.com/jcmvbkbc/linux-xtensa >>> git bisect bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c # 01:17 6- >>> 11 Merge tag 'usb-4.9-rc1' of >>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb >>> git bisect good 1a4a2bc460721bc8f91e4c1294d39b38e5af132f # 01:32 52+ >>>0 Merge branch 'x86-asm-for-linus' of >>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip >>> git bisect good 3ef0a61a467639cf7def299309cd9
[PATCH 1/1] usb: gadget: dummy_hcd: clear usb_gadget region before registration
When the user does device unbind and rebind test, the kernel will
show below dump due to usb_gadget memory region is dirty after unbind.
Clear usb_gadget region for every new probe.
root@imx6qdlsolo:/sys/bus/platform/drivers/dummy_udc# echo dummy_udc.0 > bind
[ 102.523312] kobject (eddd78b0): tried to init an initialized object,
something is seriously wrong.
[ 102.532447] CPU: 0 PID: 734 Comm: sh Not tainted 4.10.0-rc7-00872-g1b2b8e9
#1298
[ 102.539866] Hardware name: Freescale i.MX6 SoloX (Device Tree)
[ 102.545717] Backtrace:
[ 102.548225] [] (dump_backtrace) from []
(show_stack+0x18/0x1c)
[ 102.555822] r7:ede34000 r6:60010013 r5: r4:c0f29418
[ 102.561512] [] (show_stack) from []
(dump_stack+0xb4/0xe8)
[ 102.568764] [] (dump_stack) from []
(kobject_init+0x80/0x9c)
[ 102.576187] r10:001f r9:eddd7000 r8:eeaf8c10 r7:eddd78a8 r6:c177891c
r5:c0f3b060
[ 102.584036] r4:eddd78b0 r3:
[ 102.587641] [] (kobject_init) from []
(device_initialize+0x28/0xf8)
[ 102.595665] r5:eebc4800 r4:eddd78a8
[ 102.599268] [] (device_initialize) from []
(device_register+0x14/0x20)
[ 102.607556] r7:eddd78a8 r6: r5:eebc4800 r4:eddd78a8
[ 102.613256] [] (device_register) from []
(usb_add_gadget_udc_release+0x8c/0x1ec)
[ 102.622410] r5:eebc4800 r4:eddd7860
[ 102.626015] [] (usb_add_gadget_udc_release) from []
(usb_add_gadget_udc+0x14/0x18)
[ 102.635351] r10:001f r9:eddd7000 r8:eddd788c r7:bf003770 r6:eddd77f8
r5:eddd7818
[ 102.643198] r4:eddd785c r3:eddd7b24
[ 102.646834] [] (usb_add_gadget_udc) from []
(dummy_udc_probe+0x170/0x1c4 [dummy_hcd])
[ 102.656458] [] (dummy_udc_probe [dummy_hcd]) from []
(platform_drv_probe+0x54/0xb8)
[ 102.665881] r10:0008 r9:c1778960 r8:bf004128 r7:fdfb r6:bf004128
r5:eeaf8c10
[ 102.673727] r4:eeaf8c10
[ 102.676293] [] (platform_drv_probe) from []
(driver_probe_device+0x264/0x474)
[ 102.685186] r7: r6: r5:c1778960 r4:eeaf8c10
[ 102.690876] [] (driver_probe_device) from []
(bind_store+0xb8/0x14c)
[ 102.698994] r10:eeb3bb4c r9:ede34000 r8:000c r7:eeaf8c44 r6:bf004128
r5:c0f3b668
[ 102.706840] r4:eeaf8c10
[ 102.709402] [] (bind_store) from []
(drv_attr_store+0x28/0x34)
[ 102.716998] r9:ede34000 r8: r7:ee3863c0 r6:ee3863c0 r5:c0538c80
r4:c053970c
[ 102.724776] [] (drv_attr_store) from []
(sysfs_kf_write+0x50/0x54)
[ 102.732711] r5:c0538c80 r4:000c
[ 102.736313] [] (sysfs_kf_write) from []
(kernfs_fop_write+0x100/0x214)
[ 102.744599] r7:ee3863c0 r6:eeb3bb40 r5: r4:
[ 102.750287] [] (kernfs_fop_write) from []
(__vfs_write+0x34/0x120)
[ 102.758231] r10: r9:ede34000 r8:c0108bc4 r7:000c r6:ede35f80
r5:c029bd84
[ 102.766077] r4:ee223780
[ 102.768638] [] (__vfs_write) from []
(vfs_write+0xa8/0x170)
[ 102.775974] r9:ede34000 r8:c0108bc4 r7:ede35f80 r6:01861cb0 r5:ee223780
r4:000c
[ 102.783743] [] (vfs_write) from [] (SyS_write+0x4c/0xa8)
[ 102.790818] r9:ede34000 r8:c0108bc4 r7:000c r6:01861cb0 r5:ee223780
r4:ee223780
[ 102.798595] [] (SyS_write) from []
(ret_fast_syscall+0x0/0x1c)
[ 102.806188] r7:0004 r6:b6e83d58 r5:01861cb0 r4:000c
Cc: Alan Stern
Cc: stable
Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC
drivers")
Signed-off-by: Peter Chen
Tested-by: Xiaolong Ye
Reported-by: Fengguang Wu
---
drivers/usb/gadget/udc/dummy_hcd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index c60abe3..8cabc59 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -1031,6 +1031,8 @@ static int dummy_udc_probe(struct platform_device *pdev)
int rc;
dum = *((void **)dev_get_platdata(&pdev->dev));
+ /* Clear usb_gadget region for new registration to udc-core */
+ memzero_explicit(&dum->gadget, sizeof(struct usb_gadget));
dum->gadget.name = gadget_name;
dum->gadget.ops = &dummy_ops;
dum->gadget.max_speed = USB_SPEED_SUPER;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] HID: hiddev: allocate minor number hiddev's USB interface is bound to
Hi Jiri, Benjamin Could you please review my hiddev patch? Thanks, jaejoong 2017-02-15 18:55 GMT+09:00 Jaejoong Kim : > When HID device connected to the PC, HID device driver announces which > driver is loaded with a kernel info message. In this case, hiddev's minor > number is always '0' even though hiddev's real minor number is not zero. > > To display hiddev with minor number asked from usb core, we need > to fill hiddev's minor number this interface is bound to. > > Signed-off-by: Jaejoong Kim > --- > Changes in v2: > - fix typo in commit message > --- > > drivers/hid/usbhid/hiddev.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c > index 700145b..27e1f8d 100644 > --- a/drivers/hid/usbhid/hiddev.c > +++ b/drivers/hid/usbhid/hiddev.c > @@ -910,6 +910,7 @@ int hiddev_connect(struct hid_device *hid, unsigned int > force) > kfree(hiddev); > return -1; > } > + hid->minor = usbhid->intf->minor; > return 0; > } > > -- > 2.7.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
