All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To: Dmitry Osipenko <digetx@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Philipp Zabel <p.zabel@pengutronix.de>
Cc: Jon Hunter <jonathanh@nvidia.com>,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] memory: tegra: Add missing dependencies
Date: Thu, 10 Jun 2021 08:43:48 +0200	[thread overview]
Message-ID: <1400979c-c7a7-9618-1168-70185ed10546@canonical.com> (raw)
In-Reply-To: <a3110fbd-c4af-0317-5a6d-1f780f1dac91@gmail.com>

On 09/06/2021 18:57, Dmitry Osipenko wrote:
> 09.06.2021 16:19, Krzysztof Kozlowski пишет:
>> On 09/06/2021 13:58, Dmitry Osipenko wrote:
>>> 09.06.2021 14:28, Thierry Reding пишет:
>>>> From: Thierry Reding <treding@nvidia.com>
>>>>
>>>> When enabling the COMPILE_TEST Kconfig option, the Tegra memory
>>>> controller can be built without ARCH_TEGRA being selected. However, the
>>>> driver implicitly depends on some symbols pulled in via ARCH_TEGRA,
>>>> which causes the build to break.
>>>>
>>>> Add explicit dependencies for OF_EARLY_FLATTREE and OF_RESERVED_MEM to
>>>> the Tegra MC Kconfig option to make sure they are selected even if
>>>> ARCH_TEGRA is not.
>>>>
>>>> Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
>>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>>> ---
>>>>  drivers/memory/tegra/Kconfig | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
>>>> index f9bae36c03a3..ecfb071fc4f4 100644
>>>> --- a/drivers/memory/tegra/Kconfig
>>>> +++ b/drivers/memory/tegra/Kconfig
>>>> @@ -48,6 +48,8 @@ config TEGRA124_EMC
>>>>  config TEGRA210_EMC_TABLE
>>>>  	bool
>>>>  	depends on ARCH_TEGRA_210_SOC || COMPILE_TEST
>>>> +	select OF_EARLY_FLATTREE
>>>> +	select OF_RESERVED_MEM
>>>>  
>>>>  config TEGRA210_EMC
>>>>  	tristate "NVIDIA Tegra210 External Memory Controller driver"
>>>>
>>>
>>> Will this work if CONFIG_OF is disabled?
>>
>> Yeah, good question. That's why I propose "depends on". No issues with
>> unmet or circular dependencies.
> 
> What about to add stub for RESERVEDMEM_OF_DECLARE() + CONFIG_OF_RESERVED_MEM=n?
> 
> diff --git a/include/linux/of.h b/include/linux/of.h
> index d8db8d3592fd..9c2e71e202d1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -1329,6 +1329,12 @@ static inline int of_get_available_child_count(const struct device_node *np)
>  	return num;
>  }
>  
> +#define _OF_DECLARE_STUB(table, name, compat, fn, fn_type)		\
> +	static const struct of_device_id __of_table_##name		\
> +		__attribute__((unused))					\
> +		 = { .compatible = compat,				\
> +		     .data = (fn == (fn_type)NULL) ? fn : fn }
> +
>  #if defined(CONFIG_OF) && !defined(MODULE)
>  #define _OF_DECLARE(table, name, compat, fn, fn_type)			\
>  	static const struct of_device_id __of_table_##name		\
> @@ -1338,10 +1344,7 @@ static inline int of_get_available_child_count(const struct device_node *np)
>  		     .data = (fn == (fn_type)NULL) ? fn : fn  }
>  #else
>  #define _OF_DECLARE(table, name, compat, fn, fn_type)			\
> -	static const struct of_device_id __of_table_##name		\
> -		__attribute__((unused))					\
> -		 = { .compatible = compat,				\
> -		     .data = (fn == (fn_type)NULL) ? fn : fn }
> +	_OF_DECLARE_STUB(table, name, compat, fn, fn_type)
>  #endif
>  
>  typedef int (*of_init_fn_2)(struct device_node *, struct device_node *);
> diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
> index 76e4a0fffba4..4de2a24cadc9 100644
> --- a/include/linux/of_reserved_mem.h
> +++ b/include/linux/of_reserved_mem.h
> @@ -27,11 +27,11 @@ struct reserved_mem_ops {
>  
>  typedef int (*reservedmem_of_init_fn)(struct reserved_mem *rmem);
>  
> +#ifdef CONFIG_OF_RESERVED_MEM
> +
>  #define RESERVEDMEM_OF_DECLARE(name, compat, init)			\
>  	_OF_DECLARE(reservedmem, name, compat, init, reservedmem_of_init_fn)
>  
> -#ifdef CONFIG_OF_RESERVED_MEM
> -
>  int of_reserved_mem_device_init_by_idx(struct device *dev,
>  				       struct device_node *np, int idx);
>  int of_reserved_mem_device_init_by_name(struct device *dev,
> @@ -41,6 +41,10 @@ void of_reserved_mem_device_release(struct device *dev);
>  
>  struct reserved_mem *of_reserved_mem_lookup(struct device_node *np);
>  #else
> +
> +#define RESERVEDMEM_OF_DECLARE(name, compat, init)			\
> +	_OF_DECLARE_STUB(reservedmem, name, compat, init, reservedmem_of_init_fn)
> +
>  static inline int of_reserved_mem_device_init_by_idx(struct device *dev,
>  					struct device_node *np, int idx)
>  {

The stubs might be good idea anyway, but the driver explicitly needs for
runtime working reservedmem, so it should select it.

Best regards,
Krzysztof

  reply	other threads:[~2021-06-10  6:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09 11:28 [PATCH 0/2] memory: tegra: Fixes for COMPILE_TEST Thierry Reding
2021-06-09 11:28 ` [PATCH 1/2] memory: tegra: Add missing dependencies Thierry Reding
2021-06-09 11:58   ` Dmitry Osipenko
2021-06-09 13:19     ` Krzysztof Kozlowski
2021-06-09 16:57       ` Dmitry Osipenko
2021-06-10  6:43         ` Krzysztof Kozlowski [this message]
2021-06-10 15:50           ` Dmitry Osipenko
2021-06-10 16:23             ` Dmitry Osipenko
2021-06-11  6:50               ` Krzysztof Kozlowski
2021-06-11  7:21                 ` Dmitry Osipenko
2021-06-11 11:00                   ` Thierry Reding
2021-06-11 13:40                     ` Dmitry Osipenko
2021-06-14 11:50                       ` Krzysztof Kozlowski
2021-06-14 14:16                         ` Dmitry Osipenko
2021-06-09 17:00       ` Thierry Reding
2021-06-10  6:42         ` Krzysztof Kozlowski
2021-06-17  0:35   ` kernel test robot
2021-06-17  0:35     ` kernel test robot
2021-06-09 11:28 ` [PATCH 2/2] reset: Add compile-test stubs Thierry Reding
2021-06-09 11:47   ` Philipp Zabel

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=1400979c-c7a7-9618-1168-70185ed10546@canonical.com \
    --to=krzysztof.kozlowski@canonical.com \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=thierry.reding@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.