Re: linux-next: Fixes tag needs some work in the pinctrl tree
On 4/12/21 2:00 AM, Stephen Rothwell wrote:
> Hi all,
>
Hi!
> In commit
>
> 2cfebcb2a22f ("pinctrl: at91-pio4: Fix slew rate disablement")
>
> Fixes tag
>
> Fixes: 440b144978ba ("pinctrl: at91-pio4: add support for slew-rate")
>
> has these problem(s):
>
> - Target SHA1 does not exist
oh, yes.
>
> Maybe you meant
>
> Fixes: c709135e576b ("pinctrl: at91-pio4: add support for slew-rate")
You're correct. It seems that I used a vendor branch when looking for the
fixes tag, sorry. I'll be more careful next time.
Cheers,
ta
Re: [PATCH] mtd: add OTP (one-time-programmable) erase ioctl
Michael, Would you please resend this patch, together with the mtd-utils and the SPI NOR patch in a single patch set? You'll help us all having all in a single place. For the new ioctl we'll need acks from all the mtd maintainers and at least a tested-by tag. Cheers, ta
Re: [PATCH -next] dmaengine: at_xdmac: Remove unused inline function at_xdmac_csize()
On 4/6/21 11:50 AM, YueHaibing wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> 765c37d87669 ("dmaengine: at_xdmac: rework slave configuration part")
> left behind this, so can remove it.
Checkpatch complains:
ERROR: Please use git commit description style 'commit <12+ chars of sha1>
("")' - ie: 'commit 765c37d87669 ("dmaengine: at_xdmac: rework
slave configuration part")'
but the change is good:
Reviewed-by: Tudor Ambarus
>
> Signed-off-by: YueHaibing
> ---
> drivers/dma/at_xdmac.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index fe45ad5d06c4..64a52bf4d737 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -344,17 +344,6 @@ static inline int at_xdmac_chan_is_paused(struct
> at_xdmac_chan *atchan)
> return test_bit(AT_XDMAC_CHAN_IS_PAUSED, >status);
> }
>
> -static inline int at_xdmac_csize(u32 maxburst)
> -{
> - int csize;
> -
> - csize = ffs(maxburst) - 1;
> - if (csize > 4)
> - csize = -EINVAL;
> -
> - return csize;
> -};
> -
> static inline bool at_xdmac_chan_is_peripheral_xfer(u32 cfg)
> {
> return cfg & AT_XDMAC_CC_TYPE_PER_TRAN;
> --
> 2.17.1
>
Re: [PATCH] drivers: mtd: ubi: Remove unnecessary struct declaration
On 4/6/21 9:37 AM, Wan Jiabing wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> struct ubi_wl_entry is defined at 178th line.
> The declaration here is unnecessary. Remove it.
>
> Signed-off-by: Wan Jiabing
the subject of the patch should start with "ubi:", thus
"ubi: Remove unnecessary struct declaration"
with that:
Reviewed-by: Tudor Ambarus
> ---
> drivers/mtd/ubi/ubi.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
> index c2da77163f94..7c083ad58274 100644
> --- a/drivers/mtd/ubi/ubi.h
> +++ b/drivers/mtd/ubi/ubi.h
> @@ -388,8 +388,6 @@ struct ubi_volume_desc {
> int mode;
> };
>
> -struct ubi_wl_entry;
> -
> /**
> * struct ubi_debug_info - debugging information for an UBI device.
> *
> --
> 2.25.1
>
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
Re: [PATCH 1/2] mtd: spi-nor: sfdp: save a copy of the SFDP data
On 4/5/21 6:07 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi,
>
> Am 2021-04-05 15:11, schrieb tudor.amba...@microchip.com:
>> On 3/18/21 11:24 AM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> Due to possible mode switching to 8D-8D-8D, it might not be possible
>>> to
>>> read the SFDP after the initial probe. To be able to dump the SFDP via
>>> sysfs afterwards, make a complete copy of it.
>>>
>>> Signed-off-by: Michael Walle
>>> ---
>>> drivers/mtd/spi-nor/core.h | 10
>>> drivers/mtd/spi-nor/sfdp.c | 49
>>> +
>>> include/linux/mtd/spi-nor.h | 3 +++
>>> 3 files changed, 62 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
>>> index 4a3f7f150b5d..668f22011b1d 100644
>>> --- a/drivers/mtd/spi-nor/core.h
>>> +++ b/drivers/mtd/spi-nor/core.h
>>> @@ -407,6 +407,16 @@ struct spi_nor_manufacturer {
>>> const struct spi_nor_fixups *fixups;
>>> };
>>>
>>> +/**
>>> + * struct sfdp - SFDP data
>>> + * @num_dwords: number of entries in the dwords array
>>> + * @dwords: array of double words of the SFDP data
>>> + */
>>> +struct sfdp {
>>> + size_t num_dwords;
>>> + u32 *dwords;
>>> +};
>>> +
>>> /* Manufacturer drivers. */
>>> extern const struct spi_nor_manufacturer spi_nor_atmel;
>>> extern const struct spi_nor_manufacturer spi_nor_catalyst;
>>> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
>>> index 25142ec4737b..2b6c96e02532 100644
>>> --- a/drivers/mtd/spi-nor/sfdp.c
>>> +++ b/drivers/mtd/spi-nor/sfdp.c
>>> @@ -16,6 +16,7 @@
>>> (((p)->parameter_table_pointer[2] << 16) | \
>>> ((p)->parameter_table_pointer[1] << 8) | \
>>> ((p)->parameter_table_pointer[0] << 0))
>>> +#define SFDP_PARAM_HEADER_PARAM_LEN(p) ((p)->length * 4)
>>>
>>> #define SFDP_BFPT_ID 0xff00 /* Basic Flash Parameter Table
>>> */
>>> #define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
>>> @@ -1263,6 +1264,8 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
>>> struct sfdp_parameter_header *param_headers = NULL;
>>> struct sfdp_header header;
>>> struct device *dev = nor->dev;
>>> + struct sfdp *sfdp;
>>> + size_t sfdp_size;
>>> size_t psize;
>>> int i, err;
>>>
>>> @@ -1285,6 +1288,9 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
>>> bfpt_header->major != SFDP_JESD216_MAJOR)
>>> return -EINVAL;
>>>
>>> + sfdp_size = SFDP_PARAM_HEADER_PTP(bfpt_header) +
>>> + SFDP_PARAM_HEADER_PARAM_LEN(bfpt_header);
>>> +
>>> /*
>>> * Allocate memory then read all parameter headers with a
>>> single
>>> * Read SFDP command. These parameter headers will actually be
>>> parsed
>>> @@ -1311,6 +1317,49 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
>>> }
>>> }
>>>
>>> + /*
>>> + * Cache the complete SFDP data. It is not (easily) possible
>>> to fetch
>>> + * SFDP after probe time and we need it for the sysfs access.
>>> + */
>>> + for (i = 0; i < header.nph; i++) {
>>> + param_header = _headers[i];
>>> + sfdp_size = max_t(size_t, sfdp_size,
>>> + SFDP_PARAM_HEADER_PTP(param_header)
>>> +
>>> +
>>> SFDP_PARAM_HEADER_PARAM_LEN(param_header));
>>> + }
>>
>> Michael, I like the idea of saving the SFDP data, but I think this can
>> be
>> improved a little. For example, it is not mandatory for the tables to
>> be
>> continuous in memory, there can be some gaps between BFPT and SMPT for
>> example,
>> thus we can improve the memory allocation logic.
>
> I want to parse the SFDP as little as possible. Keep in mind, that this
> should
> help to debug SFDP (errors). Therefore, I don't want to rely on the SFDP
> saying
> "hey there is a hole, please skip it". Who knows if there is some useful
> data?
What kind of useful data? Do we care about data that doesn't follow the jesd216
standard?
>
>> Also, we can make the saved sfdp
>> data table-agnostic so that we don't duplicate the reads in
>> parse_bfpt/smpt/4bait.
>
> This falls into the same category as above. While it might be reused,
> the
> primary use case is to have the SFDP data available to a developer/user.
> Eg.
> what will you do with some holes in the sysfs read()? Return zeros?
We don't have to have gaps in our internal buffer, we just allocate as much
as we need and we write into our internal buffer just the sfdp tables, without
the gaps.
>
> FWIW I'm planning to refactor the read code so the cached values are
> used.
>
> -michael
Re: [PATCH 1/2] mtd: spi-nor: sfdp: save a copy of the SFDP data
Hi,
On 3/18/21 11:24 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Due to possible mode switching to 8D-8D-8D, it might not be possible to
> read the SFDP after the initial probe. To be able to dump the SFDP via
> sysfs afterwards, make a complete copy of it.
>
> Signed-off-by: Michael Walle
> ---
> drivers/mtd/spi-nor/core.h | 10
> drivers/mtd/spi-nor/sfdp.c | 49 +
> include/linux/mtd/spi-nor.h | 3 +++
> 3 files changed, 62 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 4a3f7f150b5d..668f22011b1d 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -407,6 +407,16 @@ struct spi_nor_manufacturer {
> const struct spi_nor_fixups *fixups;
> };
>
> +/**
> + * struct sfdp - SFDP data
> + * @num_dwords: number of entries in the dwords array
> + * @dwords: array of double words of the SFDP data
> + */
> +struct sfdp {
> + size_t num_dwords;
> + u32 *dwords;
> +};
> +
> /* Manufacturer drivers. */
> extern const struct spi_nor_manufacturer spi_nor_atmel;
> extern const struct spi_nor_manufacturer spi_nor_catalyst;
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index 25142ec4737b..2b6c96e02532 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -16,6 +16,7 @@
> (((p)->parameter_table_pointer[2] << 16) | \
> ((p)->parameter_table_pointer[1] << 8) | \
> ((p)->parameter_table_pointer[0] << 0))
> +#define SFDP_PARAM_HEADER_PARAM_LEN(p) ((p)->length * 4)
>
> #define SFDP_BFPT_ID 0xff00 /* Basic Flash Parameter Table */
> #define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
> @@ -1263,6 +1264,8 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
> struct sfdp_parameter_header *param_headers = NULL;
> struct sfdp_header header;
> struct device *dev = nor->dev;
> + struct sfdp *sfdp;
> + size_t sfdp_size;
> size_t psize;
> int i, err;
>
> @@ -1285,6 +1288,9 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
> bfpt_header->major != SFDP_JESD216_MAJOR)
> return -EINVAL;
>
> + sfdp_size = SFDP_PARAM_HEADER_PTP(bfpt_header) +
> + SFDP_PARAM_HEADER_PARAM_LEN(bfpt_header);
> +
> /*
> * Allocate memory then read all parameter headers with a single
> * Read SFDP command. These parameter headers will actually be parsed
> @@ -1311,6 +1317,49 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
> }
> }
>
> + /*
> +* Cache the complete SFDP data. It is not (easily) possible to fetch
> +* SFDP after probe time and we need it for the sysfs access.
> +*/
> + for (i = 0; i < header.nph; i++) {
> + param_header = _headers[i];
> + sfdp_size = max_t(size_t, sfdp_size,
> + SFDP_PARAM_HEADER_PTP(param_header) +
> + SFDP_PARAM_HEADER_PARAM_LEN(param_header));
> + }
Michael, I like the idea of saving the SFDP data, but I think this can be
improved a little. For example, it is not mandatory for the tables to be
continuous in memory, there can be some gaps between BFPT and SMPT for example,
thus we can improve the memory allocation logic. Also, we can make the saved
sfdp
data table-agnostic so that we don't duplicate the reads in
parse_bfpt/smpt/4bait.
Are you willing to respin?
Cheers,
ta
Re: [PATCH 06/10] crypto: atmel-ecc: Struct headers need to start with keyword 'struct'
On 3/18/21 2:44 PM, Lee Jones wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Fixes the following W=1 kernel build warning(s): > > drivers/crypto/atmel-ecc.c:41: warning: cannot understand function > prototype: 'struct atmel_ecdh_ctx ' > > Cc: Tudor Ambarus > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Nicolas Ferre > Cc: Alexandre Belloni > Cc: Ludovic Desroches > Cc: linux-cry...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Lee Jones Reviewed-by: Tudor Ambarus > --- > drivers/crypto/atmel-ecc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c > index 515946c99394e..333fbefbbccbd 100644 > --- a/drivers/crypto/atmel-ecc.c > +++ b/drivers/crypto/atmel-ecc.c > @@ -26,7 +26,7 @@ > static struct atmel_ecc_driver_data driver_data; > > /** > - * atmel_ecdh_ctx - transformation context > + * struct atmel_ecdh_ctx - transformation context > * @client : pointer to i2c client device > * @fallback : used for unsupported curves or when user wants to use its > own > * private key. > -- > 2.27.0 >
Re: [PATCH] crypto: atmel-ecc - fix W=1 "cannot understand" warning
On 3/20/21 10:15 AM, Meng Yu wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Fix kernel-doc warnings due to missing "struct" keyword. > > The warning likes: > drivers/crypto/atmel-ecc.c:40: warning: cannot understand function prototype: > 'struct atmel_ecdh_ctx ' > > Signed-off-by: Meng Yu Thanks. There is a patch similar to yours that was sent in advance: https://patchwork.kernel.org/project/linux-crypto/patch/20210318124422.3200180-7-lee.jo...@linaro.org/ > --- > drivers/crypto/atmel-ecc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c > index 515946c..333fbef 100644 > --- a/drivers/crypto/atmel-ecc.c > +++ b/drivers/crypto/atmel-ecc.c > @@ -26,7 +26,7 @@ > static struct atmel_ecc_driver_data driver_data; > > /** > - * atmel_ecdh_ctx - transformation context > + * struct atmel_ecdh_ctx - transformation context > * @client : pointer to i2c client device > * @fallback : used for unsupported curves or when user wants to use its > own > * private key. > -- > 2.8.1 >
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/17/21 10:21 AM, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Am 2021-03-17 07:09, schrieb tudor.amba...@microchip.com: >> On 3/15/21 8:23 AM, Vignesh Raghavendra wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know >>> the content is safe >>> >>> On 3/9/21 12:58 PM, tudor.amba...@microchip.com wrote: On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you > know the content is safe > > On 3/6/21 3:20 PM, Tudor Ambarus wrote: >> It makes the core file a bit smaller and provides better separation >> between the Software Write Protection features and the core logic. >> All the next generic software write protection features (e.g. >> Individual >> Block Protection) will reside in swp.c. >> >> Signed-off-by: Tudor Ambarus >> --- >> drivers/mtd/spi-nor/Makefile | 2 +- >> drivers/mtd/spi-nor/core.c | 407 >> +- >> drivers/mtd/spi-nor/core.h | 4 + >> drivers/mtd/spi-nor/swp.c | 419 >> +++ > > Hmmm, name swp.c does not seem intuitive to me. How about expanding > it a > bit: > > soft-wr-protect.c or software-write-protect.c ? >> >> Having in mind that we have the SWP configs, I think I prefer swp.c. >> But let's see what majority thinks, we'll do as majority prefers. >> Michael, Pratyush? > > It's just an internal name, thus as long as it remotely makes sense, > I'm fine. It's just a matter of taste, isn't it? Sure, it's a matter of preference. What's yours? > > But here's one technical reason that would bother me more: name > clashes between the core modules: core, sfdp, otp, swp and the > vendor names. It is very unlikely, but there is a non-zero chance ;) > We can move all manufacturers to a manufacturers/ folder. Each manufacturer driver will have to #include "../core.h", about what I have some mixed feelings.
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/15/21 8:23 AM, Vignesh Raghavendra wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 3/9/21 12:58 PM, tudor.amba...@microchip.com wrote: >> On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >>> content is safe >>> >>> On 3/6/21 3:20 PM, Tudor Ambarus wrote: It makes the core file a bit smaller and provides better separation between the Software Write Protection features and the core logic. All the next generic software write protection features (e.g. Individual Block Protection) will reside in swp.c. Signed-off-by: Tudor Ambarus --- drivers/mtd/spi-nor/Makefile | 2 +- drivers/mtd/spi-nor/core.c | 407 +- drivers/mtd/spi-nor/core.h | 4 + drivers/mtd/spi-nor/swp.c| 419 +++ >>> >>> Hmmm, name swp.c does not seem intuitive to me. How about expanding it a >>> bit: >>> >>> soft-wr-protect.c or software-write-protect.c ? Having in mind that we have the SWP configs, I think I prefer swp.c. But let's see what majority thinks, we'll do as majority prefers. Michael, Pratyush? >>> >> cut > > I am not a fan of renaming Kconfig options as it breaks make > olddefconfig flow which many developers rely on. > I'm fine keeping them as they are for now. If someone else screams we will reconsider.
Re: [PATCH v2 5/5] mtd: spi-nor: swp: Drop 'else' after 'return'
On 3/15/21 8:53 AM, Joe Perches wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Mon, 2021-03-08 at 11:58 +0530, Pratyush Yadav wrote:
>> On 06/03/21 11:50AM, Tudor Ambarus wrote:
>>> else is not generally useful after a break or return.
>>>
>>> Signed-off-by: Tudor Ambarus
>>
>> Reviewed-by: Pratyush Yadav
>>
>
> I don't think this improves the code.
>
> Generally, checkpatch is a stupid little script.
>
> This code uses a form like:
> if (foo)
> return bar;
> else
> return baz;
Isn't else redundant? What are the benefits of keeping the else?
>
> which checkpatch recognizes as OK and so checkpatch does not
> emit any warning message, but this code just adds comments
> before each return which confuses checkpatch.
>
> I think better would be to change the code to use temporaries
> and convert the functions to bool.
>
> Something like:
> ---
> drivers/mtd/spi-nor/core.c | 25 +++--
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 0522304f52fa..e174a2f1d621 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1798,36 +1798,41 @@ static void spi_nor_get_locked_range_sr(struct
> spi_nor *nor, u8 sr, loff_t *ofs,
> }
>
> /*
> - * Return 1 if the entire region is locked (if @locked is true) or unlocked
> (if
> - * @locked is false); 0 otherwise
> + * Return true if the entire region is locked
> + * (if @locked is true) or unlocked (if @locked is false); false otherwise
> */
> -static int spi_nor_check_lock_status_sr(struct spi_nor *nor, loff_t ofs,
> +static bool spi_nor_check_lock_status_sr(struct spi_nor *nor, loff_t ofs,
> uint64_t len, u8 sr, bool locked)
> {
> loff_t lock_offs;
> uint64_t lock_len;
> + uint64_t lock_max;
> + uint64_t ofs_max;
>
> if (!len)
> - return 1;
> + return true;
returning one is wrong indeed, would you submit a patch for the conversion
of the functions to bool?
>
> spi_nor_get_locked_range_sr(nor, sr, _offs, _len);
>
> + lock_max = lock_offs + lock_len;
> + ofs_max = ofs + len;
> +
> if (locked)
> /* Requested range is a sub-range of locked range */
> - return (ofs + len <= lock_offs + lock_len) && (ofs >=
> lock_offs);
> + return (ofs_max <= lock_max) && (ofs >= lock_offs);
> else
> /* Requested range does not overlap with locked range */
> - return (ofs >= lock_offs + lock_len) || (ofs + len <=
> lock_offs);
> + return (ofs >= lock_max) || (ofs_max <= lock_offs);
This should be fine too.
Cheers,
ta
Re: [PATCH v4 1/4] mtd: spi-nor: add OTP support
On 3/15/21 11:39 AM, Tudor Ambarus - M18064 wrote: > On 3/15/21 11:23 AM, Michael Walle wrote: > > cut > diff --git a/drivers/mtd/spi-nor/otp.c b/drivers/mtd/spi-nor/otp.c new file mode 100644 index ..4e301fd5156b --- /dev/null +++ b/drivers/mtd/spi-nor/otp.c @@ -0,0 +1,218 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * OTP support for SPI NOR flashes + * + * Copyright (C) 2021 Michael Walle > + */ + +#include +#include +#include + +#include "core.h" + +#define spi_nor_otp_ops(nor) ((nor)->params->otp.ops) +#define spi_nor_otp_region_len(nor) ((nor)->params->otp.org->len) +#define spi_nor_otp_n_regions(nor) ((nor)->params->otp.org->n_regions) >>> >>> I don't like these wrappers because they gratuiously hide what's really >>> there. >>> I find the code more easier to read without these wrappers, because I >>> don't >>> have to memorize what these wrappers are doing, and I better see how >>> the code >>> is organized. >> >> TBH I find it easier on the eye and I've never seen so much dereferences >> as in mtd/spi-nor. the dereferences will still be there, but will be just hidden by these wrappers, don't they? Why would one prefer the wrappers? > > It's what I prefer, but it's not a hard requirement. Would you please check > for a second opinion with Vignesh? Inquire about the helpers too. Then do as > you find best. > > Cheers, > ta >
Re: [PATCH v4 1/4] mtd: spi-nor: add OTP support
On 3/15/21 11:23 AM, Michael Walle wrote: cut >>> diff --git a/drivers/mtd/spi-nor/otp.c b/drivers/mtd/spi-nor/otp.c >>> new file mode 100644 >>> index ..4e301fd5156b >>> --- /dev/null >>> +++ b/drivers/mtd/spi-nor/otp.c >>> @@ -0,0 +1,218 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * OTP support for SPI NOR flashes >>> + * >>> + * Copyright (C) 2021 Michael Walle > + */ >>> + >>> +#include >>> +#include >>> +#include >>> + >>> +#include "core.h" >>> + >>> +#define spi_nor_otp_ops(nor) ((nor)->params->otp.ops) >>> +#define spi_nor_otp_region_len(nor) ((nor)->params->otp.org->len) >>> +#define spi_nor_otp_n_regions(nor) >>> ((nor)->params->otp.org->n_regions) >> >> I don't like these wrappers because they gratuiously hide what's really >> there. >> I find the code more easier to read without these wrappers, because I >> don't >> have to memorize what these wrappers are doing, and I better see how >> the code >> is organized. > > TBH I find it easier on the eye and I've never seen so much dereferences > as in mtd/spi-nor. It's what I prefer, but it's not a hard requirement. Would you please check for a second opinion with Vignesh? Inquire about the helpers too. Then do as you find best. Cheers, ta
Re: [PATCH v4 3/4] mtd: spi-nor: winbond: add OTP support to w25q32fw/jw
On 3/15/21 11:26 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2021-03-15 09:26, schrieb tudor.amba...@microchip.com:
>> On 3/6/21 2:05 AM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> With all the helper functions in place, add OTP support for the
>>> Winbond
>>> W25Q32JW and W25Q32FW.
>>>
>>> Both were tested on a LS1028A SoC with a NXP FSPI controller.
>>>
>>> Signed-off-by: Michael Walle
>>> ---
>>> drivers/mtd/spi-nor/winbond.c | 17 +++--
>>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mtd/spi-nor/winbond.c
>>> b/drivers/mtd/spi-nor/winbond.c
>>> index e5dfa786f190..9a3f8ff007fd 100644
>>> --- a/drivers/mtd/spi-nor/winbond.c
>>> +++ b/drivers/mtd/spi-nor/winbond.c
>>> @@ -55,14 +55,18 @@ static const struct flash_info winbond_parts[] = {
>>> { "w25q32", INFO(0xef4016, 0, 64 * 1024, 64, SECT_4K) },
>>> { "w25q32dw", INFO(0xef6016, 0, 64 * 1024, 64,
>>> SECT_4K | SPI_NOR_DUAL_READ |
>>> SPI_NOR_QUAD_READ |
>>> - SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
>>> + SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
>>> + OTP_INFO(256, 3, 0x1000, 0x1000)
>>> + },
>>> +
>>> { "w25q32jv", INFO(0xef7016, 0, 64 * 1024, 64,
>>> SECT_4K | SPI_NOR_DUAL_READ |
>>> SPI_NOR_QUAD_READ |
>>> SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
>>> },
>>> { "w25q32jwm", INFO(0xef8016, 0, 64 * 1024, 64,
>>> SECT_4K | SPI_NOR_DUAL_READ |
>>> SPI_NOR_QUAD_READ |
>>> - SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
>>> + SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
>>> + OTP_INFO(256, 3, 0x1000, 0x1000) },
>>> { "w25q64jwm", INFO(0xef8017, 0, 64 * 1024, 128,
>>> SECT_4K | SPI_NOR_DUAL_READ |
>>> SPI_NOR_QUAD_READ |
>>> SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
>>> @@ -131,9 +135,18 @@ static int winbond_set_4byte_addr_mode(struct
>>> spi_nor *nor, bool enable)
>>> return spi_nor_write_disable(nor);
>>> }
>>>
>>> +static const struct spi_nor_otp_ops winbond_otp_ops = {
>>> + .read = spi_nor_otp_read_secr,
>>> + .write = spi_nor_otp_write_secr,
>>> + .lock = spi_nor_otp_lock_sr2,
>>> + .is_locked = spi_nor_otp_is_locked_sr2,
>>> +};
>>
>> Should we have this in otp.c? It can be shared with gigadevice as well
>> as far as I understood.
>
> It should work in principle for both vendors, but I couldn't test it. So
> for now, I've kept it private to winbond.c. If there will be OTP support
> for other flashes with the same ops, it should be moved.
>
Ok.
Re: [PATCH v4 4/4] mtd: spi-nor: implement OTP erase for Winbond and similar flashes
On 3/6/21 2:05 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Winbond flashes with OTP support provide a command to erase the OTP
> data. This might come in handy during development.
>
> This was tested with a Winbond W25Q32JW on a LS1028A SoC with the
> NXP FSPI controller.
>
> Signed-off-by: Michael Walle
I skimmed through this, seems ok. Send 4/4 with the new ioctl addition
in a dedicated patch set, ideally both will go through the spi-nor/next
branch. For the new ioctl we'll need ACKs from all the mtd maintainers
and at least a Tested-by tag. Please send the mtd-utils changes too.
Cheers,
ta
> ---
> drivers/mtd/spi-nor/core.c| 4 +-
> drivers/mtd/spi-nor/core.h| 4 ++
> drivers/mtd/spi-nor/otp.c | 74 ++-
> drivers/mtd/spi-nor/winbond.c | 1 +
> 4 files changed, 79 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index ef7df26896f1..21a737804576 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -166,8 +166,8 @@ static int spi_nor_controller_ops_read_reg(struct spi_nor
> *nor, u8 opcode,
> return nor->controller_ops->read_reg(nor, opcode, buf, len);
> }
>
> -static int spi_nor_controller_ops_write_reg(struct spi_nor *nor, u8 opcode,
> - const u8 *buf, size_t len)
> +int spi_nor_controller_ops_write_reg(struct spi_nor *nor, u8 opcode,
> +const u8 *buf, size_t len)
> {
> if (spi_nor_protocol_is_dtr(nor->reg_proto))
> return -EOPNOTSUPP;
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index dfbf6ba42b57..ef62ec4625a1 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -213,6 +213,7 @@ struct spi_nor_otp_ops {
> int (*read)(struct spi_nor *nor, loff_t addr, size_t len, u8 *buf);
> int (*write)(struct spi_nor *nor, loff_t addr, size_t len, u8 *buf);
> int (*lock)(struct spi_nor *nor, unsigned int region);
> + int (*erase)(struct spi_nor *nor, loff_t addr);
> int (*is_locked)(struct spi_nor *nor, unsigned int region);
> };
>
> @@ -481,6 +482,8 @@ extern const struct spi_nor_manufacturer spi_nor_xmc;
> void spi_nor_spimem_setup_op(const struct spi_nor *nor,
> struct spi_mem_op *op,
> const enum spi_nor_protocol proto);
> +int spi_nor_controller_ops_write_reg(struct spi_nor *nor, u8 opcode,
> +const u8 *buf, size_t len);
> int spi_nor_write_enable(struct spi_nor *nor);
> int spi_nor_write_disable(struct spi_nor *nor);
> int spi_nor_set_4byte_addr_mode(struct spi_nor *nor, bool enable);
> @@ -506,6 +509,7 @@ ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t
> to, size_t len,
>
> int spi_nor_otp_read_secr(struct spi_nor *nor, loff_t addr, size_t len, u8
> *buf);
> int spi_nor_otp_write_secr(struct spi_nor *nor, loff_t addr, size_t len, u8
> *buf);
> +int spi_nor_otp_erase_secr(struct spi_nor *nor, loff_t addr);
> int spi_nor_otp_lock_sr2(struct spi_nor *nor, unsigned int region);
> int spi_nor_otp_is_locked_sr2(struct spi_nor *nor, unsigned int region);
>
> diff --git a/drivers/mtd/spi-nor/otp.c b/drivers/mtd/spi-nor/otp.c
> index 4e8da9108c77..78ec79368c29 100644
> --- a/drivers/mtd/spi-nor/otp.c
> +++ b/drivers/mtd/spi-nor/otp.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
>
> #include "core.h"
>
> @@ -111,6 +112,50 @@ int spi_nor_otp_write_secr(struct spi_nor *nor, loff_t
> addr, size_t len, u8 *buf
> return ret ?: written;
> }
>
> +/**
> + * spi_nor_otp_erase_secr() - erase one OTP region
> + * @nor:pointer to 'struct spi_nor'
> + * @to: offset to write to
> + * @len:number of bytes to write
> + * @buf:pointer to src buffer
> + *
> + * Erase one OTP region by using the SPINOR_OP_ESECR commands. This method is
> + * used on GigaDevice and Winbond flashes.
> + *
> + * Return: 0 on success, -errno otherwise
> + */
> +int spi_nor_otp_erase_secr(struct spi_nor *nor, loff_t addr)
> +{
> + int ret;
> +
> + ret = spi_nor_write_enable(nor);
> + if (ret)
> + return ret;
> +
> + if (nor->spimem) {
> + struct spi_mem_op op =
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_ESECR, 0),
> + SPI_MEM_OP_ADDR(3, addr, 0),
> + SPI_MEM_OP_NO_DUMMY,
> + SPI_MEM_OP_NO_DATA);
> +
> + spi_nor_spimem_setup_op(nor, , nor->write_proto);
> +
> + ret = spi_mem_exec_op(nor->spimem, );
> + } else {
> + nor->bouncebuf[2] = addr & 0xff;
> + nor->bouncebuf[1] = (addr >> 8) & 0xff;
> + nor->bouncebuf[0] =
Re: [PATCH v4 2/4] mtd: spi-nor: implement OTP support for Winbond and similar flashes
On 3/6/21 2:05 AM, Michael Walle wrote: > + nor->dirmap.rdesc = NULL; why can't we use dirmap? > + > + ret = spi_nor_read_data(nor, addr, len, buf);
Re: [PATCH v4 3/4] mtd: spi-nor: winbond: add OTP support to w25q32fw/jw
On 3/6/21 2:05 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> With all the helper functions in place, add OTP support for the Winbond
> W25Q32JW and W25Q32FW.
>
> Both were tested on a LS1028A SoC with a NXP FSPI controller.
>
> Signed-off-by: Michael Walle
> ---
> drivers/mtd/spi-nor/winbond.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
> index e5dfa786f190..9a3f8ff007fd 100644
> --- a/drivers/mtd/spi-nor/winbond.c
> +++ b/drivers/mtd/spi-nor/winbond.c
> @@ -55,14 +55,18 @@ static const struct flash_info winbond_parts[] = {
> { "w25q32", INFO(0xef4016, 0, 64 * 1024, 64, SECT_4K) },
> { "w25q32dw", INFO(0xef6016, 0, 64 * 1024, 64,
>SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> - SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> + SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
> + OTP_INFO(256, 3, 0x1000, 0x1000)
> + },
> +
> { "w25q32jv", INFO(0xef7016, 0, 64 * 1024, 64,
>SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
>SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
> },
> { "w25q32jwm", INFO(0xef8016, 0, 64 * 1024, 64,
> SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> - SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> + SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
> + OTP_INFO(256, 3, 0x1000, 0x1000) },
> { "w25q64jwm", INFO(0xef8017, 0, 64 * 1024, 128,
> SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> @@ -131,9 +135,18 @@ static int winbond_set_4byte_addr_mode(struct spi_nor
> *nor, bool enable)
> return spi_nor_write_disable(nor);
> }
>
> +static const struct spi_nor_otp_ops winbond_otp_ops = {
> + .read = spi_nor_otp_read_secr,
> + .write = spi_nor_otp_write_secr,
> + .lock = spi_nor_otp_lock_sr2,
> + .is_locked = spi_nor_otp_is_locked_sr2,
> +};
Should we have this in otp.c? It can be shared with gigadevice as well
as far as I understood.
Cheers,
ta
> +
> static void winbond_default_init(struct spi_nor *nor)
> {
> nor->params->set_4byte_addr_mode = winbond_set_4byte_addr_mode;
> + if (nor->params->otp.org->n_regions)
> + nor->params->otp.ops = _otp_ops;
> }
>
> static const struct spi_nor_fixups winbond_fixups = {
> --
> 2.20.1
>
Re: [PATCH v4 2/4] mtd: spi-nor: implement OTP support for Winbond and similar flashes
On 3/6/21 2:05 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Use the new OTP ops to implement OTP access on Winbond flashes. Most
> Winbond flashes provides up to four different OTP regions ("Security
> Registers").
>
> Winbond devices use a special opcode to read and write to the OTP
> regions, just like the RDSFDP opcode. In fact, it seems that the
> (undocumented) first OTP area of the newer flashes is the actual SFDP
> table.
>
> On a side note, Winbond devices also allow erasing the OTP regions as
> long as the area isn't locked down.
>
> Signed-off-by: Michael Walle
> ---
> drivers/mtd/spi-nor/core.c | 2 +-
> drivers/mtd/spi-nor/core.h | 6 ++
> drivers/mtd/spi-nor/otp.c | 164
> include/linux/mtd/spi-nor.h | 9 ++
> 4 files changed, 180 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 0c5c757fa95b..ef7df26896f1 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1034,7 +1034,7 @@ static int spi_nor_write_16bit_sr_and_check(struct
> spi_nor *nor, u8 sr1)
> *
> * Return: 0 on success, -errno otherwise.
> */
> -static int spi_nor_write_16bit_cr_and_check(struct spi_nor *nor, u8 cr)
> +int spi_nor_write_16bit_cr_and_check(struct spi_nor *nor, u8 cr)
> {
> int ret;
> u8 *sr_cr = nor->bouncebuf;
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index ec8da1243846..dfbf6ba42b57 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -496,6 +496,7 @@ int spi_nor_read_sr(struct spi_nor *nor, u8 *sr);
> int spi_nor_read_cr(struct spi_nor *nor, u8 *cr);
> int spi_nor_write_sr(struct spi_nor *nor, const u8 *sr, size_t len);
> int spi_nor_write_sr_and_check(struct spi_nor *nor, u8 sr1);
> +int spi_nor_write_16bit_cr_and_check(struct spi_nor *nor, u8 cr);
>
> int spi_nor_xread_sr(struct spi_nor *nor, u8 *sr);
> ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t from, size_t len,
> @@ -503,6 +504,11 @@ ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t
> from, size_t len,
> ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t to, size_t len,
>const u8 *buf);
>
> +int spi_nor_otp_read_secr(struct spi_nor *nor, loff_t addr, size_t len, u8
> *buf);
> +int spi_nor_otp_write_secr(struct spi_nor *nor, loff_t addr, size_t len, u8
> *buf);
> +int spi_nor_otp_lock_sr2(struct spi_nor *nor, unsigned int region);
> +int spi_nor_otp_is_locked_sr2(struct spi_nor *nor, unsigned int region);
> +
> int spi_nor_hwcaps_read2cmd(u32 hwcaps);
> u8 spi_nor_convert_3to4_read(u8 opcode);
> void spi_nor_set_read_settings(struct spi_nor_read_command *read,
> diff --git a/drivers/mtd/spi-nor/otp.c b/drivers/mtd/spi-nor/otp.c
> index 4e301fd5156b..4e8da9108c77 100644
> --- a/drivers/mtd/spi-nor/otp.c
> +++ b/drivers/mtd/spi-nor/otp.c
> @@ -15,6 +15,170 @@
> #define spi_nor_otp_region_len(nor) ((nor)->params->otp.org->len)
> #define spi_nor_otp_n_regions(nor) ((nor)->params->otp.org->n_regions)
>
> +/**
> + * spi_nor_otp_read_secr() - read OTP data
> + * @nor: pointer to 'struct spi_nor'
> + * @from: offset to read from
> + * @len:number of bytes to read
> + * @buf:pointer to dst buffer
is buf DMA-able?
> + *
> + * Read OTP data from one region by using the SPINOR_OP_RSECR commands. This
> + * method is used on GigaDevice and Winbond flashes.
> + *
> + * Return: number of bytes read successfully, -errno otherwise
> + */
> +int spi_nor_otp_read_secr(struct spi_nor *nor, loff_t addr, size_t len, u8
> *buf)
> +{
> + u8 addr_width, read_opcode, read_dummy;
> + struct spi_mem_dirmap_desc *rdesc;
> + enum spi_nor_protocol read_proto;
> + int ret;
> +
> + read_opcode = nor->read_opcode;
> + addr_width = nor->addr_width;
> + read_dummy = nor->read_dummy;
> + read_proto = nor->read_proto;
> + rdesc = nor->dirmap.rdesc;
> +
> + nor->read_opcode = SPINOR_OP_RSECR;
> + nor->addr_width = 3;
> + nor->read_dummy = 8;
> + nor->read_proto = SNOR_PROTO_1_1_1;
any winbond/gigadevice flashes with octal dtr support? Do they
provide SEC Register opcodes for octal dtr?
> + nor->dirmap.rdesc = NULL;
> +
> + ret = spi_nor_read_data(nor, addr, len, buf);
> +
> + nor->read_opcode = read_opcode;
> + nor->addr_width = addr_width;
> + nor->read_dummy = read_dummy;
> + nor->read_proto = read_proto;
> + nor->dirmap.rdesc = rdesc;
> +
> + return ret;
> +}
> +
> +/**
> + * spi_nor_otp_write_secr() - write OTP data
> + * @nor:pointer to 'struct spi_nor'
> + * @to: offset to write to
> + * @len:number of bytes to write
> + * @buf:pointer to src buffer
> + *
> + * Write OTP data to one region by using the SPINOR_OP_PSECR commands. This
> + *
Re: [PATCH v4 1/4] mtd: spi-nor: add OTP support
Michael,
Just cosmetic suggestions this time.
On 3/6/21 2:05 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> SPI flashes sometimes have a special OTP area, which can (and is) used to
> store immutable properties like board serial number or vendor assigned
> network hardware addresses.
>
> The MTD subsystem already supports accessing such areas and some (non
> SPI NOR) flashes already implement support for it. It differentiates
> between user and factory areas. User areas can be written by the user and
> factory ones are pre-programmed and locked down by the vendor, usually
> containing an "electrical serial number". This patch will only add support
> for the user areas.
>
> Lay the foundation and implement the MTD callbacks for the SPI NOR and add
> necessary parameters to the flash_info structure. If a flash supports OTP
> it can be added by the convenience macro OTP_INFO(). Sometimes there are
> individual regions, which might have individual offsets. Therefore, it is
> possible to specify the starting address of the first regions as well as
> the distance between two regions (e.g. Winbond devices uses this method).
>
> Additionally, the regions might be locked down. Once locked, no further
> write access is possible.
>
> For SPI NOR flashes the OTP area is accessed like the normal memory, e.g.
> by offset addressing; except that you either have to use special read/write
> commands (Winbond) or you have to enter (and exit) a specific OTP mode
> (Macronix, Micron).
>
> Thus we introduce four operations to which the MTD callbacks will be
> mapped: .read(), .write(), .lock() and .is_locked(). The read and the write
> ops will be given an address offset to operate on while the locking ops use
> regions because locking always affects a whole region. It is up to the
> flash driver to implement these ops.
>
> Signed-off-by: Michael Walle
> ---
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/core.c | 5 +
> drivers/mtd/spi-nor/core.h | 54 +
> drivers/mtd/spi-nor/otp.c| 218 +++
> 4 files changed, 278 insertions(+)
> create mode 100644 drivers/mtd/spi-nor/otp.c
>
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 653923896205..2ed2e76ce4f1 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -12,6 +12,7 @@ spi-nor-objs += intel.o
> spi-nor-objs += issi.o
> spi-nor-objs += macronix.o
> spi-nor-objs += micron-st.o
> +spi-nor-objs += otp.o
spi-nor-objs:= core.o sfdp.o otp.o
This better indicates that otp is part of the "core" driver, while
the rest are manufacturer drivers (that are too part of the core).
> spi-nor-objs += spansion.o
> spi-nor-objs += sst.o
> spi-nor-objs += winbond.o
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 4a315cb1c4db..0c5c757fa95b 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3009,6 +3009,8 @@ static void spi_nor_info_init_params(struct spi_nor
> *nor)
> spi_nor_set_erase_type(>erase_type[i], info->sector_size,
>SPINOR_OP_SE);
> spi_nor_init_uniform_erase_map(map, erase_mask, params->size);
> +
> + nor->params->otp.org = >otp_org;
Init this immediately after the setup init, something like:
params->setup = spi_nor_default_setup;
params->otp.org = >otp_org;
> }
>
> /**
> @@ -3550,6 +3552,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> if (ret)
> return ret;
>
> + /* Configure OTP parameters and ops */
> + spi_nor_otp_init(nor);
Please move this as the last init thing in spi_nor_scan, immediately after
spi_nor_init(nor);
MTD OTP ops are not used accross spi_nor_scan(), there's no need to init
these earlier.
> +
> /* Send all the required SPI flash commands to initialize device */
> ret = spi_nor_init(nor);
> if (ret)
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 4a3f7f150b5d..ec8da1243846 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -187,6 +187,45 @@ struct spi_nor_locking_ops {
> int (*is_locked)(struct spi_nor *nor, loff_t ofs, uint64_t len);
> };
>
> +/**
> + * struct spi_nor_otp_organization - Structure to describe the SPI NOR OTP
> regions
> + * @len: size of one OTP region in bytes.
> + * @base: start address of the OTP area.
> + * @offset:offset between consecutive OTP regions if there are more
> + * than one.
> + * @n_regions: number of individual OTP regions.
> + */
> +struct spi_nor_otp_organization {
> + size_t len;
> + loff_t base;
> + loff_t
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/6/21 1:19 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2021-03-06 10:50, schrieb Tudor Ambarus:
>> It makes the core file a bit smaller and provides better separation
>> between the Software Write Protection features and the core logic.
>> All the next generic software write protection features (e.g.
>> Individual
>> Block Protection) will reside in swp.c.
>>
>> Signed-off-by: Tudor Ambarus
>> ---
>
> [..]
>
>> @@ -3554,6 +3152,9 @@ int spi_nor_scan(struct spi_nor *nor, const char
>> *name,
>> if (ret)
>> return ret;
>>
>> + if (nor->params->locking_ops)
>
> Should this be in spi_nor_register_locking_ops(), too? I.e.
>
> void spi_nor_register_locking_ops() {
> if (!nor->params->locking_ops)
> return;
> ..
> }
Yes, the checking should be done inside spi_nor_register_locking_ops,
will move it.
Btw, what do you find a better name, spi_nor_register_locking_ops or
spi_nor_init_locking_ops? Applies to OTP as well.
Thanks,
ta
>
> I don't have a strong opinion on that so far. I just noticed because
> I put the check into spi_nor_otp_init() for my OTP series. They should
> be the same though.
>
>> + spi_nor_register_locking_ops(nor);
>
> -michael
Re: [RFC PATCH 0/6] spi: Add OSPI PHY calibration support for spi-cadence-quadspi
On 3/12/21 3:32 PM, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Am 2021-03-11 20:12, schrieb Pratyush Yadav: >> The main problem here is telling the controller where to find the >> pattern and how to read it. This RFC uses nvmem cells which point to a >> fixed partition containing the data to do the reads. It depends on [0] >> and [1]. >> >> The obvious problem with this is it won't work when the partitions are >> defined via command line. I don't see any good way to add nvmem cells >> to >> command line partitions. I would like some help or ideas here. We don't >> necessarily have to use nvmem either. Any way that can cleanly and >> consistently let the controller find out where the pattern is stored is >> good. > > The NXP LS1028A SoC has a similar calibration (although there its done > in hardware it seems) and there the datasheet mentions there are flash > devices which supports a preamble before a read function. The preamble > is then some kind of learning pattern. Did you see a flash which > actually > supports that in the wild? I can't find any publicly available MX66LM1G45G is an example. > datasheets> of 8bit I/O SPI NOR flashes
Re: [RFC PATCH 0/6] spi: Add OSPI PHY calibration support for spi-cadence-quadspi
On 3/12/21 12:10 PM, Pratyush Yadav wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 12/03/21 09:09AM, tudor.amba...@microchip.com wrote: >> On 3/11/21 9:12 PM, Pratyush Yadav wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >>> content is safe >>> >>> Hi, >>> >>> This series adds support for OSPI PHY calibration on the Cadence OSPI >>> controller. This calibration procedure is needed to allow high clock >>> speeds in 8D-8D-8D mode. The procedure reads some pre-determined pattern >>> data from the flash and runs a sequence of test reads to find out the >>> optimal delays for high speed transfer. More details on the calibration >>> procedure in patch 5/6. >> >> Can the calibration sequence be avoided if the controller is informed >> about the frequency on which the flash operates? s/frequency/maximum supported frequency by the flash > > Maybe I don't understand this correctly, but there should not be any > frequency on which the flash operates. The controller drives the SPI > clock so the frequency is decided by the controller. Sure, there is a > max supported frequency for the flash but the controller can run it > slower than that if it wishes. The flash has no say in that. > > Anyway, the exact frequency at which the flash is running is not it is > looking for. More details below. I thought about choosing at the controller side: min(max_frequency_controller, max_frequency_flash) And there is also the need of changing the frequency on which an op runs, like the READ SFDP cmd, for which it is recommended to be run at 50 MHz, but maybe this is another topic, let's see. > >> >> Can you add more details about the optimal delays? Are we talking about >> flash's AC characteristics? Is the calibration still needed if the upper >> layer informs the QSPI controller about the needed delays? > > There is usually a delay from when the flash drives the data line (IOW, > puts a data bit on it) and when the signal reaches the controller. This > delay can vary by the flash, board, silicon characteristics, > temperature, etc. I wonder whether the delay advertised by the flash matters the most, while all the other are negligible. When I talk about delay, I'm thinking for example at the delay required between two consecutive transfers without removing the chip select, or about the minimum delay needed between the activation or the deactivation of the chip select. These are all described by the flash. Does your controller have such fields in its registers, to set such delays? If yes, is the calibration sequence still needed if all the delays are set correctly? When I hear about "board delays", I think about the impedance of the lines, which should correspond to the impedance of the Flash's IOs (which depends on the frequency on which the flash runs). A mechanism to choose the best frequency and impedance level can be added. Flashes have an interval of temperature on which they are guaranteed to work (I would expect in the same conditions). Information about temperature ranges and associated delays (if measured?) can be passed too. Cheers, ta > > At lower speeds (25 MHz for example) this delay is not a problem because > the clock period is longer so there is much more time to sample the data > line. It is very likely the controller will sample at a time when the > data line is valid. At high speeds (166 MHz for example), especially in > DDR mode, this delay starts to play a larger role because the time to > sample the data line is much smaller. Now unless the delay is accounted > for, it is possible that the controller samples the data line too late > or too early and sees invalid data. > > These delays depend on physical characteristics so it is not possible > for any upper layer to inform the controller about it. How will they > even know what the required delay is? > > In summary, no, there is no way an upper layer can inform the controller > about this delay. > >> >> Cheers, >> ta >> >>> >>> The main problem here is telling the controller where to find the >>> pattern and how to read it. This RFC uses nvmem cells which point to a >>> fixed partition containing the data to do the reads. It depends on [0] >>> and [1]. >>> >>> The obvious problem with this is it won't work when the partitions are >>> defined via command line. I don't see any good way to add nvmem cells to >>> command line partitions. I would like some help or ideas here. We don't >>> necessarily have to use nvmem either. Any way that can cleanly and >>> consistently let the controller find out where the pattern is stored is >>> good. >>> >>> The dts patch depends on [2]. >>> >>> Tested on TI's J721E EVM. >>> >>> [0] >>> https://patchwork.ozlabs.org/project/linux-mtd/patch/20210302190012.1255-1-zaj...@gmail.com/ >>> [1] >>> https://patchwork.ozlabs.org/project/linux-mtd/patch/20210308011853.19360-1-ansuels...@gmail.com/ >>> [2] >>>
Re: [RFC PATCH 4/6] spi: cadence-qspi: Use PHY for DAC reads if possible
On 3/11/21 9:12 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Check if a read is eligible for PHY and if it is, enable PHY and DQS.
DQS as in data strobe? Shouldn't the upper layer inform the QSPI controller
whether DS is required or not?
>
> Since PHY reads only work at an address that is 16-byte aligned and of
> size that is a multiple of 16 bytes, read the starting and ending
> unaligned portions without PHY, and only enable PHY for the middle part.
>
> Signed-off-by: Pratyush Yadav
> ---
> drivers/spi/spi-cadence-quadspi.c | 203 ++
> 1 file changed, 182 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/spi/spi-cadence-quadspi.c
> b/drivers/spi/spi-cadence-quadspi.c
> index e2d6ea833423..e64d8e125263 100644
> --- a/drivers/spi/spi-cadence-quadspi.c
> +++ b/drivers/spi/spi-cadence-quadspi.c
> @@ -41,19 +41,27 @@
>
> struct cqspi_st;
>
> +struct phy_setting {
> + u8 rx;
> + u8 tx;
> + u8 read_delay;
> +};
> +
> struct cqspi_flash_pdata {
> - struct cqspi_st *cqspi;
> - u32 clk_rate;
> - u32 read_delay;
> - u32 tshsl_ns;
> - u32 tsd2d_ns;
> - u32 tchsh_ns;
> - u32 tslch_ns;
> - u8 inst_width;
> - u8 addr_width;
> - u8 data_width;
> - booldtr;
> - u8 cs;
> + struct cqspi_st *cqspi;
> + u32 clk_rate;
> + u32 read_delay;
> + u32 tshsl_ns;
> + u32 tsd2d_ns;
> + u32 tchsh_ns;
> + u32 tslch_ns;
> + u8 inst_width;
> + u8 addr_width;
> + u8 data_width;
> + booldtr;
> + u8 cs;
> + booluse_phy;
> + struct phy_setting phy_setting;
> };
>
> struct cqspi_st {
> @@ -108,12 +116,14 @@ struct cqspi_driver_platdata {
> /* Register map */
> #define CQSPI_REG_CONFIG 0x00
> #define CQSPI_REG_CONFIG_ENABLE_MASK BIT(0)
> +#define CQSPI_REG_CONFIG_PHY_ENBIT(3)
> #define CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL BIT(7)
> #define CQSPI_REG_CONFIG_DECODE_MASK BIT(9)
> #define CQSPI_REG_CONFIG_CHIPSELECT_LSB10
> #define CQSPI_REG_CONFIG_DMA_MASK BIT(15)
> #define CQSPI_REG_CONFIG_BAUD_LSB 19
> #define CQSPI_REG_CONFIG_DTR_PROTO BIT(24)
> +#define CQSPI_REG_CONFIG_PHY_PIPELINE BIT(25)
> #define CQSPI_REG_CONFIG_DUAL_OPCODE BIT(30)
> #define CQSPI_REG_CONFIG_IDLE_LSB 31
> #define CQSPI_REG_CONFIG_CHIPSELECT_MASK 0xF
> @@ -150,6 +160,7 @@ struct cqspi_driver_platdata {
> #define CQSPI_REG_READCAPTURE_BYPASS_LSB 0
> #define CQSPI_REG_READCAPTURE_DELAY_LSB1
> #define CQSPI_REG_READCAPTURE_DELAY_MASK 0xF
> +#define CQSPI_REG_READCAPTURE_DQS_LSB 8
>
> #define CQSPI_REG_SIZE 0x14
> #define CQSPI_REG_SIZE_ADDRESS_LSB 0
> @@ -999,6 +1010,7 @@ static void cqspi_config_baudrate_div(struct cqspi_st
> *cqspi)
>
> static void cqspi_readdata_capture(struct cqspi_st *cqspi,
>const bool bypass,
> + const bool dqs,
>const unsigned int delay)
> {
> void __iomem *reg_base = cqspi->iobase;
> @@ -1017,6 +1029,11 @@ static void cqspi_readdata_capture(struct cqspi_st
> *cqspi,
> reg |= (delay & CQSPI_REG_READCAPTURE_DELAY_MASK)
> << CQSPI_REG_READCAPTURE_DELAY_LSB;
>
> + if (dqs)
> + reg |= (1 << CQSPI_REG_READCAPTURE_DQS_LSB);
> + else
> + reg &= ~(1 << CQSPI_REG_READCAPTURE_DQS_LSB);
> +
> writel(reg, reg_base + CQSPI_REG_READCAPTURE);
> }
>
> @@ -1035,6 +1052,64 @@ static void cqspi_controller_enable(struct cqspi_st
> *cqspi, bool enable)
> writel(reg, reg_base + CQSPI_REG_CONFIG);
> }
>
> +static void cqspi_phy_enable(struct cqspi_flash_pdata *f_pdata, bool enable)
> +{
> + struct cqspi_st *cqspi = f_pdata->cqspi;
> + void __iomem *reg_base = cqspi->iobase;
> + u32 reg;
> + u8 dummy;
> +
> + if (enable) {
> + cqspi_readdata_capture(cqspi, 1, true,
> + f_pdata->phy_setting.read_delay);
> +
> + reg = readl(reg_base + CQSPI_REG_CONFIG);
> + reg |= CQSPI_REG_CONFIG_PHY_EN |
> + CQSPI_REG_CONFIG_PHY_PIPELINE;
> + writel(reg, reg_base +
Re: [RFC PATCH 0/6] spi: Add OSPI PHY calibration support for spi-cadence-quadspi
On 3/11/21 9:12 PM, Pratyush Yadav wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Hi, > > This series adds support for OSPI PHY calibration on the Cadence OSPI > controller. This calibration procedure is needed to allow high clock > speeds in 8D-8D-8D mode. The procedure reads some pre-determined pattern > data from the flash and runs a sequence of test reads to find out the > optimal delays for high speed transfer. More details on the calibration > procedure in patch 5/6. Can the calibration sequence be avoided if the controller is informed about the frequency on which the flash operates? Can you add more details about the optimal delays? Are we talking about flash's AC characteristics? Is the calibration still needed if the upper layer informs the QSPI controller about the needed delays? Cheers, ta > > The main problem here is telling the controller where to find the > pattern and how to read it. This RFC uses nvmem cells which point to a > fixed partition containing the data to do the reads. It depends on [0] > and [1]. > > The obvious problem with this is it won't work when the partitions are > defined via command line. I don't see any good way to add nvmem cells to > command line partitions. I would like some help or ideas here. We don't > necessarily have to use nvmem either. Any way that can cleanly and > consistently let the controller find out where the pattern is stored is > good. > > The dts patch depends on [2]. > > Tested on TI's J721E EVM. > > [0] > https://patchwork.ozlabs.org/project/linux-mtd/patch/20210302190012.1255-1-zaj...@gmail.com/ > [1] > https://patchwork.ozlabs.org/project/linux-mtd/patch/20210308011853.19360-1-ansuels...@gmail.com/ > [2] > https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210305153926.3479-2-p.ya...@ti.com/ > > Pratyush Yadav (6): > spi: spi-mem: Tell controller when device is ready for calibration > mtd: spi-nor: core: consolidate read op creation > mtd: spi-nor: core: run calibration when initialization is done > spi: cadence-qspi: Use PHY for DAC reads if possible > spi: cadence-qspi: Tune PHY to allow running at higher frequencies > arm64: dts: ti: k3-j721e-som-p0: Enable PHY calibration > > arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi | 55 ++ > drivers/mtd/spi-nor/core.c | 74 +- > drivers/spi/spi-cadence-quadspi.c | 820 +++- > drivers/spi/spi-mem.c | 12 + > include/linux/spi/spi-mem.h | 8 + > 5 files changed, 916 insertions(+), 53 deletions(-) > > -- > 2.30.0 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
Re: [PATCH v2] ARM: dts: at91: sam9x60: fix mux-mask to match product's datasheet
On 3/10/21 5:20 PM, nicolas.fe...@microchip.com wrote:
> From: Nicolas Ferre
>
> Fix the whole mux-mask table according to datasheet for the sam9x60
> product. Too much functions for pins were disabled leading to
> misunderstandings when enabling more peripherals or taking this table
> as an example for another board.
> Take advantage of this fix to move the mux-mask in the SoC file where it
> belongs and use lower case letters for hex numbers like everywhere in
> the file.
>
> Signed-off-by: Nicolas Ferre
> Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and
> board")
> Cc: # 5.6+
> Cc: Sandeep Sheriker Mallikarjun
I went through all the pins described in DS60001579D, and I obtained
the same mux-mask values:
Reviewed-by: Tudor Ambarus
> ---
> v1 -> v2:
> - move to SoC dtsi file: it applies to all boards using the sam9x60 SoC
> version
> - use lower case for hex numbers instead of mixed nonsense
>
> arch/arm/boot/dts/at91-sam9x60ek.dts | 8
> arch/arm/boot/dts/sam9x60.dtsi | 9 +
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/at91-sam9x60ek.dts
> b/arch/arm/boot/dts/at91-sam9x60ek.dts
> index 4c40ae571154..775ceb3acb6c 100644
> --- a/arch/arm/boot/dts/at91-sam9x60ek.dts
> +++ b/arch/arm/boot/dts/at91-sam9x60ek.dts
> @@ -334,14 +334,6 @@ ethernet-phy@0 {
> };
>
> {
> - atmel,mux-mask = <
> - /* A B C */
> - 0xFEFF 0xC0E039FF 0xEF00019D /* pioA */
> - 0x03FF 0x02FC7E68 0x0078 /* pioB */
> - 0x 0xF83F 0xB800F3FC /* pioC */
> - 0x003F 0x003F8000 0x /* pioD */
> - >;
> -
> adc {
> pinctrl_adc_default: adc_default {
> atmel,pins = AT91_PINCTRL_NONE>;
> diff --git a/arch/arm/boot/dts/sam9x60.dtsi b/arch/arm/boot/dts/sam9x60.dtsi
> index 84066c1298df..ec45ced3cde6 100644
> --- a/arch/arm/boot/dts/sam9x60.dtsi
> +++ b/arch/arm/boot/dts/sam9x60.dtsi
> @@ -606,6 +606,15 @@ pinctrl: pinctrl@f400 {
> compatible = "microchip,sam9x60-pinctrl",
> "atmel,at91sam9x5-pinctrl", "atmel,at91rm9200-pinctrl", "simple-bus";
> ranges = <0xf400 0xf400 0x800>;
>
> + /* mux-mask corresponding to sam9x60 SoC in
> TFBGA228L package */
> + atmel,mux-mask = <
> + /* A B C
> */
> + 0x 0xffe03fff
> 0xef00019d /* pioA */
> + 0x03ff 0x02fc7e7f
> 0x0078 /* pioB */
> + 0x 0x
> 0xf83f /* pioC */
> + 0x003f 0x003f8000
> 0x /* pioD */
> + >;
> +
> pioA: gpio@f400 {
> compatible = "microchip,sam9x60-gpio",
> "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
> reg = <0xf400 0x200>;
>
Re: [PATCH 1/4] dt-bindings: at25: add Fujitsu MB85RS4MT
On 3/10/21 12:59 AM, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Hi Tim, > > Am 2021-03-09 23:00, schrieb Tim Harvey: >> Document the compatible value for the Fujitsu MB85RS4MT SPI >> FRAM EEPROM device so that it can be used in DTS files. >> >> This is a 512KiB FRAM EEPROM. >> >> Signed-off-by: Tim Harvey >> --- >> Documentation/devicetree/bindings/eeprom/at25.yaml | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml >> b/Documentation/devicetree/bindings/eeprom/at25.yaml >> index 6a2dc8b3ed14..f594db72b711 100644 >> --- a/Documentation/devicetree/bindings/eeprom/at25.yaml >> +++ b/Documentation/devicetree/bindings/eeprom/at25.yaml >> @@ -26,6 +26,7 @@ properties: >> - anvo,anv32e61w >> - atmel,at25256B >> - fujitsu,mb85rs1mt >> + - fujitsu,mb85rs4mt >> - fujitsu,mb85rs64 >> - microchip,at25160bn >> - microchip,25lc040 > > Hm, the driver is spi-nor but this is for the at25 driver. Is > this correct? Doesn't it work if you just add the ID to > spi-nor/fujitsu.c and use 'compatible = "jedec,spi-nor' ? > Tim, Can you try and see if you can work with this flash by setting "atmel,at25" compatible? There are some SPI NOR-like flashes MRAMs, FRAMs, even EEPROMs, that share a part of opcodes of SPI NORs, but have slightly different characteristics (ex. no erase, no wait times for writes on FRAMs). See the patch series submitted by Richard, that I have stalled: https://patchwork.ozlabs.org/project/linux-mtd/list/?series=208584=* I now have time to allocate for this, I'll study all and come up with a proposal in one or two weeks. Cheers, ta
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 3/6/21 3:20 PM, Tudor Ambarus wrote: >> It makes the core file a bit smaller and provides better separation >> between the Software Write Protection features and the core logic. >> All the next generic software write protection features (e.g. Individual >> Block Protection) will reside in swp.c. >> >> Signed-off-by: Tudor Ambarus >> --- >> drivers/mtd/spi-nor/Makefile | 2 +- >> drivers/mtd/spi-nor/core.c | 407 +- >> drivers/mtd/spi-nor/core.h | 4 + >> drivers/mtd/spi-nor/swp.c| 419 +++ > > Hmmm, name swp.c does not seem intuitive to me. How about expanding it a > bit: > > soft-wr-protect.c or software-write-protect.c ? > I thought about the SWP configs that we have. How about keeping swp.c and rename configs to: s/MTD_SPI_NOR_SWP_DISABLE/MTD_SPI_NOR_DISABLE_BOOT_SWP s/MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE/MTD_SPI_DISABLE_BOOT_SWP_ON_VOLATILE s/MTD_SPI_NOR_SWP_KEEP/MTD_SPI_NOR_KEEP_BOOT_SWP The renamed configs should better indicate that the software write protection is disabled just at boot time, while the locking support is still enabled. Otherwise one may think that with a MTD_SPI_NOR_SWP_DISABLE, all the software write protection features are stripped/not available. Cheers, ta
Re: [PATCH] mtd: spi-nor: gigadevice: Add support for gd25lb256e
On 2/9/21 1:11 PM, Md Sadre Alam wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Add support for gd25lb256e. This device tested on IPQ5018
> platform with dd from/to the flash for read/write respectly,
typo: respectly
> and mtd erase for erasing the flash.
>
> Signed-off-by: Md Sadre Alam
> ---
> drivers/mtd/spi-nor/gigadevice.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/gigadevice.c
> b/drivers/mtd/spi-nor/gigadevice.c
> index 447d84b..8f1e7ec 100644
> --- a/drivers/mtd/spi-nor/gigadevice.c
> +++ b/drivers/mtd/spi-nor/gigadevice.c
> @@ -50,6 +50,9 @@ static const struct flash_info gigadevice_parts[] = {
>SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK |
>SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6)
> .fixups = _fixups },
> + { "gd25lb256e", INFO(0xc86719, 0, 64 * 1024, 512,
> + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> + SPI_NOR_4B_OPCODES) },
The flash doesn't have support for 0x3b command, you can't add the
SPI_NOR_DUAL_READ flag.
I see that the flash name contains info about the generation of the flash.
Is the generation differentiated by a different device ID? If not, we can
strip the "e" from the flash name.
Looks like the flash has support for BP0-3 protection. You can try
to add the flash locking flags and test the support with mtd-utils,
if you're interested in this kind of support.
Cheers,
ta
> };
>
> const struct spi_nor_manufacturer spi_nor_gigadevice = {
> --
> 2.7.4
>
Re: [PATCH] mtd: spi-nor: sfdp: Fix out of bound array access
On 2/19/21 9:50 AM, Mathieu Dubois-Briand wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Hi, > > I just came across this commit (9166f4af32db) in spi-nor/for-5.12: > https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/commit/?h=spi-nor/for-5.12=9166f4af32db74e1544a2149aef231ff24515ea3. > > So I believe this patch isn't needed anymore. > That's true. Thanks, ta
Re: [PATCH v3 1/2] mtd: spi-nor: add OTP support
Hi, Michael,
On 2/16/21 6:28 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> SPI flashes sometimes have a special OTP area, which can (and is) used to
> store immutable properties like board serial number or vendor assigned
> network hardware addresses.
>
> The MTD subsystem already supports accessing such areas and some (non
> SPI-NOR) flashes already implement support for it. It differentiates
> between user and factory areas. User areas can be written by the user and
> factory ones are pre-programmed and locked down by the vendor, usually
> containing an "electrical serial number". This patch will only add support
> for the user areas.
>
> Lay the foundation and implement the MTD callbacks for the SPI-NOR and add
> necessary parameters to the flash_info structure. If a flash supports OTP
> it can be added by the convenience macro OTP_INFO(). Sometimes there are
> individual regions, which might have individual offsets. Therefore, it is
> possible to specify the starting address of the first regions as well as
> the distance between two regions (e.g. Winbond devices uses this method).
>
> Additionally, the regions might be locked down. Once locked, no further
> write access is possible.
>
> For SPI-NOR flashes the OTP area is accessed like the normal memory, e.g.
> by offset addressing; except that you either have to use special read/write
> commands (Winbond) or you have to enter (and exit) a specific OTP mode
> (Macronix, Micron).
>
> Thus we introduce four operations to which the MTD callbacks will be
> mapped: .read(), .write(), .lock() and .is_locked(). The read and the write
> ops will be given an address offset to operate on while the locking ops use
> regions because locking always affects a whole region. It is up to the
> flash driver to implement these ops.
>
SPI NORs can support some OTP-like behaviour, meaning that in addition to
the tipical OTP ops (read, write, lock), the SPI NORs can also erase the
OTP-like memory before the permanent lock. I find the erase useful, in
case one writes something wrong from the start, in case of errors where
what was written differs from what is read back, or simply at development
stage, to check the implementation. So I think we should add support for
that too. If not now, maybe later.
Michael, the overall implementation looks good, and I think we can have
a version of it merged in the following merge window. Some suggestions
and comments below.
cut
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 0522304f52fa..af9d7f194f01 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
cut
> @@ -3502,6 +3508,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> mtd->_is_locked = spi_nor_is_locked;
> }
>
> + spi_nor_otp_init(nor);
since this returns void, we can do it the last thing in the spi_nor_scan(), so
that we don't gratuitously init fields in case of errors.
> +
> if (info->flags & USE_FSR)
> nor->flags |= SNOR_F_USE_FSR;
> if (info->flags & SPI_NOR_HAS_TB) {
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 4a3f7f150b5d..5fb54ae08c5b 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -175,6 +175,21 @@ struct spi_nor_erase_map {
> u8 uniform_erase_type;
> };
>
> +/**
> + * struct spi_nor_otp_info - Structure to describe the SPI NOR OTP region
> + * @otp_size: size of one OTP region in bytes.
> + * @n_otps:number of individual OTP regions.
> + * @otp_start_addr:start address of the OTP area.
> + * @otp_addr_offset: offset between consecutive OTP regions if there are
> + * more than one.
> + */
> +struct spi_nor_otp_info {
> + u32 otp_size;
> + int n_otps;
> + u32 otp_start_addr;
> + u32 otp_addr_offset;
> +};
How about the following:
struct spi_nor_otp_memory_organization {
loff_t base;
loff_t offset;
size_t len;
unsigned int n_regions;
};
> +
> /**
> * struct spi_nor_locking_ops - SPI NOR locking methods
> * @lock: lock a region of the SPI NOR.
> @@ -187,6 +202,20 @@ struct spi_nor_locking_ops {
> int (*is_locked)(struct spi_nor *nor, loff_t ofs, uint64_t len);
> };
>
> +/**
> + * struct spi_nor_otp_ops - SPI NOR OTP methods
> + * @read: read from the SPI NOR OTP area.
> + * @write: write to the SPI NOR OTP area.
> + * @lock: lock an OTP region.
> + * @is_locked: check if an OTP region of the SPI NOR is locked.
> + */
> +struct spi_nor_otp_ops {
> + int (*read)(struct spi_nor *nor, loff_t ofs, uint64_t len, u8 *buf);
int (*read)(struct spi_nor *nor, loff_t offset, size_t len, u8 *buf);
> + int (*write)(struct spi_nor *nor, loff_t ofs, uint64_t len, u8 *buf);
same here
> + int (*lock)(struct
Re: [PATCH v9 3/7] crypto: move curve_id of ECDH from the key to algorithm name
On 2/24/21 3:29 AM, yumeng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> 在 2021/2/23 18:44, tudor.amba...@microchip.com 写道:
>> Hi,
>>
>> On 2/23/21 9:10 AM, Meng Yu wrote:
>>> --- a/drivers/crypto/atmel-ecc.c
>>> +++ b/drivers/crypto/atmel-ecc.c
>>> @@ -104,7 +104,7 @@ static int atmel_ecdh_set_secret(struct crypto_kpp
>>> *tfm, const void *buf,
>>> return -EINVAL;
>>> }
>>>
>>> - ctx->n_sz = atmel_ecdh_supported_curve(params.curve_id);
>>> + ctx->n_sz = atmel_ecdh_supported_curve(ctx->curve_id);
>>> if (!ctx->n_sz || params.key_size) {
>>> /* fallback to ecdh software implementation */
>>> ctx->do_fallback = true;
>>
>> Now that you moved the curve id info into the alg name, and it is
>> no longer dynamically discovered when decoding the key, does it
>> still make sense to keep the curve id, the key size checks, and
>> the fallback to the software implementation?
>> I think we can keep the curve id, the key size check if 'atmel-ecc' may
> support other curves in the future, and if you're sure P256 is the only
> curve 'atmel-ecc' uses, and it will be changed, we can delete it.
>
> And fallback to ecdh software implementation is needed when
> params.key_size is zero.
>
I've read the code again, now I remember. The fallback is needed indeed,
but for other reason. ecdh-nist-p256 will be handled in the crypto IP
only when its user provides a zero length private key: we will use a
pre-provisioned private key that can't be read outside of the device.
The fallback was needed for ecdh-nist-p256 when the user provides a
non-zero private key, or for other curve IDs.
Since the atecc508 and atecc608 (for which there isn't support in kernel
as of now) both support just NIST Standard P256 Elliptic Curve, and the
curve id is now unique per alg, the ctx->curve_id handling does no longer
make sense. So please remove the ctx->curve_id handling. ctx->n_sz can be
removed too and use instead directly ATMEL_ECC_NIST_P256_N_SIZE, similar
to how ATMEL_ECC_PUBKEY_SIZE is used.
Re: [PATCH v9 3/7] crypto: move curve_id of ECDH from the key to algorithm name
Hi,
On 2/23/21 9:10 AM, Meng Yu wrote:
> --- a/drivers/crypto/atmel-ecc.c
> +++ b/drivers/crypto/atmel-ecc.c
> @@ -104,7 +104,7 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm,
> const void *buf,
> return -EINVAL;
> }
>
> - ctx->n_sz = atmel_ecdh_supported_curve(params.curve_id);
> + ctx->n_sz = atmel_ecdh_supported_curve(ctx->curve_id);
> if (!ctx->n_sz || params.key_size) {
> /* fallback to ecdh software implementation */
> ctx->do_fallback = true;
Now that you moved the curve id info into the alg name, and it is
no longer dynamically discovered when decoding the key, does it
still make sense to keep the curve id, the key size checks, and
the fallback to the software implementation?
I don't have an atecc508 at hand to test the changes, but I expect
your changes won't affect the functionality.
ta
Re: [PATCH] mtd: spi-nor: gigadevice: Add support for gd25lb256e
Hi,
On 2/16/21 5:10 PM, mda...@codeaurora.org wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 2021-02-09 16:41, Md Sadre Alam wrote:
>> Add support for gd25lb256e. This device tested on IPQ5018
>> platform with dd from/to the flash for read/write respectly,
>> and mtd erase for erasing the flash.
>>
>> Signed-off-by: Md Sadre Alam
>> ---
>> drivers/mtd/spi-nor/gigadevice.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/gigadevice.c
>> b/drivers/mtd/spi-nor/gigadevice.c
>> index 447d84b..8f1e7ec 100644
>> --- a/drivers/mtd/spi-nor/gigadevice.c
>> +++ b/drivers/mtd/spi-nor/gigadevice.c
>> @@ -50,6 +50,9 @@ static const struct flash_info gigadevice_parts[] = {
>> SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK |
>> SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6)
>> .fixups = _fixups },
>> + { "gd25lb256e", INFO(0xc86719, 0, 64 * 1024, 512,
>> + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
>> + SPI_NOR_4B_OPCODES) },
>> };
>>
>> const struct spi_nor_manufacturer spi_nor_gigadevice = {
>
> ping! Is there any additional info needed for this ?
No other info needed, just time to review it. Please stop sending
free pings, every patch will be reviewed.
Cheers,
ta
Re: [PATCH v4 0/8] Make fw_devlink=on more forgiving
On 2/10/21 10:54 AM, Saravana Kannan wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Wed, Feb 10, 2021 at 12:19 AM wrote:
>>
>> Hi, Saravana,
>>
>> On 2/6/21 12:26 AM, Saravana Kannan wrote:
>>> There are a lot of devices/drivers where they never have a struct device
>>> created for them or the driver initializes the hardware without ever
>>> binding to the struct device.
>>>
>>> This series is intended to avoid any boot regressions due to such
>>> devices/drivers when fw_devlink=on and also address the handling of
>>> optional suppliers.
>>>
>>> Patch 1 and 2 addresses the issue of firmware nodes that look like
>>> they'll have struct devices created for them, but will never actually
>>> have struct devices added for them. For example, DT nodes with a
>>> compatible property that don't have devices added for them.
>>>
>>> Patch 3 and 4 allow for handling optional DT bindings.
>>>
>>> Patch 5 sets up a generic API to handle drivers that never bind with
>>> their devices.
>>>
>>> Patch 6 through 8 update different frameworks to use the new API.
>>>
>>> Thanks,
>>> Saravana
>>>
>>> Saravana Kannan (8):
>>> driver core: fw_devlink: Detect supplier devices that will never be
>>> added
>>> of: property: Don't add links to absent suppliers
>>> driver core: Add fw_devlink.strict kernel param
>>> of: property: Add fw_devlink support for optional properties
>>> driver core: fw_devlink: Handle suppliers that don't use driver core
>>> irqdomain: Mark fwnodes when their irqdomain is added/removed
>>> PM: domains: Mark fwnodes when their powerdomain is added/removed
>>> clk: Mark fwnodes when their clock provider is added/removed
>>>
>>> .../admin-guide/kernel-parameters.txt | 5 ++
>>> drivers/base/core.c | 58 ++-
>>> drivers/base/power/domain.c | 2 +
>>> drivers/clk/clk.c | 3 +
>>> drivers/of/property.c | 16 +++--
>>> include/linux/fwnode.h| 20 ++-
>>> kernel/irq/irqdomain.c| 2 +
>>> 7 files changed, 98 insertions(+), 8 deletions(-)
>>>
>>
>> Even with this patch set applied, sama5d2_xplained can not boot.
>> Patch at [1] makes sama5d2_xplained boot again. Stephen applied it
>> to clk-next.
>
> I'm glad you won't actually have any boot issues in 5.12, but the fact
> you need [1] with this series doesn't make a lot of sense to me
> because:
>
> 1. The FWNODE_FLAG_INITIALIZED flag will be set for the clock fwnode
> in question way before any consumer devices are added.
Looks like in my case FWNODE_FLAG_INITIALIZED is not set, because
drivers/clk/at91/sama5d2.c uses of_clk_add_hw_provider().
> 2. Any consumer device added after (1) will stop trying to link to the
> clock device.
>
> Are you somehow adding a consumer to the clock fwnode before (1)?
>
> Can you try this patch without your clk fix? I was trying to avoid
> looping through a list, but looks like your case might somehow need
> it?
>
I tried it, didn't solve my boot problem. The following patch makes the
sama5d2_xplained boot again, even without the patch from [1]:
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 27ff90eacb1f..9370e4dfecae 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -4594,6 +4594,8 @@ int of_clk_add_hw_provider(struct device_node *np,
if (ret < 0)
of_clk_del_provider(np);
+ fwnode_dev_initialized(>fwnode, true);
+
return ret;
}
EXPORT_SYMBOL_GPL(of_clk_add_hw_provider);
Cheers,
ta
> -Saravana
>
> +++ b/drivers/base/core.c
> @@ -943,6 +943,31 @@ static void device_links_missing_supplier(struct
> device *dev)
> }
> }
>
> +static int fw_devlink_check_suppliers(struct device *dev)
> +{
> + struct fwnode_link *link;
> + int ret = 0;
> +
> + if (!dev->fwnode ||fw_devlink_is_permissive())
> + return 0;
> +
> + /*
> +* Device waiting for supplier to become available is not allowed to
> +* probe.
> +*/
> + mutex_lock(_link_lock);
> + list_for_each_entry(link, >fwnode->suppliers, c_hook) {
> + if (link->supplier->flags & FWNODE_FLAG_INITIALIZED)
> + continue;
> +
> + ret = -EPROBE_DEFER;
> + break;
> + }
> + mutex_unlock(_link_lock);
> +
> + return ret;
> +}
> +
> /**
> * device_links_check_suppliers - Check presence of supplier drivers.
> * @dev: Consumer device.
> @@ -964,21 +989,13 @@ int device_links_check_suppliers(struct device *dev)
> struct device_link *link;
> int ret = 0;
>
> - /*
> -* Device waiting for supplier to become available is not allowed to
> -* probe.
> -*/
> - mutex_lock(_link_lock);
> - if (dev->fwnode && !list_empty(>fwnode->suppliers) &&
> -
Re: [PATCH v4 0/8] Make fw_devlink=on more forgiving
Hi, Saravana, On 2/6/21 12:26 AM, Saravana Kannan wrote: > There are a lot of devices/drivers where they never have a struct device > created for them or the driver initializes the hardware without ever > binding to the struct device. > > This series is intended to avoid any boot regressions due to such > devices/drivers when fw_devlink=on and also address the handling of > optional suppliers. > > Patch 1 and 2 addresses the issue of firmware nodes that look like > they'll have struct devices created for them, but will never actually > have struct devices added for them. For example, DT nodes with a > compatible property that don't have devices added for them. > > Patch 3 and 4 allow for handling optional DT bindings. > > Patch 5 sets up a generic API to handle drivers that never bind with > their devices. > > Patch 6 through 8 update different frameworks to use the new API. > > Thanks, > Saravana > > Saravana Kannan (8): > driver core: fw_devlink: Detect supplier devices that will never be > added > of: property: Don't add links to absent suppliers > driver core: Add fw_devlink.strict kernel param > of: property: Add fw_devlink support for optional properties > driver core: fw_devlink: Handle suppliers that don't use driver core > irqdomain: Mark fwnodes when their irqdomain is added/removed > PM: domains: Mark fwnodes when their powerdomain is added/removed > clk: Mark fwnodes when their clock provider is added/removed > > .../admin-guide/kernel-parameters.txt | 5 ++ > drivers/base/core.c | 58 ++- > drivers/base/power/domain.c | 2 + > drivers/clk/clk.c | 3 + > drivers/of/property.c | 16 +++-- > include/linux/fwnode.h| 20 ++- > kernel/irq/irqdomain.c| 2 + > 7 files changed, 98 insertions(+), 8 deletions(-) > Even with this patch set applied, sama5d2_xplained can not boot. Patch at [1] makes sama5d2_xplained boot again. Stephen applied it to clk-next. Cheers, ta [1] https://lore.kernel.org/lkml/20210203154332.470587-1-tudor.amba...@microchip.com/
Re: [PATCH] clk: at91: sama5d2: Mark device OF_POPULATED after setup
Hi, Saravana,
On 2/9/21 9:06 PM, Saravana Kannan wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Tue, Feb 9, 2021 at 7:21 AM wrote:
>>
>> Hi, Saravana,
>>
>> On 2/9/21 11:11 AM, Saravana Kannan wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>>> content is safe
>>>
>>> On Mon, Feb 8, 2021 at 11:55 PM Stephen Boyd wrote:
Quoting Saravana Kannan (2021-01-28 09:01:41)
> On Thu, Jan 28, 2021 at 2:45 AM Tudor Ambarus
> wrote:
>>
>> The sama5d2 requires the clock provider initialized before timers.
>> We can't use a platform driver for the sama5d2-pmc driver, as the
>> platform_bus_init() is called later on, after time_init().
>>
>> As fw_devlink considers only devices, it does not know that the
>> pmc is ready. Hence probing of devices that depend on it fail:
>> probe deferral - supplier f0014000.pmc not ready
>>
>> Fix this by setting the OF_POPULATED flag for the sama5d2_pmc
>> device node after successful setup. This will make
>> of_link_to_phandle() ignore the sama5d2_pmc device node as a
>> dependency, and consumer devices will be probed again.
>>
>> Fixes: e590474768f1cc04 ("driver core: Set fw_devlink=on by default")
>> Signed-off-by: Tudor Ambarus
>> ---
>> I'll be out of office, will check the rest of the at91 SoCs
>> at the begining of next week.
>>
>> drivers/clk/at91/sama5d2.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
>> index 9a5cbc7cd55a..5eea2b4a63dd 100644
>> --- a/drivers/clk/at91/sama5d2.c
>> +++ b/drivers/clk/at91/sama5d2.c
>> @@ -367,6 +367,8 @@ static void __init sama5d2_pmc_setup(struct
>> device_node *np)
>>
>> of_clk_add_hw_provider(np, of_clk_hw_pmc_get, sama5d2_pmc);
>>
>> + of_node_set_flag(np, OF_POPULATED);
>> +
>> return;
>
> Hi Tudor,
>
> Thanks for looking into this.
>
> I already accounted for early clocks like this when I designed
> fw_devlink. Each driver shouldn't need to set OF_POPULATED.
> drivers/clk/clk.c already does this for you.
>
> I think the problem is that your driver is using
> CLK_OF_DECLARE_DRIVER() instead of CLK_OF_DECLARE(). The comments for
> CLK_OF_DECLARE_DRIVER() says:
> /*
> * Use this macro when you have a driver that requires two initialization
> * routines, one at of_clk_init(), and one at platform device probe
> */
>
> In your case, you are explicitly NOT having a driver bind to this
> clock later. So you shouldn't be using CLK_OF_DECLARE() instead.
>
I see
drivers/power/reset/at91-sama5d2_shdwc.c: { .compatible =
"atmel,sama5d2-pmc" },
so isn't that the driver that wants to bind to the same device node
again? First at of_clk_init() time here and then second for the reset
driver?
>>>
>>> You are right. I assumed that when Tudor was setting OF_POPULATED,
>>
>> No, there's a single driver that binds to that compatible.
>>
>>> they didn't want to create a struct device and they knew it was right
>>> for their platform.
>>>
>>> However...
>>> $ git grep "atmel,sama5d2-pmc"
>>> arch/arm/boot/dts/sama5d2.dtsi: compatible =
>>> "atmel,sama5d2-pmc", "syscon";
>>> arch/arm/mach-at91/pm.c:{ .compatible = "atmel,sama5d2-pmc",
>>> .data = _infos[1] },
>>> drivers/clk/at91/pmc.c: { .compatible = "atmel,sama5d2-pmc" },
>>> drivers/clk/at91/sama5d2.c:CLK_OF_DECLARE_DRIVER(sama5d2_pmc,
>>> "atmel,sama5d2-pmc", sama5d2_pmc_setup);
>>> drivers/power/reset/at91-sama5d2_shdwc.c: { .compatible =
>>> "atmel,sama5d2-pmc" },
>>>
>>> Geez! How many drivers are there for this one device. Clearly not all
>>> of them are going to bind. But I'm not going to dig into this. You can
>>
>> From this entire list only the drivers/clk/at91/sama5d2.c driver binds to the
>> "atmel,sama5d2-pmc" compatible, the rest are just using the compatible to
>> map the PMC memory.
>>
>>> reject this patch. I expect this series [1] to take care of the issue
>>> Tudor was trying to fix.
>>>
>>> Tudor,
>>>
>>> Want to give this series [1] a shot?
>>
>> The series at [1] doesn't apply clean neither on next-20210209, nor on
>> driver-core-next. On top of which sha1 should I apply them?
>
> It's on top of driver-core-next:
> 4731210c09f5 gpiolib: Bind gpio_device to a driver to enable
> fw_devlink=on by default
I see Greg took your series. I tried the driver-core-next (with your series
included), it doesn't solve my boot problem on sama5d2_xplained.
With [2] applied, sama5d2_xplained can boot again.
Cheers,
ta
>
>> Anyway, I think the patch at [2] is still needed, regardless of the outcome
>> of [1].
>
> Right, [2] is still a good clean up based on your comment above.
>
Re: [PATCH] clk: at91: sama5d2: Mark device OF_POPULATED after setup
Hi, Saravana,
On 2/9/21 11:11 AM, Saravana Kannan wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Mon, Feb 8, 2021 at 11:55 PM Stephen Boyd wrote:
>>
>> Quoting Saravana Kannan (2021-01-28 09:01:41)
>>> On Thu, Jan 28, 2021 at 2:45 AM Tudor Ambarus
>>> wrote:
The sama5d2 requires the clock provider initialized before timers.
We can't use a platform driver for the sama5d2-pmc driver, as the
platform_bus_init() is called later on, after time_init().
As fw_devlink considers only devices, it does not know that the
pmc is ready. Hence probing of devices that depend on it fail:
probe deferral - supplier f0014000.pmc not ready
Fix this by setting the OF_POPULATED flag for the sama5d2_pmc
device node after successful setup. This will make
of_link_to_phandle() ignore the sama5d2_pmc device node as a
dependency, and consumer devices will be probed again.
Fixes: e590474768f1cc04 ("driver core: Set fw_devlink=on by default")
Signed-off-by: Tudor Ambarus
---
I'll be out of office, will check the rest of the at91 SoCs
at the begining of next week.
drivers/clk/at91/sama5d2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
index 9a5cbc7cd55a..5eea2b4a63dd 100644
--- a/drivers/clk/at91/sama5d2.c
+++ b/drivers/clk/at91/sama5d2.c
@@ -367,6 +367,8 @@ static void __init sama5d2_pmc_setup(struct
device_node *np)
of_clk_add_hw_provider(np, of_clk_hw_pmc_get, sama5d2_pmc);
+ of_node_set_flag(np, OF_POPULATED);
+
return;
>>>
>>> Hi Tudor,
>>>
>>> Thanks for looking into this.
>>>
>>> I already accounted for early clocks like this when I designed
>>> fw_devlink. Each driver shouldn't need to set OF_POPULATED.
>>> drivers/clk/clk.c already does this for you.
>>>
>>> I think the problem is that your driver is using
>>> CLK_OF_DECLARE_DRIVER() instead of CLK_OF_DECLARE(). The comments for
>>> CLK_OF_DECLARE_DRIVER() says:
>>> /*
>>> * Use this macro when you have a driver that requires two initialization
>>> * routines, one at of_clk_init(), and one at platform device probe
>>> */
>>>
>>> In your case, you are explicitly NOT having a driver bind to this
>>> clock later. So you shouldn't be using CLK_OF_DECLARE() instead.
>>>
>>
>> I see
>>
>> drivers/power/reset/at91-sama5d2_shdwc.c: { .compatible =
>> "atmel,sama5d2-pmc" },
>>
>> so isn't that the driver that wants to bind to the same device node
>> again? First at of_clk_init() time here and then second for the reset
>> driver?
>
> You are right. I assumed that when Tudor was setting OF_POPULATED,
No, there's a single driver that binds to that compatible.
> they didn't want to create a struct device and they knew it was right
> for their platform.
>
> However...
> $ git grep "atmel,sama5d2-pmc"
> arch/arm/boot/dts/sama5d2.dtsi: compatible =
> "atmel,sama5d2-pmc", "syscon";
> arch/arm/mach-at91/pm.c:{ .compatible = "atmel,sama5d2-pmc",
> .data = _infos[1] },
> drivers/clk/at91/pmc.c: { .compatible = "atmel,sama5d2-pmc" },
> drivers/clk/at91/sama5d2.c:CLK_OF_DECLARE_DRIVER(sama5d2_pmc,
> "atmel,sama5d2-pmc", sama5d2_pmc_setup);
> drivers/power/reset/at91-sama5d2_shdwc.c: { .compatible =
> "atmel,sama5d2-pmc" },
>
> Geez! How many drivers are there for this one device. Clearly not all
> of them are going to bind. But I'm not going to dig into this. You can
From this entire list only the drivers/clk/at91/sama5d2.c driver binds to the
"atmel,sama5d2-pmc" compatible, the rest are just using the compatible to
map the PMC memory.
> reject this patch. I expect this series [1] to take care of the issue
> Tudor was trying to fix.
>
> Tudor,
>
> Want to give this series [1] a shot?
The series at [1] doesn't apply clean neither on next-20210209, nor on
driver-core-next. On top of which sha1 should I apply them?
Anyway, I think the patch at [2] is still needed, regardless of the outcome
of [1].
>
> [1] -
> https://lore.kernel.org/lkml/20210205222644.2357303-1-sarava...@google.com/
[2]
https://lore.kernel.org/lkml/20210203154332.470587-1-tudor.amba...@microchip.com/
Cheers,
ta
Re: [PATCH] clk: at91: sama5d2: Mark device OF_POPULATED after setup
Hi, Stephen,
On 2/9/21 9:55 AM, Stephen Boyd wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Quoting Saravana Kannan (2021-01-28 09:01:41)
>> On Thu, Jan 28, 2021 at 2:45 AM Tudor Ambarus
>> wrote:
>>>
>>> The sama5d2 requires the clock provider initialized before timers.
>>> We can't use a platform driver for the sama5d2-pmc driver, as the
>>> platform_bus_init() is called later on, after time_init().
>>>
>>> As fw_devlink considers only devices, it does not know that the
>>> pmc is ready. Hence probing of devices that depend on it fail:
>>> probe deferral - supplier f0014000.pmc not ready
>>>
>>> Fix this by setting the OF_POPULATED flag for the sama5d2_pmc
>>> device node after successful setup. This will make
>>> of_link_to_phandle() ignore the sama5d2_pmc device node as a
>>> dependency, and consumer devices will be probed again.
>>>
>>> Fixes: e590474768f1cc04 ("driver core: Set fw_devlink=on by default")
>>> Signed-off-by: Tudor Ambarus
>>> ---
>>> I'll be out of office, will check the rest of the at91 SoCs
>>> at the begining of next week.
>>>
>>> drivers/clk/at91/sama5d2.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
>>> index 9a5cbc7cd55a..5eea2b4a63dd 100644
>>> --- a/drivers/clk/at91/sama5d2.c
>>> +++ b/drivers/clk/at91/sama5d2.c
>>> @@ -367,6 +367,8 @@ static void __init sama5d2_pmc_setup(struct device_node
>>> *np)
>>>
>>> of_clk_add_hw_provider(np, of_clk_hw_pmc_get, sama5d2_pmc);
>>>
>>> + of_node_set_flag(np, OF_POPULATED);
>>> +
>>> return;
>>
>> Hi Tudor,
>>
>> Thanks for looking into this.
>>
>> I already accounted for early clocks like this when I designed
>> fw_devlink. Each driver shouldn't need to set OF_POPULATED.
>> drivers/clk/clk.c already does this for you.
>>
>> I think the problem is that your driver is using
>> CLK_OF_DECLARE_DRIVER() instead of CLK_OF_DECLARE(). The comments for
>> CLK_OF_DECLARE_DRIVER() says:
>> /*
>> * Use this macro when you have a driver that requires two initialization
>> * routines, one at of_clk_init(), and one at platform device probe
>> */
>>
>> In your case, you are explicitly NOT having a driver bind to this
>> clock later. So you shouldn't be using CLK_OF_DECLARE() instead.
>>
>
> I see
>
> drivers/power/reset/at91-sama5d2_shdwc.c: { .compatible =
> "atmel,sama5d2-pmc" },
>
> so isn't that the driver that wants to bind to the same device node
> again? First at of_clk_init() time here and then second for the reset
> driver?
No, it isn't. at91_shdwc_driver binds the compatibles from at91_shdwc_of_match:
static const struct of_device_id at91_shdwc_of_match[] = {
{
.compatible = "atmel,sama5d2-shdwc",
.data = _reg_config,
},
{
.compatible = "microchip,sam9x60-shdwc",
.data = _reg_config,
}, {
/*sentinel*/
}
};
MODULE_DEVICE_TABLE(of, at91_shdwc_of_match);
The pmc compatibles are later on used in the probe function in order to
get with of_iomap() the pmc_base, that is later used in at91_poweroff()
method.
Just for the reference, this patch is superseded by the following:
https://lore.kernel.org/lkml/20210203154332.470587-1-tudor.amba...@microchip.com/
Cheers,
ta
Re: [PATCH 1/2] mtd: spi-nor: core: Advance erase after the erase cmd has been completed
On 2/8/21 1:41 PM, Pratyush Yadav wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 05/02/21 03:52PM, Tudor Ambarus wrote: >> Wait for the erase cmd to complete and then advance the erase. >> >> Signed-off-by: Tudor Ambarus >> --- >> drivers/mtd/spi-nor/core.c | 12 ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c >> index 0522304f52fa..bcaa161bc7db 100644 >> --- a/drivers/mtd/spi-nor/core.c >> +++ b/drivers/mtd/spi-nor/core.c >> @@ -1618,12 +1618,12 @@ static int spi_nor_erase_multi_sectors(struct >> spi_nor *nor, u64 addr, u32 len) >> if (ret) >> goto destroy_erase_cmd_list; >> >> - addr += cmd->size; >> - cmd->count--; >> - >> ret = spi_nor_wait_till_ready(nor); >> if (ret) >> goto destroy_erase_cmd_list; >> + >> + addr += cmd->size; >> + cmd->count--; >> } >> list_del(>list); >> kfree(cmd); >> @@ -1704,12 +1704,12 @@ static int spi_nor_erase(struct mtd_info *mtd, >> struct erase_info *instr) >> if (ret) >> goto erase_err; >> >> - addr += mtd->erasesize; >> - len -= mtd->erasesize; >> - >> ret = spi_nor_wait_till_ready(nor); >> if (ret) >> goto erase_err; >> + >> + addr += mtd->erasesize; >> + len -= mtd->erasesize; > > Do these changes have any practical benefit? IMO they are worth doing > even if there is none but I'm curious what prompted this patch. I saw these when reviewing Takahiro's patches. Addr and len were gratuitously updated even when the wait failed. We'll avoid 2 extra ops on the error path. Plus, having them updated before the wait can be misleading for someone that tracks them down with some debug messages. I find the code better structured, and the code will make more sense when it is read, if using this patch. > > Reviewed-by: Pratyush Yadav Thanks, ta > >> } >> >> /* erase multiple sectors */ > > -- > Regards, > Pratyush Yadav > Texas Instruments Inc. >
Re: [PATCH 2/2] mtd: spi-nor: core: Add dbg msg for spi_nor_erase_multi_sectors()
On 2/8/21 1:41 PM, Pratyush Yadav wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 05/02/21 03:52PM, Tudor Ambarus wrote: >> Useful when debugging non-uniform erase. >> >> Signed-off-by: Tudor Ambarus >> --- >> drivers/mtd/spi-nor/core.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c >> index bcaa161bc7db..7401c60b53e6 100644 >> --- a/drivers/mtd/spi-nor/core.c >> +++ b/drivers/mtd/spi-nor/core.c >> @@ -1622,6 +1622,9 @@ static int spi_nor_erase_multi_sectors(struct spi_nor >> *nor, u64 addr, u32 len) >> if (ret) >> goto destroy_erase_cmd_list; >> >> + dev_dbg(nor->dev, "erase_cmd->size = 0x%08x, >> erase_cmd->opcode = 0x%02x, erase_cmd->count = %d\n", >> + cmd->size, cmd->opcode, cmd->count); >> + > > I don't like the position of this debug message. This prints cmd->count > _after_ the erase is done but _before_ cmd->count is updated. It might oh, yes. > end up giving some wrong or misleading information. Can you either move > it before the start of the erase or after all the bookkeeping is done? Before the start of the erase sounds good, but still inside the while, so that we catch each executed command. And maybe I'll change dev_dbg to dev_vdbg. I'll made my mind before v2. Cheers, ta > >> addr += cmd->size; >> cmd->count--; >> } >> -- >> 2.25.1 > > -- > Regards, > Pratyush Yadav > Texas Instruments Inc. >
Re: [PATCH] mtd: spi-nor: boya: add support for boya by25q128as
Hi, George,
On 2/7/21 2:30 PM, George Brooke wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Adds support for the Boya Microelectronics BY25Q128AS 128 Mbit flash.
> I tested this on the Creality WB-01 embedded device which uses this,
> although that was with OpenWrt which is still using 5.4 so I had to
> do a bit of porting work. Don't see how that would make much of a
> difference though.
>
> Signed-off-by: George Brooke
> ---
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/boya.c | 23 +++
> drivers/mtd/spi-nor/core.c | 1 +
> drivers/mtd/spi-nor/core.h | 1 +
> 4 files changed, 26 insertions(+)
> create mode 100644 drivers/mtd/spi-nor/boya.c
>
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 653923896205..7d1551fbfbaa 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -2,6 +2,7 @@
>
> spi-nor-objs := core.o sfdp.o
> spi-nor-objs += atmel.o
> +spi-nor-objs += boya.o
> spi-nor-objs += catalyst.o
> spi-nor-objs += eon.o
> spi-nor-objs += esmt.o
> diff --git a/drivers/mtd/spi-nor/boya.c b/drivers/mtd/spi-nor/boya.c
> new file mode 100644
> index ..014b0087048a
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/boya.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2005, Intec Automation Inc.
> + * Copyright (C) 2014, Freescale Semiconductor, Inc.
> + */
> +
> +#include
> +
> +#include "core.h"
> +
> +static const struct flash_info boya_parts[] = {
> + /* Boya */
> + { "by25q128as", INFO(0x684018, 0, 64 * 1024, 256,
The manufacturer’s identification code is defined by one or more
eight (8) bit fields each consisting of seven (7) data bits plus one (1)
odd parity bit. It is a single field limiting the possible number of
vendors to 126. To expand the maximum number of identification codes a
continuation scheme has been defined.
According to JEP106BA, the manufacturer ID for Boya should be preceded by
eight continuation codes. So I would expect the manufacturer ID for this
flash to be: 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x68.
Without the continuation codes, we will have collisions between
manufacturer IDs, Convex Computer being an example.
I see that the datasheet [1] for this flash doesn't specify anything
about the continuation codes, so I suspect that Boya just got it wrong.
We'll have to check other datasheets from Boya and see if they got
their manufacturer ID wrong for all their flashes. We'll have to add
some fixup mechanism for the manufacturers ID handling, in order to
avoid collisions with other manufacturers IDs.
Cheers,
ta
[1]
https://datasheet.lcsc.com/szlcsc/1904091402_BOYAMICRO-BY25Q128ASSIG_C383794.pdf
> + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> + SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
> + },
> +};
> +
> +const struct spi_nor_manufacturer spi_nor_boya = {
> + .name = "boya",
> + .parts = boya_parts,
> + .nparts = ARRAY_SIZE(boya_parts),
> +};
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 20df44b753da..4d0d003e9c3f 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2160,6 +2160,7 @@ int spi_nor_sr2_bit7_quad_enable(struct spi_nor *nor)
>
> static const struct spi_nor_manufacturer *manufacturers[] = {
> _nor_atmel,
> + _nor_boya,
> _nor_catalyst,
> _nor_eon,
> _nor_esmt,
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index d631ee299de3..d5ed5217228b 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -409,6 +409,7 @@ struct spi_nor_manufacturer {
>
> /* Manufacturer drivers. */
> extern const struct spi_nor_manufacturer spi_nor_atmel;
> +extern const struct spi_nor_manufacturer spi_nor_boya;
> extern const struct spi_nor_manufacturer spi_nor_catalyst;
> extern const struct spi_nor_manufacturer spi_nor_eon;
> extern const struct spi_nor_manufacturer spi_nor_esmt;
> --
> 2.30.0
>
Re: [PATCH] clk: at91: Fix the declaration of the clocks
Hi, Michael, Stephen,
Do you plan to take this patch for v5.12?
If fw_devlink will remain set to ON for v5.12, some of our boards will
no longer boot without this patch.
Cheers,
ta
On 2/3/21 5:43 PM, Tudor Ambarus wrote:
> These are all "early clocks" that require initialization just at
> of_clk_init() time. Use CLK_OF_DECLARE() to declare them.
>
> This also fixes a problem that was spotted when fw_devlink was
> set to 'on' by default: the boards failed to boot. The reason is
> that CLK_OF_DECLARE_DRIVER() clears the OF_POPULATED and causes
> the consumers of the clock to be postponed by fw_devlink until
> the second initialization routine of the clock has been completed.
> One of the consumers of the clock is the timer, which is used as a
> clocksource, and needs the clock initialized early. Postponing the
> timers caused the fail at boot.
>
> Signed-off-by: Tudor Ambarus
> ---
> Tested on sama5d2_xplained.
>
> drivers/clk/at91/at91rm9200.c | 3 +--
> drivers/clk/at91/at91sam9260.c | 16
> drivers/clk/at91/at91sam9g45.c | 3 +--
> drivers/clk/at91/at91sam9n12.c | 3 +--
> drivers/clk/at91/at91sam9rl.c | 3 ++-
> drivers/clk/at91/at91sam9x5.c | 20 ++--
> drivers/clk/at91/sama5d2.c | 3 ++-
> drivers/clk/at91/sama5d3.c | 2 +-
> drivers/clk/at91/sama5d4.c | 3 ++-
> 9 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/clk/at91/at91rm9200.c b/drivers/clk/at91/at91rm9200.c
> index 0fad1009f315..428a6f4b9ebc 100644
> --- a/drivers/clk/at91/at91rm9200.c
> +++ b/drivers/clk/at91/at91rm9200.c
> @@ -215,5 +215,4 @@ static void __init at91rm9200_pmc_setup(struct
> device_node *np)
> * deferring properly. Once this is fixed, this can be switched to a platform
> * driver.
> */
> -CLK_OF_DECLARE_DRIVER(at91rm9200_pmc, "atmel,at91rm9200-pmc",
> - at91rm9200_pmc_setup);
> +CLK_OF_DECLARE(at91rm9200_pmc, "atmel,at91rm9200-pmc", at91rm9200_pmc_setup);
> diff --git a/drivers/clk/at91/at91sam9260.c b/drivers/clk/at91/at91sam9260.c
> index ceb5495f723a..b29843bea278 100644
> --- a/drivers/clk/at91/at91sam9260.c
> +++ b/drivers/clk/at91/at91sam9260.c
> @@ -491,26 +491,26 @@ static void __init at91sam9260_pmc_setup(struct
> device_node *np)
> {
> at91sam926x_pmc_setup(np, _data);
> }
> -CLK_OF_DECLARE_DRIVER(at91sam9260_pmc, "atmel,at91sam9260-pmc",
> - at91sam9260_pmc_setup);
> +
> +CLK_OF_DECLARE(at91sam9260_pmc, "atmel,at91sam9260-pmc",
> at91sam9260_pmc_setup);
>
> static void __init at91sam9261_pmc_setup(struct device_node *np)
> {
> at91sam926x_pmc_setup(np, _data);
> }
> -CLK_OF_DECLARE_DRIVER(at91sam9261_pmc, "atmel,at91sam9261-pmc",
> - at91sam9261_pmc_setup);
> +
> +CLK_OF_DECLARE(at91sam9261_pmc, "atmel,at91sam9261-pmc",
> at91sam9261_pmc_setup);
>
> static void __init at91sam9263_pmc_setup(struct device_node *np)
> {
> at91sam926x_pmc_setup(np, _data);
> }
> -CLK_OF_DECLARE_DRIVER(at91sam9263_pmc, "atmel,at91sam9263-pmc",
> - at91sam9263_pmc_setup);
> +
> +CLK_OF_DECLARE(at91sam9263_pmc, "atmel,at91sam9263-pmc",
> at91sam9263_pmc_setup);
>
> static void __init at91sam9g20_pmc_setup(struct device_node *np)
> {
> at91sam926x_pmc_setup(np, _data);
> }
> -CLK_OF_DECLARE_DRIVER(at91sam9g20_pmc, "atmel,at91sam9g20-pmc",
> - at91sam9g20_pmc_setup);
> +
> +CLK_OF_DECLARE(at91sam9g20_pmc, "atmel,at91sam9g20-pmc",
> at91sam9g20_pmc_setup);
> diff --git a/drivers/clk/at91/at91sam9g45.c b/drivers/clk/at91/at91sam9g45.c
> index 0214333dedd3..15da0dfe3ef2 100644
> --- a/drivers/clk/at91/at91sam9g45.c
> +++ b/drivers/clk/at91/at91sam9g45.c
> @@ -228,5 +228,4 @@ static void __init at91sam9g45_pmc_setup(struct
> device_node *np)
> * The TCB is used as the clocksource so its clock is needed early. This
> means
> * this can't be a platform driver.
> */
> -CLK_OF_DECLARE_DRIVER(at91sam9g45_pmc, "atmel,at91sam9g45-pmc",
> - at91sam9g45_pmc_setup);
> +CLK_OF_DECLARE(at91sam9g45_pmc, "atmel,at91sam9g45-pmc",
> at91sam9g45_pmc_setup);
> diff --git a/drivers/clk/at91/at91sam9n12.c b/drivers/clk/at91/at91sam9n12.c
> index f9db5316a7f1..7fe435f4b46b 100644
> --- a/drivers/clk/at91/at91sam9n12.c
> +++ b/drivers/clk/at91/at91sam9n12.c
> @@ -255,5 +255,4 @@ static void __init at91sam9n12_pmc_setup(struct
> device_node *np)
> * The TCB is used as the clocksource so its clock is needed early. This
> means
> * this can't be a platform driver.
> */
> -CLK_OF_DECLARE_DRIVER(at91sam9n12_pmc, "atmel,at91sam9n12-pmc",
> - at91sam9n12_pmc_setup);
> +CLK_OF_DECLARE(at91sam9n12_pmc, "atmel,at91sam9n12-pmc",
> at91sam9n12_pmc_setup);
> diff --git a/drivers/clk/at91/at91sam9rl.c b/drivers/clk/at91/at91sam9rl.c
> index 66736e03cfef..ecbabf5162bd 100644
> --- a/drivers/clk/at91/at91sam9rl.c
> +++ b/drivers/clk/at91/at91sam9rl.c
> @@ -186,4 +186,5 @@ static void __init
Re: [PATCH] ARM: configs: sama5_defconfig: add QSPI driver
On 2/8/21 10:21 AM, nicolas.fe...@microchip.com wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > From: Nicolas Ferre > > Add Quad SPI driver to the sama5 defconfig. This driver is needed for > sama5d2 SoC. > > Signed-off-by: Nicolas Ferre Reviewed-by: Tudor Ambarus > --- > arch/arm/configs/sama5_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/sama5_defconfig > b/arch/arm/configs/sama5_defconfig > index b72bd38a1c45..f4c3c0652432 100644 > --- a/arch/arm/configs/sama5_defconfig > +++ b/arch/arm/configs/sama5_defconfig > @@ -121,6 +121,7 @@ CONFIG_I2C_AT91=y > CONFIG_I2C_GPIO=y > CONFIG_SPI=y > CONFIG_SPI_ATMEL=y > +CONFIG_SPI_ATMEL_QUADSPI=y > CONFIG_SPI_GPIO=y > CONFIG_GPIO_SYSFS=y > CONFIG_GPIO_SAMA5D2_PIOBU=m > -- > 2.30.0 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
Re: [PATCH] ARM: configs: at91: enable drivers for sam9x60
On 2/5/21 11:54 AM, Claudiu Beznea wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Enable drivers for sam9x60/sam9x60-ek: > - shutdown controller > - CAN > - AT24 EEPROM (present on SAM9X60-EK) > - MCP23S08 (present on SAM9X60-EK) > - AES, TDES, SHA Crypto IPs are present only sam9x60. Should we have them as modules? > > And use "make savedefconfig". > > Signed-off-by: Claudiu Beznea With or without the Crypto IPs as modules: Reviewed-by: Tudor Ambarus > --- > arch/arm/configs/at91_dt_defconfig | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/configs/at91_dt_defconfig > b/arch/arm/configs/at91_dt_defconfig > index 5f3415c743ec..e274f8c492d2 100644 > --- a/arch/arm/configs/at91_dt_defconfig > +++ b/arch/arm/configs/at91_dt_defconfig > @@ -17,8 +17,6 @@ CONFIG_SOC_SAM9X60=y > # CONFIG_ATMEL_CLOCKSOURCE_PIT is not set > CONFIG_AEABI=y > CONFIG_UACCESS_WITH_MEMCPY=y > -CONFIG_ZBOOT_ROM_TEXT=0x0 > -CONFIG_ZBOOT_ROM_BSS=0x0 > CONFIG_ARM_APPENDED_DTB=y > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x2110,25165824 > root=/dev/ram0 rw" > @@ -38,6 +36,8 @@ CONFIG_IP_PNP_BOOTP=y > CONFIG_IP_PNP_RARP=y > # CONFIG_INET_DIAG is not set > CONFIG_IPV6_SIT_6RD=y > +CONFIG_CAN=y > +CONFIG_CAN_AT91=y > CONFIG_CFG80211=y > CONFIG_MAC80211=y > CONFIG_DEVTMPFS=y > @@ -58,6 +58,7 @@ CONFIG_BLK_DEV_RAM=y > CONFIG_BLK_DEV_RAM_COUNT=4 > CONFIG_BLK_DEV_RAM_SIZE=8192 > CONFIG_ATMEL_SSC=y > +CONFIG_EEPROM_AT24=m > CONFIG_SCSI=y > CONFIG_BLK_DEV_SD=y > # CONFIG_SCSI_LOWLEVEL is not set > @@ -91,7 +92,6 @@ CONFIG_RT2800USB_UNKNOWN=y > CONFIG_RTL8187=m > CONFIG_RTL8192CU=m > # CONFIG_RTLWIFI_DEBUG is not set > -CONFIG_INPUT_POLLDEV=y > CONFIG_INPUT_JOYDEV=y > CONFIG_INPUT_EVDEV=y > # CONFIG_KEYBOARD_ATKBD is not set > @@ -111,8 +111,8 @@ CONFIG_I2C_GPIO=y > CONFIG_SPI=y > CONFIG_SPI_ATMEL=y > CONFIG_SPI_ATMEL_QUADSPI=y > +CONFIG_PINCTRL_MCP23S08=m > CONFIG_POWER_RESET=y > -# CONFIG_POWER_RESET_AT91_SAMA5D2_SHDWC is not set > CONFIG_POWER_SUPPLY=y > # CONFIG_HWMON is not set > CONFIG_WATCHDOG=y > @@ -208,7 +208,9 @@ CONFIG_NLS_UTF8=y > CONFIG_CRYPTO_ECB=y > CONFIG_CRYPTO_USER_API_HASH=m > CONFIG_CRYPTO_USER_API_SKCIPHER=m > -# CONFIG_CRYPTO_HW is not set > +CONFIG_CRYPTO_DEV_ATMEL_AES=y > +CONFIG_CRYPTO_DEV_ATMEL_TDES=y > +CONFIG_CRYPTO_DEV_ATMEL_SHA=y > CONFIG_CRC_CCITT=y > CONFIG_FONTS=y > CONFIG_FONT_8x8=y > -- > 2.7.4 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
Re: [PATCH] ARM: configs: at91: enable drivers for sam9x60
On 2/5/21 12:12 PM, tudor.amba...@microchip.com wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 2/5/21 11:54 AM, Claudiu Beznea wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >> content is safe >> >> Enable drivers for sam9x60/sam9x60-ek: >> - shutdown controller >> - CAN >> - AT24 EEPROM (present on SAM9X60-EK) >> - MCP23S08 (present on SAM9X60-EK) >> - AES, TDES, SHA > > Crypto IPs are present only sam9x60. Should we have them as modules? ^The^on :) > >> >> And use "make savedefconfig". >> >> Signed-off-by: Claudiu Beznea > > With or without the Crypto IPs as modules: > > Reviewed-by: Tudor Ambarus > >> --- >> arch/arm/configs/at91_dt_defconfig | 12 +++- >> 1 file changed, 7 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm/configs/at91_dt_defconfig >> b/arch/arm/configs/at91_dt_defconfig >> index 5f3415c743ec..e274f8c492d2 100644 >> --- a/arch/arm/configs/at91_dt_defconfig >> +++ b/arch/arm/configs/at91_dt_defconfig >> @@ -17,8 +17,6 @@ CONFIG_SOC_SAM9X60=y >> # CONFIG_ATMEL_CLOCKSOURCE_PIT is not set >> CONFIG_AEABI=y >> CONFIG_UACCESS_WITH_MEMCPY=y >> -CONFIG_ZBOOT_ROM_TEXT=0x0 >> -CONFIG_ZBOOT_ROM_BSS=0x0 >> CONFIG_ARM_APPENDED_DTB=y >> CONFIG_ARM_ATAG_DTB_COMPAT=y >> CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x2110,25165824 >> root=/dev/ram0 rw" >> @@ -38,6 +36,8 @@ CONFIG_IP_PNP_BOOTP=y >> CONFIG_IP_PNP_RARP=y >> # CONFIG_INET_DIAG is not set >> CONFIG_IPV6_SIT_6RD=y >> +CONFIG_CAN=y >> +CONFIG_CAN_AT91=y >> CONFIG_CFG80211=y >> CONFIG_MAC80211=y >> CONFIG_DEVTMPFS=y >> @@ -58,6 +58,7 @@ CONFIG_BLK_DEV_RAM=y >> CONFIG_BLK_DEV_RAM_COUNT=4 >> CONFIG_BLK_DEV_RAM_SIZE=8192 >> CONFIG_ATMEL_SSC=y >> +CONFIG_EEPROM_AT24=m >> CONFIG_SCSI=y >> CONFIG_BLK_DEV_SD=y >> # CONFIG_SCSI_LOWLEVEL is not set >> @@ -91,7 +92,6 @@ CONFIG_RT2800USB_UNKNOWN=y >> CONFIG_RTL8187=m >> CONFIG_RTL8192CU=m >> # CONFIG_RTLWIFI_DEBUG is not set >> -CONFIG_INPUT_POLLDEV=y >> CONFIG_INPUT_JOYDEV=y >> CONFIG_INPUT_EVDEV=y >> # CONFIG_KEYBOARD_ATKBD is not set >> @@ -111,8 +111,8 @@ CONFIG_I2C_GPIO=y >> CONFIG_SPI=y >> CONFIG_SPI_ATMEL=y >> CONFIG_SPI_ATMEL_QUADSPI=y >> +CONFIG_PINCTRL_MCP23S08=m >> CONFIG_POWER_RESET=y >> -# CONFIG_POWER_RESET_AT91_SAMA5D2_SHDWC is not set >> CONFIG_POWER_SUPPLY=y >> # CONFIG_HWMON is not set >> CONFIG_WATCHDOG=y >> @@ -208,7 +208,9 @@ CONFIG_NLS_UTF8=y >> CONFIG_CRYPTO_ECB=y >> CONFIG_CRYPTO_USER_API_HASH=m >> CONFIG_CRYPTO_USER_API_SKCIPHER=m >> -# CONFIG_CRYPTO_HW is not set >> +CONFIG_CRYPTO_DEV_ATMEL_AES=y >> +CONFIG_CRYPTO_DEV_ATMEL_TDES=y >> +CONFIG_CRYPTO_DEV_ATMEL_SHA=y >> CONFIG_CRC_CCITT=y >> CONFIG_FONTS=y >> CONFIG_FONT_8x8=y >> -- >> 2.7.4 >> >> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
Re: [PATCH 12/20] crypto: atmel-ecc: Struct headers need to start with keyword 'struct'
On 2/4/21 1:09 PM, Lee Jones wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Fixes the following W=1 kernel build warning(s): > > drivers/crypto/atmel-ecc.c:41: warning: cannot understand function > prototype: 'struct atmel_ecdh_ctx ' > > Cc: Tudor Ambarus > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Nicolas Ferre > Cc: Alexandre Belloni > Cc: Ludovic Desroches > Cc: linux-cry...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Lee Jones Reviewed-by: Tudor Ambarus > --- > drivers/crypto/atmel-ecc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c > index 9bd8e5167be34..66a31e5739f4c 100644 > --- a/drivers/crypto/atmel-ecc.c > +++ b/drivers/crypto/atmel-ecc.c > @@ -26,7 +26,7 @@ > static struct atmel_ecc_driver_data driver_data; > > /** > - * atmel_ecdh_ctx - transformation context > + * struct atmel_ecdh_ctx - transformation context > * @client : pointer to i2c client device > * @fallback : used for unsupported curves or when user wants to use its > own > * private key. > -- > 2.25.1 >
Re: [PATCH v2 0/3] Make fw_devlink=on more forgiving
Hi, Saravana, On 2/2/21 6:33 AM, Saravana Kannan wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > This patch series solves two general issues with fw_devlink=on > > Patch 1/3 and 3/3 addresses the issue of firmware nodes that look like > they'll have struct devices created for them, but will never actually > have struct devices added for them. For example, DT nodes with a > compatible property that don't have devices added for them. > > Patch 2/2 address (for static kernels) the issue of optional suppliers > that'll never have a driver registered for them. So, if the device could > have probed with fw_devlink=permissive with a static kernel, this patch > should allow those devices to probe with a fw_devlink=on. This doesn't > solve it for the case where modules are enabled because there's no way > to tell if a driver will never be registered or it's just about to be > registered. I have some other ideas for that, but it'll have to come > later thinking about it a bit. > > Marek, Geert, > > I don't expect v2 to do any better for your cases. > > This series not making any difference for Marek is still a mystery to > me. I guess one of the consumers doesn't take too well to its probe (and > it's consumers' probe) being delayed till late_initcall(). I'll continue > looking into it. > > Marc, > > This v2 should do better than v1 with gpiolib stub driver reverted. I > forgot to take care of the case where more suppliers could link after I > went and deleted some of the links. v2 handles that now. > > Tudor, > > You should still make the clock driver fix (because it's a bug), but I > think this series will fix your issue too (even without the clock driver > fix). Can you please give this a shot? > Did the following tests (using sama5_defconfig and at91-sama5d2_xplained.dts): 1/ modular kernel with your v2 on top of next-20210202, and without the clock driver fix: the problem persists. 2/ static kernel with your v2 on top of next-20210202, and without the clock driver fix: the problem persists. Comparing to the previous test, I see that the links to pmc are dropped. I can see the following only with early printk enabled: platform fc008000.serial: Dropping the link to f0014000.pmc But later on, the serial still gets deferred waiting for the dma controller this time: platform f802.serial: probe deferral - supplier f001.dma-controller not ready I'll check what happens in the dma-controller. 3/ modular kernel with your v2 and the clock driver fix on top of next-20210202: I can boot the board and I have access to the console. I still have some probe deferrals that I need to check: root@sama5d2-xplained-sd:~# dmesg | grep -i defer [4.335625] platform b000.sdio-host: probe deferral - wait for supplier pmic@5b [4.474559] platform fc03.adc: probe deferral - wait for supplier pmic@5b [4.884315] calling deferred_probe_initcall+0x0/0xd8 @ 1 [4.889206] platform fc03.adc: probe deferral - wait for supplier pmic@5b [5.139447] initcall deferred_probe_initcall+0x0/0xd8 returned 0 after 245132 usecs root@sama5d2-xplained-sd:~# dmesg | grep -i linked [4.916342] platform fc03.adc: Linked as a consumer to 0-005b [4.921298] platform b000.sdio-host: Linked as a consumer to 0-005b [4.926817] i2c 0-005b: Linked as a sync state only consumer to fc038000.pinctrl [4.990246] platform act8945a-charger: Linked as a consumer to fc038000.pinctrl [5.078488] at24 1-0054: Linked as a consumer to regulator.0 [5.111533] at91-sama5d2_adc fc03.adc: Linked as a consumer to regulator.5 [5.118969] sdhci-at91 b000.sdio-host: Linked as a consumer to regulator.3 root@sama5d2-xplained-sd:~# dmesg | grep -i drop [5.014026] act8945a 0-005b: Dropping the link to fc038000.pinctrl 4/ static kernel with your v2 and the clock driver fix on top of next-20210202: I can boot the board and I have access to the console. The probe deferrals are the same as in test 3/. Cheers, ta
Re: [PATCH v1 5/5] driver core: Set fw_devlink=on by default
Hi, Saravana,
On 1/25/21 8:16 PM, Saravana Kannan wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Mon, Jan 25, 2021 at 9:05 AM wrote:
>>
>> Hi, Saravana,
>>
>> On 12/18/20 5:17 AM, Saravana Kannan wrote:
>>> Cyclic dependencies in some firmware was one of the last remaining
>>> reasons fw_devlink=on couldn't be set by default. Now that cyclic
>>> dependencies don't block probing, set fw_devlink=on by default.
>>>
>>> Setting fw_devlink=on by default brings a bunch of benefits (currently,
>>> only for systems with device tree firmware):
>>> * Significantly cuts down deferred probes.
>>> * Device probe is effectively attempted in graph order.
>>> * Makes it much easier to load drivers as modules without having to
>>> worry about functional dependencies between modules (depmod is still
>>> needed for symbol dependencies).
>>>
>>> If this patch prevents some devices from probing, it's very likely due
>>> to the system having one or more device drivers that "probe"/set up a
>>> device (DT node with compatible property) without creating a struct
>>> device for it. If we hit such cases, the device drivers need to be
>>> fixed so that they populate struct devices and probe them like normal
>>> device drivers so that the driver core is aware of the devices and their
>>> status. See [1] for an example of such a case.
>>>
>>> [1] -
>>> https://lore.kernel.org/lkml/CAGETcx9PiX==mlxb9po8myyk6u2vhpvwtmsa5nkd-ywh5xh...@mail.gmail.com/
>>> Signed-off-by: Saravana Kannan
>>
>> next-20210125 fails to boot on at91 sama5d2 platforms. No output is
>> seen, unless earlyprintk is enabled.
>>
>> I have bisected this to commit e590474768f1cc04 ("driver core: Set
>> fw_devlink=on by default").
>>
>> I've attached a log that I'm seeing on a sama5d2_xplained (sama5_defconfig
>> and arch/arm/boot/dts/at91-sama5d2_xplained.dts). I enabled the
>> following logs:
>> 1. The ones in device_links_check_suppliers()
>> 2. The ones in device_link_add()
>> 3. initcall_debug=1
>>
>> There seem to be some probe fails due to the pmc supplier not being ready:
>> calling at_xdmac_init+0x0/0x18 @ 1
>> platform f001.dma-controller: probe deferral - supplier f0014000.pmc not
>> ready
>> platform f0004000.dma-controller: probe deferral - supplier f0014000.pmc not
>> ready
>> initcall at_xdmac_init+0x0/0x18 returned -19 after 19531 usecs
>>
>> calling udc_driver_init+0x0/0x18 @ 1
>> platform 30.gadget: probe deferral - supplier f0014000.pmc not ready
>> initcall udc_driver_init+0x0/0x18 returned -19 after 7524 usecs
>>
>> There are others too. I'm checking them.
>
> Thanks Tudor. I'll look into this within a few days. I'm also looking
> into coming up with a more generic solution.
>
I've sent a patch addressing this at:
https://lore.kernel.org/lkml/20210128104446.164269-1-tudor.amba...@microchip.com/T/#u
Can you please take a look?
Cheers,
ta
Re: [PATCH v1 5/5] driver core: Set fw_devlink=on by default
Hi, Saravana,
On 12/18/20 5:17 AM, Saravana Kannan wrote:
> Cyclic dependencies in some firmware was one of the last remaining
> reasons fw_devlink=on couldn't be set by default. Now that cyclic
> dependencies don't block probing, set fw_devlink=on by default.
>
> Setting fw_devlink=on by default brings a bunch of benefits (currently,
> only for systems with device tree firmware):
> * Significantly cuts down deferred probes.
> * Device probe is effectively attempted in graph order.
> * Makes it much easier to load drivers as modules without having to
> worry about functional dependencies between modules (depmod is still
> needed for symbol dependencies).
>
> If this patch prevents some devices from probing, it's very likely due
> to the system having one or more device drivers that "probe"/set up a
> device (DT node with compatible property) without creating a struct
> device for it. If we hit such cases, the device drivers need to be
> fixed so that they populate struct devices and probe them like normal
> device drivers so that the driver core is aware of the devices and their
> status. See [1] for an example of such a case.
>
> [1] -
> https://lore.kernel.org/lkml/CAGETcx9PiX==mlxb9po8myyk6u2vhpvwtmsa5nkd-ywh5xh...@mail.gmail.com/
> Signed-off-by: Saravana Kannan
next-20210125 fails to boot on at91 sama5d2 platforms. No output is
seen, unless earlyprintk is enabled.
I have bisected this to commit e590474768f1cc04 ("driver core: Set
fw_devlink=on by default").
I've attached a log that I'm seeing on a sama5d2_xplained (sama5_defconfig
and arch/arm/boot/dts/at91-sama5d2_xplained.dts). I enabled the
following logs:
1. The ones in device_links_check_suppliers()
2. The ones in device_link_add()
3. initcall_debug=1
There seem to be some probe fails due to the pmc supplier not being ready:
calling at_xdmac_init+0x0/0x18 @ 1
platform f001.dma-controller: probe deferral - supplier f0014000.pmc not
ready
platform f0004000.dma-controller: probe deferral - supplier f0014000.pmc not
ready
initcall at_xdmac_init+0x0/0x18 returned -19 after 19531 usecs
calling udc_driver_init+0x0/0x18 @ 1
platform 30.gadget: probe deferral - supplier f0014000.pmc not ready
initcall udc_driver_init+0x0/0x18 returned -19 after 7524 usecs
There are others too. I'm checking them.
Cheers,
ta
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 5.11.0-rc4-next-20210125+ (atudor@atudor-ThinkPad-T470p) (arm-linux-gnueabi-gcc (Linaro GCC 7.5-2019.12) 7.5.0, GNU ld (Linaro_Binutils-2019.12) 2.28.2.20170706) #57 Mon Jan 25 18:36:05 EET 2021
CPU: ARMv7 Processor [410fc051] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt: Machine model: Atmel SAMA5D2 Xplained
printk: debug: ignoring loglevel setting.
printk: bootconsole [earlycon0] enabled
Memory policy: Data cache writeback
Zone ranges:
Normal [mem 0x2000-0x3fff]
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x2000-0x3fff]
Initmem setup node 0 [mem 0x2000-0x3fff]
On node 0 totalpages: 131072
Normal zone: 1024 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 131072 pages, LIFO batch:31
CPU: All CPU(s) started in SVC mode.
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists, mobility grouping on. Total pages: 130048
Kernel command line: console=ttyS0,115200 root=/dev/nfs rootfstype=nfs rw rootwait ignore_loglevel earlyprintk initcall_debug nfsroot=192.168.0.120:/nfsroot/2020.04/sama5d2-xplained,tcp,v3 ip=192.168.0.125:192.168.0.120::
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 506940K/524288K available (8192K kernel code, 281K rwdata, 1896K rodata, 1024K init, 113K bss, 17348K reserved, 0K cma-reserved)
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
L2C-310 ID prefetch enabled, offset 2 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 8 ways, 128 kB
L2C-310: CACHE_ID 0x41c9, AUX_CTRL 0x3602
random: get_random_bytes called from start_kernel+0x33c/0x4c0 with crng_init=0
clocksource: timer@f800c000: mask: 0x max_cycles: 0x, max_idle_ns: 184217874325 ns
sched_clock: 32 bits at 10MHz, resolution 96ns, wraps every 206986376143ns
Switching to timer-based delay loop, resolution 96ns
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 20.75 BogoMIPS (lpj=103750)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
CPU: Testing write buffer coherency: ok
calling
Re: [PATCH] spi-nor: Add support for xt25f128b
Hi, Andreas,
On 12/21/20 12:43 AM, Andreas Rammhold wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This adds support for the xt25f128b as found on the rockpi4b SBC.
>
> Signed-off-by: Andreas Rammhold
> ---
>
> This continues the efforts done in [1] & [2] that went stale. I've
> tested this patch on my RockPi4b which only has the xt25f128b (and not
> the xt25f32b as also propsed in [2]). I have tried to obtain a copy of
> the datasheets but was unable to find them. Not sure whre you would get
> them.
>
> While [1] was already for the new spi-nor layout it was missing the bits
> in the core.{c,h} files.
>
>
> [1]:
> https://patchwork.ozlabs.org/project/linux-mtd/patch/camgqo2y9mydj6antoawlbrku8vgewqcb-y1tkxtswsmsed+...@mail.gmail.com/
> [2]:
> https://patchwork.ozlabs.org/project/linux-mtd/patch/20200206171941.ga2...@makrotopia.org/
>
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/core.c | 1 +
> drivers/mtd/spi-nor/core.h | 1 +
> drivers/mtd/spi-nor/xtx.c| 16
> 4 files changed, 19 insertions(+)
> create mode 100644 drivers/mtd/spi-nor/xtx.c
>
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 653923896205..3f7a52d7fa0b 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -17,6 +17,7 @@ spi-nor-objs += sst.o
> spi-nor-objs += winbond.o
> spi-nor-objs += xilinx.o
> spi-nor-objs += xmc.o
> +spi-nor-objs += xtx.o
> obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o
>
> obj-$(CONFIG_MTD_SPI_NOR) += controllers/
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index f0ae7a01703a..ca1988554945 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2024,6 +2024,7 @@ static const struct spi_nor_manufacturer
> *manufacturers[] = {
> _nor_winbond,
> _nor_xilinx,
> _nor_xmc,
> + _nor_xtx,
> };
>
> static const struct flash_info *
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 6f2f6b27173f..cea8c0c25c9f 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -398,6 +398,7 @@ extern const struct spi_nor_manufacturer spi_nor_sst;
> extern const struct spi_nor_manufacturer spi_nor_winbond;
> extern const struct spi_nor_manufacturer spi_nor_xilinx;
> extern const struct spi_nor_manufacturer spi_nor_xmc;
> +extern const struct spi_nor_manufacturer spi_nor_xtx;
>
> int spi_nor_write_enable(struct spi_nor *nor);
> int spi_nor_write_disable(struct spi_nor *nor);
> diff --git a/drivers/mtd/spi-nor/xtx.c b/drivers/mtd/spi-nor/xtx.c
> new file mode 100644
> index ..a10102d8b3e2
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/xtx.c
> @@ -0,0 +1,16 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +
> +#include "core.h"
> +
> +static const struct flash_info xtx_parts[] = {
> + /* XTX (Shenzhen Xin Tian Xia Tech) */
> + { "xt25f128b", INFO(0x0b4018, 0, 64 * 1024, 256, SECT_4K) },
According to JEP106BA, the XTX's identification code is in bank 10
and is comprised of 9 Continuation Codes (0x7f) and then by 0B.
XTX's manufacturer ID should be:
0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x0b.
Can you hack the SPI_NOR_MAX_ID_LEN field, in order to read 12
or more bytes? I assume XTX got it wrong, and put the
continuation codes after the flash ID.
Cheers,
ta
> +};
> +
> +const struct spi_nor_manufacturer spi_nor_xtx = {
> + .name = "xtx",
> + .parts = xtx_parts,
> + .nparts = ARRAY_SIZE(xtx_parts),
> +};
> --
> 2.29.2
>
Re: [PATCH v2] mtd: spi-nor: macronix: enable 4-bit BP support for MX25L6405D
Hi, Sieng,
On 12/8/20 3:57 AM, Sieng Piaw Liew wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Enable 4-bit Block Protect support for MX256405D and its variants using
> the same ID.
>
> Tested on Innacom W3400V6 router with MX25L6406E chip.
> https://github.com/openwrt/openwrt/pull/3501
>
> Signed-off-by: Sieng Piaw Liew
> ---
> Changes in v2:
> - Add SPI_NOR_HAS_LOCK which SPI_NOR_4BIT_BP required.
>
> drivers/mtd/spi-nor/macronix.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
> index 9203abaac229..033ede381673 100644
> --- a/drivers/mtd/spi-nor/macronix.c
> +++ b/drivers/mtd/spi-nor/macronix.c
> @@ -42,7 +42,9 @@ static const struct flash_info macronix_parts[] = {
> { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32, SECT_4K) },
> { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, SECT_4K) },
> { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) },
> - { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, SECT_4K) },
> + { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128,
> + SECT_4K | SPI_NOR_HAS_LOCK |
> + SPI_NOR_4BIT_BP) },
I've read again the datasheet[1], and to me it looks like we
don't support the locking scheme for this flash.
What mx25l6405d calls BP3, we refer to as Top/Bottom support (TB bit).
The problem that I see is that mx25l6405d uses some kind of twisted
TB bit.
For example, for BP3=1, BP2=0, BP1=0, BP0=1, the flash's datasheet
states that the lower half blocks are protected (0th-63th), while in
our code we would expect that just the lower first two blocks to be
protected (0th and 1st). We need new support for this flash.
Cheers,
ta
[1]
https://www.macronix.com/Lists/Datasheet/Attachments/7309/MX25L6405D,%203V,%2064Mb,%20v1.5.pdf
> { "mx25u2033e", INFO(0xc22532, 0, 64 * 1024, 4, SECT_4K) },
> { "mx25u3235f", INFO(0xc22536, 0, 64 * 1024, 64,
> SECT_4K | SPI_NOR_DUAL_READ |
> --
> 2.17.1
>
Re: [PATCH 1/1] spi: atmel: Put allocated master before return
On 1/20/21 7:00 AM, Pan Bian wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The allocated master is not released. Goto error handling label rather
> than directly return.
>
> Fixes: 04242ca4e891 ("spi: atmel: Use SPI core DMA mapping framework")
The correct fixes tag is:
Fixes: 5e9af37e46bc ("spi: atmel: introduce probe deferring")
With this addressed, one can add:
Reviewed-by: Tudor Ambarus
> Signed-off-by: Pan Bian
> ---
> drivers/spi/spi-atmel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 948396b382d7..f429436082af 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1590,7 +1590,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
> if (ret == 0) {
> as->use_dma = true;
> } else if (ret == -EPROBE_DEFER) {
> - return ret;
> + goto out_unmap_regs;
> }
> } else if (as->caps.has_pdc_support) {
> as->use_pdc = true;
> --
> 2.17.1
>
>
Re: [PATCH v2 2/2] mtd: spi-nor: sst: Add support for Global Unlock on sst26vf
On 1/20/21 5:02 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2021-01-20 15:52, schrieb tudor.amba...@microchip.com:
>> On 1/20/21 4:05 PM, Michael Walle wrote:
diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
index 00e48da0744a..d6e1396abb96 100644
--- a/drivers/mtd/spi-nor/sst.c
+++ b/drivers/mtd/spi-nor/sst.c
@@ -8,6 +8,39 @@
#include "core.h"
+static int sst26vf_lock(struct spi_nor *nor, loff_t ofs, uint64_t
len)
+{
+ return -EOPNOTSUPP;
+}
+
+static int sst26vf_unlock(struct spi_nor *nor, loff_t ofs, uint64_t
len)
+{
+ if (ofs == 0 && len == nor->params->size)
+ return spi_nor_global_block_unlock(nor);
>>>
>>>
>>> Some blocks might not be unlocked because they are permanently
>>> locked. Does it make sense to read BPNV of the control register
>>> and add a debug message here?
>>
>> It would, yes. If any block is permanently locked in the unlock_all
>> case,
>> I'll just print a dbg message and return -EINVAL. Sounds good?
>
> spi_nor_sr_unlock(), atmel_at25fs_unlock() and atmel_global_unprotect()
> will return -EIO in case the SR wasn't writable.
You mean in the spi_nor_write_sr_and_check() calls. -EIO is fine
there if what we wrote is different than what we read back, it would
indicate an IO error.
GBULK command clears all the write-protection bits in the Block
Protection register, except for those bits that have been permanently
locked down. So even if we have few blocks permanently locked, i.e.
CR.BPNV == 1, the GBULK can clear the protection for the remaining
blocks. So not really an IO error, but rather an -EINVAL, because
the user asks to unlock more than we can.
Cheers,
ta
Re: [PATCH v2 2/2] mtd: spi-nor: sst: Add support for Global Unlock on sst26vf
On 1/20/21 6:47 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2021-01-20 17:25, schrieb tudor.amba...@microchip.com:
>> On 1/20/21 5:49 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> Am 2021-01-20 16:39, schrieb tudor.amba...@microchip.com:
On 1/20/21 5:02 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know
> the content is safe
>
> Am 2021-01-20 15:52, schrieb tudor.amba...@microchip.com:
>> On 1/20/21 4:05 PM, Michael Walle wrote:
diff --git a/drivers/mtd/spi-nor/sst.c
b/drivers/mtd/spi-nor/sst.c
index 00e48da0744a..d6e1396abb96 100644
--- a/drivers/mtd/spi-nor/sst.c
+++ b/drivers/mtd/spi-nor/sst.c
@@ -8,6 +8,39 @@
#include "core.h"
+static int sst26vf_lock(struct spi_nor *nor, loff_t ofs,
uint64_t
len)
+{
+ return -EOPNOTSUPP;
+}
+
+static int sst26vf_unlock(struct spi_nor *nor, loff_t ofs,
uint64_t
len)
+{
+ if (ofs == 0 && len == nor->params->size)
+ return spi_nor_global_block_unlock(nor);
>>>
>>>
>>> Some blocks might not be unlocked because they are permanently
>>> locked. Does it make sense to read BPNV of the control register
>>> and add a debug message here?
>>
>> It would, yes. If any block is permanently locked in the unlock_all
>> case,
>> I'll just print a dbg message and return -EINVAL. Sounds good?
>
> spi_nor_sr_unlock(), atmel_at25fs_unlock() and
> atmel_global_unprotect()
> will return -EIO in case the SR wasn't writable.
You mean in the spi_nor_write_sr_and_check() calls. -EIO is fine
there if what we wrote is different than what we read back, it would
indicate an IO error.
GBULK command clears all the write-protection bits in the Block
Protection register, except for those bits that have been permanently
locked down. So even if we have few blocks permanently locked, i.e.
CR.BPNV == 1, the GBULK can clear the protection for the remaining
blocks. So not really an IO error, but rather an -EINVAL, because
the user asks to unlock more than we can.
>>>
>>> Doesn't EINVAL indicate wrong parameters, but does nothing? In this
>>> case, unlock would be partially successful.
>>>
>> yes, that's what I said I'll do: "If any block is permanently locked
>> in the unlock_all case, I'll just print a dbg message and return
>> -EINVAL",
>> without sending a GBULK cmd. Caller wrongly asks to unlock all, when we
>> can just unlock partial memory.
>
> Doh, I've missed that you will do it beforehand. Yes then EINVAL
> is fine by me.
>
> But you won't unlock the flash during startup (given the config option
> is enabled) if any blocks has been permanently locked. Thus if just the
> topmost 4k block is permanently locked down, the whole flash wouldn't be
> writable, right?. I don't have a strong opinion on that.
Correct. I don't see problems with that. Individual Block protection
with unlock on a smaller granularity can be added later on, and the
behavior during boot will remain the same.
Cheers,
ta
Re: [PATCH v2 2/2] mtd: spi-nor: sst: Add support for Global Unlock on sst26vf
On 1/20/21 5:49 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2021-01-20 16:39, schrieb tudor.amba...@microchip.com:
>> On 1/20/21 5:02 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> Am 2021-01-20 15:52, schrieb tudor.amba...@microchip.com:
On 1/20/21 4:05 PM, Michael Walle wrote:
>> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
>> index 00e48da0744a..d6e1396abb96 100644
>> --- a/drivers/mtd/spi-nor/sst.c
>> +++ b/drivers/mtd/spi-nor/sst.c
>> @@ -8,6 +8,39 @@
>>
>> #include "core.h"
>>
>> +static int sst26vf_lock(struct spi_nor *nor, loff_t ofs, uint64_t
>> len)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static int sst26vf_unlock(struct spi_nor *nor, loff_t ofs,
>> uint64_t
>> len)
>> +{
>> + if (ofs == 0 && len == nor->params->size)
>> + return spi_nor_global_block_unlock(nor);
>
>
> Some blocks might not be unlocked because they are permanently
> locked. Does it make sense to read BPNV of the control register
> and add a debug message here?
It would, yes. If any block is permanently locked in the unlock_all
case,
I'll just print a dbg message and return -EINVAL. Sounds good?
>>>
>>> spi_nor_sr_unlock(), atmel_at25fs_unlock() and
>>> atmel_global_unprotect()
>>> will return -EIO in case the SR wasn't writable.
>>
>> You mean in the spi_nor_write_sr_and_check() calls. -EIO is fine
>> there if what we wrote is different than what we read back, it would
>> indicate an IO error.
>>
>> GBULK command clears all the write-protection bits in the Block
>> Protection register, except for those bits that have been permanently
>> locked down. So even if we have few blocks permanently locked, i.e.
>> CR.BPNV == 1, the GBULK can clear the protection for the remaining
>> blocks. So not really an IO error, but rather an -EINVAL, because
>> the user asks to unlock more than we can.
>
> Doesn't EINVAL indicate wrong parameters, but does nothing? In this
> case, unlock would be partially successful.
>
yes, that's what I said I'll do: "If any block is permanently locked
in the unlock_all case, I'll just print a dbg message and return -EINVAL",
without sending a GBULK cmd. Caller wrongly asks to unlock all, when we
can just unlock partial memory.
It's similar to what is at:
https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/tree/drivers/mtd/spi-nor/core.c?h=spi-nor/next#n1946
> In any case, my point was that depending on the underlying locking
> ops, either -EIO or -EINVAL is returned if spi_nor_unlock() fails
> for the same reason, that is unlock() wasn't possible because of
> some sort of hardware write protection. And IMHO it should return
> the same errno (whatever the correct errno is in this case).
>
But the reasons are different: 1/caller wrongly asks to unlock
more than we can, thus -EINVAL 2/ -EIO when we don't read what
we expect to read.
Cheers,
ta
Re: [PATCH v2 2/2] mtd: spi-nor: sst: Add support for Global Unlock on sst26vf
On 1/20/21 4:05 PM, Michael Walle wrote:
>> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
>> index 00e48da0744a..d6e1396abb96 100644
>> --- a/drivers/mtd/spi-nor/sst.c
>> +++ b/drivers/mtd/spi-nor/sst.c
>> @@ -8,6 +8,39 @@
>>
>> #include "core.h"
>>
>> +static int sst26vf_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static int sst26vf_unlock(struct spi_nor *nor, loff_t ofs, uint64_t
>> len)
>> +{
>> + if (ofs == 0 && len == nor->params->size)
>> + return spi_nor_global_block_unlock(nor);
>
>
> Some blocks might not be unlocked because they are permanently
> locked. Does it make sense to read BPNV of the control register
> and add a debug message here?
It would, yes. If any block is permanently locked in the unlock_all case,
I'll just print a dbg message and return -EINVAL. Sounds good?
Cheers,
ta
Re: [PATCH 1/2] mtd: spi-nor: Add Global Block Unlock command
On 1/20/21 2:29 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Tudor,
Hi, Pratyush,
Thanks for reviewing this.
>
> On 20/01/21 12:54PM, Tudor Ambarus wrote:
>> The Global Block Unlock command has different names depending
>> on the manufacturer, but always the same command value: 0x98.
>> Macronix's MX25U12835F names it Gang Block Unlock, Winbound's
>> W25Q128FV names it Global Block Unlock and Microchip's
>> SST26VF064B names it Global Block Protection Unlock.
>>
>> Used in the Individual Block Protection mode, which is mutual
>
> Nitpick: s/mutual/mutually/
>
>> exclusive with the Block Protection mode (BP0-3).
>>
>> Signed-off-by: Tudor Ambarus
>> ---
>> drivers/mtd/spi-nor/core.c | 35 +++
>> drivers/mtd/spi-nor/core.h | 1 +
>> include/linux/mtd/spi-nor.h | 1 +
>> 3 files changed, 37 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index 20df44b753da..cb275608cb7f 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -853,6 +853,41 @@ int spi_nor_wait_till_ready(struct spi_nor *nor)
>>
>> DEFAULT_READY_WAIT_JIFFIES);
>> }
>>
>> +/**
>> + * spi_nor_global_block_unlock() - Unlock Global Block Protection.
>> + * @nor: pointer to 'struct spi_nor'.
>> + *
>> + * Return: 0 on success, -errno otherwise.
>> + */
>> +int spi_nor_global_block_unlock(struct spi_nor *nor)
>> +{
>> + int ret;
>> +
>> + ret = spi_nor_write_enable(nor);
>> + if (ret)
>> + return ret;
>> +
>> + if (nor->spimem) {
>> + struct spi_mem_op op =
>> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_GBULK, 1),
>
> Set the buswidth to 0...
>
>> +SPI_MEM_OP_NO_ADDR,
>> +SPI_MEM_OP_NO_DUMMY,
>> +SPI_MEM_OP_NO_DATA);
>
> ... and run the op through spi_nor_spimem_setup_op().
Right, I thought that SPINOR_OP_GBULK is available just in single SPI
mode, but I see it can be issued in QPI mode as well. Will change.
Cheers,
ta
>
> With this fixed,
>
> Reviewed-by: Pratyush Yadav
>
>> +
>> + ret = spi_mem_exec_op(nor->spimem, );
>> + } else {
>> + ret = spi_nor_controller_ops_write_reg(nor, SPINOR_OP_GBULK,
>> +NULL, 0);
>> + }
>> +
>> + if (ret) {
>> + dev_dbg(nor->dev, "error %d on Global Block Unlock\n", ret);
>> + return ret;
>> + }
>> +
>> + return spi_nor_wait_till_ready(nor);
>> +}
>> +
>> /**
>> * spi_nor_write_sr() - Write the Status Register.
>> * @nor: pointer to 'struct spi_nor'.
>> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
>> index d631ee299de3..eb26796db026 100644
>> --- a/drivers/mtd/spi-nor/core.h
>> +++ b/drivers/mtd/spi-nor/core.h
>> @@ -434,6 +434,7 @@ int spi_nor_write_disable(struct spi_nor *nor);
>> int spi_nor_set_4byte_addr_mode(struct spi_nor *nor, bool enable);
>> int spi_nor_write_ear(struct spi_nor *nor, u8 ear);
>> int spi_nor_wait_till_ready(struct spi_nor *nor);
>> +int spi_nor_global_block_unlock(struct spi_nor *nor);
>> int spi_nor_lock_and_prep(struct spi_nor *nor);
>> void spi_nor_unlock_and_unprep(struct spi_nor *nor);
>> int spi_nor_sr1_bit6_quad_enable(struct spi_nor *nor);
>> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
>> index d13958de6d8a..a0d572855444 100644
>> --- a/include/linux/mtd/spi-nor.h
>> +++ b/include/linux/mtd/spi-nor.h
>> @@ -53,6 +53,7 @@
>> #define SPINOR_OP_WREAR 0xc5/* Write Extended Address
>> Register */
>> #define SPINOR_OP_SRSTEN 0x66/* Software Reset Enable */
>> #define SPINOR_OP_SRST 0x99/* Software Reset */
>> +#define SPINOR_OP_GBULK 0x98/* Global Block Unlock */
>>
>> /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
>> #define SPINOR_OP_READ_4B0x13/* Read data bytes (low frequency) */
>
> --
> Regards,
> Pratyush Yadav
> Texas Instruments India
>
Re: [PATCH 2/2] mtd: spi-nor: sst: Add support for Global Unlock on sst26vf
On 1/20/21 2:29 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Tudor,
>
> On 20/01/21 12:54PM, Tudor Ambarus wrote:
>> Even if sst26vf shares the SPINOR_OP_GBULK opcode with
>> Macronix (ex. MX25U12835F) and Winbound (ex. W25Q128FV),
>> it has its own Individual Block Protection scheme, which
>> is also capable to read-lock individual parameter blocks.
>> Thus the sst26vf's Individual Block Protection scheme will
>> reside in the sst.c manufacturer driver.
>>
>> Add support to unlock the entire flash memory. The device
>> is write-protected by default after a power-on reset cycle
>> (volatile software protection), in order to avoid inadvertent
>> writes during power-up. Could do an erase, write, read back,
>> and compare when MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE=y.
>>
>> Signed-off-by: Tudor Ambarus
>> ---
>> drivers/mtd/spi-nor/sst.c | 38 --
>> 1 file changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
>> index 00e48da0744a..1cd2a360c41e 100644
>> --- a/drivers/mtd/spi-nor/sst.c
>> +++ b/drivers/mtd/spi-nor/sst.c
>> @@ -8,6 +8,39 @@
>>
>> #include "core.h"
>>
>> +static int sst26vf_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static int sst26vf_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
>> +{
>> + if (!ofs && len == nor->params->size)
>
> Nitpick: ofs is not a boolean value. Don't treat it as such. (ofs == 0
> && len == nor->params->size) makes the intent much clearer.
I agree, will change. Cheers,
ta
>
>> + return spi_nor_global_block_unlock(nor);
>> +
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static int sst26vf_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static const struct spi_nor_locking_ops sst26vf_locking_ops = {
>> + .lock = sst26vf_lock,
>> + .unlock = sst26vf_unlock,
>> + .is_locked = sst26vf_is_locked,
>> +};
>> +
>> +static void sst26vf_default_init(struct spi_nor *nor)
>> +{
>> + nor->params->locking_ops = _locking_ops;
>> +}
>> +
>> +static const struct spi_nor_fixups sst26vf_fixups = {
>> + .default_init = sst26vf_default_init,
>> +};
>> +
>> static const struct flash_info sst_parts[] = {
>> /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>> { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8,
>> @@ -39,8 +72,9 @@ static const struct flash_info sst_parts[] = {
>> { "sst26vf016b", INFO(0xbf2641, 0, 64 * 1024, 32,
>> SECT_4K | SPI_NOR_DUAL_READ) },
>> { "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128,
>> - SECT_4K | SPI_NOR_DUAL_READ |
>> - SPI_NOR_QUAD_READ) },
>> + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
>> + SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> + .fixups = _fixups },
>> };
>>
>> static int sst_write(struct mtd_info *mtd, loff_t to, size_t len,
>> --
>> 2.25.1
>>
>>
>> __
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
> --
> Regards,
> Pratyush Yadav
> Texas Instruments India
>
Re: [PATCH 4.19] dmaengine: at_hdmac: Fix memory leak
On 1/4/21 1:02 PM, Greg KH wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Wed, Sep 23, 2020 at 08:19:18AM +, tudor.amba...@microchip.com wrote:
>> On 9/23/20 11:13 AM, tudor.amba...@microchip.com wrote:
>>> Hi, Pavel,
>>>
>>> On 9/20/20 11:28 AM, Pavel Machek wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
This fixes memory leak in at_hdmac. Mainline does not have the same
problem.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 86427f6ba78c..0847b2055857 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -1714,8 +1714,10 @@ static struct dma_chan *at_dma_xlate(struct
of_phandle_args *dma_spec,
atslave->dma_dev = _pdev->dev;
chan = dma_request_channel(mask, at_dma_filter, atslave);
- if (!chan)
+ if (!chan) {
+ kfree(atslave);
return NULL;
+ }
>>>
>>> Thanks for submitting this to stable. While the fix is good, you can instead
>>> cherry-pick the commit that hit upstream. In order to do that cleanly on top
>>> of v4.19.145, you have to pick two other fixes:
>>>
>>> commit a6e7f19c9100 ("dmaengine: at_hdmac: Substitute kzalloc with kmalloc")
>>> commit 3832b78b3ec2 ("dmaengine: at_hdmac: add missing put_device() call in
>>> at_dma_xlate()")>>> commit a6e7f19c9100 ("dmaengine: at_hdmac: Substitute
>>> kzalloc with kmalloc")
>>
>> this last commit should have been
>> commit e097eb7473d9 ("dmaengine: at_hdmac: add missing kfree() call in
>> at_dma_xlate()")
>>
>> bad copy and paste :)
>
> So are all 3 of those needed on both 5.4.y and 4.19.y to resolve this
> issue?
>
Yes. I've just cherry-picked all three commits on both v5.4.86 and v4.19.164,
everything looks ok. I also compiled using sama5_defconfig, all good.
The order in which they should be taken is 1/ a6e7f19c9100, then 2/
3832b78b3ec2,
and 3/ e097eb7473d9.
Cheers,
ta
Re: [PATCH] mtd: spi-nor: winbond: Add support for w25q512jv
Hi, Shuhao,
On 11/11/20 3:45 AM, Shuhao Mai wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Add support for w25q512jv. This is of the same series chip with
> w25q256jv, which is already supported, but with size doubled and
> different JEDEC ID.
Where and how was this tested? Please add this info in the commit
message.
>
> Signed-off-by: Shuhao Mai
> ---
> drivers/mtd/spi-nor/winbond.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
> index e5dfa786f190..beaa6389e2dc 100644
> --- a/drivers/mtd/spi-nor/winbond.c
> +++ b/drivers/mtd/spi-nor/winbond.c
> @@ -97,6 +97,8 @@ static const struct flash_info winbond_parts[] = {
> SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> },
> { "w25m512jv", INFO(0xef7119, 0, 64 * 1024, 1024,
> SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ)
> },
> + { "w25q512jv", INFO(0xef4020, 0, 64 * 1024, 1024,
We should name it "w25q512jvq" in order to differentiate it to the
"M" version:
https://www.winbond.com/resource-files/W25Q512JV%20DTR%20RevD%2006292020%20133.pdf
The flash supports BP locking and we can enable it if you can test
the locking with mtd-utils. Not mandatory though.
Cheers,
ta
> + SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ)
> },
> };
>
> /**
> --
> 2.20.1
>
Re: [PATCH] Add spi-nor driver for Realtek RTL838x/RTL839x switch SoCs
On 12/15/20 11:46 PM, Bert Vermeulen wrote: > This driver supports the spiflash core in all RTL838x/RTL839x SoCs, > and likely some older models as well (RTL8196C). > Can we use SPIMEM and move this under drivers/spi/ instead? Cheers, ta > Signed-off-by: Bert Vermeulen > --- > drivers/mtd/spi-nor/controllers/Kconfig | 7 + > drivers/mtd/spi-nor/controllers/Makefile | 1 + > .../spi-nor/controllers/rtl8380-spiflash.c| 347 ++ > .../spi-nor/controllers/rtl8380-spiflash.h| 34 ++ > 4 files changed, 389 insertions(+) > create mode 100644 drivers/mtd/spi-nor/controllers/rtl8380-spiflash.c > create mode 100644 drivers/mtd/spi-nor/controllers/rtl8380-spiflash.h
Re: [PATCH] spi: Limit the spi device max speed to controller's max speed
On 12/15/20 4:24 PM, Geert Uytterhoeven wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Mark, Tudor,
Hi, Geert,
>
> On Fri, Dec 11, 2020 at 8:02 PM Mark Brown wrote:
>> On Wed, 9 Dec 2020 19:35:14 +0200, Tudor Ambarus wrote:
>>> Make sure the max_speed_hz of spi_device does not override
>>> the max_speed_hz of controller.
>>
>> Applied to
>>
>>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
>>
>> Thanks!
>>
>> [1/1] spi: Limit the spi device max speed to controller's max speed
>> commit: 9326e4f1e5dd1a4410c429638d3c412b6fc17040
>
>> - if (!spi->max_speed_hz)
>> + if (!spi->max_speed_hz ||
>> + spi->max_speed_hz > spi->controller->max_speed_hz)
>> spi->max_speed_hz = spi->controller->max_speed_hz;
>
> If spi->controller->max_speed_hz is zero, a non-zero spi->max_speed_hz
> will be overwritten by zero.
>
oh, yes, you're right.
> Hence this broke spi-sh-msiof, which has the following check in
> sh_msiof_spi_set_clk_regs():
>
> if (!spi_hz || !parent_rate) {
> WARN(1, "Invalid clock rate parameters %lu and %u\n",
> parent_rate, spi_hz);
> return;
> }
>
> Without this, the driver would trigger a division-by-zero later...
>
> Arguably all SPI controller drivers should fill in
> spi_controller.{min,max}_speed_hz, but as long as that is not the case,
> I think this patch should be reverted, or the check should be enhanced
> to make sure spi->controller->max_speed_hz is non-zero.
>
I'm fine both ways, since this should be improved anyway. Will send a patch
with the non-zero check and add your Reported-by, Suggested-by tags, in case
Mark decides to keep it.
Cheers,
ta
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
Re: Re: [PATCH] spi: Limit the spi device max speed to controller's max speed
On 12/10/20 5:33 PM, Mark Brown wrote: > On Thu, Dec 10, 2020 at 08:58:18AM +, tudor.amba...@microchip.com wrote: >> On 12/9/20 10:30 PM, Serge Semin wrote: > >> Right, in general we aim to do this sort of fixup on the transfers >> and messages rather than the devices, I guess we might be missing >> validation in some of the flash acceleration paths or was this an issue >> seen through inspection? > >> We miss validation for the SPI controllers that provide the >> spi_controller_mem_ops with its exec_op() method. In this case the SPI >> core does not check if the max_speed_hz of spi_device overrides the >> max_speed_hz of controller. > >> This was seen through inspection. There are octal SPI NOR flashes that >> can run at 400 MHZ, and I've also seen SPI controllers that are limited >> to 200 MHZ (microchip's sama7g5 octal SPI for example, which is not yet >> in mainline). > > Right, that's the hole :/ > Ideally the driver wouldn't have to check though (no harm in doing so of course). > >> Right. I thought of doing this in the SPI core, rather than doing in (each) >> controller driver. > > Yes, we should just make sure things are OK in the core as much as we > can so there's less work for driver authors. > >>> If so then we'd need to have a dedicated speed-related field in the >>> spi_mem_op structure, which would be accordingly initialized by the >>> SPI-mem core. > >> We do need a max_speed_hz in the SPIMEM, but probably for other purposes: >> NOR flashes, for example, can discover the maximum supported frequency >> at run-time, when parsing the jesd216 SFDP tables. One may consider that >> the run-time discovered max_speed_hz should have a higher precedence than >> what we fill with the spi-max-frequency dt property, because the >> manufacturers/jesd216 standard know/s better. Of course, if the >> manufacturers put a wrong max_speed_hz in the sfdp table, that can be >> updated at runtime with a fixup() hook, on a case by case basis. Other >> thing to consider here, is the max_speed_hz supported by the PCB. For >> example if the SPI flash supports 400 MHZ, the controller 200 MHZ, but >> the PCB only 180 MHZ, then we'll have to synchronize all three. But this >> seems like a discussion for other patch. > > The potential for board issues suggests that we should be taking the > minimum of what the board DT and runtime discovery say - if the board > limits things more than the parts we should assume that there's a system > integration limitation there. > >> Let me know if you think that this patch is ok for now. I can update the >> commit message if needed. > > It does work for now but it'd be nicer if we were doing this through > recording the decision on the transfer. > Ok, we can drop the patch, as nobody complained about this until now. I can work on a better approach. Are you saying that we should calibrate/adjust the maximum supported frequency on each operation/command? Most of the commands can work at the same frequency. I know an exception: on SPI NOR flashes, the jesd216 standard specifies that the READ SFDP command should be run at 50MHz, even though the rest of the commands/opcodes can run at a higher frequency. It is common that flashes can run this command at 50+ MHz, and nobody bothered about adjusting the frequency at run-time until now. That being said, maybe we can calibrate/adjust a generic max frequency for most of the commands and treat the exceptions on a per operation basis. Cheers, ta
Re: [PATCH] spi: Limit the spi device max speed to controller's max speed
Hi, Serge, Mark, On 12/9/20 10:30 PM, Serge Semin wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Wed, Dec 09, 2020 at 08:25:52PM +, Mark Brown wrote: >> On Wed, Dec 09, 2020 at 11:15:35PM +0300, Serge Semin wrote: >>> On Wed, Dec 09, 2020 at 07:54:20PM +, Mark Brown wrote: >> Right, in general we aim to do this sort of fixup on the transfers and messages rather than the devices, I guess we might be missing validation in some of the flash acceleration paths or was this an issue seen through inspection? We miss validation for the SPI controllers that provide the spi_controller_mem_ops with its exec_op() method. In this case the SPI core does not check if the max_speed_hz of spi_device overrides the max_speed_hz of controller. This was seen through inspection. There are octal SPI NOR flashes that can run at 400 MHZ, and I've also seen SPI controllers that are limited to 200 MHZ (microchip's sama7g5 octal SPI for example, which is not yet in mainline). >> >>> In case of DW SPI driver we just make sure the SPI-client device >>> speed set in the max_speed_hz doesn't exceed the controller SPI-bus >>> clock frequency and clamp it if it does. So the driver is safe in that >>> matter. >> > >> Ideally the driver wouldn't have to check though (no harm in doing so of >> course). Right. I thought of doing this in the SPI core, rather than doing in (each) controller driver. Serge, I've looked at https://elixir.bootlin.com/linux/v5.10-rc7/source/drivers/spi/spi.c#L3570 That limits the xfer speed hz to the controller's max_speed_hz. SPI controllers that implement the exec_op() optimized handler are not going through this path and are not covered by the check in __spi_validate(). > > If so then we'd need to have a dedicated speed-related field in the > spi_mem_op structure, which would be accordingly initialized by the > SPI-mem core. > We do need a max_speed_hz in the SPIMEM, but probably for other purposes: NOR flashes, for example, can discover the maximum supported frequency at run-time, when parsing the jesd216 SFDP tables. One may consider that the run-time discovered max_speed_hz should have a higher precedence than what we fill with the spi-max-frequency dt property, because the manufacturers/jesd216 standard know/s better. Of course, if the manufacturers put a wrong max_speed_hz in the sfdp table, that can be updated at runtime with a fixup() hook, on a case by case basis. Other thing to consider here, is the max_speed_hz supported by the PCB. For example if the SPI flash supports 400 MHZ, the controller 200 MHZ, but the PCB only 180 MHZ, then we'll have to synchronize all three. But this seems like a discussion for other patch. Let me know if you think that this patch is ok for now. I can update the commit message if needed. Cheers, ta
Re: [PATCH] mtd: spi-nor: macronix: enable 4-bit BP support for MX25L6405D
Hi, Sieng,
On 12/7/20 4:46 AM, Sieng Piaw Liew wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Enable 4-bit Block Protect support for MX256405D and its variants using
> the same ID.
>
> Tested on Innacom W3400V6 router with MX25L6406E chip.
:) What kind of tests did you exactly make?
> https://github.com/openwrt/openwrt/pull/3501
>
> Signed-off-by: Sieng Piaw Liew
> ---
> drivers/mtd/spi-nor/macronix.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
> index 9203abaac229..7aa8b1ee9daa 100644
> --- a/drivers/mtd/spi-nor/macronix.c
> +++ b/drivers/mtd/spi-nor/macronix.c
> @@ -42,7 +42,8 @@ static const struct flash_info macronix_parts[] = {
> { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32, SECT_4K) },
> { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, SECT_4K) },
> { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) },
> - { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, SECT_4K) },
> + { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128,
> + SECT_4K | SPI_NOR_4BIT_BP) },
I assume this won't work because it misses the SPI_NOR_HAS_LOCK flag.
Cheers,
ta
> { "mx25u2033e", INFO(0xc22532, 0, 64 * 1024, 4, SECT_4K) },
> { "mx25u3235f", INFO(0xc22536, 0, 64 * 1024, 64,
> SECT_4K | SPI_NOR_DUAL_READ |
> --
> 2.17.1
>
Re: [PATCH] mtd: spi-nor: winbond: Add support for w25m512jw
Hi, Lad, On 10/16/20 2:55 PM, Lad Prabhakar wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > This chip is (nearly) identical to the Winbond w25m512jv which is > already supported by Linux. Compared to the w25m512jv, the 'jw' > has a different JEDEC ID. W25M512JW-IQ (2 x 256M-bit) Serial MCP (Multi Chip Package) Flash memory, introduces a new “Software Die Select (C2h)” instruction, which we don't support. I guess you can't access the second die with what we have in mainline. Or am I wrong? We'll need to add support for multi-die support if we want to add new multi-die flashes. ta
Re: [PATCH v7 1/7] mtd: spi-nor: sst: fix BPn bits for the SST25VF064C
On 12/3/20 4:39 PM, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Am 2020-12-03 15:34, schrieb tudor.amba...@microchip.com: >> On 12/3/20 1:00 AM, Michael Walle wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know >>> the content is safe >>> >>> This flash part actually has 4 block protection bits. >>> >>> Reported-by: Tudor Ambarus >>> Cc: sta...@vger.kernel.org # v5.7+ >> >> While the patch is correct according to the datasheet, it was >> not tested, so it's not a candidate for stable. I would update >> the commit message to indicate that the the patch was made >> solely on datasheet info and not tested, I would add the fixes >> tag, and strip cc-ing to stable. > > What is the difference? Any commit with a Fixes tag will also land > in the stable trees. Just that it will cause compile errors for > kernel older than 5.7. > > So if you don't want to have it in stable then you must not add > a Fixes: tag either. > Documentation/process/stable-kernel-rules.rst doesn't say that the Fixes tag is a guarantee that a patch will hit the stable kernels. Since this patch was not tested, it's not a candidate for stable as per the first rule. It's a theoretical fix, because it should indeed fix the locking as per the datasheet. Even for theoretical fixes, I would like to know what commit broke the functionality, and that's why I asked for the Fixes tag. We don't want the patch in stable, so that's why I said that I would indicate in the commit message that it was not tested, and that I would strip the cc to stable. Maybe it's just my understanding. Others may help.
Re: [PATCH v7 7/7] mtd: spi-nor: keep lock bits if they are non-volatile
On 12/3/20 1:00 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Traditionally, linux unlocks the whole flash because there are legacy
> devices which has the write protections bits set by default at startup.
> If you actually want to use the flash protection bits, eg. because there
> is a read-only part for a bootloader, this automatic unlocking is
> harmful. If there is no hardware write protection in place (usually
> called WP#), a startup of the kernel just discards this protection.
>
> I've gone through the datasheets of all the flashes (except the Intel
> ones where I could not find any datasheet nor reference) which supports
> the unlocking feature and looked how the sector protection was
> implemented. The currently supported flashes can be divided into the
> following two categories:
> (1) block protection bits are non-volatile. Thus they keep their values
> at reset and power-cycle
> (2) flashes where these bits are volatile. After reset or power-cycle,
> the whole memory array is protected.
> (a) some devices needs a special "Global Unprotect" command, eg.
> the Atmel AT25DF041A.
> (b) some devices require to clear the BPn bits in the status
> register.
>
> Due to the reasons above, we do not want to clear the bits for flashes
> which belong to category (1). Fortunately for us, only Atmel flashes
> fall into category (2a). Implement the "Global Protect" and "Global
> Unprotect" commands for these. For (2b) we can use normal block
> protection locking scheme.
>
> This patch adds a new flag to indicate the case (2). Only if we have
> such a flash we unlock the whole flash array. To be backwards compatible
> it also introduces a kernel configuration option which restores the
> complete legacy behavior ("Disable write protection on any flashes").
> Hopefully, this will clean up "unlock the entire flash for legacy
> devices" once and for all.
>
> For reference here are the actually commits which introduced the legacy
> behavior (and extended the behavior to other chip manufacturers):
>
> commit f80e521c916cb ("mtd: m25p80: add support for the Intel/Numonyx
> {16,32,64}0S33B SPI flash chips")
> commit ea60658a08f8f ("mtd: m25p80: disable SST software protection bits by
> default")
> commit 7228982442365 ("[MTD] m25p80: fix bug - ATmel spi flash fails to be
> copied to")
>
> Actually, this might also fix handling of the Atmel AT25DF flashes,
> because the original commit 7228982442365 ("[MTD] m25p80: fix bug -
> ATmel spi flash fails to be copied to") was writing a 0 to the status
> register, which is a "Global Unprotect". This might not be the case in
> the current code which only handles the block protection bits BP2, BP1
> and BP0. Thus, it depends on the current contents of the status register
> if this unlock actually corresponds to a "Global Unprotect" command. In
> the worst case, the current code might leave the AT25DF flashes in a
> write protected state.
>
> The commit 191f5c2ed4b6f ("mtd: spi-nor: use 16-bit WRR command when QE
> is set on spansion flashes") changed that behavior by just clearing BP2
> to BP0 instead of writing a 0 to the status register.
>
> Further, the commit 3e0930f109e76 ("mtd: spi-nor: Rework the disabling
> of block write protection") expanded the unlock_all() feature to ANY
> flash which supports locking.
>
> Signed-off-by: Michael Walle
Reviewed-by: Tudor Ambarus
nice work, thanks!
> ---
> changes since v6:
> - fixed typos, small documentation changes
> - changed _WP_ to _SWP_, "write protection" to "software write
>protection"
> - use dev_dbg() instead of dev_err() to print message about WP pin
>
> changes since v5:
> - also set SRWD bit for the "Global Protect" command
> - use spi_nor_write_sr() instead of spi_nor_write_sr_and_check() to send
>the "Global Protect" or "Global Unprotect" command
> - mark ESMT F25L32QA as non-volatile as indicated in a newer datasheet
>revision
> - rebased to latest tree
>
> changes since v4:
> - made atmel_global_protection_default_init() static, spotted by
>l...@intel.com
>
> changes since v3:
> - now defaulting to MTD_SPI_NOR_WP_DISABLE_ON_VOLATILE, suggested by Vignesh
> - restored the original spi_nor_unlock_all(), instead add individual
>locking ops for the "Global Protect" scheme in atmel.c. This was tested
>partly with the AT25SL321 (for the test I added the fixups to this
>flash).
> - renamed SPI_NOR_UNPROTECT to SPI_NOR_WP_IS_VOLATILE. Suggested by
>Vingesh, although I've renamed it to a more general "WP_IS_VOLATILE"
>because either the BP bits or the individual sector locks might be
>volatile.
> - add mention of both block protection bits and "Global Unprotect" command
>in the Kconfig help text.
>
> changes since v2:
> - add Kconfig option to be able to retain legacy behavior
> - rebased the patch due to the spi-nor rewrite
> -
Re: [PATCH v7 6/7] mtd: spi-nor: atmel: fix unlock_all() for AT25FS010/040
On 12/3/20 1:00 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> These flashes have some weird BP bits mapping which aren't supported in
> the current locking code. Just add a simple unlock op to unprotect the
> entire flash array which is needed for legacy behavior.
>
> Signed-off-by: Michael Walle
With fixes tag added, one can add:
Reviewed-by: Tudor Ambarus
> ---
> changes since v6:
> - use spi_nor_write_sr_and_check() and log a debug message if writing
>fails
>
> changes since v5:
> - new patch
>
> drivers/mtd/spi-nor/atmel.c | 53 +++--
> drivers/mtd/spi-nor/core.c | 2 +-
> drivers/mtd/spi-nor/core.h | 1 +
> 3 files changed, 53 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c
> index 49d392c6c8bc..ee382a44bd0f 100644
> --- a/drivers/mtd/spi-nor/atmel.c
> +++ b/drivers/mtd/spi-nor/atmel.c
> @@ -8,10 +8,59 @@
>
> #include "core.h"
>
> +/*
> + * The Atmel AT25FS010/AT25FS040 parts have some weird configuration for the
> + * block protection bits. We don't support them. But legacy behavior in linux
> + * is to unlock the whole flash array on startup. Therefore, we have to
> support
> + * exactly this operation.
> + */
> +static int atmel_at25fs_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static int atmel_at25fs_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
> +{
> + int ret;
> +
> + /* We only support unlocking the whole flash array */
> + if (ofs || len != nor->params->size)
> + return -EINVAL;
> +
> + /* Write 0x00 to the status register to disable write protection */
> + ret = spi_nor_write_sr_and_check(nor, 0);
> + if (ret)
> + dev_dbg(nor->dev, "unable to clear BP bits, WP# asserted?\n");
> +
> + return ret;
> +}
> +
> +static int atmel_at25fs_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t
> len)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static const struct spi_nor_locking_ops atmel_at25fs_locking_ops = {
> + .lock = atmel_at25fs_lock,
> + .unlock = atmel_at25fs_unlock,
> + .is_locked = atmel_at25fs_is_locked,
> +};
> +
> +static void atmel_at25fs_default_init(struct spi_nor *nor)
> +{
> + nor->params->locking_ops = _at25fs_locking_ops;
> +}
> +
> +static const struct spi_nor_fixups atmel_at25fs_fixups = {
> + .default_init = atmel_at25fs_default_init,
> +};
> +
> static const struct flash_info atmel_parts[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> - { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K |
> SPI_NOR_HAS_LOCK) },
> - { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K |
> SPI_NOR_HAS_LOCK) },
> + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K |
> SPI_NOR_HAS_LOCK)
> + .fixups = _at25fs_fixups },
> + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K |
> SPI_NOR_HAS_LOCK)
> + .fixups = _at25fs_fixups },
>
> { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K |
> SPI_NOR_HAS_LOCK) },
> { "at25df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K |
> SPI_NOR_HAS_LOCK) },
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 013198abe929..6afcb99e9741 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1049,7 +1049,7 @@ static int spi_nor_write_16bit_cr_and_check(struct
> spi_nor *nor, u8 cr)
> *
> * Return: 0 on success, -errno otherwise.
> */
> -static int spi_nor_write_sr_and_check(struct spi_nor *nor, u8 sr1)
> +int spi_nor_write_sr_and_check(struct spi_nor *nor, u8 sr1)
> {
> if (nor->flags & SNOR_F_HAS_16BIT_SR)
> return spi_nor_write_16bit_sr_and_check(nor, sr1);
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 0a775a7b5606..7780169d485b 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -430,6 +430,7 @@ void spi_nor_unlock_and_unprep(struct spi_nor *nor);
> int spi_nor_sr1_bit6_quad_enable(struct spi_nor *nor);
> int spi_nor_sr2_bit1_quad_enable(struct spi_nor *nor);
> int spi_nor_sr2_bit7_quad_enable(struct spi_nor *nor);
> +int spi_nor_write_sr_and_check(struct spi_nor *nor, u8 sr1);
>
> int spi_nor_xread_sr(struct spi_nor *nor, u8 *sr);
> ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t from, size_t len,
> --
> 2.20.1
>
Re: [PATCH v7 1/7] mtd: spi-nor: sst: fix BPn bits for the SST25VF064C
On 12/3/20 1:00 AM, Michael Walle wrote:
> --- a/drivers/mtd/spi-nor/sst.c
> +++ b/drivers/mtd/spi-nor/sst.c
> @@ -18,7 +18,8 @@ static const struct flash_info sst_parts[] = {
> SECT_4K | SST_WRITE) },
> { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64,
> SECT_4K | SST_WRITE) },
> - { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
> + { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128,
> + SECT_4K | SPI_NOR_4BIT_BP) },
And I would put 1/7 after 4/7, so that I can set the locking flags
in some order: SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP. We first indicate
that the flash supports locking, and then what kind of locking, BP3,
and not the other way around.
anyway, just cosmetics
Re: [PATCH v7 2/7] mtd: spi-nor: ignore errors in spi_nor_unlock_all()
On 12/3/20 1:00 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Just try to unlock the whole SPI-NOR flash array. Don't abort the
> probing in case of an error. Justifications:
> (1) For some boards, this just works because
> spi_nor_write_16bit_sr_and_check() is broken and just checks the
> second half of the 16bit. Once that will be fixed, SPI probe will
> fail for boards which has hardware-write protected SPI-NOR flashes.
> (2) Until now, hardware write-protection was the only viable solution
> to use the block protection bits. This is because this very
> function spi_nor_unlock_all() will be called unconditionally on
> every linux boot. Therefore, this bits only makes sense in
> combination with the hardware write-protection. If we would fail
> the SPI probe on an error in spi_nor_unlock_all() we'd break
> virtually all users of the block protection bits.
> (3) We should try hard to keep the MTD working even if the flash might
> not be writable/erasable.
>
> Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write
> protection")
> Signed-off-by: Michael Walle
Reviewed-by: Tudor Ambarus
> ---
> changes since v6:
> - new patch
>
> drivers/mtd/spi-nor/core.c | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 5bee7c8da4dc..013198abe929 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3121,20 +3121,27 @@ static int spi_nor_quad_enable(struct spi_nor *nor)
> }
>
> /**
> - * spi_nor_unlock_all() - Unlocks the entire flash memory array.
> + * spi_nor_try_unlock_all() - Tries to unlock the entire flash memory array.
> * @nor: pointer to a 'struct spi_nor'.
> *
> * Some SPI NOR flashes are write protected by default after a power-on reset
> * cycle, in order to avoid inadvertent writes during power-up. Backward
> * compatibility imposes to unlock the entire flash memory array at power-up
> * by default.
> + *
> + * Unprotecting the entire flash array will fail for boards which are
> hardware
> + * write-protected. Thus any errors are ignored.
> */
> -static int spi_nor_unlock_all(struct spi_nor *nor)
> +static void spi_nor_try_unlock_all(struct spi_nor *nor)
> {
> - if (nor->flags & SNOR_F_HAS_LOCK)
> - return spi_nor_unlock(>mtd, 0, nor->params->size);
> + int ret;
>
> - return 0;
> + if (!(nor->flags & SNOR_F_HAS_LOCK))
> + return;
> +
> + ret = spi_nor_unlock(>mtd, 0, nor->params->size);
> + if (ret)
> + dev_dbg(nor->dev, "Failed to unlock the entire flash memory
> array\n");
> }
>
> static int spi_nor_init(struct spi_nor *nor)
> @@ -3153,11 +3160,7 @@ static int spi_nor_init(struct spi_nor *nor)
> return err;
> }
>
> - err = spi_nor_unlock_all(nor);
> - if (err) {
> - dev_dbg(nor->dev, "Failed to unlock the entire flash memory
> array\n");
> - return err;
> - }
> + spi_nor_try_unlock_all(nor);
>
> if (nor->addr_width == 4 &&
> nor->read_proto != SNOR_PROTO_8_8_8_DTR &&
> --
> 2.20.1
>
Re: [PATCH v7 1/7] mtd: spi-nor: sst: fix BPn bits for the SST25VF064C
On 12/3/20 1:00 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This flash part actually has 4 block protection bits.
>
> Reported-by: Tudor Ambarus
> Cc: sta...@vger.kernel.org # v5.7+
While the patch is correct according to the datasheet, it was
not tested, so it's not a candidate for stable. I would update
the commit message to indicate that the the patch was made
solely on datasheet info and not tested, I would add the fixes
tag, and strip cc-ing to stable.
> Signed-off-by: Michael Walle
With the above addressed:
Reviewed-by: Tudor Ambarus
> ---
> I didn't add the Fixes: tag because we depend on the 4bit BP support which
> was introduced in 5.7.
>
> changes since v6:
> - new patch
>
> drivers/mtd/spi-nor/sst.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
> index e0af6d25d573..0ab07624fb73 100644
> --- a/drivers/mtd/spi-nor/sst.c
> +++ b/drivers/mtd/spi-nor/sst.c
> @@ -18,7 +18,8 @@ static const struct flash_info sst_parts[] = {
> SECT_4K | SST_WRITE) },
> { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64,
> SECT_4K | SST_WRITE) },
> - { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
> + { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128,
> + SECT_4K | SPI_NOR_4BIT_BP) },
> { "sst25wf512", INFO(0xbf2501, 0, 64 * 1024, 1,
> SECT_4K | SST_WRITE) },
> { "sst25wf010", INFO(0xbf2502, 0, 64 * 1024, 2,
> --
> 2.20.1
>
Re: [PATCH v6 5/5] mtd: spi-nor: keep lock bits if they are non-volatile
On 12/2/20 1:25 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2020-12-02 12:10, schrieb tudor.amba...@microchip.com:
>> On 11/30/20 4:38 PM, Michael Walle wrote:
> [..]
> + * indicated by SNOR_F_WP_IS_VOLATILE.
> + */
> + if (IS_ENABLED(CONFIG_MTD_SPI_NOR_WP_DISABLE) ||
> + (IS_ENABLED(CONFIG_MTD_SPI_NOR_WP_DISABLE_ON_VOLATILE)
> &&
> + nor->flags & SNOR_F_WP_IS_VOLATILE)) {
> + err = spi_nor_unlock_all(nor);
> + if (err) {
> + dev_err(nor->dev, "Failed to unlock the
> entire
> flash memory array\n");
dev_dbg for low level info
>>>
>>> Is this low level info or an actual error? Which raises the question:
>>> should spi_nor_unlock_all() in case SWRD couldn't be cleared and thus
>>> should all the spi_nor_init fail of this? Or should it rather be a
>>
>> yes, it should, because the flash will not work as expected/requested.
>
> One counterargument: take our sl28 board, it has a hardware
> write-protected
> SPI flash. It actually works right now because the write_sr_and_check()
> doesn't work as intended and doesn't check what is written. So if you'd
> fix that (and these changes would be backported to the stable trees),
> you'd
> basically break spi-nor on these boards. And this _must_ be the case for
> all boards which are actually using (hard- or sofware) write-protection.
> That is the only way write-protection makes sense prior to this patch
> series. Because linux will happily unlock every flash on startup.
> Therefore,
> the hardware write protection is the only measure against this.
>
I see. If WP# is asserted, spi_nor_unlock_all() would fail and would stop
the execution. One can avoid the fail by choosing MTD_SPI_NOR_SWP_KEEP,
but that would not be backward compatible. Having in mind that in the
past the unlock all was just a zero written to SR, without checking if
the write was successful, I would now say that your proposal with the
soft error if fair. Even if writes and erases will not work in case WP#
is asserted, we would at least let users do reads. The writes and erases
problems would be caught when enabling the debug traces. So please go
ahead and print just a dev_dbg when spi_nor_unlock_all() fails, without
stopping the execution.
Cheers,
ta
Re: [PATCH v2] mtd: spi-nor: Fix multiple typos
On 11/30/20 5:24 PM, Jonathan Neuschäfer wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> There are a few typos in comments in the SPI NOR framework; fix them.
>
> Signed-off-by: Jonathan Neuschäfer
> ---
> drivers/mtd/spi-nor/core.c | 4 ++--
> drivers/mtd/spi-nor/sfdp.c | 2 +-
> include/linux/mtd/spi-nor.h | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index f0ae7a01703a1..b224b275125a3 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1447,7 +1447,7 @@ static int spi_nor_erase_multi_sectors(struct spi_nor
> *nor, u64 addr, u32 len)
>
> /*
> * Erase an address range on the nor chip. The address range may extend
> - * one or more erase sectors. Return an error is there is a problem erasing.
> + * one or more erase sectors. Return an error if there is a problem erasing.
There's a double space before "Return" that could be trimmed.
Maybe Vignesh will do it when applying. It's good to see typos
fixed, thanks.
Reviewed-by: Tudor Ambarus
> */
> static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
> {
> @@ -2537,7 +2537,7 @@ spi_nor_select_uniform_erase(struct spi_nor_erase_map
> *map,
> }
>
> /*
> -* Otherwise, the current erase size is still a valid
> canditate.
> +* Otherwise, the current erase size is still a valid
> candidate.
> * Select the biggest valid candidate.
> */
> if (!erase && tested_erase->size)
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index e2a43d39eb5f4..05b22c6576832 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -59,7 +59,7 @@ struct sfdp_bfpt_read {
>
> struct sfdp_bfpt_erase {
> /*
> -* The half-word at offset in DWORD encodes the
> +* The half-word at offset in DWORD encodes the
> * op code and erase sector size to be used by Sector Erase commands.
> */
> u32 dword;
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 60bac2c0ec456..582ee04eeea20 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -406,7 +406,7 @@ static inline struct device_node
> *spi_nor_get_flash_node(struct spi_nor *nor)
> * @name: the chip type name
> * @hwcaps:the hardware capabilities supported by the controller driver
> *
> - * The drivers can use this fuction to scan the SPI NOR.
> + * The drivers can use this function to scan the SPI NOR.
> * In the scanning, it will try to get all the necessary information to
> * fill the mtd_info{} and the spi_nor{}.
> *
> --
> 2.29.2
>
Re: [PATCH v6 5/5] mtd: spi-nor: keep lock bits if they are non-volatile
On 11/30/20 4:38 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2020-11-28 11:17, schrieb tudor.amba...@microchip.com:
>> On 11/26/20 10:26 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> Traditionally, linux unlocks the whole flash because there are legacy
>>> devices which has the write protections bits set by default at
>>> startup.
>>> If you actually want to use the flash protection bits, eg. because
>>> there
>>> is a read-only part for a bootloader, this automatic unlocking is
>>> harmful. If there is no hardware write protection in place (usually
>>> called WP#), a startup of the kernel just discards this protection.
>>>
>>> I've gone through the datasheets of all the flashes (except the Intel
>>> ones where I could not find any datasheet nor reference) which
>>> supports
>>> the unlocking feature and looked how the sector protection was
>>> implemented. The currently supported flashes can be divided into the
>>> following two categories:
>>> (1) block protection bits are non-volatile. Thus they keep their
>>> values
>>> at reset and power-cycle
>>> (2) flashes where these bits are volatile. After reset or
>>> power-cycle,
>>> the whole memory array is protected.
>>> (a) some devices needs a special "Global Unprotect" command, eg.
>>> the Atmel AT25DF041A.
>>> (b) some devices require to clear the BPn bits in the status
>>> register.
>>>
>>> Due to the reasons above, we do not want to clear the bits for flashes
>>> which belong to category (1). Fortunately for us, only Atmel flashes
>>> fall into category (2a). Implement the "Global Protect" and "Global
>>> Unprotect" commands for these. For (2b) we can use normal block
>>> protection locking scheme.
>>>
>>> This patch adds a new flag to indicate the case (2). Only if we have
>>> such a flash we unlock the whole flash array. To be backwards
>>> compatible
>>> it also introduces a kernel configuration option which restores the
>>> complete legacy behavior ("Disable write protection on any flashes").
>>> Hopefully, this will clean up "unlock the entire flash for legacy
>>> devices" once and for all.
>>>
>>> For reference here are the actually commits which introduced the
>>> legacy
>>> behaviour (and extended the behaviour to other chip manufacturers):
>>
>> typo: behavior
>>
>>>
>>> commit f80e521c916cb ("mtd: m25p80: add support for the Intel/Numonyx
>>> {16,32,64}0S33B SPI flash chips")
>>> commit ea60658a08f8f ("mtd: m25p80: disable SST software protection
>>> bits by default")
>>> commit 7228982442365 ("[MTD] m25p80: fix bug - ATmel spi flash fails
>>> to be copied to")
>>>
>>> Actually, this might also fix handling of the Atmel AT25DF flashes,
>>> because the original commit 7228982442365 ("[MTD] m25p80: fix bug -
>>> ATmel spi flash fails to be copied to") was writing a 0 to the status
>>> register, which is a "Global Unprotect". This might not be the case in
>>> the current code which only handles the block protection bits BP2, BP1
>>> and BP0. Thus, it depends on the current contents of the status
>>> register
>>> if this unlock actually corresponds to a "Global Unprotect" command.
>>> In
>>> the worst case, the current code might leave the AT25DF flashes in a
>>> write protected state.
>>>
>>> The commit 191f5c2ed4b6f ("mtd: spi-nor: use 16-bit WRR command when
>>> QE
>>> is set on spansion flashes") changed that behaviour by just clearing
>>> BP2
>>> to BP0 instead of writing a 0 to the status register.
>>>
>>> Further, the commit 3e0930f109e76 ("mtd: spi-nor: Rework the disabling
>>> of block write protection") expanded the unlock_all() feature to ANY
>>> flash which supports locking.
>>>
>>> Signed-off-by: Michael Walle
>>> ---
>>> changes since v5:
>>> - also set SRWD bit for the "Global Protect" command
>>> - use spi_nor_write_sr() instead of spi_nor_write_sr_and_check() to
>>> send
>>> the "Global Protect" or "Global Unprotect" command
>>> - mark ESMT F25L32QA as non-volatile as indicated in a newer
>>> datasheet
>>> revision
>>> - rebased to latest tree
>>>
>>> changes since v4:
>>> - made atmel_global_protection_default_init() static, spotted by
>>> l...@intel.com
>>>
>>> changes since v3:
>>> - now defaulting to MTD_SPI_NOR_WP_DISABLE_ON_VOLATILE, suggested by
>>> Vignesh
>>> - restored the original spi_nor_unlock_all(), instead add individual
>>> locking ops for the "Global Protect" scheme in atmel.c. This was
>>> tested
>>> partly with the AT25SL321 (for the test I added the fixups to this
>>> flash).
>>> - renamed SPI_NOR_UNPROTECT to SPI_NOR_WP_IS_VOLATILE. Suggested by
>>> Vingesh, although I've renamed it to a more general
>>> "WP_IS_VOLATILE"
>>> because either the BP bits or the individual sector locks might be
>>> volatile.
>>> - add mention of both block protection bits and "Global
Re: [PATCH v6 4/5] mtd: spi-nor: atmel: Fix unlock_all() for AT25FS010/040
On 11/30/20 4:16 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2020-11-28 09:25, schrieb tudor.amba...@microchip.com:
>> On 11/26/20 10:26 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> These flashes have some weird BP bits mapping which aren't supported
>>> in
>>> the current locking code. Just add a simple unlock op to unprotect the
>>> entire flash array which is needed for legacy behavior.
>>>
>>> Signed-off-by: Michael Walle
>>> ---
>>> changes since v5
>>> - new patch
>>>
>>> drivers/mtd/spi-nor/atmel.c | 53
>>> +++--
>>> drivers/mtd/spi-nor/core.c | 2 +-
>>> drivers/mtd/spi-nor/core.h | 1 +
>>> 3 files changed, 53 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c
>>> index 49d392c6c8bc..fe6a4653823d 100644
>>> --- a/drivers/mtd/spi-nor/atmel.c
>>> +++ b/drivers/mtd/spi-nor/atmel.c
>>> @@ -8,10 +8,59 @@
>>>
>>> #include "core.h"
>>>
>>> +/*
>>> + * The Atmel AT25FS010/AT25FS040 parts have some weird configuration
>>> for the
>>> + * block protection bits. We don't support them. But legacy behaviour
>>> in linux
>>> + * is to unlock the whole flash array on startup. Therefore, we have
>>> to support
>>> + * exactly this operation.
>>> + */
>>> +static int atmel_at25fs_lock(struct spi_nor *nor, loff_t ofs,
>>> uint64_t len)
>>> +{
>>> + return -EOPNOTSUPP;
>>> +}
>>> +
>>> +static int atmel_at25fs_unlock(struct spi_nor *nor, loff_t ofs,
>>> uint64_t len)
>>> +{
>>> + /* We only support unlocking the whole flash array */
>>> + if (ofs || len != nor->params->size)
>>> + return -EINVAL;
>>> +
>>> + /*
>>> + * Write 0x00 to the status register to try to disable the
>>> write
>>> + * protection. This will fail if SRWD (the datasheet calls it
>>> WPEN) is
>>> + * set. But there is nothing we can do.
>>> + */
>>
>> can't we do the same as you did in 5/5?
>
> Sure, but - assuming it is only used for the legacy unlock all operation
> - the
> outcome will be the same. It will either keep being locked or all will
> be
> unlocked.
In case WP# is asserted, we'll catch this via the dev_dbg message in
spi_nor_write_sr_and_check() when trying to clear the SRWD bit. We will
have an idea of what's going on, instead of a silent fail to unlock.
>
> That being said, I can also change it to the same as the
> global_unprotect().
> I don't have any option on that other than this is simpler.
>
> -michael
Re: [PATCH v2 2/3] mtd: spi-nor: core: Allow flashes to specify MTD writesize
On 11/18/20 8:24 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Some flashes like the Cypress S28 family use ECC. Under this ECC scheme,
> multi-pass writes to an ECC block is not allowed. In other words, once
> data is programmed to an ECC block, it can't be programmed again without
> erasing it first.
>
> Upper layers like file systems need to be given this information so they
> do not cause error conditions on the flash by attempting multi-pass
> programming. This can be done by setting 'writesize' in 'struct
> mtd_info'.
>
> Set the default to 1 but allow flashes to modify it in fixup hooks. If
> more flashes show up with this constraint in the future it might be
> worth it to add it to 'struct flash_info', but for now increasing its
> size is not worth it.
>
> Signed-off-by: Pratyush Yadav
> ---
>
> Notes:
> New in v2.
>
> drivers/mtd/spi-nor/core.c | 4 +++-
> drivers/mtd/spi-nor/core.h | 3 +++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 5bee7c8da4dc..80fbcb9c0828 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3054,6 +3054,8 @@ static int spi_nor_init_params(struct spi_nor *nor)
> if (!nor->params)
> return -ENOMEM;
>
> + nor->params->writesize = 1;
> +
please do default inits in spi_nor_info_init_params(). A good place would be:
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2885,6 +2885,7 @@ static void spi_nor_info_init_params(struct spi_nor *nor)
nor->flags |= SNOR_F_HAS_16BIT_SR;
/* Set SPI NOR sizes. */
+ params->writesize = 1;
params->size = (u64)info->sector_size * info->n_sectors;
params->page_size = info->page_size;
> spi_nor_info_init_params(nor);
>
> spi_nor_manufacturer_init_params(nor);
> @@ -3430,7 +3432,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> mtd->name = dev_name(dev);
> mtd->priv = nor;
> mtd->type = MTD_NORFLASH;
> - mtd->writesize = 1;
> + mtd->writesize = nor->params->writesize;
> mtd->flags = MTD_CAP_NORFLASH;
> mtd->size = nor->params->size;
> mtd->_erase = spi_nor_erase;
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 0a775a7b5606..413ea311e632 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -197,6 +197,8 @@ struct spi_nor_locking_ops {
> * @rdsr_dummy:dummy cycles needed for Read Status Register
> command.
> * @rdsr_addr_nbytes: dummy address bytes needed for Read Status Register
> * command.
> + * @writesize Minimal writable flash unit size. Defaults to 1. Set
> to
> + * ECC unit size for ECC-ed flashes.
> * @hwcaps:describes the read and page program hardware
> * capabilities.
> * @reads: read capabilities ordered by priority: the higher
> index
> @@ -222,6 +224,7 @@ struct spi_nor_flash_parameter {
> u32 page_size;
I would put writesize before or after page_size, because they are related.
Also, it would probably avoid padding.
With these addressed, one can add:
Reviewed-by: Tudor Ambarus
> u8 rdsr_dummy;
> u8 rdsr_addr_nbytes;
> + u32 writesize;
>
> struct spi_nor_hwcaps hwcaps;
> struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
> --
> 2.28.0
>
Re: [PATCH v2 1/3] UBI: Do not zero out EC and VID on ECC-ed NOR flashes
On 11/18/20 8:24 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> For NOR flashes EC and VID are zeroed out before an erase is issued to
> make sure UBI does not mistakenly treat the PEB as used and associate it
> with an LEB.
>
> But on some flashes, like the Cypress Semper S28 SPI NOR flash family,
> multi-pass page programming is not allowed on the default ECC scheme.
> This means zeroing out these magic numbers will result in the flash
> throwing a page programming error.
>
> Do not zero out EC and VID for such flashes. A writesize > 1 is an
> indication of an ECC-ed flash.
>
> Signed-off-by: Pratyush Yadav
> ---
>
> Notes:
> Changes in v2:
>
> - Use mtd->writesize to check if multi-pass programming can be done
> instead of using MTD_NO_MULTI_PASS_WRITE.
> - Remove the assertion that a NOR flash most have writesize of 1.
>
> drivers/mtd/ubi/build.c | 4 +---
> drivers/mtd/ubi/io.c| 9 -
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
> index e85b04e9716b..25fd7816b1f4 100644
> --- a/drivers/mtd/ubi/build.c
> +++ b/drivers/mtd/ubi/build.c
> @@ -628,10 +628,8 @@ static int io_init(struct ubi_device *ubi, int
> max_beb_per1024)
> ubi->bad_peb_limit = get_bad_peb_limit(ubi, max_beb_per1024);
> }
>
> - if (ubi->mtd->type == MTD_NORFLASH) {
> - ubi_assert(ubi->mtd->writesize == 1);
> + if (ubi->mtd->type == MTD_NORFLASH)
> ubi->nor_flash = 1;
> - }
>
> ubi->min_io_size = ubi->mtd->writesize;
> ubi->hdrs_min_io_size = ubi->mtd->writesize >> ubi->mtd->subpage_sft;
> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
> index 14d890b00d2c..2f3312c31e51 100644
> --- a/drivers/mtd/ubi/io.c
> +++ b/drivers/mtd/ubi/io.c
> @@ -535,7 +535,14 @@ int ubi_io_sync_erase(struct ubi_device *ubi, int pnum,
> int torture)
> return -EROFS;
> }
>
> - if (ubi->nor_flash) {
> + /*
> +* If the flash is ECC-ed then we have to erase the ECC block before
> we
> +* can write to it. But the write is in preparation to an erase in the
> +* first place. This means we cannot zero out EC and VID before the
> +* erase and we just have to hope the flash starts erasing from the
> +* start of the page.
> +*/
> + if (ubi->nor_flash && ubi->mtd->writesize == 1) {
Are there any SPI NORs with ECC block size of 4 bytes? Should we call
nor_erase_prepare() in this case?
Anyway, there's none in SPI NOR as of now, so:
Reviewed-by: Tudor Ambarus
> err = nor_erase_prepare(ubi, pnum);
> if (err)
> return err;
> --
> 2.28.0
>
Re: [PATCH v2 3/3] mtd: spi-nor: spansion: Set ECC block size
On 11/18/20 8:24 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The S28 flash family uses 2-bit ECC by default with each ECC block being
> 16 bytes. Under this scheme multi-pass programming to an ECC block is
> not allowed. Set the writesize to make sure multi-pass programming is
> not attempted on the flash.
>
> Signed-off-by: Pratyush Yadav
Reviewed-by: Tudor Ambarus
> ---
>
> Notes:
> New in v2.
>
> drivers/mtd/spi-nor/spansion.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
> index e487fd341a56..b0c5521c1e27 100644
> --- a/drivers/mtd/spi-nor/spansion.c
> +++ b/drivers/mtd/spi-nor/spansion.c
> @@ -109,6 +109,7 @@ static int spi_nor_cypress_octal_dtr_enable(struct
> spi_nor *nor, bool enable)
> static void s28hs512t_default_init(struct spi_nor *nor)
> {
> nor->params->octal_dtr_enable = spi_nor_cypress_octal_dtr_enable;
> + nor->params->writesize = 16;
> }
>
> static void s28hs512t_post_sfdp_fixup(struct spi_nor *nor)
> --
> 2.28.0
>
Re: [PATCH v6 5/5] mtd: spi-nor: keep lock bits if they are non-volatile
On 11/26/20 10:26 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Traditionally, linux unlocks the whole flash because there are legacy
> devices which has the write protections bits set by default at startup.
> If you actually want to use the flash protection bits, eg. because there
> is a read-only part for a bootloader, this automatic unlocking is
> harmful. If there is no hardware write protection in place (usually
> called WP#), a startup of the kernel just discards this protection.
>
> I've gone through the datasheets of all the flashes (except the Intel
> ones where I could not find any datasheet nor reference) which supports
> the unlocking feature and looked how the sector protection was
> implemented. The currently supported flashes can be divided into the
> following two categories:
> (1) block protection bits are non-volatile. Thus they keep their values
> at reset and power-cycle
> (2) flashes where these bits are volatile. After reset or power-cycle,
> the whole memory array is protected.
> (a) some devices needs a special "Global Unprotect" command, eg.
> the Atmel AT25DF041A.
> (b) some devices require to clear the BPn bits in the status
> register.
>
> Due to the reasons above, we do not want to clear the bits for flashes
> which belong to category (1). Fortunately for us, only Atmel flashes
> fall into category (2a). Implement the "Global Protect" and "Global
> Unprotect" commands for these. For (2b) we can use normal block
> protection locking scheme.
>
> This patch adds a new flag to indicate the case (2). Only if we have
> such a flash we unlock the whole flash array. To be backwards compatible
> it also introduces a kernel configuration option which restores the
> complete legacy behavior ("Disable write protection on any flashes").
> Hopefully, this will clean up "unlock the entire flash for legacy
> devices" once and for all.
>
> For reference here are the actually commits which introduced the legacy
> behaviour (and extended the behaviour to other chip manufacturers):
typo: behavior
>
> commit f80e521c916cb ("mtd: m25p80: add support for the Intel/Numonyx
> {16,32,64}0S33B SPI flash chips")
> commit ea60658a08f8f ("mtd: m25p80: disable SST software protection bits by
> default")
> commit 7228982442365 ("[MTD] m25p80: fix bug - ATmel spi flash fails to be
> copied to")
>
> Actually, this might also fix handling of the Atmel AT25DF flashes,
> because the original commit 7228982442365 ("[MTD] m25p80: fix bug -
> ATmel spi flash fails to be copied to") was writing a 0 to the status
> register, which is a "Global Unprotect". This might not be the case in
> the current code which only handles the block protection bits BP2, BP1
> and BP0. Thus, it depends on the current contents of the status register
> if this unlock actually corresponds to a "Global Unprotect" command. In
> the worst case, the current code might leave the AT25DF flashes in a
> write protected state.
>
> The commit 191f5c2ed4b6f ("mtd: spi-nor: use 16-bit WRR command when QE
> is set on spansion flashes") changed that behaviour by just clearing BP2
> to BP0 instead of writing a 0 to the status register.
>
> Further, the commit 3e0930f109e76 ("mtd: spi-nor: Rework the disabling
> of block write protection") expanded the unlock_all() feature to ANY
> flash which supports locking.
>
> Signed-off-by: Michael Walle
> ---
> changes since v5:
> - also set SRWD bit for the "Global Protect" command
> - use spi_nor_write_sr() instead of spi_nor_write_sr_and_check() to send
>the "Global Protect" or "Global Unprotect" command
> - mark ESMT F25L32QA as non-volatile as indicated in a newer datasheet
>revision
> - rebased to latest tree
>
> changes since v4:
> - made atmel_global_protection_default_init() static, spotted by
>l...@intel.com
>
> changes since v3:
> - now defaulting to MTD_SPI_NOR_WP_DISABLE_ON_VOLATILE, suggested by Vignesh
> - restored the original spi_nor_unlock_all(), instead add individual
>locking ops for the "Global Protect" scheme in atmel.c. This was tested
>partly with the AT25SL321 (for the test I added the fixups to this
>flash).
> - renamed SPI_NOR_UNPROTECT to SPI_NOR_WP_IS_VOLATILE. Suggested by
>Vingesh, although I've renamed it to a more general "WP_IS_VOLATILE"
>because either the BP bits or the individual sector locks might be
>volatile.
> - add mention of both block protection bits and "Global Unprotect" command
>in the Kconfig help text.
>
> changes since v2:
> - add Kconfig option to be able to retain legacy behaviour
> - rebased the patch due to the spi-nor rewrite
> - dropped the Fixes: tag, it doens't make sense after the spi-nor rewrite
> - mention commit 3e0930f109e76 which further modified the unlock
>behaviour.
>
> changes since v1:
> - completely rewrote patch, the first version used a device tree
Re: [PATCH v6 4/5] mtd: spi-nor: atmel: Fix unlock_all() for AT25FS010/040
On 11/26/20 10:26 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> These flashes have some weird BP bits mapping which aren't supported in
> the current locking code. Just add a simple unlock op to unprotect the
> entire flash array which is needed for legacy behavior.
>
> Signed-off-by: Michael Walle
> ---
> changes since v5
> - new patch
>
> drivers/mtd/spi-nor/atmel.c | 53 +++--
> drivers/mtd/spi-nor/core.c | 2 +-
> drivers/mtd/spi-nor/core.h | 1 +
> 3 files changed, 53 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c
> index 49d392c6c8bc..fe6a4653823d 100644
> --- a/drivers/mtd/spi-nor/atmel.c
> +++ b/drivers/mtd/spi-nor/atmel.c
> @@ -8,10 +8,59 @@
>
> #include "core.h"
>
> +/*
> + * The Atmel AT25FS010/AT25FS040 parts have some weird configuration for the
> + * block protection bits. We don't support them. But legacy behaviour in
> linux
> + * is to unlock the whole flash array on startup. Therefore, we have to
> support
> + * exactly this operation.
> + */
> +static int atmel_at25fs_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static int atmel_at25fs_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
> +{
> + /* We only support unlocking the whole flash array */
> + if (ofs || len != nor->params->size)
> + return -EINVAL;
> +
> + /*
> +* Write 0x00 to the status register to try to disable the write
> +* protection. This will fail if SRWD (the datasheet calls it WPEN) is
> +* set. But there is nothing we can do.
> +*/
can't we do the same as you did in 5/5?
+ ret = spi_nor_read_sr(nor, nor->bouncebuf);
+ if (ret)
+ return ret;
+
+ sr = nor->bouncebuf[0];
+
+ if (sr & SR_SRWD) {
+ sr &= ~SR_SRWD;
+ ret = spi_nor_write_sr_and_check(nor, sr);
+ if (ret)
+ return ret;
+ }
If SRWD is set to 1, we first try to set it to 0. If WP# is asserted, we
will catch this in spi_nor_write_sr_and_check()
> + nor->bouncebuf[0] = 0;
> +
> + return spi_nor_write_sr(nor, nor->bouncebuf, 1);
and then you can use spi_nor_write_sr_and_check here
> +}
> +
> +static int atmel_at25fs_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t
> len)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static const struct spi_nor_locking_ops atmel_at25fs_locking_ops = {
> + .lock = atmel_at25fs_lock,
> + .unlock = atmel_at25fs_unlock,
> + .is_locked = atmel_at25fs_is_locked,
> +};
> +
> +static void atmel_at25fs_default_init(struct spi_nor *nor)
> +{
> + nor->params->locking_ops = _at25fs_locking_ops;
> +}
> +
> +static const struct spi_nor_fixups atmel_at25fs_fixups = {
> + .default_init = atmel_at25fs_default_init,
> +};
> +
> static const struct flash_info atmel_parts[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> - { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K |
> SPI_NOR_HAS_LOCK) },
> - { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K |
> SPI_NOR_HAS_LOCK) },
> + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K |
> SPI_NOR_HAS_LOCK)
> + .fixups = _at25fs_fixups },
> + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K |
> SPI_NOR_HAS_LOCK)
> + .fixups = _at25fs_fixups },
>
> { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K |
> SPI_NOR_HAS_LOCK) },
> { "at25df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K |
> SPI_NOR_HAS_LOCK) },
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 5bee7c8da4dc..8c06a28a90de 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -861,7 +861,7 @@ int spi_nor_wait_till_ready(struct spi_nor *nor)
> *
> * Return: 0 on success, -errno otherwise.
> */
> -static int spi_nor_write_sr(struct spi_nor *nor, const u8 *sr, size_t len)
> +int spi_nor_write_sr(struct spi_nor *nor, const u8 *sr, size_t len)
> {
> int ret;
>
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 0a775a7b5606..16b350e1d865 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -430,6 +430,7 @@ void spi_nor_unlock_and_unprep(struct spi_nor *nor);
> int spi_nor_sr1_bit6_quad_enable(struct spi_nor *nor);
> int spi_nor_sr2_bit1_quad_enable(struct spi_nor *nor);
> int spi_nor_sr2_bit7_quad_enable(struct spi_nor *nor);
> +int spi_nor_write_sr(struct spi_nor *nor, const u8 *sr, size_t len);
>
> int spi_nor_xread_sr(struct spi_nor *nor, u8 *sr);
> ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t from, size_t len,
> --
> 2.20.1
>
Re: [PATCH v6 3/5] mtd: spi-nor: intel: remove global protection flag
On 11/26/20 10:26 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> For the Atmel and SST parts this flag was already moved to individual
> flash parts because it is considered bad esp. because newer flash chips
> will automatically inherit the "has locking" support. While this won't
> likely be the case for the Intel parts, we do it for consistency
> reasons.
>
> Signed-off-by: Michael Walle
Reviewed-by: Tudor Ambarus
> ---
> changes since v5
> - new patch
>
> drivers/mtd/spi-nor/intel.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/intel.c b/drivers/mtd/spi-nor/intel.c
> index d8196f101368..6c31bef3fc60 100644
> --- a/drivers/mtd/spi-nor/intel.c
> +++ b/drivers/mtd/spi-nor/intel.c
> @@ -10,23 +10,13 @@
>
> static const struct flash_info intel_parts[] = {
> /* Intel/Numonyx -- xxxs33b */
> - { "160s33b", INFO(0x898911, 0, 64 * 1024, 32, 0) },
> - { "320s33b", INFO(0x898912, 0, 64 * 1024, 64, 0) },
> - { "640s33b", INFO(0x898913, 0, 64 * 1024, 128, 0) },
> -};
> -
> -static void intel_default_init(struct spi_nor *nor)
> -{
> - nor->flags |= SNOR_F_HAS_LOCK;
> -}
> -
> -static const struct spi_nor_fixups intel_fixups = {
> - .default_init = intel_default_init,
> + { "160s33b", INFO(0x898911, 0, 64 * 1024, 32, SPI_NOR_HAS_LOCK) },
> + { "320s33b", INFO(0x898912, 0, 64 * 1024, 64, SPI_NOR_HAS_LOCK) },
> + { "640s33b", INFO(0x898913, 0, 64 * 1024, 128, SPI_NOR_HAS_LOCK) },
> };
>
> const struct spi_nor_manufacturer spi_nor_intel = {
> .name = "intel",
> .parts = intel_parts,
> .nparts = ARRAY_SIZE(intel_parts),
> - .fixups = _fixups,
> };
> --
> 2.20.1
>
Re: [PATCH v5 1/3] mtd: spi-nor: atmel: remove global protection flag
On 11/25/20 8:17 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2020-11-24 20:09, schrieb tudor.amba...@microchip.com:
>> On 10/3/20 6:32 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> This is considered bad for the following reasons:
>>> (1) We only support the block protection with BPn bits for write
>>> protection. Not all Atmel parts support this.
>>> (2) Newly added flash chip will automatically inherit the "has
>>> locking" support and thus needs to explicitly tested. Better
>>> be opt-in instead of opt-out.
>>> (3) There are already supported flashes which doesn't support
>>> the locking scheme. So I assume this wasn't properly tested
>>> before adding that chip; which enforces my previous argument
>>> that locking support should be an opt-in.
>>>
>>> Remove the global flag and add individual flags to all flashes which
>>> supports BP locking. In particular the following flashes don't support
>>> the BP scheme:
>>> - AT26F004
>>> - AT25SL321
>>> - AT45DB081D
>>>
>>> Please note, that some flashes which are marked as SPI_NOR_HAS_LOCK
>>> just
>>> support Global Protection, i.e. not our supported block protection
>>> locking scheme. This is to keep backwards compatibility with the
>>> current "unlock all at boot" mechanism. In particular the following
>>> flashes doesn't have BP bits:
>>> - AT25DF041A
>>> - AT25DF321
>>> - AT25DF321A
>>> - AT25DF641
>>> - AT26DF081A
>>> - AT26DF161A
>>> - AT26DF321
>>>
>>> Signed-off-by: Michael Walle
>>
>> Reviewed-by: Tudor Ambarus
>>
>>> ---
>>> changes since v4:
>>> - none
>>>
>>> changes since v3/v2/v1:
>>> - there was no such version because this patch was bundled with
>>> another
>>> patch
>>>
>>> changes since RFC:
>>> - mention the flashes which just support the "Global Unprotect" in
>>> the
>>> commit message
>>>
>>> drivers/mtd/spi-nor/atmel.c | 28 +---
>>> 1 file changed, 9 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c
>>> index 3f5f21a473a6..49d392c6c8bc 100644
>>> --- a/drivers/mtd/spi-nor/atmel.c
>>> +++ b/drivers/mtd/spi-nor/atmel.c
>>> @@ -10,37 +10,27 @@
>>>
>>> static const struct flash_info atmel_parts[] = {
>>> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
>>> - { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
>>> - { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
>>> + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K |
>>> SPI_NOR_HAS_LOCK) },
>>
>> https://datasheetspdf.com/pdf-file/587164/ATMELCorporation/AT25FS010/1
>> BP bits are at bit 2, 3, 5 and 6.
>> BP0, BP1, BP3, BP4 and WPEN, are nonvolatile cells
>>
>>> + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K |
>>> SPI_NOR_HAS_LOCK) },
>>
>> https://datasheetspdf.com/pdf-file/587165/ATMELCorporation/AT25FS040/1
>> BP bits are at bit 2, 3, 4, 5, and 6.
>> BP0, BP1, BP2, BP3, BP4 are nonvolatile cells
>>
>>>
>>> - { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
>>> - { "at25df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
>>> - { "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
>>> - { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
>>> + { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K |
>>> SPI_NOR_HAS_LOCK) },
>>
>> https://datasheetspdf.com/pdf-file/975331/Adesto/AT25DF041A/1
>> Global Protect/Unprotect using Write SR command:
>> Global Unlock: write 0x00 to SR
>> Global Lock: Read SR. If SR.SPRL is 1 write 0xff to SR, else write
>> 0x7f.
>
> That is not my understanding. Quote:
> To perform a Global Protect, the appropriate WP pin and SPRL
> conditions must be met, and the system must write a logical “1”
> to bits 5, 4, 3, and 2 of the Status Register.
>
> And
> Conversely, to per-form a Global Unprotect, the same WP and SPRL
> conditions must be met but the system must write a logical “0” to
> bits 5, 4, 3, and 2 of the Status Register
>
> Keep in mind that bit 5, 4, 3 and 2 is exactly the
> ATMEL_SR_GLOBAL_PROTECT_MASK. The SPRL bit is handled in the unlock()
> function. Accoring to table 9.2 you also have to first disable the SPRL
> bit and then write the BP bits to zero.
>
We took this on irc, I try to summarize the conclusions:
1/ for global unlock protect we have to first set SPRL to zero, if not already
set, then to set the BP bits to zero
2/ for global lock protect, SPRL and BP bits should be written in one shot
3/ consider WP#: set SPRL to 1 when something is locked, set it to zero
if nothing is locked.
4/ at25fs010 and at25fs040 have a BPn mechanism that uses BP4, similar to
what we have in spi_nor_sr_locking_ops(). We decided that it doesn't worth
to pollute the core function just
Re: [PATCH v5 3/3] mtd: spi-nor: keep lock bits if they are non-volatile
On 11/25/20 8:52 PM, Michael Walle wrote:
>> Looks like BP3 is needed here.
>
> https://ww1.microchip.com/downloads/en/DeviceDoc/20005036C.pdf
>
> agreed. But again cannot test it. Would add it as a seperate patch
> to this series. (or leave it like it is)
Separate patch for the TB/BP3 bits is fine. We should add a fixes tag
for the patch that introduced the bug:
commit 3e0930f109e76 ("mtd: spi-nor: Rework the disabling of block write
protection")
cheers,
ta
Re: [PATCH v5 1/3] mtd: spi-nor: atmel: remove global protection flag
On 11/26/20 2:45 PM, Tudor Ambarus - M18064 wrote:
> On 11/25/20 8:17 PM, Michael Walle wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> Am 2020-11-24 20:09, schrieb tudor.amba...@microchip.com:
>>> On 10/3/20 6:32 PM, Michael Walle wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know
the content is safe
This is considered bad for the following reasons:
(1) We only support the block protection with BPn bits for write
protection. Not all Atmel parts support this.
(2) Newly added flash chip will automatically inherit the "has
locking" support and thus needs to explicitly tested. Better
be opt-in instead of opt-out.
(3) There are already supported flashes which doesn't support
the locking scheme. So I assume this wasn't properly tested
before adding that chip; which enforces my previous argument
that locking support should be an opt-in.
Remove the global flag and add individual flags to all flashes which
supports BP locking. In particular the following flashes don't support
the BP scheme:
- AT26F004
- AT25SL321
- AT45DB081D
Please note, that some flashes which are marked as SPI_NOR_HAS_LOCK
just
support Global Protection, i.e. not our supported block protection
locking scheme. This is to keep backwards compatibility with the
current "unlock all at boot" mechanism. In particular the following
flashes doesn't have BP bits:
- AT25DF041A
- AT25DF321
- AT25DF321A
- AT25DF641
- AT26DF081A
- AT26DF161A
- AT26DF321
Signed-off-by: Michael Walle
>>>
>>> Reviewed-by: Tudor Ambarus
>>>
---
changes since v4:
- none
changes since v3/v2/v1:
- there was no such version because this patch was bundled with
another
patch
changes since RFC:
- mention the flashes which just support the "Global Unprotect" in
the
commit message
drivers/mtd/spi-nor/atmel.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c
index 3f5f21a473a6..49d392c6c8bc 100644
--- a/drivers/mtd/spi-nor/atmel.c
+++ b/drivers/mtd/spi-nor/atmel.c
@@ -10,37 +10,27 @@
static const struct flash_info atmel_parts[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
- { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
+ { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K |
SPI_NOR_HAS_LOCK) },
>>>
>>> https://datasheetspdf.com/pdf-file/587164/ATMELCorporation/AT25FS010/1
>>> BP bits are at bit 2, 3, 5 and 6.
>>> BP0, BP1, BP3, BP4 and WPEN, are nonvolatile cells
>>>
+ { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K |
SPI_NOR_HAS_LOCK) },
>>>
>>> https://datasheetspdf.com/pdf-file/587165/ATMELCorporation/AT25FS040/1
>>> BP bits are at bit 2, 3, 4, 5, and 6.
>>> BP0, BP1, BP2, BP3, BP4 are nonvolatile cells
>>>
- { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
- { "at25df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
- { "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
- { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
+ { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K |
SPI_NOR_HAS_LOCK) },
>>>
>>> https://datasheetspdf.com/pdf-file/975331/Adesto/AT25DF041A/1
>>> Global Protect/Unprotect using Write SR command:
>>> Global Unlock: write 0x00 to SR
>>> Global Lock: Read SR. If SR.SPRL is 1 write 0xff to SR, else write
>>> 0x7f.
>>
>> That is not my understanding. Quote:
>> To perform a Global Protect, the appropriate WP pin and SPRL
>> conditions must be met, and the system must write a logical “1”
>> to bits 5, 4, 3, and 2 of the Status Register.
>>
>> And
>> Conversely, to per-form a Global Unprotect, the same WP and SPRL
>> conditions must be met but the system must write a logical “0” to
>> bits 5, 4, 3, and 2 of the Status Register
>>
>
> Right. I think we are both correct, and we should choose one method
> or the other depending on the level of support we want to introduce.
> If we want "locking ops", i.e. partial or full lock and unlock of the
> flash, we'll go your way. If we want to keep things as they were before
> 3e0930f109e76, we'll just support the global unlock by writing 0x00 to SR.
I'm wrong, please ignore. I mixed BP locking with individual sector protection.
Let me read again.
Re: [PATCH v5 1/3] mtd: spi-nor: atmel: remove global protection flag
On 11/25/20 8:17 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2020-11-24 20:09, schrieb tudor.amba...@microchip.com:
>> On 10/3/20 6:32 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> This is considered bad for the following reasons:
>>> (1) We only support the block protection with BPn bits for write
>>> protection. Not all Atmel parts support this.
>>> (2) Newly added flash chip will automatically inherit the "has
>>> locking" support and thus needs to explicitly tested. Better
>>> be opt-in instead of opt-out.
>>> (3) There are already supported flashes which doesn't support
>>> the locking scheme. So I assume this wasn't properly tested
>>> before adding that chip; which enforces my previous argument
>>> that locking support should be an opt-in.
>>>
>>> Remove the global flag and add individual flags to all flashes which
>>> supports BP locking. In particular the following flashes don't support
>>> the BP scheme:
>>> - AT26F004
>>> - AT25SL321
>>> - AT45DB081D
>>>
>>> Please note, that some flashes which are marked as SPI_NOR_HAS_LOCK
>>> just
>>> support Global Protection, i.e. not our supported block protection
>>> locking scheme. This is to keep backwards compatibility with the
>>> current "unlock all at boot" mechanism. In particular the following
>>> flashes doesn't have BP bits:
>>> - AT25DF041A
>>> - AT25DF321
>>> - AT25DF321A
>>> - AT25DF641
>>> - AT26DF081A
>>> - AT26DF161A
>>> - AT26DF321
>>>
>>> Signed-off-by: Michael Walle
>>
>> Reviewed-by: Tudor Ambarus
>>
>>> ---
>>> changes since v4:
>>> - none
>>>
>>> changes since v3/v2/v1:
>>> - there was no such version because this patch was bundled with
>>> another
>>> patch
>>>
>>> changes since RFC:
>>> - mention the flashes which just support the "Global Unprotect" in
>>> the
>>> commit message
>>>
>>> drivers/mtd/spi-nor/atmel.c | 28 +---
>>> 1 file changed, 9 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c
>>> index 3f5f21a473a6..49d392c6c8bc 100644
>>> --- a/drivers/mtd/spi-nor/atmel.c
>>> +++ b/drivers/mtd/spi-nor/atmel.c
>>> @@ -10,37 +10,27 @@
>>>
>>> static const struct flash_info atmel_parts[] = {
>>> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
>>> - { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
>>> - { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
>>> + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K |
>>> SPI_NOR_HAS_LOCK) },
>>
>> https://datasheetspdf.com/pdf-file/587164/ATMELCorporation/AT25FS010/1
>> BP bits are at bit 2, 3, 5 and 6.
>> BP0, BP1, BP3, BP4 and WPEN, are nonvolatile cells
>>
>>> + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K |
>>> SPI_NOR_HAS_LOCK) },
>>
>> https://datasheetspdf.com/pdf-file/587165/ATMELCorporation/AT25FS040/1
>> BP bits are at bit 2, 3, 4, 5, and 6.
>> BP0, BP1, BP2, BP3, BP4 are nonvolatile cells
>>
>>>
>>> - { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
>>> - { "at25df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
>>> - { "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
>>> - { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
>>> + { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K |
>>> SPI_NOR_HAS_LOCK) },
>>
>> https://datasheetspdf.com/pdf-file/975331/Adesto/AT25DF041A/1
>> Global Protect/Unprotect using Write SR command:
>> Global Unlock: write 0x00 to SR
>> Global Lock: Read SR. If SR.SPRL is 1 write 0xff to SR, else write
>> 0x7f.
>
> That is not my understanding. Quote:
> To perform a Global Protect, the appropriate WP pin and SPRL
> conditions must be met, and the system must write a logical “1”
> to bits 5, 4, 3, and 2 of the Status Register.
>
> And
> Conversely, to per-form a Global Unprotect, the same WP and SPRL
> conditions must be met but the system must write a logical “0” to
> bits 5, 4, 3, and 2 of the Status Register
>
Right. I think we are both correct, and we should choose one method
or the other depending on the level of support we want to introduce.
If we want "locking ops", i.e. partial or full lock and unlock of the
flash, we'll go your way. If we want to keep things as they were before
3e0930f109e76, we'll just support the global unlock by writing 0x00 to SR.
Here's what I followed in the datasheet:
'''
Essentially, if the SPRL bit of the Status Register is in the logical “0”
state (Sector Protection Registers are not locked), then writing a 00h
to the Status Register will perform a Global Unprotect without changing
the state of the SPRL bit. Similarly, writing a 7Fh to the Status Register
will perform a Global Protect and keep the SPRL bit in the logical “0” state.
Re: [PATCH v5 3/3] mtd: spi-nor: keep lock bits if they are non-volatile
On 10/3/20 6:32 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Traditionally, linux unlocks the whole flash because there are legacy
> devices which has the write protections bits set by default at startup.
> If you actually want to use the flash protection bits, eg. because there
> is a read-only part for a bootloader, this automatic unlocking is
> harmful. If there is no hardware write protection in place (usually
> called WP#), a startup of the kernel just discards this protection.
>
> I've gone through the datasheets of all the flashes (except the Intel
> ones where I could not find any datasheet nor reference) which supports
> the unlocking feature and looked how the sector protection was
> implemented. The currently supported flashes can be divided into the
> following two categories:
> (1) block protection bits are non-volatile. Thus they keep their values
> at reset and power-cycle
> (2) flashes where these bits are volatile. After reset or power-cycle,
> the whole memory array is protected.
> (a) some devices needs a special "Global Unprotect" command, eg.
> the Atmel AT25DF041A.
> (b) some devices require to clear the BPn bits in the status
> register.
>
> Due to the reasons above, we do not want to clear the bits for flashes
> which belong to category (1). Fortunately for us, only Atmel flashes
> fall into category (2a). Implement the "Global Protect" and "Global
> Unprotect" commands for these. For (2b) we can use normal block
> protection locking scheme.
>
> This patch adds a new flag to indicate the case (2). Only if we have
> such a flash we unlock the whole flash array. To be backwards compatible
> it also introduces a kernel configuration option which restores the
> complete legacy behavior ("Disable write protection on any flashes").
> Hopefully, this will clean up "unlock the entire flash for legacy
> devices" once and for all.
>
> For reference here are the actually commits which introduced the legacy
> behaviour (and extended the behaviour to other chip manufacturers):
>
> commit f80e521c916cb ("mtd: m25p80: add support for the Intel/Numonyx
> {16,32,64}0S33B SPI flash chips")
> commit ea60658a08f8f ("mtd: m25p80: disable SST software protection bits by
> default")
> commit 7228982442365 ("[MTD] m25p80: fix bug - ATmel spi flash fails to be
> copied to")
>
> Actually, this might also fix handling of the Atmel AT25DF flashes,
> because the original commit 7228982442365 ("[MTD] m25p80: fix bug -
> ATmel spi flash fails to be copied to") was writing a 0 to the status
> register, which is a "Global Unprotect". This might not be the case in
> the current code which only handles the block protection bits BP2, BP1
> and BP0. Thus, it depends on the current contents of the status register
> if this unlock actually corresponds to a "Global Unprotect" command. In
> the worst case, the current code might leave the AT25DF flashes in a
> write protected state.
>
> The commit 191f5c2ed4b6f ("mtd: spi-nor: use 16-bit WRR command when QE
> is set on spansion flashes") changed that behaviour by just clearing BP2
> to BP0 instead of writing a 0 to the status register.
>
> Further, the commit 3e0930f109e76 ("mtd: spi-nor: Rework the disabling
> of block write protection") expanded the unlock_all() feature to ANY
> flash which supports locking.
>
> Signed-off-by: Michael Walle
> ---
> changes since v4:
> - made atmel_global_protection_default_init() static, spotted by
>l...@intel.com
>
> changes since v3:
> - now defaulting to MTD_SPI_NOR_WP_DISABLE_ON_VOLATILE, suggested by Vignesh
> - restored the original spi_nor_unlock_all(), instead add individual
>locking ops for the "Global Protect" scheme in atmel.c. This was tested
>partly with the AT25SL321 (for the test I added the fixups to this
>flash).
> - renamed SPI_NOR_UNPROTECT to SPI_NOR_WP_IS_VOLATILE. Suggested by
>Vingesh, although I've renamed it to a more general "WP_IS_VOLATILE"
>because either the BP bits or the individual sector locks might be
>volatile.
> - add mention of both block protection bits and "Global Unprotect" command
>in the Kconfig help text.
>
> changes since v2:
> - add Kconfig option to be able to retain legacy behaviour
> - rebased the patch due to the spi-nor rewrite
> - dropped the Fixes: tag, it doens't make sense after the spi-nor rewrite
> - mention commit 3e0930f109e76 which further modified the unlock
>behaviour.
>
> changes since v1:
> - completely rewrote patch, the first version used a device tree flag
>
> drivers/mtd/spi-nor/Kconfig | 42 ++
> drivers/mtd/spi-nor/atmel.c | 111 +---
> drivers/mtd/spi-nor/core.c | 36
> drivers/mtd/spi-nor/core.h | 8 +++
> drivers/mtd/spi-nor/esmt.c | 8 ++-
> drivers/mtd/spi-nor/intel.c | 6 +-
> drivers/mtd/spi-nor/sst.c | 21
Re: [PATCH v5 2/3] mtd: spi-nor: sst: remove global protection flag
On 10/3/20 6:32 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This is considered bad for the following reasons:
> (1) We only support the block protection with BPn bits for write
> protection. Not all SST parts support this.
> (2) Newly added flash chip will automatically inherit the "has
> locking" support and thus needs to explicitly tested. Better
> be opt-in instead of opt-out.
> (3) There are already supported flashes which doesn't support
> the locking scheme. So I assume this wasn't properly tested
> before adding that chip; which enforces my previous argument
> that locking support should be an opt-in.
>
> Remove the global flag and add individual flags to all flashes
> which supports BP locking. In particular the following flashes
> don't support the BP scheme:
> - SST26VF016B
> - SST26WF016B
> - SST26VF064B
>
> Signed-off-by: Michael Walle
Reviewed-by: Tudor Ambarus
> ---
> changes since v4:
> - none
>
> changes since v3/v2/v1:
> - there was no such version because this patch was bundled with another
>patch
>
> changes since RFC:
> - none
>
> drivers/mtd/spi-nor/sst.c | 30 --
> 1 file changed, 12 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
> index e0af6d25d573..8b169fa4102a 100644
> --- a/drivers/mtd/spi-nor/sst.c
> +++ b/drivers/mtd/spi-nor/sst.c
> @@ -11,26 +11,26 @@
> static const struct flash_info sst_parts[] = {
> /* SST -- large erase sizes are "overlays", "sectors" are 4K */
> { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8,
> - SECT_4K | SST_WRITE) },
> + SECT_4K | SST_WRITE | SPI_NOR_HAS_LOCK) },
https://ww1.microchip.com/downloads/en/DeviceDoc/DS20005051D.pdf
BP GENMASK(2, 5), volatile, after power up BP0-2 set to 1, BP3 set to 0.
BP3 is "don't care".
SR.BPL BIT(7) volatile, default to 0. When 1 - BPs are read-only bits,
when 0 - BPs are r/w
> { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16,
> - SECT_4K | SST_WRITE) },
> + SECT_4K | SST_WRITE | SPI_NOR_HAS_LOCK) },
https://ww1.microchip.com/downloads/en/DeviceDoc/20005045C.pdf
same as in sst25vf040b
> { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32,
> - SECT_4K | SST_WRITE) },
> + SECT_4K | SST_WRITE | SPI_NOR_HAS_LOCK) },
https://ww1.microchip.com/downloads/en/DeviceDoc/20005044C.pdf
same as in sst25vf040b
> { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64,
> - SECT_4K | SST_WRITE) },
> - { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
> + SECT_4K | SST_WRITE | SPI_NOR_HAS_LOCK) },
https://ww1.microchip.com/downloads/en/DeviceDoc/20005071B.pdf
same as in sst25vf040b
> + { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K |
> SPI_NOR_HAS_LOCK) },
https://ww1.microchip.com/downloads/en/devicedoc/20005036c.pdf
BP GENMASK(2, 5), volatile, after power up all set to 1.
SR.BPL BIT(7) volatile, default to 0. When 1 - BPs are read-only bits,
when 0 - BPs are r/w
> { "sst25wf512", INFO(0xbf2501, 0, 64 * 1024, 1,
> - SECT_4K | SST_WRITE) },
> + SECT_4K | SST_WRITE | SPI_NOR_HAS_LOCK) },
https://ww1.microchip.com/downloads/en/DeviceDoc/20005016C.pdf
BP GENMASK(2, 4), volatile, after power up all set to 1.
SR.BPL BIT(7) volatile, default to 0. When 1 - BPs are read-only bits,
when 0 - BPs are r/w
> { "sst25wf010", INFO(0xbf2502, 0, 64 * 1024, 2,
> - SECT_4K | SST_WRITE) },
> + SECT_4K | SST_WRITE | SPI_NOR_HAS_LOCK) },
same datasheet and characteristics as in sst25wf512
> { "sst25wf020", INFO(0xbf2503, 0, 64 * 1024, 4,
> - SECT_4K | SST_WRITE) },
> - { "sst25wf020a", INFO(0x621612, 0, 64 * 1024, 4, SECT_4K) },
> - { "sst25wf040b", INFO(0x621613, 0, 64 * 1024, 8, SECT_4K) },
> + SECT_4K | SST_WRITE | SPI_NOR_HAS_LOCK) },
same datasheet and characteristics as in sst25wf512
> + { "sst25wf020a", INFO(0x621612, 0, 64 * 1024, 4, SECT_4K |
> SPI_NOR_HAS_LOCK) },
https://ww1.microchip.com/downloads/en/DeviceDoc/20005139F.pdf
BP0 BIT(2), BP1 BIT(3), TB BIT(5), BPL BIT(7) all non-volatile
SR.BPL BIT(7): when 1 - BPs are read-only bits, when 0 - BPs are r/w
> + { "sst25wf040b", INFO(0x621613, 0, 64 * 1024, 8, SECT_4K |
> SPI_NOR_HAS_LOCK) },
https://ww1.microchip.com/downloads/en/DeviceDoc/20005193D.pdf
BP0 BIT(2), BP1 BIT(3), BP2 BIT(4), TB BIT(5), BPL BIT(7) all non-volatile
SR.BPL BIT(7): when 1 - BPs are read-only bits, when 0 - BPs are r/w
> { "sst25wf040", INFO(0xbf2504, 0, 64 * 1024,
Re: [PATCH v5 1/3] mtd: spi-nor: atmel: remove global protection flag
On 10/3/20 6:32 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This is considered bad for the following reasons:
> (1) We only support the block protection with BPn bits for write
> protection. Not all Atmel parts support this.
> (2) Newly added flash chip will automatically inherit the "has
> locking" support and thus needs to explicitly tested. Better
> be opt-in instead of opt-out.
> (3) There are already supported flashes which doesn't support
> the locking scheme. So I assume this wasn't properly tested
> before adding that chip; which enforces my previous argument
> that locking support should be an opt-in.
>
> Remove the global flag and add individual flags to all flashes which
> supports BP locking. In particular the following flashes don't support
> the BP scheme:
> - AT26F004
> - AT25SL321
> - AT45DB081D
>
> Please note, that some flashes which are marked as SPI_NOR_HAS_LOCK just
> support Global Protection, i.e. not our supported block protection
> locking scheme. This is to keep backwards compatibility with the
> current "unlock all at boot" mechanism. In particular the following
> flashes doesn't have BP bits:
> - AT25DF041A
> - AT25DF321
> - AT25DF321A
> - AT25DF641
> - AT26DF081A
> - AT26DF161A
> - AT26DF321
>
> Signed-off-by: Michael Walle
Reviewed-by: Tudor Ambarus
> ---
> changes since v4:
> - none
>
> changes since v3/v2/v1:
> - there was no such version because this patch was bundled with another
>patch
>
> changes since RFC:
> - mention the flashes which just support the "Global Unprotect" in the
>commit message
>
> drivers/mtd/spi-nor/atmel.c | 28 +---
> 1 file changed, 9 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c
> index 3f5f21a473a6..49d392c6c8bc 100644
> --- a/drivers/mtd/spi-nor/atmel.c
> +++ b/drivers/mtd/spi-nor/atmel.c
> @@ -10,37 +10,27 @@
>
> static const struct flash_info atmel_parts[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> - { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> - { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
> + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K |
> SPI_NOR_HAS_LOCK) },
https://datasheetspdf.com/pdf-file/587164/ATMELCorporation/AT25FS010/1
BP bits are at bit 2, 3, 5 and 6.
BP0, BP1, BP3, BP4 and WPEN, are nonvolatile cells
> + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K |
> SPI_NOR_HAS_LOCK) },
https://datasheetspdf.com/pdf-file/587165/ATMELCorporation/AT25FS040/1
BP bits are at bit 2, 3, 4, 5, and 6.
BP0, BP1, BP2, BP3, BP4 are nonvolatile cells
>
> - { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
> - { "at25df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
> - { "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
> - { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
> + { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K |
> SPI_NOR_HAS_LOCK) },
https://datasheetspdf.com/pdf-file/975331/Adesto/AT25DF041A/1
Global Protect/Unprotect using Write SR command:
Global Unlock: write 0x00 to SR
Global Lock: Read SR. If SR.SPRL is 1 write 0xff to SR, else write 0x7f.
Upon device power-up or after a device reset, each Sector Protection
Register will default to the logical “1” state indicating that all
sectors are protected and cannot be programmed or erased.
> + { "at25df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K |
> SPI_NOR_HAS_LOCK) },
https://datasheetspdf.com/pdf-file/609207/ATMELCorporation/AT25DF321/1
Global Protect/Unprotect same as in at25df041a.
> + { "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K |
> SPI_NOR_HAS_LOCK) },
https://datasheetspdf.com/pdf-file/829669/Adesto/AT25DF321A/1
Global Protect/Unprotect same as in at25df041a.
> + { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K |
> SPI_NOR_HAS_LOCK) },
https://www.adestotech.com/wp-content/uploads/doc3680.pdf
Global Protect/Unprotect same as in at25df041a.
>
> { "at25sl321", INFO(0x1f4216, 0, 64 * 1024, 64,
> SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> },
https://www.adestotech.com/wp-content/uploads/AT25SL321_112.pdf
Ok, just hw write protection.
>
> { "at26f004", INFO(0x1f0400, 0, 64 * 1024, 8, SECT_4K) },
https://cdn.sos.sk/productdata/08/5e/c7c8063e/at-26-f004-ssu.pdf
OK, never worked, just Individual Sector Protection for Program/Erase Protection
> - { "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16, SECT_4K) },
> - { "at26df161a", INFO(0x1f4601, 0, 64 * 1024, 32, SECT_4K) },
> - { "at26df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
> + { "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16, SECT_4K |
> SPI_NOR_HAS_LOCK)
Re: [PATCH v16 14/15] mtd: spi-nor: spansion: add support for Cypress Semper flash
On 11/7/20 9:58 AM, Vignesh Raghavendra wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi,
>
> [...]
>
> On 10/5/20 9:01 PM, Pratyush Yadav wrote:
>> +static int spi_nor_cypress_octal_dtr_enable(struct spi_nor *nor, bool
>> enable)
>> +{
>> + struct spi_mem_op op;
>> + u8 *buf = nor->bouncebuf;
>> + int ret;
>> +
>> + if (enable) {
>> + /* Use 24 dummy cycles for memory array reads. */
>> + ret = spi_nor_write_enable(nor);
>> + if (ret)
>> + return ret;
>> +
>> + *buf = SPINOR_REG_CYPRESS_CFR2V_MEMLAT_11_24;
>> + op = (struct spi_mem_op)
>> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
>> +SPI_MEM_OP_ADDR(3, SPINOR_REG_CYPRESS_CFR2V,
>> +1),
>> +SPI_MEM_OP_NO_DUMMY,
>> +SPI_MEM_OP_DATA_OUT(1, buf, 1));
>> +
>> + ret = spi_mem_exec_op(nor->spimem, );
>> + if (ret)
>> + return ret;
>> +
>> + ret = spi_nor_wait_till_ready(nor);
>> + if (ret)
>> + return ret;
>> +
>> + nor->read_dummy = 24;
>> + }
>> +
>> + /* Set/unset the octal and DTR enable bits. */
>> + ret = spi_nor_write_enable(nor);
>> + if (ret)
>> + return ret;
>> +
>> + if (enable)
>> + *buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN;
>> + else
>> + *buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_DS;
>> +
>> + op = (struct spi_mem_op)
>> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
>> +SPI_MEM_OP_ADDR(enable ? 3 : 4,
>> +SPINOR_REG_CYPRESS_CFR5V,
>> +1),
>> +SPI_MEM_OP_NO_DUMMY,
>> +SPI_MEM_OP_DATA_OUT(1, buf, 1));
>> +
>> + if (!enable)
>> + spi_nor_spimem_setup_op(nor, , SNOR_PROTO_8_8_8_DTR);
>> +
>> + ret = spi_mem_exec_op(nor->spimem, );
>> + if (ret)
>> + return ret;
>> +
>> + /* Give some time for the mode change to take place. */
>> + usleep_range(1000, 1500);
>> +
>
> This delay is no longer needed right? I can drop it while applying, if
> you confirm.
>
> Tudor: Could you provide your R-by?
with usleep_range dropped one can add:
Reviewed-by: Tudor Ambarus
Cheers,
ta
Re: [PATCH v2 1/8] clk: at91: sama7g5: fix compilation error
On 11/4/20 7:45 PM, Claudiu Beznea wrote:
> pmc_data_allocate() has been changed. pmc_data_free() was removed.
> Adapt the code taking this into consideration. With this the programmable
> clocks were also saved in sama7g5_pmc so that they could be later
> referenced.
>
> Fixes: cb783bbbcf54 ("clk: at91: sama7g5: add clock support for sama7g5")
> Signed-off-by: Claudiu Beznea
Reviewed-by: Tudor Ambarus
Tested-by: Tudor Ambarus
> ---
> drivers/clk/at91/sama7g5.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/at91/sama7g5.c b/drivers/clk/at91/sama7g5.c
> index 0db2ab3eca14..a092a940baa4 100644
> --- a/drivers/clk/at91/sama7g5.c
> +++ b/drivers/clk/at91/sama7g5.c
> @@ -838,7 +838,7 @@ static void __init sama7g5_pmc_setup(struct device_node
> *np)
> sama7g5_pmc = pmc_data_allocate(PMC_I2S1_MUX + 1,
> nck(sama7g5_systemck),
> nck(sama7g5_periphck),
> - nck(sama7g5_gck));
> + nck(sama7g5_gck), 8);
> if (!sama7g5_pmc)
> return;
>
> @@ -980,6 +980,8 @@ static void __init sama7g5_pmc_setup(struct device_node
> *np)
> sama7g5_prog_mux_table);
> if (IS_ERR(hw))
> goto err_free;
> +
> + sama7g5_pmc->pchws[i] = hw;
> }
>
> for (i = 0; i < ARRAY_SIZE(sama7g5_systemck); i++) {
> @@ -1052,7 +1054,7 @@ static void __init sama7g5_pmc_setup(struct device_node
> *np)
> kfree(alloc_mem);
> }
>
> - pmc_data_free(sama7g5_pmc);
> + kfree(sama7g5_pmc);
> }
>
> /* Some clks are used for a clocksource */
>
Re: [PATCH v4 3/7] mtd: spi-nor: sfdp: parse command sequences to change octal DTR mode
Hi, Mason, YC Lin,
On 5/29/20 10:36 AM, Mason Yang wrote:
> A set of simple command sequences is provided which can be executed
> directly by the host controller to enable octal DTR mode.
>
> Each command sequence is 8 per byte for single SPI mode.
>
> Signed-off-by: Mason Yang
> ---
> drivers/mtd/spi-nor/core.h | 20 +
> drivers/mtd/spi-nor/sfdp.c | 104
> +
> 2 files changed, 124 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index a33f807..8de7f53 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -183,6 +183,23 @@ struct spi_nor_locking_ops {
> };
>
> /**
> + * struct cmd_seq_octal_dtr - command sequences to change to octal DTR mode
> + * Each command sequence is 8 per byte for single SPI mode.
> + * @len: commmand length of each command sequence.
> + * @opcode: command code.
> + * @addr:address offset to device.
> + * @data:data write to device.
> + */
> +struct cmd_seq_octal_dtr {
> + u8 len;
> + u8 opcode;
> + u32 addr;
> + u8 data;
> +};
You define seven bytes for the command sequence, while the table defines
eight bytes: first byte indicates the length of the sequence, and the
following seven bytes are values to be output by the controller.
How did you choose this cmd seq organization? The standard refers to the
7-byte sequence as "byte values to be output by the controller", it doesn't
indicate at which offset the opcode, addr and data are.
> +
> +#define CMD_SEQ_NUM 4
> +
> +/**
> * struct spi_nor_flash_parameter - SPI NOR flash parameters and settings.
> * Includes legacy flash parameters and settings that can be overwritten
> * by the spi_nor_fixups hooks, or dynamically when parsing the JESD216
> @@ -205,6 +222,7 @@ struct spi_nor_locking_ops {
> * higher index in the array, the higher priority.
> * @erase_map: the erase map parsed from the SFDP Sector Map
> Parameter
> * Table.
> + * @cmd_seq: command sequence to change to octal DTR mode.
> * @quad_enable: enables SPI NOR quad mode.
> * @set_4byte_addr_mode: puts the SPI NOR in 4 byte addressing mode.
> * @convert_addr:converts an absolute address into something the flash
> @@ -232,6 +250,8 @@ struct spi_nor_flash_parameter {
>
> struct spi_nor_erase_maperase_map;
>
> + struct cmd_seq_octal_dtrcmd_seq[CMD_SEQ_NUM];
> +
> int (*quad_enable)(struct spi_nor *nor);
> int (*set_4byte_addr_mode)(struct spi_nor *nor, bool enable);
> u32 (*convert_addr)(struct spi_nor *nor, u32 addr);
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index 27a4de4..ef19290 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -21,6 +21,7 @@
> #define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
> #define SFDP_4BAIT_ID0xff84 /* 4-byte Address Instruction
> Table */
> #define SFDP_PROFILE1_ID 0xff05 /* xSPI Profile 1.0 table. */
> +#define SFDP_CMD_TO_8DTR_ID 0xff0a /* Command Sequences to Octal DTR */
>
> #define SFDP_SIGNATURE 0x50444653U
> #define SFDP_JESD216_MAJOR 1
> @@ -49,6 +50,19 @@ struct xspi_dummy_cycles {
> u8 shift; /* Bit shift */
> };
>
> +#define CMD_TO_8DTR_LEN GENMASK(31, 24)
> +#define CMD_TO_8DTR_OPCODE GENMASK(23, 16)
> +#define CMD_TO_8DTR_1_ADDR GENMASK(15, 8)
> +#define CMD_TO_8DTR_1_ADDR_DATA GENMASK(7, 0)
> +#define CMD_TO_8DTR_4_ADDR_MSB GENMASK(15, 0)
> +#define CMD_TO_8DTR_4_ADDR_LSB GENMASK(31, 16)
> +#define CMD_TO_8DTR_4_ADDR_DATA GENMASK(15, 8)
> +#define CMD_TO_8DTR_SIZE_MAX 8
> +
> +struct sfdp_cmd_to_8dtr {
> + u32 dwords[CMD_TO_8DTR_SIZE_MAX];
> +};
> +
> /* Basic Flash Parameter Table 20th DWORD, Max operation speed of device */
> struct octal_max_speed {
> u8 idx; /* Bits value */
> @@ -1219,6 +1233,91 @@ static int spi_nor_parse_profile1(struct spi_nor *nor,
> }
>
> /**
> + * spi_nor_parse_cmd_to_8dtr() - parse the command sequence to octal DTR
> + * @nor: pointer to a 'struct spi_nor'
> + * @param_header:command sequence to octal DTR parameter table header.
> + * @params: pointer to the 'struct spi_nor_flash_parameter' to be.
> + *
> + * Return: 0 on success, -errno otherwise.
> + */
> +static int spi_nor_parse_cmd_to_8dtr(struct spi_nor *nor,
> + const struct sfdp_parameter_header *header,
> + struct spi_nor_flash_parameter *params)
> +{
> + struct sfdp_cmd_to_8dtr cmd_seq;
you'll need to kmalloc cmd_seq because spi_nor_read_sfdp expects a DMA-able
buffer.
> + u32 i, j, addr;
> + size_t len;
> + int ret;
> +
> + if (header->major != SFDP_JESD216_MAJOR ||
> +
Re: [PATCH v16 00/15] mtd: spi-nor: add xSPI Octal DTR support
Hi, Pratyush, On 10/5/20 6:31 PM, Pratyush Yadav wrote: > Tested on Micron MT35X and S28HS flashes for Octal DTR. Do these flashes define the "Command Sequences to Change to Octal DDR (8D-8D-8D) mode" table? Can't we use that table instead of defining our own octal dtr enable functions? I see that Mason used this table for a macronix flash: https://patchwork.ozlabs.org/project/linux-mtd/patch/1590737775-4798-4-git-send-email-masonccy...@mxic.com.tw/ https://patchwork.ozlabs.org/project/linux-mtd/patch/1590737775-4798-8-git-send-email-masonccy...@mxic.com.tw/ Cheers, ta
Re: [PATCH v4 7/7] mtd: spi-nor: macronix: Add Octal 8D-8D-8D supports for Macronix mx25uw51245g
Hi, Mason, YC Lin,
On 5/29/20 10:36 AM, Mason Yang wrote:
> Macronix mx25uw51245g is a SPI NOR that supports 1-1-1/8-8-8 mode.
>
> Correct the dummy cycles to device for various frequencies
> after xSPI profile 1.0 table parsed.
>
> Enable mx25uw51245g to Octal DTR mode by executing the command sequences
> to change to octal DTR mode.
>
> Signed-off-by: Mason Yang
> ---
> drivers/mtd/spi-nor/macronix.c | 55
> ++
> 1 file changed, 55 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
> index 96735d8..6c9a24c 100644
> --- a/drivers/mtd/spi-nor/macronix.c
> +++ b/drivers/mtd/spi-nor/macronix.c
> @@ -8,6 +8,57 @@
>
> #include "core.h"
>
> +#define MXIC_CR2_DUMMY_SET_ADDR 0x300
> +
> +/* Fixup the dummy cycles to device and setup octa_dtr_enable() */
> +static void mx25uw51245g_post_sfdp_fixups(struct spi_nor *nor)
> +{
> + struct spi_nor_flash_parameter *params = nor->params;
> + int ret;
> + u8 rdc, wdc;
> +
> + ret = spi_nor_read_cr2(nor, MXIC_CR2_DUMMY_SET_ADDR, );
nor->bouncebuf is DMA-able, use it instead of rdc
> + if (ret)
> + return;
> +
> + /* Refer to dummy cycle and frequency table(MHz) */
> + switch (params->dummy_cycles) {
> + case 10:/* 10 dummy cycles for 104 MHz */
> + wdc = 5;
> + break;
> + case 12:/* 12 dummy cycles for 133 MHz */
> + wdc = 4;
> + break;
> + case 16:/* 16 dummy cycles for 166 MHz */
> + wdc = 2;
> + break;
> + case 18:/* 18 dummy cycles for 173 MHz */
> + wdc = 1;
> + break;
> + case 20:/* 20 dummy cycles for 200 MHz */
> + default:
> + wdc = 0;
> + }
> +
> + if (rdc != wdc)
> + spi_nor_write_cr2(nor, MXIC_CR2_DUMMY_SET_ADDR, );
> +
> + if (params->cmd_seq[0].len) {
> + params->octal_dtr_enable = spi_nor_cmd_seq_octal_dtr;
> + params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;
> + params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
> +
> + } else {
> + params->octal_dtr_enable = NULL;
> + params->hwcaps.mask &= ~SNOR_HWCAPS_READ_8_8_8_DTR;
> + params->hwcaps.mask &= ~SNOR_HWCAPS_PP_8_8_8_DTR;
> + }
> +}
> +
> +static struct spi_nor_fixups mx25uw51245g_fixups = {
> + .post_sfdp = mx25uw51245g_post_sfdp_fixups,
> +};
> +
> static int
> mx25l25635_post_bfpt_fixups(struct spi_nor *nor,
> const struct sfdp_parameter_header *bfpt_header,
> @@ -84,6 +135,10 @@
> SPI_NOR_QUAD_READ) },
> { "mx66l1g55g", INFO(0xc2261b, 0, 64 * 1024, 2048,
> SPI_NOR_QUAD_READ) },
> + { "mx25uw51245g", INFO(0xc2813a, 0, 64 * 1024, 1024,
> + SECT_4K | SPI_NOR_4B_OPCODES |
> + SPI_NOR_OCTAL_DTR_READ)
octal dtr page program is supported?
> + .fixups = _fixups },
> };
>
> static void macronix_default_init(struct spi_nor *nor)
>
Cheers,
ta
Re: [PATCH v16 00/15] mtd: spi-nor: add xSPI Octal DTR support
On 10/28/20 2:49 PM, Pratyush Yadav wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Hi Tudor, > > On 28/10/20 07:53AM, tudor.amba...@microchip.com wrote: >> Hi, Pratyush, >> >> On 10/5/20 6:31 PM, Pratyush Yadav wrote: >>> Tested on Micron MT35X and S28HS flashes for Octal DTR. >> >> Do these flashes define the "Command Sequences to Change to >> Octal DDR (8D-8D-8D) mode" table? Can't we use that table >> instead of defining our own octal dtr enable functions? > > The Micron flash does not have this table. The Cypress flash does. The > problem is that one of the samples of the Cypress flash I tested on had > incorrect data in that table which meant the sequence would fail. The > newer samples of the flash have the correct data. Can we differentiate the Cypress flashes? Do you remember what was the incorrect data? > > I don't know how many of those faulty flashes are out there in the wild. > IMO, to be on the safe side spi_nor_cypress_octal_dtr_enable() needs to > be implemented. So from the point of view of this series there is no > need to parse the Octal DDR enable table. Meh, we cover manufacturer's mistakes. On the long run, our aim should be to follow the SFDP standard and if a flash implements it wrong, to either fix it via a fixup hook (if the fix is minimal), or to skip the faulty table. Regarding "Command Sequences to Change to Octal DDR (8D-8D-8D) mode" table. Have you looked over https://patchwork.ozlabs.org/project/linux-mtd/patch/1590737775-4798-4-git-send-email-masonccy...@mxic.com.tw/ ? Is there a standard way to determine the offsets of opcode, addr and data in the cmd seq? Cheers, ta > >> I see that Mason used this table for a macronix flash: >> https://patchwork.ozlabs.org/project/linux-mtd/patch/1590737775-4798-4-git-send-email-masonccy...@mxic.com.tw/ >> https://patchwork.ozlabs.org/project/linux-mtd/patch/1590737775-4798-8-git-send-email-masonccy...@mxic.com.tw/ >> >> Cheers, >> ta > > -- > Regards, > Pratyush Yadav > Texas Instruments India >
Re: [PATCH v4 4/7] mtd: spi-nor: core: add configuration register 2 read & write support
Hi, Mason, YC Lin,
On 5/29/20 10:36 AM, Mason Yang wrote:
> Configuration register 2 is to set the device operation condition like
> STR or DTR mode at address offset 0 and DQS mode at address offset 0x200.
>
> Each device has various address offset for it's specific operatoin
> setting.
>
> Signed-off-by: Mason Yang
> ---
> drivers/mtd/spi-nor/core.c | 78
> ++
> drivers/mtd/spi-nor/core.h | 2 ++
> 2 files changed, 80 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 3799417..fed6236 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -269,6 +269,84 @@ int spi_nor_write_disable(struct spi_nor *nor)
> }
>
> /**
> + * spi_nor_read_cr2() - Read the Configuration Register 2.
> + * @nor: pointer to 'struct spi_nor'.
> + * @addr:offset address to read.
> + * @cr2: pointer to a DMA-able buffer where the value of the
> + * Configuration Register 2 will be written.
> + *
> + * Return: 0 on success, -errno otherwise.
> + */
> +int spi_nor_read_cr2(struct spi_nor *nor, u32 addr, u8 *cr2)
spi_nor_read_volatile_reg() please
do we need to pass len as an argument?
s/cr2/buf
why do we need addr for register interactions?
> +{
> + int ret;
> + u8 cmd = nor->params->rd_reg_cmd;
you'll need to redefine to rd_vreg_cmd.
> +
> + if (nor->spimem) {
> + struct spi_mem_op op =
> + SPI_MEM_OP(SPI_MEM_OP_CMD(cmd, 1),
> +SPI_MEM_OP_ADDR(4, addr, 1),
nor->addr_width?
> +SPI_MEM_OP_DUMMY(4, 1),
nor->read_dummy?
> +SPI_MEM_OP_DATA_IN(1, cr2, 1));
SPI_MEM_OP_DATA_IN(len, cr2, 0)?
> +
> + spi_nor_spimem_setup_op(nor, , nor->reg_proto);
> +
> + ret = spi_mem_exec_op(nor->spimem, );
> + } else {
> + if (spi_nor_protocol_is_dtr(nor->reg_proto))
> + ret = -ENOTSUPP;
> + else
> + ret = nor->controller_ops->read_reg(nor, cmd, cr2, 1);
> + }
> +
> + if (ret)
> + dev_dbg(nor->dev, "error %d reading CR2\n", ret);
> +
> + return ret;
> +}
> +
> +/**
> + * spi_nor_write_cr2() - Write the Configuration Register 2.
> + * @nor: pointer to 'struct spi_nor'.
> + * @addr:offset address to write.
> + * @cr2: pointer to a DMA-able buffer where the value of the
> + * Configuratin Register 2 will be read.
> + *
> + * Return: 0 on success, -errno otherwise.
> + */
> +int spi_nor_write_cr2(struct spi_nor *nor, u32 addr, u8 *cr2)
spi_nor_write_volatile_reg() please
Cheers,
ta
Re: [PATCH v4 0/7] mtd: spi-nor: add xSPI Octal DTR support
Hi, Mason, YC Lin, We'll have to figure out how we can best use the "Command Sequences to Change to Octal DDR" table. Would be great if you continue to work on this. One has to rebase this series on top of v5.10-rc1 with Pratyush's series [1] applied in advance. Please let me know about your plans with this series. Cheers, ta [1] https://patchwork.ozlabs.org/project/linux-mtd/cover/20201005153138.6437-1-p.ya...@ti.com/
Re: [PATCH v4 2/7] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
Hi, Mason, YC Lin,
On 5/29/20 10:36 AM, Mason Yang wrote:
> JESD251, xSPI profile 1.0 table supports octal DTR mode.
> Extract information like the fast read opcode, dummy cycles for various
> frequencies, the number of dummy cycles needed for a Read Status
> Register command, the number of address bytes needed for a Read
> Status Register command, read volatile register command and write
> volatile register command.
>
> According to BFPT 20th DWORD of octal maximum speed, driver get it's
> specific dummy cycles from profile 1.0 table and then could update
> it to device by their fixup hooks.
>
> Since driver get octal DTR read opcode and then set read settings,
> expose spi_nor_set_read_settings() in core.h.
>
> Signed-off-by: Mason Yang
> ---
> drivers/mtd/spi-nor/core.c | 2 +-
> drivers/mtd/spi-nor/core.h | 16 +++
> drivers/mtd/spi-nor/sfdp.c | 106
> +
> 3 files changed, 123 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 1ab4386..3799417 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2204,7 +2204,7 @@ static int spi_nor_check(struct spi_nor *nor)
> return 0;
> }
>
> -static void
> +void
> spi_nor_set_read_settings(struct spi_nor_read_command *read,
> u8 num_mode_clocks,
> u8 num_wait_states,
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 7a36b22..a33f807 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -191,6 +191,12 @@ struct spi_nor_locking_ops {
> * @size:the flash memory density in bytes.
> * @page_size: the page size of the SPI NOR flash memory.
> * @octal_max_speed: maximum operation speed of device in octal mode.
> + * @rdsr_dummy: dummy cycles needed for Read Status Register
> command.
> + * @rdsr_addr_nbytes:dummy address bytes needed for Read Status
> Register
> + * command.
> + * @rd_reg_cmd: read volatile register command for xSPI device.
> + * @wr_reg_cmd: write volatile register command for xSPI device.
Can all the volatile registers be accessed with these commands?
The profile1.0 table lacks description.
> + * @dummy_cycles:dummy cycles used for various frequencies
> * @hwcaps: describes the read and page program hardware
> * capabilities.
> * @reads: read capabilities ordered by priority: the higher index
> @@ -214,6 +220,11 @@ struct spi_nor_flash_parameter {
> u64 size;
> u32 page_size;
> u16 octal_max_speed;
> + u8 rdsr_dummy;
> + u8 rdsr_addr_nbytes;
> + u8 rd_reg_cmd;
> + u8 wr_reg_cmd;
> + u8 dummy_cycles;
>
> struct spi_nor_hwcaps hwcaps;
> struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
> @@ -420,6 +431,11 @@ ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t
> to, size_t len,
>
> int spi_nor_hwcaps_read2cmd(u32 hwcaps);
> u8 spi_nor_convert_3to4_read(u8 opcode);
> +void spi_nor_set_read_settings(struct spi_nor_read_command *read,
> +u8 num_mode_clocks,
> +u8 num_wait_states,
> +u8 opcode,
> +enum spi_nor_protocol proto);
> void spi_nor_set_pp_settings(struct spi_nor_pp_command *pp, u8 opcode,
>enum spi_nor_protocol proto);
>
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index 4d13f66..27a4de4 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -20,6 +20,7 @@
> #define SFDP_BFPT_ID 0xff00 /* Basic Flash Parameter Table */
> #define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
> #define SFDP_4BAIT_ID0xff84 /* 4-byte Address Instruction
> Table */
> +#define SFDP_PROFILE1_ID 0xff05 /* xSPI Profile 1.0 table. */
>
> #define SFDP_SIGNATURE 0x50444653U
> #define SFDP_JESD216_MAJOR 1
> @@ -27,6 +28,27 @@
> #define SFDP_JESD216A_MINOR 5
> #define SFDP_JESD216B_MINOR 6
>
> +/* xSPI Profile 1.0 table (from JESD216D.01). */
> +#define XSPI_PF1_DWORD1_RD_CMD GENMASK(15, 8)
> +#define XSPI_PF1_DWORD1_RDSR_ADDR_BYTES BIT(29)
> +#define XSPI_PF1_DWORD1_RDSR_DUMMY_CYCLES BIT(28)
> +#define XSPI_PF1_DWORD2_RD_REG_CMD GENMASK(31, 24)
> +#define XSPI_PF1_DWORD2_WR_REG_CMD GENMASK(15, 8)
> +#define XSPI_PF1_DUMMY_CYCLES_DEFAULT20
> +#define XSPI_DWORD(x) ((x) - 1)
> +#define XSPI_DWORD_MAX 5
> +
> +struct sfdp_xspi {
> + u32
Re: [PATCH v4 1/7] mtd: spi-nor: sfdp: get octal mode maximum speed from BFPT
Hi, Mason, YC Lin,
On 5/29/20 10:36 AM, Mason Yang wrote:
> Get maximum operation speed of device in octal mode from
> BFPT 20th DWORD.
>
I would like to understand how would we use the max speed value
at the SPI NOR level. The maximum operation speed is typically used
to determine the number of dummy cycles, which is described in xSPI
Spec for speeds of 200 MHz or less. Even if BFPT[dword20] describes
supported speeds up to 400 MHz, it doesn't indicate the number of
required dummy cycles. What number of dummy cycles would we use for
speeds higher than 200 MHz?
We may be tempted however to pass the max_speed_hz to the SPIMEM layer,
so that the controller can sync with the memory to choose the best
available speed.
Cheers,
ta
> Signed-off-by: Mason Yang
> ---
> drivers/mtd/spi-nor/core.h | 2 ++
> drivers/mtd/spi-nor/sfdp.c | 36
> drivers/mtd/spi-nor/sfdp.h | 4
> 3 files changed, 42 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 6f2f6b2..7a36b22 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -190,6 +190,7 @@ struct spi_nor_locking_ops {
> *
> * @size:the flash memory density in bytes.
> * @page_size: the page size of the SPI NOR flash memory.
> + * @octal_max_speed: maximum operation speed of device in octal mode.
> * @hwcaps: describes the read and page program hardware
> * capabilities.
> * @reads: read capabilities ordered by priority: the higher index
> @@ -212,6 +213,7 @@ struct spi_nor_locking_ops {
> struct spi_nor_flash_parameter {
> u64 size;
> u32 page_size;
> + u16 octal_max_speed;
>
> struct spi_nor_hwcaps hwcaps;
> struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index f6038d3..4d13f66 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -4,6 +4,7 @@
> * Copyright (C) 2014, Freescale Semiconductor, Inc.
> */
>
> +#include
> #include
> #include
> #include
> @@ -26,6 +27,12 @@
> #define SFDP_JESD216A_MINOR 5
> #define SFDP_JESD216B_MINOR 6
>
> +/* Basic Flash Parameter Table 20th DWORD, Max operation speed of device */
> +struct octal_max_speed {
> + u8 idx; /* Bits value */
> + u16 hz; /* MHz */
> +};
> +
> struct sfdp_header {
> u32 signature; /* Ox50444653U <=> "SFDP" */
> u8 minor;
> @@ -440,6 +447,22 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
> u32 addr;
> u16 half;
> u8 erase_mask;
> + static const struct octal_max_speed max_hz[] = {
> + /* Bits value, MHz */
> + { 0x0c, 400 },
> + { 0x0b, 333 },
> + { 0x0a, 266 },
> + { 0x09, 250 },
> + { 0x08, 200 },
> + { 0x07, 166 },
> + { 0x06, 133 },
> + { 0x05, 100 },
> + { 0x04, 80 },
> + { 0x03, 66 },
> + { 0x02, 50 },
> + { 0x01, 33 },
> + };
> + u8 idx;
>
> /* JESD216 Basic Flash Parameter Table length is at least 9 DWORDs. */
> if (bfpt_header->length < BFPT_DWORD_MAX_JESD216)
> @@ -604,6 +627,19 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
> return -EINVAL;
> }
>
> + /* Octal mode max speed */
> + idx = max(FIELD_GET(BFPT_DWORD20_OCTAL_DTR_MAX_SPEED,
> + bfpt.dwords[BFPT_DWORD(20)]),
> + FIELD_GET(BFPT_DWORD20_OCTAL_STR_MAX_SPEED,
> + bfpt.dwords[BFPT_DWORD(20)]));
> +
> + for (i = 0; i < ARRAY_SIZE(max_hz); i++) {
> + if (max_hz[i].idx == idx) {
> + params->octal_max_speed = max_hz[i].hz;
> + break;
> + }
> + }
> +
> return spi_nor_post_bfpt_fixups(nor, bfpt_header, , params);
> }
>
> diff --git a/drivers/mtd/spi-nor/sfdp.h b/drivers/mtd/spi-nor/sfdp.h
> index e0a8ded..8ae6d9a 100644
> --- a/drivers/mtd/spi-nor/sfdp.h
> +++ b/drivers/mtd/spi-nor/sfdp.h
> @@ -83,6 +83,10 @@ struct sfdp_bfpt {
> #define BFPT_DWORD15_QER_SR2_BIT1_NO_RD (0x4UL << 20)
> #define BFPT_DWORD15_QER_SR2_BIT1(0x5UL << 20) /* Spansion */
>
> +#define BFPT_DWORD20_OCTAL_MAX_SPEED_MASK GENMASK(31, 16)
> +#define BFPT_DWORD20_OCTAL_DTR_MAX_SPEEDGENMASK(31, 28)
> +#define BFPT_DWORD20_OCTAL_STR_MAX_SPEEDGENMASK(19, 16)
> +
> struct sfdp_parameter_header {
> u8 id_lsb;
> u8 minor;
>
Re: [PATCH v16 05/15] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
On 10/5/20 6:31 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This table is indication that the flash is xSPI compliant and hence
> supports octal DTR mode. Extract information like the fast read opcode,
> dummy cycles, the number of dummy cycles needed for a Read Status
> Register command, and the number of address bytes needed for a Read
> Status Register command.
>
> We don't know what speed the controller is running at. Find the fast
> read dummy cycles for the fastest frequency the flash can run at to be
> sure we are never short of dummy cycles. If nothing is available,
> default to 20. Flashes that use a different value should update it in
> their fixup hooks.
>
> Since we want to set read settings, expose spi_nor_set_read_settings()
> in core.h.
>
> Signed-off-by: Pratyush Yadav
> Reviewed-by: Tudor Ambarus
> ---
> drivers/mtd/spi-nor/core.c | 2 +-
> drivers/mtd/spi-nor/core.h | 10 +
> drivers/mtd/spi-nor/sfdp.c | 91 ++
> 3 files changed, 102 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 779e64974fea..ad280874a2e8 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2332,7 +2332,7 @@ static int spi_nor_check(struct spi_nor *nor)
> return 0;
> }
>
> -static void
> +void
> spi_nor_set_read_settings(struct spi_nor_read_command *read,
> u8 num_mode_clocks,
> u8 num_wait_states,
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 5d95b4183a33..9a33c8d07335 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -192,6 +192,9 @@ struct spi_nor_locking_ops {
> *
> * @size: the flash memory density in bytes.
> * @page_size: the page size of the SPI NOR flash memory.
> + * @rdsr_dummy:dummy cycles needed for Read Status Register
> command.
> + * @rdsr_addr_nbytes: dummy address bytes needed for Read Status Register
> + * command.
> * @hwcaps:describes the read and page program hardware
> * capabilities.
> * @reads: read capabilities ordered by priority: the higher
> index
> @@ -214,6 +217,8 @@ struct spi_nor_locking_ops {
> struct spi_nor_flash_parameter {
> u64 size;
> u32 page_size;
> + u8 rdsr_dummy;
> + u8 rdsr_addr_nbytes;
>
> struct spi_nor_hwcaps hwcaps;
> struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
> @@ -425,6 +430,11 @@ ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t
> to, size_t len,
>
> int spi_nor_hwcaps_read2cmd(u32 hwcaps);
> u8 spi_nor_convert_3to4_read(u8 opcode);
> +void spi_nor_set_read_settings(struct spi_nor_read_command *read,
> + u8 num_mode_clocks,
> + u8 num_wait_states,
> + u8 opcode,
> + enum spi_nor_protocol proto);
> void spi_nor_set_pp_settings(struct spi_nor_pp_command *pp, u8 opcode,
> enum spi_nor_protocol proto);
>
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index c77655968f80..b2d097b44a55 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -4,6 +4,7 @@
> * Copyright (C) 2014, Freescale Semiconductor, Inc.
> */
>
> +#include
> #include
> #include
> #include
> @@ -19,6 +20,7 @@
> #define SFDP_BFPT_ID 0xff00 /* Basic Flash Parameter Table */
> #define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
> #define SFDP_4BAIT_ID 0xff84 /* 4-byte Address Instruction Table */
> +#define SFDP_PROFILE1_ID 0xff05 /* xSPI Profile 1.0 table. */
>
> #define SFDP_SIGNATURE 0x50444653U
>
> @@ -1108,6 +1110,91 @@ static int spi_nor_parse_4bait(struct spi_nor *nor,
> return ret;
> }
>
> +#define PROFILE1_DWORD1_RDSR_ADDR_BYTESBIT(29)
> +#define PROFILE1_DWORD1_RDSR_DUMMY BIT(28)
> +#define PROFILE1_DWORD1_RD_FAST_CMDGENMASK(15, 8)
> +#define PROFILE1_DWORD4_DUMMY_200MHZ GENMASK(11, 7)
> +#define PROFILE1_DWORD5_DUMMY_166MHZ GENMASK(31, 27)
> +#define PROFILE1_DWORD5_DUMMY_133MHZ GENMASK(21, 17)
> +#define PROFILE1_DWORD5_DUMMY_100MHZ GENMASK(11, 7)
> +
> +/**
> + * spi_nor_parse_profile1() - parse the xSPI Profile 1.0 table
> + * @nor: pointer to a 'struct spi_nor'
> + * @profile1_header: pointer to the 'struct sfdp_parameter_header'
> describing
> + * the Profile 1.0 Table length and version.
> + * @params:pointer to the 'struct spi_nor_flash_parameter'
