* Re: [RFC] [PATCH] watchdog_info separation and constify
From: Wim Van Sebroeck @ 2010-01-19 22:00 UTC (permalink / raw)
To: Alan Cox
Cc: Mark Brown, LKML, linuxppc-dev, uclinux-dist-devel, Joe Perches,
Russell King, Andrew Morton, linux-omap, Florian Fainelli
In-Reply-To: <20100119212755.72e81d24@lxorguk.ukuu.org.uk>
Hi Alan,
> > please comment on following patch.
>
> Why move them out - why not just make them const ?
There's 2 options:
1) we only make them const now. And we move them out later when we do the conversion to the generic watchdog api (which means that we will rip out the code for the open, release, write and ioctl handling of /dev/watchdog) or
2) we make them const and move them out of ioctl and then the ripping out of the code is much easier.
I opted for the second option.
Kind regards,
Wim.
^ permalink raw reply
* Re: [RFC] [PATCH] watchdog_info separation and constify
From: Joe Perches @ 2010-01-19 22:36 UTC (permalink / raw)
To: Mark Brown
Cc: LKML, linuxppc-dev, Wim Van Sebroeck, uclinux-dist-devel,
Russell King, Andrew Morton, linux-omap, Florian Fainelli,
Alan Cox
In-Reply-To: <20100119221647.GC29306@sirena.org.uk>
On Tue, 2010-01-19 at 22:16 +0000, Mark Brown wrote:
> On Tue, Jan 19, 2010 at 01:42:31PM -0800, Joe Perches wrote:
> > Maybe a standard #define WATCHDOG_NAME <foo>
> > .identity = WATCHGOD_NAME
>
> I don't really see that the indrection via the #define would buy us
> anything?
Maybe not, just a suggestion.
There are already 17 uses though.
It might have some value like DRV_NAME does or
any other frequent #define used in printks or
#include code.
It may be useful standardization prior to or post
some generic watchdog code consolidation.
$ grep -r --include=*.[ch] -Poh "^#define\s*\w+NAME\b" drivers | \
sed -r -e 's/\s+/ /g' | sort | uniq -c | sort -rn | head -10
334 #define DRV_NAME
137 #define DRIVER_NAME
59 #define MODULE_NAME
25 #define DRVNAME
21 #define DRV_MODULE_NAME
18 #define DEVICE_NAME
17 #define WATCHDOG_NAME
15 #define MY_NAME
12 #define BOARD_MAP_NAME
11 #define DSS_SUBSYS_NAME
^ permalink raw reply
* Re: [RFC] [PATCH] watchdog_info separation and constify
From: Mark Brown @ 2010-01-19 22:16 UTC (permalink / raw)
To: Joe Perches
Cc: LKML, linuxppc-dev, Wim Van Sebroeck, uclinux-dist-devel,
Russell King, Andrew Morton, linux-omap, Florian Fainelli,
Alan Cox
In-Reply-To: <1263937351.18117.69.camel@Joe-Laptop.home>
On Tue, Jan 19, 2010 at 01:42:31PM -0800, Joe Perches wrote:
> Maybe a standard #define WATCHDOG_NAME <foo>
> .identity = WATCHGOD_NAME
I don't really see that the indrection via the #define would buy us
anything?
^ permalink raw reply
* Re: [PATCH] powerpc/4xx: Add support for type 1 pci transactions on 4xx boards
From: Felix Radensky @ 2010-01-19 22:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Stef van Os, Stefan Roese, Feng Kan, linuxppc-dev
In-Reply-To: <1263444961.724.343.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2010-01-13 at 10:18 +1100, Benjamin Herrenschmidt wrote:
>
>> On Tue, 2010-01-12 at 15:09 +0100, Stef van Os wrote:
>>
>>> This patch adds type 1 PCI transactions to 4xx PCI code, enabling the
>>> discovery of
>>> devices behind a PCI bridge.
>>>
>> Your patch appears word wrapped and whitespace damaged...
>>
>> I'll fix it up manually this time around but please check your mailer
>> setup :-)
>>
>
> Allright, it's not quite that.
>
> I've looked at my docs, and it looks like older parts such as the 440EP
> do -not- take the config type in the low bit.
>
> More interestingly, they only generate config 0 cycles if you pass a bus
> number of 0 :-)
>
> So we'll need do do something a little bit different here. We probably
> need to indicate in the device-tree what kind of SoC we have (whether
> it supports the explicit bit to choose between type 0 and type 1 or
> not).
>
> If not, we should then set the "self_busno" field of the bridge to 0,
> causing indirect_pci to always use bus number 0 when trying to talk
> to the bus segment behind the bridge, whatever the linux bus number
> for it actually is.
>
> Now, we need to make a precise list here of what SoC uses what. 460xx
> seem to all support the explicit bit. 440EP doesn't. What else ?
>
> Somebody from AMCC can dbl check that ?
>
I've checked what platforms take configuration type in the lower bit:
405XX - no
440EP - no
440GR - no
440EPx/440GRx - no
440GP - yes
440GX - yes
440SP - yes
440SPe - yes
460XX - yes
The distinction between these groups is pretty clear in the device trees.
The members of the first group all have "ibm,plb-pci" property, and all
members of second group have "ibm,plb-pcix" property.
So only ppc4xx_probe_pcix_bridge() routine should be fixed.
Felix.
^ permalink raw reply
* Re: [PATCH] powerpc/4xx: Add support for type 1 pci transactions on 4xx boards
From: Benjamin Herrenschmidt @ 2010-01-19 22:57 UTC (permalink / raw)
To: Felix Radensky; +Cc: Stef van Os, Stefan Roese, Feng Kan, linuxppc-dev
In-Reply-To: <4B5637A6.5070600@embedded-sol.com>
On Wed, 2010-01-20 at 00:52 +0200, Felix Radensky wrote:
>
> 405XX - no
> 440EP - no
> 440GR - no
> 440EPx/440GRx - no
>
> 440GP - yes
> 440GX - yes
> 440SP - yes
> 440SPe - yes
> 460XX - yes
>
> The distinction between these groups is pretty clear in the device trees.
> The members of the first group all have "ibm,plb-pci" property, and all
> members of second group have "ibm,plb-pcix" property.
>
> So only ppc4xx_probe_pcix_bridge() routine should be fixed.
Ah cool, I hadn't noticed that it matched the cell type.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 02/11] fs_enet: Add FEC TX Alignment workaround for MPC5121
From: Stephen Rothwell @ 2010-01-19 23:42 UTC (permalink / raw)
To: David Miller; +Cc: kosmo, jrigby, netdev, linuxppc-dev, agust, dzu, wd
In-Reply-To: <20100119.123706.12493208.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 320 bytes --]
Hi Dave,
On Tue, 19 Jan 2010 12:37:06 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Well... where are the other 9 patches?
I think the other 9 are not network related, just PowerPC related.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Large physical address support on e500 platform
From: Alex Dubov @ 2010-01-20 1:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <DC402F23-C6B5-4F7E-B66D-F0AFCC298CEA@kernel.crashing.org>
> =0A> > So, the obvious question is, what is the current=0A> status of lar=
ge physical=0A> > address support on e500? Is it a problem in current=0A> g=
it version or is it=0A> > not ready yet?=0A> > =0A> > Thanks.=0A> =0A> Its =
possible that we've broken module/vmalloc support with=0A> "Large physical =
addressing".=A0 Its not something I've=0A> tried in a while.=A0 What kernel=
/git SHA are you using.=0A> =0A=0AI'm just pulling in from the main kernel =
tree git.=0AMy current version is 2.6.33-rc4-00193-gd1e4922-dirty,=0Abut it=
had not changed since 2.6.33-rc2=0A=0AI started from 2.6.32, but I don't r=
emember if I had a large PA=0Asupport enabled there.=0A=0A=0A=0A=0A __=
___________________________________________________________________________=
_____=0ASee what's on at the movies in your area. Find out now: http://au.m=
ovies.yahoo.com/session-times/
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Johnny Hung @ 2010-01-20 2:32 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: kernelnewbies, linux-mtd@lists.infradead.org, Ricard Wanderlof,
linuxppc-dev@lists.ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <20100119140600.GH16182@darwin>
2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
>
>> On Tue, 19 Jan 2010, Johnny Hung wrote:
>>
>>> Okay, I think the steps is below if my rootfs is ramdisk and configure
>>> files in jffs2,
>>>
>>> 1. cp /etc/* /mnt/mtd/etc/ =A0 =A0(/mnt/mtd is my jffs2 fs)
>>> 2. rm -rf /etc/*
>>> 3. make symbolic links from all /etc/xx to /mnt/mtd/etc/xxx
>>> 4. remake ramdisk rootfs
>>>
>>> It seems all files in ramdisk rootfs /etc all links to /mnt/mtd/etc/
>>> and try to modify these files is effective after reboot.
>>> But is this a common way in embedded linux ?
>>
Thanks, I understand.
>> In principle, but it is easier (and cleaner) to make a symbolic link fro=
m
>> (say) /etc -> /mnt/mtd/etc without linking every individual file and
>> directory.
>
> i totally agree with ricard when you want to move the entire directory
> to jffs2 and not only some selected files
>
>> You could also use a jffs2 file system in flash for your rootfs, that wa=
y
>> you wouldn't need a ramdisk at all.
>
> i'd also recommend you to consider if you really need the
> ramdisk. when using a ram disk its entire content is loaded to the RAM
> occupying space, even if you don't use certain files (or part of
> them). other filesystems are more efficient in this aspect.
> if the main purpose is to have a read only rootfs, i'd suggest a look
> at squashfs.
I consider to use ramdisk as rootfs because worry about wrong
operation in rootfs (is use jffs2 rootfs) and it will cause system
boot up failed.
Another query, does the syslogd/klogd log files also store in jffs2
rootfs? Write to jffs2 frequently will reduce flash life cycle.
BRs, H. Johnny
>
> --
> Matthias Kaehlcke
> Embedded Linux Developer
> Barcelona
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0La posibilidad de realizar un suenyo es lo
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 que hace que la vida sea interesante
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .''`.
> =A0 =A0using free software / Debian GNU/Linux | http://debian.org =A0: :'=
=A0:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0`. `'`
> gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0`-
>
^ permalink raw reply
* Re: [PATCH 02/11] fs_enet: Add FEC TX Alignment workaround for MPC5121
From: David Miller @ 2010-01-20 4:04 UTC (permalink / raw)
To: sfr; +Cc: kosmo, jrigby, netdev, linuxppc-dev, agust, dzu, wd
In-Reply-To: <20100120104225.3361e6c4.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 20 Jan 2010 10:42:25 +1100
> On Tue, 19 Jan 2010 12:37:06 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>>
>> Well... where are the other 9 patches?
>
> I think the other 9 are not network related, just PowerPC related.
Ok, but that's very confusing.
If it's meant to go into two different trees split the
patches up into two different series.
^ permalink raw reply
* linux-next: kvm tree build warning
From: Stephen Rothwell @ 2010-01-20 6:48 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti
Cc: linux-next, ppc-dev, linux-kernel, Alexander Graf
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
[Not sure what happened to the previous versions To/CC lists, sorry]
Hi all,
Today's linux-next build (powerpc allyesconfig) produced this warning:
arch/powerpc/kvm/book3s.c: In function '__kvmppc_vcpu_run':
arch/powerpc/kvm/book3s.c:1102: warning: 'ext_bkp.vrsave' may be used uninitialized in this function
Introduced by commit 2609c1d06b6a7952273fb33b33ad32aff0628146 ("KVM: PPC:
Add support for FPU/Altivec/VSX"). This *may* be a false positive but
will be a problem for normal builds where warnings are treated as errors
in arch/powerpc.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Ricard Wanderlof @ 2010-01-20 7:15 UTC (permalink / raw)
To: Johnny Hung
Cc: Ricard Wanderlöf, linux-embedded@vger.kernel.org,
kernelnewbies, linux-mtd@lists.infradead.org, Matthias Kaehlcke,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <cb9ecdfa1001191832k28961740qa825a8c8d5e631f2@mail.gmail.com>
On Wed, 20 Jan 2010, Johnny Hung wrote:
>> i'd also recommend you to consider if you really need the
>> ramdisk. when using a ram disk its entire content is loaded to the RAM
>> occupying space, even if you don't use certain files (or part of
>> them). other filesystems are more efficient in this aspect.
>> if the main purpose is to have a read only rootfs, i'd suggest a look
>> at squashfs.
>
> I consider to use ramdisk as rootfs because worry about wrong
> operation in rootfs (is use jffs2 rootfs) and it will cause system
> boot up failed.
You have a point, however, you could do two things to help:
a) Mount the root file system as read-only. That way you can never write=20
to it, unless you remount it read-write. But you can still reflash that=20
partition if you need to upgrade.
b) Register the mtd partition holding the root file system as read-only.
This is even more seecure as remounting the file system won't permit=20
writes. However, it also means you can't write to it for upgrading. (I
don't think the mtd core permits changing an already registered mtd=20
partition from readonly to writable, but I could be wrong.)
> Another query, does the syslogd/klogd log files also store in jffs2
> rootfs? Write to jffs2 frequently will reduce flash life cycle.
I think it is fairly common to have a combination of devices:
/ (root) is a readonly flash device (mtd partition)
/etc is a writable flash device (mtd partition)
/tmp and /var are ramdisks (tmpfs), so they are writable, but lost when
power is cycled.
/Ricard
--=20
Ricard Wolf Wanderl=F6f ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Matthias Kaehlcke @ 2010-01-20 7:12 UTC (permalink / raw)
To: Johnny Hung
Cc: kernelnewbies, linux-mtd@lists.infradead.org, Ricard Wanderlof,
linuxppc-dev@lists.ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <cb9ecdfa1001191832k28961740qa825a8c8d5e631f2@mail.gmail.com>
El Wed, Jan 20, 2010 at 10:32:15AM +0800 Johnny Hung ha dit:
> 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
> > El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
> >
> >> On Tue, 19 Jan 2010, Johnny Hung wrote:
> >>
> >>> Okay, I think the steps is below if my rootfs is ramdisk and configure
> >>> files in jffs2,
> >>>
> >>> 1. cp /etc/* /mnt/mtd/etc/ (/mnt/mtd is my jffs2 fs)
> >>> 2. rm -rf /etc/*
> >>> 3. make symbolic links from all /etc/xx to /mnt/mtd/etc/xxx
> >>> 4. remake ramdisk rootfs
> >>>
> >>> It seems all files in ramdisk rootfs /etc all links to /mnt/mtd/etc/
> >>> and try to modify these files is effective after reboot.
> >>> But is this a common way in embedded linux ?
> >>
>
> Thanks, I understand.
>
> >> In principle, but it is easier (and cleaner) to make a symbolic link from
> >> (say) /etc -> /mnt/mtd/etc without linking every individual file and
> >> directory.
> >
> > i totally agree with ricard when you want to move the entire directory
> > to jffs2 and not only some selected files
> >
> >> You could also use a jffs2 file system in flash for your rootfs, that way
> >> you wouldn't need a ramdisk at all.
> >
> > i'd also recommend you to consider if you really need the
> > ramdisk. when using a ram disk its entire content is loaded to the RAM
> > occupying space, even if you don't use certain files (or part of
> > them). other filesystems are more efficient in this aspect.
> > if the main purpose is to have a read only rootfs, i'd suggest a look
> > at squashfs.
>
> I consider to use ramdisk as rootfs because worry about wrong
> operation in rootfs (is use jffs2 rootfs) and it will cause system
> boot up failed.
you could set up a rootfs partition with a read-only file system
(squashfs, jffs2 mounted ro) and a second partition that's writable.
> Another query, does the syslogd/klogd log files also store in jffs2
> rootfs? Write to jffs2 frequently will reduce flash life cycle.
by default the log files will be written to /var/log, if this
directory happens to be on a jffs2 partition writes will go there and
produce wear out. to avoid this you could set up a small tmpfs (in
RAM) and mount it on /var
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
We can't solve problems by using the same kind
of thinking we used when we created them
(Albert Einstein)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Matthias Kaehlcke @ 2010-01-20 7:17 UTC (permalink / raw)
To: Ricard Wanderlof
Cc: Johnny Hung, kernelnewbies, linux-mtd@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <Pine.LNX.4.64.1001200809550.32263@lnxricardw.se.axis.com>
El Wed, Jan 20, 2010 at 08:15:01AM +0100 Ricard Wanderlof ha dit:
> On Wed, 20 Jan 2010, Johnny Hung wrote:
>
>>> i'd also recommend you to consider if you really need the
>>> ramdisk. when using a ram disk its entire content is loaded to the RAM
>>> occupying space, even if you don't use certain files (or part of
>>> them). other filesystems are more efficient in this aspect.
>>> if the main purpose is to have a read only rootfs, i'd suggest a look
>>> at squashfs.
>>
>> I consider to use ramdisk as rootfs because worry about wrong
>> operation in rootfs (is use jffs2 rootfs) and it will cause system
>> boot up failed.
>
> You have a point, however, you could do two things to help:
>
> a) Mount the root file system as read-only. That way you can never write
> to it, unless you remount it read-write. But you can still reflash that
> partition if you need to upgrade.
>
> b) Register the mtd partition holding the root file system as read-only.
> This is even more seecure as remounting the file system won't permit
> writes. However, it also means you can't write to it for upgrading. (I
> don't think the mtd core permits changing an already registered mtd
> partition from readonly to writable, but I could be wrong.)
AFAIK the mtd core doesn't permit changing a partition from ro to
rw. but if you happen to need to reflash the partition anyway, you can
load a tiny kernel modules that changes the flag indicating if a
partition is writable.
i once had to recurr to this solution and it works ;)
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
Tant qu'il y aura sur terre des hommes pour qui existe un concept
d' 'honneur national', la menace d'une nouvelle guerre subsistera
(B. Traven)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Marco Stornelli @ 2010-01-20 7:57 UTC (permalink / raw)
To: Johnny Hung
Cc: Ricard Wanderlof, linux-embedded@vger.kernel.org, kernelnewbies,
linux-mtd@lists.infradead.org, Matthias Kaehlcke,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <cb9ecdfa1001191832k28961740qa825a8c8d5e631f2@mail.gmail.com>
2010/1/20 Johnny Hung <johnny.hacking@gmail.com>:
> 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
>> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
>>
> I consider to use ramdisk as rootfs because worry about wrong
> operation in rootfs (is use jffs2 rootfs) and it will cause system
> boot up failed.
> Another query, does the syslogd/klogd log files also store in jffs2
> rootfs? Write to jffs2 frequently will reduce flash life cycle.
>
> BRs, H. Johnny
>>
>> --
In general a good splitting for rootfs could be: squashfs for rootfs,
tmpfs for volatile data (/tmp), ubifs (with a flash partition) for
"strong" permanent data (/etc, ....) and pramfs for "light" permanent
data (/var/log, .....).
I think you should "split" your rootfs. Ramdisk is an old approach
with some drawbacks.
Marco
^ permalink raw reply
* Re: [PATCH 02/11] fs_enet: Add FEC TX Alignment workaround for MPC5121
From: Wolfram Sang @ 2010-01-20 10:22 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: Piotr Ziecik, dzu, netdev, linuxppc-dev, John Rigby, wd
In-Reply-To: <1263932653-3634-3-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
> diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
> index 909b78d..a391219 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -587,6 +587,33 @@ void fs_cleanup_bds(struct net_device *dev)
>
> /**********************************************************************************/
>
> +static struct sk_buff *tx_skb_align_workaround(struct net_device *dev,
> + struct sk_buff *skb)
> +{
> + struct sk_buff *new_skb;
> +
> + /* Alloc new skb */
> + new_skb = dev_alloc_skb(ENET_RX_FRSIZE + 32);
> + if (!new_skb) {
> + printk(KERN_WARNING DRV_MODULE_NAME
> + ": %s Memory squeeze, dropping tx packet.\n",
> + dev->name);
I understand this type of printk fits to the rest of the code, I just wonder if
new (and patched) printouts shouldn't be converted to dev_*? Might be one line
then, and more consistent to what other drivers produce.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Matthias Kaehlcke @ 2010-01-20 10:21 UTC (permalink / raw)
To: Marco Stornelli
Cc: Ricard Wanderlof, linux-embedded@vger.kernel.org, kernelnewbies,
Johnny Hung, linux-mtd@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2ea1731b1001192357r72d627e2gb36d71f23fd69b2e@mail.gmail.com>
El Wed, Jan 20, 2010 at 08:57:44AM +0100 Marco Stornelli ha dit:
> 2010/1/20 Johnny Hung <johnny.hacking@gmail.com>:
> > 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
> >> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
> >>
> > I consider to use ramdisk as rootfs because worry about wrong
> > operation in rootfs (is use jffs2 rootfs) and it will cause system
> > boot up failed.
> > Another query, does the syslogd/klogd log files also store in jffs2
> > rootfs? Write to jffs2 frequently will reduce flash life cycle.
> >
> > BRs, H. Johnny
> >>
> >> --
>
> In general a good splitting for rootfs could be: squashfs for rootfs,
> tmpfs for volatile data (/tmp), ubifs (with a flash partition) for
> "strong" permanent data (/etc, ....) and pramfs for "light" permanent
> data (/var/log, .....).
if ubifs is a good choice depends on the size of the partition, iirc
it has a significant overhead for very small partitions.
once using ubi it could be interesting to set up the read-only rootfs
partition upon ubi in order to spread the wear out over a maximum of blocks.
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
You can chain me, you can torture me, you can even
destroy this body, but you will never imprison my mind
(Mahatma Gandhi)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: linux-next: kvm tree build warning
From: Alexander Graf @ 2010-01-20 10:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Marcelo Tosatti, ppc-dev, linux-next, Avi Kivity, linux-kernel
In-Reply-To: <20100120174814.43195995.sfr@canb.auug.org.au>
On 20.01.2010, at 07:48, Stephen Rothwell wrote:
> [Not sure what happened to the previous versions To/CC lists, sorry]
>=20
> Hi all,
>=20
> Today's linux-next build (powerpc allyesconfig) produced this warning:
>=20
> arch/powerpc/kvm/book3s.c: In function '__kvmppc_vcpu_run':
> arch/powerpc/kvm/book3s.c:1102: warning: 'ext_bkp.vrsave' may be used =
uninitialized in this function
>=20
> Introduced by commit 2609c1d06b6a7952273fb33b33ad32aff0628146 ("KVM: =
PPC:
> Add support for FPU/Altivec/VSX"). This *may* be a false positive but
> will be a problem for normal builds where warnings are treated as =
errors
> in arch/powerpc.
This is odd. The same function saves and restores ext_bkp.vrsave under a =
common condition:
if (save_vec) {
if (current->thread.regs->msr & MSR_VEC)
giveup_altivec(current);
memcpy(ext_bkp.vr, current->thread.vr, =
sizeof(ext_bkp.vr));
ext_bkp.vscr =3D current->thread.vscr;
ext_bkp.vrsave =3D current->thread.vrsave;
}
[...]
if (save_vec && current->thread.used_vr) {
memcpy(current->thread.vr, ext_bkp.vr, =
sizeof(ext_bkp.vr));
current->thread.vscr =3D ext_bkp.vscr;
current->thread.vrsave =3D ext_bkp.vrsave;
}
So there can't be a case where ext_bkp.vrsave is read, but not written =
to before, which is what this warning implies, right?
Also, why doesn't gcc complain about vscr too then? They're both used in =
the very same if statement.
Additionally, while compiling locally I looked for warnings and didn't =
spot any. So apparently our compiler versions / options don't match. =
Which version of gcc are you using? I assume a gcc bug.
$ gcc --version
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
Alex=
^ permalink raw reply
* Re: [PATCH 06/11] mtd: Add MPC5121 NAND Flash Controller driver
From: Wolfram Sang @ 2010-01-20 10:49 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, linux-mtd, wd, dzu, Piotr Ziecik
In-Reply-To: <1263932653-3634-7-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Tue, Jan 19, 2010 at 09:24:08PM +0100, Anatolij Gustschin wrote:
> From: Piotr Ziecik <kosmo@semihalf.com>
>
> Adds NAND Flash Controller driver for MPC5121 Revision 2.
> All device features, except hardware ECC and power management,
> are supported.
>
> Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: <linux-mtd@lists.infradead.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: John Rigby <jcrigby@gmail.com>
> ---
Please include a logfile with changes since the last version. This really
helps.
> +static int __init mpc5121_nfc_probe(struct of_device *op,
> + const struct of_device_id *match)
[...]
> +{
> + /* Support external chip-select logic on ADS5121 board */
> + rootnode = of_find_node_by_path("/");
> + if (of_device_is_compatible(rootnode, "fsl,mpc5121ads")) {
> + retval = ads5121_chipselect_init(mtd);
> + if (retval) {
> + dev_err(dev, "Chipselect init error!\n");
> + of_node_put(rootnode);
> + return retval;
> + }
> +
> + chip->select_chip = ads5121_select_chip;
> + }
> + of_node_put(rootnode);
If we have to live with the platform-stuff being in the driver, maybe a table
having the compatible-string and an init-function pointer per entry will make
it scale better with the number of boards?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 05/11] rtc: Add MPC5121 Real time clock driver
From: Wolfram Sang @ 2010-01-20 11:01 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: Piotr Ziecik, dzu, rtc-linux, linuxppc-dev, John Rigby, wd
In-Reply-To: <1263932653-3634-6-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]
On Tue, Jan 19, 2010 at 09:24:07PM +0100, Anatolij Gustschin wrote:
> From: John Rigby <jrigby@freescale.com>
>
> Based on Domen Puncer's rtc driver for 5200 posted to
> the ppclinux mailing list:
> http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11675
> but never commited anywhere.
>
> Changes to Domen's original:
>
> Changed filenames/routine names from mpc5200* to mpc5121*
> Changed match to only care about compatible and use "fsl,"
> convention for compatible.
>
> Make alarms more sane by dealing with lack of second alarm resolution.
>
> Deal with the fact that most of the 5121 rtc registers are not persistent
> across a reset even with a battery attached:
>
> Use actual_time register for time keeping
> and target_time register as an offset to linux time
>
> The target_time register would normally be used for hibernation
> but hibernation does not work on current silicon
Last time, we discussed if it makes sense to rename it to mpc5xxx, as the rtc
is quite similar to the mpc5200 one. I then checked and parts of the
differences include that it is not possible on a 5200 to use the tricks to keep
the RTC persistent across resets. Thus, I think the patch is okay with not
supporting the 5200. Its rtc seems pretty useless.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 01/11] fs_enet: Add support for MPC512x to fs_enet driver
From: Anatolij Gustschin @ 2010-01-20 11:20 UTC (permalink / raw)
To: Scott Wood; +Cc: Piotr Ziecik, dzu, netdev, linuxppc-dev, John Rigby, wd
In-Reply-To: <4B561AA3.7040506@freescale.com>
Scott Wood <scottwood@freescale.com> wrote:
> > + void __iomem *fec_fun_code;
> > + void __iomem *fec_r_hash;
> > + void __iomem *fec_x_cntrl;
> > + void __iomem *fec_dma_control;
> > +};
>
> Why void and not the specific type?
Ok, I will fix it for using u32 __iomem *.
> > static void set_promiscuous_mode(struct net_device *dev)
> > {
> > struct fs_enet_private *fep = netdev_priv(dev);
> > - fec_t __iomem *fecp = fep->fec.fecp;
> > + struct reg_tbl *fecp = fep->fec.rtbl;
>
> Hmm, having something called "fecp" that is a different type than other
> "fecp"s could be confusing.
Ok, I will use 'regp' instead of 'fecp' then.
> > @@ -134,6 +143,20 @@ static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
> > if (!fec->fecp)
> > goto out_fec;
> >
> > + if (of_device_is_compatible(ofdev->node, "fsl,mpc5121-fec-mdio")) {
>
> You can put a data pointer in the of_platform match struct, instead of
> re-checking the compatible.
.data pointer in 'fs_enet_mdio_fec_match' is already used for
mpc5xxx_get_bus_frequency(). Setting .data to some sort of FEC ID in
match struct for "fsl,pq1-fec-mdio" would be confusing to.
Would a simple
if (!strncmp(match->compatible, "fsl,mpc5121-fec-mdio",
sizeof(match->compatible))) {
suffice here?
Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc/4xx: Add support for type 1 pci transactions on 4xx boards
From: Felix Radensky @ 2010-01-20 11:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Stef van Os, Stefan Roese, Feng Kan, linuxppc-dev
In-Reply-To: <1263941873.724.524.camel@pasglop>
Hi, Stef
Benjamin Herrenschmidt wrote:
> On Wed, 2010-01-20 at 00:52 +0200, Felix Radensky wrote:
>
>> 405XX - no
>> 440EP - no
>> 440GR - no
>> 440EPx/440GRx - no
>>
>> 440GP - yes
>> 440GX - yes
>> 440SP - yes
>> 440SPe - yes
>> 460XX - yes
>>
>> The distinction between these groups is pretty clear in the device trees.
>> The members of the first group all have "ibm,plb-pci" property, and all
>> members of second group have "ibm,plb-pcix" property.
>>
>> So only ppc4xx_probe_pcix_bridge() routine should be fixed.
>>
>
> Ah cool, I hadn't noticed that it matched the cell type.
>
>
Can you please send an updated patch.
Thanks a lot.
Felix.
^ permalink raw reply
* Re: [PATCH 0/11] Update support for MPC512x
From: Wolfram Sang @ 2010-01-20 11:22 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: wd, dzu, netdev, linux-usb, linuxppc-dev, linux-mtd, linux-i2c,
rtc-linux, Dan Williams
In-Reply-To: <1263932653-3634-1-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]
> The patches are based on v2.6.33-rc4 and cover the following
> items:
The USB-patch needs two patches from linux-next. For convenience, don't you
have a git-tree somewhere? :)
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 03/11] powerpc/mpc5121: Add machine restart support
From: Wolfram Sang @ 2010-01-20 11:28 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, wd, dzu, Piotr Ziecik
In-Reply-To: <1263932653-3634-4-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 4776 bytes --]
On Tue, Jan 19, 2010 at 09:24:05PM +0100, Anatolij Gustschin wrote:
> Add reset module registers representation and
> machine restart callback for mpc5121 platform.
>
> Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: John Rigby <jcrigby@gmail.com>
Looks good to me. Minor nits below.
> ---
> arch/powerpc/include/asm/mpc5xxx.h | 14 +++++++++-
> arch/powerpc/platforms/512x/mpc5121_ads.c | 1 +
> arch/powerpc/platforms/512x/mpc5121_generic.c | 1 +
> arch/powerpc/platforms/512x/mpc512x.h | 1 +
> arch/powerpc/platforms/512x/mpc512x_shared.c | 35 +++++++++++++++++++++++++
> 5 files changed, 51 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mpc5xxx.h b/arch/powerpc/include/asm/mpc5xxx.h
> index 5ce9c5f..0004986 100644
> --- a/arch/powerpc/include/asm/mpc5xxx.h
> +++ b/arch/powerpc/include/asm/mpc5xxx.h
> @@ -18,5 +18,17 @@
>
> extern unsigned long mpc5xxx_get_bus_frequency(struct device_node *node);
>
> -#endif /* __ASM_POWERPC_MPC5xxx_H__ */
> +/* MPC512x Reset module registers */
> +struct mpc512x_reset_module {
> + u32 rcwlr; /* Reset Configuration Word Low Register */
> + u32 rcwhr; /* Reset Configuration Word High Register */
> + u32 reserved1;
> + u32 reserved2;
> + u32 rsr; /* Reset Status Register */
> + u32 rmr; /* Reset Mode Register */
> + u32 rpr; /* Reset Protection Register */
> + u32 rcr; /* Reset Control Register */
> + u32 rcer; /* Reset Control Enable Register */
> +};
>
> +#endif /* __ASM_POWERPC_MPC5xxx_H__ */
> diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c b/arch/powerpc/platforms/512x/mpc5121_ads.c
> index 441abc4..2f40404 100644
> --- a/arch/powerpc/platforms/512x/mpc5121_ads.c
> +++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
> @@ -68,4 +68,5 @@ define_machine(mpc5121_ads) {
> .init_IRQ = mpc5121_ads_init_IRQ,
> .get_irq = ipic_get_irq,
> .calibrate_decr = generic_calibrate_decr,
> + .restart = mpc512x_restart,
> };
> diff --git a/arch/powerpc/platforms/512x/mpc5121_generic.c b/arch/powerpc/platforms/512x/mpc5121_generic.c
> index 2479de9..de4c3f7 100644
> --- a/arch/powerpc/platforms/512x/mpc5121_generic.c
> +++ b/arch/powerpc/platforms/512x/mpc5121_generic.c
> @@ -55,4 +55,5 @@ define_machine(mpc5121_generic) {
> .init_IRQ = mpc512x_init_IRQ,
> .get_irq = ipic_get_irq,
> .calibrate_decr = generic_calibrate_decr,
> + .restart = mpc512x_restart,
> };
> diff --git a/arch/powerpc/platforms/512x/mpc512x.h b/arch/powerpc/platforms/512x/mpc512x.h
> index 22a5352..c38875c 100644
> --- a/arch/powerpc/platforms/512x/mpc512x.h
> +++ b/arch/powerpc/platforms/512x/mpc512x.h
> @@ -12,5 +12,6 @@
> #ifndef __MPC512X_H__
> #define __MPC512X_H__
> extern void __init mpc512x_init_IRQ(void);
> +extern void mpc512x_restart(char *cmd);
> void __init mpc512x_declare_of_platform_devices(void);
> #endif /* __MPC512X_H__ */
> diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
> index 434d683..8a0d577 100644
> --- a/arch/powerpc/platforms/512x/mpc512x_shared.c
> +++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
> @@ -21,9 +21,44 @@
> #include <asm/ipic.h>
> #include <asm/prom.h>
> #include <asm/time.h>
> +#include <asm/mpc5xxx.h>
>
> #include "mpc512x.h"
>
> +static void __iomem *reset_module_base;
type here also?
> +
> +static int __init mpc512x_restart_init(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-reset");
> + if (!np)
> + return -1;
> +
> + reset_module_base = of_iomap(np, 0);
> + of_node_put(np);
> +
> + return 0;
> +}
> +
Drop this empty line?
> +arch_initcall(mpc512x_restart_init);
> +
> +void mpc512x_restart(char *cmd)
> +{
> + struct mpc512x_reset_module *rm = reset_module_base;
> +
> + if (rm) {
> + /* Enable software reset "RSTE" */
> + out_be32(&rm->rpr, 0x52535445);
> + /* Set software hard reset */
> + out_be32(&rm->rcr, 0x2);
> + } else {
> + printk(KERN_ERR ": Restart module not mapped.\n");
The colon is a leftover?
> + }
> + for (;;)
> + ;
> +}
> +
> void __init mpc512x_init_IRQ(void)
> {
> struct device_node *np;
> --
> 1.5.6.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Marco Stornelli @ 2010-01-20 11:54 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Ricard Wanderlof, linux-embedded@vger.kernel.org, kernelnewbies,
Johnny Hung, linux-mtd@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20100120102145.GV16182@darwin>
2010/1/20 Matthias Kaehlcke <matthias@kaehlcke.net>:
> El Wed, Jan 20, 2010 at 08:57:44AM +0100 Marco Stornelli ha dit:
>
>> 2010/1/20 Johnny Hung <johnny.hacking@gmail.com>:
>> > 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
>> >> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
>> >>
>> > I consider to use ramdisk as rootfs because worry about wrong
>> > operation in rootfs (is use jffs2 rootfs) and it will cause system
>> > boot up failed.
>> > Another query, does the syslogd/klogd log files also store in jffs2
>> > rootfs? Write to jffs2 frequently will reduce flash life cycle.
>> >
>> > BRs, H. Johnny
>> >>
>> >> --
>>
>> In general a good splitting for rootfs could be: squashfs for rootfs,
>> tmpfs for volatile data (/tmp), ubifs (with a flash partition) for
>> "strong" permanent data (/etc, ....) and pramfs for "light" permanent
>> data (/var/log, .....).
>
> if ubifs is a good choice depends on the size of the partition, iirc
> it has a significant overhead for very small partitions.
>
> once using ubi it could be interesting to set up the read-only rootfs
> partition upon ubi in order to spread the wear out over a maximum of blocks.
>
I don't know the size constraints of Johnny, so it can be useful to use jffs2.
Marco
^ permalink raw reply
* Re: linux-next: kvm tree build warning
From: Stephen Rothwell @ 2010-01-20 13:01 UTC (permalink / raw)
To: Alexander Graf
Cc: Marcelo Tosatti, ppc-dev, linux-next, Avi Kivity, linux-kernel
In-Reply-To: <3727B46C-0197-47A4-AF41-023517C15752@suse.de>
[-- Attachment #1: Type: text/plain, Size: 928 bytes --]
Hi Alex,
On Wed, 20 Jan 2010 11:42:28 +0100 Alexander Graf <agraf@suse.de> wrote:
>
> This is odd. The same function saves and restores ext_bkp.vrsave under a common condition:
>
> So there can't be a case where ext_bkp.vrsave is read, but not written to before, which is what this warning implies, right?
Right.
> Also, why doesn't gcc complain about vscr too then? They're both used in the very same if statement.
I have no idea how gcc makes these decisions. :-(
> Additionally, while compiling locally I looked for warnings and didn't spot any. So apparently our compiler versions / options don't match. Which version of gcc are you using? I assume a gcc bug.
>
> $ gcc --version
> gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
I use a 4.4.0 cross compiler (I should update it).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox