Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1433069 > unrolled thread
| Started by | Catalin Marinas <catalin.marinas@arm.com> |
|---|---|
| First post | 2016-06-28 17:40 +0200 |
| Last post | 2016-06-28 18:30 +0200 |
| Articles | 3 — 3 participants |
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.
Re: [PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs Catalin Marinas <catalin.marinas@arm.com> - 2016-06-28 17:40 +0200
Re: [PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs Suzuki K Poulose <Suzuki.Poulose@arm.com> - 2016-06-28 18:20 +0200
Re: [PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs Mark Rutland <mark.rutland@arm.com> - 2016-06-28 18:30 +0200
| From | Catalin Marinas <catalin.marinas@arm.com> |
|---|---|
| Date | 2016-06-28 17:40 +0200 |
| Subject | Re: [PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs |
| Message-ID | <rP3hf-rd-9@gated-at.bofh.it> |
On Tue, Jun 21, 2016 at 12:12:36PM +0100, Suzuki K. Poulose wrote:
> +#define CPUINFO_ATTR_RO(_name) \
> + static ssize_t show_##_name(struct device *dev, \
> + struct device_attribute *attr, char *buf) \
> + { \
> + struct cpuinfo_arm64 *info = &per_cpu(cpu_data, dev->id); \
> + \
> + if (info->reg_midr) \
> + return sprintf(buf, "0x%016x\n", info->reg_##_name); \
> + else \
> + return 0; \
> + } \
> + static DEVICE_ATTR(_name, 0444, show_##_name, NULL)
> +
> +CPUINFO_ATTR_RO(midr);
> +CPUINFO_ATTR_RO(revidr);
Since exposing these values is aimed at JIT code (and not human
readable), wouldn't it make more sense to present the binary value
instead of the ascii transformation?
--
Catalin
[toc] | [next] | [standalone]
| From | Suzuki K Poulose <Suzuki.Poulose@arm.com> |
|---|---|
| Date | 2016-06-28 18:20 +0200 |
| Message-ID | <rP3TX-Uy-1@gated-at.bofh.it> |
| In reply to | #1433069 |
On 28/06/16 16:33, Catalin Marinas wrote:
> On Tue, Jun 21, 2016 at 12:12:36PM +0100, Suzuki K. Poulose wrote:
>> +#define CPUINFO_ATTR_RO(_name) \
>> + static ssize_t show_##_name(struct device *dev, \
>> + struct device_attribute *attr, char *buf) \
>> + { \
>> + struct cpuinfo_arm64 *info = &per_cpu(cpu_data, dev->id); \
>> + \
>> + if (info->reg_midr) \
>> + return sprintf(buf, "0x%016x\n", info->reg_##_name); \
>> + else \
>> + return 0; \
>> + } \
>> + static DEVICE_ATTR(_name, 0444, show_##_name, NULL)
>> +
>> +CPUINFO_ATTR_RO(midr);
>> +CPUINFO_ATTR_RO(revidr);
>
> Since exposing these values is aimed at JIT code (and not human
> readable), wouldn't it make more sense to present the binary value
> instead of the ascii transformation?
I am fine with either.
Edward,
Do you have any preference ?
Suzuki
[toc] | [prev] | [next] | [standalone]
| From | Mark Rutland <mark.rutland@arm.com> |
|---|---|
| Date | 2016-06-28 18:30 +0200 |
| Message-ID | <rP43E-XT-23@gated-at.bofh.it> |
| In reply to | #1433069 |
On Tue, Jun 28, 2016 at 04:33:46PM +0100, Catalin Marinas wrote:
> On Tue, Jun 21, 2016 at 12:12:36PM +0100, Suzuki K. Poulose wrote:
> > +#define CPUINFO_ATTR_RO(_name) \
> > + static ssize_t show_##_name(struct device *dev, \
> > + struct device_attribute *attr, char *buf) \
> > + { \
> > + struct cpuinfo_arm64 *info = &per_cpu(cpu_data, dev->id); \
> > + \
> > + if (info->reg_midr) \
> > + return sprintf(buf, "0x%016x\n", info->reg_##_name); \
> > + else \
> > + return 0; \
> > + } \
> > + static DEVICE_ATTR(_name, 0444, show_##_name, NULL)
> > +
> > +CPUINFO_ATTR_RO(midr);
> > +CPUINFO_ATTR_RO(revidr);
>
> Since exposing these values is aimed at JIT code (and not human
> readable), wouldn't it make more sense to present the binary value
> instead of the ascii transformation?
Per Documentation/filesystems/sysfs.txt, attributes should be ASCII text
files, with one value per file. I think they should stay as they are.
Thanks,
Mark.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web