Re: [PATCH] video: fbdev: controlfb: Fix build for COMPILE_TEST=y && PPC_PMAC=n
On 8/21/20 12:49 PM, Michael Ellerman wrote:
> The build is currently broken, if COMPILE_TEST=y and PPC_PMAC=n:
>
> linux/drivers/video/fbdev/controlfb.c: In function ‘control_set_hardware’:
> linux/drivers/video/fbdev/controlfb.c:276:2: error: implicit declaration of
> function ‘btext_update_display’
> 276 | btext_update_display(p->frame_buffer_phys + CTRLFB_OFF,
> | ^~~~
>
> Fix it by including btext.h whenever CONFIG_BOOTX_TEXT is enabled.
>
> Fixes: a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
> Signed-off-by: Michael Ellerman
Acked-by: Bartlomiej Zolnierkiewicz
Thanks for fixing this.
> ---
> drivers/video/fbdev/controlfb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Does anyone mind if I apply this via the powerpc tree for v5.9?
>
> It would be nice to get the build clean.
No objections from my side.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> cheers
>
> diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
> index 9c4f1be856ec..547abeb39f87 100644
> --- a/drivers/video/fbdev/controlfb.c
> +++ b/drivers/video/fbdev/controlfb.c
> @@ -49,6 +49,8 @@
> #include
> #ifdef CONFIG_PPC_PMAC
> #include
> +#endif
> +#ifdef CONFIG_BOOTX_TEXT
> #include
> #endif
>
Re: [PATCH v2 2/2] powerpc/configs: replace deprecated riva/nvidia with nouveau
On 5/18/20 1:19 PM, Emil Velikov wrote: > Hi Michael, > > On Mon, 18 May 2020 at 08:30, Michael Ellerman wrote: >> >> Emil Velikov writes: >>> As mentioned in earlier commit, the riva and nvidia fbdev drivers have >>> seen no love over the years, are short on features and overall below par >>> >>> Users are encouraged to switch to the nouveau drm driver instead. >>> >>> v2: Split configs to separate patch, enable nouveau (Bartlomiej) >>> >>> Cc: Antonino Daplas >>> Cc: Bartlomiej Zolnierkiewicz >>> Cc: linux-fb...@vger.kernel.org >>> Cc: dri-de...@lists.freedesktop.org >>> Cc: Michael Ellerman >>> Cc: Benjamin Herrenschmidt >>> Cc: Paul Mackerras >>> Cc: linuxppc-dev@lists.ozlabs.org >>> Signed-off-by: Emil Velikov >>> Acked-by: Daniel Vetter (v1) >>> --- >>> Hi all unless, there are objections I would prefer to merge this via >>> the drm tree. >> >> Have you tested that the resulting kernels work on the relevant >> hardware? >> > Sadly, no I haven't. I'm updating the defconfigs as requested by the > fbdev maintainer. I've just noticed that v1 (patch #1/1) & v2 (patch #1/2) lack Cc: to powerpc Maintainers so they cannot see the context of changes in this patch. Also you've proposed v1 yourself and it has already contained modifications to defconfigs (removal of setting the config options for the old drivers) in addition to marking the old drivers as BROKEN. It now turns out that v1 has also never been tested. :( Please don't submit untested patches without marking them as such. >> The old drivers may be crufty but they presumably have been tested by >> people and at least somewhat work. >> >> So I'd be inclined to leave the defconfigs alone until someone can test >> that the new driver works at all. @Michael: Fully agreed. I would also like you to review/ack patch #1/2: https://lore.kernel.org/dri-devel/20200517220524.4036334-1-emil.l.veli...@gmail.com/ Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > Works for me. > >> I gave it a quick spin on a G5 I have access to and dmesg has a bunch of >> errors in it (see below). I can't actually tell if the display is >> working because the machine is remote, and I can't go and check it at >> the moment because the office is closed. >> > >>From what I can see, there seems to be three bits: > - attempted out-of-bound attempts to read the vbios > Genuine concern or noise? Likely using the bios from open firmware, > check any of the other options - see NvBios in [1] > - cannot figure out the timer input frequency > No idea > - the TV1 EDID is empty > Is there an actual TV connected to the device, check with another cable > > Regardless of the patches, reporting [2] the above would be a nice move. > > Thanks > Emil > [1] > https://protect2.fireeye.com/url?k=d6cf7004-8b548c67-d6cefb4b-0cc47a31cdbc-7c3b251c170ed483&q=1&u=https%3A%2F%2Fnouveau.freedesktop.org%2Fwiki%2FKernelModuleParameters%2F > [2] https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues
Re: [PATCH v2 2/2] powerpc: Remove Xilinx PPC405/PPC440 support
On 3/30/20 3:32 PM, Michal Simek wrote:
> The latest Xilinx design tools called ISE and EDK has been released in
> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
> These platforms are no longer supported and tested.
>
> PowerPC 405/440 port is orphan from 2013 by
> commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
> commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and
> maintainership")
> that's why it is time to remove the support fot these platforms.
>
> Signed-off-by: Michal Simek
> Acked-by: Arnd Bergmann
Acked-by: Bartlomiej Zolnierkiewicz # for fbdev
> ---
>
> Changes in v2:
> - Based on my chat with Arnd I removed arch/powerpc/xmon/ changes done in
> v1 to keep them the same as before. (kbuild reported some issues with it
> too)
>
> Documentation/devicetree/bindings/xilinx.txt | 143 --
> Documentation/powerpc/bootwrapper.rst| 28 +-
> MAINTAINERS | 6 -
> arch/powerpc/Kconfig.debug | 2 +-
> arch/powerpc/boot/Makefile | 7 +-
> arch/powerpc/boot/dts/Makefile | 1 -
> arch/powerpc/boot/dts/virtex440-ml507.dts| 406
> arch/powerpc/boot/dts/virtex440-ml510.dts| 466 ---
> arch/powerpc/boot/ops.h | 1 -
> arch/powerpc/boot/serial.c | 5 -
> arch/powerpc/boot/uartlite.c | 79
> arch/powerpc/boot/virtex.c | 97
> arch/powerpc/boot/virtex405-head.S | 31 --
> arch/powerpc/boot/wrapper| 8 -
> arch/powerpc/configs/40x/virtex_defconfig| 75 ---
> arch/powerpc/configs/44x/virtex5_defconfig | 74 ---
> arch/powerpc/configs/ppc40x_defconfig| 8 -
> arch/powerpc/configs/ppc44x_defconfig| 8 -
> arch/powerpc/include/asm/xilinx_intc.h | 16 -
> arch/powerpc/include/asm/xilinx_pci.h| 21 -
> arch/powerpc/kernel/cputable.c | 39 --
> arch/powerpc/platforms/40x/Kconfig | 31 --
> arch/powerpc/platforms/40x/Makefile | 1 -
> arch/powerpc/platforms/40x/virtex.c | 54 ---
> arch/powerpc/platforms/44x/Kconfig | 37 --
> arch/powerpc/platforms/44x/Makefile | 2 -
> arch/powerpc/platforms/44x/virtex.c | 60 ---
> arch/powerpc/platforms/44x/virtex_ml510.c| 30 --
> arch/powerpc/platforms/Kconfig | 4 -
> arch/powerpc/sysdev/Makefile | 2 -
> arch/powerpc/sysdev/xilinx_intc.c| 88
> arch/powerpc/sysdev/xilinx_pci.c | 132 --
> drivers/char/Kconfig | 2 +-
> drivers/video/fbdev/Kconfig | 2 +-
> 34 files changed, 7 insertions(+), 1959 deletions(-)
> delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
> delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
> delete mode 100644 arch/powerpc/boot/uartlite.c
> delete mode 100644 arch/powerpc/boot/virtex.c
> delete mode 100644 arch/powerpc/boot/virtex405-head.S
> delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig
> delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig
> delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h
> delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h
> delete mode 100644 arch/powerpc/platforms/40x/virtex.c
> delete mode 100644 arch/powerpc/platforms/44x/virtex.c
> delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
> delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c
> delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
[PATCH] misc: remove redundant 'default n' from Kconfig-s
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:
...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:
config FOO
bool
config FOO
bool
default n
With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/misc/Kconfig | 10 --
drivers/misc/altera-stapl/Kconfig |1 -
drivers/misc/c2port/Kconfig |2 --
drivers/misc/cb710/Kconfig|1 -
drivers/misc/cxl/Kconfig |3 ---
drivers/misc/echo/Kconfig |1 -
drivers/misc/genwqe/Kconfig |1 -
drivers/misc/lis3lv02d/Kconfig|2 --
drivers/misc/ocxl/Kconfig |1 -
9 files changed, 22 deletions(-)
Index: b/drivers/misc/Kconfig
===
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -8,7 +8,6 @@ config SENSORS_LIS3LV02D
tristate
depends on INPUT
select INPUT_POLLDEV
- default n
config AD525X_DPOT
tristate "Analog Devices Digital Potentiometers"
@@ -61,7 +60,6 @@ config ATMEL_TCLIB
config DUMMY_IRQ
tristate "Dummy IRQ handler"
- default n
---help---
This module accepts a single 'irq' parameter, which it should
register for.
The sole purpose of this module is to help with debugging of systems
on
@@ -117,7 +115,6 @@ config PHANTOM
config INTEL_MID_PTI
tristate "Parallel Trace Interface for MIPI P1149.7 cJTAG standard"
depends on PCI && TTY && (X86_INTEL_MID || COMPILE_TEST)
- default n
help
The PTI (Parallel Trace Interface) driver directs
trace data routed from various parts in the system out
@@ -193,7 +190,6 @@ config ATMEL_SSC
config ENCLOSURE_SERVICES
tristate "Enclosure Services"
- default n
help
Provides support for intelligent enclosures (bays which
contain storage devices). You also need either a host
@@ -217,7 +213,6 @@ config SGI_XP
config CS5535_MFGPT
tristate "CS5535/CS5536 Geode Multi-Function General Purpose Timer
(MFGPT) support"
depends on MFD_CS5535
- default n
help
This driver provides access to MFGPT functionality for other
drivers that need timers. MFGPTs are available in the CS5535 and
@@ -250,7 +245,6 @@ config CS5535_CLOCK_EVENT_SRC
config HP_ILO
tristate "Channel interface driver for the HP iLO processor"
depends on PCI
- default n
help
The channel interface driver allows applications to communicate
with iLO management processors present on HP ProLiant servers.
@@ -285,7 +279,6 @@ config QCOM_FASTRPC
config SGI_GRU
tristate "SGI GRU driver"
depends on X86_UV && SMP
- default n
select MMU_NOTIFIER
---help---
The GRU is a hardware resource located in the system chipset. The GRU
@@ -300,7 +293,6 @@ config SGI_GRU
config SGI_GRU_DEBUG
bool "SGI GRU driver debug"
depends on SGI_GRU
- default n
---help---
This option enables additional debugging code for the SGI GRU driver.
If you are unsure, say N.
@@ -358,7 +350,6 @@ config SENSORS_BH1770
config SENSORS_APDS990X
tristate "APDS990X combined als and proximity sensors"
depends on I2C
-default n
---help---
Say Y here if you want to build a driver for Avago APDS990x
combined ambient light and proximity sensor chip.
@@ -386,7 +377,6 @@ config DS1682
config SPEAR13XX_PCIE_GADGET
bool "PCIe gadget support for SPEAr13XX platform"
depends on ARCH_SPEAR13XX && BROKEN
- default n
help
This option enables gadget support for PCIe controller. If
board file defines any controller as PCIe endpoint then a sysfs
Index: b/drivers/misc/altera-stapl/Kconfig
===
--- a/drivers/misc/altera-stapl/Kconfig
+++ b/drivers/misc/altera-stapl/Kconfig
@@ -4,6 +4,5 @@ comment "Altera FPGA firmware download m
config ALTERA_STAPL
t
Re: Re: Kernel panic when loading the IDE controller driver
On 02/14/2019 06:54 PM, Christophe Leroy wrote: > > > Le 13/02/2019 à 16:27, Christophe Leroy a écrit : >> >> >> Le 13/02/2019 à 13:53, sgosavi1 a écrit : >>>> Why using 4.15.13 which is obsolete instead of using one of the Long >>>> Term Support versions which are still maintained, like 4.14 or 4.19 ? >>>> (see the complete list at https://www.kernel.org/category/releases.html) >>> >>> Well, when I started this task 4.15.13 was probably the latest stable >>> release and hence we decided to port this version. In the older kernel, we >>> have the m8260_setup.c source file for our board where the function >>> "io_block_mapping" was used to configure the non-standard IO port address >>> starting at 0xe000 location. This address was passed as the base address >>> followed by control address and IRQ number to the ide-core.ko module. In the >>> new kernel we do not have an option to send these addresses and IRQ numbers >>> as arguments to the driver. Instead the ide-generic.c source file in the new >>> kernel uses the standard IO port values and IRQ values. I modified the code >>> in the above file to used the addresses and IRQ number we used in the past. >>> Also, added code in the "MMU_init" function call available under >>> arch/PowerPC/init_32.c to setup the IO port address range by adding the >>> "io_block_mapping" call and the required IO port address range. >>> >>> Is there anything else that needs to be added or how can we configure the >>> desired IO address range in the new kernel? >>> >> >> Maybe look around >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9a0e77f28b50128df0c9e26ae489e44e29a7270a >> >> Also look at ide_platform.c. I imagine there must be some way to set it up >> in your device tree. Please don't add new users to subsystem deprecated almost 10 years ago.. >> Maybe Bartlomiej Zolnierkiewicz can help ? >> >> Christophe > > Le 14/02/2019 à 09:17, sgosavi1 a écrit :>> Maybe look around >> >> I have gone through this before and also tried the pata_platform driver but >> no success yet. I haven't found any example that passes the IO ports and IRQ >> information through the device tree to the driver code. Please look at pata_of_platform.c driver from libata subsystem, it should have all required functionality. >> Thanks, >> Sachin. > > > Maybe someone from the IDE SUBSYSTEM would be able to help better ? > > Entire thread at > http://linuxppc.10917.n7.nabble.com/Kernel-panic-when-loading-the-IDE-controller-driver-td150020.html#none > > Christophe Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
[PATCH] powerpc: remove redundant 'default n' from Kconfig-s
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:
...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:
config FOO
bool
config FOO
bool
default n
With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/powerpc/Kconfig | 14 --
arch/powerpc/Kconfig.debug |6 --
arch/powerpc/platforms/40x/Kconfig |9 -
arch/powerpc/platforms/44x/Kconfig | 22 --
arch/powerpc/platforms/82xx/Kconfig|1 -
arch/powerpc/platforms/Kconfig | 21 -
arch/powerpc/platforms/Kconfig.cputype |4
arch/powerpc/platforms/cell/Kconfig|3 ---
arch/powerpc/platforms/maple/Kconfig |1 -
arch/powerpc/platforms/pasemi/Kconfig |1 -
arch/powerpc/platforms/powernv/Kconfig |1 -
arch/powerpc/platforms/ps3/Kconfig |2 --
arch/powerpc/platforms/pseries/Kconfig |2 --
arch/powerpc/sysdev/Kconfig|5 -
arch/powerpc/sysdev/xive/Kconfig |3 ---
15 files changed, 95 deletions(-)
Index: b/arch/powerpc/Kconfig
===
--- a/arch/powerpc/Kconfig 2018-10-09 17:32:25.059264623 +0200
+++ b/arch/powerpc/Kconfig 2018-10-09 17:32:25.055264623 +0200
@@ -285,12 +285,10 @@ config ARCH_MAY_HAVE_PC_FDC
config PPC_UDBG_16550
bool
- default n
config GENERIC_TBSYNC
bool
default y if PPC32 && SMP
- default n
config AUDIT_ARCH
bool
@@ -309,13 +307,11 @@ config EPAPR_BOOT
bool
help
Used to allow a board to specify it wants an ePAPR compliant wrapper.
- default n
config DEFAULT_UIMAGE
bool
help
Used to allow a board to specify it wants a uImage built by default
- default n
config ARCH_HIBERNATION_POSSIBLE
bool
@@ -329,11 +325,9 @@ config ARCH_SUSPEND_POSSIBLE
config PPC_DCR_NATIVE
bool
- default n
config PPC_DCR_MMIO
bool
- default n
config PPC_DCR
bool
@@ -344,7 +338,6 @@ config PPC_OF_PLATFORM_PCI
bool
depends on PCI
depends on PPC64 # not supported on 32 bits yet
- default n
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
depends on PPC32 || PPC_BOOK3S_64
@@ -447,14 +440,12 @@ config PPC_TRANSACTIONAL_MEM
depends on SMP
select ALTIVEC
select VSX
- default n
---help---
Support user-mode Transactional Memory on POWERPC.
config LD_HEAD_STUB_CATCH
bool "Reserve 256 bytes to cope with linker stubs in HEAD text" if
EXPERT
depends on PPC64
- default n
help
Very large kernels can cause linker branch stubs to be generated by
code in head_64.S, which moves the head text sections out of their
@@ -557,7 +548,6 @@ config RELOCATABLE
config RELOCATABLE_TEST
bool "Test relocatable kernel"
depends on (PPC64 && RELOCATABLE)
- default n
help
This runs the relocatable kernel at the address it was initially
loaded at, which tends to be non-zero and therefore test the
@@ -769,7 +759,6 @@ config PPC_SUBPAGE_PROT
config PPC_COPRO_BASE
bool
- default n
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
@@ -870,7 +859,6 @@ config PPC_INDIRECT_PCI
bool
depends on PCI
default y if 40x || 44x
- default n
config EISA
bool
@@ -967,7 +955,6 @@ source "drivers/pcmcia/Kconfig"
config HAS_RAPIDIO
bool
- default n
config RAPIDIO
tristate "RapidIO support"
@@ -990,7 +977,6 @@ endmenu
config NONSTATIC_KERNEL
bool
- default n
menu "Advanced setup"
depends on PPC32
Index: b/arch/powerpc/Kconfig.debug
===
--- a/arch/powerpc/Kconfig.debug2018-10-09 17:32:25.059264623 +0200
+++ b/arch/powerpc/Kconfig.debug2018-10-09 17:32:25.055264623 +0200
@@ -2,7 +2,6 @@
config PPC_DISABLE_WERROR
bool "Don't build arch/powerpc code with -Werror"
- default n
help
This option t
Re: [PATCH v2 02/24] drivers/video/fbdev: use ioremap_wc/wt() instead of __ioremap()
On 09/12/2018 05:58 PM, Christophe Leroy wrote: > _PAGE_NO_CACHE is a platform specific flag. In addition, this flag > is misleading because one would think it requests a noncached page > whereas a noncached page is _PAGE_NO_CACHE | _PAGE_GUARDED > > _PAGE_NO_CACHE alone means write combined noncached page, so lets > use ioremap_wc() instead. > > _PAGE_WRITETHRU is also platform specific flag. Use ioremap_wt() > instead. > > Signed-off-by: Christophe Leroy After reading patch #1 this one LGTM. Acked-by: Bartlomiej Zolnierkiewicz > --- > drivers/video/fbdev/chipsfb.c| 3 +-- > drivers/video/fbdev/controlfb.c | 5 + > drivers/video/fbdev/platinumfb.c | 5 + > drivers/video/fbdev/valkyriefb.c | 12 ++-- > 4 files changed, 9 insertions(+), 16 deletions(-) Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
Re: [PATCH] fbdev: controlfb: Add missing modes to fix out of bounds access
On Tuesday, November 07, 2017 03:05:05 PM Geert Uytterhoeven wrote: > Dan's static analysis says: > > drivers/video/fbdev/controlfb.c:560 control_setup() > error: buffer overflow 'control_mac_modes' 20 <= 21 > > Indeed, control_mac_modes[] has only 20 elements, while VMODE_MAX is 22, > which may lead to an out of bounds read when parsing vmode commandline > options. > > The bug was introduced in v2.4.5.6, when 2 new modes were added to > macmodes.h, but control_mac_modes[] wasn't updated: > > https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.5.2&id=29f279c764808560eaceb88fef36cbc35c529aad > > Augment control_mac_modes[] with the two new video modes to fix this. > > Reported-by: Dan Carpenter > Signed-off-by: Geert Uytterhoeven Patch queued for 4.15, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
Re: [bug report] out of bounds read parsing vmode commandline option
Hi,
On Wednesday, October 04, 2017 06:42:37 PM Geert Uytterhoeven wrote:
> Hi Dan,
>
> On Wed, Oct 4, 2017 at 2:50 PM, Dan Carpenter
> wrote:
> > This bug predates git but it looks like it might be simple to fix if the
> > right person looked at the code.
> >
> > drivers/video/fbdev/controlfb.c:560 control_setup()
> > error: buffer overflow 'control_mac_modes' 20 <= 21
> >
> > drivers/video/fbdev/controlfb.c
> >549 static void __init control_setup(char *options)
> >550 {
> >551 char *this_opt;
> >552
> >553 if (!options || !*options)
> >554 return;
> >555
> >556 while ((this_opt = strsep(&options, ",")) != NULL) {
> >557 if (!strncmp(this_opt, "vmode:", 6)) {
> >558 int vmode = simple_strtoul(this_opt+6,
> > NULL, 0);
> > ^
> > We get vmode from the command line.
> >
> >559 if (vmode > 0 && vmode <= VMODE_MAX &&
> > ^
> > We check that it's <= 22.
> >
> >560 control_mac_modes[vmode - 1].m[1] >= 0)
> > ^
> > But the problem is that control_mac_modes[] only has 20 elements so the
> > highest valid index is 19. vmode - 1 can be up to 21.
>
> Nice catch!
>
> The bug was introduced in v2.4.5.6, when 2 new modes were added to
> macmodes.h, but control_mac_modes[] wasn't updated:
>
> https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.5.2&id=29f279c764808560eaceb88fef36cbc35c529aad
>
> A simple fix is to check against ARRAY_SIZE(control_mac_modes) instead.
>
> A better fix is to add the missing entries to control_mac_modes[], cfr. the
> (gmail-whitespace-damaged) patch below:
>
> --- a/drivers/video/fbdev/controlfb.h
> +++ b/drivers/video/fbdev/controlfb.h
> @@ -141,5 +141,7 @@ static struct max_cmodes control_mac_modes[] = {
> {{ 1, 2}}, /* 1152x870, 75Hz */
> {{ 0, 1}}, /* 1280x960, 75Hz */
> {{ 0, 1}}, /* 1280x1024, 75Hz */
> + {{ 1, 2}}, /* 1152x768, 60Hz */
> + {{ 0, 1}}, /* 1600x1024, 60Hz */
> };
>
> (this array lists the maximum color mode (8, 16, or 32 bpp) for each
> video mode given RAM restrictions (2 or 4 MiB)).
>
> The 1152x768 mode is probably OK. Given the 1600x1024 mode has a lower
> dotclock (112 MHz) than the supported 1280x960 mode, it's probably OK, too.
Looks fine to me, could you please submit it as a normal patch?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Re: [PATCH] video: fbdev: annotate fb_fix_screeninfo with const and __initconst
On Sunday, August 20, 2017 11:14:51 PM Bhumika Goyal wrote: > Make these const as they are only used during a copy operation. > Some structures are used as a copy operation inside __init functions, so > make them const and replace __initdata with __initconst to avoid section > conflict error. > > Signed-off-by: Bhumika Goyal Patch queued for 4.14, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
Re: [PATCH] video: console: Remove reference to CONFIG_8xx
On Friday, April 14, 2017 03:50:04 PM Christophe Leroy wrote: > CONFIG_8xx is deprecated and should soon be removed in favor > of CONFIG_PPC_8xx. > > Signed-off-by: Christophe Leroy Patch queued for 4.12, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
Re: [PATCH v3] Fix loading of module radeonfb on PowerMac
Hi,
On Wednesday, February 01, 2017 07:55:25 AM Mathieu Malaterre wrote:
> Any chance this patch could be considered for inclusion this time ?
>
> Thanks
>
> On Wed, Nov 23, 2016 at 8:26 AM, Mathieu Malaterre wrote:
> > When the linux kernel is build with (typical kernel ship with Debian
> > installer):
> >
> > CONFIG_FB_OF=y
> > CONFIG_VT_HW_CONSOLE_BINDING=y
> > CONFIG_FB_RADEON=m
> >
> > The offb driver takes precedence over module radeonfb. It is then
> > impossible to load the module, error reported is:
> >
> > [ 96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
> > [ 96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem
> > 0x9800-0x9fff pref]
> > [ 96.551531] radeonfb (:00:10.0): cannot request region 0.
> > [ 96.551545] radeonfb: probe of :00:10.0 failed with error -16
> >
> > This patch reproduce the behavior of the module radeon, so as to make it
> > possible to load radeonfb when offb is first loaded.
> >
> > The problem is that offb call pci_request_region first, and then radeonfb
> > tries to do it, and since one is trying to take over from the other, it
> > can't
> > do that because the area is already reserved.
> >
> > It should be noticed that `offb_destroy` is never called which explain the
> > need to skip error detection on the radeonfb side.
> >
> > Signed-off-by: Mathieu Malaterre
> > Link: https://bugs.debian.org/826629#57
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
> > Suggested-by: Lennart Sorensen
> > ---
> >
> > v2: Remove compilation warning
> >
> > v3: Hide error messages on PPC
> >
> > drivers/video/fbdev/aty/radeon_base.c | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/video/fbdev/aty/radeon_base.c
> > b/drivers/video/fbdev/aty/radeon_base.c
> > index 218339a..837c86a 100644
> > --- a/drivers/video/fbdev/aty/radeon_base.c
> > +++ b/drivers/video/fbdev/aty/radeon_base.c
> > @@ -2259,6 +2259,22 @@ static struct bin_attribute edid2_attr = {
> > .read = radeon_show_edid2,
> > };
> >
> > +static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
> > +{
> > + struct apertures_struct *ap;
> > +
> > + ap = alloc_apertures(1);
> > + if (!ap)
> > + return -ENOMEM;
> > +
> > + ap->ranges[0].base = pci_resource_start(pdev, 0);
> > + ap->ranges[0].size = pci_resource_len(pdev, 0);
> > +
> > + remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
> > + kfree(ap);
> > +
> > + return 0;
> > +}
> >
> > static int radeonfb_pci_register(struct pci_dev *pdev,
> > const struct pci_device_id *ent)
> > @@ -2314,20 +2330,29 @@ static int radeonfb_pci_register(struct pci_dev
> > *pdev,
> > rinfo->fb_base_phys = pci_resource_start (pdev, 0);
> > rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
> >
> > + ret = radeon_kick_out_firmware_fb(pdev);
> > + if (ret)
> > + return ret;
> > +
> > /* request the mem regions */
> > ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
> > + /* this is not an error on PowerMac where offb already requested mem
> > regions */
> > +#ifndef CONFIG_PPC
This doesn't look correct:
- PPC is not only PowerMac and offb supports more cards
than radeon (while radeonfb can be used for secondary
graphics card)
- offb can be disabled
(i.e. in CONFIG_FB_OF=n && CONFIG_FB_RADEON=y case error
checking will be missing now)
The last put_fb_info() on fb_info should call ->fb_destroy
(offb_destroy in our case) and remove_conflicting_framebuffers()
is calling put_fb_info() so there is some extra reference on
fb_info somewhere preventing it from going away.
Please look into fixing this.
> > if (ret < 0) {
> > printk( KERN_ERR "radeonfb (%s): cannot request region
> > 0.\n",
> > pci_name(rinfo->pdev));
> > goto err_release_fb;
> > }
> > +#endif
> >
> > ret = pci_request_region(pdev, 2, "radeonfb mmio");
> > +#ifndef CONFIG_PPC
> > if (ret < 0) {
> > printk( KERN_ERR "radeonfb (%s): cannot request region
> > 2.\n",
> > pci_name(rinfo->pdev));
> > goto err_release_pci0;
> > }
> > +#endif
> >
> > /* map the regions */
> > rinfo->mmio_base = ioremap(rinfo->mmio_base_phys, RADEON_REGSIZE);
> > @@ -2511,10 +2536,12 @@ static int radeonfb_pci_register(struct pci_dev
> > *pdev,
> > iounmap(rinfo->mmio_base);
> > err_release_pci2:
> > pci_release_region(pdev, 2);
> > +#ifndef CONFIG_PPC
> > err_release_pci0:
> > pci_release_region(pdev, 0);
> > err_release_fb:
> > framebuffer_release(info);
> > +#endif
> > err_disable:
> > err_out:
> > return ret;
> > --
> > 2.1.4
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Re: [RFT PATCH] powerpc: convert amigaone_defconfig to use libata PATA drivers
Hi, On Wednesday, February 03, 2016 10:17:51 PM Gerhard Pircher wrote: > Am 2016-02-03 um 16:50 schrieb Bartlomiej Zolnierkiewicz: > > IDE subsystem has been deprecated since 2009 and the majority > > (if not all) of Linux distributions have switched to use > > libata for ATA support exclusively. However there are still > > some users (mostly old or/and embedded non-x86 systems) that > > have not converted from using IDE subsystem to libata PATA > > drivers. This doesn't seem to be good thing in the long-term > > for Linux as while there is less and less PATA systems left > > in use: > > > > * testing efforts are divided between two subsystems > > > > * having duplicate drivers for same hardware confuses users > > > > This patch converts amigaone_defconfig to use libata PATA > > drivers. > > > > Signed-off-by: Bartlomiej Zolnierkiewicz > > --- > > Build tested only. > > If you have affected hardware please test. Thank you. > > > > arch/powerpc/configs/amigaone_defconfig | 10 -- > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > diff --git a/arch/powerpc/configs/amigaone_defconfig > > b/arch/powerpc/configs/amigaone_defconfig > > index 84f1b41..55a4929 100644 > > --- a/arch/powerpc/configs/amigaone_defconfig > > +++ b/arch/powerpc/configs/amigaone_defconfig > > @@ -46,12 +46,6 @@ CONFIG_PARPORT_PC_FIFO=y > > CONFIG_BLK_DEV_FD=y > > CONFIG_BLK_DEV_LOOP=y > > CONFIG_BLK_DEV_RAM=y > > -CONFIG_IDE=y > > -CONFIG_BLK_DEV_IDECD=y > > -# CONFIG_IDEPCI_PCIBUS_ORDER is not set > > -CONFIG_BLK_DEV_GENERIC=y > > -CONFIG_BLK_DEV_SIIMAGE=y > > -CONFIG_BLK_DEV_VIA82CXXX=y > > CONFIG_SCSI=y > > CONFIG_BLK_DEV_SD=y > > CONFIG_CHR_DEV_ST=y > > @@ -62,6 +56,10 @@ CONFIG_SCSI_CONSTANTS=y > > CONFIG_SCSI_SYM53C8XX_2=y > > CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 > > # CONFIG_SCSI_SYM53C8XX_MMIO is not set > > +CONFIG_ATA=y > > +CONFIG_PATA_SIL680=y > > +CONFIG_PATA_VIA=y > > +CONFIG_ATA_GENERIC=y > > CONFIG_NETDEVICES=y > > CONFIG_VORTEX=y > > CONFIG_8139CP=y > > > Thanks for cleaning up the defconfig file! > > libata drivers work fine on the amigaone platform (tested on all three > first-gen AmigaOne machines). BTW: could it be that CONFIG_ATA_SFF=y > and CONFIG_ATA_BMDMA=y are missing in the patch? Thank you for testing! When it comes to CONFIG_ATA_SFF and CONFIG_ATA_BMDMA there is no need to explicitly enable them because once CONFIG_ATA is enabled they both are also enabled by default (they both have 'default y' in Kconfig). [ defconfig changes in the patch were obtained by: - doing 'make amigaone_defconfig' - changing IDE options to libata ones using 'make menuconfig' - doing 'make savedefconfig' - doing 'diff -u arch/powerpc/configs/amigaone_defconfig defconfig' so there should be no missing options etc. ] Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert pseries_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts pseries_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/pseries_defconfig | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig index 36871a4..9b1bc2a 100644 --- a/arch/powerpc/configs/pseries_defconfig +++ b/arch/powerpc/configs/pseries_defconfig @@ -89,10 +89,6 @@ CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=65536 CONFIG_VIRTIO_BLK=m -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y @@ -119,7 +115,8 @@ CONFIG_SCSI_DH_RDAC=m CONFIG_SCSI_DH_ALUA=m CONFIG_ATA=y CONFIG_SATA_AHCI=y -# CONFIG_ATA_SFF is not set +CONFIG_PATA_AMD=y +CONFIG_ATA_GENERIC=y CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert storcenter_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts storcenter_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/storcenter_defconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/configs/storcenter_defconfig b/arch/powerpc/configs/storcenter_defconfig index b5db7df..adf7d26 100644 --- a/arch/powerpc/configs/storcenter_defconfig +++ b/arch/powerpc/configs/storcenter_defconfig @@ -37,12 +37,11 @@ CONFIG_NFTL_RW=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_AMDSTD=y CONFIG_MTD_PHYSMAP=y -CONFIG_IDE=y -CONFIG_BLK_DEV_VIA82CXXX=y -CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_SPI_ATTRS=y +CONFIG_ATA=y +CONFIG_PATA_VIA=y CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: disable IDE subsystem in pq2fads_defconfig
This patch disables deprecated IDE subsystem in pq2fads_defconfig (no IDE host drivers are selected in this config so there is no valid reason to enable IDE subsystem itself). Signed-off-by: Bartlomiej Zolnierkiewicz --- arch/powerpc/configs/pq2fads_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/configs/pq2fads_defconfig b/arch/powerpc/configs/pq2fads_defconfig index 3e336ee..1e77d45 100644 --- a/arch/powerpc/configs/pq2fads_defconfig +++ b/arch/powerpc/configs/pq2fads_defconfig @@ -40,7 +40,6 @@ CONFIG_MTD_CFI_I4=y CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_PHYSMAP_OF=y CONFIG_BLK_DEV_LOOP=y -CONFIG_IDE=y CONFIG_NETDEVICES=y CONFIG_TUN=y CONFIG_FS_ENET=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert ppc6xx_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts ppc6xx_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/ppc6xx_defconfig | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig index e5d2c3d..0d93067 100644 --- a/arch/powerpc/configs/ppc6xx_defconfig +++ b/arch/powerpc/configs/ppc6xx_defconfig @@ -378,13 +378,6 @@ CONFIG_EEPROM_AT24=m CONFIG_EEPROM_LEGACY=m CONFIG_EEPROM_MAX6875=m CONFIG_EEPROM_93CX6=m -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=m -CONFIG_IDE_TASK_IOCTL=y -# CONFIG_IDEPCI_PCIBUS_ORDER is not set -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_IDE_PMAC=y -CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y CONFIG_RAID_ATTRS=m CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m @@ -411,13 +404,14 @@ CONFIG_ATA=y CONFIG_SATA_FSL=m CONFIG_PDC_ADMA=m CONFIG_ATA_PIIX=m +CONFIG_PATA_MACIO=y CONFIG_PATA_MPC52xx=m CONFIG_PATA_OPTIDMA=m CONFIG_PATA_SCH=m CONFIG_PATA_VIA=m CONFIG_PATA_PLATFORM=m CONFIG_PATA_OF_PLATFORM=m -CONFIG_ATA_GENERIC=m +CONFIG_ATA_GENERIC=y CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=m -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert ppc64e_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts ppc64e_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/ppc64e_defconfig | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/configs/ppc64e_defconfig b/arch/powerpc/configs/ppc64e_defconfig index ddf9773..ec795e2 100644 --- a/arch/powerpc/configs/ppc64e_defconfig +++ b/arch/powerpc/configs/ppc64e_defconfig @@ -59,10 +59,6 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=65536 -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y @@ -79,6 +75,8 @@ CONFIG_SCSI_DEBUG=m CONFIG_ATA=y CONFIG_SATA_SIL24=y CONFIG_SATA_SVW=y +CONFIG_PATA_AMD=y +CONFIG_ATA_GENERIC=y CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert ppc64_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts ppc64_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/ppc64_defconfig | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index b041fb6..0fcab20 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -83,12 +83,6 @@ CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=65536 CONFIG_VIRTIO_BLK=m -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_AMD74XX=y -CONFIG_BLK_DEV_IDE_PMAC=y -CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y @@ -118,6 +112,9 @@ CONFIG_SATA_AHCI=y CONFIG_SATA_SIL24=y CONFIG_SATA_MV=y CONFIG_SATA_SVW=y +CONFIG_PATA_AMD=y +CONFIG_PATA_MACIO=y +CONFIG_ATA_GENERIC=y CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert pmac32_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts pmac32_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/pmac32_defconfig | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig index ea8705f..c4efc5d 100644 --- a/arch/powerpc/configs/pmac32_defconfig +++ b/arch/powerpc/configs/pmac32_defconfig @@ -118,15 +118,6 @@ CONFIG_CONNECTOR=y CONFIG_MAC_FLOPPY=m CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECS=m -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_PDC202XX_NEW=y -CONFIG_BLK_DEV_SL82C105=y -CONFIG_BLK_DEV_IDE_PMAC=y -CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y -CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y @@ -141,6 +132,12 @@ CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_MESH=y CONFIG_SCSI_MAC53C94=y +CONFIG_ATA=y +CONFIG_PATA_MACIO=y +CONFIG_PATA_PDC2027X=y +CONFIG_PATA_WINBOND=y +CONFIG_PATA_PCMCIA=m +CONFIG_ATA_GENERIC=y CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: disable IDE subsystem in pasemi_defconfig
This patch disables deprecated IDE subsystem in pasemi_defconfig (no IDE host drivers are selected in this config so there is no valid reason to enable IDE subsystem itself). Cc: Olof Johansson Signed-off-by: Bartlomiej Zolnierkiewicz --- arch/powerpc/configs/pasemi_defconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/powerpc/configs/pasemi_defconfig b/arch/powerpc/configs/pasemi_defconfig index 8f94782..d7654e4 100644 --- a/arch/powerpc/configs/pasemi_defconfig +++ b/arch/powerpc/configs/pasemi_defconfig @@ -58,9 +58,6 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_EEPROM_LEGACY=y -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_IDE_TASK_IOCTL=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_CHR_DEV_OSST=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert maple_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts maple_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/maple_defconfig | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/configs/maple_defconfig b/arch/powerpc/configs/maple_defconfig index ac9666f..75b5a4e 100644 --- a/arch/powerpc/configs/maple_defconfig +++ b/arch/powerpc/configs/maple_defconfig @@ -40,16 +40,15 @@ CONFIG_IP_PNP_DHCP=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=8192 -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_IDE_TASK_IOCTL=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_AMD74XX=y # CONFIG_SCSI_PROC_FS is not set CONFIG_BLK_DEV_SD=y +CONFIG_BLK_DEV_SR=y +CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_SCSI_IPR=y CONFIG_ATA=y +CONFIG_PATA_AMD=y +CONFIG_ATA_GENERIC=y CONFIG_NETDEVICES=y CONFIG_AMD8111_ETH=y CONFIG_TIGON3=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/86xx: disable IDE subsystem in mpc8610_hpcd_defconfig
This patch disables deprecated IDE subsystem in mpc8610_hpcd_defconfig (no IDE host drivers are selected in this config so there is no valid reason to enable IDE subsystem itself). Signed-off-by: Bartlomiej Zolnierkiewicz --- arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig b/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig index e32207d..1ef927f 100644 --- a/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig +++ b/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig @@ -49,7 +49,6 @@ CONFIG_MTD_NAND_FSL_ELBC=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=131072 -CONFIG_IDE=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_SG=y CONFIG_ATA=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert g5_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts g5_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/g5_defconfig | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig index 1d9ad85..b7688c1 100644 --- a/arch/powerpc/configs/g5_defconfig +++ b/arch/powerpc/configs/g5_defconfig @@ -60,10 +60,6 @@ CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=65536 CONFIG_CDROM_PKTCDVD=m -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_IDE_PMAC=y -CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y @@ -73,6 +69,7 @@ CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_SPI_ATTRS=y CONFIG_ATA=y CONFIG_SATA_SVW=y +CONFIG_PATA_MACIO=y CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert chrp32_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts chrp32_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/chrp32_defconfig | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/configs/chrp32_defconfig b/arch/powerpc/configs/chrp32_defconfig index 253a9f2..9eb8080 100644 --- a/arch/powerpc/configs/chrp32_defconfig +++ b/arch/powerpc/configs/chrp32_defconfig @@ -42,12 +42,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_SL82C105=y -CONFIG_BLK_DEV_VIA82CXXX=y -CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y @@ -56,6 +50,10 @@ CONFIG_CHR_DEV_SG=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 +CONFIG_ATA=y +CONFIG_PATA_VIA=y +CONFIG_PATA_WINBOND=y +CONFIG_ATA_GENERIC=y CONFIG_NETDEVICES=y CONFIG_PCNET32=y CONFIG_NET_TULIP=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert cell_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts cell_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/cell_defconfig | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/configs/cell_defconfig b/arch/powerpc/configs/cell_defconfig index db328e6..679edaa 100644 --- a/arch/powerpc/configs/cell_defconfig +++ b/arch/powerpc/configs/cell_defconfig @@ -108,16 +108,15 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=131072 -CONFIG_IDE=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_AEC62XX=y -CONFIG_BLK_DEV_SIIMAGE=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=m CONFIG_CHR_DEV_SG=y CONFIG_ATA=y CONFIG_SATA_PROMISE=y +CONFIG_PATA_ARTOP=y CONFIG_PATA_PDC2027X=m +CONFIG_PATA_SIL680=y +CONFIG_ATA_GENERIC=y CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc: convert amigaone_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts amigaone_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/amigaone_defconfig | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/configs/amigaone_defconfig b/arch/powerpc/configs/amigaone_defconfig index 84f1b41..55a4929 100644 --- a/arch/powerpc/configs/amigaone_defconfig +++ b/arch/powerpc/configs/amigaone_defconfig @@ -46,12 +46,6 @@ CONFIG_PARPORT_PC_FIFO=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -# CONFIG_IDEPCI_PCIBUS_ORDER is not set -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_SIIMAGE=y -CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y @@ -62,6 +56,10 @@ CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 # CONFIG_SCSI_SYM53C8XX_MMIO is not set +CONFIG_ATA=y +CONFIG_PATA_SIL680=y +CONFIG_PATA_VIA=y +CONFIG_ATA_GENERIC=y CONFIG_NETDEVICES=y CONFIG_VORTEX=y CONFIG_8139CP=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc/86xx: convert gef_sbc310_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts gef_sbc310_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/86xx/gef_sbc310_defconfig | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/powerpc/configs/86xx/gef_sbc310_defconfig b/arch/powerpc/configs/86xx/gef_sbc310_defconfig index cadc366..2efd871 100644 --- a/arch/powerpc/configs/86xx/gef_sbc310_defconfig +++ b/arch/powerpc/configs/86xx/gef_sbc310_defconfig @@ -76,14 +76,12 @@ CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=131072 CONFIG_DS1682=y -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECS=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y CONFIG_ATA=y CONFIG_SATA_SIL24=y -# CONFIG_ATA_SFF is not set +CONFIG_PATA_PCMCIA=y CONFIG_NETDEVICES=y CONFIG_BONDING=m CONFIG_DUMMY=m -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc/86xx: convert gef_ppc9a_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts gef_ppc9a_defconfig to use libata PATA drivers. Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig index 9792a2c..ca06080 100644 --- a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig +++ b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig @@ -76,13 +76,12 @@ CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=131072 CONFIG_DS1682=y -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECS=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y CONFIG_ATA=y CONFIG_SATA_SIL=y +CONFIG_PATA_PCMCIA=y CONFIG_NETDEVICES=y CONFIG_BONDING=m CONFIG_DUMMY=m -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc/85xx: convert tqm8560_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts tqm8560_defconfig to use libata PATA drivers. Cc: Scott Wood Cc: Kumar Gala Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/85xx/tqm8560_defconfig | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/configs/85xx/tqm8560_defconfig b/arch/powerpc/configs/85xx/tqm8560_defconfig index 633d5b7..daa6842 100644 --- a/arch/powerpc/configs/85xx/tqm8560_defconfig +++ b/arch/powerpc/configs/85xx/tqm8560_defconfig @@ -30,9 +30,10 @@ CONFIG_MTD_CFI_AMDSTD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=32768 -CONFIG_IDE=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_VIA82CXXX=y +CONFIG_BLK_DEV_SD=y +CONFIG_ATA=y +CONFIG_PATA_VIA=y +CONFIG_ATA_GENERIC=y CONFIG_NETDEVICES=y CONFIG_GIANFAR=y CONFIG_E100=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc/85xx: convert tqm8555_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts tqm8555_defconfig to use libata PATA drivers. Cc: Scott Wood Cc: Kumar Gala Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/85xx/tqm8555_defconfig | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/configs/85xx/tqm8555_defconfig b/arch/powerpc/configs/85xx/tqm8555_defconfig index 02a931d..3d9c1c0d 100644 --- a/arch/powerpc/configs/85xx/tqm8555_defconfig +++ b/arch/powerpc/configs/85xx/tqm8555_defconfig @@ -30,9 +30,10 @@ CONFIG_MTD_CFI_AMDSTD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=32768 -CONFIG_IDE=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_VIA82CXXX=y +CONFIG_BLK_DEV_SD=y +CONFIG_ATA=y +CONFIG_PATA_VIA=y +CONFIG_ATA_GENERIC=y CONFIG_NETDEVICES=y CONFIG_GIANFAR=y CONFIG_E100=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc/85xx: convert tqm8541_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts tqm8541_defconfig to use libata PATA drivers. Cc: Scott Wood Cc: Kumar Gala Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/85xx/tqm8541_defconfig | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/configs/85xx/tqm8541_defconfig b/arch/powerpc/configs/85xx/tqm8541_defconfig index bb402b3..c9b0028 100644 --- a/arch/powerpc/configs/85xx/tqm8541_defconfig +++ b/arch/powerpc/configs/85xx/tqm8541_defconfig @@ -30,9 +30,10 @@ CONFIG_MTD_CFI_AMDSTD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=32768 -CONFIG_IDE=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_VIA82CXXX=y +CONFIG_BLK_DEV_SD=y +CONFIG_ATA=y +CONFIG_PATA_VIA=y +CONFIG_ATA_GENERIC=y CONFIG_NETDEVICES=y CONFIG_GIANFAR=y CONFIG_E100=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc/85xx: convert tqm8540_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts tqm8540_defconfig to use libata PATA drivers. Cc: Scott Wood Cc: Kumar Gala Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/85xx/tqm8540_defconfig | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/configs/85xx/tqm8540_defconfig b/arch/powerpc/configs/85xx/tqm8540_defconfig index 4daaf29..358d068 100644 --- a/arch/powerpc/configs/85xx/tqm8540_defconfig +++ b/arch/powerpc/configs/85xx/tqm8540_defconfig @@ -30,9 +30,10 @@ CONFIG_MTD_CFI_AMDSTD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=32768 -CONFIG_IDE=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_VIA82CXXX=y +CONFIG_BLK_DEV_SD=y +CONFIG_ATA=y +CONFIG_PATA_VIA=y +CONFIG_ATA_GENERIC=y CONFIG_NETDEVICES=y CONFIG_GIANFAR=y CONFIG_E100=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: disable IDE subsystem in stx_gp3_defconfig
This patch disables deprecated IDE subsystem in stx_gp3_defconfig (no IDE host drivers are selected in this config so there is no valid reason to enable IDE subsystem itself). Cc: Scott Wood Cc: Kumar Gala Signed-off-by: Bartlomiej Zolnierkiewicz --- arch/powerpc/configs/85xx/stx_gp3_defconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/configs/85xx/stx_gp3_defconfig b/arch/powerpc/configs/85xx/stx_gp3_defconfig index f66d16b..b451905 100644 --- a/arch/powerpc/configs/85xx/stx_gp3_defconfig +++ b/arch/powerpc/configs/85xx/stx_gp3_defconfig @@ -31,8 +31,6 @@ CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=32768 -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=m CONFIG_SCSI=m CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFT PATCH] powerpc/85xx: convert mpc85xx_cds_defconfig to use libata PATA drivers
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts mpc85xx_cds_defconfig to use libata PATA drivers. Cc: Scott Wood Cc: Kumar Gala Signed-off-by: Bartlomiej Zolnierkiewicz --- Build tested only. If you have affected hardware please test. Thank you. arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/configs/85xx/mpc85xx_cds_defconfig b/arch/powerpc/configs/85xx/mpc85xx_cds_defconfig index ecb0c3b..acc5342 100644 --- a/arch/powerpc/configs/85xx/mpc85xx_cds_defconfig +++ b/arch/powerpc/configs/85xx/mpc85xx_cds_defconfig @@ -30,9 +30,9 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=32768 -CONFIG_IDE=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_VIA82CXXX=y +CONFIG_ATA=y +CONFIG_PATA_VIA=y +CONFIG_ATA_GENERIC=y CONFIG_NETDEVICES=y CONFIG_GIANFAR=y CONFIG_E1000=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: disable IDE subsystem in ksi8560_defconfig
This patch disables deprecated IDE subsystem in ksi8560_defconfig (no IDE host drivers are selected in this config so there is no valid reason to enable IDE subsystem itself). Cc: Scott Wood Cc: Kumar Gala Signed-off-by: Bartlomiej Zolnierkiewicz --- arch/powerpc/configs/85xx/ksi8560_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/configs/85xx/ksi8560_defconfig b/arch/powerpc/configs/85xx/ksi8560_defconfig index 3be85c5..6f753a7 100644 --- a/arch/powerpc/configs/85xx/ksi8560_defconfig +++ b/arch/powerpc/configs/85xx/ksi8560_defconfig @@ -34,7 +34,6 @@ CONFIG_MTD_PHYSMAP_OF=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=32768 -CONFIG_IDE=y CONFIG_NETDEVICES=y CONFIG_FS_ENET=y # CONFIG_FS_ENET_HAS_SCC is not set -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/83xx: disable IDE subsystem in mpc834x_itx_defconfig
This patch disables deprecated IDE subsystem in mpc834x_itx_defconfig (no IDE host drivers are selected in this config so there is no valid reason to enable IDE subsystem itself). Cc: Scott Wood Cc: Kumar Gala Signed-off-by: Bartlomiej Zolnierkiewicz --- arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/configs/83xx/mpc834x_itx_defconfig b/arch/powerpc/configs/83xx/mpc834x_itx_defconfig index 2a5fdcb..87fc15b 100644 --- a/arch/powerpc/configs/83xx/mpc834x_itx_defconfig +++ b/arch/powerpc/configs/83xx/mpc834x_itx_defconfig @@ -35,7 +35,6 @@ CONFIG_MTD_PHYSMAP=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=32768 -CONFIG_IDE=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_SG=y CONFIG_SCSI_SPI_ATTRS=y -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/3] Remove celleb-only SCC PATA drivers
Hi, On Tuesday, April 14, 2015 03:28:45 PM Daniel Axtens wrote: > The SCC PATA interface is only used by celleb. > celleb has been dropped [1], so drop the drivers. > > [1] http://patchwork.ozlabs.org/patch/451730/ > > CC: Bartlomiej Zolnierkiewicz > CC: Tejun Heo > CC: "David S. Miller" > CC: linux-...@vger.kernel.org > CC: Valentin Rothberg > CC: m...@ellerman.id.au > CC: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Daniel Axtens > > --- > v2: get name of ozlab*s*.org right. Sorry all. > --- > drivers/ata/Kconfig|9 - > drivers/ata/Makefile |1 - > drivers/ata/pata_scc.c | 1110 > > drivers/ide/Kconfig|9 - > drivers/ide/Makefile |1 - > drivers/ide/scc_pata.c | 887 -- > 6 files changed, 2017 deletions(-) > delete mode 100644 drivers/ata/pata_scc.c > delete mode 100644 drivers/ide/scc_pata.c For PATA part: Acked-by: Bartlomiej Zolnierkiewicz If Tejun & Dave are OK with it this patch can go through libata tree. Otherwise you will need to split it on separate libata/IDE patches. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 9/9] cpuidle: remove state_count field from struct cpuidle_device
dev->state_count is now always equal to drv->state_count so
it can be removed.
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
drivers/cpuidle/cpuidle.c | 3 ---
drivers/cpuidle/sysfs.c | 5 +++--
include/linux/cpuidle.h | 1 -
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index a55e68f..e3d2052 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -252,9 +252,6 @@ int cpuidle_enable_device(struct cpuidle_device *dev)
if (!dev->registered)
return -EINVAL;
- if (!dev->state_count)
- dev->state_count = drv->state_count;
-
ret = cpuidle_add_device_sysfs(dev);
if (ret)
return ret;
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index e918b6d..dcaae4c 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -398,7 +398,7 @@ static int cpuidle_add_state_sysfs(struct cpuidle_device
*device)
struct cpuidle_driver *drv = cpuidle_get_cpu_driver(device);
/* state statistics */
- for (i = 0; i < device->state_count; i++) {
+ for (i = 0; i < drv->state_count; i++) {
kobj = kzalloc(sizeof(struct cpuidle_state_kobj), GFP_KERNEL);
if (!kobj)
goto error_state;
@@ -430,9 +430,10 @@ error_state:
*/
static void cpuidle_remove_state_sysfs(struct cpuidle_device *device)
{
+ struct cpuidle_driver *drv = cpuidle_get_cpu_driver(device);
int i;
- for (i = 0; i < device->state_count; i++)
+ for (i = 0; i < drv->state_count; i++)
cpuidle_free_state_kobj(device, i);
}
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 50fcbb0..d133817 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -69,7 +69,6 @@ struct cpuidle_device {
unsigned intcpu;
int last_residency;
- int state_count;
struct cpuidle_state_usage states_usage[CPUIDLE_STATE_MAX];
struct cpuidle_state_kobj *kobjs[CPUIDLE_STATE_MAX];
struct cpuidle_driver_kobj *kobj_driver;
--
1.8.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 8/9] intel_idle: use the common cpuidle_[un]register() routines
It is now possible to use the common cpuidle_[un]register() routines
(instead of open-coding them) so do it.
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
Cc: Len Brown
---
drivers/idle/intel_idle.c | 114 --
1 file changed, 29 insertions(+), 85 deletions(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 524d07b..a1a4dbd 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -93,10 +93,8 @@ struct idle_cpu {
};
static const struct idle_cpu *icpu;
-static struct cpuidle_device __percpu *intel_idle_cpuidle_devices;
static int intel_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index);
-static int intel_idle_cpu_init(int cpu);
static struct cpuidle_state *cpuidle_state_table;
@@ -400,11 +398,27 @@ static void __setup_broadcast_timer(void *arg)
clockevents_notify(reason, &cpu);
}
+static void auto_demotion_disable(void *dummy)
+{
+ unsigned long long msr_bits;
+
+ rdmsrl(MSR_NHM_SNB_PKG_CST_CFG_CTL, msr_bits);
+ msr_bits &= ~(icpu->auto_demotion_disable_flags);
+ wrmsrl(MSR_NHM_SNB_PKG_CST_CFG_CTL, msr_bits);
+}
+static void c1e_promotion_disable(void *dummy)
+{
+ unsigned long long msr_bits;
+
+ rdmsrl(MSR_IA32_POWER_CTL, msr_bits);
+ msr_bits &= ~0x2;
+ wrmsrl(MSR_IA32_POWER_CTL, msr_bits);
+}
+
static int cpu_hotplug_notify(struct notifier_block *n,
unsigned long action, void *hcpu)
{
int hotcpu = (unsigned long)hcpu;
- struct cpuidle_device *dev;
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
@@ -416,11 +430,15 @@ static int cpu_hotplug_notify(struct notifier_block *n,
/*
* Some systems can hotplug a cpu at runtime after
* the kernel has booted, we have to initialize the
-* driver in this case
+* hardware in this case.
*/
- dev = per_cpu_ptr(intel_idle_cpuidle_devices, hotcpu);
- if (!dev->registered)
- intel_idle_cpu_init(hotcpu);
+ if (icpu->auto_demotion_disable_flags)
+ smp_call_function_single(hotcpu, auto_demotion_disable,
+ NULL, 1);
+
+ if (icpu->disable_promotion_to_c1e)
+ smp_call_function_single(hotcpu, c1e_promotion_disable,
+ NULL, 1);
break;
}
@@ -431,23 +449,6 @@ static struct notifier_block cpu_hotplug_notifier = {
.notifier_call = cpu_hotplug_notify,
};
-static void auto_demotion_disable(void *dummy)
-{
- unsigned long long msr_bits;
-
- rdmsrl(MSR_NHM_SNB_PKG_CST_CFG_CTL, msr_bits);
- msr_bits &= ~(icpu->auto_demotion_disable_flags);
- wrmsrl(MSR_NHM_SNB_PKG_CST_CFG_CTL, msr_bits);
-}
-static void c1e_promotion_disable(void *dummy)
-{
- unsigned long long msr_bits;
-
- rdmsrl(MSR_IA32_POWER_CTL, msr_bits);
- msr_bits &= ~0x2;
- wrmsrl(MSR_IA32_POWER_CTL, msr_bits);
-}
-
static const struct idle_cpu idle_cpu_nehalem = {
.state_table = nehalem_cstates,
.auto_demotion_disable_flags = NHM_C1_AUTO_DEMOTE | NHM_C3_AUTO_DEMOTE,
@@ -560,23 +561,6 @@ static int __init intel_idle_probe(void)
}
/*
- * intel_idle_cpuidle_devices_uninit()
- * unregister, free cpuidle_devices
- */
-static void intel_idle_cpuidle_devices_uninit(void)
-{
- int i;
- struct cpuidle_device *dev;
-
- for_each_online_cpu(i) {
- dev = per_cpu_ptr(intel_idle_cpuidle_devices, i);
- cpuidle_unregister_device(dev);
- }
-
- free_percpu(intel_idle_cpuidle_devices);
- return;
-}
-/*
* intel_idle_cpuidle_driver_init()
* allocate, initialize cpuidle_states
*/
@@ -632,37 +616,9 @@ static int __init intel_idle_cpuidle_driver_init(void)
}
-/*
- * intel_idle_cpu_init()
- * allocate, initialize, register cpuidle_devices
- * @cpu: cpu/core to initialize
- */
-static int intel_idle_cpu_init(int cpu)
-{
- struct cpuidle_device *dev;
-
- dev = per_cpu_ptr(intel_idle_cpuidle_devices, cpu);
-
- dev->cpu = cpu;
-
- if (cpuidle_register_device(dev)) {
- pr_debug(PREFIX "cpuidle_register_device %d failed!\n", cpu);
- intel_idle_cpuidle_devices_uninit();
- return -EIO;
- }
-
- if (icpu->auto_demotion_disable_flags)
- smp_call_function_single(cpu, auto_demotion_disable, NULL, 1);
-
- if (icpu->disable_promotion_to_c1e)
- smp_call_function_single(cpu, c1e_promotion_disable, NULL, 1);
-
- return 0;
-}
-
static int __init intel_idle_init(void)
{
- int retval, i;
+ int retval;
[PATCH v2 7/9] intel_idle: remove superfluous dev->state_count initialization
intel_idle driver sets dev->state_count to drv->state_count so
the default dev->state_count initialization in cpuidle_enable_device()
(called from cpuidle_register_device()) can be used instead.
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
Cc: Len Brown
---
drivers/idle/intel_idle.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 38da3fb..524d07b 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -639,39 +639,10 @@ static int __init intel_idle_cpuidle_driver_init(void)
*/
static int intel_idle_cpu_init(int cpu)
{
- int cstate;
struct cpuidle_device *dev;
dev = per_cpu_ptr(intel_idle_cpuidle_devices, cpu);
- dev->state_count = 1;
-
- for (cstate = 0; cstate < CPUIDLE_STATE_MAX; ++cstate) {
- int num_substates, mwait_hint, mwait_cstate, mwait_substate;
-
- if (cpuidle_state_table[cstate].enter == NULL)
- break;
-
- if (cstate + 1 > max_cstate) {
- printk(PREFIX "max_cstate %d reached\n", max_cstate);
- break;
- }
-
- mwait_hint = flg2MWAIT(cpuidle_state_table[cstate].flags);
- mwait_cstate = MWAIT_HINT2CSTATE(mwait_hint);
- mwait_substate = MWAIT_HINT2SUBSTATE(mwait_hint);
-
- /* does the state exist in CPUID.MWAIT? */
- num_substates = (mwait_substates >> ((mwait_cstate + 1) * 4))
- & MWAIT_SUBSTATE_MASK;
-
- /* if sub-state in table is not enumerated by CPUID */
- if ((mwait_substate + 1) > num_substates)
- continue;
-
- dev->state_count += 1;
- }
-
dev->cpu = cpu;
if (cpuidle_register_device(dev)) {
--
1.8.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 5/9] ACPI / cpuidle: remove dev->state_count setting
dev->state_count is now always equal to drv->state_count and drv->state_count no longer can change during driver's lifetime so the default dev->state_count initialization in cpuidle_enable_device() (called from cpuidle_register_device()) can be used instead. Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Kyungmin Park Cc: Len Brown --- drivers/acpi/processor_idle.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index c080c99..da8ce91 100644 --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@ -951,8 +951,6 @@ static int acpi_processor_setup_cpuidle_cx(struct acpi_processor *pr, break; } - dev->state_count = count; - if (!count) return -EINVAL; -- 1.8.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 6/9] intel_idle: do C1E promotion disable quirk for hotplugged CPUs
If the system is booted with some CPUs offline C1E promotion disable quirk won't be applied because on_each_cpu() in intel_idle_cpuidle_driver_init() operates only on online CPUs. Fix it by adding the C1E promotion disable handling to intel_idle_cpu_init() (which is also called during CPU_ONLINE operation). Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Kyungmin Park Cc: Len Brown --- drivers/idle/intel_idle.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index 92d1206..38da3fb 100644 --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@ -683,6 +683,9 @@ static int intel_idle_cpu_init(int cpu) if (icpu->auto_demotion_disable_flags) smp_call_function_single(cpu, auto_demotion_disable, NULL, 1); + if (icpu->disable_promotion_to_c1e) + smp_call_function_single(cpu, c1e_promotion_disable, NULL, 1); + return 0; } -- 1.8.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 4/9] ACPI / cpuidle: fix max idle state handling with hotplug CPU support
acpi_processor_hotplug() calls acpi_processor_setup_cpuidle_cx()
without calling acpi_processor_setup_cpuidle_states() first so it
is possible that dev->state_count becomes different from
drv->state_count (in case of SMP system with unsupported C2/C3
states + enabled CPU hotplug and num_online_cpus() becoming > 1).
The driver code assumes that cpuidle core will handle such cases
but currently this is untrue (dev->state_count is used only for
handling cpuidle state sysfs entries and drv->state_count is used
for all other cases) and will not be fixed in the future as
dev->state_count is planned to be removed.
Fix the issue by checking for the max supported idle state in
C2/C3 state's ->enter handler (acpi_idle_enter_simple() for C2/C3
and acpi_idle_enter_bm() for C3 + bm_check flag set) and setting
the C1 state (instead of higher states) when needed.
Also remove no longer needed max idle state checks from
acpi_processor_setup_cpuidle_[states,cx]().
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
Cc: Len Brown
---
drivers/acpi/processor_idle.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index a0cc5ef4f..c080c99 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -783,6 +783,13 @@ static int acpi_idle_enter_simple(struct cpuidle_device
*dev,
if (unlikely(!pr))
return -EINVAL;
+#ifdef CONFIG_HOTPLUG_CPU
+ if ((cx->type != ACPI_STATE_C1) && (num_online_cpus() > 1) &&
+ !pr->flags.has_cst &&
+ !(acpi_gbl_FADT.flags & ACPI_FADT_C2_MP_SUPPORTED))
+ return acpi_idle_enter_c1(dev, drv, CPUIDLE_DRIVER_STATE_START);
+#endif
+
if (cx->entry_method == ACPI_CSTATE_FFH) {
if (current_set_polling_and_test())
return -EINVAL;
@@ -829,6 +836,13 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev,
if (unlikely(!pr))
return -EINVAL;
+#ifdef CONFIG_HOTPLUG_CPU
+ if ((cx->type != ACPI_STATE_C1) && (num_online_cpus() > 1) &&
+ !pr->flags.has_cst &&
+ !(acpi_gbl_FADT.flags & ACPI_FADT_C2_MP_SUPPORTED))
+ return acpi_idle_enter_c1(dev, drv, CPUIDLE_DRIVER_STATE_START);
+#endif
+
if (!cx->bm_sts_skip && acpi_idle_bm_check()) {
if (drv->safe_state_index >= 0) {
return drv->states[drv->safe_state_index].enter(dev,
@@ -930,12 +944,6 @@ static int acpi_processor_setup_cpuidle_cx(struct
acpi_processor *pr,
if (!cx->valid)
continue;
-#ifdef CONFIG_HOTPLUG_CPU
- if ((cx->type != ACPI_STATE_C1) && (num_online_cpus() > 1) &&
- !pr->flags.has_cst &&
- !(acpi_gbl_FADT.flags & ACPI_FADT_C2_MP_SUPPORTED))
- continue;
-#endif
per_cpu(acpi_cstate[count], dev->cpu) = cx;
count++;
@@ -985,13 +993,6 @@ static int acpi_processor_setup_cpuidle_states(struct
acpi_processor *pr)
if (!cx->valid)
continue;
-#ifdef CONFIG_HOTPLUG_CPU
- if ((cx->type != ACPI_STATE_C1) && (num_online_cpus() > 1) &&
- !pr->flags.has_cst &&
- !(acpi_gbl_FADT.flags & ACPI_FADT_C2_MP_SUPPORTED))
- continue;
-#endif
-
state = &drv->states[count];
snprintf(state->name, CPUIDLE_NAME_LEN, "C%d", i);
strncpy(state->desc, cx->desc, CPUIDLE_DESC_LEN);
--
1.8.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/9] POWERPC: pseries: cpuidle: use the common cpuidle_[un]register() routines
It is now possible to use the common cpuidle_[un]register() routines
(instead of open-coding them) so do it.
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
Acked-by: Daniel Lezcano
Cc: Deepthi Dharwar
---
arch/powerpc/platforms/pseries/processor_idle.c | 57 ++---
1 file changed, 3 insertions(+), 54 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
b/arch/powerpc/platforms/pseries/processor_idle.c
index 8aa8c40..94134a5 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -28,7 +28,6 @@ struct cpuidle_driver pseries_idle_driver = {
#define MAX_IDLE_STATE_COUNT 2
static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
-static struct cpuidle_device __percpu *pseries_cpuidle_devices;
static struct cpuidle_state *cpuidle_state_table;
static inline void idle_loop_prolog(unsigned long *in_purr)
@@ -191,7 +190,7 @@ static int pseries_cpuidle_add_cpu_notifier(struct
notifier_block *n,
{
int hotcpu = (unsigned long)hcpu;
struct cpuidle_device *dev =
- per_cpu_ptr(pseries_cpuidle_devices, hotcpu);
+ per_cpu_ptr(cpuidle_devices, hotcpu);
if (dev && cpuidle_get_driver()) {
switch (action) {
@@ -248,48 +247,6 @@ static int pseries_cpuidle_driver_init(void)
return 0;
}
-/* pseries_idle_devices_uninit(void)
- * unregister cpuidle devices and de-allocate memory
- */
-static void pseries_idle_devices_uninit(void)
-{
- int i;
- struct cpuidle_device *dev;
-
- for_each_possible_cpu(i) {
- dev = per_cpu_ptr(pseries_cpuidle_devices, i);
- cpuidle_unregister_device(dev);
- }
-
- free_percpu(pseries_cpuidle_devices);
- return;
-}
-
-/* pseries_idle_devices_init()
- * allocate, initialize and register cpuidle device
- */
-static int pseries_idle_devices_init(void)
-{
- int i;
- struct cpuidle_device *dev;
-
- pseries_cpuidle_devices = alloc_percpu(struct cpuidle_device);
- if (pseries_cpuidle_devices == NULL)
- return -ENOMEM;
-
- for_each_possible_cpu(i) {
- dev = per_cpu_ptr(pseries_cpuidle_devices, i);
- dev->cpu = i;
- if (cpuidle_register_device(dev)) {
- printk(KERN_DEBUG \
- "cpuidle_register_device %d failed!\n", i);
- return -EIO;
- }
- }
-
- return 0;
-}
-
/*
* pseries_idle_probe()
* Choose state table for shared versus dedicated partition
@@ -325,19 +282,12 @@ static int __init pseries_processor_idle_init(void)
return retval;
pseries_cpuidle_driver_init();
- retval = cpuidle_register_driver(&pseries_idle_driver);
+ retval = cpuidle_register(&pseries_idle_driver, NULL);
if (retval) {
printk(KERN_DEBUG "Registration of pseries driver failed.\n");
return retval;
}
- retval = pseries_idle_devices_init();
- if (retval) {
- pseries_idle_devices_uninit();
- cpuidle_unregister_driver(&pseries_idle_driver);
- return retval;
- }
-
register_cpu_notifier(&setup_hotplug_notifier);
printk(KERN_DEBUG "pseries_idle_driver registered\n");
@@ -348,8 +298,7 @@ static void __exit pseries_processor_idle_exit(void)
{
unregister_cpu_notifier(&setup_hotplug_notifier);
- pseries_idle_devices_uninit();
- cpuidle_unregister_driver(&pseries_idle_driver);
+ cpuidle_unregister(&pseries_idle_driver);
return;
}
--
1.8.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/9] POWERPC: pseries: cpuidle: remove superfluous dev->state_count initialization
pseries cpuidle driver sets dev->state_count to drv->state_count so
the default dev->state_count initialization in cpuidle_enable_device()
(called from cpuidle_register_device()) can be used instead.
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
Acked-by: Daniel Lezcano
Cc: Deepthi Dharwar
---
arch/powerpc/platforms/pseries/processor_idle.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
b/arch/powerpc/platforms/pseries/processor_idle.c
index a166e38..8aa8c40 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -271,7 +271,6 @@ static void pseries_idle_devices_uninit(void)
static int pseries_idle_devices_init(void)
{
int i;
- struct cpuidle_driver *drv = &pseries_idle_driver;
struct cpuidle_device *dev;
pseries_cpuidle_devices = alloc_percpu(struct cpuidle_device);
@@ -280,7 +279,6 @@ static int pseries_idle_devices_init(void)
for_each_possible_cpu(i) {
dev = per_cpu_ptr(pseries_cpuidle_devices, i);
- dev->state_count = drv->state_count;
dev->cpu = i;
if (cpuidle_register_device(dev)) {
printk(KERN_DEBUG \
--
1.8.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/9] cpuidle: rework device state count handling
Hi, Some cpuidle drivers assume that cpuidle core will handle cases where device->state_count is smaller than driver->state_count, unfortunately currently this is untrue (device->state_count is used only for handling cpuidle state sysfs entries and driver->state_count is used for all other cases) and will not be fixed in the future as device->state_count is planned to be removed [1]. This patchset fixes such drivers (ARM EXYNOS cpuidle driver and ACPI cpuidle driver), removes superflous device->state_count initialization from drivers for which device->state_count equals driver->state_count (POWERPC pseries cpuidle driver and intel_idle driver) and finally removes state_count field from struct cpuidle_device. Additionaly (while at it) this patchset fixes C1E promotion disable quirk handling (in intel_idle driver) and converts cpuidle drivers code to use the common cpuidle_[un]register() routines (in POWERPC pseries cpuidle driver and intel_idle driver). [1] http://permalink.gmane.org/gmane.linux.power-management.general/36908 Reference to v1: http://comments.gmane.org/gmane.linux.power-management.general/37390 Changes since v1: - synced patch series with next-20131220 - added ACKs from Daniel Lezcano Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (9): ARM: EXYNOS: cpuidle: fix AFTR mode check POWERPC: pseries: cpuidle: remove superfluous dev->state_count initialization POWERPC: pseries: cpuidle: use the common cpuidle_[un]register() routines ACPI / cpuidle: fix max idle state handling with hotplug CPU support ACPI / cpuidle: remove dev->state_count setting intel_idle: do C1E promotion disable quirk for hotplugged CPUs intel_idle: remove superfluous dev->state_count initialization intel_idle: use the common cpuidle_[un]register() routines cpuidle: remove state_count field from struct cpuidle_device arch/arm/mach-exynos/cpuidle.c | 8 +- arch/powerpc/platforms/pseries/processor_idle.c | 59 +- drivers/acpi/processor_idle.c | 29 +++-- drivers/cpuidle/cpuidle.c | 3 - drivers/cpuidle/sysfs.c | 5 +- drivers/idle/intel_idle.c | 140 +--- include/linux/cpuidle.h | 1 - 7 files changed, 51 insertions(+), 194 deletions(-) -- 1.8.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/9] ARM: EXYNOS: cpuidle: fix AFTR mode check
The EXYNOS cpuidle driver code assumes that cpuidle core will handle
dev->state_count smaller than drv->state_count but currently this is
untrue (dev->state_count is used only for handling cpuidle state sysfs
entries and drv->state_count is used for all other cases) and will not
be fixed in the future as dev->state_count is planned to be removed.
Fix the issue by checking for the max supported idle state in AFTR
state's ->enter handler (exynos4_enter_lowpower()) and entering AFTR
mode only when cores other than CPU0 are offline.
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
Acked-by: Daniel Lezcano
Cc: Kukjin Kim
---
arch/arm/mach-exynos/cpuidle.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index da65b03..f57cb91 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -172,8 +172,8 @@ static int exynos4_enter_lowpower(struct cpuidle_device
*dev,
{
int new_index = index;
- /* This mode only can be entered when other core's are offline */
- if (num_online_cpus() > 1)
+ /* AFTR can only be entered when cores other than CPU0 are offline */
+ if (num_online_cpus() > 1 || dev->cpu != 0)
new_index = drv->safe_state_index;
if (new_index == 0)
@@ -235,10 +235,6 @@ static int exynos_cpuidle_probe(struct platform_device
*pdev)
device = &per_cpu(exynos4_cpuidle_device, cpu_id);
device->cpu = cpu_id;
- /* Support IDLE only */
- if (cpu_id != 0)
- device->state_count = 1;
-
ret = cpuidle_register_device(device);
if (ret) {
dev_err(&pdev->dev, "failed to register cpuidle
device\n");
--
1.8.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/legacy_serial: fix incorrect placement of __initdata tag
On Tuesday, October 08, 2013 02:56:23 PM Michael Ellerman wrote: > On Thu, Oct 03, 2013 at 01:51:27PM +0200, Bartlomiej Zolnierkiewicz wrote: > > On Tuesday, October 01, 2013 04:13:25 PM Michael Ellerman wrote: > > > On Mon, Sep 30, 2013 at 03:11:42PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > > __initdata tag should be placed between the variable name and equal > > > > sign for the variable to be placed in the intended .init.data section. > > > > > > I see lots of other occurences of that in arch/powerpc. Why not send a > > > single patch to update them all? > > > > The other occurences while not following the preferred kernel coding style > > are (probably) working OK with gcc. This particular occurence just doesn't > > work as it should. > > Why would the other occurrences work but not this one? Because gcc seems to generate the correct code for things like i.e. this one: struct of_device_id __initdata legacy_serial_parents[] but not for ones like this: struct __initdata of_device_id legacy_serial_parents[] > Regardless, why don't we just do a single patch to clean them all up to > match coding style and (probably) do what they're intended. Because: - fixing this occurence changes runtime, fixing others won't - there were no such request from powerpc Maintainers Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/legacy_serial: fix incorrect placement of __initdata tag
On Tuesday, October 01, 2013 04:13:25 PM Michael Ellerman wrote: > On Mon, Sep 30, 2013 at 03:11:42PM +0200, Bartlomiej Zolnierkiewicz wrote: > > __initdata tag should be placed between the variable name and equal > > sign for the variable to be placed in the intended .init.data section. > > I see lots of other occurences of that in arch/powerpc. Why not send a > single patch to update them all? The other occurences while not following the preferred kernel coding style are (probably) working OK with gcc. This particular occurence just doesn't work as it should. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/8xx: tqm8xx: fix incorrect placement of __initdata tag
On Monday, September 30, 2013 03:20:29 PM David Laight wrote:
> > __initdata tag should be placed between the variable name and equal
> > sign for the variable to be placed in the intended .init.data section.
> ...
> > -static struct __initdata cpm_pin tqm8xx_pins[] = {
> > +static struct cpm_pin tqm8xx_pins[] __initdata = {
>
> As far as gcc is concerned it can go almost anywhere before the '=',
> even before the 'static'.
> Splitting 'struct cpm_pin' does seem an odd choice.
It is not only an odd choice, it just doesn't work as it should in
the practice (as tested with gcc-4.6.3 from Ubuntu 12.04).
> The Linux coding standards might suggest a location.
> I'd have thought that either before or after the 'static' would be best
> (ie as a storage class qualifier).
The majority of the kernel code uses __initdata before equal sign
and the __initdata documentation in recommends such
usage:
"
* For initialized data:
* You should insert __initdata or __initconst between the variable name
* and equal sign followed by value, e.g.:
*
* static int init_variable __initdata = 0;
* static const char linux_logo[] __initconst = { 0x32, 0x36, ... };
"
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/8xx: tqm8xx: fix incorrect placement of __initdata tag
__initdata tag should be placed between the variable name and equal
sign for the variable to be placed in the intended .init.data section.
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
arch/powerpc/platforms/8xx/tqm8xx_setup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/tqm8xx_setup.c
b/arch/powerpc/platforms/8xx/tqm8xx_setup.c
index 8d21ab7..ef0778a 100644
--- a/arch/powerpc/platforms/8xx/tqm8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/tqm8xx_setup.c
@@ -48,7 +48,7 @@ struct cpm_pin {
int port, pin, flags;
};
-static struct __initdata cpm_pin tqm8xx_pins[] = {
+static struct cpm_pin tqm8xx_pins[] __initdata = {
/* SMC1 */
{CPM_PORTB, 24, CPM_PIN_INPUT}, /* RX */
{CPM_PORTB, 25, CPM_PIN_INPUT | CPM_PIN_SECONDARY}, /* TX */
@@ -63,7 +63,7 @@ static struct __initdata cpm_pin tqm8xx_pins[] = {
{CPM_PORTC, 11, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_GPIO},
};
-static struct __initdata cpm_pin tqm8xx_fec_pins[] = {
+static struct cpm_pin tqm8xx_fec_pins[] __initdata = {
/* MII */
{CPM_PORTD, 3, CPM_PIN_OUTPUT},
{CPM_PORTD, 4, CPM_PIN_OUTPUT},
--
1.8.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/legacy_serial: fix incorrect placement of __initdata tag
__initdata tag should be placed between the variable name and equal
sign for the variable to be placed in the intended .init.data section.
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
arch/powerpc/kernel/legacy_serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c
b/arch/powerpc/kernel/legacy_serial.c
index 22e88dd..40bd7bd 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -35,7 +35,7 @@ static struct legacy_serial_info {
phys_addr_t taddr;
} legacy_serial_infos[MAX_LEGACY_SERIAL_PORTS];
-static struct __initdata of_device_id legacy_serial_parents[] = {
+static struct of_device_id legacy_serial_parents[] __initdata = {
{.type = "soc",},
{.type = "tsi-bridge",},
{.type = "opb", },
--
1.8.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.
Hi,
On Thursday, August 22, 2013 11:00:29 AM Deepthi Dharwar wrote:
> This patch involves moving the current pseries_idle backend driver code
> from pseries/processor_idle.c to drivers/cpuidle/cpuidle-powerpc.c,
> and making the backend code generic enough to be able to extend this
> driver code for both powernv and pseries.
>
> It enables the support for pseries platform, such that going forward the same
> code
> with minimal efforts can be re-used for a common driver on powernv
> and can be further extended to support cpuidle idle state mgmt for the rest
> of the powerpc platforms in the future. This removes a lot of code duplicacy,
> making the code elegant.
This patch mixes the code movement with the actual code changes which is
not a good practice as it makes review more difficult and is generally bad
from the long term maintainance POV.
Please split this patch on code movement and code changes parts.
V4 of this patch now also seems to contain changes which I posted on
Tuesday as a part of dev->state_count removal patchset:
http://permalink.gmane.org/gmane.linux.power-management.general/37392
http://permalink.gmane.org/gmane.linux.power-management.general/37393
so some work probably got duplicated. :(
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Signed-off-by: Deepthi Dharwar
> ---
> arch/powerpc/include/asm/paca.h | 23 +
> arch/powerpc/include/asm/processor.h|2
> arch/powerpc/platforms/pseries/Kconfig |9 -
> arch/powerpc/platforms/pseries/Makefile |1
> arch/powerpc/platforms/pseries/processor_idle.c | 360
> ---
> drivers/cpuidle/Kconfig |7
> drivers/cpuidle/Makefile|2
> drivers/cpuidle/cpuidle-powerpc.c | 304 +++
> 8 files changed, 337 insertions(+), 371 deletions(-)
> delete mode 100644 arch/powerpc/platforms/pseries/processor_idle.c
> create mode 100644 drivers/cpuidle/cpuidle-powerpc.c
>
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index 77c91e7..7bd83ff 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -175,6 +175,29 @@ extern void setup_paca(struct paca_struct *new_paca);
> extern void allocate_pacas(void);
> extern void free_unused_pacas(void);
>
> +#ifdef CONFIG_PPC_BOOK3S
> +#define get_lppaca_is_shared_proc() get_paca()->lppaca_ptr->shared_proc
> +static inline void set_lppaca_idle(u8 idle)
> +{
> + get_paca()->lppaca_ptr->idle = idle;
> +}
> +
> +static inline void add_lppaca_wait_state(u64 cycles)
> +{
> + get_paca()->lppaca_ptr->wait_state_cycles += cycles;
> +}
> +
> +static inline void set_lppaca_donate_dedicated_cpu(u8 value)
> +{
> + get_paca()->lppaca_ptr->donate_dedicated_cpu = value;
> +}
> +#else
> +#define get_lppaca_is_shared_proc() -1
> +static inline void set_lppaca_idle(u8 idle) { }
> +static inline void add_lppaca_wait_state(u64 cycles) { }
> +static inline void set_lppaca_donate_dedicated_cpu(u8 value) { }
> +#endif
> +
> #else /* CONFIG_PPC64 */
>
> static inline void allocate_pacas(void) { };
> diff --git a/arch/powerpc/include/asm/processor.h
> b/arch/powerpc/include/asm/processor.h
> index e378ccc..5f57c56 100644
> --- a/arch/powerpc/include/asm/processor.h
> +++ b/arch/powerpc/include/asm/processor.h
> @@ -430,7 +430,7 @@ enum idle_boot_override {IDLE_NO_OVERRIDE = 0,
> IDLE_POWERSAVE_OFF};
> extern int powersave_nap;/* set if nap mode can be used in idle loop */
> extern void power7_nap(void);
>
> -#ifdef CONFIG_PSERIES_IDLE
> +#ifdef CONFIG_CPU_IDLE_POWERPC
> extern void update_smt_snooze_delay(int cpu, int residency);
> #else
> static inline void update_smt_snooze_delay(int cpu, int residency) {}
> diff --git a/arch/powerpc/platforms/pseries/Kconfig
> b/arch/powerpc/platforms/pseries/Kconfig
> index 62b4f80..bb59bb0 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -119,12 +119,3 @@ config DTL
> which are accessible through a debugfs file.
>
> Say N if you are unsure.
> -
> -config PSERIES_IDLE
> - bool "Cpuidle driver for pSeries platforms"
> - depends on CPU_IDLE
> - depends on PPC_PSERIES
> - default y
> - help
> - Select this option to enable processor idle state management
> - through cpuidle subsystem.
> diff --git a/arch/powerpc/platforms/pseries/Makefile
> b/arch/powerpc/platforms/pseries/Makefile
> index 8ae0103..4b22379 100644
> --- a/arch/powerpc/pla
Re: [PATCH] HVSI: Fix apparently backwards args to time_before() in hvsi.c
On Friday 01 January 2010 06:28:03 pm Robert P. J. Day wrote: > > Signed-off-by: Robert P. J. Day > > --- > > no appropriate subsystem maintainer listed in MAINTAINERS. drivers/char/Makefile: obj-$(CONFIG_HVC_CONSOLE) += hvc_vio.o hvsi.o so it should belong to: HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-...@ozlabs.org S: Odd Fixes F: drivers/char/hvc_* [ Though maybe Ben would be willing to pick this one up directly as hvsi is PPC specific thingy and patch is obviously correct. ] > diff --git a/drivers/char/hvsi.c b/drivers/char/hvsi.c > index 793b236..71c0fcd 100644 > --- a/drivers/char/hvsi.c > +++ b/drivers/char/hvsi.c > @@ -711,7 +711,7 @@ static void hvsi_drain_input(struct hvsi_struct *hp) > uint8_t buf[HVSI_MAX_READ] __ALIGNED__; > unsigned long end_jiffies = jiffies + HVSI_TIMEOUT; > > - while (time_before(end_jiffies, jiffies)) > + while (time_before(jiffies, end_jiffies)) > if (0 == hvsi_read(hp, buf, HVSI_MAX_READ)) > break; > } -- Bartlomiej Zolnierkiewicz ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powermac: thermal control turns system off in normal temperature conditions
From: Lyonel Vincent
Subject: [PATCH] powermac: thermal control turns system off in normal
temperature conditions
On certain PowerMacs, a module (therm_windtunnel) controls various
thermal settings (it can report CPU/case temperature, change speed
of internal fans, etc.)
By default, the hardware thermal control has a temperature limit to
protect the computer from damages (the default limit seems to be 80°C)
but therm_windtunnel.c reduces it to an anormaly low value (65°C),
which means that he computer will shut down randomly when hit by direct
sun light or during summer (summer in France can be quite hot), actually
possibly losing data instead of protecting it.
The overheat limit in therm_windtunnel.c:253-254 should be set to 75°C
and 70°C instead of 65°C and 60°C respectively.
From: Lyonel Vincent
Signed-off-by: Bartlomiej Zolnierkiewicz
---
Resurrected from Fedora's bugzilla (aka The Big Black Hole):
https://bugzilla.redhat.com/show_bug.cgi?id=171937
The patch itself seems perfectly valid to me
(especially given comments in therm_windtunnel.c).
drivers/macintosh/therm_windtunnel.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/macintosh/therm_windtunnel.c
===
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -239,8 +239,8 @@ setup_hardware( void )
* to be on the safe side (OSX doesn't)...
*/
if( x.overheat_temp == (80 << 8) ) {
- x.overheat_temp = 65 << 8;
- x.overheat_hyst = 60 << 8;
+ x.overheat_temp = 75 << 8;
+ x.overheat_hyst = 70 << 8;
write_reg( x.thermostat, 2, x.overheat_hyst, 2 );
write_reg( x.thermostat, 3, x.overheat_temp, 2 );
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Delay on intialization ide subsystem(most likely)
On Sunday 05 July 2009 13:17:54 Andrey Gusev wrote:
> On Wed, 10 Jun 2009 13:44:29 +0200
> Bartlomiej Zolnierkiewicz wrote:
>
> > On Tuesday 09 June 2009 01:26:27 Benjamin Herrenschmidt wrote:
> > > On Mon, 2009-06-08 at 22:20 +0200, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > > > [ 70.584122] hdb:<3>ide-pmac lost interrupt, dma status: 8480
> > > >
> > > > DMA status indicates that DMA transfer is still active according
> > > > to the controller. This one is really a platform/hardware
> > > > specific issue.
> > >
> > > I've partially missed that thread. Is the a bugzilla entry or
> >
> > There is no bugzilla entry currently so please check mailing list
> > archives for previous discussion.
> >
> > > something ? Is this a regression ?
> >
> > At least not a recent one (it happens since at least 2.6.24).
> >
>
> Delay is fixed itself in 2.6.31-rc2. Most likely it was platform specific
> issue. But lost interrupt still exists.
> There is log of 2.6.31-rc2:
Thanks for letting us know. When it comes to the lost interrupt issue
I still suspect that this is pmac specific problem (though Dave may have
some fresh idea about it).
> [1.595268] MacIO PCI driver attached to Keylargo chipset
> [1.597024] irq: irq 32 on host
> /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 32
> [1.597988] irq: irq 19 on host
> /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 19
> [1.598024] irq: irq 11 on host
> /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 16
> [1.598365] irq: irq 20 on host
> /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 20
> [1.598401] irq: irq 12 on host
> /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 17
> [1.598762] irq: irq 5 on host
> /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 18
> [1.598797] irq: irq 6 on host
> /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 21
> [1.599264] irq: irq 7 on host
> /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 24
> [1.599300] irq: irq 8 on host
> /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 29
> [1.601336] Uniform Multi-Platform E-IDE driver
> [1.602201] ide-pmac 0002:20:0d.0: enabling device ( -> 0002)
> [2.630651] ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID
> 3, irq 39
> [2.630767] Probing IDE interface ide0...
> [2.930834] hda: IBM-IC35L060AVVA07-0, ATA DISK drive
> [3.290646] hdb: QUANTUM FIREBALLP LM20.5, ATA DISK drive
> [3.291087] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [3.291264] hda: UDMA/100 mode selected
> [3.291473] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [3.291720] hdb: UDMA/66 mode selected
> [3.292118] ide0 at 0xf10c2000-0xf10c2070,0xf10c2160 on irq 39
> [4.320649] ide-pmac: Found Apple KeyLargo ATA-4 controller (macio), bus
> ID 2, irq 19
> [4.320753] Probing IDE interface ide1...
> [4.921004] ide1 at 0xf10ba000-0xf10ba070,0xf10ba160 on irq 19
> [5.950647] ide-pmac: Found Apple KeyLargo ATA-3 controller (macio), bus
> ID 0, irq 20
> [5.950743] Probing IDE interface ide2...
> [6.370828] hde: PHILIPS CDD5101, ATAPI CD/DVD-ROM drive
> [6.730948] hde: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [6.731332] hde: MWDMA2 mode selected
> [6.731832] ide2 at 0xf10be000-0xf10be070,0xf10be160 on irq 20
> [6.732558] ide-gd driver 1.18
> [6.732735] hda: max request size: 128KiB
> [6.763392] hda: 120103200 sectors (61492 MB) w/1863KiB Cache,
> CHS=65535/16/63
> [6.763741] hda: cache flushes supported
> [6.764277] hda: [mac] hda1 hda2 hda3 hda4
> [6.770469] hdb: max request size: 128KiB
> [6.803427] hdb: Host Protected Area detected.
> [6.803431]current capacity is 40130390 sectors (20546 MB)
> [6.803435]native capacity is 40132503 sectors (20547 MB)
> [6.803590] hdb: 40130390 sectors (20546 MB) w/1900KiB Cache,
> CHS=39811/16/63
> [6.803684] hdb: cache flushes not supported
> [6.803910] hdb:
> [ 26.800743] ide-pmac lost interrupt, dma status: 8480
> [ 26.800809] hdb: lost interrupt
> [ 26.800850] hdb: dma_intr: status=0x58 { DriveReady SeekComplete
> DataRequest }
> [ 26.800976] hdb: possibly failed opcode: 0xc8
> [ 26.803449] hda: DMA disabled
> [ 26.805664] hdb: DMA disabled
> [ 26.900633] ide0: reset: success
> [ 26.949147] hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 >
> [ 27.007890] ide-cd driver 5.00
> [ 27.011728] ide-cd: hde: ATAPI 32X DVD-ROM CD-R/RW drive, 8192kB Cache
> [ 27.014163] Uniform CD-ROM driver Revision: 3.20
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Delay on intialization ide subsystem(most likely)
On Tuesday 09 June 2009 01:26:27 Benjamin Herrenschmidt wrote: > On Mon, 2009-06-08 at 22:20 +0200, Bartlomiej Zolnierkiewicz wrote: > > > > [ 70.584122] hdb:<3>ide-pmac lost interrupt, dma status: 8480 > > > > DMA status indicates that DMA transfer is still active according to > > the controller. This one is really a platform/hardware specific issue. > > I've partially missed that thread. Is the a bugzilla entry or There is no bugzilla entry currently so please check mailing list archives for previous discussion. > something ? Is this a regression ? At least not a recent one (it happens since at least 2.6.24). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Delay on intialization ide subsystem(most likely)
On Saturday 30 May 2009 12:46:43 Andrey Gusev wrote: > On Wed, 20 May 2009 17:56:14 +0200 > Bartlomiej Zolnierkiewicz wrote: > > > On Friday 15 May 2009 22:40:07 Andrey Gusev wrote: > > > On Wed, 13 May 2009 20:46:33 +0200 > > > Bartlomiej Zolnierkiewicz wrote: > > > > > > > On Wednesday 13 May 2009 19:11:23 Andrey Gusev wrote: > > > > > On Wed, 13 May 2009 15:28:26 +0200 > > > > > Bartlomiej Zolnierkiewicz wrote: > > > > > > > > > > > On Tuesday 12 May 2009 21:50:24 Andrey Gusev wrote: > > > > > > > On Mon, 27 Apr 2009 23:21:48 +0200 > > > > > > > Bartlomiej Zolnierkiewicz wrote: > > > > > > > > > > > > > > > On Monday 27 April 2009 22:36:45 Andrey Gusev wrote: > > > > > > > > > On Sat, 25 Apr 2009 16:48:38 +0200 > > > > > > > > > Bartlomiej Zolnierkiewicz wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > On Saturday 25 April 2009 15:02:03 Andrey Gusev wrote: > > > > > > > > > > > Hello! > > > > > > > > > > > > > > > > > > > > > > I have tested linux-2.6.30-rc3 on my system and find > > > > > > > > > > > some problems. One of them is delaying on > > > > > > > > > > > initialization IDE subsystem. I don't have this > > > > > > > > > > > problem on 2.6.29.1. The difference is looked on > > > > > > > > > > > log of dmesg. > > > > > > > > > > > > > > > > > > > > Unfortunately this doesn't give us any hint about the > > > > > > > > > > root cause of the bug so please try narrowing the > > > > > > > > > > problem down to the specific change using git-bisect > > > > > > > > > > (sorry, there were 212 drivers/ide/ commits during > > > > > > > > > > v2.6.29..v2.6.30-rc3 and much much more > > > > > > > > > > non-drivers/ide/ ones). > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Bart > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > > > > > > > > > > > > > > The full result of bisect is: > > > > > > > > > > > > > > > > > > > > > > > > > > > git bisect start > > > > > > > > > # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux > > > > > > > > > 2.6.29 git bisect good > > > > > > > > > 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 # bad: > > > > > > > > > [091069740304c979f957ceacec39c461d0192158] Linux > > > > > > > > > 2.6.30-rc3 git bisect bad > > > > > > > > > 091069740304c979f957ceacec39c461d0192158 # good: > > > > > > > > > [40f07111be99b71c1e8d40c13cdc38445add787f] V4L/DVB > > > > > > > > > (11166): pvrusb2: Implement status fetching from > > > > > > > > > sub-devices git bisect good > > > > > > > > > 40f07111be99b71c1e8d40c13cdc38445add787f # good: > > > > > > > > > [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: > > > > > > > > > sxg: slicoss: Specify the license for Sahara SXG and > > > > > > > > > Slicoss drivers git bisect good > > > > > > > > > ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 > > > > > > > > > > > > > > > > > > > > > > > > > > > git bisect start 'drivers/ide/' > > > > > > > > > > > > > > > > Please note that limiting search space to drivers/ide/ > > > > > > > > may not give reliable results in case problem was > > > > > > > > introduced by some other kernel area. > > > > > > > > > > > &
Re: Delay on intialization ide subsystem(most likely)
On Friday 15 May 2009 22:40:07 Andrey Gusev wrote: > On Wed, 13 May 2009 20:46:33 +0200 > Bartlomiej Zolnierkiewicz wrote: > > > On Wednesday 13 May 2009 19:11:23 Andrey Gusev wrote: > > > On Wed, 13 May 2009 15:28:26 +0200 > > > Bartlomiej Zolnierkiewicz wrote: > > > > > > > On Tuesday 12 May 2009 21:50:24 Andrey Gusev wrote: > > > > > On Mon, 27 Apr 2009 23:21:48 +0200 > > > > > Bartlomiej Zolnierkiewicz wrote: > > > > > > > > > > > On Monday 27 April 2009 22:36:45 Andrey Gusev wrote: > > > > > > > On Sat, 25 Apr 2009 16:48:38 +0200 > > > > > > > Bartlomiej Zolnierkiewicz wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Saturday 25 April 2009 15:02:03 Andrey Gusev wrote: > > > > > > > > > Hello! > > > > > > > > > > > > > > > > > > I have tested linux-2.6.30-rc3 on my system and find > > > > > > > > > some problems. One of them is delaying on > > > > > > > > > initialization IDE subsystem. I don't have this problem > > > > > > > > > on 2.6.29.1. The difference is looked on log of dmesg. > > > > > > > > > > > > > > > > Unfortunately this doesn't give us any hint about the root > > > > > > > > cause of the bug so please try narrowing the problem down > > > > > > > > to the specific change using git-bisect (sorry, there > > > > > > > > were 212 drivers/ide/ commits during v2.6.29..v2.6.30-rc3 > > > > > > > > and much much more non-drivers/ide/ ones). > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Bart > > > > > > > > > > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > > > > > > > > The full result of bisect is: > > > > > > > > > > > > > > > > > > > > > git bisect start > > > > > > > # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux > > > > > > > 2.6.29 git bisect good > > > > > > > 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 # bad: > > > > > > > [091069740304c979f957ceacec39c461d0192158] Linux 2.6.30-rc3 > > > > > > > git bisect bad 091069740304c979f957ceacec39c461d0192158 # > > > > > > > good: [40f07111be99b71c1e8d40c13cdc38445add787f] V4L/DVB > > > > > > > (11166): pvrusb2: Implement status fetching from > > > > > > > sub-devices git bisect good > > > > > > > 40f07111be99b71c1e8d40c13cdc38445add787f # good: > > > > > > > [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: sxg: > > > > > > > slicoss: Specify the license for Sahara SXG and Slicoss > > > > > > > drivers git bisect good > > > > > > > ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 > > > > > > > > > > > > > > > > > > > > > git bisect start 'drivers/ide/' > > > > > > > > > > > > Please note that limiting search space to drivers/ide/ may not > > > > > > give reliable results in case problem was introduced by some > > > > > > other kernel area. > > > > > > > > > > > > > # good: [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: > > > > > > > sxg: slicoss: Specify the license for Sahara SXG and > > > > > > > Slicoss drivers git bisect good > > > > > > > ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 # bad: > > > > > > > [091069740304c979f957ceacec39c461d0192158] Linux 2.6.30-rc3 > > > > > > > git bisect bad 091069740304c979f957ceacec39c461d0192158 # > > > > > > > good: [e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d] ide-cd: > > > > > > > convert cdrom_decode_status() to use switch statements git > > > > > > > bisect good e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d # > > > > > > > good: [3153c26b54230d025c6d536e8d3015def4524906] ide: > > > > > > > refactor tf_read() method git bisec
Re: Delay on intialization ide subsystem(most likely)
On Wednesday 13 May 2009 19:11:23 Andrey Gusev wrote: > On Wed, 13 May 2009 15:28:26 +0200 > Bartlomiej Zolnierkiewicz wrote: > > > On Tuesday 12 May 2009 21:50:24 Andrey Gusev wrote: > > > On Mon, 27 Apr 2009 23:21:48 +0200 > > > Bartlomiej Zolnierkiewicz wrote: > > > > > > > On Monday 27 April 2009 22:36:45 Andrey Gusev wrote: > > > > > On Sat, 25 Apr 2009 16:48:38 +0200 > > > > > Bartlomiej Zolnierkiewicz wrote: > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Saturday 25 April 2009 15:02:03 Andrey Gusev wrote: > > > > > > > Hello! > > > > > > > > > > > > > > I have tested linux-2.6.30-rc3 on my system and find some > > > > > > > problems. One of them is delaying on initialization IDE > > > > > > > subsystem. I don't have this problem on 2.6.29.1. The > > > > > > > difference is looked on log of dmesg. > > > > > > > > > > > > Unfortunately this doesn't give us any hint about the root > > > > > > cause of the bug so please try narrowing the problem down to > > > > > > the specific change using git-bisect (sorry, there were 212 > > > > > > drivers/ide/ commits during v2.6.29..v2.6.30-rc3 and much much > > > > > > more non-drivers/ide/ ones). > > > > > > > > > > > > Thanks, > > > > > > Bart > > > > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > > The full result of bisect is: > > > > > > > > > > > > > > > git bisect start > > > > > # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29 > > > > > git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 > > > > > # bad: [091069740304c979f957ceacec39c461d0192158] Linux > > > > > 2.6.30-rc3 git bisect bad > > > > > 091069740304c979f957ceacec39c461d0192158 # good: > > > > > [40f07111be99b71c1e8d40c13cdc38445add787f] V4L/DVB (11166): > > > > > pvrusb2: Implement status fetching from sub-devices git bisect > > > > > good 40f07111be99b71c1e8d40c13cdc38445add787f # good: > > > > > [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: sxg: > > > > > slicoss: Specify the license for Sahara SXG and Slicoss drivers > > > > > git bisect good ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 > > > > > > > > > > > > > > > git bisect start 'drivers/ide/' > > > > > > > > Please note that limiting search space to drivers/ide/ may not > > > > give reliable results in case problem was introduced by some > > > > other kernel area. > > > > > > > > > # good: [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: sxg: > > > > > slicoss: Specify the license for Sahara SXG and Slicoss drivers > > > > > git bisect good ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 # bad: > > > > > [091069740304c979f957ceacec39c461d0192158] Linux 2.6.30-rc3 git > > > > > bisect bad 091069740304c979f957ceacec39c461d0192158 # good: > > > > > [e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d] ide-cd: convert > > > > > cdrom_decode_status() to use switch statements git bisect good > > > > > e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d # good: > > > > > [3153c26b54230d025c6d536e8d3015def4524906] ide: refactor > > > > > tf_read() method git bisect good > > > > > 3153c26b54230d025c6d536e8d3015def4524906 # good: > > > > > [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366: fix HPT370 > > > > > DMA timeouts git bisect good > > > > > c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac # bad: > > > > > [d5f840bf74c09ca5a31e518c9d98426b5f44] ide: Remove void > > > > > casts git bisect bad d5f840bf74c09ca5a31e518c9d98426b5f44 # > > > > > bad: [59c8d04f5ee97ea46da854e9adbbaa45d988c39d] hpt366: use > > > > > ATA_DMA_* constants git bisect bad > > > > > 59c8d04f5ee97ea46da854e9adbbaa45d988c39d > > > > > > > > Uhh.. something went wrong during bisect. > > > > > > > > "hpt366: use ATA_DMA_* constants" cannot be a first bad commit > > > > because hpt366 is not even used on t
Re: [PATCH] alim15x3: Remove historical hacks, re-enable init_hwif for PowerPC
On Monday 27 April 2009 20:47:42 Anton Vorontsov wrote: > Some time ago we had to disable init_hwif callback for PowerPC builds. > That was because of a historical IRQ overwrite in the driver, which > was causing IDE malfunction on the MPC8610HPCD PowerPC boards. > > It's unclear whether this overwrite is still useful, but it is proven > to cause a bit of harm, and today some PowerPC targets (Xilinx ML510, > as reported by Roderick Colenbrander) need the init_hwif, so we have > to re-enable it and remove the overwrite. > > Reported-by: Roderick Colenbrander > Suggested-by: Bartlomiej Zolnierkiewicz > Signed-off-by: Anton Vorontsov thanks, I applied it to ide-2.6.git/for-next ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 05/12] Next April 21 : PPC64 randconfig [drivers/macintosh/mediabay.o]
On Wednesday 22 April 2009 05:59:27 Paul Mackerras wrote: > Bartlomiej Zolnierkiewicz writes: > > > mediabay shouldn't include unconditionally so > > remove the superfluous include from mediabay.c ( > > will pull in for CONFIG_BLK_DEV_IDE_PMAC=y). > > I don't like relying on second-hand imports like that. I prefer the > previous patch, that made mediabay depend on CONFIG_BLOCK. I missed it somehow... OK, I found it now and it should fix the problem as well. > BTW, if including causes an error when CONFIG_BLOCK=n, > then there is a bug in , IMO. is for drivers/ide only. mediabay lacks proper abstraction layer and is probably the only abuser left. Besides being a build fix my patch is a right step in cleaning this mess so I'm going to apply it through ide tree. Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 07/12] Next April 14 : PPC64 randconfig [drivers/ide/pmac.c]
On Tuesday 14 April 2009 20:29:19 Subrata Modak wrote: > Observed the following build error: > --- > CC [M] drivers/ide/pmac.o > drivers/ide/pmac.c: In function ‘pmac_ide_init_dev’: > drivers/ide/pmac.c:955: error: implicit declaration of function > ‘check_media_bay_by_base’ > drivers/ide/pmac.c: In function ‘pmac_ide_setup_device’: > drivers/ide/pmac.c:1090: error: implicit declaration of function > ‘media_bay_set_ide_infos’ > make[2]: *** [drivers/ide/pmac.o] Error 1 > make[1]: *** [drivers/ide] Error 2 > make: *** [drivers] Error 2 > --- Should be fixed by: From: Bartlomiej Zolnierkiewicz Subject: [PATCH] ide-pmac: fix modular build for CONFIG_PMAC_MEDIABAY=y On Tuesday 14 April 2009 20:29:19 Subrata Modak wrote: > Observed the following build error: > --- > CC [M] drivers/ide/pmac.o > drivers/ide/pmac.c: In function ‘pmac_ide_init_dev’: > drivers/ide/pmac.c:955: error: implicit declaration of function > ‘check_media_bay_by_base’ > drivers/ide/pmac.c: In function ‘pmac_ide_setup_device’: > drivers/ide/pmac.c:1090: error: implicit declaration of function > ‘media_bay_set_ide_infos’ > make[2]: *** [drivers/ide/pmac.o] Error 1 > make[1]: *** [drivers/ide] Error 2 > make: *** [drivers] Error 2 > --- IDE PMAC host driver can be modular now so we need to export check_media_bay_by_base() and media_bay_set_ide_infos(). Reported-by: Subrata Modak Cc: Paul Mackerras Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/macintosh/mediabay.c |2 ++ 1 file changed, 2 insertions(+) Index: b/drivers/macintosh/mediabay.c === --- a/drivers/macintosh/mediabay.c +++ b/drivers/macintosh/mediabay.c @@ -447,6 +447,7 @@ int check_media_bay_by_base(unsigned lon return -ENODEV; } +EXPORT_SYMBOL_GPL(check_media_bay_by_base); int media_bay_set_ide_infos(struct device_node* which_bay, unsigned long base, int irq, ide_hwif_t *hwif) @@ -486,6 +487,7 @@ int media_bay_set_ide_infos(struct devic return -ENODEV; } +EXPORT_SYMBOL_GPL(media_bay_set_ide_infos); #endif /* CONFIG_BLK_DEV_IDE_PMAC */ static void media_bay_step(int i) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 05/12] Next April 21 : PPC64 randconfig [drivers/macintosh/mediabay.o]
On Tuesday 21 April 2009 20:51:15 Subrata Modak wrote: > Reported this earlier on 14th April: > http://lkml.org/lkml/2009/4/14/490, > > Is there a solution available ? Perfect timing. I was just going through overdue reports. > CC drivers/macintosh/mediabay.o > In file included from drivers/macintosh/mediabay.c:21: > include/linux/ide.h:610: error: field ‘sense_rq’ has incomplete type > make[2]: *** [drivers/macintosh/mediabay.o] Error 1 > make[1]: *** [drivers/macintosh] Error 2 > make: *** [drivers] Error 2 > --- From: Bartlomiej Zolnierkiewicz Subject: [PATCH] mediabay: fix build for CONFIG_BLOCK=n On Tuesday 14 April 2009 20:31:21 Subrata Modak wrote: > Observed the following build error: > --- > CC drivers/macintosh/mediabay.o > In file included from drivers/macintosh/mediabay.c:21: > include/linux/ide.h:605: error: field ‘request_sense_rq’ has incomplete > type > make[2]: *** [drivers/macintosh/mediabay.o] Error 1 > make[1]: *** [drivers/macintosh] Error 2 > make: *** [drivers] Error 2 > --- mediabay shouldn't include unconditionally so remove the superfluous include from mediabay.c ( will pull in for CONFIG_BLK_DEV_IDE_PMAC=y). Reported-by: Subrata Modak Cc: Paul Mackerras Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/macintosh/mediabay.c |1 - 1 file changed, 1 deletion(-) Index: b/drivers/macintosh/mediabay.c === --- a/drivers/macintosh/mediabay.c +++ b/drivers/macintosh/mediabay.c @@ -18,7 +18,6 @@ #include #include #include -#include #include #include #include ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
On Friday 17 April 2009 18:49:44 Benjamin Herrenschmidt wrote:
> > But they don't. On MPC8610HPCD we have IDE interrupt directly
> > connected to the MPIC line (through PCI sideband interrupt), and
> > i8259 is _completely_ disabled in the bridge.
>
> Hrm why did you do that ? :-)
>
> Just kidding... if what you want is the PCI interrupt, then it should
> be in native mode, not legacy mode... Maybe the driver can figure out
> how the chip is configured by reading said configuration and use
> either the legacy interrupts or the PCI one...
>
> > See this commit:
> >
> > commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3
> > Author: Anton Vorontsov
> > Date: Tue Apr 29 22:57:38 2008 +0200
> >
> > alim15x3: disable init_hwif_ali15x3 for PowerPC
> >
> > > Acked-by: Benjamin Herrenschmidt
> >
> > If the patch applied, MPC8610HPCD will be broken.
> >
> > We need at least some machine_is() check.
>
> That sucks. That's an endless problems with IDE and those on-board
> chipsets though. The interrupts should pretty much -always- be provided
> by the arch code, but for some reason, that got removed in favor of
> various hacks in the drivers themselves...
Previous PPC IRQ hacks combined with IDE IRQ hacks were a real nightmare
from maintenance perspective -- one could just never tell what is going
on and whether it is correct.
IDE host driver specific hacks were just a necessary temporary step into
solving this problem and most of them got removed in this merge window
during more general rework of IRQ setup code.
Nowadays IDE PCI layer just consistently uses arch specific (+ non-IDE
specific so libata gets benefits too) pci_get_legacy_ide_irq() helper
for legacy IRQs, please see ide_pci_init_one():
...
/* fixup IRQ */
if (ide_pci_is_in_compatibility_mode(dev)) {
hw[0].irq = pci_get_legacy_ide_irq(dev, 0);
hw[1].irq = pci_get_legacy_ide_irq(dev, 1);
} else
hw[1].irq = hw[0].irq = ret;
...
That's all! No PPC-specific IRQ overrides, IDE-specific IRQ overrides
and IDE host driver ones needed! :)
There is still some legacy code (like the one in alim15x3 host driver)
needing fixing but the infrastructure allowing it should be all there.
Hmm, it looks like this historical IRQ override in init_hwif_ali15x3():
if (dev->device == PCI_DEVICE_ID_AL_M5229)
hwif->irq = hwif->channel ? 15 : 14;
should be just removed nowadays.
Seems like this should allow MPC8610HPCD to work with Roderick's patch
if the IDE controller is set to native mode and ALI south-bridge SIRQ
tables are correctly set (or if this is not ALI's south-bridge). Anton?
Thanks,
Bart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
Hi, On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote: > Hi, > > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge > for IDE, USB and Audio. I did a lot of work to get the pci bus working > on this board and it works correctly but the default init code > of the alim15x3 driver doesn't work for me. The driver explicitly > disabled some initialization code for powerpc after uncommenting this > code it works properly. Benjamin Herrenschmidt and I think this > !CONFIG_PPC check should be removed because the system behaves > like a real 'x86' system (also the i8259 interrupt controller is used). Ben, I guess you are OK with the change and there are no longer other platforms requiring CONFIG_PPC check below? [I don't see your ACK here] > Regards, > Roderick Colenbrander > > > From 1c40c2f1485ecd3bc5ad7a3af537cb94de0877c3 Mon Sep 17 00:00:00 2001 > From: Roderick Colenbrander > Date: Wed, 15 Apr 2009 10:45:17 +0200 > Subject: [PATCH] Use the 'x86' init_hwif code in the alim15x3 for > x86-like PowerPC boards like Xilinx ML310/410/510. Roderick, please add your "Signed-off-by:" line (per Documentation/SubmittingPatches). Thanks. > --- > drivers/ide/alim15x3.c |9 + > 1 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c > index 537da1c..9176c0f 100644 > --- a/drivers/ide/alim15x3.c > +++ b/drivers/ide/alim15x3.c > @@ -402,14 +402,15 @@ static u8 ali_cable_detect(ide_hwif_t *hwif) > return cbl; > } > > -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) > +#if !defined(CONFIG_SPARC64) > /** > *init_hwif_ali15x3-Initialize the ALI IDE x86 stuff > *@hwif: interface to configure > * > *Obtain the IRQ tables for an ALi based IDE solution on the PC > - *class platforms. This part of the code isn't applicable to the > - *Sparc and PowerPC systems. > + *class platforms. This part of the code isn't applicable to > + *Sparc systems. It is usable on 'x86-like' PowerPC systems > + * which use a Ali M15x3 south bridge like e.g. Xilinx ML310/410/510. > */ > > static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif) > @@ -455,7 +456,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif) > } > #else > #define init_hwif_ali15x3 NULL > -#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */ > +#endif /* !defined(CONFIG_SPARC64) */ > > /** > *init_dma_ali15x3-set up DMA on ALi15x3 > -- > 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] linux-next remove wmb() from ide-dma-sff.c and scc_pata.c
On Tuesday 31 March 2009, KOBAYASHI Yoshitake wrote: > 2009/03/31 16:51, Geert Uytterhoeven wrote: > > On Mon, 30 Mar 2009, Grant Grundler wrote: > >> Followup to "[PATCH 03/10] ide: destroy DMA mappings after ending DMA" > >> email on March 14th: > >> http://lkml.org/lkml/2009/3/14/17 > >> > >> No maintainer is listed for "Toshiba CELL Reference Set IDE" > >> (BLK_DEV_CELLEB) > >> or tx4939ide.c in MAINTAINERS. I've CC'd "Ishizaki Kou" @Toshiba > >> (Maintainer for > >> "Spidernet Network Driver for CELL") and linuxppc-dev list in the hope > >> someone else > >> would know or would be able to ACK this patch. > > > > tx49xx is MIPS, for Nemoto-san. > > The patch looks good for Toshiba Cell Reference Set. Great, I applied the patch. Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards
On Tuesday 13 January 2009, Gerhard Pircher wrote: > > Original-Nachricht > > Datum: Tue, 13 Jan 2009 16:02:38 +1100 > > Von: Benjamin Herrenschmidt > > An: Gerhard Pircher > > CC: Bartlomiej Zolnierkiewicz , > > grant.lik...@secretlab.ca, linuxppc-dev@ozlabs.org, > > linux-...@vger.kernel.org > > Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne > > boards > > > > Yes, it can wait. > > > Although I would like to know from the powerpc maintainer, if my > > > platform patches could still go in 2.6.29, if I resend them in the next > > > days? I > > > guess it's too late, right? > > > > Yes it is. I'll put them in -next after -rc2 or later, when we are happy > > with them. That gives us a bit of time to do extra polishing. > Good, then I'll send out a new patch for the IDE driver and the current one > can be reverted. The following patchset fixes core IDE PCI code to always use pci_get_legacy_ide_irq() and ide_pci_is_in_compatibility_mode(): http://lkml.org/lkml/2009/1/19/163 so via82cxxx specific solution is no longer necessary. [ IOW I'll keep your previous patch and the #ifdef issue will solve itself after the above patchset is merged. ] Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards
On Sunday 11 January 2009, Gerhard Pircher wrote: > > Original-Nachricht > > Datum: Sun, 11 Jan 2009 17:51:55 +0100 > > Von: Bartlomiej Zolnierkiewicz > > An: "Gerhard Pircher" > > CC: "Grant Likely" , linuxppc-dev@ozlabs.org, > > linux-...@vger.kernel.org > > Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne > > boards > > > On Wednesday 07 January 2009, Gerhard Pircher wrote: > > > > > > Original-Nachricht > > > > Datum: Wed, 7 Jan 2009 08:13:06 -0700 > > > > Von: "Grant Likely" > > > > An: "Gerhard Pircher" > > > > CC: linuxppc-dev@ozlabs.org, bzoln...@gmail.com > > > > Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for > > AmigaOne boards > > > > > > > On Wed, Jan 7, 2009 at 7:12 AM, Gerhard Pircher > > > > > > wrote: > > > > > The AmigaOne uses the onboard VIA IDE controller in legacy mode > > > > >(like the Pegasos). > > > > > > > > > > Signed-off-by: Gerhard Pircher > > > > > --- > > > > > drivers/ide/via82cxxx.c |5 + > > > > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > > > > > This patch needs to also be posted on the linux-ide mailing list. > > > Ouch, I only sent it to the maintainer. I'll fix that. > > > > [ Please also keep all previous recipients on cc: when doing so. ] > Okay, I'll keep that in mind. > > > > > > diff --git a/drivers/ide/via82cxxx.c b/drivers/ide/via82cxxx.c > > > > > index 2a812d3..086f476 100644 > > > > > --- a/drivers/ide/via82cxxx.c > > > > > +++ b/drivers/ide/via82cxxx.c > > > > > @@ -450,6 +450,11 @@ static int __devinit via_init_one(struct > > pci_dev > > > > *dev, const struct pci_device_i > > > > >d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS; > > > > > #endif > > > > > > > > > > +#ifdef CONFIG_AMIGAONE > > > > > + if (machine_is(amigaone)) > > > > > + d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS; > > > > > +#endif > > > > > + > > > > > > > > I know you're just following the example of the PEGASOS workaround > > > > immediately above; but the #defines are really ugly. I wonder if > > > > there is there a cleaner way to manipulate the flags. > > > AFAIK the via82cxxx driver doesn't make use of the > > > pci_get_legacy_ide_irq approach. > > > > I applied your patch for 2.6.29 but for 2.6.30 I would ask you to clean > > up #ifdefs by using ide_pci_is_in_compatibility_mode() helper instead for > > checking if IDE_HFLAG_FORCE_LEGACY_IRQS should be set. > Wouldn't it be better, if I clean this up now? (I have to resend my AmigaOne > platform patches anyway). Replacement patch instead of incremental one is also fine with me -- given that it can wait for 2.6.30. > > [ Some time ago Pegasos got PCI quirk to put controller in the legacy mode > > (arch/powerpc/platforms/chrp/pci.c) so it is OK to also remove Pegasos' > > special case while at it. ] > Okay, so the change shouldn't break IDE for Pegasos machines (I don't have > a Pegasos for testing). Yes but there may be some other platforms (not necessarily powerpc ones) that may be affected (i.e. they can depend indirectly on IRQ auto-probing during IDE probe) so cleanup patch needs to spend some time in linux-next. Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/9] sl82c105: remove dead code
On Sunday 11 January 2009, Sergei Shtylyov wrote: > Hello. > > Bartlomiej Zolnierkiewicz wrote: > > > CONFIG_LOPEC and CONFIG_SANDPOINT config options are gone. > > > > So these are gone with arch/ppc/? Yep. > That's a pity -- MV has spent a lot of efforts on porting the latter > to arch/powerpc/ but somehow it haven't got merged upstream. My patches > ot this driver were actually due to it being used on Sandpoint. :-) Heh, and I cleaned ppc IDE hooks just before these platforms were removed (that's how these ifdefs got into sl82c105.c). :-) Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards
On Wednesday 07 January 2009, Gerhard Pircher wrote: > > Original-Nachricht > > Datum: Wed, 7 Jan 2009 08:13:06 -0700 > > Von: "Grant Likely" > > An: "Gerhard Pircher" > > CC: linuxppc-dev@ozlabs.org, bzoln...@gmail.com > > Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne > > boards > > > On Wed, Jan 7, 2009 at 7:12 AM, Gerhard Pircher > > wrote: > > > The AmigaOne uses the onboard VIA IDE controller in legacy mode (like > > the > > > Pegasos). > > > > > > Signed-off-by: Gerhard Pircher > > > --- > > > drivers/ide/via82cxxx.c |5 + > > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > This patch needs to also be posted on the linux-ide mailing list. > Ouch, I only sent it to the maintainer. I'll fix that. [ Please also keep all previous recipients on cc: when doing so. ] > > > diff --git a/drivers/ide/via82cxxx.c b/drivers/ide/via82cxxx.c > > > index 2a812d3..086f476 100644 > > > --- a/drivers/ide/via82cxxx.c > > > +++ b/drivers/ide/via82cxxx.c > > > @@ -450,6 +450,11 @@ static int __devinit via_init_one(struct pci_dev > > *dev, const struct pci_device_i > > >d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS; > > > #endif > > > > > > +#ifdef CONFIG_AMIGAONE > > > + if (machine_is(amigaone)) > > > + d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS; > > > +#endif > > > + > > > > I know you're just following the example of the PEGASOS workaround > > immediately above; but the #defines are really ugly. I wonder if > > there is there a cleaner way to manipulate the flags. > AFAIK the via82cxxx driver doesn't make use of the pci_get_legacy_ide_irq > approach. I applied your patch for 2.6.29 but for 2.6.30 I would ask you to clean up #ifdefs by using ide_pci_is_in_compatibility_mode() helper instead for checking if IDE_HFLAG_FORCE_LEGACY_IRQS should be set. [ Some time ago Pegasos got PCI quirk to put controller in the legacy mode (arch/powerpc/platforms/chrp/pci.c) so it is OK to also remove Pegasos' special case while at it. ] Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6 patch] cleanup powerpc/include/asm/ide.h
On Friday 08 August 2008, Adrian Bunk wrote: > This patch removes code that became unused through IDE changes and the > arch/ppc/ removal. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Thursday 31 July 2008, Bartlomiej Zolnierkiewicz wrote:
[...]
Sorry if my mails were a bit harsh but nobody likes to be pushed around.
[ It is not like I don't want to add proper hot-plugging support or do test
on more hardware but my time schedule is already tight enough and there are
still more fundamental things to address (which take priority). ]
> -host->dev[0] = hws[0]->dev;
> +host->dev[0] = hws[0]->parent ? hws[0]->parent : hws[0]->dev;
>
> Could you please try it together with my previous patch for
> ide_device_{get,put}()?
Please test it when you have some time.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Thursday 31 July 2008, Benjamin Herrenschmidt wrote:
>
> > Is it actually caused by additional reference counting on drive->gendev?
> > IOW if you reverse the patch below instead of applying the previous fix
> > do things work OK again?
> >
> > > Note that there shouldn't be anything fundamentally different from
> > > ide-pmac here vs. something like pcmcia IDE cards... do you have one of
> > > these to test with ?
> >
> > Nope and I really don't intend to have one. I count on other people
> > to take some care of support for host drivers that they maintain/use. ;)
>
> Reverting the patch below does the job. Thanks.
Thanks, this narrows down the problem pretty nicely.
[ Unfortunately we cannot revert the whole patch as it would break
unloading of IDE host drivers modules so I still need you help on
fixing this one. ]
Lets get back to the oops:
Vector: 300 (Data Access) at [c59dfdc0]
pc: c0211f78: ide_device_put+0x18/0x58
lr: c0223c34: ide_cd_put+0x40/0x5c
sp: c59dfe70
msr: 9032
dar: 10
dsisr: 4000
current = 0xc58a9880
pid = 843, comm = media-bay
enter ? for help
[c59dfe80] c0223c34 ide_cd_put+0x40/0x5c
[c59dfea0] c02114d4 generic_ide_remove+0x28/0x3c
[c59dfeb0] c01ea108 __device_release_driver+0x78/0xb4
[c59dfec0] c01ea218 device_release_driver+0x28/0x44
[c59dfee0] c01e9350 bus_remove_device+0xac/0xd8
[c59dff00] c01e77f8 device_del+0x104/0x198
[c59dff20] c01e78a4 device_unregister+0x18/0x30
[c59dff40] c0212598 __ide_port_unregister_devices+0x6c/0x88
[c59dff60] c021276c ide_port_unregister_devices+0x38/0x80
[c59dff80] c0209078 media_bay_step+0x1cc/0x5c0
[c59dffb0] c02094f8 media_bay_task+0x8c/0xcc
[c59dffd0] c0048640 kthread+0x48/0x84
[c59dfff0] c0011b38 kernel_thread+0x44/0x60
On a fresh look at ide_device_put(), ide_host_alloc() and pmac.c
it may be that the above oops is actually media-bay specific.
ide_device_put():
...
struct device *host_dev = drive->hwif->host->dev[0];
struct module *module = host_dev ? host_dev->driver->owner : NULL;
...
ide_host_alloc():
...
if (hws[0])
host->dev[0] = hws[0]->dev;
...
pmac.c:
...
pmac_ide_macio_attach(struct macio_dev *mdev, const struct of_device_id *match)
...
dev_set_drvdata(&mdev->ofdev.dev, pmif);
memset(&hw, 0, sizeof(hw));
pmac_ide_init_ports(&hw, pmif->regbase);
hw.irq = irq;
hw.dev = &mdev->bus->pdev->dev;
hw.parent = &mdev->ofdev.dev;
...
pmac macio is unique in using different devices for hwif->dev / host->dev
(hw.dev) and hwif->gendev.parent / dev_set_drvdata() (hw.parent)
[ I has been actually wondering why is it so for some time...? ]
Thus we may be hitting oops in ide_device_put() on host_dev->driver
because hw.dev is used as host->dev for pmac macio in ide_device_put()
while we really want to use hw.parent.
Fix should be as simple as:
-host->dev[0] = hws[0]->dev;
+host->dev[0] = hws[0]->parent ? hws[0]->parent : hws[0]->dev;
Could you please try it together with my previous patch for
ide_device_{get,put}()?
Bart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Thursday 31 July 2008, Benjamin Herrenschmidt wrote: > On Thu, 2008-07-31 at 02:48 +0200, Bartlomiej Zolnierkiewicz wrote: > > There seems to be some confusion between warm-plugging of IDE devices > > and hot-plugging of IDE devices. > > > > > not a single piece of HW to exercise those code path ? I don't ask you > > > to get a powermac with a media-bay, but ide_cs seems to be a pretty > > > important one that's part of what the ide maintainer should take care > > > of... And I suspect it's going to exercise the same code path as > > > mediabay. > > > > I'm open for offers of co-maintaince of the code (which includes taking > > over particular host drivers) and since you seem to have pretty good > > insight into what ide maintainer should be doing I presume that you want > > to be added to MAINTAINERS? > > Should I laugh ? > > Seriously here. Those things used to work, you broke them. That's jumping to conlusions as you haven't yet proven that it was really me. :) Which would be great because than I can finally start fixing the damage. > It may be worthwile cleanup / improvements, but at the end of the day, > if you are the maintainer for drivers/ide, and things as fundamental as > supporting proper ide_cs seems to be totally part of your job. I'm not Maybe I'm really completely unsuited for the job. I even didn't know that proper supporting of _one_ particular host driver is a _fundamental_ part of the _subsystem_ maintainer's job... > saying ide_cs is broken today (though I suspect it -may- be suffering > from similar breakage to media-bay), however, I'm reacting to your > apparent lack of interest in making sure these things work. If only all people showed so much interest as *IDE*PMAC* Maintainer in making sure that things work (instead of i.e. telling people what should they be doing in their _limited_ _private_ time) we would have nothing to worry about! ;) Can we now go back to fixing ide-pmac breakage? Pretty please. It is not unlikely that it in the time it took for the last four mails it would have been fixed already. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Thursday 31 July 2008, Benjamin Herrenschmidt wrote: > On Wed, 2008-07-30 at 21:11 +0200, Bartlomiej Zolnierkiewicz wrote: > > > > > Note that there shouldn't be anything fundamentally different from > > > ide-pmac here vs. something like pcmcia IDE cards... do you have one > > of > > > these to test with ? > > > > Nope and I really don't intend to have one. I count on other people > > to take some care of support for host drivers that they > > maintain/use. ;) > > Hrm... that's not a very sane approach. You have some infrastructure for > adding / removing devices, in fact changes things in that area even, and There seems to be some confusion between warm-plugging of IDE devices and hot-plugging of IDE devices. > not a single piece of HW to exercise those code path ? I don't ask you > to get a powermac with a media-bay, but ide_cs seems to be a pretty > important one that's part of what the ide maintainer should take care > of... And I suspect it's going to exercise the same code path as > mediabay. I'm open for offers of co-maintaince of the code (which includes taking over particular host drivers) and since you seem to have pretty good insight into what ide maintainer should be doing I presume that you want to be added to MAINTAINERS? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Wednesday 30 July 2008, Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-29 at 21:26 +0200, Bartlomiej Zolnierkiewicz wrote:
>
> > I WON!!!
>
> Only half...
Heh, I wasn't talking about fixing the issue...
(hint: look up the author of the bad commit).
> It goes further and then blows up again. First problem is, this
> unregister interface doesn't quite convey the fact that the HW is gone
> and the IDE code seems to take it's sweet time figuring it out after
> trying some requests. Maybe something smarter can be done here ? ie,
> ide_set_interface_dead() :-)
Sure, it would be great to have controller hotplug working reliably
one day but the recent patches shouldn't really be making things worse
(quite the contrary) so I would prefer to find and learn more about
the cause of regression first.
[ However nothing prevents us from improving the hotplug support in
parallel to fixing the issue so if you have some ideas that could
be conveyed in form of patches please go ahead. ]
> mediabay0: switching to 7
> mediabay0: powering down
> media bay 0 is empty
> hdc: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hdc: status error: status=0x00 { }
> ide: failed opcode was: unknown
>
> Then after this couple of failed attempts at sending commands, it
> crashes with the backtrace below. Another NULL dereference apparently,
> though the DAR value (the faulting address) has been slightly different
> between consecutive tests so it may be a use-after-free too.
Is it actually caused by additional reference counting on drive->gendev?
IOW if you reverse the patch below instead of applying the previous fix
do things work OK again?
> Note that there shouldn't be anything fundamentally different from
> ide-pmac here vs. something like pcmcia IDE cards... do you have one of
> these to test with ?
Nope and I really don't intend to have one. I count on other people
to take some care of support for host drivers that they maintain/use. ;)
Thanks,
Bart
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 4e73aee..8f253e5 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -57,23 +57,29 @@ static DEFINE_MUTEX(idecd_ref_mutex);
#define ide_cd_g(disk) \
container_of((disk)->private_data, struct cdrom_info, driver)
+static void ide_cd_release(struct kref *);
+
static struct cdrom_info *ide_cd_get(struct gendisk *disk)
{
struct cdrom_info *cd = NULL;
mutex_lock(&idecd_ref_mutex);
cd = ide_cd_g(disk);
- if (cd)
+ if (cd) {
kref_get(&cd->kref);
+ if (ide_device_get(cd->drive)) {
+ kref_put(&cd->kref, ide_cd_release);
+ cd = NULL;
+ }
+ }
mutex_unlock(&idecd_ref_mutex);
return cd;
}
-static void ide_cd_release(struct kref *);
-
static void ide_cd_put(struct cdrom_info *cd)
{
mutex_lock(&idecd_ref_mutex);
+ ide_device_put(cd->drive);
kref_put(&cd->kref, ide_cd_release);
mutex_unlock(&idecd_ref_mutex);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Tuesday 29 July 2008, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 29 July 2008, Bartlomiej Zolnierkiewicz wrote:
> > On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote:
> > > On Tue, 2008-07-29 at 13:41 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > Well, all I do is call into Bart's new helpers to scan for or
> > > > unregister
> > > > > devices ...
> > > >
> > > > The switch to these helpers happened _before_ 2.6.26 and it shouldn't
> > > > bring
> > > > such behavior change (ditto for new IDE host addition/removal
> > > > helpers)...
> > > >
> > > > Please try to git-bisect it when you have some time.
> > >
> > > Ok, I will. I worked fine when I last tried your patches. I'll see if I
> > > can track it down too. Been a bit too busy lately as you can imagine.
> > >
> > > Do you have something that exercise the same code path you can use ?
> >
> > I'll see if I can reproduce it with IDE warm-plug support later...
>
> OK, I reproduced it here with IDE warm-plug support
> (echo -n "1" > /sys/class/ide_port/ide*/delete_devices)
> for devices driven by ide-cd.
>
> It is also reproducible under qemu so I'm scripting it
> into git-bisect run now...
I WON!!!
From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Subject: [PATCH] ide: fix regression caused by ide_device_{get,put}() addition
On Monday 28 July 2008, Benjamin Herrenschmidt wrote:
[...]
> Vector: 300 (Data Access) at [c58b7b80]
> pc: c014f264: elv_may_queue+0x10/0x44
> lr: c0152750: get_request+0x2c/0x2c0
> sp: c58b7c30
>msr: 1032
>dar: c
> dsisr: 4000
> current = 0xc58aaae0
> pid = 854, comm = media-bay
> enter ? for help
> mon> t
> [c58b7c40] c0152750 get_request+0x2c/0x2c0
> [c58b7c70] c0152a08 get_request_wait+0x24/0xec
> [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0
> [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc
> [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0
> [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c
> [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8
> [c58b7e50] c022395c ide_cd_release+0x80/0x84
> [c58b7e70] c0163650 kref_put+0x54/0x6c
> [c58b7e80] c0223884 ide_cd_put+0x40/0x5c
> [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c
> [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4
> [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44
> [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8
> [c58b7f00] c01e7424 device_del+0x104/0x198
> [c58b7f20] c01e74d0 device_unregister+0x18/0x30
> [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88
> [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80
> [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0
> [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc
> [c58b7fd0] c00485c0 kthread+0x48/0x84
> [c58b7ff0] c0011b20 kernel_thread+0x44/0x60
The guilty commit turned out to be 08da591e14cf87247ec09b17c350235157a92fc3
("ide: add ide_device_{get,put}() helpers"). ide_device_put() is called
before kref_put() in ide_cd_put() so IDE device is already gone by the time
ide_cd_release() is reached.
Fix it by calling ide_device_get() before kref_get() and ide_device_put()
after kref_put() in all affected device drivers.
Reported-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: FUJITA Tomonori <[EMAIL PROTECTED]>
Cc: Borislav Petkov <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-cd.c | 10 +-
drivers/ide/ide-disk.c |9 -
drivers/ide/ide-floppy.c |9 -
drivers/ide/ide-tape.c |9 -
drivers/scsi/ide-scsi.c |9 -
5 files changed, 21 insertions(+), 25 deletions(-)
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -66,11 +66,11 @@ static struct cdrom_info *ide_cd_get(str
mutex_lock(&idecd_ref_mutex);
cd = ide_cd_g(disk);
if (cd) {
- kref_get(&cd->kref);
- if (ide_device_get(cd->drive)) {
- kref_put(&cd->kref, ide_cd_release);
+ if (ide_device_get(cd->drive))
cd = NULL;
- }
+ else
+ kref_get(&cd->kref);
+
}
mutex_unlock(&idecd_ref_mutex);
return cd;
@@ -79,8 +79,8 @@ static struct cdrom_info *ide_cd_get(str
static void ide_cd_put(struct cdrom_info *cd)
{
mutex_lock(&idecd_ref_mutex);
- ide_device_put(cd->drive);
kref_put(&cd->kref, ide_cd_release);
+ ide_device_put(cd-
Re: ide pmac breakage
On Tuesday 29 July 2008, Bartlomiej Zolnierkiewicz wrote: > On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote: > > On Tue, 2008-07-29 at 13:41 +0200, Bartlomiej Zolnierkiewicz wrote: > > > > Well, all I do is call into Bart's new helpers to scan for or > > > unregister > > > > devices ... > > > > > > The switch to these helpers happened _before_ 2.6.26 and it shouldn't > > > bring > > > such behavior change (ditto for new IDE host addition/removal > > > helpers)... > > > > > > Please try to git-bisect it when you have some time. > > > > Ok, I will. I worked fine when I last tried your patches. I'll see if I > > can track it down too. Been a bit too busy lately as you can imagine. > > > > Do you have something that exercise the same code path you can use ? > > I'll see if I can reproduce it with IDE warm-plug support later... OK, I reproduced it here with IDE warm-plug support (echo -n "1" > /sys/class/ide_port/ide*/delete_devices) for devices driven by ide-cd. It is also reproducible under qemu so I'm scripting it into git-bisect run now... Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote: > On Tue, 2008-07-29 at 13:41 +0200, Bartlomiej Zolnierkiewicz wrote: > > > Well, all I do is call into Bart's new helpers to scan for or > > unregister > > > devices ... > > > > The switch to these helpers happened _before_ 2.6.26 and it shouldn't > > bring > > such behavior change (ditto for new IDE host addition/removal > > helpers)... > > > > Please try to git-bisect it when you have some time. > > Ok, I will. I worked fine when I last tried your patches. I'll see if I > can track it down too. Been a bit too busy lately as you can imagine. > > Do you have something that exercise the same code path you can use ? I'll see if I can reproduce it with IDE warm-plug support later... Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote: > On Tue, 2008-07-29 at 14:17 +0900, FUJITA Tomonori wrote: > > If q->elevator is NULL, the media-bay code might mess up the ref > > counting of the request queue... > > Well, all I do is call into Bart's new helpers to scan for or unregister > devices ... The switch to these helpers happened _before_ 2.6.26 and it shouldn't bring such behavior change (ditto for new IDE host addition/removal helpers)... Please try to git-bisect it when you have some time. Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Monday 28 July 2008, Benjamin Herrenschmidt wrote: > On Mon, 2008-07-28 at 11:29 +1000, Benjamin Herrenschmidt wrote: > > The current ide-pmac upstream is broken. It calls > > media_bay_set_ide_infos() with an uninitialized "hwif" argument. > > > > It's not a trivial mistake, there's a chicken-and-egg problem in the > > init code in there. > > > > I've locally fixed it with this patch that i'll merge via the powerpc > > tree unless you have an objection. Fine with me (you may add my ACK) and thanks for fixing it. > > However, the machine crashes when removing the media-bay CD-ROM drive. > > > > Crash appears to be a NULL deref, possibly in elv_may_queue() though > > I don't have a clean backtrace yet, working on it... I wonder whether conversion from on-stack struct requests to allocated ones may have something to do with it (or not?)... > Here's a backtrace: > > Vector: 300 (Data Access) at [c58b7b80] > pc: c014f264: elv_may_queue+0x10/0x44 > lr: c0152750: get_request+0x2c/0x2c0 > sp: c58b7c30 >msr: 1032 >dar: c > dsisr: 4000 > current = 0xc58aaae0 > pid = 854, comm = media-bay > enter ? for help > mon> t > [c58b7c40] c0152750 get_request+0x2c/0x2c0 > [c58b7c70] c0152a08 get_request_wait+0x24/0xec > [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0 > [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc > [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0 > [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c > [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8 > [c58b7e50] c022395c ide_cd_release+0x80/0x84 > [c58b7e70] c0163650 kref_put+0x54/0x6c > [c58b7e80] c0223884 ide_cd_put+0x40/0x5c > [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c > [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4 > [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44 > [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8 > [c58b7f00] c01e7424 device_del+0x104/0x198 > [c58b7f20] c01e74d0 device_unregister+0x18/0x30 > [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88 > [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80 > [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0 > [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc > [c58b7fd0] c00485c0 kthread+0x48/0x84 > [c58b7ff0] c0011b20 kernel_thread+0x44/0x60 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: manual merge of the powerpc tree
Hi,
On Monday 07 July 2008, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in
> drivers/macintosh/mediabay.c between commit
> 7ad963b103d3863b1161c59f3e65a435979804ed ("ide-pmac: media-bay support
> fixes (take 4)") from the ide tree and commit
> 9a24729d8aeef967eac7af71c6a69edc83d06558 ("macintosh/media bay: Convert
> semaphore to mutex") from the powerpc tree.
Since I haven't heard back from Ben [1] on ide-pmac/media-bay IRQ issue
I took another look at ide-pmac patches and I think that it should be
possible to rework them in such way that consecutive ide patches (> 100)
won't depend on "ide-pmac: media-bay support fixes (take 4)" patch.
This would allow us to re-schedule it to 2.6.28 (which is probably what
we want because 2.6.26 is probably just around the corner and we will be
pretty busy with 2.6.27 merge window soon). Ben, what's your opinion?
[1] which doesn't surprise me given his new responsibilities ;)
Thanks,
Bart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/7] ide-pmac: move ide_find_port() call to pmac_ide_setup_device()
Move ide_find_port() call to pmac_ide_setup_device().
While at it:
- fix return value (s/-ENODEV/-ENOENT/)
- add DRV_NAME define and use it to set name field of pmac_port_info
- use ide_find_port_slot() instead of ide_find_port()
- remove superfluous error message (ide_find_port_slot() takes care of it)
- drop IDE interface number from driver banner message (but include bus type)
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ppc/pmac.c | 42 --
1 file changed, 16 insertions(+), 26 deletions(-)
Index: b/drivers/ide/ppc/pmac.c
===
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -48,6 +48,8 @@
#include
#endif
+#define DRV_NAME "ide-pmac"
+
#undef IDE_PMAC_DEBUG
#define DMA_WAIT_TIMEOUT 50
@@ -982,6 +984,7 @@ static const struct ide_port_ops pmac_id
static const struct ide_dma_ops pmac_dma_ops;
static const struct ide_port_info pmac_port_info = {
+ .name = DRV_NAME,
.init_dma = pmac_ide_init_dma,
.chipset= ide_pmac,
#ifdef CONFIG_BLK_DEV_IDEDMA_PMAC
@@ -1000,11 +1003,11 @@ static const struct ide_port_info pmac_p
* Setup, register & probe an IDE channel driven by this driver, this is
* called by one of the 2 probe functions (macio or PCI).
*/
-static int __devinit
-pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif, hw_regs_t *hw)
+static int __devinit pmac_ide_setup_device(pmac_ide_hwif_t *pmif, hw_regs_t
*hw)
{
struct device_node *np = pmif->node;
const int *bidp;
+ ide_hwif_t *hwif;
u8 idx[4] = { 0xff, 0xff, 0xff, 0xff };
struct ide_port_info d = pmac_port_info;
@@ -1073,16 +1076,21 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
msleep(jiffies_to_msecs(IDE_WAKEUP_DELAY));
}
+ printk(KERN_INFO DRV_NAME ": Found Apple %s controller (%s), "
+"bus ID %d%s, irq %d\n", model_name[pmif->kind],
+pmif->mdev ? "MacIO" : "PCI", pmif->aapl_bus_id,
+pmif->mediabay ? " (mediabay)" : "", hw.irq);
+
+ hwif = ide_find_port_slot(&d);
+ if (hwif == NULL)
+ return -ENOENT;
+
/* Setup MMIO ops */
default_hwif_mmiops(hwif);
hwif->OUTBSYNC = pmac_outbsync;
ide_init_port_hw(hwif, hw);
- printk(KERN_INFO "ide%d: Found Apple %s controller, bus ID %d%s, irq
%d\n",
- hwif->index, model_name[pmif->kind], pmif->aapl_bus_id,
- pmif->mediabay ? " (mediabay)" : "", hwif->irq);
-
idx[0] = hwif->index;
ide_device_add(idx, &d);
@@ -1112,7 +1120,6 @@ pmac_ide_macio_attach(struct macio_dev *
{
void __iomem *base;
unsigned long regbase;
- ide_hwif_t *hwif;
pmac_ide_hwif_t *pmif;
int irq, rc;
hw_regs_t hw;
@@ -1121,14 +1128,6 @@ pmac_ide_macio_attach(struct macio_dev *
if (pmif == NULL)
return -ENOMEM;
- hwif = ide_find_port();
- if (hwif == NULL) {
- printk(KERN_ERR "ide-pmac: MacIO interface attach with no
slot\n");
- printk(KERN_ERR " %s\n", mdev->ofdev.node->full_name);
- rc = -ENODEV;
- goto out_free_pmif;
- }
-
if (macio_resource_count(mdev) == 0) {
printk(KERN_WARNING "ide-pmac: no address for %s\n",
mdev->ofdev.node->full_name);
@@ -1183,7 +1182,7 @@ pmac_ide_macio_attach(struct macio_dev *
hw.dev = &mdev->bus->pdev->dev;
hw.parent = &mdev->ofdev.dev;
- rc = pmac_ide_setup_device(pmif, hwif, &hw);
+ rc = pmac_ide_setup_device(pmif, &hw);
if (rc != 0) {
/* The inteface is released to the common IDE layer */
dev_set_drvdata(&mdev->ofdev.dev, NULL);
@@ -1242,7 +1241,6 @@ pmac_ide_macio_resume(struct macio_dev *
static int __devinit
pmac_ide_pci_attach(struct pci_dev *pdev, const struct pci_device_id *id)
{
- ide_hwif_t *hwif;
struct device_node *np;
pmac_ide_hwif_t *pmif;
void __iomem *base;
@@ -1260,14 +1258,6 @@ pmac_ide_pci_attach(struct pci_dev *pdev
if (pmif == NULL)
return -ENOMEM;
- hwif = ide_find_port();
- if (hwif == NULL) {
- printk(KERN_ERR "ide-pmac: PCI interface attach with no
slot\n");
- printk(KERN_ERR " %s\n", np->full_name);
- rc = -ENODEV;
- goto out_free_pmif;
- }
-
[PATCH 6/7] ide-pmac: add ->init_dev method
There should be no functional changes caused by this patch.
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ppc/pmac.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
Index: b/drivers/ide/ppc/pmac.c
===
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -941,7 +941,23 @@ static u8 pmac_ide_cable_detect(ide_hwif
return ATA_CBL_PATA40;
}
+static void pmac_ide_init_dev(ide_drive_t *drive)
+{
+ ide_hwif_t *hwif = drive->hwif;
+ pmac_ide_hwif_t *pmif =
+ (pmac_ide_hwif_t *)drv_get_drvdata(hwif->gendev.parent);
+
+ if (pmif->mediabay) {
+#ifdef CONFIG_PMAC_MEDIABAY
+ if (check_media_bay(np->parent, MB_CD) == -ENODEV)
+ return;
+#endif
+ drive->noprobe = 1;
+ }
+}
+
static const struct ide_port_ops pmac_ide_ata6_port_ops = {
+ .init_dev = pmac_ide_init_dev,
.set_pio_mode = pmac_ide_set_pio_mode,
.set_dma_mode = pmac_ide_set_dma_mode,
.selectproc = pmac_ide_kauai_selectproc,
@@ -949,6 +965,7 @@ static const struct ide_port_ops pmac_id
};
static const struct ide_port_ops pmac_ide_ata4_port_ops = {
+ .init_dev = pmac_ide_init_dev,
.set_pio_mode = pmac_ide_set_pio_mode,
.set_dma_mode = pmac_ide_set_dma_mode,
.selectproc = pmac_ide_selectproc,
@@ -956,6 +973,7 @@ static const struct ide_port_ops pmac_id
};
static const struct ide_port_ops pmac_ide_port_ops = {
+ .init_dev = pmac_ide_init_dev,
.set_pio_mode = pmac_ide_set_pio_mode,
.set_dma_mode = pmac_ide_set_dma_mode,
.selectproc = pmac_ide_selectproc,
@@ -1065,15 +1083,6 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
hwif->index, model_name[pmif->kind], pmif->aapl_bus_id,
pmif->mediabay ? " (mediabay)" : "", hwif->irq);
- if (pmif->mediabay) {
-#ifdef CONFIG_PMAC_MEDIABAY
- if (check_media_bay(np->parent, MB_CD) == -ENODEV)
- break;
-#endif
- hwif->drives[0].noprobe = 1;
- hwif->drives[1].noprobe = 1;
- }
-
idx[0] = hwif->index;
ide_device_add(idx, &d);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/7] ide-pmac: store pmif instead of hwif in ->driver_data
* Pass pmif instead of hwif to pmac_ide_do_{suspend,resume}().
* Store pmif instead of hwif in ->driver_data.
* Use dev_get_drvdata() instead of ->hwif_data to obtain pmif.
There should be no functional changes caused by this patch.
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ppc/pmac.c | 93 -
1 file changed, 55 insertions(+), 38 deletions(-)
Index: b/drivers/ide/ppc/pmac.c
===
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -424,7 +424,9 @@ static void pmac_ide_kauai_selectproc(id
static void
pmac_ide_selectproc(ide_drive_t *drive)
{
- pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t *)HWIF(drive)->hwif_data;
+ ide_hwif_t *hwif = drive->hwif;
+ pmac_ide_hwif_t *pmif =
+ (pmac_ide_hwif_t *)dev_get_drvdata(hwif->gendev.parent);
if (pmif == NULL)
return;
@@ -444,7 +446,9 @@ pmac_ide_selectproc(ide_drive_t *drive)
static void
pmac_ide_kauai_selectproc(ide_drive_t *drive)
{
- pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t *)HWIF(drive)->hwif_data;
+ ide_hwif_t *hwif = drive->hwif;
+ pmac_ide_hwif_t *pmif =
+ (pmac_ide_hwif_t *)dev_get_drvdata(hwif->gendev.parent);
if (pmif == NULL)
return;
@@ -465,7 +469,9 @@ pmac_ide_kauai_selectproc(ide_drive_t *d
static void
pmac_ide_do_update_timings(ide_drive_t *drive)
{
- pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t *)HWIF(drive)->hwif_data;
+ ide_hwif_t *hwif = drive->hwif;
+ pmac_ide_hwif_t *pmif =
+ (pmac_ide_hwif_t *)dev_get_drvdata(hwif->gendev.parent);
if (pmif == NULL)
return;
@@ -493,11 +499,13 @@ static void pmac_outbsync(ide_hwif_t *hw
static void
pmac_ide_set_pio_mode(ide_drive_t *drive, const u8 pio)
{
+ ide_hwif_t *hwif = drive->hwif;
+ pmac_ide_hwif_t *pmif =
+ (pmac_ide_hwif_t *)dev_get_drvdata(hwif->gendev.parent);
struct ide_timing *tim = ide_timing_find_mode(XFER_PIO_0 + pio);
u32 *timings, t;
unsigned accessTicks, recTicks;
unsigned accessTime, recTime;
- pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t *)HWIF(drive)->hwif_data;
unsigned int cycle_time;
if (pmif == NULL)
@@ -778,9 +786,11 @@ set_timings_mdma(ide_drive_t *drive, int
static void pmac_ide_set_dma_mode(ide_drive_t *drive, const u8 speed)
{
+ ide_hwif_t *hwif = drive->hwif;
+ pmac_ide_hwif_t *pmif =
+ (pmac_ide_hwif_t *)dev_get_drvdata(hwif->gendev.parent);
int unit = (drive->select.b.unit & 0x01);
int ret = 0;
- pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t *)HWIF(drive)->hwif_data;
u32 *timings, *timings2, tl[2];
timings = &pmif->timings[unit];
@@ -852,11 +862,8 @@ sanitize_timings(pmac_ide_hwif_t *pmif)
/* Suspend call back, should be called after the child devices
* have actually been suspended
*/
-static int
-pmac_ide_do_suspend(ide_hwif_t *hwif)
+static int pmac_ide_do_suspend(pmac_ide_hwif_t *pmif)
{
- pmac_ide_hwif_t *pmif = (pmac_ide_hwif_t *)hwif->hwif_data;
-
/* We clear the timings */
pmif->timings[0] = 0;
pmif->timings[1] = 0;
@@ -884,11 +891,8 @@ pmac_ide_do_suspend(ide_hwif_t *hwif)
/* Resume call back, should be called before the child devices
* are resumed
*/
-static int
-pmac_ide_do_resume(ide_hwif_t *hwif)
+static int pmac_ide_do_resume(pmac_ide_hwif_t *pmif)
{
- pmac_ide_hwif_t *pmif = (pmac_ide_hwif_t *)hwif->hwif_data;
-
/* Hard reset & re-enable controller (do we really need to reset ?
-BenH) */
if (!pmif->mediabay) {
ppc_md.feature_call(PMAC_FTR_IDE_RESET, pmif->node,
pmif->aapl_bus_id, 1);
@@ -916,7 +920,8 @@ pmac_ide_do_resume(ide_hwif_t *hwif)
static u8 pmac_ide_cable_detect(ide_hwif_t *hwif)
{
- pmac_ide_hwif_t *pmif = (pmac_ide_hwif_t *)ide_get_hwifdata(hwif);
+ pmac_ide_hwif_t *pmif =
+ (pmac_ide_hwif_t *)drv_get_drvdata(hwif->gendev.parent);
struct device_node *np = pmif->node;
const char *cable = of_get_property(np, "cable-type", NULL);
@@ -1054,7 +1059,6 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
default_hwif_mmiops(hwif);
hwif->OUTBSYNC = pmac_outbsync;
- hwif->hwif_data = pmif;
ide_init_port_hw(hwif, hw);
printk(KERN_INFO "ide%d: Found Apple %s controller, bus ID %d%s, irq
%d\n",
@@ -1162,7 +1166,7 @@ pmac_ide_macio_attach(struct macio_dev *
} else
pmif->dma_regs = NULL;
#endif /* CONFIG_BLK_DEV_IDEDMA_PMAC */
- dev_set_drvdata(&mdev->ofdev.dev, hwif);
+ dev_
[PATCH 4/7] ide-pmac: media-bay support fixes
* If MB_CD device has already been detected and bay is in mb_up state just
change bay's state to mb_ide_resetting and let probing thread do the rest
instead of having open-coded waiting for IDE device to become ready in
media_bay_set_ide_infos() and doing the probe by ide_device_add().
* Move media_bay_set_ide_infos() call after ide_device_add().
* Use check_media_bay() instead of check_media_bay_by_base(),
then remove the latter function.
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ppc/pmac.c | 18 --
drivers/macintosh/mediabay.c | 33 +
include/asm-powerpc/mediabay.h |1 -
3 files changed, 13 insertions(+), 39 deletions(-)
Index: b/drivers/ide/ppc/pmac.c
===
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -1030,10 +1030,6 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
/* XXX FIXME: Media bay stuff need re-organizing */
if (np->parent && np->parent->name
&& strcasecmp(np->parent->name, "media-bay") == 0) {
-#ifdef CONFIG_PMAC_MEDIABAY
- media_bay_set_ide_infos(np->parent, pmif->regbase, pmif->irq,
- hwif);
-#endif /* CONFIG_PMAC_MEDIABAY */
pmif->mediabay = 1;
if (!bidp)
pmif->aapl_bus_id = 1;
@@ -1067,19 +1063,21 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
if (pmif->mediabay) {
#ifdef CONFIG_PMAC_MEDIABAY
- if (check_media_bay_by_base(pmif->regbase, MB_CD)) {
-#else
- if (1) {
+ if (check_media_bay(np->parent, MB_CD) == -ENODEV)
+ break;
#endif
- hwif->drives[0].noprobe = 1;
- hwif->drives[1].noprobe = 1;
- }
+ hwif->drives[0].noprobe = 1;
+ hwif->drives[1].noprobe = 1;
}
idx[0] = hwif->index;
ide_device_add(idx, &d);
+#ifdef CONFIG_PMAC_MEDIABAY
+ media_bay_set_ide_infos(np->parent, pmif->regbase, pmif->irq, hwif);
+#endif
+
return 0;
}
Index: b/drivers/macintosh/mediabay.c
===
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -433,21 +433,6 @@ int check_media_bay(struct device_node *
EXPORT_SYMBOL(check_media_bay);
#ifdef CONFIG_BLK_DEV_IDE_PMAC
-int check_media_bay_by_base(unsigned long base, int what)
-{
- int i;
-
- for (i=0; imdev && which_bay == bay->mdev->ofdev.node) {
- int timeout = 5000, index = hwif->index;
-
down(&bay->lock);
bay->cd_port= hwif;
@@ -469,18 +452,12 @@ int media_bay_set_ide_infos(struct devic
up(&bay->lock);
return 0;
}
- printk(KERN_DEBUG "Registered ide%d for media bay
%d\n", index, i);
- do {
- if (MB_IDE_READY(i)) {
- bay->cd_index = index;
- up(&bay->lock);
- return 0;
- }
- mdelay(1);
- } while(--timeout);
- printk(KERN_DEBUG "Timeount waiting IDE in bay %d\n",
i);
+
+ /* let probing thread do the rest */
+ bay->state = mb_ide_resetting;
+
up(&bay->lock);
- return -ENODEV;
+ return 0;
}
}
Index: b/include/asm-powerpc/mediabay.h
===
--- a/include/asm-powerpc/mediabay.h
+++ b/include/asm-powerpc/mediabay.h
@@ -25,7 +25,6 @@ extern int media_bay_count;
#ifdef CONFIG_BLK_DEV_IDE_PMAC
#include
-int check_media_bay_by_base(unsigned long base, int what);
/* called by IDE PMAC host driver to register IDE controller for media bay */
int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base,
int irq, ide_hwif_t *hwif);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/7] ide-pmac: remove bogus comment about pmac_ide_setup_device()
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- drivers/ide/ppc/pmac.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) Index: b/drivers/ide/ppc/pmac.c === --- a/drivers/ide/ppc/pmac.c +++ b/drivers/ide/ppc/pmac.c @@ -975,10 +975,7 @@ static const struct ide_port_info pmac_p /* * Setup, register & probe an IDE channel driven by this driver, this is - * called by one of the 2 probe functions (macio or PCI). Note that a channel - * that ends up beeing free of any device is not kept around by this driver - * (it is kept in 2.4). This introduce an interface numbering change on some - * rare machines unfortunately, but it's better this way. + * called by one of the 2 probe functions (macio or PCI). */ static int __devinit pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif, hw_regs_t *hw) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/7] ide-pmac: add ->cable_detect method
Add ->cable_detect method and remove no longer needed pmif->cable_80 flag
(there is also no need to mask ->udma_mask now).
This fixes:
- forced ignoring of cable detection (needed for some CF devices & debug)
- cable detection for warm-plug
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ppc/pmac.c | 55 +++--
1 file changed, 31 insertions(+), 24 deletions(-)
Index: b/drivers/ide/ppc/pmac.c
===
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -57,7 +57,6 @@ typedef struct pmac_ide_hwif {
int irq;
int kind;
int aapl_bus_id;
- unsignedcable_80 : 1;
unsignedmediabay : 1;
unsignedbroken_dma : 1;
unsignedbroken_dma_warn : 1;
@@ -915,10 +914,40 @@ pmac_ide_do_resume(ide_hwif_t *hwif)
return 0;
}
+static u8 pmac_ide_cable_detect(ide_hwif_t *hwif)
+{
+ pmac_ide_hwif_t *pmif = (pmac_ide_hwif_t *)ide_get_hwifdata(hwif);
+ struct device_node *np = pmif->node;
+ const char *cable = of_get_property(np, "cable-type", NULL);
+
+ /* Get cable type from device-tree. */
+ if (cable && !strncmp(cable, "80-", 3))
+ return ATA_CBL_PATA80;
+
+ /*
+* G5's seem to have incorrect cable type in device-tree.
+* Let's assume they have a 80 conductor cable, this seem
+* to be always the case unless the user mucked around.
+*/
+ if (of_device_is_compatible(np, "K2-UATA") ||
+ of_device_is_compatible(np, "shasta-ata"))
+ return ATA_CBL_PATA80;
+
+ return ATA_CBL_PATA40;
+}
+
static const struct ide_port_ops pmac_ide_ata6_port_ops = {
.set_pio_mode = pmac_ide_set_pio_mode,
.set_dma_mode = pmac_ide_set_dma_mode,
.selectproc = pmac_ide_kauai_selectproc,
+ .cable_detect = pmac_ide_cable_detect,
+};
+
+static const struct ide_port_ops pmac_ide_ata4_port_ops = {
+ .set_pio_mode = pmac_ide_set_pio_mode,
+ .set_dma_mode = pmac_ide_set_dma_mode,
+ .selectproc = pmac_ide_selectproc,
+ .cable_detect = pmac_ide_cable_detect,
};
static const struct ide_port_ops pmac_ide_port_ops = {
@@ -959,7 +988,6 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
u8 idx[4] = { 0xff, 0xff, 0xff, 0xff };
struct ide_port_info d = pmac_port_info;
- pmif->cable_80 = 0;
pmif->broken_dma = pmif->broken_dma_warn = 0;
if (of_device_is_compatible(np, "shasta-ata")) {
pmif->kind = controller_sh_ata6;
@@ -976,6 +1004,7 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
} else if (of_device_is_compatible(np, "keylargo-ata")) {
if (strcmp(np->name, "ata-4") == 0) {
pmif->kind = controller_kl_ata4;
+ d.port_ops = &pmac_ide_ata4_port_ops;
d.udma_mask = ATA_UDMA4;
} else
pmif->kind = controller_kl_ata3;
@@ -989,22 +1018,6 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
bidp = of_get_property(np, "AAPL,bus-id", NULL);
pmif->aapl_bus_id = bidp ? *bidp : 0;
- /* Get cable type from device-tree */
- if (pmif->kind == controller_kl_ata4 || pmif->kind == controller_un_ata6
- || pmif->kind == controller_k2_ata6
- || pmif->kind == controller_sh_ata6) {
- const char* cable = of_get_property(np, "cable-type", NULL);
- if (cable && !strncmp(cable, "80-", 3))
- pmif->cable_80 = 1;
- }
- /* G5's seem to have incorrect cable type in device-tree. Let's assume
-* they have a 80 conductor cable, this seem to be always the case
unless
-* the user mucked around
-*/
- if (of_device_is_compatible(np, "K2-UATA") ||
- of_device_is_compatible(np, "shasta-ata"))
- pmif->cable_80 = 1;
-
/* On Kauai-type controllers, we make sure the FCR is correct */
if (pmif->kauai_fcr)
writel(KAUAI_FCR_UATA_MAGIC |
@@ -1050,7 +1063,6 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
hwif->hwif_data = pmif;
ide_init_port_hw(hwif, hw);
- hwif->cbl = pmif->cable_80 ? ATA_CBL_PATA80 : ATA_CBL_PATA40;
printk(KERN_INFO "ide%d: Found Apple %s controller, bus ID %d%s, irq
%d\n",
[PATCH 1/7] ide-pmac: bugfix for media-bay support rework
Fix bug introduced by:
commit 2dde7861afa23cd59db83515cb0b810b92b220aa
Author: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Date: Fri Apr 18 00:46:23 2008 +0200
ide: rework PowerMac media-bay support (take 2)
...
[ Yeah, I suck. ]
bay->cd_index shouldn't be changed if IDE devices are not present
or retry operations won't happen.
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
first three patches are meant for 2.6.26, the rest for 2.6.27
drivers/macintosh/mediabay.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: b/drivers/macintosh/mediabay.c
===
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -556,7 +556,8 @@ static void media_bay_step(int i)
printk("mediabay %d, registering IDE...\n", i);
pmu_suspend();
ide_port_scan(bay->cd_port);
- bay->cd_index = bay->cd_port->index;
+ if (bay->cd_port->present)
+ bay->cd_index = bay->cd_port->index;
pmu_resume();
}
if (bay->cd_index == -1) {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [IDE] alim15x3: disable init_hwif_ali15x3 for PowerPC
On Tuesday 29 April 2008, Anton Vorontsov wrote: > We don't need init_hwif_ali15x3() on the PowerPC systems either. > > Before: > > ALI15X3: IDE controller (0x10b9:0x5229 rev 0xc8) at PCI slot 0001:03:1f.0 > ALI15X3: 100% native mode on irq 19 > ide0: BM-DMA at 0x1120-0x1127 > ide1: BM-DMA at 0x1128-0x112f > hda: SONY DVD RW AW-Q170A, ATAPI CD/DVD-ROM drive > hda: UDMA/66 mode selected > ide0: Disabled unable to get IRQ 14. > ide0: failed to initialize IDE interface > ide1: Disabled unable to get IRQ 15. > ide1: failed to initialize IDE interface > > After: > > ALI15X3: IDE controller (0x10b9:0x5229 rev 0xc8) at PCI slot 0001:03:1f.0 > ALI15X3: 100% native mode on irq 19 > ide0: BM-DMA at 0x1120-0x1127 > ide1: BM-DMA at 0x1128-0x112f > hda: SONY DVD RW AW-Q170A, ATAPI CD/DVD-ROM drive > hda: UDMA/66 mode selected > ide0 at 0x1100-0x1107,0x110a on irq 19 > ide1 at 0x1110-0x1117,0x111a on irq 19 > hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache > > ide0 works well, though I can't test ide1, it isn't traced out on > the board. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> applied, thanks ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ide: make ide_pci_check_iomem() actually work
On Wednesday 09 April 2008, Bartlomiej Zolnierkiewicz wrote: > > [ added Akira & Kou to cc: ] > > On Tuesday 08 April 2008, Sergei Shtylyov wrote: > > Hi, I just wrote: > > > > >>> This function didn't actually check if a given BAR is in I/O space > > >>> because of > > >>> using the bogus PCI_BASE_ADDRESS_IO_MASK (which equals ~3) to test > > >>> the resource > > >>> flags instead of IORESOURCE_IO -- fix this, make ide_hwif_configure() > > >>> check the > > >>> results failing if necessary, and move the printk() call to the > > >>> failure path. > > > > >> This change is OK in itself but I worry that ide_pci_check_iomem() may > > >> now > > >> return "false" errors (bogus PCI_BASE_ADDRESS_IO_MASK check resulted > > >> in MEM > > >> resources always surviving ide_pci_check_iomem() calls before the fix) > > >> for > > >> some host drivers (siimage, scc_pata...) resulting in failed > > >> initialization. > > > > >The SiI chips do have normal I/O resources at BAR0..BAR3. As for > > > scc_pata, the control should not even get there because BAR0..BAR3 are > > > *not* IDE command/control block bases on this chip (BAR0/1 are > > > control/DMA bases if you look into setup_mmio_scc()) but they are > > > treated as such by the code immediately following ide_pci_check_iomem() > > > calls in ide_hwif_configure(), i.e. we might have an error here. The > > > same can be said about the PowerMAC driver which has all its MMIO > > > registers at BAR0. > > > > >> How's about removing this dead/broken function instead for now? > > > > >If we indeed have a MMIO problem here, it's not in this function but > > > in its callers. > > > > Looks like we actually have this problem with scc_pata -- it calls > > ide_setup_pci_device() which should lead to calling ide_hwif_configure(). > > But > > this is broken since this call chain expects a normal PCI IDE controller > > with > > BAR0..BAR3 either non-existant or being primary/secondary port bases in I/O > > space. > > Yep, scc_pata needs fixing before your patch can be applied. [...] Sergei, I applied your patch just after scc_pata's one. Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] scc_pata.c: do setup itself instead of ide_setup_pci_device ()
On Tuesday 15 April 2008, Akira Iguchi wrote: > scc_pata has the different BAR configuration and using ide_setup_pci_device() > is inappropriate. > (ide_setup_pci_device() expects a normal PCI IDE controller with > BAR0..BAR3 either non-existant or being primary/secondary port bases > in I/O space.) > > This patch do all needed setup itself instead of calling > ide_setup_pci_device(). > > Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]> > Signed-off-by: Akira Iguchi <[EMAIL PROTECTED]> Thanks for quickly handling it, applied. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] siimage: fix kernel oops on PPC 44x
On Tuesday 08 April 2008, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> >>Fix kernel oops due to machine check occuring in init_chipset_siimage() on
> >>PPC
> >>44x platforms. These 32-bit CPUs have 36-bit physical address and PCI I/O
> >>and
> >>memory spaces are mapped beyond 4 GB; arch/ppc/ code has a fixup in
> >>ioremap()
> >>that creates an illusion of the PCI I/O and memory resources being mapped
> >>below
> >>4 GB, while arch/powerpc/ code got rid of this fixup with PPC 44x having
> >>instead
> >>CONFIG_RESOURCES_64BIT=y -- this causes the resources to be truncated to
> >>32-bit
> >>'unsigned long' type in this driver, and so non-existant memory being
> >>ioremap'ed
> >>and then accessed...
>
> >>Thanks to Valentine Barshak for providing an initial patch and explanations.
>
> >>Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
>
> > applied and pushed to Linus, thanks!
>
> > I guess that it would be worth to audit the rest of IDE code for
>
> Already done. Some drivers, like sgiioc4, scc_pata, and pmac are prone to
> that at least in theory. Although I doubt that they ever get used in such
> environments as PPC 44x platform kernels, i.e. 32-bit kernel and PCI mapped
> beyond 4 GB.
>
> > pci_resource_{start,end}() vs 'unsigned long' occurences and fix them.
>
> There are quite a lot of those overall but they only pose danger if the
> resource in question is in memory space since the I/O space always uses
> 'unsigned long' addresses. So, IDE core and drivers using only I/O resources
> should not be prone to that kind of issue.
Thanks for taking a look (good to hear that we are fine for now).
> > [ Even if they work at the moment they are just bugs waiting to happened
> > when we add support for some new platforms or rewrite the code... ]
I still think that it is worth to switch to always using resource_size_t
with pci_resource{start,end}() - increase of the code size should be minimal
and negligable (also it would happen only for CONFIG_RESOURCES_64BIT=y)
but in the return we will keep the code consistent and hint people who're
writing new code (and are looking at the existing code as a base).
[ this is kernel-wide comment, w.r.t. to IDE - I'll try updating it when
I have some time (unless of course somebody sends me a patch earlier :) ]
Thanks,
Bart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ide: make ide_pci_check_iomem() actually work
[ added Akira & Kou to cc: ] On Tuesday 08 April 2008, Sergei Shtylyov wrote: > Hi, I just wrote: > > >>> This function didn't actually check if a given BAR is in I/O space > >>> because of > >>> using the bogus PCI_BASE_ADDRESS_IO_MASK (which equals ~3) to test > >>> the resource > >>> flags instead of IORESOURCE_IO -- fix this, make ide_hwif_configure() > >>> check the > >>> results failing if necessary, and move the printk() call to the > >>> failure path. > > >> This change is OK in itself but I worry that ide_pci_check_iomem() may > >> now > >> return "false" errors (bogus PCI_BASE_ADDRESS_IO_MASK check resulted > >> in MEM > >> resources always surviving ide_pci_check_iomem() calls before the fix) > >> for > >> some host drivers (siimage, scc_pata...) resulting in failed > >> initialization. > > >The SiI chips do have normal I/O resources at BAR0..BAR3. As for > > scc_pata, the control should not even get there because BAR0..BAR3 are > > *not* IDE command/control block bases on this chip (BAR0/1 are > > control/DMA bases if you look into setup_mmio_scc()) but they are > > treated as such by the code immediately following ide_pci_check_iomem() > > calls in ide_hwif_configure(), i.e. we might have an error here. The > > same can be said about the PowerMAC driver which has all its MMIO > > registers at BAR0. > > >> How's about removing this dead/broken function instead for now? > > >If we indeed have a MMIO problem here, it's not in this function but > > in its callers. > > Looks like we actually have this problem with scc_pata -- it calls > ide_setup_pci_device() which should lead to calling ide_hwif_configure(). But > this is broken since this call chain expects a normal PCI IDE controller with > BAR0..BAR3 either non-existant or being primary/secondary port bases in I/O > space. Yep, scc_pata needs fixing before your patch can be applied. Looks like it just needs to do all the needed setup itself in init_setup_scc() instead of calling ide_setup_pci_device() [ similarly to how cs5520 host driver handles this in cs5520.c::cs5520_init_one() ]. PS it would be also nice to call pci_enable_device() before setup_mmio_scc() (which accesses PCI BARs, calls pci_set_master() etc.) while we are at it (driver seems to work fine without it ATM but it may break in future). Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] siimage: fix kernel oops on PPC 44x
On Monday 07 April 2008, Sergei Shtylyov wrote:
> Fix kernel oops due to machine check occuring in init_chipset_siimage() on PPC
> 44x platforms. These 32-bit CPUs have 36-bit physical address and PCI I/O and
> memory spaces are mapped beyond 4 GB; arch/ppc/ code has a fixup in ioremap()
> that creates an illusion of the PCI I/O and memory resources being mapped
> below
> 4 GB, while arch/powerpc/ code got rid of this fixup with PPC 44x having
> instead
> CONFIG_RESOURCES_64BIT=y -- this causes the resources to be truncated to
> 32-bit
> 'unsigned long' type in this driver, and so non-existant memory being
> ioremap'ed
> and then accessed...
>
> Thanks to Valentine Barshak for providing an initial patch and explanations.
>
> Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
applied and pushed to Linus, thanks!
I guess that it would be worth to audit the rest of IDE code for
pci_resource_{start,end}() vs 'unsigned long' occurences and fix them.
[ Even if they work at the moment they are just bugs waiting to happened
when we add support for some new platforms or rewrite the code... ]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 15/18] ide: remove broken/dangerous HDIO_[UNREGISTER, SCAN]_HWIF ioctls
On Friday 28 March 2008, Mark Lord wrote: > Sergei Shtylyov wrote: > > Bartlomiej Zolnierkiewicz wrote: > > > >> hdparm explicitely marks HDIO_[UNREGISTER,SCAN]_HWIF ioctls as DANGEROUS > >> and given the number of bugs we can assume that there are no real users: > .. > > There is the odd user of these, actually. > > But the most recent to email me (a few weeks ago), > reported that the SCAN function was no longer working on his kernel. > > I'll remove the -R and -U flags completely from hdparm-8.7. This will be quite helpful, thanks! Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 15/18] ide: remove broken/dangerous HDIO_[UNREGISTER, SCAN]_HWIF ioctls
On Thursday 27 March 2008, Sergei Shtylyov wrote:
[...]
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
>
> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
Thanks for reviewing it.
> > Index: b/drivers/ide/ide-pnp.c
> > ===
> > --- a/drivers/ide/ide-pnp.c
> > +++ b/drivers/ide/ide-pnp.c
> [...]
> > @@ -655,52 +530,6 @@ void ide_init_port_hw(ide_hwif_t *hwif,
> > }
> > EXPORT_SYMBOL_GPL(ide_init_port_hw);
> >
> > -/**
> > - * ide_register_hw - register IDE interface
> > - * @hw: hardware registers
> > - * @quirkproc: quirkproc function
> > - * @hwifp: pointer to returned hwif
> > - *
> > - * Register an IDE interface, specifying exactly the registers etc.
> > - *
> > - * Returns -1 on error.
> > - */
> > -
> > -static int ide_register_hw(hw_regs_t *hw, void (*quirkproc)(ide_drive_t *),
> > - ide_hwif_t **hwifp)
> > -{
> > - int index, retry = 1;
> > - ide_hwif_t *hwif;
> > - u8 idx[4] = { 0xff, 0xff, 0xff, 0xff };
> > -
> > - do {
> > - hwif = ide_find_port(hw->io_ports[IDE_DATA_OFFSET]);
> > - index = hwif->index;
> > - if (hwif)
> > - goto found;
>
> Hm, I remember there was a patch that fixed the above bug where hwif is
> dereferenced before being checked for NULL, I wonder how come it was lost?
It has been already merged into Linus' tree
(commit 0c6025d8bd688dfd351a09bc620aafa4d1ff).
Thanks,
Bart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] next-20080218 build failure at pmac_ide_macio_attach ()
On Monday 18 February 2008, Kamalesh Babulal wrote:
> Hi,
>
> The next-20080218 kernel build fails on the powerpc(s)
>
> drivers/ide/ppc/pmac.c: In function ‘pmac_ide_macio_attach’:
> drivers/ide/ppc/pmac.c:1094: error: conversion to non-scalar type requested
> drivers/ide/ppc/pmac.c: In function ‘pmac_ide_pci_attach’:
> drivers/ide/ppc/pmac.c:1232: error: conversion to non-scalar type requested
> make[3]: *** [drivers/ide/ppc/pmac.o] Error 1
> make[2]: *** [drivers/ide/ppc] Error 2
> make[1]: *** [drivers/ide] Error 2
> make: *** [drivers] Error 2
>
> I Have tested this patch for build failure only.
>
> Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]>
> ---
> --- linux-2.6.25-rc1/drivers/ide/ppc/pmac.c 2008-02-18 18:41:48.0
> +0530
> +++ linux-2.6.25-rc1/drivers/ide/ppc/~pmac.c 2008-02-18 19:20:37.0
> +0530
> @@ -1091,7 +1091,7 @@ pmac_ide_macio_attach(struct macio_dev *
> int irq, rc;
> hw_regs_t hw;
>
> - pmif = (struct pmac_ide_hwif)kzalloc(sizeof(*pmif), GFP_KERNEL);
> + pmif = (struct pmac_ide_hwif*)kzalloc(sizeof(*pmif), GFP_KERNEL);
> if (pmif == NULL)
> return -ENOMEM;
>
> @@ -1229,7 +1229,7 @@ pmac_ide_pci_attach(struct pci_dev *pdev
> return -ENODEV;
> }
>
> - pmif = (struct pmac_ide_hwif)kzalloc(sizeof(*pmif), GFP_KERNEL);
> + pmif = (struct pmac_ide_hwif*)kzalloc(sizeof(*pmif), GFP_KERNEL);
> if (pmif == NULL)
> return -ENOMEM;
>
Thanks, I integrated it with the "guilty" patch to preserve bisectability.
From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Subject: [PATCH] ide-pmac: dynamically allocate struct pmac_ide_hwif instances
(take 2)
* Dynamically allocate struct pmac_ide_hwif instances in pmac_ide_macio_attach()
and pmac_ide_pci_attach(), then remove no longer needed pmac_ide[].
v2:
* Build fix from Kamalesh Babulal.
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: Kamalesh Babulal <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ppc/pmac.c | 49 +
1 file changed, 33 insertions(+), 16 deletions(-)
Index: b/drivers/ide/ppc/pmac.c
===
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -79,8 +79,6 @@ typedef struct pmac_ide_hwif {
} pmac_ide_hwif_t;
-static pmac_ide_hwif_t pmac_ide[MAX_HWIFS];
-
enum {
controller_ohare, /* OHare based */
controller_heathrow,/* Heathrow/Paddington */
@@ -1094,29 +1092,34 @@ pmac_ide_macio_attach(struct macio_dev *
int i, rc;
hw_regs_t hw;
+ pmif = kzalloc(sizeof(*pmif), GFP_KERNEL);
+ if (pmif == NULL)
+ return -ENOMEM;
+
i = 0;
- while (i < MAX_HWIFS && (ide_hwifs[i].io_ports[IDE_DATA_OFFSET] != 0
- || pmac_ide[i].node != NULL))
+ while (i < MAX_HWIFS && (ide_hwifs[i].io_ports[IDE_DATA_OFFSET] != 0))
++i;
if (i >= MAX_HWIFS) {
printk(KERN_ERR "ide-pmac: MacIO interface attach with no
slot\n");
printk(KERN_ERR " %s\n", mdev->ofdev.node->full_name);
- return -ENODEV;
+ rc = -ENODEV;
+ goto out_free_pmif;
}
- pmif = &pmac_ide[i];
hwif = &ide_hwifs[i];
if (macio_resource_count(mdev) == 0) {
printk(KERN_WARNING "ide%d: no address for %s\n",
i, mdev->ofdev.node->full_name);
- return -ENXIO;
+ rc = -ENXIO;
+ goto out_free_pmif;
}
/* Request memory resource for IO ports */
if (macio_request_resource(mdev, 0, "ide-pmac (ports)")) {
printk(KERN_ERR "ide%d: can't request mmio resource !\n", i);
- return -EBUSY;
+ rc = -EBUSY;
+ goto out_free_pmif;
}
/* XXX This is bogus. Should be fixed in the registry by checking
@@ -1166,11 +1169,15 @@ pmac_ide_macio_attach(struct macio_dev *
iounmap(pmif->dma_regs);
macio_release_resource(mdev, 1);
}
- memset(pmif, 0, sizeof(*pmif));
macio_release_resource(mdev, 0);
+ kfree(pmif);
}
return rc;
+
+out_free_pmif:
+ kfree(pmif);
+ return rc;
}
static int
@@ -1223,30 +1230,36 @@ pmac_ide_pci_attach(struct pci_dev *pdev
printk(KERN_ERR "ide-pmac: cannot find MacIO node for Kauai ATA
interface\n");
return -ENODEV;
}
+
+ pmif = kz
