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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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