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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 Sep 2019 09:35:00 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Sakari Ailus <sakari.ailus@....fi>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        linux-media@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.3 084/203] media: omap3isp: Don't set streaming
 state on random subdevs

On Mon, Sep 23, 2019 at 10:25:03AM +0300, Laurent Pinchart wrote:
>On Mon, Sep 23, 2019 at 10:19:42AM +0300, Sakari Ailus wrote:
>> Hi Sasha,
>>
>> On Sun, Sep 22, 2019 at 02:41:50PM -0400, Sasha Levin wrote:
>> > From: Sakari Ailus <sakari.ailus@...ux.intel.com>
>> >
>> > [ Upstream commit 7ef57be07ac146e70535747797ef4aee0f06e9f9 ]
>> >
>> > The streaming state should be set to the first upstream sub-device only,
>> > not everywhere, for a sub-device driver itself knows how to best control
>> > the streaming state of its own upstream sub-devices.
>> >
>> > Signed-off-by: Sakari Ailus <sakari.ailus@...ux.intel.com>
>> > Reviewed-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
>> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
>> > Signed-off-by: Sasha Levin <sashal@...nel.org>
>>
>> I don't disagree with this going to the stable trees as well, but in that
>> case it *must* be accompanied by commit e9eb103f0277 ("media: omap3isp: Set
>> device on omap3isp subdevs") or the driver will mostly cease to work.
>>
>> Could you pick that up as well?
>
>While I don't disagree either, I also think there's no requirement to
>get this commit backported to stable branches. It seems to be the result
>of a too aggressive auto-selection.

I'd very much agree that AUTOSEL is trying to be aggressive with it's
patch selection (it's actually sort of like a "dial" I can adjust and
now it's adjusted pretty high).

However, please don't see it as something that is forced on you; if the
maintainers disagree with patch selection please just let me know and it
will dropped. The only reason I'm being aggressive with AUTOSEL is that
I'm hopefull it will provide better experience for our users.

--
Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