netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Danzberger <dd@embedd.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: woojung.huh@microchip.com, UNGLinuxDriver@microchip.com,
	 netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH] net: dsa: microchip: fix NULL pointer dereference on platform init
Date: Tue, 05 Dec 2023 23:15:58 +0100	[thread overview]
Message-ID: <52f88c8bf0897f1b97360fd4f94bdfe2e18f6cc0.camel@embedd.com> (raw)
In-Reply-To: <20231205181735.csbtkcy3g256kwxl@skbuf>

On Tue, 2023-12-05 at 20:17 +0200, Vladimir Oltean wrote:
> On Tue, Dec 05, 2023 at 06:33:18PM +0100, Daniel Danzberger wrote:
> > On Tue, 2023-12-05 at 18:55 +0200, Vladimir Oltean wrote:
> > > On Tue, Dec 05, 2023 at 09:00:39AM +0100, Daniel Danzberger wrote:
> > > > > Is this all that's necessary for instantiating the ksz driver through
> > > > > ds->dev->platform_data? I suppose not, so can you post it all, please?
> > > > Yes, that NULL pointer was the only issue I encountered.
> > > 
> > > I was just thinking, the KSZ9477 has internal PHYs on ports 0-4, and an
> > > internal MDIO bus registered in ksz_mdio_register(). The bus registration
> > > won't work without OF, since it returns early when not finding
> > > of_get_child_by_name(dev->dev->of_node, "mdio").
> > Interesting, I did not notice that.
> > After the NULL pointer issue was fixed the switch just worked.
> > > 
> > > Don't you need the internal PHY ports to work?
> > For now the switch seems to run just fine, with port 0 being the CPU port and 1-4 being used as
> > regular switch ports.
> > I will do some more testing this week however...
> 
> What does "regular switch ports" mean? L2 forwarding between them?
> Could you give us an "ip addr" output?
root@t2t-ngr421:~# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1502 qdisc mq state UP group default qlen 1000
    link/ether 00:13:95:55:cf:d7 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::213:95ff:fe55:cfd7/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
3: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group
default qlen 1000
    link/ether 00:13:95:55:cf:d7 brd ff:ff:ff:ff:ff:ff
4: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state
LOWERLAYERDOWN group default qlen 1000
    link/ether 00:13:95:55:cf:d7 brd ff:ff:ff:ff:ff:ff
5: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state
LOWERLAYERDOWN group default qlen 1000
    link/ether 00:13:95:55:cf:d7 brd ff:ff:ff:ff:ff:ff
6: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state
LOWERLAYERDOWN group default qlen 1000
    link/ether 00:13:95:55:cf:d7 brd ff:ff:ff:ff:ff:ff
7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:13:95:55:cf:d7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.1/24 brd 192.168.20.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd4e:2bf5:cc74::1/60 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::213:95ff:fe55:cfd7/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

The lan* devices are then bridged together:

root@t2t-ngr421:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br-lan		7fff.00139555cfd7	no		lan4
							lan2
							lan3
							lan1


-- 
Regards

Daniel Danzberger
embeDD GmbH, Alter Postplatz 2, CH-6370 Stans

  reply	other threads:[~2023-12-05 22:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-04 15:43 [PATCH] net: dsa: microchip: fix NULL pointer dereference on platform init Daniel Danzberger
2023-12-04 17:43 ` Vladimir Oltean
2023-12-05  8:00   ` Daniel Danzberger
2023-12-05  8:36     ` Vladimir Oltean
2023-12-05  9:08       ` Daniel Danzberger
2023-12-05  9:39         ` Vladimir Oltean
2023-12-05 16:55     ` Vladimir Oltean
2023-12-05 17:33       ` Daniel Danzberger
2023-12-05 18:17         ` Vladimir Oltean
2023-12-05 22:15           ` Daniel Danzberger [this message]
2023-12-06  0:37             ` Vladimir Oltean
2023-12-06 15:26               ` Andrew Lunn
2023-12-06 21:49                 ` Vladimir Oltean
2023-12-05 10:12 ` Vladimir Oltean
2023-12-05 11:44   ` Daniel Danzberger
2023-12-05 12:04     ` Vladimir Oltean
2023-12-05 12:42       ` Vladimir Oltean

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=52f88c8bf0897f1b97360fd4f94bdfe2e18f6cc0.camel@embedd.com \
    --to=dd@embedd.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=woojung.huh@microchip.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;
as well as URLs for NNTP newsgroup(s).