Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

[Dmitry Torokhov]

On Fri, Jun 24, 2016 at 09:19:32AM +0200, Benjamin Tissoires wrote:
> On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> > On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > > +
> > > +static struct i2c_driver rmi_smb_driver = {
> > > + .driver = {
> > > + .owner  = THIS_MODULE,
> > > + .name   = "rmi4_smbus",
> > > + .pm = _smb_pm,
> > > + .resume = rmi_smb_resume,
> > 
> > Why rmi_smb_resume is not part of rmi_smb_pm?
> > 
> 
> This is because rmi_smbus device both have a PS/2 interface and a SMBus
> one. I'll have to check again now that I have a slightly different way
> of binding smbus devices in my tree, but the issue was:
> - having resume part of pm means it will get caught by PM directly
> - the PS/2 node gets also resumed by PM
> - calling PS/2 commands during resume switches the devices back into
>   PS/2 and stops the SMBus communication.
> 
> So it's easier to wait only for the PS/2 PM resume call which will call
> the SMBus resume function when the device is in a proper state.
> 
> I'll send out the updated patch with your comments next week hopefully.

Hmm, I think you will have to walk me through resume process. How do we
tie in PS/2 and I2C on these devices abd have PS/2 code call into this
driver?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/2] kbuild, x86: Track generated headers with generated-y

[James Hogan]

Track generated header files which aren't already in genhdr-y, alongside
generic-y wrappers in the */include/generated/[uapi/]asm/ directories.
Currently only x86 generates extra headers in these directories, for the
purposes of enumerating system calls for different ABIs, and xen
hypercalls.

This will allow the asm-generic wrapper handling code to remove stale
wrappers when files are removed from generic-y, without also removing
these headers which are generated separately.

Reported-by: kbuild test robot 
Signed-off-by: James Hogan 
Acked-by: Arnd Bergmann 
Cc: Michal Marek 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Jonathan Corbet 
Cc: linux-kbu...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-doc@vger.kernel.org
---
Changes in v4:
- None (resend).

Changes in v2:
- New patch (thanks to kbuild test robot).
---
 Documentation/kbuild/makefiles.txt | 14 ++
 arch/x86/include/asm/Kbuild|  6 ++
 2 files changed, 20 insertions(+)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 13f888a02a3d..385a5ef41c17 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -47,6 +47,7 @@ This document describes the Linux kernel Makefiles.
--- 7.2 genhdr-y
--- 7.3 destination-y
--- 7.4 generic-y
+   --- 7.5 generated-y
 
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1319,6 +1320,19 @@ See subsequent chapter for the syntax of the Kbuild file.
Example: termios.h
#include 
 
+   --- 7.5 generated-y
+
+   If an architecture generates other header files alongside generic-y
+   wrappers, and not included in genhdr-y, then generated-y specifies
+   them.
+
+   This prevents them being treated as stale asm-generic wrappers and
+   removed.
+
+   Example:
+   #arch/x86/include/asm/Kbuild
+   generated-y += syscalls_32.h
+
 === 8 Kbuild Variables
 
 The top Makefile exports the following variables:
diff --git a/arch/x86/include/asm/Kbuild b/arch/x86/include/asm/Kbuild
index aeac434c9feb..2cfed174e3c9 100644
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@ -1,5 +1,11 @@
 
 
+generated-y += syscalls_32.h
+generated-y += syscalls_64.h
+generated-y += unistd_32_ia32.h
+generated-y += unistd_64_x32.h
+generated-y += xen-hypercalls.h
+
 genhdr-y += unistd_32.h
 genhdr-y += unistd_64.h
 genhdr-y += unistd_x32.h
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: devicetree random-seed properties, was: "Re: [PATCH v7 0/9] x86/mm: memory area address KASLR"

[Andy Lutomirski]

On Fri, Jun 24, 2016 at 12:04 PM, Kees Cook  wrote:
> On Fri, Jun 24, 2016 at 9:02 AM, Jason Cooper  wrote:
>> Thomas,
>>
>> Sorry for wandering off the topic of your series.  The big take away for
>> me is that you and Kees are concerned about x86 systems pre-RDRAND.
>> Just as I'm concerned about deployed embedded systems without bootloader
>> support for hw-rngs and so forth.
>>
>> Whatever final form the approach takes for ARM/dt, I'll make sure we can
>> extend it to legacy x86 systems.
>
> Yeah, this seems like a productive conversation to me. :)

I have an old patch and spec I need to dust off that does this during
*very* early boot on x86 using MSRs so that kASLR can use it.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/1] hwmon: Add support for INA3221 Triple Current/Voltage Monitors

[Guenter Roeck]

On Fri, Jun 24, 2016 at 12:30:56PM -0500, Andrew F. Davis wrote:
> On 06/24/2016 11:46 AM, Guenter Roeck wrote:
> > On Fri, Jun 24, 2016 at 10:02:51AM -0500, Andrew F. Davis wrote:
> >> On 06/18/2016 10:16 AM, Guenter Roeck wrote:
> >>>
> >>> The chip registers are 16 bit. Can you repeat the command using the "w"
> >>> option ?
> >>>
> >>
> >> # i2cdump -y 2 0x40 w
> >>  0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
> >> 00: 2771       f87f
> >> 08: f87f f87f f87f f87f f87f  fe7f 0300
> >> 10: 1027 2823      
> >> 18:    f8f8   4954 2032
> >> 20: 2771       f87f
> >> 28: f87f f87f f87f f87f f87f  fe7f 0300
> >> 30: 1027 2823      
> >> 38:    f8f8   4954 2032
> >> 40: 2771       f87f
> >> 48: f87f f87f f87f f87f f87f  fe7f 0300
> >> 50: 1027 2823      
> >> 58:    f8f8   4954 2032
> >> 60: 2771       f87f
> >> 68: f87f f87f f87f f87f f87f  fe7f 0300
> >> 70: 1027 2823      
> >> 78:    f8f8   4954 2032
> >> 80: 2771       f87f
> >> 88: f87f f87f f87f f87f f87f  fe7f 0300
> >> 90: 1027 2823      
> >> 98:    f8f8   4954 2032
> >> a0: 2771       f87f
> >> a8: f87f f87f f87f f87f f87f  fe7f 0300
> >> b0: 1027 2823      
> >> b8:    f8f8   4954 2032
> >> c0: 2771       f87f
> >> c8: f87f f87f f87f f87f f87f  fe7f 0300
> >> d0: 1027 2823      
> >> d8:    f8f8   4954 2032
> >> e0: 2771       f87f
> >> e8: f87f f87f f87f f87f f87f  fe7f 0300
> >> f0: 1027 2823      
> >> f8:    f8f8   4954 2032
> > 
> > Thanks a lot!
> > 
> 
> Feel free to completely ignore the first register dump I sent, I did it
> for the wrong device anyway :).
> 
> I had just gotten done reading this:
> https://lkml.org/lkml/2015/12/10/459
> and accidentally got EVMs confused did the test for the TMP461, but it
> does look like on startup register 0x16 can be used to differentiate the
> parts, if the TMP461 hadn't gone into a different driver.
> 
Good catch.

