linux-kernel - Re: [PATCH 1/5] soc: mediatek: Add infracfg misc driver support

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: <CAGS+omD-0bPeQqau9mm4pTqOhtPW=ecR5ibB8==pifRMgSKrjg@mail.gmail.com>
Date:	Tue, 19 May 2015 14:54:41 +0800
From:	Daniel Kurtz <djkurtz@...omium.org>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"open list:OPEN FIRMWARE AND..." <devicetree@...r.kernel.org>,
	Kevin Hilman <khilman@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-mediatek@...ts.infradead.org,
	Sasha Hauer <kernel@...gutronix.de>,
	Matthias Brugger <matthias.bgg@...il.com>
Subject: Re: [PATCH 1/5] soc: mediatek: Add infracfg misc driver support

On Mon, May 18, 2015 at 4:16 PM, Sascha Hauer <s.hauer@...gutronix.de> wrote:
> Hi Daniel,
>
> On Fri, May 15, 2015 at 10:17:33PM +0800, Daniel Kurtz wrote:
>> Hi Sascha,
>>
>> On Tue, May 12, 2015 at 3:23 AM, Sascha Hauer <s.hauer@...gutronix.de> wrote:
>> > This adds support for some miscellaneous bits of the infracfg controller.
>> > The mtk_infracfg_set/clear_bus_protection functions are necessary for
>> > the scpsys power domain driver to handle the bus protection bits which
>> > are contained in the infacfg register space.
>> >
>> > Signed-off-by: Sascha Hauer <s.hauer@...gutronix.de>
>> > ---
>> >  drivers/soc/mediatek/Kconfig        |  9 +++++
>> >  drivers/soc/mediatek/Makefile       |  1 +
>> >  drivers/soc/mediatek/mtk-infracfg.c | 80 +++++++++++++++++++++++++++++++++++++
>> >  3 files changed, 90 insertions(+)
>> >  create mode 100644 drivers/soc/mediatek/mtk-infracfg.c
>> >
>> > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
>> > index bcdb22d..6fae66f 100644
>> > --- a/drivers/soc/mediatek/Kconfig
>> > +++ b/drivers/soc/mediatek/Kconfig
>> > @@ -9,3 +9,12 @@ config MTK_PMIC_WRAP
>> >           Say yes here to add support for MediaTek PMIC Wrapper found
>> >           on different MediaTek SoCs. The PMIC wrapper is a proprietary
>> >           hardware to connect the PMIC.
>> > +
>> > +config MTK_INFRACFG
>>
>> nit: Could you alphabetize these config options - so this one before
>> MTK_PMIC_WRAP
>>
>> > +       tristate "MediaTek INFRACFG Support"
>> > +       depends on ARCH_MEDIATEK
>>
>> I've seen several drivers like this now:
>>
>>   depends on ARCH_MEDIATEK || COMPILE_TEST
>>
>>
>> > +       select REGMAP
>> > +       help
>> > +         Say yes here to add support for the MediaTek INFRACFG controller. The
>> > +         INFRACFG controller contains various infrastructure registers not
>> > +         directly associated to any device.
>> > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
>> > index ecaf4de..ce39119 100644
>> > --- a/drivers/soc/mediatek/Makefile
>> > +++ b/drivers/soc/mediatek/Makefile
>> > @@ -1 +1,2 @@
>> >  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
>> > +obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
>>
>> alphabetize here, too.
>>
>> > diff --git a/drivers/soc/mediatek/mtk-infracfg.c b/drivers/soc/mediatek/mtk-infracfg.c
>> > new file mode 100644
>> > index 0000000..b3ebfae
>> > --- /dev/null
>> > +++ b/drivers/soc/mediatek/mtk-infracfg.c
>> > @@ -0,0 +1,80 @@
>> > +#include <linux/regmap.h>
>> > +#include <linux/export.h>
>> > +#include <linux/jiffies.h>
>> > +#include <linux/soc/mediatek/infracfg.h>
>> > +#include <asm/processor.h>
>>
>> and... alphabetize headers here.
>>
>> I'm not sure if people care, but I find it makes it much easier to
>> merge/add things later if these lists are already sorted.
>> Same "please alphabetize" comments for the mtk-scpsys patch, so I
>> won't repeat them.
>>
>> > +
>> > +#define INFRA_TOPAXI_PROTECTEN         0x0220
>> > +#define INFRA_TOPAXI_PROTECTSTA1       0x0228
>> > +
>> > +/**
>> > + * mtk_infracfg_set_bus_protection - enable bus protection
>> > + * @regmap: The infracfg regmap
>> > + * @mask: The mask containing the protection bits to be enabled.
>> > + *
>> > + * This function enables the bus protection bits for disabled power
>> > + * domains so that the system does not hanf when some unit accesses the
>> > + * bus while in power down.
>> > + */
>> > +int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask)
>> > +{
>> > +       unsigned long expired;
>> > +       u32 val;
>> > +       int ret;
>> > +
>> > +       regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
>> > +
>> > +       expired = jiffies + HZ;
>> > +
>> > +       while (1) {
>> > +               ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
>> > +               if (ret)
>> > +                       return ret;
>> > +
>> > +               if ((val & mask) == mask)
>> > +                       break;
>> > +
>> > +               cpu_relax();
>> > +               if (time_after(jiffies, expired))
>> > +                       return -EIO;
>>
>> I think we should check for timeout first, and then cpu_relax() if
>> there is still time left (here and in
>> mtk_infracfg_clear_bus_protection()).  Otherwise we end up doing one
>> final cpu_relax() without rechecking the register we are polling
>> (again, I have the same comment for the timeout loops in mtk-scpsys).
>
> I think cpu_relax() delays execution in the order of microseconds (I
> don't actually know, just a guess), so if the timeout is a second the
> order doesn't really matter. What can happen though is an interrupt
> after the (val & mask) test but before the timeout check. So to be
> truly correct we have to repeat the (val & mask) test after the
> time_after() check. Is that what you want?

I'm not following, why would you need to repeat (val & mask) test
after time_after?
What does an interrupt have to do with it?
Can you show a code snippet with what exactly you are proposing?

-Dan

>> Also, shouldn't we return -ETIMEOUT if we timeout?
>
> I dunno. Probably the operation operation timed out because of an IO
> error. I'll change it to -ETIMEDOUT.
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/