Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1524638 > unrolled thread

[PATCH 1/2] of: base: add support to get machine model name

Back to article view | Back to linux.kernel

Contents

  [PATCH 1/2] of: base: add support to get machine model name Sudeep Holla <sudeep.holla@arm.com> - 2016-11-17 19:10 +0100
    Re: [PATCH 1/2] of: base: add support to get machine model name Frank Rowand <frowand.list@gmail.com> - 2016-11-17 22:10 +0100
      Re: [PATCH 1/2] of: base: add support to get machine model name Frank Rowand <frowand.list@gmail.com> - 2016-11-17 23:20 +0100
      Re: [PATCH 1/2] of: base: add support to get machine model name Sudeep Holla <sudeep.holla@arm.com> - 2016-11-18 11:50 +0100
        Re: [PATCH 1/2] of: base: add support to get machine model name Frank Rowand <frowand.list@gmail.com> - 2016-11-18 21:30 +0100
          Re: [PATCH 1/2] of: base: add support to get machine model name Frank Rowand <frowand.list@gmail.com> - 2016-11-21 17:10 +0100
            Re: [PATCH 1/2] of: base: add support to get machine model name Sudeep Holla <sudeep.holla@arm.com> - 2016-11-21 17:30 +0100
              Re: [PATCH 1/2] of: base: add support to get machine model name Frank Rowand <frowand.list@gmail.com> - 2016-11-21 20:30 +0100
                Re: [PATCH 1/2] of: base: add support to get machine model name Frank Rowand <frowand.list@gmail.com> - 2016-11-21 22:00 +0100
          Re: [PATCH 1/2] of: base: add support to get machine model name Sudeep Holla <sudeep.holla@arm.com> - 2016-11-21 17:30 +0100
            Re: [PATCH 1/2] of: base: add support to get machine model name Frank Rowand <frowand.list@gmail.com> - 2016-11-21 21:30 +0100
    Re: [PATCH 1/2] of: base: add support to get machine model name Rob Herring <robh@kernel.org> - 2016-11-18 15:50 +0100
      Re: [PATCH 1/2] of: base: add support to get machine model name Frank Rowand <frowand.list@gmail.com> - 2016-11-18 21:10 +0100
        Re: [PATCH 1/2] of: base: add support to get machine model name Frank Rowand <frowand.list@gmail.com> - 2016-11-22 19:50 +0100
          Re: [PATCH 1/2] of: base: add support to get machine model name Rob Herring <robh@kernel.org> - 2016-11-22 22:40 +0100
            Re: [PATCH 1/2] of: base: add support to get machine model name Sudeep Holla <sudeep.holla@arm.com> - 2016-11-23 11:40 +0100
          Re: [PATCH 1/2] of: base: add support to get machine model name Sudeep Holla <sudeep.holla@arm.com> - 2016-11-23 11:40 +0100

#1524638 — [PATCH 1/2] of: base: add support to get machine model name

Currently platforms/drivers needing to get the machine model name are
replicating the same snippet of code. In some case, the OF reference
counting is either missing or incorrect.

This patch adds support to read the machine model name either using
the "model" or the "compatible" property in the device tree root node
to the core OF/DT code.

This can be used to remove all the duplicate code snippets doing exactly
same thing later.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/of/base.c  | 32 ++++++++++++++++++++++++++++++++
 include/linux/of.h |  6 ++++++
 2 files changed, 38 insertions(+)

Hi Rob,

It would be good if we can target this for v4.10, so that we have no
dependencies to push PATCH 2/2 in v4.11

