lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYrF9O+nJZkH+EVP=3gvdKBrnf11gTVh-xzKjPFk1EHfg@mail.gmail.com>
Date:   Sun, 20 Nov 2022 23:33:41 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Dipen Patel <dipenp@...dia.com>
Cc:     "N, Pandith" <pandith.n@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Hall, Christopher S" <christopher.s.hall@...el.com>,
        "Gross, Mark" <mark.gross@...el.com>,
        "Sangannavar, Mallikarjunappa" 
        <mallikarjunappa.sangannavar@...el.com>,
        "D, Lakshmi Sowjanya" <lakshmi.sowjanya.d@...el.com>,
        "T R, Thejesh Reddy" <thejesh.reddy.t.r@...el.com>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>, timestamp@...ts.linux.dev
Subject: Re: Intel timed i/o driver in HTE

On Sat, Nov 19, 2022 at 3:33 AM Dipen Patel <dipenp@...dia.com> wrote:
> On 11/17/22 10:47 AM, N, Pandith wrote:

> > To support Intel timed i/o driver, it was suggested by Linux community to enhance hte framework.
> > However, we see some limitations to support complete Intel timed i/o device.
(...)
> >       b. Timed output  - single shot or periodic pulse train.
> >       Uses TSC(Timestamp counter) for timestamp or generate events, which could be translated to system time.
(...)
> For 1b, the timestamp part can be added as hte provider. I see opportunity to enhance hte framework to provide
> translation facility between the domain, system time in this case. However programming interface to facilitate
> timed IO output can not fit into HTE the way it is right now. May be one possible way is to enchance HTE with API something like
> hte_configure_timestamp_periodic/timed could be possible in which case HTE does something more than just timestamping the event.
>
> I have to see how in GPIO case that proposed API works out, if it will bypass gpio framework etc...
>
> Adding Linus W into the discussion....

I think I already answered with some open ended questions in discussion
with Christopher S. Hall:
https://lore.kernel.org/linux-iio/CACRpkdbeQ_67V3jkw_-KfTwe54TxrK_LA7N8Nwj1qEpTELN9dQ@mail.gmail.com/
https://lore.kernel.org/linux-iio/CACRpkda63TNWLdTjY+_xxXb4df4qCZi1EaXL3pXK=+Hon-0RLQ@mail.gmail.com/
https://lore.kernel.org/linux-iio/CACRpkdYxverx-KsG9URrh5qkEFXDknZKCE6RM555mjOuC--vMg@mail.gmail.com/

I think Intel is in a bit of uncomfortable design space with this thing that
isn't fitting properly anywhere. Dunno what to do about that :/

One thing I didn't get a clear answer for is what kind of use cases the
timed GPIO is for. I was suspecting things like stepper motors. I was
suspecting at one point some kind of sync pulse to something. But
no clear answer.

It is useful to know the usecase to be able to figure out the appropriate
subsystem. It might be that GPIO with some custom ioctl()s for
the gpiodev is the right answer to some of the question, as outlined
above.

and I see Dipen has some answers:

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