On Fri, 20 Mar 2015 08:54:35 +0100 "Dr. H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> wrote: > Hi Neil, > > Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@xxxxxxxxxx>: > > > Hi again, > > here is version 3 of support for tty-slaves. > > > > This version introduces a new bus-type for tty-slaves, > > Hm. I am still not convinced that a tty is a „bus“ and > that this is a solution for a wide-spread problem. Don't read too much into the word "bus". It is really just a mechanism for grouping drivers together - with maybe a hint of a suggestions that it helps communicate with the devices which the drivers drive. And I'm not particularly interested in solving wide-spread problems, just in solving my problem in a suitably idiomatic way. > > > and causes > > a tty-slave device to appear in /sys/devices between the uart and the > > tty. > > It effectively intercepts and calls from the tty to the uart (i.e. any > > tty_operations) and applies extra functionality at that point. > > > > > Currently the only driver intercepts open and close. > > It powers on the device on open, and powers off at last-close. > > That is what the missing piece in Linux is to make the w2sg0004 > chip work. > > > > > Power can be controlled by a regulator or by toggling a GPIO. > > I think such a GPIO logic has nothing to do with serial and > should be left over to the regulator logic, i.e. we need a special > regulator-w2sg0004 driver. > > So I suggest to remove the GPIO logic from your > > drivers/tty/slave/serial-power-manager.c > > And then you can even get rid of adding a chip specific „compatible“ > entry for the subnodes. But (nearly) every node has a "compatible" entry. Each node describes a device, and the "compatible" string tells us what sort of device. Surely you agree that there is a particular device that needs to be controlled? In that case there needs to be a node representing it and a "compatible" string describing it. That is how "devicetree" works. > > > > > I think I've incorporated most of the feed back I received from > > previous versions, but if I missed something - I apologize. If > > this approach is structurally acceptable then I can fix up all the > > smaller issues. > > As said I would prefer that the w2sg0004 driver is just a separate > „regulator“ driver as we had proposed before. You can prefer that if you wish. But given that the w2sg0004 is not in fact a regulator, but is in fact a GPS device, I doubt you will find a lot of support for your approach (as indeed I didn't when I tried it...) Thanks, NeilBrown
Attachment:
pgp4H9By95FwZ.pgp
Description: OpenPGP digital signature
