From: Kate Hsuan on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1685415116
Sounds good. I'll move all the stuff to `redhat/scripts/fedora`.
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe
From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684872559
I don't disagree, though all new config items coming in for RHEL have to be
reviewed by the subsystem owners anyway, and tend to default to off unless
requested otherwise. There
From: Hans de Goede on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684863927
> recommend that we move all of this to `redhat/scripts/fedora` though as it
is pretty fedora specific
That sounds good to me.
Although I would like to point out that with this
From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684856741
I am okay with this concept. I might recommend that we move all of this to
`redhat/scripts/fedora` though as it is pretty fedora specific at the moment.
It will also allow me to
From: Hans de Goede on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684802550
> I am scratching my head how do we audit @hpa1 's list?
One thing you can audit is if the removed i2c/spi drivers have an
acpi_match_table. Without that they are basically not
From: Hans de Goede on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684783523
So @hpa1 created this script at my request.
Looking at the discussions here it seems there are 2 separate discussion
points:
1. Why use a script
2. Why disable these drivers
I've
From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684758822
> Right so you are kinda stuck and you default to on. Ok, I get your data
source comment now (which is sorta the same as my who-decides-unnecessary
comment). I would have thought
From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684727952
Right so you are kinda stuck and you default to on. Ok, I get your data
source comment now (which is sorta the same as my who-decides-unnecessary
comment).I would have thought
From: Hans de Goede on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684724074
So @hpa1 created this script at my request.
Looking at the discussions above it seems there are 2 separate discussion
points:
1. Why disable these drivers
2. Why use a script
Let
From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684711819
While Fedora is very much interested in enabling any drivers for hardware that
is or soon will be in the wild, there isn't much point in enabling a driver on
an arch where it will
From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684685920
This seems to conflict with Fedora's principle here a little. I believe
Fedora purposely enables all drivers for an arch and thus is not interested in
package size. The idea is that
From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1683958591
I suppose I am curious as to why it is set up like this then. I do understand
that new iio drivers can (and do) show up pretty much every merge window.
Having an allow list would
From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1683946934
I still do not see how custom-overrides has anything to do with this. If the
hardware doesn't exist on x86, it needs to be disabled on x86 permanently, not
for a specific build,
From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1683927918
So I'll ask again: Why aren't you using the custom-overrides for this
functionality, and tracking the contents of that file locally? It seems a
better approach would be to apply
14 matches
Mail list logo
