linux-kernel - Re: [PATCH 6/7] tty: serial: samsung

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: <46109820-904b-4e87-5134-7d045dbbe57e@marcan.st>
Date:   Mon, 11 Oct 2021 14:32:29 +0900
From:   Hector Martin <marcan@...can.st>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     Marc Zyngier <maz@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        Arnd Bergmann <arnd@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mark Kettenis <mark.kettenis@...all.nl>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        devicetree@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
        linux-serial@...r.kernel.org
Subject: Re: [PATCH 6/7] tty: serial: samsung_tty: Support runtime PM

On 06/10/2021 16.43, Krzysztof Kozlowski wrote:
> On 05/10/2021 17:59, Hector Martin wrote:
>> +	pm_runtime_get_noresume(&pdev->dev);
>> +	pm_runtime_set_active(&pdev->dev);
>> +	pm_runtime_enable(&pdev->dev);
>> +
> 
> You need to cleanup in error paths (put/disable).

There are none though, this function always returns success past this point.

>>   	if (port) {
>> +		pm_runtime_get_sync(&dev->dev);
> 
> 1. You need to check return status.
> 2. Why do you need to resume the device here?

As Rafael mentioned, this is basically disabling PM so the device is 
enabled when not bound (which seems to be expected behavior). Not sure 
what I'd do if the resume fails... this is the remove path after all, 
it's not like we're doing anything else with the device at this point.

>> +
>>   		s3c24xx_serial_cpufreq_deregister(to_ourport(port));
>>   		uart_remove_one_port(&s3c24xx_uart_drv, port);
>> +
>> +		pm_runtime_disable(&dev->dev);
> 
> Why disabling it only if port!=NULL? Can remove() be called if
> platform_set_drvdata() was not?

Good question, I'm not entirely sure why these code paths have a check 
for NULL there. They were already there, do you happen to know why? To 
me it sounds like remove would only be called if probe succeeds, at 
which point drvdata should always be set.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub