[linux-yocto][v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g][PATCH 2/2] dts: Aptiv-FL: enable gmac0 device node
From: Quanyang Wang
Enable gmac0 device and set it to be a fixed link.
Signed-off-by: Quanyang Wang
---
arch/arm64/boot/dts/freescale/s32gxxxa-cvc-fl.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/s32gxxxa-cvc-fl.dtsi
b/arch/arm64/boot/dts/freescale/s32gxxxa-cvc-fl.dtsi
index f3569655f83d4..537eda907e80d 100644
--- a/arch/arm64/boot/dts/freescale/s32gxxxa-cvc-fl.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32gxxxa-cvc-fl.dtsi
@@ -37,11 +37,15 @@ &qspi {
&gmac0 {
/* Before enabling SJA1110, set it to be "disabled" */
- status = "disabled";
+ status = "okay";
phy-mode = "rgmii";
phy-handle = <&gmac0_mdio_c_phy19>;
pinctrl-names = "default";
pinctrl-0 = <&gmac0rgmiic_pins>, <&gmac0mdioc_pins>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
&gmac0_mdio {
--
2.36.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13352):
https://lists.yoctoproject.org/g/linux-yocto/message/13352
Mute This Topic: https://lists.yoctoproject.org/mt/102966201/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g][PATCH 1/2] drivers: stmmac: add condition check on phydev
From: Quanyang Wang When stmmac is using fixed-link mode, dev->phydev is NULL after calling stmmac_init_phy, so we need to add condition check if dev->phydev is NULL pointer. This patch is to fix the following calltrace: Unable to handle kernel NULL pointer dereference at virtual address 0435 Mem abort info: ESR = 0x9605 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x0005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=000882fea000 [0435] pgd=, p4d=, pud= Internal error: Oops: 9605 [#1] PREEMPT_RT SMP Modules linked in: 8021q pfeng(O) s32cc_adc llce_core ci_hdrc_imx usbmisc_imx flexcan firmware_class industrialio_triggered_buffer i2c_imx kfifo_buf pwm_fsl_ftm sch_fq_codel openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 fuse CPU: 5 PID: 375 Comm: dhcpcd Tainted: G O 6.1.62-rt10-yocto-preempt-rt #66 Hardware name: Freescale S32G399A (DT) pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __stmmac_open+0x374/0x418 lr : __stmmac_open+0x370/0x418 sp : ffc00c633a50 x29: ffc00c633a50 x28: 1043 x27: ff8800371e00 x26: x25: 000a x24: ff8802eec240 x23: ff8800d8dc10 x22: ff8800cae000 x21: x20: ff88026c8000 x19: ff88026c89c0 x18: 0020 x17: x16: x15: ff8802eec6d8 x14: 0001 x13: ffc0094cfefa x12: ffc0094cfef6 x11: 0040 x10: 000a x9 : ffc0080a5414 x8 : 000a x7 : 647968703d3d3d3d x6 : x5 : ff885bfb6ae0 x4 : x3 : 0027 x2 : x1 : x0 : 0018 Call trace: __stmmac_open+0x374/0x418 stmmac_open+0x48/0xa0 __dev_open+0x10c/0x1c8 __dev_change_flags+0x174/0x1d0 dev_change_flags+0x2c/0x70 devinet_ioctl+0x664/0x738 inet_ioctl+0x1e4/0x1f8 sock_do_ioctl+0x50/0x100 sock_ioctl+0x234/0x358 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x58/0x120 el0_svc_common.constprop.0+0x4c/0xf8 do_el0_svc+0x34/0xc0 el0_svc+0x2c/0x88 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x18c/0x190 Code: b0003440 910f6000 940f8975 f9448a81 (3950d420) Signed-off-by: Quanyang Wang --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 460aaf5a430e2..6c5d5c562c70d 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -3894,7 +3894,8 @@ static int __stmmac_open(struct net_device *dev, stmmac_enable_all_dma_irq(priv); /* Indicate that the MAC is responsible for PHY PM */ - dev->phydev->mac_managed_pm = true; + if (dev->phydev) + dev->phydev->mac_managed_pm = true; return 0; -- 2.36.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13351): https://lists.yoctoproject.org/g/linux-yocto/message/13351 Mute This Topic: https://lists.yoctoproject.org/mt/102966200/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g][PATCH 0/2]
From: Quanyang Wang Hi Bruce, Would you please help merge these 2 patches to the branches: v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g v6.1/standard/nxp-sdk-5.15/nxp-s32g Thanks, Quanyang Quanyang Wang (2): drivers: stmmac: add condition check on phydev dts: Aptiv-FL: enable gmac0 device node arch/arm64/boot/dts/freescale/s32gxxxa-cvc-fl.dtsi | 6 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++- 2 files changed, 7 insertions(+), 2 deletions(-) -- 2.36.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13350): https://lists.yoctoproject.org/g/linux-yocto/message/13350 Mute This Topic: https://lists.yoctoproject.org/mt/102966199/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
On Thu, Nov 30, 2023 at 11:38 PM Liu, Yongxin wrote:
>
> > -Original Message-
> > From: Gortmaker, Paul
> > Sent: Friday, December 1, 2023 11:14
> > To: Liu, Yongxin
> > Cc: Bruce Ashfield ; linux-
> > yo...@lists.yoctoproject.org
> > Subject: Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number
> > of CPUs
> >
> > [RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs]
> > On 30/11/2023 (Thu 21:43) Liu, Yongxin wrote:
> >
> > > > -Original Message-
> > > > From: Gortmaker, Paul
> > > > Sent: Friday, December 1, 2023 10:27
> > > > To: Liu, Yongxin
> > > > Cc: Bruce Ashfield ; linux-
> > > > yo...@lists.yoctoproject.org
> > > > Subject: Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for
> > > > number of CPUs
> > > >
> > > > [RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number
> > > > of CPUs] On 30/11/2023 (Thu 20:12) Liu, Yongxin wrote:
> > > >
> > > > > > -Original Message-
> > > > > > From: linux-yocto@lists.yoctoproject.org > > > > > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> > > > > > lists.yoctoproject.org
> > > > > > Sent: Friday, December 1, 2023 03:08
> > > > > > To: Bruce Ashfield
> > > > > > Cc: linux-yocto@lists.yoctoproject.org
> > > > > > Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for
> > > > > > number of CPUs
> > > > > >
> > > > > > From: Paul Gortmaker
> > > > > >
> > > > > > The x86-64 BSP isn't quite the same as the "more specific" BSP
> > > > > > like a Beaglebone Black or the (now deleted) Edgerouter. Where
> > > > > > we have exact hardware specifics for boards like those, the
> > > > > > x86-64 BSP is more of a "generic" thing used as the baseline
> > > > > > across an endless sea
> > > > of boards.
> > > > > >
> > > > > > To that end, this is somewhat a revert of commit bd77e1f904f6
> > > > > > ("bsp/intel-x86: change the supported maximum number of CPUs to
> > > > > > 512 in 64- bit bsp")
> > > > > >
> > > > > > It is great that a handful of people out there are using Yocto
> > > > > > on these huge server machines, but that doesn't reflect 99% of
> > > > > > the rest of us who continue to lean towards the original
> > > > > > "embedded theme" of
> > > > Yocto.
> > > > > >
> > > > > > That means a whole bunch of extra per-CPU jumping through hoops;
> > > > > > some can be mitigated by booting with "nr_cpus=4" (or whatever
> > > > > > the core count
> > > > > > is) but I guarantee largely nobody out there is doing that.
> > > > > >
> > > > > > Let those users with the crazy CPU count own that config
> > > > > > customization locally. The default is 64 which still seems way
> > > > > > too large IMHO, but at least we are moving in the right direction.
> > > > >
> > > > >
> > > > > This intel-x86-64 BSP is a generic one used from mobile to server.
> > > > >
> > > > > Customers need to customize not only the CPU number config but
> > > > > also other configs, like, removing unused drivers or adding debug
> > options.
> > > > > From this point of view, there is no difference between 64 or 512.
> > >
> > > I changed 64 to 512. Because we have server machines with more than 64
> > CPU.
> > > I want the BSP support those machines by default.
> >
> > But you still miss the point. It doesn't matter what you or any company
> > "want" in this case. Like it or not, it is a shared resource and so the
> > defaults have to be what is good for Yocto project and not for *you*
> >
> > >
> > > >
> > > > So you've basically argued my case for me. If changes are
> > > > inevitable, then why do we change the default?
> > > >
> > > > > But it changes the "rule" that intel-x86-64 works for all
> > > > > supported
> > > > platforms.
> > > > > We need to do extra work for servers with large CPU number.
> > > >
> > > > No. There is no "rule" in Yocto like that. That is nonsense
> > > > because there is no way Yocto can commit to "support" all the crazy
> > > > different
> > > > x86-64 variants out there.
> > >
> > >
> > > I think this "bsp/intel-x86" is used only by Wind River.
> > > So bsp/intel-x86 should work for all supported machines claimed by Wind
> > River.
> >
> > No. That is where you are dead wrong. Wind River does not own Yocto.
> > Think for a minute. A new Yocto user comes along and sees "intel-x86"
> > and because that name is so generic -- thinks "I'll build that for my old
> > PC."
>
> I have a question why we need bsp/intel-x86, because Yocto already has
> bsp/intel-common and bsp/common-pc?
>
>
> >
> > > If we need to do some local change to support some machine. That's not
> > good.
> > > Because people usually build image with default configs and then
> > complain something doesn't work.
> >
> > Again, it is NOT the problem of the Yocto project what isn't good for YOU.
> > If you need EDAC and NUMA and 500+ CPU support, then make a proper BSP
> > with those settings and submit it as "bsp/mega-server-2000" or whatever.
>
> Then I think we should revise bsp/
[linux-yocto] Trial merge of v5.15.139 v5.15.140 v5.15.141 v6.1.63 v6.1.64 v6.1.65 for linux-yocto
Hi Bruce, This is a trial merge of the stable kernel v5.15.139 v5.15.140 v5.15.141 v6.1.63 v6.1.64 v6.1.65 for the following branches in the linux-yocto. 0352666c1d49 v5.15/standard/sdkv5.10/axxia ef6b4a29d7c3 v5.15/standard/preempt-rt/sdkv5.10/axxia 17a4f2b6112d v5.15/standard/base e3b78ce10900 v5.15/standard/preempt-rt/base 721598769f6c v5.15/standard/cn-sdkv5.4/octeon #Have textual conflicts acef382e68b4 v5.15/standard/preempt-rt/cn-sdkv5.4/octeon #Have textual conflicts ceea32b1bac3 v5.15/standard/cn-sdkv5.15/octeon #Have textual conflicts 2740c9c2cd17 v5.15/standard/preempt-rt/cn-sdkv5.15/octeon #Have textual conflicts 72b1a3810300 v5.15/standard/ti-sdk-5.10/ti-j72xx #Have textual conflicts 9808d3be535f v5.15/standard/preempt-rt/ti-sdk-5.10/ti-j72xx #Have textual conflicts 5b2cd316e5d7 v5.15/standard/nxp-sdk-5.15/nxp-soc #Have textual conflicts 32456cf4f4d4 v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc #Have textual conflicts 3c67b1e649e6 v5.15/standard/bcm-2xxx-rpi 2b96a4a670ad v5.15/standard/preempt-rt/bcm-2xxx-rpi d234859b0c4c v5.15/standard/nxp-sdk-5.15/nxp-s32g 8bb3e145661f v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g 5e18be40f33b v5.15/standard/intel-sdk-5.15/intel-socfpga 9a71b246d92a v5.15/standard/preempt-rt/intel-sdk-5.15/intel-socfpga 8ddafcb21f53 v5.15/standard/x86 e5b2e6e4149d v5.15/standard/preempt-rt/x86 cb5476610eac v5.15/standard/sdkv5.15/xlnx-soc #Have textual conflicts dbafaeed50a0 v5.15/standard/preempt-rt/sdkv5.15/xlnx-soc #Have textual conflicts df7d92109d0b v6.1/standard/sdkv5.10/axxia 1684e38b4edf v6.1/standard/preempt-rt/sdkv5.10/axxia 6409c1fca71b v6.1/standard/base f3024223c728 v6.1/standard/preempt-rt/base f33ec558ba26 v6.1/standard/ti-sdk-6.1/ti-j7xxx #Have textual conflicts 4f19d0d5b031 v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx #Have textual conflicts 39db2ae93c0f v6.1/standard/nxp-sdk-6.1/nxp-soc #Have textual conflicts aafd1a13e8a8 v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc #Have textual conflicts 4123aa109af2 v6.1/standard/cn-sdkv5.15/octeon #Have textual and semantic conflicts e3eca79b2af1 v6.1/standard/preempt-rt/cn-sdkv5.15/octeon #Have textual and semantic conflicts 57d7e3aba9f4 v6.1/standard/microchip-polarfire-soc 237e9607299c v6.1/standard/preempt-rt/microchip-polarfire-soc 0addbc847781 v6.1/standard/bcm-2xxx-rpi #Have textual conflicts 17de1019def8 v6.1/standard/preempt-rt/bcm-2xxx-rpi #Have textual conflicts b3de578ed156 v6.1/standard/nxp-sdk-5.15/nxp-s32g 9eb121a7db94 v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g a9544f7a93a0 v6.1/standard/intel-sdk-6.1/intel-socfpga 2cf0fbfdd69a v6.1/standard/preempt-rt/intel-sdk-6.1/intel-socfpga 2abf396e5074 v6.1/standard/x86 42ed29e3d167 v6.1/standard/preempt-rt/x86 85fddbed50e6 v6.1/standard/sdkv6.1/xlnx-soc #Have textual conflicts b20da95bb266 v6.1/standard/preempt-rt/sdkv6.1/xlnx-soc #Have textual conflicts There are many nasty merge conflicts when merging v6.1.63 on the octeon branches. I hope I have resolved them all correctly. There are also some merge conflicts for other stable releases, but they are not particular difficult to handle. All the branches have passed my build test. I have pushed all these branches to: https://github.com/haokexin/linux You can use this as a reference for the linux-yocto stable kernel bump. Thanks, Kevin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13348): https://lists.yoctoproject.org/g/linux-yocto/message/13348 Mute This Topic: https://lists.yoctoproject.org/mt/102948914/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
