From: Thor Thayer <thor.thayer@linux.intel.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Lee Jones <lee.jones@linaro.org>,
Dinh Nguyen <dinguyen@kernel.org>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Giuseppe Cavallaro <peppe.cavallaro@st.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
Jose Abreu <joabreu@synopsys.com>,
David Miller <davem@davemloft.net>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Olof Johansson <olof@lixom.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Networking <netdev@vger.kernel.org>
Subject: Re: [RESEND 1/4] mfd: altera-sysmgr: Add SOCFPGA System Manager abstraction
Date: Mon, 17 Dec 2018 17:23:48 -0600 [thread overview]
Message-ID: <183b18b9-55f4-55d0-b1f6-674a6df49d1b@linux.intel.com> (raw)
In-Reply-To: <CAK8P3a1+LKakyD_gJTiNqKwNuP2Ptr_Wj4zJXf=+SDHSJHbexA@mail.gmail.com>
Hi Arnd,
On 12/14/18 6:36 AM, Arnd Bergmann wrote:
> On Tue, Nov 13, 2018 at 5:03 PM <thor.thayer@linux.intel.com> wrote:
>>
>> From: Thor Thayer <thor.thayer@linux.intel.com>
>>
>> The SOCFPGA System Manager register block aggregate different
>> peripheral functions into one place.
>> On 32 bit ARM parts, the syscon framework fits this problem well.
>> On 64 bit ARM parts, the System Manager can only be accessed by
>> EL3 secure mode. Since a SMC call to EL3 is required, a new
>> driver using regmaps similar to syscon was created that handles
>> the SMC call.
>> Since regmaps abstract out the underlying register access, the
>> changes to drivers using System Manager are minimal.
>>
>> Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
>> ---
>> Resend - update use_single_rw to use_single_read and
>> use_single_write which was added in 4.20.
>
> Sorry for stepping in late here, I forgot to review it earlier and
> Lee had to remind me to take a look.
>
:) Thank you for the review and comments!
>> +static const struct regmap_config s10_sysmgr_regmap_cfg = {
>> + .name = "s10_sysmgr",
>> + .reg_bits = 32,
>> + .reg_stride = 4,
>> + .val_bits = 32,
>> + .reg_read = s10_protected_reg_read,
>> + .reg_write = s10_protected_reg_write,
>> + .fast_io = true,
>> + .use_single_read = true,
>> + .use_single_write = true,
>> +};
>
> The new regmap seems fine to me, that looks like a good way
> of abstracting the two hardware methods.
>
>> +/**
>> + * socfpga_is_s10
>> + * Determine if running on Stratix10 platform.
>> + * Return: True if running Stratix10, otherwise false.
>> + */
>> +static int socfpga_is_s10(void)
>> +{
>> + return of_machine_is_compatible("altr,socfpga-stratix10");
>> +}
>
> I don't really like the way you are checking for a specific here
> here though, that is something that should only be done in
> an absolute emergency when there is no way of fixing the
> device tree files.
>
> Since this is a new driver for a device that is not used in
> mainline kernels yet (AFAICT), let's fix the binding and add
> a proper detection method here.
>
Thank you. I'm not completely clear on this. Are you saying this
function should test for a new compatible that is assigned to Stratix10
in the binding ("altr,sys-mgr-s10") instead of the machine name?
>> +
>> +/**
>> + * of_sysmgr_register
>> + * Create and register the Altera System Manager regmap.
>> + * Return: Pointer to new sysmgr on success.
>> + * Pointer error on failure.
>> + */
>> +static struct altr_sysmgr *of_sysmgr_register(struct device_node *np)
>> +{
>> + struct altr_sysmgr *sysmgr;
>> + struct regmap *regmap;
>> + u32 reg_io_width;
>> + int ret;
>> + struct regmap_config sysmgr_config = s10_sysmgr_regmap_cfg;
>> + struct resource res;
>> +
>> + if (!of_device_is_compatible(np, "altr,sys-mgr"))
>> + return ERR_PTR(-EINVAL);
>> +
>> + sysmgr = kzalloc(sizeof(*sysmgr), GFP_KERNEL);
>> + if (!sysmgr)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + if (of_address_to_resource(np, 0, &res)) {
>> + ret = -ENOMEM;
>> + goto err_map;
>> + }
>> +
>> + /* Need physical address for SMCC call */
>> + sysmgr->base = (void __iomem *)res.start;
>
> The cast here seems really ugly. Instead of mixinx up
> address spaces, how about adding a resource_size_t
> member in the sysmgr structure?
>
Yes. I will change.
>> + * search for reg-io-width property in DT. If it is not provided,
>> + * default to 4 bytes. regmap_init will return an error if values
>> + * are invalid so there is no need to check them here.
>> + */
>> + ret = of_property_read_u32(np, "reg-io-width", ®_io_width);
>> + if (ret)
>> + reg_io_width = 4;
>
> How likely is it that this would ever not be four bytes? It looks
> like you just copied this from syscon, but it really should not be
> needed.
>
Yes. I will change.
>> +struct regmap *altr_sysmgr_node_to_regmap(struct device_node *np)
>> +{
>> + struct altr_sysmgr *sysmgr = NULL;
>> +
>> + if (!socfpga_is_s10())
>> + return syscon_node_to_regmap(np);
>
> Why do you go through syscon here? Doesn't this add a lot of complexity?
>
> I'd suggest using regmap_init_mmio() directly and open-coding the
> initialization you need as you do for the s10 case.
>
Yes. It is more complex but I was concerned about re-implementing large
parts of syscon for the ARM32 case.
However, re-implementing it will simplify the driver and keep both ARM32
and ARM64 together. Thanks for the suggestion - I will change it.
>> + if (!p_sysmgr)
>> + sysmgr = of_sysmgr_register(np);
>> + else
>> + sysmgr = p_sysmgr;
>> +
>> + if (IS_ERR_OR_NULL(sysmgr))
>> + return ERR_CAST(sysmgr);
>
> Don't use IS_ERR_OR_NULL(), it's just a sign that your API
> is bad. Instead, define the interface either so that you
> always return NULL on error or that you always return an
> PTR_ERR() value on error.
>
OK. I will change this.
>> +struct regmap *altr_sysmgr_regmap_lookup_by_compatible(const char *s)
>> +{
>> + struct device_node *sysmgr_np;
>> + struct regmap *regmap;
>> +
>> + if (!socfpga_is_s10())
>> + return syscon_regmap_lookup_by_compatible(s);
>> +
>> + sysmgr_np = of_find_compatible_node(NULL, NULL, s);
>> + if (!sysmgr_np)
>> + return ERR_PTR(-ENODEV);
>> +
>> + regmap = altr_sysmgr_node_to_regmap(sysmgr_np);
>> + of_node_put(sysmgr_np);
>> +
>> + return regmap;
>> +}
>> +EXPORT_SYMBOL_GPL(altr_sysmgr_regmap_lookup_by_compatible);
>
> That should not be needed, just look it up by phandle and be done
> with it. Again, lookup by compatible should only be needed for
> compatibility with old DTB files, but you should be able to fix the
> binding so you always have a phandle to the correct node here,
> at least for the s10 case.
>
> For the older chips with existing DTs, I guess drivers can fall back to
> the syscon method directly.
>
>> +EXPORT_SYMBOL_GPL(altr_sysmgr_regmap_lookup_by_pdevname);
>
> Same comment.
>
> Arnd
>
Yes. I will make these changes.
Thanks so much for the review!
next prev parent reply other threads:[~2018-12-17 23:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 16:06 [RESEND 0/4] Add SOCFPGA System Manager thor.thayer
2018-11-13 16:06 ` [RESEND 1/4] mfd: altera-sysmgr: Add SOCFPGA System Manager abstraction thor.thayer
2018-12-14 12:36 ` Arnd Bergmann
2018-12-17 23:23 ` Thor Thayer [this message]
2018-12-18 15:24 ` Arnd Bergmann
2018-11-13 16:06 ` [RESEND 2/4] ARM: socfpga_defconfig: Enable CONFIG_MTD_ALTERA_SYSMGR thor.thayer
2018-11-13 16:06 ` [RESEND 3/4] arm64: defconfig: " thor.thayer
2018-11-13 16:06 ` [RESEND 4/4] net: stmmac: socfpga: Convert to shared System Manager driver thor.thayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=183b18b9-55f4-55d0-b1f6-674a6df49d1b@linux.intel.com \
--to=thor.thayer@linux.intel.com \
--cc=alexandre.torgue@st.com \
--cc=arnd@arndb.de \
--cc=bjorn.andersson@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=dinguyen@kernel.org \
--cc=joabreu@synopsys.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mchehab+samsung@kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olof@lixom.net \
--cc=peppe.cavallaro@st.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome