[PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michal Simek]

Hi,

recently we wanted to update xilinx intc driver and we found that function
which we wanted to remove is still wired by ancient Xilinx PowerPC
platforms. Here is the thread about it.
https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xilinx.com/

I have been talking about it internally and there is no interest in these
platforms and it is also orphan for quite a long time. None is really
running/testing these platforms regularly that's why I think it makes sense
to remove them also with drivers which are specific to this platform.

U-Boot support was removed in 2017 without anybody complain about it
https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed

Based on current ppc/next.

If anyone has any objection about it, please let me know.

Thanks,
Michal


Michal Simek (2):
  sound: ac97: Remove sound driver for ancient platform
  powerpc: Remove Xilinx PPC405/PPC440 support

 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 --
 arch/powerpc/xmon/ppc-dis.c                  |    6 -
 arch/powerpc/xmon/ppc-opc.c                  |   23 -
 arch/powerpc/xmon/ppc.h                      |    5 -
 drivers/char/Kconfig                         |    2 +-
 drivers/video/fbdev/Kconfig                  |    2 +-
 sound/drivers/Kconfig                        |   12 -
 sound/drivers/Makefile                       |    2 -
 sound/drivers/ml403-ac97cr.c                 | 1298 ------------------
 40 files changed, 7 insertions(+), 3305 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
 delete mode 100644 sound/drivers/ml403-ac97cr.c

-- 
2.26.0

[PATCH 1/2] sound: ac97: Remove sound driver for ancient platform

[Michal Simek]

Xilinx PowerPC platforms are no longer supported and none is really testing
these platforms that's why remove them. If someone has any issue with it
these patches can be reverted.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---

 sound/drivers/Kconfig        |   12 -
 sound/drivers/Makefile       |    2 -
 sound/drivers/ml403-ac97cr.c | 1298 ----------------------------------
 3 files changed, 1312 deletions(-)
 delete mode 100644 sound/drivers/ml403-ac97cr.c

diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index 577c8e03ec4d..7141f73cddd3 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -186,18 +186,6 @@ config SND_PORTMAN2X4
 	  To compile this driver as a module, choose M here: the module
 	  will be called snd-portman2x4.
 
-config SND_ML403_AC97CR
-	tristate "Xilinx ML403 AC97 Controller Reference"
-	depends on XILINX_VIRTEX
-	select SND_AC97_CODEC
-	help
-	  Say Y here to include support for the
-	  opb_ac97_controller_ref_v1_00_a ip core found in Xilinx's ML403
-	  reference design.
-
-	  To compile this driver as a module, choose M here: the module
-	  will be called snd-ml403_ac97cr.
-
 config SND_AC97_POWER_SAVE
 	bool "AC97 Power-Saving Mode"
 	depends on SND_AC97_CODEC
diff --git a/sound/drivers/Makefile b/sound/drivers/Makefile
index 615558a281c8..c0fe4eccdaef 100644
--- a/sound/drivers/Makefile
+++ b/sound/drivers/Makefile
@@ -11,7 +11,6 @@ snd-mts64-objs := mts64.o
 snd-portman2x4-objs := portman2x4.o
 snd-serial-u16550-objs := serial-u16550.o
 snd-virmidi-objs := virmidi.o
-snd-ml403-ac97cr-objs := ml403-ac97cr.o pcm-indirect2.o
 
 # Toplevel Module Dependency
 obj-$(CONFIG_SND_DUMMY) += snd-dummy.o
@@ -21,6 +20,5 @@ obj-$(CONFIG_SND_SERIAL_U16550) += snd-serial-u16550.o
 obj-$(CONFIG_SND_MTPAV) += snd-mtpav.o
 obj-$(CONFIG_SND_MTS64) += snd-mts64.o
 obj-$(CONFIG_SND_PORTMAN2X4) += snd-portman2x4.o
-obj-$(CONFIG_SND_ML403_AC97CR) += snd-ml403-ac97cr.o
 
 obj-$(CONFIG_SND) += opl3/ opl4/ mpu401/ vx/ pcsp/
diff --git a/sound/drivers/ml403-ac97cr.c b/sound/drivers/ml403-ac97cr.c
deleted file mode 100644
index 0710707da8c1..000000000000
--- a/sound/drivers/ml403-ac97cr.c
+++ /dev/null
@@ -1,1298 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * ALSA driver for Xilinx ML403 AC97 Controller Reference
- *   IP: opb_ac97_controller_ref_v1_00_a (EDK 8.1i)
- *   IP: opb_ac97_controller_ref_v1_00_a (EDK 9.1i)
- *
- *  Copyright (c) by 2007  Joachim Foerster <JOFT@gmx.de>
- */
-
-/* Some notes / status of this driver:
- *
- * - Don't wonder about some strange implementations of things - especially the
- * (heavy) shadowing of codec registers, with which I tried to reduce read
- * accesses to a minimum, because after a variable amount of accesses, the AC97
- * controller doesn't raise the register access finished bit anymore ...
- *
- * - Playback support seems to be pretty stable - no issues here.
- * - Capture support "works" now, too. Overruns don't happen any longer so often.
- *   But there might still be some ...
- */
-
-#include <linux/init.h>
-#include <linux/module.h>
-
-#include <linux/platform_device.h>
-
-#include <linux/ioport.h>
-#include <linux/slab.h>
-#include <linux/io.h>
-#include <linux/interrupt.h>
-
-/* HZ */
-#include <linux/param.h>
-/* jiffies, time_*() */
-#include <linux/jiffies.h>
-/* schedule_timeout*() */
-#include <linux/sched.h>
-/* spin_lock*() */
-#include <linux/spinlock.h>
-/* struct mutex, mutex_init(), mutex_*lock() */
-#include <linux/mutex.h>
-
-/* snd_printk(), snd_printd() */
-#include <sound/core.h>
-#include <sound/pcm.h>
-#include <sound/pcm_params.h>
-#include <sound/initval.h>
-#include <sound/ac97_codec.h>
-
-#include "pcm-indirect2.h"
-
-
-#define SND_ML403_AC97CR_DRIVER "ml403-ac97cr"
-
-MODULE_AUTHOR("Joachim Foerster <JOFT@gmx.de>");
-MODULE_DESCRIPTION("Xilinx ML403 AC97 Controller Reference");
-MODULE_LICENSE("GPL");
-MODULE_SUPPORTED_DEVICE("{{Xilinx,ML403 AC97 Controller Reference}}");
-
-static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
-static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;
-static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE;
-
-module_param_array(index, int, NULL, 0444);
-MODULE_PARM_DESC(index, "Index value for ML403 AC97 Controller Reference.");
-module_param_array(id, charp, NULL, 0444);
-MODULE_PARM_DESC(id, "ID string for ML403 AC97 Controller Reference.");
-module_param_array(enable, bool, NULL, 0444);
-MODULE_PARM_DESC(enable, "Enable this ML403 AC97 Controller Reference.");
-
-/* Special feature options */
-/*#define CODEC_WRITE_CHECK_RAF*/ /* don't return after a write to a codec
-				   * register, while RAF bit is not set
-				   */
-/* Debug options for code which may be removed completely in a final version */
-#ifdef CONFIG_SND_DEBUG
-/*#define CODEC_STAT*/            /* turn on some minimal "statistics"
-				   * about codec register usage
-				   */
-#define SND_PCM_INDIRECT2_STAT    /* turn on some "statistics" about the
-				   * process of copying bytes from the
-				   * intermediate buffer to the hardware
-				   * fifo and the other way round
-				   */
-#endif
-
-/* Definition of a "level/facility dependent" printk(); may be removed
- * completely in a final version
- */
-#undef PDEBUG
-#ifdef CONFIG_SND_DEBUG
-/* "facilities" for PDEBUG */
-#define UNKNOWN       (1<<0)
-#define CODEC_SUCCESS (1<<1)
-#define CODEC_FAKE    (1<<2)
-#define INIT_INFO     (1<<3)
-#define INIT_FAILURE  (1<<4)
-#define WORK_INFO     (1<<5)
-#define WORK_FAILURE  (1<<6)
-
-#define PDEBUG_FACILITIES (UNKNOWN | INIT_FAILURE | WORK_FAILURE)
-
-#define PDEBUG(fac, fmt, args...) do { \
-		if (fac & PDEBUG_FACILITIES) \
-			snd_printd(KERN_DEBUG SND_ML403_AC97CR_DRIVER ": " \
-				   fmt, ##args); \
-	} while (0)
-#else
-#define PDEBUG(fac, fmt, args...) /* nothing */
-#endif
-
-
-
-/* Defines for "waits"/timeouts (portions of HZ=250 on arch/ppc by default) */
-#define CODEC_TIMEOUT_ON_INIT       5	/* timeout for checking for codec
-					 * readiness (after insmod)
-					 */
-#ifndef CODEC_WRITE_CHECK_RAF
-#define CODEC_WAIT_AFTER_WRITE    100	/* general, static wait after a write
-					 * access to a codec register, may be
-					 * 0 to completely remove wait
-					 */
-#else
-#define CODEC_TIMEOUT_AFTER_WRITE   5	/* timeout after a write access to a
-					 * codec register, if RAF bit is used
-					 */
-#endif
-#define CODEC_TIMEOUT_AFTER_READ    5	/* timeout after a read access to a
-					 * codec register (checking RAF bit)
-					 */
-
-/* Infrastructure for codec register shadowing */
-#define LM4550_REG_OK        (1<<0)   /* register exists */
-#define LM4550_REG_DONEREAD  (1<<1)   /* read register once, value should be
-				       * the same currently in the register
-				       */
-#define LM4550_REG_NOSAVE    (1<<2)   /* values written to this register will
-				       * not be saved in the register
-				       */
-#define LM4550_REG_NOSHADOW  (1<<3)   /* don't do register shadowing, use plain
-				       * hardware access
-				       */
-#define LM4550_REG_READONLY  (1<<4)   /* register is read only */
-#define LM4550_REG_FAKEPROBE (1<<5)   /* fake write _and_ read actions during
-				       * probe() correctly
-				       */
-#define LM4550_REG_FAKEREAD  (1<<6)   /* fake read access, always return
-				       * default value
-				       */
-#define LM4550_REG_ALLFAKE   (LM4550_REG_FAKEREAD | LM4550_REG_FAKEPROBE)
-
-struct lm4550_reg {
-	u16 value;
-	u16 flag;
-	u16 wmask;
-	u16 def;
-};
-
-struct lm4550_reg lm4550_regfile[64] = {
-	[AC97_RESET / 2]              = {.flag = LM4550_REG_OK \
-						| LM4550_REG_NOSAVE \
-						| LM4550_REG_FAKEREAD,
-					 .def = 0x0D50},
-	[AC97_MASTER / 2]             = {.flag = LM4550_REG_OK
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x9F1F,
-					 .def = 0x8000},
-	[AC97_HEADPHONE / 2]          = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x9F1F,
-					 .def = 0x8000},
-	[AC97_MASTER_MONO / 2]        = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x801F,
-					 .def = 0x8000},
-	[AC97_PC_BEEP / 2]            = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x801E,
-					 .def = 0x0},
-	[AC97_PHONE / 2]              = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x801F,
-					 .def = 0x8008},
-	[AC97_MIC / 2]                = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x805F,
-					 .def = 0x8008},
-	[AC97_LINE / 2]               = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x9F1F,
-					 .def = 0x8808},
-	[AC97_CD / 2]                 = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x9F1F,
-					 .def = 0x8808},
-	[AC97_VIDEO / 2]              = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x9F1F,
-					 .def = 0x8808},
-	[AC97_AUX / 2]                = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x9F1F,
-					 .def = 0x8808},
-	[AC97_PCM / 2]                = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x9F1F,
-					 .def = 0x8008},
-	[AC97_REC_SEL / 2]            = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x707,
-					 .def = 0x0},
-	[AC97_REC_GAIN / 2]           = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .wmask = 0x8F0F,
-					 .def = 0x8000},
-	[AC97_GENERAL_PURPOSE / 2]    = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .def = 0x0,
-					 .wmask = 0xA380},
-	[AC97_3D_CONTROL / 2]         = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEREAD \
-						| LM4550_REG_READONLY,
-					 .def = 0x0101},
-	[AC97_POWERDOWN / 2]          = {.flag = LM4550_REG_OK \
-						| LM4550_REG_NOSHADOW \
-						| LM4550_REG_NOSAVE,
-					 .wmask = 0xFF00},
-					/* may not write ones to
-					 * REF/ANL/DAC/ADC bits
-					 * FIXME: Is this ok?
-					 */
-	[AC97_EXTENDED_ID / 2]        = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEREAD \
-						| LM4550_REG_READONLY,
-					 .def = 0x0201}, /* primary codec */
-	[AC97_EXTENDED_STATUS / 2]    = {.flag = LM4550_REG_OK \
-						| LM4550_REG_NOSHADOW \
-						| LM4550_REG_NOSAVE,
-					 .wmask = 0x1},
-	[AC97_PCM_FRONT_DAC_RATE / 2] = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .def = 0xBB80,
-					 .wmask = 0xFFFF},
-	[AC97_PCM_LR_ADC_RATE / 2]    = {.flag = LM4550_REG_OK \
-						| LM4550_REG_FAKEPROBE,
-					 .def = 0xBB80,
-					 .wmask = 0xFFFF},
-	[AC97_VENDOR_ID1 / 2]         = {.flag = LM4550_REG_OK \
-						| LM4550_REG_READONLY \
-						| LM4550_REG_FAKEREAD,
-					 .def = 0x4E53},
-	[AC97_VENDOR_ID2 / 2]         = {.flag = LM4550_REG_OK \
-						| LM4550_REG_READONLY \
-						| LM4550_REG_FAKEREAD,
-					 .def = 0x4350}
-};
-
-#define LM4550_RF_OK(reg)    (lm4550_regfile[reg / 2].flag & LM4550_REG_OK)
-
-static void lm4550_regfile_init(void)
-{
-	int i;
-	for (i = 0; i < 64; i++)
-		if (lm4550_regfile[i].flag & LM4550_REG_FAKEPROBE)
-			lm4550_regfile[i].value = lm4550_regfile[i].def;
-}
-
-static void lm4550_regfile_write_values_after_init(struct snd_ac97 *ac97)
-{
-	int i;
-	for (i = 0; i < 64; i++)
-		if ((lm4550_regfile[i].flag & LM4550_REG_FAKEPROBE) &&
-		    (lm4550_regfile[i].value != lm4550_regfile[i].def)) {
-			PDEBUG(CODEC_FAKE, "lm4550_regfile_write_values_after_"
-			       "init(): reg=0x%x value=0x%x / %d is different "
-			       "from def=0x%x / %d\n",
-			       i, lm4550_regfile[i].value,
-			       lm4550_regfile[i].value, lm4550_regfile[i].def,
-			       lm4550_regfile[i].def);
-			snd_ac97_write(ac97, i * 2, lm4550_regfile[i].value);
-			lm4550_regfile[i].flag |= LM4550_REG_DONEREAD;
-		}
-}
-
-
-/* direct registers */
-#define CR_REG(ml403_ac97cr, x) ((ml403_ac97cr)->port + CR_REG_##x)
-
-#define CR_REG_PLAYFIFO         0x00
-#define   CR_PLAYDATA(a)        ((a) & 0xFFFF)
-
-#define CR_REG_RECFIFO          0x04
-#define   CR_RECDATA(a)         ((a) & 0xFFFF)
-
-#define CR_REG_STATUS           0x08
-#define   CR_RECOVER            (1<<7)
-#define   CR_PLAYUNDER          (1<<6)
-#define   CR_CODECREADY         (1<<5)
-#define   CR_RAF                (1<<4)
-#define   CR_RECEMPTY           (1<<3)
-#define   CR_RECFULL            (1<<2)
-#define   CR_PLAYHALF           (1<<1)
-#define   CR_PLAYFULL           (1<<0)
-
-#define CR_REG_RESETFIFO        0x0C
-#define   CR_RECRESET           (1<<1)
-#define   CR_PLAYRESET          (1<<0)
-
-#define CR_REG_CODEC_ADDR       0x10
-/* UG082 says:
- * #define   CR_CODEC_ADDR(a)  ((a) << 1)
- * #define   CR_CODEC_READ     (1<<0)
- * #define   CR_CODEC_WRITE    (0<<0)
- */
-/* RefDesign example says: */
-#define   CR_CODEC_ADDR(a)      ((a) << 0)
-#define   CR_CODEC_READ         (1<<7)
-#define   CR_CODEC_WRITE        (0<<7)
-
-#define CR_REG_CODEC_DATAREAD   0x14
-#define   CR_CODEC_DATAREAD(v)  ((v) & 0xFFFF)
-
-#define CR_REG_CODEC_DATAWRITE  0x18
-#define   CR_CODEC_DATAWRITE(v) ((v) & 0xFFFF)
-
-#define CR_FIFO_SIZE            32
-
-struct snd_ml403_ac97cr {
-	/* lock for access to (controller) registers */
-	spinlock_t reg_lock;
-	/* mutex for the whole sequence of accesses to (controller) registers
-	 * which affect codec registers
-	 */
-	struct mutex cdc_mutex;
-
-	int irq; /* for playback */
-	int enable_irq;	/* for playback */
-
-	int capture_irq;
-	int enable_capture_irq;
-
-	struct resource *res_port;
-	void *port;
-
-	struct snd_ac97 *ac97;
-	int ac97_fake;
-#ifdef CODEC_STAT
-	int ac97_read;
-	int ac97_write;
-#endif
-
-	struct platform_device *pfdev;
-	struct snd_card *card;
-	struct snd_pcm *pcm;
-	struct snd_pcm_substream *playback_substream;
-	struct snd_pcm_substream *capture_substream;
-
-	struct snd_pcm_indirect2 ind_rec; /* for playback */
-	struct snd_pcm_indirect2 capture_ind2_rec;
-};
-
-static const struct snd_pcm_hardware snd_ml403_ac97cr_playback = {
-	.info =	            (SNDRV_PCM_INFO_MMAP |
-			     SNDRV_PCM_INFO_INTERLEAVED |
-			     SNDRV_PCM_INFO_MMAP_VALID),
-	.formats =          SNDRV_PCM_FMTBIT_S16_BE,
-	.rates =	    (SNDRV_PCM_RATE_CONTINUOUS |
-			     SNDRV_PCM_RATE_8000_48000),
-	.rate_min =	    4000,
-	.rate_max =	    48000,
-	.channels_min =     2,
-	.channels_max =     2,
-	.buffer_bytes_max = (128*1024),
-	.period_bytes_min = CR_FIFO_SIZE/2,
-	.period_bytes_max = (64*1024),
-	.periods_min =      2,
-	.periods_max =      (128*1024)/(CR_FIFO_SIZE/2),
-	.fifo_size =	    0,
-};
-
-static const struct snd_pcm_hardware snd_ml403_ac97cr_capture = {
-	.info =	            (SNDRV_PCM_INFO_MMAP |
-			     SNDRV_PCM_INFO_INTERLEAVED |
-			     SNDRV_PCM_INFO_MMAP_VALID),
-	.formats =          SNDRV_PCM_FMTBIT_S16_BE,
-	.rates =            (SNDRV_PCM_RATE_CONTINUOUS |
-			     SNDRV_PCM_RATE_8000_48000),
-	.rate_min =         4000,
-	.rate_max =         48000,
-	.channels_min =     2,
-	.channels_max =     2,
-	.buffer_bytes_max = (128*1024),
-	.period_bytes_min = CR_FIFO_SIZE/2,
-	.period_bytes_max = (64*1024),
-	.periods_min =      2,
-	.periods_max =      (128*1024)/(CR_FIFO_SIZE/2),
-	.fifo_size =	    0,
-};
-
-static size_t
-snd_ml403_ac97cr_playback_ind2_zero(struct snd_pcm_substream *substream,
-				    struct snd_pcm_indirect2 *rec)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	int copied_words = 0;
-	u32 full = 0;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-
-	spin_lock(&ml403_ac97cr->reg_lock);
-	while ((full = (in_be32(CR_REG(ml403_ac97cr, STATUS)) &
-			CR_PLAYFULL)) != CR_PLAYFULL) {
-		out_be32(CR_REG(ml403_ac97cr, PLAYFIFO), 0);
-		copied_words++;
-	}
-	rec->hw_ready = 0;
-	spin_unlock(&ml403_ac97cr->reg_lock);
-
-	return (size_t) (copied_words * 2);
-}
-
-static size_t
-snd_ml403_ac97cr_playback_ind2_copy(struct snd_pcm_substream *substream,
-				    struct snd_pcm_indirect2 *rec,
-				    size_t bytes)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	u16 *src;
-	int copied_words = 0;
-	u32 full = 0;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-	src = (u16 *)(substream->runtime->dma_area + rec->sw_data);
-
-	spin_lock(&ml403_ac97cr->reg_lock);
-	while (((full = (in_be32(CR_REG(ml403_ac97cr, STATUS)) &
-			 CR_PLAYFULL)) != CR_PLAYFULL) && (bytes > 1)) {
-		out_be32(CR_REG(ml403_ac97cr, PLAYFIFO),
-			 CR_PLAYDATA(src[copied_words]));
-		copied_words++;
-		bytes = bytes - 2;
-	}
-	if (full != CR_PLAYFULL)
-		rec->hw_ready = 1;
-	else
-		rec->hw_ready = 0;
-	spin_unlock(&ml403_ac97cr->reg_lock);
-
-	return (size_t) (copied_words * 2);
-}
-
-static size_t
-snd_ml403_ac97cr_capture_ind2_null(struct snd_pcm_substream *substream,
-				   struct snd_pcm_indirect2 *rec)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	int copied_words = 0;
-	u32 empty = 0;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-
-	spin_lock(&ml403_ac97cr->reg_lock);
-	while ((empty = (in_be32(CR_REG(ml403_ac97cr, STATUS)) &
-			 CR_RECEMPTY)) != CR_RECEMPTY) {
-		volatile u32 trash;
-
-		trash = CR_RECDATA(in_be32(CR_REG(ml403_ac97cr, RECFIFO)));
-		/* Hmmmm, really necessary? Don't want call to in_be32()
-		 * to be optimised away!
-		 */
-		trash++;
-		copied_words++;
-	}
-	rec->hw_ready = 0;
-	spin_unlock(&ml403_ac97cr->reg_lock);
-
-	return (size_t) (copied_words * 2);
-}
-
-static size_t
-snd_ml403_ac97cr_capture_ind2_copy(struct snd_pcm_substream *substream,
-				   struct snd_pcm_indirect2 *rec, size_t bytes)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	u16 *dst;
-	int copied_words = 0;
-	u32 empty = 0;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-	dst = (u16 *)(substream->runtime->dma_area + rec->sw_data);
-
-	spin_lock(&ml403_ac97cr->reg_lock);
-	while (((empty = (in_be32(CR_REG(ml403_ac97cr, STATUS)) &
-			  CR_RECEMPTY)) != CR_RECEMPTY) && (bytes > 1)) {
-		dst[copied_words] = CR_RECDATA(in_be32(CR_REG(ml403_ac97cr,
-							      RECFIFO)));
-		copied_words++;
-		bytes = bytes - 2;
-	}
-	if (empty != CR_RECEMPTY)
-		rec->hw_ready = 1;
-	else
-		rec->hw_ready = 0;
-	spin_unlock(&ml403_ac97cr->reg_lock);
-
-	return (size_t) (copied_words * 2);
-}
-
-static snd_pcm_uframes_t
-snd_ml403_ac97cr_pcm_pointer(struct snd_pcm_substream *substream)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	struct snd_pcm_indirect2 *ind2_rec = NULL;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-
-	if (substream == ml403_ac97cr->playback_substream)
-		ind2_rec = &ml403_ac97cr->ind_rec;
-	if (substream == ml403_ac97cr->capture_substream)
-		ind2_rec = &ml403_ac97cr->capture_ind2_rec;
-
-	if (ind2_rec != NULL)
-		return snd_pcm_indirect2_pointer(substream, ind2_rec);
-	return (snd_pcm_uframes_t) 0;
-}
-
-static int
-snd_ml403_ac97cr_pcm_playback_trigger(struct snd_pcm_substream *substream,
-				      int cmd)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	int err = 0;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-
-	switch (cmd) {
-	case SNDRV_PCM_TRIGGER_START:
-		PDEBUG(WORK_INFO, "trigger(playback): START\n");
-		ml403_ac97cr->ind_rec.hw_ready = 1;
-
-		/* clear play FIFO */
-		out_be32(CR_REG(ml403_ac97cr, RESETFIFO), CR_PLAYRESET);
-
-		/* enable play irq */
-		ml403_ac97cr->enable_irq = 1;
-		enable_irq(ml403_ac97cr->irq);
-		break;
-	case SNDRV_PCM_TRIGGER_STOP:
-		PDEBUG(WORK_INFO, "trigger(playback): STOP\n");
-		ml403_ac97cr->ind_rec.hw_ready = 0;
-#ifdef SND_PCM_INDIRECT2_STAT
-		snd_pcm_indirect2_stat(substream, &ml403_ac97cr->ind_rec);
-#endif
-		/* disable play irq */
-		disable_irq_nosync(ml403_ac97cr->irq);
-		ml403_ac97cr->enable_irq = 0;
-		break;
-	default:
-		err = -EINVAL;
-		break;
-	}
-	PDEBUG(WORK_INFO, "trigger(playback): (done)\n");
-	return err;
-}
-
-static int
-snd_ml403_ac97cr_pcm_capture_trigger(struct snd_pcm_substream *substream,
-				      int cmd)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	int err = 0;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-
-	switch (cmd) {
-	case SNDRV_PCM_TRIGGER_START:
-		PDEBUG(WORK_INFO, "trigger(capture): START\n");
-		ml403_ac97cr->capture_ind2_rec.hw_ready = 0;
-
-		/* clear record FIFO */
-		out_be32(CR_REG(ml403_ac97cr, RESETFIFO), CR_RECRESET);
-
-		/* enable record irq */
-		ml403_ac97cr->enable_capture_irq = 1;
-		enable_irq(ml403_ac97cr->capture_irq);
-		break;
-	case SNDRV_PCM_TRIGGER_STOP:
-		PDEBUG(WORK_INFO, "trigger(capture): STOP\n");
-		ml403_ac97cr->capture_ind2_rec.hw_ready = 0;
-#ifdef SND_PCM_INDIRECT2_STAT
-		snd_pcm_indirect2_stat(substream,
-				       &ml403_ac97cr->capture_ind2_rec);
-#endif
-		/* disable capture irq */
-		disable_irq_nosync(ml403_ac97cr->capture_irq);
-		ml403_ac97cr->enable_capture_irq = 0;
-		break;
-	default:
-		err = -EINVAL;
-		break;
-	}
-	PDEBUG(WORK_INFO, "trigger(capture): (done)\n");
-	return err;
-}
-
-static int
-snd_ml403_ac97cr_pcm_playback_prepare(struct snd_pcm_substream *substream)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	struct snd_pcm_runtime *runtime;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-	runtime = substream->runtime;
-
-	PDEBUG(WORK_INFO,
-	       "prepare(): period_bytes=%d, minperiod_bytes=%d\n",
-	       snd_pcm_lib_period_bytes(substream), CR_FIFO_SIZE / 2);
-
-	/* set sampling rate */
-	snd_ac97_set_rate(ml403_ac97cr->ac97, AC97_PCM_FRONT_DAC_RATE,
-			  runtime->rate);
-	PDEBUG(WORK_INFO, "prepare(): rate=%d\n", runtime->rate);
-
-	/* init struct for intermediate buffer */
-	memset(&ml403_ac97cr->ind_rec, 0,
-	       sizeof(struct snd_pcm_indirect2));
-	ml403_ac97cr->ind_rec.hw_buffer_size = CR_FIFO_SIZE;
-	ml403_ac97cr->ind_rec.sw_buffer_size =
-		snd_pcm_lib_buffer_bytes(substream);
-	ml403_ac97cr->ind_rec.min_periods = -1;
-	ml403_ac97cr->ind_rec.min_multiple =
-		snd_pcm_lib_period_bytes(substream) / (CR_FIFO_SIZE / 2);
-	PDEBUG(WORK_INFO, "prepare(): hw_buffer_size=%d, "
-	       "sw_buffer_size=%d, min_multiple=%d\n",
-	       CR_FIFO_SIZE, ml403_ac97cr->ind_rec.sw_buffer_size,
-	       ml403_ac97cr->ind_rec.min_multiple);
-	return 0;
-}
-
-static int
-snd_ml403_ac97cr_pcm_capture_prepare(struct snd_pcm_substream *substream)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	struct snd_pcm_runtime *runtime;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-	runtime = substream->runtime;
-
-	PDEBUG(WORK_INFO,
-	       "prepare(capture): period_bytes=%d, minperiod_bytes=%d\n",
-	       snd_pcm_lib_period_bytes(substream), CR_FIFO_SIZE / 2);
-
-	/* set sampling rate */
-	snd_ac97_set_rate(ml403_ac97cr->ac97, AC97_PCM_LR_ADC_RATE,
-			  runtime->rate);
-	PDEBUG(WORK_INFO, "prepare(capture): rate=%d\n", runtime->rate);
-
-	/* init struct for intermediate buffer */
-	memset(&ml403_ac97cr->capture_ind2_rec, 0,
-	       sizeof(struct snd_pcm_indirect2));
-	ml403_ac97cr->capture_ind2_rec.hw_buffer_size = CR_FIFO_SIZE;
-	ml403_ac97cr->capture_ind2_rec.sw_buffer_size =
-		snd_pcm_lib_buffer_bytes(substream);
-	ml403_ac97cr->capture_ind2_rec.min_multiple =
-		snd_pcm_lib_period_bytes(substream) / (CR_FIFO_SIZE / 2);
-	PDEBUG(WORK_INFO, "prepare(capture): hw_buffer_size=%d, "
-	       "sw_buffer_size=%d, min_multiple=%d\n", CR_FIFO_SIZE,
-	       ml403_ac97cr->capture_ind2_rec.sw_buffer_size,
-	       ml403_ac97cr->capture_ind2_rec.min_multiple);
-	return 0;
-}
-
-static int snd_ml403_ac97cr_playback_open(struct snd_pcm_substream *substream)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	struct snd_pcm_runtime *runtime;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-	runtime = substream->runtime;
-
-	PDEBUG(WORK_INFO, "open(playback)\n");
-	ml403_ac97cr->playback_substream = substream;
-	runtime->hw = snd_ml403_ac97cr_playback;
-
-	snd_pcm_hw_constraint_step(runtime, 0,
-				   SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
-				   CR_FIFO_SIZE / 2);
-	return 0;
-}
-
-static int snd_ml403_ac97cr_capture_open(struct snd_pcm_substream *substream)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	struct snd_pcm_runtime *runtime;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-	runtime = substream->runtime;
-
-	PDEBUG(WORK_INFO, "open(capture)\n");
-	ml403_ac97cr->capture_substream = substream;
-	runtime->hw = snd_ml403_ac97cr_capture;
-
-	snd_pcm_hw_constraint_step(runtime, 0,
-				   SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
-				   CR_FIFO_SIZE / 2);
-	return 0;
-}
-
-static int snd_ml403_ac97cr_playback_close(struct snd_pcm_substream *substream)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-
-	PDEBUG(WORK_INFO, "close(playback)\n");
-	ml403_ac97cr->playback_substream = NULL;
-	return 0;
-}
-
-static int snd_ml403_ac97cr_capture_close(struct snd_pcm_substream *substream)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-
-	ml403_ac97cr = snd_pcm_substream_chip(substream);
-
-	PDEBUG(WORK_INFO, "close(capture)\n");
-	ml403_ac97cr->capture_substream = NULL;
-	return 0;
-}
-
-static const struct snd_pcm_ops snd_ml403_ac97cr_playback_ops = {
-	.open = snd_ml403_ac97cr_playback_open,
-	.close = snd_ml403_ac97cr_playback_close,
-	.prepare = snd_ml403_ac97cr_pcm_playback_prepare,
-	.trigger = snd_ml403_ac97cr_pcm_playback_trigger,
-	.pointer = snd_ml403_ac97cr_pcm_pointer,
-};
-
-static const struct snd_pcm_ops snd_ml403_ac97cr_capture_ops = {
-	.open = snd_ml403_ac97cr_capture_open,
-	.close = snd_ml403_ac97cr_capture_close,
-	.prepare = snd_ml403_ac97cr_pcm_capture_prepare,
-	.trigger = snd_ml403_ac97cr_pcm_capture_trigger,
-	.pointer = snd_ml403_ac97cr_pcm_pointer,
-};
-
-static irqreturn_t snd_ml403_ac97cr_irq(int irq, void *dev_id)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	struct platform_device *pfdev;
-	int cmp_irq;
-
-	ml403_ac97cr = (struct snd_ml403_ac97cr *)dev_id;
-	if (ml403_ac97cr == NULL)
-		return IRQ_NONE;
-
-	pfdev = ml403_ac97cr->pfdev;
-
-	/* playback interrupt */
-	cmp_irq = platform_get_irq(pfdev, 0);
-	if (irq == cmp_irq) {
-		if (ml403_ac97cr->enable_irq)
-			snd_pcm_indirect2_playback_interrupt(
-				ml403_ac97cr->playback_substream,
-				&ml403_ac97cr->ind_rec,
-				snd_ml403_ac97cr_playback_ind2_copy,
-				snd_ml403_ac97cr_playback_ind2_zero);
-		else
-			goto __disable_irq;
-	} else {
-		/* record interrupt */
-		cmp_irq = platform_get_irq(pfdev, 1);
-		if (irq == cmp_irq) {
-			if (ml403_ac97cr->enable_capture_irq)
-				snd_pcm_indirect2_capture_interrupt(
-					ml403_ac97cr->capture_substream,
-					&ml403_ac97cr->capture_ind2_rec,
-					snd_ml403_ac97cr_capture_ind2_copy,
-					snd_ml403_ac97cr_capture_ind2_null);
-			else
-				goto __disable_irq;
-		} else
-			return IRQ_NONE;
-	}
-	return IRQ_HANDLED;
-
-__disable_irq:
-	PDEBUG(INIT_INFO, "irq(): irq %d is meant to be disabled! So, now try "
-	       "to disable it _really_!\n", irq);
-	disable_irq_nosync(irq);
-	return IRQ_HANDLED;
-}
-
-static unsigned short
-snd_ml403_ac97cr_codec_read(struct snd_ac97 *ac97, unsigned short reg)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr = ac97->private_data;
-#ifdef CODEC_STAT
-	u32 stat;
-	u32 rafaccess = 0;
-#endif
-	unsigned long end_time;
-	u16 value = 0;
-
-	if (!LM4550_RF_OK(reg)) {
-		snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": "
-			   "access to unknown/unused codec register 0x%x "
-			   "ignored!\n", reg);
-		return 0;
-	}
-	/* check if we can fake/answer this access from our shadow register */
-	if ((lm4550_regfile[reg / 2].flag &
-	     (LM4550_REG_DONEREAD | LM4550_REG_ALLFAKE)) &&
-	    !(lm4550_regfile[reg / 2].flag & LM4550_REG_NOSHADOW)) {
-		if (lm4550_regfile[reg / 2].flag & LM4550_REG_FAKEREAD) {
-			PDEBUG(CODEC_FAKE, "codec_read(): faking read from "
-			       "reg=0x%x, val=0x%x / %d\n",
-			       reg, lm4550_regfile[reg / 2].def,
-			       lm4550_regfile[reg / 2].def);
-			return lm4550_regfile[reg / 2].def;
-		} else if ((lm4550_regfile[reg / 2].flag &
-			    LM4550_REG_FAKEPROBE) &&
-			   ml403_ac97cr->ac97_fake) {
-			PDEBUG(CODEC_FAKE, "codec_read(): faking read from "
-			       "reg=0x%x, val=0x%x / %d (probe)\n",
-			       reg, lm4550_regfile[reg / 2].value,
-			       lm4550_regfile[reg / 2].value);
-			return lm4550_regfile[reg / 2].value;
-		} else {
-#ifdef CODEC_STAT
-			PDEBUG(CODEC_FAKE, "codec_read(): read access "
-			       "answered by shadow register 0x%x (value=0x%x "
-			       "/ %d) (cw=%d cr=%d)\n",
-			       reg, lm4550_regfile[reg / 2].value,
-			       lm4550_regfile[reg / 2].value,
-			       ml403_ac97cr->ac97_write,
-			       ml403_ac97cr->ac97_read);
-#else
-			PDEBUG(CODEC_FAKE, "codec_read(): read access "
-			       "answered by shadow register 0x%x (value=0x%x "
-			       "/ %d)\n",
-			       reg, lm4550_regfile[reg / 2].value,
-			       lm4550_regfile[reg / 2].value);
-#endif
-			return lm4550_regfile[reg / 2].value;
-		}
-	}
-	/* if we are here, we _have_ to access the codec really, no faking */
-	if (mutex_lock_interruptible(&ml403_ac97cr->cdc_mutex) != 0)
-		return 0;
-#ifdef CODEC_STAT
-	ml403_ac97cr->ac97_read++;
-#endif
-	spin_lock(&ml403_ac97cr->reg_lock);
-	out_be32(CR_REG(ml403_ac97cr, CODEC_ADDR),
-		 CR_CODEC_ADDR(reg) | CR_CODEC_READ);
-	spin_unlock(&ml403_ac97cr->reg_lock);
-	end_time = jiffies + (HZ / CODEC_TIMEOUT_AFTER_READ);
-	do {
-		spin_lock(&ml403_ac97cr->reg_lock);
-#ifdef CODEC_STAT
-		rafaccess++;
-		stat = in_be32(CR_REG(ml403_ac97cr, STATUS));
-		if ((stat & CR_RAF) == CR_RAF) {
-			value = CR_CODEC_DATAREAD(
-				in_be32(CR_REG(ml403_ac97cr, CODEC_DATAREAD)));
-			PDEBUG(CODEC_SUCCESS, "codec_read(): (done) reg=0x%x, "
-			       "value=0x%x / %d (STATUS=0x%x)\n",
-			       reg, value, value, stat);
-#else
-		if ((in_be32(CR_REG(ml403_ac97cr, STATUS)) &
-		     CR_RAF) == CR_RAF) {
-			value = CR_CODEC_DATAREAD(
-				in_be32(CR_REG(ml403_ac97cr, CODEC_DATAREAD)));
-			PDEBUG(CODEC_SUCCESS, "codec_read(): (done) "
-			       "reg=0x%x, value=0x%x / %d\n",
-			       reg, value, value);
-#endif
-			lm4550_regfile[reg / 2].value = value;
-			lm4550_regfile[reg / 2].flag |= LM4550_REG_DONEREAD;
-			spin_unlock(&ml403_ac97cr->reg_lock);
-			mutex_unlock(&ml403_ac97cr->cdc_mutex);
-			return value;
-		}
-		spin_unlock(&ml403_ac97cr->reg_lock);
-		schedule_timeout_uninterruptible(1);
-	} while (time_after(end_time, jiffies));
-	/* read the DATAREAD register anyway, see comment below */
-	spin_lock(&ml403_ac97cr->reg_lock);
-	value =
-	    CR_CODEC_DATAREAD(in_be32(CR_REG(ml403_ac97cr, CODEC_DATAREAD)));
-	spin_unlock(&ml403_ac97cr->reg_lock);
-#ifdef CODEC_STAT
-	snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": "
-		   "timeout while codec read! "
-		   "(reg=0x%x, last STATUS=0x%x, DATAREAD=0x%x / %d, %d) "
-		   "(cw=%d, cr=%d)\n",
-		   reg, stat, value, value, rafaccess,
-		   ml403_ac97cr->ac97_write, ml403_ac97cr->ac97_read);
-#else
-	snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": "
-		   "timeout while codec read! "
-		   "(reg=0x%x, DATAREAD=0x%x / %d)\n",
-		   reg, value, value);
-#endif
-	/* BUG: This is PURE speculation! But after _most_ read timeouts the
-	 * value in the register is ok!
-	 */
-	lm4550_regfile[reg / 2].value = value;
-	lm4550_regfile[reg / 2].flag |= LM4550_REG_DONEREAD;
-	mutex_unlock(&ml403_ac97cr->cdc_mutex);
-	return value;
-}
-
-static void
-snd_ml403_ac97cr_codec_write(struct snd_ac97 *ac97, unsigned short reg,
-			     unsigned short val)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr = ac97->private_data;
-
-#ifdef CODEC_STAT
-	u32 stat;
-	u32 rafaccess = 0;
-#endif
-#ifdef CODEC_WRITE_CHECK_RAF
-	unsigned long end_time;
-#endif
-
-	if (!LM4550_RF_OK(reg)) {
-		snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": "
-			   "access to unknown/unused codec register 0x%x "
-			   "ignored!\n", reg);
-		return;
-	}
-	if (lm4550_regfile[reg / 2].flag & LM4550_REG_READONLY) {
-		snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": "
-			   "write access to read only codec register 0x%x "
-			   "ignored!\n", reg);
-		return;
-	}
-	if ((val & lm4550_regfile[reg / 2].wmask) != val) {
-		snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": "
-			   "write access to codec register 0x%x "
-			   "with bad value 0x%x / %d!\n",
-			   reg, val, val);
-		val = val & lm4550_regfile[reg / 2].wmask;
-	}
-	if (((lm4550_regfile[reg / 2].flag & LM4550_REG_FAKEPROBE) &&
-	     ml403_ac97cr->ac97_fake) &&
-	    !(lm4550_regfile[reg / 2].flag & LM4550_REG_NOSHADOW)) {
-		PDEBUG(CODEC_FAKE, "codec_write(): faking write to reg=0x%x, "
-		       "val=0x%x / %d\n", reg, val, val);
-		lm4550_regfile[reg / 2].value = (val &
-						lm4550_regfile[reg / 2].wmask);
-		return;
-	}
-	if (mutex_lock_interruptible(&ml403_ac97cr->cdc_mutex) != 0)
-		return;
-#ifdef CODEC_STAT
-	ml403_ac97cr->ac97_write++;
-#endif
-	spin_lock(&ml403_ac97cr->reg_lock);
-	out_be32(CR_REG(ml403_ac97cr, CODEC_DATAWRITE),
-		 CR_CODEC_DATAWRITE(val));
-	out_be32(CR_REG(ml403_ac97cr, CODEC_ADDR),
-		 CR_CODEC_ADDR(reg) | CR_CODEC_WRITE);
-	spin_unlock(&ml403_ac97cr->reg_lock);
-#ifdef CODEC_WRITE_CHECK_RAF
-	/* check CR_CODEC_RAF bit to see if write access to register is done;
-	 * loop until bit is set or timeout happens
-	 */
-	end_time = jiffies + HZ / CODEC_TIMEOUT_AFTER_WRITE;
-	do {
-		spin_lock(&ml403_ac97cr->reg_lock);
-#ifdef CODEC_STAT
-		rafaccess++;
-		stat = in_be32(CR_REG(ml403_ac97cr, STATUS))
-		if ((stat & CR_RAF) == CR_RAF) {
-#else
-		if ((in_be32(CR_REG(ml403_ac97cr, STATUS)) &
-		     CR_RAF) == CR_RAF) {
-#endif
-			PDEBUG(CODEC_SUCCESS, "codec_write(): (done) "
-			       "reg=0x%x, value=%d / 0x%x\n",
-			       reg, val, val);
-			if (!(lm4550_regfile[reg / 2].flag &
-			      LM4550_REG_NOSHADOW) &&
-			    !(lm4550_regfile[reg / 2].flag &
-			      LM4550_REG_NOSAVE))
-				lm4550_regfile[reg / 2].value = val;
-			lm4550_regfile[reg / 2].flag |= LM4550_REG_DONEREAD;
-			spin_unlock(&ml403_ac97cr->reg_lock);
-			mutex_unlock(&ml403_ac97cr->cdc_mutex);
-			return;
-		}
-		spin_unlock(&ml403_ac97cr->reg_lock);
-		schedule_timeout_uninterruptible(1);
-	} while (time_after(end_time, jiffies));
-#ifdef CODEC_STAT
-	snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": "
-		   "timeout while codec write "
-		   "(reg=0x%x, val=0x%x / %d, last STATUS=0x%x, %d) "
-		   "(cw=%d, cr=%d)\n",
-		   reg, val, val, stat, rafaccess, ml403_ac97cr->ac97_write,
-		   ml403_ac97cr->ac97_read);
-#else
-	snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": "
-		   "timeout while codec write (reg=0x%x, val=0x%x / %d)\n",
-		   reg, val, val);
-#endif
-#else /* CODEC_WRITE_CHECK_RAF */
-#if CODEC_WAIT_AFTER_WRITE > 0
-	/* officially, in AC97 spec there is no possibility for a AC97
-	 * controller to determine, if write access is done or not - so: How
-	 * is Xilinx able to provide a RAF bit for write access?
-	 * => very strange, thus just don't check RAF bit (compare with
-	 * Xilinx's example app in EDK 8.1i) and wait
-	 */
-	schedule_timeout_uninterruptible(HZ / CODEC_WAIT_AFTER_WRITE);
-#endif
-	PDEBUG(CODEC_SUCCESS, "codec_write(): (done) "
-	       "reg=0x%x, value=%d / 0x%x (no RAF check)\n",
-	       reg, val, val);
-#endif
-	mutex_unlock(&ml403_ac97cr->cdc_mutex);
-	return;
-}
-
-static int
-snd_ml403_ac97cr_chip_init(struct snd_ml403_ac97cr *ml403_ac97cr)
-{
-	unsigned long end_time;
-	PDEBUG(INIT_INFO, "chip_init():\n");
-	end_time = jiffies + HZ / CODEC_TIMEOUT_ON_INIT;
-	do {
-		if (in_be32(CR_REG(ml403_ac97cr, STATUS)) & CR_CODECREADY) {
-			/* clear both hardware FIFOs */
-			out_be32(CR_REG(ml403_ac97cr, RESETFIFO),
-				 CR_RECRESET | CR_PLAYRESET);
-			PDEBUG(INIT_INFO, "chip_init(): (done)\n");
-			return 0;
-		}
-		schedule_timeout_uninterruptible(1);
-	} while (time_after(end_time, jiffies));
-	snd_printk(KERN_ERR SND_ML403_AC97CR_DRIVER ": "
-		   "timeout while waiting for codec, "
-		   "not ready!\n");
-	return -EBUSY;
-}
-
-static int snd_ml403_ac97cr_free(struct snd_ml403_ac97cr *ml403_ac97cr)
-{
-	PDEBUG(INIT_INFO, "free():\n");
-	/* irq release */
-	if (ml403_ac97cr->irq >= 0)
-		free_irq(ml403_ac97cr->irq, ml403_ac97cr);
-	if (ml403_ac97cr->capture_irq >= 0)
-		free_irq(ml403_ac97cr->capture_irq, ml403_ac97cr);
-	/* give back "port" */
-	iounmap(ml403_ac97cr->port);
-	kfree(ml403_ac97cr);
-	PDEBUG(INIT_INFO, "free(): (done)\n");
-	return 0;
-}
-
-static int snd_ml403_ac97cr_dev_free(struct snd_device *snddev)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr = snddev->device_data;
-	PDEBUG(INIT_INFO, "dev_free():\n");
-	return snd_ml403_ac97cr_free(ml403_ac97cr);
-}
-
-static int
-snd_ml403_ac97cr_create(struct snd_card *card, struct platform_device *pfdev,
-			struct snd_ml403_ac97cr **rml403_ac97cr)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr;
-	int err;
-	static const struct snd_device_ops ops = {
-		.dev_free = snd_ml403_ac97cr_dev_free,
-	};
-	struct resource *resource;
-	int irq;
-
-	*rml403_ac97cr = NULL;
-	ml403_ac97cr = kzalloc(sizeof(*ml403_ac97cr), GFP_KERNEL);
-	if (ml403_ac97cr == NULL)
-		return -ENOMEM;
-	spin_lock_init(&ml403_ac97cr->reg_lock);
-	mutex_init(&ml403_ac97cr->cdc_mutex);
-	ml403_ac97cr->card = card;
-	ml403_ac97cr->pfdev = pfdev;
-	ml403_ac97cr->irq = -1;
-	ml403_ac97cr->enable_irq = 0;
-	ml403_ac97cr->capture_irq = -1;
-	ml403_ac97cr->enable_capture_irq = 0;
-	ml403_ac97cr->port = NULL;
-	ml403_ac97cr->res_port = NULL;
-
-	PDEBUG(INIT_INFO, "Trying to reserve resources now ...\n");
-	resource = platform_get_resource(pfdev, IORESOURCE_MEM, 0);
-	/* get "port" */
-	ml403_ac97cr->port = ioremap(resource->start,
-					     (resource->end) -
-					     (resource->start) + 1);
-	if (ml403_ac97cr->port == NULL) {
-		snd_printk(KERN_ERR SND_ML403_AC97CR_DRIVER ": "
-			   "unable to remap memory region (%pR)\n",
-			   resource);
-		snd_ml403_ac97cr_free(ml403_ac97cr);
-		return -EBUSY;
-	}
-	snd_printk(KERN_INFO SND_ML403_AC97CR_DRIVER ": "
-		   "remap controller memory region to "
-		   "0x%x done\n", (unsigned int)ml403_ac97cr->port);
-	/* get irq */
-	irq = platform_get_irq(pfdev, 0);
-	if (request_irq(irq, snd_ml403_ac97cr_irq, 0,
-			dev_name(&pfdev->dev), (void *)ml403_ac97cr)) {
-		snd_printk(KERN_ERR SND_ML403_AC97CR_DRIVER ": "
-			   "unable to grab IRQ %d\n",
-			   irq);
-		snd_ml403_ac97cr_free(ml403_ac97cr);
-		return -EBUSY;
-	}
-	ml403_ac97cr->irq = irq;
-	snd_printk(KERN_INFO SND_ML403_AC97CR_DRIVER ": "
-		   "request (playback) irq %d done\n",
-		   ml403_ac97cr->irq);
-	irq = platform_get_irq(pfdev, 1);
-	if (request_irq(irq, snd_ml403_ac97cr_irq, 0,
-			dev_name(&pfdev->dev), (void *)ml403_ac97cr)) {
-		snd_printk(KERN_ERR SND_ML403_AC97CR_DRIVER ": "
-			   "unable to grab IRQ %d\n",
-			   irq);
-		snd_ml403_ac97cr_free(ml403_ac97cr);
-		return -EBUSY;
-	}
-	ml403_ac97cr->capture_irq = irq;
-	snd_printk(KERN_INFO SND_ML403_AC97CR_DRIVER ": "
-		   "request (capture) irq %d done\n",
-		   ml403_ac97cr->capture_irq);
-
-	err = snd_ml403_ac97cr_chip_init(ml403_ac97cr);
-	if (err < 0) {
-		snd_ml403_ac97cr_free(ml403_ac97cr);
-		return err;
-	}
-
-	err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, ml403_ac97cr, &ops);
-	if (err < 0) {
-		PDEBUG(INIT_FAILURE, "probe(): snd_device_new() failed!\n");
-		snd_ml403_ac97cr_free(ml403_ac97cr);
-		return err;
-	}
-
-	*rml403_ac97cr = ml403_ac97cr;
-	return 0;
-}
-
-static void snd_ml403_ac97cr_mixer_free(struct snd_ac97 *ac97)
-{
-	struct snd_ml403_ac97cr *ml403_ac97cr = ac97->private_data;
-	PDEBUG(INIT_INFO, "mixer_free():\n");
-	ml403_ac97cr->ac97 = NULL;
-	PDEBUG(INIT_INFO, "mixer_free(): (done)\n");
-}
-
-static int
-snd_ml403_ac97cr_mixer(struct snd_ml403_ac97cr *ml403_ac97cr)
-{
-	struct snd_ac97_bus *bus;
-	struct snd_ac97_template ac97;
-	int err;
-	static const struct snd_ac97_bus_ops ops = {
-		.write = snd_ml403_ac97cr_codec_write,
-		.read = snd_ml403_ac97cr_codec_read,
-	};
-	PDEBUG(INIT_INFO, "mixer():\n");
-	err = snd_ac97_bus(ml403_ac97cr->card, 0, &ops, NULL, &bus);
-	if (err < 0)
-		return err;
-
-	memset(&ac97, 0, sizeof(ac97));
-	ml403_ac97cr->ac97_fake = 1;
-	lm4550_regfile_init();
-#ifdef CODEC_STAT
-	ml403_ac97cr->ac97_read = 0;
-	ml403_ac97cr->ac97_write = 0;
-#endif
-	ac97.private_data = ml403_ac97cr;
-	ac97.private_free = snd_ml403_ac97cr_mixer_free;
-	ac97.scaps = AC97_SCAP_AUDIO | AC97_SCAP_SKIP_MODEM |
-	    AC97_SCAP_NO_SPDIF;
-	err = snd_ac97_mixer(bus, &ac97, &ml403_ac97cr->ac97);
-	ml403_ac97cr->ac97_fake = 0;
-	lm4550_regfile_write_values_after_init(ml403_ac97cr->ac97);
-	PDEBUG(INIT_INFO, "mixer(): (done) snd_ac97_mixer()=%d\n", err);
-	return err;
-}
-
-static int
-snd_ml403_ac97cr_pcm(struct snd_ml403_ac97cr *ml403_ac97cr, int device)
-{
-	struct snd_pcm *pcm;
-	int err;
-
-	err = snd_pcm_new(ml403_ac97cr->card, "ML403AC97CR/1", device, 1, 1,
-			  &pcm);
-	if (err < 0)
-		return err;
-	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK,
-			&snd_ml403_ac97cr_playback_ops);
-	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE,
-			&snd_ml403_ac97cr_capture_ops);
-	pcm->private_data = ml403_ac97cr;
-	pcm->info_flags = 0;
-	strcpy(pcm->name, "ML403AC97CR DAC/ADC");
-	ml403_ac97cr->pcm = pcm;
-
-	snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_CONTINUOUS,
-				       NULL,
-				       64 * 1024,
-				       128 * 1024);
-	return 0;
-}
-
-static int snd_ml403_ac97cr_probe(struct platform_device *pfdev)
-{
-	struct snd_card *card;
-	struct snd_ml403_ac97cr *ml403_ac97cr = NULL;
-	int err;
-	int dev = pfdev->id;
-
-	if (dev >= SNDRV_CARDS)
-		return -ENODEV;
-	if (!enable[dev])
-		return -ENOENT;
-
-	err = snd_card_new(&pfdev->dev, index[dev], id[dev], THIS_MODULE,
-			   0, &card);
-	if (err < 0)
-		return err;
-	err = snd_ml403_ac97cr_create(card, pfdev, &ml403_ac97cr);
-	if (err < 0) {
-		PDEBUG(INIT_FAILURE, "probe(): create failed!\n");
-		snd_card_free(card);
-		return err;
-	}
-	PDEBUG(INIT_INFO, "probe(): create done\n");
-	card->private_data = ml403_ac97cr;
-	err = snd_ml403_ac97cr_mixer(ml403_ac97cr);
-	if (err < 0) {
-		snd_card_free(card);
-		return err;
-	}
-	PDEBUG(INIT_INFO, "probe(): mixer done\n");
-	err = snd_ml403_ac97cr_pcm(ml403_ac97cr, 0);
-	if (err < 0) {
-		snd_card_free(card);
-		return err;
-	}
-	PDEBUG(INIT_INFO, "probe(): PCM done\n");
-	strcpy(card->driver, SND_ML403_AC97CR_DRIVER);
-	strcpy(card->shortname, "ML403 AC97 Controller Reference");
-	sprintf(card->longname, "%s %s at 0x%lx, irq %i & %i, device %i",
-		card->shortname, card->driver,
-		(unsigned long)ml403_ac97cr->port, ml403_ac97cr->irq,
-		ml403_ac97cr->capture_irq, dev + 1);
-
-	err = snd_card_register(card);
-	if (err < 0) {
-		snd_card_free(card);
-		return err;
-	}
-	platform_set_drvdata(pfdev, card);
-	PDEBUG(INIT_INFO, "probe(): (done)\n");
-	return 0;
-}
-
-static int snd_ml403_ac97cr_remove(struct platform_device *pfdev)
-{
-	snd_card_free(platform_get_drvdata(pfdev));
-	return 0;
-}
-
-/* work with hotplug and coldplug */
-MODULE_ALIAS("platform:" SND_ML403_AC97CR_DRIVER);
-
-static struct platform_driver snd_ml403_ac97cr_driver = {
-	.probe = snd_ml403_ac97cr_probe,
-	.remove = snd_ml403_ac97cr_remove,
-	.driver = {
-		.name = SND_ML403_AC97CR_DRIVER,
-	},
-};
-
-module_platform_driver(snd_ml403_ac97cr_driver);
-- 
2.26.0

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Arnd Bergmann]

