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]
Date:   Tue, 19 Sep 2023 09:06:54 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Johan Hovold <johan@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>, agross@...nel.org,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 6.5 30/36] arm64: dts: qcom: sc8280xp-x13s: Add
 camera activity LED

On Tue, Sep 19, 2023 at 08:15:04AM +0200, Johan Hovold wrote:
>On Mon, Sep 18, 2023 at 05:41:38PM -0400, Sasha Levin wrote:
>> On Mon, Sep 11, 2023 at 08:33:02AM +0200, Johan Hovold wrote:
>> >On Fri, Sep 08, 2023 at 03:28:41PM -0400, Sasha Levin wrote:
>> >> From: Konrad Dybcio <konrad.dybcio@...aro.org>
>> >>
>> >> [ Upstream commit 1c63dd1c5fdafa8854526d7d60d2b741c813678d ]
>> >>
>> >> Disappointigly, the camera activity LED is implemented in software.
>> >> Hook it up as a gpio-led and (until we have camera *and* a "camera on"
>> >> LED trigger) configure it as a panic indicator.
>> >>
>> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>> >> Link: https://lore.kernel.org/r/20230805-topic-x13s_cam_led-v1-1-443d752158c4@linaro.org
>> >> Signed-off-by: Bjorn Andersson <andersson@...nel.org>
>> >> Signed-off-by: Sasha Levin <sashal@...nel.org>
>> >
>> >This is a new feature if anything, not a fix. Please drop from all
>> >autosel queues.
>>
>> Not a feature, but hardware enablement.
>
>Call it what you will, but please drop it. Otherwise by that logic you'd
>need to backport all devicetree patches (as well as most driver changes)
>since they ultimately aim at enabling hardware.

Not all, only ones that re-use existing kernel driver but enable it for
new hardware (i.e. adding a new pci-id/usb-id/dts entries).

-- 
Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