The inX_enable interface allows user space to enable or disable
the corresponding channel. Meanwhile, according to hwmon ABI, a
disabled channel/sensor should return -ENODATA as a read result.
However, there're configurable nodes sharing the same __show()
functions. So this change also adds to che
This series of patch is to add three sets of sysfs nodes for ina3221
hwmon driver. PATCH-1 adds two power sysfs nodes while PATCH-2 adds
an enable node.
Note: both two patches are rebased upon the following patch:
"hwmon: ina3221: Read channel input source info from DT"
As this patch
The hwmon sysfs ABI supports powerX_input and powerX_crit. This
can ease user space programs who care more about power in total
than voltage or current individually.
So this patch adds these two sysfs nodes for INA3221 driver.
Signed-off-by: Nicolin Chen
---
Documentation/hwmon/ina3221 | 4 +
On Tue, Sep 25, 2018 at 08:40:59PM -0700, Guenter Roeck wrote:
> >>>+2) child nodes
> >>>+ Required properties:
> >>>+ - reg: Must be 0, 1 or 2, corresponding to IN1, IN2 or IN3 port of
> >>>INA3221
> >>>+ input@0 {
> >>>+ reg = <0x0>;
> >>>+ status = "disabled";
> >>saying
On 9/26/18 2:00 AM, Helen Koike wrote:
> This series is reviving an old patchwork.
> Booting from a mapped device requires an initramfs. This series is
> allows for device-mapper targets to be configured at boot time for
> use early in the boot process (as the root device or otherwise).
>
> Exa
From: Will Drewry
Add a dm= kernel parameter modeled after the md= parameter from
do_mounts_md. It allows for device-mapper targets to be configured at
boot time for use early in the boot process (as the root device or
otherwise).
Signed-off-by: Will Drewry
Signed-off-by: Kees Cook
[rework to
From: Enric Balletbo i Serra
Add a dm_ioctl_cmd to issue the equivalent of a DM ioctl call in kernel.
Signed-off-by: Enric Balletbo i Serra
---
drivers/md/dm-ioctl.c | 50 +++
include/linux/device-mapper.h | 6 +
2 files changed, 56 insertions(+)
d
This series is reviving an old patchwork.
Booting from a mapped device requires an initramfs. This series is
allows for device-mapper targets to be configured at boot time for
use early in the boot process (as the root device or otherwise).
Example, the following could be added in the boot paramet
On 09/25/2018 08:08 PM, Nicolin Chen wrote:
Hello Guenter,
On Tue, Sep 25, 2018 at 06:52:29PM -0700, Guenter Roeck wrote:
+2) child nodes
+ Required properties:
+ - reg: Must be 0, 1 or 2, corresponding to IN1, IN2 or IN3 port of INA3221
+
+ Optional properties:
+ - label: Name of the inpu
Hello Guenter,
On Tue, Sep 25, 2018 at 06:52:29PM -0700, Guenter Roeck wrote:
> > +2) child nodes
> > + Required properties:
> > + - reg: Must be 0, 1 or 2, corresponding to IN1, IN2 or IN3 port of
> > INA3221
> > +
> > + Optional properties:
> > + - label: Name of the input source
> > + -
Hi Nicolin,
On 09/25/2018 03:59 PM, Nicolin Chen wrote:
Texas Instruments INA3221 is a triple-channel shunt and bus
voltage monitor. This patch adds a DT binding doc for it.
Signed-off-by: Nicolin Chen
---
Changelog
v4->v5:
* Replaced "input-id" with "reg" and added address-cells and size-ce
Texas Instruments INA3221 is a triple-channel shunt and bus
voltage monitor. This patch adds a DT binding doc for it.
Signed-off-by: Nicolin Chen
---
Changelog
v4->v5:
* Replaced "input-id" with "reg" and added address-cells and size-cells
* Replaced "input-label" with "label"
* Replaced "shun
An ina3221 chip has three input ports. Each port is used
to measure the voltage and current of its input source.
The DT binding now has defined bindings for their input
sources, so the driver should read these information and
handle accordingly.
This patch adds a new structure of input source spe
This series adds a initial DT binding doc for ina3221. It defines
a child node to describe the input source of each ina3221 channel.
Then it changes the driver to handle the information properly.
Changelog
v4->v5:
* Changed two property names of child node (PATCH-1)
* Changed the driver accordin
On 25/09/2018 15:38, Paul Cercueil wrote:
>
> Le 24 sept. 2018 9:14 AM, Daniel Lezcano a écrit :
>>
>> On 24/09/2018 08:53, Paul Cercueil wrote:
>>>
>>> Le 24 sept. 2018 07:58, Daniel Lezcano a écrit
>>> :
On 24/09/2018 07:49, Paul Cercueil wrote:
>
> Le 24 sept. 2018 07:35
On Tue, Sep 25, 2018 at 11:26 AM Joel Fernandes (Google)
wrote:
>
> Hi Paul,
> These patches are documentation updates for the rcu_dynticks rolling into
> rcu_data and also the updates to the fact that there's a single rcu_state now.
> Its based on your rcu/dev branch.
>
> Next I'm thinking of tac
The rcu_state structure doesn't have a gp_seq_needed field. Update the
description under rcu_data accordingly, to reflect this.
Signed-off-by: Joel Fernandes (Google)
---
.../RCU/Design/Data-Structures/Data-Structures.html| 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff
Since commit fced9c8cfe6b ("rcu: Avoid resched_cpu() when rescheduling
the current CPU"), resched_cpu is not directly called from
sync_sched_exp_handler. Update the documentation about the same.
Signed-off-by: Joel Fernandes (Google)
---
.../Expedited-Grace-Periods/Expedited-Grace-Periods.html
An important note under the rcu_segcblist description could use a
more detailed description. Especially explanation of the scenario
where the ->head field may be temporarily NULL making it not wise to
rely on it to determine if callbacks are associated with the
rcu_segcblist. Thanks Paul for clarif
rcu_dynticks was folded into rcu_data structure. Update the data
structures RCU document accordingly.
Signed-off-by: Joel Fernandes (Google)
---
.../BigTreeClassicRCUBHdyntick.svg| 695 --
.../Data-Structures/Data-Structures.html | 92 +--
2 files changed, 25 in
Hi Paul,
These patches are documentation updates for the rcu_dynticks rolling into
rcu_data and also the updates to the fact that there's a single rcu_state now.
Its based on your rcu/dev branch.
Next I'm thinking of tackling 'RCU Callback Handling' and further digging into
the dyntick handling an
On Tue, 2018-09-25 at 19:03 +0200, Peter Zijlstra wrote:
> On Fri, Sep 21, 2018 at 08:03:27AM -0700, Yu-cheng Yu wrote:
> > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
> > index 4bd56079048f..9f51b0e1da25 100644
> > --- a/arch/x86/kernel/fpu/core.c
> > +++ b/arch/x86/kernel
On Fri, Sep 21, 2018 at 08:03:27AM -0700, Yu-cheng Yu wrote:
> diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
> index 4bd56079048f..9f51b0e1da25 100644
> --- a/arch/x86/kernel/fpu/core.c
> +++ b/arch/x86/kernel/fpu/core.c
> @@ -365,8 +365,13 @@ void fpu__drop(struct fpu *fpu)
On Fri, Sep 21, 2018 at 08:03:26AM -0700, Yu-cheng Yu wrote:
> diff --git a/arch/x86/include/asm/fpu/internal.h
> b/arch/x86/include/asm/fpu/internal.h
> index a38bf5a1e37a..f1f9bf91a0ab 100644
> --- a/arch/x86/include/asm/fpu/internal.h
> +++ b/arch/x86/include/asm/fpu/internal.h
> @@ -93,7 +93,
On Tue, 2018-09-25 at 18:27 +0200, Peter Zijlstra wrote:
> On Fri, Sep 21, 2018 at 08:03:25AM -0700, Yu-cheng Yu wrote:
>
> > diff --git a/arch/x86/kernel/cpu/scattered.c
> > b/arch/x86/kernel/cpu/scattered.c
> > index 772c219b6889..63cbb4d9938e 100644
> > --- a/arch/x86/kernel/cpu/scattered.c
> >
On Fri, Sep 21, 2018 at 08:03:25AM -0700, Yu-cheng Yu wrote:
> diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
> index 772c219b6889..63cbb4d9938e 100644
> --- a/arch/x86/kernel/cpu/scattered.c
> +++ b/arch/x86/kernel/cpu/scattered.c
> @@ -21,6 +21,7 @@ struct cpuid_b
On Tue, 25 Sep 2018 16:06:56 +0300
Jarkko Sakkinen wrote:
> Documentation of the features of the Software Guard eXtensions used
> by the Linux kernel and basic design choices for the core and driver
> and functionality.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> Documentation/index.rst
Documentation of the features of the Software Guard eXtensions used
by the Linux kernel and basic design choices for the core and driver
and functionality.
Signed-off-by: Jarkko Sakkinen
---
Documentation/index.rst | 1 +
Documentation/x86/intel_sgx.rst | 185 ++
Intel(R) SGX is a set of CPU instructions that can be used by applications
to set aside private regions of code and data. The code outside the enclave
is disallowed to access the memory inside the enclave by the CPU access
control. In a way you can think that SGX provides inverted sandbox. It
prot
On Tue, Sep 25, 2018 at 11:14:56AM +0200, David Hildenbrand wrote:
> Let's perform all checking + offlining + removing under
> device_hotplug_lock, so nobody can mess with these devices via
> sysfs concurrently.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Ra
Let's document the magic a bit, especially why device_hotplug_lock is
required when adding/removing memory and how it all play together with
requests to online/offline memory from user space.
Cc: Jonathan Corbet
Cc: Michal Hocko
Cc: Andrew Morton
Reviewed-by: Pavel Tatashin
Reviewed-by: Rashmi
add_memory() currently does not take the device_hotplug_lock, however
is aleady called under the lock from
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
to synchronize against CPU hot-remove and similar.
In general, we should hold the device_hotplug
device_online() should be called with device_hotplug_lock() held.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Reviewed-by: Pavel Tatashin
Reviewed-by: Rashmica Gupta
Signed-off-by: David Hildenbrand
---
arch/p
Let's perform all checking + offlining + removing under
device_hotplug_lock, so nobody can mess with these devices via
sysfs concurrently.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Reviewed-by: Pavel Tatashin
R
There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
fix concurrent memory hot-add deadlock"), which tried to fix a possible
lock inversion reported and discussed in [1] due to the two locks
a) device_lock()
b) mem_hotplug_lock
While add_memory() first takes b), f
remove_memory() is exported right now but requires the
device_hotplug_lock, which is not exported. So let's provide a variant
that takes the lock and only export that one.
The lock is already held in
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
Reading through the code and studying how mem_hotplug_lock is to be used,
I noticed that there are two places where we can end up calling
device_online()/device_offline() - online_pages()/offline_pages() without
the mem_hotplug_lock. And there are other places where we call
device_online()/device_o
37 matches
Mail list logo