That makes me wonder if we should move tmp461 support to the lm90 driver.
What do you think ? Problem is that tmp461 will be auto-detected as tmp451
by the lm90 driver, which is less than perfect.

My test script for ina3221 only accepts a single value - 16380 - for the
limit registers. Seems odd. I'll have to look into it some more.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: devicetree random-seed properties, was: "Re: [PATCH v7 0/9] x86/mm: memory area address KASLR"

[Kees Cook]

On Fri, Jun 24, 2016 at 9:02 AM, Jason Cooper  wrote:
> Thomas,
>
> Sorry for wandering off the topic of your series.  The big take away for
> me is that you and Kees are concerned about x86 systems pre-RDRAND.
> Just as I'm concerned about deployed embedded systems without bootloader
> support for hw-rngs and so forth.
>
> Whatever final form the approach takes for ARM/dt, I'll make sure we can
> extend it to legacy x86 systems.

Yeah, this seems like a productive conversation to me. :)

> Ard,
>
> On Fri, Jun 24, 2016 at 12:54:01PM +0200, Ard Biesheuvel wrote:
>> On 24 June 2016 at 03:11, Jason Cooper  wrote:
>> > On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
> ...
>> >> On arm64, only DT is used for KASLR (even when booting via ACPI). My
>> >> first draft used register x1, but this turned out to be too much of a
>> >> hassle, since parsing the DT is also necessary to discover whether
>> >> there is a 'nokaslr' argument on the kernel command line. So the
>> >> current implementation only supports a single method, which is the
>> >> /chosen/kaslr-seed uint64 property.
>> >
>> > Ok, just to clarify (after a short offline chat), my goal is to set a
>> > userspace,random-seed  property in the device tree once.
>> > The bootloader scripts would also only need to be altered once.
>> >
>> > Then, at each boot, the bootloader reads the entirety of
>> > /var/lib/misc/random-seed (512 bytes) into the configured address.
>> > random-seed could be in /boot, or on a flash partition.
>> >
>> > The decompressor would consume a small portion of that seed for kaslr
>> > and such.  After that, the rest would be consumed by random.c to
>> > initialize the entropy pools.
>> >
>>
>> I see. This indeed has little to do with the arm64 KASLR case, other
>> than that they both use a DT property.
>>
>> In the arm64 KASLR case, I deliberately chose to leave it up to the
>> bootloader/firmware to roll the dice, for the same reason you pointed
>> out, i.e., that there is no architected way on ARM to obtain random
>> bits. So in that sense, what you are doing is complimentary to my
>> work, and a KASLR  aware arm64 bootloader would copy some of its
>> random bits taken from /var/lib/misc/random-seed into the
>> /chosen/kaslr-seed DT property.
>
> Here I disagree.  We have two distinct entropy sources; the hw-rng
> currently feeding kaslr via the /chosen/kaslr-seed property, and the
> seasoned userspace seed I propose handed in via an extra property.
>
> Having the bootloader conflate those two sources as if they are equal
> seems to muddy the waters.  I prefer to have bootloaders tell me where
> they got the data rather than to hope the bootloader sourced and mixed
> it well.
>
>> Note that, at the moment, this DT property is only an internal
>> contract between the kernel's UEFI stub and the kernel proper, so we
>> could still easily change that if necessary.
>
> Ideally, I'd prefer to be deliberate with the DT properties, e.g.
>
> random-seed,hwrng <--- bootloader reads from hw-rng
> random-seed,userspace <--- bootloader reads file from us to addr
>
> The kernel decompressor can init kaslr with only one of the two
> properties populated.  If both properties are present, then the
> decompressor can extract a u64 from userspace-seed and mix it with
> hwrng-seed before use.
>
> The small devicetree portion of my brain feels like 'kaslr-seed' is
> telling the OS what to do with the value.  Whereas devicetree is
> supposed to be describing the hardware.  Or, in this case, describing
> the source of the data.
>
> Given that more entropy from more sources is useful for random.c a bit
> later in the boot process, it might be worth making hwrng-seed larger
> than u64 as well.  This way we can potentially seed random.c from two
> sources *before* init even starts.  Without having to depend on the
> kernel's hw-rng driver being probed.  After all, it might not have been
> built, or it could be a module that's loaded later.
>
> I've attached a draft patch to chosen.txt.
>
> thx,
>
> Jason.
>
>
> --->8-
> diff --git a/Documentation/devicetree/bindings/chosen.txt 
> b/Documentation/devicetree/bindings/chosen.txt
> index 6ae9d82d4c37..61f15f04bc0a 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -45,6 +45,52 @@ on PowerPC "stdout" if "stdout-path" is not found.  
> However, the
>  "linux,stdout-path" and "stdout" properties are deprecated. New platforms
>  should only use the "stdout-path" property.
>
> +random-seed properties
> +--
> +
> +The goal of these properties are to provide an entropy seed early in the boot
> +process.  Typically, this is needed by the kernel decompressor for
> +initializing KASLR.  At that point, the kernel entropy pools haven't been
> +initialized yet, and any hardware rng drivers haven't been loaded yet, if 
> 

Re: [PATCH] capabilities: add capability cgroup controller

[Eric W. Biederman]

"Serge E. Hallyn"  writes:

> Quoting Tejun Heo (t...@kernel.org):
>> Hello,
>> 
>> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
>> > Quoting Tejun Heo (t...@kernel.org):
>> > > But isn't being recursive orthogonal to using cgroup?  Why not account
>> > > usages recursively along the process hierarchy?  Capabilities don't
>> > > have much to do with cgroup but everything with process hierarchy.
>> > > That's how they're distributed and modified.  If monitoring their
>> > > usages is necessary, it makes sense to do it in the same structure.
>> > 
>> > That was my argument against using cgroups to enforce a new bounding
>> > set.  For tracking though, the cgroup process tracking seems as applicable
>> > to this as it does to systemd tracking of services.  It tracks a task and
>> > the children it forks.
>> 
>> Just monitoring is less jarring than implementing security enforcement
>> via cgroup, but it is still jarring.  What's wrong with recursive
>> process hierarchy monitoring which is in line with the whole facility
>> is implemented anyway?
>
> As I think Topi pointed out, one shortcoming is that if there is a short-lived
> child task, using its /proc/self/status is racy.  You might just miss that it
> ever even existed, let alone that the "application" needed it.
>
> Another alternative we've both mentioned is to use systemtap.  That's not
> as nice a solution as a cgroup, but then again this isn't really a common
> case, so maybe it is precisely what a tracing infrastructure is meant for.

Hmm.

We have capability use wired up into auditing.  So we might be able to
get away with just adding an appropriate audit message in
commoncap.c:cap_capable that honors the audit flag and logs an audit
message.  The hook in selinux already appears to do that.

Certainly audit sounds like the subsystem for this kind of work, as it's
whole point in life is logging things, then something in userspace can
just run over the audit longs and build a nice summary.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/1] hwmon: Add support for INA3221 Triple Current/Voltage Monitors

[Andrew F. Davis]

On 06/24/2016 11:46 AM, Guenter Roeck wrote:
> On Fri, Jun 24, 2016 at 10:02:51AM -0500, Andrew F. Davis wrote:
>> On 06/18/2016 10:16 AM, Guenter Roeck wrote:
>>>
>>> The chip registers are 16 bit. Can you repeat the command using the "w"
>>> option ?
>>>
>>
>> # i2cdump -y 2 0x40 w
>>  0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
>> 00: 2771       f87f
>> 08: f87f f87f f87f f87f f87f  fe7f 0300
>> 10: 1027 2823      
>> 18:    f8f8   4954 2032
>> 20: 2771       f87f
>> 28: f87f f87f f87f f87f f87f  fe7f 0300
>> 30: 1027 2823      
>> 38:    f8f8   4954 2032
>> 40: 2771       f87f
>> 48: f87f f87f f87f f87f f87f  fe7f 0300
>> 50: 1027 2823      
>> 58:    f8f8   4954 2032
>> 60: 2771       f87f
>> 68: f87f f87f f87f f87f f87f  fe7f 0300
>> 70: 1027 2823      
>> 78:    f8f8   4954 2032
>> 80: 2771       f87f
>> 88: f87f f87f f87f f87f f87f  fe7f 0300
>> 90: 1027 2823      
>> 98:    f8f8   4954 2032
>> a0: 2771       f87f
>> a8: f87f f87f f87f f87f f87f  fe7f 0300
>> b0: 1027 2823      
>> b8:    f8f8   4954 2032
>> c0: 2771       f87f
>> c8: f87f f87f f87f f87f f87f  fe7f 0300
>> d0: 1027 2823      
>> d8:    f8f8   4954 2032
>> e0: 2771       f87f
>> e8: f87f f87f f87f f87f f87f  fe7f 0300
>> f0: 1027 2823      
>> f8:    f8f8   4954 2032
> 
> Thanks a lot!
> 

Feel free to completely ignore the first register dump I sent, I did it
for the wrong device anyway :).

I had just gotten done reading this:
https://lkml.org/lkml/2015/12/10/459
and accidentally got EVMs confused did the test for the TMP461, but it
does look like on startup register 0x16 can be used to differentiate the
parts, if the TMP461 hadn't gone into a different driver.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] capabilities: add capability cgroup controller

[Tejun Heo]

Hello, Serge.

On Fri, Jun 24, 2016 at 11:59:10AM -0500, Serge E. Hallyn wrote:
> > Just monitoring is less jarring than implementing security enforcement
> > via cgroup, but it is still jarring.  What's wrong with recursive
> > process hierarchy monitoring which is in line with the whole facility
> > is implemented anyway?
> 
> As I think Topi pointed out, one shortcoming is that if there is a short-lived
> child task, using its /proc/self/status is racy.  You might just miss that it
> ever even existed, let alone that the "application" needed it.

But the parent can collect whatever its children used.  We already do
that with other stats.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] leds: documentation: 'ide-disk' to 'disk-activity'

[Stephan Linz]

Hi Jacek,

thanks for your help. The new patch is on the way (v6).


br,
Stephan

Am 24.06.2016 um 08:50 schrieb Jacek Anaszewski:
> Hi Stephan,
> 
> On 06/23/2016 09:38 PM, Stephan Linz wrote:
>> Cc: Joseph Jezak 
>> Cc: Jörg Sommer 
>> Cc: Mark Rutland 
>> Signed-off-by: Stephan Linz 
>> Acked-by: Rob Herring 
>> Signed-off-by: Jacek Anaszewski 
>> ---
>> Changes in v5:
>>- Keep documentation for the old 'ide-disk' device tree
>>  binding, but mark as deprecated and refer to the new
>>  trigger 'disk-activity'.
>>
>> Changes in v4:
>>- Keep the 'ide-disk' trigger and add a second one
>>  for 'disk-activity'.
>>
>> Changes in v3:
>>- Port to kernel 4.x
>>- Split into platform independent and dependent parts.
>>
>> v2: https://patchwork.ozlabs.org/patch/117485/
>> v1: http://dev.gentoo.org/~josejx/ata.patch
>> ---
>>   Documentation/devicetree/bindings/leds/common.txt| 5 -
>>   Documentation/devicetree/bindings/leds/leds-gpio.txt | 4 ++--
>>   Documentation/laptops/asus-laptop.txt| 2 +-
>>   Documentation/leds/leds-class.txt| 2 +-
>>   4 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/common.txt
>> b/Documentation/devicetree/bindings/leds/common.txt
>> index af10678..1c32e31 100644
>> --- a/Documentation/devicetree/bindings/leds/common.txt
>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>> @@ -25,8 +25,11 @@ Optional properties for child nodes:
>>  system
>>"default-on" - LED will turn on (but for leds-gpio see
>> "default-state"
>>   property in Documentation/devicetree/bindings/gpio/led.txt)
>> + "disk-activity" - LED indicates disk activity, the old name
>> "ide-disk" is
>> +   still valid for backward compatibility
>>"heartbeat" - LED "double" flashes at a load average based rate
>> - "ide-disk" - LED indicates disk activity
>> + "ide-disk" - LED indicates IDE disk activity (deprecated), do
>> not use for
>> +  new implementation, use the new "disk-activity"
>> name instead
> 
> I'd like to reorganize this change.
> 
> I think that the two affected properties should be placed next to
> each other. I'd also remove the remark about ide-disk at disk-activity,
> since we're leaving ide-disk, with added reference to disk-activity.
> 
> How about following:
> 
> + "disk-activity" - LED indicates disk activity
> - "ide-disk" - LED indicates disk activity
> + "ide-disk" - LED indicates IDE disk activity (deprecated),
>in new implementations use "disk-activity"
> 
>>"timer" - LED flashes at a fixed, configurable rate
>>
>>   - led-max-microamp : Maximum LED supply current in microamperes.
>> This property
>> diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt
>> b/Documentation/devicetree/bindings/leds/leds-gpio.txt
>> index cbbeb18..5b1b43a 100644
>> --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
>> +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt
>> @@ -33,9 +33,9 @@ Examples:
>>   leds {
>>   compatible = "gpio-leds";
>>   hdd {
>> -label = "IDE Activity";
>> +label = "Disk Activity";
>>   gpios = <_pio 0 GPIO_ACTIVE_LOW>;
>> -linux,default-trigger = "ide-disk";
>> +linux,default-trigger = "disk-activity";
>>   };
>>
>>   fault {
>> diff --git a/Documentation/laptops/asus-laptop.txt
>> b/Documentation/laptops/asus-laptop.txt
>> index 79a1bc6..5f28587 100644
>> --- a/Documentation/laptops/asus-laptop.txt
>> +++ b/Documentation/laptops/asus-laptop.txt
>> @@ -72,7 +72,7 @@ LEDs
>>   echo 1 >  /sys/class/leds/asus::mail/brightness
>> will switch the mail LED on.
>> You can also know if they are on/off by reading their content and use
>> -  kernel triggers like ide-disk or heartbeat.
>> +  kernel triggers like disk-activity or heartbeat.
>>
>>   Backlight
>>   -
>> diff --git a/Documentation/leds/leds-class.txt
>> b/Documentation/leds/leds-class.txt
>> index 44f5e6b..f1f7ec9 100644
>> --- a/Documentation/leds/leds-class.txt
>> +++ b/Documentation/leds/leds-class.txt
>> @@ -11,7 +11,7 @@ brightness support so will just be turned on for
>> non-zero brightness settings.
>>   The class also introduces the optional concept of an LED trigger. A
>> trigger
>>   is a kernel based source of led events. Triggers can either be
>> simple or
>>   complex. A simple trigger isn't configurable and is designed to slot
>> into
>> -existing subsystems with minimal additional code. Examples are the
>> ide-disk,
>> +existing subsystems with minimal additional code. Examples are the
>> disk-activity,
>>   nand-disk and sharpsl-charge triggers. With led triggers disabled,
>> the code
>>   optimises away.
>>
>>
> 
> 



signature.asc

[PATCH v6] leds: documentation: 'ide-disk' to 'disk-activity'

[Stephan Linz]

Cc: Joseph Jezak 
Cc: Jörg Sommer 
Cc: Mark Rutland 
Signed-off-by: Stephan Linz 
Acked-by: Rob Herring 
Signed-off-by: Jacek Anaszewski 
---
Changes in v6:
  - Reorganize v5.

Changes in v5:
  - Keep documentation for the old 'ide-disk' device tree
binding, but mark as deprecated and refer to the new
trigger 'disk-activity'.

Changes in v4:
  - Keep the 'ide-disk' trigger and add a second one
for 'disk-activity'.

Changes in v3:
  - Port to kernel 4.x
  - Split into platform independent and dependent parts.

v2: https://patchwork.ozlabs.org/patch/117485/
v1: http://dev.gentoo.org/~josejx/ata.patch
---
 Documentation/devicetree/bindings/leds/common.txt| 4 +++-
 Documentation/devicetree/bindings/leds/leds-gpio.txt | 4 ++--
 Documentation/laptops/asus-laptop.txt| 2 +-
 Documentation/leds/leds-class.txt| 2 +-
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/common.txt 
b/Documentation/devicetree/bindings/leds/common.txt
index af10678..93ef6e6 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -26,7 +26,9 @@ Optional properties for child nodes:
  "default-on" - LED will turn on (but for leds-gpio see "default-state"
property in Documentation/devicetree/bindings/gpio/led.txt)
  "heartbeat" - LED "double" flashes at a load average based rate
- "ide-disk" - LED indicates disk activity
+ "disk-activity" - LED indicates disk activity
+ "ide-disk" - LED indicates IDE disk activity (deprecated),
+  in new implementations use "disk-activity"
  "timer" - LED flashes at a fixed, configurable rate
 
 - led-max-microamp : Maximum LED supply current in microamperes. This property
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt 
b/Documentation/devicetree/bindings/leds/leds-gpio.txt
index cbbeb18..5b1b43a 100644
--- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt
@@ -33,9 +33,9 @@ Examples:
 leds {
compatible = "gpio-leds";
hdd {
-   label = "IDE Activity";
+   label = "Disk Activity";
gpios = <_pio 0 GPIO_ACTIVE_LOW>;
-   linux,default-trigger = "ide-disk";
+   linux,default-trigger = "disk-activity";
};
 
fault {
diff --git a/Documentation/laptops/asus-laptop.txt 
b/Documentation/laptops/asus-laptop.txt
index 79a1bc6..5f28587 100644
--- a/Documentation/laptops/asus-laptop.txt
+++ b/Documentation/laptops/asus-laptop.txt
@@ -72,7 +72,7 @@ LEDs
 echo 1 >  /sys/class/leds/asus::mail/brightness
   will switch the mail LED on.
   You can also know if they are on/off by reading their content and use
-  kernel triggers like ide-disk or heartbeat.
+  kernel triggers like disk-activity or heartbeat.
 
 Backlight
 -
diff --git a/Documentation/leds/leds-class.txt 
b/Documentation/leds/leds-class.txt
index 44f5e6b..f1f7ec9 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -11,7 +11,7 @@ brightness support so will just be turned on for non-zero 
brightness settings.
 The class also introduces the optional concept of an LED trigger. A trigger
 is a kernel based source of led events. Triggers can either be simple or
 complex. A simple trigger isn't configurable and is designed to slot into
-existing subsystems with minimal additional code. Examples are the ide-disk,
+existing subsystems with minimal additional code. Examples are the 
disk-activity,
 nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
 optimises away.
 
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv5 5/8] Documentation: dt: socfpga: Add Arria10 Ethernet binding

[Rob Herring]

On Wed, Jun 22, 2016 at 08:58:56AM -0500, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> Add the device tree bindings needed to support the Altera Ethernet
> FIFO buffers on the Arria10 chip.
> 
> Signed-off-by: Thor Thayer 
> ---
> v2  No Change
> v3  Change to common compatible string based on maintainer comments
> Add local IRQ values.
> v4  Add compatible string for parent node.
> v5  Change parent phandle name to altr,ecc-parent
> ---
>  .../bindings/arm/altera/socfpga-eccmgr.txt |   24 
> 
>  1 file changed, 24 insertions(+)

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] capabilities: add capability cgroup controller

[Serge E. Hallyn]

Quoting Tejun Heo (t...@kernel.org):
> Hello,
> 
> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
> > Quoting Tejun Heo (t...@kernel.org):
> > > But isn't being recursive orthogonal to using cgroup?  Why not account
> > > usages recursively along the process hierarchy?  Capabilities don't
> > > have much to do with cgroup but everything with process hierarchy.
> > > That's how they're distributed and modified.  If monitoring their
> > > usages is necessary, it makes sense to do it in the same structure.
> > 
> > That was my argument against using cgroups to enforce a new bounding
> > set.  For tracking though, the cgroup process tracking seems as applicable
> > to this as it does to systemd tracking of services.  It tracks a task and
> > the children it forks.
> 
> Just monitoring is less jarring than implementing security enforcement
> via cgroup, but it is still jarring.  What's wrong with recursive
> process hierarchy monitoring which is in line with the whole facility
> is implemented anyway?

As I think Topi pointed out, one shortcoming is that if there is a short-lived
child task, using its /proc/self/status is racy.  You might just miss that it
ever even existed, let alone that the "application" needed it.

Another alternative we've both mentioned is to use systemtap.  That's not
as nice a solution as a cgroup, but then again this isn't really a common
case, so maybe it is precisely what a tracing infrastructure is meant for.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/1] hwmon: Add support for INA3221 Triple Current/Voltage Monitors

[Guenter Roeck]

On Fri, Jun 24, 2016 at 10:02:51AM -0500, Andrew F. Davis wrote:
> On 06/18/2016 10:16 AM, Guenter Roeck wrote:
> >
> > The chip registers are 16 bit. Can you repeat the command using the "w"
> > option ?
> > 
> 
> # i2cdump -y 2 0x40 w
>  0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
> 00: 2771       f87f
> 08: f87f f87f f87f f87f f87f  fe7f 0300
> 10: 1027 2823      
> 18:    f8f8   4954 2032
> 20: 2771       f87f
> 28: f87f f87f f87f f87f f87f  fe7f 0300
> 30: 1027 2823      
> 38:    f8f8   4954 2032
> 40: 2771       f87f
> 48: f87f f87f f87f f87f f87f  fe7f 0300
> 50: 1027 2823      
> 58:    f8f8   4954 2032
> 60: 2771       f87f
> 68: f87f f87f f87f f87f f87f  fe7f 0300
> 70: 1027 2823      
> 78:    f8f8   4954 2032
> 80: 2771       f87f
> 88: f87f f87f f87f f87f f87f  fe7f 0300
> 90: 1027 2823      
> 98:    f8f8   4954 2032
> a0: 2771       f87f
> a8: f87f f87f f87f f87f f87f  fe7f 0300
> b0: 1027 2823      
> b8:    f8f8   4954 2032
> c0: 2771       f87f
> c8: f87f f87f f87f f87f f87f  fe7f 0300
> d0: 1027 2823      
> d8:    f8f8   4954 2032
> e0: 2771       f87f
> e8: f87f f87f f87f f87f f87f  fe7f 0300
> f0: 1027 2823      
> f8:    f8f8   4954 2032

Thanks a lot!

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

devicetree random-seed properties, was: "Re: [PATCH v7 0/9] x86/mm: memory area address KASLR"

[Jason Cooper]

Thomas,

Sorry for wandering off the topic of your series.  The big take away for
me is that you and Kees are concerned about x86 systems pre-RDRAND.
Just as I'm concerned about deployed embedded systems without bootloader
support for hw-rngs and so forth.

Whatever final form the approach takes for ARM/dt, I'll make sure we can
extend it to legacy x86 systems.


Ard,

On Fri, Jun 24, 2016 at 12:54:01PM +0200, Ard Biesheuvel wrote:
> On 24 June 2016 at 03:11, Jason Cooper  wrote:
> > On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
...
> >> On arm64, only DT is used for KASLR (even when booting via ACPI). My
> >> first draft used register x1, but this turned out to be too much of a
> >> hassle, since parsing the DT is also necessary to discover whether
> >> there is a 'nokaslr' argument on the kernel command line. So the
> >> current implementation only supports a single method, which is the
> >> /chosen/kaslr-seed uint64 property.
> >
> > Ok, just to clarify (after a short offline chat), my goal is to set a
> > userspace,random-seed  property in the device tree once.
> > The bootloader scripts would also only need to be altered once.
> >
> > Then, at each boot, the bootloader reads the entirety of
> > /var/lib/misc/random-seed (512 bytes) into the configured address.
> > random-seed could be in /boot, or on a flash partition.
> >
> > The decompressor would consume a small portion of that seed for kaslr
> > and such.  After that, the rest would be consumed by random.c to
> > initialize the entropy pools.
> >
> 
> I see. This indeed has little to do with the arm64 KASLR case, other
> than that they both use a DT property.
> 
> In the arm64 KASLR case, I deliberately chose to leave it up to the
> bootloader/firmware to roll the dice, for the same reason you pointed
> out, i.e., that there is no architected way on ARM to obtain random
> bits. So in that sense, what you are doing is complimentary to my
> work, and a KASLR  aware arm64 bootloader would copy some of its
> random bits taken from /var/lib/misc/random-seed into the
> /chosen/kaslr-seed DT property.

Here I disagree.  We have two distinct entropy sources; the hw-rng
currently feeding kaslr via the /chosen/kaslr-seed property, and the
seasoned userspace seed I propose handed in via an extra property.

Having the bootloader conflate those two sources as if they are equal
seems to muddy the waters.  I prefer to have bootloaders tell me where
they got the data rather than to hope the bootloader sourced and mixed
it well.

> Note that, at the moment, this DT property is only an internal
> contract between the kernel's UEFI stub and the kernel proper, so we
> could still easily change that if necessary.

Ideally, I'd prefer to be deliberate with the DT properties, e.g.

random-seed,hwrng <--- bootloader reads from hw-rng
random-seed,userspace <--- bootloader reads file from us to addr

The kernel decompressor can init kaslr with only one of the two
properties populated.  If both properties are present, then the
decompressor can extract a u64 from userspace-seed and mix it with
hwrng-seed before use.

The small devicetree portion of my brain feels like 'kaslr-seed' is
telling the OS what to do with the value.  Whereas devicetree is
supposed to be describing the hardware.  Or, in this case, describing
the source of the data.

Given that more entropy from more sources is useful for random.c a bit
later in the boot process, it might be worth making hwrng-seed larger
than u64 as well.  This way we can potentially seed random.c from two
sources *before* init even starts.  Without having to depend on the
kernel's hw-rng driver being probed.  After all, it might not have been
built, or it could be a module that's loaded later.

I've attached a draft patch to chosen.txt.

thx,

Jason.


--->8-
diff --git a/Documentation/devicetree/bindings/chosen.txt 
b/Documentation/devicetree/bindings/chosen.txt
index 6ae9d82d4c37..61f15f04bc0a 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -45,6 +45,52 @@ on PowerPC "stdout" if "stdout-path" is not found.  However, 
the
 "linux,stdout-path" and "stdout" properties are deprecated. New platforms
 should only use the "stdout-path" property.
 
+random-seed properties
+--
+
+The goal of these properties are to provide an entropy seed early in the boot
+process.  Typically, this is needed by the kernel decompressor for
+initializing KASLR.  At that point, the kernel entropy pools haven't been
+initialized yet, and any hardware rng drivers haven't been loaded yet, if they
+exist.
+
+The bootloader can attain these seeds and pass them to the kernel via the
+respective properties.  The bootloader is not expected to mix or condition
+this data in any way, simply read and pass.  Either one or both properties can
+be set if the data is available.
+

Re: [PATCH 1/2] cgroup: pids: show number of failed forks since limit reset

[Tejun Heo]

Hello,

On Fri, Jun 24, 2016 at 01:00:48PM +1000, Aleksa Sarai wrote:
> This allows users to dynamically adjust their limits based on how many
> failed forks happened since they last reset their limits, otherwise they
> would have to track (in a racy way) how many limit failures there were
> since the last limit change manually. In addition, we log the first
> failure since the limit was reset (which was the original semantics of
> the patchset).

Isn't that trivially achievable by reading the counter and then
calculating the diff?  I don't think it matters all that much whether
the log message is printed once per cgroup or per config-change.  It's
just a hint for the admin to avoid setting her off on a wild goose
chase.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Ard Biesheuvel]

