diff mbox

[PATCHv3,1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

Message ID 1444276117-3657-1-git-send-email-linux.amoon@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Anand Moon Oct. 8, 2015, 3:48 a.m. UTC 
Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over
USB 3.0.

Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

---
Changes: Fixed the commit message thanks to Krzysztof Kozlowski
         Added reviewed by Krzysztof Kozlowski
---
 arch/arm/configs/exynos_defconfig | 1 +
 1 file changed, 1 insertion(+)

Comments

Arnd Bergmann Oct. 8, 2015, 7:41 a.m. UTC | #1 
On Thursday 08 October 2015 03:48:36 Anand Moon wrote:
> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index 1ff2bfa..5d1937b 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -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?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Krzysztof Kozlowski Oct. 8, 2015, 7:46 a.m. UTC | #2 
On 08.10.2015 16:41, Arnd Bergmann wrote:
> On Thursday 08 October 2015 03:48:36 Anand Moon wrote:
>> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
>> index 1ff2bfa..5d1937b 100644
>> --- a/arch/arm/configs/exynos_defconfig
>> +++ b/arch/arm/configs/exynos_defconfig
>> @@ -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?

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann Oct. 8, 2015, 8:37 a.m. UTC | #3 
On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:
> On 08.10.2015 16:41, Arnd Bergmann wrote:
> > On Thursday 08 October 2015 03:48:36 Anand Moon wrote:
> >> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> >> index 1ff2bfa..5d1937b 100644
> >> --- a/arch/arm/configs/exynos_defconfig
> >> +++ b/arch/arm/configs/exynos_defconfig
> >> @@ -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?

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?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sjoerd Simons Oct. 8, 2015, 9:27 a.m. UTC | #4 
On Thu, 2015-10-08 at 10:37 +0200, Arnd Bergmann wrote:
> On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:
> > On 08.10.2015 16:41, Arnd Bergmann wrote:
> > > On Thursday 08 October 2015 03:48:36 Anand Moon wrote:
> > > > diff --git a/arch/arm/configs/exynos_defconfig
> > > > b/arch/arm/configs/exynos_defconfig
> > > > index 1ff2bfa..5d1937b 100644
> > > > --- a/arch/arm/configs/exynos_defconfig
> > > > +++ b/arch/arm/configs/exynos_defconfig
> > > > @@ -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
> > 
> > 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 :)
Arnd Bergmann Oct. 8, 2015, 2:41 p.m. UTC | #5 
On Thursday 08 October 2015 11:27:13 Sjoerd Simons wrote:
> On Thu, 2015-10-08 at 10:37 +0200, Arnd Bergmann wrote:
> > On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:
> > > On 08.10.2015 16:41, Arnd Bergmann wrote:
> > > > On Thursday 08 October 2015 03:48:36 Anand Moon wrote:
> > > > > diff --git a/arch/arm/configs/exynos_defconfig
> > > > > b/arch/arm/configs/exynos_defconfig
> > > > > index 1ff2bfa..5d1937b 100644
> > > > > --- a/arch/arm/configs/exynos_defconfig
> > > > > +++ b/arch/arm/configs/exynos_defconfig
> > > > > @@ -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
> > > 
> > > 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 

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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anand Moon Oct. 9, 2015, 3:44 a.m. UTC | #6 
Hi Arnd,

On 8 October 2015 at 20:11, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 08 October 2015 11:27:13 Sjoerd Simons wrote:
>> On Thu, 2015-10-08 at 10:37 +0200, Arnd Bergmann wrote:
>> > On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:
>> > > On 08.10.2015 16:41, Arnd Bergmann wrote:
>> > > > On Thursday 08 October 2015 03:48:36 Anand Moon wrote:
>> > > > > diff --git a/arch/arm/configs/exynos_defconfig
>> > > > > b/arch/arm/configs/exynos_defconfig
>> > > > > index 1ff2bfa..5d1937b 100644
>> > > > > --- a/arch/arm/configs/exynos_defconfig
>> > > > > +++ b/arch/arm/configs/exynos_defconfig
>> > > > > @@ -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
>> > >
>> > > 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
>
> 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.

-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann Oct. 9, 2015, 8:15 a.m. UTC | #7 
On Friday 09 October 2015 09:14:33 Anand Moon wrote:
> 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.

The NFS booting is exactly the question here: Would it be a significant
hassle for anyone to require using a ramdisk if they need NFS root?

If we all think it would be an acceptable price, we should probably
make all ethernet drivers loadable modules, as it is commonly
done on distros.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sjoerd Simons Oct. 9, 2015, 9:59 a.m. UTC | #8 
On Thu, 2015-10-08 at 16:41 +0200, Arnd Bergmann wrote:
> On Thursday 08 October 2015 11:27:13 Sjoerd Simons wrote:
> > On Thu, 2015-10-08 at 10:37 +0200, Arnd Bergmann wrote:
> > > On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:
> > > > On 08.10.2015 16:41, Arnd Bergmann wrote:
> > > > > On Thursday 08 October 2015 03:48:36 Anand Moon wrote:
> > > > > > diff --git a/arch/arm/configs/exynos_defconfig
> > > > > > b/arch/arm/configs/exynos_defconfig
> > > > > > index 1ff2bfa..5d1937b 100644
> > > > > > --- a/arch/arm/configs/exynos_defconfig
> > > > > > +++ b/arch/arm/configs/exynos_defconfig
> > > > > > @@ -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-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?
> > > 
> > > 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 
> 
> Yes, agreed, that what I'm trying to do here ;-)

I see, sorry I misunderstood what you were after.

> 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).

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

++
Arnd Bergmann Oct. 9, 2015, 10:28 a.m. UTC | #9 
On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote:
> 
> > 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).
> 

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.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Krzysztof Kozlowski Oct. 9, 2015, 10:47 a.m. UTC | #10 
W dniu 09.10.2015 o 19:28, Arnd Bergmann pisze:
> On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote:
>>
>>> 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).
>>
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anand Moon Oct. 9, 2015, 10:52 a.m. UTC | #11 
Hi Krzysztof,

On 9 October 2015 at 16:17, Krzysztof Kozlowski <k.kozlowski@samsung.com> wrote:
> W dniu 09.10.2015 o 19:28, Arnd Bergmann pisze:
>> On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote:
>>>
>>>> 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).
>>>
>>
>> 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

Yes I will change this to build as module for multi_v7, and resend the patch.

-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index 1ff2bfa..5d1937b 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -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