Re: [PATCH v1] spi: fix client driver breakages when using GPIO descriptors

[Grant Likely]

On 18/11/2020 11:40, Mark Brown wrote:

On Wed, Nov 18, 2020 at 02:03:41AM +0100, Linus Walleij wrote:

On Mon, Nov 16, 2020 at 10:06 PM Mark Brown  wrote:



I think the main push in the other direction has always been people who
want to not have to write a driver at all and put absolutely everything
into DT which has scaling issues :/



What I can't understand is what gave them that idea.



This thing looks like a dream to these people for example:
https://gist.github.com/Minecrell/56c2b20118ba00a9723f0785301bc5ec#file-dsi_panel_s6e88a0_ams452ef01_qhd_octa_video-dtsi
And it looks like a nightmare to me.



(There is even a tool to convert this description into a proper display
driver now.)



It just seems to be one of those golden hammer things: everything
start to look like nails.


What people think they were sold was the idea that they shouldn't have
to write driver code or upstream things, something with more AML like
capabilities (not realising that AML works partly because ACPI hugely
constrains system design).


And is also untrue. AML only provides an API abstraction for a specific 
power management model. All the actual driving of the device still 
requires driver code and requires reading devices-specific properties 
out of the ACPI node.


g.

Re: [PATCH v1] spi: fix client driver breakages when using GPIO descriptors

[Grant Likely]

On 11/11/2020 13:36, Linus Walleij wrote:

On Wed, Nov 11, 2020 at 1:33 PM Mark Brown  wrote:

On Wed, Nov 11, 2020 at 02:05:19AM +0100, Linus Walleij wrote:



I would say that anything that has:



spi->mode = ...



is essentially broken.


This is not clear to me, most of these settings are things that are
constant for the device so it's not clear that they should be being set
by the device tree in the first place.


This was added initially with some two properties
in drivers/of/of_spi.c in 2008:
commit 284b01897340974000bcc84de87a4e1becc8a83d
"spi: Add OF binding support for SPI busses"

This was around the time ARM was first starting to migrate
to device tree, so I suppose it made sense to them/us back
then.

Some properties were the accumulated over time.

commit d57a4282d04810417c4ed2a49cbbeda8b3569b18
"spi/devicetree: Move devicetree support code into spi directory"
made this part of the SPI subsystem.

This seems as simple as nobody was there to push back and
say "wait the devices can specify that with code, don't put it
as properties in device tree". To be honest we have kind of
moved back and forward on that topic over time. :/


The idea that the chip select
might be being inverted like it is by this whole gpiolib/DT/new binding
thing is breaking expectations too.


OK I think you're right, then this patch probably brings the behaviour
back to expectations and it's how I should have done it in the first
place. My bad code :/
Reviewed-by: Linus Walleij 


The core sets up vital things in .mode from e.g. device tree in
of_spi_parse_dt():



 /* Mode (clock phase/polarity/etc.) */
 if (of_property_read_bool(nc, "spi-cpha"))
 spi->mode |= SPI_CPHA;
 if (of_property_read_bool(nc, "spi-cpol"))
 spi->mode |= SPI_CPOL;
 if (of_property_read_bool(nc, "spi-3wire"))
 spi->mode |= SPI_3WIRE;
 if (of_property_read_bool(nc, "spi-lsb-first"))
 spi->mode |= SPI_LSB_FIRST;
 if (of_property_read_bool(nc, "spi-cs-high"))
 spi->mode |= SPI_CS_HIGH;



All this gets overwritten and ignored when a client just assigns mode
like that. Not just SPI_CS_HIGH. I doubt things are different
with ACPI.


OTOH most of these are things the device driver should just get right
without needing any input from DT, there's a few where there's plausible
options (eg, you can imagine pin strap configuration for 3 wire mode)


Yes I actually ran into a case where the same Samsung display support
both 4 and 3-wire mode so that needs to be configured in the device
tree depending on the layout of the electronics. Arguably we should have
just standardized the device tree bindings and let the individual SPI
drivers parse that themselves in such cases.


so generally it's not clear how many of these make sense for anything
other than spidev.  This binding all predates my involvement so I don't
know the thought process here.


I dug out some details, let's see if Grant has some historical anecdotes
to add. The usage document from back then doesn't really say what
device properties should be encoded in the device tree and what
should just be assigned by code and e.g. determined from the
compatible-string. It was later that especially Rob pointed out that
random properties on device nodes was overused and that simply
knowing the compatible is often enough.


I think your analysis is correct. When this was done we were still
figuring stuff out and the abstraction between device and bus in SPI
isn't exactly clean. I don't have anything to add.

g.



I don't know if we ever formalized it, there is nowadays a rule akin to

"if a property can be determined from the compatible-string, and if the
  compatible-string is identifying the variant of the electronic component,
  then do not add this property to the device tree description. Just
  deduce it from the compatible-string, assign it with code to the device
  model of the operating system and handle it inside the operating system."

I think this, while clear and intuitive, wasn't at all clear and intuitive in
the recent past.

Yours,
Linus Walleij


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [net-next PATCH v1] net: phy: Move of_mdio from drivers/of to drivers/net/mdio

[Grant Likely]

On 08/10/2020 15:47, Calvin Johnson wrote:

Better place for of_mdio.c is drivers/net/mdio.
Move of_mdio.c from drivers/of to drivers/net/mdio

Signed-off-by: Calvin Johnson 


In-Principle-Acked-By: Grant Likely 

... but I've not tested or compiled *anything*!

g.


---

  MAINTAINERS| 2 +-
  drivers/net/mdio/Kconfig   | 8 
  drivers/net/mdio/Makefile  | 2 ++
  drivers/{of => net/mdio}/of_mdio.c | 0
  drivers/of/Kconfig | 7 ---
  drivers/of/Makefile| 1 -
  6 files changed, 11 insertions(+), 9 deletions(-)
  rename drivers/{of => net/mdio}/of_mdio.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8ff71b1a4a99..d1b82a3a1843 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6525,9 +6525,9 @@ F:Documentation/devicetree/bindings/net/mdio*
  F:Documentation/devicetree/bindings/net/qca,ar803x.yaml
  F:Documentation/networking/phy.rst
  F:drivers/net/mdio/
+F: drivers/net/mdio/of_mdio.c
  F:drivers/net/pcs/
  F:drivers/net/phy/
-F: drivers/of/of_mdio.c
  F:drivers/of/of_net.c
  F:include/dt-bindings/net/qca-ar803x.h
  F:include/linux/*mdio*.h
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
index 27a2a4a3d943..a10cc460d7cf 100644
--- a/drivers/net/mdio/Kconfig
+++ b/drivers/net/mdio/Kconfig
@@ -19,6 +19,14 @@ config MDIO_BUS
  reflects whether the mdio_bus/mdio_device code is built as a
  loadable module or built-in.
  
+config OF_MDIO

+   def_tristate PHYLIB
+   depends on OF
+   depends on PHYLIB
+   select FIXED_PHY
+   help
+ OpenFirmware MDIO bus (Ethernet PHY) accessors
+
  if MDIO_BUS
  
  config MDIO_DEVRES

diff --git a/drivers/net/mdio/Makefile b/drivers/net/mdio/Makefile
index 14d1beb633c9..5c498dde463f 100644
--- a/drivers/net/mdio/Makefile
+++ b/drivers/net/mdio/Makefile
@@ -1,6 +1,8 @@
  # SPDX-License-Identifier: GPL-2.0
  # Makefile for Linux MDIO bus drivers
  
+obj-$(CONFIG_OF_MDIO)	+= of_mdio.o

+
  obj-$(CONFIG_MDIO_ASPEED) += mdio-aspeed.o
  obj-$(CONFIG_MDIO_BCM_IPROC)  += mdio-bcm-iproc.o
  obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
diff --git a/drivers/of/of_mdio.c b/drivers/net/mdio/of_mdio.c
similarity index 100%
rename from drivers/of/of_mdio.c
rename to drivers/net/mdio/of_mdio.c
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index d91618641be6..18450437d5d5 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -74,13 +74,6 @@ config OF_NET
depends on NETDEVICES
def_bool y
  
-config OF_MDIO

-   def_tristate PHYLIB
-   depends on PHYLIB
-   select FIXED_PHY
-   help
- OpenFirmware MDIO bus (Ethernet PHY) accessors
-
  config OF_RESERVED_MEM
bool
depends on OF_EARLY_FLATTREE
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 663a4af0cccd..6e1e5212f058 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_OF_ADDRESS)  += address.o
  obj-$(CONFIG_OF_IRQ)+= irq.o
  obj-$(CONFIG_OF_NET)  += of_net.o
  obj-$(CONFIG_OF_UNITTEST) += unittest.o
-obj-$(CONFIG_OF_MDIO)  += of_mdio.o
  obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
  obj-$(CONFIG_OF_RESOLVE)  += resolver.o
  obj-$(CONFIG_OF_OVERLAY) += overlay.o

Re: [net-next PATCH v1 6/7] net: dpaa2-mac: Add ACPI support for DPAA2 MAC driver

[Grant Likely]

On 30/09/2020 17:04, Calvin Johnson wrote:

Modify dpaa2_mac_connect() to support ACPI along with DT.
Modify dpaa2_mac_get_node() to get the dpmac fwnode from either
DT or ACPI.

Replace of_get_phy_mode with fwnode_get_phy_mode to get
phy-mode for a dpmac_node.

Use helper function phylink_fwnode_phy_connect() to find phy_dev and
connect to mac->phylink.

Signed-off-by: Calvin Johnson 
---

  .../net/ethernet/freescale/dpaa2/dpaa2-mac.c  | 79 ---
  1 file changed, 50 insertions(+), 29 deletions(-)

diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c 
b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
index 90cd243070d7..18502ee83e46 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
@@ -3,6 +3,7 @@
  
  #include "dpaa2-eth.h"

  #include "dpaa2-mac.h"
+#include 
  
  #define phylink_to_dpaa2_mac(config) \

container_of((config), struct dpaa2_mac, phylink_config)
@@ -35,38 +36,56 @@ static int phy_mode(enum dpmac_eth_if eth_if, 
phy_interface_t *if_mode)
  }
  
  /* Caller must call of_node_put on the returned value */

-static struct device_node *dpaa2_mac_get_node(u16 dpmac_id)
+static struct fwnode_handle *dpaa2_mac_get_node(struct device *dev,
+   u16 dpmac_id)
  {
-   struct device_node *dpmacs, *dpmac = NULL;
-   u32 id;
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   struct fwnode_handle *dpmacs, *dpmac = NULL;
+   unsigned long long adr;
+   acpi_status status;
int err;
+   u32 id;
  
-	dpmacs = of_find_node_by_name(NULL, "dpmacs");

-   if (!dpmacs)
-   return NULL;
+   if (is_of_node(dev->parent->fwnode)) {
+   dpmacs = device_get_named_child_node(dev->parent, "dpmacs");
+   if (!dpmacs)
+   return NULL;
+
+   while ((dpmac = fwnode_get_next_child_node(dpmacs, dpmac))) {
+   err = fwnode_property_read_u32(dpmac, "reg", );
+   if (err)
+   continue;
+   if (id == dpmac_id)
+   return dpmac;
+   }
There is a change of behaviour here that isn't described in the patch 
description, so I'm having trouble following the intent. The original 
code searches the tree for a node named "dpmacs", but the new code 
constrains the search to just the parent device.


Also, because the new code path is only used in the DT case, I don't see 
why the behaviour change is required. If it is a bug fix, it should be 
broken out into a separate patch. If it is something else, can you 
describe what the reasoning is?


I also see that the change to the code has dropped the of_node_put() on 
the exit path.


  
-	while ((dpmac = of_get_next_child(dpmacs, dpmac)) != NULL) {

-   err = of_property_read_u32(dpmac, "reg", );
-   if (err)
-   continue;
-   if (id == dpmac_id)
-   break;
+   } else if (is_acpi_node(dev->parent->fwnode)) {
+   device_for_each_child_node(dev->parent, dpmac) {
+   status = 
acpi_evaluate_integer(ACPI_HANDLE_FWNODE(dpmac),
+  "_ADR", NULL, );
+   if (ACPI_FAILURE(status)) {
+   pr_debug("_ADR returned %d on %s\n",
+status, (char *)buffer.pointer);
+   continue;
+   } else {
+   id = (u32)adr;
+   if (id == dpmac_id)
+   return dpmac;
+   }
+   }
}
-
-   of_node_put(dpmacs);
-
-   return dpmac;
+   return NULL;
  }
  
-static int dpaa2_mac_get_if_mode(struct device_node *node,

+static int dpaa2_mac_get_if_mode(struct fwnode_handle *dpmac_node,
 struct dpmac_attr attr)
  {
phy_interface_t if_mode;
int err;
  
-	err = of_get_phy_mode(node, _mode);

-   if (!err)
-   return if_mode;
+   err = fwnode_get_phy_mode(dpmac_node);
+   if (err > 0)
+   return err;


Is this correct? The function prototype from patch 2 is:

struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)

It returns struct fwnode_handle *. Does this compile?

  
  	err = phy_mode(attr.eth_if, _mode);

if (!err)
@@ -303,7 +322,7 @@ int dpaa2_mac_connect(struct dpaa2_mac *mac)
  {
struct fsl_mc_device *dpmac_dev = mac->mc_dev;
struct net_device *net_dev = mac->net_dev;
-   struct device_node *dpmac_node;
+   struct fwnode_handle *dpmac_node = NULL;
struct phylink *phylink;
struct dpmac_attr attr;
int err;
@@ -323,7 +342,7 @@ int 

Re: [net-next PATCH v1 1/7] Documentation: ACPI: DSD: Document MDIO PHY

[Grant Likely]

On 30/09/2020 17:37, Rafael J. Wysocki wrote:

On Wed, Sep 30, 2020 at 6:05 PM Calvin Johnson
 wrote:


Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.

Describe properties "phy-handle" and "phy-mode".

Signed-off-by: Calvin Johnson 
---

  Documentation/firmware-guide/acpi/dsd/phy.rst | 78 +++
  1 file changed, 78 insertions(+)
  create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst

diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst 
b/Documentation/firmware-guide/acpi/dsd/phy.rst
new file mode 100644
index ..f10feb24ec1c
--- /dev/null
+++ b/Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,78 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+MDIO bus and PHYs in ACPI
+=
+
+The PHYs on an mdiobus are probed and registered using
+fwnode_mdiobus_register_phy().
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+mdiobus have to be referenced.
+
+phy-handle
+---
+For each MAC node, a property "phy-handle" is used to reference the
+PHY that is registered on an MDIO bus.


It is not clear what "a property" means in this context.

This should refer to the documents introducing the _DSD-based generic
device properties rules, including the GUID used below.

You need to say whether or not the property is mandatory and if it
isn't mandatory, you need to say what the lack of it means.


+
+phy-mode
+
+Property "phy-mode" defines the type of PHY interface.


This needs to be more detailed too, IMO.  At the very least, please
list all of the possible values of it and document their meaning.


If the goal is to align with DT, it would be appropriate to point to 
where those properties are defined for DT rather than to have a separate 
description here. I suggest something along the lines of:


   The "phy-mode" _DSD property is used to describe the connection to
   the PHY. The valid values for "phy-mode" are defined in
   Documentation/devicetree/bindings/ethernet-controller.yaml




+
+An example of this is shown below::
+
+DSDT entry for MACs where PHY nodes are referenced
+--
+   Scope(\_SB.MCE0.PR17) // 1G
+   {
+ Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+Package (2) {"phy-mode", "rgmii-id"},
+Package (2) {"phy-handle", Package (){\_SB.MDI0.PHY1}}


What is "phy-handle"?

You haven't introduced it above.


Can you elaborate? "phy-handle" has a section to itself in this 
document. Agree that it needs to be defined more, but it does read to me 
as having been defined.





+ }
+  })
+   }
+
+   Scope(\_SB.MCE0.PR18) // 1G
+   {
+ Name (_DSD, Package () {
+   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+   Package () {
+   Package (2) {"phy-mode", "rgmii-id"},
+   Package (2) {"phy-handle", Package (){\_SB.MDI0.PHY2}}
+   }
+ })
+   }
+
+DSDT entry for MDIO node
+
+a) Silicon Component


What is this device, exactly?


+
+   Scope(_SB)
+   {
+ Device(MDI0) {
+   Name(_HID, "NXP0006")
+   Name(_CCA, 1)
+   Name(_UID, 0)
+   Name(_CRS, ResourceTemplate() {
+ Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)
+ Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
+  {
+MDI0_IT
+  }
+   }) // end of _CRS for MDI0
+ } // end of MDI0
+   }
+
+b) Platform Component
+-
+   Scope(\_SB.MDI0)
+   {
+ Device(PHY1) {
+   Name (_ADR, 0x1)
+ } // end of PHY1
+
+ Device(PHY2) {
+   Name (_ADR, 0x2)
+ } // end of PHY2
+   }
--


What is the connection between the last two pieces of ASL and the _DSD
definitions above?

Re: [net-next PATCH v1 3/7] net: phy: Introduce fwnode_get_phy_id()

[Grant Likely]

On 30/09/2020 17:04, Calvin Johnson wrote:

Extract phy_id from compatible string. This will be used by
fwnode_mdiobus_register_phy() to create phy device using the
phy_id.

Signed-off-by: Calvin Johnson 
---

  drivers/net/phy/phy_device.c | 32 +++-
  include/linux/phy.h  |  5 +
  2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index c4aec56d0a95..162abde6223d 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -9,6 +9,7 @@
  
  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
  
+#include 

  #include 
  #include 
  #include 
@@ -845,6 +846,27 @@ static int get_phy_c22_id(struct mii_bus *bus, int addr, 
u32 *phy_id)
return 0;
  }
  
+/* Extract the phy ID from the compatible string of the form

+ * ethernet-phy-id..
+ */
+int fwnode_get_phy_id(struct fwnode_handle *fwnode, u32 *phy_id)
+{
+   unsigned int upper, lower;
+   const char *cp;
+   int ret;
+
+   ret = fwnode_property_read_string(fwnode, "compatible", );
+   if (ret)
+   return ret;
+
+   if (sscanf(cp, "ethernet-phy-id%4x.%4x", , ) == 2) {
+   *phy_id = ((upper & 0x) << 16) | (lower & 0x);
+   return 0;
+   }
+   return -EINVAL;
+}
+EXPORT_SYMBOL(fwnode_get_phy_id);


This block, and the changes in patch 4 duplicate functions from 
drivers/of/of_mdio.c, but it doesn't refactor anything in 
drivers/of/of_mdio.c to use the new path. Is your intent to bring all of 
the parsing in these functions of "compatible" into the ACPI code path?


If so, then the existing code path needs to be refactored to work with 
fwnode_handle instead of device_node.


If not, then the DT path in these functions should call out to of_mdio, 
while the ACPI path only does what is necessary.



+
  /**
   * get_phy_device - reads the specified PHY device and returns its @phy_device
   *struct
@@ -2866,7 +2888,15 @@ EXPORT_SYMBOL_GPL(device_phy_find_device);
   */
  struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
  {
-   return fwnode_find_reference(fwnode, "phy-handle", 0);
+   struct fwnode_handle *phy_node;
+
+   phy_node = fwnode_find_reference(fwnode, "phy-handle", 0);
+   if (is_acpi_node(fwnode) || !IS_ERR(phy_node))
+   return phy_node;
+   phy_node = fwnode_find_reference(fwnode, "phy", 0);
+   if (IS_ERR(phy_node))
+   phy_node = fwnode_find_reference(fwnode, "phy-device", 0);
+   return phy_node;
  }
  EXPORT_SYMBOL_GPL(fwnode_get_phy_node);
  
diff --git a/include/linux/phy.h b/include/linux/phy.h

index 7b1bf3d46fd3..b6814e04092f 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1378,6 +1378,7 @@ struct phy_device *phy_device_create(struct mii_bus *bus, 
int addr, u32 phy_id,
 bool is_c45,
 struct phy_c45_device_ids *c45_ids);
  #if IS_ENABLED(CONFIG_PHYLIB)
+int fwnode_get_phy_id(struct fwnode_handle *fwnode, u32 *phy_id);
  struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode);
  struct phy_device *device_phy_find_device(struct device *dev);
  struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode);
@@ -1385,6 +1386,10 @@ struct phy_device *get_phy_device(struct mii_bus *bus, 
int addr, bool is_c45);
  int phy_device_register(struct phy_device *phy);
  void phy_device_free(struct phy_device *phydev);
  #else
