Re: [PATCH 1/2] staging/comedi/drivers: add driver for ad7739 analog to digital converter chip on an spi bus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 20, 2012 at 10:37:12AM +0400, Alexander Pazdnikov wrote:
> Fri, 16 Mar 2012 08:28:50 -0700 от Greg KH <greg@xxxxxxxxx>:
> 
> > You should probably take this out, along with the call below where you
> > use it, as it's not needed anymore, right?
> > 
> > > +	snprintf(devname, sizeof(devname), "%s%u.%u", spi_bus_type.name,
> > > +		 (unsigned)((dev->iobase >> 8) & 0xFF),
> > > +		 (unsigned)(dev->iobase & 0xFF));
> > > +
> > > +	d = bus_find_device_by_name(&spi_bus_type, NULL, devname);
> > > +	if (!d) {
> > > +		dev_err(dev->class_dev, "devices %s not found\n", devname);
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	priv->spi = to_spi_device(d);
> > 
> > Is that how you register a spi device normally?  I don't see any other
> > SPI drivers doing this, why are you not just registering the driver with
> > the bus like others do?
> 
> Because it is not an spi driver like other spi drivers are, it is
> based on another common spi driver - spidev, and it is only a high
> level protocol driver for ad7739 chip.
> I've used platform startup code to setup platform devices.
> On embedded systems chips are unlikly to be pluggable, socame to a
> disicion, that it is more error safe to try to setup an ad7739 chip
> only for already registered spi devices.
> ad7739 device is registered from user space by issueing a command of the form:
>    
>     comedi_config /dev/comedi10 ad7739 0x106
> 
> After that we can use /dev/comedi10 to work with ad7739 chip by common
> functions, i.e. to get analog data from one channel with comedi_lib
> userspace functions.
> Comedi is a framework for common use of data acquisition purpuses from
> different analog converters and digital input/outputs.
> 
> Of course, it will be more pluggable, if based spidev device will be registered here.
> I didn't find any practical needs to make it more pluggable and to
> register based spidev device indeed of just searching for such a
> device, may be i'm wrong.

I still don't understand, sorry.  You shouldn't be poking around in the
core of the SPI layer with a "simple" driver like this, especially as no
other SPI driver does this, right?

What is wrong with using the "correct" SPI driver interface for this
driver?  Why can't you do that?

greg k-h
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux