On Fri, 2011-05-13 at 09:17 +0200, Ivo Van Doorn wrote: > Hi, > > >> > As mentioned by Jan, the device contains a RT3572 > >> > chipset. Its entry > >> > could moved into the section for known RT35XX devices (i.e. > >> > "#ifdef > >> > CONFIG_RT2800USB_RT35XX") as an alternative. > >> > > >> > Geoff > >> > >> This has already been done: http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commitdiff;h=ce2919c9fffe2aa52f9c3e327176d03764dbf9b5 > > > > That's all very well, but that isn't going to get into a stable release > > for another 3 months! Device ID updates that don't require new > > supporting code should be sent upstream straight away (and cc'd to > > stable@xxxxxxxxxx). > > The patch has been send upstream, it has been in wireless-next-2.6.git > since April 19... > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next-2.6.git;a=commit;h=ce2919c9fffe2aa52f9c3e327176d03764dbf9b5 > The patch depends on the RT53xx support patch which was also intented > for 2.6.40. What is it, RT35XX or RT53XX?! > > I've cherry-picked this and the other two updates in rt2800usb that > > aren't in Linus's tree, but that doesn't help the users of other > > distributions that would benefit from them. > > True, but the normal flow for new features and hardware support is that they > should be properly merged during the normal merge window. The addition > of support of RT53xx is not something that should go to stable@xxxxxxxxxxxxx I understand that. Ben. > Patches from rt2x00.git are quite quickly send from rt2x00.git to upstream, > and patches which are not send upstream directly have a reason for not being > send at that time (Usually it means that it requires some extra testing). > > Ivo > -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part
