[PATCH] staging: dgnc: re-arrange functions for removing forward declarations

[Daeseok Youn]

Re-arrange the functions for removing forward declarations in dgnc_driver.c

Signed-off-by: Daeseok Youn 
---
I've checked the object size of dgnc_driver.c before and after.
It has same size after re-arranging functions.

 drivers/staging/dgnc/dgnc_driver.c | 533 ++---
 1 file changed, 261 insertions(+), 272 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_driver.c 
b/drivers/staging/dgnc/dgnc_driver.c
index d3243a3..6f2bffa 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -31,21 +31,6 @@
 MODULE_DESCRIPTION("Driver for the Digi International Neo and Classic PCI 
based product line");
 MODULE_SUPPORTED_DEVICE("dgnc");
 
-/**
- *
- * protos for this file
- *
- */
-static int dgnc_start(void);
-static int dgnc_request_irq(struct dgnc_board *brd);
-static void dgnc_free_irq(struct dgnc_board *brd);
-static struct dgnc_board *dgnc_found_board(struct pci_dev *pdev, int id);
-static voiddgnc_cleanup_board(struct dgnc_board *brd);
-static voiddgnc_poll_handler(ulong dummy);
-static int dgnc_init_one(struct pci_dev *pdev,
- const struct pci_device_id *ent);
-static int dgnc_do_remap(struct dgnc_board *brd);
-
 /*
  * File operations permitted on Control/Management major.
  */
@@ -114,261 +99,23 @@ struct board_id {
{   NULL,   0,  0   }
 };
 
-static struct pci_driver dgnc_driver = {
-   .name   = "dgnc",
-   .probe  = dgnc_init_one,
-   .id_table   = dgnc_pci_tbl,
-};
-
-/
- *
- * Driver load/unload functions
- *
- /
-
-static void cleanup(bool sysfiles)
-{
-   int i;
-   unsigned long flags;
-
-   spin_lock_irqsave(_poll_lock, flags);
-   dgnc_poll_stop = 1;
-   spin_unlock_irqrestore(_poll_lock, flags);
-
-   /* Turn off poller right away. */
-   del_timer_sync(_poll_timer);
-
-   if (sysfiles)
-   dgnc_remove_driver_sysfiles(_driver);
-
-   device_destroy(dgnc_class, MKDEV(dgnc_major, 0));
-   class_destroy(dgnc_class);
-   unregister_chrdev(dgnc_major, "dgnc");
-
-   for (i = 0; i < dgnc_num_boards; ++i) {
-   dgnc_remove_ports_sysfiles(dgnc_board[i]);
-   dgnc_cleanup_tty(dgnc_board[i]);
-   dgnc_cleanup_board(dgnc_board[i]);
-   }
-
-}
-
-/*
- * dgnc_cleanup_module()
- *
- * Module unload.  This is where it all ends.
- */
-static void __exit dgnc_cleanup_module(void)
-{
-   cleanup(true);
-   pci_unregister_driver(_driver);
-}
-
-/*
- * init_module()
- *
- * Module load.  This is where it all starts.
- */
-static int __init dgnc_init_module(void)
-{
-   int rc;
-
-   /*
-* Initialize global stuff
-*/
-   rc = dgnc_start();
-
-   if (rc < 0)
-   return rc;
-
-   /*
-* Find and configure all the cards
-*/
-   rc = pci_register_driver(_driver);
-   if (rc) {
-   pr_warn("WARNING: dgnc driver load failed.  No Digi Neo or 
Classic boards found.\n");
-   cleanup(false);
-   return rc;
-   }
-   dgnc_create_driver_sysfiles(_driver);
-
-   return 0;
-}
 
-module_init(dgnc_init_module);
-module_exit(dgnc_cleanup_module);
 
 /*
- * Start of driver.
+ * Remap PCI memory.
  */
-static int dgnc_start(void)
+static int dgnc_do_remap(struct dgnc_board *brd)
 {
int rc = 0;
-   unsigned long flags;
-   struct device *dev;
-
-   /* make sure timer is initialized before we do anything else */
-   init_timer(_poll_timer);
-
-   /*
-* Register our base character device into the kernel.
-* This allows the download daemon to connect to the downld device
-* before any of the boards are init'ed.
-*
-* Register management/dpa devices
-*/
-   rc = register_chrdev(0, "dgnc", _board_fops);
-   if (rc < 0) {
-   pr_err(DRVSTR ": Can't register dgnc driver device (%d)\n", rc);
-   return rc;
-   }
-   dgnc_major = rc;
-
-   dgnc_class = class_create(THIS_MODULE, "dgnc_mgmt");
-   if (IS_ERR(dgnc_class)) {
-   rc = PTR_ERR(dgnc_class);
-   pr_err(DRVSTR ": Can't create dgnc_mgmt class (%d)\n", rc);
-   goto failed_class;
-   }
-
-   dev = device_create(dgnc_class, NULL,
-   MKDEV(dgnc_major, 0),
-   NULL, "dgnc_mgmt");
-   if (IS_ERR(dev)) {
-   rc = PTR_ERR(dev);
-   pr_err(DRVSTR ": Can't create device (%d)\n", rc);
-   goto failed_device;
-   }
-
-   /* Start the 

[PATCH] staging: dgnc: re-arrange functions for removing forward declarations

[Daeseok Youn]

Re-arrange the functions for removing forward declarations in dgnc_driver.c

Signed-off-by: Daeseok Youn 
---
I've checked the object size of dgnc_driver.c before and after.
It has same size after re-arranging functions.

 drivers/staging/dgnc/dgnc_driver.c | 533 ++---
 1 file changed, 261 insertions(+), 272 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_driver.c 
b/drivers/staging/dgnc/dgnc_driver.c
index d3243a3..6f2bffa 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -31,21 +31,6 @@
 MODULE_DESCRIPTION("Driver for the Digi International Neo and Classic PCI 
based product line");
 MODULE_SUPPORTED_DEVICE("dgnc");
 
-/**
- *
- * protos for this file
- *
- */
-static int dgnc_start(void);
-static int dgnc_request_irq(struct dgnc_board *brd);
-static void dgnc_free_irq(struct dgnc_board *brd);
-static struct dgnc_board *dgnc_found_board(struct pci_dev *pdev, int id);
-static voiddgnc_cleanup_board(struct dgnc_board *brd);
-static voiddgnc_poll_handler(ulong dummy);
-static int dgnc_init_one(struct pci_dev *pdev,
- const struct pci_device_id *ent);
-static int dgnc_do_remap(struct dgnc_board *brd);
-
 /*
  * File operations permitted on Control/Management major.
  */
@@ -114,261 +99,23 @@ struct board_id {
{   NULL,   0,  0   }
 };
 
-static struct pci_driver dgnc_driver = {
-   .name   = "dgnc",
-   .probe  = dgnc_init_one,
-   .id_table   = dgnc_pci_tbl,
-};
-
-/
- *
- * Driver load/unload functions
- *
- /
-
-static void cleanup(bool sysfiles)
-{
-   int i;
-   unsigned long flags;
-
-   spin_lock_irqsave(_poll_lock, flags);
-   dgnc_poll_stop = 1;
-   spin_unlock_irqrestore(_poll_lock, flags);
-
-   /* Turn off poller right away. */
-   del_timer_sync(_poll_timer);
-
-   if (sysfiles)
-   dgnc_remove_driver_sysfiles(_driver);
-
-   device_destroy(dgnc_class, MKDEV(dgnc_major, 0));
-   class_destroy(dgnc_class);
-   unregister_chrdev(dgnc_major, "dgnc");
-
-   for (i = 0; i < dgnc_num_boards; ++i) {
-   dgnc_remove_ports_sysfiles(dgnc_board[i]);
-   dgnc_cleanup_tty(dgnc_board[i]);
-   dgnc_cleanup_board(dgnc_board[i]);
-   }
-
-}
-
-/*
- * dgnc_cleanup_module()
- *
- * Module unload.  This is where it all ends.
- */
-static void __exit dgnc_cleanup_module(void)
-{
-   cleanup(true);
-   pci_unregister_driver(_driver);
-}
-
-/*
- * init_module()
- *
- * Module load.  This is where it all starts.
- */
-static int __init dgnc_init_module(void)
-{
-   int rc;
-
-   /*
-* Initialize global stuff
-*/
-   rc = dgnc_start();
-
-   if (rc < 0)
-   return rc;
-
-   /*
-* Find and configure all the cards
-*/
-   rc = pci_register_driver(_driver);
-   if (rc) {
-   pr_warn("WARNING: dgnc driver load failed.  No Digi Neo or 
Classic boards found.\n");
-   cleanup(false);
-   return rc;
-   }
-   dgnc_create_driver_sysfiles(_driver);
-
-   return 0;
-}
 
-module_init(dgnc_init_module);
-module_exit(dgnc_cleanup_module);
 
 /*
- * Start of driver.
+ * Remap PCI memory.
  */
-static int dgnc_start(void)
+static int dgnc_do_remap(struct dgnc_board *brd)
 {
int rc = 0;
-   unsigned long flags;
-   struct device *dev;
-
-   /* make sure timer is initialized before we do anything else */
-   init_timer(_poll_timer);
-
-   /*
-* Register our base character device into the kernel.
-* This allows the download daemon to connect to the downld device
-* before any of the boards are init'ed.
-*
-* Register management/dpa devices
-*/
-   rc = register_chrdev(0, "dgnc", _board_fops);
-   if (rc < 0) {
-   pr_err(DRVSTR ": Can't register dgnc driver device (%d)\n", rc);
-   return rc;
-   }
-   dgnc_major = rc;
-
-   dgnc_class = class_create(THIS_MODULE, "dgnc_mgmt");
-   if (IS_ERR(dgnc_class)) {
-   rc = PTR_ERR(dgnc_class);
-   pr_err(DRVSTR ": Can't create dgnc_mgmt class (%d)\n", rc);
-   goto failed_class;
-   }
-
-   dev = device_create(dgnc_class, NULL,
-   MKDEV(dgnc_major, 0),
-   NULL, "dgnc_mgmt");
-   if (IS_ERR(dev)) {
-   rc = PTR_ERR(dev);
-   pr_err(DRVSTR ": Can't create device (%d)\n", rc);
-   goto failed_device;
-   }
-
-   /* Start the poller */
-   

Re: BYD TouchPad driver (4.8.1) misdetects a Logitech mouse

[Ondrej Zary]

On Friday 11 November 2016, Eric Wong wrote:
> Sorry for the late response, forwarding to Dmitry and linux-input.
> I haven't dealt with input in years...
>
> Michael Shell  wrote:
> > Not a big deal, but something nonetheless ...
> >
> > I recently upgraded my kernel from 4.3 to 4.8.1 (this is a Linux From
> > Scratch build). There was only one obvious hiccup - X would not
> > start because it no longer saw the mouse.
> >
> > I have a Logitech RX250 PS2/USB mouse on the PS/2 port (via a USB->PS2
> > adapter):
> >
> > http://support.logitech.com/en_gb/product/rx250-mouse
> >
> > The RX250 is a wheel mouse, but with an added left/right scroll wheel
> > "tilt" feature to provide for horizontal scrolling.
> >
> > In my xorg.conf I had:
> >
> >
> > Section "InputDevice"
> > Identifier  "Mouse0"
> > Driver  "evdev"
> > Option  "Name"  "ImExPS/2 Logitech Explorer Mouse"
> > EndSection
> >
> >
> > However, under the 4.8.1 kernel, cat /proc/bus/input/devices shows:
> >
> >
> > I: Bus=0011 Vendor=0002 Product=0006 Version=0073
> > N: Name="ImExPS/2 BYD TouchPad"
> > P: Phys=isa0060/serio1/input0
> > S: Sysfs=/devices/platform/i8042/serio1/input/input3
> > U: Uniq=
> > H: Handlers=mouse0 event2
> > B: PROP=1
> > B: EV=7
> > B: KEY=1f 0 0 0 0 0 0 0 0
> > B: REL=143
> >
> >
> > and dmesg shows the lines:
> >
> >
> > psmouse serio1: logips2pp: Detected unknown Logitech mouse model 115
> > input: ImExPS/2 BYD TouchPad as
> > /devices/platform/i8042/serio1/input/input3
> >
> >
> > Changing the mouse name in xorg.conf to "ImExPS/2 BYD TouchPad" did
> > allow the mouse to work correctly under X, including the tilt buttons.
> > FWIW, in the 4.8.1 kernel config, the byd.c driver does default to
> > "Yes", a default which I accepted under make oldconfig.
> >
> > Apparently, the detection code (byd_detect) in the new byd.c driver,
> > which did not even exist in 4.3, (drivers/input/mouse/byd.c) falsely
> > sees the Logitech RX250 as being a BYD TouchPad and thus alters the
> > vendor and model names.
> >
> > I do not know if it is also desirable to add an entry for a Logitech
> > model 115 in get_model_info in logips2pp.c
> > (drivers/input/mouse/logips2pp.c). But if so, I would be willing to
> > test any such new code. Even as an unknown Logitech model, it does
> > work just fine. I am curious as to how the tilt feature buttons would
> > be declared in the model info (would these be PS2PP_EXTRA_BTN,
> > or PS2PP_NAV_BTN, etc.?)
> >
> >
> >
> >   Cheers and thanks in advance,
> >
> >   Mike Shell

The BYD detection is broken. I've seen at least 3 different mice detected as 
BYD touchpad.

-- 
Ondrej Zary

Re: BYD TouchPad driver (4.8.1) misdetects a Logitech mouse

[Ondrej Zary]

On Friday 11 November 2016, Eric Wong wrote:
> Sorry for the late response, forwarding to Dmitry and linux-input.
> I haven't dealt with input in years...
>
> Michael Shell  wrote:
> > Not a big deal, but something nonetheless ...
> >
> > I recently upgraded my kernel from 4.3 to 4.8.1 (this is a Linux From
> > Scratch build). There was only one obvious hiccup - X would not
> > start because it no longer saw the mouse.
> >
> > I have a Logitech RX250 PS2/USB mouse on the PS/2 port (via a USB->PS2
> > adapter):
> >
> > http://support.logitech.com/en_gb/product/rx250-mouse
> >
> > The RX250 is a wheel mouse, but with an added left/right scroll wheel
> > "tilt" feature to provide for horizontal scrolling.
> >
> > In my xorg.conf I had:
> >
> >
> > Section "InputDevice"
> > Identifier  "Mouse0"
> > Driver  "evdev"
> > Option  "Name"  "ImExPS/2 Logitech Explorer Mouse"
> > EndSection
> >
> >
> > However, under the 4.8.1 kernel, cat /proc/bus/input/devices shows:
> >
> >
> > I: Bus=0011 Vendor=0002 Product=0006 Version=0073
> > N: Name="ImExPS/2 BYD TouchPad"
> > P: Phys=isa0060/serio1/input0
> > S: Sysfs=/devices/platform/i8042/serio1/input/input3
> > U: Uniq=
> > H: Handlers=mouse0 event2
> > B: PROP=1
> > B: EV=7
> > B: KEY=1f 0 0 0 0 0 0 0 0
> > B: REL=143
> >
> >
> > and dmesg shows the lines:
> >
> >
> > psmouse serio1: logips2pp: Detected unknown Logitech mouse model 115
> > input: ImExPS/2 BYD TouchPad as
> > /devices/platform/i8042/serio1/input/input3
> >
> >
> > Changing the mouse name in xorg.conf to "ImExPS/2 BYD TouchPad" did
> > allow the mouse to work correctly under X, including the tilt buttons.
> > FWIW, in the 4.8.1 kernel config, the byd.c driver does default to
> > "Yes", a default which I accepted under make oldconfig.
> >
> > Apparently, the detection code (byd_detect) in the new byd.c driver,
> > which did not even exist in 4.3, (drivers/input/mouse/byd.c) falsely
> > sees the Logitech RX250 as being a BYD TouchPad and thus alters the
> > vendor and model names.
> >
> > I do not know if it is also desirable to add an entry for a Logitech
> > model 115 in get_model_info in logips2pp.c
> > (drivers/input/mouse/logips2pp.c). But if so, I would be willing to
> > test any such new code. Even as an unknown Logitech model, it does
> > work just fine. I am curious as to how the tilt feature buttons would
> > be declared in the model info (would these be PS2PP_EXTRA_BTN,
> > or PS2PP_NAV_BTN, etc.?)
> >
> >
> >
> >   Cheers and thanks in advance,
> >
> >   Mike Shell

The BYD detection is broken. I've seen at least 3 different mice detected as 
BYD touchpad.

-- 
Ondrej Zary

Re: [PATCH v4 1/5] arm64: perf: Basic uncore counter support for Cavium ThunderX SOC

[Jan Glauber]

On Thu, Nov 10, 2016 at 04:54:06PM +, Mark Rutland wrote:
> > +/*
> > + * Some notes about the various counters supported by this "uncore" PMU
> > + * and the design:
> > + *
> > + * All counters are 64 bit long.
> > + * There are no overflow interrupts.
> > + * Counters are summarized per node/socket.
> > + * Most devices appear as separate PCI devices per socket with the 
> > exception
> > + * of OCX TLK which appears as one PCI device per socket and contains 
> > several
> > + * units with counters that are merged.
> 
> As a general note, as I commented on the QC L2 PMU driver [1,2], we need
> to figure out if we should be aggregating physical PMUs or not.

As said before, although it would be possible to create separate PMUs
for each unit, the individual counters are not interesting. For example
we are not interested in individual counters of Tag-and-data unit 0..7,
we just want the global view.

> Judging by subsequent patches, each unit has individual counters and
> controls, and thus we cannot atomically read/write counters or controls
> across them. As such, I do not think we should aggregate them, and
> should expose them separately to userspace.

That sounds like just moving the problem of aggregating the counters to
user-space. And would make the results even worse, if the user needs
several calls to summarize the counters, given how slow a perf counter
read is.


> That will simplify a number of things (e.g. the CPU migration code no
> longer has to iterate over a list of units).

Sure, it simplifies the kernel part, but it moves the cost to the user.

Re: [PATCH v4 1/5] arm64: perf: Basic uncore counter support for Cavium ThunderX SOC

[Jan Glauber]

On Thu, Nov 10, 2016 at 04:54:06PM +, Mark Rutland wrote:
> > +/*
> > + * Some notes about the various counters supported by this "uncore" PMU
> > + * and the design:
> > + *
> > + * All counters are 64 bit long.
> > + * There are no overflow interrupts.
> > + * Counters are summarized per node/socket.
> > + * Most devices appear as separate PCI devices per socket with the 
> > exception
> > + * of OCX TLK which appears as one PCI device per socket and contains 
> > several
> > + * units with counters that are merged.
> 
> As a general note, as I commented on the QC L2 PMU driver [1,2], we need
> to figure out if we should be aggregating physical PMUs or not.

As said before, although it would be possible to create separate PMUs
for each unit, the individual counters are not interesting. For example
we are not interested in individual counters of Tag-and-data unit 0..7,
we just want the global view.

> Judging by subsequent patches, each unit has individual counters and
> controls, and thus we cannot atomically read/write counters or controls
> across them. As such, I do not think we should aggregate them, and
> should expose them separately to userspace.

That sounds like just moving the problem of aggregating the counters to
user-space. And would make the results even worse, if the user needs
several calls to summarize the counters, given how slow a perf counter
read is.


> That will simplify a number of things (e.g. the CPU migration code no
> longer has to iterate over a list of units).

Sure, it simplifies the kernel part, but it moves the cost to the user.

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 19:03, Olof Johansson wrote:

On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla  wrote:



On 10/11/16 14:12, Rob Herring wrote:


On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla 
wrote:




On 10/11/16 01:22, Rob Herring wrote:



On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:



This patch adds specific compatible to support legacy SCPI protocol.

Cc: Rob Herring 
Signed-off-by: Sudeep Holla 
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index d1882c4540d0..ebd03fc93135 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -7,7 +7,9 @@ by Linux to initiate various system control and power
operations.

 Required properties:

-- compatible : should be "arm,scpi"
+- compatible : should be
+   * "arm,scpi" : For implementations complying to SCPI v1.0 or
above
+   * "arm,legacy-scpi" : For implementations complying pre SCPI
v1.0




I'd prefer that we explicitly enumerate the old versions. Are there
many?



I understand your concern, but this legacy SCPI protocol was not
officially released. It was just WIP which vendors picked up from very
early releases. Since they are not numbered, it's hard to have specific
compatibles with different versions until v1.0. That's one of the reason
to retain platform specific compatible so that we can add any quirks
based on them if needed.

I will probably add these information in the commit log so that it's
clear why we can't do version based compatible.



This is exactly my point. By enumerate, I meant having platform
specific compatibles. Having "arm,legacy-scpi" is pointless because
who knows what version they followed and they may all be different.



OK, but IIUC Olof's concern wanted a generic one along with the platform
specific compatible which kind of makes sense as so far we have seen
some commonality between Amlogic and Rockchip.

E.g. Amlogic follows most of the legacy protocol though it deviates in
couple of things which we can handle with platform specific compatible
(in the following patch in the series). When another user(Rockchip ?)
make use of this legacy protocol, we can start using those platform
specific compatible for deviations only.

Is that not acceptable ?


If there's no shared legacy feature set, then it's probably less
useful to have a shared less precise compatible value.



There is and will be some shared feature set for sure. At the least the
standard command set will be shared.


What the main point I was trying to get across was that we shouldn't
expand the generic binding with per-vendor compatible fields, instead
we should have those as extensions on the side.



Yes I get the point. We will have per-vendor compatibles for handle the
deviations but generic one to handle the shared set.


I'm also a little apprehensive of using "legacy", it goes in the same
bucket as "misc". At some point 1.0 will be legacy too, etc.



True and I agree, how about "arm,scpi-pre-1.0" instead ?

--
Regards,
Sudeep

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 19:03, Olof Johansson wrote:

On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla  wrote:



On 10/11/16 14:12, Rob Herring wrote:


On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla 
wrote:




On 10/11/16 01:22, Rob Herring wrote:



On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:



This patch adds specific compatible to support legacy SCPI protocol.

Cc: Rob Herring 
Signed-off-by: Sudeep Holla 
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index d1882c4540d0..ebd03fc93135 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -7,7 +7,9 @@ by Linux to initiate various system control and power
operations.

 Required properties:

-- compatible : should be "arm,scpi"
+- compatible : should be
+   * "arm,scpi" : For implementations complying to SCPI v1.0 or
above
+   * "arm,legacy-scpi" : For implementations complying pre SCPI
v1.0




I'd prefer that we explicitly enumerate the old versions. Are there
many?



I understand your concern, but this legacy SCPI protocol was not
officially released. It was just WIP which vendors picked up from very
early releases. Since they are not numbered, it's hard to have specific
compatibles with different versions until v1.0. That's one of the reason
to retain platform specific compatible so that we can add any quirks
based on them if needed.

I will probably add these information in the commit log so that it's
clear why we can't do version based compatible.



This is exactly my point. By enumerate, I meant having platform
specific compatibles. Having "arm,legacy-scpi" is pointless because
who knows what version they followed and they may all be different.



OK, but IIUC Olof's concern wanted a generic one along with the platform
specific compatible which kind of makes sense as so far we have seen
some commonality between Amlogic and Rockchip.

E.g. Amlogic follows most of the legacy protocol though it deviates in
couple of things which we can handle with platform specific compatible
(in the following patch in the series). When another user(Rockchip ?)
make use of this legacy protocol, we can start using those platform
specific compatible for deviations only.

Is that not acceptable ?


If there's no shared legacy feature set, then it's probably less
useful to have a shared less precise compatible value.



There is and will be some shared feature set for sure. At the least the
standard command set will be shared.


What the main point I was trying to get across was that we shouldn't
expand the generic binding with per-vendor compatible fields, instead
we should have those as extensions on the side.



Yes I get the point. We will have per-vendor compatibles for handle the
deviations but generic one to handle the shared set.


I'm also a little apprehensive of using "legacy", it goes in the same
bucket as "misc". At some point 1.0 will be legacy too, etc.



True and I agree, how about "arm,scpi-pre-1.0" instead ?

--
Regards,
Sudeep

Re: [PATCH v5 00/23] Support qcom's HSIC USB and rewrite USB2 HS support

[Peter Chen]

On Tue, Oct 18, 2016 at 01:51:39PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-18 02:31:40)
> > On Mon, Oct 17, 2016 at 06:56:13PM -0700, Stephen Boyd wrote:
> > > I've also sent separate patches for other minor pieces to make this
> > > all work. The full tree can be found here[2], hacks and all to get
> > > things working. I've tested this on the db410c, apq8074 dragonboard,
> > > and ifc6410 with configfs gadgets and otg cables.
> > > 
> > > Patches based on v4.8-rc1
> 
> Oops should be v4.9-rc1 here.
> 
> > > 
> > > Changes from v4:
> > >  * Picked up Acks from Rob
> > >  * Updated HS phy init sequence DT property to restrict it to offsets
> > 
> > I remembered that you got all my acks for chipidea patches, right? I did
> > not check for this series.
> 
> Sorry I've added in one more patch
> 
>usb: chipidea: Emulate OTGSC interrupt enable path
> 
> to fix extcon interrupt emulation even further.
> 
> > 
> > Besides, the patch "gpu: Remove depends on RESET_CONTROLLER when not a
> > provider" [1]  still not be accepted, I need this patch to be merged
> > first, then apply your chipidea part, otherwise, there is a building
> > warning.
> > 
> > [1] https://patchwork.kernel.org/patch/9322583/
> 
> Yes, I'm going to resend that patch now. I hope that David will apply it
> for -rc2.

Stephen, just a mind. I have rebased Greg's usb-next tree (v4.9-rc3 on
it), your GPU fix is still not there.

-- 

Best Regards,
Peter Chen

Re: [PATCH v5 00/23] Support qcom's HSIC USB and rewrite USB2 HS support

[Peter Chen]

On Tue, Oct 18, 2016 at 01:51:39PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-18 02:31:40)
> > On Mon, Oct 17, 2016 at 06:56:13PM -0700, Stephen Boyd wrote:
> > > I've also sent separate patches for other minor pieces to make this
> > > all work. The full tree can be found here[2], hacks and all to get
> > > things working. I've tested this on the db410c, apq8074 dragonboard,
> > > and ifc6410 with configfs gadgets and otg cables.
> > > 
> > > Patches based on v4.8-rc1
> 
> Oops should be v4.9-rc1 here.
> 
> > > 
> > > Changes from v4:
> > >  * Picked up Acks from Rob
> > >  * Updated HS phy init sequence DT property to restrict it to offsets
> > 
> > I remembered that you got all my acks for chipidea patches, right? I did
> > not check for this series.
> 
> Sorry I've added in one more patch
> 
>usb: chipidea: Emulate OTGSC interrupt enable path
> 
> to fix extcon interrupt emulation even further.
> 
> > 
> > Besides, the patch "gpu: Remove depends on RESET_CONTROLLER when not a
> > provider" [1]  still not be accepted, I need this patch to be merged
> > first, then apply your chipidea part, otherwise, there is a building
> > warning.
> > 
> > [1] https://patchwork.kernel.org/patch/9322583/
> 
> Yes, I'm going to resend that patch now. I hope that David will apply it
> for -rc2.

Stephen, just a mind. I have rebased Greg's usb-next tree (v4.9-rc3 on
it), your GPU fix is still not there.

-- 

Best Regards,
Peter Chen

Re: [patch v5] i2c: mux: mellanox: add driver

[Peter Rosin]

On 2016-11-10 13:56, Vadim Pasternak wrote:
> 
> 
>> -Original Message-
>> From: Peter Rosin [mailto:p...@axentia.se]
>> Sent: Thursday, November 10, 2016 1:13 PM
>> To: Vadim Pasternak ; w...@the-dreams.de
>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; 
>> j...@resnulli.us;
>> Michael Shych 
>> Subject: Re: [patch v5] i2c: mux: mellanox: add driver
>>
>> [resend to all, got the wrong button, sorry]
>>
>> On 2016-11-10 11:42, Peter Rosin wrote:
>>> On 2016-11-03 06:20, Vadim Pasternak wrote:
 Hi,

 I see that this patch has not been picked-up yet for i2c-next.
 Is it possible it was missed from some reason?
>>>
>>> Yes, apparently, really sorry about that!
>>>
>>> I'll put it in a branch and make a pull request for Wolfram (but that
>>> is a bit new for me, we'll see how it goes).
>>
>> But now that I looked again, I noticed that the source is dual licensed and 
>> yet
>> your MODULE_LICENSE tag says only "GPL v2". I.e. the same issue your i2c
>> master driver had that Vladimir Zapolskiy noticed.
>>
>> Please fix this, and it might be a good idea to take a look in your other 
>> drivers as
>> well in case you have further problems in this department...
> 
> Hi Peter,
> 
> Thank you for reply. 
> I'll re-submit it from the current i2c next branch.
> Since I'll fix the license, I guess I should issue it as "patch v6". Right?

Sounds right, yes.

Cheers,
Peter

Re: [patch v5] i2c: mux: mellanox: add driver

[Peter Rosin]

On 2016-11-10 13:56, Vadim Pasternak wrote:
> 
> 
>> -Original Message-
>> From: Peter Rosin [mailto:p...@axentia.se]
>> Sent: Thursday, November 10, 2016 1:13 PM
>> To: Vadim Pasternak ; w...@the-dreams.de
>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; 
>> j...@resnulli.us;
>> Michael Shych 
>> Subject: Re: [patch v5] i2c: mux: mellanox: add driver
>>
>> [resend to all, got the wrong button, sorry]
>>
>> On 2016-11-10 11:42, Peter Rosin wrote:
>>> On 2016-11-03 06:20, Vadim Pasternak wrote:
 Hi,

 I see that this patch has not been picked-up yet for i2c-next.
 Is it possible it was missed from some reason?
>>>
>>> Yes, apparently, really sorry about that!
>>>
>>> I'll put it in a branch and make a pull request for Wolfram (but that
>>> is a bit new for me, we'll see how it goes).
>>
>> But now that I looked again, I noticed that the source is dual licensed and 
>> yet
>> your MODULE_LICENSE tag says only "GPL v2". I.e. the same issue your i2c
>> master driver had that Vladimir Zapolskiy noticed.
>>
>> Please fix this, and it might be a good idea to take a look in your other 
>> drivers as
>> well in case you have further problems in this department...
> 
> Hi Peter,
> 
> Thank you for reply. 
> I'll re-submit it from the current i2c next branch.
> Since I'll fix the license, I guess I should issue it as "patch v6". Right?

Sounds right, yes.

Cheers,
Peter

Re: [PATCH v3 05/46] perf/x86/intel/cmt: add per-package locks

[Ingo Molnar]

* Peter Zijlstra  wrote:

> On Thu, Nov 10, 2016 at 06:22:17PM -0800, David Carrillo-Cisneros wrote:
> > A possible alternative to nested spinlocks is to use a single rw_lock to
> > protect changes to the monr hierarchy.
> > 
> > This works because, when manipulating pmonrs, the monr hierarchy (monr's
> > parent and children) is read but never changed (reader path).
> > Changes to the monr hierarchy do change pmonrs (writer path).
> > 
> > It would be implemented like:
> > 
> >   // system-wide lock for monr hierarchy
> >   rwlock_t monr_hrchy_rwlock = __RW_LOCK_UNLOCKED(monr_hrchy_rwlock);
> > 
> > 
> > Reader Path: Access pmonrs in same pkgd. Used in pmonr state transitions
> > and when reading cgroups (read subtree of pmonrs in same package):
> > 
> > v3 (old):
> > 
> >   raw_spin_lock(>lock);
> >   // read monr data, read/write pmonr data
> >   raw_spin_unlock(>lock);
> > 
> > next version:
> > 
> >   read_lock(_hrchy_rwlock);
> >   raw_spin_lock(>lock);
> >   // read monr data, read/write pmonr data
> >   raw_spin_unlock(>lock);
> >   read_unlock(_hrchy_rwlock);
> > 
> > 
> > Writer Path: Modifies monr hierarchy (add/remove monr in
> > creation/destruction of events and start/stop monitoring
> > of cgroups):
> > 
> > v3 (old):
> > 
> >   monr_hrchy_acquire_locks(...); // acquires all pkg->lock
> >   // read/write monr data, potentially read/write pmonr data
> >   monr_hrchy_release_locks(...); // release all pkg->lock
> > 
> > v4:
> > 
> >   write_lock(_hrchy_rwlock);
> >   // read/write monr data, potentially read/write pmonr data
> >   write_unlock(_hrchy_rwlock);
> > 
> > 
> > The write-path should occur infrequently. The reader-path
> > is slower due to the additional read_lock(_hrchy_rwlock).
> > The number of locks to acquire remains constant on the number of
> > packages in both paths. There would be no need to ever nest pkgd->lock's.
> > 
> > For v3, I discarded this idea because, due to the additional
> > read_lock(_hrchy_rwlock), the pmonr state transitions that may
> > occur in a context switch would be slower than in the current version.
> > But it may be ultimately better considering the scalability issues
> > that you mention.
> 
> Well, its very hard to suggest alternatives, because there simply isn't
> anything of content here. This patch just adds locks, and the next few
> patches don't describe much either.
> 
> Why can't this be RCU?
> 
> Also, "monr" is a horribly 'word'.

And 'hrchy' is a hrbbl wrd as wll!

Thanks,

Ingo

Re: [PATCH v3 05/46] perf/x86/intel/cmt: add per-package locks

[Ingo Molnar]

* Peter Zijlstra  wrote:

> On Thu, Nov 10, 2016 at 06:22:17PM -0800, David Carrillo-Cisneros wrote:
> > A possible alternative to nested spinlocks is to use a single rw_lock to
> > protect changes to the monr hierarchy.
> > 
> > This works because, when manipulating pmonrs, the monr hierarchy (monr's
> > parent and children) is read but never changed (reader path).
> > Changes to the monr hierarchy do change pmonrs (writer path).
> > 
> > It would be implemented like:
> > 
> >   // system-wide lock for monr hierarchy
> >   rwlock_t monr_hrchy_rwlock = __RW_LOCK_UNLOCKED(monr_hrchy_rwlock);
> > 
> > 
> > Reader Path: Access pmonrs in same pkgd. Used in pmonr state transitions
> > and when reading cgroups (read subtree of pmonrs in same package):
> > 
> > v3 (old):
> > 
> >   raw_spin_lock(>lock);
> >   // read monr data, read/write pmonr data
> >   raw_spin_unlock(>lock);
> > 
> > next version:
> > 
> >   read_lock(_hrchy_rwlock);
> >   raw_spin_lock(>lock);
> >   // read monr data, read/write pmonr data
> >   raw_spin_unlock(>lock);
> >   read_unlock(_hrchy_rwlock);
> > 
> > 
> > Writer Path: Modifies monr hierarchy (add/remove monr in
> > creation/destruction of events and start/stop monitoring
> > of cgroups):
> > 
> > v3 (old):
> > 
> >   monr_hrchy_acquire_locks(...); // acquires all pkg->lock
> >   // read/write monr data, potentially read/write pmonr data
> >   monr_hrchy_release_locks(...); // release all pkg->lock
> > 
> > v4:
> > 
> >   write_lock(_hrchy_rwlock);
> >   // read/write monr data, potentially read/write pmonr data
> >   write_unlock(_hrchy_rwlock);
> > 
> > 
> > The write-path should occur infrequently. The reader-path
> > is slower due to the additional read_lock(_hrchy_rwlock).
> > The number of locks to acquire remains constant on the number of
> > packages in both paths. There would be no need to ever nest pkgd->lock's.
> > 
> > For v3, I discarded this idea because, due to the additional
> > read_lock(_hrchy_rwlock), the pmonr state transitions that may
> > occur in a context switch would be slower than in the current version.
> > But it may be ultimately better considering the scalability issues
> > that you mention.
> 
> Well, its very hard to suggest alternatives, because there simply isn't
> anything of content here. This patch just adds locks, and the next few
> patches don't describe much either.
> 
> Why can't this be RCU?
> 
> Also, "monr" is a horribly 'word'.

And 'hrchy' is a hrbbl wrd as wll!

Thanks,

Ingo

Re: [PATCH v3 05/46] perf/x86/intel/cmt: add per-package locks

[Peter Zijlstra]

On Thu, Nov 10, 2016 at 06:22:17PM -0800, David Carrillo-Cisneros wrote:
> A possible alternative to nested spinlocks is to use a single rw_lock to
> protect changes to the monr hierarchy.
> 
> This works because, when manipulating pmonrs, the monr hierarchy (monr's
> parent and children) is read but never changed (reader path).
> Changes to the monr hierarchy do change pmonrs (writer path).
> 
> It would be implemented like:
> 
>   // system-wide lock for monr hierarchy
>   rwlock_t monr_hrchy_rwlock = __RW_LOCK_UNLOCKED(monr_hrchy_rwlock);
> 
> 
> Reader Path: Access pmonrs in same pkgd. Used in pmonr state transitions
> and when reading cgroups (read subtree of pmonrs in same package):
> 
> v3 (old):
> 
>   raw_spin_lock(>lock);
>   // read monr data, read/write pmonr data
>   raw_spin_unlock(>lock);
> 
> next version:
> 
>   read_lock(_hrchy_rwlock);
>   raw_spin_lock(>lock);
>   // read monr data, read/write pmonr data
>   raw_spin_unlock(>lock);
>   read_unlock(_hrchy_rwlock);
> 
> 
> Writer Path: Modifies monr hierarchy (add/remove monr in
> creation/destruction of events and start/stop monitoring
> of cgroups):
> 
> v3 (old):
> 
>   monr_hrchy_acquire_locks(...); // acquires all pkg->lock
>   // read/write monr data, potentially read/write pmonr data
>   monr_hrchy_release_locks(...); // release all pkg->lock
> 
> v4:
> 
>   write_lock(_hrchy_rwlock);
>   // read/write monr data, potentially read/write pmonr data
>   write_unlock(_hrchy_rwlock);
> 
> 
> The write-path should occur infrequently. The reader-path
> is slower due to the additional read_lock(_hrchy_rwlock).
> The number of locks to acquire remains constant on the number of
> packages in both paths. There would be no need to ever nest pkgd->lock's.
> 
> For v3, I discarded this idea because, due to the additional
> read_lock(_hrchy_rwlock), the pmonr state transitions that may
> occur in a context switch would be slower than in the current version.
> But it may be ultimately better considering the scalability issues
> that you mention.

Well, its very hard to suggest alternatives, because there simply isn't
anything of content here. This patch just adds locks, and the next few
patches don't describe much either.

Why can't this be RCU?

Also, "monr" is a horribly 'word'.

Re: [PATCH v3 05/46] perf/x86/intel/cmt: add per-package locks

[Peter Zijlstra]

On Thu, Nov 10, 2016 at 06:22:17PM -0800, David Carrillo-Cisneros wrote:
> A possible alternative to nested spinlocks is to use a single rw_lock to
> protect changes to the monr hierarchy.
> 
> This works because, when manipulating pmonrs, the monr hierarchy (monr's
> parent and children) is read but never changed (reader path).
> Changes to the monr hierarchy do change pmonrs (writer path).
> 
> It would be implemented like:
> 
>   // system-wide lock for monr hierarchy
>   rwlock_t monr_hrchy_rwlock = __RW_LOCK_UNLOCKED(monr_hrchy_rwlock);
> 
> 
> Reader Path: Access pmonrs in same pkgd. Used in pmonr state transitions
> and when reading cgroups (read subtree of pmonrs in same package):
> 
> v3 (old):
> 
>   raw_spin_lock(>lock);
>   // read monr data, read/write pmonr data
>   raw_spin_unlock(>lock);
> 
> next version:
> 
>   read_lock(_hrchy_rwlock);
>   raw_spin_lock(>lock);
>   // read monr data, read/write pmonr data
>   raw_spin_unlock(>lock);
>   read_unlock(_hrchy_rwlock);
> 
> 
> Writer Path: Modifies monr hierarchy (add/remove monr in
> creation/destruction of events and start/stop monitoring
> of cgroups):
> 
> v3 (old):
> 
>   monr_hrchy_acquire_locks(...); // acquires all pkg->lock
>   // read/write monr data, potentially read/write pmonr data
>   monr_hrchy_release_locks(...); // release all pkg->lock
> 
> v4:
> 
>   write_lock(_hrchy_rwlock);
>   // read/write monr data, potentially read/write pmonr data
>   write_unlock(_hrchy_rwlock);
> 
> 
> The write-path should occur infrequently. The reader-path
> is slower due to the additional read_lock(_hrchy_rwlock).
> The number of locks to acquire remains constant on the number of
> packages in both paths. There would be no need to ever nest pkgd->lock's.
> 
> For v3, I discarded this idea because, due to the additional
> read_lock(_hrchy_rwlock), the pmonr state transitions that may
> occur in a context switch would be slower than in the current version.
> But it may be ultimately better considering the scalability issues
> that you mention.

Well, its very hard to suggest alternatives, because there simply isn't
anything of content here. This patch just adds locks, and the next few
patches don't describe much either.

Why can't this be RCU?

Also, "monr" is a horribly 'word'.

Re: question about clk_get_parent

[Julia Lawall]

On Thu, 10 Nov 2016, Russell King - ARM Linux wrote:

> On Thu, Nov 10, 2016 at 09:55:16PM +0100, Julia Lawall wrote:
> > As far as I can see in the various definitions of clk_get_parent, they all
> > return either NULL or a value stored in a structure field.  But the
> > documentation with the prototype in includ/linux/clk.h says that it
> > returns a valid IS_ERR() condition containing errno.  Are ERR_PTR values
> > stored in the structure fields?
>
> The API documentation (in clk.h) is correct.  The API (from the user
> perspective) considers invalid clocks to be the set of pointers for
> which IS_ERR() is true.
>
> By implication, valid clocks are those for which IS_ERR() returns
> false.
>
> Hence, in order for clk_get_parent() to indicate an error, it has to
> return a pointer value which corresponds with IS_ERR() being true.
>
> The question over the NULL clock pointer is left to the implementation
> to decide whether it's an error or not as far as the API design goes,
> but practically everyone treats it as "there is no clock" which is
> entirely reasonable.
>
> Also, remember from the clk API design point of view, users of the
> API should never dereference the clk pointer, it is a cookie as far
> as users should be concerned. (The clk structure was not available to
> drivers in the early days.)  Only clk implementations and clk drivers
> should dereference, and these should not dereference anything but
> their own clocks.

Thanks for the explanation, but I'm not sure how to relate it to what is
in the code.  For example, in drivers/clk/clk.c, there is:

{
struct clk *parent;

if (!clk)
return NULL;

clk_prepare_lock();
/* TODO: Create a per-user clk and change callers to call clk_put */
parent = !clk->core->parent ? NULL : clk->core->parent->hw->clk;
clk_prepare_unlock();

return parent;
}

Could clk->core->parent->hw->clk return an ERR_PTR value?  Or is the point
that from the clock point of view, this definition never fails?

thanks,
julia

>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
>

Re: question about clk_get_parent

[Julia Lawall]

On Thu, 10 Nov 2016, Russell King - ARM Linux wrote:

> On Thu, Nov 10, 2016 at 09:55:16PM +0100, Julia Lawall wrote:
> > As far as I can see in the various definitions of clk_get_parent, they all
> > return either NULL or a value stored in a structure field.  But the
> > documentation with the prototype in includ/linux/clk.h says that it
> > returns a valid IS_ERR() condition containing errno.  Are ERR_PTR values
> > stored in the structure fields?
>
> The API documentation (in clk.h) is correct.  The API (from the user
> perspective) considers invalid clocks to be the set of pointers for
> which IS_ERR() is true.
>
> By implication, valid clocks are those for which IS_ERR() returns
> false.
>
> Hence, in order for clk_get_parent() to indicate an error, it has to
> return a pointer value which corresponds with IS_ERR() being true.
>
> The question over the NULL clock pointer is left to the implementation
> to decide whether it's an error or not as far as the API design goes,
> but practically everyone treats it as "there is no clock" which is
> entirely reasonable.
>
> Also, remember from the clk API design point of view, users of the
> API should never dereference the clk pointer, it is a cookie as far
> as users should be concerned. (The clk structure was not available to
> drivers in the early days.)  Only clk implementations and clk drivers
> should dereference, and these should not dereference anything but
> their own clocks.

Thanks for the explanation, but I'm not sure how to relate it to what is
in the code.  For example, in drivers/clk/clk.c, there is:

{
struct clk *parent;

if (!clk)
return NULL;

clk_prepare_lock();
/* TODO: Create a per-user clk and change callers to call clk_put */
parent = !clk->core->parent ? NULL : clk->core->parent->hw->clk;
clk_prepare_unlock();

return parent;
}

Could clk->core->parent->hw->clk return an ERR_PTR value?  Or is the point
that from the clock point of view, this definition never fails?

thanks,
julia

>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
>

[PATCH net 0/2] r8152: rx patches

[Hayes Wang]

Let the rx sw checksum available and add some checks for rx desc.

Hayes Wang (2):
  r8152: fix the sw rx checksum is unavailable
  r8152: rx descriptor check

 drivers/net/usb/r8152.c | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

-- 
2.7.4

[PATCH net 0/2] r8152: rx patches

[Hayes Wang]

Let the rx sw checksum available and add some checks for rx desc.

Hayes Wang (2):
  r8152: fix the sw rx checksum is unavailable
  r8152: rx descriptor check

 drivers/net/usb/r8152.c | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

-- 
2.7.4

[PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

[Hayes Wang]

Fix the hw rx checksum is always enabled, and the user couldn't switch
it to sw rx checksum.

Note that the RTL_VER_01 only supports sw rx checksum only. Besides,
the hw rx checksum for RTL_VER_02 is disabled after
commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 75c5168..0e42a78 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1730,7 +1730,7 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc 
*rx_desc)
u8 checksum = CHECKSUM_NONE;
u32 opts2, opts3;
 
-   if (tp->version == RTL_VER_01 || tp->version == RTL_VER_02)
+   if (!(tp->netdev->features & NETIF_F_RXCSUM))
goto return_result;
 
opts2 = le32_to_cpu(rx_desc->opts2);
@@ -4307,6 +4307,11 @@ static int rtl8152_probe(struct usb_interface *intf,
NETIF_F_HIGHDMA | NETIF_F_FRAGLIST |
NETIF_F_IPV6_CSUM | NETIF_F_TSO6;
 
+   if (tp->version == RTL_VER_01) {
+   netdev->features &= ~NETIF_F_RXCSUM;
+   netdev->hw_features &= ~NETIF_F_RXCSUM;
+   }
+
netdev->ethtool_ops = 
netif_set_gso_max_size(netdev, RTL_LIMITED_TSO_SIZE);
 
-- 
2.7.4

[PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

[Hayes Wang]

Fix the hw rx checksum is always enabled, and the user couldn't switch
it to sw rx checksum.

Note that the RTL_VER_01 only supports sw rx checksum only. Besides,
the hw rx checksum for RTL_VER_02 is disabled after
commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 75c5168..0e42a78 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1730,7 +1730,7 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc 
*rx_desc)
u8 checksum = CHECKSUM_NONE;
u32 opts2, opts3;
 
-   if (tp->version == RTL_VER_01 || tp->version == RTL_VER_02)
+   if (!(tp->netdev->features & NETIF_F_RXCSUM))
goto return_result;
 
opts2 = le32_to_cpu(rx_desc->opts2);
@@ -4307,6 +4307,11 @@ static int rtl8152_probe(struct usb_interface *intf,
NETIF_F_HIGHDMA | NETIF_F_FRAGLIST |
NETIF_F_IPV6_CSUM | NETIF_F_TSO6;
 
+   if (tp->version == RTL_VER_01) {
+   netdev->features &= ~NETIF_F_RXCSUM;
+   netdev->hw_features &= ~NETIF_F_RXCSUM;
+   }
+
netdev->ethtool_ops = 
netif_set_gso_max_size(netdev, RTL_LIMITED_TSO_SIZE);
 
-- 
2.7.4

[PATCH net 2/2] r8152: rx descriptor check

[Hayes Wang]

For some platforms, the data in memory is not the same with the one
from the device. That is, the data of memory is unbelievable. The
check is used to find out this situation.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 49 +
 1 file changed, 49 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0e42a78..e766121 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1756,6 +1756,43 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc 
*rx_desc)
return checksum;
 }
 
+static int invalid_rx_desc(struct r8152 *tp, struct rx_desc *rx_desc)
+{
+   u32 opts1 = le32_to_cpu(rx_desc->opts1);
+   u32 opts2 = le32_to_cpu(rx_desc->opts2);
+   unsigned int pkt_len = opts1 & RX_LEN_MASK;
+
+   switch (tp->version) {
+   case RTL_VER_01:
+   case RTL_VER_02:
+   if (pkt_len > RTL8152_RMS)
+   return -EIO;
+   break;
+   default:
+   if (pkt_len > RTL8153_RMS)
+   return -EIO;
+   break;
+   }
+
+   switch (opts2 & (RD_IPV4_CS | RD_IPV6_CS)) {
+   case (RD_IPV4_CS | RD_IPV6_CS):
+   return -EIO;
+   case RD_IPV4_CS:
+   case RD_IPV6_CS:
+   switch (opts2 & (RD_UDP_CS | RD_TCP_CS)) {
+   case (RD_UDP_CS | RD_TCP_CS):
+   return -EIO;
+   default:
+   break;
+   }
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
 static int rx_bottom(struct r8152 *tp, int budget)
 {
unsigned long flags;
@@ -1812,6 +1849,18 @@ static int rx_bottom(struct r8152 *tp, int budget)
unsigned int pkt_len;
struct sk_buff *skb;
 
+   if (unlikely(invalid_rx_desc(tp, rx_desc))) {
+   if (net_ratelimit())
+   netif_err(tp, rx_err, netdev,
+ "Memory unbelievable\n");
+   if (tp->netdev->features & NETIF_F_RXCSUM) {
+   tp->netdev->features &= ~NETIF_F_RXCSUM;
+   netif_err(tp, rx_err, netdev,
+ "rx checksum off\n");
+   }
+   break;
+   }
+
pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
if (pkt_len < ETH_ZLEN)
break;
-- 
2.7.4

[PATCH net 2/2] r8152: rx descriptor check

[Hayes Wang]

For some platforms, the data in memory is not the same with the one
from the device. That is, the data of memory is unbelievable. The
check is used to find out this situation.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 49 +
 1 file changed, 49 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0e42a78..e766121 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1756,6 +1756,43 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc 
*rx_desc)
return checksum;
 }
 
+static int invalid_rx_desc(struct r8152 *tp, struct rx_desc *rx_desc)
+{
+   u32 opts1 = le32_to_cpu(rx_desc->opts1);
+   u32 opts2 = le32_to_cpu(rx_desc->opts2);
+   unsigned int pkt_len = opts1 & RX_LEN_MASK;
+
+   switch (tp->version) {
+   case RTL_VER_01:
+   case RTL_VER_02:
+   if (pkt_len > RTL8152_RMS)
+   return -EIO;
+   break;
+   default:
+   if (pkt_len > RTL8153_RMS)
+   return -EIO;
+   break;
+   }
+
+   switch (opts2 & (RD_IPV4_CS | RD_IPV6_CS)) {
+   case (RD_IPV4_CS | RD_IPV6_CS):
+   return -EIO;
+   case RD_IPV4_CS:
+   case RD_IPV6_CS:
+   switch (opts2 & (RD_UDP_CS | RD_TCP_CS)) {
+   case (RD_UDP_CS | RD_TCP_CS):
+   return -EIO;
+   default:
+   break;
+   }
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
 static int rx_bottom(struct r8152 *tp, int budget)
 {
unsigned long flags;
@@ -1812,6 +1849,18 @@ static int rx_bottom(struct r8152 *tp, int budget)
unsigned int pkt_len;
struct sk_buff *skb;
 
+   if (unlikely(invalid_rx_desc(tp, rx_desc))) {
+   if (net_ratelimit())
+   netif_err(tp, rx_err, netdev,
+ "Memory unbelievable\n");
+   if (tp->netdev->features & NETIF_F_RXCSUM) {
+   tp->netdev->features &= ~NETIF_F_RXCSUM;
+   netif_err(tp, rx_err, netdev,
+ "rx checksum off\n");
+   }
+   break;
+   }
+
pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
if (pkt_len < ETH_ZLEN)
break;
-- 
2.7.4

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Joonsoo Kim]

On Tue, Nov 08, 2016 at 02:59:19PM +0800, Chen Feng wrote:
> 
> 
> On 2016/11/8 11:59, Joonsoo Kim wrote:
> > On Mon, Nov 07, 2016 at 03:46:02PM +0800, Chen Feng wrote:
> >>
> >>
> >> On 2016/11/7 15:44, Chen Feng wrote:
> >>> On 2016/11/7 15:27, Joonsoo Kim wrote:
>  On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote:
> >
> >
> > On 2016/11/7 14:15, Joonsoo Kim wrote:
> >> On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
> >>> Hello, I hava a question on cma zone.
> >>>
> >>> When we have cma zone, cma zone will be the highest zone of system.
> >>>
> >>> In android system, the most memory allocator is ION. Media system will
> >>> alloc unmovable memory from it.
> >>>
> >>> On low memory scene, will the CMA zone always do balance?
> >>
> >> Allocation request for low zone (normal zone) would not cause CMA zone
> >> to be balanced since it isn't helpful.
> >>
> > Yes. But the cma zone will run out soon. And it always need to do 
> > balance.
> >
> > How about use migrate cma before movable and let cma type to fallback 
> > movable.
> >
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html
> 
>  ZONE_CMA approach will act like as your solution. Could you elaborate
>  more on the problem of zone approach?
> 
> >>>
> >>> The ZONE approach is that makes cma pages in a zone. It can cause a 
> >>> higher swapin/out
> >>> than use migrate cma first.
> > 
> > Interesting result. I should look at it more deeply. Could you explain
> > me why the ZONE approach causes a higher swapin/out?
> > 
> The result is that. I don't have a obvious reason. Maybe add a zone, need to 
> do more balance
> to keep the watermark of cma-zone. cma-zone is always used firstly. Since the 
> test-case
> alloced the same memory in total.

Please do more analysis.
Without the correct analysis, the result doesn't have any meaning. We
can't make sure that it is always better than the other. IMHO, number
is important but more important thing is a theory. Number is just
auxiliary method to prove the theory.

> 
> >>>
> >>> The higher swapin/out may have a performance effect to application. The 
> >>> application may
> >>> use too much time swapin memory.
> >>>
> >>> You can see my tested result attached for detail. And the baseline is 
> >>> result of [1].
> >>>
> >>>
> >> My test case is run 60 applications and alloc 512MB ION memory.
> >>
> >> Repeat this action 50 times
> > 
> > Could you tell me more detail about your test?
> > Kernel version? Total Memory? Total CMA Memory? Android system? What
> > type of memory does ION uses? Other statistics? Etc...
> 
> Tested on 4.1, android 7, 512MB-cma in 4G memory.
> ION use normal unmovable memory, I use it to simulate a camera open operator.

Okay. Kernel version would be the one of the reasons.

On 4.1, there is a fair zone allocator so behaviour of ZONE_CMA is
different with movable first policy. Allocation would be interleaving
between zones. It has pros and cons. The fair zone allocator is
removed in the recent kernel so please test with it on the recent
kernel for apple to apple comparison.

> > 
> > If it tested on the Android, I'm not sure that we need to consider
> > it's result. Android has a lowmemory killer which is quitely different
> > with normal reclaim behaviour.
> Why?

Lowmemory killer don't keep LRU ordering of the page. It uses LRU
ordering of the app and kill the app to reclaim the mermory. It makes
reclaim behaviour quiet different with original one. And, it largely
depends on userspace setting so we can't take care about it.

Thanks.

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Joonsoo Kim]

On Tue, Nov 08, 2016 at 02:59:19PM +0800, Chen Feng wrote:
> 
> 
> On 2016/11/8 11:59, Joonsoo Kim wrote:
> > On Mon, Nov 07, 2016 at 03:46:02PM +0800, Chen Feng wrote:
> >>
> >>
> >> On 2016/11/7 15:44, Chen Feng wrote:
> >>> On 2016/11/7 15:27, Joonsoo Kim wrote:
>  On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote:
> >
> >
> > On 2016/11/7 14:15, Joonsoo Kim wrote:
> >> On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
> >>> Hello, I hava a question on cma zone.
> >>>
> >>> When we have cma zone, cma zone will be the highest zone of system.
> >>>
> >>> In android system, the most memory allocator is ION. Media system will
> >>> alloc unmovable memory from it.
> >>>
> >>> On low memory scene, will the CMA zone always do balance?
> >>
> >> Allocation request for low zone (normal zone) would not cause CMA zone
> >> to be balanced since it isn't helpful.
> >>
> > Yes. But the cma zone will run out soon. And it always need to do 
> > balance.
> >
> > How about use migrate cma before movable and let cma type to fallback 
> > movable.
> >
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html
> 
>  ZONE_CMA approach will act like as your solution. Could you elaborate
>  more on the problem of zone approach?
> 
> >>>
> >>> The ZONE approach is that makes cma pages in a zone. It can cause a 
> >>> higher swapin/out
> >>> than use migrate cma first.
> > 
> > Interesting result. I should look at it more deeply. Could you explain
> > me why the ZONE approach causes a higher swapin/out?
> > 
> The result is that. I don't have a obvious reason. Maybe add a zone, need to 
> do more balance
> to keep the watermark of cma-zone. cma-zone is always used firstly. Since the 
> test-case
> alloced the same memory in total.

Please do more analysis.
Without the correct analysis, the result doesn't have any meaning. We
can't make sure that it is always better than the other. IMHO, number
is important but more important thing is a theory. Number is just
auxiliary method to prove the theory.

> 
> >>>
> >>> The higher swapin/out may have a performance effect to application. The 
> >>> application may
> >>> use too much time swapin memory.
> >>>
> >>> You can see my tested result attached for detail. And the baseline is 
> >>> result of [1].
> >>>
> >>>
> >> My test case is run 60 applications and alloc 512MB ION memory.
> >>
> >> Repeat this action 50 times
> > 
> > Could you tell me more detail about your test?
> > Kernel version? Total Memory? Total CMA Memory? Android system? What
> > type of memory does ION uses? Other statistics? Etc...
> 
> Tested on 4.1, android 7, 512MB-cma in 4G memory.
> ION use normal unmovable memory, I use it to simulate a camera open operator.

Okay. Kernel version would be the one of the reasons.

On 4.1, there is a fair zone allocator so behaviour of ZONE_CMA is
different with movable first policy. Allocation would be interleaving
between zones. It has pros and cons. The fair zone allocator is
removed in the recent kernel so please test with it on the recent
kernel for apple to apple comparison.

> > 
> > If it tested on the Android, I'm not sure that we need to consider
> > it's result. Android has a lowmemory killer which is quitely different
> > with normal reclaim behaviour.
> Why?

Lowmemory killer don't keep LRU ordering of the page. It uses LRU
ordering of the app and kill the app to reclaim the mermory. It makes
reclaim behaviour quiet different with original one. And, it largely
depends on userspace setting so we can't take care about it.

Thanks.

[PATCH 2/2] staging: iio: ad7606: move out of staging

[Eva Rachel Retuya]

Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the
corresponding Makefile and Kconfig associated with the change.

Signed-off-by: Eva Rachel Retuya 
---
 drivers/iio/adc/Kconfig  |  34 +++
 drivers/iio/adc/Makefile |   3 +
 drivers/iio/adc/ad7606.c | 519 +++
 drivers/iio/adc/ad7606.h |  78 ++
 drivers/iio/adc/ad7606_par.c | 112 
 drivers/iio/adc/ad7606_spi.c |  78 ++
 drivers/staging/iio/adc/Kconfig  |  34 ---
 drivers/staging/iio/adc/Makefile |   4 -
 drivers/staging/iio/adc/ad7606.c | 519 ---
 drivers/staging/iio/adc/ad7606.h |  78 --
 drivers/staging/iio/adc/ad7606_par.c | 112 
 drivers/staging/iio/adc/ad7606_spi.c |  78 --
 12 files changed, 824 insertions(+), 825 deletions(-)
 create mode 100644 drivers/iio/adc/ad7606.c
 create mode 100644 drivers/iio/adc/ad7606.h
 create mode 100644 drivers/iio/adc/ad7606_par.c
 create mode 100644 drivers/iio/adc/ad7606_spi.c
 delete mode 100644 drivers/staging/iio/adc/ad7606.c
 delete mode 100644 drivers/staging/iio/adc/ad7606.h
 delete mode 100644 drivers/staging/iio/adc/ad7606_par.c
 delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index c3fe98d..742db8f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -58,6 +58,40 @@ config AD7476
  To compile this driver as a module, choose M here: the
  module will be called ad7476.
 
+config AD7606
+   tristate "Analog Devices AD7606 ADC driver"
+   depends on GPIOLIB || COMPILE_TEST
+   depends on HAS_IOMEM
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   help
+ Say yes here to build support for Analog Devices:
+ ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC).
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606.
+
+config AD7606_IFACE_PARALLEL
+   tristate "parallel interface support"
+   depends on AD7606
+   help
+ Say yes here to include parallel interface support on the AD7606
+ ADC driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606_parallel.
+
+config AD7606_IFACE_SPI
+   tristate "spi interface support"
+   depends on AD7606
+   depends on SPI
+   help
+ Say yes here to include parallel interface support on the AD7606
+ ADC driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606_spi.
+
 config AD7766
tristate "Analog Devices AD7766/AD7767 ADC driver"
depends on SPI_MASTER
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 96894b3..d06d3a9 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -9,6 +9,9 @@ obj-$(CONFIG_AD7291) += ad7291.o
 obj-$(CONFIG_AD7298) += ad7298.o
 obj-$(CONFIG_AD7923) += ad7923.o
 obj-$(CONFIG_AD7476) += ad7476.o
+obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o
+obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o
+obj-$(CONFIG_AD7606) += ad7606.o
 obj-$(CONFIG_AD7766) += ad7766.o
 obj-$(CONFIG_AD7791) += ad7791.o
 obj-$(CONFIG_AD7793) += ad7793.o
diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
new file mode 100644
index 000..cceb18c
--- /dev/null
+++ b/drivers/iio/adc/ad7606.c
@@ -0,0 +1,519 @@
+/*
+ * AD7606 SPI ADC driver
+ *
+ * Copyright 2011 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ad7606.h"
+
+static int ad7606_reset(struct ad7606_state *st)
+{
+   if (st->gpio_reset) {
+   gpiod_set_value(st->gpio_reset, 1);
+   ndelay(100); /* t_reset >= 100ns */
+   gpiod_set_value(st->gpio_reset, 0);
+   return 0;
+   }
+
+   return -ENODEV;
+}
+
+static int ad7606_read_samples(struct ad7606_state *st)
+{
+   unsigned int num = st->chip_info->num_channels;
+   u16 *data = st->data;
+   int ret;
+
+   /*
+* The frstdata signal is set to high while and after reading the sample
+* of the first channel and low for all other channels. This can be used
+* to check that the incoming data is correctly aligned. During normal
+* operation the data should never become unaligned, but some glitch or
+* electrostatic discharge might cause an extra read or clock cycle.
+* Monitoring the frstdata signal allows to recover from such failure
+* situations.
+*/
+
+   if (st->gpio_frstdata) {
+   ret = st->bops->read_block(st->dev, 1, data);
+   if (ret)
+  

[PATCH 2/2] staging: iio: ad7606: move out of staging

[Eva Rachel Retuya]

Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the
corresponding Makefile and Kconfig associated with the change.

Signed-off-by: Eva Rachel Retuya 
---
 drivers/iio/adc/Kconfig  |  34 +++
 drivers/iio/adc/Makefile |   3 +
 drivers/iio/adc/ad7606.c | 519 +++
 drivers/iio/adc/ad7606.h |  78 ++
 drivers/iio/adc/ad7606_par.c | 112 
 drivers/iio/adc/ad7606_spi.c |  78 ++
 drivers/staging/iio/adc/Kconfig  |  34 ---
 drivers/staging/iio/adc/Makefile |   4 -
 drivers/staging/iio/adc/ad7606.c | 519 ---
 drivers/staging/iio/adc/ad7606.h |  78 --
 drivers/staging/iio/adc/ad7606_par.c | 112 
 drivers/staging/iio/adc/ad7606_spi.c |  78 --
 12 files changed, 824 insertions(+), 825 deletions(-)
 create mode 100644 drivers/iio/adc/ad7606.c
 create mode 100644 drivers/iio/adc/ad7606.h
 create mode 100644 drivers/iio/adc/ad7606_par.c
 create mode 100644 drivers/iio/adc/ad7606_spi.c
 delete mode 100644 drivers/staging/iio/adc/ad7606.c
 delete mode 100644 drivers/staging/iio/adc/ad7606.h
 delete mode 100644 drivers/staging/iio/adc/ad7606_par.c
 delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index c3fe98d..742db8f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -58,6 +58,40 @@ config AD7476
  To compile this driver as a module, choose M here: the
  module will be called ad7476.
 
+config AD7606
+   tristate "Analog Devices AD7606 ADC driver"
+   depends on GPIOLIB || COMPILE_TEST
+   depends on HAS_IOMEM
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   help
+ Say yes here to build support for Analog Devices:
+ ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC).
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606.
+
+config AD7606_IFACE_PARALLEL
+   tristate "parallel interface support"
+   depends on AD7606
+   help
+ Say yes here to include parallel interface support on the AD7606
+ ADC driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606_parallel.
+
+config AD7606_IFACE_SPI
+   tristate "spi interface support"
+   depends on AD7606
+   depends on SPI
+   help
+ Say yes here to include parallel interface support on the AD7606
+ ADC driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606_spi.
+
 config AD7766
tristate "Analog Devices AD7766/AD7767 ADC driver"
depends on SPI_MASTER
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 96894b3..d06d3a9 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -9,6 +9,9 @@ obj-$(CONFIG_AD7291) += ad7291.o
 obj-$(CONFIG_AD7298) += ad7298.o
 obj-$(CONFIG_AD7923) += ad7923.o
 obj-$(CONFIG_AD7476) += ad7476.o
+obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o
+obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o
+obj-$(CONFIG_AD7606) += ad7606.o
 obj-$(CONFIG_AD7766) += ad7766.o
 obj-$(CONFIG_AD7791) += ad7791.o
 obj-$(CONFIG_AD7793) += ad7793.o
diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
new file mode 100644
index 000..cceb18c
--- /dev/null
+++ b/drivers/iio/adc/ad7606.c
@@ -0,0 +1,519 @@
+/*
+ * AD7606 SPI ADC driver
+ *
+ * Copyright 2011 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ad7606.h"
+
+static int ad7606_reset(struct ad7606_state *st)
+{
+   if (st->gpio_reset) {
+   gpiod_set_value(st->gpio_reset, 1);
+   ndelay(100); /* t_reset >= 100ns */
+   gpiod_set_value(st->gpio_reset, 0);
+   return 0;
+   }
+
+   return -ENODEV;
+}
+
+static int ad7606_read_samples(struct ad7606_state *st)
+{
+   unsigned int num = st->chip_info->num_channels;
+   u16 *data = st->data;
+   int ret;
+
+   /*
+* The frstdata signal is set to high while and after reading the sample
+* of the first channel and low for all other channels. This can be used
+* to check that the incoming data is correctly aligned. During normal
+* operation the data should never become unaligned, but some glitch or
+* electrostatic discharge might cause an extra read or clock cycle.
+* Monitoring the frstdata signal allows to recover from such failure
+* situations.
+*/
+
+   if (st->gpio_frstdata) {
+   ret = st->bops->read_block(st->dev, 1, data);
+   if (ret)
+   return 

[PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

[Eva Rachel Retuya]

Eliminate the non-standard attribute in_voltage_range and move its
functionality under the scale attribute. read_raw() has been taken care
of previously so only write_raw() is handled here.

Additionally, rename the attribute in_voltage_range_available into
in_voltage_scale_available.

Suggested-by: Lars-Peter Clausen 
Signed-off-by: Eva Rachel Retuya 
---
 drivers/staging/iio/adc/ad7606.c | 56 
 1 file changed, 16 insertions(+), 40 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7606.c b/drivers/staging/iio/adc/ad7606.c
index 4531908..cceb18c 100644
--- a/drivers/staging/iio/adc/ad7606.c
+++ b/drivers/staging/iio/adc/ad7606.c
@@ -161,42 +161,7 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
 }
 
-static ssize_t ad7606_show_range(struct device *dev,
-struct device_attribute *attr, char *buf)
-{
-   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
-   struct ad7606_state *st = iio_priv(indio_dev);
-
-   return sprintf(buf, "%u\n", st->range);
-}
-
-static ssize_t ad7606_store_range(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
-{
-   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
-   struct ad7606_state *st = iio_priv(indio_dev);
-   unsigned long lval;
-   int ret;
-
-   ret = kstrtoul(buf, 10, );
-   if (ret)
-   return ret;
-
-   if (!(lval == 5000 || lval == 1))
-   return -EINVAL;
-
-   mutex_lock(_dev->mlock);
-   gpiod_set_value(st->gpio_range, lval == 1);
-   st->range = lval;
-   mutex_unlock(_dev->mlock);
-
-   return count;
-}
-
-static IIO_DEVICE_ATTR(in_voltage_range, S_IRUGO | S_IWUSR,
-  ad7606_show_range, ad7606_store_range, 0);
-static IIO_CONST_ATTR(in_voltage_range_available, "5000 1");
+static IIO_CONST_ATTR(in_voltage_scale_available, "5000 1");
 
 static int ad7606_oversampling_get_index(unsigned int val)
 {
@@ -221,6 +186,19 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
int ret;
 
switch (mask) {
+   case IIO_CHAN_INFO_SCALE:
+   if (val2)
+   return -EINVAL;
+
+   if (!(val == 5000 || val == 1))
+   return -EINVAL;
+
+   mutex_lock(_dev->mlock);
+   gpiod_set_value(st->gpio_range, val == 1);
+   st->range = val;
+   mutex_unlock(_dev->mlock);
+
+   return 0;
case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
if (val2)
return -EINVAL;
@@ -247,8 +225,7 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
 static IIO_CONST_ATTR(oversampling_ratio_available, "1 2 4 8 16 32 64");
 
 static struct attribute *ad7606_attributes_os_and_range[] = {
-   _dev_attr_in_voltage_range.dev_attr.attr,
-   _const_attr_in_voltage_range_available.dev_attr.attr,
+   _const_attr_in_voltage_scale_available.dev_attr.attr,
_const_attr_oversampling_ratio_available.dev_attr.attr,
NULL,
 };
@@ -267,8 +244,7 @@ static const struct attribute_group 
ad7606_attribute_group_os = {
 };
 
 static struct attribute *ad7606_attributes_range[] = {
-   _dev_attr_in_voltage_range.dev_attr.attr,
-   _const_attr_in_voltage_range_available.dev_attr.attr,
+   _const_attr_in_voltage_scale_available.dev_attr.attr,
NULL,
 };
 
-- 
2.7.4

[PATCH 0/2] staging: iio: ad7606: move driver out of staging

[Eva Rachel Retuya]

Address the last remaining TODO [1] for this driver and move it from staging
into mainline.

[1] https://marc.info/?l=linux-iio=147689684332118=2 

Eva Rachel Retuya (2):
  staging: iio: ad7606: replace range/range_available with corresponding
scale
  staging: iio: ad7606: move out of staging

 drivers/iio/adc/Kconfig  |  34 +++
 drivers/iio/adc/Makefile |   3 +
 drivers/iio/adc/ad7606.c | 519 +
 drivers/iio/adc/ad7606.h |  78 +
 drivers/iio/adc/ad7606_par.c | 112 
 drivers/iio/adc/ad7606_spi.c |  78 +
 drivers/staging/iio/adc/Kconfig  |  34 ---
 drivers/staging/iio/adc/Makefile |   4 -
 drivers/staging/iio/adc/ad7606.c | 543 ---
 drivers/staging/iio/adc/ad7606.h |  78 -
 drivers/staging/iio/adc/ad7606_par.c | 112 
 drivers/staging/iio/adc/ad7606_spi.c |  78 -
 12 files changed, 824 insertions(+), 849 deletions(-)
 create mode 100644 drivers/iio/adc/ad7606.c
 create mode 100644 drivers/iio/adc/ad7606.h
 create mode 100644 drivers/iio/adc/ad7606_par.c
 create mode 100644 drivers/iio/adc/ad7606_spi.c
 delete mode 100644 drivers/staging/iio/adc/ad7606.c
 delete mode 100644 drivers/staging/iio/adc/ad7606.h
 delete mode 100644 drivers/staging/iio/adc/ad7606_par.c
 delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c

-- 
2.7.4

[PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

[Eva Rachel Retuya]

Eliminate the non-standard attribute in_voltage_range and move its
functionality under the scale attribute. read_raw() has been taken care
of previously so only write_raw() is handled here.

Additionally, rename the attribute in_voltage_range_available into
in_voltage_scale_available.

Suggested-by: Lars-Peter Clausen 
Signed-off-by: Eva Rachel Retuya 
---
 drivers/staging/iio/adc/ad7606.c | 56 
 1 file changed, 16 insertions(+), 40 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7606.c b/drivers/staging/iio/adc/ad7606.c
index 4531908..cceb18c 100644
--- a/drivers/staging/iio/adc/ad7606.c
+++ b/drivers/staging/iio/adc/ad7606.c
@@ -161,42 +161,7 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
 }
 
-static ssize_t ad7606_show_range(struct device *dev,
-struct device_attribute *attr, char *buf)
-{
-   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
-   struct ad7606_state *st = iio_priv(indio_dev);
-
-   return sprintf(buf, "%u\n", st->range);
-}
-
-static ssize_t ad7606_store_range(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
-{
-   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
-   struct ad7606_state *st = iio_priv(indio_dev);
-   unsigned long lval;
-   int ret;
-
-   ret = kstrtoul(buf, 10, );
-   if (ret)
-   return ret;
-
-   if (!(lval == 5000 || lval == 1))
-   return -EINVAL;
-
-   mutex_lock(_dev->mlock);
-   gpiod_set_value(st->gpio_range, lval == 1);
-   st->range = lval;
-   mutex_unlock(_dev->mlock);
-
-   return count;
-}
-
-static IIO_DEVICE_ATTR(in_voltage_range, S_IRUGO | S_IWUSR,
-  ad7606_show_range, ad7606_store_range, 0);
-static IIO_CONST_ATTR(in_voltage_range_available, "5000 1");
+static IIO_CONST_ATTR(in_voltage_scale_available, "5000 1");
 
 static int ad7606_oversampling_get_index(unsigned int val)
 {
@@ -221,6 +186,19 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
int ret;
 
switch (mask) {
+   case IIO_CHAN_INFO_SCALE:
+   if (val2)
+   return -EINVAL;
+
+   if (!(val == 5000 || val == 1))
+   return -EINVAL;
+
+   mutex_lock(_dev->mlock);
+   gpiod_set_value(st->gpio_range, val == 1);
+   st->range = val;
+   mutex_unlock(_dev->mlock);
+
+   return 0;
case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
if (val2)
return -EINVAL;
@@ -247,8 +225,7 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
 static IIO_CONST_ATTR(oversampling_ratio_available, "1 2 4 8 16 32 64");
 
 static struct attribute *ad7606_attributes_os_and_range[] = {
-   _dev_attr_in_voltage_range.dev_attr.attr,
-   _const_attr_in_voltage_range_available.dev_attr.attr,
+   _const_attr_in_voltage_scale_available.dev_attr.attr,
_const_attr_oversampling_ratio_available.dev_attr.attr,
NULL,
 };
@@ -267,8 +244,7 @@ static const struct attribute_group 
ad7606_attribute_group_os = {
 };
 
 static struct attribute *ad7606_attributes_range[] = {
-   _dev_attr_in_voltage_range.dev_attr.attr,
-   _const_attr_in_voltage_range_available.dev_attr.attr,
+   _const_attr_in_voltage_scale_available.dev_attr.attr,
NULL,
 };
 
-- 
2.7.4

[PATCH 0/2] staging: iio: ad7606: move driver out of staging

[Eva Rachel Retuya]

Address the last remaining TODO [1] for this driver and move it from staging
into mainline.

[1] https://marc.info/?l=linux-iio=147689684332118=2 

Eva Rachel Retuya (2):
  staging: iio: ad7606: replace range/range_available with corresponding
scale
  staging: iio: ad7606: move out of staging

 drivers/iio/adc/Kconfig  |  34 +++
 drivers/iio/adc/Makefile |   3 +
 drivers/iio/adc/ad7606.c | 519 +
 drivers/iio/adc/ad7606.h |  78 +
 drivers/iio/adc/ad7606_par.c | 112 
 drivers/iio/adc/ad7606_spi.c |  78 +
 drivers/staging/iio/adc/Kconfig  |  34 ---
 drivers/staging/iio/adc/Makefile |   4 -
 drivers/staging/iio/adc/ad7606.c | 543 ---
 drivers/staging/iio/adc/ad7606.h |  78 -
 drivers/staging/iio/adc/ad7606_par.c | 112 
 drivers/staging/iio/adc/ad7606_spi.c |  78 -
 12 files changed, 824 insertions(+), 849 deletions(-)
 create mode 100644 drivers/iio/adc/ad7606.c
 create mode 100644 drivers/iio/adc/ad7606.h
 create mode 100644 drivers/iio/adc/ad7606_par.c
 create mode 100644 drivers/iio/adc/ad7606_spi.c
 delete mode 100644 drivers/staging/iio/adc/ad7606.c
 delete mode 100644 drivers/staging/iio/adc/ad7606.h
 delete mode 100644 drivers/staging/iio/adc/ad7606_par.c
 delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c

-- 
2.7.4

Re: [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz

[Vignesh R]

On Friday 11 November 2016 09:00 AM, John Syne wrote:
> 
>> On Nov 9, 2016, at 9:07 PM, Vignesh R  wrote:
>>
>> Hi,
>>
>> On Thursday 10 November 2016 05:23 AM, John Syne wrote:
>>> OK, then back to my original question. Given that these DT properties are 
>>> supported in the driver
>>>
>>
>> Below properties are supported by only by ti_am3335x_adc driver and not
>> ti_am335x_tsc driver. As author of this patch pointed out in another
>> reply, there is no need to change step-opendelay for tsc. AFAIK, I don't
>> see a use case where these values needs to be tweaked for tsc channels,
>> therefore it does not make sense to be DT properties.
> Yeah, the confusion was mine because the author of this patch series was 
> proposing to hard code these settings while DT properties already existed in 
> the ti_am335x_adc driver. I use the ADC for sensor measurement and do not use 
> the touchscreen features. I already pointed out where these DT parameters 
> should be added by referencing how this was done in one of the BBB DT overlay 
> files [1]. I am just proposing the same is done as a default in the 
> AM33xx.dtsi and AM4372.dtsi files. Here is what I was proposing. 

> Granted, the adc-channels should be restricted to the subset of channels not 
> used by tsc, but you get the idea.

There are 4 wire, 5 wire and 8 wire touchscreens. Therefore there is no
way to know in advance, how many channels are available for adc. IMO,
this is not a SoC specific configuration but board dependent. Hence, all
channel related configurations need to be in board specific dts files
and not in top level dtsi files.

> 
> tscadc: tscadc@44e0d000 {
>   compatible = "ti,am3359-tscadc";
>   reg = <0x44e0d000 0x1000>;
>   interrupt-parent = <>;
>   interrupts = <16>;
>   ti,hwmods = "adc_tsc";
>   status = "disabled";
>   dmas = < 53 0>, < 57 0>;
>   dma-names = "fifo0", "fifo1”;
> 
>   tsc {
>   compatible = "ti,am3359-tsc";
>   };
>   am335x_adc: adc {
>   #io-channel-cells = <1>;
>   ti,adc-channels = <0 1 2 3 4 5 6>;
>   ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 
> 0x16 0x16>;
>   ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 
> 0x98 0x98 0x98>;
>   ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 
> 0x0 0x0>;
>   compatible = "ti,am3359-adc";
>   };
> };
> 
> [1]https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
> 

-- 
Regards
Vignesh

Re: [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz

[Vignesh R]

On Friday 11 November 2016 09:00 AM, John Syne wrote:
> 
>> On Nov 9, 2016, at 9:07 PM, Vignesh R  wrote:
>>
>> Hi,
>>
>> On Thursday 10 November 2016 05:23 AM, John Syne wrote:
>>> OK, then back to my original question. Given that these DT properties are 
>>> supported in the driver
>>>
>>
>> Below properties are supported by only by ti_am3335x_adc driver and not
>> ti_am335x_tsc driver. As author of this patch pointed out in another
>> reply, there is no need to change step-opendelay for tsc. AFAIK, I don't
>> see a use case where these values needs to be tweaked for tsc channels,
>> therefore it does not make sense to be DT properties.
> Yeah, the confusion was mine because the author of this patch series was 
> proposing to hard code these settings while DT properties already existed in 
> the ti_am335x_adc driver. I use the ADC for sensor measurement and do not use 
> the touchscreen features. I already pointed out where these DT parameters 
> should be added by referencing how this was done in one of the BBB DT overlay 
> files [1]. I am just proposing the same is done as a default in the 
> AM33xx.dtsi and AM4372.dtsi files. Here is what I was proposing. 

> Granted, the adc-channels should be restricted to the subset of channels not 
> used by tsc, but you get the idea.

There are 4 wire, 5 wire and 8 wire touchscreens. Therefore there is no
way to know in advance, how many channels are available for adc. IMO,
this is not a SoC specific configuration but board dependent. Hence, all
channel related configurations need to be in board specific dts files
and not in top level dtsi files.

> 
> tscadc: tscadc@44e0d000 {
>   compatible = "ti,am3359-tscadc";
>   reg = <0x44e0d000 0x1000>;
>   interrupt-parent = <>;
>   interrupts = <16>;
>   ti,hwmods = "adc_tsc";
>   status = "disabled";
>   dmas = < 53 0>, < 57 0>;
>   dma-names = "fifo0", "fifo1”;
> 
>   tsc {
>   compatible = "ti,am3359-tsc";
>   };
>   am335x_adc: adc {
>   #io-channel-cells = <1>;
>   ti,adc-channels = <0 1 2 3 4 5 6>;
>   ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 
> 0x16 0x16>;
>   ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 
> 0x98 0x98 0x98>;
>   ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 
> 0x0 0x0>;
>   compatible = "ti,am3359-adc";
>   };
> };
> 
> [1]https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
> 

-- 
Regards
Vignesh

Re: [PATCH] cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs

[kbuild test robot]

Hi Markus,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on next-20161110]
[cannot apply to v4.9-rc4]
[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/Markus-Mayer/cpufreq-brcmstb-cpufreq-CPUfreq-driver-for-older-Broadcom-STB-SoCs/2016-075914
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> FATAL: drivers/cpufreq/brcmstb-cpufreq: sizeof(struct platform_device_id)=24 
>> is not a modulo of the size of section 
>> __mod_platform___device_table=392.
>> Fix definition of struct platform_device_id in mod_devicetable.h

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs

[kbuild test robot]

Hi Markus,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on next-20161110]
[cannot apply to v4.9-rc4]
[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/Markus-Mayer/cpufreq-brcmstb-cpufreq-CPUfreq-driver-for-older-Broadcom-STB-SoCs/2016-075914
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> FATAL: drivers/cpufreq/brcmstb-cpufreq: sizeof(struct platform_device_id)=24 
>> is not a modulo of the size of section 
>> __mod_platform___device_table=392.
>> Fix definition of struct platform_device_id in mod_devicetable.h

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v3 8/9] media: venus: add Makefiles and Kconfig files

[Vivek Gautam]

On Mon, Nov 7, 2016 at 11:04 PM, Stanimir Varbanov
 wrote:
> Makefile and Kconfig files to build the Venus video codec driver.
>
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/media/platform/qcom/Kconfig|  7 +++
>  drivers/media/platform/qcom/Makefile   |  1 +
>  drivers/media/platform/qcom/venus/Makefile | 15 +++
>  3 files changed, 23 insertions(+)
>  create mode 100644 drivers/media/platform/qcom/Kconfig
>  create mode 100644 drivers/media/platform/qcom/Makefile
>  create mode 100644 drivers/media/platform/qcom/venus/Makefile
>
> diff --git a/drivers/media/platform/qcom/Kconfig 
> b/drivers/media/platform/qcom/Kconfig
> new file mode 100644
> index ..bf4d2fcce924
> --- /dev/null
> +++ b/drivers/media/platform/qcom/Kconfig
> @@ -0,0 +1,7 @@
> +
> +menuconfig VIDEO_QCOM_VENUS
> +tristate "Qualcomm Venus V4L2 encoder/decoder driver"
> +depends on ARCH_QCOM && VIDEO_V4L2

Let's also enable this for COMPILE_TEST.


Thanks
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 8/9] media: venus: add Makefiles and Kconfig files

[Vivek Gautam]

On Mon, Nov 7, 2016 at 11:04 PM, Stanimir Varbanov
 wrote:
> Makefile and Kconfig files to build the Venus video codec driver.
>
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/media/platform/qcom/Kconfig|  7 +++
>  drivers/media/platform/qcom/Makefile   |  1 +
>  drivers/media/platform/qcom/venus/Makefile | 15 +++
>  3 files changed, 23 insertions(+)
>  create mode 100644 drivers/media/platform/qcom/Kconfig
>  create mode 100644 drivers/media/platform/qcom/Makefile
>  create mode 100644 drivers/media/platform/qcom/venus/Makefile
>
> diff --git a/drivers/media/platform/qcom/Kconfig 
> b/drivers/media/platform/qcom/Kconfig
> new file mode 100644
> index ..bf4d2fcce924
> --- /dev/null
> +++ b/drivers/media/platform/qcom/Kconfig
> @@ -0,0 +1,7 @@
> +
> +menuconfig VIDEO_QCOM_VENUS
> +tristate "Qualcomm Venus V4L2 encoder/decoder driver"
> +depends on ARCH_QCOM && VIDEO_V4L2

Let's also enable this for COMPILE_TEST.


Thanks
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] mm: support anonymous stable page

[Minchan Kim]

Sorry for sending a wrong version. Here is new one.

>From 2d42ead9335cde51fd58d6348439ca03cf359ba2 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Fri, 11 Nov 2016 15:02:57 +0900
Subject: [PATCH] mm: support anonymous stable page

For developemnt for zram-swap asynchronous writeback, I found
strange corruption of compressed page. With investigation, it
reveals currently stable page doesn't support anonymous page.
IOW, reuse_swap_page can reuse the page without waiting
writeback completion so that it can corrupt data during
zram compression. It can affect every swap device which supports
asynchronous writeback and CRC checking as well as zRAM.

Unfortunately, reuse_swap_page should be atomic so that we
cannot wait on writeback in there so the approach in this patch
is simply return false if we found it needs stable page.
Although it increases memory footprint temporarily, it happens
rarely and it should be reclaimed easily althoug it happened.
Also, It would be better than waiting of IO completion, which
is critial path for application latency.

Cc: Hugh Dickins 
Cc: Darrick J. Wong 
Signed-off-by: Minchan Kim 
---
 mm/swapfile.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 2210de290b54..ea591435d8e0 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -943,11 +943,21 @@ bool reuse_swap_page(struct page *page, int 
*total_mapcount)
count = page_trans_huge_mapcount(page, total_mapcount);
if (count <= 1 && PageSwapCache(page)) {
count += page_swapcount(page);
-   if (count == 1 && !PageWriteback(page)) {
+   if (count != 1)
+   goto out;
+   if (!PageWriteback(page)) {
delete_from_swap_cache(page);
SetPageDirty(page);
+   } else {
+   struct address_space *mapping;
+
+   mapping = page_mapping(page);
+   if (bdi_cap_stable_pages_required(
+   inode_to_bdi(mapping->host)))
+   return false;
}
}
+out:
return count <= 1;
 }
 
@@ -2180,6 +2190,7 @@ static struct swap_info_struct *alloc_swap_info(void)
 static int claim_swapfile(struct swap_info_struct *p, struct inode *inode)
 {
int error;
+   struct address_space *swapper_space;
 
if (S_ISBLK(inode->i_mode)) {
p->bdev = bdgrab(I_BDEV(inode));
@@ -2202,6 +2213,9 @@ static int claim_swapfile(struct swap_info_struct *p, 
struct inode *inode)
} else
return -EINVAL;
 
+   swapper_space = _spaces[p->type];
+   swapper_space->host = inode;
+
return 0;
 }
 
-- 
2.7.4

Re: [PATCH] mm: support anonymous stable page

[Minchan Kim]

Sorry for sending a wrong version. Here is new one.

>From 2d42ead9335cde51fd58d6348439ca03cf359ba2 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Fri, 11 Nov 2016 15:02:57 +0900
Subject: [PATCH] mm: support anonymous stable page

For developemnt for zram-swap asynchronous writeback, I found
strange corruption of compressed page. With investigation, it
reveals currently stable page doesn't support anonymous page.
IOW, reuse_swap_page can reuse the page without waiting
writeback completion so that it can corrupt data during
zram compression. It can affect every swap device which supports
asynchronous writeback and CRC checking as well as zRAM.

Unfortunately, reuse_swap_page should be atomic so that we
cannot wait on writeback in there so the approach in this patch
is simply return false if we found it needs stable page.
Although it increases memory footprint temporarily, it happens
rarely and it should be reclaimed easily althoug it happened.
Also, It would be better than waiting of IO completion, which
is critial path for application latency.

Cc: Hugh Dickins 
Cc: Darrick J. Wong 
Signed-off-by: Minchan Kim 
---
 mm/swapfile.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 2210de290b54..ea591435d8e0 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -943,11 +943,21 @@ bool reuse_swap_page(struct page *page, int 
*total_mapcount)
count = page_trans_huge_mapcount(page, total_mapcount);
if (count <= 1 && PageSwapCache(page)) {
count += page_swapcount(page);
-   if (count == 1 && !PageWriteback(page)) {
+   if (count != 1)
+   goto out;
+   if (!PageWriteback(page)) {
delete_from_swap_cache(page);
SetPageDirty(page);
+   } else {
+   struct address_space *mapping;
+
+   mapping = page_mapping(page);
+   if (bdi_cap_stable_pages_required(
+   inode_to_bdi(mapping->host)))
+   return false;
}
}
+out:
return count <= 1;
 }
 
@@ -2180,6 +2190,7 @@ static struct swap_info_struct *alloc_swap_info(void)
 static int claim_swapfile(struct swap_info_struct *p, struct inode *inode)
 {
int error;
+   struct address_space *swapper_space;
 
if (S_ISBLK(inode->i_mode)) {
p->bdev = bdgrab(I_BDEV(inode));
@@ -2202,6 +2213,9 @@ static int claim_swapfile(struct swap_info_struct *p, 
struct inode *inode)
} else
return -EINVAL;
 
+   swapper_space = _spaces[p->type];
+   swapper_space->host = inode;
+
return 0;
 }
 
-- 
2.7.4

[git pull] vfs.git

[Al Viro]

Christoph's and Jan's aio fixes, fixup for generic_file_splice_read
(removal of pointless detritus that actually breaks it when used for gfs2
->splice_read()) and fixup for generic_file_read_iter() interaction with
ITER_PIPE destinations.

The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30:

  Linux 4.9-rc3 (2016-10-29 13:52:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to e519e7774784f3fa7728657d780863805ed1c983:

  splice: remove detritus from generic_file_splice_read() (2016-11-10 18:32:13 
-0500)


Al Viro (1):
  splice: remove detritus from generic_file_splice_read()

Christoph Hellwig (3):
  aio: hold an extra file reference over AIO read/write operations
  fs: remove the never implemented aio_fsync file operation
  fs: remove aio_run_iocb

Eryu Guan (1):
  mm/filemap: don't allow partially uptodate page for pipes

Jan Kara (1):
  aio: fix freeze protection of aio writes

 Documentation/filesystems/Locking |   1 -
 Documentation/filesystems/vfs.txt |   1 -
 fs/aio.c  | 207 --
 fs/ntfs/dir.c |   2 -
 fs/splice.c   |   5 -
 include/linux/fs.h|   2 +-
 mm/filemap.c  |   3 +
 7 files changed, 113 insertions(+), 108 deletions(-)

[git pull] vfs.git

[Al Viro]

Christoph's and Jan's aio fixes, fixup for generic_file_splice_read
(removal of pointless detritus that actually breaks it when used for gfs2
->splice_read()) and fixup for generic_file_read_iter() interaction with
ITER_PIPE destinations.

The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30:

  Linux 4.9-rc3 (2016-10-29 13:52:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to e519e7774784f3fa7728657d780863805ed1c983:

  splice: remove detritus from generic_file_splice_read() (2016-11-10 18:32:13 
-0500)


Al Viro (1):
  splice: remove detritus from generic_file_splice_read()

Christoph Hellwig (3):
  aio: hold an extra file reference over AIO read/write operations
  fs: remove the never implemented aio_fsync file operation
  fs: remove aio_run_iocb

Eryu Guan (1):
  mm/filemap: don't allow partially uptodate page for pipes

Jan Kara (1):
  aio: fix freeze protection of aio writes

 Documentation/filesystems/Locking |   1 -
 Documentation/filesystems/vfs.txt |   1 -
 fs/aio.c  | 207 --
 fs/ntfs/dir.c |   2 -
 fs/splice.c   |   5 -
 include/linux/fs.h|   2 +-
 mm/filemap.c  |   3 +
 7 files changed, 113 insertions(+), 108 deletions(-)

Re: [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Archit Taneja]

Hi Jitao,

I couldn't locate the original mail, so posting on this thread instead.
Some comments below.

On 11/10/2016 10:09 PM, Enric Balletbo Serra wrote:

Hi Jitao,

2016-08-27 8:44 GMT+02:00 Jitao Shi :

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
Reviewed-by: Daniel Kurtz 
---
Changes since v16:
 - Disable ps8640 DSI MCS Function.
 - Rename gpios name more clearly.
 - Tune the ps8640 power on sequence.

Changes since v15:
 - Drop drm_connector_(un)register calls from parade ps8640.
   The main DRM driver mtk_drm_drv now calls
   drm_connector_register_all() after drm_dev_register() in the
   mtk_drm_bind() function. That function should iterate over all
   connectors and call drm_connector_register() for each of them.
   So, remove drm_connector_(un)register calls from parade ps8640.

Changes since v14:
 - update copyright info.
 - change bridge_to_ps8640 and connector_to_ps8640 to inline function.
 - fix some coding style.
 - use sizeof as array counter.
 - use drm_get_edid when read edid.
 - add mutex when firmware updating.

Changes since v13:
 - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 
*data, u16 data_len)
 - fix PAGE2_SW_REST tyro.
 - move the buf[3] init to entrance of the function.

Changes since v12:
 - fix hw_chip_id build warning

Changes since v11:
 - Remove depends on I2C, add DRM depends
 - Reuse ps8640_write_bytes() in ps8640_write_byte()
 - Use timer check for polling like the routines in 
 - Fix no drm_connector_unregister/drm_connector_cleanup when 
ps8640_bridge_attach fail
 - Check the ps8640 hardware id in ps8640_validate_firmware
 - Remove fw_version check
 - Move ps8640_validate_firmware before ps8640_enter_bl
 - Add ddc_i2c unregister when probe fail and ps8640_remove
---
 drivers/gpu/drm/bridge/Kconfig |   12 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/parade-ps8640.c | 1077 
 3 files changed, 1090 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index b590e67..c59d043 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -50,6 +50,18 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on DRM
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
 config DRM_SII902X
tristate "Silicon Image sii902x RGB/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index efdb07e..3360537 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..7d67431
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1077 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 


Not needed.


+#include 
+#include 
+#include 
+#include 
+#include 


The above 2 aren't needed.


+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 


Not needed.


+#include 
+#include 
+
+#define PAGE1_VSTART   0x6b
+#define PAGE2_SPI_CFG3 0x82
+#define I2C_TO_SPI_RESET   0x20
+#define PAGE2_ROMADD_BYTE1 0x8e
+#define PAGE2_ROMADD_BYTE2 0x8f
+#define PAGE2_SWSPI_WDATA  0x90
+#define PAGE2_SWSPI_RDATA  0x91
+#define PAGE2_SWSPI_LEN0x92
+#define PAGE2_SWSPI_CTL0x93
+#define TRIGGER_NO_READBACK0x05
+#define TRIGGER_READBACK   0x01
+#define PAGE2_SPI_STATUS   0x9e
+#define SPI_READY 

Re: [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Archit Taneja]

Hi Jitao,

I couldn't locate the original mail, so posting on this thread instead.
Some comments below.

On 11/10/2016 10:09 PM, Enric Balletbo Serra wrote:

Hi Jitao,

2016-08-27 8:44 GMT+02:00 Jitao Shi :

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
Reviewed-by: Daniel Kurtz 
---
Changes since v16:
 - Disable ps8640 DSI MCS Function.
 - Rename gpios name more clearly.
 - Tune the ps8640 power on sequence.

Changes since v15:
 - Drop drm_connector_(un)register calls from parade ps8640.
   The main DRM driver mtk_drm_drv now calls
   drm_connector_register_all() after drm_dev_register() in the
   mtk_drm_bind() function. That function should iterate over all
   connectors and call drm_connector_register() for each of them.
   So, remove drm_connector_(un)register calls from parade ps8640.

Changes since v14:
 - update copyright info.
 - change bridge_to_ps8640 and connector_to_ps8640 to inline function.
 - fix some coding style.
 - use sizeof as array counter.
 - use drm_get_edid when read edid.
 - add mutex when firmware updating.

Changes since v13:
 - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 
*data, u16 data_len)
 - fix PAGE2_SW_REST tyro.
 - move the buf[3] init to entrance of the function.

Changes since v12:
 - fix hw_chip_id build warning

Changes since v11:
 - Remove depends on I2C, add DRM depends
 - Reuse ps8640_write_bytes() in ps8640_write_byte()
 - Use timer check for polling like the routines in 
 - Fix no drm_connector_unregister/drm_connector_cleanup when 
ps8640_bridge_attach fail
 - Check the ps8640 hardware id in ps8640_validate_firmware
 - Remove fw_version check
 - Move ps8640_validate_firmware before ps8640_enter_bl
 - Add ddc_i2c unregister when probe fail and ps8640_remove
---
 drivers/gpu/drm/bridge/Kconfig |   12 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/parade-ps8640.c | 1077 
 3 files changed, 1090 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index b590e67..c59d043 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -50,6 +50,18 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on DRM
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
 config DRM_SII902X
tristate "Silicon Image sii902x RGB/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index efdb07e..3360537 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..7d67431
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1077 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 


Not needed.


+#include 
+#include 
+#include 
+#include 
+#include 


The above 2 aren't needed.


+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 


Not needed.


+#include 
+#include 
+
+#define PAGE1_VSTART   0x6b
+#define PAGE2_SPI_CFG3 0x82
+#define I2C_TO_SPI_RESET   0x20
+#define PAGE2_ROMADD_BYTE1 0x8e
+#define PAGE2_ROMADD_BYTE2 0x8f
+#define PAGE2_SWSPI_WDATA  0x90
+#define PAGE2_SWSPI_RDATA  0x91
+#define PAGE2_SWSPI_LEN0x92
+#define PAGE2_SWSPI_CTL0x93
+#define TRIGGER_NO_READBACK0x05
+#define TRIGGER_READBACK   0x01
+#define PAGE2_SPI_STATUS   0x9e
+#define SPI_READY  0x0c
+#define PAGE2_GPIO_L   0xa6
+#define PAGE2_GPIO_H  

Re: [tip:x86/urgent] x86/cpu: Deal with broken firmware (VMWare/XEN)

[Alok Kataria]

Hi Thomas, 

On Wed, 2016-11-09 at 12:27 -0800, tip-bot for Thomas Gleixner wrote:
> Commit-ID:  d49597fd3bc7d9534de55e9256767f073be1b33a
> Gitweb: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_tip_d49597fd3bc7d9534de55e9256767f073be1b33a=CwIDaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=2AkLWShm6V8Nuu8ZZ-80Flo6y0XxCGmO1xrsAeRArAE=WBsB4JFr-Dct0um4Kf8QAxC7w6p-Mlk3H-LwItQJ7Fw=qI64vSH3y6q8wJhcqpI4dXYma-i1RTtlxgKwKwhFWWo=
>  
> Author: Thomas Gleixner 
> AuthorDate: Wed, 9 Nov 2016 16:35:51 +0100
> Committer:  Thomas Gleixner 
> CommitDate: Wed, 9 Nov 2016 21:05:01 +0100
> 
> x86/cpu: Deal with broken firmware (VMWare/XEN)
> 
> Both ACPI and MP specifications require that the APIC id in the respective
> tables must be the same as the APIC id in CPUID.
> 
> The kernel retrieves the physical package id from the APIC id during the
> ACPI/MP table scan and builds the physical to logical package map. The
> physical package id which is used after a CPU comes up is retrieved from
> CPUID. So we rely on ACPI/MP tables and CPUID agreeing in that respect.
> 
> There exist VMware and XEN implementations which violate the spec. As a
> result the physical to logical package map, which relies on the ACPI/MP
> tables does not work on those systems, because the CPUID initialized
> physical package id does not match the firmware id. This causes system
> crashes and malfunction due to invalid package mappings.

For documentation purpose let me note that, VMware VMs running at
virtual hardware version 9 and above don't have this ACPI/MP and CPUID
divergence on the package id. So not everyone will see this issue on
their VMs, this bug is limited to folks running at virtual hardware
version 8 and prior.

It's good that we can workaround the platform bug for those VMs, thanks
for adding these checks.

Alok

> 
> The only way to cure this is to sanitize the physical package id after the
> CPUID enumeration and yell when the APIC ids are different. Fix up the
> initial APIC id, which is fine as it is only used printout purposes.
> 
> If the physical package IDs differ yell and use the package information
> from the ACPI/MP tables so the existing logical package map just works.
> 
> Chas provided the resulting dmesg output for his affected 4 virtual
> sockets, 1 core per socket VM:
> 
> [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 1 CPUID: 2
> [Firmware Bug]: CPU1: Using firmware package id 1 instead of 2
> 
> 
> Reported-and-tested-by: "Charles (Chas) Williams" ,
> Reported-by: M. Vefa Bicakci 
> Signed-off-by: Thomas Gleixner 
> Cc: Peter Zijlstra 
> Cc: Sebastian Andrzej Siewior 
> Cc: Borislav Petkov 
> Cc: Alok Kataria 
> Cc: Boris Ostrovsky 
> Cc: #4.6+ 
> Link: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_alpine.DEB.2.20.1611091613540.3501-40nanos=CwIDaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=2AkLWShm6V8Nuu8ZZ-80Flo6y0XxCGmO1xrsAeRArAE=WBsB4JFr-Dct0um4Kf8QAxC7w6p-Mlk3H-LwItQJ7Fw=HNQMGUrw_s6Mc_oyREBnD4TrUjERbLcH1viAZr-aFPY=
>  
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/kernel/cpu/common.c | 32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 9bd910a..cc9e980 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -979,6 +979,35 @@ static void x86_init_cache_qos(struct cpuinfo_x86 *c)
>  }
>  
>  /*
> + * The physical to logical package id mapping is initialized from the
> + * acpi/mptables information. Make sure that CPUID actually agrees with
> + * that.
> + */
> +static void sanitize_package_id(struct cpuinfo_x86 *c)
> +{
> +#ifdef CONFIG_SMP
> + unsigned int pkg, apicid, cpu = smp_processor_id();
> +
> + apicid = apic->cpu_present_to_apicid(cpu);
> + pkg = apicid >> boot_cpu_data.x86_coreid_bits;
> +
> + if (apicid != c->initial_apicid) {
> + pr_err(FW_BUG "CPU%u: APIC id mismatch. Firmware: %x CPUID: 
> %x\n",
> +cpu, apicid, c->initial_apicid);
> + c->initial_apicid = apicid;
> + }
> + if (pkg != c->phys_proc_id) {
> + pr_err(FW_BUG "CPU%u: Using firmware package id %u instead of 
> %u\n",
> +cpu, pkg, c->phys_proc_id);
> + c->phys_proc_id = pkg;
> + }
> + c->logical_proc_id = topology_phys_to_logical_pkg(pkg);
> +#else
> + c->logical_proc_id = 0;
> +#endif
> +}
> +
> +/*
>   * This does the hard work of actually picking apart the CPU stuff...
>   */
>  static void identify_cpu(struct cpuinfo_x86 *c)
> @@ -1103,8 +1132,7 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>  #ifdef CONFIG_NUMA
>   

Re: [tip:x86/urgent] x86/cpu: Deal with broken firmware (VMWare/XEN)

[Alok Kataria]

Hi Thomas, 

On Wed, 2016-11-09 at 12:27 -0800, tip-bot for Thomas Gleixner wrote:
> Commit-ID:  d49597fd3bc7d9534de55e9256767f073be1b33a
> Gitweb: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_tip_d49597fd3bc7d9534de55e9256767f073be1b33a=CwIDaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=2AkLWShm6V8Nuu8ZZ-80Flo6y0XxCGmO1xrsAeRArAE=WBsB4JFr-Dct0um4Kf8QAxC7w6p-Mlk3H-LwItQJ7Fw=qI64vSH3y6q8wJhcqpI4dXYma-i1RTtlxgKwKwhFWWo=
>  
> Author: Thomas Gleixner 
> AuthorDate: Wed, 9 Nov 2016 16:35:51 +0100
> Committer:  Thomas Gleixner 
> CommitDate: Wed, 9 Nov 2016 21:05:01 +0100
> 
> x86/cpu: Deal with broken firmware (VMWare/XEN)
> 
> Both ACPI and MP specifications require that the APIC id in the respective
> tables must be the same as the APIC id in CPUID.
> 
> The kernel retrieves the physical package id from the APIC id during the
> ACPI/MP table scan and builds the physical to logical package map. The
> physical package id which is used after a CPU comes up is retrieved from
> CPUID. So we rely on ACPI/MP tables and CPUID agreeing in that respect.
> 
> There exist VMware and XEN implementations which violate the spec. As a
> result the physical to logical package map, which relies on the ACPI/MP
> tables does not work on those systems, because the CPUID initialized
> physical package id does not match the firmware id. This causes system
> crashes and malfunction due to invalid package mappings.

For documentation purpose let me note that, VMware VMs running at
virtual hardware version 9 and above don't have this ACPI/MP and CPUID
divergence on the package id. So not everyone will see this issue on
their VMs, this bug is limited to folks running at virtual hardware
version 8 and prior.

It's good that we can workaround the platform bug for those VMs, thanks
for adding these checks.

Alok

> 
> The only way to cure this is to sanitize the physical package id after the
> CPUID enumeration and yell when the APIC ids are different. Fix up the
> initial APIC id, which is fine as it is only used printout purposes.
> 
> If the physical package IDs differ yell and use the package information
> from the ACPI/MP tables so the existing logical package map just works.
> 
> Chas provided the resulting dmesg output for his affected 4 virtual
> sockets, 1 core per socket VM:
> 
> [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 1 CPUID: 2
> [Firmware Bug]: CPU1: Using firmware package id 1 instead of 2
> 
> 
> Reported-and-tested-by: "Charles (Chas) Williams" ,
> Reported-by: M. Vefa Bicakci 
> Signed-off-by: Thomas Gleixner 
> Cc: Peter Zijlstra 
> Cc: Sebastian Andrzej Siewior 
> Cc: Borislav Petkov 
> Cc: Alok Kataria 
> Cc: Boris Ostrovsky 
> Cc: #4.6+ 
> Link: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_alpine.DEB.2.20.1611091613540.3501-40nanos=CwIDaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=2AkLWShm6V8Nuu8ZZ-80Flo6y0XxCGmO1xrsAeRArAE=WBsB4JFr-Dct0um4Kf8QAxC7w6p-Mlk3H-LwItQJ7Fw=HNQMGUrw_s6Mc_oyREBnD4TrUjERbLcH1viAZr-aFPY=
>  
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/kernel/cpu/common.c | 32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 9bd910a..cc9e980 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -979,6 +979,35 @@ static void x86_init_cache_qos(struct cpuinfo_x86 *c)
>  }
>  
>  /*
> + * The physical to logical package id mapping is initialized from the
> + * acpi/mptables information. Make sure that CPUID actually agrees with
> + * that.
> + */
> +static void sanitize_package_id(struct cpuinfo_x86 *c)
> +{
> +#ifdef CONFIG_SMP
> + unsigned int pkg, apicid, cpu = smp_processor_id();
> +
> + apicid = apic->cpu_present_to_apicid(cpu);
> + pkg = apicid >> boot_cpu_data.x86_coreid_bits;
> +
> + if (apicid != c->initial_apicid) {
> + pr_err(FW_BUG "CPU%u: APIC id mismatch. Firmware: %x CPUID: 
> %x\n",
> +cpu, apicid, c->initial_apicid);
> + c->initial_apicid = apicid;
> + }
> + if (pkg != c->phys_proc_id) {
> + pr_err(FW_BUG "CPU%u: Using firmware package id %u instead of 
> %u\n",
> +cpu, pkg, c->phys_proc_id);
> + c->phys_proc_id = pkg;
> + }
> + c->logical_proc_id = topology_phys_to_logical_pkg(pkg);
> +#else
> + c->logical_proc_id = 0;
> +#endif
> +}
> +
> +/*
>   * This does the hard work of actually picking apart the CPU stuff...
>   */
>  static void identify_cpu(struct cpuinfo_x86 *c)
> @@ -1103,8 +1132,7 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>  #ifdef CONFIG_NUMA
>   numa_add_cpu(smp_processor_id());
>  #endif
> - /* The boot/hotplug time assigment got cleared, restore it */
> - c->logical_proc_id = topology_phys_to_logical_pkg(c->phys_proc_id);
> + sanitize_package_id(c);
>  }
>  
>  /*

Re: [patch] mm, slab: faster active and free stats

[Joonsoo Kim]

On Wed, Nov 09, 2016 at 04:38:08PM -0800, David Rientjes wrote:
> On Tue, 8 Nov 2016, Andrew Morton wrote:
> 
> > > Reading /proc/slabinfo or monitoring slabtop(1) can become very expensive
> > > if there are many slab caches and if there are very lengthy per-node
> > > partial and/or free lists.
> > > 
> > > Commit 07a63c41fa1f ("mm/slab: improve performance of gathering slabinfo
> > > stats") addressed the per-node full lists which showed a significant
> > > improvement when no objects were freed.  This patch has the same
> > > motivation and optimizes the remainder of the usecases where there are
> > > very lengthy partial and free lists.
> > > 
> > > This patch maintains per-node active_slabs (full and partial) and
> > > free_slabs rather than iterating the lists at runtime when reading
> > > /proc/slabinfo.
> > 
> > Are there any nice numbers you can share?
> > 
> 
> Yes, please add this to the description:
> 
> 
> When allocating 100GB of slab from a test cache where every slab page is
> on the partial list, reading /proc/slabinfo (includes all other slab
> caches on the system) takes ~247ms on average with 48 samples.
> 
> As a result of this patch, the same read takes ~0.856ms on average.

Hello, David.

Maintaining acitve/free_slab counters looks so complex. And, I think
that we don't need to maintain these counters for faster slabinfo.
Key point is to remove iterating n->slabs_partial list.

We can calculate active slab/object by following equation as you did in
this patch.

active_slab(n) = n->num_slab - the number of free_slab
active_object(n) = n->num_slab * cachep->num - n->free_objects

To get the number of free_slab, we need to iterate n->slabs_free list
but I guess it would be small enough.

If you don't like to iterate n->slabs_free list in slabinfo, just
maintaining the number of slabs_free would be enough.

Thanks.

Re: [patch] mm, slab: faster active and free stats

[Joonsoo Kim]

On Wed, Nov 09, 2016 at 04:38:08PM -0800, David Rientjes wrote:
> On Tue, 8 Nov 2016, Andrew Morton wrote:
> 
> > > Reading /proc/slabinfo or monitoring slabtop(1) can become very expensive
> > > if there are many slab caches and if there are very lengthy per-node
> > > partial and/or free lists.
> > > 
> > > Commit 07a63c41fa1f ("mm/slab: improve performance of gathering slabinfo
> > > stats") addressed the per-node full lists which showed a significant
> > > improvement when no objects were freed.  This patch has the same
> > > motivation and optimizes the remainder of the usecases where there are
> > > very lengthy partial and free lists.
> > > 
> > > This patch maintains per-node active_slabs (full and partial) and
> > > free_slabs rather than iterating the lists at runtime when reading
> > > /proc/slabinfo.
> > 
> > Are there any nice numbers you can share?
> > 
> 
> Yes, please add this to the description:
> 
> 
> When allocating 100GB of slab from a test cache where every slab page is
> on the partial list, reading /proc/slabinfo (includes all other slab
> caches on the system) takes ~247ms on average with 48 samples.
> 
> As a result of this patch, the same read takes ~0.856ms on average.

Hello, David.

Maintaining acitve/free_slab counters looks so complex. And, I think
that we don't need to maintain these counters for faster slabinfo.
Key point is to remove iterating n->slabs_partial list.

We can calculate active slab/object by following equation as you did in
this patch.

active_slab(n) = n->num_slab - the number of free_slab
active_object(n) = n->num_slab * cachep->num - n->free_objects

To get the number of free_slab, we need to iterate n->slabs_free list
but I guess it would be small enough.

If you don't like to iterate n->slabs_free list in slabinfo, just
maintaining the number of slabs_free would be enough.

Thanks.

Re: [PATCH v16 0/5] Mediatek MT8173 CMDQ support

[Jassi Brar]

On Thu, Nov 10, 2016 at 4:45 PM, Horng-Shyang Liao  wrote:
> On Tue, 2016-11-01 at 19:28 +0800, HS Liao wrote:
>> Hi,
>>
>> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
>> to help write registers with critical time limitation, such as
>> updating display configuration during the vblank. It controls Global
>> Command Engine (GCE) hardware to achieve this requirement.
>>
>> These patches have a build dependency on top of v4.9-rc1.
>>
>> Changes since v15:
>>  - separate "suspend and resume" patch from "save energy" patch
>>  - don't stop running tasks in cmdq_suspend()
>>(i.e. leave no running tasks guarantee to clients)
>>
>> Best regards,
>> HS Liao
>>
>> HS Liao (5):
>>   dt-bindings: soc: Add documentation for the MediaTek GCE unit
>>   CMDQ: Mediatek CMDQ driver
>>   arm64: dts: mt8173: Add GCE node
>>   CMDQ: suspend and resume
>>   CMDQ: save energy
>>
>>  .../devicetree/bindings/mailbox/mtk-gce.txt|  43 ++
>>  arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  10 +
>>  drivers/mailbox/Kconfig|  10 +
>>  drivers/mailbox/Makefile   |   2 +
>>  drivers/mailbox/mtk-cmdq-mailbox.c | 632 
>> +
>>  drivers/soc/mediatek/Kconfig   |  11 +
>>  drivers/soc/mediatek/Makefile  |   1 +
>>  drivers/soc/mediatek/mtk-cmdq-helper.c | 310 ++
>>  include/linux/mailbox/mtk-cmdq-mailbox.h   |  67 +++
>>  include/linux/soc/mediatek/mtk-cmdq.h  | 182 ++
>>  10 files changed, 1268 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
>>  create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
>>  create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
>>  create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
>>  create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
>>
>
>
> Hi Jassi, Matthias,
>
> Sorry to disturb you.
>
No, you don't disturb, but the controller driver and protocol driver,
introduced in the same patch, does :)   So does the suspend/resume
support (patch 4&5) added  separately as a patch on top. Please
reorganise the patchset.

Thanks.

Re: [PATCH v16 0/5] Mediatek MT8173 CMDQ support

[Jassi Brar]

On Thu, Nov 10, 2016 at 4:45 PM, Horng-Shyang Liao  wrote:
> On Tue, 2016-11-01 at 19:28 +0800, HS Liao wrote:
>> Hi,
>>
>> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
>> to help write registers with critical time limitation, such as
>> updating display configuration during the vblank. It controls Global
>> Command Engine (GCE) hardware to achieve this requirement.
>>
>> These patches have a build dependency on top of v4.9-rc1.
>>
>> Changes since v15:
>>  - separate "suspend and resume" patch from "save energy" patch
>>  - don't stop running tasks in cmdq_suspend()
>>(i.e. leave no running tasks guarantee to clients)
>>
>> Best regards,
>> HS Liao
>>
>> HS Liao (5):
>>   dt-bindings: soc: Add documentation for the MediaTek GCE unit
>>   CMDQ: Mediatek CMDQ driver
>>   arm64: dts: mt8173: Add GCE node
>>   CMDQ: suspend and resume
>>   CMDQ: save energy
>>
>>  .../devicetree/bindings/mailbox/mtk-gce.txt|  43 ++
>>  arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  10 +
>>  drivers/mailbox/Kconfig|  10 +
>>  drivers/mailbox/Makefile   |   2 +
>>  drivers/mailbox/mtk-cmdq-mailbox.c | 632 
>> +
>>  drivers/soc/mediatek/Kconfig   |  11 +
>>  drivers/soc/mediatek/Makefile  |   1 +
>>  drivers/soc/mediatek/mtk-cmdq-helper.c | 310 ++
>>  include/linux/mailbox/mtk-cmdq-mailbox.h   |  67 +++
>>  include/linux/soc/mediatek/mtk-cmdq.h  | 182 ++
>>  10 files changed, 1268 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
>>  create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
>>  create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
>>  create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
>>  create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
>>
>
>
> Hi Jassi, Matthias,
>
> Sorry to disturb you.
>
No, you don't disturb, but the controller driver and protocol driver,
introduced in the same patch, does :)   So does the suspend/resume
support (patch 4&5) added  separately as a patch on top. Please
reorganise the patchset.

Thanks.

[PATCH] mm: support anonymous stable page

[Minchan Kim]

For developemnt for zram-swap asynchronous writeback, I found
strange corruption of compressed page. With investigation, it
reveals currently stable page doesn't support anonymous page.
IOW, reuse_swap_page can reuse the page without waiting
writeback completion so that it can corrupt data during
zram compression. It can affect every swap device which supports
asynchronous writeback and CRC checking as well as zRAM.

Unfortunately, reuse_swap_page should be atomic so that we
cannot wait on writeback in there so the approach in this patch
is simply return false if we found it needs stable page.
Although it increases memory footprint temporarily, it happens
rarely and it should be reclaimed easily althoug it happened.
Also, It would be better than waiting of IO completion, which
is critial path for application latency.

Cc: Hugh Dickins 
Cc: Darrick J. Wong 
Signed-off-by: Minchan Kim 
---
 mm/swapfile.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 816ca8663ae5..ea591435d8e0 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -949,7 +949,12 @@ bool reuse_swap_page(struct page *page, int 
*total_mapcount)
delete_from_swap_cache(page);
SetPageDirty(page);
} else {
-   wait_for_stable_page(page);
+   struct address_space *mapping;
+
+   mapping = page_mapping(page);
+   if (bdi_cap_stable_pages_required(
+   inode_to_bdi(mapping->host)))
+   return false;
}
}
 out:
@@ -2185,6 +2190,7 @@ static struct swap_info_struct *alloc_swap_info(void)
 static int claim_swapfile(struct swap_info_struct *p, struct inode *inode)
 {
int error;
+   struct address_space *swapper_space;
 
if (S_ISBLK(inode->i_mode)) {
p->bdev = bdgrab(I_BDEV(inode));
@@ -2207,6 +2213,9 @@ static int claim_swapfile(struct swap_info_struct *p, 
struct inode *inode)
} else
return -EINVAL;
 
+   swapper_space = _spaces[p->type];
+   swapper_space->host = inode;
+
return 0;
 }
 
-- 
2.7.4

[PATCH] mm: support anonymous stable page

[Minchan Kim]

For developemnt for zram-swap asynchronous writeback, I found
strange corruption of compressed page. With investigation, it
reveals currently stable page doesn't support anonymous page.
IOW, reuse_swap_page can reuse the page without waiting
writeback completion so that it can corrupt data during
zram compression. It can affect every swap device which supports
asynchronous writeback and CRC checking as well as zRAM.

Unfortunately, reuse_swap_page should be atomic so that we
cannot wait on writeback in there so the approach in this patch
is simply return false if we found it needs stable page.
Although it increases memory footprint temporarily, it happens
rarely and it should be reclaimed easily althoug it happened.
Also, It would be better than waiting of IO completion, which
is critial path for application latency.

Cc: Hugh Dickins 
Cc: Darrick J. Wong 
Signed-off-by: Minchan Kim 
---
 mm/swapfile.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 816ca8663ae5..ea591435d8e0 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -949,7 +949,12 @@ bool reuse_swap_page(struct page *page, int 
*total_mapcount)
delete_from_swap_cache(page);
SetPageDirty(page);
} else {
-   wait_for_stable_page(page);
+   struct address_space *mapping;
+
+   mapping = page_mapping(page);
+   if (bdi_cap_stable_pages_required(
+   inode_to_bdi(mapping->host)))
+   return false;
}
}
 out:
@@ -2185,6 +2190,7 @@ static struct swap_info_struct *alloc_swap_info(void)
 static int claim_swapfile(struct swap_info_struct *p, struct inode *inode)
 {
int error;
+   struct address_space *swapper_space;
 
if (S_ISBLK(inode->i_mode)) {
p->bdev = bdgrab(I_BDEV(inode));
@@ -2207,6 +2213,9 @@ static int claim_swapfile(struct swap_info_struct *p, 
struct inode *inode)
} else
return -EINVAL;
 
+   swapper_space = _spaces[p->type];
+   swapper_space->host = inode;
+
return 0;
 }
 
-- 
2.7.4

Re: [PATCH 06/35] staging: lustre: osc: Performance tune for LRU

[kbuild test robot]

Hi Jinshan,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20161110]
[cannot apply to v4.9-rc4]
[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/James-Simmons/second-batch-of-missing-lustre-2-8-patches/2016-021225
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

>> ERROR: "__divdi3" [drivers/staging/lustre/lustre/osc/osc.ko] undefined!
   ERROR: "__umoddi3" [drivers/staging/lustre/lustre/obdclass/obdclass.ko] 
undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 06/35] staging: lustre: osc: Performance tune for LRU

[kbuild test robot]

Hi Jinshan,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20161110]
[cannot apply to v4.9-rc4]
[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/James-Simmons/second-batch-of-missing-lustre-2-8-patches/2016-021225
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

>> ERROR: "__divdi3" [drivers/staging/lustre/lustre/osc/osc.ko] undefined!
   ERROR: "__umoddi3" [drivers/staging/lustre/lustre/obdclass/obdclass.ko] 
undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v8 2/3] drm/fence: add fence timeline to drm_crtc

[Gustavo Padovan]

From: Gustavo Padovan 

Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.

v2: Comment by Daniel Stone:
- add BUG_ON() to fence_to_crtc() macro

v3: Comment by Ville Syrjälä
- Use more meaningful name as crtc timeline name

v4: Comments by Brian Starkey
- Use even more meaninful name for the crtc timeline
- add doc for timeline_name
Comment by Daniel Vetter
- use in-line style for comments

- rebase after fence -> dma_fence rename

v5: Comment by Daniel Vetter
- Add doc for drm_crtc_fence_ops

Signed-off-by: Gustavo Padovan 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 31 +++
 include/drm/drm_crtc.h | 45 +
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 154e040..9b9881b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -165,6 +165,32 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc)
 #endif
 }
 
+static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->dev->driver->name;
+}
+
+static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->timeline_name;
+}
+
+static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+const struct dma_fence_ops drm_crtc_fence_ops = {
+   .get_driver_name = drm_crtc_fence_get_driver_name,
+   .get_timeline_name = drm_crtc_fence_get_timeline_name,
+   .enable_signaling = drm_crtc_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
 /**
  * drm_crtc_init_with_planes - Initialise a new CRTC object with
  *specified primary and cursor planes.
@@ -222,6 +248,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
return -ENOMEM;
}
 
+   crtc->fence_context = dma_fence_context_alloc(1);
+   spin_lock_init(>fence_lock);
+   snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
+"CRTC:%d-%s", crtc->base.id, crtc->name);
+
crtc->base.properties = >properties;
 
list_add_tail(>head, >crtc_list);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 11780a9..0870de1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -32,6 +32,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -739,9 +741,52 @@ struct drm_crtc {
 */
struct drm_crtc_crc crc;
 #endif
+
+   /**
+* @fence_context:
+*
+* timeline context used for fence operations.
+*/
+   unsigned int fence_context;
+
+   /**
+* @fence_lock:
+*
+* spinlock to protect the fences in the fence_context.
+*/
+
+   spinlock_t fence_lock;
+   /**
+* @fence_seqno:
+*
+* Seqno variable used as monotonic counter for the fences
+* created on the CRTC's timeline.
+*/
+   unsigned long fence_seqno;
+
+   /**
+* @timeline_name:
+*
+* The name of the CRTC's fence timeline.
+*/
+   char timeline_name[32];
 };
 
 /**
+ * dma_crtc_fence_ops - fence ops for the drm_crtc timeline
+ *
+ * It contains the dma_fence_ops that should be called by the dma_fence
+ * code. CRTC core should use this ops when initializing fences.
+ */
+extern const struct dma_fence_ops drm_crtc_fence_ops;
+
+static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
+{
+   BUG_ON(fence->ops != _crtc_fence_ops);
+   return container_of(fence->lock, struct drm_crtc, fence_lock);
+}
+
+/**
  * struct drm_mode_set - new values for a CRTC config change
  * @fb: framebuffer to use for new config
  * @crtc: CRTC whose configuration we're about to change
-- 
2.5.5

[PATCH v8 1/3] drm/fence: add in-fences support

[Gustavo Padovan]

From: Gustavo Padovan 

There is now a new property called IN_FENCE_FD attached to every plane
state that receives sync_file fds from userspace via the atomic commit
IOCTL.

The fd is then translated to a fence (that may be a fence_array
subclass or just a normal fence) and then used by DRM to fence_wait() for
all fences in the sync_file to signal. So it only commits when all
framebuffers are ready to scanout.

v2: Comments by Daniel Vetter:
- remove set state->fence = NULL in destroy phase
- accept fence -1 as valid and just return 0
- do not call fence_get() - sync_file_fences_get() already calls it
- fence_put() if state->fence is already set, in case userspace
set the property more than once.

v3: WARN_ON if fence is set but state has no FB

v4: Comment from Maarten Lankhorst
- allow set fence with no related fb

v5: rename FENCE_FD to IN_FENCE_FD

v6: Comments by Daniel Vetter:
- rename plane_state->in_fence back to "fence"
- re-introduce WARN_ON if fence set but no fb

 - rebase after fence -> dma_fence rename

v7: Comments by Brian Starkey
- set state->fence to NULL when duplicating the state
- fail if IN_FENCE_FD was already set

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/Kconfig |  1 +
 drivers/gpu/drm/drm_atomic.c| 14 ++
 drivers/gpu/drm/drm_atomic_helper.c |  5 +
 drivers/gpu/drm/drm_crtc.c  |  6 ++
 drivers/gpu/drm/drm_plane.c |  1 +
 include/drm/drm_crtc.h  |  5 +
 6 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 25e8e37..360cb92 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+   select SYNC_FILE
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
  introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b096c16..8e26ad1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 
@@ -709,6 +710,17 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
drm_framebuffer_unreference(fb);
+   } else if (property == config->prop_in_fence_fd) {
+   if (state->fence)
+   return -EINVAL;
+
+   if (U642I64(val) == -1)
+   return 0;
+
+   state->fence = sync_file_get_fence(val);
+   if (!state->fence)
+   return -EINVAL;
+
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, val);
return drm_atomic_set_crtc_for_plane(state, crtc);
@@ -770,6 +782,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
 
if (property == config->prop_fb_id) {
*val = (state->fb) ? state->fb->base.id : 0;
+   } else if (property == config->prop_in_fence_fd) {
+   *val = -1;
} else if (property == config->prop_crtc_id) {
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->prop_crtc_x) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 75ad01d..caed870 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3076,6 +3076,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
 
if (state->fb)
drm_framebuffer_reference(state->fb);
+
+   state->fence = NULL;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
 
@@ -3114,6 +3116,9 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 {
if (state->fb)
drm_framebuffer_unreference(state->fb);
+
+   if (state->fence)
+   dma_fence_put(state->fence);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ce274ed..154e040 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -397,6 +397,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_fb_id = prop;
 
+   prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC,
+   "IN_FENCE_FD", -1, INT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_in_fence_fd = prop;
+
prop = drm_property_create_object(dev, 

[PATCH v8 0/3] drm: add explict fencing

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

New version of the DRM fences patches with all comments on v7 adressed. Please
refer to the cover letter[1] in a previous version to check for more details.

The changes since the last version can be seen in commit message on each patch.

Robert Foss managed to port Android's drm_hwcomposer to the new HWC2 API and
added support to fences. Current patches can be seen here:

https://git.collabora.com/cgit/user/robertfoss/drm_hwcomposer.git/log/?h=hwc2_fence_v1

He ran AOSP on top of padovan/fences kernel branch with full fence support on
qemu/virgl and msm db410c. That means we already have a working open source
userspace using the explicit fencing implementation.

Also i-g-t testing are available with all tests suggested in v7 included:

https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/log/

Please review!

Gustavo

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253822.html

---
Gustavo Padovan (3):
  drm/fence: add in-fences support
  drm/fence: add fence timeline to drm_crtc
  drm/fence: add out-fences support

 drivers/gpu/drm/Kconfig |   1 +
 drivers/gpu/drm/drm_atomic.c| 256 +---
 drivers/gpu/drm/drm_atomic_helper.c |   5 +
 drivers/gpu/drm/drm_crtc.c  |  45 +++
 drivers/gpu/drm/drm_plane.c |   1 +
 include/drm/drm_atomic.h|   1 +
 include/drm/drm_crtc.h  |  56 
 7 files changed, 320 insertions(+), 45 deletions(-)

-- 
2.5.5

[PATCH v8 3/3] drm/fence: add out-fences support

[Gustavo Padovan]

From: Gustavo Padovan 

Support DRM out-fences by creating a sync_file with a fence for each CRTC
that sets the OUT_FENCE_PTR property.

We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
the sync_file fd back to userspace.

The sync_file and fd are allocated/created before commit, but the
fd_install operation only happens after we know that commit succeed.

v2: Comment by Rob Clark:
- Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.

Comment by Daniel Vetter:
- Add clean up code for out_fences

v3: Comments by Daniel Vetter:
- create DRM_MODE_ATOMIC_EVENT_MASK
- userspace should fill out_fences_ptr with the crtc_ids for which
it wants fences back.

v4: Create OUT_FENCE_PTR properties and remove old approach.

v5: Comments by Brian Starkey:
- Remove extra fence_get() in atomic_ioctl()
- Check ret before iterating on the crtc_state
- check ret before fd_install
- set fence_state to NULL at the beginning
- check fence_state->out_fence_ptr before put_user()
- change order of fput() and put_unused_fd() on failure

 - Add access_ok() check to the out_fence_ptr received
 - Rebase after fence -> dma_fence rename
 - Store out_fence_ptr in the drm_atomic_state
 - Split crtc_setup_out_fence()
 - return -1 as out_fence with TEST_ONLY flag

v6: Comments by Daniel Vetter
- Add prepare/unprepare_crtc_signaling()
- move struct drm_out_fence_state to drm_atomic.c
- mark get_crtc_fence() as static

Comments by Brian Starkey
- proper set fence_ptr fence_state array
- isolate fence_idx increment

- improve error handling

v7: Comments by Daniel Vetter
- remove prefix from internal functions
- make out_fence_ptr an s64 pointer
- degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
- fix doc issues
- filter out OUT_FENCE_PTR == NULL and do fail in this case
- add complete_crtc_signalling()
- krealloc fence_state on demand

Comment by Brian Starkey
- remove unused crtc_state arg from get_out_fence()

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/drm_atomic.c | 242 +++
 drivers/gpu/drm/drm_crtc.c   |   8 ++
 include/drm/drm_atomic.h |   1 +
 include/drm/drm_crtc.h   |   6 ++
 4 files changed, 212 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8e26ad1..cd39f13 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
 }
 EXPORT_SYMBOL(drm_atomic_get_crtc_state);
 
+static void set_out_fence_for_crtc(struct drm_atomic_state *state,
+  struct drm_crtc *crtc, u64 __user *fence_ptr)
+{
+   state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
+}
+
+static u64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
+  struct drm_crtc *crtc)
+{
+   u64 __user *fence_ptr;
+
+   fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
+   state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
+
+   return fence_ptr;
+}
+
 /**
  * drm_atomic_set_mode_for_crtc - set mode for CRTC
  * @state: the CRTC whose incoming state to update
@@ -491,6 +508,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == config->prop_out_fence_ptr) {
+   s64 __user *fence_ptr = u64_to_user_ptr(val);
+
+   if (!fence_ptr)
+   return 0;
+
+   if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
+   return -EFAULT;
+
+   set_out_fence_for_crtc(state->state, crtc, fence_ptr);
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
@@ -533,6 +560,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? state->ctm->base.id : 0;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
+   else if (property == config->prop_out_fence_ptr)
+   *val = 0;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
@@ -1659,11 +1688,9 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
  */
 
 static struct drm_pending_vblank_event *create_vblank_event(
-   struct drm_device *dev, struct drm_file *file_priv,
-   struct dma_fence 

[PATCH v8 2/3] drm/fence: add fence timeline to drm_crtc

[Gustavo Padovan]

From: Gustavo Padovan 

Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.

v2: Comment by Daniel Stone:
- add BUG_ON() to fence_to_crtc() macro

v3: Comment by Ville Syrjälä
- Use more meaningful name as crtc timeline name

v4: Comments by Brian Starkey
- Use even more meaninful name for the crtc timeline
- add doc for timeline_name
Comment by Daniel Vetter
- use in-line style for comments

- rebase after fence -> dma_fence rename

v5: Comment by Daniel Vetter
- Add doc for drm_crtc_fence_ops

Signed-off-by: Gustavo Padovan 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 31 +++
 include/drm/drm_crtc.h | 45 +
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 154e040..9b9881b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -165,6 +165,32 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc)
 #endif
 }
 
+static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->dev->driver->name;
+}
+
+static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->timeline_name;
+}
+
+static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+const struct dma_fence_ops drm_crtc_fence_ops = {
+   .get_driver_name = drm_crtc_fence_get_driver_name,
+   .get_timeline_name = drm_crtc_fence_get_timeline_name,
+   .enable_signaling = drm_crtc_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
 /**
  * drm_crtc_init_with_planes - Initialise a new CRTC object with
  *specified primary and cursor planes.
@@ -222,6 +248,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
return -ENOMEM;
}
 
+   crtc->fence_context = dma_fence_context_alloc(1);
+   spin_lock_init(>fence_lock);
+   snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
+"CRTC:%d-%s", crtc->base.id, crtc->name);
+
crtc->base.properties = >properties;
 
list_add_tail(>head, >crtc_list);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 11780a9..0870de1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -32,6 +32,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -739,9 +741,52 @@ struct drm_crtc {
 */
struct drm_crtc_crc crc;
 #endif
+
+   /**
+* @fence_context:
+*
+* timeline context used for fence operations.
+*/
+   unsigned int fence_context;
+
+   /**
+* @fence_lock:
+*
+* spinlock to protect the fences in the fence_context.
+*/
+
+   spinlock_t fence_lock;
+   /**
+* @fence_seqno:
+*
+* Seqno variable used as monotonic counter for the fences
+* created on the CRTC's timeline.
+*/
+   unsigned long fence_seqno;
+
+   /**
+* @timeline_name:
+*
+* The name of the CRTC's fence timeline.
+*/
+   char timeline_name[32];
 };
 
 /**
+ * dma_crtc_fence_ops - fence ops for the drm_crtc timeline
+ *
+ * It contains the dma_fence_ops that should be called by the dma_fence
+ * code. CRTC core should use this ops when initializing fences.
+ */
+extern const struct dma_fence_ops drm_crtc_fence_ops;
+
+static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
+{
+   BUG_ON(fence->ops != _crtc_fence_ops);
+   return container_of(fence->lock, struct drm_crtc, fence_lock);
+}
+
+/**
  * struct drm_mode_set - new values for a CRTC config change
  * @fb: framebuffer to use for new config
  * @crtc: CRTC whose configuration we're about to change
-- 
2.5.5

[PATCH v8 1/3] drm/fence: add in-fences support

[Gustavo Padovan]

From: Gustavo Padovan 

There is now a new property called IN_FENCE_FD attached to every plane
state that receives sync_file fds from userspace via the atomic commit
IOCTL.

The fd is then translated to a fence (that may be a fence_array
subclass or just a normal fence) and then used by DRM to fence_wait() for
all fences in the sync_file to signal. So it only commits when all
framebuffers are ready to scanout.

v2: Comments by Daniel Vetter:
- remove set state->fence = NULL in destroy phase
- accept fence -1 as valid and just return 0
- do not call fence_get() - sync_file_fences_get() already calls it
- fence_put() if state->fence is already set, in case userspace
set the property more than once.

v3: WARN_ON if fence is set but state has no FB

v4: Comment from Maarten Lankhorst
- allow set fence with no related fb

v5: rename FENCE_FD to IN_FENCE_FD

v6: Comments by Daniel Vetter:
- rename plane_state->in_fence back to "fence"
- re-introduce WARN_ON if fence set but no fb

 - rebase after fence -> dma_fence rename

v7: Comments by Brian Starkey
- set state->fence to NULL when duplicating the state
- fail if IN_FENCE_FD was already set

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/Kconfig |  1 +
 drivers/gpu/drm/drm_atomic.c| 14 ++
 drivers/gpu/drm/drm_atomic_helper.c |  5 +
 drivers/gpu/drm/drm_crtc.c  |  6 ++
 drivers/gpu/drm/drm_plane.c |  1 +
 include/drm/drm_crtc.h  |  5 +
 6 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 25e8e37..360cb92 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+   select SYNC_FILE
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
  introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b096c16..8e26ad1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 
@@ -709,6 +710,17 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
drm_framebuffer_unreference(fb);
+   } else if (property == config->prop_in_fence_fd) {
+   if (state->fence)
+   return -EINVAL;
+
+   if (U642I64(val) == -1)
+   return 0;
+
+   state->fence = sync_file_get_fence(val);
+   if (!state->fence)
+   return -EINVAL;
+
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, val);
return drm_atomic_set_crtc_for_plane(state, crtc);
@@ -770,6 +782,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
 
if (property == config->prop_fb_id) {
*val = (state->fb) ? state->fb->base.id : 0;
+   } else if (property == config->prop_in_fence_fd) {
+   *val = -1;
} else if (property == config->prop_crtc_id) {
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->prop_crtc_x) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 75ad01d..caed870 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3076,6 +3076,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
 
if (state->fb)
drm_framebuffer_reference(state->fb);
+
+   state->fence = NULL;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
 
@@ -3114,6 +3116,9 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 {
if (state->fb)
drm_framebuffer_unreference(state->fb);
+
+   if (state->fence)
+   dma_fence_put(state->fence);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ce274ed..154e040 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -397,6 +397,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_fb_id = prop;
 
+   prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC,
+   "IN_FENCE_FD", -1, INT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_in_fence_fd = prop;
+
prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
"CRTC_ID", 

[PATCH v8 0/3] drm: add explict fencing

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

New version of the DRM fences patches with all comments on v7 adressed. Please
refer to the cover letter[1] in a previous version to check for more details.

The changes since the last version can be seen in commit message on each patch.

Robert Foss managed to port Android's drm_hwcomposer to the new HWC2 API and
added support to fences. Current patches can be seen here:

https://git.collabora.com/cgit/user/robertfoss/drm_hwcomposer.git/log/?h=hwc2_fence_v1

He ran AOSP on top of padovan/fences kernel branch with full fence support on
qemu/virgl and msm db410c. That means we already have a working open source
userspace using the explicit fencing implementation.

Also i-g-t testing are available with all tests suggested in v7 included:

https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/log/

Please review!

Gustavo

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253822.html

---
Gustavo Padovan (3):
  drm/fence: add in-fences support
  drm/fence: add fence timeline to drm_crtc
  drm/fence: add out-fences support

 drivers/gpu/drm/Kconfig |   1 +
 drivers/gpu/drm/drm_atomic.c| 256 +---
 drivers/gpu/drm/drm_atomic_helper.c |   5 +
 drivers/gpu/drm/drm_crtc.c  |  45 +++
 drivers/gpu/drm/drm_plane.c |   1 +
 include/drm/drm_atomic.h|   1 +
 include/drm/drm_crtc.h  |  56 
 7 files changed, 320 insertions(+), 45 deletions(-)

-- 
2.5.5

[PATCH v8 3/3] drm/fence: add out-fences support

[Gustavo Padovan]

From: Gustavo Padovan 

Support DRM out-fences by creating a sync_file with a fence for each CRTC
that sets the OUT_FENCE_PTR property.

We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
the sync_file fd back to userspace.

The sync_file and fd are allocated/created before commit, but the
fd_install operation only happens after we know that commit succeed.

v2: Comment by Rob Clark:
- Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.

Comment by Daniel Vetter:
- Add clean up code for out_fences

v3: Comments by Daniel Vetter:
- create DRM_MODE_ATOMIC_EVENT_MASK
- userspace should fill out_fences_ptr with the crtc_ids for which
it wants fences back.

v4: Create OUT_FENCE_PTR properties and remove old approach.

v5: Comments by Brian Starkey:
- Remove extra fence_get() in atomic_ioctl()
- Check ret before iterating on the crtc_state
- check ret before fd_install
- set fence_state to NULL at the beginning
- check fence_state->out_fence_ptr before put_user()
- change order of fput() and put_unused_fd() on failure

 - Add access_ok() check to the out_fence_ptr received
 - Rebase after fence -> dma_fence rename
 - Store out_fence_ptr in the drm_atomic_state
 - Split crtc_setup_out_fence()
 - return -1 as out_fence with TEST_ONLY flag

v6: Comments by Daniel Vetter
- Add prepare/unprepare_crtc_signaling()
- move struct drm_out_fence_state to drm_atomic.c
- mark get_crtc_fence() as static

Comments by Brian Starkey
- proper set fence_ptr fence_state array
- isolate fence_idx increment

- improve error handling

v7: Comments by Daniel Vetter
- remove prefix from internal functions
- make out_fence_ptr an s64 pointer
- degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
- fix doc issues
- filter out OUT_FENCE_PTR == NULL and do fail in this case
- add complete_crtc_signalling()
- krealloc fence_state on demand

Comment by Brian Starkey
- remove unused crtc_state arg from get_out_fence()

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/drm_atomic.c | 242 +++
 drivers/gpu/drm/drm_crtc.c   |   8 ++
 include/drm/drm_atomic.h |   1 +
 include/drm/drm_crtc.h   |   6 ++
 4 files changed, 212 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8e26ad1..cd39f13 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
 }
 EXPORT_SYMBOL(drm_atomic_get_crtc_state);
 
+static void set_out_fence_for_crtc(struct drm_atomic_state *state,
+  struct drm_crtc *crtc, u64 __user *fence_ptr)
+{
+   state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
+}
+
+static u64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
+  struct drm_crtc *crtc)
+{
+   u64 __user *fence_ptr;
+
+   fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
+   state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
+
+   return fence_ptr;
+}
+
 /**
  * drm_atomic_set_mode_for_crtc - set mode for CRTC
  * @state: the CRTC whose incoming state to update
@@ -491,6 +508,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == config->prop_out_fence_ptr) {
+   s64 __user *fence_ptr = u64_to_user_ptr(val);
+
+   if (!fence_ptr)
+   return 0;
+
+   if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
+   return -EFAULT;
+
+   set_out_fence_for_crtc(state->state, crtc, fence_ptr);
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
@@ -533,6 +560,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? state->ctm->base.id : 0;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
+   else if (property == config->prop_out_fence_ptr)
+   *val = 0;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
@@ -1659,11 +1688,9 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
  */
 
 static struct drm_pending_vblank_event *create_vblank_event(
-   struct drm_device *dev, struct drm_file *file_priv,
-   struct dma_fence *fence, uint64_t user_data)
+   struct drm_device *dev, 

[PATCH v4 1/6] kconfig: introduce the "imply" keyword

[Nicolas Pitre]

The "imply" keyword is a weak version of "select" where the target
config symbol can still be turned off, avoiding those pitfalls that come
with the "select" keyword.

This is useful e.g. with multiple drivers that want to indicate their
ability to hook into a secondary subsystem while allowing the user to
configure that subsystem out without also having to unset these drivers.

Currently, the same effect can almost be achieved with:

config DRIVER_A
tristate

config DRIVER_B
tristate

config DRIVER_C
tristate

config DRIVER_D
tristate

[...]

config SUBSYSTEM_X
tristate
default DRIVER_A || DRIVER_B || DRIVER_C || DRIVER_D || [...]

This is unwieldy to maintain especially with a large number of drivers.
Furthermore, there is no easy way to restrict the choice for SUBSYSTEM_X
to y or n, excluding m, when some drivers are built-in. The "select"
keyword allows for excluding m, but it excludes n as well. Hence
this "imply" keyword.  The above becomes:

config DRIVER_A
tristate
imply SUBSYSTEM_X

config DRIVER_B
tristate
imply SUBSYSTEM_X

[...]

config SUBSYSTEM_X
tristate

This is much cleaner, and way more flexible than "select". SUBSYSTEM_X
can still be configured out, and it can be set as a module when none of
the drivers are configured in or all of them are modular.

Signed-off-by: Nicolas Pitre 
Reviewed-by: Josh Triplett 
Acked-by: Richard Cochran 
Acked-by: Thomas Gleixner 
---
 Documentation/kbuild/kconfig-language.txt | 29 
 scripts/kconfig/expr.h|  2 ++
 scripts/kconfig/menu.c| 55 ++-
 scripts/kconfig/symbol.c  | 24 +-
 scripts/kconfig/zconf.gperf   |  1 +
 scripts/kconfig/zconf.y   | 16 +++--
 6 files changed, 108 insertions(+), 19 deletions(-)

diff --git a/Documentation/kbuild/kconfig-language.txt 
b/Documentation/kbuild/kconfig-language.txt
index 069fcb3eef..262722d886 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -113,6 +113,34 @@ applicable everywhere (see syntax).
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
 
+- weak reverse dependencies: "imply"  ["if" ]
+  This is similar to "select" as it enforces a lower limit on another
+  symbol except that the "implied" symbol's value may still be set to n
+  from a direct dependency or with a visible prompt.
+
+  Given the following example:
+
+  config FOO
+   tristate
+   imply BAZ
+
+  config BAZ
+   tristate
+   depends on BAR
+
+  The following values are possible:
+
+   FOO BAR BAZ's default   choice for BAZ
+   --- --- -   --
+   n   y   n   N/m/y
+   m   y   m   M/y/n
+   y   y   y   Y/n
+   y   n   *   N
+
+  This is useful e.g. with multiple drivers that want to indicate their
+  ability to hook into a secondary subsystem while allowing the user to
+  configure that subsystem out without also having to unset these drivers.
+
 - limiting menu display: "visible if" 
   This attribute is only applicable to menu blocks, if the condition is
   false, the menu block is not displayed to the user (the symbols
@@ -481,6 +509,7 @@ historical issues resolved through these different 
solutions.
   b) Match dependency semantics:
b1) Swap all "select FOO" to "depends on FOO" or,
b2) Swap all "depends on FOO" to "select FOO"
+  c) Consider the use of "imply" instead of "select"
 
 The resolution to a) can be tested with the sample Kconfig file
 Documentation/kbuild/Kconfig.recursion-issue-01 through the removal
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index 973b6f7333..a73f762c48 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -85,6 +85,7 @@ struct symbol {
struct property *prop;
struct expr_value dir_dep;
struct expr_value rev_dep;
+   struct expr_value implied;
 };
 
 #define for_all_symbols(i, sym) for (i = 0; i < SYMBOL_HASHSIZE; i++) for (sym 
= symbol_hash[i]; sym; sym = sym->next) if (sym->type != S_OTHER)
@@ -136,6 +137,7 @@ enum prop_type {
P_DEFAULT,  /* default y */
P_CHOICE,   /* choice value */
P_SELECT,   /* select BAR */
+   P_IMPLY,/* imply BAR */
P_RANGE,/* range 7..100 (for a symbol) */
P_ENV,  /* value from environment variable */
P_SYMBOL,   /* where a symbol is defined */
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index aed678e8a7..e9357931b4 100644
--- a/scripts/kconfig/menu.c
+++ 

[PATCH v4 6/6] posix-timers: make it configurable

[Nicolas Pitre]

Some embedded systems have no use for them.  This removes about
25KB from the kernel binary size when configured out.

Corresponding syscalls are routed to a stub logging the attempt to
use those syscalls which should be enough of a clue if they were
disabled without proper consideration. They are: timer_create,
timer_gettime: timer_getoverrun, timer_settime, timer_delete,
clock_adjtime, setitimer, getitimer, alarm.

The clock_settime, clock_gettime, clock_getres and clock_nanosleep
syscalls are replaced by simple wrappers compatible with CLOCK_REALTIME,
CLOCK_MONOTONIC and CLOCK_BOOTTIME only which should cover the vast
majority of use cases with very little code.

Signed-off-by: Nicolas Pitre 
Reviewed-by: Josh Triplett 
Acked-by: Richard Cochran 
Acked-by: Thomas Gleixner 
---
 arch/alpha/kernel/osf_sys.c |   8 +++
 drivers/char/Kconfig|   1 +
 drivers/ptp/Kconfig |   2 +-
 fs/exec.c   |   2 +
 init/Kconfig|  17 ++
 kernel/compat.c |   8 +++
 kernel/exit.c   |  11 +++-
 kernel/fork.c   |   2 +
 kernel/signal.c |   6 +++
 kernel/sys.c|   3 +-
 kernel/time/Makefile|  10 +++-
 kernel/time/alarmtimer.c|   6 ++-
 kernel/time/posix-stubs.c   | 123 
 kernel/time/timer.c |   3 +-
 security/selinux/hooks.c|  11 ++--
 15 files changed, 200 insertions(+), 13 deletions(-)
 create mode 100644 kernel/time/posix-stubs.c

diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index ffb93f499c..56e427c7aa 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1029,11 +1029,16 @@ SYSCALL_DEFINE2(osf_settimeofday, struct timeval32 
__user *, tv,
return do_sys_settimeofday(tv ?  : NULL, tz ?  : NULL);
 }
 
+asmlinkage long sys_ni_posix_timers(void);
+
 SYSCALL_DEFINE2(osf_getitimer, int, which, struct itimerval32 __user *, it)
 {
struct itimerval kit;
int error;
 
+   if (!IS_ENABLED(CONFIG_POSIX_TIMERS))
+   return sys_ni_posix_timers();
+
error = do_getitimer(which, );
if (!error && put_it32(it, ))
error = -EFAULT;
@@ -1047,6 +1052,9 @@ SYSCALL_DEFINE3(osf_setitimer, int, which, struct 
itimerval32 __user *, in,
struct itimerval kin, kout;
int error;
 
+   if (!IS_ENABLED(CONFIG_POSIX_TIMERS))
+   return sys_ni_posix_timers();
+
if (in) {
if (get_it32(, in))
return -EFAULT;
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index dcc09739a5..45ba878ae0 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -542,6 +542,7 @@ config HANGCHECK_TIMER
 config MMTIMER
tristate "MMTIMER Memory mapped RTC for SGI Altix"
depends on IA64_GENERIC || IA64_SGI_SN2
+   depends on POSIX_TIMERS
default y
help
  The mmtimer device allows direct userspace access to the
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index 0f7492f8ea..bdce332911 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -6,7 +6,7 @@ menu "PTP clock support"
 
 config PTP_1588_CLOCK
tristate "PTP clock support"
-   depends on NET
+   depends on NET && POSIX_TIMERS
select PPS
select NET_PTP_CLASSIFY
help
diff --git a/fs/exec.c b/fs/exec.c
index 6fcfb3f7b1..a67a172332 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1164,8 +1164,10 @@ static int de_thread(struct task_struct *tsk)
/* we have changed execution domain */
tsk->exit_signal = SIGCHLD;
 
+#ifdef CONFIG_POSIX_TIMERS
exit_itimers(sig);
flush_itimer_signals();
+#endif
 
if (atomic_read(>count) != 1) {
struct sighand_struct *newsighand;
diff --git a/init/Kconfig b/init/Kconfig
index 34407f15e6..456e0b8912 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1445,6 +1445,23 @@ config SYSCTL_SYSCALL
 
  If unsure say N here.
 
+config POSIX_TIMERS
+   bool "Posix Clocks & timers" if EXPERT
+   default y
+   help
+ This includes native support for POSIX timers to the kernel.
+ Some embedded systems have no use for them and therefore they
+ can be configured out to reduce the size of the kernel image.
+
+ When this option is disabled, the following syscalls won't be
+ available: timer_create, timer_gettime: timer_getoverrun,
+ timer_settime, timer_delete, clock_adjtime, getitimer,
+ setitimer, alarm. Furthermore, the clock_settime, clock_gettime,
+ clock_getres and clock_nanosleep syscalls will be limited to
+ CLOCK_REALTIME, CLOCK_MONOTONIC and CLOCK_BOOTTIME only.
+
+ If unsure say y.
+
 config KALLSYMS
 bool "Load all symbols for debugging/ksymoops" if EXPERT
 default y
diff --git 

[PATCH v4 3/6] ptp_clock: allow for it to be optional

[Nicolas Pitre]

In order to break the hard dependency between the PTP clock subsystem and
ethernet drivers capable of being clock providers, this patch provides
simple PTP stub functions to allow linkage of those drivers into the
kernel even when the PTP subsystem is configured out. Drivers must be
ready to accept NULL from ptp_clock_register() in that case.

And to make it possible for PTP to be configured out, the select statement
in those driver's Kconfig menu entries is converted to the new "imply"
statement. This way the PTP subsystem may have Kconfig dependencies of
its own, such as POSIX_TIMERS, without having to make those ethernet
drivers unavailable if POSIX timers are cconfigured out. And when support
for POSIX timers is selected again then the default config option for PTP
clock support will automatically be adjusted accordingly.

The pch_gbe driver is a bit special as it relies on extra code in
drivers/ptp/ptp_pch.c. Therefore we let the make process descend into
drivers/ptp/ even if PTP_1588_CLOCK is unselected.

Signed-off-by: Nicolas Pitre 
Reviewed-by: Josh Triplett 
Acked-by: Richard Cochran 
Acked-by: Edward Cree 
Acked-by: Thomas Gleixner 
---
 drivers/Makefile|  2 +-
 drivers/net/ethernet/adi/Kconfig|  2 +-
 drivers/net/ethernet/amd/Kconfig|  2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-main.c   |  6 ++-
 drivers/net/ethernet/broadcom/Kconfig   |  4 +-
 drivers/net/ethernet/cavium/Kconfig |  2 +-
 drivers/net/ethernet/freescale/Kconfig  |  2 +-
 drivers/net/ethernet/intel/Kconfig  | 10 ++--
 drivers/net/ethernet/mellanox/mlx4/Kconfig  |  2 +-
 drivers/net/ethernet/mellanox/mlx5/core/Kconfig |  2 +-
 drivers/net/ethernet/renesas/Kconfig|  2 +-
 drivers/net/ethernet/samsung/Kconfig|  2 +-
 drivers/net/ethernet/sfc/Kconfig|  2 +-
 drivers/net/ethernet/stmicro/stmmac/Kconfig |  2 +-
 drivers/net/ethernet/ti/Kconfig |  2 +-
 drivers/net/ethernet/tile/Kconfig   |  2 +-
 drivers/ptp/Kconfig |  8 +--
 include/linux/ptp_clock_kernel.h| 65 -
 18 files changed, 69 insertions(+), 50 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index f0afdfb3c7..8cfa1ff8f6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_INPUT) += input/
 obj-$(CONFIG_RTC_LIB)  += rtc/
 obj-y  += i2c/ media/
 obj-$(CONFIG_PPS)  += pps/
-obj-$(CONFIG_PTP_1588_CLOCK)   += ptp/
+obj-y  += ptp/
 obj-$(CONFIG_W1)   += w1/
 obj-y  += power/
 obj-$(CONFIG_HWMON)+= hwmon/
diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig
index 6b94ba6103..98cc8f5350 100644
--- a/drivers/net/ethernet/adi/Kconfig
+++ b/drivers/net/ethernet/adi/Kconfig
@@ -58,7 +58,7 @@ config BFIN_RX_DESC_NUM
 config BFIN_MAC_USE_HWSTAMP
bool "Use IEEE 1588 hwstamp"
depends on BFIN_MAC && BF518
-   select PTP_1588_CLOCK
+   imply PTP_1588_CLOCK
default y
---help---
  To support the IEEE 1588 Precision Time Protocol (PTP), select y here
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 0038709fd3..713ea7ad22 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -177,7 +177,7 @@ config AMD_XGBE
depends on ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
-   select PTP_1588_CLOCK
+   imply PTP_1588_CLOCK
---help---
  This driver supports the AMD 10GbE Ethernet device found on an
  AMD SoC.
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c 
b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
index 9de078819a..e10e569c0d 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
@@ -773,7 +773,8 @@ static int xgbe_probe(struct platform_device *pdev)
goto err_wq;
}
 
-   xgbe_ptp_register(pdata);
+   if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK))
+   xgbe_ptp_register(pdata);
 
xgbe_debugfs_init(pdata);
 
@@ -812,7 +813,8 @@ static int xgbe_remove(struct platform_device *pdev)
 
xgbe_debugfs_exit(pdata);
 
-   xgbe_ptp_unregister(pdata);
+   if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK))
+   xgbe_ptp_unregister(pdata);
 
flush_workqueue(pdata->an_workqueue);
destroy_workqueue(pdata->an_workqueue);
diff --git a/drivers/net/ethernet/broadcom/Kconfig 
b/drivers/net/ethernet/broadcom/Kconfig
index bd8c80c0b7..6a8d74aeb6 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -110,7 +110,7 @@ config TIGON3

[PATCH v4 1/6] kconfig: introduce the "imply" keyword

[Nicolas Pitre]

The "imply" keyword is a weak version of "select" where the target
config symbol can still be turned off, avoiding those pitfalls that come
with the "select" keyword.

This is useful e.g. with multiple drivers that want to indicate their
ability to hook into a secondary subsystem while allowing the user to
configure that subsystem out without also having to unset these drivers.

Currently, the same effect can almost be achieved with:

config DRIVER_A
tristate

config DRIVER_B
tristate

config DRIVER_C
tristate

config DRIVER_D
tristate

[...]

config SUBSYSTEM_X
tristate
default DRIVER_A || DRIVER_B || DRIVER_C || DRIVER_D || [...]

This is unwieldy to maintain especially with a large number of drivers.
Furthermore, there is no easy way to restrict the choice for SUBSYSTEM_X
to y or n, excluding m, when some drivers are built-in. The "select"
keyword allows for excluding m, but it excludes n as well. Hence
this "imply" keyword.  The above becomes:

