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

Groups > linux.kernel > #1510155 > unrolled thread

Re: [PATCH] soc: qcom: Add SoC info driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] soc: qcom: Add SoC info driver Imran Khan <kimran@codeaurora.org> - 2016-10-27 16:00 +0200
    Re: [PATCH] soc: qcom: Add SoC info driver Arnd Bergmann <arnd@arndb.de> - 2016-10-27 16:00 +0200
      Re: [PATCH] soc: qcom: Add SoC info driver Imran Khan <kimran@codeaurora.org> - 2016-11-02 09:00 +0100
        Re: [PATCH] soc: qcom: Add SoC info driver Arnd Bergmann <arnd@arndb.de> - 2016-11-02 14:20 +0100

#1510155 — Re: [PATCH] soc: qcom: Add SoC info driver

On 10/26/2016 8:16 PM, Arnd Bergmann wrote:
> On Wednesday, October 26, 2016 7:42:08 PM CEST Imran Khan wrote:
>> On 10/26/2016 7:35 PM, Arnd Bergmann wrote:
>>>>> As we are talking about generic soc_device_attribute fields, I was hoping that
>>>>> having a vendor field would be helpful as along with family it would provide
>>>>> a more thorough information. Also as more than one foundries may be used for 
>>>>> a soc, can we have a field say foundry_id to provide this information.
>>> My first feeling is that this 'vendor' information can should be
>>> derived from the family. It's also not clear what would happen
>>> to this when a company gets bought. E.g. the Oxnas product family
>>> was subsequently owned by Oxford, PLX, Avago and Broadcom, and the
>>> mxs family was Sigmatel, Freescale, now NXP and might soon be
>>> Qualcomm. What would you put in there in this case?
>>
>> Okay, not having vendor field is fine for me. Could you also suggest
>> something about the foundry_id field.
> 
> This one seems more well-defined, so it's probably ok to add. What
> would be the use case of reading this? Would you want to read it
> just from user space or also from the kernel?
> 

As of now the use case I can think of, only involve reading this from user
space. For example for the same soc, coming from different foundries with
different manufacturing process, we may have a situation where some inconsistent
h/w behavior is being observed only on parts received from a certain foundry
and in those cases this information may help in segregation of problematic socs
and may also be used in testing these socs under a different set of settings like
voltage, frequency etc.

> Maybe this can be combined with a manufacturing process, which probably
> falls into a similar category, so we could have something like
> "TSMC 28ULP" as a string in there.
>

Yes. Having a manufacturing process as part of foundry-id can provide a more
thorough information.
 
> 	Arnd
> 


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation

[toc] | [next] | [standalone]

#1510191

On Thursday, October 27, 2016 6:40:27 PM CEST Imran Khan wrote:
> On 10/26/2016 8:16 PM, Arnd Bergmann wrote:
> > On Wednesday, October 26, 2016 7:42:08 PM CEST Imran Khan wrote:
> >> On 10/26/2016 7:35 PM, Arnd Bergmann wrote:
> >>>>> As we are talking about generic soc_device_attribute fields, I was hoping that
> >>>>> having a vendor field would be helpful as along with family it would provide
> >>>>> a more thorough information. Also as more than one foundries may be used for 
> >>>>> a soc, can we have a field say foundry_id to provide this information.
> >>> My first feeling is that this 'vendor' information can should be
> >>> derived from the family. It's also not clear what would happen
> >>> to this when a company gets bought. E.g. the Oxnas product family
> >>> was subsequently owned by Oxford, PLX, Avago and Broadcom, and the
> >>> mxs family was Sigmatel, Freescale, now NXP and might soon be
> >>> Qualcomm. What would you put in there in this case?
> >>
> >> Okay, not having vendor field is fine for me. Could you also suggest
> >> something about the foundry_id field.
> > 
> > This one seems more well-defined, so it's probably ok to add. What
> > would be the use case of reading this? Would you want to read it
> > just from user space or also from the kernel?
> > 
> 
> As of now the use case I can think of, only involve reading this from user
> space. For example for the same soc, coming from different foundries with
> different manufacturing process, we may have a situation where some inconsistent
> h/w behavior is being observed only on parts received from a certain foundry
> and in those cases this information may help in segregation of problematic socs
> and may also be used in testing these socs under a different set of settings like
> voltage, frequency etc.
>
> > Maybe this can be combined with a manufacturing process, which probably
> > falls into a similar category, so we could have something like
> > "TSMC 28ULP" as a string in there.
> >
> 
> Yes. Having a manufacturing process as part of foundry-id can provide a more
> thorough information.

