Re: [PATCH] leds: Add mutex protection in brightness_show()

[Pavel Machek]

Hi!

> Initially the claim about no need for lock in brightness_show()
> was valid as the function was just returning unchanged
> LED brightness. After the addition of led_update_brightness() this

The claim was probably wrong from the day one, unless brightness is of
type "atomic_t".

 /* Ensures consistent access to the LED Flash Class device */
struct mutexled_access;
};

This should really list fields that are protected by led_access.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] leds: Add mutex protection in brightness_show()

[Pavel Machek]

Hi!

> Initially the claim about no need for lock in brightness_show()
> was valid as the function was just returning unchanged
> LED brightness. After the addition of led_update_brightness() this

The claim was probably wrong from the day one, unless brightness is of
type "atomic_t".

 /* Ensures consistent access to the LED Flash Class device */
struct mutexled_access;
};

This should really list fields that are protected by led_access.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] leds: Add mutex protection in brightness_show()

[Pavel Machek]

Hi!

> On 04-11-16 08:52, Jacek Anaszewski wrote:
> >Initially the claim about no need for lock in brightness_show()
> >was valid as the function was just returning unchanged
> >LED brightness. After the addition of led_update_brightness() this
> >is no longer true, as the function can change the brightness if
> >a LED class driver implements brightness_get op. It can lead to
> >races between led_update_brightness() and led_set_brightness(),
> >resulting in overwriting new brightness with the old one before
> >the former is written to the device.
> >
> >Signed-off-by: Jacek Anaszewski 
> >Cc: Hans de Goede 
> >Cc: Sakari Ailus 
> >Cc: Pavel Machek 
> >Cc: Andrew Lunn 
> >---
> > drivers/leds/led-class.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> >index 731e4eb..0c2307b 100644
> >--- a/drivers/leds/led-class.c
> >+++ b/drivers/leds/led-class.c
> >@@ -30,8 +30,9 @@ static ssize_t brightness_show(struct device *dev,
> > {
> > struct led_classdev *led_cdev = dev_get_drvdata(dev);
> >
> >-/* no lock needed for this */
> >+mutex_lock(_cdev->led_access);
> > led_update_brightness(led_cdev);
> >+mutex_unlock(_cdev->led_access);
> >
> > return sprintf(buf, "%u\n", led_cdev->brightness);
> > }
> >
> 
> I'm afraid that this fix is not enough, the led_access lock is only
> held when the brightness is being updated through sysfs, not for
> trigger / sw-blinking updates (which cannot take a mutex as they
> may be called from non blocking contexts).
> 
> We may need to consider to add a spinlock to the led_classdev and
> always lock that when calling into the driver, except for when
> the driver has a brightness_set_blocking callback. Which will need
> special handling.
> >>>
> >>>led_update_brightness() currently has two users besides LED subsystem
> >>>(at least grep reports those places):
> >>>
> >>>1. v4l2-flash-led-class wrapper, for which led_access mutex was
> >>>   introduced. Its purpose was to disable LED sysfs interface while
> >>>   v4l2-flash wrapper takes over control of LED class device
> >>>   (not saying that the mutex wasn't missing even without this
> >>>use case). Now I've realized that the call to
> >>>led_sysfs_is_disabled() is missing in this patch.
> >>>2. /drivers/platform/x86/thinkpad_acpi.c - it calls
> >>>   led_update_brightness() on suspend
> >>>
> >>>I think that the best we can now do is to add
> >>>lockdep_assert_held(_cdev->led_access) in led_update_brightness()
> >>>and a description saying that the caller has to acquire led_access
> >>>lock before calling it. Similarly as in case of
> >>>led_sysfs_disable()/led_sysfs_disable().
> >>
> >>The problem is not only callers of led_update_brightness() not holding
> >>led_cdev->led_access, the problem is also callers of led_set_brightness
> >>not holding led_cdev->led_access and they cannot take this lock because
> >>they may be called from a non-blocking context.
> >
> >Thinking more about this, using a spinlock is also not going to work
> >because led_cdev->brightness_set_blocking and led_cdev->brightness_get
> >can both block and thus cannot be called with a spinlock held.
> >
> >I think that we need to just make this a problem of the led drivers
> >and in include/linux/leds.h document that the led-core does not do
> >locking and that the drivers themselves need to protect against
> >their brightness_set / brightness_get callbacks when necessary.
> 
> Thanks for the analysis. Either way, this patch, with the modification
> I mentioned in my previous message is required to assure proper
> LED sysfs locking.
> 
> Regarding the races between user and atomic context, I think that
> it should be system root's responsibility to define LED access
> policy. If a LED is registered for any trigger events then setting
> brightness from user space should be made impossible. Such a hint
> could be even added to the Documentation/leds/leds-class.txt.

No, kernel locking may not depend on "root did not do anything
stupid". Sorry.

Is there problem with led_access becoming a spinlock, and
brightness_set_blocking taking it internally while it reads the
brightness (but not while sleeping)? 

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] leds: Add mutex protection in brightness_show()

[Pavel Machek]

Hi!

> On 04-11-16 08:52, Jacek Anaszewski wrote:
> >Initially the claim about no need for lock in brightness_show()
> >was valid as the function was just returning unchanged
> >LED brightness. After the addition of led_update_brightness() this
> >is no longer true, as the function can change the brightness if
> >a LED class driver implements brightness_get op. It can lead to
> >races between led_update_brightness() and led_set_brightness(),
> >resulting in overwriting new brightness with the old one before
> >the former is written to the device.
> >
> >Signed-off-by: Jacek Anaszewski 
> >Cc: Hans de Goede 
> >Cc: Sakari Ailus 
> >Cc: Pavel Machek 
> >Cc: Andrew Lunn 
> >---
> > drivers/leds/led-class.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> >index 731e4eb..0c2307b 100644
> >--- a/drivers/leds/led-class.c
> >+++ b/drivers/leds/led-class.c
> >@@ -30,8 +30,9 @@ static ssize_t brightness_show(struct device *dev,
> > {
> > struct led_classdev *led_cdev = dev_get_drvdata(dev);
> >
> >-/* no lock needed for this */
> >+mutex_lock(_cdev->led_access);
> > led_update_brightness(led_cdev);
> >+mutex_unlock(_cdev->led_access);
> >
> > return sprintf(buf, "%u\n", led_cdev->brightness);
> > }
> >
> 
> I'm afraid that this fix is not enough, the led_access lock is only
> held when the brightness is being updated through sysfs, not for
> trigger / sw-blinking updates (which cannot take a mutex as they
> may be called from non blocking contexts).
> 
> We may need to consider to add a spinlock to the led_classdev and
> always lock that when calling into the driver, except for when
> the driver has a brightness_set_blocking callback. Which will need
> special handling.
> >>>
> >>>led_update_brightness() currently has two users besides LED subsystem
> >>>(at least grep reports those places):
> >>>
> >>>1. v4l2-flash-led-class wrapper, for which led_access mutex was
> >>>   introduced. Its purpose was to disable LED sysfs interface while
> >>>   v4l2-flash wrapper takes over control of LED class device
> >>>   (not saying that the mutex wasn't missing even without this
> >>>use case). Now I've realized that the call to
> >>>led_sysfs_is_disabled() is missing in this patch.
> >>>2. /drivers/platform/x86/thinkpad_acpi.c - it calls
> >>>   led_update_brightness() on suspend
> >>>
> >>>I think that the best we can now do is to add
> >>>lockdep_assert_held(_cdev->led_access) in led_update_brightness()
> >>>and a description saying that the caller has to acquire led_access
> >>>lock before calling it. Similarly as in case of
> >>>led_sysfs_disable()/led_sysfs_disable().
> >>
> >>The problem is not only callers of led_update_brightness() not holding
> >>led_cdev->led_access, the problem is also callers of led_set_brightness
> >>not holding led_cdev->led_access and they cannot take this lock because
> >>they may be called from a non-blocking context.
> >
> >Thinking more about this, using a spinlock is also not going to work
> >because led_cdev->brightness_set_blocking and led_cdev->brightness_get
> >can both block and thus cannot be called with a spinlock held.
> >
> >I think that we need to just make this a problem of the led drivers
> >and in include/linux/leds.h document that the led-core does not do
> >locking and that the drivers themselves need to protect against
> >their brightness_set / brightness_get callbacks when necessary.
> 
> Thanks for the analysis. Either way, this patch, with the modification
> I mentioned in my previous message is required to assure proper
> LED sysfs locking.
> 
> Regarding the races between user and atomic context, I think that
> it should be system root's responsibility to define LED access
> policy. If a LED is registered for any trigger events then setting
> brightness from user space should be made impossible. Such a hint
> could be even added to the Documentation/leds/leds-class.txt.

No, kernel locking may not depend on "root did not do anything
stupid". Sorry.

Is there problem with led_access becoming a spinlock, and
brightness_set_blocking taking it internally while it reads the
brightness (but not while sleeping)? 

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

[Bjørn Mork]

Oliver Neukum  writes:

> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>
>> These problems could very well be caused by running at SuperSpeed
>> (USB-3) instead of high speed (USB-2).
>> 
>> Is there any way to test what happens when the device is attached to 
>> the computer by a USB-2 cable?  That would prevent it from operating at 
>> SuperSpeed.
>> 
>> The main point, however, is that the proposed patch doesn't seem to
>> address the true problem, which is that the device gets suspended
>> between probes.  The patch only tries to prevent it from being
>> suspended during a probe -- which is already prevented by the USB core.
>
> But why doesn't it fail during normal operation?
>
> I suspect that its firmware requires the altsetting
>
> /* should we change control altsetting on a NCM/MBIM function? */
> if (cdc_ncm_select_altsetting(intf) == CDC_NCM_COMM_ALTSETTING_MBIM) {
> data_altsetting = CDC_NCM_DATA_ALTSETTING_MBIM;
> ret = cdc_mbim_set_ctrlalt(dev, intf, 
> CDC_NCM_COMM_ALTSETTING_MBIM);
>
> to be set before it accepts a suspension.

Could be, but I don't think so.  The above code is effectively a noop
unless the function is a combined NCM/MBIM function.  Something I've
never seen on a Sierra Wireless device (ignoring the infamous EM7345,
which really is an Intel device).

This is a typical example of a Sierra Wireless modem configured for
MBIM:

P:  Vendor=1199 ProdID=9079 Rev= 0.06
S:  Manufacturer=Sierra Wireless, Incorporated
S:  Product=Sierra Wireless EM7455 Qualcomm Snapdragon X7 LTE-A
S:  SerialNumber=LF615126xxx
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
A:  FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=(none)
E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
I:* If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
I:  If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms


The control interface of plain MBIM functions will always have a single
altsetting, like the example above. So cdc_ncm_select_altsetting(intf)
returns "0", while CDC_NCM_COMM_ALTSETTING_MBIM is "1".


Just for reference, using the Intel^H^H^H^H^HEM7345 as example, this is
what a combined NCM/MBIM function looks like:


P:  Vendor=1199 ProdID=a001 Rev=17.29
S:  Manufacturer=Sierra Wireless Inc.
S:  Product=Sierra Wireless EM7345 4G LTE
S:  SerialNumber=013937000xx
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00
A:  FirstIf#= 2 IfCount= 2 Cls=02(comm.) Sub=02 Prot=01
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_mbim
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 2 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms


And this is what the code you quote is trying to deal with.  Note the
different subclass of altsetting 0 and 1 This is incredibly ugly.

FWIW, the modem in question cannot be an EM7345. That modem does not
have the static interface numbering oddity.  Another sign that it isn't
a true Sierra device.




Bjørn

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

[Bjørn Mork]

Oliver Neukum  writes:

> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>
>> These problems could very well be caused by running at SuperSpeed
>> (USB-3) instead of high speed (USB-2).
>> 
>> Is there any way to test what happens when the device is attached to 
>> the computer by a USB-2 cable?  That would prevent it from operating at 
>> SuperSpeed.
>> 
>> The main point, however, is that the proposed patch doesn't seem to
>> address the true problem, which is that the device gets suspended
>> between probes.  The patch only tries to prevent it from being
>> suspended during a probe -- which is already prevented by the USB core.
>
> But why doesn't it fail during normal operation?
>
> I suspect that its firmware requires the altsetting
>
> /* should we change control altsetting on a NCM/MBIM function? */
> if (cdc_ncm_select_altsetting(intf) == CDC_NCM_COMM_ALTSETTING_MBIM) {
> data_altsetting = CDC_NCM_DATA_ALTSETTING_MBIM;
> ret = cdc_mbim_set_ctrlalt(dev, intf, 
> CDC_NCM_COMM_ALTSETTING_MBIM);
>
> to be set before it accepts a suspension.

Could be, but I don't think so.  The above code is effectively a noop
unless the function is a combined NCM/MBIM function.  Something I've
never seen on a Sierra Wireless device (ignoring the infamous EM7345,
which really is an Intel device).

This is a typical example of a Sierra Wireless modem configured for
MBIM:

P:  Vendor=1199 ProdID=9079 Rev= 0.06
S:  Manufacturer=Sierra Wireless, Incorporated
S:  Product=Sierra Wireless EM7455 Qualcomm Snapdragon X7 LTE-A
S:  SerialNumber=LF615126xxx
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
A:  FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=(none)
E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
I:* If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
I:  If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms


The control interface of plain MBIM functions will always have a single
altsetting, like the example above. So cdc_ncm_select_altsetting(intf)
returns "0", while CDC_NCM_COMM_ALTSETTING_MBIM is "1".


Just for reference, using the Intel^H^H^H^H^HEM7345 as example, this is
what a combined NCM/MBIM function looks like:


P:  Vendor=1199 ProdID=a001 Rev=17.29
S:  Manufacturer=Sierra Wireless Inc.
S:  Product=Sierra Wireless EM7345 4G LTE
S:  SerialNumber=013937000xx
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00
A:  FirstIf#= 2 IfCount= 2 Cls=02(comm.) Sub=02 Prot=01
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_mbim
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 2 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms


And this is what the code you quote is trying to deal with.  Note the
different subclass of altsetting 0 and 1 This is incredibly ugly.

FWIW, the modem in question cannot be an EM7345. That modem does not
have the static interface numbering oddity.  Another sign that it isn't
a true Sierra device.




Bjørn

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

[John Garry]

On 03/11/2016 14:58, John Garry wrote:

The following patch introduces an annoying WARN
when a device is removed from the SAS topology:
[SCSI] libsas: prevent domain rediscovery competing with ata error handling



Are there any views on this patch? I would have thought that the parties 
who use the drivers based on libsas would be interested in fixing this bug.


BTW, We are internally testing, hence the RFC.

Thanks in advance,
John


A sample WARN is as follows:
[  236.842227] WARNING: CPU: 7 PID: 1520 at fs/sysfs/group.c:237 
sysfs_remove_group+0x90/0x98
[  236.850465] Modules linked in:
[  236.853544]
[  236.855045] CPU: 7 PID: 1520 Comm: kworker/u64:4 Tainted: GW   
4.9.0-rc1-15310-g3fbc29e-dirty #676
[  236.865010] Hardware name: Huawei Taishan 2180 /D03, BIOS Estuary v2.3 D03 
UEFI 08/17/2016
[  236.873249] Workqueue: scsi_wq_0 sas_destruct_devices
[  236.878317] task: 8027ba31b200 task.stack: 8027b9d44000
[  236.884225] PC is at sysfs_remove_group+0x90/0x98
[  236.888920] LR is at sysfs_remove_group+0x90/0x98
[  236.893616] pc : [] lr : [] pstate: 
6145
[  236.900989] sp : 8027b9d47bf0

< snip >

[  237.116463] [] sysfs_remove_group+0x90/0x98
[  237.122197] [] dpm_sysfs_remove+0x58/0x68
[  237.127758] [] device_del+0x40/0x218
[  237.132886] [] device_unregister+0x14/0x2c
[  237.138536] [] bsg_unregister_queue+0x5c/0xa0
[  237.12] [] sas_rphy_remove+0x44/0x80
[  237.149915] [] sas_rphy_delete+0x14/0x28
[  237.155388] [] sas_destruct_devices+0x64/0x98
[  237.161293] [] process_one_work+0x128/0x2e4
[  237.167027] [] worker_thread+0x58/0x434
[  237.172415] [] kthread+0xd4/0xe8
[  237.177198] [] ret_from_fork+0x10/0x50
[  237.182557] sysfs group 'power' not found for kobject 'end_device-0:0:5'

(this can be really huge when an expander is unplugged)

The problem is with the process of sas_port and domain_device
destruction in domain revalidation. There is a 2-stage process:
In domain revalidation (which runs in work queue context), if a
domain_device is discovered to be gone, then the following happens:
- the domain_device is queued for destruction in a separate work item
- the associated sas_port is destroyed immediately

This causes a problem in that the sas_port associated with
a domain_device is destroyed prior the domain_device: this causes
the sysfs WARN. Essentially the "rug has been pulled from underneath".

Also, likewise, when a root port is deformed due to loss of signal,
we have the same issue.

To solve, destroy the sas_port in a separate work item to which
we do the domain revalidation with a new discovery event, as follows:
- When a domain_device is detected to be gone, the domain_device is
  queued for destruction in a separate work item. The associated
  sas_port is also queued for destruction in another separate work item
  (needs to be queued 2nd)
- the domain_device is destroyed
- the sas_port is destroyed
[similar is done for loss of signal event, in sas_port_deformed()].

Fixes: 87c8331fcf72e501c3a3c0cdc5c [SCSI] libsas: prevent domain
rediscovery competing with ata error handling

Signed-off-by: John Garry 

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 60de662..01d0fe2 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -361,7 +361,7 @@ static void sas_destruct_devices(struct work_struct *work)

clear_bit(DISCE_DESTRUCT, >disc.pending);

-   list_for_each_entry_safe(dev, n, >destroy_list, disco_list_node) {
+   list_for_each_entry_safe(dev, n, >dev_destroy_list, 
disco_list_node) {
list_del_init(>disco_list_node);

sas_remove_children(>rphy->dev);
@@ -383,7 +383,7 @@ void sas_unregister_dev(struct asd_sas_port *port, struct 
domain_device *dev)

if (!test_and_set_bit(SAS_DEV_DESTROY, >state)) {
sas_rphy_unlink(dev->rphy);
-   list_move_tail(>disco_list_node, >destroy_list);
+   list_move_tail(>disco_list_node, >dev_destroy_list);
sas_discover_event(dev->port, DISCE_DESTRUCT);
}
 }
@@ -525,6 +525,28 @@ static void sas_revalidate_domain(struct work_struct *work)
mutex_unlock(>disco_mutex);
 }

+/* -- Async Port destruct -- */
+static void sas_async_port_destruct(struct work_struct *work)
+{
+   struct sas_discovery_event *ev = to_sas_discovery_event(work);
+   struct asd_sas_port *port = ev->port;
+   struct sas_port *sas_port, *n;
+
+   clear_bit(DISCE_PORT_DESTRUCT, >disc.pending);
+
+   list_for_each_entry_safe(sas_port, n, >port_destroy_list, 
destroy_list) {
+   list_del_init(>port_destroy_list);
+
+   sas_port_delete(sas_port);
+   }
+}
+
+void sas_port_destruct(struct asd_sas_port *port, struct sas_port *sas_port)
+{
+   list_move_tail(_port->destroy_list, >port_destroy_list);
+   sas_discover_event(port, DISCE_PORT_DESTRUCT);
+}
+
 /* 

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

[John Garry]

On 03/11/2016 14:58, John Garry wrote:

The following patch introduces an annoying WARN
when a device is removed from the SAS topology:
[SCSI] libsas: prevent domain rediscovery competing with ata error handling



Are there any views on this patch? I would have thought that the parties 
who use the drivers based on libsas would be interested in fixing this bug.


BTW, We are internally testing, hence the RFC.

Thanks in advance,
John


A sample WARN is as follows:
[  236.842227] WARNING: CPU: 7 PID: 1520 at fs/sysfs/group.c:237 
sysfs_remove_group+0x90/0x98
[  236.850465] Modules linked in:
[  236.853544]
[  236.855045] CPU: 7 PID: 1520 Comm: kworker/u64:4 Tainted: GW   
4.9.0-rc1-15310-g3fbc29e-dirty #676
[  236.865010] Hardware name: Huawei Taishan 2180 /D03, BIOS Estuary v2.3 D03 
UEFI 08/17/2016
[  236.873249] Workqueue: scsi_wq_0 sas_destruct_devices
[  236.878317] task: 8027ba31b200 task.stack: 8027b9d44000
[  236.884225] PC is at sysfs_remove_group+0x90/0x98
[  236.888920] LR is at sysfs_remove_group+0x90/0x98
[  236.893616] pc : [] lr : [] pstate: 
6145
[  236.900989] sp : 8027b9d47bf0

< snip >

[  237.116463] [] sysfs_remove_group+0x90/0x98
[  237.122197] [] dpm_sysfs_remove+0x58/0x68
[  237.127758] [] device_del+0x40/0x218
[  237.132886] [] device_unregister+0x14/0x2c
[  237.138536] [] bsg_unregister_queue+0x5c/0xa0
[  237.12] [] sas_rphy_remove+0x44/0x80
[  237.149915] [] sas_rphy_delete+0x14/0x28
[  237.155388] [] sas_destruct_devices+0x64/0x98
[  237.161293] [] process_one_work+0x128/0x2e4
[  237.167027] [] worker_thread+0x58/0x434
[  237.172415] [] kthread+0xd4/0xe8
[  237.177198] [] ret_from_fork+0x10/0x50
[  237.182557] sysfs group 'power' not found for kobject 'end_device-0:0:5'

(this can be really huge when an expander is unplugged)

The problem is with the process of sas_port and domain_device
destruction in domain revalidation. There is a 2-stage process:
In domain revalidation (which runs in work queue context), if a
domain_device is discovered to be gone, then the following happens:
- the domain_device is queued for destruction in a separate work item
- the associated sas_port is destroyed immediately

This causes a problem in that the sas_port associated with
a domain_device is destroyed prior the domain_device: this causes
the sysfs WARN. Essentially the "rug has been pulled from underneath".

Also, likewise, when a root port is deformed due to loss of signal,
we have the same issue.

To solve, destroy the sas_port in a separate work item to which
we do the domain revalidation with a new discovery event, as follows:
- When a domain_device is detected to be gone, the domain_device is
  queued for destruction in a separate work item. The associated
  sas_port is also queued for destruction in another separate work item
  (needs to be queued 2nd)
- the domain_device is destroyed
- the sas_port is destroyed
[similar is done for loss of signal event, in sas_port_deformed()].

Fixes: 87c8331fcf72e501c3a3c0cdc5c [SCSI] libsas: prevent domain
rediscovery competing with ata error handling

Signed-off-by: John Garry 

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 60de662..01d0fe2 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -361,7 +361,7 @@ static void sas_destruct_devices(struct work_struct *work)

clear_bit(DISCE_DESTRUCT, >disc.pending);

-   list_for_each_entry_safe(dev, n, >destroy_list, disco_list_node) {
+   list_for_each_entry_safe(dev, n, >dev_destroy_list, 
disco_list_node) {
list_del_init(>disco_list_node);

sas_remove_children(>rphy->dev);
@@ -383,7 +383,7 @@ void sas_unregister_dev(struct asd_sas_port *port, struct 
domain_device *dev)

if (!test_and_set_bit(SAS_DEV_DESTROY, >state)) {
sas_rphy_unlink(dev->rphy);
-   list_move_tail(>disco_list_node, >destroy_list);
+   list_move_tail(>disco_list_node, >dev_destroy_list);
sas_discover_event(dev->port, DISCE_DESTRUCT);
}
 }
@@ -525,6 +525,28 @@ static void sas_revalidate_domain(struct work_struct *work)
mutex_unlock(>disco_mutex);
 }

+/* -- Async Port destruct -- */
+static void sas_async_port_destruct(struct work_struct *work)
+{
+   struct sas_discovery_event *ev = to_sas_discovery_event(work);
+   struct asd_sas_port *port = ev->port;
+   struct sas_port *sas_port, *n;
+
+   clear_bit(DISCE_PORT_DESTRUCT, >disc.pending);
+
+   list_for_each_entry_safe(sas_port, n, >port_destroy_list, 
destroy_list) {
+   list_del_init(>port_destroy_list);
+
+   sas_port_delete(sas_port);
+   }
+}
+
+void sas_port_destruct(struct asd_sas_port *port, struct sas_port *sas_port)
+{
+   list_move_tail(_port->destroy_list, >port_destroy_list);
+   sas_discover_event(port, DISCE_PORT_DESTRUCT);
+}
+
 /* -- Events 

Re: Including images on Sphinx documents

[Mauro Carvalho Chehab]

Em Mon, 07 Nov 2016 12:53:55 +0200
Jani Nikula  escreveu:

> On Mon, 07 Nov 2016, Mauro Carvalho Chehab  wrote:
> > Hi Jon,
> >
> > I'm trying to sort out the next steps to do after KS, with regards to
> > images included on RST files.
> >
> > The issue is that Sphinx image support highly depends on the output
> > format. Also, despite TexLive support for svg and png images[1], Sphinx
> > doesn't produce the right LaTeX commands to use svg[2]. On my tests
> > with PNG on my notebook, it also didn't seem to do the right thing for
> > PNG either. So, it seems that the only safe way to support images is
> > to convert all of them to PDF for latex/pdf build.
> >
> > [1] On Fedora, via texlive-dvipng and texlive-svg
> > [2] https://github.com/sphinx-doc/sphinx/issues/1907
> >
> > As far as I understand from KS, two decisions was taken:
> >
> > - We're not adding a sphinx extension to run generic commands;
> > - The PDF images should be build in runtime from their source files
> >   (either svg or bitmap), and not ship anymore the corresponding
> >   PDF files generated from its source.
> >
> > As you know, we use several images at the media documentation:
> > https://www.kernel.org/doc/html/latest/_images/
> >
> > Those images are tightly coupled with the explanation texts. So,
> > maintaining them away from the documentation is not an option.
> >
> > I was originally thinking that adding a graphviz extension would solve the
> > issue, but, in fact, most of the images aren't diagrams. Instead, there are 
> > several ones with images showing the result of passing certain parameters to
> > the ioctls, explaining things like scale and cropping and how bytes are
> > packed on some image formats.
> >
> > Linus proposed to call some image conversion tool like ImageMagick or
> > inkscape to convert them to PDF when building the pdfdocs or latexdocs
> > target at Makefile, but there's an issue with that: Sphinx doesn't read
> > files from Documentation/output, and writing them directly at the
> > source dir would be against what it is expected when the "O=" argument
> > is passed to make. 
> >
> > So, we have a few alternatives:
> >
> > 1) copy (or symlink) all rst files to Documentation/output (or to the
> >build dir specified via O= directive) and generate the *.pdf there,
> >and produce those converted images via Makefile.;
> >
> > 2) add an Sphinx extension that would internally call ImageMagick and/or
> >inkscape to convert the bitmap;
> >
> > 3) if possible, add an extension to trick Sphinx for it to consider the 
> >output dir as a source dir too.  
> 
> Looking at the available extensions, and the images to be displayed,
> seems to me making svg work, somehow, is the right approach. (As opposed
> to trying to represent the images in graphviz or whatnot.)

I guess answered this one already, but it got lost somehow...

The problem is not just with svg. Sphinx also do the wrong thing with
PNG, despite apparently generating the right LaTeX image include command.

> IIUC texlive supports displaying svg directly, but the problem is that
> Sphinx produces bad latex for that. Can we make it work by manually
> writing the latex? If yes, we wouldn't need to use an external tool to
> convert the svg to something else, but rather fix the latex. Thus:
> 
> 4a) See if this works:
> 
> .. only:: html
> 
>.. image:: foo.svg

We're currently using .. figure:: instead, as it allow optional caption
and legend, but I got the idea.

> .. raw:: latex
> 
>

That is a horrible hack, and will lose other attributes at
image:: (or figure::), like :align:

Also, it won't solve, as the images will need to be copied to the
build dir via Makefile, as Spinx only copies the images it recognizes.

So, in practice, the only difference is that Makefile would be calling
"cp" instead of "convert", plus we'll have to hack all ReST sources.

> 4b) Add a directive extension to make the above happen automatically.

If doable, I agree that this is the best solution. Any volunteers to write
such extension?

> Of course, the correct fix is to have this fixed in upstream Sphinx, but
> as a workaround an extension doing the above seems plausible, and not
> too much effort - provided that we can make the raw latex work.

Yeah, fixing it on Sphinx upstream would be the best, but we'll still
need to maintain the workaround for a while for the unpatched versions
of Sphinx.

Thanks,
Mauro

Re: Including images on Sphinx documents

[Mauro Carvalho Chehab]

Em Mon, 07 Nov 2016 12:53:55 +0200
Jani Nikula  escreveu:

> On Mon, 07 Nov 2016, Mauro Carvalho Chehab  wrote:
> > Hi Jon,
> >
> > I'm trying to sort out the next steps to do after KS, with regards to
> > images included on RST files.
> >
> > The issue is that Sphinx image support highly depends on the output
> > format. Also, despite TexLive support for svg and png images[1], Sphinx
> > doesn't produce the right LaTeX commands to use svg[2]. On my tests
> > with PNG on my notebook, it also didn't seem to do the right thing for
> > PNG either. So, it seems that the only safe way to support images is
> > to convert all of them to PDF for latex/pdf build.
> >
> > [1] On Fedora, via texlive-dvipng and texlive-svg
> > [2] https://github.com/sphinx-doc/sphinx/issues/1907
> >
> > As far as I understand from KS, two decisions was taken:
> >
> > - We're not adding a sphinx extension to run generic commands;
> > - The PDF images should be build in runtime from their source files
> >   (either svg or bitmap), and not ship anymore the corresponding
> >   PDF files generated from its source.
> >
> > As you know, we use several images at the media documentation:
> > https://www.kernel.org/doc/html/latest/_images/
> >
> > Those images are tightly coupled with the explanation texts. So,
> > maintaining them away from the documentation is not an option.
> >
> > I was originally thinking that adding a graphviz extension would solve the
> > issue, but, in fact, most of the images aren't diagrams. Instead, there are 
> > several ones with images showing the result of passing certain parameters to
> > the ioctls, explaining things like scale and cropping and how bytes are
> > packed on some image formats.
> >
> > Linus proposed to call some image conversion tool like ImageMagick or
> > inkscape to convert them to PDF when building the pdfdocs or latexdocs
> > target at Makefile, but there's an issue with that: Sphinx doesn't read
> > files from Documentation/output, and writing them directly at the
> > source dir would be against what it is expected when the "O=" argument
> > is passed to make. 
> >
> > So, we have a few alternatives:
> >
> > 1) copy (or symlink) all rst files to Documentation/output (or to the
> >build dir specified via O= directive) and generate the *.pdf there,
> >and produce those converted images via Makefile.;
> >
> > 2) add an Sphinx extension that would internally call ImageMagick and/or
> >inkscape to convert the bitmap;
> >
> > 3) if possible, add an extension to trick Sphinx for it to consider the 
> >output dir as a source dir too.  
> 
> Looking at the available extensions, and the images to be displayed,
> seems to me making svg work, somehow, is the right approach. (As opposed
> to trying to represent the images in graphviz or whatnot.)

I guess answered this one already, but it got lost somehow...

The problem is not just with svg. Sphinx also do the wrong thing with
PNG, despite apparently generating the right LaTeX image include command.

> IIUC texlive supports displaying svg directly, but the problem is that
> Sphinx produces bad latex for that. Can we make it work by manually
> writing the latex? If yes, we wouldn't need to use an external tool to
> convert the svg to something else, but rather fix the latex. Thus:
> 
> 4a) See if this works:
> 
> .. only:: html
> 
>.. image:: foo.svg

We're currently using .. figure:: instead, as it allow optional caption
and legend, but I got the idea.

> .. raw:: latex
> 
>

That is a horrible hack, and will lose other attributes at
image:: (or figure::), like :align:

Also, it won't solve, as the images will need to be copied to the
build dir via Makefile, as Spinx only copies the images it recognizes.

So, in practice, the only difference is that Makefile would be calling
"cp" instead of "convert", plus we'll have to hack all ReST sources.

> 4b) Add a directive extension to make the above happen automatically.

If doable, I agree that this is the best solution. Any volunteers to write
such extension?

> Of course, the correct fix is to have this fixed in upstream Sphinx, but
> as a workaround an extension doing the above seems plausible, and not
> too much effort - provided that we can make the raw latex work.

Yeah, fixing it on Sphinx upstream would be the best, but we'll still
need to maintain the workaround for a while for the unpatched versions
of Sphinx.

Thanks,
Mauro

[PATCH v9 4/8] thunderbolt: Networking state machine

[Amir Levy]

This patch builds the peer to peer communication path.
Communication is established by a negotiation process whereby messages are
sent back and forth between the peers until a connection is established.
This includes the Thunderbolt Network driver communication with the second
peer via Intel Connection Manager(ICM) firmware.
  ++++
  |Host 1  ||Host 2  |
  ||||
  | +---+  || +---+  |
  | |Thunderbolt|  || |Thunderbolt|  |
  | |Networking |  || |Networking |  |
  | |Driver |  || |Driver |  |
  | +---+  || +---+  |
  |  ^ ||  ^ |
  |  | ||  | |
  | ++---+ || ++---+ |
  | |Thunderbolt |   | || |Thunderbolt |   | |
  | |Controller  v   | || |Controller  v   | |
  | | +---+  | || | +---+  | |
  | | |ICM|<-+-++-+>|ICM|  | |
  | | +---+  | || | +---+  | |
  | ++ || ++ |
  ++++
Note that this patch only establishes the link between the two hosts and
not Network Packet handling - this is dealt with in the next patch.

Signed-off-by: Amir Levy 
---
 drivers/thunderbolt/icm/Makefile  |   2 +-
 drivers/thunderbolt/icm/icm_nhi.c | 262 -
 drivers/thunderbolt/icm/net.c | 783 ++
 drivers/thunderbolt/icm/net.h |  70 
 4 files changed, 1109 insertions(+), 8 deletions(-)
 create mode 100644 drivers/thunderbolt/icm/net.c

diff --git a/drivers/thunderbolt/icm/Makefile b/drivers/thunderbolt/icm/Makefile
index f0d0fbb..94a2797 100644
--- a/drivers/thunderbolt/icm/Makefile
+++ b/drivers/thunderbolt/icm/Makefile
@@ -1,2 +1,2 @@
 obj-${CONFIG_THUNDERBOLT_ICM} += thunderbolt-icm.o
-thunderbolt-icm-objs := icm_nhi.o
+thunderbolt-icm-objs := icm_nhi.o net.o
diff --git a/drivers/thunderbolt/icm/icm_nhi.c 
b/drivers/thunderbolt/icm/icm_nhi.c
index c843ce8..edc910b 100644
--- a/drivers/thunderbolt/icm/icm_nhi.c
+++ b/drivers/thunderbolt/icm/icm_nhi.c
@@ -64,6 +64,13 @@ static const struct nla_policy nhi_genl_policy[NHI_ATTR_MAX 
+ 1] = {
.len = TBT_ICM_RING_MAX_FRAME_SIZE },
[NHI_ATTR_MSG_FROM_ICM] = { .type = NLA_BINARY,
.len = TBT_ICM_RING_MAX_FRAME_SIZE },
+   [NHI_ATTR_LOCAL_ROUTE_STRING]   = {
+   .len = sizeof(struct route_string) },
+   [NHI_ATTR_LOCAL_UUID]   = { .len = sizeof(uuid_be) },
+   [NHI_ATTR_REMOTE_UUID]  = { .len = sizeof(uuid_be) },
+   [NHI_ATTR_LOCAL_DEPTH]  = { .type = NLA_U8, },
+   [NHI_ATTR_ENABLE_FULL_E2E]  = { .type = NLA_FLAG, },
+   [NHI_ATTR_MATCH_FRAME_ID]   = { .type = NLA_FLAG, },
 };
 
 /* NHI genetlink family */
@@ -480,6 +487,29 @@ int nhi_mailbox(struct tbt_nhi_ctxt *nhi_ctxt, u32 cmd, 
u32 data, bool deinit)
return 0;
 }
 
+static inline bool nhi_is_path_disconnected(u32 cmd, u8 num_ports)
+{
+   return (cmd >= DISCONNECT_PORT_A_INTER_DOMAIN_PATH &&
+   cmd < (DISCONNECT_PORT_A_INTER_DOMAIN_PATH + num_ports));
+}
+
+static int nhi_mailbox_disconn_path(struct tbt_nhi_ctxt *nhi_ctxt, u32 cmd)
+   __releases(_list_mutex)
+{
+   struct port_net_dev *port;
+   u32 port_num = cmd - DISCONNECT_PORT_A_INTER_DOMAIN_PATH;
+
+   port = &(nhi_ctxt->net_devices[port_num]);
+   mutex_lock(>state_mutex);
+
+   mutex_unlock(_list_mutex);
+   port->medium_sts = MEDIUM_READY_FOR_APPROVAL;
+   if (port->net_dev)
+   negotiation_events(port->net_dev, MEDIUM_DISCONNECTED);
+   mutex_unlock(>state_mutex);
+   return  0;
+}
+
 static int nhi_mailbox_generic(struct tbt_nhi_ctxt *nhi_ctxt, u32 mb_cmd)
__releases(_list_mutex)
 {
@@ -526,13 +556,90 @@ static int nhi_genl_mailbox(__always_unused struct 
sk_buff *u_skb,
return -ERESTART;
 
nhi_ctxt = nhi_search_ctxt(*(u32 *)info->userhdr);
-   if (nhi_ctxt && !nhi_ctxt->d0_exit)
-   return nhi_mailbox_generic(nhi_ctxt, mb_cmd);
+   if (nhi_ctxt && !nhi_ctxt->d0_exit) {
+
+   /* rwsem is released later by the below functions */
+   if (nhi_is_path_disconnected(cmd, nhi_ctxt->num_ports))
+   return nhi_mailbox_disconn_path(nhi_ctxt, cmd);
+   else
+   return nhi_mailbox_generic(nhi_ctxt, mb_cmd);
+
+   }
 
mutex_unlock(_list_mutex);
return -ENODEV;
 }
 
+static int 

[PATCH v9 1/8] thunderbolt: Macro rename

[Amir Levy]

This first patch updates the NHI Thunderbolt controller registers file to
reflect that it is not only for Cactus Ridge.
No functional change intended.

Signed-off-by: Amir Levy 
Signed-off-by: Andreas Noever 
---
 drivers/thunderbolt/nhi_regs.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
index 86b996c..75cf069 100644
--- a/drivers/thunderbolt/nhi_regs.h
+++ b/drivers/thunderbolt/nhi_regs.h
@@ -1,11 +1,11 @@
 /*
- * Thunderbolt Cactus Ridge driver - NHI registers
+ * Thunderbolt driver - NHI registers
  *
  * Copyright (c) 2014 Andreas Noever 
  */
 
-#ifndef DSL3510_REGS_H_
-#define DSL3510_REGS_H_
+#ifndef NHI_REGS_H_
+#define NHI_REGS_H_
 
 #include 
 
-- 
2.7.4

[PATCH v9 7/8] thunderbolt: Networking doc

[Amir Levy]

Adding Thunderbolt(TM) networking documentation.

Signed-off-by: Amir Levy 
---
 Documentation/00-INDEX   |   2 +
 Documentation/thunderbolt/networking.txt | 132 +++
 2 files changed, 134 insertions(+)
 create mode 100644 Documentation/thunderbolt/networking.txt

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 3acc4f1..0239e68 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -440,6 +440,8 @@ this_cpu_ops.txt
- List rationale behind and the way to use this_cpu operations.
 thermal/
- directory with information on managing thermal issues (CPU/temp)
+thunderbolt/
+   - directory with info regarding Thunderbolt.
 trace/
- directory with info on tracing technologies within linux
 unaligned-memory-access.txt
diff --git a/Documentation/thunderbolt/networking.txt 
b/Documentation/thunderbolt/networking.txt
new file mode 100644
index 000..88d1c12
--- /dev/null
+++ b/Documentation/thunderbolt/networking.txt
@@ -0,0 +1,132 @@
+Intel Thunderbolt(TM) Networking driver
+===
+
+Copyright(c) 2013 - 2016 Intel Corporation.
+
+Contact Information:
+Intel Thunderbolt mailing list 
+Edited by Amir Levy 
+
+Overview
+
+
+* The Thunderbolt Networking driver enables peer to peer networking on 
non-Apple
+  platforms running Linux.
+
+* The driver creates a virtual Ethernet device that enables computer to 
computer
+  communication over the Thunderbolt cable.
+
+* Using Thunderbolt Networking you can perform high speed file transfers 
between
+  computers, perform PC migrations and/or set up small workgroups with shared
+  storage without compromising any other Thunderbolt functionality.
+
+* The driver is located in drivers/thunderbolt/icm.
+
+* This driver will function only on non-Apple platforms with firmware based
+  Thunderbolt controllers that support Thunderbolt Networking.
+
+  ++++
+  |Host 1  ||Host 2  |
+  ||||
+  |   +---+||+---+   |
+  |   |Network||||Network|   |
+  |   |Stack  ||||Stack  |   |
+  |   +---+||+---+   |
+  |   ^||^   |
+  |   ||||   |
+  |   v||v   |
+  | +---+  ||  +---+ |
+  | |Thunderbolt|  ||  |Thunderbolt| |
+  | |Networking |  ||  |Networking | |
+  | |Driver |  ||  |Driver | |
+  | +---+  ||  +---+ |
+  |   ^||^   |
+  |   ||||   |
+  |   v||v   |
+  | +---+  ||  +---+ |
+  | |Thunderbolt|  ||  |Thunderbolt| |
+  | |Controller |<-++->|Controller | |
+  | |with ICM   |  ||  |with ICM   | |
+  | |enabled|  ||  |enabled| |
+  | +---+  ||  +---+ |
+  ++++
+
+Files
+=
+
+The following files are located in the drivers/thunderbolt/icm directory:
+
+- icm_nhi.c/h: These files allow communication with the firmware (Intel
+  Connection Manager) based controller. They also create an interface for
+  netlink communication with a user space daemon.
+
+- net.c/net.h: These files implement the 'eth' interface for the
+  Thunderbolt(TM) Networking.
+
+Interface to User Space
+===
+
+The interface to the user space module is implemented through a Generic 
Netlink.
+This is the communications protocol between the Thunderbolt driver and the user
+space application.
+
+Note that this interface mediates user space communication with ICM.
+(Existing Linux tools can be used to configure the network interface.)
+
+The Thunderbolt Daemon utilizes this interface to communicate with the driver.
+To be accessed by the user space module, both kernel and user space modules
+have to register with the same GENL_NAME.
+For the purpose of the Thunderbolt Network driver, "thunderbolt" is used.
+The registration is done at driver initialization time for all instances
+of the Thunderbolt controllers. The communication is carried through 
pre-defined
+Thunderbolt messages. Each specific message has a callback function that is
+called when the related message is received.
+
+Message Definitions:
+* NHI_CMD_UNSPEC: Not used.
+* NHI_CMD_SUBSCRIBE: Subscription request from daemon to driver to open the
+  communication channel.
+* NHI_CMD_UNSUBSCRIBE: Request from daemon to driver to unsubscribe and
+  to close communication channel.
+* NHI_CMD_QUERY_INFORMATION: Request information from the driver 

[PATCH v9 4/8] thunderbolt: Networking state machine

[Amir Levy]

This patch builds the peer to peer communication path.
Communication is established by a negotiation process whereby messages are
sent back and forth between the peers until a connection is established.
This includes the Thunderbolt Network driver communication with the second
peer via Intel Connection Manager(ICM) firmware.
  ++++
  |Host 1  ||Host 2  |
  ||||
  | +---+  || +---+  |
  | |Thunderbolt|  || |Thunderbolt|  |
  | |Networking |  || |Networking |  |
  | |Driver |  || |Driver |  |
  | +---+  || +---+  |
  |  ^ ||  ^ |
  |  | ||  | |
  | ++---+ || ++---+ |
  | |Thunderbolt |   | || |Thunderbolt |   | |
  | |Controller  v   | || |Controller  v   | |
  | | +---+  | || | +---+  | |
  | | |ICM|<-+-++-+>|ICM|  | |
  | | +---+  | || | +---+  | |
  | ++ || ++ |
  ++++
Note that this patch only establishes the link between the two hosts and
not Network Packet handling - this is dealt with in the next patch.

Signed-off-by: Amir Levy 
---
 drivers/thunderbolt/icm/Makefile  |   2 +-
 drivers/thunderbolt/icm/icm_nhi.c | 262 -
 drivers/thunderbolt/icm/net.c | 783 ++
 drivers/thunderbolt/icm/net.h |  70 
 4 files changed, 1109 insertions(+), 8 deletions(-)
 create mode 100644 drivers/thunderbolt/icm/net.c

diff --git a/drivers/thunderbolt/icm/Makefile b/drivers/thunderbolt/icm/Makefile
index f0d0fbb..94a2797 100644
--- a/drivers/thunderbolt/icm/Makefile
+++ b/drivers/thunderbolt/icm/Makefile
@@ -1,2 +1,2 @@
 obj-${CONFIG_THUNDERBOLT_ICM} += thunderbolt-icm.o
-thunderbolt-icm-objs := icm_nhi.o
+thunderbolt-icm-objs := icm_nhi.o net.o
diff --git a/drivers/thunderbolt/icm/icm_nhi.c 
b/drivers/thunderbolt/icm/icm_nhi.c
index c843ce8..edc910b 100644
--- a/drivers/thunderbolt/icm/icm_nhi.c
+++ b/drivers/thunderbolt/icm/icm_nhi.c
@@ -64,6 +64,13 @@ static const struct nla_policy nhi_genl_policy[NHI_ATTR_MAX 
+ 1] = {
.len = TBT_ICM_RING_MAX_FRAME_SIZE },
[NHI_ATTR_MSG_FROM_ICM] = { .type = NLA_BINARY,
.len = TBT_ICM_RING_MAX_FRAME_SIZE },
+   [NHI_ATTR_LOCAL_ROUTE_STRING]   = {
+   .len = sizeof(struct route_string) },
+   [NHI_ATTR_LOCAL_UUID]   = { .len = sizeof(uuid_be) },
+   [NHI_ATTR_REMOTE_UUID]  = { .len = sizeof(uuid_be) },
+   [NHI_ATTR_LOCAL_DEPTH]  = { .type = NLA_U8, },
+   [NHI_ATTR_ENABLE_FULL_E2E]  = { .type = NLA_FLAG, },
+   [NHI_ATTR_MATCH_FRAME_ID]   = { .type = NLA_FLAG, },
 };
 
 /* NHI genetlink family */
@@ -480,6 +487,29 @@ int nhi_mailbox(struct tbt_nhi_ctxt *nhi_ctxt, u32 cmd, 
u32 data, bool deinit)
return 0;
 }
 
+static inline bool nhi_is_path_disconnected(u32 cmd, u8 num_ports)
+{
+   return (cmd >= DISCONNECT_PORT_A_INTER_DOMAIN_PATH &&
+   cmd < (DISCONNECT_PORT_A_INTER_DOMAIN_PATH + num_ports));
+}
+
+static int nhi_mailbox_disconn_path(struct tbt_nhi_ctxt *nhi_ctxt, u32 cmd)
+   __releases(_list_mutex)
+{
+   struct port_net_dev *port;
+   u32 port_num = cmd - DISCONNECT_PORT_A_INTER_DOMAIN_PATH;
+
+   port = &(nhi_ctxt->net_devices[port_num]);
+   mutex_lock(>state_mutex);
+
+   mutex_unlock(_list_mutex);
+   port->medium_sts = MEDIUM_READY_FOR_APPROVAL;
+   if (port->net_dev)
+   negotiation_events(port->net_dev, MEDIUM_DISCONNECTED);
+   mutex_unlock(>state_mutex);
+   return  0;
+}
+
 static int nhi_mailbox_generic(struct tbt_nhi_ctxt *nhi_ctxt, u32 mb_cmd)
__releases(_list_mutex)
 {
@@ -526,13 +556,90 @@ static int nhi_genl_mailbox(__always_unused struct 
sk_buff *u_skb,
return -ERESTART;
 
nhi_ctxt = nhi_search_ctxt(*(u32 *)info->userhdr);
-   if (nhi_ctxt && !nhi_ctxt->d0_exit)
-   return nhi_mailbox_generic(nhi_ctxt, mb_cmd);
+   if (nhi_ctxt && !nhi_ctxt->d0_exit) {
+
+   /* rwsem is released later by the below functions */
+   if (nhi_is_path_disconnected(cmd, nhi_ctxt->num_ports))
+   return nhi_mailbox_disconn_path(nhi_ctxt, cmd);
+   else
+   return nhi_mailbox_generic(nhi_ctxt, mb_cmd);
+
+   }
 
mutex_unlock(_list_mutex);
return -ENODEV;
 }
 
+static int nhi_genl_approve_networking(__always_unused struct 

[PATCH v9 1/8] thunderbolt: Macro rename

[Amir Levy]

This first patch updates the NHI Thunderbolt controller registers file to
reflect that it is not only for Cactus Ridge.
No functional change intended.

Signed-off-by: Amir Levy 
Signed-off-by: Andreas Noever 
---
 drivers/thunderbolt/nhi_regs.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
index 86b996c..75cf069 100644
--- a/drivers/thunderbolt/nhi_regs.h
+++ b/drivers/thunderbolt/nhi_regs.h
@@ -1,11 +1,11 @@
 /*
- * Thunderbolt Cactus Ridge driver - NHI registers
+ * Thunderbolt driver - NHI registers
  *
  * Copyright (c) 2014 Andreas Noever 
  */
 
-#ifndef DSL3510_REGS_H_
-#define DSL3510_REGS_H_
+#ifndef NHI_REGS_H_
+#define NHI_REGS_H_
 
 #include 
 
-- 
2.7.4

[PATCH v9 7/8] thunderbolt: Networking doc

[Amir Levy]

Adding Thunderbolt(TM) networking documentation.

Signed-off-by: Amir Levy 
---
 Documentation/00-INDEX   |   2 +
 Documentation/thunderbolt/networking.txt | 132 +++
 2 files changed, 134 insertions(+)
 create mode 100644 Documentation/thunderbolt/networking.txt

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 3acc4f1..0239e68 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -440,6 +440,8 @@ this_cpu_ops.txt
- List rationale behind and the way to use this_cpu operations.
 thermal/
- directory with information on managing thermal issues (CPU/temp)
+thunderbolt/
+   - directory with info regarding Thunderbolt.
 trace/
- directory with info on tracing technologies within linux
 unaligned-memory-access.txt
diff --git a/Documentation/thunderbolt/networking.txt 
b/Documentation/thunderbolt/networking.txt
new file mode 100644
index 000..88d1c12
--- /dev/null
+++ b/Documentation/thunderbolt/networking.txt
@@ -0,0 +1,132 @@
+Intel Thunderbolt(TM) Networking driver
+===
+
+Copyright(c) 2013 - 2016 Intel Corporation.
+
+Contact Information:
+Intel Thunderbolt mailing list 
+Edited by Amir Levy 
+
+Overview
+
+
+* The Thunderbolt Networking driver enables peer to peer networking on 
non-Apple
+  platforms running Linux.
+
+* The driver creates a virtual Ethernet device that enables computer to 
computer
+  communication over the Thunderbolt cable.
+
+* Using Thunderbolt Networking you can perform high speed file transfers 
between
+  computers, perform PC migrations and/or set up small workgroups with shared
+  storage without compromising any other Thunderbolt functionality.
+
+* The driver is located in drivers/thunderbolt/icm.
+
+* This driver will function only on non-Apple platforms with firmware based
+  Thunderbolt controllers that support Thunderbolt Networking.
+
+  ++++
+  |Host 1  ||Host 2  |
+  ||||
+  |   +---+||+---+   |
+  |   |Network||||Network|   |
+  |   |Stack  ||||Stack  |   |
+  |   +---+||+---+   |
+  |   ^||^   |
+  |   ||||   |
+  |   v||v   |
+  | +---+  ||  +---+ |
+  | |Thunderbolt|  ||  |Thunderbolt| |
+  | |Networking |  ||  |Networking | |
+  | |Driver |  ||  |Driver | |
+  | +---+  ||  +---+ |
+  |   ^||^   |
+  |   ||||   |
+  |   v||v   |
+  | +---+  ||  +---+ |
+  | |Thunderbolt|  ||  |Thunderbolt| |
+  | |Controller |<-++->|Controller | |
+  | |with ICM   |  ||  |with ICM   | |
+  | |enabled|  ||  |enabled| |
+  | +---+  ||  +---+ |
+  ++++
+
+Files
+=
+
+The following files are located in the drivers/thunderbolt/icm directory:
+
+- icm_nhi.c/h: These files allow communication with the firmware (Intel
+  Connection Manager) based controller. They also create an interface for
+  netlink communication with a user space daemon.
+
+- net.c/net.h: These files implement the 'eth' interface for the
+  Thunderbolt(TM) Networking.
+
+Interface to User Space
+===
+
+The interface to the user space module is implemented through a Generic 
Netlink.
+This is the communications protocol between the Thunderbolt driver and the user
+space application.
+
+Note that this interface mediates user space communication with ICM.
+(Existing Linux tools can be used to configure the network interface.)
+
+The Thunderbolt Daemon utilizes this interface to communicate with the driver.
+To be accessed by the user space module, both kernel and user space modules
+have to register with the same GENL_NAME.
+For the purpose of the Thunderbolt Network driver, "thunderbolt" is used.
+The registration is done at driver initialization time for all instances
+of the Thunderbolt controllers. The communication is carried through 
pre-defined
+Thunderbolt messages. Each specific message has a callback function that is
+called when the related message is received.
+
+Message Definitions:
+* NHI_CMD_UNSPEC: Not used.
+* NHI_CMD_SUBSCRIBE: Subscription request from daemon to driver to open the
+  communication channel.
+* NHI_CMD_UNSUBSCRIBE: Request from daemon to driver to unsubscribe and
+  to close communication channel.
+* NHI_CMD_QUERY_INFORMATION: Request information from the driver such as
+  driver version, FW version offset, number of ports in the controller
+  and 

[PATCH v9 5/8] thunderbolt: Networking transmit and receive

[Amir Levy]

This patch provides the handling interface for sending and receiving
network packets between the hosts over the full communication route
(using the communication path established in the previous patch).

The Thunderbolt Network driver interfaces the Linux network stack
and the hardware controller configuration to handle packet transmissions:
  ++++
  |Host 1  ||Host 2  |
  ||||
  |   +---+||+---+   |
  |   |Network||||Network|   |
  |   |Stack  ||||Stack  |   |
  |   +---+||+---+   |
  |   ^||^   |
  |   ||||   |
  |   v||v   |
  | +---+  ||  +---+ |
  | |Thunderbolt|  ||  |Thunderbolt| |
  | |Networking |  ||  |Networking | |
  | |Driver |  ||  |Driver | |
  | +---+  ||  +---+ |
  |   ^||^   |
  |   ||||   |
  |   v||v   |
  | +---+  ||  +---+ |
  | |Thunderbolt|  ||  |Thunderbolt| |
  | |Controller |<-++->|Controller | |
  | +---+  ||  +---+ |
  ++++

Signed-off-by: Amir Levy 
---
 drivers/thunderbolt/icm/icm_nhi.c |   15 +
 drivers/thunderbolt/icm/net.c | 1471 +
 2 files changed, 1486 insertions(+)

diff --git a/drivers/thunderbolt/icm/icm_nhi.c 
b/drivers/thunderbolt/icm/icm_nhi.c
index edc910b..b1cc347 100644
--- a/drivers/thunderbolt/icm/icm_nhi.c
+++ b/drivers/thunderbolt/icm/icm_nhi.c
@@ -928,6 +928,7 @@ static irqreturn_t nhi_msi(int __always_unused irq, void 
*data)
 {
struct tbt_nhi_ctxt *nhi_ctxt = data;
u32 isr0, isr1, imr0, imr1;
+   int i;
 
/* clear on read */
isr0 = ioread32(nhi_ctxt->iobase + REG_RING_NOTIFY_BASE);
@@ -950,6 +951,20 @@ static irqreturn_t nhi_msi(int __always_unused irq, void 
*data)
 
spin_unlock(_ctxt->lock);
 
+   for (i = 0; i < nhi_ctxt->num_ports; ++i) {
+   struct net_device *net_dev =
+   nhi_ctxt->net_devices[i].net_dev;
+   if (net_dev) {
+   u8 path = PATH_FROM_PORT(nhi_ctxt->num_paths, i);
+
+   if (isr0 & REG_RING_INT_RX_PROCESSED(
+   path, nhi_ctxt->num_paths))
+   tbt_net_rx_msi(net_dev);
+   if (isr0 & REG_RING_INT_TX_PROCESSED(path))
+   tbt_net_tx_msi(net_dev);
+   }
+   }
+
if (isr0 & REG_RING_INT_RX_PROCESSED(TBT_ICM_RING_NUM,
 nhi_ctxt->num_paths))
schedule_work(_ctxt->icm_msgs_work);
diff --git a/drivers/thunderbolt/icm/net.c b/drivers/thunderbolt/icm/net.c
index beeafb3..cf985dd 100644
--- a/drivers/thunderbolt/icm/net.c
+++ b/drivers/thunderbolt/icm/net.c
@@ -124,6 +124,17 @@ struct approve_inter_domain_connection_cmd {
 
 };
 
+struct tbt_frame_header {
+   /* size of the data with the frame */
+   __le32 frame_size;
+   /* running index on the frames */
+   __le16 frame_index;
+   /* ID of the frame to match frames to specific packet */
+   __le16 frame_id;
+   /* how many frames assembles a full packet */
+   __le32 frame_count;
+};
+
 enum neg_event {
RECEIVE_LOGOUT = NUM_MEDIUM_STATUSES,
RECEIVE_LOGIN_RESPONSE,
@@ -131,15 +142,81 @@ enum neg_event {
NUM_NEG_EVENTS
 };
 
+enum frame_status {
+   GOOD_FRAME,
+   GOOD_AS_FIRST_FRAME,
+   GOOD_AS_FIRST_MULTICAST_FRAME,
+   FRAME_NOT_READY,
+   FRAME_ERROR,
+};
+
+enum packet_filter {
+   /* all multicast MAC addresses */
+   PACKET_TYPE_ALL_MULTICAST,
+   /* all types of MAC addresses: multicast, unicast and broadcast */
+   PACKET_TYPE_PROMISCUOUS,
+   /* all unicast MAC addresses */
+   PACKET_TYPE_UNICAST_PROMISCUOUS,
+};
+
 enum disconnect_path_stage {
STAGE_1 = BIT(0),
STAGE_2 = BIT(1)
 };
 
+struct tbt_net_stats {
+   u64 tx_packets;
+   u64 tx_bytes;
+   u64 tx_errors;
+   u64 rx_packets;
+   u64 rx_bytes;
+   u64 rx_length_errors;
+   u64 rx_over_errors;
+   u64 rx_crc_errors;
+   u64 rx_missed_errors;
+   u64 multicast;
+};
+
+static const char tbt_net_gstrings_stats[][ETH_GSTRING_LEN] = {
+   "tx_packets",
+   "tx_bytes",
+   "tx_errors",
+   "rx_packets",
+   "rx_bytes",
+   "rx_length_errors",
+   "rx_over_errors",
+   "rx_crc_errors",
+   "rx_missed_errors",
+

[PATCH v9 5/8] thunderbolt: Networking transmit and receive

[Amir Levy]

This patch provides the handling interface for sending and receiving
network packets between the hosts over the full communication route
(using the communication path established in the previous patch).

The Thunderbolt Network driver interfaces the Linux network stack
and the hardware controller configuration to handle packet transmissions:
  ++++
  |Host 1  ||Host 2  |
  ||||
  |   +---+||+---+   |
  |   |Network||||Network|   |
  |   |Stack  ||||Stack  |   |
  |   +---+||+---+   |
  |   ^||^   |
  |   ||||   |
  |   v||v   |
  | +---+  ||  +---+ |
  | |Thunderbolt|  ||  |Thunderbolt| |
  | |Networking |  ||  |Networking | |
  | |Driver |  ||  |Driver | |
  | +---+  ||  +---+ |
  |   ^||^   |
  |   ||||   |
  |   v||v   |
  | +---+  ||  +---+ |
  | |Thunderbolt|  ||  |Thunderbolt| |
  | |Controller |<-++->|Controller | |
  | +---+  ||  +---+ |
  ++++

Signed-off-by: Amir Levy 
---
 drivers/thunderbolt/icm/icm_nhi.c |   15 +
 drivers/thunderbolt/icm/net.c | 1471 +
 2 files changed, 1486 insertions(+)

diff --git a/drivers/thunderbolt/icm/icm_nhi.c 
b/drivers/thunderbolt/icm/icm_nhi.c
index edc910b..b1cc347 100644
--- a/drivers/thunderbolt/icm/icm_nhi.c
+++ b/drivers/thunderbolt/icm/icm_nhi.c
@@ -928,6 +928,7 @@ static irqreturn_t nhi_msi(int __always_unused irq, void 
*data)
 {
struct tbt_nhi_ctxt *nhi_ctxt = data;
u32 isr0, isr1, imr0, imr1;
+   int i;
 
/* clear on read */
isr0 = ioread32(nhi_ctxt->iobase + REG_RING_NOTIFY_BASE);
@@ -950,6 +951,20 @@ static irqreturn_t nhi_msi(int __always_unused irq, void 
*data)
 
spin_unlock(_ctxt->lock);
 
+   for (i = 0; i < nhi_ctxt->num_ports; ++i) {
+   struct net_device *net_dev =
+   nhi_ctxt->net_devices[i].net_dev;
+   if (net_dev) {
+   u8 path = PATH_FROM_PORT(nhi_ctxt->num_paths, i);
+
+   if (isr0 & REG_RING_INT_RX_PROCESSED(
+   path, nhi_ctxt->num_paths))
+   tbt_net_rx_msi(net_dev);
+   if (isr0 & REG_RING_INT_TX_PROCESSED(path))
+   tbt_net_tx_msi(net_dev);
+   }
+   }
+
if (isr0 & REG_RING_INT_RX_PROCESSED(TBT_ICM_RING_NUM,
 nhi_ctxt->num_paths))
schedule_work(_ctxt->icm_msgs_work);
diff --git a/drivers/thunderbolt/icm/net.c b/drivers/thunderbolt/icm/net.c
index beeafb3..cf985dd 100644
--- a/drivers/thunderbolt/icm/net.c
+++ b/drivers/thunderbolt/icm/net.c
@@ -124,6 +124,17 @@ struct approve_inter_domain_connection_cmd {
 
 };
 
+struct tbt_frame_header {
+   /* size of the data with the frame */
+   __le32 frame_size;
+   /* running index on the frames */
+   __le16 frame_index;
+   /* ID of the frame to match frames to specific packet */
+   __le16 frame_id;
+   /* how many frames assembles a full packet */
+   __le32 frame_count;
+};
+
 enum neg_event {
RECEIVE_LOGOUT = NUM_MEDIUM_STATUSES,
RECEIVE_LOGIN_RESPONSE,
@@ -131,15 +142,81 @@ enum neg_event {
NUM_NEG_EVENTS
 };
 
+enum frame_status {
+   GOOD_FRAME,
+   GOOD_AS_FIRST_FRAME,
+   GOOD_AS_FIRST_MULTICAST_FRAME,
+   FRAME_NOT_READY,
+   FRAME_ERROR,
+};
+
+enum packet_filter {
+   /* all multicast MAC addresses */
+   PACKET_TYPE_ALL_MULTICAST,
+   /* all types of MAC addresses: multicast, unicast and broadcast */
+   PACKET_TYPE_PROMISCUOUS,
+   /* all unicast MAC addresses */
+   PACKET_TYPE_UNICAST_PROMISCUOUS,
+};
+
 enum disconnect_path_stage {
STAGE_1 = BIT(0),
STAGE_2 = BIT(1)
 };
 
+struct tbt_net_stats {
+   u64 tx_packets;
+   u64 tx_bytes;
+   u64 tx_errors;
+   u64 rx_packets;
+   u64 rx_bytes;
+   u64 rx_length_errors;
+   u64 rx_over_errors;
+   u64 rx_crc_errors;
+   u64 rx_missed_errors;
+   u64 multicast;
+};
+
+static const char tbt_net_gstrings_stats[][ETH_GSTRING_LEN] = {
+   "tx_packets",
+   "tx_bytes",
+   "tx_errors",
+   "rx_packets",
+   "rx_bytes",
+   "rx_length_errors",
+   "rx_over_errors",
+   "rx_crc_errors",
+   "rx_missed_errors",
+   "multicast",
+};
+

[PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

[Amir Levy]

This driver enables Thunderbolt Networking on non-Apple platforms
running Linux.

Thunderbolt Networking provides peer-to-peer connections to transfer
files between computers, perform PC migrations, and/or set up small
workgroups with shared storage.

This is a virtual connection that emulates an Ethernet adapter that
enables Ethernet networking with the benefit of Thunderbolt superfast
medium capability.

Thunderbolt Networking enables two hosts and several devices that
have a Thunderbolt controller to be connected together in a linear
(Daisy chain) series from a single port.

Thunderbolt Networking for Linux is compatible with Thunderbolt
Networking on systems running macOS or Windows and also supports
Thunderbolt generation 2 and 3 controllers.

Note that all pre-existing Thunderbolt generation 3 features, such as
USB, Display and other Thunderbolt device connectivity will continue
to function exactly as they did prior to enabling Thunderbolt Networking.

Code and Software Specifications:
This kernel code creates a virtual ethernet device for computer to
computer communication over a Thunderbolt cable.
The new driver is a separate driver to the existing Thunderbolt driver.
It is designed to work on systems running Linux that
interface with Intel Connection Manager (ICM) firmware based
Thunderbolt controllers that support Thunderbolt Networking.
The kernel code operates in coordination with the Thunderbolt user-
space daemon to implement full Thunderbolt networking functionality.

Hardware Specifications:
Thunderbolt Hardware specs have not yet been published but are used
where necessary for register definitions. 

Acked-by: Andreas Noever 
Tested-by: Mario Limonciello 

Changes since v8:
 - Added support for more Thunderbolt device IDs

These patches were pushed to GitHub where they can be reviewed more
comfortably with green/red highlighting:
https://github.com/01org/thunderbolt-software-kernel-tree

Daemon code:
https://github.com/01org/thunderbolt-software-daemon

For reference, here's a link to version 8:
[v8]:   https://lkml.org/lkml/2016/9/28/378

Amir Levy (8):
  thunderbolt: Macro rename
  thunderbolt: Updating the register definitions
  thunderbolt: Communication with the ICM (firmware)
  thunderbolt: Networking state machine
  thunderbolt: Networking transmit and receive
  thunderbolt: Kconfig for Thunderbolt Networking
  thunderbolt: Networking doc
  thunderbolt: Adding maintainer entry

 Documentation/00-INDEX   |2 +
 Documentation/thunderbolt/networking.txt |  132 ++
 MAINTAINERS  |8 +-
 drivers/thunderbolt/Kconfig  |   27 +-
 drivers/thunderbolt/Makefile |3 +-
 drivers/thunderbolt/icm/Makefile |2 +
 drivers/thunderbolt/icm/icm_nhi.c| 1520 
 drivers/thunderbolt/icm/icm_nhi.h|   85 ++
 drivers/thunderbolt/icm/net.c| 2254 ++
 drivers/thunderbolt/icm/net.h|  287 
 drivers/thunderbolt/nhi_regs.h   |  115 +-
 11 files changed, 4426 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/thunderbolt/networking.txt
 create mode 100644 drivers/thunderbolt/icm/Makefile
 create mode 100644 drivers/thunderbolt/icm/icm_nhi.c
 create mode 100644 drivers/thunderbolt/icm/icm_nhi.h
 create mode 100644 drivers/thunderbolt/icm/net.c
 create mode 100644 drivers/thunderbolt/icm/net.h

-- 
2.7.4

[PATCH v9 8/8] thunderbolt: Adding maintainer entry

[Amir Levy]

Add Amir Levy as maintainer for Thunderbolt(TM) ICM driver

Signed-off-by: Amir Levy 
---
 MAINTAINERS | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 411e3b8..87763c44 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10652,7 +10652,13 @@ F: include/uapi/linux/stm.h
 THUNDERBOLT DRIVER
 M: Andreas Noever 
 S: Maintained
-F: drivers/thunderbolt/
+F: drivers/thunderbolt/*
+
+THUNDERBOLT ICM DRIVER
+M: Amir Levy 
+S: Maintained
+F: drivers/thunderbolt/icm/
+F: Documentation/thunderbolt/networking.txt
 
 TI BQ27XXX POWER SUPPLY DRIVER
 R: Andrew F. Davis 
-- 
2.7.4

[PATCH v9 6/8] thunderbolt: Kconfig for Thunderbolt Networking

[Amir Levy]

Update to the Kconfig Thunderbolt description to add
Thunderbolt networking as an option.
The menu item "Thunderbolt support" now offers:
"Apple Hardware Support" (existing)
and/or
"Thunderbolt Networking" (new)

You can choose the driver for your platform or build both drivers -
each driver will detect if it can run on the specific platform.
If the Thunderbolt Networking option is chosen, Thunderbolt Networking
will be enabled between Linux non-Apple systems, macOS and
Windows based systems.
Thunderbolt Networking will not affect any other Thunderbolt feature that
was previous available to Linux users on either Apple or
non-Apple platforms.

Signed-off-by: Amir Levy 
---
 drivers/thunderbolt/Kconfig  | 27 +++
 drivers/thunderbolt/Makefile |  3 ++-
 2 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig
index c121acc..376e5bb 100644
--- a/drivers/thunderbolt/Kconfig
+++ b/drivers/thunderbolt/Kconfig
@@ -1,13 +1,32 @@
-menuconfig THUNDERBOLT
-   tristate "Thunderbolt support for Apple devices"
+config THUNDERBOLT
+   tristate "Thunderbolt support"
depends on PCI
select CRC32
help
- Cactus Ridge Thunderbolt Controller driver
+ Thunderbolt Controller driver
+
+if THUNDERBOLT
+
+config THUNDERBOLT_APPLE
+   tristate "Apple hardware support"
+   help
  This driver is required if you want to hotplug Thunderbolt devices on
  Apple hardware.
 
  Device chaining is currently not supported.
 
- To compile this driver a module, choose M here. The module will be
+ To compile this driver as a module, choose M here. The module will be
  called thunderbolt.
+
+config THUNDERBOLT_ICM
+   tristate "Thunderbolt Networking"
+   help
+ This driver is required if you want Thunderbolt Networking on
+ non-Apple hardware.
+ It creates a virtual Ethernet device that enables computer to
+ computer communication over a Thunderbolt cable.
+
+ To compile this driver as a module, choose M here. The module will be
+ called thunderbolt_icm.
+
+endif
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index 5d1053c..b6aa6a3 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,4 @@
-obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
+obj-${CONFIG_THUNDERBOLT_APPLE} := thunderbolt.o
 thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o tunnel_pci.o 
eeprom.o
 
+obj-${CONFIG_THUNDERBOLT_ICM} += icm/
-- 
2.7.4

[PATCH v9 8/8] thunderbolt: Adding maintainer entry

[Amir Levy]

Add Amir Levy as maintainer for Thunderbolt(TM) ICM driver

Signed-off-by: Amir Levy 
---
 MAINTAINERS | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 411e3b8..87763c44 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10652,7 +10652,13 @@ F: include/uapi/linux/stm.h
 THUNDERBOLT DRIVER
 M: Andreas Noever 
 S: Maintained
-F: drivers/thunderbolt/
+F: drivers/thunderbolt/*
+
+THUNDERBOLT ICM DRIVER
+M: Amir Levy 
+S: Maintained
+F: drivers/thunderbolt/icm/
+F: Documentation/thunderbolt/networking.txt
 
 TI BQ27XXX POWER SUPPLY DRIVER
 R: Andrew F. Davis 
-- 
2.7.4

[PATCH v9 6/8] thunderbolt: Kconfig for Thunderbolt Networking

[Amir Levy]

Update to the Kconfig Thunderbolt description to add
Thunderbolt networking as an option.
The menu item "Thunderbolt support" now offers:
"Apple Hardware Support" (existing)
and/or
"Thunderbolt Networking" (new)

You can choose the driver for your platform or build both drivers -
each driver will detect if it can run on the specific platform.
If the Thunderbolt Networking option is chosen, Thunderbolt Networking
will be enabled between Linux non-Apple systems, macOS and
Windows based systems.
Thunderbolt Networking will not affect any other Thunderbolt feature that
was previous available to Linux users on either Apple or
non-Apple platforms.

Signed-off-by: Amir Levy 
---
 drivers/thunderbolt/Kconfig  | 27 +++
 drivers/thunderbolt/Makefile |  3 ++-
 2 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig
index c121acc..376e5bb 100644
--- a/drivers/thunderbolt/Kconfig
+++ b/drivers/thunderbolt/Kconfig
@@ -1,13 +1,32 @@
-menuconfig THUNDERBOLT
-   tristate "Thunderbolt support for Apple devices"
+config THUNDERBOLT
+   tristate "Thunderbolt support"
depends on PCI
select CRC32
help
- Cactus Ridge Thunderbolt Controller driver
+ Thunderbolt Controller driver
+
+if THUNDERBOLT
+
+config THUNDERBOLT_APPLE
+   tristate "Apple hardware support"
+   help
  This driver is required if you want to hotplug Thunderbolt devices on
  Apple hardware.
 
  Device chaining is currently not supported.
 
- To compile this driver a module, choose M here. The module will be
+ To compile this driver as a module, choose M here. The module will be
  called thunderbolt.
+
+config THUNDERBOLT_ICM
+   tristate "Thunderbolt Networking"
+   help
+ This driver is required if you want Thunderbolt Networking on
+ non-Apple hardware.
+ It creates a virtual Ethernet device that enables computer to
+ computer communication over a Thunderbolt cable.
+
+ To compile this driver as a module, choose M here. The module will be
+ called thunderbolt_icm.
+
+endif
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index 5d1053c..b6aa6a3 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,4 @@
-obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
+obj-${CONFIG_THUNDERBOLT_APPLE} := thunderbolt.o
 thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o tunnel_pci.o 
eeprom.o
 
+obj-${CONFIG_THUNDERBOLT_ICM} += icm/
-- 
2.7.4

[PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

[Amir Levy]

This driver enables Thunderbolt Networking on non-Apple platforms
running Linux.

Thunderbolt Networking provides peer-to-peer connections to transfer
files between computers, perform PC migrations, and/or set up small
workgroups with shared storage.

This is a virtual connection that emulates an Ethernet adapter that
enables Ethernet networking with the benefit of Thunderbolt superfast
medium capability.

Thunderbolt Networking enables two hosts and several devices that
have a Thunderbolt controller to be connected together in a linear
(Daisy chain) series from a single port.

Thunderbolt Networking for Linux is compatible with Thunderbolt
Networking on systems running macOS or Windows and also supports
Thunderbolt generation 2 and 3 controllers.

Note that all pre-existing Thunderbolt generation 3 features, such as
USB, Display and other Thunderbolt device connectivity will continue
to function exactly as they did prior to enabling Thunderbolt Networking.

Code and Software Specifications:
This kernel code creates a virtual ethernet device for computer to
computer communication over a Thunderbolt cable.
The new driver is a separate driver to the existing Thunderbolt driver.
It is designed to work on systems running Linux that
interface with Intel Connection Manager (ICM) firmware based
Thunderbolt controllers that support Thunderbolt Networking.
The kernel code operates in coordination with the Thunderbolt user-
space daemon to implement full Thunderbolt networking functionality.

Hardware Specifications:
Thunderbolt Hardware specs have not yet been published but are used
where necessary for register definitions. 

Acked-by: Andreas Noever 
Tested-by: Mario Limonciello 

Changes since v8:
 - Added support for more Thunderbolt device IDs

These patches were pushed to GitHub where they can be reviewed more
comfortably with green/red highlighting:
https://github.com/01org/thunderbolt-software-kernel-tree

Daemon code:
https://github.com/01org/thunderbolt-software-daemon

For reference, here's a link to version 8:
[v8]:   https://lkml.org/lkml/2016/9/28/378

Amir Levy (8):
  thunderbolt: Macro rename
  thunderbolt: Updating the register definitions
  thunderbolt: Communication with the ICM (firmware)
  thunderbolt: Networking state machine
  thunderbolt: Networking transmit and receive
  thunderbolt: Kconfig for Thunderbolt Networking
  thunderbolt: Networking doc
  thunderbolt: Adding maintainer entry

 Documentation/00-INDEX   |2 +
 Documentation/thunderbolt/networking.txt |  132 ++
 MAINTAINERS  |8 +-
 drivers/thunderbolt/Kconfig  |   27 +-
 drivers/thunderbolt/Makefile |3 +-
 drivers/thunderbolt/icm/Makefile |2 +
 drivers/thunderbolt/icm/icm_nhi.c| 1520 
 drivers/thunderbolt/icm/icm_nhi.h|   85 ++
 drivers/thunderbolt/icm/net.c| 2254 ++
 drivers/thunderbolt/icm/net.h|  287 
 drivers/thunderbolt/nhi_regs.h   |  115 +-
 11 files changed, 4426 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/thunderbolt/networking.txt
 create mode 100644 drivers/thunderbolt/icm/Makefile
 create mode 100644 drivers/thunderbolt/icm/icm_nhi.c
 create mode 100644 drivers/thunderbolt/icm/icm_nhi.h
 create mode 100644 drivers/thunderbolt/icm/net.c
 create mode 100644 drivers/thunderbolt/icm/net.h

-- 
2.7.4

[PATCH v9 2/8] thunderbolt: Updating the register definitions

[Amir Levy]

Adding more Thunderbolt(TM) register definitions
and some helper macros.

Signed-off-by: Amir Levy 
---
 drivers/thunderbolt/nhi_regs.h | 109 +
 1 file changed, 109 insertions(+)

diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
index 75cf069..b8e961f 100644
--- a/drivers/thunderbolt/nhi_regs.h
+++ b/drivers/thunderbolt/nhi_regs.h
@@ -9,6 +9,11 @@
 
 #include 
 
+#define NHI_MMIO_BAR 0
+
+#define TBT_RING_MIN_NUM_BUFFERS   2
+#define TBT_RING_MAX_FRAME_SIZE(4 * 1024)
+
 enum ring_flags {
RING_FLAG_ISOCH_ENABLE = 1 << 27, /* TX only? */
RING_FLAG_E2E_FLOW_CONTROL = 1 << 28,
@@ -39,6 +44,33 @@ struct ring_desc {
u32 time; /* write zero */
 } __packed;
 
+/**
+ * struct tbt_buf_desc - TX/RX ring buffer descriptor.
+ * This is same as struct ring_desc, but without the use of bitfields and
+ * with explicit endianity.
+ */
+struct tbt_buf_desc {
+   __le64 phys;
+   __le32 attributes;
+   __le32 time;
+};
+
+#define DESC_ATTR_LEN_SHIFT0
+#define DESC_ATTR_LEN_MASK GENMASK(11, DESC_ATTR_LEN_SHIFT)
+#define DESC_ATTR_EOF_SHIFT12
+#define DESC_ATTR_EOF_MASK GENMASK(15, DESC_ATTR_EOF_SHIFT)
+#define DESC_ATTR_SOF_SHIFT16
+#define DESC_ATTR_SOF_MASK GENMASK(19, DESC_ATTR_SOF_SHIFT)
+#define DESC_ATTR_TX_ISOCH_DMA_EN  BIT(20) /* TX */
+#define DESC_ATTR_RX_CRC_ERR   BIT(20) /* RX after use */
+#define DESC_ATTR_DESC_DONEBIT(21)
+#define DESC_ATTR_REQ_STS  BIT(22) /* TX and RX before use */
+#define DESC_ATTR_RX_BUF_OVRN_ERR  BIT(22) /* RX after use */
+#define DESC_ATTR_INT_EN   BIT(23)
+#define DESC_ATTR_OFFSET_SHIFT 24
+#define DESC_ATTR_OFFSET_MASK  GENMASK(31, DESC_ATTR_OFFSET_SHIFT)
+
+
 /* NHI registers in bar 0 */
 
 /*
@@ -60,6 +92,30 @@ struct ring_desc {
  */
 #define REG_RX_RING_BASE   0x08000
 
+#define REG_RING_STEP  16
+#define REG_RING_PHYS_LO_OFFSET0
+#define REG_RING_PHYS_HI_OFFSET4
+#define REG_RING_CONS_PROD_OFFSET  8   /* cons - RO, prod - RW */
+#define REG_RING_CONS_SHIFT0
+#define REG_RING_CONS_MASK GENMASK(15, REG_RING_CONS_SHIFT)
+#define REG_RING_PROD_SHIFT16
+#define REG_RING_PROD_MASK GENMASK(31, REG_RING_PROD_SHIFT)
+#define REG_RING_SIZE_OFFSET   12
+#define REG_RING_SIZE_SHIFT0
+#define REG_RING_SIZE_MASK GENMASK(15, REG_RING_SIZE_SHIFT)
+#define REG_RING_BUF_SIZE_SHIFT16
+#define REG_RING_BUF_SIZE_MASK GENMASK(27, REG_RING_BUF_SIZE_SHIFT)
+
+#define TBT_RING_CONS_PROD_REG(iobase, ringbase, ringnumber) \
+ ((iobase) + (ringbase) + \
+ ((ringnumber) * REG_RING_STEP) + \
+ REG_RING_CONS_PROD_OFFSET)
+
+#define TBT_REG_RING_PROD_EXTRACT(val) (((val) & REG_RING_PROD_MASK) >> \
+  REG_RING_PROD_SHIFT)
+
+#define TBT_REG_RING_CONS_EXTRACT(val) (((val) & REG_RING_CONS_MASK) >> \
+  REG_RING_CONS_SHIFT)
 /*
  * 32 bytes per entry, one entry for every hop (REG_HOP_COUNT)
  * 00: enum_ring_flags
@@ -77,6 +133,19 @@ struct ring_desc {
  * ..: unknown
  */
 #define REG_RX_OPTIONS_BASE0x29800
+#define REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT12
+#define REG_RX_OPTS_TX_E2E_HOP_ID_MASK \
+   GENMASK(22, REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT)
+#define REG_RX_OPTS_MASK_OFFSET4
+#define REG_RX_OPTS_MASK_EOF_SHIFT 0
+#define REG_RX_OPTS_MASK_EOF_MASK  GENMASK(15, REG_RX_OPTS_MASK_EOF_SHIFT)
+#define REG_RX_OPTS_MASK_SOF_SHIFT 16
+#define REG_RX_OPTS_MASK_SOF_MASK  GENMASK(31, REG_RX_OPTS_MASK_SOF_SHIFT)
+
+#define REG_OPTS_STEP  32
+#define REG_OPTS_E2E_ENBIT(28)
+#define REG_OPTS_RAW   BIT(30)
+#define REG_OPTS_VALID BIT(31)
 
 /*
  * three bitfields: tx, rx, rx overflow
@@ -86,6 +155,7 @@ struct ring_desc {
  */
 #define REG_RING_NOTIFY_BASE   0x37800
 #define RING_NOTIFY_REG_COUNT(nhi) ((31 + 3 * nhi->hop_count) / 32)
+#define REG_RING_NOTIFY_STEP   4
 
 /*
  * two bitfields: rx, tx
@@ -94,8 +164,47 @@ struct ring_desc {
  */
 #define REG_RING_INTERRUPT_BASE0x38200
 #define RING_INTERRUPT_REG_COUNT(nhi) ((31 + 2 * nhi->hop_count) / 32)
+#define REG_RING_INT_TX_PROCESSED(ring_num)BIT(ring_num)
+#define REG_RING_INT_RX_PROCESSED(ring_num, num_paths) BIT((ring_num) + \
+   (num_paths))
+#define RING_INT_DISABLE(base, val) iowrite32( \
+   ioread32((base) + REG_RING_INTERRUPT_BASE) & ~(val), \
+   (base) + REG_RING_INTERRUPT_BASE)
+#define RING_INT_ENABLE(base, val) 

[PATCH v9 3/8] thunderbolt: Communication with the ICM (firmware)

[Amir Levy]

This patch provides the communication protocol between the
Intel Connection Manager(ICM) firmware that is operational in the
Thunderbolt controller in non-Apple hardware.
The ICM firmware-based controller is used for establishing and maintaining
the Thunderbolt Networking connection - we need to be able to communicate
with it.

Signed-off-by: Amir Levy 
---
 drivers/thunderbolt/icm/Makefile  |2 +
 drivers/thunderbolt/icm/icm_nhi.c | 1257 +
 drivers/thunderbolt/icm/icm_nhi.h |   85 +++
 drivers/thunderbolt/icm/net.h |  217 +++
 4 files changed, 1561 insertions(+)
 create mode 100644 drivers/thunderbolt/icm/Makefile
 create mode 100644 drivers/thunderbolt/icm/icm_nhi.c
 create mode 100644 drivers/thunderbolt/icm/icm_nhi.h
 create mode 100644 drivers/thunderbolt/icm/net.h

diff --git a/drivers/thunderbolt/icm/Makefile b/drivers/thunderbolt/icm/Makefile
new file mode 100644
index 000..f0d0fbb
--- /dev/null
+++ b/drivers/thunderbolt/icm/Makefile
@@ -0,0 +1,2 @@
+obj-${CONFIG_THUNDERBOLT_ICM} += thunderbolt-icm.o
+thunderbolt-icm-objs := icm_nhi.o
diff --git a/drivers/thunderbolt/icm/icm_nhi.c 
b/drivers/thunderbolt/icm/icm_nhi.c
new file mode 100644
index 000..c843ce8
--- /dev/null
+++ b/drivers/thunderbolt/icm/icm_nhi.c
@@ -0,0 +1,1257 @@
+/***
+ *
+ * Intel Thunderbolt(TM) driver
+ * Copyright(c) 2014 - 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#include 
+#include 
+#include 
+#include 
+#include "icm_nhi.h"
+#include "net.h"
+
+#define NHI_GENL_VERSION 1
+#define NHI_GENL_NAME "thunderbolt"
+
+#define DEVICE_DATA(num_ports, dma_port, nvm_ver_offset, nvm_auth_on_boot,\
+   support_full_e2e) \
+   ((num_ports) | ((dma_port) << 4) | ((nvm_ver_offset) << 10) | \
+((nvm_auth_on_boot) << 22) | ((support_full_e2e) << 23))
+#define DEVICE_DATA_NUM_PORTS(device_data) ((device_data) & 0xf)
+#define DEVICE_DATA_DMA_PORT(device_data) (((device_data) >> 4) & 0x3f)
+#define DEVICE_DATA_NVM_VER_OFFSET(device_data) (((device_data) >> 10) & 0xfff)
+#define DEVICE_DATA_NVM_AUTH_ON_BOOT(device_data) (((device_data) >> 22) & 0x1)
+#define DEVICE_DATA_SUPPORT_FULL_E2E(device_data) (((device_data) >> 23) & 0x1)
+
+#define USEC_TO_256_NSECS(usec) DIV_ROUND_UP((usec) * NSEC_PER_USEC, 256)
+
+/* NHI genetlink commands */
+enum {
+   NHI_CMD_UNSPEC,
+   NHI_CMD_SUBSCRIBE,
+   NHI_CMD_UNSUBSCRIBE,
+   NHI_CMD_QUERY_INFORMATION,
+   NHI_CMD_MSG_TO_ICM,
+   NHI_CMD_MSG_FROM_ICM,
+   NHI_CMD_MAILBOX,
+   NHI_CMD_APPROVE_TBT_NETWORKING,
+   NHI_CMD_ICM_IN_SAFE_MODE,
+   __NHI_CMD_MAX,
+};
+#define NHI_CMD_MAX (__NHI_CMD_MAX - 1)
+
+/* NHI genetlink policy */
+static const struct nla_policy nhi_genl_policy[NHI_ATTR_MAX + 1] = {
+   [NHI_ATTR_DRV_VERSION]  = { .type = NLA_NUL_STRING, },
+   [NHI_ATTR_NVM_VER_OFFSET]   = { .type = NLA_U16, },
+   [NHI_ATTR_NUM_PORTS]= { .type = NLA_U8, },
+   [NHI_ATTR_DMA_PORT] = { .type = NLA_U8, },
+   [NHI_ATTR_SUPPORT_FULL_E2E] = { .type = NLA_FLAG, },
+   [NHI_ATTR_MAILBOX_CMD]  = { .type = NLA_U32, },
+   [NHI_ATTR_PDF]  = { .type = NLA_U32, },
+   [NHI_ATTR_MSG_TO_ICM]   = { .type = NLA_BINARY,
+   .len = TBT_ICM_RING_MAX_FRAME_SIZE },
+   [NHI_ATTR_MSG_FROM_ICM] = { .type = NLA_BINARY,
+   .len = TBT_ICM_RING_MAX_FRAME_SIZE },
+};
+
+/* NHI genetlink family */
+static struct genl_family nhi_genl_family = {
+   .id = GENL_ID_GENERATE,
+   .hdrsize= FIELD_SIZEOF(struct tbt_nhi_ctxt, id),
+   .name   = NHI_GENL_NAME,
+   .version= NHI_GENL_VERSION,
+   .maxattr= NHI_ATTR_MAX,
+};
+
+static LIST_HEAD(controllers_list);
+static DEFINE_MUTEX(controllers_list_mutex);
+static atomic_t subscribers = ATOMIC_INIT(0);
+/*
+ * Some of the received generic netlink messages are replied in a different
+ * context. The reply has to include the netlink portid of sender, therefore
+ * saving it in global variable (current assuption is one sender).
+ */
+static u32 portid;
+
+static bool nhi_nvm_authenticated(struct tbt_nhi_ctxt *nhi_ctxt)
+{
+   enum icm_operation_mode op_mode;
+   u32 *msg_head, port_id, reg;
+   

[PATCH v9 2/8] thunderbolt: Updating the register definitions

[Amir Levy]

Adding more Thunderbolt(TM) register definitions
and some helper macros.

Signed-off-by: Amir Levy 
---
 drivers/thunderbolt/nhi_regs.h | 109 +
 1 file changed, 109 insertions(+)

diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
index 75cf069..b8e961f 100644
--- a/drivers/thunderbolt/nhi_regs.h
+++ b/drivers/thunderbolt/nhi_regs.h
@@ -9,6 +9,11 @@
 
 #include 
 
+#define NHI_MMIO_BAR 0
+
+#define TBT_RING_MIN_NUM_BUFFERS   2
+#define TBT_RING_MAX_FRAME_SIZE(4 * 1024)
+
 enum ring_flags {
RING_FLAG_ISOCH_ENABLE = 1 << 27, /* TX only? */
RING_FLAG_E2E_FLOW_CONTROL = 1 << 28,
@@ -39,6 +44,33 @@ struct ring_desc {
u32 time; /* write zero */
 } __packed;
 
+/**
+ * struct tbt_buf_desc - TX/RX ring buffer descriptor.
+ * This is same as struct ring_desc, but without the use of bitfields and
+ * with explicit endianity.
+ */
+struct tbt_buf_desc {
+   __le64 phys;
+   __le32 attributes;
+   __le32 time;
+};
+
+#define DESC_ATTR_LEN_SHIFT0
+#define DESC_ATTR_LEN_MASK GENMASK(11, DESC_ATTR_LEN_SHIFT)
+#define DESC_ATTR_EOF_SHIFT12
+#define DESC_ATTR_EOF_MASK GENMASK(15, DESC_ATTR_EOF_SHIFT)
+#define DESC_ATTR_SOF_SHIFT16
+#define DESC_ATTR_SOF_MASK GENMASK(19, DESC_ATTR_SOF_SHIFT)
+#define DESC_ATTR_TX_ISOCH_DMA_EN  BIT(20) /* TX */
+#define DESC_ATTR_RX_CRC_ERR   BIT(20) /* RX after use */
+#define DESC_ATTR_DESC_DONEBIT(21)
+#define DESC_ATTR_REQ_STS  BIT(22) /* TX and RX before use */
+#define DESC_ATTR_RX_BUF_OVRN_ERR  BIT(22) /* RX after use */
+#define DESC_ATTR_INT_EN   BIT(23)
+#define DESC_ATTR_OFFSET_SHIFT 24
+#define DESC_ATTR_OFFSET_MASK  GENMASK(31, DESC_ATTR_OFFSET_SHIFT)
+
+
 /* NHI registers in bar 0 */
 
 /*
@@ -60,6 +92,30 @@ struct ring_desc {
  */
 #define REG_RX_RING_BASE   0x08000
 
+#define REG_RING_STEP  16
+#define REG_RING_PHYS_LO_OFFSET0
+#define REG_RING_PHYS_HI_OFFSET4
+#define REG_RING_CONS_PROD_OFFSET  8   /* cons - RO, prod - RW */
+#define REG_RING_CONS_SHIFT0
+#define REG_RING_CONS_MASK GENMASK(15, REG_RING_CONS_SHIFT)
+#define REG_RING_PROD_SHIFT16
+#define REG_RING_PROD_MASK GENMASK(31, REG_RING_PROD_SHIFT)
+#define REG_RING_SIZE_OFFSET   12
+#define REG_RING_SIZE_SHIFT0
+#define REG_RING_SIZE_MASK GENMASK(15, REG_RING_SIZE_SHIFT)
+#define REG_RING_BUF_SIZE_SHIFT16
+#define REG_RING_BUF_SIZE_MASK GENMASK(27, REG_RING_BUF_SIZE_SHIFT)
+
+#define TBT_RING_CONS_PROD_REG(iobase, ringbase, ringnumber) \
+ ((iobase) + (ringbase) + \
+ ((ringnumber) * REG_RING_STEP) + \
+ REG_RING_CONS_PROD_OFFSET)
+
+#define TBT_REG_RING_PROD_EXTRACT(val) (((val) & REG_RING_PROD_MASK) >> \
+  REG_RING_PROD_SHIFT)
+
+#define TBT_REG_RING_CONS_EXTRACT(val) (((val) & REG_RING_CONS_MASK) >> \
+  REG_RING_CONS_SHIFT)
 /*
  * 32 bytes per entry, one entry for every hop (REG_HOP_COUNT)
  * 00: enum_ring_flags
@@ -77,6 +133,19 @@ struct ring_desc {
  * ..: unknown
  */
 #define REG_RX_OPTIONS_BASE0x29800
+#define REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT12
+#define REG_RX_OPTS_TX_E2E_HOP_ID_MASK \
+   GENMASK(22, REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT)
+#define REG_RX_OPTS_MASK_OFFSET4
+#define REG_RX_OPTS_MASK_EOF_SHIFT 0
+#define REG_RX_OPTS_MASK_EOF_MASK  GENMASK(15, REG_RX_OPTS_MASK_EOF_SHIFT)
+#define REG_RX_OPTS_MASK_SOF_SHIFT 16
+#define REG_RX_OPTS_MASK_SOF_MASK  GENMASK(31, REG_RX_OPTS_MASK_SOF_SHIFT)
+
+#define REG_OPTS_STEP  32
+#define REG_OPTS_E2E_ENBIT(28)
+#define REG_OPTS_RAW   BIT(30)
+#define REG_OPTS_VALID BIT(31)
 
 /*
  * three bitfields: tx, rx, rx overflow
@@ -86,6 +155,7 @@ struct ring_desc {
  */
 #define REG_RING_NOTIFY_BASE   0x37800
 #define RING_NOTIFY_REG_COUNT(nhi) ((31 + 3 * nhi->hop_count) / 32)
+#define REG_RING_NOTIFY_STEP   4
 
 /*
  * two bitfields: rx, tx
@@ -94,8 +164,47 @@ struct ring_desc {
  */
 #define REG_RING_INTERRUPT_BASE0x38200
 #define RING_INTERRUPT_REG_COUNT(nhi) ((31 + 2 * nhi->hop_count) / 32)
+#define REG_RING_INT_TX_PROCESSED(ring_num)BIT(ring_num)
+#define REG_RING_INT_RX_PROCESSED(ring_num, num_paths) BIT((ring_num) + \
+   (num_paths))
+#define RING_INT_DISABLE(base, val) iowrite32( \
+   ioread32((base) + REG_RING_INTERRUPT_BASE) & ~(val), \
+   (base) + REG_RING_INTERRUPT_BASE)
+#define RING_INT_ENABLE(base, val) iowrite32( \
+  

[PATCH v9 3/8] thunderbolt: Communication with the ICM (firmware)

[Amir Levy]

This patch provides the communication protocol between the
Intel Connection Manager(ICM) firmware that is operational in the
Thunderbolt controller in non-Apple hardware.
The ICM firmware-based controller is used for establishing and maintaining
the Thunderbolt Networking connection - we need to be able to communicate
with it.

Signed-off-by: Amir Levy 
---
 drivers/thunderbolt/icm/Makefile  |2 +
 drivers/thunderbolt/icm/icm_nhi.c | 1257 +
 drivers/thunderbolt/icm/icm_nhi.h |   85 +++
 drivers/thunderbolt/icm/net.h |  217 +++
 4 files changed, 1561 insertions(+)
 create mode 100644 drivers/thunderbolt/icm/Makefile
 create mode 100644 drivers/thunderbolt/icm/icm_nhi.c
 create mode 100644 drivers/thunderbolt/icm/icm_nhi.h
 create mode 100644 drivers/thunderbolt/icm/net.h

diff --git a/drivers/thunderbolt/icm/Makefile b/drivers/thunderbolt/icm/Makefile
new file mode 100644
index 000..f0d0fbb
--- /dev/null
+++ b/drivers/thunderbolt/icm/Makefile
@@ -0,0 +1,2 @@
+obj-${CONFIG_THUNDERBOLT_ICM} += thunderbolt-icm.o
+thunderbolt-icm-objs := icm_nhi.o
diff --git a/drivers/thunderbolt/icm/icm_nhi.c 
b/drivers/thunderbolt/icm/icm_nhi.c
new file mode 100644
index 000..c843ce8
--- /dev/null
+++ b/drivers/thunderbolt/icm/icm_nhi.c
@@ -0,0 +1,1257 @@
+/***
+ *
+ * Intel Thunderbolt(TM) driver
+ * Copyright(c) 2014 - 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#include 
+#include 
+#include 
+#include 
+#include "icm_nhi.h"
+#include "net.h"
+
+#define NHI_GENL_VERSION 1
+#define NHI_GENL_NAME "thunderbolt"
+
+#define DEVICE_DATA(num_ports, dma_port, nvm_ver_offset, nvm_auth_on_boot,\
+   support_full_e2e) \
+   ((num_ports) | ((dma_port) << 4) | ((nvm_ver_offset) << 10) | \
+((nvm_auth_on_boot) << 22) | ((support_full_e2e) << 23))
+#define DEVICE_DATA_NUM_PORTS(device_data) ((device_data) & 0xf)
+#define DEVICE_DATA_DMA_PORT(device_data) (((device_data) >> 4) & 0x3f)
+#define DEVICE_DATA_NVM_VER_OFFSET(device_data) (((device_data) >> 10) & 0xfff)
+#define DEVICE_DATA_NVM_AUTH_ON_BOOT(device_data) (((device_data) >> 22) & 0x1)
+#define DEVICE_DATA_SUPPORT_FULL_E2E(device_data) (((device_data) >> 23) & 0x1)
+
+#define USEC_TO_256_NSECS(usec) DIV_ROUND_UP((usec) * NSEC_PER_USEC, 256)
+
+/* NHI genetlink commands */
+enum {
+   NHI_CMD_UNSPEC,
+   NHI_CMD_SUBSCRIBE,
+   NHI_CMD_UNSUBSCRIBE,
+   NHI_CMD_QUERY_INFORMATION,
+   NHI_CMD_MSG_TO_ICM,
+   NHI_CMD_MSG_FROM_ICM,
+   NHI_CMD_MAILBOX,
+   NHI_CMD_APPROVE_TBT_NETWORKING,
+   NHI_CMD_ICM_IN_SAFE_MODE,
+   __NHI_CMD_MAX,
+};
+#define NHI_CMD_MAX (__NHI_CMD_MAX - 1)
+
+/* NHI genetlink policy */
+static const struct nla_policy nhi_genl_policy[NHI_ATTR_MAX + 1] = {
+   [NHI_ATTR_DRV_VERSION]  = { .type = NLA_NUL_STRING, },
+   [NHI_ATTR_NVM_VER_OFFSET]   = { .type = NLA_U16, },
+   [NHI_ATTR_NUM_PORTS]= { .type = NLA_U8, },
+   [NHI_ATTR_DMA_PORT] = { .type = NLA_U8, },
+   [NHI_ATTR_SUPPORT_FULL_E2E] = { .type = NLA_FLAG, },
+   [NHI_ATTR_MAILBOX_CMD]  = { .type = NLA_U32, },
+   [NHI_ATTR_PDF]  = { .type = NLA_U32, },
+   [NHI_ATTR_MSG_TO_ICM]   = { .type = NLA_BINARY,
+   .len = TBT_ICM_RING_MAX_FRAME_SIZE },
+   [NHI_ATTR_MSG_FROM_ICM] = { .type = NLA_BINARY,
+   .len = TBT_ICM_RING_MAX_FRAME_SIZE },
+};
+
+/* NHI genetlink family */
+static struct genl_family nhi_genl_family = {
+   .id = GENL_ID_GENERATE,
+   .hdrsize= FIELD_SIZEOF(struct tbt_nhi_ctxt, id),
+   .name   = NHI_GENL_NAME,
+   .version= NHI_GENL_VERSION,
+   .maxattr= NHI_ATTR_MAX,
+};
+
+static LIST_HEAD(controllers_list);
+static DEFINE_MUTEX(controllers_list_mutex);
+static atomic_t subscribers = ATOMIC_INIT(0);
+/*
+ * Some of the received generic netlink messages are replied in a different
+ * context. The reply has to include the netlink portid of sender, therefore
+ * saving it in global variable (current assuption is one sender).
+ */
+static u32 portid;
+
+static bool nhi_nvm_authenticated(struct tbt_nhi_ctxt *nhi_ctxt)
+{
+   enum icm_operation_mode op_mode;
+   u32 *msg_head, port_id, reg;
+   struct sk_buff *skb;
+ 

[PATCH v2] leds: Add mutex protection in brightness_show()

[Jacek Anaszewski]

Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness.

After the addition of led_update_brightness() this is no longer
true, as the function can change the brightness if a LED class
driver implements brightness_get op. It can lead to races between
led_update_brightness() and led_set_brightness().

Signed-off-by: Jacek Anaszewski 
Cc: Hans de Goede 
Cc: Sakari Ailus 
Cc: Pavel Machek 
Cc: Andrew Lunn 
---
Changes since v1:
- added led_sysfs_is_disabled() check
- moved sprintf under mutex protection

 drivers/leds/led-class.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index b12f861..e472407 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -29,11 +29,23 @@ static ssize_t brightness_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
struct led_classdev *led_cdev = dev_get_drvdata(dev);
+   int ret;
 
-   /* no lock needed for this */
-   led_update_brightness(led_cdev);
+   mutex_lock(_cdev->led_access);
+
+   if (led_sysfs_is_disabled(led_cdev)) {
+   ret = -EBUSY;
+   goto unlock;
+   }
+
+   ret = led_update_brightness(led_cdev);
+   if (ret < 0)
+   goto unlock;
 
-   return sprintf(buf, "%u\n", led_cdev->brightness);
+   ret = sprintf(buf, "%u\n", led_cdev->brightness);
+unlock:
+   mutex_unlock(_cdev->led_access);
+   return ret;
 }
 
 static ssize_t brightness_store(struct device *dev,
-- 
1.9.1

[PATCH v2] leds: Add mutex protection in brightness_show()

[Jacek Anaszewski]

Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness.

After the addition of led_update_brightness() this is no longer
true, as the function can change the brightness if a LED class
driver implements brightness_get op. It can lead to races between
led_update_brightness() and led_set_brightness().

Signed-off-by: Jacek Anaszewski 
Cc: Hans de Goede 
Cc: Sakari Ailus 
Cc: Pavel Machek 
Cc: Andrew Lunn 
---
Changes since v1:
- added led_sysfs_is_disabled() check
- moved sprintf under mutex protection

 drivers/leds/led-class.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index b12f861..e472407 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -29,11 +29,23 @@ static ssize_t brightness_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
struct led_classdev *led_cdev = dev_get_drvdata(dev);
+   int ret;
 
-   /* no lock needed for this */
-   led_update_brightness(led_cdev);
+   mutex_lock(_cdev->led_access);
+
+   if (led_sysfs_is_disabled(led_cdev)) {
+   ret = -EBUSY;
+   goto unlock;
+   }
+
+   ret = led_update_brightness(led_cdev);
+   if (ret < 0)
+   goto unlock;
 
-   return sprintf(buf, "%u\n", led_cdev->brightness);
+   ret = sprintf(buf, "%u\n", led_cdev->brightness);
+unlock:
+   mutex_unlock(_cdev->led_access);
+   return ret;
 }
 
 static ssize_t brightness_store(struct device *dev,
-- 
1.9.1

Re: [PATCH v3 4/4] KVM: x86: emulate FXSAVE and FXRSTOR

[Radim Krčmář]

2016-11-09 00:25+0100, Paolo Bonzini:
> On 08/11/2016 20:54, Radim Krčmář wrote:
>> Internal errors were reported on 16 bit fxsave and fxrstor with ipxe.
>> Old Intels don't have unrestricted_guest, so we have to emulate them.
>> 
>> The patch takes advantage of the hardware implementation.
>> 
>> Signed-off-by: Radim Krčmář 
>> ---
>>  v3:
>>  - remove fxsave64 and extra colons at the end of asm to make old GCCs
>>happy  (fxsave64 could have been implemented using other nmemonics,
>>but there is no point when it won't be used + removing it makes the
>>code nicer.)
>>  v2:
>>  - throws #GP to the guest when reserved MXCSR are set [Nadav]
>>  - returns internal emulation error if an exception is hit during
>>execution
>>  - preserves XMM 8-15
>> ---
>>  arch/x86/kvm/emulate.c | 113 
>> -
>>  1 file changed, 112 insertions(+), 1 deletion(-)
>> 
>> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
>> index 6af3cac6ec89..1b3fab1fb8d3 100644
>> --- a/arch/x86/kvm/emulate.c
>> +++ b/arch/x86/kvm/emulate.c
>> @@ -3883,6 +3883,115 @@ static int em_movsxd(struct x86_emulate_ctxt *ctxt)
>>  return X86EMUL_CONTINUE;
>>  }
>>  
>> +static int check_fxsr(struct x86_emulate_ctxt *ctxt)
>> +{
>> +u32 eax = 1, ebx, ecx = 0, edx;
>> +
>> +ctxt->ops->get_cpuid(ctxt, , , , );
>> +if (!(edx & FFL(FXSR)))
>> +return emulate_ud(ctxt);
>> +
>> +if (ctxt->ops->get_cr(ctxt, 0) & (X86_CR0_TS | X86_CR0_EM))
>> +return emulate_nm(ctxt);
>> +
>> +/*
>> + * Don't emulate a case that should never be hit, instead of working
>> + * around a lack of fxsave64/fxrstor64 on old compilers.
>> + */
>> +if (ctxt->mode >= X86EMUL_MODE_PROT64)
>> +return X86EMUL_UNHANDLEABLE;
>> +
>> +return X86EMUL_CONTINUE;
>> +}
>> +
>> +/*
>> + * FXSAVE and FXRSTOR have 4 different formats depending on execution mode,
>> + *  1) 16 bit mode
>> + *  2) 32 bit mode
>> + * - like (1), but FIP and FDP (foo) are only 16 bit.  At least Intel 
>> CPUs
>> + *   preserve whole 32 bit values, though, so (1) and (2) are the same 
>> wrt.
>> + *   save and restore
>> + *  3) 64-bit mode with REX.W prefix
>> + * - like (2), but XMM 8-15 are being saved and restored
>> + *  4) 64-bit mode without REX.W prefix
>> + * - like (3), but FIP and FDP are 64 bit
>> + *
>> + * Emulation uses (3) for (1) and (2) and preserves XMM 8-15 to reach the
>> + * desired result.  (4) is not emulated.
>> + *
>> + * XXX: Guest and host CPUID.(EAX=07H,ECX=0H):EBX[bit 13] (deprecate FPU CS
>> + * and FPU DS) should match.
>> + */
>> +static int em_fxsave(struct x86_emulate_ctxt *ctxt)
>> +{
>> +struct fxregs_state fx_state;
>> +size_t size = 288; /* up to XMM7 */
> 
> Sorry for noticing this only now; if CR4.OSFXSR is 0, XMM and MXCSR
> should not be saved.

Intel processors don't save it, but the spec allows saving even when
CR4.OSFXSR is 0:

  If the OSFXSR bit in control register CR4 is not set, the FXSAVE
  instruction may not save this register (these registers).
  This behavior is implementation dependent.

I let "implementation dependent" behavior be the one with less code, but
haven't checked AMD spec, which doesn't seem to make it implementation
dependent ... I'll add it.  (On intel, OSFXSR gets written with 0 and
XMM 0-7 isn't modified without OSFXSR, so I'll just assume that AMD
won't break with that.)

> I can apply the first three patches already if you prefer.

Yes, they would not change, thanks.

RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

[Gabriele Paoloni]

Hi Arnd

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: 08 November 2016 16:25
> To: Yuanzhichang
> Cc: catalin.mari...@arm.com; will.dea...@arm.com; robh...@kernel.org;
> bhelg...@google.com; mark.rutl...@arm.com; o...@lixom.net; linux-arm-
> ker...@lists.infradead.org; lorenzo.pieral...@arm.com; linux-
> ker...@vger.kernel.org; Linuxarm; devicet...@vger.kernel.org; linux-
> p...@vger.kernel.org; linux-ser...@vger.kernel.org; miny...@acm.org;
> b...@kernel.crashing.org; liviu.du...@arm.com; zourongr...@gmail.com;
> John Garry; Gabriele Paoloni; zhichang.yua...@gmail.com;
> kant...@163.com; xuwei (O)
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
> 
> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> > +   /*
> > +* The first PCIBIOS_MIN_IO is reserved specifically for
> indirectIO.
> > +* It will separate indirectIO range from pci host bridge to
> > +* avoid the possible PIO conflict.
> > +* Set the indirectIO range directly here.
> > +*/
> > +   lpcdev->io_ops.start = 0;
> > +   lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> > +   lpcdev->io_ops.devpara = lpcdev;
> > +   lpcdev->io_ops.pfin = hisilpc_comm_in;
> > +   lpcdev->io_ops.pfout = hisilpc_comm_out;
> > +   lpcdev->io_ops.pfins = hisilpc_comm_ins;
> > +   lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> 
> I have to look at patch 2 in more detail again, after missing a few
> review
> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
> range here, and would hope that we can just go through the same
> assignment of logical port ranges that we have for PCI buses,
> decoupling
> the bus addresses from the linux-internal ones.

The point here is that we want to avoid any conflict/overlap between
the LPC I/O space and the PCI I/O space. With the assignment above
we make sure that LPC never interfere with PCI I/O space.

Thanks

Gab

> 
>   Arnd

Re: [PATCH v3 4/4] KVM: x86: emulate FXSAVE and FXRSTOR

[Radim Krčmář]

2016-11-09 00:25+0100, Paolo Bonzini:
> On 08/11/2016 20:54, Radim Krčmář wrote:
>> Internal errors were reported on 16 bit fxsave and fxrstor with ipxe.
>> Old Intels don't have unrestricted_guest, so we have to emulate them.
>> 
>> The patch takes advantage of the hardware implementation.
>> 
>> Signed-off-by: Radim Krčmář 
>> ---
>>  v3:
>>  - remove fxsave64 and extra colons at the end of asm to make old GCCs
>>happy  (fxsave64 could have been implemented using other nmemonics,
>>but there is no point when it won't be used + removing it makes the
>>code nicer.)
>>  v2:
>>  - throws #GP to the guest when reserved MXCSR are set [Nadav]
>>  - returns internal emulation error if an exception is hit during
>>execution
>>  - preserves XMM 8-15
>> ---
>>  arch/x86/kvm/emulate.c | 113 
>> -
>>  1 file changed, 112 insertions(+), 1 deletion(-)
>> 
>> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
>> index 6af3cac6ec89..1b3fab1fb8d3 100644
>> --- a/arch/x86/kvm/emulate.c
>> +++ b/arch/x86/kvm/emulate.c
>> @@ -3883,6 +3883,115 @@ static int em_movsxd(struct x86_emulate_ctxt *ctxt)
>>  return X86EMUL_CONTINUE;
>>  }
>>  
>> +static int check_fxsr(struct x86_emulate_ctxt *ctxt)
>> +{
>> +u32 eax = 1, ebx, ecx = 0, edx;
>> +
>> +ctxt->ops->get_cpuid(ctxt, , , , );
>> +if (!(edx & FFL(FXSR)))
>> +return emulate_ud(ctxt);
>> +
>> +if (ctxt->ops->get_cr(ctxt, 0) & (X86_CR0_TS | X86_CR0_EM))
>> +return emulate_nm(ctxt);
>> +
>> +/*
>> + * Don't emulate a case that should never be hit, instead of working
>> + * around a lack of fxsave64/fxrstor64 on old compilers.
>> + */
>> +if (ctxt->mode >= X86EMUL_MODE_PROT64)
>> +return X86EMUL_UNHANDLEABLE;
>> +
>> +return X86EMUL_CONTINUE;
>> +}
>> +
>> +/*
>> + * FXSAVE and FXRSTOR have 4 different formats depending on execution mode,
>> + *  1) 16 bit mode
>> + *  2) 32 bit mode
>> + * - like (1), but FIP and FDP (foo) are only 16 bit.  At least Intel 
>> CPUs
>> + *   preserve whole 32 bit values, though, so (1) and (2) are the same 
>> wrt.
>> + *   save and restore
>> + *  3) 64-bit mode with REX.W prefix
>> + * - like (2), but XMM 8-15 are being saved and restored
>> + *  4) 64-bit mode without REX.W prefix
>> + * - like (3), but FIP and FDP are 64 bit
>> + *
>> + * Emulation uses (3) for (1) and (2) and preserves XMM 8-15 to reach the
>> + * desired result.  (4) is not emulated.
>> + *
>> + * XXX: Guest and host CPUID.(EAX=07H,ECX=0H):EBX[bit 13] (deprecate FPU CS
>> + * and FPU DS) should match.
>> + */
>> +static int em_fxsave(struct x86_emulate_ctxt *ctxt)
>> +{
>> +struct fxregs_state fx_state;
>> +size_t size = 288; /* up to XMM7 */
> 
> Sorry for noticing this only now; if CR4.OSFXSR is 0, XMM and MXCSR
> should not be saved.

Intel processors don't save it, but the spec allows saving even when
CR4.OSFXSR is 0:

  If the OSFXSR bit in control register CR4 is not set, the FXSAVE
  instruction may not save this register (these registers).
  This behavior is implementation dependent.

I let "implementation dependent" behavior be the one with less code, but
haven't checked AMD spec, which doesn't seem to make it implementation
dependent ... I'll add it.  (On intel, OSFXSR gets written with 0 and
XMM 0-7 isn't modified without OSFXSR, so I'll just assume that AMD
won't break with that.)

> I can apply the first three patches already if you prefer.

Yes, they would not change, thanks.

RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

[Gabriele Paoloni]

Hi Arnd

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: 08 November 2016 16:25
> To: Yuanzhichang
> Cc: catalin.mari...@arm.com; will.dea...@arm.com; robh...@kernel.org;
> bhelg...@google.com; mark.rutl...@arm.com; o...@lixom.net; linux-arm-
> ker...@lists.infradead.org; lorenzo.pieral...@arm.com; linux-
> ker...@vger.kernel.org; Linuxarm; devicet...@vger.kernel.org; linux-
> p...@vger.kernel.org; linux-ser...@vger.kernel.org; miny...@acm.org;
> b...@kernel.crashing.org; liviu.du...@arm.com; zourongr...@gmail.com;
> John Garry; Gabriele Paoloni; zhichang.yua...@gmail.com;
> kant...@163.com; xuwei (O)
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
> 
> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> > +   /*
> > +* The first PCIBIOS_MIN_IO is reserved specifically for
> indirectIO.
> > +* It will separate indirectIO range from pci host bridge to
> > +* avoid the possible PIO conflict.
> > +* Set the indirectIO range directly here.
> > +*/
> > +   lpcdev->io_ops.start = 0;
> > +   lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> > +   lpcdev->io_ops.devpara = lpcdev;
> > +   lpcdev->io_ops.pfin = hisilpc_comm_in;
> > +   lpcdev->io_ops.pfout = hisilpc_comm_out;
> > +   lpcdev->io_ops.pfins = hisilpc_comm_ins;
> > +   lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> 
> I have to look at patch 2 in more detail again, after missing a few
> review
> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
> range here, and would hope that we can just go through the same
> assignment of logical port ranges that we have for PCI buses,
> decoupling
> the bus addresses from the linux-internal ones.

The point here is that we want to avoid any conflict/overlap between
the LPC I/O space and the PCI I/O space. With the assignment above
we make sure that LPC never interfere with PCI I/O space.

Thanks

Gab

> 
>   Arnd

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

[Oliver Neukum]

On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:

> These problems could very well be caused by running at SuperSpeed
> (USB-3) instead of high speed (USB-2).
> 
> Is there any way to test what happens when the device is attached to 
> the computer by a USB-2 cable?  That would prevent it from operating at 
> SuperSpeed.
> 
> The main point, however, is that the proposed patch doesn't seem to
> address the true problem, which is that the device gets suspended
> between probes.  The patch only tries to prevent it from being
> suspended during a probe -- which is already prevented by the USB core.

But why doesn't it fail during normal operation?

I suspect that its firmware requires the altsetting

/* should we change control altsetting on a NCM/MBIM function? */
if (cdc_ncm_select_altsetting(intf) == CDC_NCM_COMM_ALTSETTING_MBIM) {
data_altsetting = CDC_NCM_DATA_ALTSETTING_MBIM;
ret = cdc_mbim_set_ctrlalt(dev, intf, 
CDC_NCM_COMM_ALTSETTING_MBIM);

to be set before it accepts a suspension.

Regards
Oliver

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

[Oliver Neukum]

On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:

> These problems could very well be caused by running at SuperSpeed
> (USB-3) instead of high speed (USB-2).
> 
> Is there any way to test what happens when the device is attached to 
> the computer by a USB-2 cable?  That would prevent it from operating at 
> SuperSpeed.
> 
> The main point, however, is that the proposed patch doesn't seem to
> address the true problem, which is that the device gets suspended
> between probes.  The patch only tries to prevent it from being
> suspended during a probe -- which is already prevented by the USB core.

But why doesn't it fail during normal operation?

I suspect that its firmware requires the altsetting

/* should we change control altsetting on a NCM/MBIM function? */
if (cdc_ncm_select_altsetting(intf) == CDC_NCM_COMM_ALTSETTING_MBIM) {
data_altsetting = CDC_NCM_DATA_ALTSETTING_MBIM;
ret = cdc_mbim_set_ctrlalt(dev, intf, 
CDC_NCM_COMM_ALTSETTING_MBIM);

to be set before it accepts a suspension.

Regards
Oliver

Re: [PATCH/RFC v2] tools/leds: Add led_notify_mon program for monitoring brightness changes

[Jacek Anaszewski]

On 11/09/2016 12:50 PM, Hans de Goede wrote:

Reviewed-by: Hans de Goede 


Applied, thanks.

--
Best regards,
Jacek Anaszewski

Re: [Ksummit-discuss] Including images on Sphinx documents

[Jani Nikula]

On Wed, 09 Nov 2016, Markus Heiser  wrote:
> Am 09.11.2016 um 12:16 schrieb Jani Nikula :
>>> So I vote for :
>>> 
 1) copy (or symlink) all rst files to Documentation/output (or to the
 build dir specified via O= directive) and generate the *.pdf there,
 and produce those converted images via Makefile.;
>> 
>> We're supposed to solve problems, not create new ones.
>
> ... new ones? ...

Handle in-tree builds without copying.

Make dependency analysis with source rst and "intermediate" rst work.

Make sure your copying gets the timestamps right.

Make Sphinx dependency analysis look at the right copies depending on
in-tree vs. out-of-tree. Generally make sure it doesn't confuse Sphinx's
own dependency analysis.

The stuff I didn't think of.

Sure, it's all supposed to be basic Makefile stuff, but don't make the
mistake of thinking just one invocation of 'cp' will solve all the
problems. It all adds to the complexity we were trying to avoid when
dumping DocBook. It adds to the complexity of debugging stuff. (And hey,
there's still the one rebuilding-stuff-for-no-reason issue open.)

If you want to keep the documentation build sane, try to avoid the
Makefile preprocessing. And same old story, if you fix this for real,
even if as a Sphinx extension, *other* people than kernel developers
will be interested, and *we* don't have to do so much ourselves.


BR,
Jani.



>
>>> IMO placing 'sourcedir' to O= is more sane since this marries the
>>> Linux Makefile concept (relative to $PWD) with the sphinx concept
>>> (in or below 'sourcedir').
>
> -- Markus --

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [RFC] mem-hotplug: shall we skip unmovable node when doing numa balance?

[Mel Gorman]

On Tue, Nov 08, 2016 at 12:43:17PM +0800, Xishi Qiu wrote:
> On mem-hotplug system, there is a problem, please see the following case.
> 
> memtester xxG, the memory will be alloced on a movable node. And after numa
> balancing, the memory may be migrated to the other node, it may be a unmovable
> node. This will reduce the free memory of the unmovable node, and may be oom
> later.
> 

How would it OOM later? It's movable memmory that is moving via
automatic NUMA balancing so at the very least it can be reclaimed. If
the memory is mlocked or unable to migrate then it's irrelevant if
automatic balancing put it there.

> My question is that shall we skip unmovable node when doing numa balance?
> or just let the manager set some numa policies?
> 

If the unmovable node must be protected from automatic NUMA balancing
then policies are the appropriate step to prevent the processes running
on that node or from allocating memory on that node.

Either way, protecting unmovable nodes in the name of hotplug is pretty
much guaranteed to be a performance black hole because at the very
least, page table pages will always be remote accesses for processes
running on the unmovable node.

> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 057964d..f0954ac 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -2334,6 +2334,13 @@ int mpol_misplaced(struct page *page, struct 
> vm_area_struct *vma, unsigned long
>  out:
>   mpol_cond_put(pol);
>  
> + /* Skip unmovable nodes when do numa balancing */
> + if (movable_node_enabled && ret != -1) {
> + zone = NODE_DATA(ret)->node_zones + MAX_NR_ZONES - 1;
> + if (!populated_zone(zone))
> + ret = -1;
> + }
> +
>   return ret;
>  }

Nak.

-- 
Mel Gorman
SUSE Labs

Re: [PATCH/RFC v2] tools/leds: Add led_notify_mon program for monitoring brightness changes

[Jacek Anaszewski]

On 11/09/2016 12:50 PM, Hans de Goede wrote:

Reviewed-by: Hans de Goede 


Applied, thanks.

--
Best regards,
Jacek Anaszewski

Re: [Ksummit-discuss] Including images on Sphinx documents

[Jani Nikula]

On Wed, 09 Nov 2016, Markus Heiser  wrote:
> Am 09.11.2016 um 12:16 schrieb Jani Nikula :
>>> So I vote for :
>>> 
 1) copy (or symlink) all rst files to Documentation/output (or to the
 build dir specified via O= directive) and generate the *.pdf there,
 and produce those converted images via Makefile.;
>> 
>> We're supposed to solve problems, not create new ones.
>
> ... new ones? ...

Handle in-tree builds without copying.

Make dependency analysis with source rst and "intermediate" rst work.

Make sure your copying gets the timestamps right.

Make Sphinx dependency analysis look at the right copies depending on
in-tree vs. out-of-tree. Generally make sure it doesn't confuse Sphinx's
own dependency analysis.

The stuff I didn't think of.

Sure, it's all supposed to be basic Makefile stuff, but don't make the
mistake of thinking just one invocation of 'cp' will solve all the
problems. It all adds to the complexity we were trying to avoid when
dumping DocBook. It adds to the complexity of debugging stuff. (And hey,
there's still the one rebuilding-stuff-for-no-reason issue open.)

If you want to keep the documentation build sane, try to avoid the
Makefile preprocessing. And same old story, if you fix this for real,
even if as a Sphinx extension, *other* people than kernel developers
will be interested, and *we* don't have to do so much ourselves.


BR,
Jani.



>
>>> IMO placing 'sourcedir' to O= is more sane since this marries the
>>> Linux Makefile concept (relative to $PWD) with the sphinx concept
>>> (in or below 'sourcedir').
>
> -- Markus --

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [RFC] mem-hotplug: shall we skip unmovable node when doing numa balance?

[Mel Gorman]

On Tue, Nov 08, 2016 at 12:43:17PM +0800, Xishi Qiu wrote:
> On mem-hotplug system, there is a problem, please see the following case.
> 
> memtester xxG, the memory will be alloced on a movable node. And after numa
> balancing, the memory may be migrated to the other node, it may be a unmovable
> node. This will reduce the free memory of the unmovable node, and may be oom
> later.
> 

How would it OOM later? It's movable memmory that is moving via
automatic NUMA balancing so at the very least it can be reclaimed. If
the memory is mlocked or unable to migrate then it's irrelevant if
automatic balancing put it there.

> My question is that shall we skip unmovable node when doing numa balance?
> or just let the manager set some numa policies?
> 

If the unmovable node must be protected from automatic NUMA balancing
then policies are the appropriate step to prevent the processes running
on that node or from allocating memory on that node.

Either way, protecting unmovable nodes in the name of hotplug is pretty
much guaranteed to be a performance black hole because at the very
least, page table pages will always be remote accesses for processes
running on the unmovable node.

> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 057964d..f0954ac 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -2334,6 +2334,13 @@ int mpol_misplaced(struct page *page, struct 
> vm_area_struct *vma, unsigned long
>  out:
>   mpol_cond_put(pol);
>  
> + /* Skip unmovable nodes when do numa balancing */
> + if (movable_node_enabled && ret != -1) {
> + zone = NODE_DATA(ret)->node_zones + MAX_NR_ZONES - 1;
> + if (!populated_zone(zone))
> + ret = -1;
> + }
> +
>   return ret;
>  }

Nak.

-- 
Mel Gorman
SUSE Labs

Re: [PATCH v2 1/3] hwmon: (mcp3021) rework for DT support

[Guenter Roeck]

On 10/27/2016 03:33 PM, Clemens Gruber wrote:

Support setting the reference voltage from the device tree.
Rework of driver structure, put chip specific data in a separate
structure and assign it depending on device id from platform data or
DT match.

Signed-off-by: Clemens Gruber 
---
 Documentation/hwmon/mcp3021 |   6 ++
 drivers/hwmon/mcp3021.c | 145 
 2 files changed, 111 insertions(+), 40 deletions(-)

diff --git a/Documentation/hwmon/mcp3021 b/Documentation/hwmon/mcp3021
index 74a6b72..be252b7 100644
--- a/Documentation/hwmon/mcp3021
+++ b/Documentation/hwmon/mcp3021
@@ -12,6 +12,7 @@ Supported chips:
 Authors:
Mingkai Hu
Sven Schuchmann 
+   Clemens Gruber 

 Description
 ---
@@ -27,3 +28,8 @@ Communication to the MCP3021/MCP3221  is performed using a 
2-wire I2C
 compatible interface. Standard (100 kHz) and Fast (400 kHz) I2C modes are
 available. The default I2C device address is 0x4d (contact the Microchip
 factory for additional address options).
+
+The reference voltage used in the conversion can be set through platform data
+in millivolt (for backwards compatibility) or via device tree in microvolt.
+Please refer to Documentation/devicetree/bindings/i2c/mcp3021.txt for details
+about the device tree bindings.
diff --git a/drivers/hwmon/mcp3021.c b/drivers/hwmon/mcp3021.c
index 972444a..a8cf97f 100644
--- a/drivers/hwmon/mcp3021.c
+++ b/drivers/hwmon/mcp3021.c
@@ -4,6 +4,7 @@
  * Copyright (C) 2008-2009, 2012 Freescale Semiconductor, Inc.
  * Author: Mingkai Hu 
  * Reworked by Sven Schuchmann 
+ * Copyright (C) 2016 Clemens Gruber 
  *
  * This driver export the value of analog input voltage to sysfs, the
  * voltage unit is mV. Through the sysfs interface, lm-sensors tool
@@ -22,37 +23,56 @@
 #include 
 #include 
 #include 
+#include 
+#include 

-/* Vdd info */
+/* Vdd / reference voltage in millivolt */
 #define MCP3021_VDD_MAX5500
 #define MCP3021_VDD_MIN2700
-#define MCP3021_VDD_REF3300
-
-/* output format */
-#define MCP3021_SAR_SHIFT  2
-#define MCP3021_SAR_MASK   0x3ff
-#define MCP3021_OUTPUT_RES 10  /* 10-bit resolution */
-
-#define MCP3221_SAR_SHIFT  0
-#define MCP3221_SAR_MASK   0xfff
-#define MCP3221_OUTPUT_RES 12  /* 12-bit resolution */
+#define MCP3021_VDD_DEFAULT3300



There is no technical reason to drop / change those defines and use literals
in the code instead. Please don't.


 enum chips {
mcp3021,
mcp3221
 };

+struct mcp3021_chip_info {
+   u16 sar_shift;
+   u16 sar_mask;
+   u8 output_res;
+};
+
 /*
  * Client data (each client gets its own)
  */
 struct mcp3021_data {
struct device *hwmon_dev;
-   u32 vdd;/* device power supply */
-   u16 sar_shift;
-   u16 sar_mask;
-   u8 output_res;
+   const struct mcp3021_chip_info *chip_info;
+   u32 vdd; /* device power supply and reference voltage in millivolt */
 };

+static const struct mcp3021_chip_info mcp3021_chip_info_tbl[] = {
+   [mcp3021] = {
+   .sar_shift = 2,
+   .sar_mask = 0x3ff,
+   .output_res = 10,   /* 10-bit resolution */
+   },
+   [mcp3221] = {
+   .sar_shift = 0,
+   .sar_mask = 0xfff,
+   .output_res = 12,   /* 12-bit resolution */
+   },
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id of_mcp3021_match[] = {
+   { .compatible = "microchip,mcp3021", .data = (void *)mcp3021 },
+   { .compatible = "microchip,mcp3221", .data = (void *)mcp3221 },
+   { }
+};
+MODULE_DEVICE_TABLE(of, of_mcp3021_match);
+#endif
+
 static int mcp3021_read16(struct i2c_client *client)
 {
struct mcp3021_data *data = i2c_get_clientdata(client);
@@ -73,14 +93,15 @@ static int mcp3021_read16(struct i2c_client *client)
 * The ten-bit output code is composed of the lower 4-bit of the
 * first byte and the upper 6-bit of the second byte.
 */
-   reg = (reg >> data->sar_shift) & data->sar_mask;
+   reg = (reg >> data->chip_info->sar_shift) & data->chip_info->sar_mask;

return reg;
 }

 static inline u16 volts_from_reg(struct mcp3021_data *data, u16 val)
 {
-   return DIV_ROUND_CLOSEST(data->vdd * val, 1 << data->output_res);
+   return DIV_ROUND_CLOSEST(data->vdd * val,
+1 << data->chip_info->output_res);
 }

 static ssize_t show_in_input(struct device *dev, struct device_attribute *attr,
@@ -101,44 +122,85 @@ static ssize_t show_in_input(struct device *dev, struct 
device_attribute *attr,

 static DEVICE_ATTR(in0_input, S_IRUGO, show_in_input, NULL);

-static int mcp3021_probe(struct i2c_client *client,
+#ifdef CONFIG_OF
+static int 

Re: [PATCH v2 1/3] hwmon: (mcp3021) rework for DT support

[Guenter Roeck]

On 10/27/2016 03:33 PM, Clemens Gruber wrote:

Support setting the reference voltage from the device tree.
Rework of driver structure, put chip specific data in a separate
structure and assign it depending on device id from platform data or
DT match.

Signed-off-by: Clemens Gruber 
---
 Documentation/hwmon/mcp3021 |   6 ++
 drivers/hwmon/mcp3021.c | 145 
 2 files changed, 111 insertions(+), 40 deletions(-)

diff --git a/Documentation/hwmon/mcp3021 b/Documentation/hwmon/mcp3021
index 74a6b72..be252b7 100644
--- a/Documentation/hwmon/mcp3021
+++ b/Documentation/hwmon/mcp3021
@@ -12,6 +12,7 @@ Supported chips:
 Authors:
Mingkai Hu
Sven Schuchmann 
+   Clemens Gruber 

 Description
 ---
@@ -27,3 +28,8 @@ Communication to the MCP3021/MCP3221  is performed using a 
2-wire I2C
 compatible interface. Standard (100 kHz) and Fast (400 kHz) I2C modes are
 available. The default I2C device address is 0x4d (contact the Microchip
 factory for additional address options).
+
+The reference voltage used in the conversion can be set through platform data
+in millivolt (for backwards compatibility) or via device tree in microvolt.
+Please refer to Documentation/devicetree/bindings/i2c/mcp3021.txt for details
+about the device tree bindings.
diff --git a/drivers/hwmon/mcp3021.c b/drivers/hwmon/mcp3021.c
index 972444a..a8cf97f 100644
--- a/drivers/hwmon/mcp3021.c
+++ b/drivers/hwmon/mcp3021.c
@@ -4,6 +4,7 @@
  * Copyright (C) 2008-2009, 2012 Freescale Semiconductor, Inc.
  * Author: Mingkai Hu 
  * Reworked by Sven Schuchmann 
+ * Copyright (C) 2016 Clemens Gruber 
  *
  * This driver export the value of analog input voltage to sysfs, the
  * voltage unit is mV. Through the sysfs interface, lm-sensors tool
@@ -22,37 +23,56 @@
 #include 
 #include 
 #include 
+#include 
+#include 

-/* Vdd info */
+/* Vdd / reference voltage in millivolt */
 #define MCP3021_VDD_MAX5500
 #define MCP3021_VDD_MIN2700
-#define MCP3021_VDD_REF3300
-
-/* output format */
-#define MCP3021_SAR_SHIFT  2
-#define MCP3021_SAR_MASK   0x3ff
-#define MCP3021_OUTPUT_RES 10  /* 10-bit resolution */
-
-#define MCP3221_SAR_SHIFT  0
-#define MCP3221_SAR_MASK   0xfff
-#define MCP3221_OUTPUT_RES 12  /* 12-bit resolution */
+#define MCP3021_VDD_DEFAULT3300



There is no technical reason to drop / change those defines and use literals
in the code instead. Please don't.


 enum chips {
mcp3021,
mcp3221
 };

+struct mcp3021_chip_info {
+   u16 sar_shift;
+   u16 sar_mask;
+   u8 output_res;
+};
+
 /*
  * Client data (each client gets its own)
  */
 struct mcp3021_data {
struct device *hwmon_dev;
-   u32 vdd;/* device power supply */
-   u16 sar_shift;
-   u16 sar_mask;
-   u8 output_res;
+   const struct mcp3021_chip_info *chip_info;
+   u32 vdd; /* device power supply and reference voltage in millivolt */
 };

+static const struct mcp3021_chip_info mcp3021_chip_info_tbl[] = {
+   [mcp3021] = {
+   .sar_shift = 2,
+   .sar_mask = 0x3ff,
+   .output_res = 10,   /* 10-bit resolution */
+   },
+   [mcp3221] = {
+   .sar_shift = 0,
+   .sar_mask = 0xfff,
+   .output_res = 12,   /* 12-bit resolution */
+   },
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id of_mcp3021_match[] = {
+   { .compatible = "microchip,mcp3021", .data = (void *)mcp3021 },
+   { .compatible = "microchip,mcp3221", .data = (void *)mcp3221 },
+   { }
+};
+MODULE_DEVICE_TABLE(of, of_mcp3021_match);
+#endif
+
 static int mcp3021_read16(struct i2c_client *client)
 {
struct mcp3021_data *data = i2c_get_clientdata(client);
@@ -73,14 +93,15 @@ static int mcp3021_read16(struct i2c_client *client)
 * The ten-bit output code is composed of the lower 4-bit of the
 * first byte and the upper 6-bit of the second byte.
 */
-   reg = (reg >> data->sar_shift) & data->sar_mask;
+   reg = (reg >> data->chip_info->sar_shift) & data->chip_info->sar_mask;

return reg;
 }

 static inline u16 volts_from_reg(struct mcp3021_data *data, u16 val)
 {
-   return DIV_ROUND_CLOSEST(data->vdd * val, 1 << data->output_res);
+   return DIV_ROUND_CLOSEST(data->vdd * val,
+1 << data->chip_info->output_res);
 }

 static ssize_t show_in_input(struct device *dev, struct device_attribute *attr,
@@ -101,44 +122,85 @@ static ssize_t show_in_input(struct device *dev, struct 
device_attribute *attr,

 static DEVICE_ATTR(in0_input, S_IRUGO, show_in_input, NULL);

-static int mcp3021_probe(struct i2c_client *client,
+#ifdef CONFIG_OF
+static int mcp3021_probe_dt(struct i2c_client *client,
const struct i2c_device_id *id)
 {
-   int err;
-   struct mcp3021_data *data = NULL;
+   struct 

Re: [PATCH v2] led: core: Use atomic bit-field for the blink-flags

[Hans de Goede]

Hi,

On 08-11-16 14:58, Jacek Anaszewski wrote:

From: Hans de Goede 

All the LED_BLINK* flags are accessed read-modify-write from e.g.
led_set_brightness and led_blink_set_oneshot while both
set_brightness_work and the blink_timer may be running.

If these race then the modify step done by one of them may be lost,
switch the LED_BLINK* flags to a new atomic work_flags bit-field
to avoid this race.

Signed-off-by: Hans de Goede 
Signed-off-by: Jacek Anaszewski 
---
Changes since v1:
- keep set_brightness_work in linux/leds.h


Thank you.

Patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans





 drivers/leds/led-class.c |  1 +
 drivers/leds/led-core.c  | 52 +---
 include/linux/leds.h | 24 --
 3 files changed, 42 insertions(+), 35 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index c8d2d67..b12f861 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -212,6 +212,7 @@ int led_classdev_register(struct device *parent, struct 
led_classdev *led_cdev)
return -ENODEV;
}

+   led_cdev->work_flags = 0;
 #ifdef CONFIG_LEDS_TRIGGERS
init_rwsem(_cdev->trigger_lock);
 #endif
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index e2e5cc7..620257a 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -61,12 +61,13 @@ static void led_timer_function(unsigned long data)

if (!led_cdev->blink_delay_on || !led_cdev->blink_delay_off) {
led_set_brightness_nosleep(led_cdev, LED_OFF);
-   led_cdev->flags &= ~LED_BLINK_SW;
+   clear_bit(LED_BLINK_SW, _cdev->work_flags);
return;
}

-   if (led_cdev->flags & LED_BLINK_ONESHOT_STOP) {
-   led_cdev->flags &=  ~(LED_BLINK_ONESHOT_STOP | LED_BLINK_SW);
+   if (test_and_clear_bit(LED_BLINK_ONESHOT_STOP,
+  _cdev->work_flags)) {
+   clear_bit(LED_BLINK_SW, _cdev->work_flags);
return;
}

@@ -81,10 +82,9 @@ static void led_timer_function(unsigned long data)
 * Do it only if there is no pending blink brightness
 * change, to avoid overwriting the new value.
 */
-   if (!(led_cdev->flags & LED_BLINK_BRIGHTNESS_CHANGE))
+   if (!test_and_clear_bit(LED_BLINK_BRIGHTNESS_CHANGE,
+   _cdev->work_flags))
led_cdev->blink_brightness = brightness;
-   else
-   led_cdev->flags &= ~LED_BLINK_BRIGHTNESS_CHANGE;
brightness = LED_OFF;
delay = led_cdev->blink_delay_off;
}
@@ -95,13 +95,15 @@ static void led_timer_function(unsigned long data)
 * the final blink state so that the led is toggled each delay_on +
 * delay_off milliseconds in worst case.
 */
-   if (led_cdev->flags & LED_BLINK_ONESHOT) {
-   if (led_cdev->flags & LED_BLINK_INVERT) {
+   if (test_bit(LED_BLINK_ONESHOT, _cdev->work_flags)) {
+   if (test_bit(LED_BLINK_INVERT, _cdev->work_flags)) {
if (brightness)
-   led_cdev->flags |= LED_BLINK_ONESHOT_STOP;
+   set_bit(LED_BLINK_ONESHOT_STOP,
+   _cdev->work_flags);
} else {
if (!brightness)
-   led_cdev->flags |= LED_BLINK_ONESHOT_STOP;
+   set_bit(LED_BLINK_ONESHOT_STOP,
+   _cdev->work_flags);
}
}

@@ -114,10 +116,9 @@ static void set_brightness_delayed(struct work_struct *ws)
container_of(ws, struct led_classdev, set_brightness_work);
int ret = 0;

-   if (led_cdev->flags & LED_BLINK_DISABLE) {
+   if (test_and_clear_bit(LED_BLINK_DISABLE, _cdev->work_flags)) {
led_cdev->delayed_set_value = LED_OFF;
led_stop_software_blink(led_cdev);
-   led_cdev->flags &= ~LED_BLINK_DISABLE;
}

ret = __led_set_brightness(led_cdev, led_cdev->delayed_set_value);
@@ -160,7 +161,7 @@ static void led_set_software_blink(struct led_classdev 
*led_cdev,
return;
}

-   led_cdev->flags |= LED_BLINK_SW;
+   set_bit(LED_BLINK_SW, _cdev->work_flags);
mod_timer(_cdev->blink_timer, jiffies + 1);
 }

@@ -169,7 +170,7 @@ static void led_blink_setup(struct led_classdev *led_cdev,
 unsigned long *delay_on,
 unsigned long *delay_off)
 {
-   if (!(led_cdev->flags & LED_BLINK_ONESHOT) &&
+   if (!test_bit(LED_BLINK_ONESHOT, _cdev->work_flags) &&
led_cdev->blink_set &&
  

Re: [PATCH v2] leds: ledtrig-heartbeat: Make top brightness adjustable

[Hans de Goede]

Hi,

On 09-11-16 11:43, Jacek Anaszewski wrote:

LED class heartbeat trigger allowed only for blinking with max_brightness
value. This patch adds more flexibility by exploiting part of LED core
software blink infrastructure.

Signed-off-by: Jacek Anaszewski 
Cc: Pavel Machek 
Cc: Hans de Goede 
---
Changes since v1:
- after introduction of work_flags and new_blink_brightness properties
  this patch needs to be updated


Patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



 drivers/leds/trigger/ledtrig-heartbeat.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/leds/trigger/ledtrig-heartbeat.c 
b/drivers/leds/trigger/ledtrig-heartbeat.c
index c9f3862..e6f2f8b 100644
--- a/drivers/leds/trigger/ledtrig-heartbeat.c
+++ b/drivers/leds/trigger/ledtrig-heartbeat.c
@@ -43,6 +43,9 @@ static void led_heartbeat_function(unsigned long data)
return;
}

+   if (test_and_clear_bit(LED_BLINK_BRIGHTNESS_CHANGE, 
_cdev->work_flags))
+   led_cdev->blink_brightness = led_cdev->new_blink_brightness;
+
/* acts like an actual heart beat -- ie thump-thump-pause... */
switch (heartbeat_data->phase) {
case 0:
@@ -59,26 +62,26 @@ static void led_heartbeat_function(unsigned long data)
delay = msecs_to_jiffies(70);
heartbeat_data->phase++;
if (!heartbeat_data->invert)
-   brightness = led_cdev->max_brightness;
+   brightness = led_cdev->blink_brightness;
break;
case 1:
delay = heartbeat_data->period / 4 - msecs_to_jiffies(70);
heartbeat_data->phase++;
if (heartbeat_data->invert)
-   brightness = led_cdev->max_brightness;
+   brightness = led_cdev->blink_brightness;
break;
case 2:
delay = msecs_to_jiffies(70);
heartbeat_data->phase++;
if (!heartbeat_data->invert)
-   brightness = led_cdev->max_brightness;
+   brightness = led_cdev->blink_brightness;
break;
default:
delay = heartbeat_data->period - heartbeat_data->period / 4 -
msecs_to_jiffies(70);
heartbeat_data->phase = 0;
if (heartbeat_data->invert)
-   brightness = led_cdev->max_brightness;
+   brightness = led_cdev->blink_brightness;
break;
}

@@ -133,7 +136,10 @@ static void heartbeat_trig_activate(struct led_classdev 
*led_cdev)
setup_timer(_data->timer,
led_heartbeat_function, (unsigned long) led_cdev);
heartbeat_data->phase = 0;
+   if (!led_cdev->blink_brightness)
+   led_cdev->blink_brightness = led_cdev->max_brightness;
led_heartbeat_function(heartbeat_data->timer.data);
+   set_bit(LED_BLINK_SW, _cdev->work_flags);
led_cdev->activated = true;
 }

@@ -145,6 +151,7 @@ static void heartbeat_trig_deactivate(struct led_classdev 
*led_cdev)
del_timer_sync(_data->timer);
device_remove_file(led_cdev->dev, _attr_invert);
kfree(heartbeat_data);
+   clear_bit(LED_BLINK_SW, _cdev->work_flags);
led_cdev->activated = false;
}
 }

Re: [PATCH v2] leds: ledtrig-heartbeat: Make top brightness adjustable

[Jacek Anaszewski]

Hi Pavel,

On 11/09/2016 12:21 PM, Pavel Machek wrote:

On Wed 2016-11-09 11:43:46, Jacek Anaszewski wrote:

LED class heartbeat trigger allowed only for blinking with max_brightness
value. This patch adds more flexibility by exploiting part of LED core
software blink infrastructure.

Signed-off-by: Jacek Anaszewski 


Acked-by: Pavel Machek 



Thanks. Reapplied on top of blink_brightness race fixes.

--
Best regards,
Jacek Anaszewski

Re: [PATCH v2] led: core: Use atomic bit-field for the blink-flags

[Hans de Goede]

Hi,

On 08-11-16 14:58, Jacek Anaszewski wrote:

From: Hans de Goede 

All the LED_BLINK* flags are accessed read-modify-write from e.g.
led_set_brightness and led_blink_set_oneshot while both
set_brightness_work and the blink_timer may be running.

If these race then the modify step done by one of them may be lost,
switch the LED_BLINK* flags to a new atomic work_flags bit-field
to avoid this race.

Signed-off-by: Hans de Goede 
Signed-off-by: Jacek Anaszewski 
---
Changes since v1:
- keep set_brightness_work in linux/leds.h


Thank you.

Patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans





 drivers/leds/led-class.c |  1 +
 drivers/leds/led-core.c  | 52 +---
 include/linux/leds.h | 24 --
 3 files changed, 42 insertions(+), 35 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index c8d2d67..b12f861 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -212,6 +212,7 @@ int led_classdev_register(struct device *parent, struct 
led_classdev *led_cdev)
return -ENODEV;
}

+   led_cdev->work_flags = 0;
 #ifdef CONFIG_LEDS_TRIGGERS
init_rwsem(_cdev->trigger_lock);
 #endif
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index e2e5cc7..620257a 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -61,12 +61,13 @@ static void led_timer_function(unsigned long data)

if (!led_cdev->blink_delay_on || !led_cdev->blink_delay_off) {
led_set_brightness_nosleep(led_cdev, LED_OFF);
-   led_cdev->flags &= ~LED_BLINK_SW;
+   clear_bit(LED_BLINK_SW, _cdev->work_flags);
return;
}

-   if (led_cdev->flags & LED_BLINK_ONESHOT_STOP) {
-   led_cdev->flags &=  ~(LED_BLINK_ONESHOT_STOP | LED_BLINK_SW);
+   if (test_and_clear_bit(LED_BLINK_ONESHOT_STOP,
+  _cdev->work_flags)) {
+   clear_bit(LED_BLINK_SW, _cdev->work_flags);
return;
}

@@ -81,10 +82,9 @@ static void led_timer_function(unsigned long data)
 * Do it only if there is no pending blink brightness
 * change, to avoid overwriting the new value.
 */
-   if (!(led_cdev->flags & LED_BLINK_BRIGHTNESS_CHANGE))
+   if (!test_and_clear_bit(LED_BLINK_BRIGHTNESS_CHANGE,
+   _cdev->work_flags))
led_cdev->blink_brightness = brightness;
-   else
-   led_cdev->flags &= ~LED_BLINK_BRIGHTNESS_CHANGE;
brightness = LED_OFF;
delay = led_cdev->blink_delay_off;
}
@@ -95,13 +95,15 @@ static void led_timer_function(unsigned long data)
 * the final blink state so that the led is toggled each delay_on +
 * delay_off milliseconds in worst case.
 */
-   if (led_cdev->flags & LED_BLINK_ONESHOT) {
-   if (led_cdev->flags & LED_BLINK_INVERT) {
+   if (test_bit(LED_BLINK_ONESHOT, _cdev->work_flags)) {
+   if (test_bit(LED_BLINK_INVERT, _cdev->work_flags)) {
if (brightness)
-   led_cdev->flags |= LED_BLINK_ONESHOT_STOP;
+   set_bit(LED_BLINK_ONESHOT_STOP,
+   _cdev->work_flags);
} else {
if (!brightness)
-   led_cdev->flags |= LED_BLINK_ONESHOT_STOP;
+   set_bit(LED_BLINK_ONESHOT_STOP,
+   _cdev->work_flags);
}
}

@@ -114,10 +116,9 @@ static void set_brightness_delayed(struct work_struct *ws)
container_of(ws, struct led_classdev, set_brightness_work);
int ret = 0;

-   if (led_cdev->flags & LED_BLINK_DISABLE) {
+   if (test_and_clear_bit(LED_BLINK_DISABLE, _cdev->work_flags)) {
led_cdev->delayed_set_value = LED_OFF;
led_stop_software_blink(led_cdev);
-   led_cdev->flags &= ~LED_BLINK_DISABLE;
}

ret = __led_set_brightness(led_cdev, led_cdev->delayed_set_value);
@@ -160,7 +161,7 @@ static void led_set_software_blink(struct led_classdev 
*led_cdev,
return;
}

-   led_cdev->flags |= LED_BLINK_SW;
+   set_bit(LED_BLINK_SW, _cdev->work_flags);
mod_timer(_cdev->blink_timer, jiffies + 1);
 }

@@ -169,7 +170,7 @@ static void led_blink_setup(struct led_classdev *led_cdev,
 unsigned long *delay_on,
 unsigned long *delay_off)
 {
-   if (!(led_cdev->flags & LED_BLINK_ONESHOT) &&
+   if (!test_bit(LED_BLINK_ONESHOT, _cdev->work_flags) &&
led_cdev->blink_set &&
!led_cdev->blink_set(led_cdev, delay_on, delay_off))
return;
@@ -196,8 

Re: [PATCH v2] leds: ledtrig-heartbeat: Make top brightness adjustable

[Hans de Goede]

Hi,

On 09-11-16 11:43, Jacek Anaszewski wrote:

LED class heartbeat trigger allowed only for blinking with max_brightness
value. This patch adds more flexibility by exploiting part of LED core
software blink infrastructure.

Signed-off-by: Jacek Anaszewski 
Cc: Pavel Machek 
Cc: Hans de Goede 
---
Changes since v1:
- after introduction of work_flags and new_blink_brightness properties
  this patch needs to be updated


Patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



 drivers/leds/trigger/ledtrig-heartbeat.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/leds/trigger/ledtrig-heartbeat.c 
b/drivers/leds/trigger/ledtrig-heartbeat.c
index c9f3862..e6f2f8b 100644
--- a/drivers/leds/trigger/ledtrig-heartbeat.c
+++ b/drivers/leds/trigger/ledtrig-heartbeat.c
@@ -43,6 +43,9 @@ static void led_heartbeat_function(unsigned long data)
return;
}

+   if (test_and_clear_bit(LED_BLINK_BRIGHTNESS_CHANGE, 
_cdev->work_flags))
+   led_cdev->blink_brightness = led_cdev->new_blink_brightness;
+
/* acts like an actual heart beat -- ie thump-thump-pause... */
switch (heartbeat_data->phase) {
case 0:
@@ -59,26 +62,26 @@ static void led_heartbeat_function(unsigned long data)
delay = msecs_to_jiffies(70);
heartbeat_data->phase++;
if (!heartbeat_data->invert)
-   brightness = led_cdev->max_brightness;
+   brightness = led_cdev->blink_brightness;
break;
case 1:
delay = heartbeat_data->period / 4 - msecs_to_jiffies(70);
heartbeat_data->phase++;
if (heartbeat_data->invert)
-   brightness = led_cdev->max_brightness;
+   brightness = led_cdev->blink_brightness;
break;
case 2:
delay = msecs_to_jiffies(70);
heartbeat_data->phase++;
if (!heartbeat_data->invert)
-   brightness = led_cdev->max_brightness;
+   brightness = led_cdev->blink_brightness;
break;
default:
delay = heartbeat_data->period - heartbeat_data->period / 4 -
msecs_to_jiffies(70);
heartbeat_data->phase = 0;
if (heartbeat_data->invert)
-   brightness = led_cdev->max_brightness;
+   brightness = led_cdev->blink_brightness;
break;
}

@@ -133,7 +136,10 @@ static void heartbeat_trig_activate(struct led_classdev 
*led_cdev)
setup_timer(_data->timer,
led_heartbeat_function, (unsigned long) led_cdev);
heartbeat_data->phase = 0;
+   if (!led_cdev->blink_brightness)
+   led_cdev->blink_brightness = led_cdev->max_brightness;
led_heartbeat_function(heartbeat_data->timer.data);
+   set_bit(LED_BLINK_SW, _cdev->work_flags);
led_cdev->activated = true;
 }

@@ -145,6 +151,7 @@ static void heartbeat_trig_deactivate(struct led_classdev 
*led_cdev)
del_timer_sync(_data->timer);
device_remove_file(led_cdev->dev, _attr_invert);
kfree(heartbeat_data);
+   clear_bit(LED_BLINK_SW, _cdev->work_flags);
led_cdev->activated = false;
}
 }

Re: [PATCH v2] leds: ledtrig-heartbeat: Make top brightness adjustable

[Jacek Anaszewski]

Hi Pavel,

On 11/09/2016 12:21 PM, Pavel Machek wrote:

On Wed 2016-11-09 11:43:46, Jacek Anaszewski wrote:

LED class heartbeat trigger allowed only for blinking with max_brightness
value. This patch adds more flexibility by exploiting part of LED core
software blink infrastructure.

Signed-off-by: Jacek Anaszewski 


Acked-by: Pavel Machek 



Thanks. Reapplied on top of blink_brightness race fixes.

--
Best regards,
Jacek Anaszewski

Re: [PATCH/RFC v2] tools/leds: Add led_notify_mon program for monitoring brightness changes

[Hans de Goede]

Hi,

On 08-11-16 12:36, Jacek Anaszewski wrote:

LED subsystem supports POLLPRI on "brightness" sysfs file of LED
class devices. This tool demonstrates how to use the feature.

Signed-off-by: Jacek Anaszewski 
Cc: Hans de Goede 


Thank you.

Patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


---
Changes since v1:
- added lseek which fixes non-blocking poll() behaviour

 tools/leds/Makefile |  4 +--
 tools/leds/led_notify_mon.c | 83 +
 2 files changed, 85 insertions(+), 2 deletions(-)
 create mode 100644 tools/leds/led_notify_mon.c

diff --git a/tools/leds/Makefile b/tools/leds/Makefile
index c03a79e..0fa948a 100644
--- a/tools/leds/Makefile
+++ b/tools/leds/Makefile
@@ -3,11 +3,11 @@
 CC = $(CROSS_COMPILE)gcc
 CFLAGS = -Wall -Wextra -g -I../../include/uapi

-all: uledmon
+all: uledmon led_notify_mon
 %: %.c
$(CC) $(CFLAGS) -o $@ $^

 clean:
-   $(RM) uledmon
+   $(RM) uledmon led_notify_mon

 .PHONY: all clean
diff --git a/tools/leds/led_notify_mon.c b/tools/leds/led_notify_mon.c
new file mode 100644
index 000..8b6e6f9
--- /dev/null
+++ b/tools/leds/led_notify_mon.c
@@ -0,0 +1,83 @@
+/*
+ * led_notify_mon.c
+ *
+ * This program monitors LED brightness change notifications,
+ * either having its origin in the hardware or in the software.
+ * A timestamp and brightness value is printed each time the brightness 
changes.
+ *
+ * Usage: led_notify_mon 
+ *
+ *  is the name of the LED class device to be monitored. Pressing
+ * CTRL+C will exit.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+int main(int argc, char const *argv[])
+{
+   int fd, ret;
+   char brightness_file_path[LEDS_MAX_NAME_SIZE + 11];
+   struct pollfd pollfd;
+   struct timespec ts;
+   char buf[11];
+
+   if (argc != 2) {
+   fprintf(stderr, "Requires  argument\n");
+   return 1;
+   }
+
+   snprintf(brightness_file_path, LEDS_MAX_NAME_SIZE,
+"/sys/class/leds/%s/brightness", argv[1]);
+
+   fd = open(brightness_file_path, O_RDONLY);
+   if (fd == -1) {
+   printf("Failed to open %s file\n", brightness_file_path);
+   return 1;
+   }
+
+   ret = read(fd, buf, sizeof(buf));
+   if (ret < 0) {
+   printf("Failed to read %s file\n", brightness_file_path);
+   goto err_read;
+   }
+
+   pollfd.fd = fd;
+   pollfd.events = POLLPRI;
+
+   while (1) {
+   ret = poll(, 1, -1);
+   if (ret == -1) {
+   printf("Failed to poll %s file (%d)\n",
+   brightness_file_path, ret);
+   ret = 1;
+   break;
+   }
+
+   clock_gettime(CLOCK_MONOTONIC, );
+
+   ret = read(fd, buf, sizeof(buf));
+   if (ret < 0)
+   break;
+
+   ret = lseek(pollfd.fd, 0, SEEK_SET);
+   if (ret < 0) {
+   printf("lseek failed (%d)\n", ret);
+   break;
+   }
+
+   printf("[%ld.%09ld] %d\n", ts.tv_sec, ts.tv_nsec, atoi(buf));
+   }
+
+err_read:
+   close(fd);
+
+   return ret;
+}

Re: [PATCH/RFC v2] tools/leds: Add led_notify_mon program for monitoring brightness changes

[Hans de Goede]

Hi,

On 08-11-16 12:36, Jacek Anaszewski wrote:

LED subsystem supports POLLPRI on "brightness" sysfs file of LED
class devices. This tool demonstrates how to use the feature.

Signed-off-by: Jacek Anaszewski 
Cc: Hans de Goede 


Thank you.

Patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


---
Changes since v1:
- added lseek which fixes non-blocking poll() behaviour

 tools/leds/Makefile |  4 +--
 tools/leds/led_notify_mon.c | 83 +
 2 files changed, 85 insertions(+), 2 deletions(-)
 create mode 100644 tools/leds/led_notify_mon.c

diff --git a/tools/leds/Makefile b/tools/leds/Makefile
index c03a79e..0fa948a 100644
--- a/tools/leds/Makefile
+++ b/tools/leds/Makefile
@@ -3,11 +3,11 @@
 CC = $(CROSS_COMPILE)gcc
 CFLAGS = -Wall -Wextra -g -I../../include/uapi

-all: uledmon
+all: uledmon led_notify_mon
 %: %.c
$(CC) $(CFLAGS) -o $@ $^

 clean:
-   $(RM) uledmon
+   $(RM) uledmon led_notify_mon

 .PHONY: all clean
diff --git a/tools/leds/led_notify_mon.c b/tools/leds/led_notify_mon.c
new file mode 100644
index 000..8b6e6f9
--- /dev/null
+++ b/tools/leds/led_notify_mon.c
@@ -0,0 +1,83 @@
+/*
+ * led_notify_mon.c
+ *
+ * This program monitors LED brightness change notifications,
+ * either having its origin in the hardware or in the software.
+ * A timestamp and brightness value is printed each time the brightness 
changes.
+ *
+ * Usage: led_notify_mon 
+ *
+ *  is the name of the LED class device to be monitored. Pressing
+ * CTRL+C will exit.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+int main(int argc, char const *argv[])
+{
+   int fd, ret;
+   char brightness_file_path[LEDS_MAX_NAME_SIZE + 11];
+   struct pollfd pollfd;
+   struct timespec ts;
+   char buf[11];
+
+   if (argc != 2) {
+   fprintf(stderr, "Requires  argument\n");
+   return 1;
+   }
+
+   snprintf(brightness_file_path, LEDS_MAX_NAME_SIZE,
+"/sys/class/leds/%s/brightness", argv[1]);
+
+   fd = open(brightness_file_path, O_RDONLY);
+   if (fd == -1) {
+   printf("Failed to open %s file\n", brightness_file_path);
+   return 1;
+   }
+
+   ret = read(fd, buf, sizeof(buf));
+   if (ret < 0) {
+   printf("Failed to read %s file\n", brightness_file_path);
+   goto err_read;
+   }
+
+   pollfd.fd = fd;
+   pollfd.events = POLLPRI;
+
+   while (1) {
+   ret = poll(, 1, -1);
+   if (ret == -1) {
+   printf("Failed to poll %s file (%d)\n",
+   brightness_file_path, ret);
+   ret = 1;
+   break;
+   }
+
+   clock_gettime(CLOCK_MONOTONIC, );
+
+   ret = read(fd, buf, sizeof(buf));
+   if (ret < 0)
+   break;
+
+   ret = lseek(pollfd.fd, 0, SEEK_SET);
+   if (ret < 0) {
+   printf("lseek failed (%d)\n", ret);
+   break;
+   }
+
+   printf("[%ld.%09ld] %d\n", ts.tv_sec, ts.tv_nsec, atoi(buf));
+   }
+
+err_read:
+   close(fd);
+
+   return ret;
+}

[PATCH 4.4 45/69] scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Kashyap Desai 

commit 1e793f6fc0db920400574211c48f9157a37e3945 upstream.

Commit 02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.

[mkp: clarified patch description]

Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
Signed-off-by: Kashyap Desai 
Signed-off-by: Sumit Saxena 
Reviewed-by: Tomas Henzl 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Ewan D. Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/megaraid/megaraid_sas_base.c |   13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1688,16 +1688,13 @@ megasas_queue_command(struct Scsi_Host *
goto out_done;
}
 
-   switch (scmd->cmnd[0]) {
-   case SYNCHRONIZE_CACHE:
-   /*
-* FW takes care of flush cache on its own
-* No need to send it down
-*/
+   /*
+* FW takes care of flush cache on its own for Virtual Disk.
+* No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to 
FW.
+*/
+   if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
scmd->result = DID_OK << 16;
goto out_done;
-   default:
-   break;
}
 
if (instance->instancet->build_and_issue_cmd(instance, scmd)) {

[PATCH 4.4 45/69] scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Kashyap Desai 

commit 1e793f6fc0db920400574211c48f9157a37e3945 upstream.

Commit 02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.

[mkp: clarified patch description]

Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
Signed-off-by: Kashyap Desai 
Signed-off-by: Sumit Saxena 
Reviewed-by: Tomas Henzl 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Ewan D. Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/megaraid/megaraid_sas_base.c |   13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1688,16 +1688,13 @@ megasas_queue_command(struct Scsi_Host *
goto out_done;
}
 
-   switch (scmd->cmnd[0]) {
-   case SYNCHRONIZE_CACHE:
-   /*
-* FW takes care of flush cache on its own
-* No need to send it down
-*/
+   /*
+* FW takes care of flush cache on its own for Virtual Disk.
+* No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to 
FW.
+*/
+   if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
scmd->result = DID_OK << 16;
goto out_done;
-   default:
-   break;
}
 
if (instance->instancet->build_and_issue_cmd(instance, scmd)) {

[PATCH 4.4 48/69] mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Jaehoon Chung 

commit 45c7a4908a307a023e237a64a3eadcafc4836493 upstream.

platform_get_resource can be returned the NULL pointer.
Then regs->start should be referred to NULL Pointer.
devm_ioremap_resource() checks whether res is NULL or not.

Signed-off-by: Jaehoon Chung 
Reviewed-by: Shawn Lin 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/dw_mmc-pltfm.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -59,12 +59,13 @@ int dw_mci_pltfm_register(struct platfor
host->pdata = pdev->dev.platform_data;
 
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   /* Get registers' physical base address */
-   host->phy_regs = regs->start;
host->regs = devm_ioremap_resource(>dev, regs);
if (IS_ERR(host->regs))
return PTR_ERR(host->regs);
 
+   /* Get registers' physical base address */
+   host->phy_regs = regs->start;
+
platform_set_drvdata(pdev, host);
return dw_mci_probe(host);
 }

[PATCH 4.4 50/69] drm/radeon/si_dpm: Limit clocks on HD86xx part

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Tom St Denis 

commit fb9a5b0c1c9893db2e0d18544fd49e19d784a87d upstream.

Limit clocks on a specific HD86xx part to avoid
crashes (while awaiting an appropriate PP fix).

Signed-off-by: Tom St Denis 
Reviewed-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/si_dpm.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3021,6 +3021,12 @@ static void si_apply_state_adjust_rules(
max_sclk = 75000;
max_mclk = 8;
}
+   /* limit clocks on HD8600 series */
+   if (rdev->pdev->device == 0x6660 &&
+   rdev->pdev->revision == 0x83) {
+   max_sclk = 75000;
+   max_mclk = 8;
+   }
 
if (rps->vce_active) {
rps->evclk = 
rdev->pm.dpm.vce_states[rdev->pm.dpm.vce_level].evclk;

Re: [PATCH v2] led: core: Use atomic bit-field for the blink-flags

[Jacek Anaszewski]

Since we've already agreed on keeping the flags in the leds.h,
then I'm applying this patch to the for-next branch of linux-leds.git.

Thanks,
Jacek Anaszewski

On 11/08/2016 02:58 PM, Jacek Anaszewski wrote:

From: Hans de Goede 

All the LED_BLINK* flags are accessed read-modify-write from e.g.
led_set_brightness and led_blink_set_oneshot while both
set_brightness_work and the blink_timer may be running.

If these race then the modify step done by one of them may be lost,
switch the LED_BLINK* flags to a new atomic work_flags bit-field
to avoid this race.

Signed-off-by: Hans de Goede 
Signed-off-by: Jacek Anaszewski 
---
Changes since v1:
- keep set_brightness_work in linux/leds.h

 drivers/leds/led-class.c |  1 +
 drivers/leds/led-core.c  | 52 +---
 include/linux/leds.h | 24 --
 3 files changed, 42 insertions(+), 35 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index c8d2d67..b12f861 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -212,6 +212,7 @@ int led_classdev_register(struct device *parent, struct 
led_classdev *led_cdev)
return -ENODEV;
}

+   led_cdev->work_flags = 0;
 #ifdef CONFIG_LEDS_TRIGGERS
init_rwsem(_cdev->trigger_lock);
 #endif
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index e2e5cc7..620257a 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -61,12 +61,13 @@ static void led_timer_function(unsigned long data)

if (!led_cdev->blink_delay_on || !led_cdev->blink_delay_off) {
led_set_brightness_nosleep(led_cdev, LED_OFF);
-   led_cdev->flags &= ~LED_BLINK_SW;
+   clear_bit(LED_BLINK_SW, _cdev->work_flags);
return;
}

-   if (led_cdev->flags & LED_BLINK_ONESHOT_STOP) {
-   led_cdev->flags &=  ~(LED_BLINK_ONESHOT_STOP | LED_BLINK_SW);
+   if (test_and_clear_bit(LED_BLINK_ONESHOT_STOP,
+  _cdev->work_flags)) {
+   clear_bit(LED_BLINK_SW, _cdev->work_flags);
return;
}

@@ -81,10 +82,9 @@ static void led_timer_function(unsigned long data)
 * Do it only if there is no pending blink brightness
 * change, to avoid overwriting the new value.
 */
-   if (!(led_cdev->flags & LED_BLINK_BRIGHTNESS_CHANGE))
+   if (!test_and_clear_bit(LED_BLINK_BRIGHTNESS_CHANGE,
+   _cdev->work_flags))
led_cdev->blink_brightness = brightness;
-   else
-   led_cdev->flags &= ~LED_BLINK_BRIGHTNESS_CHANGE;
brightness = LED_OFF;
delay = led_cdev->blink_delay_off;
}
@@ -95,13 +95,15 @@ static void led_timer_function(unsigned long data)
 * the final blink state so that the led is toggled each delay_on +
 * delay_off milliseconds in worst case.
 */
-   if (led_cdev->flags & LED_BLINK_ONESHOT) {
-   if (led_cdev->flags & LED_BLINK_INVERT) {
+   if (test_bit(LED_BLINK_ONESHOT, _cdev->work_flags)) {
+   if (test_bit(LED_BLINK_INVERT, _cdev->work_flags)) {
if (brightness)
-   led_cdev->flags |= LED_BLINK_ONESHOT_STOP;
+   set_bit(LED_BLINK_ONESHOT_STOP,
+   _cdev->work_flags);
} else {
if (!brightness)
-   led_cdev->flags |= LED_BLINK_ONESHOT_STOP;
+   set_bit(LED_BLINK_ONESHOT_STOP,
+   _cdev->work_flags);
}
}

@@ -114,10 +116,9 @@ static void set_brightness_delayed(struct work_struct *ws)
container_of(ws, struct led_classdev, set_brightness_work);
int ret = 0;

-   if (led_cdev->flags & LED_BLINK_DISABLE) {
+   if (test_and_clear_bit(LED_BLINK_DISABLE, _cdev->work_flags)) {
led_cdev->delayed_set_value = LED_OFF;
led_stop_software_blink(led_cdev);
-   led_cdev->flags &= ~LED_BLINK_DISABLE;
}

ret = __led_set_brightness(led_cdev, led_cdev->delayed_set_value);
@@ -160,7 +161,7 @@ static void led_set_software_blink(struct led_classdev 
*led_cdev,
return;
}

-   led_cdev->flags |= LED_BLINK_SW;
+   set_bit(LED_BLINK_SW, _cdev->work_flags);
mod_timer(_cdev->blink_timer, jiffies + 1);
 }

@@ -169,7 +170,7 @@ static void led_blink_setup(struct led_classdev *led_cdev,
 unsigned long *delay_on,
 unsigned long *delay_off)
 {
-   if (!(led_cdev->flags & LED_BLINK_ONESHOT) &&
+   if (!test_bit(LED_BLINK_ONESHOT, 

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

[Andy Lutomirski]

On Tue, Nov 8, 2016 at 8:25 PM, Ricardo Neri
 wrote:
> On Tue, 2016-11-08 at 07:32 -0800, Andy Lutomirski wrote:
>> > diff --git a/arch/x86/include/asm/disabled-features.h
>> b/arch/x86/include/asm/disabled-features.h
>> > index 85599ad..4707445 100644
>> > --- a/arch/x86/include/asm/disabled-features.h
>> > +++ b/arch/x86/include/asm/disabled-features.h
>> > @@ -16,6 +16,12 @@
>> >  # define DISABLE_MPX   (1<<(X86_FEATURE_MPX & 31))
>> >  #endif
>> >
>> > +#ifdef CONFIG_X86_INTEL_UMIP
>>
>> ^
>>
>> What's this?
>>
>> Let's try to do this with a minimum of configuration.
>
> My intention here is put in this file all the #if build configurations
> so that I don't have to put them other files by using functions such as
> cpu_feature_enable. Isn't this the intention of this file?

What I mean is: why does this need a config option at all?

--Andy

Re: [Ksummit-discuss] Including images on Sphinx documents

[Jani Nikula]

On Wed, 09 Nov 2016, Mauro Carvalho Chehab  wrote:
> Em Wed, 09 Nov 2016 13:16:55 +0200
> Jani Nikula  escreveu:
>
>> >> 1) copy (or symlink) all rst files to Documentation/output (or to the
>> >>  build dir specified via O= directive) and generate the *.pdf there,
>> >>  and produce those converted images via Makefile.;  
>> 
>> We're supposed to solve problems, not create new ones.
>
> So, what's your proposal?

Second message in the thread,
http://lkml.kernel.org/r/87wpgf8ssc@intel.com

>
> Thanks,
> Mauro
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 4.4 48/69] mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Jaehoon Chung 

commit 45c7a4908a307a023e237a64a3eadcafc4836493 upstream.

platform_get_resource can be returned the NULL pointer.
Then regs->start should be referred to NULL Pointer.
devm_ioremap_resource() checks whether res is NULL or not.

Signed-off-by: Jaehoon Chung 
Reviewed-by: Shawn Lin 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/dw_mmc-pltfm.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -59,12 +59,13 @@ int dw_mci_pltfm_register(struct platfor
host->pdata = pdev->dev.platform_data;
 
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   /* Get registers' physical base address */
-   host->phy_regs = regs->start;
host->regs = devm_ioremap_resource(>dev, regs);
if (IS_ERR(host->regs))
return PTR_ERR(host->regs);
 
+   /* Get registers' physical base address */
+   host->phy_regs = regs->start;
+
platform_set_drvdata(pdev, host);
return dw_mci_probe(host);
 }

[PATCH 4.4 50/69] drm/radeon/si_dpm: Limit clocks on HD86xx part

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Tom St Denis 

commit fb9a5b0c1c9893db2e0d18544fd49e19d784a87d upstream.

Limit clocks on a specific HD86xx part to avoid
crashes (while awaiting an appropriate PP fix).

Signed-off-by: Tom St Denis 
Reviewed-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/si_dpm.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3021,6 +3021,12 @@ static void si_apply_state_adjust_rules(
max_sclk = 75000;
max_mclk = 8;
}
+   /* limit clocks on HD8600 series */
+   if (rdev->pdev->device == 0x6660 &&
+   rdev->pdev->revision == 0x83) {
+   max_sclk = 75000;
+   max_mclk = 8;
+   }
 
if (rps->vce_active) {
rps->evclk = 
rdev->pm.dpm.vce_states[rdev->pm.dpm.vce_level].evclk;

Re: [PATCH v2] led: core: Use atomic bit-field for the blink-flags

[Jacek Anaszewski]

Since we've already agreed on keeping the flags in the leds.h,
then I'm applying this patch to the for-next branch of linux-leds.git.

Thanks,
Jacek Anaszewski

On 11/08/2016 02:58 PM, Jacek Anaszewski wrote:

From: Hans de Goede 

All the LED_BLINK* flags are accessed read-modify-write from e.g.
led_set_brightness and led_blink_set_oneshot while both
set_brightness_work and the blink_timer may be running.

If these race then the modify step done by one of them may be lost,
switch the LED_BLINK* flags to a new atomic work_flags bit-field
to avoid this race.

Signed-off-by: Hans de Goede 
Signed-off-by: Jacek Anaszewski 
---
Changes since v1:
- keep set_brightness_work in linux/leds.h

 drivers/leds/led-class.c |  1 +
 drivers/leds/led-core.c  | 52 +---
 include/linux/leds.h | 24 --
 3 files changed, 42 insertions(+), 35 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index c8d2d67..b12f861 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -212,6 +212,7 @@ int led_classdev_register(struct device *parent, struct 
led_classdev *led_cdev)
return -ENODEV;
}

+   led_cdev->work_flags = 0;
 #ifdef CONFIG_LEDS_TRIGGERS
init_rwsem(_cdev->trigger_lock);
 #endif
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index e2e5cc7..620257a 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -61,12 +61,13 @@ static void led_timer_function(unsigned long data)

if (!led_cdev->blink_delay_on || !led_cdev->blink_delay_off) {
led_set_brightness_nosleep(led_cdev, LED_OFF);
-   led_cdev->flags &= ~LED_BLINK_SW;
+   clear_bit(LED_BLINK_SW, _cdev->work_flags);
return;
}

-   if (led_cdev->flags & LED_BLINK_ONESHOT_STOP) {
-   led_cdev->flags &=  ~(LED_BLINK_ONESHOT_STOP | LED_BLINK_SW);
+   if (test_and_clear_bit(LED_BLINK_ONESHOT_STOP,
+  _cdev->work_flags)) {
+   clear_bit(LED_BLINK_SW, _cdev->work_flags);
return;
}

@@ -81,10 +82,9 @@ static void led_timer_function(unsigned long data)
 * Do it only if there is no pending blink brightness
 * change, to avoid overwriting the new value.
 */
-   if (!(led_cdev->flags & LED_BLINK_BRIGHTNESS_CHANGE))
+   if (!test_and_clear_bit(LED_BLINK_BRIGHTNESS_CHANGE,
+   _cdev->work_flags))
led_cdev->blink_brightness = brightness;
-   else
-   led_cdev->flags &= ~LED_BLINK_BRIGHTNESS_CHANGE;
brightness = LED_OFF;
delay = led_cdev->blink_delay_off;
}
@@ -95,13 +95,15 @@ static void led_timer_function(unsigned long data)
 * the final blink state so that the led is toggled each delay_on +
 * delay_off milliseconds in worst case.
 */
-   if (led_cdev->flags & LED_BLINK_ONESHOT) {
-   if (led_cdev->flags & LED_BLINK_INVERT) {
+   if (test_bit(LED_BLINK_ONESHOT, _cdev->work_flags)) {
+   if (test_bit(LED_BLINK_INVERT, _cdev->work_flags)) {
if (brightness)
-   led_cdev->flags |= LED_BLINK_ONESHOT_STOP;
+   set_bit(LED_BLINK_ONESHOT_STOP,
+   _cdev->work_flags);
} else {
if (!brightness)
-   led_cdev->flags |= LED_BLINK_ONESHOT_STOP;
+   set_bit(LED_BLINK_ONESHOT_STOP,
+   _cdev->work_flags);
}
}

@@ -114,10 +116,9 @@ static void set_brightness_delayed(struct work_struct *ws)
container_of(ws, struct led_classdev, set_brightness_work);
int ret = 0;

-   if (led_cdev->flags & LED_BLINK_DISABLE) {
+   if (test_and_clear_bit(LED_BLINK_DISABLE, _cdev->work_flags)) {
led_cdev->delayed_set_value = LED_OFF;
led_stop_software_blink(led_cdev);
-   led_cdev->flags &= ~LED_BLINK_DISABLE;
}

ret = __led_set_brightness(led_cdev, led_cdev->delayed_set_value);
@@ -160,7 +161,7 @@ static void led_set_software_blink(struct led_classdev 
*led_cdev,
return;
}

-   led_cdev->flags |= LED_BLINK_SW;
+   set_bit(LED_BLINK_SW, _cdev->work_flags);
mod_timer(_cdev->blink_timer, jiffies + 1);
 }

@@ -169,7 +170,7 @@ static void led_blink_setup(struct led_classdev *led_cdev,
 unsigned long *delay_on,
 unsigned long *delay_off)
 {
-   if (!(led_cdev->flags & LED_BLINK_ONESHOT) &&
+   if (!test_bit(LED_BLINK_ONESHOT, _cdev->work_flags) &&
led_cdev->blink_set &&

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

[Andy Lutomirski]

On Tue, Nov 8, 2016 at 8:25 PM, Ricardo Neri
 wrote:
> On Tue, 2016-11-08 at 07:32 -0800, Andy Lutomirski wrote:
>> > diff --git a/arch/x86/include/asm/disabled-features.h
>> b/arch/x86/include/asm/disabled-features.h
>> > index 85599ad..4707445 100644
>> > --- a/arch/x86/include/asm/disabled-features.h
>> > +++ b/arch/x86/include/asm/disabled-features.h
>> > @@ -16,6 +16,12 @@
>> >  # define DISABLE_MPX   (1<<(X86_FEATURE_MPX & 31))
>> >  #endif
>> >
>> > +#ifdef CONFIG_X86_INTEL_UMIP
>>
>> ^
>>
>> What's this?
>>
>> Let's try to do this with a minimum of configuration.
>
> My intention here is put in this file all the #if build configurations
> so that I don't have to put them other files by using functions such as
> cpu_feature_enable. Isn't this the intention of this file?

What I mean is: why does this need a config option at all?

--Andy

Re: [Ksummit-discuss] Including images on Sphinx documents

[Jani Nikula]

On Wed, 09 Nov 2016, Mauro Carvalho Chehab  wrote:
> Em Wed, 09 Nov 2016 13:16:55 +0200
> Jani Nikula  escreveu:
>
>> >> 1) copy (or symlink) all rst files to Documentation/output (or to the
>> >>  build dir specified via O= directive) and generate the *.pdf there,
>> >>  and produce those converted images via Makefile.;  
>> 
>> We're supposed to solve problems, not create new ones.
>
> So, what's your proposal?

Second message in the thread,
http://lkml.kernel.org/r/87wpgf8ssc@intel.com

>
> Thanks,
> Mauro
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

[Eric Engestrom]

On Wednesday, 2016-11-09 02:13:25 +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote:
> > > The function's behaviour was changed in 90844f00049e, without changing
> > > its signature, causing people to keep using it the old way without
> > > realising they were now leaking memory.
> > > Rob Clark also noticed it was also allocating GFP_KERNEL memory in
> > > atomic contexts, breaking them.
> > > 
> > > Instead of having to allocate GFP_ATOMIC memory and fixing the callers
> > > to make them cleanup the memory afterwards, let's change the function's
> > > signature by having the caller take care of the memory and passing it to
> > > the function.
> > > The new parameter is a single-field struct in order to enforce the size
> > > of its buffer and help callers to correctly manage their memory.
> > > 
> > > Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
> > > Cc: Rob Clark 
> > > Cc: Christian König 
> > > Acked-by: Christian König 
> > > Acked-by: Rob Clark 
> > > Acked-by: Sinclair Yeh  (vmwgfx)
> > > Reviewed-by: Jani Nikula 
> > > Suggested-by: Ville Syrjälä 
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > > v3 - fix "Fixes" tag, replace it with an actual commit message
> > >- collect ack & r-b
> > > 
> > > v2 - use single-field struct instead of typedef to let the compiler
> > >  enforce the type (Christian König)
> > 
> > Applied to drm-misc, thanks.
> 
> Well, had to drop it again since it didn't compile:
> 
> 
>   CC [M]  drivers/gpu/drm/drm_blend.o
> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’:
> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function 
> ‘drm_get_format_name’
>  drm_get_format_name(fb->pixel_format));
>  ^~~
> In file included from ./include/drm/drmP.h:71:0,
>  from drivers/gpu/drm/drm_atomic.c:29:
> ./include/drm/drm_fourcc.h:65:7: note: declared here
>  char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>^~~
> 
> Can you pls rebase onto drm-misc or linux-next or something?

That was based on airlied/drm-next (last fetched on Sunday I think),
I can rebase it on drm-misc if it helps, but it seems older than
drm-next.
Should I just rebase on top of current head of drm-next?

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

[Eric Engestrom]

On Wednesday, 2016-11-09 02:13:25 +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote:
> > > The function's behaviour was changed in 90844f00049e, without changing
> > > its signature, causing people to keep using it the old way without
> > > realising they were now leaking memory.
> > > Rob Clark also noticed it was also allocating GFP_KERNEL memory in
> > > atomic contexts, breaking them.
> > > 
> > > Instead of having to allocate GFP_ATOMIC memory and fixing the callers
> > > to make them cleanup the memory afterwards, let's change the function's
> > > signature by having the caller take care of the memory and passing it to
> > > the function.
> > > The new parameter is a single-field struct in order to enforce the size
> > > of its buffer and help callers to correctly manage their memory.
> > > 
> > > Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
> > > Cc: Rob Clark 
> > > Cc: Christian König 
> > > Acked-by: Christian König 
> > > Acked-by: Rob Clark 
> > > Acked-by: Sinclair Yeh  (vmwgfx)
> > > Reviewed-by: Jani Nikula 
> > > Suggested-by: Ville Syrjälä 
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > > v3 - fix "Fixes" tag, replace it with an actual commit message
> > >- collect ack & r-b
> > > 
> > > v2 - use single-field struct instead of typedef to let the compiler
> > >  enforce the type (Christian König)
> > 
> > Applied to drm-misc, thanks.
> 
> Well, had to drop it again since it didn't compile:
> 
> 
>   CC [M]  drivers/gpu/drm/drm_blend.o
> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’:
> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function 
> ‘drm_get_format_name’
>  drm_get_format_name(fb->pixel_format));
>  ^~~
> In file included from ./include/drm/drmP.h:71:0,
>  from drivers/gpu/drm/drm_atomic.c:29:
> ./include/drm/drm_fourcc.h:65:7: note: declared here
>  char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>^~~
> 
> Can you pls rebase onto drm-misc or linux-next or something?

That was based on airlied/drm-next (last fetched on Sunday I think),
I can rebase it on drm-misc if it helps, but it seems older than
drm-next.
Should I just rebase on top of current head of drm-next?

[PATCH 4.4 69/69] HID: usbhid: add ATEN CS962 to list of quirky devices

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Oliver Neukum 

commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream.

Like many similar devices it needs a quirk to work.
Issuing the request gets the device into an irrecoverable state.

Signed-off-by: Oliver Neukum 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-ids.h   |1 +
 drivers/hid/usbhid/hid-quirks.c |1 +
 2 files changed, 2 insertions(+)

--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -168,6 +168,7 @@
 #define USB_DEVICE_ID_ATEN_4PORTKVM0x2205
 #define USB_DEVICE_ID_ATEN_4PORTKVMC   0x2208
 #define USB_DEVICE_ID_ATEN_CS682   0x2213
+#define USB_DEVICE_ID_ATEN_CS692   0x8021
 
 #define USB_VENDOR_ID_ATMEL0x03eb
 #define USB_DEVICE_ID_ATMEL_MULTITOUCH 0x211c
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -61,6 +61,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVM, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVMC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS682, HID_QUIRK_NOGET },
+   { USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS692, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FIGHTERSTICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_COMBATSTICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FLIGHT_SIM_ECLIPSE_YOKE, 
HID_QUIRK_NOGET },

[PATCH 4.4 69/69] HID: usbhid: add ATEN CS962 to list of quirky devices

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Oliver Neukum 

commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream.

Like many similar devices it needs a quirk to work.
Issuing the request gets the device into an irrecoverable state.

Signed-off-by: Oliver Neukum 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-ids.h   |1 +
 drivers/hid/usbhid/hid-quirks.c |1 +
 2 files changed, 2 insertions(+)

--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -168,6 +168,7 @@
 #define USB_DEVICE_ID_ATEN_4PORTKVM0x2205
 #define USB_DEVICE_ID_ATEN_4PORTKVMC   0x2208
 #define USB_DEVICE_ID_ATEN_CS682   0x2213
+#define USB_DEVICE_ID_ATEN_CS692   0x8021
 
 #define USB_VENDOR_ID_ATMEL0x03eb
 #define USB_DEVICE_ID_ATMEL_MULTITOUCH 0x211c
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -61,6 +61,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVM, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVMC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS682, HID_QUIRK_NOGET },
+   { USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS692, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FIGHTERSTICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_COMBATSTICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FLIGHT_SIM_ECLIPSE_YOKE, 
HID_QUIRK_NOGET },

[PATCH 4.4 58/69] mm/cma: silence warnings due to max() usage

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Stephen Rothwell 

commit badbda53e505089062e194c614e6f23450bc98b2 upstream.

pageblock_order can be (at least) an unsigned int or an unsigned long
depending on the kernel config and architecture, so use max_t(unsigned
long, ...) when comparing it.

fixes these warnings:

In file included from include/asm-generic/bug.h:13:0,
 from arch/powerpc/include/asm/bug.h:127,
 from include/linux/bug.h:4,
 from include/linux/mmdebug.h:4,
 from include/linux/mm.h:8,
 from include/linux/memblock.h:18,
 from mm/cma.c:28:
mm/cma.c: In function 'cma_init_reserved_mem':
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types 
lacks a cast
  (void) (&_max1 == &_max2);   ^
mm/cma.c:186:27: note: in expansion of macro 'max'
  alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
   ^
mm/cma.c: In function 'cma_declare_contiguous':
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types 
lacks a cast
  (void) (&_max1 == &_max2);   ^
include/linux/kernel.h:747:9: note: in definition of macro 'max'
  typeof(y) _max2 = (y);^
mm/cma.c:270:29: note: in expansion of macro 'max'
   (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
 ^
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types 
lacks a cast
  (void) (&_max1 == &_max2);   ^
include/linux/kernel.h:747:21: note: in definition of macro 'max'
  typeof(y) _max2 = (y);^
mm/cma.c:270:29: note: in expansion of macro 'max'
   (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
 ^

[a...@linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20160526150748.5be38...@canb.auug.org.au
Signed-off-by: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/cma.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/mm/cma.c
+++ b/mm/cma.c
@@ -183,7 +183,8 @@ int __init cma_init_reserved_mem(phys_ad
return -EINVAL;
 
/* ensure minimal alignment required by mm core */
-   alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
+   alignment = PAGE_SIZE <<
+   max_t(unsigned long, MAX_ORDER - 1, pageblock_order);
 
/* alignment should be aligned with order_per_bit */
if (!IS_ALIGNED(alignment >> PAGE_SHIFT, 1 << order_per_bit))
@@ -266,8 +267,8 @@ int __init cma_declare_contiguous(phys_a
 * migratetype page by page allocator's buddy algorithm. In the case,
 * you couldn't get a contiguous memory, which is not what we want.
 */
-   alignment = max(alignment,
-   (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
+   alignment = max(alignment,  (phys_addr_t)PAGE_SIZE <<
+ max_t(unsigned long, MAX_ORDER - 1, pageblock_order));
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit &= ~(alignment - 1);

[PATCH 4.4 58/69] mm/cma: silence warnings due to max() usage

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Stephen Rothwell 

commit badbda53e505089062e194c614e6f23450bc98b2 upstream.

pageblock_order can be (at least) an unsigned int or an unsigned long
depending on the kernel config and architecture, so use max_t(unsigned
long, ...) when comparing it.

fixes these warnings:

In file included from include/asm-generic/bug.h:13:0,
 from arch/powerpc/include/asm/bug.h:127,
 from include/linux/bug.h:4,
 from include/linux/mmdebug.h:4,
 from include/linux/mm.h:8,
 from include/linux/memblock.h:18,
 from mm/cma.c:28:
mm/cma.c: In function 'cma_init_reserved_mem':
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types 
lacks a cast
  (void) (&_max1 == &_max2);   ^
mm/cma.c:186:27: note: in expansion of macro 'max'
  alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
   ^
mm/cma.c: In function 'cma_declare_contiguous':
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types 
lacks a cast
  (void) (&_max1 == &_max2);   ^
include/linux/kernel.h:747:9: note: in definition of macro 'max'
  typeof(y) _max2 = (y);^
mm/cma.c:270:29: note: in expansion of macro 'max'
   (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
 ^
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types 
lacks a cast
  (void) (&_max1 == &_max2);   ^
include/linux/kernel.h:747:21: note: in definition of macro 'max'
  typeof(y) _max2 = (y);^
mm/cma.c:270:29: note: in expansion of macro 'max'
   (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
 ^

[a...@linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20160526150748.5be38...@canb.auug.org.au
Signed-off-by: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/cma.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/mm/cma.c
+++ b/mm/cma.c
@@ -183,7 +183,8 @@ int __init cma_init_reserved_mem(phys_ad
return -EINVAL;
 
/* ensure minimal alignment required by mm core */
-   alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
+   alignment = PAGE_SIZE <<
+   max_t(unsigned long, MAX_ORDER - 1, pageblock_order);
 
/* alignment should be aligned with order_per_bit */
if (!IS_ALIGNED(alignment >> PAGE_SHIFT, 1 << order_per_bit))
@@ -266,8 +267,8 @@ int __init cma_declare_contiguous(phys_a
 * migratetype page by page allocator's buddy algorithm. In the case,
 * you couldn't get a contiguous memory, which is not what we want.
 */
-   alignment = max(alignment,
-   (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
+   alignment = max(alignment,  (phys_addr_t)PAGE_SIZE <<
+ max_t(unsigned long, MAX_ORDER - 1, pageblock_order));
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit &= ~(alignment - 1);

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

[liviu . dudau]

On Tue, Nov 08, 2016 at 11:47:08AM +0800, zhichang.yuan wrote:
> This patch solves two issues:
> 1) parse and get the right I/O range from DTS node whose parent does not
> define the corresponding ranges property;
> 
> There are some special ISA/LPC devices that work on a specific I/O range where
> it is not correct to specify a ranges property in DTS parent node as cpu
> addresses translated from DTS node are only for memory space on some
> architectures, such as Arm64. Without the parent 'ranges' property, current
> of_translate_address() return an error.
> Here we add a fixup function, of_get_isa_indirect_io(). During the OF address
> translation, this fixup will be called to check the 'reg' address to be
> translating is for those sepcial ISA/LPC devices and get the I/O range
> directly from the 'reg' property.
> 
> 2) eliminate the I/O range conflict risk with PCI/PCIE leagecy I/O device;
> 
> The current __of_address_to_resource() always translates the I/O range to PIO.
> But this processing is not suitable for our ISA/LPC devices whose I/O range is
> not cpu address(Arnd had stressed this in his comments on V2,V3 patch-set).
> Here, we bypass the mapping between cpu address and PIO for the special
> ISA/LPC devices. But to drive these ISA/LPC devices, a I/O port address below
> PCIBIOS_MIN_IO is needed by in*/out*(). Which means there is conflict risk
> between I/O range of [0, PCIBIOS_MIN_IO) and PCI/PCIE legacy I/O range of [0,
> IO_SPACE_LIMIT).
> To avoid the I/O conflict, this patch reserve the I/O range below
> PCIBIOS_MIN_IO.
> 
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> ---
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  | 31 
>  arch/arm64/include/asm/io.h|  6 +++
>  arch/arm64/kernel/extio.c  | 25 ++
>  drivers/of/address.c   | 56 
> +-
>  drivers/pci/pci.c  |  6 +--
>  include/linux/of_address.h | 17 +++
>  include/linux/pci.h|  8 
>  7 files changed, 145 insertions(+), 4 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 000..13c8ddd
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,31 @@
> +Hisilicon Hip06 low-pin-count device
> +  Usually LPC controller is part of PCI host bridge, so the legacy ISA ports
> +  locate on LPC bus can be accessed direclty. But some SoCs have independent
> +  LPC controller, and access the legacy ports by triggering LPC I/O cycles.
> +  Hisilicon Hip06 implements this LPC device.
> +
> +Required properties:
> +- compatible: should be "hisilicon,low-pin-count"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the register set of this device is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to 
> the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b {
> + compatible = "hisilicom,low-pin-count";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + status = "disabled";
> + };
> +};


This documentation file needs to be part of the next patch. It has nothing to 
do with
what you are trying to fix here.


> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 136735d..c26b7cc 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -175,6 +175,12 @@ static inline u64 __raw_readq(const volatile void 
> __iomem *addr)
>  #define outsl outsl
>  
>  DECLARE_EXTIO(l, u32)
> +
> +#define indirect_io_enabled indirect_io_enabled
> +extern bool indirect_io_enabled(void);
> +
> +#define addr_is_indirect_io addr_is_indirect_io
> +extern int addr_is_indirect_io(u64 taddr);
>  #endif
>  
>  
> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
> index 647b3fa..3d45fa8 100644
> --- a/arch/arm64/kernel/extio.c
> +++ b/arch/arm64/kernel/extio.c
> @@ -19,6 +19,31 @@
>  
>  struct extio_ops *arm64_extio_ops;
>  
> +/**
> + * indirect_io_enabled - check whether indirectIO is enabled.
> + *   arm64_extio_ops will be set only when indirectIO mechanism had been
> + *   initialized.
> + *
> + * Returns true when indirectIO is enabled.
> + */
> +bool indirect_io_enabled(void)
> +{
> 

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

[liviu . dudau]

On Tue, Nov 08, 2016 at 11:47:08AM +0800, zhichang.yuan wrote:
> This patch solves two issues:
> 1) parse and get the right I/O range from DTS node whose parent does not
> define the corresponding ranges property;
> 
> There are some special ISA/LPC devices that work on a specific I/O range where
> it is not correct to specify a ranges property in DTS parent node as cpu
> addresses translated from DTS node are only for memory space on some
> architectures, such as Arm64. Without the parent 'ranges' property, current
> of_translate_address() return an error.
> Here we add a fixup function, of_get_isa_indirect_io(). During the OF address
> translation, this fixup will be called to check the 'reg' address to be
> translating is for those sepcial ISA/LPC devices and get the I/O range
> directly from the 'reg' property.
> 
> 2) eliminate the I/O range conflict risk with PCI/PCIE leagecy I/O device;
> 
> The current __of_address_to_resource() always translates the I/O range to PIO.
> But this processing is not suitable for our ISA/LPC devices whose I/O range is
> not cpu address(Arnd had stressed this in his comments on V2,V3 patch-set).
> Here, we bypass the mapping between cpu address and PIO for the special
> ISA/LPC devices. But to drive these ISA/LPC devices, a I/O port address below
> PCIBIOS_MIN_IO is needed by in*/out*(). Which means there is conflict risk
> between I/O range of [0, PCIBIOS_MIN_IO) and PCI/PCIE legacy I/O range of [0,
> IO_SPACE_LIMIT).
> To avoid the I/O conflict, this patch reserve the I/O range below
> PCIBIOS_MIN_IO.
> 
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> ---
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  | 31 
>  arch/arm64/include/asm/io.h|  6 +++
>  arch/arm64/kernel/extio.c  | 25 ++
>  drivers/of/address.c   | 56 
> +-
>  drivers/pci/pci.c  |  6 +--
>  include/linux/of_address.h | 17 +++
>  include/linux/pci.h|  8 
>  7 files changed, 145 insertions(+), 4 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 000..13c8ddd
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,31 @@
> +Hisilicon Hip06 low-pin-count device
> +  Usually LPC controller is part of PCI host bridge, so the legacy ISA ports
> +  locate on LPC bus can be accessed direclty. But some SoCs have independent
> +  LPC controller, and access the legacy ports by triggering LPC I/O cycles.
> +  Hisilicon Hip06 implements this LPC device.
> +
> +Required properties:
> +- compatible: should be "hisilicon,low-pin-count"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the register set of this device is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to 
> the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b {
> + compatible = "hisilicom,low-pin-count";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + status = "disabled";
> + };
> +};


This documentation file needs to be part of the next patch. It has nothing to 
do with
what you are trying to fix here.


> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 136735d..c26b7cc 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -175,6 +175,12 @@ static inline u64 __raw_readq(const volatile void 
> __iomem *addr)
>  #define outsl outsl
>  
>  DECLARE_EXTIO(l, u32)
> +
> +#define indirect_io_enabled indirect_io_enabled
> +extern bool indirect_io_enabled(void);
> +
> +#define addr_is_indirect_io addr_is_indirect_io
> +extern int addr_is_indirect_io(u64 taddr);
>  #endif
>  
>  
> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
> index 647b3fa..3d45fa8 100644
> --- a/arch/arm64/kernel/extio.c
> +++ b/arch/arm64/kernel/extio.c
> @@ -19,6 +19,31 @@
>  
>  struct extio_ops *arm64_extio_ops;
>  
> +/**
> + * indirect_io_enabled - check whether indirectIO is enabled.
> + *   arm64_extio_ops will be set only when indirectIO mechanism had been
> + *   initialized.
> + *
> + * Returns true when indirectIO is enabled.
> + */
> +bool indirect_io_enabled(void)
> +{
> + return arm64_extio_ops ? true : false;
> +}
> +
> 

[PATCH 4.4 44/69] mac80211: discard multicast and 4-addr A-MSDUs

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Johannes Berg 

commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream.

In mac80211, multicast A-MSDUs are accepted in many cases that
they shouldn't be accepted in:
 * drop A-MSDUs with a multicast A1 (RA), as required by the
   spec in 9.11 (802.11-2012 version)
 * drop A-MSDUs with a 4-addr header, since the fourth address
   can't actually be useful for them; unless 4-address frame
   format is actually requested, even though the fourth address
   is still not useful in this case, but ignored

Accepting the first case, in particular, is very problematic
since it allows anyone else with possession of a GTK to send
unicast frames encapsulated in a multicast A-MSDU, even when
the AP has client isolation enabled.

Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman 

---
 net/mac80211/rx.c |   24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2203,16 +2203,22 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx
if (!(status->rx_flags & IEEE80211_RX_AMSDU))
return RX_CONTINUE;
 
-   if (ieee80211_has_a4(hdr->frame_control) &&
-   rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
-   !rx->sdata->u.vlan.sta)
-   return RX_DROP_UNUSABLE;
+   if (unlikely(ieee80211_has_a4(hdr->frame_control))) {
+   switch (rx->sdata->vif.type) {
+   case NL80211_IFTYPE_AP_VLAN:
+   if (!rx->sdata->u.vlan.sta)
+   return RX_DROP_UNUSABLE;
+   break;
+   case NL80211_IFTYPE_STATION:
+   if (!rx->sdata->u.mgd.use_4addr)
+   return RX_DROP_UNUSABLE;
+   break;
+   default:
+   return RX_DROP_UNUSABLE;
+   }
+   }
 
-   if (is_multicast_ether_addr(hdr->addr1) &&
-   ((rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- rx->sdata->u.vlan.sta) ||
-(rx->sdata->vif.type == NL80211_IFTYPE_STATION &&
- rx->sdata->u.mgd.use_4addr)))
+   if (is_multicast_ether_addr(hdr->addr1))
return RX_DROP_UNUSABLE;
 
skb->dev = dev;

[PATCH 4.4 44/69] mac80211: discard multicast and 4-addr A-MSDUs

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Johannes Berg 

commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream.

In mac80211, multicast A-MSDUs are accepted in many cases that
they shouldn't be accepted in:
 * drop A-MSDUs with a multicast A1 (RA), as required by the
   spec in 9.11 (802.11-2012 version)
 * drop A-MSDUs with a 4-addr header, since the fourth address
   can't actually be useful for them; unless 4-address frame
   format is actually requested, even though the fourth address
   is still not useful in this case, but ignored

Accepting the first case, in particular, is very problematic
since it allows anyone else with possession of a GTK to send
unicast frames encapsulated in a multicast A-MSDU, even when
the AP has client isolation enabled.

Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman 

---
 net/mac80211/rx.c |   24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2203,16 +2203,22 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx
if (!(status->rx_flags & IEEE80211_RX_AMSDU))
return RX_CONTINUE;
 
-   if (ieee80211_has_a4(hdr->frame_control) &&
-   rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
-   !rx->sdata->u.vlan.sta)
-   return RX_DROP_UNUSABLE;
+   if (unlikely(ieee80211_has_a4(hdr->frame_control))) {
+   switch (rx->sdata->vif.type) {
+   case NL80211_IFTYPE_AP_VLAN:
+   if (!rx->sdata->u.vlan.sta)
+   return RX_DROP_UNUSABLE;
+   break;
+   case NL80211_IFTYPE_STATION:
+   if (!rx->sdata->u.mgd.use_4addr)
+   return RX_DROP_UNUSABLE;
+   break;
+   default:
+   return RX_DROP_UNUSABLE;
+   }
+   }
 
-   if (is_multicast_ether_addr(hdr->addr1) &&
-   ((rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- rx->sdata->u.vlan.sta) ||
-(rx->sdata->vif.type == NL80211_IFTYPE_STATION &&
- rx->sdata->u.mgd.use_4addr)))
+   if (is_multicast_ether_addr(hdr->addr1))
return RX_DROP_UNUSABLE;
 
skb->dev = dev;

[PATCH 4.4 63/69] UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Boris Brezillon 

commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.

scan_pool() does not mark the PEB for scrubing when bitflips are
detected in the EC header of a free PEB (VID header region left to
0xff).
Make sure we scrub the PEB in this case.

Signed-off-by: Boris Brezillon 
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mtd/ubi/fastmap.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -513,10 +513,11 @@ static int scan_pool(struct ubi_device *
unsigned long long ec = be64_to_cpu(ech->ec);
unmap_peb(ai, pnum);
dbg_bld("Adding PEB to free: %i", pnum);
+
if (err == UBI_IO_FF_BITFLIPS)
-   add_aeb(ai, free, pnum, ec, 1);
-   else
-   add_aeb(ai, free, pnum, ec, 0);
+   scrub = 1;
+
+   add_aeb(ai, free, pnum, ec, scrub);
continue;
} else if (err == 0 || err == UBI_IO_BITFLIPS) {
dbg_bld("Found non empty PEB:%i in pool", pnum);

[PATCH 4.4 56/69] powerpc/ptrace: Fix out of bounds array access warning

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Khem Raj 

commit 1e407ee3b21f981140491d5b8a36422979ca246f upstream.

gcc-6 correctly warns about a out of bounds access

arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset 
greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' 
[-Warray-bounds]
offsetof(struct thread_fp_state, fpr[32][0]));
^

check the end of array instead of beginning of next element to fix this

Signed-off-by: Khem Raj 
Cc: Kees Cook 
Cc: Michael Ellerman 
Cc: Segher Boessenkool 
Tested-by: Aaro Koskinen 
Acked-by: Olof Johansson 
Signed-off-by: Michael Ellerman 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kernel/ptrace.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -376,7 +376,7 @@ static int fpr_get(struct task_struct *t
 
 #else
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
-offsetof(struct thread_fp_state, fpr[32][0]));
+offsetof(struct thread_fp_state, fpr[32]));
 
return user_regset_copyout(, , , ,
   >thread.fp_state, 0, -1);
@@ -404,7 +404,7 @@ static int fpr_set(struct task_struct *t
return 0;
 #else
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
-offsetof(struct thread_fp_state, fpr[32][0]));
+offsetof(struct thread_fp_state, fpr[32]));
 
return user_regset_copyin(, , , ,
  >thread.fp_state, 0, -1);

Re: [PATCH v10 4/7] x86/syscalls/32: Wire up arch_prctl on x86-32

[Borislav Petkov]

On Tue, Nov 08, 2016 at 10:39:53AM -0800, Kyle Huey wrote:
> Hook up arch_prctl to call do_arch_prctl on x86-32, and in 32 bit compat
> mode on x86-64. This allows us to have arch_prctls that are not specific to

function_name()

> 64 bits.
> 
> On UML, simply stub out this syscall.
> 
> Signed-off-by: Kyle Huey 

...

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH 4.4 41/69] Input: i8042 - add XMG C504 to keyboard reset table

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Patrick Scheuring 

commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream.

The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop.
Therefore it also needs a keyboard reset to detect the Elantech touchpad.
Otherwise the touchpad appears to be dead.

With this patch the touchpad is detected:

$ dmesg | grep -E "(i8042|Elantech|elantech)"

[2.675399] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 
0x60,0x64 irq 1,12
[2.680372] i8042: Attempting to reset device connected to KBD port
[2.789037] serio: i8042 KBD port at 0x60,0x64 irq 1
[2.791586] serio: i8042 AUX port at 0x60,0x64 irq 12
[2.813840] input: AT Translated Set 2 keyboard as 
/devices/platform/i8042/serio0/input/input4
[3.811431] psmouse serio1: elantech: assuming hardware version 4 (with 
firmware version 0x361f0e)
[3.825424] psmouse serio1: elantech: Synaptics capabilities query result 
0x00, 0x15, 0x0f.
[3.839424] psmouse serio1: elantech: Elan sample query result 03, 58, 74
[3.911349] input: ETPS/2 Elantech Touchpad as 
/devices/platform/i8042/serio1/input/input6

Signed-off-by: Patrick Scheuring 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/serio/i8042-x86ia64io.h |7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -877,6 +877,13 @@ static const struct dmi_system_id __init
DMI_MATCH(DMI_PRODUCT_NAME, "P34"),
},
},
+   {
+   /* Schenker XMG C504 - Elantech touchpad */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "XMG"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "C504"),
+   },
+   },
{ }
 };
 

[PATCH 4.4 40/69] dm mirror: fix read error on recovery after default leg failure

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Heinz Mauelshagen 

commit dcb2ff56417362c31f6b430c3c531a84581e8721 upstream.

If a default leg has failed, any read will cause a new operational
default leg to be selected and the read is resubmitted.  But until now
the read will return failure even though it was successful due to
resubmission.  The reason for this is bio->bi_error was not being
cleared before resubmitting the bio.

Fix by clearing bio->bi_error before resubmission.

Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio")
Signed-off-by: Heinz Mauelshagen 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-raid1.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -1288,6 +1288,7 @@ static int mirror_end_io(struct dm_targe
 
dm_bio_restore(bd, bio);
bio_record->details.bi_bdev = NULL;
+   bio->bi_error = 0;
 
queue_bio(ms, bio, rw);
return DM_ENDIO_INCOMPLETE;

[PATCH 4.4 64/69] pwm: Unexport children before chip removal

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: David Hsu 

commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream.

Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.

Signed-off-by: David Hsu 
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pwm/core.c  |2 ++
 drivers/pwm/sysfs.c |   18 ++
 include/linux/pwm.h |5 +
 3 files changed, 25 insertions(+)

--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -321,6 +321,8 @@ int pwmchip_remove(struct pwm_chip *chip
unsigned int i;
int ret = 0;
 
+   pwmchip_sysfs_unexport_children(chip);
+
mutex_lock(_lock);
 
for (i = 0; i < chip->npwm; i++) {
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -350,6 +350,24 @@ void pwmchip_sysfs_unexport(struct pwm_c
}
 }
 
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+   struct device *parent;
+   unsigned int i;
+
+   parent = class_find_device(_class, NULL, chip,
+  pwmchip_sysfs_match);
+   if (!parent)
+   return;
+
+   for (i = 0; i < chip->npwm; i++) {
+   struct pwm_device *pwm = >pwms[i];
+
+   if (test_bit(PWMF_EXPORTED, >flags))
+   pwm_unexport_child(parent, pwm);
+   }
+}
+
 static int __init pwm_sysfs_init(void)
 {
return class_register(_class);
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -331,6 +331,7 @@ static inline void pwm_remove_table(stru
 #ifdef CONFIG_PWM_SYSFS
 void pwmchip_sysfs_export(struct pwm_chip *chip);
 void pwmchip_sysfs_unexport(struct pwm_chip *chip);
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip);
 #else
 static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
 {
@@ -339,6 +340,10 @@ static inline void pwmchip_sysfs_export(
 static inline void pwmchip_sysfs_unexport(struct pwm_chip *chip)
 {
 }
+
+static inline void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+}
 #endif /* CONFIG_PWM_SYSFS */
 
 #endif /* __LINUX_PWM_H */

[PATCH 4.4 43/69] firewire: net: fix fragmented datagram_size off-by-one

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefan Richter 

commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream.

RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:

datagram_size:  The encoded size of the entire IP datagram.  The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).

Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:

ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;

ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;

Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.

Only firewire-net sets and gets datagram_size without this offset.  The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394.  (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
  - from OS X fail entirely,
  - from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.

So let's fix firewire-net's datagram_size accessors.

Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed.  (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)

Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firewire/net.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -73,13 +73,13 @@ struct rfc2734_header {
 
 #define fwnet_get_hdr_lf(h)(((h)->w0 & 0xc000) >> 30)
 #define fwnet_get_hdr_ether_type(h)(((h)->w0 & 0x))
-#define fwnet_get_hdr_dg_size(h)   (((h)->w0 & 0x0fff) >> 16)
+#define fwnet_get_hdr_dg_size(h)   h)->w0 & 0x0fff) >> 16) + 1)
 #define fwnet_get_hdr_fg_off(h)(((h)->w0 & 0x0fff))
 #define fwnet_get_hdr_dgl(h)   (((h)->w1 & 0x) >> 16)
 
-#define fwnet_set_hdr_lf(lf)   ((lf)  << 30)
+#define fwnet_set_hdr_lf(lf)   ((lf) << 30)
 #define fwnet_set_hdr_ether_type(et)   (et)
-#define fwnet_set_hdr_dg_size(dgs) ((dgs) << 16)
+#define fwnet_set_hdr_dg_size(dgs) (((dgs) - 1) << 16)
 #define fwnet_set_hdr_fg_off(fgo)  (fgo)
 
 #define fwnet_set_hdr_dgl(dgl) ((dgl) << 16)
@@ -622,7 +622,7 @@ static int fwnet_incoming_packet(struct
fg_off = fwnet_get_hdr_fg_off();
}
datagram_label = fwnet_get_hdr_dgl();
-   dg_size = fwnet_get_hdr_dg_size(); /* ??? + 1 */
+   dg_size = fwnet_get_hdr_dg_size();
 
if (fg_off + len > dg_size)
return 0;

[PATCH 4.4 63/69] UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Boris Brezillon 

commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.

scan_pool() does not mark the PEB for scrubing when bitflips are
detected in the EC header of a free PEB (VID header region left to
0xff).
Make sure we scrub the PEB in this case.

Signed-off-by: Boris Brezillon 
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mtd/ubi/fastmap.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -513,10 +513,11 @@ static int scan_pool(struct ubi_device *
unsigned long long ec = be64_to_cpu(ech->ec);
unmap_peb(ai, pnum);
dbg_bld("Adding PEB to free: %i", pnum);
+
if (err == UBI_IO_FF_BITFLIPS)
-   add_aeb(ai, free, pnum, ec, 1);
-   else
-   add_aeb(ai, free, pnum, ec, 0);
+   scrub = 1;
+
+   add_aeb(ai, free, pnum, ec, scrub);
continue;
} else if (err == 0 || err == UBI_IO_BITFLIPS) {
dbg_bld("Found non empty PEB:%i in pool", pnum);

[PATCH 4.4 56/69] powerpc/ptrace: Fix out of bounds array access warning

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Khem Raj 

commit 1e407ee3b21f981140491d5b8a36422979ca246f upstream.

gcc-6 correctly warns about a out of bounds access

arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset 
greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' 
[-Warray-bounds]
offsetof(struct thread_fp_state, fpr[32][0]));
^

check the end of array instead of beginning of next element to fix this

Signed-off-by: Khem Raj 
Cc: Kees Cook 
Cc: Michael Ellerman 
Cc: Segher Boessenkool 
Tested-by: Aaro Koskinen 
Acked-by: Olof Johansson 
Signed-off-by: Michael Ellerman 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kernel/ptrace.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -376,7 +376,7 @@ static int fpr_get(struct task_struct *t
 
 #else
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
-offsetof(struct thread_fp_state, fpr[32][0]));
+offsetof(struct thread_fp_state, fpr[32]));
 
return user_regset_copyout(, , , ,
   >thread.fp_state, 0, -1);
@@ -404,7 +404,7 @@ static int fpr_set(struct task_struct *t
return 0;
 #else
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
-offsetof(struct thread_fp_state, fpr[32][0]));
+offsetof(struct thread_fp_state, fpr[32]));
 
return user_regset_copyin(, , , ,
  >thread.fp_state, 0, -1);

Re: [PATCH v10 4/7] x86/syscalls/32: Wire up arch_prctl on x86-32

[Borislav Petkov]

On Tue, Nov 08, 2016 at 10:39:53AM -0800, Kyle Huey wrote:
> Hook up arch_prctl to call do_arch_prctl on x86-32, and in 32 bit compat
> mode on x86-64. This allows us to have arch_prctls that are not specific to

function_name()

> 64 bits.
> 
> On UML, simply stub out this syscall.
> 
> Signed-off-by: Kyle Huey 

...

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH 4.4 41/69] Input: i8042 - add XMG C504 to keyboard reset table

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Patrick Scheuring 

commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream.

The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop.
Therefore it also needs a keyboard reset to detect the Elantech touchpad.
Otherwise the touchpad appears to be dead.

With this patch the touchpad is detected:

$ dmesg | grep -E "(i8042|Elantech|elantech)"

[2.675399] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 
0x60,0x64 irq 1,12
[2.680372] i8042: Attempting to reset device connected to KBD port
[2.789037] serio: i8042 KBD port at 0x60,0x64 irq 1
[2.791586] serio: i8042 AUX port at 0x60,0x64 irq 12
[2.813840] input: AT Translated Set 2 keyboard as 
/devices/platform/i8042/serio0/input/input4
[3.811431] psmouse serio1: elantech: assuming hardware version 4 (with 
firmware version 0x361f0e)
[3.825424] psmouse serio1: elantech: Synaptics capabilities query result 
0x00, 0x15, 0x0f.
[3.839424] psmouse serio1: elantech: Elan sample query result 03, 58, 74
[3.911349] input: ETPS/2 Elantech Touchpad as 
/devices/platform/i8042/serio1/input/input6

Signed-off-by: Patrick Scheuring 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/serio/i8042-x86ia64io.h |7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -877,6 +877,13 @@ static const struct dmi_system_id __init
DMI_MATCH(DMI_PRODUCT_NAME, "P34"),
},
},
+   {
+   /* Schenker XMG C504 - Elantech touchpad */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "XMG"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "C504"),
+   },
+   },
{ }
 };
 

[PATCH 4.4 40/69] dm mirror: fix read error on recovery after default leg failure

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Heinz Mauelshagen 

commit dcb2ff56417362c31f6b430c3c531a84581e8721 upstream.

If a default leg has failed, any read will cause a new operational
default leg to be selected and the read is resubmitted.  But until now
the read will return failure even though it was successful due to
resubmission.  The reason for this is bio->bi_error was not being
cleared before resubmitting the bio.

Fix by clearing bio->bi_error before resubmission.

Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio")
Signed-off-by: Heinz Mauelshagen 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-raid1.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -1288,6 +1288,7 @@ static int mirror_end_io(struct dm_targe
 
dm_bio_restore(bd, bio);
bio_record->details.bi_bdev = NULL;
+   bio->bi_error = 0;
 
queue_bio(ms, bio, rw);
return DM_ENDIO_INCOMPLETE;

[PATCH 4.4 64/69] pwm: Unexport children before chip removal

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: David Hsu 

commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream.

Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.

Signed-off-by: David Hsu 
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pwm/core.c  |2 ++
 drivers/pwm/sysfs.c |   18 ++
 include/linux/pwm.h |5 +
 3 files changed, 25 insertions(+)

--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -321,6 +321,8 @@ int pwmchip_remove(struct pwm_chip *chip
unsigned int i;
int ret = 0;
 
+   pwmchip_sysfs_unexport_children(chip);
+
mutex_lock(_lock);
 
for (i = 0; i < chip->npwm; i++) {
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -350,6 +350,24 @@ void pwmchip_sysfs_unexport(struct pwm_c
}
 }
 
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+   struct device *parent;
+   unsigned int i;
+
+   parent = class_find_device(_class, NULL, chip,
+  pwmchip_sysfs_match);
+   if (!parent)
+   return;
+
+   for (i = 0; i < chip->npwm; i++) {
+   struct pwm_device *pwm = >pwms[i];
+
+   if (test_bit(PWMF_EXPORTED, >flags))
+   pwm_unexport_child(parent, pwm);
+   }
+}
+
 static int __init pwm_sysfs_init(void)
 {
return class_register(_class);
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -331,6 +331,7 @@ static inline void pwm_remove_table(stru
 #ifdef CONFIG_PWM_SYSFS
 void pwmchip_sysfs_export(struct pwm_chip *chip);
 void pwmchip_sysfs_unexport(struct pwm_chip *chip);
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip);
 #else
 static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
 {
@@ -339,6 +340,10 @@ static inline void pwmchip_sysfs_export(
 static inline void pwmchip_sysfs_unexport(struct pwm_chip *chip)
 {
 }
+
+static inline void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+}
 #endif /* CONFIG_PWM_SYSFS */
 
 #endif /* __LINUX_PWM_H */

[PATCH 4.4 43/69] firewire: net: fix fragmented datagram_size off-by-one

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefan Richter 

commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream.

RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:

datagram_size:  The encoded size of the entire IP datagram.  The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).

Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:

ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;

ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;

Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.

Only firewire-net sets and gets datagram_size without this offset.  The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394.  (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
  - from OS X fail entirely,
  - from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.

So let's fix firewire-net's datagram_size accessors.

Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed.  (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)

Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firewire/net.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -73,13 +73,13 @@ struct rfc2734_header {
 
 #define fwnet_get_hdr_lf(h)(((h)->w0 & 0xc000) >> 30)
 #define fwnet_get_hdr_ether_type(h)(((h)->w0 & 0x))
-#define fwnet_get_hdr_dg_size(h)   (((h)->w0 & 0x0fff) >> 16)
+#define fwnet_get_hdr_dg_size(h)   h)->w0 & 0x0fff) >> 16) + 1)
 #define fwnet_get_hdr_fg_off(h)(((h)->w0 & 0x0fff))
 #define fwnet_get_hdr_dgl(h)   (((h)->w1 & 0x) >> 16)
 
-#define fwnet_set_hdr_lf(lf)   ((lf)  << 30)
+#define fwnet_set_hdr_lf(lf)   ((lf) << 30)
 #define fwnet_set_hdr_ether_type(et)   (et)
-#define fwnet_set_hdr_dg_size(dgs) ((dgs) << 16)
+#define fwnet_set_hdr_dg_size(dgs) (((dgs) - 1) << 16)
 #define fwnet_set_hdr_fg_off(fgo)  (fgo)
 
 #define fwnet_set_hdr_dgl(dgl) ((dgl) << 16)
@@ -622,7 +622,7 @@ static int fwnet_incoming_packet(struct
fg_off = fwnet_get_hdr_fg_off();
}
datagram_label = fwnet_get_hdr_dgl();
-   dg_size = fwnet_get_hdr_dg_size(); /* ??? + 1 */
+   dg_size = fwnet_get_hdr_dg_size();
 
if (fg_off + len > dg_size)
return 0;

Re: [PATCH net-next 1/2] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path

[Daniel Borkmann]

On 11/09/2016 11:58 AM, kbuild test robot wrote:
[...]

All errors (new ones prefixed by >>):

drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function 'mlx4_xdp_set':

drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2752:4: error: implicit 
declaration of function 'bpf_prog_add_undo' 
[-Werror=implicit-function-declaration]

bpf_prog_add_undo(prog, priv->rx_ring_num - 1);
^
cc1: some warnings being treated as errors


Ahh right, needs an empty variant for !CONFIG_BPF_SYSCALL. I'll fix that up
before sending an official patch.

Thanks,
Daniel

[PATCH 4.4 68/69] ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Boris Brezillon 

commit 40b6e61ac72e99672e47cdb99c8d7d226004169b upstream.

Commit e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already
exists") introduced a bug by changing the possible error codes returned
by add_vol():
- this function no longer returns NULL in case of allocation failure
  but return ERR_PTR(-ENOMEM)
- when a duplicate entry in the volume RB tree is found it returns
  ERR_PTR(-EEXIST) instead of ERR_PTR(-EINVAL)

Fix the tests done on add_vol() return val to match this new behavior.

Fixes: e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already exists")
Reported-by: Dan Carpenter 
Signed-off-by: Boris Brezillon 
Acked-by: Sheng Yong 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mtd/ubi/fastmap.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -749,11 +749,11 @@ static int ubi_attach_fastmap(struct ubi
 fmvhdr->vol_type,
 be32_to_cpu(fmvhdr->last_eb_bytes));
 
-   if (!av)
-   goto fail_bad;
-   if (PTR_ERR(av) == -EINVAL) {
-   ubi_err(ubi, "volume (ID %i) already exists",
-   fmvhdr->vol_id);
+   if (IS_ERR(av)) {
+   if (PTR_ERR(av) == -EEXIST)
+   ubi_err(ubi, "volume (ID %i) already exists",
+   fmvhdr->vol_id);
+
goto fail_bad;
}
 

[PATCH 4.4 59/69] drm/exynos: fix error handling in exynos_drm_subdrv_open

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 55c4b906aa2aec3fa66310ec03c6842e34a04b2a upstream.

gcc-6 warns about a pointless loop in exynos_drm_subdrv_open:

drivers/gpu/drm/exynos/exynos_drm_core.c: In function 'exynos_drm_subdrv_open':
drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: error: self-comparison always 
evaluates to false [-Werror=tautological-compare]
  list_for_each_entry_reverse(subdrv, >list, list) {

Here, the list_for_each_entry_reverse immediately terminates because
the subdrv pointer is compared to itself as the loop end condition.

If we were to take the current subdrv pointer as the start of the
list (as we would do if list_for_each_entry_reverse() was not a macro),
we would iterate backwards over the _drm_subdrv_list anchor,
which would be even worse.

Instead, we need to use list_for_each_entry_continue_reverse()
to go back over each subdrv that was successfully opened until
the first entry.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Inki Dae 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/exynos/exynos_drm_core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -101,7 +101,7 @@ int exynos_drm_subdrv_open(struct drm_de
return 0;
 
 err:
-   list_for_each_entry_reverse(subdrv, >list, list) {
+   list_for_each_entry_continue_reverse(subdrv, _drm_subdrv_list, 
list) {
if (subdrv->close)
subdrv->close(dev, subdrv->dev, file);
}

[PATCH 4.4 59/69] drm/exynos: fix error handling in exynos_drm_subdrv_open

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 55c4b906aa2aec3fa66310ec03c6842e34a04b2a upstream.

gcc-6 warns about a pointless loop in exynos_drm_subdrv_open:

drivers/gpu/drm/exynos/exynos_drm_core.c: In function 'exynos_drm_subdrv_open':
drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: error: self-comparison always 
evaluates to false [-Werror=tautological-compare]
  list_for_each_entry_reverse(subdrv, >list, list) {

Here, the list_for_each_entry_reverse immediately terminates because
the subdrv pointer is compared to itself as the loop end condition.

If we were to take the current subdrv pointer as the start of the
list (as we would do if list_for_each_entry_reverse() was not a macro),
we would iterate backwards over the _drm_subdrv_list anchor,
which would be even worse.

Instead, we need to use list_for_each_entry_continue_reverse()
to go back over each subdrv that was successfully opened until
the first entry.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Inki Dae 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/exynos/exynos_drm_core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -101,7 +101,7 @@ int exynos_drm_subdrv_open(struct drm_de
return 0;
 
 err:
-   list_for_each_entry_reverse(subdrv, >list, list) {
+   list_for_each_entry_continue_reverse(subdrv, _drm_subdrv_list, 
list) {
if (subdrv->close)
subdrv->close(dev, subdrv->dev, file);
}

Re: [PATCH net-next 1/2] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path

[Daniel Borkmann]

On 11/09/2016 11:58 AM, kbuild test robot wrote:
[...]

All errors (new ones prefixed by >>):

drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function 'mlx4_xdp_set':

drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2752:4: error: implicit 
declaration of function 'bpf_prog_add_undo' 
[-Werror=implicit-function-declaration]

bpf_prog_add_undo(prog, priv->rx_ring_num - 1);
^
cc1: some warnings being treated as errors


Ahh right, needs an empty variant for !CONFIG_BPF_SYSCALL. I'll fix that up
before sending an official patch.

Thanks,
Daniel

[PATCH 4.4 68/69] ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Boris Brezillon 

commit 40b6e61ac72e99672e47cdb99c8d7d226004169b upstream.

Commit e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already
exists") introduced a bug by changing the possible error codes returned
by add_vol():
- this function no longer returns NULL in case of allocation failure
  but return ERR_PTR(-ENOMEM)
- when a duplicate entry in the volume RB tree is found it returns
  ERR_PTR(-EEXIST) instead of ERR_PTR(-EINVAL)

Fix the tests done on add_vol() return val to match this new behavior.

Fixes: e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already exists")
Reported-by: Dan Carpenter 
Signed-off-by: Boris Brezillon 
Acked-by: Sheng Yong 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mtd/ubi/fastmap.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -749,11 +749,11 @@ static int ubi_attach_fastmap(struct ubi
 fmvhdr->vol_type,
 be32_to_cpu(fmvhdr->last_eb_bytes));
 
-   if (!av)
-   goto fail_bad;
-   if (PTR_ERR(av) == -EINVAL) {
-   ubi_err(ubi, "volume (ID %i) already exists",
-   fmvhdr->vol_id);
+   if (IS_ERR(av)) {
+   if (PTR_ERR(av) == -EEXIST)
+   ubi_err(ubi, "volume (ID %i) already exists",
+   fmvhdr->vol_id);
+
goto fail_bad;
}
 

[PATCH 4.4 61/69] smc91x: avoid self-comparison warning

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit e3ebd894f084255fde19116955ba7054858ff5d6 upstream.

The smc91x driver defines a macro that compares its argument to
itself, apparently to get a true result while using its argument
to avoid a warning about unused local variables.

Unfortunately, this triggers a warning with gcc-6, as the comparison
is obviously useless:

drivers/net/ethernet/smsc/smc91x.c: In function 'smc_hardware_send_pkt':
drivers/net/ethernet/smsc/smc91x.c:563:14: error: self-comparison always 
evaluates to true [-Werror=tautological-compare]
  if (!smc_special_trylock(>lock, flags)) {

This replaces the macro with another one that behaves similarly,
with a cast to (void) to ensure the argument is used, and using
a literal 'true' as its value.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/ethernet/smsc/smc91x.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -540,7 +540,7 @@ static inline void  smc_rcv(struct net_d
 #define smc_special_lock(lock, flags)  spin_lock_irqsave(lock, flags)
 #define smc_special_unlock(lock, flags)spin_unlock_irqrestore(lock, 
flags)
 #else
-#define smc_special_trylock(lock, flags)   (flags == flags)
+#define smc_special_trylock(lock, flags)   ((void)flags, true)
 #define smc_special_lock(lock, flags)  do { flags = 0; } while (0)
 #define smc_special_unlock(lock, flags)do { flags = 0; } while (0)
 #endif

[PATCH 4.8 011/138] gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Lars-Peter Clausen 

commit e405f9fcb63602d35f7a419ededa3f952a395a72 upstream.

The line offset that is used as an index into the descs array is provided
by userspace and might go beyond the bounds of the array. If that happens
undefined behavior will occur.

Make sure that the offset is within the bounds of the desc array and reject
any requests that specify a value outside of it.

Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpiolib.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -442,6 +442,11 @@ static int linehandle_create(struct gpio
u32 lflags = handlereq.flags;
struct gpio_desc *desc;
 
+   if (offset >= gdev->ngpio) {
+   ret = -EINVAL;
+   goto out_free_descs;
+   }
+
desc = >descs[offset];
ret = gpiod_request(desc, lh->label);
if (ret)

[PATCH 4.4 55/69] x86/xen: fix upper bound of pmd loop in xen_cleanhighmap()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Juergen Gross 

commit 1cf38741308c64d08553602b3374fb39224eeb5a upstream.

xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper
bound of the loop setting non-kernel-image entries to zero should not
exceed the size of level2_kernel_pgt.

Reported-by: Linus Torvalds 
Signed-off-by: Juergen Gross 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/xen/mmu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1113,7 +1113,7 @@ static void __init xen_cleanhighmap(unsi
 
/* NOTE: The loop is more greedy than the cleanup_highmap variant.
 * We include the PMD passed in on _both_ boundaries. */
-   for (; vaddr <= vaddr_end && (pmd < (level2_kernel_pgt + PAGE_SIZE));
+   for (; vaddr <= vaddr_end && (pmd < (level2_kernel_pgt + PTRS_PER_PMD));
pmd++, vaddr += PMD_SIZE) {
if (pmd_none(*pmd))
continue;

[PATCH 4.4 61/69] smc91x: avoid self-comparison warning

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit e3ebd894f084255fde19116955ba7054858ff5d6 upstream.

The smc91x driver defines a macro that compares its argument to
itself, apparently to get a true result while using its argument
to avoid a warning about unused local variables.

Unfortunately, this triggers a warning with gcc-6, as the comparison
is obviously useless:

drivers/net/ethernet/smsc/smc91x.c: In function 'smc_hardware_send_pkt':
drivers/net/ethernet/smsc/smc91x.c:563:14: error: self-comparison always 
evaluates to true [-Werror=tautological-compare]
  if (!smc_special_trylock(>lock, flags)) {

This replaces the macro with another one that behaves similarly,
with a cast to (void) to ensure the argument is used, and using
a literal 'true' as its value.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/ethernet/smsc/smc91x.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -540,7 +540,7 @@ static inline void  smc_rcv(struct net_d
 #define smc_special_lock(lock, flags)  spin_lock_irqsave(lock, flags)
 #define smc_special_unlock(lock, flags)spin_unlock_irqrestore(lock, 
flags)
 #else
-#define smc_special_trylock(lock, flags)   (flags == flags)
+#define smc_special_trylock(lock, flags)   ((void)flags, true)
 #define smc_special_lock(lock, flags)  do { flags = 0; } while (0)
 #define smc_special_unlock(lock, flags)do { flags = 0; } while (0)
 #endif

[PATCH 4.8 011/138] gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Lars-Peter Clausen 

commit e405f9fcb63602d35f7a419ededa3f952a395a72 upstream.

The line offset that is used as an index into the descs array is provided
by userspace and might go beyond the bounds of the array. If that happens
undefined behavior will occur.

Make sure that the offset is within the bounds of the desc array and reject
any requests that specify a value outside of it.

Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpiolib.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -442,6 +442,11 @@ static int linehandle_create(struct gpio
u32 lflags = handlereq.flags;
struct gpio_desc *desc;
 
+   if (offset >= gdev->ngpio) {
+   ret = -EINVAL;
+   goto out_free_descs;
+   }
+
desc = >descs[offset];
ret = gpiod_request(desc, lh->label);
if (ret)

[PATCH 4.4 55/69] x86/xen: fix upper bound of pmd loop in xen_cleanhighmap()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Juergen Gross 

commit 1cf38741308c64d08553602b3374fb39224eeb5a upstream.

xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper
bound of the loop setting non-kernel-image entries to zero should not
exceed the size of level2_kernel_pgt.

Reported-by: Linus Torvalds 
Signed-off-by: Juergen Gross 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/xen/mmu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1113,7 +1113,7 @@ static void __init xen_cleanhighmap(unsi
 
/* NOTE: The loop is more greedy than the cleanup_highmap variant.
 * We include the PMD passed in on _both_ boundaries. */
-   for (; vaddr <= vaddr_end && (pmd < (level2_kernel_pgt + PAGE_SIZE));
+   for (; vaddr <= vaddr_end && (pmd < (level2_kernel_pgt + PTRS_PER_PMD));
pmd++, vaddr += PMD_SIZE) {
if (pmd_none(*pmd))
continue;