Re: [PATCH 3/5] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
Hi Felipe,
On Fri, Aug 29, 2014 at 12:46 AM, Felipe Balbi wrote:
> hi,
>
> On Thu, Aug 28, 2014 at 01:31:58PM +0530, Vivek Gautam wrote:
>> @@ -457,11 +458,19 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
>> clk_prepare_enable(phy_drd->ref_clk);
>>
>> /* Enable VBUS supply */
>> + if (phy_drd->vbus_boost) {
>> + ret = regulator_enable(phy_drd->vbus_boost);
>> + if (ret) {
>> + dev_err(phy_drd->dev,
>> + "Failed to enable VBUS boost supply\n");
>> + goto fail_vbus;
>> + }
>> + }
>
> really this is nitpicking, but can you add a blank line here just make
> my inner child happy ? :-)
Sure will add an extra line here and similar instances of this change.
>
>> @@ -470,6 +479,9 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
>>
>> return 0;
>>
>> +fail_vbus_boost:
>> + if (phy_drd->vbus_boost)
>> + regulator_disable(phy_drd->vbus_boost);
>
> same here
>
> --
> balbi
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi wrote: > 2014-08-28 10:02 GMT+02:00 Vivek Gautam: > >> This USB 3.0 PHY controller is also present on Exynos7 >> platform, so adding the dependency on ARCH_EXYNOS7 for this driver. > >> +++ b/drivers/phy/Kconfig >> @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 >> >> config PHY_EXYNOS5_USBDRD >> tristate "Exynos5 SoC series USB DRD PHY driver" >> - depends on ARCH_EXYNOS5 && OF >> + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) && OF > > shouldn't that prompt and its help text be updated to mention also Exynos7? Right, even that has to be updated accordingly. Will update the same in next version of the patch. Thanks for pointing this. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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] mfd: add support for Diolan DLN-2 devices
On Sat, 30 Aug 2014, Octavian Purdila wrote: > This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO > Master Adapter DLN-2. Details about the device can be found here: > > https://www.diolan.com/i2c/i2c_interface.html. > > Information about the USB protocol can be found in the Programmer's > Reference Manual [1], see section 1.7. > > Because the hardware has a single transmit endpoint and a single > receive endpoint the communication between the various DLN2 drivers > and the hardware will be muxed/demuxed by this driver. > > Each DLN2 module will be identified by the handle field within the DLN2 > message header. If a DLN2 module issues multiple commands in parallel > they will be identified by the echo counter field in the message header. > > The DLN2 modules can use the dln2_transfer() function to issue a > command and wait for its response. They can also register a callback > that is going to be called when a specific event id is generated by > the device (e.g. GPIO interrupts). The device uses handle 0 for > sending events. > > [1] https://www.diolan.com/downloads/dln-api-manual.pdf MFD is not a dumping ground for misfit h/w. Almost all of this code looks like it belongs in drivers/usb. Please move it there. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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] xhci-ring: Fix Null pointer dereference
Hello
The promised dmesg output. Still some "xhci_drop_endpoint called with..."
Thanks!
Sep 1 10:52:00 neopili kernel: [ 193.123108] usb 2-2: new SuperSpeed
USB device number 2 using xhci_hcd
Sep 1 10:52:00 neopili kernel: [ 193.142204] usb 2-2: New USB device
found, idVendor=0525, idProduct=a4a5
Sep 1 10:52:00 neopili kernel: [ 193.142211] usb 2-2: New USB device
strings: Mfr=3, Product=4, SerialNumber=0
Sep 1 10:52:00 neopili kernel: [ 193.142215] usb 2-2: Product: Mass
Storage Gadget
Sep 1 10:52:00 neopili kernel: [ 193.142218] usb 2-2: Manufacturer:
Linux 3.16.0-qtec-standard+ with net2280
Sep 1 10:52:00 neopili systemd-udevd[221]: unknown key
'SYSFS{manufacturer}' in /etc/udev/rules.d/52-digilent-usb.rules:35
Sep 1 10:52:00 neopili systemd-udevd[221]: invalid rule
'/etc/udev/rules.d/52-digilent-usb.rules:35'
Sep 1 10:52:00 neopili systemd-udevd[221]: unknown key 'BUS' in
/lib/udev/rules.d/60-libgnuradio-fcd3.7.3.rules:2
Sep 1 10:52:00 neopili systemd-udevd[221]: invalid rule
'/lib/udev/rules.d/60-libgnuradio-fcd3.7.3.rules:2'
Sep 1 10:52:00 neopili systemd-udevd[1720]: failed to execute
'/lib/udev/mtp-probe' 'mtp-probe
/sys/devices/pci:00/:00:1c.6/:0e:00.0/usb2/2-2 2 2': No
such file or directory
Sep 1 10:52:00 neopili kernel: [ 193.289553] usb-storage 2-2:1.0:
USB Mass Storage device detected
Sep 1 10:52:00 neopili kernel: [ 193.289745] usb-storage 2-2:1.0:
Quirks match for vid 0525 pid a4a5: 1
Sep 1 10:52:00 neopili kernel: [ 193.289820] scsi host6: usb-storage 2-2:1.0
Sep 1 10:52:00 neopili kernel: [ 193.289991] usbcore: registered new
interface driver usb-storage
Sep 1 10:52:00 neopili kernel: [ 193.312632] usbcore: registered new
interface driver uas
Sep 1 10:52:01 neopili kernel: [ 194.288067] scsi 6:0:0:0:
Direct-Access LinuxFile-Stor Gadget 0316 PQ: 0 ANSI: 2
Sep 1 10:52:01 neopili kernel: [ 194.288957] sd 6:0:0:0: Attached
scsi generic sg2 type 0
Sep 1 10:52:01 neopili kernel: [ 194.290003] sd 6:0:0:0: [sdb] 32768
512-byte logical blocks: (16.7 MB/16.0 MiB)
Sep 1 10:52:01 neopili kernel: [ 194.403012] usb 2-2: reset
SuperSpeed USB device number 2 using xhci_hcd
Sep 1 10:52:01 neopili kernel: [ 194.419901] xhci_hcd :0e:00.0:
xHCI xhci_drop_endpoint called with disabled ep 8805e68915c8
Sep 1 10:52:01 neopili kernel: [ 194.419907] xhci_hcd :0e:00.0:
xHCI xhci_drop_endpoint called with disabled ep 8805e6891580
Sep 1 10:52:31 neopili kernel: [ 224.908382] usb 2-2: reset
SuperSpeed USB device number 2 using xhci_hcd
Sep 1 10:52:31 neopili kernel: [ 224.925090] xhci_hcd :0e:00.0:
xHCI xhci_drop_endpoint called with disabled ep 8805e68915c8
Sep 1 10:52:31 neopili kernel: [ 224.925100] xhci_hcd :0e:00.0:
xHCI xhci_drop_endpoint called with disabled ep 8805e6891580
Sep 1 10:52:31 neopili kernel: [ 224.926327] sd 6:0:0:0: [sdb] Write
Protect is off
Sep 1 10:52:31 neopili kernel: [ 224.926336] sd 6:0:0:0: [sdb] Mode
Sense: 00 00 00 00
On Fri, Aug 29, 2014 at 5:20 PM, Mathias Nyman wrote:
> On 08/28/2014 06:09 PM, Ricardo Ribalda Delgado wrote:
>> Sure, but the hw leaves my desk until next monday in 30 minutes.
>>
>> So unless you send the patch right now you will have to wait for
>> results until next Monday
>>
>> Thanks!
>>
>
> Great, anytime you can test it is appreciated.
> Added the patch to the bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=75521
>
> Patch looks like this:
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index c020b09..7aee5a3 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -3544,6 +3544,10 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd,
> struct usb_device *udev)
> for (i = 1; i < 31; ++i) {
> struct xhci_virt_ep *ep = &virt_dev->eps[i];
>
> + /* reset device sets ep states to disabled, also halted ones
> */
> + ep->ep_state &= ~(EP_HALTED || SET_DEQ_PENDING);
> + ep->stopped_td = NULL;
> +
> if (ep->ep_state & EP_HAS_STREAMS) {
> xhci_warn(xhci, "WARN: endpoint 0x%02x has streams on
> device reset, freeing streams.\n",
> xhci_get_endpoint_address(i));
>
>
> -Mathias
>
--
Ricardo Ribalda
--
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] mfd: add support for Diolan DLN-2 devices
On Mon, Sep 1, 2014 at 11:37 AM, Lee Jones wrote: > On Sat, 30 Aug 2014, Octavian Purdila wrote: > >> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO >> Master Adapter DLN-2. Details about the device can be found here: >> >> https://www.diolan.com/i2c/i2c_interface.html. >> >> Information about the USB protocol can be found in the Programmer's >> Reference Manual [1], see section 1.7. >> >> Because the hardware has a single transmit endpoint and a single >> receive endpoint the communication between the various DLN2 drivers >> and the hardware will be muxed/demuxed by this driver. >> >> Each DLN2 module will be identified by the handle field within the DLN2 >> message header. If a DLN2 module issues multiple commands in parallel >> they will be identified by the echo counter field in the message header. >> >> The DLN2 modules can use the dln2_transfer() function to issue a >> command and wait for its response. They can also register a callback >> that is going to be called when a specific event id is generated by >> the device (e.g. GPIO interrupts). The device uses handle 0 for >> sending events. >> >> [1] https://www.diolan.com/downloads/dln-api-manual.pdf > > MFD is not a dumping ground for misfit h/w. Almost all of this code > looks like it belongs in drivers/usb. Please move it there. > Hi Lee, We initially submitted this driver as a pure USB driver, with our own module registration mechanism, but during the first round of reviews people pointed out that a MFD driver is the better approach, and I agree. I also see that there are already a couple of USB drivers implemented as MFD drivers. Do you see a better approach? Thanks, Tavi -- 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] xhci-ring: Fix Null pointer dereference
After some time of use (one hour or so) my system started to behave
"weird". I did check dmesg and I was receiving the following line
again and again:
usb-storage: Error in queuecommand_lck: us->sfb= 8805bd61ccc0
I did disconnect the usb device and the whole computer crashed :S
On Mon, Sep 1, 2014 at 11:02 AM, Ricardo Ribalda Delgado
wrote:
> Hello
>
> The promised dmesg output. Still some "xhci_drop_endpoint called with..."
>
> Thanks!
>
> Sep 1 10:52:00 neopili kernel: [ 193.123108] usb 2-2: new SuperSpeed
> USB device number 2 using xhci_hcd
> Sep 1 10:52:00 neopili kernel: [ 193.142204] usb 2-2: New USB device
> found, idVendor=0525, idProduct=a4a5
> Sep 1 10:52:00 neopili kernel: [ 193.142211] usb 2-2: New USB device
> strings: Mfr=3, Product=4, SerialNumber=0
> Sep 1 10:52:00 neopili kernel: [ 193.142215] usb 2-2: Product: Mass
> Storage Gadget
> Sep 1 10:52:00 neopili kernel: [ 193.142218] usb 2-2: Manufacturer:
> Linux 3.16.0-qtec-standard+ with net2280
> Sep 1 10:52:00 neopili systemd-udevd[221]: unknown key
> 'SYSFS{manufacturer}' in /etc/udev/rules.d/52-digilent-usb.rules:35
> Sep 1 10:52:00 neopili systemd-udevd[221]: invalid rule
> '/etc/udev/rules.d/52-digilent-usb.rules:35'
> Sep 1 10:52:00 neopili systemd-udevd[221]: unknown key 'BUS' in
> /lib/udev/rules.d/60-libgnuradio-fcd3.7.3.rules:2
> Sep 1 10:52:00 neopili systemd-udevd[221]: invalid rule
> '/lib/udev/rules.d/60-libgnuradio-fcd3.7.3.rules:2'
> Sep 1 10:52:00 neopili systemd-udevd[1720]: failed to execute
> '/lib/udev/mtp-probe' 'mtp-probe
> /sys/devices/pci:00/:00:1c.6/:0e:00.0/usb2/2-2 2 2': No
> such file or directory
> Sep 1 10:52:00 neopili kernel: [ 193.289553] usb-storage 2-2:1.0:
> USB Mass Storage device detected
> Sep 1 10:52:00 neopili kernel: [ 193.289745] usb-storage 2-2:1.0:
> Quirks match for vid 0525 pid a4a5: 1
> Sep 1 10:52:00 neopili kernel: [ 193.289820] scsi host6: usb-storage 2-2:1.0
> Sep 1 10:52:00 neopili kernel: [ 193.289991] usbcore: registered new
> interface driver usb-storage
> Sep 1 10:52:00 neopili kernel: [ 193.312632] usbcore: registered new
> interface driver uas
> Sep 1 10:52:01 neopili kernel: [ 194.288067] scsi 6:0:0:0:
> Direct-Access LinuxFile-Stor Gadget 0316 PQ: 0 ANSI: 2
> Sep 1 10:52:01 neopili kernel: [ 194.288957] sd 6:0:0:0: Attached
> scsi generic sg2 type 0
> Sep 1 10:52:01 neopili kernel: [ 194.290003] sd 6:0:0:0: [sdb] 32768
> 512-byte logical blocks: (16.7 MB/16.0 MiB)
> Sep 1 10:52:01 neopili kernel: [ 194.403012] usb 2-2: reset
> SuperSpeed USB device number 2 using xhci_hcd
> Sep 1 10:52:01 neopili kernel: [ 194.419901] xhci_hcd :0e:00.0:
> xHCI xhci_drop_endpoint called with disabled ep 8805e68915c8
> Sep 1 10:52:01 neopili kernel: [ 194.419907] xhci_hcd :0e:00.0:
> xHCI xhci_drop_endpoint called with disabled ep 8805e6891580
> Sep 1 10:52:31 neopili kernel: [ 224.908382] usb 2-2: reset
> SuperSpeed USB device number 2 using xhci_hcd
> Sep 1 10:52:31 neopili kernel: [ 224.925090] xhci_hcd :0e:00.0:
> xHCI xhci_drop_endpoint called with disabled ep 8805e68915c8
> Sep 1 10:52:31 neopili kernel: [ 224.925100] xhci_hcd :0e:00.0:
> xHCI xhci_drop_endpoint called with disabled ep 8805e6891580
> Sep 1 10:52:31 neopili kernel: [ 224.926327] sd 6:0:0:0: [sdb] Write
> Protect is off
> Sep 1 10:52:31 neopili kernel: [ 224.926336] sd 6:0:0:0: [sdb] Mode
> Sense: 00 00 00 00
>
> On Fri, Aug 29, 2014 at 5:20 PM, Mathias Nyman
> wrote:
>> On 08/28/2014 06:09 PM, Ricardo Ribalda Delgado wrote:
>>> Sure, but the hw leaves my desk until next monday in 30 minutes.
>>>
>>> So unless you send the patch right now you will have to wait for
>>> results until next Monday
>>>
>>> Thanks!
>>>
>>
>> Great, anytime you can test it is appreciated.
>> Added the patch to the bug:
>> https://bugzilla.kernel.org/show_bug.cgi?id=75521
>>
>> Patch looks like this:
>>
>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>> index c020b09..7aee5a3 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c
>> @@ -3544,6 +3544,10 @@ int xhci_discover_or_reset_device(struct usb_hcd
>> *hcd, struct usb_device *udev)
>> for (i = 1; i < 31; ++i) {
>> struct xhci_virt_ep *ep = &virt_dev->eps[i];
>>
>> + /* reset device sets ep states to disabled, also halted ones
>> */
>> + ep->ep_state &= ~(EP_HALTED || SET_DEQ_PENDING);
>> + ep->stopped_td = NULL;
>> +
>> if (ep->ep_state & EP_HAS_STREAMS) {
>> xhci_warn(xhci, "WARN: endpoint 0x%02x has streams
>> on device reset, freeing streams.\n",
>> xhci_get_endpoint_address(i));
>>
>>
>> -Mathias
>>
>
>
>
> --
> Ricardo Ribalda
--
Ricardo Ribalda
--
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
[PATCH resend 1/2] usb: serial: xsens_mt: add author and description
Signed-off-by: Frans Klaver
---
drivers/usb/serial/xsens_mt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/xsens_mt.c b/drivers/usb/serial/xsens_mt.c
index 4841fb5..d500ccd 100644
--- a/drivers/usb/serial/xsens_mt.c
+++ b/drivers/usb/serial/xsens_mt.c
@@ -82,4 +82,6 @@ static struct usb_serial_driver * const serial_drivers[] = {
module_usb_serial_driver(serial_drivers, id_table);
+MODULE_AUTHOR("Frans Klaver ");
+MODULE_DESCRIPTION("USB-serial driver for Xsens motion trackers");
MODULE_LICENSE("GPL");
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH resend 2/2] usb: serial: xsens_mt: always bind to interface number 1
Probe is testing if the current interface provides two bulk endpoints.
While this achieves the goal of only binding to the correct interface,
we already know we can find the device on interface number 1. Stop
checking the endpoints and just return successfully when interface
number 1 is probed.
Signed-off-by: Frans Klaver
---
drivers/usb/serial/xsens_mt.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/serial/xsens_mt.c b/drivers/usb/serial/xsens_mt.c
index d500ccd..ea67ed9 100644
--- a/drivers/usb/serial/xsens_mt.c
+++ b/drivers/usb/serial/xsens_mt.c
@@ -41,28 +41,13 @@ static const struct usb_device_id id_table[] = {
};
MODULE_DEVICE_TABLE(usb, id_table);
-static int has_required_endpoints(const struct usb_host_interface *interface)
-{
- __u8 i;
- int has_bulk_in = 0;
- int has_bulk_out = 0;
-
- for (i = 0; i < interface->desc.bNumEndpoints; ++i) {
- if (usb_endpoint_is_bulk_in(&interface->endpoint[i].desc))
- has_bulk_in = 1;
- else if (usb_endpoint_is_bulk_out(&interface->endpoint[i].desc))
- has_bulk_out = 1;
- }
-
- return has_bulk_in && has_bulk_out;
-}
-
static int xsens_mt_probe(struct usb_serial *serial,
const struct usb_device_id *id)
{
- if (!has_required_endpoints(serial->interface->cur_altsetting))
- return -ENODEV;
- return 0;
+ if (serial->interface->cur_altsetting.desc.bInterfaceNumber == 1)
+ return 0;
+
+ return -ENODEV;
}
static struct usb_serial_driver xsens_mt_device = {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] mfd: add support for Diolan DLN-2 devices
On Mon, 01 Sep 2014, Octavian Purdila wrote: > On Mon, Sep 1, 2014 at 11:37 AM, Lee Jones wrote: > > On Sat, 30 Aug 2014, Octavian Purdila wrote: > > > >> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO > >> Master Adapter DLN-2. Details about the device can be found here: > >> > >> https://www.diolan.com/i2c/i2c_interface.html. > >> > >> Information about the USB protocol can be found in the Programmer's > >> Reference Manual [1], see section 1.7. > >> > >> Because the hardware has a single transmit endpoint and a single > >> receive endpoint the communication between the various DLN2 drivers > >> and the hardware will be muxed/demuxed by this driver. > >> > >> Each DLN2 module will be identified by the handle field within the DLN2 > >> message header. If a DLN2 module issues multiple commands in parallel > >> they will be identified by the echo counter field in the message header. > >> > >> The DLN2 modules can use the dln2_transfer() function to issue a > >> command and wait for its response. They can also register a callback > >> that is going to be called when a specific event id is generated by > >> the device (e.g. GPIO interrupts). The device uses handle 0 for > >> sending events. > >> > >> [1] https://www.diolan.com/downloads/dln-api-manual.pdf > > > > MFD is not a dumping ground for misfit h/w. Almost all of this code > > looks like it belongs in drivers/usb. Please move it there. > > > > We initially submitted this driver as a pure USB driver, with our own > module registration mechanism, but during the first round of reviews > people pointed out that a MFD driver is the better approach, and I > agree. I also see that there are already a couple of USB drivers > implemented as MFD drivers. Can you link me to your previous submission please? > Do you see a better approach? You should have a small MFD driver which controls resources and registers children. All other functionality should live in their respective drivers/X locations i.e. USB functionallity should normally live in drivers/usb. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: sierra: add 1199:68AA device ID
On Thu, Aug 28, 2014 at 03:08:16PM +0200, Bjørn Mork wrote: > This VID:PID is used for some Direct IP devices behaving > identical to the already supported 0F3D:68AA devices. > > Cc: > Reported-by: Lars Melin > Signed-off-by: Bjørn Mork > --- > This should be applied on top of my 'USB: sierra: avoid CDC class > functions on "68A3" devices' to avoid unnecessary conflicts. > Apologies for not sending them as a series. It's a matter of one > patch triggering another report... Both patches applied, thanks. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: exynos: remove usb_phy_generic support
Hi,
On Friday, August 29, 2014 11:33:04 AM Greg Kroah-Hartman wrote:
> On Fri, Aug 29, 2014 at 11:02:52AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday, August 28, 2014 12:29:52 PM Greg Kroah-Hartman wrote:
> > > On Thu, Aug 28, 2014 at 08:11:04PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > [ added Alan and Greg to cc: ]
> > > >
> > > > Hi,
> > > >
> > > > On Wednesday, August 27, 2014 11:42:25 PM Vivek Gautam wrote:
> > > > > Hi Baltlomiej,
> > > > >
> > > > >
> > > > > On Wed, Aug 27, 2014 at 1:22 PM, Bartlomiej Zolnierkiewicz
> > > > > wrote:
> > > > > > dwc3 driver is using the new Exynos5 SoC series USB DRD PHY driver
> > > > > > (PHY_EXYNOS5_USBDRD which selects GENERIC_PHY) as can be seen by
> > > > > > looking at the following commits:
> > > > > >
> > > > > > 7a4cf0fde054 ("ARM: dts: Update DWC3 usb controller to use new
> > > > > > phy driver for exynos5250")
> > > > > >
> > > > > > f070267b5fc1 ("ARM: dts: Enable support for DWC3 controller for
> > > > > > exynos5420")
> > > > > >
> > > > > > Thus remove unused usb_phy_generic support from dwc3 Exynos glue
> > > > > > layer.
> > > > > >
> > > > > > [ The code that is being removed is harmful in the context of
> > > > > > multi_v7_defconfig and enabling "EHCI support for Samsung
> > > > > > S5P/EXYNOS SoC Series" (USB_EHCI_EXYNOS) + "OHCI support for
> > > > > > Samsung S5P/EXYNOS SoC Series" (USB_OHCI_EXYNOS) because "EHCI
> > > > > > support for OMAP3 and later chips" (USB_EHCI_HCD_OMAP) selects
> > > > > > "NOP USB Transceiver Driver" (NOP_USB_XCEIV). NOP USB driver
> > > > > > attaches itself to usb_phy_generic platform devices created by
> > > > > > dwc3 Exynos glue layer and later causes Exynos EHCI driver to
> > > > > > fail probe and Exynos OHCI driver to hang on probe (as observed
> > > > > > on Exynos5250 Arndale board). ]
> > > > >
> > > > > The issue with EHCI and OHCI on exynos platforms is that until now
> > > > > they also request
> > > > > usb-phy and only later if they don't find one, they go ahead and get a
> > > > > 'phy' generic.
> > > > >
> > > > > Fortunately we missed this issue with exynos_defconfig, and as you
> > > > > rightly
> > > > > mentioned with multi_v7_defconfig, the NOP_USB_XCEIV gets enabled and
> > > > > EHCI and OHCI exynos get no-op usb-phy, which actually blocks
> > > > > EHCI/OHCI from
> > > > > initializing the real PHYs.
> > > > >
> > > > > This issue is resolved with patches:
> > > > > [PATCH v2 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy
> > > > > support
> > > > > [PATCH v2 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy
> > > > > support
> > > > > wherein we are completely removing the usb-phy support from
> > > > > ehci/ohci-exynos.
> > > > > So with these patches we should not see the issue mentioned by you.
> > > >
> > > > Indeed, your patches fix the issue.
> > > >
> > > > Greg, could these two patches ([1] & [2]) get merged quickly, pretty
> > > > please
> > > > (they were already acked by Alan)? They are not a mere cleanups because
> > > > they fix the actual problem with using multi_v7_defconfig which in turn
> > > > has
> > > > been blocking Olof's defconfig update patch [3] for quite some time now.
> > > > Moreover these patches are limited to Exynos host drivers so they
> > > > should be
> > > > pretty safe when it comes to potential regressions.
> > > >
> > > > [1] http://www.spinics.net/lists/linux-usb/msg112294.html
> > > > [2] http://www.spinics.net/lists/linux-usb/msg112293.html
> > > > [3] http://www.spinics.net/lists/arm-kernel/msg349654.html
> > >
> > > merged for 3.18-rc1, or do you "need" them for 3.17-final?
> >
> > If it is not too much trouble please push them to 3.17-final.
>
> They don't meet the "regression or bugfix" rule at all, so I can't do
> this, sorry. I'll queue them up for 3.18.
These patches fix a real problem of boot hang when enabling Exynos USB
host drivers and using ARM multiplatform config so IMHO they fall into
bugfix category.
> > > I already reverted one patch for exynos for 3.17-final that is sitting
> > > in my tree to go to Linus soon as you all didn't seem to want it
> > > anymore, so I'm getting really confused here...
> >
> > These two patches are a replacement for the one reverted and
> > they just remove the old code instead of keeping it as fallback.
> > This means that the reverted patch was not breaking anything and
> > these two new patches could have been also done as incremental
> > ones. Sorry for the confusion.
>
> As they came in too late for 3.17-rc1, they will have to wait for
> 3.18-rc1.
Okay..
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
--
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] mfd: add support for Diolan DLN-2 devices
On Mon, Sep 1, 2014 at 12:51 PM, Lee Jones wrote: > On Mon, 01 Sep 2014, Octavian Purdila wrote: > >> On Mon, Sep 1, 2014 at 11:37 AM, Lee Jones wrote: >> > On Sat, 30 Aug 2014, Octavian Purdila wrote: >> > >> >> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO >> >> Master Adapter DLN-2. Details about the device can be found here: >> >> >> >> https://www.diolan.com/i2c/i2c_interface.html. >> >> >> >> Information about the USB protocol can be found in the Programmer's >> >> Reference Manual [1], see section 1.7. >> >> >> >> Because the hardware has a single transmit endpoint and a single >> >> receive endpoint the communication between the various DLN2 drivers >> >> and the hardware will be muxed/demuxed by this driver. >> >> >> >> Each DLN2 module will be identified by the handle field within the DLN2 >> >> message header. If a DLN2 module issues multiple commands in parallel >> >> they will be identified by the echo counter field in the message header. >> >> >> >> The DLN2 modules can use the dln2_transfer() function to issue a >> >> command and wait for its response. They can also register a callback >> >> that is going to be called when a specific event id is generated by >> >> the device (e.g. GPIO interrupts). The device uses handle 0 for >> >> sending events. >> >> >> >> [1] https://www.diolan.com/downloads/dln-api-manual.pdf >> > >> > MFD is not a dumping ground for misfit h/w. Almost all of this code >> > looks like it belongs in drivers/usb. Please move it there. >> > >> >> We initially submitted this driver as a pure USB driver, with our own >> module registration mechanism, but during the first round of reviews >> people pointed out that a MFD driver is the better approach, and I >> agree. I also see that there are already a couple of USB drivers >> implemented as MFD drivers. > > Can you link me to your previous submission please? Sure, here it is: https://lkml.org/lkml/2014/8/20/228 > >> Do you see a better approach? > > You should have a small MFD driver which controls resources and > registers children. All other functionality should live in their > respective drivers/X locations i.e. USB functionallity should normally > live in drivers/usb. > OK, that sounds better. I am not sure how to handle the registration part though, since in this case we need to create the children at runtime, from the usb probe routine. The only solution I see is to move the driver completely to usb/drivers and continue to use the MFD infrastructure. Does that sound OK to you? Thanks, Tavi -- 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] xhci-ring: Fix Null pointer dereference
On 09/01/2014 12:36 PM, Ricardo Ribalda Delgado wrote: > After some time of use (one hour or so) my system started to behave > "weird". I did check dmesg and I was receiving the following line > again and again: > > usb-storage: Error in queuecommand_lck: us->sfb= 8805bd61ccc0 > > I did disconnect the usb device and the whole computer crashed :S > Ok, thanks. Would you say things work better after the patch? I still think the patch solves part of the issue, i.e. how we handle halted endpoints in reset, but I don't know the reason why the endpoints stall in the first place -Mathias -- 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] xhci-ring: Fix Null pointer dereference
Well, it is hard to say. rc2 without the patch showed more warnings, but never crashed badly (queuecommand_lck). The sample size is not big enough. maybe rc2 also has the queuecommand_lck bug, but I havent hit it. On Mon, Sep 1, 2014 at 12:37 PM, Mathias Nyman wrote: > On 09/01/2014 12:36 PM, Ricardo Ribalda Delgado wrote: >> After some time of use (one hour or so) my system started to behave >> "weird". I did check dmesg and I was receiving the following line >> again and again: >> >> usb-storage: Error in queuecommand_lck: us->sfb= 8805bd61ccc0 >> >> I did disconnect the usb device and the whole computer crashed :S >> > > Ok, thanks. > > Would you say things work better after the patch? > > I still think the patch solves part of the issue, i.e. how we handle halted > endpoints > in reset, but I don't know the reason why the endpoints stall in the first > place > > -Mathias > > -- Ricardo Ribalda -- 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] xhci-ring: Fix Null pointer dereference
On 09/01/2014 01:26 PM, Ricardo Ribalda Delgado wrote: > Well, it is hard to say. rc2 without the patch showed more warnings, > but never crashed badly (queuecommand_lck). > > The sample size is not big enough. maybe rc2 also has the > queuecommand_lck bug, but I havent hit it. > Ok, I won't submit it as I now know what really is going on. I asked for once of the devices that can trigger this bug, https://bugzilla.kernel.org/show_bug.cgi?id=75521 I'll know more when I can get my hands on it -Mathias -- 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] xhci-ring: Fix Null pointer dereference
Do you have a NEC/Renesas uPD720200 USB 3.0 Host? If so, try with an usb gadget acting as a mass storage. That hits the bug in my machine. Regarsd! On Mon, Sep 1, 2014 at 1:12 PM, Mathias Nyman wrote: > On 09/01/2014 01:26 PM, Ricardo Ribalda Delgado wrote: >> Well, it is hard to say. rc2 without the patch showed more warnings, >> but never crashed badly (queuecommand_lck). >> >> The sample size is not big enough. maybe rc2 also has the >> queuecommand_lck bug, but I havent hit it. >> > > Ok, I won't submit it as I now know what really is going on. > > I asked for once of the devices that can trigger this bug, > https://bugzilla.kernel.org/show_bug.cgi?id=75521 > > I'll know more when I can get my hands on it > > -Mathias -- Ricardo Ribalda -- 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] usb: gadget: net2280: Fix invalid handling of Reset irq
Hello Felipe
I think that you have forgotten about this patch :). It is needed by
usb3380 in usb3.0 mode. Otherwise the device keeps reseting.
Thanks!
On Tue, Aug 26, 2014 at 6:00 PM, Ricardo Ribalda Delgado
wrote:
> Without this patch, some hosts keep restarting indefinitely the target.
>
> Fixes: ae8e530 (usb: gadget: net2280: Code Cleanup)
> Signed-off-by: Ricardo Ribalda Delgado
> ---
>
> v2: Request by Felipe Balbi
>
> Use Fixes: on commit message
>
> drivers/usb/gadget/udc/net2280.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/net2280.c
> b/drivers/usb/gadget/udc/net2280.c
> index f4eac11..2e95715 100644
> --- a/drivers/usb/gadget/udc/net2280.c
> +++ b/drivers/usb/gadget/udc/net2280.c
> @@ -3320,7 +3320,7 @@ static void handle_stat1_irqs(struct net2280 *dev, u32
> stat)
> if (stat & tmp) {
> writel(tmp, &dev->regs->irqstat1);
> if stat & BIT(ROOT_PORT_RESET_INTERRUPT)) &&
> - (readl(&dev->usb->usbstat) & mask)) ||
> + ((readl(&dev->usb->usbstat) & mask) == 0)) ||
> ((readl(&dev->usb->usbctl) &
> BIT(VBUS_PIN)) == 0)) &&
> (dev->gadget.speed != USB_SPEED_UNKNOWN)) {
> --
> 2.1.0
>
--
Ricardo Ribalda
--
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] mfd: add support for Diolan DLN-2 devices
On Mon, 01 Sep 2014, Octavian Purdila wrote: > On Mon, Sep 1, 2014 at 12:51 PM, Lee Jones wrote: > > On Mon, 01 Sep 2014, Octavian Purdila wrote: > > > >> On Mon, Sep 1, 2014 at 11:37 AM, Lee Jones wrote: > >> > On Sat, 30 Aug 2014, Octavian Purdila wrote: > >> > > >> >> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO > >> >> Master Adapter DLN-2. Details about the device can be found here: > >> >> > >> >> https://www.diolan.com/i2c/i2c_interface.html. > >> >> > >> >> Information about the USB protocol can be found in the Programmer's > >> >> Reference Manual [1], see section 1.7. > >> >> > >> >> Because the hardware has a single transmit endpoint and a single > >> >> receive endpoint the communication between the various DLN2 drivers > >> >> and the hardware will be muxed/demuxed by this driver. > >> >> > >> >> Each DLN2 module will be identified by the handle field within the DLN2 > >> >> message header. If a DLN2 module issues multiple commands in parallel > >> >> they will be identified by the echo counter field in the message header. > >> >> > >> >> The DLN2 modules can use the dln2_transfer() function to issue a > >> >> command and wait for its response. They can also register a callback > >> >> that is going to be called when a specific event id is generated by > >> >> the device (e.g. GPIO interrupts). The device uses handle 0 for > >> >> sending events. > >> >> > >> >> [1] https://www.diolan.com/downloads/dln-api-manual.pdf > >> > > >> > MFD is not a dumping ground for misfit h/w. Almost all of this code > >> > looks like it belongs in drivers/usb. Please move it there. > >> > > >> > >> We initially submitted this driver as a pure USB driver, with our own > >> module registration mechanism, but during the first round of reviews > >> people pointed out that a MFD driver is the better approach, and I > >> agree. I also see that there are already a couple of USB drivers > >> implemented as MFD drivers. > > > > Can you link me to your previous submission please? > > Sure, here it is: > > https://lkml.org/lkml/2014/8/20/228 > > > > >> Do you see a better approach? > > > > You should have a small MFD driver which controls resources and > > registers children. All other functionality should live in their > > respective drivers/X locations i.e. USB functionallity should normally > > live in drivers/usb. > > > > OK, that sounds better. I am not sure how to handle the registration > part though, since in this case we need to create the children at > runtime, from the usb probe routine. > > The only solution I see is to move the driver completely to > usb/drivers and continue to use the MFD infrastructure. Does that > sound OK to you? I have no problem with that. If this is an MFD driver, it _should_ live in drivers/mfd. However, all of that USB specific stuff defiantly should not. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] g_printer: Kernel freeze at disconnect/reconnect
Peter Bestler writes: > > I am using the g_printer driver in combination with kernel 3.2-rc7. > The hardware-platform is a Freescale p2020 (devicecontroller is the > fsl-usb2-core). For testing I use the printer.c-app in > /Documentation/usb/gadget_printer.c > > After setting a correct configuration and transmit/receive some bytes > via poll and read/write I pull the usb-cable. The Kernel freezes instantly > and only a reboot can bring up the board again. Thats because the fsl-udc > does not receive a reset_irq at physical disconnect, only suspend_irq. > . . . Greetings Peter! Were you able to solve the kernel freeze? Also, can you please help me with setting the configuration for g_printer? Please advise and thanks for your time. Peace . . . Vince -- 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] xhci-ring: Fix Null pointer dereference
On 09/01/2014 02:19 PM, Ricardo Ribalda Delgado wrote: > Do you have a NEC/Renesas uPD720200 USB 3.0 Host? > > If so, try with an usb gadget acting as a mass storage. That hits the > bug in my machine. > Thanks for the tip, but currently I only got Intel hosts. btw I earlier meant to say that I _don't_ know what's going on yet. -Mathias -- 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] xhci-ring: Fix Null pointer dereference
I could offer you a net3380 usb gadget device (mini pcie or pcie) but the uPD720200 is my notebook, so I cannot afford an extra one for you :) On Mon, Sep 1, 2014 at 2:25 PM, Mathias Nyman wrote: > On 09/01/2014 02:19 PM, Ricardo Ribalda Delgado wrote: >> Do you have a NEC/Renesas uPD720200 USB 3.0 Host? >> >> If so, try with an usb gadget acting as a mass storage. That hits the >> bug in my machine. >> > > Thanks for the tip, but currently I only got Intel hosts. > > btw I earlier meant to say that I _don't_ know what's going on yet. > > -Mathias > > -- Ricardo Ribalda -- 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 device stop probe after some times of EPROTO error
> On Sat, Aug 23, 2014 at 11:37:28PM +0800, peter li wrote: >> 1.In which case will i get EPROTO during commuicate with usb device, i >> called usb_bulk_msg in my usb_drv > > What driver is this? > I write the driver based on the old version usb-skeleton.c, the driver works fine,the error EPROTO will happen one time in about several thousand time. >> 2.while i continue plug and pull the usb device a few times because of >> EPROTO and some times (errno=110) error , the usb device is not probed, >> nothing print in dmesg. > > Sounds like a broken device, is the firmware crashed in it? Does the > device see the USB connection? > the usb device is ok, i reboot the pc or move the usb device to another pc , it works fine. some message in dmesg: usb 2-1:device descriptor read/64 ,error -62 usb 2-1:new full speed USB device using ohci and address 118 usb 2-1:can't config #1,error -71 usb 2-1:device not accpting address 119, error -71 .. usb 2-1:new full speed USB device using ohci and address 118 usb 2-1:device descriptor read/64 ,error -62 usb 2-1:device descriptor read/64 ,error -62 usb 2-1:new full speed USB device using ohci and address 119 usb 2-1:device descriptor read/64 ,error -62 usb 2-1:device descriptor read/64 ,error -62 ... some times retry by pull and plug the usb device stop probe , nothing in dmesg -- 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 RESEND v2 3/7] usb: phy: mxs: Add VF610 USB PHY support
I think I still miss a Signed-Off-By Felipe Balbi here...
All the rest should make it into 3.18, but USB without PHY is no fun to
use ;-)
Am 2014-08-19 01:37, schrieb Stefan Agner:
> This adds support for the USB PHY in Vybrid VF610. We assume that
> the disconnection without VBUS is also needed for Vybrid.
>
> Tests showed, without MXS_PHY_NEED_IP_FIX, enumeration of devices
> behind a USB Hub fails with errors:
>
> [ 215.163507] usb usb1-port1: cannot reset (err = -32)
> [ 215.170498] usb usb1-port1: cannot reset (err = -32)
> [ 215.185120] usb usb1-port1: cannot reset (err = -32)
> [ 215.191345] usb usb1-port1: cannot reset (err = -32)
> [ 215.202487] usb usb1-port1: cannot reset (err = -32)
> [ 215.207718] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
> [ 215.219317] usb usb1-port1: unable to enumerate USB device
>
> Hence we also enable the MXS_PHY_NEED_IP_FIX flag.
>
> Acked-by: Peter Chen
> Signed-off-by: Stefan Agner
> ---
> Documentation/devicetree/bindings/usb/mxs-phy.txt | 1 +
> drivers/usb/phy/phy-mxs-usb.c | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt
> b/Documentation/devicetree/bindings/usb/mxs-phy.txt
> index cef181a..fe3eed8 100644
> --- a/Documentation/devicetree/bindings/usb/mxs-phy.txt
> +++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt
> @@ -5,6 +5,7 @@ Required properties:
> * "fsl,imx23-usbphy" for imx23 and imx28
> * "fsl,imx6q-usbphy" for imx6dq and imx6dl
> * "fsl,imx6sl-usbphy" for imx6sl
> + * "fsl,vf610-usbphy" for Vybrid vf610
>"fsl,imx23-usbphy" is still a fallback for other strings
> - reg: Should contain registers location and length
> - interrupts: Should contain phy interrupt
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index c42bdf0..8c2f23b 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -125,10 +125,16 @@ static const struct mxs_phy_data imx6sl_phy_data = {
> MXS_PHY_NEED_IP_FIX,
> };
>
> +static const struct mxs_phy_data vf610_phy_data = {
> + .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
> + MXS_PHY_NEED_IP_FIX,
> +};
> +
> static const struct of_device_id mxs_phy_dt_ids[] = {
> { .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
> { .compatible = "fsl,imx6q-usbphy", .data = &imx6q_phy_data, },
> { .compatible = "fsl,imx23-usbphy", .data = &imx23_phy_data, },
> + { .compatible = "fsl,vf610-usbphy", .data = &vf610_phy_data, },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
--
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: renesas_usbhs: fix driver dependencies
Renesas USBHS controller support should be available only on Renesas ARM SoCs and SuperH architecture. Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Kyungmin Park Cc: Simon Horman Cc: Magnus Damm --- drivers/usb/renesas_usbhs/Kconfig |1 + 1 file changed, 1 insertion(+) Index: b/drivers/usb/renesas_usbhs/Kconfig === --- a/drivers/usb/renesas_usbhs/Kconfig 2014-07-30 14:31:51.883523522 +0200 +++ b/drivers/usb/renesas_usbhs/Kconfig 2014-09-01 14:25:42.028512490 +0200 @@ -5,6 +5,7 @@ config USB_RENESAS_USBHS tristate 'Renesas USBHS controller' depends on USB_GADGET + depends on ARCH_SHMOBILE || ARCH_SH || COMPILE_TEST default n help Renesas USBHS is a discrete USB host and peripheral controller chip -- 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: renesas_usbhs: fix driver dependencies
Hello. On 9/1/2014 5:14 PM, Bartlomiej Zolnierkiewicz wrote: Renesas USBHS controller support should be available only on Renesas ARM SoCs and SuperH architecture. Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Kyungmin Park Cc: Simon Horman Cc: Magnus Damm --- drivers/usb/renesas_usbhs/Kconfig |1 + 1 file changed, 1 insertion(+) Index: b/drivers/usb/renesas_usbhs/Kconfig === --- a/drivers/usb/renesas_usbhs/Kconfig 2014-07-30 14:31:51.883523522 +0200 +++ b/drivers/usb/renesas_usbhs/Kconfig 2014-09-01 14:25:42.028512490 +0200 @@ -5,6 +5,7 @@ config USB_RENESAS_USBHS tristate 'Renesas USBHS controller' depends on USB_GADGET + depends on ARCH_SHMOBILE || ARCH_SH || COMPILE_TEST Again, I think you meant SUPERH here, not ARCH_SH. WBR, Sergei -- 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] xhci-ring: Fix Null pointer dereference
On Mon, 1 Sep 2014, Mathias Nyman wrote: > On 09/01/2014 12:36 PM, Ricardo Ribalda Delgado wrote: > > After some time of use (one hour or so) my system started to behave > > "weird". I did check dmesg and I was receiving the following line > > again and again: > > > > usb-storage: Error in queuecommand_lck: us->sfb= 8805bd61ccc0 This is probably caused by some transfer not occurring correctly. With a usbmon trace we could see what was going on. > > I did disconnect the usb device and the whole computer crashed :S > > > > Ok, thanks. > > Would you say things work better after the patch? > > I still think the patch solves part of the issue, i.e. how we handle halted > endpoints > in reset, but I don't know the reason why the endpoints stall in the first > place The endpoint stall occurs because the device's protocol requires the endpoint to stall. The reason doesn't matter; xhci-hcd should handle stalls correctly whenever they occur. 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: gadgetfs regression: module refcount bug since 3.10
On Sun, 31 Aug 2014, S. Lockwood-Childs wrote: > gadgetfs has had a module refcount bug in all recent kernels, from v3.10 up > through present. I realize that gadgetfs is deprecated in favor of functionfs > nowadays, but probably you will want to fix it anyways since gadgetfs is still > in the tree. > More time spent with git-bisect showed that commit 3273097ee9c077 > "gadgetfs: don't bother with fops->owner" was the one that caused > the regression. Simply reverting that commit restores old behavior with > balanced gets and puts: opening gadgetfs files increments the module > refcount, closing them decrements it. You ought to CC: the person who wrote that commit. He is in the best position to fix problems with it. 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
[PATCH v2] usb: renesas_usbhs: fix driver dependencies
Renesas USBHS controller support should be available only on Renesas ARM SoCs and SuperH architecture. Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Kyungmin Park Cc: Simon Horman Cc: Magnus Damm --- v2: - s/ARCH_SH/SUPERH/ (thanks to Sergei Shtylyov) drivers/usb/renesas_usbhs/Kconfig |1 + 1 file changed, 1 insertion(+) Index: b/drivers/usb/renesas_usbhs/Kconfig === --- a/drivers/usb/renesas_usbhs/Kconfig 2014-07-30 14:31:51.883523522 +0200 +++ b/drivers/usb/renesas_usbhs/Kconfig 2014-09-01 14:25:42.028512490 +0200 @@ -5,6 +5,7 @@ config USB_RENESAS_USBHS tristate 'Renesas USBHS controller' depends on USB_GADGET + depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST default n help Renesas USBHS is a discrete USB host and peripheral controller chip -- 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 device stop probe after some times of EPROTO error
On Mon, 1 Sep 2014, peter li wrote: > > On Sat, Aug 23, 2014 at 11:37:28PM +0800, peter li wrote: > >> 1.In which case will i get EPROTO during commuicate with usb device, i > >> called usb_bulk_msg in my usb_drv > > > > What driver is this? > > > > I write the driver based on the old version usb-skeleton.c, the driver > works fine,the error EPROTO will happen one time in about > several thousand time. > > >> 2.while i continue plug and pull the usb device a few times because of > >> EPROTO and some times (errno=110) error , the usb device is not probed, > >> nothing print in dmesg. > > > > Sounds like a broken device, is the firmware crashed in it? Does the > > device see the USB connection? > > > > the usb device is ok, i reboot the pc or move the usb device to > another pc , it works fine. No, it is not working fine. If it were working fine, you wouldn't get all these errors. > some message in dmesg: > usb 2-1:device descriptor read/64 ,error -62 > usb 2-1:new full speed USB device using ohci and address 118 > usb 2-1:can't config #1,error -71 > > usb 2-1:device not accpting address 119, error -71 These are all errors caused by the device. > .. > > usb 2-1:new full speed USB device using ohci and address 118 > usb 2-1:device descriptor read/64 ,error -62 > usb 2-1:device descriptor read/64 ,error -62 > usb 2-1:new full speed USB device using ohci and address 119 > usb 2-1:device descriptor read/64 ,error -62 > usb 2-1:device descriptor read/64 ,error -62 > ... > some times retry by pull and plug the usb device > > stop probe , nothing in dmesg The device is not working correctly. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] mfd: add support for Diolan DLN-2 devices
On Mon, Sep 1, 2014 at 2:39 PM, Lee Jones wrote: > On Mon, 01 Sep 2014, Octavian Purdila wrote: > >> On Mon, Sep 1, 2014 at 12:51 PM, Lee Jones wrote: >> > On Mon, 01 Sep 2014, Octavian Purdila wrote: >> > >> >> On Mon, Sep 1, 2014 at 11:37 AM, Lee Jones wrote: >> >> > On Sat, 30 Aug 2014, Octavian Purdila wrote: >> >> > >> >> >> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO >> >> >> Master Adapter DLN-2. Details about the device can be found here: >> >> >> >> >> >> https://www.diolan.com/i2c/i2c_interface.html. >> >> >> >> >> >> Information about the USB protocol can be found in the Programmer's >> >> >> Reference Manual [1], see section 1.7. >> >> >> >> >> >> Because the hardware has a single transmit endpoint and a single >> >> >> receive endpoint the communication between the various DLN2 drivers >> >> >> and the hardware will be muxed/demuxed by this driver. >> >> >> >> >> >> Each DLN2 module will be identified by the handle field within the DLN2 >> >> >> message header. If a DLN2 module issues multiple commands in parallel >> >> >> they will be identified by the echo counter field in the message >> >> >> header. >> >> >> >> >> >> The DLN2 modules can use the dln2_transfer() function to issue a >> >> >> command and wait for its response. They can also register a callback >> >> >> that is going to be called when a specific event id is generated by >> >> >> the device (e.g. GPIO interrupts). The device uses handle 0 for >> >> >> sending events. >> >> >> >> >> >> [1] https://www.diolan.com/downloads/dln-api-manual.pdf >> >> > >> >> > MFD is not a dumping ground for misfit h/w. Almost all of this code >> >> > looks like it belongs in drivers/usb. Please move it there. >> >> > >> >> >> >> We initially submitted this driver as a pure USB driver, with our own >> >> module registration mechanism, but during the first round of reviews >> >> people pointed out that a MFD driver is the better approach, and I >> >> agree. I also see that there are already a couple of USB drivers >> >> implemented as MFD drivers. >> > >> > Can you link me to your previous submission please? >> >> Sure, here it is: >> >> https://lkml.org/lkml/2014/8/20/228 >> >> > >> >> Do you see a better approach? >> > >> > You should have a small MFD driver which controls resources and >> > registers children. All other functionality should live in their >> > respective drivers/X locations i.e. USB functionallity should normally >> > live in drivers/usb. >> > >> >> OK, that sounds better. I am not sure how to handle the registration >> part though, since in this case we need to create the children at >> runtime, from the usb probe routine. >> >> The only solution I see is to move the driver completely to >> usb/drivers and continue to use the MFD infrastructure. Does that >> sound OK to you? > > I have no problem with that. If this is an MFD driver, it _should_ > live in drivers/mfd. However, all of that USB specific stuff > defiantly should not. > It is a multi-function driver which is using the USB interface, so I am not sure where it belongs. The only driver that calls mfd_add_devices and is not in drivers/mfd is the hid sensor hub driver. BTW, the mfd/viperboard.c driver is very similar with this driver. It has less USB specific stuff because the protocol is simpler, but still has some. -- 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] mfd: add support for Diolan DLN-2 devices
On Mon, 01 Sep 2014, Octavian Purdila wrote: > On Mon, Sep 1, 2014 at 2:39 PM, Lee Jones wrote: > > On Mon, 01 Sep 2014, Octavian Purdila wrote: > > > >> On Mon, Sep 1, 2014 at 12:51 PM, Lee Jones wrote: > >> > On Mon, 01 Sep 2014, Octavian Purdila wrote: > >> > > >> >> On Mon, Sep 1, 2014 at 11:37 AM, Lee Jones wrote: > >> >> > On Sat, 30 Aug 2014, Octavian Purdila wrote: > >> >> > > >> >> >> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO > >> >> >> Master Adapter DLN-2. Details about the device can be found here: > >> >> >> > >> >> >> https://www.diolan.com/i2c/i2c_interface.html. > >> >> >> > >> >> >> Information about the USB protocol can be found in the Programmer's > >> >> >> Reference Manual [1], see section 1.7. > >> >> >> > >> >> >> Because the hardware has a single transmit endpoint and a single > >> >> >> receive endpoint the communication between the various DLN2 drivers > >> >> >> and the hardware will be muxed/demuxed by this driver. > >> >> >> > >> >> >> Each DLN2 module will be identified by the handle field within the > >> >> >> DLN2 > >> >> >> message header. If a DLN2 module issues multiple commands in parallel > >> >> >> they will be identified by the echo counter field in the message > >> >> >> header. > >> >> >> > >> >> >> The DLN2 modules can use the dln2_transfer() function to issue a > >> >> >> command and wait for its response. They can also register a callback > >> >> >> that is going to be called when a specific event id is generated by > >> >> >> the device (e.g. GPIO interrupts). The device uses handle 0 for > >> >> >> sending events. > >> >> >> > >> >> >> [1] https://www.diolan.com/downloads/dln-api-manual.pdf > >> >> > > >> >> > MFD is not a dumping ground for misfit h/w. Almost all of this code > >> >> > looks like it belongs in drivers/usb. Please move it there. > >> >> > > >> >> > >> >> We initially submitted this driver as a pure USB driver, with our own > >> >> module registration mechanism, but during the first round of reviews > >> >> people pointed out that a MFD driver is the better approach, and I > >> >> agree. I also see that there are already a couple of USB drivers > >> >> implemented as MFD drivers. > >> > > >> > Can you link me to your previous submission please? > >> > >> Sure, here it is: > >> > >> https://lkml.org/lkml/2014/8/20/228 > >> > >> > > >> >> Do you see a better approach? > >> > > >> > You should have a small MFD driver which controls resources and > >> > registers children. All other functionality should live in their > >> > respective drivers/X locations i.e. USB functionallity should normally > >> > live in drivers/usb. > >> > > >> > >> OK, that sounds better. I am not sure how to handle the registration > >> part though, since in this case we need to create the children at > >> runtime, from the usb probe routine. > >> > >> The only solution I see is to move the driver completely to > >> usb/drivers and continue to use the MFD infrastructure. Does that > >> sound OK to you? > > > > I have no problem with that. If this is an MFD driver, it _should_ > > live in drivers/mfd. However, all of that USB specific stuff > > defiantly should not. > > > > It is a multi-function driver which is using the USB interface, so I > am not sure where it belongs. The only driver that calls > mfd_add_devices and is not in drivers/mfd is the hid sensor hub > driver. > > BTW, the mfd/viperboard.c driver is very similar with this driver. It > has less USB specific stuff because the protocol is simpler, but still > has some. Looking at viperboard.c, it seems to use some basic generic framework calls to obtain some information about the device information like version numbers. Your driver is leaps and bounds more USB centric. Your MFD driver should know about things like; regmap, platform data, memory allocation, same-chip devices (children), etc. Your MFD driver should not need to concern itself with; endpoints, slots, URBs, USB device IDs and the like. The later knowledge belongs in drivers/usb. You should be calling mfd_add_devices() from within the MFD driver. At a guess, I would say that you need a new entry for the USB stuff in your mfd_cells structure. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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] mfd: add support for Diolan DLN-2 devices
On Mon, Sep 1, 2014 at 6:46 PM, Lee Jones wrote: > On Mon, 01 Sep 2014, Octavian Purdila wrote: > >> On Mon, Sep 1, 2014 at 2:39 PM, Lee Jones wrote: >> > On Mon, 01 Sep 2014, Octavian Purdila wrote: >> > >> >> On Mon, Sep 1, 2014 at 12:51 PM, Lee Jones wrote: >> >> > On Mon, 01 Sep 2014, Octavian Purdila wrote: >> >> > >> >> >> On Mon, Sep 1, 2014 at 11:37 AM, Lee Jones >> >> >> wrote: >> >> >> > On Sat, 30 Aug 2014, Octavian Purdila wrote: >> >> >> > >> >> >> >> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO >> >> >> >> Master Adapter DLN-2. Details about the device can be found here: >> >> >> >> >> >> >> >> https://www.diolan.com/i2c/i2c_interface.html. >> >> >> >> >> >> >> >> Information about the USB protocol can be found in the Programmer's >> >> >> >> Reference Manual [1], see section 1.7. >> >> >> >> >> >> >> >> Because the hardware has a single transmit endpoint and a single >> >> >> >> receive endpoint the communication between the various DLN2 drivers >> >> >> >> and the hardware will be muxed/demuxed by this driver. >> >> >> >> >> >> >> >> Each DLN2 module will be identified by the handle field within the >> >> >> >> DLN2 >> >> >> >> message header. If a DLN2 module issues multiple commands in >> >> >> >> parallel >> >> >> >> they will be identified by the echo counter field in the message >> >> >> >> header. >> >> >> >> >> >> >> >> The DLN2 modules can use the dln2_transfer() function to issue a >> >> >> >> command and wait for its response. They can also register a callback >> >> >> >> that is going to be called when a specific event id is generated by >> >> >> >> the device (e.g. GPIO interrupts). The device uses handle 0 for >> >> >> >> sending events. >> >> >> >> >> >> >> >> [1] https://www.diolan.com/downloads/dln-api-manual.pdf >> >> >> > >> >> >> > MFD is not a dumping ground for misfit h/w. Almost all of this code >> >> >> > looks like it belongs in drivers/usb. Please move it there. >> >> >> > >> >> >> >> >> >> We initially submitted this driver as a pure USB driver, with our own >> >> >> module registration mechanism, but during the first round of reviews >> >> >> people pointed out that a MFD driver is the better approach, and I >> >> >> agree. I also see that there are already a couple of USB drivers >> >> >> implemented as MFD drivers. >> >> > >> >> > Can you link me to your previous submission please? >> >> >> >> Sure, here it is: >> >> >> >> https://lkml.org/lkml/2014/8/20/228 >> >> >> >> > >> >> >> Do you see a better approach? >> >> > >> >> > You should have a small MFD driver which controls resources and >> >> > registers children. All other functionality should live in their >> >> > respective drivers/X locations i.e. USB functionallity should normally >> >> > live in drivers/usb. >> >> > >> >> >> >> OK, that sounds better. I am not sure how to handle the registration >> >> part though, since in this case we need to create the children at >> >> runtime, from the usb probe routine. >> >> >> >> The only solution I see is to move the driver completely to >> >> usb/drivers and continue to use the MFD infrastructure. Does that >> >> sound OK to you? >> > >> > I have no problem with that. If this is an MFD driver, it _should_ >> > live in drivers/mfd. However, all of that USB specific stuff >> > defiantly should not. >> > >> >> It is a multi-function driver which is using the USB interface, so I >> am not sure where it belongs. The only driver that calls >> mfd_add_devices and is not in drivers/mfd is the hid sensor hub >> driver. >> >> BTW, the mfd/viperboard.c driver is very similar with this driver. It >> has less USB specific stuff because the protocol is simpler, but still >> has some. > > Looking at viperboard.c, it seems to use some basic generic framework > calls to obtain some information about the device information like > version numbers. Your driver is leaps and bounds more USB centric. > > Your MFD driver should know about things like; regmap, platform data, > memory allocation, same-chip devices (children), etc. Your MFD driver > should not need to concern itself with; endpoints, slots, URBs, USB > device IDs and the like. The later knowledge belongs in drivers/usb. > > You should be calling mfd_add_devices() from within the MFD driver. > At a guess, I would say that you need a new entry for the USB stuff in > your mfd_cells structure. > Makes sense, thanks for making clearing up what the MFD part of the driver should do. Here is how I think it could work: * keep the usb probe routine in the MFD driver (and keep it a usb driver) * add a new cell for the usb part * pass the usb_interface via platform_data to the USB sub-driver's platform_device probe routine and continue the USB setup there Lee, USB folks, is this acceptable? -- 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] usb: renesas_usbhs: fix driver dependencies
On Mon, Sep 1, 2014 at 4:24 PM, Bartlomiej Zolnierkiewicz
wrote:
> Renesas USBHS controller support should be available only on
> Renesas ARM SoCs and SuperH architecture.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Acked-by: Kyungmin Park
> Cc: Simon Horman
> Cc: Magnus Damm
> ---
> v2:
> - s/ARCH_SH/SUPERH/ (thanks to Sergei Shtylyov)
Acked-by: Geert Uytterhoeven
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
Re: [PATCH v2 1/3] mfd: add support for Diolan DLN-2 devices
On Mon, Sep 01, 2014 at 07:22:39PM +0300, Octavian Purdila wrote: > On Mon, Sep 1, 2014 at 6:46 PM, Lee Jones wrote: > > On Mon, 01 Sep 2014, Octavian Purdila wrote: > > > >> On Mon, Sep 1, 2014 at 2:39 PM, Lee Jones wrote: > >> > On Mon, 01 Sep 2014, Octavian Purdila wrote: > >> >> On Mon, Sep 1, 2014 at 12:51 PM, Lee Jones wrote: > >> >> > You should have a small MFD driver which controls resources and > >> >> > registers children. All other functionality should live in their > >> >> > respective drivers/X locations i.e. USB functionallity should normally > >> >> > live in drivers/usb. > >> >> > > >> >> > >> >> OK, that sounds better. I am not sure how to handle the registration > >> >> part though, since in this case we need to create the children at > >> >> runtime, from the usb probe routine. > >> >> > >> >> The only solution I see is to move the driver completely to > >> >> usb/drivers and continue to use the MFD infrastructure. Does that > >> >> sound OK to you? > >> > > >> > I have no problem with that. If this is an MFD driver, it _should_ > >> > live in drivers/mfd. However, all of that USB specific stuff > >> > defiantly should not. > >> > > >> > >> It is a multi-function driver which is using the USB interface, so I > >> am not sure where it belongs. The only driver that calls > >> mfd_add_devices and is not in drivers/mfd is the hid sensor hub > >> driver. > >> > >> BTW, the mfd/viperboard.c driver is very similar with this driver. It > >> has less USB specific stuff because the protocol is simpler, but still > >> has some. > > > > Looking at viperboard.c, it seems to use some basic generic framework > > calls to obtain some information about the device information like > > version numbers. Your driver is leaps and bounds more USB centric. > > > > Your MFD driver should know about things like; regmap, platform data, > > memory allocation, same-chip devices (children), etc. Your MFD driver > > should not need to concern itself with; endpoints, slots, URBs, USB > > device IDs and the like. The later knowledge belongs in drivers/usb. > > > > You should be calling mfd_add_devices() from within the MFD driver. > > At a guess, I would say that you need a new entry for the USB stuff in > > your mfd_cells structure. > > > > Makes sense, thanks for making clearing up what the MFD part of the > driver should do. > > Here is how I think it could work: > > * keep the usb probe routine in the MFD driver (and keep it a usb driver) > > * add a new cell for the usb part > > * pass the usb_interface via platform_data to the USB sub-driver's > platform_device probe routine and continue the USB setup there > > Lee, USB folks, is this acceptable? No, no. USB is not a function of the MFD device, it's the transport. Thus there should be no USB MFD-cell. No subdriver can work without it. And the USB id belongs in the MFD-driver in the same way that an i2c id (address) does. Just like an MFD device with i2c as a transport, this driver would function as an arbiter to a shared resource (i.e. the register space). The reason it seems much more USB-centric than an i2c-mfd driver is that that transport API is simpler and some code have also already been generalised (e.g. regmap), whereas we appear to have only two USB mfd-drivers thus far. The viperboard is perhaps a bad example in so far that it has pushed the transport details down into the subdrivers (and thus into gpio, i2c and iio subsystems) instead of handling it one place. I haven't looked at the details of the protocol for the device in question, but it might even be possible to use regmap here (as I mentioned in my comments on v1). Johan -- 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] usb: renesas_usbhs: fix driver dependencies
On Mon, Sep 01, 2014 at 06:40:50PM +0200, Geert Uytterhoeven wrote: > On Mon, Sep 1, 2014 at 4:24 PM, Bartlomiej Zolnierkiewicz > wrote: > > Renesas USBHS controller support should be available only on > > Renesas ARM SoCs and SuperH architecture. > > > > Signed-off-by: Bartlomiej Zolnierkiewicz > > Acked-by: Kyungmin Park > > Cc: Simon Horman > > Cc: Magnus Damm > > --- > > v2: > > - s/ARCH_SH/SUPERH/ (thanks to Sergei Shtylyov) > > Acked-by: Geert Uytterhoeven Acked-by: Simon Horman -- 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 net-next] r8152: rename rx_buf_sz
The variable "rx_buf_sz" is used by both tx and rx buffers. Replace
it with "agg_buf_sz".
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index cc64dc0..80b0179 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -607,9 +607,9 @@ enum tx_csum_stat {
* The RTL chips use a 64 element hash table based on the Ethernet CRC.
*/
static const int multicast_filter_limit = 32;
-static unsigned int rx_buf_sz = 16384;
+static unsigned int agg_buf_sz = 16384;
-#define RTL_LIMITED_TSO_SIZE (rx_buf_sz - sizeof(struct tx_desc) - \
+#define RTL_LIMITED_TSO_SIZE (agg_buf_sz - sizeof(struct tx_desc) - \
VLAN_ETH_HLEN - VLAN_HLEN)
static
@@ -1248,13 +1248,13 @@ static int alloc_all_mem(struct r8152 *tp)
skb_queue_head_init(&tp->tx_queue);
for (i = 0; i < RTL8152_MAX_RX; i++) {
- buf = kmalloc_node(rx_buf_sz, GFP_KERNEL, node);
+ buf = kmalloc_node(agg_buf_sz, GFP_KERNEL, node);
if (!buf)
goto err1;
if (buf != rx_agg_align(buf)) {
kfree(buf);
- buf = kmalloc_node(rx_buf_sz + RX_ALIGN, GFP_KERNEL,
+ buf = kmalloc_node(agg_buf_sz + RX_ALIGN, GFP_KERNEL,
node);
if (!buf)
goto err1;
@@ -1274,13 +1274,13 @@ static int alloc_all_mem(struct r8152 *tp)
}
for (i = 0; i < RTL8152_MAX_TX; i++) {
- buf = kmalloc_node(rx_buf_sz, GFP_KERNEL, node);
+ buf = kmalloc_node(agg_buf_sz, GFP_KERNEL, node);
if (!buf)
goto err1;
if (buf != tx_agg_align(buf)) {
kfree(buf);
- buf = kmalloc_node(rx_buf_sz + TX_ALIGN, GFP_KERNEL,
+ buf = kmalloc_node(agg_buf_sz + TX_ALIGN, GFP_KERNEL,
node);
if (!buf)
goto err1;
@@ -1518,7 +1518,7 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
tx_data = agg->head;
agg->skb_num = 0;
agg->skb_len = 0;
- remain = rx_buf_sz;
+ remain = agg_buf_sz;
while (remain >= ETH_ZLEN + sizeof(struct tx_desc)) {
struct tx_desc *tx_desc;
@@ -1565,7 +1565,7 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
dev_kfree_skb_any(skb);
- remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg->head);
+ remain = agg_buf_sz - (int)(tx_agg_align(tx_data) - agg->head);
}
if (!skb_queue_empty(&skb_head)) {
@@ -1771,7 +1771,7 @@ static
int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags)
{
usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
- agg->head, rx_buf_sz,
+ agg->head, agg_buf_sz,
(usb_complete_t)read_bulk_callback, agg);
return usb_submit_urb(agg->urb, mem_flags);
@@ -1915,8 +1915,8 @@ static void set_tx_qlen(struct r8152 *tp)
{
struct net_device *netdev = tp->netdev;
- tp->tx_qlen = rx_buf_sz / (netdev->mtu + VLAN_ETH_HLEN + VLAN_HLEN +
- sizeof(struct tx_desc));
+ tp->tx_qlen = agg_buf_sz / (netdev->mtu + VLAN_ETH_HLEN + VLAN_HLEN +
+ sizeof(struct tx_desc));
}
static inline u8 rtl8152_get_speed(struct r8152 *tp)
--
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: [PATCH net-next] r8152: rename rx_buf_sz
From: Hayes Wang Date: Tue, 2 Sep 2014 10:27:52 +0800 > The variable "rx_buf_sz" is used by both tx and rx buffers. Replace > it with "agg_buf_sz". > > Signed-off-by: Hayes Wang Applied. -- 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
[uas/3.16.1] panic in uas_data_cmplt()
Dear all: The kernel version is 3.16.1-1-ARCH Today I keep getting this panic when booting up. http://i.imgur.com/0Rx93Kr.jpg It might be that the UAS device was in some strange state, because that after I unplugged and power-cycled the UAS, everything went normal again. Does anyone know what's the root cause of this issue? Or could anyone provide some instruction on how to debug this issue? Thanks -- 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: [uas/3.16.1] panic in uas_data_cmplt()
Hi, On 09/02/2014 06:18 AM, Chunwei Chen wrote: > Dear all: > > The kernel version is 3.16.1-1-ARCH > > Today I keep getting this panic when booting up. > http://i.imgur.com/0Rx93Kr.jpg > > It might be that the UAS device was in some strange state, > because that after I unplugged and power-cycled the UAS, > everything went normal again. > > Does anyone know what's the root cause of this issue? > Or could anyone provide some instruction on how to debug this issue? There seem to be some issues in the error handling paths of the uas driver. I plan to rewrite them completely for robustness and go through them with a fine comb to fix any possible bugs while at it. I'll send out a mail when I've a new version ready for testing. Regards, Hans -- 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
