> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> index
> d17c473c1ef292875475bf3bdf62d07241c13882..d713a6445a6267145a7014f308d
> f3bb25b8c3287 100644
> --- a/include/linux/sysfs.h
> +++ b/include/linux/sysfs.h
> @@ -305,8 +305,12 @@ struct bin_attribute {
> struct address_space
On Fri, 2024-06-28 at 10:54 +1000, Michael Ellerman wrote:
> Stefan Berger writes:
> > Fix the following type of error message caused by a missing call to
> > tpm2_sessions_init() in the IBM vTPM driver:
> >
> > [ 2.987131] tpm tpm0: tpm2_load_context: failed with a TPM error
> > 0x01C4
> > [
On Mon, 2024-06-17 at 15:56 -0400, Stefan Berger wrote:
>
>
> On 6/17/24 15:42, James Bottomley wrote:
> > On Mon, 2024-06-17 at 15:34 -0400, Stefan Berger wrote:
> > > Fix the following type of error message caused by a missing call
> > > to
> > > t
On Mon, 2024-06-17 at 15:34 -0400, Stefan Berger wrote:
> Fix the following type of error message caused by a missing call to
> tpm2_sessions_init() in the IBM vTPM driver:
>
> [ 2.987131] tpm tpm0: tpm2_load_context: failed with a TPM error
> 0x01C4
> [ 2.987140] ima: Error Communicating to
On Mon, 2022-11-21 at 16:05 +0100, Greg Kroah-Hartman wrote:
> On Mon, Nov 21, 2022 at 09:03:18AM -0500, James Bottomley wrote:
> > On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote:
> > > On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote:
[...]
> >
On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote:
> On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote:
> > On Sun, 2022-11-20 at 17:13 +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Nov 19, 2022 at 01:20:09AM -0500, Nayna wrote:
> > > >
&
objects are not namespaced. I mentioned it here as an
> > > > example of the difference between firmware and kernel objects.
> > > > It is also in response to the feedback from James Bottomley in
> > > > RFC v2 [
> > > > https://lore.kernel.org/linuxpp
On Thu, 2022-06-23 at 10:54 +0200, Greg Kroah-Hartman wrote:
[...]
> > diff --git a/fs/fwsecurityfs/inode.c b/fs/fwsecurityfs/inode.c
> > new file mode 100644
> > index ..5d06dc0de059
> > --- /dev/null
> > +++ b/fs/fwsecurityfs/inode.c
> > @@ -0,0 +1,159 @@
> > +// SPDX-License-Identifi
On Mon, 2022-02-28 at 23:59 +0200, Mike Rapoport wrote:
>
> On February 28, 2022 10:42:53 PM GMT+02:00, James Bottomley <
> james.bottom...@hansenpartnership.com> wrote:
> > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
[...]
> > > > I do wish we coul
On Mon, 2022-02-28 at 21:56 +0100, Christian König wrote:
>
> Am 28.02.22 um 21:42 schrieb James Bottomley:
> > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
> > > Am 28.02.22 um 20:56 schrieb Linus Torvalds:
> > > > On Mon, Feb 28, 2022 at 4:19
On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
> Am 28.02.22 um 20:56 schrieb Linus Torvalds:
> > On Mon, Feb 28, 2022 at 4:19 AM Christian König
> > wrote:
> > > I don't think that using the extra variable makes the code in any
> > > way
> > > more reliable or easier to read.
> > So I
On Tue, 2022-02-01 at 15:41 +0100, Greg KH wrote:
> On Tue, Feb 01, 2022 at 09:24:50AM -0500, James Bottomley wrote:
> > [cc's added]
> > On Tue, 2022-02-01 at 14:50 +0100, Greg KH wrote:
[...]
> > > You all need to work together to come up with a unified place for
[cc's added]
On Tue, 2022-02-01 at 14:50 +0100, Greg KH wrote:
> On Tue, Feb 01, 2022 at 12:44:08PM +, Dov Murik wrote:
[...]
> > # ls -la /sys/kernel/security/coco/efi_secret
> > total 0
> > drwxr-xr-x 2 root root 0 Jun 28 11:55 .
> > drwxr-xr-x 3 root root 0 Jun 28 11:54 ..
> > -r--r- 1 r
On Fri, 2020-10-09 at 14:34 -0700, Eric Biggers wrote:
> On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The kmap() calls in this FS are localized to a single thread. To
> > avoid the over head of global PKRS updates use the new
> > kmap_thread()
On Mon, 2020-08-17 at 12:28 -0700, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 07:41:58AM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> > > From: Allen Pais
> > >
> > > Commit 12cc923f1ccc ("tasklet: Introduce new
On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> From: Allen Pais
>
> Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> introduced a new tasklet initialization API. This series converts
> all the scsi drivers to use the new tasklet_setup() API
I've got to say I agree wi
On Tue, 2020-06-16 at 14:13 +, Johannes Thumshirn wrote:
> On 16/06/2020 16:09, Bart Van Assche wrote:
> > On 2020-06-16 02:42, Finn Thain wrote:
> > > Martin said, "I'd appreciate a patch to remove it"
> > >
> > > And Bart said, "do you want to keep this driver in the kernel
> > > tree?"
> >
On Wed, 2020-03-04 at 07:35 -0500, Mimi Zohar wrote:
> On Tue, 2020-03-03 at 23:43 -0800, James Bottomley wrote:
> > On Tue, 2020-03-03 at 21:33 -0500, Nayna Jain wrote:
> > > diff --git a/security/integrity/ima/Kconfig
> > > b/security/integrity/ima/Kconfig
> > &
On Tue, 2020-03-03 at 21:33 -0500, Nayna Jain wrote:
> Every time a new architecture defines the IMA architecture specific
> functions - arch_ima_get_secureboot() and arch_ima_get_policy(), the
> IMA
> include file needs to be updated. To avoid this "noise", this patch
> defines a new IMA Kconfig I
On Thu, 2019-08-08 at 19:00 +0300, Christoph Hellwig wrote:
> parisc is the only architecture that sets ARCH_NO_COHERENT_DMA_MMAP
> when an MMU is enabled. AFAIK this is because parisc CPUs use VIVT
> caches,
We're actually VIPT but the same principle applies.
> which means exporting normally c
On Fri, 2019-01-18 at 11:57 -0500, Dennis Clarke wrote:
> On 1/18/19 11:18 AM, Arnd Bergmann wrote:
> > This is a minor update of the patches I posted last week, I
> > would like to add this into linux-next now, but would still do
> > changes if there are concerns about the contents. The first
> >
On Sun, 2018-12-30 at 18:50 +0100, LEROY Christophe wrote:
> Arnd Bergmann a écrit :
> > On Sat, Dec 29, 2018 at 3:51 AM Michael Schmitz
> > wrote:
[...]
> > > (On second thought - I don't want to speculate whether there's
> > > weird compiler options that could result in the
> > > nvram_check_ch
On Wed, 2017-10-18 at 18:10 +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 17, 2017 at 08:57:13AM -0700, James Bottomley wrote:
> >
> > On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote:
> > >
> > > >
> > > >
> > >
On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote:
> >
> > Fixes is only for bug fixes. These don't fix any bugs.
>
> How do you distinguish these in questionable source code
> from other error categories or software weaknesses?
A style change is one that doesn't change the effect of t
On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote:
> > Elena Reshetova writes:
> >
> > > refcount_t type and corresponding API should be
> > > used instead of atomic_t when the variable is used as
> > > a reference counter. This allows to avoid accidental
> > > refcounter overflows that m
On Fri, 2016-02-12 at 08:51 -0800, Tyrel Datwyler wrote:
> On 02/12/2016 08:43 AM, James Bottomley wrote:
> > On Wed, 2016-02-10 at 19:32 -0600, Tyrel Datwyler wrote:
> > > Add defines for mad version and mad os_type, and replace the
> > > magic
> > > numbe
On Wed, 2016-02-10 at 19:32 -0600, Tyrel Datwyler wrote:
> Add defines for mad version and mad os_type, and replace the magic
> numbers in set_adapter_info() accordingly.
>
> Signed-off-by: Tyrel Datwyler
> ---
Is there some reason you didn't carry the review tag over from this:
http://mid.gman
Could you please add a cover letter (a 0/30) and thread your patches
from that? For large patch series, it really does make following
everything a lot easier for me (and most other people who use a threaded
mail reader).
Thanks,
James
___
Linuxppc-de
On Thu, 2015-08-13 at 20:30 -0700, Dan Williams wrote:
> On Thu, Aug 13, 2015 at 7:31 AM, Christoph Hellwig wrote:
> > On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote:
> >> I'm assuming that anybody who wants to use the page-less
> >> scatter-gather lists always does so on memory th
On Wed, 2015-08-12 at 09:05 +0200, Christoph Hellwig wrote:
> Dan Williams started to look into addressing I/O to and from
> Persistent Memory in his series from June:
>
> http://thread.gmane.org/gmane.linux.kernel.cross-arch/27944
>
> I've started looking into DMA mapping of these SGLs spe
On Wed, 2015-05-13 at 15:31 +0200, Arnd Bergmann wrote:
> On Wednesday 13 May 2015 08:23:41 Brian King wrote:
> > On 05/13/2015 03:10 AM, Arnd Bergmann wrote:
> > > On Tuesday 12 May 2015 18:24:43 Brian King wrote:
> > >>
> > >> Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for
On Fri, 2014-10-24 at 10:40 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
> > Hey guys, was looking over the generic GUP while working on a sparc64
> > issue and I noticed that you guys do speculative page gets, and after
> > talking with Johannes Wei
On Tue, 2014-09-09 at 06:40 -0400, Peter Hurley wrote:
> On 09/08/2014 10:56 PM, James Bottomley wrote:
> > On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
> >> On 09/08/2014 01:50 AM, James Bottomley wrote:
> >>>> But additionally, even if gcc combin
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
> On 09/08/2014 01:50 AM, James Bottomley wrote:
> >> Two things: I think that gcc has given up on combining adjacent writes,
> >> perhaps because unaligned writes on some arches are prohibitive, so
> >> w
On Mon, 2014-09-08 at 16:45 -0400, Chris Metcalf wrote:
> On 9/8/2014 1:50 AM, James Bottomley wrote:
> > Actual alignment is pretty irrelevant. That's why all architectures
> > which require alignment also have to implement misaligned traps ... this
> > is a fund
On Mon, 2014-09-08 at 12:12 -0700, H. Peter Anvin wrote:
> On 09/08/2014 12:09 PM, James Bottomley wrote:
> >
> > Um, I think you need to re-read the thread; that's not what I said at
> > all. It's even written lower down: "PA can't do atomic bit sets (no
On Mon, 2014-09-08 at 11:12 -0700, H. Peter Anvin wrote:
> On 09/07/2014 10:56 PM, James Bottomley wrote:
> > On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
> >> How many PARISC systems do we have that actually do real work on Linux?
> >
> > I'd be ve
On Mon, 2014-09-08 at 18:52 +0100, One Thousand Gnomes wrote:
> On Fri, 05 Sep 2014 08:41:52 -0700
> "H. Peter Anvin" wrote:
>
> > On 09/05/2014 08:31 AM, Peter Hurley wrote:
> > >
> > > Which is a bit ironic because I remember when Digital had a team
> > > working on emulating native x86 apps o
> > Thanx, Paul
> >
> >> On September 7, 2014 4:00:19 PM PDT, "Paul E. McKenney"
> > wrote:
> >> >On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
> >> >> On Sun, 2014-09-0
On Sun, 2014-09-07 at 16:41 -0400, Peter Hurley wrote:
> On 09/07/2014 03:04 PM, James Bottomley wrote:
> > On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
> >> On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
> >>> On Thu, 2014-09-04 at
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
> On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
> > On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
> > > On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
> > > > Hi
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
> On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
> > Hi James,
> >
> > On 09/04/2014 10:11 PM, James Bottomley wrote:
> > > On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
> &g
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
> +And there are anti-guarantees:
> +
> + (*) These guarantees do not apply to bitfields, because compilers often
> + generate code to modify these using non-atomic read-modify-write
> + sequences. Do not attempt to use bitfields t
On Sat, 2014-03-22 at 22:52 +, Russell King - ARM Linux wrote:
> On Sat, Mar 22, 2014 at 03:37:40PM -0700, James Bottomley wrote:
> > On Sat, 2014-03-22 at 22:23 +, Russell King - ARM Linux wrote:
> > > On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
&
On Sat, 2014-03-22 at 22:23 +, Russell King - ARM Linux wrote:
> On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
> > Perhaps now might be the time to ask which are the remaining
> > architectures that cannot do SG chaining and then we can fix them and
> >
On Sat, 2014-03-22 at 11:13 -0700, Laura Abbott wrote:
> Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture
> specific scatterlist.h, make it a proper Kconfig option and use that
> instead. At same time, remove the header files are are now mostly
> useless and just include
On Mon, 2013-02-04 at 10:09 +, James Hogan wrote:
> The IRQ_PER_CPU Kconfig symbol was removed in the following commit:
>
> Commit 6a58fb3bad099076f36f0f30f44507bc3275cdb6 ("genirq: Remove
> CONFIG_IRQ_PER_CPU") merged in v2.6.39-rc1.
>
> But IRQ_PER_CPU wasn't removed from any of the archite
On Wed, 2013-01-23 at 17:29 -0800, Michel Lespinasse wrote:
> Update the parisc arch_get_unmapped_area function to make use of
> vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse
> Acked-by: Rik van Riel
>
> ---
> arch/parisc/kernel/sys_paris
On Fri, 2012-07-27 at 15:19 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-07-18 at 18:49 +0200, o...@aepfle.de wrote:
> > From: Linda Xie
>
> James, can I assume you're picking up those two ?
If they get acked by the maintiners ...
James
___
L
On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
> wrote:
> + lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
> constraints in an 'asm': => 50:70
> + lib/mpi/generic_mpih-mul2.c: error: inconsistent operand
> constrai
On Tue, 2011-12-27 at 09:25 +0100, Marek Szyprowski wrote:
[...]
> > > Usually these drivers don't touch the buffer data at all, so the mapping
> > > in kernel virtual address space is not needed. We can introduce
> > > DMA_ATTRIB_NO_KERNEL_MAPPING attribute which lets kernel to skip/ignore
> > > c
On Tue, 2011-08-30 at 08:32 +1000, Stephen Rothwell wrote:
> Hi Linus,
>
> On Mon, 29 Aug 2011 10:44:51 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the fixes tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > arch/powerpc/kernel/built-in.o: In funct
On Thu, 2011-05-19 at 13:08 +0900, Hitoshi Mitake wrote:
> On Thu, May 19, 2011 at 04:11, Moore, Eric wrote:
> > On Wednesday, May 18, 2011 12:31 PM Milton Miller wrote:
> >> Ingo I would propose the following commits added in 2.6.29 be reverted.
> >> I think the current concensus is drivers must
On Tue, 2011-05-17 at 22:15 -0600, Matthew Wilcox wrote:
> On Wed, May 18, 2011 at 09:37:08AM +0530, Desai, Kashyap wrote:
> > On Wed, 2011-05-04 at 17:23 +0530, Kashyap, Desai wrote:
> > > The following code seems to be there in
> > > /usr/src/linux/arch/x86/include/asm/io.h.
> > > This is not go
_zero(v) atomic_add_unless((v), -1, 0)
> >
> > /*
> > * atomic_inc_and_test - increment and test
>
> no opinion on the actual idea, but for the Blackfin pieces:
> Acked-by: Mike Frysinger
This goes for parisc as well.
Acked-by: James Bottomley
James
On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
> On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
> >
> > Hi,
> >
> > this series makes it possible to build bit-identical kernel image and
> > modules from identical sources. Of course the build is already
> > deterministic in terms
On Wed, 2009-12-02 at 17:51 -0800, Pravin Bathija wrote:
> Powerpc 44x uses 36 bit real address while the real address defined
> in MPT Fusion driver is of type 32 bit. This causes ioremap to fail and
> driver
> fails to initialize. This fix changes the data types representing the real
>
On Thu, 2009-11-05 at 08:43 -0500, Josh Boyer wrote:
> On Tue, Sep 15, 2009 at 03:25:55PM -0700, pbath...@amcc.com wrote:
> >From: Pravin Bathija
> >
> >Powerpc 44x uses 36 bit real address while the real address defined
> >in MPT Fusion driver is of type 32 bit. This causes ioremap to fail and
>
On Mon, 2009-06-22 at 11:11 -0500, Brian King wrote:
> James,
>
> I was running into a similar hang on one of my Power boxes as well.
> Reverting c868d550115b9ccc0027c67265b9520790f05601 allowed by system
> to boot. It looks like that patch injected a bug where we can end up
> waiting on an uninit
2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I
can begin bisecting.
The boot log of the hang is:
Please wait, loading kernel...
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 0250, size: 8280 Kbytes
OF stdout device is: /ht/i...@8/ser...@2f8
Preparing t
On Thu, 2009-05-21 at 14:51 -0500, James Bottomley wrote:
> On Thu, 2009-05-21 at 13:47 -0500, Brian King wrote:
> > cc'ing linuxppc-dev...
> >
> > -Brian
> >
> >
> > James Bottomley wrote:
> > > Kernels after 2.6.30-rc1 stopped booting
On Thu, 2009-05-21 at 13:47 -0500, Brian King wrote:
> cc'ing linuxppc-dev...
>
> -Brian
>
>
> James Bottomley wrote:
> > Kernels after 2.6.30-rc1 stopped booting on my powerstation. The ipr
> > just times out and refuses to probe devices. If I let it drop
On Thu, 2009-03-26 at 12:04 +0530, Sachin Sant wrote:
> Sachin Sant wrote:
> > Today's next failed to boot on a powerpc box
> > (Power6 blade IBM,7998-61X) with following recursive locking message.
> >
> > =
> > [ INFO: possible recursive locking detected
On Mon, 2009-02-09 at 11:11 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2009-02-08 at 22:29 +1100, Michael Ellerman wrote:
> > On Fri, 2009-02-06 at 18:42 -0800, Geoff Levand wrote:
> > > Change the PS3 platform code to use hard coded numbers for its
> > > LV1 device types.
> > >
> > > The PS3
On Wed, 2008-09-10 at 10:09 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2008-09-09 at 19:04 -0500, James Bottomley wrote:
> > commit deac93df26b20cf8438339b5935b5f5643bc30c9
> > Author: James Bottomley <[EMAIL PROTECTED]>
> > Date: Wed Sep 3 20:43:36 2008 -050
commit deac93df26b20cf8438339b5935b5f5643bc30c9
Author: James Bottomley <[EMAIL PROTECTED]>
Date: Wed Sep 3 20:43:36 2008 -0500
lib: Correct printk %pF to work on all architectures
Broke the non modular builds by moving an essential function into
modules.c. Fix this by moving it out
OK, so could we get this in to -rc5 please? It's a bug fix for parisc
since we're currently printing rubbish.
James
---
From: James Bottomley <[EMAIL PROTECTED]>
Date: Wed, 3 Sep 2008 20:43:36 -0500
Subject: lib: Correct printk %pF to work on all architectures
It was intro
On Wed, 2008-09-03 at 17:01 -0700, Linus Torvalds wrote:
>
> On Wed, 3 Sep 2008, James Bottomley wrote:
> >
> > Oh ... because Arjan has a patch to export
> > dereference_function_descriptor. I suppose I could make him do the
> > heavy lifting, but it seemed se
On Wed, 2008-09-03 at 16:15 -0700, Linus Torvalds wrote:
>
> On Wed, 3 Sep 2008, James Bottomley wrote:
> >
> > You want me to pull the elf header files into lib/vsprintf.c and have
> > something like
>
> No.
>
> I want you to stop polluting with total and
On Wed, 2008-09-03 at 15:54 -0700, Linus Torvalds wrote:
> > Anyway, it's easy to do (if a slightly larger diff) ... I have to move
> > the prototype from include/kernel.h to include/module.h because I need
> > an assured asm/xxx include before it to get the override.
>
> I don't really see what t
On Wed, 2008-09-03 at 14:22 -0700, Linus Torvalds wrote:
>
> On Wed, 3 Sep 2008, James Bottomley wrote:
> >
> > Make dereference_function_descriptor() more accommodating by allowing
> > architecture overrides.
>
> Don't do it like this.
>
> We don'
le.c because that's where the kernel
internal linker which knows how to deal with function descriptors sits.
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
arch/ia64/kernel/module.c |9 +
arch/parisc/kernel/module.c | 13 +
arch/powerpc/ker
On Tue, 2008-07-08 at 08:05 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2008-07-07 at 09:39 -0500, James Bottomley wrote:
> > > Caused because commit 341b56db6804040aa9559e913865108424e3b18b
> > ("[SCSI]
> > > ibmvscsi: driver enablement for CMO"),
Correct cc's added
On Mon, 2008-07-07 at 22:25 +1000, Stephen Rothwell wrote:
> Hi James,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'map_sg_data':
> drivers/scsi/ibmvscsi/ibmvscsi.c:431: error: 'FW_FEATURE_CMO' unde
On Tue, 2008-06-10 at 10:41 -0700, Jesse Barnes wrote:
> On Monday, June 09, 2008 11:56 pm Nick Piggin wrote:
> > So that still doesn't tell us what *minimum* level of ordering we should
> > provide in the cross platform readl/writel API. Some relatively sane
> > suggestions would be:
> >
> > - as
On Thu, 2008-05-29 at 10:47 -0400, Jes Sorensen wrote:
> > "Roland" == Roland Dreier <[EMAIL PROTECTED]> writes:
>
> >> This is a different issue. We deal with it on powerpc by having
> >> writel set a per-cpu flag and spin_unlock() test it, and do the
> >> barrier if needed there.
>
> Roland
On Tue, 2008-05-27 at 10:38 -0700, Roland Dreier wrote:
> > Actually, this specifically should not be. The need for mmiowb on altix
> > is because it explicitly violates some of the PCI rules that would
> > otherwise impede performance. The compromise is that readX on altix
> > contains the n
On Tue, 2008-05-27 at 08:50 -0700, Roland Dreier wrote:
> > Though it's my understanding that at least ia64 does require the
> > explicit barriers anyway, so we are still in a dodgy situation here
> > where it's not clear what drivers should do and we end up with
> > possibly excessive barriers
On Fri, 2007-09-14 at 12:50 -0700, Medve Emilian-EMMEDVE1 wrote:
> Which solution would you be more comfortable with?
The one which is currently in -mm is this one:
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=49892223f7d3a2333ef9e6cbdd526676e1fc517a
James
__
On Tue, 2007-07-17 at 07:49 +1000, Benjamin Herrenschmidt wrote:
> > No ... that was the point of flush_kernel_dcache_page(). The page in
> > question is page cache backed and contains user mappings. However, the
> > block layer has already done a flush_dcache_page() in get_user_pages()
> > and t
On Mon, 2007-07-16 at 14:16 +0200, Jens Axboe wrote:
> On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > > I'll update my patches. Thanks for the comments!
> >
> > Does this
On Fri, 2007-07-13 at 17:10 +0200, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Arnd Bergmann wrote:
> > On Friday 13 July 2007, James Bottomley wrote:
> > > > IC.
> > > >
> > > > - flush_kernel_dcache_page() is a no-op on ppc64
> > >
On Fri, 2007-07-13 at 15:45 +0200, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, James Bottomley wrote:
> > On Fri, 2007-07-13 at 15:25 +0200, Geert Uytterhoeven wrote:
> > > kmap() just returns page_address() on ppc64, as there's no highmem.
> > > kunmap() is a
On Fri, 2007-07-13 at 15:25 +0200, Geert Uytterhoeven wrote:
> kmap() just returns page_address() on ppc64, as there's no highmem.
> kunmap() is a no-op.
> So technically I could just use page_address() directly, but Christoph
> wanted
> me to keep the kmap()/kunmap() sequence because it's conside
On Wed, 2007-07-04 at 15:22 +0200, Geert Uytterhoeven wrote:
> + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> + if (!kaddr)
> + return -1;
> + len = sgpnt->length;
> + if ((req_len
85 matches
Mail list logo