Ok, sounds good. Let's do it like this. We can always add support for
in-kernel matching of this string if needed later.

	Arnd

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

#1513720

On 10/27/2016 7:11 PM, Arnd Bergmann wrote:
> On Thursday, October 27, 2016 6:40:27 PM CEST Imran Khan wrote:
>> On 10/26/2016 8:16 PM, Arnd Bergmann wrote:
>>> On Wednesday, October 26, 2016 7:42:08 PM CEST Imran Khan wrote:
>>>> On 10/26/2016 7:35 PM, Arnd Bergmann wrote:
>>>>>>> As we are talking about generic soc_device_attribute fields, I was hoping that
>>>>>>> having a vendor field would be helpful as along with family it would provide
>>>>>>> a more thorough information. Also as more than one foundries may be used for 
>>>>>>> a soc, can we have a field say foundry_id to provide this information.
>>>>> My first feeling is that this 'vendor' information can should be
>>>>> derived from the family. It's also not clear what would happen
>>>>> to this when a company gets bought. E.g. the Oxnas product family
>>>>> was subsequently owned by Oxford, PLX, Avago and Broadcom, and the
>>>>> mxs family was Sigmatel, Freescale, now NXP and might soon be
>>>>> Qualcomm. What would you put in there in this case?
>>>>
>>>> Okay, not having vendor field is fine for me. Could you also suggest
>>>> something about the foundry_id field.
>>>
>>> This one seems more well-defined, so it's probably ok to add. What
>>> would be the use case of reading this? Would you want to read it
>>> just from user space or also from the kernel?
>>>
>>
>> As of now the use case I can think of, only involve reading this from user
>> space. For example for the same soc, coming from different foundries with
>> different manufacturing process, we may have a situation where some inconsistent
>> h/w behavior is being observed only on parts received from a certain foundry
>> and in those cases this information may help in segregation of problematic socs
>> and may also be used in testing these socs under a different set of settings like
>> voltage, frequency etc.
>>
>>> Maybe this can be combined with a manufacturing process, which probably
>>> falls into a similar category, so we could have something like
>>> "TSMC 28ULP" as a string in there.
>>>
>>
>> Yes. Having a manufacturing process as part of foundry-id can provide a more
>> thorough information.
> 
> Ok, sounds good. Let's do it like this. We can always add support for
> in-kernel matching of this string if needed later.
>

Thanks for the feedback. So how should I proceed now, should I 

i. send one patch first that adds the serial_number and foundry_id fields
in generic soc_dev_attribute structure and then send my modified socinfo 
driver as per new soc_dev_attribute structure

or 

ii. send both the changes as 2 separate patches of the same patch set.

or 

iii. Continue with the current soc_dev_attribute structure and modify
the socinfo driver once soc_dev_attribute structure has serial_number
and foundry_id fields.

 
> 	Arnd
> 


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation

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

#1513836

On Wednesday 02 November 2016, Imran Khan wrote:
> On 10/27/2016 7:11 PM, Arnd Bergmann wrote:
> > On Thursday, October 27, 2016 6:40:27 PM CEST Imran Khan wrote:
> >> On 10/26/2016 8:16 PM, Arnd Bergmann wrote:
> >>> On Wednesday, October 26, 2016 7:42:08 PM CEST Imran Khan wrote:
> >>
> >> Yes. Having a manufacturing process as part of foundry-id can provide a more
> >> thorough information.
> > 
> > Ok, sounds good. Let's do it like this. We can always add support for
> > in-kernel matching of this string if needed later.
> >
> 
> Thanks for the feedback. So how should I proceed now, should I 
> 
> i. send one patch first that adds the serial_number and foundry_id fields
> in generic soc_dev_attribute structure and then send my modified socinfo 
> driver as per new soc_dev_attribute structure
> 
> or 
> 
> ii. send both the changes as 2 separate patches of the same patch set.
> 
> or 
> 
> iii. Continue with the current soc_dev_attribute structure and modify
> the socinfo driver once soc_dev_attribute structure has serial_number
> and foundry_id fields.

It's not overly important, but I'd prefer the third approach, the advantage
being that we can review the driver and merge it independently of
any possible further discussion on the added attributes. Sending
this as a series of three patches (1. add the driver, 2. add the
infrastructure, 3. use the infrastructure in your driver) is probably
best.

	Arnd

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web