linux-kernel - Re: [PATCH] HID: intel-ish-hid: ISH firmware loader client driver

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: <CAHX4x86DKshGWj8D4nYje3fUvETG14jD4jNt+VgpejmzU2Dnog@mail.gmail.com>
Date:   Wed, 27 Mar 2019 10:01:49 -0600
From:   Nick Crews <ncrews@...omium.org>
To:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc:     Rushikesh S Kadam <rushikesh.s.kadam@...el.com>,
        benjamin.tissoires@...hat.com, jikos@...nel.org,
        jettrink@...omium.org, gwendal@...gle.com,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-input@...r.kernel.org
Subject: Re: [PATCH] HID: intel-ish-hid: ISH firmware loader client driver

On Tue, Mar 26, 2019 at 8:22 PM Srinivas Pandruvada
<srinivas.pandruvada@...ux.intel.com> wrote:
>
> On Tue, 2019-03-26 at 18:39 -0600, Nick Crews wrote:
> > Hi Rushikesh, I know I've been reviewing this on Chromium, but I have
> > some more larges-scale design thoughts.
> Hi Nick.
>
> Does this fundamentally change, the way it is done here or can wait for
> subsequent revisions later?

I don't have any official stakes in this, as I'm not the maintainer or
anything, so
I'm just preaching what I think would be good design :)

I think I would like to see most of my suggestions addressed. At the
very least there
are some actual bugs (infinite loops, accessing bad memory, not
reporting all errors)
 that need to get fixed. Of course I'm not the one that has to write
or test it, but I imagine
that the one large design change I proposed of where memory is
allocated shouldn't be too
hard either. I worry that "subsequent revisions" to upstream won't
happen, since it's hard enough
to get a patch accepted. Maybe that concern isn't warranted though, I
don't have that
much experience on the LKML.

Is there a really tight deadline for this? If so then I would say we
should apply what
we currently have to the Chromium tree, and upstream the final version
when it's done.

Thanks,
Nick

>
> Thanks,
> Srinivas
>