linux-kernel - Re: [PATCH 2/4] Bluetooth: btmtksdio: handle runtime pm only when sdio

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

Date:   Thu, 25 Nov 2021 16:22:03 +0800
From:   <sean.wang@...iatek.com>
To:     <marcel@...tmann.org>, <johan.hedberg@...il.com>
CC:     <Mark-YW.Chen@...iatek.com>, <sean.wang@...iatek.com>,
        <Soul.Huang@...iatek.com>, <YN.Chen@...iatek.com>,
        <Leon.Yen@...iatek.com>, <Eric-SY.Chang@...iatek.com>,
        <Deren.Wu@...iatek.com>, <km.lin@...iatek.com>,
        <robin.chiu@...iatek.com>, <Eddie.Chen@...iatek.com>,
        <ch.yeh@...iatek.com>, <posh.sun@...iatek.com>,
        <ted.huang@...iatek.com>, <Eric.Liang@...iatek.com>,
        <Stella.Chang@...iatek.com>, <Tom.Chou@...iatek.com>,
        <steve.lee@...iatek.com>, <jsiuda@...gle.com>,
        <frankgor@...gle.com>, <jemele@...gle.com>,
        <abhishekpandit@...gle.com>, <michaelfsun@...gle.com>,
        <mcchou@...omium.org>, <shawnku@...gle.com>,
        <linux-bluetooth@...r.kernel.org>,
        <linux-mediatek@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] Bluetooth: btmtksdio: handle runtime pm only when sdio_func is available

From: Sean Wang <sean.wang@...iatek.com>

>>Hi Sean,
>
>> Runtime pm ops is not aware the sdio_func status that is probably
>> being disabled by btmtksdio_close. Thus, we are only able to access
>> the sdio_func for the runtime pm operations only when the sdio_func is
>> available.
>>
>> Fixes: 7f3c563c575e7 ("Bluetooth: btmtksdio: Add runtime PM support to
>> SDIO based Bluetooth")
>> Co-developed-by: Mark-yw Chen <mark-yw.chen@...iatek.com>
>> Signed-off-by: Mark-yw Chen <mark-yw.chen@...iatek.com>
>> Signed-off-by: Sean Wang <sean.wang@...iatek.com>
>> ---
>> drivers/bluetooth/btmtksdio.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/bluetooth/btmtksdio.c
>> b/drivers/bluetooth/btmtksdio.c index 4f3412ad8fca..4c46c62e4623
>> 100644
>> --- a/drivers/bluetooth/btmtksdio.c
>> +++ b/drivers/bluetooth/btmtksdio.c
>> @@ -1037,6 +1037,9 @@ static int btmtksdio_runtime_suspend(struct device *dev)
>>	if (!bdev)
>>		return 0;
>>
>> +	if (!test_bit(HCI_RUNNING, &bdev->hdev->flags))
>> +		return 0;
>> +
>>	sdio_claim_host(bdev->func);
>>
>>	sdio_writel(bdev->func, C_FW_OWN_REQ_SET, MTK_REG_CHLPCR, &err); @@
>> -1064,6 +1067,9 @@ static int btmtksdio_runtime_resume(struct device *dev)
>>	if (!bdev)
>>		return 0;
>>
>> +	if (!test_bit(HCI_RUNNING, &bdev->hdev->flags))
>> +		return 0;
>> +
>>	sdio_claim_host(bdev->func);
>>
>>	sdio_writel(bdev->func, C_FW_OWN_REQ_CLR, MTK_REG_CHLPCR, &err);
>
>I dislike looking at HCI_RUNNING since that check should be removed from a driver. Do you really need it? I mean, a driver should now if it is running or not.

We don't really need it, instead we can use internal flags in the driver to know the status. I will do this in v2.

	Sean
>
>Regards
>
>Marcel
>