Re: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary

On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle wrote: >On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote: >> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O >> Port access. In a future patch HAS_IOPORT=n will disable compilation of >> the I/O accessor functions

Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi

On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote: >On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote: >> On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote: >>> Hi Heiko, >>> >>> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote: >>> > On Tue, Feb 14,

Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand"

On July 6, 2022 5:23:31 AM PDT, Borislav Petkov wrote: >On Tue, Jul 05, 2022 at 04:11:45PM -0700, H. Peter Anvin wrote: >> What I'm wondering is if we shouldn't be simply instrument *every* >> invocation, and set the trust to zero if we ever trip it. > >I guess y

Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand"

On July 5, 2022 3:00:04 PM PDT, Borislav Petkov wrote: >On Tue, Jul 05, 2022 at 02:50:34PM -0700, H. Peter Anvin wrote: >> It's just math. The only variable is your confidence level, i.e. at >> what level do you decide that the likelihood of pure chance is way >> smalle

Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand"

On July 5, 2022 12:57:04 PM PDT, Borislav Petkov wrote: >On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote: >> Oh, huh. Maybe in that case I should adjust the message to say "consider >> using `random.trust_cpu=0`," which is the thing that would actually make >> a security

Re: [PATCH v3 02/22] compat: provide compat_ptr() on all architectures

,oprofile-l...@lists.sf.net,linux-s390 ,sparclinux From: h...@zytor.com Message-ID: <41625f06-d755-4c82-86df-a9415feee...@zytor.com> On January 7, 2020 12:08:31 AM PST, Arnd Bergmann wrote: >On Tue, Jan 7, 2020 at 3:05 AM Michael Ellerman >wrote: >> Arnd Bergmann writes: >> > + >> > +static

Re: [PATCH v3 02/22] compat: provide compat_ptr() on all architectures

t.h| 18 ++ > 9 files changed, 20 insertions(+), 109 deletions(-) > For x86: Reviewed-by: H. Peter Anvin It still suffers from the zero-one-infinity rule failure of the compat architecture as a whole, but that is a very different problem. In this case "

Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

On 4/16/19 2:59 AM, Florian Weimer wrote: > * hpa: > >> Using symbol versioning doesn't really help much since the real >> problem is that struct termios can be passed around in userspace, and >> the interfaces between user space libraries don't have any >> versioning. However, my POC code deals

Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

On 4/15/19 10:22 AM, Adhemerval Zanella wrote: >> >> New interfaces are only necessary for the handful of architectures that >> don't have the speed fields *and* to space to put them in. > > Based on your WIP, it seems that both sparc and mips could be adapted. > Do we still have glibc

Re: [PATCH] treewide: remove current_text_addr