On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote:
>
> recently we wanted to update xilinx intc driver and we found that function
> which we wanted to remove is still wired by ancient Xilinx PowerPC
> platforms. Here is the thread about it.
> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xilinx.com/
>
> I have been talking about it internally and there is no interest in these
> platforms and it is also orphan for quite a long time. None is really
> running/testing these platforms regularly that's why I think it makes sense
> to remove them also with drivers which are specific to this platform.
>
> U-Boot support was removed in 2017 without anybody complain about it
> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed
>
> Based on current ppc/next.
>
> If anyone has any objection about it, please let me know.

Acked-by: Arnd Bergmann <arnd@arndb.de>

This looks reasonable to me as well, in particular as the code only
supports the two
ppc44x virtex developer boards and no commercial products.

It does raise a follow-up question about ppc40x though: is it time to
retire all of it?
The other ppc405 machines appear to have seen even fewer updates after the
OpenBlockS 600 got added in 2011, so it's possible nobody is using them any more
with modern kernels.

I see that OpenWRT removed both ppc40x and ppc44x exactly a year ago after
they had not been maintained for years.

However, 44x (in its ppc476 incarnation) is clearly still is used
through the fsp2 platform,
and can not be deprecated at least until that is known to have stopped
getting kernel
updates.

        Arnd

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Andy Shevchenko]

On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote:
> >
> > recently we wanted to update xilinx intc driver and we found that function
> > which we wanted to remove is still wired by ancient Xilinx PowerPC
> > platforms. Here is the thread about it.
> > https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xilinx.com/
> >
> > I have been talking about it internally and there is no interest in these
> > platforms and it is also orphan for quite a long time. None is really
> > running/testing these platforms regularly that's why I think it makes sense
> > to remove them also with drivers which are specific to this platform.
> >
> > U-Boot support was removed in 2017 without anybody complain about it
> > https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed
> >
> > Based on current ppc/next.
> >
> > If anyone has any objection about it, please let me know.
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> This looks reasonable to me as well, in particular as the code only
> supports the two
> ppc44x virtex developer boards and no commercial products.
> 
> It does raise a follow-up question about ppc40x though: is it time to
> retire all of it?

Who knows?

I have in possession nice WD My Book Live, based on this architecture, and I
won't it gone from modern kernel support. OTOH I understand that amount of real
users not too big.

Ah, and I have Amiga board, but that one is being used only for testing, so,
I don't care much.

> The other ppc405 machines appear to have seen even fewer updates after the
> OpenBlockS 600 got added in 2011, so it's possible nobody is using them any more
> with modern kernels.
> 
> I see that OpenWRT removed both ppc40x and ppc44x exactly a year ago after
> they had not been maintained for years.
> 
> However, 44x (in its ppc476 incarnation) is clearly still is used
> through the fsp2 platform,
> and can not be deprecated at least until that is known to have stopped
> getting kernel
> updates.
> 
>         Arnd

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Andy Shevchenko]

On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
> > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote:
> > >
> > > recently we wanted to update xilinx intc driver and we found that function
> > > which we wanted to remove is still wired by ancient Xilinx PowerPC
> > > platforms. Here is the thread about it.
> > > https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xilinx.com/
> > >
> > > I have been talking about it internally and there is no interest in these
> > > platforms and it is also orphan for quite a long time. None is really
> > > running/testing these platforms regularly that's why I think it makes sense
> > > to remove them also with drivers which are specific to this platform.
> > >
> > > U-Boot support was removed in 2017 without anybody complain about it
> > > https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed
> > >
> > > Based on current ppc/next.
> > >
> > > If anyone has any objection about it, please let me know.
> > 
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > 
> > This looks reasonable to me as well, in particular as the code only
> > supports the two
> > ppc44x virtex developer boards and no commercial products.
> > 
> > It does raise a follow-up question about ppc40x though: is it time to
> > retire all of it?
> 
> Who knows?
> 
> I have in possession nice WD My Book Live, based on this architecture, and I
> won't it gone from modern kernel support. OTOH I understand that amount of real
> users not too big.

+Cc: Christian Lamparter, whom I owe for that WD box.

> 
> Ah, and I have Amiga board, but that one is being used only for testing, so,
> I don't care much.
> 
> > The other ppc405 machines appear to have seen even fewer updates after the
> > OpenBlockS 600 got added in 2011, so it's possible nobody is using them any more
> > with modern kernels.
> > 
> > I see that OpenWRT removed both ppc40x and ppc44x exactly a year ago after
> > they had not been maintained for years.
> > 
> > However, 44x (in its ppc476 incarnation) is clearly still is used
> > through the fsp2 platform,
> > and can not be deprecated at least until that is known to have stopped
> > getting kernel
> > updates.
> > 
> >         Arnd
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Arnd Bergmann]

On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
> > > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote:
> > > >
> > > > recently we wanted to update xilinx intc driver and we found that function
> > > > which we wanted to remove is still wired by ancient Xilinx PowerPC
> > > > platforms. Here is the thread about it.
> > > > https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xilinx.com/
> > > >
> > > > I have been talking about it internally and there is no interest in these
> > > > platforms and it is also orphan for quite a long time. None is really
> > > > running/testing these platforms regularly that's why I think it makes sense
> > > > to remove them also with drivers which are specific to this platform.
> > > >
> > > > U-Boot support was removed in 2017 without anybody complain about it
> > > > https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed
> > > >
> > > > Based on current ppc/next.
> > > >
> > > > If anyone has any objection about it, please let me know.
> > >
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > This looks reasonable to me as well, in particular as the code only
> > > supports the two
> > > ppc44x virtex developer boards and no commercial products.
> > >
> > > It does raise a follow-up question about ppc40x though: is it time to
> > > retire all of it?
> >
> > Who knows?
> >
> > I have in possession nice WD My Book Live, based on this architecture, and I
> > won't it gone from modern kernel support. OTOH I understand that amount of real
> > users not too big.
>
> +Cc: Christian Lamparter, whom I owe for that WD box.

According to https://openwrt.org/toh/wd/mybooklive, that one is based on
APM82181/ppc464, so it is about several generations newer than what I
asked about (ppc40x).

> > Ah, and I have Amiga board, but that one is being used only for testing, so,
> > I don't care much.

I think there are a couple of ppc440 based Amiga boards, but again, not 405
to my knowledge.

      Arnd

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Andy Shevchenko]

On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
> > > > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote:

...

> > > > It does raise a follow-up question about ppc40x though: is it time to
> > > > retire all of it?
> > >
> > > Who knows?
> > >
> > > I have in possession nice WD My Book Live, based on this architecture, and I
> > > won't it gone from modern kernel support. OTOH I understand that amount of real
> > > users not too big.
> >
> > +Cc: Christian Lamparter, whom I owe for that WD box.
> 
> According to https://openwrt.org/toh/wd/mybooklive, that one is based on
> APM82181/ppc464, so it is about several generations newer than what I
> asked about (ppc40x).
> 
> > > Ah, and I have Amiga board, but that one is being used only for testing, so,
> > > I don't care much.
> 
> I think there are a couple of ppc440 based Amiga boards, but again, not 405
> to my knowledge.

Ah, you are right. No objections from ppc40x removal!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] sound: ac97: Remove sound driver for ancient platform

[Takashi Iwai]

On Fri, 27 Mar 2020 13:12:21 +0100,
Michal Simek wrote:
> 
> Xilinx PowerPC platforms are no longer supported and none is really testing
> these platforms that's why remove them. If someone has any issue with it
> these patches can be reverted.
> 
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> 
>  sound/drivers/Kconfig        |   12 -
>  sound/drivers/Makefile       |    2 -
>  sound/drivers/ml403-ac97cr.c | 1298 ----------------------------------

I believe that sound/drivers/pcm-indirect2.[ch] can be removed
altogether as it's used/linked only by this driver.

With that,
  Acked-by: Takashi Iwai <tiwai@suse.de>


thanks,

Takashi

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
>> <andriy.shevchenko@linux.intel.com> wrote:
>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote:
> 
> ...
> 
>>>>> It does raise a follow-up question about ppc40x though: is it time to
>>>>> retire all of it?
>>>>
>>>> Who knows?
>>>>
>>>> I have in possession nice WD My Book Live, based on this architecture, and I
>>>> won't it gone from modern kernel support. OTOH I understand that amount of real
>>>> users not too big.
>>>
>>> +Cc: Christian Lamparter, whom I owe for that WD box.
>>
>> According to https://openwrt.org/toh/wd/mybooklive, that one is based on
>> APM82181/ppc464, so it is about several generations newer than what I
>> asked about (ppc40x).
>>
>>>> Ah, and I have Amiga board, but that one is being used only for testing, so,
>>>> I don't care much.
>>
>> I think there are a couple of ppc440 based Amiga boards, but again, not 405
>> to my knowledge.
> 
> Ah, you are right. No objections from ppc40x removal!
> 

Removing 40x would help cleaning things a bit. For instance 40x is the 
last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x 
we can get rid of PTE_ATOMIC_UPDATES completely.


If no one objects, I can prepare a series to drop support for 40x 
completely.

Michael, any thought ?

Christophe

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michael Ellerman]

Christophe Leroy <christophe.leroy@c-s.fr> writes:
> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
>>> <andriy.shevchenko@linux.intel.com> wrote:
>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote:
>> ...
>> 
>>>>>> It does raise a follow-up question about ppc40x though: is it time to
>>>>>> retire all of it?
>>>>>
>>>>> Who knows?
>>>>>
>>>>> I have in possession nice WD My Book Live, based on this architecture, and I
>>>>> won't it gone from modern kernel support. OTOH I understand that amount of real
>>>>> users not too big.
>>>>
>>>> +Cc: Christian Lamparter, whom I owe for that WD box.
>>>
>>> According to https://openwrt.org/toh/wd/mybooklive, that one is based on
>>> APM82181/ppc464, so it is about several generations newer than what I
>>> asked about (ppc40x).
>>>
>>>>> Ah, and I have Amiga board, but that one is being used only for testing, so,
>>>>> I don't care much.
>>>
>>> I think there are a couple of ppc440 based Amiga boards, but again, not 405
>>> to my knowledge.
>> 
>> Ah, you are right. No objections from ppc40x removal!
>
> Removing 40x would help cleaning things a bit. For instance 40x is the 
> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x 
> we can get rid of PTE_ATOMIC_UPDATES completely.
>
> If no one objects, I can prepare a series to drop support for 40x 
> completely.
>
> Michael, any thought ?

I have no attachment to 40x, and I'd certainly be happy to have less
code in the tree, we struggle to keep even the modern platforms well
maintained.

At the same time I don't want to render anyone's hardware obsolete
unnecessarily. But if there's really no one using 40x then we should
remove it, it could well be broken already.

So I guess post a series to do the removal and we'll see if anyone
speaks up.

cheers

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
>>>> <andriy.shevchenko@linux.intel.com> wrote:
>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote:
>>> ...
>>>
>>>>>>> It does raise a follow-up question about ppc40x though: is it time to
>>>>>>> retire all of it?
>>>>>>
>>>>>> Who knows?
>>>>>>
>>>>>> I have in possession nice WD My Book Live, based on this architecture, and I
>>>>>> won't it gone from modern kernel support. OTOH I understand that amount of real
>>>>>> users not too big.
>>>>>
>>>>> +Cc: Christian Lamparter, whom I owe for that WD box.
>>>>
>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is based on
>>>> APM82181/ppc464, so it is about several generations newer than what I
>>>> asked about (ppc40x).
>>>>
>>>>>> Ah, and I have Amiga board, but that one is being used only for testing, so,
>>>>>> I don't care much.
>>>>
>>>> I think there are a couple of ppc440 based Amiga boards, but again, not 405
>>>> to my knowledge.
>>>
>>> Ah, you are right. No objections from ppc40x removal!
>>
>> Removing 40x would help cleaning things a bit. For instance 40x is the
>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x
>> we can get rid of PTE_ATOMIC_UPDATES completely.
>>
>> If no one objects, I can prepare a series to drop support for 40x
>> completely.
>>
>> Michael, any thought ?
> 
> I have no attachment to 40x, and I'd certainly be happy to have less
> code in the tree, we struggle to keep even the modern platforms well
> maintained.
> 
> At the same time I don't want to render anyone's hardware obsolete
> unnecessarily. But if there's really no one using 40x then we should
> remove it, it could well be broken already.
> 
> So I guess post a series to do the removal and we'll see if anyone
> speaks up.
> 

Ok, series sent out, see 
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757


While we are at it, can we also remove the 601 ? This one is also full 
of workarounds and diverges a bit from other 6xx.

I'm unable to find its end of life date, but it was on the market in 
1994, so I guess it must be outdated by more than 10-15 yr old now ?

Christophe

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michal Simek]

On 31. 03. 20 8:56, Christophe Leroy wrote:
> 
> 
> Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
>>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
>>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
>>>>> <andriy.shevchenko@linux.intel.com> wrote:
>>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
>>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
>>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
>>>>>>>> <michal.simek@xilinx.com> wrote:
>>>> ...
>>>>
>>>>>>>> It does raise a follow-up question about ppc40x though: is it
>>>>>>>> time to
>>>>>>>> retire all of it?
>>>>>>>
>>>>>>> Who knows?
>>>>>>>
>>>>>>> I have in possession nice WD My Book Live, based on this
>>>>>>> architecture, and I
>>>>>>> won't it gone from modern kernel support. OTOH I understand that
>>>>>>> amount of real
>>>>>>> users not too big.
>>>>>>
>>>>>> +Cc: Christian Lamparter, whom I owe for that WD box.
>>>>>
>>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is
>>>>> based on
>>>>> APM82181/ppc464, so it is about several generations newer than what I
>>>>> asked about (ppc40x).
>>>>>
>>>>>>> Ah, and I have Amiga board, but that one is being used only for
>>>>>>> testing, so,
>>>>>>> I don't care much.
>>>>>
>>>>> I think there are a couple of ppc440 based Amiga boards, but again,
>>>>> not 405
>>>>> to my knowledge.
>>>>
>>>> Ah, you are right. No objections from ppc40x removal!
>>>
>>> Removing 40x would help cleaning things a bit. For instance 40x is the
>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x
>>> we can get rid of PTE_ATOMIC_UPDATES completely.
>>>
>>> If no one objects, I can prepare a series to drop support for 40x
>>> completely.
>>>
>>> Michael, any thought ?
>>
>> I have no attachment to 40x, and I'd certainly be happy to have less
>> code in the tree, we struggle to keep even the modern platforms well
>> maintained.
>>
>> At the same time I don't want to render anyone's hardware obsolete
>> unnecessarily. But if there's really no one using 40x then we should
>> remove it, it could well be broken already.
>>
>> So I guess post a series to do the removal and we'll see if anyone
>> speaks up.
>>
> 
> Ok, series sent out, see
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757

ok. I see you have done it completely independently of my patchset.
Would be better if you can base it on the top of my 2 patches because
they are in conflict now and I need to also remove virtex 44x platform
also with alsa driver.

Thanks,
Michal

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 31/03/2020 à 08:59, Michal Simek a écrit :
> On 31. 03. 20 8:56, Christophe Leroy wrote:
>>
>>
>> Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
>>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
>>>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
>>>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
>>>>>> <andriy.shevchenko@linux.intel.com> wrote:
>>>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
>>>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
>>>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
>>>>>>>>> <michal.simek@xilinx.com> wrote:
>>>>> ...
>>>>>
>>>>>>>>> It does raise a follow-up question about ppc40x though: is it
>>>>>>>>> time to
>>>>>>>>> retire all of it?
>>>>>>>>
>>>>>>>> Who knows?
>>>>>>>>
>>>>>>>> I have in possession nice WD My Book Live, based on this
>>>>>>>> architecture, and I
>>>>>>>> won't it gone from modern kernel support. OTOH I understand that
>>>>>>>> amount of real
>>>>>>>> users not too big.
>>>>>>>
>>>>>>> +Cc: Christian Lamparter, whom I owe for that WD box.
>>>>>>
>>>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is
>>>>>> based on
>>>>>> APM82181/ppc464, so it is about several generations newer than what I
>>>>>> asked about (ppc40x).
>>>>>>
>>>>>>>> Ah, and I have Amiga board, but that one is being used only for
>>>>>>>> testing, so,
>>>>>>>> I don't care much.
>>>>>>
>>>>>> I think there are a couple of ppc440 based Amiga boards, but again,
>>>>>> not 405
>>>>>> to my knowledge.
>>>>>
>>>>> Ah, you are right. No objections from ppc40x removal!
>>>>
>>>> Removing 40x would help cleaning things a bit. For instance 40x is the
>>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x
>>>> we can get rid of PTE_ATOMIC_UPDATES completely.
>>>>
>>>> If no one objects, I can prepare a series to drop support for 40x
>>>> completely.
>>>>
>>>> Michael, any thought ?
>>>
>>> I have no attachment to 40x, and I'd certainly be happy to have less
>>> code in the tree, we struggle to keep even the modern platforms well
>>> maintained.
>>>
>>> At the same time I don't want to render anyone's hardware obsolete
>>> unnecessarily. But if there's really no one using 40x then we should
>>> remove it, it could well be broken already.
>>>
>>> So I guess post a series to do the removal and we'll see if anyone
>>> speaks up.
>>>
>>
>> Ok, series sent out, see
>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
> 
> ok. I see you have done it completely independently of my patchset.
> Would be better if you can base it on the top of my 2 patches because
> they are in conflict now and I need to also remove virtex 44x platform
> also with alsa driver.
> 

I can't see your first patch, only the second one shows up in the 
series, see 
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757

Christophe

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 31/03/2020 à 09:19, Christophe Leroy a écrit :
> 
> 
> Le 31/03/2020 à 08:59, Michal Simek a écrit :
>> On 31. 03. 20 8:56, Christophe Leroy wrote:
>>>
>>>
>>> Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
>>>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
>>>>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
>>>>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
>>>>>>> <andriy.shevchenko@linux.intel.com> wrote:
>>>>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
>>>>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
>>>>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
>>>>>>>>>> <michal.simek@xilinx.com> wrote:
>>>>>> ...
>>>>>>
>>>>>>>>>> It does raise a follow-up question about ppc40x though: is it
>>>>>>>>>> time to
>>>>>>>>>> retire all of it?
>>>>>>>>>
>>>>>>>>> Who knows?
>>>>>>>>>
>>>>>>>>> I have in possession nice WD My Book Live, based on this
>>>>>>>>> architecture, and I
>>>>>>>>> won't it gone from modern kernel support. OTOH I understand that
>>>>>>>>> amount of real
>>>>>>>>> users not too big.
>>>>>>>>
>>>>>>>> +Cc: Christian Lamparter, whom I owe for that WD box.
>>>>>>>
>>>>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is
>>>>>>> based on
>>>>>>> APM82181/ppc464, so it is about several generations newer than 
>>>>>>> what I
>>>>>>> asked about (ppc40x).
>>>>>>>
>>>>>>>>> Ah, and I have Amiga board, but that one is being used only for
>>>>>>>>> testing, so,
>>>>>>>>> I don't care much.
>>>>>>>
>>>>>>> I think there are a couple of ppc440 based Amiga boards, but again,
>>>>>>> not 405
>>>>>>> to my knowledge.
>>>>>>
>>>>>> Ah, you are right. No objections from ppc40x removal!
>>>>>
>>>>> Removing 40x would help cleaning things a bit. For instance 40x is the
>>>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x
>>>>> we can get rid of PTE_ATOMIC_UPDATES completely.
>>>>>
>>>>> If no one objects, I can prepare a series to drop support for 40x
>>>>> completely.
>>>>>
>>>>> Michael, any thought ?
>>>>
>>>> I have no attachment to 40x, and I'd certainly be happy to have less
>>>> code in the tree, we struggle to keep even the modern platforms well
>>>> maintained.
>>>>
>>>> At the same time I don't want to render anyone's hardware obsolete
>>>> unnecessarily. But if there's really no one using 40x then we should
>>>> remove it, it could well be broken already.
>>>>
>>>> So I guess post a series to do the removal and we'll see if anyone
>>>> speaks up.
>>>>
>>>
>>> Ok, series sent out, see
>>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
>>
>> ok. I see you have done it completely independently of my patchset.
>> Would be better if you can base it on the top of my 2 patches because
>> they are in conflict now and I need to also remove virtex 44x platform
>> also with alsa driver.
>>
> 
> I can't see your first patch, only the second one shows up in the 
> series, see 
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
> 


Ok, I found your first patch on another patchwork, it doesn't touch any 
file in arch/powerpc/

I sent a v2 series with your powerpc patch as patch 2/11

See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167766

Christophe

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michal Simek]

On 31. 03. 20 11:49, Christophe Leroy wrote:
> 
> 
> Le 31/03/2020 à 09:19, Christophe Leroy a écrit :
>>
>>
>> Le 31/03/2020 à 08:59, Michal Simek a écrit :
>>> On 31. 03. 20 8:56, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
>>>>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>>>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
>>>>>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
>>>>>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
>>>>>>>> <andriy.shevchenko@linux.intel.com> wrote:
>>>>>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
>>>>>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
>>>>>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
>>>>>>>>>>> <michal.simek@xilinx.com> wrote:
>>>>>>> ...
>>>>>>>
>>>>>>>>>>> It does raise a follow-up question about ppc40x though: is it
>>>>>>>>>>> time to
>>>>>>>>>>> retire all of it?
>>>>>>>>>>
>>>>>>>>>> Who knows?
>>>>>>>>>>
>>>>>>>>>> I have in possession nice WD My Book Live, based on this
>>>>>>>>>> architecture, and I
>>>>>>>>>> won't it gone from modern kernel support. OTOH I understand that
>>>>>>>>>> amount of real
>>>>>>>>>> users not too big.
>>>>>>>>>
>>>>>>>>> +Cc: Christian Lamparter, whom I owe for that WD box.
>>>>>>>>
>>>>>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is
>>>>>>>> based on
>>>>>>>> APM82181/ppc464, so it is about several generations newer than
>>>>>>>> what I
>>>>>>>> asked about (ppc40x).
>>>>>>>>
>>>>>>>>>> Ah, and I have Amiga board, but that one is being used only for
>>>>>>>>>> testing, so,
>>>>>>>>>> I don't care much.
>>>>>>>>
>>>>>>>> I think there are a couple of ppc440 based Amiga boards, but again,
>>>>>>>> not 405
>>>>>>>> to my knowledge.
>>>>>>>
>>>>>>> Ah, you are right. No objections from ppc40x removal!
>>>>>>
>>>>>> Removing 40x would help cleaning things a bit. For instance 40x is
>>>>>> the
>>>>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove
>>>>>> 40x
>>>>>> we can get rid of PTE_ATOMIC_UPDATES completely.
>>>>>>
>>>>>> If no one objects, I can prepare a series to drop support for 40x
>>>>>> completely.
>>>>>>
>>>>>> Michael, any thought ?
>>>>>
>>>>> I have no attachment to 40x, and I'd certainly be happy to have less
>>>>> code in the tree, we struggle to keep even the modern platforms well
>>>>> maintained.
>>>>>
>>>>> At the same time I don't want to render anyone's hardware obsolete
>>>>> unnecessarily. But if there's really no one using 40x then we should
>>>>> remove it, it could well be broken already.
>>>>>
>>>>> So I guess post a series to do the removal and we'll see if anyone
>>>>> speaks up.
>>>>>
>>>>
>>>> Ok, series sent out, see
>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
>>>
>>> ok. I see you have done it completely independently of my patchset.
>>> Would be better if you can base it on the top of my 2 patches because
>>> they are in conflict now and I need to also remove virtex 44x platform
>>> also with alsa driver.
>>>
>>
>> I can't see your first patch, only the second one shows up in the
>> series, see
>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
>>
> 
> 
> Ok, I found your first patch on another patchwork, it doesn't touch any
> file in arch/powerpc/

There was just driver dependency on symbol which is removed by 2/2.
Let's see what you get from kbuild if any symbol is removed but still
used in drivers folder.

> 
> I sent a v2 series with your powerpc patch as patch 2/11
> 
> See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167766

Thanks,
Michal

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 31/03/2020 à 12:04, Michal Simek a écrit :
> On 31. 03. 20 11:49, Christophe Leroy wrote:
>>
>>
>> Le 31/03/2020 à 09:19, Christophe Leroy a écrit :
>>>
>>>
>>> Le 31/03/2020 à 08:59, Michal Simek a écrit :
>>>> On 31. 03. 20 8:56, Christophe Leroy wrote:
>>>>>
>>>>>
>>>>> Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
>>>>>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>>>>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
>>>>>>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
>>>>>>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
>>>>>>>>> <andriy.shevchenko@linux.intel.com> wrote:
>>>>>>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
>>>>>>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
>>>>>>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
>>>>>>>>>>>> <michal.simek@xilinx.com> wrote:
>>>>>>>> ...
>>>>>>>>
>>>>>>>>>>>> It does raise a follow-up question about ppc40x though: is it
>>>>>>>>>>>> time to
>>>>>>>>>>>> retire all of it?
>>>>>>>>>>>
>>>>>>>>>>> Who knows?
>>>>>>>>>>>
>>>>>>>>>>> I have in possession nice WD My Book Live, based on this
>>>>>>>>>>> architecture, and I
>>>>>>>>>>> won't it gone from modern kernel support. OTOH I understand that
>>>>>>>>>>> amount of real
>>>>>>>>>>> users not too big.
>>>>>>>>>>
>>>>>>>>>> +Cc: Christian Lamparter, whom I owe for that WD box.
>>>>>>>>>
>>>>>>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is
>>>>>>>>> based on
>>>>>>>>> APM82181/ppc464, so it is about several generations newer than
>>>>>>>>> what I
>>>>>>>>> asked about (ppc40x).
>>>>>>>>>
>>>>>>>>>>> Ah, and I have Amiga board, but that one is being used only for
>>>>>>>>>>> testing, so,
>>>>>>>>>>> I don't care much.
>>>>>>>>>
>>>>>>>>> I think there are a couple of ppc440 based Amiga boards, but again,
>>>>>>>>> not 405
>>>>>>>>> to my knowledge.
>>>>>>>>
>>>>>>>> Ah, you are right. No objections from ppc40x removal!
>>>>>>>
>>>>>>> Removing 40x would help cleaning things a bit. For instance 40x is
>>>>>>> the
>>>>>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove
>>>>>>> 40x
>>>>>>> we can get rid of PTE_ATOMIC_UPDATES completely.
>>>>>>>
>>>>>>> If no one objects, I can prepare a series to drop support for 40x
>>>>>>> completely.
>>>>>>>
>>>>>>> Michael, any thought ?
>>>>>>
>>>>>> I have no attachment to 40x, and I'd certainly be happy to have less
>>>>>> code in the tree, we struggle to keep even the modern platforms well
>>>>>> maintained.
>>>>>>
>>>>>> At the same time I don't want to render anyone's hardware obsolete
>>>>>> unnecessarily. But if there's really no one using 40x then we should
>>>>>> remove it, it could well be broken already.
>>>>>>
>>>>>> So I guess post a series to do the removal and we'll see if anyone
>>>>>> speaks up.
>>>>>>
>>>>>
>>>>> Ok, series sent out, see
>>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
>>>>
>>>> ok. I see you have done it completely independently of my patchset.
>>>> Would be better if you can base it on the top of my 2 patches because
>>>> they are in conflict now and I need to also remove virtex 44x platform
>>>> also with alsa driver.
>>>>
>>>
>>> I can't see your first patch, only the second one shows up in the
>>> series, see
>>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
>>>
>>
>>
>> Ok, I found your first patch on another patchwork, it doesn't touch any
>> file in arch/powerpc/
> 
> There was just driver dependency on symbol which is removed by 2/2.
> Let's see what you get from kbuild if any symbol is removed but still
> used in drivers folder.

Nothing bad apparently, see build test at 
http://kisskb.ellerman.id.au/kisskb/head/a4890e3fb046950e9a62dc3eff5b37469551e823/

Christophe

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Segher Boessenkool]

On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote:
> While we are at it, can we also remove the 601 ? This one is also full 
> of workarounds and diverges a bit from other 6xx.
> 
> I'm unable to find its end of life date, but it was on the market in 
> 1994, so I guess it must be outdated by more than 10-15 yr old now ?

There probably are still some people running Linux on 601 powermacs.


Segher

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Arnd Bergmann]

On Tue, Mar 31, 2020 at 7:51 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote:
> > While we are at it, can we also remove the 601 ? This one is also full
> > of workarounds and diverges a bit from other 6xx.
> >
> > I'm unable to find its end of life date, but it was on the market in
> > 1994, so I guess it must be outdated by more than 10-15 yr old now ?
>
> There probably are still some people running Linux on 601 powermacs.

It could be marked as "BROKEN" for a year to find out for sure ;-)

Apparently there were only two or three models that are old enough to
have a 601 and new enough to run Linux with PCI and OF: 7200/8200
and 7500. These were sold for less than 18 months around 1996,
though one can still find them on eBay.

           Arnd

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Benjamin Herrenschmidt]

On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
> I have no attachment to 40x, and I'd certainly be happy to have less
> code in the tree, we struggle to keep even the modern platforms well
> maintained.
> 
> At the same time I don't want to render anyone's hardware obsolete
> unnecessarily. But if there's really no one using 40x then we should
> remove it, it could well be broken already.
> 
> So I guess post a series to do the removal and we'll see if anyone
> speaks up.

We shouldn't remove 40x completely. Just remove the Xilinx 405 stuff.

Cheers,
Ben.

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Arnd Bergmann]

On Wed, Apr 1, 2020 at 11:07 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Mar 31, 2020 at 7:51 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote:
> > > While we are at it, can we also remove the 601 ? This one is also full
> > > of workarounds and diverges a bit from other 6xx.
> > >
> > > I'm unable to find its end of life date, but it was on the market in
> > > 1994, so I guess it must be outdated by more than 10-15 yr old now ?
> >
> > There probably are still some people running Linux on 601 powermacs.
>
> It could be marked as "BROKEN" for a year to find out for sure ;-)
>
> Apparently there were only two or three models that are old enough to
> have a 601 and new enough to run Linux with PCI and OF: 7200/8200
> and 7500. These were sold for less than 18 months around 1996,
> though one can still find them on eBay.

A. Wilcox said on IRC regarding 601 support in Adélie Linux:

"right now we are primarily targeting G3, though 603 should be supported.
601/601e support is planned to be added for 2.0 (next year)."

      Arnd

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michael Ellerman]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
>> I have no attachment to 40x, and I'd certainly be happy to have less
>> code in the tree, we struggle to keep even the modern platforms well
>> maintained.
>> 
>> At the same time I don't want to render anyone's hardware obsolete
>> unnecessarily. But if there's really no one using 40x then we should
>> remove it, it could well be broken already.
>> 
>> So I guess post a series to do the removal and we'll see if anyone
>> speaks up.
>
> We shouldn't remove 40x completely. Just remove the Xilinx 405 stuff.

Congratulations on becoming the 40x maintainer!

cheers

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Benjamin Herrenschmidt]

On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
> > > I have no attachment to 40x, and I'd certainly be happy to have
> > > less
> > > code in the tree, we struggle to keep even the modern platforms
> > > well
> > > maintained.
> > > 
> > > At the same time I don't want to render anyone's hardware
> > > obsolete
> > > unnecessarily. But if there's really no one using 40x then we
> > > should
> > > remove it, it could well be broken already.
> > > 
> > > So I guess post a series to do the removal and we'll see if
> > > anyone
> > > speaks up.
> > 
> > We shouldn't remove 40x completely. Just remove the Xilinx 405
> > stuff.
> 
> Congratulations on becoming the 40x maintainer!

Didn't I give you my last 40x system ? :-) IBM still put 40x cores
inside POWER chips no ?

Cheers,
Ben.

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Geert Uytterhoeven]

Hi Ben,

On Wed, Apr 8, 2020 at 1:34 AM Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > > On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
> > > > I have no attachment to 40x, and I'd certainly be happy to have
> > > > less
> > > > code in the tree, we struggle to keep even the modern platforms
> > > > well
> > > > maintained.
> > > >
> > > > At the same time I don't want to render anyone's hardware
> > > > obsolete
> > > > unnecessarily. But if there's really no one using 40x then we
> > > > should
> > > > remove it, it could well be broken already.
> > > >
> > > > So I guess post a series to do the removal and we'll see if
> > > > anyone
> > > > speaks up.
> > >
> > > We shouldn't remove 40x completely. Just remove the Xilinx 405
> > > stuff.
> >
> > Congratulations on becoming the 40x maintainer!
>
> Didn't I give you my last 40x system ? :-) IBM still put 40x cores
> inside POWER chips no ?

Good to know!

Are they still big-endian, or have they been corrupted by the LE frenzy,
too? ;)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 08/04/2020 à 01:32, Benjamin Herrenschmidt a écrit :
> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>>> On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
>>>> I have no attachment to 40x, and I'd certainly be happy to have
>>>> less
>>>> code in the tree, we struggle to keep even the modern platforms
>>>> well
>>>> maintained.
>>>>
>>>> At the same time I don't want to render anyone's hardware
>>>> obsolete
>>>> unnecessarily. But if there's really no one using 40x then we
>>>> should
>>>> remove it, it could well be broken already.
>>>>
>>>> So I guess post a series to do the removal and we'll see if
>>>> anyone
>>>> speaks up.
>>>
>>> We shouldn't remove 40x completely. Just remove the Xilinx 405
>>> stuff.
>>
>> Congratulations on becoming the 40x maintainer!
> 
> Didn't I give you my last 40x system ? :-) IBM still put 40x cores
> inside POWER chips no ?
> 

According to Wikipedia (https://en.wikipedia.org/wiki/PowerPC_400), 405 
cores are used in modern equipments (how modern ?), however 403 has 
never reached the market.

Can we start removing 403 stuff ? That's not a lot, but still.

Does anybody knows anything about this ERRATUM 77 stuff ? Is that still 
an issue with all 405 cores or has this been fixed long time ago and can 
be removed ?

Christophe

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michael Ellerman]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>> > On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
>> > > I have no attachment to 40x, and I'd certainly be happy to have
>> > > less
>> > > code in the tree, we struggle to keep even the modern platforms
>> > > well
>> > > maintained.
>> > > 
>> > > At the same time I don't want to render anyone's hardware
>> > > obsolete
>> > > unnecessarily. But if there's really no one using 40x then we
>> > > should
>> > > remove it, it could well be broken already.
>> > > 
>> > > So I guess post a series to do the removal and we'll see if
>> > > anyone
>> > > speaks up.
>> > 
>> > We shouldn't remove 40x completely. Just remove the Xilinx 405
>> > stuff.
>> 
>> Congratulations on becoming the 40x maintainer!
>
> Didn't I give you my last 40x system ? :-)

Probably, but my desk is nearly as messy as yours so it's probably
buried under some even more obscure hardware :P

> IBM still put 40x cores inside POWER chips no ?

Oh yeah that's true. I guess most folks don't know that, or that they
run RHEL on them.

cheers

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Arnd Bergmann]

+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
> >> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > IBM still put 40x cores inside POWER chips no ?
>
> Oh yeah that's true. I guess most folks don't know that, or that they
> run RHEL on them.

Is there a reason for not having those dts files in mainline then?
If nothing else, it would document what machines are still being
used with future kernels.

Also, if that's the only 405 based product that is still relevant with
a 5.7+ kernel, it may be useful to know at which point they
move to a 476 core and stop updating kernels on the old ones.

          Arnd

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michael Ellerman]

Arnd Bergmann <arnd@arndb.de> writes:
> +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>> > On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
>> >> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>> > IBM still put 40x cores inside POWER chips no ?
>>
>> Oh yeah that's true. I guess most folks don't know that, or that they
>> run RHEL on them.
>
> Is there a reason for not having those dts files in mainline then?
> If nothing else, it would document what machines are still being
> used with future kernels.

Sorry that part was a joke :D  Those chips don't run Linux.

cheers

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
> Arnd Bergmann <arnd@arndb.de> writes:
>> +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>>>> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
>>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>>>> IBM still put 40x cores inside POWER chips no ?
>>>
>>> Oh yeah that's true. I guess most folks don't know that, or that they
>>> run RHEL on them.
>>
>> Is there a reason for not having those dts files in mainline then?
>> If nothing else, it would document what machines are still being
>> used with future kernels.
> 
> Sorry that part was a joke :D  Those chips don't run Linux.
> 

Nice to know :)

What's the plan then, do we still want to keep 40x in the kernel ?

If yes, is it ok to drop the oldies anyway as done in my series 
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=172630 ?

(Note that this series will conflict with my series on hugepages on 8xx 
due to the PTE_ATOMIC_UPDATES stuff. I can rebase the 40x modernisation 
series on top of the 8xx hugepages series if it is worth it)

Christophe

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michael Ellerman]

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
>> Arnd Bergmann <arnd@arndb.de> writes:
>>> +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>>>>> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
>>>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>>>>> IBM still put 40x cores inside POWER chips no ?
>>>>
>>>> Oh yeah that's true. I guess most folks don't know that, or that they
>>>> run RHEL on them.
>>>
>>> Is there a reason for not having those dts files in mainline then?
>>> If nothing else, it would document what machines are still being
>>> used with future kernels.
>> 
>> Sorry that part was a joke :D  Those chips don't run Linux.
>> 
>
> Nice to know :)
>
> What's the plan then, do we still want to keep 40x in the kernel ?

I guess we keep it for now.

Perhaps we mark it BROKEN for a few releases and see if anyone
complains?

> If yes, is it ok to drop the oldies anyway as done in my series 
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=172630 ?

Yeah let's do it. I would love to get rid of that horrible
PPC405_ERR77() sprinkled all through our atomics.

> (Note that this series will conflict with my series on hugepages on 8xx 
> due to the PTE_ATOMIC_UPDATES stuff. I can rebase the 40x modernisation 
> series on top of the 8xx hugepages series if it is worth it)

Yeah if you can rebase that would be great.

cheers

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michal Simek]

On 21. 05. 20 15:53, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
>>> Arnd Bergmann <arnd@arndb.de> writes:
>>>> +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>>>>>> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
>>>>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>>>>>> IBM still put 40x cores inside POWER chips no ?
>>>>>
>>>>> Oh yeah that's true. I guess most folks don't know that, or that they
>>>>> run RHEL on them.
>>>>
>>>> Is there a reason for not having those dts files in mainline then?
>>>> If nothing else, it would document what machines are still being
>>>> used with future kernels.
>>>
>>> Sorry that part was a joke :D  Those chips don't run Linux.
>>>
>>
>> Nice to know :)
>>
>> What's the plan then, do we still want to keep 40x in the kernel ?
> 
> I guess we keep it for now.
> 
> Perhaps we mark it BROKEN for a few releases and see if anyone
> complains?

I would like to get at least that xilinx patch to the tree to unblock
our changes on interrupt controller.

Thanks,
Michal