On 08.10.2019 22:05, Greg KH wrote:
> On Tue, Oct 08, 2019 at 09:53:16PM +0200, Heiner Kallweit wrote:
>> Since a while I see the following. I didn't bisect yet, maybe issue is
>> caused by
>> 32bca2df7da2 ("usb-storage: export symbols in USB_STORAGE namespace&qu
Since a while I see the following. I didn't bisect yet, maybe issue is caused by
32bca2df7da2 ("usb-storage: export symbols in USB_STORAGE namespace")?
DEPMOD 5.4.0-rc2-next-20191008+
depmod: WARNING:
/lib/modules/5.4.0-rc2-next-20191008+/kernel/drivers/usb/storage/ums-realtek.ko
needs unknow
On 04.01.2019 16:57, Andrew Lunn wrote:
>> I wonder, if I use the phylib functions instead of the ad-hoc ones in
>> the MAC driver, is there still a problem with synchronization ?
>
> You would need to look deep into phylib. When does it reset the PHY?
> Configure auto-neg, setup interrupts, etc?
Am 14.05.2018 um 11:58 schrieb Benjamin Tissoires:
> Hi Heiner,
>
> On Fri, May 11, 2018 at 12:11 AM, Heiner Kallweit
> wrote:
>> Due to some other issue with one devices supported by hid-led I figured
>> out that it's no longer needed to li
Due to some other issue with one devices supported by hid-led I figured
out that it's no longer needed to list devices with own driver in
hid_have_special_driver[].
So I removed the entries for the hid-led devices and got the following.
When I plugged in the device first the device-specific driver
found, using dummy regulator
Therefore introduce an upfront check whether the supplies are available.
If they are not skip all supply regulator operations.
Signed-off-by: Heiner Kallweit
---
v2:
- replace the config parameter with an upfront check whether
the supplies are available and adjust
Am 31.01.2017 um 20:23 schrieb Heiner Kallweit:
> Am 31.01.2017 um 19:48 schrieb John Youn:
>> On 1/30/2017 11:13 PM, Heiner Kallweit wrote:
>>> Am 31.01.2017 um 03:32 schrieb John Youn:
>>>> On 1/28/2017 2:06 PM, Heiner Kallweit wrote:
>>>>> Suppli
Am 31.01.2017 um 19:48 schrieb John Youn:
> On 1/30/2017 11:13 PM, Heiner Kallweit wrote:
>> Am 31.01.2017 um 03:32 schrieb John Youn:
>>> On 1/28/2017 2:06 PM, Heiner Kallweit wrote:
>>>> Supplies for vusb_a and vusb_d are needed only on a minority of systems
>
Am 31.01.2017 um 03:32 schrieb John Youn:
> On 1/28/2017 2:06 PM, Heiner Kallweit wrote:
>> Supplies for vusb_a and vusb_d are needed only on a minority of systems
>> supported by the dwc2 driver (AFAIK systems with Samsung SoCs).
>>
>> On all other systems this re
vusb_a not found, using dummy regulator
Introduce a configuration parameter to ignore the supplies on
systems not needing it.
Signed-off-by: Heiner Kallweit
---
drivers/usb/dwc2/core.h | 2 ++
drivers/usb/dwc2/params.c | 6 ++
drivers/usb/dwc2/platform.c | 30
Since commit 0a7d0d7fa820 "usb: dwc2: Remove dwc2_set_all_params function"
this comment isn't applicable any longer.
Signed-off-by: Heiner Kallweit
---
drivers/usb/dwc2/core.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
Am 25.01.2017 um 22:28 schrieb John Youn:
> On 1/15/2017 12:37 PM, Heiner Kallweit wrote:
>> Set the iomem parameters in the usb_hcd to fix this misleading
>> message during driver load:
>> dwc2 c910.usb: irq 22, io mem 0x
>>
>> Signed-off-by: Heiner
Set the iomem parameters in the usb_hcd to fix this misleading
message during driver load:
dwc2 c910.usb: irq 22, io mem 0x
Signed-off-by: Heiner Kallweit
---
v2:
- get info from hsotg->dev instead of adding a function parameter
---
drivers/usb/dwc2/hcd.c | 7 +++
1 file chan
The irq is available in hsotg already, so there's no need to
pass it as separate function parameter.
Signed-off-by: Heiner Kallweit
---
drivers/usb/dwc2/core.h | 2 +-
drivers/usb/dwc2/hcd.c | 4 ++--
drivers/usb/dwc2/hcd.h | 2 +-
drivers/usb/dwc2/platform.c | 2 +-
4
Am 24.01.2017 um 09:46 schrieb Felipe Balbi:
>
> Hi,
>
> John Youn writes:
>>> John Youn writes:
@@ -1229,7 +1229,8 @@ static inline void dwc2_hcd_connect(struct
dwc2_hsotg *hsotg) {}
static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool
fo
Am 17.01.2017 um 21:08 schrieb Heiner Kallweit:
> Am 17.01.2017 um 09:11 schrieb Felipe Balbi:
>>
>> Hi,
>>
>> Heiner Kallweit writes:
>>> Am 16.01.2017 um 15:05 schrieb Felipe Balbi:
>>>>
>>>> Hi,
>>>>
>>>>
ned-off-by: Heiner Kallweit
---
drivers/usb/dwc2/pci.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
index a23329e3..ae419615 100644
--- a/drivers/usb/dwc2/pci.c
+++ b/drivers/usb/dwc2/pci.c
@@ -62,20 +62,6 @@ struct dwc
Am 17.01.2017 um 09:11 schrieb Felipe Balbi:
>
> Hi,
>
> Heiner Kallweit writes:
>> Am 16.01.2017 um 15:05 schrieb Felipe Balbi:
>>>
>>> Hi,
>>>
>>> Heiner Kallweit writes:
>>>> Set the iomem parameters in the usb_hcd to fix t
Am 16.01.2017 um 15:05 schrieb Felipe Balbi:
>
> Hi,
>
> Heiner Kallweit writes:
>> Set the iomem parameters in the usb_hcd to fix this misleading
>> message during driver load:
>> dwc2 c910.usb: irq 22, io mem 0x0000
>>
>> Signed-off-by: He
Set the iomem parameters in the usb_hcd to fix this misleading
message during driver load:
dwc2 c910.usb: irq 22, io mem 0x
Signed-off-by: Heiner Kallweit
---
drivers/usb/dwc2/core.h | 3 ++-
drivers/usb/dwc2/hcd.c | 5 -
drivers/usb/dwc2/hcd.h | 3 ++-
drivers/usb
Am 07.10.2016 um 18:22 schrieb Benjamin Tissoires:
> On Oct 03 2016 or thereabouts, Heiner Kallweit wrote:
>> The hid-led driver works fine under 4.8.0, however with the next
>> kernel from today I get this:
>>
>> [ cut here ]
>> WARNING
/0x190
[] ? kernel_read_file_from_fd+0x44/0x70
[] SYSC_finit_module+0xba/0xc0
[] SyS_finit_module+0x9/0x10
[] entry_SYSCALL_64_fastpath+0x18/0xad
---[ end trace c9e6ea27003ecf9e ]---
Fix this by using a kmalloc'ed buffer when calling hid_hw_raw_request.
Signed-off-by: Heiner Kallweit
-
Am 03.10.2016 um 20:22 schrieb Alan Stern:
> On Mon, 3 Oct 2016, Heiner Kallweit wrote:
>
>> The hid-led driver works fine under 4.8.0, however with the next
>> kernel from today I get this:
>>
>> [ cut here ]
>> WARNING: CPU: 0 PID:
/0x190
[] ? kernel_read_file_from_fd+0x44/0x70
[] SYSC_finit_module+0xba/0xc0
[] SyS_finit_module+0x9/0x10
[] entry_SYSCALL_64_fastpath+0x18/0xad
---[ end trace c9e6ea27003ecf9e ]---
Fix this by using a kmalloc'ed buffer when calling hid_hw_raw_request.
Signed-off-by: Heiner Kallweit
---
dr
Am 03.08.2016 um 23:25 schrieb Alan Stern:
> On Wed, 3 Aug 2016, Heiner Kallweit wrote:
>
>> Since commit 71723f95463d "PM / runtime: print error when activating a
>> child to unactive parent" I see the following error message:
>>
>> scsi host2: usb-s
he approach from the mentioned commit and getting
the runtime pm reference before calling scsi_add_host.
Signed-off-by: Heiner Kallweit
---
drivers/usb/storage/usb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index ef2
LED subsystem instead of proprietary sysfs entries,
this allows e.g. to use the device with features like triggers
Successfully tested with a Dream Cheeky Webmail Notifier and a
Riso Kagaku Webmail Notifier compatible device.
Signed-off-by: Heiner Kallweit
---
v2:
- change usbled to hidled
Am 17.06.2016 um 10:53 schrieb Benjamin Tissoires:
> Hi Heiner,
>
> On Jun 17 2016 or thereabouts, Heiner Kallweit wrote:
>> This patch migrates the USB LED driver to the HID subsystem.
>> Supported are Dream Cheeky Webmail Notifier / Friends Alert
>> and R
etely.
Riso Kagaku RGB LED + Dream Cheeky Webmail Notifier
These devices are HID compliant and are supported by a new USB LED
driver under drivers/hid utilizing the kernel LED subsystem.
So let's remove the old USB LED driver.
Signed-off-by: Heiner Kallweit
Acked-by: Greg Kroah-Hartman
--
Am 16.06.2016 um 21:13 schrieb Greg Kroah-Hartman:
> On Thu, Jun 16, 2016 at 09:00:50PM +0200, Heiner Kallweit wrote:
>> The USB LED driver exposes a undocumented sysfs interface and doesn't
>> use the standard kernel LED subsystem. It supports three devices:
>>
>>
LED subsystem instead of proprietary sysfs entries,
this allows e.g. to use the device with features like triggers
Successfully tested with a Dream Cheeky Webmail Notifier and a
Riso Kagaku Webmail Notifier compatible device.
Signed-off-by: Heiner Kallweit
---
drivers/hid/Kconfig | 12
etely.
Riso Kagaku RGB LED + Dream Cheeky Webmail Notifier
These devices are HID compliant and will be supported by a new driver
under drivers/hid utilizing the kernel LED subsystem.
So let's remove the USB LED driver.
Signed-off-by: Heiner Kallweit
---
drivers/usb/misc/Kconfig | 9 --
d
Am 16.06.2016 um 09:08 schrieb Greg Kroah-Hartman:
> On Thu, Jun 16, 2016 at 07:45:35AM +0200, Heiner Kallweit wrote:
>> Am 15.06.2016 um 22:59 schrieb Heiner Kallweit:
>>> Am 15.06.2016 um 09:31 schrieb Benjamin Tissoires:
>>>> On Jun 15 2016 or thereabouts, H
Am 15.06.2016 um 22:59 schrieb Heiner Kallweit:
> Am 15.06.2016 um 09:31 schrieb Benjamin Tissoires:
>> On Jun 15 2016 or thereabouts, Heiner Kallweit wrote:
>>> Am 14.06.2016 um 23:49 schrieb Benjamin Tissoires:
>>>> On Jun 12 2016 or thereabouts, Heiner Kallwei
Am 15.06.2016 um 09:31 schrieb Benjamin Tissoires:
> On Jun 15 2016 or thereabouts, Heiner Kallweit wrote:
>> Am 14.06.2016 um 23:49 schrieb Benjamin Tissoires:
>>> On Jun 12 2016 or thereabouts, Heiner Kallweit wrote:
>>>> The Riso Kagaku Webmail Notifier (and its c
Am 14.06.2016 um 23:49 schrieb Benjamin Tissoires:
> On Jun 12 2016 or thereabouts, Heiner Kallweit wrote:
>> The Riso Kagaku Webmail Notifier (and its clones) is supported as part of
>> usb/misc/usbled driver currently. This patch migrates the driver for this
>> device
a Dream Cheeky Webmail Notifier.
Signed-off-by: Heiner Kallweit
---
v2:
- move hid_hw_start after dc_init_device to avoid a potential race
---
drivers/hid/Kconfig| 8 ++
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 6 +-
drivers/hid/hid-dream-cheeky.c
Am 14.06.2016 um 21:57 schrieb Oliver Neukum:
> On Tue, 2016-06-14 at 21:34 +0200, Heiner Kallweit wrote:
>> Am 14.06.2016 um 10:05 schrieb Oliver Neukum:
>>> On Tue, 2016-06-14 at 07:51 +0200, Heiner Kallweit wrote:
>>>
>>>> + ret = hid_hw_start(hde
Am 14.06.2016 um 10:05 schrieb Oliver Neukum:
> On Tue, 2016-06-14 at 07:51 +0200, Heiner Kallweit wrote:
>
>> +ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
>> +if (ret)
>> +return ret;
>> +
>> +minor = ((struct hidraw *) hd
a Dream Cheeky Webmail Notifier.
Signed-off-by: Heiner Kallweit
---
drivers/hid/Kconfig| 8 ++
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 6 +-
drivers/hid/hid-dream-cheeky.c | 177 +
drivers/hid/hid-ids.h
rrent module, therefore so far allow
compilation of the new driver only if the old one is disabled.
Signed-off-by: Heiner Kallweit
---
v2:
- change config symbol from HID_RIKA to HID_RISO_KAGAKU
- use full name Riso Kagaku instead of rika in several places
- don't remove device from igno
Am 03.06.2016 um 10:46 schrieb Benjamin Tissoires:
> On May 28 2016 or thereabouts, Heiner Kallweit wrote:
>> Am 27.05.2016 um 23:45 schrieb Benjamin Tissoires:
>>> On May 27 2016 or thereabouts, Heiner Kallweit wrote:
>>>> The Riso Kagaku Webmail Notifier (and its c
Am 27.05.2016 um 23:45 schrieb Benjamin Tissoires:
> On May 27 2016 or thereabouts, Heiner Kallweit wrote:
>> The Riso Kagaku Webmail Notifier (and its clones) is supported as part of
>> usb/misc/usbled driver currently. This patch migrates the driver for this
>> device
rrent module, therefore so far allow
compilation of the new driver only if the old one is disabled.
Signed-off-by: Heiner Kallweit
---
drivers/hid/Kconfig| 9 +++
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 2 +-
drivers/hid/hid-rika.c
Am 05.04.2016 um 21:45 schrieb Jacek Anaszewski:
> On 04/05/2016 11:01 AM, Pavel Machek wrote:
>> Hi!
>>
>>> It would have the same downsides as in case of having r, g and b in
>>> separate attributes, i.e. - problems with setting LED colour in
>>> a consistent way. This way LED blinkin
On Wed, Mar 30, 2016 at 3:03 PM, Pavel Machek wrote:
> Hi!
>
>> >Ok, so:
>> >
>> >a) Do we want RGB leds to be handled by existing subsystem, or do we
>> >need separate layer on top of that?
>> >
>> >b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
>> >and it is what hardware
Am 29.03.2016 um 23:43 schrieb Pavel Machek:
> Hi!
>
>>> First, please Cc me on RGB color support.
>>>
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation
color components.This allows to implement the color extension
Am 29.03.2016 um 12:05 schrieb Pavel Machek:
> On Tue 2016-03-01 22:36:12, Heiner Kallweit wrote:
>> Export a function to convert HSV color values to RGB.
>> It's intended to be called by drivers for RGB LEDs.
>>
>> Signed-off-by: Heiner Kallweit
>> ---
>
Am 29.03.2016 um 12:02 schrieb Pavel Machek:
> Hi!
>
> First, please Cc me on RGB color support.
>
>> Add generic support for RGB Color LED's.
>>
>> Basic idea is to use enum led_brightness also for the hue and saturation
>> color components.This allows to implement the color extension w/o
>> cha
ff but keep existing color so that it can be restored
if the LED is switched on again later
0x100 -> switch LED off and set also hue and saturation to 0
0x00 -> set full brightness, full saturation and set hue to 0 (red)
Signed-off-by: Heiner Kallweit
---
v2:
- move extension-spe
Am 11.03.2016 um 09:38 schrieb Jacek Anaszewski:
> Hi Heiner,
>
> Thanks for the updated set. I've renamed the feature to RGB LED class
> and pushed out to devel branch of linux-leds.git. It will sit there
> till the end of the upcoming merge window. There have been some
> uncertainties raised rel
Am 06.03.2016 um 21:55 schrieb Karl Palsson:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Heiner Kallweit wrote:
>> Add generic support for RGB LED's.
>>
>> Basic idea is to use enum led_brightness also for the hue and
>> saturation color comp
ep existing color so that it can be restored
if the LED is switched on again later
0x100 -> switch LED off and set also hue and saturation to 0
0x00 -> set full brightness, full saturation and set hue to 0 (red)
Signed-off-by: Heiner Kallweit
---
v2:
- move extension-specific cod
Extend brightness sysfs property handling to deal with monochrome
and color mode as well.
Signed-off-by: Heiner Kallweit
---
v2:
- split from patch 1
v3:
- moved one change (led_is_off) to patch 1
v4:
- changed printf format string to %#.6x
v5:
- no changes
v6:
- no changes
v7:
- no changes
Document the RGB extension in Documentation/leds/leds-class.txt
Signed-off-by: Heiner Kallweit
---
v2:
- introduced to patch series
v3:
- document extension in more detail
v4:
- Better explain why flag LED_SET_HUE_SAT is needed
v5:
- no changes
v6:
- no changes
v7:
- move Documentation/ABI
Am 04.03.2016 um 10:05 schrieb Jacek Anaszewski:
> On 03/01/2016 10:36 PM, Heiner Kallweit wrote:
>> Export a function to convert HSV color values to RGB.
>> It's intended to be called by drivers for RGB LEDs.
>>
>> Signed-off-by: Heiner Kallweit
>> ---
>
Document the ABI change in Documentation/ABI/testing/sysfs-class-led.
Signed-off-by: Heiner Kallweit
---
v7:
- separated from patch 3
---
Documentation/ABI/testing/sysfs-class-led | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-led
b
Export a function to convert HSV color values to RGB.
It's intended to be called by drivers for RGB LEDs.
Signed-off-by: Heiner Kallweit
---
v2:
- move hsv -> rgb conversion to separate file
- remove flag LED_DEV_CAP_RGB
v3:
- call led_hsv_to_rgb only if LED_DEV_CAP_HSV is set
This i
parts as either
you use the RGB LED extension or not. However this shouldn't be really
an issue as the resulting code is relatively short and simple.
Signed-off-by: Heiner Kallweit
---
drivers/hid/hid-thingm.c | 131 +--
1 file changed, 36 inserti
Document the color extension in Documentation/leds/leds-class.txt
Signed-off-by: Heiner Kallweit
---
v2:
- introduced to patch series
v3:
- document extension in more detail
v4:
- Better explain why flag LED_SET_HUE_SAT is needed
v5:
- no changes
v6:
- add docu for this feature to Documentation
On Wed, Mar 2, 2016 at 9:38 AM, Jacek Anaszewski
wrote:
> On 03/01/2016 10:41 PM, Greg KH wrote:
>>
>> On Tue, Mar 01, 2016 at 10:29:31PM +0100, Heiner Kallweit wrote:
>>>
>>> Document the color extension in Documentation/leds/leds-class.txt
>>>
>>
ff but keep existing color so that it can be restored
if the LED is switched on again later
0x100 -> switch LED off and set also hue and saturation to 0
0x00 -> set full brightness, full saturation and set hue to 0 (red)
Signed-off-by: Heiner Kallweit
---
v2:
- move extension-spe
Document the color extension in Documentation/leds/leds-class.txt
Signed-off-by: Heiner Kallweit
---
v2:
- introduced to patch series
v3:
- document extension in more detail
v4:
- Better explain why flag LED_SET_HUE_SAT is needed
v5:
- no changes
---
Documentation/leds/leds-class.txt | 27
Extend brightness sysfs property handling to deal with monochrome
and color mode as well.
Signed-off-by: Heiner Kallweit
---
v2:
- split from patch 1
v3:
- moved one change (led_is_off) to patch 1
v4:
- changed printf format string to %#.6x
v5:
- no changes
---
drivers/leds/led-class.c | 7
Export a function to convert HSV color values to RGB.
It's intended to be called by drivers for RGB LEDs.
Signed-off-by: Heiner Kallweit
---
v2:
- move hsv -> rgb conversion to separate file
- remove flag LED_DEV_CAP_RGB
v3:
- call led_hsv_to_rgb only if LED_DEV_CAP_HSV is set
This i
Am 29.02.2016 um 10:57 schrieb Jacek Anaszewski:
> On 02/26/2016 11:36 PM, Heiner Kallweit wrote:
>> Am 25.02.2016 um 13:40 schrieb Jacek Anaszewski:
>>> On 02/23/2016 09:27 PM, Heiner Kallweit wrote:
>>>> Am 19.02.2016 um 14:59 schrieb Jacek Anaszewski:
>>>
Use mutex usb_bus_idr_lock to protect idr_find.
Signed-off-by: Heiner Kallweit
---
drivers/usb/host/r8a66597-hcd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index 1ef8873..bfa7fa3 100644
--- a/drivers/usb/host
Now that usb_bus_list has been removed and switched to idr
rename the related mutex accordingly.
Signed-off-by: Heiner Kallweit
---
drivers/usb/core/devices.c | 6 +++---
drivers/usb/core/hcd.c | 30 +++---
drivers/usb/core/hub.c | 4 ++--
drivers/usb/mon
Am 03.02.2016 um 22:28 schrieb Greg Kroah-Hartman:
> On Mon, Jan 25, 2016 at 08:31:21PM +0100, Heiner Kallweit wrote:
>> Now that usb_bus_list has been removed and switched to idr
>> rename the related mutex accordingly.
>>
>> Signed-off-by: Heiner Kallweit
>> -
Am 25.01.2016 um 06:02 schrieb Greg Kroah-Hartman:
> On Tue, Dec 22, 2015 at 09:22:09PM +0100, Heiner Kallweit wrote:
>> USB bus numbering is based on directly dealing with bitmaps and
>> defines a separate list of busses.
>> This can be simplified and unified by using exist
USB bus numbering is based on directly dealing with bitmaps and
defines a separate list of busses.
This can be simplified and unified by using existing idr functionality.
Signed-off-by: Heiner Kallweit
---
drivers/usb/core/devices.c | 10 ++
drivers/usb/core/hcd.c | 21
Now that usb_bus_list has been removed and switched to idr
rename the related mutex accordingly.
Signed-off-by: Heiner Kallweit
---
drivers/usb/core/devices.c | 6 +++---
drivers/usb/core/hcd.c | 30 +++---
drivers/usb/core/hub.c | 4 ++--
drivers/usb/mon
Use mutex usb_bus_idr_lock to protect idr_find.
Signed-off-by: Heiner Kallweit
---
drivers/usb/host/r8a66597-hcd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index 1ef8873..bfa7fa3 100644
--- a/drivers/usb/host
Use mutex usb_bus_idr_lock to protect idr_find.
Signed-off-by: Heiner Kallweit
---
drivers/usb/host/r8a66597-hcd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index 1ef8873..bfa7fa3 100644
--- a/drivers/usb/host
USB bus numbering is based on directly dealing with bitmaps and
defines a separate list of busses.
This can be simplified and unified by using existing idr functionality.
Signed-off-by: Heiner Kallweit
---
drivers/usb/core/devices.c | 10 ++
drivers/usb/core/hcd.c | 21
Now that usb_bus_list has been removed and switched to idr
rename the related mutex accordingly.
Signed-off-by: Heiner Kallweit
---
drivers/usb/core/devices.c | 6 +++---
drivers/usb/core/hcd.c | 30 +++---
drivers/usb/core/hub.c | 4 ++--
drivers/usb/mon
Both delays are at the lower end of where the use of usleep_range
is recommended. However as both udelay's occur in loops I think it
makes sense to replace them with sleeping equivalents to avoid
longer busy-waits.
Signed-off-by: Heiner Kallweit
---
drivers/usb/chipidea/core.c | 2 +-
dr
77 matches
Mail list logo
