Hello Tony and Kevin, On Wed, Oct 14, 2009 at 11:44:07AM +0200, De-Schrijver Peter (Nokia-D/Helsinki) wrote: > On Tue, Oct 13, 2009 at 09:51:30PM +0200, ext Kevin Hilman wrote: > > On Tue, Oct 13, 2009 at 12:48 PM, Tony Lindgren <t...@atomide.com> wrote: > > > * Kevin Hilman <khil...@deeprootsystems.com> [091013 12:09]: > > >> "Peter 'p2' De Schrijver" <peter.de-schrij...@nokia.com> writes: > > >> > > >> > From: De-Schrijver Peter (Nokia-D/Helsinki) > > >> > <peter.de-schrij...@nokia.com> > > >> > > > >> > This patch exports the OMAP3 IDCODE, Production ID and Die ID to > > >> > userspace via > > >> > sysfs. This can be used to track down silicon specific issues. The > > >> > info is > > >> > exported via sysfs because it should be possible to include this in > > >> > corematic > > >> > dumps. > > >> > > > >> > Signed-off-by: Peter 'p2' De Schrijver <peter.de-schrij...@nokia.com> > > >> > > >> Please export these via debugfs. > > > > > > I don't think we want to export unique chip identifiers by default. > > > > > > > Right, which is why I suggested using debugfs, which is something that > > probably wouldn't be enabled/exported on default production kernels. > > > > Which is why I do not want it in debugfs as we log this info in > crash reports on devices which might not have debugfs enabled.
As Peter said here, this patch is to identify the chip from user land. So it is not really a debug tool, but a identification tool. Any good reason why we should not have it? Another thing is, it could go into /proc/cpuinfo. Currently I don't see any OMAP related info there, only ARM. Do you guys know why we don't put anything in /proc/cpuinfo? > > Cheers, > > Peter. > > -- > goa is a state of mind > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html BR, -- Eduardo Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
