Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Michel Dänzer]

On 18/04/17 02:04 PM, Ilia Mirkin wrote:
> On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer  wrote:
>> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin  wrote:
> However, I totally agree with Alex that someone with a BE machine
> should review the whole stack before we could be confident with anything.

 Here's what I'm confident about: xf86-video-nouveau worked just fine
 on top of kernel 4.3 on an AGP GeForce FX 5200 (with AGPGART turned
 off because ... well ... uninorth). fbcon/fbdev accel worked,
 xf86-video-nouveau's 2d accel worked, and simple demos (ala glxgears)
 worked after I fixed up mesa and nv30 driver items in version ... 11.1
 it seems. As I recall it had gotten all broken in 10.0 or so by Adam
 Jackson in the name of making llvmpipe work on BE, declaring all other
 drivers broken, with various fixes by Michel Dänzer to get it back to
 working over the years.

 Anyone "fixing" the stack has to maintain that level of functioning
 through their various fixing.

 I will double-check that the above still works with the latest
 kernel/xorg/xf86-video-nouveau/mesa and report back (hopefully by this
 weekend). If there are any patches you'd like me to test, now's the
 time to ask -- getting the box up and running is the hard part,
 booting up an extra kernel -- easy.
>>>
>>> OK, so I revived my PowerMac7,3 G5 setup (PPC64 BE, NV34 GPU). Booted
>>> it with an upstream 4.11-rc7 kernel, loaded up the nouveau kernel
>>> module (which is included in that kernel), updated X to 1.19.2 and
>>> mesa to 17.0.3. Everything works fine. Specifically:
>>>
>>> fbcon on top of fbdev provided by nouveau -- colors are fine
>>> glxgears hw-accelerated by mesa on top of xf86-video-nouveau using
>>> DRI2 -- colors are fine
>>> glxgears softpipe-accelerated by mesa on top of xf86-video-nouveau --
>>> colors are fine
>>> glxgears softpipe-accelerated by mesa on top of xf86-video-modesetting
>>> -- colors are fine
>>> xterm on top of xf86-video-nouveau -- colors are fine
>>> xterm on top of xf86-video-modesetting -- colors are fine
>>>
>>> I couldn't test anything with GLAMOR since GLAMOR requires GL 2.1 or
>>> higher, whereas nouveau's NV3x acceleration only provides GL 1.5 (due
>>> to lacking NPOT and a handful of other things).
>>>
>>> The modetest utility did have trouble with AR24 and I'm pretty sure
>>> the XR24 pattern was off too. However I wouldn't be surprised if the
>>> modetest utility itself had endian issues in the pattern generation
>>> logic. (Seems to be the case, based on a quick glance at the
>>> tests/util/format.c logic and how it's used in pattern.c.)
>>>
>>> So in short, I think the current definitions of format are fine.
>>
>> I agree with Pekka that it's not that simple. What you've established is
>> that things look fine after going through several layers of abstraction.
>> It's possible that multiple bugs in those layers cancel each other out;
>> in particular, it's quite likely that the code dealing with DRM formats
>> is treating them as using native endianness (one possible giveaway for
>> that is using shifts for (un)packing colour components).
> 
> Quite true that this proves nothing. However one should note that
> fbcon -> fbdev works,

BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
native endian packed colour values.


> and both mesa hw driver and softpipe driver work, in addition to regular
> DDX accel.

Similarly, the X11 protocol uses native endian packed colour values.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Michel Dänzer]

On 18/04/17 02:04 PM, Ilia Mirkin wrote:
> On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer  wrote:
>> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin  wrote:
> However, I totally agree with Alex that someone with a BE machine
> should review the whole stack before we could be confident with anything.

 Here's what I'm confident about: xf86-video-nouveau worked just fine
 on top of kernel 4.3 on an AGP GeForce FX 5200 (with AGPGART turned
 off because ... well ... uninorth). fbcon/fbdev accel worked,
 xf86-video-nouveau's 2d accel worked, and simple demos (ala glxgears)
 worked after I fixed up mesa and nv30 driver items in version ... 11.1
 it seems. As I recall it had gotten all broken in 10.0 or so by Adam
 Jackson in the name of making llvmpipe work on BE, declaring all other
 drivers broken, with various fixes by Michel Dänzer to get it back to
 working over the years.

 Anyone "fixing" the stack has to maintain that level of functioning
 through their various fixing.

 I will double-check that the above still works with the latest
 kernel/xorg/xf86-video-nouveau/mesa and report back (hopefully by this
 weekend). If there are any patches you'd like me to test, now's the
 time to ask -- getting the box up and running is the hard part,
 booting up an extra kernel -- easy.
>>>
>>> OK, so I revived my PowerMac7,3 G5 setup (PPC64 BE, NV34 GPU). Booted
>>> it with an upstream 4.11-rc7 kernel, loaded up the nouveau kernel
>>> module (which is included in that kernel), updated X to 1.19.2 and
>>> mesa to 17.0.3. Everything works fine. Specifically:
>>>
>>> fbcon on top of fbdev provided by nouveau -- colors are fine
>>> glxgears hw-accelerated by mesa on top of xf86-video-nouveau using
>>> DRI2 -- colors are fine
>>> glxgears softpipe-accelerated by mesa on top of xf86-video-nouveau --
>>> colors are fine
>>> glxgears softpipe-accelerated by mesa on top of xf86-video-modesetting
>>> -- colors are fine
>>> xterm on top of xf86-video-nouveau -- colors are fine
>>> xterm on top of xf86-video-modesetting -- colors are fine
>>>
>>> I couldn't test anything with GLAMOR since GLAMOR requires GL 2.1 or
>>> higher, whereas nouveau's NV3x acceleration only provides GL 1.5 (due
>>> to lacking NPOT and a handful of other things).
>>>
>>> The modetest utility did have trouble with AR24 and I'm pretty sure
>>> the XR24 pattern was off too. However I wouldn't be surprised if the
>>> modetest utility itself had endian issues in the pattern generation
>>> logic. (Seems to be the case, based on a quick glance at the
>>> tests/util/format.c logic and how it's used in pattern.c.)
>>>
>>> So in short, I think the current definitions of format are fine.
>>
>> I agree with Pekka that it's not that simple. What you've established is
>> that things look fine after going through several layers of abstraction.
>> It's possible that multiple bugs in those layers cancel each other out;
>> in particular, it's quite likely that the code dealing with DRM formats
>> is treating them as using native endianness (one possible giveaway for
>> that is using shifts for (un)packing colour components).
> 
> Quite true that this proves nothing. However one should note that
> fbcon -> fbdev works,

BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
native endian packed colour values.


> and both mesa hw driver and softpipe driver work, in addition to regular
> DDX accel.

Similarly, the X11 protocol uses native endian packed colour values.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [PATCH v2 2/3] drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board

[Andrzej Hajda]

On 17.04.2017 08:02, Hoegeun Kwon wrote:
> This patch supports TM2e panel and the panel has 1600x2560 resolution
> in 5.65" physical.
>
> This identify panel type with compatibility string, also invoke
> display mode that matches the type. So add the check code for s6e3ha2
> compatibility and s6e3hf2 type and select the drm_display_mode of
> default and edge type.
>
> Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

Re: [PATCH v2 2/3] drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board

[Andrzej Hajda]

On 17.04.2017 08:02, Hoegeun Kwon wrote:
> This patch supports TM2e panel and the panel has 1600x2560 resolution
> in 5.65" physical.
>
> This identify panel type with compatibility string, also invoke
> display mode that matches the type. So add the check code for s6e3ha2
> compatibility and s6e3hf2 type and select the drm_display_mode of
> default and edge type.
>
> Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

Re: linux-next: build failure after merge of the staging tree

[Greg KH]

On Tue, Apr 18, 2017 at 03:32:20PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> make[7]: *** No rule to make target 
> 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o',
>  needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'.  Stop.
> 
> Caused by commit
> 
>   7afe8f84f793 ("atomisp: remove UDS kernel code")
> 
> I have used the staging tree from next-20170413 for today.

Ok, the 0-day bot reported something odd like this, with Alan's original
patches, but I couldn't reproduce it, and then when I applied them, the
0-day bot worked just fine.  But now you are having the same issue.

I'm totally confused, Alan, any ideas?

thanks,

greg k-h

Re: linux-next: build failure after merge of the staging tree

[Greg KH]

On Tue, Apr 18, 2017 at 03:32:20PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> make[7]: *** No rule to make target 
> 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o',
>  needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'.  Stop.
> 
> Caused by commit
> 
>   7afe8f84f793 ("atomisp: remove UDS kernel code")
> 
> I have used the staging tree from next-20170413 for today.

Ok, the 0-day bot reported something odd like this, with Alan's original
patches, but I couldn't reproduce it, and then when I applied them, the
0-day bot worked just fine.  But now you are having the same issue.

I'm totally confused, Alan, any ideas?

thanks,

greg k-h

linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi all,

After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3426:25: error: 
initialization from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  .change_virtual_intf = cfg80211_rtw_change_iface,
 ^
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3426:25: note: (near 
initialization for 'rtw_cfg80211_ops.change_virtual_intf')
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3445:22: error: 
initialization from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  .add_virtual_intf = cfg80211_rtw_add_virtual_intf,
  ^
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3445:22: note: (near 
initialization for 'rtw_cfg80211_ops.add_virtual_intf')

Caused by commit

  554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")

interacting with commit

  818a986e4eba ("cfg80211: move add/change interface monitor flags into params")

from the mac80211-next tree.

I have added the following merge fix patch:

From: Stephen Rothwell 
Date: Tue, 18 Apr 2017 15:43:43 +1000
Subject: [PATCH] staging: merge fix for add/change_virtual-intf API change

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index 52aa65bfd890..f17f4fbd3396 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1310,7 +1310,7 @@ extern int netdev_open(struct net_device *pnetdev);
 
 static int cfg80211_rtw_change_iface(struct wiphy *wiphy,
 struct net_device *ndev,
-enum nl80211_iftype type, u32 *flags,
+enum nl80211_iftype type,
 struct vif_params *params)
 {
enum nl80211_iftype old_type;
@@ -2711,7 +2711,7 @@ static struct wireless_dev *
struct wiphy *wiphy,
const char *name,
unsigned char name_assign_type,
-   enum nl80211_iftype type, u32 *flags, struct vif_params *params)
+   enum nl80211_iftype type, struct vif_params *params)
 {
int ret = 0;
struct net_device* ndev = NULL;
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi all,

After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3426:25: error: 
initialization from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  .change_virtual_intf = cfg80211_rtw_change_iface,
 ^
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3426:25: note: (near 
initialization for 'rtw_cfg80211_ops.change_virtual_intf')
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3445:22: error: 
initialization from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  .add_virtual_intf = cfg80211_rtw_add_virtual_intf,
  ^
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3445:22: note: (near 
initialization for 'rtw_cfg80211_ops.add_virtual_intf')

Caused by commit

  554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")

interacting with commit

  818a986e4eba ("cfg80211: move add/change interface monitor flags into params")

from the mac80211-next tree.

I have added the following merge fix patch:

From: Stephen Rothwell 
Date: Tue, 18 Apr 2017 15:43:43 +1000
Subject: [PATCH] staging: merge fix for add/change_virtual-intf API change

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index 52aa65bfd890..f17f4fbd3396 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1310,7 +1310,7 @@ extern int netdev_open(struct net_device *pnetdev);
 
 static int cfg80211_rtw_change_iface(struct wiphy *wiphy,
 struct net_device *ndev,
-enum nl80211_iftype type, u32 *flags,
+enum nl80211_iftype type,
 struct vif_params *params)
 {
enum nl80211_iftype old_type;
@@ -2711,7 +2711,7 @@ static struct wireless_dev *
struct wiphy *wiphy,
const char *name,
unsigned char name_assign_type,
-   enum nl80211_iftype type, u32 *flags, struct vif_params *params)
+   enum nl80211_iftype type, struct vif_params *params)
 {
int ret = 0;
struct net_device* ndev = NULL;
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v2 1/3] dt-bindings: Add support for samsung s6e3hf2 panel

[Andrzej Hajda]

On 17.04.2017 08:02, Hoegeun Kwon wrote:
> The samsung s6e3hf2 panel is a 5.65" 1600x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
>
> The s6e3hf2 is add to samsung,s6e3ha2.txt binding because it is a
> panel similar to the s6e3ha2. So add the compatible string and
> comments.
>
> Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

Re: [PATCH v2 1/3] dt-bindings: Add support for samsung s6e3hf2 panel

[Andrzej Hajda]

On 17.04.2017 08:02, Hoegeun Kwon wrote:
> The samsung s6e3hf2 panel is a 5.65" 1600x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
>
> The s6e3hf2 is add to samsung,s6e3ha2.txt binding because it is a
> panel similar to the s6e3ha2. So add the compatible string and
> comments.
>
> Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

Linux 3.12.73

[Jiri Slaby]

I'm announcing the release of the 3.12.73 kernel.

All users of the 3.12 kernel series must upgrade.

The updated 3.12.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.12.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary


Adrian Hunter (1):
  mmc: sdhci: Do not disable interrupts while waiting for clock

Akinobu Mita (2):
  Input: mpr121 - handle multiple bits change of status register
  Input: mpr121 - set missing event capability

Alan Stern (2):
  USB: fix linked-list corruption in rh_call_control()
  USB: OHCI: Fix race between ED unlink and URB submission

Alex Hung (1):
  ACPI / video: skip evaluating _DOD when it does not exist

Alexander Potapenko (1):
  net: don't call strlen() on the user buffer in packet_bind_spkt()

Andi Kleen (1):
  kernek/fork.c: allocate idle task for a CPU always on its local node

Andrew Lunn (1):
  ipv4: igmp: Allow removing groups from a removed interface

Andrey Ulanov (1):
  net: unix: properly re-increment inflight counter of GC discarded 
candidates

Andy Whitcroft (2):
  xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window
  xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder

Anton Blanchard (1):
  scsi: lpfc: Add shutdown method for kexec

Ardinartsev Nikita (1):
  HID: hid-lg: Fix immediate disconnection of Logitech Rumblepad 2

Arnaldo Carvalho de Melo (1):
  dccp: Unlock sock before calling sk_free()

Arnd Bergmann (5):
  crypto: improve gcc optimization flags for serpent and wp512
  MIPS: ip27: Disable qlge driver in defconfig
  MIPS: ip22: Fix ip28 build for modern gcc
  mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy
  cpmac: remove hopeless #warning

Bjørn Mork (4):
  qmi_wwan: add Dell DW5811e
  USB: qcserial: add Sierra Wireless MC74xx/EM74xx
  USB: qcserial: add Sierra Wireless EM74xx device ID
  USB: serial: qcserial: add Dell DW5811e

Brendan McGrath (1):
  HID: i2c-hid: Add sleep between POWER ON and RESET

Brian Foster (1):
  xfs: pass total block res. as total xfs_bmapi_write() parameter

Chris J Arges (1):
  igb: Workaround for igb i210 firmware issue

Colin Ian King (1):
  HID: usbhid: Quirk a AMI virtual mouse and keyboard with ALWAYS_POLL

Dan Carpenter (1):
  ACPI / resources: free memory on error in add_region_before()

Dan Streetman (1):
  xen: do not re-use pirq number cached in pci device msi msg data

Dan Williams (1):
  USB: serial: option: add Quectel UC15, UC20, EC21, and EC25 modems

Darrick J. Wong (2):
  xfs: don't allow di_size with high bit set
  xfs: clear _XBF_PAGES from buffers when readahead page

Dave Martin (5):
  c6x/ptrace: Remove useless PTRACE_SETREGSET implementation
  sparc/ptrace: Preserve previous registers for short regset write
  metag/ptrace: Preserve previous registers for short regset write
  metag/ptrace: Provide default TXSTATUS for short NT_PRSTATUS
  metag/ptrace: Reject partial NT_METAG_RPIPE writes

David Hildenbrand (1):
  KVM: kvm_io_bus_unregister_dev() should never fail

David Ward (1):
  USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module

Dmitry V. Levin (1):
  uapi: fix linux/packet_diag.h userspace compilation error

Eric Biggers (1):
  ext4: mark inode dirty after converting inline directory

Eric Dumazet (5):
  net: net_enable_timestamp() can be called from irq contexts
  tcp: fix various issues for sockets morphing to listen state
  net: properly release sk_frag.page
  ipv4: provide stronger user input validation in nl_fib_input()
  tcp: initialize icsk_ack.lrcvtime at session start time

Eric Sandeen (1):
  xfs: fix up xfs_swap_extent_forks inline extent handling

Felipe Balbi (1):
  usb: dwc3: gadget: make Set Endpoint Configuration macros safe

Florian Westphal (2):
  ipv6: avoid write to a possibly cloned skb
  netlink: remove mmapped netlink support

Guenter Roeck (2):
  usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci 
controllers
  usb: hub: Fix crash after failure to read BOS descriptor

Hannes Frederic Sowa (1):
  dccp: fix memory leak during tear-down of unsuccessful connection request

Ilya Dryomov (2):
  libceph: don't set weight to IN when OSD is destroyed
  libceph: force GFP_NOIO for socket allocations

James Bottomley (1):
  scsi: mpt3sas: fix hang on ata passthrough commands

Jason A. Donenfeld (1):
  padata: avoid race in reordering

Jiri Slaby (2):
  crypto: algif_hash - avoid zero-sized array
  Linux 3.12.73

Johan Hovold (22):
  USB: serial: digi_acceleport: fix OOB data sanity check
  USB: serial: digi_acceleport: fix OOB-event processing
  USB: 

Linux 3.12.73

[Jiri Slaby]

I'm announcing the release of the 3.12.73 kernel.

All users of the 3.12 kernel series must upgrade.

The updated 3.12.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.12.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary


Adrian Hunter (1):
  mmc: sdhci: Do not disable interrupts while waiting for clock

Akinobu Mita (2):
  Input: mpr121 - handle multiple bits change of status register
  Input: mpr121 - set missing event capability

Alan Stern (2):
  USB: fix linked-list corruption in rh_call_control()
  USB: OHCI: Fix race between ED unlink and URB submission

Alex Hung (1):
  ACPI / video: skip evaluating _DOD when it does not exist

Alexander Potapenko (1):
  net: don't call strlen() on the user buffer in packet_bind_spkt()

Andi Kleen (1):
  kernek/fork.c: allocate idle task for a CPU always on its local node

Andrew Lunn (1):
  ipv4: igmp: Allow removing groups from a removed interface

Andrey Ulanov (1):
  net: unix: properly re-increment inflight counter of GC discarded 
candidates

Andy Whitcroft (2):
  xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window
  xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder

Anton Blanchard (1):
  scsi: lpfc: Add shutdown method for kexec

Ardinartsev Nikita (1):
  HID: hid-lg: Fix immediate disconnection of Logitech Rumblepad 2

Arnaldo Carvalho de Melo (1):
  dccp: Unlock sock before calling sk_free()

Arnd Bergmann (5):
  crypto: improve gcc optimization flags for serpent and wp512
  MIPS: ip27: Disable qlge driver in defconfig
  MIPS: ip22: Fix ip28 build for modern gcc
  mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy
  cpmac: remove hopeless #warning

Bjørn Mork (4):
  qmi_wwan: add Dell DW5811e
  USB: qcserial: add Sierra Wireless MC74xx/EM74xx
  USB: qcserial: add Sierra Wireless EM74xx device ID
  USB: serial: qcserial: add Dell DW5811e

Brendan McGrath (1):
  HID: i2c-hid: Add sleep between POWER ON and RESET

Brian Foster (1):
  xfs: pass total block res. as total xfs_bmapi_write() parameter

Chris J Arges (1):
  igb: Workaround for igb i210 firmware issue

Colin Ian King (1):
  HID: usbhid: Quirk a AMI virtual mouse and keyboard with ALWAYS_POLL

Dan Carpenter (1):
  ACPI / resources: free memory on error in add_region_before()

Dan Streetman (1):
  xen: do not re-use pirq number cached in pci device msi msg data

Dan Williams (1):
  USB: serial: option: add Quectel UC15, UC20, EC21, and EC25 modems

Darrick J. Wong (2):
  xfs: don't allow di_size with high bit set
  xfs: clear _XBF_PAGES from buffers when readahead page

Dave Martin (5):
  c6x/ptrace: Remove useless PTRACE_SETREGSET implementation
  sparc/ptrace: Preserve previous registers for short regset write
  metag/ptrace: Preserve previous registers for short regset write
  metag/ptrace: Provide default TXSTATUS for short NT_PRSTATUS
  metag/ptrace: Reject partial NT_METAG_RPIPE writes

David Hildenbrand (1):
  KVM: kvm_io_bus_unregister_dev() should never fail

David Ward (1):
  USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module

Dmitry V. Levin (1):
  uapi: fix linux/packet_diag.h userspace compilation error

Eric Biggers (1):
  ext4: mark inode dirty after converting inline directory

Eric Dumazet (5):
  net: net_enable_timestamp() can be called from irq contexts
  tcp: fix various issues for sockets morphing to listen state
  net: properly release sk_frag.page
  ipv4: provide stronger user input validation in nl_fib_input()
  tcp: initialize icsk_ack.lrcvtime at session start time

Eric Sandeen (1):
  xfs: fix up xfs_swap_extent_forks inline extent handling

Felipe Balbi (1):
  usb: dwc3: gadget: make Set Endpoint Configuration macros safe

Florian Westphal (2):
  ipv6: avoid write to a possibly cloned skb
  netlink: remove mmapped netlink support

Guenter Roeck (2):
  usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci 
controllers
  usb: hub: Fix crash after failure to read BOS descriptor

Hannes Frederic Sowa (1):
  dccp: fix memory leak during tear-down of unsuccessful connection request

Ilya Dryomov (2):
  libceph: don't set weight to IN when OSD is destroyed
  libceph: force GFP_NOIO for socket allocations

James Bottomley (1):
  scsi: mpt3sas: fix hang on ata passthrough commands

Jason A. Donenfeld (1):
  padata: avoid race in reordering

Jiri Slaby (2):
  crypto: algif_hash - avoid zero-sized array
  Linux 3.12.73

Johan Hovold (22):
  USB: serial: digi_acceleport: fix OOB data sanity check
  USB: serial: digi_acceleport: fix OOB-event processing
  USB: 

[PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

[Hoeun Ryu]

 vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area
during boot process and those virtually mapped areas are never unmapped.
So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing
existing vmlist entries and prevent those areas from being removed from the
rbtree by accident. This flags can be also used by other vmalloc APIs to
specify that the area will never go away.
 This makes remove_vm_area() more robust against other kind of errors (eg.
programming errors).

Signed-off-by: Hoeun Ryu 
---
v2:
 - update changelog
 - add description to VM_STATIC
 - check VM_STATIC first before VM_VM_AREA in remove_vm_area()

 include/linux/vmalloc.h | 7 +++
 mm/vmalloc.c| 9 ++---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 46991ad..a42c210 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -19,6 +19,13 @@ struct notifier_block;   /* in notifier.h */
 #define VM_UNINITIALIZED   0x0020  /* vm_struct is not fully 
initialized */
 #define VM_NO_GUARD0x0040  /* don't add guard page */
 #define VM_KASAN   0x0080  /* has allocated kasan shadow 
memory */
+/*
+ * static area, vmap_area will never go away.
+ * This flag is OR-ed automatically in vmalloc_init() if the area is inserted
+ * by vm_area_add_early()/vm_area_register_early() during early boot process
+ * or you can give this flag manually using other vmalloc APIs.
+ */
+#define VM_STATIC  0x0200
 /* bits [20..32] reserved for arch specific ioremap internals */
 
 /*
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 8ef8ea1..6bc6c39 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1262,7 +1262,7 @@ void __init vmalloc_init(void)
/* Import existing vmlist entries. */
for (tmp = vmlist; tmp; tmp = tmp->next) {
va = kzalloc(sizeof(struct vmap_area), GFP_NOWAIT);
-   va->flags = VM_VM_AREA;
+   va->flags = VM_VM_AREA | VM_STATIC;
va->va_start = (unsigned long)tmp->addr;
va->va_end = va->va_start + tmp->size;
va->vm = tmp;
@@ -1480,7 +1480,7 @@ struct vm_struct *remove_vm_area(const void *addr)
might_sleep();
 
va = find_vmap_area((unsigned long)addr);
-   if (va && va->flags & VM_VM_AREA) {
+   if (va && likely(!(va->flags & VM_STATIC)) && va->flags & VM_VM_AREA) {
struct vm_struct *vm = va->vm;
 
spin_lock(_area_lock);
@@ -1510,7 +1510,7 @@ static void __vunmap(const void *addr, int 
deallocate_pages)
 
area = remove_vm_area(addr);
if (unlikely(!area)) {
-   WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n",
+   WARN(1, KERN_ERR "Trying to vfree() nonexistent or static vm 
area (%p)\n",
addr);
return;
}
@@ -2708,6 +2708,9 @@ static int s_show(struct seq_file *m, void *p)
if (v->phys_addr)
seq_printf(m, " phys=%pa", >phys_addr);
 
+   if (v->flags & VM_STATIC)
+   seq_puts(m, " static");
+
if (v->flags & VM_IOREMAP)
seq_puts(m, " ioremap");
 
-- 
2.7.4

[PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

[Hoeun Ryu]

 vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area
during boot process and those virtually mapped areas are never unmapped.
So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing
existing vmlist entries and prevent those areas from being removed from the
rbtree by accident. This flags can be also used by other vmalloc APIs to
specify that the area will never go away.
 This makes remove_vm_area() more robust against other kind of errors (eg.
programming errors).

Signed-off-by: Hoeun Ryu 
---
v2:
 - update changelog
 - add description to VM_STATIC
 - check VM_STATIC first before VM_VM_AREA in remove_vm_area()

 include/linux/vmalloc.h | 7 +++
 mm/vmalloc.c| 9 ++---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 46991ad..a42c210 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -19,6 +19,13 @@ struct notifier_block;   /* in notifier.h */
 #define VM_UNINITIALIZED   0x0020  /* vm_struct is not fully 
initialized */
 #define VM_NO_GUARD0x0040  /* don't add guard page */
 #define VM_KASAN   0x0080  /* has allocated kasan shadow 
memory */
+/*
+ * static area, vmap_area will never go away.
+ * This flag is OR-ed automatically in vmalloc_init() if the area is inserted
+ * by vm_area_add_early()/vm_area_register_early() during early boot process
+ * or you can give this flag manually using other vmalloc APIs.
+ */
+#define VM_STATIC  0x0200
 /* bits [20..32] reserved for arch specific ioremap internals */
 
 /*
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 8ef8ea1..6bc6c39 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1262,7 +1262,7 @@ void __init vmalloc_init(void)
/* Import existing vmlist entries. */
for (tmp = vmlist; tmp; tmp = tmp->next) {
va = kzalloc(sizeof(struct vmap_area), GFP_NOWAIT);
-   va->flags = VM_VM_AREA;
+   va->flags = VM_VM_AREA | VM_STATIC;
va->va_start = (unsigned long)tmp->addr;
va->va_end = va->va_start + tmp->size;
va->vm = tmp;
@@ -1480,7 +1480,7 @@ struct vm_struct *remove_vm_area(const void *addr)
might_sleep();
 
va = find_vmap_area((unsigned long)addr);
-   if (va && va->flags & VM_VM_AREA) {
+   if (va && likely(!(va->flags & VM_STATIC)) && va->flags & VM_VM_AREA) {
struct vm_struct *vm = va->vm;
 
spin_lock(_area_lock);
@@ -1510,7 +1510,7 @@ static void __vunmap(const void *addr, int 
deallocate_pages)
 
area = remove_vm_area(addr);
if (unlikely(!area)) {
-   WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n",
+   WARN(1, KERN_ERR "Trying to vfree() nonexistent or static vm 
area (%p)\n",
addr);
return;
}
@@ -2708,6 +2708,9 @@ static int s_show(struct seq_file *m, void *p)
if (v->phys_addr)
seq_printf(m, " phys=%pa", >phys_addr);
 
+   if (v->flags & VM_STATIC)
+   seq_puts(m, " static");
+
if (v->flags & VM_IOREMAP)
seq_puts(m, " ioremap");
 
-- 
2.7.4

Re: [PATCH] powerpc/mm: some cleanup of do_page_fault()

[Michael Ellerman]

Christophe Leroy  writes:

> This patch is a bunch of small cleanups of the do_page_fault()
> function:
> 1/ Function store_updates_sp() checks whether the faulting
> instruction is a store updating r1. Therefore we can limit its calls
> to stores exceptions
> 2/ Only the get_user() in store_updates_sp() has to be done outside
> the mm semaphore. All the comparison can be done within the semaphore,
> so only when really needed.
> 3/ As we got a DSI exception, the address pointed by regs->nip is
> obviously valid, otherwise we would have had a instruction exception.
> So __get_user() can be used instead of get_user()
> 4/ Replaced one duplicate 'trap == 0x400' by 'is_exec'
> 5/ Created a 'is_user = user_mode(regs)' and replaced all
> 'user_mode(regs)'.
> Analysis of the assembly code shows that when using user_mode(regs),
> at least the 'andi. r7,r8,16384' is redone several times, and also
> the 'lwz r8,132(r31)' at times. With the new form, the 'is_user'
> is mapped to cr4, then all further use of is_user results in just
> things like 'beq cr4,218 '
> 6/ The 8xx has a dedicated exception for breakpoints, that directly
> calls do_break()

Those are probably all OK, if you send them as separate patches.

> 7/ stdu and stdux only exist on PPC64, so no need to check for them
> on PPC32

I don't love that, because it adds two ifdefs in the C code and the gain
must be pretty small.

cheers

Re: [PATCH] powerpc/mm: some cleanup of do_page_fault()

[Michael Ellerman]

Christophe Leroy  writes:

> This patch is a bunch of small cleanups of the do_page_fault()
> function:
> 1/ Function store_updates_sp() checks whether the faulting
> instruction is a store updating r1. Therefore we can limit its calls
> to stores exceptions
> 2/ Only the get_user() in store_updates_sp() has to be done outside
> the mm semaphore. All the comparison can be done within the semaphore,
> so only when really needed.
> 3/ As we got a DSI exception, the address pointed by regs->nip is
> obviously valid, otherwise we would have had a instruction exception.
> So __get_user() can be used instead of get_user()
> 4/ Replaced one duplicate 'trap == 0x400' by 'is_exec'
> 5/ Created a 'is_user = user_mode(regs)' and replaced all
> 'user_mode(regs)'.
> Analysis of the assembly code shows that when using user_mode(regs),
> at least the 'andi. r7,r8,16384' is redone several times, and also
> the 'lwz r8,132(r31)' at times. With the new form, the 'is_user'
> is mapped to cr4, then all further use of is_user results in just
> things like 'beq cr4,218 '
> 6/ The 8xx has a dedicated exception for breakpoints, that directly
> calls do_break()

Those are probably all OK, if you send them as separate patches.

> 7/ stdu and stdux only exist on PPC64, so no need to check for them
> on PPC32

I don't love that, because it adds two ifdefs in the C code and the gain
must be pretty small.

cheers

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Logan Gunthorpe]

On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote:
> Is it ? Again, you create a "concept" the user may have no idea about,
> "p2pmem memory". So now any kind of memory buffer on a device can could
> be use for p2p but also potentially a bunch of other things becomes
> special and called "p2pmem" ...

The user is going to have to have an idea about it if they are designing
systems to make use of it. I've said it before many times: this is an
optimization with significant trade-offs so the user does have to make
decisions regarding when to enable it.


> But what do you have in p2pmem that somebody benefits from. Again I
> don't understand what that "p2pmem" device buys you in term of
> functionality vs. having the device just instanciate the pages.

Well thanks for just taking a big shit on all of our work without even
reading the patches. Bravo.

> Now having some kind of way to override the dma_ops, yes I do get that,
> and it could be that this "p2pmem" is typically the way to do it, but
> at the moment you don't even have that. So I'm a bit at a loss here.

Yes, we've already said many times that this is something we will need
to add.

> But it doesn't *have* to be. Again, take my GPU example. The fact that
> a NIC might be able to DMA into it doesn't make it specifically "p2p
> memory".

Just because you use it for other things doesn't mean it can't also
provide the service of a "p2pmem" device.

> So now your "p2pmem" device needs to also be laid out on top of those
> MMIO registers ? It's becoming weird.

Yes, Max Gurtovoy has also expressed an interest in expanding this work
to cover things other than memory. He's suggested simply calling it a
p2p device, but until we figure out what exactly that all means we can't
really finalize a name.

> See, basically, doing peer 2 peer between devices has 3 main challenges
> today: The DMA API needing struct pages, the MMIO translation issues
> and the IOMMU translation issues.
> 
> You seem to create that added device as some kind of "owner" for the
> struct pages, solving #1, but leave #2 and #3 alone.

Well there are other challenges too. Like figuring out when it's
appropriate to use, tying together the device that provides the memory
with the driver tring to use it in DMA transactions, etc, etc. Our patch
set tackles these latter issues.

> If we go down that path, though, rather than calling it p2pmem I would
> call it something like dma_target which I find much clearer especially
> since it doesn't have to be just memory.

I'm not set on the name. My arguments have been specifically for the
existence of an independent struct device. But I'm not really interested
in getting into bike shedding arguments over what to call it at this
time when we don't even really know what it's going to end up doing in
the end.

> The memory allocation should be a completely orthogonal and separate
> thing yes. You are conflating two completely different things now into
> a single concept.

Well we need a uniform way for a driver trying to coordinate a p2p dma
to find and obtain memory from devices that supply it. We are not
dealing with GPUs that already have complicated allocators. We are
dealing with people adding memory to their devices for the _sole_
purpose of enabling p2p transfers. So having a common allocation setup
is seen as a benefit to us.

Logan

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Logan Gunthorpe]

On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote:
> Is it ? Again, you create a "concept" the user may have no idea about,
> "p2pmem memory". So now any kind of memory buffer on a device can could
> be use for p2p but also potentially a bunch of other things becomes
> special and called "p2pmem" ...

The user is going to have to have an idea about it if they are designing
systems to make use of it. I've said it before many times: this is an
optimization with significant trade-offs so the user does have to make
decisions regarding when to enable it.


> But what do you have in p2pmem that somebody benefits from. Again I
> don't understand what that "p2pmem" device buys you in term of
> functionality vs. having the device just instanciate the pages.

Well thanks for just taking a big shit on all of our work without even
reading the patches. Bravo.

> Now having some kind of way to override the dma_ops, yes I do get that,
> and it could be that this "p2pmem" is typically the way to do it, but
> at the moment you don't even have that. So I'm a bit at a loss here.

Yes, we've already said many times that this is something we will need
to add.

> But it doesn't *have* to be. Again, take my GPU example. The fact that
> a NIC might be able to DMA into it doesn't make it specifically "p2p
> memory".

Just because you use it for other things doesn't mean it can't also
provide the service of a "p2pmem" device.

> So now your "p2pmem" device needs to also be laid out on top of those
> MMIO registers ? It's becoming weird.

Yes, Max Gurtovoy has also expressed an interest in expanding this work
to cover things other than memory. He's suggested simply calling it a
p2p device, but until we figure out what exactly that all means we can't
really finalize a name.

> See, basically, doing peer 2 peer between devices has 3 main challenges
> today: The DMA API needing struct pages, the MMIO translation issues
> and the IOMMU translation issues.
> 
> You seem to create that added device as some kind of "owner" for the
> struct pages, solving #1, but leave #2 and #3 alone.

Well there are other challenges too. Like figuring out when it's
appropriate to use, tying together the device that provides the memory
with the driver tring to use it in DMA transactions, etc, etc. Our patch
set tackles these latter issues.

> If we go down that path, though, rather than calling it p2pmem I would
> call it something like dma_target which I find much clearer especially
> since it doesn't have to be just memory.

I'm not set on the name. My arguments have been specifically for the
existence of an independent struct device. But I'm not really interested
in getting into bike shedding arguments over what to call it at this
time when we don't even really know what it's going to end up doing in
the end.

> The memory allocation should be a completely orthogonal and separate
> thing yes. You are conflating two completely different things now into
> a single concept.

Well we need a uniform way for a driver trying to coordinate a p2p dma
to find and obtain memory from devices that supply it. We are not
dealing with GPUs that already have complicated allocators. We are
dealing with people adding memory to their devices for the _sole_
purpose of enabling p2p transfers. So having a common allocation setup
is seen as a benefit to us.

Logan

Re: [PATCH v3 01/12] arm64: allwinner: a64: enable RSB on A64

[Maxime Ripard]

On Mon, Apr 17, 2017 at 07:57:36PM +0800, Icenowy Zheng wrote:
> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
> 
> Add it and its pinmux.
> 
> Signed-off-by: Icenowy Zheng 
> Acked-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v3 01/12] arm64: allwinner: a64: enable RSB on A64

[Maxime Ripard]

On Mon, Apr 17, 2017 at 07:57:36PM +0800, Icenowy Zheng wrote:
> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
> 
> Add it and its pinmux.
> 
> Signed-off-by: Icenowy Zheng 
> Acked-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] ARM: sunxi: h3/h5: fix the compatible of R_CCU

[Maxime Ripard]

On Mon, Apr 17, 2017 at 06:34:49PM +0800, Icenowy Zheng wrote:
> The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible.
> 
> Fix it by changing it to the correct H3 compatible.
> 
> Signed-off-by: Icenowy Zheng 

Applied, thanks

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] ARM: sunxi: h3/h5: fix the compatible of R_CCU

[Maxime Ripard]

On Mon, Apr 17, 2017 at 06:34:49PM +0800, Icenowy Zheng wrote:
> The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible.
> 
> Fix it by changing it to the correct H3 compatible.
> 
> Signed-off-by: Icenowy Zheng 

Applied, thanks

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] arm64: dts: allwinner: pine64: Add remaining UART aliases

[Maxime Ripard]

On Fri, Apr 14, 2017 at 09:08:04PM +0200, Andreas Färber wrote:
> Enabling uart2 node currently leads to a /dev/ttyS1 device, with ttyS0..4
> always present, causing confusion on the user's part.
> 
> dtc cannot resolve an overlay's  reference for strings, only for
> phandles, so it would need to hardcode the full node path.
> 
> Avoid this and enforce reliable numbering by adding serialX aliases for:
> 
> UART1 - on Wifi/BT connector
> UART2 - on Pi-2 connector
> UART3 - on Euler connector
> UART4 - on Euler connector
> 
> Signed-off-by: Andreas Färber 

Applied, thanks

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] arm64: dts: allwinner: pine64: Add remaining UART aliases

[Maxime Ripard]

On Fri, Apr 14, 2017 at 09:08:04PM +0200, Andreas Färber wrote:
> Enabling uart2 node currently leads to a /dev/ttyS1 device, with ttyS0..4
> always present, causing confusion on the user's part.
> 
> dtc cannot resolve an overlay's  reference for strings, only for
> phandles, so it would need to hardcode the full node path.
> 
> Avoid this and enforce reliable numbering by adding serialX aliases for:
> 
> UART1 - on Wifi/BT connector
> UART2 - on Pi-2 connector
> UART3 - on Euler connector
> UART4 - on Euler connector
> 
> Signed-off-by: Andreas Färber 

Applied, thanks

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] arm64: dts: allwinner: a64: Add UART2 pin nodes

[Maxime Ripard]

On Fri, Apr 14, 2017 at 07:13:20PM +0200, Andreas Färber wrote:
> UART2 is exposed on the Pi connector of Pine64. Make a pinctrl node
> available at the SoC level, to simplify enabling UART2 via DT overlay.
> 
> Signed-off-by: Andreas Färber 

Applied, thanks!

Could you also create the node in the pine64 DTS (with an explicit
status = "disabled" in there) so that the overlay would be even easier
to make ?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] arm64: dts: allwinner: a64: Add UART2 pin nodes

[Maxime Ripard]

On Fri, Apr 14, 2017 at 07:13:20PM +0200, Andreas Färber wrote:
> UART2 is exposed on the Pi connector of Pine64. Make a pinctrl node
> available at the SoC level, to simplify enabling UART2 via DT overlay.
> 
> Signed-off-by: Andreas Färber 

Applied, thanks!

Could you also create the node in the pine64 DTS (with an explicit
status = "disabled" in there) so that the overlay would be even easier
to make ?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi Greg,

After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:

make[7]: *** No rule to make target 
'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o',
 needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'.  Stop.

Caused by commit

  7afe8f84f793 ("atomisp: remove UDS kernel code")

I have used the staging tree from next-20170413 for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the staging tree

[Stephen Rothwell]

Hi Greg,

After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:

make[7]: *** No rule to make target 
'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o',
 needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'.  Stop.

Caused by commit

  7afe8f84f793 ("atomisp: remove UDS kernel code")

I have used the staging tree from next-20170413 for today.

-- 
Cheers,
Stephen Rothwell

[PATCH V3] mm/madvise: Move up the behavior parameter validation

[Anshuman Khandual]

The madvise_behavior_valid() function should be called before
acting upon the behavior parameter. Hence move up the function.
This also includes MADV_SOFT_OFFLINE and MADV_HWPOISON options
as valid behavior parameter for the system call madvise().

Signed-off-by: Anshuman Khandual 
---
Changes in V3:

Moved the madvise_inject_error() function down which will make
sure that the boundary conditions are checked for address and
length arguments as per Naoya.

Changes in V2:

