Re: [PATCH v4] MIPS: Expose prid and globalnumber to sysfs

From: "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To: "Greg KH" <greg@kroah.com>
Cc: "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	linux-kernel@vger.kernel.org,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	linux-api@vger.kernel.org, f.fainelli@gmail.com
Subject: Re: [PATCH v4] MIPS: Expose prid and globalnumber to sysfs
Date: Tue, 16 Aug 2022 13:38:27 +0100	[thread overview]
Message-ID: <c17cdcf9-14bd-4287-9525-287dfc908fa2@www.fastmail.com> (raw)
In-Reply-To: <YvthfQUfv0TiO/bK@kroah.com>

在2022年8月16日八月 上午10:21，Greg KH写道：
> On Tue, Aug 16, 2022 at 09:12:58AM +0000, Jiaxun Yang wrote:
>> Some application would like to know precise model and rev of processor
>> to do errata workaround or optimization.
>> 
>> Expose them in sysfs as:
>> /sys/devices/system/cpu/cpuX/regs/identification/prid
>> /sys/devices/system/cpu/cpuX/regs/identification/globalnumber
>> 
>> Reusing AArch64 CPU registers directory.
>> 
>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>> ---
>> v2: Drop static qualifier for kobj (gregkh)
>> v3: Use kzalloc to allocate struct cpuregs.
>>     note: When Greg mentioned about static I was thinking about
>>     static qualifier of percpu variable. After reading documents
>>     again it turns out kobjs should be allocated at runtime. Arm64's
>>     cpuinfo kobj is also on a percpu variable... I guess that was a
>>     intentional use?
>> v4: Properly handle err of kobj creation. (gregkh)
>
> Nothing was fixed :(

[Resending due to previous mail contains HTML. I just got a Macbook
and was trying to use it's built-in mail client. Turns out that it's
sending HTML even with "Plain Text" selected...
Now turning back to mutt. Apologise for inconvinence.]

Hi Greg,

Sorry for misinterpret your comments again :(

Hmm I just use kobject_put to replace kobject_del.
I thought that was what you were trying to say?

>
> Again, please read the documentation for the kobject calls you are
> making as it explains how to properly handle errors being returned from
> them, and what you need to call if that happens.

Quoting the document the only sentence mentioning error handling is:

It is good practice to always use kobject_put() after kobject_init() to avoid
errors creeping in.

In our case is it safe to call kobject_put if() the error happens at kobject_init()
stage of kobject_init_and_add()? Do you mean that I should use kobject_put to
clean up kobject_init_and_add() error?

Thanks
- Jiaxun

>
> thanks,
>
> greg k-h