+static inline int fwnode_get_phy_id(struct fwnode_handle *fwnode, u32 *phy_id)
+{
+   return 0;
+}
  static inline
  struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode)
  {

Re: [net-next PATCH v1 3/7] net: phy: Introduce fwnode_get_phy_id()

[Grant Likely]

On 01/10/2020 05:00, Calvin Johnson wrote:

On Wed, Sep 30, 2020 at 08:19:02PM +0200, Andrew Lunn wrote:

On Wed, Sep 30, 2020 at 07:07:25PM +0100, Russell King - ARM Linux admin wrote:

On Wed, Sep 30, 2020 at 06:34:40PM +0200, Andrew Lunn wrote:

@@ -2866,7 +2888,15 @@ EXPORT_SYMBOL_GPL(device_phy_find_device);
   */
  struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
  {
-   return fwnode_find_reference(fwnode, "phy-handle", 0);
+   struct fwnode_handle *phy_node;
+
+   phy_node = fwnode_find_reference(fwnode, "phy-handle", 0);
+   if (is_acpi_node(fwnode) || !IS_ERR(phy_node))
+   return phy_node;
+   phy_node = fwnode_find_reference(fwnode, "phy", 0);
+   if (IS_ERR(phy_node))
+   phy_node = fwnode_find_reference(fwnode, "phy-device", 0);
+   return phy_node;


Why do you have three different ways to reference a PHY?


Compatibility with the DT version - note that "phy" and "phy-device"
are only used for non-ACPI fwnodes. This should allow us to convert
drivers where necessary without fear of causing DT regressions.


Ah.

A comment would be good here.


Sure. Will add comment.


Actually, I agree with Andrew. I don't see why new properties are being 
defined for following a reference from a property to a PHY node. This 
function shouldn't need to change at all.


g.

Re: [PATCH 1/1] of: properties of reserved-memory nodes

[Grant Likely]

On 10/09/2020 17:20, Heinrich Schuchardt wrote:

The reusable and the no-map property are mutually exclusive.
Clarify this in the documentation.

Signed-off-by: Heinrich Schuchardt 


Acked-by: Grant Likely 


---
  .../devicetree/bindings/reserved-memory/reserved-memory.txt| 3 +++
  1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index bac4afa3b197..eb987203548f 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -64,6 +64,9 @@ reusable (optional) - empty property
system can use that region to store volatile or cached data that
can be otherwise regenerated or migrated elsewhere.

+A node must not carry both the no-map and the reusable property as these are
+logically contradictory.
+
  Linux implementation note:
  - If a "linux,cma-default" property is present, then Linux will use the
region for the default pool of the contiguous memory allocator.
--
2.28.0

[PATCH] hid-input: Fix devices that return multiple bytes in battery report

[Grant Likely]

Some devices, particularly the 3DConnexion Spacemouse wireless 3D
controllers, return more than just the battery capacity in the battery
report. The Spacemouse devices return an additional byte with a device
specific field. However, hidinput_query_battery_capacity() only
requests a 2 byte transfer.

When a spacemouse is connected via USB (direct wire, no wireless dongle)
and it returns a 3 byte report instead of the assumed 2 byte battery
report the larger transfer confuses and frightens the USB subsystem
which chooses to ignore the transfer. Then after 2 seconds assume the
device has stopped responding and reset it. This can be reproduced
easily by using a wired connection with a wireless spacemouse. The
Spacemouse will enter a loop of resetting every 2 seconds which can be
observed in dmesg.

This patch solves the problem by increasing the transfer request to 4
bytes instead of 2. The fix isn't particularly elegant, but it is simple
and safe to backport to stable kernels. A further patch will follow to
more elegantly handle battery reports that contain additional data.

Signed-off-by: Grant Likely 
Cc: Darren Hart 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: sta...@vger.kernel.org
---
 drivers/hid/hid-input.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index dea9cc65bf80..e8641ce677e4 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -350,13 +350,13 @@ static int hidinput_query_battery_capacity(struct 
hid_device *dev)
u8 *buf;
int ret;
 
-   buf = kmalloc(2, GFP_KERNEL);
+   buf = kmalloc(4, GFP_KERNEL);
if (!buf)
return -ENOMEM;
 
-   ret = hid_hw_raw_request(dev, dev->battery_report_id, buf, 2,
+   ret = hid_hw_raw_request(dev, dev->battery_report_id, buf, 4,
 dev->battery_report_type, HID_REQ_GET_REPORT);
-   if (ret != 2) {
+   if (ret < 2) {
kfree(buf);
return -ENODATA;
}
-- 
2.20.1

Re: [PATCH v1 1/5] drivercore: Revert "deferral race condition fix"

[Grant Likely]

On 11/11/2018 19:26, Rob Herring wrote:
> On Sun, Nov 11, 2018 at 7:04 AM Andy Shevchenko
>  wrote:
>>
>> I seems Grant's mail delivery bounces messages. I delibirately reduced
>> the Cc list for sake of ping Grant in case it would pass.
>
> That would be because he is not at Linaro anymore. Added his ARM account.
>
>> On Sat, Nov 10, 2018 at 8:12 PM Andy Shevchenko
>>  wrote:
>>>
>>> Consider the following scenario.
>>>
>>> There are two independent devices coupled together by functional 
>>> dependencies:
>>>   - USB OTG (dwc3-pci)
>>>   - extcon (tested with extcon-intel-mrfld, not yet in upstream)
>>>
>>> Each of the driver services a corresponding device is built as a module. In 
>>> the
>>> Buildroot environment the modules are probed by alphabetical ordering of 
>>> their
>>> modaliases. The latter comes to the case when USB OTG driver will be probed
>>> first followed by extcon one.
>>>
>>> So, if the platform anticipates extcon device to be appeared, in the above 
>>> case
>>> we will get deferred probe of USB OTG, because of ordering.
>>>
>>> Now, a cherry on top of the cake, the deferred probing list contains
>>> the only two modules, i.e. USB OTG and extcon. Due to above circumstances,
>>> values in the local_trigger_count and deferred_trigger_count are not the 
>>> same,
>>> and thus provokes deferred probe triggering again and again.
>>>
>>> ...
>>> [   20.678332] platform dwc3.0.auto: Retrying from deferred list
>>> [   20.694743] platform dwc3.0.auto: Driver dwc3 requests probe deferral
>>> [   20.701254] platform dwc3.0.auto: Added to deferred list
>>> [   20.706620] platform dwc3.0.auto: driver_deferred_probe_add_trigger 1 2
>>> [   20.713732] platform dwc3.0.auto: Retrying from deferred list
>>> [   20.730035] platform dwc3.0.auto: Driver dwc3 requests probe deferral
>>> [   20.736540] platform dwc3.0.auto: Added to deferred list
>>> [   20.741889] platform dwc3.0.auto: driver_deferred_probe_add_trigger 3 4
>>> [   20.748991] platform dwc3.0.auto: Retrying from deferred list
>>> [   20.765416] platform dwc3.0.auto: Driver dwc3 requests probe deferral
>>> [   20.771914] platform dwc3.0.auto: Added to deferred list
>>> [   20.777279] platform dwc3.0.auto: driver_deferred_probe_add_trigger 5 6
>>> ...
>>>
>>> Deeper investigation shows the culprit commit 58b116bce136
>>> ("drivercore: deferral race condition fix") which was dedicated to fix some
>>> other issue while bringing a regression.
>>>
>>> This reverts commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 for good until
>>> we will have better solution.
>
> How is behavior that's been there for 4.5 years a regression? Aren't
> we going to break Davinci that this commit was supposed to fix? What
> else could be relying on current behavior?

It has been a long time since I looked at this code, but so this may be
totally wrong. Something is causing driver_deferred_probe_trigger to get
called. I suspect all of this is happening within the single probe
event. This driver creates nested devices, which are bound to there own
driver. If one of those child devices probes successfully, and then the
parent probe fails with -EPROBE_DEFER, does it cause the whole structure
to be torn down again? If so, then that's the cause. The successful
probe will cause the probe loop.

You should investigate what driver probe/remove events happen in the
failure case. That will tell you exactly what is happening.

g.


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH v1 1/5] drivercore: Revert "deferral race condition fix"

[Grant Likely]

On 11/11/2018 19:26, Rob Herring wrote:
> On Sun, Nov 11, 2018 at 7:04 AM Andy Shevchenko
>  wrote:
>>
>> I seems Grant's mail delivery bounces messages. I delibirately reduced
>> the Cc list for sake of ping Grant in case it would pass.
>
> That would be because he is not at Linaro anymore. Added his ARM account.
>
>> On Sat, Nov 10, 2018 at 8:12 PM Andy Shevchenko
>>  wrote:
>>>
>>> Consider the following scenario.
>>>
>>> There are two independent devices coupled together by functional 
>>> dependencies:
>>>   - USB OTG (dwc3-pci)
>>>   - extcon (tested with extcon-intel-mrfld, not yet in upstream)
>>>
>>> Each of the driver services a corresponding device is built as a module. In 
>>> the
>>> Buildroot environment the modules are probed by alphabetical ordering of 
>>> their
>>> modaliases. The latter comes to the case when USB OTG driver will be probed
>>> first followed by extcon one.
>>>
>>> So, if the platform anticipates extcon device to be appeared, in the above 
>>> case
>>> we will get deferred probe of USB OTG, because of ordering.
>>>
>>> Now, a cherry on top of the cake, the deferred probing list contains
>>> the only two modules, i.e. USB OTG and extcon. Due to above circumstances,
>>> values in the local_trigger_count and deferred_trigger_count are not the 
>>> same,
>>> and thus provokes deferred probe triggering again and again.
>>>
>>> ...
>>> [   20.678332] platform dwc3.0.auto: Retrying from deferred list
>>> [   20.694743] platform dwc3.0.auto: Driver dwc3 requests probe deferral
>>> [   20.701254] platform dwc3.0.auto: Added to deferred list
>>> [   20.706620] platform dwc3.0.auto: driver_deferred_probe_add_trigger 1 2
>>> [   20.713732] platform dwc3.0.auto: Retrying from deferred list
>>> [   20.730035] platform dwc3.0.auto: Driver dwc3 requests probe deferral
>>> [   20.736540] platform dwc3.0.auto: Added to deferred list
>>> [   20.741889] platform dwc3.0.auto: driver_deferred_probe_add_trigger 3 4
>>> [   20.748991] platform dwc3.0.auto: Retrying from deferred list
>>> [   20.765416] platform dwc3.0.auto: Driver dwc3 requests probe deferral
>>> [   20.771914] platform dwc3.0.auto: Added to deferred list
>>> [   20.777279] platform dwc3.0.auto: driver_deferred_probe_add_trigger 5 6
>>> ...
>>>
>>> Deeper investigation shows the culprit commit 58b116bce136
>>> ("drivercore: deferral race condition fix") which was dedicated to fix some
>>> other issue while bringing a regression.
>>>
>>> This reverts commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 for good until
>>> we will have better solution.
>
> How is behavior that's been there for 4.5 years a regression? Aren't
> we going to break Davinci that this commit was supposed to fix? What
> else could be relying on current behavior?

It has been a long time since I looked at this code, but so this may be
totally wrong. Something is causing driver_deferred_probe_trigger to get
called. I suspect all of this is happening within the single probe
event. This driver creates nested devices, which are bound to there own
driver. If one of those child devices probes successfully, and then the
parent probe fails with -EPROBE_DEFER, does it cause the whole structure
to be torn down again? If so, then that's the cause. The successful
probe will cause the probe loop.

You should investigate what driver probe/remove events happen in the
failure case. That will tell you exactly what is happening.

g.


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: drivers binding to device node with multiple compatible strings

[Grant Likely]

On 04/10/2018 10:32, Grant Likely wrote:

On Fri, Sep 28, 2018 at 10:01 PM Li Yang  wrote:


On Fri, Sep 28, 2018 at 3:07 PM Rob Herring  wrote:


On Thu, Sep 27, 2018 at 5:25 PM Li Yang  wrote:


Hi Rob and Grant,

Various device tree specs are recommending to include all the
potential compatible strings in the device node, with the order from
most specific to most general.  But it looks like Linux kernel doesn't
provide a way to bind the device to the most specific driver, however,
the first registered compatible driver will be bound.

As more and more generic drivers are added to the Linux kernel, they
are competing with the more specific vendor drivers and causes problem
when both are built into the kernel.  I'm wondering if there is a
generic solution (or in plan) to make the most specific driver bound
to the device.   Or we have to disable the more general driver or
remove the more general compatible string from the device tree?


It's been a known limitation for a long time. However, in practice it
doesn't seem to be a common problem. Perhaps folks just remove the
less specific compatible from their DT (though that's not ideal). For
most modern bindings, there's so many other resources beyond
compatible (clocks, resets, pinctrl, etc.) that there are few generic
drivers that can work.

I guess if we want to fix this, we'd need to have weighted matching in
the driver core and unbind drivers when we get a better match. Though
it could get messy if the better driver probe fails. Then we've got to
rebind to the original driver.


Probably we can populate the platform devices from device tree after
the device_init phase?  So that all built-in drivers are already
registered when the devices are created and we can try find the best
match in one go?  For more specific loadable modules we probably need
to unbind from the old driver and bind to the new one.  But I agree
with you that it could be messy.


It's a tradeoff.


Oops! Accidentally hit send too early.

It's a tradeoff. If the platform device population is deferred until 
after all drivers are loaded, then there isn't any mechanism to ensure 
some devices get probed early in the init sequence.


As Rob said, while it is a problem in theory, there haven't been a lot 
of actual cases where it is a problem. The solution has been to either 
remove the generic match from the device, or we can blacklist particular 
devices from the generic driver.


g.






Do you have a specific case where you hit this?


Maybe not a new issue but "snps,dw-pcie" is competing with various
"fsl,-pcie" compatibles.  Also a specific PHY
"ethernet-phy-id." with generic "ethernet-phy-ieee802.3-c45".

Regards,
Leo

Re: drivers binding to device node with multiple compatible strings

[Grant Likely]

On 04/10/2018 10:32, Grant Likely wrote:

On Fri, Sep 28, 2018 at 10:01 PM Li Yang  wrote:


On Fri, Sep 28, 2018 at 3:07 PM Rob Herring  wrote:


On Thu, Sep 27, 2018 at 5:25 PM Li Yang  wrote:


Hi Rob and Grant,

Various device tree specs are recommending to include all the
potential compatible strings in the device node, with the order from
most specific to most general.  But it looks like Linux kernel doesn't
provide a way to bind the device to the most specific driver, however,
the first registered compatible driver will be bound.

As more and more generic drivers are added to the Linux kernel, they
are competing with the more specific vendor drivers and causes problem
when both are built into the kernel.  I'm wondering if there is a
generic solution (or in plan) to make the most specific driver bound
to the device.   Or we have to disable the more general driver or
remove the more general compatible string from the device tree?


It's been a known limitation for a long time. However, in practice it
doesn't seem to be a common problem. Perhaps folks just remove the
less specific compatible from their DT (though that's not ideal). For
most modern bindings, there's so many other resources beyond
compatible (clocks, resets, pinctrl, etc.) that there are few generic
drivers that can work.

I guess if we want to fix this, we'd need to have weighted matching in
the driver core and unbind drivers when we get a better match. Though
it could get messy if the better driver probe fails. Then we've got to
rebind to the original driver.


Probably we can populate the platform devices from device tree after
the device_init phase?  So that all built-in drivers are already
registered when the devices are created and we can try find the best
match in one go?  For more specific loadable modules we probably need
to unbind from the old driver and bind to the new one.  But I agree
with you that it could be messy.


It's a tradeoff.


Oops! Accidentally hit send too early.

It's a tradeoff. If the platform device population is deferred until 
after all drivers are loaded, then there isn't any mechanism to ensure 
some devices get probed early in the init sequence.


As Rob said, while it is a problem in theory, there haven't been a lot 
of actual cases where it is a problem. The solution has been to either 
remove the generic match from the device, or we can blacklist particular 
devices from the generic driver.


g.






Do you have a specific case where you hit this?


Maybe not a new issue but "snps,dw-pcie" is competing with various
"fsl,-pcie" compatibles.  Also a specific PHY
"ethernet-phy-id." with generic "ethernet-phy-ieee802.3-c45".

Regards,
Leo

Re: [PATCH] efi_stub: update documentation on dtb= parameter

[Grant Likely]

> On 6 Sep 2018, at 16:51, Jonathan Corbet  wrote:
> 
> On Wed,  5 Sep 2018 20:07:50 +0100
> Grant Likely  wrote:
> 
>> The dtb= parameter is no longer the primary mechanism for providing a
>> devicetree to the kernel. Now either firmware or the boot selector (ex.
>> Grub) should provide the devicetree and dtb= should only be used for
>> debug or when using firmware that doesn't understand DT.
>> Update the EFI stub documentation to reflect the current usage.
> 
> So I hate to be obnoxious, but...
> 
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy
>> the information in any medium. Thank you.
> 
> Can I get a version of the patch without this language?  Then I'll be glad
> to apply it.

Ugh. Well that was dumb. There is a magic trick I have to perform to get rid of 
the disclaimer, but it didn’t work this time. I’ll fix and get a new one out.

g.

> 
> Thanks,
> 
> jon

Re: [PATCH] efi_stub: update documentation on dtb= parameter

[Grant Likely]

> On 6 Sep 2018, at 16:51, Jonathan Corbet  wrote:
> 
> On Wed,  5 Sep 2018 20:07:50 +0100
> Grant Likely  wrote:
> 
>> The dtb= parameter is no longer the primary mechanism for providing a
>> devicetree to the kernel. Now either firmware or the boot selector (ex.
>> Grub) should provide the devicetree and dtb= should only be used for
>> debug or when using firmware that doesn't understand DT.
>> Update the EFI stub documentation to reflect the current usage.
> 
> So I hate to be obnoxious, but...
> 
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy
>> the information in any medium. Thank you.
> 
> Can I get a version of the patch without this language?  Then I'll be glad
> to apply it.

Ugh. Well that was dumb. There is a magic trick I have to perform to get rid of 
the disclaimer, but it didn’t work this time. I’ll fix and get a new one out.

g.

> 
> Thanks,
> 
> jon

Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

[Grant Likely]

On Wed, Sep 5, 2018 at 10:37 AM Ard Biesheuvel
 wrote:
> On 4 September 2018 at 12:13, Grant Likely  wrote:
> > On Tue, Sep 4, 2018 at 7:24 AM Ard Biesheuvel  
> > wrote:
> >>
> >> On 2 September 2018 at 04:54, Olof Johansson  wrote:
> >> > On Thu, Aug 30, 2018 at 9:23 AM, Ard Biesheuvel
> >> >  wrote:
> >> >> On 30 August 2018 at 17:06, Olof Johansson  wrote:
> >> >>> On Wed, Aug 29, 2018 at 10:54 PM, Ard Biesheuvel
> >> >>>  wrote:
> >> >>>> Don't be surprised if some future enhancements of the EFI stub code
> >> >>>> depend on !EFI_ARMSTUB_DTB_LOADER.
> >
> > That's an odd statement to make. The DTB loader code is well contained
> > and with defined semantics... True, the semantics are "I DON'T BELIEVE
> > FIRMWARE", but it is still well defined. What scenario are you
> > envisioning where EFI_ARMSTUB_DTB_LOADER would be explicitly excluded?
> >
>
> Well, to be honest, I don't have a real-world example at hand, but my
> concern is about cases where the firmware provided DTB and the
> override DTB diverge in a way that leaves it up to the EFI stub to
> reconcile them and/or to reason about which one it should prefer.
>
> One example could be OP-TEE support: currently, we put a
> /firmware/optee node in the DT to inform the OS that OP-TEE is running
> in the secure world. If we allow a DT to be provided via dtb= that
> provides such a node, we are blocking all future opportunities in
> future kernels to do any kind of preparatory OP-TEE related
> initialization in the EFI stub [while boot services are still
> available] unless we decide to make it the EFI stub's problem to
> reason about which version of the DT is the correct one to use. What
> if the firmware's DT has /firmware/optee/status = disabled and the
> dtb= one does not?
>
> Another trivial example is GRUB: passing dtb= via the command line
> will break initrds loaded via GRUB, since they are passed via the
> /chosen node.

Using 'dtb=' straight out means *I don't believe anything firmware
tells me*, so of course nothing like OP-TEE integration, command line
passing, dynamic configuration, or anything that firmware might want
to tell the kernel is going to work. Anyone who uses dtb= gets to keep
the pieces when they break stuff. That can be written down into policy
in the dtb= documentation if you like. I've just posted a patch to do
that.

g.

Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

[Grant Likely]

On Wed, Sep 5, 2018 at 10:37 AM Ard Biesheuvel
 wrote:
> On 4 September 2018 at 12:13, Grant Likely  wrote:
> > On Tue, Sep 4, 2018 at 7:24 AM Ard Biesheuvel  
> > wrote:
> >>
> >> On 2 September 2018 at 04:54, Olof Johansson  wrote:
> >> > On Thu, Aug 30, 2018 at 9:23 AM, Ard Biesheuvel
> >> >  wrote:
> >> >> On 30 August 2018 at 17:06, Olof Johansson  wrote:
> >> >>> On Wed, Aug 29, 2018 at 10:54 PM, Ard Biesheuvel
> >> >>>  wrote:
> >> >>>> Don't be surprised if some future enhancements of the EFI stub code
> >> >>>> depend on !EFI_ARMSTUB_DTB_LOADER.
> >
> > That's an odd statement to make. The DTB loader code is well contained
> > and with defined semantics... True, the semantics are "I DON'T BELIEVE
> > FIRMWARE", but it is still well defined. What scenario are you
> > envisioning where EFI_ARMSTUB_DTB_LOADER would be explicitly excluded?
> >
>
> Well, to be honest, I don't have a real-world example at hand, but my
> concern is about cases where the firmware provided DTB and the
> override DTB diverge in a way that leaves it up to the EFI stub to
> reconcile them and/or to reason about which one it should prefer.
>
> One example could be OP-TEE support: currently, we put a
> /firmware/optee node in the DT to inform the OS that OP-TEE is running
> in the secure world. If we allow a DT to be provided via dtb= that
> provides such a node, we are blocking all future opportunities in
> future kernels to do any kind of preparatory OP-TEE related
> initialization in the EFI stub [while boot services are still
> available] unless we decide to make it the EFI stub's problem to
> reason about which version of the DT is the correct one to use. What
> if the firmware's DT has /firmware/optee/status = disabled and the
> dtb= one does not?
>
> Another trivial example is GRUB: passing dtb= via the command line
> will break initrds loaded via GRUB, since they are passed via the
> /chosen node.

Using 'dtb=' straight out means *I don't believe anything firmware
tells me*, so of course nothing like OP-TEE integration, command line
passing, dynamic configuration, or anything that firmware might want
to tell the kernel is going to work. Anyone who uses dtb= gets to keep
the pieces when they break stuff. That can be written down into policy
in the dtb= documentation if you like. I've just posted a patch to do
that.

g.

Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

[Grant Likely]

On Wed, Sep 5, 2018 at 6:27 PM Scott Branden  wrote:
>
>
>
> On 18-09-05 02:40 AM, Ard Biesheuvel wrote:
> > On 4 September 2018 at 19:19, Scott Branden  
> > wrote:
> >> Rather than introduce EFI_ARMSTUB_DTB_LOADER, why not have
> >> the efistub use CONFIG_OF to determine whether it supports dtb= or not?
> >>
> >> That way ACPI-only distros disable devicetree support entirely.
> >>
> > Unfortunately, CONFIG_OF cannot be disabled on arm64 even on ACPI-only 
> > builds.
> OF shouldn't be automatically selected in the arm64/Kconfig.  It should
> have a config
> parmaeter like other archs as mips and arm.  I can submit a patch so it
> functions the
> same way as other archs so it is not always selected.  It will be good
> to add a USE_OF
> config options like the other archs (or simply remove the select from
> the Kconfig and choose OF directly in the defconfig.
> This will have the added benefit of doing away with OF support when its
> not needed on an ARM64 platform.  ACPI is already not automatically
> selected for all ARM64 platforms, nor should devicetree.

We don't do that on Arm because a devicetree is always required at
boot time. Even on ACPI systems a tiny DTB is used containing just a
/chosen node for passing the kernel command line and the initrd
location.

g.

g.

Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

[Grant Likely]

On Wed, Sep 5, 2018 at 6:27 PM Scott Branden  wrote:
>
>
>
> On 18-09-05 02:40 AM, Ard Biesheuvel wrote:
> > On 4 September 2018 at 19:19, Scott Branden  
> > wrote:
> >> Rather than introduce EFI_ARMSTUB_DTB_LOADER, why not have
> >> the efistub use CONFIG_OF to determine whether it supports dtb= or not?
> >>
> >> That way ACPI-only distros disable devicetree support entirely.
> >>
> > Unfortunately, CONFIG_OF cannot be disabled on arm64 even on ACPI-only 
> > builds.
> OF shouldn't be automatically selected in the arm64/Kconfig.  It should
> have a config
> parmaeter like other archs as mips and arm.  I can submit a patch so it
> functions the
> same way as other archs so it is not always selected.  It will be good
> to add a USE_OF
> config options like the other archs (or simply remove the select from
> the Kconfig and choose OF directly in the defconfig.
> This will have the added benefit of doing away with OF support when its
> not needed on an ARM64 platform.  ACPI is already not automatically
> selected for all ARM64 platforms, nor should devicetree.

We don't do that on Arm because a devicetree is always required at
boot time. Even on ACPI systems a tiny DTB is used containing just a
/chosen node for passing the kernel command line and the initrd
location.

g.

g.

Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

[Grant Likely]

Hey folks. More comments below, but the short answer is I really don't
see what the problem is. Distros cannot easily support platforms that
require a dtb= parameter, and so they probably won't. They may or may
not disable 'dtb=', depending on whether they see it as valuable for
debug.

Vertically integrated platforms are a different beast. We may strongly
recommend firmware provides the dtb for all the mentioned good
reasons, but they still get to decide their deployment methodology,
and it is not burdensome for the kernel to keep the dtb= feature that
they are using.

On Tue, Sep 4, 2018 at 7:24 AM Ard Biesheuvel  wrote:
>
> On 2 September 2018 at 04:54, Olof Johansson  wrote:
> > On Thu, Aug 30, 2018 at 9:23 AM, Ard Biesheuvel
> >  wrote:
> >> On 30 August 2018 at 17:06, Olof Johansson  wrote:
> >>> On Wed, Aug 29, 2018 at 10:54 PM, Ard Biesheuvel
> >>>  wrote:
>  On 29 August 2018 at 20:59, Scott Branden  
>  wrote:
> > Hi Olof,
> >
> >
> > On 18-08-29 11:44 AM, Olof Johansson wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Aug 29, 2018 at 10:21 AM, Scott Branden
> >>  wrote:
> >>>
> >>> Enable EFI_ARMSTUB_DTB_LOADER to add support for the dtb= command line
> >>> parameter to function with efi loader.
> >>>
> >>> Required to boot on existing bootloaders that do not support 
> >>> devicetree
> >>> provided by the platform or by the bootloader.
> >>>
> >>> Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option for 
> >>> the
> >>> DTB loader")
> >>> Signed-off-by: Scott Branden 
> >>
> >> Why did Ard create an option for this if it's just going be turned on
> >> in default configs? Doesn't make sense to me.
> >>
> >> It would help to know what firmware still is crippled and how common
> >> it is, since it's been a few years that this has been a requirement by
> >> now.
> >
> > Broadcom NS2 and Stingray in current development and production need 
> > this
> > option in the kernel enabled in order to boot.
> 
>  And these production systems run mainline kernels in a defconfig 
>  configuration?
> 
>  The simply reality is that the DTB loader has been deprecated for a
>  good reason: it was only ever intended as a development hack anyway,
>  and if we need to treat the EFI stub provided DTB as a first class
>  citizen, there are things we need to fix to make things works as
>  expected. For instance, GRUB will put a property in the /chosen node
>  for the initramfs which will get dropped if you boot with dtb=.
> 
>  Don't be surprised if some future enhancements of the EFI stub code
>  depend on !EFI_ARMSTUB_DTB_LOADER.

That's an odd statement to make. The DTB loader code is well contained
and with defined semantics... True, the semantics are "I DON'T BELIEVE
FIRMWARE", but it is still well defined. What scenario are you
envisioning where EFI_ARMSTUB_DTB_LOADER would be explicitly excluded?

Conversely, the dtb= argument is an invaluable debug tool during
development. As Olof has already said, there are a lot of embedded
deployments where there is no desire for grub or any other
intermediary loader.

>  On UEFI systems, DTBs [or ACPI
>  tables] are used by the firmware to describe itself and the underlying
>  platform to the OS, and the practice of booting with DTB file images
>  (taken from the kernel build as well) conflicts with that view. Note
>  that GRUB still permits you to load DTBs from files (and supports more
>  sources than just the file system the kernel Image was loaded from).
> >>>
> >>> Ard,
> >>>
> >>> Maybe a WARN() splat would be more useful as a phasing-out method than
> >>> removing functionality for them that needs to be reinstated through
> >>> changing the config?
> >>>
> >>
> >> We don't have any of that in the stub, and inventing new ways to pass
> >> such information between the stub and the kernel proper seems like a
> >> cart-before-horse kind of thing to me. The EFI stub diagnostic
> >> messages you get on the serial console are not recorded in the kernel
> >> log buffer, so they only appear if you actually look at the serial
> >> output.

As an aside, they probably should be recorded. That is probably a
question for the UEFI USWG. Grub and the ARMSTUB could probably bodge
something together, but that would be non-standard.

> >
> > Ah yeah. I suppose you could do it in the kernel later if you detect
> > you've booted through EFI with dtb= on the command line though.
> >
> >>
> >>> Once the stub and the boot method is there, it's hard to undo as we
> >>> can see here. Being loud and warn might be more useful, and set a
> >>> timeline for hard removal (12 months?).
> >>>
> >>
> >> The dtb= handling is still there, it is just not enabled by default.
> >> We can keep it around if people are still using it. But as I pointed
> >> out, we may decide to make new 

Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

[Grant Likely]

Hey folks. More comments below, but the short answer is I really don't
see what the problem is. Distros cannot easily support platforms that
require a dtb= parameter, and so they probably won't. They may or may
not disable 'dtb=', depending on whether they see it as valuable for
debug.

Vertically integrated platforms are a different beast. We may strongly
recommend firmware provides the dtb for all the mentioned good
reasons, but they still get to decide their deployment methodology,
and it is not burdensome for the kernel to keep the dtb= feature that
they are using.

On Tue, Sep 4, 2018 at 7:24 AM Ard Biesheuvel  wrote:
>
> On 2 September 2018 at 04:54, Olof Johansson  wrote:
> > On Thu, Aug 30, 2018 at 9:23 AM, Ard Biesheuvel
> >  wrote:
> >> On 30 August 2018 at 17:06, Olof Johansson  wrote:
> >>> On Wed, Aug 29, 2018 at 10:54 PM, Ard Biesheuvel
> >>>  wrote:
>  On 29 August 2018 at 20:59, Scott Branden  
>  wrote:
> > Hi Olof,
> >
> >
> > On 18-08-29 11:44 AM, Olof Johansson wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Aug 29, 2018 at 10:21 AM, Scott Branden
> >>  wrote:
> >>>
> >>> Enable EFI_ARMSTUB_DTB_LOADER to add support for the dtb= command line
> >>> parameter to function with efi loader.
> >>>
> >>> Required to boot on existing bootloaders that do not support 
> >>> devicetree
> >>> provided by the platform or by the bootloader.
> >>>
> >>> Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option for 
> >>> the
> >>> DTB loader")
> >>> Signed-off-by: Scott Branden 
> >>
> >> Why did Ard create an option for this if it's just going be turned on
> >> in default configs? Doesn't make sense to me.
> >>
> >> It would help to know what firmware still is crippled and how common
> >> it is, since it's been a few years that this has been a requirement by
> >> now.
> >
> > Broadcom NS2 and Stingray in current development and production need 
> > this
> > option in the kernel enabled in order to boot.
> 
>  And these production systems run mainline kernels in a defconfig 
>  configuration?
> 
>  The simply reality is that the DTB loader has been deprecated for a
>  good reason: it was only ever intended as a development hack anyway,
>  and if we need to treat the EFI stub provided DTB as a first class
>  citizen, there are things we need to fix to make things works as
>  expected. For instance, GRUB will put a property in the /chosen node
>  for the initramfs which will get dropped if you boot with dtb=.
> 
>  Don't be surprised if some future enhancements of the EFI stub code
>  depend on !EFI_ARMSTUB_DTB_LOADER.

That's an odd statement to make. The DTB loader code is well contained
and with defined semantics... True, the semantics are "I DON'T BELIEVE
FIRMWARE", but it is still well defined. What scenario are you
envisioning where EFI_ARMSTUB_DTB_LOADER would be explicitly excluded?

Conversely, the dtb= argument is an invaluable debug tool during
development. As Olof has already said, there are a lot of embedded
deployments where there is no desire for grub or any other
intermediary loader.

>  On UEFI systems, DTBs [or ACPI
>  tables] are used by the firmware to describe itself and the underlying
>  platform to the OS, and the practice of booting with DTB file images
>  (taken from the kernel build as well) conflicts with that view. Note
>  that GRUB still permits you to load DTBs from files (and supports more
>  sources than just the file system the kernel Image was loaded from).
> >>>
> >>> Ard,
> >>>
> >>> Maybe a WARN() splat would be more useful as a phasing-out method than
> >>> removing functionality for them that needs to be reinstated through
> >>> changing the config?
> >>>
> >>
> >> We don't have any of that in the stub, and inventing new ways to pass
> >> such information between the stub and the kernel proper seems like a
> >> cart-before-horse kind of thing to me. The EFI stub diagnostic
> >> messages you get on the serial console are not recorded in the kernel
> >> log buffer, so they only appear if you actually look at the serial
> >> output.

As an aside, they probably should be recorded. That is probably a
question for the UEFI USWG. Grub and the ARMSTUB could probably bodge
something together, but that would be non-standard.

> >
> > Ah yeah. I suppose you could do it in the kernel later if you detect
> > you've booted through EFI with dtb= on the command line though.
> >
> >>
> >>> Once the stub and the boot method is there, it's hard to undo as we
> >>> can see here. Being loud and warn might be more useful, and set a
> >>> timeline for hard removal (12 months?).
> >>>
> >>
> >> The dtb= handling is still there, it is just not enabled by default.
> >> We can keep it around if people are still using it. But as I pointed
> >> out, we may decide to make new 

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Grant Likely]

On 23/04/2018 17:49, Geert Uytterhoeven wrote:

Hi Grant,

On Mon, Apr 23, 2018 at 4:47 PM, Grant Likely <grant.lik...@arm.com> wrote:

On 21/04/2018 02:28, Rob Herring wrote:

On Fri, Apr 20, 2018 at 4:00 PM, Frank Rowand <frowand.l...@gmail.com>
wrote:

+  interrupts:
+# Either 1 or 2 interrupts can be present
+minItems: 1
+maxItems: 2
+items:
+  - description: tx or combined interrupt
+  - description: rx interrupt
+
+description: |
+  A variable number of interrupts warrants a description of what
conditions
+  affect the number of interrupts. Otherwise, descriptions on
standard
+  properties are not necessary.
+
+  interrupt-names:
+# minItems must be specified here because the default would be 2
+minItems: 1


Why the difference between the interrupts property and the
interrupt-names
property (specifying maxItems for interrupt, but not interrupt-names)?


I should probably have maxItems here too.


Others have already commented on a desire to have a way to specify that
number of interrupts should match number of interrupt-names.


Yeah, but I don't see a way to do that. You could stick the array size
constraints in a common definition and have a $ref to that definition
from both, but that doesn't really save you too much.



There has been discussions in the jsonschema community regarding
referencing data in the document when applying the schema.

https://github.com/json-schema-org/json-schema-spec/issues/549

However, those discussions are ongoing and have been pushed back to
after draft-8 (the current release is draft-7). We can instead define
DT-specific keywords and extend the validator to make it do what we
want. We need to do something very similar to validate that the length
of tuples in 'reg', 'interrupts', and '*gpios' match the '#*-cells' values.


Checking that property lengths match the corresponding #*-cells cannot
be done for a schema, but only for the final DTS, as #*-cells is a property
of the target node, right?


It can be done in the schema checking of the target node. For example,
given a GPIO specifier of:

gpios = < 0> < 4 1> < 3 0>;

The validation engine could validate that the  and  targets
have the same length as the associated gpio descriptor tuples. (ex.
gpio1 needs #gpio-cells=<1>; and gpio2 needs #gpio-cells=<2>; If the
tuples are the wrong size, then validation should fail.

g.


Gr{oetje,eeting}s,

 Geert



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Grant Likely]

On 23/04/2018 17:49, Geert Uytterhoeven wrote:

Hi Grant,

On Mon, Apr 23, 2018 at 4:47 PM, Grant Likely  wrote:

On 21/04/2018 02:28, Rob Herring wrote:

On Fri, Apr 20, 2018 at 4:00 PM, Frank Rowand 
wrote:

+  interrupts:
+# Either 1 or 2 interrupts can be present
+minItems: 1
+maxItems: 2
+items:
+  - description: tx or combined interrupt
+  - description: rx interrupt
+
+description: |
+  A variable number of interrupts warrants a description of what
conditions
+  affect the number of interrupts. Otherwise, descriptions on
standard
+  properties are not necessary.
+
+  interrupt-names:
+# minItems must be specified here because the default would be 2
+minItems: 1


Why the difference between the interrupts property and the
interrupt-names
property (specifying maxItems for interrupt, but not interrupt-names)?


I should probably have maxItems here too.


Others have already commented on a desire to have a way to specify that
number of interrupts should match number of interrupt-names.


Yeah, but I don't see a way to do that. You could stick the array size
constraints in a common definition and have a $ref to that definition
from both, but that doesn't really save you too much.



There has been discussions in the jsonschema community regarding
referencing data in the document when applying the schema.

https://github.com/json-schema-org/json-schema-spec/issues/549

However, those discussions are ongoing and have been pushed back to
after draft-8 (the current release is draft-7). We can instead define
DT-specific keywords and extend the validator to make it do what we
want. We need to do something very similar to validate that the length
of tuples in 'reg', 'interrupts', and '*gpios' match the '#*-cells' values.


Checking that property lengths match the corresponding #*-cells cannot
be done for a schema, but only for the final DTS, as #*-cells is a property
of the target node, right?


It can be done in the schema checking of the target node. For example,
given a GPIO specifier of:

gpios = < 0> < 4 1> < 3 0>;

The validation engine could validate that the  and  targets
have the same length as the associated gpio descriptor tuples. (ex.
gpio1 needs #gpio-cells=<1>; and gpio2 needs #gpio-cells=<2>; If the
tuples are the wrong size, then validation should fail.

g.


Gr{oetje,eeting}s,

 Geert



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Grant Likely]

On 23/04/2018 15:38, Rob Herring wrote:

On Mon, Apr 23, 2018 at 9:01 AM, Grant Likely <grant.lik...@arm.com> wrote:

On 21/04/2018 00:41, Stephen Boyd wrote:


Quoting Rob Herring (2018-04-20 11:15:04)


On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd <sb...@kernel.org> wrote:


Quoting Rob Herring (2018-04-18 15:29:05)


diff --git a/Documentation/devicetree/bindings/example-schema.yaml
b/Documentation/devicetree/bindings/example-schema.yaml
new file mode 100644
index ..fe0a3bd1668e
--- /dev/null
+++ b/Documentation/devicetree/bindings/example-schema.yaml


[...]


+  interrupts:
+# Either 1 or 2 interrupts can be present
+minItems: 1
+maxItems: 2
+items:
+  - description: tx or combined interrupt
+  - description: rx interrupt
+
+description: |



The '|' is needed to make yaml happy?



Yes, this is simply how you do literal text blocks in yaml.

We don't really need for this one really, but for the top-level
'description' we do. The long term intent is 'description' would be
written in sphinx/rst and can be extracted into the DT spec (for
common bindings). Grant has experimented with that some.



Ok. That sounds cool. Then we could embed links to datasheets and SVGs
too.



I'd like it if we can define the description text blocks to be
reStructeredText markup. That makes it even easier to integrate with the
specification documentation.


I think that's going to require thinking about how each binding is
integrated into the spec. We're only talking about common bindings I
presume, but still we have no model defined. For example, with
properties, I'd assume we'd want to generate a table of properties and
we wouldn't want the property descriptions in rST because the
description becomes just a cell in the table. So we need some sort of
template.

Also, how do we validate that description contains valid rST? No point
requiring it until we can validate it.


Indeed. Part of that was me thinking outloud. Need to actually get it
working before adding constraints.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Grant Likely]

On 23/04/2018 15:38, Rob Herring wrote:

On Mon, Apr 23, 2018 at 9:01 AM, Grant Likely  wrote:

On 21/04/2018 00:41, Stephen Boyd wrote:


Quoting Rob Herring (2018-04-20 11:15:04)


On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd  wrote:


Quoting Rob Herring (2018-04-18 15:29:05)


diff --git a/Documentation/devicetree/bindings/example-schema.yaml
b/Documentation/devicetree/bindings/example-schema.yaml
new file mode 100644
index ..fe0a3bd1668e
--- /dev/null
+++ b/Documentation/devicetree/bindings/example-schema.yaml


[...]


+  interrupts:
+# Either 1 or 2 interrupts can be present
+minItems: 1
+maxItems: 2
+items:
+  - description: tx or combined interrupt
+  - description: rx interrupt
+
+description: |



The '|' is needed to make yaml happy?



Yes, this is simply how you do literal text blocks in yaml.

We don't really need for this one really, but for the top-level
'description' we do. The long term intent is 'description' would be
written in sphinx/rst and can be extracted into the DT spec (for
common bindings). Grant has experimented with that some.



Ok. That sounds cool. Then we could embed links to datasheets and SVGs
too.



I'd like it if we can define the description text blocks to be
reStructeredText markup. That makes it even easier to integrate with the
specification documentation.


I think that's going to require thinking about how each binding is
integrated into the spec. We're only talking about common bindings I
presume, but still we have no model defined. For example, with
properties, I'd assume we'd want to generate a table of properties and
we wouldn't want the property descriptions in rST because the
description becomes just a cell in the table. So we need some sort of
template.

Also, how do we validate that description contains valid rST? No point
requiring it until we can validate it.


Indeed. Part of that was me thinking outloud. Need to actually get it
working before adding constraints.

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Grant Likely]

On 21/04/2018 02:28, Rob Herring wrote:

On Fri, Apr 20, 2018 at 4:00 PM, Frank Rowand  wrote:

Hi Rob,

Thanks for the example.  It was a good starting tutorial of sorts for me
to understand the format a bit.


On 04/18/18 15:29, Rob Herring wrote:

The current DT binding documentation format of freeform text is painful
to write, review, validate and maintain.

This is just an example of what a binding in the schema format looks
like. It's using jsonschema vocabulary in a YAML encoded document. Using
jsonschema gives us access to existing tooling. A YAML encoding gives us
something easy to edit.

This example is just the tip of the iceberg, but it the part most
developers writing bindings will interact with. Backing all this up
are meta-schema (to validate the binding schemas), some DT core schema,
YAML encoded DT output with dtc, and a small number of python scripts to
run validation. The gory details including how to run end-to-end
validation can be found here:

https://www.spinics.net/lists/devicetree-spec/msg00649.html

Signed-off-by: Rob Herring 
---
Cc list,
You all review and/or write lots of binding documents. I'd like some feedback
on the format.

Thanks,
Rob

  .../devicetree/bindings/example-schema.yaml| 149 +
  1 file changed, 149 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/example-schema.yaml

diff --git a/Documentation/devicetree/bindings/example-schema.yaml 
b/Documentation/devicetree/bindings/example-schema.yaml
new file mode 100644
index ..fe0a3bd1668e
--- /dev/null
+++ b/Documentation/devicetree/bindings/example-schema.yaml


I'm guessing by the path name that this is in the Linux kernel source tree.


Yes, well, my kernel tree. Most of the work still lives here:

https://github.com/robherring/yaml-bindings/


@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: BSD-2-Clause


If in the Linux kernel source tree, then allow gpl-v2 as a possible license.


Why? BSD is compatible. The license of the above repo is all BSD.

Of course there's all the existing docs which default to GPLv2 and
we'll probably have to maintain that.


+# Copyright 2018 Linaro Ltd.
+%YAML 1.2
+---
+# All the top-level keys are standard json-schema keywords except for
+# 'maintainers' and 'select'
+
+# $id is a unique idenifier based on the filename


  ^  identifier


+$id: "http://devicetree.org/schemas/example-schema.yaml#;


Does this imply that all schemas will be at devicetree.org instead
of in the Linux kernel source tree?  This would be counter to my
earlier guess about where this patch is applied.


They could be, but not necessarily. This is just convention in
jsonschema is the best I understand it.

I don't think you'd want validation to require an internet connection.
For the base meta-schema, for example, it does exist at
http://json-schema.org/draft-06/schema, but that's also distributed
with implementations of jsonschema validators.

A large part (not that any part is large) of the tools Grant and I
have written is doing the cross reference resolution of files which
uses the $id field.



+$schema: "http://devicetree.org/meta-schemas/core.yaml#;


How is $schema used?


Tells the validator what meta-schema this schema follows. Typically
you see draft04 or draft06 here if you haven't written a meta-schema.


On this topic, we should probably do the same thing for the dt
metaschemas. I didn't worry about it initially because there was a lot
of working out what it should look like, but we should include a
revision number in the DT metaschema $id URLs.


Is it accessed across the network?


Could be, but generally no.


The $schema and $id values are used as unique identifiers. The parser is
setup to look locally for both devicetree.org and json-schema.org URLs,
so network access is not used. The parser /can/ fetch a URL over the
network, but that isn't a feature we want to use.

Using the http://devicetree.org/ prefix makes sense for the metaschema,
and for all the schema files because I think the desire is to have a
common database for all users. For practical reasons it makes sense to
start with putting them in the Linux kernel tree, but only because
that's where all the binding documents currently are. However, we also
have the DT rebasing tree that is tracking mainline and has a good
structure. We can start encouraging non-Linux users to base off the
-rebasing tree, and work on transition plans to allow patches against
-rebasing, and to eventually make it the master tree instead of the kernel.

It is also possible to have other prefixes for schemas that don't belong
in the common repo (but I cannot think of many good reasons for doing that).




(This example file provides a good example of a single syntax style, but does
not preclude other equivalent syntax.)


There's also a question of formatting. For example, we can have:

enum: [1,2,3]

or

enum:
   - 1
   - 2
   - 3

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Grant Likely]

On 21/04/2018 02:28, Rob Herring wrote:

On Fri, Apr 20, 2018 at 4:00 PM, Frank Rowand  wrote:

Hi Rob,

Thanks for the example.  It was a good starting tutorial of sorts for me
to understand the format a bit.


On 04/18/18 15:29, Rob Herring wrote:

The current DT binding documentation format of freeform text is painful
to write, review, validate and maintain.

This is just an example of what a binding in the schema format looks
like. It's using jsonschema vocabulary in a YAML encoded document. Using
jsonschema gives us access to existing tooling. A YAML encoding gives us
something easy to edit.

This example is just the tip of the iceberg, but it the part most
developers writing bindings will interact with. Backing all this up
are meta-schema (to validate the binding schemas), some DT core schema,
YAML encoded DT output with dtc, and a small number of python scripts to
run validation. The gory details including how to run end-to-end
validation can be found here:

https://www.spinics.net/lists/devicetree-spec/msg00649.html

Signed-off-by: Rob Herring 
---
Cc list,
You all review and/or write lots of binding documents. I'd like some feedback
on the format.

Thanks,
Rob

  .../devicetree/bindings/example-schema.yaml| 149 +
  1 file changed, 149 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/example-schema.yaml

diff --git a/Documentation/devicetree/bindings/example-schema.yaml 
b/Documentation/devicetree/bindings/example-schema.yaml
new file mode 100644
index ..fe0a3bd1668e
--- /dev/null
+++ b/Documentation/devicetree/bindings/example-schema.yaml


I'm guessing by the path name that this is in the Linux kernel source tree.


Yes, well, my kernel tree. Most of the work still lives here:

https://github.com/robherring/yaml-bindings/


@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: BSD-2-Clause


If in the Linux kernel source tree, then allow gpl-v2 as a possible license.


Why? BSD is compatible. The license of the above repo is all BSD.

Of course there's all the existing docs which default to GPLv2 and
we'll probably have to maintain that.


+# Copyright 2018 Linaro Ltd.
+%YAML 1.2
+---
+# All the top-level keys are standard json-schema keywords except for
+# 'maintainers' and 'select'
+
+# $id is a unique idenifier based on the filename


  ^  identifier


+$id: "http://devicetree.org/schemas/example-schema.yaml#;


Does this imply that all schemas will be at devicetree.org instead
of in the Linux kernel source tree?  This would be counter to my
earlier guess about where this patch is applied.


They could be, but not necessarily. This is just convention in
jsonschema is the best I understand it.

I don't think you'd want validation to require an internet connection.
For the base meta-schema, for example, it does exist at
http://json-schema.org/draft-06/schema, but that's also distributed
with implementations of jsonschema validators.

A large part (not that any part is large) of the tools Grant and I
have written is doing the cross reference resolution of files which
uses the $id field.



+$schema: "http://devicetree.org/meta-schemas/core.yaml#;


How is $schema used?


Tells the validator what meta-schema this schema follows. Typically
you see draft04 or draft06 here if you haven't written a meta-schema.


On this topic, we should probably do the same thing for the dt
metaschemas. I didn't worry about it initially because there was a lot
of working out what it should look like, but we should include a
revision number in the DT metaschema $id URLs.


Is it accessed across the network?


Could be, but generally no.


The $schema and $id values are used as unique identifiers. The parser is
setup to look locally for both devicetree.org and json-schema.org URLs,
so network access is not used. The parser /can/ fetch a URL over the
network, but that isn't a feature we want to use.

Using the http://devicetree.org/ prefix makes sense for the metaschema,
and for all the schema files because I think the desire is to have a
common database for all users. For practical reasons it makes sense to
start with putting them in the Linux kernel tree, but only because
that's where all the binding documents currently are. However, we also
have the DT rebasing tree that is tracking mainline and has a good
structure. We can start encouraging non-Linux users to base off the
-rebasing tree, and work on transition plans to allow patches against
-rebasing, and to eventually make it the master tree instead of the kernel.

It is also possible to have other prefixes for schemas that don't belong
in the common repo (but I cannot think of many good reasons for doing that).




(This example file provides a good example of a single syntax style, but does
not preclude other equivalent syntax.)


There's also a question of formatting. For example, we can have:

enum: [1,2,3]

or

enum:
   - 1
   - 2
   - 3

IMO, we should lock that down too.


I 

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Grant Likely]

On 21/04/2018 00:41, Stephen Boyd wrote:

Quoting Rob Herring (2018-04-20 11:15:04)

On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd  wrote:

Quoting Rob Herring (2018-04-18 15:29:05)

diff --git a/Documentation/devicetree/bindings/example-schema.yaml 
b/Documentation/devicetree/bindings/example-schema.yaml
new file mode 100644
index ..fe0a3bd1668e
--- /dev/null
+++ b/Documentation/devicetree/bindings/example-schema.yaml

[...]

+  interrupts:
+# Either 1 or 2 interrupts can be present
+minItems: 1
+maxItems: 2
+items:
+  - description: tx or combined interrupt
+  - description: rx interrupt
+
+description: |


The '|' is needed to make yaml happy?


Yes, this is simply how you do literal text blocks in yaml.

We don't really need for this one really, but for the top-level
'description' we do. The long term intent is 'description' would be
written in sphinx/rst and can be extracted into the DT spec (for
common bindings). Grant has experimented with that some.


Ok. That sounds cool. Then we could embed links to datasheets and SVGs
too.


I'd like it if we can define the description text blocks to be
reStructeredText markup. That makes it even easier to integrate with the
specification documentation.

[...]

+  # Property names starting with '#' must be quoted
+  '#interrupt-cells':
+# A simple case where the value must always be '2'.
+# The core schema handles that this must be a single integer.
+const: 2
+
+  interrupt-controller: {}


Does '{}' mean nothing to see here?


Yes. It's just an empty schema that's always valid.


IIRC, in the current jsonschema draft-6 spec, the following also has the
same behaviour, which I like slightly better:
interrupt-controller: true

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Grant Likely]

On 21/04/2018 00:41, Stephen Boyd wrote:

Quoting Rob Herring (2018-04-20 11:15:04)

On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd  wrote:

Quoting Rob Herring (2018-04-18 15:29:05)

diff --git a/Documentation/devicetree/bindings/example-schema.yaml 
b/Documentation/devicetree/bindings/example-schema.yaml
new file mode 100644
index ..fe0a3bd1668e
--- /dev/null
+++ b/Documentation/devicetree/bindings/example-schema.yaml

[...]

+  interrupts:
+# Either 1 or 2 interrupts can be present
+minItems: 1
+maxItems: 2
+items:
+  - description: tx or combined interrupt
+  - description: rx interrupt
+
+description: |


The '|' is needed to make yaml happy?


Yes, this is simply how you do literal text blocks in yaml.

We don't really need for this one really, but for the top-level
'description' we do. The long term intent is 'description' would be
written in sphinx/rst and can be extracted into the DT spec (for
common bindings). Grant has experimented with that some.


Ok. That sounds cool. Then we could embed links to datasheets and SVGs
too.


I'd like it if we can define the description text blocks to be
reStructeredText markup. That makes it even easier to integrate with the
specification documentation.

[...]

+  # Property names starting with '#' must be quoted
+  '#interrupt-cells':
+# A simple case where the value must always be '2'.
+# The core schema handles that this must be a single integer.
+const: 2
+
+  interrupt-controller: {}


Does '{}' mean nothing to see here?


Yes. It's just an empty schema that's always valid.


IIRC, in the current jsonschema draft-6 spec, the following also has the
same behaviour, which I like slightly better:
interrupt-controller: true

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property

[Grant Likely]

On Thu, Jan 11, 2018 at 4:36 PM, Timur Tabi <ti...@codeaurora.org> wrote:
> On 01/11/2018 10:33 AM, Grant Likely wrote:
>>
>> What level of access control is implemented here? Is there access
>> control for each GPIO individually, or is it done by banks of GPIOs?
>> Just asking to make sure I understand the problem domain.
>
>
> On our ACPI system, it's specific GPIOs.  Each GPIO is in its own 64k page,
> which is what allows us to block specific ones.

Okay, thanks.

g.

>
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property

[Grant Likely]

On Thu, Jan 11, 2018 at 4:36 PM, Timur Tabi  wrote:
> On 01/11/2018 10:33 AM, Grant Likely wrote:
>>
>> What level of access control is implemented here? Is there access
>> control for each GPIO individually, or is it done by banks of GPIOs?
>> Just asking to make sure I understand the problem domain.
>
>
> On our ACPI system, it's specific GPIOs.  Each GPIO is in its own 64k page,
> which is what allows us to block specific ones.

Okay, thanks.

g.

>
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property

[Grant Likely]

On Wed, Jan 10, 2018 at 1:37 PM, Linus Walleij  wrote:
> On Wed, Jan 10, 2018 at 2:58 AM, Stephen Boyd  wrote:
>
>> Some qcom platforms make some GPIOs or pins unavailable for use
>> by non-secure operating systems, and thus reading or writing the
>> registers for those pins will cause access control issues.
>> Introduce a DT property to describe the set of GPIOs that are
>> available for use so that higher level OSes are able to know what
>> pins to avoid reading/writing.

What level of access control is implemented here? Is there access
control for each GPIO individually, or is it done by banks of GPIOs?
Just asking to make sure I understand the problem domain.

>>
>> Cc: 
>> Signed-off-by: Stephen Boyd 
>
> I like the idea, let's check what we think about the details regarding
> naming and semantics, I need feedback from some DT people
> in particular.
>
> Paging in Grant on this as he might have some input.
>
>> I stuck this inside msm8996, but maybe it can go somewhere more generic?
>
> Yeah just put it in Documentation/devicetree/bindings/gpio/gpio.txt
> Everyone and its dog doing GPIO reservations "from another world"
> will need to use this.
>
>> +- ngpios-ranges:
>> +   Usage: optional
>> +   Value type: 
>> +   Definition: Tuples of GPIO ranges (base, size) indicating
>> +   GPIOs available for use.
>> +
>>  Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt 
>> for
>>  a general description of GPIO and interrupt bindings.
>
> I like the tuples syntax. That's fine. It's like gpio-ranges we have
> already to map between pin controllers and GPIO.
>
> I don't think we can reuse gpio-ranges because that is
> exclusively for pin control ATM, it would be fine if the ranges
> were for a specific device, like pin control does, like:
>
> gpio-ranges = <_world_thing 0 20 10>;
>
> But you definately would need a node to tie it to, so that the
> driver for that node can specify that it's gonna take the
> GPIOs.
>
> But I think the semantics should be the inverse. That you
> point out "holes" with the lines we *can't* use.
>
> We already support a generic property "ngpios" that says how
> many of the GPIOs (counted from zero) that can be used,
> so if those should be able to use this as a generic property it
> is better with the inverse semantics and say that the
> "reserved-gpio-ranges", "secureworld-gpio-ranges"
> (or whatever we decide to call it) takes precedence over
> ngpios so we don't end up in ambigous places.

Heh, I just went down the same thought process on the naming before I
read the above. Yes I agree. The property name should have something
like "reserved" in it. I vote for "gpio-reserved-ranges" because it
puts the binding owner (gpio) at the front of the name, it indicates
that the list is unavailable GPIOs, and that the format is a set of
ranges.

The fiddly bit is it assumes the GPIOs are described by a single
number. It works fine as long as the GPIO controllers can use a single
cell to describe a gpio number (instead of having #gpio-cells = 3 with
the first cell being bank, the second being number in bank, and the
third being flags).

>
> Then, will it be possible to put the parsing, handling and
> disablement of these ranges into drivers/gpio/gpiolib-of.c
> where we handle the ranges today, or do we need to
> do it in the individual drivers?

I certainly would prefer parsing this in common code, and not in
individual drivers, but again it becomes hard for any driver using
multiple cells to describe the local GPIO number. I think the guidance
here needs to be that the property is relevant when the internal GPIO
number representation fits within a uint32, which realistically should
never be a problem.

g.

Re: [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property

[Grant Likely]

On Wed, Jan 10, 2018 at 1:37 PM, Linus Walleij  wrote:
> On Wed, Jan 10, 2018 at 2:58 AM, Stephen Boyd  wrote:
>
>> Some qcom platforms make some GPIOs or pins unavailable for use
>> by non-secure operating systems, and thus reading or writing the
>> registers for those pins will cause access control issues.
>> Introduce a DT property to describe the set of GPIOs that are
>> available for use so that higher level OSes are able to know what
>> pins to avoid reading/writing.

What level of access control is implemented here? Is there access
control for each GPIO individually, or is it done by banks of GPIOs?
Just asking to make sure I understand the problem domain.

>>
>> Cc: 
>> Signed-off-by: Stephen Boyd 
>
> I like the idea, let's check what we think about the details regarding
> naming and semantics, I need feedback from some DT people
> in particular.
>
> Paging in Grant on this as he might have some input.
>
>> I stuck this inside msm8996, but maybe it can go somewhere more generic?
>
> Yeah just put it in Documentation/devicetree/bindings/gpio/gpio.txt
> Everyone and its dog doing GPIO reservations "from another world"
> will need to use this.
>
>> +- ngpios-ranges:
>> +   Usage: optional
>> +   Value type: 
>> +   Definition: Tuples of GPIO ranges (base, size) indicating
>> +   GPIOs available for use.
>> +
>>  Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt 
>> for
>>  a general description of GPIO and interrupt bindings.
>
> I like the tuples syntax. That's fine. It's like gpio-ranges we have
> already to map between pin controllers and GPIO.
>
> I don't think we can reuse gpio-ranges because that is
> exclusively for pin control ATM, it would be fine if the ranges
> were for a specific device, like pin control does, like:
>
> gpio-ranges = <_world_thing 0 20 10>;
>
> But you definately would need a node to tie it to, so that the
> driver for that node can specify that it's gonna take the
> GPIOs.
>
> But I think the semantics should be the inverse. That you
> point out "holes" with the lines we *can't* use.
>
> We already support a generic property "ngpios" that says how
> many of the GPIOs (counted from zero) that can be used,
> so if those should be able to use this as a generic property it
> is better with the inverse semantics and say that the
> "reserved-gpio-ranges", "secureworld-gpio-ranges"
> (or whatever we decide to call it) takes precedence over
> ngpios so we don't end up in ambigous places.

Heh, I just went down the same thought process on the naming before I
read the above. Yes I agree. The property name should have something
like "reserved" in it. I vote for "gpio-reserved-ranges" because it
puts the binding owner (gpio) at the front of the name, it indicates
that the list is unavailable GPIOs, and that the format is a set of
ranges.

The fiddly bit is it assumes the GPIOs are described by a single
number. It works fine as long as the GPIO controllers can use a single
cell to describe a gpio number (instead of having #gpio-cells = 3 with
the first cell being bank, the second being number in bank, and the
third being flags).

>
> Then, will it be possible to put the parsing, handling and
> disablement of these ranges into drivers/gpio/gpiolib-of.c
> where we handle the ranges today, or do we need to
> do it in the individual drivers?

I certainly would prefer parsing this in common code, and not in
individual drivers, but again it becomes hard for any driver using
multiple cells to describe the local GPIO number. I think the guidance
here needs to be that the property is relevant when the internal GPIO
number representation fits within a uint32, which realistically should
never be a problem.

g.

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Grant Likely]

On Sun, Oct 22, 2017 at 7:23 PM, Pantelis Antoniou
<pantelis.anton...@konsulko.com> wrote:
> Hi Grant,
>
>> On Oct 22, 2017, at 19:54 , Grant Likely <grant.lik...@secretlab.ca> wrote:
>>
>> On Fri, Oct 20, 2017 at 8:16 PM, Pantelis Antoniou
>> <pantelis.anton...@konsulko.com> wrote:
>>> Hi Grant,
>>>
>>>> On Oct 20, 2017, at 20:46 , Grant Likely <grant.lik...@secretlab.ca> wrote:
>>>>
>>>> On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou
>>>> <pantelis.anton...@konsulko.com> wrote:
[...]
>>> Yes. This is expected. I don’t think pure YAML form is a good match for all
>>> the crazy things that are possible (and actually used in practice) with DTS.
>>
>> I don’t think it is as dire as that. The DTS structure is not complex
>> and I think can easily be mapped into pure YAML. But, it does require
>> treating the DTS structure separately from its semantic meaning. For
>> example, the grammar of nodes, properties and labels easily maps to
>> pure YAML, but phandles and overlay trees have semantic meaning that
>> must be resolved by DT specific code. I’ll respond to you’re specific
>> examples below…
>>
>
> We are in complete agreement here. Single nodes and properties map to YAML 
> perfectly.
> It’s the complex way that we build the complete DTB that stress the YAML 
> structures.

Okay, good.

>>> If we were to force YAML/DT file to be regular YAML files parseable by 
>>> everything
>>> we’d have to rethink a lot of conventions that DT files currently use and 
>>> I’m afraid
>>> a machine translation from DTS to YAML might not be feasible then.
>>>
>>> OTOH moving to that model might make it possible to use YAML constructs 
>>> that are not
>>> mapped at all to DTS. For instance
>>>
>>> - foo: true
>>>  bar: “string”
>>>
>>> - foo: false
>>>  bar: “another-string”
>>>
>>> is not possible to be mapped to a DT node/property structure right now.
>>
>> I’m not following. Are you saying DT has no way to encode a list of
>> nodes? What use case are you imagining?
>>
>
> This threw me off too at first.
>
> The problem is when you try to convert this into a live tree structure.
>
> The YAML encoding is
>
> +SEQ
>  +MAP
>   =VAL :foo
>   =VAL :true
>   =VAL :bar
>   =VAL "string
>  -MAP
>  +MAP
>   =VAL :foo
>   =VAL :false
>   =VAL :bar
>   =VAL "another-string
>  -MAP
> -SEQ
>
> So it’s a sequence of MAPs.
>
> In a live tree DTS form would be
>
> noname-property = { foo=true; bar = “string”; }, { foo = false; 
> bar=“another-string”; };
>
> We don’t have the capability as right now to express something like this.
>
> Namely properties containing nodes, and the root of the live tree not being a 
> node.

Ah, so you're proposing property data that encodes key/value pairs,
correct? Effectively adding another layer of namespace under a
property, but that namespace is invisible to and generic DT parsing
code in an OS (for how DT is defined today).

I would straight out make that structure illegal in the YAML DT
metaschema until such time as the semantics are defined. For now
properties should only be allowed to contain scalars, or lists of
scalars/lists which can be nested.

[...]

>>>> The encoding differentiates between nodes and properties implicitly
>>>> base on whether the contents are a map, or a scalar/list. This does
>>>> mean any parser needs to do a bit more work and it may impact what can
>>>> be done with validation (I'm not going to talk about validation in
>>>> this email though. We'll talk next week.)
>>>
>>> Hmm, I’m not sure I follow this. Is that related to the metadata problem.
>>
>> It has to do with iterating over properties or nodes. Nodes and props
>> are mixed together, and any code processing them has to explicitly
>> check the type to differentiate between the two. The alternative would
>> be to collect all properties under a single key:
>>
>> parent:
>>  $props:
>>foo: hello
>>bar: world
>>  child1: {}
>>  child2: {}
>>
>
> That’s no problem. It does look weird though. I am using the same parser
> for parsing bindings and this might make the files a little bit weird.

That it does. I don’t feel strongly about either approach, but I want
to see how the different encodings affect doing the schema bits.

>
> Keep in mind that we have two YAML formats to parse; the hardware description
> and the bindings describing them.

Three! Hw description, schema & metaschema. :-) But metaschema should
be a normal jsonschema file.

>
>>>
>>> BTW, a blog post explaining the rationale behind yamldt is going to come
>>> up soon at our website, I’ll post the link when it does.
>>
>> Cool. I see it got posted, but didn’t get a chance to read it before I
>> got on this airplane. Will try to read this evening.
>>
>> (BTW, I’m arriving at about 11:00 tonight)
>>
>
> Have a safe flight, you’ll get to beat me up tomorrow :)

