20 марта 2012 г. 18:26 пользователь Greg KH <greg@xxxxxxxxx> написал:
>
> 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
Seems, that your are right, going to implement driver with your suggestion.
--
Best regards
Alexander Pazdnikov
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
