linux-kernel - RE: [PATCH v3 2/2] drivers: misc: adi-axi-tdd: Add TDD engine

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: <BN7PR03MB4545DA4A9404F349170CBA1097D8A@BN7PR03MB4545.namprd03.prod.outlook.com>
Date:   Mon, 23 Oct 2023 13:30:21 +0000
From:   "Balas, Eliza" <Eliza.Balas@...log.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Derek Kiernan <derek.kiernan@....com>,
        Dragan Cvetic <dragan.cvetic@....com>,
        Arnd Bergmann <arnd@...db.de>
Subject: RE: [PATCH v3 2/2] drivers: misc: adi-axi-tdd: Add TDD engine

> -----Original Message-----
> From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Sent: Monday, October 23, 2023 16:00
> To: Balas, Eliza <Eliza.Balas@...log.com>
> Cc: linux-kernel@...r.kernel.org; devicetree@...r.kernel.org; Rob Herring <robh+dt@...nel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@...aro.org>; Conor Dooley <conor+dt@...nel.org>; Derek Kiernan <derek.kiernan@....com>; Dragan
> Cvetic <dragan.cvetic@....com>; Arnd Bergmann <arnd@...db.de>
> Subject: Re: [PATCH v3 2/2] drivers: misc: adi-axi-tdd: Add TDD engine
> 
> [External]
> 
> On Mon, Oct 23, 2023 at 12:54:15PM +0000, Balas, Eliza wrote:
> > > -----Original Message-----
> > > From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > Sent: Friday, October 20, 2023 17:32
> > > To: Balas, Eliza <Eliza.Balas@...log.com>
> > > Cc: linux-kernel@...r.kernel.org; devicetree@...r.kernel.org; Rob Herring <robh+dt@...nel.org>; Krzysztof Kozlowski
> > > <krzysztof.kozlowski+dt@...aro.org>; Conor Dooley <conor+dt@...nel.org>; Derek Kiernan <derek.kiernan@....com>; Dragan
> > > Cvetic <dragan.cvetic@....com>; Arnd Bergmann <arnd@...db.de>
> > > Subject: Re: [PATCH v3 2/2] drivers: misc: adi-axi-tdd: Add TDD engine
> > >
> > > [External]
> > >
> > > On Fri, Oct 20, 2023 at 11:18:44AM +0000, Balas, Eliza wrote:
> > > > > > +static int adi_axi_tdd_parse_ms(struct adi_axi_tdd_state *st,
> > > > > > +				const char *buf,
> > > > > > +				u64 *res)
> > > > > > +{
> > > > > > +	u64 clk_rate = READ_ONCE(st->clk.rate);
> > > > > > +	char *orig_str, *modf_str, *int_part, frac_part[7];
> > > > > > +	long ival, frac;
> > > > > > +	int ret;
> > > > > > +
> > > > > > +	orig_str = kstrdup(buf, GFP_KERNEL);
> > > > > > +	int_part = strsep(&orig_str, ".");
> > > > >
> > > > > Why are we parsing floating point in the kernel?  Please just keep the
> > > > > api simple so that we don't have to try to do any type of parsing other
> > > > > than turning a single text number into a value.
> > > > >
> > > >
> > > > The adi_axi_tdd_parse_ms function does almost the same thing as the
> > > > iio_str_to_fixpoint() function which already exists in kernel.
> > >
> > > That does not mean that this is a valid api for your device as you are
> > > not an iio driver (why aren't you an iio driver?)
> > >
> > > > It parses a fixed-point number from a string.
> > >
> > > And as such, you shouldn't duplicate existing logic.
> > >
> > > > The __iio_str_to_fixpoint is used in a similar way, as I intend to use adi_axi_tdd_parse_ms.
> > > > It writes to a channel the corresponding scale (micro,nano) for a value.
> > >
> > > Why not just have the api accept values in nanoseconds and then no
> > > parsing is needed?
> >
> > I thought this would be easier for the user, to work with smaller values,
> > than using a lot of zeros for nanoseconds. I will make the changes
> > to accept values in nanoseconds..
> 
> Make the kernel simpler, it's easier to make more complex userspace,
> right?
> 
> > > > Since the device is not an iio device, using an iio function would be confusing.
> > >
> > > Why isn't this an iio device?
> >
> > The device is not registered into the IIO device tree,
> > and does not rely on IIO kernel APIs.
> > Even though there are a few attributes that resemble the
> > ones from iio, and the sysfs structure is similar,
> > this is not an IIO device.
> > In the previous patch versions 1 and 2 we concluded
> > that this device fits better in the misc subsystem.
> 
> Ok, can you point to that in the changelog where the IIO maintainer
> agreed that this doesn't fit into that subsystem?
> 
This was one of the discussions from previous v2 : https://lore.kernel.org/all/5b6318f16799e6e2575fe541e83e42e0afebe6cf.camel@gmail.com/

I will add it to the changelog the next time I submit the patches.

Thank you,
Eliza