Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

24 participants
2727 discussions

Re: [PATCH v2 1/2] dt-bindings: mtd: nuvoton,ma35d1-nand: add new bindings

by Krzysztof Kozlowski

On Mon, Aug 19, 2024 at 09:20:36AM +0000, Hui-Ping Chen wrote: > Add dt-bindings for the Nuvoton MA35 SoC NAND Controller. > > Signed-off-by: Hui-Ping Chen <hpchen0nvt(a)gmail.com> > --- > .../bindings/mtd/nuvoton,ma35d1-nand.yaml | 93 +++++++++++++++++++ > 1 file changed, 93 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Best regards, Krzysztof

8 months, 1 week

Re: [PATCH v3 5/5] udmabuf: remove udmabuf_folio

by kernel test robot

Hi Huan, kernel test robot noticed the following build warnings: [auto build test WARNING on 033a4691702cdca3a613256b0623b8eeacb4985e] url: https://github.com/intel-lab-lkp/linux/commits/Huan-Yang/udmabuf-cancel-mma… base: 033a4691702cdca3a613256b0623b8eeacb4985e patch link: https://lore.kernel.org/r/20240813090518.3252469-6-link%40vivo.com patch subject: [PATCH v3 5/5] udmabuf: remove udmabuf_folio config: s390-allyesconfig (https://download.01.org/0day-ci/archive/20240816/202408162012.cL9pnFSm-lkp@…) compiler: s390-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240816/202408162012.cL9pnFSm-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202408162012.cL9pnFSm-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/dma-buf/udmabuf.c:175: warning: Function parameter or struct member 'ubuf' not described in 'unpin_all_folios' vim +175 drivers/dma-buf/udmabuf.c 17a7ce20349045 Gurchetan Singh 2019-12-02 165 d934739404652b Huan Yang 2024-08-13 166 /** d934739404652b Huan Yang 2024-08-13 167 * unpin_all_folios: unpin each folio we pinned in create d934739404652b Huan Yang 2024-08-13 168 * The udmabuf set all folio in folios and pinned it, but for large folio, d934739404652b Huan Yang 2024-08-13 169 * We may have only used a small portion of the physical in the folio. d934739404652b Huan Yang 2024-08-13 170 * we will repeatedly, sequentially set the folio into the array to ensure d934739404652b Huan Yang 2024-08-13 171 * that the offset can index the correct folio at the corresponding index. d934739404652b Huan Yang 2024-08-13 172 * Hence, we only need to unpin the first iterred folio. d934739404652b Huan Yang 2024-08-13 173 */ d934739404652b Huan Yang 2024-08-13 174 static void unpin_all_folios(struct udmabuf *ubuf) c6a3194c05e7e6 Vivek Kasireddy 2024-06-23 @175 { d934739404652b Huan Yang 2024-08-13 176 pgoff_t pg; d934739404652b Huan Yang 2024-08-13 177 struct folio *last = NULL; c6a3194c05e7e6 Vivek Kasireddy 2024-06-23 178 d934739404652b Huan Yang 2024-08-13 179 for (pg = 0; pg < ubuf->pagecount; pg++) { d934739404652b Huan Yang 2024-08-13 180 struct folio *tmp = ubuf->folios[pg]; c6a3194c05e7e6 Vivek Kasireddy 2024-06-23 181 d934739404652b Huan Yang 2024-08-13 182 if (tmp == last) d934739404652b Huan Yang 2024-08-13 183 continue; c6a3194c05e7e6 Vivek Kasireddy 2024-06-23 184 d934739404652b Huan Yang 2024-08-13 185 last = tmp; d934739404652b Huan Yang 2024-08-13 186 unpin_folio(tmp); d934739404652b Huan Yang 2024-08-13 187 } c6a3194c05e7e6 Vivek Kasireddy 2024-06-23 188 } c6a3194c05e7e6 Vivek Kasireddy 2024-06-23 189 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

8 months, 2 weeks

Re: [PATCH v7 00/16] Add audio support for the MediaTek Genio 350-evk board

by Mark Brown

On Wed, Aug 14, 2024 at 10:23:12AM +0200, Alexandre Mergnat wrote: > Simple gentle ping, the serie seems ready to be applied. Please don't send content free pings and please allow a reasonable time for review. People get busy, go on holiday, attend conferences and so on so unless there is some reason for urgency (like critical bug fixes) please allow at least a couple of weeks for review. If there have been review comments then people may be waiting for those to be addressed. Sending content free pings adds to the mail volume (if they are seen at all) which is often the problem and since they can't be reviewed directly if something has gone wrong you'll have to resend the patches anyway, so sending again is generally a better approach though there are some other maintainers who like them - if in doubt look at how patches for the subsystem are normally handled.

8 months, 2 weeks

Re: [PATCH 2/2] mtd: rawnand: nuvoton: add new driver for the Nuvoton MA35 SoC

by kernel test robot

