Re: [PATCH v2 06/10] iio: adc: at91-sama5d2_adc: add support for position and pressure channels

[Jonathan Cameron]

On Tue, 27 Mar 2018 15:32:39 +0300
Eugen Hristev  wrote:

> This implements the support for position and pressure for the included
> touchscreen support in the SAMA5D2 SOC ADC block.
> Two position channels are added and one for pressure.
> They can be read in raw format, or through a buffer.
> A normal use case is for a consumer driver to register a callback buffer
> for these channels.
> When the touchscreen channels are in the active scan mask,
> the driver will start the touchscreen sampling and push the data to the
> buffer.
> 
> Some parts of this patch are based on initial original work by
> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
> 
> Signed-off-by: Eugen Hristev 
Looks pretty good to me.  A few minor comments inline.

Jonathan

> ---
> Changes in v2:
>  - the support is now based on callback buffer.
> 
>  drivers/iio/adc/at91-sama5d2_adc.c | 452 
> -
>  1 file changed, 443 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c 
> b/drivers/iio/adc/at91-sama5d2_adc.c
> index 8729d65..29a7fb9 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -102,14 +102,26 @@
>  #define AT91_SAMA5D2_LCDR0x20
>  /* Interrupt Enable Register */
>  #define AT91_SAMA5D2_IER 0x24
> +/* Interrupt Enable Register - TS X measurement ready */
> +#define AT91_SAMA5D2_IER_XRDY   BIT(20)
> +/* Interrupt Enable Register - TS Y measurement ready */
> +#define AT91_SAMA5D2_IER_YRDY   BIT(21)
> +/* Interrupt Enable Register - TS pressure measurement ready */
> +#define AT91_SAMA5D2_IER_PRDY   BIT(22)
>  /* Interrupt Enable Register - general overrun error */
>  #define AT91_SAMA5D2_IER_GOVRE BIT(25)
> +/* Interrupt Enable Register - Pen detect */
> +#define AT91_SAMA5D2_IER_PENBIT(29)
> +/* Interrupt Enable Register - No pen detect */
> +#define AT91_SAMA5D2_IER_NOPEN  BIT(30)
>  /* Interrupt Disable Register */
>  #define AT91_SAMA5D2_IDR 0x28
>  /* Interrupt Mask Register */
>  #define AT91_SAMA5D2_IMR 0x2c
>  /* Interrupt Status Register */
>  #define AT91_SAMA5D2_ISR 0x30
> +/* Interrupt Status Register - Pen touching sense status */
> +#define AT91_SAMA5D2_ISR_PENS   BIT(31)
>  /* Last Channel Trigger Mode Register */
>  #define AT91_SAMA5D2_LCTMR   0x34
>  /* Last Channel Compare Window Register */
> @@ -131,8 +143,38 @@
>  #define AT91_SAMA5D2_CDR00x50
>  /* Analog Control Register */
>  #define AT91_SAMA5D2_ACR 0x94
> +/* Analog Control Register - Pen detect sensitivity mask */
> +#define AT91_SAMA5D2_ACR_PENDETSENS_MASKGENMASK(1, 0)
> +
>  /* Touchscreen Mode Register */
>  #define AT91_SAMA5D2_TSMR0xb0
> +/* Touchscreen Mode Register - No touch mode */
> +#define AT91_SAMA5D2_TSMR_TSMODE_NONE   0
> +/* Touchscreen Mode Register - 4 wire screen, no pressure measurement */
> +#define AT91_SAMA5D2_TSMR_TSMODE_4WIRE_NO_PRESS 1
> +/* Touchscreen Mode Register - 4 wire screen, pressure measurement */
> +#define AT91_SAMA5D2_TSMR_TSMODE_4WIRE_PRESS2
> +/* Touchscreen Mode Register - 5 wire screen */
> +#define AT91_SAMA5D2_TSMR_TSMODE_5WIRE  3
> +/* Touchscreen Mode Register - Average samples mask */
> +#define AT91_SAMA5D2_TSMR_TSAV_MASK GENMASK(5, 4)
> +/* Touchscreen Mode Register - Average samples */
> +#define AT91_SAMA5D2_TSMR_TSAV(x)   ((x) << 4)
> +/* Touchscreen Mode Register - Touch/trigger frequency ratio mask */
> +#define AT91_SAMA5D2_TSMR_TSFREQ_MASK   GENMASK(11, 8)
> +/* Touchscreen Mode Register - Touch/trigger frequency ratio */
> +#define AT91_SAMA5D2_TSMR_TSFREQ(x) ((x) << 8)
> +/* Touchscreen Mode Register - Pen Debounce Time mask */
> +#define AT91_SAMA5D2_TSMR_PENDBC_MASK   GENMASK(31, 28)
> +/* Touchscreen Mode Register - Pen Debounce Time */
> +#define AT91_SAMA5D2_TSMR_PENDBC(x)((x) << 28)
> +/* Touchscreen Mode Register - No DMA for touch measurements */
> +#define AT91_SAMA5D2_TSMR_NOTSDMA   BIT(22)
> +/* Touchscreen Mode Register - Disable pen detection */
> +#define AT91_SAMA5D2_TSMR_PENDET_DIS(0 << 24)
> +/* Touchscreen Mode Register - Enable pen detection */
> +#define AT91_SAMA5D2_TSMR_PENDET_ENABIT(24)
> +
>  /* Touchscreen X Position Register */
>  #define AT91_SAMA5D2_XPOSR   0xb4
>  /* Touchscreen Y Position Register */
> @@ -151,6 +193,12 @@
>  #define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL 2
>  /* Trigger Mode external trigger any edge */
>  #define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY 3
> +/* Trigger Mode internal periodic */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_PERIODIC 5
> +/* Trigger Mode - trigger period mask */
> +#define AT91_SAMA5D2_TRGR_TRGPER_MASK   GENMASK(31, 16)
> +/* Trigger Mode - trigger period */
> +#define AT91_SAMA5D2_TRGR_TRGPER(x) ((x) << 16)
>  
>  /* Correction Select Register */
>  #define 

Re: [PATCH v2 06/10] iio: adc: at91-sama5d2_adc: add support for position and pressure channels

[Jonathan Cameron]

On Tue, 27 Mar 2018 15:32:39 +0300
Eugen Hristev  wrote:

> This implements the support for position and pressure for the included
> touchscreen support in the SAMA5D2 SOC ADC block.
> Two position channels are added and one for pressure.
> They can be read in raw format, or through a buffer.
> A normal use case is for a consumer driver to register a callback buffer
> for these channels.
> When the touchscreen channels are in the active scan mask,
> the driver will start the touchscreen sampling and push the data to the
> buffer.
> 
> Some parts of this patch are based on initial original work by
> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
> 
> Signed-off-by: Eugen Hristev 
Looks pretty good to me.  A few minor comments inline.

Jonathan

> ---
> Changes in v2:
>  - the support is now based on callback buffer.
> 
>  drivers/iio/adc/at91-sama5d2_adc.c | 452 
> -
>  1 file changed, 443 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c 
> b/drivers/iio/adc/at91-sama5d2_adc.c
> index 8729d65..29a7fb9 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -102,14 +102,26 @@
>  #define AT91_SAMA5D2_LCDR0x20
>  /* Interrupt Enable Register */
>  #define AT91_SAMA5D2_IER 0x24
> +/* Interrupt Enable Register - TS X measurement ready */
> +#define AT91_SAMA5D2_IER_XRDY   BIT(20)
> +/* Interrupt Enable Register - TS Y measurement ready */
> +#define AT91_SAMA5D2_IER_YRDY   BIT(21)
> +/* Interrupt Enable Register - TS pressure measurement ready */
> +#define AT91_SAMA5D2_IER_PRDY   BIT(22)
>  /* Interrupt Enable Register - general overrun error */
>  #define AT91_SAMA5D2_IER_GOVRE BIT(25)
> +/* Interrupt Enable Register - Pen detect */
> +#define AT91_SAMA5D2_IER_PENBIT(29)
> +/* Interrupt Enable Register - No pen detect */
> +#define AT91_SAMA5D2_IER_NOPEN  BIT(30)
>  /* Interrupt Disable Register */
>  #define AT91_SAMA5D2_IDR 0x28
>  /* Interrupt Mask Register */
>  #define AT91_SAMA5D2_IMR 0x2c
>  /* Interrupt Status Register */
>  #define AT91_SAMA5D2_ISR 0x30
> +/* Interrupt Status Register - Pen touching sense status */
> +#define AT91_SAMA5D2_ISR_PENS   BIT(31)
>  /* Last Channel Trigger Mode Register */
>  #define AT91_SAMA5D2_LCTMR   0x34
>  /* Last Channel Compare Window Register */
> @@ -131,8 +143,38 @@
>  #define AT91_SAMA5D2_CDR00x50
>  /* Analog Control Register */
>  #define AT91_SAMA5D2_ACR 0x94
> +/* Analog Control Register - Pen detect sensitivity mask */
> +#define AT91_SAMA5D2_ACR_PENDETSENS_MASKGENMASK(1, 0)
> +
>  /* Touchscreen Mode Register */
>  #define AT91_SAMA5D2_TSMR0xb0
> +/* Touchscreen Mode Register - No touch mode */
> +#define AT91_SAMA5D2_TSMR_TSMODE_NONE   0
> +/* Touchscreen Mode Register - 4 wire screen, no pressure measurement */
> +#define AT91_SAMA5D2_TSMR_TSMODE_4WIRE_NO_PRESS 1
> +/* Touchscreen Mode Register - 4 wire screen, pressure measurement */
> +#define AT91_SAMA5D2_TSMR_TSMODE_4WIRE_PRESS2
> +/* Touchscreen Mode Register - 5 wire screen */
> +#define AT91_SAMA5D2_TSMR_TSMODE_5WIRE  3
> +/* Touchscreen Mode Register - Average samples mask */
> +#define AT91_SAMA5D2_TSMR_TSAV_MASK GENMASK(5, 4)
> +/* Touchscreen Mode Register - Average samples */
> +#define AT91_SAMA5D2_TSMR_TSAV(x)   ((x) << 4)
> +/* Touchscreen Mode Register - Touch/trigger frequency ratio mask */
> +#define AT91_SAMA5D2_TSMR_TSFREQ_MASK   GENMASK(11, 8)
> +/* Touchscreen Mode Register - Touch/trigger frequency ratio */
> +#define AT91_SAMA5D2_TSMR_TSFREQ(x) ((x) << 8)
> +/* Touchscreen Mode Register - Pen Debounce Time mask */
> +#define AT91_SAMA5D2_TSMR_PENDBC_MASK   GENMASK(31, 28)
> +/* Touchscreen Mode Register - Pen Debounce Time */
> +#define AT91_SAMA5D2_TSMR_PENDBC(x)((x) << 28)
> +/* Touchscreen Mode Register - No DMA for touch measurements */
> +#define AT91_SAMA5D2_TSMR_NOTSDMA   BIT(22)
> +/* Touchscreen Mode Register - Disable pen detection */
> +#define AT91_SAMA5D2_TSMR_PENDET_DIS(0 << 24)
> +/* Touchscreen Mode Register - Enable pen detection */
> +#define AT91_SAMA5D2_TSMR_PENDET_ENABIT(24)
> +
>  /* Touchscreen X Position Register */
>  #define AT91_SAMA5D2_XPOSR   0xb4
>  /* Touchscreen Y Position Register */
> @@ -151,6 +193,12 @@
>  #define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL 2
>  /* Trigger Mode external trigger any edge */
>  #define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY 3
> +/* Trigger Mode internal periodic */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_PERIODIC 5
> +/* Trigger Mode - trigger period mask */
> +#define AT91_SAMA5D2_TRGR_TRGPER_MASK   GENMASK(31, 16)
> +/* Trigger Mode - trigger period */
> +#define AT91_SAMA5D2_TRGR_TRGPER(x) ((x) << 16)
>  
>  /* Correction Select Register */
>  #define AT91_SAMA5D2_COSR0xd0
> @@ -169,6 +217,22 @@
>  #define 

[PATCH v2 5/6] spi: sun6i: introduce register set/unset helpers

[Sergey Suloev]

Two helper functions were added in order to update registers
easily.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 39 +--
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 210cef9..18f9344 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -115,29 +115,29 @@ static inline void sun6i_spi_write(struct sun6i_spi 
*sspi, u32 reg, u32 value)
writel(value, sspi->base_addr + reg);
 }
 
-static inline u32 sun6i_spi_get_tx_fifo_count(struct sun6i_spi *sspi)
+static inline void sun6i_spi_set(struct sun6i_spi *sspi, u32 addr, u32 val)
 {
-   u32 reg = sun6i_spi_read(sspi, SUN6I_FIFO_STA_REG);
-
-   reg >>= SUN6I_FIFO_STA_TF_CNT_BITS;
+   u32 reg = sun6i_spi_read(sspi, addr);
 
-   return reg & SUN6I_FIFO_STA_TF_CNT_MASK;
+   reg |= val;
+   sun6i_spi_write(sspi, addr, reg);
 }
 
-static inline void sun6i_spi_enable_interrupt(struct sun6i_spi *sspi, u32 mask)
+static inline void sun6i_spi_unset(struct sun6i_spi *sspi, u32 addr, u32 val)
 {
-   u32 reg = sun6i_spi_read(sspi, SUN6I_INT_CTL_REG);
+   u32 reg = sun6i_spi_read(sspi, addr);
 
-   reg |= mask;
-   sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, reg);
+   reg &= ~val;
+   sun6i_spi_write(sspi, addr, reg);
 }
 
-static inline void sun6i_spi_disable_interrupt(struct sun6i_spi *sspi, u32 
mask)
+static inline u32 sun6i_spi_get_tx_fifo_count(struct sun6i_spi *sspi)
 {
-   u32 reg = sun6i_spi_read(sspi, SUN6I_INT_CTL_REG);
+   u32 reg = sun6i_spi_read(sspi, SUN6I_FIFO_STA_REG);
 
-   reg &= ~mask;
-   sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, reg);
+   reg >>= SUN6I_FIFO_STA_TF_CNT_BITS;
+
+   return reg & SUN6I_FIFO_STA_TF_CNT_MASK;
 }
 
 static inline void sun6i_spi_drain_fifo(struct sun6i_spi *sspi, int len)
@@ -299,18 +299,14 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG,
SUN6I_FIFO_CTL_RF_RST | SUN6I_FIFO_CTL_TF_RST);
 
-
-   reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
/*
 * If it's a TX only transfer, we don't want to fill the RX
 * FIFO with bogus data
 */
if (sspi->rx_buf)
-   reg &= ~SUN6I_TFR_CTL_DHB;
+   sun6i_spi_unset(sspi, SUN6I_TFR_CTL_REG, SUN6I_TFR_CTL_DHB);
else
-   reg |= SUN6I_TFR_CTL_DHB;
-
-   sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+   sun6i_spi_set(sspi, SUN6I_TFR_CTL_REG, SUN6I_TFR_CTL_DHB);
 
 
/* Ensure that we have a parent clock fast enough */
@@ -361,11 +357,10 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
sun6i_spi_fill_fifo(sspi, sspi->fifo_depth);
 
/* Enable transfer complete interrupt */
-   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TC);
+   sun6i_spi_set(sspi, SUN6I_INT_CTL_REG, SUN6I_INT_CTL_TC);
 
/* Start the transfer */
-   reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
-   sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
+   sun6i_spi_set(sspi, SUN6I_TFR_CTL_REG, SUN6I_TFR_CTL_XCH);
 
/* Wait for completion */
ret = sun6i_spi_wait_for_transfer(spi, tfr);
-- 
2.16.2

Re: [PATCH 3/3] iio: adc: meson-axg: add saradc driver

[Jonathan Cameron]

On Fri, 30 Mar 2018 13:09:31 +0200
Martin Blumenstingl  wrote:

> On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> > From: Xingyu Chen 
> >
> > Add the SAR ADC driver for the Amlogic Meson-AXG SoC.
> >
> > Signed-off-by: Xingyu Chen   
> I suggest changing the subject of this patch to:
> iio: adc: meson-saradc: add support for Meson AXG
> 
Good point - updated.
> (because "iio: adc: meson-axg" does not point to the "meson-saradc"
> driver and no new driver is added with this patch)
> 
> with that:
> Acked-by: Martin Blumenstingl 
Thanks, acks added to all 3 patches.

Jonathan

> 
> > ---
> >  drivers/iio/adc/meson_saradc.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> > index 799ed929ab99..a5d481a2b4ef 100644
> > --- a/drivers/iio/adc/meson_saradc.c
> > +++ b/drivers/iio/adc/meson_saradc.c
> > @@ -935,6 +935,11 @@ static const struct meson_sar_adc_data 
> > meson_sar_adc_gxm_data = {
> > .name = "meson-gxm-saradc",
> >  };
> >
> > +static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
> > +   .param = _sar_adc_gxl_param,
> > +   .name = "meson-axg-saradc",
> > +};
> > +
> >  static const struct of_device_id meson_sar_adc_of_match[] = {
> > {
> > .compatible = "amlogic,meson8-saradc",
> > @@ -953,6 +958,9 @@ static const struct of_device_id 
> > meson_sar_adc_of_match[] = {
> > }, {
> > .compatible = "amlogic,meson-gxm-saradc",
> > .data = _sar_adc_gxm_data,
> > +   }, {
> > +   .compatible = "amlogic,meson-axg-saradc",
> > +   .data = _sar_adc_axg_data,
> > },
> > {},
> >  };
> > --
> > 2.15.1
> >  

[PATCH v2 5/6] spi: sun6i: introduce register set/unset helpers

[Sergey Suloev]

Two helper functions were added in order to update registers
easily.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 39 +--
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 210cef9..18f9344 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -115,29 +115,29 @@ static inline void sun6i_spi_write(struct sun6i_spi 
*sspi, u32 reg, u32 value)
writel(value, sspi->base_addr + reg);
 }
 
-static inline u32 sun6i_spi_get_tx_fifo_count(struct sun6i_spi *sspi)
+static inline void sun6i_spi_set(struct sun6i_spi *sspi, u32 addr, u32 val)
 {
-   u32 reg = sun6i_spi_read(sspi, SUN6I_FIFO_STA_REG);
-
-   reg >>= SUN6I_FIFO_STA_TF_CNT_BITS;
+   u32 reg = sun6i_spi_read(sspi, addr);
 
-   return reg & SUN6I_FIFO_STA_TF_CNT_MASK;
+   reg |= val;
+   sun6i_spi_write(sspi, addr, reg);
 }
 
-static inline void sun6i_spi_enable_interrupt(struct sun6i_spi *sspi, u32 mask)
+static inline void sun6i_spi_unset(struct sun6i_spi *sspi, u32 addr, u32 val)
 {
-   u32 reg = sun6i_spi_read(sspi, SUN6I_INT_CTL_REG);
+   u32 reg = sun6i_spi_read(sspi, addr);
 
-   reg |= mask;
-   sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, reg);
+   reg &= ~val;
+   sun6i_spi_write(sspi, addr, reg);
 }
 
-static inline void sun6i_spi_disable_interrupt(struct sun6i_spi *sspi, u32 
mask)
+static inline u32 sun6i_spi_get_tx_fifo_count(struct sun6i_spi *sspi)
 {
-   u32 reg = sun6i_spi_read(sspi, SUN6I_INT_CTL_REG);
+   u32 reg = sun6i_spi_read(sspi, SUN6I_FIFO_STA_REG);
 
-   reg &= ~mask;
-   sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, reg);
+   reg >>= SUN6I_FIFO_STA_TF_CNT_BITS;
+
+   return reg & SUN6I_FIFO_STA_TF_CNT_MASK;
 }
 
 static inline void sun6i_spi_drain_fifo(struct sun6i_spi *sspi, int len)
@@ -299,18 +299,14 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG,
SUN6I_FIFO_CTL_RF_RST | SUN6I_FIFO_CTL_TF_RST);
 
-
-   reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
/*
 * If it's a TX only transfer, we don't want to fill the RX
 * FIFO with bogus data
 */
if (sspi->rx_buf)
-   reg &= ~SUN6I_TFR_CTL_DHB;
+   sun6i_spi_unset(sspi, SUN6I_TFR_CTL_REG, SUN6I_TFR_CTL_DHB);
else
-   reg |= SUN6I_TFR_CTL_DHB;
-
-   sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+   sun6i_spi_set(sspi, SUN6I_TFR_CTL_REG, SUN6I_TFR_CTL_DHB);
 
 
/* Ensure that we have a parent clock fast enough */
@@ -361,11 +357,10 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
sun6i_spi_fill_fifo(sspi, sspi->fifo_depth);
 
/* Enable transfer complete interrupt */
-   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TC);
+   sun6i_spi_set(sspi, SUN6I_INT_CTL_REG, SUN6I_INT_CTL_TC);
 
/* Start the transfer */
-   reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
-   sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
+   sun6i_spi_set(sspi, SUN6I_TFR_CTL_REG, SUN6I_TFR_CTL_XCH);
 
/* Wait for completion */
ret = sun6i_spi_wait_for_transfer(spi, tfr);
-- 
2.16.2

Re: [PATCH 3/3] iio: adc: meson-axg: add saradc driver

[Jonathan Cameron]

On Fri, 30 Mar 2018 13:09:31 +0200
Martin Blumenstingl  wrote:

> On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> > From: Xingyu Chen 
> >
> > Add the SAR ADC driver for the Amlogic Meson-AXG SoC.
> >
> > Signed-off-by: Xingyu Chen   
> I suggest changing the subject of this patch to:
> iio: adc: meson-saradc: add support for Meson AXG
> 
Good point - updated.
> (because "iio: adc: meson-axg" does not point to the "meson-saradc"
> driver and no new driver is added with this patch)
> 
> with that:
> Acked-by: Martin Blumenstingl 
Thanks, acks added to all 3 patches.

Jonathan

> 
> > ---
> >  drivers/iio/adc/meson_saradc.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> > index 799ed929ab99..a5d481a2b4ef 100644
> > --- a/drivers/iio/adc/meson_saradc.c
> > +++ b/drivers/iio/adc/meson_saradc.c
> > @@ -935,6 +935,11 @@ static const struct meson_sar_adc_data 
> > meson_sar_adc_gxm_data = {
> > .name = "meson-gxm-saradc",
> >  };
> >
> > +static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
> > +   .param = _sar_adc_gxl_param,
> > +   .name = "meson-axg-saradc",
> > +};
> > +
> >  static const struct of_device_id meson_sar_adc_of_match[] = {
> > {
> > .compatible = "amlogic,meson8-saradc",
> > @@ -953,6 +958,9 @@ static const struct of_device_id 
> > meson_sar_adc_of_match[] = {
> > }, {
> > .compatible = "amlogic,meson-gxm-saradc",
> > .data = _sar_adc_gxm_data,
> > +   }, {
> > +   .compatible = "amlogic,meson-axg-saradc",
> > +   .data = _sar_adc_axg_data,
> > },
> > {},
> >  };
> > --
> > 2.15.1
> >  

[PATCH v2 6/6] spi: sun6i: add DMA transfers support

[Sergey Suloev]

DMA transfers are now available for sun6i and sun8i SoCs.
The DMA mode is used automatically as soon as requested
transfer length is more than FIFO length.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 296 
 1 file changed, 275 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 18f9344..5665c84 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -55,11 +57,14 @@
 
 #define SUN6I_FIFO_CTL_REG 0x18
 #define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_MASK  0xff
-#define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_BITS  0
+#define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_POS   0
+#define SUN6I_FIFO_CTL_RF_DRQ_EN   BIT(8)
 #define SUN6I_FIFO_CTL_RF_RST  BIT(15)
 #define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_MASK  0xff
-#define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_BITS  16
+#define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_POS   16
+#define SUN6I_FIFO_CTL_TF_DRQ_EN   BIT(24)
 #define SUN6I_FIFO_CTL_TF_RST  BIT(31)
+#define SUN6I_FIFO_CTL_DMA_DEDICATEBIT(9)|BIT(25)
 
 #define SUN6I_FIFO_STA_REG 0x1c
 #define SUN6I_FIFO_STA_RF_CNT_MASK 0x7f
@@ -177,6 +182,15 @@ static inline void sun6i_spi_fill_fifo(struct sun6i_spi 
*sspi, int len)
}
 }
 
+static bool sun6i_spi_can_dma(struct spi_master *master,
+ struct spi_device *spi,
+ struct spi_transfer *tfr)
+{
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+
+   return tfr->len > sspi->fifo_depth;
+}
+
 static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
 {
struct sun6i_spi *sspi = spi_master_get_devdata(spi->master);
@@ -208,6 +222,9 @@ static size_t sun6i_spi_max_transfer_size(struct spi_device 
*spi)
struct spi_master *master = spi->master;
struct sun6i_spi *sspi = spi_master_get_devdata(master);
 
+   if (master->can_dma)
+   return SUN6I_MAX_XFER_SIZE;
+
return sspi->fifo_depth;
 }
 
@@ -268,15 +285,174 @@ static int sun6i_spi_wait_for_transfer(struct spi_device 
*spi,
return 0;
 }
 
+static void sun6i_spi_dma_callback(void *param)
+{
+   struct spi_master *master = param;
+
+   dev_dbg(>dev, "DMA transfer complete\n");
+   spi_finalize_current_transfer(master);
+}
+
+static int sun6i_spi_dmap_prep_tx(struct spi_master *master,
+ struct spi_transfer *tfr,
+ dma_cookie_t *cookie)
+{
+   struct dma_async_tx_descriptor *chan_desc = NULL;
+
+   chan_desc = dmaengine_prep_slave_sg(master->dma_tx,
+   tfr->tx_sg.sgl, tfr->tx_sg.nents,
+   DMA_TO_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!chan_desc) {
+   dev_err(>dev,
+   "Couldn't prepare TX DMA slave\n");
+   return -EIO;
+   }
+
+   chan_desc->callback = sun6i_spi_dma_callback;
+   chan_desc->callback_param = master;
+
+   *cookie = dmaengine_submit(chan_desc);
+   dma_async_issue_pending(master->dma_tx);
+
+   return 0;
+}
+
+static int sun6i_spi_dmap_prep_rx(struct spi_master *master,
+ struct spi_transfer *tfr,
+ dma_cookie_t *cookie)
+{
+   struct dma_async_tx_descriptor *chan_desc = NULL;
+
+   chan_desc = dmaengine_prep_slave_sg(master->dma_rx,
+   tfr->rx_sg.sgl, tfr->rx_sg.nents,
+   DMA_FROM_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!chan_desc) {
+   dev_err(>dev,
+   "Couldn't prepare RX DMA slave\n");
+   return -EIO;
+   }
+
+   chan_desc->callback = sun6i_spi_dma_callback;
+   chan_desc->callback_param = master;
+
+   *cookie = dmaengine_submit(chan_desc);
+   dma_async_issue_pending(master->dma_rx);
+
+   return 0;
+}
+
+static int sun6i_spi_transfer_one_dma(struct spi_device *spi,
+ struct spi_transfer *tfr)
+{
+   struct spi_master *master = spi->master;
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+   dma_cookie_t tx_cookie = 0,rx_cookie = 0;
+   enum dma_status status;
+   int ret;
+   u32 reg, trig_level = 0;
+
+   dev_dbg(>dev, "Using DMA mode for transfer\n");
+
+   reg = sun6i_spi_read(sspi, SUN6I_FIFO_CTL_REG);
+
+   if (sspi->tx_buf) {
+   ret = sun6i_spi_dmap_prep_tx(master, tfr, _cookie);
+   if (ret)
+   goto out;
+
+   reg |= 

[PATCH v2 0/6] spi: Add support for DMA transfers in sun6i SPI driver

[Sergey Suloev]

The following patchset provides corrections for PIO-mode
and support for DMA transfers in sun6i SPI driver.

Changes in v2:
1) Fixed issue with misplacing a piece of code that requires access
to the transfer structure into sun6i_spi_prepare_message() function
where the transfer structure is not available.

2) Fixed issue with passing an invalid argument into devm_request_irq()
function.

Sergey Suloev (6):
  spi: sun6i: coding style/readability improvements
  spi: sun6i: handle chip select polarity flag
  spi: sun6i: restrict transfer length in PIO-mode
  spi: sun6i: use completion provided by SPI core
  spi: sun6i: introduce register set/unset helpers
  spi: sun6i: add DMA transfers support

 drivers/spi/spi-sun6i.c | 507 
 1 file changed, 381 insertions(+), 126 deletions(-)

-- 
2.16.2

[PATCH v2 6/6] spi: sun6i: add DMA transfers support

[Sergey Suloev]

DMA transfers are now available for sun6i and sun8i SoCs.
The DMA mode is used automatically as soon as requested
transfer length is more than FIFO length.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 296 
 1 file changed, 275 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 18f9344..5665c84 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -55,11 +57,14 @@
 
 #define SUN6I_FIFO_CTL_REG 0x18
 #define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_MASK  0xff
-#define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_BITS  0
+#define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_POS   0
+#define SUN6I_FIFO_CTL_RF_DRQ_EN   BIT(8)
 #define SUN6I_FIFO_CTL_RF_RST  BIT(15)
 #define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_MASK  0xff
-#define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_BITS  16
+#define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_POS   16
+#define SUN6I_FIFO_CTL_TF_DRQ_EN   BIT(24)
 #define SUN6I_FIFO_CTL_TF_RST  BIT(31)
+#define SUN6I_FIFO_CTL_DMA_DEDICATEBIT(9)|BIT(25)
 
 #define SUN6I_FIFO_STA_REG 0x1c
 #define SUN6I_FIFO_STA_RF_CNT_MASK 0x7f
@@ -177,6 +182,15 @@ static inline void sun6i_spi_fill_fifo(struct sun6i_spi 
*sspi, int len)
}
 }
 
+static bool sun6i_spi_can_dma(struct spi_master *master,
+ struct spi_device *spi,
+ struct spi_transfer *tfr)
+{
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+
+   return tfr->len > sspi->fifo_depth;
+}
+
 static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
 {
struct sun6i_spi *sspi = spi_master_get_devdata(spi->master);
@@ -208,6 +222,9 @@ static size_t sun6i_spi_max_transfer_size(struct spi_device 
*spi)
struct spi_master *master = spi->master;
struct sun6i_spi *sspi = spi_master_get_devdata(master);
 
+   if (master->can_dma)
+   return SUN6I_MAX_XFER_SIZE;
+
return sspi->fifo_depth;
 }
 
@@ -268,15 +285,174 @@ static int sun6i_spi_wait_for_transfer(struct spi_device 
*spi,
return 0;
 }
 
+static void sun6i_spi_dma_callback(void *param)
+{
+   struct spi_master *master = param;
+
+   dev_dbg(>dev, "DMA transfer complete\n");
+   spi_finalize_current_transfer(master);
+}
+
+static int sun6i_spi_dmap_prep_tx(struct spi_master *master,
+ struct spi_transfer *tfr,
+ dma_cookie_t *cookie)
+{
+   struct dma_async_tx_descriptor *chan_desc = NULL;
+
+   chan_desc = dmaengine_prep_slave_sg(master->dma_tx,
+   tfr->tx_sg.sgl, tfr->tx_sg.nents,
+   DMA_TO_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!chan_desc) {
+   dev_err(>dev,
+   "Couldn't prepare TX DMA slave\n");
+   return -EIO;
+   }
+
+   chan_desc->callback = sun6i_spi_dma_callback;
+   chan_desc->callback_param = master;
+
+   *cookie = dmaengine_submit(chan_desc);
+   dma_async_issue_pending(master->dma_tx);
+
+   return 0;
+}
+
+static int sun6i_spi_dmap_prep_rx(struct spi_master *master,
+ struct spi_transfer *tfr,
+ dma_cookie_t *cookie)
+{
+   struct dma_async_tx_descriptor *chan_desc = NULL;
+
+   chan_desc = dmaengine_prep_slave_sg(master->dma_rx,
+   tfr->rx_sg.sgl, tfr->rx_sg.nents,
+   DMA_FROM_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!chan_desc) {
+   dev_err(>dev,
+   "Couldn't prepare RX DMA slave\n");
+   return -EIO;
+   }
+
+   chan_desc->callback = sun6i_spi_dma_callback;
+   chan_desc->callback_param = master;
+
+   *cookie = dmaengine_submit(chan_desc);
+   dma_async_issue_pending(master->dma_rx);
+
+   return 0;
+}
+
+static int sun6i_spi_transfer_one_dma(struct spi_device *spi,
+ struct spi_transfer *tfr)
+{
+   struct spi_master *master = spi->master;
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+   dma_cookie_t tx_cookie = 0,rx_cookie = 0;
+   enum dma_status status;
+   int ret;
+   u32 reg, trig_level = 0;
+
+   dev_dbg(>dev, "Using DMA mode for transfer\n");
+
+   reg = sun6i_spi_read(sspi, SUN6I_FIFO_CTL_REG);
+
+   if (sspi->tx_buf) {
+   ret = sun6i_spi_dmap_prep_tx(master, tfr, _cookie);
+   if (ret)
+   goto out;
+
+   reg |= 

[PATCH v2 0/6] spi: Add support for DMA transfers in sun6i SPI driver

[Sergey Suloev]

The following patchset provides corrections for PIO-mode
and support for DMA transfers in sun6i SPI driver.

Changes in v2:
1) Fixed issue with misplacing a piece of code that requires access
to the transfer structure into sun6i_spi_prepare_message() function
where the transfer structure is not available.

2) Fixed issue with passing an invalid argument into devm_request_irq()
function.

Sergey Suloev (6):
  spi: sun6i: coding style/readability improvements
  spi: sun6i: handle chip select polarity flag
  spi: sun6i: restrict transfer length in PIO-mode
  spi: sun6i: use completion provided by SPI core
  spi: sun6i: introduce register set/unset helpers
  spi: sun6i: add DMA transfers support

 drivers/spi/spi-sun6i.c | 507 
 1 file changed, 381 insertions(+), 126 deletions(-)

-- 
2.16.2

[PATCH v2 2/6] spi: sun6i: handle chip select polarity flag

[Sergey Suloev]

The chip select polarity flag is declared as supported
but is not handled in the code.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 88ad45e..78acc1f 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -193,6 +193,12 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool 
enable)
else
reg &= ~SUN6I_TFR_CTL_CS_LEVEL;
 
+   /* Handle chip select "reverse" polarity */
+   if (spi->mode & SPI_CS_HIGH)
+   reg &= ~SUN6I_TFR_CTL_SPOL;
+   else
+   reg |= SUN6I_TFR_CTL_SPOL;
+
/* We want to control the chip select manually */
reg |= SUN6I_TFR_CTL_CS_MANUAL;
 
-- 
2.16.2

[PATCH v2 2/6] spi: sun6i: handle chip select polarity flag

[Sergey Suloev]

The chip select polarity flag is declared as supported
but is not handled in the code.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 88ad45e..78acc1f 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -193,6 +193,12 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool 
enable)
else
reg &= ~SUN6I_TFR_CTL_CS_LEVEL;
 
+   /* Handle chip select "reverse" polarity */
+   if (spi->mode & SPI_CS_HIGH)
+   reg &= ~SUN6I_TFR_CTL_SPOL;
+   else
+   reg |= SUN6I_TFR_CTL_SPOL;
+
/* We want to control the chip select manually */
reg |= SUN6I_TFR_CTL_CS_MANUAL;
 
-- 
2.16.2

[PATCH v2 3/6] spi: sun6i: restrict transfer length in PIO-mode

[Sergey Suloev]

There is no need to handle 3/4 empty/full interrupts as
the maximum supported transfer length in PIO mode is
128 bytes for sun6i- and 64 bytes for sun8i-family SoCs.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 61 ++---
 1 file changed, 17 insertions(+), 44 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 78acc1f..4db1f20 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -207,7 +207,10 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool 
enable)
 
 static size_t sun6i_spi_max_transfer_size(struct spi_device *spi)
 {
-   return SUN6I_MAX_XFER_SIZE - 1;
+   struct spi_master *master = spi->master;
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+
+   return sspi->fifo_depth;
 }
 
 static int sun6i_spi_prepare_message(struct spi_master *master,
@@ -250,13 +253,18 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
struct sun6i_spi *sspi = spi_master_get_devdata(master);
unsigned int mclk_rate, div, timeout;
unsigned int start, end, tx_time;
-   unsigned int trig_level;
unsigned int tx_len = 0;
int ret = 0;
u32 reg;
 
-   if (tfr->len > SUN6I_MAX_XFER_SIZE)
-   return -EINVAL;
+   /* A zero length transfer never finishes if programmed
+  in the hardware */
+   if (!tfr->len)
+   return 0;
+
+   /* Don't support transfer larger than the FIFO */
+   if (tfr->len > sspi->fifo_depth)
+   return -EMSGSIZE;
 
reinit_completion(>done);
sspi->tx_buf = tfr->tx_buf;
@@ -270,17 +278,6 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG,
SUN6I_FIFO_CTL_RF_RST | SUN6I_FIFO_CTL_TF_RST);
 
-   /*
-* Setup FIFO interrupt trigger level
-* Here we choose 3/4 of the full fifo depth, as it's the hardcoded
-* value used in old generation of Allwinner SPI controller.
-* (See spi-sun4i.c)
-*/
-   trig_level = sspi->fifo_depth / 4 * 3;
-   sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG,
-   (trig_level << SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_BITS) |
-   (trig_level << SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_BITS));
-
 
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
/*
@@ -342,12 +339,8 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
/* Fill the TX FIFO */
sun6i_spi_fill_fifo(sspi, sspi->fifo_depth);
 
-   /* Enable the interrupts */
-   sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, SUN6I_INT_CTL_TC);
-   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TC |
-SUN6I_INT_CTL_RF_RDY);
-   if (tx_len > sspi->fifo_depth)
-   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TF_ERQ);
+   /* Enable transfer complete interrupt */
+   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TC);
 
/* Start the transfer */
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
@@ -376,7 +369,9 @@ out:
 static irqreturn_t sun6i_spi_handler(int irq, void *dev_id)
 {
struct sun6i_spi *sspi = dev_id;
-   u32 status = sun6i_spi_read(sspi, SUN6I_INT_STA_REG);
+   u32 status;
+
+   status = sun6i_spi_read(sspi, SUN6I_INT_STA_REG);
 
/* Transfer complete */
if (status & SUN6I_INT_CTL_TC) {
@@ -386,28 +381,6 @@ static irqreturn_t sun6i_spi_handler(int irq, void *dev_id)
return IRQ_HANDLED;
}
 
-   /* Receive FIFO 3/4 full */
-   if (status & SUN6I_INT_CTL_RF_RDY) {
-   sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
-   /* Only clear the interrupt _after_ draining the FIFO */
-   sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_RF_RDY);
-   return IRQ_HANDLED;
-   }
-
-   /* Transmit FIFO 3/4 empty */
-   if (status & SUN6I_INT_CTL_TF_ERQ) {
-   sun6i_spi_fill_fifo(sspi, SUN6I_FIFO_DEPTH);
-
-   if (!sspi->len)
-   /* nothing left to transmit */
-   sun6i_spi_disable_interrupt(sspi, SUN6I_INT_CTL_TF_ERQ);
-
-   /* Only clear the interrupt _after_ re-seeding the FIFO */
-   sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_TF_ERQ);
-
-   return IRQ_HANDLED;
-   }
-
return IRQ_NONE;
 }
 
-- 
2.16.2

[PATCH v2 3/6] spi: sun6i: restrict transfer length in PIO-mode

[Sergey Suloev]

There is no need to handle 3/4 empty/full interrupts as
the maximum supported transfer length in PIO mode is
128 bytes for sun6i- and 64 bytes for sun8i-family SoCs.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 61 ++---
 1 file changed, 17 insertions(+), 44 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 78acc1f..4db1f20 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -207,7 +207,10 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool 
enable)
 
 static size_t sun6i_spi_max_transfer_size(struct spi_device *spi)
 {
-   return SUN6I_MAX_XFER_SIZE - 1;
+   struct spi_master *master = spi->master;
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+
+   return sspi->fifo_depth;
 }
 
 static int sun6i_spi_prepare_message(struct spi_master *master,
@@ -250,13 +253,18 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
struct sun6i_spi *sspi = spi_master_get_devdata(master);
unsigned int mclk_rate, div, timeout;
unsigned int start, end, tx_time;
-   unsigned int trig_level;
unsigned int tx_len = 0;
int ret = 0;
u32 reg;
 
-   if (tfr->len > SUN6I_MAX_XFER_SIZE)
-   return -EINVAL;
+   /* A zero length transfer never finishes if programmed
+  in the hardware */
+   if (!tfr->len)
+   return 0;
+
+   /* Don't support transfer larger than the FIFO */
+   if (tfr->len > sspi->fifo_depth)
+   return -EMSGSIZE;
 
reinit_completion(>done);
sspi->tx_buf = tfr->tx_buf;
@@ -270,17 +278,6 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG,
SUN6I_FIFO_CTL_RF_RST | SUN6I_FIFO_CTL_TF_RST);
 
-   /*
-* Setup FIFO interrupt trigger level
-* Here we choose 3/4 of the full fifo depth, as it's the hardcoded
-* value used in old generation of Allwinner SPI controller.
-* (See spi-sun4i.c)
-*/
-   trig_level = sspi->fifo_depth / 4 * 3;
-   sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG,
-   (trig_level << SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_BITS) |
-   (trig_level << SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_BITS));
-
 
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
/*
@@ -342,12 +339,8 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
/* Fill the TX FIFO */
sun6i_spi_fill_fifo(sspi, sspi->fifo_depth);
 
-   /* Enable the interrupts */
-   sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, SUN6I_INT_CTL_TC);
-   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TC |
-SUN6I_INT_CTL_RF_RDY);
-   if (tx_len > sspi->fifo_depth)
-   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TF_ERQ);
+   /* Enable transfer complete interrupt */
+   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TC);
 
/* Start the transfer */
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
@@ -376,7 +369,9 @@ out:
 static irqreturn_t sun6i_spi_handler(int irq, void *dev_id)
 {
struct sun6i_spi *sspi = dev_id;
-   u32 status = sun6i_spi_read(sspi, SUN6I_INT_STA_REG);
+   u32 status;
+
+   status = sun6i_spi_read(sspi, SUN6I_INT_STA_REG);
 
/* Transfer complete */
if (status & SUN6I_INT_CTL_TC) {
@@ -386,28 +381,6 @@ static irqreturn_t sun6i_spi_handler(int irq, void *dev_id)
return IRQ_HANDLED;
}
 
-   /* Receive FIFO 3/4 full */
-   if (status & SUN6I_INT_CTL_RF_RDY) {
-   sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
-   /* Only clear the interrupt _after_ draining the FIFO */
-   sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_RF_RDY);
-   return IRQ_HANDLED;
-   }
-
-   /* Transmit FIFO 3/4 empty */
-   if (status & SUN6I_INT_CTL_TF_ERQ) {
-   sun6i_spi_fill_fifo(sspi, SUN6I_FIFO_DEPTH);
-
-   if (!sspi->len)
-   /* nothing left to transmit */
-   sun6i_spi_disable_interrupt(sspi, SUN6I_INT_CTL_TF_ERQ);
-
-   /* Only clear the interrupt _after_ re-seeding the FIFO */
-   sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_TF_ERQ);
-
-   return IRQ_HANDLED;
-   }
-
return IRQ_NONE;
 }
 
-- 
2.16.2

Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support

[Alexandre Belloni]

On 23/03/2018 at 14:41:25 -0700, Florian Fainelli wrote:
> On 03/23/2018 01:11 PM, Alexandre Belloni wrote:
> > Add a driver for Microsemi Ocelot Ethernet switch support.
> > 
> > This makes two modules:
> > mscc_ocelot_common handles all the common features that doesn't depend on
> > how the switch is integrated in the SoC. Currently, it handles offloading
> > bridging to the hardware. ocelot_io.c handles register accesses. This is
> > unfortunately needed because the register layout is packed and then depends
> > on the number of ports available on the switch. The register definition
> > files are automatically generated.
> > 
> > ocelot_board handles the switch integration on the SoC and on the board.
> > 
> > Frame injection and extraction to/from the CPU port is currently done using
> > register accesses which is quite slow. DMA is possible but the port is not
> > able to absorb the whole switch bandwidth.
> > 
> > Signed-off-by: Alexandre Belloni 
> 
> Random drive by comments because this is quite a number of lines to review!
> 
> Overall, looks quite good for a first version. Out of curiosity, is
> there a particular switch test you ran this driver against? LNST?
> 

We have a really small custom test suite.

> > +   /* Add dummy CRC */
> > +   ocelot_write_rix(ocelot, 0, QS_INJ_WR, grp);
> > +   skb_tx_timestamp(skb);
> > +
> > +   dev->stats.tx_packets++;
> > +   dev->stats.tx_bytes += skb->len;
> > +   dev_kfree_skb_any(skb);
> 
> No interrupt to indicate transmit completion?
> 

No, unfortunately, the TX interrupts only indicates there is room to
start injecting frames, not that they have been transmitted.

> 
> > +static int ocelot_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
> > + struct net_device *dev, const unsigned char *addr,
> > + u16 vid, u16 flags)
> > +{
> > +   struct ocelot_port *port = netdev_priv(dev);
> > +   struct ocelot *ocelot = port->ocelot;
> > +
> > +   if (!vid) {
> > +   if (!port->vlan_aware)
> > +   /* If the bridge is not VLAN aware and no VID was
> > +* provided, set it to 1 as bridges have a default VID
> > +* of 1. Otherwise the MAC entry wouldn't match incoming
> > +* packets as the VID would differ (0 != 1).
> > +*/
> > +   vid = 1;
> > +   else
> > +   /* If the bridge is VLAN aware a VID must be provided as
> > +* otherwise the learnt entry wouldn't match any frame.
> > +*/
> > +   return -EINVAL;
> > +   }
> 
> So if we are targeting vid = 0 we end-up with vid = 1 possibly?
> 

I've removed that part that is not needed for now and will rework when
sending VLAN support.

> > +   ocelot_write_gix(ocelot, port_cfg, ANA_PORT_PORT_CFG,
> > +ocelot_port->chip_port);
> > +
> > +   /* Apply FWD mask. The loop is needed to add/remove the current port as
> > +* a source for the other ports.
> > +*/
> > +   for (port = 0; port < ocelot->num_phys_ports; port++) {
> > +   if (ocelot->bridge_fwd_mask & BIT(port)) {
> > +   unsigned long mask = ocelot->bridge_fwd_mask & 
> > ~BIT(port);
> > +
> > +   for (i = 0; i < ocelot->num_phys_ports; i++) {
> > +   unsigned long bond_mask = ocelot->lags[i];
> > +
> > +   if (!bond_mask)
> > +   continue;
> > +
> > +   if (bond_mask & BIT(port)) {
> > +   mask &= ~bond_mask;
> > +   break;
> > +   }
> > +   }
> > +
> > +   ocelot_write_rix(ocelot,
> > +BIT(ocelot->num_phys_ports) | mask,
> > +ANA_PGID_PGID, PGID_SRC + port);
> > +   } else {
> > +   /* Only the CPU port, this is compatible with link
> > +* aggregation.
> > +*/
> > +   ocelot_write_rix(ocelot,
> > +BIT(ocelot->num_phys_ports),
> > +ANA_PGID_PGID, PGID_SRC + port);
> > +   }
> 
> All of this sounds like it should be moved into the br_join/leave, this
> does not appear to be the right place to do that.
> 

No, I've triple checked because this is a comment that both Andrew and
you had. Once a port is added to the PGID MASK, it will start forwarding
frames so we really want that to happen only when the port is in
BR_STATE_FORWARDING state. Else, we may forward frames between the
addition of the port to the bridge and setting the port to the
BR_STATE_BLOCKING state.


-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support

[Alexandre Belloni]

On 23/03/2018 at 14:41:25 -0700, Florian Fainelli wrote:
> On 03/23/2018 01:11 PM, Alexandre Belloni wrote:
> > Add a driver for Microsemi Ocelot Ethernet switch support.
> > 
> > This makes two modules:
> > mscc_ocelot_common handles all the common features that doesn't depend on
> > how the switch is integrated in the SoC. Currently, it handles offloading
> > bridging to the hardware. ocelot_io.c handles register accesses. This is
> > unfortunately needed because the register layout is packed and then depends
> > on the number of ports available on the switch. The register definition
> > files are automatically generated.
> > 
> > ocelot_board handles the switch integration on the SoC and on the board.
> > 
> > Frame injection and extraction to/from the CPU port is currently done using
> > register accesses which is quite slow. DMA is possible but the port is not
> > able to absorb the whole switch bandwidth.
> > 
> > Signed-off-by: Alexandre Belloni 
> 
> Random drive by comments because this is quite a number of lines to review!
> 
> Overall, looks quite good for a first version. Out of curiosity, is
> there a particular switch test you ran this driver against? LNST?
> 

We have a really small custom test suite.

> > +   /* Add dummy CRC */
> > +   ocelot_write_rix(ocelot, 0, QS_INJ_WR, grp);
> > +   skb_tx_timestamp(skb);
> > +
> > +   dev->stats.tx_packets++;
> > +   dev->stats.tx_bytes += skb->len;
> > +   dev_kfree_skb_any(skb);
> 
> No interrupt to indicate transmit completion?
> 

No, unfortunately, the TX interrupts only indicates there is room to
start injecting frames, not that they have been transmitted.

> 
> > +static int ocelot_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
> > + struct net_device *dev, const unsigned char *addr,
> > + u16 vid, u16 flags)
> > +{
> > +   struct ocelot_port *port = netdev_priv(dev);
> > +   struct ocelot *ocelot = port->ocelot;
> > +
> > +   if (!vid) {
> > +   if (!port->vlan_aware)
> > +   /* If the bridge is not VLAN aware and no VID was
> > +* provided, set it to 1 as bridges have a default VID
> > +* of 1. Otherwise the MAC entry wouldn't match incoming
> > +* packets as the VID would differ (0 != 1).
> > +*/
> > +   vid = 1;
> > +   else
> > +   /* If the bridge is VLAN aware a VID must be provided as
> > +* otherwise the learnt entry wouldn't match any frame.
> > +*/
> > +   return -EINVAL;
> > +   }
> 
> So if we are targeting vid = 0 we end-up with vid = 1 possibly?
> 

I've removed that part that is not needed for now and will rework when
sending VLAN support.

> > +   ocelot_write_gix(ocelot, port_cfg, ANA_PORT_PORT_CFG,
> > +ocelot_port->chip_port);
> > +
> > +   /* Apply FWD mask. The loop is needed to add/remove the current port as
> > +* a source for the other ports.
> > +*/
> > +   for (port = 0; port < ocelot->num_phys_ports; port++) {
> > +   if (ocelot->bridge_fwd_mask & BIT(port)) {
> > +   unsigned long mask = ocelot->bridge_fwd_mask & 
> > ~BIT(port);
> > +
> > +   for (i = 0; i < ocelot->num_phys_ports; i++) {
> > +   unsigned long bond_mask = ocelot->lags[i];
> > +
> > +   if (!bond_mask)
> > +   continue;
> > +
> > +   if (bond_mask & BIT(port)) {
> > +   mask &= ~bond_mask;
> > +   break;
> > +   }
> > +   }
> > +
> > +   ocelot_write_rix(ocelot,
> > +BIT(ocelot->num_phys_ports) | mask,
> > +ANA_PGID_PGID, PGID_SRC + port);
> > +   } else {
> > +   /* Only the CPU port, this is compatible with link
> > +* aggregation.
> > +*/
> > +   ocelot_write_rix(ocelot,
> > +BIT(ocelot->num_phys_ports),
> > +ANA_PGID_PGID, PGID_SRC + port);
> > +   }
> 
> All of this sounds like it should be moved into the br_join/leave, this
> does not appear to be the right place to do that.
> 

No, I've triple checked because this is a comment that both Andrew and
you had. Once a port is added to the PGID MASK, it will start forwarding
frames so we really want that to happen only when the port is in
BR_STATE_FORWARDING state. Else, we may forward frames between the
addition of the port to the bridge and setting the port to the
BR_STATE_BLOCKING state.


-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [RFCv2 PATCH 0/3] Salted build ids via linker sections

[Mark Wielaard]

On Thu, 2018-03-29 at 11:01 -0700, Laura Abbott wrote:
> I'm still mostly looking for feedback whether
> this would be acceptable for merging or if we should just persue a
> --build-id-salt in binutils.

Personally I would go with this approach. It seems simple and it might
take years before a new linker option is available everywhere.

To simplify things I think you could just always add the extra vdso
.comment initialized to something like KERNELRELEASE. Which distros
seem to update anyway to include their build number, so they wouldn't
need to do anything special to "update the build salt".

Cheers,

Mark

Re: [RFCv2 PATCH 0/3] Salted build ids via linker sections

[Mark Wielaard]

On Thu, 2018-03-29 at 11:01 -0700, Laura Abbott wrote:
> I'm still mostly looking for feedback whether
> this would be acceptable for merging or if we should just persue a
> --build-id-salt in binutils.

Personally I would go with this approach. It seems simple and it might
take years before a new linker option is available everywhere.

To simplify things I think you could just always add the extra vdso
.comment initialized to something like KERNELRELEASE. Which distros
seem to update anyway to include their build number, so they wouldn't
need to do anything special to "update the build salt".

Cheers,

Mark

Re: [PATCH] sched: support dynamiQ cluster

[Vincent Guittot]

Hi Morten,

On 29 March 2018 at 14:53, Morten Rasmussen  wrote:
> On Wed, Mar 28, 2018 at 09:46:55AM +0200, Vincent Guittot wrote:
>> Arm DynamiQ system can integrate cores with different micro architecture
>> or max OPP under the same DSU so we can have cores with different compute
>> capacity at the LLC (which was not the case with legacy big/LITTLE
>> architecture). Such configuration is similar in some way to ITMT on intel
>> platform which allows some cores to be boosted to higher turbo frequency
>> than others and which uses SD_ASYM_PACKING feature to ensures that CPUs with
>> highest capacity, will always be used in priortiy in order to provide
>> maximum throughput.
>>
>> Add arch_asym_cpu_priority() for arm64 as this function is used to
>> differentiate CPUs in the scheduler. The CPU's capacity is used to order
>> CPUs in the same DSU.
>>
>> Create sched domain topolgy level for arm64 so we can set SD_ASYM_PACKING
>> at MC level.
>>
>> Some tests have been done on a hikey960 platform (quad cortex-A53,
>> quad cortex-A73). For the test purpose, the CPUs topology of the hikey960
>> has been modified so the 8 heterogeneous cores are described as being part
>> of the same cluster and sharing resources (MC level) like with a DynamiQ DSU.
>>
>> Results below show the time in seconds to run sysbench --test=cpu with an
>> increasing number of threads. The sysbench test run 32 times
>>
>>  without patch with patchdiff
>> 1 threads11.04(+/- 30%)8.86(+/- 0%)  -19%
>> 2 threads 5.59(+/- 14%)4.43(+/- 0%)  -20%
>> 3 threads 3.80(+/- 13%)2.95(+/- 0%)  -22%
>> 4 threads 3.10(+/- 12%)2.22(+/- 0%)  -28%
>> 5 threads 2.47(+/-  5%)1.95(+/- 0%)  -21%
>> 6 threads 2.09(+/-  0%)1.73(+/- 0%)  -17%
>> 7 threads 1.64(+/-  0%)1.56(+/- 0%)  - 7%
>> 8 threads 1.42(+/-  0%)1.42(+/- 0%)0%
>>
>> Results show a better and stable results across iteration with the patch
>> compared to mainline because we are always using big cores in priority 
>> whereas
>> with mainline, the scheduler randomly choose a big or a little cores when
>> there are more cores than number of threads.
>> With 1 thread, the test duration varies in the range [8.85 .. 15.86] for
>> mainline whereas it stays in the range [8.85..8.87] with the patch
>
> Using ASYM_PACKING is essentially an easier but somewhat less accurate
> way to achieve the same behaviour for big.LITTLE system as with the
> "misfit task" series that been under review here for the last couple of
> months.

I think that it's not exactly the same goal although if it's probably
close but ASYM_PACKING ensures that the maximum compute capacity is
used.

>
> As I see it, the main differences is that ASYM_PACKING attempts to pack
> all tasks regardless of task utilization on the higher capacity cpus
> whereas the "misfit task" series carefully picks cpus with tasks they
> can't handle so we don't risk migrating tasks which are perfectly

That's one main difference because misfit task will let middle range
load task on little CPUs which will not provide maximum performance.
I have put an example below

> suitable to for a little cpu to a big cpu unnecessarily. Also it is
> based directly on utilization and cpu capacity like the capacity
> awareness we already have to deal with big.LITTLE in the wake-up path.
> Furthermore, it should work for all big.LITTLE systems regardless of the
> topology, where I think ASYM_PACKING might not work well for systems
> with separate big and little sched_domains.

I haven't look in details if ASYM_PACKING can work correctly on legacy
big/little as I was mainly focus on dynamiQ config but I guess that
might also work

>
> Have to tried taking the misfit patches for a spin on your setup? I
> expect them give you the same behaviour as you report above.

So I have tried both your tests and mine on both patchset and they
provide same results which is somewhat expected as the benches are run
for several seconds.
In other to highlight the main difference between misfit task and
ASYM_PACKING, I have reused your test and reduced the number of
max-request for sysbench so that the test duration was in the range of
hundreds ms.

Hikey960 (emulate dynamiq topology)
   min avg(stdev)  max
misfit 0.0975000.114911(+- 10%)0.138500
asym   0.0925000.106072(+-  6%)0.122900

In this case, we can see that ASYM_PACKING is doing better( 8%)
because it migrates sysbench threads on big core as soon as they are
available whereas misfit task has to wait for the utilization to
increase above the 80% which takes around 70ms when starting with an
utilization that is null

Regards,
Vincent

>
> Morten

Re: [PATCH] sched: support dynamiQ cluster

[Vincent Guittot]

Hi Morten,

On 29 March 2018 at 14:53, Morten Rasmussen  wrote:
> On Wed, Mar 28, 2018 at 09:46:55AM +0200, Vincent Guittot wrote:
>> Arm DynamiQ system can integrate cores with different micro architecture
>> or max OPP under the same DSU so we can have cores with different compute
>> capacity at the LLC (which was not the case with legacy big/LITTLE
>> architecture). Such configuration is similar in some way to ITMT on intel
>> platform which allows some cores to be boosted to higher turbo frequency
>> than others and which uses SD_ASYM_PACKING feature to ensures that CPUs with
>> highest capacity, will always be used in priortiy in order to provide
>> maximum throughput.
>>
>> Add arch_asym_cpu_priority() for arm64 as this function is used to
>> differentiate CPUs in the scheduler. The CPU's capacity is used to order
>> CPUs in the same DSU.
>>
>> Create sched domain topolgy level for arm64 so we can set SD_ASYM_PACKING
>> at MC level.
>>
>> Some tests have been done on a hikey960 platform (quad cortex-A53,
>> quad cortex-A73). For the test purpose, the CPUs topology of the hikey960
>> has been modified so the 8 heterogeneous cores are described as being part
>> of the same cluster and sharing resources (MC level) like with a DynamiQ DSU.
>>
>> Results below show the time in seconds to run sysbench --test=cpu with an
>> increasing number of threads. The sysbench test run 32 times
>>
>>  without patch with patchdiff
>> 1 threads11.04(+/- 30%)8.86(+/- 0%)  -19%
>> 2 threads 5.59(+/- 14%)4.43(+/- 0%)  -20%
>> 3 threads 3.80(+/- 13%)2.95(+/- 0%)  -22%
>> 4 threads 3.10(+/- 12%)2.22(+/- 0%)  -28%
>> 5 threads 2.47(+/-  5%)1.95(+/- 0%)  -21%
>> 6 threads 2.09(+/-  0%)1.73(+/- 0%)  -17%
>> 7 threads 1.64(+/-  0%)1.56(+/- 0%)  - 7%
>> 8 threads 1.42(+/-  0%)1.42(+/- 0%)0%
>>
>> Results show a better and stable results across iteration with the patch
>> compared to mainline because we are always using big cores in priority 
>> whereas
>> with mainline, the scheduler randomly choose a big or a little cores when
>> there are more cores than number of threads.
>> With 1 thread, the test duration varies in the range [8.85 .. 15.86] for
>> mainline whereas it stays in the range [8.85..8.87] with the patch
>
> Using ASYM_PACKING is essentially an easier but somewhat less accurate
> way to achieve the same behaviour for big.LITTLE system as with the
> "misfit task" series that been under review here for the last couple of
> months.

I think that it's not exactly the same goal although if it's probably
close but ASYM_PACKING ensures that the maximum compute capacity is
used.

>
> As I see it, the main differences is that ASYM_PACKING attempts to pack
> all tasks regardless of task utilization on the higher capacity cpus
> whereas the "misfit task" series carefully picks cpus with tasks they
> can't handle so we don't risk migrating tasks which are perfectly

That's one main difference because misfit task will let middle range
load task on little CPUs which will not provide maximum performance.
I have put an example below

> suitable to for a little cpu to a big cpu unnecessarily. Also it is
> based directly on utilization and cpu capacity like the capacity
> awareness we already have to deal with big.LITTLE in the wake-up path.
> Furthermore, it should work for all big.LITTLE systems regardless of the
> topology, where I think ASYM_PACKING might not work well for systems
> with separate big and little sched_domains.

I haven't look in details if ASYM_PACKING can work correctly on legacy
big/little as I was mainly focus on dynamiQ config but I guess that
might also work

>
> Have to tried taking the misfit patches for a spin on your setup? I
> expect them give you the same behaviour as you report above.

So I have tried both your tests and mine on both patchset and they
provide same results which is somewhat expected as the benches are run
for several seconds.
In other to highlight the main difference between misfit task and
ASYM_PACKING, I have reused your test and reduced the number of
max-request for sysbench so that the test duration was in the range of
hundreds ms.

Hikey960 (emulate dynamiq topology)
   min avg(stdev)  max
misfit 0.0975000.114911(+- 10%)0.138500
asym   0.0925000.106072(+-  6%)0.122900

In this case, we can see that ASYM_PACKING is doing better( 8%)
because it migrates sysbench threads on big core as soon as they are
available whereas misfit task has to wait for the utilization to
increase above the 80% which takes around 70ms when starting with an
utilization that is null

Regards,
Vincent

>
> Morten

Re: 4.16-rc5 on Motorola Droid 4

[Sebastian Reichel]

Hi,

On Tue, Mar 27, 2018 at 11:21:56PM +0200, Pavel Machek wrote:
> Also, if you know how to get information from light sensor, that would
> be nice.

You need CONFIG_SENSORS_ISL29028. Once the driver is probed:

$ cat /sys/bus/iio/devices/iio\:device1/name
isl29030
$ cat /sys/bus/iio/devices/iio\:device1/in_illuminance_input
19

-- Sebastian


signature.asc
Description: PGP signature

Re: 4.16-rc5 on Motorola Droid 4

[Sebastian Reichel]

Hi,

On Tue, Mar 27, 2018 at 11:21:56PM +0200, Pavel Machek wrote:
> Also, if you know how to get information from light sensor, that would
> be nice.

You need CONFIG_SENSORS_ISL29028. Once the driver is probed:

$ cat /sys/bus/iio/devices/iio\:device1/name
isl29030
$ cat /sys/bus/iio/devices/iio\:device1/in_illuminance_input
19

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 00/11] Use global pages with PTI

[Ingo Molnar]

* Ingo Molnar  wrote:

> > No Global pages (baseline): 186.951 seconds time elapsed  ( +-  0.35% )
> > 28 Global pages (this set): 185.756 seconds time elapsed  ( +-  0.09% )
> >  -1.195 seconds (-0.64%)
> > 
> > Lower is better here, obviously.
> > 
> > I also re-checked everything using will-it-scale's llseek1 test[2] which
> > is basically a microbenchmark of a halfway reasonable syscall.  Higher
> > here is better.
> > 
> > No Global pages (baseline): 15783951 lseeks/sec
> > 28 Global pages (this set): 16054688 lseeks/sec
> >  +270737 lseeks/sec (+1.71%)
> > 
> > So, both the kernel compile and the microbenchmark got measurably faster.
> 
> Ok, cool, this is much better!
> 
> Mind re-sending the patch-set against latest -tip so it can be merged?
> 
> At this point !PCID Intel hardware is not a primary concern, if something bad 
> happens on them with global pages we can quirk global pages off on them in 
> some 
> way, or so.

BTW., the expectation on !PCID Intel hardware would be for global pages to help 
even more than the 0.6% and 1.7% you measured on PCID hardware: PCID already 
_reduces_ the cost of TLB flushes - so if there's not even PCID then global 
pages 
should help even more.

In theory at least. Would still be nice to measure it.

Thanks,

Ingo

Re: [PATCH 00/11] Use global pages with PTI

[Ingo Molnar]

* Ingo Molnar  wrote:

> > No Global pages (baseline): 186.951 seconds time elapsed  ( +-  0.35% )
> > 28 Global pages (this set): 185.756 seconds time elapsed  ( +-  0.09% )
> >  -1.195 seconds (-0.64%)
> > 
> > Lower is better here, obviously.
> > 
> > I also re-checked everything using will-it-scale's llseek1 test[2] which
> > is basically a microbenchmark of a halfway reasonable syscall.  Higher
> > here is better.
> > 
> > No Global pages (baseline): 15783951 lseeks/sec
> > 28 Global pages (this set): 16054688 lseeks/sec
> >  +270737 lseeks/sec (+1.71%)
> > 
> > So, both the kernel compile and the microbenchmark got measurably faster.
> 
> Ok, cool, this is much better!
> 
> Mind re-sending the patch-set against latest -tip so it can be merged?
> 
> At this point !PCID Intel hardware is not a primary concern, if something bad 
> happens on them with global pages we can quirk global pages off on them in 
> some 
> way, or so.

BTW., the expectation on !PCID Intel hardware would be for global pages to help 
even more than the 0.6% and 1.7% you measured on PCID hardware: PCID already 
_reduces_ the cost of TLB flushes - so if there's not even PCID then global 
pages 
should help even more.

In theory at least. Would still be nice to measure it.

Thanks,

Ingo

Re: [PATCH v2 05/10] iio: adc: at91-sama5d2_adc: fix channel configuration for differential channels

[Jonathan Cameron]

On Tue, 27 Mar 2018 15:32:38 +0300
Eugen Hristev  wrote:

> When iterating through the channels, the index in the array is not the
> scan index. Added an xlate function to translate to the proper index.
> This will be used also for devicetree channel xlate
> 
> Signed-off-by: Eugen Hristev 
So, this is a fix for an existing bug?

Please move this to the front of your set (to make it easier to backport).
Describe the result of the bug as well.

Fixes tag would be good.

Thanks,

Jonathan


> ---
>  drivers/iio/adc/at91-sama5d2_adc.c | 41 
> ++
>  1 file changed, 37 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c 
> b/drivers/iio/adc/at91-sama5d2_adc.c
> index 4eff835..8729d65 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -333,6 +333,27 @@ static const struct iio_chan_spec at91_adc_channels[] = {
>   + AT91_SAMA5D2_DIFF_CHAN_CNT + 1),
>  };
>  
> +static int at91_adc_chan_xlate(struct iio_dev *indio_dev, int chan)
> +{
> + int i;
> +
> + for (i = 0; i < indio_dev->num_channels; i++) {
> + if (indio_dev->channels[i].scan_index == chan)
> + return i;
> + }
> + return -EINVAL;
> +}
> +
> +static inline struct iio_chan_spec const *
> +at91_adc_chan_get(struct iio_dev *indio_dev, int chan)
> +{
> + int index = at91_adc_chan_xlate(indio_dev, chan);
> +
> + if (index < 0)
> + return NULL;
> + return indio_dev->channels + index;
> +}
> +
>  static int at91_adc_configure_trigger(struct iio_trigger *trig, bool state)
>  {
>   struct iio_dev *indio = iio_trigger_get_drvdata(trig);
> @@ -350,8 +371,10 @@ static int at91_adc_configure_trigger(struct iio_trigger 
> *trig, bool state)
>   at91_adc_writel(st, AT91_SAMA5D2_TRGR, status);
>  
>   for_each_set_bit(bit, indio->active_scan_mask, indio->num_channels) {
> - struct iio_chan_spec const *chan = indio->channels + bit;
> + struct iio_chan_spec const *chan = at91_adc_chan_get(indio, 
> bit);
>  
> + if (!chan)
> + continue;
>   if (state) {
>   at91_adc_writel(st, AT91_SAMA5D2_CHER,
>   BIT(chan->channel));
> @@ -448,7 +471,11 @@ static int at91_adc_dma_start(struct iio_dev *indio_dev)
>  
>   for_each_set_bit(bit, indio_dev->active_scan_mask,
>indio_dev->num_channels) {
> - struct iio_chan_spec const *chan = indio_dev->channels + bit;
> + struct iio_chan_spec const *chan =
> +  at91_adc_chan_get(indio_dev, bit);
> +
> + if (!chan)
> + continue;
>  
>   st->dma_st.rx_buf_sz += chan->scan_type.storagebits / 8;
>   }
> @@ -526,8 +553,11 @@ static int at91_adc_buffer_predisable(struct iio_dev 
> *indio_dev)
>*/
>   for_each_set_bit(bit, indio_dev->active_scan_mask,
>indio_dev->num_channels) {
> - struct iio_chan_spec const *chan = indio_dev->channels + bit;
> + struct iio_chan_spec const *chan =
> + at91_adc_chan_get(indio_dev, bit);
>  
> + if (!chan)
> + continue;
>   if (st->dma_st.dma_chan)
>   at91_adc_readl(st, chan->address);
>   }
> @@ -587,8 +617,11 @@ static void at91_adc_trigger_handler_nodma(struct 
> iio_dev *indio_dev,
>  
>   for_each_set_bit(bit, indio_dev->active_scan_mask,
>indio_dev->num_channels) {
> - struct iio_chan_spec const *chan = indio_dev->channels + bit;
> + struct iio_chan_spec const *chan =
> + at91_adc_chan_get(indio_dev, bit);
>  
> + if (!chan)
> + continue;
>   st->buffer[i] = at91_adc_readl(st, chan->address);
>   i++;
>   }

Re: [PATCH v2 05/10] iio: adc: at91-sama5d2_adc: fix channel configuration for differential channels

[Jonathan Cameron]

On Tue, 27 Mar 2018 15:32:38 +0300
Eugen Hristev  wrote:

> When iterating through the channels, the index in the array is not the
> scan index. Added an xlate function to translate to the proper index.
> This will be used also for devicetree channel xlate
> 
> Signed-off-by: Eugen Hristev 
So, this is a fix for an existing bug?

Please move this to the front of your set (to make it easier to backport).
Describe the result of the bug as well.

Fixes tag would be good.

Thanks,

Jonathan


> ---
>  drivers/iio/adc/at91-sama5d2_adc.c | 41 
> ++
>  1 file changed, 37 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c 
> b/drivers/iio/adc/at91-sama5d2_adc.c
> index 4eff835..8729d65 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -333,6 +333,27 @@ static const struct iio_chan_spec at91_adc_channels[] = {
>   + AT91_SAMA5D2_DIFF_CHAN_CNT + 1),
>  };
>  
> +static int at91_adc_chan_xlate(struct iio_dev *indio_dev, int chan)
> +{
> + int i;
> +
> + for (i = 0; i < indio_dev->num_channels; i++) {
> + if (indio_dev->channels[i].scan_index == chan)
> + return i;
> + }
> + return -EINVAL;
> +}
> +
> +static inline struct iio_chan_spec const *
> +at91_adc_chan_get(struct iio_dev *indio_dev, int chan)
> +{
> + int index = at91_adc_chan_xlate(indio_dev, chan);
> +
> + if (index < 0)
> + return NULL;
> + return indio_dev->channels + index;
> +}
> +
>  static int at91_adc_configure_trigger(struct iio_trigger *trig, bool state)
>  {
>   struct iio_dev *indio = iio_trigger_get_drvdata(trig);
> @@ -350,8 +371,10 @@ static int at91_adc_configure_trigger(struct iio_trigger 
> *trig, bool state)
>   at91_adc_writel(st, AT91_SAMA5D2_TRGR, status);
>  
>   for_each_set_bit(bit, indio->active_scan_mask, indio->num_channels) {
> - struct iio_chan_spec const *chan = indio->channels + bit;
> + struct iio_chan_spec const *chan = at91_adc_chan_get(indio, 
> bit);
>  
> + if (!chan)
> + continue;
>   if (state) {
>   at91_adc_writel(st, AT91_SAMA5D2_CHER,
>   BIT(chan->channel));
> @@ -448,7 +471,11 @@ static int at91_adc_dma_start(struct iio_dev *indio_dev)
>  
>   for_each_set_bit(bit, indio_dev->active_scan_mask,
>indio_dev->num_channels) {
> - struct iio_chan_spec const *chan = indio_dev->channels + bit;
> + struct iio_chan_spec const *chan =
> +  at91_adc_chan_get(indio_dev, bit);
> +
> + if (!chan)
> + continue;
>  
>   st->dma_st.rx_buf_sz += chan->scan_type.storagebits / 8;
>   }
> @@ -526,8 +553,11 @@ static int at91_adc_buffer_predisable(struct iio_dev 
> *indio_dev)
>*/
>   for_each_set_bit(bit, indio_dev->active_scan_mask,
>indio_dev->num_channels) {
> - struct iio_chan_spec const *chan = indio_dev->channels + bit;
> + struct iio_chan_spec const *chan =
> + at91_adc_chan_get(indio_dev, bit);
>  
> + if (!chan)
> + continue;
>   if (st->dma_st.dma_chan)
>   at91_adc_readl(st, chan->address);
>   }
> @@ -587,8 +617,11 @@ static void at91_adc_trigger_handler_nodma(struct 
> iio_dev *indio_dev,
>  
>   for_each_set_bit(bit, indio_dev->active_scan_mask,
>indio_dev->num_channels) {
> - struct iio_chan_spec const *chan = indio_dev->channels + bit;
> + struct iio_chan_spec const *chan =
> + at91_adc_chan_get(indio_dev, bit);
>  
> + if (!chan)
> + continue;
>   st->buffer[i] = at91_adc_readl(st, chan->address);
>   i++;
>   }

Re: [PATCH 00/11] Use global pages with PTI

[Ingo Molnar]

* Dave Hansen  wrote:

> On 03/27/2018 01:07 PM, Ingo Molnar wrote:
> > * Thomas Gleixner  wrote:
> >>> systems.  Atoms are going to be the easiest thing to get my hands on,
> >>> but I tend to shy away from them for performance work.
> >> What I have in mind is that I wonder whether the whole circus is worth it
> >> when there is no performance advantage on PCID systems.
> 
> I was waiting on trying to find a relatively recent Atom system (they
> actually come in reasonably sized servers [1]), but I'm hitting a snag
> there, so I figured I'd just share a kernel compile using Ingo's
> perf-based methodology on a Skylake desktop system with PCIDs.
>
> Here's the kernel compile:
> 
> No Global pages (baseline): 186.951 seconds time elapsed  ( +-  0.35% )
> 28 Global pages (this set): 185.756 seconds time elapsed  ( +-  0.09% )
>  -1.195 seconds (-0.64%)
> 
> Lower is better here, obviously.
> 
> I also re-checked everything using will-it-scale's llseek1 test[2] which
> is basically a microbenchmark of a halfway reasonable syscall.  Higher
> here is better.
> 
> No Global pages (baseline): 15783951 lseeks/sec
> 28 Global pages (this set): 16054688 lseeks/sec
>+270737 lseeks/sec (+1.71%)
> 
> So, both the kernel compile and the microbenchmark got measurably faster.

Ok, cool, this is much better!

Mind re-sending the patch-set against latest -tip so it can be merged?

At this point !PCID Intel hardware is not a primary concern, if something bad 
happens on them with global pages we can quirk global pages off on them in some 
way, or so.

Thanks,

Ingo

Re: [PATCH 00/11] Use global pages with PTI

[Ingo Molnar]

* Dave Hansen  wrote:

> On 03/27/2018 01:07 PM, Ingo Molnar wrote:
> > * Thomas Gleixner  wrote:
> >>> systems.  Atoms are going to be the easiest thing to get my hands on,
> >>> but I tend to shy away from them for performance work.
> >> What I have in mind is that I wonder whether the whole circus is worth it
> >> when there is no performance advantage on PCID systems.
> 
> I was waiting on trying to find a relatively recent Atom system (they
> actually come in reasonably sized servers [1]), but I'm hitting a snag
> there, so I figured I'd just share a kernel compile using Ingo's
> perf-based methodology on a Skylake desktop system with PCIDs.
>
> Here's the kernel compile:
> 
> No Global pages (baseline): 186.951 seconds time elapsed  ( +-  0.35% )
> 28 Global pages (this set): 185.756 seconds time elapsed  ( +-  0.09% )
>  -1.195 seconds (-0.64%)
> 
> Lower is better here, obviously.
> 
> I also re-checked everything using will-it-scale's llseek1 test[2] which
> is basically a microbenchmark of a halfway reasonable syscall.  Higher
> here is better.
> 
> No Global pages (baseline): 15783951 lseeks/sec
> 28 Global pages (this set): 16054688 lseeks/sec
>+270737 lseeks/sec (+1.71%)
> 
> So, both the kernel compile and the microbenchmark got measurably faster.

Ok, cool, this is much better!

Mind re-sending the patch-set against latest -tip so it can be merged?

At this point !PCID Intel hardware is not a primary concern, if something bad 
happens on them with global pages we can quirk global pages off on them in some 
way, or so.

Thanks,

Ingo

[PATCH v2 1/7] net: thunderx: move filter register related macro into proper place

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ThunderX NIC has set of registers which allows to configure
filter policy for ingress packets. There are three possible regimes
of filtering multicasts, broadcasts and unicasts: accept all, reject all
and accept filter allowed only.

Current implementation has enum with all of them and two generic macro
for enabling filtering et all (CAM_ACCEPT) and enabling/disabling
broadcast packets, which also should be corrected in order to represent
register bits properly. All these values are private for driver and
there is no need to ‘publish’ them via header file.

This commit is to move filtering register manipulation values from
header file into source with explicit assignment of exact register
values to them to be used while register configuring.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 13 +
 drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 11 ---
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 91d34ea40e2c..0dd211605eb1 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -24,6 +24,19 @@
 #define DRV_NAME   "thunder_bgx"
 #define DRV_VERSION"1.0"
 
+/* RX_DMAC_CTL configuration */
+enum MCAST_MODE {
+   MCAST_MODE_REJECT = 0x0,
+   MCAST_MODE_ACCEPT = 0x1,
+   MCAST_MODE_CAM_FILTER = 0x2,
+   RSVD = 0x3
+};
+
+#define BCAST_ACCEPT  BIT(0)
+#define CAM_ACCEPTBIT(3)
+#define MCAST_MODE_MASK   0x3
+#define BGX_MCAST_MODE(x) (x << 1)
+
 struct lmac {
struct bgx  *bgx;
int dmac;
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
index 5a7567d31138..52439da62c97 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
@@ -205,17 +205,6 @@
 #define LMAC_INTR_LINK_UP  BIT(0)
 #define LMAC_INTR_LINK_DOWNBIT(1)
 
-/*  RX_DMAC_CTL configuration*/
-enum MCAST_MODE {
-   MCAST_MODE_REJECT,
-   MCAST_MODE_ACCEPT,
-   MCAST_MODE_CAM_FILTER,
-   RSVD
-};
-
-#define BCAST_ACCEPT   1
-#define CAM_ACCEPT 1
-
 void octeon_mdiobus_force_mod_depencency(void);
 void bgx_lmac_rx_tx_enable(int node, int bgx_idx, int lmacid, bool enable);
 void bgx_add_dmac_addr(u64 dmac, int node, int bgx_idx, int lmac);
-- 
2.14.3

[PATCH v2 1/7] net: thunderx: move filter register related macro into proper place

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ThunderX NIC has set of registers which allows to configure
filter policy for ingress packets. There are three possible regimes
of filtering multicasts, broadcasts and unicasts: accept all, reject all
and accept filter allowed only.

Current implementation has enum with all of them and two generic macro
for enabling filtering et all (CAM_ACCEPT) and enabling/disabling
broadcast packets, which also should be corrected in order to represent
register bits properly. All these values are private for driver and
there is no need to ‘publish’ them via header file.

This commit is to move filtering register manipulation values from
header file into source with explicit assignment of exact register
values to them to be used while register configuring.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 13 +
 drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 11 ---
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 91d34ea40e2c..0dd211605eb1 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -24,6 +24,19 @@
 #define DRV_NAME   "thunder_bgx"
 #define DRV_VERSION"1.0"
 
+/* RX_DMAC_CTL configuration */
+enum MCAST_MODE {
+   MCAST_MODE_REJECT = 0x0,
+   MCAST_MODE_ACCEPT = 0x1,
+   MCAST_MODE_CAM_FILTER = 0x2,
+   RSVD = 0x3
+};
+
+#define BCAST_ACCEPT  BIT(0)
+#define CAM_ACCEPTBIT(3)
+#define MCAST_MODE_MASK   0x3
+#define BGX_MCAST_MODE(x) (x << 1)
+
 struct lmac {
struct bgx  *bgx;
int dmac;
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
index 5a7567d31138..52439da62c97 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
@@ -205,17 +205,6 @@
 #define LMAC_INTR_LINK_UP  BIT(0)
 #define LMAC_INTR_LINK_DOWNBIT(1)
 
-/*  RX_DMAC_CTL configuration*/
-enum MCAST_MODE {
-   MCAST_MODE_REJECT,
-   MCAST_MODE_ACCEPT,
-   MCAST_MODE_CAM_FILTER,
-   RSVD
-};
-
-#define BCAST_ACCEPT   1
-#define CAM_ACCEPT 1
-
 void octeon_mdiobus_force_mod_depencency(void);
 void bgx_lmac_rx_tx_enable(int node, int bgx_idx, int lmacid, bool enable);
 void bgx_add_dmac_addr(u64 dmac, int node, int bgx_idx, int lmac);
-- 
2.14.3

[PATCH v2 2/7] net: thunderx: add MAC address filter tracking for LMAC

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ThunderX NIC has two Ethernet Interfaces (BGX) each of them could has
up to four Logical MACs configured. Each of BGX has 32 filters to be
configured for filtering ingress packets. The number of filters available
to particular LMAC is from 8 (if we have four LMACs configured per BGX)
up to 32 (in case of only one LMAC is configured per BGX).

At the same time the NIC could present up to 128 VFs to OS as network
interfaces, each of them kernel will configure with set of MAC addresses
for filtering. So to prevent dupes in BGX filter registers from different
network interfaces it is required to cache and track all filter
configuration requests prior to applying them onto BGX filter registers.

This commit is to update LMAC structures with control fields to
allocate/releasing filters tracking list along with implementing
dmac array allocate/release per LMAC.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 44 +++
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 0dd211605eb1..de90e6aa5a4f 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -37,9 +37,18 @@ enum MCAST_MODE {
 #define MCAST_MODE_MASK   0x3
 #define BGX_MCAST_MODE(x) (x << 1)
 
+struct dmac_map {
+   u64 vf_map;
+   u64 dmac;
+};
+
 struct lmac {
struct bgx  *bgx;
-   int dmac;
+   /* actual number of DMACs configured */
+   u8  dmacs_cfg;
+   /* overal number of possible DMACs could be configured per LMAC */
+   u8  dmacs_count;
+   struct dmac_map *dmacs; /* DMAC:VFs tracking filter array */
u8  mac[ETH_ALEN];
u8  lmac_type;
u8  lane_to_sds;
@@ -236,6 +245,19 @@ void bgx_set_lmac_mac(int node, int bgx_idx, int lmacid, 
const u8 *mac)
 }
 EXPORT_SYMBOL(bgx_set_lmac_mac);
 
+static void bgx_flush_dmac_cam_filter(struct bgx *bgx, int lmacid)
+{
+   struct lmac *lmac = NULL;
+   u8  idx = 0;
+
+   lmac = >lmac[lmacid];
+   /* reset CAM filters */
+   for (idx = 0; idx < lmac->dmacs_count; idx++)
+   bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM +
+ ((lmacid * lmac->dmacs_count) + idx) *
+ sizeof(u64), 0);
+}
+
 void bgx_lmac_rx_tx_enable(int node, int bgx_idx, int lmacid, bool enable)
 {
struct bgx *bgx = get_bgx(node, bgx_idx);
@@ -481,18 +503,6 @@ u64 bgx_get_tx_stats(int node, int bgx_idx, int lmac, int 
idx)
 }
 EXPORT_SYMBOL(bgx_get_tx_stats);
 
-static void bgx_flush_dmac_addrs(struct bgx *bgx, int lmac)
-{
-   u64 offset;
-
-   while (bgx->lmac[lmac].dmac > 0) {
-   offset = ((bgx->lmac[lmac].dmac - 1) * sizeof(u64)) +
-   (lmac * MAX_DMAC_PER_LMAC * sizeof(u64));
-   bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM + offset, 0);
-   bgx->lmac[lmac].dmac--;
-   }
-}
-
 /* Configure BGX LMAC in internal loopback mode */
 void bgx_lmac_internal_loopback(int node, int bgx_idx,
int lmac_idx, bool enable)
@@ -925,6 +935,11 @@ static int bgx_lmac_enable(struct bgx *bgx, u8 lmacid)
bgx_reg_write(bgx, lmacid, BGX_SMUX_TX_MIN_PKT, 60 + 4);
}
 
+   /* actual number of filters available to exact LMAC */
+   lmac->dmacs_count = (RX_DMAC_COUNT / bgx->lmac_count);
+   lmac->dmacs = kcalloc(lmac->dmacs_count, sizeof(*lmac->dmacs),
+ GFP_KERNEL);
+
/* Enable lmac */
bgx_reg_modify(bgx, lmacid, BGX_CMRX_CFG, CMR_EN);
 
@@ -1011,7 +1026,8 @@ static void bgx_lmac_disable(struct bgx *bgx, u8 lmacid)
cfg &= ~CMR_EN;
bgx_reg_write(bgx, lmacid, BGX_CMRX_CFG, cfg);
 
-   bgx_flush_dmac_addrs(bgx, lmacid);
+   bgx_flush_dmac_cam_filter(bgx, lmacid);
+   kfree(lmac->dmacs);
 
if ((lmac->lmac_type != BGX_MODE_XFI) &&
(lmac->lmac_type != BGX_MODE_XLAUI) &&
-- 
2.14.3

[PATCH v2 2/7] net: thunderx: add MAC address filter tracking for LMAC

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ThunderX NIC has two Ethernet Interfaces (BGX) each of them could has
up to four Logical MACs configured. Each of BGX has 32 filters to be
configured for filtering ingress packets. The number of filters available
to particular LMAC is from 8 (if we have four LMACs configured per BGX)
up to 32 (in case of only one LMAC is configured per BGX).

At the same time the NIC could present up to 128 VFs to OS as network
interfaces, each of them kernel will configure with set of MAC addresses
for filtering. So to prevent dupes in BGX filter registers from different
network interfaces it is required to cache and track all filter
configuration requests prior to applying them onto BGX filter registers.

This commit is to update LMAC structures with control fields to
allocate/releasing filters tracking list along with implementing
dmac array allocate/release per LMAC.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 44 +++
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 0dd211605eb1..de90e6aa5a4f 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -37,9 +37,18 @@ enum MCAST_MODE {
 #define MCAST_MODE_MASK   0x3
 #define BGX_MCAST_MODE(x) (x << 1)
 
+struct dmac_map {
+   u64 vf_map;
+   u64 dmac;
+};
+
 struct lmac {
struct bgx  *bgx;
-   int dmac;
+   /* actual number of DMACs configured */
+   u8  dmacs_cfg;
+   /* overal number of possible DMACs could be configured per LMAC */
+   u8  dmacs_count;
+   struct dmac_map *dmacs; /* DMAC:VFs tracking filter array */
u8  mac[ETH_ALEN];
u8  lmac_type;
u8  lane_to_sds;
@@ -236,6 +245,19 @@ void bgx_set_lmac_mac(int node, int bgx_idx, int lmacid, 
const u8 *mac)
 }
 EXPORT_SYMBOL(bgx_set_lmac_mac);
 
+static void bgx_flush_dmac_cam_filter(struct bgx *bgx, int lmacid)
+{
+   struct lmac *lmac = NULL;
+   u8  idx = 0;
+
+   lmac = >lmac[lmacid];
+   /* reset CAM filters */
+   for (idx = 0; idx < lmac->dmacs_count; idx++)
+   bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM +
+ ((lmacid * lmac->dmacs_count) + idx) *
+ sizeof(u64), 0);
+}
+
 void bgx_lmac_rx_tx_enable(int node, int bgx_idx, int lmacid, bool enable)
 {
struct bgx *bgx = get_bgx(node, bgx_idx);
@@ -481,18 +503,6 @@ u64 bgx_get_tx_stats(int node, int bgx_idx, int lmac, int 
idx)
 }
 EXPORT_SYMBOL(bgx_get_tx_stats);
 
-static void bgx_flush_dmac_addrs(struct bgx *bgx, int lmac)
-{
-   u64 offset;
-
-   while (bgx->lmac[lmac].dmac > 0) {
-   offset = ((bgx->lmac[lmac].dmac - 1) * sizeof(u64)) +
-   (lmac * MAX_DMAC_PER_LMAC * sizeof(u64));
-   bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM + offset, 0);
-   bgx->lmac[lmac].dmac--;
-   }
-}
-
 /* Configure BGX LMAC in internal loopback mode */
 void bgx_lmac_internal_loopback(int node, int bgx_idx,
int lmac_idx, bool enable)
@@ -925,6 +935,11 @@ static int bgx_lmac_enable(struct bgx *bgx, u8 lmacid)
bgx_reg_write(bgx, lmacid, BGX_SMUX_TX_MIN_PKT, 60 + 4);
}
 
+   /* actual number of filters available to exact LMAC */
+   lmac->dmacs_count = (RX_DMAC_COUNT / bgx->lmac_count);
+   lmac->dmacs = kcalloc(lmac->dmacs_count, sizeof(*lmac->dmacs),
+ GFP_KERNEL);
+
/* Enable lmac */
bgx_reg_modify(bgx, lmacid, BGX_CMRX_CFG, CMR_EN);
 
@@ -1011,7 +1026,8 @@ static void bgx_lmac_disable(struct bgx *bgx, u8 lmacid)
cfg &= ~CMR_EN;
bgx_reg_write(bgx, lmacid, BGX_CMRX_CFG, cfg);
 
-   bgx_flush_dmac_addrs(bgx, lmacid);
+   bgx_flush_dmac_cam_filter(bgx, lmacid);
+   kfree(lmac->dmacs);
 
if ((lmac->lmac_type != BGX_MODE_XFI) &&
(lmac->lmac_type != BGX_MODE_XLAUI) &&
-- 
2.14.3

[PATCH v2 4/7] net: thunderx: add new messages for handle ndo_set_rx_mode callback

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The kernel calls ndo_set_rx_mode() callback supplying it will all necessary
info, such as device state flags, multicast mac addresses list and so on.
Since we have only 128 bits to communicate with PF we need to initiate
several requests to PF with small/short operation each based on input data.

So this commit implements following PF messages codes along with new
data structures for them:
NIC_MBOX_MSG_RESET_XCAST to flush all filters configured for this
  particular network interface (VF)
NIC_MBOX_MSG_ADD_MCAST   to add new MAC address to DMAC filter registers
  for this particular network interface (VF)
NIC_MBOX_MSG_SET_XCAST   to apply filtering configuration to filter control
  register

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nic.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h 
b/drivers/net/ethernet/cavium/thunder/nic.h
index 4cacce5d2b16..069289b4f968 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -403,6 +403,9 @@ struct nicvf {
 #defineNIC_MBOX_MSG_PTP_CFG0x19/* HW packet timestamp 
*/
 #defineNIC_MBOX_MSG_CFG_DONE   0xF0/* VF configuration 
done */
 #defineNIC_MBOX_MSG_SHUTDOWN   0xF1/* VF is being shutdown 
*/
+#defineNIC_MBOX_MSG_RESET_XCAST0xF2/* Reset DCAM filtering 
mode */
+#defineNIC_MBOX_MSG_ADD_MCAST  0xF3/* Add MAC to DCAM 
filters */
+#defineNIC_MBOX_MSG_SET_XCAST  0xF4/* Set MCAST/BCAST RX 
mode */
 
 struct nic_cfg_msg {
u8msg;
@@ -556,6 +559,14 @@ struct set_ptp {
bool  enable;
 };
 
+struct xcast {
+   u8msg;
+   union {
+   u8mode;
+   u64   mac;
+   } data;
+};
+
 /* 128 bit shared memory between PF and each VF */
 union nic_mbx {
struct { u8 msg; }  msg;
@@ -576,6 +587,7 @@ union nic_mbx {
struct reset_stat_cfg   reset_stat;
struct pfc  pfc;
struct set_ptp  ptp;
+   struct xcastxcast;
 };
 
 #define NIC_NODE_ID_MASK   0x03
-- 
2.14.3

[PATCH v2 4/7] net: thunderx: add new messages for handle ndo_set_rx_mode callback

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The kernel calls ndo_set_rx_mode() callback supplying it will all necessary
info, such as device state flags, multicast mac addresses list and so on.
Since we have only 128 bits to communicate with PF we need to initiate
several requests to PF with small/short operation each based on input data.

So this commit implements following PF messages codes along with new
data structures for them:
NIC_MBOX_MSG_RESET_XCAST to flush all filters configured for this
  particular network interface (VF)
NIC_MBOX_MSG_ADD_MCAST   to add new MAC address to DMAC filter registers
  for this particular network interface (VF)
NIC_MBOX_MSG_SET_XCAST   to apply filtering configuration to filter control
  register

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nic.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h 
b/drivers/net/ethernet/cavium/thunder/nic.h
index 4cacce5d2b16..069289b4f968 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -403,6 +403,9 @@ struct nicvf {
 #defineNIC_MBOX_MSG_PTP_CFG0x19/* HW packet timestamp 
*/
 #defineNIC_MBOX_MSG_CFG_DONE   0xF0/* VF configuration 
done */
 #defineNIC_MBOX_MSG_SHUTDOWN   0xF1/* VF is being shutdown 
*/
+#defineNIC_MBOX_MSG_RESET_XCAST0xF2/* Reset DCAM filtering 
mode */
+#defineNIC_MBOX_MSG_ADD_MCAST  0xF3/* Add MAC to DCAM 
filters */
+#defineNIC_MBOX_MSG_SET_XCAST  0xF4/* Set MCAST/BCAST RX 
mode */
 
 struct nic_cfg_msg {
u8msg;
@@ -556,6 +559,14 @@ struct set_ptp {
bool  enable;
 };
 
+struct xcast {
+   u8msg;
+   union {
+   u8mode;
+   u64   mac;
+   } data;
+};
+
 /* 128 bit shared memory between PF and each VF */
 union nic_mbx {
struct { u8 msg; }  msg;
@@ -576,6 +587,7 @@ union nic_mbx {
struct reset_stat_cfg   reset_stat;
struct pfc  pfc;
struct set_ptp  ptp;
+   struct xcastxcast;
 };
 
 #define NIC_NODE_ID_MASK   0x03
-- 
2.14.3

[PATCH v2 5/7] net: thunderx: add XCAST messages handlers for PF

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

This commit is to add message handling for ndo_set_rx_mode()
callback at PF side.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nic_main.c | 45 +++---
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c 
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 7ff66a8194e2..55af04fa03a7 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -21,6 +21,8 @@
 #define DRV_NAME   "nicpf"
 #define DRV_VERSION"1.0"
 
+#define NIC_VF_PER_MBX_REG  64
+
 struct hw_info {
u8  bgx_cnt;
u8  chans_per_lmac;
@@ -1072,6 +1074,40 @@ static void nic_handle_mbx_intr(struct nicpf *nic, int 
vf)
case NIC_MBOX_MSG_PTP_CFG:
nic_config_timestamp(nic, vf, );
break;
+   case NIC_MBOX_MSG_RESET_XCAST:
+   if (vf >= nic->num_vf_en) {
+   ret = -1; /* NACK */
+   break;
+   }
+   bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   bgx_reset_xcast_mode(nic->node, bgx, lmac,
+vf < NIC_VF_PER_MBX_REG ? vf :
+vf - NIC_VF_PER_MBX_REG);
+   break;
+
+   case NIC_MBOX_MSG_ADD_MCAST:
+   if (vf >= nic->num_vf_en) {
+   ret = -1; /* NACK */
+   break;
+   }
+   bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   bgx_set_dmac_cam_filter(nic->node, bgx, lmac,
+   mbx.xcast.data.mac,
+   vf < NIC_VF_PER_MBX_REG ? vf :
+   vf - NIC_VF_PER_MBX_REG);
+   break;
+
+   case NIC_MBOX_MSG_SET_XCAST:
+   if (vf >= nic->num_vf_en) {
+   ret = -1; /* NACK */
+   break;
+   }
+   bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   bgx_set_xcast_mode(nic->node, bgx, lmac, mbx.xcast.data.mode);
+   break;
default:
dev_err(>pdev->dev,
"Invalid msg from VF%d, msg 0x%x\n", vf, mbx.msg.msg);
@@ -1094,7 +1130,7 @@ static irqreturn_t nic_mbx_intr_handler(int irq, void 
*nic_irq)
struct nicpf *nic = (struct nicpf *)nic_irq;
int mbx;
u64 intr;
-   u8  vf, vf_per_mbx_reg = 64;
+   u8  vf;
 
if (irq == pci_irq_vector(nic->pdev, NIC_PF_INTR_ID_MBOX0))
mbx = 0;
@@ -1103,12 +1139,13 @@ static irqreturn_t nic_mbx_intr_handler(int irq, void 
*nic_irq)
 
intr = nic_reg_read(nic, NIC_PF_MAILBOX_INT + (mbx << 3));
dev_dbg(>pdev->dev, "PF interrupt Mbox%d 0x%llx\n", mbx, intr);
-   for (vf = 0; vf < vf_per_mbx_reg; vf++) {
+   for (vf = 0; vf < NIC_VF_PER_MBX_REG; vf++) {
if (intr & (1ULL << vf)) {
dev_dbg(>pdev->dev, "Intr from VF %d\n",
-   vf + (mbx * vf_per_mbx_reg));
+   vf + (mbx * NIC_VF_PER_MBX_REG));
 
-   nic_handle_mbx_intr(nic, vf + (mbx * vf_per_mbx_reg));
+   nic_handle_mbx_intr(nic, vf +
+   (mbx * NIC_VF_PER_MBX_REG));
nic_clear_mbx_intr(nic, vf, mbx);
}
}
-- 
2.14.3

[PATCH v2 5/7] net: thunderx: add XCAST messages handlers for PF

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

This commit is to add message handling for ndo_set_rx_mode()
callback at PF side.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nic_main.c | 45 +++---
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c 
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 7ff66a8194e2..55af04fa03a7 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -21,6 +21,8 @@
 #define DRV_NAME   "nicpf"
 #define DRV_VERSION"1.0"
 
+#define NIC_VF_PER_MBX_REG  64
+
 struct hw_info {
u8  bgx_cnt;
u8  chans_per_lmac;
@@ -1072,6 +1074,40 @@ static void nic_handle_mbx_intr(struct nicpf *nic, int 
vf)
case NIC_MBOX_MSG_PTP_CFG:
nic_config_timestamp(nic, vf, );
break;
+   case NIC_MBOX_MSG_RESET_XCAST:
+   if (vf >= nic->num_vf_en) {
+   ret = -1; /* NACK */
+   break;
+   }
+   bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   bgx_reset_xcast_mode(nic->node, bgx, lmac,
+vf < NIC_VF_PER_MBX_REG ? vf :
+vf - NIC_VF_PER_MBX_REG);
+   break;
+
+   case NIC_MBOX_MSG_ADD_MCAST:
+   if (vf >= nic->num_vf_en) {
+   ret = -1; /* NACK */
+   break;
+   }
+   bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   bgx_set_dmac_cam_filter(nic->node, bgx, lmac,
+   mbx.xcast.data.mac,
+   vf < NIC_VF_PER_MBX_REG ? vf :
+   vf - NIC_VF_PER_MBX_REG);
+   break;
+
+   case NIC_MBOX_MSG_SET_XCAST:
+   if (vf >= nic->num_vf_en) {
+   ret = -1; /* NACK */
+   break;
+   }
+   bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   bgx_set_xcast_mode(nic->node, bgx, lmac, mbx.xcast.data.mode);
+   break;
default:
dev_err(>pdev->dev,
"Invalid msg from VF%d, msg 0x%x\n", vf, mbx.msg.msg);
@@ -1094,7 +1130,7 @@ static irqreturn_t nic_mbx_intr_handler(int irq, void 
*nic_irq)
struct nicpf *nic = (struct nicpf *)nic_irq;
int mbx;
u64 intr;
-   u8  vf, vf_per_mbx_reg = 64;
+   u8  vf;
 
if (irq == pci_irq_vector(nic->pdev, NIC_PF_INTR_ID_MBOX0))
mbx = 0;
@@ -1103,12 +1139,13 @@ static irqreturn_t nic_mbx_intr_handler(int irq, void 
*nic_irq)
 
intr = nic_reg_read(nic, NIC_PF_MAILBOX_INT + (mbx << 3));
dev_dbg(>pdev->dev, "PF interrupt Mbox%d 0x%llx\n", mbx, intr);
-   for (vf = 0; vf < vf_per_mbx_reg; vf++) {
+   for (vf = 0; vf < NIC_VF_PER_MBX_REG; vf++) {
if (intr & (1ULL << vf)) {
dev_dbg(>pdev->dev, "Intr from VF %d\n",
-   vf + (mbx * vf_per_mbx_reg));
+   vf + (mbx * NIC_VF_PER_MBX_REG));
 
-   nic_handle_mbx_intr(nic, vf + (mbx * vf_per_mbx_reg));
+   nic_handle_mbx_intr(nic, vf +
+   (mbx * NIC_VF_PER_MBX_REG));
nic_clear_mbx_intr(nic, vf, mbx);
}
}
-- 
2.14.3

[PATCH v2 7/7] net: thunderx: add ndo_set_rx_mode callback implementation for VF

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ndo_set_rx_mode() is called from atomic context which causes
messages response timeouts while VF to PF communication via MSIx.
To get rid of that we're copy passed mc list, parse flags and queue
handling of kernel request to ordered workqueue.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nicvf_main.c | 110 ++-
 1 file changed, 109 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c 
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 7d9c5ffbd041..c8a8faaf17e9 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "nic_reg.h"
 #include "nic.h"
@@ -67,6 +68,9 @@ module_param(cpi_alg, int, S_IRUGO);
 MODULE_PARM_DESC(cpi_alg,
 "PFC algorithm (0=none, 1=VLAN, 2=VLAN16, 3=IP Diffserv)");
 
+/* workqueue for handling kernel ndo_set_rx_mode() calls */
+static struct workqueue_struct *nicvf_rx_mode_wq;
+
 static inline u8 nicvf_netdev_qidx(struct nicvf *nic, u8 qidx)
 {
if (nic->sqs_mode)
@@ -1919,6 +1923,100 @@ static int nicvf_ioctl(struct net_device *netdev, 
struct ifreq *req, int cmd)
}
 }
 
+static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
+{
+   struct nicvf_work *vf_work = container_of(work_arg, struct nicvf_work,
+ work.work);
+   struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
+   union nic_mbx mbx = {};
+   struct xcast_addr *xaddr, *next;
+
+   if (!vf_work)
+   return;
+
+   /* From the inside of VM code flow we have only 128 bits memory
+* available to send message to host's PF, so send all mc addrs
+* one by one, starting from flush command in case if kernel
+* requests to configure specific MAC filtering
+*/
+
+   /* flush DMAC filters and reset RX mode */
+   mbx.xcast.msg = NIC_MBOX_MSG_RESET_XCAST;
+   nicvf_send_msg_to_pf(nic, );
+
+   if (vf_work->mode & BGX_XCAST_MCAST_FILTER) {
+   /* once enabling filtering, we need to signal to PF to add
+* its' own LMAC to the filter to accept packets for it.
+*/
+   mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
+   mbx.xcast.data.mac = 0;
+   nicvf_send_msg_to_pf(nic, );
+   }
+
+   /* check if we have any specific MACs to be added to PF DMAC filter */
+   if (vf_work->mc) {
+   /* now go through kernel list of MACs and add them one by one */
+   list_for_each_entry_safe(xaddr, next,
+_work->mc->list, list) {
+   mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
+   mbx.xcast.data.mac = xaddr->addr;
+   nicvf_send_msg_to_pf(nic, );
+
+   /* after receiving ACK from PF release memory */
+   list_del(>list);
+   kfree(xaddr);
+   vf_work->mc->count--;
+   }
+   kfree(vf_work->mc);
+   }
+
+   /* and finally set rx mode for PF accordingly */
+   mbx.xcast.msg = NIC_MBOX_MSG_SET_XCAST;
+   mbx.xcast.data.mode = vf_work->mode;
+
+   nicvf_send_msg_to_pf(nic, );
+}
+
+static void nicvf_set_rx_mode(struct net_device *netdev)
+{
+   struct nicvf *nic = netdev_priv(netdev);
+   struct netdev_hw_addr *ha;
+   struct xcast_addr_list *mc_list = NULL;
+   u8 mode = 0;
+
+   if (netdev->flags & IFF_PROMISC) {
+   mode = BGX_XCAST_BCAST_ACCEPT | BGX_XCAST_MCAST_ACCEPT;
+   } else {
+   if (netdev->flags & IFF_BROADCAST)
+   mode |= BGX_XCAST_BCAST_ACCEPT;
+
+   if (netdev->flags & IFF_ALLMULTI) {
+   mode |= BGX_XCAST_MCAST_ACCEPT;
+   } else if (netdev->flags & IFF_MULTICAST) {
+   mode |= BGX_XCAST_MCAST_FILTER;
+   /* here we need to copy mc addrs */
+   if (netdev_mc_count(netdev)) {
+   struct xcast_addr *xaddr;
+
+   mc_list = kmalloc(sizeof(*mc_list), GFP_ATOMIC);
+   INIT_LIST_HEAD(_list->list);
+   netdev_hw_addr_list_for_each(ha, >mc) {
+   xaddr = kmalloc(sizeof(*xaddr),
+   GFP_ATOMIC);
+   xaddr->addr =
+   ether_addr_to_u64(ha->addr);
+   list_add_tail(>list,
+ _list->list);
+

[PATCH v2 7/7] net: thunderx: add ndo_set_rx_mode callback implementation for VF

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ndo_set_rx_mode() is called from atomic context which causes
messages response timeouts while VF to PF communication via MSIx.
To get rid of that we're copy passed mc list, parse flags and queue
handling of kernel request to ordered workqueue.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nicvf_main.c | 110 ++-
 1 file changed, 109 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c 
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 7d9c5ffbd041..c8a8faaf17e9 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "nic_reg.h"
 #include "nic.h"
@@ -67,6 +68,9 @@ module_param(cpi_alg, int, S_IRUGO);
 MODULE_PARM_DESC(cpi_alg,
 "PFC algorithm (0=none, 1=VLAN, 2=VLAN16, 3=IP Diffserv)");
 
+/* workqueue for handling kernel ndo_set_rx_mode() calls */
+static struct workqueue_struct *nicvf_rx_mode_wq;
+
 static inline u8 nicvf_netdev_qidx(struct nicvf *nic, u8 qidx)
 {
if (nic->sqs_mode)
@@ -1919,6 +1923,100 @@ static int nicvf_ioctl(struct net_device *netdev, 
struct ifreq *req, int cmd)
}
 }
 
+static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
+{
+   struct nicvf_work *vf_work = container_of(work_arg, struct nicvf_work,
+ work.work);
+   struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
+   union nic_mbx mbx = {};
+   struct xcast_addr *xaddr, *next;
+
+   if (!vf_work)
+   return;
+
+   /* From the inside of VM code flow we have only 128 bits memory
+* available to send message to host's PF, so send all mc addrs
+* one by one, starting from flush command in case if kernel
+* requests to configure specific MAC filtering
+*/
+
+   /* flush DMAC filters and reset RX mode */
+   mbx.xcast.msg = NIC_MBOX_MSG_RESET_XCAST;
+   nicvf_send_msg_to_pf(nic, );
+
+   if (vf_work->mode & BGX_XCAST_MCAST_FILTER) {
+   /* once enabling filtering, we need to signal to PF to add
+* its' own LMAC to the filter to accept packets for it.
+*/
+   mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
+   mbx.xcast.data.mac = 0;
+   nicvf_send_msg_to_pf(nic, );
+   }
+
+   /* check if we have any specific MACs to be added to PF DMAC filter */
+   if (vf_work->mc) {
+   /* now go through kernel list of MACs and add them one by one */
+   list_for_each_entry_safe(xaddr, next,
+_work->mc->list, list) {
+   mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
+   mbx.xcast.data.mac = xaddr->addr;
+   nicvf_send_msg_to_pf(nic, );
+
+   /* after receiving ACK from PF release memory */
+   list_del(>list);
+   kfree(xaddr);
+   vf_work->mc->count--;
+   }
+   kfree(vf_work->mc);
+   }
+
+   /* and finally set rx mode for PF accordingly */
+   mbx.xcast.msg = NIC_MBOX_MSG_SET_XCAST;
+   mbx.xcast.data.mode = vf_work->mode;
+
+   nicvf_send_msg_to_pf(nic, );
+}
+
+static void nicvf_set_rx_mode(struct net_device *netdev)
+{
+   struct nicvf *nic = netdev_priv(netdev);
+   struct netdev_hw_addr *ha;
+   struct xcast_addr_list *mc_list = NULL;
+   u8 mode = 0;
+
+   if (netdev->flags & IFF_PROMISC) {
+   mode = BGX_XCAST_BCAST_ACCEPT | BGX_XCAST_MCAST_ACCEPT;
+   } else {
+   if (netdev->flags & IFF_BROADCAST)
+   mode |= BGX_XCAST_BCAST_ACCEPT;
+
+   if (netdev->flags & IFF_ALLMULTI) {
+   mode |= BGX_XCAST_MCAST_ACCEPT;
+   } else if (netdev->flags & IFF_MULTICAST) {
+   mode |= BGX_XCAST_MCAST_FILTER;
+   /* here we need to copy mc addrs */
+   if (netdev_mc_count(netdev)) {
+   struct xcast_addr *xaddr;
+
+   mc_list = kmalloc(sizeof(*mc_list), GFP_ATOMIC);
+   INIT_LIST_HEAD(_list->list);
+   netdev_hw_addr_list_for_each(ha, >mc) {
+   xaddr = kmalloc(sizeof(*xaddr),
+   GFP_ATOMIC);
+   xaddr->addr =
+   ether_addr_to_u64(ha->addr);
+   list_add_tail(>list,
+ _list->list);
+   mc_list->count++;
+  

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Ingo Molnar]

* Dominik Brodowski  wrote:

> On Fri, Mar 30, 2018 at 01:03:54PM +0200, Ingo Molnar wrote:
> > 
> > * Dominik Brodowski  wrote:
> > 
> > > > > The whole series is available at
> > > > > 
> > > > > 
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > > > > syscalls-WIP
> > > > 
> > > > BTW., I'd like all these bits to go through the x86 tree.
> > > > 
> > > > What is the expected merge route of the generic preparatory bits?
> > > 
> > > My current plan is to push the 109 patch bomb to remove in-kernel calls 
> > > to syscalls
> > > directly to Linus once v4.16 is released.
> > 
> > Are there any (textual and semantic) conflicts with the latest -next?
> > 
> > Also, to what extent were these 109 patches tested in -next?
> 
> These 109 patches are equivalent to the syscalls tree in linux-next. Most of
> these patches habe been in there for quite a while (the last major batch went
> in on March 22; other patches are in there since March 14th).
> 
> Conflicts existend with asm-generic and metag (which contain remvoal of some
> architectures; I have solved that issue by not caring about those archs any
> more); trivial conflicts exist since very few days with the vfs and sparc
> trees.

Ok, great - all that sounds good to me, and I'll integrate the x86 bits once 
the 
generic bits are upstream.

Thanks,

Ingo

[PATCH v2 6/7] net: thunderx: add workqueue control structures for handle ndo_set_rx_mode request

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The kernel calls ndo_set_rx_mode() callback from atomic context which
causes messaging timeouts between VF and PF (as they’re implemented via
MSIx). So in order to handle ndo_set_rx_mode() we need to get rid of it.

This commit implements necessary workqueue related structures to let VF
queue kernel request processing in non-atomic context later.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nic.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h 
b/drivers/net/ethernet/cavium/thunder/nic.h
index 069289b4f968..5fc46c5a4f36 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -265,6 +265,22 @@ struct nicvf_drv_stats {
 
 struct cavium_ptp;
 
+struct xcast_addr {
+   struct list_head list;
+   u64  addr;
+};
+
+struct xcast_addr_list {
+   struct list_head list;
+   int  count;
+};
+
+struct nicvf_work {
+   struct delayed_workwork;
+   u8 mode;
+   struct xcast_addr_list *mc;
+};
+
 struct nicvf {
struct nicvf*pnicvf;
struct net_device   *netdev;
@@ -313,6 +329,7 @@ struct nicvf {
struct nicvf_pfcpfc;
struct tasklet_struct   qs_err_task;
struct work_struct  reset_task;
+   struct nicvf_work   rx_mode_work;
 
/* PTP timestamp */
struct cavium_ptp   *ptp_clock;
-- 
2.14.3

[PATCH v2 6/7] net: thunderx: add workqueue control structures for handle ndo_set_rx_mode request

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The kernel calls ndo_set_rx_mode() callback from atomic context which
causes messaging timeouts between VF and PF (as they’re implemented via
MSIx). So in order to handle ndo_set_rx_mode() we need to get rid of it.

This commit implements necessary workqueue related structures to let VF
queue kernel request processing in non-atomic context later.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nic.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h 
b/drivers/net/ethernet/cavium/thunder/nic.h
index 069289b4f968..5fc46c5a4f36 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -265,6 +265,22 @@ struct nicvf_drv_stats {
 
 struct cavium_ptp;
 
+struct xcast_addr {
+   struct list_head list;
+   u64  addr;
+};
+
+struct xcast_addr_list {
+   struct list_head list;
+   int  count;
+};
+
+struct nicvf_work {
+   struct delayed_workwork;
+   u8 mode;
+   struct xcast_addr_list *mc;
+};
+
 struct nicvf {
struct nicvf*pnicvf;
struct net_device   *netdev;
@@ -313,6 +329,7 @@ struct nicvf {
struct nicvf_pfcpfc;
struct tasklet_struct   qs_err_task;
struct work_struct  reset_task;
+   struct nicvf_work   rx_mode_work;
 
/* PTP timestamp */
struct cavium_ptp   *ptp_clock;
-- 
2.14.3

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Ingo Molnar]

* Dominik Brodowski  wrote:

> On Fri, Mar 30, 2018 at 01:03:54PM +0200, Ingo Molnar wrote:
> > 
> > * Dominik Brodowski  wrote:
> > 
> > > > > The whole series is available at
> > > > > 
> > > > > 
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > > > > syscalls-WIP
> > > > 
> > > > BTW., I'd like all these bits to go through the x86 tree.
> > > > 
> > > > What is the expected merge route of the generic preparatory bits?
> > > 
> > > My current plan is to push the 109 patch bomb to remove in-kernel calls 
> > > to syscalls
> > > directly to Linus once v4.16 is released.
> > 
> > Are there any (textual and semantic) conflicts with the latest -next?
> > 
> > Also, to what extent were these 109 patches tested in -next?
> 
> These 109 patches are equivalent to the syscalls tree in linux-next. Most of
> these patches habe been in there for quite a while (the last major batch went
> in on March 22; other patches are in there since March 14th).
> 
> Conflicts existend with asm-generic and metag (which contain remvoal of some
> architectures; I have solved that issue by not caring about those archs any
> more); trivial conflicts exist since very few days with the vfs and sparc
> trees.

Ok, great - all that sounds good to me, and I'll integrate the x86 bits once 
the 
generic bits are upstream.

Thanks,

Ingo

[PATCH v2 0/7] net: thunderx: implement DMAC filtering support

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

By default CN88XX BGX accepts all incoming multicast and broadcast
packets and filtering is disabled. The nic driver doesn't provide
an ability to change such behaviour.

This series is to implement DMAC filtering management for CN88XX
nic driver allowing user to enable/disable filtering and configure
specific MAC addresses to filter traffic.

Changes from v1:
build issues:
 - update code in order to address compiler warnings;
checkpatch.pl reported issues:
 - update code in order to fit 80 symbols length;
 - update commit descriptions in order to fit 80 symbols length;

Vadim Lomovtsev (7):
  net: thunderx: move filter register related macro into proper place
  net: thunderx: add MAC address filter tracking for LMAC
  net: thunderx: add multicast filter management support
  net: thunderx: add new messages for handle ndo_set_rx_mode callback
  net: thunderx: add XCAST messages handlers for PF
  net: thunderx: add workqueue control structures for handle
ndo_set_rx_mode request
  net: thunderx: add ndo_set_rx_mode callback implementation for VF

 drivers/net/ethernet/cavium/thunder/nic.h |  29 
 drivers/net/ethernet/cavium/thunder/nic_main.c|  45 -
 drivers/net/ethernet/cavium/thunder/nicvf_main.c  | 110 +++-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 201 --
 drivers/net/ethernet/cavium/thunder/thunder_bgx.h |  19 +-
 5 files changed, 374 insertions(+), 30 deletions(-)

-- 
2.14.3

[PATCH v2 3/7] net: thunderx: add multicast filter management support

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ThunderX NIC could be partitioned to up to 128 VFs and thus
represented to system. Each VF is mapped to pair BGX:LMAC, and each of VF
is configured by kernel individually. Eventually the bunch of VFs could be
mapped onto same pair BGX:LMAC and thus could cause several multicast
filtering configuration requests to LMAC with the same MAC addresses.

This commit is to add ThunderX NIC BGX filtering manipulation routines.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 144 ++
 drivers/net/ethernet/cavium/thunder/thunder_bgx.h |  10 +-
 2 files changed, 153 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index de90e6aa5a4f..5d08d2aeb172 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -258,6 +258,150 @@ static void bgx_flush_dmac_cam_filter(struct bgx *bgx, 
int lmacid)
  sizeof(u64), 0);
 }
 
+static void bgx_lmac_remove_filters(struct lmac *lmac, u8 vf_id)
+{
+   int i = 0;
+
+   if (!lmac)
+   return;
+
+   /* We've got reset filters request from some of attached VF, while the
+* others might want to keep their configuration. So in this case lets
+* iterate over all of configured filters and decrease number of
+* referencies. if some addresses get zero refs remove them from list
+*/
+   for (i = lmac->dmacs_cfg - 1; i >= 0; i--) {
+   lmac->dmacs[i].vf_map &= ~BIT_ULL(vf_id);
+   if (!lmac->dmacs[i].vf_map) {
+   lmac->dmacs_cfg--;
+   lmac->dmacs[i].dmac = 0;
+   lmac->dmacs[i].vf_map = 0;
+   }
+   }
+}
+
+static int bgx_lmac_save_filter(struct lmac *lmac, u64 dmac, u8 vf_id)
+{
+   u8 i = 0;
+
+   if (!lmac)
+   return -1;
+
+   /* At the same time we could have several VFs 'attached' to some
+* particular LMAC, and each VF is represented as network interface
+* for kernel. So from user perspective it should be possible to
+* manipulate with its' (VF) receive modes. However from PF
+* driver perspective we need to keep track of filter configurations
+* for different VFs to prevent filter values dupes
+*/
+   for (i = 0; i < lmac->dmacs_cfg; i++) {
+   if (lmac->dmacs[i].dmac == dmac) {
+   lmac->dmacs[i].vf_map |= BIT_ULL(vf_id);
+   return -1;
+   }
+   }
+
+   if (!(lmac->dmacs_cfg < lmac->dmacs_count))
+   return -1;
+
+   /* keep it for further tracking */
+   lmac->dmacs[lmac->dmacs_cfg].dmac = dmac;
+   lmac->dmacs[lmac->dmacs_cfg].vf_map = BIT_ULL(vf_id);
+   lmac->dmacs_cfg++;
+   return 0;
+}
+
+static int bgx_set_dmac_cam_filter_mac(struct bgx *bgx, int lmacid,
+  u64 cam_dmac, u8 idx)
+{
+   struct lmac *lmac = NULL;
+   u64 cfg = 0;
+
+   /* skip zero addresses as meaningless */
+   if (!cam_dmac || !bgx)
+   return -1;
+
+   lmac = >lmac[lmacid];
+
+   /* configure DCAM filtering for designated LMAC */
+   cfg = RX_DMACX_CAM_LMACID(lmacid & LMAC_ID_MASK) |
+   RX_DMACX_CAM_EN | cam_dmac;
+   bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM +
+ ((lmacid * lmac->dmacs_count) + idx) * sizeof(u64), cfg);
+   return 0;
+}
+
+void bgx_set_dmac_cam_filter(int node, int bgx_idx, int lmacid,
+u64 cam_dmac, u8 vf_id)
+{
+   struct bgx *bgx = get_bgx(node, bgx_idx);
+   struct lmac *lmac = NULL;
+
+   if (!bgx)
+   return;
+
+   lmac = >lmac[lmacid];
+
+   if (!cam_dmac)
+   cam_dmac = ether_addr_to_u64(lmac->mac);
+
+   /* since we might have several VFs attached to particular LMAC
+* and kernel could call mcast config for each of them with the
+* same MAC, check if requested MAC is already in filtering list and
+* updare/prepare list of MACs to be applied later to HW filters
+*/
+   bgx_lmac_save_filter(lmac, cam_dmac, vf_id);
+}
+EXPORT_SYMBOL(bgx_set_dmac_cam_filter);
+
+void bgx_set_xcast_mode(int node, int bgx_idx, int lmacid, u8 mode)
+{
+   struct bgx *bgx = get_bgx(node, bgx_idx);
+   struct lmac *lmac = NULL;
+   u64 cfg = 0;
+   u8 i = 0;
+
+   if (!bgx)
+   return;
+
+   lmac = >lmac[lmacid];
+
+   cfg = bgx_reg_read(bgx, lmacid, BGX_CMRX_RX_DMAC_CTL);
+   if (mode & BGX_XCAST_BCAST_ACCEPT)
+   cfg |= BCAST_ACCEPT;
+   else
+   cfg &= ~BCAST_ACCEPT;
+
+   /* disable all MCASTs and DMAC filtering */
+   cfg &= ~(CAM_ACCEPT 

[PATCH v2 0/7] net: thunderx: implement DMAC filtering support

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

By default CN88XX BGX accepts all incoming multicast and broadcast
packets and filtering is disabled. The nic driver doesn't provide
an ability to change such behaviour.

This series is to implement DMAC filtering management for CN88XX
nic driver allowing user to enable/disable filtering and configure
specific MAC addresses to filter traffic.

Changes from v1:
build issues:
 - update code in order to address compiler warnings;
checkpatch.pl reported issues:
 - update code in order to fit 80 symbols length;
 - update commit descriptions in order to fit 80 symbols length;

Vadim Lomovtsev (7):
  net: thunderx: move filter register related macro into proper place
  net: thunderx: add MAC address filter tracking for LMAC
  net: thunderx: add multicast filter management support
  net: thunderx: add new messages for handle ndo_set_rx_mode callback
  net: thunderx: add XCAST messages handlers for PF
  net: thunderx: add workqueue control structures for handle
ndo_set_rx_mode request
  net: thunderx: add ndo_set_rx_mode callback implementation for VF

 drivers/net/ethernet/cavium/thunder/nic.h |  29 
 drivers/net/ethernet/cavium/thunder/nic_main.c|  45 -
 drivers/net/ethernet/cavium/thunder/nicvf_main.c  | 110 +++-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 201 --
 drivers/net/ethernet/cavium/thunder/thunder_bgx.h |  19 +-
 5 files changed, 374 insertions(+), 30 deletions(-)

-- 
2.14.3

[PATCH v2 3/7] net: thunderx: add multicast filter management support

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ThunderX NIC could be partitioned to up to 128 VFs and thus
represented to system. Each VF is mapped to pair BGX:LMAC, and each of VF
is configured by kernel individually. Eventually the bunch of VFs could be
mapped onto same pair BGX:LMAC and thus could cause several multicast
filtering configuration requests to LMAC with the same MAC addresses.

This commit is to add ThunderX NIC BGX filtering manipulation routines.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 144 ++
 drivers/net/ethernet/cavium/thunder/thunder_bgx.h |  10 +-
 2 files changed, 153 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index de90e6aa5a4f..5d08d2aeb172 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -258,6 +258,150 @@ static void bgx_flush_dmac_cam_filter(struct bgx *bgx, 
int lmacid)
  sizeof(u64), 0);
 }
 
+static void bgx_lmac_remove_filters(struct lmac *lmac, u8 vf_id)
+{
+   int i = 0;
+
+   if (!lmac)
+   return;
+
+   /* We've got reset filters request from some of attached VF, while the
+* others might want to keep their configuration. So in this case lets
+* iterate over all of configured filters and decrease number of
+* referencies. if some addresses get zero refs remove them from list
+*/
+   for (i = lmac->dmacs_cfg - 1; i >= 0; i--) {
+   lmac->dmacs[i].vf_map &= ~BIT_ULL(vf_id);
+   if (!lmac->dmacs[i].vf_map) {
+   lmac->dmacs_cfg--;
+   lmac->dmacs[i].dmac = 0;
+   lmac->dmacs[i].vf_map = 0;
+   }
+   }
+}
+
+static int bgx_lmac_save_filter(struct lmac *lmac, u64 dmac, u8 vf_id)
+{
+   u8 i = 0;
+
+   if (!lmac)
+   return -1;
+
+   /* At the same time we could have several VFs 'attached' to some
+* particular LMAC, and each VF is represented as network interface
+* for kernel. So from user perspective it should be possible to
+* manipulate with its' (VF) receive modes. However from PF
+* driver perspective we need to keep track of filter configurations
+* for different VFs to prevent filter values dupes
+*/
+   for (i = 0; i < lmac->dmacs_cfg; i++) {
+   if (lmac->dmacs[i].dmac == dmac) {
+   lmac->dmacs[i].vf_map |= BIT_ULL(vf_id);
+   return -1;
+   }
+   }
+
+   if (!(lmac->dmacs_cfg < lmac->dmacs_count))
+   return -1;
+
+   /* keep it for further tracking */
+   lmac->dmacs[lmac->dmacs_cfg].dmac = dmac;
+   lmac->dmacs[lmac->dmacs_cfg].vf_map = BIT_ULL(vf_id);
+   lmac->dmacs_cfg++;
+   return 0;
+}
+
+static int bgx_set_dmac_cam_filter_mac(struct bgx *bgx, int lmacid,
+  u64 cam_dmac, u8 idx)
+{
+   struct lmac *lmac = NULL;
+   u64 cfg = 0;
+
+   /* skip zero addresses as meaningless */
+   if (!cam_dmac || !bgx)
+   return -1;
+
+   lmac = >lmac[lmacid];
+
+   /* configure DCAM filtering for designated LMAC */
+   cfg = RX_DMACX_CAM_LMACID(lmacid & LMAC_ID_MASK) |
+   RX_DMACX_CAM_EN | cam_dmac;
+   bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM +
+ ((lmacid * lmac->dmacs_count) + idx) * sizeof(u64), cfg);
+   return 0;
+}
+
+void bgx_set_dmac_cam_filter(int node, int bgx_idx, int lmacid,
+u64 cam_dmac, u8 vf_id)
+{
+   struct bgx *bgx = get_bgx(node, bgx_idx);
+   struct lmac *lmac = NULL;
+
+   if (!bgx)
+   return;
+
+   lmac = >lmac[lmacid];
+
+   if (!cam_dmac)
+   cam_dmac = ether_addr_to_u64(lmac->mac);
+
+   /* since we might have several VFs attached to particular LMAC
+* and kernel could call mcast config for each of them with the
+* same MAC, check if requested MAC is already in filtering list and
+* updare/prepare list of MACs to be applied later to HW filters
+*/
+   bgx_lmac_save_filter(lmac, cam_dmac, vf_id);
+}
+EXPORT_SYMBOL(bgx_set_dmac_cam_filter);
+
+void bgx_set_xcast_mode(int node, int bgx_idx, int lmacid, u8 mode)
+{
+   struct bgx *bgx = get_bgx(node, bgx_idx);
+   struct lmac *lmac = NULL;
+   u64 cfg = 0;
+   u8 i = 0;
+
+   if (!bgx)
+   return;
+
+   lmac = >lmac[lmacid];
+
+   cfg = bgx_reg_read(bgx, lmacid, BGX_CMRX_RX_DMAC_CTL);
+   if (mode & BGX_XCAST_BCAST_ACCEPT)
+   cfg |= BCAST_ACCEPT;
+   else
+   cfg &= ~BCAST_ACCEPT;
+
+   /* disable all MCASTs and DMAC filtering */
+   cfg &= ~(CAM_ACCEPT | BGX_MCAST_MODE(MCAST_MODE_MASK));
+
+   /* check 

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Dominik Brodowski]

On Fri, Mar 30, 2018 at 01:03:54PM +0200, Ingo Molnar wrote:
> 
> * Dominik Brodowski  wrote:
> 
> > > > The whole series is available at
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > > > syscalls-WIP
> > > 
> > > BTW., I'd like all these bits to go through the x86 tree.
> > > 
> > > What is the expected merge route of the generic preparatory bits?
> > 
> > My current plan is to push the 109 patch bomb to remove in-kernel calls to 
> > syscalls
> > directly to Linus once v4.16 is released.
> 
> Are there any (textual and semantic) conflicts with the latest -next?
> 
> Also, to what extent were these 109 patches tested in -next?

These 109 patches are equivalent to the syscalls tree in linux-next. Most of
these patches habe been in there for quite a while (the last major batch went
in on March 22; other patches are in there since March 14th).

Conflicts existend with asm-generic and metag (which contain remvoal of some
architectures; I have solved that issue by not caring about those archs any
more); trivial conflicts exist since very few days with the vfs and sparc
trees.

Thanks,
Dominik

Re: [PATCH v6 6/6] Staging: iio: adis16209: Move adis16209 driver out of staging

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:52:51 +0530
Shreeya Patel  wrote:

> Move the adis16209 driver out of staging directory and merge to the
> mainline IIO subsystem.
> 
> Signed-off-by: Shreeya Patel 
Other than fixing up for the patch 5 indentation change there
was some 'fuzz' due to the adis16201 moving before this one - easily
fixed up but please check I didn't get it wrong!

Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.

Good final series and good cleanup in general.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Move driver adis16209 from staging to mainline IIO subsystem
> after complete cleanup of it.
> 
>  drivers/iio/accel/Kconfig |  12 ++
>  drivers/iio/accel/Makefile|   1 +
>  drivers/iio/accel/adis16209.c | 330 
> ++
>  drivers/staging/iio/accel/Kconfig |  12 --
>  drivers/staging/iio/accel/Makefile|   1 -
>  drivers/staging/iio/accel/adis16209.c | 330 
> --
>  6 files changed, 343 insertions(+), 343 deletions(-)
>  create mode 100644 drivers/iio/accel/adis16209.c
>  delete mode 100644 drivers/staging/iio/accel/adis16209.c
> 
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index c6d9517..f95f43c 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -5,6 +5,18 @@
>  
>  menu "Accelerometers"
>  
> +config ADIS16209
> +tristate "Analog Devices ADIS16209 Dual-Axis Digital Inclinometer 
> and Accelerometer"
> +depends on SPI
> +select IIO_ADIS_LIB
> +select IIO_ADIS_LIB_BUFFER if IIO_BUFFER
> +help
> +  Say Y here to build support for Analog Devices adis16209 dual-axis 
> digital inclinometer
> +  and accelerometer.
> +
> +  To compile this driver as a module, say M here: the module will be
> +  called adis16209.
> +
>  config ADXL345
>   tristate
>  
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 368aedb..40861b9 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -4,6 +4,7 @@
>  #
>  
>  # When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_ADIS16209) += adis16209.o
>  obj-$(CONFIG_ADXL345) += adxl345_core.o
>  obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
>  obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
> diff --git a/drivers/iio/accel/adis16209.c b/drivers/iio/accel/adis16209.c
> new file mode 100644
> index 000..cc50667
> --- /dev/null
> +++ b/drivers/iio/accel/adis16209.c
> @@ -0,0 +1,330 @@
> +/*
> + * ADIS16209 Dual-Axis Digital Inclinometer and Accelerometer
> + *
> + * Copyright 2010 Analog Devices Inc.
> + *
> + * Licensed under the GPL-2 or later.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define ADIS16209_STARTUP_DELAY_MS   220
> +#define ADIS16209_FLASH_CNT_REG  0x00
> +
> +/* Data Output Register Definitions */
> +#define ADIS16209_SUPPLY_OUT_REG 0x02
> +#define ADIS16209_XACCL_OUT_REG  0x04
> +#define ADIS16209_YACCL_OUT_REG  0x06
> +/* Output, auxiliary ADC input */
> +#define ADIS16209_AUX_ADC_REG0x08
> +/* Output, temperature */
> +#define ADIS16209_TEMP_OUT_REG   0x0A
> +/* Output, +/- 90 degrees X-axis inclination */
> +#define ADIS16209_XINCL_OUT_REG  0x0C
> +#define ADIS16209_YINCL_OUT_REG  0x0E
> +/* Output, +/-180 vertical rotational position */
> +#define ADIS16209_ROT_OUT_REG0x10
> +
> +/*
> + * Calibration Register Definitions.
> + * Acceleration, inclination or rotation offset null.
> + */
> +#define ADIS16209_XACCL_NULL_REG 0x12
> +#define ADIS16209_YACCL_NULL_REG 0x14
> +#define ADIS16209_XINCL_NULL_REG 0x16
> +#define ADIS16209_YINCL_NULL_REG 0x18
> +#define ADIS16209_ROT_NULL_REG   0x1A
> +
> +/* Alarm Register Definitions */
> +#define ADIS16209_ALM_MAG1_REG   0x20
> +#define ADIS16209_ALM_MAG2_REG   0x22
> +#define ADIS16209_ALM_SMPL1_REG  0x24
> +#define ADIS16209_ALM_SMPL2_REG  0x26
> +#define ADIS16209_ALM_CTRL_REG   0x28
> +
> +#define ADIS16209_AUX_DAC_REG0x30
> +#define ADIS16209_GPIO_CTRL_REG  0x32
> +#define ADIS16209_SMPL_PRD_REG   0x36
> +#define ADIS16209_AVG_CNT_REG0x38
> +#define ADIS16209_SLP_CNT_REG0x3A
> +
> +#define ADIS16209_MSC_CTRL_REG   0x34
> +#define  ADIS16209_MSC_CTRL_PWRUP_SELF_TEST  BIT(10)
> +#define  ADIS16209_MSC_CTRL_SELF_TEST_EN BIT(8)
> +#define  ADIS16209_MSC_CTRL_DATA_RDY_EN  BIT(2)
> +/* Data-ready polarity: 1 = active high, 0 = active low */
> +#define  ADIS16209_MSC_CTRL_ACTIVE_HIGH  BIT(1)
> +#define  

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Dominik Brodowski]

On Fri, Mar 30, 2018 at 01:03:54PM +0200, Ingo Molnar wrote:
> 
> * Dominik Brodowski  wrote:
> 
> > > > The whole series is available at
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > > > syscalls-WIP
> > > 
> > > BTW., I'd like all these bits to go through the x86 tree.
> > > 
> > > What is the expected merge route of the generic preparatory bits?
> > 
> > My current plan is to push the 109 patch bomb to remove in-kernel calls to 
> > syscalls
> > directly to Linus once v4.16 is released.
> 
> Are there any (textual and semantic) conflicts with the latest -next?
> 
> Also, to what extent were these 109 patches tested in -next?

These 109 patches are equivalent to the syscalls tree in linux-next. Most of
these patches habe been in there for quite a while (the last major batch went
in on March 22; other patches are in there since March 14th).

Conflicts existend with asm-generic and metag (which contain remvoal of some
architectures; I have solved that issue by not caring about those archs any
more); trivial conflicts exist since very few days with the vfs and sparc
trees.

Thanks,
Dominik

Re: [PATCH v6 6/6] Staging: iio: adis16209: Move adis16209 driver out of staging

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:52:51 +0530
Shreeya Patel  wrote:

> Move the adis16209 driver out of staging directory and merge to the
> mainline IIO subsystem.
> 
> Signed-off-by: Shreeya Patel 
Other than fixing up for the patch 5 indentation change there
was some 'fuzz' due to the adis16201 moving before this one - easily
fixed up but please check I didn't get it wrong!

Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.

Good final series and good cleanup in general.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Move driver adis16209 from staging to mainline IIO subsystem
> after complete cleanup of it.
> 
>  drivers/iio/accel/Kconfig |  12 ++
>  drivers/iio/accel/Makefile|   1 +
>  drivers/iio/accel/adis16209.c | 330 
> ++
>  drivers/staging/iio/accel/Kconfig |  12 --
>  drivers/staging/iio/accel/Makefile|   1 -
>  drivers/staging/iio/accel/adis16209.c | 330 
> --
>  6 files changed, 343 insertions(+), 343 deletions(-)
>  create mode 100644 drivers/iio/accel/adis16209.c
>  delete mode 100644 drivers/staging/iio/accel/adis16209.c
> 
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index c6d9517..f95f43c 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -5,6 +5,18 @@
>  
>  menu "Accelerometers"
>  
> +config ADIS16209
> +tristate "Analog Devices ADIS16209 Dual-Axis Digital Inclinometer 
> and Accelerometer"
> +depends on SPI
> +select IIO_ADIS_LIB
> +select IIO_ADIS_LIB_BUFFER if IIO_BUFFER
> +help
> +  Say Y here to build support for Analog Devices adis16209 dual-axis 
> digital inclinometer
> +  and accelerometer.
> +
> +  To compile this driver as a module, say M here: the module will be
> +  called adis16209.
> +
>  config ADXL345
>   tristate
>  
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 368aedb..40861b9 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -4,6 +4,7 @@
>  #
>  
>  # When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_ADIS16209) += adis16209.o
>  obj-$(CONFIG_ADXL345) += adxl345_core.o
>  obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
>  obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
> diff --git a/drivers/iio/accel/adis16209.c b/drivers/iio/accel/adis16209.c
> new file mode 100644
> index 000..cc50667
> --- /dev/null
> +++ b/drivers/iio/accel/adis16209.c
> @@ -0,0 +1,330 @@
> +/*
> + * ADIS16209 Dual-Axis Digital Inclinometer and Accelerometer
> + *
> + * Copyright 2010 Analog Devices Inc.
> + *
> + * Licensed under the GPL-2 or later.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define ADIS16209_STARTUP_DELAY_MS   220
> +#define ADIS16209_FLASH_CNT_REG  0x00
> +
> +/* Data Output Register Definitions */
> +#define ADIS16209_SUPPLY_OUT_REG 0x02
> +#define ADIS16209_XACCL_OUT_REG  0x04
> +#define ADIS16209_YACCL_OUT_REG  0x06
> +/* Output, auxiliary ADC input */
> +#define ADIS16209_AUX_ADC_REG0x08
> +/* Output, temperature */
> +#define ADIS16209_TEMP_OUT_REG   0x0A
> +/* Output, +/- 90 degrees X-axis inclination */
> +#define ADIS16209_XINCL_OUT_REG  0x0C
> +#define ADIS16209_YINCL_OUT_REG  0x0E
> +/* Output, +/-180 vertical rotational position */
> +#define ADIS16209_ROT_OUT_REG0x10
> +
> +/*
> + * Calibration Register Definitions.
> + * Acceleration, inclination or rotation offset null.
> + */
> +#define ADIS16209_XACCL_NULL_REG 0x12
> +#define ADIS16209_YACCL_NULL_REG 0x14
> +#define ADIS16209_XINCL_NULL_REG 0x16
> +#define ADIS16209_YINCL_NULL_REG 0x18
> +#define ADIS16209_ROT_NULL_REG   0x1A
> +
> +/* Alarm Register Definitions */
> +#define ADIS16209_ALM_MAG1_REG   0x20
> +#define ADIS16209_ALM_MAG2_REG   0x22
> +#define ADIS16209_ALM_SMPL1_REG  0x24
> +#define ADIS16209_ALM_SMPL2_REG  0x26
> +#define ADIS16209_ALM_CTRL_REG   0x28
> +
> +#define ADIS16209_AUX_DAC_REG0x30
> +#define ADIS16209_GPIO_CTRL_REG  0x32
> +#define ADIS16209_SMPL_PRD_REG   0x36
> +#define ADIS16209_AVG_CNT_REG0x38
> +#define ADIS16209_SLP_CNT_REG0x3A
> +
> +#define ADIS16209_MSC_CTRL_REG   0x34
> +#define  ADIS16209_MSC_CTRL_PWRUP_SELF_TEST  BIT(10)
> +#define  ADIS16209_MSC_CTRL_SELF_TEST_EN BIT(8)
> +#define  ADIS16209_MSC_CTRL_DATA_RDY_EN  BIT(2)
> +/* Data-ready polarity: 1 = active high, 0 = active low */
> +#define  ADIS16209_MSC_CTRL_ACTIVE_HIGH  BIT(1)
> +#define  ADIS16209_MSC_CTRL_DATA_RDY_DIO2BIT(0)
> +
> +#define 

[PATCH] PM / devfreq: use put_device() instead of kfree()

[Arvind Yadav]

Never directly free @dev after calling device_register() or
device_unregister(), even if device_register() returned an error.
Always use put_device() to give up the reference initialized.

Signed-off-by: Arvind Yadav 
---
 drivers/devfreq/devfreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index fe2af6a..a225b94 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -625,7 +625,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
err = device_register(>dev);
if (err) {
mutex_unlock(>lock);
-   goto err_dev;
+   put_device(>dev);
+   goto err_out;
}
 
devfreq->trans_table =  devm_kzalloc(>dev,
@@ -671,6 +672,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_unlock(_list_lock);
 
device_unregister(>dev);
+   devfreq = NULL;
 err_dev:
if (devfreq)
kfree(devfreq);
-- 
2.7.4

[PATCH] PM / devfreq: use put_device() instead of kfree()

[Arvind Yadav]

Never directly free @dev after calling device_register() or
device_unregister(), even if device_register() returned an error.
Always use put_device() to give up the reference initialized.

Signed-off-by: Arvind Yadav 
---
 drivers/devfreq/devfreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index fe2af6a..a225b94 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -625,7 +625,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
err = device_register(>dev);
if (err) {
mutex_unlock(>lock);
-   goto err_dev;
+   put_device(>dev);
+   goto err_out;
}
 
devfreq->trans_table =  devm_kzalloc(>dev,
@@ -671,6 +672,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_unlock(_list_lock);
 
device_unregister(>dev);
+   devfreq = NULL;
 err_dev:
if (devfreq)
kfree(devfreq);
-- 
2.7.4

Re: [PATCH v6 5/6] Staging: iio: adis16209: Use GENMASK

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:51:19 +0530
Shreeya Patel  wrote:

> Use GENMASK to improve readability and remove the local
> variables used to store intermediate data.
> 
> Signed-off-by: Shreeya Patel 
See below.

Fixed up and applied to the togreg branch of iio.git and pushed out
as testing for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 19 ---
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index ed6d7c7..cc50667 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -112,25 +112,22 @@ static int adis16209_write_raw(struct iio_dev 
> *indio_dev,
>  long mask)
>  {
>   struct adis *st = iio_priv(indio_dev);
> - int bits;
> - s16 val16;
> - u8 addr;
> + int m;
> +
> + if (mask != IIO_CHAN_INFO_CALIBBIAS)
> + return -EINVAL;
>  
> - switch (mask) {
> - case IIO_CHAN_INFO_CALIBBIAS:
Looks to me like the indenting is now incorrect.
The next block should be one less tab in.

>   switch (chan->type) {
>   case IIO_ACCEL:
>   case IIO_INCLI:
> - bits = 14;
> + m = GENMASK(13, 0);
>   break;
>   default:
>   return -EINVAL;
>   }
> - val16 = val & ((1 << bits) - 1);
> - addr = adis16209_addresses[chan->scan_index][0];
> - return adis_write_reg_16(st, addr, val16);
> - }
> - return -EINVAL;
> +
> + return adis_write_reg_16(st, adis16209_addresses[chan->scan_index][0],
> +  val & m);
>  }
>  
>  static int adis16209_read_raw(struct iio_dev *indio_dev,

Re: [PATCH v6 5/6] Staging: iio: adis16209: Use GENMASK

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:51:19 +0530
Shreeya Patel  wrote:

> Use GENMASK to improve readability and remove the local
> variables used to store intermediate data.
> 
> Signed-off-by: Shreeya Patel 
See below.

Fixed up and applied to the togreg branch of iio.git and pushed out
as testing for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 19 ---
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index ed6d7c7..cc50667 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -112,25 +112,22 @@ static int adis16209_write_raw(struct iio_dev 
> *indio_dev,
>  long mask)
>  {
>   struct adis *st = iio_priv(indio_dev);
> - int bits;
> - s16 val16;
> - u8 addr;
> + int m;
> +
> + if (mask != IIO_CHAN_INFO_CALIBBIAS)
> + return -EINVAL;
>  
> - switch (mask) {
> - case IIO_CHAN_INFO_CALIBBIAS:
Looks to me like the indenting is now incorrect.
The next block should be one less tab in.

>   switch (chan->type) {
>   case IIO_ACCEL:
>   case IIO_INCLI:
> - bits = 14;
> + m = GENMASK(13, 0);
>   break;
>   default:
>   return -EINVAL;
>   }
> - val16 = val & ((1 << bits) - 1);
> - addr = adis16209_addresses[chan->scan_index][0];
> - return adis_write_reg_16(st, addr, val16);
> - }
> - return -EINVAL;
> +
> + return adis_write_reg_16(st, adis16209_addresses[chan->scan_index][0],
> +  val & m);
>  }
>  
>  static int adis16209_read_raw(struct iio_dev *indio_dev,

Re: [PATCH v6 4/6] Staging: iio: adis16209: Remove unused headers

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:49:22 +0530
Shreeya Patel  wrote:

> Remove few unused header files since the adis core handles
> the sysfs and buffer support.
> 
> Signed-off-by: Shreeya Patel 
Applied,

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index ee7e87b..ed6d7c7 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -6,7 +6,6 @@
>   * Licensed under the GPL-2 or later.
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -16,8 +15,6 @@
>  #include 
>  
>  #include 
> -#include 
> -#include 
>  #include 
>  
>  #define ADIS16209_STARTUP_DELAY_MS   220

Re: [PATCH v6 4/6] Staging: iio: adis16209: Remove unused headers

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:49:22 +0530
Shreeya Patel  wrote:

> Remove few unused header files since the adis core handles
> the sysfs and buffer support.
> 
> Signed-off-by: Shreeya Patel 
Applied,

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index ee7e87b..ed6d7c7 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -6,7 +6,6 @@
>   * Licensed under the GPL-2 or later.
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -16,8 +15,6 @@
>  #include 
>  
>  #include 
> -#include 
> -#include 
>  #include 
>  
>  #define ADIS16209_STARTUP_DELAY_MS   220

Re: [PATCH v6 3/6] Staging: iio: adis16209: Add a blank line after return statements

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:44:42 +0530
Shreeya Patel  wrote:

> Add a blank line after return statements to improve the code
> readability.
> 
> Signed-off-by: Shreeya Patel 
Applied to the togreg branch of iio.git and pushed out as
testing for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index 8f4fa6b..ee7e87b 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -277,6 +277,7 @@ static int adis16209_probe(struct spi_device *spi)
>   indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
>   if (!indio_dev)
>   return -ENOMEM;
> +
>   st = iio_priv(indio_dev);
>   spi_set_drvdata(spi, indio_dev);
>  
> @@ -290,6 +291,7 @@ static int adis16209_probe(struct spi_device *spi)
>   ret = adis_init(st, indio_dev, spi, _data);
>   if (ret)
>   return ret;
> +
>   ret = adis_setup_buffer_and_trigger(st, indio_dev, NULL);
>   if (ret)
>   return ret;

Re: [PATCH v6 3/6] Staging: iio: adis16209: Add a blank line after return statements

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:44:42 +0530
Shreeya Patel  wrote:

> Add a blank line after return statements to improve the code
> readability.
> 
> Signed-off-by: Shreeya Patel 
Applied to the togreg branch of iio.git and pushed out as
testing for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index 8f4fa6b..ee7e87b 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -277,6 +277,7 @@ static int adis16209_probe(struct spi_device *spi)
>   indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
>   if (!indio_dev)
>   return -ENOMEM;
> +
>   st = iio_priv(indio_dev);
>   spi_set_drvdata(spi, indio_dev);
>  
> @@ -290,6 +291,7 @@ static int adis16209_probe(struct spi_device *spi)
>   ret = adis_init(st, indio_dev, spi, _data);
>   if (ret)
>   return ret;
> +
>   ret = adis_setup_buffer_and_trigger(st, indio_dev, NULL);
>   if (ret)
>   return ret;

Re: [PATCH v6 2/6] Staging: iio: adis16209: Prefer reverse christmas tree ordering

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:43:23 +0530
Shreeya Patel  wrote:

> Prefer reverse christmas tree ordering of declarations to
> improve readability.
> 
> Signed-off-by: Shreeya Patel 
Applied to the togreg branch of iio.git and pushed out as
testing for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index 0e6366a..8f4fa6b 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -270,9 +270,9 @@ static const struct adis_data adis16209_data = {
>  
>  static int adis16209_probe(struct spi_device *spi)
>  {
> - int ret;
> - struct adis *st;
>   struct iio_dev *indio_dev;
> + struct adis *st;
> + int ret;
>  
>   indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
>   if (!indio_dev)

Re: [PATCH v6 2/6] Staging: iio: adis16209: Prefer reverse christmas tree ordering

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:43:23 +0530
Shreeya Patel  wrote:

> Prefer reverse christmas tree ordering of declarations to
> improve readability.
> 
> Signed-off-by: Shreeya Patel 
Applied to the togreg branch of iio.git and pushed out as
testing for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index 0e6366a..8f4fa6b 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -270,9 +270,9 @@ static const struct adis_data adis16209_data = {
>  
>  static int adis16209_probe(struct spi_device *spi)
>  {
> - int ret;
> - struct adis *st;
>   struct iio_dev *indio_dev;
> + struct adis *st;
> + int ret;
>  
>   indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
>   if (!indio_dev)

Re: [Question] Documentation/features: More automation/scripting help?

[Ingo Molnar]

* Andrea Parri  wrote:

> Hi all,
> 
> The directory (not yet three years old although, I freely admit, I've
> only recently become aware of it) provides arch. support matrices for
> more than 40 generic kernel features that need per-arch. support:
> 
> This is a superb project! ;-)  and not a simple one given that, to be
> effective, this requires the prompt collaboration between (the intere-
> sted) features maintainers/developers, every architecture maintainers,
> and documentation maintainers.
> 
> There currently appear to be some mismatches between such doc and the
> the actual state of the code (e.g., missing architecture, feature not
> existing anymore, status flags out-of-date). Realized this, I started
> to patch the doc, but this process became soon tedious (consider also
> that I barely know what some of these features are about...).
> 
> Hence this post. I am wondering if it would make sense to script some
> of these matrices.  So, rather than (or together with) using the cur-
> rently hard-coded matrices, try to (automatically) generate them from
> the sources/configs. Consider the sketch below (sorry for the raw sh).
> 
> diff --git a/Documentation/features/list-arch.sh 
> b/Documentation/features/list-arch.sh
> index c16b5b5956889..cdec0c1db9db2 100755
> --- a/Documentation/features/list-arch.sh
> +++ b/Documentation/features/list-arch.sh
> @@ -18,7 +18,13 @@ for F in */*/arch-support.txt; do
>C=$(grep -h "^# Kconfig:" $F | cut -c25-)
>D=$(grep -h "^# description:" $F | cut -c25-)
>S=$(grep -hw $ARCH $F | cut -d\| -f3)
> +  myS=$(grep -h $C ../../arch/$ARCH/Kconfig)
> +  if [ -z "$myS" ]; then
> +   myS=" -- "
> +  else
> +   myS=" ok "
> +  fi
>  
> -  printf "%10s/%-22s:%s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$C" "$D"
> +  printf "%10s/%-22s:%s VS. %s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$myS" "$C" 
> "$D"
>  done
>  
> 
> With this diff.,
> 
> andrea@andrea:~$ ./Documentation/features/list-arch.sh riscv > /tmp/riscv.txt
> grep: asm/rwsem.h: No such file or directory
> andrea@andrea:~$ cat /tmp/riscv.txt
> #
> # Kernel feature support matrix of the 'riscv' architecture:
> #
>   core/ BPF-JIT  : VS.  -- |
> HAVE_BPF_JIT #  arch supports BPF JIT optimizations
>   core/ generic-idle-thread  : VS.  ok | 
> GENERIC_SMP_IDLE_THREAD #  arch makes use of the generic SMP idle thread 
> facility
>   core/ jump-labels  : VS.  -- |
> HAVE_ARCH_JUMP_LABEL #  arch supports live patched, high efficiency branches
>   core/ tracehook: VS.  ok | 
> HAVE_ARCH_TRACEHOOK #  arch supports tracehook (ptrace) register handling APIs
>  debug/ gcov-profile-all : VS.  -- |   
> ARCH_HAS_GCOV_PROFILE_ALL #  arch supports whole-kernel GCOV code coverage 
> profiling
>  debug/ KASAN: VS.  -- | 
> HAVE_ARCH_KASAN #  arch supports the KASAN runtime memory checker
>  debug/ kgdb : VS.  -- |  
> HAVE_ARCH_KGDB #  arch supports the kGDB kernel debugger
>  debug/ kprobes  : VS.  ok |
> HAVE_KPROBES #  arch supports live patched kernel probe
>  debug/ kprobes-on-ftrace: VS.  -- |  
> HAVE_KPROBES_ON_FTRACE #  arch supports combined kprobes and ftrace live 
> patching
>  debug/ kretprobes   : VS.  -- | 
> HAVE_KRETPROBES #  arch supports kernel function-return probes
>  debug/ optprobes: VS.  -- |  
> HAVE_OPTPROBES #  arch supports live patched optprobes
>  debug/ stackprotector   : VS.  -- |  
> HAVE_CC_STACKPROTECTOR #  arch supports compiler driven stack overflow 
> protection
>  debug/ uprobes  : VS.  -- |   
> ARCH_SUPPORTS_UPROBES #  arch supports live patched user probes
>  debug/ user-ret-profiler: VS.  -- |   
> HAVE_USER_RETURN_NOTIFIER #  arch supports user-space return from system call 
> profiler
> io/ dma-api-debug: VS.  ok |  
> HAVE_DMA_API_DEBUG #  arch supports DMA debug facilities
> io/ dma-contiguous   : VS.  ok | 
> HAVE_DMA_CONTIGUOUS #  arch supports the DMA CMA (continuous memory allocator)
> io/ sg-chain : VS.  -- |   
> ARCH_HAS_SG_CHAIN #  arch supports chained scatter-gather lists
>lib/ strncasecmp  : VS.  -- | 
> __HAVE_ARCH_STRNCASECMP #  arch provides an optimized strncasecmp() function
>locking/ cmpxchg-local: VS.  -- |  
> HAVE_CMPXCHG_LOCAL #  arch supports the this_cpu_cmpxchg() API
>locking/ lockdep  : VS.  -- | 
> LOCKDEP_SUPPORT #  arch supports the runtime locking correctness debug 
> facility
>locking/ queued-rwlocks   : VS.  

Re: [Question] Documentation/features: More automation/scripting help?

[Ingo Molnar]

* Andrea Parri  wrote:

> Hi all,
> 
> The directory (not yet three years old although, I freely admit, I've
> only recently become aware of it) provides arch. support matrices for
> more than 40 generic kernel features that need per-arch. support:
> 
> This is a superb project! ;-)  and not a simple one given that, to be
> effective, this requires the prompt collaboration between (the intere-
> sted) features maintainers/developers, every architecture maintainers,
> and documentation maintainers.
> 
> There currently appear to be some mismatches between such doc and the
> the actual state of the code (e.g., missing architecture, feature not
> existing anymore, status flags out-of-date). Realized this, I started
> to patch the doc, but this process became soon tedious (consider also
> that I barely know what some of these features are about...).
> 
> Hence this post. I am wondering if it would make sense to script some
> of these matrices.  So, rather than (or together with) using the cur-
> rently hard-coded matrices, try to (automatically) generate them from
> the sources/configs. Consider the sketch below (sorry for the raw sh).
> 
> diff --git a/Documentation/features/list-arch.sh 
> b/Documentation/features/list-arch.sh
> index c16b5b5956889..cdec0c1db9db2 100755
> --- a/Documentation/features/list-arch.sh
> +++ b/Documentation/features/list-arch.sh
> @@ -18,7 +18,13 @@ for F in */*/arch-support.txt; do
>C=$(grep -h "^# Kconfig:" $F | cut -c25-)
>D=$(grep -h "^# description:" $F | cut -c25-)
>S=$(grep -hw $ARCH $F | cut -d\| -f3)
> +  myS=$(grep -h $C ../../arch/$ARCH/Kconfig)
> +  if [ -z "$myS" ]; then
> +   myS=" -- "
> +  else
> +   myS=" ok "
> +  fi
>  
> -  printf "%10s/%-22s:%s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$C" "$D"
> +  printf "%10s/%-22s:%s VS. %s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$myS" "$C" 
> "$D"
>  done
>  
> 
> With this diff.,
> 
> andrea@andrea:~$ ./Documentation/features/list-arch.sh riscv > /tmp/riscv.txt
> grep: asm/rwsem.h: No such file or directory
> andrea@andrea:~$ cat /tmp/riscv.txt
> #
> # Kernel feature support matrix of the 'riscv' architecture:
> #
>   core/ BPF-JIT  : VS.  -- |
> HAVE_BPF_JIT #  arch supports BPF JIT optimizations
>   core/ generic-idle-thread  : VS.  ok | 
> GENERIC_SMP_IDLE_THREAD #  arch makes use of the generic SMP idle thread 
> facility
>   core/ jump-labels  : VS.  -- |
> HAVE_ARCH_JUMP_LABEL #  arch supports live patched, high efficiency branches
>   core/ tracehook: VS.  ok | 
> HAVE_ARCH_TRACEHOOK #  arch supports tracehook (ptrace) register handling APIs
>  debug/ gcov-profile-all : VS.  -- |   
> ARCH_HAS_GCOV_PROFILE_ALL #  arch supports whole-kernel GCOV code coverage 
> profiling
>  debug/ KASAN: VS.  -- | 
> HAVE_ARCH_KASAN #  arch supports the KASAN runtime memory checker
>  debug/ kgdb : VS.  -- |  
> HAVE_ARCH_KGDB #  arch supports the kGDB kernel debugger
>  debug/ kprobes  : VS.  ok |
> HAVE_KPROBES #  arch supports live patched kernel probe
>  debug/ kprobes-on-ftrace: VS.  -- |  
> HAVE_KPROBES_ON_FTRACE #  arch supports combined kprobes and ftrace live 
> patching
>  debug/ kretprobes   : VS.  -- | 
> HAVE_KRETPROBES #  arch supports kernel function-return probes
>  debug/ optprobes: VS.  -- |  
> HAVE_OPTPROBES #  arch supports live patched optprobes
>  debug/ stackprotector   : VS.  -- |  
> HAVE_CC_STACKPROTECTOR #  arch supports compiler driven stack overflow 
> protection
>  debug/ uprobes  : VS.  -- |   
> ARCH_SUPPORTS_UPROBES #  arch supports live patched user probes
>  debug/ user-ret-profiler: VS.  -- |   
> HAVE_USER_RETURN_NOTIFIER #  arch supports user-space return from system call 
> profiler
> io/ dma-api-debug: VS.  ok |  
> HAVE_DMA_API_DEBUG #  arch supports DMA debug facilities
> io/ dma-contiguous   : VS.  ok | 
> HAVE_DMA_CONTIGUOUS #  arch supports the DMA CMA (continuous memory allocator)
> io/ sg-chain : VS.  -- |   
> ARCH_HAS_SG_CHAIN #  arch supports chained scatter-gather lists
>lib/ strncasecmp  : VS.  -- | 
> __HAVE_ARCH_STRNCASECMP #  arch provides an optimized strncasecmp() function
>locking/ cmpxchg-local: VS.  -- |  
> HAVE_CMPXCHG_LOCAL #  arch supports the this_cpu_cmpxchg() API
>locking/ lockdep  : VS.  -- | 
> LOCKDEP_SUPPORT #  arch supports the runtime locking correctness debug 
> facility
>locking/ queued-rwlocks   : VS.  -- | 
> 

[PATCH] hid: intel-ish-hid: use put_device() instead of kfree()

[Arvind Yadav]

Never directly free @dev after calling device_register(), even
if it returned an error. Always use put_device() to give up the
reference initialized.

Signed-off-by: Arvind Yadav 
---
 drivers/hid/intel-ish-hid/ishtp/bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c 
b/drivers/hid/intel-ish-hid/ishtp/bus.c
index f272cdd..2623a56 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -418,7 +418,7 @@ static struct ishtp_cl_device *ishtp_bus_add_device(struct 
ishtp_device *dev,
list_del(>device_link);
spin_unlock_irqrestore(>device_list_lock, flags);
dev_err(dev->devc, "Failed to register ISHTP client device\n");
-   kfree(device);
+   put_device(>dev);
return NULL;
}
 
-- 
2.7.4

[PATCH] hid: intel-ish-hid: use put_device() instead of kfree()

[Arvind Yadav]

Never directly free @dev after calling device_register(), even
if it returned an error. Always use put_device() to give up the
reference initialized.

Signed-off-by: Arvind Yadav 
---
 drivers/hid/intel-ish-hid/ishtp/bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c 
b/drivers/hid/intel-ish-hid/ishtp/bus.c
index f272cdd..2623a56 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -418,7 +418,7 @@ static struct ishtp_cl_device *ishtp_bus_add_device(struct 
ishtp_device *dev,
list_del(>device_link);
spin_unlock_irqrestore(>device_list_lock, flags);
dev_err(dev->devc, "Failed to register ISHTP client device\n");
-   kfree(device);
+   put_device(>dev);
return NULL;
}
 
-- 
2.7.4

[PATCH] uts_namespace: Move boot_id in uts namespace

[Angel Shtilianov]

Currently the same boot_id is reported for all containers running
on a host node, including the host node itself. Even after restarting
a container it will still have the same persistent boot_id.

This can cause troubles in cases where you have multiple containers
from the same cluster on one host node. The software inside each
container will get the same boot_id and thus fail to join the cluster,
after the first container from the node has already joined.

UTS namespace on other hand keeps the machine specific data, so it
seems to be the correct place to move the boot_id and instantiate it,
so each container will have unique id for its own boot lifetime, if
it has its own uts namespace.

Signed-off-by: Angel Shtilianov 
---
 drivers/char/random.c   | 4 
 include/linux/utsname.h | 1 +
 kernel/utsname.c| 4 +++-
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index ec42c8bb9b0d..e05daf7f38f4 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1960,6 +1960,10 @@ static int proc_do_uuid(struct ctl_table *table, int 
write,
unsigned char buf[64], tmp_uuid[16], *uuid;
 
uuid = table->data;
+#ifdef CONFIG_UTS_NS
+   if (!!uuid && (uuid == (unsigned char *)sysctl_bootid))
+   uuid = current->nsproxy->uts_ns->sysctl_bootid;
+#endif
if (!uuid) {
uuid = tmp_uuid;
generate_random_uuid(uuid);
diff --git a/include/linux/utsname.h b/include/linux/utsname.h
index c8060c2ecd04..f704aca3e95a 100644
--- a/include/linux/utsname.h
+++ b/include/linux/utsname.h
@@ -27,6 +27,7 @@ struct uts_namespace {
struct user_namespace *user_ns;
struct ucounts *ucounts;
struct ns_common ns;
+   char sysctl_bootid[16];
 } __randomize_layout;
 extern struct uts_namespace init_uts_ns;
 
diff --git a/kernel/utsname.c b/kernel/utsname.c
index 913fe4336d2b..f1749cdcd341 100644
--- a/kernel/utsname.c
+++ b/kernel/utsname.c
@@ -34,8 +34,10 @@ static struct uts_namespace *create_uts_ns(void)
struct uts_namespace *uts_ns;
 
uts_ns = kmalloc(sizeof(struct uts_namespace), GFP_KERNEL);
-   if (uts_ns)
+   if (uts_ns) {
kref_init(_ns->kref);
+   memset(uts_ns->sysctl_bootid, 0, 16);
+   }
return uts_ns;
 }
 
-- 
2.5.0

[PATCH] uts_namespace: Move boot_id in uts namespace

[Angel Shtilianov]

Currently the same boot_id is reported for all containers running
on a host node, including the host node itself. Even after restarting
a container it will still have the same persistent boot_id.

This can cause troubles in cases where you have multiple containers
from the same cluster on one host node. The software inside each
container will get the same boot_id and thus fail to join the cluster,
after the first container from the node has already joined.

UTS namespace on other hand keeps the machine specific data, so it
seems to be the correct place to move the boot_id and instantiate it,
so each container will have unique id for its own boot lifetime, if
it has its own uts namespace.

Signed-off-by: Angel Shtilianov 
---
 drivers/char/random.c   | 4 
 include/linux/utsname.h | 1 +
 kernel/utsname.c| 4 +++-
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index ec42c8bb9b0d..e05daf7f38f4 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1960,6 +1960,10 @@ static int proc_do_uuid(struct ctl_table *table, int 
write,
unsigned char buf[64], tmp_uuid[16], *uuid;
 
uuid = table->data;
+#ifdef CONFIG_UTS_NS
+   if (!!uuid && (uuid == (unsigned char *)sysctl_bootid))
+   uuid = current->nsproxy->uts_ns->sysctl_bootid;
+#endif
if (!uuid) {
uuid = tmp_uuid;
generate_random_uuid(uuid);
diff --git a/include/linux/utsname.h b/include/linux/utsname.h
index c8060c2ecd04..f704aca3e95a 100644
--- a/include/linux/utsname.h
+++ b/include/linux/utsname.h
@@ -27,6 +27,7 @@ struct uts_namespace {
struct user_namespace *user_ns;
struct ucounts *ucounts;
struct ns_common ns;
+   char sysctl_bootid[16];
 } __randomize_layout;
 extern struct uts_namespace init_uts_ns;
 
diff --git a/kernel/utsname.c b/kernel/utsname.c
index 913fe4336d2b..f1749cdcd341 100644
--- a/kernel/utsname.c
+++ b/kernel/utsname.c
@@ -34,8 +34,10 @@ static struct uts_namespace *create_uts_ns(void)
struct uts_namespace *uts_ns;
 
uts_ns = kmalloc(sizeof(struct uts_namespace), GFP_KERNEL);
-   if (uts_ns)
+   if (uts_ns) {
kref_init(_ns->kref);
+   memset(uts_ns->sysctl_bootid, 0, 16);
+   }
return uts_ns;
 }
 
-- 
2.5.0

Re: [PATCH v3 3/8] efi: Decode IA32/X64 Processor Error Info Structure

[Ard Biesheuvel]

On 29 March 2018 at 14:53, Ghannam, Yazen  wrote:
>> -Original Message-
>> From: Borislav Petkov 
>> Sent: Thursday, March 29, 2018 6:55 AM
>> To: Ghannam, Yazen 
>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> ard.biesheu...@linaro.org; x...@kernel.org; tony.l...@intel.com
>> Subject: Re: [PATCH v3 3/8] efi: Decode IA32/X64 Processor Error Info
>> Structure
>>
>> On Sat, Mar 24, 2018 at 01:49:35PM -0500, Yazen Ghannam wrote:
>> > From: Yazen Ghannam 
>> >
>> > Print the fields in the IA32/X64 Processor Error Info Structure.
>> >
>> > Based on UEFI 2.7 Table 253. IA32/X64 Processor Error Information
>> > Structure.
>> >
>> > Signed-off-by: Yazen Ghannam 
>> > ---
>> > Link:
>> > https://lkml.kernel.org/r/20180226193904.20532-4-
>> yazen.ghan...@amd.com
>> >
>> > v2->v3:
>> > * Fix table number in commit message.
>> > * Don't print raw validation bits.
>> >
>> > v1->v2:
>> > * Add parantheses around "bits" expression in macro.
>> > * Fix indentation on multi-line statements.
>> >
>> >  drivers/firmware/efi/cper-x86.c | 50
>> +
>> >  1 file changed, 50 insertions(+)
>> >
>> > diff --git a/drivers/firmware/efi/cper-x86.c b/drivers/firmware/efi/cper-
>> x86.c
>> > index 863f0cd2a0ff..a9ab3bbf7986 100644
>> > --- a/drivers/firmware/efi/cper-x86.c
>> > +++ b/drivers/firmware/efi/cper-x86.c
>> > @@ -3,15 +3,28 @@
>> >
>> >  #include 
>> >
>> > +#define INDENT_SP  " "
>>
>> There's that thing again. So it was a total waste of time discussing
>> this last time. So let me save my time this time:
>>
>> NAKed-by: Borislav Petkov 
>>
>
> IIRC, the arguments for keeping this are
> 1) convention for CPER
> 2) code readability
>
> The argument against was
> 1) it's dumb
>
> So I decided to keep it. I don't really mind either way so I'll change it
> if there's a second opinion.
>

Yes, please change it.

Re: [PATCH v3 3/8] efi: Decode IA32/X64 Processor Error Info Structure

[Ard Biesheuvel]

On 29 March 2018 at 14:53, Ghannam, Yazen  wrote:
>> -Original Message-
>> From: Borislav Petkov 
>> Sent: Thursday, March 29, 2018 6:55 AM
>> To: Ghannam, Yazen 
>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> ard.biesheu...@linaro.org; x...@kernel.org; tony.l...@intel.com
>> Subject: Re: [PATCH v3 3/8] efi: Decode IA32/X64 Processor Error Info
>> Structure
>>
>> On Sat, Mar 24, 2018 at 01:49:35PM -0500, Yazen Ghannam wrote:
>> > From: Yazen Ghannam 
>> >
>> > Print the fields in the IA32/X64 Processor Error Info Structure.
>> >
>> > Based on UEFI 2.7 Table 253. IA32/X64 Processor Error Information
>> > Structure.
>> >
>> > Signed-off-by: Yazen Ghannam 
>> > ---
>> > Link:
>> > https://lkml.kernel.org/r/20180226193904.20532-4-
>> yazen.ghan...@amd.com
>> >
>> > v2->v3:
>> > * Fix table number in commit message.
>> > * Don't print raw validation bits.
>> >
>> > v1->v2:
>> > * Add parantheses around "bits" expression in macro.
>> > * Fix indentation on multi-line statements.
>> >
>> >  drivers/firmware/efi/cper-x86.c | 50
>> +
>> >  1 file changed, 50 insertions(+)
>> >
>> > diff --git a/drivers/firmware/efi/cper-x86.c b/drivers/firmware/efi/cper-
>> x86.c
>> > index 863f0cd2a0ff..a9ab3bbf7986 100644
>> > --- a/drivers/firmware/efi/cper-x86.c
>> > +++ b/drivers/firmware/efi/cper-x86.c
>> > @@ -3,15 +3,28 @@
>> >
>> >  #include 
>> >
>> > +#define INDENT_SP  " "
>>
>> There's that thing again. So it was a total waste of time discussing
>> this last time. So let me save my time this time:
>>
>> NAKed-by: Borislav Petkov 
>>
>
> IIRC, the arguments for keeping this are
> 1) convention for CPER
> 2) code readability
>
> The argument against was
> 1) it's dumb
>
> So I decided to keep it. I don't really mind either way so I'll change it
> if there's a second opinion.
>

Yes, please change it.

Re: [PATCH v4 2/2] locking/debug: Restructure the lock debugging menu

[Ingo Molnar]

* Waiman Long  wrote:

> Two config options in the lock debugging menu that are probably the most
> frequently used, as far as I am concerned, is the PROVE_LOCKING and
> LOCK_STAT. From a UI perspective, they should be front and center. So
> these two options are now moved to the top of the lock debugging menu.
> 
> The DEBUG_WW_MUTEX_SLOWPATH option is also added to the PROVE_LOCKING
> umbrella.
> 
> Signed-off-by: Waiman Long 
> ---
>  lib/Kconfig.debug | 146 
> --
>  1 file changed, 76 insertions(+), 70 deletions(-)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 6aad28c..dc9ffe2 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1034,6 +1034,79 @@ config DEBUG_PREEMPT
>  
>  menu "Lock Debugging (spinlocks, mutexes, etc...)"
>  
> +config LOCK_DEBUGGING_SUPPORT
> + bool
> + depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && 
> LOCKDEP_SUPPORT
> + default y

Ok, this patch is a nice reorganization - but could we please split this into 
two 
patches, the first one adds the LOCK_DEBUGGING_SUPPORT helper, the other does 
the 
reordering of the entries (without changing anything in the entries)?

It's hard to review when the two steps are mixed up.

Thanks,

Ingo

Re: [PATCH v4 2/2] locking/debug: Restructure the lock debugging menu

[Ingo Molnar]

* Waiman Long  wrote:

> Two config options in the lock debugging menu that are probably the most
> frequently used, as far as I am concerned, is the PROVE_LOCKING and
> LOCK_STAT. From a UI perspective, they should be front and center. So
> these two options are now moved to the top of the lock debugging menu.
> 
> The DEBUG_WW_MUTEX_SLOWPATH option is also added to the PROVE_LOCKING
> umbrella.
> 
> Signed-off-by: Waiman Long 
> ---
>  lib/Kconfig.debug | 146 
> --
>  1 file changed, 76 insertions(+), 70 deletions(-)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 6aad28c..dc9ffe2 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1034,6 +1034,79 @@ config DEBUG_PREEMPT
>  
>  menu "Lock Debugging (spinlocks, mutexes, etc...)"
>  
> +config LOCK_DEBUGGING_SUPPORT
> + bool
> + depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && 
> LOCKDEP_SUPPORT
> + default y

Ok, this patch is a nice reorganization - but could we please split this into 
two 
patches, the first one adds the LOCK_DEBUGGING_SUPPORT helper, the other does 
the 
reordering of the entries (without changing anything in the entries)?

It's hard to review when the two steps are mixed up.

Thanks,

Ingo

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

[Ilya Smith]

> On 30 Mar 2018, at 12:57, Pavel Machek  wrote:
> 
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>> 
>>> On 30 Mar 2018, at 10:55, Pavel Machek  wrote:
>>> 
>>> Hi!
>>> 
 Current implementation doesn't randomize address returned by mmap.
 All the entropy ends with choosing mmap_base_addr at the process
 creation. After that mmap build very predictable layout of address
 space. It allows to bypass ASLR in many cases. This patch make
 randomization of address on any mmap call.
>>> 
>>> How will this interact with people debugging their application, and
>>> getting different behaviours based on memory layout?
>>> 
>>> strace, strace again, get different results?
>>> 
>> 
>> Honestly I’m confused about your question. If the only one way for debugging 
>> application is to use predictable mmap behaviour, then something went wrong 
>> in 
>> this live and we should stop using computers at all.
> 
> I'm not saying "only way". I'm saying one way, and you are breaking
> that. There's advanced stuff like debuggers going "back in time".
> 

Correct me if I wrong, when you run gdb for instance and try to debug some 
application, gdb will disable randomization. This behaviour works with gdb 
command: set disable-randomization on. As I know, gdb remove flag PF_RANDOMIZE 
from current personality thats how it disables ASLR for debugging process. 
According to my patch, flag PF_RANDOMIZE is checked before calling 
unmapped_area_random. So I don’t breaking debugging. If you talking about the 
case, when your application crashes under customer environment and you want to
debug it; in this case layout of memory is what you don’t control at all and 
you have to understand what is where. So for debugging memory process layout is
not what you should care of.

Thanks,
Ilya

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

[Ilya Smith]

> On 30 Mar 2018, at 12:57, Pavel Machek  wrote:
> 
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>> 
>>> On 30 Mar 2018, at 10:55, Pavel Machek  wrote:
>>> 
>>> Hi!
>>> 
 Current implementation doesn't randomize address returned by mmap.
 All the entropy ends with choosing mmap_base_addr at the process
 creation. After that mmap build very predictable layout of address
 space. It allows to bypass ASLR in many cases. This patch make
 randomization of address on any mmap call.
>>> 
>>> How will this interact with people debugging their application, and
>>> getting different behaviours based on memory layout?
>>> 
>>> strace, strace again, get different results?
>>> 
>> 
>> Honestly I’m confused about your question. If the only one way for debugging 
>> application is to use predictable mmap behaviour, then something went wrong 
>> in 
>> this live and we should stop using computers at all.
> 
> I'm not saying "only way". I'm saying one way, and you are breaking
> that. There's advanced stuff like debuggers going "back in time".
> 

Correct me if I wrong, when you run gdb for instance and try to debug some 
application, gdb will disable randomization. This behaviour works with gdb 
command: set disable-randomization on. As I know, gdb remove flag PF_RANDOMIZE 
from current personality thats how it disables ASLR for debugging process. 
According to my patch, flag PF_RANDOMIZE is checked before calling 
unmapped_area_random. So I don’t breaking debugging. If you talking about the 
case, when your application crashes under customer environment and you want to
debug it; in this case layout of memory is what you don’t control at all and 
you have to understand what is where. So for debugging memory process layout is
not what you should care of.

Thanks,
Ilya

Re: [PATCH 3/3] iio: adc: meson-axg: add saradc driver

[Martin Blumenstingl]

On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> From: Xingyu Chen 
>
> Add the SAR ADC driver for the Amlogic Meson-AXG SoC.
>
> Signed-off-by: Xingyu Chen 
I suggest changing the subject of this patch to:
iio: adc: meson-saradc: add support for Meson AXG

(because "iio: adc: meson-axg" does not point to the "meson-saradc"
driver and no new driver is added with this patch)

with that:
Acked-by: Martin Blumenstingl 

> ---
>  drivers/iio/adc/meson_saradc.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 799ed929ab99..a5d481a2b4ef 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -935,6 +935,11 @@ static const struct meson_sar_adc_data 
> meson_sar_adc_gxm_data = {
> .name = "meson-gxm-saradc",
>  };
>
> +static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
> +   .param = _sar_adc_gxl_param,
> +   .name = "meson-axg-saradc",
> +};
> +
>  static const struct of_device_id meson_sar_adc_of_match[] = {
> {
> .compatible = "amlogic,meson8-saradc",
> @@ -953,6 +958,9 @@ static const struct of_device_id meson_sar_adc_of_match[] 
> = {
> }, {
> .compatible = "amlogic,meson-gxm-saradc",
> .data = _sar_adc_gxm_data,
> +   }, {
> +   .compatible = "amlogic,meson-axg-saradc",
> +   .data = _sar_adc_axg_data,
> },
> {},
>  };
> --
> 2.15.1
>

Re: [PATCH 3/3] iio: adc: meson-axg: add saradc driver

[Martin Blumenstingl]

On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> From: Xingyu Chen 
>
> Add the SAR ADC driver for the Amlogic Meson-AXG SoC.
>
> Signed-off-by: Xingyu Chen 
I suggest changing the subject of this patch to:
iio: adc: meson-saradc: add support for Meson AXG

(because "iio: adc: meson-axg" does not point to the "meson-saradc"
driver and no new driver is added with this patch)

with that:
Acked-by: Martin Blumenstingl 

> ---
>  drivers/iio/adc/meson_saradc.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 799ed929ab99..a5d481a2b4ef 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -935,6 +935,11 @@ static const struct meson_sar_adc_data 
> meson_sar_adc_gxm_data = {
> .name = "meson-gxm-saradc",
>  };
>
> +static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
> +   .param = _sar_adc_gxl_param,
> +   .name = "meson-axg-saradc",
> +};
> +
>  static const struct of_device_id meson_sar_adc_of_match[] = {
> {
> .compatible = "amlogic,meson8-saradc",
> @@ -953,6 +958,9 @@ static const struct of_device_id meson_sar_adc_of_match[] 
> = {
> }, {
> .compatible = "amlogic,meson-gxm-saradc",
> .data = _sar_adc_gxm_data,
> +   }, {
> +   .compatible = "amlogic,meson-axg-saradc",
> +   .data = _sar_adc_axg_data,
> },
> {},
>  };
> --
> 2.15.1
>

Re: [PATCH v3 0/8] ARM: davinci: complete the conversion to using the reset framework

[Bartosz Golaszewski]

2018-03-27 18:48 GMT+02:00 David Lechner :
> Wasn't there a v4 already? Is this really v5 instead of v3?
>

Yes there was and Philipp applied the v4 alright.

>
> On 03/27/2018 04:20 AM, Bartosz Golaszewski wrote:
>>
>> From: Bartosz Golaszewski 
>>
>> This series converts the only user of the handcoded, mach-specific reset
>> routines in the davinci platform to using the reset framework.
>>
>> Patches 1-3 add necessary lookups/DT-properties.
>
>
> Should I just squash the DT changes into my common-clock-v9 branch
> since those patches haven't been picked up yet anyway? That will be
> 2 fewer patches to keep track of.

I would personally prefer to keep the changesets thematically
separate. The clock series is big anyway already.

Thanks,
Bartosz

Re: [PATCH v3 0/8] ARM: davinci: complete the conversion to using the reset framework

[Bartosz Golaszewski]

2018-03-27 18:48 GMT+02:00 David Lechner :
> Wasn't there a v4 already? Is this really v5 instead of v3?
>

Yes there was and Philipp applied the v4 alright.

>
> On 03/27/2018 04:20 AM, Bartosz Golaszewski wrote:
>>
>> From: Bartosz Golaszewski 
>>
>> This series converts the only user of the handcoded, mach-specific reset
>> routines in the davinci platform to using the reset framework.
>>
>> Patches 1-3 add necessary lookups/DT-properties.
>
>
> Should I just squash the DT changes into my common-clock-v9 branch
> since those patches haven't been picked up yet anyway? That will be
> 2 fewer patches to keep track of.

I would personally prefer to keep the changesets thematically
separate. The clock series is big anyway already.

Thanks,
Bartosz

Re: [PATCH 1/3] iio: adc: meson-saradc: squash and share the common adc platform data

[Martin Blumenstingl]

On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> Extract and promote common adc platform data into a new structure,
> to make it better share the info between several SoCs,
> this will avoid duplicating the code all over the place,
> Save a few memory and make the code more maintainable.
>
> Signed-off-by: Yixun Lan 
Acked-by: Martin Blumenstingl 

this will also help me when I add support for the internal temperature
sensor (as Meson8b and Meson8m2 share the same settings, except the
name)

> ---
>  drivers/iio/adc/meson_saradc.c | 75 
> +++---
>  1 file changed, 42 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 29fa7736d80c..799ed929ab99 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -219,15 +219,19 @@ enum meson_sar_adc_chan7_mux_sel {
> CHAN7_MUX_CH7_INPUT = 0x7,
>  };
>
> -struct meson_sar_adc_data {
> +struct meson_sar_adc_param {
> boolhas_bl30_integration;
> unsigned long   clock_rate;
> u32 bandgap_reg;
> unsigned intresolution;
> -   const char  *name;
> const struct regmap_config  *regmap_config;
>  };
>
> +struct meson_sar_adc_data {
> +   const struct meson_sar_adc_param*param;
> +   const char  *name;
> +};
> +
>  struct meson_sar_adc_priv {
> struct regmap   *regmap;
> struct regulator*vref;
> @@ -276,7 +280,7 @@ static int meson_sar_adc_calib_val(struct iio_dev 
> *indio_dev, int val)
> /* use val_calib = scale * val_raw + offset calibration function */
> tmp = div_s64((s64)val * priv->calibscale, MILLION) + priv->calibbias;
>
> -   return clamp(tmp, 0, (1 << priv->data->resolution) - 1);
> +   return clamp(tmp, 0, (1 << priv->data->param->resolution) - 1);
>  }
>
>  static int meson_sar_adc_wait_busy_clear(struct iio_dev *indio_dev)
> @@ -328,7 +332,7 @@ static int meson_sar_adc_read_raw_sample(struct iio_dev 
> *indio_dev,
> }
>
> fifo_val = FIELD_GET(MESON_SAR_ADC_FIFO_RD_SAMPLE_VALUE_MASK, regval);
> -   fifo_val &= GENMASK(priv->data->resolution - 1, 0);
> +   fifo_val &= GENMASK(priv->data->param->resolution - 1, 0);
> *val = meson_sar_adc_calib_val(indio_dev, fifo_val);
>
> return 0;
> @@ -447,7 +451,7 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>
> mutex_lock(_dev->mlock);
>
> -   if (priv->data->has_bl30_integration) {
> +   if (priv->data->param->has_bl30_integration) {
> /* prevent BL30 from using the SAR ADC while we are using it 
> */
> regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> @@ -473,7 +477,7 @@ static void meson_sar_adc_unlock(struct iio_dev 
> *indio_dev)
>  {
> struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>
> -   if (priv->data->has_bl30_integration)
> +   if (priv->data->param->has_bl30_integration)
> /* allow BL30 to use the SAR ADC again */
> regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> @@ -557,7 +561,7 @@ static int meson_sar_adc_iio_info_read_raw(struct iio_dev 
> *indio_dev,
> }
>
> *val = ret / 1000;
> -   *val2 = priv->data->resolution;
> +   *val2 = priv->data->param->resolution;
> return IIO_VAL_FRACTIONAL_LOG2;
>
> case IIO_CHAN_INFO_CALIBBIAS:
> @@ -630,7 +634,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  */
> meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>
> -   if (priv->data->has_bl30_integration) {
> +   if (priv->data->param->has_bl30_integration) {
> /*
>  * leave sampling delay and the input clocks as configured by
>  * BL30 to make sure BL30 gets the values it expects when
> @@ -710,7 +714,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
> return ret;
> }
>
> -   ret = clk_set_rate(priv->adc_clk, priv->data->clock_rate);
> +   ret = clk_set_rate(priv->adc_clk, priv->data->param->clock_rate);
> if (ret) {
> dev_err(indio_dev->dev.parent,
> "failed to set adc clock rate\n");
> @@ -723,14 +727,15 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  static void meson_sar_adc_set_bandgap(struct iio_dev *indio_dev, bool on_off)
>  {
> struct meson_sar_adc_priv *priv = 

Re: [PATCH 1/3] iio: adc: meson-saradc: squash and share the common adc platform data

[Martin Blumenstingl]

On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> Extract and promote common adc platform data into a new structure,
> to make it better share the info between several SoCs,
> this will avoid duplicating the code all over the place,
> Save a few memory and make the code more maintainable.
>
> Signed-off-by: Yixun Lan 
Acked-by: Martin Blumenstingl 

this will also help me when I add support for the internal temperature
sensor (as Meson8b and Meson8m2 share the same settings, except the
name)

> ---
>  drivers/iio/adc/meson_saradc.c | 75 
> +++---
>  1 file changed, 42 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 29fa7736d80c..799ed929ab99 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -219,15 +219,19 @@ enum meson_sar_adc_chan7_mux_sel {
> CHAN7_MUX_CH7_INPUT = 0x7,
>  };
>
> -struct meson_sar_adc_data {
> +struct meson_sar_adc_param {
> boolhas_bl30_integration;
> unsigned long   clock_rate;
> u32 bandgap_reg;
> unsigned intresolution;
> -   const char  *name;
> const struct regmap_config  *regmap_config;
>  };
>
> +struct meson_sar_adc_data {
> +   const struct meson_sar_adc_param*param;
> +   const char  *name;
> +};
> +
>  struct meson_sar_adc_priv {
> struct regmap   *regmap;
> struct regulator*vref;
> @@ -276,7 +280,7 @@ static int meson_sar_adc_calib_val(struct iio_dev 
> *indio_dev, int val)
> /* use val_calib = scale * val_raw + offset calibration function */
> tmp = div_s64((s64)val * priv->calibscale, MILLION) + priv->calibbias;
>
> -   return clamp(tmp, 0, (1 << priv->data->resolution) - 1);
> +   return clamp(tmp, 0, (1 << priv->data->param->resolution) - 1);
>  }
>
>  static int meson_sar_adc_wait_busy_clear(struct iio_dev *indio_dev)
> @@ -328,7 +332,7 @@ static int meson_sar_adc_read_raw_sample(struct iio_dev 
> *indio_dev,
> }
>
> fifo_val = FIELD_GET(MESON_SAR_ADC_FIFO_RD_SAMPLE_VALUE_MASK, regval);
> -   fifo_val &= GENMASK(priv->data->resolution - 1, 0);
> +   fifo_val &= GENMASK(priv->data->param->resolution - 1, 0);
> *val = meson_sar_adc_calib_val(indio_dev, fifo_val);
>
> return 0;
> @@ -447,7 +451,7 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>
> mutex_lock(_dev->mlock);
>
> -   if (priv->data->has_bl30_integration) {
> +   if (priv->data->param->has_bl30_integration) {
> /* prevent BL30 from using the SAR ADC while we are using it 
> */
> regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> @@ -473,7 +477,7 @@ static void meson_sar_adc_unlock(struct iio_dev 
> *indio_dev)
>  {
> struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>
> -   if (priv->data->has_bl30_integration)
> +   if (priv->data->param->has_bl30_integration)
> /* allow BL30 to use the SAR ADC again */
> regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> @@ -557,7 +561,7 @@ static int meson_sar_adc_iio_info_read_raw(struct iio_dev 
> *indio_dev,
> }
>
> *val = ret / 1000;
> -   *val2 = priv->data->resolution;
> +   *val2 = priv->data->param->resolution;
> return IIO_VAL_FRACTIONAL_LOG2;
>
> case IIO_CHAN_INFO_CALIBBIAS:
> @@ -630,7 +634,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  */
> meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>
> -   if (priv->data->has_bl30_integration) {
> +   if (priv->data->param->has_bl30_integration) {
> /*
>  * leave sampling delay and the input clocks as configured by
>  * BL30 to make sure BL30 gets the values it expects when
> @@ -710,7 +714,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
> return ret;
> }
>
> -   ret = clk_set_rate(priv->adc_clk, priv->data->clock_rate);
> +   ret = clk_set_rate(priv->adc_clk, priv->data->param->clock_rate);
> if (ret) {
> dev_err(indio_dev->dev.parent,
> "failed to set adc clock rate\n");
> @@ -723,14 +727,15 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  static void meson_sar_adc_set_bandgap(struct iio_dev *indio_dev, bool on_off)
>  {
> struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
> +   const struct meson_sar_adc_param *param = 

Re: [PATCH 2/3] dt-bindings: iio: adc: document the Meson AXG support

[Martin Blumenstingl]

On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> From: Xingyu Chen 
>
> Update the documentation to expicitly support the Meson-AXG SoC.
>
> Signed-off-by: Xingyu Chen 
Acked-by: Martin Blumenstingl 

> ---
>  Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git 
> a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt 
> b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> index 1e6ee3deb4fa..d1acd5ea2737 100644
> --- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> @@ -7,6 +7,7 @@ Required properties:
> - "amlogic,meson-gxbb-saradc" for GXBB
> - "amlogic,meson-gxl-saradc" for GXL
> - "amlogic,meson-gxm-saradc" for GXM
> +   - "amlogic,meson-axg-saradc" for AXG
> along with the generic "amlogic,meson-saradc"
>  - reg: the physical base address and length of the registers
>  - interrupts:  the interrupt indicating end of sampling
> --
> 2.15.1
>

Re: [PATCH 2/3] dt-bindings: iio: adc: document the Meson AXG support

[Martin Blumenstingl]

On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> From: Xingyu Chen 
>
> Update the documentation to expicitly support the Meson-AXG SoC.
>
> Signed-off-by: Xingyu Chen 
Acked-by: Martin Blumenstingl 

> ---
>  Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git 
> a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt 
> b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> index 1e6ee3deb4fa..d1acd5ea2737 100644
> --- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> @@ -7,6 +7,7 @@ Required properties:
> - "amlogic,meson-gxbb-saradc" for GXBB
> - "amlogic,meson-gxl-saradc" for GXL
> - "amlogic,meson-gxm-saradc" for GXM
> +   - "amlogic,meson-axg-saradc" for AXG
> along with the generic "amlogic,meson-saradc"
>  - reg: the physical base address and length of the registers
>  - interrupts:  the interrupt indicating end of sampling
> --
> 2.15.1
>

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Ingo Molnar]

* Dominik Brodowski  wrote:

> > > The whole series is available at
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > > syscalls-WIP
> > 
> > BTW., I'd like all these bits to go through the x86 tree.
> > 
> > What is the expected merge route of the generic preparatory bits?
> 
> My current plan is to push the 109 patch bomb to remove in-kernel calls to 
> syscalls
> directly to Linus once v4.16 is released.

Are there any (textual and semantic) conflicts with the latest -next?

Also, to what extent were these 109 patches tested in -next?

> For this series of seven patches, I am content with them going upstream 
> through 
> the x86 tree (once that contains a backmerge of Linus' tree or the syscalls 
> tree, obviously). IMO, these seven patches should be kept together, and not 
> routed upstream through different channels.

Of course they should stay together - the generic code impact is minimal, these 
are 95% x86.

Thanks,

Ingo

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Ingo Molnar]

* Dominik Brodowski  wrote:

> > > The whole series is available at
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > > syscalls-WIP
> > 
> > BTW., I'd like all these bits to go through the x86 tree.
> > 
> > What is the expected merge route of the generic preparatory bits?
> 
> My current plan is to push the 109 patch bomb to remove in-kernel calls to 
> syscalls
> directly to Linus once v4.16 is released.

Are there any (textual and semantic) conflicts with the latest -next?

Also, to what extent were these 109 patches tested in -next?

> For this series of seven patches, I am content with them going upstream 
> through 
> the x86 tree (once that contains a backmerge of Linus' tree or the syscalls 
> tree, obviously). IMO, these seven patches should be kept together, and not 
> routed upstream through different channels.

Of course they should stay together - the generic code impact is minimal, these 
are 95% x86.

Thanks,

Ingo

Re: [PATCH] ARM: dts: da850-evm: Enable usb_phy, usb0 and usb1

[Sekhar Nori]

On Monday 19 March 2018 09:51 PM, Adam Ford wrote:
> The EVM kit has two USB ports.  This patch will enable both
> when booting with device tree.
> 
> Signed-off-by: Adam Ford 

Applied for v4.18

Thanks,
Sekhar

Re: [PATCH] ARM: dts: da850-evm: Enable usb_phy, usb0 and usb1

[Sekhar Nori]

On Monday 19 March 2018 09:51 PM, Adam Ford wrote:
> The EVM kit has two USB ports.  This patch will enable both
> when booting with device tree.
> 
> Signed-off-by: Adam Ford 

Applied for v4.18

Thanks,
Sekhar

Re: [PATCH v2] PM / wakeup: use seq_open() to show wakeup stats

[Geert Uytterhoeven]

On Fri, Mar 30, 2018 at 12:25 PM, Rafael J. Wysocki  wrote:
> On Monday, March 5, 2018 9:47:46 AM CEST Ganesh Mahendran wrote:
>> single_open() interface requires that the whole output must
>> fit into a single buffer. This will lead to timeout when
>> system memory is not in a good situation.
>>
>> This patch use seq_open() to show wakeup stats. This method
>> need only one page, so timeout will not be observed.
>>
>> Signed-off-by: Ganesh Mahendran 
>> 
>> v2: use srcu_read_lock instead of rcu_read_lock
>> ---
>>  drivers/base/power/wakeup.c | 77 
>> +++--
>>  1 file changed, 61 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
>> index ea01621..3bcab7d 100644
>> --- a/drivers/base/power/wakeup.c
>> +++ b/drivers/base/power/wakeup.c
>> @@ -1029,32 +1029,77 @@ static int print_wakeup_source_stats(struct seq_file 
>> *m,
>>   return 0;
>>  }
>>
>> -/**
>> - * wakeup_sources_stats_show - Print wakeup sources statistics information.
>> - * @m: seq_file to print the statistics into.
>> - */
>> -static int wakeup_sources_stats_show(struct seq_file *m, void *unused)
>> +static void *wakeup_sources_stats_seq_start(struct seq_file *m,
>> + loff_t *pos)
>>  {
>>   struct wakeup_source *ws;
>> - int srcuidx;
>> + loff_t n = *pos;
>> + int *srcuidx = m->private;
>>
>> - seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
>> - "expire_count\tactive_since\ttotal_time\tmax_time\t"
>> - "last_change\tprevent_suspend_time\n");
>> + if (n == 0) {
>> + seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
>> + "expire_count\tactive_since\ttotal_time\tmax_time\t"
>> + "last_change\tprevent_suspend_time\n");
>> + }
>>
>> - srcuidx = srcu_read_lock(_srcu);
>> - list_for_each_entry_rcu(ws, _sources, entry)
>> - print_wakeup_source_stats(m, ws);
>> - srcu_read_unlock(_srcu, srcuidx);
>> + *srcuidx = srcu_read_lock(_srcu);
>> + list_for_each_entry_rcu(ws, _sources, entry) {
>> + if (n-- > 0)
>> + continue;
>> + goto out;
>> + }
>> + ws = NULL;
>> +out:
>> + return ws;
>> +}
>
> Please clean up the above at least.
>
> If I'm not mistaken, you don't need the label and the goto here.

The continue is also not needed, if the test condition is inverted.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2] PM / wakeup: use seq_open() to show wakeup stats

[Geert Uytterhoeven]

On Fri, Mar 30, 2018 at 12:25 PM, Rafael J. Wysocki  wrote:
> On Monday, March 5, 2018 9:47:46 AM CEST Ganesh Mahendran wrote:
>> single_open() interface requires that the whole output must
>> fit into a single buffer. This will lead to timeout when
>> system memory is not in a good situation.
>>
>> This patch use seq_open() to show wakeup stats. This method
>> need only one page, so timeout will not be observed.
>>
>> Signed-off-by: Ganesh Mahendran 
>> 
>> v2: use srcu_read_lock instead of rcu_read_lock
>> ---
>>  drivers/base/power/wakeup.c | 77 
>> +++--
>>  1 file changed, 61 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
>> index ea01621..3bcab7d 100644
>> --- a/drivers/base/power/wakeup.c
>> +++ b/drivers/base/power/wakeup.c
>> @@ -1029,32 +1029,77 @@ static int print_wakeup_source_stats(struct seq_file 
>> *m,
>>   return 0;
>>  }
>>
>> -/**
>> - * wakeup_sources_stats_show - Print wakeup sources statistics information.
>> - * @m: seq_file to print the statistics into.
>> - */
>> -static int wakeup_sources_stats_show(struct seq_file *m, void *unused)
>> +static void *wakeup_sources_stats_seq_start(struct seq_file *m,
>> + loff_t *pos)
>>  {
>>   struct wakeup_source *ws;
>> - int srcuidx;
>> + loff_t n = *pos;
>> + int *srcuidx = m->private;
>>
>> - seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
>> - "expire_count\tactive_since\ttotal_time\tmax_time\t"
>> - "last_change\tprevent_suspend_time\n");
>> + if (n == 0) {
>> + seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
>> + "expire_count\tactive_since\ttotal_time\tmax_time\t"
>> + "last_change\tprevent_suspend_time\n");
>> + }
>>
>> - srcuidx = srcu_read_lock(_srcu);
>> - list_for_each_entry_rcu(ws, _sources, entry)
>> - print_wakeup_source_stats(m, ws);
>> - srcu_read_unlock(_srcu, srcuidx);
>> + *srcuidx = srcu_read_lock(_srcu);
>> + list_for_each_entry_rcu(ws, _sources, entry) {
>> + if (n-- > 0)
>> + continue;
>> + goto out;
>> + }
>> + ws = NULL;
>> +out:
>> + return ws;
>> +}
>
> Please clean up the above at least.
>
> If I'm not mistaken, you don't need the label and the goto here.

The continue is also not needed, if the test condition is inverted.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

RE: IT Help-Desk Support

[Cicerchi, David M]

Employee/Staff Urgency.



This is to Notify all Employee/Staff, there would be an Important Update 
SecureTide® BARACUDA 2018 Anti-Spam filter for all Outlook Webmail users. this 
is to Secure our Inboxes from Spam & Malware Worldwide. to activate, Kindly 
click on Encrypt 
Email. You are 
advised to Logout and Re-login into your mailbox to complete Update.



Note: Update last 24Hours of receiving this message. Failure to complete 
update, your Outlook Web Account would be deactivated and shut down.



Regards,

IT Help-Desk Support

RE: IT Help-Desk Support

[Cicerchi, David M]

Employee/Staff Urgency.



This is to Notify all Employee/Staff, there would be an Important Update 
SecureTide® BARACUDA 2018 Anti-Spam filter for all Outlook Webmail users. this 
is to Secure our Inboxes from Spam & Malware Worldwide. to activate, Kindly 
click on Encrypt 
Email. You are 
advised to Logout and Re-login into your mailbox to complete Update.



Note: Update last 24Hours of receiving this message. Failure to complete 
update, your Outlook Web Account would be deactivated and shut down.



Regards,

IT Help-Desk Support

Re: [RFC] new SYSCALL_DEFINE/COMPAT_SYSCALL_DEFINE wrappers

[Ingo Molnar]

* John Paul Adrian Glaubitz  wrote:

> On 03/27/2018 12:40 PM, Linus Torvalds wrote:
> > On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz
> >  wrote:
> >>
> >> What about a tarball with a minimal Debian x32 chroot? Then you can
> >> install interesting packages you would like to test yourself.
> > 
> > That probably works fine.
> 
> I just created a fresh Debian x32 unstable chroot using this command:
> 
> $ debootstrap --no-check-gpg --variant=minbase --arch=x32 unstable 
> debian-x32-unstable http://ftp.ports.debian.org/debian-ports
> 
> It can be downloaded from my Debian webspace along checksum files for
> verification:
> 
> > https://people.debian.org/~glaubitz/chroots/
> 
> Let me know if you run into any issues.

Here's the direct download link:

  $ wget https://people.debian.org/~glaubitz/chroots/debian-x32-unstable.tar.gz

Checksum should be:

  $ sha256sum debian-x32-unstable.tar.gz
  010844bcc76bd1a3b7a20fe47f7067ed8e429a84fa60030a2868626e8fa7ec3b  
debian-x32-unstable.tar.gz

Seems to work fine here (on a distro kernel) even if I extract all the files as 
a 
non-root user and do:

  ~/s/debian-x32-unstable> fakechroot /usr/sbin/chroot . /usr/bin/dpkg -l  | 
tail -2

  ERROR: ld.so: object 'libfakechroot.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
  ii  util-linux:x32 2.31.1-0.5   x32  miscellaneous 
system utilities
  ii  zlib1g:x32 1:1.2.8.dfsg-5   x32  compression 
library - runtime

So that 'dpkg' instance appears to be running inside the chroot environment and 
is 
listing x32 installed packages.

Although I did get this warning:

  ERROR: ld.so: object 'libfakechroot.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.

Even with that warning, is still still a sufficiently complex test of x32 
syscall 
code paths?

BTW., "fakechroot /usr/sbin/chroot ." crashes instead of giving me a bash shell.

Thanks,

Ingo

Re: [RFC] new SYSCALL_DEFINE/COMPAT_SYSCALL_DEFINE wrappers

[Ingo Molnar]

* John Paul Adrian Glaubitz  wrote:

> On 03/27/2018 12:40 PM, Linus Torvalds wrote:
> > On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz
> >  wrote:
> >>
> >> What about a tarball with a minimal Debian x32 chroot? Then you can
> >> install interesting packages you would like to test yourself.
> > 
> > That probably works fine.
> 
> I just created a fresh Debian x32 unstable chroot using this command:
> 
> $ debootstrap --no-check-gpg --variant=minbase --arch=x32 unstable 
> debian-x32-unstable http://ftp.ports.debian.org/debian-ports
> 
> It can be downloaded from my Debian webspace along checksum files for
> verification:
> 
> > https://people.debian.org/~glaubitz/chroots/
> 
> Let me know if you run into any issues.

Here's the direct download link:

  $ wget https://people.debian.org/~glaubitz/chroots/debian-x32-unstable.tar.gz

Checksum should be:

  $ sha256sum debian-x32-unstable.tar.gz
  010844bcc76bd1a3b7a20fe47f7067ed8e429a84fa60030a2868626e8fa7ec3b  
debian-x32-unstable.tar.gz

Seems to work fine here (on a distro kernel) even if I extract all the files as 
a 
non-root user and do:

  ~/s/debian-x32-unstable> fakechroot /usr/sbin/chroot . /usr/bin/dpkg -l  | 
tail -2

  ERROR: ld.so: object 'libfakechroot.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
  ii  util-linux:x32 2.31.1-0.5   x32  miscellaneous 
system utilities
  ii  zlib1g:x32 1:1.2.8.dfsg-5   x32  compression 
library - runtime

So that 'dpkg' instance appears to be running inside the chroot environment and 
is 
listing x32 installed packages.

Although I did get this warning:

  ERROR: ld.so: object 'libfakechroot.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.

Even with that warning, is still still a sufficiently complex test of x32 
syscall 
code paths?

BTW., "fakechroot /usr/sbin/chroot ." crashes instead of giving me a bash shell.

Thanks,

Ingo

Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

[Sebastian Reichel]

Hi,

On Thu, Mar 29, 2018 at 09:06:11AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel  [180329 15:47]:
> > Hi,
> > 
> > On Thu, Mar 29, 2018 at 06:59:04AM -0700, Tony Lindgren wrote:
> > > > I think cpcap is always the clock and frame master, but I think
> > > > mdm6600 is the remote side and OMAP is not involved at all.
> > > 
> > > OK. So could it be just an alsamixer on/off toggle then for
> > > "Modem" or something similar?
> > 
> > I think so. We might want to have an "Mode" enum instead, though.
> > That can be extended, once we unlock the other modes (bluetooth,
> > bluetooth call).
> 
> OK. Seems in addition to the "Mode" enum, we also need
> some other switch for modem on and off toggle?

I don't think so. DAPM should automatically power on/off the
modem if there is a valid path from some CPCAP output/input.
Since the mode enum will "disconnect" the modem in the DAPM
graph, it should be enabled/disabled automatically.

> I guess most people want to save the preferred "Mode" enum,
> then for the duration of the call enable the selected mode.
> 
> And I guess the mute is already there for the mic with 'm'
> in alsamixer for conf calls :)

Yes.

-- Sebastian


signature.asc
Description: PGP signature

Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

[Sebastian Reichel]

Hi,

On Thu, Mar 29, 2018 at 09:06:11AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel  [180329 15:47]:
> > Hi,
> > 
> > On Thu, Mar 29, 2018 at 06:59:04AM -0700, Tony Lindgren wrote:
> > > > I think cpcap is always the clock and frame master, but I think
> > > > mdm6600 is the remote side and OMAP is not involved at all.
> > > 
> > > OK. So could it be just an alsamixer on/off toggle then for
> > > "Modem" or something similar?
> > 
> > I think so. We might want to have an "Mode" enum instead, though.
> > That can be extended, once we unlock the other modes (bluetooth,
> > bluetooth call).
> 
> OK. Seems in addition to the "Mode" enum, we also need
> some other switch for modem on and off toggle?

I don't think so. DAPM should automatically power on/off the
modem if there is a valid path from some CPCAP output/input.
Since the mode enum will "disconnect" the modem in the DAPM
graph, it should be enabled/disabled automatically.

> I guess most people want to save the preferred "Mode" enum,
> then for the duration of the call enable the selected mode.
> 
> And I guess the mute is already there for the mic with 'm'
> in alsamixer for conf calls :)

Yes.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] f2fs: remain written times to update inode during fsync

[Chao Yu]

Hi Jaegeuk,

On 2018/3/30 13:51, Jaegeuk Kim wrote:
> This fixes xfstests/generic/392.

Hmm... Could you please give more details about this issue and solution in
commit message, since I can catch up the solution only with the code.

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/f2fs.h  | 15 +++
>  fs/f2fs/inode.c |  4 
>  2 files changed, 19 insertions(+)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 000f93f6767e..675c39d85111 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -664,6 +664,7 @@ struct f2fs_inode_info {
>   kprojid_t i_projid; /* id for project quota */
>   int i_inline_xattr_size;/* inline xattr size */
>   struct timespec i_crtime;   /* inode creation time */
> + struct timespec i_disk_time[4]; /* inode disk times */
>  };
>  
>  static inline void get_extent_info(struct extent_info *ext,
> @@ -2457,6 +2458,11 @@ static inline void clear_file(struct inode *inode, int 
> type)
>   f2fs_mark_inode_dirty_sync(inode, true);
>  }
>  
> +static inline bool time_equal(struct timespec a, struct timespec b)
> +{
> + return (a.tv_sec == b.tv_sec) && (a.tv_nsec == b.tv_nsec);
> +}
> +
>  static inline bool f2fs_skip_inode_update(struct inode *inode, int dsync)
>  {
>   bool ret;
> @@ -2474,6 +2480,15 @@ static inline bool f2fs_skip_inode_update(struct inode 
> *inode, int dsync)
>   i_size_read(inode) & ~PAGE_MASK)
>   return false;
>  
> + if (!time_equal(F2FS_I(inode)->i_disk_time[0], inode->i_atime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[1], inode->i_ctime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[2], inode->i_mtime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[3], F2FS_I(inode)->i_crtime))
> + return false;
> +
>   down_read(_I(inode)->i_sem);
>   ret = F2FS_I(inode)->last_disk_size == i_size_read(inode);
>   up_read(_I(inode)->i_sem);
> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> index 401f09ccce7e..70aba580f4b0 100644
> --- a/fs/f2fs/inode.c
> +++ b/fs/f2fs/inode.c
> @@ -444,6 +444,10 @@ void update_inode(struct inode *inode, struct page 
> *node_page)
>   if (inode->i_nlink == 0)
>   clear_inline_node(node_page);
>  
> + F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
> + F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
> + F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
> + F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;
>  }
>  
>  void update_inode_page(struct inode *inode)
> 

Re: [PATCH] f2fs: remain written times to update inode during fsync

[Chao Yu]

Hi Jaegeuk,

On 2018/3/30 13:51, Jaegeuk Kim wrote:
> This fixes xfstests/generic/392.

Hmm... Could you please give more details about this issue and solution in
commit message, since I can catch up the solution only with the code.

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/f2fs.h  | 15 +++
>  fs/f2fs/inode.c |  4 
>  2 files changed, 19 insertions(+)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 000f93f6767e..675c39d85111 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -664,6 +664,7 @@ struct f2fs_inode_info {
>   kprojid_t i_projid; /* id for project quota */
>   int i_inline_xattr_size;/* inline xattr size */
>   struct timespec i_crtime;   /* inode creation time */
> + struct timespec i_disk_time[4]; /* inode disk times */
>  };
>  
>  static inline void get_extent_info(struct extent_info *ext,
> @@ -2457,6 +2458,11 @@ static inline void clear_file(struct inode *inode, int 
> type)
>   f2fs_mark_inode_dirty_sync(inode, true);
>  }
>  
> +static inline bool time_equal(struct timespec a, struct timespec b)
> +{
> + return (a.tv_sec == b.tv_sec) && (a.tv_nsec == b.tv_nsec);
> +}
> +
>  static inline bool f2fs_skip_inode_update(struct inode *inode, int dsync)
>  {
>   bool ret;
> @@ -2474,6 +2480,15 @@ static inline bool f2fs_skip_inode_update(struct inode 
> *inode, int dsync)
>   i_size_read(inode) & ~PAGE_MASK)
>   return false;
>  
> + if (!time_equal(F2FS_I(inode)->i_disk_time[0], inode->i_atime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[1], inode->i_ctime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[2], inode->i_mtime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[3], F2FS_I(inode)->i_crtime))
> + return false;
> +
>   down_read(_I(inode)->i_sem);
>   ret = F2FS_I(inode)->last_disk_size == i_size_read(inode);
>   up_read(_I(inode)->i_sem);
> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> index 401f09ccce7e..70aba580f4b0 100644
> --- a/fs/f2fs/inode.c
> +++ b/fs/f2fs/inode.c
> @@ -444,6 +444,10 @@ void update_inode(struct inode *inode, struct page 
> *node_page)
>   if (inode->i_nlink == 0)
>   clear_inline_node(node_page);
>  
> + F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
> + F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
> + F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
> + F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;
>  }
>  
>  void update_inode_page(struct inode *inode)
> 

Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

[Rahul Lakkireddy]

On Friday, March 03/30/18, 2018 at 16:09:07 +0530, Jiri Pirko wrote:
> Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkire...@chelsio.com wrote:
> >Add a new module crashdd that exports the /sys/kernel/crashdd/
> >directory in second kernel, containing collected hardware/firmware
> >dumps.
> >
> >The sequence of actions done by device drivers to append their device
> >specific hardware/firmware logs to /sys/kernel/crashdd/ directory are
> >as follows:
> >
> >1. During probe (before hardware is initialized), device drivers
> >register to the crashdd module (via crashdd_add_dump()), with
> >callback function, along with buffer size and log name needed for
> >firmware/hardware log collection.
> >
> >2. Crashdd creates a driver's directory under
> >/sys/kernel/crashdd/. Then, it allocates the buffer with
> 
> This smells. I need to identify the exact ASIC instance that produced
> the dump. To identify by driver name does not help me if I have multiple
> instances of the same driver. This looks wrong to me. This looks like
> a job for devlink where you have 1 devlink instance per 1 ASIC instance.
> 
> Please see:
> http://patchwork.ozlabs.org/project/netdev/list/?series=36524
> 
> I bevieve that the solution in the patchset could be used for
> your usecase too.
> 
> 

The sysfs approach proposed here had been dropped in favour exporting
the dumps as ELF notes in /proc/vmcore.

Will be posting the new patches soon.

> >requested size and invokes the device driver's registered callback
> >function.
> >
> >3. Device driver collects all hardware/firmware logs into the buffer
> >and returns control back to crashdd.
> >
> >4. Crashdd exposes the buffer as a binary file via
> >/sys/kernel/crashdd//.
> >

Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

[Rahul Lakkireddy]

On Friday, March 03/30/18, 2018 at 16:09:07 +0530, Jiri Pirko wrote:
> Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkire...@chelsio.com wrote:
> >Add a new module crashdd that exports the /sys/kernel/crashdd/
> >directory in second kernel, containing collected hardware/firmware
> >dumps.
> >
> >The sequence of actions done by device drivers to append their device
> >specific hardware/firmware logs to /sys/kernel/crashdd/ directory are
> >as follows:
> >
> >1. During probe (before hardware is initialized), device drivers
> >register to the crashdd module (via crashdd_add_dump()), with
> >callback function, along with buffer size and log name needed for
> >firmware/hardware log collection.
> >
> >2. Crashdd creates a driver's directory under
> >/sys/kernel/crashdd/. Then, it allocates the buffer with
> 
> This smells. I need to identify the exact ASIC instance that produced
> the dump. To identify by driver name does not help me if I have multiple
> instances of the same driver. This looks wrong to me. This looks like
> a job for devlink where you have 1 devlink instance per 1 ASIC instance.
> 
> Please see:
> http://patchwork.ozlabs.org/project/netdev/list/?series=36524
> 
> I bevieve that the solution in the patchset could be used for
> your usecase too.
> 
> 

The sysfs approach proposed here had been dropped in favour exporting
the dumps as ELF notes in /proc/vmcore.

Will be posting the new patches soon.

> >requested size and invokes the device driver's registered callback
> >function.
> >
> >3. Device driver collects all hardware/firmware logs into the buffer
> >and returns control back to crashdd.
> >
> >4. Crashdd exposes the buffer as a binary file via
> >/sys/kernel/crashdd//.
> >

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Dominik Brodowski]

On Fri, Mar 30, 2018 at 12:16:02PM +0200, Ingo Molnar wrote:
> 
> * Dominik Brodowski  wrote:
> 
> > A few questions remain, from important stuff to bikeshedding:
> > 
> > 1) Is it acceptable to pass the existing struct pt_regs to the sys_*()
> >kernel functions in emulate_vsyscall(), or should it use a hand-crafted
> >struct pt_regs instead?
> 
> I think so: we already have task_pt_regs() which gives access to the real 
> return 
> registers on the kernel stack.
> 
> I think as long as we constify the pointer, we should pass in the real thing.

Good idea. I have updated the patchset accordingly.

> > 2) Is it the right approach to generate the __sys32_ia32_*() names to
> >include in the syscall table on-the-fly, or should they all be listed
> >in arch/x86/entry/syscalls/syscall_32.tbl ?
> 
> I think as a general principle all system call tables should point to the 
> first-hop wrapper symbol name (i.e. __sys32_ia32_*() in this case), not to 
> the 
> generic symbol name - even though we could generate the former from the 
> latter.
> 
> The more indirection in these tables, the harder to read they become I think.
> 
> > 3) I have chosen to name the default 64-bit syscall stub sys_*(), same as
> >the "normal" syscall, and the IA32_EMULATION compat syscall stub
> >compat_sys_*(), same as the "normal" compat syscall. Though this
> >might cause some confusion, as the "same" function uses a different
> >calling convention and different parameters on x86, it has the
> >advantages that
> > - the kernel *has* a function sys_*() implementing the syscall,
> >   so those curious in stack traces etc. will find it in plain
> >   sight,
> > - it is easier to handle in the syscall table generation, and
> > - error injection works the same.
> 
> I don't think there should be a symbol space overlap, that will only lead to 
> confusion. The symbols can be _similar_, with a prefix, underscores or so, 
> but 
> they shouldn't match I think.

OK, I'll wait for a few more opinions on these two related issues, and update
the code accordingly then.

> > The whole series is available at
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > syscalls-WIP
> 
> BTW., I'd like all these bits to go through the x86 tree.
> 
> What is the expected merge route of the generic preparatory bits?

My current plan is to push the 109 patch bomb to remove in-kernel calls to 
syscalls
directly to Linus once v4.16 is released.

For this series of seven patches, I am content with them going upstream through
the x86 tree (once that contains a backmerge of Linus' tree or the syscalls
tree, obviously). IMO, these seven patches should be kept together, and not 
routed
upstream through different channels.

Thanks,
Dominik

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Dominik Brodowski]

On Fri, Mar 30, 2018 at 12:16:02PM +0200, Ingo Molnar wrote:
> 
> * Dominik Brodowski  wrote:
> 
> > A few questions remain, from important stuff to bikeshedding:
> > 
> > 1) Is it acceptable to pass the existing struct pt_regs to the sys_*()
> >kernel functions in emulate_vsyscall(), or should it use a hand-crafted
> >struct pt_regs instead?
> 
> I think so: we already have task_pt_regs() which gives access to the real 
> return 
> registers on the kernel stack.
> 
> I think as long as we constify the pointer, we should pass in the real thing.

Good idea. I have updated the patchset accordingly.

> > 2) Is it the right approach to generate the __sys32_ia32_*() names to
> >include in the syscall table on-the-fly, or should they all be listed
> >in arch/x86/entry/syscalls/syscall_32.tbl ?
> 
> I think as a general principle all system call tables should point to the 
> first-hop wrapper symbol name (i.e. __sys32_ia32_*() in this case), not to 
> the 
> generic symbol name - even though we could generate the former from the 
> latter.
> 
> The more indirection in these tables, the harder to read they become I think.
> 
> > 3) I have chosen to name the default 64-bit syscall stub sys_*(), same as
> >the "normal" syscall, and the IA32_EMULATION compat syscall stub
> >compat_sys_*(), same as the "normal" compat syscall. Though this
> >might cause some confusion, as the "same" function uses a different
> >calling convention and different parameters on x86, it has the
> >advantages that
> > - the kernel *has* a function sys_*() implementing the syscall,
> >   so those curious in stack traces etc. will find it in plain
> >   sight,
> > - it is easier to handle in the syscall table generation, and
> > - error injection works the same.
> 
> I don't think there should be a symbol space overlap, that will only lead to 
> confusion. The symbols can be _similar_, with a prefix, underscores or so, 
> but 
> they shouldn't match I think.

OK, I'll wait for a few more opinions on these two related issues, and update
the code accordingly then.

> > The whole series is available at
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > syscalls-WIP
> 
> BTW., I'd like all these bits to go through the x86 tree.
> 
> What is the expected merge route of the generic preparatory bits?

My current plan is to push the 109 patch bomb to remove in-kernel calls to 
syscalls
directly to Linus once v4.16 is released.

For this series of seven patches, I am content with them going upstream through
the x86 tree (once that contains a backmerge of Linus' tree or the syscalls
tree, obviously). IMO, these seven patches should be kept together, and not 
routed
upstream through different channels.

Thanks,
Dominik

Re: [PATCH v2 2/2] net: mvneta: improve suspend/resume

[Russell King - ARM Linux]

On Fri, Mar 30, 2018 at 06:36:15PM +0800, Jisheng Zhang wrote:
> Current suspend/resume implementation reuses the mvneta_open() and
> mvneta_close(), but it could be optimized to take only necessary
> actions during suspend/resume.
> 
> One obvious problem of current implementation is: after hundreds of
> system suspend/resume cycles, the resume of mvneta could fail due to
> fragmented dma coherent memory. After this patch, the non-necessary
> memory alloc/free is optimized out.

I don't think you've properly tested this.  Please ensure that you test
patches with the appropriate debug options enabled.

> @@ -4586,16 +4586,43 @@ static int mvneta_remove(struct platform_device *pdev)
>  #ifdef CONFIG_PM_SLEEP
>  static int mvneta_suspend(struct device *device)
>  {
> + int queue;
>   struct net_device *dev = dev_get_drvdata(device);
>   struct mvneta_port *pp = netdev_priv(dev);
>  
> - rtnl_lock();
> - if (netif_running(dev))
> - mvneta_stop(dev);
> - rtnl_unlock();
...
> + mvneta_stop_dev(pp);

You're removing the rtnl_lock() that I introduced in 3b8bc67413de
("net: mvneta: ensure PM paths take the rtnl lock") which is necessary
to provide phylink with consistent locking.  mvneta_stop_dev() calls
phylink_stop() which will check that the rtnl lock is held, and will
print a warning if it isn't.

Your patch will cause a regression here.

> +
> + for (queue = 0; queue < rxq_number; queue++) {
> + struct mvneta_rx_queue *rxq = >rxqs[queue];
> +
> + mvneta_rxq_drop_pkts(pp, rxq);
> + }
> +
> + for (queue = 0; queue < txq_number; queue++) {
> + struct mvneta_tx_queue *txq = >txqs[queue];
> +
> + mvneta_txq_hw_deinit(pp, txq);
> + }
> +
> +clean_exit:
>   netif_device_detach(dev);
>   clk_disable_unprepare(pp->clk_bus);
>   clk_disable_unprepare(pp->clk);
> +
>   return 0;
>  }
>  
> @@ -4604,7 +4631,7 @@ static int mvneta_resume(struct device *device)
>   struct platform_device *pdev = to_platform_device(device);
>   struct net_device *dev = dev_get_drvdata(device);
>   struct mvneta_port *pp = netdev_priv(dev);
> - int err;
> + int err, queue;
>  
>   clk_prepare_enable(pp->clk);
>   if (!IS_ERR(pp->clk_bus))
> @@ -4626,12 +4653,36 @@ static int mvneta_resume(struct device *device)
>   }
>  
>   netif_device_attach(dev);
> - rtnl_lock();
> - if (netif_running(dev)) {
> - mvneta_open(dev);
> - mvneta_set_rx_mode(dev);
...
>   }
> - rtnl_unlock();
...
> + mvneta_start_dev(pp);

Same applies here.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH v2 2/2] net: mvneta: improve suspend/resume

[Russell King - ARM Linux]

On Fri, Mar 30, 2018 at 06:36:15PM +0800, Jisheng Zhang wrote:
> Current suspend/resume implementation reuses the mvneta_open() and
> mvneta_close(), but it could be optimized to take only necessary
> actions during suspend/resume.
> 
> One obvious problem of current implementation is: after hundreds of
> system suspend/resume cycles, the resume of mvneta could fail due to
> fragmented dma coherent memory. After this patch, the non-necessary
> memory alloc/free is optimized out.

I don't think you've properly tested this.  Please ensure that you test
patches with the appropriate debug options enabled.

> @@ -4586,16 +4586,43 @@ static int mvneta_remove(struct platform_device *pdev)
>  #ifdef CONFIG_PM_SLEEP
>  static int mvneta_suspend(struct device *device)
>  {
> + int queue;
>   struct net_device *dev = dev_get_drvdata(device);
>   struct mvneta_port *pp = netdev_priv(dev);
>  
> - rtnl_lock();
> - if (netif_running(dev))
> - mvneta_stop(dev);
> - rtnl_unlock();
...
> + mvneta_stop_dev(pp);

You're removing the rtnl_lock() that I introduced in 3b8bc67413de
("net: mvneta: ensure PM paths take the rtnl lock") which is necessary
to provide phylink with consistent locking.  mvneta_stop_dev() calls
phylink_stop() which will check that the rtnl lock is held, and will
print a warning if it isn't.

Your patch will cause a regression here.

> +
> + for (queue = 0; queue < rxq_number; queue++) {
> + struct mvneta_rx_queue *rxq = >rxqs[queue];
> +
> + mvneta_rxq_drop_pkts(pp, rxq);
> + }
> +
> + for (queue = 0; queue < txq_number; queue++) {
> + struct mvneta_tx_queue *txq = >txqs[queue];
> +
> + mvneta_txq_hw_deinit(pp, txq);
> + }
> +
> +clean_exit:
>   netif_device_detach(dev);
>   clk_disable_unprepare(pp->clk_bus);
>   clk_disable_unprepare(pp->clk);
> +
>   return 0;
>  }
>  
> @@ -4604,7 +4631,7 @@ static int mvneta_resume(struct device *device)
>   struct platform_device *pdev = to_platform_device(device);
>   struct net_device *dev = dev_get_drvdata(device);
>   struct mvneta_port *pp = netdev_priv(dev);
> - int err;
> + int err, queue;
>  
>   clk_prepare_enable(pp->clk);
>   if (!IS_ERR(pp->clk_bus))
> @@ -4626,12 +4653,36 @@ static int mvneta_resume(struct device *device)
>   }
>  
>   netif_device_attach(dev);
> - rtnl_lock();
> - if (netif_running(dev)) {
> - mvneta_open(dev);
> - mvneta_set_rx_mode(dev);
...
>   }
> - rtnl_unlock();
...
> + mvneta_start_dev(pp);

Same applies here.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up