Eduardo Valentin <eduardo.valentin@xxxxxxxxx> writes: > 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 <tony@xxxxxxxxxxx> wrote: >> > > * Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> [091013 12:09]: >> > >> "Peter 'p2' De Schrijver" <peter.de-schrijver@xxxxxxxxx> writes: >> > >> >> > >> > From: De-Schrijver Peter (Nokia-D/Helsinki) <Peter.De-Schrijver@xxxxxxxxx> >> > >> > >> > >> > 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-schrijver@xxxxxxxxx> >> > >> >> > >> 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? I don't know any reason not to. This sounds like a good candiate for OMAP specific details in /proc/cpuinfo. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
