mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
To: Daniel Golle <daniel@makrotopia.org>, Elad Yifee <eladwf@gmail.com>
Cc: Felix Fietkau <nbd@nbd.name>, Sean Wang <sean.wang@mediatek.com>,
	Mark Lee <Mark-MC.Lee@mediatek.com>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH net-next] net: ethernet: mediatek: Allow gaps in MAC allocation
Date: Fri, 5 Jul 2024 14:55:35 +0200	[thread overview]
Message-ID: <2e441889-cb53-4004-aeed-1268d20b54b7@intel.com> (raw)
In-Reply-To: <ZofX4qfGf93Q8jys@makrotopia.org>

On 7/5/24 13:24, Daniel Golle wrote:
> Hi netdev maintainers,
> 

TL;DR
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>

and no-one provided feedback against merging this patch so far

> On Tue, Jul 02, 2024 at 09:05:19AM +0000, Daniel Golle wrote:
>>> what about:
>>> 4733│ static int mtk_sgmii_init(struct mtk_eth *eth)
>>> 4734│ {
>>> 4735│         struct device_node *np;
>>> 4736│         struct regmap *regmap;
>>> 4737│         u32 flags;
>>> 4738│         int i;
>>> 4739│
>>> 4740│         for (i = 0; i < MTK_MAX_DEVS; i++) {
>>> 4741│                 np = of_parse_phandle(eth->dev->of_node, "mediatek,sgmiisys", i);
>>> 4742│                 if (!np)
>>> 4743│                         break;
>>>
>>> should we also continue here?
>>
>> Good point. As sgmiisys is defined in dtsi it's not so relevant in
>> practise though, as the SoC components are of course always present even
>> if we don't use them. Probably it is still better to not be overly
>> strict on the presence of things we may not even use, not even emit an
>> error message and silently break something else, so yes, worth fixing
>> imho.
>>
> 
> I've noticed that this patch was marked as "Changes Requested" on patchwork
> despite having received a positive review.
> 
> I'm afraid this is possibly due to a misunderstanding:
> 
> The (unrelated and rather exotic) similar issue pointed to by Przemek
> Kitszel should not be fixed in the same commit. It is unrelated, and if
> at all, should be sent to 'net' tree rather than 'net-next'.
> 
> Looking at it more closely I would not consider it an issue as we
> currently in the bindings we **require** the correct number of sgmiisys phandles to be
> present for each SoC supporting SGMII:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/mediatek,net.yaml#n200
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/mediatek,net.yaml#n245
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/mediatek,net.yaml#n287
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/mediatek,net.yaml#n325
> 
> Hence there aren't ever any gaps, also because the sgmiisys phandles are
> defined in the SoC-specific DTSI **even for boards not making any use of
> them**.
> 
> I hence would like this very patch to be merged (or at least discussed)
> as-is, and if there is really a need to address the issue mentioned by
> Przemek Kitszel, then deal with it in a separate commit.
> 
> 
> Cheers
> 
> 
> Daniel

you are right, I have even marked this specifically as Reviewed-by: $me,
so I think is just a mistake to mark it as CR
(without the RB tag, it will be wise to mark such comments as no-issue
or similar, and I typically do so)

  reply	other threads:[~2024-07-05 12:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-01 19:28 Daniel Golle
2024-07-02  6:58 ` Przemek Kitszel
2024-07-02  9:05   ` Daniel Golle
2024-07-05 11:24     ` Daniel Golle
2024-07-05 12:55       ` Przemek Kitszel [this message]
2024-07-06  0:00 ` patchwork-bot+netdevbpf

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=2e441889-cb53-4004-aeed-1268d20b54b7@intel.com \
    --to=przemyslaw.kitszel@intel.com \
    --cc=Mark-MC.Lee@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eladwf@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=lorenzo@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sean.wang@mediatek.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

all inboxes | Powered by JetHome®