On Tue, Jan 15, 2013 at 09:14:26PM +0000, Ian Abbott wrote: > On 15/01/13 18:45, Greg KH wrote: > >On Tue, Jan 15, 2013 at 10:15:57AM -0800, Greg KH wrote: > >>On Tue, Jan 15, 2013 at 02:45:20PM +0000, Ian Abbott wrote: > >>>upstream > >>>commit 34ffb33e09132401872fe79e95c30824ce194d23 > >>> > >>>The 'ni_at_a2150' module links to `cfc_write_to_buffer` in the > >>>'comedi_fc' module, so selecting 'COMEDI_NI_AT_A2150' in the kernel > >>>config needs to also select 'COMEDI_FC'. > >>> > >>>Signed-off-by: Ian Abbott <[email protected]> > >>>Cc: <[email protected]> # 3.0.x, 3.2.x, 3.4.x > >>>--- > >>>Note 1: backported from upstream patch with minor conflict fix. > >>>Note 2: upstream patch already on 3.7.x stable queue. > >> > >>Thanks for the backport, now applied. > > > >And now the build breaks :( > > > >Hm, the COMEDI_FC option always seems to fail, no matter if this is > >enabled or not, odd, in 3.4, and 3.0, any ideas what is going on here? > > > >The error is: > > > > CC [M] drivers/staging/comedi/comedi_fops.o > >drivers/staging/comedi/comedi_fops.c: In function ‘comedi_unlocked_ioctl’: > >drivers/staging/comedi/comedi_fops.c:143:17: error: ‘struct > >comedi_device_file_info’ has no member named ‘hardware_device’ > > > >thanks, > > > >greg k-h > > > > Oops. It wasn't this patch that broke it, it was: > > staging: comedi: prevent auto-unconfig of manually configured devices > > It appears that one depends on upstream > commit c43435d7722134ed1fda58ce1025f41029bd58ad > staging: comedi: don't hijack hardware device private data > > I've just compiled 3.0 and 3.4 okay with that commit and the one > that broke it.
Ah, thanks, that fixed it for me, so I've queued it up for the next release. greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
