Re: [PATCH] hwmon: SENSORS_SBTSI should depend on X86

On Wed, Dec 16, 2020 at 8:31 AM Guenter Roeck wrote: > > On Wed, Dec 16, 2020 at 02:46:41PM +0100, Geert Uytterhoeven wrote: > > The AMD SB Temperature Sensor Interface (SB-TSI) is only present on AMD > > X86 SoCs. Hence add a dependency on X86, to prevent asking the user > > about this driver wh

Re: [PATCH linux hwmon-next v5 1/3] hwmon: (sbtsi) Add basic support for SB-TSI sensors

On Sat, Dec 12, 2020 at 8:44 AM Guenter Roeck wrote: > > On Fri, Dec 11, 2020 at 01:54:25PM -0800, Kun Yi wrote: > > SB Temperature Sensor Interface (SB-TSI) is an SMBus compatible > > interface that reports AMD SoC's Ttcl (normalized temperature), > > and res

Re: [PATCH linux hwmon-next v5 3/3] dt-bindings: (hwmon/sbtsi_tmep) Add SB-TSI hwmon driver bindings

On Fri, Dec 11, 2020 at 3:51 PM Guenter Roeck wrote: > > On 12/11/20 1:54 PM, Kun Yi wrote: > > Document device tree bindings for AMD SB-TSI emulated temperature > > sensor. > > > > Signed-off-by: Kun Yi > > Any reason for dropping Rob's Revie

Re: [PATCH linux hwmon-next v4 1/3] hwmon: (sbtsi) Add basic support for SB-TSI sensors

Thanks Guenter for reviewing! On Wed, Dec 2, 2020 at 5:37 PM Guenter Roeck wrote: > > On Wed, Dec 02, 2020 at 08:55:59AM -0800, Kun Yi wrote: > > SB Temperature Sensor Interface (SB-TSI) is an SMBus compatible > > interface that reports AMD SoC's Ttcl (normalized temperat

[PATCH linux hwmon-next v5 1/3] hwmon: (sbtsi) Add basic support for SB-TSI sensors

ly 98h for socket 0 and 90h for socket 1, but it could vary based on hardware address select pins. [1]: https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf Test status: tested reading temp1_input, and reading/writing temp1_max/min. Signed-off-by: Kun Yi --- drivers/hwmon/Kconfig | 10 +

[PATCH linux hwmon-next v5 3/3] dt-bindings: (hwmon/sbtsi_tmep) Add SB-TSI hwmon driver bindings

Document device tree bindings for AMD SB-TSI emulated temperature sensor. Signed-off-by: Kun Yi --- .../devicetree/bindings/hwmon/amd,sbtsi.yaml | 54 +++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml diff --git a

[PATCH linux hwmon-next v5 2/3] hwmon: (sbtsi) Add documentation

Document the SB-TSI sensor interface driver. Signed-off-by: Kun Yi --- Documentation/hwmon/index.rst | 1 + Documentation/hwmon/sbtsi_temp.rst | 40 ++ 2 files changed, 41 insertions(+) create mode 100644 Documentation/hwmon/sbtsi_temp.rst diff --git a

[PATCH linux hwmon-next v5 0/3] SB-TSI hwmon driver v5

v5: addressed comments in v4 v4: addressed comments in v3; converted DT binding to required schema v3: addressed comment in v2 and improved documentation v2: rewrote using devm_hwmon_device_register_with_info() API and addressed comments received in v1 v1: first version Kun Yi (3): hwmon

Re:

Much apologies for the super late reply.. I was out for an extended period of time due to personal circumstances. I have now addressed most of the comments in the v4 series. Also cc'ed Supreeth who works on the AMD System Manageability stack. On Wed, Dec 2, 2020 at 8:57 AM Kun Yi wrote: &

[PATCH linux hwmon-next v4 1/3] hwmon: (sbtsi) Add basic support for SB-TSI sensors

ly 98h for socket 0 and 90h for socket 1, but it could vary based on hardware address select pins. [1]: https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf Test status: tested reading temp1_input, and reading/writing temp1_max/min. Signed-off-by: Kun Yi --- drivers/hwmon/Kconfig | 10 +

[PATCH linux hwmon-next v4 3/3] dt-bindings: (hwmon/sbtsi_tmep) Add SB-TSI hwmon driver bindings

Document device tree bindings for AMD SB-TSI emulated temperature sensor. Signed-off-by: Kun Yi --- .../devicetree/bindings/hwmon/amd,sbtsi.yaml | 54 +++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml diff --git a

[PATCH linux hwmon-next v4 2/3] hwmon: (sbtsi) Add documentation

Document the SB-TSI sensor interface driver. Signed-off-by: Kun Yi --- Documentation/hwmon/index.rst | 1 + Documentation/hwmon/sbtsi_temp.rst | 40 ++ 2 files changed, 41 insertions(+) create mode 100644 Documentation/hwmon/sbtsi_temp.rst diff --git a

[PATCH linux hwmon-next v4 0/3] SB-TSI hwmon driver v4

v4: addressed comments in v3; converted DT binding to required schema v3: addressed comment in v2 and improved documentation v2: rewrote using devm_hwmon_device_register_with_info() API and addressed comments received in v1 v1: first version Kun Yi (3): hwmon: (sbtsi) Add basic support for

[PATCH 2/2] ledtrig-gpio: 0 is a valid GPIO number

GPIO number 0 is a valid case to handle. Use -1 as initial value and use gpio_is_valid() to determine validity of the GPIO number. Signed-off-by: Kun Yi Change-Id: I4a29f98b237fd0d8ba4dd2a28219d4429f2ccfff --- drivers/leds/trigger/ledtrig-gpio.c | 16 +--- 1 file changed, 5

[PATCH 0/2] Fix LED GPIO trigger behavior

select the pin as a GPIO instead of, say an I2C pin. I'd like to learn whether it is appropriate to assume user of ledtrig-gpio really intends to use GPIOs and not some weird pins that are used as other functions. Kun Yi (2): ledtrig-gpio: Request user input pin as GPIO ledtrig-gpio: 0

[PATCH 1/2] ledtrig-gpio: Request user input pin as GPIO

correctly requested as GPIO Signed-off-by: Kun Yi Change-Id: I657e3e108552612506775cc348a8b4b35d40cac5 --- drivers/leds/trigger/ledtrig-gpio.c | 31 +++-- 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/drivers/leds/trigger/ledtrig-gpio.c b/drivers/leds/trigger

Re: [PATCH v1 1/1] pinctrl: nuvoton: modify NPCM7xx pin configuration function

On Wed, Nov 7, 2018 at 5:44 AM Tomer Maimon wrote: > > Modify GPIO direction setting in pin configuration function by using > generic GPIO functions to set the GPIO direction instead of direct > access to the GPIO direction register. > > Signed-off-by: Tomer Maimon Tested-by: K

Re: [PATCH 2/2] pinctrl: pinctrl-npcm7xx: Set BGPIOF_VOLATILE_REG

On Tue, Oct 30, 2018 at 5:08 AM Linus Walleij wrote: > > On Wed, Oct 17, 2018 at 11:30 PM Kun Yi wrote: > > > Indicate that the pins are both controlled by the pinctrl driver and the > > generic GPIO driver, thus GPIO driver should read the register value > > before

[PATCH 1/2] gpio: gpio-mmio: Allow volatile shadow regs

-by: Kun Yi --- drivers/gpio/gpio-mmio.c| 50 + include/linux/gpio/driver.h | 2 ++ 2 files changed, 36 insertions(+), 16 deletions(-) diff --git a/drivers/gpio/gpio-mmio.c b/drivers/gpio/gpio-mmio.c index 935292a30c99..5e13e43a793d 100644 --- a/drivers/gpio

[PATCH 0/2] Allow gpio-mmio to co-exist with pinctrl driver

pinctrl driver is lost. Kun Yi (2): gpio: gpio-mmio: Allow volatile shadow regs pinctrl: pinctrl-npcm7xx: Set BGPIOF_VOLATILE_REG drivers/gpio/gpio-mmio.c | 50 +++ drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 3 +- include/linux/gpio/driver.h

[PATCH 2/2] pinctrl: pinctrl-npcm7xx: Set BGPIOF_VOLATILE_REG

Indicate that the pins are both controlled by the pinctrl driver and the generic GPIO driver, thus GPIO driver should read the register value before updating, instead of using the stored shadow register values. Signed-off-by: Kun Yi --- drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 3 ++- 1 file

Re: [RFC PATCH v2 1/4] dt-bindings: misc: Add bindings for misc. BMC control fields

Andrew, Benjamin, Rob, Thanks for bringing up the set of patches and a great discussion. After going through the thread I figured that I'd like to share a few things we needed to hack when programming several BMC boards: - Debug UART enable/mux - Disable GPIO D/E passthrough (I think this is supp

Re: [patch v12 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver

Thanks for working on the driver, Oleksandr. I gave this a try on a board with Aspeed 2520. One question below: On Tue, Nov 14, 2017 at 8:11 AM, Oleksandr Shamray wrote: > Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller. > > Driver implements the following jtag ops: > -