From: "Mike Frysinger" <vapier.adi@gmail.com>
To: "Arnd Bergmann" <arnd@arndb.de>
Cc: bryan.wu@analog.com, "Andrew Morton" <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 1/5] Blackfin: blackfin architecture patch update
Date: Mon, 5 Mar 2007 21:09:05 -0500 [thread overview]
Message-ID: <8bd0f97a0703051809n1762e8e3gce4ddb7af8d3882a@mail.gmail.com> (raw)
In-Reply-To: <200703032330.50116.arnd@arndb.de>
On 3/3/07, Arnd Bergmann <arnd@arndb.de> wrote:
> > +#if defined(CONFIG_MTD_UCLINUX)
> > + /* generic memory mapped MTD driver */
> > + memory_mtd_end = memory_end;
> > +
> > + mtd_phys = _ramstart;
> > + mtd_size = PAGE_ALIGN(*((unsigned long *)(mtd_phys + 8)));
> > +
> > +# if defined(CONFIG_EXT2_FS) || defined(CONFIG_EXT3_FS)
> > + if (*((unsigned short *)(mtd_phys + 0x438)) == EXT2_SUPER_MAGIC)
> > + mtd_size =
> > + PAGE_ALIGN(*((unsigned long *)(mtd_phys + 0x404)) << 10);
> > +# endif
> > +
> > +# if defined(CONFIG_CRAMFS)
> > + if (*((unsigned long *)(mtd_phys)) == CRAMFS_MAGIC)
> > + mtd_size = PAGE_ALIGN(*((unsigned long *)(mtd_phys + 0x4)));
> > +# endif
> > +
> > +# if defined(CONFIG_ROMFS_FS)
> > + if (((unsigned long *)mtd_phys)[0] == ROMSB_WORD0
> > + && ((unsigned long *)mtd_phys)[1] == ROMSB_WORD1)
> > + mtd_size =
> > + PAGE_ALIGN(be32_to_cpu(((unsigned long *)mtd_phys)[2]));
>
> This detection seems to me like a strange thing to do in setup_arch().
> It should be possible to do this much later, at a point where the system
> is much less fragile and e.g. printk works. It could even be moved into
> some place in the mtd code itself, since other architectures might want
> to do the same thing.
the MTD code already does this ... the difference is that the blackfin
port changes the memory layout dynamically by relocating the rootfs
from the end of its data section to the end of memory ... that's why
it's done so early in the boot process, it shrinks the memory pool
available to the kernel allocator
> > +#define TCGETS 0x5401
> > +#define TCSETS 0x5402
> > +#define TCSETSW 0x5403
> > +#define TCSETSF 0x5404
> > +#define TCGETA 0x5405
> > +#define TCSETA 0x5406
> > +#define TCSETAW 0x5407
> > +#define TCSETAF 0x5408
> > +#define TCSBRK 0x5409
> > +#define TCXONC 0x540A
> > +#define TCFLSH 0x540B
> > +#define TIOCEXCL 0x540C
> > +#define TIOCNXCL 0x540D
> > +#define TIOCSCTTY 0x540E
> > +#define TIOCGPGRP 0x540F
> > +#define TIOCSPGRP 0x5410
> > +#define TIOCOUTQ 0x5411
> > +#define TIOCSTI 0x5412
> > +#define TIOCGWINSZ 0x5413
> > +#define TIOCSWINSZ 0x5414
> > +#define TIOCMGET 0x5415
> > +#define TIOCMBIS 0x5416
> > +#define TIOCMBIC 0x5417
> > +#define TIOCMSET 0x5418
> > +#define TIOCGSOFTCAR 0x5419
> > +#define TIOCSSOFTCAR 0x541A
> > +#define FIONREAD 0x541B
> > +#define TIOCINQ FIONREAD
> > +#define TIOCLINUX 0x541C
> > +#define TIOCCONS 0x541D
> > +#define TIOCGSERIAL 0x541E
> > +#define TIOCSSERIAL 0x541F
> > +#define TIOCPKT 0x5420
> > +#define FIONBIO 0x5421
> > +#define TIOCNOTTY 0x5422
> > +#define TIOCSETD 0x5423
> > +#define TIOCGETD 0x5424
> > +#define TCSBRKP 0x5425 /* Needed for POSIX tcsendbreak() */
> > +#define TIOCTTYGSTRUCT 0x5426 /* For debugging only */
> > +#define TIOCSBRK 0x5427 /* BSD compatibility */
> > +#define TIOCCBRK 0x5428 /* BSD compatibility */
> > +#define TIOCGSID 0x5429 /* Return the session ID of FD */
> > +#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of pty-mux
> device) */
> > +#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
>
> These look like another good candidate for an asm-generic version.
yeah, most everyone has the same ioctl values for terminal cruft
> > These macros allow us to work around hardware bugs when accessing the
> > registers by simply redefining the accessor to do something more
> > complex.
>
> If there is a bug in the hardware, the workaround belongs into the
> driver. You can then still define a special inline function to
> access that particular register.
not when it's an anomaly in a register that is not driver specific
(like the VR_CTL register), or it's a peripheral that has no generic
driver [yet] (like the SPORT or PPI)
-mike
next prev parent reply other threads:[~2007-03-06 2:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-01 4:14 Wu, Bryan
2007-03-03 20:38 ` Arnd Bergmann
2007-03-05 7:13 ` Wu, Bryan
2007-03-03 22:30 ` Arnd Bergmann
2007-03-03 22:50 ` bert hubert
2007-03-03 23:05 ` Arnd Bergmann
2007-03-05 6:54 ` Aubrey Li
2007-03-05 8:47 ` Arnd Bergmann
2007-03-05 9:19 ` Wu, Bryan
2007-03-05 16:43 ` Arnd Bergmann
2007-03-05 7:34 ` Wu, Bryan
2007-03-05 8:10 ` Arnd Bergmann
2007-03-06 2:09 ` Mike Frysinger [this message]
2007-03-05 9:23 ` Paul Mundt
2007-03-05 12:32 ` Bernd Schmidt
2007-03-05 12:39 ` Paul Mundt
2007-03-05 13:26 ` Robin Getz
2007-03-05 14:00 ` Paul Mundt
2007-03-05 16:29 ` Robin Getz
2007-03-05 17:32 ` Paul Mundt
2007-03-05 22:06 ` Robin Getz
2007-03-06 2:04 ` Mike Frysinger
2007-03-21 15:44 ` Mike Frysinger
2007-03-21 23:42 ` Paul Mundt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8bd0f97a0703051809n1762e8e3gce4ddb7af8d3882a@mail.gmail.com \
--to=vapier.adi@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bryan.wu@analog.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®