* [RFC] possible removal of omap-serial
@ 2014-03-20 23:52 Felipe Balbi
2014-03-21 0:04 ` Alan Cox
2014-03-21 0:12 ` Greg KH
0 siblings, 2 replies; 11+ messages in thread
From: Felipe Balbi @ 2014-03-20 23:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi folks,
I've been toying with the idea of removing
drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
ungly copy of 8250 driver.
The original concern was wrt suspend/resume but I think it'd be a far
better approach to implement runtime PM in 8250 and write a rather small
8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
OMAP-specific details out of the way.
The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
instead of ttyS\d so removing omap-serial.c would have a direct impact
in userland. I wonder if it's an acceptable "regression" considering
we'd be able to reuse 8250 gaining proper Flow Control support, proper
DMA support, years and years of bug-fixes, etc.
What do you guys say ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140320/277e2096/attachment.sig>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial
2014-03-20 23:52 [RFC] possible removal of omap-serial Felipe Balbi
@ 2014-03-21 0:04 ` Alan Cox
2014-03-21 0:12 ` Greg KH
1 sibling, 0 replies; 11+ messages in thread
From: Alan Cox @ 2014-03-21 0:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2014-03-20 at 18:52 -0500, Felipe Balbi wrote:
> Hi folks,
>
> I've been toying with the idea of removing
> drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
> ungly copy of 8250 driver.
>
> The original concern was wrt suspend/resume but I think it'd be a far
> better approach to implement runtime PM in 8250 and write a rather small
> 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
> OMAP-specific details out of the way.
>
> The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
> instead of ttyS\d so removing omap-serial.c would have a direct impact
> in userland. I wonder if it's an acceptable "regression" considering
> we'd be able to reuse 8250 gaining proper Flow Control support, proper
> DMA support, years and years of bug-fixes, etc.
>
> What do you guys say ?
I think it would be better even if we have to support calling it ttyO%d
somehow.
Alan
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial
2014-03-20 23:52 [RFC] possible removal of omap-serial Felipe Balbi
2014-03-21 0:04 ` Alan Cox
@ 2014-03-21 0:12 ` Greg KH
2014-03-21 1:35 ` Felipe Balbi
1 sibling, 1 reply; 11+ messages in thread
From: Greg KH @ 2014-03-21 0:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
> Hi folks,
>
> I've been toying with the idea of removing
> drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
> ungly copy of 8250 driver.
>
> The original concern was wrt suspend/resume but I think it'd be a far
> better approach to implement runtime PM in 8250 and write a rather small
> 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
> OMAP-specific details out of the way.
>
> The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
> instead of ttyS\d so removing omap-serial.c would have a direct impact
> in userland. I wonder if it's an acceptable "regression" considering
> we'd be able to reuse 8250 gaining proper Flow Control support, proper
> DMA support, years and years of bug-fixes, etc.
Breaking device node names is a contentious issue for serial ports, I
don't think you can do that :(
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial
2014-03-21 0:12 ` Greg KH
@ 2014-03-21 1:35 ` Felipe Balbi
2014-03-21 1:37 ` Felipe Balbi
0 siblings, 1 reply; 11+ messages in thread
From: Felipe Balbi @ 2014-03-21 1:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
> On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
> > Hi folks,
> >
> > I've been toying with the idea of removing
> > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
> > ungly copy of 8250 driver.
> >
> > The original concern was wrt suspend/resume but I think it'd be a far
> > better approach to implement runtime PM in 8250 and write a rather small
> > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
> > OMAP-specific details out of the way.
> >
> > The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
> > instead of ttyS\d so removing omap-serial.c would have a direct impact
> > in userland. I wonder if it's an acceptable "regression" considering
> > we'd be able to reuse 8250 gaining proper Flow Control support, proper
> > DMA support, years and years of bug-fixes, etc.
>
> Breaking device node names is a contentious issue for serial ports, I
> don't think you can do that :(
would an upstream udev rule creating a symbolic link from ttyO to ttyS
be enough ?
I didn't test this yet but I guess this is enough (?)
KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS"
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140320/de2b9cbe/attachment-0001.sig>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial
2014-03-21 1:35 ` Felipe Balbi
@ 2014-03-21 1:37 ` Felipe Balbi
2014-03-21 2:36 ` Greg KH
0 siblings, 1 reply; 11+ messages in thread
From: Felipe Balbi @ 2014-03-21 1:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
> > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
> > > Hi folks,
> > >
> > > I've been toying with the idea of removing
> > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
> > > ungly copy of 8250 driver.
> > >
> > > The original concern was wrt suspend/resume but I think it'd be a far
> > > better approach to implement runtime PM in 8250 and write a rather small
> > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
> > > OMAP-specific details out of the way.
> > >
> > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
> > > instead of ttyS\d so removing omap-serial.c would have a direct impact
> > > in userland. I wonder if it's an acceptable "regression" considering
> > > we'd be able to reuse 8250 gaining proper Flow Control support, proper
> > > DMA support, years and years of bug-fixes, etc.
> >
> > Breaking device node names is a contentious issue for serial ports, I
> > don't think you can do that :(
>
> would an upstream udev rule creating a symbolic link from ttyO to ttyS
> be enough ?
>
> I didn't test this yet but I guess this is enough (?)
>
> KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS"
or actually it should be to other way around, ttyS would be the real
device:
KERNEL=="ttyS[0-9]", GROUP="dialout", SYMLINK+="ttyO"
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140320/f8cee27f/attachment.sig>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial
2014-03-21 1:37 ` Felipe Balbi
@ 2014-03-21 2:36 ` Greg KH
2014-03-21 2:45 ` Robert Nelson
0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2014-03-21 2:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote:
> On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
> > > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
> > > > Hi folks,
> > > >
> > > > I've been toying with the idea of removing
> > > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
> > > > ungly copy of 8250 driver.
> > > >
> > > > The original concern was wrt suspend/resume but I think it'd be a far
> > > > better approach to implement runtime PM in 8250 and write a rather small
> > > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
> > > > OMAP-specific details out of the way.
> > > >
> > > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
> > > > instead of ttyS\d so removing omap-serial.c would have a direct impact
> > > > in userland. I wonder if it's an acceptable "regression" considering
> > > > we'd be able to reuse 8250 gaining proper Flow Control support, proper
> > > > DMA support, years and years of bug-fixes, etc.
> > >
> > > Breaking device node names is a contentious issue for serial ports, I
> > > don't think you can do that :(
> >
> > would an upstream udev rule creating a symbolic link from ttyO to ttyS
> > be enough ?
> >
> > I didn't test this yet but I guess this is enough (?)
> >
> > KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS"
>
> or actually it should be to other way around, ttyS would be the real
> device:
>
> KERNEL=="ttyS[0-9]", GROUP="dialout", SYMLINK+="ttyO"
As udev rules don't ship with the kernel, this might be tough to do :(
Might be easier to make the 8250 driver handle different "names" like
Alan said.
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial
2014-03-21 2:36 ` Greg KH
@ 2014-03-21 2:45 ` Robert Nelson
2014-03-21 2:52 ` Felipe Balbi
0 siblings, 1 reply; 11+ messages in thread
From: Robert Nelson @ 2014-03-21 2:45 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 20, 2014 at 9:36 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote:
>> On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
>> > Hi,
>> >
>> > On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
>> > > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
>> > > > Hi folks,
>> > > >
>> > > > I've been toying with the idea of removing
>> > > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
>> > > > ungly copy of 8250 driver.
>> > > >
>> > > > The original concern was wrt suspend/resume but I think it'd be a far
>> > > > better approach to implement runtime PM in 8250 and write a rather small
>> > > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
>> > > > OMAP-specific details out of the way.
>> > > >
>> > > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
>> > > > instead of ttyS\d so removing omap-serial.c would have a direct impact
>> > > > in userland. I wonder if it's an acceptable "regression" considering
>> > > > we'd be able to reuse 8250 gaining proper Flow Control support, proper
>> > > > DMA support, years and years of bug-fixes, etc.
>> > >
>> > > Breaking device node names is a contentious issue for serial ports, I
>> > > don't think you can do that :(
>> >
>> > would an upstream udev rule creating a symbolic link from ttyO to ttyS
>> > be enough ?
>> >
>> > I didn't test this yet but I guess this is enough (?)
>> >
>> > KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS"
>>
>> or actually it should be to other way around, ttyS would be the real
>> device:
>>
>> KERNEL=="ttyS[0-9]", GROUP="dialout", SYMLINK+="ttyO"
>
> As udev rules don't ship with the kernel, this might be tough to do :(
>
> Might be easier to make the 8250 driver handle different "names" like
> Alan said.
On the support side, I'm not looking forward to this for beagle/panda
users. We've already converted them once from ttySx -> ttyOx back in
2.6.33/2.6.34? days. That was an irc/email/u-boot/kernel nightmare...
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial
2014-03-21 2:45 ` Robert Nelson
@ 2014-03-21 2:52 ` Felipe Balbi
2014-03-21 17:10 ` Tony Lindgren
0 siblings, 1 reply; 11+ messages in thread
From: Felipe Balbi @ 2014-03-21 2:52 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 20, 2014 at 09:45:42PM -0500, Robert Nelson wrote:
> On Thu, Mar 20, 2014 at 9:36 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote:
> >> On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
> >> > Hi,
> >> >
> >> > On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
> >> > > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
> >> > > > Hi folks,
> >> > > >
> >> > > > I've been toying with the idea of removing
> >> > > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
> >> > > > ungly copy of 8250 driver.
> >> > > >
> >> > > > The original concern was wrt suspend/resume but I think it'd be a far
> >> > > > better approach to implement runtime PM in 8250 and write a rather small
> >> > > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
> >> > > > OMAP-specific details out of the way.
> >> > > >
> >> > > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
> >> > > > instead of ttyS\d so removing omap-serial.c would have a direct impact
> >> > > > in userland. I wonder if it's an acceptable "regression" considering
> >> > > > we'd be able to reuse 8250 gaining proper Flow Control support, proper
> >> > > > DMA support, years and years of bug-fixes, etc.
> >> > >
> >> > > Breaking device node names is a contentious issue for serial ports, I
> >> > > don't think you can do that :(
> >> >
> >> > would an upstream udev rule creating a symbolic link from ttyO to ttyS
> >> > be enough ?
> >> >
> >> > I didn't test this yet but I guess this is enough (?)
> >> >
> >> > KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS"
> >>
> >> or actually it should be to other way around, ttyS would be the real
> >> device:
> >>
> >> KERNEL=="ttyS[0-9]", GROUP="dialout", SYMLINK+="ttyO"
> >
> > As udev rules don't ship with the kernel, this might be tough to do :(
> >
> > Might be easier to make the 8250 driver handle different "names" like
> > Alan said.
I'll see if I find a way to avoid that or at least see if we find any
other way of creating a symlink... In any case, just switching back to
8250, even if just maintaining ttyO name, is already a big benefit.
> On the support side, I'm not looking forward to this for beagle/panda
> users. We've already converted them once from ttySx -> ttyOx back in
> 2.6.33/2.6.34? days. That was an irc/email/u-boot/kernel nightmare...
that's exactly why we're talking about ways to maintain backwards
compatibility here. But I'm more interested in finding a way to switch
over to ttyS and have a symlink to ttyO, that way a simple debootstrap
(or any other ARM distro minimal rootfs) would work out of the box,
without any changes, just like in "normal" systems.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140320/c35bb0fa/attachment.sig>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial
2014-03-21 2:52 ` Felipe Balbi
@ 2014-03-21 17:10 ` Tony Lindgren
2014-03-21 17:36 ` Felipe Balbi
0 siblings, 1 reply; 11+ messages in thread
From: Tony Lindgren @ 2014-03-21 17:10 UTC (permalink / raw)
To: linux-arm-kernel
* Felipe Balbi <balbi@ti.com> [140320 19:57]:
> On Thu, Mar 20, 2014 at 09:45:42PM -0500, Robert Nelson wrote:
> > On Thu, Mar 20, 2014 at 9:36 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote:
> > >> On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
> > >> > Hi,
> > >> >
> > >> > On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
> > >> > > On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
> > >> > > > Hi folks,
> > >> > > >
> > >> > > > I've been toying with the idea of removing
> > >> > > > drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
> > >> > > > ungly copy of 8250 driver.
> > >> > > >
> > >> > > > The original concern was wrt suspend/resume but I think it'd be a far
> > >> > > > better approach to implement runtime PM in 8250 and write a rather small
> > >> > > > 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
> > >> > > > OMAP-specific details out of the way.
> > >> > > >
> > >> > > > The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
> > >> > > > instead of ttyS\d so removing omap-serial.c would have a direct impact
> > >> > > > in userland. I wonder if it's an acceptable "regression" considering
> > >> > > > we'd be able to reuse 8250 gaining proper Flow Control support, proper
> > >> > > > DMA support, years and years of bug-fixes, etc.
> > >> > >
> > >> > > Breaking device node names is a contentious issue for serial ports, I
> > >> > > don't think you can do that :(
> > >> >
> > >> > would an upstream udev rule creating a symbolic link from ttyO to ttyS
> > >> > be enough ?
> > >> >
> > >> > I didn't test this yet but I guess this is enough (?)
> > >> >
> > >> > KERNEL=="ttyO[0-9]", GROUP="dialout", SYMLINK+="ttyS"
> > >>
> > >> or actually it should be to other way around, ttyS would be the real
> > >> device:
> > >>
> > >> KERNEL=="ttyS[0-9]", GROUP="dialout", SYMLINK+="ttyO"
> > >
> > > As udev rules don't ship with the kernel, this might be tough to do :(
> > >
> > > Might be easier to make the 8250 driver handle different "names" like
> > > Alan said.
>
> I'll see if I find a way to avoid that or at least see if we find any
> other way of creating a symlink... In any case, just switching back to
> 8250, even if just maintaining ttyO name, is already a big benefit.
>
> > On the support side, I'm not looking forward to this for beagle/panda
> > users. We've already converted them once from ttySx -> ttyOx back in
> > 2.6.33/2.6.34? days. That was an irc/email/u-boot/kernel nightmare...
>
> that's exactly why we're talking about ways to maintain backwards
> compatibility here. But I'm more interested in finding a way to switch
> over to ttyS and have a symlink to ttyO, that way a simple debootstrap
> (or any other ARM distro minimal rootfs) would work out of the box,
> without any changes, just like in "normal" systems.
Yeah let's not break things. The symlink solution won't work for kernel
console output so it needs to be dealt with some other way.
It seems that the biggest amount of work is making existing 8250
support the missing features in a clean way and without breaking
other platforms. Looks like 8250_dw.c has some pm_runtime_calls so
obviously it's doable.
Regards,
Tony
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial
2014-03-21 17:10 ` Tony Lindgren
@ 2014-03-21 17:36 ` Felipe Balbi
2014-03-21 17:44 ` Greg KH
0 siblings, 1 reply; 11+ messages in thread
From: Felipe Balbi @ 2014-03-21 17:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, Mar 21, 2014 at 10:10:30AM -0700, Tony Lindgren wrote:
> > > On the support side, I'm not looking forward to this for beagle/panda
> > > users. We've already converted them once from ttySx -> ttyOx back in
> > > 2.6.33/2.6.34? days. That was an irc/email/u-boot/kernel nightmare...
> >
> > that's exactly why we're talking about ways to maintain backwards
> > compatibility here. But I'm more interested in finding a way to switch
> > over to ttyS and have a symlink to ttyO, that way a simple debootstrap
> > (or any other ARM distro minimal rootfs) would work out of the box,
> > without any changes, just like in "normal" systems.
>
> Yeah let's not break things. The symlink solution won't work for kernel
again. Let's not break things again.
> console output so it needs to be dealt with some other way.
it would if kernel itself would create the symlink, but that might not
be doable in a clean way.
> It seems that the biggest amount of work is making existing 8250
> support the missing features in a clean way and without breaking
> other platforms. Looks like 8250_dw.c has some pm_runtime_calls so
> obviously it's doable.
right
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140321/2335bfe4/attachment.sig>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] possible removal of omap-serial
2014-03-21 17:36 ` Felipe Balbi
@ 2014-03-21 17:44 ` Greg KH
0 siblings, 0 replies; 11+ messages in thread
From: Greg KH @ 2014-03-21 17:44 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Mar 21, 2014 at 12:36:53PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Mar 21, 2014 at 10:10:30AM -0700, Tony Lindgren wrote:
> > > > On the support side, I'm not looking forward to this for beagle/panda
> > > > users. We've already converted them once from ttySx -> ttyOx back in
> > > > 2.6.33/2.6.34? days. That was an irc/email/u-boot/kernel nightmare...
> > >
> > > that's exactly why we're talking about ways to maintain backwards
> > > compatibility here. But I'm more interested in finding a way to switch
> > > over to ttyS and have a symlink to ttyO, that way a simple debootstrap
> > > (or any other ARM distro minimal rootfs) would work out of the box,
> > > without any changes, just like in "normal" systems.
> >
> > Yeah let's not break things. The symlink solution won't work for kernel
>
> again. Let's not break things again.
>
> > console output so it needs to be dealt with some other way.
>
> it would if kernel itself would create the symlink, but that might not
> be doable in a clean way.
The kernel isn't going to create the symlink, sorry, no.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-03-21 17:44 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-20 23:52 [RFC] possible removal of omap-serial Felipe Balbi
2014-03-21 0:04 ` Alan Cox
2014-03-21 0:12 ` Greg KH
2014-03-21 1:35 ` Felipe Balbi
2014-03-21 1:37 ` Felipe Balbi
2014-03-21 2:36 ` Greg KH
2014-03-21 2:45 ` Robert Nelson
2014-03-21 2:52 ` Felipe Balbi
2014-03-21 17:10 ` Tony Lindgren
2014-03-21 17:36 ` Felipe Balbi
2014-03-21 17:44 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).