[PATCH] UWB: clean up attribute use by using ATTRIBUTE_GROUPS()
From: Greg Kroah-Hartman
The ATTRIBUTE_GROUPS() macro can be used in the uwb code to reduce the
number of lines of code.
Signed-off-by: Greg Kroah-Hartman
---
drivers/uwb/lc-dev.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
--- a/drivers/uwb/lc-dev.c
+++ b/drivers/uwb/lc-dev.c
@@ -244,7 +244,7 @@ static ssize_t uwb_dev_RSSI_store(struct
static DEVICE_ATTR(RSSI, S_IRUGO | S_IWUSR, uwb_dev_RSSI_show,
uwb_dev_RSSI_store);
-static struct attribute *dev_attrs[] = {
+static struct attribute *uwb_dev_attrs[] = {
&dev_attr_EUI_48.attr,
&dev_attr_DevAddr.attr,
&dev_attr_BPST.attr,
@@ -253,20 +253,10 @@ static struct attribute *dev_attrs[] = {
&dev_attr_RSSI.attr,
NULL,
};
-
-static struct attribute_group dev_attr_group = {
- .attrs = dev_attrs,
-};
-
-static const struct attribute_group *groups[] = {
- &dev_attr_group,
- NULL,
-};
+ATTRIBUTE_GROUPS(uwb_dev);
/**
* Device SYSFS registration
- *
- *
*/
static int __uwb_dev_sys_add(struct uwb_dev *uwb_dev, struct device
*parent_dev)
{
@@ -276,7 +266,7 @@ static int __uwb_dev_sys_add(struct uwb_
/* Device sysfs files are only useful for neighbor devices not
local radio controllers. */
if (&uwb_dev->rc->uwb_dev != uwb_dev)
- dev->groups = groups;
+ dev->groups = uwb_dev_groups;
dev->parent = parent_dev;
dev_set_drvdata(dev, uwb_dev);
--
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
Usb problem, FGR not stopped yet!
Somewhere after kernel 3.2.0 my usb started acting weird and not working correctly. For example, 'sudo lsusb -v' makes dmesg say: [ 717.076019] uhci_hcd :00:10.3: FGR not stopped yet! [ 717.104021] uhci_hcd :00:10.2: FGR not stopped yet! [ 717.128019] uhci_hcd :00:10.1: FGR not stopped yet! [ 739.428037] uhci_hcd :00:10.3: FGR not stopped yet! [ 739.452074] uhci_hcd :00:10.2: FGR not stopped yet! [ 739.476025] uhci_hcd :00:10.1: FGR not stopped yet! That's the only error message I can find related to this problem. Also pluggin in printer or phone makes the same message, and they don't work at all. Everything plugged at boot seem to work, but if I unplug my keyboard, it doesn't work anymore after plugging it back in. Same with mouse. Here's 'sudo lsusb -v' output: sudo lsusb -v Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice3.11 iManufacturer 3 Linux 3.11-1-686-pae ehci_hcd iProduct2 EHCI Host Controller iSerial 1 :00:10.4 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 11 bDescriptorType 41 nNbrPorts 8 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 0x00 PortPwrCtrlMask0xff 0xff Hub Port Status: Port 1: .0100 power Port 2: .0100 power Port 3: .0100 power Port 4: .0100 power Port 5: .0100 power Port 6: .0100 power Port 7: .0100 power Port 8: .0100 power Device Status: 0x0001 Self Powered Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice3.11 iManufacturer 3 Linux 3.11-1-686-pae uhci_hcd iProduct2 UHCI Host Controller iSerial 1 :00:10.3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRem
Re: Need testers for long-standing xHCI clear halt bug
On Mon, Oct 14, 2013 at 04:01:31PM -0700, Sarah Sharp wrote: > On Sat, Oct 12, 2013 at 09:25:17AM +0200, Marcus Meissner wrote: > > Hi Sarah, > > > > I built: > > > > - current kernel git with SUSE config > > - libgphoto2 with the clear_halt reenabled > > - rebooted > > > > gphoto2 now hangs on the second try > > > > - only applied both patches referenced. > > I need to whack them a bit as xhci_giveback_urb_in_irq got a new parameter > > - rebuilt, rebooted > > > > gphoto2 now works on multiple tries. > > > > So the patches seem to fix the issue for my usecase. > > Great! Can you also try it without the second patch? It's not needed, > but I want to double check that the code still works without it. I reverted the second patch and the problem still is fixed. So the second patch is not required for my case. Ciao, Marcus -- 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] uas: Fix uas not working when plugged into an ehci port
Hi,
On 10/18/2013 04:01 PM, Alan Stern wrote:
On Thu, 17 Oct 2013, Hans de Goede wrote:
I thought it would be a good idea to also test uas with usb-2, and it turns out
it ws, as it did not work. The problem is that the uas driver was passing the
bEndpointAddress' direction bit to usb_rcvbulkpipe, the xhci code seems to
not care about this, but with the ehci code this causes usb_submit_urb
failure.
With this fixed the uas code works nicely with an uas device plugged into
an ehci port.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index bf80ef1..078e962 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -957,13 +957,13 @@ static void uas_configure_endpoints(struct uas_dev_info
*devinfo)
eps[3] = usb_pipe_endpoint(udev, devinfo->data_out_pipe);
} else {
devinfo->cmd_pipe = usb_sndbulkpipe(udev,
- eps[0]->desc.bEndpointAddress);
+ eps[0]->desc.bEndpointAddress & 0xf);
devinfo->status_pipe = usb_rcvbulkpipe(udev,
- eps[1]->desc.bEndpointAddress);
+ eps[1]->desc.bEndpointAddress & 0xf);
devinfo->data_in_pipe = usb_rcvbulkpipe(udev,
- eps[2]->desc.bEndpointAddress);
+ eps[2]->desc.bEndpointAddress & 0xf);
devinfo->data_out_pipe = usb_sndbulkpipe(udev,
- eps[3]->desc.bEndpointAddress);
+ eps[3]->desc.bEndpointAddress & 0xf);
Please use usb_endpoint_num() for this.
Thanks for the review, new version coming up.
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
[PATCH 0/1] uas: Fix uas not working when plugged into an ehci port v2
Hi All, Here is v2 of this patch, new in v2: -use usb_endpoint_num() to get the endpoint num, rather then masking ourselves 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
[PATCH] uas: Fix uas not working when plugged into an ehci port
I thought it would be a good idea to also test uas with usb-2, and it turns out
it was, as it did not work. The problem is that the uas driver was passing the
bEndpointAddress' direction bit to usb_rcvbulkpipe, the xhci code seems to not
care about this, but with the ehci code this causes usb_submit_urb failure.
With this fixed the uas code works nicely with an uas device plugged into
an ehci port.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index bf80ef1..58cd005 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -957,13 +957,13 @@ static void uas_configure_endpoints(struct uas_dev_info
*devinfo)
eps[3] = usb_pipe_endpoint(udev, devinfo->data_out_pipe);
} else {
devinfo->cmd_pipe = usb_sndbulkpipe(udev,
- eps[0]->desc.bEndpointAddress);
+usb_endpoint_num(&eps[0]->desc));
devinfo->status_pipe = usb_rcvbulkpipe(udev,
- eps[1]->desc.bEndpointAddress);
+usb_endpoint_num(&eps[1]->desc));
devinfo->data_in_pipe = usb_rcvbulkpipe(udev,
- eps[2]->desc.bEndpointAddress);
+usb_endpoint_num(&eps[2]->desc));
devinfo->data_out_pipe = usb_sndbulkpipe(udev,
- eps[3]->desc.bEndpointAddress);
+usb_endpoint_num(&eps[3]->desc));
}
devinfo->qdepth = usb_alloc_streams(devinfo->intf, eps + 1, 3, 256,
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: ohci-pxa27x: add regulators for usb devices
On 10/18/2013 05:23 PM, Alan Stern wrote:
What happens to ext_regulator[0] if you fail to enable
ext_regulator[1]? Does it remain permanently enabled?
It will be turned off when pxa27x_stop_hc is called.
Ah, I see. You enable regulators only in pxa27x_start_hc() and disable
them only in pxa27x_stop_hc(). The second routine is always called
if the first one succeeds.
Which leads to the question: What happens to usb_regulator if
pxa27x_start_hc() returns early because of a failure in inf->init()?
That is something I missed; good catch. This would be a place to call
regulator_disable_all() (before exiting pxa27x_start_hc).
I'll go over the code again when I resubmit to make sure I covered
everything.
+static void ohci_regulator_put_all(struct pxa27x_ohci *ohci)
+{
+ int i;
+
+ for (i = 0; i < PXA_UHC_MAX_PORTNUM; i++) {
+ if (ohci->ext_regulator[i])
+ regulator_put(ohci->ext_regulator[i]);
+ }
+
+ /* usb regulator should be present if we get here */
+ regulator_put(ohci->usb_regulator);
+}
What happens if you call regulator_put() for an enabled regulator?
It'll remain enabled, but there's not much that can be done about this:
The problem with regulators is that there's no way to tell *why*
they're enabled. The same regulator can supply more than one device,
and thus be turned on by multiple drivers. Because of this there's no
way to tell if corrective measures should be taken before a
regulator_put.
A better question would be: What happens if you call
regulator_disable() after regulator_enable() fails? Does this end up
not mattering?
Depends on the situation. There's a use_count for each regulator which
keeps track of enables(++)/disables(--). The regulator is disabled in
the actual hardware only when use_count == 0.
If nobody succesfully called regulator_enable() (use_count is 0) then
the kernel will warn that there's an unbalanced use of
regulator_enable/disable, and do nothing further with the regulator.
If use_count >= 1 not because of ohci-pxa27x, then we would be messing
with someone else's use of the regulator. From what I've seen, other
drivers don't make an attempt to protect against this possibility.
--
Regards,
Nikita.
--
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: Undetected Fresco Logic FL1000G USB 3.0 controller in Asus N43SN after replace a motherboard
On 2013-08-13 20:38, Greg KH wrote: > On Tue, Aug 13, 2013 at 11:18:24AM +0200, Marcin Zajączkowski wrote: >> Hi, >> >> I had no problem with a USB 3.0 port in my Asus N43SN since I bought a >> laptop (~2 years). Recently I replaced a motherboard to the new one >> (N43SL.413 looks the same as the first one) due to a problem with a >> graphical chipset and after that a USB3 controller stopped to be even >> detected. >> >> $ lspci | grep -i USB >> 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset >> Family USB Enhanced Host Controller #2 (rev 05) >> 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset >> Family USB Enhanced Host Controller #1 (rev 05) >> >> (in the past there was also an additional USB3 controller - AFAIR Fresco >> Logic FL1000G USB 3.0). > > Sounds like a BIOS issue, is there an upgrade for it somewhere? There's > not much the usb driver can do if the PCI controller isn't found > anywhere :( Thanks for your reply. It was a hardware problem. Even in a BIOS updater started from BIOS itself a device in this USB port was ot visible. I had to replace a mother board once again to make it work. Marcin -- 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 problem, FGR not stopped yet!
On Sun, 20 Oct 2013, Teemu Ojansivu wrote: > Somewhere after kernel 3.2.0 my usb started acting weird and not > working correctly. > For example, 'sudo lsusb -v' makes dmesg say: > [ 717.076019] uhci_hcd :00:10.3: FGR not stopped yet! > [ 717.104021] uhci_hcd :00:10.2: FGR not stopped yet! > [ 717.128019] uhci_hcd :00:10.1: FGR not stopped yet! > [ 739.428037] uhci_hcd :00:10.3: FGR not stopped yet! > [ 739.452074] uhci_hcd :00:10.2: FGR not stopped yet! > [ 739.476025] uhci_hcd :00:10.1: FGR not stopped yet! > > That's the only error message I can find related to this problem. If you go back to a 3.2 or earlier kernel, does the same thing happen? My reason for asking is because there haven't been any changes to that part of the driver in a long time -- since well before 3.2. This suggests that something may have happened to your hardware. 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: [alsa-devel] no reset_resume for driver snd-usb-audio for logitech headset H600
On 2013-10-09 11:16 (CEST,UTC+2), Takashi Iwai wrote:
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 9d9de8d..c591a83 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -747,6 +747,7 @@ static struct usb_driver usb_audio_driver = {
.disconnect = usb_audio_disconnect,
.suspend = usb_audio_suspend,
.resume = usb_audio_resume,
+ .reset_resume = usb_audio_resume,
.id_table = usb_audio_ids,
.supports_autosuspend = 1,
};
Shall I add the line in b/sound/usb/card.c and try it? Which kernel version
shall I use?
+ .reset_resume = usb_audio_resume,
Do you need further debugging information?
Thanks, Bernhard
--
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: [alsa-devel] no reset_resume for driver snd-usb-audio for logitech headset H600
At Sun, 20 Oct 2013 23:18:13 +0200,
wrote:
>
> On 2013-10-09 11:16 (CEST,UTC+2), Takashi Iwai wrote:
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index 9d9de8d..c591a83 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -747,6 +747,7 @@ static struct usb_driver usb_audio_driver = {
> .disconnect = usb_audio_disconnect,
> .suspend = usb_audio_suspend,
> .resume = usb_audio_resume,
> +.reset_resume = usb_audio_resume,
> .id_table = usb_audio_ids,
> .supports_autosuspend = 1,
> };
>
> Shall I add the line in b/sound/usb/card.c and try it? Which kernel version
> shall I use?
It doesn't matter which kernel version is.
The error message should disappear, but I don't know whether any other
positive effect you get. As Clemens pointed, there can be some
negative effects by this, so it cannot be taken as is. But at least,
it'd be good to know the result...
thanks,
Takashi
>
> + .reset_resume = usb_audio_resume,
>
> Do you need further debugging information?
>
> Thanks, Bernhard
>
>
--
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: When USB PHY framework should be used?
Dear all, may I please draw your attention to this thread? Thank you, Arokux -- 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 problem, FGR not stopped yet!
On 21 October 2013 00:13, Alan Stern wrote: > On Sun, 20 Oct 2013, Teemu Ojansivu wrote: > >> Somewhere after kernel 3.2.0 my usb started acting weird and not >> working correctly. >> For example, 'sudo lsusb -v' makes dmesg say: >> [ 717.076019] uhci_hcd :00:10.3: FGR not stopped yet! >> [ 717.104021] uhci_hcd :00:10.2: FGR not stopped yet! >> [ 717.128019] uhci_hcd :00:10.1: FGR not stopped yet! >> [ 739.428037] uhci_hcd :00:10.3: FGR not stopped yet! >> [ 739.452074] uhci_hcd :00:10.2: FGR not stopped yet! >> [ 739.476025] uhci_hcd :00:10.1: FGR not stopped yet! >> >> That's the only error message I can find related to this problem. > > If you go back to a 3.2 or earlier kernel, does the same thing happen? > > My reason for asking is because there haven't been any changes to that > part of the driver in a long time -- since well before 3.2. This > suggests that something may have happened to your hardware. > > Alan Stern > Hardware problem was my first guess, but that usb has no such problems on kernel 3.2.0 or older made me believe it was not. No problems in any other operating systems for that matter. I'm on Debian (unstable), could it be something they did? My kernel right now is 3.11, but if I boot into 3.2 usb works perfectly. And the funny thing is, usb memory sticks work normally, just that almost any other device causes problems. -- 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
