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 = &priv->ch[i];
+ int ret;

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

   if (IS_TX(i)) {
   ltq_dma_alloc_tx(&ch->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(&ch->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 = &gswip_xrx200 },
+   { .compatible = "lantiq,xrx300-gswip", .data = &gswip_xrx300 },
+   { .compatible = "lantiq,xrx330-gswip", .data = &gswip_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 common

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&task_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 = &pdev->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 &icu0 29 1 // slot 14, irq 29
>> +0x7000 0 0 1 &ebu0 0 IRQ_TYPE_LEVEL_LOW // slot 
>> 14
>>  >;
>>  gpios-reset = <&gpio 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(&bcm47xx_bus.bcma);
if (err)
panic("Failed to initialize BCMA bus (err %d)&quo

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

[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: [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 = &asc0;
> + };
> +
> + 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 = <&cgu 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 = <&cpu_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

[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 
> 
> 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 

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(&priv->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(&priv->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&q=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&o=newest&f=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: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 

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

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_A

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 = &rtl8189etv;
> + };
> +};
> +

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.

> +&ohci1 {
> + /*
> +  * 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";
> +};
> +
> +&mmc1 {
> + 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 
> 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: 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 

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
> +#ifnd

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
> +#e

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 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

[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 

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 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 
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 
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 
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 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

Re: [PATCH] MIPS: smp-mt: fix missing task_stack_page compile error

[Hauke Mehrtens]

On 03/12/2017 07:15 PM, Hauke Mehrtens wrote:
> arch/mips/include/asm/processor.h references task_stack_page, but it is
> not defined anywhere. Including linux/sched/task_stack.h directly in
> asm/processor.h caused a different compile warning.
> 
> This fixes the folowing compile error in kernel 4.11-rc1:
>   CC  arch/mips/kernel/smp-mt.o
> In file included from ./arch/mips/include/asm/irq.h:16:0,
>  from ./include/linux/irq.h:26,
>  from ./include/asm-generic/hardirq.h:12,
>  from ./arch/mips/include/asm/hardirq.h:16,
>  from ./include/linux/hardirq.h:8,
>  from ./include/linux/interrupt.h:12,
>  from arch/mips/kernel/smp-mt.c:23:
> arch/mips/kernel/smp-mt.c: In function 'vsmp_boot_secondary':
> ./arch/mips/include/asm/processor.h:384:41: error: implicit declaration of 
> function 'task_stack_page' [-Werror=implicit-function-declaration]
>  #define __KSTK_TOS(tsk) ((unsigned long)task_stack_page(tsk) + \
>  ^
> ./arch/mips/include/asm/mipsmtregs.h:339:11: note: in definition of macro 
> 'mttgpr'
>   : : "r" (v));   \
>^
> arch/mips/kernel/smp-mt.c:215:2: note: in expansion of macro 'write_tc_gpr_sp'
>   write_tc_gpr_sp( __KSTK_TOS(idle));
>   ^
> arch/mips/kernel/smp-mt.c:215:19: note: in expansion of macro '__KSTK_TOS'
>   write_tc_gpr_sp( __KSTK_TOS(idle));
>^
> cc1: all warnings being treated as errors
> scripts/Makefile.build:294: recipe for target 'arch/mips/kernel/smp-mt.o' 
> failed
> 
> Fixes: f3ac60671954 ("sched/headers: Move task-stack related APIs from 
>  to ")
> Signed-off-by: Hauke Mehrtens 
> ---
>  arch/mips/kernel/smp-mt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/mips/kernel/smp-mt.c b/arch/mips/kernel/smp-mt.c
> index e077ea3e11fb..effc1ed18954 100644
> --- a/arch/mips/kernel/smp-mt.c
> +++ b/arch/mips/kernel/smp-mt.c
> @@ -18,7 +18,7 @@
>   * Copyright (C) 2006 Ralf Baechle (r...@linux-mips.org)
>   */
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 

This is already fixed in this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc69910f329d61821897871e0e957eda39beb3d8

Hauke

[PATCH 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.

Signed-off-by: John Spencer 
Tested-by: David Heidelberger 
Signed-off-by: Jonas Gorski 
---
 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 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 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.

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 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.

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 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.

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] MIPS: smp-mt: fix missing task_stack_page compile error

[Hauke Mehrtens]

arch/mips/include/asm/processor.h references task_stack_page, but it is
not defined anywhere. Including linux/sched/task_stack.h directly in
asm/processor.h caused a different compile warning.

This fixes the folowing compile error in kernel 4.11-rc1:
  CC  arch/mips/kernel/smp-mt.o
In file included from ./arch/mips/include/asm/irq.h:16:0,
 from ./include/linux/irq.h:26,
 from ./include/asm-generic/hardirq.h:12,
 from ./arch/mips/include/asm/hardirq.h:16,
 from ./include/linux/hardirq.h:8,
 from ./include/linux/interrupt.h:12,
 from arch/mips/kernel/smp-mt.c:23:
arch/mips/kernel/smp-mt.c: In function 'vsmp_boot_secondary':
./arch/mips/include/asm/processor.h:384:41: error: implicit declaration of 
function 'task_stack_page' [-Werror=implicit-function-declaration]
 #define __KSTK_TOS(tsk) ((unsigned long)task_stack_page(tsk) + \
 ^
./arch/mips/include/asm/mipsmtregs.h:339:11: note: in definition of macro 
'mttgpr'
  : : "r" (v));   \
   ^
arch/mips/kernel/smp-mt.c:215:2: note: in expansion of macro 'write_tc_gpr_sp'
  write_tc_gpr_sp( __KSTK_TOS(idle));
  ^
arch/mips/kernel/smp-mt.c:215:19: note: in expansion of macro '__KSTK_TOS'
  write_tc_gpr_sp( __KSTK_TOS(idle));
   ^
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target 'arch/mips/kernel/smp-mt.o' failed

Fixes: f3ac60671954 ("sched/headers: Move task-stack related APIs from 
 to ")
Signed-off-by: Hauke Mehrtens 
---
 arch/mips/kernel/smp-mt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/kernel/smp-mt.c b/arch/mips/kernel/smp-mt.c
index e077ea3e11fb..effc1ed18954 100644
--- a/arch/mips/kernel/smp-mt.c
+++ b/arch/mips/kernel/smp-mt.c
@@ -18,7 +18,7 @@
  * Copyright (C) 2006 Ralf Baechle (r...@linux-mips.org)
  */
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.11.0

Re: [PATCH v2] MAINTAINERS: Add Jon Mason to BCM5301X maintainers

[Hauke Mehrtens]

On 02/09/2017 12:43 AM, Jon Mason wrote:
> Adding myself as a maintainer for Broadcom Northstar SoCs.  Also, adding
> a regex entry to discover the SVK DTs already present.
> 
> Signed-off-by: Jon Mason 

Acked-by: Hauke Mehrtens 

> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2abda6c..70f4b62 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2641,12 +2641,14 @@ F:arch/mips/include/asm/mach-bcm47xx/*
>  BROADCOM BCM5301X ARM ARCHITECTURE
>  M:   Hauke Mehrtens 
>  M:   Rafał Miłecki 
> +M:   Jon Mason 
>  M:   bcm-kernel-feedback-l...@broadcom.com
>  L:   linux-arm-ker...@lists.infradead.org
>  S:   Maintained
>  F:   arch/arm/mach-bcm/bcm_5301x.c
>  F:   arch/arm/boot/dts/bcm5301x*.dtsi
>  F:   arch/arm/boot/dts/bcm470*
> +F:   arch/arm/boot/dts/bcm953012*
>  
>  BROADCOM BCM53573 ARM ARCHITECTURE
>  M:   Rafał Miłecki 
> 

Re: [PATCH] spi: lantiq-ssc: fix platform_no_drv_owner.cocci warnings

[Hauke Mehrtens]

On 02/19/2017 06:33 PM, kbuild test robot wrote:
> drivers/spi/spi-lantiq-ssc.c:973:3-8: No need to set .owner here. The core 
> will do it.
> 
>  Remove .owner field if calls are used which set it automatically
> 
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> 
> CC: Hauke Mehrtens 
> Signed-off-by: Fengguang Wu 

Acked-by: Hauke Mehrtens 

> ---
> 
>  spi-lantiq-ssc.c |1 -
>  1 file changed, 1 deletion(-)
> 
> --- a/drivers/spi/spi-lantiq-ssc.c
> +++ b/drivers/spi/spi-lantiq-ssc.c
> @@ -970,7 +970,6 @@ static struct platform_driver lantiq_ssc
>   .remove = lantiq_ssc_remove,
>   .driver = {
>   .name = "spi-lantiq-ssc",
> - .owner = THIS_MODULE,
>   .of_match_table = lantiq_ssc_match,
>   },
>  };
> 

[PATCH] 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.

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 44b8a6bd5fe1..dbf16a3de4d2 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

Re: [PATCH] mtd: nand: fix implicit module.h usage in xway_nand.c

[Hauke Mehrtens]

On 12/22/2016 12:27 AM, kbuild test robot wrote:
> Hi Paul,
> 
> [auto build test ERROR on mtd/master]
> [also build test ERROR on v4.9 next-20161221]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Paul-Gortmaker/mtd-nand-fix-implicit-module-h-usage-in-xway_nand-c/20161221-115714
> base:   git://git.infradead.org/linux-mtd.git master
> config: mips-xway_defconfig (attached as .config)
> compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=mips 
> 
> All errors (new ones prefixed by >>):
> 
>arch/mips/built-in.o: In function `vpe_run':
>>> (.text+0x148f0): undefined reference to `physical_memsize'
>arch/mips/built-in.o: In function `vpe_run':
>(.text+0x148f4): undefined reference to `physical_memsize'
Let me look into this, it is probably caused by activating a "bad"
config option and not related to GPIO at all.

Hauke

Re: [PATCH] mtd: nand: fix implicit module.h usage in xway_nand.c

[Hauke Mehrtens]

On 12/22/2016 10:01 AM, Boris Brezillon wrote:
> +Brian
> 
> On Wed, 21 Dec 2016 16:19:00 +0100
> Hauke Mehrtens  wrote:
> 
>> On 12/20/2016 10:18 PM, Paul Gortmaker wrote:
>>> In commit d47529b2e9fe0ec2eb1f072afad8849f52e385c4 ("gpio: don't
>>> include module.h in shared driver header") we fixed a bunch of
>>> implicit includes and then did what the shortlog says -- remove
>>> module.h from a gpio header.
>>>
>>> In parallel, commit 024366750c2e04fdcda8bca685194ef0196b35fe
>>> ("mtd: nand: xway: convert to normal platform driver") added new
>>> modular function calls to a file that now became relying on the
>>> above module.h presence in the gpio header, since it did not
>>> explicitly include module.h header for them as part of the change.
>>>
>>> The problem only appears when the two dev streams are merged.
>>>
>>> Since the file is tristate, the fix is obvious -- it needs an
>>> explicit include of module.h header.  
>>
>> Hi Paul,
>>
>> the xway nand driver does not build as a module, so I made it bool, this
>> patch:
>> http://lists.infradead.org/pipermail/linux-mtd/2016-December/070800.html
>> And then made it use the non module versions here:
>> http://lists.infradead.org/pipermail/linux-mtd/2016-December/070801.html
>>
>> In the beginning I also came up with the same patch as you, but the mtd
>> people suggested to do it differently. I hope my two patches are on
>> their way into Linus tree.
> 
> Yep. Just waiting for Linus to release 4.10-rc1 to rebase my nand/next
> branch and start applying new patches. It should be queued for 4.11 and
> backported to all previous release (thanks to the Cc-stable + Fixes
> tags).
> 
> I didn't plan to take these fixes in one of the 4.10-rc fixes PR, since
> this bug is here for several releases, and no-one complained before.
> Let me know if you think otherwise, I'll add my ack and ask Brian to
> take it in the MTD tree.

The difference is that the NAND driver built when build in kernel till
4.9 because the module.h header file was included indirectly. This broke
by the combination of the two commits mentioned by Paul.

Hauke

Re: [PATCH] mtd: nand: fix implicit module.h usage in xway_nand.c

[Hauke Mehrtens]

On 12/20/2016 10:18 PM, Paul Gortmaker wrote:
> In commit d47529b2e9fe0ec2eb1f072afad8849f52e385c4 ("gpio: don't
> include module.h in shared driver header") we fixed a bunch of
> implicit includes and then did what the shortlog says -- remove
> module.h from a gpio header.
> 
> In parallel, commit 024366750c2e04fdcda8bca685194ef0196b35fe
> ("mtd: nand: xway: convert to normal platform driver") added new
> modular function calls to a file that now became relying on the
> above module.h presence in the gpio header, since it did not
> explicitly include module.h header for them as part of the change.
> 
> The problem only appears when the two dev streams are merged.
> 
> Since the file is tristate, the fix is obvious -- it needs an
> explicit include of module.h header.

Hi Paul,

the xway nand driver does not build as a module, so I made it bool, this
patch:
http://lists.infradead.org/pipermail/linux-mtd/2016-December/070800.html
And then made it use the non module versions here:
http://lists.infradead.org/pipermail/linux-mtd/2016-December/070801.html

In the beginning I also came up with the same patch as you, but the mtd
people suggested to do it differently. I hope my two patches are on
their way into Linus tree.

Hauke

Re: [PATCH dt V2] ARM: BCM5301X: Enable UART by default for BCM4708(1), BCM4709(4) & BCM53012

[Hauke Mehrtens]

On 12/01/2016 06:40 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Every device tested so far got UART0 (at 0x18000300) working as serial
> console. It's most likely part of reference design and all vendors use
> it that way.

I think the last 4 boards are some of the reference boards. ;-)

> It seems to be easier to enable it by default and just disable it if we
> ever see a device with different hardware design.
> 
> Signed-off-by: Rafał Miłecki 

Acked-by: Hauke Mehrtens 

> ---
> V2: Update bcm94708.dts bcm94709.dts bcm953012er.dts & bcm953012k.dts
> ---
>  arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts  | 4 
>  arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts   | 4 
>  arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts   | 4 
>  arch/arm/boot/dts/bcm4708-netgear-r6250.dts| 4 
>  arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts  | 4 
>  arch/arm/boot/dts/bcm4708.dtsi | 4 
>  arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 4 
>  arch/arm/boot/dts/bcm47081.dtsi| 4 
>  arch/arm/boot/dts/bcm4709-netgear-r7000.dts| 4 
>  arch/arm/boot/dts/bcm4709-netgear-r8000.dts| 4 
>  arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts  | 4 
>  arch/arm/boot/dts/bcm4709.dtsi | 1 +
>  arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts  | 4 
>  arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts  | 4 
>  arch/arm/boot/dts/bcm47094-netgear-r8500.dts   | 4 
>  arch/arm/boot/dts/bcm47094.dtsi| 1 +
>  arch/arm/boot/dts/bcm94708.dts | 4 
>  arch/arm/boot/dts/bcm94709.dts | 4 
>  arch/arm/boot/dts/bcm953012er.dts  | 4 
>  arch/arm/boot/dts/bcm953012k.dts   | 1 -
>  20 files changed, 10 insertions(+), 61 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts 
> b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> index 9cb186e..d49afec0 100644
> --- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> +++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> @@ -136,10 +136,6 @@
>   };
>  };
>  
> -&uart0 {
> - status = "okay";
> -};
> -
>  &usb2 {
>   vcc-gpio = <&chipcommon 9 GPIO_ACTIVE_HIGH>;
>  };
> diff --git a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts 
> b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> index 35e6ed6..f591b0f 100644
> --- a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> +++ b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> @@ -55,10 +55,6 @@
>   };
>  };
>  
> -&uart0 {
> - status = "okay";
> -};
> -
>  &spi_nor {
>   status = "okay";
>  };
> diff --git a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts 
> b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> index 1c7e53d..50d65d8 100644
> --- a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> +++ b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> @@ -56,10 +56,6 @@
>   };
>  };
>  
> -&uart0 {
> - status = "okay";
> -};
> -
>  &spi_nor {
>   status = "okay";
>  };
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts 
> b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> index 8ce39d5..8519548 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> @@ -83,10 +83,6 @@
>   };
>  };
>  
> -&uart0 {
> - status = "okay";
> -};
> -
>  &usb3 {
>   vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
>  };
> diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts 
> b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> index 70f4bb9..74cfcd3 100644
> --- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> +++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> @@ -119,10 +119,6 @@
>   };
>  };
>  
> -&uart0 {
> - status = "okay";
> -};
> -
>  &spi_nor {
>   status = "okay";
>  };
> diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
> index eed4dd1..d0eec09 100644
> --- a/arch/arm/boot/dts/bcm4708.dtsi
> +++ b/arch/arm/boot/dts/bcm4708.dtsi
> @@ -34,3 +34,7 @@
>   };
>  
>  };
> +
> +&uart0 {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts 
> b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> index a9c8def..2922536 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> @@ -122,7 +122,3 @@
&

Re: [PATCH v3 0/4] MIPS: Remote processor driver

[Hauke Mehrtens]

On 10/11/2016 03:42 PM, Matt Redfearn wrote:
> 
> The MIPS remote processor driver allows non-Linux firmware to take
> control of and execute on one of the systems VPEs. The CPU must be
> offlined from Linux first. A sysfs interface is created which allows
> firmware to be loaded and changed at runtime. A full description is
> available at [1]. An example firmware that can be used with this driver
> is available at [2].
> 
> This is useful to allow running bare metal code, or an RTOS, on one or
> more CPUs while allowing Linux to continue running on those remaining.
> 
> The remote processor framework allows for firmwares to provide any
> virtio device for communication between the firmware running on the
> remote VP and Linux. For example [1] demonstrates a simple firmware
> which provides a virtual serial port. Any string sent to the port is
> case inverted and returned.
> 
> This is conceptually similar to the VPE loader functionality, but is
> more standard as it fits into the remoteproc subsystem.
> 
> The first patches in this series lay the groundwork for the driver
> before it is added. The last series deprecates the VPE loader.
> 
> This functionality is supported on:
> - MIPS32r2 devices implementing the MIPS MT ASE for multithreading, such
>   as interAptiv.
> - MIPS32r6 devices implementing VPs, such as I6400.
> 
> Limitations:
> - The remoteproc core supports only 32bit ELFs. Therefore it is only
>   possible to run 32bit firmware on the remote processor. Also, for
>   virtio communication, pointers are passed from the kernel to firmware.
>   There can be no mismatch in pointer sizes between the kernel and
>   firmware, so this limits the host kernel to 32bit as well.
> 
> The functionality has been tested on the Ci40 board which has a 2 core 2
> thread interAptiv.
> 

Does this also work with big firmware binaries, like 2 MB firmware size?
It looks like dma_alloc_coherent() is used in rproc_handle_carveout() to
allocate the memory which will probably not work after full boot.

Is it possible to configure the cache line in a way that it will not be
removed from the cache to avoid high latency loads from main memory?
This is only needed for small firmware binaries, but allows even shorter
reaction times and better real time behavior.

In general I am in favor of having this as a standard Linux interface.

Hauke

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

[Hauke Mehrtens]

On 10/17/2016 10:30 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Broadcom's Northstar XHCI controllers seem to need a special start
> procedure to work correctly. There isn't any official documentation of
> this, the problem is that controller doesn't detect any connected
> devices with default setup. Moreover connecting USB device to controller
> that doesn't run properly can cause SoC's watchdog issues.
> 
> A workaround that was successfully tested on multiple devices is to
> perform a fake doorbell. This patch adds code for doing this and enables
> it on BCM4708 family.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Enable quirk for brcm,bcm4708 machines instead of adding separated binding
> for it. Thanks Rob for your comment on this.
> ---
>  drivers/usb/host/xhci-plat.c |  6 +
>  drivers/usb/host/xhci.c  | 63 
> +---
>  drivers/usb/host/xhci.h  |  1 +
>  3 files changed, 67 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index ed56bf9..b01a3be 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -56,12 +56,18 @@ static int xhci_priv_init_quirk(struct usb_hcd *hcd)
>  
>  static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
>  {
> + struct platform_device  *pdev = to_platform_device(dev);
> + struct device_node  *node = pdev->dev.of_node;
> +
>   /*
>* As of now platform drivers don't provide MSI support so we ensure
>* here that the generic code does not try to make a pci_dev from our
>* dev struct in order to setup MSI
>*/
>   xhci->quirks |= XHCI_PLAT;
> +
> + if (node && of_machine_is_compatible("brcm,bcm4708"))
> + xhci->quirks |= XHCI_FAKE_DOORBELL;

Are you sure only the bcm4708 and similar SoCs are affected? Having here
a list with 3 or more checks would looks strange. I prefer your first patch.

@Florian do you know if other Broadcom SoC are affected by this problem
or are only Northstar SoCs affected?

Hauke

Re: [PATCH v3 4/4] MIPS: Deprecate VPE Loader

[Hauke Mehrtens]

This interface is currently used by the Intel / Lantiq voice Firmware.
This firmware is used by all Intel / Lantiq MIPS SoCs when they should
support analog voice.

What is the proposed timeline for the removal of this interface?

Hauke

On 10/11/2016 03:42 PM, Matt Redfearn wrote:
> The MIPS remote processor driver (CONFIG_MIPS_RPROC) provides a more
> standard mechanism for using one or more VPs as coprocessors running
> separate firmware.
> 
> Here we deprecate this mechanism before it is removed.
> 
> Signed-off-by: Matt Redfearn 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/mips/Kconfig | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index fd2468e71e63..3e767c373c7b 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -2264,7 +2264,7 @@ comment "MIPS R2-to-R6 emulator is only available for 
> UP kernels"
>   depends on SMP && CPU_MIPSR6
>  
>  config MIPS_VPE_LOADER
> - bool "VPE loader support."
> + bool "VPE loader support (DEPRECATED)"
>   depends on SYS_SUPPORTS_MULTITHREADING && MODULES
>   select CPU_MIPSR2_IRQ_VI
>   select CPU_MIPSR2_IRQ_EI
> @@ -2273,6 +2273,9 @@ config MIPS_VPE_LOADER
> Includes a loader for loading an elf relocatable object
> onto another VPE and running it.
>  
> +   Unless you have a specific need, you should use CONFIG_MIPS_RPROC
> +  instead of this.
> +
>  config MIPS_VPE_LOADER_CMP
>   bool
>   default "y"
> 

ubifs: regression: unable to mount ubifs

[Hauke Mehrtens]

The commit 322ea0bb "mtd: switch ubi_open_volume_path() to vfs_stat()"
breaks mounting ubifs volumes for me.

On kernel 4.7-rc3 I am getting the following error when trying to mount
an ubifs volume. This volume in on a ubi file system which exports it as
a mtd partition.

root@lede:/# mkdir /tmp/test
root@lede:/# mount -t ubifs /dev/ubi0_10 /tmp/test/
[  178.782184] UBIFS error (pid: 955): cannot open "/dev/ubi0_10", error
-22mount: mounting /dev/ubi0_10 on /tmp/test/ failed: Invalid argument
root@lede:/#

In the function ubi_open_volume_path() the call to vfs_stat() returns
-EFAULT.

After I reverted commit 322ea0bb it works again.

Hauke

Re: Unclear BSD licensing (headers, MODULE_LICENSE, versions)

[Hauke Mehrtens]

On 05/15/2016 12:44 AM, Rafał Miłecki wrote:
> Hi,

..

> Another problem is text of BSD license
> 
> 1) Some BSD 2-clause licensed sources don't link to its content.
> 
> In case of GPLv2 some sources simply mention this license and refer to
> COPYING. Few examples:
> a) drivers/bcma/main.c
> "Licensed under the GNU/GPL. See COPYING for details."
> b) drivers/block/umem.c
> "This driver is released to the public under the terms of the GNU
> GENERAL PUBLIC LICENSE version 2
> c) drivers/mfd/tps6507x.c
> "For licencing details see kernel-base/COPYING"

When I talked to some lawyers they did not like it when you only
reference a file and do not explicitly specify which license you are
using. The problem is that the code could be moved to an other project
with a different COPYING file. They were fine with b) because that
explicitly says which license text you mean. When you move this to
somewhere else you can still find our which license was meant here.

> I believe the same could be done for BSD 2-clause license, however
> there is no file that can be pointed. It results in some sources
> specifying 2-clause license in a header without really providing the
> content. Example:
> arch/arm/boot/dts/lpc4350.dtsi
> 
> 2) Some BSD 3-clause or Clear BSD licensed sources don't provide needed text
> 
> Many templates of BSD 3-clause license I found contain 
> that should be replaced by a proper organization/company. That makes
> me suspect we can't have a generic text of BSD 3-clause or Clear BSD
> in any shared file like COPYING. However there are sources that
> specify one of above licenses without providing or linking its text.
> Few examples:
> arch/blackfin/mach-bf609/include/mach/anomaly.h
> drivers/block/zram/zram_drv.c

I like the text of the ISC license:
https://en.wikipedia.org/wiki/ISC_license
This license is a BSD license, but it does not have  in it
and is even shorter that the ofter BSD licenses. Qualcomm Atheros used
this license text for ath9k and some other code. The main purpose was to
make it possible to integrate this code into *BSD. You can also put such
a short license text directly into your code.

This also allowed you to use the code in proprietary operating systems
like VxWorks.

> I'm wondering how we could improve this situation. I got 2 main ideas:
> 
> 1) Extend MODULE_LICENSE
> We could add new acceptable entries specifying BSD version. We could
> try to improve checkpatch.pl to look for a full license in a header
> (it seems to be required as it has to provide ). Maybe
> we could figure out (with some lawyers?) how to treat sources using
> "Dual BSD/GPL" mentioning GPL only (without BSD) in their header.
> 
> 2) Get clear rules on how to write a header
> If you find extending MODULE_LICENSE a bad idea, maybe we can simply
> help people write proper headers. Explain the problem, provide
> examples, maybe add some check in checkpatch.pl.

I see MODULE_LICENSE more as a hint not as a legal binding thing. You
could also have a module which uses a file which is licensed under GPL
and one which is licensed under BSD license. Then the compiled module is
GPL, but parts of the cod is still BSD. I prefer to have the license
information in each source file, as a reference to a license (not some
generic file) or directly the license text.

Hauke

Re: [PATCH] ARM: BCM5301X: Add DT for Luxul XAP-1510

[Hauke Mehrtens]

On 05/05/2016 12:36 AM, Rafał Miłecki wrote:
> On 4 May 2016 at 20:53, Florian Fainelli  wrote:
>> On 03/05/16 10:28, Dan Haab wrote:
>>> Luxul XAP-1510 is an AP device based on BCM4708 SoC. It uses flash
>>> memory connected to the SPI controller.
>>
>> Looks fine, except one nit:
>>
>>> diff --git a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts 
>>> b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
>>> new file mode 100644
>>> index 000..f4460b5
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
>>> @@ -0,0 +1,67 @@
>>> +/*
>>> + * Broadcom BCM470X / BCM5301X ARM platform code.
>>> + * DTS for Luxul XAP-1510
>>> + *
>>> + * Copyright 2015 Luxul Inc.
>>> + *
>>> + * Licensed under the GNU/GPL. See COPYING for details.
>>
>> The ARM SoC maintainer have been asking to utilize a license which is
>> also BSD compatible, so something along the lines of this one:
>>
>> arch/arm/boot/dts/bcm911360k.dts
>>
>> Do you mind respining the patch to include that kind of license header?
> 
> I wasn't aware of this neither. Shall we re-license existing DTS files
> as well? I'm fine with changing them to BSD compatible.
> 
> I'm a bit confused by using BSD license only. Kernel is licensed under
> GNU GPL version 2 and if there are some BSD compatible modules, they
> use dual licensing model (BSD/GPL). Shouldn't we use BSD/GPL in DTS
> files as well then?
> 

As far as I understand the License part you can take code which is
licensed under BSD license and use it in GPL code because you can comply
with the BSD license and also handle it in a way to be GPL compliant at
the same time. You can also make a change to BSD code and license this
change under the GPL, then the complete code (the old one + your change)
is now GPL.

Are the device tree files licensed under BSD license to make it easier
to integrate them into a proprietary boot loader or what is the purpose?

Hauke

Re: [PATCH] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar

[Hauke Mehrtens]

On 04/05/2016 09:34 PM, Jon Mason wrote:
> 
> 
> On Wed, Mar 30, 2016 at 5:32 PM, Jon Mason  > wrote:
> 
> On Tue, Mar 29, 2016 at 10:01 AM, Rafał Miłecki  > wrote:
> 
> Northstar is a family of SoCs used in home routers. They have
> USB 2.0
> and 3.0 controllers with PHYs that need to be properly initialized.
> This driver provides PHY init support in a generic way and can
> be bound
> with an EHCI controller driver.
> 
> 
> Like the USB3 patch you just submitted for NS, this is a common IP
> block with NSP.  I believe with some minor changes it can support
> both.  Please allow me 1-2 days to look at these in more detail and
> see if I can get these patches working on NSP.
> 
> Thanks,
> Jon
> 
> 
> After some internal discussion, I don't think this is going to work. 
> This IP block is common for NS, NSP, and a few others.  So binding it to
> BMCA is going to prevent us from being able to use it on any other
> platforms.  However, a non-BMCA driver would still be usable by NS.  So,
> I think that is a superior solution.
> 
> We are currently in the process of getting a Phy driver out which would
> cover all the iProc SoCs.  I think it is 1-2 weeks away from being
> submitted.  So, I think to go forward we should use that one for NS. 
> However, that does not bridge the gap until it is accepted.
> 
> So, I think we have 2 options.
> 1.  Wait for BCM to submit the iProc phy driver
> 2.  Push this now, and remove it after the iProc phy driver is accepted.
> 
> Thoughts?
> 
> Thanks,
> Jon
> 
Hi Jon,

As far as I see this does not have any build time dependency to bcma, it
only uses some header from bcma. Does this not build and run on your
devices without bcma?

Hauke

Re: [PATCH v2] drivers/firmware/broadcom/bcm47xx_nvram.c: fix incorrect __ioread32_copy

[Hauke Mehrtens]

On 03/16/2016 12:06 AM, Aaro Koskinen wrote:
> Commit 1f330c327900 ("drivers/firmware/broadcom/bcm47xx_nvram.c: use
> __ioread32_copy() instead of open-coding") switched to use a generic copy
> function, but failed to notice that the header pointer is updated between
> the two copies, resulting in bogus data being copied in the latter one.
> Fix by keeping the old header pointer.
> 
> The patch fixes totally broken networking on WRT54GL router (both LAN
> and WLAN interfaces fail to probe).
> 
> Fixes: 1f330c327900 ("drivers/firmware/broadcom/bcm47xx_nvram.c: use 
> __ioread32_copy() instead of open-coding")
> Signed-off-by: Aaro Koskinen 
> ---
> 
>   v2: Avoid using the device memory after the first copy when
>   checking the nvram length, suggested by Stephen Boyd.
> 
>   v1: http://marc.info/?t=14580785083&r=1&w=2
> 
>  drivers/firmware/broadcom/bcm47xx_nvram.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c 
> b/drivers/firmware/broadcom/bcm47xx_nvram.c
> index 0c2f0a6..0b631e5 100644
> --- a/drivers/firmware/broadcom/bcm47xx_nvram.c
> +++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
> @@ -94,15 +94,14 @@ static int nvram_find_and_copy(void __iomem *iobase, u32 
> lim)
>  
>  found:
>   __ioread32_copy(nvram_buf, header, sizeof(*header) / 4);
> - header = (struct nvram_header *)nvram_buf;
> - nvram_len = header->len;
> + nvram_len = ((struct nvram_header *)(nvram_buf))->len;

I do not understand why this change is needed? Doesn't the old code do
exactly the same as the new one?

The old code updated the header pointer and then accesses a member, the
new one directly accesses this member without updating this pointer.

I assume, I am missing something. ;-)

>   if (nvram_len > size) {
>   pr_err("The nvram size according to the header seems to be 
> bigger than the partition on flash\n");
>   nvram_len = size;
>   }
>   if (nvram_len >= NVRAM_SPACE) {
>   pr_err("nvram on flash (%i bytes) is bigger than the reserved 
> space in memory, will just copy the first %i bytes\n",
> -header->len, NVRAM_SPACE - 1);
> +nvram_len, NVRAM_SPACE - 1);
>   nvram_len = NVRAM_SPACE - 1;
>   }
>   /* proceed reading data after header */
> 

