Messages in this thread | | | From | Baolin Wang <> | Date | Fri, 24 Apr 2020 16:43:24 +0800 | Subject | Re: [PATCH 1/2] mfd: syscon: Support physical regmap bus |
| |
On Fri, Apr 24, 2020 at 4:42 PM Baolin Wang <baolin.wang7@gmail.com> wrote: > > On Fri, Apr 24, 2020 at 4:32 PM Lee Jones <lee.jones@linaro.org> wrote: > > > > On Fri, 24 Apr 2020, Arnd Bergmann wrote: > > > > > On Fri, Apr 24, 2020 at 10:11 AM Lee Jones <lee.jones@linaro.org> wrote: > > > > On Fri, 17 Apr 2020, Baolin Wang wrote: > > > > > @@ -106,14 +107,25 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_clk) > > > > > syscon_config.val_bits = reg_io_width * 8; > > > > > syscon_config.max_register = resource_size(&res) - reg_io_width; > > > > > > > > > > - regmap = regmap_init_mmio(NULL, base, &syscon_config); > > > > > + /* > > > > > + * The Spreadtrum syscon need register a real physical regmap bus > > > > > + * with new atomic bits updating operation instead of using > > > > > + * read-modify-write. > > > > > + */ > > > > > + if (IS_ENABLED(CONFIG_ARCH_SPRD) && > > > > > + of_device_is_compatible(np, "sprd,atomic-syscon") && > > > > > > > > Please find a more generic way of supporting your use-case. This is a > > > > generic driver, and as such I am vehemently against adding any sort of > > > > vendor specific code in here. > > > > > > I suggested doing it this way, as all alternatives seemed worse than this. > > > > If we're using a registration function (could probably be swapped out > > for or accompanied by a Device Tree property) anyway, then why conduct > > the vendor platform checks? > > Actually I've send out the v3 patch according to Arnd's suggestion. In > v3 patch, I removed the registration function, but we agreed that > adding the vendor specific support in the syscon driver seems a better > way than others.
Sorry, I forgot the link: https://lore.kernel.org/patchwork/patch/1228160/
-- Baolin Wang
| |