[linux-yocto][linux-yocto v6.1/standard/ti-sdk-6.1/ti-j7xxx & v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx][PATCH 2/2] mtd: spi-nor: core: avoid odd length/address writes in 8D-8D-8D mode
From: Pratyush Yadav commit a9f1c2f3eaa70c64348a3ac5ec9892bcdbaa5ae4 from git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git On Octal DTR capable flashes like Micron Xcella the writes cannot start or end at an odd address in Octal DTR mode. Extra 0xff bytes need to be appended or prepended to make sure the start address and end address are even. 0xff is used because on NOR flashes a program operation can only flip bits from 1 to 0, not the other way round. 0 to 1 flip needs to happen via erases. Signed-off-by: Pratyush Yadav Signed-off-by: Apurva Nandan Signed-off-by: Vignesh Raghavendra Signed-off-by: Xulin Sun --- drivers/mtd/spi-nor/core.c | 72 +- 1 file changed, 71 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index ad068610ae80..15b0f6df6083 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -1814,6 +1814,71 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, return ret; } +/* + * On Octal DTR capable flashes like Micron Xcella the writes cannot start or + * end at an odd address in Octal DTR mode. Extra 0xff bytes need to be appended + * or prepended to make sure the start address and end address are even. 0xff is + * used because on NOR flashes a program operation can only flip bits from 1 to + * 0, not the other way round. 0 to 1 flip needs to happen via erases. + */ +static int spi_nor_octal_dtr_write(struct spi_nor *nor, loff_t to, size_t len, + const u8 *buf) +{ + u8 *tmp_buf; + size_t bytes_written; + loff_t start, end; + int ret; + + if (IS_ALIGNED(to, 2) && IS_ALIGNED(len, 2)) + return spi_nor_write_data(nor, to, len, buf); + + tmp_buf = kmalloc(nor->params->page_size, GFP_KERNEL); + if (!tmp_buf) + return -ENOMEM; + + memset(tmp_buf, 0xff, nor->params->page_size); + + start = round_down(to, 2); + end = round_up(to + len, 2); + + memcpy(tmp_buf + (to - start), buf, len); + + ret = spi_nor_write_data(nor, start, end - start, tmp_buf); + if (ret == 0) { + ret = -EIO; + goto out; + } + if (ret < 0) + goto out; + + /* +* More bytes are written than actually requested, but that number can't +* be reported to the calling function or it will confuse its +* calculations. Calculate how many of the _requested_ bytes were +* written. +*/ + bytes_written = ret; + + if (to != start) + ret -= to - start; + + /* +* Only account for extra bytes at the end if they were actually +* written. For example, if for some reason the controller could only +* complete a partial write then the adjustment for the extra bytes at +* the end is not needed. +*/ + if (start + bytes_written == end) + ret -= end - (to + len); + + if (ret < 0) + ret = -EIO; + +out: + kfree(tmp_buf); + return ret; +} + /* * Write an address range to the nor chip. Data must be written in * FLASH_PAGESIZE chunks. The address range may be any size provided @@ -1858,7 +1923,12 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, if (ret) goto write_err; - ret = spi_nor_write_data(nor, addr, page_remain, buf + i); + if (nor->write_proto == SNOR_PROTO_8_8_8_DTR) + ret = spi_nor_octal_dtr_write(nor, addr, page_remain, + buf + i); + else + ret = spi_nor_write_data(nor, addr, page_remain, +buf + i); if (ret < 0) goto write_err; written = ret; -- 2.35.5 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12746): https://lists.yoctoproject.org/g/linux-yocto/message/12746 Mute This Topic: https://lists.yoctoproject.org/mt/99500991/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1/standard/ti-sdk-6.1/ti-j7xxx & v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx][PATCH 1/2] mtd: spi-nor: core: avoid odd length/address reads on 8D-8D-8D mode
From: Pratyush Yadav commit c515105b5c117888b6859534a7c694489f6bcf6d from git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git On Octal DTR capable flashes like Micron Xcella reads cannot start or end at an odd address in Octal DTR mode. Extra bytes need to be read at the start or end to make sure both the start address and length remain even. To avoid allocating too much extra memory, thereby putting unnecessary memory pressure on the system, the temporary buffer containing the extra padding bytes is capped at PAGE_SIZE bytes. The rest of the 2-byte aligned part should be read directly in the main buffer. Signed-off-by: Pratyush Yadav Signed-off-by: Apurva Nandan Signed-off-by: Vignesh Raghavendra Signed-off-by: Xulin Sun --- drivers/mtd/spi-nor/core.c | 81 +- 1 file changed, 80 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 99194aa07196..ad068610ae80 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -1696,6 +1696,82 @@ static const struct flash_info *spi_nor_detect(struct spi_nor *nor) return info; } +/* + * On Octal DTR capable flashes like Micron Xcella reads cannot start or + * end at an odd address in Octal DTR mode. Extra bytes need to be read + * at the start or end to make sure both the start address and length + * remain even. + */ +static int spi_nor_octal_dtr_read(struct spi_nor *nor, loff_t from, size_t len, + u_char *buf) +{ + u_char *tmp_buf; + size_t tmp_len; + loff_t start, end; + int ret, bytes_read; + + if (IS_ALIGNED(from, 2) && IS_ALIGNED(len, 2)) + return spi_nor_read_data(nor, from, len, buf); + else if (IS_ALIGNED(from, 2) && len > PAGE_SIZE) + return spi_nor_read_data(nor, from, round_down(len, PAGE_SIZE), +buf); + + tmp_buf = kmalloc(PAGE_SIZE, GFP_KERNEL); + if (!tmp_buf) + return -ENOMEM; + + start = round_down(from, 2); + end = round_up(from + len, 2); + + /* +* Avoid allocating too much memory. The requested read length might be +* quite large. Allocating a buffer just as large (slightly bigger, in +* fact) would put unnecessary memory pressure on the system. +* +* For example if the read is from 3 to 1M, then this will read from 2 +* to 4098. The reads from 4098 to 1M will then not need a temporary +* buffer so they can proceed as normal. +*/ + tmp_len = min_t(size_t, end - start, PAGE_SIZE); + + ret = spi_nor_read_data(nor, start, tmp_len, tmp_buf); + if (ret == 0) { + ret = -EIO; + goto out; + } + if (ret < 0) + goto out; + + /* +* More bytes are read than actually requested, but that number can't be +* reported to the calling function or it will confuse its calculations. +* Calculate how many of the _requested_ bytes were read. +*/ + bytes_read = ret; + + if (from != start) + ret -= from - start; + + /* +* Only account for extra bytes at the end if they were actually read. +* For example, if the total length was truncated because of temporary +* buffer size limit then the adjustment for the extra bytes at the end +* is not needed. +*/ + if (start + bytes_read == end) + ret -= end - (from + len); + + if (ret < 0) { + ret = -EIO; + goto out; + } + + memcpy(buf, tmp_buf + (from - start), ret); +out: + kfree(tmp_buf); + return ret; +} + static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf) { @@ -1713,7 +1789,10 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, addr = spi_nor_convert_addr(nor, addr); - ret = spi_nor_read_data(nor, addr, len, buf); + if (nor->read_proto == SNOR_PROTO_8_8_8_DTR) + ret = spi_nor_octal_dtr_read(nor, addr, len, buf); + else + ret = spi_nor_read_data(nor, addr, len, buf); if (ret == 0) { /* We shouldn't see 0-length reads */ ret = -EIO; -- 2.35.5 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12745): https://lists.yoctoproject.org/g/linux-yocto/message/12745 Mute This Topic: https://lists.yoctoproject.org/mt/99500990/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto][yocto-kernel-cache yocto-6.1][PATCH 4/4] nxp-imx8: Enable USB_CHIPIDEA related config
merged. Bruce In message: [linux-yocto][yocto-kernel-cache yocto-6.1][PATCH 4/4] nxp-imx8: Enable USB_CHIPIDEA related config on 09/06/2023 Xiaolei Wang wrote: > Enable USB_CHIPIDEA related config for nxp-imx8. > > Signed-off-by: Xiaolei Wang > --- > bsp/nxp-imx8/nxp-imx8.cfg | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/bsp/nxp-imx8/nxp-imx8.cfg b/bsp/nxp-imx8/nxp-imx8.cfg > index 1581cdc6..b116ae2d 100644 > --- a/bsp/nxp-imx8/nxp-imx8.cfg > +++ b/bsp/nxp-imx8/nxp-imx8.cfg > @@ -416,6 +416,13 @@ CONFIG_USB_HCD_TEST_MODE=y > CONFIG_USB_ACM=m > CONFIG_USB_STORAGE=y > CONFIG_USB_UAS=y > +CONFIG_USB_CHIPIDEA=y > +CONFIG_USB_CHIPIDEA_UDC=y > +CONFIG_USB_CHIPIDEA_HOST=y > +CONFIG_USB_CONFIGFS=m > +CONFIG_USB_G_NCM=m > +CONFIG_USB_G_ACM_MS=m > +CONFIG_USB_MASS_STORAGE=m > > # > # Typec driver > -- > 2.25.1 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12747): https://lists.yoctoproject.org/g/linux-yocto/message/12747 Mute This Topic: https://lists.yoctoproject.org/mt/99425088/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] Trial merge of v5.15.116 v6.1.33 for linux-yocto
In message: Trial merge of v5.15.116 v6.1.33 for linux-yocto on 09/06/2023 Kevin Hao wrote: > Hi Bruce, > > This is a trial merge of the stable kernel v5.15.116 v6.1.33 for the > following branches in the linux-yocto. > b0e9a39058ad v5.15/standard/sdkv5.10/axxia > 3cf221b9e147 v5.15/standard/preempt-rt/sdkv5.10/axxia > 6297cf31f2d4 v5.15/standard/base > a0128f43ee89 v5.15/standard/preempt-rt/base > f238650795f0 v5.15/standard/cn-sdkv5.4/octeon > 880376765107 v5.15/standard/preempt-rt/cn-sdkv5.4/octeon > 19b81b959b97 v5.15/standard/cn-sdkv5.15/octeon > 1d399987502f v5.15/standard/preempt-rt/cn-sdkv5.15/octeon > 733961a9e14c v5.15/standard/ti-sdk-5.10/ti-j72xx > f5a87e4cd3b1 v5.15/standard/preempt-rt/ti-sdk-5.10/ti-j72xx > f609b097d46f v5.15/standard/nxp-sdk-5.15/nxp-soc > 7a5690f55876 v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc > d93147dedb3f v5.15/standard/bcm-2xxx-rpi > 25e3c5c7c1e7 v5.15/standard/preempt-rt/bcm-2xxx-rpi > ed2eb07bf630 v5.15/standard/nxp-sdk-5.15/nxp-s32g > e740512652f7 v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g > 722854cbd7d0 v5.15/standard/intel-sdk-5.15/intel-socfpga > 9f700e5e143c v5.15/standard/preempt-rt/intel-sdk-5.15/intel-socfpga > 22966cd59668 v5.15/standard/x86 > a245c0f608bc v5.15/standard/preempt-rt/x86 > b06e2009d807 v5.15/standard/sdkv5.15/xlnx-soc > 62f47b591681 v5.15/standard/preempt-rt/sdkv5.15/xlnx-soc > c8c5579cb846 v6.1/standard/base > b7766b32efae v6.1/standard/preempt-rt/base > 670a5fbad429 v6.1/standard/ti-sdk-6.1/ti-j7xxx > bdbae08cf02d v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx > 8f3fea71f103 v6.1/standard/nxp-sdk-6.1/nxp-soc > e39c95984cc8 v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc > 0e3df600facd v6.1/standard/cn-sdkv5.15/octeon > a2dc26d89057 v6.1/standard/preempt-rt/cn-sdkv5.15/octeon > 34bfb07787f2 v6.1/standard/bcm-2xxx-rpi > f3460a9443ec v6.1/standard/preempt-rt/bcm-2xxx-rpi > 0bc567b4dab9 v6.1/standard/nxp-sdk-5.15/nxp-s32g > d2ea28c7c1b2 v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g > 158d5c11091d v6.1/standard/intel-sdk-6.1/intel-socfpga > f44f96cfbc02 v6.1/standard/preempt-rt/intel-sdk-6.1/intel-socfpga > c8c5579cb846 v6.1/standard/x86 > f678bb7f7b3b v6.1/standard/preempt-rt/x86 > aac97db53af9 v6.1/standard/sdkv6.1/xlnx-soc > 4e14a5e778ff v6.1/standard/preempt-rt/sdkv6.1/xlnx-soc > > A perfect stable release and there is no any merge conflict. My build script > exposes > two build errors on the new created octeon branches. I have sent out the > fixes [1] for them. > All the branches have passed my build test. I have pushed all these branches > to: > https://github.com/haokexin/linux Thanks Kevin, I've merged the two octeon fixes. Bruce > > You can use this as a reference for the linux-yocto stable kernel bump. > > [1] https://lists.yoctoproject.org/g/linux-yocto/message/12726 > > Thanks, > Kevin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12748): https://lists.yoctoproject.org/g/linux-yocto/message/12748 Mute This Topic: https://lists.yoctoproject.org/mt/99429725/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [yocto-kernel-cache v6.1/v5.15]: nxp-s32g: disable the 4K sector setting for mtd device
In message: [yocto-kernel-cache v6.1/v5.15]: nxp-s32g: disable the 4K sector setting for mtd device on 12/06/2023 Zhantao Tang wrote: > Hi Bruce, > > The following patch is to disable the 4K sector setting for mtd device, > would you please help to merge it into yocto-6.1 and yocto-5.15 branches? merged. Bruce > > Thanks, > Zhantao -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12749): https://lists.yoctoproject.org/g/linux-yocto/message/12749 Mute This Topic: https://lists.yoctoproject.org/mt/99477480/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto][linux-yocto v5.15] kernel code for marvell cn96xx
In message: [linux-yocto][linux-yocto v5.15] kernel code for marvell cn96xx on 12/06/2023 Ruiqiang Hao wrote: > Hi Bruce, > > Please help to merge this patch into our linux-yocto repo. > > repo: > linux-yocto > branch: > v5.15/standard/cn-sdkv5.4/octeon > v5.15/standard/preempt-rt/cn-sdkv5.4/octeon merged. Bruce > > Thanks, > Ruiqiang -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12750): https://lists.yoctoproject.org/g/linux-yocto/message/12750 Mute This Topic: https://lists.yoctoproject.org/mt/99481784/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto][v6.1/standard/preempt-rt/sdkv6.1/xlnx-soc][PATCH] arm64: zynqmp: add "xlnx,nr-outputs" property for clk_wiz_0 node
In message: [linux-yocto][v6.1/standard/preempt-rt/sdkv6.1/xlnx-soc][PATCH] arm64: zynqmp: add "xlnx,nr-outputs" property for clk_wiz_0 node on 13/06/2023 quanyang.w...@windriver.com wrote: > From: Quanyang Wang > > In clk-xlnx-clock-wizard.c, the function clk_wzrd_probe will check if > there is "xlnx,nr-outputs" property, if not, the probe will return > error. Add "xlnx,nr-outputs" property for clk_wiz_0 node to avoid probe > failure. > > Signed-off-by: Quanyang Wang > --- > Hi Bruce, > Would you please help merge this patch to the branches: > v6.1/standard/preempt-rt/sdkv6.1/xlnx-soc > v6.1/standard/sdkv6.1/xlnx-soc merged. Bruce > Thanks, > Quanyang > --- > arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0-canfd.dts | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0-canfd.dts > b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0-canfd.dts > index 73ba3abd7aa89..d5b54d4a98d12 100644 > --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0-canfd.dts > +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0-canfd.dts > @@ -69,6 +69,7 @@ clk_wiz_0: clk_wiz@8001 { > compatible = "xlnx,clk-wiz-6.0", "xlnx,clocking-wizard"; > reg = <0x0 0x8001 0x0 0x1>; > speed-grade = <2>; > + xlnx,nr-outputs = <7>; > }; > psu_ctrl_ipi: PERIPHERAL@ff38 { > compatible = "xlnx,PERIPHERAL-1.0"; > -- > 2.36.1 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12751): https://lists.yoctoproject.org/g/linux-yocto/message/12751 Mute This Topic: https://lists.yoctoproject.org/mt/99499864/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto][linux-yocto v6.1/standard/ti-sdk-6.1/ti-j7xxx & v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx][PATCH 1/2] mtd: spi-nor: core: avoid odd length/address reads on 8D-8D-8D mode
merged. Bruce In message: [linux-yocto][linux-yocto v6.1/standard/ti-sdk-6.1/ti-j7xxx & v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx][PATCH 1/2] mtd: spi-nor: core: avoid odd length/address reads on 8D-8D-8D mode on 13/06/2023 Xulin Sun wrote: > From: Pratyush Yadav > > commit c515105b5c117888b6859534a7c694489f6bcf6d from > git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git > > On Octal DTR capable flashes like Micron Xcella reads cannot start or > end at an odd address in Octal DTR mode. Extra bytes need to be read at > the start or end to make sure both the start address and length remain > even. > > To avoid allocating too much extra memory, thereby putting unnecessary > memory pressure on the system, the temporary buffer containing the extra > padding bytes is capped at PAGE_SIZE bytes. The rest of the 2-byte > aligned part should be read directly in the main buffer. > > Signed-off-by: Pratyush Yadav > Signed-off-by: Apurva Nandan > Signed-off-by: Vignesh Raghavendra > Signed-off-by: Xulin Sun > --- > drivers/mtd/spi-nor/core.c | 81 +- > 1 file changed, 80 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c > index 99194aa07196..ad068610ae80 100644 > --- a/drivers/mtd/spi-nor/core.c > +++ b/drivers/mtd/spi-nor/core.c > @@ -1696,6 +1696,82 @@ static const struct flash_info *spi_nor_detect(struct > spi_nor *nor) > return info; > } > > +/* > + * On Octal DTR capable flashes like Micron Xcella reads cannot start or > + * end at an odd address in Octal DTR mode. Extra bytes need to be read > + * at the start or end to make sure both the start address and length > + * remain even. > + */ > +static int spi_nor_octal_dtr_read(struct spi_nor *nor, loff_t from, size_t > len, > + u_char *buf) > +{ > + u_char *tmp_buf; > + size_t tmp_len; > + loff_t start, end; > + int ret, bytes_read; > + > + if (IS_ALIGNED(from, 2) && IS_ALIGNED(len, 2)) > + return spi_nor_read_data(nor, from, len, buf); > + else if (IS_ALIGNED(from, 2) && len > PAGE_SIZE) > + return spi_nor_read_data(nor, from, round_down(len, PAGE_SIZE), > + buf); > + > + tmp_buf = kmalloc(PAGE_SIZE, GFP_KERNEL); > + if (!tmp_buf) > + return -ENOMEM; > + > + start = round_down(from, 2); > + end = round_up(from + len, 2); > + > + /* > + * Avoid allocating too much memory. The requested read length might be > + * quite large. Allocating a buffer just as large (slightly bigger, in > + * fact) would put unnecessary memory pressure on the system. > + * > + * For example if the read is from 3 to 1M, then this will read from 2 > + * to 4098. The reads from 4098 to 1M will then not need a temporary > + * buffer so they can proceed as normal. > + */ > + tmp_len = min_t(size_t, end - start, PAGE_SIZE); > + > + ret = spi_nor_read_data(nor, start, tmp_len, tmp_buf); > + if (ret == 0) { > + ret = -EIO; > + goto out; > + } > + if (ret < 0) > + goto out; > + > + /* > + * More bytes are read than actually requested, but that number can't be > + * reported to the calling function or it will confuse its calculations. > + * Calculate how many of the _requested_ bytes were read. > + */ > + bytes_read = ret; > + > + if (from != start) > + ret -= from - start; > + > + /* > + * Only account for extra bytes at the end if they were actually read. > + * For example, if the total length was truncated because of temporary > + * buffer size limit then the adjustment for the extra bytes at the end > + * is not needed. > + */ > + if (start + bytes_read == end) > + ret -= end - (from + len); > + > + if (ret < 0) { > + ret = -EIO; > + goto out; > + } > + > + memcpy(buf, tmp_buf + (from - start), ret); > +out: > + kfree(tmp_buf); > + return ret; > +} > + > static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, > size_t *retlen, u_char *buf) > { > @@ -1713,7 +1789,10 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t > from, size_t len, > > addr = spi_nor_convert_addr(nor, addr); > > - ret = spi_nor_read_data(nor, addr, len, buf); > + if (nor->read_proto == SNOR_PROTO_8_8_8_DTR) > + ret = spi_nor_octal_dtr_read(nor, addr, len, buf); > + else > + ret = spi_nor_read_data(nor, addr, len, buf); > if (ret == 0) { > /* We shouldn't see 0-length reads */ > ret = -EIO; > -- > 2.35.5 > In message: [linux-yocto][linux-yocto v6.1/standard/ti-sdk-6.1/ti-j7xxx & v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx][PATCH 2/2] mtd: s
[linux-yocto] [std/rt kernel v6.1]: nxp-s32g: serial: linflexuart: fix STR failure issue
Hi Bruce, The following two patches are to fix STR failure issue. Would you please help to merge them into the following: v6.1/standard/nxp-sdk-5.15/nxp-s32g v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g branches? Thanks, Zhantao -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12753): https://lists.yoctoproject.org/g/linux-yocto/message/12753 Mute This Topic: https://lists.yoctoproject.org/mt/99519833/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/2] serial: linflexuart: correct dma operations to fix Sleep-To-RAM failure
The commit a78233959f79 ("tty: serial: linflexuart: UART support for FIFO with DMA") put the dma operations in wrong place, causing Sleep-To-RAM failure from resume, so correct the location of these operations to fix the issue. Signed-off-by: Zhantao Tang --- drivers/tty/serial/fsl_linflexuart.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/tty/serial/fsl_linflexuart.c b/drivers/tty/serial/fsl_linflexuart.c index 51475d92c998..b092c93df472 100644 --- a/drivers/tty/serial/fsl_linflexuart.c +++ b/drivers/tty/serial/fsl_linflexuart.c @@ -1615,6 +1615,12 @@ static int linflex_remove(struct platform_device *pdev) clk_disable_unprepare(lfport->clk_ipg); #endif + if (lfport->dma_tx_chan) + dma_release_channel(lfport->dma_tx_chan); + + if (lfport->dma_rx_chan) + dma_release_channel(lfport->dma_rx_chan); + return 0; } @@ -1629,12 +1635,6 @@ static int linflex_suspend(struct device *dev) clk_disable_unprepare(lfport->clk); clk_disable_unprepare(lfport->clk_ipg); - if (lfport->dma_tx_chan) - dma_release_channel(lfport->dma_tx_chan); - - if (lfport->dma_rx_chan) - dma_release_channel(lfport->dma_rx_chan); - return 0; } -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12754): https://lists.yoctoproject.org/g/linux-yocto/message/12754 Mute This Topic: https://lists.yoctoproject.org/mt/99519834/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 2/2] serial: linflexuart: drop the unneeded stack variable
In commit a78233959f79 ("tty: serial: linflexuart: UART support for FIFO with DMA"), the second param of linflex_console_putchar() has been updated to "unsigned char" to compatible with v6.1 kernel, then the ich variable in linflex_poll_putchar() is not needed anymore, so drop it. Signed-off-by: Zhantao Tang --- drivers/tty/serial/fsl_linflexuart.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/tty/serial/fsl_linflexuart.c b/drivers/tty/serial/fsl_linflexuart.c index b092c93df472..1b518808dcf4 100644 --- a/drivers/tty/serial/fsl_linflexuart.c +++ b/drivers/tty/serial/fsl_linflexuart.c @@ -1204,7 +1204,6 @@ static int linflex_poll_init(struct uart_port *port) static void linflex_poll_putchar(struct uart_port *port, unsigned char ch) { - int ich = ch; unsigned long flags; struct linflex_port *sport = container_of(port, struct linflex_port, port); @@ -1216,7 +1215,7 @@ static void linflex_poll_putchar(struct uart_port *port, unsigned char ch) linflex_poll_init(port); } - linflex_console_putchar(port, ich); + linflex_console_putchar(port, ch); spin_unlock_irqrestore(&sport->port.lock, flags); } -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12755): https://lists.yoctoproject.org/g/linux-yocto/message/12755 Mute This Topic: https://lists.yoctoproject.org/mt/99519835/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [yocto-kernel-cache][yocto-6.1][PATCH] bsp: xilinx-zynqmp: add XILINX_INTC to support "xlnx,xps-intc-1.00.a"
From: Quanyang Wang We need to enable CONFIG_XILINX_INTC in order to verify Xilinx FPGA related interrupt controller driver irq-xilinx-intc.c. Signed-off-by: Quanyang Wang --- Hi Bruce, Would you please help merge this patch to the branch: yocto-6.1 Thanks, Quanyang --- bsp/xilinx-zynqmp/xilinx-zynqmp.cfg | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg b/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg index f236a7c070..036d3c08a3 100644 --- a/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg +++ b/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg @@ -249,3 +249,5 @@ CONFIG_ZYNQMP_FIRMWARE_DEBUG=y CONFIG_CRYPTO_DEV_ZYNQMP_SHA3=y CONFIG_CRYPTO_DEV_XILINX_RSA=y CONFIG_CRYPTO_DEV_ZYNQMP_AES=y + +CONFIG_XILINX_INTC=y -- 2.36.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12756): https://lists.yoctoproject.org/g/linux-yocto/message/12756 Mute This Topic: https://lists.yoctoproject.org/mt/99519837/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-