Hi Hui-Ping, kernel test robot noticed the following build warnings: [auto build test WARNING on mtd/nand/next] [also build test WARNING on linus/master v6.11-rc3 next-20240813] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Hui-Ping-Chen/dt-bindings-mt… base: https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next patch link: https://lore.kernel.org/r/20240812030045.20831-3-hpchen0nvt%40gmail.com patch subject: [PATCH 2/2] mtd: rawnand: nuvoton: add new driver for the Nuvoton MA35 SoC config: arc-randconfig-r133-20240813 (https://download.01.org/0day-ci/archive/20240814/202408140515.pbHkvxZD-lkp@…) compiler: arc-elf-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240814/202408140515.pbHkvxZD-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202408140515.pbHkvxZD-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:119:3: sparse: sparse: symbol 'E_BCHALGORITHM' was not declared. Should it be static? >> drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:333:28: sparse: sparse: cast removes address space '__iomem' of expression drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:348:39: sparse: sparse: cast removes address space '__iomem' of expression >> drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:746:41: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char *register ptr @@ got void [noderef] __iomem * @@ drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:746:41: sparse: expected char *register ptr drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:746:41: sparse: got void [noderef] __iomem * drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:760:18: sparse: sparse: cast removes address space '__iomem' of expression >> drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:774:32: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char *ptr @@ got void [noderef] __iomem * @@ drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:774:32: sparse: expected char *ptr drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:774:32: sparse: got void [noderef] __iomem * drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:813:32: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char *ptr @@ got void [noderef] __iomem * @@ drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:813:32: sparse: expected char *ptr drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:813:32: sparse: got void [noderef] __iomem * drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char *register ptr @@ got void [noderef] __iomem * @@ drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: expected char *register ptr drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: got void [noderef] __iomem * drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char *register ptr @@ got void [noderef] __iomem * @@ drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: expected char *register ptr drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: got void [noderef] __iomem * drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char *register ptr @@ got void [noderef] __iomem * @@ drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: expected char *register ptr drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: got void [noderef] __iomem * drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char *register ptr @@ got void [noderef] __iomem * @@ drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: expected char *register ptr drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:516:49: sparse: got void [noderef] __iomem * vim +/E_BCHALGORITHM +119 drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c 111 112 /* BCH algorithm related constants and variables */ 113 enum { 114 eBCH_NONE = 0, 115 eBCH_T8, 116 eBCH_T12, 117 eBCH_T24, 118 eBCH_CNT > 119 } E_BCHALGORITHM; 120 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

8 months, 2 weeks

Re: [PATCH 2/2] mtd: rawnand: nuvoton: add new driver for the Nuvoton MA35 SoC

by kernel test robot

