From: Krzysztof Kozlowski <krzk@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>, Arnd Bergmann <arnd@arndb.de>,
taehyun cho <taehyun.cho@samsung.com>,
balbi@kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>
Subject: Re: [PATCH] usb: dwc3: make USB_DWC3_EXYNOS independent
Date: Wed, 3 Mar 2021 16:44:09 +0100 [thread overview]
Message-ID: <c50d2091-0f87-dd2c-a7bc-df1bed14c17f@kernel.org> (raw)
In-Reply-To: <YD+XkFAfoKpSsea3@kroah.com>
On 03/03/2021 15:05, Greg Kroah-Hartman wrote:
> On Wed, Mar 03, 2021 at 11:38:39AM +0100, Krzysztof Kozlowski wrote:
>> This is so far component of a SoC, so it cannot be re-used outside of
>> SoC. Unless it appears in a new SoC (just like recent re-use of Samsung
>> serial driver for Apple M1). Because of the architecture, you cannot
>> build universal kernel without ARCH_EXYNOS. You need it. Otherwise the
>> kernel won't boot on hardware with DWC Exynos.
>
> So, to create a "generic" arm64 kernel, I need to go enable all of the
> ARCH_* variants as well? I thought we were trying to NOT do the same
> mess that arm32 had for this type of thing.
The kernel itself is generic and could work on all arm64 platforms. You
have to however enable all ARCH_* because of the design choice:
1. device tree sources are toggled with ARCH_xxx
2. the given ARCH_xxx might select specific drivers needed for the
kernel to work (or the drivers depend on it).
Maybe except the device trees, the case 2. above could be solved not
with dependency but "imply".
>> Since DWC Exynos won't work without ARCH_EXYNOS - the user will not get
>> any usable binary - I think all, or almost all, SoC specific drivers are
>> limited per ARCH. This limits the amount of choices for distro people
>> and other kernel configuring folks, so they won't have to consider
>> useless options.
>
> Why do we have ARCH_EXYNOS at all? x86-64 doesn't have this, why is
> arm64 somehow special here?
Because x86 is plug and play? Has BIOS? You can have generic kernel? ARM
is not like this - you need to load for example proper device tree blob
matching your hardware. This could be loaded/passed/chosen by
bootloader, but it's not the same as BIOS.
> That's my complaint, it feels wrong that I have to go and enable all
> different ARCH_ symbols just to build these drivers. If people want
> 'default' configurations, then provide an exynos default config file,
> right?
If you refer to only building, then options are usually
compile-testable. But if you think about having a working kernel, why
having a ARCH_xxx for given platform feels wrong? Isn't it nice to hide
all stuff behind one option?
I think MIPS and RISC-V do similar.
>
>> Anyway, that's the convention or consensus so far for entire SoC. If we
>> want to change it - sure, but let's make it for everyone, not for just
>> this one USB driver.
>
> Great, let's change it for everyone, I don't see a need for ARCH_*
> symbols except for people who want to make it simpler for their one
> board type. And for that, use a defconfig.
>
> I've complained about this before, from a driver subsystem maintainer
> point of view, this is crazy, drivers should be building and working on
> everything. Worst case, it's a cpu-type issue, to build or not build a
> driver (i.e. s390, i386), best case it's a feature-type issue to depend
> on (i.e. USB, TTY, etc.). But never a "this one sub-architecture of
> this one cpu"-type issue. That feels crazy to me...
From the building point of view, I agree that the goal is to build them
everywhere. This is why we have COMPILE_TEST. From the running/working
point of view, these are not PCI or USB cards. These are dedicated
blocks of System on Chip. They sometimes got reused on different SoCs
but they do not exist outside the SoC.
Is there a point to split a complex PCI driver into 10 different parts
and be able to use each of this part separately? Usually not...
Best regards,
Krzysztof
next prev parent reply other threads:[~2021-03-03 18:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20210303022537epcas2p1b85ab825ceca3a411a177cc1af8a2c7b@epcas2p1.samsung.com>
2021-03-03 2:26 ` [PATCH] usb: dwc3: make USB_DWC3_EXYNOS independent taehyun cho
2021-03-03 10:24 ` Krzysztof Kozlowski
2021-03-03 10:30 ` Greg Kroah-Hartman
2021-03-03 10:38 ` Krzysztof Kozlowski
2021-03-03 11:01 ` Krzysztof Kozlowski
2021-03-03 12:54 ` Arnd Bergmann
2021-03-03 14:05 ` Greg Kroah-Hartman
2021-03-03 14:56 ` Guenter Roeck
2021-03-03 15:09 ` Greg Kroah-Hartman
2021-03-03 15:46 ` Krzysztof Kozlowski
2021-03-03 16:33 ` Arnd Bergmann
2021-03-03 16:43 ` Greg Kroah-Hartman
2021-03-03 16:49 ` Krzysztof Kozlowski
2021-03-03 16:50 ` Krzysztof Kozlowski
2021-03-03 16:56 ` Greg Kroah-Hartman
2021-03-03 19:40 ` Arnd Bergmann
2021-03-03 15:44 ` Krzysztof Kozlowski [this message]
2021-03-03 17:51 ` Arnd Bergmann
2021-03-03 13:12 ` taehyun cho
2021-03-03 13:15 ` Krzysztof Kozlowski
[not found] <taehyun cho>
[not found] ` <CGME20210208112816epcas2p43777bb9740f7307e38cb534f01099126@epcas2p4.samsung.com>
2021-02-08 11:29 ` taehyun cho
2021-02-08 11:39 ` Greg Kroah-Hartman
[not found] ` <CGME20210208114447epcas2p3507f22a555355ac7710c5ca220853e0e@epcas2p3.samsung.com>
2021-02-08 11:45 ` taehyun cho
2021-02-08 11:57 ` Greg Kroah-Hartman
2021-02-08 13:05 ` Krzysztof Kozlowski
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=c50d2091-0f87-dd2c-a7bc-df1bed14c17f@kernel.org \
--to=krzk@kernel.org \
--cc=arnd@arndb.de \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=taehyun.cho@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.