Re: Race related to e04a0442d33b "HID: core: remove the absolute need of hid_have_special_driver[]"

Am 14.05.2018 um 11:58 schrieb Benjamin Tissoires: > Hi Heiner, > > On Fri, May 11, 2018 at 12:11 AM, Heiner Kallweit <hkallwe...@gmail.com> > wrote: >> Due to some other issue with one devices supported by hid-led I figured >> out that it's no longer needed t

Race related to e04a0442d33b "HID: core: remove the absolute need of hid_have_special_driver[]"

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

[PATCH v2] usb: dwc2: skip regulator operations if supplies vusb_a and vusb_d are not available

not 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 <hkallwe...@gmail.com> --- v2: - replace the config parameter with an upfront check whether the su

Re: [PATCH] usb: dwc2: introduce config parameter to ignore supplies vusb_a and vusb_d

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: >>>>> S

Re: [PATCH] usb: dwc2: introduce config parameter to ignore supplies vusb_a and vusb_d

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 >

Re: [PATCH] usb: dwc2: introduce config parameter to ignore supplies vusb_a and vusb_d

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 thi

[PATCH] usb: dwc2: introduce config parameter to ignore supplies vusb_a and vusb_d

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 <hkallwe...@gmail.com> --- drivers/usb/dwc2/core.h | 2 ++ drivers/usb/dwc2/params.c | 6 ++ drivers/usb/dwc2/platform.

[PATCH] usb: dwc2: remove deprecated comment in definition of struct dwc2_core_params

Since commit 0a7d0d7fa820 "usb: dwc2: Remove dwc2_set_all_params function" this comment isn't applicable any longer. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/usb/dwc2/core.h | 4 1 file changed, 4 deletions(-) diff --git a/drivers/usb/dwc2/core.h b/

[PATCH] usb: dwc2: eliminate irq parameter from dwc2_hcd_init

The irq is available in hsotg already, so there's no need to pass it as separate function parameter. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/usb/dwc2/core.h | 2 +- drivers/usb/dwc2/hcd.c | 4 ++-- drivers/usb/dwc2/hcd.h | 2 +- drivers/usb/dwc2/plat

