ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

arch/arm/configs/exynos_defconfig CONFIG_BLK_DEV_DM=y · line 67

Quoted 12 lines · On Thursday 08 October 2015 03:48:36 Anand Moon wrote:

arch/arm/configs/exynos_defconfig +1 -0

index 1ff2bfa..5d1937b 100644
@@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y
 CONFIG_DM_CRYPT=m
 CONFIG_NETDEVICES=y
 CONFIG_SMSC911X=y
+CONFIG_USB_RTL8152=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y

Can we make that a loadable module for multi_v7_defconfig?

Quoted 15 lines · Arnd Bergmann

arch/arm/configs/exynos_defconfig CONFIG_BLK_DEV_DM=y · line 67

Quoted 12 lines · On Thursday 08 October 2015 03:48:36 Anand Moon wrote:

arch/arm/configs/exynos_defconfig +1 -0

index 1ff2bfa..5d1937b 100644
@@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y
 CONFIG_DM_CRYPT=m
 CONFIG_NETDEVICES=y
 CONFIG_SMSC911X=y
+CONFIG_USB_RTL8152=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y

Can we make that a loadable module for multi_v7_defconfig?

What about nfsroot boots? We were discussing this also here:
http://linux-arm-kernel.infradead.narkive.com/lG5g4hrB/patch-arm-multi-v7-defconfig-enable-usb3503

and actually I would be happy to see a confirmed policy about that. Everything should be a module for multi_v7?

Quoted 22 lines · On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:

Quoted 16 lines · Arnd Bergmann

arch/arm/configs/exynos_defconfig CONFIG_BLK_DEV_DM=y · line 67

Quoted 13 lines · On Thursday 08 October 2015 03:48:36 Anand Moon wrote:

arch/arm/configs/exynos_defconfig +1 -0

index 1ff2bfa..5d1937b 100644
@@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y
 CONFIG_DM_CRYPT=m
 CONFIG_NETDEVICES=y
 CONFIG_SMSC911X=y
+CONFIG_USB_RTL8152=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y

Can we make that a loadable module for multi_v7_defconfig?

What about nfsroot boots? We were discussing this also here:
http://linux-arm-kernel.infradead.narkive.com/lG5g4hrB/patch-arm-mu
lti-v7-defconfig-enable-usb3503

Quoted 2 lines

and actually I would be happy to see a confirmed policy about that. Everything should be a module for multi_v7?

We try to make as much as possible modular here, and NFS root is a corner
case: it's possible to do NFS root with an initramfs, but it's easier not
to. Is it something you do a lot on this hardware?

Quoted 23 lines · Arnd Bergmann

Quoted 22 lines · On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:

Quoted 16 lines · Arnd Bergmann

arch/arm/configs/exynos_defconfig CONFIG_BLK_DEV_DM=y · line 67

Quoted 13 lines · On Thursday 08 October 2015 03:48:36 Anand Moon wrote:

arch/arm/configs/exynos_defconfig +1 -0

index 1ff2bfa..5d1937b 100644
@@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y
 CONFIG_DM_CRYPT=m
 CONFIG_NETDEVICES=y
 CONFIG_SMSC911X=y
+CONFIG_USB_RTL8152=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y

Can we make that a loadable module for multi_v7_defconfig?

What about nfsroot boots? We were discussing this also here:
http://linux-arm-kernel.infradead.narkive.com/lG5g4hrB/patch-arm-mu
lti-v7-defconfig-enable-usb3503

Quoted 8 lines

Quoted 2 lines

and actually I would be happy to see a confirmed policy about that. Everything should be a module for multi_v7?

We try to make as much as possible modular here, and NFS root is a corner
case: it's possible to do NFS root with an initramfs, but it's easier not
to. Is it something you do a lot on this hardware?

It's a workflow thing though, not a hardware specific thing. I personally tend to use NFS root quite often and so do various colleagues irrespective of the hardware (and an XU4 is bound to appear on my desk someday).

Now I personally really don't mind whether NFS root requires a ramdisk or not (though some consistency would be nice). However deciding it on a per device basis just makes everything quite fuzzy (e.g. my recent rockchip multi_v7 patchset first ended up in a similar discussion, though v2 was merged without further comments when I indicated in the cover letter that i used the NFS root use-case as one of the deciding factors for y vs. m).

It would be really good to see someone put their foot down on the general policy (e.g. the arm-soc maintainers?), such that this discussion doesn't need to happen every time

Quoted 46 lines · On Thursday 08 October 2015 11:27:13 Sjoerd Simons wrote:

Quoted 23 lines · Arnd Bergmann

Quoted 22 lines · On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:

Quoted 16 lines · Arnd Bergmann

arch/arm/configs/exynos_defconfig CONFIG_BLK_DEV_DM=y · line 67

Quoted 13 lines · On Thursday 08 October 2015 03:48:36 Anand Moon wrote:

arch/arm/configs/exynos_defconfig +1 -0

index 1ff2bfa..5d1937b 100644
@@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y
 CONFIG_DM_CRYPT=m
 CONFIG_NETDEVICES=y
 CONFIG_SMSC911X=y
+CONFIG_USB_RTL8152=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y

Can we make that a loadable module for multi_v7_defconfig?

What about nfsroot boots? We were discussing this also here:
http://linux-arm-kernel.infradead.narkive.com/lG5g4hrB/patch-arm-mu
lti-v7-defconfig-enable-usb3503

Quoted 8 lines

Quoted 2 lines

and actually I would be happy to see a confirmed policy about that. Everything should be a module for multi_v7?

We try to make as much as possible modular here, and NFS root is a corner
case: it's possible to do NFS root with an initramfs, but it's easier not
to. Is it something you do a lot on this hardware?

It's a workflow thing though, not a hardware specific thing. I personally tend to use NFS root quite often and so do various colleagues irrespective of the hardware (and an XU4 is bound to appear on my desk someday).

Now I personally really don't mind whether NFS root requires a ramdisk or not (though some consistency would be nice). However deciding it on a per device basis just makes everything quite fuzzy (e.g. my recent rockchip multi_v7 patchset first ended up in a similar discussion, though v2 was merged without further comments when I indicated in the cover letter that i used the NFS root use-case as one of the deciding factors for y vs. m).

Quoted 3 lines

It would be really good to see someone put their foot down on the general policy (e.g. the arm-soc maintainers?), such that this discussion doesn't need to happen every time

Yes, agreed, that what I'm trying to do here ;-)

I realize that building things as modules is a hassle, it is so for some things more than for others, so I keep asking the question to everyone to find out what a good balance is to make as much as possible modules without hurting too much.

Once we have a firm policy in place, we should probably change all the existing symbols.

Arnd

As long as we use correct exynos5422-odroidxu4.dtb is used in the boot.scr/boot.ini ethernet come up,
build and tested using CONFIG_USB_RTL8152=m using multi_v7_defconfig.

Not sure what is the policy for NFS booting.

Do you want CONFIG_USB_RTL8152 to be build as module in exynos/multi_v7_defconfig.

Quoted 56 lines · On Thursday 08 October 2015 11:27:13 Sjoerd Simons wrote:

Quoted 28 lines · Arnd Bergmann

Quoted 18 lines · On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:

Quoted 16 lines · Arnd Bergmann

arch/arm/configs/exynos_defconfig CONFIG_BLK_DEV_DM=y · line 67

Quoted 13 lines · On Thursday 08 October 2015 03:48:36 Anand Moon wrote:

arch/arm/configs/exynos_defconfig +1 -0

index 1ff2bfa..5d1937b 100644
@@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y
 CONFIG_DM_CRYPT=m
 CONFIG_NETDEVICES=y
 CONFIG_SMSC911X=y
+CONFIG_USB_RTL8152=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y

Can we make that a loadable module for multi_v7_defconfig?

Quoted 8 lines

What about nfsroot boots? We were discussing this also here:
http://linux-arm-kernel.infradead.narkive.com/lG5g4hrB/patch-ar
m-mu
lti-v7-defconfig-enable-usb3503

and actually I would be happy to see a confirmed policy about that.
Everything should be a module for multi_v7?

Quoted 7 lines

We try to make as much as possible modular here, and NFS root is a
corner
case: it's possible to do NFS root with an initramfs, but it's easier
not
to. Is it something you do a lot on this hardware?