See you tomorrow. It will be good to catch up.

g.

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Grant Likely]

On Sun, Oct 22, 2017 at 7:23 PM, Pantelis Antoniou
 wrote:
> Hi Grant,
>
>> On Oct 22, 2017, at 19:54 , Grant Likely  wrote:
>>
>> On Fri, Oct 20, 2017 at 8:16 PM, Pantelis Antoniou
>>  wrote:
>>> Hi Grant,
>>>
>>>> On Oct 20, 2017, at 20:46 , Grant Likely  wrote:
>>>>
>>>> On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou
>>>>  wrote:
[...]
>>> Yes. This is expected. I don’t think pure YAML form is a good match for all
>>> the crazy things that are possible (and actually used in practice) with DTS.
>>
>> I don’t think it is as dire as that. The DTS structure is not complex
>> and I think can easily be mapped into pure YAML. But, it does require
>> treating the DTS structure separately from its semantic meaning. For
>> example, the grammar of nodes, properties and labels easily maps to
>> pure YAML, but phandles and overlay trees have semantic meaning that
>> must be resolved by DT specific code. I’ll respond to you’re specific
>> examples below…
>>
>
> We are in complete agreement here. Single nodes and properties map to YAML 
> perfectly.
> It’s the complex way that we build the complete DTB that stress the YAML 
> structures.

Okay, good.

>>> If we were to force YAML/DT file to be regular YAML files parseable by 
>>> everything
>>> we’d have to rethink a lot of conventions that DT files currently use and 
>>> I’m afraid
>>> a machine translation from DTS to YAML might not be feasible then.
>>>
>>> OTOH moving to that model might make it possible to use YAML constructs 
>>> that are not
>>> mapped at all to DTS. For instance
>>>
>>> - foo: true
>>>  bar: “string”
>>>
>>> - foo: false
>>>  bar: “another-string”
>>>
>>> is not possible to be mapped to a DT node/property structure right now.
>>
>> I’m not following. Are you saying DT has no way to encode a list of
>> nodes? What use case are you imagining?
>>
>
> This threw me off too at first.
>
> The problem is when you try to convert this into a live tree structure.
>
> The YAML encoding is
>
> +SEQ
>  +MAP
>   =VAL :foo
>   =VAL :true
>   =VAL :bar
>   =VAL "string
>  -MAP
>  +MAP
>   =VAL :foo
>   =VAL :false
>   =VAL :bar
>   =VAL "another-string
>  -MAP
> -SEQ
>
> So it’s a sequence of MAPs.
>
> In a live tree DTS form would be
>
> noname-property = { foo=true; bar = “string”; }, { foo = false; 
> bar=“another-string”; };
>
> We don’t have the capability as right now to express something like this.
>
> Namely properties containing nodes, and the root of the live tree not being a 
> node.

Ah, so you're proposing property data that encodes key/value pairs,
correct? Effectively adding another layer of namespace under a
property, but that namespace is invisible to and generic DT parsing
code in an OS (for how DT is defined today).

I would straight out make that structure illegal in the YAML DT
metaschema until such time as the semantics are defined. For now
properties should only be allowed to contain scalars, or lists of
scalars/lists which can be nested.

[...]

>>>> The encoding differentiates between nodes and properties implicitly
>>>> base on whether the contents are a map, or a scalar/list. This does
>>>> mean any parser needs to do a bit more work and it may impact what can
>>>> be done with validation (I'm not going to talk about validation in
>>>> this email though. We'll talk next week.)
>>>
>>> Hmm, I’m not sure I follow this. Is that related to the metadata problem.
>>
>> It has to do with iterating over properties or nodes. Nodes and props
>> are mixed together, and any code processing them has to explicitly
>> check the type to differentiate between the two. The alternative would
>> be to collect all properties under a single key:
>>
>> parent:
>>  $props:
>>foo: hello
>>bar: world
>>  child1: {}
>>  child2: {}
>>
>
> That’s no problem. It does look weird though. I am using the same parser
> for parsing bindings and this might make the files a little bit weird.

That it does. I don’t feel strongly about either approach, but I want
to see how the different encodings affect doing the schema bits.

>
> Keep in mind that we have two YAML formats to parse; the hardware description
> and the bindings describing them.

Three! Hw description, schema & metaschema. :-) But metaschema should
be a normal jsonschema file.

>
>>>
>>> BTW, a blog post explaining the rationale behind yamldt is going to come
>>> up soon at our website, I’ll post the link when it does.
>>
>> Cool. I see it got posted, but didn’t get a chance to read it before I
>> got on this airplane. Will try to read this evening.
>>
>> (BTW, I’m arriving at about 11:00 tonight)
>>
>
> Have a safe flight, you’ll get to beat me up tomorrow :)

See you tomorrow. It will be good to catch up.

g.

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Grant Likely]

