Hello Lee, On 01/20/2015 05:55 PM, Lee Jones wrote: > On Tue, 20 Jan 2015, Javier Martinez Canillas wrote: > >> Hello Lee, >> >> On 01/20/2015 05:29 PM, Lee Jones wrote: >> > >> > It's not a blocker, but it is a ridiculous name to use inside the >> > driver/ directory 'cos almost everything is a dev(ice) here. >> > >> >> Right, do you think that "cros-ec-chardev" will be a more suitable >> name? Sorry, I'm really bad at naming things... > > But is it really a chardev? Don't chardevs usually live in > drivers/char? It probably uses a chardev node in /dev, but what does > it really do? What information can/will userspace obtain from this > memory block? > Right, is a driver that register a chardev but mostly to expose an ioctl interface to send commands to the Embedded Controller from user-space. The Application Processor communicates with Embedded Controller by sending commands over an interface. This can be either spi or i2c on ARM (depending on the Chromebook model) or LPC on x86 Chromebooks so the platform driver instantiated by the "cros-ec-dev" mfd cell is to allow user-space to send commands to the Embedded Controller (using the correct transport method). So this chardev is used by the ectool binary in ChromeOS to communicate with the Embedded Controller. The actual driver is located in drivers/platform/chrome/cros_ec_dev.c and is added by "platform/chrome: Add Chrome OS EC userspace device interface" [0] in this series. In the downstream ChromiumOS kernel tree it is located in drivers/mfd but I moved to drivers/platform/chrome/ since you asked me to find a better place for it. Best regards, Javier [0]: https://lkml.org/lkml/2015/1/2/81 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |