Re: driver migration
Hello
> You can use ftrace to help you watch the flow of your driver before it
> crashes, or just printk, as you have found out, is the best way to debug
> things.
Thanks for the hints. I will give ftrace a go.
It takes me around 5-7 minutes to see the kernel crash, and then reboot,
make changes, and try again (more if I use eclipse). I am wondering, if
there are ways to allow faster turnaround times. Maybe, it would be an
option to run the tests in an emulator, such as qemu? Any experience with that?
The first crash that is also logged I am getting in
usbrsa_allocate_write_urbs when calling spin_lock_irqsave. I see no obvious
mistakes, and on an old 3.0.x kernel, this was running fine. Any suggestion
of what am I doing wrong here?
printk("%s -- clear_bit",__func__);
spin_lock_irqsave(&priv_data->lock,flags);
clear_bit( i,&priv_data->write_urb_pool_lock);
spin_unlock_irqrestore(&priv_data->lock,flags);
printk("%s -- clear_bit end",__func__);
Here the log:
usbrsa: module verification failed: signature and/o
r required key missing - tainting kernel
usbcore: registered new interface driver usbrsa
usbserial: USB Serial support registered for IO-DAT
A - USB-RSA - (prerenumeration) usbserial: USB Serial support registered
for IO-DATA - USB-RSA
usb 3-3: new full-speed USB device number 2 using x
hci_hcd
usb 3-3: New USB device found, idVendor=04bb, idPro
duct=0a01
usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 3-3: usbrsa_firmware_download
usb 3-3: usbrsa_firmware_download(): Firmware downloaded.
usb 3-3: usbrsa_firmware_download(): Device with new firmware reset.
usbrsa 3-3:1.0: IO-DATA - USB-RSA - (prerenumeration) converter detected
Feb 22 07:48:52 btron mtp-probe: checking bus 3, device 2:
"/sys/devices/pci:00/:00:14.0/usb3/3-3"
mtp-probe: bus: 3, device: 2 was not an MTP device
usb 3-3: USB disconnect, device number 2
usbrsa 3-3:1.0: device disconnected
usb 3-3: new full-speed USB device number 3 using xhci_hcd
usb 3-3: New USB device found, idVendor=04bb, idProduct=0a02
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: USB-RS232C CONVERTER
usb 3-3: Manufacturer: I-O DATA DEVICE,Inc.
usb 3-3: SerialNumber: USB-RSA Rev.1䰑羐
USB-RSA converter detected
usbrsa_attach start
usb 3-3: usbrsa_attach
usbrsa_attach about to enter
'usbrsa_allocate_write_urbs'usbrsa_allocate_write_urbs() Mark 1
usb-serial (null): usbrsa_allocate_write_urbs()
usbrsa_allocate_write_urbs() Mark 2usbrsa_allocate_write_urbs; i=0
usbrsa_allocate_write_urbs; Mark3
usbrsa_allocate_write_urbs; Mark4
usbrsa_allocate_write_urbs -- clear_bit
BUG: unable to handle kernel paging request at 1ddc00017654
IP: [] native_queued_spin_lock_slowpath+0x104/0x190
PGD 0
Oops: 0002 [#1] SMP
Modules linked in: usbrsa(OE) usbserial ezusb drbg ansi_cprng ctr ccm bnep
rfcomm dm_crypt nfsd auth_rpcgss nfs_acl nfs lockd grace sunrpc binfmt_misc
fscache nls_iso8859_1 uvcvideo videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2 videobuf2_core videodev arc4 iwldvm mac80211
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec
btusb intel_rapl x86_pkg_temp_thermal intel_powerclamp btrtl btbcm coretemp
snd_hda_core btintel snd_hwdep kvm_intel iwlwifi bluetooth kvm snd_pcm
snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq irqbypass mei_me
snd_seq_device snd_timer snd cfg80211 mei asus_nb_wmi asus_wmi sparse_keymap
crct10dif_pclmul soundcore crc32_pclmul ghash_clmulni_intel aesni_intel
shpchp lpc_ich aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev
serio_raw mac_hid parport_pc ppdev lp parport nouveau i915 mxm_wmi ttm
i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
drm ahci psmouse alx libahci mdio wmi video
CPU: 4 PID: 37 Comm: kworker/4:0 Tainted: G OE 4.5.0-rc4-custom #1
Hardware name: ASUSTeK COMPUTER INC. N56VZ/N56VZ, BIOS N56VZ.215 11/02/2012
Workqueue: usb_hub_wq hub_event
task: 88041c54d7c0 ti: 88041c57c000 task.ti 88041c57c000
RIP: 0010:[] []
native_queued_spin_lock_slowpath+0x104/0x190
RSP: 0018:88041c57f700 EFLAGS: 00010002
RAX: 39df RBX: 0282 RCX: 0014
RDX: 1ddc00017654 RSI: e78092ef RDI: 8800b971aa10
RBP: 88041c57f700 R08: 88042ef17640 R09:
R10: 0005 R11: 04b7 R12:
R13: 8800b971aa10 R14: 88041aaaca80 R15:
FS: () GS:88042ef0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 1ddc00017654 CR3: 01c0c000 CR4: 001406e0
Stack:
88041c57f710 811726fd 88041c57f728 817a47e7
8800b971aa00 88041c57f760 a09e7655 0002
88041c6ab800 88041c6ab810 88041a1aaa80 a09ea000
Call Trace:
[] queued_spin_lock_slowpath+0xb/0xf
[] _raw_spin_lock_irqsave+0x37/0x40
[] usbrsa_attach+0x1b5/0x660 [usbrsa]
[] usb_
Re: Nokia N900: musb is in wrong state after boot
Pali Rohár writes: > On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote: >> * Pali Rohár [160126 06:35]: >> > On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote: >> > > * joerg Reisenweber [160121 11:35]: >> > > > On Thu 21 January 2016 11:21:13 Tony Lindgren wrote: >> > > > > Do you have some pointer >> > > > > to the "certain resistor value on ID to GND" spec? Is it >> > > > > maybe part of the carkit related parts of the USB spec? >> > > > >> > > > ""Three additional ID pin states are defined[4] at the nominal >> > > > resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect >> > > > to the ground pin. These permit the device to work with USB >> > > > Accessory Charger Adapters that allows the OTG device to be >> > > > attached to both a charger and another device simultaneously. >> > > > [6]"" >> > > > https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs >> > > >> > > OK thanks. So it's the "accessory charger" part of the >> > > battery charging specification 1.1. >> > >> > So, Tony, do you have some idea what needs to be changed and how to >> > fix peripheral mode after boot on Nokia N900? >> >> No, I'm waiting to hear an educated guess from Felipe on this one. about why peripheral mode doesn't work on n900 ? No idea. that's always the default role of MUSB and last I checked, before stopping working on this, BBB was working just fine. N900 is odd in that it has two PHYs (1701 handles data lines while twl4030 handles power lines, IIRC), but peripheral should be working. The only reason for MUSB to not start would be that it's not detecting VBUS being above session valid threshold, however twl4030 should have an IRQ for that. What happens when cable is attached ? Any IRQs anywhere firing ? -- balbi signature.asc Description: PGP signature
RE: [RESEND PATCH v6 07/10] usb: chipidea: otg: enable HNP polling support for gadget and host
Hi,
Jun Li writes:
>> > Li Jun writes:
>> > > Enable HNP polling support for chipidea gadget and allocate memory
>> > > for host request flag when otg fsm init.
>> > >
>> > > Acked-by: Peter Chen
>> > > Signed-off-by: Li Jun
>> >
>> > Why do you guys do this to me ? It's v6 and this thing still doesn't
>> > compile. Why even send stuff you haven't even compile tested Why ???
>>
>> I certainly tested my patch set on multiple i.MX6 platforms, so, the build
>> is ok in my side.
>>
>> >
>> > > ---
>> > > drivers/usb/chipidea/otg_fsm.c | 4
>> > > 1 file changed, 4 insertions(+)
>> > >
>> > > diff --git a/drivers/usb/chipidea/otg_fsm.c
>> > > b/drivers/usb/chipidea/otg_fsm.c index cb28e76..9a963a7 100644
>> > > --- a/drivers/usb/chipidea/otg_fsm.c
>> > > +++ b/drivers/usb/chipidea/otg_fsm.c
>> > > @@ -797,6 +797,10 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
>> > > ci->fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
>> > > ci->fsm.otg->state = OTG_STATE_UNDEFINED;
>> > > ci->fsm.ops = &ci_otg_ops;
>> > > +ci->gadget.hnp_polling_support = 1;
>> > > +ci->fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
>> > > +if (!ci->fsm.host_req_flag)
>> >
>> > the name of the flag is host_request_flag, not host_req_flag. Now, how
>> > can I be certain you really tested this at all ? I won't accept this
>> > without hard-proof of this really working.
>>
>> Nope, the flag is host_req_flag, not "host_request_flag" as you said, See
>> my patch 3/7:
>> [RESEND PATCH v6 03/10] usb: common: otg-fsm: add HNP polling support
>>
>> @@ -119,6 +131,8 @@ struct otg_fsm {
>> /* Current usb protocol used: 0:undefine; 1:host; 2:client */
>> int protocol;
>> struct mutex lock;
>> + u8 *host_req_flag;
>> + struct delayed_work hnp_polling_work;
>> };
>>
>>
>> >
>> > Sorry guys, but it's v6 of this patch series and we're still having
>> > build issues.
>> >
>>
>> I don't know why you has this build issue, I created my patchset against
>> Peter's chipidea tree(ci-for-usb-next branch). I will apply my patches to
>> your tree(testing_next) and try again.
>>
>
> Also NO build issue found with my patchset on your tree(testing/next
> branch).
no way, second time this happens. Just tried applying again and it's all
building fine. Sorry about that
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT
On Sun 21 Feb 22:02 PST 2016, Peter Chen wrote: > On Sun, Feb 21, 2016 at 09:32:13PM -0800, Bjorn Andersson wrote: > > On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set > > to be able to do DMA allocations, so use the of_dma_configure() helper > > to populate the dma properties and assign an appropriate dma_ops. > > > > Signed-off-by: Bjorn Andersson > > --- > > drivers/usb/chipidea/core.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > > index 7404064b9bbc..047b9d4e67aa 100644 > > --- a/drivers/usb/chipidea/core.c > > +++ b/drivers/usb/chipidea/core.c > > @@ -62,6 +62,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -834,6 +835,9 @@ struct platform_device *ci_hdrc_add_device(struct > > device *dev, > > pdev->dev.dma_parms = dev->dma_parms; > > dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask); > > > > + if (IS_ENABLED(CONFIG_OF) && dev->of_node) > > + of_dma_configure(&pdev->dev, dev->of_node); > > + > > ret = platform_device_add_resources(pdev, res, nres); > > if (ret) > > goto err; > > Just would like to confirm, it will not affect the default behavior > which the "dma-ranges" is not set at those platforms? > If I read the code correctly, the only difference if you don't specify dma-ranges, dma-coherent or specify an iommu is that the dma_ops gets assigned. Regards, Bjorn -- 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: chipidea: Configure DMA properties and ops from DT
On Sun, Feb 21, 2016 at 09:32:13PM -0800, Bjorn Andersson wrote: > On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set > to be able to do DMA allocations, so use the of_dma_configure() helper > to populate the dma properties and assign an appropriate dma_ops. > > Signed-off-by: Bjorn Andersson > --- > drivers/usb/chipidea/core.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > index 7404064b9bbc..047b9d4e67aa 100644 > --- a/drivers/usb/chipidea/core.c > +++ b/drivers/usb/chipidea/core.c > @@ -62,6 +62,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -834,6 +835,9 @@ struct platform_device *ci_hdrc_add_device(struct device > *dev, > pdev->dev.dma_parms = dev->dma_parms; > dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask); > > + if (IS_ENABLED(CONFIG_OF) && dev->of_node) > + of_dma_configure(&pdev->dev, dev->of_node); > + > ret = platform_device_add_resources(pdev, res, nres); > if (ret) > goto err; Just would like to confirm, it will not affect the default behavior which the "dma-ranges" is not set at those platforms? -- 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
[PATCH] usb: chipidea: Configure DMA properties and ops from DT
On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set to be able to do DMA allocations, so use the of_dma_configure() helper to populate the dma properties and assign an appropriate dma_ops. Signed-off-by: Bjorn Andersson --- drivers/usb/chipidea/core.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index 7404064b9bbc..047b9d4e67aa 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -62,6 +62,7 @@ #include #include #include +#include #include #include #include @@ -834,6 +835,9 @@ struct platform_device *ci_hdrc_add_device(struct device *dev, pdev->dev.dma_parms = dev->dma_parms; dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask); + if (IS_ENABLED(CONFIG_OF) && dev->of_node) + of_dma_configure(&pdev->dev, dev->of_node); + ret = platform_device_add_resources(pdev, res, nres); if (ret) goto err; -- 2.5.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/3] usb: core: Allow compilation on platforms where NO_DMA=y
On Sun, Feb 21, 2016 at 10:46:59PM +0100, Geert Uytterhoeven wrote: > Hi Greg, > > On Sun, Feb 21, 2016 at 5:23 AM, Greg Kroah-Hartman > wrote: > > On Tue, Feb 16, 2016 at 04:10:57PM +0100, Geert Uytterhoeven wrote: > >> Some platforms don't have DMA, but we should still be able to build USB > >> drivers for these platforms. They could still be used through vhci_hcd, > >> usbip_host, or maybe something like USB passthrough in UML from a > >> capable host. > >> > >> If NO_DMA=y: > >> > >> ERROR: "dma_pool_destroy" [drivers/usb/core/usbcore.ko] undefined! > >> ERROR: "bad_dma_ops" [drivers/usb/core/usbcore.ko] undefined! > >> ERROR: "dma_pool_free" [drivers/usb/core/usbcore.ko] undefined! > >> ERROR: "dma_pool_alloc" [drivers/usb/core/usbcore.ko] undefined! > >> ERROR: "dma_pool_create" [drivers/usb/core/usbcore.ko] undefined! > >> > >> Add a few checks for CONFIG_HAS_DMA to fix this. > >> > >> Signed-off-by: Geert Uytterhoeven > >> Acked-by: Vegard Nossum > >> --- > >> v2: > >> - Replace remaining #ifdefs by IS_ENABLED() checks, > >> - Add to patch description that this actually allows using USB on UML, > >> - Add Acked-by. > > > > This patch didn't apply to my tree, can you rebase it against usb-next > > of usb.git and resend? > > Are you sure it's this one that didn't apply? It's already in usb-testing? > > "[2/3] usb: host: Host drivers relying on DMA should depend on HAS_DMA" > doesn't apply, as your tree gained some HAS_IOMEM dependencies, so I'll > resend. Thanks, I think you were right. greg k-h -- 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: idmouse.c: Put the interface on error
usb_autopm_put_interface() should be called regardless of what idmouse_create_image() returns. Signed-off-by: Junjie Mao --- drivers/usb/misc/idmouse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/misc/idmouse.c b/drivers/usb/misc/idmouse.c index 4e38683c653c..5105397e62fc 100644 --- a/drivers/usb/misc/idmouse.c +++ b/drivers/usb/misc/idmouse.c @@ -257,9 +257,9 @@ static int idmouse_open(struct inode *inode, struct file *file) if (result) goto error; result = idmouse_create_image (dev); + usb_autopm_put_interface(interface); if (result) goto error; - usb_autopm_put_interface(interface); /* increment our usage count for the driver */ ++dev->open; -- 1.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 oops regression caused by -stable patch
Thanks for reporting, Tony. It was remiss of me.
There is another BOS free operation in label re_enumerate. This cause a
double-free of BOS.
USB2 doesn't have BOS desc, so you cannot reproduce it.
I am on a travel. It is appreciated if you can help try below fix.
Hi, Greg, I will commit a final patch once returned from travel.
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5501,8 +5501,10 @@ done:
return 0;
re_enumerate:
- usb_release_bos_descriptor(udev);
- udev->bos = bos;
+ if (udev->bos != bos) {
+ usb_release_bos_descriptor(udev);
+ udev->bos = bos;
+ }
Best Regards,
Du, Changbin
> On Fri, Feb 19, 2016 at 09:39:57AM -0500, Tony Battersby wrote:
> > This upstream commit is causing an oops:
> > d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device")
> >
> > This patch has already been included in several -stable kernels. Here
> > are the affected kernels:
> > 4.5.0-rc4 (current git)
> > 4.4.2
> > 4.3.6 (currently in review)
> > 4.1.18
> > 3.18.27
> > 3.14.61
> >
> > How to reproduce the problem:
> > Boot kernel with slub debugging enabled (otherwise memory corruption
> > will cause random oopses later instead of immediately)
> > Plug in USB 3.0 disk to xhci USB 3.0 port
> > dd if=/dev/sdc of=/dev/null bs=65536
> > (where /dev/sdc is the USB 3.0 disk)
> > Unplug USB cable while dd is still going
> > Oops is immediate:
>
> Not good, thanks for letting us know. I've now reverted this and will
> get the fix into 4.5-rc6.
>
> greg k-h
0001-usb-hub-fix-panic-in-usb_reset_and_verify_device.patch
Description: 0001-usb-hub-fix-panic-in-usb_reset_and_verify_device.patch
Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28
On Fri, Feb 19, 2016 at 11:05 PM, Fabio Estevam wrote: > On Fri, Feb 19, 2016 at 12:13 PM, Felipe Balbi wrote: > >> h, okay. So you have another problem, actually. Seems like ci_hdrc >> just shouldn't call your phy->suspend(), or your phy->suspend() >> shouldn't do anything. How about below? >> >> @@ -370,6 +370,9 @@ static int mxs_phy_suspend(struct usb_phy *x, int >> suspend) >> struct mxs_phy *mxs_phy = to_mxs_phy(x); >> bool low_speed_connection, vbus_is_on; >> >> + if (mxs_phy->data->flags & MXS_PHY_ABNORMAL_IN_SUSPEND) >> + return 0; /* or should we return -EBUSY ? */ >> + > > Tested with 0 and also -EBUSY. This code is called now, but it does > not fix the problem. Same log: > > [3.005881] hub 1-1:1.0: USB hub found > [3.010341] hub 1-1:1.0: 2 ports detected > [3.536362] usb 1-1: USB disconnect, device number 2 > [3.582732] usb usb1-port1: cannot reset (err = -32) > [3.588289] usb usb1-port1: cannot reset (err = -32) > [3.593546] usb usb1-port1: cannot reset (err = -32) > [3.598929] usb usb1-port1: cannot reset (err = -32) > [3.604188] usb usb1-port1: cannot reset (err = -32) > [3.609339] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? > -- Fabio, Felipe is correct. The mx23 and mx28 should NOT call mxs phy's suspend API since the runtime suspend is not enabled for mx23 and mx28 at chipidea driver. Would you please check if CI_HDRC_SUPPORTS_RUNTIME_PM is set wrongly for mx23/mx28 at ci_hdrc_imx.c? If it does not been set, would please add WARN_ON(1) at mxs_phy_suspend to show call stack? -- BR, 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
[PATCH 3/3] usb: musb: sunxi: support module autoloading
From: Emilio López
MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on
sunxi systems using the OTG controller. This commit adds the missing
line so it loads automatically when building it as a module and running
on a system with an USB OTG port.
Signed-off-by: Emilio López
---
drivers/usb/musb/sunxi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index d9b0dc4..fdab423 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -752,6 +752,7 @@ static const struct of_device_id sunxi_musb_match[] = {
{ .compatible = "allwinner,sun8i-a33-musb", },
{}
};
+MODULE_DEVICE_TABLE(of, sunxi_musb_match);
static struct platform_driver sunxi_musb_driver = {
.probe = sunxi_musb_probe,
--
2.7.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
[PATCH 2/3] dmaengine: sun4i: support module autoloading
From: Emilio López
MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on
supported systems. This commit adds the missing line so it loads
automatically when building it as a module and running on a system
with the early sunxi DMA engine.
Signed-off-by: Emilio López
---
drivers/dma/sun4i-dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/sun4i-dma.c b/drivers/dma/sun4i-dma.c
index 1661d518..e0df233 100644
--- a/drivers/dma/sun4i-dma.c
+++ b/drivers/dma/sun4i-dma.c
@@ -1271,6 +1271,7 @@ static const struct of_device_id sun4i_dma_match[] = {
{ .compatible = "allwinner,sun4i-a10-dma" },
{ /* sentinel */ },
};
+MODULE_DEVICE_TABLE(of, sun4i_dma_match);
static struct platform_driver sun4i_dma_driver = {
.probe = sun4i_dma_probe,
--
2.7.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
[PATCH 1/3] [media] rc: sunxi-cir: support module autoloading
From: Emilio López
MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on
systems supporting infrared. This commit adds the missing line so it
works out of the box when built as a module and running on a sunxi
system with an infrared receiver.
Signed-off-by: Emilio López
---
drivers/media/rc/sunxi-cir.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 40f7768..eaadc08 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -326,6 +326,7 @@ static const struct of_device_id sunxi_ir_match[] = {
{ .compatible = "allwinner,sun5i-a13-ir", },
{},
};
+MODULE_DEVICE_TABLE(of, sunxi_ir_match);
static struct platform_driver sunxi_ir_driver = {
.probe = sunxi_ir_probe,
--
2.7.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 v2 1/3] usb: core: Allow compilation on platforms where NO_DMA=y
Hi Greg,
On Sun, Feb 21, 2016 at 5:23 AM, Greg Kroah-Hartman
wrote:
> On Tue, Feb 16, 2016 at 04:10:57PM +0100, Geert Uytterhoeven wrote:
>> Some platforms don't have DMA, but we should still be able to build USB
>> drivers for these platforms. They could still be used through vhci_hcd,
>> usbip_host, or maybe something like USB passthrough in UML from a
>> capable host.
>>
>> If NO_DMA=y:
>>
>> ERROR: "dma_pool_destroy" [drivers/usb/core/usbcore.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/usb/core/usbcore.ko] undefined!
>> ERROR: "dma_pool_free" [drivers/usb/core/usbcore.ko] undefined!
>> ERROR: "dma_pool_alloc" [drivers/usb/core/usbcore.ko] undefined!
>> ERROR: "dma_pool_create" [drivers/usb/core/usbcore.ko] undefined!
>>
>> Add a few checks for CONFIG_HAS_DMA to fix this.
>>
>> Signed-off-by: Geert Uytterhoeven
>> Acked-by: Vegard Nossum
>> ---
>> v2:
>> - Replace remaining #ifdefs by IS_ENABLED() checks,
>> - Add to patch description that this actually allows using USB on UML,
>> - Add Acked-by.
>
> This patch didn't apply to my tree, can you rebase it against usb-next
> of usb.git and resend?
Are you sure it's this one that didn't apply? It's already in usb-testing?
"[2/3] usb: host: Host drivers relying on DMA should depend on HAS_DMA"
doesn't apply, as your tree gained some HAS_IOMEM dependencies, so I'll
resend.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v5] usb: devio: Add ioctl to disallow detaching kernel USB drivers.
From: Reilly Grant
The new USBDEVFS_DROP_PRIVILEGES ioctl allows a process to voluntarily
relinquish the ability to issue other ioctls that may interfere with
other processes and drivers that have claimed an interface on the
device.
This commit also includes a simple utility to be able to test the
ioctl, located at Documentation/usb/usbdevfs-drop-permissions.c
Example (with qemu-kvm's input device):
$ lsusb
...
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
$ usb-devices
...
C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=02 Driver=usbhid
$ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
OK: privileges dropped!
Available options:
[0] Exit now
[1] Reset device. Should fail if device is in use
[2] Claim 4 interfaces. Should succeed where not in use
[3] Narrow interface permission mask
Which option shall I run?: 1
ERROR: USBDEVFS_RESET failed! (1 - Operation not permitted)
Which test shall I run next?: 2
ERROR claiming if 0 (1 - Operation not permitted)
ERROR claiming if 1 (1 - Operation not permitted)
ERROR claiming if 2 (1 - Operation not permitted)
ERROR claiming if 3 (1 - Operation not permitted)
Which test shall I run next?: 0
After unbinding usbhid:
$ usb-devices
...
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=02 Driver=(none)
$ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
...
Which option shall I run?: 2
OK: claimed if 0
ERROR claiming if 1 (1 - Operation not permitted)
ERROR claiming if 2 (1 - Operation not permitted)
ERROR claiming if 3 (1 - Operation not permitted)
Which test shall I run next?: 1
OK: USBDEVFS_RESET succeeded
Which test shall I run next?: 0
After unbinding usbhid and restricting the mask:
$ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
...
Which option shall I run?: 3
Insert new mask: 0
OK: privileges dropped!
Which test shall I run next?: 2
ERROR claiming if 0 (1 - Operation not permitted)
ERROR claiming if 1 (1 - Operation not permitted)
ERROR claiming if 2 (1 - Operation not permitted)
ERROR claiming if 3 (1 - Operation not permitted)
Signed-off-by: Reilly Grant
Acked-by: Alan Stern
Signed-off-by: Emilio López
---
Changes in v5:
- rebased on usb-next, changing the capability flag value to not collide
- Added Alan's ack
Changes in v4:
- IOR -> IOW
- Explain the new ioctl on usb Docbook
- Small program to be able to test the new functionality
- New capability flag
- Allow people to reset devices if they are the only ones
claiming interfaces, as suggested by Alan
Changes in v3:
- Switch ioctl to use a __u32 given the iface qty is capped at 32
- Reword comments as requested by Alan
- Allow callers to shrink the allowed interfaces mask
Changes in v2:
- Added a parameter to the ioctl, a mask of interfaces an unprivileged
process is allowed to claim.
- Drop Tested-by's
Documentation/DocBook/usb.tmpl| 12 +++
Documentation/usb/usbdevfs-drop-permissions.c | 120 ++
drivers/usb/core/devio.c | 63 --
include/uapi/linux/usbdevice_fs.h | 2 +
4 files changed, 192 insertions(+), 5 deletions(-)
create mode 100644 Documentation/usb/usbdevfs-drop-permissions.c
diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl
index 4cd5b2c..bc776be0 100644
--- a/Documentation/DocBook/usb.tmpl
+++ b/Documentation/DocBook/usb.tmpl
@@ -732,6 +732,18 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void
*param)
or SET_INTERFACE.
+ USBDEVFS_DROP_PRIVILEGES
+ This is used to relinquish the ability
+ to do certain operations which are considered to be
+ privileged on a usbfs file descriptor.
+ This includes claiming arbitrary interfaces, resetting
+ a device on which there are currently claimed interfaces
+ from other users, and issuing USBDEVFS_IOCTL calls.
+ The ioctl parameter is a 32 bit mask of interfaces
+ the user is allowed to claim on this file descriptor.
+ You may issue this ioctl more than one time to narrow
+ said mask.
+
diff --git a/Documentation/usb/usbdevfs-drop-permissions.c
b/Documentation/usb/usbdevfs-drop-permissions.c
new file mode 100644
index 000..6b8da6e
--- /dev/null
+++ b/Documentation/usb/usbdevfs-drop-permissions.c
@@ -0,0 +1,120 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* For building without an updated set of headers */
+#ifndef USBDEVFS_DROP_PRIVILEGES
+#define USBDEVFS_DROP_PRIVILEGES _IOW('U', 30,
Re: [PATCH] Support HP lt4114 LTE Module (Huawei ME206V-561)
On 2016-02-20 03:34, Dan Williams wrote: On Fri, 2016-02-19 at 18:21 +0100, Bjørn Mork wrote: Dan Williams writes: On Fri, 2016-02-19 at 21:20 +0700, Lars Melin wrote: cfg #1 MI_00 HP Mobile Connect - PC UI Interface MI_01 HP Mobile Connect - Application Interface MI_02 HP Mobile Connect - Modem MI_03 HP Mobile Connect - Network Card (jungo ncm) MI_04 HP Mobile Connect - GPS Interface cfg#2 MI_00 HP Mobile Connect - Network Card (cdc_ether) MI_02 HP Mobile Connect - Modem MI_03 HP Mobile Connect - Application Interface MI_04 HP Mobile Connect - PC UI Interface MI_05 HP Mobile Connect - GPS Interface cfg#3 MI_00 HP Mobile Connect - Network Card (cdc_mbim) MI_02 HP Mobile Connect - GPS Interface Bjorn, with these devices that technically "support" a bunch of different modes, what should our advice be on mode select? Personally I'd love to switch modems that support MBIM into MBIM by default... Yup, me too. That is the configuration with a class driver and standardized management, allowing it to work without any device or vendor specific support. It is also the configuration used by current Windows versions and therefore most likely tested. I don't think such a policy is suitable for the kernel, though. In fact, I don't think the current kernel policy is appropriate for the kernel either :) But we'll have to leave that as it is. Do you think it is possible to create a catch-all udev rule preferring MBIM? I guess we'll need some helper for that, since it means making a choice based on the attributes of an inactive configuration. usb_modeswitch would be the most logical helper. Dan usb_modeswitch does already handle one module under Huawei's own id so it should also be able to switch the HP branded ones. There are more HP branded modules which we may see in the future and I'll make sure that they will be added to usb_modeswitch as soon as I know their interface layout. HP's own drivers tells what kind of interfaces are available but not in which config they are present or in which order within a config. There is at least some useful info in them about baseline drivers: Remark="HP"/> Remark="HP"/> Remark="HP"/> which makes me think that lt4114 should not be in qcserial but in option instead. -- 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: Nokia N900: musb is in wrong state after boot
On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote: > * Pali Rohár [160126 06:35]: > > On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote: > > > * joerg Reisenweber [160121 11:35]: > > > > On Thu 21 January 2016 11:21:13 Tony Lindgren wrote: > > > > > Do you have some pointer > > > > > to the "certain resistor value on ID to GND" spec? Is it > > > > > maybe part of the carkit related parts of the USB spec? > > > > > > > > ""Three additional ID pin states are defined[4] at the nominal > > > > resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect > > > > to the ground pin. These permit the device to work with USB > > > > Accessory Charger Adapters that allows the OTG device to be > > > > attached to both a charger and another device simultaneously. > > > > [6]"" > > > > https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs > > > > > > OK thanks. So it's the "accessory charger" part of the > > > battery charging specification 1.1. > > > > So, Tony, do you have some idea what needs to be changed and how to > > fix peripheral mode after boot on Nokia N900? > > No, I'm waiting to hear an educated guess from Felipe on this one. PING! Still no answer. Felipe changed email address. > > First I would like to have fully working peripheral mode on Nokia > > N900 and then we can try to hack host mode (if possible). > > > > But peripheral mode is a must due to development, because it > > provides usb network or usb tty. > > Totally. > > Regards, > > Tony -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