Hi Hui-Ping, kernel test robot noticed the following build warnings: [auto build test WARNING on mtd/nand/next] [also build test WARNING on linus/master v6.11-rc3 next-20240812] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Hui-Ping-Chen/dt-bindings-mt… base: https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next patch link: https://lore.kernel.org/r/20240812030045.20831-3-hpchen0nvt%40gmail.com patch subject: [PATCH 2/2] mtd: rawnand: nuvoton: add new driver for the Nuvoton MA35 SoC config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20240812/202408122007.quTiDXPR-lkp@…) compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240812/202408122007.quTiDXPR-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202408122007.quTiDXPR-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c:991:29: warning: cast from 'irqreturn_t (*)(int, struct ma35_nand_info *)' (aka 'enum irqreturn (*)(int, struct ma35_nand_info *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Wcast-function-type-strict] 991 | if (request_irq(nand->irq, (irq_handler_t)&ma35_nand_irq, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. vim +991 drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c 921 922 static int ma35_nand_probe(struct platform_device *pdev) 923 { 924 struct ma35_nand_info *nand; 925 struct nand_chip *chip; 926 struct mtd_info *mtd; 927 int retval = 0; 928 929 nand = devm_kzalloc(&pdev->dev, sizeof(struct ma35_nand_info), GFP_KERNEL); 930 if (!nand) 931 return -ENOMEM; 932 933 nand_controller_init(&nand->controller); 934 935 nand->regs = devm_platform_ioremap_resource(pdev, 0); 936 if (IS_ERR(nand->regs)) 937 return PTR_ERR(nand->regs); 938 939 nand->dev = &pdev->dev; 940 chip = &nand->chip; 941 mtd = nand_to_mtd(chip); 942 nand_set_controller_data(chip, nand); 943 nand_set_flash_node(chip, pdev->dev.of_node); 944 945 mtd->priv = chip; 946 mtd->owner = THIS_MODULE; 947 mtd->dev.parent = &pdev->dev; 948 949 nand->clk = of_clk_get(pdev->dev.of_node, 0); 950 if (IS_ERR(nand->clk)) 951 return dev_err_probe(&pdev->dev, PTR_ERR(nand->clk), 952 "failed to find nand clock\n"); 953 954 retval = clk_prepare_enable(nand->clk); 955 if (retval < 0) { 956 dev_err(&pdev->dev, "Failed to enable clock\n"); 957 return -ENXIO; 958 } 959 960 nand->chip.controller = &nand->controller; 961 962 chip->legacy.cmdfunc = ma35_nand_command; 963 chip->legacy.waitfunc = ma35_waitfunc; 964 chip->legacy.read_byte = ma35_nand_read_byte; 965 chip->legacy.select_chip = ma35_nand_select_chip; 966 chip->legacy.read_buf = ma35_read_buf_dma; 967 chip->legacy.write_buf = ma35_write_buf_dma; 968 chip->legacy.dev_ready = ma35_nand_devready; 969 chip->legacy.chip_delay = 25; /* us */ 970 971 /* Read OOB data first, then HW read page */ 972 chip->ecc.hwctl = ma35_nand_enable_hwecc; 973 chip->ecc.calculate = ma35_nand_calculate_ecc; 974 chip->ecc.correct = ma35_nand_correct_data; 975 chip->ecc.write_page = ma35_nand_write_page_hwecc; 976 chip->ecc.read_page = ma35_nand_read_page_hwecc_oob_first; 977 chip->ecc.read_oob = ma35_nand_read_oob_hwecc; 978 chip->options |= (NAND_NO_SUBPAGE_WRITE | NAND_USES_DMA); 979 980 ma35_nand_initialize(nand); 981 platform_set_drvdata(pdev, nand); 982 983 nand->controller.ops = &ma35_nand_controller_ops; 984 985 nand->irq = platform_get_irq(pdev, 0); 986 if (nand->irq < 0) { 987 dev_err(&pdev->dev, "failed to get platform irq\n"); 988 return -EINVAL; 989 } 990 > 991 if (request_irq(nand->irq, (irq_handler_t)&ma35_nand_irq, 992 IRQF_TRIGGER_HIGH, "ma35d1-nand", nand)) { 993 dev_err(&pdev->dev, "Error requesting NAND IRQ\n"); 994 return -ENXIO; 995 } 996 997 retval = nand_scan(chip, 1); 998 if (retval) 999 return retval; 1000 1001 if (mtd_device_register(mtd, nand->parts, nand->nr_parts)) { 1002 nand_cleanup(chip); 1003 devm_kfree(&pdev->dev, nand); 1004 return retval; 1005 } 1006 1007 pr_info("ma35-nfi: registered successfully! mtdid=%s\n", mtd->name); 1008 1009 return retval; 1010 } 1011 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

8 months, 2 weeks

Re: [PATCH 2/2] mtd: rawnand: nuvoton: add new driver for the Nuvoton MA35 SoC

by Krzysztof Kozlowski

On 12/08/2024 11:10, Hui-Ping Chen wrote: >>> + >>> +/* NAND-type Flash BCH Error Data Registers */ >>> +#define MA35_NFI_REG_NANDECCED0 (0x960) >>> +#define MA35_NFI_REG_NANDECCED1 (0x964) >>> +#define MA35_NFI_REG_NANDECCED2 (0x968) >>> +#define MA35_NFI_REG_NANDECCED3 (0x96C) >>> +#define MA35_NFI_REG_NANDECCED4 (0x970) >>> +#define MA35_NFI_REG_NANDECCED5 (0x974) >>> + >>> +/* NAND-type Flash Redundant Area Registers */ >>> +#define MA35_NFI_REG_NANDRA0 (0xA00) >>> +#define MA35_NFI_REG_NANDRA1 (0xA04) >>> + >>> +#define SKIP_SPARE_BYTES 4 >>> + >>> +/* BCH algorithm related constants and variables */ >>> +enum { >>> + eBCH_NONE = 0, >>> + eBCH_T8, >>> + eBCH_T12, >>> + eBCH_T24, >>> + eBCH_CNT >>> +} E_BCHALGORITHM; >>> + >>> +static const int g_i32BCHAlgoIdx[eBCH_CNT] = {BCH_T8, BCH_T8, BCH_T12, BCH_T24}; >>> +static struct nand_ecclayout_user ma35_nand_oob; >> Why this is file-scope? > > I will remove the `static`. No, why this cannot be instance dependent? Quick looks says it could. And should. Best regards, Krzysztof

8 months, 2 weeks

Re: [PATCH 1/2] dt-bindings: mtd: nuvoton,ma35d1-nand: add new bindings

by Krzysztof Kozlowski

On 12/08/2024 11:02, Hui-Ping Chen wrote: > > >>> + >>> + nand-ecc-step-size: >>> + enum: [512, 1024] >> No defaults? So is this required? > > This is required, but I will also add a default. If this is required and should be in required: list. Default does not make sense then... it contradicts the point of being required. > > > >>> + >>> + nand-ecc-strength: >>> + enum: [8, 12, 24] >> No defaults? So is this required? > > This is required, but I will also add a default. Ditto Best regards, Krzysztof

8 months, 2 weeks

Re: [PATCH 2/2] mtd: rawnand: nuvoton: add new driver for the Nuvoton MA35 SoC

by Krzysztof Kozlowski

On 12/08/2024 05:00, Hui-Ping Chen wrote: > Nuvoton MA35 SoCs NAND Flash Interface Controller > supports 2KB, 4KB and 8KB page size, and up to 8-bit, > 12-bit, and 24-bit hardware ECC calculation circuit > to protect data communication. > > Signed-off-by: Hui-Ping Chen <hpchen0nvt(a)gmail.com> > --- > drivers/mtd/nand/raw/Kconfig | 8 + > drivers/mtd/nand/raw/Makefile | 1 + > drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c | 1109 ++++++++++++++++++++ > 3 files changed, 1118 insertions(+) > create mode 100644 drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig > index 614257308516..932bf2215470 100644 > --- a/drivers/mtd/nand/raw/Kconfig > +++ b/drivers/mtd/nand/raw/Kconfig > @@ -448,6 +448,14 @@ config MTD_NAND_RENESAS > Enables support for the NAND controller found on Renesas R-Car > Gen3 and RZ/N1 SoC families. > > +config MTD_NAND_NVT_MA35 > + tristate "Nuvoton MA35 SoC NAND controller" > + depends on ARCH_MA35 || COMPILE_TEST > + depends on OF > + help > + Enables support for the NAND controller found on > + the Nuvoton MA35 series SoCs. > + > comment "Misc" > > config MTD_SM_COMMON > diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile > index 25120a4afada..cdfdfee3f5f3 100644 > --- a/drivers/mtd/nand/raw/Makefile > +++ b/drivers/mtd/nand/raw/Makefile > @@ -57,6 +57,7 @@ obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o > obj-$(CONFIG_MTD_NAND_ROCKCHIP) += rockchip-nand-controller.o > obj-$(CONFIG_MTD_NAND_PL35X) += pl35x-nand-controller.o > obj-$(CONFIG_MTD_NAND_RENESAS) += renesas-nand-controller.o > +obj-$(CONFIG_MTD_NAND_NVT_MA35) += nuvoton_ma35d1_nand.o > > nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o > nand-objs += nand_onfi.o > diff --git a/drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c b/drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c > new file mode 100644 > index 000000000000..7445eb489c38 > --- /dev/null > +++ b/drivers/mtd/nand/raw/nuvoton_ma35d1_nand.c > @@ -0,0 +1,1109 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2024 Nuvoton Technology Corp. > + */ > +#include <linux/slab.h> > +#include <linux/init.h> > +#include <linux/module.h> > +#include <linux/interrupt.h> > +#include <linux/io.h> > +#include <linux/platform_device.h> > +#include <linux/delay.h> > +#include <linux/clk.h> > +#include <linux/err.h> > +#include <linux/of.h> > + > +#include <linux/mtd/mtd.h> > +#include <linux/mtd/partitions.h> > +#include <linux/mtd/rawnand.h> > +#include <linux/dma-mapping.h> > +#include <linux/dmaengine.h> > + > +/* NFI DMA Registers */ > +#define MA35_NFI_REG_BUFFER0 (0x000) > +#define MA35_NFI_REG_DMACTL (0x400) > +#define DMA_EN BIT(0) > +#define DMA_RST BIT(1) > +#define DMA_BUSY BIT(9) > + > +#define MA35_NFI_REG_DMASA (0x408) > +#define MA35_NFI_REG_DMABCNT (0x40C) > +#define MA35_NFI_REG_DMAINTEN (0x410) > +#define MA35_NFI_REG_DMAINTSTS (0x414) > + > +/* NFI Global Registers */ > +#define MA35_NFI_REG_GCTL (0x800) > +#define NAND_EN BIT(3) > +#define MA35_NFI_REG_GINTEN (0x804) > +#define MA35_NFI_REG_GINTSTS (0x808) > + > +/* NAND-type Flash Registers */ > +#define MA35_NFI_REG_NANDCTL (0x8A0) > +#define SWRST BIT(0) > +#define DMA_W_EN BIT(1) > +#define DMA_R_EN BIT(2) > +#define ECC_CHK BIT(7) > +#define PROT3BEN BIT(8) > +#define PSIZE_2K (1 << 16) > +#define PSIZE_4K (2 << 16) > +#define PSIZE_8K (3 << 16) > +#define PSIZE_MASK (3 << 16) > +#define BCH_T24 BIT(18) > +#define BCH_T8 BIT(20) > +#define BCH_T12 BIT(21) > +#define BCH_MASK (0x1f << 18) > +#define ECC_EN BIT(23) > +#define DISABLE_CS0 BIT(25) > + > +#define MA35_NFI_REG_NANDTMCTL (0x8A4) > +#define MA35_NFI_REG_NANDINTEN (0x8A8) > +#define MA35_NFI_REG_NANDINTSTS (0x8AC) > +#define INT_DMA BIT(0) > +#define INT_ECC BIT(2) > +#define INT_RB0 BIT(10) > +#define INT_RB0_STS BIT(18) > + > +#define MA35_NFI_REG_NANDCMD (0x8B0) > +#define MA35_NFI_REG_NANDADDR (0x8B4) > +#define ENDADDR BIT(31) > + > +#define MA35_NFI_REG_NANDDATA (0x8B8) > +#define MA35_NFI_REG_NANDRACTL (0x8BC) > +#define MA35_NFI_REG_NANDECTL (0x8C0) > +#define ENABLE_WP (0x0) > +#define DISABLE_WP BIT(0) > + > +#define MA35_NFI_REG_NANDECCES0 (0x8D0) > +#define ECC_STATUS_MASK (0x3) > +#define ECC_ERR_CNT_MASK (0x1f) > + > +#define MA35_NFI_REG_NANDECCES1 (0x8D4) > +#define MA35_NFI_REG_NANDECCES2 (0x8D8) > +#define MA35_NFI_REG_NANDECCES3 (0x8DC) > + > +/* NAND-type Flash BCH Error Address Registers */ > +#define MA35_NFI_REG_NANDECCEA0 (0x900) > +#define MA35_NFI_REG_NANDECCEA1 (0x904) > +#define MA35_NFI_REG_NANDECCEA2 (0x908) > +#define MA35_NFI_REG_NANDECCEA3 (0x90C) > +#define MA35_NFI_REG_NANDECCEA4 (0x910) > +#define MA35_NFI_REG_NANDECCEA5 (0x914) > +#define MA35_NFI_REG_NANDECCEA6 (0x918) > +#define MA35_NFI_REG_NANDECCEA7 (0x91C) > +#define MA35_NFI_REG_NANDECCEA8 (0x920) > +#define MA35_NFI_REG_NANDECCEA9 (0x924) > +#define MA35_NFI_REG_NANDECCEA10 (0x928) > +#define MA35_NFI_REG_NANDECCEA11 (0x92C) > + > +/* NAND-type Flash BCH Error Data Registers */ > +#define MA35_NFI_REG_NANDECCED0 (0x960) > +#define MA35_NFI_REG_NANDECCED1 (0x964) > +#define MA35_NFI_REG_NANDECCED2 (0x968) > +#define MA35_NFI_REG_NANDECCED3 (0x96C) > +#define MA35_NFI_REG_NANDECCED4 (0x970) > +#define MA35_NFI_REG_NANDECCED5 (0x974) > + > +/* NAND-type Flash Redundant Area Registers */ > +#define MA35_NFI_REG_NANDRA0 (0xA00) > +#define MA35_NFI_REG_NANDRA1 (0xA04) > + > +#define SKIP_SPARE_BYTES 4 > + > +/* BCH algorithm related constants and variables */ > +enum { > + eBCH_NONE = 0, > + eBCH_T8, > + eBCH_T12, > + eBCH_T24, > + eBCH_CNT > +} E_BCHALGORITHM; > + > +static const int g_i32BCHAlgoIdx[eBCH_CNT] = {BCH_T8, BCH_T8, BCH_T12, BCH_T24}; > +static struct nand_ecclayout_user ma35_nand_oob; Why this is file-scope? > +static const int g_i32ParityNum[3][eBCH_CNT] = { This is not a Linux coding style. Do not send Windows or some other platform-independent patches to review. > + {0, 60, 92, 90}, /* for 2K */ > + {0, 120, 184, 180}, /* for 4K */ > + {0, 240, 368, 360}, /* for 8K */ > +}; > + > + > +struct ma35_nand_info { > + struct nand_controller controller; > + struct device *dev; > + void __iomem *regs; > + int irq; > + struct clk *clk; > + struct completion complete; > + > + struct mtd_info mtd; > + struct nand_chip chip; > + struct mtd_partition *parts; > + int nr_parts; > + > + int eBCHAlgo; No, use Linux coding style. > + u8 *dma_buf; > + spinlock_t dma_lock; > + dma_addr_t dma_addr; > +}; > + > +static int ma35_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 = mtd->oobsize - oobregion->length; > + > + return 0; > +} ... this code looks poor, really poor. > +} > + > +static int ma35_nfi_correct(struct nand_chip *chip, unsigned long addr) > +{ > + struct ma35_nand_info *nand = nand_get_controller_data(chip); > + struct mtd_info *mtd = nand_to_mtd(chip); > + int uStatus, i, j, i32FieldNum = 0; > + int uReportErrCnt = 0; > + int uErrorCnt = 0; > + More of weird coding style. Use Linux coding style. Patch is for Linux. > + if ((readl(nand->regs + MA35_NFI_REG_NANDCTL) & BCH_MASK) == BCH_T24) > + i32FieldNum = mtd->writesize / 1024; > + else > + i32FieldNum = mtd->writesize / 512; ... > +static int ma35_nand_probe(struct platform_device *pdev) > +{ > + struct ma35_nand_info *nand; > + struct nand_chip *chip; > + struct mtd_info *mtd; > + int retval = 0; > + > + nand = devm_kzalloc(&pdev->dev, sizeof(struct ma35_nand_info), GFP_KERNEL); sizeof(*) > + if (!nand) > + return -ENOMEM; > + > + nand_controller_init(&nand->controller); > + > + nand->regs = devm_platform_ioremap_resource(pdev, 0); > + if (IS_ERR(nand->regs)) > + return PTR_ERR(nand->regs); > + > + nand->dev = &pdev->dev; > + chip = &nand->chip; > + mtd = nand_to_mtd(chip); > + nand_set_controller_data(chip, nand); > + nand_set_flash_node(chip, pdev->dev.of_node); > + > + mtd->priv = chip; > + mtd->owner = THIS_MODULE; > + mtd->dev.parent = &pdev->dev; > + > + nand->clk = of_clk_get(pdev->dev.of_node, 0); No, no. That's not how you get a clock. Use devm_clk_get(). > + if (IS_ERR(nand->clk)) > + return dev_err_probe(&pdev->dev, PTR_ERR(nand->clk), > + "failed to find nand clock\n"); > + > + retval = clk_prepare_enable(nand->clk); > + if (retval < 0) { > + dev_err(&pdev->dev, "Failed to enable clock\n"); > + return -ENXIO; > + } > + > + nand->chip.controller = &nand->controller; > + > + chip->legacy.cmdfunc = ma35_nand_command; > + chip->legacy.waitfunc = ma35_waitfunc; > + chip->legacy.read_byte = ma35_nand_read_byte; > + chip->legacy.select_chip = ma35_nand_select_chip; > + chip->legacy.read_buf = ma35_read_buf_dma; > + chip->legacy.write_buf = ma35_write_buf_dma; > + chip->legacy.dev_ready = ma35_nand_devready; > + chip->legacy.chip_delay = 25; /* us */ > + > + /* Read OOB data first, then HW read page */ > + chip->ecc.hwctl = ma35_nand_enable_hwecc; > + chip->ecc.calculate = ma35_nand_calculate_ecc; > + chip->ecc.correct = ma35_nand_correct_data; > + chip->ecc.write_page = ma35_nand_write_page_hwecc; > + chip->ecc.read_page = ma35_nand_read_page_hwecc_oob_first; > + chip->ecc.read_oob = ma35_nand_read_oob_hwecc; > + chip->options |= (NAND_NO_SUBPAGE_WRITE | NAND_USES_DMA); > + > + ma35_nand_initialize(nand); > + platform_set_drvdata(pdev, nand); > + > + nand->controller.ops = &ma35_nand_controller_ops; > + > + nand->irq = platform_get_irq(pdev, 0); > + if (nand->irq < 0) { > + dev_err(&pdev->dev, "failed to get platform irq\n"); Syntax is return dev_err_probe > + return -EINVAL; > + } > + > + if (request_irq(nand->irq, (irq_handler_t)&ma35_nand_irq, > + IRQF_TRIGGER_HIGH, "ma35d1-nand", nand)) { > + dev_err(&pdev->dev, "Error requesting NAND IRQ\n"); > + return -ENXIO; > + } > + > + retval = nand_scan(chip, 1); > + if (retval) > + return retval; > + > + if (mtd_device_register(mtd, nand->parts, nand->nr_parts)) { > + nand_cleanup(chip); > + devm_kfree(&pdev->dev, nand); > + return retval; > + } > + > + pr_info("ma35-nfi: registered successfully! mtdid=%s\n", mtd->name); Drop, does not help. Drivers do not use pr_xxx anyway. Why your code is so inconsistent? It's like random junk glued together. > + > + return retval; > +} > + > +static void ma35_nand_remove(struct platform_device *pdev) > +{ > + struct ma35_nand_info *nand = platform_get_drvdata(pdev); > + struct nand_chip *chip = &nand->chip; > + int ret; > + > + ret = mtd_device_unregister(nand_to_mtd(chip)); > + WARN_ON(ret); > + nand_cleanup(chip); > + > + clk_disable_unprepare(nand->clk); > + > + kfree(nand); > + platform_set_drvdata(pdev, NULL); > +} > + > +/* PM Support */ > +#ifdef CONFIG_PM > +static int ma35_nand_suspend(struct platform_device *pdev, pm_message_t pm) > +{ > + struct ma35_nand_info *nand = platform_get_drvdata(pdev); > + unsigned long timeo = jiffies + HZ/2; > + > + /* wait DMAC to ready */ > + while (1) { > + if ((readl(nand->regs + MA35_NFI_REG_DMACTL) & DMA_BUSY) == 0) > + break; > + if (time_after(jiffies, timeo)) > + return -ETIMEDOUT; > + } > + > + clk_disable(nand->clk); > + > + return 0; > +} > + > +static int ma35_nand_resume(struct platform_device *pdev) > +{ > + struct ma35_nand_info *nand = platform_get_drvdata(pdev); > + > + clk_enable(nand->clk); > + ma35_nand_hwecc_init(nand); > + ma35_nand_dmac_init(nand); > + > + return 0; > +} > + > +#else > +#define ma35_nand_suspend NULL > +#define ma35_nand_resume NULL > +#endif > + > +static const struct of_device_id ma35_nfi_of_match[] = { > + { .compatible = "nuvoton,ma35d1-nand" }, > + {}, > +}; > +MODULE_DEVICE_TABLE(of, ma35_nfi_of_match); > + > +static struct platform_driver ma35_nand_driver = { > + .driver = { > + .name = "ma35d1-nand", > + .owner = THIS_MODULE, > + .of_match_table = of_match_ptr(ma35_nfi_of_match), Drop of_match_ptr. You have warnings here. > + }, > + .probe = ma35_nand_probe, > + .remove_new = ma35_nand_remove, > + .suspend = ma35_nand_suspend, > + .resume = ma35_nand_resume, > +}; > + > +static int __init ma35_nand_init(void) > +{ > + int ret; > + > + pr_info("ma35 mtd nand driver\n"); NAK, drop, useless and really pointless. > + > + ret = platform_driver_register(&ma35_nand_driver); > + if (ret) { > + pr_warn("nand: failed to add device driver %s\n", > + ma35_nand_driver.driver.name); > + return ret; > + } > + > + return ret; > +} > + > +static void __exit ma35_nand_exit(void) > +{ > + platform_driver_unregister(&ma35_nand_driver); > + pr_info("nand: unregistered successfully!\n"); NAK, drop, useless and really pointless. > +} > + > +module_init(ma35_nand_init); > +module_exit(ma35_nand_exit); Do not open-code these functions, there are wrappers for this. > + > +MODULE_DESCRIPTION("Nuvoton ma35 NAND driver"); > +MODULE_AUTHOR("Hui-Ping Chen <hpchen0nvt(a)gmail.com>"); > +MODULE_LICENSE("GPL"); Best regards, Krzysztof

