Re: [PATCH net-next] net: dsa: lantiq_gswip: Add support for dumping the registers

[Hauke Mehrtens]

On 4/13/21 12:24 AM, Martin Blumenstingl wrote:

Hi Andrew,

On Mon, Apr 12, 2021 at 1:16 AM Andrew Lunn  wrote:


On Sun, Apr 11, 2021 at 10:55:11PM +0200, Martin Blumenstingl wrote:

Add support for .get_regs_len and .get_regs so it is easier to find out
about the state of the ports on the GSWIP hardware. For this we
specifically add the GSWIP_MAC_PSTATp(port) and GSWIP_MDIO_STATp(port)
register #defines as these contain the current port status (as well as
the result of the auto polling mechanism). Other global and per-port
registers which are also considered useful are included as well.


Although this is O.K, there has been a trend towards using devlink
regions for this, and other register sets in the switch. Take a look
at drivers/net/dsa/mv88e6xxx/devlink.c.

There is a userspace tool for the mv88e6xxx devlink regions here:

https://github.com/lunn/mv88e6xxx_dump

and a few people have forked it and modified it for other DSA
switches. At some point we might want to try to merge the forks back
together so we have one tool to dump any switch.

actually I was wondering if there is some way to make the registers
"easier to read" in userspace.
It turns out there is :-)

Hauke, which approach do you recommend?:
- update this patch with your suggestion and ask Andrew to still merge
it soon-ish
- put this topic somewhere on my or your TODO-list and come up with a
devlink solution at some point in the future


Would you work on the devlink solution in the next weeks?
I think this is part of the ABI when we add it, can we later remove the 
ethtool registers when we add devlink support or is this not allowed?


Hauke

Re: [PATCH net-next] net: dsa: lantiq_gswip: Add support for dumping the registers

[Hauke Mehrtens]

On 4/11/21 10:55 PM, Martin Blumenstingl wrote:

Add support for .get_regs_len and .get_regs so it is easier to find out
about the state of the ports on the GSWIP hardware. For this we
specifically add the GSWIP_MAC_PSTATp(port) and GSWIP_MDIO_STATp(port)
register #defines as these contain the current port status (as well as
the result of the auto polling mechanism). Other global and per-port
registers which are also considered useful are included as well.

Acked-by: Hauke Mehrtens 
Signed-off-by: Martin Blumenstingl 
---
  drivers/net/dsa/lantiq_gswip.c | 83 ++
  1 file changed, 83 insertions(+)

diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 314ae78bbdd6..d3cfc72644ff 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -90,6 +90,21 @@
 GSWIP_MDIO_PHY_LINK_MASK | \
 GSWIP_MDIO_PHY_SPEED_MASK | \
 GSWIP_MDIO_PHY_FDUP_MASK)
+#define GSWIP_MDIO_STATp(p)(0x16 + (p))
+#define  GSWIP_MDIO_STAT_RXACT BIT(10)
+#define  GSWIP_MDIO_STAT_TXACT BIT(9)
+#define  GSWIP_MDIO_STAT_CLK_STOP_CAPABBIT(8)
+#define  GSWIP_MDIO_STAT_EEE_CAPABLE   BIT(7)
+#define  GSWIP_MDIO_STAT_PACT  BIT(6)
+#define  GSWIP_MDIO_STAT_LSTAT BIT(5)
+#define  GSWIP_MDIO_STAT_SPEED_M10 0x00
+#define  GSWIP_MDIO_STAT_SPEED_M1000x08
+#define  GSWIP_MDIO_STAT_SPEED_1G  0x10
+#define  GSWIP_MDIO_STAT_SPEED_RESERVED0x18
+#define  GSWIP_MDIO_STAT_SPEED_MASK0x18
+#define  GSWIP_MDIO_STAT_FDUP  BIT(2)
+#define  GSWIP_MDIO_STAT_RXPAUEN   BIT(1)
+#define  GSWIP_MDIO_STAT_TXPAUEN   BIT(0)
  
  /* GSWIP MII Registers */

  #define GSWIP_MII_CFGp(p) (0x2 * (p))
@@ -195,6 +210,19 @@
  #define GSWIP_PCE_DEFPVID(p)  (0x486 + ((p) * 0xA))
  
  #define GSWIP_MAC_FLEN			0x8C5

+#define GSWIP_MAC_PSTATp(p)(0x900 + ((p) * 0xC))
+#define  GSWIP_MAC_PSTAT_PACT  BIT(11)
+#define  GSWIP_MAC_PSTAT_GBIT  BIT(10)
+#define  GSWIP_MAC_PSTAT_MBIT  BIT(9)
+#define  GSWIP_MAC_PSTAT_FDUP  BIT(8)
+#define  GSWIP_MAC_PSTAT_RXPAU BIT(7)
+#define  GSWIP_MAC_PSTAT_TXPAU BIT(6)
+#define  GSWIP_MAC_PSTAT_RXPAUEN   BIT(5)
+#define  GSWIP_MAC_PSTAT_TXPAUEN   BIT(4)
+#define  GSWIP_MAC_PSTAT_LSTAT BIT(3)
+#define  GSWIP_MAC_PSTAT_CRS   BIT(2)
+#define  GSWIP_MAC_PSTAT_TXLPI BIT(1)
+#define  GSWIP_MAC_PSTAT_RXLPI BIT(0)
  #define GSWIP_MAC_CTRL_0p(p)  (0x903 + ((p) * 0xC))
  #define  GSWIP_MAC_CTRL_0_PADEN   BIT(8)
  #define  GSWIP_MAC_CTRL_0_FCS_EN  BIT(7)
@@ -701,6 +729,57 @@ static void gswip_port_disable(struct dsa_switch *ds, int 
port)
  GSWIP_SDMA_PCTRLp(port));
  }
  
+static int gswip_get_regs_len(struct dsa_switch *ds, int port)

+{
+   return 17 * sizeof(u32);
+}
+
+static void gswip_get_regs(struct dsa_switch *ds, int port,
+  struct ethtool_regs *regs, void *_p)
+{
+   struct gswip_priv *priv = ds->priv;
+   u32 *p = _p;
+
+   regs->version = gswip_switch_r(priv, GSWIP_VERSION);


This is the bump format version not the HW version, see here:
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/ethtool.h#L298

I would prefer to just return 1 here, for this format. When we add an 
extra register we would change this to 2 and so on.


These are not all registers of this switch, but for now this looks good.


+
+   memset(p, 0xff, 17 * sizeof(u32));
+
+   p[0] = gswip_mdio_r(priv, GSWIP_MDIO_GLOB);
+   p[1] = gswip_mdio_r(priv, GSWIP_MDIO_CTRL);
+   p[2] = gswip_mdio_r(priv, GSWIP_MDIO_MDC_CFG0);
+   p[3] = gswip_mdio_r(priv, GSWIP_MDIO_MDC_CFG1);
+
+   if (!dsa_is_cpu_port(priv->ds, port)) {
+   p[4] = gswip_mdio_r(priv, GSWIP_MDIO_PHYp(port));
+   p[5] = gswip_mdio_r(priv, GSWIP_MDIO_STATp(port));
+   p[6] = gswip_mii_r(priv, GSWIP_MII_CFGp(port));


Please add:
#define GSWIP_MDIO_EEEp(p)  (0x1C + (p))


+   }
+
+   switch (port) {
+   case 0:
+   p[7] = gswip_mii_r(priv, GSWIP_MII_PCDU0);
+   break;
+   case 1:
+   p[7] = gswip_mii_r(priv, GSWIP_MII_PCDU1);
+   break;
+   case 5:
+   p[7] = gswip_mii_r(priv, GSWIP_MII_PCDU5);
+   break;
+   default:
+   break;
+   }
+
+   p[8] = gswip_switch_r(priv, GSWIP_PCE_PCTRL_0p(port));
+   p[9] = gswip_switch_r(priv, GSWIP_PCE_VCTRL(port));
+   p[10] = gswip_switch_r(priv, GSWIP_PCE_DEFPVID(port));
+   p[11] = gswip_switch_r(priv, GSWIP_MAC_FLEN);
+   p[12] = gswip_switch_r(priv, GSWIP_MAC_PSTATp(port));
+   p[13] = gswip_switch_r(priv, GSWIP_MAC_CTRL_0p(port));
+   p[14] = gswip_swit

Re: [PATCH RFC net 2/2] net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits

[Hauke Mehrtens]

On 4/7/21 2:32 AM, Andrew Lunn wrote:

case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
miicfg |= GSWIP_MII_CFG_MODE_RGMII;
+
+   if (phylink_autoneg_inband(mode))
+   miicfg |= GSWIP_MII_CFG_RGMII_IBS;


Is there any other MAC driver doing this? Are there any boards
actually enabling it? Since it is so odd, if there is nothing using
it, i would be tempted to leave this out.


We saw this option in the switch documentation and activated it to 
prepare for such systems, but I do not have any board which uses this 
and I am also not aware that this is used anywhere.


Hauke

Re: [PATCH RFC net 2/2] net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits

[Hauke Mehrtens]

On 4/6/21 10:35 PM, Martin Blumenstingl wrote:

There are a few more bits in the GSWIP_MII_CFG register for which we
did rely on the boot-loader (or the hardware defaults) to set them up
properly.

For some external RMII PHYs we need to select the GSWIP_MII_CFG_RMII_CLK
bit and also we should un-set it for non-RMII PHYs.


The GSWIP_MII_CFG_RMII_CLK option is ignored in other modes.


The GSWIP IP also
supports in-band auto-negotiation for RGMII PHYs. Set or unset the
corresponding bit depending on the auto-negotiation mode.

Clear the xMII isolation bit when set at initialization time if it was
previously set by the bootloader. Not doing so could lead to no traffic
(neither RX nor TX) on a port with this bit set.

While here, also add the GSWIP_MII_CFG_RESET bit. We don't need to
manage it because this bit is self-clearning when set. We still add it
here to get a better overview of the GSWIP_MII_CFG register.

Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Cc: sta...@vger.kernel.org
Suggested-by: Hauke Mehrtens 
Acked-by: Hauke Mehrtens 
Signed-off-by: Martin Blumenstingl 
---
  drivers/net/dsa/lantiq_gswip.c | 22 +++---
  1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 47ea3a8c90a4..f330035ed85b 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -93,8 +93,12 @@
  
  /* GSWIP MII Registers */

  #define GSWIP_MII_CFGp(p) (0x2 * (p))
+#define  GSWIP_MII_CFG_RESET   BIT(15)
  #define  GSWIP_MII_CFG_EN BIT(14)
+#define  GSWIP_MII_CFG_ISOLATE BIT(13)
  #define  GSWIP_MII_CFG_LDCLKDIS   BIT(12)
+#define  GSWIP_MII_CFG_RGMII_IBS   BIT(8)
+#define  GSWIP_MII_CFG_RMII_CLKBIT(7)
  #define  GSWIP_MII_CFG_MODE_MIIP  0x0
  #define  GSWIP_MII_CFG_MODE_MIIM  0x1
  #define  GSWIP_MII_CFG_MODE_RMIIP 0x2
@@ -821,9 +825,11 @@ static int gswip_setup(struct dsa_switch *ds)
/* Configure the MDIO Clock 2.5 MHz */
gswip_mdio_mask(priv, 0xff, 0x09, GSWIP_MDIO_MDC_CFG1);
  
-	/* Disable the xMII link */

+   /* Disable the xMII interface and clear it's isolation bit */
for (i = 0; i < priv->hw_info->max_ports; i++)
-   gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, i);
+   gswip_mii_mask_cfg(priv,
+  GSWIP_MII_CFG_EN | GSWIP_MII_CFG_ISOLATE,
+  0, i);
  
  	/* enable special tag insertion on cpu port */

gswip_switch_mask(priv, 0, GSWIP_FDMA_PCTRL_STEN,
@@ -1597,19 +1603,29 @@ static void gswip_phylink_mac_config(struct dsa_switch 
*ds, int port,
break;
case PHY_INTERFACE_MODE_RMII:
miicfg |= GSWIP_MII_CFG_MODE_RMIIM;
+
+   /* Configure the RMII clock as output: */
+   miicfg |= GSWIP_MII_CFG_RMII_CLK;
break;
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
miicfg |= GSWIP_MII_CFG_MODE_RGMII;
+
+   if (phylink_autoneg_inband(mode))
+   miicfg |= GSWIP_MII_CFG_RGMII_IBS;
break;
default:
dev_err(ds->dev,
"Unsupported interface: %d\n", state->interface);
return;
}
-   gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_MODE_MASK, miicfg, port);
+
+   gswip_mii_mask_cfg(priv,
+  GSWIP_MII_CFG_MODE_MASK | GSWIP_MII_CFG_RMII_CLK |
+  GSWIP_MII_CFG_RGMII_IBS | GSWIP_MII_CFG_LDCLKDIS,
+  miicfg, port);
  
  	gswip_port_set_link(priv, port, state->link);

gswip_port_set_speed(priv, port, state->speed, state->interface);

Re: [PATCH v3 2/3] net: dsa: lantiq: verify compatible strings against hardware

[Hauke Mehrtens]

On 3/21/21 6:39 PM, Aleksander Jan Bajkowski wrote:

Verify compatible string against hardware.

Signed-off-by: Aleksander Jan Bajkowski 


Acked-by: Hauke Mehrtens 

Re: [PATCH v3 1/3] net: dsa: lantiq: allow to use all GPHYs on xRX300 and xRX330

[Hauke Mehrtens]

On 3/21/21 6:39 PM, Aleksander Jan Bajkowski wrote:

This patch allows to use all PHYs on GRX300 and GRX330. The ARX300
has 3 and the GRX330 has 4 integrated PHYs connected to different
ports compared to VRX200. Each integrated PHY can work as single
Gigabit Ethernet PHY (GMII) or as double Fast Ethernet PHY (MII).

Allowed port configurations:

xRX200:
GMAC0: RGMII, MII, REVMII or RMII port
GMAC1: RGMII, MII, REVMII or RMII port
GMAC2: GPHY0 (GMII)
GMAC3: GPHY0 (MII)
GMAC4: GPHY1 (GMII)
GMAC5: GPHY1 (MII) or RGMII port

xRX300:
GMAC0: RGMII port
GMAC1: GPHY2 (GMII)
GMAC2: GPHY0 (GMII)
GMAC3: GPHY0 (MII)
GMAC4: GPHY1 (GMII)
GMAC5: GPHY1 (MII) or RGMII port

xRX330:
GMAC0: RGMII, GMII or RMII port
GMAC1: GPHY2 (GMII)
GMAC2: GPHY0 (GMII)
GMAC3: GPHY0 (MII) or GPHY3 (GMII)
GMAC4: GPHY1 (GMII)
GMAC5: GPHY1 (MII), RGMII or RMII port

Tested on D-Link DWR966 (xRX330) with OpenWRT.

Signed-off-by: Aleksander Jan Bajkowski 


Acked-by: Hauke Mehrtens 

Re: MaxLinear, please maintain your drivers was Re: [PATCH] leds: lgm: fix gpiolib dependency

[Hauke Mehrtens]

On 3/10/21 5:57 PM, Arnd Bergmann wrote:

On Wed, Mar 10, 2021 at 8:30 AM Pavel Machek  wrote:


Hi!


I'd like people from Intel to contact me. There's more to fix there,
and AFAICT original author went away.


The following message to  was
undeliverable.



: Recipient
+address rejected: User unknown in virtual mailbox table'



commit c3987cd2bca34ddfec69027acedb2fae5ffcf7a0
Author: Amireddy Mallikarjuna reddy 


I asked around, and got told Mallikarjuna has been "sold" to MaxLinear,
together with the rest of the Connected Home Division.  So he most likely
still works on this stuff, just under a different banner.


If someone knows how to contact the author, that would be welcome.


Alas, no idea about his MaxLinear address.


Thanks for the effort. Anyway, I suspect I'll just do this:


Maybe Hauke or John  (added both to cc) know who at MaxLinear is
responsible for maintaining the Lightning Mountain drivers now.

Arnd


Hi Qiming,

It looks like there are some problems and potential fixes for the led 
driver Mallikarjuna added to the Linux kernel for LGM some time ago.


Could you please take care of this request from Pavel and Arnd.


Hauke





diff --git a/drivers/leds/blink/Kconfig b/drivers/leds/blink/Kconfig
index 6dedc58c47b3..79493f21d365 100644
--- a/drivers/leds/blink/Kconfig
+++ b/drivers/leds/blink/Kconfig
@@ -1,14 +1,6 @@
-menuconfig LEDS_BLINK
-   bool "LED Blink support"
-   depends on LEDS_CLASS
-   help
- This option enables blink support for the leds class.
- If unsure, say Y.
-
-if LEDS_BLINK
-
  config LEDS_BLINK_LGM
 tristate "LED support for Intel LGM SoC series"
+   depends on BROKEN
 depends on GPIOLIB
 depends on LEDS_CLASS
 depends on MFD_SYSCON
@@ -17,5 +9,3 @@ config LEDS_BLINK_LGM
   Parallel to serial conversion, which is also called SSO controller,
   can drive external shift register for LED outputs.
   This enables LED support for Serial Shift Output controller(SSO).
-
-endif # LEDS_BLINK


--
http://www.livejournal.com/~pavelmachek

Re: [PATCH] phy: lantiq: rcu-usb2: wait after clock enable

[Hauke Mehrtens]

On 1/7/21 11:49 PM, Mathias Kresin wrote:

Commit 65dc2e725286 ("usb: dwc2: Update Core Reset programming flow.")
revealed that the phy isn't ready immediately after enabling it's
clocks. The dwc2_check_core_version() fails and the dwc2 usb driver
errors out.

Add a short delay to let the phy get up and running. There isn't any
documentation how much time is required, the value was chosen based on
tests.

Cc:  # v5.7+
Signed-off-by: Mathias Kresin 


Acked-by: Hauke Mehrtens 

I do not know how long you have to wait here, but this looks ok, when it 
works.


Hauke


---
  drivers/phy/lantiq/phy-lantiq-rcu-usb2.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c 
b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
index a7d126192cf1..29d246ea24b4 100644
--- a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
+++ b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
@@ -124,8 +124,16 @@ static int ltq_rcu_usb2_phy_power_on(struct phy *phy)
reset_control_deassert(priv->phy_reset);
  
  	ret = clk_prepare_enable(priv->phy_gate_clk);

-   if (ret)
+   if (ret) {
dev_err(dev, "failed to enable PHY gate\n");
+   return ret;
+   }
+
+   /*
+* at least the xrx200 usb2 phy requires some extra time to be
+* operational after enabling the clock
+*/
+   usleep_range(100, 200);
  
  	return ret;

  }

Re: [PATCH 2/2] net: dsa: lantiq_gswip: Fix GSWIP_MII_CFG(p) register access

[Hauke Mehrtens]

On 1/3/21 2:25 AM, Martin Blumenstingl wrote:

There is one GSWIP_MII_CFG register for each switch-port except the CPU
port. The register offset for the first port is 0x0, 0x02 for the
second, 0x04 for the third and so on.

Update the driver to not only restrict the GSWIP_MII_CFG registers to
ports 0, 1 and 5. Handle ports 0..5 instead but skip the CPU port. This
means we are not overwriting the configuration for the third port (port
two since we start counting from zero) with the settings for the sixth
port (with number five) anymore.

The GSWIP_MII_PCDU(p) registers are not updated because there's really
only three (one for each of the following ports: 0, 1, 5).

Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Cc: sta...@vger.kernel.org
Signed-off-by: Martin Blumenstingl 


Acked-by: Hauke Mehrtens 


---
  drivers/net/dsa/lantiq_gswip.c | 23 ++-
  1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 5d378c8026f0..4b36d89bec06 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -92,9 +92,7 @@
 GSWIP_MDIO_PHY_FDUP_MASK)
  
  /* GSWIP MII Registers */

-#define GSWIP_MII_CFG0 0x00
-#define GSWIP_MII_CFG1 0x02
-#define GSWIP_MII_CFG5 0x04
+#define GSWIP_MII_CFGp(p)  (0x2 * (p))
  #define  GSWIP_MII_CFG_EN BIT(14)
  #define  GSWIP_MII_CFG_LDCLKDIS   BIT(12)
  #define  GSWIP_MII_CFG_MODE_MIIP  0x0
@@ -392,17 +390,9 @@ static void gswip_mii_mask(struct gswip_priv *priv, u32 
clear, u32 set,
  static void gswip_mii_mask_cfg(struct gswip_priv *priv, u32 clear, u32 set,
   int port)
  {
-   switch (port) {
-   case 0:
-   gswip_mii_mask(priv, clear, set, GSWIP_MII_CFG0);
-   break;
-   case 1:
-   gswip_mii_mask(priv, clear, set, GSWIP_MII_CFG1);
-   break;
-   case 5:
-   gswip_mii_mask(priv, clear, set, GSWIP_MII_CFG5);
-   break;
-   }
+   /* There's no MII_CFG register for the CPU port */
+   if (!dsa_is_cpu_port(priv->ds, port))
+   gswip_mii_mask(priv, clear, set, GSWIP_MII_CFGp(port));
  }
  
  static void gswip_mii_mask_pcdu(struct gswip_priv *priv, u32 clear, u32 set,

@@ -822,9 +812,8 @@ static int gswip_setup(struct dsa_switch *ds)
gswip_mdio_mask(priv, 0xff, 0x09, GSWIP_MDIO_MDC_CFG1);
  
  	/* Disable the xMII link */

-   gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, 0);
-   gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, 1);
-   gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, 5);
+   for (i = 0; i < priv->hw_info->max_ports; i++)
+   gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, i);
  
  	/* enable special tag insertion on cpu port */

gswip_switch_mask(priv, 0, GSWIP_FDMA_PCTRL_STEN,

Re: [PATCH 1/2] net: dsa: lantiq_gswip: Enable GSWIP_MII_CFG_EN also for internal PHYs

[Hauke Mehrtens]

On 1/3/21 2:25 AM, Martin Blumenstingl wrote:

Enable GSWIP_MII_CFG_EN also for internal PHYs to make traffic flow.
Without this the PHY link is detected properly and ethtool statistics
for TX are increasing but there's no RX traffic coming in.

Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Cc: sta...@vger.kernel.org
Suggested-by: Hauke Mehrtens 
Signed-off-by: Martin Blumenstingl 


Acked-by: Hauke Mehrtens 


---
  drivers/net/dsa/lantiq_gswip.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 09701c17f3f6..5d378c8026f0 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -1541,9 +1541,7 @@ static void gswip_phylink_mac_link_up(struct dsa_switch 
*ds, int port,
  {
struct gswip_priv *priv = ds->priv;
  
-	/* Enable the xMII interface only for the external PHY */

-   if (interface != PHY_INTERFACE_MODE_INTERNAL)
-   gswip_mii_mask_cfg(priv, 0, GSWIP_MII_CFG_EN, port);
+   gswip_mii_mask_cfg(priv, 0, GSWIP_MII_CFG_EN, port);
  }
  
  static void gswip_get_strings(struct dsa_switch *ds, int port, u32 stringset,

Re: [PATCH] net: lantiq_etop: check the result of request_irq()

[Hauke Mehrtens]

On 12/21/20 7:04 PM, Andrew Lunn wrote:

On Tue, Dec 22, 2020 at 12:59:08AM +0900, Masahiro Yamada wrote:

On Tue, Dec 22, 2020 at 12:26 AM Andrew Lunn  wrote:


On Mon, Dec 21, 2020 at 02:43:23PM +0900, Masahiro Yamada wrote:

The declaration of request_irq() in  is marked as
__must_check.

Without the return value check, I see the following warnings:

drivers/net/ethernet/lantiq_etop.c: In function 'ltq_etop_hw_init':
drivers/net/ethernet/lantiq_etop.c:273:4: warning: ignoring return value of 
'request_irq', declared with attribute warn_unused_result [-Wunused-result]
   273 |request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv);
   |^~
drivers/net/ethernet/lantiq_etop.c:281:4: warning: ignoring return value of 
'request_irq', declared with attribute warn_unused_result [-Wunused-result]
   281 |request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv);
   |^~

Reported-by: Miguel Ojeda 
Signed-off-by: Masahiro Yamada 
---

  drivers/net/ethernet/lantiq_etop.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/lantiq_etop.c 
b/drivers/net/ethernet/lantiq_etop.c
index 2d0c52f7106b..960494f9752b 100644
--- a/drivers/net/ethernet/lantiq_etop.c
+++ b/drivers/net/ethernet/lantiq_etop.c
@@ -264,13 +264,18 @@ ltq_etop_hw_init(struct net_device *dev)
   for (i = 0; i < MAX_DMA_CHAN; i++) {
   int irq = LTQ_DMA_CH0_INT + i;
   struct ltq_etop_chan *ch = >ch[i];
+ int ret;

   ch->idx = ch->dma.nr = i;
   ch->dma.dev = >pdev->dev;

   if (IS_TX(i)) {
   ltq_dma_alloc_tx(>dma);
- request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv);
+ ret = request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", 
priv);
+ if (ret) {
+ netdev_err(dev, "failed to request irq\n");
+ return ret;


You need to cleanup what ltq_dma_alloc_tx() did.



Any failure from this function will roll back
in the following paths:

   ltq_etop_hw_exit()
  -> ltq_etop_free_channel()
   -> ltq_dma_free()


So, dma is freed anyway.

One problem I see is,
ltq_etop_hw_exit() frees all DMA channels,
some of which may not have been allocated yet.

If it is a bug, it is an existing bug.





+ }
   } else if (IS_RX(i)) {
   ltq_dma_alloc_rx(>dma);
   for (ch->dma.desc = 0; ch->dma.desc < LTQ_DESC_NUM;
@@ -278,7 +283,11 @@ ltq_etop_hw_init(struct net_device *dev)
   if (ltq_etop_alloc_skb(ch))
   return -ENOMEM;



This -ENOMEM does not roll back anything here.

As stated above, dma_free_coherent() is called.
The problem is, ltq_etop_hw_exit() rolls back too much.

If your requirement is "this driver is completely wrong. Please rewrite it",
sorry, I cannot (unless I am paid to do so).

I am just following this driver's roll-back model.

Please do not expect more to a person who
volunteers to eliminate build warnings.

Of course, if somebody volunteers to rewrite this driver correctly,
that is appreciated.


Hi Hauke

Do you still have this hardware? Do you have time to take a look at
the cleanup code?

Thanks
Andrew



Hi Andrew,

I have this hardware somewhere at home, but I never made it work.
If I find some time I can have a loom at this problem in the next few weeks.

Hauke

Re: [PATCH 1/2] net: dsa: lantiq: allow to use all GPHYs on xRX300 and xRX330

[Hauke Mehrtens]

On 12/4/20 2:49 AM, Andrew Lunn wrote:

  static const struct of_device_id gswip_of_match[] = {
{ .compatible = "lantiq,xrx200-gswip", .data = _xrx200 },
+   { .compatible = "lantiq,xrx300-gswip", .data = _xrx300 },
+   { .compatible = "lantiq,xrx330-gswip", .data = _xrx300 },
{},


Is there an ID register which allows you to ask the silicon what it
is?


Yes there is, see GSWIP_VERSION.


It would be good to verify the compatible string against the hardware,
if that is possible.

Andrew






OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 1/2] net: dsa: lantiq: allow to use all GPHYs on xRX300 and xRX330

[Hauke Mehrtens]

Hi,

This looks good.

I haven't checked all the differences between the SoCs, but found some 
minor problems in the code for the port configuration.



On 12/3/20 11:03 PM, Aleksander Jan Bajkowski wrote:

From: Aleksander Jan Bajkowski 

This patch allows you to use all phs on GRX300 and GRX330. The ARX300 has 3
and the GRX330 has 4 integrated PHYs connected to different ports compared
to VRX200.

Port configurations:

xRX200:
GMAC0: RGMII port
GMAC1: RGMII port
GMAC2: GPHY0 (GMII)
GMAC3: GPHY0 (MII)
GMAC4: GPHY1 (GMII)
GMAC5: GPHY1 (MII) or RGMII port

xRX300:
GMAC0: RGMII port
GMAC1: GPHY2 (GMII)
GMAC2: GPHY0 (GMII)
GMAC3: GPHY0 (MII)
GMAC4: GPHY1 (GMII)
GMAC5: GPHY1 (MII) or RGMII port

xRX330:
GMAC0: RGMII port
GMAC1: GPHY2 (GMII)
GMAC2: GPHY0 (GMII)
GMAC3: GPHY3 (GMII)

GMAC3: GPHY3 (GMII) or GPHY0 (MII)
This can be changed in GSWIP_MII_CFG3 (0xc3)


GMAC4: GPHY1 (GMII)
GMAC5: GPHY1 (MII) or RGMII port


You also have to change gswip_mii_mask_cfg() it only supports port 0, 1 
and 5, but this SoC can not change port 1 (always connected to internal 
GPHY, but it can change port 3 (change between GPHY0/MII/0x0 and 
PHY3/GMII/0x1)




Tested on D-Link DWR966 with OpenWRT.

Signed-off-by: Aleksander Jan Bajkowski 
---
  drivers/net/dsa/lantiq_gswip.c | 110 +++--
  1 file changed, 104 insertions(+), 6 deletions(-)

diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 09701c17f3f6..540cf99ad7fe 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -222,6 +222,7 @@
  struct gswip_hw_info {
int max_ports;
int cpu_port;
+   struct dsa_switch_ops *ops;
  };
  
  struct xway_gphy_match_data {

@@ -1409,9 +1410,9 @@ static int gswip_port_fdb_dump(struct dsa_switch *ds, int 
port,
return 0;
  }
  
-static void gswip_phylink_validate(struct dsa_switch *ds, int port,

-  unsigned long *supported,
-  struct phylink_link_state *state)
+static void gswip_xrx200_phylink_validate(struct dsa_switch *ds, int port,
+ unsigned long *supported,
+ struct phylink_link_state *state)
  {
__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
  
@@ -1471,7 +1472,70 @@ static void gswip_phylink_validate(struct dsa_switch *ds, int port,

bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
dev_err(ds->dev, "Unsupported interface '%s' for port %d\n",
phy_modes(state->interface), port);
+}
+
+static void gswip_xrx300_phylink_validate(struct dsa_switch *ds, int port,
+ unsigned long *supported,
+ struct phylink_link_state *state)
+{
+   __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+
+   switch (port) {
+   case 0:
+   if (!phy_interface_mode_is_rgmii(state->interface) &&
+   state->interface != PHY_INTERFACE_MODE_MII &


MII is not support on port 0


+   state->interface != PHY_INTERFACE_MODE_REVMII &&


REVMII is not support on port 0


+   state->interface != PHY_INTERFACE_MODE_RMII)


GMII is now supported with 0x9


+   goto unsupported;
+   break;
+   case 1:
+   case 2:
+   case 3:
+   case 4:
+   if (state->interface != PHY_INTERFACE_MODE_INTERNAL)
+   goto unsupported;
+   break;
+   case 5:
+   if (!phy_interface_mode_is_rgmii(state->interface) &&
+   state->interface != PHY_INTERFACE_MODE_INTERNAL)
+   goto unsupported;

port 5 also supports RMIIM with bit 0x3 on xrx300 and xrx330


+   break;
+   default:
+   bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
+   dev_err(ds->dev, "Unsupported port: %i\n", port);
+   return;
+   }
+
+   /* Allow all the expected bits */
+   phylink_set(mask, Autoneg);
+   phylink_set_port_modes(mask);
+   phylink_set(mask, Pause);
+   phylink_set(mask, Asym_Pause);
+
+   /* With the exclusion of MII and Reverse MII, we support Gigabit,
+* including Half duplex
+*/
+   if (state->interface != PHY_INTERFACE_MODE_MII &&
+   state->interface != PHY_INTERFACE_MODE_REVMII) {
+   phylink_set(mask, 1000baseT_Full);
+   phylink_set(mask, 1000baseT_Half);
+   }
+
+   phylink_set(mask, 10baseT_Half);
+   phylink_set(mask, 10baseT_Full);
+   phylink_set(mask, 100baseT_Half);
+   phylink_set(mask, 100baseT_Full);
+
+   bitmap_and(supported, supported, mask,
+  __ETHTOOL_LINK_MODE_MASK_NBITS);
+   bitmap_and(state->advertising, state->advertising, mask,
+  __ETHTOOL_LINK_MODE_MASK_NBITS);
You can put this block into a 

Re: [PATCH v2] net: lantiq: Wait for the GPHY firmware to be ready

[Hauke Mehrtens]

On 11/15/20 5:57 PM, Martin Blumenstingl wrote:

A user reports (slightly shortened from the original message):
   libphy: lantiq,xrx200-mdio: probed
   mdio_bus 1e108000.switch-mii: MDIO device at address 17 is missing.
   gswip 1e108000.switch lan: no phy at 2
   gswip 1e108000.switch lan: failed to connect to port 2: -19
   lantiq,xrx200-net 1e10b308.eth eth0: error -19 setting up slave phy

This is a single-port board using the internal Fast Ethernet PHY. The
user reports that switching to PHY scanning instead of configuring the
PHY within device-tree works around this issue.

The documentation for the standalone variant of the PHY11G (which is
probably very similar to what is used inside the xRX200 SoCs but having
the firmware burnt onto that standalone chip in the factory) states that
the PHY needs 300ms to be ready for MDIO communication after releasing
the reset.

Add a 300ms delay after initializing all GPHYs to ensure that the GPHY
firmware had enough time to initialize and to appear on the MDIO bus.
Unfortunately there is no (known) documentation on what the minimum time
to wait after releasing the reset on an internal PHY so play safe and
take the one for the external variant. Only wait after the last GPHY
firmware is loaded to not slow down the initialization too much (
xRX200 has two GPHYs but newer SoCs have at least three GPHYs).

Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Reviewed-by: Andrew Lunn 
Signed-off-by: Martin Blumenstingl 


Acked-by: Hauke Mehrtens 


---
Changes since v1:
- move the msleep() closer to the actual loop over all GPHY instances
   as suggested by Andrew
- added Andrew's Reviewed-by (thank you!)


  drivers/net/dsa/lantiq_gswip.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 74db81dafee3..09701c17f3f6 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -26,6 +26,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -1837,6 +1838,16 @@ static int gswip_gphy_fw_list(struct gswip_priv *priv,
i++;
}
  
+	/* The standalone PHY11G requires 300ms to be fully

+* initialized and ready for any MDIO communication after being
+* taken out of reset. For the SoC-internal GPHY variant there
+* is no (known) documentation for the minimum time after a
+* reset. Use the same value as for the standalone variant as
+* some users have reported internal PHYs not being detected
+* without any delay.
+*/
+   msleep(300);
+
return 0;
  
  remove_gphy:






OpenPGP_0x93DD20630910B515.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH AUTOSEL 5.4 10/58] mips: vdso: fix 'jalr t9' crash in vdso code

[Hauke Mehrtens]

On 8/29/20 3:56 PM, Sasha Levin wrote:
> On Sat, Aug 29, 2020 at 03:08:01PM +0200, Hauke Mehrtens wrote:
>> On 3/5/20 6:13 PM, Sasha Levin wrote:
>>> From: Victor Kamensky 
>>>
>>> [ Upstream commit d3f703c4359ff06619b2322b91f69710453e6b6d ]
>>>
>>> Observed that when kernel is built with Yocto mips64-poky-linux-gcc,
>>> and mips64-poky-linux-gnun32-gcc toolchain, resulting vdso contains
>>> 'jalr t9' instructions in its code and since in vdso case nobody
>>> sets GOT table code crashes when instruction reached. On other hand
>>> observed that when kernel is built mips-poky-linux-gcc toolchain, the
>>> same 'jalr t9' instruction are replaced with PC relative function
>>> calls using 'bal' instructions.
>>>
>>> The difference boils down to -mrelax-pic-calls and -mexplicit-relocs
>>> gcc options that gets different default values depending on gcc
>>> target triplets and corresponding binutils. -mrelax-pic-calls got
>>> enabled by default only in mips-poky-linux-gcc case. MIPS binutils
>>> ld relies on R_MIPS_JALR relocation to convert 'jalr t9' into 'bal'
>>> and such relocation is generated only if -mrelax-pic-calls option
>>> is on.
>>>
>>> Please note 'jalr t9' conversion to 'bal' can happen only to static
>>> functions. These static PIC calls use mips local GOT entries that
>>> are supposed to be filled with start of DSO value by run-time linker
>>> (missing in VDSO case) and they do not have dynamic relocations.
>>> Global mips GOT entries must have dynamic relocations and they should
>>> be prevented by cmd_vdso_check Makefile rule.
>>>
>>> Solution call out -mrelax-pic-calls and -mexplicit-relocs options
>>> explicitly while compiling MIPS vdso code. That would get correct
>>> and consistent between different toolchains behaviour.
>>>
>>> Reported-by: Bruce Ashfield 
>>> Signed-off-by: Victor Kamensky 
>>> Signed-off-by: Paul Burton 
>>> Cc: linux-m...@vger.kernel.org
>>> Cc: Ralf Baechle 
>>> Cc: James Hogan 
>>> Cc: Vincenzo Frascino 
>>> Cc: richard.pur...@linuxfoundation.org
>>> Signed-off-by: Sasha Levin 
>>> ---
>>>  arch/mips/vdso/Makefile | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>
>> Hi Sasha,
>>
>> Why was this not added to the 5.4 stable branch?
>>
>> Some OpenWrt users ran into this problem with kernel 5.4 on MIPS64 [0].
>> We backported this patch on our own in OpenWrt [1], but it should be
>> added to the sable branch in my opinion as it fixes a real problem.
>>
>> @Sasha: Can you add it to the 5.4 stable branch or should I send some
>> special email?
> 
> It failed building on 5.4. If you'd like it included, please send me a
> tested backport for 5.4.
> 

I successfully compiled a kernel 5.4.61 with this patch on top with GCC
8.4 for MIPS 64 big and little Endian.

What was broken in your compile test?

Someone complained that it does not compile with LLVM any more, there is
this additional fix to solve that problem:
https://git.kernel.org/linus/72cf3b3df423c1bbd8fa1056fed009d3a260f8a9
OpenWrt does not support LLVM, so we did not see this problem.

Could you please backport these two commits to kernel 5.4:
https://git.kernel.org/linus/d3f703c4359ff06619b2322b91f69710453e6b6d
https://git.kernel.org/linus/72cf3b3df423c1bbd8fa1056fed009d3a260f8a9

We haven't seen this problem with kernel 4.19 or older, but I am not
sure if this was luck.

Hauke



signature.asc
Description: OpenPGP digital signature

Re: [PATCH AUTOSEL 5.4 10/58] mips: vdso: fix 'jalr t9' crash in vdso code

[Hauke Mehrtens]

On 3/5/20 6:13 PM, Sasha Levin wrote:
> From: Victor Kamensky 
> 
> [ Upstream commit d3f703c4359ff06619b2322b91f69710453e6b6d ]
> 
> Observed that when kernel is built with Yocto mips64-poky-linux-gcc,
> and mips64-poky-linux-gnun32-gcc toolchain, resulting vdso contains
> 'jalr t9' instructions in its code and since in vdso case nobody
> sets GOT table code crashes when instruction reached. On other hand
> observed that when kernel is built mips-poky-linux-gcc toolchain, the
> same 'jalr t9' instruction are replaced with PC relative function
> calls using 'bal' instructions.
> 
> The difference boils down to -mrelax-pic-calls and -mexplicit-relocs
> gcc options that gets different default values depending on gcc
> target triplets and corresponding binutils. -mrelax-pic-calls got
> enabled by default only in mips-poky-linux-gcc case. MIPS binutils
> ld relies on R_MIPS_JALR relocation to convert 'jalr t9' into 'bal'
> and such relocation is generated only if -mrelax-pic-calls option
> is on.
> 
> Please note 'jalr t9' conversion to 'bal' can happen only to static
> functions. These static PIC calls use mips local GOT entries that
> are supposed to be filled with start of DSO value by run-time linker
> (missing in VDSO case) and they do not have dynamic relocations.
> Global mips GOT entries must have dynamic relocations and they should
> be prevented by cmd_vdso_check Makefile rule.
> 
> Solution call out -mrelax-pic-calls and -mexplicit-relocs options
> explicitly while compiling MIPS vdso code. That would get correct
> and consistent between different toolchains behaviour.
> 
> Reported-by: Bruce Ashfield 
> Signed-off-by: Victor Kamensky 
> Signed-off-by: Paul Burton 
> Cc: linux-m...@vger.kernel.org
> Cc: Ralf Baechle 
> Cc: James Hogan 
> Cc: Vincenzo Frascino 
> Cc: richard.pur...@linuxfoundation.org
> Signed-off-by: Sasha Levin 
> ---
>  arch/mips/vdso/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 

Hi Sasha,

Why was this not added to the 5.4 stable branch?

Some OpenWrt users ran into this problem with kernel 5.4 on MIPS64 [0].
We backported this patch on our own in OpenWrt [1], but it should be
added to the sable branch in my opinion as it fixes a real problem.

@Sasha: Can you add it to the 5.4 stable branch or should I send some
special email?

[0]: https://bugs.openwrt.org/index.php?do=details_id=3277
[1]: https://git.openwrt.org/2932b4d05e1d212259c2903fd9cebcee5616680b

Hauke



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] MIPS: lantiq: xway: sysctrl: fix the GPHY clock alias names

[Hauke Mehrtens]

On 6/7/20 3:10 PM, Martin Blumenstingl wrote:
> The dt-bindings for the GSWIP describe that the node should be named
> "switch". Use the same name in sysctrl.c so the GSWIP driver can
> actually find the "gphy0" and "gphy1" clocks.
> 
> Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Martin Blumenstingl 

Acked-by: Hauke Mehrtens 

> ---
>  arch/mips/lantiq/xway/sysctrl.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/mips/lantiq/xway/sysctrl.c b/arch/mips/lantiq/xway/sysctrl.c
> index aa37545ebe8f..b10342018d19 100644
> --- a/arch/mips/lantiq/xway/sysctrl.c
> +++ b/arch/mips/lantiq/xway/sysctrl.c
> @@ -514,8 +514,8 @@ void __init ltq_soc_init(void)
>   clkdev_add_pmu("1e10b308.eth", NULL, 0, 0, PMU_SWITCH |
>  PMU_PPE_DP | PMU_PPE_TC);
>   clkdev_add_pmu("1da0.usif", "NULL", 1, 0, PMU_USIF);
> - clkdev_add_pmu("1e108000.gswip", "gphy0", 0, 0, PMU_GPHY);
> - clkdev_add_pmu("1e108000.gswip", "gphy1", 0, 0, PMU_GPHY);
> + clkdev_add_pmu("1e108000.switch", "gphy0", 0, 0, PMU_GPHY);
> + clkdev_add_pmu("1e108000.switch", "gphy1", 0, 0, PMU_GPHY);
>   clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU);
>   clkdev_add_pmu("1e116000.mei", "afe", 1, 2, PMU_ANALOG_DSL_AFE);
>   clkdev_add_pmu("1e116000.mei", "dfe", 1, 0, PMU_DFE);
> @@ -538,8 +538,8 @@ void __init ltq_soc_init(void)
>   PMU_SWITCH | PMU_PPE_DPLUS | PMU_PPE_DPLUM |
>   PMU_PPE_EMA | PMU_PPE_TC | PMU_PPE_SLL01 |
>   PMU_PPE_QSB | PMU_PPE_TOP);
> - clkdev_add_pmu("1e108000.gswip", "gphy0", 0, 0, PMU_GPHY);
> - clkdev_add_pmu("1e108000.gswip", "gphy1", 0, 0, PMU_GPHY);
> + clkdev_add_pmu("1e108000.switch", "gphy0", 0, 0, PMU_GPHY);
> + clkdev_add_pmu("1e108000.switch", "gphy1", 0, 0, PMU_GPHY);
>   clkdev_add_pmu("1e103000.sdio", NULL, 1, 0, PMU_SDIO);
>   clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU);
>   clkdev_add_pmu("1e116000.mei", "dfe", 1, 0, PMU_DFE);
> 




signature.asc
Description: OpenPGP digital signature

Re: [PATCH net v1] net: dsa: lantiq_gswip: fix and improve the unsupported interface error

[Hauke Mehrtens]

On 6/7/20 3:02 PM, Martin Blumenstingl wrote:
> While trying to use the lantiq_gswip driver on one of my boards I made
> a mistake when specifying the phy-mode (because the out-of-tree driver
> wants phy-mode "gmii" or "mii" for the internal PHYs). In this case the
> following error is printed multiple times:
>   Unsupported interface: 3
> 
> While it gives at least a hint at what may be wrong it is not very user
> friendly. Print the human readable phy-mode and also which port is
> configured incorrectly (this hardware supports ports 0..6) to improve
> the cases where someone made a mistake.
> 
> Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Signed-off-by: Martin Blumenstingl 

Acked-by: Hauke Mehrtens 

> ---
>  drivers/net/dsa/lantiq_gswip.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
> index cf6fa8fede33..521ebc072903 100644
> --- a/drivers/net/dsa/lantiq_gswip.c
> +++ b/drivers/net/dsa/lantiq_gswip.c
> @@ -1452,7 +1452,8 @@ static void gswip_phylink_validate(struct dsa_switch 
> *ds, int port,
>  
>  unsupported:
>   bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
> - dev_err(ds->dev, "Unsupported interface: %d\n", state->interface);
> + dev_err(ds->dev, "Unsupported interface '%s' for port %d\n",
> + phy_modes(state->interface), port);
>   return;
>  }
>  
> 

Re: [PATCH 1/4] spi: lantiq: Synchronize interrupt handlers and transfers

[Hauke Mehrtens]

On 4/28/20 1:10 PM, Daniel Schwierzeck wrote:
> 
> 
> Am 24.04.20 um 12:42 schrieb Dilip Kota:
>> Synchronize tx, rx and error interrupts by registering to the
>> same interrupt handler. Interrupt handler will recognize and process
>> the appropriate interrupt on the basis of interrupt status register.
>> Also, establish synchronization between the interrupt handler and
>> transfer operation by taking the locks and registering the interrupt
>> handler as thread IRQ which avoids the bottom half.
> 
> actually there is no real bottom half. Reading or writing the FIFOs is
> fast and is therefore be done in hard IRQ context. But as the comment
> for lantiq_ssc_bussy_work() state, the driver needs some busy-waiting
> after the last interrupt. I don't think it's worth to replace this with
> threaded interrupts which add more runtime overhead and likely decrease
> the maximum transfer speed.
> 
>> Fixes the wrongly populated interrupt register offsets too.
>>
>> Fixes: 17f84b793c01 ("spi: lantiq-ssc: add support for Lantiq SSC SPI 
>> controller")
>> Fixes: ad2fca0721d1 ("spi: lantiq-ssc: add LTQ_ prefix to defines")
>> Signed-off-by: Dilip Kota 
>> ---
>>  drivers/spi/spi-lantiq-ssc.c | 89 
>> ++--
>>  1 file changed, 45 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/spi/spi-lantiq-ssc.c b/drivers/spi/spi-lantiq-ssc.c
>> index 1fd7ee53d451..b67f5925bcb0 100644
>> --- a/drivers/spi/spi-lantiq-ssc.c
>> +++ b/drivers/spi/spi-lantiq-ssc.c
>> @@ -6,6 +6,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -13,7 +14,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -50,8 +50,8 @@
>>  #define LTQ_SPI_RXCNT   0x84
>>  #define LTQ_SPI_DMACON  0xec
>>  #define LTQ_SPI_IRNEN   0xf4
>> -#define LTQ_SPI_IRNICR  0xf8
>> -#define LTQ_SPI_IRNCR   0xfc
>> +#define LTQ_SPI_IRNCR   0xf8
>> +#define LTQ_SPI_IRNICR  0xfc
> 
> the values are matching the datasheets for Danube and VRX200 family.
> AFAICS the registers have been swapped for some newer SoCs like GRX330
> or GRX550. It didn't matter until now because those registers were
> unused by the driver. So if you want to use those registers, you have to
> deal somehow with the register offset swap in struct lantiq_ssc_hwcfg.

Hi,

The Interrupt controller found on Danube till xrx300 which is probably
from Infineon like this SPI controller IP acknowledges the interrupts
also inside this SPI controller IP automatically, this has to be done
manually on the xrx500 and probably also LGM as they use a different
interrupt controller. I prepared patches for this internally 2.5 years
ago but did not send them upstream because of internal processes.

I would suggest to only do this ack on the newer platforms starting with
the xrx500 and not on the older.

On SMP systems a lock is needed in lantiq_ssc_xmit_interrupt() to
protect against an other thread reading from the RX buffer or writing to
the TX buffer in parallel.

@Dilip. Did you try the patches I send you one months ago on the LGM?

I would be helpful to split this patch into multiple like already
suggest to make it easier to find the bugs.

Hauke

Re: [musl] [PATCH] arm64: uapi: Fix user space compile with musl libc

[Hauke Mehrtens]

On 10/19/19 10:29 PM, Rich Felker wrote:
> On Sat, Oct 19, 2019 at 10:17:17PM +0200, Hauke Mehrtens wrote:
>> musl libc also defines the structures in their arch/aarch64/bits/signal.h
>> header file. Some applications like strace and gdb include both of them
>> and then the structure definitions are clashing and the build of these
>> user space applications fails.
>>
>> This patch allows a libc to define a constant which tells the kernel
>> header file that the libc already defined these structures and that they
>> should not be defined by the kernel uapi header files any more to
>> prevent clashes. This is done in a similar way as it is already done for
>> other header files.
>>
>> When this patch was accepted into the kernel I will also update musl
>> libc to define these constants.
> 
> I don't entirely object to this outright, but I'd really like to avoid
> adding further __UAPI_DEF_* suppressions. AIUI asm/sigcontext.h is not
> intended to be used with userspace headers. Is it still being
> indirectly included via some other uapi headers? (I thought that was
> fixed..) If so, that should really be fixed first, and then we can see
> if there's still motivation for the patch here.
> 
> Rich
> 
Hi Rich,

I did some more research and it looks like this patch also fixes my
problem with strace and gdb compile:
https://git.kernel.org/linus/9966a05c7b80f075f2bc7e48dbb108d3f2927234

I will backport it in OpenWrt to kernel 4.19.

Please drop my patch.

It would be nice if it could go into the stable 4.19 kernel.

Hauke

[PATCH] arm64: uapi: Fix user space compile with musl libc

[Hauke Mehrtens]

musl libc also defines the structures in their arch/aarch64/bits/signal.h
header file. Some applications like strace and gdb include both of them
and then the structure definitions are clashing and the build of these
user space applications fails.

This patch allows a libc to define a constant which tells the kernel
header file that the libc already defined these structures and that they
should not be defined by the kernel uapi header files any more to
prevent clashes. This is done in a similar way as it is already done for
other header files.

When this patch was accepted into the kernel I will also update musl
libc to define these constants.

Signed-off-by: Hauke Mehrtens 
Cc: sta...@vger.kernel.org
---
 arch/arm64/include/uapi/asm/sigcontext.h | 13 +
 include/uapi/linux/libc-compat.h | 20 
 2 files changed, 33 insertions(+)

diff --git a/arch/arm64/include/uapi/asm/sigcontext.h 
b/arch/arm64/include/uapi/asm/sigcontext.h
index 8b0ebce92427..92d911146137 100644
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -20,7 +20,9 @@
 #ifndef __ASSEMBLY__
 
 #include 
+#include 
 
+#if __UAPI_DEF_SIGCONTEXT
 /*
  * Signal context structure - contains all info to do with the state
  * before the signal handler was invoked.
@@ -35,6 +37,7 @@ struct sigcontext {
/* 4K reserved for FP/SIMD state and future expansion */
__u8 __reserved[4096] __attribute__((__aligned__(16)));
 };
+#endif
 
 /*
  * Allocation of __reserved[]:
@@ -57,6 +60,7 @@ struct sigcontext {
  * generated when userspace does not opt in for any such extension.
  */
 
+#if __UAPI_DEF_AARCH64_CTX
 /*
  * Header to be used at the beginning of structures extending the user
  * context. Such structures must be placed after the rt_sigframe on the stack
@@ -67,7 +71,9 @@ struct _aarch64_ctx {
__u32 magic;
__u32 size;
 };
+#endif
 
+#if __UAPI_DEF_FPSIMD_CONTEXT
 #define FPSIMD_MAGIC   0x46508001
 
 struct fpsimd_context {
@@ -76,7 +82,9 @@ struct fpsimd_context {
__u32 fpcr;
__uint128_t vregs[32];
 };
+#endif
 
+#if __UAPI_DEF_ESR_CONTEXT
 /*
  * Note: similarly to all other integer fields, each V-register is stored in an
  * endianness-dependent format, with the byte at offset i from the start of the
@@ -93,7 +101,9 @@ struct esr_context {
struct _aarch64_ctx head;
__u64 esr;
 };
+#endif
 
+#if __UAPI_DEF_EXTRA_CONTEXT
 /*
  * extra_context: describes extra space in the signal frame for
  * additional structures that don't fit in sigcontext.__reserved[].
@@ -128,7 +138,9 @@ struct extra_context {
__u32 size; /* size in bytes of the extra space */
__u32 __reserved[3];
 };
+#endif
 
+#if __UAPI_DEF_SVE_CONTEXT
 #define SVE_MAGIC  0x53564501
 
 struct sve_context {
@@ -136,6 +148,7 @@ struct sve_context {
__u16 vl;
__u16 __reserved[3];
 };
+#endif
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 8254c937c9f4..a863130f4638 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -264,4 +264,24 @@
 
 #endif /* __GLIBC__ */
 
+/* Definitions for arch/arm64/include/uapi/asm/sigcontext.h */
+#ifndef __UAPI_DEF_SIGCONTEXT
+#define __UAPI_DEF_SIGCONTEXT  1
+#endif
+#ifndef __UAPI_DEF_AARCH64_CTX
+#define __UAPI_DEF_AARCH64_CTX 1
+#endif
+#ifndef __UAPI_DEF_FPSIMD_CONTEXT
+#define __UAPI_DEF_FPSIMD_CONTEXT  1
+#endif
+#ifndef __UAPI_DEF_ESR_CONTEXT
+#define __UAPI_DEF_ESR_CONTEXT 1
+#endif
+#ifndef __UAPI_DEF_EXTRA_CONTEXT
+#define __UAPI_DEF_EXTRA_CONTEXT   1
+#endif
+#ifndef __UAPI_DEF_SVE_CONTEXT
+#define __UAPI_DEF_SVE_CONTEXT 1
+#endif
+
 #endif /* _UAPI_LIBC_COMPAT_H */
-- 
2.20.1

Re: [PATCH AUTOSEL 5.2 17/42] MIPS: lantiq: update the clock alias' for the mainline PCIe PHY driver

[Hauke Mehrtens]

On 9/29/19 7:32 PM, Sasha Levin wrote:
> From: Martin Blumenstingl 
> 
> [ Upstream commit ed90302be64a53d9031c8ce05428c358b16a5d96 ]
> 
> The mainline PCIe PHY driver has it's own devicetree node. Update the
> clock alias so the mainline driver finds the clocks.
> 
> The first PCIe PHY is located at 0x1f106800 and exists on VRX200, ARX300
> and GRX390.
> The second PCIe PHY is located at 0x1f700400 and exists on ARX300 and
> GRX390.
> The third PCIe PHY is located at 0x1f106a00 and exists onl on GRX390.
> Lantiq's board support package (called "UGW") names these registers
> "PDI".
> 
> Signed-off-by: Martin Blumenstingl 
> Signed-off-by: Paul Burton 
> Cc: linux-m...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Cc: j...@phrozen.org
> Cc: kis...@ti.com
> Cc: r...@linux-mips.org
> Cc: robh...@kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: ha...@hauke-m.de
> Cc: mark.rutl...@arm.com
> Cc: m...@dev.tdt.de
> Signed-off-by: Sasha Levin 
> ---
>  arch/mips/lantiq/xway/sysctrl.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Hi Sasha,

This change only makes sense with the new upstream PCIe phy driver which
was added to kernel 5.4 [0], older kernel versions do not have this PCIe
PHY driver. I would not backport these changes to older kernel versions.

[0]: https://git.kernel.org/linus/e52a632195bf43d1a91ae699e7536a6ead736aa7

Hauke



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] ethernet: lantiq_xrx200: Use devm_platform_ioremap_resource() in xrx200_probe()

[Hauke Mehrtens]

On 9/20/19 12:57 PM, Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 20 Sep 2019 11:48:33 +0200
> 
> Simplify this function implementation by using the wrapper function
> “devm_platform_ioremap_resource” instead of calling the functions
> “platform_get_resource” and “devm_ioremap_resource” directly.
> 
> * Thus reduce also a bit of exception handling code here.
> * Delete the local variable “res”.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Hauke Mehrtens 

