linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <tkuw584924@gmail.com>, <michael@walle.cc>
Cc: <linux-mtd@lists.infradead.org>, <miquel.raynal@bootlin.com>,
	<richard@nod.at>, <vigneshr@ti.com>, <p.yadav@ti.com>,
	<Bacem.Daassi@infineon.com>, <Takahiro.Kuwano@infineon.com>
Subject: Re: [PATCH v15 6/8] mtd: spi-nor: Retain nor->addr_width at 4BAIT parse
Date: Wed, 8 Jun 2022 11:39:41 +0000	[thread overview]
Message-ID: <8333ceed-9445-4be9-4483-36c211822700@microchip.com> (raw)
In-Reply-To: <57fd05cd-e0a7-b41a-53f0-c419ddc53a1a@gmail.com>

On 5/14/22 06:51, Takahiro Kuwano wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 5/13/2022 6:40 PM, Michael Walle wrote:
>> [btw the subject still has the old name of the addr_width]
>>
> Yes, it must be fixed in next rev.
> 
>> Am 2022-05-13 03:26, schrieb Takahiro Kuwano:
>>> On 5/13/2022 7:14 AM, Michael Walle wrote:
>>>> Am 2022-05-10 00:10, schrieb tkuw584924@gmail.com:
>>>>> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
>>>>>
>>>>> In 4BAIT parse, keep nor->params->addr_width because it may be used as
>>>>> current address mode in SMPT parse later on.
>>>> Mh I'm not sure this is needed at all.
>>>>
>>>> SFDP spec says
>>>>   Variable address length (the current setting of the address
>>>>   length mode defines the address length)
>>>>
>>>> and
>>>>   When the length is defined as variable, the software or hardware
>>>>   controlling the memory is aware of the address length mode last
>>>>   set in the memory device and this same length of address.
>>>>
>>>> We don't set any address mode until all the SFDP parsing is
>>>> over. Therefore we should always be in 3 byte mode, no?
>>>>
>>> Actually there are some devices that have variable address length but
>>> 4 byte mode by default (I will work on those devices after this series
>>> is settled). To support such case, I prefer to use params->addr_nbytes
>>> as current address mode so that I can fix it in post_bfpt_fixup() hook.
>> Are there public datasheets available? So these devices have a 3 byte
> I will send datasheets to you in another email. At this point, only
> summary datasheet is available in website.
> 
>> and a 4 byte mode, but after reset, they are in the 4 byte mode? Looks
> Yes.
> 
>> like it should be fixed in a different way. I'm not sure the "current
>> mode" handling is correct.
>>
> Yes, we may want to introduce a new flag like SPI_NOR_4BAM_DEFAULT and check
> the flag in BFPT parse. Once I send another series, please review.
> 

Sounds good on a first look. We can consider nor->addr_nbytes of value 3 as
default and change it to 4 when such a flag is set. But you don't need such
flag in this particular case, don't you? Also, can the default number of addr
bytes be retrieved from SFDP? Anyway, let this for later and respin the series,
please.

Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2022-06-08 11:40 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-09 22:10 [PATCH v15 0/8] mtd: spi-nor: Add support for Infineon s25hl-t/s25hs-t tkuw584924
2022-05-09 22:10 ` [PATCH v15 1/8] mtd: spi-nor: s/addr_width/addr_nbytes tkuw584924
2022-05-12 21:01   ` Michael Walle
2022-05-31 11:13   ` Pratyush Yadav
2022-05-09 22:10 ` [PATCH v15 2/8] mtd: spi-nor: core: Shrink the storage size of the flash_info's addr_nbytes tkuw584924
2022-05-12 21:22   ` Michael Walle
2022-05-31 11:14   ` Pratyush Yadav
2022-05-09 22:10 ` [PATCH v15 3/8] mtd: spi-nor: sfdp: Clarify that nor->read_{opcode, dummy} are uninitialized tkuw584924
2022-05-12 21:33   ` Michael Walle
2022-05-12 21:38     ` Michael Walle
2022-05-31 11:18   ` Pratyush Yadav
2022-05-09 22:10 ` [PATCH v15 4/8] mtd: spi-nor: Do not change nor->addr_nbytes at SFDP parsing time tkuw584924
2022-05-12 21:45   ` Michael Walle
2022-05-31 11:30   ` Pratyush Yadav
2022-07-21 14:32     ` Tudor.Ambarus
2022-07-21 15:02     ` Tudor.Ambarus
2022-05-09 22:10 ` [PATCH v15 5/8] mtd: spi-nor: core: Couple the number of address bytes with the address mode tkuw584924
2022-05-12 22:07   ` Michael Walle
2022-05-09 22:10 ` [PATCH v15 6/8] mtd: spi-nor: Retain nor->addr_width at 4BAIT parse tkuw584924
2022-05-12 22:14   ` Michael Walle
2022-05-13  1:26     ` Takahiro Kuwano
2022-05-13  9:40       ` Michael Walle
2022-05-14  3:51         ` Takahiro Kuwano
2022-05-18  6:04           ` Takahiro Kuwano
2022-05-18  8:35             ` Michael Walle
2022-05-18  9:12               ` Takahiro Kuwano
2022-05-23  7:49           ` Michael Walle
2022-05-23  9:56             ` Takahiro Kuwano
2022-06-03  9:33               ` Takahiro Kuwano
2022-07-21 16:06             ` Tudor.Ambarus
2022-07-22  4:00               ` Takahiro Kuwano
2022-07-22  4:20                 ` Tudor.Ambarus
2022-07-22  4:31                   ` Vanessa Page
2022-07-22  4:46                   ` Takahiro Kuwano
2022-07-22  5:06                     ` Tudor.Ambarus
2022-07-22  5:11                       ` Takahiro Kuwano
2022-07-22  6:08                         ` Tudor.Ambarus
2022-07-22  7:38                           ` Tudor.Ambarus
2022-07-22  7:45                             ` Tudor.Ambarus
2022-06-08 11:39           ` Tudor.Ambarus [this message]
2022-05-09 22:10 ` [PATCH v15 7/8] mtd: spi-nor: spansion: Add local function to discover page size tkuw584924
2022-05-09 22:10 ` [PATCH v15 8/8] mtd: spi-nor: spansion: Add s25hl-t/s25hs-t IDs and fixups tkuw584924

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8333ceed-9445-4be9-4483-36c211822700@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Bacem.Daassi@infineon.com \
    --cc=Takahiro.Kuwano@infineon.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=tkuw584924@gmail.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).