* Re: Lock in the ironlake_panel_vdd_work()
From: Keith Packard @ 2011-10-31 18:33 UTC (permalink / raw)
To: Daniel Vetter, Konstantin Belousov; +Cc: intel-gfx
In-Reply-To: <20111031133446.GE2920@phenom.ffwll.local>
[-- Attachment #1.1: Type: text/plain, Size: 1657 bytes --]
On Mon, 31 Oct 2011 14:34:46 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Oct 31, 2011 at 03:01:33PM +0200, Konstantin Belousov wrote:
> > I have a question about ironlake_panel_vdd_work(). Should it use
> > the device struct_mutex, or need it to be the mode_config.mutex
> > instead ?
>
> Yeah. This was actually flagged in review by Chris and me, but seems to
> have been lost in the merge. Keith?
I thought I fixed that; it must have gotten lost in the fairly steady
set of rebasing/reworking of that patch sequence.
commit 241dedda2785f040da45576418686490431232d2
Author: Keith Packard <keithp@keithp.com>
Date: Mon Oct 31 11:30:10 2011 -0700
drm/i915: Use mode_config.mutex in ironlake_panel_vdd_work
Use of the struct_mutex is not correct for locking in mode setting paths.
Signed-off-by: Keith Packard <keithp@keithp.com>
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6611d90..30420c1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -971,9 +971,9 @@ static void ironlake_panel_vdd_work(struct work_struct *__work)
struct intel_dp, panel_vdd_work);
struct drm_device *dev = intel_dp->base.base.dev;
- mutex_lock(&dev->struct_mutex);
+ mutex_lock(&dev->mode_config.mutex);
ironlake_panel_vdd_off_sync(intel_dp);
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&dev->mode_config.mutex);
}
static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH 1/2] add boot_config command support
From: Sascha Hauer @ 2011-10-31 18:33 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD; +Cc: barebox
In-Reply-To: <20111030185023.GD7961@game.jcrosoft.org>
On Sun, Oct 30, 2011 at 07:50:23PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > + dev = "sda1";
> > > + fs = "ext3";
> > > + path = "/boot/inird-3.0.0";
> > > + };
> > > + fdt@3 {
> > > + dev = "sda1";
> > > + fs = "ext3";
> > > + path = "boot/usb_a9g20.dtb";
> > > + };
> > > +
> > > + kernel@4 {
> > > + format = "uimage";
> > > + dev = "sda3";
> > > + fs = "squashfs";
> > > + path = "/boot/uImage-installer-3.0.0";
> > > + };
> > > + initrd@4 {
> > > + dev = "sda3";
> > > + fs = "squashfs";
> > > + path = "/boot/initrd-installer-3.0.0";
> > > + };
> >
> > Why do you describe the device/fstype in each and every node? a
> > reference to a partition descriptions would be more convenient here.
> > Also it's strange that the patch is an absolute path and not a path
> > relative to the mountpoint.
> becasue we need to known the fs to mont it
>
> the fs could a real fs or nfs or tftp the path is absolute mount the
> mountpoint
Linux normally mounts the boot partition to /boot. The information you
need to describe is: sda3:initrd-installer-3.0.0. What shall the /boot
mean above?
> >
> > > + };
> > > +
> > > + configuration {
> > > + description = "Welcome on Barebox Boot Sequence";
> > > + default = "linux_3_0_0";
> > > + altboot = "installer";
> > > + bootdelay = <5>;
> > > + splash = /incbin/("splash_menu.bmp");
> > > +
> > > + linux_2_6_36 {
> > > + description = "Linux 2.6.36";
> > > + cmdline = "mem=64M console=ttyS0,115200 root=/dev/sda2 rw rootfstype=ext3";
> >
> > We should be able to build the commandline out of its parts. A
> > monolithic string seems not very flexible.
>
> the idea is to put var inside and after you will use this cmdline as a based
> to construct the finall one
> >
> > > + kernel = "kernel@1";
> > > + initrd = "initrd@1";
> > phandles instead?
> >
> more code in the c code and mre difficult to handle when modifying the dtb
> from barebox
I don't buy that. Other than that it seems to justify my point that the
dtb format you chose is driven by your adhoc needs and not by some
concept.
> >
> > So instead of the list_head directly you export it via
> > boot_config_get_kernels() which basically has the same effect but is
> > harder to read. Please do not do that.
> realy don't like to export it
You already do, by taking the indirection over a function.
> >
> > > + printf("[Initrd]\n");
> > > +
> > > + list_for_each_entry(bed, boot_config_get_initrds(), list)
> > > + printf("%s\n", bed->name);
> > > +
> > > + printf("[FDT]\n");
> > > +
> > > + list_for_each_entry(bed, boot_config_get_fdts(), list)
> > > + printf("%s\n", bed->name);
> > > +
> > > +}
> > > +
> > > +static void print_boot_config_data(struct boot_config_data *bed)
> >
> > What's a bed? Supposedly the thing I should go now.
> I like it :P
> it was supposed to mean boot env data
>
> but switch to boot_config_data
> >
> > > +{
> > > + printf("name = '%s'\n", bed->name);
> > > + printf("dev = '%s'\n", bed->dev);
> > > + printf("fs = '%s'\n", bed->fs);
> > > + printf("path = '%s'\n", bed->path);
> > > +}
> > > +
> > > +static void print_boot_config(struct boot_config *e)
> > > +{
> > > + struct boot_config_var *v;
> > > +
> > > + printf("Config '%s'\n\n", e->name);
> > > +
> > > + v = boot_config_var_get_by_name(e, "description");
> >
> > You have a mechanism to attach arbitrary key/value pairs to a struct
> > boot_config. Still you do not iterate over all over all variables in the
> > corresponding devicetree node, but instead only handle the variables
> > explicitely that you now about.
> >
> > This does not make sense. struct boot_config should simply have a char
> > *description, char *cmdline and whatever else you need. Then you can
> > remove this boot_config_var_get_by_name() cruft.
> I knwon this version is not switch to new one I finish it
-ENOPARSE
> > > + switch(cbc.action) {
> >
> > What's this cbc.action thing about? It is only ever used in this
> > function.
> is to specify what to do based on the option as you can have alots of option
> see menu framwork
Look again. This variable is used only locally in this function and it
would be a bug if the functions below would interpret it.
> >
> > > + case action_list:
> > > + ret = do_boot_config_list(&cbc);
> > > + break;
> > > + case action_load:
> > > + ret = do_boot_config_load(&cbc);
> > > + break;
> > > + case action_boot:
> > > + ret = do_boot_config_boot(&cbc);
> > > + break;
> > > +
> > > + };
> > > +
> > > + if (ret)
> > > + return COMMAND_ERROR_USAGE;
> >
> >
> > I am not going to read further. Every struct boot_config seems to have a
> > clearly defined set of variables but instead of adding the corresponding
> > pointers to struct boot_config you have this strange
> > attach-key-value-pairs-to-c-struct in place.
> > Supposedly this is some leftover from earlier versions. Sending
> > non-finished patches as a RFC is perfectly fine, but in this case it's
> > sometimes really hard to see where you're heading to.
> Yas you have miniamal set of variable but the code is more generic and
> support to have more var.
>
> As example for network or complex system the idea is to have no limit of which
> var you can add, you just need to specify the mandatory one.
>
> And the Framework is not DTB only but generic other format will have other
> var.
When other formats have other variables then you end up with a system
where barebox does not know its own internal format. No. It does not
make sense to translate from dtb or whatever format to another
nonnative format which then has to be translated into soemthing else
which barebox understands.
> >
> > If you want to get this in someday it's going to be a long way.
> > Communicating with the Linux userspace using a devicetree means creating
> > an API which also means that we have to have the nice feeling that this API
> > can be stable. Right now it more looks to me as if the devicetree format is
> > an adhoc implementation of what you needed for your example.
> The point is the DTB is one format , we can use ant format for the
> boot_config.
> THe DTB match the need to describe the boot config and will not impact the
> boot laoder size but we can use a grub config file too or PXE boot
>
> so the DTB is just a format to support to demonstrate the boot_config
> framework
This 'just a format' is exported to Linux and thus should be more
thought about.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [U-Boot] Conflicting definitions of flush_dcache
From: Mike Frysinger @ 2011-10-31 18:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111031075624.GA9871@chokladfabriken.org>
On Monday 31 October 2011 03:56:25 Stefan Kristiansson wrote:
> so my gut feeling is that nios2 and the 2 ethernet drivers should be
> changed to use for example flush_dcache_range(?)
correct
> Perhaps cmd_cache.c should also be fixed to use flush_dcache_all()?
> flush_icache() ofcourse suffer from the same problem.
that sounds reasonable. the prototypes also need to get added to
include/common.h ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/2d6ed692/attachment.pgp
^ permalink raw reply
* Re: [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
From: Jim Rees @ 2011-10-31 18:31 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Benny Halevy, Peng Tao, linux-nfs, Peng Tao, nfsv4 list
In-Reply-To: <1320085212.4714.48.camel@lade.trondhjem.org>
Trond Myklebust wrote:
I don't necessarily disagree with what you are saying, but I have yet to
see a single server side implementation of CB_RECALL_ANY, let alone any
numbers that indicate performance or responsiveness problems resulting
from our existing client-side implementation.
I therefore find it hard to understand why optimising this particular
code is such a high priority, or why a patch that is adding per-file
layoutreturns to initiate_bulk_draining() is going to help anything at
all.
Testing between the linux block layout client and the EMC block layout
server revealed a deadlock when the server had handed out some number of
layouts and couldn't hand out any more. So now the EMC block layout server
implements CB_RECALL_ANY. So yes, this solves a real world problem, and
yes, there is a server that implements this.
We had some discussions at the time, and I don't remember if those were on
the linux-nfs list or in some other forum. We decided that the client was
in the best position to decide which layouts were no longer needed, so we
needed some way for the server to tell the client to return some layouts
without specifying which ones. CB_RECALL_ANY seemed custom-made for this
purpose, so we used it.
I don't think it would be appropriate for the server to recall all layouts
when it only needs some of them back.
^ permalink raw reply
* Re: [nfsv4] [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
From: Trond Myklebust @ 2011-10-31 18:31 UTC (permalink / raw)
To: Matt W. Benjamin; +Cc: linux-nfs, nfsv4 list, Benny Halevy
In-Reply-To: <553963112.119.1320085390187.JavaMail.root@thunderbeast.private.linuxbox.com>
On Mon, 2011-10-31 at 14:23 -0400, Matt W. Benjamin wrote:
> Hi,
>
> Such a server implementation will certainly not be long in coming.
Good. However until then, we have nothing to test any performance claims
against.
Trond
> ----- "Trond Myklebust" <Trond.Myklebust@netapp.com> wrote:
>
> > On Mon, 2011-10-31 at 19:57 +0200, Benny Halevy wrote:
>
> > >
> > > Waiting for revocation may work well with some servers but would be
> > disastrous in
> > > terms of performance and responsiveness with others.
> >
> > I don't necessarily disagree with what you are saying, but I have yet
> > to
> > see a single server side implementation of CB_RECALL_ANY, let alone
> > any
> > numbers that indicate performance or responsiveness problems
> > resulting
> > from our existing client-side implementation.
> >
> > I therefore find it hard to understand why optimising this particular
> > code is such a high priority, or why a patch that is adding per-file
> > layoutreturns to initiate_bulk_draining() is going to help anything
> > at
> > all.
> >
> > Trond
> >
>
>
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* [U-Boot] [PATCH 5/5] powerpc/85xx: resize the boot page TLB before relocating CCSR
From: Timur Tabi @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320085845-10547-1-git-send-email-timur@freescale.com>
On some Freescale systems (e.g. those booted from the on-chip ROM), the
TLB that covers the boot page can also cover CCSR, which breaks the CCSR
relocation code. To fix this, we resize the boot page TLB so that it only
covers the 4KB boot page.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/cpu/mpc85xx/start.S | 49 ++++++++++++++++++++++++++++++++++++++
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 6de8765..39f1438 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -330,6 +330,55 @@ l2_disabled:
#endif /* CONFIG_MPC8569 */
/*
+ * Search for the TLB that covers the code we're executing, and shrink it
+ * so that it covers only this 4K page. That will ensure that any other
+ * TLB we create won't interfere with it. We assume that the TLB exists,
+ * which is why we don't check the Valid bit of MAS1.
+ *
+ * This is necessary, for example, when booting from the on-chip ROM,
+ * which (oddly) creates a single 4GB TLB that covers CCSR and DDR.
+ * If we don't shrink this TLB now, then we'll accidentally delete it
+ * in "purge_old_ccsr_tlb" below.
+ */
+ bl nexti /* Find our address */
+nexti: mflr r1 /* R1 = our PC */
+ li r2, 0
+ mtspr MAS6, r2 /* Assume the current PID and AS are 0 */
+ isync
+ msync
+ tlbsx 0, r1 /* This must succeed */
+
+ /* Set the size of the TLB to 4KB */
+ mfspr r3, MAS1
+ li r2, 0xF00
+ andc r3, r3, r2 /* Clear the TSIZE bits */
+ ori r3, r3, MAS1_TSIZE(BOOKE_PAGESZ_4K)@l
+ mtspr MAS1, r3
+
+ /*
+ * Set the base address of the TLB to our PC. We assume that
+ * virtual == physical. We also assume that MAS2_EPN == MAS3_RPN.
+ */
+ lis r3, MAS2_EPN at h
+ ori r3, r3, MAS2_EPN at l /* R3 = MAS2_EPN */
+
+ and r1, r1, r3 /* Our PC, rounded down to the nearest page */
+
+ mfspr r2, MAS2
+ andc r2, r2, r3
+ or r2, r2, r1
+ mtspr MAS2, r2 /* Set the EPN to our PC base address */
+
+ mfspr r2, MAS3
+ andc r2, r2, r3
+ or r2, r2, r1
+ mtspr MAS3, r2 /* Set the RPN to our PC base address */
+
+ isync
+ msync
+ tlbwe
+
+/*
* Relocate CCSR, if necessary. We relocate CCSR if (obviously) the default
* location is not where we want it. This typically happens on a 36-bit
* system, where we want to move CCSR to near the top of 36-bit address space.
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH 4/5] powerpc/85xx: verify the current address of CCSR before relocating it
From: Timur Tabi @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320085845-10547-1-git-send-email-timur@freescale.com>
Verify that CCSR is actually located where it is supposed to be before
we relocate it. This is useful in detecting U-Boot configurations that
are broken (e.g. an incorrect value for CONFIG_SYS_CCSRBAR_DEFAULT).
If the current value is wrong, we enter an infinite loop, which is handy
for debuggers.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/cpu/mpc85xx/start.S | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index ccb331a..6de8765 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -422,6 +422,33 @@ create_ccsr_old_tlb:
msync
tlbwe
+ /*
+ * We have a TLB for what we think is the current (old) CCSR. Let's
+ * verify that, otherwise we won't be able to move it.
+ * CONFIG_SYS_CCSRBAR_DEFAULT is always a 32-bit number, so we only
+ * need to compare the lower 32 bits of CCSRBAR on CoreNet systems.
+ */
+verify_old_ccsr:
+ lis r0, CONFIG_SYS_CCSRBAR_DEFAULT at h
+ ori r0, r0, CONFIG_SYS_CCSRBAR_DEFAULT at l
+#ifdef CONFIG_FSL_CORENET
+ lwz r1, 4(r9) /* CCSRBARL */
+#else
+ lwz r1, 0(r9) /* CCSRBAR, shifted right by 12 */
+ slwi r1, r1, 12
+#endif
+
+ cmpl 0, r0, r1
+
+ /*
+ * If the value we read from CCSRBARL is not what we expect, then
+ * enter an infinite loop. This will at least allow a debugger to
+ * halt execution and examine TLBs, etc. There's no point in going
+ * on.
+ */
+infinite_debug_loop:
+ bne infinite_debug_loop
+
#ifdef CONFIG_FSL_CORENET
#define CCSR_LAWBARH0 (CONFIG_SYS_CCSRBAR + 0x1000)
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH 3/5] powerpc/85xx: add some missing sync instructions in the CCSR relocation code
From: Timur Tabi @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320085845-10547-1-git-send-email-timur@freescale.com>
Calls to tlbwe and tlbsx should be preceded with an isync/msync pair.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/cpu/mpc85xx/start.S | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index b5bf1fa..ccb331a 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -363,6 +363,8 @@ purge_old_ccsr_tlb:
li r1, 0
mtspr MAS6, r1 /* Search the current address space and PID */
+ isync
+ msync
tlbsx 0, r8
mfspr r1, MAS1
andis. r2, r1, MAS1_VALID at h /* Check for the Valid bit */
@@ -370,6 +372,8 @@ purge_old_ccsr_tlb:
rlwinm r1, r1, 0, 1, 31 /* Clear Valid bit */
mtspr MAS1, r1
+ isync
+ msync
tlbwe
1:
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH 2/5] powerpc/85xx: fix some comments in the CCSR relocation code
From: Timur Tabi @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320085845-10547-1-git-send-email-timur@freescale.com>
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/cpu/mpc85xx/start.S | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 528abc9..b5bf1fa 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -398,7 +398,7 @@ create_ccsr_new_tlb:
tlbwe
/*
- * Create a TLB for the old location of CCSR. Register R9 is reserved
+ * Create a TLB for the current location of CCSR. Register R9 is reserved
* for the virtual address of this TLB (CONFIG_SYS_CCSRBAR + 0x1000).
*/
create_ccsr_old_tlb:
@@ -457,7 +457,7 @@ create_temp_law:
*/
read_old_ccsrbar:
lwz r0, 0(r9) /* CCSRBARH */
- lwz r0, 4(r9) /* CCSRBARH */
+ lwz r0, 4(r9) /* CCSRBARL */
isync
/*
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH 1/5] powerpc/85xx: fix definition of MAS register macros
From: Timur Tabi @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
Some of the MAS register macros do not protect the parameter with
parentheses, which could cause wrong values if the parameter includes
operators.
Also fix the definition of TSIZE_TO_BYTES() so that it actually uses
the parameter. This hasn't caused any problems to date because the
parameter was always been 'tsize'.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/include/asm/mmu.h | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index ef5076b..209103e 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -392,17 +392,17 @@ extern void print_bats(void);
*/
#define MAS0_TLBSEL_MSK 0x30000000
-#define MAS0_TLBSEL(x) ((x << 28) & MAS0_TLBSEL_MSK)
+#define MAS0_TLBSEL(x) (((x) << 28) & MAS0_TLBSEL_MSK)
#define MAS0_ESEL_MSK 0x0FFF0000
-#define MAS0_ESEL(x) ((x << 16) & MAS0_ESEL_MSK)
+#define MAS0_ESEL(x) (((x) << 16) & MAS0_ESEL_MSK)
#define MAS0_NV(x) ((x) & 0x00000FFF)
#define MAS1_VALID 0x80000000
#define MAS1_IPROT 0x40000000
-#define MAS1_TID(x) ((x << 16) & 0x3FFF0000)
+#define MAS1_TID(x) (((x) << 16) & 0x3FFF0000)
#define MAS1_TS 0x00001000
-#define MAS1_TSIZE(x) ((x << 8) & 0x00000F00)
-#define TSIZE_TO_BYTES(x) ((phys_addr_t)(1UL << ((tsize * 2) + 10)))
+#define MAS1_TSIZE(x) (((x) << 8) & 0x00000F00)
+#define TSIZE_TO_BYTES(x) (1ULL << (((x) * 2) + 10))
#define MAS2_EPN 0xFFFFF000
#define MAS2_X0 0x00000040
--
1.7.3.4
^ permalink raw reply related
* Re: [RFC/PATCH 1/7] x86, mm: Use MAX_DMA_PFN for ZONE_DMA on 32-bit
From: Yinghai Lu @ 2011-10-31 18:30 UTC (permalink / raw)
To: Pekka Enberg; +Cc: x86, linux-kernel, Tejun Heo, H. Peter Anvin, David Rientjes
In-Reply-To: <1319811801-1725-1-git-send-email-penberg@kernel.org>
On Fri, Oct 28, 2011 at 7:23 AM, Pekka Enberg <penberg@kernel.org> 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>
for this patch set:
Acked-by: Yinghai Lu <yinghai@kernel.org>
Thanks
Yinghai
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] Support running QEMU on Valgrind
From: Markus Armbruster @ 2011-10-31 18:30 UTC (permalink / raw)
To: Stefan Weil; +Cc: Avi Kivity, Alexander Graf, qemu-devel
In-Reply-To: <4EAED62D.3080602@weilnetz.de>
Stefan Weil <sw@weilnetz.de> writes:
> Am 31.10.2011 07:38, schrieb Markus Armbruster:
>> Alexander Graf <agraf@suse.de> writes:
>>> On 30.10.2011, at 13:07, Stefan Weil wrote:
>>>> Valgrind is a tool which can automatically detect many kinds of bugs.
>>>>
>>>> Running QEMU on Valgrind with x86_64 hosts was not possible because
>>>> Valgrind aborts when memalign is called with an alignment larger than
>>>> 1 MiB. QEMU normally uses 2 MiB on Linux x86_64.
>>>>
>>>> Now the alignment is reduced to the page size when QEMU is running on
>>>> Valgrind.
>>>>
>>>> valgrind.h is a copy from Valgrind svn trunk r12226 with trailing
>>>> whitespace stripped but otherwise unmodified, so it still raises lots
>>>> of errors when checked with scripts/checkpatch.pl.
>>>
>>> Can't we just require valgrind header files to be around when kvm
>>> is enabled? I would rather not copy code from other
>>> projects. Alternatively you could take the header and shrink it
>>> down to maybe 5 lines of inline asm code that would be a lot more
>>> readable :). You're #ifdef'ing on x86_64 already anyways.
>>>
>>>>
>>>> It is included here to avoid a dependency on Valgrind.
>> Our usual way to avoid a hard dependency on something we want is to
>> detect it in configure, then do something like
>>
>> #ifdef CONFIG_VALGRIND
>> #include "valgrind.h"
>> #else
>> #define RUNNING_ON_VALGRIND 0
>> #endif
>>
>> [...]
>
> Markus, you obviously did not read my last mail.
> I know how configure works, so there is no need to teach me.
Hope I didn't offend you; sorry if I did.
> I wrote that I decided against the configure solution because
> it is not adequate here. Adding a copy of valgrind.h which
> is explicitly made for being copied is simpler and better:
>
> * It avoids code in configure. There are already so many
> checks in configure that it takes a rather long time to run,
> and additional checks don't improve maintainability.
Configure does what it needs to do. If it's slow or hard to maintain,
we can discuss how to better solve the problem. Avoiding to solve parts
of the problem doesn't seem such a good idea, though.
> * It adds Valgrind support for any x86_64 QEMU binary
> without enforcing a build dependency on Valgrind.
> This is useful for QEMU packages in distributions.
I can't speak for other distributions, but over here we very much prefer
build dependencies over copies. Anyone who ever searched a bunch of
packages for copies containing a hot security hole will understand why.
> You said that copies are evil without explaining why you
> think so. What about the other copies in QEMU? There are
> lots of them, and some (e.g. the Linux headers) were added
> recently.
Copies are evil because we need to pick the one version that's right for
all our users. Repeatedly.
That's okay (sort of) when there's a tight coupling, and there's really
only one admissible version.
Or it may be a lesser evil when the thing copied isn't readily available
(not packaged in common distros).
I can't see either of that for valgrind.h.
^ permalink raw reply
* Re: [MIPS]clocks_calc_mult_shift() may gen a too big mult value
From: David Daney @ 2011-10-31 18:30 UTC (permalink / raw)
To: John Stultz, tglx@linutronix.de
Cc: zhangfx, Chen Jie, Yong Zhang, linux-mips@linux-mips.org, LKML,
yanhua, 项宇, 孙海勇
In-Reply-To: <1320084763.8964.22.camel@js-netbook>
On 10/31/2011 11:12 AM, John Stultz wrote:
> On Mon, 2011-10-31 at 21:59 +0800, zhangfx wrote:
[...]
>>
>> In short, choosing a mult close to 2^32 is dangerous. But I don't know
>> what's the best way to avoid it for general cases, because I don't know
>> how big error can be and the adj can be for different systems.
>
> Ah. Ok, sorry for being so slow to understand.
>
> So yea, I think you're right that the issue seems to be that for certain
> feq values, the resulting mult,shift pair is optimized a little too far,
> and we don't leave enough room for ntp adjustments to mult, without the
> possibility of overflowing mult.
>
> The following patch should handle it (although I'm at a conf right now,
> so I couldn't test it), although I might be trying to be too smart here.
> Rather then just checking if mult is larger then 0xf0000000, we try to
> quantify the largest valid mult adjustment, and then make sure mult +
> that value doesn't overflow. NTP limits adjustments to 500ppm, but the
> kernel might have to deal with larger internal adjustments. Probably we
> could be safe ruling out larger then 5% adjustments.
>
> So then its just a matter of 1/2^4. So the largest mult adjustment
> should be 1<< (cs->shift - 4)
>
> Does this seem reasonable? Let me know if this seems to work for you.
>
> Thomas: does this fix look like its in a reasonable spot? I don't want
> to clutter up the calc_mult_shift() code up since this really only
> applies to clocksources and not clockevents.
>
> NOT TESTED& NOT FOR INCLUSION (YET)
> Signed-off-by: John Stultz<john.stultz@linaro.org>
> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> index cf52fda..73518d2 100644
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -640,7 +640,7 @@ static void clocksource_enqueue(struct clocksource *cs)
> void __clocksource_updatefreq_scale(struct clocksource *cs, u32 scale, u32 freq)
> {
> u64 sec;
> -
> + u32 maxadj;
> /*
> * Calc the maximum number of seconds which we can run before
> * wrapping around. For clocksources which have a mask> 32bit
> @@ -661,6 +661,22 @@ void __clocksource_updatefreq_scale(struct clocksource *cs, u32 scale, u32 freq)
>
> clocks_calc_mult_shift(&cs->mult,&cs->shift, freq,
> NSEC_PER_SEC / scale, sec * scale);
> +
> + /*
> + * Since mult may be adjusted by ntp, add an extra saftey margin
> + * for clocksources that have large mults, to avoid overflow.
> + *
> + * Assume we won't try to correct for more then 5% adjustments
Can we do any better than making assumptions about this?
The current assumption appears to be that only very small adjustments
will be made, and that didn't workout so well.
Is it possible to put hard constraints on these things, so that it will
always work?
David Daney
> + * (50,000 ppm), which approximates to 1/16 or 1/2^4.
> + * Thus 1<< (shift - 4) is the largest mult adjustment we'll
> + * support.
> + */
> + maxadj = 1<< (shift-4);
> + if ((cs->mult + maxadj< cs->mult) || (cs->mult - maxadj> cs->mult)) {
> + cs->mult>>= 1;
> + cs->shift--;
> + }
> +
> cs->max_idle_ns = clocksource_max_deferment(cs);
> }
> EXPORT_SYMBOL_GPL(__clocksource_updatefreq_scale);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [U-Boot] [PATCH] gpio: Adapt PCA9698 to standard GPIO API
From: Mike Frysinger @ 2011-10-31 18:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320050352-17351-1-git-send-email-eibach@gdsys.de>
nice ...
Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/ff1b8df3/attachment.pgp
^ permalink raw reply
* Re: Setting proper video mode
From: Adam Jackson @ 2011-10-31 18:29 UTC (permalink / raw)
To: Jarek; +Cc: intel-gfx
In-Reply-To: <1320083294.7964.79.camel@tower.local>
On 10/31/11 1:48 PM, Jarek wrote:
> Dnia 2011-10-31, pon o godzinie 12:42 -0400, Adam Jackson pisze:
>> Also, how does the output of intel_reg_dumper compare between the two
>> drivers?
>
> As I understand, I should execute it, from running xorg. Am I right?
Yes.
> If I will find difference, what should I do ?
Well it depends what the differences are. Things like plane base
addresses being different wouldn't be surprising, but PLL setup might
matter. Just send reg dumps from both and we'll figure it out.
> The refresh rate comes from Xorg.0.log. With xf86-video-intel the
> display doesn't show any picture, only backlight is activated when I'm
> starting X.
> By the way, this MB has two LDVS outputs: LVDS1 and LVDS2. The second
> one is not connected to anything, but in the log both are connected.
We don't have any way of doing connection sense on LVDS so we have to
say they're connected if they appear at all. Otherwise you can't use them.
- ajax
^ permalink raw reply
* [U-Boot] [PATCH] ARM: define CONFIG_MACH_TYPE for all keymile boards
From: Mike Frysinger @ 2011-10-31 18:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE7CE6.8080109@compulab.co.il>
On Monday 31 October 2011 06:48:06 Igor Grinberg wrote:
> On 10/31/11 12:07, Valentin Longchamp wrote:
> > --- a/include/configs/km/km_arm.h
> > +++ b/include/configs/km/km_arm.h
> > @@ -48,6 +48,8 @@
> >
> > #define CONFIG_KW88F6281 /* SOC Name */
> > #define CONFIG_MACH_KM_KIRKWOOD /* Machine type */
> >
> > +#define CONFIG_MACH_TYPE MACH_TYPE_KM_KIRKWOOD
> > +
>
> Probably, you also want to remove the gd->bd->bi_arch_number
> assignment from board files using this mach id?
if possible, i'd like to punt bi_arch_number from everyone ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/6bc9bf6c/attachment.pgp
^ permalink raw reply
* Re: [PATCH] nfs: Fix unused variable warning.
From: Trond Myklebust @ 2011-10-31 18:28 UTC (permalink / raw)
To: Rakib Mullick; +Cc: linux-kernel, linux-nfs, akpm
In-Reply-To: <CADZ9YHgR=WHzCfJf7_T_WjHJJHzOnWZsM2bWSACwLHEcHy+h-g@mail.gmail.com>
On Tue, 2011-11-01 at 00:16 +0600, Rakib Mullick wrote:
> On Mon, Oct 31, 2011 at 11:43 PM, Trond Myklebust
> <Trond.Myklebust@netapp.com> wrote:
> > On Mon, 2011-10-31 at 23:12 +0600, Rakib Mullick wrote:
> >> On Mon, Oct 31, 2011 at 9:18 PM, Trond Myklebust
> >> <Trond.Myklebust@netapp.com> wrote:
> >> > On Fri, 2011-10-28 at 16:36 +0600, Rakib Mullick wrote:
> >> + data->inode->nfs_client->cl_hostname,
> > ^^^^^^^^^^^^
> > NFS_SERVER(data->inode)->nfs_client....
>
> Opss. Sorry, should've more careful, rather doing it quickly :(.
> data->inode has nothing inside named nfs_client, but didn't even
> complain. I'll resend it.
>
> Anyway, I found the two following warning in nfs/file.c
>
> fs/nfs/file.c: In function ‘nfs_file_release’:
> fs/nfs/file.c:140:17: warning: unused variable ‘dentry’
> fs/nfs/file.c: In function ‘nfs_file_read’:
> fs/nfs/file.c:237:9: warning: unused variable ‘count’
>
> I'm wanting to send one patch to cleanup all these unused variable
> issues. Shall I? Or, should I send separate patches?
Please send 2 patches: the stuff in fs/nfs/file.c looks as if it
predates the linux-3.1 release, and so we might want to keep those fixes
in a separate patch.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* Re: [PATCH] echo: fix octal escaping with \1...\7
From: Harald van Dijk @ 2011-10-31 18:07 UTC (permalink / raw)
To: dash
In-Reply-To: <4EAE9ECB.4040607@redhat.com>
On Mon, 2011-10-31 at 07:12 -0600, Eric Blake wrote:
> Scripts that rely on a certain interpretation of "echo '\1'" are broken
> regardless of how dash behaves; but that said, since POSIX doesn't
> require dash's current behavior, and since the proposed patch makes dash
> both smaller and more like other shells in treating it as an extension
> that means a literal 1 rather than an octal escape, I would be in favor
> of making the change in dash.
The problem with that is that the patch makes dash behave differently
from other shells in its interpretation of printf's %b format. bash, for
instance, does accept \1 escape sequences there, as an extension to
POSIX. Currently, so does dash. With this patch, it stops working in
dash. And unsharing the code between echo and printf would probably make
dash larger.
There's also another problem: the patch doesn't work as advertised
anyway. It should continue to make echo "\0101" print a single character
followed by newline. Instead, with that patch dash takes \010 as an
escape sequence, and then follows it by 1 and a newline.
Cheers,
Harald
^ permalink raw reply
* Re: root paths in packages
From: McClintock Matthew-B29882 @ 2011-10-31 18:27 UTC (permalink / raw)
To: Mike Tsukerman; +Cc: yocto@yoctoproject.org
In-Reply-To: <CALs2vtdoWAwy9S=6UMgwszm1njQH5wt2=_TZdLNZeTz-NoPSPw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]
On Mon, Oct 31, 2011 at 11:40 AM, Mike Tsukerman
<miketsukerman@gmail.com> wrote:
> I'am using upstream release from git repository.
> my building path is /media/mdev/yocto/poky/build/.
> For example dpkg rpm package for armv7 neon. But it's the same for all
> other packages. This cause many many errors and faults.
> i've attached to the letter screenshot with example.
> On Mon, Oct 31, 2011 at 8:32 PM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>>
>> On Mon, Oct 31, 2011 at 5:57 AM, Mike Tsukerman <miketsukerman@gmail.com>
>> wrote:
>> > Hello,
>> > I've build rpm packages and met some interesting things.
>> > In the rpm all scripts and files include root paths from machine that
>> > i've
>> > build on.
>> > how can i change that?
Mike,
You need to reply all to include the mailing list.
What commands did you run to generate this rpm? What file is this in?
Usually the shebang should be updated to remove any references to
build environment but it looks like it's still referencing perl-native
from the build environment.
Is this script used on the target machine or just during the build
process? It might not be explicitly required.
[-- Attachment #2: example.png --]
[-- Type: image/png, Size: 162063 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] Input: ALPS - Remove assumptions about packet size
From: Dmitry Torokhov @ 2011-10-31 18:24 UTC (permalink / raw)
To: Chase Douglas, Alessandro Rubini, Henrik Rydberg, Andrew Skalski,
linux-input, linux-kernel
In-Reply-To: <20111031181702.GB12205@thinkpad-t410>
On Mon, Oct 31, 2011 at 02:17:02PM -0400, Seth Forshee wrote:
> On Sun, Oct 30, 2011 at 11:36:19AM -0400, Chase Douglas wrote:
> > On 10/26/2011 05:14 PM, Seth Forshee wrote:
> > > In preparation for version 4 protocol support, which has 8-byte
> > > data packets, remove all hard-coded assumptions about packet size
> > > and use psmouse->pktsize instead.
> > >
> > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> > > ---
> > > drivers/input/mouse/alps.c | 27 ++++++++++++++++++---------
> > > 1 files changed, 18 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> > > index 572cb21..14d1f64 100644
> > > --- a/drivers/input/mouse/alps.c
> > > +++ b/drivers/input/mouse/alps.c
> > > @@ -315,7 +315,7 @@ static void alps_flush_packet(unsigned long data)
> > >
> > > serio_pause_rx(psmouse->ps2dev.serio);
> > >
> > > - if (psmouse->pktcnt == 6) {
> > > + if (psmouse->pktcnt == psmouse->pktsize) {
> > >
> > > /*
> > > * We did not any more data in reasonable amount of time.
> > > @@ -365,15 +365,15 @@ static psmouse_ret_t alps_process_byte(struct psmouse *psmouse)
> > > return PSMOUSE_BAD_DATA;
> > > }
> > >
> > > - /* Bytes 2 - 6 should have 0 in the highest bit */
> > > - if (psmouse->pktcnt >= 2 && psmouse->pktcnt <= 6 &&
> > > + /* Bytes 2 - pktsize should have 0 in the highest bit */
> > > + if (psmouse->pktcnt >= 2 && psmouse->pktcnt <= psmouse->pktsize &&
> > > (psmouse->packet[psmouse->pktcnt - 1] & 0x80)) {
> > > dbg("refusing packet[%i] = %x\n",
> > > psmouse->pktcnt - 1, psmouse->packet[psmouse->pktcnt - 1]);
> > > return PSMOUSE_BAD_DATA;
> > > }
> > >
> > > - if (psmouse->pktcnt == 6) {
> > > + if (psmouse->pktcnt == psmouse->pktsize) {
> > > alps_process_packet(psmouse);
> > > return PSMOUSE_FULL_PACKET;
> > > }
> > > @@ -531,8 +531,13 @@ static int alps_tap_mode(struct psmouse *psmouse, int enable)
> > > static int alps_poll(struct psmouse *psmouse)
> > > {
> > > struct alps_data *priv = psmouse->private;
> > > - unsigned char buf[6];
> > > + unsigned char *buf;
> > > bool poll_failed;
> > > + int ret = -1;
> > > +
> > > + buf = kmalloc(psmouse->pktsize, GFP_KERNEL);
> > > + if (!buf)
> > > + return -1;
> >
> > Can we preallocate a buffer somewhere instead of allocating every time
> > we enter the function? If we know the maximum packet size we could
> > allocate on the stack instead.
>
> Thanks for pointing that out; I had meant to come back and do something
> about this but forgot. I was hoping to avoid having to hard-code an
> assumed maximum packet size. I'll take a look at it.
probably doing something like
unsigned char buf[sizeof(psmouse->packet)];
will cover it.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 4/7] Input: ALPS - Remove assumptions about packet size
From: Dmitry Torokhov @ 2011-10-31 18:24 UTC (permalink / raw)
To: Chase Douglas, Alessandro Rubini, Henrik Rydberg, Andrew Skalski,
linux-input
In-Reply-To: <20111031181702.GB12205@thinkpad-t410>
On Mon, Oct 31, 2011 at 02:17:02PM -0400, Seth Forshee wrote:
> On Sun, Oct 30, 2011 at 11:36:19AM -0400, Chase Douglas wrote:
> > On 10/26/2011 05:14 PM, Seth Forshee wrote:
> > > In preparation for version 4 protocol support, which has 8-byte
> > > data packets, remove all hard-coded assumptions about packet size
> > > and use psmouse->pktsize instead.
> > >
> > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> > > ---
> > > drivers/input/mouse/alps.c | 27 ++++++++++++++++++---------
> > > 1 files changed, 18 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> > > index 572cb21..14d1f64 100644
> > > --- a/drivers/input/mouse/alps.c
> > > +++ b/drivers/input/mouse/alps.c
> > > @@ -315,7 +315,7 @@ static void alps_flush_packet(unsigned long data)
> > >
> > > serio_pause_rx(psmouse->ps2dev.serio);
> > >
> > > - if (psmouse->pktcnt == 6) {
> > > + if (psmouse->pktcnt == psmouse->pktsize) {
> > >
> > > /*
> > > * We did not any more data in reasonable amount of time.
> > > @@ -365,15 +365,15 @@ static psmouse_ret_t alps_process_byte(struct psmouse *psmouse)
> > > return PSMOUSE_BAD_DATA;
> > > }
> > >
> > > - /* Bytes 2 - 6 should have 0 in the highest bit */
> > > - if (psmouse->pktcnt >= 2 && psmouse->pktcnt <= 6 &&
> > > + /* Bytes 2 - pktsize should have 0 in the highest bit */
> > > + if (psmouse->pktcnt >= 2 && psmouse->pktcnt <= psmouse->pktsize &&
> > > (psmouse->packet[psmouse->pktcnt - 1] & 0x80)) {
> > > dbg("refusing packet[%i] = %x\n",
> > > psmouse->pktcnt - 1, psmouse->packet[psmouse->pktcnt - 1]);
> > > return PSMOUSE_BAD_DATA;
> > > }
> > >
> > > - if (psmouse->pktcnt == 6) {
> > > + if (psmouse->pktcnt == psmouse->pktsize) {
> > > alps_process_packet(psmouse);
> > > return PSMOUSE_FULL_PACKET;
> > > }
> > > @@ -531,8 +531,13 @@ static int alps_tap_mode(struct psmouse *psmouse, int enable)
> > > static int alps_poll(struct psmouse *psmouse)
> > > {
> > > struct alps_data *priv = psmouse->private;
> > > - unsigned char buf[6];
> > > + unsigned char *buf;
> > > bool poll_failed;
> > > + int ret = -1;
> > > +
> > > + buf = kmalloc(psmouse->pktsize, GFP_KERNEL);
> > > + if (!buf)
> > > + return -1;
> >
> > Can we preallocate a buffer somewhere instead of allocating every time
> > we enter the function? If we know the maximum packet size we could
> > allocate on the stack instead.
>
> Thanks for pointing that out; I had meant to come back and do something
> about this but forgot. I was hoping to avoid having to hard-code an
> assumed maximum packet size. I'll take a look at it.
probably doing something like
unsigned char buf[sizeof(psmouse->packet)];
will cover it.
--
Dmitry
^ permalink raw reply
* [U-Boot] [PATCH] miiphy: Note that miiphy_* API is deprecated
From: Mike Frysinger @ 2011-10-31 18:24 UTC (permalink / raw)
To: u-boot
In-Reply-To: <10B6933F-AEDD-49DA-9361-5868A5F2F327@freescale.com>
On Monday 31 October 2011 11:12:12 Andy Fleming wrote:
> On Oct 31, 2011, at 10:08 AM, Tabi Timur-B04825 wrote:
> > On Mon, Oct 31, 2011 at 9:46 AM, Andy Fleming wrote:
> >> We want to move everything to phylib, and we definitely don't want
> >> new drivers using the miiphy infrastructure.
> >
> > How about using gcc's deprecated function feature? Or is that too
> > aggressive?
>
> I don't think we want every net driver prior to the last release to create
> a warning. We may switch to that after we get some momentum on switching
> drivers over. The first goal is just to provide information that a new
> driver-writer may see so that the old API doesn't expand.
right, this is why i didn't suggest a #warning or __deprecated before. i'm
pretty sure way more code is using the old phy layer than the new phy layer
atm.
i also want to say that the new phy layer doesn't have all the support that
the old one did ... if you look in include/miiphy.h, there are a few defines at
the end there which are not in linux/mii.h.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/296b8b1e/attachment.pgp
^ permalink raw reply
* Re: [nfsv4] [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
From: Matt W. Benjamin @ 2011-10-31 18:23 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-nfs, nfsv4 list, Benny Halevy
In-Reply-To: <1320085212.4714.48.camel@lade.trondhjem.org>
Hi,
Such a server implementation will certainly not be long in coming.
Matt
----- "Trond Myklebust" <Trond.Myklebust@netapp.com> wrote:
> On Mon, 2011-10-31 at 19:57 +0200, Benny Halevy wrote:
> >
> > Waiting for revocation may work well with some servers but would be
> disastrous in
> > terms of performance and responsiveness with others.
>
> I don't necessarily disagree with what you are saying, but I have yet
> to
> see a single server side implementation of CB_RECALL_ANY, let alone
> any
> numbers that indicate performance or responsiveness problems
> resulting
> from our existing client-side implementation.
>
> I therefore find it hard to understand why optimising this particular
> code is such a high priority, or why a patch that is adding per-file
> layoutreturns to initiate_bulk_draining() is going to help anything
> at
> all.
>
> Trond
>
--
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI 48104
http://linuxbox.com
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 18:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: git, James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFz3=cbciRfTYodNhdEetXYxTARGTfpP9GL9RZK222XmKQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> For the people who use "git request-pull", I'm attaching a trivial
> patch to make it add this kind of signature if you give it the "-s"
> flag. It basically just adds a hunk like the appended crazy example to
> the pull request, and it's small enough and simple enough that it
> makes verification simple too with just the above kind of trivial
> cut-and-paste thing.
>
> (Junio cc'd, I think he had something more complicated in mind)
You have misread me this time.
I think the minimalistic "paste this line to your 'git pull' command line
and expect to get history leading to this commit" like you did in your
patch would be the solution that is the least painful and still useful,
which is an important criterion for wide adoption.
> Now, admittedly it would be *even nicer* if this gpg-signed block was
> instead uploaded as a signed tag automatically, and "git pull" would
> notice such a signed tag (tagname the same as the branch name + date
> or something) and would download and verify the tag as I pull. Then I
> wouldn't even need to actually do the cut-and-paste at all. But this
> is the *really* simple approach that gets up 95% of the way there.
I however have a small trouble with "lieutenants use signed tags in order
to prove who they are to Linus", depending on the details.
It certainly lets you run "git tag --verify" after you pulled and will
give you assurance that you pulled the right thing from the right person,
but what do you plan to do to the tag from your lieutenants after you
fetched and verified? I count 379 merges by you between 3.0 (2011-07-21)
and 3.1 (2011-10-24), which would mean you would see 4-5 tags per day on
average. Will these tags be pushed out to your public history?
On one hand, we (not just you but the consumers of "Linus kernel") can
consider these tags are of ephemeral nature. Once they are used for _you_
to verify the authenticity, they are not needed anymore. The consumers of
"Linus kernel" by definition trusts what you publish, so as long as they
have a way to verify the tip commit you push out, they _should_ be happy.
If you take this stance, you would not push these tags out so that you do
not have to contaminate the tags namespace with them, and you might even
choose to discard them once you pulled and verified the lieutenants' tips
to avoid contamination of your own refs namespace.
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. Keeping signed tags and publishing them
is one way to make it possible, but 400 extra tags in 3 months feels like
an approach with too much downside (i.e. noise) for that benefit.
On Git mailing list, we have been toying with a couple of ideas. The
simplest one (cooking in next) is to allow committers to add gpg signature
in an additional header of the commit objects. "git show" and friends are
taught how to verify these signatures when asked.
This might have a potential downside on the lieutenants' workflow; after
integrating the work by their sub-lieutenants and by themselves, they
would test and review the result to convince themselves that it is worth
asking you to pull, and then they have to either
(1) "commit --amend --gpg-signature" the tip; or
(2) "commit --allow-empty --gpg-signature" to add an empty commit
whose sole purpose is to hold the signature (and avoid amending
the tip)
before pushing it out, asking you to pull.
An alternative we have discussed was to store gpg signature for the commit
("push certificate") somewhere in notes tree and push that out, certifying
that the commit indeed came from the pusher, but that would:
(1) require upstreams to fetch (and possibly suffer from merge conflicts
in notes tree) push certificate whenever they pull from their
lieutenants; and
(2) require downstreams to also fetch the notes tree for "push
certificates" (especially when the central repository is shared among
multiple people) before adding their own signature and then push it
back (and possiblly suffer from "non-fast-forward" in notes tree).
both of which are downsides coming from "notes" being not a very good
match for what these signatures are trying to achieve.
Namely, the current "notes" mechanism is designed to keep track of history
of changes made to notes attached to commits, but for the signature
application, we do not care about the order that signatures came to two
separate commits. "Non-fast-forward" conflicts while pushing, or having to
fetch and merge before adding one's own signature, are unwanted burden
imposed only by choosing to use "notes" for storing and conveying the
signature.
Also the "notes" approach would end up mixing "push certificates" for
different branches (this won't be an issue in your repository where there
is only one branch) into a single "notes" tree. We would want to use
something that behaves more like the "auto-following" semantics of tag
objects. You would want to fetch only signatures that are attached to the
commits you are fetching. Use of signed tags, or commit objects that can
be signed in-place, have this property, but storing signature in notes
tree does not give it to us.
I think further discussions on this should continue on the git mailing
list.
^ permalink raw reply
* [U-Boot] [PATCH 1/2] PXA: Add MMC driver using the generic MMC framework
From: Marek Vasut @ 2011-10-31 18:23 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1314568975-19619-1-git-send-email-marek.vasut@gmail.com>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> ---
> arch/arm/include/asm/arch-pxa/regs-mmc.h | 155 +++++++++++
> drivers/mmc/Makefile | 1 +
> drivers/mmc/pxa_mmc_gen.c | 442
> ++++++++++++++++++++++++++++++ 3 files changed, 598 insertions(+), 0
> deletions(-)
> create mode 100644 arch/arm/include/asm/arch-pxa/regs-mmc.h
> create mode 100644 drivers/mmc/pxa_mmc_gen.c
Hey Andy,
maybe you can pick this up now?
Cheers
^ 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.