On Fri, Nov 1, 2024 at 8:35 PM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Tue, Oct 29, 2024 at 08:23:37PM +0000, Lothar Rubusch wrote:
> > The dwmac 3.72a is an ip version that can be found on Intel/Altera Arria10
> > SoCs. Going by the hardware features "snps,multicast-filter-bins" and
> > "snps,perfect-filter-entries" shall be supported. Thus add a
> > compatibility flag, and extend coverage of the driver for the 3.72a.
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@xxxxxxxxx>
> > ---
> > drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c | 1 +
> > drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c
> > index 598eff926..b9218c07e 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c
> > @@ -56,6 +56,7 @@ static const struct of_device_id dwmac_generic_match[] = {
> > { .compatible = "snps,dwmac-3.610"},
> > { .compatible = "snps,dwmac-3.70a"},
> > { .compatible = "snps,dwmac-3.710"},
> > + { .compatible = "snps,dwmac-3.72a"},
> > { .compatible = "snps,dwmac-4.00"},
> > { .compatible = "snps,dwmac-4.10a"},
> > { .compatible = "snps,dwmac"},
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > index 54797edc9..e7e2d6c20 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > @@ -522,6 +522,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
> > if (of_device_is_compatible(np, "st,spear600-gmac") ||
> > of_device_is_compatible(np, "snps,dwmac-3.50a") ||
> > of_device_is_compatible(np, "snps,dwmac-3.70a") ||
> > + of_device_is_compatible(np, "snps,dwmac-3.72a") ||
>
> All these of_device_is_compatible() checks should really go away and all
> the settings just come from match table data. Then everything is const
> and we're not matching multiple times at run-time. That would be a bit
> of refactoring though...
I can see your point, but I have some doubts on that. As I asked
before, my current scope is actually on upstreaming my .dts/.dtsi
files. This would be nice, since I'm doing it in parallel in u-boot
and they're going to dts/upstream so we're waiting on the kernel
community here.
I'm unclear what additionally to fixing my .dts files is needed. Shall
I fix all? / some? / none? of the errors your dtbs check bot gives?
First, most of the errors come from not covered bindings. Since TXT
files for socfpga never were converted to YAML. Should I do this? I
guess this would increase coverage of dt-bindings check and reduce the
errors tremendously. But I'd see it as a different patch set if so. Is
this needed to upstream my .dts files?
Second, the maintainer of platform socfpga seems to be currently on a
sabbatical. At least I hope he's fine and not sick or burned out. But
also I would like to get some feedback on the .dts files. Please help
me if you can give me some.
Third, when I update things like the mentioned dwmac things and try to
update the driver compatible to best of my knowledge, I understand
that it would be better to refactor a redundantly checked
compatibility to just one check in the driver.
But, I only have one hardware: an Arria10 SOM which is affected here.
And, is it really anyway needed to refactor networking drivers for
upstreamining my .dts/.dtsi files at the end of the day?
Please don't missunderstand me. I can absolutely see your point here
and appreciate all type of feedback. Anyway IMHO these are all
different topics i.e. different sets of patches, or smells a bit like
scope creep. I separated the 2 patches for a different set, as Jakub
wrote.