config DRIVER_A
tristate
imply SUBSYSTEM_X

config DRIVER_B
tristate
imply SUBSYSTEM_X

[...]

config SUBSYSTEM_X
tristate

This is much cleaner, and way more flexible than "select". SUBSYSTEM_X
can still be configured out, and it can be set as a module when none of
the drivers are configured in or all of them are modular.

Signed-off-by: Nicolas Pitre 
Reviewed-by: Josh Triplett 
Acked-by: Richard Cochran 
Acked-by: Thomas Gleixner 
---
 Documentation/kbuild/kconfig-language.txt | 29 
 scripts/kconfig/expr.h|  2 ++
 scripts/kconfig/menu.c| 55 ++-
 scripts/kconfig/symbol.c  | 24 +-
 scripts/kconfig/zconf.gperf   |  1 +
 scripts/kconfig/zconf.y   | 16 +++--
 6 files changed, 108 insertions(+), 19 deletions(-)

diff --git a/Documentation/kbuild/kconfig-language.txt 
b/Documentation/kbuild/kconfig-language.txt
index 069fcb3eef..262722d886 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -113,6 +113,34 @@ applicable everywhere (see syntax).
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
 
+- weak reverse dependencies: "imply"  ["if" ]
+  This is similar to "select" as it enforces a lower limit on another
+  symbol except that the "implied" symbol's value may still be set to n
+  from a direct dependency or with a visible prompt.
+
+  Given the following example:
+
+  config FOO
+   tristate
+   imply BAZ
+
+  config BAZ
+   tristate
+   depends on BAR
+
+  The following values are possible:
+
+   FOO BAR BAZ's default   choice for BAZ
+   --- --- -   --
+   n   y   n   N/m/y
+   m   y   m   M/y/n
+   y   y   y   Y/n
+   y   n   *   N
+
+  This is useful e.g. with multiple drivers that want to indicate their
+  ability to hook into a secondary subsystem while allowing the user to
+  configure that subsystem out without also having to unset these drivers.
+
 - limiting menu display: "visible if" 
   This attribute is only applicable to menu blocks, if the condition is
   false, the menu block is not displayed to the user (the symbols
@@ -481,6 +509,7 @@ historical issues resolved through these different 
solutions.
   b) Match dependency semantics:
b1) Swap all "select FOO" to "depends on FOO" or,
b2) Swap all "depends on FOO" to "select FOO"
+  c) Consider the use of "imply" instead of "select"
 
 The resolution to a) can be tested with the sample Kconfig file
 Documentation/kbuild/Kconfig.recursion-issue-01 through the removal
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index 973b6f7333..a73f762c48 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -85,6 +85,7 @@ struct symbol {
struct property *prop;
struct expr_value dir_dep;
struct expr_value rev_dep;
+   struct expr_value implied;
 };
 
 #define for_all_symbols(i, sym) for (i = 0; i < SYMBOL_HASHSIZE; i++) for (sym 
= symbol_hash[i]; sym; sym = sym->next) if (sym->type != S_OTHER)
@@ -136,6 +137,7 @@ enum prop_type {
P_DEFAULT,  /* default y */
P_CHOICE,   /* choice value */
P_SELECT,   /* select BAR */
+   P_IMPLY,/* imply BAR */
P_RANGE,/* range 7..100 (for a symbol) */
P_ENV,  /* value from environment variable */
P_SYMBOL,   /* where a symbol is defined */
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index aed678e8a7..e9357931b4 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -233,6 +233,8 @@ static void sym_check_prop(struct symbol 

[PATCH v4 6/6] posix-timers: make it configurable

[Nicolas Pitre]

Some embedded systems have no use for them.  This removes about
25KB from the kernel binary size when configured out.

Corresponding syscalls are routed to a stub logging the attempt to
use those syscalls which should be enough of a clue if they were
disabled without proper consideration. They are: timer_create,
timer_gettime: timer_getoverrun, timer_settime, timer_delete,
clock_adjtime, setitimer, getitimer, alarm.

The clock_settime, clock_gettime, clock_getres and clock_nanosleep
syscalls are replaced by simple wrappers compatible with CLOCK_REALTIME,
CLOCK_MONOTONIC and CLOCK_BOOTTIME only which should cover the vast
majority of use cases with very little code.

Signed-off-by: Nicolas Pitre 
Reviewed-by: Josh Triplett 
Acked-by: Richard Cochran 
Acked-by: Thomas Gleixner 
---
 arch/alpha/kernel/osf_sys.c |   8 +++
 drivers/char/Kconfig|   1 +
 drivers/ptp/Kconfig |   2 +-
 fs/exec.c   |   2 +
 init/Kconfig|  17 ++
 kernel/compat.c |   8 +++
 kernel/exit.c   |  11 +++-
 kernel/fork.c   |   2 +
 kernel/signal.c |   6 +++
 kernel/sys.c|   3 +-
 kernel/time/Makefile|  10 +++-
 kernel/time/alarmtimer.c|   6 ++-
 kernel/time/posix-stubs.c   | 123 
 kernel/time/timer.c |   3 +-
 security/selinux/hooks.c|  11 ++--
 15 files changed, 200 insertions(+), 13 deletions(-)
 create mode 100644 kernel/time/posix-stubs.c

diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index ffb93f499c..56e427c7aa 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1029,11 +1029,16 @@ SYSCALL_DEFINE2(osf_settimeofday, struct timeval32 
__user *, tv,
return do_sys_settimeofday(tv ?  : NULL, tz ?  : NULL);
 }
 
+asmlinkage long sys_ni_posix_timers(void);
+
 SYSCALL_DEFINE2(osf_getitimer, int, which, struct itimerval32 __user *, it)
 {
struct itimerval kit;
int error;
 
+   if (!IS_ENABLED(CONFIG_POSIX_TIMERS))
+   return sys_ni_posix_timers();
+
error = do_getitimer(which, );
if (!error && put_it32(it, ))
error = -EFAULT;
@@ -1047,6 +1052,9 @@ SYSCALL_DEFINE3(osf_setitimer, int, which, struct 
itimerval32 __user *, in,
struct itimerval kin, kout;
int error;
 
+   if (!IS_ENABLED(CONFIG_POSIX_TIMERS))
+   return sys_ni_posix_timers();
+
if (in) {
if (get_it32(, in))
return -EFAULT;
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index dcc09739a5..45ba878ae0 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -542,6 +542,7 @@ config HANGCHECK_TIMER
 config MMTIMER
tristate "MMTIMER Memory mapped RTC for SGI Altix"
depends on IA64_GENERIC || IA64_SGI_SN2
+   depends on POSIX_TIMERS
default y
help
  The mmtimer device allows direct userspace access to the
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index 0f7492f8ea..bdce332911 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -6,7 +6,7 @@ menu "PTP clock support"
 
 config PTP_1588_CLOCK
tristate "PTP clock support"
-   depends on NET
+   depends on NET && POSIX_TIMERS
select PPS
select NET_PTP_CLASSIFY
help
diff --git a/fs/exec.c b/fs/exec.c
index 6fcfb3f7b1..a67a172332 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1164,8 +1164,10 @@ static int de_thread(struct task_struct *tsk)
/* we have changed execution domain */
tsk->exit_signal = SIGCHLD;
 
+#ifdef CONFIG_POSIX_TIMERS
exit_itimers(sig);
flush_itimer_signals();
+#endif
 
if (atomic_read(>count) != 1) {
struct sighand_struct *newsighand;
diff --git a/init/Kconfig b/init/Kconfig
index 34407f15e6..456e0b8912 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1445,6 +1445,23 @@ config SYSCTL_SYSCALL
 
  If unsure say N here.
 
+config POSIX_TIMERS
+   bool "Posix Clocks & timers" if EXPERT
+   default y
+   help
+ This includes native support for POSIX timers to the kernel.
+ Some embedded systems have no use for them and therefore they
+ can be configured out to reduce the size of the kernel image.
+
+ When this option is disabled, the following syscalls won't be
+ available: timer_create, timer_gettime: timer_getoverrun,
+ timer_settime, timer_delete, clock_adjtime, getitimer,
+ setitimer, alarm. Furthermore, the clock_settime, clock_gettime,
+ clock_getres and clock_nanosleep syscalls will be limited to
+ CLOCK_REALTIME, CLOCK_MONOTONIC and CLOCK_BOOTTIME only.
+
+ If unsure say y.
+
 config KALLSYMS
 bool "Load all symbols for debugging/ksymoops" if EXPERT
 default y
diff --git a/kernel/compat.c b/kernel/compat.c
index 333d364be2..b3a047f208 100644
--- 

[PATCH v4 3/6] ptp_clock: allow for it to be optional

[Nicolas Pitre]

In order to break the hard dependency between the PTP clock subsystem and
ethernet drivers capable of being clock providers, this patch provides
simple PTP stub functions to allow linkage of those drivers into the
kernel even when the PTP subsystem is configured out. Drivers must be
ready to accept NULL from ptp_clock_register() in that case.

And to make it possible for PTP to be configured out, the select statement
in those driver's Kconfig menu entries is converted to the new "imply"
statement. This way the PTP subsystem may have Kconfig dependencies of
its own, such as POSIX_TIMERS, without having to make those ethernet
drivers unavailable if POSIX timers are cconfigured out. And when support
for POSIX timers is selected again then the default config option for PTP
clock support will automatically be adjusted accordingly.

The pch_gbe driver is a bit special as it relies on extra code in
drivers/ptp/ptp_pch.c. Therefore we let the make process descend into
drivers/ptp/ even if PTP_1588_CLOCK is unselected.

Signed-off-by: Nicolas Pitre 
Reviewed-by: Josh Triplett 
Acked-by: Richard Cochran 
Acked-by: Edward Cree 
Acked-by: Thomas Gleixner 
---
 drivers/Makefile|  2 +-
 drivers/net/ethernet/adi/Kconfig|  2 +-
 drivers/net/ethernet/amd/Kconfig|  2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-main.c   |  6 ++-
 drivers/net/ethernet/broadcom/Kconfig   |  4 +-
 drivers/net/ethernet/cavium/Kconfig |  2 +-
 drivers/net/ethernet/freescale/Kconfig  |  2 +-
 drivers/net/ethernet/intel/Kconfig  | 10 ++--
 drivers/net/ethernet/mellanox/mlx4/Kconfig  |  2 +-
 drivers/net/ethernet/mellanox/mlx5/core/Kconfig |  2 +-
 drivers/net/ethernet/renesas/Kconfig|  2 +-
 drivers/net/ethernet/samsung/Kconfig|  2 +-
 drivers/net/ethernet/sfc/Kconfig|  2 +-
 drivers/net/ethernet/stmicro/stmmac/Kconfig |  2 +-
 drivers/net/ethernet/ti/Kconfig |  2 +-
 drivers/net/ethernet/tile/Kconfig   |  2 +-
 drivers/ptp/Kconfig |  8 +--
 include/linux/ptp_clock_kernel.h| 65 -
 18 files changed, 69 insertions(+), 50 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index f0afdfb3c7..8cfa1ff8f6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_INPUT) += input/
 obj-$(CONFIG_RTC_LIB)  += rtc/
 obj-y  += i2c/ media/
 obj-$(CONFIG_PPS)  += pps/
-obj-$(CONFIG_PTP_1588_CLOCK)   += ptp/
+obj-y  += ptp/
 obj-$(CONFIG_W1)   += w1/
 obj-y  += power/
 obj-$(CONFIG_HWMON)+= hwmon/
diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig
index 6b94ba6103..98cc8f5350 100644
--- a/drivers/net/ethernet/adi/Kconfig
+++ b/drivers/net/ethernet/adi/Kconfig
@@ -58,7 +58,7 @@ config BFIN_RX_DESC_NUM
 config BFIN_MAC_USE_HWSTAMP
bool "Use IEEE 1588 hwstamp"
depends on BFIN_MAC && BF518
-   select PTP_1588_CLOCK
+   imply PTP_1588_CLOCK
default y
---help---
  To support the IEEE 1588 Precision Time Protocol (PTP), select y here
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 0038709fd3..713ea7ad22 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -177,7 +177,7 @@ config AMD_XGBE
depends on ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
-   select PTP_1588_CLOCK
+   imply PTP_1588_CLOCK
---help---
  This driver supports the AMD 10GbE Ethernet device found on an
  AMD SoC.
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c 
b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
index 9de078819a..e10e569c0d 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
@@ -773,7 +773,8 @@ static int xgbe_probe(struct platform_device *pdev)
goto err_wq;
}
 
-   xgbe_ptp_register(pdata);
+   if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK))
+   xgbe_ptp_register(pdata);
 
xgbe_debugfs_init(pdata);
 
@@ -812,7 +813,8 @@ static int xgbe_remove(struct platform_device *pdev)
 
xgbe_debugfs_exit(pdata);
 
-   xgbe_ptp_unregister(pdata);
+   if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK))
+   xgbe_ptp_unregister(pdata);
 
