Re: [PATCH v3 3/8] clk: samsung: add BPLL rate table for Exynos 5422 SoC

[Chanwoo Choi]

Hi Lukasz,

2019년 2월 1일 (금) 오후 11:22, Lukasz Luba 님이 작성:

>
> Hi Chanwoo,
>
> On 2/1/19 9:44 AM, Chanwoo Choi wrote:
> > Hi,
> >
> > On 19. 1. 31. 오후 5:49, Lukasz Luba wrote:
> >> Add new table rate for BPLL for Exynos5422 SoC supporting Dynamic Memory
> >> Controller frequencies for driver's DRAM timings.
> >>
> >> CC: Sylwester Nawrocki 
> >> CC: Chanwoo Choi 
> >> CC: Michael Turquette 
> >> CC: Stephen Boyd 
> >> CC: Kukjin Kim 
> >> CC: Krzysztof Kozlowski 
> >> CC: linux-samsung-...@vger.kernel.org
> >> CC: linux-...@vger.kernel.org
> >> CC: linux-arm-ker...@lists.infradead.org
> >> CC: linux-kernel@vger.kernel.org
> >> Signed-off-by: Lukasz Luba 
> >> ---
> >>   drivers/clk/samsung/clk-exynos5420.c | 15 ++-
> >>   1 file changed, 14 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> >> b/drivers/clk/samsung/clk-exynos5420.c
> >> index 3e87421..8bf9579 100644
> >> --- a/drivers/clk/samsung/clk-exynos5420.c
> >> +++ b/drivers/clk/samsung/clk-exynos5420.c
> >> @@ -1325,6 +1325,19 @@ static const struct samsung_pll_rate_table 
> >> exynos5420_pll2550x_24mhz_tbl[] __ini
> >>  PLL_35XX_RATE(24 * MHZ, 2,  200, 3, 3),
> >>   };
> >>
> >> +static const struct samsung_pll_rate_table exynos5422_bpll_rate_table[] = 
> >> {
> >> +PLL_35XX_RATE(24 * MHZ, 93300, 311, 4, 1),
> >> +PLL_35XX_RATE(24 * MHZ, 82500, 275, 4, 1),
> >> +PLL_35XX_RATE(24 * MHZ, 72800, 182, 3, 1),
> >> +PLL_35XX_RATE(24 * MHZ, 63300, 211, 4, 1),
> >> +PLL_35XX_RATE(24 * MHZ, 54300, 181, 2, 2),
> >> +PLL_35XX_RATE(24 * MHZ, 41300, 413, 6, 2),
> >> +PLL_35XX_RATE(24 * MHZ, 27500, 275, 3, 3),
> >> +PLL_35XX_RATE(24 * MHZ, 20600, 206, 3, 3),
> >> +PLL_35XX_RATE(24 * MHZ, 16500, 110, 2, 3),
> >> +PLL_35XX_RATE(24 * MHZ, 13800, 184, 2, 4),
> >
> > Except for 825Mhz, I can't find the target frequency
> > on Exynos5422 TRM document. Usually, Exynos TRM specified
> > the supported stable clocks. It means that undefined clocks
> > are not stable as I knew. Where do you find them?
> >
> > When I calculated the PLL frequency with PMS value, it is correct.
> > But, just we need to check the reference of undefined clocks on TRM
> > in order to guarantee the stable operation.
> They values live in vendor code for Android.
> I have tested the DMC & DDR with these ratios in stress scenarios
> for a few days and it was stable.

If possible, please share the url of original vendor code.

>
> >
> > Remove 933/138Mhz because exynos5433-dmc.c doesn't use 933Mhz and 138Mhz
> > and also Exynos5422 TRM doesn't define 933/138Mhz on pll table.
> OK, I will remove them.
> >
> >> +};
> >> +
> >>   static const struct samsung_pll_rate_table exynos5420_epll_24mhz_tbl[] = 
> >> {
> >>  PLL_36XX_RATE(24 * MHZ, 6U, 100, 2, 1, 0),
> >>  PLL_36XX_RATE(24 * MHZ, 4U, 200, 3, 2, 0),
> >> @@ -1467,7 +1480,7 @@ static void __init exynos5x_clk_init(struct 
> >> device_node *np,
> >>  exynos5x_plls[apll].rate_table = 
> >> exynos5420_pll2550x_24mhz_tbl;
> >>  exynos5x_plls[epll].rate_table = exynos5420_epll_24mhz_tbl;
> >>  exynos5x_plls[kpll].rate_table = 
> >> exynos5420_pll2550x_24mhz_tbl;
> >> -exynos5x_plls[bpll].rate_table = 
> >> exynos5420_pll2550x_24mhz_tbl;
> >> +exynos5x_plls[bpll].rate_table = exynos5422_bpll_rate_table;
> >
> > Exynos5422 used the same PLL table for apll, kpll, bpll and so on.
> > You don't need to make the separate pll table. Just add new entries
> > to exynos5420_pll2550x_24mhz_tbl table.
> OK, I will extend the exynos5420_pll2550x_24mhz_tbl table.
>
> In v4 patch set, it will be fixed.
>
> Regards,
> Lukasz
> >
> >>  }
> >>
> >>  samsung_clk_register_pll(ctx, exynos5x_plls, 
> >> ARRAY_SIZE(exynos5x_plls),
> >>
> >



--
Best Regards,
Chanwoo Choi
Samsung Electronics

[PATCH] signal: always allocate siginfo for SI_TKILL

[Jack Andersen]

The patch titled
`signal: Never allocate siginfo for SIGKILL or SIGSTOP`
created a regression for users of PTRACE_GETSIGINFO needing to
discern signals that were raised via the tgkill syscall.

A notable user of this tgkill+ptrace combination is lldb while
debugging a multithreaded program. Without the ability to detect a
SIGSTOP originating from tgkill, lldb does not have a way to
synchronize on a per-thread basis and falls back to SIGSTOP-ing the
entire process.

This patch allocates the siginfo as it did previously whenever the
SI_TKILL code is present.

Signed-off-by: Jack Andersen 
---
 kernel/signal.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 9a32bc2088c9..7a810aefb5df 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1058,9 +1058,11 @@ static int __send_signal(int sig, struct kernel_siginfo 
*info, struct task_struc
result = TRACE_SIGNAL_DELIVERED;
/*
 * Skip useless siginfo allocation for SIGKILL SIGSTOP,
-* and kernel threads.
+* and kernel threads. SI_TKILL is an exception to allow
+* processes to discern signals originating from tgkill.
 */
-   if (sig_kernel_only(sig) || (t->flags & PF_KTHREAD))
+   if ((sig_kernel_only(sig) && info->si_code != SI_TKILL) ||
+   (t->flags & PF_KTHREAD))
goto out_set;
 
/*
-- 
2.20.1

Re: [PATCH net-next 10/12] net: hns3: don't allow user to change vlan filter state

[Sergei Shtylyov]

Hello!

On 02.02.2019 17:39, Huazhong Tan wrote:


From: Jian Shen 

When user disables vlan filter, and adds vlan device, it won't
notify the driver the update the vlan filter. In this case, when


   To update, perhaps?


user enables vlan filter again, the packets with new vlan tag
will be filtered by vlan filter.

Signed-off-by: Jian Shen 
Signed-off-by: Peng Li 
Signed-off-by: Huazhong Tan 

[...]

MBR, Sergei

Re: [PATCH v2 9/9] mtd: rawnand: jz4780-bch: Add support for the JZ4740

[Boris Brezillon]

On Sat,  2 Feb 2019 20:19:26 -0300
Paul Cercueil  wrote:

> Add the backend code for the jz4780-bch driver to support the JZ4740
> SoC from Ingenic.
> 
> Signed-off-by: Paul Cercueil 
> ---
> 
> Changes:
> 
> v2: New patch
> 
>  drivers/mtd/nand/raw/ingenic/Makefile |   2 +-
>  drivers/mtd/nand/raw/ingenic/jz4740_bch.c | 173 ++
>  .../mtd/nand/raw/ingenic/jz4780_bch_common.c  |   1 +
>  .../nand/raw/ingenic/jz4780_bch_internal.h|   1 +
>  4 files changed, 176 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/mtd/nand/raw/ingenic/jz4740_bch.c
> 
> diff --git a/drivers/mtd/nand/raw/ingenic/Makefile 
> b/drivers/mtd/nand/raw/ingenic/Makefile
> index f38b467490cf..d16c96113a93 100644
> --- a/drivers/mtd/nand/raw/ingenic/Makefile
> +++ b/drivers/mtd/nand/raw/ingenic/Makefile
> @@ -1,3 +1,3 @@
>  obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
>  obj-$(CONFIG_MTD_NAND_JZ4780) += jz4780_nand.o jz4780_bch_common.o \
> -  jz4780_bch.o jz4725b_bch.o
> +  jz4780_bch.o jz4725b_bch.o jz4740_bch.o

I still don't see the point of the jz4780_bch_common/jz47xxx_bch
separation. You seem to always embed all objects anyway, so you can
just put the code for both engines in the same source file and decide
which one to use based on the compat (which you already do anyway). 

> diff --git a/drivers/mtd/nand/raw/ingenic/jz4740_bch.c 
> b/drivers/mtd/nand/raw/ingenic/jz4740_bch.c
> new file mode 100644
> index ..61ea109cee9d
> --- /dev/null
> +++ b/drivers/mtd/nand/raw/ingenic/jz4740_bch.c
> @@ -0,0 +1,173 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * JZ4740 backend code for the jz4780-bch driver
> + * based on jz4740-nand.c
> + *
> + * Copyright (c) 2019 Paul Cercueil 
> + */
> +
> +#include 
> +#include 
> +
> +#include "jz4780_bch.h"
> +#include "jz4780_bch_internal.h"
> +
> +#define JZ_REG_NAND_ECC_CTRL 0x00
> +#define JZ_REG_NAND_DATA 0x04
> +#define JZ_REG_NAND_PAR0 0x08
> +#define JZ_REG_NAND_PAR1 0x0C
> +#define JZ_REG_NAND_PAR2 0x10
> +#define JZ_REG_NAND_IRQ_STAT 0x14
> +#define JZ_REG_NAND_IRQ_CTRL 0x18
> +#define JZ_REG_NAND_ERR(x)   (0x1C + ((x) << 2))
> +
> +#define JZ_NAND_ECC_CTRL_PAR_READY   BIT(4)
> +#define JZ_NAND_ECC_CTRL_ENCODINGBIT(3)
> +#define JZ_NAND_ECC_CTRL_RS  BIT(2)
> +#define JZ_NAND_ECC_CTRL_RESET   BIT(1)
> +#define JZ_NAND_ECC_CTRL_ENABLE  BIT(0)
> +
> +#define JZ_NAND_STATUS_ERR_COUNT (BIT(31) | BIT(30) | BIT(29))
> +#define JZ_NAND_STATUS_PAD_FINISHBIT(4)
> +#define JZ_NAND_STATUS_DEC_FINISHBIT(3)
> +#define JZ_NAND_STATUS_ENC_FINISHBIT(2)
> +#define JZ_NAND_STATUS_UNCOR_ERROR   BIT(1)
> +#define JZ_NAND_STATUS_ERROR BIT(0)
> +
> +static const uint8_t empty_block_ecc[] = {
> + 0xcd, 0x9d, 0x90, 0x58, 0xf4, 0x8b, 0xff, 0xb7, 0x6f
> +};
> +
> +static void jz4740_bch_init(struct jz4780_bch *bch, bool encode)
> +{
> + uint32_t reg;
> +
> + /* Clear interrupt status */
> + writel(0, bch->base + JZ_REG_NAND_IRQ_STAT);
> +
> + /* Initialize and enable BCH */
> + reg = readl(bch->base + JZ_REG_NAND_ECC_CTRL);
> + reg |= JZ_NAND_ECC_CTRL_RESET;
> + reg |= JZ_NAND_ECC_CTRL_ENABLE;
> + reg |= JZ_NAND_ECC_CTRL_RS;
> + if (encode)
> + reg |= JZ_NAND_ECC_CTRL_ENCODING;
> + else
> + reg &= ~JZ_NAND_ECC_CTRL_ENCODING;
> +
> + writel(reg, bch->base + JZ_REG_NAND_ECC_CTRL);
> +}
> +
> +static int jz4740_bch_calculate(struct jz4780_bch *bch,
> + struct jz4780_bch_params *params,
> + const u8 *buf, u8 *ecc_code)
> +{
> + uint32_t reg, status;
> + unsigned int timeout = 1000;
> + int i;
> +
> + jz4740_bch_init(bch, true);
> +
> + do {
> + status = readl(bch->base + JZ_REG_NAND_IRQ_STAT);
> + } while (!(status & JZ_NAND_STATUS_ENC_FINISH) && --timeout);
> +
> + if (timeout == 0)
> + return -ETIMEDOUT;
> +
> + reg = readl(bch->base + JZ_REG_NAND_ECC_CTRL);
> + reg &= ~JZ_NAND_ECC_CTRL_ENABLE;
> + writel(reg, bch->base + JZ_REG_NAND_ECC_CTRL);
> +
> + for (i = 0; i < params->bytes; ++i)
> + ecc_code[i] = readb(bch->base + JZ_REG_NAND_PAR0 + i);
> +
> + /* If the written data is completely 0xff, we also want to write 0xff as
> +  * ecc, otherwise we will get in trouble when doing subpage writes.
> +  */
> + if (memcmp(ecc_code, empty_block_ecc, ARRAY_SIZE(empty_block_ecc)) == 0)
> + memset(ecc_code, 0xff, ARRAY_SIZE(empty_block_ecc));
> +
> + return 0;
> +}
> +
> +static void jz_nand_correct_data(uint8_t *buf, int index, int mask)
> +{
> + int offset = index & 0x7;
> + uint16_t data;
> +
> + index += (index >> 3);
> +
> + data = buf[index];
> + data |= buf[index + 1] << 8;
> +
> + mask ^= (data >> offset) & 0x1ff;
> + data &= ~(0x1ff << offset);
> + data |= (mask 

Did you send the images?

[Grace]

Want to retouch your photos? we can help you.

Deep etching or masking for your photos, or even adding clipping path.
Retouching also if needed.

Hopefully to start something for you soon.

Thanks,
Grace














Ingolsdtadt


Nettetal

Re: [PATCH v2 4/9] mtd: rawnand: jz4780: Add support for the JZ4740

[Boris Brezillon]

On Sat,  2 Feb 2019 20:19:21 -0300
Paul Cercueil  wrote:

> Add support for probing the jz4780-nand driver on the JZ4740 SoC from
> Ingenic.
> 
> Signed-off-by: Paul Cercueil 
> ---
> 
> Changes:
> 
> v2: - Add support for the JZ4740 and not the JZ4725B: they behave the
>   same, and JZ4740 is fully upstream while JZ4725B is not. The
>   JZ4725B devicetree will then simply use the "ingenic,jz4740-nand"
>   compatible string.
> - Fix the number of bytes for the ECC when the ECC strength is 4.
>   This is needed for the JZ4740, which uses Reed-Solomon instead of
>   BCH.
> 
>  drivers/mtd/nand/raw/ingenic/jz4780_nand.c | 48 +-

If we're going to make the driver compatible with jz4740 and jz4725b
maybe we should rename the source files jz47xx_{nand,bch}.{c,h}.

>  1 file changed, 37 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c 
> b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
> index 7f55358b860f..c0855fef7735 100644
> --- a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
> +++ b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -26,13 +27,15 @@
>  
>  #define DRV_NAME "jz4780-nand"
>  
> -#define OFFSET_DATA  0x
> -#define OFFSET_CMD   0x0040
> -#define OFFSET_ADDR  0x0080
> -
>  /* Command delay when there is no R/B pin. */
>  #define RB_DELAY_US  100
>  
> +struct jz_soc_info {
> + unsigned long data_offset;
> + unsigned long addr_offset;
> + unsigned long cmd_offset;
> +};
> +
>  struct jz4780_nand_cs {
>   unsigned int bank;
>   void __iomem *base;
> @@ -40,6 +43,7 @@ struct jz4780_nand_cs {
>  
>  struct jz4780_nand_controller {
>   struct device *dev;
> + const struct jz_soc_info *soc_info;
>   struct jz4780_bch *bch;
>   struct nand_controller controller;
>   unsigned int num_banks;
> @@ -101,9 +105,9 @@ static void jz4780_nand_cmd_ctrl(struct nand_chip *chip, 
> int cmd,
>   return;
>  
>   if (ctrl & NAND_ALE)
> - writeb(cmd, cs->base + OFFSET_ADDR);
> + writeb(cmd, cs->base + nfc->soc_info->addr_offset);
>   else if (ctrl & NAND_CLE)
> - writeb(cmd, cs->base + OFFSET_CMD);
> + writeb(cmd, cs->base + nfc->soc_info->cmd_offset);
>  }
>  
>  static int jz4780_nand_dev_ready(struct nand_chip *chip)
> @@ -161,8 +165,13 @@ static int jz4780_nand_attach_chip(struct nand_chip 
> *chip)
>   struct jz4780_nand_controller *nfc = 
> to_jz4780_nand_controller(chip->controller);
>   int eccbytes;
>  
> - chip->ecc.bytes = fls((1 + 8) * chip->ecc.size) *
> - (chip->ecc.strength / 8);
> + if (chip->ecc.strength == 4) {
> + /* JZ4740 uses 9 bytes of ECC to correct maximum 4 errors */
> + chip->ecc.bytes = 9;
> + } else {
> + chip->ecc.bytes = fls((1 + 8) * chip->ecc.size) *
> +   (chip->ecc.strength / 8);
> + }
>  
>   switch (chip->ecc.mode) {
>   case NAND_ECC_HW:
> @@ -272,8 +281,8 @@ static int jz4780_nand_init_chip(struct platform_device 
> *pdev,
>   return -ENOMEM;
>   mtd->dev.parent = dev;
>  
> - chip->legacy.IO_ADDR_R = cs->base + OFFSET_DATA;
> - chip->legacy.IO_ADDR_W = cs->base + OFFSET_DATA;
> + chip->legacy.IO_ADDR_R = cs->base + nfc->soc_info->data_offset;
> + chip->legacy.IO_ADDR_W = cs->base + nfc->soc_info->data_offset;
>   chip->legacy.chip_delay = RB_DELAY_US;
>   chip->options = NAND_NO_SUBPAGE_WRITE;
>   chip->legacy.select_chip = jz4780_nand_select_chip;
> @@ -353,6 +362,10 @@ static int jz4780_nand_probe(struct platform_device 
> *pdev)
>   if (!nfc)
>   return -ENOMEM;
>  
> + nfc->soc_info = device_get_match_data(dev);
> + if (!nfc->soc_info)
> + return -EINVAL;
> +
>   /*
>* Check for BCH HW before we call nand_scan_ident, to prevent us from
>* having to call it again if the BCH driver returns -EPROBE_DEFER.
> @@ -390,8 +403,21 @@ static int jz4780_nand_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static const struct jz_soc_info jz4740_soc_info = {
> + .data_offset = 0x,
> + .cmd_offset  = 0x8000,
> + .addr_offset = 0x0001,
> +};
> +
> +static const struct jz_soc_info jz4780_soc_info = {
> + .data_offset = 0x,
> + .cmd_offset  = 0x0040,
> + .addr_offset = 0x0080,
> +};
> +
>  static const struct of_device_id jz4780_nand_dt_match[] = {
> - { .compatible = "ingenic,jz4780-nand" },
> + { .compatible = "ingenic,jz4740-nand", .data = _soc_info },
> + { .compatible = "ingenic,jz4780-nand",  .data = _soc_info  },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, jz4780_nand_dt_match);

Re: [PATCH v2 6/9] mtd: rawnand: jz4780: Add ooblayout for the Qi Ben Nanonote

[Boris Brezillon]

On Sat,  2 Feb 2019 20:19:23 -0300
Paul Cercueil  wrote:

> The Ben Nanonote from Qi Hardware expects a specific OOB layout on its
> NAND. If the "ingenic,oob-layout" device property is set to "qi,lb60",
> this specific OOB layout is used.

I'm really not a big fan of this ingenic,oob-layout property, it
encourages people to use new custom layouts which is just a pain to
maintain. I understand that we don't have the choice for this board as
it's already upstream, but maybe we can avoid adding this prop and
check the root compat (which should contain the board name). 

> 
> Signed-off-by: Paul Cercueil 
> ---
> 
> Changes:
> 
> v2: New patch
> 
>  drivers/mtd/nand/raw/ingenic/jz4780_nand.c | 37 ++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c 
> b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
> index baebb9a5c7c8..4b304eceae8d 100644
> --- a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
> +++ b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
> @@ -346,6 +346,41 @@ static int jz4780_nand_init_chips(struct 
> jz4780_nand_controller *nfc,
>   return 0;
>  }
>  
> +static int qi_lb60_ooblayout_ecc(struct mtd_info *mtd, int section,
> +  struct mtd_oob_region *oobregion)
> +{
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + struct nand_ecc_ctrl *ecc = >ecc;
> +
> + if (section || !ecc->total)
> + return -ERANGE;
> +
> + oobregion->length = ecc->total;
> + oobregion->offset = 12;
> +
> + return 0;
> +}
> +
> +static int qi_lb60_ooblayout_free(struct mtd_info *mtd, int section,
> +   struct mtd_oob_region *oobregion)
> +{
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + struct nand_ecc_ctrl *ecc = >ecc;
> +
> + if (section)
> + return -ERANGE;
> +
> + oobregion->length = mtd->oobsize - ecc->total - 12;
> + oobregion->offset = 12 + ecc->total;
> +
> + return 0;
> +}
> +
> +const struct mtd_ooblayout_ops qi_lb60_ooblayout_ops = {
> + .ecc = qi_lb60_ooblayout_ecc,
> + .free = qi_lb60_ooblayout_free,
> +};
> +
>  static int jz4725b_ooblayout_ecc(struct mtd_info *mtd, int section,
>struct mtd_oob_region *oobregion)
>  {
> @@ -409,6 +444,8 @@ static int jz4780_nand_probe(struct platform_device *pdev)
>   if (!ret) {
>   if (!strcmp(layout, "ingenic,jz4725b")) {
>   nfc->oob_layout  = _ooblayout_ops;
> + } else if (!strcmp(layout, "qi,lb60")) {
> + nfc->oob_layout = _lb60_ooblayout_ops;
>   } else {
>   dev_err(dev, "Unrecognized OOB layout %s\n", layout);
>   return -EINVAL;

Re: [PATCH v2 5/9] mtd: rawnand: jz4780: Add ooblayout for the JZ4725B

[Boris Brezillon]

On Sat,  2 Feb 2019 20:19:22 -0300
Paul Cercueil  wrote:

> The boot ROM of the JZ4725B SoC expects a specific OOB layout on the
> NAND.
> 
> Add an optional "ingenic,oob-layout" device property. When set to
> "ingenic,jz4725b", this specific OOB layout is used.

It's a SoC-specific layout, please add a compatible for ingenic,jz4725b
and use it to determine the layout to use.

> 
> Signed-off-by: Paul Cercueil 
> ---
> 
> Changes:
> 
> v2: Instead of forcing the OOB layout, leave it to the board code or
> devicetree to decide if the jz4725b-specific layout should be used
> or not.
> 
>  drivers/mtd/nand/raw/ingenic/jz4780_nand.c | 51 +-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c 
> b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
> index c0855fef7735..baebb9a5c7c8 100644
> --- a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
> +++ b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
> @@ -44,6 +44,7 @@ struct jz4780_nand_cs {
>  struct jz4780_nand_controller {
>   struct device *dev;
>   const struct jz_soc_info *soc_info;
> + const struct mtd_ooblayout_ops *oob_layout;
>   struct jz4780_bch *bch;
>   struct nand_controller controller;
>   unsigned int num_banks;
> @@ -213,7 +214,7 @@ static int jz4780_nand_attach_chip(struct nand_chip *chip)
>   return -EINVAL;
>   }
>  
> - mtd_set_ooblayout(mtd, _ooblayout_lp_ops);
> + mtd_set_ooblayout(mtd, nfc->oob_layout);
>  
>   return 0;
>  }
> @@ -345,11 +346,47 @@ static int jz4780_nand_init_chips(struct 
> jz4780_nand_controller *nfc,
>   return 0;
>  }
>  
> +static int jz4725b_ooblayout_ecc(struct mtd_info *mtd, int section,
> +  struct mtd_oob_region *oobregion)
> +{
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + struct nand_ecc_ctrl *ecc = >ecc;
> +
> + if (section || !ecc->total)
> + return -ERANGE;
> +
> + oobregion->length = ecc->total;
> + oobregion->offset = 3;
> +
> + return 0;
> +}
> +
> +static int jz4725b_ooblayout_free(struct mtd_info *mtd, int section,
> +   struct mtd_oob_region *oobregion)
> +{
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + struct nand_ecc_ctrl *ecc = >ecc;
> +
> + if (section)
> + return -ERANGE;
> +
> + oobregion->length = mtd->oobsize - ecc->total - 3;
> + oobregion->offset = 3 + ecc->total;
> +
> + return 0;
> +}
> +
> +const struct mtd_ooblayout_ops jz4725b_ooblayout_ops = {
> + .ecc = jz4725b_ooblayout_ecc,
> + .free = jz4725b_ooblayout_free,
> +};
> +
>  static int jz4780_nand_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
>   unsigned int num_banks;
>   struct jz4780_nand_controller *nfc;
> + const char *layout;
>   int ret;
>  
>   num_banks = jz4780_nemc_num_banks(dev);
> @@ -366,6 +403,18 @@ static int jz4780_nand_probe(struct platform_device 
> *pdev)
>   if (!nfc->soc_info)
>   return -EINVAL;
>  
> + nfc->oob_layout = _ooblayout_lp_ops;
> +
> + ret = device_property_read_string(dev, "ingenic,oob-layout", );
> + if (!ret) {
> + if (!strcmp(layout, "ingenic,jz4725b")) {
> + nfc->oob_layout  = _ooblayout_ops;
> + } else {
> + dev_err(dev, "Unrecognized OOB layout %s\n", layout);
> + return -EINVAL;
> + }
> + }
> +
>   /*
>* Check for BCH HW before we call nand_scan_ident, to prevent us from
>* having to call it again if the BCH driver returns -EPROBE_DEFER.

Re: [PATCH v2 0/9] Ingenic JZ4780 NAND patchset v2

[Boris Brezillon]

On Sat,  2 Feb 2019 20:19:17 -0300
Paul Cercueil  wrote:

> Hi,
> 
> As requested by Boris, I added a patch to move all the Ingenic NAND
> drivers to their own directory.
> 
> In this V2 I added support for the JZ4740 SoC. The combo of the
> jz4780-nemc, jz4780-nand and jz4740-bch now obsolete the old and dusty
> jz4740-nand driver.

Any plan to get the old driver removed? I guess you want to migrate the
boards to DT first.

> 
> To support the only upstream JZ4740-based board we have, the Ben
> Nanonote, I added an option to specify the OOB layout of that device
> from a device property string.
> 
> Finally, I dropped the last two patches that moved the platform NAND
> code to devicetree; I will upstream them as part of a different
> patchset.
> 
> Cheers,
> -Paul
> 

[PATCH v2 2/3] dt-bindings: nvmem: Add bindings for ZynqMP nvmem driver

[Nava kishore Manne]

Add documentation to describe Xilinx ZynqMP nvmem driver
bindings.

Signed-off-by: Nava kishore Manne 
Reviewed-by: Rob Herring 
---
 .../bindings/nvmem/xlnx,zynqmp-nvmem.txt  | 47 +++
 1 file changed, 47 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt

diff --git a/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt 
b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
new file mode 100644
index ..2043c8284f8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
@@ -0,0 +1,47 @@
+--
+=  Zynq UltraScale+ MPSoC nvmem firmware driver binding =
+--
+The nvmem_firmware node provides access to the hardware related data
+like soc revision, IDCODE... etc, By using the firmware interface.
+
+Required properties:
+- compatible: should be "xlnx,zynqmp-nvmem-fw"
+
+= Data cells =
+Are child nodes of silicon id, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+---
+ Example
+---
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   nvmem_firmware {
+   compatible = "xlnx,zynqmp-nvmem-fw";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* Data cells */
+   soc_revision: soc_revision {
+   reg = <0x0 0x4>;
+   };
+   };
+   };
+};
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+   pcap {
+   ...
+
+   nvmem-cells = <_revision>;
+   nvmem-cell-names = "soc_revision";
+
+   ...
+   };
+
-- 
2.18.0

[PATCH v2 3/3] nvmem: zynqmp: Added zynqmp nvmem firmware driver

[Nava kishore Manne]

This patch adds zynqmp nvmem firmware driver to access the
SoC revision information from the hardware register.

Signed-off-by: Nava kishore Manne 
---
Changes for v2:
-None.
Changes for v1:
-None.

Changes for RFC-V3:
-Changed nvmem_register() to devm_nvmem_register()
 and pr_debug() to dev_dbg() as suggested by srinivas.

Changes for RFC-V2:
-None.

 drivers/nvmem/Kconfig| 15 +++
 drivers/nvmem/Makefile   |  5 ++-
 drivers/nvmem/zynqmp_nvmem.c | 86 
 3 files changed, 96 insertions(+), 10 deletions(-)
 create mode 100644 drivers/nvmem/zynqmp_nvmem.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 0a7a470ee859..2edb1428ef6d 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -181,15 +181,14 @@ config RAVE_SP_EEPROM
help
  Say y here to enable Rave SP EEPROM support.
 
-config SC27XX_EFUSE
-   tristate "Spreadtrum SC27XX eFuse Support"
-   depends on MFD_SC27XX_PMIC || COMPILE_TEST
-   depends on HAS_IOMEM
+config NVMEM_ZYNQMP
+   bool "Xilinx ZYNQMP SoC nvmem firmware support"
+   depends on ARCH_ZYNQMP
help
- This is a simple driver to dump specified values of Spreadtrum
- SC27XX PMICs from eFuse.
+ This is a driver to access hardware related data like
+ soc revision, IDCODE... etc by using the firmware
+ interface.
 
- This driver can also be built as a module. If so, the module
- will be called nvmem-sc27xx-efuse.
+ If sure, say yes. If unsure, say no.
 
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 4e8c61628f1a..0b3abd7f5d02 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -39,5 +39,6 @@ obj-$(CONFIG_NVMEM_SNVS_LPGPR)+= nvmem_snvs_lpgpr.o
 nvmem_snvs_lpgpr-y := snvs_lpgpr.o
 obj-$(CONFIG_RAVE_SP_EEPROM)   += nvmem-rave-sp-eeprom.o
 nvmem-rave-sp-eeprom-y := rave-sp-eeprom.o
-obj-$(CONFIG_SC27XX_EFUSE) += nvmem-sc27xx-efuse.o
-nvmem-sc27xx-efuse-y   := sc27xx-efuse.o
+obj-$(CONFIG_NVMEM_ZYNQMP) += nvmem_zynqmp_nvmem.o
+nvmem_zynqmp_nvmem-y   := zynqmp_nvmem.o
+
diff --git a/drivers/nvmem/zynqmp_nvmem.c b/drivers/nvmem/zynqmp_nvmem.c
new file mode 100644
index ..b910864e91b7
--- /dev/null
+++ b/drivers/nvmem/zynqmp_nvmem.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SILICON_REVISION_MASK 0xF
+
+struct zynqmp_nvmem_data {
+   struct device *dev;
+   struct nvmem_device *nvmem;
+};
+
+static int zynqmp_nvmem_read(void *context, unsigned int offset,
+void *val, size_t bytes)
+{
+   int ret;
+   int idcode, version;
+   struct zynqmp_nvmem_data *priv = context;
+
+   const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+   if (!eemi_ops || !eemi_ops->get_chipid)
+   return -ENXIO;
+
+   ret = eemi_ops->get_chipid(, );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(priv->dev, "Read chipid val %x %x\n", idcode, version);
+   *(int *)val = version & SILICON_REVISION_MASK;
+
+   return 0;
+}
+
+static struct nvmem_config econfig = {
+   .name = "zynqmp-nvmem",
+   .owner = THIS_MODULE,
+   .word_size = 1,
+   .size = 1,
+   .read_only = true,
+};
+
+static const struct of_device_id zynqmp_nvmem_match[] = {
+   { .compatible = "xlnx,zynqmp-nvmem-fw", },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, zynqmp_nvmem_match);
+
+static int zynqmp_nvmem_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct zynqmp_nvmem_data *priv;
+
+   priv = devm_kzalloc(dev, sizeof(struct zynqmp_nvmem_data), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   priv->dev = dev;
+   econfig.dev = dev;
+   econfig.reg_read = zynqmp_nvmem_read;
+   econfig.priv = priv;
+
+   priv->nvmem = devm_nvmem_register(dev, );
+
+   return PTR_ERR_OR_ZERO(priv->nvmem);
+}
+
+static struct platform_driver zynqmp_nvmem_driver = {
+   .probe = zynqmp_nvmem_probe,
+   .driver = {
+   .name = "zynqmp-nvmem",
+   .of_match_table = zynqmp_nvmem_match,
+   },
+};
+
+module_platform_driver(zynqmp_nvmem_driver);
+
+MODULE_AUTHOR("Michal Simek , Nava kishore Manne 
");
+MODULE_DESCRIPTION("ZynqMP NVMEM driver");
+MODULE_LICENSE("GPL");
-- 
2.18.0

[PATCH v2 0/3] Add nvmem driver support for ZynqMP

[Nava kishore Manne]

Nava kishore Manne (3):
  firmware: xilinx: Add zynqmp_pm_get_chipid() API
  dt-bindings: nvmem: Add bindings for ZynqMP nvmem driver
  nvmem: zynqmp: Added zynqmp nvmem firmware driver

 .../bindings/nvmem/xlnx,zynqmp-nvmem.txt  | 47 ++
 drivers/firmware/xilinx/zynqmp.c  | 24 ++
 drivers/nvmem/Kconfig | 15 ++--
 drivers/nvmem/Makefile|  5 +-
 drivers/nvmem/zynqmp_nvmem.c  | 86 +++
 include/linux/firmware/xlnx-zynqmp.h  |  2 +
 6 files changed, 169 insertions(+), 10 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
 create mode 100644 drivers/nvmem/zynqmp_nvmem.c

-- 
2.18.0

[PATCH v2 1/3] firmware: xilinx: Add zynqmp_pm_get_chipid() API

[Nava kishore Manne]

This patch adds a new API to provide access to the
hardware related data like soc revision, IDCODE... etc.

Signed-off-by: Nava kishore Manne 
---
Changes for v2:
-None.
Changes for v1:
-None.

Changes for RFC-V3:
-corrected typo error in commit msg.

Changes for RFC-v2:
-New Patch.

 drivers/firmware/xilinx/zynqmp.c | 24 
 include/linux/firmware/xlnx-zynqmp.h |  2 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 9a1c72a9280f..af2a209fc2da 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -186,6 +186,29 @@ static int zynqmp_pm_get_api_version(u32 *version)
return ret;
 }
 
+/**
+ * zynqmp_pm_get_chipid - Get silicon ID registers
+ * @idcode: IDCODE register
+ * @version:version register
+ *
+ * Return:  Returns the status of the operation and the idcode and version
+ *  registers in @idcode and @version.
+ */
+static int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!idcode || !version)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_GET_CHIPID, 0, 0, 0, 0, ret_payload);
+   *idcode = ret_payload[1];
+   *version = ret_payload[2];
+
+   return ret;
+}
+
 /**
  * zynqmp_pm_get_trustzone_version() - Get secure trustzone firmware version
  * @version:   Returned version value
@@ -471,6 +494,7 @@ static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 
arg1, u32 arg2,
 
 static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
+   .get_chipid = zynqmp_pm_get_chipid,
.query_data = zynqmp_pm_query_data,
.clock_enable = zynqmp_pm_clock_enable,
.clock_disable = zynqmp_pm_clock_disable,
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 3c3c28eff56a..c435f4b35adf 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -34,6 +34,7 @@
 
 enum pm_api_id {
PM_GET_API_VERSION = 1,
+   PM_GET_CHIPID = 22,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -91,6 +92,7 @@ struct zynqmp_pm_query_data {
 
 struct zynqmp_eemi_ops {
int (*get_api_version)(u32 *version);
+   int (*get_chipid)(u32 *idcode, u32 *version);
int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
int (*clock_enable)(u32 clock_id);
int (*clock_disable)(u32 clock_id);
-- 
2.18.0

question about drivers/phy/renesas/phy-rcar-gen2.c

[Julia Lawall]

Hello,

I was wondering whether phy-rcar-gen2.c would use dynamically allocated
device nodes?  If so, it looks like the following code could cause a
use-after-free, due to not incrementing th reference count:

for_each_child_of_node(dev->of_node, np) {
struct rcar_gen2_channel *channel = drv->channels + i;
u32 channel_num;
int error, n;

channel->of_node = np;
...
}

On the other hand, if the reference cound it incrememnted, preventing
memory leaks in the case where the probe function fails would entail some
complex rewriting of the code, so I thought it would be better to ask
first.

thanks,
julia

[PATCH v2] mm: proc: smaps_rollup: Fix pss_locked calculation

[Sandeep Patil]

The 'pss_locked' field of smaps_rollup was being calculated incorrectly.
It accumulated the current pss everytime a locked VMA was found.  Fix
that by adding to 'pss_locked' the same time as that of 'pss' if the vma
being walked is locked.

Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup")
Cc: sta...@vger.kernel.org # 4.14.y 4.19.y
Signed-off-by: Sandeep Patil 
---

v1->v2
--
- Move pss_locked accounting into smaps_account() inline with pss

 fs/proc/task_mmu.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index f0ec9edab2f3..85b0ef890b28 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -423,7 +423,7 @@ struct mem_size_stats {
 };
 
 static void smaps_account(struct mem_size_stats *mss, struct page *page,
-   bool compound, bool young, bool dirty)
+   bool compound, bool young, bool dirty, bool locked)
 {
int i, nr = compound ? 1 << compound_order(page) : 1;
unsigned long size = nr * PAGE_SIZE;
@@ -450,24 +450,31 @@ static void smaps_account(struct mem_size_stats *mss, 
struct page *page,
else
mss->private_clean += size;
mss->pss += (u64)size << PSS_SHIFT;
+   if (locked)
+   mss->pss_locked += (u64)size << PSS_SHIFT;
return;
}
 
for (i = 0; i < nr; i++, page++) {
int mapcount = page_mapcount(page);
+   unsigned long pss = (PAGE_SIZE << PSS_SHIFT);
 
if (mapcount >= 2) {
if (dirty || PageDirty(page))
mss->shared_dirty += PAGE_SIZE;
else
mss->shared_clean += PAGE_SIZE;
-   mss->pss += (PAGE_SIZE << PSS_SHIFT) / mapcount;
+   mss->pss += pss / mapcount;
+   if (locked)
+   mss->pss_locked += pss / mapcount;
} else {
if (dirty || PageDirty(page))
mss->private_dirty += PAGE_SIZE;
else
mss->private_clean += PAGE_SIZE;
-   mss->pss += PAGE_SIZE << PSS_SHIFT;
+   mss->pss += pss;
+   if (locked)
+   mss->pss_locked += pss;
}
}
 }
@@ -490,6 +497,7 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
 {
struct mem_size_stats *mss = walk->private;
struct vm_area_struct *vma = walk->vma;
+   bool locked = !!(vma->vm_flags & VM_LOCKED);
struct page *page = NULL;
 
if (pte_present(*pte)) {
@@ -532,7 +540,7 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
if (!page)
return;
 
-   smaps_account(mss, page, false, pte_young(*pte), pte_dirty(*pte));
+   smaps_account(mss, page, false, pte_young(*pte), pte_dirty(*pte), 
locked);
 }
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
@@ -541,6 +549,7 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
 {
struct mem_size_stats *mss = walk->private;
struct vm_area_struct *vma = walk->vma;
+   bool locked = !!(vma->vm_flags & VM_LOCKED);
struct page *page;
 
/* FOLL_DUMP will return -EFAULT on huge zero page */
@@ -555,7 +564,7 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
/* pass */;
else
VM_BUG_ON_PAGE(1, page);
-   smaps_account(mss, page, true, pmd_young(*pmd), pmd_dirty(*pmd));
+   smaps_account(mss, page, true, pmd_young(*pmd), pmd_dirty(*pmd), 
locked);
 }
 #else
 static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
@@ -737,11 +746,8 @@ static void smap_gather_stats(struct vm_area_struct *vma,
}
}
 #endif
-
/* mmap_sem is held in m_start */
walk_page_vma(vma, _walk);
-   if (vma->vm_flags & VM_LOCKED)
-   mss->pss_locked += mss->pss;
 }
 
 #define SEQ_PUT_DEC(str, val) \
-- 
2.20.1.611.gfbb209baf1-goog

Re: [PATCH v2] Bluetooth: Add NULL check for tiocmget() and tiocmset()

[Myungho Jung]

On Thu, Jan 31, 2019 at 04:40:00PM +0100, Johan Hovold wrote:
> On Tue, Jan 29, 2019 at 09:39:28PM -0800, Myungho Jung wrote:
> > tiocmget() and tiocmset() operations are optional and some tty drivers
> > like pty miss the operations. We need NULL check to prevent from
> > dereference.
> > 
> > Signed-off-by: Myungho Jung 
> > ---
> >  drivers/bluetooth/hci_ath.c   | 6 ++
> >  drivers/bluetooth/hci_ldisc.c | 4 
> >  2 files changed, 10 insertions(+)
> 
> Ah, you had already submitted a v2.
> 
> I still suggest splitting this one in two patches and that you add a
> Fixes and stable tag to each so that they both get backported to stable.
> 
> Also, when resubmitting, make sure to include a short changelog here
> below the cut-off line (---).
> 
> > 
> > diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
> > index d568fbd94d6c..fb9f6323a911 100644
> > --- a/drivers/bluetooth/hci_ath.c
> > +++ b/drivers/bluetooth/hci_ath.c
> > @@ -185,8 +185,14 @@ static int ath_set_bdaddr(struct hci_dev *hdev, const 
> > bdaddr_t *bdaddr)
> >  
> >  static int ath_setup(struct hci_uart *hu)
> >  {
> > +   struct tty_struct *tty = hu->tty;
> > +
> > BT_DBG("hu %p", hu);
> >  
> > +   /* tty driver should support operations to set RTS */
> > +   if (!tty->driver->ops->tiocmget || !tty->driver->ops->tiocmset)
> > +   return -EOPNOTSUPP;
> 
> -ENODEV might be more appropriate.
> 
> Johan

I'll split into 2 seperate patches. So, do I need to add stable tag on each
patch like below to be cherry-picked?

Cc:  # : 

I looked for a good example from mailing list but didn't find one.

Thanks,
Myungho

Re: 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 (posix-timers: Fix, division by zero bug). Problems with glibc.

[Paul Eggert]

Thomas Gleixner wrote:

Can you please verify whether the issue is fixed with 4.19.19?


It depends on what you mean by "verify". I looked at the Linux kernel source 
code and checked that the "posix-cpu-timers: Unbreak timer rearming" patch is in 
4.19.19 (but not 4.19.18) and in 4.20.6 (but not 4.20.5). I did not test Emacs's 
CPU profiler on these kernels, as I don't have them installed. I expect to 
upgrade soon to 4.20.6 (whenever Fedora 29 release does - 4.20.6 was submitted 
for testing a couple of days ago) and plan to give it a try then.

Re: [PATCH] mm: proc: smaps_rollup: Fix pss_locked calculation

[Sandeep Patil]

On Tue, Jan 29, 2019 at 04:52:21PM +0100, Vlastimil Babka wrote:
> On 1/29/19 1:15 AM, Andrew Morton wrote:
> > On Sun, 20 Jan 2019 17:10:49 -0800 Sandeep Patil  
> > wrote:
> > 
> >> The 'pss_locked' field of smaps_rollup was being calculated incorrectly
> >> as it accumulated the current pss everytime a locked VMA was found.
> >> 
> >> Fix that by making sure we record the current pss value before each VMA
> >> is walked. So, we can only add the delta if the VMA was found to be
> >> VM_LOCKED.
> >> 
> >> ...
> >>
> >> --- a/fs/proc/task_mmu.c
> >> +++ b/fs/proc/task_mmu.c
> >> @@ -709,6 +709,7 @@ static void smap_gather_stats(struct vm_area_struct 
> >> *vma,
> >>  #endif
> >>.mm = vma->vm_mm,
> >>};
> >> +  unsigned long pss;
> >>  
> >>smaps_walk.private = mss;
> >>  
> >> @@ -737,11 +738,12 @@ static void smap_gather_stats(struct vm_area_struct 
> >> *vma,
> >>}
> >>}
> >>  #endif
> >> -
> >> +  /* record current pss so we can calculate the delta after page walk */
> >> +  pss = mss->pss;
> >>/* mmap_sem is held in m_start */
> >>walk_page_vma(vma, _walk);
> >>if (vma->vm_flags & VM_LOCKED)
> >> -  mss->pss_locked += mss->pss;
> >> +  mss->pss_locked += mss->pss - pss;
> >>  }
> > 
> > This seems to be a rather obscure way of accumulating
> > mem_size_stats.pss_locked.  Wouldn't it make more sense to do this in
> > smaps_account(), wherever we increment mem_size_stats.pss?
> > 
> > It would be a tiny bit less efficient but I think that the code cleanup
> > justifies such a cost?
> 
> Yeah, Sandeep could you add 'bool locked' param to smaps_account() and check 
> it
> there? We probably don't need the whole vma param yet.

Agree, I will send -v2 shortly.

- ssp

Re: race between flush_to_ldisc and pty_cleanup

[Keun-O Park]

Hi,

02/01/2019 07:31 PM에 Maninder Singh 이(가) 쓴 글:
> Hi,
>
>> On Fri, Feb 01, 2019 at 07:03:26PM +0530, Maninder Singh wrote:
>>> Hi,
>>>
>>>
>>> There is some race condition between tty_port_put and flush_to_ldisc
>>> which lead to use after free case:
>>> (Kernel 4.1)
>>>
>>> [1403.5130] Unable to handle kernel paging request at virtual address 
>>> 6b6b6b83
>>> ...
>>> ...
>>> ...
>>>
>>> [1403.5132] [] (ldsem_down_read_trylock) from [] 
>>> (tty_ldisc_ref+0x24/0x60)
>>> [1403.5132] [] (tty_ldisc_ref) from [] 
>>> (flush_to_ldisc+0x6c/0x21c)
>>> [1403.5132]  r5:dbcd4a84 r4:
>>> [1403.5132] [] (flush_to_ldisc) from [] 
>>> (process_one_work+0x214/0x570)
>>> [1403.5132]  r10: r9:ddab r8:e3d6e000 r7: r6:e453f740 
>>> r5:cb37b780
>>> [1403.5132]  r4:dbcd4a84
>>> [1403.5132] [] (process_one_work) from [] 
>>> (worker_thread+0x60/0x580)
>>> [1403.5132]  r10:e453f740 r9:ddab r8:e453f764 r7:0088 r6:e453f740 
>>> r5:cb37b798
>>> [1403.5132]  r4:cb37b780
>>> [1403.5132] [] (worker_thread) from [] 
>>> (kthread+0xec/0x104)
>>> [1403.5132]  r10: r9: r8: r7:c004a274 r6:cb37b780 
>>> r5:d8a3fc80
>>> [1403.5132]  r4:
>>> [1403.5132] [] (kthread) from [] 
>>> (ret_from_fork+0x14/0x3c)
>>>
>>>
>>> for checking further we entered some debug prints and added delay in 
>>> flush_to_ldisc to reproduce
>>> and seems there is some issue with workqueue implementation of TTY:
>>>
>>> bool tty_buffer_cancel_work(struct tty_port *port)
>>> {
>>> bool ret;
>>> ret = cancel_work_sync(>buf.work); // Check return value of 
>>> cancel_work_sync
>>> pr_emerg("Work cancelled is 0x%x %pS %d\n", (unsigned 
>>> int)>buf.work, (void *)_RET_IP_, ret);
>>> return ret;
>>> }
>>>
>>> static void flush_to_ldisc(struct work_struct *work)
>>> {
>>> ...
>>> mdelay(100);   // Added Delay to reproduce race
>>>
>>> if (flag_work_cancel) {
>>> pr_emerg("scheduled work after stopping work %x\n", 
>>> (unsigned int)work);
>>>
>>> 
>>> }
>>>
>>> static void pty_cleanup(struct tty_struct *tty)
>>> {
>>> ...
>>> flag_work_cancel = 1;
>>> ...
>>> }
>>>
>>>
>>> [1403.4158]Work cancelled is dbcd4a84 tty_port_destroy+0x1c/0x6c  0   
>>> // Since return is 0 so no work is pending
>>>
>>> [1403.5129] scheduled work after stopping work dbcd4a84// Still same 
>>> work is scheduled after cancelled
>>> [1403.5130] Unable to handle kernel paging request at virtual address 
>>> 6b6b6b83   // Kernel OOPs occured because of use after free
>> Ok, after my initial "use a newer kernel" comment, this really does look
>> strange.  There has also been a lot of workqueue fixes and rework since
>> 4.1, and that might be the thing that fixes this issue here.
>>
>> However, are you sure you are not just calling flush_to_ldisc() directly
>> through some codepath somehow?  If you look at the stack in the
> Yes, there is no call path for flush_to_disc directly. It is all aligned with 
> kernel 4.1.
>
>
>> pr_emerg() message, where did it come from?  From the same workqueue
>> that you already stopped?
> We added debug prints to check "work" in pty_cleanup() & flush_to_ldisc
>
>> Testing on a newer kernel would be great, if possible.
> We are facing it hard, but currently we have 4.1 and able to reproduce on 
> that.
> Not really possible to have the latest kernel on the same target and may be 
> reproduce the same race.
> Tried to track for changes in the other stable branches, but no change looks 
> really relevant for this race.
> I might be wrong, please help if there is any commit related with this.
Please find & review the attached patch for this issue.

I think the tty which called pty_cleanup may be different from the tty
which called flush_to_ldisc.
Please check if those two are same or different. I don't think this is a
workqueue problem.
Thanks.

Best Regards,
Sahara

>
>> thanks,
>>
>> greg k-h
> Our initial debugging direction was with "tty" but looks some issue in 
> workqueue.
> Also, the most surprising looks to be the CANCEL and FLUSH to be occuring on 
> the same CORE in sequence.
> So, if the CANCEL really worked how can the flush_to_ldisc be scheduled.
>
> Thanks,
> Maninder Singh
>



Keun-O Park | Principal Software Engineer
Tel: +971 2 417 1417 | Mob: +971 55 260 7343
keun-o.p...@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.








From 3a65ec01f8849c3e11267794b9d1c70ef32d13e3 Mon Sep 17 00:00:00 2001
From: Sahara 
Date: Sun, 3 Feb 2019 09:27:28 +0400
Subject: 

[PATCH] PM / suspend: measure the time of filesystem syncing

[Harry Pan]

This patch gives the reader an intuitive metric of the time cost by
the kernel issuing a filesystem sync during suspend; although developer
can guess by the timestamp of next log or enable the ftrace power event
for manual calculation, this manner is easier to read and benefits the
automatic script.

Signed-off-by: Harry Pan 
---
 kernel/power/suspend.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 0bd595a0b610..f3b7c64f2242 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -550,6 +550,8 @@ static void suspend_finish(void)
 static int enter_state(suspend_state_t state)
 {
int error;
+   ktime_t start, end, elapsed;
+   unsigned int elapsed_msecs;
 
trace_suspend_resume(TPS("suspend_enter"), state, true);
if (state == PM_SUSPEND_TO_IDLE) {
@@ -570,9 +572,14 @@ static int enter_state(suspend_state_t state)
 
 #ifndef CONFIG_SUSPEND_SKIP_SYNC
trace_suspend_resume(TPS("sync_filesystems"), 0, true);
+   start = ktime_get_boottime();
pr_info("Syncing filesystems ... ");
ksys_sync();
-   pr_cont("done.\n");
+   end = ktime_get_boottime();
+   elapsed = ktime_sub(end, start);
+   elapsed_msecs = ktime_to_ms(elapsed);
+   pr_cont("(elapsed %d.%03d seconds) done.\n", elapsed_msecs / 1000,
+   elapsed_msecs % 1000);
trace_suspend_resume(TPS("sync_filesystems"), 0, false);
 #endif
 
-- 
2.18.1

[PATCH] Bluetooth: hci_ldisc: Add NULL check for tty set_termios operation

[Myungho Jung]

set_termios should not be NULL so return EOPNOTSUPP if tty driver does
not support the operation.

Reported-by: syzbot+a950165cbb86bdd02...@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung 
---
 drivers/bluetooth/hci_ldisc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index fbf7b4df23ab..44ac2e9494cc 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -474,10 +474,10 @@ static int hci_uart_tty_open(struct tty_struct *tty)
 
BT_DBG("tty %p", tty);
 
-   /* Error if the tty has no write op instead of leaving an exploitable
-* hole
+   /* Error if the tty has no write or set_termios op instead of leaving an
+* exploitable hole
 */
-   if (tty->ops->write == NULL)
+   if (tty->ops->write == NULL || tty->ops->set_termios == NULL)
return -EOPNOTSUPP;
 
hu = kzalloc(sizeof(struct hci_uart), GFP_KERNEL);
-- 
2.17.1

Re: [PATCH] atl1c: fix indentation issue on an if statement

[David Miller]

From: Colin King 
Date: Sat,  2 Feb 2019 11:41:29 +

> From: Colin Ian King 
> 
> An if statement is indented one level too deep, fix this by removing
> the extra tabs. Also add some spaces to the dev_warn arguments to clean
> up checkpatch warnings.
> 
> Signed-off-by: Colin Ian King 

Applied.

Re: [PATCH] atheros: atl2: fix an indentaion issue on a return statement

[David Miller]

From: Colin King 
Date: Sat,  2 Feb 2019 11:45:26 +

> From: Colin Ian King 
> 
> A return statment is not indented correctly, fix this by adding an
> extra tab.
> 
> Signed-off-by: Colin Ian King 

Applied.

Re: [PATCH] chelsio: clean up indentation issue

[David Miller]

From: Colin King 
Date: Sat,  2 Feb 2019 11:33:51 +

> From: Colin Ian King 
> 
> The assignment to size is indented too far, fix this and join
> two lines into one.
> 
> Signed-off-by: Colin Ian King 

Applied.

Re: [PATCH] bna: fix indentation issue on call to bfa_ioc_pf_failed

[David Miller]

From: Colin King 
Date: Sat,  2 Feb 2019 11:37:07 +

> From: Colin Ian King 
> 
> The call to bfa_ioc_pf_failed is indented too far, fix this by
> removing a tab.
> 
> Signed-off-by: Colin Ian King 

Applied.

Re: [PATCH v2 net-next 1/2] net: nixge: Separate ctrl and dma resources

[David Miller]

From: alex.willi...@ettus.com
Date: Thu, 31 Jan 2019 13:33:27 -0800

> From: Alex Williams 
> 
> The DMA engine is a separate entity altogether, and this allows the DMA
> controller's address to float elsewhere in the FPGA's map.
> 
> Signed-off-by: Alex Williams 

Applied.

Re: [PATCH v2 net-next 2/2] net: nixge: Update device-tree bindings with v3.00

[David Miller]

From: alex.willi...@ettus.com
Date: Thu, 31 Jan 2019 13:33:28 -0800

> From: Alex Williams 
> 
> Now the DMA engine is free to float elsewhere in the system map.
> 
> Signed-off-by: Alex Williams 

Applied.

Do the work

[Grace]

Want to retouch your photos? we can help you.

Deep etching or masking for your photos, or even adding clipping path.
Retouching also if needed.

Hopefully to start something for you soon.

Thanks,
Grace



















Fuldad


Altednburg

[PATCH] device.h: Add __cold to dev_ logging functions

[Joe Perches]

Add __cold to the dev_ logging functions similar to
the use of __cold in the generic printk function.

Using __cold moves all the dev_ logging functions
out-of-line possibly improving code locality and runtime
performance.

Signed-off-by: Joe Perches 
---
 include/linux/device.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index 5663003a95eb..df719f7fb5f0 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1381,28 +1381,28 @@ void device_link_remove(void *consumer, struct device 
*supplier);
 
 #ifdef CONFIG_PRINTK
 
-__printf(3, 0)
+__printf(3, 0) __cold
 int dev_vprintk_emit(int level, const struct device *dev,
 const char *fmt, va_list args);
-__printf(3, 4)
+__printf(3, 4) __cold
 int dev_printk_emit(int level, const struct device *dev, const char *fmt, ...);
 
-__printf(3, 4)
+__printf(3, 4) __cold
 void dev_printk(const char *level, const struct device *dev,
const char *fmt, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void _dev_emerg(const struct device *dev, const char *fmt, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void _dev_alert(const struct device *dev, const char *fmt, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void _dev_crit(const struct device *dev, const char *fmt, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void _dev_err(const struct device *dev, const char *fmt, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void _dev_warn(const struct device *dev, const char *fmt, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void _dev_notice(const struct device *dev, const char *fmt, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void _dev_info(const struct device *dev, const char *fmt, ...);
 
 #else

[PATCH] netdevice.h: Add __cold to netdev_ logging functions

[Joe Perches]

Add __cold to the netdev_ logging functions similar to
the use of __cold in the generic printk function.

Using __cold moves all the netdev_ logging functions
out-of-line possibly improving code locality and runtime
performance.

Signed-off-by: Joe Perches 
---
 include/linux/netdevice.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 579d132a75ff..b6c6d2fe17b0 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -4671,22 +4671,22 @@ static inline const char *netdev_reg_state(const struct 
net_device *dev)
return " (unknown)";
 }
 
-__printf(3, 4)
+__printf(3, 4) __cold
 void netdev_printk(const char *level, const struct net_device *dev,
   const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void netdev_emerg(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void netdev_alert(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void netdev_crit(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void netdev_err(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void netdev_warn(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void netdev_notice(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
 void netdev_info(const struct net_device *dev, const char *format, ...);
 
 #define netdev_level_once(level, dev, fmt, ...)\

Re: [PATCH] ipmr: ip6mr: Create new sockopt to clear mfc cache only

[David Miller]

From: Callum Sinclair 
Date: Thu, 31 Jan 2019 09:52:09 +1300

>  
> -/* Close the multicast socket, and clear the vif tables etc */
> -static void mroute_clean_tables(struct mr_table *mrt, bool all)
> +/* Clear the vif tables */
> +static void mroute_clean_cache(struct mr_table *mrt, bool all)
>  {
> - struct net *net = read_pnet(>net);
>   struct mr_mfc *c, *tmp;
>   struct mfc_cache *cache;
> - LIST_HEAD(list);
> - int i;
> -
> - /* Shut down all active vif entries */
> - for (i = 0; i < mrt->maxvif; i++) {
> - if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
> - continue;
> - vif_delete(mrt, i, 0, );
> - }
> - unregister_netdevice_many();
> + struct net *net = read_pnet(>net);

Please do not change the order of local variables like this, you're breaking
the correct reverse christmas tree ordering of longest to shortest line for
local variable declarations.

Thanks.

Re: [PATCH v2] Bluetooth: hci_uart: Switch pty driver to slave side in tty_set_termios()

[Myungho Jung]

On Sat, Feb 02, 2019 at 01:15:16PM +0100, Marcel Holtmann wrote:
> Hi Myungho,
> 
> > tty_set_termios() should be called with slave side of pty driver. So, If
> > tty driver is pty master, it needs to be switched to ->link.
> > 
> > Reported-by: syzbot+a950165cbb86bdd02...@syzkaller.appspotmail.com
> > Signed-off-by: Myungho Jung 
> > ---
> > drivers/bluetooth/hci_ldisc.c | 27 ++-
> > 1 file changed, 22 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> > index fbf7b4df23ab..0f6e70ea1dc3 100644
> > --- a/drivers/bluetooth/hci_ldisc.c
> > +++ b/drivers/bluetooth/hci_ldisc.c
> > @@ -299,10 +299,21 @@ static int hci_uart_send_frame(struct hci_dev *hdev, 
> > struct sk_buff *skb)
> > return 0;
> > }
> > 
> > +/* If pty master, return slave side */
> > +static struct tty_struct *hci_uart_get_real_tty(struct tty_struct *tty)
> > +{
> > +   if (tty->driver->type == TTY_DRIVER_TYPE_PTY &&
> > +   tty->driver->subtype == PTY_TYPE_MASTER)
> > +   tty->link;
> > +
> > +   return tty;
> > +}
> > +
> > /* Flow control or un-flow control the device */
> > void hci_uart_set_flow_control(struct hci_uart *hu, bool enable)
> > {
> > struct tty_struct *tty = hu->tty;
> > +   struct tty_struct *real_tty;
> > struct ktermios ktermios;
> > int status;
> > unsigned int set = 0;
> > @@ -314,11 +325,14 @@ void hci_uart_set_flow_control(struct hci_uart *hu, 
> > bool enable)
> > return;
> > }
> > 
> > +   /* termios should be set from slave side if tty driver is pty */
> > +   real_tty = hci_uart_get_real_tty(tty);
> > +
> > if (enable) {
> > /* Disable hardware flow control */
> > -   ktermios = tty->termios;
> > +   ktermios = real_tty->termios;
> > ktermios.c_cflag &= ~CRTSCTS;
> > -   status = tty_set_termios(tty, );
> > +   status = tty_set_termios(real_tty, );
> > BT_DBG("Disabling hardware flow control: %s",
> >status ? "failed" : "success");
> > 
> > @@ -350,9 +364,9 @@ void hci_uart_set_flow_control(struct hci_uart *hu, 
> > bool enable)
> > BT_DBG("Setting RTS: %s", status ? "failed" : "success");
> > 
> > /* Re-enable hardware flow control */
> > -   ktermios = tty->termios;
> > +   ktermios = real_tty->termios;
> > ktermios.c_cflag |= CRTSCTS;
> > -   status = tty_set_termios(tty, );
> > +   status = tty_set_termios(real_tty, );
> > BT_DBG("Enabling hardware flow control: %s",
> >status ? "failed" : "success");
> > }
> > @@ -367,9 +381,12 @@ void hci_uart_set_speeds(struct hci_uart *hu, unsigned 
> > int init_speed,
> > 
> > void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed)
> > {
> > -   struct tty_struct *tty = hu->tty;
> > +   struct tty_struct *tty;
> > struct ktermios ktermios;
> > 
> > +   /* termios should be set from slave side if tty driver is pty */
> > +   tty = hci_uart_get_real_tty(hu->tty);
> > +
> 
> didn’t we conclude that allowing the HCI line discipline on a PTY master 
> isn't worth the effort? The ptm_unix98_ops doesn’t have the .set_termios and 
> thus, just check that ops->set_termios is present in hci_uart_tty_open and if 
> not fail with EOPNOTSUPP like we do for missing ops->write.
> 
> Regards
> 
> Marcel
> 
Hi Marcel,

I thought there might be some cases that reach here even returning error in
hci_uart_tty_open(). Let me fix it from hci_uart_tty_open.

Thanks,
Myungho

Re: [PATCH v2 2/2] staging: erofs: complete POSIX ACL support

[Chao Yu]

Sorry for the delay due to business travel.

On 2019/1/29 2:30, Dan Carpenter wrote:
> On Tue, Jan 29, 2019 at 12:41:55AM +0800, Chao Yu wrote:
>> Hi Dan and Xiang,
>>
>> On 2019-1-28 21:48, Gao Xiang wrote:
>>> Hi Dan,
>>>
>>> On 2019/1/28 21:33, Dan Carpenter wrote:
 Hopefully, regular kmalloc() is enough.

 Do really need the erofs_kmalloc() function?  Regular kmalloc() has
 fault injection already.  Have you tried to use it?
>>
>> Yes, I think we'd better to use erofs_kmalloc(). :)
>>
>> Actually, fault injection in erofs_kmalloc only affect erofs module, we can
>> expect that the range of fault can be limited in erofs code, rather than 
>> whole
>> kernel, so the test point can be aimed at more accurately.
>>
> 
> Are you serious?  The standard fault injection doesn't do that???

Oh, I just realized the common fault injection can inject into specified
module with function granularity, sorry.

> 
> Please fix it instead of creating a duplicate better implementation
> which only your filesystem can use.  I would have thought that obviously

I agreed that it will be good to make common fault injection better,
covering more cases, so that it can benefit all modules which need fault
injection functionality. But rather than injecting kmalloc, there will be
other injection demands from erofs/f2fs, like injecting in the middle of
their specified function, how could we do that? Could you give us advice?

Thanks,

> any fault injection framework could at least be configured to test
> specific code...
> 
> regards,
> dan carpenter
> 
> 
> .
> 

Re: [PATCH net-next v5 12/12] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW

[Deepa Dinamani]

On Sat, Feb 2, 2019 at 9:15 AM Oliver Hartkopp  wrote:
>
> Hi all,
>
> On 02.02.19 16:34, Deepa Dinamani wrote:
> > Add new socket timeout options that are y2038 safe.
> (..)
> >
> > diff --git a/arch/alpha/include/uapi/asm/socket.h 
> > b/arch/alpha/include/uapi/asm/socket.h
> > index 9826d1db71d0..0d0fddb7e738 100644
> > --- a/arch/alpha/include/uapi/asm/socket.h
> > +++ b/arch/alpha/include/uapi/asm/socket.h
> > @@ -119,19 +119,25 @@
> >   #define SO_TIMESTAMPNS_NEW  64
> >   #define SO_TIMESTAMPING_NEW 65
> >
> > -#if !defined(__KERNEL__)
> > +#define SO_RCVTIMEO_NEW 66
> > +#define SO_SNDTIMEO_NEW 67
> >
> > -#define  SO_RCVTIMEO SO_RCVTIMEO_OLD
> > -#define  SO_SNDTIMEO SO_SNDTIMEO_OLD
> > +#if !defined(__KERNEL__)
> >
> >   #if __BITS_PER_LONG == 64
> >   #define SO_TIMESTAMPSO_TIMESTAMP_OLD
> >   #define SO_TIMESTAMPNS  SO_TIMESTAMPNS_OLD
> >   #define SO_TIMESTAMPING SO_TIMESTAMPING_OLD
> > +
> > +#define SO_RCVTIMEO  SO_RCVTIMEO_OLD
> > +#define SO_SNDTIMEO  SO_SNDTIMEO_OLD
>
> Maybe I'm a bit late in this discussion as you are already in v5 ...
>
> I can see patches making the transition in different steps where it
> might be helpful to name them *_OLD and *_NEW to understand the patches.
>
> But in the end the naming stays in the kernel for a very long time and I
> remember myself (in early years) to name things 'new', 'new2', 'new3'.
>
> In fact SO_TIMESTAMP_OLD should be named SO_TIMESTAMP32 and
> SO_TIMESTAMP_NEW should be named SO_TIMESTAMP64.

Hmm. SO_TIMESTAMP_OLD uses 64-bit time_t on a 64 bit machine. In fact,
there is no difference between the two options on a 64 bit machine. So
using  SO_TIMESTAMP_32 is just wrong.

Likewise, SO_TIMESTAMP_64 naming somehow indicates that the existing
one was not, and that is also not true on a 64-bit machine.

Further, userspace will still continue to use SO_TIMESTAMP and the
macros take care of which option to select internally.

Moreover, these macros have been there for more than ten years
(introduced before 2.4) and there has been no change. I doubt you will
ever have NEW2.
I think this argument is similar to saying don’t name these macros
SO_TIMESTAMP because there might be SO_TIMESTAMP1 some day. There is
never a perfect name. SO_TIMESTAMPING is also not really descriptive.

> Especially as it tells you what is 'inside', the naming of these new 
> introduced constants should be replaced with *32 and *64 names.
> The documentation and the other comments still fit perfectly then.

I would prefer not to do this, for reasons mentioned above. Since you
point out that it is easier to use this naming for intermediate steps,
I suggest that we leave the series as it is.
If you feel strongly to post a follow-on renaming patch, you could
discuss it with the subsystem maintainers, if you think there is a
correct but more descriptive naming.

-Deepa

> Regards,
> Oliver

Did you send the images?

[Grace]

Want to retouch your photos? we can help you.

Deep etching or masking for your photos, or even adding clipping path.
Retouching also if needed.

Hopefully to start something for you soon.

Thanks,
Grace














Pforzdeim


Landau

Still need this?

[Grace]

Want to retouch your photos? we can help you.

Deep etching or masking for your photos, or even adding clipping path.
Retouching also if needed.

Hopefully to start something for you soon.

Thanks,
Grace

















Dordmagen


Maindtal

[PATCH] Rename include/{uapi => }/asm-generic/shmparam.h really

[Masahiro Yamada]

Commit 36c0f7f0f899 ("arch: unexport asm/shmparam.h for all
architectures") is different from the patch I submitted.

My patch is this:
https://lore.kernel.org/lkml/1546904307-11124-1-git-send-email-yamada.masah...@socionext.com/T/#u

The file renaming part:

  rename include/{uapi => }/asm-generic/shmparam.h (100%)

was lost when it was picked up.

I think it was an accident because Andrew did not say anything.

Fixes: 36c0f7f0f899 ("arch: unexport asm/shmparam.h for all architectures")
Signed-off-by: Masahiro Yamada 
Cc: Andrew Morton 
---

 include/{uapi => }/asm-generic/shmparam.h | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename include/{uapi => }/asm-generic/shmparam.h (100%)

diff --git a/include/uapi/asm-generic/shmparam.h 
b/include/asm-generic/shmparam.h
similarity index 100%
rename from include/uapi/asm-generic/shmparam.h
rename to include/asm-generic/shmparam.h
-- 
2.7.4

Re: [PATCH 9/9] [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

[Vasily Khoruzhick]

On Thu, Oct 18, 2018 at 4:31 AM Laurent Pinchart
 wrote:

> Given that the tolerance is a property of the panel or bridge, I agree with
> Daniel that it should be implemented there, or at least in cooperation with
> drm_panel and drm_bridge.

Clock tolerance is not specified in ANX6345 datasheet.

> Semi-related information, I think the CEA and VESA standards allow a 0.5%
> clock tolerance. What is the maximum clock frequency deviation required for
> this platform ?

This particular platform requires ~1% deviation.

E.g. on Pinebook with 768p panel: requested clock: 73.0 MHz, real
clock: 72.296296 MHz (0.96%)
on Pinebook with 1080p panel: requested clock: 138.5 MHz, real clock:
138.461538 MHz (0.03%)

So unfortunately 0.5% is not enough.

Regards,
Vasily

[PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family

[Dan Williams]

As Dexuan reports the NVDIMM_FAMILY_HYPERV platform is incompatible with
the existing Linux namespace implementation because it uses
NSLABEL_FLAG_LOCAL for x1-width PMEM interleave sets. Quirk it as an
platform / DIMM that does not provide BLK-aperture access. Allow the
libnvdimm core to assume no potential for aliasing. In case other
implementations make the same mistake, provide a "noblk" module
parameter to force-enable the quirk.

Link: 
https://lkml.kernel.org/r/pu1p153mb0169977604493b82b662a01cbf...@pu1p153mb0169.apcp153.prod.outlook.com
Reported-by: Dexuan Cui 
Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c|4 
 drivers/nvdimm/dimm_devs.c  |7 ++-
 drivers/nvdimm/label.c  |3 +++
 drivers/nvdimm/namespace_devs.c |6 ++
 drivers/nvdimm/region_devs.c|7 +++
 include/linux/libnvdimm.h   |2 ++
 6 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 4a7e8b1fa43b..811c399a3a76 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2016,6 +2016,10 @@ static int acpi_nfit_register_dimms(struct 
acpi_nfit_desc *acpi_desc)
cmd_mask |= nfit_mem->dsm_mask & 
NVDIMM_STANDARD_CMDMASK;
}
 
+   /* Quirk to ignore LOCAL for labels on HYPERV DIMMs */
+   if (nfit_mem->family == NVDIMM_FAMILY_HYPERV)
+   set_bit(NDD_NOBLK, );
+
if (test_bit(NFIT_MEM_LSR, _mem->flags)) {
set_bit(ND_CMD_GET_CONFIG_SIZE, _mask);
set_bit(ND_CMD_GET_CONFIG_DATA, _mask);
diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
index 4890310df874..186d63f16434 100644
--- a/drivers/nvdimm/dimm_devs.c
+++ b/drivers/nvdimm/dimm_devs.c
@@ -11,6 +11,7 @@
  * General Public License for more details.
  */
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,10 @@
 
 static DEFINE_IDA(dimm_ida);
 
+static bool noblk;
+module_param(noblk, bool, 0444);
+MODULE_PARM_DESC(noblk, "force disable BLK / local alias support");
+
 /*
  * Retrieve bus and dimm handle and return if this bus supports
  * get_config_data commands
@@ -551,7 +556,7 @@ struct nvdimm *__nvdimm_create(struct nvdimm_bus 
*nvdimm_bus,
 
nvdimm->dimm_id = dimm_id;
nvdimm->provider_data = provider_data;
-   nvdimm->flags = flags;
+   nvdimm->flags = flags | noblk ? (1 << NDD_NOBLK) : 0;
nvdimm->cmd_mask = cmd_mask;
nvdimm->num_flush = num_flush;
nvdimm->flush_wpq = flush_wpq;
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index 6d6e9a12150b..f3d753d3169c 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -392,6 +392,7 @@ int nd_label_reserve_dpa(struct nvdimm_drvdata *ndd)
return 0; /* no label, nothing to reserve */
 
for_each_clear_bit_le(slot, free, nslot) {
+   struct nvdimm *nvdimm = to_nvdimm(ndd->dev);
struct nd_namespace_label *nd_label;
struct nd_region *nd_region = NULL;
u8 label_uuid[NSLABEL_UUID_LEN];
@@ -406,6 +407,8 @@ int nd_label_reserve_dpa(struct nvdimm_drvdata *ndd)
 
memcpy(label_uuid, nd_label->uuid, NSLABEL_UUID_LEN);
flags = __le32_to_cpu(nd_label->flags);
+   if (test_bit(NDD_NOBLK, >flags))
+   flags &= ~NSLABEL_FLAG_LOCAL;
nd_label_gen_id(_id, label_uuid, flags);
res = nvdimm_allocate_dpa(ndd, _id,
__le64_to_cpu(nd_label->dpa),
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 4b077555ac70..3677b0c4a33d 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -2492,6 +2492,12 @@ static int init_active_labels(struct nd_region 
*nd_region)
if (!label_ent)
break;
label = nd_label_active(ndd, j);
+   if (test_bit(NDD_NOBLK, >flags)) {
+   u32 flags = __le32_to_cpu(label->flags);
+
+   flags &= ~NSLABEL_FLAG_LOCAL;
+   label->flags = __cpu_to_le32(flags);
+   }
label_ent->label = label;
 
mutex_lock(_mapping->lock);
diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index e2818f94f292..3b58baa44b5c 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -1003,6 +1003,13 @@ static struct nd_region *nd_region_create(struct 
nvdimm_bus *nvdimm_bus,
 
if (test_bit(NDD_UNARMED, >flags))
ro = 1;
+
+   if (test_bit(NDD_NOBLK, >flags)
+   && dev_type == _blk_device_type) {
+  

Re: linux-next: tracebacks in workqueue.c/__flush_work()

[Tetsuo Handa]

(Adding Chris Metcalf and Rusty Russell.)

If NR_CPUS == 1 due to CONFIG_SMP=n, for_each_cpu(cpu, _work) loop does not
evaluate "struct cpumask has_work" modified by cpumask_set_cpu(cpu, _work) 
at
previous for_each_online_cpu() loop. Guenter Roeck found a problem among three
commits listed below.

  Commit 5fbc461636c32efd ("mm: make lru_add_drain_all() selective")
  expects that has_work is evaluated by for_each_cpu().

  Commit 2d3854a37e8b767a ("cpumask: introduce new API, without changing 
anything")
  assumes that for_each_cpu() does not need to evaluate has_work.

  Commit 4d43d395fed12463 ("workqueue: Try to catch flush_work() without 
INIT_WORK().")
  expects that has_work is evaluated by for_each_cpu().

What should we do? Do we explicitly evaluate has_mask if NR_CPUS == 1 ?

 mm/swap.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/swap.c b/mm/swap.c
index 4929bc1..5f07734 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -698,7 +698,8 @@ void lru_add_drain_all(void)
}
 
for_each_cpu(cpu, _work)
-   flush_work(_cpu(lru_add_drain_work, cpu));
+   if (NR_CPUS > 1 || cpumask_test_cpu(cpu, _work))
+   flush_work(_cpu(lru_add_drain_work, cpu));
 
mutex_unlock();
 }

On 2019/02/03 7:20, Guenter Roeck wrote:
> Commit "workqueue: Try to catch flush_work() without INIT_WORK()" added
> a warning if flush_work() is called without worker function.
> 
> This results in the following tracebacks, typically observed during
> system shutdown.
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 101 at kernel/workqueue.c:3018 __flush_work+0x2a4/0x2e0
> Modules linked in:
> CPU: 0 PID: 101 Comm: umount Not tainted 5.0.0-rc4-next-20190201 #1
>fc0007dcbd18  fc3338a0 fc3517d4
>fc3517d4 fce56c98 fce56c98 fcebc1d8
>fcec0bd8 a8024010 0bca 
>fc3d3ea4 fce56c98 fce56c60 fcebc1d8
>fcec0bd8  0001 
>fc000782d520  fc44ef50 fc0007c4b540
> Trace:
> [] __warn+0x160/0x190
> [] __flush_work+0x2a4/0x2e0
> [] __flush_work+0x2a4/0x2e0
> [] lru_add_drain_all+0xe4/0x190
> [] shrink_dcache_sb+0x70/0xb0
> [] invalidate_bh_lru+0x44/0x80
> [] on_each_cpu_cond+0x5c/0x90
> [] invalidate_bh_lru+0x0/0x80
> [] invalidate_bdev+0x3c/0x70
> [] reconfigure_super+0x178/0x2c0
> [] ksys_umount+0x664/0x680
> [] sys_umount+0x1c/0x30
> [] entSys+0xa4/0xc0
> [] entSys+0xa4/0xc0
> 
> ---[ end trace 613cea34708701f1 ]---
> 
> The problem is seen with several (but not all) architectures. Affected
> architectures/platforms are:
> alpha
> arm:versatilepb
> m68k
> mips, mips64 (boot from IDE drive or MMC, SMP disabled)
> parisc (nosmp builds)
> sparc, sparc64 (nosmp builds)
> 
> There may be others; several of my tests fail with build failures.
> 
> If/when it is seen, the problem is persistent.
> 
> Common denominator seems to be that SMP is disabled. It does appear that
> for_each_cpu() ignores the mask for nosmp builds, but I don't really
> understand why.
> 
> Guenter
> 

[PATCH v2 2/2] linux/kernel.h: split *_MAX and *_MIN macros into

[Masahiro Yamada]

 tends to be cluttered because we often put various
sort of unrelated stuff in it. So, we have split out a sensible chunk
of code into a separate header from time to time.

This commit splits out the *_MAX and *_MIN defines.

The standard header  contains various MAX, MIN constants
including numerial limits. [1]

I think it makes sense to move in-kernel MAX, MIN constants into
include/linux/limits.h.

We already have include/uapi/linux/limits.h to contain some user-space
constants. I changed its include guard to _UAPI_LINUX_LIMITS_H. This
change has no impact to the user-space because scripts/headers_install.sh
rips off the '_UAPI' prefix from the include guards of exported headers.

[1] http://pubs.opengroup.org/onlinepubs/009604499/basedefs/limits.h.html

Signed-off-by: Masahiro Yamada 
Cc: Alex Elder 
Cc: Alexey Dobriyan 
Cc: Zhang Yanmin 
---

Changes in v2: None

 include/linux/kernel.h  | 29 +
 include/linux/limits.h  | 36 
 include/uapi/linux/limits.h |  4 ++--
 3 files changed, 39 insertions(+), 30 deletions(-)
 create mode 100644 include/linux/limits.h

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index afc19d9..b80b965 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -4,6 +4,7 @@
 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -16,34 +17,6 @@
 #include 
 #include 
 
-#define USHRT_MAX  ((unsigned short)~0U)
-#define SHRT_MAX   ((short)(USHRT_MAX>>1))
-#define SHRT_MIN   ((short)(-SHRT_MAX - 1))
-#define INT_MAX((int)(~0U>>1))
-#define INT_MIN(-INT_MAX - 1)
-#define UINT_MAX   (~0U)
-#define LONG_MAX   ((long)(~0UL>>1))
-#define LONG_MIN   (-LONG_MAX - 1)
-#define ULONG_MAX  (~0UL)
-#define LLONG_MAX  ((long long)(~0ULL>>1))
-#define LLONG_MIN  (-LLONG_MAX - 1)
-#define ULLONG_MAX (~0ULL)
-#define SIZE_MAX   (~(size_t)0)
-#define PHYS_ADDR_MAX  (~(phys_addr_t)0)
-
-#define U8_MAX ((u8)~0U)
-#define S8_MAX ((s8)(U8_MAX>>1))
-#define S8_MIN ((s8)(-S8_MAX - 1))
-#define U16_MAX((u16)~0U)
-#define S16_MAX((s16)(U16_MAX>>1))
-#define S16_MIN((s16)(-S16_MAX - 1))
-#define U32_MAX((u32)~0U)
-#define S32_MAX((s32)(U32_MAX>>1))
-#define S32_MIN((s32)(-S32_MAX - 1))
-#define U64_MAX((u64)~0ULL)
-#define S64_MAX((s64)(U64_MAX>>1))
-#define S64_MIN((s64)(-S64_MAX - 1))
-
 #define STACK_MAGIC0xdeadbeef
 
 /**
diff --git a/include/linux/limits.h b/include/linux/limits.h
new file mode 100644
index 000..76afcd2
--- /dev/null
+++ b/include/linux/limits.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_LIMITS_H
+#define _LINUX_LIMITS_H
+
+#include 
+#include 
+
+#define USHRT_MAX  ((unsigned short)~0U)
+#define SHRT_MAX   ((short)(USHRT_MAX >> 1))
+#define SHRT_MIN   ((short)(-SHRT_MAX - 1))
+#define INT_MAX((int)(~0U >> 1))
+#define INT_MIN(-INT_MAX - 1)
+#define UINT_MAX   (~0U)
+#define LONG_MAX   ((long)(~0UL >> 1))
+#define LONG_MIN   (-LONG_MAX - 1)
+#define ULONG_MAX  (~0UL)
+#define LLONG_MAX  ((long long)(~0ULL >> 1))
+#define LLONG_MIN  (-LLONG_MAX - 1)
+#define ULLONG_MAX (~0ULL)
+#define SIZE_MAX   (~(size_t)0)
+#define PHYS_ADDR_MAX  (~(phys_addr_t)0)
+
+#define U8_MAX ((u8)~0U)
+#define S8_MAX ((s8)(U8_MAX >> 1))
+#define S8_MIN ((s8)(-S8_MAX - 1))
+#define U16_MAX((u16)~0U)
+#define S16_MAX((s16)(U16_MAX >> 1))
+#define S16_MIN((s16)(-S16_MAX - 1))
+#define U32_MAX((u32)~0U)
+#define S32_MAX((s32)(U32_MAX >> 1))
+#define S32_MIN((s32)(-S32_MAX - 1))
+#define U64_MAX((u64)~0ULL)
+#define S64_MAX((s64)(U64_MAX >> 1))
+#define S64_MIN((s64)(-S64_MAX - 1))
+
+#endif /* _LINUX_LIMITS_H */
diff --git a/include/uapi/linux/limits.h b/include/uapi/linux/limits.h
index c3547f0..6bcbe30 100644
--- a/include/uapi/linux/limits.h
+++ b/include/uapi/linux/limits.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _LINUX_LIMITS_H
-#define _LINUX_LIMITS_H
+#ifndef _UAPI_LINUX_LIMITS_H
+#define _UAPI_LINUX_LIMITS_H
 
 #define NR_OPEN1024
 
-- 
2.7.4

[PATCH v2 1/2] linux/kernel.h: use 'short' to define USHRT_MAX, SHRT_MAX, SHRT_MIN

[Masahiro Yamada]

The commit log of 44f564a4bf6a ("ipc: add definitions of USHORT_MAX
and others") did not explain why it used (s16) and (u16) instead of
(short) and (unsigned short).

Let's use (short) and (unsigned short), which is more sensible, and
more consistent with the other MAX/MIN defines.

As you see in include/uapi/asm-generic/int-ll64.h, s16/u16 are
typedef'ed as signed/unsigned short. So, this commit does not have
a functional change.

Remove the unneeded parentheses around ~0U while we are here.

Signed-off-by: Masahiro Yamada 
Cc: Alexey Dobriyan 
Cc: Zhang Yanmin 
---

Changes in v2:
  - Remove unneeded parentheses

 include/linux/kernel.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 8f0e68e..afc19d9 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -16,9 +16,9 @@
 #include 
 #include 
 
-#define USHRT_MAX  ((u16)(~0U))
-#define SHRT_MAX   ((s16)(USHRT_MAX>>1))
-#define SHRT_MIN   ((s16)(-SHRT_MAX - 1))
+#define USHRT_MAX  ((unsigned short)~0U)
+#define SHRT_MAX   ((short)(USHRT_MAX>>1))
+#define SHRT_MIN   ((short)(-SHRT_MAX - 1))
 #define INT_MAX((int)(~0U>>1))
 #define INT_MIN(-INT_MAX - 1)
 #define UINT_MAX   (~0U)
-- 
2.7.4

Re: [PATCH 1/2] linux/kernel.h: use 'short' to define USHRT_MAX, SHRT_MAX, SHRT_MIN

[Masahiro Yamada]

On Sun, Feb 3, 2019 at 1:33 AM Alexey Dobriyan  wrote:
>
> On Sun, Feb 03, 2019 at 01:06:24AM +0900, Masahiro Yamada wrote:
> > The log of commit 44f564a4bf6a ("ipc: add definitions of USHORT_MAX
> > and others") did not explain why it used (s16) and (u16) instead of
> > (short) and (unsigned short).
> >
> > Let's use (short) and (unsigned short), which is more sensible, and
> > more consistent with the other MAX/MIN defines.
> >
> > As you see in include/uapi/asm-generic/int-ll64.h, s16/u16 are
> > typedef'ed as signed/unsigned short. So, this commit does not have
> > a functional change.
>
> > -#define USHRT_MAX((u16)(~0U))
> > -#define SHRT_MAX ((s16)(USHRT_MAX>>1))
> > -#define SHRT_MIN ((s16)(-SHRT_MAX - 1))
> > +#define USHRT_MAX((unsigned short)(~0U))
>  ^   ^
>  +---+
>unnecessary ()


Thanks, I will remove it in v2.




> > +#define SHRT_MAX ((short)(USHRT_MAX>>1))
> > +#define SHRT_MIN ((short)(-SHRT_MAX - 1))
>
> "short" and "unsigned short" are probably the most useless C types.
> I doubt their usage should be promoted.



-- 
Best Regards
Masahiro Yamada

[PATCH] Bluetooth: Fix decrementing reference count twice in releasing socket

[Myungho Jung]

When releasing socket, it is possible to enter hci_sock_release() and
hci_sock_dev_event(HCI_DEV_UNREG) at the same time in different thread.
The reference count of hdev should be decremented only once from one of
them but if storing hdev to local variable in hci_sock_release() before
detached from socket and setting to NULL in hci_sock_dev_event(),
hci_dev_put(hdev) is unexpectedly called twice. This is resolved by
referencing hdev from socket after bt_sock_unlink() in
hci_sock_release().

Reported-by: syzbot+fdc3f4efff43b...@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung 
---
 net/bluetooth/hci_sock.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 1506e1632394..d4e2a166ae17 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -831,8 +831,6 @@ static int hci_sock_release(struct socket *sock)
if (!sk)
return 0;
 
-   hdev = hci_pi(sk)->hdev;
-
switch (hci_pi(sk)->channel) {
case HCI_CHANNEL_MONITOR:
atomic_dec(_promisc);
@@ -854,6 +852,7 @@ static int hci_sock_release(struct socket *sock)
 
bt_sock_unlink(_sk_list, sk);
 
+   hdev = hci_pi(sk)->hdev;
if (hdev) {
if (hci_pi(sk)->channel == HCI_CHANNEL_USER) {
/* When releasing a user channel exclusive access,
-- 
2.17.1

Re: [PATCH v2 1/2] rtc: add AB-RTCMC-32.768kHz-EOZ9 RTC support

[Artem Panfilov]

Hi Alexandre,

On 31.01.2019 0:48, Alexandre Belloni wrote:

>> +#endif /* CONFIG_RTC_DRV_ABEOZ9_HWMON */
> This comment is not correct

Thank you for your remarks. Can I add HMON support as Kconfig build option?

Regards,
Artem

[PATCH-next] drm/sun4i: Use PTR_ERR_OR_ZERO in sun8i_phy_clk_create()

[Christopher Diaz Riveros]

Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Signed-off-by: Christopher Diaz Riveros 
---
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c 
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
index a4d31fe3abff..d52f581797f0 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
@@ -171,8 +171,6 @@ int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct 
device *dev,
priv->hw.init = 
 
phy->clk_phy = devm_clk_register(dev, >hw);
-   if (IS_ERR(phy->clk_phy))
-   return PTR_ERR(phy->clk_phy);
 
-   return 0;
+   return PTR_ERR_OR_ZERO(phy->clk_phy);
 }
-- 
2.20.1

[PATCH v2 0/9] Ingenic JZ4780 NAND patchset v2

[Paul Cercueil]

Hi,

As requested by Boris, I added a patch to move all the Ingenic NAND
drivers to their own directory.

In this V2 I added support for the JZ4740 SoC. The combo of the
jz4780-nemc, jz4780-nand and jz4740-bch now obsolete the old and dusty
jz4740-nand driver.

To support the only upstream JZ4740-based board we have, the Ben
Nanonote, I added an option to specify the OOB layout of that device
from a device property string.

Finally, I dropped the last two patches that moved the platform NAND
code to devicetree; I will upstream them as part of a different
patchset.

Cheers,
-Paul

[PATCH v2 9/9] mtd: rawnand: jz4780-bch: Add support for the JZ4740

[Paul Cercueil]

Add the backend code for the jz4780-bch driver to support the JZ4740
SoC from Ingenic.

Signed-off-by: Paul Cercueil 
---

Changes:

v2: New patch

 drivers/mtd/nand/raw/ingenic/Makefile |   2 +-
 drivers/mtd/nand/raw/ingenic/jz4740_bch.c | 173 ++
 .../mtd/nand/raw/ingenic/jz4780_bch_common.c  |   1 +
 .../nand/raw/ingenic/jz4780_bch_internal.h|   1 +
 4 files changed, 176 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/raw/ingenic/jz4740_bch.c

diff --git a/drivers/mtd/nand/raw/ingenic/Makefile 
b/drivers/mtd/nand/raw/ingenic/Makefile
index f38b467490cf..d16c96113a93 100644
--- a/drivers/mtd/nand/raw/ingenic/Makefile
+++ b/drivers/mtd/nand/raw/ingenic/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_JZ4780) += jz4780_nand.o jz4780_bch_common.o \
-jz4780_bch.o jz4725b_bch.o
+jz4780_bch.o jz4725b_bch.o jz4740_bch.o
diff --git a/drivers/mtd/nand/raw/ingenic/jz4740_bch.c 
b/drivers/mtd/nand/raw/ingenic/jz4740_bch.c
new file mode 100644
index ..61ea109cee9d
--- /dev/null
+++ b/drivers/mtd/nand/raw/ingenic/jz4740_bch.c
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * JZ4740 backend code for the jz4780-bch driver
+ * based on jz4740-nand.c
+ *
+ * Copyright (c) 2019 Paul Cercueil 
+ */
+
+#include 
+#include 
+
+#include "jz4780_bch.h"
+#include "jz4780_bch_internal.h"
+
+#define JZ_REG_NAND_ECC_CTRL   0x00
+#define JZ_REG_NAND_DATA   0x04
+#define JZ_REG_NAND_PAR0   0x08
+#define JZ_REG_NAND_PAR1   0x0C
+#define JZ_REG_NAND_PAR2   0x10
+#define JZ_REG_NAND_IRQ_STAT   0x14
+#define JZ_REG_NAND_IRQ_CTRL   0x18
+#define JZ_REG_NAND_ERR(x) (0x1C + ((x) << 2))
+
+#define JZ_NAND_ECC_CTRL_PAR_READY BIT(4)
+#define JZ_NAND_ECC_CTRL_ENCODING  BIT(3)
+#define JZ_NAND_ECC_CTRL_RSBIT(2)
+#define JZ_NAND_ECC_CTRL_RESET BIT(1)
+#define JZ_NAND_ECC_CTRL_ENABLEBIT(0)
+
+#define JZ_NAND_STATUS_ERR_COUNT   (BIT(31) | BIT(30) | BIT(29))
+#define JZ_NAND_STATUS_PAD_FINISH  BIT(4)
+#define JZ_NAND_STATUS_DEC_FINISH  BIT(3)
+#define JZ_NAND_STATUS_ENC_FINISH  BIT(2)
+#define JZ_NAND_STATUS_UNCOR_ERROR BIT(1)
+#define JZ_NAND_STATUS_ERROR   BIT(0)
+
+static const uint8_t empty_block_ecc[] = {
+   0xcd, 0x9d, 0x90, 0x58, 0xf4, 0x8b, 0xff, 0xb7, 0x6f
+};
+
+static void jz4740_bch_init(struct jz4780_bch *bch, bool encode)
+{
+   uint32_t reg;
+
+   /* Clear interrupt status */
+   writel(0, bch->base + JZ_REG_NAND_IRQ_STAT);
+
+   /* Initialize and enable BCH */
+   reg = readl(bch->base + JZ_REG_NAND_ECC_CTRL);
+   reg |= JZ_NAND_ECC_CTRL_RESET;
+   reg |= JZ_NAND_ECC_CTRL_ENABLE;
+   reg |= JZ_NAND_ECC_CTRL_RS;
+   if (encode)
+   reg |= JZ_NAND_ECC_CTRL_ENCODING;
+   else
+   reg &= ~JZ_NAND_ECC_CTRL_ENCODING;
+
+   writel(reg, bch->base + JZ_REG_NAND_ECC_CTRL);
+}
+
+static int jz4740_bch_calculate(struct jz4780_bch *bch,
+   struct jz4780_bch_params *params,
+   const u8 *buf, u8 *ecc_code)
+{
+   uint32_t reg, status;
+   unsigned int timeout = 1000;
+   int i;
+
+   jz4740_bch_init(bch, true);
+
+   do {
+   status = readl(bch->base + JZ_REG_NAND_IRQ_STAT);
+   } while (!(status & JZ_NAND_STATUS_ENC_FINISH) && --timeout);
+
+   if (timeout == 0)
+   return -ETIMEDOUT;
+
+   reg = readl(bch->base + JZ_REG_NAND_ECC_CTRL);
+   reg &= ~JZ_NAND_ECC_CTRL_ENABLE;
+   writel(reg, bch->base + JZ_REG_NAND_ECC_CTRL);
+
+   for (i = 0; i < params->bytes; ++i)
+   ecc_code[i] = readb(bch->base + JZ_REG_NAND_PAR0 + i);
+
+   /* If the written data is completely 0xff, we also want to write 0xff as
+* ecc, otherwise we will get in trouble when doing subpage writes.
+*/
+   if (memcmp(ecc_code, empty_block_ecc, ARRAY_SIZE(empty_block_ecc)) == 0)
+   memset(ecc_code, 0xff, ARRAY_SIZE(empty_block_ecc));
+
+   return 0;
+}
+
+static void jz_nand_correct_data(uint8_t *buf, int index, int mask)
+{
+   int offset = index & 0x7;
+   uint16_t data;
+
+   index += (index >> 3);
+
+   data = buf[index];
+   data |= buf[index + 1] << 8;
+
+   mask ^= (data >> offset) & 0x1ff;
+   data &= ~(0x1ff << offset);
+   data |= (mask << offset);
+
+   buf[index] = data & 0xff;
+   buf[index + 1] = (data >> 8) & 0xff;
+}
+
+static int jz4740_bch_correct(struct jz4780_bch *bch,
+ struct jz4780_bch_params *params,
+ u8 *buf, u8 *ecc_code)
+{
+   int i, error_count, index;
+   uint32_t reg, status, error;
+   unsigned int timeout = 1000;
+
+   jz4740_bch_init(bch, false);
+
+   for (i = 0; i < params->bytes; ++i)
+   

[PATCH v2 7/9] mtd: rawnand: jz4780-bch: Separate top-level and SoC specific code

[Paul Cercueil]

The jz4780-nand driver uses an API provided by the jz4780-bch driver.
This makes it difficult to support other SoCs in the jz4780-bch driver.
To work around this, we separate the API functions from the SoC-specific
code, so that these API functions are SoC-agnostic.

Signed-off-by: Paul Cercueil 
---

Changes:

v2: Add an optional .probe() callback. It is used for instance to set
the clock rate in the JZ4780 backend.

 drivers/mtd/nand/raw/ingenic/Makefile |   3 +-
 drivers/mtd/nand/raw/ingenic/jz4780_bch.c | 170 ++---
 .../mtd/nand/raw/ingenic/jz4780_bch_common.c  | 177 ++
 .../nand/raw/ingenic/jz4780_bch_internal.h|  35 
 4 files changed, 230 insertions(+), 155 deletions(-)
 create mode 100644 drivers/mtd/nand/raw/ingenic/jz4780_bch_common.c
 create mode 100644 drivers/mtd/nand/raw/ingenic/jz4780_bch_internal.h

diff --git a/drivers/mtd/nand/raw/ingenic/Makefile 
b/drivers/mtd/nand/raw/ingenic/Makefile
index 44c2ca053d24..c308062a6620 100644
--- a/drivers/mtd/nand/raw/ingenic/Makefile
+++ b/drivers/mtd/nand/raw/ingenic/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
-obj-$(CONFIG_MTD_NAND_JZ4780) += jz4780_nand.o jz4780_bch.o
+obj-$(CONFIG_MTD_NAND_JZ4780) += jz4780_nand.o jz4780_bch_common.o \
+jz4780_bch.o
diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_bch.c 
b/drivers/mtd/nand/raw/ingenic/jz4780_bch.c
index 7e4e5e627603..1b4486c38c6b 100644
--- a/drivers/mtd/nand/raw/ingenic/jz4780_bch.c
+++ b/drivers/mtd/nand/raw/ingenic/jz4780_bch.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * JZ4780 BCH controller
+ * JZ4780 backend code for the jz4780-bch driver
  *
  * Copyright (c) 2015 Imagination Technologies
  * Author: Alex Smith 
@@ -8,18 +8,13 @@
 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
+#include 
 
 #include "jz4780_bch.h"
+#include "jz4780_bch_internal.h"
 
 #define BCH_BHCR   0x0
 #define BCH_BHCCR  0x8
@@ -62,13 +57,6 @@
 /* Timeout for BCH calculation/correction. */
 #define BCH_TIMEOUT_US 10
 
-struct jz4780_bch {
-   struct device *dev;
-   void __iomem *base;
-   struct clk *clk;
-   struct mutex lock;
-};
-
 static void jz4780_bch_init(struct jz4780_bch *bch,
struct jz4780_bch_params *params, bool encode)
 {
@@ -167,18 +155,9 @@ static bool jz4780_bch_wait_complete(struct jz4780_bch 
*bch, unsigned int irq,
return true;
 }
 
-/**
- * jz4780_bch_calculate() - calculate ECC for a data buffer
- * @bch: BCH device.
- * @params: BCH parameters.
- * @buf: input buffer with raw data.
- * @ecc_code: output buffer with ECC.
- *
- * Return: 0 on success, -ETIMEDOUT if timed out while waiting for BCH
- * controller.
- */
-int jz4780_bch_calculate(struct jz4780_bch *bch, struct jz4780_bch_params 
*params,
-const u8 *buf, u8 *ecc_code)
+static int jz4780_calculate(struct jz4780_bch *bch,
+   struct jz4780_bch_params *params,
+   const u8 *buf, u8 *ecc_code)
 {
int ret = 0;
 
@@ -197,23 +176,10 @@ int jz4780_bch_calculate(struct jz4780_bch *bch, struct 
jz4780_bch_params *param
mutex_unlock(>lock);
return ret;
 }
-EXPORT_SYMBOL(jz4780_bch_calculate);
-
-/**
- * jz4780_bch_correct() - detect and correct bit errors
- * @bch: BCH device.
- * @params: BCH parameters.
- * @buf: raw data read from the chip.
- * @ecc_code: ECC read from the chip.
- *
- * Given the raw data and the ECC read from the NAND device, detects and
- * corrects errors in the data.
- *
- * Return: the number of bit errors corrected, -EBADMSG if there are too many
- * errors to correct or -ETIMEDOUT if we timed out waiting for the controller.
- */
-int jz4780_bch_correct(struct jz4780_bch *bch, struct jz4780_bch_params 
*params,
-  u8 *buf, u8 *ecc_code)
+
+static int jz4780_correct(struct jz4780_bch *bch,
+ struct jz4780_bch_params *params,
+ u8 *buf, u8 *ecc_code)
 {
u32 reg, mask, index;
int i, ret, count;
@@ -259,121 +225,17 @@ int jz4780_bch_correct(struct jz4780_bch *bch, struct 
jz4780_bch_params *params,
mutex_unlock(>lock);
return ret;
 }
-EXPORT_SYMBOL(jz4780_bch_correct);
-
-/**
- * jz4780_bch_get() - get the BCH controller device
- * @np: BCH device tree node.
- *
- * Gets the BCH controller device from the specified device tree node. The
- * device must be released with jz4780_bch_release() when it is no longer being
- * used.
- *
- * Return: a pointer to jz4780_bch, errors are encoded into the pointer.
- * PTR_ERR(-EPROBE_DEFER) if the device hasn't been initialised yet.
- */
-static struct jz4780_bch *jz4780_bch_get(struct device_node *np)
-{
-   struct platform_device *pdev;
-   struct jz4780_bch *bch;

[PATCH v2 8/9] mtd: rawnand: jz4780-bch: Add support for the JZ4725B

[Paul Cercueil]

Add the backend code for the jz4780-bch driver to support the JZ4725B
SoC from Ingenic.

Signed-off-by: Paul Cercueil 
---

Changes:

v2: No changes

 drivers/mtd/nand/raw/ingenic/Makefile |   2 +-
 drivers/mtd/nand/raw/ingenic/jz4725b_bch.c| 234 ++
 .../mtd/nand/raw/ingenic/jz4780_bch_common.c  |   1 +
 .../nand/raw/ingenic/jz4780_bch_internal.h|   1 +
 4 files changed, 237 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/raw/ingenic/jz4725b_bch.c

diff --git a/drivers/mtd/nand/raw/ingenic/Makefile 
b/drivers/mtd/nand/raw/ingenic/Makefile
index c308062a6620..f38b467490cf 100644
--- a/drivers/mtd/nand/raw/ingenic/Makefile
+++ b/drivers/mtd/nand/raw/ingenic/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_JZ4780) += jz4780_nand.o jz4780_bch_common.o \
-jz4780_bch.o
+jz4780_bch.o jz4725b_bch.o
diff --git a/drivers/mtd/nand/raw/ingenic/jz4725b_bch.c 
b/drivers/mtd/nand/raw/ingenic/jz4725b_bch.c
new file mode 100644
index ..54f9c5796e83
--- /dev/null
+++ b/drivers/mtd/nand/raw/ingenic/jz4725b_bch.c
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * JZ4780 backend code for the jz4780-bch driver
+ *
+ * Copyright (C) 2018 Paul Cercueil 
+ *
+ * Based on jz4780_bch.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "jz4780_bch.h"
+#include "jz4780_bch_internal.h"
+
+#define BCH_BHCR   0x0
+#define BCH_BHCSR  0x4
+#define BCH_BHCCR  0x8
+#define BCH_BHCNT  0xc
+#define BCH_BHDR   0x10
+#define BCH_BHPAR0 0x14
+#define BCH_BHERR0 0x28
+#define BCH_BHINT  0x24
+#define BCH_BHINTES0x3c
+#define BCH_BHINTEC0x40
+#define BCH_BHINTE 0x38
+
+#define BCH_BHCR_BSEL_SHIFT2
+#define BCH_BHCR_BSEL_MASK (0x1 << BCH_BHCR_BSEL_SHIFT)
+#define BCH_BHCR_ENCE  BIT(3)
+#define BCH_BHCR_INIT  BIT(1)
+#define BCH_BHCR_BCHE  BIT(0)
+
+#define BCH_BHCNT_DEC_COUNT_SHIFT  16
+#define BCH_BHCNT_DEC_COUNT_MASK   (0x3ff << BCH_BHCNT_DEC_COUNT_SHIFT)
+#define BCH_BHCNT_ENC_COUNT_SHIFT  0
+#define BCH_BHCNT_ENC_COUNT_MASK   (0x3ff << BCH_BHCNT_ENC_COUNT_SHIFT)
+
+#define BCH_BHERR_INDEX0_SHIFT 0
+#define BCH_BHERR_INDEX0_MASK  (0x1fff << BCH_BHERR_INDEX0_SHIFT)
+#define BCH_BHERR_INDEX1_SHIFT 16
+#define BCH_BHERR_INDEX1_MASK  (0x1fff << BCH_BHERR_INDEX1_SHIFT)
+
+#define BCH_BHINT_ERRC_SHIFT   28
+#define BCH_BHINT_ERRC_MASK(0xf << BCH_BHINT_ERRC_SHIFT)
+#define BCH_BHINT_TERRC_SHIFT  16
+#define BCH_BHINT_TERRC_MASK   (0x7f << BCH_BHINT_TERRC_SHIFT)
+#define BCH_BHINT_ALL_0BIT(5)
+#define BCH_BHINT_ALL_FBIT(4)
+#define BCH_BHINT_DECF BIT(3)
+#define BCH_BHINT_ENCF BIT(2)
+#define BCH_BHINT_UNCORBIT(1)
+#define BCH_BHINT_ERR  BIT(0)
+
+/* Timeout for BCH calculation/correction. */
+#define BCH_TIMEOUT_US 10
+
+static void jz4725b_bch_init(struct jz4780_bch *bch,
+struct jz4780_bch_params *params, bool encode)
+{
+   u32 reg;
+
+   /* Clear interrupt status. */
+   writel(readl(bch->base + BCH_BHINT), bch->base + BCH_BHINT);
+
+   /* Initialise and enable BCH. */
+   writel(0x1f, bch->base + BCH_BHCCR);
+   writel(BCH_BHCR_BCHE, bch->base + BCH_BHCSR);
+
+   if (params->strength == 8)
+   writel(BCH_BHCR_BSEL_MASK, bch->base + BCH_BHCSR);
+   else
+   writel(BCH_BHCR_BSEL_MASK, bch->base + BCH_BHCCR);
+
+   if (encode)
+   writel(BCH_BHCR_ENCE, bch->base + BCH_BHCSR);
+   else
+   writel(BCH_BHCR_ENCE, bch->base + BCH_BHCCR);
+
+   writel(BCH_BHCR_INIT, bch->base + BCH_BHCSR);
+
+   /* Set up BCH count register. */
+   reg = params->size << BCH_BHCNT_ENC_COUNT_SHIFT;
+   reg |= (params->size + params->bytes) << BCH_BHCNT_DEC_COUNT_SHIFT;
+   writel(reg, bch->base + BCH_BHCNT);
+}
+
+static void jz4725b_bch_disable(struct jz4780_bch *bch)
+{
+   writel(readl(bch->base + BCH_BHINT), bch->base + BCH_BHINT);
+   writel(BCH_BHCR_BCHE, bch->base + BCH_BHCCR);
+}
+
+static void jz4725b_bch_write_data(struct jz4780_bch *bch, const u8 *buf,
+  size_t size)
+{
+   while (size--)
+   writeb(*buf++, bch->base + BCH_BHDR);
+}
+
+static void jz4725b_bch_read_parity(struct jz4780_bch *bch, u8 *buf,
+   size_t size)
+{
+   size_t size32 = size / sizeof(u32);
+   size_t size8 = size % sizeof(u32);
+   u32 *dest32;
+  

[PATCH v2 3/9] mtd: rawnand: jz4780: Use SPDX license notifiers

[Paul Cercueil]

Use SPDX license notifiers instead of GPLv2 license text in the headers.

Signed-off-by: Paul Cercueil 
Reviewed-by: Boris Brezillon 
---

Changes:

v2: No changes

 drivers/mtd/nand/raw/ingenic/jz4780_bch.c  | 5 +
 drivers/mtd/nand/raw/ingenic/jz4780_bch.h  | 5 +
 drivers/mtd/nand/raw/ingenic/jz4780_nand.c | 5 +
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_bch.c 
b/drivers/mtd/nand/raw/ingenic/jz4780_bch.c
index 7201827809e9..7e4e5e627603 100644
--- a/drivers/mtd/nand/raw/ingenic/jz4780_bch.c
+++ b/drivers/mtd/nand/raw/ingenic/jz4780_bch.c
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * JZ4780 BCH controller
  *
  * Copyright (c) 2015 Imagination Technologies
  * Author: Alex Smith 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published
- * by the Free Software Foundation.
  */
 
 #include 
diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_bch.h 
b/drivers/mtd/nand/raw/ingenic/jz4780_bch.h
index bf4718088a3a..451e0c770160 100644
--- a/drivers/mtd/nand/raw/ingenic/jz4780_bch.h
+++ b/drivers/mtd/nand/raw/ingenic/jz4780_bch.h
@@ -1,12 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * JZ4780 BCH controller
  *
  * Copyright (c) 2015 Imagination Technologies
  * Author: Alex Smith 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published
- * by the Free Software Foundation.
  */
 
 #ifndef __DRIVERS_MTD_NAND_JZ4780_BCH_H__
diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c 
b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
index 22e58975f0d5..7f55358b860f 100644
--- a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
+++ b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * JZ4780 NAND driver
  *
  * Copyright (c) 2015 Imagination Technologies
  * Author: Alex Smith 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published
- * by the Free Software Foundation.
  */
 
 #include 
-- 
2.20.1

[PATCH v2 5/9] mtd: rawnand: jz4780: Add ooblayout for the JZ4725B

[Paul Cercueil]

The boot ROM of the JZ4725B SoC expects a specific OOB layout on the
NAND.

Add an optional "ingenic,oob-layout" device property. When set to
"ingenic,jz4725b", this specific OOB layout is used.

Signed-off-by: Paul Cercueil 
---

Changes:

v2: Instead of forcing the OOB layout, leave it to the board code or
devicetree to decide if the jz4725b-specific layout should be used
or not.

 drivers/mtd/nand/raw/ingenic/jz4780_nand.c | 51 +-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c 
b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
index c0855fef7735..baebb9a5c7c8 100644
--- a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
+++ b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
@@ -44,6 +44,7 @@ struct jz4780_nand_cs {
 struct jz4780_nand_controller {
struct device *dev;
const struct jz_soc_info *soc_info;
+   const struct mtd_ooblayout_ops *oob_layout;
struct jz4780_bch *bch;
struct nand_controller controller;
unsigned int num_banks;
@@ -213,7 +214,7 @@ static int jz4780_nand_attach_chip(struct nand_chip *chip)
return -EINVAL;
}
 
-   mtd_set_ooblayout(mtd, _ooblayout_lp_ops);
+   mtd_set_ooblayout(mtd, nfc->oob_layout);
 
return 0;
 }
@@ -345,11 +346,47 @@ static int jz4780_nand_init_chips(struct 
jz4780_nand_controller *nfc,
return 0;
 }
 
+static int jz4725b_ooblayout_ecc(struct mtd_info *mtd, int section,
+struct mtd_oob_region *oobregion)
+{
+   struct nand_chip *chip = mtd_to_nand(mtd);
+   struct nand_ecc_ctrl *ecc = >ecc;
+
+   if (section || !ecc->total)
+   return -ERANGE;
+
+   oobregion->length = ecc->total;
+   oobregion->offset = 3;
+
+   return 0;
+}
+
+static int jz4725b_ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+   struct nand_chip *chip = mtd_to_nand(mtd);
+   struct nand_ecc_ctrl *ecc = >ecc;
+
+   if (section)
+   return -ERANGE;
+
+   oobregion->length = mtd->oobsize - ecc->total - 3;
+   oobregion->offset = 3 + ecc->total;
+
+   return 0;
+}
+
+const struct mtd_ooblayout_ops jz4725b_ooblayout_ops = {
+   .ecc = jz4725b_ooblayout_ecc,
+   .free = jz4725b_ooblayout_free,
+};
+
 static int jz4780_nand_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
unsigned int num_banks;
struct jz4780_nand_controller *nfc;
+   const char *layout;
int ret;
 
num_banks = jz4780_nemc_num_banks(dev);
@@ -366,6 +403,18 @@ static int jz4780_nand_probe(struct platform_device *pdev)
if (!nfc->soc_info)
return -EINVAL;
 
+   nfc->oob_layout = _ooblayout_lp_ops;
+
+   ret = device_property_read_string(dev, "ingenic,oob-layout", );
+   if (!ret) {
+   if (!strcmp(layout, "ingenic,jz4725b")) {
+   nfc->oob_layout  = _ooblayout_ops;
+   } else {
+   dev_err(dev, "Unrecognized OOB layout %s\n", layout);
+   return -EINVAL;
+   }
+   }
+
/*
 * Check for BCH HW before we call nand_scan_ident, to prevent us from
 * having to call it again if the BCH driver returns -EPROBE_DEFER.
-- 
2.20.1

[PATCH v2 2/9] dt-bindings: mtd: ingenic: Add compatible strings for the JZ4740

[Paul Cercueil]

Add compatible strings to probe the jz4780-nand and jz4780-bch drivers
from devicetree on the JZ4725B and JZ4740 SoCs from Ingenic.

Signed-off-by: Paul Cercueil 
---

Changes:

v2: - Change 'ingenic,jz4725b-nand' compatible string to
  'ingenic,jz4740-nand' to reflect driver change
- Add 'ingenic,jz4740-bch' compatible string
- Document 'ingenic,oob-layout' property

 .../devicetree/bindings/mtd/ingenic,jz4780-nand.txt | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt 
b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
index 29ea5853ca91..294b56a2098a 100644
--- a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
@@ -6,7 +6,9 @@ memory-controllers/ingenic,jz4780-nemc.txt), and thus NAND 
device nodes must
 be children of the NEMC node.
 
 Required NAND controller device properties:
-- compatible: Should be set to "ingenic,jz4780-nand".
+- compatible: Should be one of:
+  * ingenic,jz4740-nand
+  * ingenic,jz4780-nand
 - reg: For each bank with a NAND chip attached, should specify a bank number,
   an offset of 0 and a size of 0x100 (i.e. the whole NEMC bank).
 
@@ -15,6 +17,10 @@ Optional NAND controller device properties:
   property must contain a phandle for the BCH controller node. The required
   properties for this node are described below. If this is not specified,
   software BCH will be used instead.
+- ingenic,oob-layout: Specify the OOB layout to replace the default one.
+  Valid values are:
+  * ingenic,jz4725b
+  * qi,lb60
 
 Optional children nodes:
 - Individual NAND chips are children of the NAND controller node.
@@ -72,7 +78,10 @@ NAND devices. The following is a description of the device 
properties for a
 BCH controller.
 
 Required BCH properties:
-- compatible: Should be set to "ingenic,jz4780-bch".
+- compatible: Should be one of:
+  * ingenic,jz4740-bch
+  * ingenic,jz4725b-bch
+  * ingenic,jz4780-bch
 - reg: Should specify the BCH controller registers location and length.
 - clocks: Clock for the BCH controller.
 
-- 
2.20.1

[PATCH v2 4/9] mtd: rawnand: jz4780: Add support for the JZ4740

[Paul Cercueil]

Add support for probing the jz4780-nand driver on the JZ4740 SoC from
Ingenic.

Signed-off-by: Paul Cercueil 
---

Changes:

v2: - Add support for the JZ4740 and not the JZ4725B: they behave the
  same, and JZ4740 is fully upstream while JZ4725B is not. The
  JZ4725B devicetree will then simply use the "ingenic,jz4740-nand"
  compatible string.
- Fix the number of bytes for the ECC when the ECC strength is 4.
  This is needed for the JZ4740, which uses Reed-Solomon instead of
  BCH.

 drivers/mtd/nand/raw/ingenic/jz4780_nand.c | 48 +-
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c 
b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
index 7f55358b860f..c0855fef7735 100644
--- a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
+++ b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,13 +27,15 @@
 
 #define DRV_NAME   "jz4780-nand"
 
-#define OFFSET_DATA0x
-#define OFFSET_CMD 0x0040
-#define OFFSET_ADDR0x0080
-
 /* Command delay when there is no R/B pin. */
 #define RB_DELAY_US100
 
+struct jz_soc_info {
+   unsigned long data_offset;
+   unsigned long addr_offset;
+   unsigned long cmd_offset;
+};
+
 struct jz4780_nand_cs {
unsigned int bank;
void __iomem *base;
@@ -40,6 +43,7 @@ struct jz4780_nand_cs {
 
 struct jz4780_nand_controller {
struct device *dev;
+   const struct jz_soc_info *soc_info;
struct jz4780_bch *bch;
struct nand_controller controller;
unsigned int num_banks;
@@ -101,9 +105,9 @@ static void jz4780_nand_cmd_ctrl(struct nand_chip *chip, 
int cmd,
return;
 
if (ctrl & NAND_ALE)
-   writeb(cmd, cs->base + OFFSET_ADDR);
+   writeb(cmd, cs->base + nfc->soc_info->addr_offset);
else if (ctrl & NAND_CLE)
-   writeb(cmd, cs->base + OFFSET_CMD);
+   writeb(cmd, cs->base + nfc->soc_info->cmd_offset);
 }
 
 static int jz4780_nand_dev_ready(struct nand_chip *chip)
@@ -161,8 +165,13 @@ static int jz4780_nand_attach_chip(struct nand_chip *chip)
struct jz4780_nand_controller *nfc = 
to_jz4780_nand_controller(chip->controller);
int eccbytes;
 
-   chip->ecc.bytes = fls((1 + 8) * chip->ecc.size) *
-   (chip->ecc.strength / 8);
+   if (chip->ecc.strength == 4) {
+   /* JZ4740 uses 9 bytes of ECC to correct maximum 4 errors */
+   chip->ecc.bytes = 9;
+   } else {
+   chip->ecc.bytes = fls((1 + 8) * chip->ecc.size) *
+ (chip->ecc.strength / 8);
+   }
 
switch (chip->ecc.mode) {
case NAND_ECC_HW:
@@ -272,8 +281,8 @@ static int jz4780_nand_init_chip(struct platform_device 
*pdev,
return -ENOMEM;
mtd->dev.parent = dev;
 
-   chip->legacy.IO_ADDR_R = cs->base + OFFSET_DATA;
-   chip->legacy.IO_ADDR_W = cs->base + OFFSET_DATA;
+   chip->legacy.IO_ADDR_R = cs->base + nfc->soc_info->data_offset;
+   chip->legacy.IO_ADDR_W = cs->base + nfc->soc_info->data_offset;
chip->legacy.chip_delay = RB_DELAY_US;
chip->options = NAND_NO_SUBPAGE_WRITE;
chip->legacy.select_chip = jz4780_nand_select_chip;
@@ -353,6 +362,10 @@ static int jz4780_nand_probe(struct platform_device *pdev)
if (!nfc)
return -ENOMEM;
 
+   nfc->soc_info = device_get_match_data(dev);
+   if (!nfc->soc_info)
+   return -EINVAL;
+
/*
 * Check for BCH HW before we call nand_scan_ident, to prevent us from
 * having to call it again if the BCH driver returns -EPROBE_DEFER.
@@ -390,8 +403,21 @@ static int jz4780_nand_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct jz_soc_info jz4740_soc_info = {
+   .data_offset = 0x,
+   .cmd_offset  = 0x8000,
+   .addr_offset = 0x0001,
+};
+
+static const struct jz_soc_info jz4780_soc_info = {
+   .data_offset = 0x,
+   .cmd_offset  = 0x0040,
+   .addr_offset = 0x0080,
+};
+
 static const struct of_device_id jz4780_nand_dt_match[] = {
-   { .compatible = "ingenic,jz4780-nand" },
+   { .compatible = "ingenic,jz4740-nand", .data = _soc_info },
+   { .compatible = "ingenic,jz4780-nand",  .data = _soc_info  },
{},
 };
 MODULE_DEVICE_TABLE(of, jz4780_nand_dt_match);
-- 
2.20.1

[PATCH v2 6/9] mtd: rawnand: jz4780: Add ooblayout for the Qi Ben Nanonote

[Paul Cercueil]

The Ben Nanonote from Qi Hardware expects a specific OOB layout on its
NAND. If the "ingenic,oob-layout" device property is set to "qi,lb60",
this specific OOB layout is used.

Signed-off-by: Paul Cercueil 
---

Changes:

v2: New patch

 drivers/mtd/nand/raw/ingenic/jz4780_nand.c | 37 ++
 1 file changed, 37 insertions(+)

diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c 
b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
index baebb9a5c7c8..4b304eceae8d 100644
--- a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
+++ b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
@@ -346,6 +346,41 @@ static int jz4780_nand_init_chips(struct 
jz4780_nand_controller *nfc,
return 0;
 }
 
+static int qi_lb60_ooblayout_ecc(struct mtd_info *mtd, int section,
+struct mtd_oob_region *oobregion)
+{
+   struct nand_chip *chip = mtd_to_nand(mtd);
+   struct nand_ecc_ctrl *ecc = >ecc;
+
+   if (section || !ecc->total)
+   return -ERANGE;
+
+   oobregion->length = ecc->total;
+   oobregion->offset = 12;
+
+   return 0;
+}
+
+static int qi_lb60_ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+   struct nand_chip *chip = mtd_to_nand(mtd);
+   struct nand_ecc_ctrl *ecc = >ecc;
+
+   if (section)
+   return -ERANGE;
+
+   oobregion->length = mtd->oobsize - ecc->total - 12;
+   oobregion->offset = 12 + ecc->total;
+
+   return 0;
+}
+
+const struct mtd_ooblayout_ops qi_lb60_ooblayout_ops = {
+   .ecc = qi_lb60_ooblayout_ecc,
+   .free = qi_lb60_ooblayout_free,
+};
+
 static int jz4725b_ooblayout_ecc(struct mtd_info *mtd, int section,
 struct mtd_oob_region *oobregion)
 {
@@ -409,6 +444,8 @@ static int jz4780_nand_probe(struct platform_device *pdev)
if (!ret) {
if (!strcmp(layout, "ingenic,jz4725b")) {
nfc->oob_layout  = _ooblayout_ops;
+   } else if (!strcmp(layout, "qi,lb60")) {
+   nfc->oob_layout = _lb60_ooblayout_ops;
} else {
dev_err(dev, "Unrecognized OOB layout %s\n", layout);
return -EINVAL;
-- 
2.20.1

[PATCH v2 1/9] mtd: rawnand: Move drivers for Ingenic SoCs to subfolder

[Paul Cercueil]

Before adding support for more SoCs and seeing the number of files for
these drivers grow, we move them to their own subfolder to keep it tidy.

Signed-off-by: Paul Cercueil 
---

Changes:

v2: New patch

 drivers/mtd/nand/raw/Kconfig | 14 +-
 drivers/mtd/nand/raw/Makefile|  3 +--
 drivers/mtd/nand/raw/ingenic/Kconfig | 13 +
 drivers/mtd/nand/raw/ingenic/Makefile|  2 ++
 drivers/mtd/nand/raw/{ => ingenic}/jz4740_nand.c |  0
 drivers/mtd/nand/raw/{ => ingenic}/jz4780_bch.c  |  0
 drivers/mtd/nand/raw/{ => ingenic}/jz4780_bch.h  |  0
 drivers/mtd/nand/raw/{ => ingenic}/jz4780_nand.c |  0
 8 files changed, 17 insertions(+), 15 deletions(-)
 create mode 100644 drivers/mtd/nand/raw/ingenic/Kconfig
 create mode 100644 drivers/mtd/nand/raw/ingenic/Makefile
 rename drivers/mtd/nand/raw/{ => ingenic}/jz4740_nand.c (100%)
 rename drivers/mtd/nand/raw/{ => ingenic}/jz4780_bch.c (100%)
 rename drivers/mtd/nand/raw/{ => ingenic}/jz4780_bch.h (100%)
 rename drivers/mtd/nand/raw/{ => ingenic}/jz4780_nand.c (100%)

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 1a55d3e3d4c5..d886be2fc174 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -470,19 +470,7 @@ config MTD_NAND_NUC900
  This enables the driver for the NAND Flash on evaluation board based
  on w90p910 / NUC9xx.
 
-config MTD_NAND_JZ4740
-   tristate "Support for JZ4740 SoC NAND controller"
-   depends on MACH_JZ4740 || COMPILE_TEST
-   depends on HAS_IOMEM
-   help
- Enables support for NAND Flash on JZ4740 SoC based boards.
-
-config MTD_NAND_JZ4780
-   tristate "Support for NAND on JZ4780 SoC"
-   depends on JZ4780_NEMC
-   help
- Enables support for NAND Flash connected to the NEMC on JZ4780 SoC
- based boards, using the BCH controller for hardware error correction.
+source "drivers/mtd/nand/raw/ingenic/Kconfig"
 
 config MTD_NAND_FSMC
tristate "Support for NAND on ST Micros FSMC"
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 57159b349054..f419d373d090 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -45,8 +45,7 @@ obj-$(CONFIG_MTD_NAND_NUC900) += nuc900_nand.o
 obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
 obj-$(CONFIG_MTD_NAND_VF610_NFC)   += vf610_nfc.o
 obj-$(CONFIG_MTD_NAND_RICOH)   += r852.o
-obj-$(CONFIG_MTD_NAND_JZ4740)  += jz4740_nand.o
-obj-$(CONFIG_MTD_NAND_JZ4780)  += jz4780_nand.o jz4780_bch.o
+obj-y  += ingenic/
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
 obj-$(CONFIG_MTD_NAND_XWAY)+= xway_nand.o
 obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)   += bcm47xxnflash/
diff --git a/drivers/mtd/nand/raw/ingenic/Kconfig 
b/drivers/mtd/nand/raw/ingenic/Kconfig
new file mode 100644
index ..67806c87b2c4
--- /dev/null
+++ b/drivers/mtd/nand/raw/ingenic/Kconfig
@@ -0,0 +1,13 @@
+config MTD_NAND_JZ4740
+   tristate "Support for JZ4740 SoC NAND controller"
+   depends on MACH_JZ4740 || COMPILE_TEST
+   depends on HAS_IOMEM
+   help
+ Enables support for NAND Flash on JZ4740 SoC based boards.
+
+config MTD_NAND_JZ4780
+   tristate "Support for NAND on JZ4780 SoC"
+   depends on JZ4780_NEMC
+   help
+ Enables support for NAND Flash connected to the NEMC on JZ4780 SoC
+ based boards, using the BCH controller for hardware error correction.
diff --git a/drivers/mtd/nand/raw/ingenic/Makefile 
b/drivers/mtd/nand/raw/ingenic/Makefile
new file mode 100644
index ..44c2ca053d24
--- /dev/null
+++ b/drivers/mtd/nand/raw/ingenic/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
+obj-$(CONFIG_MTD_NAND_JZ4780) += jz4780_nand.o jz4780_bch.o
diff --git a/drivers/mtd/nand/raw/jz4740_nand.c 
b/drivers/mtd/nand/raw/ingenic/jz4740_nand.c
similarity index 100%
rename from drivers/mtd/nand/raw/jz4740_nand.c
rename to drivers/mtd/nand/raw/ingenic/jz4740_nand.c
diff --git a/drivers/mtd/nand/raw/jz4780_bch.c 
b/drivers/mtd/nand/raw/ingenic/jz4780_bch.c
similarity index 100%
rename from drivers/mtd/nand/raw/jz4780_bch.c
rename to drivers/mtd/nand/raw/ingenic/jz4780_bch.c
diff --git a/drivers/mtd/nand/raw/jz4780_bch.h 
b/drivers/mtd/nand/raw/ingenic/jz4780_bch.h
similarity index 100%
rename from drivers/mtd/nand/raw/jz4780_bch.h
rename to drivers/mtd/nand/raw/ingenic/jz4780_bch.h
diff --git a/drivers/mtd/nand/raw/jz4780_nand.c 
b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
similarity index 100%
rename from drivers/mtd/nand/raw/jz4780_nand.c
rename to drivers/mtd/nand/raw/ingenic/jz4780_nand.c
-- 
2.20.1

Re: [PATCH] XArray tests: allocation has to be GFP_ATOMIC under rcu_read_lock

[Matthew Wilcox]

On Tue, Jan 29, 2019 at 07:08:42PM +0800, Li RongQing wrote:
> - XA_BUG_ON(xa, xa_store_index(xa, 1, GFP_KERNEL) != NULL);
> + XA_BUG_ON(xa, xa_store_index(xa, 1, GFP_ATOMIC) != NULL);

Did you try running this change in userspace too?  I don't think it'll
work.

I think the right change would be:

+++ b/lib/test_xarray.c
@@ -107,8 +107,11 @@ static noinline void check_xas_retry(struct xarray *xa)
XA_BUG_ON(xa, xas.xa_node != XAS_RESTART);
XA_BUG_ON(xa, xas_next_entry(, ULONG_MAX) != xa_mk_value(0));
XA_BUG_ON(xa, xas.xa_node != NULL);
+   rcu_read_unlock();
 
XA_BUG_ON(xa, xa_store_index(xa, 1, GFP_KERNEL) != NULL);
+
+   rcu_read_lock();
XA_BUG_ON(xa, !xa_is_internal(xas_reload()));
xas.xa_node = XAS_RESTART;
XA_BUG_ON(xa, xas_next_entry(, ULONG_MAX) != xa_mk_value(0));

[PATCH] staging: rtl8192u: fix a null pointer dereference on a null dev pointer

[Colin King]

From: Colin Ian King 

There is an earlier null check on pointer dev which implies it may be null,
however the assignment of pointer pref and the call to free_ieee82011 on
a null dev can cause null pointer dereference errors.  Fix this by moving
the assignment of priv and the the call to free_ieee80211 into the block of
code that performs the null dev sanity check.

Detected by CoverityScan, CID#143078 ("Dereference after null check")

Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging")
Signed-off-by: Colin Ian King 
---
 drivers/staging/rtl8192u/r8192U_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 0ac0bbf7d923..4741a29326ea 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4955,9 +4955,10 @@ static void rtl8192_cancel_deferred_work(struct 
r8192_priv *priv)
 static void rtl8192_usb_disconnect(struct usb_interface *intf)
 {
struct net_device *dev = usb_get_intfdata(intf);
-   struct r8192_priv *priv = ieee80211_priv(dev);
 
if (dev) {
+   struct r8192_priv *priv = ieee80211_priv(dev);
+
unregister_netdev(dev);
 
RT_TRACE(COMP_DOWN,
@@ -4969,8 +4970,8 @@ static void rtl8192_usb_disconnect(struct usb_interface 
*intf)
priv->pFirmware = NULL;
rtl8192_usb_deleteendpoints(dev);
usleep_range(1, 11000);
+   free_ieee80211(dev);
}
-   free_ieee80211(dev);
RT_TRACE(COMP_DOWN, "wlan driver removed\n");
 }
 
-- 
2.20.1

[PATCH] staging: most: cdev: add missing check for cdev_add failure

[Colin King]

From: Colin Ian King 

Currently the call to cdev_add is missing a check for failure. Fix this by
checking for failure and exiting via a new error path that ensures the
allocated comp_channel struct is kfree'd.

Detected by CoverityScan, CID#1462359 ("Unchecked return value")

Fixes: 9bc79bbcd0c5 ("Staging: most: add MOST driver's aim-cdev module")
Signed-off-by: Colin Ian King 
---
 drivers/staging/most/cdev/cdev.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/most/cdev/cdev.c b/drivers/staging/most/cdev/cdev.c
index ea64aabda94e..f2b347cda8b7 100644
--- a/drivers/staging/most/cdev/cdev.c
+++ b/drivers/staging/most/cdev/cdev.c
@@ -453,7 +453,9 @@ static int comp_probe(struct most_interface *iface, int 
channel_id,
c->devno = MKDEV(comp.major, current_minor);
cdev_init(>cdev, _fops);
c->cdev.owner = THIS_MODULE;
-   cdev_add(>cdev, c->devno, 1);
+   retval = cdev_add(>cdev, c->devno, 1);
+   if (retval < 0)
+   goto err_free_c;
c->iface = iface;
c->cfg = cfg;
c->channel_id = channel_id;
@@ -485,6 +487,7 @@ static int comp_probe(struct most_interface *iface, int 
channel_id,
list_del(>list);
 err_del_cdev_and_free_channel:
cdev_del(>cdev);
+err_free_c:
kfree(c);
 err_remove_ida:
ida_simple_remove(_id, current_minor);
-- 
2.20.1

Re: Bluetooth: hci0: last event is not cmd complete (0x0f) with LG TV

[Paul Menzel]

Dear Linux folks,


On 01.02.19 22:34, Paul Menzel wrote:

[attaching Linux messages, lspci and lsusb output]

On 01.02.19 22:20, Paul Menzel wrote:


When trying to pair a Dell Latitude E7250 running Debian Sid/unstable 
with Linux 4.20 and GNOME 3.30 with an LG TV, after starting the 
pairing process the TV is listed. in Bluetooth dialog of GNOME setting.


The TV displays the instructions below.


Complete the next three steps on your mobile device:
1. Turn ON Bluetooth.
2. Select the TV name from the list of available devices.
   • TV Name : 679
3. Confirm the connection request.


Selecting the TV in the GNOME dialog, a dialog is shown on my system 
with a PIN consisting of six numbers. With the dialog, Linux logs the 
message below.


  Bluetooth: hci0: last event is not cmd complete (0x0f)

But, the TV does not show any PIN. Confirming it anyway, nothing is 
happening further.


Is that supposed to work? It’d be great if you helped me to set this up.


Please find a trace attached. This time Linux 4.19.16 was running.

sudo tcpdump -i bluetooth0 -w bluetooth0_capture.pcap


Kind regards,

Paul


bluetooth0_capture.pcap
Description: application/vnd.tcpdump.pcap

linux-next: tracebacks in workqueue.c/__flush_work()

[Guenter Roeck]

Commit "workqueue: Try to catch flush_work() without INIT_WORK()" added
a warning if flush_work() is called without worker function.

This results in the following tracebacks, typically observed during
system shutdown.

[ cut here ]
WARNING: CPU: 0 PID: 101 at kernel/workqueue.c:3018 __flush_work+0x2a4/0x2e0
Modules linked in:
CPU: 0 PID: 101 Comm: umount Not tainted 5.0.0-rc4-next-20190201 #1
   fc0007dcbd18  fc3338a0 fc3517d4
   fc3517d4 fce56c98 fce56c98 fcebc1d8
   fcec0bd8 a8024010 0bca 
   fc3d3ea4 fce56c98 fce56c60 fcebc1d8
   fcec0bd8  0001 
   fc000782d520  fc44ef50 fc0007c4b540
Trace:
[] __warn+0x160/0x190
[] __flush_work+0x2a4/0x2e0
[] __flush_work+0x2a4/0x2e0
[] lru_add_drain_all+0xe4/0x190
[] shrink_dcache_sb+0x70/0xb0
[] invalidate_bh_lru+0x44/0x80
[] on_each_cpu_cond+0x5c/0x90
[] invalidate_bh_lru+0x0/0x80
[] invalidate_bdev+0x3c/0x70
[] reconfigure_super+0x178/0x2c0
[] ksys_umount+0x664/0x680
[] sys_umount+0x1c/0x30
[] entSys+0xa4/0xc0
[] entSys+0xa4/0xc0

---[ end trace 613cea34708701f1 ]---

The problem is seen with several (but not all) architectures. Affected
architectures/platforms are:
alpha
arm:versatilepb
m68k
mips, mips64 (boot from IDE drive or MMC, SMP disabled)
parisc (nosmp builds)
sparc, sparc64 (nosmp builds)

There may be others; several of my tests fail with build failures.

If/when it is seen, the problem is persistent.

Common denominator seems to be that SMP is disabled. It does appear that
for_each_cpu() ignores the mask for nosmp builds, but I don't really
understand why.

Guenter

[PATCH] MMC: OMAP: fix the maximum timeout setting

[Aaro Koskinen]

When running OMAP1 kernel on QEMU, MMC access is annoyingly noisy:

MMC: CTO of 0xff and 0xfe cannot be used!
MMC: CTO of 0xff and 0xfe cannot be used!
MMC: CTO of 0xff and 0xfe cannot be used!
[ad inf.]

Emulator warnings appear to be valid. The TI document SPRU680 [1]
("OMAP5910 Dual-Core Processor MultiMedia Card/Secure Data Memory Card
(MMC/SD) Reference Guide") page 36 states that the maximum timeout
is 253 cycles and "0xff and 0xfe cannot be used".

Fix by using 0xfd as the maximum timeout.

Tested using QEMU 2.5 (Siemens SX1 machine, OMAP310), and also checked
on real hardware using Palm TE (OMAP310), Nokia 770 (OMAP1710)
and Nokia N810 (OMAP2420) that MMC works as before.

[1] http://www.ti.com/lit/ug/spru680/spru680.pdf

Fixes: 730c9b7e6630f ("[MMC] Add OMAP MMC host driver")
Signed-off-by: Aaro Koskinen 
---
 drivers/mmc/host/omap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index c60a7625b1fa..b2873a2432b6 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -920,7 +920,7 @@ static inline void set_cmd_timeout(struct mmc_omap_host 
*host, struct mmc_reques
reg &= ~(1 << 5);
OMAP_MMC_WRITE(host, SDIO, reg);
/* Set maximum timeout */
-   OMAP_MMC_WRITE(host, CTO, 0xff);
+   OMAP_MMC_WRITE(host, CTO, 0xfd);
 }
 
 static inline void set_data_timeout(struct mmc_omap_host *host, struct 
mmc_request *req)
-- 
2.17.0

Re: [PATCH][next] media: staging: intel-ipu3: fix unsigned comparison with < 0

[Colin Ian King]

ping?

On 22/12/2018 11:49, Colin King wrote:
> From: Colin Ian King 
> 
> The comparison css->pipes[pipe].bindex < 0 is always false because
> bindex is an unsigned int.  Fix this by using a signed integer for
> the comparison.
> 
> Detected by CoverityScan, CID#1476023 ("Unsigned compared against 0")
> 
> Fixes: f5f2e4273518 ("media: staging/intel-ipu3: Add css pipeline 
> programming")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/staging/media/ipu3/ipu3-css.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/ipu3/ipu3-css.c 
> b/drivers/staging/media/ipu3/ipu3-css.c
> index 44c55639389a..b9354d2bb692 100644
> --- a/drivers/staging/media/ipu3/ipu3-css.c
> +++ b/drivers/staging/media/ipu3/ipu3-css.c
> @@ -1751,7 +1751,7 @@ int ipu3_css_fmt_try(struct ipu3_css *css,
>   [IPU3_CSS_QUEUE_OUT].fmt.mpix;
>   struct v4l2_pix_format_mplane *const vf =
>   [IPU3_CSS_QUEUE_VF].fmt.mpix;
> - int i, s;
> + int i, s, ret;
>  
>   /* Adjust all formats, get statistics buffer sizes and formats */
>   for (i = 0; i < IPU3_CSS_QUEUES; i++) {
> @@ -1826,12 +1826,12 @@ int ipu3_css_fmt_try(struct ipu3_css *css,
>   s = (bds->height - gdc->height) / 2 - FILTER_SIZE;
>   env->height = s < MIN_ENVELOPE ? MIN_ENVELOPE : s;
>  
> - css->pipes[pipe].bindex =
> - ipu3_css_find_binary(css, pipe, q, r);
> - if (css->pipes[pipe].bindex < 0) {
> + ret = ipu3_css_find_binary(css, pipe, q, r);
> + if (ret < 0) {
>   dev_err(css->dev, "failed to find suitable binary\n");
>   return -EINVAL;
>   }
> + css->pipes[pipe].bindex = ret;
>  
>   dev_dbg(css->dev, "Binary index %d for pipe %d found.",
>   css->pipes[pipe].bindex, pipe);
> 

[PATCH] staging: comedi: dt2811: fix integer overflow in multiply

[Colin King]

From: Colin Ian King 

Multiplying two unsigned ints leads to an unsigned int result. The
intention is that the result is a unsigned long long, so to fix the
overflow cast the div to an unsigned long long to ensure that the
multiplication is on unsigned long longs to avoid overflow.

Detected by CoverityScan, CID#1357597 ("Unintentioal integer overflow")

Fixes: f2975a9b2ab9 ("staging: comedi: dt2811: add async command support for AI 
subdevice")
Signed-off-by: Colin Ian King 
---
 drivers/staging/comedi/drivers/dt2811.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/dt2811.c 
b/drivers/staging/comedi/drivers/dt2811.c
index 05207a519755..820e75f850ff 100644
--- a/drivers/staging/comedi/drivers/dt2811.c
+++ b/drivers/staging/comedi/drivers/dt2811.c
@@ -323,7 +323,8 @@ static unsigned int dt2811_ns_to_timer(unsigned int 
*nanosec,
for (_mult = 0; _mult <= 7; _mult++) {
unsigned int div = dt2811_clk_dividers[_div];
unsigned int mult = dt2811_clk_multipliers[_mult];
-   unsigned long long divider = div * mult;
+   unsigned long long divider =
+   (unsigned long long)div * mult;
unsigned int divisor = DT2811_TMRCTR_MANTISSA(_div) |
   DT2811_TMRCTR_EXPONENT(_mult);
 
-- 
2.20.1

linux-next: Fixes tag needs some work in the origin tree

[Stephen Rothwell]

[Just a reminder for the future.]

Hi all,

In commit

  2bb10639f12c ("RISC-V: fix bad use of of_node_put")

Fixes tag

  Fixes: 94f9bf118f ("RISC-V: Fix of_node_* refcount")

has these problem(s):

  - SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").

-- 
Cheers,
Stephen Rothwell


pgpURl1lQ1UGi.pgp
Description: OpenPGP digital signature

linux-next: Fixes tag needs some work in Linus' tree

[Stephen Rothwell]

[Just a reminder for the future.]

Hi all,

In commit

  85bd6e61f34d ("blk-mq: fix a hung issue when fsync")

Fixes tag

  Fixes: bd166ef1 (blk-mq-sched: add framework for MQ capable IO schedulers)

has these problem(s):

  - SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").

-- 
Cheers,
Stephen Rothwell


pgpRakFBxU_2x.pgp
Description: OpenPGP digital signature

Re: [PATCH] docs: kernel-doc: typo "documentaion"

[Matthew Wilcox]

On Fri, Feb 01, 2019 at 02:04:16PM -0800, frowand.l...@gmail.com wrote:
>Include documentation for each *function* in *source*.
> -  If no *function* if specified, the documentaion for all functions
> +  If no *function* if specified, the documentation for all functions
>and types in the *source* will be included.

Could you fix the if/is mistake while you're at it?

Re: [GIT PULL] libnvdimm fixes for v5.0-rc4

[Dan Williams]

On Sat, Feb 2, 2019 at 11:12 AM Linus Torvalds
 wrote:
>
> On Sat, Jan 26, 2019 at 3:31 PM Williams, Dan J
>  wrote:
> >
> > Hi Linus, please pull from:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
> > tags/libnvdimm-fixes-5.0-rc4
>
> Hmm. One more pr-tracker-bot note: going through the pull requests
> from the last week, I notice that this one didn't get a pr-tracker
> response.
>
> It looks like lkml still hates you, so your pull request email never
> made it to the list despite being cc'd. And thus it never makes it to
> the lore and pr-tracker-bot infrastructure either.
>
> Have you tried looking into why lkml has that red-hot hatred of your emails?
>
> Because it does seem to be personal - you have pissed off the email
> gods some way. Did you get a bounce?

No bounce, but I at least have good company in the shunned group.
Mel's analysis of the impact of page-allocator randomization [1]
somehow also missed lore.kernel.org, but lkml.org caught it [2]. Add
Dave Hansen on the outside chance his mail scripts have caught other
instances of patches sent to the list but not archived in
lore.kernel.org.

[1]: <20181012082213.ge5...@techsingularity.net>
[2]: https://lkml.org/lkml/2018/10/12/309

Re: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show functions

[Kimberly Brown]

On Fri, Feb 01, 2019 at 06:24:24PM +, Dexuan Cui wrote:
> > From: Kimberly Brown 
> > Sent: Thursday, January 31, 2019 9:47 AM
> > ...
> > 2) Prevent a deadlock that can occur between the proposed mutex_lock()
> > call in the vmbus_chan_attr_show() function and the sysfs/kernfs functions.
> Hi Kim,
> Can you please share more details about the deadlock? 
> It's unclear to me how the deadlock happens.
>

Hi Dexuan,

I encountered the deadlock by:
1) Adding a call to msleep() before acquiring the mutex in
vmbus_chan_attr_show()
2) Opening a hv_netvsc subchannel's sysfs file
3) Removing hv_netvsc while the sysfs file is opening

Here's the lockdep output:

[  164.167699] hv_vmbus: unregistering driver hv_netvsc

[  164.171660] ==
[  164.171661] WARNING: possible circular locking dependency detected
[  164.171663] 5.0.0-rc1+ #58 Not tainted
[  164.171664] --
[  164.171666] kworker/0:1/12 is trying to acquire lock:
[  164.171668] 664f9893 (kn->count#43){}, at: 
kernfs_remove+0x23/0x40
[  164.171676]
   but task is already holding lock:
[  164.171677] 7b9e8443 (_connection.channel_mutex){+.+.}, at: 
vmbus_onoffer_rescind+0x1ae/0x210 [hv_vmbus]
[  164.171686]
   which lock already depends on the new lock.

[  164.171687]
   the existing dependency chain (in reverse order) is:
[  164.171688]
   -> #1 (_connection.channel_mutex){+.+.}:
[  164.171694]__mutex_lock+0x65/0x9b0
[  164.171696]mutex_lock_nested+0x1b/0x20
[  164.171700]vmbus_chan_attr_show+0x3f/0x90 [hv_vmbus]
[  164.171703]sysfs_kf_seq_show+0xa4/0x130
[  164.171705]kernfs_seq_show+0x2d/0x30
[  164.171708]seq_read+0xe2/0x410
[  164.171711]kernfs_fop_read+0x14e/0x1a0
[  164.171714]__vfs_read+0x3a/0x1a0
[  164.171716]vfs_read+0x91/0x140
[  164.171718]ksys_read+0x58/0xc0
[  164.171721]__x64_sys_read+0x1a/0x20
[  164.171724]do_syscall_64+0x65/0x1b0
[  164.171727]entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  164.171728]
   -> #0 (kn->count#43){}:
[  164.171732]lock_acquire+0xa3/0x180
[  164.171734]__kernfs_remove+0x278/0x300
[  164.171737]kernfs_remove+0x23/0x40
[  164.171739]sysfs_remove_dir+0x51/0x60
[  164.171741]kobject_del.part.7+0x13/0x40
[  164.171743]kobject_put+0x6a/0x1a0
[  164.171748]hv_process_channel_removal+0xfe/0x180 [hv_vmbus]
[  164.171752]vmbus_onoffer_rescind+0x20a/0x210 [hv_vmbus]
[  164.171756]vmbus_onmessage+0x5f/0x150 [hv_vmbus]
[  164.171760]vmbus_onmessage_work+0x22/0x30 [hv_vmbus]
[  164.171763]process_one_work+0x291/0x5c0
[  164.171765]worker_thread+0x34/0x400
[  164.171767]kthread+0x124/0x140
[  164.171770]ret_from_fork+0x3a/0x50
[  164.171771]
   other info that might help us debug this:

[  164.171772]  Possible unsafe locking scenario:

[  164.171773]CPU0CPU1
[  164.171775]
[  164.171776]   lock(_connection.channel_mutex);
[  164.171777]lock(kn->count#43);
[  164.171779]
lock(_connection.channel_mutex);
[  164.171781]   lock(kn->count#43);
[  164.171783]
*** DEADLOCK ***

[  164.171785] 3 locks held by kworker/0:1/12:
[  164.171786]  #0: 2128b29f ((wq_completion)"events"){+.+.}, at: 
process_one_work+0x20f/0x5c0
[  164.171790]  #1: 41d2602c ((work_completion)(>work)){+.+.}, at: 
process_one_work+0x20f/0x5c0
[  164.171794]  #2: 7b9e8443 (_connection.channel_mutex){+.+.}, 
at: vmbus_onoffer_rescind+0x1ae/0x210 [hv_vmbus]
[  164.171799]
   stack backtrace:
[  164.171802] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.0.0-rc1+ #58
[  164.171804] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS Hyper-V UEFI Release v3.0 03/02/2018
[  164.171809] Workqueue: events vmbus_onmessage_work [hv_vmbus]
[  164.171811] Call Trace:
[  164.171816]  dump_stack+0x8e/0xd5
[  164.171819]  print_circular_bug.isra.37+0x1e7/0x1f5
[  164.171822]  __lock_acquire+0x1427/0x1490
[  164.171826]  ? sched_clock+0x9/0x10
[  164.171830]  lock_acquire+0xa3/0x180
[  164.171832]  ? lock_acquire+0xa3/0x180
[  164.171835]  ? kernfs_remove+0x23/0x40
[  164.171838]  __kernfs_remove+0x278/0x300
[  164.171840]  ? kernfs_remove+0x23/0x40
[  164.171843]  kernfs_remove+0x23/0x40
[  164.171846]  sysfs_remove_dir+0x51/0x60
[  164.171848]  kobject_del.part.7+0x13/0x40
[  164.171850]  kobject_put+0x6a/0x1a0
[  164.171855]  hv_process_channel_removal+0xfe/0x180 [hv_vmbus]
[  164.171859]  vmbus_onoffer_rescind+0x20a/0x210 [hv_vmbus]
[  164.171863]  vmbus_onmessage+0x5f/0x150 [hv_vmbus]
[  164.171868]  vmbus_onmessage_work+0x22/0x30 [hv_vmbus]
[  164.171870]  

Re: [PATCH] net: dsa: Fix lockdep false positive splat

[Florian Fainelli]

Le 2/2/19 à 9:53 AM, Marc Zyngier a écrit :
> Creating a macvtap on a DSA-backed interface results in the following
> splat when lockdep is enabled:
> 
> [   19.638080] IPv6: ADDRCONF(NETDEV_CHANGE): lan0: link becomes ready
> [   23.041198] device lan0 entered promiscuous mode
> [   23.043445] device eth0 entered promiscuous mode
> [   23.049255]
> [   23.049557] 
> [   23.055021] WARNING: possible recursive locking detected
> [   23.060490] 5.0.0-rc3-00013-g56c857a1b8d3 #118 Not tainted
> [   23.066132] 
> [   23.071598] ip/2861 is trying to acquire lock:
> [   23.076171] f61990cb (_xmit_ETHER){+...}, at: 
> dev_set_rx_mode+0x1c/0x38
> [   23.083693]
> [   23.083693] but task is already holding lock:
> [   23.089696] ecf0c3b4 (_xmit_ETHER){+...}, at: dev_uc_add+0x24/0x70
> [   23.096774]
> [   23.096774] other info that might help us debug this:
> [   23.103494]  Possible unsafe locking scenario:
> [   23.103494]
> [   23.109584]CPU0
> [   23.112093]
> [   23.114601]   lock(_xmit_ETHER);
> [   23.117917]   lock(_xmit_ETHER);
> [   23.121233]
> [   23.121233]  *** DEADLOCK ***
> [   23.121233]
> [   23.127325]  May be due to missing lock nesting notation
> [   23.127325]
> [   23.134315] 2 locks held by ip/2861:
> [   23.137987]  #0: 3b766c72 (rtnl_mutex){+.+.}, at: 
> rtnetlink_rcv_msg+0x338/0x4e0
> [   23.146231]  #1: ecf0c3b4 (_xmit_ETHER){+...}, at: 
> dev_uc_add+0x24/0x70
> [   23.153757]
> [   23.153757] stack backtrace:
> [   23.158243] CPU: 0 PID: 2861 Comm: ip Not tainted 
> 5.0.0-rc3-00013-g56c857a1b8d3 #118
> [   23.166212] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT)
> [   23.172843] Call trace:
> [   23.175358]  dump_backtrace+0x0/0x188
> [   23.179116]  show_stack+0x14/0x20
> [   23.182524]  dump_stack+0xb4/0xec
> [   23.185928]  __lock_acquire+0x123c/0x1860
> [   23.190048]  lock_acquire+0xc8/0x248
> [   23.193724]  _raw_spin_lock_bh+0x40/0x58
> [   23.197755]  dev_set_rx_mode+0x1c/0x38
> [   23.201607]  dev_set_promiscuity+0x3c/0x50
> [   23.205820]  dsa_slave_change_rx_flags+0x5c/0x70
> [   23.210567]  __dev_set_promiscuity+0x148/0x1e0
> [   23.215136]  __dev_set_rx_mode+0x74/0x98
> [   23.219167]  dev_uc_add+0x54/0x70
> [   23.222575]  macvlan_open+0x170/0x1d0
> [   23.226336]  __dev_open+0xe0/0x160
> [   23.229830]  __dev_change_flags+0x16c/0x1b8
> [   23.234132]  dev_change_flags+0x20/0x60
> [   23.238074]  do_setlink+0x2d0/0xc50
> [   23.241658]  __rtnl_newlink+0x5f8/0x6e8
> [   23.245601]  rtnl_newlink+0x50/0x78
> [   23.249184]  rtnetlink_rcv_msg+0x360/0x4e0
> [   23.253397]  netlink_rcv_skb+0xe8/0x130
> [   23.257338]  rtnetlink_rcv+0x14/0x20
> [   23.261012]  netlink_unicast+0x190/0x210
> [   23.265043]  netlink_sendmsg+0x288/0x350
> [   23.269075]  sock_sendmsg+0x18/0x30
> [   23.272659]  ___sys_sendmsg+0x29c/0x2c8
> [   23.276602]  __sys_sendmsg+0x60/0xb8
> [   23.280276]  __arm64_sys_sendmsg+0x1c/0x28
> [   23.284488]  el0_svc_common+0xd8/0x138
> [   23.288340]  el0_svc_handler+0x24/0x80
> [   23.292192]  el0_svc+0x8/0xc
> 
> This looks fairly harmless (no actual deadlock occurs), and is
> fixed in a similar way to c6894dec8ea9 ("bridge: fix lockdep
> addr_list_lock false positive splat") by putting the addr_list_lock
> in its own lockdep class.

Great timing, I was just looking at this after solving another one seen
with the bridge code on net-next. AFAIR you can also trigger this with
VLAN and pretty much anything that tries to push UC/MC address list down
to the master device.

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH AUTOSEL 4.19 059/258] x86/resctrl: Fixup the user-visible strings

[Sasha Levin]

On Mon, Jan 28, 2019 at 11:07:34AM -0800, Reinette Chatre wrote:

Hi Sasha,

On 1/28/2019 7:56 AM, Sasha Levin wrote:

From: Babu Moger 

[ Upstream commit 723f1a0dd8e26a7523ba068204bee11c95ded38d ]

Fix the messages in rdt_last_cmd_printf() and rdt_last_cmd_puts() to
make them more meaningful and consistent.


It is not clear to me why this patch is considered for stable since it
just changes user visible strings to be more consistent.

If user visible string consistency/correctness is of concern and is what
prompted its consideration then please also consider to include upstream
commit
456824896de2b68df40b3ea5777ef49dc6cc8fda "x86/resctrl: Use
rdt_last_cmd_puts() where possible" that fixes two typos that was
introduced in this commit. This may introduce difficultly though since
the file layout changed between the kernel versions these patches are
found in.


I've dropped it, it shouldn't have been included to begin with.

--
Thanks,
Sasha

Re: general protection fault in rds_recv_rcvbuf_delta

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:cd984a5be215 Merge tag 'xtensa-20190201' of git://github.c..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1725e4ff40
kernel config:  https://syzkaller.appspot.com/x/.config?x=2e0064f906afee10
dashboard link: https://syzkaller.appspot.com/bug?extid=4b4f8163c2e246df3c4c
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11631328c0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1172c7ef40

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4b4f8163c2e246df3...@syzkaller.appspotmail.com

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
CPU: 0 PID: 8054 Comm: syz-executor390 Not tainted 5.0.0-rc4+ #56
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:rds_recv_rcvbuf_delta.part.0+0x14a/0x3f0 net/rds/recv.c:103
Code: c1 ea 03 80 3c 02 00 0f 85 6e 02 00 00 4c 8b a3 c0 04 00 00 48 b8 00  
00 00 00 00 fc ff df 49 8d 7c 24 2c 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48  
89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 00

RSP: 0018:88808fd9f670 EFLAGS: 00010007
RAX: dc00 RBX: 8880a96a97c0 RCX: 8681f5bd
RDX: 0005 RSI: 8681f5cb RDI: 002c
RBP: 88808fd9f6a8 R08: 888086a1a000 R09: ed1011fb3ec4
R10: ed1011fb3ec3 R11: 0003 R12: 
R13: 8880a96a9ce4 R14: 0002e400 R15: 88809aeecc00
FS:  026d4940() GS:8880ae80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 00424ec0 CR3: 8e163000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 rds_recv_rcvbuf_delta net/rds/recv.c:379 [inline]
 rds_recv_incoming+0x789/0x11f0 net/rds/recv.c:379
 rds_loop_xmit+0xf3/0x2a0 net/rds/loop.c:96
 rds_send_xmit+0x1113/0x2560 net/rds/send.c:355
 rds_sendmsg+0x280a/0x3450 net/rds/send.c:1368
 sock_sendmsg_nosec net/socket.c:621 [inline]
 sock_sendmsg+0xdd/0x130 net/socket.c:631
 ___sys_sendmsg+0x806/0x930 net/socket.c:2116
 __sys_sendmsg+0x105/0x1d0 net/socket.c:2154
 __do_sys_sendmsg net/socket.c:2163 [inline]
 __se_sys_sendmsg net/socket.c:2161 [inline]
 __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4487e9
Code: e8 4c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 ab c5 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7fffa307f188 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 0003 RCX: 004487e9
RDX:  RSI: 2340 RDI: 0004
RBP: c806 R08:  R09: 
R10:  R11: 0246 R12: 004ab4b0
R13: 004052b0 R14:  R15: 
Modules linked in:
---[ end trace e9dbe4e38be82e2e ]---
RIP: 0010:rds_recv_rcvbuf_delta.part.0+0x14a/0x3f0 net/rds/recv.c:103
Code: c1 ea 03 80 3c 02 00 0f 85 6e 02 00 00 4c 8b a3 c0 04 00 00 48 b8 00  
00 00 00 00 fc ff df 49 8d 7c 24 2c 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48  
89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 00

RSP: 0018:88808fd9f670 EFLAGS: 00010007
RAX: dc00 RBX: 8880a96a97c0 RCX: 8681f5bd
RDX: 0005 RSI: 8681f5cb RDI: 002c
RBP: 88808fd9f6a8 R08: 888086a1a000 R09: ed1011fb3ec4
R10: ed1011fb3ec3 R11: 0003 R12: 
R13: 8880a96a9ce4 R14: 0002e400 R15: 88809aeecc00
FS:  026d4940() GS:8880ae80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 00424ec0 CR3: 8e163000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400

Re: [GIT PULL] libnvdimm fixes for v5.0-rc4

[Linus Torvalds]

On Sat, Jan 26, 2019 at 3:31 PM Williams, Dan J
 wrote:
>
> Hi Linus, please pull from:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
> tags/libnvdimm-fixes-5.0-rc4

Hmm. One more pr-tracker-bot note: going through the pull requests
from the last week, I notice that this one didn't get a pr-tracker
response.

It looks like lkml still hates you, so your pull request email never
made it to the list despite being cc'd. And thus it never makes it to
the lore and pr-tracker-bot infrastructure either.

Have you tried looking into why lkml has that red-hot hatred of your emails?

Because it does seem to be personal - you have pissed off the email
gods some way. Did you get a bounce?

   Linus

Re: [PATCH] platform/x86: intel_int0002_vgpio: Implement irq_set_wake

[Maxim Mikityanskiy]

On Sat, Feb 2, 2019 at 12:52 AM Hans de Goede  wrote:
>
> Hi,
>
> On 1/31/19 8:47 PM, Maxim Mikityanskiy wrote:
> > Hi,
> >
> > On Mon, Sep 24, 2018 at 5:37 PM Hans de Goede  wrote:
> >>
> >> We were relying on the interrupt being shared with the ACPI SCI and the
> >> ACPI core calling irq_set_wake. But that does not always happen on
> >> Bay Trail devices, so we should do it ourselves.
> >>
> >> This fixes wake from USB not working on various Bay Trail devices.
> >
> > This patch breaks suspend on ASUS E202SA (bisecting pointed me to this
> > patch, and if I revert it and build 4.20.5 without this patch,
> > everything works flawlessly).
>
> Thank you for the bug report, can you please test 4.20.5 with the attached
> patch on top? That should fix it. Once I've confirmation that this fixes
> things I will submit the patch upstream.

I've tested your patch against both 4.20.5 and 4.20.6, and it works
fine. Thank you for such a quick fix.

> Regards,
>
> Hans
>
>
> >
> > This command fails with the following message:
> >
> > # echo mem > /sys/power/state
> > Error while writing to stdout
> > write_loop: Device or resource busy
> >
> > And here is dmesg output:
> >
> > [  224.077275] PM: suspend entry (deep)
> > [  224.077286] PM: Syncing filesystems ... done.
> > [  225.495014] Freezing user space processes ... (elapsed 0.003 seconds) 
> > done.
> > [  225.498540] OOM killer disabled.
> > [  225.498543] Freezing remaining freezable tasks ... (elapsed 0.002
> > seconds) done.
> > [  225.500693] printk: Suspending console(s) (use no_console_suspend to 
> > debug)
> > [  225.502793] wlp1s0: deauthenticating from 00:03:7f:12:34:56 by
> > local choice (Reason: 3=DEAUTH_LEAVING)
> > [  225.535333] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> > [  225.535882] sd 0:0:0:0: [sda] Stopping disk
> > [  226.969070] ACPI: EC: interrupt blocked
> > [  227.002156] ACPI: Preparing to enter system sleep state S3
> > [  227.007890] ACPI: EC: event blocked
> > [  227.007895] ACPI: EC: EC stopped
> > [  227.007900] PM: Saving platform NVS memory
> > [  227.008264] Disabling non-boot CPUs ...
> > [  227.034114] smpboot: CPU 1 is now offline
> > [  227.088320] smpboot: CPU 2 is now offline
> > [  227.141513] smpboot: CPU 3 is now offline
> > [  227.147086] Enabling non-boot CPUs ...
> > [  227.147187] x86: Booting SMP configuration:
> > [  227.147190] smpboot: Booting Node 0 Processor 1 APIC 0x2
> > [  227.147916]  cache: parent cpu1 should not be sleeping
> > [  227.148354] CPU1 is up
> > [  227.148424] smpboot: Booting Node 0 Processor 2 APIC 0x4
> > [  227.149800]  cache: parent cpu2 should not be sleeping
> > [  227.151143] CPU2 is up
> > [  227.151187] smpboot: Booting Node 0 Processor 3 APIC 0x6
> > [  227.152399]  cache: parent cpu3 should not be sleeping
> > [  227.153883] CPU3 is up
> > [  227.154876] ACPI: EC: EC started
> > [  227.155282] ACPI: Waking up from system sleep state S3
> > [  227.159874] ACPI: button: The lid device is not compliant to SW_LID.
> > [  227.169441] ACPI: EC: interrupt unblocked
> > [  228.236790] ACPI: EC: event unblocked
> > [  228.241950] rtlwifi: rtlwifi: wireless switch is on
> > [  228.251865] sd 0:0:0:0: [sda] Starting disk
> > [  228.476637] usb 1-4: reset full-speed USB device number 2 using xhci_hcd
> > [  228.562879] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> > [  228.563924] ata2: SATA link down (SStatus 4 SControl 300)
> > [  228.564979] ata1.00: supports DRM functions and may not be fully 
> > accessible
> > [  228.565493] ata1.00: NCQ Send/Recv Log not supported
> > [  228.567649] ata1.00: supports DRM functions and may not be fully 
> > accessible
> > [  228.568252] ata1.00: NCQ Send/Recv Log not supported
> > [  228.570075] ata1.00: configured for UDMA/133
> > [  228.580412] ahci :00:13.0: port does not support device sleep
> > [  228.639349] Bluetooth: hci0: RTL: rtl: examining hci_ver=06
> > hci_rev=0e2f lmp_ver=06 lmp_subver=a041
> >
> > [  228.639368] Bluetooth: hci0: RTL: rtl: unknown IC info, lmp subver
> > a041, hci rev 0e2f, hci ver 0006
> > [  228.639742] acpi LNXPOWER:01: Turning OFF
> > [  228.640033] OOM killer enabled.
> > [  228.640040] Restarting tasks ... done.
> > [  228.795406] PM: suspend exit
> > [  228.800399] audit: type=1130 audit(1548962671.104:94): pid=1 uid=0
> > auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd"
> > exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> > res=success'
> > [  229.067206] wlp1s0: authenticate with 12:34:56:78:90:12
> > [  229.067823] wlp1s0: send auth to 12:34:56:78:90:12 (try 1/3)
> > [  229.070955] wlp1s0: authenticated
> > [  229.072395] wlp1s0: associate with 12:34:56:78:90:12 (try 1/3)
> > [  229.074505] wlp1s0: RX AssocResp from 12:34:56:78:90:12 (capab=0x11
> > status=0 aid=2)
> > [  229.074819] wlp1s0: associated
> > [  233.809200] audit: type=1131 audit(1548962676.106:95): pid=1 uid=0
> > auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd"
> > 

Re: [GIT PULL] Devicetree fix for 5.0-rc5

[pr-tracker-bot]

The pull request you sent on Sat, 2 Feb 2019 11:10:06 -0600:

> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git 
> tags/devicetree-fixes-for-5.0-3

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/12491ed354d23c0ecbe02459bf4be58b8c772bc8

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] SCSI fixes for 5.0-rc4

[pr-tracker-bot]

The pull request you sent on Fri, 01 Feb 2019 16:06:45 -0800:

> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3cde55ee7921609331178c84cca485491c97df2a

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

RE: [PATCH V9 3/5] i2c: tegra: Add DMA support

[Sowjanya Komatineni]

>  +static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev) {
>  +struct dma_chan *dma_chan;
>  +u32 *dma_buf;
>  +dma_addr_t dma_phys;
>  +int err = 0;
>  +
>  +if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA))
>  +return -ENODEV;
> >>>
> >>> Driver shall not fail to probe if DMA driver is disabled, but to continue 
> >>> with the PIO-only mode available.
> >>>
> >>> Should be:
> >>>
> >>>   if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA))
> >>>   return 0;
> >>>
> >> Except EPROBE_DEFER, anything else returned from tegra_i2c_init_dma 
> >> (ENODEV/ENOMEM) is ignored in i2c_probe DMA mode decision is based on xfer 
> >> size and availability of dma channel or can be changed based on valid dma 
> >> buf to shorten the line.
> >>
> > 
> > Ah, sorry. I missed that, seems good then.
> > 
>
> BTW, it may be worthwhile to move out the error code handling into 
> tegra_i2c_init_dma() for clarity. It also won't hurt to not ignore errors 
> other than -ENODEV.

Either ways are same. To be more readable/clear on error types for diff cases 
and errors that we are ignoring, I am explicitly keeping error codecs 
(EPROBE_DEFER/ENODEV/ENOMEM) same way.
Also in probe for readability checking with EPROBE_DEFER which explicitly 
indicating we keep deferring i2c probe rather than simple return.

Re: [PATCH 1/3] sched/wait: use freezable_schedule when possible

[Joel Fernandes]

On Fri, Feb 01, 2019 at 06:38:05AM +0100, Hugo Lefeuvre wrote:
> Replace schedule(); try_to_freeze() by freezable_schedule().
> 
> Tasks calling freezable_schedule() set the PF_FREEZER_SKIP flag
> before calling schedule(). Unlike tasks calling schedule();
> try_to_freeze() tasks calling freezable_schedule() are not awaken by
> try_to_freeze_tasks(). Instead they call try_to_freeze() when they
> wake up if the freeze is still underway.
> 
> It is not a problem since sleeping tasks can't do anything which isn't
> allowed for a frozen task while sleeping.
> 
> The result is a potential performance gain during freeze, since less
> tasks have to be awaken.

I'm curious did you try the freezing process and see if pointless wakeups are
reduced?  That would be an added bonus if you did.

Otherwise seems like a nice change. Peter and Rafael, what do you think?

thanks,

 - Joel

Re: perf_event_open+clone = unkillable process

[Jiri Olsa]

On Fri, Feb 01, 2019 at 06:06:03PM +0100, Dmitry Vyukov wrote:
> On Fri, Feb 1, 2019 at 5:48 PM Dmitry Vyukov  wrote:
> >
> > Hello,
> >
> > The following program creates an unkillable process that eats CPU.
> > /proc/pid/stack is empty, I am not sure what other info I can provide.
> >
> > Tested is on upstream commit 4aa9fc2a435abe95a1e8d7f8c7b3d6356514b37a.
> > Config is attached.
> 
> Looking through other reproducers that create unkillable processes, I
> think I found a much simpler reproducer (below). It's single threaded
> and just setups SIGBUS handler and does timer_create+timer_settime to
> send repeated SIGBUS. The resulting process can't be killed with
> SIGKILL.
> +Thomas for timers.

nice, I managed to kill it by strace ;-)

[jolsa@krava perf]$ strace  -p 10725
strace: Process 10725 attached
--- stopped by SIGBUS ---
--- stopped by SIGBUS ---
--- stopped by SIGBUS ---
--- stopped by SIGBUS ---
+++ killed by SIGINT +++

+Oleg

jirka

> 
> 
> // autogenerated by syzkaller (https://github.com/google/syzkaller)
> 
> #define _GNU_SOURCE
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> static __thread int skip_segv;
> static __thread jmp_buf segv_env;
> 
> static void segv_handler(int sig, siginfo_t* info, void* ctx)
> {
>   uintptr_t addr = (uintptr_t)info->si_addr;
>   const uintptr_t prog_start = 1 << 20;
>   const uintptr_t prog_end = 100 << 20;
>   if (__atomic_load_n(_segv, __ATOMIC_RELAXED) &&
>   (addr < prog_start || addr > prog_end)) {
> _longjmp(segv_env, 1);
>   }
>   exit(sig);
> }
> 
> static void install_segv_handler(void)
> {
>   struct sigaction sa;
>   memset(, 0, sizeof(sa));
>   sa.sa_handler = SIG_IGN;
>   syscall(SYS_rt_sigaction, 0x20, , NULL, 8);
>   syscall(SYS_rt_sigaction, 0x21, , NULL, 8);
>   memset(, 0, sizeof(sa));
>   sa.sa_sigaction = segv_handler;
>   sa.sa_flags = SA_NODEFER | SA_SIGINFO;
>   sigaction(SIGSEGV, , NULL);
>   sigaction(SIGBUS, , NULL);
> }
> 
> int main(void)
> {
>   syscall(__NR_mmap, 0x2000, 0x100, 3, 0x32, -1, 0);
>   install_segv_handler();
>   int tid = syscall(__NR_gettid);
>   *(uint64_t*)0x2000 = 0;
>   *(uint32_t*)0x2008 = 7;
>   *(uint32_t*)0x200c = 4;
>   *(uint32_t*)0x2010 = tid;
>   syscall(__NR_timer_create, 0, 0x2000, 0x2080);
>   *(uint64_t*)0x2004a000 = 0;
>   *(uint64_t*)0x2004a008 = 1;
>   *(uint64_t*)0x2004a010 = 7;
>   *(uint64_t*)0x2004a018 = 0xe4c;
>   syscall(__NR_timer_settime, 0, 3, 0x2004a000, 0);
>   return 0;
> }

RE: [PATCH V9 3/5] i2c: tegra: Add DMA support

[Sowjanya Komatineni]

> > This patch adds DMA support for Tegra I2C.
> > 
> > Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for 
> > transfer size of the max FIFO depth and DMA mode is used for transfer 
> > size higher than max FIFO depth to save CPU overhead.
> > 
> > PIO mode needs full intervention of CPU to fill or empty FIFO's and 
> > also need to service multiple data requests interrupt for the same 
> > transaction. This adds delay between data bytes of the same transfer 
> > when CPU is fully loaded and some slave devices has internal timeout 
> > for no bus activity and stops transaction to avoid bus hang. DMA mode 
> > is helpful in such cases.
> > 
> > DMA mode is also helpful for Large transfers during downloading or 
> > uploading FW over I2C to some external devices.
> > 
> > Signed-off-by: Sowjanya Komatineni 
> > ---
>
>
> > +static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev) {
> > +   struct dma_chan *dma_chan;
> > +   u32 *dma_buf;
> > +   dma_addr_t dma_phys;
> > +   int err = 0;
> > +
> > +   if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA))
> > +   return -ENODEV;
>
> Another detail is that we need to keep older kernels working on T186+ after 
> its device-tree will get the "dmas" property, device-tree changes shall be 
> backwards-compatible with older kernels. Hence we need to check that platform 
> actually wants the APB DMA driver, otherwise T186+ will be failing with 
> -EPROBE_DEFER.

Yes, that will be a separate patch later for adding DMA support for Tegra186 
and later chips once we check on GPCDMA upstream

Re: [PATCH] swiotlb: Return error from swiotlb_init_with_tbl()

[kbuild test robot]

Hi Joerg,

I love your patch! Perhaps something to improve:

[auto build test WARNING on swiotlb/linux-next]
[also build test WARNING on v5.0-rc4]
[cannot apply to next-20190201]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Joerg-Roedel/swiotlb-Return-error-from-swiotlb_init_with_tbl/20190203-013129
base:   https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git 
linux-next
config: riscv-tinyconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 8.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=riscv 

All warnings (new ones prefixed by >>):

   kernel/dma/swiotlb.c: In function 'swiotlb_init_with_tbl':
>> kernel/dma/swiotlb.c:230:17: warning: passing argument 1 of 'memblock_free' 
>> makes integer from pointer without a cast [-Wint-conversion]
  memblock_free(io_tlb_list,
^~~
   In file included from kernel/dma/swiotlb.c:42:
   include/linux/memblock.h:123:31: note: expected 'phys_addr_t' {aka 'long 
long unsigned int'} but argument is of type 'unsigned int *'
int memblock_free(phys_addr_t base, phys_addr_t size);
  ^~~~
   kernel/dma/swiotlb.c:234:17: warning: passing argument 1 of 'memblock_free' 
makes integer from pointer without a cast [-Wint-conversion]
  memblock_free(io_tlb_orig_addr,
^~~~
   In file included from kernel/dma/swiotlb.c:42:
   include/linux/memblock.h:123:31: note: expected 'phys_addr_t' {aka 'long 
long unsigned int'} but argument is of type 'phys_addr_t *' {aka 'long long 
unsigned int *'}
int memblock_free(phys_addr_t base, phys_addr_t size);
  ^~~~

vim +/memblock_free +230 kernel/dma/swiotlb.c

   190  
   191  int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int 
verbose)
   192  {
   193  unsigned long i, bytes;
   194  
   195  bytes = nslabs << IO_TLB_SHIFT;
   196  
   197  io_tlb_nslabs = nslabs;
   198  io_tlb_start = __pa(tlb);
   199  io_tlb_end = io_tlb_start + bytes;
   200  
   201  /*
   202   * Allocate and initialize the free list array.  This array is 
used
   203   * to find contiguous free memory regions of size up to 
IO_TLB_SEGSIZE
   204   * between io_tlb_start and io_tlb_end.
   205   */
   206  io_tlb_list = memblock_alloc_nopanic(
   207  PAGE_ALIGN(io_tlb_nslabs * sizeof(int)),
   208  PAGE_SIZE);
   209  io_tlb_orig_addr = memblock_alloc_nopanic(
   210  PAGE_ALIGN(io_tlb_nslabs * 
sizeof(phys_addr_t)),
   211  PAGE_SIZE);
   212  if (io_tlb_list == NULL || io_tlb_orig_addr == NULL)
   213  goto out_fail;
   214  
   215  for (i = 0; i < io_tlb_nslabs; i++) {
   216  io_tlb_list[i] = IO_TLB_SEGSIZE - OFFSET(i, 
IO_TLB_SEGSIZE);
   217  io_tlb_orig_addr[i] = INVALID_PHYS_ADDR;
   218  }
   219  io_tlb_index = 0;
   220  
   221  if (verbose)
   222  swiotlb_print_info();
   223  
   224  swiotlb_set_max_segment(io_tlb_nslabs << IO_TLB_SHIFT);
   225  
   226  return 0;
   227  
   228  out_fail:
   229  if (io_tlb_list)
 > 230  memblock_free(io_tlb_list,
   231PAGE_ALIGN(io_tlb_nslabs * sizeof(int)));
   232  
   233  if (io_tlb_orig_addr)
   234  memblock_free(io_tlb_orig_addr,
   235PAGE_ALIGN(io_tlb_nslabs * 
sizeof(phys_addr_t)));
   236  
   237  io_tlb_list  = NULL;
   238  io_tlb_orig_addr = NULL;
   239  io_tlb_end   = 0;
   240  io_tlb_start = 0;
   241  io_tlb_nslabs= 0;
   242  max_segment  = 0;
   243  
   244  return -ENOMEM;
   245  }
   246  

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


.config.gz
Description: application/gzip

Re: System crash with perf_fuzzer (kernel: 5.0.0-rc3)

[Vince Weaver]

On Fri, 1 Feb 2019, Jiri Olsa wrote:

> > 
> > I've just started fuzzing with the patch applied.  Often it takes a few 
> > hours to trigger the bug.
> 
> cool, thanks

I let it run overnight and no crash.

> > Added question about this bug.  It appeared that the crash was triggered 
> > by the BTS driver over-writing kernel memory.  The data being written, was 
> > this user controllable?  Meaning, is this a security issue being fixed, or 
> > just a crashing issue?
> 
> yea, I have an example that can trigger it immediately

I mean: the crash is happening because data structures are getting 
over-written by the BTS driver.  Depending who and what is doing this, 
this could be a security issue (i.e. if it was raw BTS data that was 
partially userspace controlled values).  Though even if this were the case 
it would probably be hard to exploit.

Vince

Re: [PATCH] Move static keyword at beginning of declaration

[Geoff Levand]

On 2/2/19 5:05 AM, Mathieu Malaterre wrote:
> Move the static keyword around to remove the following warnings (W=1):
> 
>   arch/powerpc/platforms/ps3/os-area.c:212:1: error: 'static' is not at 
> beginning of declaration [-Werror=old-style-declaration]
>   arch/powerpc/platforms/ps3/system-bus.c:45:1: error: 'static' is not at 
> beginning of declaration [-Werror=old-style-declaration]
> 
> -struct saved_params {
> +static struct saved_params {
>   unsigned int valid;
>   s64 rtc_diff;
>   unsigned int av_multi_out;
> -} static saved_params;
> +} saved_params;

Seems fine.

Acked-by: Geoff Levand 

[PATCH] net: dsa: Fix lockdep false positive splat

[Marc Zyngier]

Creating a macvtap on a DSA-backed interface results in the following
splat when lockdep is enabled:

[   19.638080] IPv6: ADDRCONF(NETDEV_CHANGE): lan0: link becomes ready
[   23.041198] device lan0 entered promiscuous mode
[   23.043445] device eth0 entered promiscuous mode
[   23.049255]
[   23.049557] 
[   23.055021] WARNING: possible recursive locking detected
[   23.060490] 5.0.0-rc3-00013-g56c857a1b8d3 #118 Not tainted
[   23.066132] 
[   23.071598] ip/2861 is trying to acquire lock:
[   23.076171] f61990cb (_xmit_ETHER){+...}, at: 
dev_set_rx_mode+0x1c/0x38
[   23.083693]
[   23.083693] but task is already holding lock:
[   23.089696] ecf0c3b4 (_xmit_ETHER){+...}, at: dev_uc_add+0x24/0x70
[   23.096774]
[   23.096774] other info that might help us debug this:
[   23.103494]  Possible unsafe locking scenario:
[   23.103494]
[   23.109584]CPU0
[   23.112093]
[   23.114601]   lock(_xmit_ETHER);
[   23.117917]   lock(_xmit_ETHER);
[   23.121233]
[   23.121233]  *** DEADLOCK ***
[   23.121233]
[   23.127325]  May be due to missing lock nesting notation
[   23.127325]
[   23.134315] 2 locks held by ip/2861:
[   23.137987]  #0: 3b766c72 (rtnl_mutex){+.+.}, at: 
rtnetlink_rcv_msg+0x338/0x4e0
[   23.146231]  #1: ecf0c3b4 (_xmit_ETHER){+...}, at: 
dev_uc_add+0x24/0x70
[   23.153757]
[   23.153757] stack backtrace:
[   23.158243] CPU: 0 PID: 2861 Comm: ip Not tainted 
5.0.0-rc3-00013-g56c857a1b8d3 #118
[   23.166212] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT)
[   23.172843] Call trace:
[   23.175358]  dump_backtrace+0x0/0x188
[   23.179116]  show_stack+0x14/0x20
[   23.182524]  dump_stack+0xb4/0xec
[   23.185928]  __lock_acquire+0x123c/0x1860
[   23.190048]  lock_acquire+0xc8/0x248
[   23.193724]  _raw_spin_lock_bh+0x40/0x58
[   23.197755]  dev_set_rx_mode+0x1c/0x38
[   23.201607]  dev_set_promiscuity+0x3c/0x50
[   23.205820]  dsa_slave_change_rx_flags+0x5c/0x70
[   23.210567]  __dev_set_promiscuity+0x148/0x1e0
[   23.215136]  __dev_set_rx_mode+0x74/0x98
[   23.219167]  dev_uc_add+0x54/0x70
[   23.222575]  macvlan_open+0x170/0x1d0
[   23.226336]  __dev_open+0xe0/0x160
[   23.229830]  __dev_change_flags+0x16c/0x1b8
[   23.234132]  dev_change_flags+0x20/0x60
[   23.238074]  do_setlink+0x2d0/0xc50
[   23.241658]  __rtnl_newlink+0x5f8/0x6e8
[   23.245601]  rtnl_newlink+0x50/0x78
[   23.249184]  rtnetlink_rcv_msg+0x360/0x4e0
[   23.253397]  netlink_rcv_skb+0xe8/0x130
[   23.257338]  rtnetlink_rcv+0x14/0x20
[   23.261012]  netlink_unicast+0x190/0x210
[   23.265043]  netlink_sendmsg+0x288/0x350
[   23.269075]  sock_sendmsg+0x18/0x30
[   23.272659]  ___sys_sendmsg+0x29c/0x2c8
[   23.276602]  __sys_sendmsg+0x60/0xb8
[   23.280276]  __arm64_sys_sendmsg+0x1c/0x28
[   23.284488]  el0_svc_common+0xd8/0x138
[   23.288340]  el0_svc_handler+0x24/0x80
[   23.292192]  el0_svc+0x8/0xc

This looks fairly harmless (no actual deadlock occurs), and is
fixed in a similar way to c6894dec8ea9 ("bridge: fix lockdep
addr_list_lock false positive splat") by putting the addr_list_lock
in its own lockdep class.

Signed-off-by: Marc Zyngier 
---
 net/dsa/master.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/dsa/master.c b/net/dsa/master.c
index 71bb15f491c8..54f5551fb799 100644
--- a/net/dsa/master.c
+++ b/net/dsa/master.c
@@ -205,6 +205,8 @@ static void dsa_master_reset_mtu(struct net_device *dev)
rtnl_unlock();
 }
 
+static struct lock_class_key dsa_master_addr_list_lock_key;
+
 int dsa_master_setup(struct net_device *dev, struct dsa_port *cpu_dp)
 {
int ret;
@@ -218,6 +220,8 @@ int dsa_master_setup(struct net_device *dev, struct 
dsa_port *cpu_dp)
wmb();
 
dev->dsa_ptr = cpu_dp;
+   lockdep_set_class(>addr_list_lock,
+ _master_addr_list_lock_key);
 
ret = dsa_master_ethtool_setup(dev);
if (ret)
-- 
2.20.1

Re: [PATCH] PCI / ACPI: Don't clear pme_poll on device that has unreliable ACPI wake

[Kai Heng Feng]

Hi Bjorn,

> On Jan 28, 2019, at 3:51 PM, Kai Heng Feng  
> wrote:
[snipped]

>> If I understand correctly, the bugzilla lspci
>> (https://bugzilla.kernel.org/attachment.cgi?id=280691) was collected
>> at point 8, and it shows PME_Status=1 when it should be 0.
>> 
>> If we write a 1 to PME_Status to clear it, and it remains set, that's
>> obviously a hardware defect, and Intel should document that in an
>> erratum, and a quirk would be the appropriate way to work around it.
>> But I doubt that's what's happening.
> 
> I’ll ask them if they can provide an erratum.

Got confirmed with e1000e folks, I219 (the device in question) doesn’t really 
support runtime D3.
I also checked the behavior of the device under Windows, and it stays at D0 all 
the time even when it’s not in use.

So I sent a patch [1] to disable it.

[1] https://lkml.org/lkml/2019/2/2/200

Kai-Heng

[PATCH] e1000e: Disable runtime PM on CNP+

[Kai-Heng Feng]

There are some new e1000e devices can only be woken up from D3 one time,
by plugging ethernet cable. Subsequent cable plugging does set PME bit
correctly, but it still doesn't get woken up.

Since e1000e connects to the root complex directly, we rely on ACPI to
wake it up. In this case, the GPE from _PRW only works once and stops
working after that. Though it appears to be a platform bug, e1000e
maintainers confirmed that I219 does not support D3.

So disable runtime PM on CNP+ chips. We may need to disable earlier
generations if this bug also hit older platforms.

Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=280819
Signed-off-by: Kai-Heng Feng 
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 189f231075c2..9366b9d19a6f 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -7351,7 +7351,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
e1000_print_device_info(adapter);
 
-   if (pci_dev_run_wake(pdev))
+   if (pci_dev_run_wake(pdev) && hw->mac.type < e1000_pch_cnp)
pm_runtime_put_noidle(>dev);
 
return 0;
-- 
2.17.1

Re: [PATCH AUTOSEL 4.19 083/258] drm: Move drm_mode_setcrtc() local re-init to failure path

[Sasha Levin]

On Mon, Jan 28, 2019 at 04:03:41PM -0500, Sean Paul wrote:

On Mon, Jan 28, 2019 at 10:56:29AM -0500, Sasha Levin wrote:

From: Sean Paul 

[ Upstream commit c232e9f41b136c141df9938024e521191a7b910d ]

Instead of always re-initializing the variables we need to clean up on
out, move the re-initialization into the branch that goes back to retry
label.

This is a lateral move right now, but will allow us to pull out the
modeset locking into common code. I kept this change separate to make
things easier to review.

Changes in v2:
- None

Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181129150423.239081-2-s...@poorly.run
Signed-off-by: Sasha Levin 


This probably doesn't need to get pulled back to stable. It was a pre-cursor for
some new helper macros that also don't need to be pulled back.

(Same comment for the 4.20 version)


Now dropped, thank you.

--
Thanks,
Sasha

Re: [PATCH AUTOSEL 4.19 181/258] tools uapi asm: Update asm-generic/unistd.h copy

[Sasha Levin]

On Mon, Jan 28, 2019 at 05:56:55PM +0100, Arnd Bergmann wrote:

On Mon, Jan 28, 2019 at 5:07 PM Sasha Levin  wrote:


From: Arnaldo Carvalho de Melo 

[ Upstream commit 89a0948984896352cac1ebe079cb3d64d6c3adc6 ]

To get the change in:

  b7d624ab4312 ("asm-generic: unistd.h: fixup broken macro include.")

That doesn't imply in any changes in the tools.


This one should only be in linux-4.20, not any earlier tree that
does not also backport b7d624ab4312, otherwise the uapi headers
are wrong.

I don't think we want b7d624ab4312 backported, it would only
be useful if we backport all y2038 patches.


I dropped it, thanks!

--
Thanks,
Sasha

Re: [PATCH v5 07/13] x86/fsgsbase/64: When copying a thread, use the FSGSBASE instructions if available

[Andy Lutomirski]

On Fri, Feb 1, 2019 at 12:54 PM Chang S. Bae  wrote:
>
> Copy real FS/GSBASE values instead of approximation when FSGSBASE is
> enabled.
>
> Factoring out to save_fsgs() does not result in the same behavior because
> save_base_legacy() does not copy FS/GSBASE when the index is zero.
>
> Signed-off-by: Chang S. Bae 
> Cc: Andy Lutomirski 
> Cc: H. Peter Anvin 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Andi Kleen 
> ---
>  arch/x86/kernel/process_64.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index d8ade9530fdb..648e43b58c69 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -477,10 +477,16 @@ int copy_thread_tls(unsigned long clone_flags, unsigned 
> long sp,
> p->thread.sp = (unsigned long) fork_frame;
> p->thread.io_bitmap_ptr = NULL;
>
> -   savesegment(gs, p->thread.gsindex);
> -   p->thread.gsbase = p->thread.gsindex ? 0 : me->thread.gsbase;
> savesegment(fs, p->thread.fsindex);
> -   p->thread.fsbase = p->thread.fsindex ? 0 : me->thread.fsbase;
> +   savesegment(gs, p->thread.gsindex);
> +   if (static_cpu_has(X86_FEATURE_FSGSBASE)) {
> +   p->thread.fsbase = rdfsbase();
> +   p->thread.gsbase = __rdgsbase_inactive();
> +   } else {
> +   /* save_base_legacy() does not set base when index is zero. */

After looking at this a bit, I propose that we just clean this up all
the way.  Can't this whole mess be changed to:

save_fsgs(me);
p->thread.fsindex = me->thread.fsindex;
p->thread.fsbase = me->thread.fsbase;
p->thread.gsindex = me->thread.gsindex;
p->thread.gsbase = me->thread.gsbase;

This will avoid all of the horrible tracing through the logic to
figure out why the code is correct.

Sure, it'll be a few cycles slower with FSGSBASE, but this isn't
really a fast path, and if we ever really care, we can optimize it
later.

Re: [PATCH 02/18] dmaengine: imx-sdma: pass struct device to DMA API functions

[Christoph Hellwig]

On Sat, Feb 02, 2019 at 03:41:21PM +0530, Vinod Koul wrote:
> On 01-02-19, 09:47, Christoph Hellwig wrote:
> > The DMA API generally relies on a struct device to work properly, and
> > only barely works without one for legacy reasons.  Pass the easily
> > available struct device from the platform_device to remedy this.
> 
> This looks good to me but fails to apply. Can you please base it on
> dmaengine-next or linux-next please and resend

commit ceaf52265148d3a5ca24237fd1c709caa5f46184
Author: Andy Duan 
Date:   Fri Jan 11 14:29:49 2019 +

dmaengine: imx-sdma: pass ->dev to dma_alloc_coherent() API

in linux-next actually is equivalent to this patch, so we can drop
this one.

> 
> Thanks
> -- 
> ~Vinod
---end quoted text---

Re: [PATCH net-next v5 12/12] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW

[Oliver Hartkopp]

Hi all,

On 02.02.19 16:34, Deepa Dinamani wrote:

Add new socket timeout options that are y2038 safe.

(..)


diff --git a/arch/alpha/include/uapi/asm/socket.h 
b/arch/alpha/include/uapi/asm/socket.h
index 9826d1db71d0..0d0fddb7e738 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -119,19 +119,25 @@
  #define SO_TIMESTAMPNS_NEW  64
  #define SO_TIMESTAMPING_NEW 65
  
-#if !defined(__KERNEL__)

+#define SO_RCVTIMEO_NEW 66
+#define SO_SNDTIMEO_NEW 67
  
-#define	SO_RCVTIMEO SO_RCVTIMEO_OLD

-#defineSO_SNDTIMEO SO_SNDTIMEO_OLD
+#if !defined(__KERNEL__)
  
  #if __BITS_PER_LONG == 64

  #define SO_TIMESTAMP  SO_TIMESTAMP_OLD
  #define SO_TIMESTAMPNSSO_TIMESTAMPNS_OLD
  #define SO_TIMESTAMPING SO_TIMESTAMPING_OLD
+
+#define SO_RCVTIMEOSO_RCVTIMEO_OLD
+#define SO_SNDTIMEOSO_SNDTIMEO_OLD


Maybe I'm a bit late in this discussion as you are already in v5 ...

I can see patches making the transition in different steps where it 
might be helpful to name them *_OLD and *_NEW to understand the patches.


But in the end the naming stays in the kernel for a very long time and I 
remember myself (in early years) to name things 'new', 'new2', 'new3'.


In fact SO_TIMESTAMP_OLD should be named SO_TIMESTAMP32 and 
SO_TIMESTAMP_NEW should be named SO_TIMESTAMP64.


Especially as it tells you what is 'inside', the naming of these new 
introduced constants should be replaced with *32 and *64 names.


The documentation and the other comments still fit perfectly then.

Regards,
Oliver

Re: [PATCH v3 1/3] iio: chemical: add support for Plantower PMS7003 sensor

[Jonathan Cameron]

On Fri,  1 Feb 2019 22:57:57 +0100
Tomasz Duszynski  wrote:

> Add support for Plantower PMS7003 particulate matter sensor.
> 
> Signed-off-by: Tomasz Duszynski 
Other than waiting for review of the binding and potentially that minor
change to the gpio naming I suggested, this looks good to me.

Thanks,

Jonathan

> ---
>  drivers/iio/chemical/Kconfig   |  10 +
>  drivers/iio/chemical/Makefile  |   1 +
>  drivers/iio/chemical/pms7003.c | 340 +
>  3 files changed, 351 insertions(+)
>  create mode 100644 drivers/iio/chemical/pms7003.c
> 
> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
> index 57832b4360e9..d5d146e9e372 100644
> --- a/drivers/iio/chemical/Kconfig
> +++ b/drivers/iio/chemical/Kconfig
> @@ -61,6 +61,16 @@ config IAQCORE
> iAQ-Core Continuous/Pulsed VOC (Volatile Organic Compounds)
> sensors
>  
> +config PMS7003
> + tristate "Plantower PMS7003 particulate matter sensor"
> + depends on SERIAL_DEV_BUS
> + help
> +   Say Y here to build support for the Plantower PMS7003 particulate
> +   matter sensor.
> +
> +   To compile this driver as a module, choose M here: the module will
> +   be called pms7003.
> +
>  config SPS30
>   tristate "SPS30 particulate matter sensor"
>   depends on I2C
> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
> index 65bf0f89c0e4..f5d1365acb49 100644
> --- a/drivers/iio/chemical/Makefile
> +++ b/drivers/iio/chemical/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_BME680_I2C) += bme680_i2c.o
>  obj-$(CONFIG_BME680_SPI) += bme680_spi.o
>  obj-$(CONFIG_CCS811) += ccs811.o
>  obj-$(CONFIG_IAQCORE)+= ams-iaq-core.o
> +obj-$(CONFIG_PMS7003) += pms7003.o
>  obj-$(CONFIG_SENSIRION_SGP30)+= sgp30.o
>  obj-$(CONFIG_SPS30) += sps30.o
>  obj-$(CONFIG_VZ89X)  += vz89x.o
> diff --git a/drivers/iio/chemical/pms7003.c b/drivers/iio/chemical/pms7003.c
> new file mode 100644
> index ..0c913c60adde
> --- /dev/null
> +++ b/drivers/iio/chemical/pms7003.c
> @@ -0,0 +1,340 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Plantower PMS7003 particulate matter sensor driver
> + *
> + * Copyright (c) Tomasz Duszynski 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PMS7003_DRIVER_NAME "pms7003"
> +
> +#define PMS7003_MAGIC 0x424d
> +/* last 2 data bytes hold frame checksum */
> +#define PMS7003_MAX_DATA_LENGTH 28
> +#define PMS7003_CHECKSUM_LENGTH 2
> +#define PMS7003_PM10_OFFSET 10
> +#define PMS7003_PM2P5_OFFSET 8
> +#define PMS7003_PM1_OFFSET 6
> +
> +#define PMS7003_TIMEOUT msecs_to_jiffies(6000)
> +#define PMS7003_CMD_LENGTH 7
> +#define PMS7003_PM_MAX 1000
> +#define PMS7003_PM_MIN 0
> +
> +enum {
> + PM1,
> + PM2P5,
> + PM10,
> +};
> +
> +enum pms7003_cmd {
> + CMD_WAKEUP,
> + CMD_ENTER_PASSIVE_MODE,
> + CMD_READ_PASSIVE,
> + CMD_SLEEP,
> +};
> +
> +/*
> + * commands have following format:
> + *
> + * +--+--+-+--+-+---+---+
> + * | 0x42 | 0x4d | cmd | 0x00 | arg | cksum msb | cksum lsb |
> + * +--+--+-+--+-+---+---+
> + */
> +static const u8 pms7003_cmd_tbl[][PMS7003_CMD_LENGTH] = {
> + [CMD_WAKEUP] = { 0x42, 0x4d, 0xe4, 0x00, 0x01, 0x01, 0x74 },
> + [CMD_ENTER_PASSIVE_MODE] = { 0x42, 0x4d, 0xe1, 0x00, 0x00, 0x01, 0x70 },
> + [CMD_READ_PASSIVE] = { 0x42, 0x4d, 0xe2, 0x00, 0x00, 0x01, 0x71 },
> + [CMD_SLEEP] = { 0x42, 0x4d, 0xe4, 0x00, 0x00, 0x01, 0x73 },
> +};
> +
> +struct pms7003_frame {
> + u8 data[PMS7003_MAX_DATA_LENGTH];
> + u16 expected_length;
> + u16 length;
> +};
> +
> +struct pms7003_state {
> + struct serdev_device *serdev;
> + struct pms7003_frame frame;
> + struct completion frame_ready;
> + struct mutex lock; /* must be held whenever state gets touched */
> +};
> +
> +static int pms7003_do_cmd(struct pms7003_state *state, enum pms7003_cmd cmd)
> +{
> + int ret;
> +
> + ret = serdev_device_write(state->serdev, pms7003_cmd_tbl[cmd],
> +   PMS7003_CMD_LENGTH, PMS7003_TIMEOUT);
> + if (ret < PMS7003_CMD_LENGTH)
> + return ret < 0 ? ret : -EIO;
> +
> + ret = wait_for_completion_interruptible_timeout(>frame_ready,
> + PMS7003_TIMEOUT);
> + if (!ret)
> + ret = -ETIMEDOUT;
> +
> + return ret < 0 ? ret : 0;
> +}
> +
> +static u16 pms7003_get_pm(const u8 *data)
> +{
> + return clamp_val(get_unaligned_be16(data),
> +  PMS7003_PM_MIN, PMS7003_PM_MAX);
> +}
> +
> +static irqreturn_t pms7003_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct pms7003_state *state = 

Re: [PATCH v5 08/13] x86/fsgsbase/64: Introduce the FIND_PERCPU_BASE macro

[Andy Lutomirski]

On Fri, Feb 1, 2019 at 12:55 PM Chang S. Bae  wrote:
>
> GSBASE is used to find per-CPU data in the kernel. But when it is unknown,
> the per-CPU base can be found from the per_cpu_offset table with a CPU NR.
> The CPU NR is extracted from the limit field of the CPUNODE entry in GDT,
> or by the RDPID instruction.
>
> Also, add the GAS-compatible RDPID macro.
>
> The new macro will be used on a following patch.
>
> Suggested-by: H. Peter Anvin 
> Signed-off-by: Chang S. Bae 
> Cc: Andy Lutomirski 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Dave Hansen 
> Cc: Andi Kleen 
> ---
>  arch/x86/include/asm/fsgsbase.h | 46 +
>  arch/x86/include/asm/inst.h | 15 +++
>  2 files changed, 61 insertions(+)
>
> diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsbase.h
> index aefd53767a5d..eecca2250748 100644
> --- a/arch/x86/include/asm/fsgsbase.h
> +++ b/arch/x86/include/asm/fsgsbase.h
> @@ -78,6 +78,52 @@ extern void x86_gsbase_write_cpu_inactive(unsigned long 
> gsbase);
>
>  #endif /* CONFIG_X86_64 */
>
> +#else /* __ASSEMBLY__ */
> +
> +#ifdef CONFIG_X86_64
> +
> +#include 
> +
> +#if CONFIG_SMP

ifdef?

> +
> +/*
> + * CPU/node NR is loaded from the limit (size) field of a special segment
> + * descriptor entry in GDT.
> + */
> +.macro LOAD_CPU_AND_NODE_SEG_LIMIT reg:req
> +   movq$__CPUNODE_SEG, \reg
> +   lsl \reg, \reg
> +.endm
> +

Please put the alternative in here instead of in FIND_PERCPU_BASE.

> +/*
> + * Fetch the per-CPU GSBASE value for this processor and put it in @reg.
> + * We normally use %gs for accessing per-CPU data, but we are setting up
> + * %gs here and obviously can not use %gs itself to access per-CPU data.
> + */
> +.macro FIND_PERCPU_BASE reg:req
> +   /*
> +* The CPU/node NR is initialized earlier, directly in cpu_init().
> +* The CPU NR is extracted from it.
> +*/

This comment is unnecessary.

> +   ALTERNATIVE \
> +   "LOAD_CPU_AND_NODE_SEG_LIMIT \reg", \
> +   "RDPID  \reg", \
> +   X86_FEATURE_RDPID
> +   andq$VDSO_CPUNODE_MASK, \reg
> +   movq__per_cpu_offset(, \reg, 8), \reg
> +.endm
> +
> +#else
> +
> +.macro FIND_PERCPU_BASE reg:req
> +   /* Tracking the base offset value */

I don't understand this comment at all.  Please just remove it.

Re: [PATCH] dell_rbu: stop abusing the DMA API

[Christoph Hellwig]

On Fri, Feb 01, 2019 at 03:15:59PM -0800, Darren Hart wrote:
> On Tue, Jan 29, 2019 at 08:34:09AM +0100, Christoph Hellwig wrote:
> > For some odd reason dell_rbu actually seems to want the physical and
> > not a bus address for the allocated buffer.  Lets assume that actually
> > is correct given that it is BIOS-related and that is a good source
> > of insanity.  In that case we should not use dma_alloc_coherent with
> > a NULL device to allocate memory, but use GFP_DMA32 to stay under
> > the 32-bit BIOS limit.
> 
> + Mario re bios related physical address - is Christoph's assumption
> correct?
> 
> Christoph, did you observe a failure? If so, we should probably also
> tag for stable.

No, I've been auditing for DMA API (ab-)users that don't pass a
struct device.  Generally the fix was to just pass a struct device
that is easily available.  But dell_rbu doesn't actually seem to
be a "device" in the traditional sense, and the way it uses the
DMA API is really, really odd - it first does a virt_to_phys on
memory allocated from the page allocator (so works with physical
addresses in that case) and the retries with a dma_alloc_coherent
with a NULL argument, which in no way is guaranteed to you give
you something else, although for the current x86 implementation
will give you the equivalent of a GFP_DMA32 page allocator allocation
plus virt_to_phys.

Re: [PATCH v3 3/3] dt-bindings: iio: chemical: pms7003: add device tree support

[Jonathan Cameron]

On Fri,  1 Feb 2019 22:57:59 +0100
Tomasz Duszynski  wrote:

> Add device tree support for Plantower PMS7003 particulate matter sensor.
> 
> Signed-off-by: Tomasz Duszynski 
Hi Tomasz,

Sorry, I clearly didn't look at this in enough detail on earlier versions.
I think the set gpio is rather device specific so should have a vendor
prefix.

I would also like to get an opinion on the generic name from the devicetree
maintainers before we start to standardise on it.

Thanks,

Jonathan

> ---
>  .../iio/chemical/plantower,pms7003.txt| 20 +++
>  1 file changed, 20 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt 
> b/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt
> new file mode 100644
> index ..cbad95480e04
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt
> @@ -0,0 +1,20 @@
> +* Plantower PMS7003 particulate matter sensor
> +
> +Required properties:
> +- compatible: must be "plantower,pms7003"
> +- vcc-supply: phandle to the regulator that provides power to the sensor
> +
> +Optional properties:
> +- set-gpios: phandle to the GPIO connected to the SET line

Hmm. This is a somewhat 'unusual' one so should probably have a vendor prefix.

> +- reset-gpios: phandle to the GPIO connected to the RESET line

reset is common and clear in meaning, so vendor prefix probably not appropriate.
> +
> +Refer to serial/slave-device.txt for generic serial attached device bindings.
> +
> +Example:
> +
> + {
> + air-pollution-sensor {
> + vcc-supply = <_vcc5v0>;
> + compatible = "plantower,pms7003";
> + };
> +};

[GIT PULL] Devicetree fix for 5.0-rc5

[Rob Herring]

Linus,

Please pull.

Rob

The following changes since commit 75a080cde08d2dcba19ee864f9732094d93fab41:

  powerpc: chrp: Use of_node_is_type to access device_type (2019-01-19
10:35:42 -0600)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
tags/devicetree-fixes-for-5.0-3

for you to fetch changes up to 5fa98c2eda35fcd1a1d91a9785c390f54688240c:

  dt-bindings: Fix dt_binding_check target for in tree builds
(2019-01-23 09:15:57 -0600)


A single fix for building DT bindings in-tree.


Rob Herring (1):
  dt-bindings: Fix dt_binding_check target for in tree builds

 Documentation/devicetree/bindings/Makefile | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

Re: [PATCH] iio: chemical: sps30: remove printk format specifier

[Jonathan Cameron]

On Sat,  2 Feb 2019 10:00:03 +0100
Tomasz Duszynski  wrote:

> pr_fmt is used by printk wrappers. There are not any in the driver
> code so remove the format specifier.
> 
> Signed-off-by: Tomasz Duszynski 
Applied to the togreg branch of iio.git and pushed out
as testing for the autobuilders to mostly ignore it.

Thanks,

Jonathan

> ---
>  drivers/iio/chemical/sps30.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/iio/chemical/sps30.c b/drivers/iio/chemical/sps30.c
> index 376fac41ecb5..e03a28a67146 100644
> --- a/drivers/iio/chemical/sps30.c
> +++ b/drivers/iio/chemical/sps30.c
> @@ -7,8 +7,6 @@
>   * I2C slave address: 0x69
>   */
> 
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
>  #include 
>  #include 
>  #include 
> --
> 2.20.1
> 

Re: [PATCH v2 2/2] staging: iio: frequency: ad9833: Load clock using clock framework

[Jonathan Cameron]

On Fri, 1 Feb 2019 17:01:38 +0200
Beniamin Bia  wrote:

> From: Beniamin Bia 
> 
> The clock frequency is loaded from device-tree using clock framework
> instead of statically value. The change allow configuration of
> the device via device-trees and better initialization sequence.
> This is part of broader effort to add device-tree support to this driver
> and take it out from staging.
> 
> Signed-off-by: Beniamin Bia 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> Changes in v2:
> -the intermidiate clk variable was replaced by the variable in
>device state
> -st variable may be uninitialized warning was fixed by adding a new
>error label
>  drivers/staging/iio/frequency/ad9834.c | 35 ++
>  1 file changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/staging/iio/frequency/ad9834.c 
> b/drivers/staging/iio/frequency/ad9834.c
> index f4f5eaa15e30..f036f75d1f22 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -6,6 +6,7 @@
>   * Licensed under the GPL-2.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -71,7 +72,7 @@
>  struct ad9834_state {
>   struct spi_device   *spi;
>   struct regulator*reg;
> - unsigned intmclk;
> + struct clk  *mclk;
>   unsigned short  control;
>   unsigned short  devid;
>   struct spi_transfer xfer;
> @@ -110,12 +111,15 @@ static unsigned int ad9834_calc_freqreg(unsigned long 
> mclk, unsigned long fout)
>  static int ad9834_write_frequency(struct ad9834_state *st,
> unsigned long addr, unsigned long fout)
>  {
> + unsigned long clk_freq;
>   unsigned long regval;
>  
> - if (fout > (st->mclk / 2))
> + clk_freq = clk_get_rate(st->mclk);
> +
> + if (fout > (clk_freq / 2))
>   return -EINVAL;
>  
> - regval = ad9834_calc_freqreg(st->mclk, fout);
> + regval = ad9834_calc_freqreg(clk_freq, fout);
>  
>   st->freq_data[0] = cpu_to_be16(addr | (regval &
>  RES_MASK(AD9834_FREQ_BITS / 2)));
> @@ -415,7 +419,14 @@ static int ad9834_probe(struct spi_device *spi)
>   spi_set_drvdata(spi, indio_dev);
>   st = iio_priv(indio_dev);
>   mutex_init(>lock);
> - st->mclk = 2500;
> + st->mclk = devm_clk_get(>dev, NULL);
> +
> + ret = clk_prepare_enable(st->mclk);
> + if (ret) {
> + dev_err(>dev, "Failed to enable master clock\n");
> + goto error_disable_reg;
> + }
> +
>   st->spi = spi;
>   st->devid = spi_get_device_id(spi)->driver_data;
>   st->reg = reg;
> @@ -460,31 +471,32 @@ static int ad9834_probe(struct spi_device *spi)
>   ret = spi_sync(st->spi, >msg);
>   if (ret) {
>   dev_err(>dev, "device init failed\n");
> - goto error_disable_reg;
> + goto error_clock_unprepare;
>   }
>  
>   ret = ad9834_write_frequency(st, AD9834_REG_FREQ0, 100);
>   if (ret)
> - goto error_disable_reg;
> + goto error_clock_unprepare;
>  
>   ret = ad9834_write_frequency(st, AD9834_REG_FREQ1, 500);
>   if (ret)
> - goto error_disable_reg;
> + goto error_clock_unprepare;
>  
>   ret = ad9834_write_phase(st, AD9834_REG_PHASE0, 512);
>   if (ret)
> - goto error_disable_reg;
> + goto error_clock_unprepare;
>  
>   ret = ad9834_write_phase(st, AD9834_REG_PHASE1, 1024);
>   if (ret)
> - goto error_disable_reg;
> + goto error_clock_unprepare;
>  
>   ret = iio_device_register(indio_dev);
>   if (ret)
> - goto error_disable_reg;
> + goto error_clock_unprepare;
>  
>   return 0;
> -
> +error_clock_unprepare:
> + clk_disable_unprepare(st->mclk);
>  error_disable_reg:
>   regulator_disable(reg);
>  
> @@ -497,6 +509,7 @@ static int ad9834_remove(struct spi_device *spi)
>   struct ad9834_state *st = iio_priv(indio_dev);
>  
>   iio_device_unregister(indio_dev);
> + clk_disable_unprepare(st->mclk);
>   regulator_disable(st->reg);
>  
>   return 0;

Re: [GIT PULL] bcm2835-dt-64-next-2019-02-01

[Florian Fainelli]

Le 2/1/19 à 3:02 PM, Stefan Wahren a écrit :
> Hi Florian,
> 
> this is the fixup version (cherry picked the patch with the reference target)
> of the dt-64-next pull request. Please consider this as a replacement for
> the broken dt-64-next pull request.
> 
> The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
> 
>   Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
> 
> are available in the git repository at:
> 
>   git://github.com/anholt/linux tags/bcm2835-dt-64-next-2019-02-01
> 
> for you to fetch changes up to 441d8020d8fc8654698f5518cdf76832f84101f4:
> 
>   arm64: dts: broadcom: Add reference to RPi 3 A+ (2019-02-01 23:35:26 +0100)
> 
> 
> This pull request brings in the arm64 reference for Raspberry Pi 3 A+.
> 
> 

Merged into devicetree-arm64/next, thanks Sfefan!
-- 
Florian

Re: [PATCH v2 1/2] staging: iio: frequency: ad9833: Get frequency value statically

[Jonathan Cameron]

On Fri, 1 Feb 2019 17:01:37 +0200
Beniamin Bia  wrote:

> From: Beniamin Bia 
> 
> The values from platform data were replaced by statically values.
> This was just a intermediate step of taking this driver out of staging and
> load data from device tree.
> 
> Signed-off-by: Beniamin Bia 
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan
> ---
> Changes in v2:
> - The platform data structure was removed and the values are
>   written directly
>  drivers/staging/iio/frequency/ad9834.c | 21 +++
>  drivers/staging/iio/frequency/ad9834.h | 28 --
>  2 files changed, 7 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/staging/iio/frequency/ad9834.c 
> b/drivers/staging/iio/frequency/ad9834.c
> index 995acdd7c942..f4f5eaa15e30 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -391,16 +391,11 @@ static const struct iio_info ad9833_info = {
>  
>  static int ad9834_probe(struct spi_device *spi)
>  {
> - struct ad9834_platform_data *pdata = dev_get_platdata(>dev);
>   struct ad9834_state *st;
>   struct iio_dev *indio_dev;
>   struct regulator *reg;
>   int ret;
>  
> - if (!pdata) {
> - dev_dbg(>dev, "no platform data?\n");
> - return -ENODEV;
> - }
>  
>   reg = devm_regulator_get(>dev, "avdd");
>   if (IS_ERR(reg))
> @@ -420,7 +415,7 @@ static int ad9834_probe(struct spi_device *spi)
>   spi_set_drvdata(spi, indio_dev);
>   st = iio_priv(indio_dev);
>   mutex_init(>lock);
> - st->mclk = pdata->mclk;
> + st->mclk = 2500;
>   st->spi = spi;
>   st->devid = spi_get_device_id(spi)->driver_data;
>   st->reg = reg;
> @@ -456,11 +451,9 @@ static int ad9834_probe(struct spi_device *spi)
>   spi_message_add_tail(>freq_xfer[1], >freq_msg);
>  
>   st->control = AD9834_B28 | AD9834_RESET;
> + st->control |= AD9834_DIV2;
>  
> - if (!pdata->en_div2)
> - st->control |= AD9834_DIV2;
> -
> - if (!pdata->en_signbit_msb_out && (st->devid == ID_AD9834))
> + if (st->devid == ID_AD9834)
>   st->control |= AD9834_SIGN_PIB;
>  
>   st->data = cpu_to_be16(AD9834_REG_CMD | st->control);
> @@ -470,19 +463,19 @@ static int ad9834_probe(struct spi_device *spi)
>   goto error_disable_reg;
>   }
>  
> - ret = ad9834_write_frequency(st, AD9834_REG_FREQ0, pdata->freq0);
> + ret = ad9834_write_frequency(st, AD9834_REG_FREQ0, 100);
>   if (ret)
>   goto error_disable_reg;
>  
> - ret = ad9834_write_frequency(st, AD9834_REG_FREQ1, pdata->freq1);
> + ret = ad9834_write_frequency(st, AD9834_REG_FREQ1, 500);
>   if (ret)
>   goto error_disable_reg;
>  
> - ret = ad9834_write_phase(st, AD9834_REG_PHASE0, pdata->phase0);
> + ret = ad9834_write_phase(st, AD9834_REG_PHASE0, 512);
>   if (ret)
>   goto error_disable_reg;
>  
> - ret = ad9834_write_phase(st, AD9834_REG_PHASE1, pdata->phase1);
> + ret = ad9834_write_phase(st, AD9834_REG_PHASE1, 1024);
>   if (ret)
>   goto error_disable_reg;
>  
> diff --git a/drivers/staging/iio/frequency/ad9834.h 
> b/drivers/staging/iio/frequency/ad9834.h
> index ae620f38eb49..da7e83ceedad 100644
> --- a/drivers/staging/iio/frequency/ad9834.h
> +++ b/drivers/staging/iio/frequency/ad9834.h
> @@ -8,32 +8,4 @@
>  #ifndef IIO_DDS_AD9834_H_
>  #define IIO_DDS_AD9834_H_
>  
> -/*
> - * TODO: struct ad7887_platform_data needs to go into include/linux/iio
> - */
> -
> -/**
> - * struct ad9834_platform_data - platform specific information
> - * @mclk:master clock in Hz
> - * @freq0:   power up freq0 tuning word in Hz
> - * @freq1:   power up freq1 tuning word in Hz
> - * @phase0:  power up phase0 value [0..4095] correlates with 0..2PI
> - * @phase1:  power up phase1 value [0..4095] correlates with 0..2PI
> - * @en_div2: digital output/2 is passed to the SIGN BIT OUT pin
> - * @en_signbit_msb_out:  the MSB (or MSB/2) of the DAC data is connected 
> to the
> - *   SIGN BIT OUT pin. en_div2 controls whether it is the MSB
> - *   or MSB/2 that is output. if en_signbit_msb_out=false,
> - *   the on-board comparator is connected to SIGN BIT OUT
> - */
> -
> -struct ad9834_platform_data {
> - unsigned intmclk;
> - unsigned intfreq0;
> - unsigned intfreq1;
> - unsigned short  phase0;
> - unsigned short  phase1;
> - boolen_div2;
> - boolen_signbit_msb_out;
> -};
> -
>  #endif /* IIO_DDS_AD9834_H_ */