drivers/usb/usbip/vhci_hcd.c | 3 +++ 1 file changed, 3 insertions(+)
From: Zongmin Zhou <zhouzongmin@kylinos.cn>
fix usb device limited max_sectors when use usbip protocol
Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn>
---
drivers/usb/usbip/vhci_hcd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index e70fba9f55d6..fca3a4a6e94d 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1345,6 +1345,9 @@ static int vhci_hcd_probe(struct platform_device *pdev)
usbip_dbg_vhci_hc("name %s id %d\n", pdev->name, pdev->id);
+ /* Set the dma mask to support 64bit for vhci-hcd driver. */
+ dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+
/*
* Allocate and initialize hcd.
* Our private data is also allocated automatically.
--
2.34.1Hi Zongmin,
kernel test robot noticed the following build errors:
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on usb/usb-next usb/usb-linus linus/master v6.15-rc3 next-20250422]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Zongmin-Zhou/usbip-set-the-dma-mask-to-64bit-default-for-vhci-driver/20250422-143646
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
patch link: https://lore.kernel.org/r/20250422063409.607859-1-min_halo%40163.com
patch subject: [PATCH] usbip: set the dma mask to 64bit default for vhci-driver
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20250423/202504231526.8kjh2iap-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250423/202504231526.8kjh2iap-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202504231526.8kjh2iap-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/usb/usbip/vhci_hcd.c: In function 'vhci_hcd_probe':
>> drivers/usb/usbip/vhci_hcd.c:1349:9: error: implicit declaration of function 'dma_set_mask'; did you mean 'xa_set_mark'? [-Wimplicit-function-declaration]
1349 | dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
| ^~~~~~~~~~~~
| xa_set_mark
>> drivers/usb/usbip/vhci_hcd.c:1349:34: error: implicit declaration of function 'DMA_BIT_MASK'; did you mean 'BIT_MASK'? [-Wimplicit-function-declaration]
1349 | dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
| ^~~~~~~~~~~~
| BIT_MASK
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for DRM_AUX_HPD_BRIDGE
Depends on [n]: HAS_IOMEM [=y] && DRM [=n] && DRM_BRIDGE [=n] && OF [=y]
Selected by [m]:
- UCSI_HUAWEI_GAOKUN [=m] && USB_SUPPORT [=y] && TYPEC [=m] && TYPEC_UCSI [=m] && EC_HUAWEI_GAOKUN [=m]
vim +1349 drivers/usb/usbip/vhci_hcd.c
1338
1339 static int vhci_hcd_probe(struct platform_device *pdev)
1340 {
1341 struct vhci *vhci = *((void **)dev_get_platdata(&pdev->dev));
1342 struct usb_hcd *hcd_hs;
1343 struct usb_hcd *hcd_ss;
1344 int ret;
1345
1346 usbip_dbg_vhci_hc("name %s id %d\n", pdev->name, pdev->id);
1347
1348 /* Set the dma mask to support 64bit for vhci-hcd driver. */
> 1349 dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
1350
1351 /*
1352 * Allocate and initialize hcd.
1353 * Our private data is also allocated automatically.
1354 */
1355 hcd_hs = usb_create_hcd(&vhci_hc_driver, &pdev->dev, dev_name(&pdev->dev));
1356 if (!hcd_hs) {
1357 pr_err("create primary hcd failed\n");
1358 return -ENOMEM;
1359 }
1360 hcd_hs->has_tt = 1;
1361
1362 /*
1363 * Finish generic HCD structure initialization and register.
1364 * Call the driver's reset() and start() routines.
1365 */
1366 ret = usb_add_hcd(hcd_hs, 0, 0);
1367 if (ret != 0) {
1368 pr_err("usb_add_hcd hs failed %d\n", ret);
1369 goto put_usb2_hcd;
1370 }
1371
1372 hcd_ss = usb_create_shared_hcd(&vhci_hc_driver, &pdev->dev,
1373 dev_name(&pdev->dev), hcd_hs);
1374 if (!hcd_ss) {
1375 ret = -ENOMEM;
1376 pr_err("create shared hcd failed\n");
1377 goto remove_usb2_hcd;
1378 }
1379
1380 ret = usb_add_hcd(hcd_ss, 0, 0);
1381 if (ret) {
1382 pr_err("usb_add_hcd ss failed %d\n", ret);
1383 goto put_usb3_hcd;
1384 }
1385
1386 usbip_dbg_vhci_hc("bye\n");
1387 return 0;
1388
1389 put_usb3_hcd:
1390 usb_put_hcd(hcd_ss);
1391 remove_usb2_hcd:
1392 usb_remove_hcd(hcd_hs);
1393 put_usb2_hcd:
1394 usb_put_hcd(hcd_hs);
1395 vhci->vhci_hcd_hs = NULL;
1396 vhci->vhci_hcd_ss = NULL;
1397 return ret;
1398 }
1399
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Hi Zongmin,
kernel test robot noticed the following build errors:
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on usb/usb-next usb/usb-linus linus/master v6.15-rc3 next-20250422]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Zongmin-Zhou/usbip-set-the-dma-mask-to-64bit-default-for-vhci-driver/20250422-143646
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
patch link: https://lore.kernel.org/r/20250422063409.607859-1-min_halo%40163.com
patch subject: [PATCH] usbip: set the dma mask to 64bit default for vhci-driver
config: arm-randconfig-004-20250423 (https://download.01.org/0day-ci/archive/20250423/202504230805.MkmxQyas-lkp@intel.com/config)
compiler: clang version 21.0.0git (https://github.com/llvm/llvm-project f819f46284f2a79790038e1f6649172789734ae8)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250423/202504230805.MkmxQyas-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202504230805.MkmxQyas-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/usb/usbip/vhci_hcd.c:1349:2: error: call to undeclared function 'dma_set_mask'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
1349 | dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
| ^
drivers/usb/usbip/vhci_hcd.c:1349:2: note: did you mean 'xa_set_mark'?
include/linux/xarray.h:361:6: note: 'xa_set_mark' declared here
361 | void xa_set_mark(struct xarray *, unsigned long index, xa_mark_t);
| ^
>> drivers/usb/usbip/vhci_hcd.c:1349:27: error: call to undeclared function 'DMA_BIT_MASK'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
1349 | dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
| ^
2 errors generated.
vim +/dma_set_mask +1349 drivers/usb/usbip/vhci_hcd.c
1338
1339 static int vhci_hcd_probe(struct platform_device *pdev)
1340 {
1341 struct vhci *vhci = *((void **)dev_get_platdata(&pdev->dev));
1342 struct usb_hcd *hcd_hs;
1343 struct usb_hcd *hcd_ss;
1344 int ret;
1345
1346 usbip_dbg_vhci_hc("name %s id %d\n", pdev->name, pdev->id);
1347
1348 /* Set the dma mask to support 64bit for vhci-hcd driver. */
> 1349 dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
1350
1351 /*
1352 * Allocate and initialize hcd.
1353 * Our private data is also allocated automatically.
1354 */
1355 hcd_hs = usb_create_hcd(&vhci_hc_driver, &pdev->dev, dev_name(&pdev->dev));
1356 if (!hcd_hs) {
1357 pr_err("create primary hcd failed\n");
1358 return -ENOMEM;
1359 }
1360 hcd_hs->has_tt = 1;
1361
1362 /*
1363 * Finish generic HCD structure initialization and register.
1364 * Call the driver's reset() and start() routines.
1365 */
1366 ret = usb_add_hcd(hcd_hs, 0, 0);
1367 if (ret != 0) {
1368 pr_err("usb_add_hcd hs failed %d\n", ret);
1369 goto put_usb2_hcd;
1370 }
1371
1372 hcd_ss = usb_create_shared_hcd(&vhci_hc_driver, &pdev->dev,
1373 dev_name(&pdev->dev), hcd_hs);
1374 if (!hcd_ss) {
1375 ret = -ENOMEM;
1376 pr_err("create shared hcd failed\n");
1377 goto remove_usb2_hcd;
1378 }
1379
1380 ret = usb_add_hcd(hcd_ss, 0, 0);
1381 if (ret) {
1382 pr_err("usb_add_hcd ss failed %d\n", ret);
1383 goto put_usb3_hcd;
1384 }
1385
1386 usbip_dbg_vhci_hc("bye\n");
1387 return 0;
1388
1389 put_usb3_hcd:
1390 usb_put_hcd(hcd_ss);
1391 remove_usb2_hcd:
1392 usb_remove_hcd(hcd_hs);
1393 put_usb2_hcd:
1394 usb_put_hcd(hcd_hs);
1395 vhci->vhci_hcd_hs = NULL;
1396 vhci->vhci_hcd_ss = NULL;
1397 return ret;
1398 }
1399
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Tue, Apr 22, 2025 at 02:34:09PM +0800, Zongmin Zhou wrote: > From: Zongmin Zhou <zhouzongmin@kylinos.cn> > > fix usb device limited max_sectors when use usbip protocol As far as I can tell this is a virtual HCI and can't perform DMA. Thus nothing should use DMA API calls on it and the mask is irrelevant.
Dear Greg and Christoph: This patch is the simple solution for the issue described in below link: https://lore.kernel.org/all/20250219092555.112631-1-min_halo@163.com/ This issue has been discussed at length with Shuah. As Christoph said,vhci-hcd is a virtual hci, but it serves as a bridge to connect virtual USB devices to the real USB controller. Since the commit d74ffae8b8dd is applied on kernel v5.3, the virtual USB devices's max_sectors size is limited since v5.3. Just because on vhci-hcd, the dma mask setting follows the platform device default setting(32-bit). So I want to get the real USB controller dma mask to set on vhci-hcd driver， or set to 64 by default,to fix the max_sectors limited issue on virtual USB device since the commit d74ffae8b8dd applied. Thanks. On 2025/4/22 15:24, Christoph Hellwig wrote: > On Tue, Apr 22, 2025 at 02:34:09PM +0800, Zongmin Zhou wrote: >> From: Zongmin Zhou <zhouzongmin@kylinos.cn> >> >> fix usb device limited max_sectors when use usbip protocol > As far as I can tell this is a virtual HCI and can't perform DMA. > Thus nothing should use DMA API calls on it and the mask is irrelevant.
On Fri, Apr 25, 2025 at 04:08:47PM +0800, Zongmin Zhou wrote: > Dear Greg and Christoph: > > This patch is the simple solution for the issue described in below link: > https://lore.kernel.org/all/20250219092555.112631-1-min_halo@163.com/ > > This issue has been discussed at length with Shuah. > > As Christoph said,vhci-hcd is a virtual hci, > but it serves as a bridge to connect virtual USB devices to the real USB > controller. > Since the commit d74ffae8b8dd is applied on kernel v5.3, > the virtual USB devices's max_sectors size is limited since v5.3. > > Just because on vhci-hcd, the dma mask setting follows the platform device > default setting(32-bit). Wait, why is vhci-hcd a platform device at all? It shouldn't be doing that, try removing that to start with, which will remove that "default" setting. I recommend using the faux bus as a potential replacement. thanks, greg k-h
Dear Greg and Shuah, I found out that the vhci-hcd driver added this virtual device as a platform device from the very beginning since 2014. I'm just getting in touch with this module and don't have a deep understanding of it，shuah should be clearer. I don't know if using the faux bus to replace the platform bus can solve the problem that the error limitation on max_hw_sectors for usbip device since commit d74ffae8b8dd applied. But this change will request user to update kernel version to support faux bus. This will also be an expensive change to fix the problem? I have been discussing with shuah for a long time. Is there any simpler way to fix this problem? On 2025/4/25 16:28, Greg KH wrote: > On Fri, Apr 25, 2025 at 04:08:47PM +0800, Zongmin Zhou wrote: >> Dear Greg and Christoph: >> >> This patch is the simple solution for the issue described in below link: >> https://lore.kernel.org/all/20250219092555.112631-1-min_halo@163.com/ >> >> This issue has been discussed at length with Shuah. >> >> As Christoph said,vhci-hcd is a virtual hci, >> but it serves as a bridge to connect virtual USB devices to the real USB >> controller. >> Since the commit d74ffae8b8dd is applied on kernel v5.3, >> the virtual USB devices's max_sectors size is limited since v5.3. >> >> Just because on vhci-hcd, the dma mask setting follows the platform device >> default setting(32-bit). > Wait, why is vhci-hcd a platform device at all? It shouldn't be doing > that, try removing that to start with, which will remove that "default" > setting. I recommend using the faux bus as a potential replacement. > > thanks, > > greg k-h
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Mon, Apr 28, 2025 at 05:51:08PM +0800, Zongmin Zhou wrote: > Dear Greg and Shuah, > > I found out that the vhci-hcd driver added this virtual device > as a platform device from the very beginning since 2014. Ah, I should have caught it back then, but at the time there really wasn't another option. > I'm just getting in touch with this module and > don't have a deep understanding of it，shuah should be clearer. See the recent patches I did converting drivers to use the faux bus code, it should be pretty simple to do. > I don't know if using the faux bus to replace the platform bus can solve the > problem that the error limitation on max_hw_sectors for usbip device > since commit d74ffae8b8dd applied. That is for the storage driver, not usbip. As the faux bus does not have any real dma operations, this should cause it to work properly given the default values involed, but that's up to you to test to verify it does just that. Try it and see! > But this change will request user to update kernel version to support faux > bus. That's just a normal kernel update to a newer version, what is wrong with that? > This will also be an expensive change to fix the problem? Fixing things properly is the correct thing to do in all cases. thanks, greg k-h
On 4/28/25 04:04, Greg KH wrote: > A: http://en.wikipedia.org/wiki/Top_post > Q: Were do I find info about this thing called top-posting? > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > On Mon, Apr 28, 2025 at 05:51:08PM +0800, Zongmin Zhou wrote: >> Dear Greg and Shuah, >> >> I found out that the vhci-hcd driver added this virtual device >> as a platform device from the very beginning since 2014. > > Ah, I should have caught it back then, but at the time there really > wasn't another option. > >> I'm just getting in touch with this module and >> don't have a deep understanding of it，shuah should be clearer. faux_device should work fine for this. We do have to test of course. There are several examples of converting platform device to faux device. 72239a78f9f5b9f05ea4bb7a15b92807906dab71 dcd2a9a5550ef556c8fc11601a0f729fb71ead5d > > See the recent patches I did converting drivers to use the faux bus > code, it should be pretty simple to do. > >> I don't know if using the faux bus to replace the platform bus can solve the >> problem that the error limitation on max_hw_sectors for usbip device >> since commit d74ffae8b8dd applied. > > That is for the storage driver, not usbip. As the faux bus does not > have any real dma operations, this should cause it to work properly > given the default values involed, but that's up to you to test to verify > it does just that. Try it and see! > >> But this change will request user to update kernel version to support faux >> bus. > > That's just a normal kernel update to a newer version, what is wrong > with that? With one difference that the fix depends on faux_device feature - hence we can't apply it to stables. I do think it is the right direction to go to faux_device. > >> This will also be an expensive change to fix the problem? > > Fixing things properly is the correct thing to do in all cases. > Zongmin, do let me know if you are unable to make the change. thanks, -- Shuah
On 2025/4/29 07:07, Shuah Khan wrote: > On 4/28/25 04:04, Greg KH wrote: >> A: http://en.wikipedia.org/wiki/Top_post >> Q: Were do I find info about this thing called top-posting? >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> A: Top-posting. >> Q: What is the most annoying thing in e-mail? >> >> A: No. >> Q: Should I include quotations after my reply? >> >> http://daringfireball.net/2007/07/on_top >> Sorry for that,and thank you for the comment!I've learned it. >> On Mon, Apr 28, 2025 at 05:51:08PM +0800, Zongmin Zhou wrote: >>> Dear Greg and Shuah, >>> >>> I found out that the vhci-hcd driver added this virtual device >>> as a platform device from the very beginning since 2014. >> >> Ah, I should have caught it back then, but at the time there really >> wasn't another option. >> > >>> I'm just getting in touch with this module and >>> don't have a deep understanding of it，shuah should be clearer. > > faux_device should work fine for this. We do have to test of course. > > There are several examples of converting platform device to faux device. > > 72239a78f9f5b9f05ea4bb7a15b92807906dab71 > dcd2a9a5550ef556c8fc11601a0f729fb71ead5d > Ok,I will learn to do it. Thank you for your guidance. >> >> See the recent patches I did converting drivers to use the faux bus >> code, it should be pretty simple to do. >> >>> I don't know if using the faux bus to replace the platform bus can >>> solve the >>> problem that the error limitation on max_hw_sectors for usbip device >>> since commit d74ffae8b8dd applied. >> >> That is for the storage driver, not usbip. As the faux bus does not >> have any real dma operations, this should cause it to work properly >> given the default values involed, but that's up to you to test to verify >> it does just that. Try it and see! >> >>> But this change will request user to update kernel version to >>> support faux >>> bus. >> >> That's just a normal kernel update to a newer version, what is wrong >> with that? > > With one difference that the fix depends on faux_device feature - hence > we can't apply it to stables. I do think it is the right direction to > go to faux_device. > I just encountered similar users who were using a lower version of the kernel and were unwilling to upgrade. But if reach a consensus to go to faux_device, I will try to make the change(converting platform device to faux device for vhci-hcd). >> >>> This will also be an expensive change to fix the problem? >> >> Fixing things properly is the correct thing to do in all cases. >> > > Zongmin, do let me know if you are unable to make the change. > > thanks, > -- Shuah
On Wed, Apr 30, 2025 at 01:24:31PM +0800, Zongmin Zhou wrote: > > With one difference that the fix depends on faux_device feature - hence > > we can't apply it to stables. I do think it is the right direction to > > go to faux_device. > > > I just encountered similar users who were using a lower version of the > kernel and were unwilling to upgrade. That is not our problem here, sorry. > But if reach a consensus to go to faux_device, > I will try to make the change(converting platform device to faux device for > vhci-hcd). We have said that you should try this, no need for us to ask again. thanks, greg k-h
On Tue, Apr 22, 2025 at 02:34:09PM +0800, Zongmin Zhou wrote: > From: Zongmin Zhou <zhouzongmin@kylinos.cn> > > fix usb device limited max_sectors when use usbip protocol Please explain more as to why this is needed. > > Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn> What commit id does this fix? thanks, greg k-h
© 2016 - 2025 Red Hat, Inc.