[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <c17cdcf9-14bd-4287-9525-287dfc908fa2@www.fastmail.com>
Date: Tue, 16 Aug 2022 13:38:27 +0100
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Greg KH" <greg@...ah.com>
Cc: "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
linux-kernel@...r.kernel.org,
"Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
linux-api@...r.kernel.org, f.fainelli@...il.com
Subject: Re: [PATCH v4] MIPS: Expose prid and globalnumber to sysfs
在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@...goat.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
Powered by blists - more mailing lists