linux-kernel - Re: [PATCH v4 3/4] media: raspberrypi: Add support for RP1-CFE

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] [day] [month] [year] [list]

Message-ID: <2e9a8d32-1f30-4623-b420-44dfc76c1ef0@ideasonboard.com>
Date: Tue, 10 Sep 2024 13:28:34 +0300
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Jacopo Mondi <jacopo.mondi@...asonboard.com>
Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Raspberry Pi Kernel Maintenance <kernel-list@...pberrypi.com>,
 Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Florian Fainelli <florian.fainelli@...adcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, oe-kbuild-all@...ts.linux.dev,
 linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, Naushir Patuck
 <naush@...pberrypi.com>, Kieran Bingham <kieran.bingham@...asonboard.com>,
 kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v4 3/4] media: raspberrypi: Add support for RP1-CFE



On 10/09/2024 13:18, Jacopo Mondi wrote:
> Hi Tomi
> 
> On Tue, Sep 10, 2024 at 12:56:38PM GMT, Tomi Valkeinen wrote:
>> On 10/09/2024 12:19, Jacopo Mondi wrote:
>>
>>> However, I think this current patch is correct (assuming the above
>>> reasoning on i2c sensor drivers is correct) and doesn't require
>>> CONFIG_PM, so I would be tempted to keep this version.
>>
>> I think the existence of this discussion alone proves my point that we
>> should only support PM-case, unless !PM is a requirement =).
>>
>> But if you do want to keep !PM:
>>
>> Is there a reason why not mark the device as active with
>> pm_runtime_set_active() after calling pispbe_runtime_resume and before
> 
> cargo-cult ?
> 
>> accessing the device? That feels like the most logical way to use the
>> function, and it would be right regardless whether the core will enable the
>> parents before probe() or not.
> 
> Possibly more accurate, but there's no guarantee it's correct. The
> peripheral might have requirements on the clock or power rails
> enablement order and some might be managed by the parent. I know we're
> talking hypothesis but my point is that there's not correctness
> guarantee we can enforce unless the parent is powered up when the
> device probes ?
> 
> Anyway, I'll defer the call to the group: either keep the patch as it
> is right now on the list, or go full runtime_pm. I understand there is
> no reason to care about !CONFIG_PM but somehow I feel "bad" in listing
> it as a dependency if the peripheral can actually work without it.
> Maybe I should just ignore that feeling ?

The runtime PM is just a software construct, so all peripherals can work 
without it.

I decided to ignore the feeling, very much based on this thread, and 
sent CFE v5 with it depending on PM.

  Tomi