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-next>] [day] [month] [year] [list]
Date:   Tue, 10 Mar 2020 10:40:16 +0100
From:   Matthias Brugger <mbrugger@...e.com>
To:     Stephen Boyd <sboyd@...nel.org>,
        Enric Balletbo Serra <eballetbo@...il.com>
Cc:     Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        David Airlie <airlied@...ux.ie>, CK HU <ck.hu@...iatek.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Mark Rutland <mark.rutland@....com>,
        Michael Turquette <mturquette@...libre.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        ulrich.hecht+renesas@...il.com,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Andrew-CT Chen <andrew-ct.chen@...iatek.com>,
        Minghsiu Tsai <minghsiu.tsai@...iatek.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Richard Fontana <rfontana@...hat.com>,
        Collabora Kernel ML <kernel@...labora.com>,
        linux-clk@...r.kernel.org, Weiyi Lu <weiyi.lu@...iatek.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        mtk01761 <wendell.lin@...iatek.com>, linux-media@...r.kernel.org,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        frank-w@...lic-files.de, Seiya Wang <seiya.wang@...iatek.com>,
        sean.wang@...iatek.com, Houlong Wei <"houlong.w ei"@mediatek.com>,
        ARM/Mediatek SoC support <linux-mediatek@...ts.infradead.org>,
        Hsin-Yi Wang <hsinyi@...omium.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Allison Randal <allison@...utok.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        fwll.ch@...edesktop.org, matthias.bgg@...nel.org
Subject: Re: [PATCH v11 3/5] soc: mediatek: Move mt8173 MMSYS to platform
 driver



On 09/03/2020 23:50, Stephen Boyd wrote:
> Quoting Enric Balletbo Serra (2020-03-06 14:09:50)
>> Missatge de Stephen Boyd <sboyd@...nel.org> del dia dv., 6 de mar
>> 2020 a les 22:37:
>>>
>>> Quoting Enric Balletbo i Serra (2020-03-06 08:30:16)
>>>> On 5/3/20 22:01, Stephen Boyd wrote:
>>>>> Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
>>>>>> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
>>>>>> new file mode 100644
>>>>>> index 000000000000..473cdf732fb5
>>>>>> --- /dev/null
>>>>>> +++ b/drivers/soc/mediatek/mtk-mmsys.c
>>>>>> @@ -0,0 +1,154 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>> +/*
>>>>>> + * Copyright (c) 2014 MediaTek Inc.
>>>>>> + * Author: James Liao <jamesjj.liao@...iatek.com>
>>>>>> + */
>>>>>> +
>>>>>> +#include <linux/clk-provider.h>
>>>>>> +#include <linux/of_device.h>
>>>>>> +#include <linux/platform_device.h>
>>>>>> +
>>>>>> +#include "../../clk/mediatek/clk-gate.h"
>>>>>> +#include "../../clk/mediatek/clk-mtk.h"
>>>>>
>>>>> Why not use include/linux/clk/?
>>>>>
>>>>
>>>> I can move these files to include, this will impact a lot more of drivers but,
>>>> yes, I think is the right way.
>>>>
>>>>> But I also don't understand why the clk driver is moved outside of
>>>>> drivers/clk/ into drivers/soc/. Commit text saying that it has shared
>>>>> registers doesn't mean it can't still keep the clk driver part in the
>>>>> drivers/clk/ area.
>>>>>
>>>>
>>>> Actually moving this to the soc directory has been requested by CK (mediatek) as
>>>> a change in v8. You can see the discussion in [1]
>>>>
>>>
>>> I can reply there in that thread if necessary, but we shouldn't need to
>>> force simple-mfd into DT bindings to support this. Match the compatible
>>> string in drivers/soc/ and register devices in software for the
>>> different pieces of this overall hardware block. If necessary, pass down
>>> the ioremapped addresss down through device data to each logical driver
>>> in the respective subsystem.
>>>
>>> So yes, it looks like an MFD, but that doesn't mean we have to change
>>> the DT binding or put it in drivers/mfd to support that. And we don't
>>> have to fix any problems with allowing two drivers to probe the same
>>> compatible string.
>>>
>>
>> That thread maybe has too much information and things evolved since
>> then. Note that the final solution is not an MFD neither we change the
>> bindings. I pointed to that thread just because CK (CK please correct
>> me if I'm wrong) thought that the driver is not a pure clock driver
>> and he preferred to move to drivers/soc/mediatek (in that thread, he
>> exposes his opinion on that).  Sorry to introduce more confusion.
>>
>> You seem to be fine with the approach (just minor changes), so it
>> looks to me that the only problem is if this should be in drivers/clk
>> or drivers/soc. Honestly, this is not something I can't decide and
>> I'll let you (the soc and clk maintainers) decide. I don't really have
>> a strong opinion here. I don't mind move again to drivers/clk if that
>> is what we want but let's come to an agreement.
>>
> 
> It's already in drivers/clk, so leave the clk part there and register
> the clk device and any other devices by matching the compatible in
> drivers/soc. That is my preferred solution. Can that be done?
> 

I think we can once again create a platform device in drivers/soc which matches
the drivers/clk and then do the routing in drivers/soc. Enric any thoughts?

Powered by blists - more mailing lists