On Thu, 01 Aug 2013 10:31:13 -0600 Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 08/01/2013 01:51 AM, Alexander Shiyan wrote: > >> On 07/31/2013 04:55 AM, Alexander Shiyan wrote: > >>> Add DT support to the SCCNCP serial driver. > >> > >>> diff --git a/Documentation/devicetree/bindings/tty/serial/sccnxp-serial.txt b/Documentation/devicetree/bindings/tty/serial/sccnxp-serial.txt [...] > >>> +- nxp,sccnxp-io-cfg: Array contains values for the emulated modem signals. > >>> + The number of values depends on the UART-number in the selected chip. > >>> + Each value should be composed according to the following rules: > >>> + (LINE1 << SIGNAL1) | ... | (LINEX << SIGNALX), where: > >>> + LINE - VALUE: > >>> + OP0 - 1 > >> ... > >>> + IP6 - 15 > >>> + SIGNAL - VALUE: > >>> + DTR - 0 > >> ... > >>> + DIR - 24 > >> > >> I wonder that shouldn't be implemented using standard pinctrl bindings. > >> I could see someone wanting to create a pinmuxing-based serial port > >> multiplexing device, which would then need to rely on this node acting > >> as a standard pin controller... > > > > In this case pin-controller cannot be applied here. > > Why not? > > > The device has several lines of general purpose inputs and outputs, there is > > no functional purpose of these lines as a modem signals. In the driver realized > > only an emulation of these signals. That is, this property describes the trick. > > I have no idea how to do this trick in another way. > > I assume the HW design is that there are 15 pins, and there is a > register or are multiple registers that define which pins are used for > which purpose. > > If so, that's exactly what the pinctrl bindings are for. > > However, you're talking about emulation... Is this property really > describing HW? If not, it isn't appropriate for DT. What your opinion about replace this property by "quirk" property and hardcode these values into the driver? Thanks. -- Alexander Shiyan <shc_work@xxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html