On Fri, Oct 20, 2017 at 8:16 PM, Pantelis Antoniou
<pantelis.anton...@konsulko.com> wrote:
> Hi Grant,
>
>> On Oct 20, 2017, at 20:46 , Grant Likely <grant.lik...@secretlab.ca> wrote:
>>
>> On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou
>> <pantelis.anton...@konsulko.com> wrote:
>>> Hello again,
>>>
>>> Significant progress has been made on yamldt and is now capable of
>>> not only generating yaml from DTS source but also compiling DTS sources
>>> and being almost fully compatible with DTC.
>>>
>>> Compiling the kernel's DTBs using yamldt is as simple as using a
>>> DTC=yamldt.
>>>
>>> Error reporting is accurate and validation against a YAML based schema
>>> works as well. In a short while I will begin posting patches with
>>> fixes on bindings and DTS files in the kernel.
>>>
>>> Please try it on your platform and report if you encounter any problems.
>>>
>>> https://github.com/pantoniou/yamldt
>>>
>>> I am eagerly awaiting for your comments.
>>
>> Hi Pantelis,
>>
>> This is good work. I've played around with it and I'm looking forward
>> to chatting next week.
>>
>
> Thanks. I’m looking forward to it too.
>
>> One thing I've done is tried loading the output YAML files into
>> another YAML interpreter and the current encoding causes problems.
>> Specifically, in yamldt anchors/aliases are being used as a
>> replacement for labels/phandles, but that conflicts with the YAML data
>> model which defines a reference as a way to make a copy of the data
>> appear in another part of the tree. For example, for the following
>> snippit:
>>
>> intc: intc@1 {
>>#interrupt-cells = <1>;
>>compatible = "acme,intc";
>>reg = <0x1 0x1000>;
>>gpio-controller;
>> };
>>
>> serial@2 {
>>compatible = "acme,uart";
>>reg = <0x2 0x1000>;
>>interrupt-parent = <>;
>>interrupts = <5>;
>> };
>>
>> yamldt will encode this as:
>>
>> intc@1: 
>>"#interrupt-cells": 1
>>compatible: acme,intc
>>reg: [0x1, 0x1000]
>>gpio-controller:
>>
>> serial@2:
>>compatible: acme,uart
>>reg: [0x2, 0x1000]
>>interrupt-parent: *intc
>>interrupts: 5
>>
>> But, the expected behaviour for a YAML parser is expand the alias
>> '*intc' which results in the following structure:
>>
>> intc@1: 
>>"#interrupt-cells": 1
>>compatible: acme,intc
>>reg: [0x1, 0x1000]
>>gpio-controller:
>>
>> serial@2:
>>compatible: acme,uart
>>reg: [0x2, 0x1000]
>>interrupt-parent:
>>"#interrupt-cells": 1
>>compatible: acme,intc
>>reg: [0x1, 0x1000]
>>gpio-controller:
>>interrupts: 5
>>
>> See? It results in the entire interrupt controller node to appear as
>> an instance under the interrupt-parent property, when the intention is
>> only to create a phandle. yamldt should not redefine the behaviour of
>> '*' aliases. Instead, it should use a different indicator, either
>> using an explicit !phandle tag, or by replacing '*' with something
>> else. I worked around it in my tests by replacing '*' with '$’.
>
> Yes. This is expected. I don’t think pure YAML form is a good match for all
> the crazy things that are possible (and actually used in practice) with DTS.

I don’t think it is as dire as that. The DTS structure is not complex
and I think can easily be mapped into pure YAML. But, it does require
treating the DTS structure separately from its semantic meaning. For
example, the grammar of nodes, properties and labels easily maps to
pure YAML, but phandles and overlay trees have semantic meaning that
must be resolved by DT specific code. I’ll respond to you’re specific
examples below...

>
> For instance there’s no way a normal YAML parser won’t choke with something 
> like
>
> / {
>   foo;
> };
>
> / {
>   bar;
> };
>
> Which is a common idiom in DTS files.

That’s only true when the top level of nodes is encoded as a map, but
it shouldn’t be. It should be a list instead, for two reasons. First,
order matters for the top level. Subsequent top level trees have to be
applied in order to fully resolve the tree, but a map doesn’t preserve
the ordering. Second, as you rightly point out, the same name can be
used for multiple top level trees. So, the encoding should 

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Grant Likely]

On Fri, Oct 20, 2017 at 8:16 PM, Pantelis Antoniou
 wrote:
> Hi Grant,
>
>> On Oct 20, 2017, at 20:46 , Grant Likely  wrote:
>>
>> On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou
>>  wrote:
>>> Hello again,
>>>
>>> Significant progress has been made on yamldt and is now capable of
>>> not only generating yaml from DTS source but also compiling DTS sources
>>> and being almost fully compatible with DTC.
>>>
>>> Compiling the kernel's DTBs using yamldt is as simple as using a
>>> DTC=yamldt.
>>>
>>> Error reporting is accurate and validation against a YAML based schema
>>> works as well. In a short while I will begin posting patches with
>>> fixes on bindings and DTS files in the kernel.
>>>
>>> Please try it on your platform and report if you encounter any problems.
>>>
>>> https://github.com/pantoniou/yamldt
>>>
>>> I am eagerly awaiting for your comments.
>>
>> Hi Pantelis,
>>
>> This is good work. I've played around with it and I'm looking forward
>> to chatting next week.
>>
>
> Thanks. I’m looking forward to it too.
>
>> One thing I've done is tried loading the output YAML files into
>> another YAML interpreter and the current encoding causes problems.
>> Specifically, in yamldt anchors/aliases are being used as a
>> replacement for labels/phandles, but that conflicts with the YAML data
>> model which defines a reference as a way to make a copy of the data
>> appear in another part of the tree. For example, for the following
>> snippit:
>>
>> intc: intc@1 {
>>#interrupt-cells = <1>;
>>compatible = "acme,intc";
>>reg = <0x1 0x1000>;
>>gpio-controller;
>> };
>>
>> serial@2 {
>>compatible = "acme,uart";
>>reg = <0x2 0x1000>;
>>interrupt-parent = <>;
>>interrupts = <5>;
>> };
>>
>> yamldt will encode this as:
>>
>> intc@1: 
>>"#interrupt-cells": 1
>>compatible: acme,intc
>>reg: [0x1, 0x1000]
>>gpio-controller:
>>
>> serial@2:
>>compatible: acme,uart
>>reg: [0x2, 0x1000]
>>interrupt-parent: *intc
>>interrupts: 5
>>
>> But, the expected behaviour for a YAML parser is expand the alias
>> '*intc' which results in the following structure:
>>
>> intc@1: 
>>"#interrupt-cells": 1
>>compatible: acme,intc
>>reg: [0x1, 0x1000]
>>gpio-controller:
>>
>> serial@2:
>>compatible: acme,uart
>>reg: [0x2, 0x1000]
>>interrupt-parent:
>>"#interrupt-cells": 1
>>compatible: acme,intc
>>reg: [0x1, 0x1000]
>>gpio-controller:
>>interrupts: 5
>>
>> See? It results in the entire interrupt controller node to appear as
>> an instance under the interrupt-parent property, when the intention is
>> only to create a phandle. yamldt should not redefine the behaviour of
>> '*' aliases. Instead, it should use a different indicator, either
>> using an explicit !phandle tag, or by replacing '*' with something
>> else. I worked around it in my tests by replacing '*' with '$’.
>
> Yes. This is expected. I don’t think pure YAML form is a good match for all
> the crazy things that are possible (and actually used in practice) with DTS.

I don’t think it is as dire as that. The DTS structure is not complex
and I think can easily be mapped into pure YAML. But, it does require
treating the DTS structure separately from its semantic meaning. For
example, the grammar of nodes, properties and labels easily maps to
pure YAML, but phandles and overlay trees have semantic meaning that
must be resolved by DT specific code. I’ll respond to you’re specific
examples below...

>
> For instance there’s no way a normal YAML parser won’t choke with something 
> like
>
> / {
>   foo;
> };
>
> / {
>   bar;
> };
>
> Which is a common idiom in DTS files.

That’s only true when the top level of nodes is encoded as a map, but
it shouldn’t be. It should be a list instead, for two reasons. First,
order matters for the top level. Subsequent top level trees have to be
applied in order to fully resolve the tree, but a map doesn’t preserve
the ordering. Second, as you rightly point out, the same name can be
used for multiple top level trees. So, the encoding should be a list
with each list entry containing the node path {/path,}, and the
node data. One possible way to do this is 

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Grant Likely]

On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou
 wrote:
> Hello again,
>
> Significant progress has been made on yamldt and is now capable of
> not only generating yaml from DTS source but also compiling DTS sources
> and being almost fully compatible with DTC.
>
> Compiling the kernel's DTBs using yamldt is as simple as using a
> DTC=yamldt.
>
> Error reporting is accurate and validation against a YAML based schema
> works as well. In a short while I will begin posting patches with
> fixes on bindings and DTS files in the kernel.
>
> Please try it on your platform and report if you encounter any problems.
>
> https://github.com/pantoniou/yamldt
>
> I am eagerly awaiting for your comments.

Hi Pantelis,

This is good work. I've played around with it and I'm looking forward
to chatting next week.

One thing I've done is tried loading the output YAML files into
another YAML interpreter and the current encoding causes problems.
Specifically, in yamldt anchors/aliases are being used as a
replacement for labels/phandles, but that conflicts with the YAML data
model which defines a reference as a way to make a copy of the data
appear in another part of the tree. For example, for the following
snippit:

intc: intc@1 {
#interrupt-cells = <1>;
compatible = "acme,intc";
reg = <0x1 0x1000>;
gpio-controller;
};

serial@2 {
compatible = "acme,uart";
reg = <0x2 0x1000>;
interrupt-parent = <>;
interrupts = <5>;
};

yamldt will encode this as:

intc@1: 
"#interrupt-cells": 1
compatible: acme,intc
reg: [0x1, 0x1000]
gpio-controller:

serial@2:
compatible: acme,uart
reg: [0x2, 0x1000]
interrupt-parent: *intc
interrupts: 5

But, the expected behaviour for a YAML parser is expand the alias
'*intc' which results in the following structure:

intc@1: 
"#interrupt-cells": 1
compatible: acme,intc
reg: [0x1, 0x1000]
gpio-controller:

serial@2:
compatible: acme,uart
reg: [0x2, 0x1000]
interrupt-parent:
"#interrupt-cells": 1
compatible: acme,intc
reg: [0x1, 0x1000]
gpio-controller:
interrupts: 5

See? It results in the entire interrupt controller node to appear as
an instance under the interrupt-parent property, when the intention is
only to create a phandle. yamldt should not redefine the behaviour of
'*' aliases. Instead, it should use a different indicator, either
using an explicit !phandle tag, or by replacing '*' with something
else. I worked around it in my tests by replacing '*' with '$'.

Plus, it would be useful to use normal YAML anchors/aliases for
creating node templates. For example:

serial-template:  . # The anchor for the template
compatible: acme,uart
interrupt-parent: *intc

root:
serial@2:
<<: *acme-uart   # Alias node merged into serial@2
interrupts: 5
reg: [0x2, 0x1000]
serial@3:
<<: *acme-uart   # Alias node merged into serial@3
interrupts: 5
reg: [0x3, 0x1000]

Another problem with anchors/references is YAML seems to require the
anchor to be defined before the reference, or at least that's what
pyyaml and ruamel both expect. Regardless, The chosen YAML encoding
should be readily consumable by existing yaml implementations without
having to do a lot of customization.

I'm slightly concerned about using & anchors for labels because it
seems only one anchor can be defined per node, but DTC allows multiple
labels for a single node. This might not be an issue in practice
though. Another implementation issue related to using & anchors is the
YAML spec defines them as an encoding artifact, and parsers can
discard the anchor names after parsing the YAML structure, which is a
problem if we use something like $name to reference an anchor. The
solution might just be that labels need to go into a special property
so they don't disappear from the data stream.

There appears to be no place to put metadata. The root of the tree is
the top level of the YAML structure. There isn't any provision for
having a top level object to hold things like the memreserve map. We
may need a namespace to use for special properties that aren't nodes
or properties.

The encoding differentiates between nodes and properties implicitly
base on whether the contents are a map, or a scalar/list. This does
mean any parser needs to do a bit more work and it may impact what can
be done with validation (I'm not going to talk about validation in
this email though. We'll talk next week.)

Cheers,
g.

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Grant Likely]

On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou
 wrote:
> Hello again,
>
> Significant progress has been made on yamldt and is now capable of
> not only generating yaml from DTS source but also compiling DTS sources
> and being almost fully compatible with DTC.
>
> Compiling the kernel's DTBs using yamldt is as simple as using a
> DTC=yamldt.
>
> Error reporting is accurate and validation against a YAML based schema
> works as well. In a short while I will begin posting patches with
> fixes on bindings and DTS files in the kernel.
>
> Please try it on your platform and report if you encounter any problems.
>
> https://github.com/pantoniou/yamldt
>
> I am eagerly awaiting for your comments.

Hi Pantelis,

This is good work. I've played around with it and I'm looking forward
to chatting next week.

One thing I've done is tried loading the output YAML files into
another YAML interpreter and the current encoding causes problems.
Specifically, in yamldt anchors/aliases are being used as a
replacement for labels/phandles, but that conflicts with the YAML data
model which defines a reference as a way to make a copy of the data
appear in another part of the tree. For example, for the following
snippit:

intc: intc@1 {
#interrupt-cells = <1>;
compatible = "acme,intc";
reg = <0x1 0x1000>;
gpio-controller;
};

serial@2 {
compatible = "acme,uart";
reg = <0x2 0x1000>;
interrupt-parent = <>;
interrupts = <5>;
};

yamldt will encode this as:

intc@1: 
"#interrupt-cells": 1
compatible: acme,intc
reg: [0x1, 0x1000]
gpio-controller:

serial@2:
compatible: acme,uart
reg: [0x2, 0x1000]
interrupt-parent: *intc
interrupts: 5

But, the expected behaviour for a YAML parser is expand the alias
'*intc' which results in the following structure:

intc@1: 
"#interrupt-cells": 1
compatible: acme,intc
reg: [0x1, 0x1000]
gpio-controller:

serial@2:
compatible: acme,uart
reg: [0x2, 0x1000]
interrupt-parent:
"#interrupt-cells": 1
compatible: acme,intc
reg: [0x1, 0x1000]
gpio-controller:
interrupts: 5

See? It results in the entire interrupt controller node to appear as
an instance under the interrupt-parent property, when the intention is
only to create a phandle. yamldt should not redefine the behaviour of
'*' aliases. Instead, it should use a different indicator, either
using an explicit !phandle tag, or by replacing '*' with something
else. I worked around it in my tests by replacing '*' with '$'.

Plus, it would be useful to use normal YAML anchors/aliases for
creating node templates. For example:

serial-template:  . # The anchor for the template
compatible: acme,uart
interrupt-parent: *intc

root:
serial@2:
<<: *acme-uart   # Alias node merged into serial@2
interrupts: 5
reg: [0x2, 0x1000]
serial@3:
<<: *acme-uart   # Alias node merged into serial@3
interrupts: 5
reg: [0x3, 0x1000]

Another problem with anchors/references is YAML seems to require the
anchor to be defined before the reference, or at least that's what
pyyaml and ruamel both expect. Regardless, The chosen YAML encoding
should be readily consumable by existing yaml implementations without
having to do a lot of customization.

I'm slightly concerned about using & anchors for labels because it
seems only one anchor can be defined per node, but DTC allows multiple
labels for a single node. This might not be an issue in practice
though. Another implementation issue related to using & anchors is the
YAML spec defines them as an encoding artifact, and parsers can
discard the anchor names after parsing the YAML structure, which is a
problem if we use something like $name to reference an anchor. The
solution might just be that labels need to go into a special property
so they don't disappear from the data stream.

There appears to be no place to put metadata. The root of the tree is
the top level of the YAML structure. There isn't any provision for
having a top level object to hold things like the memreserve map. We
may need a namespace to use for special properties that aren't nodes
or properties.

The encoding differentiates between nodes and properties implicitly
base on whether the contents are a map, or a scalar/list. This does
mean any parser needs to do a bit more work and it may impact what can
be done with validation (I'm not going to talk about validation in
this email though. We'll talk next week.)

Cheers,
g.

Re: [PATCH] firmware: bluefield: add boot control driver

[Grant Likely]

On Tue, Oct 10, 2017 at 12:58 PM, Leif Lindholm
 wrote:
>
> On Tue, Oct 10, 2017 at 11:23:32AM +0100, Mark Rutland wrote:
>> On Tue, Oct 10, 2017 at 11:15:39AM +0100, Sudeep Holla wrote:
>> > (+Mark, Grant)
>> >
>> > On 09/10/17 18:16, Chris Metcalf wrote:
>> > > The Mellanox BlueField SoC firmware supports a safe upgrade mode as
>> > > part of the flow where users put new firmware on the secondary eMMC
>> > > boot partition (the one not currently in use), tell the eMMC to make
>> > > the secondary boot partition primary, and reset.
>>
>> When you say "firmware", are you referreind to actual firmware, or a
>> platform-specific OS image?
>>
>> For the former, the preferred update mechanism would be UpdateCapsule().
>>
>> For the latter, I'm not sure what the usual mechanism for doing this
>> with EFI would be.
>>
>> Ard, Leif?
>
> This sounds to me very much like something we'd want to keep out of
> the kernel. Assuming ACPI means UEFI, there should be less invasive
> solutions to this problem.

Agreed. This looks like a very specific solution to a generic problem.

g.

Re: [PATCH] firmware: bluefield: add boot control driver

[Grant Likely]

On Tue, Oct 10, 2017 at 12:58 PM, Leif Lindholm
 wrote:
>
> On Tue, Oct 10, 2017 at 11:23:32AM +0100, Mark Rutland wrote:
>> On Tue, Oct 10, 2017 at 11:15:39AM +0100, Sudeep Holla wrote:
>> > (+Mark, Grant)
>> >
>> > On 09/10/17 18:16, Chris Metcalf wrote:
>> > > The Mellanox BlueField SoC firmware supports a safe upgrade mode as
>> > > part of the flow where users put new firmware on the secondary eMMC
>> > > boot partition (the one not currently in use), tell the eMMC to make
>> > > the secondary boot partition primary, and reset.
>>
>> When you say "firmware", are you referreind to actual firmware, or a
>> platform-specific OS image?
>>
>> For the former, the preferred update mechanism would be UpdateCapsule().
>>
>> For the latter, I'm not sure what the usual mechanism for doing this
>> with EFI would be.
>>
>> Ard, Leif?
>
> This sounds to me very much like something we'd want to keep out of
> the kernel. Assuming ACPI means UEFI, there should be less invasive
> solutions to this problem.

Agreed. This looks like a very specific solution to a generic problem.

g.

Re: [PATCH 0/6] Shrinking DT memory usage

[Grant Likely]

On Thu, Oct 5, 2017 at 8:44 PM, Rob Herring  wrote:
> On kernels with a minimal config and a RAM target in the 100s of KB, DT
> is quite a hog of runtime memory usage. How much is dependent on how many
> nodes and properties in the DT which have a corresponding struct device_node
> and struct property in the kernel. Just skipping disabled nodes saves a
> lot by not creating the device_nodes in the first place[1], but there's
> more low hanging fruit by making some of the fields in struct property and
> struct device_node optional. With the changes here, the memory usage goes
> from 17KB to under 8KB on QEMU's ARM virt machine which is a relatively
> small DT.
>
> The majority of the diffstat here is just moving all the kobject/sysfs
> related code to its own file so we can avoid adding a bunch of ifdefs.
>
> There's more drastic approaches we could take such as doing the
> unflattening at build time and storing the bulk of the unflattened tree
> as const data. Grant also has some ideas on storing properties as ids
> instead. He's explained it to me, but I still don't understand it.

It was a two part idea. The first part is to start using numerical IDs
for property names instead of strings. The DTB format kind of already
does this because all the property names are stored in the string
table at the end of the dtb. The actual properties just reference an
offset into the string table. If we predefined ids for some property
names (reg, compatible, status, etc.), then we could have a variant of
the of_property_* API to find properties by numerical ID instead of by
strcmp().

The second idea is to eliminate struct property entirely and always
store a node's properties as a single DTB tagged list blob. It would
reduce the space required at the expense of processing time when
parsing the blob. The upshot is the property list could be left in a
flash-resident copy of the DTB.

Details need to be investigated, and it would be much more invasive
than what Rob has been able to do here. It may not be worth the
effort.

g.

Re: [PATCH 0/6] Shrinking DT memory usage

[Grant Likely]

On Thu, Oct 5, 2017 at 8:44 PM, Rob Herring  wrote:
> On kernels with a minimal config and a RAM target in the 100s of KB, DT
> is quite a hog of runtime memory usage. How much is dependent on how many
> nodes and properties in the DT which have a corresponding struct device_node
> and struct property in the kernel. Just skipping disabled nodes saves a
> lot by not creating the device_nodes in the first place[1], but there's
> more low hanging fruit by making some of the fields in struct property and
> struct device_node optional. With the changes here, the memory usage goes
> from 17KB to under 8KB on QEMU's ARM virt machine which is a relatively
> small DT.
>
> The majority of the diffstat here is just moving all the kobject/sysfs
> related code to its own file so we can avoid adding a bunch of ifdefs.
>
> There's more drastic approaches we could take such as doing the
> unflattening at build time and storing the bulk of the unflattened tree
> as const data. Grant also has some ideas on storing properties as ids
> instead. He's explained it to me, but I still don't understand it.

It was a two part idea. The first part is to start using numerical IDs
for property names instead of strings. The DTB format kind of already
does this because all the property names are stored in the string
table at the end of the dtb. The actual properties just reference an
offset into the string table. If we predefined ids for some property
names (reg, compatible, status, etc.), then we could have a variant of
the of_property_* API to find properties by numerical ID instead of by
strcmp().

The second idea is to eliminate struct property entirely and always
store a node's properties as a single DTB tagged list blob. It would
reduce the space required at the expense of processing time when
parsing the blob. The upshot is the property list could be left in a
flash-resident copy of the DTB.

Details need to be investigated, and it would be much more invasive
than what Rob has been able to do here. It may not be worth the
effort.

g.

Re: [PATCH 2/6] of: remove struct property.unique_id for FDT

[Grant Likely]

On Thu, Oct 5, 2017 at 8:44 PM, Rob Herring <r...@kernel.org> wrote:
> Only Sparc uses unique_id, so remove it for FDT builds and shrink struct
> property a bit making the unflattened DT less of a memory hog.

It can be even more constrained than that. I think the only user is
openpromfs so you could make it depend on CONFIG_SUN_OPENPROMFS, and
adjust the needed code in pdt.c.

Ideally, I'd like to be rid of unique_id entirely, but that's a much
more invasive patch set. Regardless:

Acked-by: Grant Likely <grant.lik...@secretlab.ca>

(That goes for the entire series)

>
> Cc: Nicolas Pitre <n...@linaro.org>
> Cc: Frank Rowand <frowand.l...@gmail.com>
> Signed-off-by: Rob Herring <r...@kernel.org>
> ---
>  include/linux/of.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index cfc34117fc92..8f9e96752837 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -38,7 +38,9 @@ struct property {
> void*value;
> struct property *next;
> unsigned long _flags;
> +#if defined(CONFIG_OF_PROMTREE)
> unsigned int unique_id;
> +#endif
> struct bin_attribute attr;
>  };
>
> --
> 2.11.0
>

Re: [PATCH 2/6] of: remove struct property.unique_id for FDT

[Grant Likely]

On Thu, Oct 5, 2017 at 8:44 PM, Rob Herring  wrote:
> Only Sparc uses unique_id, so remove it for FDT builds and shrink struct
> property a bit making the unflattened DT less of a memory hog.

It can be even more constrained than that. I think the only user is
openpromfs so you could make it depend on CONFIG_SUN_OPENPROMFS, and
adjust the needed code in pdt.c.

Ideally, I'd like to be rid of unique_id entirely, but that's a much
more invasive patch set. Regardless:

Acked-by: Grant Likely 

(That goes for the entire series)

>
> Cc: Nicolas Pitre 
> Cc: Frank Rowand 
> Signed-off-by: Rob Herring 
> ---
>  include/linux/of.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index cfc34117fc92..8f9e96752837 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -38,7 +38,9 @@ struct property {
> void*value;
> struct property *next;
> unsigned long _flags;
> +#if defined(CONFIG_OF_PROMTREE)
> unsigned int unique_id;
> +#endif
> struct bin_attribute attr;
>  };
>
> --
> 2.11.0
>

Re: [PATCH] of: document /sys/firmware/fdt

[Grant Likely]

On Wed, Jun 14, 2017 at 5:20 AM,  <frowand.l...@gmail.com> wrote:
> From: Frank Rowand <frank.row...@sony.com>
>
> Add ABI documentation for /sys/firmware/fdt
>
> Update contact for /sys/firmware/devicetree/* to include mail list
>
> Signed-off-by: Frank Rowand <frank.row...@sony.com>

Acked-by: Grant Likely <grant.lik...@arm.com>

(Apologies for acking from a different address. My ARM email isn't yet
set up to play nice on mailing lists.)

g.

> ---
>  Documentation/ABI/testing/sysfs-firmware-ofw | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-ofw 
> b/Documentation/ABI/testing/sysfs-firmware-ofw
> index f562b188e71d..8e700db6c295 100644
> --- a/Documentation/ABI/testing/sysfs-firmware-ofw
> +++ b/Documentation/ABI/testing/sysfs-firmware-ofw
> @@ -1,6 +1,6 @@
>  What:  /sys/firmware/devicetree/*
>  Date:  November 2013
> -Contact:   Grant Likely <grant.lik...@linaro.org>
> +Contact:   Grant Likely <grant.lik...@linaro.org>, 
> devicet...@vger.kernel.org
>  Description:
> When using OpenFirmware or a Flattened Device Tree to 
> enumerate
> hardware, the device tree structure will be exposed in this
> @@ -26,3 +26,28 @@ Description:
> name plus address). Properties are represented as files
> in the directory. The contents of each file is the exact
> binary data from the device tree.
> +
> +What:  /sys/firmware/fdt
> +Date:  February 2015
> +KernelVersion: 3.19
> +Contact:   Frank Rowand <frank.row...@sony.com>, 
> devicet...@vger.kernel.org
> +Description:
> +   Exports the FDT blob that was passed to the kernel by
> +   the bootloader. This allows userland applications such
> +   as kexec to access the raw binary. This blob is also
> +   useful when debugging since it contains any changes
> +   made to the blob by the bootloader.
> +
> +   The fact that this node does not reside under
> +   /sys/firmware/device-tree is deliberate: FDT is also used
> +   on arm64 UEFI/ACPI systems to communicate just the UEFI
> +   and ACPI entry points, but the FDT is never unflattened
> +   and used to configure the system.
> +
> +   A CRC32 checksum is calculated over the entire FDT
> +   blob, and verified at late_initcall time. The sysfs
> +   entry is instantiated only if the checksum is valid,
> +   i.e., if the FDT blob has not been modified in the mean
> +   time. Otherwise, a warning is printed.
> +Users: kexec, debugging
> +
> --
> Frank Rowand <frank.row...@sony.com>
>

Re: [PATCH] of: document /sys/firmware/fdt

[Grant Likely]

On Wed, Jun 14, 2017 at 5:20 AM,   wrote:
> From: Frank Rowand 
>
> Add ABI documentation for /sys/firmware/fdt
>
> Update contact for /sys/firmware/devicetree/* to include mail list
>
> Signed-off-by: Frank Rowand 

Acked-by: Grant Likely 

(Apologies for acking from a different address. My ARM email isn't yet
set up to play nice on mailing lists.)

g.

> ---
>  Documentation/ABI/testing/sysfs-firmware-ofw | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-ofw 
> b/Documentation/ABI/testing/sysfs-firmware-ofw
> index f562b188e71d..8e700db6c295 100644
> --- a/Documentation/ABI/testing/sysfs-firmware-ofw
> +++ b/Documentation/ABI/testing/sysfs-firmware-ofw
> @@ -1,6 +1,6 @@
>  What:  /sys/firmware/devicetree/*
>  Date:  November 2013
> -Contact:   Grant Likely 
> +Contact:   Grant Likely , 
> devicet...@vger.kernel.org
>  Description:
> When using OpenFirmware or a Flattened Device Tree to 
> enumerate
> hardware, the device tree structure will be exposed in this
> @@ -26,3 +26,28 @@ Description:
> name plus address). Properties are represented as files
> in the directory. The contents of each file is the exact
> binary data from the device tree.
> +
> +What:  /sys/firmware/fdt
> +Date:  February 2015
> +KernelVersion: 3.19
> +Contact:   Frank Rowand , 
> devicet...@vger.kernel.org
> +Description:
> +   Exports the FDT blob that was passed to the kernel by
> +   the bootloader. This allows userland applications such
> +   as kexec to access the raw binary. This blob is also
> +   useful when debugging since it contains any changes
> +   made to the blob by the bootloader.
> +
> +   The fact that this node does not reside under
> +   /sys/firmware/device-tree is deliberate: FDT is also used
> +   on arm64 UEFI/ACPI systems to communicate just the UEFI
> +   and ACPI entry points, but the FDT is never unflattened
> +   and used to configure the system.
> +
> +   A CRC32 checksum is calculated over the entire FDT
> +   blob, and verified at late_initcall time. The sysfs
> +   entry is instantiated only if the checksum is valid,
> +   i.e., if the FDT blob has not been modified in the mean
> +   time. Otherwise, a warning is printed.
> +Users: kexec, debugging
> +
> --
> Frank Rowand 
>

Re: [PATCH] of: document /sys/firmware/fdt

[Grant Likely]

I'm slowly getting back into things and plan to actively participate.
Please use my ARM address:

grant.lik...@arm.com

g.

On Wed, Jun 28, 2017 at 10:46 PM, Frank Rowand <frowand.l...@gmail.com> wrote:
> On 06/22/17 08:23, Rob Herring wrote:
>> Meant to add Grant.
>>
>> On Thu, Jun 22, 2017 at 10:21:24AM -0500, Rob Herring wrote:
>>> On Tue, Jun 13, 2017 at 09:20:07PM -0700, frowand.l...@gmail.com wrote:
>>>> From: Frank Rowand <frank.row...@sony.com>
>>>>
>>>> Add ABI documentation for /sys/firmware/fdt
>>>>
>>>> Update contact for /sys/firmware/devicetree/* to include mail list
>>>>
>>>> Signed-off-by: Frank Rowand <frank.row...@sony.com>
>>>> ---
>>>>  Documentation/ABI/testing/sysfs-firmware-ofw | 27 
>>>> ++-
>>>>  1 file changed, 26 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/ABI/testing/sysfs-firmware-ofw 
>>>> b/Documentation/ABI/testing/sysfs-firmware-ofw
>>>> index f562b188e71d..8e700db6c295 100644
>>>> --- a/Documentation/ABI/testing/sysfs-firmware-ofw
>>>> +++ b/Documentation/ABI/testing/sysfs-firmware-ofw
>>>> @@ -1,6 +1,6 @@
>>>>  What:  /sys/firmware/devicetree/*
>>>>  Date:  November 2013
>>>> -Contact:   Grant Likely <grant.lik...@linaro.org>
>>>> +Contact:   Grant Likely <grant.lik...@linaro.org>, 
>>>> devicet...@vger.kernel.org
>>>
>>> Grant's email is not valid either. I would just drop it unless he wants
>>> his secretlab.ca email.
>>>
>>> Rob
>>
>
> No response from Grant, so I'll drop his email and add the mail list.
>
> Also, for the newly added section I'll change the contact from being both
> me and the mail list to just be the mail list.
>
> -Frank

Re: [PATCH] of: document /sys/firmware/fdt

[Grant Likely]

I'm slowly getting back into things and plan to actively participate.
Please use my ARM address:

grant.lik...@arm.com

g.

On Wed, Jun 28, 2017 at 10:46 PM, Frank Rowand  wrote:
> On 06/22/17 08:23, Rob Herring wrote:
>> Meant to add Grant.
>>
>> On Thu, Jun 22, 2017 at 10:21:24AM -0500, Rob Herring wrote:
>>> On Tue, Jun 13, 2017 at 09:20:07PM -0700, frowand.l...@gmail.com wrote:
>>>> From: Frank Rowand 
>>>>
>>>> Add ABI documentation for /sys/firmware/fdt
>>>>
>>>> Update contact for /sys/firmware/devicetree/* to include mail list
>>>>
>>>> Signed-off-by: Frank Rowand 
>>>> ---
>>>>  Documentation/ABI/testing/sysfs-firmware-ofw | 27 
>>>> ++-
>>>>  1 file changed, 26 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/ABI/testing/sysfs-firmware-ofw 
>>>> b/Documentation/ABI/testing/sysfs-firmware-ofw
>>>> index f562b188e71d..8e700db6c295 100644
>>>> --- a/Documentation/ABI/testing/sysfs-firmware-ofw
>>>> +++ b/Documentation/ABI/testing/sysfs-firmware-ofw
>>>> @@ -1,6 +1,6 @@
>>>>  What:  /sys/firmware/devicetree/*
>>>>  Date:  November 2013
>>>> -Contact:   Grant Likely 
>>>> +Contact:   Grant Likely , 
>>>> devicet...@vger.kernel.org
>>>
>>> Grant's email is not valid either. I would just drop it unless he wants
>>> his secretlab.ca email.
>>>
>>> Rob
>>
>
> No response from Grant, so I'll drop his email and add the mail list.
>
> Also, for the newly added section I'll change the contact from being both
> me and the mail list to just be the mail list.
>
> -Frank

[PATCH] pci: remove error message when device not present

[Grant Likely]

It's not an error if the IBM ACPI pseudo-device isn't present, it merely
means the kernel isn't running on that IBM hardware. Get rid of the
error report so as not to pollute the kernel log with an message
irrelevant to the vast majority of users.

If someone wants to debug it, they can turn on the pr_debug() message
which will show progress through the .init function.

Reported-by: Jim Hull <jim.h...@hpe.com>
Signed-off-by: Grant Likely <grant.lik...@hpe.com>
Cc: Linn Crosetto <l...@hpe.com>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Bjorn Helgaas <bhelg...@google.com>
---
 drivers/pci/hotplug/acpiphp_ibm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/hotplug/acpiphp_ibm.c 
b/drivers/pci/hotplug/acpiphp_ibm.c
index f6221d7..ec43510 100644
--- a/drivers/pci/hotplug/acpiphp_ibm.c
+++ b/drivers/pci/hotplug/acpiphp_ibm.c
@@ -439,7 +439,6 @@ static int __init ibm_acpiphp_init(void)
if (acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, ibm_find_acpi_device, NULL,
_acpi_handle, NULL) != FOUND_APCI) {
-   pr_err("%s: acpi_walk_namespace failed\n", __func__);
retval = -ENODEV;
goto init_return;
}
-- 
2.9.3

[PATCH] pci: remove error message when device not present

[Grant Likely]

It's not an error if the IBM ACPI pseudo-device isn't present, it merely
means the kernel isn't running on that IBM hardware. Get rid of the
error report so as not to pollute the kernel log with an message
irrelevant to the vast majority of users.

If someone wants to debug it, they can turn on the pr_debug() message
which will show progress through the .init function.

Reported-by: Jim Hull 
Signed-off-by: Grant Likely 
Cc: Linn Crosetto 
Cc: "Rafael J. Wysocki" 
Cc: Bjorn Helgaas 
---
 drivers/pci/hotplug/acpiphp_ibm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/hotplug/acpiphp_ibm.c 
b/drivers/pci/hotplug/acpiphp_ibm.c
index f6221d7..ec43510 100644
--- a/drivers/pci/hotplug/acpiphp_ibm.c
+++ b/drivers/pci/hotplug/acpiphp_ibm.c
@@ -439,7 +439,6 @@ static int __init ibm_acpiphp_init(void)
if (acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, ibm_find_acpi_device, NULL,
_acpi_handle, NULL) != FOUND_APCI) {
-   pr_err("%s: acpi_walk_namespace failed\n", __func__);
retval = -ENODEV;
goto init_return;
}
-- 
2.9.3

Re: [PATCH] of: Prevent unaligned access in of_alias_scan()

[Grant Likely]

On Fri, Sep 23, 2016 at 4:38 PM, Paul Burton <paul.bur...@imgtec.com> wrote:
> When allocating a struct alias_prop, of_alias_scan() only requested that
> it be aligned on a 4 byte boundary. The struct contains pointers which
> leads to us attempting 64 bit writes on 64 bit systems, and if the CPU
> doesn't support unaligned memory accesses then this causes problems -
> for example on some MIPS64r2 CPUs including the "mips64r2-generic" QEMU
> emulated CPU it will trigger an address error exception.
>
> Fix this by requesting alignment for the struct alias_prop allocation
> matching that which the compiler expects, using the __alignof__ keyword.
>
> Signed-off-by: Paul Burton <paul.bur...@imgtec.com>

Looks right to me.

Reviewed-by: Grant Likely <grant.lik...@secretlab.ca>

> Cc: devicet...@vger.kernel.org
> Cc: Rob Herring <robh...@kernel.org>
> Cc: Frank Rowand <frowand.l...@gmail.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: Ralf Baechle <r...@linux-mips.org>
> ---
>  drivers/of/base.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 3ce6953..448aa40 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2042,7 +2042,7 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 
> align))
> continue;
>
> /* Allocate an alias_prop with enough space for the stem */
> -   ap = dt_alloc(sizeof(*ap) + len + 1, 4);
> +   ap = dt_alloc(sizeof(*ap) + len + 1, __alignof__(*ap));
> if (!ap)
> continue;
> memset(ap, 0, sizeof(*ap) + len + 1);
> --
> 2.10.0
>

Re: [PATCH] of: Prevent unaligned access in of_alias_scan()

[Grant Likely]

On Fri, Sep 23, 2016 at 4:38 PM, Paul Burton  wrote:
> When allocating a struct alias_prop, of_alias_scan() only requested that
> it be aligned on a 4 byte boundary. The struct contains pointers which
> leads to us attempting 64 bit writes on 64 bit systems, and if the CPU
> doesn't support unaligned memory accesses then this causes problems -
> for example on some MIPS64r2 CPUs including the "mips64r2-generic" QEMU
> emulated CPU it will trigger an address error exception.
>
> Fix this by requesting alignment for the struct alias_prop allocation
> matching that which the compiler expects, using the __alignof__ keyword.
>
> Signed-off-by: Paul Burton 

Looks right to me.

Reviewed-by: Grant Likely 

> Cc: devicet...@vger.kernel.org
> Cc: Rob Herring 
> Cc: Frank Rowand 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: Ralf Baechle 
> ---
>  drivers/of/base.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 3ce6953..448aa40 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2042,7 +2042,7 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 
> align))
> continue;
>
> /* Allocate an alias_prop with enough space for the stem */
> -   ap = dt_alloc(sizeof(*ap) + len + 1, 4);
> +   ap = dt_alloc(sizeof(*ap) + len + 1, __alignof__(*ap));
> if (!ap)
> continue;
> memset(ap, 0, sizeof(*ap) + len + 1);
> --
> 2.10.0
>