Re: vdso clock_gettime() sometimes broken after sleep

[Hauke Mehrtens]

On 01/29/2016 10:32 PM, Hauke Mehrtens wrote:
> When using the vdso clock_gettime() it looks like that the clock is
> sometimes not going forward when the process sleeps and the clock also
> sleeps. This problem only happens with the vdso clock and not with the
> normal syscall clock.
> 
> I wrote a small test program which calls the syscall and the vdso
> version. In the first call they are showing the same time, but after I
> sleeped for 1 second, they are off by one second. This problem occurs
> not 100% reliable but I see it pretty often. Only the CLOCK_REALTIME and
> CLOCK_MONOTONIC seam to be affected CLOCK_REALTIME_COARSE is not affected.
> 
> I am using an MIPS BE 34Kc V5.6 CPU with two VPEs, but only one is used.
> This is a Lantiq VRX200 SoC with OpenWrt Linux kernel 4.4 and musl libc.
> 
> Hauke

Hi,

Any news on this? For me this is a usespace API regression. Should I
send a patch deactivating the vdso support only for the MIPS 34Kc CPU or
for completely for mips?

Hauke


> Here are my measurements:
> 
> start test
> syscall: CLOCK_REALTIME: tv_sec: 1454098944, tv_nsec: 463189916
> vdso:CLOCK_REALTIME: tv_sec: 1454098944, tv_nsec: 463242196
> syscall: CLOCK_REALTIME_COARSE: tv_sec: 1454098944, tv_nsec: 45600
> vdso:CLOCK_REALTIME_COARSE: tv_sec: 1454098944, tv_nsec: 45600
> syscall: CLOCK_MONOTONIC: tv_sec: 107, tv_nsec: 28113172
> vdso:CLOCK_MONOTONIC: tv_sec: 107, tv_nsec: 32150208
> syscall: CLOCK_MONOTONIC_COARSE: tv_sec: 107, tv_nsec: 24678324
> vdso:CLOCK_MONOTONIC_COARSE: tv_sec: 107, tv_nsec: 24678324
> syscall: CLOCK_MONOTONIC_RAW: tv_sec: 107, tv_nsec: 28263008
> vdso:CLOCK_MONOTONIC_RAW: tv_sec: 107, tv_nsec: 28300760
> syscall: CLOCK_BOOTTIME: tv_sec: 107, tv_nsec: 28337540
> vdso:CLOCK_BOOTTIME: tv_sec: 107, tv_nsec: 28379100
> syscall: CLOCK_PROCESS_CPUTIME_ID: tv_sec: 0, tv_nsec: 328
> vdso:CLOCK_PROCESS_CPUTIME_ID: tv_sec: 0, tv_nsec: 3153120
> syscall: CLOCK_THREAD_CPUTIME_ID: tv_sec: 0, tv_nsec: 3192208
> vdso:CLOCK_THREAD_CPUTIME_ID: tv_sec: 0, tv_nsec: 3231696
> sleep(1)
> syscall: CLOCK_REALTIME: tv_sec: 1454098945, tv_nsec: 464023036
> vdso:CLOCK_REALTIME: tv_sec: 1454098946, tv_nsec: 468077456
> syscall: CLOCK_REALTIME_COARSE: tv_sec: 1454098945, tv_nsec: 46000
> vdso:CLOCK_REALTIME_COARSE: tv_sec: 1454098945, tv_nsec: 46000
> syscall: CLOCK_MONOTONIC: tv_sec: 108, tv_nsec: 28874940
> vdso:CLOCK_MONOTONIC: tv_sec: 109, tv_nsec: 32911852
> syscall: CLOCK_MONOTONIC_COARSE: tv_sec: 108, tv_nsec: 24678324
> vdso:CLOCK_MONOTONIC_COARSE: tv_sec: 108, tv_nsec: 24678324
> syscall: CLOCK_MONOTONIC_RAW: tv_sec: 108, tv_nsec: 29023384
> vdso:CLOCK_MONOTONIC_RAW: tv_sec: 108, tv_nsec: 29061372
> syscall: CLOCK_BOOTTIME: tv_sec: 108, tv_nsec: 29097912
> vdso:CLOCK_BOOTTIME: tv_sec: 108, tv_nsec: 29139864
> syscall: CLOCK_PROCESS_CPUTIME_ID: tv_sec: 0, tv_nsec: 3824540
> vdso:CLOCK_PROCESS_CPUTIME_ID: tv_sec: 0, tv_nsec: 3865708
> syscall: CLOCK_THREAD_CPUTIME_ID: tv_sec: 0, tv_nsec: 3904680
> vdso:CLOCK_THREAD_CPUTIME_ID: tv_sec: 0, tv_nsec: 3943892
> sleep(2)
> syscall: CLOCK_REALTIME: tv_sec: 1454098947, tv_nsec: 464791376
> vdso:CLOCK_REALTIME: tv_sec: 1454098950, tv_nsec: 468847600
> syscall: CLOCK_REALTIME_COARSE: tv_sec: 1454098947, tv_nsec: 46000
> vdso:CLOCK_REALTIME_COARSE: tv_sec: 1454098947, tv_nsec: 46000
> syscall: CLOCK_MONOTONIC: tv_sec: 110, tv_nsec: 29644468
> vdso:CLOCK_MONOTONIC: tv_sec: 113, tv_nsec: 33682152
> syscall: CLOCK_MONOTONIC_COARSE: tv_sec: 110, tv_nsec: 24678324
> vdso:CLOCK_MONOTONIC_COARSE: tv_sec: 110, tv_nsec: 24678324
> syscall: CLOCK_MONOTONIC_RAW: tv_sec: 110, tv_nsec: 29794136
> vdso:CLOCK_MONOTONIC_RAW: tv_sec: 110, tv_nsec: 29831728
> syscall: CLOCK_BOOTTIME: tv_sec: 110, tv_nsec: 29868576
> vdso:CLOCK_BOOTTIME: tv_sec: 110, tv_nsec: 29909920
> syscall: CLOCK_PROCESS_CPUTIME_ID: tv_sec: 0, tv_nsec: 4547416
> vdso:CLOCK_PROCESS_CPUTIME_ID: tv_sec: 0, tv_nsec: 4589684
> syscall: CLOCK_THREAD_CPUTIME_ID: tv_sec: 0, tv_nsec: 4628872
> vdso:CLOCK_THREAD_CPUTIME_ID: tv_sec: 0, tv_nsec: 4668808
> sleep(3)
> syscall: CLOCK_REALTIME: tv_sec: 1454098950, tv_nsec: 465558716
> vdso:CLOCK_REALTIME: tv_sec: 1454098956, tv_nsec: 469613960
> syscall: CLOCK_REALTIME_COARSE: tv_sec: 1454098950, tv_nsec: 46000
> vdso:CLOCK_REALTIME_COARSE: tv_sec: 1454098950, tv_nsec: 46000
> syscall: CLOCK_MONOTONIC: tv_sec: 113, tv_nsec: 30411308
> vdso:CLOCK_MONOTONIC: tv_sec: 119, tv_nsec: 34448236
> syscall: CLOCK_MONOTONIC_COARSE: tv_sec: 113, tv_nsec: 24678324
> vdso:CLOCK_MONOTONIC_COARSE: tv_sec: 113, tv_nsec: 24678324
> syscall: CLOCK_MONOTONIC_RAW: tv_sec: 113, tv_nsec: 30559184
> vdso

