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] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 7 Jan 2014 12:12:39 -0800
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:	"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Mark Rutland <Mark.Rutland@....com>,
	Kumar Gala <galak@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC

On 01/07, Lorenzo Pieralisi wrote:
> 
> Not sure this binding (cache node) belongs in cpus.txt
> 
> I am working on defining cache bindings for ARM within the C-state
> standardization effort:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/215543.html

Thanks I'll take a look.

> 
> > +
> > +	Description: Describes a cache in an ARM based system
> > +
> > +	- compatible
> > +		Usage: required
> > +		Value type: <string>
> > +		Definition: shall contain at least "cache"
> 
> It is a bit vague, can't we just follow the ePAPR compatible definition ?
> See posting above.

Hm.. I thought this did follow the ePAPR spec. I see 'compatible,
required, string, A standard property. The value shall include
the string "cache".' Looks the same?

And I see 'cache-level, required, u32, Specifies the level in the
cache hierarchy. For example, a level 2 cache has a value of
<2>.'

> 
> > +
> > +	- cache-level
> > +		Usage: required
> > +		Value type: <u32>
> > +		Definition: level in the cache heirachy
> 
> "hierarchy".

Thanks.

> I have a problem with the cache level definition, and in
> particular the numbering, ie what the level number represents. If we
> mean the cache level seen through the CLIDR and co., it is hard to use
> it for shared caches since the level seen by different CPUs can actually
> be different, or put it differently the level number might not be unique for
> a shared cache. I need to think about a proper way to sort this out.
> 

Ok. I don't even use this property in my driver. All I really
need is the phandle from cpus pointing to the L2 and the
interrupts property in the L2 node.

How do you want to proceed here? If your cache binding goes
through I would just need to add the interrupts part. Or you
could even add that part in the same patch, you could have my
signed-off-by for that.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