Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Alan,

Am 24.01.2016 um 18:10 schrieb One Thousand Gnomes :

>>> but by having only the
>>> minimum necessary in the kernel. Unix  
>> 
>> I think you are confusing it with the goals of microkernels (e.g. Mach or 
>> Hurd).
> 
> No and the quote below is from Doug McIlroy - who amongst other thing
> invented pipes.

Which is a brilliant concept.

> 
>>> 
>>> "We used to sit around in the Unix Room saying, 'What can we throw out?
>>> Why is there this option?" - Doug McIlroy  

Maybe I am interpreting differently, but "throwing out unnecessary things from
Unix" is logically not the same as "having the minimum necessary in the kernel".

The latter appears to be implying to do *everything* which can be done in user 
space.
This is what I mean that the goal of throwing out everything not necessary from 
the
kernel leads to micro-kernel concepts. And neither Unix nor Linux did throw out
enough to become a microkernel. So they still have components which could be
thrown out and moved to user space.

And Unix is kernel + user space. So the citation could also mean that they did
throw out (and simplify) concepts in both areas. Not only from the kernel. So 
they
did balance and optimize the whole system (which is what I want to achieve as 
well).

Unfortunately I never had a chance to meet one of the Unix inventors, so I
can't ask them what they really meant and how they did work.

But anyways, this is discussing the wrong problem on the wrong level.

People out there (and me included) would like to hide or better, easier and
more systematically access devices directly connected on the same PCB to
a specific UART. And can't. Or can do only with ugly or inefficient solutions.

>From that we come to this fundamental discussion level because you say that
Linux should be a kernel which should only support the minimum. Therefore our
requests are rejected, because it could be solved by blowing up the user space.

This is IMHO your very valid opinion, but it is not a guideline that I observe 
when
going through the source tree. There are tons of things that could be done
in user space (e.g. what are all those I2C device drivers good for? /dev/i2c 
should
suffice to control every device from user space. What is iio good for in the 
kernel?
a library could translate everything into iio interfaces).

So this discrepancy is what I criticize because I don't see a basic rule or
design principle behind what is acceptable and what is not.

If it exists, please point me to it. I am open to learn about that.

> 
>> Most GPS receivers I came across are modules which spit out NMEA
>> records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There
>> may be others, but I don't want to have all problems of the world solved
>> at once.
> 
> The kernel lives in the big world, not your personal fiefdom

Every contribution initially looks at the area, the contributor is aware of and
knows best and does not find a solution using existing hooks. Then discussion
starts.

But what a contributor can't (and should never) accept is if his problem is
simply declared to be a non-problem without providing a *better* alternative
solution for it. Better for everybody including the contributor.

> 
> *PLONK*

Thanks.

Well, I have to apologize that I was not yet aware who hides behind the
"one thousand gnomes" e-mail address... Because I judge discussion partners
by what they say now and how they help to solve my actual problem for the future
(and not what they have done in the past).

So you do have a lot of experience with Linux history. And you are amongst
the handful of persons who know every detail of the Linux kernel. That is good
because it shows that you can really influence how this discussion ends.

But sometimes experience could be a little blocking to new ideas and experiences
not related to Linux (e.g. close to hardware or embedded design) brought in by
newcomers.

And it collides with my belief that everything can be done, if people want.

Now, how can we help those who want (for IMHO very understandable reasons)
to access a specific UART from kernel modules?

-- hns

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Alan,

Am 24.01.2016 um 18:10 schrieb One Thousand Gnomes :

>>> but by having only the
>>> minimum necessary in the kernel. Unix  
>> 
>> I think you are confusing it with the goals of microkernels (e.g. Mach or 
>> Hurd).
> 
> No and the quote below is from Doug McIlroy - who amongst other thing
> invented pipes.

Which is a brilliant concept.

> 
>>> 
>>> "We used to sit around in the Unix Room saying, 'What can we throw out?
>>> Why is there this option?" - Doug McIlroy  

Maybe I am interpreting differently, but "throwing out unnecessary things from
Unix" is logically not the same as "having the minimum necessary in the kernel".

The latter appears to be implying to do *everything* which can be done in user 
space.
This is what I mean that the goal of throwing out everything not necessary from 
the
kernel leads to micro-kernel concepts. And neither Unix nor Linux did throw out
enough to become a microkernel. So they still have components which could be
thrown out and moved to user space.

And Unix is kernel + user space. So the citation could also mean that they did
throw out (and simplify) concepts in both areas. Not only from the kernel. So 
they
did balance and optimize the whole system (which is what I want to achieve as 
well).

Unfortunately I never had a chance to meet one of the Unix inventors, so I
can't ask them what they really meant and how they did work.

But anyways, this is discussing the wrong problem on the wrong level.

People out there (and me included) would like to hide or better, easier and
more systematically access devices directly connected on the same PCB to
a specific UART. And can't. Or can do only with ugly or inefficient solutions.

>From that we come to this fundamental discussion level because you say that
Linux should be a kernel which should only support the minimum. Therefore our
requests are rejected, because it could be solved by blowing up the user space.

This is IMHO your very valid opinion, but it is not a guideline that I observe 
when
going through the source tree. There are tons of things that could be done
in user space (e.g. what are all those I2C device drivers good for? /dev/i2c 
should
suffice to control every device from user space. What is iio good for in the 
kernel?
a library could translate everything into iio interfaces).

So this discrepancy is what I criticize because I don't see a basic rule or
design principle behind what is acceptable and what is not.

If it exists, please point me to it. I am open to learn about that.

> 
>> Most GPS receivers I came across are modules which spit out NMEA
>> records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There
>> may be others, but I don't want to have all problems of the world solved
>> at once.
> 
> The kernel lives in the big world, not your personal fiefdom

Every contribution initially looks at the area, the contributor is aware of and
knows best and does not find a solution using existing hooks. Then discussion
starts.

But what a contributor can't (and should never) accept is if his problem is
simply declared to be a non-problem without providing a *better* alternative
solution for it. Better for everybody including the contributor.

> 
> *PLONK*

Thanks.

Well, I have to apologize that I was not yet aware who hides behind the
"one thousand gnomes" e-mail address... Because I judge discussion partners
by what they say now and how they help to solve my actual problem for the future
(and not what they have done in the past).

So you do have a lot of experience with Linux history. And you are amongst
the handful of persons who know every detail of the Linux kernel. That is good
because it shows that you can really influence how this discussion ends.

But sometimes experience could be a little blocking to new ideas and experiences
not related to Linux (e.g. close to hardware or embedded design) brought in by
newcomers.

And it collides with my belief that everything can be done, if people want.

Now, how can we help those who want (for IMHO very understandable reasons)
to access a specific UART from kernel modules?

-- hns

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> > but by having only the
> > minimum necessary in the kernel. Unix  
> 
> I think you are confusing it with the goals of microkernels (e.g. Mach or 
> Hurd).

No and the quote below is from Doug McIlroy - who amongst other thing
invented pipes.

> > 
> > "We used to sit around in the Unix Room saying, 'What can we throw out?
> > Why is there this option?" - Doug McIlroy  

> Most GPS receivers I came across are modules which spit out NMEA
> records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There
> may be others, but I don't want to have all problems of the world solved
> at once.

The kernel lives in the big world, not your personal fiefdom

*PLONK*

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> > but by having only the
> > minimum necessary in the kernel. Unix  
> 
> I think you are confusing it with the goals of microkernels (e.g. Mach or 
> Hurd).

No and the quote below is from Doug McIlroy - who amongst other thing
invented pipes.

> > 
> > "We used to sit around in the Unix Room saying, 'What can we throw out?
> > Why is there this option?" - Doug McIlroy  

> Most GPS receivers I came across are modules which spit out NMEA
> records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There
> may be others, but I don't want to have all problems of the world solved
> at once.

The kernel lives in the big world, not your personal fiefdom

*PLONK*

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 23.01.2016 um 18:28 schrieb One Thousand Gnomes :

>>> There is lots of stuff we probe and bind via user space - most things
>>> these days in fact. That's much of why we have notifiers and udev. It's
>>> frequently a win in flexibility, security and configurability to do stuff
>>> via user daemons. We do it for example with all the volume management,
>>> raid and disk encryption.  
>> 
>> Because volumes are something users really want to configure. They
>> can change their hardware configuration every now and then. And
>> there are removable media to be considered.
> 
> Like USB bluetooth dongles, like systems with external SPI ports, or plug
> in SPI devices, or plug in gps devices on other interfaces ?
> 
>> In our UART cases the underlaying hardware can't be reconfigured. So
>> there is no need to load this burden of config to the user.
> 
> Plenty of uarts it can be or the BT can be muxed with other device
> endpoints.

Please give examples where the user can configure such a chip that is
soldered on the same PCB as the SoC.

> 
>> For BT or GPS I just want it to work the same on all devices (independently
>> on how the specific chip is connected). Kernel should unify such things.
>> Or it would not be a Un(iplexed)ix.
> 
> I think you are confusing Unix and Multics.

No, If I write Unix I mean Unix. The "Un" stands for "Uniplexed" which is
a pun of course. But it alludes to "Unification" giving the impression of
"Simplification".

> 
> Unix is nothing to do with Linux and Unix was about creating a beautiful
> system not by having a huge crap filled kernel,

and no crap filled user space.

> but by having only the
> minimum necessary in the kernel. Unix

I think you are confusing it with the goals of microkernels (e.g. Mach or Hurd).

> was not about what was put in but
> what was left out.

Exactly. It left out complexity. E.g. everything is a file. You can use devices
like files. Just open some /dev/tty and get GPS NMEA records...

> 
> "We used to sit around in the Unix Room saying, 'What can we throw out?
> Why is there this option?" - Doug McIlroy

Fine. Let's throw out the idea to configure power on/off a GPS or BT device
by user space daemons for hard wired chips.

> 
> GPS is a train wreck for commonality. Most GPS requires custom binary
> only user space code often obfuscated in order to meet the regulations
> governing GPS technology to stop third parties using it for missile
> guidance.

Most GPS receivers I came across are modules which spit out NMEA
records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There
may be others, but I don't want to have all problems of the world solved
at once.

-- hns

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> > There is lots of stuff we probe and bind via user space - most things
> > these days in fact. That's much of why we have notifiers and udev. It's
> > frequently a win in flexibility, security and configurability to do stuff
> > via user daemons. We do it for example with all the volume management,
> > raid and disk encryption.  
> 
> Because volumes are something users really want to configure. They
> can change their hardware configuration every now and then. And
> there are removable media to be considered.

Like USB bluetooth dongles, like systems with external SPI ports, or plug
in SPI devices, or plug in gps devices on other interfaces ?

> In our UART cases the underlaying hardware can't be reconfigured. So
> there is no need to load this burden of config to the user.

Plenty of uarts it can be or the BT can be muxed with other device
endpoints.

> For BT or GPS I just want it to work the same on all devices (independently
> on how the specific chip is connected). Kernel should unify such things.
> Or it would not be a Un(iplexed)ix.

I think you are confusing Unix and Multics.

Unix is nothing to do with Linux and Unix was about creating a beautiful
system not by having a huge crap filled kernel, but by having only the
minimum necessary in the kernel. Unix was not about what was put in but
what was left out.

"We used to sit around in the Unix Room saying, 'What can we throw out?
Why is there this option?" - Doug McIlroy

GPS is a train wreck for commonality. Most GPS requires custom binary
only user space code often obfuscated in order to meet the regulations
governing GPS technology to stop third parties using it for missile
guidance.


Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 22.01.2016 um 21:12 schrieb One Thousand Gnomes :

>> I would have expected that the main (and IMO sufficient) reason why
>> the kernel should do it is because the particular bus used to connect
>> a BT chip to the CPU is a hw detail that a kernel that does its job
>> should keep to itself. Same as userspace not needing to care if a BT
>> chip is behind SDIO or USB, why does it have to tell the kernel behind
>> which UART a BT chip is sitting?
> 
> Lots of reasons, some historic some not
> 
> 1. Different BT chips have different interfaces, especially when it gets
> to stuff like firmware reprogramming

HCI protocol is quite standardized. And firmware reprogramming is
rarely done. If it is needed, each chip type can have its own driver
module that knows how to inject firmware.

This just needs a decent kernel API for a chip driver to communicate
with the chip.

For SDIO connected WiFi chips it appears that firmware download done
by kernel modules is a standard solution.

> 
> 2. In many cases we don't know at the kernel level where there are BT
> uarts. It's improving with recent ACPI but for many systems it's simply
> not available to the OS

We just need to describe the connection of some peer driver to some
UART by means of DT. Then, kernel level can know.

> 
> 3. The power management for a lot of BT (especially on device tree) is
> not actually expressed, so you need a slightly customised daemon for each
> device - that one is ugly but the serial and bt layers can't fix it.

The peer chip driver (not the serial or bt layers) could fix it. With help
from bt and serial layers.

> 
> 4. Because you don't want to just automatically load and turn on
> bluetooth just because it is there - it burns power

That is obviously something nobody wants.

If the chip must be turned on (or turns on) during boot, the driver
can turn it off right after initialization and make the subsystem sleep
until activated again. Then it does not burn power although it
loads automatically.

> 
> 
> There is lots of stuff we probe and bind via user space - most things
> these days in fact. That's much of why we have notifiers and udev. It's
> frequently a win in flexibility, security and configurability to do stuff
> via user daemons. We do it for example with all the volume management,
> raid and disk encryption.

Because volumes are something users really want to configure. They
can change their hardware configuration every now and then. And
there are removable media to be considered.

In our UART cases the underlaying hardware can't be reconfigured. So
there is no need to load this burden of config to the user.

For BT or GPS I just want it to work the same on all devices (independently
on how the specific chip is connected). Kernel should unify such things.
Or it would not be a Un(iplexed)ix.

-- hns

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 22.01.2016 um 21:12 schrieb One Thousand Gnomes :

>> I would have expected that the main (and IMO sufficient) reason why
>> the kernel should do it is because the particular bus used to connect
>> a BT chip to the CPU is a hw detail that a kernel that does its job
>> should keep to itself. Same as userspace not needing to care if a BT
>> chip is behind SDIO or USB, why does it have to tell the kernel behind
>> which UART a BT chip is sitting?
> 
> Lots of reasons, some historic some not
> 
> 1. Different BT chips have different interfaces, especially when it gets
> to stuff like firmware reprogramming

HCI protocol is quite standardized. And firmware reprogramming is
rarely done. If it is needed, each chip type can have its own driver
module that knows how to inject firmware.

This just needs a decent kernel API for a chip driver to communicate
with the chip.

For SDIO connected WiFi chips it appears that firmware download done
by kernel modules is a standard solution.

> 
> 2. In many cases we don't know at the kernel level where there are BT
> uarts. It's improving with recent ACPI but for many systems it's simply
> not available to the OS

We just need to describe the connection of some peer driver to some
UART by means of DT. Then, kernel level can know.

> 
> 3. The power management for a lot of BT (especially on device tree) is
> not actually expressed, so you need a slightly customised daemon for each
> device - that one is ugly but the serial and bt layers can't fix it.

The peer chip driver (not the serial or bt layers) could fix it. With help
from bt and serial layers.

> 
> 4. Because you don't want to just automatically load and turn on
> bluetooth just because it is there - it burns power

That is obviously something nobody wants.

If the chip must be turned on (or turns on) during boot, the driver
can turn it off right after initialization and make the subsystem sleep
until activated again. Then it does not burn power although it
loads automatically.

> 
> 
> There is lots of stuff we probe and bind via user space - most things
> these days in fact. That's much of why we have notifiers and udev. It's
> frequently a win in flexibility, security and configurability to do stuff
> via user daemons. We do it for example with all the volume management,
> raid and disk encryption.

Because volumes are something users really want to configure. They
can change their hardware configuration every now and then. And
there are removable media to be considered.

In our UART cases the underlaying hardware can't be reconfigured. So
there is no need to load this burden of config to the user.

For BT or GPS I just want it to work the same on all devices (independently
on how the specific chip is connected). Kernel should unify such things.
Or it would not be a Un(iplexed)ix.

-- hns

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> > There is lots of stuff we probe and bind via user space - most things
> > these days in fact. That's much of why we have notifiers and udev. It's
> > frequently a win in flexibility, security and configurability to do stuff
> > via user daemons. We do it for example with all the volume management,
> > raid and disk encryption.  
> 
> Because volumes are something users really want to configure. They
> can change their hardware configuration every now and then. And
> there are removable media to be considered.

Like USB bluetooth dongles, like systems with external SPI ports, or plug
in SPI devices, or plug in gps devices on other interfaces ?

> In our UART cases the underlaying hardware can't be reconfigured. So
> there is no need to load this burden of config to the user.

Plenty of uarts it can be or the BT can be muxed with other device
endpoints.

> For BT or GPS I just want it to work the same on all devices (independently
> on how the specific chip is connected). Kernel should unify such things.
> Or it would not be a Un(iplexed)ix.

I think you are confusing Unix and Multics.

Unix is nothing to do with Linux and Unix was about creating a beautiful
system not by having a huge crap filled kernel, but by having only the
minimum necessary in the kernel. Unix was not about what was put in but
what was left out.

"We used to sit around in the Unix Room saying, 'What can we throw out?
Why is there this option?" - Doug McIlroy

GPS is a train wreck for commonality. Most GPS requires custom binary
only user space code often obfuscated in order to meet the regulations
governing GPS technology to stop third parties using it for missile
guidance.


Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 23.01.2016 um 18:28 schrieb One Thousand Gnomes :

>>> There is lots of stuff we probe and bind via user space - most things
>>> these days in fact. That's much of why we have notifiers and udev. It's
>>> frequently a win in flexibility, security and configurability to do stuff
>>> via user daemons. We do it for example with all the volume management,
>>> raid and disk encryption.  
>> 
>> Because volumes are something users really want to configure. They
>> can change their hardware configuration every now and then. And
>> there are removable media to be considered.
> 
> Like USB bluetooth dongles, like systems with external SPI ports, or plug
> in SPI devices, or plug in gps devices on other interfaces ?
> 
>> In our UART cases the underlaying hardware can't be reconfigured. So
>> there is no need to load this burden of config to the user.
> 
> Plenty of uarts it can be or the BT can be muxed with other device
> endpoints.

Please give examples where the user can configure such a chip that is
soldered on the same PCB as the SoC.

> 
>> For BT or GPS I just want it to work the same on all devices (independently
>> on how the specific chip is connected). Kernel should unify such things.
>> Or it would not be a Un(iplexed)ix.
> 
> I think you are confusing Unix and Multics.

No, If I write Unix I mean Unix. The "Un" stands for "Uniplexed" which is
a pun of course. But it alludes to "Unification" giving the impression of
"Simplification".

> 
> Unix is nothing to do with Linux and Unix was about creating a beautiful
> system not by having a huge crap filled kernel,

and no crap filled user space.

> but by having only the
> minimum necessary in the kernel. Unix

I think you are confusing it with the goals of microkernels (e.g. Mach or Hurd).

> was not about what was put in but
> what was left out.

Exactly. It left out complexity. E.g. everything is a file. You can use devices
like files. Just open some /dev/tty and get GPS NMEA records...

> 
> "We used to sit around in the Unix Room saying, 'What can we throw out?
> Why is there this option?" - Doug McIlroy

Fine. Let's throw out the idea to configure power on/off a GPS or BT device
by user space daemons for hard wired chips.

> 
> GPS is a train wreck for commonality. Most GPS requires custom binary
> only user space code often obfuscated in order to meet the regulations
> governing GPS technology to stop third parties using it for missile
> guidance.

Most GPS receivers I came across are modules which spit out NMEA
records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There
may be others, but I don't want to have all problems of the world solved
at once.

-- hns

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Andreas Kemnade]

On Fri, 22 Jan 2016 20:12:29 +
One Thousand Gnomes  wrote:

> > I would have expected that the main (and IMO sufficient) reason why
> > the kernel should do it is because the particular bus used to connect
> > a BT chip to the CPU is a hw detail that a kernel that does its job
> > should keep to itself. Same as userspace not needing to care if a BT
> > chip is behind SDIO or USB, why does it have to tell the kernel behind
> > which UART a BT chip is sitting?
> 
> Lots of reasons, some historic some not
> 
> 1. Different BT chips have different interfaces, especially when it gets
> to stuff like firmware reprogramming
> 
> 2. In many cases we don't know at the kernel level where there are BT
> uarts. It's improving with recent ACPI but for many systems it's simply
> not available to the OS
> 
Same is true for i2c devices. The solution there is that you have various
methods for providing the information to the kernel, some 
are autoprobed, some are via board files and you can also tell via sysfs
that there is one device.

> 3. The power management for a lot of BT (especially on device tree) is
> not actually expressed, so you need a slightly customised daemon for each
> device - that one is ugly but the serial and bt layers can't fix it.
> 
That boils down to a circular it is not there because it is not there.
If we express the power management, it can be done in kernel.

> 4. Because you don't want to just automatically load and turn on
> bluetooth just because it is there - it burns power
> 
Exactly the same is true for wifi and for many other devices for
which drivers are automatically handled in kernel, too.
Well, do you have a list of devices which do not burn power?
I would be highly interested in those.

Regards,
Andreas


pgpPEGBL_N0Da.pgp
Description: OpenPGP digital signature

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> I would have expected that the main (and IMO sufficient) reason why
> the kernel should do it is because the particular bus used to connect
> a BT chip to the CPU is a hw detail that a kernel that does its job
> should keep to itself. Same as userspace not needing to care if a BT
> chip is behind SDIO or USB, why does it have to tell the kernel behind
> which UART a BT chip is sitting?

Lots of reasons, some historic some not

1. Different BT chips have different interfaces, especially when it gets
to stuff like firmware reprogramming

2. In many cases we don't know at the kernel level where there are BT
uarts. It's improving with recent ACPI but for many systems it's simply
not available to the OS

3. The power management for a lot of BT (especially on device tree) is
not actually expressed, so you need a slightly customised daemon for each
device - that one is ugly but the serial and bt layers can't fix it.

4. Because you don't want to just automatically load and turn on
bluetooth just because it is there - it burns power


There is lots of stuff we probe and bind via user space - most things
these days in fact. That's much of why we have notifiers and udev. It's
frequently a win in flexibility, security and configurability to do stuff
via user daemons. We do it for example with all the volume management,
raid and disk encryption.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Rob Herring]

On Fri, Jan 22, 2016 at 9:45 AM, Tomeu Vizoso  wrote:
> On 20 January 2016 at 19:03, H. Nikolaus Schaller  wrote:
>>
>> Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes 
>> :
>>
 The problem is that *I* have no control over user space. But I also don't 
 want
 to say to my users "that is not my problem - get it solved yourself". This 
 does
 not help them.
>>>
>>> Stuffing things into the kernel because the user space of a given
>>> platform can't get itself organised isn't helpful to the other billion
>>> plus Linux devices out there.
>>
>> The assumption that there is  "the" user space of a given platform is wrong.
>
> I'm a bit surprised at the arguments being exchanged here regarding
> why the kernel may or may not deal with the detail that a (say) BT
> chip is behind a uart.
>
> I would have expected that the main (and IMO sufficient) reason why
> the kernel should do it is because the particular bus used to connect
> a BT chip to the CPU is a hw detail that a kernel that does its job
> should keep to itself. Same as userspace not needing to care if a BT
> chip is behind SDIO or USB, why does it have to tell the kernel behind
> which UART a BT chip is sitting?

Thanks for writing exactly what I had not gotten around to writing.
You are exactly right. While historically UART devices where not
probe-able like SDIO (in theory) and USB are and maybe that was a
reason to handle in userspace, we do have the technology to describe
the UART connections now.

Adding Marcel who has also previously commented on the reasons why
this belongs in the kernel [1].

Rob

[1] 
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-August/002212.html

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Tomeu Vizoso]

On 20 January 2016 at 19:03, H. Nikolaus Schaller  wrote:
>
> Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes 
> :
>
>>> The problem is that *I* have no control over user space. But I also don't 
>>> want
>>> to say to my users "that is not my problem - get it solved yourself". This 
>>> does
>>> not help them.
>>
>> Stuffing things into the kernel because the user space of a given
>> platform can't get itself organised isn't helpful to the other billion
>> plus Linux devices out there.
>
> The assumption that there is  "the" user space of a given platform is wrong.

I'm a bit surprised at the arguments being exchanged here regarding
why the kernel may or may not deal with the detail that a (say) BT
chip is behind a uart.

I would have expected that the main (and IMO sufficient) reason why
the kernel should do it is because the particular bus used to connect
a BT chip to the CPU is a hw detail that a kernel that does its job
should keep to itself. Same as userspace not needing to care if a BT
chip is behind SDIO or USB, why does it have to tell the kernel behind
which UART a BT chip is sitting?

Regards,

Tomeu

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> I would have expected that the main (and IMO sufficient) reason why
> the kernel should do it is because the particular bus used to connect
> a BT chip to the CPU is a hw detail that a kernel that does its job
> should keep to itself. Same as userspace not needing to care if a BT
> chip is behind SDIO or USB, why does it have to tell the kernel behind
> which UART a BT chip is sitting?

Lots of reasons, some historic some not

1. Different BT chips have different interfaces, especially when it gets
to stuff like firmware reprogramming

2. In many cases we don't know at the kernel level where there are BT
uarts. It's improving with recent ACPI but for many systems it's simply
not available to the OS

3. The power management for a lot of BT (especially on device tree) is
not actually expressed, so you need a slightly customised daemon for each
device - that one is ugly but the serial and bt layers can't fix it.

4. Because you don't want to just automatically load and turn on
bluetooth just because it is there - it burns power


There is lots of stuff we probe and bind via user space - most things
these days in fact. That's much of why we have notifiers and udev. It's
frequently a win in flexibility, security and configurability to do stuff
via user daemons. We do it for example with all the volume management,
raid and disk encryption.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Andreas Kemnade]

On Fri, 22 Jan 2016 20:12:29 +
One Thousand Gnomes  wrote:

> > I would have expected that the main (and IMO sufficient) reason why
> > the kernel should do it is because the particular bus used to connect
> > a BT chip to the CPU is a hw detail that a kernel that does its job
> > should keep to itself. Same as userspace not needing to care if a BT
> > chip is behind SDIO or USB, why does it have to tell the kernel behind
> > which UART a BT chip is sitting?
> 
> Lots of reasons, some historic some not
> 
> 1. Different BT chips have different interfaces, especially when it gets
> to stuff like firmware reprogramming
> 
> 2. In many cases we don't know at the kernel level where there are BT
> uarts. It's improving with recent ACPI but for many systems it's simply
> not available to the OS
> 
Same is true for i2c devices. The solution there is that you have various
methods for providing the information to the kernel, some 
are autoprobed, some are via board files and you can also tell via sysfs
that there is one device.

> 3. The power management for a lot of BT (especially on device tree) is
> not actually expressed, so you need a slightly customised daemon for each
> device - that one is ugly but the serial and bt layers can't fix it.
> 
That boils down to a circular it is not there because it is not there.
If we express the power management, it can be done in kernel.

> 4. Because you don't want to just automatically load and turn on
> bluetooth just because it is there - it burns power
> 
Exactly the same is true for wifi and for many other devices for
which drivers are automatically handled in kernel, too.
Well, do you have a list of devices which do not burn power?
I would be highly interested in those.

Regards,
Andreas


pgpPEGBL_N0Da.pgp
Description: OpenPGP digital signature

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Tomeu Vizoso]

On 20 January 2016 at 19:03, H. Nikolaus Schaller  wrote:
>
> Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes 
> :
>
>>> The problem is that *I* have no control over user space. But I also don't 
>>> want
>>> to say to my users "that is not my problem - get it solved yourself". This 
>>> does
>>> not help them.
>>
>> Stuffing things into the kernel because the user space of a given
>> platform can't get itself organised isn't helpful to the other billion
>> plus Linux devices out there.
>
> The assumption that there is  "the" user space of a given platform is wrong.

I'm a bit surprised at the arguments being exchanged here regarding
why the kernel may or may not deal with the detail that a (say) BT
chip is behind a uart.

I would have expected that the main (and IMO sufficient) reason why
the kernel should do it is because the particular bus used to connect
a BT chip to the CPU is a hw detail that a kernel that does its job
should keep to itself. Same as userspace not needing to care if a BT
chip is behind SDIO or USB, why does it have to tell the kernel behind
which UART a BT chip is sitting?

Regards,

Tomeu

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Rob Herring]