It's a workflow thing though, not a hardware specific thing. I personally tend to use NFS root quite often and so do various colleagues irrespective of the hardware (and an XU4 is bound to appear
on my desk someday).

Now I personally really don't mind whether NFS root requires a ramdisk
or not (though some consistency would be nice). However deciding it on
a per device basis just makes everything quite fuzzy (e.g. my recent
rockchip multi_v7 patchset first ended up in a similar discussion, though v2 was merged without further comments when I indicated in the
cover letter that i used the NFS root use-case as one of the deciding
factors for y vs. m).

Quoted 3 lines

It would be really good to see someone put their foot down on the general policy (e.g. the arm-soc maintainers?), such that this discussion doesn't need to happen every time

Yes, agreed, that what I'm trying to do here ;-)

I realize that building things as modules is a hassle, it is so for some things more than for others, so I keep asking the question to everyone to find out what a good balance is to make as much as possible modules without hurting too much.

Once we have a firm policy in place, we should probably change all the existing symbols.

Quoted 5 lines

I realize that building things as modules is a hassle, it is so for some things more than for others, so I keep asking the question to everyone to find out what a good balance is to make as much as possible modules without hurting too much.

Fwiw, I don't find building modules overly cumbersome. Getting an initramfs capable of moving on to an NFS root is mostly a one-time thing (not unlike setting up the nfs root itself) and injecting modules into it is relatively simple (doubly so if taking advantage of the multiple cpio archive feature linux has).

Interestingly, for me not building things as modules in multi_v7 tends to cause more work as it hides a few categories of bugs that tend to crop up once building distro kernels (e.g. missing module aliases, missing module device table entries, implicitly relying on clocks being active during probe as unused clocks only get turned of late in the init sequence etc).

Quoted 12 lines

Quoted 5 lines

I realize that building things as modules is a hassle, it is so for some things more than for others, so I keep asking the question to everyone to find out what a good balance is to make as much as possible modules without hurting too much.

Fwiw, I don't find building modules overly cumbersome. Getting an initramfs capable of moving on to an NFS root is mostly a one-time thing (not unlike setting up the nfs root itself) and injecting modules into it is relatively simple (doubly so if taking advantage of the multiple cpio archive feature linux has).

Quoted 7 lines

Interestingly, for me not building things as modules in multi_v7 tends to cause more work as it hides a few categories of bugs that tend to crop up once building distro kernels (e.g. missing module aliases, missing module device table entries, implicitly relying on clocks being active during probe as unused clocks only get turned of late in the init sequence etc).

Ok, let's try to make all future network drivers modules in the multi_v7_defconfig then, and get people to use an initramfs if they need NFS root. If nobody complains too loudly for the next few releases, we can change the existing drivers to =m as well.

W dniu 09.10.2015 o 19:28, Arnd Bergmann pisze:

Quoted 21 lines · On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote:

Quoted 12 lines

Quoted 5 lines

I realize that building things as modules is a hassle, it is so for some things more than for others, so I keep asking the question to everyone to find out what a good balance is to make as much as possible modules without hurting too much.

Fwiw, I don't find building modules overly cumbersome. Getting an initramfs capable of moving on to an NFS root is mostly a one-time thing (not unlike setting up the nfs root itself) and injecting modules into it is relatively simple (doubly so if taking advantage of the multiple cpio archive feature linux has).

Quoted 7 lines

Interestingly, for me not building things as modules in multi_v7 tends to cause more work as it hides a few categories of bugs that tend to crop up once building distro kernels (e.g. missing module aliases, missing module device table entries, implicitly relying on clocks being active during probe as unused clocks only get turned of late in the init sequence etc).

Quoted 4 lines

Ok, let's try to make all future network drivers modules in the multi_v7_defconfig then, and get people to use an initramfs if they need NFS root. If nobody complains too loudly for the next few releases, we can change the existing drivers to =m as well.

Personally I don't use NFS root and we don't have such configurations at work. At least I am not aware of such. So from my point of view network adapters as module is okay.

Anand,
Can you change it in multi_v7 patch to module?

Best regards,
Krzysztof