On 08/27/18 06:11, Peter Zijlstra wrote: > On Mon, Aug 27, 2018 at 05:26:53AM -0700, H. Peter Anvin wrote: > >> _THIS_IP_, however, is completely ill-defined, other than being an >> address *somewhere* in the same global function (not even necessarily >> the same

Re: [PATCH] treewide: remove current_text_addr

On 08/27/18 00:33, Peter Zijlstra wrote: > > What problem are we trying to solve? _THIS_IP_ and _RET_IP_ work fine. > We're 'good' at dealing with text addresses, we use them for call stacks > and all sorts. Why does this need changing? > _RET_IP_ works fine, with the following two caveats: 1.

Re: [PATCH] treewide: remove current_text_addr

On 08/26/18 12:30, H. Peter Anvin wrote: > Here is a full-blown (user space) test program demonstrating the whole > technique and how to use it. > > -hpa Incidentally, it looks like _RET_IP_ really should be defined as: /* * Is there any reason whatsoever to have _RET_IP_

Re: [PATCH] treewide: remove current_text_addr

Here is a full-blown (user space) test program demonstrating the whole technique and how to use it. -hpa #include #include #define _RET_IP_ ((unsigned long)__builtin_return_address(0)) #define noinline __attribute__((noinline)) #define used __attribute__((used)) /* __always_inline is

Re: [PATCH] treewide: remove current_text_addr

On 08/25/18 20:16, H. Peter Anvin wrote: > On 08/25/18 19:38, H. Peter Anvin wrote: >> >> If it was worthwhile it would make more sense to at least force this >> into the rodata section with the string, something like the attached >> file for an example; however, I hav

Re: [PATCH] treewide: remove current_text_addr

On 08/25/18 03:48, Helge Deller wrote: > > Currently alpha, s390, sparc, sh, c6x, ia64 and parisc provide an > inline assembly function to get the current instruction pointer. > As mentioned in an earlier thread, I personally would *prefer* if > _THIS_IP_ would use those inline assembly

Re: [PATCH] treewide: remove current_text_addr

On 08/25/18 19:38, H. Peter Anvin wrote: > > If it was worthwhile it would make more sense to at least force this > into the rodata section with the string, something like the attached > file for an example; however, I have a hunch it doesn't matter. > An even nuttier versi

Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

,Eric Biederman ,Tejun Heo ,Paolo Bonzini ,Andrew Morton ,"Kirill A . Shutemov" ,Lu Baolu From: h...@zytor.com

Re: [PATCH 1/3] futex: remove duplicated code

,Thomas Gleixner ,Ingo Molnar ,Chris Zankel ,Max Filippov ,Arnd Bergmann

Re: [PATCH 1/3] futex: remove duplicated code

vger.kernel.org,sparcli...@vger.kernel.org,linux-xte...@linux-xtensa.org,linux-a...@vger.kernel.org From: h...@zytor.com Message-ID: <cf18535e-39e7-44d3-88d0-80b9961e6...@zytor.com> On March 4, 2017 1:38:05 PM PST, Stafford Horne <sho...@gmail.com> wrote: >On Sat, Mar 04, 2017 at 11:

Re: [PATCH 1/3] futex: remove duplicated code

vger.kernel.org,sparcli...@vger.kernel.org,linux-xte...@linux-xtensa.org,linux-a...@vger.kernel.org From: h...@zytor.com Message-ID: <9b46afa6-c422-41fd-8e8a-356e44a6d...@zytor.com> On March 4, 2017 1:38:05 PM PST, Stafford Horne <sho...@gmail.com> wrote: >On Sat, Mar 04, 2017 at 11:

Re: [PATCH 1/3] futex: remove duplicated code

On 03/04/17 05:05, Russell King - ARM Linux wrote: >> >> +static int futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr) >> +{ >> +int op = (encoded_op >> 28) & 7; >> +int cmp = (encoded_op >> 24) & 15; >> +int oparg = (encoded_op << 8) >> 20; >> +int cmparg = (encoded_op

Re: [PATCH 00/14] Present useful limits to user (v2)

,Johannes Weiner ,Alexei Starovoitov ,Arnaldo Carvalho de Melo ,Alexander Shishkin ,Balbir Singh ,Markus Elfring ,"David S.

Re: [PATCH 0/8] Use correctly the Xen memory terminologies in Linux

On 07/28/2015 08:02 AM, Julien Grall wrote: Hi all, This patch series aims to use the memory terminologies described in include/linux/mm.h [1] for Linux xen code. Linux is using mistakenly MFN when GFN is meant, I suspect this is because the first support of Xen was for PV. This has

Re: [PATCH 1/5] kexec: Fix make headers_check

On 08/30/2014 05:47 AM, Paul Bolle wrote: Obviously, this can only break compiling those libraries, or other users. It can't break already compiled binaries. Besides I don't think those libraries, etc actually exist. Maximilian mentioned klibc in January, but I wasn't able to find a version

Re: bit fields data tearing

On 09/08/2014 10:52 AM, One Thousand Gnomes wrote: I think the whole removing Alpha EV5 support is basically bonkers. Just use set_bit in the tty layer. Alpha will continue to work as well as it always has done and you won't design out support for any future processor that turns out not to

Re: bit fields data tearing

On 09/08/2014 10:52 AM, 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 Alpha/NT. Right

Re: bit fields data tearing

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 on all alignment requiring architectures, like PPC and Sparc

Re: bit fields data tearing

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 atomic RMW except the ldcw operation) it can do atomic writes to fundamental sizes (byte, short, int, long)

Re: bit fields data tearing

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 atomic RMW except the ldcw operation) it can do atomic writes to fundamental sizes (byte, short, int, long)

Re: bit fields data tearing

On 09/08/2014 03:43 PM, James Bottomley wrote: This was years ago (possibly decades). We had to implement in-kernel unaligned traps for the networking layer because it could access short and int fields that weren't of the correct alignment when processing packets. It that's all corrected

Re: bit fields data tearing

On 09/08/2014 07:56 PM, James Bottomley wrote: Yeah, the extra requirement I added is basically nonsense, since the only issue is what instructions the compiler is emitting. So if compiler thinks the alignment is natural and combines the writes -- ok. If the compiler thinks the alignment is

Re: bit fields data tearing

Add a short member for proper alignment and one will probably pop out. Sent from my tablet, pardon any formatting problems. On Sep 8, 2014, at 19:56, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote: On 09/08/2014 01:50 AM,

Re: bit fields data tearing

I'm confused why storing 0x0102 would be a problem. I think gcc does that even on other cpus. More atomicity can't hurt, can it? On September 7, 2014 4:00:19 PM PDT, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote: On Sun,

Re: bit fields data tearing

How many PARISC systems do we have that actually do real work on Linux? On September 7, 2014 4:36:55 PM PDT, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Sun, Sep 07, 2014 at 04:17:30PM -0700, H. Peter Anvin wrote: I'm confused why storing 0x0102 would be a problem. I think gcc does

Re: bit fields data tearing

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 Alpha/NT. Right, because the x86 architecture was obsolete and would never scale... -hpa

Re: bit fields data tearing

On 09/05/2014 01:12 PM, Peter Zijlstra wrote: ... and I'm wondering if I should _remove_ pre-EV56 configurations or move the default choice and produce a warning about unsupported Alpha CPUs instead? depends BROKEN or is that deprecated? Just rip it out, like I did for the i386.

Re: bit fields data tearing

On 09/05/2014 01:14 PM, Peter Hurley wrote: Here's how I read the two statements. First, the commit message: It [this commit] documents that CPUs [supported by the Linux kernel] _must provide_ atomic one-byte and two-byte naturally aligned loads and stores. Second, in the body of

Re: bit fields data tearing

On 09/04/2014 02:52 AM, Benjamin Herrenschmidt wrote: Yeah correct, alpha and bytes right ? Is there any other ? That's why I suggested int. Even for Alpha it is only the 21064 AFAIK. -hpa ___ Linuxppc-dev mailing list

Re: bit fields data tearing

On 09/04/2014 12:42 PM, Peter Hurley wrote: Or we could give up on the Alpha. If Alpha is turning into Voyager (kept alive only as a museum piece, but actively causing problems) then please let's kill it. -hpa ___ Linuxppc-dev mailing

Re: bit fields data tearing

On 09/04/2014 05:59 PM, Peter Hurley wrote: I have no idea how prevalent the ev56 is compared to the ev5. Still we're talking about a chip that came out in 1996. Ah yes, I stand corrected. According to Wikipedia, the affected CPUs were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164

Re: bit fields data tearing

On 09/04/2014 05:59 PM, Peter Hurley wrote: I have no idea how prevalent the ev56 is compared to the ev5. Still we're talking about a chip that came out in 1996. Ah yes, I stand corrected. According to Wikipedia, the affected CPUs were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164

Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

for a patch that mostly deletes code. Akpm, can you take this? I'm fine with it as-is. Acked-by: H. Peter Anvin h...@linux.intel.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 10/10] Kconfig: cleanup SERIO_I8042 dependencies

: linuxppc-dev@lists.ozlabs.org CC: Paul Mundt let...@linux-sh.org CC: linux...@vger.kernel.org CC: David S. Miller da...@davemloft.net CC: sparcli...@vger.kernel.org CC: Guan Xuetao g...@mprc.pku.edu.cn CC: Ingo Molnar mi...@redhat.com CC: Thomas Gleixner t...@linutronix.de CC: H. Peter Anvin h

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

On 10/10/2013 03:17 AM, Alexander Gordeev wrote: On Wed, Oct 09, 2013 at 03:24:08PM +1100, Benjamin Herrenschmidt wrote: Ok, this suggestion sounded in one or another form by several people. What about name it pcim_enable_msix_range() and wrap in couple more helpers to complete an API:

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

On 10/02/2013 03:29 AM, Alexander Gordeev wrote: As result, device drivers will cease to use the overcomplicated repeated fallbacks technique and resort to a straightforward pattern - determine the number of MSI/MSI-X interrupts required before calling pci_enable_msi_block() and

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

On 05/28/2013 01:19 AM, Ingo Molnar wrote: So I think the same principle applies to it as to any other debugging code: it's fine to be able to turn debugging off. It's a performance versus kernel robustness/determinism trade-off. I suspect, rather, that BUG() should turn into a trap (or

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

On 05/28/2013 08:43 AM, Arnd Bergmann wrote: Right, that is what the patch I just posted does. On a related note, I found that WARN_ON() can no longer be compiled out since there is already code that relies on the side-effects of the condition. I assume that was an intentional change I

Re: [PATCH 2/3] x86/mm/numa: use setup_nr_node_ids() instead of opencoding.

On 03/26/2013 10:56 AM, Yinghai Lu wrote: For 1 and 2, Acked-by: Yinghai Lu ying...@kernel.org Similarly: Acked-by: H. Peter Anvin h...@linux.intel.com -hpa ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https

Re: [PATCH v2 4/6] x86: Add clear_page_nocache

patchset base is stale. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: build warnings after merge of the final tree

ones among the flood. hpa, Was this change only needed for x86? If so, could you put that into asm/ftrace.h instead? Yes (on both accounts). It was part of the syscall changes; I'll move the include. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work

Re: [PATCHv5] atomic: add *_dec_not_zero

On 12/04/2011 02:41 PM, Benjamin Herrenschmidt wrote: I agree with Russell, his approach is a lot easier to maintain long run, we should even consider converting existing definitions. Thirded. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't

Re: [RFC] virtio: expose for non-virtualization users too

On 07/05/2011 07:06 AM, Ohad Ben-Cohen wrote: virtio has been so far used only in the context of virtualization, and the virtio Kconfig was sourced directly by the relevant arch Kconfigs when VIRTUALIZATION was selected. Now that we start using virtio for inter-processor communications, we

Re: [RFC,PATCH] Cleanup PC parallel port Kconfig

makes total sense. No it doesn't. It depends on the ISA DMA API, not that the machine has ISA DMA. I have a platform which has no ISA DMA but uses the floppy driver. Please don't break it. OK, even more case in point, then. -hpa -- H. Peter Anvin, Intel Open Source Technology

Re: [RFC,PATCH] Cleanup PC parallel port Kconfig

On 06/15/2011 12:39 AM, Russell King - ARM Linux wrote: On Tue, Jun 14, 2011 at 09:31:27PM -0700, H. Peter Anvin wrote: On 06/14/2011 03:08 PM, Luck, Tony wrote: I took a look at the back of all my ia64 systems - none of them have a parallel port. It seems unlikely that new systems

Re: [RFC,PATCH] Cleanup PC parallel port Kconfig

On 06/14/2011 12:08 PM, Ralf Baechle wrote: The PC parallel port Kconfig as acquired one of those messy terms to describe it's architecture dependencies: depends on (!SPARC64 || PCI) !SPARC32 !M32R !FRV \ (!M68K || ISA) !MN10300 !AVR32 !BLACKFIN This isn't

Re: [RFC,PATCH] Cleanup PC parallel port Kconfig

SoCs are offered on x86 platforms? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo

Re: [RFC,PATCH] Cleanup PC parallel port Kconfig

get MMIO based drivers for PCI-less platforms. Now, isn't that was iowrite/ioread was designed for? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ Linuxppc-dev mailing list

Re: [RFC,PATCH] Cleanup PC parallel port Kconfig

:-) So even if I had a printer (or other device) that used a parallel port, I have no way to test it. If it has PCI slots, it can have a parallel port. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf

Re: [RFC,PATCH] Cleanup PC parallel port Kconfig

On 06/14/2011 09:40 PM, Guenter Roeck wrote: On Wed, Jun 15, 2011 at 12:18:36AM -0400, H. Peter Anvin wrote: On 06/14/2011 03:34 PM, Ralf Baechle wrote: There is no point in offering to build something that couldn't possibly be used. It just makes the kernel harder to configure and inflates

Re: [PATCH] Audit: push audit success and retcode into arch ptrace.h

which one is correct, but this patch now uses regs[3]. Signed-off-by: Eric Paris epa...@redhat.com For the x86 portions: Acked-by: H. Peter Anvin h...@zytor.com -hpa ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https

Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct II

Sorry... I confused them too. It's TS_COMPAT which is problematic. -- Sent from my mobile phone. Please pardon any lack of formatting. Stephen Wilson wils...@start.ca wrote: On Thu, Mar 10, 2011 at 08:38:09AM -0800, Andi Kleen wrote: On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote:

Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct

TIF_IA32 is set during the execution of a 32-bit system call - so touched on each compat system call. Is this the actual flag you want? A 32-bit address space flag is different from TIF_IA32. -- Sent from my mobile phone. Please pardon any lack of formatting. Stephen Wilson wils...@start.ca

Re: [RFC] [PATCH] allow low HZ values?

On 10/11/2010 03:33 PM, Thomas Gleixner wrote: On Tue, 12 Oct 2010, Benjamin Herrenschmidt wrote: On Mon, 2010-10-11 at 13:11 -0700, Tim Pepper wrote: I'm not necessarily wanting to open up the age old question of what is a good HZ, but we were doing some testing on timer tick overheads for

Re: [PATCH 31/40] trace syscalls: Convert various generic compat syscalls

On 06/23/2010 04:38 AM, Frederic Weisbecker wrote: I haven't heard any complains about existing syscalls wrappers. Then you truly haven't been listening. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf

Re: [PATCH 12/40] x86, compat: convert ia32 layer to use

. It should *not* be visible to userspace that there is an arch-specici implementation. There are already a huge amount of gratuitous user space ABI differences, of course, partly because we *still* don't actually have a systematic model for argument passing. -hpa -- H. Peter Anvin

Re: [PATCH v21 011/100] eclone (11/11): Document sys_eclone

On 06/09/2010 11:14 AM, Sukadev Bhattiprolu wrote: | | Even for x86, it's an easier API. Callers would be specifying | two numbers they already have: the argument and return value | for malloc. Currently the numbers must be added together, | destroying information, except on hppa (must not

Re: Badness on the Warp

code conflicts logically, even if it isn't visible as a conflict in git. Furthermore, of course, you can have misresolved actual conflicts. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf

Re: [PATCH v2 1/6] Add new macros for page-aligned data and bss sections.

macroizing this kind of stuff. This is part of why macroizing it is good: it means we end up with *one* place that determines this stuff, not some magic heuristics in the linker. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf

Re: [PATCH v2 1/6] Add new macros for page-aligned data and bss sections.

Sam Ravnborg wrote: On Fri, May 01, 2009 at 09:33:13AM -0700, H. Peter Anvin wrote: Tim Abbott wrote: On Fri, 1 May 2009, Sam Ravnborg wrote: On Thu, Apr 30, 2009 at 03:54:08PM -0400, Tim Abbott wrote: +#define __PAGE_ALIGNED_DATA .section .data.page_aligned, aw, @progbits +#define

Re: [PATCH v2 1/6] Add new macros for page-aligned data and bss sections.

... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/3] powerpc/86xx: Add MMC SPI support for MPC8610HPCD boards

at that point. Does that disagree with your observations? If so, I'd be really interested to find out what you have seen in more detail, as it adds to the understanding of MMC/SD cards in the field. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak

Re: [PATCH 59/60] microblaze_v4: syscall_table.S and unistd.h

Arnd Bergmann wrote: You still set __NR_fork. There is no point defining the number if you can't actually call the syscall in the first place. Worse, it is actively *harmful* to set the number; klibc or anything that uses similar kinds of scripts for portability will see the symbol and

Re: Microblaze init port v4

Arnd Bergmann wrote: * You are using sys_ipc and sys_socketcall instead of the broken-out syscalls, which is a direct consequence of following the i386 numbering scheme. Please pretty please kill, kill, kill... -hpa ___ Linuxppc-dev

Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

Arnd Bergmann wrote: On Thursday 26 June 2008, Adrian Bunk wrote: The comment could be nuked (as well as the #ifdef __KERNEL__), but for the one #define an asm-generic header would IMHO be overkill. I agree that it doesn't technically make sense to have a one-line asm-generic header, but I

Re: [PATCH 30/60] microblaze_v4: support for a.out

Michal Simek wrote: I expect it but I haven't information about. I'll check it. I'm assuming Microblaze doesn't actually add a.out support, does it? -hpa ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org

Re: [PATCH 30/60] microblaze_v4: support for a.out

Michal Simek wrote: Michal Simek wrote: I expect it but I haven't information about. I'll check it. I'm assuming Microblaze doesn't actually add a.out support, does it? I think that any support were there but I assume that no one use it. Most other new architectures don't bother, hence the

Re: How to link a .o with all modules

Kumar Gala wrote: Sam, We have a case in powerpc in which we want to link some library routines with all module objects. The routines are intended for handling out-of-line function call register save/restore so having them as EXPORT_SYMBOL() is counter productive (we do also need to link

Re: Too verbose compat_ioctl messages?

Andi Kleen wrote: H. Peter Anvin [EMAIL PROTECTED] writes: For one thing, it looks like we're returning the wrong thing (EINVAL rather than ENOTTY) across the board. This was unfortunately a common misunderstanding with non-tty-related ioctls in the early days of Linux. ENOTTY is so