* Re: [GIT] pull request for x86 platform drivers tree
From: Matthew Garrett @ 2011-10-31 22:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: platform-driver-x86
In-Reply-To: <CA+55aFwKz+-FeoZQB_Y1Oj1dEBo8LxjgLPUP=Nz0TXSTcdN2Ng@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]
On Mon, Oct 31, 2011 at 03:49:19PM -0700, Linus Torvalds wrote:
> 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.
Is this any help?
--
Matthew Garrett | mjg59@cavan.codon.org.uk
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vvcr4ojvp.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 3:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.
Why?
The signer of the message needs to be printed out *anyway*. I can
match that up with the pull request, the same way I already match up
diffstat information.
So any extra cut-and-paste is (a) stupid, (b) unnecessary and (c) annoying.
It's also "bad user interface". The whole point is that we should make
the user interface *good*. Which means that the pushing side should
only need to add a "-s" to ask for signing, have to type his
passphrase (and even that would go away when using gpg-agent or
something), and perhaps a message (which would not be about the
signing, but about something that could be added to the merge commit.
And the receiving side would just do the "git pull" and automatically
just get notified that "Yes, this push has been signed by key Xyz
Abcdef"
Linus
^ permalink raw reply
* Re: [PATCH 2/2] ext4: fix a typo in struct ext4_allocation_context
From: Ted Ts'o @ 2011-10-31 22:56 UTC (permalink / raw)
To: Robin Dong; +Cc: linux-ext4, Robin Dong
In-Reply-To: <1314272192-7414-2-git-send-email-hao.bigrat@gmail.com>
On Thu, Aug 25, 2011 at 07:36:32PM +0800, Robin Dong wrote:
> From: Robin Dong <sanbai@taobao.com>
>
> This patch change "bext" to "best".
>
> Signed-off-by: Robin Dong <sanbai@taobao.com>
Thanks, applied.
- Ted
^ permalink raw reply
* Re: [RFC/PATCH 6/7] x86, mm: Prepare zone_sizes_init() for unification
From: David Rientjes @ 2011-10-31 22:56 UTC (permalink / raw)
To: Pekka Enberg; +Cc: x86, linux-kernel, Tejun Heo, Yinghai Lu, H. Peter Anvin
In-Reply-To: <1319811801-1725-6-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 6101894..12274fb 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -677,10 +677,14 @@ void __init initmem_init(void)
> static void __init zone_sizes_init(void)
> {
> unsigned long max_zone_pfns[MAX_NR_ZONES];
> +
> memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
> #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_low_pfn;
> #ifdef CONFIG_HIGHMEM
> max_zone_pfns[ZONE_HIGHMEM] = max_pfn;
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index f6b1f08..06c4360 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -624,6 +624,9 @@ static void __init zone_sizes_init(void)
> max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
> #endif
> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
> +#ifdef CONFIG_HIGHMEM
> + max_zone_pfns[ZONE_HIGHMEM] = max_pfn;
> +#endif
>
> free_area_init_nodes(max_zone_pfns);
> }
I'd just fold patch 7 into this, it doesn't make much sense to have add
CONFIG_HIGHMEM code for 64-bit, for example, just to make the next patch
simpler.
^ permalink raw reply
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: Jonas Meurer @ 2011-10-31 22:56 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <4EAE60AC.4010001@laposte.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey Quentin,
Am 31.10.2011 09:47, schrieb Quentin Lefebvre:
> Indeed, it seems that improvements can be done for the Debian
> installer to better handle crypto disks and partitions. With the
> little experience I have about using encrypted partitions with
> LUKS/cryptsetup under/over LVM, I would not have tried to attach an
> existing encrypted device through the installer menu, as I know
> pretty well that few scenarios are handled at this point.
> Hopelessly, what you had to do in your case was to switch to a
> console to make changes by hand or, if you could, wait for the
> reboot of your fresh install to edit the system files and mount old
> volumes this way.
>
> I agree on the point you mention, i.e. encryption could be better
> integrated in the installer so that assisted mounting of old
> encrypted partitions becomes possible. [...] I would be happy to
> help Debian developers regarding this kind of install, but I have
> always delayed the moment I contact them. If you are planning to do
> so, I would be interested to be included in the discussion and give
> my feedback too.
I'm pretty sure that help with cryptsetup integration into the Debian
Installer (D-I) is highly appreciated by the current D-I developers.
As a starting point, you might want to check the following resources:
request for support to integrate existing encrypted devices in D-I:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451535
slighly outdated wiki page about cryptsetup integration to D-I:
http://wiki.debian.org/DebianInstaller/PartmanCrypto
git repository with partman-crypto code:
http://anonscm.debian.org/gitweb/?p=d-i/partman-crypto.git
Greetings,
jonas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOryeYAAoJEFJi5/9JEEn+kRQP/0rYn8A/0w0PKJ7bCbkIxyC4
xh6QWG1quFCWiWXSQMqidWrXNv9Ht2TeJ58MMn/jk/rWJV8ZE7SGkkGW5h1Lf09m
bjPqd9GRajzWLtZC7GCx5EigaNdoCtrXA4qmwDVDf8S+0KpxWZVi5tmz9CB9tUp6
V4qK5Iti2v8mH+rNktlv2sQRDfmXr0fe0+LLVTk9VmKzgn3blQ6jd51VI+XtcjK6
Uw/Tr525KlL5iPjZy7DDEJ4P+36774Euc5VmZiDahdrnzwV6oeUzIjLTLwe4KEYQ
SDVu7T8eTaCY34c9KLAr1kCg0b8TzH4GSP2JXRkK6jGpYgzgTSFlHzi+OcTsiZ26
JZKGth6vs9IILpysCqGb53KyrVaKGAG2rVe8FdOtitYm2xOpLdNPHVs9x2XP0lFN
sqo4o6cRIWBsz8RIdU6ma6pPphWBEUZqsHzLqEHqEpZN2iA3RE7Kp/RyEsnSSdz5
ra6t1So9LX+6FaxrHf6u2ZzcZ7SJB5+p54HYxgKCoXXZ/g8X95Z7PlaOBSBkvN2c
uzleQ+2PCf+002CI+UcK9hmWsp6KxzZsTagilVFDFg+66c7IDfo5xK2acquq9a3l
OujoEfOyShjo9CdMMMBlSki4V8Kn9BFfk4m0g594fJ9DkJwVl9PMSESw4CJbWuCl
YaOA82xNdVhHO0ESful+
=GPw5
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 00/17] drop unused Kconfig symbols
From: Paul Bolle @ 2011-10-31 22:55 UTC (permalink / raw)
To: Michal Marek
Cc: linux-kernel, Jesper Nilsson, Mikael Starvik,
Valdis.Kletnieks@vt.edu, Paul Mundt
In-Reply-To: <20111031224248.GB25411@sepie.suse.cz>
On Mon, 2011-10-31 at 23:42 +0100, Michal Marek wrote:
> On Mon, Oct 24, 2011 at 01:37:35PM +0200, Paul Bolle wrote:
> > 1) I've dropped five patches that were taken by the maintainers
> > (blackfin, unicore32, tomoyo, m68k, and staging). cris got a NAK (for an
> > invalid reason, but I guess I'll just try again after the v3.2 merge
> > window closes).
Just today Jesper Nilsson basically dropped that NAK. I assume Jesper
will try to carry the patch in (one of) their tree(s). Is that correct?
> > 4) I'll send these patches only to you and the people that added a tag.
> > Please tell me if you'd like me to also cc lkml and the maintainers. I
> > assumed cc'ing those addresses would not be helpful in this stage.
> >
> > Paul Bolle (17):
> > alpha: drop unused Kconfig symbol
> > sparc: drop unused Kconfig symbol
> > um: drop unused Kconfig symbol
> > sh: drop unused Kconfig symbol
Paul Mundt applied this one a few days ago. But I think git merge will
handle that somewhere down the road.
> > score: drop unused Kconfig symbols
> > m32r: drop unused Kconfig symbol
> > samples: drop unused Kconfig symbol
> > arm: at91: drop unused Kconfig symbol
> > (arm: drop unused Kconfig symbol -- skipped)
> > openrisc: drop unused Kconfig symbols
> > mips: drop unused Kconfig symbols
> > powerpc: 40x: drop unused Kconfig symbol
> > powerpc: drop unused Kconfig symbols
> > x86: drop unused Kconfig symbol
> > stmmac: drop unused Kconfig symbol
> > pci: drop unused Kconfig symbol
> > scsi: drop unused Kconfig symbol
>
> Applied except for the one arm commit.
Paul Bolle
^ permalink raw reply
* [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
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.