Re: [PATCH v2 2/2] hwmon: add generic GPIO brownout support

2018-11-05 Thread Marco Felsch
On 18-11-02 23:05, Trent Piepho wrote: > On Fri, 2018-11-02 at 07:38 +0100, Marco Felsch wrote: > > On 18-11-01 18:21, Trent Piepho wrote: > > > On Thu, 2018-11-01 at 08:14 -0700, Guenter Roeck wrote: > > > > On Thu, Nov 01, 2018 at 03:53:12PM +0100, Marco Felsch wrote: > > > > > > > > > > > > >

Re: [PATCH 2/4] x86/amd_nb: add support for newer PCI topologies

2018-11-05 Thread Borislav Petkov
On Fri, Nov 02, 2018 at 06:11:07PM +, Woods, Brian wrote: > Add support for new processors which have multiple PCI root complexes > per data fabric/SMN interface. Please write out abbreviations. I believe it is only you and I who know what SMN means. :) > The interfaces per root complex are

Re: [PATCH 4/4] hwmon: k10temp: add support for AMD F17h M30h CPUs

2018-11-05 Thread Borislav Petkov
On Fri, Nov 02, 2018 at 06:11:12PM +, Woods, Brian wrote: > Add support for AMD family 17h model 30h processors for k10temp. Model > 30h is functionally the same as model 01h processors (as far as k10temp > is concerned), just the PCI device IDs need to be updated. > > Signed-off-by: Brian

[PATCH v5 0/4] hwmon: (ina3221) Implement PM runtime to save power

2018-11-05 Thread Nicolin Chen
This series patches implement PM runtime feature in the ina3221 hwmon driver (PATCH-4). However, PATCH-[1:3] are required to make sure that the PM runtime feature would be functional and safe. Changelog v4->v5: * Dropped the change for hwmon core; Shifted all the patch indexes * Used i2c_client

[PATCH v5 4/4] hwmon: (ina3221) Add PM runtime support

2018-11-05 Thread Nicolin Chen
If all three channels are disabled via in[123]_enable ABI, the driver could suspend the chip for power saving purpose. So this patch adds the PM runtime support in order to gain more power control than system suspend and resume use case. For PM runtime, there are a few related changes happening:

[PATCH v5 2/4] hwmon: (ina3221) Serialize sysfs ABI accesses

2018-11-05 Thread Nicolin Chen
This change adds a mutex to serialize accesses of sysfs attributes. This is required when polling CVRF bit of the MASK/ENABLE register because this bit is cleared on a read of this MASK/ENABLE register or a write to CONFIG register, which means that this bit might be accidentally cleared by

[PATCH v5 3/4] hwmon: (ina3221) Make sure data is ready before reading

2018-11-05 Thread Nicolin Chen
The data might need some time to get ready after channel enabling, although the data register is always readable. The CVRF bit is to indicate that data conversion is finished, so polling the CVRF bit before data reading could ensure the result being valid. An alternative way could be to wait for

[PATCH v5 1/4] hwmon: (ina3221) Check channel status for alarms attribute read

2018-11-05 Thread Nicolin Chen
There is nothing critically wrong to read these two attributes without having a is_enabled() check at this point. But reading the MASK_ENABLE register would clear the CVRF bit according to the datasheet. So it'd be safer to fence for disabled channels in order to add pm runtime feature.

Re: [PATCH 2/4] x86/amd_nb: add support for newer PCI topologies

2018-11-05 Thread Borislav Petkov
On Mon, Nov 05, 2018 at 08:33:34PM +, Woods, Brian wrote: > I think having them togeter is cleaner. If you aren't finding any > misc IDs, I highly doubt you'll find any root IDs. There shouldn't > be much of a difference in how fast the function exits, either way. > If you want it the other

Re: [PATCH 2/4] x86/amd_nb: add support for newer PCI topologies

2018-11-05 Thread Bjorn Helgaas
[+cc Takashi, Andy, Colin, Myron for potential distro impact] [Beginning of thread: https://lore.kernel.org/linux-pci/20181102181055.130531-1-brian.wo...@amd.com/] On Sat, Nov 03, 2018 at 12:29:48AM +0100, Borislav Petkov wrote: > On Fri, Nov 02, 2018 at 02:59:25PM -0500, Bjorn Helgaas wrote: >

Re: [PATCH 2/4] x86/amd_nb: add support for newer PCI topologies

2018-11-05 Thread Woods, Brian
On Mon, Nov 05, 2018 at 10:42:33PM +0100, Borislav Petkov wrote: > Yes please. Because this is the usual kernel coding style of calling a > function (or a loop which has some result in this case) and testing that > result immediately after the function call. Done. > You say "correct" as there is