uberlinuxguy

That is the same thought I had but I think I wanted to get validation that I was right in my assumption before I went forward modifying the patches from the board vendor. It *should* be easy enough to turn the necessary parts into kernel config options that can be enabled in the post_family_config. I suppose I could also apply the board specific patches via the same post_family_config hook, but after looking through the other board configs, I didn't see anyone else doing anything like that, so I didn't want to do something out of line with every other board. I am not one that would go against the grain with a work around if there is a proper way to do things. I think I just needed a bit of validation before I went in the direction of messing with kernel code. 🙂

I am working on support for the ClockworkPi Gameshell main board. I have patches for the kernel, but it seems that the build system applies kernel patches on a "per family" basis. Indeed, looking at the 'kernel-patch.sh' script it seems the BOARD and TARGET variables that would let board specific patches work are commented out. I've read through the example PR's in the docs, but don't see an example of how applying board specific patches should work. I fear that if I put the patches into the normal flow, it will get applied to other boards within the sunxi family and things may break for other boards. Should kernel patches be crafted in a way that they SHOULD be applied at the family level? Or should I expect to be able to apply a kernel package on the per board level? The patches I have come from the board maker and involve changing more than just creating dts files.