flush_workqueue(pdata->an_workqueue);
destroy_workqueue(pdata->an_workqueue);
diff --git a/drivers/net/ethernet/broadcom/Kconfig 
b/drivers/net/ethernet/broadcom/Kconfig
index bd8c80c0b7..6a8d74aeb6 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -110,7 +110,7 @@ config TIGON3
depends on PCI
select PHYLIB
select HWMON
-   select PTP_1588_CLOCK
+   

[PATCH v4 2/6] kconfig: regenerate *.c_shipped files after previous changes

[Nicolas Pitre]

Signed-off-by: Nicolas Pitre 
---
 scripts/kconfig/zconf.hash.c_shipped |   30 +-
 scripts/kconfig/zconf.tab.c_shipped  | 1581 --
 2 files changed, 753 insertions(+), 858 deletions(-)

diff --git a/scripts/kconfig/zconf.hash.c_shipped 
b/scripts/kconfig/zconf.hash.c_shipped
index 360a62df2b..d51b15de07 100644
--- a/scripts/kconfig/zconf.hash.c_shipped
+++ b/scripts/kconfig/zconf.hash.c_shipped
@@ -55,10 +55,10 @@ kconf_id_hash (register const char *str, register unsigned 
int len)
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
-  73, 73, 73, 73, 73, 73, 73,  5, 25, 25,
+  73, 73, 73, 73, 73, 73, 73, 10, 25, 25,
0,  0,  0,  5,  0,  0, 73, 73,  5,  0,
   10,  5, 45, 73, 20, 20,  0, 15, 15, 73,
-  20,  5, 73, 73, 73, 73, 73, 73, 73, 73,
+  20,  0, 73, 73, 73, 73, 73, 73, 73, 73,
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
@@ -120,6 +120,7 @@ struct kconf_id_strings_t
 char kconf_id_strings_str43[sizeof("hex")];
 char kconf_id_strings_str46[sizeof("config")];
 char kconf_id_strings_str47[sizeof("boolean")];
+char kconf_id_strings_str50[sizeof("imply")];
 char kconf_id_strings_str51[sizeof("string")];
 char kconf_id_strings_str54[sizeof("help")];
 char kconf_id_strings_str56[sizeof("prompt")];
@@ -157,6 +158,7 @@ static const struct kconf_id_strings_t 
kconf_id_strings_contents =
 "hex",
 "config",
 "boolean",
+"imply",
 "string",
 "help",
 "prompt",
@@ -174,7 +176,7 @@ kconf_id_lookup (register const char *str, register 
unsigned int len)
 {
   enum
 {
-  TOTAL_KEYWORDS = 34,
+  TOTAL_KEYWORDS = 35,
   MIN_WORD_LENGTH = 2,
   MAX_WORD_LENGTH = 14,
   MIN_HASH_VALUE = 2,
@@ -205,15 +207,15 @@ kconf_id_lookup (register const char *str, register 
unsigned int len)
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str12,   
T_DEFAULT,  TF_COMMAND, S_TRISTATE},
 #line 36 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str13,   
T_DEFAULT,  TF_COMMAND, S_BOOLEAN},
-#line 46 "scripts/kconfig/zconf.gperf"
+#line 47 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str14,   
T_OPT_DEFCONFIG_LIST,TF_OPTION},
   {-1}, {-1},
-#line 44 "scripts/kconfig/zconf.gperf"
+#line 45 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str17,   
T_ON,   TF_PARAM},
 #line 29 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str18,   
T_OPTIONAL, TF_COMMAND},
   {-1}, {-1},
-#line 43 "scripts/kconfig/zconf.gperf"
+#line 44 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str21,   
T_OPTION,   TF_COMMAND},
 #line 17 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str22,   
T_ENDMENU,  TF_COMMAND},
@@ -223,9 +225,9 @@ kconf_id_lookup (register const char *str, register 
unsigned int len)
 #line 23 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str25,   
T_MENUCONFIG,   TF_COMMAND},
   {-1},
-#line 45 "scripts/kconfig/zconf.gperf"
+#line 46 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str27,   
T_OPT_MODULES,  TF_OPTION},
-#line 48 "scripts/kconfig/zconf.gperf"
+#line 49 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str28,   
T_OPT_ALLNOCONFIG_Y,TF_OPTION},
 #line 16 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str29,   
T_MENU, TF_COMMAND},
@@ -234,10 +236,10 @@ kconf_id_lookup (register const char *str, register 
unsigned int len)
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str31,   
T_SELECT,   TF_COMMAND},
 #line 21 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str32,   
T_COMMENT,  TF_COMMAND},
-#line 47 "scripts/kconfig/zconf.gperf"
+#line 48 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str33,   
T_OPT_ENV,  TF_OPTION},
   {-1},
-#line 41 "scripts/kconfig/zconf.gperf"
+#line 42 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str35,   
T_RANGE,TF_COMMAND},
 #line 19 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str36,   
T_CHOICE,   TF_COMMAND},
@@ -247,7 +249,7 @@ 

[PATCH v4 2/6] kconfig: regenerate *.c_shipped files after previous changes

[Nicolas Pitre]

Signed-off-by: Nicolas Pitre 
---
 scripts/kconfig/zconf.hash.c_shipped |   30 +-
 scripts/kconfig/zconf.tab.c_shipped  | 1581 --
 2 files changed, 753 insertions(+), 858 deletions(-)

diff --git a/scripts/kconfig/zconf.hash.c_shipped 
b/scripts/kconfig/zconf.hash.c_shipped
index 360a62df2b..d51b15de07 100644
--- a/scripts/kconfig/zconf.hash.c_shipped
+++ b/scripts/kconfig/zconf.hash.c_shipped
@@ -55,10 +55,10 @@ kconf_id_hash (register const char *str, register unsigned 
int len)
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
-  73, 73, 73, 73, 73, 73, 73,  5, 25, 25,
+  73, 73, 73, 73, 73, 73, 73, 10, 25, 25,
0,  0,  0,  5,  0,  0, 73, 73,  5,  0,
   10,  5, 45, 73, 20, 20,  0, 15, 15, 73,
-  20,  5, 73, 73, 73, 73, 73, 73, 73, 73,
+  20,  0, 73, 73, 73, 73, 73, 73, 73, 73,
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
   73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
@@ -120,6 +120,7 @@ struct kconf_id_strings_t
 char kconf_id_strings_str43[sizeof("hex")];
 char kconf_id_strings_str46[sizeof("config")];
 char kconf_id_strings_str47[sizeof("boolean")];
+char kconf_id_strings_str50[sizeof("imply")];
 char kconf_id_strings_str51[sizeof("string")];
 char kconf_id_strings_str54[sizeof("help")];
 char kconf_id_strings_str56[sizeof("prompt")];
@@ -157,6 +158,7 @@ static const struct kconf_id_strings_t 
kconf_id_strings_contents =
 "hex",
 "config",
 "boolean",
+"imply",
 "string",
 "help",
 "prompt",
@@ -174,7 +176,7 @@ kconf_id_lookup (register const char *str, register 
unsigned int len)
 {
   enum
 {
-  TOTAL_KEYWORDS = 34,
+  TOTAL_KEYWORDS = 35,
   MIN_WORD_LENGTH = 2,
   MAX_WORD_LENGTH = 14,
   MIN_HASH_VALUE = 2,
@@ -205,15 +207,15 @@ kconf_id_lookup (register const char *str, register 
unsigned int len)
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str12,   
T_DEFAULT,  TF_COMMAND, S_TRISTATE},
 #line 36 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str13,   
T_DEFAULT,  TF_COMMAND, S_BOOLEAN},
-#line 46 "scripts/kconfig/zconf.gperf"
+#line 47 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str14,   
T_OPT_DEFCONFIG_LIST,TF_OPTION},
   {-1}, {-1},
-#line 44 "scripts/kconfig/zconf.gperf"
+#line 45 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str17,   
T_ON,   TF_PARAM},
 #line 29 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str18,   
T_OPTIONAL, TF_COMMAND},
   {-1}, {-1},
-#line 43 "scripts/kconfig/zconf.gperf"
+#line 44 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str21,   
T_OPTION,   TF_COMMAND},
 #line 17 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str22,   
T_ENDMENU,  TF_COMMAND},
@@ -223,9 +225,9 @@ kconf_id_lookup (register const char *str, register 
unsigned int len)
 #line 23 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str25,   
T_MENUCONFIG,   TF_COMMAND},
   {-1},
-#line 45 "scripts/kconfig/zconf.gperf"
+#line 46 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str27,   
T_OPT_MODULES,  TF_OPTION},
-#line 48 "scripts/kconfig/zconf.gperf"
+#line 49 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str28,   
T_OPT_ALLNOCONFIG_Y,TF_OPTION},
 #line 16 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str29,   
T_MENU, TF_COMMAND},
@@ -234,10 +236,10 @@ kconf_id_lookup (register const char *str, register 
unsigned int len)
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str31,   
T_SELECT,   TF_COMMAND},
 #line 21 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str32,   
T_COMMENT,  TF_COMMAND},
-#line 47 "scripts/kconfig/zconf.gperf"
+#line 48 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str33,   
T_OPT_ENV,  TF_OPTION},
   {-1},
-#line 41 "scripts/kconfig/zconf.gperf"
+#line 42 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str35,   
T_RANGE,TF_COMMAND},
 #line 19 "scripts/kconfig/zconf.gperf"
   {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str36,   
T_CHOICE,   TF_COMMAND},
@@ -247,7 +249,7 @@ kconf_id_lookup (register const 

[PATCH v4 5/6] posix_cpu_timers_exit: wrong place to collect entropy

[Nicolas Pitre]

There is no logical relation between add_device_randomness() and
posix_cpu_timers_exit(). Let's move the former to where the later
is called. This way, when posix-cpu-timers.c is compiled out, there
is no need to worry about not losing a call to add_device_randomness().

Signed-off-by: Nicolas Pitre 
---
 kernel/exit.c  | 4 
 kernel/time/posix-cpu-timers.c | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 9d68c45ebb..d16bcdd89d 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -54,6 +54,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -116,6 +117,9 @@ static void __exit_signal(struct task_struct *tsk)
sig->curr_target = next_thread(tsk);
}
 
+   add_device_randomness((const void*) >se.sum_exec_runtime,
+ sizeof(unsigned long long));
+
/*
 * Accumulate here the counters for all threads as they die. We could
 * skip the group leader because it is the last user of signal_struct,
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 39008d7892..e582f20f47 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -447,10 +446,7 @@ static void cleanup_timers(struct list_head *head)
  */
 void posix_cpu_timers_exit(struct task_struct *tsk)
 {
-   add_device_randomness((const void*) >se.sum_exec_runtime,
-   sizeof(unsigned long long));
cleanup_timers(tsk->cpu_timers);
-
 }
 void posix_cpu_timers_exit_group(struct task_struct *tsk)
 {
-- 
2.7.4

[PATCH v4 5/6] posix_cpu_timers_exit: wrong place to collect entropy

[Nicolas Pitre]

There is no logical relation between add_device_randomness() and
posix_cpu_timers_exit(). Let's move the former to where the later
is called. This way, when posix-cpu-timers.c is compiled out, there
is no need to worry about not losing a call to add_device_randomness().

Signed-off-by: Nicolas Pitre 
---
 kernel/exit.c  | 4 
 kernel/time/posix-cpu-timers.c | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 9d68c45ebb..d16bcdd89d 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -54,6 +54,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -116,6 +117,9 @@ static void __exit_signal(struct task_struct *tsk)
sig->curr_target = next_thread(tsk);
}
 