On Fri, Jan 22, 2016 at 9:45 AM, Tomeu Vizoso  wrote:
> On 20 January 2016 at 19:03, H. Nikolaus Schaller  wrote:
>>
>> Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes 
>> :
>>
 The problem is that *I* have no control over user space. But I also don't 
 want
 to say to my users "that is not my problem - get it solved yourself". This 
 does
 not help them.
>>>
>>> Stuffing things into the kernel because the user space of a given
>>> platform can't get itself organised isn't helpful to the other billion
>>> plus Linux devices out there.
>>
>> The assumption that there is  "the" user space of a given platform is wrong.
>
> I'm a bit surprised at the arguments being exchanged here regarding
> why the kernel may or may not deal with the detail that a (say) BT
> chip is behind a uart.
>
> I would have expected that the main (and IMO sufficient) reason why
> the kernel should do it is because the particular bus used to connect
> a BT chip to the CPU is a hw detail that a kernel that does its job
> should keep to itself. Same as userspace not needing to care if a BT
> chip is behind SDIO or USB, why does it have to tell the kernel behind
> which UART a BT chip is sitting?

Thanks for writing exactly what I had not gotten around to writing.
You are exactly right. While historically UART devices where not
probe-able like SDIO (in theory) and USB are and maybe that was a
reason to handle in userspace, we do have the technology to describe
the UART connections now.

Adding Marcel who has also previously commented on the reasons why
this belongs in the kernel [1].

Rob

[1] 
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-August/002212.html

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Vostrikov Andrey]

Hi, Dmitry.

> On Fri, Jan 15, 2016 at 11:34 PM, Vostrikov Andrey
>  wrote:
>>
>> Yes, such implementation will help. There is a need for interface like UART 
>> BUS that will probe devices without user space.
>> Serial I/O for input subsystem defines new type of bus and uses dedicated 
>> line discipline, but it still unable to start driver by itself and requires 
>> call from 'inputattach' to open port, assign line discipline and go to 
>> forever wait on 'read'.

> That was done mainly because almost none of the serial protocols could
> be auto-probed, so device initialization/setup was moved out of kernel
> and thus we have the separate line discipline and inputattach utility.

This  is understandable for "dummy" devices like mice, that only
report input events.

But  in  case there is "intellectual" MCU, that must reply on specific
commands  with specific response - it could be auto-probed. Especially
when it is hardwired. Unfortunately, there  is  no  API  to  do  it.
Opening  port and attaching line discipline  from  kernel  side
does  not  look good. The only example is '/dev/console', which is
implemented that way.

> Thanks.

-- 
Best regards,
Andrey Vostrikov

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dmitry Torokhov]

On Fri, Jan 15, 2016 at 11:34 PM, Vostrikov Andrey
 wrote:
>
> Yes, such implementation will help. There is a need for interface like UART 
> BUS that will probe devices without user space.
> Serial I/O for input subsystem defines new type of bus and uses dedicated 
> line discipline, but it still unable to start driver by itself and requires 
> call from 'inputattach' to open port, assign line discipline and go to 
> forever wait on 'read'.

That was done mainly because almost none of the serial protocols could
be auto-probed, so device initialization/setup was moved out of kernel
and thus we have the separate line discipline and inputattach utility.

Thanks.

-- 
Dmitry

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes :

>> The problem is that *I* have no control over user space. But I also don't 
>> want
>> to say to my users "that is not my problem - get it solved yourself". This 
>> does
>> not help them.
> 
> Stuffing things into the kernel because the user space of a given
> platform can't get itself organised isn't helpful to the other billion
> plus Linux devices out there.

The assumption that there is  "the" user space of a given platform is wrong.

> 
>> And, most device drivers are corner cases since they are special solutions
>> for singular platforms.
> 
> Actually that is quite a small percentage - and the corner cases hide in
> drivers not in the core code, which is really important for
> maintainability.
> 
 I'm glad - because it raises some hard questions and while I don't agree
 with some of your starting points (like needing to "open" a uart without
 user space
>> 
>> If have an idea how to turn off the device at boot time, before any user 
>> space
>> daemon is running, we can of course ignore that.
> 
> Your early user space is responsible for it. If you can't accept that
> then I don't see any point continuing the conversation.

Exactly. There are two reasons:
* we want to make sure that it works for any user space
* it should be done as early as possible

> 
 But see below as I think your mental model is perhaps wrong
 and this is a point of confusion ?
>> 
>> Maybe you do not accept that I want to keep as low level as reasonable (for 
>> me).
> 
> It's always "for me". No the kernel project is not "for me"
> 
 Both of those techniques work in mainline without kernel changes (at
 least on devices where the right gpio sysfs nodes exist
>> 
>> they do not exist...
> 
> For most they do because they are gpio lines so exportable to userspace.
> 
 This I think is actually the really hard and interesting part of the
 problem. The "tell me about open and close" case is simple and can be
 done via tty_port today with minimal extra hooks. There is a small
 question about how you set those hooks from a DT binding
>> 
>> tty has no binding. An UART hardware has. Another reason for me to
>> start with UARTs.
> 
> Every uart is a tty_port, every non uart is a tty_port. There is no
> reason you can't bind to a non uart device. Your current patches create
> bindings for the uart layer.

Yes and no. The  { compatible = "something"; } already exists.

> 
 For some hardware that is the only way I know to do this because the
 power hungry uart receiver is physically powered down. I would have to
 check but I *think* that is true even on a modern x86 PC that supports
 wakeups via serial - although it may be well hidden in ACPI and firmware.
>> 
>> Yes, agreed. But the gpio + interrupt solution was not mainlineable as well.
> 
> That I am unsure about - at some point it is going to have to be sorted
> because it is increasingly common (if currently mostly invisible)
> 
 I'm not personally opoosed to the tty slave idea providing it ends up
 attached to the tty_port not just uart.
>> 
>> Well if you can tell us how to handle the data path I have no problems with 
>> it
>> to attach to the tty level.
> 
> If your port is closed you have no data path. If you are using uart you
> have no data path because while your patch hooks a helper that some uarts
> use some of the time it's optional and a lot of uarts don't use

I wasn't aware that lots of uart's don't use it. At least one is using it. I 
would have
to check which percentage is using it and which isn't. Thanks for pointing this
out.

> it, so
> its not even uart generic.

Understood. I wasn't aware of that.

I just was under the false impression that this is the recommended common
and a well designed (object oriented) interface. struct uart_port
being the object and the uart_ops assigned to it, being the list of methods
that can be applied to an uart_port.

http://lxr.free-electrons.com/source/Documentation/serial/driver#L14
http://lxr.free-electrons.com/source/include/linux/serial_core.h#L45
http://lxr.free-electrons.com/source/include/linux/serial_core.h#L235

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> The problem is that *I* have no control over user space. But I also don't want
> to say to my users "that is not my problem - get it solved yourself". This 
> does
> not help them.

Stuffing things into the kernel because the user space of a given
platform can't get itself organised isn't helpful to the other billion
plus Linux devices out there.

> And, most device drivers are corner cases since they are special solutions
> for singular platforms.

Actually that is quite a small percentage - and the corner cases hide in
drivers not in the core code, which is really important for
maintainability.

> >> I'm glad - because it raises some hard questions and while I don't agree
> >> with some of your starting points (like needing to "open" a uart without
> >> user space
> 
> If have an idea how to turn off the device at boot time, before any user space
> daemon is running, we can of course ignore that.

Your early user space is responsible for it. If you can't accept that
then I don't see any point continuing the conversation.

> >> But see below as I think your mental model is perhaps wrong
> >> and this is a point of confusion ?
> 
> Maybe you do not accept that I want to keep as low level as reasonable (for 
> me).

It's always "for me". No the kernel project is not "for me"

> >> Both of those techniques work in mainline without kernel changes (at
> >> least on devices where the right gpio sysfs nodes exist
> 
> they do not exist...

For most they do because they are gpio lines so exportable to userspace.

> >> This I think is actually the really hard and interesting part of the
> >> problem. The "tell me about open and close" case is simple and can be
> >> done via tty_port today with minimal extra hooks. There is a small
> >> question about how you set those hooks from a DT binding
> 
> tty has no binding. An UART hardware has. Another reason for me to
> start with UARTs.

Every uart is a tty_port, every non uart is a tty_port. There is no
reason you can't bind to a non uart device. Your current patches create
bindings for the uart layer.

> >> For some hardware that is the only way I know to do this because the
> >> power hungry uart receiver is physically powered down. I would have to
> >> check but I *think* that is true even on a modern x86 PC that supports
> >> wakeups via serial - although it may be well hidden in ACPI and firmware.
> 
> Yes, agreed. But the gpio + interrupt solution was not mainlineable as well.

That I am unsure about - at some point it is going to have to be sorted
because it is increasingly common (if currently mostly invisible)
 
> >> I'm not personally opoosed to the tty slave idea providing it ends up
> >> attached to the tty_port not just uart.
> 
> Well if you can tell us how to handle the data path I have no problems with it
> to attach to the tty level.

If your port is closed you have no data path. If you are using uart you
have no data path because while your patch hooks a helper that some uarts
use some of the time it's optional and a lot of uarts don't use it, so
its not even uart generic.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Next mail.

Am 19.01.2016 um 15:25 schrieb One Thousand Gnomes :

>>> Whoever puts the distribution together. The kernel runs init. Beyond that
>>> we don't care. Not our problem. You can boot into emacs if you want.
>> 
>> Well, it is my big problem which goes contrary to our goal to have the best
>> supported platform... We would have to provide and maintain such things
>> so that they are compatible to a plethora of unknown runtime environments.
> 
> Every platform does this and has to do this. GTA04 userspace is different
> to Raspberry PI userspace is different to PC userspace etc. Your graphics
> is different to other people, you don't have a keyboard. All these
> require there is some customisation going on.

Not necessarily. If it is well designed and every problem is solved at the right
place.

In the case of our GPS chip some customization is already there in standard
user space code. Users can just choose or configure some /dev/tty name for
their standard navigation apps and daemons and it everything else should be
done by the kernel.

Neil did describe the goal long ago:

http://neil.brown.name/blog/20120724060722

> 
>>> - There isn't a nice way to bind extra non device specific behaviour to
>>> open and close (but we have the right places to add one)
>>> 
>>> - There isn't a way to monitor rx data (and this is *really* hard to
>>> sort especially when the uart is powered down)
>> 
>> Exactly. This is why we already work 3 years on this topic...
>> 
>> The solution is to optionally keep it powered up - as long as the peer
>> device asks for.
> 
> That won't work on a lot of platforms. They need to power down the uart
> to get the power savings and they expect some kind of other monitor like
> GPIO. Eg some x86 power states are not achievable on certain SoCs with the
> uart powered up. We are already using GPIO triggers on lots of devices,
> even if people haven't noticed what is going on because the firmware
> hides it all or it's done in user space on the device.

Our proposal is completely optional. If there is no UART peer, everything
runs as it does today. Only in the case the device driver needs the UART
to stay powered on it remains powered on.

> 
> For that to work generically we would need a way to go from a serial port
> to a gpio or other monitor setting, described via ACPI and/or DT.

In other words you ask for a device driver... A device driver that knows
which serial port and which gpio. And its exact setting are defined by DT.

This is exactly what we propose. We just need the connection from a
serial interface to that driver to do the monitoring.

> We'd
> also need a way to open a port in powered off mode, or perhaps to be able
> to make open() block for an event on the downed port (just like today you
> can block for carrier), but do it before bringing the port active and thus
> powering it on.
> 
> I don't like the open case because it then means you can't use poll() on
> a set of ports to wait cleanly for an event to power them on but the
> alternative is really hard because you would have to know that no other
> thread of execution or IRQ handler or timer for the port could touch the
> hardware
> 
> - you were the only thread of execution in the driver
> - you held sufficient locks to prevent any other thread of execution
>  entering your tty code and touching the hardware
> 
> and then in effect do
> 
>   tty_port_shutdown   // power down
>   port->ops->monitor_rx() (some new method)
>   tty_port_open   // power up
> 
> We don't normally get into the situation where we have a userspace or
> kernel reference open to a device which may be physically powered off.
> 
> In that sense having the gpio monitoring separate and the relationship
> described to user space (or to some gpio/monitoring driver) by DT is a
> lot cleaner IMHO.
> 
> The open case can be made to work so that opening the tty can block with
> it powered off until an event happens, then powers up the uart. That one
> would be doable.

In our solution it simply powers up the UART and then it sets the mctrl DTR line
This will make the driver wake up the device. I.e. the problem you describe
does not exist.

> 
 What is in your view the right abstraction point for a peer device driver 
 to get
 notified about rx characters (even if the tty is currently not open)?
>>> 
>>> I don't think you have one. A lot of hardware has the receiver and
>>> transceiver physically powered off when the tty is closed. You can't even
>>> touch the registers in some cases (eg a PCI port in D3

Ok, I think it is time to summarize (a little exaggerated) the discussion:

1. technical side:
* you prefer to attach to the tty layer
* you can solve the open/close issue
* you can not solve the rx monitoring issue
* we attach to the uart_port layer
* we have a working solution
* we avoid to handle rx monitoring and rx data processing separately

2. non-techncial side ("belief" level)
* you see the GTA04 as 

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Alan,
here the missing answers.

Am 18.01.2016 um 23:32 schrieb H. Nikolaus Schaller :

> Just a first short answer (can't work 7/24 :).
> 
> Am 18.01.2016 um 23:03 schrieb One Thousand Gnomes 
> :
> 
 Your user space can do it (as most Android does).
>>> 
>>> How can it do it in automatically in a standardized way without need for 
>>> daemon support?
>> 
>> You don't need to - it can be device specific. In Android it usually is.
>> I've never understood why low end devices don't also abstract user space
>> descriptions of power control into DT nodes as well as kernel properties ?

I don't know.

But what I know is that I don't want to solve someone else's problems...

>> 
>>> * how can the daemon present another /dev/tty so that applications 
>>> expecting such
>>> an interface can attach to it (maybe through pty - but isn't that an 
>>> overkill?)
>> 
>> You don't need to - you can monitor the rx/tx stats via procfs too. Not
>> pretty but given the daemon can do both the decoding and the monitoring
>> for your device it all seems a strawman. I'd argue given the sheer range
>> of ways people PM a GPS that you ought to have those power abstractions
>> in the user space daemon. They might use kernel methods, they might not.

The problem is that *I* have no control over user space. But I also don't want
to say to my users "that is not my problem - get it solved yourself". This does
not help them.

Especially as I can help them with the kernel based solutions we have.

>> 
>>> * Who makes sure that this daemon is installed and running right after boot 
>>> up on *any* Linux system
>>> so that it can always react in case that the chip did start when it should 
>>> be off?
>> 
>> Whoever puts the distribution together. The kernel runs init. Beyond that
>> we don't care. Not our problem. You can boot into emacs if you want.
> 
> Well, it is my big problem which goes contrary to our goal to have the best
> supported platform... We would have to provide and maintain such things
> so that they are compatible to a plethora of unknown runtime environments.
> 
>> 
>> 
>>> More generally: what is a kernel good for? Why do we need kernel drivers?
>> 
>> To maintain security, to manage hardware elements that cannot be managed
>> in user space,

Ahem. Most hardware elements can be manages in user space. Use FUSE for
everything and you will only need 10% of the kernel code.

So why are you always arguing with exaggerations?

>> and to provide abstractions where the abstraction is
>> necessary and meaningful to a large number of users (not a corner case
>> phone device

well, phone devices in general outnumber all other devices in sheer numbers.

Yes, the GTA04 has low quantities. But the main hurdle I always hear is that
the kernel is not good enough.

>> unless the abstraction can be made meaningful and widely
>> useful).

And, most device drivers are corner cases since they are special solutions
for singular platforms.

>> 
>>> Just think about waking up the daemon process if a character is received. 
>>> This is
>>> much more costly than calling a notification function in the kernel driver 
>>> which might
>>> have to execute just 4 or 5 assembler instructions to decide what to do.
>> 
>> The logical continuation of that is of course not to have user space but
>> write your entire phone device in ring 0. Point being it is always a
>> trade off.
>> 
>> Your only way currently to do that is to open the tty and set a line
>> discipline which does your monitoring then hold it open. We can't stack
>> ldiscs either. If you want to monitor the line state with the physical
>> uart receiver powered down then this won't work at all.
>> 
>>> So kernel drivers are sometimes the best solution and more efficient and 
>>> controllable
>>> than a user space daemon.
>> 
>> Sometimes but not always.

I am only interested in this case and here it obviously is.

>> And even if a kernel device is the right
>> solution to your device that doesn't mean it's general purpose enough to
>> justify being stuffed upstream. Android is full of "interesting" device
>> specific tweaks the sum of which would sink the kernel project.

This is of course an argument which we have to overcome.

>> 
>>> I understand that. But what is Linux good for? For it's own sake or for
>>> users and platforms using it? Isn't it that we take it from the community
>>> and contribute improvements back to it?
>> 
>> Only when the community benefits overall.

Yes, it benefits because there are several requests for such tty/uart 
slaves/peers.
>From this I deduce that there is community demand.

I brought up this discussion again, because Andrey and Tomeu recently asked
for progress.

>> 
>>> So to me it appears that such a kernel feature is missing. Therefore we
>>> are discussing it.
>> 
>> I'm glad - because it raises some hard questions and while I don't agree
>> with some of your starting points (like needing to "open" a uart without
>> user space

If have an 

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Next mail.

Am 19.01.2016 um 15:25 schrieb One Thousand Gnomes :

>>> Whoever puts the distribution together. The kernel runs init. Beyond that
>>> we don't care. Not our problem. You can boot into emacs if you want.
>> 
>> Well, it is my big problem which goes contrary to our goal to have the best
>> supported platform... We would have to provide and maintain such things
>> so that they are compatible to a plethora of unknown runtime environments.
> 
> Every platform does this and has to do this. GTA04 userspace is different
> to Raspberry PI userspace is different to PC userspace etc. Your graphics
> is different to other people, you don't have a keyboard. All these
> require there is some customisation going on.

Not necessarily. If it is well designed and every problem is solved at the right
place.

In the case of our GPS chip some customization is already there in standard
user space code. Users can just choose or configure some /dev/tty name for
their standard navigation apps and daemons and it everything else should be
done by the kernel.

Neil did describe the goal long ago:

http://neil.brown.name/blog/20120724060722

> 
>>> - There isn't a nice way to bind extra non device specific behaviour to
>>> open and close (but we have the right places to add one)
>>> 
>>> - There isn't a way to monitor rx data (and this is *really* hard to
>>> sort especially when the uart is powered down)
>> 
>> Exactly. This is why we already work 3 years on this topic...
>> 
>> The solution is to optionally keep it powered up - as long as the peer
>> device asks for.
> 
> That won't work on a lot of platforms. They need to power down the uart
> to get the power savings and they expect some kind of other monitor like
> GPIO. Eg some x86 power states are not achievable on certain SoCs with the
> uart powered up. We are already using GPIO triggers on lots of devices,
> even if people haven't noticed what is going on because the firmware
> hides it all or it's done in user space on the device.

Our proposal is completely optional. If there is no UART peer, everything
runs as it does today. Only in the case the device driver needs the UART
to stay powered on it remains powered on.

> 
> For that to work generically we would need a way to go from a serial port
> to a gpio or other monitor setting, described via ACPI and/or DT.

In other words you ask for a device driver... A device driver that knows
which serial port and which gpio. And its exact setting are defined by DT.

This is exactly what we propose. We just need the connection from a
serial interface to that driver to do the monitoring.

> We'd
> also need a way to open a port in powered off mode, or perhaps to be able
> to make open() block for an event on the downed port (just like today you
> can block for carrier), but do it before bringing the port active and thus
> powering it on.
> 
> I don't like the open case because it then means you can't use poll() on
> a set of ports to wait cleanly for an event to power them on but the
> alternative is really hard because you would have to know that no other
> thread of execution or IRQ handler or timer for the port could touch the
> hardware
> 
> - you were the only thread of execution in the driver
> - you held sufficient locks to prevent any other thread of execution
>  entering your tty code and touching the hardware
> 
> and then in effect do
> 
>   tty_port_shutdown   // power down
>   port->ops->monitor_rx() (some new method)
>   tty_port_open   // power up
> 
> We don't normally get into the situation where we have a userspace or
> kernel reference open to a device which may be physically powered off.
> 
> In that sense having the gpio monitoring separate and the relationship
> described to user space (or to some gpio/monitoring driver) by DT is a
> lot cleaner IMHO.
> 
> The open case can be made to work so that opening the tty can block with
> it powered off until an event happens, then powers up the uart. That one
> would be doable.

In our solution it simply powers up the UART and then it sets the mctrl DTR line
This will make the driver wake up the device. I.e. the problem you describe
does not exist.

> 
 What is in your view the right abstraction point for a peer device driver 
 to get
 notified about rx characters (even if the tty is currently not open)?
>>> 
>>> I don't think you have one. A lot of hardware has the receiver and
>>> transceiver physically powered off when the tty is closed. You can't even
>>> touch the registers in some cases (eg a PCI port in D3

Ok, I think it is time to summarize (a little exaggerated) the discussion:

1. technical side:
* you prefer to attach to the tty layer
* you can solve the open/close issue
* you can not solve the rx monitoring issue
* we attach to the uart_port layer
* we have a working solution
* we avoid to handle rx monitoring and rx data processing separately

2. non-techncial side ("belief" 

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes]

> The problem is that *I* have no control over user space. But I also don't want
> to say to my users "that is not my problem - get it solved yourself". This 
> does
> not help them.

Stuffing things into the kernel because the user space of a given
platform can't get itself organised isn't helpful to the other billion
plus Linux devices out there.

> And, most device drivers are corner cases since they are special solutions
> for singular platforms.

Actually that is quite a small percentage - and the corner cases hide in
drivers not in the core code, which is really important for
maintainability.

> >> I'm glad - because it raises some hard questions and while I don't agree
> >> with some of your starting points (like needing to "open" a uart without
> >> user space
> 
> If have an idea how to turn off the device at boot time, before any user space
> daemon is running, we can of course ignore that.

Your early user space is responsible for it. If you can't accept that
then I don't see any point continuing the conversation.

> >> But see below as I think your mental model is perhaps wrong
> >> and this is a point of confusion ?
> 
> Maybe you do not accept that I want to keep as low level as reasonable (for 
> me).

It's always "for me". No the kernel project is not "for me"

> >> Both of those techniques work in mainline without kernel changes (at
> >> least on devices where the right gpio sysfs nodes exist
> 
> they do not exist...

For most they do because they are gpio lines so exportable to userspace.

> >> This I think is actually the really hard and interesting part of the
> >> problem. The "tell me about open and close" case is simple and can be
> >> done via tty_port today with minimal extra hooks. There is a small
> >> question about how you set those hooks from a DT binding
> 
> tty has no binding. An UART hardware has. Another reason for me to
> start with UARTs.

Every uart is a tty_port, every non uart is a tty_port. There is no
reason you can't bind to a non uart device. Your current patches create
bindings for the uart layer.

> >> For some hardware that is the only way I know to do this because the
> >> power hungry uart receiver is physically powered down. I would have to
> >> check but I *think* that is true even on a modern x86 PC that supports
> >> wakeups via serial - although it may be well hidden in ACPI and firmware.
> 
> Yes, agreed. But the gpio + interrupt solution was not mainlineable as well.

That I am unsure about - at some point it is going to have to be sorted
because it is increasingly common (if currently mostly invisible)
 
> >> I'm not personally opoosed to the tty slave idea providing it ends up
> >> attached to the tty_port not just uart.
> 
> Well if you can tell us how to handle the data path I have no problems with it
> to attach to the tty level.

If your port is closed you have no data path. If you are using uart you
have no data path because while your patch hooks a helper that some uarts
use some of the time it's optional and a lot of uarts don't use it, so
its not even uart generic.

Alan

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes :

>> The problem is that *I* have no control over user space. But I also don't 
>> want
>> to say to my users "that is not my problem - get it solved yourself". This 
>> does
>> not help them.
> 
> Stuffing things into the kernel because the user space of a given
> platform can't get itself organised isn't helpful to the other billion
> plus Linux devices out there.

The assumption that there is  "the" user space of a given platform is wrong.

> 
>> And, most device drivers are corner cases since they are special solutions
>> for singular platforms.
> 
> Actually that is quite a small percentage - and the corner cases hide in
> drivers not in the core code, which is really important for
> maintainability.
> 
 I'm glad - because it raises some hard questions and while I don't agree
 with some of your starting points (like needing to "open" a uart without
 user space
>> 
>> If have an idea how to turn off the device at boot time, before any user 
>> space
>> daemon is running, we can of course ignore that.
> 
> Your early user space is responsible for it. If you can't accept that
> then I don't see any point continuing the conversation.

Exactly. There are two reasons:
* we want to make sure that it works for any user space
* it should be done as early as possible

> 
 But see below as I think your mental model is perhaps wrong
 and this is a point of confusion ?
>> 
>> Maybe you do not accept that I want to keep as low level as reasonable (for 
>> me).
> 
> It's always "for me". No the kernel project is not "for me"
> 
 Both of those techniques work in mainline without kernel changes (at
 least on devices where the right gpio sysfs nodes exist
>> 
>> they do not exist...
> 
> For most they do because they are gpio lines so exportable to userspace.
> 
 This I think is actually the really hard and interesting part of the
 problem. The "tell me about open and close" case is simple and can be
 done via tty_port today with minimal extra hooks. There is a small
 question about how you set those hooks from a DT binding
>> 
>> tty has no binding. An UART hardware has. Another reason for me to
>> start with UARTs.
> 
> Every uart is a tty_port, every non uart is a tty_port. There is no
> reason you can't bind to a non uart device. Your current patches create
> bindings for the uart layer.

Yes and no. The  { compatible = "something"; } already exists.

> 
 For some hardware that is the only way I know to do this because the
 power hungry uart receiver is physically powered down. I would have to
 check but I *think* that is true even on a modern x86 PC that supports
 wakeups via serial - although it may be well hidden in ACPI and firmware.
>> 
>> Yes, agreed. But the gpio + interrupt solution was not mainlineable as well.
> 
> That I am unsure about - at some point it is going to have to be sorted
> because it is increasingly common (if currently mostly invisible)
> 
 I'm not personally opoosed to the tty slave idea providing it ends up
 attached to the tty_port not just uart.
>> 
>> Well if you can tell us how to handle the data path I have no problems with 
>> it
>> to attach to the tty level.
> 
> If your port is closed you have no data path. If you are using uart you
> have no data path because while your patch hooks a helper that some uarts
> use some of the time it's optional and a lot of uarts don't use

I wasn't aware that lots of uart's don't use it. At least one is using it. I 
would have
to check which percentage is using it and which isn't. Thanks for pointing this
out.

> it, so
> its not even uart generic.

Understood. I wasn't aware of that.

I just was under the false impression that this is the recommended common
and a well designed (object oriented) interface. struct uart_port
being the object and the uart_ops assigned to it, being the list of methods
that can be applied to an uart_port.

http://lxr.free-electrons.com/source/Documentation/serial/driver#L14
http://lxr.free-electrons.com/source/include/linux/serial_core.h#L45
http://lxr.free-electrons.com/source/include/linux/serial_core.h#L235

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Alan,
here the missing answers.

Am 18.01.2016 um 23:32 schrieb H. Nikolaus Schaller :

> Just a first short answer (can't work 7/24 :).
> 
> Am 18.01.2016 um 23:03 schrieb One Thousand Gnomes 
> :
> 
 Your user space can do it (as most Android does).
>>> 
>>> How can it do it in automatically in a standardized way without need for 
>>> daemon support?
>> 
>> You don't need to - it can be device specific. In Android it usually is.
>> I've never understood why low end devices don't also abstract user space
>> descriptions of power control into DT nodes as well as kernel properties ?

I don't know.

But what I know is that I don't want to solve someone else's problems...

>> 
>>> * how can the daemon present another /dev/tty so that applications 
>>> expecting such
>>> an interface can attach to it (maybe through pty - but isn't that an 
>>> overkill?)
>> 
>> You don't need to - you can monitor the rx/tx stats via procfs too. Not
>> pretty but given the daemon can do both the decoding and the monitoring
>> for your device it all seems a strawman. I'd argue given the sheer range
>> of ways people PM a GPS that you ought to have those power abstractions
>> in the user space daemon. They might use kernel methods, they might not.

The problem is that *I* have no control over user space. But I also don't want
to say to my users "that is not my problem - get it solved yourself". This does
not help them.

Especially as I can help them with the kernel based solutions we have.

>> 
>>> * Who makes sure that this daemon is installed and running right after boot 
>>> up on *any* Linux system
>>> so that it can always react in case that the chip did start when it should 
>>> be off?
>> 
>> Whoever puts the distribution together. The kernel runs init. Beyond that
>> we don't care. Not our problem. You can boot into emacs if you want.
> 
> Well, it is my big problem which goes contrary to our goal to have the best
> supported platform... We would have to provide and maintain such things
> so that they are compatible to a plethora of unknown runtime environments.
> 
>> 
>> 
>>> More generally: what is a kernel good for? Why do we need kernel drivers?
>> 
>> To maintain security, to manage hardware elements that cannot be managed
>> in user space,

Ahem. Most hardware elements can be manages in user space. Use FUSE for
everything and you will only need 10% of the kernel code.

So why are you always arguing with exaggerations?

>> and to provide abstractions where the abstraction is
>> necessary and meaningful to a large number of users (not a corner case
>> phone device

well, phone devices in general outnumber all other devices in sheer numbers.

Yes, the GTA04 has low quantities. But the main hurdle I always hear is that
the kernel is not good enough.

>> unless the abstraction can be made meaningful and widely
>> useful).

And, most device drivers are corner cases since they are special solutions
for singular platforms.

>> 
>>> Just think about waking up the daemon process if a character is received. 
>>> This is
>>> much more costly than calling a notification function in the kernel driver 
>>> which might
>>> have to execute just 4 or 5 assembler instructions to decide what to do.
>> 
>> The logical continuation of that is of course not to have user space but
>> write your entire phone device in ring 0. Point being it is always a
>> trade off.
>> 
>> Your only way currently to do that is to open the tty and set a line
>> discipline which does your monitoring then hold it open. We can't stack
>> ldiscs either. If you want to monitor the line state with the physical
>> uart receiver powered down then this won't work at all.
>> 
>>> So kernel drivers are sometimes the best solution and more efficient and 
>>> controllable
>>> than a user space daemon.
>> 
>> Sometimes but not always.

I am only interested in this case and here it obviously is.

>> And even if a kernel device is the right
>> solution to your device that doesn't mean it's general purpose enough to
>> justify being stuffed upstream. Android is full of "interesting" device
>> specific tweaks the sum of which would sink the kernel project.

This is of course an argument which we have to overcome.

>> 
>>> I understand that. But what is Linux good for? For it's own sake or for
>>> users and platforms using it? Isn't it that we take it from the community
>>> and contribute improvements back to it?
>> 
>> Only when the community benefits overall.

Yes, it benefits because there are several requests for such tty/uart 
slaves/peers.
>From this I deduce that there is community demand.

I brought up this discussion again, because Andrey and Tomeu recently asked
for progress.

>> 
>>> So to me it appears that such a kernel feature is missing. Therefore we
>>> are discussing it.
>> 
>> I'm glad - because it raises some hard questions and while I don't agree
>> with some of your starting points (like needing to 

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dmitry Torokhov]

On Fri, Jan 15, 2016 at 11:34 PM, Vostrikov Andrey
 wrote:
>
> Yes, such implementation will help. There is a need for interface like UART 
> BUS that will probe devices without user space.
> Serial I/O for input subsystem defines new type of bus and uses dedicated 
> line discipline, but it still unable to start driver by itself and requires 
> call from 'inputattach' to open port, assign line discipline and go to 
> forever wait on 'read'.

That was done mainly because almost none of the serial protocols could
be auto-probed, so device initialization/setup was moved out of kernel
and thus we have the separate line discipline and inputattach utility.

Thanks.

-- 
Dmitry

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Vostrikov Andrey]

Hi, Dmitry.

> On Fri, Jan 15, 2016 at 11:34 PM, Vostrikov Andrey
>  wrote:
>>
>> Yes, such implementation will help. There is a need for interface like UART 
>> BUS that will probe devices without user space.
>> Serial I/O for input subsystem defines new type of bus and uses dedicated 
>> line discipline, but it still unable to start driver by itself and requires 
>> call from 'inputattach' to open port, assign line discipline and go to 
>> forever wait on 'read'.

> That was done mainly because almost none of the serial protocols could
> be auto-probed, so device initialization/setup was moved out of kernel
> and thus we have the separate line discipline and inputattach utility.

This  is understandable for "dummy" devices like mice, that only
report input events.

But  in  case there is "intellectual" MCU, that must reply on specific
commands  with specific response - it could be auto-probed. Especially
when it is hardwired. Unfortunately, there  is  no  API  to  do  it.
Opening  port and attaching line discipline  from  kernel  side
does  not  look good. The only example is '/dev/console', which is
implemented that way.

> Thanks.

-- 
Best regards,
Andrey Vostrikov

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Christ van Willegen]

Hi all,

I will reverse a part of this e-mail to make replying easier.

On Fri, Aug 28, 2015 at 1:04 PM, Pavel Machek  wrote:
>> Please have a look into our RFC implementation and study it carefully
>> to learn why it is the better (IMHO more flexible, easier to maintain, more
>> modular) approach. Even if you don’t like phandles.
>
> It was also NAKed by device tree maintainers.

This may be true, I can't recall those specific mails...

> You promised to shut up.

But this is uncalled for.

IIRC there was, indeed, a long technical discussion about how to
connect the Bluetooth chip to the 'UART'.

I've seen Neil patches, and I've seen patches by Nikolaus.

Both appear to have their problems. I think it's fair to:

- Listen carefully to all arguments.
- Have a benevolent dictator, which we have, look into the problem
- Only 'shut up' after a thorough technical analysis has been made
about both approaches to the problem.

Both may have their merit in a number of ways. Don't just close your
eyes, put your fingers in your ears and say 'I can't hear you!'. We
are all adults, or at least, we should be in behaviour. The Linux
system has grown so much _beacuse_ of people working together. Calling
each other names and exiling them will _not_ solve the problem.

Christ van Willegen
-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Pavel Machek]

> > asking "device tree maintainer opinion", and then just simply ignoring
> > it when he does not like it, and then making promises he did not keep.
> 
> Which promises did I not keep? Please be specific, instead of

You promised to shut up.

> Please have a look into our RFC implementation and study it carefully
> to learn why it is the better (IMHO more flexible, easier to maintain, more
> modular) approach. Even if you don’t like phandles.

It was also NAKed by device tree maintainers.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 28.08.2015 um 09:02 schrieb Pavel Machek :

> Hi!
> 
>> we (the developers of the hardware) have proposed an alternative
>> approach to Neil’s implementation - for the same device and solving
>> the same problem (notifying tty open/close and uart activity to the
>> slave device driver), but differently.
>> 
>> See:
>> https://lkml.org/lkml/2015/6/28/91
>> 
>> Discussion has not yet settled on which approach is better. So your
>> opinion of comparing both is welcome.
> 
> Actually, yes, discussion has settled, agreeing that phandle reference
> for the uart is a bad idea, Nikolaus just refuses to listen to anyone,

no, I only refuse to listen to you.

You are neither maintainer for any subsystem that is involved nor have
you contributed technical arguments pro/con and it appears to me that
you refuse to listen to my argumentation.

> asking "device tree maintainer opinion", and then just simply ignoring
> it when he does not like it, and then making promises he did not keep.


Which promises did I not keep? Please be specific, instead of insulting.

I bring up this alternative again, since I get the impression that most readers
are simply not aware of *both* alternative proposals.

> Please don't stall patches just because of that.

Please provide better arguments and don’t spread FUD.

Please have a look into our RFC implementation and study it carefully
to learn why it is the better (IMHO more flexible, easier to maintain, more
modular) approach. Even if you don’t like phandles.

> 
> Best regards,
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


BR,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Pavel Machek]

Hi!

> we (the developers of the hardware) have proposed an alternative
> approach to Neil’s implementation - for the same device and solving
> the same problem (notifying tty open/close and uart activity to the
> slave device driver), but differently.
> 
> See:
> https://lkml.org/lkml/2015/6/28/91
> 
> Discussion has not yet settled on which approach is better. So your
> opinion of comparing both is welcome.

Actually, yes, discussion has settled, agreeing that phandle reference
for the uart is a bad idea, Nikolaus just refuses to listen to anyone,
asking "device tree maintainer opinion", and then just simply ignoring
it when he does not like it, and then making promises he did not keep.

Please don't stall patches just because of that.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Pavel Machek]

Hi!

 we (the developers of the hardware) have proposed an alternative
 approach to Neil’s implementation - for the same device and solving
 the same problem (notifying tty open/close and uart activity to the
 slave device driver), but differently.
 
 See:
 https://lkml.org/lkml/2015/6/28/91
 
 Discussion has not yet settled on which approach is better. So your
 opinion of comparing both is welcome.

Actually, yes, discussion has settled, agreeing that phandle reference
for the uart is a bad idea, Nikolaus just refuses to listen to anyone,
asking device tree maintainer opinion, and then just simply ignoring
it when he does not like it, and then making promises he did not keep.

Please don't stall patches just because of that.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 28.08.2015 um 09:02 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 we (the developers of the hardware) have proposed an alternative
 approach to Neil’s implementation - for the same device and solving
 the same problem (notifying tty open/close and uart activity to the
 slave device driver), but differently.
 
 See:
 https://lkml.org/lkml/2015/6/28/91
 
 Discussion has not yet settled on which approach is better. So your
 opinion of comparing both is welcome.
 
 Actually, yes, discussion has settled, agreeing that phandle reference
 for the uart is a bad idea, Nikolaus just refuses to listen to anyone,

no, I only refuse to listen to you.

You are neither maintainer for any subsystem that is involved nor have
you contributed technical arguments pro/con and it appears to me that
you refuse to listen to my argumentation.

 asking device tree maintainer opinion, and then just simply ignoring
 it when he does not like it, and then making promises he did not keep.


Which promises did I not keep? Please be specific, instead of insulting.

I bring up this alternative again, since I get the impression that most readers
are simply not aware of *both* alternative proposals.

 Please don't stall patches just because of that.

Please provide better arguments and don’t spread FUD.

Please have a look into our RFC implementation and study it carefully
to learn why it is the better (IMHO more flexible, easier to maintain, more
modular) approach. Even if you don’t like phandles.

 
 Best regards,
   Pavel
 -- 
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


BR,
Nikolaus

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Pavel Machek]

  asking device tree maintainer opinion, and then just simply ignoring
  it when he does not like it, and then making promises he did not keep.
 
 Which promises did I not keep? Please be specific, instead of

You promised to shut up.

 Please have a look into our RFC implementation and study it carefully
 to learn why it is the better (IMHO more flexible, easier to maintain, more
 modular) approach. Even if you don’t like phandles.

It was also NAKed by device tree maintainers.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Christ van Willegen]

Hi all,

I will reverse a part of this e-mail to make replying easier.

On Fri, Aug 28, 2015 at 1:04 PM, Pavel Machek pa...@ucw.cz wrote:
 Please have a look into our RFC implementation and study it carefully
 to learn why it is the better (IMHO more flexible, easier to maintain, more
 modular) approach. Even if you don’t like phandles.

 It was also NAKed by device tree maintainers.

This may be true, I can't recall those specific mails...

 You promised to shut up.

But this is uncalled for.

IIRC there was, indeed, a long technical discussion about how to
connect the Bluetooth chip to the 'UART'.

I've seen Neil patches, and I've seen patches by Nikolaus.

Both appear to have their problems. I think it's fair to:

- Listen carefully to all arguments.
- Have a benevolent dictator, which we have, look into the problem
- Only 'shut up' after a thorough technical analysis has been made
about both approaches to the problem.

Both may have their merit in a number of ways. Don't just close your
eyes, put your fingers in your ears and say 'I can't hear you!'. We
are all adults, or at least, we should be in behaviour. The Linux
system has grown so much _beacuse_ of people working together. Calling
each other names and exiling them will _not_ solve the problem.

Christ van Willegen
-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dr. H. Nikolaus Schaller]

Hi Linus,

Am 12.08.2015 um 01:20 schrieb NeilBrown :

> On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
>  wrote:
> 
>> Hi Neil,
>> 
>> first, this is a *VERY* interesting and much needed patch series,
>> I intend to look closer at it, and if possible test it with some
>> (heh) board file device. Would be happy of you put me on CC for these.
>> 
>> On Mon, May 11, 2015 at 3:56 AM, NeilBrown  wrote:
>> 
>>> When a device is connected to a UART via RS-232 (or similar), there
>>> is a DTR line that can be used for power management, and other "modem
>>> control" lines.
>>> 
>>> On an embedded board, it is very likely that there is no "DTR", and
>>> any power management need to be done using some completely separate
>>> mechanism.
>>> 
>>> So these "slaves" are really just for devices permanently attached to
>>> UARTs without a full "RS-232" (or similar) connection.  The driver
>>> does all the extra control beyond Tx/Rx.
>> 
>> What is usually happening (and I have seen it in a few places) is that
>> the SoC has *one* fully featured RS232 with CTS/RTS and even
>> DTS,DCD,RI and other esoterica, which is intended to be connected to a
>> host serial port or so, for example if this SoC is to act as a modem
>> or a fax machine, or if it is to drive one.
>> 
>> Then they often have a few more UART blocks, usually identical, which
>> only have RxD+TxD available, so they are "just" UARTs.
>> 
>> To complicate things further, you may wonder what happened with
>> the CTS/RTS (etc) signals from the other blocks. Usually they are there
>> in the silicon but just routed to dead ends.
>> 
>> To complicate it even further, usually all these pins are placed under
>> pin control multiplexing, so in an actual electronic design, the
>> system will mux out CTS/RTS (etc) from the fully featured RS232
>> blocks and only use them as UARTs anyways.
>> 
>> Then there are those who created real simple RxD/TxD-only UARTs
>> ("yeah lets dump this RS232 legacy crap" / "yeah yeah")
>> and then realized they want to drive modems ("oh crap, it seemed
>> like a good idea at the time"). Then they usually take
>> two GPIO pins for CTS/RTS and drive them as GPIOs using
>> software and you have a cheap 4-line modem line. This is what
>> drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
>> 
>>> I've tested this set and it seems to work ... except that something
>>> is sadly broken with bluetooth support in 4.1-rc1 so I've only really
>>> tested the GPS driver.  I guess it is time to rebase to -rc3.
>> 
>> You have a hardware taget I see. Which one?
> 
> GTA04 (www.gta04.org - openmoko successor).
> 
> 3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
> half of a wifi/bluetooth module, and one to a GPS.
> 
> For the GPS, I just want to power on/off when the TTY is opened/closed,
> but the power-on sequence is non-trivial as both "turn on" and
> "turn-off' toggle the same line, so I need to be able to detect current
> state.
> 
> For the bluetooth, the power is a (shared) regulator.  As well as
> power-on when the TTY is opened, I'd like regulator to be turned of
> when I "hciconfig down" - even though the TTY is still open.
> I did a patch a while ago which hooked in to hci_uart_{open,close} to
> make this work, but it isn't a really good patch.
> 
> It would be nice to hide the TTY from user-space in the bluetooth case,
> and have the "hciattach" happen in the kernel, but I think hciattach
> does extra initialisation...
> 
> NeilBrown


we (the developers of the hardware) have proposed an alternative
approach to Neil’s implementation - for the same device and solving
the same problem (notifying tty open/close and uart activity to the
slave device driver), but differently.

See:
https://lkml.org/lkml/2015/6/28/91

Discussion has not yet settled on which approach is better. So your
opinion of comparing both is welcome.

BR,
Nikolaus


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dr. H. Nikolaus Schaller]

Hi Linus,

Am 12.08.2015 um 01:20 schrieb NeilBrown n...@brown.name:

 On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
 linus.wall...@linaro.org wrote:
 
 Hi Neil,
 
 first, this is a *VERY* interesting and much needed patch series,
 I intend to look closer at it, and if possible test it with some
 (heh) board file device. Would be happy of you put me on CC for these.
 
 On Mon, May 11, 2015 at 3:56 AM, NeilBrown n...@brown.name wrote:
 
 When a device is connected to a UART via RS-232 (or similar), there
 is a DTR line that can be used for power management, and other modem
 control lines.
 
 On an embedded board, it is very likely that there is no DTR, and
 any power management need to be done using some completely separate
 mechanism.
 
 So these slaves are really just for devices permanently attached to
 UARTs without a full RS-232 (or similar) connection.  The driver
 does all the extra control beyond Tx/Rx.
 
 What is usually happening (and I have seen it in a few places) is that
 the SoC has *one* fully featured RS232 with CTS/RTS and even
 DTS,DCD,RI and other esoterica, which is intended to be connected to a
 host serial port or so, for example if this SoC is to act as a modem
 or a fax machine, or if it is to drive one.
 
 Then they often have a few more UART blocks, usually identical, which
 only have RxD+TxD available, so they are just UARTs.
 
 To complicate things further, you may wonder what happened with
 the CTS/RTS (etc) signals from the other blocks. Usually they are there
 in the silicon but just routed to dead ends.
 
 To complicate it even further, usually all these pins are placed under
 pin control multiplexing, so in an actual electronic design, the
 system will mux out CTS/RTS (etc) from the fully featured RS232
 blocks and only use them as UARTs anyways.
 
 Then there are those who created real simple RxD/TxD-only UARTs
 (yeah lets dump this RS232 legacy crap / yeah yeah)
 and then realized they want to drive modems (oh crap, it seemed
 like a good idea at the time). Then they usually take
 two GPIO pins for CTS/RTS and drive them as GPIOs using
 software and you have a cheap 4-line modem line. This is what
 drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
 
 I've tested this set and it seems to work ... except that something
 is sadly broken with bluetooth support in 4.1-rc1 so I've only really
 tested the GPS driver.  I guess it is time to rebase to -rc3.
 
 You have a hardware taget I see. Which one?
 
 GTA04 (www.gta04.org - openmoko successor).
 
 3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
 half of a wifi/bluetooth module, and one to a GPS.
 
 For the GPS, I just want to power on/off when the TTY is opened/closed,
 but the power-on sequence is non-trivial as both turn on and
 turn-off' toggle the same line, so I need to be able to detect current
 state.
 
 For the bluetooth, the power is a (shared) regulator.  As well as
 power-on when the TTY is opened, I'd like regulator to be turned of
 when I hciconfig down - even though the TTY is still open.
 I did a patch a while ago which hooked in to hci_uart_{open,close} to
 make this work, but it isn't a really good patch.
 
 It would be nice to hide the TTY from user-space in the bluetooth case,
 and have the hciattach happen in the kernel, but I think hciattach
 does extra initialisation...
 
 NeilBrown


we (the developers of the hardware) have proposed an alternative
approach to Neil’s implementation - for the same device and solving
the same problem (notifying tty open/close and uart activity to the
slave device driver), but differently.

See:
https://lkml.org/lkml/2015/6/28/91

Discussion has not yet settled on which approach is better. So your
opinion of comparing both is welcome.

BR,
Nikolaus


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/