Re: EFI co-maintainer

[Grant Likely]

On Wed, Sep 21, 2016 at 4:09 PM, Matt Fleming  wrote:
> Folks,
>
> I've asked, and Ard has agreed to step up and help me co-maintain the
> EFI subsystem.
>
> Given that there are now two maintainers, we're moving to a shared git
> repository on kernel.org, hosted at,
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
>
> Expect a MAINTAINERS patch soon.
>
> I do plan on keeping the existing tree in sync for the time being, so
> it won't actually matter which repository people base their patches
> on. Hopefully the disruption to patch submitters will be minimal.
>
> Thanks again Ard!

Brilliant! That is excellent news.

g.

Re: EFI co-maintainer

[Grant Likely]

On Wed, Sep 21, 2016 at 4:09 PM, Matt Fleming  wrote:
> Folks,
>
> I've asked, and Ard has agreed to step up and help me co-maintain the
> EFI subsystem.
>
> Given that there are now two maintainers, we're moving to a shared git
> repository on kernel.org, hosted at,
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
>
> Expect a MAINTAINERS patch soon.
>
> I do plan on keeping the existing tree in sync for the time being, so
> it won't actually matter which repository people base their patches
> on. Hopefully the disruption to patch submitters will be minimal.
>
> Thanks again Ard!

Brilliant! That is excellent news.

g.

Re: [PATCH v2 0/6] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Wed, Aug 24, 2016 at 10:23 PM, Jonathan Cameron <ji...@kernel.org> wrote:
> On 24/08/16 22:14, Jiri Kosina wrote:
>> On Wed, 24 Aug 2016, Grant Likely wrote:
>>
>>>>> v2:
>>>>> - Overview in documentation show analogy with usbhid implementation
>>>>> - sparse errors for statics. Also pointed by Jiri
>>>>> - Clearly marking exported function header file. Clean up all exports
>>>>> unused inteface functions
>>>>> - Changed to tristate from boolean as pointed by Jiri:
>>>>> this required remove/unload functions
>>>>> - Prevent crash when ISH enabled on non supported platform
>>>>> - Break client.c to smaller part by seprating buffer allocations
>>>>> - move bus register/unregister to ishtp module
>>>>> - There is only one config symbol INTEL_ISH_HID, removed silent
>>>>> config for TRANSPORT and IPC
>>>>
>>>> Tested-by: Grant Likely <grant.lik...@secretlab.ca>
>>>>
>>>> On an HP Spectre x360 laptop using v4.7-rc5.
>>>
>>> Hey Srinivas. Any progress on this patch series?
>>
>> The HID part (with patch #5 omitted) should be in linux-next through
>> hid.git already.
>>
> The one IIO patch was pulled by Greg KH last night so hit linux next
> today.  Hence all on it's way by the sound of it!

Nice!

Unfortunately, I've just hit a new bug after updating to v4.8-rc4.
4.7.0-rc6 works fine.

The kernel boots, and the driver loads, but the orientations are
wrong. It appears that the X/Y is getting swapped:

Normal orientation: display rotated 90 degrees CW
Rotated 90 degrees CW: display normal orientation
Rotated 180 degrees (upside down): display rotated 90 degrees CCW
Rotated 90 degrees CCW: display rotated 180 degrees

Cheers,
g.

Re: [PATCH v2 0/6] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Wed, Aug 24, 2016 at 10:23 PM, Jonathan Cameron  wrote:
> On 24/08/16 22:14, Jiri Kosina wrote:
>> On Wed, 24 Aug 2016, Grant Likely wrote:
>>
>>>>> v2:
>>>>> - Overview in documentation show analogy with usbhid implementation
>>>>> - sparse errors for statics. Also pointed by Jiri
>>>>> - Clearly marking exported function header file. Clean up all exports
>>>>> unused inteface functions
>>>>> - Changed to tristate from boolean as pointed by Jiri:
>>>>> this required remove/unload functions
>>>>> - Prevent crash when ISH enabled on non supported platform
>>>>> - Break client.c to smaller part by seprating buffer allocations
>>>>> - move bus register/unregister to ishtp module
>>>>> - There is only one config symbol INTEL_ISH_HID, removed silent
>>>>> config for TRANSPORT and IPC
>>>>
>>>> Tested-by: Grant Likely 
>>>>
>>>> On an HP Spectre x360 laptop using v4.7-rc5.
>>>
>>> Hey Srinivas. Any progress on this patch series?
>>
>> The HID part (with patch #5 omitted) should be in linux-next through
>> hid.git already.
>>
> The one IIO patch was pulled by Greg KH last night so hit linux next
> today.  Hence all on it's way by the sound of it!

Nice!

Unfortunately, I've just hit a new bug after updating to v4.8-rc4.
4.7.0-rc6 works fine.

The kernel boots, and the driver loads, but the orientations are
wrong. It appears that the X/Y is getting swapped:

Normal orientation: display rotated 90 degrees CW
Rotated 90 degrees CW: display normal orientation
Rotated 180 degrees (upside down): display rotated 90 degrees CCW
Rotated 90 degrees CCW: display rotated 180 degrees

Cheers,
g.

Re: [PATCH v2 0/6] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Tue, Jul 5, 2016 at 8:42 AM, Grant Likely <glik...@secretlab.ca> wrote:
>
> On 22/06/16 06:40, Srinivas Pandruvada wrote:
>>
>> Change log
>> v2:
>> - Overview in documentation show analogy with usbhid implementation
>> - sparse errors for statics. Also pointed by Jiri
>> - Clearly marking exported function header file. Clean up all exports
>> unused inteface functions
>> - Changed to tristate from boolean as pointed by Jiri:
>> this required remove/unload functions
>> - Prevent crash when ISH enabled on non supported platform
>> - Break client.c to smaller part by seprating buffer allocations
>> - move bus register/unregister to ishtp module
>> - There is only one config symbol INTEL_ISH_HID, removed silent
>> config for TRANSPORT and IPC
>
> Tested-by: Grant Likely <grant.lik...@secretlab.ca>
>
> On an HP Spectre x360 laptop using v4.7-rc5.

Hey Srinivas. Any progress on this patch series?

g.

Re: [PATCH v2 0/6] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Tue, Jul 5, 2016 at 8:42 AM, Grant Likely  wrote:
>
> On 22/06/16 06:40, Srinivas Pandruvada wrote:
>>
>> Change log
>> v2:
>> - Overview in documentation show analogy with usbhid implementation
>> - sparse errors for statics. Also pointed by Jiri
>> - Clearly marking exported function header file. Clean up all exports
>> unused inteface functions
>> - Changed to tristate from boolean as pointed by Jiri:
>> this required remove/unload functions
>> - Prevent crash when ISH enabled on non supported platform
>> - Break client.c to smaller part by seprating buffer allocations
>> - move bus register/unregister to ishtp module
>> - There is only one config symbol INTEL_ISH_HID, removed silent
>> config for TRANSPORT and IPC
>
> Tested-by: Grant Likely 
>
> On an HP Spectre x360 laptop using v4.7-rc5.

Hey Srinivas. Any progress on this patch series?

g.

Re: [PATCH v2 0/6] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On 22/06/16 06:40, Srinivas Pandruvada wrote:

Change log
v2:
- Overview in documentation show analogy with usbhid implementation
- sparse errors for statics. Also pointed by Jiri
- Clearly marking exported function header file. Clean up all exports
unused inteface functions
- Changed to tristate from boolean as pointed by Jiri:
this required remove/unload functions
- Prevent crash when ISH enabled on non supported platform
- Break client.c to smaller part by seprating buffer allocations
- move bus register/unregister to ishtp module
- There is only one config symbol INTEL_ISH_HID, removed silent
config for TRANSPORT and IPC

Tested-by: Grant Likely <grant.lik...@secretlab.ca>

On an HP Spectre x360 laptop using v4.7-rc5.

In related news, the problem I had with the rotation events not showing 
up on v1 of this series went away. I don't have a reason why, it just 
suddenly started working.


g.



Starting from Cherrytrail, multiple generation of Intel processors offers
on package sensor hub. Several recent tablets, 2-in-1 convertible laptops
are using ISH instead of external sensor hubs. This resulted in lack of
support of sensor function like device rotation and auto backlight
adjustment.
In addition, depending on the OEM implementation, support of ISH is required
to support low power sleep states.

The support of ISH on Linux platforms is not new. Android platforms with
Intel SoCs had this support for a while submitted by Daniel Drubin.
This patcheset is reusing most of those changes with  clean up and
removing Android platform specific changes.

The user mode ABI is still same as external sensor hubs using Linux
IIO. So existing user mode software should still work.
This series primarily brings in new HID transport used in ISH.

Thanks to the community members who tested RFC patches and provided
feedback.

For users testing on Linux distributions using IIO sensor proxy,
a short term work around is required till we have debugged this issue.
In systemd unit file iio-sensor-proxy.service
In the section "[Unit]" add
After=multi-user.target

Daniel Drubin (3):
   hid: intel_ish-hid: ISH Transport layer
   hid: intel-ish-hid: ipc layer
   hid: intel-ish-hid: ISH HID client driver

Srinivas Pandruvada (3):
   Documentation: hid: Intel ISH HID document
   iio: hid-sensors: use asynchronous resume
   hid: hid-sensor-hub: Add ISH quirk

  Documentation/hid/intel-ish-hid.txt| 449 ++
  drivers/hid/Kconfig|   2 +
  drivers/hid/Makefile   |   2 +
  drivers/hid/hid-sensor-hub.c   |   4 +
  drivers/hid/intel-ish-hid/Kconfig  |  17 +
  drivers/hid/intel-ish-hid/Makefile |  22 +
  drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h| 220 +
  drivers/hid/intel-ish-hid/ipc/hw-ish.h |  71 ++
  drivers/hid/intel-ish-hid/ipc/ipc.c| 719 
  drivers/hid/intel-ish-hid/ipc/pci-ish.c| 327 +++
  drivers/hid/intel-ish-hid/ipc/utils.h  |  64 ++
  drivers/hid/intel-ish-hid/ishtp-hid-client.c   | 935 +
  drivers/hid/intel-ish-hid/ishtp-hid.c  | 234 ++
  drivers/hid/intel-ish-hid/ishtp-hid.h  | 182 
  drivers/hid/intel-ish-hid/ishtp/bus.c  | 780 +
  drivers/hid/intel-ish-hid/ishtp/bus.h  | 110 +++
  drivers/hid/intel-ish-hid/ishtp/client-buffers.c   | 214 +
  drivers/hid/intel-ish-hid/ishtp/client.c   | 935 +
  drivers/hid/intel-ish-hid/ishtp/client.h   | 182 
  drivers/hid/intel-ish-hid/ishtp/dma-if.c   | 178 
  drivers/hid/intel-ish-hid/ishtp/hbm.c  | 908 
  drivers/hid/intel-ish-hid/ishtp/hbm.h  | 321 +++
  drivers/hid/intel-ish-hid/ishtp/init.c |  93 ++
  drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h| 277 ++
  .../iio/common/hid-sensors/hid-sensor-trigger.c|  21 +-
  include/linux/hid-sensor-hub.h |   1 +
  include/trace/events/intel_ish.h   |  30 +
  include/uapi/linux/input.h |   1 +
  28 files changed, 7298 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/hid/intel-ish-hid.txt
  create mode 100644 drivers/hid/intel-ish-hid/Kconfig
  create mode 100644 drivers/hid/intel-ish-hid/Makefile
  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
  create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
  create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
  create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h
  create mode 100644 drivers/hid/intel-ish

Re: [PATCH v2 0/6] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On 22/06/16 06:40, Srinivas Pandruvada wrote:

Change log
v2:
- Overview in documentation show analogy with usbhid implementation
- sparse errors for statics. Also pointed by Jiri
- Clearly marking exported function header file. Clean up all exports
unused inteface functions
- Changed to tristate from boolean as pointed by Jiri:
this required remove/unload functions
- Prevent crash when ISH enabled on non supported platform
- Break client.c to smaller part by seprating buffer allocations
- move bus register/unregister to ishtp module
- There is only one config symbol INTEL_ISH_HID, removed silent
config for TRANSPORT and IPC

Tested-by: Grant Likely 

On an HP Spectre x360 laptop using v4.7-rc5.

In related news, the problem I had with the rotation events not showing 
up on v1 of this series went away. I don't have a reason why, it just 
suddenly started working.


g.



Starting from Cherrytrail, multiple generation of Intel processors offers
on package sensor hub. Several recent tablets, 2-in-1 convertible laptops
are using ISH instead of external sensor hubs. This resulted in lack of
support of sensor function like device rotation and auto backlight
adjustment.
In addition, depending on the OEM implementation, support of ISH is required
to support low power sleep states.

The support of ISH on Linux platforms is not new. Android platforms with
Intel SoCs had this support for a while submitted by Daniel Drubin.
This patcheset is reusing most of those changes with  clean up and
removing Android platform specific changes.

The user mode ABI is still same as external sensor hubs using Linux
IIO. So existing user mode software should still work.
This series primarily brings in new HID transport used in ISH.

Thanks to the community members who tested RFC patches and provided
feedback.

For users testing on Linux distributions using IIO sensor proxy,
a short term work around is required till we have debugged this issue.
In systemd unit file iio-sensor-proxy.service
In the section "[Unit]" add
After=multi-user.target

Daniel Drubin (3):
   hid: intel_ish-hid: ISH Transport layer
   hid: intel-ish-hid: ipc layer
   hid: intel-ish-hid: ISH HID client driver

Srinivas Pandruvada (3):
   Documentation: hid: Intel ISH HID document
   iio: hid-sensors: use asynchronous resume
   hid: hid-sensor-hub: Add ISH quirk

  Documentation/hid/intel-ish-hid.txt| 449 ++
  drivers/hid/Kconfig|   2 +
  drivers/hid/Makefile   |   2 +
  drivers/hid/hid-sensor-hub.c   |   4 +
  drivers/hid/intel-ish-hid/Kconfig  |  17 +
  drivers/hid/intel-ish-hid/Makefile |  22 +
  drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h| 220 +
  drivers/hid/intel-ish-hid/ipc/hw-ish.h |  71 ++
  drivers/hid/intel-ish-hid/ipc/ipc.c| 719 
  drivers/hid/intel-ish-hid/ipc/pci-ish.c| 327 +++
  drivers/hid/intel-ish-hid/ipc/utils.h  |  64 ++
  drivers/hid/intel-ish-hid/ishtp-hid-client.c   | 935 +
  drivers/hid/intel-ish-hid/ishtp-hid.c  | 234 ++
  drivers/hid/intel-ish-hid/ishtp-hid.h  | 182 
  drivers/hid/intel-ish-hid/ishtp/bus.c  | 780 +
  drivers/hid/intel-ish-hid/ishtp/bus.h  | 110 +++
  drivers/hid/intel-ish-hid/ishtp/client-buffers.c   | 214 +
  drivers/hid/intel-ish-hid/ishtp/client.c   | 935 +
  drivers/hid/intel-ish-hid/ishtp/client.h   | 182 
  drivers/hid/intel-ish-hid/ishtp/dma-if.c   | 178 
  drivers/hid/intel-ish-hid/ishtp/hbm.c  | 908 
  drivers/hid/intel-ish-hid/ishtp/hbm.h  | 321 +++
  drivers/hid/intel-ish-hid/ishtp/init.c |  93 ++
  drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h| 277 ++
  .../iio/common/hid-sensors/hid-sensor-trigger.c|  21 +-
  include/linux/hid-sensor-hub.h |   1 +
  include/trace/events/intel_ish.h   |  30 +
  include/uapi/linux/input.h |   1 +
  28 files changed, 7298 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/hid/intel-ish-hid.txt
  create mode 100644 drivers/hid/intel-ish-hid/Kconfig
  create mode 100644 drivers/hid/intel-ish-hid/Makefile
  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
  create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
  create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
  create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h
  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.c
  create mode 1006

Re: [PATCH 0/6] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Sat, Jun 11, 2016 at 1:13 PM, Srinivas Pandruvada
<srinivas.pandruv...@linux.intel.com> wrote:
> Starting from Cherrytrail, multiple generation of Intel processors offers
> on package sensor hub. Several recent tablets, 2-in-1 convertible laptops
> are using ISH instead of external sensor hubs. This resulted in lack of
> support of sensor function like device rotation and auto backlight
> adjustment.
> In addition, depending on the OEM implementation, support of ISH is required
> to support low power sleep states.
>
> The support of ISH on Linux platforms is not new. Android platforms with
> Intel SoCs had this support for a while submitted by Daniel Drubin.
> This patcheset is reusing most of those changes with  clean up and
> removing Android platform specific changes.
>
> The user mode ABI is still same as external sensor hubs using Linux
> IIO. So existing user mode software should still work.
> This series primarily brings in new HID transport used in ISH.
>
> Thanks to the community members who tested RFC patches and provided
> feedback.
>
> For users testing on Linux distributions using IIO sensor proxy,
> a short term work around is required till we have debugged this issue.
> In systemd unit file iio-sensor-proxy.service
> In the section "[Unit]" add
> After=multi-user.target

Tested-by: Grant Likely <grant.lik...@hpe.com>

There is still a fiddly problem on my laptop where the sensor data
doesn't always start streaming, but otherwise this version works for
me.

g.

>
> Daniel Drubin (3):
>   hid: intel_ish-hid: ISH Transport layer
>   hid: intel-ish-hid: ipc layer
>   hid: intel-ish-hid: ISH HID client driver
>
> Srinivas Pandruvada (3):
>   Documentation: hid: Intel ISH HID document
>   iio: hid-sensors: use asynchronous resume
>   hid: hid-sensor-hub: Add ISH quirk
>
>  Documentation/hid/intel-ish-hid.txt|  417 
>  drivers/hid/Kconfig|2 +
>  drivers/hid/Makefile   |2 +
>  drivers/hid/hid-sensor-hub.c   |4 +
>  drivers/hid/intel-ish-hid/Kconfig  |   27 +
>  drivers/hid/intel-ish-hid/Makefile |   20 +
>  drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h|  220 
>  drivers/hid/intel-ish-hid/ipc/hw-ish.h |   70 ++
>  drivers/hid/intel-ish-hid/ipc/ipc.c|  720 +
>  drivers/hid/intel-ish-hid/ipc/pci-ish.c|  305 ++
>  drivers/hid/intel-ish-hid/ipc/utils.h  |   64 ++
>  drivers/hid/intel-ish-hid/ishtp-hid-client.c   |  922 
>  drivers/hid/intel-ish-hid/ishtp-hid.c  |  231 
>  drivers/hid/intel-ish-hid/ishtp-hid.h  |  182 
>  drivers/hid/intel-ish-hid/ishtp/bus.c  |  774 ++
>  drivers/hid/intel-ish-hid/ishtp/bus.h  |  105 ++
>  drivers/hid/intel-ish-hid/ishtp/client.c   | 1129 
> 
>  drivers/hid/intel-ish-hid/ishtp/client.h   |  194 
>  drivers/hid/intel-ish-hid/ishtp/dma-if.c   |  178 +++
>  drivers/hid/intel-ish-hid/ishtp/hbm.c  |  911 
>  drivers/hid/intel-ish-hid/ishtp/hbm.h  |  319 ++
>  drivers/hid/intel-ish-hid/ishtp/init.c |   94 ++
>  drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h|  280 +
>  .../iio/common/hid-sensors/hid-sensor-trigger.c|   21 +-
>  include/linux/hid-sensor-hub.h |1 +
>  include/trace/events/intel_ish.h   |   30 +
>  include/uapi/linux/input.h |1 +
>  27 files changed, 7222 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/hid/intel-ish-hid.txt
>  create mode 100644 drivers/hid/intel-ish-hid/Kconfig
>  create mode 100644 drivers/hid/intel-ish-hid/Makefile
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/dma-if.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/init.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
>  create mode 100644 include/trace/events/intel_ish.h
>
> --
> 2.5.5
>

Re: [PATCH 0/6] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Sat, Jun 11, 2016 at 1:13 PM, Srinivas Pandruvada
 wrote:
> Starting from Cherrytrail, multiple generation of Intel processors offers
> on package sensor hub. Several recent tablets, 2-in-1 convertible laptops
> are using ISH instead of external sensor hubs. This resulted in lack of
> support of sensor function like device rotation and auto backlight
> adjustment.
> In addition, depending on the OEM implementation, support of ISH is required
> to support low power sleep states.
>
> The support of ISH on Linux platforms is not new. Android platforms with
> Intel SoCs had this support for a while submitted by Daniel Drubin.
> This patcheset is reusing most of those changes with  clean up and
> removing Android platform specific changes.
>
> The user mode ABI is still same as external sensor hubs using Linux
> IIO. So existing user mode software should still work.
> This series primarily brings in new HID transport used in ISH.
>
> Thanks to the community members who tested RFC patches and provided
> feedback.
>
> For users testing on Linux distributions using IIO sensor proxy,
> a short term work around is required till we have debugged this issue.
> In systemd unit file iio-sensor-proxy.service
> In the section "[Unit]" add
> After=multi-user.target

Tested-by: Grant Likely 

There is still a fiddly problem on my laptop where the sensor data
doesn't always start streaming, but otherwise this version works for
me.

g.

>
> Daniel Drubin (3):
>   hid: intel_ish-hid: ISH Transport layer
>   hid: intel-ish-hid: ipc layer
>   hid: intel-ish-hid: ISH HID client driver
>
> Srinivas Pandruvada (3):
>   Documentation: hid: Intel ISH HID document
>   iio: hid-sensors: use asynchronous resume
>   hid: hid-sensor-hub: Add ISH quirk
>
>  Documentation/hid/intel-ish-hid.txt|  417 
>  drivers/hid/Kconfig|2 +
>  drivers/hid/Makefile   |2 +
>  drivers/hid/hid-sensor-hub.c   |4 +
>  drivers/hid/intel-ish-hid/Kconfig  |   27 +
>  drivers/hid/intel-ish-hid/Makefile |   20 +
>  drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h|  220 
>  drivers/hid/intel-ish-hid/ipc/hw-ish.h |   70 ++
>  drivers/hid/intel-ish-hid/ipc/ipc.c|  720 +
>  drivers/hid/intel-ish-hid/ipc/pci-ish.c|  305 ++
>  drivers/hid/intel-ish-hid/ipc/utils.h  |   64 ++
>  drivers/hid/intel-ish-hid/ishtp-hid-client.c   |  922 
>  drivers/hid/intel-ish-hid/ishtp-hid.c  |  231 
>  drivers/hid/intel-ish-hid/ishtp-hid.h  |  182 
>  drivers/hid/intel-ish-hid/ishtp/bus.c  |  774 ++
>  drivers/hid/intel-ish-hid/ishtp/bus.h  |  105 ++
>  drivers/hid/intel-ish-hid/ishtp/client.c   | 1129 
> 
>  drivers/hid/intel-ish-hid/ishtp/client.h   |  194 
>  drivers/hid/intel-ish-hid/ishtp/dma-if.c   |  178 +++
>  drivers/hid/intel-ish-hid/ishtp/hbm.c  |  911 
>  drivers/hid/intel-ish-hid/ishtp/hbm.h  |  319 ++
>  drivers/hid/intel-ish-hid/ishtp/init.c |   94 ++
>  drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h|  280 +
>  .../iio/common/hid-sensors/hid-sensor-trigger.c|   21 +-
>  include/linux/hid-sensor-hub.h |1 +
>  include/trace/events/intel_ish.h   |   30 +
>  include/uapi/linux/input.h |1 +
>  27 files changed, 7222 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/hid/intel-ish-hid.txt
>  create mode 100644 drivers/hid/intel-ish-hid/Kconfig
>  create mode 100644 drivers/hid/intel-ish-hid/Makefile
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/dma-if.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/init.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
>  create mode 100644 include/trace/events/intel_ish.h
>
> --
> 2.5.5
>

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Tue, Jun 14, 2016 at 6:01 PM, Bastien Nocera <had...@hadess.net> wrote:
> On Tue, 2016-06-14 at 17:08 +0100, Grant Likely wrote:
>> On Tue, Jun 14, 2016 at 4:12 PM, Bastien Nocera <had...@hadess.net>
>> wrote:
>> > On Tue, 2016-06-14 at 14:44 +0100, Grant Likely wrote:
>> > > On Fri, Jun 10, 2016 at 4:27 PM, Bastien Nocera <had...@hadess.ne
>> > > t>
>> > > wrote:
>> > > > On Fri, 2016-06-10 at 08:23 -0700, Srinivas Pandruvada wrote:
>> > > > > On Fri, 2016-06-10 at 17:04 +0200, Bastien Nocera wrote:
>> > > > > > >
>> > > > >
>> > > > > [...]
>> > > > >
>> > > > > > Are there any errors when setting the triggers?
>> > > > > >
>> > > > > Is there any debug option in this service to give more
>> > > > > verbose
>> > > > > output?
>> > > >
>> > > > Add:
>> > > > Environment="G_MESSAGES_DEBUG=all"
>> > > >
>> > > > To the service file. You should see the debug in systemctl:
>> > > > systemctl status iio-sensor-proxy.service
>> > > >
>> > > > Or in journalctl if there's too much data:
>> > > > journalctl --reverse -u iio-sensor-proxy.service
>> > >
>> > > Still no joy on the sensors. The proxy starts up and detects the
>> > > sensors, but I don't see any sensor events occurring:
>> >
>> > Could you try again with the current master of iio-sensor-proxy?
>> > Make
>> > sure to install the file in the same location as in your distro
>> > provided package.
>> >
>> > I've added more debug/warnings to a few cases where it would have
>> > silently failed in the past.
>> >
>> > In particular, I don't see any messages that would be coming out
>> > of:
>> > https://github.com/hadess/iio-sensor-proxy/blob/master/src/iio-buff
>> > er-utils.c#L512
>> >
>> > Could it be that the sub-directory is populated after the device is
>> > created in the kernel, causing a race?
>> >
>> > Either that, or the contents of the scan_elements/ directory is not
>> > the
>> > one expected by this code.
>> >
>> > The output of this command should us that:
>> > ls /sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-
>> > A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-
>> > 200073.8.auto/iio:device1/scan_elements
>>
>> Hmmm, this is interesting. I fetched, built and ran the latest
>> iio-sensor-proxy. It quit with the following error. However,
>> immediately afterwards, I ran the Debian packaged version (1.1-1),
>> and
>> the sensors started to work. Something in the latest master activates
>> the sensors enough for the older version to work.
>
> There's no changes in that code other than me introducing a bug that'd
> make it throw a warning when the sensor was already enabled. Fixed now.
>
> Could you try again, but make sure to replace the existing iio-sensor-
> proxy so it's started on boot, when the device appears. If you see the
> warning again, please attach the output out from "ls" as requested in
> the earlier mail.

Oops, missed that the first time. Here you go:

root@gladys:~# ls
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1/scan_elements
in_accel_x_en in_accel_y_en in_accel_z_en
in_accel_x_index  in_accel_y_index  in_accel_z_index
in_accel_x_type   in_accel_y_type   in_accel_z_type

> If it doesn't warn on startup, and it fails to work, then we're
> probably looking at a bug in the kernel...

Here is the output. The latest master still doesn't work. However, it
has the same behaviour that running the broken version of
iio-sensors-proxy (207b5bbd8) will cause the good one start working
(92fa6ea9e).

-- Logs begin at Tue 2016-06-14 22:19:47 BST, end at Tue 2016-06-14
22:20:52 BST. --
Jun 14 22:19:48 gladys systemd[1]: Starting IIO Sensor Proxy service...
Jun 14 22:19:48 gladys iio-sensor-proxy[577]: ** (process:577): DEBUG:
Found accel_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
Jun 14 22:19:48 gladys iio-sensor-proxy[577]: ** (process:577): DEBUG:
Found device 
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
of type accelerometer at IIO Buffer accelerometer
Jun 14 22:19:48 gladys iio-sensor-

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Tue, Jun 14, 2016 at 6:01 PM, Bastien Nocera  wrote:
> On Tue, 2016-06-14 at 17:08 +0100, Grant Likely wrote:
>> On Tue, Jun 14, 2016 at 4:12 PM, Bastien Nocera 
>> wrote:
>> > On Tue, 2016-06-14 at 14:44 +0100, Grant Likely wrote:
>> > > On Fri, Jun 10, 2016 at 4:27 PM, Bastien Nocera > > > t>
>> > > wrote:
>> > > > On Fri, 2016-06-10 at 08:23 -0700, Srinivas Pandruvada wrote:
>> > > > > On Fri, 2016-06-10 at 17:04 +0200, Bastien Nocera wrote:
>> > > > > > >
>> > > > >
>> > > > > [...]
>> > > > >
>> > > > > > Are there any errors when setting the triggers?
>> > > > > >
>> > > > > Is there any debug option in this service to give more
>> > > > > verbose
>> > > > > output?
>> > > >
>> > > > Add:
>> > > > Environment="G_MESSAGES_DEBUG=all"
>> > > >
>> > > > To the service file. You should see the debug in systemctl:
>> > > > systemctl status iio-sensor-proxy.service
>> > > >
>> > > > Or in journalctl if there's too much data:
>> > > > journalctl --reverse -u iio-sensor-proxy.service
>> > >
>> > > Still no joy on the sensors. The proxy starts up and detects the
>> > > sensors, but I don't see any sensor events occurring:
>> >
>> > Could you try again with the current master of iio-sensor-proxy?
>> > Make
>> > sure to install the file in the same location as in your distro
>> > provided package.
>> >
>> > I've added more debug/warnings to a few cases where it would have
>> > silently failed in the past.
>> >
>> > In particular, I don't see any messages that would be coming out
>> > of:
>> > https://github.com/hadess/iio-sensor-proxy/blob/master/src/iio-buff
>> > er-utils.c#L512
>> >
>> > Could it be that the sub-directory is populated after the device is
>> > created in the kernel, causing a race?
>> >
>> > Either that, or the contents of the scan_elements/ directory is not
>> > the
>> > one expected by this code.
>> >
>> > The output of this command should us that:
>> > ls /sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-
>> > A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-
>> > 200073.8.auto/iio:device1/scan_elements
>>
>> Hmmm, this is interesting. I fetched, built and ran the latest
>> iio-sensor-proxy. It quit with the following error. However,
>> immediately afterwards, I ran the Debian packaged version (1.1-1),
>> and
>> the sensors started to work. Something in the latest master activates
>> the sensors enough for the older version to work.
>
> There's no changes in that code other than me introducing a bug that'd
> make it throw a warning when the sensor was already enabled. Fixed now.
>
> Could you try again, but make sure to replace the existing iio-sensor-
> proxy so it's started on boot, when the device appears. If you see the
> warning again, please attach the output out from "ls" as requested in
> the earlier mail.

Oops, missed that the first time. Here you go:

root@gladys:~# ls
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1/scan_elements
in_accel_x_en in_accel_y_en in_accel_z_en
in_accel_x_index  in_accel_y_index  in_accel_z_index
in_accel_x_type   in_accel_y_type   in_accel_z_type

> If it doesn't warn on startup, and it fails to work, then we're
> probably looking at a bug in the kernel...

Here is the output. The latest master still doesn't work. However, it
has the same behaviour that running the broken version of
iio-sensors-proxy (207b5bbd8) will cause the good one start working
(92fa6ea9e).

-- Logs begin at Tue 2016-06-14 22:19:47 BST, end at Tue 2016-06-14
22:20:52 BST. --
Jun 14 22:19:48 gladys systemd[1]: Starting IIO Sensor Proxy service...
Jun 14 22:19:48 gladys iio-sensor-proxy[577]: ** (process:577): DEBUG:
Found accel_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
Jun 14 22:19:48 gladys iio-sensor-proxy[577]: ** (process:577): DEBUG:
Found device 
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
of type accelerometer at IIO Buffer accelerometer
Jun 14 22:19:48 gladys iio-sensor-proxy[577]: ** (process:577): DEBUG:
Found magn_3d at
/sys/devices/pci:00/00

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Tue, Jun 14, 2016 at 4:12 PM, Bastien Nocera <had...@hadess.net> wrote:
> On Tue, 2016-06-14 at 14:44 +0100, Grant Likely wrote:
>> On Fri, Jun 10, 2016 at 4:27 PM, Bastien Nocera <had...@hadess.net>
>> wrote:
>> > On Fri, 2016-06-10 at 08:23 -0700, Srinivas Pandruvada wrote:
>> > > On Fri, 2016-06-10 at 17:04 +0200, Bastien Nocera wrote:
>> > > > >
>> > >
>> > > [...]
>> > >
>> > > > Are there any errors when setting the triggers?
>> > > >
>> > > Is there any debug option in this service to give more verbose
>> > > output?
>> >
>> > Add:
>> > Environment="G_MESSAGES_DEBUG=all"
>> >
>> > To the service file. You should see the debug in systemctl:
>> > systemctl status iio-sensor-proxy.service
>> >
>> > Or in journalctl if there's too much data:
>> > journalctl --reverse -u iio-sensor-proxy.service
>>
>> Still no joy on the sensors. The proxy starts up and detects the
>> sensors, but I don't see any sensor events occurring:
>
> Could you try again with the current master of iio-sensor-proxy? Make
> sure to install the file in the same location as in your distro
> provided package.
>
> I've added more debug/warnings to a few cases where it would have
> silently failed in the past.
>
> In particular, I don't see any messages that would be coming out of:
> https://github.com/hadess/iio-sensor-proxy/blob/master/src/iio-buffer-utils.c#L512
>
> Could it be that the sub-directory is populated after the device is
> created in the kernel, causing a race?
>
> Either that, or the contents of the scan_elements/ directory is not the
> one expected by this code.
>
> The output of this command should us that:
> ls 
> /sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1/scan_elements

Hmmm, this is interesting. I fetched, built and ran the latest
iio-sensor-proxy. It quit with the following error. However,
immediately afterwards, I ran the Debian packaged version (1.1-1), and
the sensors started to work. Something in the latest master activates
the sensors enough for the older version to work.

To make sure it wasn't fixed by a kernel upgrade, I also rebooted and
tried again:
1) Booted system - iio-sensor-proxy.service running  --- No rotation sensing
2) # systemctl stop iio-sensor-proxy-service   --- Turn off the agent
3) # G_MESSAGES_DEBUG=all /usr/bin/iio-sensor-proxy.orig 
original version, still not working
4) # G_MESSAGES_DEBUG=all /usr/bin/iio-sensor-proxy.new 
latest master, failed with error messages
5) # G_MESSAGES_DEBUG=all /usr/bin/iio-sensor-proxy.orig 
original version, suddenly working