On 24 June 2016 at 03:11, Jason Cooper  wrote:
> Hi Ard,
>
> On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
>> On 23 June 2016 at 21:58, Kees Cook  wrote:
>> > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  
>> > wrote:
>> >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>> >>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  
>> >>> wrote:
>> >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  
>> >>> > wrote:
>> >>> >> Hey Kees,
>> >>> >>
>> >>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>> >>> >>> Notable problems that needed solving:
>> >>> >> ...
>> >>> >>>  - Reasonable entropy is needed early at boot before 
>> >>> >>> get_random_bytes()
>> >>> >>>is available.
>> >>> >>
>> >>> >> This series is targetting x86, which typically has RDRAND/RDSEED
>> >>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
>> >>> >> isn't this the same requirement for base address KASLR?
>> >>> >>
>> >>> >> Don't get me wrong, I want more diverse entropy sources available
>> >>> >> earlier in the boot process as well. :-)  I'm just wondering what's
>> >>> >> different about this series vs base address KASLR wrt early entropy
>> >>> >> sources.
>> >>> >>
>> >>> >
>> >>> > I think Kees was referring to the refactor I did to get the similar
>> >>> > entropy generation than KASLR module randomization. Our approach was
>> >>> > to provide best entropy possible even if you have an older processor
>> >>> > or under virtualization without support for these instructions.
>> >>> > Unfortunately common on companies with a large number of older
>> >>> > machines.
>> >>>
>> >>> Right, the memory offset KASLR uses the same routines as the kernel
>> >>> base KASLR. The issue is with older x86 systems, which continue to be
>> >>> very common.
>> >>
>> >> We have the same issue in embedded. :-(  Compounded by the fact that
>> >> there is no rand instruction (at least not on ARM).  So, even if there's
>> >> a HW-RNG, you can't access it until the driver is loaded.
>> >>
>> >> This is compounded by the fact that most systems deployed today have
>> >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
>> >> without dtb support at all.
>> >>
>> >> My current thinking is to add a devicetree property
>> >> "userspace,random-seed" .  This way, existing, deployed
>> >> boards can append a dtb to a modern kernel with the property set.
>> >> The factory bootloader then only needs to amend its boot scripts to read
>> >> random-seed from the fs to the given address.
>> >
>> > The arm64 KASLR implementation has defined a way for boot loaders to
>> > pass in an seed similar to this. It might be nice to have a fall-back
>> > to a DT entry, though, then the bootloaders don't need to changed.
>> >
>> > Ard might have some thoughts on why DT wasn't used for KASLR (I assume
>> > the early parsing overhead, but I don't remember the discussion any
>> > more).
>> >
>>
>> On arm64, only DT is used for KASLR (even when booting via ACPI). My
>> first draft used register x1, but this turned out to be too much of a
>> hassle, since parsing the DT is also necessary to discover whether
>> there is a 'nokaslr' argument on the kernel command line. So the
>> current implementation only supports a single method, which is the
>> /chosen/kaslr-seed uint64 property.
>
> Ok, just to clarify (after a short offline chat), my goal is to set a
> userspace,random-seed  property in the device tree once.
> The bootloader scripts would also only need to be altered once.
>
> Then, at each boot, the bootloader reads the entirety of
> /var/lib/misc/random-seed (512 bytes) into the configured address.
> random-seed could be in /boot, or on a flash partition.
>
> The decompressor would consume a small portion of that seed for kaslr
> and such.  After that, the rest would be consumed by random.c to
> initialize the entropy pools.
>

I see. This indeed has little to do with the arm64 KASLR case, other
than that they both use a DT property.

In the arm64 KASLR case, I deliberately chose to leave it up to the
bootloader/firmware to roll the dice, for the same reason you pointed
out, i.e., that there is no architected way on ARM to obtain random
bits. So in that sense, what you are doing is complimentary to my
work, and a KASLR  aware arm64 bootloader would copy some of its
random bits taken from /var/lib/misc/random-seed into the
/chosen/kaslr-seed DT property. Note that, at the moment, this DT
property is only an internal contract between the kernel's UEFI stub
and the kernel proper, so we could still easily change that if
necessary.

Alternatively, if we go with your solution, the KASLR code should read
from the address in userspace,random-seed rather than the
/chosen/kaslr-seed property itself. (or use the former as a fallback
if the latter was not found)

-- 

Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line

[Robin Murphy]

Hi Konrad,

On 24/06/16 11:46, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 24, 2016 at 10:57:29AM +0800, Jisheng Zhang wrote:
>> Dear Konrad,
>>
>> On Thu, 23 Jun 2016 12:06:10 -0400 Konrad Rzeszutek Wilk wrote:
>>
>>> On June 23, 2016 10:30:34 AM EDT, Catalin Marinas  
>>> wrote:
 On Thu, Jun 23, 2016 at 05:43:40PM +0530, Manjeet Pawar wrote:  
> From: Rohit Thapliyal 
>
> swiotlb default size of 64M is too big as
> default value therefore it is made configurable
> through command line through swiotlb_size parameter.
> swiotlb allocation shall be done only when the
> swiotlb size is given through command line.
> Otherwise no swiotlb is allocated.  

 I already queued this patch:

 http://lkml.kernel.org/g/1465372426-4077-1-git-send-email-jszh...@marvell.com

 If you have any objections to it, please reply there.  
