Hi Larry On Thu, Aug 23, 2012 at 11:56:51AM -0500, Larry Finger wrote: > >Could Realsil/Realtek post small patches please? > > > >See "Separate your changes." from Documentation/SubmittingPatches. > > > >You must have separate patches in repositories already. Life is strange, > >but I don't believe Realsil/Realtek develops driver without source > >control :-) > > Sorry for making the patch so large. > > I have no idea what Realtek uses for version control, but I have no > access to it. What I get from them is a complete new version of a > driver. To discover what changes have been made, I diff the new > version against the old and prepare the necessary patches for the > in-kernel versions, which have diverged from the vendor version. > Most of the changes are cosmetic, but not all of them fit that > category. When patches are submitted, I mark them as from Realtek > authors when that is appropriate. If the change is something that I > instituted, then I claim authorship. In either case, I am the one > that prepared the patch. Ok, I thought/hoped that Realtek is involved into that patch submission. But if that is only your work, based on vendor driver release, I don't want you to separate patches into smaller paces, since that is very tedious work. > >How this is suppose to work, this variable will be overwritten by > >any ->pci_probe ? In general this buddy/glabal_var stuff is very > >fishy, but I did not looked in detail at that. Does all of > >that actually work ? > > The question of whether it works will need to be deferred to > Chaoming. The situation is that the device has both a 2.4 GHz part > and a 5 GHz part that register as two separate devices; however, > each driver instance needs to have access to some of the private > variables of the other. Can you point me to an example of a safe way > to do this without using a global variable? Global variable is fine for that, but this need to be done carefully. Thanks Stanislaw -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
