Re: [PATCH] Input: stmpe-ts - enforce device tree only mode

Am 23.05.2015 um 00:58 schrieb Dmitry Torokhov: The STMPE MFD is only used with device tree configured systems (and STMPE MFD core depends on OF), so force the configuration to come from device tree only. Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com --- Not tested as no

Re: [PATCH -next] gpio: generic: Revert to old error handling in bgpio_map

ould be checked as early as possible (in bgpio_dev_probe instead of bgpio_setup_io). But that's something I'd consider to be more or less cosmetic. > Fixes: cf3f2a2c8bae ("gpio: generic: improve error handling in bgpio_map") > Cc: Heiner Kallweit <hkallwe...@gmail.com> > Sig

Re: [RFC][PATCH] spi: Setup the master controller driver before setting the chipselect

On Wed, Oct 14, 2015 at 1:08 PM, Andy Shevchenko wrote: > +Cc: Jarkko to see from spi-pxa2xx prospective > > On Wed, Oct 14, 2015 at 12:47 PM, Ivan T. Ivanov wrote: >> Adding Andy. >> >> >>> On Oct 13, 2015, at 12:01 AM, Franklin S Cooper Jr

Re: [PATCH v5 08/10] spi: expose master transfer size limitation.

Am 01.12.2015 um 20:58 schrieb Mark Brown: > On Tue, Dec 01, 2015 at 04:51:06PM -, Michal Suchanek wrote: >> On some SPI controllers it is not feasible to transfer arbitrary amount >> of data at once. >> >> When the limit on transfer size is a few kilobytes at least it makes >> sense to use

Re: [PATCH v4 7/7] mtd: spi-nor: add read loop

Am 20.11.2015 um 00:39 schrieb Brian Norris: > + Heiner > > On Fri, Aug 14, 2015 at 09:23:09AM -, Michal Suchanek wrote: >> mtdblock and ubi do not handle the situation when read returns less data >> than requested. Loop in spi-nor until buffer is filled or an error is >> returned. > > I'm

Re: [PATCH 4/4] HID: remove ThingM blink(1) driver

Am 22.06.2016 um 15:25 schrieb Jiri Kosina: > On Tue, 21 Jun 2016, Heiner Kallweit wrote: > >> Now that support for ThingM blink(1) was merged into the hid-led driver >> the dedicated driver for this device can be removed. >> >> Signed-off-by: Heiner

Re: [PATCH 4/4] HID: remove ThingM blink(1) driver

Am 22.06.2016 um 17:42 schrieb Vivien Didelot: > Hi, > > Jiri Kosina <ji...@kernel.org> writes: > >> On Tue, 21 Jun 2016, Heiner Kallweit wrote: >> >>> Now that support for ThingM blink(1) was merged into the hid-led driver >>> the dedicated drive

log spammed with "loading xx failed with error -2" since commit e40ba6d56b [replace call to fw_read_file_contents() with kernel version]

Since this commit my system log is spammed with firmware load errors. One example: loading /lib/firmware/updates/4.5.0-rc5-next-20160226/iwlwifi-3160-16.ucode failed with error -2 loading /lib/firmware/updates/iwlwifi-3160-16.ucode failed with error -2 loading

[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 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 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 1/3] leds: triggers: add support for RGB triggers

Am 17.03.2016 um 14:41 schrieb Jacek Anaszewski: > Hi Heiner, > > On 03/13/2016 06:14 PM, Heiner Kallweit wrote: >> Add basic support for RGB triggers. Triggers with flag LED_TRIG_CAP_RGB >> set are available to RGB LED devices only. >> >> Signed-off-by: Hein

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 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 1/3] leds: triggers: add support for RGB triggers

Am 22.03.2016 um 09:05 schrieb Jacek Anaszewski: > On 03/21/2016 06:34 PM, Heiner Kallweit wrote: >> Am 21.03.2016 um 16:35 schrieb Jacek Anaszewski: >>> On 03/19/2016 08:11 PM, Heiner Kallweit wrote: >>>> Am 18.03.2016 um 14:10 schrieb Jacek Anaszewski: >&g

Re: [PATCH 1/3] leds: triggers: add support for RGB triggers

Am 22.03.2016 um 17:00 schrieb Jacek Anaszewski: > On 03/22/2016 12:47 PM, Heiner Kallweit wrote: >> Am 22.03.2016 um 09:05 schrieb Jacek Anaszewski: >>> On 03/21/2016 06:34 PM, Heiner Kallweit wrote: >>>> Am 21.03.2016 um 16:35 schrieb Jacek Anaszewski: >&g

Re: [PATCH 1/3] leds: triggers: add support for RGB triggers

Am 23.03.2016 um 09:32 schrieb Jacek Anaszewski: > On 03/22/2016 11:06 PM, Heiner Kallweit wrote: >> Am 22.03.2016 um 17:00 schrieb Jacek Anaszewski: >>> On 03/22/2016 12:47 PM, Heiner Kallweit wrote: >>>> Am 22.03.2016 um 09:05 schrieb Jacek Anaszewski: >&g

Re: [PATCH 1/3] leds: triggers: add support for RGB triggers

Am 24.03.2016 um 14:23 schrieb Jacek Anaszewski: > On 03/23/2016 05:36 PM, Heiner Kallweit wrote: >> Am 23.03.2016 um 17:02 schrieb Jacek Anaszewski: >>> On 03/23/2016 12:57 PM, Heiner Kallweit wrote: >>>> Am 23.03.2016 um 09:32 schrieb Jacek Anaszewski: >&g

[PATCH v2 2/3] leds: triggers: add led_trigger_range_event for RGB triggers

Add led_trigger_range_event() and supporting struct led_rgb_range allowing to map a value within a value range to a color within a color range. Simple example would be to map a temperature with in a range to a color between green and red. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.

[PATCH v2 1/3] leds: triggers: add support for RGB triggers

Add basic support for RGB triggers. Triggers with flag LED_TRIG_CAP_RGB set are available to RGB LED devices only. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - renamed check to led_trigger_is_supported() - removed unrelated other change --- drivers/leds/led-triggers.

[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 1/3] leds: triggers: add support for RGB triggers

Am 21.03.2016 um 16:35 schrieb Jacek Anaszewski: > On 03/19/2016 08:11 PM, Heiner Kallweit wrote: >> Am 18.03.2016 um 14:10 schrieb Jacek Anaszewski: >>> On 03/17/2016 08:53 PM, Heiner Kallweit wrote: >>>> Am 17.03.2016 um 14:41 schrieb Jacek Anaszewski: >>>

Re: [PATCH 1/3] leds: triggers: add support for RGB triggers

Am 23.03.2016 um 17:02 schrieb Jacek Anaszewski: > On 03/23/2016 12:57 PM, Heiner Kallweit wrote: >> Am 23.03.2016 um 09:32 schrieb Jacek Anaszewski: >>> On 03/22/2016 11:06 PM, Heiner Kallweit wrote: >>>> Am 22.03.2016 um 17:00 schrieb Jacek Anaszewski: >&g

Re: [PATCH 3/3] leds: triggers: heartbeat: add RGB version of the trigger

on a single CPU system but more or less idle on a 64 CPU system. Regards, Heiner > > Best regards, > Jacek Anaszewski > > On 03/13/2016 06:18 PM, Heiner Kallweit wrote: >> Add a RGB version of the heartbeat trigger (heartbeat-rgb). This version of >> the trig

