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: <Ys71dyMdozGUAto0@smile.fi.intel.com>
Date:   Wed, 13 Jul 2022 19:40:23 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Henning Schild <henning.schild@...mens.com>
Cc:     Lee Jones <lee.jones@...aro.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Tony Luck <tony.luck@...el.com>, Wolfram Sang <wsa@...nel.org>,
        Jean Delvare <jdelvare@...e.de>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Jonathan Yong <jonathan.yong@...el.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-edac@...r.kernel.org, linux-i2c <linux-i2c@...r.kernel.org>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        LINUXWATCHDOG <linux-watchdog@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        James Morse <james.morse@....com>,
        Robert Richter <rric@...nel.org>,
        Jean Delvare <jdelvare@...e.com>, Pavel Machek <pavel@....cz>,
        Peter Tyser <ptyser@...-inc.com>,
        Andy Shevchenko <andy@...nel.org>,
        Mark Gross <markgross@...nel.org>
Subject: Re: [PATCH v6 00/12] platform/x86: introduce p2sb_bar() helper

On Wed, Jun 29, 2022 at 07:14:06PM +0200, Henning Schild wrote:
> Am Wed, 29 Jun 2022 19:39:58 +0300
> schrieb Andy Shevchenko <andriy.shevchenko@...ux.intel.com>:
> 
> > +Cc: Rafael
> > 
> > On Tue, Jun 21, 2022 at 02:58:16PM +0300, Andy Shevchenko wrote:
> > > On Wed, Jun 08, 2022 at 12:50:44PM +0200, Andy Shevchenko wrote:  
> > > > On Wed, Jun 8, 2022 at 9:42 AM Lee Jones <lee.jones@...aro.org>
> > > > wrote:  
> > > > > On Mon, 06 Jun 2022, Andy Shevchenko wrote:
> > > > >  
> > > > > > There are a few users that would like to utilize P2SB
> > > > > > mechanism of hiding and unhiding a device from the PCI
> > > > > > configuration space.
> > > > > >
> > > > > > Here is the series to consolidate p2sb handling code for
> > > > > > existing users and to provide a generic way for new comer(s).
> > > > > >
> > > > > > It also includes a patch to enable GPIO controllers on Apollo
> > > > > > Lake when it's used with ABL bootloader w/o ACPI support.
> > > > > >
> > > > > > The patch that brings the helper ("platform/x86/intel: Add
> > > > > > Primary to Sideband (P2SB) bridge support") has a commit
> > > > > > message that sheds a light on what the P2SB is and why this
> > > > > > is needed.
> > > > > >
> > > > > > I have tested this on Apollo Lake platform (I'm able to see
> > > > > > SPI NOR and since we have an ACPI device for GPIO I do not
> > > > > > see any attempts to recreate one).
> > > > > >
> > > > > > The series is ready to be merged via MFD tree, but see below.
> > > > > >
> > > > > > The series also includes updates for Simatic IPC drivers that
> > > > > > partially tagged by respective maintainers (the main question
> > > > > > is if Pavel is okay with the last three patches, since I
> > > > > > believe Hans is okay with removing some code under PDx86).
> > > > > > Hence the first 8 patches can be merged right away and the
> > > > > > rest when Pavel does his review.  
> > > > >
> > > > > Can we just wait for Pavel's review, then merge them all at
> > > > > once?  
> > > > 
> > > > Sure, it would be the best course of action.  
> > > 
> > > Pavel, do you have a chance to review the patches (last three) that
> > > touch LED drivers? What would be your verdict?  
> > 
> > Lee, Rafael,
> > 
> > It seems quite hard to get Pavel's attention to this series [1]. It's
> > already passed more than 3 weeks for any sign of review of three top
> > patches of the series that touched LED subsystem. The entire series
> > has all necessary tags, but for LED changes.
> > 
> > Note, that the top of this series is not done by me and was sent for
> > preliminary review much earlier [2], altogether it makes months of no
> > response from the maintainer.
> > 
> > The nature of patches is pretty simple and doesn't touch any of other
> > than Simatic LED drivers nor LED core. Moreover, it was written by
> > Siemens, who produces the H/W in question and very well tested as a
> > separate change and as part of the series.
> 
> The code has been reviewed and is in fact pretty simple. The only
> questionable but pragmatic change that might catch the attention of a
> pedantic reviewer is that i did put the gpio implementation of the
> driver under the same/existing kernel config switch.
> 
> > I think to move forward we may ask Rafael to review it on behalf of
> > good maintainer and with his approval apply entire series.
> > 
> > Thoughts?
> 
> Thanks for pushing this Andy. I was wondering how and when that story
> would continue. Technically these changes should really go in one badge
> or we need to find a way to separate them somehow. I would try to go
> that extra mile to get out of your way. But i am kind of afraid such an
> effort might also end up touching the same files and block us at the
> same maintainer.
> 
> Did anyone check whether Pavel was active at all in those last months
> and maybe other patches waiting for review? Hope he is fine and active
> and just somehow forgot/overlooked/ignored this one.

I have send a private mail to Pavel and have got no response.
Can we move this forward, let's say, by applying first 8 patches?

> > [1]:
> > https://lore.kernel.org/all/20220606164138.66535-1-andriy.shevchenko@linux.intel.com/
> > [2]:
> > https://lore.kernel.org/linux-leds/20220513083652.974-1-henning.schild@siemens.com/
> 

-- 
With Best Regards,
Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