8 months, 2 weeks

Re: [PATCH 1/2] dt-bindings: mtd: nuvoton,ma35d1-nand: add new bindings

by Krzysztof Kozlowski

On 12/08/2024 05:00, Hui-Ping Chen wrote: > Add dt-bindings for the Nuvoton MA35 SoC NAND Controller. > > Signed-off-by: Hui-Ping Chen <hpchen0nvt(a)gmail.com> > --- > .../bindings/mtd/nuvoton,ma35d1-nand.yaml | 97 +++++++++++++++++++ > 1 file changed, 97 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml > > diff --git a/Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml b/Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml > new file mode 100644 > index 000000000000..988c43bc6e99 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml > @@ -0,0 +1,97 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mtd/nuvoton,ma35d1-nand.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Nuvoton MA35D1 NAND Flash Interface (NFI) Controller > + > +allOf: > + - $ref: nand-controller.yaml# allOf goes usually just before properties. > + > +maintainers: > + - Hui-Ping Chen <hpchen0nvt(a)gmail.com> > + > +properties: > + compatible: > + enum: > + - nuvoton,ma35d1-nand > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + clocks: > + minItems: 1 This cannot be min only. It's unconstrained. maxItems instead. There is no existing code like this so this should make you wonder... > + > +patternProperties: > + "^nand@[a-f0-9]$": > + type: object > + $ref: raw-nand-chip.yaml > + properties: > + nand-ecc-mode: > + const: hw No, drop the property. It does not make sense to have it const. Compatible defines it. > + > + nand-ecc-step-size: > + enum: [512, 1024] No defaults? So is this required? > + > + nand-ecc-strength: > + enum: [8, 12, 24] No defaults? So is this required? > + > + nand-bus-width: > + const: 8 Drop property. > + > + unevaluatedProperties: false > + > +required: > + - compatible > + - reg > + - interrupts > + - clocks > + > +unevaluatedProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h> > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + nand-controller@401A0000 { > + compatible = "nuvoton,ma35d1-nand"; > + reg = <0x0 0x401A0000 0x0 0x1000>; > + interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&clk NAND_GATE>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + nand@0 { > + reg = <0>; > + > + nand-on-flash-bbt; > + nand-ecc-mode = "hw"; Drop > + nand-ecc-step-size = <512>; > + nand-ecc-strength = <8>; > + nand-bus-width = <8>; Drop > + > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + uboot@0 { > + label = "nand-uboot"; > + read-only; > + reg = <0x0 0x300000>; > + }; > + }; > + }; > + }; > + }; > + > +... Best regards, Krzysztof