Re: [PATCH 15/15] Revert "of/platform: export of_default_bus_match_table"

[Hauke Mehrtens]

On 01/27/2016 05:27 AM, Kefeng Wang wrote:
> This reverts commit b80443c2211c7daaabd20fbbe9e7beb3fa3408e0.
> 
> After covering to use helper of_platform_default_populate() to populate
> the default bus, no need to export of_default_bus_match_table anymore.
> 
> Cc: Masahiro Yamada 
> Cc: Rob Herring 
> Cc: Frank Rowand  
> Cc: Grant Likely 
> Signed-off-by: Kefeng Wang 
> ---
>  drivers/of/platform.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 8d103e4..af98343 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -31,7 +31,6 @@ const struct of_device_id of_default_bus_match_table[] = {
>  #endif /* CONFIG_ARM_AMBA */
>   {} /* Empty terminated list */
>  };
> -EXPORT_SYMBOL(of_default_bus_match_table);
>  
>  static int of_dev_node_match(struct device *dev, void *data)
>  {
> 

Is of_default_bus_match_table still accessed or can it be made static
and the header file entry removed?

Thanks for cleaning up all the drivers, I just needed it for one driver.

Hauke

Re: [PATCH v3 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()

[Hauke Mehrtens]

On 10/21/2015 10:57 AM, Markos Chandras wrote:
> From: Alex Smith 
> 
> Add user-mode implementations of gettimeofday() and clock_gettime() to
> the VDSO. This is currently usable with 2 clocksources: the CP0 count
> register, which is accessible to user-mode via RDHWR on R2 and later
> cores, or the MIPS Global Interrupt Controller (GIC) timer, which
> provides a "user-mode visible" section containing a mirror of its
> counter registers. This section must be mapped into user memory, which
> is done below the VDSO data page.
> 
> When a supported clocksource is not in use, the VDSO functions will
> return -ENOSYS, which causes libc to fall back on the standard syscall
> path.
> 
> When support for neither of these clocksources is compiled into the
> kernel at all, the VDSO still provides clock_gettime(), as the coarse
> realtime/monotonic clocks can still be implemented. However,
> gettimeofday() is not provided in this case as nothing can be done
> without a suitable clocksource. This causes the symbol lookup to fail
> in libc and it will then always use the standard syscall path.
> 
> This patch includes a workaround for a bug in QEMU which results in
> RDHWR on the CP0 count register always returning a constant (incorrect)
> value. A fix for this has been submitted, and the workaround can be
> removed after the fix has been in stable releases for a reasonable
> amount of time.
> 
> A simple performance test which calls gettimeofday() 1000 times in a
> loop and calculates the average execution time gives the following
> results on a Malta + I6400 (running at 20MHz):
> 
>  - Syscall:~31000 ns
>  - VDSO (GIC): ~15000 ns
>  - VDSO (CP0): ~9500 ns
> 
> [markos.chand...@imgtec.com:
> - Minor code re-arrangements in order for mappings to be made
> in the order they appear to the process' address space.
> - Move do_{monotonic, realtime} outside of the MIPS_CLOCK_VSYSCALL ifdef
> - Use gic_get_usm_range so we can do the GIC mapping in the
> arch/mips/kernel/vdso instead of the GIC irqchip driver]
> 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Alex Smith 
> Signed-off-by: Markos Chandras 
> ---
> Changes since v2:
> - Do not export VDSO symbols if the toolchain does not have proper support
> for the VDSO.
> 
> Changes since v1:
> - Use gic_get_usm_range so we can do the GIC mapping in the
> arch/mips/kernel/vdso instead of the GIC irqchip driver
> ---
>  arch/mips/Kconfig|   5 +
>  arch/mips/include/asm/clocksource.h  |  29 +
>  arch/mips/include/asm/vdso.h |  68 +-
>  arch/mips/kernel/csrc-r4k.c  |  44 +++
>  arch/mips/kernel/vdso.c  |  71 ++-
>  arch/mips/vdso/gettimeofday.c| 232 
> +++
>  arch/mips/vdso/vdso.h|   9 ++
>  arch/mips/vdso/vdso.lds.S|   5 +
>  drivers/clocksource/mips-gic-timer.c |   7 +-
>  9 files changed, 460 insertions(+), 10 deletions(-)
>  create mode 100644 arch/mips/include/asm/clocksource.h
>  create mode 100644 arch/mips/vdso/gettimeofday.c
> 



> +
> +int __vdso_clock_gettime(clockid_t clkid, struct timespec *ts)
> +{
> + const union mips_vdso_data *data = get_vdso_data();
> + int ret;
> +
> + switch (clkid) {
> + case CLOCK_REALTIME_COARSE:
> + ret = do_realtime_coarse(ts, data);
> + break;
> + case CLOCK_MONOTONIC_COARSE:
> + ret = do_monotonic_coarse(ts, data);
> + break;
> + case CLOCK_REALTIME:
> + ret = do_realtime(ts, data);
> + break;
> + case CLOCK_MONOTONIC:
> + ret = do_monotonic(ts, data);
> + break;
> + default:
> + ret = -ENOSYS;
> + break;
> + }
> +
> + /* If we return -ENOSYS libc should fall back to a syscall. */

This comment is important.

The other architectures (checked arm64, tile, x86) are calling the
original syscall instead of returning -ENOSYS here. This will confuse
people trying to use this feature like me.

When the libc does not call the normal syscall this will cause problems.

> + return ret;
> +}

Hauke

Re: [PATCH v4 5/5] ARM: BCM: Add SMP support for Broadcom 4708

[Hauke Mehrtens]

On 12/01/2015 05:24 PM, Kapil Hali wrote:
> From: Jon Mason 
> 
> Add SMP support for Broadcom's 4708 SoCs.
> 
> Signed-off-by: Jon Mason 
> Acked-by: Hauke Mehrtens 
> Tested-by: Hauke Mehrtens 
> Signed-off-by: Kapil Hali 
> ---
>  arch/arm/boot/dts/bcm4708.dtsi | 2 ++
>  arch/arm/mach-bcm/Kconfig  | 1 +
>  arch/arm/mach-bcm/Makefile | 3 +++
>  3 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
> index 31141e8..eed4dd1 100644
> --- a/arch/arm/boot/dts/bcm4708.dtsi
> +++ b/arch/arm/boot/dts/bcm4708.dtsi
> @@ -15,6 +15,7 @@
>   cpus {
>   #address-cells = <1>;
>   #size-cells = <0>;
> + enable-method = "brcm,bcm-nsp-smp";
>  
>   cpu@0 {
>   device_type = "cpu";
> @@ -27,6 +28,7 @@
>   device_type = "cpu";
>   compatible = "arm,cortex-a9";
>   next-level-cache = <&L2>;
> + secondary-boot-reg = <0x0400>;
>   reg = <0x1>;
>   };
>   };
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index 83765a0..e85246f 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -54,6 +54,7 @@ config ARCH_BCM_NSP
>  config ARCH_BCM_5301X
>   bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
>   select ARCH_BCM_IPROC
> + select HAVE_SMP
>   help
> Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
>  

When applying this patch please make sure it is correctly applied this
patch causes some problems here:

http://www.spinics.net/lists/arm-kernel/msg462137.html

> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> index 5193a25..7d66515 100644
> --- a/arch/arm/mach-bcm/Makefile
> +++ b/arch/arm/mach-bcm/Makefile
> @@ -43,6 +43,9 @@ obj-$(CONFIG_ARCH_BCM2835)  += board_bcm2835.o
>  
>  # BCM5301X
>  obj-$(CONFIG_ARCH_BCM_5301X) += bcm_5301x.o
> +ifeq ($(CONFIG_ARCH_BCM_5301X),y)
> +obj-$(CONFIG_SMP)+= platsmp.o
> +endif
>  
>  # BCM63XXx
>  ifeq ($(CONFIG_ARCH_BCM_63XX),y)
> 

I am getting this on a Northstar 1 / BCM4708:

[ 0.137634] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[ 0.143643] Setting up static identity map for 0x82a0 - 0x82d4
[ 0.189772] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[ 0.189861] Brought up 2 CPUs
[ 0.198845] SMP: Total of 2 processors activated (3188.32 BogoMIPS).
[ 0.205446] CPU: WARNING: CPU(s) started in wrong/inconsistent modes
(primary CPU mode 0x13)
[ 0.214167] CPU: This may indicate a broken bootloader or firmware.

I assume that this is correct and the bootloader is just broken, it uses
this bootloader: "CFE for Foxconn Router version: v1.0.14", I haven't
noticed any problems, so it is ok for me.

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

Re: [PATCH v4 4/5] PCI: iproc: Add iProc PCIe MSI support

[Hauke Mehrtens]

On 11/27/2015 06:37 PM, Ray Jui wrote:
> This patch adds PCIe MSI support for both PAXB and PAXC interfaces on
> all iProc based platforms
> 
> The iProc PCIe MSI support deploys an event queue based implementation.
> Each event queue is serviced by a GIC interrupt and can support up to 64
> MSI vectors. Host memory is allocated for the event queues, and each event
> queue consists of 64 word-sized entries. MSI data is written to the
> lower 16-bit of each entry, whereas the upper 16-bit of the entry is
> reserved for the controller for internal processing
> 
> Each event queue is tracked by a head pointer and tail pointer. Head
> pointer indicates the next entry in the event queue to be processed by
> the driver and is updated by the driver after processing is done.
> The controller uses the tail pointer as the next MSI data insertion
> point. The controller ensures MSI data is flushed to host memory before
> updating the tail pointer and then triggering the interrupt
> 
> MSI IRQ affinity is supported by evenly distributing the interrupts to
> each CPU core. MSI vector is moved from one GIC interrupt to another in
> order to steer to the target CPU
> 
> Therefore, the actual number of supported MSI vectors is:
> 
> M * 64 / N
> 
> where M denotes the number of GIC interrupts (event queues), and N
> denotes the number of CPU cores
> 
> This iProc event queue based MSI support should not be used with newer
> platforms with integrated MSI support in the GIC (e.g., giv2m or
> gicv3-its)
> 
> Signed-off-by: Ray Jui 
> Reviewed-by: Anup Patel 
> Reviewed-by: Vikram Prakash 
> Reviewed-by: Scott Branden 
> ---
>  drivers/pci/host/Kconfig   |   9 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-iproc-bcma.c |   1 +
>  drivers/pci/host/pcie-iproc-msi.c  | 675 
> +
>  drivers/pci/host/pcie-iproc-platform.c |   1 +
>  drivers/pci/host/pcie-iproc.c  |  26 ++
>  drivers/pci/host/pcie-iproc.h  |  23 +-
>  7 files changed, 734 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/pci/host/pcie-iproc-msi.c
> 

.
>  
>  int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res);
>  int iproc_pcie_remove(struct iproc_pcie *pcie);
>  
> +#ifdef CONFIG_PCI_MSI
> +int iproc_msi_init(struct iproc_pcie *pcie, struct device_node *node);
> +void iproc_msi_exit(struct iproc_pcie *pcie);
> +#else
> +static inline int iproc_msi_init(struct iproc_pcie *pcie,
> +  struct device_node *node)
> +{
> + return -ENODEV;
> +}
> +static void iproc_msi_exit(struct iproc_pcie *pcie)

Please use static inline here.

> +{
> +}
> +#endif
> +
>  #endif /* _PCIE_IPROC_H */
> 

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

Re: [PATCH v3 1/3] ARM: dts: enable clock support for BCM5301X

[Hauke Mehrtens]

On 11/20/2015 04:17 PM, Jon Mason wrote:
> Replace current device tree dummy clocks with real clock support for
> Broadcom Northstar SoCs.
> 
> Signed-off-by: Jon Mason 
> ---
>  arch/arm/boot/dts/bcm5301x.dtsi | 92 
> +++--
>  1 file changed, 71 insertions(+), 21 deletions(-)
> 

Acked-by: Hauke Mehrtens 

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

Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory

[Hauke Mehrtens]

On 11/20/2015 10:53 PM, Arend van Spriel wrote:
> On 11/19/2015 08:48 AM, Kalle Valo wrote:
>> Hauke Mehrtens  writes:
>>
>>> On 11/18/2015 03:45 PM, Kalle Valo wrote:
>>>> Part of reorganising wireless drivers directory and Kconfig. Note
>>>> that I had to
>>>> edit Makefiles from subdirectories to use the new location.
>>>>
>>>> Signed-off-by: Kalle Valo 
>>>> ---
>>>
>>> I would prefer to remove the brcm80211 directory in this process and
>>> create:
>>> drivers/net/wireless/broadcom/brcmfmac
>>> drivers/net/wireless/broadcom/brcmsmac
>>> drivers/net/wireless/broadcom/brcmutil
>>> drivers/net/wireless/broadcom/include
>>>
>>> This way we have one directory less.
>>
>> I think this could be done separately. This patchset is big enough
>> already, I would not like to make it anymore complicated.
>>
>> And I actually like the brcm80211 directory, I would not mind keeping it
>> still.
> 
> I prefer to keep it as brcmsmac and brcmfmac rely on brcmutil module so
> I want to keep them together under brcm80211.
> 
> So does this patch go in before or after the patches I submitted before
> the merge window. I hope after :-p

Ok, then leave it like Kalle proposed. backports should work with both
versions.

Hauke

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

Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory

[Hauke Mehrtens]

On 11/18/2015 03:45 PM, Kalle Valo wrote:
> Part of reorganising wireless drivers directory and Kconfig. Note that I had 
> to
> edit Makefiles from subdirectories to use the new location.
> 
> Signed-off-by: Kalle Valo 
> ---

I would prefer to remove the brcm80211 directory in this process and create:
drivers/net/wireless/broadcom/brcmfmac
drivers/net/wireless/broadcom/brcmsmac
drivers/net/wireless/broadcom/brcmutil
drivers/net/wireless/broadcom/include

This way we have one directory less.

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

Re: [PATCH] PCI: iproc: hide CONFIG_PCIE_IPROC

[Hauke Mehrtens]

On 11/17/2015 05:08 PM, Arnd Bergmann wrote:
> PCIE_IPROC_BCMA does not require CONFIG_OF in Kconfig, but
> CONFIG_PCIE_IPROC does, so we can get a warning when building
> for an ARM platform without DT support:
> 
> warning: (PCIE_IPROC_PLATFORM && PCIE_IPROC_BCMA) selects PCIE_IPROC which 
> has unmet direct dependencies (PCI && OF && (ARM || ARM64))
> 
> It turns out that CONFIG_PCIE_IPROC never needs to be enabled
> by a user anyway, we can simply rely on it being selected
> implictly through either PCIE_IPROC_PLATFORM or PCIE_IPROC_BCMA.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 4785ffbdc9b5 ("PCI: iproc: Add BCMA PCIe driver")
> 

Acked-by: Hauke Mehrtens 

Thanks for spotting and fixing this.

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

Re: [PATCH v3 4/4] ARM: BCM: Add SMP support for Broadcom 4708

[Hauke Mehrtens]

On 11/07/2015 12:27 AM, Hauke Mehrtens wrote:
> On 11/06/2015 11:54 PM, Jon Mason wrote:
>> On Fri, Nov 06, 2015 at 10:42:41PM +0100, Hauke Mehrtens wrote:
>>> On 11/06/2015 10:11 PM, Kapil Hali wrote:
>>>> From: Jon Mason 
>>>>
>>>> Add SMP support for Broadcom's 4708 SoCs.
>>>>
>>>> Signed-off-by: Jon Mason 
>>>> Acked-by: Hauke Mehrtens 
>>>> Tested-by: Hauke Mehrtens 
>>>> Signed-off-by: Kapil Hali 
>>>
>>> I tested this on a Netgear R6250 V1 (BCM4708) and SMP worked.
>>>
>>>> ---
>>>>  arch/arm/boot/dts/bcm4708.dtsi | 2 ++
>>>>  arch/arm/mach-bcm/Kconfig  | 1 +
>>>>  arch/arm/mach-bcm/Makefile | 3 +++
>>>>  3 files changed, 6 insertions(+)
>>>>
>>>
>>> ...
>>>
>>>> --- a/arch/arm/mach-bcm/Kconfig
>>>> +++ b/arch/arm/mach-bcm/Kconfig
>>>> @@ -54,6 +54,7 @@ config ARCH_BCM_NSP
>>>>  config ARCH_BCM_5301X
>>>>bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
>>>>select ARCH_BCM_IPROC
>>>
>>> You activated ARM_ERRATA_764369 for NSP is this not needed for NS?
>>
>> I'm not certain the CPU version, and without that it is difficult to
>> know what errata's are present in the underlying hardware.  My guess
>> is that all present in NSP are present in NS (for UP and SMP).  This
>> would put it as:
>> select ARM_ERRATA_754322
>> select ARM_ERRATA_775420
>> select ARM_ERRATA_764369 if SMP
>>
>> Would you like me to have them added?
>>
> 
> I will send a separate patch adding all the workarounds for erratas in
> the CPU core and the cache controller.
> 
> Hauke
> 
> 
Hi,

BCM4708 uses a Cortex-A9 rev r3p0 and a L2C-310 rev r3p2. For this CPU
and cache controller the same workaround are needed as for NSP, if you
will resend this patch, please add all of them.

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

Re: [PATCH v3 4/4] ARM: BCM: Add SMP support for Broadcom 4708

[Hauke Mehrtens]

On 11/06/2015 11:54 PM, Jon Mason wrote:
> On Fri, Nov 06, 2015 at 10:42:41PM +0100, Hauke Mehrtens wrote:
>> On 11/06/2015 10:11 PM, Kapil Hali wrote:
>>> From: Jon Mason 
>>>
>>> Add SMP support for Broadcom's 4708 SoCs.
>>>
>>> Signed-off-by: Jon Mason 
>>> Acked-by: Hauke Mehrtens 
>>> Tested-by: Hauke Mehrtens 
>>> Signed-off-by: Kapil Hali 
>>
>> I tested this on a Netgear R6250 V1 (BCM4708) and SMP worked.
>>
>>> ---
>>>  arch/arm/boot/dts/bcm4708.dtsi | 2 ++
>>>  arch/arm/mach-bcm/Kconfig  | 1 +
>>>  arch/arm/mach-bcm/Makefile | 3 +++
>>>  3 files changed, 6 insertions(+)
>>>
>>
>> ...
>>
>>> --- a/arch/arm/mach-bcm/Kconfig
>>> +++ b/arch/arm/mach-bcm/Kconfig
>>> @@ -54,6 +54,7 @@ config ARCH_BCM_NSP
>>>  config ARCH_BCM_5301X
>>> bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
>>> select ARCH_BCM_IPROC
>>
>> You activated ARM_ERRATA_764369 for NSP is this not needed for NS?
> 
> I'm not certain the CPU version, and without that it is difficult to
> know what errata's are present in the underlying hardware.  My guess
> is that all present in NSP are present in NS (for UP and SMP).  This
> would put it as:
> select ARM_ERRATA_754322
> select ARM_ERRATA_775420
> select ARM_ERRATA_764369 if SMP
> 
> Would you like me to have them added?
> 

I will send a separate patch adding all the workarounds for erratas in
the CPU core and the cache controller.

Hauke


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

Re: [PATCH v3 4/4] ARM: BCM: Add SMP support for Broadcom 4708

[Hauke Mehrtens]

On 11/06/2015 10:11 PM, Kapil Hali wrote:
> From: Jon Mason 
> 
> Add SMP support for Broadcom's 4708 SoCs.
> 
> Signed-off-by: Jon Mason 
> Acked-by: Hauke Mehrtens 
> Tested-by: Hauke Mehrtens 
> Signed-off-by: Kapil Hali 

I tested this on a Netgear R6250 V1 (BCM4708) and SMP worked.

> ---
>  arch/arm/boot/dts/bcm4708.dtsi | 2 ++
>  arch/arm/mach-bcm/Kconfig  | 1 +
>  arch/arm/mach-bcm/Makefile | 3 +++
>  3 files changed, 6 insertions(+)
> 

...

> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -54,6 +54,7 @@ config ARCH_BCM_NSP
>  config ARCH_BCM_5301X
>   bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
>   select ARCH_BCM_IPROC

You activated ARM_ERRATA_764369 for NSP is this not needed for NS?


> + select HAVE_SMP
>   help
> Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
>  

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

Re: [PATCH RESEND 0/4] SMP support for Broadcom NSP

[Hauke Mehrtens]

On 11/05/2015 10:34 AM, Russell King - ARM Linux wrote:
> On Thu, Nov 05, 2015 at 12:51:17AM -0500, Kapil Hali wrote:
>> Hi,
>>
>> This series adds SMP support for Broadcom's Northstar Plus SoC.
>>
>> There are similar SMP enablement methods for many ARMv7 bsed SoCs.
>> BCM NSP SoC, has a typical such mechanism - after power-on, the
>> secondary core is held in a standby state, primary core provides a
>> startup address for the secondary core and wakes it up. Booting of
>> the secondary core is serialized using pen_release global variable.
> 
> Why do you need the pen_release stuff?  The above implies that you
> have only one secondary core, and you can control when it comes out
> of standby state.
> 
> Please, don't assume that the pen_release stuff is any kind of recommended
> or standardised system.  It isn't.  It's a hack for ARMs evaluation
> platforms.
> 

I tried to remove the pen code because I also thought/hoped that it is
useless, but the 2. CPU did not boot any more after I removed it. I do
not know the internals of SoC, but it looks like this is needed.

I described it here:
http://www.spinics.net/lists/arm-kernel/msg452178.html

I removed this comparison and the jump afterwards ("cmp r7, r0") and
the 2. CPU did not boot any more. Is this pen stuff some kind of
workaround for some bug in the silicon?

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