But this can also wait till kernel 5.5.

> ---
> 
> v2:
> Further changes were requested by Radhey Shyam Pandey.
> 
> https://lore.kernel.org/r/ch2pr02mb700047afffe08fe5fd563541c7...@ch2pr02mb7000.namprd02.prod.outlook.com/
> 
> 
> 
> * Updates for three modules were split into a separate patch for each driver.
> 
> * The commit description was adjusted.
> 
> 
> 
> 
> 
>  drivers/net/ethernet/lantiq_xrx200.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ethernet/lantiq_xrx200.c 
> b/drivers/net/ethernet/lantiq_xrx200.c
> index 900affbdcc0e..0a7ea45b9e59 100644
> --- a/drivers/net/ethernet/lantiq_xrx200.c
> +++ b/drivers/net/ethernet/lantiq_xrx200.c
> @@ -424,7 +424,6 @@ static int xrx200_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
>   struct device_node *np = dev->of_node;
> - struct resource *res;
>   struct xrx200_priv *priv;
>   struct net_device *net_dev;
>   const u8 *mac;
> @@ -443,15 +442,7 @@ static int xrx200_probe(struct platform_device *pdev)
>   SET_NETDEV_DEV(net_dev, dev);
>   net_dev->min_mtu = ETH_ZLEN;
>   net_dev->max_mtu = XRX200_DMA_DATA_LEN;
> -
> - /* load the memory ranges */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(dev, "failed to get resources\n");
> - return -ENOENT;
> - }
> -
> - priv->pmac_reg = devm_ioremap_resource(dev, res);
> + priv->pmac_reg = devm_platform_ioremap_resource(pdev, 0);
>   if (IS_ERR(priv->pmac_reg)) {
>   dev_err(dev, "failed to request and remap io ranges\n");
>   return PTR_ERR(priv->pmac_reg);
> --
> 2.23.0
> 




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 5/5] MIPS: dts: lantiq: danube: easy50712: route the PCI_INTA IRQ through EBU

[Hauke Mehrtens]

On 7/28/19 12:03 PM, Marc Zyngier wrote:
> On Sat, 27 Jul 2019 18:53:15 +0100,
> Martin Blumenstingl  wrote:
>>
>> EBU provides an interrupt line for the PCI_INTA interrupt. Route
>> easy50712's PCI interrupt to EBU so the interrupt line is configured
>> correctly (using IRQ_TYPE_LEVEL_LOW, this was previously hardcoded in
>> the PCI driver) and ACKed properly.
>>
>> Signed-off-by: Martin Blumenstingl 

Acked-by: Hauke Mehrtens 

>> ---
>>  arch/mips/boot/dts/lantiq/easy50712.dts | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/mips/boot/dts/lantiq/easy50712.dts 
>> b/arch/mips/boot/dts/lantiq/easy50712.dts
>> index 1ce20b7d05cb..33c26b93cfc9 100644
>> --- a/arch/mips/boot/dts/lantiq/easy50712.dts
>> +++ b/arch/mips/boot/dts/lantiq/easy50712.dts
>> @@ -1,6 +1,8 @@
>>  // SPDX-License-Identifier: GPL-2.0
>>  /dts-v1/;
>>  
>> +#include 
>> +
>>  /include/ "danube.dtsi"
>>  
>>  / {
>> @@ -105,7 +107,7 @@
>>  lantiq,bus-clock = <>;
>>  interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
>>  interrupt-map = <
>> -0x7000 0 0 1  29 1 // slot 14, irq 29
>> +0x7000 0 0 1  0 IRQ_TYPE_LEVEL_LOW // slot 
>> 14
>>  >;
>>  gpios-reset = < 21 0>;
>>  req-mask = <0x1>;   /* GNT1 */
>> -- 
>> 2.22.0
>>
> 
> Are you OK with breaking compatibility between kernel and DT? It
> usually isn't very nice for users...

I am fine with such changes. I am not aware of any board using this SoC
which ships the kernel and the device tree file as different binaries,
it is always either attached or patched into the kernel and never in the
boot loader.

Hauke



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/3] net: dsa: lantiq_gswip: fix OF child-node lookups

[Hauke Mehrtens]

On 1/16/19 11:23 AM, Johan Hovold wrote:
> Use the new of_get_compatible_child() helper to look up child nodes to
> avoid ever matching non-child nodes elsewhere in the tree.
> 
> Also fix up the related struct device_node leaks.
> 
> Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Cc: stable# 4.20
> Cc: Hauke Mehrtens 
> Signed-off-by: Johan Hovold 

Acked-by: Hauke Mehrtens 

> ---
>  drivers/net/dsa/lantiq_gswip.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 

Re: [PATCH 3/3] net: dsa: lantiq_gswip: drop bogus drvdata check

[Hauke Mehrtens]

On 1/16/19 11:23 AM, Johan Hovold wrote:
> The platform-device driver data is set on successful probe and will
> never be NULL on remove (or we have much bigger problems).
> 
> Signed-off-by: Johan Hovold 

Acked-by: Hauke Mehrtens 

> ---
>  drivers/net/dsa/lantiq_gswip.c | 3 ---
>  1 file changed, 3 deletions(-)
> 

Re: [PATCH 1/3] net: dsa: lantiq_gswip: fix use-after-free on failed probe

[Hauke Mehrtens]

On 1/16/19 4:00 PM, Andrew Lunn wrote:
> On Wed, Jan 16, 2019 at 11:23:33AM +0100, Johan Hovold wrote:
>> Make sure to disable and deregister the switch on late probe errors to
>> avoid use-after-free when the device-resource-managed switch is freed.
>>
>> Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
>> Cc: stable   # 4.20
>> Cc: Hauke Mehrtens 
>> Signed-off-by: Johan Hovold 
>> ---
>>  drivers/net/dsa/lantiq_gswip.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
>> index 693a67f45bef..b06c41c98de9 100644
>> --- a/drivers/net/dsa/lantiq_gswip.c
>> +++ b/drivers/net/dsa/lantiq_gswip.c
>> @@ -1099,7 +1099,7 @@ static int gswip_probe(struct platform_device *pdev)
>>  dev_err(dev, "wrong CPU port defined, HW only supports port: 
>> %i",
>>  priv->hw_info->cpu_port);
>>  err = -EINVAL;
>> -goto mdio_bus;
>> +goto disable_switch;
>>  }
>>  
>>  platform_set_drvdata(pdev, priv);
>> @@ -1109,6 +1109,9 @@ static int gswip_probe(struct platform_device *pdev)
>>   (version & GSWIP_VERSION_MOD_MASK) >> GSWIP_VERSION_MOD_SHIFT);
>>  return 0;
>>  
>> +disable_switch:
>> +gswip_mdio_mask(priv, GSWIP_MDIO_GLOB_ENABLE, 0, GSWIP_MDIO_GLOB);
>> +dsa_unregister_switch(priv->ds);
> 
> This is correct. But it would be nice if somebody in the future could
> move the disabling of the switch to the inverse of the gswip_setup()
> function to make the code symmetrical.

Should we add an uninit callback?

Hauke

Re: [PATCH 1/3] net: dsa: lantiq_gswip: fix use-after-free on failed probe

[Hauke Mehrtens]

On 1/16/19 11:23 AM, Johan Hovold wrote:
> Make sure to disable and deregister the switch on late probe errors to
> avoid use-after-free when the device-resource-managed switch is freed.
> 
> Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Cc: stable# 4.20
> Cc: Hauke Mehrtens 
> Signed-off-by: Johan Hovold 

Acked-by: Hauke Mehrtens 

> ---
>  drivers/net/dsa/lantiq_gswip.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
> index 693a67f45bef..b06c41c98de9 100644
> --- a/drivers/net/dsa/lantiq_gswip.c
> +++ b/drivers/net/dsa/lantiq_gswip.c
> @@ -1099,7 +1099,7 @@ static int gswip_probe(struct platform_device *pdev)
>   dev_err(dev, "wrong CPU port defined, HW only supports port: 
> %i",
>   priv->hw_info->cpu_port);
>   err = -EINVAL;
> - goto mdio_bus;
> + goto disable_switch;
>   }
>  
>   platform_set_drvdata(pdev, priv);
> @@ -1109,6 +1109,9 @@ static int gswip_probe(struct platform_device *pdev)
>(version & GSWIP_VERSION_MOD_MASK) >> GSWIP_VERSION_MOD_SHIFT);
>   return 0;
>  
> +disable_switch:
> + gswip_mdio_mask(priv, GSWIP_MDIO_GLOB_ENABLE, 0, GSWIP_MDIO_GLOB);
> + dsa_unregister_switch(priv->ds);
>  mdio_bus:
>   if (mdio_np)
>   mdiobus_unregister(priv->ds->slave_mii_bus);
> 

Re: [PATCH mips-fixes] MIPS: BCM47XX: Setup struct device for the SoC

[Hauke Mehrtens]

On 1/2/19 1:51 PM, Rafał Miłecki wrote:

From: Rafał Miłecki 

So far we never had any device registered for the SoC. This resulted in
some small issues that we kept ignoring like:
1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing)
2) Lack of proper tree in the /sys/devices/
3) mips_dma_alloc_coherent() silently handling empty coherent_dma_mask

Kernel 4.19 came with a lot of DMA changes and caused a regression on
bcm47xx. Starting with the commit f8c55dc6e828 ("MIPS: use generic dma
noncoherent ops for simple noncoherent platforms") DMA coherent
allocations just fail. Example:
[1.114914] bgmac_bcma bcma0:2: Allocation of TX ring 0x200 failed
[1.121215] bgmac_bcma bcma0:2: Unable to alloc memory for DMA
[1.127626] bgmac_bcma: probe of bcma0:2 failed with error -12
[1.133838] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded

The bgmac driver also triggers a WARNING:
[0.959486] [ cut here ]
[0.964387] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 
bgmac_enet_probe+0x1b4/0x5c4
[0.973751] Modules linked in:
[0.976913] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.9 #0
[0.982750] Stack : 804a 804597c4   80458fd8 8381bc2c 
838282d4 80481a47
[0.991367] 8042e3ec 0001 804d38f0 0204 8398 0065 
8381bbe0 6f55b24f
[0.75]   8052 2018  0075 
0007 
[1.008583]  8048 000ee811    
80432c00 80248db8
[1.017196] 0009 0204 8398 803ad7b0  801feeec 
 804d
[1.025804] ...
[1.028325] Call Trace:
[1.030875] [<8000aef8>] show_stack+0x58/0x100
[1.035513] [<8001f8b4>] __warn+0xe4/0x118
[1.039708] [<8001f9a4>] warn_slowpath_null+0x48/0x64
[1.044935] [<80248db8>] bgmac_enet_probe+0x1b4/0x5c4
[1.050101] [<802498e0>] bgmac_probe+0x558/0x590
[1.054906] [<80252fd0>] bcma_device_probe+0x38/0x70
[1.060017] [<8020e1e8>] really_probe+0x170/0x2e8
[1.064891] [<8020e714>] __driver_attach+0xa4/0xec
[1.069784] [<8020c1e0>] bus_for_each_dev+0x58/0xb0
[1.074833] [<8020d590>] bus_add_driver+0xf8/0x218
[1.079731] [<8020ef24>] driver_register+0xcc/0x11c
[1.084804] [<804b54cc>] bgmac_init+0x1c/0x44
[1.089258] [<8000121c>] do_one_initcall+0x7c/0x1a0
[1.094343] [<804a1d34>] kernel_init_freeable+0x150/0x218
[1.099886] [<803a082c>] kernel_init+0x10/0x104
[1.104583] [<80005878>] ret_from_kernel_thread+0x14/0x1c
[1.110107] ---[ end trace f441c0d873d1fb5b ]---

This patch setups a "struct device" (and passes it to the bcma) which
allows fixing all the mentioned problems. It'll also require a tiny bcma
patch which will follow through the wireless tree & its maintainer.

Fixes: f8c55dc6e828 ("MIPS: use generic dma noncoherent ops for simple noncoherent 
platforms")
Cc: Christoph Hellwig 
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Rafał Miłecki 


Acked-by: Hauke Mehrtens 

I assume that the old ssb based devices also have such problems did you 
had a look into those?



---
  arch/mips/bcm47xx/setup.c | 30 ++
  include/linux/bcma/bcma_soc.h |  1 +
  2 files changed, 31 insertions(+)

diff --git a/arch/mips/bcm47xx/setup.c b/arch/mips/bcm47xx/setup.c
index 6054d49e608e..9339a31a0a87 100644
--- a/arch/mips/bcm47xx/setup.c
+++ b/arch/mips/bcm47xx/setup.c
@@ -173,6 +173,31 @@ void __init plat_mem_setup(void)
pm_power_off = bcm47xx_machine_halt;
  }
  
+#ifdef CONFIG_BCM47XX_BCMA

+static struct device * __init bcm47xx_setup_device(void)
+{
+   struct device *dev;
+   int err;
+
+   dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+   if (!dev)
+   return NULL;
+
+   err = dev_set_name(dev, "bcm47xx_soc");
+   if (err) {
+   pr_err("Failed to set SoC device name: %d\n", err);
+   kfree(dev);
+   return NULL;
+   }
+
+   err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
+   if (err)
+   pr_err("Failed to set SoC DMA mask: %d\n", err);
+
+   return dev;
+}
+#endif
+
  /*
   * This finishes bus initialization doing things that were not possible 
without
   * kmalloc. Make sure to call it late enough (after mm_init).
@@ -183,6 +208,10 @@ void __init bcm47xx_bus_setup(void)
if (bcm47xx_bus_type == BCM47XX_BUS_TYPE_BCMA) {
int err;
  
+		bcm47xx_bus.bcma.dev = bcm47xx_setup_device();

+   if (!bcm47xx_bus.bcma.dev)
+   panic("Failed to setup SoC device\n");
+
err = bcma_host_soc_init(_bus.bcma);
if (err)
panic("Failed to initialize BCMA bus (err %d)", err);

Re: [PATCH AUTOSEL 4.19 28/57] watchdog: lantiq: update register names to better match spec

[Hauke Mehrtens]

On 11/04/2018 02:51 PM, Sasha Levin wrote:
> From: Hauke Mehrtens 
> 
> [ Upstream commit 1f59f8aff98f200af7a6882184add7b85f5da741 ]
> 
> Some of the names of the bits were confusing to me.
> Now the bits share the same prefix as the register they are set on.
> 
> The LTQ_WDT_CR_PWL register (bits 26:25) is the pre warning limit and it
> does not turn anything on. It has 4 possible divers 1/2, 1/4, 1/8 and
> 1/16, this drivers only uses 1/16.
> The LTQ_WDT_CR_CLKDIV register bits(25:24) is only configuring a clock
> divers and do not turn any thing on too, all possible values are valid
> dividers.
> Using the LTQ_WDT_SR prefix is also wrong these bits are used in the
> LTQ_WDT_CR registers, SR is the status register which is read only.
> 
> This uses GENMASK where it is a mask and it uses shifts when a value is
> written to some bits.
> 
> Signed-off-by: Hauke Mehrtens 
> Reviewed-by: Guenter Roeck 
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Wim Van Sebroeck 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/watchdog/lantiq_wdt.c | 36 ++-
>  1 file changed, 19 insertions(+), 17 deletions(-)

This does not really fix a bug, I think it is not worth it to backport this.

Hauke



signature.asc
Description: OpenPGP digital signature

Re: [PATCH AUTOSEL 4.19 28/57] watchdog: lantiq: update register names to better match spec

[Hauke Mehrtens]

On 11/04/2018 02:51 PM, Sasha Levin wrote:
> From: Hauke Mehrtens 
> 
> [ Upstream commit 1f59f8aff98f200af7a6882184add7b85f5da741 ]
> 
> Some of the names of the bits were confusing to me.
> Now the bits share the same prefix as the register they are set on.
> 
> The LTQ_WDT_CR_PWL register (bits 26:25) is the pre warning limit and it
> does not turn anything on. It has 4 possible divers 1/2, 1/4, 1/8 and
> 1/16, this drivers only uses 1/16.
> The LTQ_WDT_CR_CLKDIV register bits(25:24) is only configuring a clock
> divers and do not turn any thing on too, all possible values are valid
> dividers.
> Using the LTQ_WDT_SR prefix is also wrong these bits are used in the
> LTQ_WDT_CR registers, SR is the status register which is read only.
> 
> This uses GENMASK where it is a mask and it uses shifts when a value is
> written to some bits.
> 
> Signed-off-by: Hauke Mehrtens 
> Reviewed-by: Guenter Roeck 
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Wim Van Sebroeck 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/watchdog/lantiq_wdt.c | 36 ++-
>  1 file changed, 19 insertions(+), 17 deletions(-)

This does not really fix a bug, I think it is not worth it to backport this.

Hauke



signature.asc
Description: OpenPGP digital signature

Re: Adding a Basic DT for the Linksys ea6500 v2 wireless home router

[Hauke Mehrtens]

On 10/04/2018 11:08 PM, René Kjellerup wrote:
> Hi Hauke,
> 
> thank you for suggesting adding the dts patch to mainline kernel,
> so here it is.
> I feel Rafal technically still have the copyrights, this is pretty
> much just a few string updates for the ea6500v2. However with this
> dts in latest OpenWrt 18.06 loads and installs on my device.
> 
> I will be available to do more testing should it be required.
> 
> Regrads
> Rene Kjellerup
> --
> -- as life grows older, I gain experience.
> -- http://www.alchemiestick.net/
> 

Hi Rene,

Please send you patch inline in the mail and not as an attachment, I
would suggest to use "git send-email" for sending the patch.

Adding Rafal as copyright owner is ok, like you did it now. You could
mention in the file header on which dts file this is based.

Hauke



signature.asc
Description: OpenPGP digital signature

Re: Adding a Basic DT for the Linksys ea6500 v2 wireless home router

[Hauke Mehrtens]

On 10/04/2018 11:08 PM, René Kjellerup wrote:
> Hi Hauke,
> 
> thank you for suggesting adding the dts patch to mainline kernel,
> so here it is.
> I feel Rafal technically still have the copyrights, this is pretty
> much just a few string updates for the ea6500v2. However with this
> dts in latest OpenWrt 18.06 loads and installs on my device.
> 
> I will be available to do more testing should it be required.
> 
> Regrads
> Rene Kjellerup
> --
> -- as life grows older, I gain experience.
> -- http://www.alchemiestick.net/
> 

Hi Rene,

Please send you patch inline in the mail and not as an attachment, I
would suggest to use "git send-email" for sending the patch.

Adding Rafal as copyright owner is ok, like you did it now. You could
mention in the file header on which dts file this is based.

Hauke



signature.asc
Description: OpenPGP digital signature

[PATCH] phy: lantiq: Fix compile warning

[Hauke Mehrtens]

This local variable is unused, remove it.

Fixes: dea54fbad332 ("phy: Add an USB PHY driver for the Lantiq SoCs using the 
RCU module")
Signed-off-by: Hauke Mehrtens 
---
 drivers/phy/lantiq/phy-lantiq-rcu-usb2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c 
b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
index 986224fca9e9..5a180f71d8d4 100644
--- a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
+++ b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
@@ -156,7 +156,6 @@ static int ltq_rcu_usb2_of_parse(struct ltq_rcu_usb2_priv 
*priv,
 {
struct device *dev = priv->dev;
const __be32 *offset;
-   int ret;
 
priv->reg_bits = of_device_get_match_data(dev);
 
-- 
2.11.0

[PATCH] phy: lantiq: Fix compile warning

[Hauke Mehrtens]

This local variable is unused, remove it.

Fixes: dea54fbad332 ("phy: Add an USB PHY driver for the Lantiq SoCs using the 
RCU module")
Signed-off-by: Hauke Mehrtens 
---
 drivers/phy/lantiq/phy-lantiq-rcu-usb2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c 
b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
index 986224fca9e9..5a180f71d8d4 100644
--- a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
+++ b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
@@ -156,7 +156,6 @@ static int ltq_rcu_usb2_of_parse(struct ltq_rcu_usb2_priv 
*priv,
 {
struct device *dev = priv->dev;
const __be32 *offset;
-   int ret;
 
priv->reg_bits = of_device_get_match_data(dev);
 
-- 
2.11.0

Re: [PATCH] MIPS: BCM47XX: Enable USB power on Netgear WNDR3400v3

[Hauke Mehrtens]

On 08/19/2018 09:20 PM, Tuomas Tynkkynen wrote:
> Setting GPIO 21 high seems to be required to enable power to USB ports
> on the WNDR3400v3. As there is already similar code for WNR3500L,
> make the existing USB power GPIO code generic and use that.
> 
> Signed-off-by: Tuomas Tynkkynen 

I didn't runtime tested this and didn't checked the board, but this
looks good.

Acked-by: Hauke Mehrtens 

> ---
>  arch/mips/bcm47xx/workarounds.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c
> index 1a8a07e7a563..46eddbec8d9f 100644
> --- a/arch/mips/bcm47xx/workarounds.c
> +++ b/arch/mips/bcm47xx/workarounds.c
> @@ -5,9 +5,8 @@
>  #include 
>  #include 
>  
> -static void __init bcm47xx_workarounds_netgear_wnr3500l(void)
> +static void __init bcm47xx_workarounds_enable_usb_power(int usb_power)
>  {
> - const int usb_power = 12;
>   int err;
>  
>   err = gpio_request_one(usb_power, GPIOF_OUT_INIT_HIGH, "usb_power");
> @@ -23,7 +22,10 @@ void __init bcm47xx_workarounds(void)
>  
>   switch (board) {
>   case BCM47XX_BOARD_NETGEAR_WNR3500L:
> - bcm47xx_workarounds_netgear_wnr3500l();
> + bcm47xx_workarounds_enable_usb_power(12);
> + break;
> + case BCM47XX_BOARD_NETGEAR_WNDR3400_V3:
> + bcm47xx_workarounds_enable_usb_power(21);
>   break;
>   default:
>   /* No workaround(s) needed */
> 

Re: [PATCH] MIPS: BCM47XX: Enable USB power on Netgear WNDR3400v3

[Hauke Mehrtens]

On 08/19/2018 09:20 PM, Tuomas Tynkkynen wrote:
> Setting GPIO 21 high seems to be required to enable power to USB ports
> on the WNDR3400v3. As there is already similar code for WNR3500L,
> make the existing USB power GPIO code generic and use that.
> 
> Signed-off-by: Tuomas Tynkkynen 

I didn't runtime tested this and didn't checked the board, but this
looks good.

Acked-by: Hauke Mehrtens 

> ---
>  arch/mips/bcm47xx/workarounds.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c
> index 1a8a07e7a563..46eddbec8d9f 100644
> --- a/arch/mips/bcm47xx/workarounds.c
> +++ b/arch/mips/bcm47xx/workarounds.c
> @@ -5,9 +5,8 @@
>  #include 
>  #include 
>  
> -static void __init bcm47xx_workarounds_netgear_wnr3500l(void)
> +static void __init bcm47xx_workarounds_enable_usb_power(int usb_power)
>  {
> - const int usb_power = 12;
>   int err;
>  
>   err = gpio_request_one(usb_power, GPIOF_OUT_INIT_HIGH, "usb_power");
> @@ -23,7 +22,10 @@ void __init bcm47xx_workarounds(void)
>  
>   switch (board) {
>   case BCM47XX_BOARD_NETGEAR_WNR3500L:
> - bcm47xx_workarounds_netgear_wnr3500l();
> + bcm47xx_workarounds_enable_usb_power(12);
> + break;
> + case BCM47XX_BOARD_NETGEAR_WNDR3400_V3:
> + bcm47xx_workarounds_enable_usb_power(21);
>   break;
>   default:
>   /* No workaround(s) needed */
> 

Re: [PATCHv2 2/2] phy:phy-lantiq-rcu-usb2: Use PTR_ERR_OR_ZERO to replace the open coded version

[Hauke Mehrtens]

On 08/16/2018 05:58 PM, zhong jiang wrote:
> PTR_ERR_OR_ZERO has implemented the if(IS_ERR(...)) + PTR_ERR, So
> just replace them rather than duplicating its implement.
> 
> Signed-off-by: zhong jiang 

Acked-by: Hauke Mehrtens 

> ---
>  drivers/phy/lantiq/phy-lantiq-rcu-usb2.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c 
> b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
> index 986224f..a918c5b 100644
> --- a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
> +++ b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
> @@ -196,10 +196,8 @@ static int ltq_rcu_usb2_of_parse(struct 
> ltq_rcu_usb2_priv *priv,
>   }
>  
>   priv->phy_reset = devm_reset_control_get_optional(dev, "phy");
> - if (IS_ERR(priv->phy_reset))
> - return PTR_ERR(priv->phy_reset);
>  
> - return 0;
> + return PTR_ERR_OR_ZERO(priv->phy_reset);
>  }
>  
>  static int ltq_rcu_usb2_phy_probe(struct platform_device *pdev)
> 

Re: [PATCHv2 2/2] phy:phy-lantiq-rcu-usb2: Use PTR_ERR_OR_ZERO to replace the open coded version

[Hauke Mehrtens]

On 08/16/2018 05:58 PM, zhong jiang wrote:
> PTR_ERR_OR_ZERO has implemented the if(IS_ERR(...)) + PTR_ERR, So
> just replace them rather than duplicating its implement.
> 
> Signed-off-by: zhong jiang 

Acked-by: Hauke Mehrtens 

> ---
>  drivers/phy/lantiq/phy-lantiq-rcu-usb2.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c 
> b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
> index 986224f..a918c5b 100644
> --- a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
> +++ b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c
> @@ -196,10 +196,8 @@ static int ltq_rcu_usb2_of_parse(struct 
> ltq_rcu_usb2_priv *priv,
>   }
>  
>   priv->phy_reset = devm_reset_control_get_optional(dev, "phy");
> - if (IS_ERR(priv->phy_reset))
> - return PTR_ERR(priv->phy_reset);
>  
> - return 0;
> + return PTR_ERR_OR_ZERO(priv->phy_reset);
>  }
>  
>  static int ltq_rcu_usb2_phy_probe(struct platform_device *pdev)
> 

Re: [PATCH v2 04/18] MIPS: dts: Add initial support for Intel MIPS SoCs

[Hauke Mehrtens]

On 08/03/2018 05:02 AM, Songjun Wu wrote:
> From: Hua Ma 
> 
> Add dts files to support Intel MIPS SoCs:
> - xrx500.dtsi is the chip dts
> - easy350_anywan.dts is the board dts
> 
> Signed-off-by: Hua Ma 
> Signed-off-by: Songjun Wu 
> ---
> 
> Changes in v2:
> - New patch split from previous patch
> - The memory address is changed to @2000
> - Update to obj-$(CONFIG_BUILTIN_DTB) as per commit fca3aa166422
> 
>  arch/mips/boot/dts/Makefile  |  1 +
>  arch/mips/boot/dts/intel-mips/Makefile   |  4 ++
>  arch/mips/boot/dts/intel-mips/easy350_anywan.dts | 26 ++
>  arch/mips/boot/dts/intel-mips/xrx500.dtsi| 66 
> 
>  4 files changed, 97 insertions(+)
>  create mode 100644 arch/mips/boot/dts/intel-mips/Makefile
>  create mode 100644 arch/mips/boot/dts/intel-mips/easy350_anywan.dts
>  create mode 100644 arch/mips/boot/dts/intel-mips/xrx500.dtsi
> 
> diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
> index 1e79cab8e269..05f52f279047 100644
> --- a/arch/mips/boot/dts/Makefile
> +++ b/arch/mips/boot/dts/Makefile
> @@ -3,6 +3,7 @@ subdir-y  += brcm
>  subdir-y += cavium-octeon
>  subdir-y += img
>  subdir-y += ingenic
> +subdir-y += intel-mips
>  subdir-y += lantiq
>  subdir-y += mscc
>  subdir-y += mti
> diff --git a/arch/mips/boot/dts/intel-mips/Makefile 
> b/arch/mips/boot/dts/intel-mips/Makefile
> new file mode 100644
> index ..adfaa07c
> --- /dev/null
> +++ b/arch/mips/boot/dts/intel-mips/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_DTB_INTEL_MIPS_GRX500)  += easy350_anywan.dtb
> +
> +obj-$(CONFIG_BUILTIN_DTB)+= $(addsuffix .o, $(dtb-y))
> diff --git a/arch/mips/boot/dts/intel-mips/easy350_anywan.dts 
> b/arch/mips/boot/dts/intel-mips/easy350_anywan.dts
> new file mode 100644
> index ..e5e95f90c5e7
> --- /dev/null
> +++ b/arch/mips/boot/dts/intel-mips/easy350_anywan.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +
> +#include 
> +#include 
> +
> +#include "xrx500.dtsi"
> +
> +/ {
> + model = "EASY350 ANYWAN (GRX350) Main model";

Main model can be removed, it does not identify the board.

> + compatible = "intel,easy350-anywan";

I think this should be
compatible = "intel,easy350-anywan", "intel,xrx500";

Are there different revisions of the EASY350 Anywan board or only of the
EASY550 board?There are at least some differences in the power supply on
the EASY550 V1 and EASY550 V2 board. I would suggest to be here very
specific to make it easier when adding more boards.

> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + bootargs = "earlycon=lantiq,0x1660 clk_ignore_unused";

What happens when you remove clk_ignore_unused?
If it crashes we should probably define some of the clock to be always
active.

> + stdout-path = "serial0";
> + };
> +
> + memory@2000 {
> + device_type = "memory";
> + reg = <0x2000 0x0e00>;
> + };
> +};
> diff --git a/arch/mips/boot/dts/intel-mips/xrx500.dtsi 
> b/arch/mips/boot/dts/intel-mips/xrx500.dtsi
> new file mode 100644
> index ..54c5f8f8b604
> --- /dev/null
> +++ b/arch/mips/boot/dts/intel-mips/xrx500.dtsi
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "intel,xrx500";
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "mti,interaptiv";
> + clocks = < CLK_CPU>;
> + reg = <0>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "mti,interaptiv";
> + reg = <1>;
> + };
> + };
> +
> + cpu_intc: interrupt-controller {
> + compatible = "mti,cpu-interrupt-controller";
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
> + gic: gic@1232 {
> + compatible = "mti,gic";
> + reg = <0x1232 0x2>;
> +
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + /*
> +  * Declare the interrupt-parent even though the mti,gic
> +  * binding doesn't require it, such that the kernel can
> +  * figure out that cpu_intc is the root interrupt
> +  * controller & should be probed first.
> +  */
> + interrupt-parent = <_intc>;
> + mti,reserved-ipi-vectors = <56 8>;
> + };
> +
> + cgu: cgu@1620 {
> + compatible = "intel,grx500-cgu", "syscon";
> + reg = <0x1620 0x200>;
> + 

Re: [PATCH v2 04/18] MIPS: dts: Add initial support for Intel MIPS SoCs

[Hauke Mehrtens]

On 08/03/2018 05:02 AM, Songjun Wu wrote:
> From: Hua Ma 
> 
> Add dts files to support Intel MIPS SoCs:
> - xrx500.dtsi is the chip dts
> - easy350_anywan.dts is the board dts
> 
> Signed-off-by: Hua Ma 
> Signed-off-by: Songjun Wu 
> ---
> 
> Changes in v2:
> - New patch split from previous patch
> - The memory address is changed to @2000
> - Update to obj-$(CONFIG_BUILTIN_DTB) as per commit fca3aa166422
> 
>  arch/mips/boot/dts/Makefile  |  1 +
>  arch/mips/boot/dts/intel-mips/Makefile   |  4 ++
>  arch/mips/boot/dts/intel-mips/easy350_anywan.dts | 26 ++
>  arch/mips/boot/dts/intel-mips/xrx500.dtsi| 66 
> 
>  4 files changed, 97 insertions(+)
>  create mode 100644 arch/mips/boot/dts/intel-mips/Makefile
>  create mode 100644 arch/mips/boot/dts/intel-mips/easy350_anywan.dts
>  create mode 100644 arch/mips/boot/dts/intel-mips/xrx500.dtsi
> 
> diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
> index 1e79cab8e269..05f52f279047 100644
> --- a/arch/mips/boot/dts/Makefile
> +++ b/arch/mips/boot/dts/Makefile
> @@ -3,6 +3,7 @@ subdir-y  += brcm
>  subdir-y += cavium-octeon
>  subdir-y += img
>  subdir-y += ingenic
> +subdir-y += intel-mips
>  subdir-y += lantiq
>  subdir-y += mscc
>  subdir-y += mti
> diff --git a/arch/mips/boot/dts/intel-mips/Makefile 
> b/arch/mips/boot/dts/intel-mips/Makefile
> new file mode 100644
> index ..adfaa07c
> --- /dev/null
> +++ b/arch/mips/boot/dts/intel-mips/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_DTB_INTEL_MIPS_GRX500)  += easy350_anywan.dtb
> +
> +obj-$(CONFIG_BUILTIN_DTB)+= $(addsuffix .o, $(dtb-y))
> diff --git a/arch/mips/boot/dts/intel-mips/easy350_anywan.dts 
> b/arch/mips/boot/dts/intel-mips/easy350_anywan.dts
> new file mode 100644
> index ..e5e95f90c5e7
> --- /dev/null
> +++ b/arch/mips/boot/dts/intel-mips/easy350_anywan.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +
> +#include 
> +#include 
> +
> +#include "xrx500.dtsi"
> +
> +/ {
> + model = "EASY350 ANYWAN (GRX350) Main model";

Main model can be removed, it does not identify the board.

> + compatible = "intel,easy350-anywan";

I think this should be
compatible = "intel,easy350-anywan", "intel,xrx500";

Are there different revisions of the EASY350 Anywan board or only of the
EASY550 board?There are at least some differences in the power supply on
the EASY550 V1 and EASY550 V2 board. I would suggest to be here very
specific to make it easier when adding more boards.

> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + bootargs = "earlycon=lantiq,0x1660 clk_ignore_unused";

What happens when you remove clk_ignore_unused?
If it crashes we should probably define some of the clock to be always
active.

> + stdout-path = "serial0";
> + };
> +
> + memory@2000 {
> + device_type = "memory";
> + reg = <0x2000 0x0e00>;
> + };
> +};
> diff --git a/arch/mips/boot/dts/intel-mips/xrx500.dtsi 
> b/arch/mips/boot/dts/intel-mips/xrx500.dtsi
> new file mode 100644
> index ..54c5f8f8b604
> --- /dev/null
> +++ b/arch/mips/boot/dts/intel-mips/xrx500.dtsi
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "intel,xrx500";
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "mti,interaptiv";
> + clocks = < CLK_CPU>;
> + reg = <0>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "mti,interaptiv";
> + reg = <1>;
> + };
> + };
> +
> + cpu_intc: interrupt-controller {
> + compatible = "mti,cpu-interrupt-controller";
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
> + gic: gic@1232 {
> + compatible = "mti,gic";
> + reg = <0x1232 0x2>;
> +
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + /*
> +  * Declare the interrupt-parent even though the mti,gic
> +  * binding doesn't require it, such that the kernel can
> +  * figure out that cpu_intc is the root interrupt
> +  * controller & should be probed first.
> +  */
> + interrupt-parent = <_intc>;
> + mti,reserved-ipi-vectors = <56 8>;
> + };
> +
> + cgu: cgu@1620 {
> + compatible = "intel,grx500-cgu", "syscon";
> + reg = <0x1620 0x200>;
> + 

Re: [PATCH v2 14/18] serial: intel: Add CCF support

[Hauke Mehrtens]

On 08/03/2018 12:30 PM, Greg Kroah-Hartman wrote:
> On Fri, Aug 03, 2018 at 03:33:38PM +0800, Wu, Songjun wrote:
>>
>>
>> On 8/3/2018 1:56 PM, Greg Kroah-Hartman wrote:
>>> On Fri, Aug 03, 2018 at 11:02:33AM +0800, Songjun Wu wrote:
 Previous implementation uses platform-dependent API to get the clock.
 Those functions are not available for other SoC which uses the same IP.
 The CCF (Common Clock Framework) have an abstraction based APIs for
 clock. In future, the platform specific code will be removed when the
 legacy soc use CCF as well.
 Change to use CCF APIs to get clock and rate. So that different SoCs
 can use the same driver.

 Signed-off-by: Songjun Wu 
 ---

 Changes in v2: None

   drivers/tty/serial/lantiq.c | 11 +++
   1 file changed, 11 insertions(+)

 diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
 index 36479d66fb7c..35518ab3a80d 100644
 --- a/drivers/tty/serial/lantiq.c
 +++ b/drivers/tty/serial/lantiq.c
 @@ -26,7 +26,9 @@
   #include 
   #include 
 +#ifdef CONFIG_LANTIQ
   #include 
 +#endif
>>> That is never how you do this in Linux, you know better.
>>>
>>> Please go and get this patchset reviewed and signed-off-by from other
>>> internal Intel kernel developers before resending it next time.  It is
>>> their job to find and fix your basic errors like this, not ours.
>> Thank you for your comment.
>> Actually, we have discussed this issue internally.
>> We put the reason why we use "#ifdef CONFIG_LANTIQ" preprocessor in commit
>> message in "[PATCH v2 08/18] serial: intel: Get serial id from dts".
>> Please refer the commit message below.
>>
>> "#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC
>> macro is defined in lantiq_soc.h.
>> lantiq_soc.h is in arch path for legacy product support.
>>
>> arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h
>>
>> If "#ifdef preprocessor" is changed to
>> "if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled,
>> code using LTQ_EARLY_ASC is compiled.
>> Compilation will fail for no LTQ_EARLY_ASC defined.
> 
> Sorry, but no.  Why is this one tiny driver/chip somehow more "special"
> than all of the tens of thousands of other devices we support to warrent
> it getting some sort of special exception to do things differently?
> What happens to the next device that wants to do it this way?
> 
> Our coding style and rules are there for a reason, do not violate them
> thinking your device is the only one that matters.
> 
> Do it properly, again, you all know better than this.
> 
> greg k-h
> 
Hi Greg,

The problem is that the Lantiq SoC code in arch/mips/lantiq does not use
the common clock framework, but it uses the clk framework directly. It
defines CONFIG_HAVE_CLK and CONFIG_CLKDEV_LOOKUP, but not
CONFIG_COMMON_CLK. The xRX500 SoC which is being added here is about 2
generations more recent than the VR9/xRX200 SoC which is the latest
which is supported by the code in arch/mips/lantiq. With this new SoC we
switched to the common clock framework. This driver is used by the older
SoC and also by the new ones because this IP core is pretty similar in
all the SoCs.
This patch makes it possible to use it with the legacy lantiq code and
also with the common clock framework. I see multiple options to fix this
problem.

1. The current approach to have it as a compile variant for a) legacy
lantiq arch code without common clock framework and b) support for SoCs
using the common clock framework.
2. Convert the lantiq arch code to the common clock framework. This
would be a good approach, but it need some efforts.
3. Remove the arch/mips/lantiq code. There are still users of this code.
4. Use the old APIs also for the new xRX500 SoC, I do not like this
approach.
5. Move lantiq_soc.h to somewhere in include/linux/ so it is globally
available and provide some better wrapper code.

Hauke



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 14/18] serial: intel: Add CCF support

[Hauke Mehrtens]

On 08/03/2018 12:30 PM, Greg Kroah-Hartman wrote:
> On Fri, Aug 03, 2018 at 03:33:38PM +0800, Wu, Songjun wrote:
>>
>>
>> On 8/3/2018 1:56 PM, Greg Kroah-Hartman wrote:
>>> On Fri, Aug 03, 2018 at 11:02:33AM +0800, Songjun Wu wrote:
 Previous implementation uses platform-dependent API to get the clock.
 Those functions are not available for other SoC which uses the same IP.
 The CCF (Common Clock Framework) have an abstraction based APIs for
 clock. In future, the platform specific code will be removed when the
 legacy soc use CCF as well.
 Change to use CCF APIs to get clock and rate. So that different SoCs
 can use the same driver.

 Signed-off-by: Songjun Wu 
 ---

 Changes in v2: None

   drivers/tty/serial/lantiq.c | 11 +++
   1 file changed, 11 insertions(+)

 diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
 index 36479d66fb7c..35518ab3a80d 100644
 --- a/drivers/tty/serial/lantiq.c
 +++ b/drivers/tty/serial/lantiq.c
 @@ -26,7 +26,9 @@
   #include 
   #include 
 +#ifdef CONFIG_LANTIQ
   #include 
 +#endif
>>> That is never how you do this in Linux, you know better.
>>>
>>> Please go and get this patchset reviewed and signed-off-by from other
>>> internal Intel kernel developers before resending it next time.  It is
>>> their job to find and fix your basic errors like this, not ours.
>> Thank you for your comment.
>> Actually, we have discussed this issue internally.
>> We put the reason why we use "#ifdef CONFIG_LANTIQ" preprocessor in commit
>> message in "[PATCH v2 08/18] serial: intel: Get serial id from dts".
>> Please refer the commit message below.
>>
>> "#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC
>> macro is defined in lantiq_soc.h.
>> lantiq_soc.h is in arch path for legacy product support.
>>
>> arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h
>>
>> If "#ifdef preprocessor" is changed to
>> "if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled,
>> code using LTQ_EARLY_ASC is compiled.
>> Compilation will fail for no LTQ_EARLY_ASC defined.
> 
> Sorry, but no.  Why is this one tiny driver/chip somehow more "special"
> than all of the tens of thousands of other devices we support to warrent
> it getting some sort of special exception to do things differently?
> What happens to the next device that wants to do it this way?
> 
> Our coding style and rules are there for a reason, do not violate them
> thinking your device is the only one that matters.
> 
> Do it properly, again, you all know better than this.
> 
> greg k-h
> 
Hi Greg,

The problem is that the Lantiq SoC code in arch/mips/lantiq does not use
the common clock framework, but it uses the clk framework directly. It
defines CONFIG_HAVE_CLK and CONFIG_CLKDEV_LOOKUP, but not
CONFIG_COMMON_CLK. The xRX500 SoC which is being added here is about 2
generations more recent than the VR9/xRX200 SoC which is the latest
which is supported by the code in arch/mips/lantiq. With this new SoC we
switched to the common clock framework. This driver is used by the older
SoC and also by the new ones because this IP core is pretty similar in
all the SoCs.
This patch makes it possible to use it with the legacy lantiq code and
also with the common clock framework. I see multiple options to fix this
problem.

1. The current approach to have it as a compile variant for a) legacy
lantiq arch code without common clock framework and b) support for SoCs
using the common clock framework.
2. Convert the lantiq arch code to the common clock framework. This
would be a good approach, but it need some efforts.
3. Remove the arch/mips/lantiq code. There are still users of this code.
4. Use the old APIs also for the new xRX500 SoC, I do not like this
approach.
5. Move lantiq_soc.h to somewhere in include/linux/ so it is globally
available and provide some better wrapper code.

Hauke



signature.asc
Description: OpenPGP digital signature

[PATCH] freevxfs: Do not inline vxfs_put_page()

[Hauke Mehrtens]

vxfs_put_page() is not implemented in a header file, but in a normal c
file and used in multiple functions in different c files. Remove the
inline attribute as it does not make sense here and causes a link error
when LTO is activated.

Signed-off-by: Hauke Mehrtens 
---
 fs/freevxfs/vxfs_subr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/freevxfs/vxfs_subr.c b/fs/freevxfs/vxfs_subr.c
index e806694d4145..8e213cce586f 100644
--- a/fs/freevxfs/vxfs_subr.c
+++ b/fs/freevxfs/vxfs_subr.c
@@ -46,7 +46,7 @@ const struct address_space_operations vxfs_aops = {
.bmap = vxfs_bmap,
 };
 
-inline void
+void
 vxfs_put_page(struct page *pp)
 {
kunmap(pp);
-- 
2.11.0

[PATCH] freevxfs: Do not inline vxfs_put_page()

[Hauke Mehrtens]

vxfs_put_page() is not implemented in a header file, but in a normal c
file and used in multiple functions in different c files. Remove the
inline attribute as it does not make sense here and causes a link error
when LTO is activated.

Signed-off-by: Hauke Mehrtens 
---
 fs/freevxfs/vxfs_subr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/freevxfs/vxfs_subr.c b/fs/freevxfs/vxfs_subr.c
index e806694d4145..8e213cce586f 100644
--- a/fs/freevxfs/vxfs_subr.c
+++ b/fs/freevxfs/vxfs_subr.c
@@ -46,7 +46,7 @@ const struct address_space_operations vxfs_aops = {
.bmap = vxfs_bmap,
 };
 
-inline void
+void
 vxfs_put_page(struct page *pp)
 {
kunmap(pp);
-- 
2.11.0

Re: [PATCH] ARM: dts: BCM5301X: Relicense most DTS files to the GPL 2.0+ / MIT

[Hauke Mehrtens]

On 05/02/2018 04:11 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> These files were created and ever touched by a group of three people
> only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC.
> 
> Introducing and discussing SPDX-License-Identifier resulted in a
> conclusion that ISC is a not recommended license (see also a
> license-rules.rst). Moveover an old e-mail from Alan Cox was pointed
> which explained that dual licensing is a safer solution than depending
> on a common compatibility belief.
> 
> This commit switches most of BCM5301X DTS files to dual licensing using:
> 1) GPL 2.0+ to make sure they are compatible with Linux kernel
> 2) MIT to allow sharing with more permissive projects
> Both licenses belong to the preferred ones (see LICENSES/preferred/).
> 
> An attempt to relicense remaining files will be made separately and will
> require approve from more/other developers.
> 
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>

Acked-by: Hauke Mehrtens <ha...@hauke-m.de>

> ---
>  arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts| 13 +
>  arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts| 13 +
>  arch/arm/boot/dts/bcm4708-linksys-ea6300-v1.dts|  3 +--
>  arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts   |  3 +--
>  arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts   |  3 +--
>  arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 13 +
>  arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts  |  3 +--
>  arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts| 13 +
>  arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 13 +
>  arch/arm/boot/dts/bcm47081-luxul-xap-1410.dts  |  3 +--
>  arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts  |  3 +--
>  arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts |  3 +--
>  arch/arm/boot/dts/bcm4709-linksys-ea9200.dts   |  3 +--
>  arch/arm/boot/dts/bcm4709-netgear-r7000.dts| 13 +
>  arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts  |  3 +--
>  arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts  | 13 +
>  arch/arm/boot/dts/bcm47094-linksys-panamera.dts|  3 +--
>  arch/arm/boot/dts/bcm47094-luxul-abr-4500.dts  |  3 +--
>  arch/arm/boot/dts/bcm47094-luxul-xbr-4500.dts  |  3 +--
>  arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts  |  3 +--
>  arch/arm/boot/dts/bcm47094-netgear-r8500.dts   |  3 +--
>  arch/arm/boot/dts/bcm5301x-nand-cs0-bch1.dtsi  |  3 +--
>  arch/arm/boot/dts/bcm5301x-nand-cs0-bch4.dtsi  |  3 +--
>  arch/arm/boot/dts/bcm5301x-nand-cs0-bch8.dtsi  |  3 +--
>  arch/arm/boot/dts/bcm5301x-nand-cs0.dtsi   |  3 +--
>  25 files changed, 25 insertions(+), 120 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts 
> b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> index 4175174e589a..ff2e551b9058 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> @@ -1,20 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>  /*
>   * Broadcom BCM470X / BCM5301X ARM platform code.
>   * DTS for Asus RT-AC56U
>   *
>   * Copyright (C) 2015 Rafał Miłecki <zaj...@gmail.com>
> - *
> - * Permission to use, copy, modify, and/or distribute this software for any
> - * purpose with or without fee is hereby granted, provided that the above
> - * copyright notice and this permission notice appear in all copies.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES 
> WITH
> - * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF 
> MERCHANTABILITY
> - * AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, 
> DIRECT,
> - * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING 
> FROM
> - * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
> - * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> - * PERFORMANCE OF THIS SOFTWARE.
>   */
>  
>  /dts-v1/;
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts 
> b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> index 8fa033fea959..3bcc03788f38 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> @@ -1,20 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>  /*
>   * Broadcom BCM470X / BCM5301X ARM platform code.
>   * DTS for Asus RT-AC68U
>   *
>   * Copyright (C) 2015 Rafał Miłecki <zaj...@gmail.com>
> - *
> - * Permission to use, copy, modify, and/or distribute this software for any
> - * purpose with or without fee is hereby granted, provided that the above
&

Re: [PATCH] ARM: dts: BCM5301X: Relicense most DTS files to the GPL 2.0+ / MIT

[Hauke Mehrtens]

On 05/02/2018 04:11 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> These files were created and ever touched by a group of three people
> only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC.
> 
> Introducing and discussing SPDX-License-Identifier resulted in a
> conclusion that ISC is a not recommended license (see also a
> license-rules.rst). Moveover an old e-mail from Alan Cox was pointed
> which explained that dual licensing is a safer solution than depending
> on a common compatibility belief.
> 
> This commit switches most of BCM5301X DTS files to dual licensing using:
> 1) GPL 2.0+ to make sure they are compatible with Linux kernel
> 2) MIT to allow sharing with more permissive projects
> Both licenses belong to the preferred ones (see LICENSES/preferred/).
> 
> An attempt to relicense remaining files will be made separately and will
> require approve from more/other developers.
> 
> Signed-off-by: Rafał Miłecki 

Acked-by: Hauke Mehrtens 

> ---
>  arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts| 13 +
>  arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts| 13 +
>  arch/arm/boot/dts/bcm4708-linksys-ea6300-v1.dts|  3 +--
>  arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts   |  3 +--
>  arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts   |  3 +--
>  arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 13 +
>  arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts  |  3 +--
>  arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts| 13 +
>  arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 13 +
>  arch/arm/boot/dts/bcm47081-luxul-xap-1410.dts  |  3 +--
>  arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts  |  3 +--
>  arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts |  3 +--
>  arch/arm/boot/dts/bcm4709-linksys-ea9200.dts   |  3 +--
>  arch/arm/boot/dts/bcm4709-netgear-r7000.dts| 13 +
>  arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts  |  3 +--
>  arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts  | 13 +
>  arch/arm/boot/dts/bcm47094-linksys-panamera.dts|  3 +--
>  arch/arm/boot/dts/bcm47094-luxul-abr-4500.dts  |  3 +--
>  arch/arm/boot/dts/bcm47094-luxul-xbr-4500.dts  |  3 +--
>  arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts  |  3 +--
>  arch/arm/boot/dts/bcm47094-netgear-r8500.dts   |  3 +--
>  arch/arm/boot/dts/bcm5301x-nand-cs0-bch1.dtsi  |  3 +--
>  arch/arm/boot/dts/bcm5301x-nand-cs0-bch4.dtsi  |  3 +--
>  arch/arm/boot/dts/bcm5301x-nand-cs0-bch8.dtsi  |  3 +--
>  arch/arm/boot/dts/bcm5301x-nand-cs0.dtsi   |  3 +--
>  25 files changed, 25 insertions(+), 120 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts 
> b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> index 4175174e589a..ff2e551b9058 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> @@ -1,20 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>  /*
>   * Broadcom BCM470X / BCM5301X ARM platform code.
>   * DTS for Asus RT-AC56U
>   *
>   * Copyright (C) 2015 Rafał Miłecki 
> - *
> - * Permission to use, copy, modify, and/or distribute this software for any
> - * purpose with or without fee is hereby granted, provided that the above
> - * copyright notice and this permission notice appear in all copies.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES 
> WITH
> - * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF 
> MERCHANTABILITY
> - * AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, 
> DIRECT,
> - * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING 
> FROM
> - * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
> - * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> - * PERFORMANCE OF THIS SOFTWARE.
>   */
>  
>  /dts-v1/;
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts 
> b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> index 8fa033fea959..3bcc03788f38 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> @@ -1,20 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>  /*
>   * Broadcom BCM470X / BCM5301X ARM platform code.
>   * DTS for Asus RT-AC68U
>   *
>   * Copyright (C) 2015 Rafał Miłecki 
> - *
> - * Permission to use, copy, modify, and/or distribute this software for any
> - * purpose with or without fee is hereby granted, provided that the above
> - * copyright notice and this permission notice appear in all copies.
> - *
> - * THE SOFTWARE IS PROVIDED &q

Re: [PATCH] MIPS: lantiq: gphy: Drop reboot/remove reset asserts

[Hauke Mehrtens]

On 04/08/2018 10:30 AM, Mathias Kresin wrote:
> While doing a global software reset, these bits are not cleared and let
> some bootloader fail to initialise the GPHYs. The bootloader don't
> expect the GPHYs in reset, as they aren't during power on.
> 
> The asserts were a workaround for a wrong syscon-reboot mask. With a
> mask set which includes the GPHY resets, these resets aren't required
> any more.
> 
> Fixes: 126534141b45 ("MIPS: lantiq: Add a GPHY driver which uses the RCU 
> syscon-mfd")
> Cc: sta...@vger.kernel.org # 4.14+
> Signed-off-by: Mathias Kresin <d...@kresin.me>

Acked-by: Hauke Mehrtens <ha...@hauke-m.de>

> ---
>  drivers/soc/lantiq/gphy.c | 34 --
>  1 file changed, 34 deletions(-)
> 
> diff --git a/drivers/soc/lantiq/gphy.c b/drivers/soc/lantiq/gphy.c
> index 8d86594..8c31ae7 100644
> --- a/drivers/soc/lantiq/gphy.c
> +++ b/drivers/soc/lantiq/gphy.c
> @@ -30,7 +30,6 @@ struct xway_gphy_priv {
>   struct clk *gphy_clk_gate;
>   struct reset_control *gphy_reset;
>   struct reset_control *gphy_reset2;
> - struct notifier_block gphy_reboot_nb;
>   void __iomem *membase;
>   char *fw_name;
>  };
> @@ -64,24 +63,6 @@ static const struct of_device_id xway_gphy_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, xway_gphy_match);
>  
> -static struct xway_gphy_priv *to_xway_gphy_priv(struct notifier_block *nb)
> -{
> - return container_of(nb, struct xway_gphy_priv, gphy_reboot_nb);
> -}
> -
> -static int xway_gphy_reboot_notify(struct notifier_block *reboot_nb,
> -unsigned long code, void *unused)
> -{
> - struct xway_gphy_priv *priv = to_xway_gphy_priv(reboot_nb);
> -
> - if (priv) {
> - reset_control_assert(priv->gphy_reset);
> - reset_control_assert(priv->gphy_reset2);
> - }
> -
> - return NOTIFY_DONE;
> -}
> -
>  static int xway_gphy_load(struct device *dev, struct xway_gphy_priv *priv,
> dma_addr_t *dev_addr)
>  {
> @@ -205,14 +186,6 @@ static int xway_gphy_probe(struct platform_device *pdev)
>   reset_control_deassert(priv->gphy_reset);
>   reset_control_deassert(priv->gphy_reset2);
>  
> - /* assert the gphy reset because it can hang after a reboot: */
> - priv->gphy_reboot_nb.notifier_call = xway_gphy_reboot_notify;
> - priv->gphy_reboot_nb.priority = -1;
> -
> - ret = register_reboot_notifier(>gphy_reboot_nb);
> - if (ret)
> - dev_warn(dev, "Failed to register reboot notifier\n");
> -
>   platform_set_drvdata(pdev, priv);
>  
>   return ret;
> @@ -224,17 +197,10 @@ static int xway_gphy_remove(struct platform_device 
> *pdev)
>   struct xway_gphy_priv *priv = platform_get_drvdata(pdev);
>   int ret;
>  
> - reset_control_assert(priv->gphy_reset);
> - reset_control_assert(priv->gphy_reset2);
> -
>   iowrite32be(0, priv->membase);
>  
>   clk_disable_unprepare(priv->gphy_clk_gate);
>  
> - ret = unregister_reboot_notifier(>gphy_reboot_nb);
> - if (ret)
> - dev_warn(dev, "Failed to unregister reboot notifier\n");
> -
>   return 0;
>  }
>  
> 

Re: [PATCH] MIPS: lantiq: gphy: Drop reboot/remove reset asserts

[Hauke Mehrtens]

On 04/08/2018 10:30 AM, Mathias Kresin wrote:
> While doing a global software reset, these bits are not cleared and let
> some bootloader fail to initialise the GPHYs. The bootloader don't
> expect the GPHYs in reset, as they aren't during power on.
> 
> The asserts were a workaround for a wrong syscon-reboot mask. With a
> mask set which includes the GPHY resets, these resets aren't required
> any more.
> 
> Fixes: 126534141b45 ("MIPS: lantiq: Add a GPHY driver which uses the RCU 
> syscon-mfd")
> Cc: sta...@vger.kernel.org # 4.14+
> Signed-off-by: Mathias Kresin 

Acked-by: Hauke Mehrtens 

> ---
>  drivers/soc/lantiq/gphy.c | 34 --
>  1 file changed, 34 deletions(-)
> 
> diff --git a/drivers/soc/lantiq/gphy.c b/drivers/soc/lantiq/gphy.c
> index 8d86594..8c31ae7 100644
> --- a/drivers/soc/lantiq/gphy.c
> +++ b/drivers/soc/lantiq/gphy.c
> @@ -30,7 +30,6 @@ struct xway_gphy_priv {
>   struct clk *gphy_clk_gate;
>   struct reset_control *gphy_reset;
>   struct reset_control *gphy_reset2;
> - struct notifier_block gphy_reboot_nb;
>   void __iomem *membase;
>   char *fw_name;
>  };
> @@ -64,24 +63,6 @@ static const struct of_device_id xway_gphy_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, xway_gphy_match);
>  
> -static struct xway_gphy_priv *to_xway_gphy_priv(struct notifier_block *nb)
> -{
> - return container_of(nb, struct xway_gphy_priv, gphy_reboot_nb);
> -}
> -
> -static int xway_gphy_reboot_notify(struct notifier_block *reboot_nb,
> -unsigned long code, void *unused)
> -{
> - struct xway_gphy_priv *priv = to_xway_gphy_priv(reboot_nb);
> -
> - if (priv) {
> - reset_control_assert(priv->gphy_reset);
> - reset_control_assert(priv->gphy_reset2);
> - }
> -
> - return NOTIFY_DONE;
> -}
> -
>  static int xway_gphy_load(struct device *dev, struct xway_gphy_priv *priv,
> dma_addr_t *dev_addr)
>  {
> @@ -205,14 +186,6 @@ static int xway_gphy_probe(struct platform_device *pdev)
>   reset_control_deassert(priv->gphy_reset);
>   reset_control_deassert(priv->gphy_reset2);
>  
> - /* assert the gphy reset because it can hang after a reboot: */
> - priv->gphy_reboot_nb.notifier_call = xway_gphy_reboot_notify;
> - priv->gphy_reboot_nb.priority = -1;
> -
> - ret = register_reboot_notifier(>gphy_reboot_nb);
> - if (ret)
> - dev_warn(dev, "Failed to register reboot notifier\n");
> -
>   platform_set_drvdata(pdev, priv);
>  
>   return ret;
> @@ -224,17 +197,10 @@ static int xway_gphy_remove(struct platform_device 
> *pdev)
>   struct xway_gphy_priv *priv = platform_get_drvdata(pdev);
>   int ret;
>  
> - reset_control_assert(priv->gphy_reset);
> - reset_control_assert(priv->gphy_reset2);
> -
>   iowrite32be(0, priv->membase);
>  
>   clk_disable_unprepare(priv->gphy_clk_gate);
>  
> - ret = unregister_reboot_notifier(>gphy_reboot_nb);
> - if (ret)
> - dev_warn(dev, "Failed to unregister reboot notifier\n");
> -
>   return 0;
>  }
>  
> 

Re: ipv6 redefinition build issue with 4.15-rc8

[Hauke Mehrtens]

On 01/18/2018 09:49 AM, Jonas Bonn wrote:
> On 01/17/2018 11:34 PM, Daniel Wagner wrote:
>>
>> On 01/17/2018 11:20 PM, Hauke Mehrtens wrote:
>>>
>>> Do we want to do any changes to the kernel header files? I do not know
>>> of any clean workaround to make this work, we can probably hack
>>> something for connman, but I think it is not worth the trouble.
>>
> 
> Well, it's not _just_ a connman issue, even though it apparently only
> shows up there, currently.
> 
> The problem with the kernel patch is that it now pulls in lib-compat.h
> which causes problems if it appears before netinet/in.h.  The following
> code is sufficient to show the issue:
> 
> #include 
> #include 
> #include 
> 
> int main(int argc, char** argv)
> {
> }
> 
> lib-compat checks if _NETINET_IN_H is defined... it's not.  So it
> defines __UAPI_DEF_IN6_ADDR.
> 
> Then netinet/in.h checks (via bits/in.h) if _LINUX_IN6_H is defined...
> it's not, so it defines the struct in6_addr (and others).
> 
> Then linux/in6.h gets pulled in and redefines the function because the
> earlier libc-compat check told it to do so.
> 
> If you comment out the first #include statement then it compiles fine.
> 
> libc-compat has, as you say, a requirement to be ordered after system
> headers in order for this to work... that doesn't feel terribly robust.
> 
> Anyway, the bug is probably in the glibc headers that are not checking
> the __UAPI_DEF*'s but rather using another broken heuristic... right
> place to fix this is probably there.
> 
> /Jonas

Florian Weimer said here "A lot of combinations are broken, especially
when kernel headers are included first.":
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1411192.html

That was on a older version of these two patches:
https://www.mail-archive.com/search?l=linux-kernel@vger.kernel.org=subject:%22Re%5C%3A+%5C%5Bmusl%5C%5D+Re%5C%3A+%5C%5BPATCH+resent%5C%5D+uapi+libc+compat%5C%3A+allow+non%5C-glibc+to+opt+out+of+uapi+definitions%22=newest=1

My understanding is that you should include libc headers before Linux
headers, otherwise you *could* run into problems. There are some
workarounds done to also support including Linux headers first, but they
are not working in all cases.

Hauke

Re: ipv6 redefinition build issue with 4.15-rc8

[Hauke Mehrtens]

On 01/18/2018 09:49 AM, Jonas Bonn wrote:
> On 01/17/2018 11:34 PM, Daniel Wagner wrote:
>>
>> On 01/17/2018 11:20 PM, Hauke Mehrtens wrote:
>>>
>>> Do we want to do any changes to the kernel header files? I do not know
>>> of any clean workaround to make this work, we can probably hack
>>> something for connman, but I think it is not worth the trouble.
>>
> 
> Well, it's not _just_ a connman issue, even though it apparently only
> shows up there, currently.
> 
> The problem with the kernel patch is that it now pulls in lib-compat.h
> which causes problems if it appears before netinet/in.h.  The following
> code is sufficient to show the issue:
> 
> #include 
> #include 
> #include 
> 
> int main(int argc, char** argv)
> {
> }
> 
> lib-compat checks if _NETINET_IN_H is defined... it's not.  So it
> defines __UAPI_DEF_IN6_ADDR.
> 
> Then netinet/in.h checks (via bits/in.h) if _LINUX_IN6_H is defined...
> it's not, so it defines the struct in6_addr (and others).
> 
> Then linux/in6.h gets pulled in and redefines the function because the
> earlier libc-compat check told it to do so.
> 
> If you comment out the first #include statement then it compiles fine.
> 
> libc-compat has, as you say, a requirement to be ordered after system
> headers in order for this to work... that doesn't feel terribly robust.
> 
> Anyway, the bug is probably in the glibc headers that are not checking
> the __UAPI_DEF*'s but rather using another broken heuristic... right
> place to fix this is probably there.
> 
> /Jonas

Florian Weimer said here "A lot of combinations are broken, especially
when kernel headers are included first.":
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1411192.html

That was on a older version of these two patches:
https://www.mail-archive.com/search?l=linux-kernel@vger.kernel.org=subject:%22Re%5C%3A+%5C%5Bmusl%5C%5D+Re%5C%3A+%5C%5BPATCH+resent%5C%5D+uapi+libc+compat%5C%3A+allow+non%5C-glibc+to+opt+out+of+uapi+definitions%22=newest=1

My understanding is that you should include libc headers before Linux
headers, otherwise you *could* run into problems. There are some
workarounds done to also support including Linux headers first, but they
are not working in all cases.

Hauke

Re: ipv6 redefinition build issue with 4.15-rc8

[Hauke Mehrtens]

On 01/17/2018 08:31 PM, Neil MacLeod wrote:
> All
> 
> Further to my previous reply (reproduced below having been bounced by
> linux-kernel) I have successfully built LibreELEC when using the
> ConnMan patch from Jonas - there were no other failures.
> 
> I have also built a number of network related packages (iftop, iperf,
> ngrp, nmap, sshfs, tcpdump, udpxy, wireless-tools), again without
> issue, so this particular 4.15-rc8 kernel change is only affecting
> ConnMan as far as I can tell.

Thanks for testing.

> Regards
> Neil
> 
>> All
>>
>> Many thanks for the replies.
>>
>> To ensure my build environment is sane I tested again without reverting the 
>> kernel commit, and reproduced the connman build failure.
>>
>> Next I tested the change suggested by Hauke (kernel patch: http://ix.io/Eh5) 
>> and connman fails to build, however it fails with a different error this 
>> time: http://ix.io/Eh2
>>
>> I then tested the change suggested by Jonas (connman patch: 
>> http://ix.io/Eh6) and connman builds successfully, no failure, so this might 
>> be a potential fix.

You should import the libc header files first and then the Linux header
files in user space applications, this is the supported order.

Can you try this patch please:

--- a/src/tethering.c
+++ b/src/tethering.c
@@ -31,11 +31,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
 #include 

 #include "connman.h"


Do we want to do any changes to the kernel header files? I do not know
of any clean workaround to make this work, we can probably hack
something for connman, but I think it is not worth the trouble.

Hauke

>> I'll now try a clean build with Jonas' patch and see if any other packages 
>> fail to build for the same reason as connman (I'm building a complete 
>> embedded distro with about 700 packages).
>>
>> I'll post again later with an update.
>>
>> Thanks
>> Neil
> 
> On 17 January 2018 at 15:25, Neil MacLeod  wrote:
>> All
>>
>> Many thanks for the replies.
>>
>> To ensure my build environment is sane I tested again without reverting the
>> kernel commit, and reproduced the connman build failure.
>>
>> Next I tested the change suggested by Hauke (kernel patch: http://ix.io/Eh5)
>> and connman fails to build, however it fails with a different error this
>> time: http://ix.io/Eh2
>>
>> I then tested the change suggested by Jonas (connman patch:
>> http://ix.io/Eh6) and connman builds successfully, no failure, so this might
>> be a potential fix.
>>
>> I'll now try a clean build with Jonas' patch and see if any other packages
>> fail to build for the same reason as connman (I'm building a complete
>> embedded distro with about 700 packages).
>>
>> I'll post again later with an update.
>>
>> Thanks
>> Neil
>>
>> On 17 January 2018 at 09:03, Jonas Bonn  wrote:
>>>
>>> On 01/17/2018 08:59 AM, Daniel Wagner wrote:

 Hi Neil,

 On 01/16/2018 07:51 PM, Neil MacLeod wrote:
>
> Since this commit in 4.15-rc8:
>
>
> https://github.com/torvalds/linux/commit/6926e041a8920c8ec27e4e155efa760aa01551fd
>
> building connman 1.35 with glibc 2.26 now fails as follows:
>
> http://ix.io/EbP
>
> I'm not sure if this is a kernel issue, a glibc issue, or a connman
> issue.
>
> Reverting the kernel commit resolves the issue, but isn't ideal (unless
> it's the correct solution, of course).
>
> Does anyone have any better ideas?
>>>
>>>
>>> Try switching the order of these headers around (src/tethering.c)...
>>> netinet/in.h seems to depend on linux/in.h being included _first_ and it's
>>> presumably being pulled in via linux/if_bridge.h now as a result of the
>>> kernel patch (couldn't immediately see why, though... I suspect the
>>> inclusion of libc-compat.h is the culprit.)
>>>
>>> #include 
>>> #include 
>>>
>>> Yes, this is a hack and only masks the issue... nonetheless.
>>>
>>> /Jonas
>>>
>>>

 Since ConnMan does not redefine 'struct in6_addr' and friends I would say
 it is kernel/glibc header include problem. But I might be wrong here.

 @Hauke: Do you happen to know what is going on?

 Thanks,
 Daniel
 ___
 connman mailing list
 conn...@lists.01.org
 https://lists.01.org/mailman/listinfo/connman
>>>
>>>
>>

Re: ipv6 redefinition build issue with 4.15-rc8

[Hauke Mehrtens]

On 01/17/2018 08:31 PM, Neil MacLeod wrote:
> All
> 
> Further to my previous reply (reproduced below having been bounced by
> linux-kernel) I have successfully built LibreELEC when using the
> ConnMan patch from Jonas - there were no other failures.
> 
> I have also built a number of network related packages (iftop, iperf,
> ngrp, nmap, sshfs, tcpdump, udpxy, wireless-tools), again without
> issue, so this particular 4.15-rc8 kernel change is only affecting
> ConnMan as far as I can tell.

Thanks for testing.

> Regards
> Neil
> 
>> All
>>
>> Many thanks for the replies.
>>
>> To ensure my build environment is sane I tested again without reverting the 
>> kernel commit, and reproduced the connman build failure.
>>
>> Next I tested the change suggested by Hauke (kernel patch: http://ix.io/Eh5) 
>> and connman fails to build, however it fails with a different error this 
>> time: http://ix.io/Eh2
>>
>> I then tested the change suggested by Jonas (connman patch: 
>> http://ix.io/Eh6) and connman builds successfully, no failure, so this might 
>> be a potential fix.

You should import the libc header files first and then the Linux header
files in user space applications, this is the supported order.

Can you try this patch please:

--- a/src/tethering.c
+++ b/src/tethering.c
@@ -31,11 +31,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
 #include 

 #include "connman.h"


Do we want to do any changes to the kernel header files? I do not know
of any clean workaround to make this work, we can probably hack
something for connman, but I think it is not worth the trouble.

Hauke

>> I'll now try a clean build with Jonas' patch and see if any other packages 
>> fail to build for the same reason as connman (I'm building a complete 
>> embedded distro with about 700 packages).
>>
>> I'll post again later with an update.
>>
>> Thanks
>> Neil
> 
> On 17 January 2018 at 15:25, Neil MacLeod  wrote:
>> All
>>
>> Many thanks for the replies.
>>
>> To ensure my build environment is sane I tested again without reverting the
>> kernel commit, and reproduced the connman build failure.
>>
>> Next I tested the change suggested by Hauke (kernel patch: http://ix.io/Eh5)
>> and connman fails to build, however it fails with a different error this
>> time: http://ix.io/Eh2
>>
>> I then tested the change suggested by Jonas (connman patch:
>> http://ix.io/Eh6) and connman builds successfully, no failure, so this might
>> be a potential fix.
>>
>> I'll now try a clean build with Jonas' patch and see if any other packages
>> fail to build for the same reason as connman (I'm building a complete
>> embedded distro with about 700 packages).
>>
>> I'll post again later with an update.
>>
>> Thanks
>> Neil
>>
>> On 17 January 2018 at 09:03, Jonas Bonn  wrote:
>>>
>>> On 01/17/2018 08:59 AM, Daniel Wagner wrote:

 Hi Neil,

 On 01/16/2018 07:51 PM, Neil MacLeod wrote:
>
> Since this commit in 4.15-rc8:
>
>
> https://github.com/torvalds/linux/commit/6926e041a8920c8ec27e4e155efa760aa01551fd
>
> building connman 1.35 with glibc 2.26 now fails as follows:
>
> http://ix.io/EbP
>
> I'm not sure if this is a kernel issue, a glibc issue, or a connman
> issue.
>
> Reverting the kernel commit resolves the issue, but isn't ideal (unless
> it's the correct solution, of course).
>
> Does anyone have any better ideas?
>>>
>>>
>>> Try switching the order of these headers around (src/tethering.c)...
>>> netinet/in.h seems to depend on linux/in.h being included _first_ and it's
>>> presumably being pulled in via linux/if_bridge.h now as a result of the
>>> kernel patch (couldn't immediately see why, though... I suspect the
>>> inclusion of libc-compat.h is the culprit.)
>>>
>>> #include 
>>> #include 
>>>
>>> Yes, this is a hack and only masks the issue... nonetheless.
>>>
>>> /Jonas
>>>
>>>

 Since ConnMan does not redefine 'struct in6_addr' and friends I would say
 it is kernel/glibc header include problem. But I might be wrong here.

 @Hauke: Do you happen to know what is going on?

 Thanks,
 Daniel
 ___
 connman mailing list
 conn...@lists.01.org
 https://lists.01.org/mailman/listinfo/connman
>>>
>>>
>>

Re: ipv6 redefinition build issue with 4.15-rc8

[Hauke Mehrtens]

On 01/17/2018 08:59 AM, Daniel Wagner wrote:
> Hi Neil,
> 
> On 01/16/2018 07:51 PM, Neil MacLeod wrote:
>> Since this commit in 4.15-rc8:
>>
>> https://github.com/torvalds/linux/commit/6926e041a8920c8ec27e4e155efa760aa01551fd
>>
>>
>> building connman 1.35 with glibc 2.26 now fails as follows:
>>
>> http://ix.io/EbP
>>
>> I'm not sure if this is a kernel issue, a glibc issue, or a connman
>> issue.
>>
>> Reverting the kernel commit resolves the issue, but isn't ideal
>> (unless it's the correct solution, of course).
>>
>> Does anyone have any better ideas?
> 
> Since ConnMan does not redefine 'struct in6_addr' and friends I would
> say it is kernel/glibc header include problem. But I might be wrong here.
> 
> @Hauke: Do you happen to know what is going on?
> 
> Thanks,
> Daniel

Hi,

my assumption is that connman uses a strange include order. Can you try
to remove the #include  from from
include/uapi/linux/if_ether.h please. This would not be the final
solution but would help to understand the problem better.

I will look into this more closely in the evening.

Hauke

Re: ipv6 redefinition build issue with 4.15-rc8

[Hauke Mehrtens]

On 01/17/2018 08:59 AM, Daniel Wagner wrote:
> Hi Neil,
> 
> On 01/16/2018 07:51 PM, Neil MacLeod wrote:
>> Since this commit in 4.15-rc8:
>>
>> https://github.com/torvalds/linux/commit/6926e041a8920c8ec27e4e155efa760aa01551fd
>>
>>
>> building connman 1.35 with glibc 2.26 now fails as follows:
>>
>> http://ix.io/EbP
>>
>> I'm not sure if this is a kernel issue, a glibc issue, or a connman
>> issue.
>>
>> Reverting the kernel commit resolves the issue, but isn't ideal
>> (unless it's the correct solution, of course).
>>
>> Does anyone have any better ideas?
> 
> Since ConnMan does not redefine 'struct in6_addr' and friends I would
> say it is kernel/glibc header include problem. But I might be wrong here.
> 
> @Hauke: Do you happen to know what is going on?
> 
> Thanks,
> Daniel

Hi,

my assumption is that connman uses a strange include order. Can you try
to remove the #include  from from
include/uapi/linux/if_ether.h please. This would not be the final
solution but would help to understand the problem better.

I will look into this more closely in the evening.

Hauke

[PATCH v4] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

From: Felix Janda <felix.ja...@posteo.de>

libc-compat.h aims to prevent symbol collisions between uapi and libc
headers for each supported libc. This requires continuous coordination
between them.

The goal of this commit is to improve the situation for libcs (such as
musl) which are not yet supported and/or do not wish to be explicitly
supported, while not affecting supported libcs. More precisely, with
this commit, unsupported libcs can request the suppression of any
specific uapi definition by defining the correspondings _UAPI_DEF_*
macro as 0. This can fix symbol collisions for them, as long as the
libc headers are included before the uapi headers. Inclusion in the
other order is outside the scope of this commit.

All infrastructure in order to enable this fallback for unsupported
libcs is already in place, except that libc-compat.h unconditionally
defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
any previous definitions are ignored. In order to fix this, this commit
merely makes these definitions conditional.

This commit together with the musl libc commit

http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258

fixes for example the following compiler errors when  is
included after musl's :

./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'

The comments referencing glibc are still correct, but this file is not
only used for glibc any more.

Signed-off-by: Felix Janda <felix.ja...@posteo.de>
Reviewed-by: Hauke Mehrtens <ha...@hauke-m.de>
---

v4: Extend patch description with comment about glibc comments
v3: Fix typos, add a comment to the file and use #ifndef.
v2: The only change to the previous version is the commit title and
message.

This was send to linux-...@vger.kernel.org before and it was suggested 
that this patch should go through the networking tree to Linus because 
most of these definitions are networking related.

 include/uapi/linux/libc-compat.h | 55 +++-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 282875cf8056..8254c937c9f4 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -168,46 +168,99 @@
 
 /* If we did not see any headers from any supported C libraries,
  * or we are being included in the kernel, then define everything
- * that we need. */
+ * that we need. Check for previous __UAPI_* definitions to give
+ * unsupported C libraries a way to opt out of any kernel definition. */
 #else /* !defined(__GLIBC__) */
 
 /* Definitions for if.h */
+#ifndef __UAPI_DEF_IF_IFCONF
 #define __UAPI_DEF_IF_IFCONF 1
+#endif
+#ifndef __UAPI_DEF_IF_IFMAP
 #define __UAPI_DEF_IF_IFMAP 1
+#endif
+#ifndef __UAPI_DEF_IF_IFNAMSIZ
 #define __UAPI_DEF_IF_IFNAMSIZ 1
+#endif
+#ifndef __UAPI_DEF_IF_IFREQ
 #define __UAPI_DEF_IF_IFREQ 1
+#endif
 /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
+#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
+#endif
 /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
+#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
+#endif
 
 /* Definitions for in.h */
+#ifndef __UAPI_DEF_IN_ADDR
 #define __UAPI_DEF_IN_ADDR 1
+#endif
+#ifndef __UAPI_DEF_IN_IPPROTO
 #define __UAPI_DEF_IN_IPPROTO  1
+#endif
+#ifndef __UAPI_DEF_IN_PKTINFO
 #define __UAPI_DEF_IN_PKTINFO  1
+#endif
+#ifndef __UAPI_DEF_IP_MREQ
 #define __UAPI_DEF_IP_MREQ 1
+#endif
+#ifndef __UAPI_DEF_SOCKADDR_IN
 #define __UAPI_DEF_SOCKADDR_IN 1
+#endif
+#ifndef __UAPI_DEF_IN_CLASS
 #define __UAPI_DEF_IN_CLASS1
+#endif
 
 /* Definitions for in6.h */
+#ifndef __UAPI_DEF_IN6_ADDR
 #define __UAPI_DEF_IN6_ADDR1
+#endif
+#ifndef __UAPI_DEF_IN6_ADDR_ALT
 #define __UAPI_DEF_IN6_ADDR_ALT1
+#endif
+#ifndef __UAPI_DEF_SOCKADDR_IN6
 #define __UAPI_DEF_SOCKADDR_IN61
+#endif
+#ifndef __UAPI_DEF_IPV6_MREQ
 #define __UAPI_DEF_IPV6_MREQ   1
+#endif
+#ifndef __UAPI_DEF_IPPROTO_V6
 #define __UAPI_DEF_IPPROTO_V6  1
+#endif
+#ifndef __UAPI_DEF_IPV6_OPTIONS
 #define __UAPI_DEF_IPV6_OPTIONS1
+#endif
+#ifndef __UAPI_DEF_IN6_PKTINFO
 #define __UAPI_DEF_IN6_PKTINFO 1
+#endif
+#ifndef __UAPI_DEF_IP6_MTUINFO
 #define __UAPI_DEF_IP6_MTUINFO 1
+#endif
 
 /* Definitions for ipx.h */
+#ifndef __UAPI_DEF_SOCKADDR_IPX
 #define __UAPI_DEF_SOCKADDR_IPX1
+#endif
+#ifndef __UAPI_DEF_IPX_ROUTE_DEFINITION
 #define __UAPI_DEF_IPX_ROUTE_DEFINITION1
+#endif
+#ifndef __UAPI_DEF_IPX_INTERFACE_DEFINITION
 #define __UAPI_DEF_IPX_INTERFACE_DEFINITION

[PATCH v4] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

From: Felix Janda 

libc-compat.h aims to prevent symbol collisions between uapi and libc
headers for each supported libc. This requires continuous coordination
between them.

The goal of this commit is to improve the situation for libcs (such as
musl) which are not yet supported and/or do not wish to be explicitly
supported, while not affecting supported libcs. More precisely, with
this commit, unsupported libcs can request the suppression of any
specific uapi definition by defining the correspondings _UAPI_DEF_*
macro as 0. This can fix symbol collisions for them, as long as the
libc headers are included before the uapi headers. Inclusion in the
other order is outside the scope of this commit.

All infrastructure in order to enable this fallback for unsupported
libcs is already in place, except that libc-compat.h unconditionally
defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
any previous definitions are ignored. In order to fix this, this commit
merely makes these definitions conditional.

This commit together with the musl libc commit

http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258

fixes for example the following compiler errors when  is
included after musl's :

./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'

The comments referencing glibc are still correct, but this file is not
only used for glibc any more.

Signed-off-by: Felix Janda 
Reviewed-by: Hauke Mehrtens 
---

v4: Extend patch description with comment about glibc comments
v3: Fix typos, add a comment to the file and use #ifndef.
v2: The only change to the previous version is the commit title and
message.

This was send to linux-...@vger.kernel.org before and it was suggested 
that this patch should go through the networking tree to Linus because 
most of these definitions are networking related.

 include/uapi/linux/libc-compat.h | 55 +++-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 282875cf8056..8254c937c9f4 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -168,46 +168,99 @@
 
 /* If we did not see any headers from any supported C libraries,
  * or we are being included in the kernel, then define everything
- * that we need. */
+ * that we need. Check for previous __UAPI_* definitions to give
+ * unsupported C libraries a way to opt out of any kernel definition. */
 #else /* !defined(__GLIBC__) */
 
 /* Definitions for if.h */
+#ifndef __UAPI_DEF_IF_IFCONF
 #define __UAPI_DEF_IF_IFCONF 1
+#endif
+#ifndef __UAPI_DEF_IF_IFMAP
 #define __UAPI_DEF_IF_IFMAP 1
+#endif
+#ifndef __UAPI_DEF_IF_IFNAMSIZ
 #define __UAPI_DEF_IF_IFNAMSIZ 1
+#endif
+#ifndef __UAPI_DEF_IF_IFREQ
 #define __UAPI_DEF_IF_IFREQ 1
+#endif
 /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
+#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
+#endif
 /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
+#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
+#endif
 
 /* Definitions for in.h */
+#ifndef __UAPI_DEF_IN_ADDR
 #define __UAPI_DEF_IN_ADDR 1
+#endif
+#ifndef __UAPI_DEF_IN_IPPROTO
 #define __UAPI_DEF_IN_IPPROTO  1
+#endif
+#ifndef __UAPI_DEF_IN_PKTINFO
 #define __UAPI_DEF_IN_PKTINFO  1
+#endif
+#ifndef __UAPI_DEF_IP_MREQ
 #define __UAPI_DEF_IP_MREQ 1
+#endif
+#ifndef __UAPI_DEF_SOCKADDR_IN
 #define __UAPI_DEF_SOCKADDR_IN 1
+#endif
+#ifndef __UAPI_DEF_IN_CLASS
 #define __UAPI_DEF_IN_CLASS1
+#endif
 
 /* Definitions for in6.h */
+#ifndef __UAPI_DEF_IN6_ADDR
 #define __UAPI_DEF_IN6_ADDR1
+#endif
+#ifndef __UAPI_DEF_IN6_ADDR_ALT
 #define __UAPI_DEF_IN6_ADDR_ALT1
+#endif
+#ifndef __UAPI_DEF_SOCKADDR_IN6
 #define __UAPI_DEF_SOCKADDR_IN61
+#endif
+#ifndef __UAPI_DEF_IPV6_MREQ
 #define __UAPI_DEF_IPV6_MREQ   1
+#endif
+#ifndef __UAPI_DEF_IPPROTO_V6
 #define __UAPI_DEF_IPPROTO_V6  1
+#endif
+#ifndef __UAPI_DEF_IPV6_OPTIONS
 #define __UAPI_DEF_IPV6_OPTIONS1
+#endif
+#ifndef __UAPI_DEF_IN6_PKTINFO
 #define __UAPI_DEF_IN6_PKTINFO 1
+#endif
+#ifndef __UAPI_DEF_IP6_MTUINFO
 #define __UAPI_DEF_IP6_MTUINFO 1
+#endif
 
 /* Definitions for ipx.h */
+#ifndef __UAPI_DEF_SOCKADDR_IPX
 #define __UAPI_DEF_SOCKADDR_IPX1
+#endif
+#ifndef __UAPI_DEF_IPX_ROUTE_DEFINITION
 #define __UAPI_DEF_IPX_ROUTE_DEFINITION1
+#endif
+#ifndef __UAPI_DEF_IPX_INTERFACE_DEFINITION
 #define __UAPI_DEF_IPX_INTERFACE_DEFINITION1
+#endif
+#ifndef __UAPI_DEF_IPX_CONFIG_DATA
 #define __UAPI_DEF_IPX_CONFIG_DATA

Re: [PATCHv3 resend] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

On 12/03/2017 12:28 PM, Dmitry V. Levin wrote:
> Hi,
> 
> On Sun, Nov 12, 2017 at 01:30:17PM -0500, Felix Janda wrote:
>> libc-compat.h aims to prevent symbol collisions between uapi and libc
>> headers for each supported libc. This requires continuous coordination
>> between them.
>>
>> The goal of this commit is to improve the situation for libcs (such as
>> musl) which are not yet supported and/or do not wish to be explicitly
>> supported, while not affecting supported libcs. More precisely, with
>> this commit, unsupported libcs can request the suppression of any
>> specific uapi definition by defining the correspondings _UAPI_DEF_*
>> macro as 0. This can fix symbol collisions for them, as long as the
>> libc headers are included before the uapi headers. Inclusion in the
>> other order is outside the scope of this commit.
>>
>> All infrastructure in order to enable this fallback for unsupported
>> libcs is already in place, except that libc-compat.h unconditionally
>> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
>> any previous definitions are ignored. In order to fix this, this commit
>> merely makes these definitions conditional.
>>
>> This commit together with the musl libc commit
>>
>> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
>>
>> fixes for example the following compiler errors when  is
>> included after musl's :
>>
>> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
>> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
>> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
>>
>> Signed-off-by: Felix Janda <felix.ja...@posteo.de>
>> Reviewed-by: Hauke Mehrtens <ha...@hauke-m.de>
>> ---
>> v3: Fix typos, add a comment to the file and use #ifndef.
>> v2: The only change to the previous version is the commit title and
>> message.
>> ---
>>  include/uapi/linux/libc-compat.h | 55 
>> +++-
>>  1 file changed, 54 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/libc-compat.h 
>> b/include/uapi/linux/libc-compat.h
>> index 44b8a6bd5fe1..65db6b26d790 100644
>> --- a/include/uapi/linux/libc-compat.h
>> +++ b/include/uapi/linux/libc-compat.h
>> @@ -167,46 +167,99 @@
>>  
>>  /* If we did not see any headers from any supported C libraries,
>>   * or we are being included in the kernel, then define everything
>> - * that we need. */
>> + * that we need. Check for previous __UAPI_* definitions to give
>> + * unsupported C libraries a way to opt out of any kernel definition. */
>>  #else /* !defined(__GLIBC__) */
>>  
>>  /* Definitions for if.h */
>> +#ifndef __UAPI_DEF_IF_IFCONF
>>  #define __UAPI_DEF_IF_IFCONF 1
>> +#endif
>> +#ifndef __UAPI_DEF_IF_IFMAP
>>  #define __UAPI_DEF_IF_IFMAP 1
>> +#endif
>> +#ifndef __UAPI_DEF_IF_IFNAMSIZ
>>  #define __UAPI_DEF_IF_IFNAMSIZ 1
>> +#endif
>> +#ifndef __UAPI_DEF_IF_IFREQ
>>  #define __UAPI_DEF_IF_IFREQ 1
>> +#endif
>>  /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
>> +#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS
>>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
>> +#endif
>>  /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
>> +#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
>>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
>> +#endif
> 
> Please double-check that mentioning glibc in comments
> of this !__GLIBC__ section is relevant.

These comments are still true for glibc, but these defines are also used
by other libc implementations. This section is also used with glibc when
the kernel headers are included before the glibc headers, but this case
is not so well supported.

>>  /* Definitions for in.h */
>> +#ifndef __UAPI_DEF_IN_ADDR
>>  #define __UAPI_DEF_IN_ADDR  1
>> +#endif
>> +#ifndef __UAPI_DEF_IN_IPPROTO
>>  #define __UAPI_DEF_IN_IPPROTO   1
>> +#endif
>> +#ifndef __UAPI_DEF_IN_PKTINFO
>>  #define __UAPI_DEF_IN_PKTINFO   1
>> +#endif
>> +#ifndef __UAPI_DEF_IP_MREQ
>>  #define __UAPI_DEF_IP_MREQ  1
>> +#endif
>> +#ifndef __UAPI_DEF_SOCKADDR_IN
>>  #define __UAPI_DEF_SOCKADDR_IN  1
>> +#endif
>> +#ifndef __UAPI_DEF_IN_CLASS
>>  #define __UAPI_DEF_IN_CLASS 1
>> +#endif
>>  
>>  /* Definitions for in6.h */
>> +#ifndef __UAPI_DEF_IN6_ADDR
>>  #define __UA

Re: [PATCHv3 resend] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

On 12/03/2017 12:28 PM, Dmitry V. Levin wrote:
> Hi,
> 
> On Sun, Nov 12, 2017 at 01:30:17PM -0500, Felix Janda wrote:
>> libc-compat.h aims to prevent symbol collisions between uapi and libc
>> headers for each supported libc. This requires continuous coordination
>> between them.
>>
>> The goal of this commit is to improve the situation for libcs (such as
>> musl) which are not yet supported and/or do not wish to be explicitly
>> supported, while not affecting supported libcs. More precisely, with
>> this commit, unsupported libcs can request the suppression of any
>> specific uapi definition by defining the correspondings _UAPI_DEF_*
>> macro as 0. This can fix symbol collisions for them, as long as the
>> libc headers are included before the uapi headers. Inclusion in the
>> other order is outside the scope of this commit.
>>
>> All infrastructure in order to enable this fallback for unsupported
>> libcs is already in place, except that libc-compat.h unconditionally
>> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
>> any previous definitions are ignored. In order to fix this, this commit
>> merely makes these definitions conditional.
>>
>> This commit together with the musl libc commit
>>
>> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
>>
>> fixes for example the following compiler errors when  is
>> included after musl's :
>>
>> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
>> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
>> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
>>
>> Signed-off-by: Felix Janda 
>> Reviewed-by: Hauke Mehrtens 
>> ---
>> v3: Fix typos, add a comment to the file and use #ifndef.
>> v2: The only change to the previous version is the commit title and
>> message.
>> ---
>>  include/uapi/linux/libc-compat.h | 55 
>> +++-
>>  1 file changed, 54 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/libc-compat.h 
>> b/include/uapi/linux/libc-compat.h
>> index 44b8a6bd5fe1..65db6b26d790 100644
>> --- a/include/uapi/linux/libc-compat.h
>> +++ b/include/uapi/linux/libc-compat.h
>> @@ -167,46 +167,99 @@
>>  
>>  /* If we did not see any headers from any supported C libraries,
>>   * or we are being included in the kernel, then define everything
>> - * that we need. */
>> + * that we need. Check for previous __UAPI_* definitions to give
>> + * unsupported C libraries a way to opt out of any kernel definition. */
>>  #else /* !defined(__GLIBC__) */
>>  
>>  /* Definitions for if.h */
>> +#ifndef __UAPI_DEF_IF_IFCONF
>>  #define __UAPI_DEF_IF_IFCONF 1
>> +#endif
>> +#ifndef __UAPI_DEF_IF_IFMAP
>>  #define __UAPI_DEF_IF_IFMAP 1
>> +#endif
>> +#ifndef __UAPI_DEF_IF_IFNAMSIZ
>>  #define __UAPI_DEF_IF_IFNAMSIZ 1
>> +#endif
>> +#ifndef __UAPI_DEF_IF_IFREQ
>>  #define __UAPI_DEF_IF_IFREQ 1
>> +#endif
>>  /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
>> +#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS
>>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
>> +#endif
>>  /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
>> +#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
>>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
>> +#endif
> 
> Please double-check that mentioning glibc in comments
> of this !__GLIBC__ section is relevant.

These comments are still true for glibc, but these defines are also used
by other libc implementations. This section is also used with glibc when
the kernel headers are included before the glibc headers, but this case
is not so well supported.

>>  /* Definitions for in.h */
>> +#ifndef __UAPI_DEF_IN_ADDR
>>  #define __UAPI_DEF_IN_ADDR  1
>> +#endif
>> +#ifndef __UAPI_DEF_IN_IPPROTO
>>  #define __UAPI_DEF_IN_IPPROTO   1
>> +#endif
>> +#ifndef __UAPI_DEF_IN_PKTINFO
>>  #define __UAPI_DEF_IN_PKTINFO   1
>> +#endif
>> +#ifndef __UAPI_DEF_IP_MREQ
>>  #define __UAPI_DEF_IP_MREQ  1
>> +#endif
>> +#ifndef __UAPI_DEF_SOCKADDR_IN
>>  #define __UAPI_DEF_SOCKADDR_IN  1
>> +#endif
>> +#ifndef __UAPI_DEF_IN_CLASS
>>  #define __UAPI_DEF_IN_CLASS 1
>> +#endif
>>  
>>  /* Definitions for in6.h */
>> +#ifndef __UAPI_DEF_IN6_ADDR
>>  #define __UAPI_DEF_IN6_ADDR 1
>> +#endif
>

Re: [PATCH] ARM: dts: sun8i: add support for Orange Pi R1

[Hauke Mehrtens]

Hi,

I tried this device tree file with my Orange Pi R1 and then the Ethernet
chip connected to the USB controller is not working. When I set PAD 20
to high the device is found on the USB bus.



On 11/12/2017 01:41 PM, Icenowy Zheng wrote:
> Orange Pi R1 is a board design based on Orange Pi Zero, with XR819 Wi-Fi
> chip replaced by RTL8189ETV Wi-Fi module and the USB Type-A jack
> replaced by an onboard USB RTL8152B USB-Ethernet adapter.
> 
> Add support for it.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/Makefile  |  1 +
>  arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 73 
> +
>  2 files changed, 74 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..3c139c63098f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -949,6 +949,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>   sun8i-a83t-bananapi-m3.dtb \
>   sun8i-a83t-cubietruck-plus.dtb \
>   sun8i-a83t-tbs-a711.dtb \
> + sun8i-h2-plus-orangepi-r1.dtb \
>   sun8i-h2-plus-orangepi-zero.dtb \
>   sun8i-h3-bananapi-m2-plus.dtb \
>   sun8i-h3-beelink-x2.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts 
> b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> new file mode 100644
> index ..32a6d312422e
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> @@ -0,0 +1,73 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/* Orange Pi R1 is based on Orange Pi Zero design */
> +#include "sun8i-h2-plus-orangepi-zero.dts"
> +
> +/ {
> + model = "Xunlong Orange Pi R1";
> + compatible = "xunlong,orangepi-r1", "allwinner,sun8i-h2-plus";
> +
> + /delete-node/ reg_vcc_wifi;
I remove this line.

> +
> + aliases {
> + ethernet1 = 
> + };
> +};
> +

I add this:
_vcc_wifi {
regulator-always-on;
};
This regulator should be connected to the USB device, but this is not in
device tree because it should be automatically probed.

> + {
> + /*
> +  * RTL8152B USB-Ethernet adapter is connected to USB1,
> +  * and it's a USB 2.0 device. So the OHCI1 controller
> +  * can be left disabled.
> +  */
> + status = "disabled";
> +};
> +
> + {
> + vmmc-supply = <_vcc3v3>;
> + vqmmc-supply = <_vcc3v3>;
> +
> + rtl8189etv: sdio_wifi@1 {
> + reg = <1>;
> + };
> +};
> 

Re: [PATCH] ARM: dts: sun8i: add support for Orange Pi R1

[Hauke Mehrtens]

Hi,

I tried this device tree file with my Orange Pi R1 and then the Ethernet
chip connected to the USB controller is not working. When I set PAD 20
to high the device is found on the USB bus.



On 11/12/2017 01:41 PM, Icenowy Zheng wrote:
> Orange Pi R1 is a board design based on Orange Pi Zero, with XR819 Wi-Fi
> chip replaced by RTL8189ETV Wi-Fi module and the USB Type-A jack
> replaced by an onboard USB RTL8152B USB-Ethernet adapter.
> 
> Add support for it.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/Makefile  |  1 +
>  arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 73 
> +
>  2 files changed, 74 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..3c139c63098f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -949,6 +949,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>   sun8i-a83t-bananapi-m3.dtb \
>   sun8i-a83t-cubietruck-plus.dtb \
>   sun8i-a83t-tbs-a711.dtb \
> + sun8i-h2-plus-orangepi-r1.dtb \
>   sun8i-h2-plus-orangepi-zero.dtb \
>   sun8i-h3-bananapi-m2-plus.dtb \
>   sun8i-h3-beelink-x2.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts 
> b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> new file mode 100644
> index ..32a6d312422e
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
> @@ -0,0 +1,73 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/* Orange Pi R1 is based on Orange Pi Zero design */
> +#include "sun8i-h2-plus-orangepi-zero.dts"
> +
> +/ {
> + model = "Xunlong Orange Pi R1";
> + compatible = "xunlong,orangepi-r1", "allwinner,sun8i-h2-plus";
> +
> + /delete-node/ reg_vcc_wifi;
I remove this line.

> +
> + aliases {
> + ethernet1 = 
> + };
> +};
> +

I add this:
_vcc_wifi {
regulator-always-on;
};
This regulator should be connected to the USB device, but this is not in
device tree because it should be automatically probed.

> + {
> + /*
> +  * RTL8152B USB-Ethernet adapter is connected to USB1,
> +  * and it's a USB 2.0 device. So the OHCI1 controller
> +  * can be left disabled.
> +  */
> + status = "disabled";
> +};
> +
> + {
> + vmmc-supply = <_vcc3v3>;
> + vqmmc-supply = <_vcc3v3>;
> +
> + rtl8189etv: sdio_wifi@1 {
> + reg = <1>;
> + };
> +};
> 

Re: [PATCHv3 resend] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

On 11/12/2017 07:30 PM, Felix Janda wrote:
> libc-compat.h aims to prevent symbol collisions between uapi and libc
> headers for each supported libc. This requires continuous coordination
> between them.
> 
> The goal of this commit is to improve the situation for libcs (such as
> musl) which are not yet supported and/or do not wish to be explicitly
> supported, while not affecting supported libcs. More precisely, with
> this commit, unsupported libcs can request the suppression of any
> specific uapi definition by defining the correspondings _UAPI_DEF_*
> macro as 0. This can fix symbol collisions for them, as long as the
> libc headers are included before the uapi headers. Inclusion in the
> other order is outside the scope of this commit.
> 
> All infrastructure in order to enable this fallback for unsupported
> libcs is already in place, except that libc-compat.h unconditionally
> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
> any previous definitions are ignored. In order to fix this, this commit
> merely makes these definitions conditional.
> 
> This commit together with the musl libc commit
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
> 
> fixes for example the following compiler errors when  is
> included after musl's :
> 
> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
> 
> Signed-off-by: Felix Janda <felix.ja...@posteo.de>
> Reviewed-by: Hauke Mehrtens <ha...@hauke-m.de>
> ---
> v3: Fix typos, add a comment to the file and use #ifndef.
> v2: The only change to the previous version is the commit title and
> message.
> ---
>  include/uapi/linux/libc-compat.h | 55 
> +++-
>  1 file changed, 54 insertions(+), 1 deletion(-)
> 

I would really like to see this in the mainline kernel as this is needed
to use the kernel headers with the musl libc, so probably every user of
the musl libc needs this.
A similar patch is in OpenWrt / LEDE and is mandatory when building the
musl toolchain used in OpenWrt / LEDE, which is the default. I would
like to get closer to build OpenWrt / LEDE with an unmodified Linux
kernel and getting this into mainline is one part of it.

As this patch is on the mailling lists since multiple months without any
reaction it looks like there is no maintainer for:
include/uapi/linux/libc-compat.h

Should we send this in the next merge window directly to Linus?

If I am wrong please correct me.

Post on the mailling list:
patch v2: https://patchwork.kernel.org/patch/9831533/
patch v3: https://patchwork.kernel.org/patch/9869953/

Hauke

Re: [PATCHv3 resend] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

On 11/12/2017 07:30 PM, Felix Janda wrote:
> libc-compat.h aims to prevent symbol collisions between uapi and libc
> headers for each supported libc. This requires continuous coordination
> between them.
> 
> The goal of this commit is to improve the situation for libcs (such as
> musl) which are not yet supported and/or do not wish to be explicitly
> supported, while not affecting supported libcs. More precisely, with
> this commit, unsupported libcs can request the suppression of any
> specific uapi definition by defining the correspondings _UAPI_DEF_*
> macro as 0. This can fix symbol collisions for them, as long as the
> libc headers are included before the uapi headers. Inclusion in the
> other order is outside the scope of this commit.
> 
> All infrastructure in order to enable this fallback for unsupported
> libcs is already in place, except that libc-compat.h unconditionally
> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
> any previous definitions are ignored. In order to fix this, this commit
> merely makes these definitions conditional.
> 
> This commit together with the musl libc commit
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
> 
> fixes for example the following compiler errors when  is
> included after musl's :
> 
> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
> 
> Signed-off-by: Felix Janda 
> Reviewed-by: Hauke Mehrtens 
> ---
> v3: Fix typos, add a comment to the file and use #ifndef.
> v2: The only change to the previous version is the commit title and
> message.
> ---
>  include/uapi/linux/libc-compat.h | 55 
> +++-
>  1 file changed, 54 insertions(+), 1 deletion(-)
> 

I would really like to see this in the mainline kernel as this is needed
to use the kernel headers with the musl libc, so probably every user of
the musl libc needs this.
A similar patch is in OpenWrt / LEDE and is mandatory when building the
musl toolchain used in OpenWrt / LEDE, which is the default. I would
like to get closer to build OpenWrt / LEDE with an unmodified Linux
kernel and getting this into mainline is one part of it.

As this patch is on the mailling lists since multiple months without any
reaction it looks like there is no maintainer for:
include/uapi/linux/libc-compat.h

Should we send this in the next merge window directly to Linus?

If I am wrong please correct me.

Post on the mailling list:
patch v2: https://patchwork.kernel.org/patch/9831533/
patch v3: https://patchwork.kernel.org/patch/9869953/

Hauke

Re: [PATCHv3] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

On 07/29/2017 04:02 PM, Felix Janda wrote:
> libc-compat.h aims to prevent symbol collisions between uapi and libc
> headers for each supported libc. This requires continuous coordination
> between them.
> 
> The goal of this commit is to improve the situation for libcs (such as
> musl) which are not yet supported and/or do not wish to be explicitly
> supported, while not affecting supported libcs. More precisely, with
> this commit, unsupported libcs can request the suppression of any
> specific uapi definition by defining the correspondings _UAPI_DEF_*
> macro as 0. This can fix symbol collisions for them, as long as the
> libc headers are included before the uapi headers. Inclusion in the
> other order is outside the scope of this commit.
> 
> All infrastructure in order to enable this fallback for unsupported
> libcs is already in place, except that libc-compat.h unconditionally
> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
> any previous definitions are ignored. In order to fix this, this commit
> merely makes these definitions conditional.
> 
> This commit together with the musl libc commit
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
> 
> fixes for example the following compiler errors when  is
> included after musl's :
> 
> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
> 
> Signed-off-by: Felix Janda 
> ---
> v3: Fix typos, add a comment to the file and use #ifndef.
> v2: The only change to the previous version is the commit title and
> message.

Was this send to the wrong mailing lists? I would like to see this in
the mainline kernel and I am wondering why it neither gets any comments
nor shows up in linux-next.

Hauke

Re: [PATCHv3] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

On 07/29/2017 04:02 PM, Felix Janda wrote:
> libc-compat.h aims to prevent symbol collisions between uapi and libc
> headers for each supported libc. This requires continuous coordination
> between them.
> 
> The goal of this commit is to improve the situation for libcs (such as
> musl) which are not yet supported and/or do not wish to be explicitly
> supported, while not affecting supported libcs. More precisely, with
> this commit, unsupported libcs can request the suppression of any
> specific uapi definition by defining the correspondings _UAPI_DEF_*
> macro as 0. This can fix symbol collisions for them, as long as the
> libc headers are included before the uapi headers. Inclusion in the
> other order is outside the scope of this commit.
> 
> All infrastructure in order to enable this fallback for unsupported
> libcs is already in place, except that libc-compat.h unconditionally
> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
> any previous definitions are ignored. In order to fix this, this commit
> merely makes these definitions conditional.
> 
> This commit together with the musl libc commit
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
> 
> fixes for example the following compiler errors when  is
> included after musl's :
> 
> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
> 
> Signed-off-by: Felix Janda 
> ---
> v3: Fix typos, add a comment to the file and use #ifndef.
> v2: The only change to the previous version is the commit title and
> message.

Was this send to the wrong mailing lists? I would like to see this in
the mainline kernel and I am wondering why it neither gets any comments
nor shows up in linux-next.

Hauke

Re: linux-next: Signed-off-by missing for commits in the mips tree

[Hauke Mehrtens]

Hi Ralf and Martin,

On 09/03/2017 11:14 PM, Martin Blumenstingl wrote:
> Hi Hauke, Hi Ralf,
> 
> On Sun, Sep 3, 2017 at 6:13 PM, Stephen Rothwell  
> wrote:
>> Hi all,
>>
>> Commits
>>
>> bb19a5e5205b MIPS: lantiq: Remove the arch/mips/lantiq/xway/reset.c 
>> implementation
>> f6a4de1654c9 MIPS: lantiq: Add a GPHY driver which uses the RCU syscon-mfd
>> 565f7e8292f5 reset: Add a reset controller driver for the Lantiq XWAY based 
>> SoCs
>> e55bfdfacaed Documentation: DT: MIPS: lantiq: Add docs for the RCU bindings
>> 5a7715f4b8e0 MIPS: lantiq: Enable MFD_SYSCON to be able to use it for the 
>> RCU MFD
> Hauke: thank you for pushing these patches forward (by adding lots of
> fixes, missing documentation and so on)!
> I can send a Signed-off-by for all of these - however I'd like you to
> be the author of at least "Documentation: DT: MIPS: lantiq: Add docs
> for the RCU bindings" (since you did all the actual work, but finding
> the best DT binding with the DT maintainers).

I am ok with this.

> Ralf: how do you want to handle this? should I simply send my
> Signed-off-by on the relevant patches and you will fixup these?
> and similarly, (if it's OK for Hauke) can you also change the author
> of "Documentation: DT: MIPS: lantiq: Add docs for the RCU bindings"?

I am ok with this and I think the easiest solution would be if Ralf
would edit it.

>> 114f298226a3 MIPS: Malta: Use new GIC accessor functions
>>
>> are missing a Signed-off-by from their author.
>>
>> Commit
>>
>> 114f298226a3 MIPS: Malta: Use new GIC accessor functions
>>
>> is missing a Signed-off-by from its commiter.
>>
>> --
>> Cheers,
>> Stephen Rothwell
> thanks for spotting this Stephen
> 
> 
> Regards,
> Martin

Hauke

Re: linux-next: Signed-off-by missing for commits in the mips tree

[Hauke Mehrtens]

Hi Ralf and Martin,

On 09/03/2017 11:14 PM, Martin Blumenstingl wrote:
> Hi Hauke, Hi Ralf,
> 
> On Sun, Sep 3, 2017 at 6:13 PM, Stephen Rothwell  
> wrote:
>> Hi all,
>>
>> Commits
>>
>> bb19a5e5205b MIPS: lantiq: Remove the arch/mips/lantiq/xway/reset.c 
>> implementation
>> f6a4de1654c9 MIPS: lantiq: Add a GPHY driver which uses the RCU syscon-mfd
>> 565f7e8292f5 reset: Add a reset controller driver for the Lantiq XWAY based 
>> SoCs
>> e55bfdfacaed Documentation: DT: MIPS: lantiq: Add docs for the RCU bindings
>> 5a7715f4b8e0 MIPS: lantiq: Enable MFD_SYSCON to be able to use it for the 
>> RCU MFD
> Hauke: thank you for pushing these patches forward (by adding lots of
> fixes, missing documentation and so on)!
> I can send a Signed-off-by for all of these - however I'd like you to
> be the author of at least "Documentation: DT: MIPS: lantiq: Add docs
> for the RCU bindings" (since you did all the actual work, but finding
> the best DT binding with the DT maintainers).

I am ok with this.

> Ralf: how do you want to handle this? should I simply send my
> Signed-off-by on the relevant patches and you will fixup these?
> and similarly, (if it's OK for Hauke) can you also change the author
> of "Documentation: DT: MIPS: lantiq: Add docs for the RCU bindings"?

I am ok with this and I think the easiest solution would be if Ralf
would edit it.

>> 114f298226a3 MIPS: Malta: Use new GIC accessor functions
>>
>> are missing a Signed-off-by from their author.
>>
>> Commit
>>
>> 114f298226a3 MIPS: Malta: Use new GIC accessor functions
>>
>> is missing a Signed-off-by from its commiter.
>>
>> --
>> Cheers,
>> Stephen Rothwell
> thanks for spotting this Stephen
> 
> 
> Regards,
> Martin

Hauke

Re: [PATCHv3] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

On 07/29/2017 04:02 PM, Felix Janda wrote:
> libc-compat.h aims to prevent symbol collisions between uapi and libc
> headers for each supported libc. This requires continuous coordination
> between them.
> 
> The goal of this commit is to improve the situation for libcs (such as
> musl) which are not yet supported and/or do not wish to be explicitly
> supported, while not affecting supported libcs. More precisely, with
> this commit, unsupported libcs can request the suppression of any
> specific uapi definition by defining the correspondings _UAPI_DEF_*
> macro as 0. This can fix symbol collisions for them, as long as the
> libc headers are included before the uapi headers. Inclusion in the
> other order is outside the scope of this commit.
> 
> All infrastructure in order to enable this fallback for unsupported
> libcs is already in place, except that libc-compat.h unconditionally
> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
> any previous definitions are ignored. In order to fix this, this commit
> merely makes these definitions conditional.
> 
> This commit together with the musl libc commit
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
> 
> fixes for example the following compiler errors when  is
> included after musl's :
> 
> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
> 
> Signed-off-by: Felix Janda <felix.ja...@posteo.de>

Reviewed-by: Hauke Mehrtens <ha...@hauke-m.de>

With this patch + a patch which protects "struct ethhdr" I was able to
build LEDE with musl libc using these kernel headers without a problem
include building iproute2.

I would like to send my patch to protect "struct ethhdr", but it depends
ion this one.

> ---
> v3: Fix typos, add a comment to the file and use #ifndef.
> v2: The only change to the previous version is the commit title and
> message.
> ---
>  include/uapi/linux/libc-compat.h | 55 
> +++-
>  1 file changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/libc-compat.h 
> b/include/uapi/linux/libc-compat.h
> index 44b8a6bd5fe1..65db6b26d790 100644
> --- a/include/uapi/linux/libc-compat.h
> +++ b/include/uapi/linux/libc-compat.h
> @@ -167,46 +167,99 @@
>  
>  /* If we did not see any headers from any supported C libraries,
>   * or we are being included in the kernel, then define everything
> - * that we need. */
> + * that we need. Check for previous __UAPI_* definitions to give
> + * unsupported C libraries a way to opt out of any kernel definition. */
>  #else /* !defined(__GLIBC__) */
>  
>  /* Definitions for if.h */
> +#ifndef __UAPI_DEF_IF_IFCONF
>  #define __UAPI_DEF_IF_IFCONF 1
> +#endif
> +#ifndef __UAPI_DEF_IF_IFMAP
>  #define __UAPI_DEF_IF_IFMAP 1
> +#endif
> +#ifndef __UAPI_DEF_IF_IFNAMSIZ
>  #define __UAPI_DEF_IF_IFNAMSIZ 1
> +#endif
> +#ifndef __UAPI_DEF_IF_IFREQ
>  #define __UAPI_DEF_IF_IFREQ 1
> +#endif
>  /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
> +#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS
>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
> +#endif
>  /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
> +#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
> +#endif
>  
>  /* Definitions for in.h */
> +#ifndef __UAPI_DEF_IN_ADDR
>  #define __UAPI_DEF_IN_ADDR   1
> +#endif
> +#ifndef __UAPI_DEF_IN_IPPROTO
>  #define __UAPI_DEF_IN_IPPROTO1
> +#endif
> +#ifndef __UAPI_DEF_IN_PKTINFO
>  #define __UAPI_DEF_IN_PKTINFO1
> +#endif
> +#ifndef __UAPI_DEF_IP_MREQ
>  #define __UAPI_DEF_IP_MREQ   1
> +#endif
> +#ifndef __UAPI_DEF_SOCKADDR_IN
>  #define __UAPI_DEF_SOCKADDR_IN   1
> +#endif
> +#ifndef __UAPI_DEF_IN_CLASS
>  #define __UAPI_DEF_IN_CLASS  1
> +#endif
>  
>  /* Definitions for in6.h */
> +#ifndef __UAPI_DEF_IN6_ADDR
>  #define __UAPI_DEF_IN6_ADDR  1
> +#endif
> +#ifndef __UAPI_DEF_IN6_ADDR_ALT
>  #define __UAPI_DEF_IN6_ADDR_ALT  1
> +#endif
> +#ifndef __UAPI_DEF_SOCKADDR_IN6
>  #define __UAPI_DEF_SOCKADDR_IN6  1
> +#endif
> +#ifndef __UAPI_DEF_IPV6_MREQ
>  #define __UAPI_DEF_IPV6_MREQ 1
> +#endif
> +#ifndef __UAPI_DEF_IPPROTO_V6
>  #define __UAPI_DEF_IPPROTO_V61
> +#endif
> +#ifndef __UAPI_DEF_IPV6_OPTIONS
>  #define __UAPI_DEF_IPV6_OPTIONS  1
> +#endif
&g

Re: [PATCHv3] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

On 07/29/2017 04:02 PM, Felix Janda wrote:
> libc-compat.h aims to prevent symbol collisions between uapi and libc
> headers for each supported libc. This requires continuous coordination
> between them.
> 
> The goal of this commit is to improve the situation for libcs (such as
> musl) which are not yet supported and/or do not wish to be explicitly
> supported, while not affecting supported libcs. More precisely, with
> this commit, unsupported libcs can request the suppression of any
> specific uapi definition by defining the correspondings _UAPI_DEF_*
> macro as 0. This can fix symbol collisions for them, as long as the
> libc headers are included before the uapi headers. Inclusion in the
> other order is outside the scope of this commit.
> 
> All infrastructure in order to enable this fallback for unsupported
> libcs is already in place, except that libc-compat.h unconditionally
> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
> any previous definitions are ignored. In order to fix this, this commit
> merely makes these definitions conditional.
> 
> This commit together with the musl libc commit
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
> 
> fixes for example the following compiler errors when  is
> included after musl's :
> 
> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
> 
> Signed-off-by: Felix Janda 

Reviewed-by: Hauke Mehrtens 

With this patch + a patch which protects "struct ethhdr" I was able to
build LEDE with musl libc using these kernel headers without a problem
include building iproute2.

I would like to send my patch to protect "struct ethhdr", but it depends
ion this one.

> ---
> v3: Fix typos, add a comment to the file and use #ifndef.
> v2: The only change to the previous version is the commit title and
> message.
> ---
>  include/uapi/linux/libc-compat.h | 55 
> +++-
>  1 file changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/libc-compat.h 
> b/include/uapi/linux/libc-compat.h
> index 44b8a6bd5fe1..65db6b26d790 100644
> --- a/include/uapi/linux/libc-compat.h
> +++ b/include/uapi/linux/libc-compat.h
> @@ -167,46 +167,99 @@
>  
>  /* If we did not see any headers from any supported C libraries,
>   * or we are being included in the kernel, then define everything
> - * that we need. */
> + * that we need. Check for previous __UAPI_* definitions to give
> + * unsupported C libraries a way to opt out of any kernel definition. */
>  #else /* !defined(__GLIBC__) */
>  
>  /* Definitions for if.h */
> +#ifndef __UAPI_DEF_IF_IFCONF
>  #define __UAPI_DEF_IF_IFCONF 1
> +#endif
> +#ifndef __UAPI_DEF_IF_IFMAP
>  #define __UAPI_DEF_IF_IFMAP 1
> +#endif
> +#ifndef __UAPI_DEF_IF_IFNAMSIZ
>  #define __UAPI_DEF_IF_IFNAMSIZ 1
> +#endif
> +#ifndef __UAPI_DEF_IF_IFREQ
>  #define __UAPI_DEF_IF_IFREQ 1
> +#endif
>  /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
> +#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS
>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
> +#endif
>  /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
> +#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
> +#endif
>  
>  /* Definitions for in.h */
> +#ifndef __UAPI_DEF_IN_ADDR
>  #define __UAPI_DEF_IN_ADDR   1
> +#endif
> +#ifndef __UAPI_DEF_IN_IPPROTO
>  #define __UAPI_DEF_IN_IPPROTO1
> +#endif
> +#ifndef __UAPI_DEF_IN_PKTINFO
>  #define __UAPI_DEF_IN_PKTINFO1
> +#endif
> +#ifndef __UAPI_DEF_IP_MREQ
>  #define __UAPI_DEF_IP_MREQ   1
> +#endif
> +#ifndef __UAPI_DEF_SOCKADDR_IN
>  #define __UAPI_DEF_SOCKADDR_IN   1
> +#endif
> +#ifndef __UAPI_DEF_IN_CLASS
>  #define __UAPI_DEF_IN_CLASS  1
> +#endif
>  
>  /* Definitions for in6.h */
> +#ifndef __UAPI_DEF_IN6_ADDR
>  #define __UAPI_DEF_IN6_ADDR  1
> +#endif
> +#ifndef __UAPI_DEF_IN6_ADDR_ALT
>  #define __UAPI_DEF_IN6_ADDR_ALT  1
> +#endif
> +#ifndef __UAPI_DEF_SOCKADDR_IN6
>  #define __UAPI_DEF_SOCKADDR_IN6  1
> +#endif
> +#ifndef __UAPI_DEF_IPV6_MREQ
>  #define __UAPI_DEF_IPV6_MREQ 1
> +#endif
> +#ifndef __UAPI_DEF_IPPROTO_V6
>  #define __UAPI_DEF_IPPROTO_V61
> +#endif
> +#ifndef __UAPI_DEF_IPV6_OPTIONS
>  #define __UAPI_DEF_IPV6_OPTIONS  1
> +#endif
> +#ifndef __UAPI_DEF_IN6_PKTINFO
>  #de

Re: [musl] [PATCHv2] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

On 07/08/2017 10:27 PM, Felix Janda wrote:
> libc-compat.h aims to prevent symbol collisions between uapi and libc
> headers for each supported libc. This requires continuous coordination
> between them.
> 
> The goal of this commit is to improve the situation for libcs (such as
> musl) which are not yet supported and/or do not wish to be explicitly
> supported, while not affecting supported libcs. More precisely, with
> this commit, unsupported libcs can request the suppression of any
> specific uapi definition by defining the correspondings _UAPI_DEF_*
> macro as 0. This can fix symbol collisions for them, as long as the
> libc headers are included before the uapi headers. Inclusion in the
> other order is outside the scope of this commit.
> 
> All infrastructure in order to enable this fallback for unsupported
> libcs is already in place, except that libc-compat.h unconditionally
> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
> any previous definitions are ignored. In order to fix this, this commit
> merely makes these definitions conditional.
> 
> This commit together with the musl libc commit
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
> 
> fixes for example the following compiler errors when  is
> included after musl's :
> 
> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
> 
> Signed-off-by: Felix Janda 
> Acked-by: Rich Felker 
> ---
> v2: The only change to the previous version is the commit title and
> message.
> ---
>  include/uapi/linux/libc-compat.h | 52 
> 
>  1 file changed, 52 insertions(+)

Does the documentation at the top of this file need some updates?

> diff --git a/include/uapi/linux/libc-compat.h 
> b/include/uapi/linux/libc-compat.h
> index 44b8a6b..c316725 100644
> --- a/include/uapi/linux/libc-compat.h
> +++ b/include/uapi/linux/libc-compat.h
> @@ -171,42 +171,94 @@
>  #else /* !defined(__GLIBC__) */

Why don't you used #ifndef ?

>  /* Definitions for if.h */
> +#if !defined(__UAPI_DEF_IF_IFCONF)
>  #define __UAPI_DEF_IF_IFCONF 1
> +#endif
> +#if !defined(__UAPI_DEF_IF_IFMAP)
>  #define __UAPI_DEF_IF_IFMAP 1
> +#endif
> +#if !defined(__UAPI_DEF_IFNAMSIZ)

This should be:
#if !defined( __UAPI_DEF_IF_IFNAMSIZ)

>  #define __UAPI_DEF_IF_IFNAMSIZ 1
> +#endif
> +#if !defined(__UAPI_DEF_IFREQ)

This should be:
#if !defined(__UAPI_DEF_IF_IFREQ)

>  #define __UAPI_DEF_IF_IFREQ 1
> +#endif
>  /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
> +#if !defined(__UAPI_DEF_IF_NET_DEVICE_FLAGS)
>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
> +#endif
>  /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
> +#if !defined(__UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO)
>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
> +#endif
>  
>  /* Definitions for in.h */
> +#if !defined(__UAPI_DEF_IN_ADDR)
>  #define __UAPI_DEF_IN_ADDR   1
> +#endif
> +#if !defined(__UAPI_DEF_IN_IPPROTO)
>  #define __UAPI_DEF_IN_IPPROTO1
> +#endif
> +#if !defined(__UAPI_DEF_IN_PKTINFO)
>  #define __UAPI_DEF_IN_PKTINFO1
> +#endif
> +#if !defined(__UAPI_DEF_IP_MREQ)
>  #define __UAPI_DEF_IP_MREQ   1
> +#endif
> +#if !defined(__UAPI_DEF_SOCKADDR_IN)
>  #define __UAPI_DEF_SOCKADDR_IN   1
> +#endif
> +#if !defined(__UAPI_DEF_IN_CLASS)
>  #define __UAPI_DEF_IN_CLASS  1
> +#endif
>  
>  /* Definitions for in6.h */
> +#if !defined(__UAPI_DEF_IN6_ADDR)
>  #define __UAPI_DEF_IN6_ADDR  1
> +#endif
> +#if !defined(__UAPI_DEF_IN6_ADDR_ALT)
>  #define __UAPI_DEF_IN6_ADDR_ALT  1
> +#endif
> +#if !defined(__UAPI_DEF_SOCKADDR_IN6)
>  #define __UAPI_DEF_SOCKADDR_IN6  1
> +#endif
> +#if !defined(__UAPI_DEF_IPV6_MREQ)
>  #define __UAPI_DEF_IPV6_MREQ 1
> +#endif
> +#if !defined(__UAPI_DEF_IPPROTO_V6)
>  #define __UAPI_DEF_IPPROTO_V61
> +#endif
> +#if !defined(__UAPI_DEF_IPV6_OPTIONS)
>  #define __UAPI_DEF_IPV6_OPTIONS  1
> +#endif
> +#if !defined(__UAPI_DEF_IN6_PKTINFO)
>  #define __UAPI_DEF_IN6_PKTINFO   1
> +#endif
> +#if !defined(__UAPI_DEF_IP6_MTUINFO)
>  #define __UAPI_DEF_IP6_MTUINFO   1
> +#endif
>  
>  /* Definitions for ipx.h */
> +#if !defined(__UAPI_DEF_SOCKADDR_IPX)
>  #define __UAPI_DEF_SOCKADDR_IPX  1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_ROUTE_DEFINITION)
>  #define __UAPI_DEF_IPX_ROUTE_DEFINITION  1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_INTERFACE_DEFINITION)
>  #define __UAPI_DEF_IPX_INTERFACE_DEFINITION  1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_CONFIG_DATA)
>  #define __UAPI_DEF_IPX_CONFIG_DATA   1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_ROUTE_DEF)
>  #define 

Re: [musl] [PATCHv2] uapi libc compat: add fallback for unsupported libcs

[Hauke Mehrtens]

On 07/08/2017 10:27 PM, Felix Janda wrote:
> libc-compat.h aims to prevent symbol collisions between uapi and libc
> headers for each supported libc. This requires continuous coordination
> between them.
> 
> The goal of this commit is to improve the situation for libcs (such as
> musl) which are not yet supported and/or do not wish to be explicitly
> supported, while not affecting supported libcs. More precisely, with
> this commit, unsupported libcs can request the suppression of any
> specific uapi definition by defining the correspondings _UAPI_DEF_*
> macro as 0. This can fix symbol collisions for them, as long as the
> libc headers are included before the uapi headers. Inclusion in the
> other order is outside the scope of this commit.
> 
> All infrastructure in order to enable this fallback for unsupported
> libcs is already in place, except that libc-compat.h unconditionally
> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
> any previous definitions are ignored. In order to fix this, this commit
> merely makes these definitions conditional.
> 
> This commit together with the musl libc commit
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
> 
> fixes for example the following compiler errors when  is
> included after musl's :
> 
> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
> 
> Signed-off-by: Felix Janda 
> Acked-by: Rich Felker 
> ---
> v2: The only change to the previous version is the commit title and
> message.
> ---
>  include/uapi/linux/libc-compat.h | 52 
> 
>  1 file changed, 52 insertions(+)

Does the documentation at the top of this file need some updates?

> diff --git a/include/uapi/linux/libc-compat.h 
> b/include/uapi/linux/libc-compat.h
> index 44b8a6b..c316725 100644
> --- a/include/uapi/linux/libc-compat.h
> +++ b/include/uapi/linux/libc-compat.h
> @@ -171,42 +171,94 @@
>  #else /* !defined(__GLIBC__) */

Why don't you used #ifndef ?

>  /* Definitions for if.h */
> +#if !defined(__UAPI_DEF_IF_IFCONF)
>  #define __UAPI_DEF_IF_IFCONF 1
> +#endif
> +#if !defined(__UAPI_DEF_IF_IFMAP)
>  #define __UAPI_DEF_IF_IFMAP 1
> +#endif
> +#if !defined(__UAPI_DEF_IFNAMSIZ)

This should be:
#if !defined( __UAPI_DEF_IF_IFNAMSIZ)

>  #define __UAPI_DEF_IF_IFNAMSIZ 1
> +#endif
> +#if !defined(__UAPI_DEF_IFREQ)

This should be:
#if !defined(__UAPI_DEF_IF_IFREQ)

>  #define __UAPI_DEF_IF_IFREQ 1
> +#endif
>  /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
> +#if !defined(__UAPI_DEF_IF_NET_DEVICE_FLAGS)
>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
> +#endif
>  /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
> +#if !defined(__UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO)
>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
> +#endif
>  
>  /* Definitions for in.h */
> +#if !defined(__UAPI_DEF_IN_ADDR)
>  #define __UAPI_DEF_IN_ADDR   1
> +#endif
> +#if !defined(__UAPI_DEF_IN_IPPROTO)
>  #define __UAPI_DEF_IN_IPPROTO1
> +#endif
> +#if !defined(__UAPI_DEF_IN_PKTINFO)
>  #define __UAPI_DEF_IN_PKTINFO1
> +#endif
> +#if !defined(__UAPI_DEF_IP_MREQ)
>  #define __UAPI_DEF_IP_MREQ   1
> +#endif
> +#if !defined(__UAPI_DEF_SOCKADDR_IN)
>  #define __UAPI_DEF_SOCKADDR_IN   1
> +#endif
> +#if !defined(__UAPI_DEF_IN_CLASS)
>  #define __UAPI_DEF_IN_CLASS  1
> +#endif
>  
>  /* Definitions for in6.h */
> +#if !defined(__UAPI_DEF_IN6_ADDR)
>  #define __UAPI_DEF_IN6_ADDR  1
> +#endif
> +#if !defined(__UAPI_DEF_IN6_ADDR_ALT)
>  #define __UAPI_DEF_IN6_ADDR_ALT  1
> +#endif
> +#if !defined(__UAPI_DEF_SOCKADDR_IN6)
>  #define __UAPI_DEF_SOCKADDR_IN6  1
> +#endif
> +#if !defined(__UAPI_DEF_IPV6_MREQ)
>  #define __UAPI_DEF_IPV6_MREQ 1
> +#endif
> +#if !defined(__UAPI_DEF_IPPROTO_V6)
>  #define __UAPI_DEF_IPPROTO_V61
> +#endif
> +#if !defined(__UAPI_DEF_IPV6_OPTIONS)
>  #define __UAPI_DEF_IPV6_OPTIONS  1
> +#endif
> +#if !defined(__UAPI_DEF_IN6_PKTINFO)
>  #define __UAPI_DEF_IN6_PKTINFO   1
> +#endif
> +#if !defined(__UAPI_DEF_IP6_MTUINFO)
>  #define __UAPI_DEF_IP6_MTUINFO   1
> +#endif
>  
>  /* Definitions for ipx.h */
> +#if !defined(__UAPI_DEF_SOCKADDR_IPX)
>  #define __UAPI_DEF_SOCKADDR_IPX  1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_ROUTE_DEFINITION)
>  #define __UAPI_DEF_IPX_ROUTE_DEFINITION  1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_INTERFACE_DEFINITION)
>  #define __UAPI_DEF_IPX_INTERFACE_DEFINITION  1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_CONFIG_DATA)
>  #define __UAPI_DEF_IPX_CONFIG_DATA   1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_ROUTE_DEF)
>  #define __UAPI_DEF_IPX_ROUTE_DEF 1
> 

Re: [PATCH] MIPS: Lantiq: Fix ASC0/ASC1 clocks

[Hauke Mehrtens]

On 05/30/2017 06:34 AM, Martin Schiller wrote:
> ASC1 is available on every Lantiq SoC (also AmazonSE) and should be
> enabled like the other generic xway clocks instead of ASC0, which is
> only available for AR9 and Danube.

This is correct.

> Signed-off-by: Martin Schiller <m...@dev.tdt.de>

Acked-by: Hauke Mehrtens <ha...@hauke-m.de>

> ---
>  arch/mips/lantiq/xway/sysctrl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/mips/lantiq/xway/sysctrl.c b/arch/mips/lantiq/xway/sysctrl.c
> index 95bec46..cd6dbea 100644
> --- a/arch/mips/lantiq/xway/sysctrl.c
> +++ b/arch/mips/lantiq/xway/sysctrl.c
> @@ -484,9 +484,9 @@ void __init ltq_soc_init(void)
>  
>   /* add our generic xway clocks */
>   clkdev_add_pmu("1000.fpi", NULL, 0, 0, PMU_FPI);
> - clkdev_add_pmu("1e100400.serial", NULL, 0, 0, PMU_ASC0);
>   clkdev_add_pmu("1e100a00.gptu", NULL, 1, 0, PMU_GPT);
>   clkdev_add_pmu("1e100bb0.stp", NULL, 1, 0, PMU_STP);
> + clkdev_add_pmu("1e100c00.serial", NULL, 0, 0, PMU_ASC1);
>   clkdev_add_pmu("1e104100.dma", NULL, 1, 0, PMU_DMA);
>   clkdev_add_pmu("1e100800.spi", NULL, 1, 0, PMU_SPI);
>   clkdev_add_pmu("1e105300.ebu", NULL, 0, 0, PMU_EBU);
> @@ -501,7 +501,6 @@ void __init ltq_soc_init(void)
>   }
>  
>   if (!of_machine_is_compatible("lantiq,ase")) {
> - clkdev_add_pmu("1e100c00.serial", NULL, 0, 0, PMU_ASC1);
>   clkdev_add_pci();
>   }
>  
> 

Re: [PATCH] MIPS: Lantiq: Fix ASC0/ASC1 clocks

[Hauke Mehrtens]

On 05/30/2017 06:34 AM, Martin Schiller wrote:
> ASC1 is available on every Lantiq SoC (also AmazonSE) and should be
> enabled like the other generic xway clocks instead of ASC0, which is
> only available for AR9 and Danube.

This is correct.

> Signed-off-by: Martin Schiller 

Acked-by: Hauke Mehrtens 

> ---
>  arch/mips/lantiq/xway/sysctrl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/mips/lantiq/xway/sysctrl.c b/arch/mips/lantiq/xway/sysctrl.c
> index 95bec46..cd6dbea 100644
> --- a/arch/mips/lantiq/xway/sysctrl.c
> +++ b/arch/mips/lantiq/xway/sysctrl.c
> @@ -484,9 +484,9 @@ void __init ltq_soc_init(void)
>  
>   /* add our generic xway clocks */
>   clkdev_add_pmu("1000.fpi", NULL, 0, 0, PMU_FPI);
> - clkdev_add_pmu("1e100400.serial", NULL, 0, 0, PMU_ASC0);
>   clkdev_add_pmu("1e100a00.gptu", NULL, 1, 0, PMU_GPT);
>   clkdev_add_pmu("1e100bb0.stp", NULL, 1, 0, PMU_STP);
> + clkdev_add_pmu("1e100c00.serial", NULL, 0, 0, PMU_ASC1);
>   clkdev_add_pmu("1e104100.dma", NULL, 1, 0, PMU_DMA);
>   clkdev_add_pmu("1e100800.spi", NULL, 1, 0, PMU_SPI);
>   clkdev_add_pmu("1e105300.ebu", NULL, 0, 0, PMU_EBU);
> @@ -501,7 +501,6 @@ void __init ltq_soc_init(void)
>   }
>  
>   if (!of_machine_is_compatible("lantiq,ase")) {
> - clkdev_add_pmu("1e100c00.serial", NULL, 0, 0, PMU_ASC1);
>   clkdev_add_pci();
>   }
>  
> 

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

[Hauke Mehrtens]

On 03/08/2017 05:39 PM, Carlos O'Donell wrote:
> Any header needing compat with a libc includes libc-compat.h (per the 
> documented way the model works). With this patch any included linux kernel
> header that also includes libc-compat.h would immediately define all 
> the __UAPI_DEF_* constants to 1 as-if it had defined those structures, 
> but it has not.
> 
> For example, with these two patches applied, the inclusion of linux/if.h
> would define __UAPI_DEF_XATTR to 1, but linux/if.h has not defined
> XATTR_CREATE or other constants, so a subsequent inclusion sys/xattrs.h
> from userspace would _not_ define XATTR_CREATE because __UAPI_DEF_XATTR set
> to 1 indicates the kernel has.
> 
> I don't want to read into the model you are proposing and would rather you
> document the semantics clearly so we can all see what you mean.

What about moving the code from libc-comapt.h into the specific header
files? This way including linux/if.h would not have an impact on
__UAPI_DEF_XATTR, because this is defined in linux/xattr.h. We would
still have a problem when the specific Linux header file gets included
before the libc header file, but at least musl does not support this anyway.

Hauke

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

[Hauke Mehrtens]

On 03/08/2017 05:39 PM, Carlos O'Donell wrote:
> Any header needing compat with a libc includes libc-compat.h (per the 
> documented way the model works). With this patch any included linux kernel
> header that also includes libc-compat.h would immediately define all 
> the __UAPI_DEF_* constants to 1 as-if it had defined those structures, 
> but it has not.
> 
> For example, with these two patches applied, the inclusion of linux/if.h
> would define __UAPI_DEF_XATTR to 1, but linux/if.h has not defined
> XATTR_CREATE or other constants, so a subsequent inclusion sys/xattrs.h
> from userspace would _not_ define XATTR_CREATE because __UAPI_DEF_XATTR set
> to 1 indicates the kernel has.
> 
> I don't want to read into the model you are proposing and would rather you
> document the semantics clearly so we can all see what you mean.

What about moving the code from libc-comapt.h into the specific header
files? This way including linux/if.h would not have an impact on
__UAPI_DEF_XATTR, because this is defined in linux/xattr.h. We would
still have a problem when the specific Linux header file gets included
before the libc header file, but at least musl does not support this anyway.

Hauke

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

[Hauke Mehrtens]

On 03/08/2017 01:46 PM, David Woodhouse wrote:
> On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote:
>> Currently, libc-compat.h detects inclusion of specific glibc headers,
>> and defines corresponding _UAPI_DEF_* macros, which in turn are used in
>> uapi headers to prevent definition of conflicting structures/constants.
>> There is no such detection for other c libraries, for them the
>> _UAPI_DEF_* macros are always defined as 1, and so none of the possibly
>> conflicting definitions are suppressed.
>>
>> This patch enables non-glibc c libraries to request the suppression of
>> any specific interface by defining the corresponding _UAPI_DEF_* macro
>> as 0.
> 
> Ick. It's fairly horrid for kernel headers to be reacting to __GLIBC__
> in any way. That's just wrong.
> 
> It makes more sense for C libraries to define the __UAPI_DEF_xxx for
> themselves as and when they add their own support for certain things,
> and for the kernel not to have incestuous knowledge of them.
> 
> The part you add here in the #else /* !__GLIBC__ */ part is what we
> should do at *all* times.
> 
> I understand that we'll want to grandfather in the glibc horridness,
> but let's make it clear that that's what it is, by letting it set the
> appropriate __UAPI_DEF_xxx macros to zero, and then continue through to
> your new part. Something like this (incremental to yours):

Felix's and this change and are looking better than my patches here:
https://lkml.org/lkml/2017/3/12/235

Is someone working on brining this into the mainline kernel?

Is it correct that only the comments should be improved?
musl only supports including the musl header files before the kernel
anyway, I assume that it is not needed to make the kernel uapi code
support also the other order.

Hauke

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

[Hauke Mehrtens]

On 03/08/2017 01:46 PM, David Woodhouse wrote:
> On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote:
>> Currently, libc-compat.h detects inclusion of specific glibc headers,
>> and defines corresponding _UAPI_DEF_* macros, which in turn are used in
>> uapi headers to prevent definition of conflicting structures/constants.
>> There is no such detection for other c libraries, for them the
>> _UAPI_DEF_* macros are always defined as 1, and so none of the possibly
>> conflicting definitions are suppressed.
>>
>> This patch enables non-glibc c libraries to request the suppression of
>> any specific interface by defining the corresponding _UAPI_DEF_* macro
>> as 0.
> 
> Ick. It's fairly horrid for kernel headers to be reacting to __GLIBC__
> in any way. That's just wrong.
> 
> It makes more sense for C libraries to define the __UAPI_DEF_xxx for
> themselves as and when they add their own support for certain things,
> and for the kernel not to have incestuous knowledge of them.
> 
> The part you add here in the #else /* !__GLIBC__ */ part is what we
> should do at *all* times.
> 
> I understand that we'll want to grandfather in the glibc horridness,
> but let's make it clear that that's what it is, by letting it set the
> appropriate __UAPI_DEF_xxx macros to zero, and then continue through to
> your new part. Something like this (incremental to yours):

Felix's and this change and are looking better than my patches here:
https://lkml.org/lkml/2017/3/12/235

Is someone working on brining this into the mainline kernel?

Is it correct that only the comments should be improved?
musl only supports including the musl header files before the kernel
anyway, I assume that it is not needed to make the kernel uapi code
support also the other order.

Hauke

Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility

[Hauke Mehrtens]

On 04/20/2017 10:36 PM, David Miller wrote:
> From: David Woodhouse 
> Date: Thu, 20 Apr 2017 21:14:37 +0100
> 
>> I agree, except I don't think you're going far enough. Those "standard
>> names" you mention... some of this stuff actually depends on __GLIBC__,
>> and *that* isn't right either.
> 
> Yep, that's something that needs correcting.
> 
Should all libc implementations define __GLIBC__ or could we at least
switch the kernel UAPI to !__KERNEL__ here?

Hauke

Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility

[Hauke Mehrtens]

On 04/20/2017 10:36 PM, David Miller wrote:
> From: David Woodhouse 
> Date: Thu, 20 Apr 2017 21:14:37 +0100
> 
>> I agree, except I don't think you're going far enough. Those "standard
>> names" you mention... some of this stuff actually depends on __GLIBC__,
>> and *that* isn't right either.
> 
> Yep, that's something that needs correcting.
> 
Should all libc implementations define __GLIBC__ or could we at least
switch the kernel UAPI to !__KERNEL__ here?

Hauke

[PATCH v2 1/3] uapi glibc compat: add libc compat code when not build for kernel

[Hauke Mehrtens]

Instead of checking if this header file is used in the glibc, check if
it is not used in kernel context, this way it will also work with other
libc implementations like musl.

The __USE_MISC symbol is glibc specific and not available in musl libc.
Only do this check when glibc is used.

This is based on an older patch from David Heidelberger
<david.heidelber...@ixit.cz>

Acked-by: Mikko Rapeli <mikko.rap...@iki.fi>
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 include/uapi/linux/libc-compat.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 44b8a6bd5fe1..43a81136ea6e 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -48,11 +48,11 @@
 #ifndef _UAPI_LIBC_COMPAT_H
 #define _UAPI_LIBC_COMPAT_H
 
-/* We have included glibc headers... */
-#if defined(__GLIBC__)
+/* We have included libc headers... */
+#if !defined(__KERNEL__)
 
-/* Coordinate with glibc net/if.h header. */
-#if defined(_NET_IF_H) && defined(__USE_MISC)
+/* Coordinate with libc net/if.h header. */
+#if defined(_NET_IF_H) && (!defined(__GLIBC__) || defined(__USE_MISC))
 
 /* GLIBC headers included first so don't define anything
  * that would already be defined. */
@@ -168,7 +168,7 @@
 /* If we did not see any headers from any supported C libraries,
  * or we are being included in the kernel, then define everything
  * that we need. */
-#else /* !defined(__GLIBC__) */
+#else /* defined(__KERNEL__) */
 
 /* Definitions for if.h */
 #define __UAPI_DEF_IF_IFCONF 1
@@ -208,6 +208,6 @@
 /* Definitions for xattr.h */
 #define __UAPI_DEF_XATTR   1
 
-#endif /* __GLIBC__ */
+#endif /* __KERNEL__ */
 
 #endif /* _UAPI_LIBC_COMPAT_H */
-- 
2.11.0

[PATCH v2 1/3] uapi glibc compat: add libc compat code when not build for kernel

[Hauke Mehrtens]

Instead of checking if this header file is used in the glibc, check if
it is not used in kernel context, this way it will also work with other
libc implementations like musl.

The __USE_MISC symbol is glibc specific and not available in musl libc.
Only do this check when glibc is used.

This is based on an older patch from David Heidelberger


Acked-by: Mikko Rapeli 
Signed-off-by: Hauke Mehrtens 
---
 include/uapi/linux/libc-compat.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 44b8a6bd5fe1..43a81136ea6e 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -48,11 +48,11 @@
 #ifndef _UAPI_LIBC_COMPAT_H
 #define _UAPI_LIBC_COMPAT_H
 
-/* We have included glibc headers... */
-#if defined(__GLIBC__)
+/* We have included libc headers... */
+#if !defined(__KERNEL__)
 
-/* Coordinate with glibc net/if.h header. */
-#if defined(_NET_IF_H) && defined(__USE_MISC)
+/* Coordinate with libc net/if.h header. */
+#if defined(_NET_IF_H) && (!defined(__GLIBC__) || defined(__USE_MISC))
 
 /* GLIBC headers included first so don't define anything
  * that would already be defined. */
@@ -168,7 +168,7 @@
 /* If we did not see any headers from any supported C libraries,
  * or we are being included in the kernel, then define everything
  * that we need. */
-#else /* !defined(__GLIBC__) */
+#else /* defined(__KERNEL__) */
 
 /* Definitions for if.h */
 #define __UAPI_DEF_IF_IFCONF 1
@@ -208,6 +208,6 @@
 /* Definitions for xattr.h */
 #define __UAPI_DEF_XATTR   1
 
-#endif /* __GLIBC__ */
+#endif /* __KERNEL__ */
 
 #endif /* _UAPI_LIBC_COMPAT_H */
-- 
2.11.0

[PATCH v2 3/3] uapi/if_ether.h: prevent redefinition of struct ethhdr

[Hauke Mehrtens]

From: David Heidelberger <david.heidelber...@ixit.cz>

Musl provides its own ethhdr struct definition. Add a guard to prevent
its definition of the appropriate musl header has already been included.

Acked-by: Mikko Rapeli <mikko.rap...@iki.fi>
Signed-off-by: John Spencer <maillist-li...@barfooze.de>
Tested-by: David Heidelberger <david.heidelber...@ixit.cz>
Signed-off-by: Jonas Gorski <j...@openwrt.org>
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 include/uapi/linux/if_ether.h|  3 +++
 include/uapi/linux/libc-compat.h | 11 +++
 2 files changed, 14 insertions(+)

diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index 5bc9bfd816b7..fb5ab8c1e753 100644
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -22,6 +22,7 @@
 #define _UAPI_LINUX_IF_ETHER_H
 
 #include 
+#include 
 
 /*
  * IEEE 802.3 Ethernet magic constants.  The frame sizes omit the preamble
@@ -142,11 +143,13 @@
  * This is an Ethernet frame header.
  */
 
+#if __UAPI_DEF_ETHHDR
 struct ethhdr {
unsigned char   h_dest[ETH_ALEN];   /* destination eth addr */
unsigned char   h_source[ETH_ALEN]; /* source ether addr*/
__be16  h_proto;/* packet type ID field */
 } __attribute__((packed));
+#endif
 
 
 #endif /* _UAPI_LINUX_IF_ETHER_H */
diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index ce2fa8a4ced6..c92d32f213d1 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -87,6 +87,14 @@
 
 #endif /* _NET_IF_H */
 
+/* musl defines the ethhdr struct itself in its netinet/if_ether.h.
+ * Glibc just includes the kernel header and uses a different guard. */
+#if defined(_NETINET_IF_ETHER_H)
+#define __UAPI_DEF_ETHHDR  0
+#else
+#define __UAPI_DEF_ETHHDR  1
+#endif
+
 /* Coordinate with glibc netinet/in.h header. */
 #if defined(_NETINET_IN_H)
 
@@ -182,6 +190,9 @@
 /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
 
+/* Definitions for if_ether.h */
+#define __UAPI_DEF_ETHHDR  1
+
 /* Definitions for in.h */
 #define __UAPI_DEF_IN_ADDR 1
 #define __UAPI_DEF_IN_IPPROTO  1
-- 
2.11.0

[PATCH v2 3/3] uapi/if_ether.h: prevent redefinition of struct ethhdr

[Hauke Mehrtens]

From: David Heidelberger 

Musl provides its own ethhdr struct definition. Add a guard to prevent
its definition of the appropriate musl header has already been included.

Acked-by: Mikko Rapeli 
Signed-off-by: John Spencer 
Tested-by: David Heidelberger 
Signed-off-by: Jonas Gorski 
Signed-off-by: Hauke Mehrtens 
---
 include/uapi/linux/if_ether.h|  3 +++
 include/uapi/linux/libc-compat.h | 11 +++
 2 files changed, 14 insertions(+)

diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index 5bc9bfd816b7..fb5ab8c1e753 100644
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -22,6 +22,7 @@
 #define _UAPI_LINUX_IF_ETHER_H
 
 #include 
+#include 
 
 /*
  * IEEE 802.3 Ethernet magic constants.  The frame sizes omit the preamble
@@ -142,11 +143,13 @@
  * This is an Ethernet frame header.
  */
 
+#if __UAPI_DEF_ETHHDR
 struct ethhdr {
unsigned char   h_dest[ETH_ALEN];   /* destination eth addr */
unsigned char   h_source[ETH_ALEN]; /* source ether addr*/
__be16  h_proto;/* packet type ID field */
 } __attribute__((packed));
+#endif
 
 
 #endif /* _UAPI_LINUX_IF_ETHER_H */
diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index ce2fa8a4ced6..c92d32f213d1 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -87,6 +87,14 @@
 
 #endif /* _NET_IF_H */
 
+/* musl defines the ethhdr struct itself in its netinet/if_ether.h.
+ * Glibc just includes the kernel header and uses a different guard. */
+#if defined(_NETINET_IF_ETHER_H)
+#define __UAPI_DEF_ETHHDR  0
+#else
+#define __UAPI_DEF_ETHHDR  1
+#endif
+
 /* Coordinate with glibc netinet/in.h header. */
 #if defined(_NETINET_IN_H)
 
@@ -182,6 +190,9 @@
 /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
 
+/* Definitions for if_ether.h */
+#define __UAPI_DEF_ETHHDR  1
+
 /* Definitions for in.h */
 #define __UAPI_DEF_IN_ADDR 1
 #define __UAPI_DEF_IN_IPPROTO  1
-- 
2.11.0

[PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility

[Hauke Mehrtens]

The code from libc-compat.h depends on some glibc specific defines and 
causes compile problems with the musl libc. These patches remove some 
of the glibc dependencies. With these patches the LEDE (OpenWrt) base 
user space applications can be build with unmodified kernel headers and 
musl libc.

This was compile tested with the user space from LEDE (OpenWrt) with 
musl 1.1.16, glibc 2.25 and uClibc-ng 1.0.22.

Changes since v1:
 - fix typo in commit message
 - combine two changes


David Heidelberger (1):
  uapi/if_ether.h: prevent redefinition of struct ethhdr

Hauke Mehrtens (2):
  uapi glibc compat: add libc compat code when not build for kernel
  uapi glibc compat: fix build if libc defines IFF_ECHO

 include/uapi/linux/if_ether.h|  3 +++
 include/uapi/linux/libc-compat.h | 25 +++--
 2 files changed, 22 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility

[Hauke Mehrtens]

The code from libc-compat.h depends on some glibc specific defines and 
causes compile problems with the musl libc. These patches remove some 
of the glibc dependencies. With these patches the LEDE (OpenWrt) base 
user space applications can be build with unmodified kernel headers and 
musl libc.

This was compile tested with the user space from LEDE (OpenWrt) with 
musl 1.1.16, glibc 2.25 and uClibc-ng 1.0.22.

Changes since v1:
 - fix typo in commit message
 - combine two changes


David Heidelberger (1):
  uapi/if_ether.h: prevent redefinition of struct ethhdr

Hauke Mehrtens (2):
  uapi glibc compat: add libc compat code when not build for kernel
  uapi glibc compat: fix build if libc defines IFF_ECHO

 include/uapi/linux/if_ether.h|  3 +++
 include/uapi/linux/libc-compat.h | 25 +++--
 2 files changed, 22 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH v2 2/3] uapi glibc compat: fix build if libc defines IFF_ECHO

[Hauke Mehrtens]

musl 1.1.15 defines IFF_ECHO and the other net_device_flags options.
When a user application includes linux/if.h and net/if.h the compile
will fail.

Activate __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO only when
it is needed. This should also make this work in case glibc will add
these defines.

Acked-by: Mikko Rapeli <mikko.rap...@iki.fi>
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 include/uapi/linux/libc-compat.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 43a81136ea6e..ce2fa8a4ced6 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -64,9 +64,11 @@
 /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 0
 /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
+#ifndef IFF_ECHO
 #ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
 #endif /* __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO */
+#endif /* IFF_ECHO */
 
 #else /* _NET_IF_H */
 
-- 
2.11.0

[PATCH v2 2/3] uapi glibc compat: fix build if libc defines IFF_ECHO

[Hauke Mehrtens]

musl 1.1.15 defines IFF_ECHO and the other net_device_flags options.
When a user application includes linux/if.h and net/if.h the compile
will fail.

Activate __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO only when
it is needed. This should also make this work in case glibc will add
these defines.

Acked-by: Mikko Rapeli 
Signed-off-by: Hauke Mehrtens 
---
 include/uapi/linux/libc-compat.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 43a81136ea6e..ce2fa8a4ced6 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -64,9 +64,11 @@
 /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 0
 /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
+#ifndef IFF_ECHO
 #ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
 #endif /* __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO */
+#endif /* IFF_ECHO */
 
 #else /* _NET_IF_H */
 
-- 
2.11.0

[PATCH resend 1/4] uapi glibc compat: add libc compat code when not build for kernel

[Hauke Mehrtens]

Instead of checking if this header file is used in the glibc, check if
iti is not used in kernel context, this way it will also work with
other libc implementations like musl.

Acked-by: Mikko Rapeli <mikko.rap...@iki.fi>
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 include/uapi/linux/libc-compat.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 44b8a6bd5fe1..7c1fead03c50 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -48,8 +48,8 @@
 #ifndef _UAPI_LIBC_COMPAT_H
 #define _UAPI_LIBC_COMPAT_H
 
-/* We have included glibc headers... */
-#if defined(__GLIBC__)
+/* We have included libc headers... */
+#if !defined(__KERNEL__)
 
 /* Coordinate with glibc net/if.h header. */
 #if defined(_NET_IF_H) && defined(__USE_MISC)
@@ -168,7 +168,7 @@
 /* If we did not see any headers from any supported C libraries,
  * or we are being included in the kernel, then define everything
  * that we need. */
-#else /* !defined(__GLIBC__) */
+#else /* defined(__KERNEL__) */
 
 /* Definitions for if.h */
 #define __UAPI_DEF_IF_IFCONF 1
@@ -208,6 +208,6 @@
 /* Definitions for xattr.h */
 #define __UAPI_DEF_XATTR   1
 
-#endif /* __GLIBC__ */
+#endif /* __KERNEL__ */
 
 #endif /* _UAPI_LIBC_COMPAT_H */
-- 
2.11.0

[PATCH resend 1/4] uapi glibc compat: add libc compat code when not build for kernel

[Hauke Mehrtens]

Instead of checking if this header file is used in the glibc, check if
iti is not used in kernel context, this way it will also work with
other libc implementations like musl.

Acked-by: Mikko Rapeli 
Signed-off-by: Hauke Mehrtens 
---
 include/uapi/linux/libc-compat.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 44b8a6bd5fe1..7c1fead03c50 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -48,8 +48,8 @@
 #ifndef _UAPI_LIBC_COMPAT_H
 #define _UAPI_LIBC_COMPAT_H
 
-/* We have included glibc headers... */
-#if defined(__GLIBC__)
+/* We have included libc headers... */
+#if !defined(__KERNEL__)
 
 /* Coordinate with glibc net/if.h header. */
 #if defined(_NET_IF_H) && defined(__USE_MISC)
@@ -168,7 +168,7 @@
 /* If we did not see any headers from any supported C libraries,
  * or we are being included in the kernel, then define everything
  * that we need. */
-#else /* !defined(__GLIBC__) */
+#else /* defined(__KERNEL__) */
 
 /* Definitions for if.h */
 #define __UAPI_DEF_IF_IFCONF 1
@@ -208,6 +208,6 @@
 /* Definitions for xattr.h */
 #define __UAPI_DEF_XATTR   1
 
-#endif /* __GLIBC__ */
+#endif /* __KERNEL__ */
 
 #endif /* _UAPI_LIBC_COMPAT_H */
-- 
2.11.0

[PATCH resend 3/4] uapi glibc compat: Do not check for __USE_MISC

[Hauke Mehrtens]

__USE_MISC is glibc specific and not available in musl libc. Only do
this check when glibc is used. This fixes a problem with musl libc.

Acked-by: Mikko Rapeli <mikko.rap...@iki.fi>
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 include/uapi/linux/libc-compat.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 49a8cc3138ae..ce2fa8a4ced6 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -51,8 +51,8 @@
 /* We have included libc headers... */
 #if !defined(__KERNEL__)
 
-/* Coordinate with glibc net/if.h header. */
-#if defined(_NET_IF_H) && defined(__USE_MISC)
+/* Coordinate with libc net/if.h header. */
+#if defined(_NET_IF_H) && (!defined(__GLIBC__) || defined(__USE_MISC))
 
 /* GLIBC headers included first so don't define anything
  * that would already be defined. */
-- 
2.11.0

[PATCH resend 4/4] uapi/if_ether.h: prevent redefinition of struct ethhdr

[Hauke Mehrtens]

From: David Heidelberger <david.heidelber...@ixit.cz>

Musl provides its own ethhdr struct definition. Add a guard to prevent
its definition of the appropriate musl header has already been included.

Acked-by: Mikko Rapeli <mikko.rap...@iki.fi>
Signed-off-by: John Spencer <maillist-li...@barfooze.de>
Tested-by: David Heidelberger <david.heidelber...@ixit.cz>
Signed-off-by: Jonas Gorski <j...@openwrt.org>
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 include/uapi/linux/if_ether.h|  3 +++
 include/uapi/linux/libc-compat.h | 11 +++
 2 files changed, 14 insertions(+)

diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index 5bc9bfd816b7..fb5ab8c1e753 100644
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -22,6 +22,7 @@
 #define _UAPI_LINUX_IF_ETHER_H
 
 #include 
+#include 
 
 /*
  * IEEE 802.3 Ethernet magic constants.  The frame sizes omit the preamble
@@ -142,11 +143,13 @@
  * This is an Ethernet frame header.
  */
 
+#if __UAPI_DEF_ETHHDR
 struct ethhdr {
unsigned char   h_dest[ETH_ALEN];   /* destination eth addr */
unsigned char   h_source[ETH_ALEN]; /* source ether addr*/
__be16  h_proto;/* packet type ID field */
 } __attribute__((packed));
+#endif
 
 
 #endif /* _UAPI_LINUX_IF_ETHER_H */
diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index ce2fa8a4ced6..c92d32f213d1 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -87,6 +87,14 @@
 
 #endif /* _NET_IF_H */
 
+/* musl defines the ethhdr struct itself in its netinet/if_ether.h.
+ * Glibc just includes the kernel header and uses a different guard. */
+#if defined(_NETINET_IF_ETHER_H)
+#define __UAPI_DEF_ETHHDR  0
+#else
+#define __UAPI_DEF_ETHHDR  1
+#endif
+
 /* Coordinate with glibc netinet/in.h header. */
 #if defined(_NETINET_IN_H)
 
@@ -182,6 +190,9 @@
 /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
 
+/* Definitions for if_ether.h */
+#define __UAPI_DEF_ETHHDR  1
+
 /* Definitions for in.h */
 #define __UAPI_DEF_IN_ADDR 1
 #define __UAPI_DEF_IN_IPPROTO  1
-- 
2.11.0

[PATCH resend 3/4] uapi glibc compat: Do not check for __USE_MISC

[Hauke Mehrtens]

__USE_MISC is glibc specific and not available in musl libc. Only do
this check when glibc is used. This fixes a problem with musl libc.

Acked-by: Mikko Rapeli 
Signed-off-by: Hauke Mehrtens 
---
 include/uapi/linux/libc-compat.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 49a8cc3138ae..ce2fa8a4ced6 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -51,8 +51,8 @@
 /* We have included libc headers... */
 #if !defined(__KERNEL__)
 
-/* Coordinate with glibc net/if.h header. */
-#if defined(_NET_IF_H) && defined(__USE_MISC)
+/* Coordinate with libc net/if.h header. */
+#if defined(_NET_IF_H) && (!defined(__GLIBC__) || defined(__USE_MISC))
 
 /* GLIBC headers included first so don't define anything
  * that would already be defined. */
-- 
2.11.0

[PATCH resend 4/4] uapi/if_ether.h: prevent redefinition of struct ethhdr

[Hauke Mehrtens]

From: David Heidelberger 

Musl provides its own ethhdr struct definition. Add a guard to prevent
its definition of the appropriate musl header has already been included.

Acked-by: Mikko Rapeli 
Signed-off-by: John Spencer 
Tested-by: David Heidelberger 
Signed-off-by: Jonas Gorski 
Signed-off-by: Hauke Mehrtens 
---
 include/uapi/linux/if_ether.h|  3 +++
 include/uapi/linux/libc-compat.h | 11 +++
 2 files changed, 14 insertions(+)

diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index 5bc9bfd816b7..fb5ab8c1e753 100644
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -22,6 +22,7 @@
 #define _UAPI_LINUX_IF_ETHER_H
 
 #include 
+#include 
 
 /*
  * IEEE 802.3 Ethernet magic constants.  The frame sizes omit the preamble
@@ -142,11 +143,13 @@
  * This is an Ethernet frame header.
  */
 
+#if __UAPI_DEF_ETHHDR
 struct ethhdr {
unsigned char   h_dest[ETH_ALEN];   /* destination eth addr */
unsigned char   h_source[ETH_ALEN]; /* source ether addr*/
__be16  h_proto;/* packet type ID field */
 } __attribute__((packed));
+#endif
 
 
 #endif /* _UAPI_LINUX_IF_ETHER_H */
diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index ce2fa8a4ced6..c92d32f213d1 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -87,6 +87,14 @@
 
 #endif /* _NET_IF_H */
 
+/* musl defines the ethhdr struct itself in its netinet/if_ether.h.
+ * Glibc just includes the kernel header and uses a different guard. */
+#if defined(_NETINET_IF_ETHER_H)
+#define __UAPI_DEF_ETHHDR  0
+#else
+#define __UAPI_DEF_ETHHDR  1
+#endif
+
 /* Coordinate with glibc netinet/in.h header. */
 #if defined(_NETINET_IN_H)
 
@@ -182,6 +190,9 @@
 /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
 
+/* Definitions for if_ether.h */
+#define __UAPI_DEF_ETHHDR  1
+
 /* Definitions for in.h */
 #define __UAPI_DEF_IN_ADDR 1
 #define __UAPI_DEF_IN_IPPROTO  1
-- 
2.11.0

[PATCH resend 2/4] uapi glibc compat: fix build if libc defines IFF_ECHO

[Hauke Mehrtens]

musl 1.1.15 defines IFF_ECHO and the other net_device_flags options.
When a user application includes linux/if.h and net/if.h the compile
will fail.

Activate __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO only when
it is needed. This should also make this work in case glibc will add
these defines.

Acked-by: Mikko Rapeli <mikko.rap...@iki.fi>
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 include/uapi/linux/libc-compat.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 7c1fead03c50..49a8cc3138ae 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -64,9 +64,11 @@
 /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 0
 /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
+#ifndef IFF_ECHO
 #ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
 #endif /* __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO */
+#endif /* IFF_ECHO */
 
 #else /* _NET_IF_H */
 
-- 
2.11.0

[PATCH resend 0/4] uapi glibc compat: fix musl libc compatibility

[Hauke Mehrtens]

The code from libc-compat.h depends on some glibc specific defines and 
causes compile problems with the musl libc. These patches remove some 
of the glibc dependencies. With these patches the LEDE (OpenWrt) base 
user space applications can be build with unmodified kernel headers and 
musl libc.

This was compile tested with the user space from LEDE (OpenWrt) with 
musl 1.1.16, glibc 2.25 and uClibc-ng 1.0.22.


David Heidelberger (1):
  uapi/if_ether.h: prevent redefinition of struct ethhdr

Hauke Mehrtens (3):
  uapi glibc compat: add libc compat code when not build for kernel
  uapi glibc compat: fix build if libc defines IFF_ECHO
  uapi glibc compat: Do not check for __USE_MISC

 include/uapi/linux/if_ether.h|  3 +++
 include/uapi/linux/libc-compat.h | 25 +++--
 2 files changed, 22 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH resend 2/4] uapi glibc compat: fix build if libc defines IFF_ECHO

[Hauke Mehrtens]

musl 1.1.15 defines IFF_ECHO and the other net_device_flags options.
When a user application includes linux/if.h and net/if.h the compile
will fail.

Activate __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO only when
it is needed. This should also make this work in case glibc will add
these defines.

Acked-by: Mikko Rapeli 
Signed-off-by: Hauke Mehrtens 
---
 include/uapi/linux/libc-compat.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 7c1fead03c50..49a8cc3138ae 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -64,9 +64,11 @@
 /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 0
 /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
+#ifndef IFF_ECHO
 #ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
 #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
 #endif /* __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO */
+#endif /* IFF_ECHO */
 
 #else /* _NET_IF_H */
 
-- 
2.11.0

[PATCH resend 0/4] uapi glibc compat: fix musl libc compatibility

[Hauke Mehrtens]

The code from libc-compat.h depends on some glibc specific defines and 
causes compile problems with the musl libc. These patches remove some 
of the glibc dependencies. With these patches the LEDE (OpenWrt) base 
user space applications can be build with unmodified kernel headers and 
musl libc.

This was compile tested with the user space from LEDE (OpenWrt) with 
musl 1.1.16, glibc 2.25 and uClibc-ng 1.0.22.


David Heidelberger (1):
  uapi/if_ether.h: prevent redefinition of struct ethhdr

Hauke Mehrtens (3):
  uapi glibc compat: add libc compat code when not build for kernel
  uapi glibc compat: fix build if libc defines IFF_ECHO
  uapi glibc compat: Do not check for __USE_MISC

 include/uapi/linux/if_ether.h|  3 +++
 include/uapi/linux/libc-compat.h | 25 +++--
 2 files changed, 22 insertions(+), 6 deletions(-)

-- 
2.11.0

Re: [PATCH 0/4] uapi glibc compat: fix musl libc compatibility

[Hauke Mehrtens]

On 2017-03-12 23:00, Hauke Mehrtens wrote:

The code from libc-compat.h depends on some glibc specific defines and
causes compile problems with the musl libc. These patches remove some
of the glibc dependencies. With these patches the LEDE (OpenWrt) base
user space applications can be build with unmodified kernel headers and
musl libc.

This was compile tested with the user space from LEDE (OpenWrt) with
musl 1.1.16, glibc 2.25 and uClibc-ng 1.0.22.

David Heidelberger (1):
  uapi/if_ether.h: prevent redefinition of struct ethhdr

Hauke Mehrtens (3):
  uapi glibc compat: add libc compat code when not build for kernel
  uapi glibc compat: fix build if libc defines IFF_ECHO
  uapi glibc compat: Do not check for __USE_MISC

 include/uapi/linux/if_ether.h|  3 +++
 include/uapi/linux/libc-compat.h | 25 +++--
 2 files changed, 22 insertions(+), 6 deletions(-)


Did I send this to the correct maintainer? I am unsure through which
maintainer this should go. I saw that some patches for the libc-compat.h
file went trough David Miller, so I tried the same.

Hauke

Re: [PATCH 0/4] uapi glibc compat: fix musl libc compatibility

[Hauke Mehrtens]

On 2017-03-12 23:00, Hauke Mehrtens wrote:

The code from libc-compat.h depends on some glibc specific defines and
causes compile problems with the musl libc. These patches remove some
of the glibc dependencies. With these patches the LEDE (OpenWrt) base
user space applications can be build with unmodified kernel headers and
musl libc.

This was compile tested with the user space from LEDE (OpenWrt) with
musl 1.1.16, glibc 2.25 and uClibc-ng 1.0.22.

David Heidelberger (1):
  uapi/if_ether.h: prevent redefinition of struct ethhdr

Hauke Mehrtens (3):
  uapi glibc compat: add libc compat code when not build for kernel
  uapi glibc compat: fix build if libc defines IFF_ECHO
  uapi glibc compat: Do not check for __USE_MISC

 include/uapi/linux/if_ether.h|  3 +++
 include/uapi/linux/libc-compat.h | 25 +++--
 2 files changed, 22 insertions(+), 6 deletions(-)


Did I send this to the correct maintainer? I am unsure through which
maintainer this should go. I saw that some patches for the libc-compat.h
file went trough David Miller, so I tried the same.

Hauke

Re: [PATCH 3/4] uapi glibc compat: Do not check for __USE_MISC

[Hauke Mehrtens]

On 03/16/2017 09:26 AM, Mikko Rapeli wrote:
> On Thu, Mar 16, 2017 at 07:59:12AM +, David Woodhouse wrote:
>> On Sun, 2017-03-12 at 23:00 +0100, Hauke Mehrtens wrote:
>>> __USE_MISC is glibc specific and not available in musl libc. Only do
>>> this check when glibc is used. This fixes a problem with musl libc.
>>> ...
>>> -/* Coordinate with glibc net/if.h header. */
>>> -#if defined(_NET_IF_H) && defined(__USE_MISC)
>>> +/* Coordinate with libc net/if.h header. */
>>> +#if defined(_NET_IF_H) && (!defined(__GLIBC__) || defined(__USE_MISC))
>>
>> I *really* don't like building up a plethora of knowledge about
>> specific libc implementations in the kernel. As a general rule, if we
>> have *anything* that depends on __GLIBC__ then we are Doing It Wrong™.
> 
> Kernel does not depend on glibc but uapi headers check for some defintions
> so that userspace code can include both libc and kernel header files
> without compiler errors.
> 
> This interface between kernel and libc header files is messy due to long
> history of copying header files from kernel to libc implementations etc
> and thus this kind of ifdef magic with in depth knowledge of various
> libc's defintions is currently unavoidable.

I agree with you David.
Should I change my patch?

The check for __USE_MISC was added in this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f0a3fdca794d1e68ae284ef4caefe681f7c18e89

musl does not define it, but still adds the defines which glibc adds
when __USE_MISC is set.

Hauke