Re: [PATCH 2/2] Staging: nvec: nvec: fixed check style issues

Hi, On Mon, 17 Dec 2018, Greg KH wrote: On Sun, Dec 16, 2018 at 08:57:43AM -0800, Amir Mahdi Ghorbanian wrote: @@ -626,7 +628,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev) break; case 2: /* first byte after command */ if (status

Re: [PATCH] ASoC: tegra_alc5632: fix device_node refcounting

Hello Alexey, AFAICT, this looks right. It seems that *most* of the machine drivers (not only tegra) forget to decrease the refcount. I'm wondering why you didn't sent a series patch to fix them all at once? Reviewed-by: Marc Dietrich Marc On Sat, 28 Jul 2018, Alexey Khoroshilov wrote

Re: [PATCH] ASoC: tegra_alc5632: fix device_node refcounting

Hello Alexey, AFAICT, this looks right. It seems that *most* of the machine drivers (not only tegra) forget to decrease the refcount. I'm wondering why you didn't sent a series patch to fix them all at once? Reviewed-by: Marc Dietrich Marc On Sat, 28 Jul 2018, Alexey Khoroshilov wrote

Re: [PATCH v1 0/4] Restore ULPI USB on Tegra20

f PLL_P_OUT4. Marcel made a patch > that changed the "ulpi-link" clock to PLL_P_OUT4 and that fixed issue > with the USB for the devices that have CDEV2 being enabled by bootloader. > The patch got into the kernel and later Marc Dietrich found that USB > stopped working on the &

Re: [PATCH v1 0/4] Restore ULPI USB on Tegra20

f PLL_P_OUT4. Marcel made a patch > that changed the "ulpi-link" clock to PLL_P_OUT4 and that fixed issue > with the USB for the devices that have CDEV2 being enabled by bootloader. > The patch got into the kernel and later Marc Dietrich found that USB > stopped working on the &

Re: [PATCH 49/61] staging: nvec: simplify getting .drvdata

Am Donnerstag, 19. April 2018, 16:06:19 CEST schrieb Wolfram Sang: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Acked-by: Marc Dietric

Re: [PATCH 49/61] staging: nvec: simplify getting .drvdata

Am Donnerstag, 19. April 2018, 16:06:19 CEST schrieb Wolfram Sang: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Acked-by: Marc Dietrich > --- > > Build tested on

Re: [PATCH] ARM: tegra: fix ulpi regression on tegra20

Hi Marcel, Am Montag, 19. Februar 2018, 16:12:52 CEST schrieb Marcel Ziswiler: > From: Marcel Ziswiler > > Since commit f8f8f1d04494 ("clk: Don't touch hardware when reparenting > during registration") ULPI has been broken on Tegra20 leading to the > following error

Re: [PATCH] ARM: tegra: fix ulpi regression on tegra20

Hi Marcel, Am Montag, 19. Februar 2018, 16:12:52 CEST schrieb Marcel Ziswiler: > From: Marcel Ziswiler > > Since commit f8f8f1d04494 ("clk: Don't touch hardware when reparenting > during registration") ULPI has been broken on Tegra20 leading to the > following error message during boot: > > [

Re: [PATCH 2/3] ARM: tegra: paz00: drop nonstandard 'backlight-boot-off'

Those issues have since been fixed upstream in pwm_bl.c without device > tree hacks, and so this un-documented property should no longer be > useful. > > Signed-off-by: Brian Norris <briannor...@chromium.org> seems to work again. Thanks! Reviewed-by: Marc Dietrich <marvi...@gm

Re: [PATCH 2/3] ARM: tegra: paz00: drop nonstandard 'backlight-boot-off'

Those issues have since been fixed upstream in pwm_bl.c without device > tree hacks, and so this un-documented property should no longer be > useful. > > Signed-off-by: Brian Norris seems to work again. Thanks! Reviewed-by: Marc Dietrich > --- > arch/arm/boot/dts/tegra20-paz00.d

Re: [Outreachy kernel] [PATCH] staging: nvec: cleanup USLEEP_RANGEcheckpatch checks

Hi Simran, Am Donnerstag, 2. März 2017, 15:48:13 CET schrieb SIMRAN SINGHAL: > On Thursday, March 2, 2017 at 8:06:40 PM UTC+5:30, Julia Lawall wrote: > > On Thu, 2 Mar 2017, simran singhal wrote: > > > Resolve strict checkpatch USLEEP_RANGE checks by converting delays and > > > sleeps as

Re: [Outreachy kernel] [PATCH] staging: nvec: cleanup USLEEP_RANGEcheckpatch checks

Hi Simran, Am Donnerstag, 2. März 2017, 15:48:13 CET schrieb SIMRAN SINGHAL: > On Thursday, March 2, 2017 at 8:06:40 PM UTC+5:30, Julia Lawall wrote: > > On Thu, 2 Mar 2017, simran singhal wrote: > > > Resolve strict checkpatch USLEEP_RANGE checks by converting delays and > > > sleeps as

Re: [PATCH] staging:nvec:nvec_ps2.c: Preferingkzalloc(sizeof(*ser_dev)...) over kzalloc(sizeof(struct serio)...)

eryone) happy week. Acked-by: Marc Dietrich <marvi...@gmx.de> > --- > drivers/staging/nvec/nvec_ps2.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/nvec/nvec_ps2.c > b/drivers/staging/nvec/nvec_ps2.c index 499952c8ef39..3b7bce

Re: [PATCH] staging:nvec:nvec_ps2.c: Preferingkzalloc(sizeof(*ser_dev)...) over kzalloc(sizeof(struct serio)...)

Am Dienstag, 14. Februar 2017, 22:31:20 CET schrieb Arushi Singhal: > Prefer kzalloc(sizeof(*ser_dev)...) over kzalloc(sizeof(struct > serio)...) as reported by checkpatch.pl. > > Signed-off-by: Arushi Singhal looks like we are in a (make everyone) happy week. Acked-by: M

Re: [PATCH] ARM: tegra: paz00: fix __initdata placement

Hello Thierry, Am Montag, 23. Januar 2017, 17:24:28 CET schrieb Thierry Reding: > On Mon, Jan 23, 2017 at 11:04:22AM +0100, Marc Dietrich wrote: > > Hello Dmitry, > > > > Am Sonntag, 22. Januar 2017, 23:43:47 CET schrieb Dmitry Torokhov: > > > To have expected e

Re: [PATCH] ARM: tegra: paz00: fix __initdata placement

Hello Thierry, Am Montag, 23. Januar 2017, 17:24:28 CET schrieb Thierry Reding: > On Mon, Jan 23, 2017 at 11:04:22AM +0100, Marc Dietrich wrote: > > Hello Dmitry, > > > > Am Sonntag, 22. Januar 2017, 23:43:47 CET schrieb Dmitry Torokhov: > > > To have expected e

Re: [PATCH] ARM: tegra: paz00: fix __initdata placement

Hello Dmitry, Am Sonntag, 22. Januar 2017, 23:43:47 CET schrieb Dmitry Torokhov: > To have expected effect the __initdata attribute should go after variable > name and before initializer.` > > Signed-off-by: Dmitry Torokhov > --- > arch/arm/mach-tegra/board-paz00.c |

Re: [PATCH] ARM: tegra: paz00: fix __initdata placement

Hello Dmitry, Am Sonntag, 22. Januar 2017, 23:43:47 CET schrieb Dmitry Torokhov: > To have expected effect the __initdata attribute should go after variable > name and before initializer.` > > Signed-off-by: Dmitry Torokhov > --- > arch/arm/mach-tegra/board-paz00.c | 2 +- > 1 file changed, 1

Re: [PATCH] Revert "staging: nvec: ps2: change serio type to passthrough"

OPTION section). > > Since paz00's embedded controller is not connected to a PS/2 port > itself, the PS/2 interface it exposes is not a pass-through one. > > Acked-by: Marc Dietrich <marvi...@gmx.de> > Signed-off-by: Paul Fertser <fercer...@gmail.com> In fact I was a bit to fast

Re: [PATCH] Revert "staging: nvec: ps2: change serio type to passthrough"

OPTION section). > > Since paz00's embedded controller is not connected to a PS/2 port > itself, the PS/2 interface it exposes is not a pass-through one. > > Acked-by: Marc Dietrich > Signed-off-by: Paul Fertser In fact I was a bit to fast to ack. Turns out I booted the wrong kernel.

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

Am Dienstag, 23. Februar 2016, 14:17:17 CET schrieb Arnd Bergmann: > On Tuesday 23 February 2016 11:38:52 Marc Dietrich wrote: > > Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann: > > > On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote: > > > >

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

Am Dienstag, 23. Februar 2016, 14:17:17 CET schrieb Arnd Bergmann: > On Tuesday 23 February 2016 11:38:52 Marc Dietrich wrote: > > Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann: > > > On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote: > > > >

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann: > On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote: > > On Thursday 18 February 2016 21:04:49 Johannes Berg wrote: > > > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > > Just for my curiosity: what is the

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann: > On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote: > > On Thursday 18 February 2016 21:04:49 Johannes Berg wrote: > > > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > > Just for my curiosity: what is the

Re: [PATCHv2 3/4] ARM: tegra: use build-in device propertieswithrfkill_gpio

Am Dienstag, 26. Januar 2016, 09:46:56 CET schrieb Johannes Berg: > On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote: > > > > > > seems to work fine. I wish we could instantiate this from device-tree > > so we can finially get rid of this file. > > That'd

