Post by Shawn W Dunn
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.
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
file in the upstream kernel source and the README 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 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.
 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