[opensuse-kernel] Kernel Patches
So, what is the generally accepted procedure for kernel patches? I have one to enable type cover keyboard support for the MS Surface Pro devices, and coolo suggested I ask here, instead of pushing it directly in OBS to the factory kernel
On 29 July 2014 14:39, Shawn W Dunn <sfalken@opensuse.org> wrote:
So, what is the generally accepted procedure for kernel patches?
Submit your patch for review to this mailing list. It would be advisable to also say which branches you tested against - 13.1/FactorySLE/etc. Other than that there's not much else really :)
I have one to enable type cover keyboard support for the MS Surface Pro devices, and coolo suggested I ask here, instead of pushing it directly in OBS to the factory kernel
Sounds like a useful patch, do you happen to know if it has been submitted upstream? Regards, Andy -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/29/14, 9:39 AM, Shawn W Dunn wrote:
So, what is the generally accepted procedure for kernel patches?
I have one to enable type cover keyboard support for the MS Surface Pro devices, and coolo suggested I ask here, instead of pushing it directly in OBS to the factory kernel
Hi Shawn - I did see your patch sent to me. Apologies, I was away over the weekend and hadn't gotten to it yet. Quick review is that the content is ok, but you need to add more documentation to it in order for it to be accepted. I don't mean in the form of comments in the code -- but documentation as to what it fixes and your Signed-off-by. The generally accepted practice is that a patch must be accepted into the upstream kernel or a 'maintainer' branch that is known to flow directly into the upstream kernel on a regular basis. To do otherwise would make the openSUSE kernel divergent from mainline rather than just a branch with backports[1]. Once your patch is upstream, we can include it into the openSUSE kernel. A good place to start would be to look at the SubmittingPatches[2] file in the upstream kernel source and the README[3] file in our own kernel-source repository. The former documents what a patch should generally look like for inclusion in the upstream kernel. The latter documents the specific rules that must be followed for us to accept it into the openSUSE kernel. Once you have everything set for the upstream kernel, all you'll need to do is open a bug report at bugzilla.novell.com, add a reference to it in your patch using the "References" tag, and add the "Patch-mainline" and "Git-commit" tags that reference where the commit landed upstream. There are examples of acceptable patch headers in the README file. Really, though, picking nearly any other patch already in the repository would be a good source to compare against. As for asking here instead of pushing directly to OBS, that's the right thing to do. The kernel-source package is maintained in a separate git repository[4] and patches against the OBS package will either be (correctly) declined or, if someone violated the rules, will be lost with the next sync from the git repository. I know this is cumbersome, but the documentation rules are mostly from the upstream kernel. They exist for long-term maintainability of the kernel. I know you just want to get your tablet's keyboard working, but everyone wants to just get /something/ working and we'd end up with a mess if we accepted patches outside of the rules. Unfortunately, it seems that the HID subsystem doesn't support the new_id mechanism that PCI and general USB devices do (HID is an abstraction layer above the USB bus). Otherwise, it would be possible to tell the driver about the new IDs at runtime until your kernel patch is accepted. I've added Jiri Kosina and Jiri Slaby, who are both active maintainers in the input/HID area, and may be able to help you once you get your patch in shape. - -Jeff [1] The SUSE "supported" patches and Xen are notable counterexamples here. The former will necessarily always be out-of-tree. There are several SUSE engineers working full-time on getting Xen reworked and merged upstream. [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document... [3] http://kernel.opensuse.org/cgit/kernel-source/tree/README [4] http://kernel.opensuse.org/cgit/kernel-source/log/ - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT160vAAoJEB57S2MheeWyeJYP/AuCU+1rWsNEkSFr2n3dLtDb vFfxXGNdA7VlOTtQheEInA9AzeOCBETcLMtCRctYqAoLmn6/uS6lcEC2CAlAZa04 EiJNsVlE76E1aPXxhkgvq6OhN/luI8Ws8qIqOpgVfdvFvPfvwbdR5Q0TI0TuMqCh 7fulfB4yxaZdzgWegC7dbzo0d2NWLy4vhr5eyPdLLAzoBeVabWdFORUvTwo+LzoQ +z2iRZ5+oJ8HGYfQNu9W4dFa5afk7lXMb2uX398ebsM22WOFHQ5VeAegSOd8TQEh UurA8acna5aFNI2kfUjzPm55UTl4WrY1sr/xuGIAUVt6mPOF4cRWtmC8KnVgyfGo AnWrut6KLdO9A3iyPPQZcife7lxgiSZS5dIbV18tv/RQmo20vBSxDqHSEKSlePlN g/GGi0RFCg7f/7AfNvK7lT+mzdDcTYbzlOI2ixCaIMxmT6CSeIzpD+oY1z8bakpm Mca/hdir2Dd04TU/YlRXO1iKcAuGDLVHwmXCw7I3s736EORp4FcUugUZenDfa90W bs5iNSWSRvlNPiWzyNUMhE+0M46qh/mpJshCyxwZrkwM2Bmo7GePBD7BZ3ezU0uD phwftobKOU/PSIc9Ddh2FohgkxPD3mI7T1kRAsQd1PDstnRYysgP952A25NNTmb2 rIwaFlmNTStJEK5Albza =3n5p -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 07/29/2014, 04:18 PM, Jeff Mahoney wrote:
I know this is cumbersome, but the documentation rules are mostly from the upstream kernel. They exist for long-term maintainability of the kernel. I know you just want to get your tablet's keyboard working, but everyone wants to just get /something/ working and we'd end up with a mess if we accepted patches outside of the rules.
What a nice write-up, Jeff!
Unfortunately, it seems that the HID subsystem doesn't support the new_id mechanism that PCI and general USB devices do (HID is an abstraction layer above the USB bus). Otherwise, it would be possible to tell the driver about the new IDs at runtime until your kernel patch is accepted.
new_id support was added some time later after the conversion to bus. So Shawn, you actually can echo something to that file to make your device working. But since I see no device information here, I cannot tell you what exactly to write to which driver in /sys/bus/hid/drivers/*/new_id thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/29/14, 10:26 AM, Jiri Slaby wrote:
On 07/29/2014, 04:18 PM, Jeff Mahoney wrote:
I know this is cumbersome, but the documentation rules are mostly from the upstream kernel. They exist for long-term maintainability of the kernel. I know you just want to get your tablet's keyboard working, but everyone wants to just get /something/ working and we'd end up with a mess if we accepted patches outside of the rules.
What a nice write-up, Jeff!
Unfortunately, it seems that the HID subsystem doesn't support the new_id mechanism that PCI and general USB devices do (HID is an abstraction layer above the USB bus). Otherwise, it would be possible to tell the driver about the new IDs at runtime until your kernel patch is accepted.
new_id support was added some time later after the conversion to bus. So Shawn, you actually can echo something to that file to make your device working. But since I see no device information here, I cannot tell you what exactly to write to which driver in /sys/bus/hid/drivers/*/new_id
Ah, yeah, I tested it on 3.12. I didn't test it with a newer version. If that's the case, then it makes things nicer in the short term. It should be as simple as: echo -n "0x045e 0x07dc" > /sys/bus/hid/drivers/hid_microsoft/new_id It could be hid_microsoft, or hid-microsoft. I don't have a 3.15 kernel booted to check it with. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT16/+AAoJEB57S2MheeWyJDkQAIMSl1kVJ3JO6ap9TgYYcFXH xLpnKp13G6dmDGTwHLW9Yaa5IBEovc9vcI8zLy35amVrVhf38/YlyWziJoFZHYnU 4wfRqPoFOx7W1N2wh6M8LQbIQ4qhSZ5BG44oIW2wxscgKAAX7RLG7a95hZS4T7cu 4VslKAKkEphFHlN6fiPHdZmX1vXpyUEuSne2w/FgoBAiY9ggYQbu3sVCSUXgOSJ2 m71cD+3iD4807CLDEZN9EChbjQJzQI1RWek7f4B6rEYA7FKvTfl0fzh7ZZDMXRL6 JWuwdeeqscFylH5jP6jdUlE3BphWOANSvdGqFNuQvYGerUHM9ggytLVgfo6AtA0K 3hKpwEqywhztvkQp2divi+iLhcWaipTknaWkX/WJggrVvfTVDh82MwVM5MdzWhGr EQXk+gLop/RB51IA6FeEONJu7Ambc+SwGypQYIcyv7Ga0TC13JaK7+ICaMGQSFF0 BG6orJireCBauc561oVe8MlvLMEQjPlWa48OnxaA0AGEcXIaBGsoCMXPCv/LggbI eZbFlFJvE8Jg8vewwj7Wb4wTVR9LftK2ugU1GFFrFRBzo0lWBFV8hgofehw9fBa2 GehS9mgQLVmwfvmYMQlXus/Dh0n71VeAQzsC2bgsCH0Mu+CUaGQEKGJud++zHwFw 6EvPyVCDq4Fsh9lUvy8r =b5gO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tue, 29 Jul 2014, Jeff Mahoney wrote:
Ah, yeah, I tested it on 3.12. I didn't test it with a newer version. If that's the case, then it makes things nicer in the short term. It should be as simple as:
echo -n "0x045e 0x07dc" > /sys/bus/hid/drivers/hid_microsoft/new_id
It could be hid_microsoft, or hid-microsoft. I don't have a 3.15 kernel booted to check it with.
You also very likely would need to unbind hid-generic from the keyboard (if it has been claimed by the generic driver) and bind hid-microsoft to it. It can be done also through sysfs. Being the upstream maintainer of this code, I'd be happy to accept the patch to the upstream kernel once it's sent my way. -- Jiri Kosina SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tuesday 29 July 2014 10:18:24 you wrote:
On 7/29/14, 9:39 AM, Shawn W Dunn wrote:
I know this is cumbersome, but the documentation rules are mostly from the upstream kernel. They exist for long-term maintainability of the kernel. I know you just want to get your tablet's keyboard working, but everyone wants to just get /something/ working and we'd end up with a mess if we accepted patches outside of the rules.
Oh, I've got a kernel built that works for *me*, it would just be nice to get it out there so everybody can use it. Especially considering nobody is shipping a linux distro with full OOB support for the Surface Pro tablets. (and we still might not be able to, there is a firmware update for the wifi/bluetooth in it, but I'm still trying to verify if it is licensed for redistribution or not)
participants (5)
-
Andrew Wafaa -
Jeff Mahoney -
Jiri Kosina -
Jiri Slaby -
Shawn W Dunn