Re: [PATCHv2 3/4] ARM: tegra: use build-in device propertieswithrfkill_gpio

Am Dienstag, 26. Januar 2016, 09:46:56 CET schrieb Johannes Berg: > On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote: > > > > > > seems to work fine. I wish we could instantiate this from device-tree > > so we can finially get rid of this file. > > That'd

Re: [PATCH] staging: nvec: replace led_classdev_register

nction. > > Signed-off-by: Hari Prasath Gujulan Elango Thanks! Acked-by: Marc Dietrich > --- > drivers/staging/nvec/nvec_paz00.c | 12 +--- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git a/drivers/staging/nvec/nvec_paz00.c > b/drivers/stagi

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties withrfkill_gpio

http://patchwork.ozlabs.org/patch/572642/ > > Johannes, I assume that you'll want to take this through your tree > because of the dependency? In that case: > > Acked-by: Thierry Reding seems to work fine. I wish we could instantiate this from device-tree so we can finially g

Re: [PATCH] staging: nvec: replace led_classdev_register

nt > nvec_paz00_remove() function. > > Signed-off-by: Hari Prasath Gujulan Elango <hguju...@visteon.com> Thanks! Acked-by: Marc Dietrich <marvi...@gmx.de> > --- > drivers/staging/nvec/nvec_paz00.c | 12 +--- > 1 file changed, 1 insertion(+), 11 deletions(-)

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties withrfkill_gpio

; > Acked-by: Thierry Reding <tred...@nvidia.com> seems to work fine. I wish we could instantiate this from device-tree so we can finially get rid of this file. Tested-by: Marc Dietrich <marvi...@gmx.de> signature.asc Description: This is a digitally signed message part.

Re: [PATCH] staging: nvec: fixed few coding style warnings

Am Donnerstag, 15. Oktober 2015, 11:48:12 schrieb Dan Carpenter: > On Thu, Oct 15, 2015 at 10:39:02AM +0200, Marc Dietrich wrote: > > > > - if (unlikely(nvec->rx == NULL)) { > > > > + if (!unlikely(nvec->rx)) { &g

Re: [PATCH] staging: nvec: fixed few coding style warnings

Am Mittwoch, 14. Oktober 2015, 21:12:36 schrieb Dan Carpenter: > On Wed, Oct 14, 2015 at 07:38:22PM +0530, Sakshi Bansal wrote: > > Fixed allignmnet issues and block comments usage > > Split it apart by type of fix. > > > @@ -617,7 +618,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)

Re: [PATCH] staging: nvec: fixed few coding style warnings

Am Mittwoch, 14. Oktober 2015, 21:12:36 schrieb Dan Carpenter: > On Wed, Oct 14, 2015 at 07:38:22PM +0530, Sakshi Bansal wrote: > > Fixed allignmnet issues and block comments usage > > Split it apart by type of fix. > > > @@ -617,7 +618,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)

Re: [PATCH] staging: nvec: fixed few coding style warnings

Am Donnerstag, 15. Oktober 2015, 11:48:12 schrieb Dan Carpenter: > On Thu, Oct 15, 2015 at 10:39:02AM +0200, Marc Dietrich wrote: > > > > - if (unlikely(nvec->rx == NULL)) { > > > > + if (!unlikely(nvec->rx)) { &g

Re: [PATCH v2] ARM: tegra: paz00: use con_id's to refer GPIO's ingpiod_lookup table

okup = { > > > > .dev_id = "rfkill_gpio", > > .table = { > > > > - GPIO_LOOKUP_IDX("tegra-gpio", 25, NULL, 0, 0), > > - GPIO_LOOKUP_IDX("tegra-gpio", 85, NULL, 1, 0), > > + GPIO

Re: [PATCH v2] ARM: tegra: paz00: use con_id's to refer GPIO's ingpiod_lookup table

uct platform_device wifi_rfkill_device = { > > > > static struct gpiod_lookup_table wifi_gpio_lookup = { > > > > .dev_id = "rfkill_gpio", > > .table = { > > > > - GPIO_LOOKUP_IDX("tegra-gpio", 25, NULL, 0, 0), > > - GPIO_LOOKUP

Re: [PATCH v3 4/4] dt: paz00: define nvec as child of i2c bus

Am Dienstag, 21. Juli 2015, 11:51:15 schrieb Andrey Danin: > On 21.07.2015 11:25, Marc Dietrich wrote: > > I think in this case it would be better to leave nvec and dt as it is for > > now, and just add the slave function to tegra-i2c. Otherwise we will > > again have two d

Re: [PATCH v3 4/4] dt: paz00: define nvec as child of i2c bus

Am Dienstag, 21. Juli 2015, 09:35:21 schrieb Andrey Danin: > On 21.07.2015 1:19, Stephen Warren wrote: > > On 07/20/2015 02:35 PM, Andrey Danin wrote: > >> NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings > >> for NVEC node. > >> > >> diff --git

Re: [PATCH v3 4/4] dt: paz00: define nvec as child of i2c bus

Am Dienstag, 21. Juli 2015, 09:35:21 schrieb Andrey Danin: On 21.07.2015 1:19, Stephen Warren wrote: On 07/20/2015 02:35 PM, Andrey Danin wrote: NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings for NVEC node. diff --git a/arch/arm/boot/dts/tegra20-paz00.dts

Re: [PATCH v3 4/4] dt: paz00: define nvec as child of i2c bus

Am Dienstag, 21. Juli 2015, 11:51:15 schrieb Andrey Danin: On 21.07.2015 11:25, Marc Dietrich wrote: I think in this case it would be better to leave nvec and dt as it is for now, and just add the slave function to tegra-i2c. Otherwise we will again have two different nvidia,nvec-slave

Re: [PATCH v2] ARM: tegra: paz00: use con_id's to refer GPIO's in gpiod_lookup table

itry Osipenko > Fixes: 72daceb (net: rfkill: gpio: Add default GPIO driver mappings for > ACPI) Cc: # v3.19+ > Acked-by: Alexandre Courbot beside a small typo in the commit message (is users -> its users) this looks good now. I can confirm that the gpio's are all available now. Revie

Re: [PATCH v2] ARM: tegra: paz00: use con_id's to refer GPIO's in gpiod_lookup table

) Cc: sta...@vger.kernel.org # v3.19+ Acked-by: Alexandre Courbot acour...@nvidia.com beside a small typo in the commit message (is users - its users) this looks good now. I can confirm that the gpio's are all available now. Reviewed-by: Marc Dietrich marvi...@gmx.de --- v2: s

Re: [PATCH] staging: nvec: remove duplicated const

Am Dienstag, 16. Juni 2015, 23:13:21 schrieb Peng Fan: > Sparse checking warning: > "drivers/staging/nvec/nvec_ps2.c:172:14: warning: duplicate const". > Remove the duplicated const to fix the warning. > > Signed-off-by: Peng Fan Thanks! Acked-by: Marc Dietrich >

Re: [PATCH] staging: nvec: remove duplicated const

Am Dienstag, 16. Juni 2015, 23:13:21 schrieb Peng Fan: Sparse checking warning: drivers/staging/nvec/nvec_ps2.c:172:14: warning: duplicate const. Remove the duplicated const to fix the warning. Signed-off-by: Peng Fan van.free...@gmail.com Thanks! Acked-by: Marc Dietrich marvi...@gmx.de

Re: [PATCH] staging:nvec:nvec - Fix for typo in comment to function tegra_nvec_remove().

Hi Shailendra, you should fill the patch description with something, even if trivial, and trim the subject line a bit, e.g. --- staging: nvec: fix typo in comment (all lowercase, no full stop at the end) Fix spelling error in comment in function tegra_nvec_remove. S-o-b - Thanks, Marc

Re: [PATCH] staging:nvec:nvec - Fix for typo in comment to function tegra_nvec_remove().

Hi Shailendra, you should fill the patch description with something, even if trivial, and trim the subject line a bit, e.g. --- staging: nvec: fix typo in comment (all lowercase, no full stop at the end) Fix spelling error in comment in function tegra_nvec_remove. S-o-b - Thanks, Marc

Re: [PATCH 3/3] dt: paz00: define nvec as child of i2c bus

Am Mittwoch, 1. April 2015, 11:28:32 schrieb Stephen Warren: > On 03/31/2015 09:46 AM, Andrey Danin wrote: > > On 31.03.2015 17:09, Stephen Warren wrote: > >> On 03/31/2015 12:40 AM, Andrey Danin wrote: > >>> Hi, > >>> > >>> Thanks for the review. > >>> > >>> On 03.02.2015 0:20, Stephen Warren

Re: [PATCH 3/3] dt: paz00: define nvec as child of i2c bus

Am Mittwoch, 1. April 2015, 11:28:32 schrieb Stephen Warren: On 03/31/2015 09:46 AM, Andrey Danin wrote: On 31.03.2015 17:09, Stephen Warren wrote: On 03/31/2015 12:40 AM, Andrey Danin wrote: Hi, Thanks for the review. On 03.02.2015 0:20, Stephen Warren wrote: [ snipped old

Re: [PATCH] staging: nvec: Make nvec_write_sync return result by parameter

Hi Even, Am Freitag, 13. Februar 2015, 21:28:48 schrieb Evan Hauck: > As outlined in the TODO file, nvec_write_sync was modified to return an > error code instead of NULL on failure, and return the nvec_msg as a > parameter. > > Signed-off-by: Evan Hauck thanks for looking into this issue! I

Re: [PATCH] staging: nvec: Make nvec_write_sync return result by parameter

Hi Even, Am Freitag, 13. Februar 2015, 21:28:48 schrieb Evan Hauck: As outlined in the TODO file, nvec_write_sync was modified to return an error code instead of NULL on failure, and return the nvec_msg as a parameter. Signed-off-by: Evan Hauck echa...@mtu.edu thanks for looking into this

Re: [PATCH v3 00/20] power_supply: Allow safe usage of power supply

_supply: Change ownership from driver to core > > These are huge. Patches 2 and 11 are Reviewed-By: Marc Dietrich # for the nvec part. Thanks! Marc signature.asc Description: This is a digitally signed message part.

Re: [PATCH v3 00/20] power_supply: Allow safe usage of power supply

. Patches 2 and 11 are Reviewed-By: Marc Dietrich marvi...@gmx.de # for the nvec part. Thanks! Marc signature.asc Description: This is a digitally signed message part.

Re: [PATCH] Warning that occured while compiling the nvec in3.19.0-rc5+ is fixed

Am Samstag 31 Januar 2015, 20:11:29 schrieb Julian Andres Klode: > On 31 January 2015 at 17:29, Greg KH wrote: > > On Sat, Jan 31, 2015 at 05:24:42PM +0530, varsharamt wrote: > >> The task was to fix a warning which was shown while compiling a driver > >> called NVEC. I wrote a brief description

Re: [PATCH] Warning that occured while compiling the nvec in3.19.0-rc5+ is fixed

Am Samstag 31 Januar 2015, 20:11:29 schrieb Julian Andres Klode: On 31 January 2015 at 17:29, Greg KH gre...@linuxfoundation.org wrote: On Sat, Jan 31, 2015 at 05:24:42PM +0530, varsharamt wrote: The task was to fix a warning which was shown while compiling a driver called NVEC. I wrote a

Re: [PATCH 3/3] dt: paz00: define nvec as child of i2c bus

Am Donnerstag, 29. Januar 2015, 10:20:22 schrieb Andrey Danin: > NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings > for NVEC node. > > Signed-off-by: Andrey Danin > --- > .../devicetree/bindings/nvec/nvidia,nvec.txt | 19 ++- >

Re: [PATCH 2/3] staging/nvec: reimplement on top of tegra i2c driver

; 0) { > + ret = devm_gpio_request_one(>dev, nvec->gpio, > + GPIOF_OUT_INIT_HIGH, > + "nvec gpio"); > + if (ret < 0) { > dev_err(nvec->dev, "couldn't request gpio\n"); > return -ENODEV; > } > > -

Re: [PATCH 1/3] i2c: tegra: implement slave mode

Hi Andrey, first, thanks for accepting the challenge once more ;-) The driver depends on I2C_SLAVE now, so you need to add this to Kconfig. The amount of code (and additional overhead) is pretty small, so I think it's ok to always enable it. Otherwise we would need lots of ifdefs. Am

Re: [PATCH 1/3] i2c: tegra: implement slave mode

Hi Andrey, first, thanks for accepting the challenge once more ;-) The driver depends on I2C_SLAVE now, so you need to add this to Kconfig. The amount of code (and additional overhead) is pretty small, so I think it's ok to always enable it. Otherwise we would need lots of ifdefs. Am

Re: [PATCH 3/3] dt: paz00: define nvec as child of i2c bus

Am Donnerstag, 29. Januar 2015, 10:20:22 schrieb Andrey Danin: NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings for NVEC node. Signed-off-by: Andrey Danin danind...@mail.ru --- .../devicetree/bindings/nvec/nvidia,nvec.txt | 19 ++-

Re: [PATCH 2/3] staging/nvec: reimplement on top of tegra i2c driver

); +module_i2c_driver(i2c_nvec_device_driver); -MODULE_ALIAS(platform:nvec); +MODULE_ALIAS(i2c:nvec); MODULE_DESCRIPTION(NVIDIA compliant embedded controller interface); MODULE_AUTHOR(Marc Dietrich marvi...@gmx.de); MODULE_LICENSE(GPL); diff --git a/drivers/staging/nvec/nvec.h b/drivers/staging/nvec

Re: GPL violation: China Telecom uses a modified linux kernel in itsproduct without sources

Am Mittwoch, 3. Dezember 2014, 22:50:09 schrieb Pavel Machek: > Hi! > > > I think China Telecom is violating GPL in one of its products, iTV. > > The product uses linux as its OS. To run on MIPS architecture, it does a > > lot of modification to linux kernel. But there is NO source published. I >

Re: GPL violation: China Telecom uses a modified linux kernel in itsproduct without sources

Am Mittwoch, 3. Dezember 2014, 22:50:09 schrieb Pavel Machek: Hi! I think China Telecom is violating GPL in one of its products, iTV. The product uses linux as its OS. To run on MIPS architecture, it does a lot of modification to linux kernel. But there is NO source published. I phoned

Re: [PATCH v5 33/48] staging: nvec: Register with kernel power-off handler

Am Donnerstag 06 November 2014, 08:43:17 schrieb Guenter Roeck: > Register with kernel power-off handler instead of setting pm_power_off > directly. Register with default priority since we don't know any better. > > Cc: Julian Andres Klode > Cc: Marc Dietrich > Cc: Greg Kroa

Re: [PATCH v5 33/48] staging: nvec: Register with kernel power-off handler

Am Donnerstag 06 November 2014, 08:43:17 schrieb Guenter Roeck: Register with kernel power-off handler instead of setting pm_power_off directly. Register with default priority since we don't know any better. Cc: Julian Andres Klode j...@jak-linux.org Cc: Marc Dietrich marvi...@gmx.de Cc

Re: [PATCH 29/44] staging: nvec: Register with kernel poweroff handler

Am Montag 06 Oktober 2014, 22:28:31 schrieb Guenter Roeck: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Register with default priority value of 128 since we don't know > any better. I just tested this change and it seems to break power off. What the driver

Re: [PATCH 29/44] staging: nvec: Register with kernel poweroff handler

Am Montag 06 Oktober 2014, 22:28:31 schrieb Guenter Roeck: Register with kernel poweroff handler instead of setting pm_power_off directly. Register with default priority value of 128 since we don't know any better. I just tested this change and it seems to break power off. What the driver

Re: kernel BUG at fs/dcache.c (3.17-rc4/5)

Hi Trond, Am Mittwoch, 17. September 2014, 09:21:05 schrieb Trond Myklebust: > On Wed, Sep 17, 2014 at 9:05 AM, Marc Dietrich wrote: > > Hi, > > > > I get this roughly once in a week. Hard to reproduce. > > > > Sep 17 14:44:21 fb07-iapwap2 kernel: [

kernel BUG at fs/dcache.c (3.17-rc4/5)

Hi, I get this roughly once in a week. Hard to reproduce. Sep 17 14:44:21 fb07-iapwap2 kernel: [ cut here ] Sep 17 14:44:21 fb07-iapwap2 kernel: kernel BUG at fs/dcache.c:1619! Sep 17 14:44:22 fb07-iapwap2 kernel: invalid opcode: [#1] PREEMPT SMP Sep 17 14:44:22

kernel BUG at fs/dcache.c (3.17-rc4/5)

Hi, I get this roughly once in a week. Hard to reproduce. Sep 17 14:44:21 fb07-iapwap2 kernel: [ cut here ] Sep 17 14:44:21 fb07-iapwap2 kernel: kernel BUG at fs/dcache.c:1619! Sep 17 14:44:22 fb07-iapwap2 kernel: invalid opcode: [#1] PREEMPT SMP Sep 17 14:44:22

Re: kernel BUG at fs/dcache.c (3.17-rc4/5)

Hi Trond, Am Mittwoch, 17. September 2014, 09:21:05 schrieb Trond Myklebust: On Wed, Sep 17, 2014 at 9:05 AM, Marc Dietrich marvi...@gmx.de wrote: Hi, I get this roughly once in a week. Hard to reproduce. Sep 17 14:44:21 fb07-iapwap2 kernel: [ cut here ] Sep

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

Am Freitag, 12. September 2014, 11:58:21 schrieb Wolfram Sang: > > ok, take our embedded controller driver (in staging/nvec) as an example. > > It's basicly an MFD connecting keyboard, mouse, power, gpio, and some > > other stuff to the soc. The MFD operates in master mode while the SOC is > > the

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

Am Freitag, 12. September 2014, 10:33:48 schrieb Wolfram Sang: > > > Why do you want DT to be involved at all? > > > > Imagine a device which supports both, slave or master mode. The driver > > needs to know in which mode it should operate. This cannot be hard coded, > > because on different

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

Am Donnerstag, 11. September 2014, 16:54:22 schrieb Wolfram Sang: > On Thu, Sep 11, 2014 at 04:52:22PM +0200, Marc Dietrich wrote: > > Am Donnerstag, 11. September 2014, 16:40:04 schrieb Wolfram Sang: > > > > b) could be seen as a configuration thing since the functionality

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

Am Donnerstag, 11. September 2014, 16:54:22 schrieb Wolfram Sang: On Thu, Sep 11, 2014 at 04:52:22PM +0200, Marc Dietrich wrote: Am Donnerstag, 11. September 2014, 16:40:04 schrieb Wolfram Sang: b) could be seen as a configuration thing since the functionality backend could be changed

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

Am Freitag, 12. September 2014, 10:33:48 schrieb Wolfram Sang: Why do you want DT to be involved at all? Imagine a device which supports both, slave or master mode. The driver needs to know in which mode it should operate. This cannot be hard coded, because on different boards,

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

Am Freitag, 12. September 2014, 11:58:21 schrieb Wolfram Sang: ok, take our embedded controller driver (in staging/nvec) as an example. It's basicly an MFD connecting keyboard, mouse, power, gpio, and some other stuff to the soc. The MFD operates in master mode while the SOC is the I2C

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

Am Donnerstag, 11. September 2014, 16:40:04 schrieb Wolfram Sang: > > b) could be seen as a configuration thing since the functionality > > backend could be changed at runtime even. > > Come to think of it, not only the functionality, also the address can be > changed at runtime. This makes me

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

Am Donnerstag, 11. September 2014, 16:12:58 schrieb Wolfram Sang: > On Thu, Sep 11, 2014 at 02:17:16PM +0200, Marc Dietrich wrote: > > > + reg = <0x64>; > > > > we had some discussions in the past how to represent i2c master devices in > > device tree.

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

cc'ing: devicetree Am Dienstag, 9. September 2014, 16:54:30 schrieb Wolfram Sang: > From: Wolfram Sang > > Not for upstream! > > Signed-off-by: Wolfram Sang > --- > arch/arm/boot/dts/r8a7790-lager.dts | 15 ++- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git

Re: [RFC 0/4] i2c: slave support framework for Linux devices

Hello Wolfram, Am Dienstag, 9. September 2014, 16:54:26 schrieb Wolfram Sang: > Finally, here is my take on the often desired feature that Linux can not > only be an I2C master, but also an I2C slave. Compared to my draft sent out > last week, this RFC has been tested on hardware (Renesas Lager

Re: [RFC 0/4] i2c: slave support framework for Linux devices

Hello Wolfram, Am Dienstag, 9. September 2014, 16:54:26 schrieb Wolfram Sang: Finally, here is my take on the often desired feature that Linux can not only be an I2C master, but also an I2C slave. Compared to my draft sent out last week, this RFC has been tested on hardware (Renesas Lager

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

cc'ing: devicetree Am Dienstag, 9. September 2014, 16:54:30 schrieb Wolfram Sang: From: Wolfram Sang wsa+rene...@sang-engineering.com Not for upstream! Signed-off-by: Wolfram Sang wsa+rene...@sang-engineering.com --- arch/arm/boot/dts/r8a7790-lager.dts | 15 ++- 1 file

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

Am Donnerstag, 11. September 2014, 16:12:58 schrieb Wolfram Sang: On Thu, Sep 11, 2014 at 02:17:16PM +0200, Marc Dietrich wrote: + reg = 0x64; we had some discussions in the past how to represent i2c master devices in device tree. The outcome was to use to a special

Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support

Am Donnerstag, 11. September 2014, 16:40:04 schrieb Wolfram Sang: b) could be seen as a configuration thing since the functionality backend could be changed at runtime even. Come to think of it, not only the functionality, also the address can be changed at runtime. This makes me think it

Re: [PATCH v2 3/4] zram: zram memory size limitation

Am Mittwoch, 20. August 2014, 08:32:25 schrieb Minchan Kim: > Hello, > > On Tue, Aug 19, 2014 at 10:06:22AM +0200, Marc Dietrich wrote: > > Am Dienstag, 19. August 2014, 16:54:46 schrieb Minchan Kim: > > > Since zram has no control feature to limit memory usage, >

Re: [PATCH v2 3/4] zram: zram memory size limitation

Am Mittwoch, 20. August 2014, 08:32:25 schrieb Minchan Kim: Hello, On Tue, Aug 19, 2014 at 10:06:22AM +0200, Marc Dietrich wrote: Am Dienstag, 19. August 2014, 16:54:46 schrieb Minchan Kim: Since zram has no control feature to limit memory usage, it makes hard to manage system memrory

Re: [PATCH v2 3/4] zram: zram memory size limitation

Am Dienstag, 19. August 2014, 16:54:46 schrieb Minchan Kim: > Since zram has no control feature to limit memory usage, > it makes hard to manage system memrory. > > This patch adds new knob "mem_limit" via sysfs to set up the > a limit so that zram could fail allocation once it reaches > the

Re: [PATCH v2 3/4] zram: zram memory size limitation

Am Dienstag, 19. August 2014, 16:54:46 schrieb Minchan Kim: Since zram has no control feature to limit memory usage, it makes hard to manage system memrory. This patch adds new knob mem_limit via sysfs to set up the a limit so that zram could fail allocation once it reaches the limit.

Re: [PATCH 2/2] staging/nvec: Use platform_get_irq()

registered yet. While this > is unlikely to become an issue for nvec, platform_get_irq() is the > recommended way to get at interrupts. > > Signed-off-by: Thierry Reding Thanks again, Thierry! Acked-by: Marc Dietrich > --- > drivers/staging/nvec/nvec.c | 5 ++--- > 1 file c

Re: [PATCH 1/2] staging/nvec: Do not pass resource to mfd_add_devices()

directly access > the registers. > > Since subdevices never need to access the registers we can simply pass > NULL instead. > > Signed-off-by: Thierry Reding Acked-by: Marc Dietrich > --- > drivers/staging/nvec/nvec.c | 2 +- > 1 file changed, 1 insertion(+), 1 del

Re: [PATCH 1/2] staging/nvec: Do not pass resource to mfd_add_devices()

directly access the registers. Since subdevices never need to access the registers we can simply pass NULL instead. Signed-off-by: Thierry Reding tred...@nvidia.com Acked-by: Marc Dietrich marvi...@gmx.de --- drivers/staging/nvec/nvec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [PATCH 2/2] staging/nvec: Use platform_get_irq()

registered yet. While this is unlikely to become an issue for nvec, platform_get_irq() is the recommended way to get at interrupts. Signed-off-by: Thierry Reding tred...@nvidia.com Thanks again, Thierry! Acked-by: Marc Dietrich marvi...@gmx.de --- drivers/staging/nvec/nvec.c | 5 ++--- 1 file

Re: [PATCH] staging:nvec: Fix several coding style warnings

our time. Marc Marc Dietrich -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] staging:nvec: Fix several coding style warnings

anyway for taking your time. Marc Marc Dietrich marvi...@gmx.de -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org

Re: [PATCH 0/2] staging: nvec: fix some coding style problems

memory' message > > drivers/staging/nvec/nvec.c | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) thanks for fixing, so for this series Acked-by: Marc Dietrich signature.asc Description: This is a digitally signed message part.

Re: [PATCH 0/2] staging: nvec: fix some coding style problems

drivers/staging/nvec/nvec.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) thanks for fixing, so for this series Acked-by: Marc Dietrich marvi...@gmx.de signature.asc Description: This is a digitally signed message part.

Re: [PATCH] staging: nvec: remove unneccessary 'else' after 'return'statement

e some apply-burdon from Greg. Ideally, you would combine all patches (one patch per checkpatch warning) in a common thread like this: git-format-patch --cover-letter --thread -s This way you could add some comments (if any) to the cover letter and just keep the plain checkpatch message in th

Re: [PATCH] staging: nvec: remove unneccessary 'else' after 'return'statement

-- Marc Dietrich marvi...@gmx.de -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] staging: nvec: insert blank lines after declarations

text looks like a bit overkill though. > Signed-off-by: Pawel Lebioda > drivers/staging/nvec/nvec_paz00.c | 1 + > drivers/staging/nvec/nvec_power.c | 1 + > drivers/staging/nvec/nvec_ps2.c | 2 ++ > 3 files changed, 4 insertions(+) Acked-by: Marc Dietrich signature.asc Descriptio

  1   2   3   >