linux-kernel - Re: [rfc] exposing MMR's of on-chip peripherals for debugging purposes

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]

Message-ID: <8bd0f97a0801280510q42dbf5d3i947877b7e3454fe1@mail.gmail.com>
Date:	Mon, 28 Jan 2008 08:10:24 -0500
From:	"Mike Frysinger" <vapier.adi@...il.com>
To:	"richard kennedy" <richard@....demon.co.uk>
Cc:	bryan.wu@...log.com,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Bryan Wu" <cooloney.lkml@...il.com>
Subject: Re: [rfc] exposing MMR's of on-chip peripherals for debugging purposes

On Jan 28, 2008 8:04 AM, richard kennedy <richard@....demon.co.uk> wrote:
> Mike Frysinger wrote:
> > On Jan 28, 2008 5:40 AM, Bryan Wu <bryan.wu@...log.com> wrote:
> >> On Mon, 2008-01-28 at 05:16 -0500, Mike Frysinger wrote:
> >>> the trouble is that this file currently weighs in at ~1.8 megs.  this
> >>> is because it contains all the information for all Blackfin processors
> >>> we support (which currently, is about ~23 variants).  it's only going
> >>> to get bigger as we support more.  Bryan cringes at the thought of
> >>> submitting it to LKML :).  so i'm fishing around for alternatives ...
> >>> the code was originally developed against 2.6.21, so UIO was not a
> >>> possibility.  i'm still not sure if it is ... i'd have to research it
> >>> a bit more and play with things.
> >> The main reason I am not willing to submit this to mainline is the file
> >> size. It's almost the biggest file in the kernel source. And it will be
> >> bigger and bigger when more and more new Blackfin processors supported
> >> by Linux kernel.
> >
> > a quick check of current git shows it is significantly larger than any other ;)
> >
> >> My suggestion is:
> >> Or more deeper thought:
> >>  - we don't need all the MMR setup at the same time for debugging. for example, maybe for some developer, he/she only needs one driver MMR for debugging such as watchdog/usb/spi/i2c ....
> >
> > splitting things up doesnt really address the original issue: there's
> > a lot of info here to be kept in the kernel
> >
> >>  - How about split the debug MMR table to each drivers or processors?
> >>  - watchdog driver implements a debug FS interface for debugging watchdog MMR and other drivers implement their own things.
> >
> > this had been mentioned before as a possibility but shot down.  you do
> > not want to tie the creation of these debug files to anything as the
> > prevents independent development of any other drivers/application that
> > use the same peripheral.
>
> there is a lot of duplication in your file, but you could slim it down a
> bit if thats the only objection.

i imagine there's a ton of duplication ... the file is auto-generated
from XML files, so i could take a look at the autogeneration producing
unified code.

> so you could have a simple function to create all the COUNTER elements
> from a given base address, then each variant only needs call that saving
> you lots of LOC.

also a possibility ... just have to be wary of the parts that have
slightly different peripherals (like the UART).
-mike
--
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/