Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
On Sat, Nov 29, 2014 at 4:35 PM, Felipe Balbi wrote: > Hi, > > On Fri, Nov 28, 2014 at 11:35:53AM +0100, Yegor Yefremov wrote: >> On Wed, Nov 19, 2014 at 6:53 PM, Tony Lindgren wrote: >> > * Enric Balletbo Serra [141119 03:14]: >> >> 2014-11-18 16:42 GMT+01:00 Tony Lindgren : >> >> >> >> Checked again, and no luck. It's very weird because from the OTG point >> >> of view, OTG is exactly the same between Beagleboard-XM and IGEPv2. >> >> >> >> Can you confirm that you're using kernel 3.18-rc5 without other >> >> patches applied ? At this moment, I don't have a Beagleboard-XM to >> >> test, I'll try to get one because at this moment I'm a bit stuck with >> >> this problem. >> > >> > Yes it was with v3.18-rc5 and the defconfig patch I posted except >> > I had to disable all the other MUSB platforms. Also tested it with >> > built in modules. >> > >> > Maybe you need to check the .dts pinctrl entries for hsusb0_* lines? >> >> Just my 2 cents, My am335x based board shows similar symptoms >> (CONFIG_USB_MUSB_DUAL_ROLE enabled). Only if I specify dr_mode = >> "host"; in my DTS I get device enumerated. 3.15, that I had before >> made no problems as OTG. > > Are you sure your ID pin is properly routed ? If you set dr_mode to otg, > then you *must* have a properly routed ID pin and use a proper > micro-/mini-ab receptacle. That's not true for e.g. beagle bone black. > > One USB port is using a Standard-A while the other uses mini-B. You > can't do any role swapping with those. Yes, I'm sure, that ID pin is routed properly. It is also not BBB, but real device Baltos iR 5221 (http://visionsystems.de/produkte/baltos-ir-5221.html). With 3.15 I'm able to use OTG port both as device and host. I boot the device, insert FTDI based hardware into OTG port and my ttyUSBx devices, then disconnect and connect to PC and I get usb0 network interface and can communicate with PC. Yegor -- 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: Is this 32-bit NCM?
I'm sorry. According to the wireshark capture, those packets without NCM signature are probably some periodical status checking interrupts. And some other packets in the same capture do show the NCM signature. Those packets are ping packets. Regarding the offset and alignment definition, the specification says as below: Alignment requirements are met by controlling the location of the payload (the data following the Ether- net header in each datagram). This alignment is specified by indicating a constraint as a divisor and a remainder. The agent formatting a given NTB aligns the payload of each datagram by inserting padding, such that the offset of each datagram satisfies the constraint: Offset % wNdpInDivisor == wNdpInPayloadRemainder (for IN datagrams) Or Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams) Regards, Kevin On 12/01/2014 01:28 PM, Enrico Mioso wrote: > Sorry. > I am a visually impaired person - and use a braille display to read your > messages; can't have access to files that don't contain ascii-based content. > Sorry Kevin. > > And thank you for everything. Don't worry about the lateness. > It was sunday. > > > On Mon, 1 Dec 2014, Kevin Zhu wrote: > > ==Date: Mon, 1 Dec 2014 04:14:10 > ==From: Kevin Zhu > ==To: Enrico Mioso , Alex Strizhevsky > ==Cc: Eli Britstein , > =="linux-usb@vger.kernel.org" , > =="you...@gmail.com" , > ==Midge Shaojun Tan , > =="net...@vger.kernel.org" , > ==Bjørn Mork > ==Subject: Re: Is this 32-bit NCM? > == > ==Hi Enrico, > == > ==I think those packets are some interrupt status. Please check my capture by > ==wireshark. > == > ==[IMAGE] > == > ==And this is a ping packet from window, which indicates it's an NCM packet. > == > ==[IMAGE] > == > ==Regards, > ==Kevin > ==On 11/30/2014 06:39 PM, Enrico Mioso wrote: > == > ==My impression guys is that this is not cdc_ncm protocol. > ==Look how many short packets you can see in there. > ==Without any ncm signature. > ==right? > == > == > ==On Sun, 30 Nov 2014, Alex Strizhevsky wrote: > == > Date: Sun, 30 Nov 2014 05:22:20 > From: Alex Strizhevsky > To: Mrkiko Rs > Cc: Eli Britstein , linux-...@vger.kernel.or > ==g, > "you...@gmail.com" , > Midge Shaojun Tan , > "net...@vger.kernel.org" , > Kevin Zhu , Bjørn Mork > Subject: Re: Is this 32-bit NCM? > > > Hi Enrico, > > Actually I have two dongles with different firmwares (23.128.00.00.00 & > 21.286.03.01.209). > Probably have sent to you the USB capture with the first one. > > In fact we have to make work the second one, this dongle has relevant SW. > > On Nov 30, 2014 3:13 AM, "Enrico Mioso" wrote: > Hi guys. > Sorry for the late our but ... I was trying to figure out > something new about > this dongle. > I also searched for it in my city shops without finding it > actually. > But then I came back and ... tried to look at some things. > > Alex, Kevin: in the Windows USB captures you sent me (and that I > sent on the > List), I can notiche something very strange. > with a shell on a computer connected to a test device I can see > the following: > at+gmr > 21.286.03.01.209 > OK > and so why in the Windows sniff the dongle answers to the same > question > something like > 23.128.00.00.00 > ? > Alex - was it the same dongle? > Kevin or anyone: can you use putty to interact with the dongle > under Windows > and type some commands, like: > at+gmr > and other similar commands? > If the dongle reports different firmware versions under Linux > and Windows, then > guys... we need to figure out the Windows switch message. > Overmore - in the device installation sh*t, you can see there is > a firmware > updater... Why? > > Alex: I used the > at^reset > command to get the modem back to normal state once; and so it > restored the > nvram to default or something. > If you reconnect it to windows ... i hope it gets re-setup as > before. > But - nothing harmful to the device, only to it's settings, > sorry. > I restored the relevant settings and it connects again, but no > dhcp. But - be > peaceful: other modems out there seems to not get dhcp anyway. > this is the state the modem arrives when you buy it, so windows > should know > Wwhat To Say To The Modem (TM). > Another thing - note that: > [14170.048693] cdc_ncm 1-2:1.2: GET_MAX_DATAGRAM_SIZE failed > > Any ideas, comments, suggestions are highly appreciated guys. >
Re: [PATCH v3 3/3] usb: phy: hold wakeupsource when USB is enumerated in peripheral mode
Hi Felipe, On 25 November 2014 at 20:15, Felipe Balbi wrote: > On Tue, Nov 25, 2014 at 07:06:18AM +, Peter Chen wrote: >> >> > >> > usb: phy: hold wakeupsource when USB is enumerated in peripheral mode >> > >> > Some systems require a mechanism to prevent system to enter into suspend >> > state when USB is connected and enumerated in peripheral mode. >> > >> > This patch provides an interface to hold a wakeupsource to prevent suspend. >> > PHY drivers can use this interface when USB is connected and enumerated in >> > peripheral mode. >> > >> > A timed wakeupsource is temporarily held on USB disconnect events, to allow >> > the rest of the system to react to the USB disconnection (dropping host >> > sessions, updating charger status, etc.) prior to re-allowing suspend. >> > >> >> Hi Kiran & Felipe, >> >> Just two questions for this series >> >> - Will it be the default behavior for all peripheral drivers? >> - If the peripheral driver's PHY driver does not vbus event, how to >> support it? >> For example, chipidea udc driver has its vbus interface at its >> controller register. > > hmm, good point. Since it's so late, I'll just go ahead and drop > $subject from v3.20. Let's delay only $subject to v3.20 merge window so > we have some more time to discuss these details. I am just curious to know/understand why this feature needs to be default behavior for all peripheral drivers? If this needs to be default behavior, could you please suggest any alternate plan/design for this feature so that i can incorporate them in new patch. Regards, Kiran > > cheers > > -- > balbi -- 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: Is this 32-bit NCM?
Sorry. I am a visually impaired person - and use a braille display to read your messages; can't have access to files that don't contain ascii-based content. Sorry Kevin. And thank you for everything. Don't worry about the lateness. It was sunday. On Mon, 1 Dec 2014, Kevin Zhu wrote: ==Date: Mon, 1 Dec 2014 04:14:10 ==From: Kevin Zhu ==To: Enrico Mioso , Alex Strizhevsky ==Cc: Eli Britstein , =="linux-usb@vger.kernel.org" , =="you...@gmail.com" , ==Midge Shaojun Tan , =="net...@vger.kernel.org" , ==Bjørn Mork ==Subject: Re: Is this 32-bit NCM? == ==Hi Enrico, == ==I think those packets are some interrupt status. Please check my capture by ==wireshark. == ==[IMAGE] == ==And this is a ping packet from window, which indicates it's an NCM packet. == ==[IMAGE] == ==Regards, ==Kevin ==On 11/30/2014 06:39 PM, Enrico Mioso wrote: == ==My impression guys is that this is not cdc_ncm protocol. ==Look how many short packets you can see in there. ==Without any ncm signature. ==right? == == ==On Sun, 30 Nov 2014, Alex Strizhevsky wrote: == Date: Sun, 30 Nov 2014 05:22:20 From: Alex Strizhevsky To: Mrkiko Rs Cc: Eli Britstein , linux-...@vger.kernel.or ==g, "you...@gmail.com" , Midge Shaojun Tan , "net...@vger.kernel.org" , Kevin Zhu , Bjørn Mork Subject: Re: Is this 32-bit NCM? Hi Enrico, Actually I have two dongles with different firmwares (23.128.00.00.00 & 21.286.03.01.209). Probably have sent to you the USB capture with the first one. In fact we have to make work the second one, this dongle has relevant SW. On Nov 30, 2014 3:13 AM, "Enrico Mioso" wrote: Hi guys. Sorry for the late our but ... I was trying to figure out something new about this dongle. I also searched for it in my city shops without finding it actually. But then I came back and ... tried to look at some things. Alex, Kevin: in the Windows USB captures you sent me (and that I sent on the List), I can notiche something very strange. with a shell on a computer connected to a test device I can see the following: at+gmr 21.286.03.01.209 OK and so why in the Windows sniff the dongle answers to the same question something like 23.128.00.00.00 ? Alex - was it the same dongle? Kevin or anyone: can you use putty to interact with the dongle under Windows and type some commands, like: at+gmr and other similar commands? If the dongle reports different firmware versions under Linux and Windows, then guys... we need to figure out the Windows switch message. Overmore - in the device installation sh*t, you can see there is a firmware updater... Why? Alex: I used the at^reset command to get the modem back to normal state once; and so it restored the nvram to default or something. If you reconnect it to windows ... i hope it gets re-setup as before. But - nothing harmful to the device, only to it's settings, sorry. I restored the relevant settings and it connects again, but no dhcp. But - be peaceful: other modems out there seems to not get dhcp anyway. this is the state the modem arrives when you buy it, so windows should know Wwhat To Say To The Modem (TM). Another thing - note that: [14170.048693] cdc_ncm 1-2:1.2: GET_MAX_DATAGRAM_SIZE failed Any ideas, comments, suggestions are highly appreciated guys. Of any type. Bjorn - unfortunately it seems this problem is related to E3727 and E3276 sticks; they can get IP from DHCP but not go ahead. == == ==This email and any files transmitted with it are confidential material. They ==are intended solely for the use of the designated individual or entity to ==whom they are addressed. If the reader of this message is not the intended ==recipient, you are hereby notified that any dissemination, use, distribution ==or copying of this communication is strictly prohibited and may be unlawful. == ==If you have received this email in error please immediately notify the ==sender and delete or destroy any copy of this message ==
Re: [PATCH v1] usb: phy: generic: migrate to gpio_desc
On Mon, Dec 1, 2014 at 5:32 AM, Robert Jarzmik wrote:
> Linus Walleij writes:
>
>> This definately make things better so:
>> Acked-by: Linus Walleij
> Thanks.
>
>> One comment though:
>>
if (dev->of_node) {
>> (...)
+ nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios");
+ err = PTR_ERR(nop->gpiod_reset);
} else if (pdata) {
>> (...)
+ err = devm_gpio_request_one(dev, pdata->gpio_reset, 0,
+ dev_name(dev));
+ if (!err)
+ nop->gpiod_reset = gpio_to_desc(pdata->gpio_reset);
+ }
>
>> So a next step would be to add support for getting the
>> devm_gpiod_get(dev, "reset-gpios"); outside of the if (dev->of_node)
>> clause, and possibly convert the board files for affected
>> platforms to use descriptors, if they will not be replaced by
>> device tree only.
>
> OK, if we were to do this, is there a way to build a static platform data
> with a
> gpio descriptor ?
> Ie. can I write something like :
> struct generic_phy_pdata {
> struct gpio_desc *reset_gpio;
> };
>
> And in machine code :
> static struct generic_phy_pdata usb_phy __initdata {
>.reset_gpio = XXX(19),
> };
>
> What should "XXX" be like to describe reset_gpio as a ACTIVE_HIGH gpio number
> 19
> ?
I think what you want to do is explained in the "Platform Data"
section of Documentation/gpio/board.txt
--
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: [Update 2x][PATCH] USB / PM: Drop CONFIG_PM_RUNTIME from the USB core
On Mon, Dec 01, 2014 at 02:12:51AM +0100, Rafael J. Wysocki wrote: > On Sunday, November 30, 2014 10:45:39 AM Alan Stern wrote: > > On Sat, 29 Nov 2014, Rafael J. Wysocki wrote: > > > > > From: Rafael J. Wysocki > > > > > > After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is > > > selected) PM_RUNTIME is always set if PM is set, so quite a few > > > #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to > > > depend on CONFIG_PM (or even dropped in some cases). > > > > > > Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code > > > and documentation. > > > > > > Signed-off-by: Rafael J. Wysocki > > > --- > > > > > > Added the Documentation/usb/power-management.txt changes. > > > > > > Of course, this depends on commit b2b49ccbdd54 (PM: Kconfig: Set > > > PM_RUNTIME > > > if PM_SLEEP is selected) which is in linux-next only (via linux-pm) at the > > > moment. > > > > Acked-by: Alan Stern > > Thanks! > > Greg, would there be any problems if I took this into the linux-pm tree? No problems at all: Acked-by: Greg Kroah-Hartman -- 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: Is this 32-bit NCM?
Hi, My dongle firmware version is 21.286.03.01.209, not working either. Regards, Kevin On 11/30/2014 06:18 PM, Enrico Mioso wrote: > Sorry - by error I did not send the message to all. > Hi everyone, and good Sunday! > The problem is that - between those two firmwares things might change, and so > we don't know what Windows does when it meets this specific branch /version of > the firmware. > I am desperately suspecting that we would not get anything hinting a lot even > looking at the usb capture of this specific firmware, but... in any case it > might be interesting to have it. > (at+gmr returns the firmware revision) > Is the dongles with 23 firmwares working under Linux? > Or, you might upgrade all dongles firmware until all of then are running the > 23 > version and so workaround the problem differently in case. > Bjorn: I noticed that anyway, as Alex suggested, tcpdump can reveal some > traffic: in particular you can see the gateway asking for us ... but no > traffic can flow out, only flow in. > The system can see traffic coming in, not generate it. Any idea or comment > from anyone is welcome. This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message -- 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: Is this 32-bit NCM?
Sorry for the late reply. I tried to calculate the offset as what windows did, but it did not help. Regards, Kevin On 12/01/2014 02:36 AM, Enrico Mioso wrote: > Thank you Bjorn for the help and suggestions. > These are parameters that the driver ends up choosing: > /sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0003 > /sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:131072 > /sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:16384 > /sys/class/net/wwan0/cdc_ncm/min_tx_pkt:14848 > /sys/class/net/wwan0/cdc_ncm/rx_max:16384 > /sys/class/net/wwan0/cdc_ncm/tx_max:16384 > /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400 > /sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4 > /sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:4 > /sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:2 > /sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4 > /sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:4 > /sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:2 > /sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:0 > > Sorry if I did not report them before. If I missed someone in CC please add it > guys. > Kevin - after you discovered that the device might handle the offset in a > different way, have you tried this approach? > > > On Thu, 27 Nov 2014, Bjørn Mork wrote: > > ==Date: Thu, 27 Nov 2014 11:03:24 > ==From: Bjørn Mork > ==To: Enrico Mioso > ==Cc: you...@gmail.com, alex...@gmail.com, linux-usb@vger.kernel.org, > ==net...@vger.kernel.org > ==Subject: Re: Is this 32-bit NCM? > == > ==Enrico Mioso writes: > == > ==> Ok - we can arrive to some ocnclusions regarding the E3272. > ==> First of all - the modem seems buggy enough to not be able to handle > requests > ==> for different formats. You need to unplug and re-plug it, but this is > onlyan > ==> impression and is reasonable. > ==> > ==> Then - the modem will accept to ndisdup the connection with > ==> at^ndisdup=1,1,"internet" > ==> but - if we use huawei_cdc_ncm + cdc_ncm we have no flow handling > messages and > ==> the modem stops here. > ==> If we use the cdc_ncm 32-bit driver (modified) we get lotfs of > ==> ^dsflorpt > ==> that's how it should be. > ==> So I think we can say that something is changing. > ==> Then there's the alignment problem you mentioned in your previous reply. > And > ==> this is hard to solve. > ==> could you try to help me understand where the problem is? > ==> I feel like we are very close to the solution but something isn't working. > ==> Or might be just try to change the 16 bit driver? > == > ==If you use a recent version of the driver as a basis, then you get the > ==CDC NCM NTB parameters in sysfs (if not, then you need to enable > ==debugging and look in the log for these values). For example: > == > ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/* > ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001 > ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360 > ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360 > ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824 > ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360 > ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360 > ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400 > ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4 > ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1 > ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0 > ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4 > ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32 > ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0 > ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32 > == > == > ==The possible problem I am thinking of is proper handling of the > ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet Frame > ==Alignment" in the spec. Which is confusing as hell, but if I understand > ==it correctly then we are supposed to align the start of the IP packets > ==(the "payload", _not_ the ethernet frame) to a whole wNdp*Divisor number > ==as long as the wNdp*PayloadRemainder is 0. > == > == > ==Bjørn > == This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message -- 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: [Update 2x][PATCH] USB / PM: Drop CONFIG_PM_RUNTIME from the USB core
On Sunday, November 30, 2014 10:45:39 AM Alan Stern wrote: > On Sat, 29 Nov 2014, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is > > selected) PM_RUNTIME is always set if PM is set, so quite a few > > #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to > > depend on CONFIG_PM (or even dropped in some cases). > > > > Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code > > and documentation. > > > > Signed-off-by: Rafael J. Wysocki > > --- > > > > Added the Documentation/usb/power-management.txt changes. > > > > Of course, this depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME > > if PM_SLEEP is selected) which is in linux-next only (via linux-pm) at the > > moment. > > Acked-by: Alan Stern Thanks! Greg, would there be any problems if I took this into the linux-pm tree? Rafael -- 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: [GIT PULL] USB driver fixes for 3.18-rc7
Linus Torvalds wrote: > I seem to get this problem possibly more commonly at boot these days: > usb 1-6: device descriptor read/64, error -71 > xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. > usb 1-6: hub failed to enable device, error -22 Since my upgrade to 98e8d2e0 from something a bit older I also get -71 error messages on boot and on resume, however this is older hardware with only ehci-pci. In my case some of the descriptors coming back from the device are bogus when the device is first seen. The device then disconnects, and when it is seen again by the kernel, nearly one second later, the descriptors are fine and there are no errors. vid/pid change from hardware ODM to OEM, suggesting that my device simply isn't ready when Linux first talks with it. //Peter -- 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/3] usb: phy: add lubbock phy driver
Dmitry Eremin-Solenikov writes:
> Extract lubbock-specific code from pxa25x_udc driver. As a bonus, phy
> driver determines connector/VBUS status by reading CPLD register. Also
> it uses a work to call into udc stack, instead of pinging vbus session
> right from irq handler.
This comment is not accurate anymore, right ? The work call, etc ...
Moreover, I have this compile error:
drivers/built-in.o: In function `lubbock_vbus_remove':
/home/rj/mio_linux/kernel/drivers/usb/phy/phy-lubbock.c:200: undefined
reference to `usb_remove_phy'
drivers/built-in.o: In function `lubbock_vbus_probe':
/home/rj/mio_linux/kernel/drivers/usb/phy/phy-lubbock.c:186: undefined
reference to `usb_add_phy'
Makefile:922: recipe for target 'vmlinux' failed
A select in Kconfig is missing, right ?
And then :
genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 294
lubbock-vbus lubbock-vbus: can't request irq 294, err: -22
lubbock-vbus: probe of lubbock-vbus failed with error -22
> +static int is_vbus_powered(void)
> +{
> + return !(LUB_MISC_RD && BIT(9));
That BIT(9) is a bit ugly. Moreover the "&&" is certainly wrong.
A define somewhere would be fine.
> +}
> +
> +static void lubbock_vbus_handle(struct lubbock_vbus_data *lubbock_vbus)
I have not reviewed that one thoroughly ...
> +
> +/* VBUS change IRQ handler */
> +static irqreturn_t lubbock_vbus_irq(int irq, void *data)
> +{
> + struct platform_device *pdev = data;
> + struct lubbock_vbus_data *lubbock_vbus = platform_get_drvdata(pdev);
> + struct usb_otg *otg = lubbock_vbus->phy.otg;
> +
> + dev_dbg(&pdev->dev, "VBUS %s (gadget: %s)\n",
> + is_vbus_powered() ? "supplied" : "inactive",
> + otg->gadget ? otg->gadget->name : "none");
> +
> + switch (irq) {
> + case LUBBOCK_USB_IRQ:
> + disable_irq(LUBBOCK_USB_IRQ);
> + enable_irq(LUBBOCK_USB_DISC_IRQ);
> + break;
> + case LUBBOCK_USB_DISC_IRQ:
> + disable_irq(LUBBOCK_USB_DISC_IRQ);
> + enable_irq(LUBBOCK_USB_IRQ);
> + break;
> + default:
> + return IRQ_NONE;
> + }
> +
> + /*
> + * No need to use workqueue here - we are in a threded handler,
> + * so we can sleep.
> + */
What if a new interrupt occurs in here, and preempts this thread.
> + if (otg->gadget)
> + lubbock_vbus_handle(lubbock_vbus);
I think the enable_irq() call should be here. I can't have an ordering problem
at this point, right ?
> + err = devm_request_threaded_irq(&pdev->dev, LUBBOCK_USB_DISC_IRQ,
> + NULL, lubbock_vbus_irq, 0, "vbus disconnect", pdev);
> + if (err) {
> + dev_err(&pdev->dev, "can't request irq %i, err: %d\n",
> + LUBBOCK_USB_DISC_IRQ, err);
> + return err;
> + }
> +
> + err = devm_request_threaded_irq(&pdev->dev, LUBBOCK_USB_IRQ,
> + NULL, lubbock_vbus_irq, 0, "vbus connect", pdev);
> + if (err) {
> + dev_err(&pdev->dev, "can't request irq %i, err: %d\n",
> + LUBBOCK_USB_IRQ, err);
> + return err;
> + }
Here you have both interrupts enabled, this will mean one interrupt at least
will fire. And of course the other one will be enabled a second time, hence
imbalance.
If you want to have an initial status of disconnected gadget, just enable ti
connect interrupt at probing.
Cheers.
--
Robert
--
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 v1] usb: phy: generic: migrate to gpio_desc
Linus Walleij writes:
> This definately make things better so:
> Acked-by: Linus Walleij
Thanks.
> One comment though:
>
>>> if (dev->of_node) {
> (...)
>>> + nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios");
>>> + err = PTR_ERR(nop->gpiod_reset);
>>> } else if (pdata) {
> (...)
>>> + err = devm_gpio_request_one(dev, pdata->gpio_reset, 0,
>>> + dev_name(dev));
>>> + if (!err)
>>> + nop->gpiod_reset = gpio_to_desc(pdata->gpio_reset);
>>> + }
> So a next step would be to add support for getting the
> devm_gpiod_get(dev, "reset-gpios"); outside of the if (dev->of_node)
> clause, and possibly convert the board files for affected
> platforms to use descriptors, if they will not be replaced by
> device tree only.
OK, if we were to do this, is there a way to build a static platform data with a
gpio descriptor ?
Ie. can I write something like :
struct generic_phy_pdata {
struct gpio_desc *reset_gpio;
};
And in machine code :
static struct generic_phy_pdata usb_phy __initdata {
.reset_gpio = XXX(19),
};
What should "XXX" be like to describe reset_gpio as a ACTIVE_HIGH gpio number 19
?
Cheers.
--
Robert
--
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: [GIT PULL] USB driver fixes for 3.18-rc7
Hmm, Greg. I seem to get this problem possibly more commonly at boot these days: usb 1-6: new full-speed USB device number 2 using xhci_hcd usb 1-6: device descriptor read/64, error -71 xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. usb 1-6: hub failed to enable device, error -22 usb 1-6: new full-speed USB device number 3 using xhci_hcd usb 1-6: device descriptor read/64, error -71 usb 1-6: hub failed to enable device, error -22 usb 1-6: new full-speed USB device number 4 using xhci_hcd usb 1-6: Device not responding to setup address. usb 1-6: Device not responding to setup address. usb 1-6: device not accepting address 4, error -71 usb 1-6: new full-speed USB device number 5 using xhci_hcd usb 1-6: Device not responding to setup address. usb 1-6: Device not responding to setup address. usb 1-6: device not accepting address 5, error -71 usb usb1-port6: unable to enumerate USB device and my keyboard doesn't work. I then unplug and re-plug it, and get usb 1-6: new full-speed USB device number 9 using xhci_hcd usb 1-6: New USB device found, idVendor=2516, idProduct=0020 usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-6: Product: Quickfire Rapid i usb 1-6: Manufacturer: CM Storm Any ideas? Some setup delay that isn't long enough at boot time for a slightly finicky device? It has happened before, but now I've gotten it twice within a couple of days: Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 (I've had this keyboard since mid-September, and looking at the logs this machine has been rebooted 41 times since, with those three failures..) Linus -- 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
[no subject]
[1.] One line summary of the problem:
[Lenovo G505s] External USB3 drive not accessible via USB 3.0 port
[2.] Full description of the problem/report:
When external USB HD is plugged into the USB3 port on the laptop, it
is not seen by the machine. It is seen when plugged into a USB2 port.
[3.] Keywords (i.e., modules, networking, kernel):
[4.] Kernel version (from /proc/version):
Linux version 3.18.0-031800rc4-generic (apw@gomeisa) (gcc version
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201411091835 SMP Sun Nov 9
23:36:36 UTC 2014
[5.] Output of Oops.. message (if applicable) with symbolic
information resolved (see Documentation/oops-tracing.txt)
n/a
[6.] A small shell script or example program which triggers the
problem (if possible)
Probably not relevant
[7.] Environment
Description:Ubuntu 14.10
Release: 14.10
[7.1.] Software (add the output of the ver_linux script here)
Cannot find entry for version 3.18, despite what output from /proc/version says.
[7.2.] Processor information (from /proc/cpuinfo):
See above
[7.3.] Module information (from /proc/modules):
See above
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
See above
[7.5.] PCI information ('lspci -vvv' as root)
See above
[7.6.] SCSI information (from /proc/scsi/scsi)
See above
[7.7.] Other information that might be relevant to the problem (please
look in /proc and include all information that you think to be
relevant):
See above
[X.] Other notes, patches, fixes, workarounds:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1390772
--
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: Is this 32-bit NCM?
Thank you Bjorn for the help and suggestions. These are parameters that the driver ends up choosing: /sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0003 /sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:131072 /sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:16384 /sys/class/net/wwan0/cdc_ncm/min_tx_pkt:14848 /sys/class/net/wwan0/cdc_ncm/rx_max:16384 /sys/class/net/wwan0/cdc_ncm/tx_max:16384 /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400 /sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4 /sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:4 /sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:2 /sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4 /sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:4 /sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:2 /sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:0 Sorry if I did not report them before. If I missed someone in CC please add it guys. Kevin - after you discovered that the device might handle the offset in a different way, have you tried this approach? On Thu, 27 Nov 2014, Bjørn Mork wrote: ==Date: Thu, 27 Nov 2014 11:03:24 ==From: Bjørn Mork ==To: Enrico Mioso ==Cc: you...@gmail.com, alex...@gmail.com, linux-usb@vger.kernel.org, ==net...@vger.kernel.org ==Subject: Re: Is this 32-bit NCM? == ==Enrico Mioso writes: == ==> Ok - we can arrive to some ocnclusions regarding the E3272. ==> First of all - the modem seems buggy enough to not be able to handle requests ==> for different formats. You need to unplug and re-plug it, but this is onlyan ==> impression and is reasonable. ==> ==> Then - the modem will accept to ndisdup the connection with ==> at^ndisdup=1,1,"internet" ==> but - if we use huawei_cdc_ncm + cdc_ncm we have no flow handling messages and ==> the modem stops here. ==> If we use the cdc_ncm 32-bit driver (modified) we get lotfs of ==> ^dsflorpt ==> that's how it should be. ==> So I think we can say that something is changing. ==> Then there's the alignment problem you mentioned in your previous reply. And ==> this is hard to solve. ==> could you try to help me understand where the problem is? ==> I feel like we are very close to the solution but something isn't working. ==> Or might be just try to change the 16 bit driver? == ==If you use a recent version of the driver as a basis, then you get the ==CDC NCM NTB parameters in sysfs (if not, then you need to enable ==debugging and look in the log for these values). For example: == ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/* ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001 ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360 ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360 ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824 ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360 ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360 ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400 ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4 ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1 ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0 ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4 ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32 ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0 ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32 == == ==The possible problem I am thinking of is proper handling of the ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet Frame ==Alignment" in the spec. Which is confusing as hell, but if I understand ==it correctly then we are supposed to align the start of the IP packets ==(the "payload", _not_ the ethernet frame) to a whole wNdp*Divisor number ==as long as the wNdp*PayloadRemainder is 0. == == ==Bjørn ==
Re: [PATCH] USB: enable all functions remote wakeup for USB3 composite device
On Sun, Nov 30, 2014 at 03:51:37AM +, Li, Aixiong wrote: > Hi all, > > The patch format still have some problem since I copied it from the html > mail. I fix it in this mail. :) And it's still not in any format that I can apply it in. Your company has training on how to properly do this, please use that training to learn how to do it so that you don't waste our time... 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 0/4] remove unneeded array
Remove an array or structure that only serves as the first argument to
memset. The complete semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@@
identifier x;
type T;
@@
{
... when any
-T x[...];
<+... when != x
- memset(x,...);
...+>
}
@@
identifier x,i;
@@
{
... when any
-struct i x;
<+... when != x
- memset(&x,...);
...+>
}
//
--
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 4/4] usbip: remove unneeded structure
From: Julia Lawall
Delete a local structure that is only used to be initialized by memset.
A semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@@
identifier x,i;
@@
{
... when any
-struct i x;
<+... when != x
- memset(&x,...);
...+>
}
//
Signed-off-by: Julia Lawall
---
tools/usb/usbip/src/usbipd.c |2 --
1 file changed, 2 deletions(-)
diff --git a/tools/usb/usbip/src/usbipd.c b/tools/usb/usbip/src/usbipd.c
index 2f87f2d..2a7cd2b 100644
--- a/tools/usb/usbip/src/usbipd.c
+++ b/tools/usb/usbip/src/usbipd.c
@@ -91,7 +91,6 @@ static void usbipd_help(void)
static int recv_request_import(int sockfd)
{
struct op_import_request req;
- struct op_common reply;
struct usbip_exported_device *edev;
struct usbip_usb_device pdu_udev;
struct list_head *i;
@@ -100,7 +99,6 @@ static int recv_request_import(int sockfd)
int rc;
memset(&req, 0, sizeof(req));
- memset(&reply, 0, sizeof(reply));
rc = usbip_net_recv(sockfd, &req, sizeof(req));
if (rc < 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: Is this 32-bit NCM?
this is a capture equivalent to the m1 capture in the previous message; the
E3251 modem is communicating us the arp traffic of the gateway asking who will
have our IP in case of DHCP.
So you have some comparison.
See preivous mail in case.
Note: at^dialmode returns 3,2 in our case, which should be fine.
In the windows sniff it returned 1,2; however we are not allowed to change
this.
On Fri, 28 Nov 2014, Bjørn Mork wrote:
==Date: Fri, 28 Nov 2014 10:29:09
==From: Bjørn Mork
==To: Enrico Mioso
==Cc: Alex Strizhevsky , shaojunmidge@audiocodes.com,
==mingying@audiocodes.com, you...@gmail.com, linux-usb@vger.kernel.org,
==net...@vger.kernel.org, eli.britst...@audiocodes.com
==Subject: Re: Is this 32-bit NCM?
==
==Enrico Mioso writes:
==
==> What I suspect, is that all this mess started when Huawei introduce new
==> firmware releases that changed something in the IPV6 support.
==> Bjorn - do you remember when a guy called Thomas reported us a problem
about an
==> LTE huawei modem that wasn't working with huawei_cdc_ncm?
==> And you then discovered the problem was originated from some changes in the
==> ordering of cdc_ncm actions; what happened then?
==> Did Thomas get his modem back to working state?
==
==yes, that bug was fixed by
==
==commit ff0992e9036e9810e7cd45234fa32ca1e79750e2
==Author: Bjørn Mork
==Date: Mon Mar 17 16:25:18 2014 +0100
==
==net: cdc_ncm: fix control message ordering
==
==This is a context modified revert of commit 6a9612e2cb22
==("net: cdc_ncm: remove ncm_parm field") which introduced
==a NCM specification violation, causing setup errors for
==some devices. These errors resulted in the device and
==host disagreeing about shared settings, with complete
==failure to communicate as the end result.
==
==The NCM specification require that many of the NCM specific
==control reuests are sent only while the NCM Data Interface
==is in alternate setting 0. Reverting the commit ensures that
==we follow this requirement.
==
==Fixes: 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field")
==Reported-and-tested-by: Pasi Kärkkäinen
==Reported-by: Thomas Schäfer
==Signed-off-by: Bjørn Mork
==Signed-off-by: David S. Miller
==
==
==
==Bjørn
== 80 cf 74 d7 00 00 00 00 53 02 80 0a 01 00 00 3c ..t.S..<
0010 9b 5c 7b 54 00 00 00 00 7f ae 01 00 8d ff ff ff .\{T
0020 28 00 00 00 00 00 00 00 80 06 00 01 00 00 28 00 (.(.
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
80 cf 74 d7 00 00 00 00 43 02 80 0a 01 00 2d 00 ..t.C.-.
0010 9b 5c 7b 54 00 00 00 00 7d b1 01 00 00 00 00 00 .\{T}...
0020 12 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
0040 12 01 00 02 00 00 00 40 d1 12 06 15 02 01 02 01 ...@
0050 00 01 ..
80 cf 74 d7 00 00 00 00 53 02 80 06 01 00 00 3c ..t.S..<
0010 9b 5c 7b 54 00 00 00 00 de b1 01 00 8d ff ff ff .\{T
0020 28 00 00 00 00 00 00 00 80 06 00 01 00 00 28 00 (.(.
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
80 cf 74 d7 00 00 00 00 43 02 80 06 01 00 2d 00 ..t.C.-.
0010 9b 5c 7b 54 00 00 00 00 5a b2 01 00 00 00 00 00 .\{TZ...
0020 12 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
0040 12 01 00 02 ef 02 01 40 1a eb 61 27 12 12 00 00 ...@..a'
0050 00 01 ..
80 cf 74 d7 00 00 00 00 53 02 80 05 01 00 00 3c ..t.S..<
0010 9b 5c 7b 54 00 00 00 00 89 b2 01 00 8d ff ff ff .\{T
0020 28 00 00 00 00 00 00 00 80 06 00 01 00 00 28 00 (.(.
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
80 cf 74 d7 00 00 00 00 43 02 80 05 01 00 2d 00 ..t.C.-.
0010 9b 5c 7b 54 00 00 00 00 b6 b6 01 00 00 00 00 00 .\{T
0020 12 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
0040 12 01 00 02 00 00 00 08 ac 05 50 02 74 00 01 02 ..P.t...
0050 00 01 ..
80 cf 74 d7 00 00 00 00 53 02 80 04 01 00 00 3c ..t.S..<
0010 9b 5c 7b 54 00 00 00 00 e0 b6 01 00 8d ff ff ff .\{T
0020 28 00 00 00 00 00 00 00 80 06 00 01 00 00 28 00 (.(.
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
80 cf 74 d7 00 00 00 00 43 02 80 04 01 00 2d 00 ..t.C.-.
0010 9b 5c 7b 54 00 00 00 00 b3 b7 01 00 00 00 00 00 .\{T
0020 12 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 02 00 00
[PATCH 0/8] replace memset by memzero_explicit
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. The complete semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier x;
local idexpression e;
type T,T1;
@@
{
... when any
T x[...];
... when any
when exists
(
e = (T1)x
|
e = (T1)&x[0]
)
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when != e
when strict
}
@@
identifier i,x;
local idexpression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
e = (T)&x
... when any
when exists
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when != e
when strict
}
//
@@
identifier x;
type T,T1;
expression e;
@@
{
... when any
T x[...];
... when any
when exists
when != e = (T1)x
when != e = (T1)&x[0]
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
@@
identifier i,x;
expression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
when != e = (T)&x
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when strict
}
//
--
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 8/8 v2] wusb: replace memset by memzero_explicit
From: Julia Lawall
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. A simplified version of the semantic patch that makes this
change is as follows: (http://coccinelle.lip6.fr/)
//
@@
identifier x;
type T;
@@
{
... when any
T x[...];
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
//
This change was suggested by Daniel Borkmann
Signed-off-by: Julia Lawall
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
v2: fixed email address
drivers/usb/wusbcore/dev-sysfs.c |2 +-
drivers/usb/wusbcore/security.c |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/wusbcore/dev-sysfs.c b/drivers/usb/wusbcore/dev-sysfs.c
index 1018345..415b140 100644
--- a/drivers/usb/wusbcore/dev-sysfs.c
+++ b/drivers/usb/wusbcore/dev-sysfs.c
@@ -101,7 +101,7 @@ static ssize_t wusb_ck_store(struct device *dev,
if (wusbhc == NULL)
return -ENODEV;
result = wusb_dev_4way_handshake(wusbhc, usb_dev->wusb_dev, &ck);
- memset(&ck, 0, sizeof(ck));
+ memzero_explicit(&ck, sizeof(ck));
wusbhc_put(wusbhc);
return result < 0 ? result : size;
}
diff --git a/drivers/usb/wusbcore/security.c b/drivers/usb/wusbcore/security.c
index cc74d66..b66faaf 100644
--- a/drivers/usb/wusbcore/security.c
+++ b/drivers/usb/wusbcore/security.c
@@ -522,10 +522,10 @@ error_hs3:
error_hs2:
error_hs1:
memset(hs, 0, 3*sizeof(hs[0]));
- memset(&keydvt_out, 0, sizeof(keydvt_out));
- memset(&keydvt_in, 0, sizeof(keydvt_in));
- memset(&ccm_n, 0, sizeof(ccm_n));
- memset(mic, 0, sizeof(mic));
+ memzero_explicit(&keydvt_out, sizeof(keydvt_out));
+ memzero_explicit(&keydvt_in, sizeof(keydvt_in));
+ memzero_explicit(&ccm_n, sizeof(ccm_n));
+ memzero_explicit(mic, sizeof(mic));
if (result < 0)
wusb_dev_set_encryption(usb_dev, 0);
error_dev_set_encryption:
--
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 0/8] replace memset by memzero_explicit
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. The complete semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier x;
local idexpression e;
type T,T1;
@@
{
... when any
T x[...];
... when any
when exists
(
e = (T1)x
|
e = (T1)&x[0]
)
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when != e
when strict
}
@@
identifier i,x;
local idexpression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
e = (T)&x
... when any
when exists
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when != e
when strict
}
//
@@
identifier x;
type T,T1;
expression e;
@@
{
... when any
T x[...];
... when any
when exists
when != e = (T1)x
when != e = (T1)&x[0]
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
@@
identifier i,x;
expression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
when != e = (T)&x
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when strict
}
//
--
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 8/8] wusb: replace memset by memzero_explicit
From: Julia Lawall
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. A simplified version of the semantic patch that makes this
change is as follows: (http://coccinelle.lip6.fr/)
//
@@
identifier x;
type T;
@@
{
... when any
T x[...];
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
//
This change was suggested by Daniel Borkmann
Signed-off-by: Julia Lawall
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
drivers/usb/wusbcore/dev-sysfs.c |2 +-
drivers/usb/wusbcore/security.c |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/wusbcore/dev-sysfs.c b/drivers/usb/wusbcore/dev-sysfs.c
index 1018345..415b140 100644
--- a/drivers/usb/wusbcore/dev-sysfs.c
+++ b/drivers/usb/wusbcore/dev-sysfs.c
@@ -101,7 +101,7 @@ static ssize_t wusb_ck_store(struct device *dev,
if (wusbhc == NULL)
return -ENODEV;
result = wusb_dev_4way_handshake(wusbhc, usb_dev->wusb_dev, &ck);
- memset(&ck, 0, sizeof(ck));
+ memzero_explicit(&ck, sizeof(ck));
wusbhc_put(wusbhc);
return result < 0 ? result : size;
}
diff --git a/drivers/usb/wusbcore/security.c b/drivers/usb/wusbcore/security.c
index cc74d66..b66faaf 100644
--- a/drivers/usb/wusbcore/security.c
+++ b/drivers/usb/wusbcore/security.c
@@ -522,10 +522,10 @@ error_hs3:
error_hs2:
error_hs1:
memset(hs, 0, 3*sizeof(hs[0]));
- memset(&keydvt_out, 0, sizeof(keydvt_out));
- memset(&keydvt_in, 0, sizeof(keydvt_in));
- memset(&ccm_n, 0, sizeof(ccm_n));
- memset(mic, 0, sizeof(mic));
+ memzero_explicit(&keydvt_out, sizeof(keydvt_out));
+ memzero_explicit(&keydvt_in, sizeof(keydvt_in));
+ memzero_explicit(&ccm_n, sizeof(ccm_n));
+ memzero_explicit(mic, sizeof(mic));
if (result < 0)
wusb_dev_set_encryption(usb_dev, 0);
error_dev_set_encryption:
--
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: [Update 2x][PATCH] USB / PM: Drop CONFIG_PM_RUNTIME from the USB core
On Sat, 29 Nov 2014, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is > selected) PM_RUNTIME is always set if PM is set, so quite a few > #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to > depend on CONFIG_PM (or even dropped in some cases). > > Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code > and documentation. > > Signed-off-by: Rafael J. Wysocki > --- > > Added the Documentation/usb/power-management.txt changes. > > Of course, this depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME > if PM_SLEEP is selected) which is in linux-next only (via linux-pm) at the > moment. Acked-by: 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: Is this 32-bit NCM?
My impression guys is that this is not cdc_ncm protocol. Look how many short packets you can see in there. Without any ncm signature. right? On Sun, 30 Nov 2014, Alex Strizhevsky wrote: ==Date: Sun, 30 Nov 2014 05:22:20 ==From: Alex Strizhevsky ==To: Mrkiko Rs ==Cc: Eli Britstein , linux-usb@vger.kernel.org, =="you...@gmail.com" , ==Midge Shaojun Tan , =="net...@vger.kernel.org" , ==Kevin Zhu , Bjørn Mork ==Subject: Re: Is this 32-bit NCM? == == ==Hi Enrico, == ==Actually I have two dongles with different firmwares (23.128.00.00.00 & ==21.286.03.01.209). ==Probably have sent to you the USB capture with the first one. == ==In fact we have to make work the second one, this dongle has relevant SW. == ==On Nov 30, 2014 3:13 AM, "Enrico Mioso" wrote: == Hi guys. == Sorry for the late our but ... I was trying to figure out == something new about == this dongle. == I also searched for it in my city shops without finding it == actually. == But then I came back and ... tried to look at some things. == == Alex, Kevin: in the Windows USB captures you sent me (and that I == sent on the == List), I can notiche something very strange. == with a shell on a computer connected to a test device I can see == the following: == at+gmr == 21.286.03.01.209 == OK == and so why in the Windows sniff the dongle answers to the same == question == something like == 23.128.00.00.00 == ? == Alex - was it the same dongle? == Kevin or anyone: can you use putty to interact with the dongle == under Windows == and type some commands, like: == at+gmr == and other similar commands? == If the dongle reports different firmware versions under Linux == and Windows, then == guys... we need to figure out the Windows switch message. == Overmore - in the device installation sh*t, you can see there is == a firmware == updater... Why? == == Alex: I used the == at^reset == command to get the modem back to normal state once; and so it == restored the == nvram to default or something. == If you reconnect it to windows ... i hope it gets re-setup as == before. == But - nothing harmful to the device, only to it's settings, == sorry. == I restored the relevant settings and it connects again, but no == dhcp. But - be == peaceful: other modems out there seems to not get dhcp anyway. == this is the state the modem arrives when you buy it, so windows == should know == Wwhat To Say To The Modem (TM). == Another thing - note that: == [14170.048693] cdc_ncm 1-2:1.2: GET_MAX_DATAGRAM_SIZE failed == == Any ideas, comments, suggestions are highly appreciated guys. == Of any type. == == Bjorn - unfortunately it seems this problem is related to E3727 == and E3276 == sticks; they can get IP from DHCP but not go ahead. == == ==
Re: Is this 32-bit NCM?
Here are two USB captures. In m1 - the computer is "silent": and it can listen to ARP traffic coming from the modem. In m2, the computer tries to talk, performing DHCP with dhclient from Ubuntu. Any strange thing? Is the device really interpreting ndpOffset as Offset in the specs Kevin? If so we might elaborate on this. On Sun, 30 Nov 2014, Alex Strizhevsky wrote: ==Date: Sun, 30 Nov 2014 05:22:20 ==From: Alex Strizhevsky ==To: Mrkiko Rs ==Cc: Eli Britstein , linux-usb@vger.kernel.org, =="you...@gmail.com" , ==Midge Shaojun Tan , =="net...@vger.kernel.org" , ==Kevin Zhu , Bjørn Mork ==Subject: Re: Is this 32-bit NCM? == == ==Hi Enrico, == ==Actually I have two dongles with different firmwares (23.128.00.00.00 & ==21.286.03.01.209). ==Probably have sent to you the USB capture with the first one. == ==In fact we have to make work the second one, this dongle has relevant SW. == ==On Nov 30, 2014 3:13 AM, "Enrico Mioso" wrote: == Hi guys. == Sorry for the late our but ... I was trying to figure out == something new about == this dongle. == I also searched for it in my city shops without finding it == actually. == But then I came back and ... tried to look at some things. == == Alex, Kevin: in the Windows USB captures you sent me (and that I == sent on the == List), I can notiche something very strange. == with a shell on a computer connected to a test device I can see == the following: == at+gmr == 21.286.03.01.209 == OK == and so why in the Windows sniff the dongle answers to the same == question == something like == 23.128.00.00.00 == ? == Alex - was it the same dongle? == Kevin or anyone: can you use putty to interact with the dongle == under Windows == and type some commands, like: == at+gmr == and other similar commands? == If the dongle reports different firmware versions under Linux == and Windows, then == guys... we need to figure out the Windows switch message. == Overmore - in the device installation sh*t, you can see there is == a firmware == updater... Why? == == Alex: I used the == at^reset == command to get the modem back to normal state once; and so it == restored the == nvram to default or something. == If you reconnect it to windows ... i hope it gets re-setup as == before. == But - nothing harmful to the device, only to it's settings, == sorry. == I restored the relevant settings and it connects again, but no == dhcp. But - be == peaceful: other modems out there seems to not get dhcp anyway. == this is the state the modem arrives when you buy it, so windows == should know == Wwhat To Say To The Modem (TM). == Another thing - note that: == [14170.048693] cdc_ncm 1-2:1.2: GET_MAX_DATAGRAM_SIZE failed == == Any ideas, comments, suggestions are highly appreciated guys. == Of any type. == == Bjorn - unfortunately it seems this problem is related to E3727 == and E3276 == sticks; they can get IP from DHCP but not go ahead. == == ==
Re: Is this 32-bit NCM?
Sorry - by error I did not send the message to all. Hi everyone, and good Sunday! The problem is that - between those two firmwares things might change, and so we don't know what Windows does when it meets this specific branch /version of the firmware. I am desperately suspecting that we would not get anything hinting a lot even looking at the usb capture of this specific firmware, but... in any case it might be interesting to have it. (at+gmr returns the firmware revision) Is the dongles with 23 firmwares working under Linux? Or, you might upgrade all dongles firmware until all of then are running the 23 version and so workaround the problem differently in case. Bjorn: I noticed that anyway, as Alex suggested, tcpdump can reveal some traffic: in particular you can see the gateway asking for us ... but no traffic can flow out, only flow in. The system can see traffic coming in, not generate it. Any idea or comment from anyone is welcome. -- 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