>>>
>>>
>>> I do (sorry about duplicate email, the other got rejected by mailing lists).
>>>
>>> Why not expand the swiotlb= parameter instead of introducing a new one?
>>
>> Do you mean pass "swiotlb=" for those platforms(most probably, arm64 with 
>> less
>> than 4GB DDR) which don't need swiotlb? I'm afraid this is not convenient, 
>> and
> 
> Why not just have a function that checks the amount of memory? x86 has
> that - if it finds that the machine has less than 4GB it will not setup
> SWIOTLB?
> 
>> users even don't notice swiotlb parameter. From another side, pass 
>> "swiotlb=0"
>> will make the swiotlb reserve 64MB instead, so how can we achieve zero 
>> reserved
>> memory for swiotlb through "swiotlb=" parameter?
> 
> Obviously make the function understand that 0 is to turn it off.
>>
>> PS: my patch didn't introduce new boot parameter.
> 
> swiotlb_sz ?

Note that Jisheng's patch is the one Catalin linked to, *not* this one,
and more or less does exactly what you describe.

Robin.

>>
>> I'm not sure I got your meaning, so could you please comment my patch
>> directly?
>>
>> Thanks,
>> Jisheng
>>
>>>
>>> Also, why not use the swiotlb by itself? That does the job as well?
>>>
>>>
>>> ___
>>> linux-arm-kernel mailing list
>>> linux-arm-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line

[Konrad Rzeszutek Wilk]

On Fri, Jun 24, 2016 at 10:57:29AM +0800, Jisheng Zhang wrote:
> Dear Konrad,
> 
> On Thu, 23 Jun 2016 12:06:10 -0400 Konrad Rzeszutek Wilk wrote:
> 
> > On June 23, 2016 10:30:34 AM EDT, Catalin Marinas  
> > wrote:
> > >On Thu, Jun 23, 2016 at 05:43:40PM +0530, Manjeet Pawar wrote:  
> > >> From: Rohit Thapliyal 
> > >> 
> > >> swiotlb default size of 64M is too big as
> > >> default value therefore it is made configurable
> > >> through command line through swiotlb_size parameter.
> > >> swiotlb allocation shall be done only when the
> > >> swiotlb size is given through command line.
> > >> Otherwise no swiotlb is allocated.  
> > >
> > >I already queued this patch:
> > >
> > >http://lkml.kernel.org/g/1465372426-4077-1-git-send-email-jszh...@marvell.com
> > >
> > >If you have any objections to it, please reply there.  
> > 
> > 
> > I do (sorry about duplicate email, the other got rejected by mailing lists).
> > 
> > Why not expand the swiotlb= parameter instead of introducing a new one?
> 
> Do you mean pass "swiotlb=" for those platforms(most probably, arm64 with less
> than 4GB DDR) which don't need swiotlb? I'm afraid this is not convenient, and

Why not just have a function that checks the amount of memory? x86 has
that - if it finds that the machine has less than 4GB it will not setup
SWIOTLB?

> users even don't notice swiotlb parameter. From another side, pass "swiotlb=0"
> will make the swiotlb reserve 64MB instead, so how can we achieve zero 
> reserved
> memory for swiotlb through "swiotlb=" parameter?

Obviously make the function understand that 0 is to turn it off.
> 
> PS: my patch didn't introduce new boot parameter.

swiotlb_sz ?

> 
> I'm not sure I got your meaning, so could you please comment my patch
> directly?
> 
> Thanks,
> Jisheng
> 
> > 
> > Also, why not use the swiotlb by itself? That does the job as well?
> > 
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] Documentation/Sphinx

[Mauro Carvalho Chehab]

Em Tue, 31 May 2016 12:16:25 +0200
Markus Heiser  escreveu:

> Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab 
> :
> 
> > Em Mon, 30 May 2016 23:05:34 +0300
> > Jani Nikula  escreveu:
> >   
> >>> I worry a little bit in that reST will be only one more toolchain 
> >>> beside DocBook .. in the long term, kernel's documentation 
> >>> should get rid of all the DocBook artifacts and for this a more
> >>> comprehensive solution is needed.
> >> 
> >> We agree on the end goal, eradicate DocBook. I must say that in my
> >> experiments, apart from the media docs, almost everything converts
> >> surprisingly nicely or IMO "good enough" with just the tmplcvt script in
> >> this series.  
> > 
> > With regards to media, my plan is to merge create a topic branch based
> > on Kernel 4.7-rc1 at:
> > https://git.linuxtv.org/media_tree.git/
> > 
> > As none of the Jani's patches seem to affect the media API docs, it
> > seems I don't need to merge back from Jon's -next branch.
> > 
> > There, I intend to add Markus patches with the conversion from the
> > DocBook to rst, plus the flat-table extension logic.
> > 
> > Then, I'll work to manually fix what's needed and I'll add the 
> > automation scripting logic that we have at the DocBook Makefile
> > to work with the new media rst files.
> > 
> > Lastly, once the job's done, I'll drop Documentation/DocBook/media.
> > 
> > Markus,
> > 
> > With that regards, could you please send the patches to me?  
> 
> Yes. What is your timeline ... is it OK if I send you a patch in the 
> next two weeks? ... first I wan't to finish my other work / I'am just
> back from holiday .. a lot of work to do :-o

Hi Markus,

I'm wanting to start working on it next week, if possible.

I created an experimental branch on my tree for such work, where
I'm merging from both Jon's doc-next tree and from media tree at:
https://git.linuxtv.org//mchehab/experimental.git/log/?h=docs-next

Could you please rebase your work with the media DocBook and with
the flat-table support to be on the top of it?

Thanks!
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

[Benjamin Tissoires]

On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> Hi Benjamin,
> 
> On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > +
> > +struct mapping_table_entry {
> > +   u16 rmiaddr;
> 
> Should be __le16 rmiaddr, otherwise:
> 
>   CHECK   drivers/input/rmi4/rmi_smbus.c
> drivers/input/rmi4/rmi_smbus.c:116:33: warning: incorrect type in assignment 
> (different base types)
> drivers/input/rmi4/rmi_smbus.c:116:33:expected unsigned short [unsigned] 
> [usertype] rmiaddr
> drivers/input/rmi4/rmi_smbus.c:116:33:got restricted __le16 [usertype] 
> 
> 
> > +
> > +static struct i2c_driver rmi_smb_driver;
> > +
> 
> I do not think this forward declaration is needed.
> 
> > +
> > +#ifdef CONFIG_PM_SLEEP
> > +static int rmi_smb_suspend(struct device *dev)
> 
> __maybe_unused instead of #ifdef.
> 
> > +{
> > +   struct i2c_client *client = to_i2c_client(dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   int ret;
> > +
> > +   ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to suspend device: %d\n", ret);
> > +
> > +   return ret;
> > +}
> > +#endif
> > +
> > +#ifdef CONFIG_PM
> > +static int rmi_smb_runtime_suspend(struct device *dev)
> 
> Same here?
> 
> > +{
> > +   struct i2c_client *client = to_i2c_client(dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   int ret;
> > +
> > +   ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to suspend device: %d\n", ret);
> > +
> > +   return 0;
> > +}
> > +
> > +static int rmi_smb_runtime_resume(struct device *dev)
> > +{
> > +   struct i2c_client *client = to_i2c_client(dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   int ret;
> > +
> > +   ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to resume device: %d\n", ret);
> > +
> > +   return 0;
> > +}
> > +#endif
> > +
> > +static const struct dev_pm_ops rmi_smb_pm = {
> > +   SET_SYSTEM_SLEEP_PM_OPS(rmi_smb_suspend, NULL)
> > +   SET_RUNTIME_PM_OPS(rmi_smb_runtime_suspend, rmi_smb_runtime_resume,
> > +  NULL)
> > +};
> > +
> > +static int rmi_smb_resume(struct device *dev)
> > +{
> > +   struct i2c_client *client = container_of(dev, struct i2c_client, dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   struct rmi_device *rmi_dev = rmi_smb->xport.rmi_dev;
> > +   int ret;
> > +
> > +   rmi_smb_reset(_smb->xport, 0);
> > +
> > +   rmi_reset(rmi_dev);
> > +
> > +   ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to resume device: %d\n", ret);
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct i2c_device_id rmi_id[] = {
> > +   { "rmi4_smbus", 0 },
> > +   { }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, rmi_id);
> > +
> > +static struct i2c_driver rmi_smb_driver = {
> > +   .driver = {
> > +   .owner  = THIS_MODULE,
> > +   .name   = "rmi4_smbus",
> > +   .pm = _smb_pm,
> > +   .resume = rmi_smb_resume,
> 
> Why rmi_smb_resume is not part of rmi_smb_pm?
> 

This is because rmi_smbus device both have a PS/2 interface and a SMBus
one. I'll have to check again now that I have a slightly different way
of binding smbus devices in my tree, but the issue was:
- having resume part of pm means it will get caught by PM directly
- the PS/2 node gets also resumed by PM
- calling PS/2 commands during resume switches the devices back into
  PS/2 and stops the SMBus communication.

So it's easier to wait only for the PS/2 PM resume call which will call
the SMBus resume function when the device is in a proper state.

I'll send out the updated patch with your comments next week hopefully.

Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] leds: documentation: 'ide-disk' to 'disk-activity'

[Jacek Anaszewski]

Hi Stephan,

On 06/23/2016 09:38 PM, Stephan Linz wrote:

Cc: Joseph Jezak 
Cc: Jörg Sommer 
Cc: Mark Rutland 
Signed-off-by: Stephan Linz 
Acked-by: Rob Herring 
Signed-off-by: Jacek Anaszewski 
---
Changes in v5:
   - Keep documentation for the old 'ide-disk' device tree
 binding, but mark as deprecated and refer to the new
 trigger 'disk-activity'.

Changes in v4:
   - Keep the 'ide-disk' trigger and add a second one
 for 'disk-activity'.

Changes in v3:
   - Port to kernel 4.x
   - Split into platform independent and dependent parts.

v2: https://patchwork.ozlabs.org/patch/117485/
v1: http://dev.gentoo.org/~josejx/ata.patch
---
  Documentation/devicetree/bindings/leds/common.txt| 5 -
  Documentation/devicetree/bindings/leds/leds-gpio.txt | 4 ++--
  Documentation/laptops/asus-laptop.txt| 2 +-
  Documentation/leds/leds-class.txt| 2 +-
  4 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/common.txt 
b/Documentation/devicetree/bindings/leds/common.txt
index af10678..1c32e31 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -25,8 +25,11 @@ Optional properties for child nodes:
   system
   "default-on" - LED will turn on (but for leds-gpio see "default-state"
property in Documentation/devicetree/bindings/gpio/led.txt)
+ "disk-activity" - LED indicates disk activity, the old name "ide-disk" is
+   still valid for backward compatibility
   "heartbeat" - LED "double" flashes at a load average based rate
- "ide-disk" - LED indicates disk activity
+ "ide-disk" - LED indicates IDE disk activity (deprecated), do not use for
+  new implementation, use the new "disk-activity" name instead


I'd like to reorganize this change.

I think that the two affected properties should be placed next to
each other. I'd also remove the remark about ide-disk at disk-activity,
since we're leaving ide-disk, with added reference to disk-activity.

How about following:

+ "disk-activity" - LED indicates disk activity
- "ide-disk" - LED indicates disk activity
+ "ide-disk" - LED indicates IDE disk activity (deprecated),
   in new implementations use "disk-activity"


   "timer" - LED flashes at a fixed, configurable rate

  - led-max-microamp : Maximum LED supply current in microamperes. This property
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt 
b/Documentation/devicetree/bindings/leds/leds-gpio.txt
index cbbeb18..5b1b43a 100644
--- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt
@@ -33,9 +33,9 @@ Examples:
  leds {
compatible = "gpio-leds";
hdd {
-   label = "IDE Activity";
+   label = "Disk Activity";
gpios = <_pio 0 GPIO_ACTIVE_LOW>;
-   linux,default-trigger = "ide-disk";
+   linux,default-trigger = "disk-activity";
};

fault {
diff --git a/Documentation/laptops/asus-laptop.txt 
b/Documentation/laptops/asus-laptop.txt
index 79a1bc6..5f28587 100644
--- a/Documentation/laptops/asus-laptop.txt
+++ b/Documentation/laptops/asus-laptop.txt
@@ -72,7 +72,7 @@ LEDs
  echo 1 >  /sys/class/leds/asus::mail/brightness
will switch the mail LED on.
You can also know if they are on/off by reading their content and use
-  kernel triggers like ide-disk or heartbeat.
+  kernel triggers like disk-activity or heartbeat.

  Backlight
  -
diff --git a/Documentation/leds/leds-class.txt 
b/Documentation/leds/leds-class.txt
index 44f5e6b..f1f7ec9 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -11,7 +11,7 @@ brightness support so will just be turned on for non-zero 
brightness settings.
  The class also introduces the optional concept of an LED trigger. A trigger
  is a kernel based source of led events. Triggers can either be simple or
  complex. A simple trigger isn't configurable and is designed to slot into
-existing subsystems with minimal additional code. Examples are the ide-disk,
+existing subsystems with minimal additional code. Examples are the 
disk-activity,
  nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
  optimises away.





--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html