[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

[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

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

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

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

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

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

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 1/3] leds: triggers: add support for RGB triggers

Am 18.03.2016 um 14:10 schrieb Jacek Anaszewski: > On 03/17/2016 08:53 PM, Heiner Kallweit wrote: >> Am 17.03.2016 um 14:41 schrieb Jacek Anaszewski: >>> Hi Heiner, >>> >>> On 03/13/2016 06:14 PM, Heiner Kallweit wrote: >>>> Add basic support for R

Re: IR remote stopped working in kernels 4.5 and 4.6

Am 04.07.2016 um 22:36 schrieb James Bottomley: > This looks to be a problem with the rc subsystem. The IR controller in > question is part of a cx8800 atsc card. In the 4.4 kernel, where it > works, this is what ir-keytable says: > > Found /sys/class/rc/rc0/ (/dev/input/event12) with: >

Re: IR remote stopped working in kernels 4.5 and 4.6

Am 04.07.2016 um 23:18 schrieb James Bottomley: > On Mon, 2016-07-04 at 23:08 +0200, Heiner Kallweit wrote: >> Am 04.07.2016 um 22:36 schrieb James Bottomley: >>> This looks to be a problem with the rc subsystem. The IR >>> controller in question is part of a c

Optional regulators in bulk operations - reverted patch

Hi Bjorn, I just came across a use case where I wanted to deal with optional regulators in bulk operations. I was about to submit a related patch when I saw that you submitted basically the same in 3ff3f518a135 "regulator: Make bulk API support optional supplies" and reverted it later stating

Re: Optional regulators in bulk operations - reverted patch

Am 31.01.2017 um 22:43 schrieb Heiner Kallweit: > Hi Bjorn, > > I just came across a use case where I wanted to deal with optional > regulators in bulk operations. I was about to submit a related > patch when I saw that you submitted basically the same in > 3ff3f518a135 "r

[PATCH] genirq: devres: use dev_name(dev) as default for devname

Allow the devname parameter to be NULL and use dev_name(dev) in this case. This should be an appropriate default for most use cases. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- kernel/irq/devres.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/

[PATCH 5/6] leds: gpio: switch to managed version of led_classdev_register

Using the managed version of led_classdev_register allows to significantly simplify the code. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/leds/leds-gpio.c | 23 ++- 1 file changed, 2 insertions(+), 21 deletions(-) diff --git a/drivers/leds/leds-gp

[PATCH 6/6] leds: gpio: fix and simplify error handling in gpio_leds_create

Simplify the error handling and add a missing call to fwnode_handle_put when checking led.name. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/leds/leds-gpio.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/leds/leds-gpio.c b/d

[PATCH 4/6] leds: gpio: fix and simplify reading property "label"

Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/leds/leds-gpio.c | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c index 171ba2f..00a24e3 100644 --- a/drivers/leds/leds-gpio.c +++ b/d

[PATCH 3/6] leds: gpio: simplify gpio_leds_create

Definition of np can be moved into the loop as well to simplify the code a little. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/leds/leds-gpio.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c

[PATCH 1/6] leds: gpio: fix an unhandled error case in create_gpio_led

gpiod_get_value_cansleep returns 0, 1, or an error code. So far errors are not handled and treated the same as 1. Change this to bail out if an error code is returned and remove the double negation. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/leds/leds-gpio

[PATCH 2/6] leds: gpio: add helper cdev_to_gpio_led_data

Add a helper for the container_of as it's used more than once. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/leds/leds-gpio.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c index 1

[PATCH v2 2/7] leds: gpio: fix an unhandled error case in create_gpio_led

gpiod_get_value_cansleep returns 0, 1, or an error code. So far errors are not handled and treated the same as 1. Change this to bail out if an error code is returned and remove the double negation. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - rebased due to removal of p

[PATCH v2 1/7] leds: gpio: introduce gpio_blink_set_t

Introduce a typedef gpio_blink_set_t to improve readability of the code. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - no change --- drivers/leds/leds-gpio.c | 6 ++ include/linux/leds.h | 9 ++--- 2 files changed, 8 insertions(+), 7 deletions(-) diff

[PATCH v2 3/7] leds: gpio: add helper cdev_to_gpio_led_data

Add a helper for the container_of as it's used more than once. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff

[PATCH v2 7/7] leds: gpio: fix and simplify error handling in gpio_leds_create

Simplify the error handling and add a missing call to fwnode_handle_put when checking led.name. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 12 1 file changed, 4 inse

[PATCH v2 6/7] leds: gpio: switch to managed version of led_classdev_register

Using the managed version of led_classdev_register allows to significantly simplify the code. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 23 ++- 1 file chan

[PATCH v2 4/7] leds: gpio: simplify gpio_leds_create

Definition of np can be moved into the loop as well to simplify the code a little. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)

[PATCH v2 5/7] leds: gpio: fix and simplify reading property "label"

Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - rebased due to removal of patch 2 of the original series --- drivers/leds/leds-gpio.c | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c index

Re: [PATCH] hid-led.c: remove unneccessary underscores

Am 07.10.2016 um 18:25 schrieb Benjamin Tissoires: > On Oct 03 2016 or thereabouts, Pavel Machek wrote: >> On Mon 2016-10-03 10:16:26, Pavel Machek wrote: >>> >>> u8 (and friends) can be used directly in kernel sources (not kernel >>> headers). >>> >>> Signed-off-by: Pavel Machek >>

Merge problem: Re: Applied "spi: fsl-espi: avoid processing uninitalized data on error" to the spi tree

Am 26.10.2016 um 12:15 schrieb Mark Brown: > The patch > >spi: fsl-espi: avoid processing uninitalized data on error > > has been applied to the spi tree at > >git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git > > All being well this means that it will be integrated into

Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error

Am 24.10.2016 um 19:27 schrieb Mark Brown: > On Tue, Oct 18, 2016 at 12:13:38AM +0200, Arnd Bergmann wrote: >> When we get a spurious interrupt in fsl_espi_irq, we end up >> processing four uninitalized bytes of data, as shown in this >> warning message: > > This doesn't apply against current

Re: [PATCH v3 0/6] Add support for IR transmitters

Am 02.11.2016 um 11:40 schrieb Andi Shyti: > Hi, > > The main goal is to add support in the rc framework for IR > transmitters, which currently is only supported by lirc but that > is not the preferred way. > > The last patch adds support for an IR transmitter driven by > the MOSI line of an SPI

Re: linux-next: build warning after merge of the rtc tree

Am 06.07.2017 um 06:24 schrieb Stephen Rothwell: > Hi Alexandre, > > After merging the rtc tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > drivers/rtc/rtc-ds1307.c: In function 'ds1307_get_time': > drivers/rtc/rtc-ds1307.c:342:26: warning: unused variable

[PATCH] nvmem: core: change of_property_read_bool to device_property_present in nvmem_register

When checking for property "read-only" it's better to use the more generic device_property_present as in addition to device tree nodes it also covers other node types like ACPI nodes. In addition switch to a logical or. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --

Why does callback irq_startup in struct irq_chip return _unsigned_ int ?

Hi Thomas, just by chance I noticed that callback irq_startup in struct irq_chip returns an unsigned int. This doesn't seem to make sense as the result is a normal retval which is casted to a signed int in function irq_startup() anyway. Is there any specific reason for this or is it simply a

Re: [PATCH] mmc:dw_mmc-k3: add sd support for hi3660

Am 16.05.2017 um 14:26 schrieb liwei: > Add sd card support for hi3660 soc > > Signed-off-by: Li Wei > Signed-off-by: Chen Jun > --- > drivers/mmc/host/dw_mmc-k3.c | 311 > +++ > 1 file changed, 311

Re: linux-next: build failure after merge of the rtc tree

Am 31.05.2017 um 06:33 schrieb Stephen Rothwell: > Hi Alexandre, > > After merging the rtc tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > drivers/rtc/rtc-ds1307.c: In function 'ds1307_probe': > drivers/rtc/rtc-ds1307.c:1410:29: error: 'struct ds1307' has no

Re: [PATCH 1/3] nvmem: core: remove member users from struct nvmem_device

Am 07.06.2017 um 17:30 schrieb Srinivas Kandagatla: > > > On 04/06/17 12:01, Heiner Kallweit wrote: >> Member users is used only to check whether we're allowed to remove >> the module. So in case of built-in it's not used at all and in case > > nvmem providers doe

Re: [PATCH] nvmem: core: add managed version of nvmem_register

Am 07.06.2017 um 18:19 schrieb Srinivas Kandagatla: > > On 04/06/17 12:06, Heiner Kallweit wrote: >> Add a device-managed version of nvmem_register. >> >> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> >> --- >> Documentation/nvmem/nvmem.txt | 1

Re: [PATCH] nvmem: core: add managed version of nvmem_register

Am 08.06.2017 um 08:26 schrieb Srinivas Kandagatla: > > > On 07/06/17 22:55, Heiner Kallweit wrote: >> Am 07.06.2017 um 18:19 schrieb Srinivas Kandagatla: >>> >>> On 04/06/17 12:06, Heiner Kallweit wrote: >>>> Add a device-managed version of nv

[PATCH 1/3] nvmem: core: remove member users from struct nvmem_device

users isn't needed. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/nvmem/core.c | 16 1 file changed, 16 deletions(-) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 8c830a80..4e07f3f8 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/

[PATCH 3/3] nvmem: core: remove nvmem_mutex

Mutex nvmem_mutex is used in __nvmem_device_get only and isn't needed due to: - of_nvmem_find just calls bus_find_device which doesn't need locking - nvmem_find_cell is protected by nvmem_cells_mutex Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/nvmem/core.

[PATCH 2/3] nvmem: core: add locking to nvmem_find_cell