8 months, 2 weeks

[PATCH rdma-next 0/8] Introducing Multi-Path DMA Support for mlx5 RDMA Driver

by Leon Romanovsky

From: Leon Romanovsky <leonro(a)nvidia.com> From Yishai, Overview -------- This patch series aims to enable multi-path DMA support, allowing an mlx5 RDMA device to issue DMA commands through multiple paths. This feature is critical for improving performance and reaching line rate in certain environments where issuing PCI transactions over one path may be significantly faster than over another. These differences can arise from various PCI generations in the system or the specific system topology. To achieve this functionality, we introduced a data direct DMA device that can serve the RDMA device by issuing DMA transactions on its behalf. The main key features and changes are described below. Multi-Path Discovery -------------------- API Implementation: * Introduced an API to discover multiple paths for a given mlx5 RDMA device. IOCTL Command: * Added a new IOCTL command, MLX5_IB_METHOD_GET_DATA_DIRECT_SYSFS_PATH, to the DEVICE object. When an affiliated Data-Direct/DMA device is present, its sysfs path is returned. Feature Activation by mlx5 RDMA Application ------------------------------------------- UVERBS Extension: * Extended UVERBS_METHOD_REG_DMABUF_MR over UVERBS_OBJECT_MR to include mlx5 extended flags. Access Flag: * Introduced the MLX5_IB_UAPI_REG_DMABUF_ACCESS_DATA_DIRECT flag, allowing applications to request the use of the affiliated DMA device for DMABUF registration. Data-Direct/DMA Device ---------------------- New Driver: * Introduced a new driver to manage the new DMA PF device ID (0x2100). Its registration/un-registration is handled as part of the mlx5_ib init/exit flows, with mlx5 IB devices as its clients. Functionality: * The driver does not interface directly with the firmware (no command interface, no caps, etc.) but works over PCI to activate its DMA functionality. It serves as the DMA device for efficiently accessing other PCI devices (e.g., GPU PF) and reads its VUID over PCI to handle NICs registrations with the same VUID. mlx5 IB RDMA Device --------------------------- VUID Query: * Reads its affiliated DMA PF VUID via the QUERY_VUID command with the data_direct bit set. Driver Registration: * Registers with the DMA PF driver to be notified upon bind/unbind. Application Request Handling: * Uses the DMA PF device upon application request as described above. DMABUF over Umem ---------------- Introduced an option to obtain a DMABUF UMEM using a different DMA device instead of the IB device, allowing the device to register over IOMMU with the expected DMA device for a given buffer registration. Further details are provided in the commit logs of the patches in this series. Thanks Yishai Hadas (8): net/mlx5: Add IFC related stuff for data direct RDMA/mlx5: Introduce the 'data direct' driver RDMA/mlx5: Add the initialization flow to utilize the 'data direct' device RDMA/umem: Add support for creating pinned DMABUF umem with a given dma device RDMA/umem: Introduce an option to revoke DMABUF umem RDMA: Pass uverbs_attr_bundle as part of '.reg_user_mr_dmabuf' API RDMA/mlx5: Add support for DMABUF MR registrations with Data-direct RDMA/mlx5: Introduce GET_DATA_DIRECT_SYSFS_PATH ioctl drivers/infiniband/core/umem_dmabuf.c | 66 +++- drivers/infiniband/core/uverbs_std_types_mr.c | 2 +- drivers/infiniband/hw/bnxt_re/ib_verbs.c | 3 +- drivers/infiniband/hw/bnxt_re/ib_verbs.h | 2 +- drivers/infiniband/hw/efa/efa.h | 2 +- drivers/infiniband/hw/efa/efa_verbs.c | 4 +- drivers/infiniband/hw/irdma/verbs.c | 2 +- drivers/infiniband/hw/mlx5/Makefile | 1 + drivers/infiniband/hw/mlx5/cmd.c | 21 ++ drivers/infiniband/hw/mlx5/cmd.h | 2 + drivers/infiniband/hw/mlx5/data_direct.c | 227 +++++++++++++ drivers/infiniband/hw/mlx5/data_direct.h | 23 ++ drivers/infiniband/hw/mlx5/main.c | 125 +++++++ drivers/infiniband/hw/mlx5/mlx5_ib.h | 22 +- drivers/infiniband/hw/mlx5/mr.c | 304 +++++++++++++++--- drivers/infiniband/hw/mlx5/odp.c | 5 +- drivers/infiniband/hw/mlx5/std_types.c | 55 +++- drivers/infiniband/hw/mlx5/umr.c | 93 ++++-- drivers/infiniband/hw/mlx5/umr.h | 1 + include/linux/mlx5/mlx5_ifc.h | 51 ++- include/rdma/ib_umem.h | 18 ++ include/rdma/ib_verbs.h | 2 +- include/uapi/rdma/mlx5_user_ioctl_cmds.h | 9 + include/uapi/rdma/mlx5_user_ioctl_verbs.h | 4 + 24 files changed, 944 insertions(+), 100 deletions(-) create mode 100644 drivers/infiniband/hw/mlx5/data_direct.c create mode 100644 drivers/infiniband/hw/mlx5/data_direct.h -- 2.45.2

8 months, 3 weeks

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig