Re: [PATCH v3 3/8] clk: samsung: add BPLL rate table for Exynos 5422 SoC
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
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
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
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?
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
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 = &jz4740_soc_info }, > + { .compatible = "ingenic,jz4780-nand", .data = &jz4780_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
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 = &chip->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 = &chip->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 = &jz4725b_ooblayout_ops; > + } else if (!strcmp(layout, "qi,lb60")) { > + nfc->oob_layout = &qi_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
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, &nand_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 = &chip->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 = &chip->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 = &pdev->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 = &nand_ooblayout_lp_ops; > + > + ret = device_property_read_string(dev, "ingenic,oob-layout", &layout); > + if (!ret) { > + if (!strcmp(layout, "ingenic,jz4725b")) { > + nfc->oob_layout = &jz4725b_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
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
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 = <&soc_revision>; + nvmem-cell-names = "soc_revision"; + + ... + }; + -- 2.18.0
[PATCH v2 3/3] nvmem: zynqmp: Added zynqmp nvmem firmware driver
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(&idcode, &version); + 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 = &pdev->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, &econfig); + + 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 (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
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
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
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, &smaps_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()
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.
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
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, &smaps_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
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(&port->buf.work); // Check return value of >>> cancel_work_sync >>> pr_emerg("Work cancelled is 0x%x %pS %d\n", (unsigned >>> int)&port->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 +040
[PATCH] PM / suspend: measure the time of filesystem syncing
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
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
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
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
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
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
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
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
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
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
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
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(&mrt->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, &list); > - } > - unregister_netdevice_many(&list); > + struct net *net = read_pnet(&mrt->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()
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, &ktermios); > > + status = tty_set_termios(real_tty, &ktermios); > > 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, &ktermios); > > + status = tty_set_termios(real_tty, &ktermios); > > 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
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
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?
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?
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
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
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
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, &flags); + if (test_bit(NFIT_MEM_LSR, &nfit_mem->flags)) { set_bit(ND_CMD_GET_CONFIG_SIZE, &cmd_mask); set_bit(ND_CMD_GET_CONFIG_DATA, &cmd_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, &nvdimm->flags)) + flags &= ~NSLABEL_FLAG_LOCAL; nd_label_gen_id(&label_id, label_uuid, flags); res = nvdimm_allocate_dpa(ndd, &label_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, &nvdimm->flags)) { + u32 flags = __le32_to_cpu(label->flags); + + flags &= ~NSLABEL_FLAG_LOCAL; + label->flags = __cpu_to_le32(flags); + } label_ent->label = label; mutex_lock(&nd_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, &nvdimm->flags)) ro = 1; + + if (test_bit(NDD_NOBLK, &nvdimm->flags) +
Re: linux-next: tracebacks in workqueue.c/__flush_work()
(Adding Chris Metcalf and Rusty Russell.) If NR_CPUS == 1 due to CONFIG_SMP=n, for_each_cpu(cpu, &has_work) loop does not evaluate "struct cpumask has_work" modified by cpumask_set_cpu(cpu, &has_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, &has_work) - flush_work(&per_cpu(lru_add_drain_work, cpu)); + if (NR_CPUS > 1 || cpumask_test_cpu(cpu, &has_work)) + flush_work(&per_cpu(lru_add_drain_work, cpu)); mutex_unlock(&lock); } 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
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
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
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
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(&monitor_promisc); @@ -854,6 +852,7 @@ static int hci_sock_release(struct socket *sock) bt_sock_unlink(&hci_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
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()
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 = &init; phy->clk_phy = devm_clk_register(dev, &priv->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
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
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) + writeb(ec
[PATCH v2 7/9] mtd: rawnand: jz4780-bch: Separate top-level and SoC specific code
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(&bch->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(&bch->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_b
[PATCH v2 8/9] mtd: rawnand: jz4780-bch: Add support for the JZ4725B
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
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
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, &nand_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 = &chip->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 = &chip->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 = &pdev->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 = &nand_ooblayout_lp_ops; + + ret = device_property_read_string(dev, "ingenic,oob-layout", &layout); + if (!ret) { + if (!strcmp(layout, "ingenic,jz4725b")) { + nfc->oob_layout = &jz4725b_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
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
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 = &jz4740_soc_info }, + { .compatible = "ingenic,jz4780-nand", .data = &jz4780_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
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 = &chip->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 = &chip->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 = &jz4725b_ooblayout_ops; + } else if (!strcmp(layout, "qi,lb60")) { + nfc->oob_layout = &qi_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
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
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(&xas, 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))); xas.xa_node = XAS_RESTART; XA_BUG_ON(xa, xas_next_entry(&xas, ULONG_MAX) != xa_mk_value(0));
[PATCH] staging: rtl8192u: fix a null pointer dereference on a null dev pointer
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
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(&c->cdev, &channel_fops); c->cdev.owner = THIS_MODULE; - cdev_add(&c->cdev, c->devno, 1); + retval = cdev_add(&c->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(&c->list); err_del_cdev_and_free_channel: cdev_del(&c->cdev); +err_free_c: kfree(c); err_remove_ida: ida_simple_remove(&comp.minor_id, current_minor); -- 2.20.1
Re: Bluetooth: hci0: last event is not cmd complete (0x0f) with LG TV
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()
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
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
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, > &q[IPU3_CSS_QUEUE_OUT].fmt.mpix; > struct v4l2_pix_format_mplane *const vf = > &q[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
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
[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
[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"
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
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
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 (&vmbus_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 (&vmbus_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(&vmbus_connection.channel_mutex); [ 164.171777]lock(kn->count#43); [ 164.171779] lock(&vmbus_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)(&ctx->work)){+.+.}, at: process_one_work+0x20f/0x5c0 [ 164.171794] #2: 7b9e8443 (&vmbus_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 [h
Re: [PATCH] net: dsa: Fix lockdep false positive splat
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
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 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
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
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" > > exe="
Re: [GIT PULL] Devicetree fix for 5.0-rc5
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
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
> +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
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
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(&skip_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(&sa, 0, sizeof(sa)); > sa.sa_handler = SIG_IGN; > syscall(SYS_rt_sigaction, 0x20, &sa, NULL, 8); > syscall(SYS_rt_sigaction, 0x21, &sa, NULL, 8); > memset(&sa, 0, sizeof(sa)); > sa.sa_sigaction = segv_handler; > sa.sa_flags = SA_NODEFER | SA_SIGINFO; > sigaction(SIGSEGV, &sa, NULL); > sigaction(SIGBUS, &sa, 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
> > 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()
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)
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
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
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(&dev->addr_list_lock, + &dsa_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
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+
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(&pdev->dev); return 0; -- 2.17.1
Re: [PATCH AUTOSEL 4.19 083/258] drm: Move drm_mode_setcrtc() local re-init to failure path
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
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
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
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
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
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(&state->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
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
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
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: > + > +&uart0 { > + air-pollution-sensor { > + vcc-supply = <®_vcc5v0>; > + compatible = "plantower,pms7003"; > + }; > +};
[GIT PULL] Devicetree fix for 5.0-rc5
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
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
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(&st->lock); > - st->mclk = 2500; > + st->mclk = devm_clk_get(&spi->dev, NULL); > + > + ret = clk_prepare_enable(st->mclk); > + if (ret) { > + dev_err(&spi->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, &st->msg); > if (ret) { > dev_err(&spi->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
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
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(&spi->dev); > struct ad9834_state *st; > struct iio_dev *indio_dev; > struct regulator *reg; > int ret; > > - if (!pdata) { > - dev_dbg(&spi->dev, "no platform data?\n"); > - return -ENODEV; > - } > > reg = devm_regulator_get(&spi->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(&st->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(&st->freq_xfer[1], &st->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_ */