[PATCH v2 1/3] mtd: spi-nor: Add support for zBIT ZB25VQ128

[Dragan Simic]

On 2023-12-09 23:13, Tom Rini wrote:
> On Sat, Dec 09, 2023 at 10:43:35PM +0100, Dragan Simic wrote:
>> On 2023-12-09 22:21, Tom Rini wrote:
>> > On Sat, Dec 09, 2023 at 10:02:09PM +0100, Dragan Simic wrote:
>> > > On 2023-12-09 21:43, Tom Rini wrote:
>> > > > On Sat, Dec 09, 2023 at 09:37:28PM +0100, Dragan Simic wrote:
>> > > > > On 2023-12-09 21:34, Tom Rini wrote:
>> > > > > > On Wed, Dec 06, 2023 at 04:24:43PM +0000, Andre Przywara wrote:
>> > > > > > > On Mon,  4 Dec 2023 00:59:52 +0000
>> > > > > > > Andre Przywara <andre.przywara at arm.com> wrote:
>> > > > > > > > Add support for the zBIT ZB25VQ128 (128M-bit) SPI NOR flash memory chip,
>> > > > > > > > as used on the Xunlong Orange Pi Zero 3 board.
>> > > > > > >
>> > > > > > > does anyone have any objections against this patch? I wanted to take
>> > > > > > > this
>> > > > > > > via the sunxi tree, as this blocks some board support patches.
>> > > > > > >
>> > > > > > > IIUC Linux gave up on adding rather generic entries up for each and
>> > > > > > > every
>> > > > > > > SPI NOR chip, if there is nothing special about them:
>> > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=773bbe1044
>> > > > > > > Should we follow suit here?
>> > > > > >
>> > > > > > And we could then start trimming the table we do have as well, to
>> > > > > > reclaim space?
>> > > > >
>> > > > > In general, yes, but we'd also need to consume a bit more space with
>> > > > > the
>> > > > > additional auto-detection logic.
>> > > >
>> > > > Maybe part one of the series is backport that logic, part two is remove
>> > > > all the easy to remove tables? Or at least a number of them so the
>> > > > series is a wash and then a targeted series of drop-an-entry and cc the
>> > > > person that added it so they can run-time verify it's still fine?
>> > >
>> > > Sounds like a plan to me and I'm willing to work on that.  Though, I think
>> > > we'll inevitably end up with increasing the resulting image sizes a bit, but
>> > > that might be an acceptable trade-off for making supporting more SPI chips
>> > > and more new boards much easier in the future.
>> >
>> > Yeah, this is where we need to go overall long term if nothing else.
>> 
>> I agree, it would make the things a bit easier.  I'll see to start 
>> working
>> on it next week.
> 
> Thanks!

Thank you for agreeing with this new approach.