Added CONFIG_MEMORY_FAILURE check before using MADV_SOFT_OFFLINE
and MADV_HWPOISONE constants.

 mm/madvise.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index efd4721..721dd6f 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -694,6 +694,10 @@ static int madvise_inject_error(int behavior,
 #endif
case MADV_DONTDUMP:
case MADV_DODUMP:
+#ifdef CONFIG_MEMORY_FAILURE
+   case MADV_SOFT_OFFLINE:
+   case MADV_HWPOISON:
+#endif
return true;
 
default:
@@ -767,10 +771,6 @@ static int madvise_inject_error(int behavior,
size_t len;
struct blk_plug plug;
 
-#ifdef CONFIG_MEMORY_FAILURE
-   if (behavior == MADV_HWPOISON || behavior == MADV_SOFT_OFFLINE)
-   return madvise_inject_error(behavior, start, start + len_in);
-#endif
if (!madvise_behavior_valid(behavior))
return error;
 
@@ -790,6 +790,11 @@ static int madvise_inject_error(int behavior,
if (end == start)
return error;
 
+#ifdef CONFIG_MEMORY_FAILURE
+   if (behavior == MADV_HWPOISON || behavior == MADV_SOFT_OFFLINE)
+   return madvise_inject_error(behavior, start, start + len_in);
+#endif
+
write = madvise_need_mmap_write(behavior);
if (write) {
if (down_write_killable(>mm->mmap_sem))
-- 
1.8.5.2

[PATCH V3] mm/madvise: Move up the behavior parameter validation

[Anshuman Khandual]

The madvise_behavior_valid() function should be called before
acting upon the behavior parameter. Hence move up the function.
This also includes MADV_SOFT_OFFLINE and MADV_HWPOISON options
as valid behavior parameter for the system call madvise().

Signed-off-by: Anshuman Khandual 
---
Changes in V3:

Moved the madvise_inject_error() function down which will make
sure that the boundary conditions are checked for address and
length arguments as per Naoya.

Changes in V2:

Added CONFIG_MEMORY_FAILURE check before using MADV_SOFT_OFFLINE
and MADV_HWPOISONE constants.

 mm/madvise.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index efd4721..721dd6f 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -694,6 +694,10 @@ static int madvise_inject_error(int behavior,
 #endif
case MADV_DONTDUMP:
case MADV_DODUMP:
+#ifdef CONFIG_MEMORY_FAILURE
+   case MADV_SOFT_OFFLINE:
+   case MADV_HWPOISON:
+#endif
return true;
 
default:
@@ -767,10 +771,6 @@ static int madvise_inject_error(int behavior,
size_t len;
struct blk_plug plug;
 
-#ifdef CONFIG_MEMORY_FAILURE
-   if (behavior == MADV_HWPOISON || behavior == MADV_SOFT_OFFLINE)
-   return madvise_inject_error(behavior, start, start + len_in);
-#endif
if (!madvise_behavior_valid(behavior))
return error;
 
@@ -790,6 +790,11 @@ static int madvise_inject_error(int behavior,
if (end == start)
return error;
 
+#ifdef CONFIG_MEMORY_FAILURE
+   if (behavior == MADV_HWPOISON || behavior == MADV_SOFT_OFFLINE)
+   return madvise_inject_error(behavior, start, start + len_in);
+#endif
+
write = madvise_need_mmap_write(behavior);
if (write) {
if (down_write_killable(>mm->mmap_sem))
-- 
1.8.5.2

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Logan Gunthorpe]

On 17/04/17 11:04 AM, Dan Williams wrote:
>> Yes, in this scheme, it needs an additional p2pmem child. Why is that an
>> issue? It certainly makes it a lot easier for the user to understand the
>> p2pmem memory in the system (through the sysfs tree) and reason about
>> the topology and when to use it. This is important.
> 
> I think you want to go the other way in the hierarchy and find a
> shared *parent* to land the p2pmem capability. Because that same agent
> is going to be responsible handling address translation for the peers.
>
> Peer-dma is always going to be a property of the bus and not the end
> devices. Requiring each bus implementation to explicitly enable
> peer-to-peer support is a feature not a bug.
> 
> We shouldn't design for some future possible use case. Solve it for
> pci and when / if another bus comes along then look at a more generic
> abstraction.

Thanks Dan, these are some good points. Wedding it closer to the PCI
code makes more sense to me now. I'd still think you'd want some struct
device though to appear in the device hierarchy and allow reasoning
about topology.

Logan

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Logan Gunthorpe]

On 17/04/17 11:04 AM, Dan Williams wrote:
>> Yes, in this scheme, it needs an additional p2pmem child. Why is that an
>> issue? It certainly makes it a lot easier for the user to understand the
>> p2pmem memory in the system (through the sysfs tree) and reason about
>> the topology and when to use it. This is important.
> 
> I think you want to go the other way in the hierarchy and find a
> shared *parent* to land the p2pmem capability. Because that same agent
> is going to be responsible handling address translation for the peers.
>
> Peer-dma is always going to be a property of the bus and not the end
> devices. Requiring each bus implementation to explicitly enable
> peer-to-peer support is a feature not a bug.
> 
> We shouldn't design for some future possible use case. Solve it for
> pci and when / if another bus comes along then look at a more generic
> abstraction.

Thanks Dan, these are some good points. Wedding it closer to the PCI
code makes more sense to me now. I'd still think you'd want some struct
device though to appear in the device hierarchy and allow reasoning
about topology.

Logan

[PATCH] RTC: Add functionality to read/write rtc scratch registers

[Keerthy]

From: Russ Dill 

Many RTCs provide scratch registers that are maintained so long as the RTC
has power. Provide a generic method to access these registers.

Signed-off-by: Russ Dill 
Signed-off-by: Keerthy 
---
 drivers/rtc/interface.c | 50 +
 drivers/rtc/rtc-omap.c  | 35 ++
 include/linux/rtc.h |  7 +++
 3 files changed, 92 insertions(+)

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index fc0fa75..facde06 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -1016,3 +1016,53 @@ int rtc_set_offset(struct rtc_device *rtc, long offset)
mutex_unlock(>ops_lock);
return ret;
 }
+
+/* rtc_read_scratch - Read from RTC scratch register
+ * @ rtc: rtc device to be used
+ * @ index: index of scratch register
+ * @ value: returned value read
+ *
+ * Kernel interface read from an RTC scratch register
+ */
+int rtc_read_scratch(struct rtc_device *rtc, unsigned int index, u32 *value)
+{
+   int err;
+
+   mutex_lock(>ops_lock);
+   if (!rtc->ops)
+   err = -ENODEV;
+   else if (index >= rtc->ops->scratch_size || !rtc->ops->read_scratch)
+   err = -EINVAL;
+   else
+   err = rtc->ops->read_scratch(rtc->dev.parent, index, value);
+   mutex_unlock(>ops_lock);
+   return err;
+}
+EXPORT_SYMBOL_GPL(rtc_read_scratch);
+
+/* rtc_write_scratch - Write to RTC scratch register
+ * @ rtc: rtc device to be used
+ * @ index: index of scratch register
+ * @ value: value to write
+ *
+ * Kernel interface write to an RTC scratch register
+ */
+int rtc_write_scratch(struct rtc_device *rtc, unsigned int index, u32 value)
+{
+   int err;
+
+   mutex_lock(>ops_lock);
+
+   if (!rtc->ops)
+   err = -ENODEV;
+   else if (index >= rtc->ops->scratch_size ||
+!rtc->ops->write_scratch)
+   err = -EINVAL;
+   else
+   err = rtc->ops->write_scratch(rtc->dev.parent, index, value);
+
+   mutex_unlock(>ops_lock);
+
+   return err;
+}
+EXPORT_SYMBOL_GPL(rtc_write_scratch);
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 13f7cd1..c90d93e 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -70,6 +70,10 @@
 #define OMAP_RTC_COMP_MSB_REG  0x50
 #define OMAP_RTC_OSC_REG   0x54
 
+#define OMAP_RTC_SCRATCH0_REG  0x60
+#define OMAP_RTC_SCRATCH1_REG  0x64
+#define OMAP_RTC_SCRATCH2_REG  0x68
+
 #define OMAP_RTC_KICK0_REG 0x6c
 #define OMAP_RTC_KICK1_REG 0x70
 
@@ -414,6 +418,34 @@ static int omap_rtc_set_alarm(struct device *dev, struct 
rtc_wkalrm *alm)
 
 static struct omap_rtc *omap_rtc_power_off_rtc;
 
+static const u32 omap_rtc_scratch_regs[] = {
+   OMAP_RTC_SCRATCH0_REG,
+   OMAP_RTC_SCRATCH1_REG,
+   OMAP_RTC_SCRATCH2_REG,
+};
+
+static int omap_rtc_read_scratch(struct device *dev, unsigned int index,
+u32 *value)
+{
+   *value = readl(omap_rtc_power_off_rtc->base +
+  omap_rtc_scratch_regs[index]);
+
+   return 0;
+}
+
+static int omap_rtc_write_scratch(struct device *dev, unsigned int index,
+ u32 value)
+{
+   struct omap_rtc *rtc = dev_get_drvdata(dev);
+
+   rtc->type->unlock(rtc);
+   writel(value, omap_rtc_power_off_rtc->base +
+  omap_rtc_scratch_regs[index]);
+   rtc->type->lock(rtc);
+
+   return 0;
+}
+
 /*
  * omap_rtc_poweroff: RTC-controlled power off
  *
@@ -484,6 +516,9 @@ static void omap_rtc_power_off(void)
.read_alarm = omap_rtc_read_alarm,
.set_alarm  = omap_rtc_set_alarm,
.alarm_irq_enable = omap_rtc_alarm_irq_enable,
+   .read_scratch   = omap_rtc_read_scratch,
+   .write_scratch  = omap_rtc_write_scratch,
+   .scratch_size   = ARRAY_SIZE(omap_rtc_scratch_regs),
 };
 
 static const struct omap_rtc_device_type omap_rtc_default_type = {
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index b693ada..da5e003 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -91,6 +91,10 @@ struct rtc_class_ops {
int (*alarm_irq_enable)(struct device *, unsigned int enabled);
int (*read_offset)(struct device *, long *offset);
int (*set_offset)(struct device *, long offset);
+   int (*read_scratch)(struct device *, unsigned int, u32*);
+   int (*write_scratch)(struct device *, unsigned int, u32);
+
+   unsigned int scratch_size;
 };
 
 #define RTC_DEVICE_NAME_SIZE 20
@@ -214,6 +218,9 @@ int rtc_timer_start(struct rtc_device *rtc, struct 
rtc_timer *timer,
 int rtc_set_offset(struct rtc_device *rtc, long offset);
 void rtc_timer_do_work(struct work_struct *work);
 
+int rtc_read_scratch(struct rtc_device *rtc, unsigned int index, u32 *value);
+int rtc_write_scratch(struct rtc_device *rtc, 

[PATCH] RTC: Add functionality to read/write rtc scratch registers

[Keerthy]

From: Russ Dill 

Many RTCs provide scratch registers that are maintained so long as the RTC
has power. Provide a generic method to access these registers.

Signed-off-by: Russ Dill 
Signed-off-by: Keerthy 
---
 drivers/rtc/interface.c | 50 +
 drivers/rtc/rtc-omap.c  | 35 ++
 include/linux/rtc.h |  7 +++
 3 files changed, 92 insertions(+)

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index fc0fa75..facde06 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -1016,3 +1016,53 @@ int rtc_set_offset(struct rtc_device *rtc, long offset)
mutex_unlock(>ops_lock);
return ret;
 }
+
+/* rtc_read_scratch - Read from RTC scratch register
+ * @ rtc: rtc device to be used
+ * @ index: index of scratch register
+ * @ value: returned value read
+ *
+ * Kernel interface read from an RTC scratch register
+ */
+int rtc_read_scratch(struct rtc_device *rtc, unsigned int index, u32 *value)
+{
+   int err;
+
+   mutex_lock(>ops_lock);
+   if (!rtc->ops)
+   err = -ENODEV;
+   else if (index >= rtc->ops->scratch_size || !rtc->ops->read_scratch)
+   err = -EINVAL;
+   else
+   err = rtc->ops->read_scratch(rtc->dev.parent, index, value);
+   mutex_unlock(>ops_lock);
+   return err;
+}
+EXPORT_SYMBOL_GPL(rtc_read_scratch);
+
+/* rtc_write_scratch - Write to RTC scratch register
+ * @ rtc: rtc device to be used
+ * @ index: index of scratch register
+ * @ value: value to write
+ *
+ * Kernel interface write to an RTC scratch register
+ */
+int rtc_write_scratch(struct rtc_device *rtc, unsigned int index, u32 value)
+{
+   int err;
+
+   mutex_lock(>ops_lock);
+
+   if (!rtc->ops)
+   err = -ENODEV;
+   else if (index >= rtc->ops->scratch_size ||
+!rtc->ops->write_scratch)
+   err = -EINVAL;
+   else
+   err = rtc->ops->write_scratch(rtc->dev.parent, index, value);
+
+   mutex_unlock(>ops_lock);
+
+   return err;
+}
+EXPORT_SYMBOL_GPL(rtc_write_scratch);
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 13f7cd1..c90d93e 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -70,6 +70,10 @@
 #define OMAP_RTC_COMP_MSB_REG  0x50
 #define OMAP_RTC_OSC_REG   0x54
 
+#define OMAP_RTC_SCRATCH0_REG  0x60
+#define OMAP_RTC_SCRATCH1_REG  0x64
+#define OMAP_RTC_SCRATCH2_REG  0x68
+
 #define OMAP_RTC_KICK0_REG 0x6c
 #define OMAP_RTC_KICK1_REG 0x70
 
@@ -414,6 +418,34 @@ static int omap_rtc_set_alarm(struct device *dev, struct 
rtc_wkalrm *alm)
 
 static struct omap_rtc *omap_rtc_power_off_rtc;
 
+static const u32 omap_rtc_scratch_regs[] = {
+   OMAP_RTC_SCRATCH0_REG,
+   OMAP_RTC_SCRATCH1_REG,
+   OMAP_RTC_SCRATCH2_REG,
+};
+
+static int omap_rtc_read_scratch(struct device *dev, unsigned int index,
+u32 *value)
+{
+   *value = readl(omap_rtc_power_off_rtc->base +
+  omap_rtc_scratch_regs[index]);
+
+   return 0;
+}
+
+static int omap_rtc_write_scratch(struct device *dev, unsigned int index,
+ u32 value)
+{
+   struct omap_rtc *rtc = dev_get_drvdata(dev);
+
+   rtc->type->unlock(rtc);
+   writel(value, omap_rtc_power_off_rtc->base +
+  omap_rtc_scratch_regs[index]);
+   rtc->type->lock(rtc);
+
+   return 0;
+}
+
 /*
  * omap_rtc_poweroff: RTC-controlled power off
  *
@@ -484,6 +516,9 @@ static void omap_rtc_power_off(void)
.read_alarm = omap_rtc_read_alarm,
.set_alarm  = omap_rtc_set_alarm,
.alarm_irq_enable = omap_rtc_alarm_irq_enable,
+   .read_scratch   = omap_rtc_read_scratch,
+   .write_scratch  = omap_rtc_write_scratch,
+   .scratch_size   = ARRAY_SIZE(omap_rtc_scratch_regs),
 };
 
 static const struct omap_rtc_device_type omap_rtc_default_type = {
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index b693ada..da5e003 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -91,6 +91,10 @@ struct rtc_class_ops {
int (*alarm_irq_enable)(struct device *, unsigned int enabled);
int (*read_offset)(struct device *, long *offset);
int (*set_offset)(struct device *, long offset);
+   int (*read_scratch)(struct device *, unsigned int, u32*);
+   int (*write_scratch)(struct device *, unsigned int, u32);
+
+   unsigned int scratch_size;
 };
 
 #define RTC_DEVICE_NAME_SIZE 20
@@ -214,6 +218,9 @@ int rtc_timer_start(struct rtc_device *rtc, struct 
rtc_timer *timer,
 int rtc_set_offset(struct rtc_device *rtc, long offset);
 void rtc_timer_do_work(struct work_struct *work);
 
+int rtc_read_scratch(struct rtc_device *rtc, unsigned int index, u32 *value);
+int rtc_write_scratch(struct rtc_device *rtc, unsigned int index, u32 value);
+
 static inline bool 

[PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

[William Wu]

This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.

When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).

On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.

Signed-off-by: William Wu 
---
Changes in v2:
- fix coding style

 Documentation/devicetree/bindings/usb/dwc3.txt |  2 ++
 drivers/usb/dwc3/core.c| 14 ++
 drivers/usb/dwc3/core.h|  4 
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index f658f39..6a89f0c 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -45,6 +45,8 @@ Optional properties:
a free-running PHY clock.
  - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
from P0 to P1/P2/P3 without delay.
+ - snps,tx-ipgap-linecheck-dis-quirk: when set, disable u2mac linestate check
+   during HS transmit.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 455d89a..03429c5 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -796,15 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
 
+   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+
/*
 * Enable hardware control of sending remote wakeup in HS when
 * the device is in the L1 state.
 */
-   if (dwc->revision >= DWC3_REVISION_290A) {
-   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+   if (dwc->revision >= DWC3_REVISION_290A)
reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
-   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
-   }
+
+   if (dwc->tx_ipgap_linecheck_dis_quirk)
+   reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+
+   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
 
return 0;
 
@@ -1023,6 +1027,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,dis-u2-freeclk-exists-quirk");
dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
+   dwc->tx_ipgap_linecheck_dis_quirk = device_property_read_bool(dev,
+   "snps,tx-ipgap-linecheck-dis-quirk");
 
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 981c77f..3c2537b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -204,6 +204,7 @@
 #define DWC3_GCTL_DSBLCLKGTNG  BIT(0)
 
 /* Global User Control 1 Register */
+#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
 #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW  BIT(24)
 
 /* Global USB2 PHY Configuration Register */
@@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
  * provide a free-running PHY clock.
  * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
  * change quirk.
+ * @tx_ipgap_linecheck_dis_quirk: set if we disable u2mac linestate
+ * check during HS transmit.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 0   - -6dB de-emphasis
@@ -1004,6 +1007,7 @@ struct dwc3 {
unsigneddis_rxdet_inp3_quirk:1;
unsigneddis_u2_freeclk_exists_quirk:1;
unsigneddis_del_phy_power_chg_quirk:1;
+   unsignedtx_ipgap_linecheck_dis_quirk:1;
 
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
-- 
2.0.0

[PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

[William Wu]

This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.

When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).

On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.

Signed-off-by: William Wu 
---
Changes in v2:
- fix coding style

 Documentation/devicetree/bindings/usb/dwc3.txt |  2 ++
 drivers/usb/dwc3/core.c| 14 ++
 drivers/usb/dwc3/core.h|  4 
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index f658f39..6a89f0c 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -45,6 +45,8 @@ Optional properties:
a free-running PHY clock.
  - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
from P0 to P1/P2/P3 without delay.
+ - snps,tx-ipgap-linecheck-dis-quirk: when set, disable u2mac linestate check
+   during HS transmit.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 455d89a..03429c5 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -796,15 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
 
+   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+
/*
 * Enable hardware control of sending remote wakeup in HS when
 * the device is in the L1 state.
 */
-   if (dwc->revision >= DWC3_REVISION_290A) {
-   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+   if (dwc->revision >= DWC3_REVISION_290A)
reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
-   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
-   }
+
+   if (dwc->tx_ipgap_linecheck_dis_quirk)
+   reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+
+   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
 
return 0;
 
@@ -1023,6 +1027,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,dis-u2-freeclk-exists-quirk");
dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
+   dwc->tx_ipgap_linecheck_dis_quirk = device_property_read_bool(dev,
+   "snps,tx-ipgap-linecheck-dis-quirk");
 
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 981c77f..3c2537b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -204,6 +204,7 @@
 #define DWC3_GCTL_DSBLCLKGTNG  BIT(0)
 
 /* Global User Control 1 Register */
+#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
 #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW  BIT(24)
 
 /* Global USB2 PHY Configuration Register */
@@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
  * provide a free-running PHY clock.
  * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
  * change quirk.
+ * @tx_ipgap_linecheck_dis_quirk: set if we disable u2mac linestate
+ * check during HS transmit.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 0   - -6dB de-emphasis
@@ -1004,6 +1007,7 @@ struct dwc3 {
unsigneddis_rxdet_inp3_quirk:1;
unsigneddis_u2_freeclk_exists_quirk:1;
unsigneddis_del_phy_power_chg_quirk:1;
+   unsignedtx_ipgap_linecheck_dis_quirk:1;
 
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
-- 
2.0.0

Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries

[Viresh Kumar]

On 17-04-17, 18:40, Rafael J. Wysocki wrote:
> On Monday, April 17, 2017 06:35:25 PM Rafael J. Wysocki wrote:
> > On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote:
> > > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki :
> > > > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote:
> > > >> Compiling the DT file with W=1, DTC warns like follows:
> > > >>
> > > >> Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> > > >> unit name, but no reg property
> > > >>
> > > >> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > > >> "reg" property.
> > > >>
> > > >> Reported-by: Krzysztof Kozlowski 
> > > >> Reported-by: Masahiro Yamada 
> > > >> Suggested-by: Mark Rutland 
> > > >> Signed-off-by: Viresh Kumar 
> > > >> Acked-by: Maxime Ripard  (sunxi)
> > > >> Reviewed-by: Chanwoo Choi 
> > > >> Reviewed-by: Krzysztof Kozlowski 
> > > >
> > > > OK, so any ACKs from the DT side?  Rob?
> > > >
> > > > Thanks,
> > > > Rafael
> > > 
> > > 
> > > 
> > > I see Rob's Acked-by.
> > > 
> > > https://lkml.org/lkml/2017/4/13/648
> > 
> > Indeed.  Thanks!
> 
> But it doesn't apply on top of -rc7 for me, so I guess there is new 
> 4.12-candidate
> material in the DTS tree that conflicts with this, in which case it is better 
> to route
> it through the DTS tree IMO.

Yes a minor conflict. I have sent the rebased version now, see if you
want to apply it directly or want arm-soc guys to do it.

-- 
viresh

Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries

[Viresh Kumar]

On 17-04-17, 18:40, Rafael J. Wysocki wrote:
> On Monday, April 17, 2017 06:35:25 PM Rafael J. Wysocki wrote:
> > On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote:
> > > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki :
> > > > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote:
> > > >> Compiling the DT file with W=1, DTC warns like follows:
> > > >>
> > > >> Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> > > >> unit name, but no reg property
> > > >>
> > > >> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > > >> "reg" property.
> > > >>
> > > >> Reported-by: Krzysztof Kozlowski 
> > > >> Reported-by: Masahiro Yamada 
> > > >> Suggested-by: Mark Rutland 
> > > >> Signed-off-by: Viresh Kumar 
> > > >> Acked-by: Maxime Ripard  (sunxi)
> > > >> Reviewed-by: Chanwoo Choi 
> > > >> Reviewed-by: Krzysztof Kozlowski 
> > > >
> > > > OK, so any ACKs from the DT side?  Rob?
> > > >
> > > > Thanks,
> > > > Rafael
> > > 
> > > 
> > > 
> > > I see Rob's Acked-by.
> > > 
> > > https://lkml.org/lkml/2017/4/13/648
> > 
> > Indeed.  Thanks!
> 
> But it doesn't apply on top of -rc7 for me, so I guess there is new 
> 4.12-candidate
> material in the DTS tree that conflicts with this, in which case it is better 
> to route
> it through the DTS tree IMO.

Yes a minor conflict. I have sent the rebased version now, see if you
want to apply it directly or want arm-soc guys to do it.

-- 
viresh

[PATCH V3] PM / OPP: Use - instead of @ for DT entries

[Viresh Kumar]

Compiling the DT file with W=1, DTC warns like follows:

Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
unit name, but no reg property

Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.

Reported-by: Krzysztof Kozlowski 
Reported-by: Masahiro Yamada 
Suggested-by: Mark Rutland 
Signed-off-by: Viresh Kumar 
Acked-by: Maxime Ripard  (sunxi)
Reviewed-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: Masahiro Yamada  (uniphier)
Acked-by: Rob Herring 
Acked-by: Tony Lindgren 
---
V2->V3:
- Rebased over 4.11-rc7 and fixed a merge conflict for sun8i.

 .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 20 +++
 .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++
 Documentation/devicetree/bindings/opp/opp.txt  | 38 ++---
 arch/arm/boot/dts/am4372.dtsi  | 10 ++--
 arch/arm/boot/dts/exynos3250.dtsi  | 46 +++
 arch/arm/boot/dts/exynos4210.dtsi  | 32 +--
 arch/arm/boot/dts/exynos4412-prime.dtsi|  4 +-
 arch/arm/boot/dts/exynos4412.dtsi  | 66 +++---
 arch/arm/boot/dts/exynos5420.dtsi  | 40 ++---
 arch/arm/boot/dts/exynos5800.dtsi  | 56 +-
 arch/arm/boot/dts/pxa25x.dtsi  |  8 +--
 arch/arm/boot/dts/pxa27x.dtsi  | 14 ++---
 arch/arm/boot/dts/sun8i-a33.dtsi   |  6 +-
 arch/arm/boot/dts/uniphier-pro5.dtsi   | 32 +--
 arch/arm/boot/dts/uniphier-pxs2.dtsi   | 16 +++---
 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 
 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi   | 14 ++---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 32 +--
 arch/arm64/boot/dts/zte/zx296718.dtsi  | 10 ++--
 20 files changed, 294 insertions(+), 294 deletions(-)

diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt 
b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
index ba0e15ad5bd9..0c38e4b8fc51 100644
--- a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
+++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
@@ -63,64 +63,64 @@ cpu0_opp_table: opp-table {
 * because they can not be enabled simultaneously on a
 * single SoC.
 */
-   opp50@3 {
+   opp50-3 {
opp-hz = /bits/ 64 <3>;
opp-microvolt = <95 931000 969000>;
opp-supported-hw = <0x06 0x0010>;
opp-suspend;
};
 
-   opp100@27500 {
+   opp100-27500 {
opp-hz = /bits/ 64 <27500>;
opp-microvolt = <110 1078000 1122000>;
opp-supported-hw = <0x01 0x00FF>;
opp-suspend;
};
 
-   opp100@3 {
+   opp100-3 {
opp-hz = /bits/ 64 <3>;
opp-microvolt = <110 1078000 1122000>;
opp-supported-hw = <0x06 0x0020>;
opp-suspend;
};
 
-   opp100@5 {
+   opp100-5 {
opp-hz = /bits/ 64 <5>;
opp-microvolt = <110 1078000 1122000>;
opp-supported-hw = <0x01 0x>;
};
 
-   opp100@6 {
+   opp100-6 {
opp-hz = /bits/ 64 <6>;
opp-microvolt = <110 1078000 1122000>;
opp-supported-hw = <0x06 0x0040>;
};
 
-   opp120@6 {
+   opp120-6 {
opp-hz = /bits/ 64 <6>;
opp-microvolt = <120 1176000 1224000>;
opp-supported-hw = <0x01 0x>;
};
 
-   opp120@72000 {
+   opp120-72000 {
opp-hz = /bits/ 64 <72000>;
opp-microvolt = <120 1176000 1224000>;
opp-supported-hw = <0x06 0x0080>;
};
 
-   oppturbo@72000 {
+   oppturbo-72000 {
opp-hz = /bits/ 64 <72000>;
opp-microvolt = <126 1234800 1285200>;
opp-supported-hw = <0x01 0x>;
};
 
-   oppturbo@8 {
+   oppturbo-8 {
opp-hz = /bits/ 64 <8>;
opp-microvolt = <126 1234800 1285200>;
opp-supported-hw = <0x06 0x0100>;
};
 
-   oppnitro@10 {
+   oppnitro-10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <1325000 1298500 1351500>;

[PATCH V3] PM / OPP: Use - instead of @ for DT entries

[Viresh Kumar]

Compiling the DT file with W=1, DTC warns like follows:

Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
unit name, but no reg property

Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.

Reported-by: Krzysztof Kozlowski 
Reported-by: Masahiro Yamada 
Suggested-by: Mark Rutland 
Signed-off-by: Viresh Kumar 
Acked-by: Maxime Ripard  (sunxi)
Reviewed-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: Masahiro Yamada  (uniphier)
Acked-by: Rob Herring 
Acked-by: Tony Lindgren 
---
V2->V3:
- Rebased over 4.11-rc7 and fixed a merge conflict for sun8i.

 .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 20 +++
 .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++
 Documentation/devicetree/bindings/opp/opp.txt  | 38 ++---
 arch/arm/boot/dts/am4372.dtsi  | 10 ++--
 arch/arm/boot/dts/exynos3250.dtsi  | 46 +++
 arch/arm/boot/dts/exynos4210.dtsi  | 32 +--
 arch/arm/boot/dts/exynos4412-prime.dtsi|  4 +-
 arch/arm/boot/dts/exynos4412.dtsi  | 66 +++---
 arch/arm/boot/dts/exynos5420.dtsi  | 40 ++---
 arch/arm/boot/dts/exynos5800.dtsi  | 56 +-
 arch/arm/boot/dts/pxa25x.dtsi  |  8 +--
 arch/arm/boot/dts/pxa27x.dtsi  | 14 ++---
 arch/arm/boot/dts/sun8i-a33.dtsi   |  6 +-
 arch/arm/boot/dts/uniphier-pro5.dtsi   | 32 +--
 arch/arm/boot/dts/uniphier-pxs2.dtsi   | 16 +++---
 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 
 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi   | 14 ++---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 32 +--
 arch/arm64/boot/dts/zte/zx296718.dtsi  | 10 ++--
 20 files changed, 294 insertions(+), 294 deletions(-)

diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt 
b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
index ba0e15ad5bd9..0c38e4b8fc51 100644
--- a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
+++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
@@ -63,64 +63,64 @@ cpu0_opp_table: opp-table {
 * because they can not be enabled simultaneously on a
 * single SoC.
 */
-   opp50@3 {
+   opp50-3 {
opp-hz = /bits/ 64 <3>;
opp-microvolt = <95 931000 969000>;
opp-supported-hw = <0x06 0x0010>;
opp-suspend;
};
 
-   opp100@27500 {
+   opp100-27500 {
opp-hz = /bits/ 64 <27500>;
opp-microvolt = <110 1078000 1122000>;
opp-supported-hw = <0x01 0x00FF>;
opp-suspend;
};
 
-   opp100@3 {
+   opp100-3 {
opp-hz = /bits/ 64 <3>;
opp-microvolt = <110 1078000 1122000>;
opp-supported-hw = <0x06 0x0020>;
opp-suspend;
};
 
-   opp100@5 {
+   opp100-5 {
opp-hz = /bits/ 64 <5>;
opp-microvolt = <110 1078000 1122000>;
opp-supported-hw = <0x01 0x>;
};
 
-   opp100@6 {
+   opp100-6 {
opp-hz = /bits/ 64 <6>;
opp-microvolt = <110 1078000 1122000>;
opp-supported-hw = <0x06 0x0040>;
};
 
-   opp120@6 {
+   opp120-6 {
opp-hz = /bits/ 64 <6>;
opp-microvolt = <120 1176000 1224000>;
opp-supported-hw = <0x01 0x>;
};
 
-   opp120@72000 {
+   opp120-72000 {
opp-hz = /bits/ 64 <72000>;
opp-microvolt = <120 1176000 1224000>;
opp-supported-hw = <0x06 0x0080>;
};
 
-   oppturbo@72000 {
+   oppturbo-72000 {
opp-hz = /bits/ 64 <72000>;
opp-microvolt = <126 1234800 1285200>;
opp-supported-hw = <0x01 0x>;
};
 
-   oppturbo@8 {
+   oppturbo-8 {
opp-hz = /bits/ 64 <8>;
opp-microvolt = <126 1234800 1285200>;
opp-supported-hw = <0x06 0x0100>;
};
 
-   oppnitro@10 {
+   oppnitro-10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0x04 0x0200>;
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index d085ef90d27c..f8e946471a58 100644
--- 

[PATCH] clk: Add functions to save and restore clock/dpll context en-masse

[Keerthy]

From: Russ Dill 

The clock/dpll registers are in the WKUP power domain. Under both RTC-only
suspend and hibernation, these registers are lost. Hence save/restore
them accordingly.

Signed-off-by: Russ Dill 
Signed-off-by: Keerthy 
---
 drivers/clk/clk.c|  70 
 drivers/clk/ti/divider.c |  36 +
 drivers/clk/ti/dpll.c|   6 +++
 drivers/clk/ti/dpll3xxx.c| 124 +++
 drivers/clk/ti/gate.c|   3 ++
 drivers/clk/ti/mux.c |  29 ++
 include/linux/clk-provider.h |  11 
 include/linux/clk.h  |  25 +
 include/linux/clk/ti.h   |   6 +++
 9 files changed, 310 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index cbe..1ca87f4 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -687,6 +687,76 @@ static int clk_core_enable_lock(struct clk_core *core)
return ret;
 }
 
+void clk_dflt_restore_context(struct clk_hw *hw)
+{
+   if (hw->clk->core->enable_count)
+   hw->clk->core->ops->enable(hw);
+   else
+   hw->clk->core->ops->disable(hw);
+}
+EXPORT_SYMBOL_GPL(clk_dflt_restore_context);
+
+static int clk_save_context(struct clk_core *clk)
+{
+   struct clk_core *child;
+   int ret = 0;
+
+   hlist_for_each_entry(child, >children, child_node) {
+   ret = clk_save_context(child);
+   if (ret < 0)
+   return ret;
+   }
+
+   if (clk->ops && clk->ops->save_context)
+   ret = clk->ops->save_context(clk->hw);
+
+   return ret;
+}
+
+static void clk_restore_context(struct clk_core *clk)
+{
+   struct clk_core *child;
+
+   if (clk->ops && clk->ops->restore_context)
+   clk->ops->restore_context(clk->hw);
+
+   hlist_for_each_entry(child, >children, child_node)
+   clk_restore_context(child);
+}
+
+int clks_save_context(void)
+{
+   struct clk_core *clk;
+   int ret;
+
+   hlist_for_each_entry(clk, _root_list, child_node) {
+   ret = clk_save_context(clk);
+   if (ret < 0)
+   return ret;
+   }
+
+   hlist_for_each_entry(clk, _orphan_list, child_node) {
+   ret = clk_save_context(clk);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(clks_save_context);
+
+void clks_restore_context(void)
+{
+   struct clk_core *clk;
+
+   hlist_for_each_entry(clk, _root_list, child_node)
+   clk_restore_context(clk);
+
+   hlist_for_each_entry(clk, _orphan_list, child_node)
+   clk_restore_context(clk);
+}
+EXPORT_SYMBOL_GPL(clks_restore_context);
+
 /**
  * clk_enable - ungate a clock
  * @clk: the clk being ungated
diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
index d6dcb28..350a58a 100644
--- a/drivers/clk/ti/divider.c
+++ b/drivers/clk/ti/divider.c
@@ -266,10 +266,46 @@ static int ti_clk_divider_set_rate(struct clk_hw *hw, 
unsigned long rate,
return 0;
 }
 
+/**
+ * clk_divider_save_context - Save the divider value
+ * @hw: pointer  struct clk_hw
+ *
+ * Save the divider value
+ */
+static int clk_divider_save_context(struct clk_hw *hw)
+{
+   struct clk_divider *divider = to_clk_divider(hw);
+   u32 val;
+
+   val = ti_clk_ll_ops->clk_readl(divider->reg) >> divider->shift;
+   divider->context = val & div_mask(divider);
+
+   return 0;
+}
+
+/**
+ * clk_divider_restore_context - restore the saved the divider value
+ * @hw: pointer  struct clk_hw
+ *
+ * Restore the saved the divider value
+ */
+static void clk_divider_restore_context(struct clk_hw *hw)
+{
+   struct clk_divider *divider = to_clk_divider(hw);
+   u32 val;
+
+   val = ti_clk_ll_ops->clk_readl(divider->reg);
+   val &= ~(div_mask(divider) << divider->shift);
+   val |= divider->context << divider->shift;
+   ti_clk_ll_ops->clk_writel(val, divider->reg);
+}
+
 const struct clk_ops ti_clk_divider_ops = {
.recalc_rate = ti_clk_divider_recalc_rate,
.round_rate = ti_clk_divider_round_rate,
.set_rate = ti_clk_divider_set_rate,
+   .save_context = clk_divider_save_context,
+   .restore_context = clk_divider_restore_context,
 };
 
 static struct clk *_register_divider(struct device *dev, const char *name,
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 96d8488..791dd31 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -39,6 +39,8 @@
.set_rate_and_parent= _noncore_dpll_set_rate_and_parent,
.determine_rate = _dpll_regm4xen_determine_rate,
.get_parent = _init_dpll_parent,
+   .save_context   = _core_dpll_save_context,
+   .restore_context = _core_dpll_restore_context,
 };
 #else
 static const struct clk_ops dpll_m4xen_ck_ops = {};
@@ -62,6 +64,8 @@

[PATCH] clk: Add functions to save and restore clock/dpll context en-masse

[Keerthy]

From: Russ Dill 

The clock/dpll registers are in the WKUP power domain. Under both RTC-only
suspend and hibernation, these registers are lost. Hence save/restore
them accordingly.

Signed-off-by: Russ Dill 
Signed-off-by: Keerthy 
---
 drivers/clk/clk.c|  70 
 drivers/clk/ti/divider.c |  36 +
 drivers/clk/ti/dpll.c|   6 +++
 drivers/clk/ti/dpll3xxx.c| 124 +++
 drivers/clk/ti/gate.c|   3 ++
 drivers/clk/ti/mux.c |  29 ++
 include/linux/clk-provider.h |  11 
 include/linux/clk.h  |  25 +
 include/linux/clk/ti.h   |   6 +++
 9 files changed, 310 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index cbe..1ca87f4 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -687,6 +687,76 @@ static int clk_core_enable_lock(struct clk_core *core)
return ret;
 }
 
+void clk_dflt_restore_context(struct clk_hw *hw)
+{
+   if (hw->clk->core->enable_count)
+   hw->clk->core->ops->enable(hw);
+   else
+   hw->clk->core->ops->disable(hw);
+}
+EXPORT_SYMBOL_GPL(clk_dflt_restore_context);
+
+static int clk_save_context(struct clk_core *clk)
+{
+   struct clk_core *child;
+   int ret = 0;
+
+   hlist_for_each_entry(child, >children, child_node) {
+   ret = clk_save_context(child);
+   if (ret < 0)
+   return ret;
+   }
+
+   if (clk->ops && clk->ops->save_context)
+   ret = clk->ops->save_context(clk->hw);
+
+   return ret;
+}
+
+static void clk_restore_context(struct clk_core *clk)
+{
+   struct clk_core *child;
+
+   if (clk->ops && clk->ops->restore_context)
+   clk->ops->restore_context(clk->hw);
+
+   hlist_for_each_entry(child, >children, child_node)
+   clk_restore_context(child);
+}
+
+int clks_save_context(void)
+{
+   struct clk_core *clk;
+   int ret;
+
+   hlist_for_each_entry(clk, _root_list, child_node) {
+   ret = clk_save_context(clk);
+   if (ret < 0)
+   return ret;
+   }
+
+   hlist_for_each_entry(clk, _orphan_list, child_node) {
+   ret = clk_save_context(clk);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(clks_save_context);
+
+void clks_restore_context(void)
+{
+   struct clk_core *clk;
+
+   hlist_for_each_entry(clk, _root_list, child_node)
+   clk_restore_context(clk);
+
+   hlist_for_each_entry(clk, _orphan_list, child_node)
+   clk_restore_context(clk);
+}
+EXPORT_SYMBOL_GPL(clks_restore_context);
+
 /**
  * clk_enable - ungate a clock
  * @clk: the clk being ungated
diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
index d6dcb28..350a58a 100644
--- a/drivers/clk/ti/divider.c
+++ b/drivers/clk/ti/divider.c
@@ -266,10 +266,46 @@ static int ti_clk_divider_set_rate(struct clk_hw *hw, 
unsigned long rate,
return 0;
 }
 
+/**
+ * clk_divider_save_context - Save the divider value
+ * @hw: pointer  struct clk_hw
+ *
+ * Save the divider value
+ */
+static int clk_divider_save_context(struct clk_hw *hw)
+{
+   struct clk_divider *divider = to_clk_divider(hw);
+   u32 val;
+
+   val = ti_clk_ll_ops->clk_readl(divider->reg) >> divider->shift;
+   divider->context = val & div_mask(divider);
+
+   return 0;
+}
+
+/**
+ * clk_divider_restore_context - restore the saved the divider value
+ * @hw: pointer  struct clk_hw
+ *
+ * Restore the saved the divider value
+ */
+static void clk_divider_restore_context(struct clk_hw *hw)
+{
+   struct clk_divider *divider = to_clk_divider(hw);
+   u32 val;
+
+   val = ti_clk_ll_ops->clk_readl(divider->reg);
+   val &= ~(div_mask(divider) << divider->shift);
+   val |= divider->context << divider->shift;
+   ti_clk_ll_ops->clk_writel(val, divider->reg);
+}
+
 const struct clk_ops ti_clk_divider_ops = {
.recalc_rate = ti_clk_divider_recalc_rate,
.round_rate = ti_clk_divider_round_rate,
.set_rate = ti_clk_divider_set_rate,
+   .save_context = clk_divider_save_context,
+   .restore_context = clk_divider_restore_context,
 };
 
 static struct clk *_register_divider(struct device *dev, const char *name,
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 96d8488..791dd31 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -39,6 +39,8 @@
.set_rate_and_parent= _noncore_dpll_set_rate_and_parent,
.determine_rate = _dpll_regm4xen_determine_rate,
.get_parent = _init_dpll_parent,
+   .save_context   = _core_dpll_save_context,
+   .restore_context = _core_dpll_restore_context,
 };
 #else
 static const struct clk_ops dpll_m4xen_ck_ops = {};
@@ -62,6 +64,8 @@
.set_rate_and_parent= 

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer  wrote:
> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin  wrote:
 However, I totally agree with Alex that someone with a BE machine
 should review the whole stack before we could be confident with anything.
>>>
>>> Here's what I'm confident about: xf86-video-nouveau worked just fine
>>> on top of kernel 4.3 on an AGP GeForce FX 5200 (with AGPGART turned
>>> off because ... well ... uninorth). fbcon/fbdev accel worked,
>>> xf86-video-nouveau's 2d accel worked, and simple demos (ala glxgears)
>>> worked after I fixed up mesa and nv30 driver items in version ... 11.1
>>> it seems. As I recall it had gotten all broken in 10.0 or so by Adam
>>> Jackson in the name of making llvmpipe work on BE, declaring all other
>>> drivers broken, with various fixes by Michel Dänzer to get it back to
>>> working over the years.
>>>
>>> Anyone "fixing" the stack has to maintain that level of functioning
>>> through their various fixing.
>>>
>>> I will double-check that the above still works with the latest
>>> kernel/xorg/xf86-video-nouveau/mesa and report back (hopefully by this
>>> weekend). If there are any patches you'd like me to test, now's the
>>> time to ask -- getting the box up and running is the hard part,
>>> booting up an extra kernel -- easy.
>>
>> OK, so I revived my PowerMac7,3 G5 setup (PPC64 BE, NV34 GPU). Booted
>> it with an upstream 4.11-rc7 kernel, loaded up the nouveau kernel
>> module (which is included in that kernel), updated X to 1.19.2 and
>> mesa to 17.0.3. Everything works fine. Specifically:
>>
>> fbcon on top of fbdev provided by nouveau -- colors are fine
>> glxgears hw-accelerated by mesa on top of xf86-video-nouveau using
>> DRI2 -- colors are fine
>> glxgears softpipe-accelerated by mesa on top of xf86-video-nouveau --
>> colors are fine
>> glxgears softpipe-accelerated by mesa on top of xf86-video-modesetting
>> -- colors are fine
>> xterm on top of xf86-video-nouveau -- colors are fine
>> xterm on top of xf86-video-modesetting -- colors are fine
>>
>> I couldn't test anything with GLAMOR since GLAMOR requires GL 2.1 or
>> higher, whereas nouveau's NV3x acceleration only provides GL 1.5 (due
>> to lacking NPOT and a handful of other things).
>>
>> The modetest utility did have trouble with AR24 and I'm pretty sure
>> the XR24 pattern was off too. However I wouldn't be surprised if the
>> modetest utility itself had endian issues in the pattern generation
>> logic. (Seems to be the case, based on a quick glance at the
>> tests/util/format.c logic and how it's used in pattern.c.)
>>
>> So in short, I think the current definitions of format are fine.
>
> I agree with Pekka that it's not that simple. What you've established is
> that things look fine after going through several layers of abstraction.
> It's possible that multiple bugs in those layers cancel each other out;
> in particular, it's quite likely that the code dealing with DRM formats
> is treating them as using native endianness (one possible giveaway for
> that is using shifts for (un)packing colour components).

Quite true that this proves nothing. However one should note that
fbcon -> fbdev works, and both mesa hw driver and softpipe driver
work, in addition to regular DDX accel. Which means that the bugs, if
they exist, are pretty consistent amongst each other, spanning
multiple layers, all agreeing as to what the proper bugginess is. One
could go so far as to declare it to be a feature.

It does show is that things generally work today in at least some, if
not many, setups, and one can't go around breaking them willy nilly.

  -ilia

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer  wrote:
> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin  wrote:
 However, I totally agree with Alex that someone with a BE machine
 should review the whole stack before we could be confident with anything.
>>>
>>> Here's what I'm confident about: xf86-video-nouveau worked just fine
>>> on top of kernel 4.3 on an AGP GeForce FX 5200 (with AGPGART turned
>>> off because ... well ... uninorth). fbcon/fbdev accel worked,
>>> xf86-video-nouveau's 2d accel worked, and simple demos (ala glxgears)
>>> worked after I fixed up mesa and nv30 driver items in version ... 11.1
>>> it seems. As I recall it had gotten all broken in 10.0 or so by Adam
>>> Jackson in the name of making llvmpipe work on BE, declaring all other
>>> drivers broken, with various fixes by Michel Dänzer to get it back to
>>> working over the years.
>>>
>>> Anyone "fixing" the stack has to maintain that level of functioning
>>> through their various fixing.
>>>
>>> I will double-check that the above still works with the latest
>>> kernel/xorg/xf86-video-nouveau/mesa and report back (hopefully by this
>>> weekend). If there are any patches you'd like me to test, now's the
>>> time to ask -- getting the box up and running is the hard part,
>>> booting up an extra kernel -- easy.
>>
>> OK, so I revived my PowerMac7,3 G5 setup (PPC64 BE, NV34 GPU). Booted
>> it with an upstream 4.11-rc7 kernel, loaded up the nouveau kernel
>> module (which is included in that kernel), updated X to 1.19.2 and
>> mesa to 17.0.3. Everything works fine. Specifically:
>>
>> fbcon on top of fbdev provided by nouveau -- colors are fine
>> glxgears hw-accelerated by mesa on top of xf86-video-nouveau using
>> DRI2 -- colors are fine
>> glxgears softpipe-accelerated by mesa on top of xf86-video-nouveau --
>> colors are fine
>> glxgears softpipe-accelerated by mesa on top of xf86-video-modesetting
>> -- colors are fine
>> xterm on top of xf86-video-nouveau -- colors are fine
>> xterm on top of xf86-video-modesetting -- colors are fine
>>
>> I couldn't test anything with GLAMOR since GLAMOR requires GL 2.1 or
>> higher, whereas nouveau's NV3x acceleration only provides GL 1.5 (due
>> to lacking NPOT and a handful of other things).
>>
>> The modetest utility did have trouble with AR24 and I'm pretty sure
>> the XR24 pattern was off too. However I wouldn't be surprised if the
>> modetest utility itself had endian issues in the pattern generation
>> logic. (Seems to be the case, based on a quick glance at the
>> tests/util/format.c logic and how it's used in pattern.c.)
>>
>> So in short, I think the current definitions of format are fine.
>
> I agree with Pekka that it's not that simple. What you've established is
> that things look fine after going through several layers of abstraction.
> It's possible that multiple bugs in those layers cancel each other out;
> in particular, it's quite likely that the code dealing with DRM formats
> is treating them as using native endianness (one possible giveaway for
> that is using shifts for (un)packing colour components).

Quite true that this proves nothing. However one should note that
fbcon -> fbdev works, and both mesa hw driver and softpipe driver
work, in addition to regular DDX accel. Which means that the bugs, if
they exist, are pretty consistent amongst each other, spanning
multiple layers, all agreeing as to what the proper bugginess is. One
could go so far as to declare it to be a feature.

It does show is that things generally work today in at least some, if
not many, setups, and one can't go around breaking them willy nilly.

  -ilia

Re: [PATCH -mm -v3] mm, swap: Sort swap entries before free

[Minchan Kim]

Hi Huang,

On Fri, Apr 07, 2017 at 02:49:01PM +0800, Huang, Ying wrote:
> From: Huang Ying 
> 
> To reduce the lock contention of swap_info_struct->lock when freeing
> swap entry.  The freed swap entries will be collected in a per-CPU
> buffer firstly, and be really freed later in batch.  During the batch
> freeing, if the consecutive swap entries in the per-CPU buffer belongs
> to same swap device, the swap_info_struct->lock needs to be
> acquired/released only once, so that the lock contention could be
> reduced greatly.  But if there are multiple swap devices, it is
> possible that the lock may be unnecessarily released/acquired because
> the swap entries belong to the same swap device are non-consecutive in
> the per-CPU buffer.
> 
> To solve the issue, the per-CPU buffer is sorted according to the swap
> device before freeing the swap entries.  Test shows that the time
> spent by swapcache_free_entries() could be reduced after the patch.
> 
> Test the patch via measuring the run time of swap_cache_free_entries()
> during the exit phase of the applications use much swap space.  The
> results shows that the average run time of swap_cache_free_entries()
> reduced about 20% after applying the patch.
> 
> Signed-off-by: Huang Ying 
> Acked-by: Tim Chen 
> Cc: Hugh Dickins 
> Cc: Shaohua Li 
> Cc: Minchan Kim 
> Cc: Rik van Riel 
> 
> v3:
> 
> - Add some comments in code per Rik's suggestion.
> 
> v2:
> 
> - Avoid sort swap entries if there is only one swap device.
> ---
>  mm/swapfile.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 90054f3c2cdc..f23c56e9be39 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1065,6 +1066,13 @@ void swapcache_free(swp_entry_t entry)
>   }
>  }
>  
> +static int swp_entry_cmp(const void *ent1, const void *ent2)
> +{
> + const swp_entry_t *e1 = ent1, *e2 = ent2;
> +
> + return (long)(swp_type(*e1) - swp_type(*e2));
> +}
> +
>  void swapcache_free_entries(swp_entry_t *entries, int n)
>  {
>   struct swap_info_struct *p, *prev;
> @@ -1075,6 +1083,10 @@ void swapcache_free_entries(swp_entry_t *entries, int 
> n)
>  
>   prev = NULL;
>   p = NULL;
> +
> + /* Sort swap entries by swap device, so each lock is only taken once. */
> + if (nr_swapfiles > 1)
> + sort(entries, n, sizeof(entries[0]), swp_entry_cmp, NULL);

Let's think on other cases.

There are two swaps and they are configured by priority so a swap's usage
would be zero unless other swap used up. In case of that, this sorting
is pointless.

As well, nr_swapfiles is never decreased so if we enable multiple
swaps and then disable until a swap is remained, this sorting is
pointelss, too.

How about lazy sorting approach? IOW, if we found prev != p and,
then we can sort it.

Thanks.

Re: [PATCH -mm -v3] mm, swap: Sort swap entries before free

[Minchan Kim]

Hi Huang,

On Fri, Apr 07, 2017 at 02:49:01PM +0800, Huang, Ying wrote:
> From: Huang Ying 
> 
> To reduce the lock contention of swap_info_struct->lock when freeing
> swap entry.  The freed swap entries will be collected in a per-CPU
> buffer firstly, and be really freed later in batch.  During the batch
> freeing, if the consecutive swap entries in the per-CPU buffer belongs
> to same swap device, the swap_info_struct->lock needs to be
> acquired/released only once, so that the lock contention could be
> reduced greatly.  But if there are multiple swap devices, it is
> possible that the lock may be unnecessarily released/acquired because
> the swap entries belong to the same swap device are non-consecutive in
> the per-CPU buffer.
> 
> To solve the issue, the per-CPU buffer is sorted according to the swap
> device before freeing the swap entries.  Test shows that the time
> spent by swapcache_free_entries() could be reduced after the patch.
> 
> Test the patch via measuring the run time of swap_cache_free_entries()
> during the exit phase of the applications use much swap space.  The
> results shows that the average run time of swap_cache_free_entries()
> reduced about 20% after applying the patch.
> 
> Signed-off-by: Huang Ying 
> Acked-by: Tim Chen 
> Cc: Hugh Dickins 
> Cc: Shaohua Li 
> Cc: Minchan Kim 
> Cc: Rik van Riel 
> 
> v3:
> 
> - Add some comments in code per Rik's suggestion.
> 
> v2:
> 
> - Avoid sort swap entries if there is only one swap device.
> ---
>  mm/swapfile.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 90054f3c2cdc..f23c56e9be39 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1065,6 +1066,13 @@ void swapcache_free(swp_entry_t entry)
>   }
>  }
>  
> +static int swp_entry_cmp(const void *ent1, const void *ent2)
> +{
> + const swp_entry_t *e1 = ent1, *e2 = ent2;
> +
> + return (long)(swp_type(*e1) - swp_type(*e2));
> +}
> +
>  void swapcache_free_entries(swp_entry_t *entries, int n)
>  {
>   struct swap_info_struct *p, *prev;
> @@ -1075,6 +1083,10 @@ void swapcache_free_entries(swp_entry_t *entries, int 
> n)
>  
>   prev = NULL;
>   p = NULL;
> +
> + /* Sort swap entries by swap device, so each lock is only taken once. */
> + if (nr_swapfiles > 1)
> + sort(entries, n, sizeof(entries[0]), swp_entry_cmp, NULL);

Let's think on other cases.

There are two swaps and they are configured by priority so a swap's usage
would be zero unless other swap used up. In case of that, this sorting
is pointless.

As well, nr_swapfiles is never decreased so if we enable multiple
swaps and then disable until a swap is remained, this sorting is
pointelss, too.

How about lazy sorting approach? IOW, if we found prev != p and,
then we can sort it.

Thanks.

Re: [PATCH 4.10 00/29] 4.10.11-stable review

[Greg Kroah-Hartman]

On Mon, Apr 17, 2017 at 12:25:38PM -0600, Shuah Khan wrote:
> On 04/16/2017 02:04 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.11 release.
> > There are 29 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Tue Apr 18 08:02:16 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.11-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.10.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.10 00/29] 4.10.11-stable review

[Greg Kroah-Hartman]

On Mon, Apr 17, 2017 at 12:25:38PM -0600, Shuah Khan wrote:
> On 04/16/2017 02:04 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.11 release.
> > There are 29 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Tue Apr 18 08:02:16 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.11-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.10.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 3.18 000/145] 3.18.49-stable review

[Greg Kroah-Hartman]

On Mon, Apr 17, 2017 at 12:18:19PM -0600, Shuah Khan wrote:
> On 04/16/2017 04:48 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.49 release.
> > There are 145 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > -
> > Wait, what?  3.18?  Wasn't that kernel dead and forgotten and left to
> > rot on the side of the road?  Yes, it was, but unfortunately, there's a
> > few million or so devices out there in the wild that still rely on this
> > kernel.  Now, some of their manufacturers and SoC vendors might not be
> > keeping their kernels up to date very well, but some do actually care
> > about security and their users, so this release is for them.  If you
> > happen to have a vendor that does not care about their users, go
> > complain, as odds are, your device is very insecure right now...
> > 
> > Because of this strange situation, and thanks to some vendors backing
> > the effort[1], I'll keep 3.18-stable alive in a semi-active mode, doing
> > releases every once in a while to keep it up to date and working well
> > based on what is happening in other more well-maintained stable kernels
> > (hint, use 4.4 or 4.9 or newer PLEASE, if your vendor refuses to do so,
> > switch vendors, it's the only way they will learn...)  I don't know how
> > long I'll keep doing this, so if you care about 3.18, please contact me
> > to let me know the expected lifespan of your device.
> > 
> > And finally, due to the delay from the last 3.18-stable kernel release,
> > there is a large backlog of patches, this is about 1/2 of the pending
> > ones so far.  I'll be working on catching up to the rest of them over
> > the next few weeks, and then the updates should be smaller than this
> > one.
> > 
> > ok, back to your normal form-letter stable -rc release notice:
> > -
> > 
> > Responses should be made by Tue Apr 18 08:01:19 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.49-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-3.18.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > [1] Google's android-common-3.18 will be tracking these releases for
> > those of you caring about a working android kernel based on 3.18, I
> > recommend using this tree:
> > https://android.googlesource.com/kernel/common/+/android-3.18
> > 
> 
> Compiled and booted on my test system. I don't have old dmesg logs to
> compare. I removed 3.18 and history from my test system. I will keep
> 3.10.49 logs for the next release.

Ah, thanks for this.  Please don't feel like you have to test 3.18 on
your system if you don't want to, I know it's a very old kernel...

greg k-h

Re: [PATCH 3.18 000/145] 3.18.49-stable review

[Greg Kroah-Hartman]

On Mon, Apr 17, 2017 at 12:18:19PM -0600, Shuah Khan wrote:
> On 04/16/2017 04:48 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.49 release.
> > There are 145 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > -
> > Wait, what?  3.18?  Wasn't that kernel dead and forgotten and left to
> > rot on the side of the road?  Yes, it was, but unfortunately, there's a
> > few million or so devices out there in the wild that still rely on this
> > kernel.  Now, some of their manufacturers and SoC vendors might not be
> > keeping their kernels up to date very well, but some do actually care
> > about security and their users, so this release is for them.  If you
> > happen to have a vendor that does not care about their users, go
> > complain, as odds are, your device is very insecure right now...
> > 
> > Because of this strange situation, and thanks to some vendors backing
> > the effort[1], I'll keep 3.18-stable alive in a semi-active mode, doing
> > releases every once in a while to keep it up to date and working well
> > based on what is happening in other more well-maintained stable kernels
> > (hint, use 4.4 or 4.9 or newer PLEASE, if your vendor refuses to do so,
> > switch vendors, it's the only way they will learn...)  I don't know how
> > long I'll keep doing this, so if you care about 3.18, please contact me
> > to let me know the expected lifespan of your device.
> > 
> > And finally, due to the delay from the last 3.18-stable kernel release,
> > there is a large backlog of patches, this is about 1/2 of the pending
> > ones so far.  I'll be working on catching up to the rest of them over
> > the next few weeks, and then the updates should be smaller than this
> > one.
> > 
> > ok, back to your normal form-letter stable -rc release notice:
> > -
> > 
> > Responses should be made by Tue Apr 18 08:01:19 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.49-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-3.18.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > [1] Google's android-common-3.18 will be tracking these releases for
> > those of you caring about a working android kernel based on 3.18, I
> > recommend using this tree:
> > https://android.googlesource.com/kernel/common/+/android-3.18
> > 
> 
> Compiled and booted on my test system. I don't have old dmesg logs to
> compare. I removed 3.18 and history from my test system. I will keep
> 3.10.49 logs for the next release.

Ah, thanks for this.  Please don't feel like you have to test 3.18 on
your system if you don't want to, I know it's a very old kernel...

greg k-h

Re: [PATCH 3.18 010/145] sctp: avoid BUG_ON on sctp_wait_for_sndbuf

[Greg Kroah-Hartman]

On Mon, Apr 17, 2017 at 05:00:50PM -0300, Marcelo Ricardo Leitner wrote:
> 
> 
> Em 16-04-2017 07:48, Greg Kroah-Hartman escreveu:
> > 3.18-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Marcelo Ricardo Leitner 
> > 
> > 
> > [ Upstream commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 ]
> 
> 
> Hi Greg. Are you also including dfcb9f4f99f1 ("sctp: deny peeloff operation
> on asocs with threads sleeping on it")
> It's a follow-up fix for this one, would be good to have it too.

Interesting, I don't see that in any of the stable trees, nor in the
networking stable queue.  David, any objection to me queueing it up for
all of the stable kernels?  I think it somehow got missed.

thanks,

greg k-h

Re: [PATCH 3.18 010/145] sctp: avoid BUG_ON on sctp_wait_for_sndbuf

[Greg Kroah-Hartman]

On Mon, Apr 17, 2017 at 05:00:50PM -0300, Marcelo Ricardo Leitner wrote:
> 
> 
> Em 16-04-2017 07:48, Greg Kroah-Hartman escreveu:
> > 3.18-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Marcelo Ricardo Leitner 
> > 
> > 
> > [ Upstream commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 ]
> 
> 
> Hi Greg. Are you also including dfcb9f4f99f1 ("sctp: deny peeloff operation
> on asocs with threads sleeping on it")
> It's a follow-up fix for this one, would be good to have it too.

Interesting, I don't see that in any of the stable trees, nor in the
networking stable queue.  David, any objection to me queueing it up for
all of the stable kernels?  I think it somehow got missed.

thanks,

greg k-h

Re: [PATCH 1/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

[Chewie Lin]

On Tue, Apr 18, 2017 at 06:14:11AM +0200, Greg KH wrote:
> On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote:
> > Swap string in the dev_warn() call with __func__ argument, instead of
> > explicitly calling the function name in the string:
> > 
> > WARNING: Prefer using "%s", __func__ to embedded function names
> > #417: FILE: main_usb.c:417:
> > +"usb_device_reset fail status=%d\n", 
> > status);
> > 
> > total: 0 errors, 1 warnings, 1058 lines checked
> > 
> > And after fix:
> > 
> > main_usb.c has no obvious style problems and is ready for 
> > submission.
> > 
> > Signed-off-by: Chewie Lin 
> > ---
> >  drivers/staging/vt6656/main_usb.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/vt6656/main_usb.c 
> > b/drivers/staging/vt6656/main_usb.c
> > index 9e074e9daf4e..71c4511b4cff 100644
> > --- a/drivers/staging/vt6656/main_usb.c
> > +++ b/drivers/staging/vt6656/main_usb.c
> > @@ -414,7 +414,7 @@ static void usb_device_reset(struct vnt_private *priv)
> > status = usb_reset_device(priv->usb);
> > if (status)
> > dev_warn(>usb->dev,
> > -"usb_device_reset fail status=%d\n", status);
> > +"%s fail status=%d\n", __func__, status);
> 
> But the call that failed was called usb_device_reset(), right?  Why is
> this function even needed at all, have the caller call the correct
> function instead please, and then this whole function can be deleted.
> 

thanks greg. 
Yes, I think that's a good approach as well. I initially wanted to fix a 
coding style problem without touching the function calls, but I can 
definitely do that as well. 

linsh

Re: [PATCH 1/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

[Chewie Lin]

On Tue, Apr 18, 2017 at 06:14:11AM +0200, Greg KH wrote:
> On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote:
> > Swap string in the dev_warn() call with __func__ argument, instead of
> > explicitly calling the function name in the string:
> > 
> > WARNING: Prefer using "%s", __func__ to embedded function names
> > #417: FILE: main_usb.c:417:
> > +"usb_device_reset fail status=%d\n", 
> > status);
> > 
> > total: 0 errors, 1 warnings, 1058 lines checked
> > 
> > And after fix:
> > 
> > main_usb.c has no obvious style problems and is ready for 
> > submission.
> > 
> > Signed-off-by: Chewie Lin 
> > ---
> >  drivers/staging/vt6656/main_usb.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/vt6656/main_usb.c 
> > b/drivers/staging/vt6656/main_usb.c
> > index 9e074e9daf4e..71c4511b4cff 100644
> > --- a/drivers/staging/vt6656/main_usb.c
> > +++ b/drivers/staging/vt6656/main_usb.c
> > @@ -414,7 +414,7 @@ static void usb_device_reset(struct vnt_private *priv)
> > status = usb_reset_device(priv->usb);
> > if (status)
> > dev_warn(>usb->dev,
> > -"usb_device_reset fail status=%d\n", status);
> > +"%s fail status=%d\n", __func__, status);
> 
> But the call that failed was called usb_device_reset(), right?  Why is
> this function even needed at all, have the caller call the correct
> function instead please, and then this whole function can be deleted.
> 

thanks greg. 
Yes, I think that's a good approach as well. I initially wanted to fix a 
coding style problem without touching the function calls, but I can 
definitely do that as well. 

linsh

Re: [PATCH] ACPICA: Export mutex functions

[Guenter Roeck]

On 04/17/2017 04:53 PM, Zheng, Lv wrote:

Hi,


From: Guenter Roeck [mailto:li...@roeck-us.net]
Subject: Re: [PATCH] ACPICA: Export mutex functions

On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote:

On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck  wrote:

On Mon, Apr 17, 2017 at 08:40:38PM +, Moore, Robert wrote:




From: Guenter Roeck [mailto:li...@roeck-us.net]
Subject: Re: [PATCH] ACPICA: Export mutex functions

On Mon, Apr 17, 2017 at 07:27:37PM +, Moore, Robert wrote:



From: Moore, Robert
Subject: RE: [PATCH] ACPICA: Export mutex functions

There is a model for the drivers to directly acquire an AML mutex
object. That is why the acquire/release public interfaces were added
to ACPICA.

I forget all of the details, but the model was developed with MS and
others during the ACPI 6.0 timeframe.



[Moore, Robert]


Here is the case where the OS may need to directly acquire an AML

mutex:


From the ACPI spec:

19.6.2 Acquire (Acquire a Mutex)

Note: For Mutex objects referenced by a _DLM object, the host OS may

also contend for ownership.



From the context in the dsdt, and from description of expected use cases
for _DLM objects I can find, this is what the mutex is used for (to
serialize access to a resource on a low pin count serial interconnect,
aka LPC).

What does that mean in practice ? That I am not supposed to use it
because it doesn't follow standard ACPI mutex declaration rules ?

Thanks,
Guenter




[Moore, Robert]

I'm not an expert on the _DLM method, but I would point you to the description 
section in the

ACPI spec, 5.7.5 _DLM (DeviceLock Mutex).




I did. However, not being an ACPI expert, that doesn't tell me anything.


Basically, if the kernel and AML need to access a device concurrently,
there should be a _DLM object under that device in the ACPI tables.
In that case it is expected to return a list of (AML) mutexes that can
be acquired by the kernel in order to synchronize device access with
respect to AML (and for each mutex it may also return a description of
the specific resources to be protected by it).

Bottom line: without _DLM, the kernel cannot synchronize things with
respect to AML properly, because it has no information how to do that
then.


That is all quite interesting. I do see the mutex in question used on various
motherboards from various vendors (I checked boards from Gigabyte, MSI, and
Intel). Interestingly, the naming seems to be consistent - it is always named
"MUT0". For the most part, it seems to be available on more recent
motherboards; older motherboards tend to use the resource without locking.
However, I don't see any mention of "_DLM" in any of the DSDTs.



OK, then you might be having problems in your opregion driver.


At the same time, access to ports 0x2e/0x2f is widely used in the kernel.
As mentioned before, it is used in watchdog, hardware monitoring, and gpio
drivers, but also in parallel port and infrared driver code. Effectively
that means that all this code is inherently unsafe on systems with ACPI
support.

I had thought about implementing a set of utility functions to make the kernel
code safer to use if the mutex is found to exist.


As what you've mentioned, there are already lots of parallel accesses in kernel 
without enabling ACPI.
Are these accesses mutually exclusive (safe)?


In-kernel, yes (using request_muxed_region). Against ACPI, no.


If so, why do you need to invent a new synchronization mechanism?



Because I am seeing a problem with the current code (more specifically,
with the it87 hwmon driver) on new Gigabyte boards.


Right now I wonder, though,
if such code would have a chance to be accepted. Any thoughts on that ?


Is that possible to make it safe in the opregion driver?



Sorry, I don't think I understand what you mean with "opregion driver".
Do you refer to the drivers accessing the memory region in question,
or in other words replicating the necessary code in every driver accessing
that region ? Sure, I can do that, if that is the preferred solution;
I have no problem with that. However, that would require exporting
the ACPI mutex functions. My understanding is that you are opposed to
exporting those, so I assume that is not what you refer to.
Can you clarify ?

Thanks,
Guenter

Re: [PATCH] ACPICA: Export mutex functions

[Guenter Roeck]

On 04/17/2017 04:53 PM, Zheng, Lv wrote:

Hi,


From: Guenter Roeck [mailto:li...@roeck-us.net]
Subject: Re: [PATCH] ACPICA: Export mutex functions

On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote:

On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck  wrote:

On Mon, Apr 17, 2017 at 08:40:38PM +, Moore, Robert wrote:




From: Guenter Roeck [mailto:li...@roeck-us.net]
Subject: Re: [PATCH] ACPICA: Export mutex functions

On Mon, Apr 17, 2017 at 07:27:37PM +, Moore, Robert wrote:



From: Moore, Robert
Subject: RE: [PATCH] ACPICA: Export mutex functions

There is a model for the drivers to directly acquire an AML mutex
object. That is why the acquire/release public interfaces were added
to ACPICA.

I forget all of the details, but the model was developed with MS and
others during the ACPI 6.0 timeframe.



[Moore, Robert]


Here is the case where the OS may need to directly acquire an AML

mutex:


From the ACPI spec:

19.6.2 Acquire (Acquire a Mutex)

Note: For Mutex objects referenced by a _DLM object, the host OS may

also contend for ownership.



From the context in the dsdt, and from description of expected use cases
for _DLM objects I can find, this is what the mutex is used for (to
serialize access to a resource on a low pin count serial interconnect,
aka LPC).

What does that mean in practice ? That I am not supposed to use it
because it doesn't follow standard ACPI mutex declaration rules ?

Thanks,
Guenter




[Moore, Robert]

I'm not an expert on the _DLM method, but I would point you to the description 
section in the

ACPI spec, 5.7.5 _DLM (DeviceLock Mutex).




I did. However, not being an ACPI expert, that doesn't tell me anything.


Basically, if the kernel and AML need to access a device concurrently,
there should be a _DLM object under that device in the ACPI tables.
In that case it is expected to return a list of (AML) mutexes that can
be acquired by the kernel in order to synchronize device access with
respect to AML (and for each mutex it may also return a description of
the specific resources to be protected by it).

Bottom line: without _DLM, the kernel cannot synchronize things with
respect to AML properly, because it has no information how to do that
then.


That is all quite interesting. I do see the mutex in question used on various
motherboards from various vendors (I checked boards from Gigabyte, MSI, and
Intel). Interestingly, the naming seems to be consistent - it is always named
"MUT0". For the most part, it seems to be available on more recent
motherboards; older motherboards tend to use the resource without locking.
However, I don't see any mention of "_DLM" in any of the DSDTs.



OK, then you might be having problems in your opregion driver.


At the same time, access to ports 0x2e/0x2f is widely used in the kernel.
As mentioned before, it is used in watchdog, hardware monitoring, and gpio
drivers, but also in parallel port and infrared driver code. Effectively
that means that all this code is inherently unsafe on systems with ACPI
support.

I had thought about implementing a set of utility functions to make the kernel
code safer to use if the mutex is found to exist.


As what you've mentioned, there are already lots of parallel accesses in kernel 
without enabling ACPI.
Are these accesses mutually exclusive (safe)?


In-kernel, yes (using request_muxed_region). Against ACPI, no.


If so, why do you need to invent a new synchronization mechanism?



Because I am seeing a problem with the current code (more specifically,
with the it87 hwmon driver) on new Gigabyte boards.


Right now I wonder, though,
if such code would have a chance to be accepted. Any thoughts on that ?


Is that possible to make it safe in the opregion driver?



Sorry, I don't think I understand what you mean with "opregion driver".
Do you refer to the drivers accessing the memory region in question,
or in other words replicating the necessary code in every driver accessing
that region ? Sure, I can do that, if that is the preferred solution;
I have no problem with that. However, that would require exporting
the ACPI mutex functions. My understanding is that you are opposed to
exporting those, so I assume that is not what you refer to.
Can you clarify ?

Thanks,
Guenter

[PATCH v6 1/2] thermal: core: Allow orderly_poweroff to be called only once

[Keerthy]

thermal_zone_device_check --> thermal_zone_device_update -->
handle_thermal_trip --> handle_critical_trips --> orderly_poweroff

The above sequence happens every 250/500 mS based on the configuration.
The orderly_poweroff function is getting called every 250/500 mS.
With a full fledged file system it takes at least 5-10 Seconds to
power off gracefully.

In that period due to the thermal_zone_device_check triggering
periodically the thermal work queues bombard with
orderly_poweroff calls multiple times eventually leading to
failures in gracefully powering off the system.

Make sure that orderly_poweroff is called only once.

Signed-off-by: Keerthy 
Acked-by: Eduardo Valentin 
---

Changes in v5:

  * Added Eduardo's Ack.

Changes in v4:

  * power_off_triggered declaration together with mutex definition.

Changes in v3:

  * Changed the place where mutex was locked and unlocked.

 drivers/thermal/thermal_core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 11f0675..8337c27 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -45,8 +45,10 @@
 
 static DEFINE_MUTEX(thermal_list_lock);
 static DEFINE_MUTEX(thermal_governor_lock);
+static DEFINE_MUTEX(poweroff_lock);
 
 static atomic_t in_suspend;
+static bool power_off_triggered;
 
 static struct thermal_governor *def_governor;
 
@@ -342,7 +344,12 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
dev_emerg(>device,
  "critical temperature reached(%d C),shutting down\n",
  tz->temperature / 1000);
-   orderly_poweroff(true);
+   mutex_lock(_lock);
+   if (!power_off_triggered) {
+   orderly_poweroff(true);
+   power_off_triggered = true;
+   }
+   mutex_unlock(_lock);
}
 }
 
@@ -1463,6 +1470,7 @@ static int __init thermal_init(void)
 {
int result;
 
+   mutex_init(_lock);
result = thermal_register_governors();
if (result)
goto error;
@@ -1497,6 +1505,7 @@ static int __init thermal_init(void)
ida_destroy(_cdev_ida);
mutex_destroy(_list_lock);
mutex_destroy(_governor_lock);
+   mutex_destroy(_lock);
return result;
 }
 
-- 
1.9.1

[PATCH v6 1/2] thermal: core: Allow orderly_poweroff to be called only once

[Keerthy]

thermal_zone_device_check --> thermal_zone_device_update -->
handle_thermal_trip --> handle_critical_trips --> orderly_poweroff

The above sequence happens every 250/500 mS based on the configuration.
The orderly_poweroff function is getting called every 250/500 mS.
With a full fledged file system it takes at least 5-10 Seconds to
power off gracefully.

In that period due to the thermal_zone_device_check triggering
periodically the thermal work queues bombard with
orderly_poweroff calls multiple times eventually leading to
failures in gracefully powering off the system.

Make sure that orderly_poweroff is called only once.

Signed-off-by: Keerthy 
Acked-by: Eduardo Valentin 
---

Changes in v5:

  * Added Eduardo's Ack.

Changes in v4:

  * power_off_triggered declaration together with mutex definition.

Changes in v3:

  * Changed the place where mutex was locked and unlocked.

 drivers/thermal/thermal_core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 11f0675..8337c27 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -45,8 +45,10 @@
 
 static DEFINE_MUTEX(thermal_list_lock);
 static DEFINE_MUTEX(thermal_governor_lock);
+static DEFINE_MUTEX(poweroff_lock);
 
 static atomic_t in_suspend;
+static bool power_off_triggered;
 
 static struct thermal_governor *def_governor;
 
@@ -342,7 +344,12 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
dev_emerg(>device,
  "critical temperature reached(%d C),shutting down\n",
  tz->temperature / 1000);
-   orderly_poweroff(true);
+   mutex_lock(_lock);
+   if (!power_off_triggered) {
+   orderly_poweroff(true);
+   power_off_triggered = true;
+   }
+   mutex_unlock(_lock);
}
 }
 
@@ -1463,6 +1470,7 @@ static int __init thermal_init(void)
 {
int result;
 
+   mutex_init(_lock);
result = thermal_register_governors();
if (result)
goto error;
@@ -1497,6 +1505,7 @@ static int __init thermal_init(void)
ida_destroy(_cdev_ida);
mutex_destroy(_list_lock);
mutex_destroy(_governor_lock);
+   mutex_destroy(_lock);
return result;
 }
 
-- 
1.9.1

[PATCH v6 2/2] thermal: core: Add a back up thermal shutdown mechanism

[Keerthy]

orderly_poweroff is triggered when a graceful shutdown
of system is desired. This may be used in many critical states of the
kernel such as when subsystems detects conditions such as critical
temperature conditions. However, in certain conditions in system
boot up sequences like those in the middle of driver probes being
initiated, userspace will be unable to power off the system in a clean
manner and leaves the system in a critical state. In cases like these,
the /sbin/poweroff will return success (having forked off to attempt
powering off the system. However, the system overall will fail to
completely poweroff (since other modules will be probed) and the system
is still functional with no userspace (since that would have shut itself
off).

However, there is no clean way of detecting such failure of userspace
powering off the system. In such scenarios, it is necessary for a backup
workqueue to be able to force a shutdown of the system when orderly
shutdown is not successful after a configurable time period.

Reported-by: Nishanth Menon 
Signed-off-by: Keerthy 
Acked-by: Eduardo Valentin 
---

Changes in v6:

  * Rephrased Kconfig description as per Eduardo's feedback.
  * Added check to verify positive values of delay in milli Seconds.

Changes in v5:

  * Mandated delay for thermal emergency poweroff to be a non-zero value.

Changes in v4:

  * Updated documentation
  * changed emergency_poweroff_func to thermal_emergency_poweroff_func

Changes in v3:

  * Removed unnecessary mutex init.
  * Added WARN messages instead of a simple warning message.
  * Added Documentation.

 Documentation/thermal/sysfs-api.txt | 21 +++
 drivers/thermal/Kconfig | 17 
 drivers/thermal/thermal_core.c  | 53 +
 3 files changed, 91 insertions(+)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index ef473dc..bb9a0a5 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -582,3 +582,24 @@ platform data is provided, this uses the step_wise 
throttling policy.
 This function serves as an arbitrator to set the state of a cooling
 device. It sets the cooling device to the deepest cooling state if
 possible.
+
+6. thermal_emergency_poweroff:
+
+On an event of critical trip temperature crossing. Thermal framework
+allows the system to shutdown gracefully by calling orderly_poweroff().
+In the event of a failure of orderly_poweroff() to shut down the system
+we are in danger of keeping the system alive at undesirably high
+temperatures. To mitigate this high risk scenario we program a work
+queue to fire after a pre-determined number of seconds to start
+an emergency shutdown of the device using the kernel_power_off()
+function. In case kernel_power_off() fails then finally
+emergency_restart() is called in the worst case.
+
+The delay should be carefully profiled so as to give adequate time for
+orderly_poweroff(). In case of failure of an orderly_poweroff() the
+emergency poweroff kicks in after the delay has elapsed and shuts down
+the system.
+
+If set to 0 emergency poweroff will not be supported. So a carefully
+profiled non-zero positive value is a must for emergerncy poweroff to be
+triggered.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9347401..74bf92b 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -15,6 +15,23 @@ menuconfig THERMAL
 
 if THERMAL
 
+config THERMAL_EMERGENCY_POWEROFF_DELAY_MS
+   int "Emergency poweroff delay in milli-seconds"
+   depends on THERMAL
+   default 0
+   help
+ Thermal subsystem will issue a graceful shutdown when
+ critical temperatures are reached using orderly_poweroff(). In
+ case of failure of an orderly_poweroff(), the thermal emergency
+ poweroff kicks in after a delay has elapsed and shuts down the system.
+ This config is number of milliseconds to delay before emergency
+ poweroff kicks in. Similarly to the critical trip point,
+ the delay should be carefully profiled so as to give adequate
+ time for orderly_poweroff() to finish on regular execution.
+ If set to 0 emergency poweroff will not be supported.
+
+ In doubt, leave as 0.
+
 config THERMAL_HWMON
bool
prompt "Expose thermal sensors as hwmon device"
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8337c27..b21b9cc 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -324,6 +324,54 @@ static void handle_non_critical_trips(struct 
thermal_zone_device *tz,
   def_governor->throttle(tz, trip);
 }
 
+/**
+ * thermal_emergency_poweroff_func - emergency poweroff work after a known 
delay
+ * @work: work_struct associated with the emergency poweroff function
+ *
+ * This function is called in 

[PATCH v6 2/2] thermal: core: Add a back up thermal shutdown mechanism

[Keerthy]

orderly_poweroff is triggered when a graceful shutdown
of system is desired. This may be used in many critical states of the
kernel such as when subsystems detects conditions such as critical
temperature conditions. However, in certain conditions in system
boot up sequences like those in the middle of driver probes being
initiated, userspace will be unable to power off the system in a clean
manner and leaves the system in a critical state. In cases like these,
the /sbin/poweroff will return success (having forked off to attempt
powering off the system. However, the system overall will fail to
completely poweroff (since other modules will be probed) and the system
is still functional with no userspace (since that would have shut itself
off).

However, there is no clean way of detecting such failure of userspace
powering off the system. In such scenarios, it is necessary for a backup
workqueue to be able to force a shutdown of the system when orderly
shutdown is not successful after a configurable time period.

Reported-by: Nishanth Menon 
Signed-off-by: Keerthy 
Acked-by: Eduardo Valentin 
---

Changes in v6:

  * Rephrased Kconfig description as per Eduardo's feedback.
  * Added check to verify positive values of delay in milli Seconds.

Changes in v5:

  * Mandated delay for thermal emergency poweroff to be a non-zero value.

Changes in v4:

  * Updated documentation
  * changed emergency_poweroff_func to thermal_emergency_poweroff_func

Changes in v3:

  * Removed unnecessary mutex init.
  * Added WARN messages instead of a simple warning message.
  * Added Documentation.

 Documentation/thermal/sysfs-api.txt | 21 +++
 drivers/thermal/Kconfig | 17 
 drivers/thermal/thermal_core.c  | 53 +
 3 files changed, 91 insertions(+)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index ef473dc..bb9a0a5 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -582,3 +582,24 @@ platform data is provided, this uses the step_wise 
throttling policy.
 This function serves as an arbitrator to set the state of a cooling
 device. It sets the cooling device to the deepest cooling state if
 possible.
+
+6. thermal_emergency_poweroff:
+
+On an event of critical trip temperature crossing. Thermal framework
+allows the system to shutdown gracefully by calling orderly_poweroff().
+In the event of a failure of orderly_poweroff() to shut down the system
+we are in danger of keeping the system alive at undesirably high
+temperatures. To mitigate this high risk scenario we program a work
+queue to fire after a pre-determined number of seconds to start
+an emergency shutdown of the device using the kernel_power_off()
+function. In case kernel_power_off() fails then finally
+emergency_restart() is called in the worst case.
+
+The delay should be carefully profiled so as to give adequate time for
+orderly_poweroff(). In case of failure of an orderly_poweroff() the
+emergency poweroff kicks in after the delay has elapsed and shuts down
+the system.
+
+If set to 0 emergency poweroff will not be supported. So a carefully
+profiled non-zero positive value is a must for emergerncy poweroff to be
+triggered.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9347401..74bf92b 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -15,6 +15,23 @@ menuconfig THERMAL
 
 if THERMAL
 
+config THERMAL_EMERGENCY_POWEROFF_DELAY_MS
+   int "Emergency poweroff delay in milli-seconds"
+   depends on THERMAL
+   default 0
+   help
+ Thermal subsystem will issue a graceful shutdown when
+ critical temperatures are reached using orderly_poweroff(). In
+ case of failure of an orderly_poweroff(), the thermal emergency
+ poweroff kicks in after a delay has elapsed and shuts down the system.
+ This config is number of milliseconds to delay before emergency
+ poweroff kicks in. Similarly to the critical trip point,
+ the delay should be carefully profiled so as to give adequate
+ time for orderly_poweroff() to finish on regular execution.
+ If set to 0 emergency poweroff will not be supported.
+
+ In doubt, leave as 0.
+
 config THERMAL_HWMON
bool
prompt "Expose thermal sensors as hwmon device"
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8337c27..b21b9cc 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -324,6 +324,54 @@ static void handle_non_critical_trips(struct 
thermal_zone_device *tz,
   def_governor->throttle(tz, trip);
 }
 
+/**
+ * thermal_emergency_poweroff_func - emergency poweroff work after a known 
delay
+ * @work: work_struct associated with the emergency poweroff function
+ *
+ * This function is called in very critical situations to force
+ * a kernel 

Re: [PATCH 2/2 v2] char: misc: use octal permissions for the proc entry

[Greg Kroah-Hartman]

On Mon, Apr 17, 2017 at 08:22:57PM +0200, Martin Kaiser wrote:
> Set the permissions for /proc/misc to 0444 explicitly. At the moment,
> we're using 0 and have proc_create_data() convert this to 0444.
> This fixes a checkpatch warning.
> 
> Signed-off-by: Martin Kaiser 
> ---
> v2:
>separate patch for each checkpatch warning
> 
>  drivers/char/misc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/char/misc.c b/drivers/char/misc.c
> index 3447b2e..3c633d5 100644
> --- a/drivers/char/misc.c
> +++ b/drivers/char/misc.c
> @@ -280,7 +280,7 @@ static int __init misc_init(void)
>   int err;
>   struct proc_dir_entry *ret;
>  
> - ret = proc_create("misc", 0, NULL, _proc_fops);
> + ret = proc_create("misc", 0444, NULL, _proc_fops);

What checkpatch warning does this fix?  0 is a number :)

thanks,

greg k-h

Re: [PATCH 2/2 v2] char: misc: use octal permissions for the proc entry

[Greg Kroah-Hartman]

On Mon, Apr 17, 2017 at 08:22:57PM +0200, Martin Kaiser wrote:
> Set the permissions for /proc/misc to 0444 explicitly. At the moment,
> we're using 0 and have proc_create_data() convert this to 0444.
> This fixes a checkpatch warning.
> 
> Signed-off-by: Martin Kaiser 
> ---
> v2:
>separate patch for each checkpatch warning
> 
>  drivers/char/misc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/char/misc.c b/drivers/char/misc.c
> index 3447b2e..3c633d5 100644
> --- a/drivers/char/misc.c
> +++ b/drivers/char/misc.c
> @@ -280,7 +280,7 @@ static int __init misc_init(void)
>   int err;
>   struct proc_dir_entry *ret;
>  
> - ret = proc_create("misc", 0, NULL, _proc_fops);
> + ret = proc_create("misc", 0444, NULL, _proc_fops);

What checkpatch warning does this fix?  0 is a number :)

thanks,

greg k-h

Re: [PATCH 1/4] added SECURITY_TIOCSTI_RESTRICT kernel config

[Matt Brown]

On 04/17/2017 02:50 AM, Greg KH wrote:

On Mon, Apr 17, 2017 at 02:07:03AM -0400, Matt Brown wrote:

adding the kernel config SECURITY_TIOCSTI_RESTRICT in order to allow
the user to restrict unprivileged command injection using TIOCSTI
tty ioctls


"unpriviledged command injection"?  That sounds a bit "odd", don't you
think?



Signed-off-by: Matt Brown 
---
 security/Kconfig | 12 
 1 file changed, 12 insertions(+)

diff --git a/security/Kconfig b/security/Kconfig
index 3ff1bf9..d757bcb 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -18,6 +18,18 @@ config SECURITY_DMESG_RESTRICT

  If you are unsure how to answer this question, answer N.

+config SECURITY_TIOCSTI_RESTRICT
+bool "Restrict unprivileged use of tiocsti command injection"
+default n
+help
+ This enforces restrictions on unprivileged users injecting commands
+ into other processes in the same tty session using the TIOCSTI ioctl


Tabs and spaces?



Sorry about that. Used the wrong vimrc for part of the Kconfig. Will
fix in updated patch.


Since tty sessions are usually separated by different users, how would
they have the same one and yet need something like this?

Also, why not put this in the tty config section?

And finally, this patch on its own doesn't do anything :(



I will take your input, update my code, and resubmit as a single
patch.


thanks,

greg k-h

Re: [PATCH 1/4] added SECURITY_TIOCSTI_RESTRICT kernel config

[Matt Brown]

On 04/17/2017 02:50 AM, Greg KH wrote:

On Mon, Apr 17, 2017 at 02:07:03AM -0400, Matt Brown wrote:

adding the kernel config SECURITY_TIOCSTI_RESTRICT in order to allow
the user to restrict unprivileged command injection using TIOCSTI
tty ioctls


"unpriviledged command injection"?  That sounds a bit "odd", don't you
think?



Signed-off-by: Matt Brown 
---
 security/Kconfig | 12 
 1 file changed, 12 insertions(+)

diff --git a/security/Kconfig b/security/Kconfig
index 3ff1bf9..d757bcb 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -18,6 +18,18 @@ config SECURITY_DMESG_RESTRICT

  If you are unsure how to answer this question, answer N.

+config SECURITY_TIOCSTI_RESTRICT
+bool "Restrict unprivileged use of tiocsti command injection"
+default n
+help
+ This enforces restrictions on unprivileged users injecting commands
+ into other processes in the same tty session using the TIOCSTI ioctl


Tabs and spaces?



Sorry about that. Used the wrong vimrc for part of the Kconfig. Will
fix in updated patch.


Since tty sessions are usually separated by different users, how would
they have the same one and yet need something like this?

Also, why not put this in the tty config section?

And finally, this patch on its own doesn't do anything :(



I will take your input, update my code, and resubmit as a single
patch.


thanks,

greg k-h

Re: [PATCH v5 0/3] vfio/type1: Synchronous locked page accounting

[Peter Xu]

On Mon, Apr 17, 2017 at 04:37:38PM -0600, Alex Williamson wrote:
> v5:
>   - patch 1/ Use bool* to cleanup vfio_lock_acct() callers; sorry
>  we cannot re-test CAP_IPC_LOCK for all callers
>   - patch 2/ Re-add pr_warn, add Kirti's R-b
>   - patch 3/ NEW, analyzing impact of vfio_lock_acct() testing
>  CAP_IPC_LOCK for all callers revealed a long hanging
>  optimization
> 
> Thanks for the reviews, keep 'em coming,

All patches looks good to me.

Reviewed-by: Peter Xu 

Thanks!

-- 
Peter Xu

Re: [PATCH v5 0/3] vfio/type1: Synchronous locked page accounting

[Peter Xu]

On Mon, Apr 17, 2017 at 04:37:38PM -0600, Alex Williamson wrote:
> v5:
>   - patch 1/ Use bool* to cleanup vfio_lock_acct() callers; sorry
>  we cannot re-test CAP_IPC_LOCK for all callers
>   - patch 2/ Re-add pr_warn, add Kirti's R-b
>   - patch 3/ NEW, analyzing impact of vfio_lock_acct() testing
>  CAP_IPC_LOCK for all callers revealed a long hanging
>  optimization
> 
> Thanks for the reviews, keep 'em coming,

All patches looks good to me.

Reviewed-by: Peter Xu 

Thanks!

-- 
Peter Xu

Re: [PATCH 1/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

[Greg KH]

On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote:
> Swap string in the dev_warn() call with __func__ argument, instead of
> explicitly calling the function name in the string:
> 
> WARNING: Prefer using "%s", __func__ to embedded function names
> #417: FILE: main_usb.c:417:
> +"usb_device_reset fail status=%d\n", status);
> 
> total: 0 errors, 1 warnings, 1058 lines checked
> 
> And after fix:
> 
> main_usb.c has no obvious style problems and is ready for submission.
> 
> Signed-off-by: Chewie Lin 
> ---
>  drivers/staging/vt6656/main_usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/vt6656/main_usb.c 
> b/drivers/staging/vt6656/main_usb.c
> index 9e074e9daf4e..71c4511b4cff 100644
> --- a/drivers/staging/vt6656/main_usb.c
> +++ b/drivers/staging/vt6656/main_usb.c
> @@ -414,7 +414,7 @@ static void usb_device_reset(struct vnt_private *priv)
>   status = usb_reset_device(priv->usb);
>   if (status)
>   dev_warn(>usb->dev,
> -  "usb_device_reset fail status=%d\n", status);
> +  "%s fail status=%d\n", __func__, status);

But the call that failed was called usb_device_reset(), right?  Why is
this function even needed at all, have the caller call the correct
function instead please, and then this whole function can be deleted.

thanks,

greg k-h

Re: [PATCH 1/1] drivers/staging/vt6656/main_usb.c: checkpatch warning

[Greg KH]

On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote:
> Swap string in the dev_warn() call with __func__ argument, instead of
> explicitly calling the function name in the string:
> 
> WARNING: Prefer using "%s", __func__ to embedded function names
> #417: FILE: main_usb.c:417:
> +"usb_device_reset fail status=%d\n", status);
> 
> total: 0 errors, 1 warnings, 1058 lines checked
> 
> And after fix:
> 
> main_usb.c has no obvious style problems and is ready for submission.
> 
> Signed-off-by: Chewie Lin 
> ---
>  drivers/staging/vt6656/main_usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/vt6656/main_usb.c 
> b/drivers/staging/vt6656/main_usb.c
> index 9e074e9daf4e..71c4511b4cff 100644
> --- a/drivers/staging/vt6656/main_usb.c
> +++ b/drivers/staging/vt6656/main_usb.c
> @@ -414,7 +414,7 @@ static void usb_device_reset(struct vnt_private *priv)
>   status = usb_reset_device(priv->usb);
>   if (status)
>   dev_warn(>usb->dev,
> -  "usb_device_reset fail status=%d\n", status);
> +  "%s fail status=%d\n", __func__, status);

But the call that failed was called usb_device_reset(), right?  Why is
this function even needed at all, have the caller call the correct
function instead please, and then this whole function can be deleted.

thanks,

greg k-h

Re: [PATCH v5 2/2] thermal: core: Add a back up thermal shutdown mechanism

[Keerthy]

On Monday 17 April 2017 10:46 PM, Eduardo Valentin wrote:
> On Sat, Apr 15, 2017 at 08:38:29AM +0530, Keerthy wrote:
>> orderly_poweroff is triggered when a graceful shutdown
>> of system is desired. This may be used in many critical states of the
>> kernel such as when subsystems detects conditions such as critical
>> temperature conditions. However, in certain conditions in system
>> boot up sequences like those in the middle of driver probes being
>> initiated, userspace will be unable to power off the system in a clean
>> manner and leaves the system in a critical state. In cases like these,
>> the /sbin/poweroff will return success (having forked off to attempt
>> powering off the system. However, the system overall will fail to
>> completely poweroff (since other modules will be probed) and the system
>> is still functional with no userspace (since that would have shut itself
>> off).
>>
>> However, there is no clean way of detecting such failure of userspace
>> powering off the system. In such scenarios, it is necessary for a backup
>> workqueue to be able to force a shutdown of the system when orderly
>> shutdown is not successful after a configurable time period.
>>
>> Reported-by: Nishanth Menon 
>> Signed-off-by: Keerthy 
>> ---
>>
>> Changes in v5:
>>
>>   * Mandated delay for thermal emergency poweroff to be a non-zero value.
>>
>> Changes in v4:
>>
>>   * Updated documentation
>>   * changed emergency_poweroff_func to thermal_emergency_poweroff_func
>>
>> Changes in v3:
>>
>>   * Removed unnecessary mutex init.
>>   * Added WARN messages instead of a simple warning message.
>>   * Added Documentation.
>>
>>  Documentation/thermal/sysfs-api.txt | 21 +++
>>  drivers/thermal/Kconfig | 15 +++
>>  drivers/thermal/thermal_core.c  | 53 
>> +
>>  3 files changed, 89 insertions(+)
>>
>> diff --git a/Documentation/thermal/sysfs-api.txt 
>> b/Documentation/thermal/sysfs-api.txt
>> index ef473dc..98dc04f 100644
>> --- a/Documentation/thermal/sysfs-api.txt
>> +++ b/Documentation/thermal/sysfs-api.txt
>> @@ -582,3 +582,24 @@ platform data is provided, this uses the step_wise 
>> throttling policy.
>>  This function serves as an arbitrator to set the state of a cooling
>>  device. It sets the cooling device to the deepest cooling state if
>>  possible.
>> +
>> +6. thermal_emergency_poweroff:
>> +
>> +On an event of critical trip temperature crossing. Thermal framework
>> +allows the system to shutdown gracefully by calling orderly_poweroff().
>> +In the event of a failure of orderly_poweroff() to shut down the system
>> +we are in danger of keeping the system alive at undesirably high
>> +temperatures. To mitigate this high risk scenario we program a work
>> +queue to fire after a pre-determined number of seconds to start
>> +an emergency shutdown of the device using the kernel_power_off()
>> +function. In case kernel_power_off() fails then finally
>> +emergency_restart() is called in the worst case.
>> +
>> +The delay should be carefully profiled so as to give adequate time for
>> +orderly_poweroff(). In case of failure of an orderly_poweroff() the
>> +emergency poweroff kicks in after the delay has elapsed and shuts down
>> +the system.
>> +
>> +If set to 0 emergency poweroff will not be supported. So a carefully
>> +profiled non-zero positive value is a must for emergerncy poweroff to be
>> +triggered.
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 9347401..2a748a6 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -15,6 +15,21 @@ menuconfig THERMAL
>>  
>>  if THERMAL
>>  
>> +config THERMAL_EMERGENCY_POWEROFF_DELAY_MS
>> +int "Emergency poweroff delay in milli-seconds"
>> +depends on THERMAL
>> +default 0
>> +help
>> +  The number of milliseconds to delay before emergency
>> +  poweroff kicks in. The delay should be carefully profiled
>> +  so as to give adequate time for orderly_poweroff(). In case
>> +  of failure of an orderly_poweroff() the emergency poweroff
>> +  kicks in after the delay has elapsed and shuts down the system.
>> +
>> +  If set to 0 emergency poweroff will not be supported. So a carefully
>> +  profiled non-zero positive value is a must for emergerncy poweroff to 
>> be
>> +  triggered.
> 
> Here is a suggestion for rephrase the above:
> 
>  +help
>  +  Thermal subsystem will issue a graceful shutdown when
>  +  critical temperatures are reached using orderly_poweroff(). In
>  +  case of failure of an orderly_poweroff(), the thermal emergency 
> poweroff
>  +  kicks in after a delay has elapsed and shuts down the system.
>  +  This config is number of milliseconds to delay before emergency
>  +  poweroff kicks in. Similarly to the critical trip point,
>  +  the delay should be carefully profiled so as to give adequate
>  +  time for 

Re: [PATCH v5 2/2] thermal: core: Add a back up thermal shutdown mechanism

[Keerthy]

On Monday 17 April 2017 10:46 PM, Eduardo Valentin wrote:
> On Sat, Apr 15, 2017 at 08:38:29AM +0530, Keerthy wrote:
>> orderly_poweroff is triggered when a graceful shutdown
>> of system is desired. This may be used in many critical states of the
>> kernel such as when subsystems detects conditions such as critical
>> temperature conditions. However, in certain conditions in system
>> boot up sequences like those in the middle of driver probes being
>> initiated, userspace will be unable to power off the system in a clean
>> manner and leaves the system in a critical state. In cases like these,
>> the /sbin/poweroff will return success (having forked off to attempt
>> powering off the system. However, the system overall will fail to
>> completely poweroff (since other modules will be probed) and the system
>> is still functional with no userspace (since that would have shut itself
>> off).
>>
>> However, there is no clean way of detecting such failure of userspace
>> powering off the system. In such scenarios, it is necessary for a backup
>> workqueue to be able to force a shutdown of the system when orderly
>> shutdown is not successful after a configurable time period.
>>
>> Reported-by: Nishanth Menon 
>> Signed-off-by: Keerthy 
>> ---
>>
>> Changes in v5:
>>
>>   * Mandated delay for thermal emergency poweroff to be a non-zero value.
>>
>> Changes in v4:
>>
>>   * Updated documentation
>>   * changed emergency_poweroff_func to thermal_emergency_poweroff_func
>>
>> Changes in v3:
>>
>>   * Removed unnecessary mutex init.
>>   * Added WARN messages instead of a simple warning message.
>>   * Added Documentation.
>>
>>  Documentation/thermal/sysfs-api.txt | 21 +++
>>  drivers/thermal/Kconfig | 15 +++
>>  drivers/thermal/thermal_core.c  | 53 
>> +
>>  3 files changed, 89 insertions(+)
>>
>> diff --git a/Documentation/thermal/sysfs-api.txt 
>> b/Documentation/thermal/sysfs-api.txt
>> index ef473dc..98dc04f 100644
>> --- a/Documentation/thermal/sysfs-api.txt
>> +++ b/Documentation/thermal/sysfs-api.txt
>> @@ -582,3 +582,24 @@ platform data is provided, this uses the step_wise 
>> throttling policy.
>>  This function serves as an arbitrator to set the state of a cooling
>>  device. It sets the cooling device to the deepest cooling state if
>>  possible.
>> +
>> +6. thermal_emergency_poweroff:
>> +
>> +On an event of critical trip temperature crossing. Thermal framework
>> +allows the system to shutdown gracefully by calling orderly_poweroff().
>> +In the event of a failure of orderly_poweroff() to shut down the system
>> +we are in danger of keeping the system alive at undesirably high
>> +temperatures. To mitigate this high risk scenario we program a work
>> +queue to fire after a pre-determined number of seconds to start
>> +an emergency shutdown of the device using the kernel_power_off()
>> +function. In case kernel_power_off() fails then finally
>> +emergency_restart() is called in the worst case.
>> +
>> +The delay should be carefully profiled so as to give adequate time for
>> +orderly_poweroff(). In case of failure of an orderly_poweroff() the
>> +emergency poweroff kicks in after the delay has elapsed and shuts down
>> +the system.
>> +
>> +If set to 0 emergency poweroff will not be supported. So a carefully
>> +profiled non-zero positive value is a must for emergerncy poweroff to be
>> +triggered.
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 9347401..2a748a6 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -15,6 +15,21 @@ menuconfig THERMAL
>>  
>>  if THERMAL
>>  
>> +config THERMAL_EMERGENCY_POWEROFF_DELAY_MS
>> +int "Emergency poweroff delay in milli-seconds"
>> +depends on THERMAL
>> +default 0
>> +help
>> +  The number of milliseconds to delay before emergency
>> +  poweroff kicks in. The delay should be carefully profiled
>> +  so as to give adequate time for orderly_poweroff(). In case
>> +  of failure of an orderly_poweroff() the emergency poweroff
>> +  kicks in after the delay has elapsed and shuts down the system.
>> +
>> +  If set to 0 emergency poweroff will not be supported. So a carefully
>> +  profiled non-zero positive value is a must for emergerncy poweroff to 
>> be
>> +  triggered.
> 
> Here is a suggestion for rephrase the above:
> 
>  +help
>  +  Thermal subsystem will issue a graceful shutdown when
>  +  critical temperatures are reached using orderly_poweroff(). In
>  +  case of failure of an orderly_poweroff(), the thermal emergency 
> poweroff
>  +  kicks in after a delay has elapsed and shuts down the system.
>  +  This config is number of milliseconds to delay before emergency
>  +  poweroff kicks in. Similarly to the critical trip point,
>  +  the delay should be carefully profiled so as to give adequate
>  +  time for orderly_poweroff() to finish on 

Re: [PATCH v2] efi: Config options to assign versions in the PE-COFF header

[Gary Lin]

On Mon, Apr 17, 2017 at 11:09:38AM -0700, Roy Franz (HPE) wrote:
> On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin  wrote:
> > On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote:
> >> On 13 April 2017 at 04:58, Gary Lin  wrote:
> >> > This commit adds the new config options to allow the user to modify the
> >> > following fields in the PE-COFF header.
> >> >
> >> > UINT16 MajorOperatingSystemVersion
> >> > UINT16 MinorOperatingSystemVersion
> >> > UINT16 MajorImageVersion
> >> > UINT16 MinorImageVersion
> >> >
> >> > Those fields are mainly for the executables or libraries in Windows NT
> >> > or higher to specify the minimum supported Windows version and the
> >> > version of the image itself.
> >> >
> >> > Given the fact that those fields are ignored in UEFI, we can safely reuse
> >> > those fields for other purposes, e.g. Security Version(*).
> >> >
> >> > (*) https://github.com/lcp/shim/wiki/Security-Version
> >> >
> >> > v2 changes:
> >> > - Modify the header direct instead of using an external script as
> >> >   suggested by Ard Biesheuvel
> >> > - Include arm and arm64
> >> >
> >>
> >> Thanks for the update. Could we put the Kconfig changes in
> >> drivers/firmware/efi/Kconfig, rather than duplicating them 3 times?
> >
> > Sure. Will send a v3 to update Kconfig.
> >
> > Thanks,
> >
> > Gary Lin
> 
> I think it would be nice to have a comment in the code (or maybe help
> in the kconfig, or Documentation/efi-stub.txt) that indicates the
> expected use of these variables, as the field names and PE/COFF spec
> won't help here.
> 
Agree. Since HPA has the concern about using the PE/COFF header, I just
raised the issue to UEFI forum and wait for the response. I'll update the
patch and document after sorting out the problem.

Thanks,

Gary Lin

> Thanks,
> Roy
> 
> >
> >>
> >> > Cc: Russell King 
> >> > Cc: Matt Fleming 
> >> > Cc: Ard Biesheuvel 
> >> > Cc: Catalin Marinas 
> >> > Cc: Will Deacon 
> >> > Cc: Thomas Gleixner 
> >> > Cc: Ingo Molnar 
> >> > Cc: "H. Peter Anvin" 
> >> > Cc: Joey Lee 
> >> > Cc: Vojtech Pavlik 
> >> > Signed-off-by: Gary Lin 
> >> > ---
> >> >  arch/arm/Kconfig  | 24 
> >> >  arch/arm/boot/compressed/efi-header.S |  8 
> >> >  arch/arm64/Kconfig| 24 
> >> >  arch/arm64/kernel/head.S  |  8 
> >> >  arch/x86/Kconfig  | 24 
> >> >  arch/x86/boot/header.S|  8 
> >> >  6 files changed, 84 insertions(+), 12 deletions(-)
> >> >
> >> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> > index 0d4e71b42c77..4965ad2ccc23 100644
> >> > --- a/arch/arm/Kconfig
> >> > +++ b/arch/arm/Kconfig
> >> > @@ -2090,6 +2090,30 @@ config EFI
> >> >   is only useful for kernels that may run on systems that have
> >> >   UEFI firmware.
> >> >
> >> > +config EFI_MAJOR_OS
> >> > +   hex "EFI Major OS Version"
> >> > +   range 0x0 0x
> >> > +   default "0x0"
> >> > +   depends on EFI_STUB
> >> > +
> >> > +config EFI_MINOR_OS
> >> > +   hex "EFI Minor OS Version"
> >> > +   range 0x0 0x
> >> > +   default "0x0"
> >> > +   depends on EFI_STUB
> >> > +
> >> > +config EFI_MAJOR_IMAGE
> >> > +   hex "EFI Major Image Version"
> >> > +   range 0x0 0x
> >> > +   default "0x0"
> >> > +   depends on EFI_STUB
> >> > +
> >> > +config EFI_MINOR_IMAGE
> >> > +   hex "EFI Minor Image Version"
> >> > +   range 0x0 0x
> >> > +   default "0x0"
> >> > +   depends on EFI_STUB
> >> > +
> >> >  endmenu
> >> >
> >> >  menu "CPU Power Management"
> >> > diff --git a/arch/arm/boot/compressed/efi-header.S 
> >> > b/arch/arm/boot/compressed/efi-header.S
> >> > index 9d5dc4fda3c1..67715472a76f 100644
> >> > --- a/arch/arm/boot/compressed/efi-header.S
> >> > +++ b/arch/arm/boot/compressed/efi-header.S
> >> > @@ -69,10 +69,10 @@ extra_header_fields:
> >> > .long   0   @ ImageBase
> >> > .long   0x200   @ SectionAlignment
> >> > .long   0x200   @ FileAlignment
> >> > -   .short  0   @ 
> >> > MajorOperatingSystemVersion
> >> > -   .short  0   @ 
> >> > MinorOperatingSystemVersion
> >> > -   .short  0   @ MajorImageVersion
> >> > -   .short  0   @ MinorImageVersion
> >> > +   .short  CONFIG_EFI_MAJOR_OS @ 
> >> > MajorOperatingSystemVersion
> >> > +   .short  CONFIG_EFI_MINOR_OS @ 
> >> > MinorOperatingSystemVersion
> >> > +   .short  

Re: [PATCH v2] efi: Config options to assign versions in the PE-COFF header

[Gary Lin]

On Mon, Apr 17, 2017 at 11:09:38AM -0700, Roy Franz (HPE) wrote:
> On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin  wrote:
> > On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote:
> >> On 13 April 2017 at 04:58, Gary Lin  wrote:
> >> > This commit adds the new config options to allow the user to modify the
> >> > following fields in the PE-COFF header.
> >> >
> >> > UINT16 MajorOperatingSystemVersion
> >> > UINT16 MinorOperatingSystemVersion
> >> > UINT16 MajorImageVersion
> >> > UINT16 MinorImageVersion
> >> >
> >> > Those fields are mainly for the executables or libraries in Windows NT
> >> > or higher to specify the minimum supported Windows version and the
> >> > version of the image itself.
> >> >
> >> > Given the fact that those fields are ignored in UEFI, we can safely reuse
> >> > those fields for other purposes, e.g. Security Version(*).
> >> >
> >> > (*) https://github.com/lcp/shim/wiki/Security-Version
> >> >
> >> > v2 changes:
> >> > - Modify the header direct instead of using an external script as
> >> >   suggested by Ard Biesheuvel
> >> > - Include arm and arm64
> >> >
> >>
> >> Thanks for the update. Could we put the Kconfig changes in
> >> drivers/firmware/efi/Kconfig, rather than duplicating them 3 times?
> >
> > Sure. Will send a v3 to update Kconfig.
> >
> > Thanks,
> >
> > Gary Lin
> 
> I think it would be nice to have a comment in the code (or maybe help
> in the kconfig, or Documentation/efi-stub.txt) that indicates the
> expected use of these variables, as the field names and PE/COFF spec
> won't help here.
> 
Agree. Since HPA has the concern about using the PE/COFF header, I just
raised the issue to UEFI forum and wait for the response. I'll update the
patch and document after sorting out the problem.

Thanks,

Gary Lin

> Thanks,
> Roy
> 
> >
> >>
> >> > Cc: Russell King 
> >> > Cc: Matt Fleming 
> >> > Cc: Ard Biesheuvel 
> >> > Cc: Catalin Marinas 
> >> > Cc: Will Deacon 
> >> > Cc: Thomas Gleixner 
> >> > Cc: Ingo Molnar 
> >> > Cc: "H. Peter Anvin" 
> >> > Cc: Joey Lee 
> >> > Cc: Vojtech Pavlik 
> >> > Signed-off-by: Gary Lin 
> >> > ---
> >> >  arch/arm/Kconfig  | 24 
> >> >  arch/arm/boot/compressed/efi-header.S |  8 
> >> >  arch/arm64/Kconfig| 24 
> >> >  arch/arm64/kernel/head.S  |  8 
> >> >  arch/x86/Kconfig  | 24 
> >> >  arch/x86/boot/header.S|  8 
> >> >  6 files changed, 84 insertions(+), 12 deletions(-)
> >> >
> >> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> > index 0d4e71b42c77..4965ad2ccc23 100644
> >> > --- a/arch/arm/Kconfig
> >> > +++ b/arch/arm/Kconfig
> >> > @@ -2090,6 +2090,30 @@ config EFI
> >> >   is only useful for kernels that may run on systems that have
> >> >   UEFI firmware.
> >> >
> >> > +config EFI_MAJOR_OS
> >> > +   hex "EFI Major OS Version"
> >> > +   range 0x0 0x
> >> > +   default "0x0"
> >> > +   depends on EFI_STUB
> >> > +
> >> > +config EFI_MINOR_OS
> >> > +   hex "EFI Minor OS Version"
> >> > +   range 0x0 0x
> >> > +   default "0x0"
> >> > +   depends on EFI_STUB
> >> > +
> >> > +config EFI_MAJOR_IMAGE
> >> > +   hex "EFI Major Image Version"
> >> > +   range 0x0 0x
> >> > +   default "0x0"
> >> > +   depends on EFI_STUB
> >> > +
> >> > +config EFI_MINOR_IMAGE
> >> > +   hex "EFI Minor Image Version"
> >> > +   range 0x0 0x
> >> > +   default "0x0"
> >> > +   depends on EFI_STUB
> >> > +
> >> >  endmenu
> >> >
> >> >  menu "CPU Power Management"
> >> > diff --git a/arch/arm/boot/compressed/efi-header.S 
> >> > b/arch/arm/boot/compressed/efi-header.S
> >> > index 9d5dc4fda3c1..67715472a76f 100644
> >> > --- a/arch/arm/boot/compressed/efi-header.S
> >> > +++ b/arch/arm/boot/compressed/efi-header.S
> >> > @@ -69,10 +69,10 @@ extra_header_fields:
> >> > .long   0   @ ImageBase
> >> > .long   0x200   @ SectionAlignment
> >> > .long   0x200   @ FileAlignment
> >> > -   .short  0   @ 
> >> > MajorOperatingSystemVersion
> >> > -   .short  0   @ 
> >> > MinorOperatingSystemVersion
> >> > -   .short  0   @ MajorImageVersion
> >> > -   .short  0   @ MinorImageVersion
> >> > +   .short  CONFIG_EFI_MAJOR_OS @ 
> >> > MajorOperatingSystemVersion
> >> > +   .short  CONFIG_EFI_MINOR_OS @ 
> >> > MinorOperatingSystemVersion
> >> > +   .short  CONFIG_EFI_MAJOR_IMAGE  @ MajorImageVersion
> >> > +   .short  CONFIG_EFI_MINOR_IMAGE  @ MinorImageVersion
> >> > .short  0   @ MajorSubsystemVersion
> >> > .short  0   

Re: cgroup: avoid attaching a cgroup root to two different superblocks

[Andrei Vagin]

On Mon, Apr 17, 2017 at 06:41:38PM +0800, Zefan Li wrote:
> On 2017/4/15 7:32, Andrei Vagin wrote:
> > On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote:
> >> Hello,
> >>
> >> One of our CRIU tests hangs with this patch.
> >>
> >> Steps to reproduce:
> >> curl -o cgroupns.c 
> >> https://gist.githubusercontent.com/avagin/f87c8a8bd2a0de9afcc74976327786bc/raw/5843701ef3679f50dd2427cf57a80871082eb28c/gistfile1.txt
> >> gcc cgroupns.c -o cgroupns
> >> ./cgroupns
> >> ./cgroupns
> > 
> > I've found a trivial reproducer:
> > mkdir /tmp/xxx
> > mount -t cgroup -o none,name=zdtmtst xxx /tmp/xxx
> > mkdir /tmp/xxx/xxx
> > umount /tmp/xxx
> > mount -t cgroup -o none,name=zdtmtst xxx /tmp/xxx
> > 
> 
> Now I remember why it didn't check NULL pointer... Could you try the 
> following fix?
> It also reverts my previous patch. I would appreciate if you run the full 
> test suit,
> to make sure it won't break anything.

It works for me. Thanks.

Tested-by: Andrei Vagin 

> 
> PS: Tejun, I found recently I can no longer receive your emails. Don't know 
> why...
> 
> ===
> 
> [PATCH] cgruop: avoid attaching a cgroup root to two different superblocks, 
> take 2
> 
> Commit bfb0b80db5f9 is broken. Now we try to fix the race by delaying
> the initialization of cgroup root refcnt until a superblock has been
> allocated.
> 
> Cc: sta...@vger.kernel.org # 3.16+
> Reported-by: Dmitry Vyukov 
> Reported-by: Andrei Vagin 
> Signed-off-by: Zefan Li 
> ---
>  kernel/cgroup/cgroup-internal.h |  2 +-
>  kernel/cgroup/cgroup-v1.c   | 18 --
>  kernel/cgroup/cgroup.c  |  8 
>  3 files changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
> index 9203bfb..e470268 100644
> --- a/kernel/cgroup/cgroup-internal.h
> +++ b/kernel/cgroup/cgroup-internal.h
> @@ -163,7 +163,7 @@ int cgroup_path_ns_locked(struct cgroup *cgrp, char *buf, 
> size_t buflen,
>  
>  void cgroup_free_root(struct cgroup_root *root);
>  void init_cgroup_root(struct cgroup_root *root, struct cgroup_sb_opts *opts);
> -int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask);
> +int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask, int ref_flags);
>  int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask);
>  struct dentry *cgroup_do_mount(struct file_system_type *fs_type, int flags,
>  struct cgroup_root *root, unsigned long magic,
> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
> index 12e19f0..6ca9b12 100644
> --- a/kernel/cgroup/cgroup-v1.c
> +++ b/kernel/cgroup/cgroup-v1.c
> @@ -1072,6 +1072,7 @@ struct dentry *cgroup1_mount(struct file_system_type 
> *fs_type, int flags,
>   struct cgroup_subsys *ss;
>   struct dentry *dentry;
>   int i, ret;
> + bool new_root = false;
>  
>   cgroup_lock_and_drain_offline(_dfl_root.cgrp);
>  
> @@ -1146,7 +1147,7 @@ struct dentry *cgroup1_mount(struct file_system_type 
> *fs_type, int flags,
>* path is super cold.  Let's just sleep a bit and retry.
>*/
>   pinned_sb = kernfs_pin_sb(root->kf_root, NULL);
> - if (IS_ERR_OR_NULL(pinned_sb) ||
> + if (IS_ERR(pinned_sb) ||
>   !percpu_ref_tryget_live(>cgrp.self.refcnt)) {
>   mutex_unlock(_mutex);
>   if (!IS_ERR_OR_NULL(pinned_sb))
> @@ -1181,10 +1182,11 @@ struct dentry *cgroup1_mount(struct file_system_type 
> *fs_type, int flags,
>   ret = -ENOMEM;
>   goto out_unlock;
>   }
> + new_root = true;
>  
>   init_cgroup_root(root, );
>  
> - ret = cgroup_setup_root(root, opts.subsys_mask);
> + ret = cgroup_setup_root(root, opts.subsys_mask, PERCPU_REF_INIT_DEAD);
>   if (ret)
>   cgroup_free_root(root);
>  
> @@ -1201,6 +1203,18 @@ struct dentry *cgroup1_mount(struct file_system_type 
> *fs_type, int flags,
>CGROUP_SUPER_MAGIC, ns);
>  
>   /*
> +  * There's a race window after we release cgroup_mutex and before
> +  * allocating a superblock. Make sure a concurrent process won't
> +  * be able to re-use the root during this window by delaying the
> +  * initialization of root refcnt.
> +  */
> + if (new_root) {
> + mutex_lock(_mutex);
> + percpu_ref_reinit(>cgrp.self.refcnt);
> + mutex_unlock(_mutex);
> + }
> +
> + /*
>* If @pinned_sb, we're reusing an existing root and holding an
>* extra ref on its sb.  Mount is complete.  Put the extra ref.
>*/
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 4885132..0f98010 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -1640,7 +1640,7 @@ void init_cgroup_root(struct cgroup_root *root, struct 
> 

Re: cgroup: avoid attaching a cgroup root to two different superblocks

[Andrei Vagin]

On Mon, Apr 17, 2017 at 06:41:38PM +0800, Zefan Li wrote:
> On 2017/4/15 7:32, Andrei Vagin wrote:
> > On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote:
> >> Hello,
> >>
> >> One of our CRIU tests hangs with this patch.
> >>
> >> Steps to reproduce:
> >> curl -o cgroupns.c 
> >> https://gist.githubusercontent.com/avagin/f87c8a8bd2a0de9afcc74976327786bc/raw/5843701ef3679f50dd2427cf57a80871082eb28c/gistfile1.txt
> >> gcc cgroupns.c -o cgroupns
> >> ./cgroupns
> >> ./cgroupns
> > 
> > I've found a trivial reproducer:
> > mkdir /tmp/xxx
> > mount -t cgroup -o none,name=zdtmtst xxx /tmp/xxx
> > mkdir /tmp/xxx/xxx
> > umount /tmp/xxx
> > mount -t cgroup -o none,name=zdtmtst xxx /tmp/xxx
> > 
> 
> Now I remember why it didn't check NULL pointer... Could you try the 
> following fix?
> It also reverts my previous patch. I would appreciate if you run the full 
> test suit,
> to make sure it won't break anything.

It works for me. Thanks.

Tested-by: Andrei Vagin 

> 
> PS: Tejun, I found recently I can no longer receive your emails. Don't know 
> why...
> 
> ===
> 
> [PATCH] cgruop: avoid attaching a cgroup root to two different superblocks, 
> take 2
> 
> Commit bfb0b80db5f9 is broken. Now we try to fix the race by delaying
> the initialization of cgroup root refcnt until a superblock has been
> allocated.
> 
> Cc: sta...@vger.kernel.org # 3.16+
> Reported-by: Dmitry Vyukov 
> Reported-by: Andrei Vagin 
> Signed-off-by: Zefan Li 
> ---
>  kernel/cgroup/cgroup-internal.h |  2 +-
>  kernel/cgroup/cgroup-v1.c   | 18 --
>  kernel/cgroup/cgroup.c  |  8 
>  3 files changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
> index 9203bfb..e470268 100644
> --- a/kernel/cgroup/cgroup-internal.h
> +++ b/kernel/cgroup/cgroup-internal.h
> @@ -163,7 +163,7 @@ int cgroup_path_ns_locked(struct cgroup *cgrp, char *buf, 
> size_t buflen,
>  
>  void cgroup_free_root(struct cgroup_root *root);
>  void init_cgroup_root(struct cgroup_root *root, struct cgroup_sb_opts *opts);
> -int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask);
> +int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask, int ref_flags);
>  int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask);
>  struct dentry *cgroup_do_mount(struct file_system_type *fs_type, int flags,
>  struct cgroup_root *root, unsigned long magic,
> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
> index 12e19f0..6ca9b12 100644
> --- a/kernel/cgroup/cgroup-v1.c
> +++ b/kernel/cgroup/cgroup-v1.c
> @@ -1072,6 +1072,7 @@ struct dentry *cgroup1_mount(struct file_system_type 
> *fs_type, int flags,
>   struct cgroup_subsys *ss;
>   struct dentry *dentry;
>   int i, ret;
> + bool new_root = false;
>  
>   cgroup_lock_and_drain_offline(_dfl_root.cgrp);
>  
> @@ -1146,7 +1147,7 @@ struct dentry *cgroup1_mount(struct file_system_type 
> *fs_type, int flags,
>* path is super cold.  Let's just sleep a bit and retry.
>*/
>   pinned_sb = kernfs_pin_sb(root->kf_root, NULL);
> - if (IS_ERR_OR_NULL(pinned_sb) ||
> + if (IS_ERR(pinned_sb) ||
>   !percpu_ref_tryget_live(>cgrp.self.refcnt)) {
>   mutex_unlock(_mutex);
>   if (!IS_ERR_OR_NULL(pinned_sb))
> @@ -1181,10 +1182,11 @@ struct dentry *cgroup1_mount(struct file_system_type 
> *fs_type, int flags,
>   ret = -ENOMEM;
>   goto out_unlock;
>   }
> + new_root = true;
>  
>   init_cgroup_root(root, );
>  
> - ret = cgroup_setup_root(root, opts.subsys_mask);
> + ret = cgroup_setup_root(root, opts.subsys_mask, PERCPU_REF_INIT_DEAD);
>   if (ret)
>   cgroup_free_root(root);
>  
> @@ -1201,6 +1203,18 @@ struct dentry *cgroup1_mount(struct file_system_type 
> *fs_type, int flags,
>CGROUP_SUPER_MAGIC, ns);
>  
>   /*
> +  * There's a race window after we release cgroup_mutex and before
> +  * allocating a superblock. Make sure a concurrent process won't
> +  * be able to re-use the root during this window by delaying the
> +  * initialization of root refcnt.
> +  */
> + if (new_root) {
> + mutex_lock(_mutex);
> + percpu_ref_reinit(>cgrp.self.refcnt);
> + mutex_unlock(_mutex);
> + }
> +
> + /*
>* If @pinned_sb, we're reusing an existing root and holding an
>* extra ref on its sb.  Mount is complete.  Put the extra ref.
>*/
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 4885132..0f98010 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -1640,7 +1640,7 @@ void init_cgroup_root(struct cgroup_root *root, struct 
> cgroup_sb_opts *opts)
>   set_bit(CGRP_CPUSET_CLONE_CHILDREN, >cgrp.flags);
>  }
>  

[PATCH] usb: dwc3: add disable u2mac linestate check quirk

[William Wu]

This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.

When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).

On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.

Signed-off-by: William Wu 
---
 Documentation/devicetree/bindings/usb/dwc3.txt |  2 ++
 drivers/usb/dwc3/core.c| 14 ++
 drivers/usb/dwc3/core.h|  4 
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index f658f39..6a89f0c 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -45,6 +45,8 @@ Optional properties:
a free-running PHY clock.
  - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
from P0 to P1/P2/P3 without delay.
+ - snps,tx-ipgap-linecheck-dis-quirk: when set, disable u2mac linestate check
+   during HS transmit.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 455d89a..22e0c35 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -796,15 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
 
+   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+
/*
 * Enable hardware control of sending remote wakeup in HS when
 * the device is in the L1 state.
 */
-   if (dwc->revision >= DWC3_REVISION_290A) {
-   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+   if (dwc->revision >= DWC3_REVISION_290A)
reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
-   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
-   }
+
+   if (dwc->tx_ipgap_linecheck_dis_quirk)
+   reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+
+   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
 
return 0;
 
@@ -1023,6 +1027,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,dis-u2-freeclk-exists-quirk");
dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
+dwc->tx_ipgap_linecheck_dis_quirk = device_property_read_bool(dev,
+   "snps,tx-ipgap-linecheck-dis-quirk");
 
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 981c77f..3c2537b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -204,6 +204,7 @@
 #define DWC3_GCTL_DSBLCLKGTNG  BIT(0)
 
 /* Global User Control 1 Register */
+#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
 #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW  BIT(24)
 
 /* Global USB2 PHY Configuration Register */
@@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
  * provide a free-running PHY clock.
  * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
  * change quirk.
+ * @tx_ipgap_linecheck_dis_quirk: set if we disable u2mac linestate
+ * check during HS transmit.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 0   - -6dB de-emphasis
@@ -1004,6 +1007,7 @@ struct dwc3 {
unsigneddis_rxdet_inp3_quirk:1;
unsigneddis_u2_freeclk_exists_quirk:1;
unsigneddis_del_phy_power_chg_quirk:1;
+   unsignedtx_ipgap_linecheck_dis_quirk:1;
 
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
-- 
2.0.0

[PATCH] usb: dwc3: add disable u2mac linestate check quirk

[William Wu]

This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.

When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).

On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.

Signed-off-by: William Wu 
---
 Documentation/devicetree/bindings/usb/dwc3.txt |  2 ++
 drivers/usb/dwc3/core.c| 14 ++
 drivers/usb/dwc3/core.h|  4 
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index f658f39..6a89f0c 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -45,6 +45,8 @@ Optional properties:
a free-running PHY clock.
  - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
from P0 to P1/P2/P3 without delay.
+ - snps,tx-ipgap-linecheck-dis-quirk: when set, disable u2mac linestate check
+   during HS transmit.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 455d89a..22e0c35 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -796,15 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
 
+   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+
/*
 * Enable hardware control of sending remote wakeup in HS when
 * the device is in the L1 state.
 */
-   if (dwc->revision >= DWC3_REVISION_290A) {
-   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+   if (dwc->revision >= DWC3_REVISION_290A)
reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
-   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
-   }
+
+   if (dwc->tx_ipgap_linecheck_dis_quirk)
+   reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+
+   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
 
return 0;
 
@@ -1023,6 +1027,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,dis-u2-freeclk-exists-quirk");
dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
+dwc->tx_ipgap_linecheck_dis_quirk = device_property_read_bool(dev,
+   "snps,tx-ipgap-linecheck-dis-quirk");
 
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 981c77f..3c2537b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -204,6 +204,7 @@
 #define DWC3_GCTL_DSBLCLKGTNG  BIT(0)
 
 /* Global User Control 1 Register */
+#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
 #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW  BIT(24)
 
 /* Global USB2 PHY Configuration Register */
@@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
  * provide a free-running PHY clock.
  * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
  * change quirk.
+ * @tx_ipgap_linecheck_dis_quirk: set if we disable u2mac linestate
+ * check during HS transmit.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 0   - -6dB de-emphasis
@@ -1004,6 +1007,7 @@ struct dwc3 {
unsigneddis_rxdet_inp3_quirk:1;
unsigneddis_u2_freeclk_exists_quirk:1;
unsigneddis_del_phy_power_chg_quirk:1;
+   unsignedtx_ipgap_linecheck_dis_quirk:1;
 
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
-- 
2.0.0

[PATCH] Input: xpad - do not suggest writing to Dominic

[Dmitry Torokhov]

Do not recommend people write to Dominic, rather everyone should be using
linux-input mailing list.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/devices/xpad.rst | 6 --
 1 file changed, 6 deletions(-)

diff --git a/Documentation/input/devices/xpad.rst 
b/Documentation/input/devices/xpad.rst
index c7c4e154bd34..5a709ab77c8d 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -88,12 +88,6 @@ the default settings.
 HOWEVER if you have an unknown dance pad not listed below, it will not
 work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
 
-PLEASE, if you have an unknown controller, email Dom  
with
-a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
-whether it is a dance pad or normal controller) so that we can add your pad
-to the list of supported devices, ensuring that it will work out of the
-box in the future.
-
 
 USB adapters
 
-- 
2.12.2.762.g0e3151a226-goog


-- 
Dmitry

[PATCH] Input: xpad - do not suggest writing to Dominic

[Dmitry Torokhov]

Do not recommend people write to Dominic, rather everyone should be using
linux-input mailing list.

Signed-off-by: Dmitry Torokhov 
---
 Documentation/input/devices/xpad.rst | 6 --
 1 file changed, 6 deletions(-)

diff --git a/Documentation/input/devices/xpad.rst 
b/Documentation/input/devices/xpad.rst
index c7c4e154bd34..5a709ab77c8d 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -88,12 +88,6 @@ the default settings.
 HOWEVER if you have an unknown dance pad not listed below, it will not
 work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
 
-PLEASE, if you have an unknown controller, email Dom  
with
-a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
-whether it is a dance pad or normal controller) so that we can add your pad
-to the list of supported devices, ensuring that it will work out of the
-box in the future.
-
 
 USB adapters
 
-- 
2.12.2.762.g0e3151a226-goog


-- 
Dmitry

Re: [PATCH 5/7] mm/follow_page_mask: Add support for hugepage directory entry

[Aneesh Kumar K.V]

kbuild test robot  writes:

> Hi Aneesh,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.11-rc7 next-20170413]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Aneesh-Kumar-K-V/HugeTLB-migration-support-for-PPC64/20170418-011540
> config: x86_64-randconfig-a0-04180109 (attached as .config)
> compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
>
> All errors (new ones prefixed by >>):
>
>In file included from mm//swap.c:35:
>>> include/linux/hugetlb.h:121: error: expected declaration specifiers or 
>>> '...' before 'hugepd_t'
>
> vim +121 include/linux/hugetlb.h
>
>115unsigned long addr, unsigned long sz);
>116pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long 
> addr);
>117int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, 
> pte_t *ptep);
>118struct page *follow_huge_addr(struct mm_struct *mm, unsigned 
> long address,
>119  int write);
>120struct page *follow_huge_pd(struct vm_area_struct *vma,
>  > 121unsigned long address, hugepd_t hpd,
>122int flags, int pdshift);
>123struct page *follow_huge_pmd(struct mm_struct *mm, unsigned 
> long address,
>124pmd_t *pmd, int flags);
>

Thanks for the report. How about

>From 64033ea38962f69271169129277bbb0482299c31 Mon Sep 17 00:00:00 2001
From: "Aneesh Kumar K.V" 
Date: Tue, 18 Apr 2017 08:39:09 +0530
Subject: [PATCH] mm/hugetlb: Move default definition of hugepd_t earlier in
 the header

This enable to use the hugepd_t type early. No functional change in this patch.

Signed-off-by: Aneesh Kumar K.V 
---
 include/linux/hugetlb.h | 47 ---
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index edab98f0a7b8..f66c1d4e0d1f 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -14,6 +14,30 @@ struct ctl_table;
 struct user_struct;
 struct mmu_gather;
 
+#ifndef is_hugepd
+/*
+ * Some architectures requires a hugepage directory format that is
+ * required to support multiple hugepage sizes. For example
+ * a4fe3ce76 "powerpc/mm: Allow more flexible layouts for hugepage pagetables"
+ * introduced the same on powerpc. This allows for a more flexible hugepage
+ * pagetable layout.
+ */
+typedef struct { unsigned long pd; } hugepd_t;
+#define is_hugepd(hugepd) (0)
+#define __hugepd(x) ((hugepd_t) { (x) })
+static inline int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
+ unsigned pdshift, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+   return 0;
+}
+#else
+extern int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
+  unsigned pdshift, unsigned long end,
+  int write, struct page **pages, int *nr);
+#endif
+
+
 #ifdef CONFIG_HUGETLB_PAGE
 
 #include 
@@ -222,29 +246,6 @@ static inline int pud_write(pud_t pud)
 }
 #endif
 
-#ifndef is_hugepd
-/*
- * Some architectures requires a hugepage directory format that is
- * required to support multiple hugepage sizes. For example
- * a4fe3ce76 "powerpc/mm: Allow more flexible layouts for hugepage pagetables"
- * introduced the same on powerpc. This allows for a more flexible hugepage
- * pagetable layout.
- */
-typedef struct { unsigned long pd; } hugepd_t;
-#define is_hugepd(hugepd) (0)
-#define __hugepd(x) ((hugepd_t) { (x) })
-static inline int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
- unsigned pdshift, unsigned long end,
- int write, struct page **pages, int *nr)
-{
-   return 0;
-}
-#else
-extern int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
-  unsigned pdshift, unsigned long end,
-  int write, struct page **pages, int *nr);
-#endif
-
 #define HUGETLB_ANON_FILE "anon_hugepage"
 
 enum {
-- 
2.7.4

 

Re: [PATCH 5/7] mm/follow_page_mask: Add support for hugepage directory entry

[Aneesh Kumar K.V]

kbuild test robot  writes:

> Hi Aneesh,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.11-rc7 next-20170413]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Aneesh-Kumar-K-V/HugeTLB-migration-support-for-PPC64/20170418-011540
> config: x86_64-randconfig-a0-04180109 (attached as .config)
> compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
>
> All errors (new ones prefixed by >>):
>
>In file included from mm//swap.c:35:
>>> include/linux/hugetlb.h:121: error: expected declaration specifiers or 
>>> '...' before 'hugepd_t'
>
> vim +121 include/linux/hugetlb.h
>
>115unsigned long addr, unsigned long sz);
>116pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long 
> addr);
>117int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, 
> pte_t *ptep);
>118struct page *follow_huge_addr(struct mm_struct *mm, unsigned 
> long address,
>119  int write);
>120struct page *follow_huge_pd(struct vm_area_struct *vma,
>  > 121unsigned long address, hugepd_t hpd,
>122int flags, int pdshift);
>123struct page *follow_huge_pmd(struct mm_struct *mm, unsigned 
> long address,
>124pmd_t *pmd, int flags);
>

Thanks for the report. How about

>From 64033ea38962f69271169129277bbb0482299c31 Mon Sep 17 00:00:00 2001
From: "Aneesh Kumar K.V" 
Date: Tue, 18 Apr 2017 08:39:09 +0530
Subject: [PATCH] mm/hugetlb: Move default definition of hugepd_t earlier in
 the header

This enable to use the hugepd_t type early. No functional change in this patch.

Signed-off-by: Aneesh Kumar K.V 
---
 include/linux/hugetlb.h | 47 ---
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index edab98f0a7b8..f66c1d4e0d1f 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -14,6 +14,30 @@ struct ctl_table;
 struct user_struct;
 struct mmu_gather;
 
+#ifndef is_hugepd
+/*
+ * Some architectures requires a hugepage directory format that is
+ * required to support multiple hugepage sizes. For example
+ * a4fe3ce76 "powerpc/mm: Allow more flexible layouts for hugepage pagetables"
+ * introduced the same on powerpc. This allows for a more flexible hugepage
+ * pagetable layout.
+ */
+typedef struct { unsigned long pd; } hugepd_t;
+#define is_hugepd(hugepd) (0)
+#define __hugepd(x) ((hugepd_t) { (x) })
+static inline int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
+ unsigned pdshift, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+   return 0;
+}
+#else
+extern int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
+  unsigned pdshift, unsigned long end,
+  int write, struct page **pages, int *nr);
+#endif
+
+
 #ifdef CONFIG_HUGETLB_PAGE
 
 #include 
@@ -222,29 +246,6 @@ static inline int pud_write(pud_t pud)
 }
 #endif
 
-#ifndef is_hugepd
-/*
- * Some architectures requires a hugepage directory format that is
- * required to support multiple hugepage sizes. For example
- * a4fe3ce76 "powerpc/mm: Allow more flexible layouts for hugepage pagetables"
- * introduced the same on powerpc. This allows for a more flexible hugepage
- * pagetable layout.
- */
-typedef struct { unsigned long pd; } hugepd_t;
-#define is_hugepd(hugepd) (0)
-#define __hugepd(x) ((hugepd_t) { (x) })
-static inline int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
- unsigned pdshift, unsigned long end,
- int write, struct page **pages, int *nr)
-{
-   return 0;
-}
-#else
-extern int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
-  unsigned pdshift, unsigned long end,
-  int write, struct page **pages, int *nr);
-#endif
-
 #define HUGETLB_ANON_FILE "anon_hugepage"
 
 enum {
-- 
2.7.4

 

Re: [PATCH] usb: Make sure usb/phy/of gets built-in

[Frank Rowand]

On 04/13/17 05:33, Alexey Brodkin wrote:
> DWC3 driver uses of_usb_get_phy_mode() which is
> implemented in drivers/usb/phy/of.c and in bare minimal
> configuration it might not be pulled in kernel binary.
> 
> In case of ARC or ARM this could be easily reproduced with
> "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m.
> 
> On building all ends-up with:
> -->8--
>   Kernel: arch/arm/boot/Image is ready
>   Kernel: arch/arm/boot/zImage is ready
>   Building modules, stage 2.
>   MODPOST 5 modules
> ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> -->8--
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Greg Kroah-Hartman 
> Cc: Masahiro Yamada 
> Cc: Geert Uytterhoeven 
> Cc: Nicolas Pitre 
> Cc: Thomas Gleixner 
> Cc: Felipe Balbi 
> Cc: Felix Fietkau 
> Cc: Jeremy Kerr 
> Cc: linux-snps-...@lists.infradead.org
> Cc: sta...@vger.kernel.org
> ---
>  drivers/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 2eced9afba53..8f8bdc9e3d29 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -104,6 +104,7 @@ obj-$(CONFIG_USB_PHY) += usb/
>  obj-$(CONFIG_USB)+= usb/
>  obj-$(CONFIG_PCI)+= usb/
>  obj-$(CONFIG_USB_GADGET) += usb/

> +obj-$(CONFIG_OF) += usb/

Would CONFIG_USB_SUPPORT make more sense? (And does it work?)


>  obj-$(CONFIG_SERIO)  += input/serio/
>  obj-$(CONFIG_GAMEPORT)   += input/gameport/
>  obj-$(CONFIG_INPUT)  += input/
> 

Re: [PATCH] usb: Make sure usb/phy/of gets built-in

[Frank Rowand]

On 04/13/17 05:33, Alexey Brodkin wrote:
> DWC3 driver uses of_usb_get_phy_mode() which is
> implemented in drivers/usb/phy/of.c and in bare minimal
> configuration it might not be pulled in kernel binary.
> 
> In case of ARC or ARM this could be easily reproduced with
> "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m.
> 
> On building all ends-up with:
> -->8--
>   Kernel: arch/arm/boot/Image is ready
>   Kernel: arch/arm/boot/zImage is ready
>   Building modules, stage 2.
>   MODPOST 5 modules
> ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> -->8--
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Greg Kroah-Hartman 
> Cc: Masahiro Yamada 
> Cc: Geert Uytterhoeven 
> Cc: Nicolas Pitre 
> Cc: Thomas Gleixner 
> Cc: Felipe Balbi 
> Cc: Felix Fietkau 
> Cc: Jeremy Kerr 
> Cc: linux-snps-...@lists.infradead.org
> Cc: sta...@vger.kernel.org
> ---
>  drivers/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 2eced9afba53..8f8bdc9e3d29 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -104,6 +104,7 @@ obj-$(CONFIG_USB_PHY) += usb/
>  obj-$(CONFIG_USB)+= usb/
>  obj-$(CONFIG_PCI)+= usb/
>  obj-$(CONFIG_USB_GADGET) += usb/

> +obj-$(CONFIG_OF) += usb/

Would CONFIG_USB_SUPPORT make more sense? (And does it work?)


>  obj-$(CONFIG_SERIO)  += input/serio/
>  obj-$(CONFIG_GAMEPORT)   += input/gameport/
>  obj-$(CONFIG_INPUT)  += input/
> 

Re: [PATCH 2/4] input: xpad.rst: Don't use literal blocks inside footnotes

[Dmitry Torokhov]

On Mon, Apr 17, 2017 at 09:46:14AM -0300, Mauro Carvalho Chehab wrote:
> Unfortunately, Sphinx (or LaTeX) can't handle literal blocks
> inside footnotes. So, just use normal text for the two
> literal code-blocks that documents the output of
> /sys/kernel/debug/usb/devices for xpad devices.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Applied, thank you.

> ---
>  Documentation/input/devices/xpad.rst | 51 
> ++--
>  1 file changed, 25 insertions(+), 26 deletions(-)
> 
> diff --git a/Documentation/input/devices/xpad.rst 
> b/Documentation/input/devices/xpad.rst
> index e19669fe5a80..c7c4e154bd34 100644
> --- a/Documentation/input/devices/xpad.rst
> +++ b/Documentation/input/devices/xpad.rst
> @@ -138,15 +138,37 @@ Driver Installation
>  
>  Once you have the adapter cable, if needed, and the controller connected
>  the xpad module should be auto loaded. To confirm you can cat
> -/sys/kernel/debug/usb/devices. There should be an entry like the one at the 
> end [4]_.
> +/sys/kernel/debug/usb/devices. There should be an entry like those:
>  
> +.. code-block:: none
> +   :caption: dump from InterAct PowerPad Pro (Germany)
> +
> +T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
> +D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
> +P:  Vendor=05fd ProdID=107a Rev= 1.00
> +C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> +I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
> +E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
> +E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
> +
> +.. code-block:: none
> +   :caption: dump from Redoctane Xbox Dance Pad (US)
> +
> +T:  Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12  MxCh= 0
> +D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> +P:  Vendor=0c12 ProdID=8809 Rev= 0.01
> +S:  Product=XBOX DDR
> +C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> +I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
> +E:  Ad=82(I) Atr=03(Int.) MxPS=  32 Ivl=4ms
> +E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=4ms
>  
>  
>  Supported Controllers
>  =
>  
>  For a full list of supported controllers and associated vendor and product
> -IDs see the xpad_device[] array[6].
> +IDs see the xpad_device[] array\ [4]_.
>  
>  As of the historic version 0.0.6 (2006-10-10) the following devices
>  were supported::
> @@ -202,30 +224,7 @@ References
>  .. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
>  .. [2] http://xpad.xbox-scene.com/
>  .. [3] http://www.markosweb.com/www/xboxhackz.com/
> -.. [4] /sys/kernel/debug/usb/devices - dump from InterAct PowerPad Pro 
> (Germany):
> -
> - ::
> -
> -T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
> -D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
> -P:  Vendor=05fd ProdID=107a Rev= 1.00
> -C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> -I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
> -E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
> -E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
> -.. [5] /sys/kernel/debug/usb/devices - dump from Redoctane Xbox Dance Pad 
> (US):
> -
> - ::
> -
> -T:  Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12  MxCh= 0
> -D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> -P:  Vendor=0c12 ProdID=8809 Rev= 0.01
> -S:  Product=XBOX DDR
> -C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> -I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
> -E:  Ad=82(I) Atr=03(Int.) MxPS=  32 Ivl=4ms
> -E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=4ms
> -.. [6] http://lxr.free-electrons.com/ident?i=xpad_device
> +.. [4] http://lxr.free-electrons.com/ident?i=xpad_device
>  
>  
>  Historic Edits
> -- 
> 2.9.3
> 

-- 
Dmitry

Re: [PATCH 2/4] input: xpad.rst: Don't use literal blocks inside footnotes

[Dmitry Torokhov]

On Mon, Apr 17, 2017 at 09:46:14AM -0300, Mauro Carvalho Chehab wrote:
> Unfortunately, Sphinx (or LaTeX) can't handle literal blocks
> inside footnotes. So, just use normal text for the two
> literal code-blocks that documents the output of
> /sys/kernel/debug/usb/devices for xpad devices.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Applied, thank you.

> ---
>  Documentation/input/devices/xpad.rst | 51 
> ++--
>  1 file changed, 25 insertions(+), 26 deletions(-)
> 
> diff --git a/Documentation/input/devices/xpad.rst 
> b/Documentation/input/devices/xpad.rst
> index e19669fe5a80..c7c4e154bd34 100644
> --- a/Documentation/input/devices/xpad.rst
> +++ b/Documentation/input/devices/xpad.rst
> @@ -138,15 +138,37 @@ Driver Installation
>  
>  Once you have the adapter cable, if needed, and the controller connected
>  the xpad module should be auto loaded. To confirm you can cat
> -/sys/kernel/debug/usb/devices. There should be an entry like the one at the 
> end [4]_.
> +/sys/kernel/debug/usb/devices. There should be an entry like those:
>  
> +.. code-block:: none
> +   :caption: dump from InterAct PowerPad Pro (Germany)
> +
> +T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
> +D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
> +P:  Vendor=05fd ProdID=107a Rev= 1.00
> +C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> +I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
> +E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
> +E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
> +
> +.. code-block:: none
> +   :caption: dump from Redoctane Xbox Dance Pad (US)
> +
> +T:  Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12  MxCh= 0
> +D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> +P:  Vendor=0c12 ProdID=8809 Rev= 0.01
> +S:  Product=XBOX DDR
> +C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> +I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
> +E:  Ad=82(I) Atr=03(Int.) MxPS=  32 Ivl=4ms
> +E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=4ms
>  
>  
>  Supported Controllers
>  =
>  
>  For a full list of supported controllers and associated vendor and product
> -IDs see the xpad_device[] array[6].
> +IDs see the xpad_device[] array\ [4]_.
>  
>  As of the historic version 0.0.6 (2006-10-10) the following devices
>  were supported::
> @@ -202,30 +224,7 @@ References
>  .. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
>  .. [2] http://xpad.xbox-scene.com/
>  .. [3] http://www.markosweb.com/www/xboxhackz.com/
> -.. [4] /sys/kernel/debug/usb/devices - dump from InterAct PowerPad Pro 
> (Germany):
> -
> - ::
> -
> -T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
> -D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
> -P:  Vendor=05fd ProdID=107a Rev= 1.00
> -C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> -I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
> -E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
> -E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
> -.. [5] /sys/kernel/debug/usb/devices - dump from Redoctane Xbox Dance Pad 
> (US):
> -
> - ::
> -
> -T:  Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12  MxCh= 0
> -D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> -P:  Vendor=0c12 ProdID=8809 Rev= 0.01
> -S:  Product=XBOX DDR
> -C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> -I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
> -E:  Ad=82(I) Atr=03(Int.) MxPS=  32 Ivl=4ms
> -E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=4ms
> -.. [6] http://lxr.free-electrons.com/ident?i=xpad_device
> +.. [4] http://lxr.free-electrons.com/ident?i=xpad_device
>  
>  
>  Historic Edits
> -- 
> 2.9.3
> 

-- 
Dmitry

Re: [PATCH 1/4] input: xpad.rst: usb/devices is now at /sys/kernel/debug/

[Dmitry Torokhov]

On Mon, Apr 17, 2017 at 09:46:13AM -0300, Mauro Carvalho Chehab wrote:
> The /proc/bus/usb/devices got moved to sysfs. It is now
> sitting   at:
> /sys/kernel/debug/usb/devices
> 
> Signed-off-by: Mauro Carvalho Chehab 

Applied, thank you.

> ---
>  Documentation/input/devices/xpad.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/input/devices/xpad.rst 
> b/Documentation/input/devices/xpad.rst
> index 80028433b460..e19669fe5a80 100644
> --- a/Documentation/input/devices/xpad.rst
> +++ b/Documentation/input/devices/xpad.rst
> @@ -138,7 +138,7 @@ Driver Installation
>  
>  Once you have the adapter cable, if needed, and the controller connected
>  the xpad module should be auto loaded. To confirm you can cat
> -/proc/bus/usb/devices. There should be an entry like the one at the end [4]_.
> +/sys/kernel/debug/usb/devices. There should be an entry like the one at the 
> end [4]_.
>  
>  
>  
> @@ -202,7 +202,7 @@ References
>  .. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
>  .. [2] http://xpad.xbox-scene.com/
>  .. [3] http://www.markosweb.com/www/xboxhackz.com/
> -.. [4] /proc/bus/usb/devices - dump from InterAct PowerPad Pro (Germany):
> +.. [4] /sys/kernel/debug/usb/devices - dump from InterAct PowerPad Pro 
> (Germany):
>  
>   ::
>  
> @@ -213,7 +213,7 @@ References
>  I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
>  E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
>  E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
> -.. [5] /proc/bus/usb/devices - dump from Redoctane Xbox Dance Pad (US):
> +.. [5] /sys/kernel/debug/usb/devices - dump from Redoctane Xbox Dance Pad 
> (US):
>  
>   ::
>  
> -- 
> 2.9.3
> 

-- 
Dmitry

Re: [PATCH 1/4] input: xpad.rst: usb/devices is now at /sys/kernel/debug/

[Dmitry Torokhov]

On Mon, Apr 17, 2017 at 09:46:13AM -0300, Mauro Carvalho Chehab wrote:
> The /proc/bus/usb/devices got moved to sysfs. It is now
> sitting   at:
> /sys/kernel/debug/usb/devices
> 
> Signed-off-by: Mauro Carvalho Chehab 

Applied, thank you.

> ---
>  Documentation/input/devices/xpad.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/input/devices/xpad.rst 
> b/Documentation/input/devices/xpad.rst
> index 80028433b460..e19669fe5a80 100644
> --- a/Documentation/input/devices/xpad.rst
> +++ b/Documentation/input/devices/xpad.rst
> @@ -138,7 +138,7 @@ Driver Installation
>  
>  Once you have the adapter cable, if needed, and the controller connected
>  the xpad module should be auto loaded. To confirm you can cat
> -/proc/bus/usb/devices. There should be an entry like the one at the end [4]_.
> +/sys/kernel/debug/usb/devices. There should be an entry like the one at the 
> end [4]_.
>  
>  
>  
> @@ -202,7 +202,7 @@ References
>  .. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
>  .. [2] http://xpad.xbox-scene.com/
>  .. [3] http://www.markosweb.com/www/xboxhackz.com/
> -.. [4] /proc/bus/usb/devices - dump from InterAct PowerPad Pro (Germany):
> +.. [4] /sys/kernel/debug/usb/devices - dump from InterAct PowerPad Pro 
> (Germany):
>  
>   ::
>  
> @@ -213,7 +213,7 @@ References
>  I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
>  E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
>  E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
> -.. [5] /proc/bus/usb/devices - dump from Redoctane Xbox Dance Pad (US):
> +.. [5] /sys/kernel/debug/usb/devices - dump from Redoctane Xbox Dance Pad 
> (US):
>  
>   ::
>  
> -- 
> 2.9.3
> 

-- 
Dmitry

Re: [PATCH 3/4] input: xpad.rst: proc/bus/usb was renamed to dev/bus/usb

[Dmitry Torokhov]

Hi Mauro,

On Mon, Apr 17, 2017 at 09:46:15AM -0300, Mauro Carvalho Chehab wrote:
> xpad.rst requests a dump of the USB description, as found
> on the USB character device. When we got rid of usbfs,
> its location change. Update it.

I have not heard from Dom ever so I think the best option is to remove
this entire paragraph.

> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/input/devices/xpad.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/input/devices/xpad.rst 
> b/Documentation/input/devices/xpad.rst
> index c7c4e154bd34..3c74c185be7d 100644
> --- a/Documentation/input/devices/xpad.rst
> +++ b/Documentation/input/devices/xpad.rst
> @@ -89,7 +89,7 @@ HOWEVER if you have an unknown dance pad not listed below, 
> it will not
>  work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
>  
>  PLEASE, if you have an unknown controller, email Dom  
> with
> -a dump from /proc/bus/usb and a description of the pad (manufacturer, 
> country,
> +a dump from /dev/bus/usb and a description of the pad (manufacturer, country,
>  whether it is a dance pad or normal controller) so that we can add your pad
>  to the list of supported devices, ensuring that it will work out of the
>  box in the future.
> -- 
> 2.9.3
> 

-- 
Dmitry

Re: [PATCH 3/4] input: xpad.rst: proc/bus/usb was renamed to dev/bus/usb

[Dmitry Torokhov]

Hi Mauro,

On Mon, Apr 17, 2017 at 09:46:15AM -0300, Mauro Carvalho Chehab wrote:
> xpad.rst requests a dump of the USB description, as found
> on the USB character device. When we got rid of usbfs,
> its location change. Update it.

I have not heard from Dom ever so I think the best option is to remove
this entire paragraph.

> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/input/devices/xpad.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/input/devices/xpad.rst 
> b/Documentation/input/devices/xpad.rst
> index c7c4e154bd34..3c74c185be7d 100644
> --- a/Documentation/input/devices/xpad.rst
> +++ b/Documentation/input/devices/xpad.rst
> @@ -89,7 +89,7 @@ HOWEVER if you have an unknown dance pad not listed below, 
> it will not
>  work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
>  
>  PLEASE, if you have an unknown controller, email Dom  
> with
> -a dump from /proc/bus/usb and a description of the pad (manufacturer, 
> country,
> +a dump from /dev/bus/usb and a description of the pad (manufacturer, country,
>  whether it is a dance pad or normal controller) so that we can add your pad
>  to the list of supported devices, ensuring that it will work out of the
>  box in the future.
> -- 
> 2.9.3
> 

-- 
Dmitry

Re: [PATCH RFC] ptr_ring: add ptr_ring_unconsume

[Jason Wang]

On 2017年04月17日 07:19, Michael S. Tsirkin wrote:

Applications that consume a batch of entries in one go
can benefit from ability to return some of them back
into the ring.

Add an API for that - assuming there's space. If there's no space
naturally we can't do this and have to drop entries, but this implies
ring is full so we'd likely drop some anyway.

Signed-off-by: Michael S. Tsirkin 
---

Jason, in my mind the biggest issue with your batching patchset is the
backet drops on disconnect.  This API will help avoid that in the common
case.


Ok, I will rebase the series on top of this. (Though I don't think we 
care the packet loss).




I would still prefer that we understand what's going on,


I try to reply in another thread, does it make sense?


  and I would
like to know what's the smallest batch size that's still helpful,


Yes, I've replied in another thread, the result is:


no batching   1.88Mpps
RX_BATCH=11.93Mpps
RX_BATCH=42.11Mpps
RX_BATCH=16   2.14Mpps
RX_BATCH=64   2.25Mpps
RX_BATCH=256  2.18Mpps


  but
I'm not going to block the patch on these grounds assuming packet drops
are fixed.


Thanks a lot.



Lightly tested - this is on top of consumer batching patches.

Thanks!

  include/linux/ptr_ring.h | 57 
  1 file changed, 57 insertions(+)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 783e7f5..5fbeab4 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -457,6 +457,63 @@ static inline int ptr_ring_init(struct ptr_ring *r, int 
size, gfp_t gfp)
return 0;
  }
  
+/*

+ * Return entries into ring. Destroy entries that don't fit.
+ *
+ * Note: this is expected to be a rare slow path operation.
+ *
+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
+static inline void ptr_ring_unconsume(struct ptr_ring *r, void **batch, int n,
+ void (*destroy)(void *))
+{
+   unsigned long flags;
+   int head;
+
+   spin_lock_irqsave(&(r)->consumer_lock, flags);
+   spin_lock(&(r)->producer_lock);
+
+   if (!r->size)
+   goto done;
+
+   /*
+* Clean out buffered entries (for simplicity). This way following code
+* can test entries for NULL and if not assume they are valid.
+*/
+   head = r->consumer_head - 1;
+   while (likely(head >= r->consumer_tail))
+   r->queue[head--] = NULL;
+   r->consumer_tail = r->consumer_head;
+
+   /*
+* Go over entries in batch, start moving head back and copy entries.
+* Stop when we run into previously unconsumed entries.
+*/
+   while (n--) {
+   head = r->consumer_head - 1;
+   if (head < 0)
+   head = r->size - 1;
+   if (r->queue[head]) {
+   /* This batch entry will have to be destroyed. */
+   ++n;
+   goto done;
+   }
+   r->queue[head] = batch[n];
+   r->consumer_tail = r->consumer_head = head;
+   }
+
+done:
+   /* Destroy all entries left in the batch. */
+   while (n--) {
+   destroy(batch[n]);
+   }
+   spin_unlock(&(r)->producer_lock);
+   spin_unlock_irqrestore(&(r)->consumer_lock, flags);
+}
+
  static inline void **__ptr_ring_swap_queue(struct ptr_ring *r, void **queue,
   int size, gfp_t gfp,
   void (*destroy)(void *))

Re: [PATCH RFC] ptr_ring: add ptr_ring_unconsume

[Jason Wang]

On 2017年04月17日 07:19, Michael S. Tsirkin wrote:

Applications that consume a batch of entries in one go
can benefit from ability to return some of them back
into the ring.

Add an API for that - assuming there's space. If there's no space
naturally we can't do this and have to drop entries, but this implies
ring is full so we'd likely drop some anyway.

Signed-off-by: Michael S. Tsirkin 
---

Jason, in my mind the biggest issue with your batching patchset is the
backet drops on disconnect.  This API will help avoid that in the common
case.


Ok, I will rebase the series on top of this. (Though I don't think we 
care the packet loss).




I would still prefer that we understand what's going on,


I try to reply in another thread, does it make sense?


  and I would
like to know what's the smallest batch size that's still helpful,


Yes, I've replied in another thread, the result is:


no batching   1.88Mpps
RX_BATCH=11.93Mpps
RX_BATCH=42.11Mpps
RX_BATCH=16   2.14Mpps
RX_BATCH=64   2.25Mpps
RX_BATCH=256  2.18Mpps


  but
I'm not going to block the patch on these grounds assuming packet drops
are fixed.


Thanks a lot.



Lightly tested - this is on top of consumer batching patches.

Thanks!

  include/linux/ptr_ring.h | 57 
  1 file changed, 57 insertions(+)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 783e7f5..5fbeab4 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -457,6 +457,63 @@ static inline int ptr_ring_init(struct ptr_ring *r, int 
size, gfp_t gfp)
return 0;
  }
  
+/*

+ * Return entries into ring. Destroy entries that don't fit.
+ *
+ * Note: this is expected to be a rare slow path operation.
+ *
+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
+static inline void ptr_ring_unconsume(struct ptr_ring *r, void **batch, int n,
+ void (*destroy)(void *))
+{
+   unsigned long flags;
+   int head;
+
+   spin_lock_irqsave(&(r)->consumer_lock, flags);
+   spin_lock(&(r)->producer_lock);
+
+   if (!r->size)
+   goto done;
+
+   /*
+* Clean out buffered entries (for simplicity). This way following code
+* can test entries for NULL and if not assume they are valid.
+*/
+   head = r->consumer_head - 1;
+   while (likely(head >= r->consumer_tail))
+   r->queue[head--] = NULL;
+   r->consumer_tail = r->consumer_head;
+
+   /*
+* Go over entries in batch, start moving head back and copy entries.
+* Stop when we run into previously unconsumed entries.
+*/
+   while (n--) {
+   head = r->consumer_head - 1;
+   if (head < 0)
+   head = r->size - 1;
+   if (r->queue[head]) {
+   /* This batch entry will have to be destroyed. */
+   ++n;
+   goto done;
+   }
+   r->queue[head] = batch[n];
+   r->consumer_tail = r->consumer_head = head;
+   }
+
+done:
+   /* Destroy all entries left in the batch. */
+   while (n--) {
+   destroy(batch[n]);
+   }
+   spin_unlock(&(r)->producer_lock);
+   spin_unlock_irqrestore(&(r)->consumer_lock, flags);
+}
+
  static inline void **__ptr_ring_swap_queue(struct ptr_ring *r, void **queue,
   int size, gfp_t gfp,
   void (*destroy)(void *))

linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/block/nbd.c: In function 'nbd_genl_connect':
drivers/block/nbd.c:1662:10: error: too few arguments to function 
'nla_parse_nested'
ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
  ^
In file included from include/net/rtnetlink.h:5:0,
 from include/net/sch_generic.h:12,
 from include/linux/filter.h:20,
 from include/net/sock.h:64,
 from drivers/block/nbd.c:32:
include/net/netlink.h:754:19: note: declared here
 static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
   ^
drivers/block/nbd.c: In function 'nbd_genl_reconfigure':
drivers/block/nbd.c:1818:10: error: too few arguments to function 
'nla_parse_nested'
ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
  ^
In file included from include/net/rtnetlink.h:5:0,
 from include/net/sch_generic.h:12,
 from include/linux/filter.h:20,
 from include/net/sock.h:64,
 from drivers/block/nbd.c:32:
include/net/netlink.h:754:19: note: declared here
 static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
   ^

Caused by commits

  e46c7287b1c2 ("nbd: add a basic netlink interface")
  b7aa3d39385d ("nbd: add a reconfigure netlink command")

interacting with commit

  fceb6435e852 ("netlink: pass extended ACK struct to parsing functions")

from the net-next tree.

I have applied the following merge fix patch:

From: Stephen Rothwell 
Date: Tue, 18 Apr 2017 12:59:05 +1000
Subject: [PATCH] nbd: fix up for nla_parse_nested() API change

Signed-off-by: Stephen Rothwell 
---
 drivers/block/nbd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index b78f23ce2395..5049d19f3940 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -1660,7 +1660,7 @@ static int nbd_genl_connect(struct sk_buff *skb, struct 
genl_info *info)
goto out;
}
ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
-  nbd_sock_policy);
+  nbd_sock_policy, NULL);
if (ret != 0) {
printk(KERN_ERR "nbd: error processing sock 
list\n");
ret = -EINVAL;
@@ -1816,7 +1816,7 @@ static int nbd_genl_reconfigure(struct sk_buff *skb, 
struct genl_info *info)
goto out;
}
ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
-  nbd_sock_policy);
+  nbd_sock_policy, NULL);
if (ret != 0) {
printk(KERN_ERR "nbd: error processing sock 
list\n");
ret = -EINVAL;
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/block/nbd.c: In function 'nbd_genl_connect':
drivers/block/nbd.c:1662:10: error: too few arguments to function 
'nla_parse_nested'
ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
  ^
In file included from include/net/rtnetlink.h:5:0,
 from include/net/sch_generic.h:12,
 from include/linux/filter.h:20,
 from include/net/sock.h:64,
 from drivers/block/nbd.c:32:
include/net/netlink.h:754:19: note: declared here
 static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
   ^
drivers/block/nbd.c: In function 'nbd_genl_reconfigure':
drivers/block/nbd.c:1818:10: error: too few arguments to function 
'nla_parse_nested'
ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
  ^
In file included from include/net/rtnetlink.h:5:0,
 from include/net/sch_generic.h:12,
 from include/linux/filter.h:20,
 from include/net/sock.h:64,
 from drivers/block/nbd.c:32:
include/net/netlink.h:754:19: note: declared here
 static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
   ^

Caused by commits

  e46c7287b1c2 ("nbd: add a basic netlink interface")
  b7aa3d39385d ("nbd: add a reconfigure netlink command")

interacting with commit

  fceb6435e852 ("netlink: pass extended ACK struct to parsing functions")

from the net-next tree.

I have applied the following merge fix patch:

From: Stephen Rothwell 
Date: Tue, 18 Apr 2017 12:59:05 +1000
Subject: [PATCH] nbd: fix up for nla_parse_nested() API change

Signed-off-by: Stephen Rothwell 
---
 drivers/block/nbd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index b78f23ce2395..5049d19f3940 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -1660,7 +1660,7 @@ static int nbd_genl_connect(struct sk_buff *skb, struct 
genl_info *info)
goto out;
}
ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
-  nbd_sock_policy);
+  nbd_sock_policy, NULL);
if (ret != 0) {
printk(KERN_ERR "nbd: error processing sock 
list\n");
ret = -EINVAL;
@@ -1816,7 +1816,7 @@ static int nbd_genl_reconfigure(struct sk_buff *skb, 
struct genl_info *info)
goto out;
}
ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
-  nbd_sock_policy);
+  nbd_sock_policy, NULL);
if (ret != 0) {
printk(KERN_ERR "nbd: error processing sock 
list\n");
ret = -EINVAL;
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

[Peter Xu]

On Mon, Apr 17, 2017 at 03:32:20PM -0600, Alex Williamson wrote:
> On Tue, 18 Apr 2017 01:02:12 +0530
> Kirti Wankhede  wrote:
> 
> > On 4/18/2017 12:49 AM, Alex Williamson wrote:
> > > On Tue, 18 Apr 2017 00:35:06 +0530
> > > Kirti Wankhede  wrote:
> > >   
> > >> On 4/17/2017 8:02 PM, Alex Williamson wrote:  
> > >>> On Mon, 17 Apr 2017 14:47:54 +0800
> > >>> Peter Xu  wrote:
> > >>> 
> >  On Sun, Apr 16, 2017 at 07:42:27PM -0600, Alex Williamson wrote:
> > 
> >  [...]
> > 
> > > -static void vfio_lock_acct(struct task_struct *task, long npage)
> > > +static int vfio_lock_acct(struct task_struct *task, long npage, bool 
> > > lock_cap)
> > >  {
> > > - struct vwork *vwork;
> > >   struct mm_struct *mm;
> > >   bool is_current;
> > > + int ret;
> > >  
> > >   if (!npage)
> > > - return;
> > > + return 0;
> > >  
> > >   is_current = (task->mm == current->mm);
> > >  
> > >   mm = is_current ? task->mm : get_task_mm(task);
> > >   if (!mm)
> > > - return; /* process exited */
> > > + return -ESRCH; /* process exited */
> > >  
> > > - if (down_write_trylock(>mmap_sem)) {
> > > - mm->locked_vm += npage;
> > > - up_write(>mmap_sem);
> > > - if (!is_current)
> > > - mmput(mm);
> > > - return;
> > > - }
> > > + ret = down_write_killable(>mmap_sem);
> > > + if (!ret) {
> > > + if (npage < 0 || lock_cap) {  
> > 
> >  Nit: maybe we can avoid passing in lock_cap in all the callers of
> >  vfio_lock_acct() and fetch it via has_capability() only if npage < 0?
> >  IMHO that'll keep the vfio_lock_acct() interface cleaner, and we won't
> >  need to pass in "false" any time when doing unpins.
> > >>>
> > >>> Unfortunately vfio_pin_pages_remote() needs to know about lock_cap
> > >>> since it tests whether the user is exceeding their locked memory
> > >>> limit.  The other callers could certainly get away with
> > >>> vfio_lock_acct() testing the capability itself but that would add a
> > >>> redundant call for the most common user.  I'm not a big fan of passing
> > >>> a lock_cap bool either, but it seemed the best fix for now.  The
> > >>> cleanest alternative I can up with is this (untested):
> > >>> 
> > >>
> > >> In my opinion, passing 'bool lock_cap' looks much clean and simple.
> > >>
> > >> Reviewed-by: Kirti Wankhede   
> > > 
> > > Well shoot, I was just starting to warm up to the bool*.  I like that
> > > we're not presuming the polarity for the callers we expect to be
> > > removing pages and I generally just dislike passing fixed bool
> > > parameters to change the function behavior.  I've cleaned it up a bit
> > > further and was starting to do some testing on this which I'd propose
> > > for v5.  Does it change your opinion?  
> > 
> > If passing fixed bool parameter is the concern then I would lean towards
> > Peter's suggestion. vfio_pin_pages_remote() will check lock capability
> > outside vfio_lock_acct() and again in vfio_lock_acct(). At other places,
> > it will be takes care within vfio_lock_acct()
> 
> Sorry, I don't see that as a viable option.  Testing for CAP_IPC_LOCK in
> both vfio_pin_pages_remote() and vfio_lock_acct() results in over a
> 10% performance hit on the mapping path with a custom micro-benchmark.
> In fact, it suggests we should probably pass that from even higher in
> the call stack.  Thanks,

Sorry I wasn't aware of such a performance degradation with such a
change. Then I would be perfectly fine with either current patch, or
the new one you proposed (with bool *). Thanks,

-- 
Peter Xu

Re: [PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

[Peter Xu]

On Mon, Apr 17, 2017 at 03:32:20PM -0600, Alex Williamson wrote:
> On Tue, 18 Apr 2017 01:02:12 +0530
> Kirti Wankhede  wrote:
> 
> > On 4/18/2017 12:49 AM, Alex Williamson wrote:
> > > On Tue, 18 Apr 2017 00:35:06 +0530
> > > Kirti Wankhede  wrote:
> > >   
> > >> On 4/17/2017 8:02 PM, Alex Williamson wrote:  
> > >>> On Mon, 17 Apr 2017 14:47:54 +0800
> > >>> Peter Xu  wrote:
> > >>> 
> >  On Sun, Apr 16, 2017 at 07:42:27PM -0600, Alex Williamson wrote:
> > 
> >  [...]
> > 
> > > -static void vfio_lock_acct(struct task_struct *task, long npage)
> > > +static int vfio_lock_acct(struct task_struct *task, long npage, bool 
> > > lock_cap)
> > >  {
> > > - struct vwork *vwork;
> > >   struct mm_struct *mm;
> > >   bool is_current;
> > > + int ret;
> > >  
> > >   if (!npage)
> > > - return;
> > > + return 0;
> > >  
> > >   is_current = (task->mm == current->mm);
> > >  
> > >   mm = is_current ? task->mm : get_task_mm(task);
> > >   if (!mm)
> > > - return; /* process exited */
> > > + return -ESRCH; /* process exited */
> > >  
> > > - if (down_write_trylock(>mmap_sem)) {
> > > - mm->locked_vm += npage;
> > > - up_write(>mmap_sem);
> > > - if (!is_current)
> > > - mmput(mm);
> > > - return;
> > > - }
> > > + ret = down_write_killable(>mmap_sem);
> > > + if (!ret) {
> > > + if (npage < 0 || lock_cap) {  
> > 
> >  Nit: maybe we can avoid passing in lock_cap in all the callers of
> >  vfio_lock_acct() and fetch it via has_capability() only if npage < 0?
> >  IMHO that'll keep the vfio_lock_acct() interface cleaner, and we won't
> >  need to pass in "false" any time when doing unpins.
> > >>>
> > >>> Unfortunately vfio_pin_pages_remote() needs to know about lock_cap
> > >>> since it tests whether the user is exceeding their locked memory
> > >>> limit.  The other callers could certainly get away with
> > >>> vfio_lock_acct() testing the capability itself but that would add a
> > >>> redundant call for the most common user.  I'm not a big fan of passing
> > >>> a lock_cap bool either, but it seemed the best fix for now.  The
> > >>> cleanest alternative I can up with is this (untested):
> > >>> 
> > >>
> > >> In my opinion, passing 'bool lock_cap' looks much clean and simple.
> > >>
> > >> Reviewed-by: Kirti Wankhede   
> > > 
> > > Well shoot, I was just starting to warm up to the bool*.  I like that
> > > we're not presuming the polarity for the callers we expect to be
> > > removing pages and I generally just dislike passing fixed bool
> > > parameters to change the function behavior.  I've cleaned it up a bit
> > > further and was starting to do some testing on this which I'd propose
> > > for v5.  Does it change your opinion?  
> > 
> > If passing fixed bool parameter is the concern then I would lean towards
> > Peter's suggestion. vfio_pin_pages_remote() will check lock capability
> > outside vfio_lock_acct() and again in vfio_lock_acct(). At other places,
> > it will be takes care within vfio_lock_acct()
> 
> Sorry, I don't see that as a viable option.  Testing for CAP_IPC_LOCK in
> both vfio_pin_pages_remote() and vfio_lock_acct() results in over a
> 10% performance hit on the mapping path with a custom micro-benchmark.
> In fact, it suggests we should probably pass that from even higher in
> the call stack.  Thanks,

Sorry I wasn't aware of such a performance degradation with such a
change. Then I would be perfectly fine with either current patch, or
the new one you proposed (with bool *). Thanks,

-- 
Peter Xu

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Michel Dänzer]

On 17/04/17 03:43 PM, Ilia Mirkin wrote:
> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin  wrote:
>>> However, I totally agree with Alex that someone with a BE machine
>>> should review the whole stack before we could be confident with anything.
>>
>> Here's what I'm confident about: xf86-video-nouveau worked just fine
>> on top of kernel 4.3 on an AGP GeForce FX 5200 (with AGPGART turned
>> off because ... well ... uninorth). fbcon/fbdev accel worked,
>> xf86-video-nouveau's 2d accel worked, and simple demos (ala glxgears)
>> worked after I fixed up mesa and nv30 driver items in version ... 11.1
>> it seems. As I recall it had gotten all broken in 10.0 or so by Adam
>> Jackson in the name of making llvmpipe work on BE, declaring all other
>> drivers broken, with various fixes by Michel Dänzer to get it back to
>> working over the years.
>>
>> Anyone "fixing" the stack has to maintain that level of functioning
>> through their various fixing.
>>
>> I will double-check that the above still works with the latest
>> kernel/xorg/xf86-video-nouveau/mesa and report back (hopefully by this
>> weekend). If there are any patches you'd like me to test, now's the
>> time to ask -- getting the box up and running is the hard part,
>> booting up an extra kernel -- easy.
> 
> OK, so I revived my PowerMac7,3 G5 setup (PPC64 BE, NV34 GPU). Booted
> it with an upstream 4.11-rc7 kernel, loaded up the nouveau kernel
> module (which is included in that kernel), updated X to 1.19.2 and
> mesa to 17.0.3. Everything works fine. Specifically:
> 
> fbcon on top of fbdev provided by nouveau -- colors are fine
> glxgears hw-accelerated by mesa on top of xf86-video-nouveau using
> DRI2 -- colors are fine
> glxgears softpipe-accelerated by mesa on top of xf86-video-nouveau --
> colors are fine
> glxgears softpipe-accelerated by mesa on top of xf86-video-modesetting
> -- colors are fine
> xterm on top of xf86-video-nouveau -- colors are fine
> xterm on top of xf86-video-modesetting -- colors are fine
> 
> I couldn't test anything with GLAMOR since GLAMOR requires GL 2.1 or
> higher, whereas nouveau's NV3x acceleration only provides GL 1.5 (due
> to lacking NPOT and a handful of other things).
> 
> The modetest utility did have trouble with AR24 and I'm pretty sure
> the XR24 pattern was off too. However I wouldn't be surprised if the
> modetest utility itself had endian issues in the pattern generation
> logic. (Seems to be the case, based on a quick glance at the
> tests/util/format.c logic and how it's used in pattern.c.)
> 
> So in short, I think the current definitions of format are fine.

I agree with Pekka that it's not that simple. What you've established is
that things look fine after going through several layers of abstraction.
It's possible that multiple bugs in those layers cancel each other out;
in particular, it's quite likely that the code dealing with DRM formats
is treating them as using native endianness (one possible giveaway for
that is using shifts for (un)packing colour components).


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Michel Dänzer]

On 17/04/17 03:43 PM, Ilia Mirkin wrote:
> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin  wrote:
>>> However, I totally agree with Alex that someone with a BE machine
>>> should review the whole stack before we could be confident with anything.
>>
>> Here's what I'm confident about: xf86-video-nouveau worked just fine
>> on top of kernel 4.3 on an AGP GeForce FX 5200 (with AGPGART turned
>> off because ... well ... uninorth). fbcon/fbdev accel worked,
>> xf86-video-nouveau's 2d accel worked, and simple demos (ala glxgears)
>> worked after I fixed up mesa and nv30 driver items in version ... 11.1
>> it seems. As I recall it had gotten all broken in 10.0 or so by Adam
>> Jackson in the name of making llvmpipe work on BE, declaring all other
>> drivers broken, with various fixes by Michel Dänzer to get it back to
>> working over the years.
>>
>> Anyone "fixing" the stack has to maintain that level of functioning
>> through their various fixing.
>>
>> I will double-check that the above still works with the latest
>> kernel/xorg/xf86-video-nouveau/mesa and report back (hopefully by this
>> weekend). If there are any patches you'd like me to test, now's the
>> time to ask -- getting the box up and running is the hard part,
>> booting up an extra kernel -- easy.
> 
> OK, so I revived my PowerMac7,3 G5 setup (PPC64 BE, NV34 GPU). Booted
> it with an upstream 4.11-rc7 kernel, loaded up the nouveau kernel
> module (which is included in that kernel), updated X to 1.19.2 and
> mesa to 17.0.3. Everything works fine. Specifically:
> 
> fbcon on top of fbdev provided by nouveau -- colors are fine
> glxgears hw-accelerated by mesa on top of xf86-video-nouveau using
> DRI2 -- colors are fine
> glxgears softpipe-accelerated by mesa on top of xf86-video-nouveau --
> colors are fine
> glxgears softpipe-accelerated by mesa on top of xf86-video-modesetting
> -- colors are fine
> xterm on top of xf86-video-nouveau -- colors are fine
> xterm on top of xf86-video-modesetting -- colors are fine
> 
> I couldn't test anything with GLAMOR since GLAMOR requires GL 2.1 or
> higher, whereas nouveau's NV3x acceleration only provides GL 1.5 (due
> to lacking NPOT and a handful of other things).
> 
> The modetest utility did have trouble with AR24 and I'm pretty sure
> the XR24 pattern was off too. However I wouldn't be surprised if the
> modetest utility itself had endian issues in the pattern generation
> logic. (Seems to be the case, based on a quick glance at the
> tests/util/format.c logic and how it's used in pattern.c.)
> 
> So in short, I think the current definitions of format are fine.

I agree with Pekka that it's not that simple. What you've established is
that things look fine after going through several layers of abstraction.
It's possible that multiple bugs in those layers cancel each other out;
in particular, it's quite likely that the code dealing with DRM formats
is treating them as using native endianness (one possible giveaway for
that is using shifts for (un)packing colour components).


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[RFC] using #pragma push_macro and pop_macro

[Joe Perches]

There is an argument for using these #pragmas for pr_fmt.

gcc/clang/icc all support push_macro and pop_macro pragmas.

As far as I can tell, these compilers are the only ones
used to compile
the kernel.

Anyone have any objection to using these pragmas?

On Tue, 2017-04-18 at 05:02 +0800, kbuild test robot wrote:
> Hi Joe,
> 
> [auto build test ERROR on v4.9-rc8]
> [also build test ERROR on next-20170413]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Joe-Perches/device-mapper-Convert-printks-to-pr_-level-macros/20170418-030508
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All error/warnings (new ones prefixed by >>):
> 
>In file included from fs/nfs/blocklayout/blocklayout.h:35:0,
> from fs/nfs/blocklayout/dev.c:11:
>fs/nfs/blocklayout/dev.c: In function 'bl_free_device':
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
> > > include/linux/printk.h:277:18: note: in expansion of macro 'pr_fmt'
> 
>  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>  ^~
> > > fs/nfs/blocklayout/dev.c:33:5: note: in expansion of macro 'pr_err'
> 
> pr_err("failed to unregister PR key.\n");
> ^~
>fs/nfs/blocklayout/dev.c: In function 'nfs4_block_decode_volume':
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
>include/linux/printk.h:284:19: note: in expansion of macro 'pr_fmt'
>  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
>   ^~
> > > fs/nfs/blocklayout/dev.c:81:5: note: in expansion of macro 'pr_info'
> 
> pr_info("signature too long: %d\n",
> ^~~
>fs/nfs/blocklayout/dev.c: In function 'bl_validate_designator':
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
> > > include/linux/printk.h:277:18: note: in expansion of macro 'pr_fmt'
> 
>  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>  ^~
>fs/nfs/blocklayout/dev.c:287:3: note: in expansion of macro 'pr_err'
>   pr_err("pNFS: unsupported designator "
>   ^~
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
> > > include/linux/printk.h:277:18: note: in expansion of macro 'pr_fmt'
> 
>  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>  ^~
>fs/nfs/blocklayout/dev.c:294:3: note: in expansion of macro 'pr_err'
>   pr_err("pNFS: invalid designator "
>   ^~
>fs/nfs/blocklayout/dev.c: In function 'bl_open_udev_path':
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
>include/linux/printk.h:279:22: note: in expansion of macro 'pr_fmt'
>  printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
>  ^~
>include/linux/printk.h:280:17: note: in expansion of macro 'pr_warning'
> #define pr_warn pr_warning
> ^~
> > > fs/nfs/blocklayout/dev.c:320:3: note: in expansion of macro 'pr_warn'
> 
>   pr_warn("pNFS: failed to open device %s (%ld)\n",
>   ^~~
>fs/nfs/blocklayout/dev.c: In function 'bl_parse_scsi':
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
>include/linux/printk.h:284:19: note: in expansion of macro 'pr_fmt'
>  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
>   ^~
>fs/nfs/blocklayout/dev.c:373:2: note: in expansion of macro 'pr_info'
>  pr_info("pNFS: using block device %s (reservation key 0x%llx)\n",
>  ^~~
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
> > > include/linux/printk.h:277:18: note: in expansion of macro 'pr_fmt'
> 
>  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>  ^~
>fs/nfs/blocklayout/dev.c:378:3: note: in expansion of macro 'pr_err'
>   pr_err("pNFS: block device %s does not support 

[RFC] using #pragma push_macro and pop_macro

[Joe Perches]

There is an argument for using these #pragmas for pr_fmt.

gcc/clang/icc all support push_macro and pop_macro pragmas.

As far as I can tell, these compilers are the only ones
used to compile
the kernel.

Anyone have any objection to using these pragmas?

On Tue, 2017-04-18 at 05:02 +0800, kbuild test robot wrote:
> Hi Joe,
> 
> [auto build test ERROR on v4.9-rc8]
> [also build test ERROR on next-20170413]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Joe-Perches/device-mapper-Convert-printks-to-pr_-level-macros/20170418-030508
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All error/warnings (new ones prefixed by >>):
> 
>In file included from fs/nfs/blocklayout/blocklayout.h:35:0,
> from fs/nfs/blocklayout/dev.c:11:
>fs/nfs/blocklayout/dev.c: In function 'bl_free_device':
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
> > > include/linux/printk.h:277:18: note: in expansion of macro 'pr_fmt'
> 
>  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>  ^~
> > > fs/nfs/blocklayout/dev.c:33:5: note: in expansion of macro 'pr_err'
> 
> pr_err("failed to unregister PR key.\n");
> ^~
>fs/nfs/blocklayout/dev.c: In function 'nfs4_block_decode_volume':
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
>include/linux/printk.h:284:19: note: in expansion of macro 'pr_fmt'
>  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
>   ^~
> > > fs/nfs/blocklayout/dev.c:81:5: note: in expansion of macro 'pr_info'
> 
> pr_info("signature too long: %d\n",
> ^~~
>fs/nfs/blocklayout/dev.c: In function 'bl_validate_designator':
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
> > > include/linux/printk.h:277:18: note: in expansion of macro 'pr_fmt'
> 
>  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>  ^~
>fs/nfs/blocklayout/dev.c:287:3: note: in expansion of macro 'pr_err'
>   pr_err("pNFS: unsupported designator "
>   ^~
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
> > > include/linux/printk.h:277:18: note: in expansion of macro 'pr_fmt'
> 
>  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>  ^~
>fs/nfs/blocklayout/dev.c:294:3: note: in expansion of macro 'pr_err'
>   pr_err("pNFS: invalid designator "
>   ^~
>fs/nfs/blocklayout/dev.c: In function 'bl_open_udev_path':
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
>include/linux/printk.h:279:22: note: in expansion of macro 'pr_fmt'
>  printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
>  ^~
>include/linux/printk.h:280:17: note: in expansion of macro 'pr_warning'
> #define pr_warn pr_warning
> ^~
> > > fs/nfs/blocklayout/dev.c:320:3: note: in expansion of macro 'pr_warn'
> 
>   pr_warn("pNFS: failed to open device %s (%ld)\n",
>   ^~~
>fs/nfs/blocklayout/dev.c: In function 'bl_parse_scsi':
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
>include/linux/printk.h:284:19: note: in expansion of macro 'pr_fmt'
>  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
>   ^~
>fs/nfs/blocklayout/dev.c:373:2: note: in expansion of macro 'pr_info'
>  pr_info("pNFS: using block device %s (reservation key 0x%llx)\n",
>  ^~~
> > > include/linux/device-mapper.h:536:34: error: expected ')' before 
> > > 'DM_MSG_PREFIX'
> 
> #define pr_fmt(fmt) DM_NAME ": " DM_MSG_PREFIX ": " fmt
>  ^
> > > include/linux/printk.h:277:18: note: in expansion of macro 'pr_fmt'
> 
>  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>  ^~
>fs/nfs/blocklayout/dev.c:378:3: note: in expansion of macro 'pr_err'
>   pr_err("pNFS: block device %s does not support 

Re: [PATCH 1/3] zram: fix operator precedence to get offset

[Minchan Kim]

On Tue, Apr 18, 2017 at 10:53:10AM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (04/18/17 08:53), Minchan Kim wrote:
> > On Mon, Apr 17, 2017 at 07:50:16PM +0900, Sergey Senozhatsky wrote:
> > > Hello Minchan,
> > > 
> > > On (04/17/17 11:14), Minchan Kim wrote:
> > > > On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote:
> > > > > On (04/17/17 10:21), Sergey Senozhatsky wrote:
> > > > > > > However, it should be *fixed* to prevent confusion in future
> > > > > 
> > > > > or may be something like below? can save us some cycles.
> > > > > 
> > > > > remove this calculation
> > > > > 
> > > > > -   offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_SHIFT;
> > > > > 
> > > > > 
> > > > > and pass 0 to zram_bvec_rw()
> > > > > 
> > > > > -   err = zram_bvec_rw(zram, , index, offset, is_write);
> > > > > +   err = zram_bvec_rw(zram, , index, 0, is_write);
> > > > 
> > > > That was one I wrote but have thought it more.
> > > > 
> > > > Because I suspect fs can submit page-size IO in non-aligned PAGE_SIZE
> > > > sector? For example, it can submit PAGE_SIZE read request from 9 sector.
> > > > Is it possible? I don't know.
> > > > 
> > > > As well, FS can format zram from sector 1, not sector 0? IOW, can't it
> > > > use starting sector as non-page algined sector?
> > > > We can do it via fdisk?
> > > > 
> > > > Anyway, If one of scenario I mentioned is possible, zram_rw_page will
> > > > be broken.
> > > > 
> > > > If it's hard to check all of scenario in this moment, it would be
> > > > better to not remove it and then add WARN_ON(offset) in there.
> > > > 
> > > > While I am writing this, I found this.
> > > > 
> > > > /**
> > > >  * bdev_read_page() - Start reading a page from a block device
> > > >  * @bdev: The device to read the page from
> > > >  * @sector: The offset on the device to read the page to (need not be 
> > > > aligned)
> > > >  * @page: The page to read
> > > >  *
> > > > 
> > > > Hmm,, need investigation but no time.
> > > 
> > > good questions.
> > > 
> > > as far as I can see, we never use 'offset' which we pass to zram_bvec_rw()
> > > from zram_rw_page(). `offset' makes a lot of sense for partial IO, but in
> > > zram_bvec_rw() we always do "bv.bv_len = PAGE_SIZE".
> > > 
> > > so what we have is
> > > 
> > > for READ
> > > 
> > > zram_rw_page()
> > >   bv.bv_len = PAGE_SIZE
> > >   zram_bvec_rw(zram, , index, offset, is_write);
> > >   zram_bvec_read()
> > >   if (is_partial_io(bvec))// always false
> > >   memcpy(user_mem + bvec->bv_offset,
> > >   uncmem + offset,
> > >   bvec->bv_len);
> > > 
> > > 
> > > for WRITE
> > > 
> > > zram_rw_page()
> > >   bv.bv_len = PAGE_SIZE
> > >   zram_bvec_rw(zram, , index, offset, is_write);
> > >   zram_bvec_write()
> > >   if (is_partial_io(bvec))// always false
> > >   memcpy(uncmem + offset,
> > >   user_mem + bvec->bv_offset,
> > >   bvec->bv_len);
> > > 
> > > 
> > > and our is_partial_io() looks at ->bv_len:
> > > 
> > >   bvec->bv_len != PAGE_SIZE;
> > > 
> > > which we set to PAGE_SIZE.
> > > 
> > > so in the existing scheme of things, we never care about 'sector'
> > > passed from zram_rw_page(). and this has worked for us for quite
> > > some time. my call would be -- let's drop zram_rw_page() `sector'
> > > calculation.
> > 
> > I can do but before that, I want to confirm. Ccing Matthew,
> > Summary for Matthew,
> > 
> > I see following comment about the sector from bdev_read_page.
> > 
> > /**
> >  * bdev_read_page() - Start reading a page from a block device
> >  * @bdev: The device to read the page from
> >  * @sector: The offset on the device to read the page to (need not be 
> > aligned)
> >  * @page: The page to read
> >  *
> > 
> > Does it mean that sector can be not aligned PAGE_SIZE?
> > 
> > For example, 512byte sector, 4K page system, 4K = 8 sector
> > 
> > bdev_read_page(bdev, 9, page);
> 
> do you mean a sector that spans two pages? sectors are pow of 2 in size
> and pages are pow of 2 in size, so page_size is `K * sector_size', isn't
> it?
> 
> fs/mpage.c
> 
> static struct bio *
> do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages,
> sector_t *last_block_in_bio, struct buffer_head *map_bh,
> unsigned long *first_logical_block, get_block_t get_block,
> gfp_t gfp)
> {
> const unsigned blkbits = inode->i_blkbits;
> const unsigned blocks_per_page = PAGE_SIZE >> blkbits;
> const unsigned blocksize = 1 << blkbits;
> sector_t block_in_file;
> sector_t last_block;
> sector_t last_block_in_file;
> sector_t blocks[MAX_BUF_PER_PAGE];
>   ...
> block_in_file = (sector_t)page->index << (PAGE_SHIFT - 

Re: [PATCH 1/3] zram: fix operator precedence to get offset

[Minchan Kim]

On Tue, Apr 18, 2017 at 10:53:10AM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (04/18/17 08:53), Minchan Kim wrote:
> > On Mon, Apr 17, 2017 at 07:50:16PM +0900, Sergey Senozhatsky wrote:
> > > Hello Minchan,
> > > 
> > > On (04/17/17 11:14), Minchan Kim wrote:
> > > > On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote:
> > > > > On (04/17/17 10:21), Sergey Senozhatsky wrote:
> > > > > > > However, it should be *fixed* to prevent confusion in future
> > > > > 
> > > > > or may be something like below? can save us some cycles.
> > > > > 
> > > > > remove this calculation
> > > > > 
> > > > > -   offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_SHIFT;
> > > > > 
> > > > > 
> > > > > and pass 0 to zram_bvec_rw()
> > > > > 
> > > > > -   err = zram_bvec_rw(zram, , index, offset, is_write);
> > > > > +   err = zram_bvec_rw(zram, , index, 0, is_write);
> > > > 
> > > > That was one I wrote but have thought it more.
> > > > 
> > > > Because I suspect fs can submit page-size IO in non-aligned PAGE_SIZE
> > > > sector? For example, it can submit PAGE_SIZE read request from 9 sector.
> > > > Is it possible? I don't know.
> > > > 
> > > > As well, FS can format zram from sector 1, not sector 0? IOW, can't it
> > > > use starting sector as non-page algined sector?
> > > > We can do it via fdisk?
> > > > 
> > > > Anyway, If one of scenario I mentioned is possible, zram_rw_page will
> > > > be broken.
> > > > 
> > > > If it's hard to check all of scenario in this moment, it would be
> > > > better to not remove it and then add WARN_ON(offset) in there.
> > > > 
> > > > While I am writing this, I found this.
> > > > 
> > > > /**
> > > >  * bdev_read_page() - Start reading a page from a block device
> > > >  * @bdev: The device to read the page from
> > > >  * @sector: The offset on the device to read the page to (need not be 
> > > > aligned)
> > > >  * @page: The page to read
> > > >  *
> > > > 
> > > > Hmm,, need investigation but no time.
> > > 
> > > good questions.
> > > 
> > > as far as I can see, we never use 'offset' which we pass to zram_bvec_rw()
> > > from zram_rw_page(). `offset' makes a lot of sense for partial IO, but in
> > > zram_bvec_rw() we always do "bv.bv_len = PAGE_SIZE".
> > > 
> > > so what we have is
> > > 
> > > for READ
> > > 
> > > zram_rw_page()
> > >   bv.bv_len = PAGE_SIZE
> > >   zram_bvec_rw(zram, , index, offset, is_write);
> > >   zram_bvec_read()
> > >   if (is_partial_io(bvec))// always false
> > >   memcpy(user_mem + bvec->bv_offset,
> > >   uncmem + offset,
> > >   bvec->bv_len);
> > > 
> > > 
> > > for WRITE
> > > 
> > > zram_rw_page()
> > >   bv.bv_len = PAGE_SIZE
> > >   zram_bvec_rw(zram, , index, offset, is_write);
> > >   zram_bvec_write()
> > >   if (is_partial_io(bvec))// always false
> > >   memcpy(uncmem + offset,
> > >   user_mem + bvec->bv_offset,
> > >   bvec->bv_len);
> > > 
> > > 
> > > and our is_partial_io() looks at ->bv_len:
> > > 
> > >   bvec->bv_len != PAGE_SIZE;
> > > 
> > > which we set to PAGE_SIZE.
> > > 
> > > so in the existing scheme of things, we never care about 'sector'
> > > passed from zram_rw_page(). and this has worked for us for quite
> > > some time. my call would be -- let's drop zram_rw_page() `sector'
> > > calculation.
> > 
> > I can do but before that, I want to confirm. Ccing Matthew,
> > Summary for Matthew,
> > 
> > I see following comment about the sector from bdev_read_page.
> > 
> > /**
> >  * bdev_read_page() - Start reading a page from a block device
> >  * @bdev: The device to read the page from
> >  * @sector: The offset on the device to read the page to (need not be 
> > aligned)
> >  * @page: The page to read
> >  *
> > 
> > Does it mean that sector can be not aligned PAGE_SIZE?
> > 
> > For example, 512byte sector, 4K page system, 4K = 8 sector
> > 
> > bdev_read_page(bdev, 9, page);
> 
> do you mean a sector that spans two pages? sectors are pow of 2 in size
> and pages are pow of 2 in size, so page_size is `K * sector_size', isn't
> it?
> 
> fs/mpage.c
> 
> static struct bio *
> do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages,
> sector_t *last_block_in_bio, struct buffer_head *map_bh,
> unsigned long *first_logical_block, get_block_t get_block,
> gfp_t gfp)
> {
> const unsigned blkbits = inode->i_blkbits;
> const unsigned blocks_per_page = PAGE_SIZE >> blkbits;
> const unsigned blocksize = 1 << blkbits;
> sector_t block_in_file;
> sector_t last_block;
> sector_t last_block_in_file;
> sector_t blocks[MAX_BUF_PER_PAGE];
>   ...
> block_in_file = (sector_t)page->index << (PAGE_SHIFT -