Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Thu, Aug 11, 2016 at 10:45:00AM +0200, Oliver Hartkopp wrote: > On 08/11/2016 09:14 AM, Andreas Werner wrote: > >On Wed, Aug 10, 2016 at 10:28:45PM +0200, Oliver Hartkopp wrote: > > >>Just check 'git grep IFF_ECHO'. Even grcan.c and janz-ican3.c have IFF_ECHO &g

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Thu, Aug 11, 2016 at 10:45:00AM +0200, Oliver Hartkopp wrote: > On 08/11/2016 09:14 AM, Andreas Werner wrote: > >On Wed, Aug 10, 2016 at 10:28:45PM +0200, Oliver Hartkopp wrote: > > >>Just check 'git grep IFF_ECHO'. Even grcan.c and janz-ican3.c have IFF_ECHO &g

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Wed, Aug 10, 2016 at 10:28:45PM +0200, Oliver Hartkopp wrote: > Hi Andreas, > > On 08/09/2016 08:10 AM, Andreas Werner wrote: > >On Mon, Aug 08, 2016 at 04:35:34PM +0200, Wolfgang Grandegger wrote: > > >>>>>>You specify here one echo_skb but

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Wed, Aug 10, 2016 at 10:28:45PM +0200, Oliver Hartkopp wrote: > Hi Andreas, > > On 08/09/2016 08:10 AM, Andreas Werner wrote: > >On Mon, Aug 08, 2016 at 04:35:34PM +0200, Wolfgang Grandegger wrote: > > >>>>>>You specify here one echo_skb but

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 08:23:55PM -0700, Benjamin Poirier wrote: > On 2016/08/08 09:26, Andreas Werner wrote: > [...] > > > > + > > > > + if (cf->can_dlc > 0) > > > > + data[0] = be32_to_cpup((__be32 *)

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 08:23:55PM -0700, Benjamin Poirier wrote: > On 2016/08/08 09:26, Andreas Werner wrote: > [...] > > > > + > > > > + if (cf->can_dlc > 0) > > > > + data[0] = be32_to_cpup((__be32 *)

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 04:35:34PM +0200, Wolfgang Grandegger wrote: > Am 08.08.2016 um 16:05 schrieb Andreas Werner: > >On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote: > >>Hello, > >> > >>Am 08.08.2016 um 13:39 schrieb Andreas Werner: >

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 04:35:34PM +0200, Wolfgang Grandegger wrote: > Am 08.08.2016 um 16:05 schrieb Andreas Werner: > >On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote: > >>Hello, > >> > >>Am 08.08.2016 um 13:39 schrieb Andreas Werner: >

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 03:06:33PM +0200, Kurt Van Dijck wrote: > > --- Original message --- > > Date: Mon, 8 Aug 2016 14:28:39 +0200 > > From: Wolfgang Grandegger > > > [...] > > >>>+ > > >>>+if (!(cf->can_id & CAN_RTR_FLAG)) { > > >>>+

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 03:06:33PM +0200, Kurt Van Dijck wrote: > > --- Original message --- > > Date: Mon, 8 Aug 2016 14:28:39 +0200 > > From: Wolfgang Grandegger > > > [...] > > >>>+ > > >>>+if (!(cf->can_id & CAN_RTR_FLAG)) { > > >>>+writel(data[0],

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote: > Hello, > > Am 08.08.2016 um 13:39 schrieb Andreas Werner: > >On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote: > >>Hello Andreas, > >> > >>a first quick review..

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote: > Hello, > > Am 08.08.2016 um 13:39 schrieb Andreas Werner: > >On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote: > >>Hello Andreas, > >> > >>a first quick review..

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote: > Hello Andreas, > > a first quick review > > Am 26.07.2016 um 11:16 schrieb Andreas Werner: > >This CAN Controller is found on MEN Chameleon FPGAs. > > > >The driver/device

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote: > Hello Andreas, > > a first quick review > > Am 26.07.2016 um 11:16 schrieb Andreas Werner: > >This CAN Controller is found on MEN Chameleon FPGAs. > > > >The driver/device

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Sun, Aug 07, 2016 at 08:58:14PM -0700, Benjamin Poirier wrote: > On 2016/07/26 11:16, Andreas Werner wrote: > [...] > > + > > + /* Lock for CTL_BTR register access. > > +* This register combines bittiming bits > > +* and the operation mode bits. > >

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Sun, Aug 07, 2016 at 08:58:14PM -0700, Benjamin Poirier wrote: > On 2016/07/26 11:16, Andreas Werner wrote: > [...] > > + > > + /* Lock for CTL_BTR register access. > > +* This register combines bittiming bits > > +* and the operation mode bits. > >

[PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

parameters to configure the buffer level interrupt for RX/TX as well as a RX timeout interrupt. With this configuration options, the driver/device provides flexibility for different types of usecases. Signed-off-by: Andreas Werner <andreas.wer...@men.de> --- drivers/net/can/Kconfig

[PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

parameters to configure the buffer level interrupt for RX/TX as well as a RX timeout interrupt. With this configuration options, the driver/device provides flexibility for different types of usecases. Signed-off-by: Andreas Werner --- drivers/net/can/Kconfig| 10 + drivers/net/can/Makefile

Re: [PATCH] net: can: Introduce MEN 16Z192-00 CAN controller driver

rovides flexibility for different types of usecases. > > Signed-off-by: Andreas Werner <andreas.wer...@men.de> > --- > drivers/net/can/Kconfig| 10 + > drivers/net/can/Makefile | 1 + > drivers/net/can/men_z192_can.c | 990 > +

Re: [PATCH] net: can: Introduce MEN 16Z192-00 CAN controller driver

rovides flexibility for different types of usecases. > > Signed-off-by: Andreas Werner > --- > drivers/net/can/Kconfig| 10 + > drivers/net/can/Makefile | 1 + > drivers/net/can/men_z192_can.c | 990 > + > 3 files ch

[PATCH] mcb: Added bar descriptor support for non PCI bus MCB carrier

-by: Andreas Werner <andreas.wer...@men.de> --- drivers/mcb/mcb-internal.h | 9 drivers/mcb/mcb-parse.c| 125 - 2 files changed, 120 insertions(+), 14 deletions(-) diff --git a/drivers/mcb/mcb-internal.h b/drivers/mcb/mcb-internal.h index 5

[PATCH] mcb: Added bar descriptor support for non PCI bus MCB carrier

-by: Andreas Werner --- drivers/mcb/mcb-internal.h | 9 drivers/mcb/mcb-parse.c| 125 - 2 files changed, 120 insertions(+), 14 deletions(-) diff --git a/drivers/mcb/mcb-internal.h b/drivers/mcb/mcb-internal.h index 5254e02..d6e6933 100644

[PATCH] net: can: Introduce MEN 16Z192-00 CAN controller driver

parameters to configure the buffer level interrupt for RX/TX as well as a RX timeout interrupt. With this configuration options, the driver/device provides flexibility for different types of usecases. Signed-off-by: Andreas Werner <andreas.wer...@men.de> --- drivers/net/can/Kconfig

[PATCH] net: can: Introduce MEN 16Z192-00 CAN controller driver

parameters to configure the buffer level interrupt for RX/TX as well as a RX timeout interrupt. With this configuration options, the driver/device provides flexibility for different types of usecases. Signed-off-by: Andreas Werner --- drivers/net/can/Kconfig| 10 + drivers/net/can/Makefile

[PATCH] mcb: Added support for LPC or non PCI based MCB carrier

Add support for MCB bases FPGAs connected to the LPC or non PCI Bus. This driver currently supports the SC24 board. The FPGA is connected to the LPC bus and is identified using the BIOS DMI string. Signed-off-by: Andreas Werner <andreas.wer...@men.de> --- drivers/mcb/Kconfig

[PATCH] mcb: Added support for LPC or non PCI based MCB carrier

Add support for MCB bases FPGAs connected to the LPC or non PCI Bus. This driver currently supports the SC24 board. The FPGA is connected to the LPC bus and is identified using the BIOS DMI string. Signed-off-by: Andreas Werner --- drivers/mcb/Kconfig | 9 +++ drivers/mcb/Makefile | 1

Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak wrote: > On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote: >> Julius and I were looking at the code when we spotted the issue. >> >> As Julius said, "just pass a boot param", is not easy on certain >> machines, like phone.

Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak wrote: > On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote: >> Julius and I were looking at the code when we spotted the issue. >> >> As Julius said, "just pass a boot param", is not easy on certain >> machines, like phone. It is not user

Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

>> I guess "force_gpt" (and "gpt" on kernel command line) exists to force >> users to think and care about a reason why the device has unreadable >> (broken) primary GPT header. > > > Yes, from find_valid_gpt(): > > * If the Primary GPT header is not valid, the Alternate GPT header > * is not

Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

>> I guess "force_gpt" (and "gpt" on kernel command line) exists to force >> users to think and care about a reason why the device has unreadable >> (broken) primary GPT header. > > > Yes, from find_valid_gpt(): > > * If the Primary GPT header is not valid, the Alternate GPT header > * is not

[PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

be what happens next). Signed-off-by: Julius Werner <jwer...@chromium.org> --- block/partitions/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/partitions/efi.c b/block/partitions/efi.c index 26cb624..0d4ca8e 100644 --- a/block/partitions/efi.c +++ b/block/

[PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

be what happens next). Signed-off-by: Julius Werner --- block/partitions/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/partitions/efi.c b/block/partitions/efi.c index 26cb624..0d4ca8e 100644 --- a/block/partitions/efi.c +++ b/block/partitions/efi.c @@ -625,7

[PATCH 2/2] mcb: Delete num_cells variable which is not required

The num_cells variable is only used in the dev_dbg print, but we can directly use the ret variable which also includes the same value. Signed-off-by: Andreas Werner <andreas.wer...@men.de> --- drivers/mcb/mcb-pci.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/d

[PATCH 1/2] mcb: Replace ioremap and request_region with the devm version

Replaced ioremap with devm_ioremap and request_mem_region with devm_request_mem_region. This makes the code much more cleaner. Signed-off-by: Andreas Werner <andreas.wer...@men.de> --- drivers/mcb/mcb-pci.c | 19 +++ 1 file changed, 7 insertions(+), 12 deletions(-) diff

[PATCH 2/2] mcb: Delete num_cells variable which is not required

The num_cells variable is only used in the dev_dbg print, but we can directly use the ret variable which also includes the same value. Signed-off-by: Andreas Werner --- drivers/mcb/mcb-pci.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mcb/mcb-pci.c b/drivers

[PATCH 1/2] mcb: Replace ioremap and request_region with the devm version

Replaced ioremap with devm_ioremap and request_mem_region with devm_request_mem_region. This makes the code much more cleaner. Signed-off-by: Andreas Werner --- drivers/mcb/mcb-pci.c | 19 +++ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/drivers/mcb/mcb-pci.c b

[PATCH 0/2] make use of devm function in the mcb-pci driver

The first patch replace the ioremap an request_mem_region function with the corresponding devm function to have a more cleaner code and a better error handling. The sencoder patch just delete a unused variable. Andreas Werner (2): mcb: Replace ioremap and request_region with the devm version

[PATCH 0/2] make use of devm function in the mcb-pci driver

The first patch replace the ioremap an request_mem_region function with the corresponding devm function to have a more cleaner code and a better error handling. The sencoder patch just delete a unused variable. Andreas Werner (2): mcb: Replace ioremap and request_region with the devm version

[PATCH] mcb: Fixed bar number assignment for the gdd

The bar number is found in reg2 within the gdd. Therefore we need to change the assigment from reg1 to reg2 which is the correct location. Signed-off-by: Andreas Werner <andreas.wer...@men.de> --- drivers/mcb/mcb-parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/d

[PATCH] mcb: Fixed bar number assignment for the gdd

The bar number is found in reg2 within the gdd. Therefore we need to change the assigment from reg1 to reg2 which is the correct location. Signed-off-by: Andreas Werner --- drivers/mcb/mcb-parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mcb/mcb-parse.c b

Re: [PATCH v2 2/2] mcb: export bus information via sysfs

Looks good to me. I have tested this on the MEN SC24 with a MCB FPGA. Reviewed-by: Andreas Werner <andreas.wer...@men.de> Tested-by: Andreas Werner <andreas.wer...@men.de>

Re: [PATCH v2 2/2] mcb: export bus information via sysfs

. I have tested this on the MEN SC24 with a MCB FPGA. Reviewed-by: Andreas Werner Tested-by: Andreas Werner

Re: [PATCH v2 1/2] mcb: Correctly initialize the bus's device

ested this on the MEN SC24 AMD Board with a MCB FPGA. Reviewed-by: Andreas Werner <andreas.wer...@men.de> Tested-by: Andreas Werner <andreas.wer...@men.de>

Re: [PATCH v2 1/2] mcb: Correctly initialize the bus's device

SC24 AMD Board with a MCB FPGA. Reviewed-by: Andreas Werner Tested-by: Andreas Werner

Re: [PATCH 09/20] mfd: menf21bmc: Use devm_mfd_add_devices() for mfd_device registration

com> > CC: Andreas Werner <andreas.wer...@men.de> > --- Thanks for the Patch, looks good to me. Reviewed-by: Andreas Werner <andreas.wer...@men.de>

Re: [PATCH 09/20] mfd: menf21bmc: Use devm_mfd_add_devices() for mfd_device registration

On Tue, Apr 05, 2016 at 05:18:21PM +0530, Laxman Dewangan wrote: > Use devm_mfd_add_devices() for mfd devices registration and get > rid of .remove callback to remove mfd devices. This is done > by managed device framework. > > Signed-off-by: Laxman Dewangan > CC: Andreas Wer

[PATCH v2] gpio: add driver for MEN 16Z127 GPIO controller

The 16Z127 is a 32bit GPIO controller on a MCB FPGA. Every single line can be configured as input and output. Push pull and open drain are supported as well as setting a debounce value for the input lines. Signed-off-by: Andreas Werner <a...@wernerandy.de> --- drivers/gpio/Kconfig

[PATCH v2] gpio: add driver for MEN 16Z127 GPIO controller

The 16Z127 is a 32bit GPIO controller on a MCB FPGA. Every single line can be configured as input and output. Push pull and open drain are supported as well as setting a debounce value for the input lines. Signed-off-by: Andreas Werner --- drivers/gpio/Kconfig| 7 ++ drivers/gpio

[PATCH v2] introduce MEN 16Z127 GPIO controller driver

This patch adds the MEN 16Z127 GPIO Controller driver, which is 32bit wide and located within a MCB FPGA. changes in v2: - ported driver to use the generic MMIO library - added open drain support - added debounce support Andreas Werner (1): gpio: add driver for MEN

[PATCH v2] introduce MEN 16Z127 GPIO controller driver

This patch adds the MEN 16Z127 GPIO Controller driver, which is 32bit wide and located within a MCB FPGA. changes in v2: - ported driver to use the generic MMIO library - added open drain support - added debounce support Andreas Werner (1): gpio: add driver for MEN

Re: [PATCH] spi/spi-fsl-espi.c: Add spi cs polarity support

Hi, any comments for this patches? Regards Andy -- 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 0/4] remove auto exit of production and added sysfs interface

Regards Andy -- 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 0/4] remove auto exit of production and added sysfs interface

Regards Andy -- 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] spi/spi-fsl-espi.c: Add spi cs polarity support

Hi, any comments for this patches? Regards Andy -- 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: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

> There's actually a real world case that's pretty common where we want > to work with dates before 2016. When I power cycle my device and it > totally loses battery, I notice that the firmware seems to start as: > > 2013-01-21 00:50:02 > > It's possible we could need to run for a while in this

Re: [lm-sensors] LM90 driver and ti tmp461 detection

On Thu, Dec 17, 2015 at 06:57:51AM -0800, Guenter Roeck wrote: > On Thu, Dec 17, 2015 at 12:48:08PM +0100, Jean Delvare wrote: > > Hi Andreas, > > > > On Tue, 15 Dec 2015 16:11:24 +0100, Andreas Werner wrote: > > > here is the register dump of the tmp461. > &g

Re: [lm-sensors] LM90 driver and ti tmp461 detection

On Thu, Dec 17, 2015 at 06:57:51AM -0800, Guenter Roeck wrote: > On Thu, Dec 17, 2015 at 12:48:08PM +0100, Jean Delvare wrote: > > Hi Andreas, > > > > On Tue, 15 Dec 2015 16:11:24 +0100, Andreas Werner wrote: > > > here is the register dump of the tmp461. > &g

Re: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

> There's actually a real world case that's pretty common where we want > to work with dates before 2016. When I power cycle my device and it > totally loses battery, I notice that the firmware seems to start as: > > 2013-01-21 00:50:02 > > It's possible we could need to run for a while in this

Re: [lm-sensors] LM90 driver and ti tmp461 detection

On Thu, Dec 17, 2015 at 12:48:08PM +0100, Jean Delvare wrote: > Hi Andreas, > > On Tue, 15 Dec 2015 16:11:24 +0100, Andreas Werner wrote: > > here is the register dump of the tmp461. > > Thanks. > > > It seemse that we really cannot detect if it is a tmp461 or a

Re: [lm-sensors] LM90 driver and ti tmp461 detection

On Thu, Dec 17, 2015 at 12:48:08PM +0100, Jean Delvare wrote: > Hi Andreas, > > On Tue, 15 Dec 2015 16:11:24 +0100, Andreas Werner wrote: > > here is the register dump of the tmp461. > > Thanks. > > > It seemse that we really cannot detect if it is a tmp461 or a

[PATCH 4/4] doc/ABI: add documentation for the additional sysfs status information

Signed-off-by: Andreas Werner --- .../ABI/testing/sysfs-bus-i2c-devices-menf21bmc| 26 ++ 1 file changed, 26 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-menf21bmc b/Documentation/ABI/testing/sysfs-bus-i2c-devices-menf21bmc index 28d1fa2

[PATCH 3/4] mfd/menf21bmc.c: add additional sysfs entries for BMC status information

This patch adds additional sysfs entries to provide status information to the userland. The following informations are now provided: - Get operation hours counter - Get board slot address - Get powercycle counter - Set/get Hw Variant Signed-off-by: Andreas Werner

[PATCH 1/4] mfd/menf21bmc: remove auto exiting of production mode and add sysfs interface

to mechanism and add a sysfs interface to manually exiting the production e.g. during the EOL test of the board. Signed-off-by: Andreas Werner --- drivers/mfd/menf21bmc.c | 65 + 1 file changed, 44 insertions(+), 21 deletions(-) diff --git a/drive

[PATCH 2/4] doc/ABI: added sysfs description for the menf21bmc MFD driver

This patch add the description of the "mode" sysfs interface for the menf21bmc MFD driver. Signed-off-by: Andreas Werner --- Documentation/ABI/testing/sysfs-bus-i2c-devices-menf21bmc | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/ABI/testing

[PATCH 0/4] remove auto exit of production and added sysfs interface

This patch set introduces new sysfs entries for BMC status information as well as the ABI documention. The mfd core driver now does not exit the production mode automatically. The new sysfs entry allows the userland to exit the production mode if required. Andreas Werner (4): mfd/menf21bmc

[PATCH 4/4] doc/ABI: add documentation for the additional sysfs status information

Signed-off-by: Andreas Werner <andreas.wer...@men.de> --- .../ABI/testing/sysfs-bus-i2c-devices-menf21bmc| 26 ++ 1 file changed, 26 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-menf21bmc b/Documentation/ABI/testing/sysfs-bus-i2c-d

[PATCH 2/4] doc/ABI: added sysfs description for the menf21bmc MFD driver

This patch add the description of the "mode" sysfs interface for the menf21bmc MFD driver. Signed-off-by: Andreas Werner <andreas.wer...@men.de> --- Documentation/ABI/testing/sysfs-bus-i2c-devices-menf21bmc | 14 ++ 1 file changed, 14 insertions(+) create mode 1006

[PATCH 1/4] mfd/menf21bmc: remove auto exiting of production mode and add sysfs interface

to mechanism and add a sysfs interface to manually exiting the production e.g. during the EOL test of the board. Signed-off-by: Andreas Werner <andreas.wer...@men.de> --- drivers/mfd/menf21bmc.c | 65 + 1 file changed, 44 insertions(+), 2

[PATCH 3/4] mfd/menf21bmc.c: add additional sysfs entries for BMC status information

This patch adds additional sysfs entries to provide status information to the userland. The following informations are now provided: - Get operation hours counter - Get board slot address - Get powercycle counter - Set/get Hw Variant Signed-off-by: Andreas Werner

[PATCH 0/4] remove auto exit of production and added sysfs interface

This patch set introduces new sysfs entries for BMC status information as well as the ABI documention. The mfd core driver now does not exit the production mode automatically. The new sysfs entry allows the userland to exit the production mode if required. Andreas Werner (4): mfd/menf21bmc

Re: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

Okay, wrote up and tested the anchor date version. I think once you get over the initial weirdness of the approach this one is really much cleaner and safer. I tested this with the older rtc_tm_to_time() API and only ported it over to rtc_tm_to_time64() for submission, since my 3.14 kernel didn't

[PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

nchor date) to be able to read and write correct timestamps from/to the RTC. Signed-off-by: Julius Werner --- drivers/rtc/rtc-rk808.c | 48 1 file changed, 44 insertions(+), 4 deletions(-) diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk8

Re: [lm-sensors] LM90 driver and ti tmp461 detection

On Sat, Dec 12, 2015 at 11:08:42AM +0100, Jean Delvare wrote: > Hallo Andreas, > > On Thu, 10 Dec 2015 18:12:31 +0100, Andreas Werner wrote: > > thanks for the register dump :-) > > Can you please share the register dump of your TMP461 with us? > > Thanks, > -- &g

Re: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

Okay, wrote up and tested the anchor date version. I think once you get over the initial weirdness of the approach this one is really much cleaner and safer. I tested this with the older rtc_tm_to_time() API and only ported it over to rtc_tm_to_time64() for submission, since my 3.14 kernel didn't

[PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st

nchor date) to be able to read and write correct timestamps from/to the RTC. Signed-off-by: Julius Werner <jwer...@chromium.org> --- drivers/rtc/rtc-rk808.c | 48 1 file changed, 44 insertions(+), 4 deletions(-) diff --git a/drivers/rtc/rtc-r

Re: [lm-sensors] LM90 driver and ti tmp461 detection

On Sat, Dec 12, 2015 at 11:08:42AM +0100, Jean Delvare wrote: > Hallo Andreas, > > On Thu, 10 Dec 2015 18:12:31 +0100, Andreas Werner wrote: > > thanks for the register dump :-) > > Can you please share the register dump of your TMP461 with us? > > Thanks, > -- &g

Re: [lm-sensors] LM90 driver and ti tmp461 detection

>Hallo Andreas, > > On Thu, 10 Dec 2015 18:12:31 +0100, Andreas Werner wrote: >> thanks for the register dump > > Can you please share the register dump of your TMP461 with us? > Hi, yes for sure. Currently i have just a evaluation board my CPU without this sensor, but

Re: [lm-sensors] LM90 driver and ti tmp461 detection

>Hallo Andreas, > > On Thu, 10 Dec 2015 18:12:31 +0100, Andreas Werner wrote: >> thanks for the register dump > > Can you please share the register dump of your TMP461 with us? > Hi, yes for sure. Currently i have just a evaluation board my CPU without this sensor, but

Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st

> I'll try to review and evaluate both solution by the end of the week (no > guarantee though). To summarize, it's a pretty simple trade-off. Do you: a) try to detect every time the RTC deviated from the real-world time and correct it instantly? This can be done most of the time but there are

Re: LM90 driver and ti tmp461 detection

... >On Thu, Dec 10, 2015 at 09:49:43AM -0800, Guenter Roeck wrote: > > > >I have a DT based board yes, but i have also planed to submit my changes > >and also wanted to implement the autodetection of the chip. > > > >I have also planned (or need) to implement the "n-Factor Correction" for the >

Re: LM90 driver and ti tmp461 detection

... > On Thu, Dec 10, 2015 at 09:43:53AM -0800, Guenter Roeck wrote: > > > >There is one difference. The temperature ranges differ: > > > >TMP451: > >Standard Mode: 0 to +127 > >Extended Mode: -64 to +191 > > > >TMP461: > >Standard Mode: -40 to +127 > >Extended Mode: -64 to +191 > > > >Therefore

Re: LM90 driver and ti tmp461 detection

On Thu, Dec 10, 2015 at 08:41:57AM -0800, Guenter Roeck wrote: > On 12/10/2015 04:08 AM, Andreas Werner wrote: > >Hi, > >i have a temperature sensor device named "TI TMP461" which is quite the > >same than the tmp451 which is already included in the lm90 dr

LM90 driver and ti tmp461 detection

Hi, i have a temperature sensor device named "TI TMP461" which is quite the same than the tmp451 which is already included in the lm90 driver. I just want to add the tmp461 to the driver but currently i have no way to differ between the tmp461 and tmp451. The main different is that the tmp461

Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st

> I'll try to review and evaluate both solution by the end of the week (no > guarantee though). To summarize, it's a pretty simple trade-off. Do you: a) try to detect every time the RTC deviated from the real-world time and correct it instantly? This can be done most of the time but there are

LM90 driver and ti tmp461 detection

Hi, i have a temperature sensor device named "TI TMP461" which is quite the same than the tmp451 which is already included in the lm90 driver. I just want to add the tmp461 to the driver but currently i have no way to differ between the tmp461 and tmp451. The main different is that the tmp461

Re: LM90 driver and ti tmp461 detection

... > On Thu, Dec 10, 2015 at 09:43:53AM -0800, Guenter Roeck wrote: > > > >There is one difference. The temperature ranges differ: > > > >TMP451: > >Standard Mode: 0 to +127 > >Extended Mode: -64 to +191 > > > >TMP461: > >Standard Mode: -40 to +127 > >Extended Mode: -64 to +191 > > > >Therefore

Re: LM90 driver and ti tmp461 detection

... >On Thu, Dec 10, 2015 at 09:49:43AM -0800, Guenter Roeck wrote: > > > >I have a DT based board yes, but i have also planed to submit my changes > >and also wanted to implement the autodetection of the chip. > > > >I have also planned (or need) to implement the "n-Factor Correction" for the >

Re: LM90 driver and ti tmp461 detection

On Thu, Dec 10, 2015 at 08:41:57AM -0800, Guenter Roeck wrote: > On 12/10/2015 04:08 AM, Andreas Werner wrote: > >Hi, > >i have a temperature sensor device named "TI TMP461" which is quite the > >same than the tmp451 which is already included in the lm90 dr

Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st

> Thinking about all this: these's actually a totally different > alternative approach we could take if you wanted. It would fix S5 and > avoid all the anchor stuff, unless I'm crazy. > > Basically totally give up on the RTC time reflecting reality. Add a > "real time to rk808" and "rk808 time

Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st

> Thinking about all this: these's actually a totally different > alternative approach we could take if you wanted. It would fix S5 and > avoid all the anchor stuff, unless I'm crazy. > > Basically totally give up on the RTC time reflecting reality. Add a > "real time to rk808" and "rk808 time

Re: [v2 0/2] ata/libata-eh.c: introduce ATA_FLAG_NO_LOG_PAGE

On Mon, Dec 07, 2015 at 10:26:30AM -0500, Tejun Heo wrote: > On Fri, Dec 04, 2015 at 06:12:24PM +0100, Andreas Werner wrote: > > This patchset add a new ata port flag ATA_FLAG_NO_LOG_PAGE to be able > > to blacklist ports/controller which e.g. locks up on a log page read. >

[PATCH v2] RTC: RK808: Work around hardware bug on November 31st

point), we read out the (adjusted) alarm time beforehand and write it (newly adjusted) back afterwards. This way, system time and alarm time will always stay on the same calendar (as long as we're able to keep track of our anchor point, at least). Signed-off-by: Julius Werner --- drive

Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

> Still, you're right that adding the GET_TIME check wouldn't hurt... at > worst it just does nothing. I'll try it out. Hmm... so it basically works (when you hack the RTC read out of the firmware), but only on reboot for some reason (which makes it way less useful). After a full power off I'm

Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

> Technically you could still implement this and if firmware happens to > read the RTC (and doesn't correct things) then we won't be able to > correct things. ...but certainly if you read the old time and then > the new time and the old time was < 11/31 and the new time was >= > 11/31 you know

Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

[+Alexandre... sorry, didn't notice that you somehow fell off the thread again, but I presume you get rtc-linux anyway] > Agreed, scheduling alarms in the future is also an important point. So > I guess I'll update the patch to fix alarm scheduling and S3 as well, > and we'll just ignore S5 as

Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

> I was presuming that alarms were never set at power off time unless > power off happened due to an exceptional case. AKA: normal Linux > shutdown disables all alarms. Hmm... maybe I misunderstand how this works. Are alarms never used to wake from S5? (It doesn't seem to work on my HiSense

Re: [v2 0/2] ata/libata-eh.c: introduce ATA_FLAG_NO_LOG_PAGE

On Mon, Dec 07, 2015 at 10:26:30AM -0500, Tejun Heo wrote: > On Fri, Dec 04, 2015 at 06:12:24PM +0100, Andreas Werner wrote: > > This patchset add a new ata port flag ATA_FLAG_NO_LOG_PAGE to be able > > to blacklist ports/controller which e.g. locks up on a log page read. >

Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

> I was presuming that alarms were never set at power off time unless > power off happened due to an exceptional case. AKA: normal Linux > shutdown disables all alarms. Hmm... maybe I misunderstand how this works. Are alarms never used to wake from S5? (It doesn't seem to work on my HiSense

Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

[+Alexandre... sorry, didn't notice that you somehow fell off the thread again, but I presume you get rtc-linux anyway] > Agreed, scheduling alarms in the future is also an important point. So > I guess I'll update the patch to fix alarm scheduling and S3 as well, > and we'll just ignore S5 as

Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

> Technically you could still implement this and if firmware happens to > read the RTC (and doesn't correct things) then we won't be able to > correct things. ...but certainly if you read the old time and then > the new time and the old time was < 11/31 and the new time was >= > 11/31 you know

<    1   2   3   4   5   6   7   8   9   10   >