linux-kernel - Re: [PATCH v14 6/6] soc: mediatek: mutex: add functions that operate registers by CMDQ

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

Message-ID: <20220318083844.24859-1-miles.chen@mediatek.com>
Date:   Fri, 18 Mar 2022 16:38:44 +0800
From:   Miles Chen <miles.chen@...iatek.com>
To:     <moudy.ho@...iatek.com>
CC:     <Project_Global_Chrome_Upstream_Group@...iatek.com>,
        <acourbot@...omium.org>, <allen-kh.cheng@...iatek.com>,
        <angelogioacchino.delregno@...labora.com>,
        <chunkuang.hu@...nel.org>, <daoyuan.huang@...iatek.com>,
        <devicetree@...r.kernel.org>, <drinkcat@...omium.org>,
        <geert+renesas@...der.be>, <hsinyi@...gle.com>,
        <hverkuil-cisco@...all.nl>, <jason-jh.lin@...iatek.com>,
        <jernej.skrabec@...l.net>, <laurent.pinchart@...asonboard.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <linux-media@...r.kernel.org>,
        <linux-mediatek@...ts.infradead.org>, <maoguang.meng@...iatek.com>,
        <matthias.bgg@...il.com>, <mchehab@...nel.org>,
        <menghui.lin@...iatek.com>, <miles.chen@...iatek.com>,
        <pihsun@...omium.org>, <ping-hsun.wu@...iatek.com>,
        <randy.wu@...iatek.com>, <river.cheng@...iatek.com>,
        <rob@...dley.net>, <robh+dt@...nel.org>, <roy-cw.yeh@...iatek.com>,
        <sj.huang@...iatek.com>, <srv_heupstream@...iatek.com>,
        <tfiga@...omium.org>
Subject: Re: [PATCH v14 6/6] soc: mediatek: mutex: add functions that operate registers by CMDQ

Hi Moudy,

>> >  		}
>> >  	}
>> >  
>> > +	if (of_address_to_resource(dev->of_node, 0, &addr) < 0)
>> > +		mtx->addr = 0L;
>> 
>> addr is phys_addr_t, which means that it holds a physical address.
>> 0 may be a valid address in some platforms, so I think
>> we should not set mtx->addr = 0L when of_address_to_resource fails.
>> Maybe probe fail by returning dev_err_probe()?
>> 
>> Thanks,
>> Miles
>
>Hi Miles,
>
>This does lead to the situation you mentioned, and sorry for the
>deficient dts parsing flow. Maybe we should follow "gce-client" usage
>and add a check condition when needed to avoid compatibility issues?
>
>Thanks,
>Moudy

According to Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml,
it is required to have a reg field in the mutex node. So I think we can
fail in this case.

Thanks,
Miles