* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Lennox Wu @ 2011-06-15 8:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
linux-arch, Jesper Nilsson, Russell King, Yoshinori Sato,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Matt Turner, Fenghua Yu, microblaze-uclinux,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-cris-kernel, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <201106142222.43553.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
2011/6/15 Arnd Bergmann <arnd@arndb.de>
>
> > config SCORE
> > - def_bool y
> > - select HAVE_GENERIC_HARDIRQS
> > - select GENERIC_IRQ_SHOW
> > + def_bool y
> > + select HAVE_GENERIC_HARDIRQS
> > + select HAVE_PC_PARPORT
> > + select GENERIC_IRQ_SHOW
> >
> > choice
> > prompt "System type"
>
> Certainly not, no PIO support
>
> Yes, there is no platform of the Score supports PIO.
Best,
Lennox
[-- Attachment #2: Type: text/html, Size: 818 bytes --]
^ permalink raw reply
* [PATCH][v2] Add support for RTC device: pt7c4338 in rtc-ds1307.c
From: Priyanka Jain @ 2011-06-15 8:59 UTC (permalink / raw)
To: akpm, w.sang, cbouatmailru, a.zummo, benh, galak, grant.likely,
b04825, linuxppc-dev, rtc-linux, p_gortmaker, linuxppc-release
Cc: Priyanka Jain
PT7C4338 chip is being manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile RAM.
Its register set is same as that of rtc device: DS1307.
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
Change for v2:
Incorporting Andrew Morton's comments to shorten patch by using
hunk: { "pt7c4338", ds_1307 }
Changes :
This patch will supersede patch:
"RTC driver(Linux) for PT7C4338 chip"
Incorporting Wolfram Sang's comments to reuse ds1307 driver.
drivers/rtc/Kconfig | 6 +++---
drivers/rtc/rtc-ds1307.c | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index b8f4e9e..c6045dd 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -126,13 +126,13 @@ comment "I2C RTC drivers"
if I2C
config RTC_DRV_DS1307
- tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025"
+ tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025, PT7C4338"
help
If you say yes here you get support for various compatible RTC
chips (often with battery backup) connected with I2C. This driver
should handle DS1307, DS1337, DS1338, DS1339, DS1340, ST M41T00,
- EPSON RX-8025 and probably other chips. In some cases the RTC
- must already have been initialized (by manufacturing or a
+ EPSON RX-8025, PT7C4338 and probably other chips. In some cases
+ the RTC must already have been initialized (by manufacturing or a
bootloader).
The first seven registers on these chips hold an RTC, and other
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 4724ba3..e851394 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -4,6 +4,8 @@
* Copyright (C) 2005 James Chapman (ds1337 core)
* Copyright (C) 2006 David Brownell
* Copyright (C) 2009 Matthias Fuchs (rx8025 support)
+ * Copyright (C) 2011 Priyanka Jain (Priyanka.Jain@freescale.com)
+ * (pt7c4338 support)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -149,6 +151,7 @@ static const struct i2c_device_id ds1307_id[] = {
{ "ds1340", ds_1340 },
{ "ds3231", ds_3231 },
{ "m41t00", m41t00 },
+ { "pt7c4338", ds_1307 },
{ "rx8025", rx_8025 },
{ }
};
--
1.6.5.6
^ permalink raw reply related
* Re: [PATCH 06/15] 8xx: Always pin kernel instruction TLB
From: Joakim Tjernlund @ 2011-06-15 9:21 UTC (permalink / raw)
To: Dan Malek; +Cc: Scott Wood, linuxppc-dev, Willy Tarreau
In-Reply-To: <792A171E-D1E1-4F35-8AC2-40C5A7519D78@digitaldans.com>
Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/06/14 20:11:18:
>
> Hi Joakim.
>
> On Jun 14, 2011, at 11:00 AM, Joakim Tjernlund wrote:
>
> > I don't have a mpc850, do you?
>
> I have to say I do :-)
>
> > Probably but that is another matter. You could continue with that
> > if you like but I am stopping here ATM.
>
> Oh, come on... I've been thinking about this for years, wouldn't
> you like to work on it? It will be fun :-)
OK, it was fun :) This is a quick impl. for kernel ITLBs. What do
you think?
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index 0f9080c..88278b4 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -33,6 +33,7 @@
#include <asm/ppc_asm.h>
#include "ppc_defs.h"
+#undef CONFIG_PIN_TLB
/* Macro to make the code more readable. */
#ifdef CONFIG_8xx_CPU6
#define DO_8xx_CPU6(val, reg) \
@@ -357,17 +358,23 @@ InstructionTLBMiss:
/* If we are faulting a kernel address, we have to use the
* kernel page tables.
*/
-#ifdef CONFIG_MODULES
- /* Since we PIN the first 8MB text, we only get ITLB misses
- * for modules
- */
andi. r21, r20, 0x0800 /* Address >= 0x80000000 */
beq 3f
+#ifdef CONFIG_MODULES
lis r21, swapper_pg_dir@h
ori r21, r21, swapper_pg_dir@l
rlwimi r20, r21, 0, 2, 19
-3:
+ lwz r21, 0(r20) /* Get the level 1 entry */
+ tophys(r21,r21)
+ ori r21, r21, MI_PS8MEG | MI_SVALID /* Set 8M byte page */
+#else
+ li r21, MI_PS8MEG | MI_SVALID /* Set 8M byte page */
#endif
+ DO_8xx_CPU6(0x2b80, r3)
+ mtspr MI_TWC, r21 /* Set segment attributes */
+ li r20, MI_BOOTINIT
+ b 5f
+3:
lwz r21, 0(r20) /* Get the level 1 entry */
rlwinm. r20, r21,0,0,19 /* Extract page descriptor page address */
@@ -401,7 +408,7 @@ InstructionTLBMiss:
*/
2: li r21, 0x00f0
rlwimi r20, r21, 0, 0x07f8 /* Set 24-27, clear 21-23,28 */
- DO_8xx_CPU6(0x2d80, r3)
+5: DO_8xx_CPU6(0x2d80, r3)
mtspr MI_RPN, r20 /* Update TLB entry */
mfspr r20, M_TW /* Restore registers */
@@ -942,13 +949,16 @@ start_here:
*/
initial_mmu:
tlbia /* Invalidate all TLB entries */
-
+#ifdef CONFIG_PIN_TLB
+//#if 1
/* Always pin the first 8 MB ITLB to prevent ITLB
misses while mucking around with SRR0/SRR1 in asm
*/
lis r8, MI_RSV4I@h
ori r8, r8, 0x1c00
-
+#else
+ li r8, 0
+#endif
mtspr MI_CTR, r8 /* Set instruction MMU control */
#ifdef CONFIG_PIN_TLB
^ permalink raw reply related
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Ralf Baechle @ 2011-06-15 8:34 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Kyle McMartin, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <4DF8329C.7000904@zytor.com>
On Tue, Jun 14, 2011 at 09:18:36PM -0700, 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 the test
> > matrix for no good reason.
> >
>
> I see... that's why a bunch of devices that only exist on ARM and MIPS
> SoCs are offered on x86 platforms?
Well, if you notice one of those, yell. Or send patches. Most of those
have been fixed.
Ralf
^ permalink raw reply
* RE: Relocatable kernel for ppc44x
From: David Laight @ 2011-06-15 9:30 UTC (permalink / raw)
To: Suzuki Poulose, monstr; +Cc: linuxppc-dev, John Williams
In-Reply-To: <4DF84D92.2030803@in.ibm.com>
=20
> The PPC440X currently uses 256M TLB entries to pin the=20
> lowmem. When we go for a relocatable kernel we have to :
>=20
> 1) Restrict the kernel load address to be 256M aligned
>=20
> OR
>=20
> 2) Use 16M TLB(the next possible TLB page size supported)=20
> entries till the first
> 256M and then use the 256M TLB entries for the rest of lowmem.
What is wrong with:
3) Use 256M TLB entries with the lowest one including
addresses below the kernel base.
Clearly the kernel shouldn't be accessing the addresses
below its base address - but that is true of a lot of
address space mapped into the kernel.
David
^ permalink raw reply
* Re: Relocatable kernel for ppc44x
From: John Williams @ 2011-06-15 9:38 UTC (permalink / raw)
To: David Laight; +Cc: linuxppc-dev, monstr, Suzuki Poulose
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AD9E@saturn3.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]
On Wed, Jun 15, 2011 at 11:30 AM, David Laight <David.Laight@aculab.com>wrote:
>
> > The PPC440X currently uses 256M TLB entries to pin the
> > lowmem. When we go for a relocatable kernel we have to :
> >
> > 1) Restrict the kernel load address to be 256M aligned
> >
> > OR
> >
> > 2) Use 16M TLB(the next possible TLB page size supported)
> > entries till the first
> > 256M and then use the 256M TLB entries for the rest of lowmem.
>
> What is wrong with:
>
> 3) Use 256M TLB entries with the lowest one including
> addresses below the kernel base.
>
> Clearly the kernel shouldn't be accessing the addresses
> below its base address - but that is true of a lot of
> address space mapped into the kernel.
>
It gets mucky since we will then need need to assess how much of that 256M
mapping will be above the kernel base, determine if that is sufficient to
boot the kernel, if not then setup additional 16MB mappings and so on. It
might be cleaner to just use multiple 16MB mappings directly?
By the way we have some patches to support a non-zero (but fixed) boot
address for PPC440. They are against 2.6.31, it's pretty simple stuff
except also requires changes in the simpleboot wrapper. We will post them
shortly since they are relevant to this discussion.
John
--
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
[-- Attachment #2: Type: text/html, Size: 1945 bytes --]
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Arnd Bergmann @ 2011-06-15 9:46 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-cris-kernel, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <4DF83577.6040903@zytor.com>
On Wednesday 15 June 2011, H. Peter Anvin wrote:
> On 06/14/2011 02:33 PM, Arnd Bergmann wrote:
> >>
> >> Why on earth restrict it like that? It's just a device driver, like
> >> more or less any other device driver...
> >
> > I'd say any other classic ISA/PC driver, including floppy, gameport or
> > serial-8250. One problem with these is that we never fully worked out
> > the dependencies for these, which we probably should. CONFIG_ISA
> > generally means ISA add-on cards, but that might not be enabled for
> > platforms that have a pc-parport but no ISA slots.
> >
>
> OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs
> are ubiquitous across just about every platform.
Obviously you want to support 8250 uarts with MMIO on most architectures,
but the driver can only be built if you define both MMIO and PIO
accessors (readb and outb). I would like to make the PIO part of 8250
conditional on having PIO support so that an architecture that doesn't
support this no longer has to provide fake accessor functions.
> Parallel port is an intermediate case... Centronics parallel ports
> predate the PC ecosystem by quite a bit, and the particular arrangement
> of ports became popular with the PC and spread to other platforms, but
> the particular variant of it known as ECP (as opposed to EPP) is ISA DMA
> specific.
The driver looks like it can easily be built without support for the ISA DMA
API.
> > On the other hand, you have embedded platforms that currently build support
> > for parport-pc but define the inb/outb macros to plain pointer dereferences
> > (otherwise you can't build the 8250 driver). Loading parport-pc on those
> > machines typically results in derefencing user memory in the best case.
> >
> > What I'd love to see is a configuration option for "arch has working
> > PC-style inb/outb instructions", so we can build a kernel without them but
> > still get MMIO based drivers for PCI-less platforms.
>
> Now, isn't that was iowrite/ioread was designed for?
Yes, it just isn't used consistently. As far as I can tell, this is for multiple
number of reasons:
* In case of 8250, the driver abstracts the difference between PIO and MMIO itself,
because it uses the same method to do indirect accesses and different strides.
Using ioread wouldn't really make the driver much simpler.
* For parport-pc, the driver really only needs PIO, we don't even
try to support the same device on random MMIO addresses, and that might not
be necessary.
* In case of floppies, the "solution" was to write a driver for every platform that
doesn't have PIO, since they tend to have other differences. The amiflop and
ataflop drivers are not even use readb(), they just derefence volatile pointers
to do MMIO. I doubt we can find volunteers to clean that up.
Arnd
^ permalink raw reply
* Re: Relocatable kernel for ppc44x
From: Benjamin Herrenschmidt @ 2011-06-15 10:11 UTC (permalink / raw)
To: Suzuki Poulose; +Cc: linuxppc-dev, monstr, John Williams
In-Reply-To: <4DF84D92.2030803@in.ibm.com>
On Wed, 2011-06-15 at 11:43 +0530, Suzuki Poulose wrote:
> On 06/14/11 17:34, Michal Simek wrote:
> > Hi,
> >
> > have someone tried to support RELOCATABLE kernel on ppc44x?
> As Josh, mentioned, I will be working on this. In fact I was trying a couple of
> patches towards this on PPC440x. But, I am stuck in debugging the hang that I am
> experiencing with the changes. I am setting up a RISCWatch processor probe to
> debug the same.
>
> Here is some information that I wanted to share :
>
> The PPC440X currently uses 256M TLB entries to pin the lowmem. When we go for a
> relocatable kernel we have to :
>
> 1) Restrict the kernel load address to be 256M aligned
Wait a minute ... :-)
There's a difference between having the kernel run from any address and
mapping the linear mapping not starting at 0.
Those are completely orthogonal.
I don't see why off hand you are changing the way the TLB is used. The
only possible change needed is to make sure the initial bolted entry set
by the asm code properly covers the kernel in whatever it's "current"
location is. The rest is a matter of fixing up the relocations...
Cheers,
Ben.
> OR
>
> 2) Use 16M TLB(the next possible TLB page size supported) entries till the first
> 256M and then use the 256M TLB entries for the rest of lowmem.
>
> Option 1 is not feasible.
>
> Towards this, I have tried a patch which uses 16M TLB entries to map the entire
> lowmem on an ebony board. But that doesn't seem to work. I am setting up the JTAG
> to debug the state.
>
> I have attached the patch below for your reference. Any suggestions/comments would
> be really helpful.
>
>
> Thanks
> Suzuki
>
> ==============================
>
>
> Use 16M TLB pages to pin the lowmem on PPC440x.
>
> ---
> arch/powerpc/include/asm/mmu-44x.h | 9 +++++++++
> arch/powerpc/kernel/head_44x.S | 2 +-
> arch/powerpc/mm/44x_mmu.c | 2 +-
> 3 files changed, 11 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.38.1/arch/powerpc/include/asm/mmu-44x.h
> ===================================================================
> --- linux-2.6.38.1.orig/arch/powerpc/include/asm/mmu-44x.h
> +++ linux-2.6.38.1/arch/powerpc/include/asm/mmu-44x.h
> @@ -121,7 +121,12 @@ typedef struct {
> #endif
>
> /* Size of the TLBs used for pinning in lowmem */
> +#define PPC_PIN_SIZE (1 << 24) /* 16M */
> +#define PPC44x_TLB_PIN_SIZE PPC44x_TLB_16M
> +#if 0
> #define PPC_PIN_SIZE (1 << 28) /* 256M */
> +#define PPC44x_TLB_PIN_SIZE PPC44x_TLB_256M
> +#endif
>
> #if (PAGE_SHIFT == 12)
> #define PPC44x_TLBE_SIZE PPC44x_TLB_4K
> @@ -142,7 +147,11 @@ typedef struct {
> #error "Unsupported PAGE_SIZE"
> #endif
>
> +#if 0
> #define mmu_linear_psize MMU_PAGE_256M
> +#else
> +#define mmu_linear_psize MMU_PAGE_16M
> +#endif
>
> #define PPC44x_PGD_OFF_SHIFT (32 - PGDIR_SHIFT + PGD_T_LOG2)
> #define PPC44x_PGD_OFF_MASK_BIT (PGDIR_SHIFT - PGD_T_LOG2)
> Index: linux-2.6.38.1/arch/powerpc/kernel/head_44x.S
> ===================================================================
> --- linux-2.6.38.1.orig/arch/powerpc/kernel/head_44x.S
> +++ linux-2.6.38.1/arch/powerpc/kernel/head_44x.S
> @@ -805,7 +805,7 @@ skpinv: addi r4,r4,1 /* Increment */
>
> /* pageid fields */
> clrrwi r3,r3,10 /* Mask off the effective page number */
> - ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_256M
> + ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_PIN_SIZE
>
> /* xlat fields */
> clrrwi r4,r4,10 /* Mask off the real page number */
> Index: linux-2.6.38.1/arch/powerpc/mm/44x_mmu.c
> ===================================================================
> --- linux-2.6.38.1.orig/arch/powerpc/mm/44x_mmu.c
> +++ linux-2.6.38.1/arch/powerpc/mm/44x_mmu.c
> @@ -84,7 +84,7 @@ static void __init ppc44x_pin_tlb(unsign
> : "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
> #endif
> "r" (phys),
> - "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
> + "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_PIN_SIZE),
> "r" (entry),
> "i" (PPC44x_TLB_PAGEID),
> "i" (PPC44x_TLB_XLAT),
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: Relocatable kernel for ppc44x
From: Benjamin Herrenschmidt @ 2011-06-15 10:14 UTC (permalink / raw)
To: David Laight; +Cc: linuxppc-dev, monstr, Suzuki Poulose, John Williams
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AD9E@saturn3.aculab.com>
On Wed, 2011-06-15 at 10:30 +0100, David Laight wrote:
> > The PPC440X currently uses 256M TLB entries to pin the
> > lowmem. When we go for a relocatable kernel we have to :
> >
> > 1) Restrict the kernel load address to be 256M aligned
> >
> > OR
> >
> > 2) Use 16M TLB(the next possible TLB page size supported)
> > entries till the first
> > 256M and then use the 256M TLB entries for the rest of lowmem.
>
> What is wrong with:
>
> 3) Use 256M TLB entries with the lowest one including
> addresses below the kernel base.
>
> Clearly the kernel shouldn't be accessing the addresses
> below its base address - but that is true of a lot of
> address space mapped into the kernel.
In the case of a relocatable kernel it's perfectly kosher to access
addresses below the kernel itself... Typically this is used for kdump
where the kdump kernel excecutes in place in a reserved area but access
to the rest of memory is allowed to ... well, do the dump :-) There
could be other reasons to do that too.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Geert Uytterhoeven @ 2011-06-15 11:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
Lennox Wu, linux-arch, Jesper Nilsson, Russell King,
Yoshinori Sato, Helge Deller, x86, James E.J. Bottomley,
Ingo Molnar, Matt Turner, Fenghua Yu, microblaze-uclinux,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <201106151146.13320.arnd@arndb.de>
On Wed, Jun 15, 2011 at 11:46, Arnd Bergmann <arnd@arndb.de> wrote:
> * In case of floppies, the "solution" was to write a driver for every pla=
tform that
> =C2=A0doesn't have PIO, since they tend to have other differences. The am=
iflop and
> =C2=A0ataflop drivers are not even use readb(), they just derefence volat=
ile pointers
> =C2=A0to do MMIO. I doubt we can find volunteers to clean that up.
Amiflop drives the Amiga floppy controller, which is completely
different from the
PC-style floppy controller.
Ataflop drives the Atari floppy controller, which seems to be a WD1772 and =
not
related to PC-style floppy controllers neither.
So none of them drive PC-style hardware, and both predate the generic readb=
()
infrastructure.
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH][v2] Add support for RTC device: pt7c4338 in rtc-ds1307.c
From: Tabi Timur-B04825 @ 2011-06-15 11:44 UTC (permalink / raw)
To: Jain Priyanka-B32167
Cc: a.zummo@towertech.it, linuxppc-release@linux.freescale.net,
rtc-linux@googlegroups.com, p_gortmaker@yahoo.com,
galak@gate.crashing.org, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1308128390-23347-1-git-send-email-Priyanka.Jain@freescale.com>
Priyanka Jain wrote:
> + * Copyright (C) 2011 Priyanka Jain (Priyanka.Jain@freescale.com)
> + * (pt7c4338 support)
You can't claim copyright just by adding one line of text.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: Relocatable kernel for ppc44x
From: Suzuki Poulose @ 2011-06-15 14:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, monstr, John Williams
In-Reply-To: <1308132715.2516.1.camel@pasglop>
On 06/15/11 15:41, Benjamin Herrenschmidt wrote:
> On Wed, 2011-06-15 at 11:43 +0530, Suzuki Poulose wrote:
>> On 06/14/11 17:34, Michal Simek wrote:
>>> Hi,
>>>
>>> have someone tried to support RELOCATABLE kernel on ppc44x?
>> As Josh, mentioned, I will be working on this. In fact I was trying a couple of
>> patches towards this on PPC440x. But, I am stuck in debugging the hang that I am
>> experiencing with the changes. I am setting up a RISCWatch processor probe to
>> debug the same.
>>
>> Here is some information that I wanted to share :
>>
>> The PPC440X currently uses 256M TLB entries to pin the lowmem. When we go for a
>> relocatable kernel we have to :
>>
>> 1) Restrict the kernel load address to be 256M aligned
>
> Wait a minute ... :-)
>
> There's a difference between having the kernel run from any address and
> mapping the linear mapping not starting at 0.
>
> Those are completely orthogonal.
>
> I don't see why off hand you are changing the way the TLB is used.
I started off with PHYSICAL_START support and that kind of hogged me into
this approach :-).
The
> only possible change needed is to make sure the initial bolted entry set
> by the asm code properly covers the kernel in whatever it's "current"
> location is. The rest is a matter of fixing up the relocations...
Could we do something like,
If kernel is loaded at X,
1. map : ((X-1) & ~256M) to PAGE_OFFSET and so on to cover the kernel in 256M
chunks.
2. Then process the relocations with (X % 256M)
Thanks
Suzuki
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Guenter Roeck @ 2011-06-15 14:36 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux@vger.kernel.org,
Guan Xuetao, Lennox Wu, linux-arch@vger.kernel.org,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller,
x86@kernel.org, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Matt Turner, Fenghua Yu,
microblaze-uclinux@itee.uq.edu.au, Chris Metcalf, Mikael Starvik,
Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
Chris Zankel, Michal Simek, Tony Luck,
linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
linux-kernel@vger.kernel.org, Kyle McMartin, Paul Mundt,
linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
David S. Miller
In-Reply-To: <20110615083437.GA32624@linux-mips.org>
On Wed, Jun 15, 2011 at 04:34:37AM -0400, Ralf Baechle wrote:
> On Tue, Jun 14, 2011 at 09:18:36PM -0700, 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 the test
> > > matrix for no good reason.
> > >
> >
> > I see... that's why a bunch of devices that only exist on ARM and MIPS
> > SoCs are offered on x86 platforms?
>
> Well, if you notice one of those, yell. Or send patches. Most of those
> have been fixed.
>
I think he was being sarcastic, and wanted to say that it should be that way.
Guenter
^ permalink raw reply
* Re: [PATCH][v2] Add support for RTC device: pt7c4338 in rtc-ds1307.c
From: Timur Tabi @ 2011-06-15 15:05 UTC (permalink / raw)
To: Priyanka Jain; +Cc: a.zummo, rtc-linux, p_gortmaker, galak, akpm, linuxppc-dev
In-Reply-To: <1308128390-23347-1-git-send-email-Priyanka.Jain@freescale.com>
Priyanka Jain wrote:
> config RTC_DRV_DS1307
> - tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025"
> + tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025, PT7C4338"
> help
> If you say yes here you get support for various compatible RTC
> chips (often with battery backup) connected with I2C. This driver
> should handle DS1307, DS1337, DS1338, DS1339, DS1340, ST M41T00,
> - EPSON RX-8025 and probably other chips. In some cases the RTC
> - must already have been initialized (by manufacturing or a
> + EPSON RX-8025, PT7C4338 and probably other chips. In some cases
> + the RTC must already have been initialized (by manufacturing or a
> bootloader).
I think you should probably drop the Kconfig change, too. It already says, "and
probably other chips", and you're also just bloating the summary line. We can't
list every possible Dallas-compatible RTC chip here.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-15 15:08 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, Arnd Bergmann, microblaze-uclinux,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-cris-kernel, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <20110615074749.GB28989@n2100.arm.linux.org.uk>
On 06/15/2011 12:47 AM, Russell King - ARM Linux wrote:
>>
>> OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs
>> are ubiquitous across just about every platform.
>>
>> Floppy is special (in the short bus sense), since it is closely tied to
>> ISA DMA. Conditionalizing this on ISA DMA 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 Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-15 15:16 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Chen Liqin,
Paul Mackerras, sparclinux@vger.kernel.org, Guan Xuetao,
Lennox Wu, linux-arch@vger.kernel.org, Jesper Nilsson,
Yoshinori Sato, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Yu, Fenghua, microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
Chris Zankel, Michal Simek, Luck, Tony,
linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
linux-kernel@vger.kernel.org, Ralf Baechle, Kyle McMartin,
Paul Mundt, linux-alpha@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <20110615073935.GA28989@n2100.arm.linux.org.uk>
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 will
>>> start adding parallel ports :-)
>>>
>>> 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.
>
> Is that a clue about where a select statement should be?
Not really, because it's a sufficient condition, not a required one.
All a platform needs to expose a PC-style parallel port interface is a
minimum of 3 contiguous I/O locations, and although in the PC they are
I/O mapped, they don't need to be.
The basic (SPP) parallel port interface is really just a glorified set
of GPIOs and could at least in theory be implemented as-is on any
platform with contiguous GPIO ports. The faster modes (EPP and ECP) do
contain logic, and ECP depends on the ISA DMA API (thanks to Russell for
pointing out that actual ISA DMA is not required, any slave DMA solution
will do.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* [PATCH -v3] Audit: push audit success and retcode into arch ptrace.h
From: Eric Paris @ 2011-06-15 15:19 UTC (permalink / raw)
To: monstr, schwidefsky, heiko.carstens, viro, eparis, akpm
Cc: linux-mips, linux-ia64, user-mode-linux-devel, linux-s390,
linux-sh, microblaze-uclinux, x86, linux-kernel, lethal,
sparclinux, linux390, linuxppc-dev
The audit system previously expected arches calling to audit_syscall_exit to
supply as arguments if the syscall was a success and what the return code was.
Audit also provides a helper AUDITSC_RESULT which was supposed to simplify things
by converting from negative retcodes to an audit internal magic value stating
success or failure. This helper was wrong and could indicate that a valid
pointer returned to userspace was a failed syscall. The fix is to fix the
layering foolishness. We now pass audit_syscall_exit a struct pt_reg and it
in turns calls back into arch code to collect the return value and to
determine if the syscall was a success or failure. We also define a generic
is_syscall_success() macro which determines success/failure based on if the
value is < -MAX_ERRNO. This works for arches like x86 which do not use a
separate mechanism to indicate syscall failure.
We make both the is_syscall_success() and regs_return_value() static inlines
instead of macros. The reason is because the audit function must take a void*
for the regs. (uml calls theirs struct uml_pt_regs instead of just struct
pt_regs so audit_syscall_exit can't take a struct pt_regs). Since the audit
function takes a void* we need to use static inlines to cast it back to the
arch correct structure to dereference it.
The other major change is that on some arches, like ia64, MIPS and ppc, we
change regs_return_value() to give us the negative value on syscall failure.
THE only other user of this macro, kretprobe_example.c, won't notice and it
makes the value signed consistently for the audit functions across all archs.
In arch/sh/kernel/ptrace_64.c I see that we were using regs[9] in the old
audit code as the return value. But the ptrace_64.h code defined the macro
regs_return_value() as regs[3]. I have no idea which one is correct, but this
patch now uses the regs_return_value() function, so it now uses regs[3].
For powerpc we previously used regs->result but now use the
regs_return_value() function which uses regs->gprs[3]. regs->gprs[3] is
always positive so the regs_return_value(), much like ia64 makes it negative
before calling the audit code when appropriate.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: H. Peter Anvin <hpa@zytor.com> [for x86 portion]
Acked-by: Tony Luck <tony.luck@intel.com> [for ia64]
Acked-by: Richard Weinberger <richard@nod.at> [for uml]
Acked-by: David S. Miller <davem@davemloft.net> [for sparc]
Acked-by: Ralf Baechle <ralf@linux-mips.org> [for mips]
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [for ppc]
---
arch/ia64/include/asm/ptrace.h | 13 ++++++++++++-
arch/ia64/kernel/ptrace.c | 9 +--------
arch/microblaze/include/asm/ptrace.h | 5 +++++
arch/microblaze/kernel/ptrace.c | 3 +--
arch/mips/include/asm/ptrace.h | 14 +++++++++++++-
arch/mips/kernel/ptrace.c | 4 +---
arch/powerpc/include/asm/ptrace.h | 13 ++++++++++++-
arch/powerpc/kernel/ptrace.c | 4 +---
arch/s390/include/asm/ptrace.h | 6 +++++-
arch/s390/kernel/ptrace.c | 4 +---
arch/sh/include/asm/ptrace_32.h | 5 ++++-
arch/sh/include/asm/ptrace_64.h | 5 ++++-
arch/sh/kernel/ptrace_32.c | 4 +---
arch/sh/kernel/ptrace_64.c | 4 +---
arch/sparc/include/asm/ptrace.h | 10 +++++++++-
arch/sparc/kernel/ptrace_64.c | 11 +----------
arch/um/kernel/ptrace.c | 4 ++--
arch/um/sys-i386/shared/sysdep/ptrace.h | 4 ++++
arch/um/sys-x86_64/shared/sysdep/ptrace.h | 4 ++++
arch/x86/ia32/ia32entry.S | 10 +++++-----
arch/x86/kernel/entry_32.S | 8 ++++----
arch/x86/kernel/entry_64.S | 10 +++++-----
arch/x86/kernel/ptrace.c | 3 +--
arch/x86/kernel/vm86_32.c | 4 ++--
include/linux/audit.h | 22 ++++++++++++++--------
include/linux/ptrace.h | 10 ++++++++++
kernel/auditsc.c | 16 ++++++++++++----
27 files changed, 135 insertions(+), 74 deletions(-)
diff --git a/arch/ia64/include/asm/ptrace.h b/arch/ia64/include/asm/ptrace.h
index 7ae9c3f..801ee1a 100644
--- a/arch/ia64/include/asm/ptrace.h
+++ b/arch/ia64/include/asm/ptrace.h
@@ -246,7 +246,18 @@ static inline unsigned long user_stack_pointer(struct pt_regs *regs)
return regs->ar_bspstore;
}
-#define regs_return_value(regs) ((regs)->r8)
+static inline int is_syscall_success(struct pt_regs *regs)
+{
+ return regs->r10 != -1;
+}
+
+static inline long regs_return_value(struct pt_regs *regs)
+{
+ if (is_syscall_success(regs))
+ return regs->r8;
+ else
+ return -regs->r8;
+}
/* Conserve space in histogram by encoding slot bits in address
* bits 2 and 3 rather than bits 0 and 1.
diff --git a/arch/ia64/kernel/ptrace.c b/arch/ia64/kernel/ptrace.c
index 8848f43..2c15408 100644
--- a/arch/ia64/kernel/ptrace.c
+++ b/arch/ia64/kernel/ptrace.c
@@ -1268,14 +1268,7 @@ syscall_trace_leave (long arg0, long arg1, long arg2, long arg3,
{
int step;
- if (unlikely(current->audit_context)) {
- int success = AUDITSC_RESULT(regs.r10);
- long result = regs.r8;
-
- if (success != AUDITSC_SUCCESS)
- result = -result;
- audit_syscall_exit(success, result);
- }
+ audit_syscall_exit(®s);
step = test_thread_flag(TIF_SINGLESTEP);
if (step || test_thread_flag(TIF_SYSCALL_TRACE))
diff --git a/arch/microblaze/include/asm/ptrace.h b/arch/microblaze/include/asm/ptrace.h
index d9b6630..bec1c74 100644
--- a/arch/microblaze/include/asm/ptrace.h
+++ b/arch/microblaze/include/asm/ptrace.h
@@ -61,6 +61,11 @@ struct pt_regs {
#define instruction_pointer(regs) ((regs)->pc)
#define profile_pc(regs) instruction_pointer(regs)
+static inline long regs_return_value(struct pt_regs *regs)
+{
+ return regs->r3;
+}
+
void show_regs(struct pt_regs *);
#else /* __KERNEL__ */
diff --git a/arch/microblaze/kernel/ptrace.c b/arch/microblaze/kernel/ptrace.c
index 6a8e0cc..9747fa5 100644
--- a/arch/microblaze/kernel/ptrace.c
+++ b/arch/microblaze/kernel/ptrace.c
@@ -159,8 +159,7 @@ asmlinkage void do_syscall_trace_leave(struct pt_regs *regs)
{
int step;
- if (unlikely(current->audit_context))
- audit_syscall_exit(AUDITSC_RESULT(regs->r3), regs->r3);
+ audit_syscall_exit(regs);
step = test_thread_flag(TIF_SINGLESTEP);
if (step || test_thread_flag(TIF_SYSCALL_TRACE))
diff --git a/arch/mips/include/asm/ptrace.h b/arch/mips/include/asm/ptrace.h
index de39b1f..7d40950 100644
--- a/arch/mips/include/asm/ptrace.h
+++ b/arch/mips/include/asm/ptrace.h
@@ -137,7 +137,19 @@ extern int ptrace_set_watch_regs(struct task_struct *child,
*/
#define user_mode(regs) (((regs)->cp0_status & KU_MASK) == KU_USER)
-#define regs_return_value(_regs) ((_regs)->regs[2])
+static inline int is_syscall_success(struct pt_regs *regs)
+{
+ return !regs->regs[7];
+}
+
+static inline long regs_return_value(struct pt_regs *regs)
+{
+ if (is_syscall_success(regs))
+ return regs->regs[2];
+ else
+ return -regs->regs[2];
+}
+
#define instruction_pointer(regs) ((regs)->cp0_epc)
#define profile_pc(regs) instruction_pointer(regs)
diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
index 4e6ea1f..ab0f196 100644
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -572,9 +572,7 @@ out:
*/
asmlinkage void syscall_trace_leave(struct pt_regs *regs)
{
- if (unlikely(current->audit_context))
- audit_syscall_exit(AUDITSC_RESULT(regs->regs[7]),
- -regs->regs[2]);
+ audit_syscall_exit(regs);
if (!(current->ptrace & PT_PTRACED))
return;
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 48223f9..78a2051 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -86,7 +86,18 @@ struct pt_regs {
#define instruction_pointer(regs) ((regs)->nip)
#define user_stack_pointer(regs) ((regs)->gpr[1])
#define kernel_stack_pointer(regs) ((regs)->gpr[1])
-#define regs_return_value(regs) ((regs)->gpr[3])
+static inline int is_syscall_success(struct pt_regs *regs)
+{
+ return !(regs->ccr & 0x10000000);
+}
+
+static inline long regs_return_value(struct pt_regs *regs)
+{
+ if (is_syscall_success(regs))
+ return regs->gpr[3];
+ else
+ return -regs->gpr[3];
+}
#ifdef CONFIG_SMP
extern unsigned long profile_pc(struct pt_regs *regs);
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index cb22024..d801ab7 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1741,9 +1741,7 @@ void do_syscall_trace_leave(struct pt_regs *regs)
{
int step;
- if (unlikely(current->audit_context))
- audit_syscall_exit((regs->ccr&0x10000000)?AUDITSC_FAILURE:AUDITSC_SUCCESS,
- regs->result);
+ audit_syscall_exit(regs);
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_exit(regs, regs->result);
diff --git a/arch/s390/include/asm/ptrace.h b/arch/s390/include/asm/ptrace.h
index 9ad628a..df397e8 100644
--- a/arch/s390/include/asm/ptrace.h
+++ b/arch/s390/include/asm/ptrace.h
@@ -544,9 +544,13 @@ extern void show_regs(struct pt_regs * regs);
#define user_mode(regs) (((regs)->psw.mask & PSW_MASK_PSTATE) != 0)
#define instruction_pointer(regs) ((regs)->psw.addr & PSW_ADDR_INSN)
#define user_stack_pointer(regs)((regs)->gprs[15])
-#define regs_return_value(regs)((regs)->gprs[2])
#define profile_pc(regs) instruction_pointer(regs)
+static inline long regs_return_value(struct pt_regs *regs)
+{
+ return regs->gprs[2];
+}
+
int regs_query_register_offset(const char *name);
const char *regs_query_register_name(unsigned int offset);
unsigned long regs_get_register(struct pt_regs *regs, unsigned int offset);
diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
index ef86ad2..d4d6fcb 100644
--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@ -753,9 +753,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
asmlinkage void do_syscall_trace_exit(struct pt_regs *regs)
{
- if (unlikely(current->audit_context))
- audit_syscall_exit(AUDITSC_RESULT(regs->gprs[2]),
- regs->gprs[2]);
+ audit_syscall_exit(regs);
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_exit(regs, regs->gprs[2]);
diff --git a/arch/sh/include/asm/ptrace_32.h b/arch/sh/include/asm/ptrace_32.h
index 6c2239c..2d3e906 100644
--- a/arch/sh/include/asm/ptrace_32.h
+++ b/arch/sh/include/asm/ptrace_32.h
@@ -76,7 +76,10 @@ struct pt_dspregs {
#ifdef __KERNEL__
#define MAX_REG_OFFSET offsetof(struct pt_regs, tra)
-#define regs_return_value(_regs) ((_regs)->regs[0])
+static inline long regs_return_value(struct pt_regs *regs)
+{
+ return regs->regs[0];
+}
#endif /* __KERNEL__ */
diff --git a/arch/sh/include/asm/ptrace_64.h b/arch/sh/include/asm/ptrace_64.h
index bf9be77..eb3fcce 100644
--- a/arch/sh/include/asm/ptrace_64.h
+++ b/arch/sh/include/asm/ptrace_64.h
@@ -13,7 +13,10 @@ struct pt_regs {
#ifdef __KERNEL__
#define MAX_REG_OFFSET offsetof(struct pt_regs, tregs[7])
-#define regs_return_value(_regs) ((_regs)->regs[3])
+static inline long regs_return_value(struct pt_regs *regs)
+{
+ return regs->regs[3];
+}
#endif /* __KERNEL__ */
diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c
index 3d7b209..5fce97e 100644
--- a/arch/sh/kernel/ptrace_32.c
+++ b/arch/sh/kernel/ptrace_32.c
@@ -529,9 +529,7 @@ asmlinkage void do_syscall_trace_leave(struct pt_regs *regs)
{
int step;
- if (unlikely(current->audit_context))
- audit_syscall_exit(AUDITSC_RESULT(regs->regs[0]),
- regs->regs[0]);
+ audit_syscall_exit(regs);
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_exit(regs, regs->regs[0]);
diff --git a/arch/sh/kernel/ptrace_64.c b/arch/sh/kernel/ptrace_64.c
index c8f9764..ba720d6 100644
--- a/arch/sh/kernel/ptrace_64.c
+++ b/arch/sh/kernel/ptrace_64.c
@@ -548,9 +548,7 @@ asmlinkage void do_syscall_trace_leave(struct pt_regs *regs)
{
int step;
- if (unlikely(current->audit_context))
- audit_syscall_exit(AUDITSC_RESULT(regs->regs[9]),
- regs->regs[9]);
+ audit_syscall_exit(regs);
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_exit(regs, regs->regs[9]);
diff --git a/arch/sparc/include/asm/ptrace.h b/arch/sparc/include/asm/ptrace.h
index c7ad3fe..10f98ca 100644
--- a/arch/sparc/include/asm/ptrace.h
+++ b/arch/sparc/include/asm/ptrace.h
@@ -206,7 +206,15 @@ do { current_thread_info()->syscall_noerror = 1; \
#define user_mode(regs) (!((regs)->tstate & TSTATE_PRIV))
#define instruction_pointer(regs) ((regs)->tpc)
#define user_stack_pointer(regs) ((regs)->u_regs[UREG_FP])
-#define regs_return_value(regs) ((regs)->u_regs[UREG_I0])
+static inline int is_syscall_success(struct pt_regs *regs)
+{
+ return !(regs->tstate & (TSTATE_XCARRY | TSTATE_ICARRY));
+}
+
+static inline long regs_return_value(struct pt_regs *regs)
+{
+ return regs->u_regs[UREG_I0];
+}
#ifdef CONFIG_SMP
extern unsigned long profile_pc(struct pt_regs *);
#else
diff --git a/arch/sparc/kernel/ptrace_64.c b/arch/sparc/kernel/ptrace_64.c
index 96ee50a..c73c8c5 100644
--- a/arch/sparc/kernel/ptrace_64.c
+++ b/arch/sparc/kernel/ptrace_64.c
@@ -1086,17 +1086,8 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
asmlinkage void syscall_trace_leave(struct pt_regs *regs)
{
-#ifdef CONFIG_AUDITSYSCALL
- if (unlikely(current->audit_context)) {
- unsigned long tstate = regs->tstate;
- int result = AUDITSC_SUCCESS;
+ audit_syscall_exit(regs);
- if (unlikely(tstate & (TSTATE_XCARRY | TSTATE_ICARRY)))
- result = AUDITSC_FAILURE;
-
- audit_syscall_exit(result, regs->u_regs[UREG_I0]);
- }
-#endif
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_exit(regs, regs->u_regs[UREG_G1]);
diff --git a/arch/um/kernel/ptrace.c b/arch/um/kernel/ptrace.c
index 701b672..839141d 100644
--- a/arch/um/kernel/ptrace.c
+++ b/arch/um/kernel/ptrace.c
@@ -203,8 +203,8 @@ void syscall_trace(struct uml_pt_regs *regs, int entryexit)
UPT_SYSCALL_ARG2(regs),
UPT_SYSCALL_ARG3(regs),
UPT_SYSCALL_ARG4(regs));
- else audit_syscall_exit(AUDITSC_RESULT(UPT_SYSCALL_RET(regs)),
- UPT_SYSCALL_RET(regs));
+ else
+ audit_syscall_exit(regs);
}
/* Fake a debug trap */
diff --git a/arch/um/sys-i386/shared/sysdep/ptrace.h b/arch/um/sys-i386/shared/sysdep/ptrace.h
index d50e62e..54ca089 100644
--- a/arch/um/sys-i386/shared/sysdep/ptrace.h
+++ b/arch/um/sys-i386/shared/sysdep/ptrace.h
@@ -162,6 +162,10 @@ struct syscall_args {
#define UPT_ORIG_SYSCALL(r) UPT_EAX(r)
#define UPT_SYSCALL_NR(r) UPT_ORIG_EAX(r)
#define UPT_SYSCALL_RET(r) UPT_EAX(r)
+static inline long regs_return_value(struct uml_pt_regs *regs)
+{
+ return UPT_SYSCALL_RET(regs);
+}
#define UPT_FAULTINFO(r) (&(r)->faultinfo)
diff --git a/arch/um/sys-x86_64/shared/sysdep/ptrace.h b/arch/um/sys-x86_64/shared/sysdep/ptrace.h
index fdba545..0924e20 100644
--- a/arch/um/sys-x86_64/shared/sysdep/ptrace.h
+++ b/arch/um/sys-x86_64/shared/sysdep/ptrace.h
@@ -124,6 +124,10 @@ struct uml_pt_regs {
#define UPT_EFLAGS(r) REGS_EFLAGS((r)->gp)
#define UPT_SYSCALL_NR(r) ((r)->syscall)
#define UPT_SYSCALL_RET(r) UPT_RAX(r)
+static inline long regs_return_value(struct uml_pt_regs *regs)
+{
+ return UPT_SYSCALL_RET(regs);
+}
extern int user_context(unsigned long sp);
diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index a0e866d..d19154c 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -14,6 +14,7 @@
#include <asm/segment.h>
#include <asm/irqflags.h>
#include <linux/linkage.h>
+#include <linux/err.h>
/* Avoid __ASSEMBLER__'ifying <linux/audit.h> just for this. */
#include <linux/elf-em.h>
@@ -210,13 +211,12 @@ sysexit_from_sys_call:
TRACE_IRQS_ON
sti
movl %eax,%esi /* second arg, syscall return value */
- cmpl $0,%eax /* is it < 0? */
- setl %al /* 1 if so, 0 if not */
+ cmpl $-MAX_ERRNO,%eax /* is it an error ? */
+ setbe %al /* 1 if so, 0 if not */
movzbl %al,%edi /* zero-extend that into %edi */
- inc %edi /* first arg, 0->1(AUDITSC_SUCCESS), 1->2(AUDITSC_FAILURE) */
- call audit_syscall_exit
+ call __audit_syscall_exit
GET_THREAD_INFO(%r10)
- movl RAX-ARGOFFSET(%rsp),%eax /* reload syscall return value */
+ movq RAX-ARGOFFSET(%rsp),%rax /* reload syscall return value */
movl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),%edi
cli
TRACE_IRQS_OFF
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 5c1a919..584112a 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -54,6 +54,7 @@
#include <asm/ftrace.h>
#include <asm/irq_vectors.h>
#include <asm/cpufeature.h>
+#include <linux/err.h>
/* Avoid __ASSEMBLER__'ifying <linux/audit.h> just for this. */
#include <linux/elf-em.h>
@@ -465,11 +466,10 @@ sysexit_audit:
TRACE_IRQS_ON
ENABLE_INTERRUPTS(CLBR_ANY)
movl %eax,%edx /* second arg, syscall return value */
- cmpl $0,%eax /* is it < 0? */
- setl %al /* 1 if so, 0 if not */
+ cmpl $-MAX_ERRNO,%eax /* is it an error ? */
+ setbe %al /* 1 if so, 0 if not */
movzbl %al,%eax /* zero-extend that */
- inc %eax /* first arg, 0->1(AUDITSC_SUCCESS), 1->2(AUDITSC_FAILURE) */
- call audit_syscall_exit
+ call __audit_syscall_exit
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF
movl TI_flags(%ebp), %ecx
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index ed9d6f3..385b7a9 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -55,6 +55,7 @@
#include <asm/paravirt.h>
#include <asm/ftrace.h>
#include <asm/percpu.h>
+#include <linux/err.h>
/* Avoid __ASSEMBLER__'ifying <linux/audit.h> just for this. */
#include <linux/elf-em.h>
@@ -566,17 +567,16 @@ auditsys:
jmp system_call_fastpath
/*
- * Return fast path for syscall audit. Call audit_syscall_exit()
+ * Return fast path for syscall audit. Call __audit_syscall_exit()
* directly and then jump back to the fast path with TIF_SYSCALL_AUDIT
* masked off.
*/
sysret_audit:
movq RAX-ARGOFFSET(%rsp),%rsi /* second arg, syscall return value */
- cmpq $0,%rsi /* is it < 0? */
- setl %al /* 1 if so, 0 if not */
+ cmpq $-MAX_ERRNO,%rsi /* is it < -MAX_ERRNO? */
+ setbe %al /* 1 if so, 0 if not */
movzbl %al,%edi /* zero-extend that into %edi */
- inc %edi /* first arg, 0->1(AUDITSC_SUCCESS), 1->2(AUDITSC_FAILURE) */
- call audit_syscall_exit
+ call __audit_syscall_exit
movl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),%edi
jmp sysret_check
#endif /* CONFIG_AUDITSYSCALL */
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 807c2a2..5c6281e 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1412,8 +1412,7 @@ void syscall_trace_leave(struct pt_regs *regs)
{
bool step;
- if (unlikely(current->audit_context))
- audit_syscall_exit(AUDITSC_RESULT(regs->ax), regs->ax);
+ audit_syscall_exit(regs);
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_exit(regs, regs->ax);
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 863f875..af17e1c 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -335,9 +335,9 @@ static void do_sys_vm86(struct kernel_vm86_struct *info, struct task_struct *tsk
if (info->flags & VM86_SCREEN_BITMAP)
mark_screen_rdonly(tsk->mm);
- /*call audit_syscall_exit since we do not exit via the normal paths */
+ /*call __audit_syscall_exit since we do not exit via the normal paths */
if (unlikely(current->audit_context))
- audit_syscall_exit(AUDITSC_RESULT(0), 0);
+ __audit_syscall_exit(1, 0);
__asm__ __volatile__(
"movl %0,%%esp\n\t"
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 208efd6..0452dfc 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -26,6 +26,7 @@
#include <linux/types.h>
#include <linux/elf-em.h>
+#include <linux/ptrace.h>
/* The netlink messages for the audit system is divided into blocks:
* 1000 - 1099 are for commanding the audit system
@@ -410,10 +411,6 @@ struct audit_field {
void *lsm_rule;
};
-#define AUDITSC_INVALID 0
-#define AUDITSC_SUCCESS 1
-#define AUDITSC_FAILURE 2
-#define AUDITSC_RESULT(x) ( ((long)(x))<0?AUDITSC_FAILURE:AUDITSC_SUCCESS )
extern int __init audit_register_class(int class, unsigned *list);
extern int audit_classify_syscall(int abi, unsigned syscall);
extern int audit_classify_arch(int arch);
@@ -426,7 +423,7 @@ extern void audit_free(struct task_struct *task);
extern void audit_syscall_entry(int arch,
int major, unsigned long a0, unsigned long a1,
unsigned long a2, unsigned long a3);
-extern void audit_syscall_exit(int failed, long return_code);
+extern void __audit_syscall_exit(int ret_success, long ret_value);
extern void __audit_getname(const char *name);
extern void audit_putname(const char *name);
extern void __audit_inode(const char *name, const struct dentry *dentry);
@@ -441,6 +438,15 @@ static inline int audit_dummy_context(void)
void *p = current->audit_context;
return !p || *(int *)p;
}
+static inline void audit_syscall_exit(void *pt_regs)
+{
+ if (unlikely(current->audit_context)) {
+ int success = is_syscall_success(pt_regs);
+ int return_code = regs_return_value(pt_regs);
+
+ __audit_syscall_exit(success, return_code);
+ }
+}
static inline void audit_getname(const char *name)
{
if (unlikely(!audit_dummy_context()))
@@ -560,12 +566,12 @@ static inline void audit_mmap_fd(int fd, int flags)
extern int audit_n_rules;
extern int audit_signals;
-#else
+#else /* CONFIG_AUDITSYSCALL */
#define audit_finish_fork(t)
#define audit_alloc(t) ({ 0; })
#define audit_free(t) do { ; } while (0)
#define audit_syscall_entry(ta,a,b,c,d,e) do { ; } while (0)
-#define audit_syscall_exit(f,r) do { ; } while (0)
+#define audit_syscall_exit(r) do { ; } while (0)
#define audit_dummy_context() 1
#define audit_getname(n) do { ; } while (0)
#define audit_putname(n) do { ; } while (0)
@@ -597,7 +603,7 @@ extern int audit_signals;
#define audit_rng(d, c, l) (0)
#define audit_n_rules 0
#define audit_signals 0
-#endif
+#endif /* CONFIG_AUDITSYSCALL */
#ifdef CONFIG_AUDIT
/* These are defined in audit.c */
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index e93ef1a..7ec570f 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -98,6 +98,7 @@
#include <linux/compiler.h> /* For unlikely. */
#include <linux/sched.h> /* For struct task_struct. */
+#include <linux/err.h> /* for IS_ERR_VALUE */
extern long arch_ptrace(struct task_struct *child, long request,
@@ -223,6 +224,15 @@ static inline void ptrace_release_task(struct task_struct *task)
#define force_successful_syscall_return() do { } while (0)
#endif
+#ifndef is_syscall_success
+/*
+ * On most systems we can tell if a syscall is a success based on if the retval
+ * is an error value. On some systems like ia64 and powerpc they have different
+ * indicators of success/failure and must define their own.
+ */
+#define is_syscall_success(regs) (!IS_ERR_VALUE((unsigned long)(regs_return_value(regs))))
+#endif
+
/*
* <asm/ptrace.h> should define the following things inside #ifdef __KERNEL__.
*
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 9c61afe..d21a34f 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -70,6 +70,11 @@
#include "audit.h"
+/* flags stating the success for a syscall */
+#define AUDITSC_INVALID 0
+#define AUDITSC_SUCCESS 1
+#define AUDITSC_FAILURE 2
+
/* AUDIT_NAMES is the number of slots we reserve in the audit_context
* for saving names from getname(). If we get more names we will allocate
* a name dynamically and also add those to the list anchored by names_list. */
@@ -1737,8 +1742,7 @@ void audit_finish_fork(struct task_struct *child)
/**
* audit_syscall_exit - deallocate audit context after a system call
- * @valid: success/failure flag
- * @return_code: syscall return value
+ * @pt_regs: syscall registers
*
* Tear down after system call. If the audit context has been marked as
* auditable (either because of the AUDIT_RECORD_CONTEXT state from
@@ -1746,13 +1750,17 @@ void audit_finish_fork(struct task_struct *child)
* message), then write out the syscall information. In call cases,
* free the names stored from getname().
*/
-void audit_syscall_exit(int valid, long return_code)
+void __audit_syscall_exit(int success, long return_code)
{
struct task_struct *tsk = current;
struct audit_context *context;
- context = audit_get_context(tsk, valid, return_code);
+ if (success)
+ success = AUDITSC_SUCCESS;
+ else
+ success = AUDITSC_FAILURE;
+ context = audit_get_context(tsk, success, return_code);
if (likely(!context))
return;
^ permalink raw reply related
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Russell King - ARM Linux @ 2011-06-15 15:21 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, Arnd Bergmann, microblaze-uclinux,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-cris-kernel, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <4DF8CAD5.1090902@zytor.com>
On Wed, Jun 15, 2011 at 08:08:05AM -0700, H. Peter Anvin wrote:
> On 06/15/2011 12:47 AM, Russell King - ARM Linux wrote:
> >>
> >> OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs
> >> are ubiquitous across just about every platform.
> >>
> >> Floppy is special (in the short bus sense), since it is closely tied to
> >> ISA DMA. Conditionalizing this on ISA DMA 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.
It's already been solved - ARCH_MAY_HAVE_PC_FDC is supposed to be
defined to y in the cases where architectures have support for it.
What we do on ARM for example is:
config ARCH_MAY_HAVE_PC_FDC
bool
and then select that symbol for our platforms which can have the
floppy driver.
And in any case we already have definitions for the presence of the
ISA DMA API vs the common ISA DMA helpers in kernel/. The presence
of the ISA DMA API is given by CONFIG_ISA_DMA_API, while the
ISA DMA helper CONFIG_GENERIC_ISA_DMA.
^ permalink raw reply
* Re: Relocatable kernel for ppc44x
From: Tirumala Marri @ 2011-06-15 16:02 UTC (permalink / raw)
To: Suzuki Poulose; +Cc: monstr, John Williams, linuxppc-dev
In-Reply-To: <4DF8C453.70500@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]
On Wed, Jun 15, 2011 at 7:40 AM, Suzuki Poulose <suzuki@in.ibm.com> wrote:
> On 06/15/11 15:41, Benjamin Herrenschmidt wrote:
>
>> On Wed, 2011-06-15 at 11:43 +0530, Suzuki Poulose wrote:
>>
>>> On 06/14/11 17:34, Michal Simek wrote:
>>>
>>>> Hi,
>>>>
>>>> have someone tried to support RELOCATABLE kernel on ppc44x?
>>>>
>>> As Josh, mentioned, I will be working on this. In fact I was trying a
>>> couple of
>>> patches towards this on PPC440x. But, I am stuck in debugging the hang
>>> that I am
>>> experiencing with the changes. I am setting up a RISCWatch processor
>>> probe to
>>> debug the same.
>>>
>>> Here is some information that I wanted to share :
>>>
>>> The PPC440X currently uses 256M TLB entries to pin the lowmem. When we go
>>> for a
>>> relocatable kernel we have to :
>>>
>>> 1) Restrict the kernel load address to be 256M aligned
>>>
>>
>> Wait a minute ... :-)
>>
>> There's a difference between having the kernel run from any address and
>> mapping the linear mapping not starting at 0.
>>
>> Those are completely orthogonal.
>>
>> I don't see why off hand you are changing the way the TLB is used.
>>
>
> I started off with PHYSICAL_START support and that kind of hogged me into
> this approach :-).
>
> The
>
>> only possible change needed is to make sure the initial bolted entry set
>> by the asm code properly covers the kernel in whatever it's "current"
>> location is. The rest is a matter of fixing up the relocations...
>>
> Could we do something like,
>
> If kernel is loaded at X,
>
> 1. map : ((X-1) & ~256M) to PAGE_OFFSET and so on to cover the kernel in
> 256M
> chunks.
> 2. Then process the relocations with (X % 256M)
>
> Thanks
>
> [marri] I had to deal with kernel relocation to non-zero physical address.
I hacked
few places to make this work. In my case there were holes(mutliple of 250MB)
in
the low-memory region. To handle these memory holes I manipulated "lmb"
structure.
I had to depend on the bootloader making sure that it is running from
non-zero
physical address and during linux boot it checks for the current TLB where
it is
running from and creates the same new TLB in linux. And everything else
should
take care of it.
--marri
[-- Attachment #2: Type: text/html, Size: 3212 bytes --]
^ permalink raw reply
* libata/ipr/powerpc: regression between 2.6.39-rc4 and 2.6.39-rc5
From: Nishanth Aravamudan @ 2011-06-15 19:17 UTC (permalink / raw)
To: jgarzik; +Cc: wayneb, linux-kernel, linux-ide, tj, mbizon, linuxppc-dev
Hi Jeff,
It appears that commit 7b3a24c57d2eeda8dba9c205342b12689c4679f9 broke
CD-ROMs on the IPR SATA bus on powerpc machines:
ata_port_alloc: ENTER
ata_port_probe: ata1: bus probe begin
ata1.00: ata_dev_read_id: ENTER
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40)
ata1.00: ata_dev_read_id: ENTER
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40)
ata1.00: limiting speed to UDMA7:PIO5
ata1.00: ata_dev_read_id: ENTER
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40)
ata1.00: disabled
ata_port_probe: ata1: bus probe end
scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
The commit in question is tagged as AHCI, but does touch the libata
core. I'm not well-versed with this code, but here's what I think I know
:)
>From __scsi_add_device, we first allocate the target:
scsi_alloc_target ->
shost->hostt->target_alloc ->
ipr_target_alloc ->
ata_port_alloc ->
sets FROZEN
We error out when we allocate the sdev:
scsi_alloc_sdev ->
shost->hostt->slave_alloc ->
ipr_slave_alloc ->
ipr_ata_slave_alloc ->
ata_sas_port_init ->
ata_port_probe
>From what I can tell, the only place that explicitly clears the FROZEN
flag is the error-handling code via ata_eh_thaw_port().
So I thought either we're not invoking the error-handler at probe time
correctly to kick the port or perhaps the SAS code is not clearing the
flag?
I tried the following patch:
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index d51f979..abd0e0b 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3797,6 +3797,7 @@ EXPORT_SYMBOL_GPL(ata_sas_port_alloc);
*/
int ata_sas_port_start(struct ata_port *ap)
{
+ ap->pflags &= ~ATA_PFLAG_FROZEN;
return 0;
}
EXPORT_SYMBOL_GPL(ata_sas_port_start);
and the CD-ROM drive works, but I have no idea if it's the right thing
to do. I chose this particular change, FWIW, because we call
ata_sas_port_start before we probe in ata_sas_port_init and it seems
like we need to mark the port as not frozen before we init it? Perhaps
that should really be a call to a thaw function, not sure. Let's just
say the ATA/SAS/SCSI interactions are a bit hard to follow at first :)
Any insight you can provide would be great!
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply related
* Re: Relocatable kernel for ppc44x
From: Scott Wood @ 2011-06-15 19:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, monstr, Suzuki Poulose, John Williams
In-Reply-To: <1308132715.2516.1.camel@pasglop>
On Wed, 15 Jun 2011 20:11:55 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2011-06-15 at 11:43 +0530, Suzuki Poulose wrote:
> > On 06/14/11 17:34, Michal Simek wrote:
> > > Hi,
> > >
> > > have someone tried to support RELOCATABLE kernel on ppc44x?
> > As Josh, mentioned, I will be working on this. In fact I was trying a couple of
> > patches towards this on PPC440x. But, I am stuck in debugging the hang that I am
> > experiencing with the changes. I am setting up a RISCWatch processor probe to
> > debug the same.
> >
> > Here is some information that I wanted to share :
> >
> > The PPC440X currently uses 256M TLB entries to pin the lowmem. When we go for a
> > relocatable kernel we have to :
> >
> > 1) Restrict the kernel load address to be 256M aligned
>
> Wait a minute ... :-)
>
> There's a difference between having the kernel run from any address and
> mapping the linear mapping not starting at 0.
>
> Those are completely orthogonal.
>
> I don't see why off hand you are changing the way the TLB is used. The
> only possible change needed is to make sure the initial bolted entry set
> by the asm code properly covers the kernel in whatever it's "current"
> location is. The rest is a matter of fixing up the relocations...
Changing where the linear mapping points to is useful for AMP configurations
where you're supposed to be considering your memory to be a subset of the
real memory. This is implemented on e500 as CONFIG_RELOCATABLE, though
it should have been called something different since it's not really
building a relocatable kernel (unlike what 64-bit does with
CONFIG_RELOCATABLE).
-Scott
^ permalink raw reply
* Re: libata/ipr/powerpc: regression between 2.6.39-rc4 and 2.6.39-rc5
From: Brian King @ 2011-06-15 20:02 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: linuxppc-dev, wayneb, linux-kernel, linux-ide, tj, mbizon,
jgarzik
In-Reply-To: <20110615191747.GA6324@us.ibm.com>
On 06/15/2011 02:17 PM, Nishanth Aravamudan wrote:
> From what I can tell, the only place that explicitly clears the FROZEN
> flag is the error-handling code via ata_eh_thaw_port().
>
> So I thought either we're not invoking the error-handler at probe time
> correctly to kick the port or perhaps the SAS code is not clearing the
> flag?
>
> I tried the following patch:
>
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index d51f979..abd0e0b 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -3797,6 +3797,7 @@ EXPORT_SYMBOL_GPL(ata_sas_port_alloc);
> */
> int ata_sas_port_start(struct ata_port *ap)
> {
> + ap->pflags &= ~ATA_PFLAG_FROZEN;
> return 0;
> }
> EXPORT_SYMBOL_GPL(ata_sas_port_start);
>
> and the CD-ROM drive works, but I have no idea if it's the right thing
> to do. I chose this particular change, FWIW, because we call
> ata_sas_port_start before we probe in ata_sas_port_init and it seems
> like we need to mark the port as not frozen before we init it? Perhaps
> that should really be a call to a thaw function, not sure. Let's just
> say the ATA/SAS/SCSI interactions are a bit hard to follow at first :)
That looks like the right thing to do. For ipr's usage of
libata, we don't have the concept of a port frozen state, so this flag
should really never get set. The alternate way to fix this would be to
only set ATA_PFLAG_FROZEN in ata_port_alloc if ap->ops->error_handler
is not NULL.
Thanks,
Brian
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: libata/ipr/powerpc: regression between 2.6.39-rc4 and 2.6.39-rc5
From: Nishanth Aravamudan @ 2011-06-15 23:34 UTC (permalink / raw)
To: Brian King
Cc: linuxppc-dev, wayneb, linux-kernel, linux-ide, tj, mbizon,
jgarzik
In-Reply-To: <4DF90FCA.1040706@linux.vnet.ibm.com>
On 15.06.2011 [15:02:18 -0500], Brian King wrote:
> On 06/15/2011 02:17 PM, Nishanth Aravamudan wrote:
> > From what I can tell, the only place that explicitly clears the FROZEN
> > flag is the error-handling code via ata_eh_thaw_port().
> >
> > So I thought either we're not invoking the error-handler at probe time
> > correctly to kick the port or perhaps the SAS code is not clearing the
> > flag?
> >
> > I tried the following patch:
> >
> > diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> > index d51f979..abd0e0b 100644
> > --- a/drivers/ata/libata-scsi.c
> > +++ b/drivers/ata/libata-scsi.c
> > @@ -3797,6 +3797,7 @@ EXPORT_SYMBOL_GPL(ata_sas_port_alloc);
> > */
> > int ata_sas_port_start(struct ata_port *ap)
> > {
> > + ap->pflags &= ~ATA_PFLAG_FROZEN;
> > return 0;
> > }
> > EXPORT_SYMBOL_GPL(ata_sas_port_start);
> >
> > and the CD-ROM drive works, but I have no idea if it's the right thing
> > to do. I chose this particular change, FWIW, because we call
> > ata_sas_port_start before we probe in ata_sas_port_init and it seems
> > like we need to mark the port as not frozen before we init it? Perhaps
> > that should really be a call to a thaw function, not sure. Let's just
> > say the ATA/SAS/SCSI interactions are a bit hard to follow at first :)
>
> That looks like the right thing to do. For ipr's usage of
> libata, we don't have the concept of a port frozen state, so this flag
> should really never get set. The alternate way to fix this would be to
> only set ATA_PFLAG_FROZEN in ata_port_alloc if ap->ops->error_handler
> is not NULL.
It seemed like ipr is as you say, but I wasn't sure if it was
appropriate to make the change above in the common libata-scis code or
not. I don't want to break some other device on accident.
Also, I tried your suggestion, but I don't think that can happen in
ata_port_alloc? ata_port_alloc is allocated ap itself, and it seems like
ap->ops typically gets set only after ata_port_alloc returns?
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC][PATCH] kexec-tools: powerpc: Use the #address-cells information to parsememory/reg - V2
From: Simon Horman @ 2011-06-16 0:12 UTC (permalink / raw)
To: Suzuki Poulose
Cc: linux ppc dev, Sebastian Andrzej Siewior, David Laight,
kexec@lists.infradead.org
In-Reply-To: <4DEF18FF.6070206@in.ibm.com>
On Wed, Jun 08, 2011 at 12:08:55PM +0530, Suzuki Poulose wrote:
> Hi,
>
> This is version 2 of the patch
>
> Changes from Version 1 :
> : Changed the interface for read_memory_region_limits to use 'int fd'
> instead of FILE*.
> : Use sizeof(variable) for read(, instead of sizeof(type).
>
>
> ---
>
> Fix parsing of the memory region information from the device-tree.
>
> The format of memory/reg is based on the #address-cells,#size-cells. Currently,
> the kexec-tools doesn't use the above values in parsing the memory/reg values.
> Hence the kexec cannot handle cases where #address-cells, #size-cells are
> different, (for e.g, PPC440X ).
>
> This patch introduces a read_memory_region_limits(), which parses the
> memory/reg contents based on the values of #address-cells and #size-cells.
>
> Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Hi,
this does not seem to apply to the master branch of
git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
^ permalink raw reply
* [PATCH][v3] Add support for RTC device: pt7c4338 in rtc-ds1307.c
From: Priyanka Jain @ 2011-06-16 4:05 UTC (permalink / raw)
To: akpm, w.sang, cbouatmailru, a.zummo, benh, galak, grant.likely,
b04825, linuxppc-dev, rtc-linux, p_gortmaker
Cc: Priyanka Jain
PT7C4338 chip is being manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile RAM.
Its register set is same as that of rtc device: DS1307.
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
Change for v3:
Incorporting Timur Tabi's comments to drop Kconfig and copyright
changes
Change for v2:
Incorporting Andrew Morton's comments to shorten patch by using
hunk: { "pt7c4338", ds_1307 }
Changes :
This patch will supersede patch:
"RTC driver(Linux) for PT7C4338 chip"
Incorporting Wolfram Sang's comments to reuse ds1307 driver.
drivers/rtc/rtc-ds1307.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 4724ba3..b2005b4 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -149,6 +149,7 @@ static const struct i2c_device_id ds1307_id[] = {
{ "ds1340", ds_1340 },
{ "ds3231", ds_3231 },
{ "m41t00", m41t00 },
+ { "pt7c4338", ds_1307 },
{ "rx8025", rx_8025 },
{ }
};
--
1.6.5.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox