On Thu, Nov 29, 2012 at 1:21 PM, Julia Lawall <julia.lawall@xxxxxxx> wrote: > On Thu, 29 Nov 2012, Luis R. Rodriguez wrote: > >> On Wed, Nov 28, 2012 at 3:07 PM, Hauke Mehrtens <hauke@xxxxxxxxxx> wrote: >>> >>> This driver is building on all supported kernel versions. >>> >>> Signed-off-by: Hauke Mehrtens <hauke@xxxxxxxxxx> >> >> >> Julia, just a heads up this is the only change that was required to >> backport one 802.11 driver with the current framework. I don't believe >> that the change below can be expressed in SmPL nor inferred into SmPL, >> but wanted to double check with you. > > > Will it be needed to transform other drivers in this way? Indeed the collection of changes for this collateral evolution is all present in one patch: patches/network/11-dev-pm-ops.patch As it is right now all patches with double digits have not been split out cleanly to *only* have present *one* collateral evolution. I started doing this starting with the first series of patches the old 01-netdev-attach-ops.patcha and from this I split it up into four patches: 0001-netdev_ops.patch 0002-net-misc.patch 0003-netdev-needed_headroom_tailroom.patch 0004-wext-namespace.patch 0005-netlink-portid.patch So for example 0001-netdev_ops.patch has only one collateral evolution which I have managed to infer SmPL using spdiff (but not yet patchparse). I suspect we can do the same with 11-dev-pm-ops.patch. > In principle, these changes to data structures should be fine for SmPL. Sweeeeeeeeeeeeeeet! Adding Adrian for #worlddomination #killingproprietarydriver plans. > I think you can even add the #ifdefs. Mama mia. > The only thing that does not look good > to me is that compat_pci_suspend and compat_pci_suspend don't have > semicolons after them. Unlike eg module_pci_driver. Is there any reason > for this? Um, well these unwrap to defining either a routine or nothing, so I think adding one should be OK. I'll test compile that today and if it works I'll add it. > I don't think these changes would be inferred by spdiff, because of the > detail that it only works inside functions. Thought so, thanks for the confirmation, it clarifies the scope of work required for these type of collateral evolutions. Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html