> On Tue, Nov 28, 2017 at 4:33 AM, Stewart Samuels
>> Hello Andreas
>> Sorry it took me so long to get back. I have just tested kernel
>> 4.15.0-0.rc0.git7.2.fc28.armv7hl and can confirm that indeed, USB 3
>> are now recognized as is the onboard gigabit ethernet port. However, the
>> system still requires the "cpuidle.off=1" argument on the
>> the extlinux.conf file to boot.
> Why is this a problem?
It is not necessarily a problem IF it is understood that this is (or will
be) the normal intended behavior by the developers for getting this device
to boot. If this is the case, then it should be documented as such so users
knows they must add it.
Sure, and we have a wiki basically anyone can edit, and even pages to
make notes for particular SoCs:
However, IMHO, if the intended behavior is such that the system
out-of-the-box without any user modification other than perhaps installing
the correct u-boot information and images, then either this argument should
be added via the install procedure(s) or it should be added implicitly to
the kernel. But as this argument is probably not necessary for other ARM
devices, the preference would be to add it via the install procedure(s).
Define "intended", the "intended" use case is a good out of the box
experience but the _FACT_ of the matter is this is a community project
and you can't expect a few key members to make all of the 100s of
possible SBCs, and their 1000s of attached devices/drivers to work out
of the box flawlessly. People have devices, projects, stacks etc
they're personally interested in, in some cases companies care about
particular devices and will pay people to work on certain SoCs or
The other possibility is that the reason the argument needs to be
to begin with is because perhaps there is a bug or it avoids some other
issues that really need to be addressed, in which case, this is only a
temporary work-around. Again, IMHO if this is the case, then the install
procedure(s) should insert the argument until the issue(s) are remedied, at
which time the argument can then be removed.
Right, but that ends up special casing stuff, and you need to the
exact details _BEFORE_ hand for the install procedure to deal with
that, IE devices X/Y/Z have issue BLAH and you have to do ZYX to make
it boot properly, and frankly it would be less work to actually fix
the bug if people are interested in that particular device. As I've
stated before I am NOT interested in Exynos devices. The other option
is people like yourself who have the device and can verify the issue,
and verify when it's fixed, could do a small amount of documentation
so others are aware of what needs to be done.
If this was a product you were paying for and not a community lead
project your requests would be completely valid, but even though we
have 100s of people that contribute to Fedora ARM directly, and even
more I and others interact with in the upstream communities I am not
their manager and people will work on the things they want to work on
or they're employer is paying them to work on (or a combination of the
From my point of view the Exynos devices are "best effort", I
personally don't have any devices to test, the Odroid manufacturers
generally don't give a shit about anything upstream and no one in the
community has stepped up to be the maintainer of the devices. So
basically from my point of view if there's a specific patch that can
be applied to fix a problem I will do so, and I did for F-27 for the
USB patch, but clearly no one tested it in a reasonable amount of
time, and I have no way of testing it myself so when I do that I have
to rely on people to test and report back yes/no, I don't have the
time to track and chase up each of the 1000s of the things I deal with
like this constantly so the people that care have to follow up.
It's very easy to say "I think this is what should happen" when you're
not the one that has to do the work. If you want to do the work and
step up and maintain the Exynos devices I'll happily assist, until
that point I'm sorry your experience isn't perfect but you do now have
a device that works.