From: Larisa Grigore <larisa.grigore@nxp.com>
S32G doesn't have the max prescale erratum and it can query the max
number of CS from hardware, so add those settings.
Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@nxp.com>
Signed-off-by: James Clark <james.clark@linaro.org>
---
drivers/spi/spi-fsl-lpspi.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 6d0138b27785..a4727ca37d90 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -159,9 +159,15 @@ static const struct fsl_lpspi_devtype_data imx7ulp_lpspi_devtype_data = {
.query_hw_for_num_cs = false,
};
+static struct fsl_lpspi_devtype_data s32g_lpspi_devtype_data = {
+ .prescale_err = false,
+ .query_hw_for_num_cs = true,
+};
+
static const struct of_device_id fsl_lpspi_dt_ids[] = {
{ .compatible = "fsl,imx7ulp-spi", .data = &imx7ulp_lpspi_devtype_data,},
{ .compatible = "fsl,imx93-spi", .data = &imx93_lpspi_devtype_data,},
+ { .compatible = "nxp,s32g2-lpspi", .data = &s32g_lpspi_devtype_data,},
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, fsl_lpspi_dt_ids);
--
2.34.1
On Thu, Aug 14, 2025 at 05:06:50PM +0100, James Clark wrote: > From: Larisa Grigore <larisa.grigore@nxp.com> > > S32G doesn't have the max prescale erratum and it can query the max > number of CS from hardware, so add those settings. binding doc should first patch. Create new patch serial for add S32G support only. Frank > > Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com> > Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@nxp.com> > Signed-off-by: James Clark <james.clark@linaro.org> > --- > drivers/spi/spi-fsl-lpspi.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c > index 6d0138b27785..a4727ca37d90 100644 > --- a/drivers/spi/spi-fsl-lpspi.c > +++ b/drivers/spi/spi-fsl-lpspi.c > @@ -159,9 +159,15 @@ static const struct fsl_lpspi_devtype_data imx7ulp_lpspi_devtype_data = { > .query_hw_for_num_cs = false, > }; > > +static struct fsl_lpspi_devtype_data s32g_lpspi_devtype_data = { > + .prescale_err = false, > + .query_hw_for_num_cs = true, > +}; > + > static const struct of_device_id fsl_lpspi_dt_ids[] = { > { .compatible = "fsl,imx7ulp-spi", .data = &imx7ulp_lpspi_devtype_data,}, > { .compatible = "fsl,imx93-spi", .data = &imx93_lpspi_devtype_data,}, > + { .compatible = "nxp,s32g2-lpspi", .data = &s32g_lpspi_devtype_data,}, > { /* sentinel */ } > }; > MODULE_DEVICE_TABLE(of, fsl_lpspi_dt_ids); > > -- > 2.34.1 >
On 14/08/2025 7:25 pm, Frank Li wrote: > On Thu, Aug 14, 2025 at 05:06:50PM +0100, James Clark wrote: >> From: Larisa Grigore <larisa.grigore@nxp.com> >> >> S32G doesn't have the max prescale erratum and it can query the max >> number of CS from hardware, so add those settings. > > binding doc should first patch. Create new patch serial for add S32G > support only. > > Frank I'm not sure putting the binding doc commit first would be right? That would imply it was a valid binding before it really was because the code change hasn't been made yet. Practically both are required so it doesn't really matter which way around they are. As for splitting the set into two, Mark mentioned that he was ok with a single one, so I assume that's fine? The devtype_data changes would conflict unless they were applied in the correct order anyway, implying the need for a single ordered patchset. James >> >> Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com> >> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@nxp.com> >> Signed-off-by: James Clark <james.clark@linaro.org> >> --- >> drivers/spi/spi-fsl-lpspi.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c >> index 6d0138b27785..a4727ca37d90 100644 >> --- a/drivers/spi/spi-fsl-lpspi.c >> +++ b/drivers/spi/spi-fsl-lpspi.c >> @@ -159,9 +159,15 @@ static const struct fsl_lpspi_devtype_data imx7ulp_lpspi_devtype_data = { >> .query_hw_for_num_cs = false, >> }; >> >> +static struct fsl_lpspi_devtype_data s32g_lpspi_devtype_data = { >> + .prescale_err = false, >> + .query_hw_for_num_cs = true, >> +}; >> + >> static const struct of_device_id fsl_lpspi_dt_ids[] = { >> { .compatible = "fsl,imx7ulp-spi", .data = &imx7ulp_lpspi_devtype_data,}, >> { .compatible = "fsl,imx93-spi", .data = &imx93_lpspi_devtype_data,}, >> + { .compatible = "nxp,s32g2-lpspi", .data = &s32g_lpspi_devtype_data,}, >> { /* sentinel */ } >> }; >> MODULE_DEVICE_TABLE(of, fsl_lpspi_dt_ids); >> >> -- >> 2.34.1 >>
On Mon, Aug 18, 2025 at 03:31:08PM +0100, James Clark wrote: > > > On 14/08/2025 7:25 pm, Frank Li wrote: > > On Thu, Aug 14, 2025 at 05:06:50PM +0100, James Clark wrote: > > > From: Larisa Grigore <larisa.grigore@nxp.com> > > > > > > S32G doesn't have the max prescale erratum and it can query the max > > > number of CS from hardware, so add those settings. > > > > binding doc should first patch. Create new patch serial for add S32G > > support only. > > > > Frank > > I'm not sure putting the binding doc commit first would be right? That would > imply it was a valid binding before it really was because the code change > hasn't been made yet. Practically both are required so it doesn't really > matter which way around they are. DT binding descrpit hardware not driver. Verify binding by dt_binding_check not by drivers. When driver use a dt property, which have to descript it first at binding doc. So binding doc patch should be before the driver use property. That's dt team requirement. You can wait for dt team comment this, But I am pertty sure it is ture. > > As for splitting the set into two, Mark mentioned that he was ok with a > single one, so I assume that's fine? The devtype_data changes would conflict > unless they were applied in the correct order anyway, implying the need for > a single ordered patchset. Yes, if there are dependence. Frank > > James > > > > > > > Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com> > > > Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@nxp.com> > > > Signed-off-by: James Clark <james.clark@linaro.org> > > > --- > > > drivers/spi/spi-fsl-lpspi.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c > > > index 6d0138b27785..a4727ca37d90 100644 > > > --- a/drivers/spi/spi-fsl-lpspi.c > > > +++ b/drivers/spi/spi-fsl-lpspi.c > > > @@ -159,9 +159,15 @@ static const struct fsl_lpspi_devtype_data imx7ulp_lpspi_devtype_data = { > > > .query_hw_for_num_cs = false, > > > }; > > > > > > +static struct fsl_lpspi_devtype_data s32g_lpspi_devtype_data = { > > > + .prescale_err = false, > > > + .query_hw_for_num_cs = true, > > > +}; > > > + > > > static const struct of_device_id fsl_lpspi_dt_ids[] = { > > > { .compatible = "fsl,imx7ulp-spi", .data = &imx7ulp_lpspi_devtype_data,}, > > > { .compatible = "fsl,imx93-spi", .data = &imx93_lpspi_devtype_data,}, > > > + { .compatible = "nxp,s32g2-lpspi", .data = &s32g_lpspi_devtype_data,}, > > > { /* sentinel */ } > > > }; > > > MODULE_DEVICE_TABLE(of, fsl_lpspi_dt_ids); > > > > > > -- > > > 2.34.1 > > > >
On Mon, Aug 18, 2025 at 03:31:08PM +0100, James Clark wrote: > On 14/08/2025 7:25 pm, Frank Li wrote: > > binding doc should first patch. Create new patch serial for add S32G > > support only. > I'm not sure putting the binding doc commit first would be right? That would > imply it was a valid binding before it really was because the code change > hasn't been made yet. Practically both are required so it doesn't really > matter which way around they are. It's the general practice everyone has adopted (though in this case the bugfix bits might want to go before the bindings, possibly it's also a bit unusual to do that). An unused binding is more acceptable than an undocumented one.
On 18/08/2025 4:18 pm, Mark Brown wrote: > On Mon, Aug 18, 2025 at 03:31:08PM +0100, James Clark wrote: >> On 14/08/2025 7:25 pm, Frank Li wrote: > >>> binding doc should first patch. Create new patch serial for add S32G >>> support only. > >> I'm not sure putting the binding doc commit first would be right? That would >> imply it was a valid binding before it really was because the code change >> hasn't been made yet. Practically both are required so it doesn't really >> matter which way around they are. > > It's the general practice everyone has adopted (though in this case the > bugfix bits might want to go before the bindings, possibly it's also a > bit unusual to do that). An unused binding is more acceptable than an > undocumented one. Fair enough. I can flip them in the next version.
© 2016 - 2025 Red Hat, Inc.