All of this was tested on Linus' latest master branch (4.7-rc3+)

Output from latest git master:

root@gladys:~# G_MESSAGES_DEBUG=all /usr/sbin/iio-sensor-proxy
** (process:9214): DEBUG: Found accel_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
** (process:9214): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
of type accelerometer at IIO Buffer accelerometer
** (process:9214): DEBUG: Found magn_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
** (process:9214): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
of type compass at IIO Buffer Compass
** (process:9214): DEBUG: Found associated trigger at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/trigger1

** (process:9214): WARNING **: Failed to enable any sensors for device
'/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1'

** (process:9214): WARNING **: Failed to enable any sensors for device
'/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1'
** (process:9214): DEBUG: Found associated trigger at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/trigger6

** (process:9214): WARNING **: Failed to enable any sensors for device
'/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6'

** (process:9214): WARNING **: Failed to enable any sensors for device
'/sys/devices/pci:00

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Tue, Jun 14, 2016 at 4:12 PM, Bastien Nocera  wrote:
> On Tue, 2016-06-14 at 14:44 +0100, Grant Likely wrote:
>> On Fri, Jun 10, 2016 at 4:27 PM, Bastien Nocera 
>> wrote:
>> > On Fri, 2016-06-10 at 08:23 -0700, Srinivas Pandruvada wrote:
>> > > On Fri, 2016-06-10 at 17:04 +0200, Bastien Nocera wrote:
>> > > > >
>> > >
>> > > [...]
>> > >
>> > > > Are there any errors when setting the triggers?
>> > > >
>> > > Is there any debug option in this service to give more verbose
>> > > output?
>> >
>> > Add:
>> > Environment="G_MESSAGES_DEBUG=all"
>> >
>> > To the service file. You should see the debug in systemctl:
>> > systemctl status iio-sensor-proxy.service
>> >
>> > Or in journalctl if there's too much data:
>> > journalctl --reverse -u iio-sensor-proxy.service
>>
>> Still no joy on the sensors. The proxy starts up and detects the
>> sensors, but I don't see any sensor events occurring:
>
> Could you try again with the current master of iio-sensor-proxy? Make
> sure to install the file in the same location as in your distro
> provided package.
>
> I've added more debug/warnings to a few cases where it would have
> silently failed in the past.
>
> In particular, I don't see any messages that would be coming out of:
> https://github.com/hadess/iio-sensor-proxy/blob/master/src/iio-buffer-utils.c#L512
>
> Could it be that the sub-directory is populated after the device is
> created in the kernel, causing a race?
>
> Either that, or the contents of the scan_elements/ directory is not the
> one expected by this code.
>
> The output of this command should us that:
> ls 
> /sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1/scan_elements

Hmmm, this is interesting. I fetched, built and ran the latest
iio-sensor-proxy. It quit with the following error. However,
immediately afterwards, I ran the Debian packaged version (1.1-1), and
the sensors started to work. Something in the latest master activates
the sensors enough for the older version to work.

To make sure it wasn't fixed by a kernel upgrade, I also rebooted and
tried again:
1) Booted system - iio-sensor-proxy.service running  --- No rotation sensing
2) # systemctl stop iio-sensor-proxy-service   --- Turn off the agent
3) # G_MESSAGES_DEBUG=all /usr/bin/iio-sensor-proxy.orig 
original version, still not working
4) # G_MESSAGES_DEBUG=all /usr/bin/iio-sensor-proxy.new 
latest master, failed with error messages
5) # G_MESSAGES_DEBUG=all /usr/bin/iio-sensor-proxy.orig 
original version, suddenly working

All of this was tested on Linus' latest master branch (4.7-rc3+)

Output from latest git master:

root@gladys:~# G_MESSAGES_DEBUG=all /usr/sbin/iio-sensor-proxy
** (process:9214): DEBUG: Found accel_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
** (process:9214): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
of type accelerometer at IIO Buffer accelerometer
** (process:9214): DEBUG: Found magn_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
** (process:9214): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
of type compass at IIO Buffer Compass
** (process:9214): DEBUG: Found associated trigger at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/trigger1

** (process:9214): WARNING **: Failed to enable any sensors for device
'/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1'

** (process:9214): WARNING **: Failed to enable any sensors for device
'/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1'
** (process:9214): DEBUG: Found associated trigger at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/trigger6

** (process:9214): WARNING **: Failed to enable any sensors for device
'/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6'

** (process:9214): WARNING **: Failed to enable any sensors for device
'/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Fri, Jun 10, 2016 at 4:27 PM, Bastien Nocera  wrote:
> On Fri, 2016-06-10 at 08:23 -0700, Srinivas Pandruvada wrote:
>> On Fri, 2016-06-10 at 17:04 +0200, Bastien Nocera wrote:
>> > >
>>
>> [...]
>>
>> > Are there any errors when setting the triggers?
>> >
>> Is there any debug option in this service to give more verbose
>> output?
>
> Add:
> Environment="G_MESSAGES_DEBUG=all"
>
> To the service file. You should see the debug in systemctl:
> systemctl status iio-sensor-proxy.service
>
> Or in journalctl if there's too much data:
> journalctl --reverse -u iio-sensor-proxy.service

Still no joy on the sensors. The proxy starts up and detects the
sensors, but I don't see any sensor events occurring:

root@gladys:~# G_MESSAGES_DEBUG=all /usr/sbin/iio-sensor-proxy
** (process:2802): DEBUG: Found accel_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
** (process:2802): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
of type accelerometer at IIO Buffer accelerometer
** (process:2802): DEBUG: Found magn_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
** (process:2802): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
of type compass at IIO Buffer Compass
** (process:2802): DEBUG: Found associated trigger at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/trigger1
** (process:2802): DEBUG: Got type for in_accel_x: is signed: 1,
bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Got type for in_accel_y: is signed: 1,
bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Got type for in_accel_z: is signed: 1,
bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_accel_x: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_accel_y: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_accel_z: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Found associated trigger at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/trigger6
** (process:2802): DEBUG: Got type for in_magn_x: is signed: 1, bytes:
4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Got type for in_magn_y: is signed: 1, bytes:
4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Got type for in_magn_z: is signed: 1, bytes:
4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Got type for
in_rot_from_north_magnetic_tilt_comp: is signed: 1, bytes: 4,
bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_magn_x: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_magn_y: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_magn_z: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for
in_rot_from_north_magnetic_tilt_comp: is signed: 1, bytes: 4,
bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Handling driver refcounting method
'ClaimLight' for ambient light sensor device
** (process:2802): DEBUG: Handling driver refcounting method
'ClaimAccelerometer' for accelerometer device
** (process:2802): DEBUG: Handling driver refcounting method
'ClaimAccelerometer' for accelerometer device
** (process:2802): DEBUG: No new data available
** (process:2802): DEBUG: No new data available
^C
root@gladys:~# G_MESSAGES_DEBUG=all /usr/sbin/iio-sensor-proxy
** (process:3568): DEBUG: Found accel_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
** (process:3568): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
of type accelerometer at IIO Buffer accelerometer
** (process:3568): DEBUG: Found magn_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
** (process:3568): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
of type compass at IIO Buffer Compass
** (process:3568): 

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Fri, Jun 10, 2016 at 4:27 PM, Bastien Nocera  wrote:
> On Fri, 2016-06-10 at 08:23 -0700, Srinivas Pandruvada wrote:
>> On Fri, 2016-06-10 at 17:04 +0200, Bastien Nocera wrote:
>> > >
>>
>> [...]
>>
>> > Are there any errors when setting the triggers?
>> >
>> Is there any debug option in this service to give more verbose
>> output?
>
> Add:
> Environment="G_MESSAGES_DEBUG=all"
>
> To the service file. You should see the debug in systemctl:
> systemctl status iio-sensor-proxy.service
>
> Or in journalctl if there's too much data:
> journalctl --reverse -u iio-sensor-proxy.service

Still no joy on the sensors. The proxy starts up and detects the
sensors, but I don't see any sensor events occurring:

root@gladys:~# G_MESSAGES_DEBUG=all /usr/sbin/iio-sensor-proxy
** (process:2802): DEBUG: Found accel_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
** (process:2802): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
of type accelerometer at IIO Buffer accelerometer
** (process:2802): DEBUG: Found magn_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
** (process:2802): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
of type compass at IIO Buffer Compass
** (process:2802): DEBUG: Found associated trigger at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/trigger1
** (process:2802): DEBUG: Got type for in_accel_x: is signed: 1,
bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Got type for in_accel_y: is signed: 1,
bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Got type for in_accel_z: is signed: 1,
bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_accel_x: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_accel_y: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_accel_z: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Found associated trigger at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/trigger6
** (process:2802): DEBUG: Got type for in_magn_x: is signed: 1, bytes:
4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Got type for in_magn_y: is signed: 1, bytes:
4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Got type for in_magn_z: is signed: 1, bytes:
4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Got type for
in_rot_from_north_magnetic_tilt_comp: is signed: 1, bytes: 4,
bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_magn_x: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_magn_y: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for in_magn_z: is
signed: 1, bytes: 4, bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Built channel array for
in_rot_from_north_magnetic_tilt_comp: is signed: 1, bytes: 4,
bits_used: 32, shift: 0, mask: 0x0, be: 0
** (process:2802): DEBUG: Handling driver refcounting method
'ClaimLight' for ambient light sensor device
** (process:2802): DEBUG: Handling driver refcounting method
'ClaimAccelerometer' for accelerometer device
** (process:2802): DEBUG: Handling driver refcounting method
'ClaimAccelerometer' for accelerometer device
** (process:2802): DEBUG: No new data available
** (process:2802): DEBUG: No new data available
^C
root@gladys:~# G_MESSAGES_DEBUG=all /usr/sbin/iio-sensor-proxy
** (process:3568): DEBUG: Found accel_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
** (process:3568): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0001/HID-SENSOR-200073.8.auto/iio:device1
of type accelerometer at IIO Buffer accelerometer
** (process:3568): DEBUG: Found magn_3d at
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
** (process:3568): DEBUG: Found device
/sys/devices/pci:00/:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001E:8086:22D8.0003/HID-SENSOR-200083.27.auto/iio:device6
of type compass at IIO Buffer Compass
** (process:3568): DEBUG: Found 

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Fri, Jun 10, 2016 at 10:44 AM, Grant Likely
<grant.lik...@secretlab.ca> wrote:
> On Thu, Jun 9, 2016 at 10:54 PM, Srinivas Pandruvada
> <srinivas.pandruv...@linux.intel.com> wrote:
>> Hi,
>> On Thu, 2016-06-09 at 22:45 +0100, Grant Likely wrote:
>>> On Tue, May 31, 2016 at 5:27 AM, Srinivas Pandruvada
>>> <srinivas.pandruv...@linux.intel.com> wrote:
>>> >
>>> > Starting from Cherrytrail, multiple generation of Intel processors
>>> > offers
>>> > on package sensor hub. Several recent tablets, 2-in-1 convertible
>>> > laptops
>>> > are using ISH instead of external sensor hubs. This resulted in
>>> > lack of
>>> > support of sensor function like device rotation and auto backlight
>>> > adjustment. In addition, depending on the OEM implementation,
>>> > support of ISH
>>> > is required to support low power sleep states.
>>> >
>>> > The support of ISH on Linux platforms is not new. Android platforms
>>> > with
>>> > Intel SoCs had this support for a while submitted by Daniel Drubin.
>>> > This patcheset is reusing most of those changes with  clean up and
>>> > removing Android platform specific changes.
>>> Hi Srinivas,
>>>
>>> Thanks for this patch series. I've got an HP Spectre x360 G2
>>> (skylake), and I've built a 4.6.0 kernel with this driver patched in.
>>> It detects the sensors hub, and creates IIO devices under
>>> /sys/bus/iio/devices:
>>>
>>> $ ls /sys/bus/iio/devices/
>>> iio:device0  iio:device1  iio:device2  iio:device3  iio:device4
>>> iio:device5  iio:device6  iio:device7  iio:device8  iio:device9
>>> trigger0  trigger1  trigger2  trigger3  trigger4  trigger5  trigger6
>>> trigger7  trigger8  trigger9
>>>
>>> However, I haven't figured out how to test it yet. (This is the first
>>> time I'm working with IIO). Do you have any test code or test
>>> procedures to show if it is working?
>>>
>> If you use Fedora 23 (or any distro with iio-sensor-proxy with gnome
>> rotation stuff), you should be able to do screen rotation and
>> brightness using ALS.
>> Each of these folders should have some raw sysfs files
>> in_xxx_raw_xx
>>
>> You should be able to use "cat" on them.
>
> Yes, I do see the in_*_raw_* files in sysfs, and I'm able to get data
> out of them. Gnome also seems to recognize that the accelerometers are
> there because it adds a rotation lock button to the system menu.
>
> However, the events are getting through yet. It may be that I'm
> missing something in my kernel config. I'm rebuilding the kernel with
> Debian's config for the 4.5.5 kernel as a quick sanity test. I'll
> report back when I've tried.

Still no joy here on getting wired up to Gnome. The sensors exist, and
I can view the output. For example, the following shell command will
give a live view of the accelerometer settings:

while true; clear; do { for f in iio\:device*/in_accel*raw; do echo $f
`cat $f`; done }; sleep 0.25s; done

In "Laptop mode":
iio:device1/in_accel_x_raw 2184
iio:device1/in_accel_y_raw -968620
iio:device1/in_accel_z_raw -224273
iio:device3/in_accel_x_raw 5784
iio:device3/in_accel_y_raw -946324
iio:device3/in_accel_z_raw -218647

When rotated clockwise 90 degrees:
iio:device1/in_accel_x_raw 1013843
iio:device1/in_accel_y_raw 8523
iio:device1/in_accel_z_raw -12259
iio:device3/in_accel_x_raw 1012352
iio:device3/in_accel_y_raw 14487
iio:device3/in_accel_z_raw -6891

When lying flat:
iio:device1/in_accel_x_raw 6995
iio:device1/in_accel_y_raw -32824
iio:device1/in_accel_z_raw -986080
iio:device3/in_accel_x_raw 5797
iio:device3/in_accel_y_raw -31402
iio:device3/in_accel_z_raw -984732

However, Gnome isn't picking up the rotation events. I don't know
where in the stack things are falling down. I do have iio-sensor-proxy
running. Any hints on debugging this?

Yet, some stuff is working now. The keyboard (but not the trackpad)
gets disabled when folded back in tablet mode.

g.

>
> I'll also take some time and review the patch series later this afternoon.
>
> g.
>
>>
>> Thanks,
>> Srinivas
>>
>>
>>> Thanks,
>>> g.
>>>
>>> >
>>> >
>>> > This series is tested on:
>>> > - Lenovo Yoga 260 with Skylake processor
>>> > - HP Pavilion x2 detachable with Cherrytrail
>>> >
>>> > The user mode ABI is still same as external sensor hubs using Linux
>>> > IIO. So existing user mode software should still work without
>>> > change.
>>>

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Fri, Jun 10, 2016 at 10:44 AM, Grant Likely
 wrote:
> On Thu, Jun 9, 2016 at 10:54 PM, Srinivas Pandruvada
>  wrote:
>> Hi,
>> On Thu, 2016-06-09 at 22:45 +0100, Grant Likely wrote:
>>> On Tue, May 31, 2016 at 5:27 AM, Srinivas Pandruvada
>>>  wrote:
>>> >
>>> > Starting from Cherrytrail, multiple generation of Intel processors
>>> > offers
>>> > on package sensor hub. Several recent tablets, 2-in-1 convertible
>>> > laptops
>>> > are using ISH instead of external sensor hubs. This resulted in
>>> > lack of
>>> > support of sensor function like device rotation and auto backlight
>>> > adjustment. In addition, depending on the OEM implementation,
>>> > support of ISH
>>> > is required to support low power sleep states.
>>> >
>>> > The support of ISH on Linux platforms is not new. Android platforms
>>> > with
>>> > Intel SoCs had this support for a while submitted by Daniel Drubin.
>>> > This patcheset is reusing most of those changes with  clean up and
>>> > removing Android platform specific changes.
>>> Hi Srinivas,
>>>
>>> Thanks for this patch series. I've got an HP Spectre x360 G2
>>> (skylake), and I've built a 4.6.0 kernel with this driver patched in.
>>> It detects the sensors hub, and creates IIO devices under
>>> /sys/bus/iio/devices:
>>>
>>> $ ls /sys/bus/iio/devices/
>>> iio:device0  iio:device1  iio:device2  iio:device3  iio:device4
>>> iio:device5  iio:device6  iio:device7  iio:device8  iio:device9
>>> trigger0  trigger1  trigger2  trigger3  trigger4  trigger5  trigger6
>>> trigger7  trigger8  trigger9
>>>
>>> However, I haven't figured out how to test it yet. (This is the first
>>> time I'm working with IIO). Do you have any test code or test
>>> procedures to show if it is working?
>>>
>> If you use Fedora 23 (or any distro with iio-sensor-proxy with gnome
>> rotation stuff), you should be able to do screen rotation and
>> brightness using ALS.
>> Each of these folders should have some raw sysfs files
>> in_xxx_raw_xx
>>
>> You should be able to use "cat" on them.
>
> Yes, I do see the in_*_raw_* files in sysfs, and I'm able to get data
> out of them. Gnome also seems to recognize that the accelerometers are
> there because it adds a rotation lock button to the system menu.
>
> However, the events are getting through yet. It may be that I'm
> missing something in my kernel config. I'm rebuilding the kernel with
> Debian's config for the 4.5.5 kernel as a quick sanity test. I'll
> report back when I've tried.

Still no joy here on getting wired up to Gnome. The sensors exist, and
I can view the output. For example, the following shell command will
give a live view of the accelerometer settings:

while true; clear; do { for f in iio\:device*/in_accel*raw; do echo $f
`cat $f`; done }; sleep 0.25s; done

In "Laptop mode":
iio:device1/in_accel_x_raw 2184
iio:device1/in_accel_y_raw -968620
iio:device1/in_accel_z_raw -224273
iio:device3/in_accel_x_raw 5784
iio:device3/in_accel_y_raw -946324
iio:device3/in_accel_z_raw -218647

When rotated clockwise 90 degrees:
iio:device1/in_accel_x_raw 1013843
iio:device1/in_accel_y_raw 8523
iio:device1/in_accel_z_raw -12259
iio:device3/in_accel_x_raw 1012352
iio:device3/in_accel_y_raw 14487
iio:device3/in_accel_z_raw -6891

When lying flat:
iio:device1/in_accel_x_raw 6995
iio:device1/in_accel_y_raw -32824
iio:device1/in_accel_z_raw -986080
iio:device3/in_accel_x_raw 5797
iio:device3/in_accel_y_raw -31402
iio:device3/in_accel_z_raw -984732

However, Gnome isn't picking up the rotation events. I don't know
where in the stack things are falling down. I do have iio-sensor-proxy
running. Any hints on debugging this?

Yet, some stuff is working now. The keyboard (but not the trackpad)
gets disabled when folded back in tablet mode.

g.

>
> I'll also take some time and review the patch series later this afternoon.
>
> g.
>
>>
>> Thanks,
>> Srinivas
>>
>>
>>> Thanks,
>>> g.
>>>
>>> >
>>> >
>>> > This series is tested on:
>>> > - Lenovo Yoga 260 with Skylake processor
>>> > - HP Pavilion x2 detachable with Cherrytrail
>>> >
>>> > The user mode ABI is still same as external sensor hubs using Linux
>>> > IIO. So existing user mode software should still work without
>>> > change.
>>> > This series primarily brings in new HID transport used in ISH.
>>> >
>>> > This series submitted as 

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Thu, Jun 9, 2016 at 10:54 PM, Srinivas Pandruvada
<srinivas.pandruv...@linux.intel.com> wrote:
> Hi,
> On Thu, 2016-06-09 at 22:45 +0100, Grant Likely wrote:
>> On Tue, May 31, 2016 at 5:27 AM, Srinivas Pandruvada
>> <srinivas.pandruv...@linux.intel.com> wrote:
>> >
>> > Starting from Cherrytrail, multiple generation of Intel processors
>> > offers
>> > on package sensor hub. Several recent tablets, 2-in-1 convertible
>> > laptops
>> > are using ISH instead of external sensor hubs. This resulted in
>> > lack of
>> > support of sensor function like device rotation and auto backlight
>> > adjustment. In addition, depending on the OEM implementation,
>> > support of ISH
>> > is required to support low power sleep states.
>> >
>> > The support of ISH on Linux platforms is not new. Android platforms
>> > with
>> > Intel SoCs had this support for a while submitted by Daniel Drubin.
>> > This patcheset is reusing most of those changes with  clean up and
>> > removing Android platform specific changes.
>> Hi Srinivas,
>>
>> Thanks for this patch series. I've got an HP Spectre x360 G2
>> (skylake), and I've built a 4.6.0 kernel with this driver patched in.
>> It detects the sensors hub, and creates IIO devices under
>> /sys/bus/iio/devices:
>>
>> $ ls /sys/bus/iio/devices/
>> iio:device0  iio:device1  iio:device2  iio:device3  iio:device4
>> iio:device5  iio:device6  iio:device7  iio:device8  iio:device9
>> trigger0  trigger1  trigger2  trigger3  trigger4  trigger5  trigger6
>> trigger7  trigger8  trigger9
>>
>> However, I haven't figured out how to test it yet. (This is the first
>> time I'm working with IIO). Do you have any test code or test
>> procedures to show if it is working?
>>
> If you use Fedora 23 (or any distro with iio-sensor-proxy with gnome
> rotation stuff), you should be able to do screen rotation and
> brightness using ALS.
> Each of these folders should have some raw sysfs files
> in_xxx_raw_xx
>
> You should be able to use "cat" on them.

Yes, I do see the in_*_raw_* files in sysfs, and I'm able to get data
out of them. Gnome also seems to recognize that the accelerometers are
there because it adds a rotation lock button to the system menu.

However, the events are getting through yet. It may be that I'm
missing something in my kernel config. I'm rebuilding the kernel with
Debian's config for the 4.5.5 kernel as a quick sanity test. I'll
report back when I've tried.

I'll also take some time and review the patch series later this afternoon.

g.

>
> Thanks,
> Srinivas
>
>
>> Thanks,
>> g.
>>
>> >
>> >
>> > This series is tested on:
>> > - Lenovo Yoga 260 with Skylake processor
>> > - HP Pavilion x2 detachable with Cherrytrail
>> >
>> > The user mode ABI is still same as external sensor hubs using Linux
>> > IIO. So existing user mode software should still work without
>> > change.
>> > This series primarily brings in new HID transport used in ISH.
>> >
>> > This series submitted as a RFC to try on several devices. We have
>> > received request from Linux users who wanted this support. So I
>> > hope all
>> > those users try and give feedback.
>> >
>> > Daniel Drubin (3):
>> >   hid: intel_ish-hid: ISH Transport layer
>> >   hid: intel-ish-hid: ipc layer
>> >   hid: intel-ish-hid: ISH HID client driver
>> >
>> > Srinivas Pandruvada (1):
>> >   Documentation: hid: Intel ISH HID document
>> >
>> >  Documentation/hid/intel-ish-hid.txt  |  375 +
>> >  drivers/hid/Kconfig  |2 +
>> >  drivers/hid/Makefile |2 +
>> >  drivers/hid/intel-ish-hid/Kconfig|   27 +
>> >  drivers/hid/intel-ish-hid/Makefile   |   20 +
>> >  drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h  |  220 +
>> >  drivers/hid/intel-ish-hid/ipc/hw-ish.h   |   71 ++
>> >  drivers/hid/intel-ish-hid/ipc/ipc.c  |  710
>> > 
>> >  drivers/hid/intel-ish-hid/ipc/pci-ish.c  |  238 ++
>> >  drivers/hid/intel-ish-hid/ipc/utils.h|   65 ++
>> >  drivers/hid/intel-ish-hid/ishtp-hid-client.c |  672
>> > +++
>> >  drivers/hid/intel-ish-hid/ishtp-hid.c|  201 +
>> >  drivers/hid/intel-ish-hid/ishtp-hid.h|  157 
>> >  drivers/hid/intel-ish-hid/ishtp/bus.c|  670
>> > ++

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Thu, Jun 9, 2016 at 10:54 PM, Srinivas Pandruvada
 wrote:
> Hi,
> On Thu, 2016-06-09 at 22:45 +0100, Grant Likely wrote:
>> On Tue, May 31, 2016 at 5:27 AM, Srinivas Pandruvada
>>  wrote:
>> >
>> > Starting from Cherrytrail, multiple generation of Intel processors
>> > offers
>> > on package sensor hub. Several recent tablets, 2-in-1 convertible
>> > laptops
>> > are using ISH instead of external sensor hubs. This resulted in
>> > lack of
>> > support of sensor function like device rotation and auto backlight
>> > adjustment. In addition, depending on the OEM implementation,
>> > support of ISH
>> > is required to support low power sleep states.
>> >
>> > The support of ISH on Linux platforms is not new. Android platforms
>> > with
>> > Intel SoCs had this support for a while submitted by Daniel Drubin.
>> > This patcheset is reusing most of those changes with  clean up and
>> > removing Android platform specific changes.
>> Hi Srinivas,
>>
>> Thanks for this patch series. I've got an HP Spectre x360 G2
>> (skylake), and I've built a 4.6.0 kernel with this driver patched in.
>> It detects the sensors hub, and creates IIO devices under
>> /sys/bus/iio/devices:
>>
>> $ ls /sys/bus/iio/devices/
>> iio:device0  iio:device1  iio:device2  iio:device3  iio:device4
>> iio:device5  iio:device6  iio:device7  iio:device8  iio:device9
>> trigger0  trigger1  trigger2  trigger3  trigger4  trigger5  trigger6
>> trigger7  trigger8  trigger9
>>
>> However, I haven't figured out how to test it yet. (This is the first
>> time I'm working with IIO). Do you have any test code or test
>> procedures to show if it is working?
>>
> If you use Fedora 23 (or any distro with iio-sensor-proxy with gnome
> rotation stuff), you should be able to do screen rotation and
> brightness using ALS.
> Each of these folders should have some raw sysfs files
> in_xxx_raw_xx
>
> You should be able to use "cat" on them.

Yes, I do see the in_*_raw_* files in sysfs, and I'm able to get data
out of them. Gnome also seems to recognize that the accelerometers are
there because it adds a rotation lock button to the system menu.

However, the events are getting through yet. It may be that I'm
missing something in my kernel config. I'm rebuilding the kernel with
Debian's config for the 4.5.5 kernel as a quick sanity test. I'll
report back when I've tried.

I'll also take some time and review the patch series later this afternoon.

g.

>
> Thanks,
> Srinivas
>
>
>> Thanks,
>> g.
>>
>> >
>> >
>> > This series is tested on:
>> > - Lenovo Yoga 260 with Skylake processor
>> > - HP Pavilion x2 detachable with Cherrytrail
>> >
>> > The user mode ABI is still same as external sensor hubs using Linux
>> > IIO. So existing user mode software should still work without
>> > change.
>> > This series primarily brings in new HID transport used in ISH.
>> >
>> > This series submitted as a RFC to try on several devices. We have
>> > received request from Linux users who wanted this support. So I
>> > hope all
>> > those users try and give feedback.
>> >
>> > Daniel Drubin (3):
>> >   hid: intel_ish-hid: ISH Transport layer
>> >   hid: intel-ish-hid: ipc layer
>> >   hid: intel-ish-hid: ISH HID client driver
>> >
>> > Srinivas Pandruvada (1):
>> >   Documentation: hid: Intel ISH HID document
>> >
>> >  Documentation/hid/intel-ish-hid.txt  |  375 +
>> >  drivers/hid/Kconfig  |2 +
>> >  drivers/hid/Makefile |2 +
>> >  drivers/hid/intel-ish-hid/Kconfig|   27 +
>> >  drivers/hid/intel-ish-hid/Makefile   |   20 +
>> >  drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h  |  220 +
>> >  drivers/hid/intel-ish-hid/ipc/hw-ish.h   |   71 ++
>> >  drivers/hid/intel-ish-hid/ipc/ipc.c  |  710
>> > 
>> >  drivers/hid/intel-ish-hid/ipc/pci-ish.c  |  238 ++
>> >  drivers/hid/intel-ish-hid/ipc/utils.h|   65 ++
>> >  drivers/hid/intel-ish-hid/ishtp-hid-client.c |  672
>> > +++
>> >  drivers/hid/intel-ish-hid/ishtp-hid.c|  201 +
>> >  drivers/hid/intel-ish-hid/ishtp-hid.h|  157 
>> >  drivers/hid/intel-ish-hid/ishtp/bus.c|  670
>> > +++
>> >  drivers/hid/intel-ish-hid/ishtp/bus.h|   99 +++
>

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Tue, May 31, 2016 at 5:27 AM, Srinivas Pandruvada
 wrote:
> Starting from Cherrytrail, multiple generation of Intel processors offers
> on package sensor hub. Several recent tablets, 2-in-1 convertible laptops
> are using ISH instead of external sensor hubs. This resulted in lack of
> support of sensor function like device rotation and auto backlight
> adjustment. In addition, depending on the OEM implementation, support of ISH
> is required to support low power sleep states.
>
> The support of ISH on Linux platforms is not new. Android platforms with
> Intel SoCs had this support for a while submitted by Daniel Drubin.
> This patcheset is reusing most of those changes with  clean up and
> removing Android platform specific changes.

Hi Srinivas,

Thanks for this patch series. I've got an HP Spectre x360 G2
(skylake), and I've built a 4.6.0 kernel with this driver patched in.
It detects the sensors hub, and creates IIO devices under
/sys/bus/iio/devices:

$ ls /sys/bus/iio/devices/
iio:device0  iio:device1  iio:device2  iio:device3  iio:device4
iio:device5  iio:device6  iio:device7  iio:device8  iio:device9
trigger0  trigger1  trigger2  trigger3  trigger4  trigger5  trigger6
trigger7  trigger8  trigger9

However, I haven't figured out how to test it yet. (This is the first
time I'm working with IIO). Do you have any test code or test
procedures to show if it is working?

Thanks,
g.

>
> This series is tested on:
> - Lenovo Yoga 260 with Skylake processor
> - HP Pavilion x2 detachable with Cherrytrail
>
> The user mode ABI is still same as external sensor hubs using Linux
> IIO. So existing user mode software should still work without change.
> This series primarily brings in new HID transport used in ISH.
>
> This series submitted as a RFC to try on several devices. We have
> received request from Linux users who wanted this support. So I hope all
> those users try and give feedback.
>
> Daniel Drubin (3):
>   hid: intel_ish-hid: ISH Transport layer
>   hid: intel-ish-hid: ipc layer
>   hid: intel-ish-hid: ISH HID client driver
>
> Srinivas Pandruvada (1):
>   Documentation: hid: Intel ISH HID document
>
>  Documentation/hid/intel-ish-hid.txt  |  375 +
>  drivers/hid/Kconfig  |2 +
>  drivers/hid/Makefile |2 +
>  drivers/hid/intel-ish-hid/Kconfig|   27 +
>  drivers/hid/intel-ish-hid/Makefile   |   20 +
>  drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h  |  220 +
>  drivers/hid/intel-ish-hid/ipc/hw-ish.h   |   71 ++
>  drivers/hid/intel-ish-hid/ipc/ipc.c  |  710 
>  drivers/hid/intel-ish-hid/ipc/pci-ish.c  |  238 ++
>  drivers/hid/intel-ish-hid/ipc/utils.h|   65 ++
>  drivers/hid/intel-ish-hid/ishtp-hid-client.c |  672 +++
>  drivers/hid/intel-ish-hid/ishtp-hid.c|  201 +
>  drivers/hid/intel-ish-hid/ishtp-hid.h|  157 
>  drivers/hid/intel-ish-hid/ishtp/bus.c|  670 +++
>  drivers/hid/intel-ish-hid/ishtp/bus.h|   99 +++
>  drivers/hid/intel-ish-hid/ishtp/client.c | 1131 
> ++
>  drivers/hid/intel-ish-hid/ishtp/client.h |  196 +
>  drivers/hid/intel-ish-hid/ishtp/dma-if.c |  175 
>  drivers/hid/intel-ish-hid/ishtp/hbm.c|  911 +
>  drivers/hid/intel-ish-hid/ishtp/hbm.h|  319 
>  drivers/hid/intel-ish-hid/ishtp/init.c   |   94 +++
>  drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h  |  276 +++
>  include/trace/events/intel_ish.h |   30 +
>  23 files changed, 6661 insertions(+)
>  create mode 100644 Documentation/hid/intel-ish-hid.txt
>  create mode 100644 drivers/hid/intel-ish-hid/Kconfig
>  create mode 100644 drivers/hid/intel-ish-hid/Makefile
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/dma-if.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/init.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
>  create mode 100644 include/trace/events/intel_ish.h
>
> --
> 1.9.1
>

Re: [RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Grant Likely]

On Tue, May 31, 2016 at 5:27 AM, Srinivas Pandruvada
 wrote:
> Starting from Cherrytrail, multiple generation of Intel processors offers
> on package sensor hub. Several recent tablets, 2-in-1 convertible laptops
> are using ISH instead of external sensor hubs. This resulted in lack of
> support of sensor function like device rotation and auto backlight
> adjustment. In addition, depending on the OEM implementation, support of ISH
> is required to support low power sleep states.
>
> The support of ISH on Linux platforms is not new. Android platforms with
> Intel SoCs had this support for a while submitted by Daniel Drubin.
> This patcheset is reusing most of those changes with  clean up and
> removing Android platform specific changes.

Hi Srinivas,

Thanks for this patch series. I've got an HP Spectre x360 G2
(skylake), and I've built a 4.6.0 kernel with this driver patched in.
It detects the sensors hub, and creates IIO devices under
/sys/bus/iio/devices:

$ ls /sys/bus/iio/devices/
iio:device0  iio:device1  iio:device2  iio:device3  iio:device4
iio:device5  iio:device6  iio:device7  iio:device8  iio:device9
trigger0  trigger1  trigger2  trigger3  trigger4  trigger5  trigger6
trigger7  trigger8  trigger9

However, I haven't figured out how to test it yet. (This is the first
time I'm working with IIO). Do you have any test code or test
procedures to show if it is working?

Thanks,
g.

>
> This series is tested on:
> - Lenovo Yoga 260 with Skylake processor
> - HP Pavilion x2 detachable with Cherrytrail
>
> The user mode ABI is still same as external sensor hubs using Linux
> IIO. So existing user mode software should still work without change.
> This series primarily brings in new HID transport used in ISH.
>
> This series submitted as a RFC to try on several devices. We have
> received request from Linux users who wanted this support. So I hope all
> those users try and give feedback.
>
> Daniel Drubin (3):
>   hid: intel_ish-hid: ISH Transport layer
>   hid: intel-ish-hid: ipc layer
>   hid: intel-ish-hid: ISH HID client driver
>
> Srinivas Pandruvada (1):
>   Documentation: hid: Intel ISH HID document
>
>  Documentation/hid/intel-ish-hid.txt  |  375 +
>  drivers/hid/Kconfig  |2 +
>  drivers/hid/Makefile |2 +
>  drivers/hid/intel-ish-hid/Kconfig|   27 +
>  drivers/hid/intel-ish-hid/Makefile   |   20 +
>  drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h  |  220 +
>  drivers/hid/intel-ish-hid/ipc/hw-ish.h   |   71 ++
>  drivers/hid/intel-ish-hid/ipc/ipc.c  |  710 
>  drivers/hid/intel-ish-hid/ipc/pci-ish.c  |  238 ++
>  drivers/hid/intel-ish-hid/ipc/utils.h|   65 ++
>  drivers/hid/intel-ish-hid/ishtp-hid-client.c |  672 +++
>  drivers/hid/intel-ish-hid/ishtp-hid.c|  201 +
>  drivers/hid/intel-ish-hid/ishtp-hid.h|  157 
>  drivers/hid/intel-ish-hid/ishtp/bus.c|  670 +++
>  drivers/hid/intel-ish-hid/ishtp/bus.h|   99 +++
>  drivers/hid/intel-ish-hid/ishtp/client.c | 1131 
> ++
>  drivers/hid/intel-ish-hid/ishtp/client.h |  196 +
>  drivers/hid/intel-ish-hid/ishtp/dma-if.c |  175 
>  drivers/hid/intel-ish-hid/ishtp/hbm.c|  911 +
>  drivers/hid/intel-ish-hid/ishtp/hbm.h|  319 
>  drivers/hid/intel-ish-hid/ishtp/init.c   |   94 +++
>  drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h  |  276 +++
>  include/trace/events/intel_ish.h |   30 +
>  23 files changed, 6661 insertions(+)
>  create mode 100644 Documentation/hid/intel-ish-hid.txt
>  create mode 100644 drivers/hid/intel-ish-hid/Kconfig
>  create mode 100644 drivers/hid/intel-ish-hid/Makefile
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
>  create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/dma-if.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.h
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/init.c
>  create mode 100644 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
>  create mode 100644 include/trace/events/intel_ish.h
>
> --
> 1.9.1
>

Re: Kernel docs: muddying the waters a bit

[Grant Likely]

On Tue, Apr 12, 2016 at 4:46 PM, Jonathan Corbet  wrote:
> On Fri, 8 Apr 2016 17:12:27 +0200
> Markus Heiser  wrote:
>
>> motivated by this MT, I implemented a toolchain to migrate the kernel’s
>> DocBook XML documentation to reST markup.
>>
>> It converts 99% of the docs well ... to gain an impression how
>> kernel-docs could benefit from, visit my sphkerneldoc project page
>> on github:
>>
>>   http://return42.github.io/sphkerneldoc/
>
> So I've obviously been pretty quiet on this recently.  Apologies...I've
> been dealing with an extended death-in-the-family experience, and there is
> still a fair amount of cleanup to be done.
>
> Looking quickly at this work, it seems similar to the results I got.  But
> there's a lot of code there that came from somewhere?  I'd put together a
> fairly simple conversion using pandoc and a couple of short sed scripts;
> is there a reason for a more complex solution?
>
> Thanks for looking into this, anyway; I hope to be able to focus more on
> it shortly.

Hi Jon,

Thanks for digging into this. FWIW, here is my $0.02. I've been
working on restarting the devicetree specification, and after looking
at both reStructuredText and Asciidoc(tor) I thought I liked the
Asciidoc markup better, so chose that. I then proceeded to spend weeks
trying to get reasonable output from the toolchain. When I got fed up
and gave Sphinx a try, I was up and running with reasonable PDF and
HTML output in a day and a half.

Honestly, in the end I think we could make either tool do what is
needed of it. However, my impression after trying to do a document
that needs to have nice publishable output with both tools is that
Sphinx is easier to work with, simpler to extend, better supported. My
vote is firmly behind Sphinx/reStructuredText.

g.

Re: Kernel docs: muddying the waters a bit

[Grant Likely]

On Tue, Apr 12, 2016 at 4:46 PM, Jonathan Corbet  wrote:
> On Fri, 8 Apr 2016 17:12:27 +0200
> Markus Heiser  wrote:
>
>> motivated by this MT, I implemented a toolchain to migrate the kernel’s
>> DocBook XML documentation to reST markup.
>>
>> It converts 99% of the docs well ... to gain an impression how
>> kernel-docs could benefit from, visit my sphkerneldoc project page
>> on github:
>>
>>   http://return42.github.io/sphkerneldoc/
>
> So I've obviously been pretty quiet on this recently.  Apologies...I've
> been dealing with an extended death-in-the-family experience, and there is
> still a fair amount of cleanup to be done.
>
> Looking quickly at this work, it seems similar to the results I got.  But
> there's a lot of code there that came from somewhere?  I'd put together a
> fairly simple conversion using pandoc and a couple of short sed scripts;
> is there a reason for a more complex solution?
>
> Thanks for looking into this, anyway; I hope to be able to focus more on
> it shortly.

Hi Jon,

Thanks for digging into this. FWIW, here is my $0.02. I've been
working on restarting the devicetree specification, and after looking
at both reStructuredText and Asciidoc(tor) I thought I liked the
Asciidoc markup better, so chose that. I then proceeded to spend weeks
trying to get reasonable output from the toolchain. When I got fed up
and gave Sphinx a try, I was up and running with reasonable PDF and
HTML output in a day and a half.

Honestly, in the end I think we could make either tool do what is
needed of it. However, my impression after trying to do a document
that needs to have nice publishable output with both tools is that
Sphinx is easier to work with, simpler to extend, better supported. My
vote is firmly behind Sphinx/reStructuredText.

g.

New TAB chair announcement

[Grant Likely]

I'm pleased to announce that at last weeks Technical Advisory Board
meeting, the TAB elected Chris Mason as the chair* and re-elected Jon
Corbet as vice-chair.

Chris & Jon, congratulations to you. I'm honoured to be able to work
with you both, and I know you will do an excellent job.

g.

*Chris is taking over from me. I served as chair for 1.5 years.
Earlier this year I decided not to stand for re-election due to
overcommitment in several areas. However, I am remaining as a regular
TAB representative.

New TAB chair announcement

[Grant Likely]

I'm pleased to announce that at last weeks Technical Advisory Board
meeting, the TAB elected Chris Mason as the chair* and re-elected Jon
Corbet as vice-chair.

Chris & Jon, congratulations to you. I'm honoured to be able to work
with you both, and I know you will do an excellent job.

g.

*Chris is taking over from me. I served as chair for 1.5 years.
Earlier this year I decided not to stand for re-election due to
overcommitment in several areas. However, I am remaining as a regular
TAB representative.

Re: Linux Plumbers 2016 Call for Organizers

[Grant Likely]

Hi all,

On behalf of the TAB, I'm happy to announce the planning committee for
the Linux Plumbers conference on the week of October 31st to November
4th in Santa Fe, New Mexico, USA.

Jes Sorensen - Chair
James Bottomley - Treasurer
Paul McKenney - Program Committee Chair
Guy Lunardi - Events Coordinator
David Woodhouse
Theodore Ts'o - TAB representative
Kate Stewart
Jake Edge
Jon Corbet - TAB representative

Planning for the event has begun, and the team will start sending out
updates in the near future. Keep an eye on the Linux Plumbers
Conference web site for more information.

http://linuxplumbersconf.org/

Congratulations to the whole team.

g.

On Sat, Sep 5, 2015 at 12:35 AM, Grant Likely  wrote:
> Each year, the Linux Foundation's Technical Advisory Board (TAB) seeks
> an organizing committee for the annual Linux Plumbers Conference; that
> process has now begun for the 2016 event.  This is your chance to put
> your stamp on one of our community's most important gatherings in a
> year when we will be celebrating 25 years of the Linux kernel.
>
> In a change from recent years, the Linux Plumbers Conference will not
> be colocated with a LinuxCon event; instead, it will be held alongside
> the annual Kernel Summit in Santa Fe, New Mexico, USA. The timing of
> the event is expected to be the week of October 31st to November 4th,
> and we have selected a suitable venue.
>
> Interested groups should have, at a minimum, an events coordinator, a
> treasurer, a program committee chair and a chairperson.  This group
> must be able to take the initiative to handle conference-specific
> details (including social events, the miniconf program, and more)
> while working with the Linux Foundation to ensure that logistics work
> smoothly.
>
> The process for putting in an application to run the Linux Plumbers
> Conference is documented here:
>
>https://wiki.linuxfoundation.org/en/LPC
>
> Applications should be in by October 5th; the TAB then will announce a
> decision by (at the latest) October 26th.
>
> If you're interested in submitting a proposal, but are concerned that
> you don't know enough about how previous Plumbers has been run, then
> fear not! The TAB will support the selected organizing committee with
> additional volunteers with past Plumbers organizing experience. Above
> all we are looking for a capable and enthusiastic group who we can
> work with to make the 2016 Linux Plumbers Conference a great success.
>
> If you have any questions about the submission process, please email
> the TAB at tech-bo...@lists.linux-foundation.org.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Plumbers 2016 Call for Organizers

[Grant Likely]

Hi all,

On behalf of the TAB, I'm happy to announce the planning committee for
the Linux Plumbers conference on the week of October 31st to November
4th in Santa Fe, New Mexico, USA.

Jes Sorensen - Chair
James Bottomley - Treasurer
Paul McKenney - Program Committee Chair
Guy Lunardi - Events Coordinator
David Woodhouse
Theodore Ts'o - TAB representative
Kate Stewart
Jake Edge
Jon Corbet - TAB representative

Planning for the event has begun, and the team will start sending out
updates in the near future. Keep an eye on the Linux Plumbers
Conference web site for more information.

http://linuxplumbersconf.org/

Congratulations to the whole team.

g.

On Sat, Sep 5, 2015 at 12:35 AM, Grant Likely <grant.lik...@secretlab.ca> wrote:
> Each year, the Linux Foundation's Technical Advisory Board (TAB) seeks
> an organizing committee for the annual Linux Plumbers Conference; that
> process has now begun for the 2016 event.  This is your chance to put
> your stamp on one of our community's most important gatherings in a
> year when we will be celebrating 25 years of the Linux kernel.
>
> In a change from recent years, the Linux Plumbers Conference will not
> be colocated with a LinuxCon event; instead, it will be held alongside
> the annual Kernel Summit in Santa Fe, New Mexico, USA. The timing of
> the event is expected to be the week of October 31st to November 4th,
> and we have selected a suitable venue.
>
> Interested groups should have, at a minimum, an events coordinator, a
> treasurer, a program committee chair and a chairperson.  This group
> must be able to take the initiative to handle conference-specific
> details (including social events, the miniconf program, and more)
> while working with the Linux Foundation to ensure that logistics work
> smoothly.
>
> The process for putting in an application to run the Linux Plumbers
> Conference is documented here:
>
>https://wiki.linuxfoundation.org/en/LPC
>
> Applications should be in by October 5th; the TAB then will announce a
> decision by (at the latest) October 26th.
>
> If you're interested in submitting a proposal, but are concerned that
> you don't know enough about how previous Plumbers has been run, then
> fear not! The TAB will support the selected organizing committee with
> additional volunteers with past Plumbers organizing experience. Above
> all we are looking for a capable and enthusiastic group who we can
> work with to make the 2016 Linux Plumbers Conference a great success.
>
> If you have any questions about the submission process, please email
> the TAB at tech-bo...@lists.linux-foundation.org.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

On Sun, Oct 25, 2015 at 5:06 PM, Grant Likely  wrote:
> Final reminder and update:
>
> The TAB elections will be held at 6:00pm tomorrow evening, Monday
> October 26th during the evening booth-crawl and reception in the Park
> Studio room. We will start at 6:00 sharp. Don't be late.
>
> Agenda:
> 1) Welcome and brief summary of what the TAB does
> 2) Questions
> 3) Last call for nominations
> 4) Candidate statements. Candidates will each have 1 minute to make a
> brief statement. Candidates who are unable to attend can provide a
> written statement to be read out.
> 5) Review of polling procedure
> 6) Polling
>
> The doors to the room will be closed at the start of polling. You must
> be in the room by that time if you intend to cast a ballot. Polling
> will be conducted by secret paper ballot and a privacy shield will be
> provided. Voters must exit the room after casting their ballot.
>
> Counting shall be performed by 2 or 3 neutral people after polling has
> completed. Results will be provided by email to the mailing lists
> later that same evening.
>
> Currently we have 15 candidates for 5 seats. The current nominations
> are (in alphabetical order):
> Kees Cook
> Jon Corbet
> Thomas Gleixner
> Stephen Hemminger
> Olof Johansson
> Shuah Khan
> Greg Kroah-Hartman
> Kurt H Maier
> Steven Rostedt
> Dave Taht
> Josh Triplett
> Theodore Ts'o
> Sage Weil
> Dan Williams
> Rafael Wysocki

and Andy Lutomirski makes 16.

That's it. Any nominations received after this point will not make it
onto the pre-printed ballot. (Nominations are still open. There are
blank spaces on the ballot for writing in other names)

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

Final reminder and update:

The TAB elections will be held at 6:00pm tomorrow evening, Monday
October 26th during the evening booth-crawl and reception in the Park
Studio room. We will start at 6:00 sharp. Don't be late.

Agenda:
1) Welcome and brief summary of what the TAB does
2) Questions
3) Last call for nominations
4) Candidate statements. Candidates will each have 1 minute to make a
brief statement. Candidates who are unable to attend can provide a
written statement to be read out.
5) Review of polling procedure
6) Polling