+   add_device_randomness((const void*) >se.sum_exec_runtime,
+ sizeof(unsigned long long));
+
/*
 * Accumulate here the counters for all threads as they die. We could
 * skip the group leader because it is the last user of signal_struct,
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 39008d7892..e582f20f47 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -447,10 +446,7 @@ static void cleanup_timers(struct list_head *head)
  */
 void posix_cpu_timers_exit(struct task_struct *tsk)
 {
-   add_device_randomness((const void*) >se.sum_exec_runtime,
-   sizeof(unsigned long long));
cleanup_timers(tsk->cpu_timers);
-
 }
 void posix_cpu_timers_exit_group(struct task_struct *tsk)
 {
-- 
2.7.4

[PATCH v4 0/6] make POSIX timers optional with some Kconfig help

[Nicolas Pitre]

Many embedded systems don't need the full POSIX timer support.
Configuring them out provides a nice kernel image size reduction.

When POSIX timers are configured out, the PTP clock subsystem should be
left out as well. However a bunch of ethernet drivers currently *select*
the later in their Kconfig entries. Therefore some more work was needed
to break that hard dependency from those drivers without preventing their
usage altogether.

Therefore this series also includes kconfig changes to implement a new
keyword to express some reverse dependencies like "select" does, named
"imply", and still allowing for the target config symbol to be disabled
if the user or a direct dependency says so.

At this point I'd like to gather ACKs especially from people in the "To"
field. Ideally this would need to go upstream as a single series to avoid
cross subsystem dependency issues.  So far it was suggested that this could
go via the kbuild tree. Given the end goal and the included timer cleanup
patches I'd lean towards the timer tree but any tree would suit me just
as well.

This is also available here for those who prefer a git tree:
git://git.linaro.org/people/nicolas.pitre/linux/ configurable_posix_timers

Changes from v3:

- Added a patch to move sys_alarm to itimer.c where the support code lives.
- Added a patch to move entropy collection out of posix-cpu-timers.c.
- Remove itimer as well when POSIX_TIMERS=n as they rely on code already
  removed. This means the getitimer, setitimer and alarm syscalls are also
  stubbed out in that case.
- Reverted the addition of empty timer stubs from posix-timers.h. Since
  there is only a few callers, it's better to conditionalize call sites
  instead, and get a link error if some were missed. Easier to clearly
  ponder the implications that way.
- Collected more ACKs.

Changes from v2:

- Dropped the patch adding the "suggest" keyword as nothing uses it.
  Requested by Paul Bolle.
- Various documentation and commit log clarifications, prompted also
  by Paul Bolle.
- Collected more ACKs.

Changes from v1:

- added "suggest" to kconfig for completeness
- various typo fixes
- small "imply" effect visibility fix

The bulk of the diffstat comes from the kconfig lex parser regeneration.

Diffstat:

 Documentation/kbuild/kconfig-language.txt   |   29 +
 arch/alpha/kernel/osf_sys.c |8 +
 drivers/Makefile|2 +-
 drivers/char/Kconfig|1 +
 drivers/net/ethernet/adi/Kconfig|2 +-
 drivers/net/ethernet/amd/Kconfig|2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-main.c   |6 +-
 drivers/net/ethernet/broadcom/Kconfig   |4 +-
 drivers/net/ethernet/cavium/Kconfig |2 +-
 drivers/net/ethernet/freescale/Kconfig  |2 +-
 drivers/net/ethernet/intel/Kconfig  |   10 +-
 drivers/net/ethernet/mellanox/mlx4/Kconfig  |2 +-
 drivers/net/ethernet/mellanox/mlx5/core/Kconfig |2 +-
 drivers/net/ethernet/renesas/Kconfig|2 +-
 drivers/net/ethernet/samsung/Kconfig|2 +-
 drivers/net/ethernet/sfc/Kconfig|2 +-
 drivers/net/ethernet/stmicro/stmmac/Kconfig |2 +-
 drivers/net/ethernet/ti/Kconfig |2 +-
 drivers/net/ethernet/tile/Kconfig   |2 +-
 drivers/ptp/Kconfig |   10 +-
 fs/exec.c   |2 +
 include/linux/ptp_clock_kernel.h|   65 +-
 include/linux/time.h|2 -
 init/Kconfig|   17 +
 kernel/compat.c |8 +
 kernel/exit.c   |   15 +-
 kernel/fork.c   |2 +
 kernel/signal.c |6 +
 kernel/sys.c|3 +-
 kernel/time/Makefile|   10 +-
 kernel/time/alarmtimer.c|6 +-
 kernel/time/itimer.c|   15 +-
 kernel/time/posix-cpu-timers.c  |4 -
 kernel/time/posix-stubs.c   |  123 ++
 kernel/time/timer.c |   16 +-
 scripts/kconfig/expr.h  |2 +
 scripts/kconfig/menu.c  |   55 +-
 scripts/kconfig/symbol.c|   24 +-
 scripts/kconfig/zconf.gperf |1 +
 scripts/kconfig/zconf.hash.c_shipped|   30 +-
 scripts/kconfig/zconf.tab.c_shipped | 1581 +++
 scripts/kconfig/zconf.y |   16 +-
 security/selinux/hooks.c|   11 +-
 43 files changed, 1148 insertions(+), 960 deletions(-)

[PATCH v4 0/6] make POSIX timers optional with some Kconfig help

[Nicolas Pitre]

Many embedded systems don't need the full POSIX timer support.
Configuring them out provides a nice kernel image size reduction.

When POSIX timers are configured out, the PTP clock subsystem should be
left out as well. However a bunch of ethernet drivers currently *select*
the later in their Kconfig entries. Therefore some more work was needed
to break that hard dependency from those drivers without preventing their
usage altogether.

Therefore this series also includes kconfig changes to implement a new
keyword to express some reverse dependencies like "select" does, named
"imply", and still allowing for the target config symbol to be disabled
if the user or a direct dependency says so.

At this point I'd like to gather ACKs especially from people in the "To"
field. Ideally this would need to go upstream as a single series to avoid
cross subsystem dependency issues.  So far it was suggested that this could
go via the kbuild tree. Given the end goal and the included timer cleanup
patches I'd lean towards the timer tree but any tree would suit me just
as well.

This is also available here for those who prefer a git tree:
git://git.linaro.org/people/nicolas.pitre/linux/ configurable_posix_timers

Changes from v3:

- Added a patch to move sys_alarm to itimer.c where the support code lives.
- Added a patch to move entropy collection out of posix-cpu-timers.c.
- Remove itimer as well when POSIX_TIMERS=n as they rely on code already
  removed. This means the getitimer, setitimer and alarm syscalls are also
  stubbed out in that case.
- Reverted the addition of empty timer stubs from posix-timers.h. Since
  there is only a few callers, it's better to conditionalize call sites
  instead, and get a link error if some were missed. Easier to clearly
  ponder the implications that way.
- Collected more ACKs.

Changes from v2:

- Dropped the patch adding the "suggest" keyword as nothing uses it.
  Requested by Paul Bolle.
- Various documentation and commit log clarifications, prompted also
  by Paul Bolle.
- Collected more ACKs.

Changes from v1:

- added "suggest" to kconfig for completeness
- various typo fixes
- small "imply" effect visibility fix

The bulk of the diffstat comes from the kconfig lex parser regeneration.

Diffstat:

 Documentation/kbuild/kconfig-language.txt   |   29 +
 arch/alpha/kernel/osf_sys.c |8 +
 drivers/Makefile|2 +-
 drivers/char/Kconfig|1 +
 drivers/net/ethernet/adi/Kconfig|2 +-
 drivers/net/ethernet/amd/Kconfig|2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-main.c   |6 +-
 drivers/net/ethernet/broadcom/Kconfig   |4 +-
 drivers/net/ethernet/cavium/Kconfig |2 +-
 drivers/net/ethernet/freescale/Kconfig  |2 +-
 drivers/net/ethernet/intel/Kconfig  |   10 +-
 drivers/net/ethernet/mellanox/mlx4/Kconfig  |2 +-
 drivers/net/ethernet/mellanox/mlx5/core/Kconfig |2 +-
 drivers/net/ethernet/renesas/Kconfig|2 +-
 drivers/net/ethernet/samsung/Kconfig|2 +-
 drivers/net/ethernet/sfc/Kconfig|2 +-
 drivers/net/ethernet/stmicro/stmmac/Kconfig |2 +-
 drivers/net/ethernet/ti/Kconfig |2 +-
 drivers/net/ethernet/tile/Kconfig   |2 +-
 drivers/ptp/Kconfig |   10 +-
 fs/exec.c   |2 +
 include/linux/ptp_clock_kernel.h|   65 +-
 include/linux/time.h|2 -
 init/Kconfig|   17 +
 kernel/compat.c |8 +
 kernel/exit.c   |   15 +-
 kernel/fork.c   |2 +
 kernel/signal.c |6 +
 kernel/sys.c|3 +-
 kernel/time/Makefile|   10 +-
 kernel/time/alarmtimer.c|6 +-
 kernel/time/itimer.c|   15 +-
 kernel/time/posix-cpu-timers.c  |4 -
 kernel/time/posix-stubs.c   |  123 ++
 kernel/time/timer.c |   16 +-
 scripts/kconfig/expr.h  |2 +
 scripts/kconfig/menu.c  |   55 +-
 scripts/kconfig/symbol.c|   24 +-
 scripts/kconfig/zconf.gperf |1 +
 scripts/kconfig/zconf.hash.c_shipped|   30 +-
 scripts/kconfig/zconf.tab.c_shipped | 1581 +++
 scripts/kconfig/zconf.y |   16 +-
 security/selinux/hooks.c|   11 +-
 43 files changed, 1148 insertions(+), 960 deletions(-)

[PATCH v4 4/6] timer: move sys_alarm from timer.c to itimer.c

[Nicolas Pitre]

Move the only user of alarm_setitimer to itimer.c where it is defined.
This allows for making alarm_setitimer static, and dropping it from the
build when __ARCH_WANT_SYS_ALARM is not defined.

Signed-off-by: Nicolas Pitre 
---
 include/linux/time.h |  2 --
 kernel/time/itimer.c | 15 ++-
 kernel/time/timer.c  | 13 -
 3 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/include/linux/time.h b/include/linux/time.h
index 4cea09d942..23f0f5ce30 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -172,8 +172,6 @@ extern int do_setitimer(int which, struct itimerval *value,
struct itimerval *ovalue);
 extern int do_getitimer(int which, struct itimerval *value);
 
-extern unsigned int alarm_setitimer(unsigned int seconds);
-
 extern long do_utimes(int dfd, const char __user *filename, struct timespec 
*times, int flags);
 
 struct tms;
diff --git a/kernel/time/itimer.c b/kernel/time/itimer.c
index 1d5c7204dd..2b9f45bc95 100644
--- a/kernel/time/itimer.c
+++ b/kernel/time/itimer.c
@@ -238,6 +238,8 @@ int do_setitimer(int which, struct itimerval *value, struct 
itimerval *ovalue)
return 0;
 }
 
+#ifdef __ARCH_WANT_SYS_ALARM
+
 /**
  * alarm_setitimer - set alarm in seconds
  *
@@ -250,7 +252,7 @@ int do_setitimer(int which, struct itimerval *value, struct 
itimerval *ovalue)
  * On 32 bit machines the seconds value is limited to (INT_MAX/2) to avoid
  * negative timeval settings which would cause immediate expiry.
  */
-unsigned int alarm_setitimer(unsigned int seconds)
+static unsigned int alarm_setitimer(unsigned int seconds)
 {
struct itimerval it_new, it_old;
 
@@ -275,6 +277,17 @@ unsigned int alarm_setitimer(unsigned int seconds)
return it_old.it_value.tv_sec;
 }
 
+/*
+ * For backwards compatibility?  This can be done in libc so Alpha
+ * and all newer ports shouldn't need it.
+ */
+SYSCALL_DEFINE1(alarm, unsigned int, seconds)
+{
+   return alarm_setitimer(seconds);
+}
+
+#endif
+
 SYSCALL_DEFINE3(setitimer, int, which, struct itimerval __user *, value,
struct itimerval __user *, ovalue)
 {
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 2d47980a1b..3ed6c67e17 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1662,19 +1662,6 @@ void run_local_timers(void)
raise_softirq(TIMER_SOFTIRQ);
 }
 
-#ifdef __ARCH_WANT_SYS_ALARM
-
-/*
- * For backwards compatibility?  This can be done in libc so Alpha
- * and all newer ports shouldn't need it.
- */
-SYSCALL_DEFINE1(alarm, unsigned int, seconds)
-{
-   return alarm_setitimer(seconds);
-}
-
-#endif
-
 static void process_timeout(unsigned long __data)
 {
wake_up_process((struct task_struct *)__data);
-- 
2.7.4

[PATCH v4 4/6] timer: move sys_alarm from timer.c to itimer.c

[Nicolas Pitre]

Move the only user of alarm_setitimer to itimer.c where it is defined.
This allows for making alarm_setitimer static, and dropping it from the
build when __ARCH_WANT_SYS_ALARM is not defined.

Signed-off-by: Nicolas Pitre 
---
 include/linux/time.h |  2 --
 kernel/time/itimer.c | 15 ++-
 kernel/time/timer.c  | 13 -
 3 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/include/linux/time.h b/include/linux/time.h
index 4cea09d942..23f0f5ce30 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -172,8 +172,6 @@ extern int do_setitimer(int which, struct itimerval *value,
struct itimerval *ovalue);
 extern int do_getitimer(int which, struct itimerval *value);
 
-extern unsigned int alarm_setitimer(unsigned int seconds);
-
 extern long do_utimes(int dfd, const char __user *filename, struct timespec 
*times, int flags);
 
 struct tms;
diff --git a/kernel/time/itimer.c b/kernel/time/itimer.c
index 1d5c7204dd..2b9f45bc95 100644
--- a/kernel/time/itimer.c
+++ b/kernel/time/itimer.c
@@ -238,6 +238,8 @@ int do_setitimer(int which, struct itimerval *value, struct 
itimerval *ovalue)
return 0;
 }
 
+#ifdef __ARCH_WANT_SYS_ALARM
+
 /**
  * alarm_setitimer - set alarm in seconds
  *
@@ -250,7 +252,7 @@ int do_setitimer(int which, struct itimerval *value, struct 
itimerval *ovalue)
  * On 32 bit machines the seconds value is limited to (INT_MAX/2) to avoid
  * negative timeval settings which would cause immediate expiry.
  */
-unsigned int alarm_setitimer(unsigned int seconds)
+static unsigned int alarm_setitimer(unsigned int seconds)
 {
struct itimerval it_new, it_old;
 
@@ -275,6 +277,17 @@ unsigned int alarm_setitimer(unsigned int seconds)
return it_old.it_value.tv_sec;
 }
 
+/*
+ * For backwards compatibility?  This can be done in libc so Alpha
+ * and all newer ports shouldn't need it.
+ */
+SYSCALL_DEFINE1(alarm, unsigned int, seconds)
+{
+   return alarm_setitimer(seconds);
+}
+
+#endif
+
 SYSCALL_DEFINE3(setitimer, int, which, struct itimerval __user *, value,
struct itimerval __user *, ovalue)
 {
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 2d47980a1b..3ed6c67e17 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1662,19 +1662,6 @@ void run_local_timers(void)
raise_softirq(TIMER_SOFTIRQ);
 }
 
-#ifdef __ARCH_WANT_SYS_ALARM
-
-/*
- * For backwards compatibility?  This can be done in libc so Alpha
- * and all newer ports shouldn't need it.
- */
-SYSCALL_DEFINE1(alarm, unsigned int, seconds)
-{
-   return alarm_setitimer(seconds);
-}
-
-#endif
-
 static void process_timeout(unsigned long __data)
 {
wake_up_process((struct task_struct *)__data);
-- 
2.7.4

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

[Nikolaus Rath]

On Nov 11 2016, Miklos Szeredi  wrote:
> On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath  wrote:
>> Hi Andrew,
>>
>> In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT
>> flag. But as far as I can tell, the flag is simply accepted without
>> having any effect (including in libfuse).
>>
>> I tried to find related later commits, but did not find anything either.
>>
>> Am I missing something?
>
> Hmm, if fuse fs detects this flag, then it can return ENOSYS from open
> resulting in this and subsequent opens succeeding without further
> calls to userspace.If fuse fs doesn't detect this flag, it should
> not return -ENOSYS, as that will result in the open failing, it should
> instead implement a no-op open method.

That doesn't sound like a good approach to me. That way, the file system
has to *know* that this flag has been introduced in order to behave
correctly, i.e. filesystems that predate the introduction of the flag
will suddenly behave differently.

I think the correct behavior would be to for the kernel to check if
userspace passed the flag, and treat ENOSYS specially if and only if the
flag was passed.

> Could handle this in libfuse and that would make things easier for
> filesystem implementors that would want to use this feature.  But I
> guess its use is relatively rare and so it doesn't really matter.

I agree, but it would be nice to get this sorted out properly
nevertheless. If nothing else, it will make the behavior easier to
explain.

Would you accept a patch that makes treatment of ENOSYS conditional on
userspace passing the flag (as outlined above)?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

[Nikolaus Rath]

On Nov 11 2016, Miklos Szeredi  wrote:
> On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath  wrote:
>> Hi Andrew,
>>
>> In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT
>> flag. But as far as I can tell, the flag is simply accepted without
>> having any effect (including in libfuse).
>>
>> I tried to find related later commits, but did not find anything either.
>>
>> Am I missing something?
>
> Hmm, if fuse fs detects this flag, then it can return ENOSYS from open
> resulting in this and subsequent opens succeeding without further
> calls to userspace.If fuse fs doesn't detect this flag, it should
> not return -ENOSYS, as that will result in the open failing, it should
> instead implement a no-op open method.

That doesn't sound like a good approach to me. That way, the file system
has to *know* that this flag has been introduced in order to behave
correctly, i.e. filesystems that predate the introduction of the flag
will suddenly behave differently.

I think the correct behavior would be to for the kernel to check if
userspace passed the flag, and treat ENOSYS specially if and only if the
flag was passed.

> Could handle this in libfuse and that would make things easier for
> filesystem implementors that would want to use this feature.  But I
> guess its use is relatively rare and so it doesn't really matter.

I agree, but it would be nice to get this sorted out properly
nevertheless. If nothing else, it will make the behavior easier to
explain.

Would you accept a patch that makes treatment of ENOSYS conditional on
userspace passing the flag (as outlined above)?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: commit 5c672ab3f0ee0f78f: fuse: serialize dirops by default

[Nikolaus Rath]

On Nov 10 2016, Miklos Szeredi  wrote:
> On Thu, Nov 10, 2016 at 11:21 PM, Nikolaus Rath  wrote:
>> Hi Miklos,
>>
>> In commit 5c672ab3f0ee0f78f7acad183f34db0f8781a200 you introduced a new
>> FUSE_PARALLEL_DIROPS capability and bumped the kernel interface no to
>> 25 - but there have been no corresponding changes to userspace.
>
> I think libfuse3 should always set this, it's just for backward compatibility.
>
>> Is this still preliminary and thus deliberately not in libfuse? I only
>> noticed it by chance.
>
> Oops, I just forgot about it.

Are you going to send a patch/pull request? If not, I don't mind adding
it either.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F


 »Time flies like an arrow, fruit flies like a Banana.«

Re: commit 5c672ab3f0ee0f78f: fuse: serialize dirops by default

[Nikolaus Rath]

On Nov 10 2016, Miklos Szeredi  wrote:
> On Thu, Nov 10, 2016 at 11:21 PM, Nikolaus Rath  wrote:
>> Hi Miklos,
>>
>> In commit 5c672ab3f0ee0f78f7acad183f34db0f8781a200 you introduced a new
>> FUSE_PARALLEL_DIROPS capability and bumped the kernel interface no to
>> 25 - but there have been no corresponding changes to userspace.
>
> I think libfuse3 should always set this, it's just for backward compatibility.
>
>> Is this still preliminary and thus deliberately not in libfuse? I only
>> noticed it by chance.
>
> Oops, I just forgot about it.

Are you going to send a patch/pull request? If not, I don't mind adding
it either.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F


 »Time flies like an arrow, fruit flies like a Banana.«

Re: [PATCH 1/3] tuntap: rx batching

[John Fastabend]

On 16-11-10 08:28 PM, Jason Wang wrote:
> 
> 
> On 2016年11月11日 12:17, John Fastabend wrote:
>> On 16-11-10 07:31 PM, Michael S. Tsirkin wrote:
>>> >On Fri, Nov 11, 2016 at 10:07:44AM +0800, Jason Wang wrote:
 >>
 >>
 >>On 2016年11月10日 00:38, Michael S. Tsirkin wrote:
> >>>On Wed, Nov 09, 2016 at 03:38:31PM +0800, Jason Wang wrote:
>> Backlog were used for tuntap rx, but it can only process 1
>> packet at
>> one time since it was scheduled during sendmsg() synchronously in
>> process context. This lead bad cache utilization so this patch
>> tries
>> to do some batching before call rx NAPI. This is done through:
>> 
>> - accept MSG_MORE as a hint from sendmsg() caller, if it was set,
>> batch the packet temporarily in a linked list and submit
>> them all
>> once MSG_MORE were cleared.
>> - implement a tuntap specific NAPI handler for processing this
>> kind of
>> possible batching. (This could be done by extending
>> backlog to
>> support skb like, but using a tun specific one looks
>> cleaner and
>> easier for future extension).
>> 
>> Signed-off-by: Jason Wang
> >>>So why do we need an extra queue?
 >>
 >>The idea was borrowed from backlog to allow some kind of bulking
 and avoid
 >>spinlock on each dequeuing.
 >>
> >>>   This is not what hardware devices do.
> >>>How about adding the packet to queue unconditionally, deferring
> >>>signalling until we get sendmsg without MSG_MORE?
 >>
 >>Then you need touch spinlock when dequeuing each packet.
>>> >
>> Random thought, I have a cmpxchg ring I am using for the qdisc work that
>> could possibly replace the spinlock implementation. I haven't figured
>> out the resizing API yet because I did not need it but I assume it could
>> help here and let you dequeue multiple skbs in one operation.
>>
>> I can post the latest version if useful or an older version is
>> somewhere on patchworks as well.
>>
>> .John
>>
>>
> 
> Look useful here, and I can compare the performance if you post.
> 
> A question is can we extend the skb_array to support that?
> 
> Thanks
> 

Sent out two RFC patches with the implementation, the first has been
running on my system for some time the second for multiple packets is
only lightly tested and that was awhile back.

.John

Re: [PATCH 1/3] tuntap: rx batching

[John Fastabend]

On 16-11-10 08:28 PM, Jason Wang wrote:
> 
> 
> On 2016年11月11日 12:17, John Fastabend wrote:
>> On 16-11-10 07:31 PM, Michael S. Tsirkin wrote:
>>> >On Fri, Nov 11, 2016 at 10:07:44AM +0800, Jason Wang wrote:
 >>
 >>
 >>On 2016年11月10日 00:38, Michael S. Tsirkin wrote:
> >>>On Wed, Nov 09, 2016 at 03:38:31PM +0800, Jason Wang wrote:
>> Backlog were used for tuntap rx, but it can only process 1
>> packet at
>> one time since it was scheduled during sendmsg() synchronously in
>> process context. This lead bad cache utilization so this patch
>> tries
>> to do some batching before call rx NAPI. This is done through:
>> 
>> - accept MSG_MORE as a hint from sendmsg() caller, if it was set,
>> batch the packet temporarily in a linked list and submit
>> them all
>> once MSG_MORE were cleared.
>> - implement a tuntap specific NAPI handler for processing this
>> kind of
>> possible batching. (This could be done by extending
>> backlog to
>> support skb like, but using a tun specific one looks
>> cleaner and
>> easier for future extension).
>> 
>> Signed-off-by: Jason Wang
> >>>So why do we need an extra queue?
 >>
 >>The idea was borrowed from backlog to allow some kind of bulking
 and avoid
 >>spinlock on each dequeuing.
 >>
> >>>   This is not what hardware devices do.
> >>>How about adding the packet to queue unconditionally, deferring
> >>>signalling until we get sendmsg without MSG_MORE?
 >>
 >>Then you need touch spinlock when dequeuing each packet.
>>> >
>> Random thought, I have a cmpxchg ring I am using for the qdisc work that
>> could possibly replace the spinlock implementation. I haven't figured
>> out the resizing API yet because I did not need it but I assume it could
>> help here and let you dequeue multiple skbs in one operation.
>>
>> I can post the latest version if useful or an older version is
>> somewhere on patchworks as well.
>>
>> .John
>>
>>
> 
> Look useful here, and I can compare the performance if you post.
> 
> A question is can we extend the skb_array to support that?
> 
> Thanks
> 

Sent out two RFC patches with the implementation, the first has been
running on my system for some time the second for multiple packets is
only lightly tested and that was awhile back.

.John

[RFC PATCH 1/2] net: use cmpxchg instead of spinlock in ptr rings

[John Fastabend]

---
 include/linux/ptr_ring_ll.h |  136 +++
 include/linux/skb_array.h   |   25 
 2 files changed, 161 insertions(+)
 create mode 100644 include/linux/ptr_ring_ll.h

diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
new file mode 100644
index 000..bcb11f3
--- /dev/null
+++ b/include/linux/ptr_ring_ll.h
@@ -0,0 +1,136 @@
+/*
+ * Definitions for the 'struct ptr_ring_ll' datastructure.
+ *
+ * Author:
+ * John Fastabend 
+ *
+ * Copyright (C) 2016 Intel Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This is a limited-size FIFO maintaining pointers in FIFO order, with
+ * one CPU producing entries and another consuming entries from a FIFO.
+ * extended from ptr_ring_ll to use cmpxchg over spin lock.
+ */
+
+#ifndef _LINUX_PTR_RING_LL_H
+#define _LINUX_PTR_RING_LL_H 1
+
+#ifdef __KERNEL__
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif
+
+struct ptr_ring_ll {
+   u32 prod_size;
+   u32 prod_mask;
+   u32 prod_head;
+   u32 prod_tail;
+   u32 cons_size;
+   u32 cons_mask;
+   u32 cons_head;
+   u32 cons_tail;
+
+   void **queue;
+};
+
+/* Note: callers invoking this in a loop must use a compiler barrier,
+ * for example cpu_relax(). Callers must hold producer_lock.
+ */
+static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr)
+{
+   u32 ret, head, tail, next, slots, mask;
+
+   do {
+   head = READ_ONCE(r->prod_head);
+   mask = READ_ONCE(r->prod_mask);
+   tail = READ_ONCE(r->cons_tail);
+
+   slots = mask + tail - head;
+   if (slots < 1)
+   return -ENOMEM;
+
+   next = head + 1;
+   ret = cmpxchg(>prod_head, head, next);
+   } while (ret != head);
+
+   r->queue[head & mask] = ptr;
+   smp_wmb();
+
+   while (r->prod_tail != head)
+   cpu_relax();
+
+   r->prod_tail = next;
+   return 0;
+}
+
+static inline void *__ptr_ring_ll_consume(struct ptr_ring_ll *r)
+{
+   u32 ret, head, tail, next, slots, mask;
+   void *ptr;
+
+   do {
+   head = READ_ONCE(r->cons_head);
+   mask = READ_ONCE(r->cons_mask);
+   tail = READ_ONCE(r->prod_tail);
+
+   slots = tail - head;
+   if (slots < 1)
+   return ERR_PTR(-ENOMEM);
+
+   next = head + 1;
+   ret = cmpxchg(>cons_head, head, next);
+   } while (ret != head);
+
+   ptr = r->queue[head & mask];
+   smp_rmb();
+
+   while (r->cons_tail != head)
+   cpu_relax();
+
+   r->cons_tail = next;
+   return ptr;
+}
+
+static inline void **__ptr_ring_ll_init_queue_alloc(int size, gfp_t gfp)
+{
+   return kzalloc(ALIGN(size * sizeof(void *), SMP_CACHE_BYTES), gfp);
+}
+
+static inline int ptr_ring_ll_init(struct ptr_ring_ll *r, int size, gfp_t gfp)
+{
+   r->queue = __ptr_ring_init_queue_alloc(size, gfp);
+   if (!r->queue)
+   return -ENOMEM;
+
+   r->prod_size = r->cons_size = size;
+   r->prod_mask = r->cons_mask = size - 1;
+   r->prod_tail = r->prod_head = 0;
+   r->cons_tail = r->prod_tail = 0;
+
+   return 0;
+}
+
+static inline void ptr_ring_ll_cleanup(struct ptr_ring_ll *r, void 
(*destroy)(void *))
+{
+   if (destroy) {
+   void *ptr;
+
+   ptr = __ptr_ring_ll_consume(r);
+   while (!IS_ERR_OR_NULL(ptr)) {
+   destroy(ptr);
+   ptr = __ptr_ring_ll_consume(r);
+   }
+   }
+   kfree(r->queue);
+}
+
+#endif /* _LINUX_PTR_RING_LL_H  */
diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
index f4dfade..9b43dfd 100644
--- a/include/linux/skb_array.h
+++ b/include/linux/skb_array.h
@@ -22,6 +22,7 @@
 
 #ifdef __KERNEL__
 #include 
+#include 
 #include 
 #include 
 #endif
@@ -30,6 +31,10 @@ struct skb_array {
struct ptr_ring ring;
 };
 
+struct skb_array_ll {
+   struct ptr_ring_ll ring;
+};
+
 /* Might be slightly faster than skb_array_full below, but callers invoking
  * this in a loop must use a compiler barrier, for example cpu_relax().
  */
@@ -43,6 +48,11 @@ static inline bool skb_array_full(struct skb_array *a)
return ptr_ring_full(>ring);
 }
 
