From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Daniel Mack <daniel@zonque.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Robert Jarzmik <robert.jarzmik@free.fr>,
Russell King <linux@armlinux.org.uk>
Subject: Re: [PATCH v1 07/10] spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
Date: Tue, 26 Mar 2024 20:50:04 +0200 [thread overview]
Message-ID: <ZgMY3AeC1Jnh1Oru@smile.fi.intel.com> (raw)
In-Reply-To: <dcdf8c46-acdc-466d-afc6-caf0e0fa39e8@sirena.org.uk>
On Tue, Mar 26, 2024 at 06:21:48PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 08:07:57PM +0200, Andy Shevchenko wrote:
>
> > Since driver can parse num-cs device property, replace platform data
> > with this new approach.
>
> But why?
To be able to hide the header's contents from public.
Should I update the commit message?
...
> > +static const struct property_entry spitz_spi_properties[] = {
> > + PROPERTY_ENTRY_U32("num-cs", 3),
> > + { }
> > +};
>
> This is just platform data with less validation AFAICT.
I'm not sure what validation you are expecting here. It should be done via
DT schema ideally when the platform gets converted to DT. This change is
an interim to that (at least it makes kernel side better). After the platform
code may be gone completely or converted. If the latter happens, we got
the validation back.
In any case it's not worse than plain DT property handling in the kernel.
The validation in that case is done elsewhere. Since the property is defined
in board files the assumed validation is done during development/review
stages. But OTOH for the legacy code we need not to touch the property
provider more than once. We are _not_ expecting this to be spread.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-26 18:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-26 18:07 [PATCH v1 00/10] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h Andy Shevchenko
2024-03-26 18:07 ` [PATCH v1 01/10] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr() Andy Shevchenko
2024-03-26 18:16 ` Mark Brown
2024-03-26 18:22 ` Andy Shevchenko
2024-03-26 18:25 ` Mark Brown
2024-03-26 18:44 ` Andy Shevchenko
2024-03-26 18:49 ` Mark Brown
2024-03-26 18:52 ` Andy Shevchenko
2024-03-26 19:10 ` Mark Brown
2024-03-26 19:20 ` Andy Shevchenko
2024-03-26 19:21 ` Andy Shevchenko
2024-03-26 19:32 ` Mark Brown
2024-03-26 20:04 ` Andy Shevchenko
2024-03-26 20:12 ` Mark Brown
2024-03-26 20:17 ` Andy Shevchenko
2024-03-26 18:07 ` [PATCH v1 02/10] spi: pxa2xx: Keep PXA*_SSP types together Andy Shevchenko
2024-03-26 18:07 ` [PATCH v1 03/10] spi: pxa2xx: Switch to use dev_err_probe() Andy Shevchenko
2024-03-26 18:07 ` [PATCH v1 04/10] spi: pxa2xx: Extract pxa2xx_spi_init_ssp() helper Andy Shevchenko
2024-03-26 18:07 ` [PATCH v1 05/10] spi: pxa2xx: Skip SSP initialization if it's done elsewhere Andy Shevchenko
2024-03-26 18:07 ` [PATCH v1 06/10] spi: pxa2xx: Allow number of chip select pins to be read from property Andy Shevchenko
2024-03-26 18:07 ` [PATCH v1 07/10] spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties Andy Shevchenko
2024-03-26 18:21 ` Mark Brown
2024-03-26 18:50 ` Andy Shevchenko [this message]
2024-03-26 20:02 ` Mark Brown
2024-03-26 20:12 ` Andy Shevchenko
2024-03-26 20:26 ` Mark Brown
2024-03-26 21:20 ` Andy Shevchenko
2024-03-26 18:07 ` [PATCH v1 08/10] spi: pxa2xx: Move contents of linux/spi/pxa2xx_spi.h to a local one Andy Shevchenko
2024-03-26 18:07 ` [PATCH v1 09/10] spi: pxa2xx: Remove outdated documentation Andy Shevchenko
2024-03-26 18:08 ` [PATCH v1 10/10] spi: pxa2xx: Don't use "proxy" headers Andy Shevchenko
2024-03-26 20:55 ` (subset) [PATCH v1 00/10] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h Mark Brown
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=ZgMY3AeC1Jnh1Oru@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=daniel@zonque.org \
--cc=haojian.zhuang@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=robert.jarzmik@free.fr \
/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).