* [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
From: Tom Warren @ 2011-10-31 22:54 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ1JVw=wMUoFc9Hyf_Q4cUJd5QXUwXtzshhW3QPq7uOGBA@mail.gmail.com>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 3/3] monitor: add ability to dump SLB entries
From: Nishanth Aravamudan @ 2011-10-31 22:53 UTC (permalink / raw)
To: Alexander Graf, qemu-devel, qemu-ppc
In-Reply-To: <20111031041412.GG9698@truffala.fritz.box>
On 31.10.2011 [15:14:12 +1100], David Gibson wrote:
> Good points below. I forgot to CC Nish, the original patch author on
> my post, so I've added him to the list now.
>
> Nish, can you correct these problems and resend the patch please?
Yep, I'll work on this shortly.
> On Mon, Oct 31, 2011 at 04:35:54AM +0100, Alexander Graf wrote:
> >
> > On 31.10.2011, at 04:16, David Gibson wrote:
> >
> > > From: Nishanth Aravamudan <nacc@us.ibm.com>
> > >
> > > When run with a PPC Book3S (server) CPU Currently 'info tlb' in the
> > > qemu monitor reports "dump_mmu: unimplemented". However, during
> > > bringup work, it can be quite handy to have the SLB entries, which are
> > > available in the CPUPPCState. This patch adds an implementation of
> > > info tlb for book3s, which dumps the SLB.
> > >
> > > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > ---
> > > target-ppc/helper.c | 32 +++++++++++++++++++++++++++-----
> > > 1 files changed, 27 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/target-ppc/helper.c b/target-ppc/helper.c
> > > index 137a494..29c7050 100644
> > > --- a/target-ppc/helper.c
> > > +++ b/target-ppc/helper.c
> > > @@ -1545,14 +1545,36 @@ static void mmubooke206_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
> > > }
> > > }
> > >
> > > +static void mmubooks_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
> > > + CPUState *env)
> > > +{
> > > + int i;
> > > + uint64_t slbe, slbv;
> > > +
> > > + cpu_synchronize_state(env);
> > > +
> > > + cpu_fprintf(f, "SLB\tESID\t\t\tVSID\n");
> > > + for (i = 0; i < env->slb_nr; i++) {
> > > + slbe = env->slb[i].esid;
> > > + slbv = env->slb[i].vsid;
> >
> > From cpu.h:
> >
> > #if defined(TARGET_PPC64)
> > /* Address space register */
> > target_ulong asr;
> > /* PowerPC 64 SLB area */
> > ppc_slb_t slb[64];
> > int slb_nr;
> > #endif
Being unfamiliar with qemu's coding style (and not immediately seeing it
in CODING_STYLE), would the right approach be to wrap this definition in
an #if defined(TARGET_PPC64)?
> > > + if (slbe == 0 && slbv == 0) {
> > > + continue;
> > > + }
> > > + cpu_fprintf(f, "%d\t0x%016" PRIx64 "\t0x%016" PRIx64 "\n",
> > > + i, slbe, slbv);
> > > + }
> > > +}
> > > +
> > > void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env)
> > > {
> > > - switch (env->mmu_model) {
> > > - case POWERPC_MMU_BOOKE206:
> > > + if (env->mmu_model == POWERPC_MMU_BOOKE206) {
> > > mmubooke206_dump_mmu(f, cpu_fprintf, env);
> > > - break;
> > > - default:
> > > - cpu_fprintf(f, "%s: unimplemented\n", __func__);
> > > + } else {
> > > + if ((env->mmu_model & POWERPC_MMU_64B) != 0) {
> >
> > I would actually prefer to explicitly keep the switch and match on
> > all implementations explicitly. Also, have you verified this works
> > without CONFIG_PPC64 set? In cpu.h I see the following:
> >
> > #if defined(TARGET_PPC64)
> > #define POWERPC_MMU_64 0x00010000
> > #define POWERPC_MMU_1TSEG 0x00020000
> > /* 64 bits PowerPC MMU */
> > POWERPC_MMU_64B = POWERPC_MMU_64 | 0x00000001,
> > /* 620 variant (no segment exceptions) */
> > POWERPC_MMU_620 = POWERPC_MMU_64 | 0x00000002,
> > /* Architecture 2.06 variant */
> > POWERPC_MMU_2_06 = POWERPC_MMU_64 | POWERPC_MMU_1TSEG | 0x00000003,
> > #endif /* defined(TARGET_PPC64) */
> >
> > So POWERPC_MMU_64B shouldn't be defined for qemu-system-ppc.
And similarly here, only have the MMU_2_06 and MMU_64B cases in the
switch be defined #if defined(TARGET_PPC64)?
Basically, asking if #ifdefs in the middle of functions are ok :)
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC/PATCH 5/7] x86, mm: Use max_low_pfn for ZONE_NORMAL on 64-bit
From: David Rientjes @ 2011-10-31 22:54 UTC (permalink / raw)
To: Pekka Enberg; +Cc: x86, linux-kernel, Tejun Heo, Yinghai Lu, H. Peter Anvin
In-Reply-To: <1319811801-1725-5-git-send-email-penberg@kernel.org>
On Fri, 28 Oct 2011, Pekka Enberg wrote:
> 64-bit has no highmem so max_low_pfn is always the same as 'max_pfn'.
>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Cc: H. Peter Anvin <hpa@linux.intel.com>
> Cc: David Rientjes <rientjes@google.com>
> Signed-off-by: Pekka Enberg <penberg@kernel.org>
Acked-by: David Rientjes <rientjes@google.com>
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFwnVZ-mK3FChvFn778Z-cT107f4v-h0CDmwkP88=Z9aHA@mail.gmail.com>
On 10/31/2011 03:52 PM, Linus Torvalds wrote:
>
> Save it in the commit we generate. BAM! Useful, readable, permanent,
> and independently verifiable.
>
Note: this means creating a commit even for a fast-forward merge. Not
that there is any technical problem with that, of course.
-hpa
^ permalink raw reply
* orion/kirkwood and device tree
From: Russell King - ARM Linux @ 2011-10-31 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110312350.28475.michael@walle.cc>
On Mon, Oct 31, 2011 at 11:50:28PM +0100, Michael Walle wrote:
> Hi Jason and all,
>
> Sorry for being quiet such a long time, much work to do here..
>
> Am Montag 31 Oktober 2011, 17:40:42 schrieb Andrew Lunn:
> > > I wish. :-) dreamplug support just made it into u-boot. So, now I
> > > just have to babysit it until 2011.12 / 2012.01 release. I should have
> > > some more cycles to dedicate to Linux/dreamplug in the coming months.
> >
> > Is uboot support necessary? I cannot use jtag on my device, so i'm
> > reluctant to upgrade uboot. I hope it is possible to append the dt to
> > kernel image, at least for development work.
> iirc, i've seen some patches around to add support for appended device trees.
> dunno if they made it upstream, though.
It was merged during this merge window:
commit b90b9a38251e9c89c34179eccde57411ceb5f1aa
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Tue Sep 13 22:37:07 2011 -0400
ARM: zImage: allow supplementing appended DTB with traditional ATAG data
^ permalink raw reply
* Re: [RFC/PATCH 3/7] x86, mm: Use max_pfn instead of highend_pfn
From: David Rientjes @ 2011-10-31 22:54 UTC (permalink / raw)
To: Pekka Enberg; +Cc: x86, linux-kernel, Tejun Heo, Yinghai Lu, H. Peter Anvin
In-Reply-To: <1319811801-1725-3-git-send-email-penberg@kernel.org>
On Fri, 28 Oct 2011, Pekka Enberg wrote:
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index 434c97d..6101894 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -54,7 +54,7 @@
> #include <asm/page_types.h>
> #include <asm/init.h>
>
> -unsigned long highstart_pfn, highend_pfn;
> +unsigned long highstart_pfn;
>
> static noinline int do_test_wp_bit(void);
>
This shouldn't build with a CONFIG_NUMA i386 config, highend_pfn is used
in arch/x86/mm/numa_32.c.
^ permalink raw reply
* Re: [PATCH] udf : fix metadata/mirror address print
From: Jan Kara @ 2011-10-31 22:53 UTC (permalink / raw)
To: Namjae Jeon; +Cc: jack, linux-kernel, Ashish Sangwan
In-Reply-To: <1320074740-1923-1-git-send-email-linkinjeon@gmail.com>
On Tue 01-11-11 00:25:40, Namjae Jeon wrote:
> I found some bug in Skip-mirror-metadata-FE-loading-when-metadata-FE-is-ok patch
> So I try to fix metadata/mirror address print.
Thanks. I've folded this patch into your previous one.
Honza
>
> Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
> Signed-off-by: Ashish Sangwan <ashishsangwan2@gmail.com>
> ---
> fs/udf/super.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index b4921ab..dfe043a 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -860,7 +860,7 @@ static int udf_load_metadata_files(struct super_block *sb, int partition)
>
> /* metadata address */
> udf_debug("Metadata file location: block = %d part = %d\n",
> - addr.logicalBlockNum, addr.partitionReferenceNum);
> + mdata->s_meta_file_loc, map->s_partition_num);
>
> mdata->s_metadata_fe = udf_find_metadata_inode_efe(sb,
> mdata->s_meta_file_loc, map->s_partition_num);
> @@ -868,7 +868,7 @@ static int udf_load_metadata_files(struct super_block *sb, int partition)
> if (mdata->s_metadata_fe == NULL) {
> /* mirror file entry */
> udf_debug("Mirror metadata file location: block = %d part = %d\n",
> - addr.logicalBlockNum, addr.partitionReferenceNum);
> + mdata->s_mirror_file_loc, map->s_partition_num);
>
> mdata->s_mirror_fe = udf_find_metadata_inode_efe(sb,
> mdata->s_mirror_file_loc, map->s_partition_num);
> --
> 1.7.4.4
>
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply
* Re: [RFC/PATCH 4/7] x86, mm: Wrap ZONE_DMA32 with CONFIG_ZONE_DMA32
From: David Rientjes @ 2011-10-31 22:52 UTC (permalink / raw)
To: Pekka Enberg
Cc: x86, linux-kernel, Tejun Heo, Yinghai Lu, H. Peter Anvin,
Arun Sharma
In-Reply-To: <1319811801-1725-4-git-send-email-penberg@kernel.org>
On Fri, 28 Oct 2011, Pekka Enberg wrote:
> In preparation for unifying 32-bit and 64-bit zone_sizes_init() make sure
> ZONE_DMA32 is wrapped in CONFIG_ZONE_DMA32.
>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Cc: H. Peter Anvin <hpa@linux.intel.com>
> Cc: David Rientjes <rientjes@google.com>
> Signed-off-by: Pekka Enberg <penberg@kernel.org>
Acked-by: David Rientjes <rientjes@google.com>
Adding Arun Sharma to the cc, he was interested in disabling
CONFIG_ZONE_DMA32 and I believe carries this patch internally (as we do).
> ---
> arch/x86/mm/init_64.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 3ddda59..a9214e6 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -620,7 +620,9 @@ static void __init zone_sizes_init(void)
> #ifdef CONFIG_ZONE_DMA
> max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
> #endif
> +#ifdef CONFIG_ZONE_DMA32
> max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
> +#endif
> max_zone_pfns[ZONE_NORMAL] = max_pfn;
>
> free_area_init_nodes(max_zone_pfns);
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vzkggok6u.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 3:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> So nobody is worried about this (quoting from my earlier message)?
No, because you haven't been reading what we write.
The tag is useless.
The information *in* the tag is not. But it shouldn't be saved in the
tag (or note, or whatever). Because that's just an annoying place for
it to be, with no upside.
Save it in the commit we generate. BAM! Useful, readable, permanent,
and independently verifiable.
And the advantage is that we can make that same mechanism add
"maintainer notes" to the merge message too. Right now some
maintainers write good notes about what the merge will bring in, but
they are basically lost, because git is so good at merging and doesn't
even stop to ask people to edit the merge message.
Linus
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:51 UTC (permalink / raw)
To: Ted Ts'o, Junio C Hamano, Linus Torvalds, git,
James Bottomley
In-Reply-To: <20111031224905.GQ16825@thunk.org>
On 10/31/2011 03:49 PM, Ted Ts'o wrote:
> On Mon, Oct 31, 2011 at 03:44:25PM -0700, Junio C Hamano wrote:
>> So nobody is worried about this (quoting from my earlier message)?
>>
>> On the other hand, the consumers of "Linus kernel" may want to say that
>> they trust your tree and your tags because they can verify them with your
>> GPG signature, but also they can independently verify the lieutenants'
>> trees you pulled from are genuine.
>>
>> A signed emphemeral tag is usable as means to verify authenticity in a
>> hop-by-hop fashion, but that does not leave a permanent trail that can be
>> used for auditing.
>
> Oh, there are definitely people who worry about this. They tend to be
> security poeple, though, so the goal is how do we leave the permanent
> trail in a way that doesn't generate too much noise or otherwise makes
> life difficult for developers who don't care.
>
Could we introduce a tag namespace that doesn't show up in gitweb by
default, and perhaps doesn't resolve in abbreviated form?
This is basically what Linus suggested, as far as I understand:
something like refs/pulls/hpa/tip-123-456 which is otherwise a normal
tag object?
-hpa
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:51 UTC (permalink / raw)
To: Ted Ts'o, Junio C Hamano, Linus Torvalds, git,
James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <20111031224905.GQ16825@thunk.org>
On 10/31/2011 03:49 PM, Ted Ts'o wrote:
> On Mon, Oct 31, 2011 at 03:44:25PM -0700, Junio C Hamano wrote:
>> So nobody is worried about this (quoting from my earlier message)?
>>
>> On the other hand, the consumers of "Linus kernel" may want to say that
>> they trust your tree and your tags because they can verify them with your
>> GPG signature, but also they can independently verify the lieutenants'
>> trees you pulled from are genuine.
>>
>> A signed emphemeral tag is usable as means to verify authenticity in a
>> hop-by-hop fashion, but that does not leave a permanent trail that can be
>> used for auditing.
>
> Oh, there are definitely people who worry about this. They tend to be
> security poeple, though, so the goal is how do we leave the permanent
> trail in a way that doesn't generate too much noise or otherwise makes
> life difficult for developers who don't care.
>
Could we introduce a tag namespace that doesn't show up in gitweb by
default, and perhaps doesn't resolve in abbreviated form?
This is basically what Linus suggested, as far as I understand:
something like refs/pulls/hpa/tip-123-456 which is otherwise a normal
tag object?
-hpa
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:51 UTC (permalink / raw)
To: Ted Ts'o, Junio C Hamano, Linus Torvalds, git,
James Bottomley
In-Reply-To: <20111031224905.GQ16825@thunk.org>
On 10/31/2011 03:49 PM, Ted Ts'o wrote:
> On Mon, Oct 31, 2011 at 03:44:25PM -0700, Junio C Hamano wrote:
>> So nobody is worried about this (quoting from my earlier message)?
>>
>> On the other hand, the consumers of "Linus kernel" may want to say that
>> they trust your tree and your tags because they can verify them with your
>> GPG signature, but also they can independently verify the lieutenants'
>> trees you pulled from are genuine.
>>
>> A signed emphemeral tag is usable as means to verify authenticity in a
>> hop-by-hop fashion, but that does not leave a permanent trail that can be
>> used for auditing.
>
> Oh, there are definitely people who worry about this. They tend to be
> security poeple, though, so the goal is how do we leave the permanent
> trail in a way that doesn't generate too much noise or otherwise makes
> life difficult for developers who don't care.
>
Could we introduce a tag namespace that doesn't show up in gitweb by
default, and perhaps doesn't resolve in abbreviated form?
This is basically what Linus suggested, as far as I understand:
something like refs/pulls/hpa/tip-123-456 which is otherwise a normal
tag object?
-hpa
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Simon Glass @ 2011-10-31 22:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110311837.33466.vapier@gentoo.org>
Hi Mike,
On Mon, Oct 31, 2011 at 3:37 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 31 October 2011 17:49:58 Simon Glass wrote:
>> On Mon, Oct 31, 2011 at 2:15 PM, Tabi Timur-B04825 wrote:
>> > On Sun, Oct 30, 2011 at 7:54 PM, Mike Frysinger wrote:
>> >> -static void print_num(const char *, ulong);
>> >> +__maybe_unused
>> >> +static void print_num(const char *name, ulong value)
>> >> +{
>> >> + ? ? ? printf("%-12s= 0x%08lX\n", name, value);
>> >> +}
>> >
>> > Will the linker remove the functions from the binary if they are unusued?
>>
>> If built with -ffunction-sections and --gc-sections,, then the linker
>> can do this sort of thing. Otherwise it can't, but the compiler can. I
>> just tested Mike's code on my ARM compiler to make sure and it happily
>> removed print_eth() when it was not used.
>
> i don't think you need function-sections to make this happen. ?since it is
> marked "static", gcc should do DCE on it. ?the __maybe_unused markings is just
> to kill off any warnings about the func not being used (which might occur in
> the #ifdef jungle below). ?that attribute does not tell gcc to retain the
> function even if it isn't referenced in this file (as far as gcc can tell).
> -mike
>
That's right, you don't need function-sections for the compiler to
eliminate the code - my point was that the linker can't do this sort
of thing...luckily it doesn't need to.
There might be an option to control this, a bit like
-fkeep-static-consts, but I can't see it. Can't see it being very
useful anyway.
Regards,
Simon
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 22:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFzedaAzzWfzhqVf8y8ZW0jeb56hZwdV3UodSp8Q_Qhc2A@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But seriously, I don't care about the *implementation* all that much.
> If people want to use the crazy git "notes" capability, you can do
> that too, although quite frankly, I don't see the point.
As I already said, I do not think notes is a good match as a tool to do
this.
> matters is that "git push" and "git pull" would JustWork(tm), and
> check the signature if one exists, without having to cut-and-paste
> data that simply shouldn't be visible to the user.
>
> I abhor the interface Ingo suggested, for example....
Some cut-and-paste (or piping the e-mail to a command) would be necessary
evil, though, as you would have GPG keys from more than one trusted person
in your keyring, and when you are responding to a pull-request from person
A, finding a valid commit signed by person B should not be a success, but
at least should raise a warning.
^ permalink raw reply
* Re: [RFC/PATCH 2/7] x86, mm: Move zone init from paging_init() on 64-bit
From: David Rientjes @ 2011-10-31 22:50 UTC (permalink / raw)
To: Pekka Enberg; +Cc: x86, linux-kernel, Tejun Heo, Yinghai Lu, H. Peter Anvin
In-Reply-To: <1319811801-1725-2-git-send-email-penberg@kernel.org>
On Fri, 28 Oct 2011, Pekka Enberg wrote:
> This patch introduces a zone_sizes_init() helper function on 64-bit to make it
> more similar to 32-bit init.
>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Cc: H. Peter Anvin <hpa@linux.intel.com>
> Cc: David Rientjes <rientjes@google.com>
> Signed-off-by: Pekka Enberg <penberg@kernel.org>
Acked-by: David Rientjes <rientjes@google.com>
^ permalink raw reply
* Re: [CONSOLIDATED PULL 00/18] Patches, QA & Bug Fixes
From: Richard Purdie @ 2011-10-31 22:44 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1319753141.git.sgw@linux.intel.com>
On Fri, 2011-10-28 at 00:06 +0200, Saul Wold wrote:
> Khem Raj (1):
> libtool: Upgrade from 2.4 -> 2.4.2
This didn't go in since it doesn't have the whitespace and SUMMARY
issues I previously mentioned fixed.
>
> Paul Eggleton (3):
> dbus: remove unused initscript
> util-linux: split out mkfs into its own package
> e2fsprogs: move mke2fs.conf to e2fsprogs-mke2fs package
>
> Saul Wold (12):
> wget: Add recipe from OE
I've pushed a subsequent commit cleaning up a couple of things I noticed
later on this one.
> dbus-glib: fix QA Packaging issues
> libgcc: fix QA Packaging issues
The above patch has feedback directly.
> at: fix QA Packaging issues
> man: fix QA Packaging issues
> mdadm: fix QA Packaging issues
> libatomics-ops: fix QA Packaging issues
> libproxy: fix QA Packaging issues
> abiword: convert to svn
> avahi: use useradd to create user
> connman: create xuser
> xserver-nodm-init: use useradd to create xuser
I didn't take these last three since the avahi dbus restart needs to
remain (but can be ignored at rootfs time with an exit 0), I think
you're going to change the xuser homedir and the xserver-nodm-init needs
to preserve the Xusername file since other scripts use it.
>
> Scott Garman (1):
> documentation-audit.sh: script for auditing documentation build
> status
>
> Wenzong Fan (1):
> distro_tracking_fields: update packages tracking fields
I merged everything else.
Cheers,
Richard
^ permalink raw reply
* Re: [RFC/PATCH 1/7] x86, mm: Use MAX_DMA_PFN for ZONE_DMA on 32-bit
From: David Rientjes @ 2011-10-31 22:50 UTC (permalink / raw)
To: Pekka Enberg; +Cc: x86, linux-kernel, Tejun Heo, Yinghai Lu, H. Peter Anvin
In-Reply-To: <1319811801-1725-1-git-send-email-penberg@kernel.org>
On Fri, 28 Oct 2011, Pekka Enberg wrote:
> Use MAX_DMA_PFN which represents the 16 MB ISA DMA limit on 32-bit x86 just
> like we do on 64-bit.
>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Cc: H. Peter Anvin <hpa@linux.intel.com>
> Cc: David Rientjes <rientjes@google.com>
> Signed-off-by: Pekka Enberg <penberg@kernel.org>
Acked-by: David Rientjes <rientjes@google.com>
^ permalink raw reply
* orion/kirkwood and device tree
From: Michael Walle @ 2011-10-31 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111031164042.GD29402@lunn.ch>
Hi Jason and all,
Sorry for being quiet such a long time, much work to do here..
Am Montag 31 Oktober 2011, 17:40:42 schrieb Andrew Lunn:
> > I wish. :-) dreamplug support just made it into u-boot. So, now I
> > just have to babysit it until 2011.12 / 2012.01 release. I should have
> > some more cycles to dedicate to Linux/dreamplug in the coming months.
>
> Is uboot support necessary? I cannot use jtag on my device, so i'm
> reluctant to upgrade uboot. I hope it is possible to append the dt to
> kernel image, at least for development work.
iirc, i've seen some patches around to add support for appended device trees.
dunno if they made it upstream, though.
> > My biggest stumbling block is still learning devicetree. Simon Glass
> > has added support for parsing and using fdt's in u-boot. I successfully
> > adapted mvrtc driver to use it. So that helped my understanding. I've
> > since found some key places in the kernel where registers are defined
> > and interrupts set. So, conceptually, I have a much better idea of how
> > it needs to happen. Unfortunately, it needs to be kirkwood / orion
> > getting fdt support, and then adding a dreamplug fdt file. A lot more
> > work to do it right.
>
> I have a reasonable idea how kirkwood/orion works. I've done some
> cleanup of the shared code between the different orion devices.
>
> I guess what i need is the simplest DT configuration needed to get the
> device to boot however still using the bubba3 hard coded platform
> devices. I can then move each platform device one by one into
> DT. However, my initial quick experiments just resulted in instant
> kernel crash...
i've already ported some marvell devices to DT. spi-orion, orion-wdt, rtc-mv
and mv_cesa. Atm i'm struggling with how to pass kirkwood_mbus_dram_info to
the device drivers (the old method is to pass it through platform_data)
I hope i find time tomorrow, to upload my git tree and/or post some RFC
patches.
--
Michael
^ permalink raw reply
* Re: [PATCH] flexcan: Fix CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK
From: Marc Kleine-Budde @ 2011-10-31 22:49 UTC (permalink / raw)
To: Reuben Dowle; +Cc: netdev, linux-can
In-Reply-To: <70F6AAAFDC054F41B9994A9BCD3DF64E16FAA211@exch01-aklnz.MARINE.NET.INT>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
On 10/31/2011 11:43 PM, Reuben Dowle wrote:
> Currently the flexcan driver uses hardware local echo. This blindly
> echoes all transmitted frames to all receiving sockets, regardless what
> CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK are set to.
>
> This patch now submits transmitted frames to be echoed in the transmit
> complete interrupt, preserving the reference to the sending socket.
> This allows the can protocol to correctly handle the local echo.
>
> Signed-off-by: Reuben Dowle <reuben.dowle@navico.com>
there were some comments inline in my original mail.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [GIT] pull request for x86 platform drivers tree
From: Linus Torvalds @ 2011-10-31 22:49 UTC (permalink / raw)
To: Matthew Garrett; +Cc: platform-driver-x86
In-Reply-To: <20111031132438.GA2824@srcf.ucam.org>
On Mon, Oct 31, 2011 at 6:24 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> are available in the git repository at:
> git://cavan.codon.org.uk/platform-drivers-x86.git for_linus
So I've never seen this host before, and have no idea whose it is or
why I should trust it..
Please make me feel better about it.
Linus
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Ted Ts'o @ 2011-10-31 22:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, Linus Torvalds, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <7vzkggok6u.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 03:44:25PM -0700, Junio C Hamano wrote:
> So nobody is worried about this (quoting from my earlier message)?
>
> On the other hand, the consumers of "Linus kernel" may want to say that
> they trust your tree and your tags because they can verify them with your
> GPG signature, but also they can independently verify the lieutenants'
> trees you pulled from are genuine.
>
> A signed emphemeral tag is usable as means to verify authenticity in a
> hop-by-hop fashion, but that does not leave a permanent trail that can be
> used for auditing.
Oh, there are definitely people who worry about this. They tend to be
security poeple, though, so the goal is how do we leave the permanent
trail in a way that doesn't generate too much noise or otherwise makes
life difficult for developers who don't care.
- Ted
^ permalink raw reply
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: Jonas Meurer @ 2011-10-31 22:48 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <CAMw1ynTLyR6L2qMo8B=C1a8GQLE85_xBks+ctzoZMQYCyAd3ug@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 31.10.2011 23:34, schrieb Claudio Moretti:
> While I agree with you, that cryptsetup already does a lot to
> prevent data (i.e. header) loss, I don't see a reason why
> (optional) header backup at some random place on the device would
> be such a big security problem.
>
> Because it would significantly decrease the efficiency of
> cryptsetup anti-forensic features, if i'm not wrong.. Meaning that
> if the header is stored somewhere in the disk, that place should be
> traceable: if it is random, there has to be some known place where
> its location is stored; if the location information is not stored,
> but one has to analyze the entire disk to find it, analyzing the
> disk would expose the header; this applies also to the "fixed
> header location" hypothesis. That's what I think I have understood
> from previous (similar and related) discussions with Arno; please,
> correct me if I'm mistaken.
I don't suggest to hide the backup header. In fact the exact place of
it should be obvious (either fixed, or better: random but written to
the first header). Thus the second header is as obvious as the first
one. Only difference: it's not at the beginning of the device.
Unfortunately the first sectors of a device are overwritten much more
often than later sectors.
I see that a backup header - which for sure needs to be overwritten by
new luksFormat - wouldn't prevent accidents like the one explained in
the first message to this thread. Only in cases where people
accidently overwrite the first sectors of a luks device, this kind of
backup header could prevent data loss.
Greetings,
jonas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOryWtAAoJEFJi5/9JEEn+wU0P/jYjfauG4Ak1C+eLZ/YzkSEH
Lf5KY5WlIip3dKSkrgtZ9EjIB71PJbDhvdA0QLG6k/5MbubrDqSIGf+rb8LvJ46n
FlaBob16VcpWbhdycgk07DRjt94lkI7IZg3LrLcK3f1xD53Ztyo96dqUlAU6jOzB
qNjhQawgViTR6YPeMozUs8fn4gPAFp5AzxdmOpvoPCuErk3A8/r7T5NBRtDROPw8
7tva1AQvoFYHh8ZmSCncTN/1h0QGMTjWVY4rVUVypk7p8axbFOUQWqpnKQ15Vee/
XfPavhd8d4ws/z0OOfMn5bLQt4c9UhWC8wbr74rt/TCkXVggx4HAUT4XHZItRkK4
8MxPZLCDxINedy1s5cpkgWFpptmqNbraf9iof2DXjQLQw1V+FABIDYXV1YxzGqc7
eWKPtpNTvhwBVYZ3PsEXIqnLTo2yrzit5/GQsk/MKgGFcJRYfK9/MqVkRWb0YNR+
tmt+H0y1TZXKm265EcryjvJ1jVJ7fylAtSbMGOW8OUHvLHTZfkzF2HZ7uhdy36RB
czEHt6WbfpZI783fjp6C3SnPNM3MJXd+UTWJN5uCaWaxWNols1mZI/Jn8M2GUDQH
TtwDDSwq/a+R63piVrvjLNJKglbjz/Km6j/Nz/VUY9B07+Ih+dPhNKOB62fl0DTW
QL8T/nDXlV4Z/IXq5Q1M
=5p2O
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] powerpc/iommu: remove default window before creating larger window
From: Nishanth Aravamudan @ 2011-10-31 22:47 UTC (permalink / raw)
To: benh; +Cc: miltonm, paulus, linuxppc-dev
In-Reply-To: <20111026224323.GA15685@us.ibm.com>
Hi Ben,
Please don't take this patch :)
While, it does work around some issues I'm tracking down, it can lead
to worse ones if we are unable to configure the larger DMA window, or if
some functions in a PE don't use 64-bit DMA masks.
Thanks,
Nish
On 26.10.2011 [15:43:23 -0700], Nishanth Aravamudan wrote:
> The DDW feature relies on there being sufficient TCE space to allocate
> for the requested DMA window size. The default window uses up some of
> that space, though, and it is recommended to first remove the default
> window and then allocate the larger window advertised by firmware. Do
> this by abstracting out parts of remove_ddw into a function that does
> not assume an existing larger window has been created.
>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> ---
> arch/powerpc/platforms/pseries/iommu.c | 35 +++++++++++++++++++++++--------
> 1 files changed, 26 insertions(+), 9 deletions(-)
>
> Is there a better way to get the default window's LIOBN than to call
> of_parse_dma_window?
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
> index 01faab9..afcc04c 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -655,6 +655,21 @@ static int __init disable_ddw_setup(char *str)
>
> early_param("disable_ddw", disable_ddw_setup);
>
> +static void __remove_ddw(struct device_node *np, const u32 *ddw_avail, u64 liobn)
> +{
> + int ret;
> +
> + ret = rtas_call(ddw_avail[2], 1, 1, NULL, liobn);
> + if (ret)
> + pr_warning("%s: failed to remove direct window: rtas returned "
> + "%d to ibm,remove-pe-dma-window(%x) %llx\n",
> + np->full_name, ret, ddw_avail[2], liobn);
> + else
> + pr_debug("%s: successfully removed direct window: rtas returned "
> + "%d to ibm,remove-pe-dma-window(%x) %llx\n",
> + np->full_name, ret, ddw_avail[2], liobn);
> +}
> +
> static void remove_ddw(struct device_node *np)
> {
> struct dynamic_dma_window_prop *dwp;
> @@ -684,15 +699,7 @@ static void remove_ddw(struct device_node *np)
> pr_debug("%s successfully cleared tces in window.\n",
> np->full_name);
>
> - ret = rtas_call(ddw_avail[2], 1, 1, NULL, liobn);
> - if (ret)
> - pr_warning("%s: failed to remove direct window: rtas returned "
> - "%d to ibm,remove-pe-dma-window(%x) %llx\n",
> - np->full_name, ret, ddw_avail[2], liobn);
> - else
> - pr_debug("%s: successfully removed direct window: rtas returned "
> - "%d to ibm,remove-pe-dma-window(%x) %llx\n",
> - np->full_name, ret, ddw_avail[2], liobn);
> + __remove_ddw(np, ddw_avail, liobn);
>
> delprop:
> ret = prom_remove_property(np, win64);
> @@ -843,6 +850,8 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
> struct direct_window *window;
> struct property *win64;
> struct dynamic_dma_window_prop *ddwprop;
> + const void *dma_window = NULL;
> + unsigned long liobn, offset, size;
>
> mutex_lock(&direct_window_init_mutex);
>
> @@ -918,6 +927,14 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
> goto out_free_prop;
> }
>
> + /*
> + * To maximize the resources available to the create RTAS call,
> + * delete the existing DMA window
> + */
> + dma_window = of_get_property(pdn, "ibm,dma-window", NULL);
> + of_parse_dma_window(pdn, dma_window, &liobn, &offset, &size);
> + __remove_ddw(pdn, ddw_avail, liobn);
> +
> ret = create_ddw(dev, ddw_avail, &create, page_shift, len);
> if (ret != 0)
> goto out_free_prop;
> --
> 1.7.5.4
>
>
> --
> Nishanth Aravamudan <nacc@us.ibm.com>
> IBM Linux Technology Center
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vzkggok6u.fsf@alter.siamese.dyndns.org>
On 10/31/2011 03:44 PM, Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> On 10/31/2011 03:30 PM, Linus Torvalds wrote:
>>>
>>> But if you do the normal "git pull git://git.kernel.org/name/of/repo"
>>> - which is how things happen as a result of a pull request - you won't
>>> get tags at all - you have to ask for them by name or use "--tags" to
>>> get them all.
>>>
>>
>> Didn't realize that... I guess I'm too used to named remotes.
>>
>> If so, just using a tag should be fine, no?
>
> So nobody is worried about this (quoting from my earlier message)?
>
> On the other hand, the consumers of "Linus kernel" may want to say that
> they trust your tree and your tags because they can verify them with your
> GPG signature, but also they can independently verify the lieutenants'
> trees you pulled from are genuine.
>
> A signed emphemeral tag is usable as means to verify authenticity in a
> hop-by-hop fashion, but that does not leave a permanent trail that can be
> used for auditing.
>
Well, the permanent trail is in the maintainer's tree, but that might
still be suboptimal. The problem with Linus pulling those tags I assume
that it makes the tree too noisy?
-hpa
^ permalink raw reply
* Re: [PATCHv2] dbus: fix for right owner in postinst
From: Richard Purdie @ 2011-10-31 22:40 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1320083026-31637-1-git-send-email-Martin.Jansa@gmail.com>
On Mon, 2011-10-31 at 18:43 +0100, Martin Jansa wrote:
> * even when I see right chown/chmod in log.do_install, files are still
> owned by bitbake:bitbake (user running bitbake) and we need to fix it on target
> $ tail -n 4 temp/log.do_install.27768
> + chown messagebus:messagebus /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/var/run/dbus /OE/shr-core/tmp/work/armv7a-vfp-neon-o
> e-linux-gnueabi/dbus-1.4.12-r2/image/var/lib/dbus
> + chown root:messagebus /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/usr/libexec/dbus-daemon-launch-helper
> + chmod 4754 /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/usr/libexec/dbus-daemon-launch-helper
> + ln -sf /dev/null /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image//lib/systemd/system/dbus-1.service
>
> $ ll -d /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/var/run/dbus \
> /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/var/lib/dbus \
> /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/usr/libexec/dbus-daemon-launch-helper \
> /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/usr/libexec/dbus-daemon-launch-helper
> -rwsr-xr-- 1 bitbake bitbake 819869 Oct 29 12:35 /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/usr/libexec/dbus-daemon-launch-he
> lper*
> -rwsr-xr-- 1 bitbake bitbake 819869 Oct 29 12:35 /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/usr/libexec/dbus-daemon-launch-he
> lper*
> drwxr-xr-x 2 bitbake bitbake 4096 Oct 29 12:35 /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/var/lib/dbus/
> drwxr-xr-x 2 bitbake bitbake 4096 Oct 29 12:35 /OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image/var/run/dbus/
>
> * and we _cannot_ use ${D} in postinst script because it get's expanded
> before including postinst file to ipk's control.tar.gz
> and on target I see something like this:
> if [ -z "/OE/shr-core/tmp/work/armv7a-vfp-neon-oe-linux-gnueabi/dbus-1.4.12-r2/image" ] && [ -e /etc/init.d/populate-volatile.sh ] ; then
> which is wrong $D without {} works
>
> * V2: updated with Otavio version to fix it also for do_rootfs
>
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
> meta/recipes-core/dbus/dbus.inc | 12 +++++-------
> 1 files changed, 5 insertions(+), 7 deletions(-)
This is just wallpapering over the cracks I'm afraid. There is something
more fundamental going wrong here and we need to track it down...
Cheers,
Richard
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.