+static inline int skb_array_ll_produce(struct skb_array_ll *a, struct sk_buff 
*skb)
+{
+   return __ptr_ring_ll_produce(>ring, skb);
+}
+
 static inline int skb_array_produce(struct skb_array *a, struct sk_buff *skb)
 {
return ptr_ring_produce(>ring, skb);
@@ -92,6 +102,11 @@ static 

[RFC PATCH 2/2] ptr_ring_ll: pop/push multiple objects at once

[John Fastabend]

Signed-off-by: John Fastabend 
---
 include/linux/ptr_ring_ll.h |   22 --
 include/linux/skb_array.h   |   11 +--
 net/sched/sch_generic.c |2 +-
 3 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
index bcb11f3..5dc25f7 100644
--- a/include/linux/ptr_ring_ll.h
+++ b/include/linux/ptr_ring_ll.h
@@ -45,9 +45,10 @@ struct ptr_ring_ll {
 /* Note: callers invoking this in a loop must use a compiler barrier,
  * for example cpu_relax(). Callers must hold producer_lock.
  */
-static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr)
+static inline int __ptr_ring_ll_produce_many(struct ptr_ring_ll *r,
+void **ptr, int num)
 {
-   u32 ret, head, tail, next, slots, mask;
+   u32 ret, head, tail, next, slots, mask, i;
 
do {
head = READ_ONCE(r->prod_head);
@@ -55,21 +56,30 @@ static inline int __ptr_ring_ll_produce(struct ptr_ring_ll 
*r, void *ptr)
tail = READ_ONCE(r->cons_tail);
 
slots = mask + tail - head;
-   if (slots < 1)
+   if (slots < num)
+   num = slots;
+
+   if (unlikely(!num))
return -ENOMEM;
 
-   next = head + 1;
+   next = head + num;
ret = cmpxchg(>prod_head, head, next);
} while (ret != head);
 
-   r->queue[head & mask] = ptr;
+   for (i = 0; i < num; i++)
+   r->queue[(head + i) & mask] = ptr[i];
smp_wmb();
 
while (r->prod_tail != head)
cpu_relax();
 
r->prod_tail = next;
-   return 0;
+   return num;
+}
+
+static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void **ptr)
+{
+   return __ptr_ring_ll_produce_many(r, ptr, 1);
 }
 
 static inline void *__ptr_ring_ll_consume(struct ptr_ring_ll *r)
diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
index 9b43dfd..de3c700 100644
--- a/include/linux/skb_array.h
+++ b/include/linux/skb_array.h
@@ -48,9 +48,16 @@ static inline bool skb_array_full(struct skb_array *a)
return ptr_ring_full(>ring);
 }
 
-static inline int skb_array_ll_produce(struct skb_array_ll *a, struct sk_buff 
*skb)
+static inline int skb_array_ll_produce_many(struct skb_array_ll *a,
+   struct sk_buff **skb, int num)
 {
-   return __ptr_ring_ll_produce(>ring, skb);
+   return __ptr_ring_ll_produce_many(>ring, (void **)skb, num);
+}
+
+static inline int skb_array_ll_produce(struct skb_array_ll *a,
+  struct sk_buff **skb)
+{
+   return __ptr_ring_ll_produce(>ring, (void **)skb);
 }
 
 static inline int skb_array_produce(struct skb_array *a, struct sk_buff *skb)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 4648ec8..58f2011 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -571,7 +571,7 @@ static int pfifo_fast_enqueue(struct sk_buff *skb, struct 
Qdisc *qdisc,
struct skb_array_ll *q = band2list(priv, band);
int err;
 
-   err = skb_array_ll_produce(q, skb);
+   err = skb_array_ll_produce(q, );
 
if (unlikely(err)) {
net_warn_ratelimited("drop a packet from fast enqueue\n");

[RFC PATCH 1/2] net: use cmpxchg instead of spinlock in ptr rings

[John Fastabend]

---
 include/linux/ptr_ring_ll.h |  136 +++
 include/linux/skb_array.h   |   25 
 2 files changed, 161 insertions(+)
 create mode 100644 include/linux/ptr_ring_ll.h

diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
new file mode 100644
index 000..bcb11f3
--- /dev/null
+++ b/include/linux/ptr_ring_ll.h
@@ -0,0 +1,136 @@
+/*
+ * Definitions for the 'struct ptr_ring_ll' datastructure.
+ *
+ * Author:
+ * John Fastabend 
+ *
+ * Copyright (C) 2016 Intel Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This is a limited-size FIFO maintaining pointers in FIFO order, with
+ * one CPU producing entries and another consuming entries from a FIFO.
+ * extended from ptr_ring_ll to use cmpxchg over spin lock.
+ */
+
+#ifndef _LINUX_PTR_RING_LL_H
+#define _LINUX_PTR_RING_LL_H 1
+
+#ifdef __KERNEL__
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif
+
+struct ptr_ring_ll {
+   u32 prod_size;
+   u32 prod_mask;
+   u32 prod_head;
+   u32 prod_tail;
+   u32 cons_size;
+   u32 cons_mask;
+   u32 cons_head;
+   u32 cons_tail;
+
+   void **queue;
+};
+
+/* Note: callers invoking this in a loop must use a compiler barrier,
+ * for example cpu_relax(). Callers must hold producer_lock.
+ */
+static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr)
+{
+   u32 ret, head, tail, next, slots, mask;
+
+   do {
+   head = READ_ONCE(r->prod_head);
+   mask = READ_ONCE(r->prod_mask);
+   tail = READ_ONCE(r->cons_tail);
+
+   slots = mask + tail - head;
+   if (slots < 1)
+   return -ENOMEM;
+
+   next = head + 1;
+   ret = cmpxchg(>prod_head, head, next);
+   } while (ret != head);
+
+   r->queue[head & mask] = ptr;
+   smp_wmb();
+
+   while (r->prod_tail != head)
+   cpu_relax();
+
+   r->prod_tail = next;
+   return 0;
+}
+
+static inline void *__ptr_ring_ll_consume(struct ptr_ring_ll *r)
+{
+   u32 ret, head, tail, next, slots, mask;
+   void *ptr;
+
+   do {
+   head = READ_ONCE(r->cons_head);
+   mask = READ_ONCE(r->cons_mask);
+   tail = READ_ONCE(r->prod_tail);
+
+   slots = tail - head;
+   if (slots < 1)
+   return ERR_PTR(-ENOMEM);
+
+   next = head + 1;
+   ret = cmpxchg(>cons_head, head, next);
+   } while (ret != head);
+
+   ptr = r->queue[head & mask];
+   smp_rmb();
+
+   while (r->cons_tail != head)
+   cpu_relax();
+
+   r->cons_tail = next;
+   return ptr;
+}
+
+static inline void **__ptr_ring_ll_init_queue_alloc(int size, gfp_t gfp)
+{
+   return kzalloc(ALIGN(size * sizeof(void *), SMP_CACHE_BYTES), gfp);
+}
+
+static inline int ptr_ring_ll_init(struct ptr_ring_ll *r, int size, gfp_t gfp)
+{
+   r->queue = __ptr_ring_init_queue_alloc(size, gfp);
+   if (!r->queue)
+   return -ENOMEM;
+
+   r->prod_size = r->cons_size = size;
+   r->prod_mask = r->cons_mask = size - 1;
+   r->prod_tail = r->prod_head = 0;
+   r->cons_tail = r->prod_tail = 0;
+
+   return 0;
+}
+
+static inline void ptr_ring_ll_cleanup(struct ptr_ring_ll *r, void 
(*destroy)(void *))
+{
+   if (destroy) {
+   void *ptr;
+
+   ptr = __ptr_ring_ll_consume(r);
+   while (!IS_ERR_OR_NULL(ptr)) {
+   destroy(ptr);
+   ptr = __ptr_ring_ll_consume(r);
+   }
+   }
+   kfree(r->queue);
+}
+
+#endif /* _LINUX_PTR_RING_LL_H  */
diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
index f4dfade..9b43dfd 100644
--- a/include/linux/skb_array.h
+++ b/include/linux/skb_array.h
@@ -22,6 +22,7 @@
 
 #ifdef __KERNEL__
 #include 
+#include 
 #include 
 #include 
 #endif
@@ -30,6 +31,10 @@ struct skb_array {
struct ptr_ring ring;
 };
 
+struct skb_array_ll {
+   struct ptr_ring_ll ring;
+};
+
 /* Might be slightly faster than skb_array_full below, but callers invoking
  * this in a loop must use a compiler barrier, for example cpu_relax().
  */
@@ -43,6 +48,11 @@ static inline bool skb_array_full(struct skb_array *a)
return ptr_ring_full(>ring);
 }
 
+static inline int skb_array_ll_produce(struct skb_array_ll *a, struct sk_buff 
*skb)
+{
+   return __ptr_ring_ll_produce(>ring, skb);
+}
+
 static inline int skb_array_produce(struct skb_array *a, struct sk_buff *skb)
 {
return ptr_ring_produce(>ring, skb);
@@ -92,6 +102,11 @@ static inline bool 

[RFC PATCH 2/2] ptr_ring_ll: pop/push multiple objects at once

[John Fastabend]

Signed-off-by: John Fastabend 
---
 include/linux/ptr_ring_ll.h |   22 --
 include/linux/skb_array.h   |   11 +--
 net/sched/sch_generic.c |2 +-
 3 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
index bcb11f3..5dc25f7 100644
--- a/include/linux/ptr_ring_ll.h
+++ b/include/linux/ptr_ring_ll.h
@@ -45,9 +45,10 @@ struct ptr_ring_ll {
 /* Note: callers invoking this in a loop must use a compiler barrier,
  * for example cpu_relax(). Callers must hold producer_lock.
  */
-static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr)
+static inline int __ptr_ring_ll_produce_many(struct ptr_ring_ll *r,
+void **ptr, int num)
 {
-   u32 ret, head, tail, next, slots, mask;
+   u32 ret, head, tail, next, slots, mask, i;
 
do {
head = READ_ONCE(r->prod_head);
@@ -55,21 +56,30 @@ static inline int __ptr_ring_ll_produce(struct ptr_ring_ll 
*r, void *ptr)
tail = READ_ONCE(r->cons_tail);
 
slots = mask + tail - head;
-   if (slots < 1)
+   if (slots < num)
+   num = slots;
+
+   if (unlikely(!num))
return -ENOMEM;
 
-   next = head + 1;
+   next = head + num;
ret = cmpxchg(>prod_head, head, next);
} while (ret != head);
 
-   r->queue[head & mask] = ptr;
+   for (i = 0; i < num; i++)
+   r->queue[(head + i) & mask] = ptr[i];
smp_wmb();
 
while (r->prod_tail != head)
cpu_relax();
 
r->prod_tail = next;
-   return 0;
+   return num;
+}
+
+static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void **ptr)
+{
+   return __ptr_ring_ll_produce_many(r, ptr, 1);
 }
 
 static inline void *__ptr_ring_ll_consume(struct ptr_ring_ll *r)
diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
index 9b43dfd..de3c700 100644
--- a/include/linux/skb_array.h
+++ b/include/linux/skb_array.h
@@ -48,9 +48,16 @@ static inline bool skb_array_full(struct skb_array *a)
return ptr_ring_full(>ring);
 }
 
-static inline int skb_array_ll_produce(struct skb_array_ll *a, struct sk_buff 
*skb)
+static inline int skb_array_ll_produce_many(struct skb_array_ll *a,
+   struct sk_buff **skb, int num)
 {
-   return __ptr_ring_ll_produce(>ring, skb);
+   return __ptr_ring_ll_produce_many(>ring, (void **)skb, num);
+}
+
+static inline int skb_array_ll_produce(struct skb_array_ll *a,
+  struct sk_buff **skb)
+{
+   return __ptr_ring_ll_produce(>ring, (void **)skb);
 }
 
 static inline int skb_array_produce(struct skb_array *a, struct sk_buff *skb)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 4648ec8..58f2011 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -571,7 +571,7 @@ static int pfifo_fast_enqueue(struct sk_buff *skb, struct 
Qdisc *qdisc,
struct skb_array_ll *q = band2list(priv, band);
int err;
 
-   err = skb_array_ll_produce(q, skb);
+   err = skb_array_ll_produce(q, );
 
if (unlikely(err)) {
net_warn_ratelimited("drop a packet from fast enqueue\n");

[RFC PATCH 0/2] illustrate cmpxchg ring for tap/tun and qdisc

[John Fastabend]

This is a cmpxchg ring that could potentially be used to replace the spinlock
variant of skb_array.

Couple comments its missing a resize operator which would need to be added
before it could be a drop in replacement. And although I tested the first
patch with my latest set of qdisc updates the second patch I have not tested
for a bit so it may or may not work but it illustrates the idea at least.

This was derived from the DPDK documentation where there is a description
of the cmpxchg ring presumably used there. It may or may not actually align
with what is done in DPDK implementation I have no idea I didn't look.


---

John Fastabend (2):
  net: use cmpxchg instead of spinlock in ptr rings
  ptr_ring_ll: pop/push multiple objects at once


 include/linux/netdevice.h   |   12 
 include/linux/ptr_ring_ll.h |  146 +++
 include/linux/skb_array.h   |   32 +
 net/core/dev.c  |   18 +
 net/sched/sch_generic.c |   86 +
 5 files changed, 224 insertions(+), 70 deletions(-)
 create mode 100644 include/linux/ptr_ring_ll.h

--
Signature

[RFC PATCH 0/2] illustrate cmpxchg ring for tap/tun and qdisc

[John Fastabend]

This is a cmpxchg ring that could potentially be used to replace the spinlock
variant of skb_array.

Couple comments its missing a resize operator which would need to be added
before it could be a drop in replacement. And although I tested the first
patch with my latest set of qdisc updates the second patch I have not tested
for a bit so it may or may not work but it illustrates the idea at least.

This was derived from the DPDK documentation where there is a description
of the cmpxchg ring presumably used there. It may or may not actually align
with what is done in DPDK implementation I have no idea I didn't look.


---

John Fastabend (2):
  net: use cmpxchg instead of spinlock in ptr rings
  ptr_ring_ll: pop/push multiple objects at once


 include/linux/netdevice.h   |   12 
 include/linux/ptr_ring_ll.h |  146 +++
 include/linux/skb_array.h   |   32 +
 net/core/dev.c  |   18 +
 net/sched/sch_generic.c |   86 +
 5 files changed, 224 insertions(+), 70 deletions(-)
 create mode 100644 include/linux/ptr_ring_ll.h

--
Signature

Re: [PATCH RFC 0/2] Generalize tpm2_get_tpm_pt to tpm2_get_cap

[Nayna]

On 11/04/2016 12:58 PM, Jarkko Sakkinen wrote:

Nayna,

I've already sent these earlier this month as we had this discussion.
Please look up your emails. I can apply these if they look good for
you. Please review them.


Sure, I replied just now. I am sorry if delay in response. I was off 
early this week and still going through all mails.


Thanks & Regards,
  - Nayna



/Jarkko

On Sun, Oct 09, 2016 at 01:14:14PM +0300, Jarkko Sakkinen wrote:

We need to generalize tpm2_get_tpm_pt to tpm2_get_cap in order to it be
suitable for grabbing handles, PCR banks and so forth.

Jarkko Sakkinen (2):
   tpm: move TPM 2.0 command and response constants to tpm2-cmd.c
   tpm: refactor tpm2_get_tpm_pt to tpm2_getcap_cmd

  drivers/char/tpm/tpm.h  |  48 ++
  drivers/char/tpm/tpm2-cmd.c | 106 +++-
  drivers/char/tpm/tpm_tis_core.c |   3 +-
  3 files changed, 80 insertions(+), 77 deletions(-)

--
2.7.4

Re: [PATCH RFC 0/2] Generalize tpm2_get_tpm_pt to tpm2_get_cap

[Nayna]

On 11/04/2016 12:58 PM, Jarkko Sakkinen wrote:

Nayna,

I've already sent these earlier this month as we had this discussion.
Please look up your emails. I can apply these if they look good for
you. Please review them.


Sure, I replied just now. I am sorry if delay in response. I was off 
early this week and still going through all mails.


Thanks & Regards,
  - Nayna



/Jarkko

On Sun, Oct 09, 2016 at 01:14:14PM +0300, Jarkko Sakkinen wrote:

We need to generalize tpm2_get_tpm_pt to tpm2_get_cap in order to it be
suitable for grabbing handles, PCR banks and so forth.

Jarkko Sakkinen (2):
   tpm: move TPM 2.0 command and response constants to tpm2-cmd.c
   tpm: refactor tpm2_get_tpm_pt to tpm2_getcap_cmd

  drivers/char/tpm/tpm.h  |  48 ++
  drivers/char/tpm/tpm2-cmd.c | 106 +++-
  drivers/char/tpm/tpm_tis_core.c |   3 +-
  3 files changed, 80 insertions(+), 77 deletions(-)

--
2.7.4

Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules

[Javier Martinez Canillas]

Hello ChenYu

On Fri, Nov 11, 2016 at 12:01 AM, Chen-Yu Tsai  wrote:
> On Fri, Nov 11, 2016 at 5:42 AM, Rob Herring  wrote:

[snip]

>>
>> Do you have patches using this already. If not, it is starting to get
>> a bit late for v4.10.
>>
>> I can apply this, but then you'll just be pulling in other DT patches.
>
> Not sure what you mean by "using" this...
>
> I have patches which use this to add DT-based modalias entries for
> module auto-loading to i2c and sunxi-rsb that I haven't sent.
>

Unfortunately the I2C core can't be changed without breaking a lot of
I2C drivers that are relying on the current behavior. I've already
posted a RFC patch [0] for I2C that does this about a year ago and
enumerated the issues that have to be addressed before the change can
be made (and fixed some of the issues mentioned) on this series [1].

Another issue is that an I2C device ID table is a requirement anyways
since I2C drivers expect an i2c_device_id as an argument of their
probe function. Kieran already have patches [2] to change that which
should land soon.

I plan to fix the remaining I2C drivers once his patches are merged
and re-post the RFC patch as a proper one.

> As far as DT usage goes, we already need this for the axp20x mfd driver.
> There are 2 variants, i2c and sunxi-rsb. For the I2C variant a fix was
> sent to fix module auto-loading by using the I2C client ID table:
>
> mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
> 
> https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next=b7142a19321484bd7681aa547c1d50148c8e2825
>

Yes, this is the workaround used by most DT-only I2C drivers. The only
reason that these drivers have an I2C device ID is due the
restrictions imposed by the I2C core.

Best regards,
Javier

Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules

[Javier Martinez Canillas]

Hello ChenYu

On Fri, Nov 11, 2016 at 12:01 AM, Chen-Yu Tsai  wrote:
> On Fri, Nov 11, 2016 at 5:42 AM, Rob Herring  wrote:

[snip]

>>
>> Do you have patches using this already. If not, it is starting to get
>> a bit late for v4.10.
>>
>> I can apply this, but then you'll just be pulling in other DT patches.
>
> Not sure what you mean by "using" this...
>
> I have patches which use this to add DT-based modalias entries for
> module auto-loading to i2c and sunxi-rsb that I haven't sent.
>

Unfortunately the I2C core can't be changed without breaking a lot of
I2C drivers that are relying on the current behavior. I've already
posted a RFC patch [0] for I2C that does this about a year ago and
enumerated the issues that have to be addressed before the change can
be made (and fixed some of the issues mentioned) on this series [1].

Another issue is that an I2C device ID table is a requirement anyways
since I2C drivers expect an i2c_device_id as an argument of their
probe function. Kieran already have patches [2] to change that which
should land soon.

I plan to fix the remaining I2C drivers once his patches are merged
and re-post the RFC patch as a proper one.

> As far as DT usage goes, we already need this for the axp20x mfd driver.
> There are 2 variants, i2c and sunxi-rsb. For the I2C variant a fix was
> sent to fix module auto-loading by using the I2C client ID table:
>
> mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
> 
> https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next=b7142a19321484bd7681aa547c1d50148c8e2825
>

Yes, this is the workaround used by most DT-only I2C drivers. The only
reason that these drivers have an I2C device ID is due the
restrictions imposed by the I2C core.

Best regards,
Javier

Re: [PATCH 05/35] staging: lustre: llog: fix wrong offset in llog_process_thread()

[kbuild test robot]

Hi Mikhail,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20161110]
[cannot apply to v4.9-rc4]
[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/James-Simmons/second-batch-of-missing-lustre-2-8-patches/2016-021225
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

>> ERROR: "__umoddi3" [drivers/staging/lustre/lustre/obdclass/obdclass.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 05/35] staging: lustre: llog: fix wrong offset in llog_process_thread()

[kbuild test robot]

Hi Mikhail,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20161110]
[cannot apply to v4.9-rc4]
[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/James-Simmons/second-batch-of-missing-lustre-2-8-patches/2016-021225
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

>> ERROR: "__umoddi3" [drivers/staging/lustre/lustre/obdclass/obdclass.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC

[Rik van Riel]

On Thu, 2016-11-10 at 13:23 -0800, Kees Cook wrote:

> If we don't use opt-out for atomics, we're going to be in the same
> situation where we have to constantly review every commit with an
> atomic for exploitable refcount flaws. Kicking this down from
> "privilege escalation" to "DoS" is a significant change in the
> kernel's weaknesses.

The only way I see around that would be to totally get
rid of the name atomic_t, forcing people with out of
tree code to use kref_t, or whatever name we pick for
the variable type that can wrap.

Something like checkpatch or a patch checking bot
could warn whenever new code is submitted that uses
the counter type that can wrap.

Not sure whether I like my idea :)

-- 
All Rights Reversed.

signature.asc
Description: This is a digitally signed message part

Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC

[Rik van Riel]

On Thu, 2016-11-10 at 13:23 -0800, Kees Cook wrote:

> If we don't use opt-out for atomics, we're going to be in the same
> situation where we have to constantly review every commit with an
> atomic for exploitable refcount flaws. Kicking this down from
> "privilege escalation" to "DoS" is a significant change in the
> kernel's weaknesses.

The only way I see around that would be to totally get
rid of the name atomic_t, forcing people with out of
tree code to use kref_t, or whatever name we pick for
the variable type that can wrap.

Something like checkpatch or a patch checking bot
could warn whenever new code is submitted that uses
the counter type that can wrap.

Not sure whether I like my idea :)

-- 
All Rights Reversed.

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

[Stefan Agner]

On 2016-11-10 10:29, Vladimir Zapolskiy wrote:
> Hi Stefan, Philipp,
> 
> On 11/09/2016 02:50 AM, Stefan Agner wrote:
>> On 2016-11-08 09:33, maitysancha...@gmail.com wrote:
>>> Hello Shawn,
>>> 
>>> On 16-10-22 15:43:04, Vladimir Zapolskiy wrote:
 Hi Shawn,
 
 On 10/22/2016 06:25 AM, Shawn Guo wrote:
> On Mon, Sep 19, 2016 at 10:41:51AM +0530, Sanchayan Maity wrote:
>> Remove the use of DDC I2C bus bitbang to support reading of EDID
>> and rely on support from internal HDMI I2C master controller instead.
>> As a result remove the device tree property ddc-i2c-bus.
>> 
>> Signed-off-by: Sanchayan Maity 
> 
> I think that the dw-hdmi i2c support [1] is a prerequisite of this
> patch.  I do not see it lands on v4.9-rc1.  Or am I missing something?
> 
> Shawn
> 
> [1] https://patchwork.kernel.org/patch/9296883/
> 
 
 I'm adding Philipp to Cc, since he is the last one who tested the change
 and helped me to push the change to the mainline:
 
   
 https://lists.freedesktop.org/archives/dri-devel/2016-September/118569.html
 
 The problem is that there is no official DW HDMI bridge maintainer, may be
 you can review the change, and if you find it satisfactory push it through
 ARM/iMX tree.
>>> 
>>> Shawn, is it okay if that patch goes through your ARM/iMX tree?
>> 
>> I don't think it makes sense that the DRM bridge changes go through
>> Shawn's tree. Dave should merge Philipps pull request...
>> 
> 
> Philipp, do you mind to submit a rebased pull request one more time?
> 

You probably saw it, Dave merged it today in his drm-next branch:
https://cgit.freedesktop.org/~airlied/linux/?h=drm-next

I guess with that Shawn can go ahead and merge this patchset for next
too...?

--
Stefan

Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

[Stefan Agner]

On 2016-11-10 10:29, Vladimir Zapolskiy wrote:
> Hi Stefan, Philipp,
> 
> On 11/09/2016 02:50 AM, Stefan Agner wrote:
>> On 2016-11-08 09:33, maitysancha...@gmail.com wrote:
>>> Hello Shawn,
>>> 
>>> On 16-10-22 15:43:04, Vladimir Zapolskiy wrote:
 Hi Shawn,
 
 On 10/22/2016 06:25 AM, Shawn Guo wrote:
> On Mon, Sep 19, 2016 at 10:41:51AM +0530, Sanchayan Maity wrote:
>> Remove the use of DDC I2C bus bitbang to support reading of EDID
>> and rely on support from internal HDMI I2C master controller instead.
>> As a result remove the device tree property ddc-i2c-bus.
>> 
>> Signed-off-by: Sanchayan Maity 
> 
> I think that the dw-hdmi i2c support [1] is a prerequisite of this
> patch.  I do not see it lands on v4.9-rc1.  Or am I missing something?
> 
> Shawn
> 
> [1] https://patchwork.kernel.org/patch/9296883/
> 
 
 I'm adding Philipp to Cc, since he is the last one who tested the change
 and helped me to push the change to the mainline:
 
   
 https://lists.freedesktop.org/archives/dri-devel/2016-September/118569.html
 
 The problem is that there is no official DW HDMI bridge maintainer, may be
 you can review the change, and if you find it satisfactory push it through
 ARM/iMX tree.
>>> 
>>> Shawn, is it okay if that patch goes through your ARM/iMX tree?
>> 
>> I don't think it makes sense that the DRM bridge changes go through
>> Shawn's tree. Dave should merge Philipps pull request...
>> 
> 
> Philipp, do you mind to submit a rebased pull request one more time?
> 

You probably saw it, Dave merged it today in his drm-next branch:
https://cgit.freedesktop.org/~airlied/linux/?h=drm-next

I guess with that Shawn can go ahead and merge this patchset for next
too...?

--
Stefan

Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi Peter,

On 11/10/2016 07:44 PM, Peter Zijlstra wrote:
> On Thu, Nov 10, 2016 at 09:56:41AM +0100, Thomas Gleixner wrote:
>> On Thu, 10 Nov 2016, Lu Baolu wrote:
>>> This seems to be a common issue for all early printk drivers.
>> No. The other early printk drivers like serial do not have that problem as
>> they simply do:
>>
>>while (*buf) {
>>   while (inb(UART) & TX_BUSY)
>>   cpu_relax();
>>   outb(*buf++, UART);
>>}
> Right, which is why actual UARTs rule. If only laptops still had pinouts
> for them life would be so much better.
>
> Ideally the USB debug port would be a virtual UART and its interface as
> simple and robust.
>
>> The wait for the UART to become ready is independent of the context as it
>> solely depends on the hardware.
>>
>> As a result you can see the output from irq/nmi intermingled with the one
>> from thread context, but that's the only problem they have.
>>
>> The only thing you can do to make this work is to prevent printing in NMI
>> context:
>>
>> write()
>> {
>>  if (in_nmi())
>>  return;
>>  
>>  raw_spinlock_irqsave(, flags);
>>  
>>
>> That fully serializes the writes and just ignores NMI context printks. Not
>> optimal, but I fear that's all you can do.
> I would also suggest telling the hardware people they have designed
> something near the brink of useless. If you cannot do random exception
> context debugging (#DB, #NMI, #MCE etc..) then there's a whole host of
> problems that simply cannot be debugged.
>
> Also note that kdb runs from NMI context, so you'll not be able to
> support that either.
>

Things become complicated when it comes to USB debug port.
But it's still addressable.

At this time, we can do it like this.

write()
{
if (in_nmi() && raw_spin_is_locked())
return;

raw_spinlock_irqsave(, flags);



This will filter some messages from NMI handler in case that
another thread is holding the spinlock. I have no idea about
how much chance could a debug user faces this. But it might
further be fixed with below enhancement.

write()
{
if (in_nmi() && raw_spin_is_locked()) {
produce_a_pending_item_in_ring();
return;
}

raw_spinlock_irqsave(, flags);

while (!pending_item_ring_is_empty)
consume_a_pending_item_in_ring();




We can design the pending item ring in a producer-consumer
model. It's easy to avoid race between the producer and
consumer.

Best regards,
Lu Baolu

Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi Peter,

On 11/10/2016 07:44 PM, Peter Zijlstra wrote:
> On Thu, Nov 10, 2016 at 09:56:41AM +0100, Thomas Gleixner wrote:
>> On Thu, 10 Nov 2016, Lu Baolu wrote:
>>> This seems to be a common issue for all early printk drivers.
>> No. The other early printk drivers like serial do not have that problem as
>> they simply do:
>>
>>while (*buf) {
>>   while (inb(UART) & TX_BUSY)
>>   cpu_relax();
>>   outb(*buf++, UART);
>>}
> Right, which is why actual UARTs rule. If only laptops still had pinouts
> for them life would be so much better.
>
> Ideally the USB debug port would be a virtual UART and its interface as
> simple and robust.
>
>> The wait for the UART to become ready is independent of the context as it
>> solely depends on the hardware.
>>
>> As a result you can see the output from irq/nmi intermingled with the one
>> from thread context, but that's the only problem they have.
>>
>> The only thing you can do to make this work is to prevent printing in NMI
>> context:
>>
>> write()
>> {
>>  if (in_nmi())
>>  return;
>>  
>>  raw_spinlock_irqsave(, flags);
>>  
>>
>> That fully serializes the writes and just ignores NMI context printks. Not
>> optimal, but I fear that's all you can do.
> I would also suggest telling the hardware people they have designed
> something near the brink of useless. If you cannot do random exception
> context debugging (#DB, #NMI, #MCE etc..) then there's a whole host of
> problems that simply cannot be debugged.
>
> Also note that kdb runs from NMI context, so you'll not be able to
> support that either.
>

Things become complicated when it comes to USB debug port.
But it's still addressable.

At this time, we can do it like this.

write()
{
if (in_nmi() && raw_spin_is_locked())
return;

raw_spinlock_irqsave(, flags);



This will filter some messages from NMI handler in case that
another thread is holding the spinlock. I have no idea about
how much chance could a debug user faces this. But it might
further be fixed with below enhancement.

write()
{
if (in_nmi() && raw_spin_is_locked()) {
produce_a_pending_item_in_ring();
return;
}

raw_spinlock_irqsave(, flags);

while (!pending_item_ring_is_empty)
consume_a_pending_item_in_ring();




We can design the pending item ring in a producer-consumer
model. It's easy to avoid race between the producer and
consumer.

Best regards,
Lu Baolu