On Thu, 2017-01-26 at 18:03 -0800, Guenter Roeck wrote:
On 01/26/2017 05:37 PM, Zhang Rui wrote:No. IMO, it depends on if the interface is used or not.
That sounds like fun. Changing bq27200-0 to bq27200_0 is Forbidden by
On Wed, 2017-01-25 at 13:09 +0100, Pali RohÃr wrote:
If this is the case, you'd better set
On Wednesday 25 January 2017 12:12:33 Pavel Machek wrote:
IIRC hwmon is used on Nokia N900.
Hi!
Ok, so the patch is on the way in. What to do next?
Well, lets revert the patch and then we can discuss what to
The hwmon name attribute must not include '-', as
Not really. Revert now. Sorry.
Right.
Before reverting, can you please try if this patch
works
or not?
Are you sure? This does not look equivalent to me at
all.
"name" file handling moved from drivers to the core,
which
added some
crazy checks what name can contain. Even if this
"works",
what is the
expected effect on the "name" file?
documented
in
Documentation/hwmon/sysfs-interface. Is enforcing that
'crazy' ?
Maybe in your world, but not in mine.
do
with
the "name" problem.
pavel@n900:/sys/class/hwmon$ cat hwmon0/name
bq27200-0
pavel@n900:/sys/class/hwmon$ cat hwmon1/name
rx51-battery
Ok... Question is "does someone actually use hwmon*/name on
To provide some detail: libsensors gets just as confused with
wildcards
and whitespace/newline as it does with '-' in the reported
name,
which
is why those are blocked by the new API.
N900"?
If
so, we can't change it, but it is well possible that noone is.
But I have not seen hwmon devices for bq27200 and rx51-battery
yet.
Those are power supply driver and auto-exporting them also via
hwmon
is
something new, right? If yes, then we can use any name for those
new
hwmon devices as they cannot break userspace... as there is no
userspace
application for them.
(struct thermal_zone_params)->no_hwmon when registering the thermal
zone device, in which case, the hwmon device will not be created.
In fact, I'd prefer to change tzp->no_hwmon to tzp->hwmon to not
create
hwmon I/F by default, and see if there is anyone using it. If yes,
we
can set the flag in soc thermal driver, explicitly, at meantime, a
hwmon compatible name is required.
But one foreseeable result is that we may get bug reports from end
user
that some sensors (acpitz, etc) are gone in 'sensors' output. And
TBH,
I'm not quite sure if this can be counted as a regression or not.
the ABI Police, but taking the entire device away is ok.
If hwmon I/F is used, we can not take it away, nor change its name.
If thermal zone I/F is used, we can not change it's 'type' name to be
compatible with new hwmon API.
Anyway, sounds good to me. No one will use something that isn't
there,
and no one will realize that it could have been there, so I don't
expect
anyone to complain.
Yes, I agree.
thanks,
rui