Re: [PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

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: Hein

[PATCH v2] usb: dwc2: fix "iomem 0x00000000" message

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 <hkallwe...@gmail.com> --- v2: - get info from hsotg->dev instead of adding a function parameter --- drivers/usb/dwc2/

Re: [PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

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

Re: [PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

Am 17.01.2017 um 21:08 schrieb Heiner Kallweit: > Am 17.01.2017 um 09:11 schrieb Felipe Balbi: >> >> Hi, >> >> Heiner Kallweit <hkallwe...@gmail.com> writes: >>> Am 16.01.2017 um 15:05 schrieb Felipe Balbi: >>>> >>>> Hi, >>&g

[PATCH] usb: dwc2: remove dead function dwc2_pci_quirks

Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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

Re: [PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

Am 17.01.2017 um 09:11 schrieb Felipe Balbi: > > Hi, > > Heiner Kallweit <hkallwe...@gmail.com> writes: >> Am 16.01.2017 um 15:05 schrieb Felipe Balbi: >>> >>> Hi, >>> >>> Heiner Kallweit <hkallwe...@gmail.com> writes: &

Re: [PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

Am 16.01.2017 um 15:05 schrieb Felipe Balbi: > > Hi, > > Heiner Kallweit <hkallwe...@gmail.com> 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 >>

[PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

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 <hkallwe...@gmail.com> --- drivers/usb/dwc2/core.h | 3 ++- drivers/usb/dwc2/hcd.c | 5 - drivers/usb/dwc2

Re: [PATCH v2] hid: hid-led: fix issue with transfer buffer not being dma capable

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

[PATCH v2] hid: hid-led: fix issue with transfer buffer not being dma capable

/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 <hkal

Re: [PATCH] hid: hid-led: fix issue with transfer buffer not being dma capable

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:

[PATCH] hid: hid-led: fix issue with transfer buffer not being dma capable

/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 <hkal

Re: [PATCH] usb: storage: fix runtime pm issue in usb_stor_probe2

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

[PATCH] usb: storage: fix runtime pm issue in usb_stor_probe2

ng the approach from the mentioned commit and getting the runtime pm reference before calling scsi_add_host. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/usb/storage/usb.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/storage/usb.c b/drive

[PATCH v2 1/2] hid: migrate USB LED driver from usb misc to hid

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 <hkallwe...@gmail.com> --- v2: -

Re: [PATCH 1/2] hid: migrate USB LED driver from usb misc to hid

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

[PATCH 2/2] usb: misc: remove outdated USB LED driver

. 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 <hkallwe...@gmail.com> Acked-by: Greg

Re: [PATCH] usb: misc: remove outdated USB LED driver

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: >> >> Del

[PATCH 1/2] hid: migrate USB LED driver from usb misc to hid

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 <hkallwe...@gmail.com> --- drive

Re: [PATCH v2] hid: migrate Riso Kagaku LED driver from USB misc to HID

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

Re: [PATCH v2] hid: migrate Riso Kagaku LED driver from USB misc to HID

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

Re: [PATCH v2] hid: migrate Riso Kagaku LED driver from USB misc to HID

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 it

Re: [PATCH v2] hid: migrate Riso Kagaku LED driver from USB misc to HID

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

[PATCH v2] hid: migrate Dream Cheeky LED driver from USB misc to HID

with a Dream Cheeky Webmail Notifier. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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 +- d

Re: [PATCH] hid: migrate Dream Cheeky LED driver from USB misc to HID

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

Re: [PATCH] hid: migrate Dream Cheeky LED driver from USB misc to HID

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

[PATCH] hid: migrate Dream Cheeky LED driver from USB misc to HID

with a Dream Cheeky Webmail Notifier. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/hid/Kconfig| 8 ++ drivers/hid/Makefile | 1 + drivers/hid/hid-core.c | 6 +- drivers/hid/hid-dream-cheeky.c

[PATCH v2] hid: migrate Riso Kagaku LED driver from USB misc to HID

module, therefore so far allow compilation of the new driver only if the old one is disabled. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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 devic

Re: [PATCH] hid: migrate Riso Kagaku LED driver from USB misc to HID

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 it

Re: [PATCH] hid: migrate Riso Kagaku LED driver from USB misc to HID

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

[PATCH] hid: migrate Riso Kagaku LED driver from USB misc to HID

module, therefore so far allow compilation of the new driver only if the old one is disabled. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/hid/Kconfig| 9 +++ drivers/hid/Makefile | 1 + drivers/hid/hid-core.c | 2 +- drivers/hid/hid-rika.c

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

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

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

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

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

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

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

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 <hkallwe...@gmail.co

[PATCH v8 1/5] leds: core: add generic support for RGB LED's

t 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 <hkallwe...@gmail.com> --- v2

Re: [PATCH v7 1/5] leds: core: add generic support for RGB LED's

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

Re: [PATCH v7 1/5] leds: core: add generic support for RGB LED's

Am 06.03.2016 um 21:55 schrieb Karl Palsson: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Heiner Kallweit <hkallwe...@gmail.com> wrote: >> Add generic support for RGB LED's. >> >> Basic idea is to use enum led_brightness also for the hue and >&g

[PATCH v7 1/5] leds: core: add generic support for RGB LED's

isting 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 <hkallwe...@gmail.com> --- v2: - move

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

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 <hkallwe...@gmail.co

[PATCH v7 3/5] leds: core: add documentation for RGB extension

Document the RGB extension in Documentation/leds/leds-class.txt Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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:

[PATCH v7 2/5] leds: core: add color LED sysfs extension

Extend brightness sysfs property handling to deal with monochrome and color mode as well. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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 c

[PATCH v7 4/5] leds: core: document ABI change for RGB extension

Document the ABI change in Documentation/ABI/testing/sysfs-class-led. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v7: - separated from patch 3 --- Documentation/ABI/testing/sysfs-class-led | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/ABI/t

[PATCH v7 5/5] leds: core: add support for RGB LED's

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 <hkallwe...@gmail.com> --- v2: - move hsv -> rgb conversion to separate file - remove flag LED_DEV_CAP_RGB v3: - call led_hsv_to_rgb only if LED_DE

[PATCH] hid: thingm: change driver to use RGB LED core extension

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 <hkallwe...@gmail.com> --- drivers/hid/hid-thingm.c | 131 +-- 1 file c

[PATCH v6 3/4] leds: core: add documentation for color extension

Document the color extension in Documentation/leds/leds-class.txt Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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: - ad

Re: [PATCH v5 3/4] leds: core: add documentation for color extension

On Wed, Mar 2, 2016 at 9:38 AM, Jacek Anaszewski <j.anaszew...@samsung.com> 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-

[PATCH v5 4/4] leds: core: add support for RGB LED's

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 <hkallwe...@gmail.com> --- v2: - move hsv -> rgb conversion to separate file - remove flag LED_DEV_CAP_RGB v3: - call led_hsv_to_rgb only if LED_DE

[PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

t 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 <hkallwe...@gmail.com> --- v2

[PATCH v5 3/4] leds: core: add documentation for color extension

Document the color extension in Documentation/leds/leds-class.txt Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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 --- Documentatio

[PATCH v5 2/4] leds: core: add color LED sysfs extension

Extend brightness sysfs property handling to deal with monochrome and color mode as well. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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 --- d

Re: [PATCH v3 4/4] leds: core: add support for RGB LED's

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: >>>

[PATCH RESEND2 2/3] usb: core: rename mutex usb_bus_list_lock to usb_bus_idr_lock

Now that usb_bus_list has been removed and switched to idr rename the related mutex accordingly. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/usb/core/devices.c | 6 +++--- drivers/usb/core/hcd.c | 30 +++--- drivers/usb/core/hub.c

Re: [PATCH RESEND 2/3] usb: core: rename mutex usb_bus_list_lock to usb_bus_idr_lock

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 Kal

[PATCH RESEND2 3/3] usb: r8a66597: add locking to r8a66597_check_detect_child

Use mutex usb_bus_idr_lock to protect idr_find. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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

[PATCH RESEND 1/3] usb: core: switch bus numbering to using idr

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 <hkallwe...@gmail.com> --- drivers/usb/core/devices.c | 10 ++ drivers/us

[PATCH RESEND 3/3] usb: r8a66597: add locking to r8a66597_check_detect_child

Use mutex usb_bus_idr_lock to protect idr_find. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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

Re: [PATCH 1/3] usb: core: switch bus numbering to using idr

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

[PATCH 3/3] usb: r8a66597: add locking to r8a66597_check_detect_child

Use mutex usb_bus_idr_lock to protect idr_find. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- 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

[PATCH 1/3] usb: core: switch bus numbering to using idr

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 <hkallwe...@gmail.com> --- drivers/usb/core/devices.c | 10 ++ drivers/us

[PATCH 2/3] usb: core: rename mutex usb_bus_list_lock to usb_bus_idr_lock

Now that usb_bus_list has been removed and switched to idr rename the related mutex accordingly. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/usb/core/devices.c | 6 +++--- drivers/usb/core/hcd.c | 30 +++--- drivers/usb/core/hub.c

[PATCH] usb: chipidea: replace udelay in loops with usleep_range

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 hkallwe...@gmail.com --- drivers/usb/chipidea