Regards,
Sudeep

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a0bccb54a9bd..0810c5ecf1aa 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -546,6 +546,38 @@ int of_machine_is_compatible(const char *compat)
 EXPORT_SYMBOL(of_machine_is_compatible);

 /**
+ * of_machine_get_model_name - Find and read the model name or the compatible
+ *		value for the machine.
+ * @model:	pointer to null terminated return string, modified only if
+ *		return value is 0.
+ *
+ * Returns a string containing either the model name or the compatible value
+ * of the machine if found, else return error.
+ *
+ * Search for a machine model name or the compatible if model name is missing
+ * in a device tree node and retrieve a null terminated string value (pointer
+ * to data, not a copy). Returns 0 on success, -EINVAL if root of the device
+ * tree is not found and other error returned by of_property_read_string on
+ * failure.
+ */
+int of_machine_get_model_name(const char **model)
+{
+	int error;
+
+	if (!of_node_get(of_root))
+		return -EINVAL;
+
+	error = of_property_read_string(of_root, "model", model);
+	if (error)
+		error = of_property_read_string_index(of_root, "compatible",
+						      0, model);
+	of_node_put(of_root);
+
+	return error;
+}
+EXPORT_SYMBOL(of_machine_get_model_name);
+
+/**
  *  __of_device_is_available - check if a device is available for use
  *
  *  @device: Node to check for availability, with locks already held
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..13fc66531f1b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -367,6 +367,7 @@ extern int of_alias_get_id(struct device_node *np, const char *stem);
 extern int of_alias_get_highest_id(const char *stem);

 extern int of_machine_is_compatible(const char *compat);
+extern int of_machine_get_model_name(const char **model);

 extern int of_add_property(struct device_node *np, struct property *prop);
 extern int of_remove_property(struct device_node *np, struct property *prop);
@@ -788,6 +789,11 @@ static inline int of_machine_is_compatible(const char *compat)
 	return 0;
 }

+static inline int of_machine_get_model_name(const char **model)
+{
+	return -EINVAL;
+}
+
 static inline bool of_console_check(const struct device_node *dn, const char *name, int index)
 {
 	return false;
--
2.7.4

[toc] | [next] | [standalone]

#1524814

On 11/17/16 07:32, Sudeep Holla wrote:
> Currently platforms/drivers needing to get the machine model name are
> replicating the same snippet of code. In some case, the OF reference
> counting is either missing or incorrect.
> 
> This patch adds support to read the machine model name either using
> the "model" or the "compatible" property in the device tree root node
> to the core OF/DT code.
> 
> This can be used to remove all the duplicate code snippets doing exactly
> same thing later.

I find five instances of reading only property "model":

  arch/arm/mach-imx/cpu.c
  arch/arm/mach-mxs/mach-mxs.c
  arch/c6x/kernel/setup.c
  arch/mips/cavium-octeon/setup.c
  arch/sh/boards/of-generic.c

I find one instance of reading property "model", then if
that does not exist, property "compatible":

  arch/mips/generic/proc.c

The proposed patch matches the code used in one place, and thus
current usage does not match the patch description.

Is my search bad?  Are you planning to add additional instances
of reading "model" then "compatible"?

-Frank

> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/of/base.c  | 32 ++++++++++++++++++++++++++++++++
>  include/linux/of.h |  6 ++++++
>  2 files changed, 38 insertions(+)
> 
> Hi Rob,
> 
> It would be good if we can target this for v4.10, so that we have no
> dependencies to push PATCH 2/2 in v4.11
> 
> Regards,
> Sudeep
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index a0bccb54a9bd..0810c5ecf1aa 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -546,6 +546,38 @@ int of_machine_is_compatible(const char *compat)
>  EXPORT_SYMBOL(of_machine_is_compatible);
> 
>  /**
> + * of_machine_get_model_name - Find and read the model name or the compatible
> + *		value for the machine.
> + * @model:	pointer to null terminated return string, modified only if
> + *		return value is 0.
> + *
> + * Returns a string containing either the model name or the compatible value
> + * of the machine if found, else return error.
> + *
> + * Search for a machine model name or the compatible if model name is missing
> + * in a device tree node and retrieve a null terminated string value (pointer
> + * to data, not a copy). Returns 0 on success, -EINVAL if root of the device
> + * tree is not found and other error returned by of_property_read_string on
> + * failure.
> + */
> +int of_machine_get_model_name(const char **model)
> +{
> +	int error;
> +
> +	if (!of_node_get(of_root))
> +		return -EINVAL;
> +
> +	error = of_property_read_string(of_root, "model", model);
> +	if (error)
> +		error = of_property_read_string_index(of_root, "compatible",
> +						      0, model);
> +	of_node_put(of_root);
> +
> +	return error;
> +}
> +EXPORT_SYMBOL(of_machine_get_model_name);
> +
> +/**
>   *  __of_device_is_available - check if a device is available for use
>   *
>   *  @device: Node to check for availability, with locks already held
> diff --git a/include/linux/of.h b/include/linux/of.h
> index d72f01009297..13fc66531f1b 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -367,6 +367,7 @@ extern int of_alias_get_id(struct device_node *np, const char *stem);
>  extern int of_alias_get_highest_id(const char *stem);
> 
>  extern int of_machine_is_compatible(const char *compat);
> +extern int of_machine_get_model_name(const char **model);
> 
>  extern int of_add_property(struct device_node *np, struct property *prop);
>  extern int of_remove_property(struct device_node *np, struct property *prop);
> @@ -788,6 +789,11 @@ static inline int of_machine_is_compatible(const char *compat)
>  	return 0;
>  }
> 
> +static inline int of_machine_get_model_name(const char **model)
> +{
> +	return -EINVAL;
> +}
> +
>  static inline bool of_console_check(const struct device_node *dn, const char *name, int index)
>  {
>  	return false;
> --
> 2.7.4
> 
> 

[toc] | [prev] | [next] | [standalone]

#1524846

On 11/17/16 13:00, Frank Rowand wrote:
> On 11/17/16 07:32, Sudeep Holla wrote:
>> Currently platforms/drivers needing to get the machine model name are
>> replicating the same snippet of code. In some case, the OF reference
>> counting is either missing or incorrect.
>>
>> This patch adds support to read the machine model name either using
>> the "model" or the "compatible" property in the device tree root node
>> to the core OF/DT code.
>>
>> This can be used to remove all the duplicate code snippets doing exactly
>> same thing later.
> 
> I find five instances of reading only property "model":
> 
>   arch/arm/mach-imx/cpu.c
>   arch/arm/mach-mxs/mach-mxs.c
>   arch/c6x/kernel/setup.c
>   arch/mips/cavium-octeon/setup.c
>   arch/sh/boards/of-generic.c

My initial search was a little too strict. With a less restrictive
search I find 16 more instances of reading property "model" and
not reading property "compatible".

> 
> I find one instance of reading property "model", then if
> that does not exist, property "compatible":
> 
>   arch/mips/generic/proc.c
> 
> The proposed patch matches the code used in one place, and thus
> current usage does not match the patch description.
> 
> Is my search bad?  Are you planning to add additional instances
> of reading "model" then "compatible"?
> 
> -Frank
> 
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Frank Rowand <frowand.list@gmail.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>>  drivers/of/base.c  | 32 ++++++++++++++++++++++++++++++++
>>  include/linux/of.h |  6 ++++++
>>  2 files changed, 38 insertions(+)
>>
>> Hi Rob,
>>
>> It would be good if we can target this for v4.10, so that we have no
>> dependencies to push PATCH 2/2 in v4.11
>>
>> Regards,
>> Sudeep
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index a0bccb54a9bd..0810c5ecf1aa 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -546,6 +546,38 @@ int of_machine_is_compatible(const char *compat)
>>  EXPORT_SYMBOL(of_machine_is_compatible);
>>
>>  /**
>> + * of_machine_get_model_name - Find and read the model name or the compatible
>> + *		value for the machine.
>> + * @model:	pointer to null terminated return string, modified only if
>> + *		return value is 0.
>> + *
>> + * Returns a string containing either the model name or the compatible value
>> + * of the machine if found, else return error.
>> + *
>> + * Search for a machine model name or the compatible if model name is missing
>> + * in a device tree node and retrieve a null terminated string value (pointer
>> + * to data, not a copy). Returns 0 on success, -EINVAL if root of the device
>> + * tree is not found and other error returned by of_property_read_string on
>> + * failure.
>> + */
>> +int of_machine_get_model_name(const char **model)
>> +{
>> +	int error;
>> +
>> +	if (!of_node_get(of_root))
>> +		return -EINVAL;
>> +
>> +	error = of_property_read_string(of_root, "model", model);
>> +	if (error)
>> +		error = of_property_read_string_index(of_root, "compatible",
>> +						      0, model);
>> +	of_node_put(of_root);
>> +
>> +	return error;
>> +}
>> +EXPORT_SYMBOL(of_machine_get_model_name);
>> +
>> +/**
>>   *  __of_device_is_available - check if a device is available for use
>>   *
>>   *  @device: Node to check for availability, with locks already held
>> diff --git a/include/linux/of.h b/include/linux/of.h
>> index d72f01009297..13fc66531f1b 100644
>> --- a/include/linux/of.h
>> +++ b/include/linux/of.h
>> @@ -367,6 +367,7 @@ extern int of_alias_get_id(struct device_node *np, const char *stem);
>>  extern int of_alias_get_highest_id(const char *stem);
>>
>>  extern int of_machine_is_compatible(const char *compat);
>> +extern int of_machine_get_model_name(const char **model);
>>
>>  extern int of_add_property(struct device_node *np, struct property *prop);
>>  extern int of_remove_property(struct device_node *np, struct property *prop);
>> @@ -788,6 +789,11 @@ static inline int of_machine_is_compatible(const char *compat)
>>  	return 0;
>>  }
>>
>> +static inline int of_machine_get_model_name(const char **model)
>> +{
>> +	return -EINVAL;
>> +}
>> +
>>  static inline bool of_console_check(const struct device_node *dn, const char *name, int index)
>>  {
>>  	return false;
>> --
>> 2.7.4
>>
>>
> 
> 

[toc] | [prev] | [next] | [standalone]

#1525169

On 17/11/16 21:00, Frank Rowand wrote:
> On 11/17/16 07:32, Sudeep Holla wrote:
>> Currently platforms/drivers needing to get the machine model name are
>> replicating the same snippet of code. In some case, the OF reference
>> counting is either missing or incorrect.
>>
>> This patch adds support to read the machine model name either using
>> the "model" or the "compatible" property in the device tree root node
>> to the core OF/DT code.
>>
>> This can be used to remove all the duplicate code snippets doing exactly
>> same thing later.
>
> I find five instances of reading only property "model":
>
>   arch/arm/mach-imx/cpu.c
>   arch/arm/mach-mxs/mach-mxs.c
>   arch/c6x/kernel/setup.c
>   arch/mips/cavium-octeon/setup.c
>   arch/sh/boards/of-generic.c
>

Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
that this will be used for.

> I find one instance of reading property "model", then if
> that does not exist, property "compatible":
>
>   arch/mips/generic/proc.c
>

Correct as you can check in patch 2/2

> The proposed patch matches the code used in one place, and thus
> current usage does not match the patch description.
>

Yes, but does it matter ? compatibles are somewhat informative about the
model IMO.

> Is my search bad?  Are you planning to add additional instances
> of reading "model" then "compatible"?
>

No, just replacing the existing ones as in patch 2/2

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1525702

On 11/18/16 02:41, Sudeep Holla wrote:
> 
> 
> On 17/11/16 21:00, Frank Rowand wrote:
>> On 11/17/16 07:32, Sudeep Holla wrote:
>>> Currently platforms/drivers needing to get the machine model name are
>>> replicating the same snippet of code. In some case, the OF reference
>>> counting is either missing or incorrect.
>>>
>>> This patch adds support to read the machine model name either using
>>> the "model" or the "compatible" property in the device tree root node
>>> to the core OF/DT code.
>>>
>>> This can be used to remove all the duplicate code snippets doing exactly
>>> same thing later.
>>
>> I find five instances of reading only property "model":
>>
>>   arch/arm/mach-imx/cpu.c
>>   arch/arm/mach-mxs/mach-mxs.c
>>   arch/c6x/kernel/setup.c
>>   arch/mips/cavium-octeon/setup.c
>>   arch/sh/boards/of-generic.c
>>
> 
> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
> that this will be used for.

I have not seen 2/2.  I do not see it on the devicetree list or on lkml.

I did see a list of drivers in the RFC patch that you sent several hours
before this patch.

In that patch you replaced reading the model name from the _flat_ device
tree with the new function in at least one location.  That is not
correct.


> 
>> I find one instance of reading property "model", then if
>> that does not exist, property "compatible":
>>
>>   arch/mips/generic/proc.c
>>
> 
> Correct as you can check in patch 2/2
> 
>> The proposed patch matches the code used in one place, and thus
>> current usage does not match the patch description.
>>
> 
> Yes, but does it matter ? compatibles are somewhat informative about the
> model IMO.

Yes it does matter.  That is just sloppy and makes devicetree yet harder
to understand.  It hurts clarity.  The new function name says get "model",
not get "model" or "first element of the compatible list".

And using the _first_ element only of the compatible list to determine
model is not a good paradigm.  It is yet another hidden, special case,
undocumented trap to lure in the unwary.

It is extremely unlikely that the change actually changes behavior for an
existing device tree because there is probably no dts that does not
contain the model property but does contain the proper magic value in
the compatible property.  But did you actually check for that?

> 
>> Is my search bad?  Are you planning to add additional instances
>> of reading "model" then "compatible"?
>>
> 
> No, just replacing the existing ones as in patch 2/2
> 

You also ignored Arnd's comment in reply to your RFC patch.

-Frank

[toc] | [prev] | [next] | [standalone]

#1526856

Hi Sudeep,

On 11/18/16 12:22, Frank Rowand wrote:
> On 11/18/16 02:41, Sudeep Holla wrote:
>>
>>
>> On 17/11/16 21:00, Frank Rowand wrote:
>>> On 11/17/16 07:32, Sudeep Holla wrote:
>>>> Currently platforms/drivers needing to get the machine model name are
>>>> replicating the same snippet of code. In some case, the OF reference
>>>> counting is either missing or incorrect.
>>>>
>>>> This patch adds support to read the machine model name either using
>>>> the "model" or the "compatible" property in the device tree root node
>>>> to the core OF/DT code.
>>>>
>>>> This can be used to remove all the duplicate code snippets doing exactly
>>>> same thing later.
>>>
>>> I find five instances of reading only property "model":
>>>
>>>   arch/arm/mach-imx/cpu.c
>>>   arch/arm/mach-mxs/mach-mxs.c
>>>   arch/c6x/kernel/setup.c
>>>   arch/mips/cavium-octeon/setup.c
>>>   arch/sh/boards/of-generic.c
>>>
>>
>> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
>> that this will be used for.
> 
> I have not seen 2/2.  I do not see it on the devicetree list or on lkml.

Can you please re-send patch 2/2?

-Frank

> 
> I did see a list of drivers in the RFC patch that you sent several hours
> before this patch.
> 
> In that patch you replaced reading the model name from the _flat_ device
> tree with the new function in at least one location.  That is not
> correct.
> 
> 
>>
>>> I find one instance of reading property "model", then if
>>> that does not exist, property "compatible":
>>>
>>>   arch/mips/generic/proc.c
>>>
>>
>> Correct as you can check in patch 2/2
>>
>>> The proposed patch matches the code used in one place, and thus
>>> current usage does not match the patch description.
>>>
>>
>> Yes, but does it matter ? compatibles are somewhat informative about the
>> model IMO.
> 
> Yes it does matter.  That is just sloppy and makes devicetree yet harder
> to understand.  It hurts clarity.  The new function name says get "model",
> not get "model" or "first element of the compatible list".
> 
> And using the _first_ element only of the compatible list to determine
> model is not a good paradigm.  It is yet another hidden, special case,
> undocumented trap to lure in the unwary.
> 
> It is extremely unlikely that the change actually changes behavior for an
> existing device tree because there is probably no dts that does not
> contain the model property but does contain the proper magic value in
> the compatible property.  But did you actually check for that?
> 
>>
>>> Is my search bad?  Are you planning to add additional instances
>>> of reading "model" then "compatible"?
>>>
>>
>> No, just replacing the existing ones as in patch 2/2
>>
> 
> You also ignored Arnd's comment in reply to your RFC patch.
> 
> -Frank
> 

[toc] | [prev] | [next] | [standalone]

#1526880

On 21/11/16 16:05, Frank Rowand wrote:
> Hi Sudeep,
>
> On 11/18/16 12:22, Frank Rowand wrote:
>> On 11/18/16 02:41, Sudeep Holla wrote:
>>>
>>>
>>> On 17/11/16 21:00, Frank Rowand wrote:
>>>> On 11/17/16 07:32, Sudeep Holla wrote:
>>>>> Currently platforms/drivers needing to get the machine model name are
>>>>> replicating the same snippet of code. In some case, the OF reference
>>>>> counting is either missing or incorrect.
>>>>>
>>>>> This patch adds support to read the machine model name either using
>>>>> the "model" or the "compatible" property in the device tree root node
>>>>> to the core OF/DT code.
>>>>>
>>>>> This can be used to remove all the duplicate code snippets doing exactly
>>>>> same thing later.
>>>>
>>>> I find five instances of reading only property "model":
>>>>
>>>>   arch/arm/mach-imx/cpu.c
>>>>   arch/arm/mach-mxs/mach-mxs.c
>>>>   arch/c6x/kernel/setup.c
>>>>   arch/mips/cavium-octeon/setup.c
>>>>   arch/sh/boards/of-generic.c
>>>>
>>>
>>> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
>>> that this will be used for.
>>
>> I have not seen 2/2.  I do not see it on the devicetree list or on lkml.
>
> Can you please re-send patch 2/2?
>

Since it is based on -next, I would prefer to wait until next merge
window to resend. You should be able to check in the link I sent if
that's OK.

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1526998

On 11/21/16 08:23, Sudeep Holla wrote:
> 
> 
> On 21/11/16 16:05, Frank Rowand wrote:
>> Hi Sudeep,
>>
>> On 11/18/16 12:22, Frank Rowand wrote:
>>> On 11/18/16 02:41, Sudeep Holla wrote:
>>>>
>>>>
>>>> On 17/11/16 21:00, Frank Rowand wrote:
>>>>> On 11/17/16 07:32, Sudeep Holla wrote:
>>>>>> Currently platforms/drivers needing to get the machine model name are
>>>>>> replicating the same snippet of code. In some case, the OF reference
>>>>>> counting is either missing or incorrect.
>>>>>>
>>>>>> This patch adds support to read the machine model name either using
>>>>>> the "model" or the "compatible" property in the device tree root node
>>>>>> to the core OF/DT code.
>>>>>>
>>>>>> This can be used to remove all the duplicate code snippets doing exactly
>>>>>> same thing later.
>>>>>
>>>>> I find five instances of reading only property "model":
>>>>>
>>>>>   arch/arm/mach-imx/cpu.c
>>>>>   arch/arm/mach-mxs/mach-mxs.c
>>>>>   arch/c6x/kernel/setup.c
>>>>>   arch/mips/cavium-octeon/setup.c
>>>>>   arch/sh/boards/of-generic.c
>>>>>
>>>>
>>>> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
>>>> that this will be used for.
>>>
>>> I have not seen 2/2.  I do not see it on the devicetree list or on lkml.
>>
>> Can you please re-send patch 2/2?
>>
> 
> Since it is based on -next, I would prefer to wait until next merge
> window to resend. You should be able to check in the link I sent if
> that's OK.

I am missing or misunderstanding something.

I do not know what "the link I sent" means.

For some reason, the devicetree mail list and lmkl mail failed to send
me a copy of patch 2/2.  Or my mail server failed to receive them.  That
is why I asked you to resend the patch. I just now looked in the devicetree
archive and found it there.

So I now can see how you plan to use the new function.

-Frank

[toc] | [prev] | [next] | [standalone]

#1527040

On 11/21/16 11:24, Frank Rowand wrote:
> On 11/21/16 08:23, Sudeep Holla wrote:
>>
>>
>> On 21/11/16 16:05, Frank Rowand wrote:
>>> Hi Sudeep,
>>>
>>> On 11/18/16 12:22, Frank Rowand wrote:
>>>> On 11/18/16 02:41, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> On 17/11/16 21:00, Frank Rowand wrote:
>>>>>> On 11/17/16 07:32, Sudeep Holla wrote:
>>>>>>> Currently platforms/drivers needing to get the machine model name are
>>>>>>> replicating the same snippet of code. In some case, the OF reference
>>>>>>> counting is either missing or incorrect.
>>>>>>>
>>>>>>> This patch adds support to read the machine model name either using
>>>>>>> the "model" or the "compatible" property in the device tree root node
>>>>>>> to the core OF/DT code.
>>>>>>>
>>>>>>> This can be used to remove all the duplicate code snippets doing exactly
>>>>>>> same thing later.
>>>>>>
>>>>>> I find five instances of reading only property "model":
>>>>>>
>>>>>>   arch/arm/mach-imx/cpu.c
>>>>>>   arch/arm/mach-mxs/mach-mxs.c
>>>>>>   arch/c6x/kernel/setup.c
>>>>>>   arch/mips/cavium-octeon/setup.c
>>>>>>   arch/sh/boards/of-generic.c
>>>>>>
>>>>>
>>>>> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
>>>>> that this will be used for.
>>>>
>>>> I have not seen 2/2.  I do not see it on the devicetree list or on lkml.
>>>
>>> Can you please re-send patch 2/2?
>>>
>>
>> Since it is based on -next, I would prefer to wait until next merge
>> window to resend. You should be able to check in the link I sent if
>> that's OK.
> 
> I am missing or misunderstanding something.
> 
> I do not know what "the link I sent" means.

Ah, the links were in the email you sent before this one, but I read this
one first.  Got it now.


> 
> For some reason, the devicetree mail list and lmkl mail failed to send
> me a copy of patch 2/2.  Or my mail server failed to receive them.  That
> is why I asked you to resend the patch. I just now looked in the devicetree
> archive and found it there.
> 
> So I now can see how you plan to use the new function.
> 
> -Frank
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#1526878

On 18/11/16 20:22, Frank Rowand wrote:
> On 11/18/16 02:41, Sudeep Holla wrote:
>>
>>
>> On 17/11/16 21:00, Frank Rowand wrote:
>>> On 11/17/16 07:32, Sudeep Holla wrote:
>>>> Currently platforms/drivers needing to get the machine model name are
>>>> replicating the same snippet of code. In some case, the OF reference
>>>> counting is either missing or incorrect.
>>>>
>>>> This patch adds support to read the machine model name either using
>>>> the "model" or the "compatible" property in the device tree root node
>>>> to the core OF/DT code.
>>>>
>>>> This can be used to remove all the duplicate code snippets doing exactly
>>>> same thing later.
>>>
>>> I find five instances of reading only property "model":
>>>
>>>   arch/arm/mach-imx/cpu.c
>>>   arch/arm/mach-mxs/mach-mxs.c
>>>   arch/c6x/kernel/setup.c
>>>   arch/mips/cavium-octeon/setup.c
>>>   arch/sh/boards/of-generic.c
>>>
>>
>> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
>> that this will be used for.
>
> I have not seen 2/2.  I do not see it on the devicetree list or on lkml.
>

Yes on both [1][2]

> I did see a list of drivers in the RFC patch that you sent several hours
> before this patch.
>
> In that patch you replaced reading the model name from the _flat_ device
> tree with the new function in at least one location.  That is not
> correct.
>
>
>>
>>> I find one instance of reading property "model", then if
>>> that does not exist, property "compatible":
>>>
>>>   arch/mips/generic/proc.c
>>>
>>
>> Correct as you can check in patch 2/2
>>
>>> The proposed patch matches the code used in one place, and thus
>>> current usage does not match the patch description.
>>>
>>
>> Yes, but does it matter ? compatibles are somewhat informative about the
>> model IMO.
>
> Yes it does matter.  That is just sloppy and makes devicetree yet harder
> to understand.  It hurts clarity.  The new function name says get "model",
> not get "model" or "first element of the compatible list".
>

This is a implementation in the Linux and it doesn't change anything in
DT semantics. I am not able to get your concern.

> And using the _first_ element only of the compatible list to determine
> model is not a good paradigm.  It is yet another hidden, special case,
> undocumented trap to lure in the unwary.
>

The function is documented and again this doesn't enforce anything in 
the bindings. It's just the way it's used by the Linux kernel.

[...]

>
> You also ignored Arnd's comment in reply to your RFC patch.
>

OK, all I can see is that Arnd wanted to reuse of_root, which I did.
Did I miss anything else ?

-- 
Regards,
Sudeep

[1] http://marc.info/?l=linux-kernel&m=147940586616629&w=2
[2] http://marc.info/?l=linux-kernel&m=147940575116579&w=2

[toc] | [prev] | [next] | [standalone]

#1527026

On 11/21/16 08:20, Sudeep Holla wrote:
> 
> 
> On 18/11/16 20:22, Frank Rowand wrote:
>> On 11/18/16 02:41, Sudeep Holla wrote:
>>>
>>>
>>> On 17/11/16 21:00, Frank Rowand wrote:
>>>> On 11/17/16 07:32, Sudeep Holla wrote:
>>>>> Currently platforms/drivers needing to get the machine model name are
>>>>> replicating the same snippet of code. In some case, the OF reference
>>>>> counting is either missing or incorrect.
>>>>>
>>>>> This patch adds support to read the machine model name either using
>>>>> the "model" or the "compatible" property in the device tree root node
>>>>> to the core OF/DT code.
>>>>>
>>>>> This can be used to remove all the duplicate code snippets doing exactly
>>>>> same thing later.
>>>>
>>>> I find five instances of reading only property "model":
>>>>
>>>>   arch/arm/mach-imx/cpu.c
>>>>   arch/arm/mach-mxs/mach-mxs.c
>>>>   arch/c6x/kernel/setup.c
>>>>   arch/mips/cavium-octeon/setup.c
>>>>   arch/sh/boards/of-generic.c
>>>>
>>>
>>> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
>>> that this will be used for.
>>
>> I have not seen 2/2.  I do not see it on the devicetree list or on lkml.
>>
> 
> Yes on both [1][2]
> 
>> I did see a list of drivers in the RFC patch that you sent several hours
>> before this patch.
>>
>> In that patch you replaced reading the model name from the _flat_ device
>> tree with the new function in at least one location.  That is not
>> correct.
>>
>>
>>>
>>>> I find one instance of reading property "model", then if
>>>> that does not exist, property "compatible":
>>>>
>>>>   arch/mips/generic/proc.c

Just for completeness, now that I have seen patch 2/2, there is a
second location that currently uses "compatible" if "model" does
not exist: drivers/soc/fsl/guts.c

>>>>
>>>
>>> Correct as you can check in patch 2/2
>>>
>>>> The proposed patch matches the code used in one place, and thus
>>>> current usage does not match the patch description.
>>>>
>>>
>>> Yes, but does it matter ? compatibles are somewhat informative about the
>>> model IMO.
>>
>> Yes it does matter.  That is just sloppy and makes devicetree yet harder
>> to understand.  It hurts clarity.  The new function name says get "model",
>> not get "model" or "first element of the compatible list".

An example of a function name that would not hurt clarity would be
of_model_or_1st_compatible().


>>
> 
> This is a implementation in the Linux and it doesn't change anything in
> DT semantics. I am not able to get your concern.

The existing code in five locations that patch 2/2 changes only attempt
to read the value of property "model".  Changing those five locations
to use of_machine_get_model_name() results in those locations using the
first string of the "compatible" property if "model" does not exist.

The value found is potentially used to determine whether to execute
model specific code.  An example of this is: octeon_pcie_pcibios_map_irq().
Can you guarantee that there is no device tree that does not contain
a "model" property in the root node, but does contains a "compatible"
property in the root node whose first value is "EBH5600"?

I have pasted the relevant code from octeon_pcie_pcibios_map_irq()
below for convenient reference:

int __init octeon_pcie_pcibios_map_irq(const struct pci_dev *dev,
                                       u8 slot, u8 pin)
{
        /*
         * The EBH5600 board with the PCI to PCIe bridge mistakenly
         * wires the first slot for both device id 2 and interrupt
         * A. According to the PCI spec, device id 2 should be C. The
         * following kludge attempts to fix this.
         */
        if (strstr(octeon_board_type_string(), "EBH5600") &&
            dev->bus && dev->bus->parent) {

My point is that it is not possible to review patch 2/2 to verify whether
any change in kernel behavior results from the change, because we do not
have access to all device tree sources.  patch 2/2 is intended to clean
up code, not to change behavior.


> 
>> And using the _first_ element only of the compatible list to determine
>> model is not a good paradigm.  It is yet another hidden, special case,
>> undocumented trap to lure in the unwary.
>>
> 
> The function is documented and again this doesn't enforce anything in
> the bindings. It's just the way it's used by the Linux kernel.
> 
> [...]
> 
>>
>> You also ignored Arnd's comment in reply to your RFC patch.
>>
> 
> OK, all I can see is that Arnd wanted to reuse of_root, which I did.
> Did I miss anything else ?
> 

My mistake, sorry.  I misread the patch.

-Frank

[toc] | [prev] | [next] | [standalone]

#1525406

On Thu, Nov 17, 2016 at 03:32:54PM +0000, Sudeep Holla wrote:
> Currently platforms/drivers needing to get the machine model name are
> replicating the same snippet of code. In some case, the OF reference
> counting is either missing or incorrect.
> 
> This patch adds support to read the machine model name either using
> the "model" or the "compatible" property in the device tree root node
> to the core OF/DT code.
> 
> This can be used to remove all the duplicate code snippets doing exactly
> same thing later.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/of/base.c  | 32 ++++++++++++++++++++++++++++++++
>  include/linux/of.h |  6 ++++++
>  2 files changed, 38 insertions(+)
> 
> Hi Rob,
> 
> It would be good if we can target this for v4.10, so that we have no
> dependencies to push PATCH 2/2 in v4.11

Applied.

Rob

[toc] | [prev] | [next] | [standalone]

#1525691

On 11/18/16 06:46, Rob Herring wrote:
> On Thu, Nov 17, 2016 at 03:32:54PM +0000, Sudeep Holla wrote:
>> Currently platforms/drivers needing to get the machine model name are
>> replicating the same snippet of code. In some case, the OF reference
>> counting is either missing or incorrect.
>>
>> This patch adds support to read the machine model name either using
>> the "model" or the "compatible" property in the device tree root node
>> to the core OF/DT code.
>>
>> This can be used to remove all the duplicate code snippets doing exactly
>> same thing later.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Frank Rowand <frowand.list@gmail.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>>  drivers/of/base.c  | 32 ++++++++++++++++++++++++++++++++
>>  include/linux/of.h |  6 ++++++
>>  2 files changed, 38 insertions(+)
>>
>> Hi Rob,
>>
>> It would be good if we can target this for v4.10, so that we have no
>> dependencies to push PATCH 2/2 in v4.11
> 
> Applied.
> 
> Rob
> 

A little fast on the trigger Rob.

-Frank

[toc] | [prev] | [next] | [standalone]

#1527845

Hi Rob,

On 11/18/16 12:00, Frank Rowand wrote:
> On 11/18/16 06:46, Rob Herring wrote:
>> On Thu, Nov 17, 2016 at 03:32:54PM +0000, Sudeep Holla wrote:
>>> Currently platforms/drivers needing to get the machine model name are
>>> replicating the same snippet of code. In some case, the OF reference
>>> counting is either missing or incorrect.
>>>
>>> This patch adds support to read the machine model name either using
>>> the "model" or the "compatible" property in the device tree root node
>>> to the core OF/DT code.
>>>
>>> This can be used to remove all the duplicate code snippets doing exactly
>>> same thing later.
>>>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Cc: Frank Rowand <frowand.list@gmail.com>
>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>>  drivers/of/base.c  | 32 ++++++++++++++++++++++++++++++++
>>>  include/linux/of.h |  6 ++++++
>>>  2 files changed, 38 insertions(+)
>>>
>>> Hi Rob,
>>>
>>> It would be good if we can target this for v4.10, so that we have no
>>> dependencies to push PATCH 2/2 in v4.11
>>
>> Applied.
>>
>> Rob
>>
> 
> A little fast on the trigger Rob.
> 
> -Frank

This patch adds a function that leads to conflating the "model" property
and the "compatible" property. This leads to opaque, confusing and unclear
code where ever it is used.   I think it is not good for the device tree
framework to contribute to writing unclear code.

Further, only two of the proposed users of this new function appear to
be proper usage.  I do not think that the small amount of reduced lines
of code is a good trade off for the reduced code clarity and for the
potential for future mis-use of this function.

Can I convince you to revert this patch?

If not, will you accept a patch to change the function name to more
clearly indicate what it does?  (One possible name would be
of_model_or_1st_compatible().)

-Frank

[toc] | [prev] | [next] | [standalone]

#1527953

On Tue, Nov 22, 2016 at 12:44 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> Hi Rob,
>
> On 11/18/16 12:00, Frank Rowand wrote:
>> On 11/18/16 06:46, Rob Herring wrote:
>>> On Thu, Nov 17, 2016 at 03:32:54PM +0000, Sudeep Holla wrote:
>>>> Currently platforms/drivers needing to get the machine model name are
>>>> replicating the same snippet of code. In some case, the OF reference
>>>> counting is either missing or incorrect.
>>>>
>>>> This patch adds support to read the machine model name either using
>>>> the "model" or the "compatible" property in the device tree root node
>>>> to the core OF/DT code.
>>>>
>>>> This can be used to remove all the duplicate code snippets doing exactly
>>>> same thing later.
>>>>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Frank Rowand <frowand.list@gmail.com>
>>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>> ---
>>>>  drivers/of/base.c  | 32 ++++++++++++++++++++++++++++++++
>>>>  include/linux/of.h |  6 ++++++
>>>>  2 files changed, 38 insertions(+)
>>>>
>>>> Hi Rob,
>>>>
>>>> It would be good if we can target this for v4.10, so that we have no
>>>> dependencies to push PATCH 2/2 in v4.11
>>>
>>> Applied.
>>>
>>> Rob
>>>
>>
>> A little fast on the trigger Rob.
>>
>> -Frank
>
> This patch adds a function that leads to conflating the "model" property
> and the "compatible" property. This leads to opaque, confusing and unclear
> code where ever it is used.   I think it is not good for the device tree
> framework to contribute to writing unclear code.
>
> Further, only two of the proposed users of this new function appear to
> be proper usage.  I do not think that the small amount of reduced lines
> of code is a good trade off for the reduced code clarity and for the
> potential for future mis-use of this function.
>
> Can I convince you to revert this patch?

Yes, I will revert.

> If not, will you accept a patch to change the function name to more
> clearly indicate what it does?  (One possible name would be
> of_model_or_1st_compatible().)

I took it as there's already the FDT equivalent function. I don't have
an issue with the name as the purpose is to get the best name string
for the machine which is model if present and most specific compatible
if not. However, any use of it beyond informational purpose is wrong.
For matching purposes, only compatible should be used.

Rob

[toc] | [prev] | [next] | [standalone]

#1528300

On 22/11/16 21:35, Rob Herring wrote:
> On Tue, Nov 22, 2016 at 12:44 PM, Frank Rowand <frowand.list@gmail.com> wrote:

[...]

>>
>> This patch adds a function that leads to conflating the "model" property
>> and the "compatible" property. This leads to opaque, confusing and unclear
>> code where ever it is used.   I think it is not good for the device tree
>> framework to contribute to writing unclear code.
>>
>> Further, only two of the proposed users of this new function appear to
>> be proper usage.  I do not think that the small amount of reduced lines
>> of code is a good trade off for the reduced code clarity and for the
>> potential for future mis-use of this function.
>>
>> Can I convince you to revert this patch?
>
> Yes, I will revert.
>
>> If not, will you accept a patch to change the function name to more
>> clearly indicate what it does?  (One possible name would be
>> of_model_or_1st_compatible().)
>
> I took it as there's already the FDT equivalent function.

Yes it was mainly for non of_flat_* replacement for
of_flat_dt_get_machine_name

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1528298

On 22/11/16 18:44, Frank Rowand wrote:
> Hi Rob,

[...]

>
> This patch adds a function that leads to conflating the "model"
> property and the "compatible" property. This leads to opaque,
> confusing and unclear code where ever it is used.   I think it is
> not good for the device tree framework to contribute to writing
> unclear code.
>

I agree, the main intention of this patch initially was to have a non
flat_* version of of_flat_dt_get_machine_name

> Further, only two of the proposed users of this new function appear
> to be proper usage.  I do not think that the small amount of reduced
> lines of code is a good trade off for the reduced code clarity and
> for the potential for future mis-use of this function.
>

OK, most of the place I found it used for logging/informational purpose
and hence I thought it could replace in places where even compatible is
used. If that's wrong or leads to misuse of this API, then fine we
should not have one.

-- 
Regards,
Sudeep

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web