The doors to the room will be closed at the start of polling. You must
be in the room by that time if you intend to cast a ballot. Polling
will be conducted by secret paper ballot and a privacy shield will be
provided. Voters must exit the room after casting their ballot.

Counting shall be performed by 2 or 3 neutral people after polling has
completed. Results will be provided by email to the mailing lists
later that same evening.

Currently we have 15 candidates for 5 seats. The current nominations
are (in alphabetical order):
Kees Cook
Jon Corbet
Thomas Gleixner
Stephen Hemminger
Olof Johansson
Shuah Khan
Greg Kroah-Hartman
Kurt H Maier
Steven Rostedt
Dave Taht
Josh Triplett
Theodore Ts'o
Sage Weil
Dan Williams
Rafael Wysocki

On Tue, Oct 20, 2015 at 9:54 AM, Grant Likely  wrote:
> Reminder and update:
>
> As described below, the TAB elections will be held next week with the
> Linux Kernel Summit and the Korea Linux Forum. The election will be
> held at 6:00pm Monday evening during the on-site evening reception.
> Each candidate will have the opportunity to make a brief statement
> before polling. Candidates who are not able to attend personally may
> provide a written statement to be read out.
>
> We now have 12 nominees for five seats.
> Kees Cook
> Jon Corbet*
> Thomas Gleixner*
> Stephen Hemminger
> Shuah Khan
> Greg Kroah-Hartman*
> Kurt H Maier
> Steven Rostedt
> Dave Taht
> Josh Triplett
> Sage Weil
> Rafael Wysocki
> (*Incumbent)
>
> The deadline for nominations remains the evening of the election.
> However, we will be pre-printing ballots on Sunday evening with the
> nominations received up to that point. There will be blank spaces
> provided on the ballot for writing in late nominations.
>
> g.
>
> On Tue, Oct 6, 2015 at 11:06 AM, Grant Likely  wrote:
>> The elections for five of the ten members of the Linux Foundation
>> Technical Advisory Board (TAB) are held every year[1]. This year the
>> election will be at the 2015 Kernel Summit in Seoul, South Korea
>> (probably on the Monday, 26 October) and will be open to all attendees
>> of both Kernel Summit and Korea Linux Forum.
>>
>> Anyone is eligible to stand for election, simply send your nomination to:
>>
>> tech-board-disc...@lists.linux-foundation.org
>>
>> We currently have 3 nominees for five places:
>> Thomas Gleixner
>> Greg Kroah-Hartman
>> Stephen Hemminger
>>
>> The deadline for receiving nominations is up until the beginning of
>> the event where the election is held. Although, please remember if
>> you're not going to be present that things go wrong with both networks
>> and mailing lists, so get your nomination in early).
>>
>> Grant Likely, TAB Chair
>>
>> [1] TAB members sit for a term of 2 years, and half of the board is up
>> for election every year. Five of the seats are up for election now.
>> The other five are half way through their term and will be up for
>> election next year. The history of the TAB elections can be found
>> here:
>>
>> https://docs.google.com/spreadsheets/d/1jGLQtul0taSRq_opYzJFALI7_34cS4RMS1_YQoTNCKA/edit#gid=0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Tech-board] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

On Sun, Oct 25, 2015 at 12:45 PM, Jonathan Corbet  wrote:
> On Sat, 24 Oct 2015 11:28:19 +0100
> Grant Likely  wrote:
>
>> I've been asked several versions of the same question, and also the
>> annual "what does the TAB actually do?" question, so I'm going to try
>> and answer them all in one email:
>
> Great summary, Grant, thanks.
>
> A few additions of my own...

Oh, yes. I completely agree with the following. Thank you Jon.

>
> - The Linux Foundation tends to ask TAB members if they can give talks at
>   events.  Even more than free software development in general, TAB
>   membership can be good if you don't like buying your own T-shirts!
>
> - The TAB has been named in the kernel's "code of conflict" as the body
>   that will receive complaints about harassment or other untoward
>   behavior in our community and try to resolve them.  Thus far, no such
>   complaints have been presented, but TAB members need to be prepared for
>   that to happen.
>
> - It has been my feeling for a fair while that the LF could make more use
>   of the TAB and its expertise than happens currently.  Good TAB members
>   might be those who are willing to let the LF know when they have an
>   opinion on what the LF should be doing with and for the community.  As
>   an example, some of us have been pushing for the TAB to help with the
>   selection of technical talks at LF conferences; I *think* that we
>   provided useful input for LCE this year.
>
> That ties in to my last thought...in my time on the TAB, I've noticed
> that most of the work tends to be done by a relatively small subset of
> the members.  Perhaps every committee is like that, in the end.  A
> successful TAB member, IMO, is one who is willing to make the time to not
> just attend attend the meetings (which may be at less-than-convenient
> times depending on where you live and travel), but also to commit to
> putting some time into helping out when there's something to be done.
>
> jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Tech-board] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

On Sun, Oct 25, 2015 at 12:45 PM, Jonathan Corbet <cor...@lwn.net> wrote:
> On Sat, 24 Oct 2015 11:28:19 +0100
> Grant Likely <glik...@secretlab.ca> wrote:
>
>> I've been asked several versions of the same question, and also the
>> annual "what does the TAB actually do?" question, so I'm going to try
>> and answer them all in one email:
>
> Great summary, Grant, thanks.
>
> A few additions of my own...

Oh, yes. I completely agree with the following. Thank you Jon.

>
> - The Linux Foundation tends to ask TAB members if they can give talks at
>   events.  Even more than free software development in general, TAB
>   membership can be good if you don't like buying your own T-shirts!
>
> - The TAB has been named in the kernel's "code of conflict" as the body
>   that will receive complaints about harassment or other untoward
>   behavior in our community and try to resolve them.  Thus far, no such
>   complaints have been presented, but TAB members need to be prepared for
>   that to happen.
>
> - It has been my feeling for a fair while that the LF could make more use
>   of the TAB and its expertise than happens currently.  Good TAB members
>   might be those who are willing to let the LF know when they have an
>   opinion on what the LF should be doing with and for the community.  As
>   an example, some of us have been pushing for the TAB to help with the
>   selection of technical talks at LF conferences; I *think* that we
>   provided useful input for LCE this year.
>
> That ties in to my last thought...in my time on the TAB, I've noticed
> that most of the work tends to be done by a relatively small subset of
> the members.  Perhaps every committee is like that, in the end.  A
> successful TAB member, IMO, is one who is willing to make the time to not
> just attend attend the meetings (which may be at less-than-convenient
> times depending on where you live and travel), but also to commit to
> putting some time into helping out when there's something to be done.
>
> jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

On Sun, Oct 25, 2015 at 5:06 PM, Grant Likely <glik...@secretlab.ca> wrote:
> Final reminder and update:
>
> The TAB elections will be held at 6:00pm tomorrow evening, Monday
> October 26th during the evening booth-crawl and reception in the Park
> Studio room. We will start at 6:00 sharp. Don't be late.
>
> Agenda:
> 1) Welcome and brief summary of what the TAB does
> 2) Questions
> 3) Last call for nominations
> 4) Candidate statements. Candidates will each have 1 minute to make a
> brief statement. Candidates who are unable to attend can provide a
> written statement to be read out.
> 5) Review of polling procedure
> 6) Polling
>
> The doors to the room will be closed at the start of polling. You must
> be in the room by that time if you intend to cast a ballot. Polling
> will be conducted by secret paper ballot and a privacy shield will be
> provided. Voters must exit the room after casting their ballot.
>
> Counting shall be performed by 2 or 3 neutral people after polling has
> completed. Results will be provided by email to the mailing lists
> later that same evening.
>
> Currently we have 15 candidates for 5 seats. The current nominations
> are (in alphabetical order):
> Kees Cook
> Jon Corbet
> Thomas Gleixner
> Stephen Hemminger
> Olof Johansson
> Shuah Khan
> Greg Kroah-Hartman
> Kurt H Maier
> Steven Rostedt
> Dave Taht
> Josh Triplett
> Theodore Ts'o
> Sage Weil
> Dan Williams
> Rafael Wysocki

and Andy Lutomirski makes 16.

That's it. Any nominations received after this point will not make it
onto the pre-printed ballot. (Nominations are still open. There are
blank spaces on the ballot for writing in other names)

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

Final reminder and update:

The TAB elections will be held at 6:00pm tomorrow evening, Monday
October 26th during the evening booth-crawl and reception in the Park
Studio room. We will start at 6:00 sharp. Don't be late.

Agenda:
1) Welcome and brief summary of what the TAB does
2) Questions
3) Last call for nominations
4) Candidate statements. Candidates will each have 1 minute to make a
brief statement. Candidates who are unable to attend can provide a
written statement to be read out.
5) Review of polling procedure
6) Polling

The doors to the room will be closed at the start of polling. You must
be in the room by that time if you intend to cast a ballot. Polling
will be conducted by secret paper ballot and a privacy shield will be
provided. Voters must exit the room after casting their ballot.

Counting shall be performed by 2 or 3 neutral people after polling has
completed. Results will be provided by email to the mailing lists
later that same evening.

Currently we have 15 candidates for 5 seats. The current nominations
are (in alphabetical order):
Kees Cook
Jon Corbet
Thomas Gleixner
Stephen Hemminger
Olof Johansson
Shuah Khan
Greg Kroah-Hartman
Kurt H Maier
Steven Rostedt
Dave Taht
Josh Triplett
Theodore Ts'o
Sage Weil
Dan Williams
Rafael Wysocki

On Tue, Oct 20, 2015 at 9:54 AM, Grant Likely <glik...@secretlab.ca> wrote:
> Reminder and update:
>
> As described below, the TAB elections will be held next week with the
> Linux Kernel Summit and the Korea Linux Forum. The election will be
> held at 6:00pm Monday evening during the on-site evening reception.
> Each candidate will have the opportunity to make a brief statement
> before polling. Candidates who are not able to attend personally may
> provide a written statement to be read out.
>
> We now have 12 nominees for five seats.
> Kees Cook
> Jon Corbet*
> Thomas Gleixner*
> Stephen Hemminger
> Shuah Khan
> Greg Kroah-Hartman*
> Kurt H Maier
> Steven Rostedt
> Dave Taht
> Josh Triplett
> Sage Weil
> Rafael Wysocki
> (*Incumbent)
>
> The deadline for nominations remains the evening of the election.
> However, we will be pre-printing ballots on Sunday evening with the
> nominations received up to that point. There will be blank spaces
> provided on the ballot for writing in late nominations.
>
> g.
>
> On Tue, Oct 6, 2015 at 11:06 AM, Grant Likely <glik...@secretlab.ca> wrote:
>> The elections for five of the ten members of the Linux Foundation
>> Technical Advisory Board (TAB) are held every year[1]. This year the
>> election will be at the 2015 Kernel Summit in Seoul, South Korea
>> (probably on the Monday, 26 October) and will be open to all attendees
>> of both Kernel Summit and Korea Linux Forum.
>>
>> Anyone is eligible to stand for election, simply send your nomination to:
>>
>> tech-board-disc...@lists.linux-foundation.org
>>
>> We currently have 3 nominees for five places:
>> Thomas Gleixner
>> Greg Kroah-Hartman
>> Stephen Hemminger
>>
>> The deadline for receiving nominations is up until the beginning of
>> the event where the election is held. Although, please remember if
>> you're not going to be present that things go wrong with both networks
>> and mailing lists, so get your nomination in early).
>>
>> Grant Likely, TAB Chair
>>
>> [1] TAB members sit for a term of 2 years, and half of the board is up
>> for election every year. Five of the seats are up for election now.
>> The other five are half way through their term and will be up for
>> election next year. The history of the TAB elections can be found
>> here:
>>
>> https://docs.google.com/spreadsheets/d/1jGLQtul0taSRq_opYzJFALI7_34cS4RMS1_YQoTNCKA/edit#gid=0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

[Including Rafael who also asked about what being a TAB member means]

On Thu, Oct 22, 2015 at 10:03 PM, Darren Hart  wrote:
> On Tue, Oct 06, 2015 at 11:06:47AM +0100, Grant Likely wrote:
> Is there a good description of what is expected of a TAB member? How much time
> is involved? What makes a great TAB member?
>
> I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab
>
> I've read the charter and scanned some of the minutes, but I'd still like to
> hear from some of the "incumbants". Specifically, what makes you successful 
> as a
> member of the TAB?

I've been asked several versions of the same question, and also the
annual "what does the TAB actually do?" question, so I'm going to try
and answer them all in one email:

As the name implies, the primary job of the TAB is to advise the Linux
Foundation board of directors on technical, social and political
issues regarding Linux and Open Source. Our job is to represent the
views of Linux developers and to foster constructive communication
between the Linux Foundation leadership and our community.

A natural by-product of this is that the TAB also acts in the
background to identify and resolve issues for the Linux community
before they become a problem. The TAB tends to be composed of well
respected individuals with good connections throughout our community,
and so we're in a good place to recognize who to talk to when an issue
is raised.

Finally, there are a few projects that the TAB is directly responsible
for. We make sure there is a planning committee for the Linux Plumbers
conference every year. We run a 'buddy' program to help new Linux
Foundation member companies learn how to be fine upstanding Linux
citizens. We are the response team for any issues of harassment or
abuse within the kernel community. In past years we coordinated the
response to UEFI Secure Boot to ensure that Linux would not be locked
out of the consumer PC market, and been active in helping member
companies understand and be comfortable with the licencing obligations
associated with Linux.

A good TAB member is well respected by the community, is a ready
listener, is comfortable discussing both technical and social issues,
and has a good understanding of how the Linux community works. Since
the TAB deals with a wide range of issues, the ideal TAB candidate
should be prepared to consider issues outside of their own area of
expertise. Sometime the most important characteristic of a TAB member
is recognizing when an issue is beyond their depth and go looking for
the right person to consult.

Time commitment wise, The TAB meets once a month for a conference
call, plus any additional time required to deal with TAB business.
Once a year (6 months after the TAB general election) the TAB elects
one member to serve as the chair, and the chair of the TAB is proposed
to the Linux Foundation to serve as a Linux Foundation Director which
has additional time requirements.

One last point, some issues addressed by the TAB are highly sensitive
and any member can request a topic to be kept strictly confidential.
We do this to protect the working relationship we have with industry
bodies, and to protect the companies and individuals involved. Any
prospective TAB member must be comfortable abiding by our
confidentiality rules.

I hope this answers your questions.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

[Including Rafael who also asked about what being a TAB member means]

On Thu, Oct 22, 2015 at 10:03 PM, Darren Hart <dvh...@infradead.org> wrote:
> On Tue, Oct 06, 2015 at 11:06:47AM +0100, Grant Likely wrote:
> Is there a good description of what is expected of a TAB member? How much time
> is involved? What makes a great TAB member?
>
> I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab
>
> I've read the charter and scanned some of the minutes, but I'd still like to
> hear from some of the "incumbants". Specifically, what makes you successful 
> as a
> member of the TAB?

I've been asked several versions of the same question, and also the
annual "what does the TAB actually do?" question, so I'm going to try
and answer them all in one email:

As the name implies, the primary job of the TAB is to advise the Linux
Foundation board of directors on technical, social and political
issues regarding Linux and Open Source. Our job is to represent the
views of Linux developers and to foster constructive communication
between the Linux Foundation leadership and our community.

A natural by-product of this is that the TAB also acts in the
background to identify and resolve issues for the Linux community
before they become a problem. The TAB tends to be composed of well
respected individuals with good connections throughout our community,
and so we're in a good place to recognize who to talk to when an issue
is raised.

Finally, there are a few projects that the TAB is directly responsible
for. We make sure there is a planning committee for the Linux Plumbers
conference every year. We run a 'buddy' program to help new Linux
Foundation member companies learn how to be fine upstanding Linux
citizens. We are the response team for any issues of harassment or
abuse within the kernel community. In past years we coordinated the
response to UEFI Secure Boot to ensure that Linux would not be locked
out of the consumer PC market, and been active in helping member
companies understand and be comfortable with the licencing obligations
associated with Linux.

A good TAB member is well respected by the community, is a ready
listener, is comfortable discussing both technical and social issues,
and has a good understanding of how the Linux community works. Since
the TAB deals with a wide range of issues, the ideal TAB candidate
should be prepared to consider issues outside of their own area of
expertise. Sometime the most important characteristic of a TAB member
is recognizing when an issue is beyond their depth and go looking for
the right person to consult.

Time commitment wise, The TAB meets once a month for a conference
call, plus any additional time required to deal with TAB business.
Once a year (6 months after the TAB general election) the TAB elects
one member to serve as the chair, and the chair of the TAB is proposed
to the Linux Foundation to serve as a Linux Foundation Director which
has additional time requirements.

One last point, some issues addressed by the TAB are highly sensitive
and any member can request a topic to be kept strictly confidential.
We do this to protect the working relationship we have with industry
bodies, and to protect the companies and individuals involved. Any
prospective TAB member must be comfortable abiding by our
confidentiality rules.

I hope this answers your questions.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

Reminder and update:

As described below, the TAB elections will be held next week with the
Linux Kernel Summit and the Korea Linux Forum. The election will be
held at 6:00pm Monday evening during the on-site evening reception.
Each candidate will have the opportunity to make a brief statement
before polling. Candidates who are not able to attend personally may
provide a written statement to be read out.

We now have 12 nominees for five seats.
Kees Cook
Jon Corbet*
Thomas Gleixner*
Stephen Hemminger
Shuah Khan
Greg Kroah-Hartman*
Kurt H Maier
Steven Rostedt
Dave Taht
Josh Triplett
Sage Weil
Rafael Wysocki
(*Incumbent)

The deadline for nominations remains the evening of the election.
However, we will be pre-printing ballots on Sunday evening with the
nominations received up to that point. There will be blank spaces
provided on the ballot for writing in late nominations.

g.

On Tue, Oct 6, 2015 at 11:06 AM, Grant Likely  wrote:
> The elections for five of the ten members of the Linux Foundation
> Technical Advisory Board (TAB) are held every year[1]. This year the
> election will be at the 2015 Kernel Summit in Seoul, South Korea
> (probably on the Monday, 26 October) and will be open to all attendees
> of both Kernel Summit and Korea Linux Forum.
>
> Anyone is eligible to stand for election, simply send your nomination to:
>
> tech-board-disc...@lists.linux-foundation.org
>
> We currently have 3 nominees for five places:
> Thomas Gleixner
> Greg Kroah-Hartman
> Stephen Hemminger
>
> The deadline for receiving nominations is up until the beginning of
> the event where the election is held. Although, please remember if
> you're not going to be present that things go wrong with both networks
> and mailing lists, so get your nomination in early).
>
> Grant Likely, TAB Chair
>
> [1] TAB members sit for a term of 2 years, and half of the board is up
> for election every year. Five of the seats are up for election now.
> The other five are half way through their term and will be up for
> election next year. The history of the TAB elections can be found
> here:
>
> https://docs.google.com/spreadsheets/d/1jGLQtul0taSRq_opYzJFALI7_34cS4RMS1_YQoTNCKA/edit#gid=0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

Reminder and update:

As described below, the TAB elections will be held next week with the
Linux Kernel Summit and the Korea Linux Forum. The election will be
held at 6:00pm Monday evening during the on-site evening reception.
Each candidate will have the opportunity to make a brief statement
before polling. Candidates who are not able to attend personally may
provide a written statement to be read out.

We now have 12 nominees for five seats.
Kees Cook
Jon Corbet*
Thomas Gleixner*
Stephen Hemminger
Shuah Khan
Greg Kroah-Hartman*
Kurt H Maier
Steven Rostedt
Dave Taht
Josh Triplett
Sage Weil
Rafael Wysocki
(*Incumbent)

The deadline for nominations remains the evening of the election.
However, we will be pre-printing ballots on Sunday evening with the
nominations received up to that point. There will be blank spaces
provided on the ballot for writing in late nominations.

g.

On Tue, Oct 6, 2015 at 11:06 AM, Grant Likely <glik...@secretlab.ca> wrote:
> The elections for five of the ten members of the Linux Foundation
> Technical Advisory Board (TAB) are held every year[1]. This year the
> election will be at the 2015 Kernel Summit in Seoul, South Korea
> (probably on the Monday, 26 October) and will be open to all attendees
> of both Kernel Summit and Korea Linux Forum.
>
> Anyone is eligible to stand for election, simply send your nomination to:
>
> tech-board-disc...@lists.linux-foundation.org
>
> We currently have 3 nominees for five places:
> Thomas Gleixner
> Greg Kroah-Hartman
> Stephen Hemminger
>
> The deadline for receiving nominations is up until the beginning of
> the event where the election is held. Although, please remember if
> you're not going to be present that things go wrong with both networks
> and mailing lists, so get your nomination in early).
>
> Grant Likely, TAB Chair
>
> [1] TAB members sit for a term of 2 years, and half of the board is up
> for election every year. Five of the seats are up for election now.
> The other five are half way through their term and will be up for
> election next year. The history of the TAB elections can be found
> here:
>
> https://docs.google.com/spreadsheets/d/1jGLQtul0taSRq_opYzJFALI7_34cS4RMS1_YQoTNCKA/edit#gid=0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

On Tue, Oct 13, 2015 at 2:09 PM, Sage Weil  wrote:
> On Tue, 13 Oct 2015, Grant Likely wrote:
>> On 11 Oct 2015 05:20, "Ric Wheeler"  wrote:
>> >
>> > I would like to nominate Sage Weil with his consent.
>> >
>> > Sage has lead the ceph project since its inception, contributed to the
>> kernel as well as had an influence on projects like openstack.
>>
>> Sage, what say you? Do you accept your nomination?
>
> I do!

Thanks Sage. You're on the list.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

On Tue, Oct 13, 2015 at 2:09 PM, Sage Weil <s...@newdream.net> wrote:
> On Tue, 13 Oct 2015, Grant Likely wrote:
>> On 11 Oct 2015 05:20, "Ric Wheeler" <ricwhee...@gmail.com> wrote:
>> >
>> > I would like to nominate Sage Weil with his consent.
>> >
>> > Sage has lead the ceph project since its inception, contributed to the
>> kernel as well as had an influence on projects like openstack.
>>
>> Sage, what say you? Do you accept your nomination?
>
> I do!

Thanks Sage. You're on the list.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

[Resending because I messed up the first one]

The elections for five of the ten members of the Linux Foundation
Technical Advisory Board (TAB) are held every year[1]. This year the
election will be at the 2015 Kernel Summit in Seoul, South Korea
(probably on the Monday, 26 October) and will be open to all attendees
of both Kernel Summit and Korea Linux Forum.

Anyone is eligible to stand for election, simply send your nomination to:

tech-board-disc...@lists.linux-foundation.org

We currently have 3 nominees for five places:
Thomas Gleixner
Greg Kroah-Hartman
Stephen Hemminger

The deadline for receiving nominations is up until the beginning of
the event where the election is held. Although, please remember if
you're not going to be present that things go wrong with both networks
and mailing lists, so get your nomination in early).

Grant Likely, TAB Chair

[1] TAB members sit for a term of 2 years, and half of the board is up
for election every year. Five of the seats are up for election now.
The other five are half way through their term and will be up for
election next year. The history of the TAB elections can be found
here:

https://docs.google.com/spreadsheets/d/1jGLQtul0taSRq_opYzJFALI7_34cS4RMS1_YQoTNCKA/edit#gid=0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

[Resending because I messed up the first one]

The elections for five of the ten members of the Linux Foundation
Technical Advisory Board (TAB) are held every year[1]. This year the
election will be at the 2015 Kernel Summit in Seoul, South Korea
(probably on the Monday, 26 October) and will be open to all attendees
of both Kernel Summit and Korea Linux Forum.

Anyone is eligible to stand for election, simply send your nomination to:

tech-board-disc...@lists.linux-foundation.org

We currently have 3 nominees for five places:
Thomas Gleixner
Greg Kroah-Hartman
Stephen Hemminger

The deadline for receiving nominations is up until the beginning of
the event where the election is held. Although, please remember if
you're not going to be present that things go wrong with both networks
and mailing lists, so get your nomination in early).

Grant Likely, TAB Chair

[1] TAB members sit for a term of 2 years, and half of the board is up
for election every year. Five of the seats are up for election now.
The other five are half way through their term and will be up for
election next year. The history of the TAB elections can be found
here:

https://docs.google.com/spreadsheets/d/1jGLQtul0taSRq_opYzJFALI7_34cS4RMS1_YQoTNCKA/edit#gid=0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fwd: Draft: Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

The elections for five of the ten members of the Linux Foundation
Technical Advisory Board[TAB] are held every year[1]. This year the
election will be at the 2015 Kernel Summit in Seoul, South Korea
(probably on the Monday, 26 October) and will be open to all attendees
of both Kernel Summit and Korea Linux Forum.

Anyone is eligible to stand for election, simply send your nomination to:

tech-board-disc...@lists.linux-foundation.org

We currently have 2 nominees for five places:
Thomas Gleixner
Greg Kroah-Hartman

The deadline for receiving nominations is up until the beginning of
the event where the election is held. Although, please remember if
you're not going to be present that things go wrong with both networks
and mailing lists, so get your nomination in early).

Grant Likely, TAB Chair

[1] TAB members sit for a term of 2 years, and half of the board is up
for election every year. Five of the seats are up for election now.
The other five are half way through their term and will be up for
election next year. The history of the TAB elections can be found
here:

https://docs.google.com/spreadsheets/d/1jGLQtul0taSRq_opYzJFALI7_34cS4RMS1_YQoTNCKA/edit#gid=0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fwd: Draft: Linux Foundation Technical Advisory Board Elections and Nomination process

[Grant Likely]

The elections for five of the ten members of the Linux Foundation
Technical Advisory Board[TAB] are held every year[1]. This year the
election will be at the 2015 Kernel Summit in Seoul, South Korea
(probably on the Monday, 26 October) and will be open to all attendees
of both Kernel Summit and Korea Linux Forum.

Anyone is eligible to stand for election, simply send your nomination to:

tech-board-disc...@lists.linux-foundation.org

We currently have 2 nominees for five places:
Thomas Gleixner
Greg Kroah-Hartman

The deadline for receiving nominations is up until the beginning of
the event where the election is held. Although, please remember if
you're not going to be present that things go wrong with both networks
and mailing lists, so get your nomination in early).

Grant Likely, TAB Chair

[1] TAB members sit for a term of 2 years, and half of the board is up
for election every year. Five of the seats are up for election now.
The other five are half way through their term and will be up for
election next year. The history of the TAB elections can be found
here:

https://docs.google.com/spreadsheets/d/1jGLQtul0taSRq_opYzJFALI7_34cS4RMS1_YQoTNCKA/edit#gid=0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux Plumbers 2016 Call for Organizers

[Grant Likely]

Each year, the Linux Foundation's Technical Advisory Board (TAB) seeks
an organizing committee for the annual Linux Plumbers Conference; that
process has now begun for the 2016 event.  This is your chance to put
your stamp on one of our community's most important gatherings in a
year when we will be celebrating 25 years of the Linux kernel.

In a change from recent years, the Linux Plumbers Conference will not
be colocated with a LinuxCon event; instead, it will be held alongside
the annual Kernel Summit in Santa Fe, New Mexico, USA. The timing of
the event is expected to be the week of October 31st to November 4th,
and we have selected a suitable venue.

Interested groups should have, at a minimum, an events coordinator, a
treasurer, a program committee chair and a chairperson.  This group
must be able to take the initiative to handle conference-specific
details (including social events, the miniconf program, and more)
while working with the Linux Foundation to ensure that logistics work
smoothly.

The process for putting in an application to run the Linux Plumbers
Conference is documented here:

   https://wiki.linuxfoundation.org/en/LPC

Applications should be in by October 5th; the TAB then will announce a
decision by (at the latest) October 26th.

If you're interested in submitting a proposal, but are concerned that
you don't know enough about how previous Plumbers has been run, then
fear not! The TAB will support the selected organizing committee with
additional volunteers with past Plumbers organizing experience. Above
all we are looking for a capable and enthusiastic group who we can
work with to make the 2016 Linux Plumbers Conference a great success.

If you have any questions about the submission process, please email
the TAB at tech-bo...@lists.linux-foundation.org.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux Plumbers 2016 Call for Organizers

[Grant Likely]

Each year, the Linux Foundation's Technical Advisory Board (TAB) seeks
an organizing committee for the annual Linux Plumbers Conference; that
process has now begun for the 2016 event.  This is your chance to put
your stamp on one of our community's most important gatherings in a
year when we will be celebrating 25 years of the Linux kernel.

In a change from recent years, the Linux Plumbers Conference will not
be colocated with a LinuxCon event; instead, it will be held alongside
the annual Kernel Summit in Santa Fe, New Mexico, USA. The timing of
the event is expected to be the week of October 31st to November 4th,
and we have selected a suitable venue.

Interested groups should have, at a minimum, an events coordinator, a
treasurer, a program committee chair and a chairperson.  This group
must be able to take the initiative to handle conference-specific
details (including social events, the miniconf program, and more)
while working with the Linux Foundation to ensure that logistics work
smoothly.

The process for putting in an application to run the Linux Plumbers
Conference is documented here:

   https://wiki.linuxfoundation.org/en/LPC

Applications should be in by October 5th; the TAB then will announce a
decision by (at the latest) October 26th.

If you're interested in submitting a proposal, but are concerned that
you don't know enough about how previous Plumbers has been run, then
fear not! The TAB will support the selected organizing committee with
additional volunteers with past Plumbers organizing experience. Above
all we are looking for a capable and enthusiastic group who we can
work with to make the 2016 Linux Plumbers Conference a great success.

If you have any questions about the submission process, please email
the TAB at tech-bo...@lists.linux-foundation.org.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] MAINTAINERS: Add Frank Rowand as DT maintainer

[Grant Likely]

Frank has agreed to step up and help with DT core code maintainership.
At the same time, Grant is taking a step back from active maintainership
responsibilities. Add Frank to the device tree core code entry and
shuffle Grant to the end of the list. In a few releases time Grant will
be removed entirely.

Signed-off-by: Grant Likely 
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 993d4cfd5aa0..c032364bf5d4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7482,8 +7482,9 @@ F:Documentation/i2c/busses/i2c-ocores
 F: drivers/i2c/busses/i2c-ocores.c
 
 OPEN FIRMWARE AND FLATTENED DEVICE TREE
-M: Grant Likely 
 M: Rob Herring 
+M: Frank Rowand 
+M: Grant Likely 
 L: devicet...@vger.kernel.org
 W: http://www.devicetree.org/
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git
-- 
2.1.4

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