lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 11 Sep 2014 02:32:35 +0000 From: "Li.Xiubo@...escale.com" <Li.Xiubo@...escale.com> To: Thomas Gleixner <tglx@...utronix.de> CC: "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: RE: [PATCH] clocksource: Add BE/LE APIs support for clocksource counter reading. > Cc: daniel.lezcano@...aro.org; linux-kernel@...r.kernel.org > Subject: Re: [PATCH] clocksource: Add BE/LE APIs support for clocksource > counter reading. > > On Wed, 10 Sep 2014, Xiubo Li wrote: > > So you add BE/LE APIs according to the subject line, but you fail > again to tell WHY. If that would be the only issue .... > > > Signed-off-by: Xiubo Li <Li.Xiubo@...escale.com> > > --- > > drivers/clocksource/mmio.c | 44 > ++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 44 insertions(+) > > > > diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c > > index 1593ade..ddc5214 100644 > > --- a/drivers/clocksource/mmio.c > > +++ b/drivers/clocksource/mmio.c > > So you think that adding this to mmio.c is the solution to the > problem? > It's just one solution of this, and will be a little faster than the old one When reading the counter value. > Ever heard about function prototypes, header files and such? > Yes, this will be fixed later if this is acceptable. > > @@ -20,21 +20,65 @@ static inline struct clocksource_mmio > *to_mmio_clksrc(struct clocksource *c) > > return container_of(c, struct clocksource_mmio, clksrc); > > } > > > > +cycle_t clocksource_mmio_readl_up_be(struct clocksource *c) > > +{ > > + return (cycle_t)be32_to_cpu(readl_relaxed(to_mmio_clksrc(c)->reg)); > > +} > > + > > +cycle_t clocksource_mmio_readl_up_le(struct clocksource *c) > > +{ > > + return (cycle_t)le32_to_cpu(readl_relaxed(to_mmio_clksrc(c)->reg)); > > +} > > + > > cycle_t clocksource_mmio_readl_up(struct clocksource *c) > > { > > return (cycle_t)readl_relaxed(to_mmio_clksrc(c)->reg); > > } > > So now we have three global functions which provide access to the mmio > clocksource. And one of them is always redundant for a given compile > time endianess. You can't be serious about this... > Yes, any good suggestion about this ? I found whatever the method it is about the endianness will always be many Different voices from different people and found it hard to taste all of them. So firstly I just using the driver's local APIs. Thanks, BRs Xiubo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists