>> On Tue, Nov 28, 2017 at 4:33 AM, Stewart Samuels <searider74@xxxxxxxxx> >> wrote: >>> >>> 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 >>> devices >>> are now recognized as is the onboard gigabit ethernet port. However, the >> >> Good. >> >>> system still requires the "cpuidle.off=1" argument on the "append" line >>> of >>> 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: https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices > However, IMHO, if the intended behavior is such that the system should boot > 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 devices. > The other possibility is that the reason the argument needs to be provided > 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 two). >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. Peter _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx