Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.

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 pbath...@amcc.com 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

Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.

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

Re: [patch] powerpc/ps3: Use hard coded values for LV1 device type

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 platform code

Re: Next March 25: Boot failure on powerpc [recursive locking detected]

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 ]

Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver

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 (ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE is defined on parisc only

Re: CONFIG_BLK_DEV_BSG=n

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

Re: MMIO and gcc re-ordering issue

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

Re: MMIO and gcc re-ordering issue

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 needed

Re: MMIO and gcc re-ordering issue

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 Cool... I assume you

Re: MMIO and gcc re-ordering issue

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 strong as

Re: linux-next: scsi tree build failure

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'

Re: linux-next: scsi tree build failure

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), which was 15/16 in a series, has been merged before

[PATCH] Correct printk %pF to work on all architectures

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/kernel/module_64.c |9 + include/linux

Re: [PATCH] Correct printk %pF to work on all architectures

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't want some stupid useless weak function that is empty

Re: [PATCH] Correct printk %pF to work on all architectures

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 this has

Re: [PATCH] Correct printk %pF to work on all architectures

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 linux/module.h with total and utter crap. Please tell my WHY

RE: [PATCH] Correct printk %pF to work on all architectures

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 introduced by commit

[PATCH] fix compile failure with non modular builds

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 again

Re: [PATCH] fix compile failure with non modular builds

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 -0500 lib: Correct printk %pF to work

Re: Build regressions/improvements in v3.4-rc7

On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote: On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: + lib/mpi/generic_mpih-mul1.c: error: inconsistent operand constraints in an 'asm': = 50:70 + lib/mpi/generic_mpih-mul2.c: error: inconsistent

Re: [PATCH] scsi/ibmvscsi: /sys/class/scsi_host/hostX/config doesn't show any information

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 lx...@us.ibm.com James, can I assume you're picking up those two ? If they get acked by the maintiners ... James

Re: bit fields data tearing

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 to

Re: bit fields data tearing

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: +And there are anti-guarantees

Re: bit fields data tearing

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 James, On 09/04/2014 10:11 PM

Re: bit fields data tearing

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 21:06 -0700, Paul E. McKenney wrote

Re: bit fields data tearing

paul...@linux.vnet.ibm.com wrote: On Sun, Sep 07, 2014 at 12:04:47PM -0700, 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 21:06 -0700, Paul E. McKenney wrote

Re: bit fields data tearing

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 h...@zytor.com 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 on

Re: bit fields data tearing

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 very surprised if this problem didn't exist

Re: bit fields data tearing

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 fundamental requirement of the networking

Re: bit fields data tearing

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 whatever minor optimization was believed

Re: bit fields data tearing

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 combines adjacent writes _that are part of the program

Re: [PATCH V2 1/2] mm: Update generic gup implementation to handle hugepage directory

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 Weiner

Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic

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 going to

Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic

On Thu, 2011-05-19 at 13:08 +0900, Hitoshi Mitake wrote: On Thu, May 19, 2011 at 04:11, Moore, Eric eric.mo...@lsi.com 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

Re: linux-next: build failure in Linus' tree

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 s...@canb.auug.org.au wrote: After merging the fixes tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kernel/built-in.o:

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

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

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

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 pull the whole thing out

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

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: Perhaps now might

Re: [PATCH 00/34] Make kernel build deterministic

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 of behavior

Re: [PATCH] atomic: add *_dec_not_zero

, but for the Blackfin pieces: Acked-by: Mike Frysinger vap...@gentoo.org This goes for parisc as well. Acked-by: James Bottomley james.bottom...@hansenpartnership.com James ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https

Re: [PATCH 1/8] mm: use vm_unmapped_area() on parisc architecture

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 wal...@google.com Acked-by: Rik van Riel r...@redhat.com ---

Re: [PATCH RESEND 1/1] arch Kconfig: remove references to IRQ_PER_CPU

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 architecture

Re: ipr boot failure caused by MSI (2.6.30-rc1+)

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 into the initramfs system, this is what

Re: ipr boot failure caused by MSI (2.6.30-rc1+)

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 my powerstation. The ipr just times out and refuses to probe

Boot failure on the powerstation with 2.6.30 latest

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

Re: Boot failure on the powerstation with 2.6.30 latest

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

Re: [PATCH] mpt2sas: Fall back to 64 bit coherent mask if 64 bit DMA / 32 bit coherent mask not supported

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 mpt2sas on

Re: [PATCH 29/31] parisc: handle page-less SG entries

On Thu, 2015-08-13 at 20:30 -0700, Dan Williams wrote: On Thu, Aug 13, 2015 at 7:31 AM, Christoph Hellwig h...@lst.de 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

Re: RFC: prepare for struct scatterlist entries without page backing

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

Re: [PATCH v2 01/30] cxlflash: Fix to avoid invalid port_sel value

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 ___

Re: [PATCH v2 3/7] ibmvscsi: Replace magic values in set_adpater_info() with defines

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

Re: [PATCH v2 3/7] ibmvscsi: Replace magic values in set_adpater_info() with defines

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

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_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 > > >

Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations

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

Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations

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: > > > > > > > > > > > > > >

Re: [PATCH v2 00/29] y2038: add time64 syscalls

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 > >

Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM

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 > > >

Re: [PATCH 7/8] parisc: don't set ARCH_NO_COHERENT_DMA_MMAP

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

Re: [PATCH v2] ima: add a new CONFIG for loading arch-specific policies

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 > > &

Re: [PATCH v2] ima: add a new CONFIG for loading arch-specific policies

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

Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

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()

Re: [PATCH 0/8] scsi: convert tasklets to use new tasklet_setup()

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

Re: [PATCH 0/8] scsi: convert tasklets to use new tasklet_setup()

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 n

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

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?" > >

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

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

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

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

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

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

Re: [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area

[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

Re: [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area

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 &g

Re: [RFC PATCH v2 2/3] fs: define a firmware security filesystem named fwsecurityfs

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 @@ > > +//

Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs

are 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/lin

Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs

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: > > > > &

Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs

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: [...] > >