Adding entries to nvmem_cells and deleting entries from it is protected by nvmem_cells_mutex. Therefore this mutex should also protect iterating over the list. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/nvmem/core.c | 8 +++- 1 file changed, 7 insertions(+), 1 de

[PATCH] nvmem: core: add managed version of nvmem_register

Add a device-managed version of nvmem_register. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- Documentation/nvmem/nvmem.txt | 1 + drivers/nvmem/core.c | 35 +++ include/linux/nvmem-provider.h | 7 +++ 3 files changed, 43 inse

[PATCH 0/3] nvmem: core: series with smaller refactorings

Series with smaller refactorings of the nvmem core. Heiner Kallweit (3): nvmem: core: remove member users from struct nvmem_device nvmem: core: add locking to nvmem_find_cell nvmem: core: remove nvmem_mutex drivers/nvmem/core.c | 37 + 1 file changed, 9

[PATCH] genirq: fix error path in __setup_irq

If __irq_set_trigger() fails irq_request_resources() was successfully called before. Therefore we should release all potentially claimed resources in the error path. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- kernel/irq/manage.c | 4 +++- 1 file changed, 3 insertions

Re: [PATCH] eeprom: at24: fix the magic value for at24mac402

Am 27.11.2017 um 13:28 schrieb Bartosz Golaszewski: > There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down > the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6, > making it impossible to read it all. > > Fix it by creating the magic value manually with the

Re: [PATCH] eeprom: at24: correctly set the size for at24mac402

Am 28.11.2017 um 13:09 schrieb Andy Shevchenko: > On Mon, Nov 27, 2017 at 11:06 PM, Bartosz Golaszewski wrote: >> There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down >> the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6, >> making it impossible

Re: [PATCH] add missing "source" line for firmware subdirectory in drivers/Kconfig

Am 28.11.2017 um 18:09 schrieb Randy Dunlap: > On 11/27/2017 11:12 PM, Heiner Kallweit wrote: >> I have a little bit of a hard time to find the right addressee for >> this patch because there is no maintainer entry for drivers/firmware. >> Can you apply the following through

[PATCH] nvmem: core: let stride and word_size default to 1

If the caller doesn't set stride and/or word_size in struct nvmem_config then nvmem_register accepts this but we may face strange effects later due to both values being 0. Therefore use 1 as default for both values. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/nvmem/

[PATCH] add missing "source" line for firmware subdirectory in drivers/Kconfig

I have a little bit of a hard time to find the right addressee for this patch because there is no maintainer entry for drivers/firmware. Can you apply the following through your tree? Add missing entry for firmware subdirectory in drivers/Kconfig. Signed-off-by: Heiner Kallweit <hkal

[PATCH] nvmem: core: switch to device_property_present for reading property "read-only"

Switch to more generic device_property_present to consider also non-DT properties. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/nvmem/core.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 5a5

[PATCH v4 0/3] i2c: introduce devm_i2c_new_dummy and use it in at24 driver

doc comments - add Reviewed-by Heiner Kallweit (3): i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy i2c: core: add device-managed version of i2c_new_dummy eeprom: at24: switch to device-managed version of i2c_new_dummy Documentation/driver-model/devres.txt | 3

[PATCH v4 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

with detailed error codes within the i2c core or for API extensions. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> Reviewed-by: Bartosz Golaszewski <b...@bgdev.pl> --- v3: - prefix i2c_new_device and i2c_new_dummy with two underscores instead one v4: - add missing kernel doc -

[PATCH v4 3/3] eeprom: at24: switch to device-managed version of i2c_new_dummy

Make use of recently introduced device-managed version of i2c_new_dummy to simplify the code. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> Reviewed-by: Bartosz Golaszewski <b...@bgdev.pl> --- v2: - small improvements regarding code readability v3: - no changes v4:

[PATCH v4 2/3] i2c: core: add device-managed version of i2c_new_dummy

case return value type: i2c_new_dummy returns NULL whilst devm_new_i2c_dummy returns an ERR_PTR. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> Reviewed-by: Bartosz Golaszewski <b...@bgdev.pl> --- v2: - use new function _i2c_new_dummy with detailed error codes v3: - no changes v

Re: [PATCH v4 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

Am 15.12.2017 um 23:02 schrieb Bartosz Golaszewski: > 2017-12-15 18:43 GMT+01:00 Heiner Kallweit <hkallwe...@gmail.com>: >> Currently i2c_new_device and i2c_new_dummy return just NULL in error >> case although they have more error details internally. Therefore move >>

[PATCH v5 0/3] i2c: introduce devm_i2c_new_dummy and use it in at24 driver

doc comments - add Reviewed-by Changes in v5: - fix a copy & paste error in patch 1 - improve readability in patch 2 Heiner Kallweit (3): i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy i2c: core: add device-managed version of i2c_new_dummy eeprom: at24: sw

[PATCH v5 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

with detailed error codes within the i2c core or for API extensions. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> Reviewed-by: Bartosz Golaszewski <b...@bgdev.pl> --- v3: - prefix i2c_new_device and i2c_new_dummy with two underscores instead one v4: - add missing kernel doc -

[PATCH v5 3/3] eeprom: at24: switch to device-managed version of i2c_new_dummy

Make use of recently introduced device-managed version of i2c_new_dummy to simplify the code. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - small improvements regarding code readability v3: - no changes v4: - no changes v5: - no changes --- drivers/misc/eeprom/at24.

[PATCH v5 2/3] i2c: core: add device-managed version of i2c_new_dummy

case return value type: i2c_new_dummy returns NULL whilst devm_new_i2c_dummy returns an ERR_PTR. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - use new function _i2c_new_dummy with detailed error codes v3: - no changes v4: - reflect renaming to __i2c_new_dummy v5: - i

[PATCH v3 0/3] i2c: introduce devm_i2c_new_dummy and use it in at24 driver

the first user of the new function. Changes in v2: - add change to i2c core to make a version of i2c_new_device available which returns an ERR_PTR instead of NULL in error case - few minor improvements Changes in v3: - rename _i2c_new_device to __i2c_new_device Heiner Kallweit (3): i2c: core

[PATCH v3 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

with detailed error codes within the i2c core or for API extensions. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v3: - prefix i2c_new_device and i2c_new_dummy with two underscores instead one --- drivers/i2c/i2c-core-base.c | 46 -

[PATCH v3 3/3] eeprom: at24: switch to device-managed version of i2c_new_dummy

Make use of recently introduced device-managed version of i2c_new_dummy to simplify the code. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - small improvements regarding code readability v3: - no changes --- drivers/misc/eeprom/at24.c | 31 +++

[PATCH v3 2/3] i2c: core: add device-managed version of i2c_new_dummy

case return value type: i2c_new_dummy returns NULL whilst devm_new_i2c_dummy returns an ERR_PTR. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - use new function _i2c_new_dummy with detailed error codes v3: - no changes --- Documentation/driver-model/devres.txt | 3 +++ d

[PATCH v6 0/3] i2c: introduce devm_i2c_new_dummy and use it in at24 driver

doc comments - add Reviewed-by Changes in v5: - fix a copy & paste error in patch 1 - improve readability in patch 2 Changes in v5: - cosmetic change in patch 1 - patch 3 rebased on top of latest at24/for-next Heiner Kallweit (3): i2c: core: improve return value handling of i2c_new_de

[PATCH v6 2/3] i2c: core: add device-managed version of i2c_new_dummy

case return value type: i2c_new_dummy returns NULL whilst devm_new_i2c_dummy returns an ERR_PTR. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - use new function _i2c_new_dummy with detailed error codes v3: - no changes v4: - reflect renaming to __i2c_new_dummy v5: - i

[PATCH v6 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

with detailed error codes within the i2c core or for API extensions. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> Reviewed-by: Bartosz Golaszewski <b...@bgdev.pl> --- v3: - prefix i2c_new_device and i2c_new_dummy with two underscores instead one v4: - add missing kernel doc -

[PATCH v6 3/3] eeprom: at24: switch to device-managed version of i2c_new_dummy

Make use of recently introduced device-managed version of i2c_new_dummy to simplify the code. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- v2: - small improvements regarding code readability v3: - no changes v4: - no changes v5: - no changes v6: - rebased --- drivers/misc/

[PATCH resubmit 2/2] eeprom: at24: switch to device-managed version of i2c_new_dummy

Make use of recently introduced device-managed version of i2c_new_dummy to simplify the code. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/misc/eeprom/at24.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/misc/eeprom/at

  1   2   3   4   5   6   7   >