Re: [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Fri, Aug 23, 2013 at 12:49:19AM +0200, Tomasz Figa wrote: On Thursday 22 of August 2013 15:43:31 Mike Turquette wrote: Quoting Sascha Hauer (2013-08-22 14:00:35) On Thu, Aug 22, 2013 at 01:09:31PM +0100, Mark Rutland wrote: On Thu, Aug 22, 2013 at 08:19:10AM +0100, Mike Turquette wrote: Quoting Tomasz Figa (2013-08-21 14:34:55) On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote: On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote: Quoting Mark Rutland (2013-08-19 02:35:43) On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote: On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote: On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote: Also I would make this option required. Use a dummy clock for mux inputs that are grounded for a specific SoC. Some clocks are not from CCM and we haven't defined in imx6q-clk.txt, so in most cases we can't provide a phandle for them, eg: spdif_ext. I think it's a bit hard to force it to be 'required'. An 'optional' looks more flexible to me and a default one is ensured even if it's missing. clks 0 is the dummy clock. This can be used for all input clocks not defined by the SoC. Where does this assumption come from? Is it documented anywhere? This is how all i.MX clock bindings currently are. See Documentation/devicetree/bindings/clock/imx*-clock.txt OK, thanks. I guess we need some discussion on dummy clocks vs skipped clocks. I think we want some consistency on this, don't we? If we really need a dummy clock, then we might also want a generic way to specify it. What do we actually mean by a dummy clock? We already have bindings for fixed-clock and co friends describe relatively simple preconfigured clocks. Some platforms have a fake clock which defines noops callbacks and basically doesn't do anything. This is analogous to the dummy regulator implementation. A central one could be registered by the clock core, as is done by the regulator core. When you say some platforms, you presumably mean the platform code in Linux? A dummy clock sounds like a completely Linux-specific abstraction rather than a description of the hardware, and I don't see why we need that in the DT: * If a clock is wired up and running (as presumably the dummy clock is), then surely it's a fixed-clock (it's running, we and we have no control over it, but we presumably know its rate) and can be described as such? * If no clock is wired up, then we should be able to describe that. If a driver believes that a clock is required when it isn't (for some level of functionality), then that driver should be fixed up to support the clock as being optional. Am I missing something? I second that. Moreover, I don't think that device tree should deal with dummy anything. It should be able to describe hardware that is available on given system, not list what hardware is not available. I wasn't clear. The dummy clock IS a completely Linux-specific abstraction. I'm not advocating a dummy clock in DT. I am advocating consolidation of the implementation of a clock that does nothing into the clock core. This code could easily live in drivers/clk/clk.c instead of having everyone open-code it. As far as specifying a dummy clock in DT? I dunno. DT should describe real hardware so there isn't much use for a dummy clock. Sorry, I misunderstood. Good to hear we're on the same page :) I'm guessing one of the reasons for such a clock are drivers do not honor the clk.h api and they freak out when clk_get gives them a NULL pointer? I'm not sure. Sascha, could you shed some light on the matter? The original reason introducing the dummy clocks in the i.MX dtbs was to provide devices a clock which the driver requests but is not software controllable. We often have the case where the same devices are on several SoCs, but not on all of them all clocks have a bit to en/disable them. Anyway, to accomplish this we don't need
Re: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system transaction
Hi, Anton and all
Is there any advice on these two patches ?
[PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system
transaction
[PATCH 3/4 V3] mmc: esdhc: Correct host version of T4240-R1.0-R2.0.
[PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection
This patch is Act-by Scott.
Patch 4/4 is split to four patches and Act-by Anton.
Thanks all.
On 07/19/2013 10:21 AM, Zhang Haijun-B42677 wrote:
Hi, all
Expect your advice and any comments.
Thanks.
Regards
Haijun.
-Original Message-
From: Zhang Haijun-B42677
Sent: Wednesday, July 17, 2013 6:11 PM
To: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Cc: cbouatmai...@gmail.com; c...@laptop.org; Wood Scott-B07421; Fleming
Andy-AFLEMING; Zhang Haijun-B42677; Zhang Haijun-B42677
Subject: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last
system transaction
A-004388: eSDHC DMA might not stop if error occurs on system transaction
eSDHC DMA(SDMA/ADMA) might not stop if an error occurs in the last system
transaction. It may continue initiating additional transactions until
software reset for data/all is issued during error recovery. There is not
any data corruption to the SD data. The IRQSTAT[DMAE] is set when the
erratum occurs.
The only conditions under which issues occur are the following:
1. SDMA - For SD Write , the error occurs in the last system transaction.
No issue for SD read
2. ADMA
a. Block count is enabled: For SD write, the error occurs in the last
system transaction. There is no issue for SD read when block count is
enabled.
b. Block count is disabled: Block count is designated by the ADMA
descriptor table, and the error occurs in the last system transaction
when ADMA is executing last descriptor line of table.
eSDHC may initiate additional system transactions. There is no data
integrity issue for case 1 and 2a described below. For case 2b, system
data might be corrupted.
Workaround: Set eSDHC_SYSCTL[RSTD] when IRQSTAT[DMAE] is set. For cases
2a and 2b above, add an extra descriptor line with zero data next to the
last descriptor line.
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
---
changes for V2:
- Update the svr version list
drivers/mmc/host/sdhci-of-esdhc.c | 112
++
1 file changed, 102 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-
of-esdhc.c
index 15039e2..adfaadd 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -21,9 +21,13 @@
#include linux/mmc/host.h
#include sdhci-pltfm.h
#include sdhci-esdhc.h
+#include asm/mpc85xx.h
#define VENDOR_V_22 0x12
#define VENDOR_V_23 0x13
+
+static u32 svr;
+
static u32 esdhc_readl(struct sdhci_host *host, int reg) {
u32 ret;
@@ -142,6 +146,26 @@ static void esdhc_writeb(struct sdhci_host *host, u8
val, int reg)
sdhci_be32bs_writeb(host, val, reg);
}
+static void esdhc_reset(struct sdhci_host *host, u8 mask) {
+ u32 ier;
+ u32 uninitialized_var(isav);
+
+ if (host-quirks SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
+ isav = esdhc_readl(host, SDHCI_INT_ENABLE);
+
+ esdhc_writeb(host, mask, SDHCI_SOFTWARE_RESET);
+ mdelay(100);
+
+ if (host-quirks SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET) {
+ ier = esdhc_readl(host, SDHCI_INT_ENABLE);
+ ier = ~SDHCI_INT_ALL_MASK;
+ ier |= isav;
+ esdhc_writel(host, ier, SDHCI_INT_ENABLE);
+ esdhc_writel(host, ier, SDHCI_SIGNAL_ENABLE);
+ }
+}
+
/*
* For Abort or Suspend after Stop at Block Gap, ignore the ADMA
* error(IRQSTAT[ADMAE]) if both Transfer Complete(IRQSTAT[TC]) @@ -
156,25 +180,92 @@ static void esdhci_of_adma_workaround(struct sdhci_host
*host, u32 intmask)
dma_addr_t dmastart;
dma_addr_t dmanow;
- tmp = in_be32(host-ioaddr + SDHCI_SLOT_INT_STATUS);
+ tmp = esdhc_readl(host, SDHCI_SLOT_INT_STATUS);
tmp = (tmp SDHCI_VENDOR_VER_MASK) SDHCI_VENDOR_VER_SHIFT;
applicable = (intmask SDHCI_INT_DATA_END)
(intmask SDHCI_INT_BLK_GAP)
(tmp == VENDOR_V_23);
- if (!applicable)
+ if (applicable) {
+
+ esdhc_reset(host, SDHCI_RESET_DATA);
+ host-data-error = 0;
+ dmastart = sg_dma_address(host-data-sg);
+ dmanow = dmastart + host-data-bytes_xfered;
+
+ /* Force update to the next DMA block boundary. */
+ dmanow = (dmanow ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1)) +
+ SDHCI_DEFAULT_BOUNDARY_SIZE;
+ host-data-bytes_xfered = dmanow - dmastart;
+ esdhc_writel(host, dmanow, SDHCI_DMA_ADDRESS);
+
return;
+ }
- host-data-error = 0;
- dmastart = sg_dma_address(host-data-sg);
- dmanow = dmastart + host-data-bytes_xfered;
/*
-*
[PATCH v11] ASoC: fsl: Add S/PDIF machine driver
This patch implements a device-tree-only machine driver for Freescale
i.MX series Soc. It works with spdif_transmitter/spdif_receiver and
fsl_spdif.c drivers.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
Changelog
v10-v11:
* Use boolean properties for spdif-out/in switch instead of codec phandles.
* Accordingly create dummy codec driver in probe() instead of DT nodes.
.../devicetree/bindings/sound/imx-audio-spdif.txt | 34 +
sound/soc/fsl/Kconfig | 11 ++
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/imx-spdif.c | 152
4 files changed, 199 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
create mode 100644 sound/soc/fsl/imx-spdif.c
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
new file mode 100644
index 000..7d13479
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
@@ -0,0 +1,34 @@
+Freescale i.MX audio complex with S/PDIF transceiver
+
+Required properties:
+
+ - compatible : fsl,imx-audio-spdif
+
+ - model : The user-visible name of this sound complex
+
+ - spdif-controller : The phandle of the i.MX S/PDIF controller
+
+
+Optional properties:
+
+ - spdif-out : This is a boolean property. If present, the transmitting
+function of S/PDIF will be enabled, indicating there's a physical
+S/PDIF out connector/jack on the board or it's connecting to some
+other IP block, such as an HDMI encoder/display-controller.
+
+ - spdif-in : This is a boolean property. If present, the receiving
+function of S/PDIF will be enabled, indicating there's a physical
+S/PDIF in connector/jack on the board.
+
+* Note: At least one of these two properties should be set in the DT binding.
+
+
+Example:
+
+sound-spdif {
+ compatible = fsl,imx-audio-spdif;
+ model = imx-spdif;
+ spdif-controller = spdif;
+ spdif-out;
+ spdif-in;
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index cd088cc..a708380 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -193,6 +193,17 @@ config SND_SOC_IMX_SGTL5000
Say Y if you want to add support for SoC audio on an i.MX board with
a sgtl5000 codec.
+config SND_SOC_IMX_SPDIF
+ tristate SoC Audio support for i.MX boards with S/PDIF
+ select SND_SOC_IMX_PCM_DMA
+ select SND_SOC_FSL_SPDIF
+ select SND_SOC_FSL_UTILS
+ select SND_SOC_SPDIF
+ help
+ SoC Audio support for i.MX boards with S/PDIF
+ Say Y if you want to add support for SoC audio on an i.MX board with
+ a S/DPDIF.
+
config SND_SOC_IMX_MC13783
tristate SoC Audio support for I.MX boards with mc13783
depends on MFD_MC13783 ARM
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 4b5970e..e2aaff7 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -45,6 +45,7 @@ snd-soc-mx27vis-aic32x4-objs := mx27vis-aic32x4.o
snd-soc-wm1133-ev1-objs := wm1133-ev1.o
snd-soc-imx-sgtl5000-objs := imx-sgtl5000.o
snd-soc-imx-wm8962-objs := imx-wm8962.o
+snd-soc-imx-spdif-objs :=imx-spdif.o
snd-soc-imx-mc13783-objs := imx-mc13783.o
obj-$(CONFIG_SND_SOC_EUKREA_TLV320) += snd-soc-eukrea-tlv320.o
@@ -53,4 +54,5 @@ obj-$(CONFIG_SND_SOC_MX27VIS_AIC32X4) +=
snd-soc-mx27vis-aic32x4.o
obj-$(CONFIG_SND_MXC_SOC_WM1133_EV1) += snd-soc-wm1133-ev1.o
obj-$(CONFIG_SND_SOC_IMX_SGTL5000) += snd-soc-imx-sgtl5000.o
obj-$(CONFIG_SND_SOC_IMX_WM8962) += snd-soc-imx-wm8962.o
+obj-$(CONFIG_SND_SOC_IMX_SPDIF) += snd-soc-imx-spdif.o
obj-$(CONFIG_SND_SOC_IMX_MC13783) += snd-soc-imx-mc13783.o
diff --git a/sound/soc/fsl/imx-spdif.c b/sound/soc/fsl/imx-spdif.c
new file mode 100644
index 000..af5b553
--- /dev/null
+++ b/sound/soc/fsl/imx-spdif.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/module.h
+#include linux/of_platform.h
+#include sound/soc.h
+
+struct imx_spdif_data {
+ struct snd_soc_dai_link dai[2];
+ struct snd_soc_card card;
+ struct platform_device *txdev;
+ struct platform_device *rxdev;
+};
+
+static int imx_spdif_audio_probe(struct platform_device *pdev)
+{
+ struct device_node *spdif_np, *np = pdev-dev.of_node;
+ struct platform_device *spdif_pdev;
+ struct imx_spdif_data *data;
+ int ret = 0, num_links = 0;
+
+ spdif_np = of_parse_phandle(np, spdif-controller, 0);
+ if (!spdif_np) {
+ dev_err(pdev-dev, failed to find
Re: [PATCH V3] i2c: move of helpers into the core
On Thu, Aug 22, 2013 at 06:00:14PM +0200, Wolfram Sang wrote: I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Acked-by: Rob Herring rob.herr...@calxeda.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Tested-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Wolfram Sang w...@the-dreams.de Applied to for-next! signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH V3 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.
On 08/23/2013 02:54 AM, Scott Wood wrote: On Thu, 2013-08-22 at 11:20 +0530, Deepthi Dharwar wrote: On 08/22/2013 01:38 AM, Scott Wood wrote: On Wed, 2013-08-21 at 10:23 +0530, Deepthi Dharwar wrote: On 08/19/2013 11:47 PM, Scott Wood wrote: What actual functionality is common to all powerpc but not common to other arches? The functionality here is idle states on powerpc like the snooze loop that is common. Also, the basic registration of the driver, hotplug notifier etc for powerpc. The snooze loop uses things like SPRN_PURR, get_lppaca(), and CTRL which aren't common to all PPC (they might be common to all book3s64). I also don't see any hook for the low power mode entry -- is snooze just a busy loop plus the de-emphasis stuff like HMT and CTRL[RUN]? I'm not familiar with the term snooze in this context. I don't think we'd use anything like that on our chips; we'd always at least wait or doze depending on the chip. Duly noted. Lot of stuff are common across book3s64. So my later versions of this patchset does just that. (V5 posted out yesterday). The driver is common only to IBM-POWER platform. Other PPC variants can have their own driver. It's not clear what is powerpc-specific about the notifier -- perhaps it should go in drivers/cpuidle/. Currently all the arcs have their own hotplug notifier. Unifying this across all archs is a challenge that needs to be taken going forward. Thanks for the review. Regards, Deepthi The way forward is to give this file a more appropriate name based on the hardware that it actually targets -- and to refactor it so that the answer to that question is not complicated. Sure, thanks. Our idea was to have POWER archs idle states merged at the first go. Only that is what is enabled in the current version (V4 posted out) ( Code is enabled for PSERIES and POWERNV only) If needed, other POWERPC archs might benefit by extending the same driver, that is why it is named cpuidle-powerpc.c But if having cpuidle backend-driver separately for other powerpc arcs makes sense such that each one have their own state information etc then it makes sense to name the files as cpuidle-power.c, cpuilde-ppc32.c and so on. Thanks. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.
Hi Bartlomiej,
Thanks for the review.
On 08/22/2013 04:26 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Thursday, August 22, 2013 11:00:29 AM Deepthi Dharwar wrote:
This patch involves moving the current pseries_idle backend driver code
from pseries/processor_idle.c to drivers/cpuidle/cpuidle-powerpc.c,
and making the backend code generic enough to be able to extend this
driver code for both powernv and pseries.
It enables the support for pseries platform, such that going forward the
same code
with minimal efforts can be re-used for a common driver on powernv
and can be further extended to support cpuidle idle state mgmt for the rest
of the powerpc platforms in the future. This removes a lot of code duplicacy,
making the code elegant.
This patch mixes the code movement with the actual code changes which is
not a good practice as it makes review more difficult and is generally bad
from the long term maintainance POV.
Please split this patch on code movement and code changes parts.
Sure. I shall do so.
V4 of this patch now also seems to contain changes which I posted on
Tuesday as a part of dev-state_count removal patchset:
http://permalink.gmane.org/gmane.linux.power-management.general/37392
http://permalink.gmane.org/gmane.linux.power-management.general/37393
so some work probably got duplicated. :(
Sorry about that. I have been re-writing this driver over the last few
weeks and this cleanup was on my to-do list since V1 as pointed out by
Daniel. I have missed seeing your cleanup.
Thanks for patch !
Regards,
Deepthi
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/paca.h | 23 +
arch/powerpc/include/asm/processor.h|2
arch/powerpc/platforms/pseries/Kconfig |9 -
arch/powerpc/platforms/pseries/Makefile |1
arch/powerpc/platforms/pseries/processor_idle.c | 360
---
drivers/cpuidle/Kconfig |7
drivers/cpuidle/Makefile|2
drivers/cpuidle/cpuidle-powerpc.c | 304 +++
8 files changed, 337 insertions(+), 371 deletions(-)
delete mode 100644 arch/powerpc/platforms/pseries/processor_idle.c
create mode 100644 drivers/cpuidle/cpuidle-powerpc.c
diff --git a/arch/powerpc/include/asm/paca.h
b/arch/powerpc/include/asm/paca.h
index 77c91e7..7bd83ff 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -175,6 +175,29 @@ extern void setup_paca(struct paca_struct *new_paca);
extern void allocate_pacas(void);
extern void free_unused_pacas(void);
+#ifdef CONFIG_PPC_BOOK3S
+#define get_lppaca_is_shared_proc() get_paca()-lppaca_ptr-shared_proc
+static inline void set_lppaca_idle(u8 idle)
+{
+get_paca()-lppaca_ptr-idle = idle;
+}
+
+static inline void add_lppaca_wait_state(u64 cycles)
+{
+get_paca()-lppaca_ptr-wait_state_cycles += cycles;
+}
+
+static inline void set_lppaca_donate_dedicated_cpu(u8 value)
+{
+get_paca()-lppaca_ptr-donate_dedicated_cpu = value;
+}
+#else
+#define get_lppaca_is_shared_proc() -1
+static inline void set_lppaca_idle(u8 idle) { }
+static inline void add_lppaca_wait_state(u64 cycles) { }
+static inline void set_lppaca_donate_dedicated_cpu(u8 value) { }
+#endif
+
#else /* CONFIG_PPC64 */
static inline void allocate_pacas(void) { };
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index e378ccc..5f57c56 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -430,7 +430,7 @@ enum idle_boot_override {IDLE_NO_OVERRIDE = 0,
IDLE_POWERSAVE_OFF};
extern int powersave_nap; /* set if nap mode can be used in idle loop */
extern void power7_nap(void);
-#ifdef CONFIG_PSERIES_IDLE
+#ifdef CONFIG_CPU_IDLE_POWERPC
extern void update_smt_snooze_delay(int cpu, int residency);
#else
static inline void update_smt_snooze_delay(int cpu, int residency) {}
diff --git a/arch/powerpc/platforms/pseries/Kconfig
b/arch/powerpc/platforms/pseries/Kconfig
index 62b4f80..bb59bb0 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -119,12 +119,3 @@ config DTL
which are accessible through a debugfs file.
Say N if you are unsure.
-
-config PSERIES_IDLE
-bool Cpuidle driver for pSeries platforms
-depends on CPU_IDLE
-depends on PPC_PSERIES
-default y
-help
- Select this option to enable processor idle state management
- through cpuidle subsystem.
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 8ae0103..4b22379 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@
Re: [PATCH V5 3/5] POWER/cpuidle: Generic IBM-POWER backend cpuidle driver.
On 08/23/2013 08:46 AM, Wang Dongsheng-B40534 wrote:
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index 0e2cd5c..e805dcd 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
Maybe drivers/cpuidle/Kconfig.powerpc is better? Like arm.
Yes will do that, going ahead other powerpc archs can use this Kconfig.
+obj-$(CONFIG_CPU_IDLE_IBM_POWER) += cpuidle-ibm-power.o
diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
b/drivers/cpuidle/cpuidle-ibm-power.c
new file mode 100644
index 000..4ee5a94
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -0,0 +1,304 @@
+/*
+ * cpuidle-ibm-power - idle state cpuidle driver.
+ * Adapted from drivers/idle/intel_idle.c and
+ * drivers/acpi/processor_idle.c
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/moduleparam.h
+#include linux/cpuidle.h
+#include linux/cpu.h
+#include linux/notifier.h
+
+#include asm/paca.h
+#include asm/reg.h
+#include asm/machdep.h
+#include asm/firmware.h
+#include asm/runlatch.h
+#include asm/plpar_wrappers.h
+
+struct cpuidle_driver power_idle_driver = {
+.name = IBM-POWER-Idle,
+.owner= THIS_MODULE,
+};
+
+#define MAX_IDLE_STATE_COUNT2
+
+static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
Again, do not use the macro.
Yes, shall use ARRAY_SIZE instead and get away with this macro.
That should work
+static struct cpuidle_state *cpuidle_state_table;
+
+static inline void idle_loop_prolog(unsigned long *in_purr)
+{
+*in_purr = mfspr(SPRN_PURR);
+/*
+ * Indicate to the HV that we are idle. Now would be
+ * a good time to find other work to dispatch.
+ */
+get_lppaca()-idle = 1;
+}
+
+static inline void idle_loop_epilog(unsigned long in_purr)
+{
+get_lppaca()-wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
+get_lppaca()-idle = 0;
+}
+
+static int snooze_loop(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+unsigned long in_purr;
+
+idle_loop_prolog(in_purr);
+local_irq_enable();
snooze_loop has already registered in cpuidle framework to handle snooze
state.
where disable the irq? Why do enable here?
On POWER, snooze state is an infinte busy looping state. The CPUs keep
looping around lowering their priority until they are interrupted. For
this we need to enable irqs in the snooze loop. There is no way a CPU
can come out this state if the interrupts are not enabled.
+/*
+ * States for dedicated partition case.
+ */
+static struct cpuidle_state dedicated_states[MAX_IDLE_STATE_COUNT] = {
+{ /* Snooze */
+.name = snooze,
+.desc = snooze,
+.flags = CPUIDLE_FLAG_TIME_VALID,
+.exit_latency = 0,
+.target_residency = 0,
+.enter = snooze_loop },
+{ /* CEDE */
+.name = CEDE,
+.desc = CEDE,
+.flags = CPUIDLE_FLAG_TIME_VALID,
+.exit_latency = 10,
+.target_residency = 100,
+.enter = dedicated_cede_loop },
+};
+
+/*
+ * States for shared partition case.
+ */
+static struct cpuidle_state shared_states[MAX_IDLE_STATE_COUNT] = {
+{ /* Shared Cede */
+.name = Shared Cede,
+.desc = Shared Cede,
+.flags = CPUIDLE_FLAG_TIME_VALID,
+.exit_latency = 0,
+.target_residency = 0,
+.enter = shared_cede_loop },
+};
+
+static void __exit power_processor_idle_exit(void)
+{
+
+unregister_cpu_notifier(setup_hotplug_notifier);
Remove a blank line.
+cpuidle_unregister(power_idle_driver);
+return;
+}
+
+module_init(power_processor_idle_init);
+module_exit(power_processor_idle_exit);
+
Did you have tested the module? If not tested, please don't use the module.
We do want to make it a module. But for now that cannot be done due to
some other dependencies. This feature needs to be built in.
Thanks for the review.
+MODULE_AUTHOR(Deepthi Dharwar deep...@linux.vnet.ibm.com);
+MODULE_DESCRIPTION(Cpuidle driver for IBM POWER platforms);
+MODULE_LICENSE(GPL);
Regards,
Deepthi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V5 3/5] POWER/cpuidle: Generic IBM-POWER backend cpuidle driver.
On 08/23/2013 08:46 AM, Wang Dongsheng-B40534 wrote:
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index 0e2cd5c..e805dcd 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
Maybe drivers/cpuidle/Kconfig.powerpc is better? Like arm.
+obj-$(CONFIG_CPU_IDLE_IBM_POWER) += cpuidle-ibm-power.o
diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
b/drivers/cpuidle/cpuidle-ibm-power.c
new file mode 100644
index 000..4ee5a94
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -0,0 +1,304 @@
+/*
+ * cpuidle-ibm-power - idle state cpuidle driver.
+ * Adapted from drivers/idle/intel_idle.c and
+ * drivers/acpi/processor_idle.c
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/moduleparam.h
+#include linux/cpuidle.h
+#include linux/cpu.h
+#include linux/notifier.h
+
+#include asm/paca.h
+#include asm/reg.h
+#include asm/machdep.h
+#include asm/firmware.h
+#include asm/runlatch.h
+#include asm/plpar_wrappers.h
+
+struct cpuidle_driver power_idle_driver = {
+.name = IBM-POWER-Idle,
+.owner= THIS_MODULE,
+};
+
+#define MAX_IDLE_STATE_COUNT2
+
+static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
Again, do not use the macro.
Wanting to re-use CPUIDLE_STATE_MAX macro, defined in linux/cpuidle.h
similar to what x86 uses. This is def scalable for various platforms ,
as demonstrated in drivers/idle/intel_idle.c
+static struct cpuidle_state *cpuidle_state_table;
+
+static inline void idle_loop_prolog(unsigned long *in_purr)
+{
+*in_purr = mfspr(SPRN_PURR);
+/*
+ * Indicate to the HV that we are idle. Now would be
+ * a good time to find other work to dispatch.
+ */
+get_lppaca()-idle = 1;
+}
+
+static inline void idle_loop_epilog(unsigned long in_purr)
+{
+get_lppaca()-wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
+get_lppaca()-idle = 0;
+}
+
+static int snooze_loop(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+unsigned long in_purr;
+
+idle_loop_prolog(in_purr);
+local_irq_enable();
snooze_loop has already registered in cpuidle framework to handle snooze
state.
where disable the irq? Why do enable here?
+/*
+ * States for dedicated partition case.
+ */
+static struct cpuidle_state dedicated_states[MAX_IDLE_STATE_COUNT] = {
+{ /* Snooze */
+.name = snooze,
+.desc = snooze,
+.flags = CPUIDLE_FLAG_TIME_VALID,
+.exit_latency = 0,
+.target_residency = 0,
+.enter = snooze_loop },
+{ /* CEDE */
+.name = CEDE,
+.desc = CEDE,
+.flags = CPUIDLE_FLAG_TIME_VALID,
+.exit_latency = 10,
+.target_residency = 100,
+.enter = dedicated_cede_loop },
+};
+
+/*
+ * States for shared partition case.
+ */
+static struct cpuidle_state shared_states[MAX_IDLE_STATE_COUNT] = {
+{ /* Shared Cede */
+.name = Shared Cede,
+.desc = Shared Cede,
+.flags = CPUIDLE_FLAG_TIME_VALID,
+.exit_latency = 0,
+.target_residency = 0,
+.enter = shared_cede_loop },
+};
+
+static void __exit power_processor_idle_exit(void)
+{
+
+unregister_cpu_notifier(setup_hotplug_notifier);
Remove a blank line.
+cpuidle_unregister(power_idle_driver);
+return;
+}
+
+module_init(power_processor_idle_init);
+module_exit(power_processor_idle_exit);
+
Did you have tested the module? If not tested, please don't use the module.
+MODULE_AUTHOR(Deepthi Dharwar deep...@linux.vnet.ibm.com);
+MODULE_DESCRIPTION(Cpuidle driver for IBM POWER platforms);
+MODULE_LICENSE(GPL);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Thu, Aug 22, 2013 at 10:00:35PM +0100, Sascha Hauer wrote: On Thu, Aug 22, 2013 at 01:09:31PM +0100, Mark Rutland wrote: On Thu, Aug 22, 2013 at 08:19:10AM +0100, Mike Turquette wrote: Quoting Tomasz Figa (2013-08-21 14:34:55) On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote: On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote: Quoting Mark Rutland (2013-08-19 02:35:43) On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote: On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote: On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote: Also I would make this option required. Use a dummy clock for mux inputs that are grounded for a specific SoC. Some clocks are not from CCM and we haven't defined in imx6q-clk.txt, so in most cases we can't provide a phandle for them, eg: spdif_ext. I think it's a bit hard to force it to be 'required'. An 'optional' looks more flexible to me and a default one is ensured even if it's missing. clks 0 is the dummy clock. This can be used for all input clocks not defined by the SoC. Where does this assumption come from? Is it documented anywhere? This is how all i.MX clock bindings currently are. See Documentation/devicetree/bindings/clock/imx*-clock.txt OK, thanks. I guess we need some discussion on dummy clocks vs skipped clocks. I think we want some consistency on this, don't we? If we really need a dummy clock, then we might also want a generic way to specify it. What do we actually mean by a dummy clock? We already have bindings for fixed-clock and co friends describe relatively simple preconfigured clocks. Some platforms have a fake clock which defines noops callbacks and basically doesn't do anything. This is analogous to the dummy regulator implementation. A central one could be registered by the clock core, as is done by the regulator core. When you say some platforms, you presumably mean the platform code in Linux? A dummy clock sounds like a completely Linux-specific abstraction rather than a description of the hardware, and I don't see why we need that in the DT: * If a clock is wired up and running (as presumably the dummy clock is), then surely it's a fixed-clock (it's running, we and we have no control over it, but we presumably know its rate) and can be described as such? * If no clock is wired up, then we should be able to describe that. If a driver believes that a clock is required when it isn't (for some level of functionality), then that driver should be fixed up to support the clock as being optional. Am I missing something? I second that. Moreover, I don't think that device tree should deal with dummy anything. It should be able to describe hardware that is available on given system, not list what hardware is not available. I wasn't clear. The dummy clock IS a completely Linux-specific abstraction. I'm not advocating a dummy clock in DT. I am advocating consolidation of the implementation of a clock that does nothing into the clock core. This code could easily live in drivers/clk/clk.c instead of having everyone open-code it. As far as specifying a dummy clock in DT? I dunno. DT should describe real hardware so there isn't much use for a dummy clock. Sorry, I misunderstood. Good to hear we're on the same page :) I'm guessing one of the reasons for such a clock are drivers do not honor the clk.h api and they freak out when clk_get gives them a NULL pointer? I'm not sure. Sascha, could you shed some light on the matter? The original reason introducing the dummy clocks in the i.MX dtbs was to provide devices a clock which the driver requests but is not software controllable. We often have the case where the same devices are on several SoCs, but not on all of them all clocks have a bit to en/disable them. So those clocks are always on at some fixed rate? Anyway, to accomplish this we don't need dummy clocks. We can just describe the real clocks. Ok. BTW with the S/PDIF core on which not all mux inputs are connected to actual clocks we could also describe the unconnected inputs as ground clocks with rate 0. This way we describe something which is really there instead of dummy clocks ;) Background to why it might be a good idea to connect a ground clock to
Re: [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Fri, Aug 23, 2013 at 07:34:21AM +0100, Sascha Hauer wrote: On Fri, Aug 23, 2013 at 12:49:19AM +0200, Tomasz Figa wrote: On Thursday 22 of August 2013 15:43:31 Mike Turquette wrote: Quoting Sascha Hauer (2013-08-22 14:00:35) On Thu, Aug 22, 2013 at 01:09:31PM +0100, Mark Rutland wrote: On Thu, Aug 22, 2013 at 08:19:10AM +0100, Mike Turquette wrote: Quoting Tomasz Figa (2013-08-21 14:34:55) On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote: On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote: Quoting Mark Rutland (2013-08-19 02:35:43) On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote: On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote: On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote: Also I would make this option required. Use a dummy clock for mux inputs that are grounded for a specific SoC. Some clocks are not from CCM and we haven't defined in imx6q-clk.txt, so in most cases we can't provide a phandle for them, eg: spdif_ext. I think it's a bit hard to force it to be 'required'. An 'optional' looks more flexible to me and a default one is ensured even if it's missing. clks 0 is the dummy clock. This can be used for all input clocks not defined by the SoC. Where does this assumption come from? Is it documented anywhere? This is how all i.MX clock bindings currently are. See Documentation/devicetree/bindings/clock/imx*-clock.txt OK, thanks. I guess we need some discussion on dummy clocks vs skipped clocks. I think we want some consistency on this, don't we? If we really need a dummy clock, then we might also want a generic way to specify it. What do we actually mean by a dummy clock? We already have bindings for fixed-clock and co friends describe relatively simple preconfigured clocks. Some platforms have a fake clock which defines noops callbacks and basically doesn't do anything. This is analogous to the dummy regulator implementation. A central one could be registered by the clock core, as is done by the regulator core. When you say some platforms, you presumably mean the platform code in Linux? A dummy clock sounds like a completely Linux-specific abstraction rather than a description of the hardware, and I don't see why we need that in the DT: * If a clock is wired up and running (as presumably the dummy clock is), then surely it's a fixed-clock (it's running, we and we have no control over it, but we presumably know its rate) and can be described as such? * If no clock is wired up, then we should be able to describe that. If a driver believes that a clock is required when it isn't (for some level of functionality), then that driver should be fixed up to support the clock as being optional. Am I missing something? I second that. Moreover, I don't think that device tree should deal with dummy anything. It should be able to describe hardware that is available on given system, not list what hardware is not available. I wasn't clear. The dummy clock IS a completely Linux-specific abstraction. I'm not advocating a dummy clock in DT. I am advocating consolidation of the implementation of a clock that does nothing into the clock core. This code could easily live in drivers/clk/clk.c instead of having everyone open-code it. As far as specifying a dummy clock in DT? I dunno. DT should describe real hardware so there isn't much use for a dummy clock. Sorry, I misunderstood. Good to hear we're on the same page :) I'm guessing one of the reasons for such a clock are drivers do not honor the clk.h api and they freak out when clk_get gives them a NULL pointer? I'm not sure. Sascha, could you shed some light on the matter? The original reason introducing the dummy clocks in the i.MX dtbs was to provide devices a clock which the driver requests but is not software
Re: [RFC 11/14] powerpc: Eliminate NO_IRQ usage
On Fri, Jul 26, 2013 at 5:56 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Thu, Jul 25, 2013 at 3:58 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Wed, Jan 11, 2012 at 9:22 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
NO_IRQ is evil. Stop using it in arch/powerpc and powerpc device drivers
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 3e06696..55c6ff9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -666,7 +666,7 @@ static int __devinit fsl_ssi_probe(struct
platform_device *pdev)
ssi_private-ssi_phys = res.start;
ssi_private-irq = irq_of_parse_and_map(np, 0);
- if (ssi_private-irq == NO_IRQ) {
+ if (!ssi_private-irq) {
dev_err(pdev-dev, no irq for node %s\n, np-full_name);
ret = -ENXIO;
goto error_iomap;
What's the plan with this patch?
This is now failing on xtensa, as it's one of the architectures that doesn't
define NO_IRQ. Only arm, c6x, mn10300, openrisc, parisc, powerpc, and sparc
define it.
Wow. I'd pretty much dropped that patch because I didn't have time to
chase it down. It should be pursued though.
In that particular case it is safe I think to apply the change. PPC
defines NO_IRQ to be 0 anyway.
Note that we still have arches that define it as nonzero:
arch/arm/include/asm/irq.h:#define NO_IRQ ((unsigned int)(-1))
arch/mn10300/include/asm/irq.h:#define NO_IRQ INT_MAX
arch/openrisc/include/asm/irq.h:#define NO_IRQ (-1)
arch/parisc/include/asm/irq.h:#define NO_IRQ (-1)
arch/sparc/include/asm/irq_32.h:#define NO_IRQ 0x
arch/sparc/include/asm/irq_64.h:#define NO_IRQ 0x
Only c6x and powerpc use zero, and thus are ready to drop NO_IRQ.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 11/14] powerpc: Eliminate NO_IRQ usage
On Fri, Aug 23, 2013 at 3:18 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Fri, Jul 26, 2013 at 5:56 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Thu, Jul 25, 2013 at 3:58 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Wed, Jan 11, 2012 at 9:22 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
NO_IRQ is evil. Stop using it in arch/powerpc and powerpc device drivers
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 3e06696..55c6ff9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -666,7 +666,7 @@ static int __devinit fsl_ssi_probe(struct
platform_device *pdev)
ssi_private-ssi_phys = res.start;
ssi_private-irq = irq_of_parse_and_map(np, 0);
- if (ssi_private-irq == NO_IRQ) {
+ if (!ssi_private-irq) {
dev_err(pdev-dev, no irq for node %s\n, np-full_name);
ret = -ENXIO;
goto error_iomap;
What's the plan with this patch?
This is now failing on xtensa, as it's one of the architectures that doesn't
define NO_IRQ. Only arm, c6x, mn10300, openrisc, parisc, powerpc, and sparc
define it.
Wow. I'd pretty much dropped that patch because I didn't have time to
chase it down. It should be pursued though.
In that particular case it is safe I think to apply the change. PPC
defines NO_IRQ to be 0 anyway.
Note that we still have arches that define it as nonzero:
arch/arm/include/asm/irq.h:#define NO_IRQ ((unsigned int)(-1))
arch/mn10300/include/asm/irq.h:#define NO_IRQ INT_MAX
arch/openrisc/include/asm/irq.h:#define NO_IRQ (-1)
arch/parisc/include/asm/irq.h:#define NO_IRQ (-1)
arch/sparc/include/asm/irq_32.h:#define NO_IRQ 0x
arch/sparc/include/asm/irq_64.h:#define NO_IRQ 0x
Only c6x and powerpc use zero, and thus are ready to drop NO_IRQ.
s390 just gained NO_IRQ support in -next, in commit
e15a9dcfdec29786d1830c5b7beaf02a288a89e1 (s390: convert interrupt
handling to use generic hardirq):
/* This number is used when no interrupt has been assigned */
#define NO_IRQ 0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Fri, Aug 23, 2013 at 01:58:15PM +0100, Mark Rutland wrote: On Fri, Aug 23, 2013 at 07:34:21AM +0100, Sascha Hauer wrote: On Fri, Aug 23, 2013 at 12:49:19AM +0200, Tomasz Figa wrote: On Thursday 22 of August 2013 15:43:31 Mike Turquette wrote: Quoting Sascha Hauer (2013-08-22 14:00:35) On Thu, Aug 22, 2013 at 01:09:31PM +0100, Mark Rutland wrote: On Thu, Aug 22, 2013 at 08:19:10AM +0100, Mike Turquette wrote: Quoting Tomasz Figa (2013-08-21 14:34:55) On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote: On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote: Quoting Mark Rutland (2013-08-19 02:35:43) On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote: On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote: On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote: Also I would make this option required. Use a dummy clock for mux inputs that are grounded for a specific SoC. Some clocks are not from CCM and we haven't defined in imx6q-clk.txt, so in most cases we can't provide a phandle for them, eg: spdif_ext. I think it's a bit hard to force it to be 'required'. An 'optional' looks more flexible to me and a default one is ensured even if it's missing. clks 0 is the dummy clock. This can be used for all input clocks not defined by the SoC. Where does this assumption come from? Is it documented anywhere? This is how all i.MX clock bindings currently are. See Documentation/devicetree/bindings/clock/imx*-clock.txt OK, thanks. I guess we need some discussion on dummy clocks vs skipped clocks. I think we want some consistency on this, don't we? If we really need a dummy clock, then we might also want a generic way to specify it. What do we actually mean by a dummy clock? We already have bindings for fixed-clock and co friends describe relatively simple preconfigured clocks. Some platforms have a fake clock which defines noops callbacks and basically doesn't do anything. This is analogous to the dummy regulator implementation. A central one could be registered by the clock core, as is done by the regulator core. When you say some platforms, you presumably mean the platform code in Linux? A dummy clock sounds like a completely Linux-specific abstraction rather than a description of the hardware, and I don't see why we need that in the DT: * If a clock is wired up and running (as presumably the dummy clock is), then surely it's a fixed-clock (it's running, we and we have no control over it, but we presumably know its rate) and can be described as such? * If no clock is wired up, then we should be able to describe that. If a driver believes that a clock is required when it isn't (for some level of functionality), then that driver should be fixed up to support the clock as being optional. Am I missing something? I second that. Moreover, I don't think that device tree should deal with dummy anything. It should be able to describe hardware that is available on given system, not list what hardware is not available. I wasn't clear. The dummy clock IS a completely Linux-specific abstraction. I'm not advocating a dummy clock in DT. I am advocating consolidation of the implementation of a clock that does nothing into the clock core. This code could easily live in drivers/clk/clk.c instead of having everyone open-code it. As far as specifying a dummy clock in DT? I dunno. DT should describe real hardware so there isn't much use for a dummy clock. Sorry, I misunderstood. Good to hear we're on the same page :) I'm guessing one of the reasons for such a clock are drivers do not honor the clk.h api and they freak out when clk_get gives them a NULL pointer? I'm not sure. Sascha, could you shed some
Re: [alsa-devel] [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
[trimming a bit of useless context]
Background to why it might be a good idea to connect a ground clock
to the unconnected input pins is that a driver has a chance to
successfully grab all clocks. Otherwise how does the driver
distinguish
between an unconnected and an erroneous clock?
Sorry, I don't follow this last question. Do you mean how to
distinguish
based on the value returned from clk_get?
Hmm, in theory, a driver could want to distinguish an error case (e.g.
clock specified, but there is a problem with it) from no clock (e.g.
clock
not specified in DT, because it is not available on particular board).
Yes, that's what I meant. To illustrate the problem for this driver:
for (i = 0; i STC_TXCLK_SRC_MAX; i++) {
sprintf(tmp, rxtx%d, i);
clk = devm_clk_get(pdev-dev, tmp);
if (IS_ERR(clk)) {
[...]
/*
* ERR_PTR(-ENOENT) returned when clock not
* present in the dt (i.e. not wired up). We can
* live without this clock, so assign a dummy
* (NULL) to simplify the rest of the code. If
* the clock is present but something else went
* wrong, we'll get a different ERR_PTR value
* and actually fail.
*/
if (clk == ERR_PTR(-ENOENT)
clk = NULL;
}
}
This could be solved by always specifying all input clocks in the
devicetree.
As far as I can see, the above is sufficient, and leaves the knowledge
of skippable clocks in the driver, where I believe it should be.
You miss my point. Once a clock is specified in the devicetree it is no
longer optional. The driver currently can't find out whether a clock
hasn't been specified (and it's ok that it's not there) or a clock has
been specified, but some error prevents actually grabbing the clock (in
which case the driver should bail out)
Unless I've misunderstood, that's exactly what I was trying to implement
above. As I understand it, what we want is:
* If a clock is not specified in the DT, but it's a clock that we know
we can live without if not wired up, then continue along with a dummy
clock (NULL). This could be changed to a different dummy, what exactly
is needed is driver-specific.
* If a clock is not specified in the DT, but it's *not* an optional
clock, then we must fail. Whether or not a clock is optional is
knowledge only the driver can have.
* If a clock is specified in the DT, but we can't get it for some
reason, fail.
* If a clock is specified in the DT, and we get it, use it.
I see we might also get PTR_ERR(-ENOENT) indirectly from
__of_parse_phandle_with_args, if the clocks property isn't present
(but clock-names is), or we're given the empty phandle. The empty
phandle case is arguable, but it would be possible to add a check for
the clocks property in of_clk_get_by_name early on where we could return
-EINVAL to prevent that being a problem.
Otherwise, it's trivial to add a function to explicitly test for this
case (see below). I don't see that we need to leak what is a Linux issue
into the dt.
Thanks,
Mark.
8
From f0d46f36426ded4ba3609d7966452f9925e2 Mon Sep 17 00:00:00 2001
From: Mark Rutland mark.rutl...@arm.com
Date: Fri, 23 Aug 2013 15:46:33 +0100
Subject: [PATCH] clk: add of_clk_is_specified
There's currently no way to perfectly distinguish between an
of_clk_get_by_name that failed because a clock was not provided in
clock-names, or for some other reason (e.g. the clocks property itself
was missing). This is problematic for drivers for some pieces of
hardware that have optional clocks -- those which must be used if wired,
but may not be wired in all cases.
This patch adds a new function of_clk_is_specified, which may be used to
distinguish these cases.
Signed-off-by: Mark Rutland mark.rutl...@arm.com
---
drivers/clk/clkdev.c | 11 +++
include/linux/clk.h | 5 +
2 files changed, 16 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..7fdeca9 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -91,6 +91,17 @@ struct clk *of_clk_get_by_name(struct device_node *np, const
char *name)
return clk;
}
EXPORT_SYMBOL(of_clk_get_by_name);
+
+/**
+ *
+ * of_clk_is_specified - Test if a clock was provided by name in a device node
+ * @np: pointer to the clock consumer node
+ * @name: name of the consumer's clock input. Not NULL.
+ */
+bool of_clk_is_specified(struct device_node *np, const char *name)
+{
+ return of_property_match_string(np, clock-names, name) = 0;
+}
#endif
/*
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 9a6d045..bf44d94 100644
---
Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
On Thu, 2013-08-22 at 21:52 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Thursday, August 22, 2013 11:19 PM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state On Wed, 2013-08-21 at 22:13 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, August 20, 2013 8:39 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state It just seems wrong to have an ad-hoc mechanism for running core-specific code when we have cputable... If we really need this, maybe we should add a cpu_setup_late function pointer. With your patch, when does the power management register get set when hot plugging a cpu? Um.. I don't deal with this situation. I will fix it. __setup/restore_cpu_e6500 looks good. But only bootcpu call __setup_cpu_e6500, not on each cpu. I think this is a bug. Other CPUs call __restore_cpu_e6500. No, there is bootcore of secondary thread, and other cores of first thread call __restore_cpu_e6500. This is the upstream list -- there is no e6500 thread support yet. :-) But in the SDK I do see generic_secondary_common_init being called from generic_secondary_thread_init, which means __restore_cpu_e6500 will be called. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system transaction
On Fri, 2013-08-23 at 14:39 +0800, Zhang Haijun wrote: Hi, Anton and all Is there any advice on these two patches ? [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system transaction [PATCH 3/4 V3] mmc: esdhc: Correct host version of T4240-R1.0-R2.0. [PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection This patch is Act-by Scott. Patch 4/4 is split to four patches and Act-by Anton. Thanks all. [snip] + if (!(((SVR_SOC_VER(svr) == SVR_T4240) (SVR_REV(svr) == 0x10)) || + ((SVR_SOC_VER(svr) == SVR_B4860) (SVR_REV(svr) == 0x10)) || + ((SVR_SOC_VER(svr) == SVR_P1010) (SVR_REV(svr) == 0x10)) || + ((SVR_SOC_VER(svr) == SVR_P3041) (SVR_REV(svr) = 0x20)) || + ((SVR_SOC_VER(svr) == SVR_P2041) (SVR_REV(svr) = 0x20)) || + ((SVR_SOC_VER(svr) == SVR_P5040) SVR_REV(svr) == 0x20))) + return; You need to include variants here. If P5040 is affected, then P5021 is affected. If P2041 is affected, then P2040 is affected, etc. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: P3041 What a new ethernet phy change to the device tree
On Fri, 2013-08-23 at 17:49 +0200, Mercier Ivan wrote: Hi everybody, I have 2 boards based on freescale p3041. Ethernet works on uboot on the 2 of them but only the eval card p3041ds works with linux. So i start modifying the device tree on the other card (wp6.dts) and now I can see the ethernet device in Linux but I can't configure it. root@p3041ds:~# ifconfig fm1-gb3 10.0.0.1 fsl_dpa ethernet.14 fm1-gb3: Could not connect to PHY /localbus@ffe124000/board-control@3,0/mdio-mux-emi1/rgmii-mdio@28/ethernet-phy@1f fsl_dpa ethernet.14 fm1-gb3: init_phy() = -19 ifconfig: SIOCSIFFLAGS: No such device It seems to be a phy address misconfiguration on mdio bus but I don't exactly know what to change on my device tree. Can anyone look at my two device trees? It sounds like you're using the Freescale SDK rather than the upstream kernel (there's no datapath support upstream yet). For SDK support please contact supp...@freescale.com or post a question on https://community.freescale.com/ -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11] ASoC: fsl: Add S/PDIF machine driver
On 08/23/2013 02:04 AM, Nicolin Chen wrote:
This patch implements a device-tree-only machine driver for Freescale
i.MX series Soc. It works with spdif_transmitter/spdif_receiver and
fsl_spdif.c drivers.
The binding looks reasonable to me now. Thanks.
diff --git a/sound/soc/fsl/imx-spdif.c b/sound/soc/fsl/imx-spdif.c
+ if (of_property_read_bool(np, spdif-out)) {
I'd be tempted to safe those property values into a variable so that ...
+ data-txdev = platform_device_register_simple(spdif-dit, -1, NULL, 0);
...
+ data-rxdev = platform_device_register_simple(spdif-dir, -1, NULL, 0);
... those two statements could be conditional upon whether TX/RX were
required too.
However, this isn't a big deal, and could be cleaned up later.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v11] ASoC: fsl: Add S/PDIF machine driver
On Fri, Aug 23, 2013 at 01:08:28PM -0600, Stephen Warren wrote: On 08/23/2013 02:04 AM, Nicolin Chen wrote: This patch implements a device-tree-only machine driver for Freescale i.MX series Soc. It works with spdif_transmitter/spdif_receiver and fsl_spdif.c drivers. The binding looks reasonable to me now. Thanks. Is that a Reviewed-by? signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
Bcc:
Subject: Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
Reply-To:
In-Reply-To: g7gj9smnc@dworkin.scrye.com
On Wed, May 08, 2013 at 06:04:39AM -0600, Anthony Foiani wrote:
Anthony Foiani t...@scrye.com writes:
Maybe I need to call ata_set_sata_spd as well. Can I do that before
discovery, or should it be a part of the port_start callback? And
if the latter, shouldn't it be handled within the ata core, instead
of expecting each host driver to do that call?
My final version calls sata_set_spd from within the hard reset
callback for the fsl sata driver.
If there's a better place to put it, please let me know.
With this patch (and an appropriate entry in the device tree), the
machine comes up and reports:
# cd /sys/devices/e000.immr/e0019000.sata
# find * -name '*_spd*' -print | xargs grep .
ata2/link2/ata_link/link2/sata_spd:1.5 Gbps
ata2/link2/ata_link/link2/hw_sata_spd_limit:1.5 Gbps
ata2/link2/ata_link/link2/sata_spd_limit:1.5 Gbps
Which is what I needed to see.
Thanks for the hints!
Best regards,
Anthony Foiani
---
From 357c96b4f31b457eca0b96147c749c21d0f4f086 Mon Sep 17 00:00:00 2001
From: Anthony Foiani anthony.foi...@gmail.com
Date: Wed, 8 May 2013 05:24:20 -0600
Subject: [PATCH] sata: fsl: allow device tree to limit sata speed.
There used to be an orphan config symbol (CONFIG_MPC8315_DS) that
would artificially limit SATA speed to generation 1 (1.5Gbps).
Since that config symbol got lost whenever any sort of configuration
was done, we instead extract the limitation from the device tree,
using a new name sata-spd-limit.
Signed-off-by: Anthony Foiani anthony.foi...@gmail.com
---
.../devicetree/bindings/powerpc/fsl/board.txt | 23 ++
drivers/ata/sata_fsl.c | 28
+++---
2 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 380914e..9c9fed4 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -67,3 +67,26 @@ Example:
gpio-controller;
};
};
+
+* Maximum SATA Generation workaround
+
+Some boards advertise SATA speeds that they cannot actually achieve.
+Previously, this was dealt with via the orphaned config symbol
+CONFIG_MPC8315_DS. We now have a device tree property
+sata-spd-limit to control this. It should live within the sata
+block.
+
+Example:
+
+ sata@18000 {
+ compatible = fsl,mpc8315-sata, fsl,pq-sata;
+ reg = 0x18000 0x1000;
+ cell-index = 1;
+ interrupts = 44 0x8;
+ interrupt-parent = ipic;
+ sata-spd-limit = 1;
+ };
+By default, there is no limitation; if a value is given, it indicates
+the maximum generation that should be negotiated. Gen 1 is 1.5Gbps,
+Gen 2 is 3.0Gbps.
This should go in Documentation/devicetree/bindings/ata/fsl-sata.txt.
As for the property name, I'd prefer fsl,sata-speed-limit or
fsl,sata-max-generation. Shaohui, do the driver bits look OK?
This patch should go via the linux-scsi list (note that Tejun Heo is now
the SATA maintainer).
-Scott
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index d6577b9..9e3f3ec 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -726,20 +726,6 @@ static int sata_fsl_port_start(struct ata_port *ap)
VPRINTK(HControl = 0x%x\n, ioread32(hcr_base + HCONTROL));
VPRINTK(CHBA = 0x%x\n, ioread32(hcr_base + CHBA));
-#ifdef CONFIG_MPC8315_DS
- /*
- * Workaround for 8315DS board 3gbps link-up issue,
- * currently limit SATA port to GEN1 speed
- */
- sata_fsl_scr_read(ap-link, SCR_CONTROL, temp);
- temp = ~(0xF 4);
- temp |= (0x1 4);
- sata_fsl_scr_write(ap-link, SCR_CONTROL, temp);
-
- sata_fsl_scr_read(ap-link, SCR_CONTROL, temp);
- dev_warn(dev, scr_control, speed limited to %x\n, temp);
-#endif
-
return 0;
}
@@ -836,6 +822,11 @@ try_offline_again:
*/
ata_msleep(ap, 1);
+ /* if the device tree forces a speed limit, set it here. */
+ ata_link_info(link, setting speed (in hard reset)\n);
+ DPRINTK(setting spd_limit\n);
+ sata_set_spd(link);
+
/*
* Now, bring the host controller online again, this can take time
* as PHY reset and communication establishment, 1st D2H FIS and
@@ -1444,6 +1435,15 @@ static int sata_fsl_probe(struct platform_device
*ofdev)
goto error_exit_with_cleanup;
}
+ /* record speed limit if requested by device tree */
+ if (!of_property_read_u32(ofdev-dev.of_node, sata-spd-limit,
+ temp))
Re: [alsa-devel] [PATCH v11] ASoC: fsl: Add S/PDIF machine driver
On 08/23/2013 01:13 PM, Mark Brown wrote: On Fri, Aug 23, 2013 at 01:08:28PM -0600, Stephen Warren wrote: On 08/23/2013 02:04 AM, Nicolin Chen wrote: This patch implements a device-tree-only machine driver for Freescale i.MX series Soc. It works with spdif_transmitter/spdif_receiver and fsl_spdif.c drivers. The binding looks reasonable to me now. Thanks. Is that a Reviewed-by? Sure, it can be, Acked-by: Stephen Warren swar...@nvidia.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/10] Series of fixes for NX driver
This series of patches contains fixes in several algorithms implemented by the NX driver. The patches can be separated in three different categories: - Changes to split the data in several hyper calls to respect the limits of data that the co-processador can handle. This affects all AES modes. - Fixes in how the driver handle zero length messages. This affects XCBC and GCM. - Fixes for SHA-2 when chunks bigger than the block size are provided. Fionnuala Gunter (2): crypto: nx - fix limits to sg lists for AES-XCBC crypto: nx - fix limits to sg lists for AES-CCM Marcelo Cerri (8): crypto: nx - add offset to nx_build_sg_lists() crypto: nx - fix limits to sg lists for AES-ECB crypto: nx - fix limits to sg lists for AES-CBC crypto: nx - fix limits to sg lists for AES-CTR crypto: nx - fix limits to sg lists for AES-GCM crypto: nx - fix XCBC for zero length messages crypto: nx - fix GCM for zero length messages crypto: nx - fix SHA-2 for chunks bigger than block size drivers/crypto/nx/nx-aes-cbc.c | 50 --- drivers/crypto/nx/nx-aes-ccm.c | 297 +--- drivers/crypto/nx/nx-aes-ctr.c | 50 --- drivers/crypto/nx/nx-aes-ecb.c | 48 --- drivers/crypto/nx/nx-aes-gcm.c | 292 ++- drivers/crypto/nx/nx-aes-xcbc.c | 191 +++--- drivers/crypto/nx/nx-sha256.c | 2 +- drivers/crypto/nx/nx-sha512.c | 2 +- drivers/crypto/nx/nx.c | 9 +- drivers/crypto/nx/nx.h | 2 +- 10 files changed, 683 insertions(+), 260 deletions(-) -- 1.7.12 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 01/10] crypto: nx - add offset to nx_build_sg_lists()
This patch includes one more parameter to nx_build_sg_lists() to skip
the given number of bytes from beginning of each sg list.
This is needed in order to implement the fixes for the AES modes to make
them able to process larger chunks of data.
Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-cbc.c | 2 +-
drivers/crypto/nx/nx-aes-ccm.c | 4 ++--
drivers/crypto/nx/nx-aes-ctr.c | 2 +-
drivers/crypto/nx/nx-aes-ecb.c | 2 +-
drivers/crypto/nx/nx-aes-gcm.c | 2 +-
drivers/crypto/nx/nx.c | 9 +++--
drivers/crypto/nx/nx.h | 2 +-
7 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c b/drivers/crypto/nx/nx-aes-cbc.c
index 9310982..f334a60 100644
--- a/drivers/crypto/nx/nx-aes-cbc.c
+++ b/drivers/crypto/nx/nx-aes-cbc.c
@@ -85,7 +85,7 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
else
NX_CPB_FDM(csbcpb) = ~NX_FDM_ENDE_ENCRYPT;
- rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes,
+ rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes, 0,
csbcpb-cpb.aes_cbc.iv);
if (rc)
goto out;
diff --git a/drivers/crypto/nx/nx-aes-ccm.c b/drivers/crypto/nx/nx-aes-ccm.c
index 39d4224..666a35b 100644
--- a/drivers/crypto/nx/nx-aes-ccm.c
+++ b/drivers/crypto/nx/nx-aes-ccm.c
@@ -293,7 +293,7 @@ static int ccm_nx_decrypt(struct aead_request *req,
if (rc)
goto out;
- rc = nx_build_sg_lists(nx_ctx, desc, req-dst, req-src, nbytes,
+ rc = nx_build_sg_lists(nx_ctx, desc, req-dst, req-src, nbytes, 0,
csbcpb-cpb.aes_ccm.iv_or_ctr);
if (rc)
goto out;
@@ -339,7 +339,7 @@ static int ccm_nx_encrypt(struct aead_request *req,
if (rc)
goto out;
- rc = nx_build_sg_lists(nx_ctx, desc, req-dst, req-src, nbytes,
+ rc = nx_build_sg_lists(nx_ctx, desc, req-dst, req-src, nbytes, 0,
csbcpb-cpb.aes_ccm.iv_or_ctr);
if (rc)
goto out;
diff --git a/drivers/crypto/nx/nx-aes-ctr.c b/drivers/crypto/nx/nx-aes-ctr.c
index 762611b..80dee8d 100644
--- a/drivers/crypto/nx/nx-aes-ctr.c
+++ b/drivers/crypto/nx/nx-aes-ctr.c
@@ -98,7 +98,7 @@ static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
goto out;
}
- rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes,
+ rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes, 0,
csbcpb-cpb.aes_ctr.iv);
if (rc)
goto out;
diff --git a/drivers/crypto/nx/nx-aes-ecb.c b/drivers/crypto/nx/nx-aes-ecb.c
index 77dbe08..fe0d803 100644
--- a/drivers/crypto/nx/nx-aes-ecb.c
+++ b/drivers/crypto/nx/nx-aes-ecb.c
@@ -85,7 +85,7 @@ static int ecb_aes_nx_crypt(struct blkcipher_desc *desc,
else
NX_CPB_FDM(csbcpb) = ~NX_FDM_ENDE_ENCRYPT;
- rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes, NULL);
+ rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes, 0, NULL);
if (rc)
goto out;
diff --git a/drivers/crypto/nx/nx-aes-gcm.c b/drivers/crypto/nx/nx-aes-gcm.c
index 74feee1..c2d6f76 100644
--- a/drivers/crypto/nx/nx-aes-gcm.c
+++ b/drivers/crypto/nx/nx-aes-gcm.c
@@ -226,7 +226,7 @@ static int gcm_aes_nx_crypt(struct aead_request *req, int
enc)
csbcpb-cpb.aes_gcm.bit_length_data = nbytes * 8;
- rc = nx_build_sg_lists(nx_ctx, desc, req-dst, req-src, nbytes,
+ rc = nx_build_sg_lists(nx_ctx, desc, req-dst, req-src, nbytes, 0,
csbcpb-cpb.aes_gcm.iv_or_cnt);
if (rc)
goto out;
diff --git a/drivers/crypto/nx/nx.c b/drivers/crypto/nx/nx.c
index bdf4990..5533fe3 100644
--- a/drivers/crypto/nx/nx.c
+++ b/drivers/crypto/nx/nx.c
@@ -211,6 +211,8 @@ struct nx_sg *nx_walk_and_build(struct nx_sg *nx_dst,
* @dst: destination scatterlist
* @src: source scatterlist
* @nbytes: length of data described in the scatterlists
+ * @offset: number of bytes to fast-forward past at the beginning of
+ * scatterlists.
* @iv: destination for the iv data, if the algorithm requires it
*
* This is common code shared by all the AES algorithms. It uses the block
@@ -222,6 +224,7 @@ int nx_build_sg_lists(struct nx_crypto_ctx *nx_ctx,
struct scatterlist*dst,
struct scatterlist*src,
unsigned int nbytes,
+ unsigned int offset,
u8*iv)
{
struct nx_sg *nx_insg = nx_ctx-in_sg;
@@ -230,8 +233,10 @@ int nx_build_sg_lists(struct nx_crypto_ctx *nx_ctx,
if (iv)
memcpy(iv, desc-info, AES_BLOCK_SIZE);
- nx_insg = nx_walk_and_build(nx_insg, nx_ctx-ap-sglen, src, 0, nbytes);
- nx_outsg =
[PATCH 03/10] crypto: nx - fix limits to sg lists for AES-CBC
This patch updates the nx-aes-cbc implementation to perform several
hyper calls if needed in order to always respect the length limits for
scatter/gather lists.
Two different limits are considered:
- ibm,max-sg-len: maximum number of bytes of each scatter/gather
list.
- ibm,max-sync-cop:
- The total number of bytes that a scatter/gather list can hold.
- The maximum number of elements that a scatter/gather list can have.
Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-cbc.c | 50 +-
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c b/drivers/crypto/nx/nx-aes-cbc.c
index f334a60..fa37df1 100644
--- a/drivers/crypto/nx/nx-aes-cbc.c
+++ b/drivers/crypto/nx/nx-aes-cbc.c
@@ -71,40 +71,50 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc-tfm);
struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
unsigned long irq_flags;
+ unsigned int processed = 0, to_process;
+ u32 max_sg_len;
int rc;
spin_lock_irqsave(nx_ctx-lock, irq_flags);
- if (nbytes nx_ctx-ap-databytelen) {
- rc = -EINVAL;
- goto out;
- }
+ max_sg_len = min_t(u32, nx_driver.of.max_sg_len/sizeof(struct nx_sg),
+ nx_ctx-ap-sglen);
if (enc)
NX_CPB_FDM(csbcpb) |= NX_FDM_ENDE_ENCRYPT;
else
NX_CPB_FDM(csbcpb) = ~NX_FDM_ENDE_ENCRYPT;
- rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes, 0,
- csbcpb-cpb.aes_cbc.iv);
- if (rc)
- goto out;
+ do {
+ to_process = min_t(u64, nbytes - processed,
+ nx_ctx-ap-databytelen);
+ to_process = min_t(u64, to_process,
+ NX_PAGE_SIZE * (max_sg_len - 1));
+ to_process = to_process ~(AES_BLOCK_SIZE - 1);
- if (!nx_ctx-op.inlen || !nx_ctx-op.outlen) {
- rc = -EINVAL;
- goto out;
- }
+ rc = nx_build_sg_lists(nx_ctx, desc, dst, src, to_process,
+ processed, csbcpb-cpb.aes_cbc.iv);
+ if (rc)
+ goto out;
- rc = nx_hcall_sync(nx_ctx, nx_ctx-op,
- desc-flags CRYPTO_TFM_REQ_MAY_SLEEP);
- if (rc)
- goto out;
+ if (!nx_ctx-op.inlen || !nx_ctx-op.outlen) {
+ rc = -EINVAL;
+ goto out;
+ }
- memcpy(desc-info, csbcpb-cpb.aes_cbc.cv, AES_BLOCK_SIZE);
+ rc = nx_hcall_sync(nx_ctx, nx_ctx-op,
+ desc-flags CRYPTO_TFM_REQ_MAY_SLEEP);
+ if (rc)
+ goto out;
- atomic_inc((nx_ctx-stats-aes_ops));
- atomic64_add(csbcpb-csb.processed_byte_count,
-(nx_ctx-stats-aes_bytes));
+ memcpy(desc-info, csbcpb-cpb.aes_cbc.cv, AES_BLOCK_SIZE);
+
+ atomic_inc((nx_ctx-stats-aes_ops));
+ atomic64_add(csbcpb-csb.processed_byte_count,
+(nx_ctx-stats-aes_bytes));
+
+ processed += to_process;
+ } while (processed nbytes);
out:
spin_unlock_irqrestore(nx_ctx-lock, irq_flags);
return rc;
--
1.7.12
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 04/10] crypto: nx - fix limits to sg lists for AES-CTR
This patch updates the nx-aes-ctr implementation to perform several
hyper calls if needed in order to always respect the length limits for
scatter/gather lists.
Two different limits are considered:
- ibm,max-sg-len: maximum number of bytes of each scatter/gather
list.
- ibm,max-sync-cop:
- The total number of bytes that a scatter/gather list can hold.
- The maximum number of elements that a scatter/gather list can have.
Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-ctr.c | 50 ++
1 file changed, 31 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-ctr.c b/drivers/crypto/nx/nx-aes-ctr.c
index 80dee8d..a37d009 100644
--- a/drivers/crypto/nx/nx-aes-ctr.c
+++ b/drivers/crypto/nx/nx-aes-ctr.c
@@ -89,33 +89,45 @@ static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc-tfm);
struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
unsigned long irq_flags;
+ unsigned int processed = 0, to_process;
+ u32 max_sg_len;
int rc;
spin_lock_irqsave(nx_ctx-lock, irq_flags);
- if (nbytes nx_ctx-ap-databytelen) {
- rc = -EINVAL;
- goto out;
- }
+ max_sg_len = min_t(u32, nx_driver.of.max_sg_len/sizeof(struct nx_sg),
+ nx_ctx-ap-sglen);
- rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes, 0,
- csbcpb-cpb.aes_ctr.iv);
- if (rc)
- goto out;
+ do {
+ to_process = min_t(u64, nbytes - processed,
+ nx_ctx-ap-databytelen);
+ to_process = min_t(u64, to_process,
+ NX_PAGE_SIZE * (max_sg_len - 1));
+ to_process = to_process ~(AES_BLOCK_SIZE - 1);
- if (!nx_ctx-op.inlen || !nx_ctx-op.outlen) {
- rc = -EINVAL;
- goto out;
- }
+ rc = nx_build_sg_lists(nx_ctx, desc, dst, src, to_process,
+ processed, csbcpb-cpb.aes_ctr.iv);
+ if (rc)
+ goto out;
- rc = nx_hcall_sync(nx_ctx, nx_ctx-op,
- desc-flags CRYPTO_TFM_REQ_MAY_SLEEP);
- if (rc)
- goto out;
+ if (!nx_ctx-op.inlen || !nx_ctx-op.outlen) {
+ rc = -EINVAL;
+ goto out;
+ }
- atomic_inc((nx_ctx-stats-aes_ops));
- atomic64_add(csbcpb-csb.processed_byte_count,
-(nx_ctx-stats-aes_bytes));
+ rc = nx_hcall_sync(nx_ctx, nx_ctx-op,
+ desc-flags CRYPTO_TFM_REQ_MAY_SLEEP);
+ if (rc)
+ goto out;
+
+ memcpy(desc-info, csbcpb-cpb.aes_cbc.cv, AES_BLOCK_SIZE);
+
+ atomic_inc((nx_ctx-stats-aes_ops));
+ atomic64_add(csbcpb-csb.processed_byte_count,
+(nx_ctx-stats-aes_bytes));
+
+ processed += to_process;
+ } while (processed nbytes);
out:
spin_unlock_irqrestore(nx_ctx-lock, irq_flags);
return rc;
--
1.7.12
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 05/10] crypto: nx - fix limits to sg lists for AES-GCM
This patch updates the nx-aes-gcm implementation to perform several
hyper calls if needed in order to always respect the length limits for
scatter/gather lists.
Two different limits are considered:
- ibm,max-sg-len: maximum number of bytes of each scatter/gather
list.
- ibm,max-sync-cop:
- The total number of bytes that a scatter/gather list can hold.
- The maximum number of elements that a scatter/gather list can have.
Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-gcm.c | 202 +++--
1 file changed, 136 insertions(+), 66 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-gcm.c b/drivers/crypto/nx/nx-aes-gcm.c
index c2d6f76..9e89bdf 100644
--- a/drivers/crypto/nx/nx-aes-gcm.c
+++ b/drivers/crypto/nx/nx-aes-gcm.c
@@ -125,37 +125,101 @@ static int nx_gca(struct nx_crypto_ctx *nx_ctx,
struct aead_request *req,
u8*out)
{
+ int rc;
struct nx_csbcpb *csbcpb_aead = nx_ctx-csbcpb_aead;
- int rc = -EINVAL;
struct scatter_walk walk;
struct nx_sg *nx_sg = nx_ctx-in_sg;
+ unsigned int nbytes = req-assoclen;
+ unsigned int processed = 0, to_process;
+ u32 max_sg_len;
- if (req-assoclen nx_ctx-ap-databytelen)
- goto out;
-
- if (req-assoclen = AES_BLOCK_SIZE) {
+ if (nbytes = AES_BLOCK_SIZE) {
scatterwalk_start(walk, req-assoc);
- scatterwalk_copychunks(out, walk, req-assoclen,
- SCATTERWALK_FROM_SG);
+ scatterwalk_copychunks(out, walk, nbytes, SCATTERWALK_FROM_SG);
scatterwalk_done(walk, SCATTERWALK_FROM_SG, 0);
-
- rc = 0;
- goto out;
+ return 0;
}
- nx_sg = nx_walk_and_build(nx_sg, nx_ctx-ap-sglen, req-assoc, 0,
- req-assoclen);
- nx_ctx-op_aead.inlen = (nx_ctx-in_sg - nx_sg) * sizeof(struct nx_sg);
+ NX_CPB_FDM(csbcpb_aead) = ~NX_FDM_CONTINUATION;
- rc = nx_hcall_sync(nx_ctx, nx_ctx-op_aead,
- req-base.flags CRYPTO_TFM_REQ_MAY_SLEEP);
- if (rc)
- goto out;
+ /* page_limit: number of sg entries that fit on one page */
+ max_sg_len = min_t(u32, nx_driver.of.max_sg_len/sizeof(struct nx_sg),
+ nx_ctx-ap-sglen);
- atomic_inc((nx_ctx-stats-aes_ops));
- atomic64_add(req-assoclen, (nx_ctx-stats-aes_bytes));
+ do {
+ /*
+* to_process: the data chunk to process in this update.
+* This value is bound by sg list limits.
+*/
+ to_process = min_t(u64, nbytes - processed,
+ nx_ctx-ap-databytelen);
+ to_process = min_t(u64, to_process,
+ NX_PAGE_SIZE * (max_sg_len - 1));
+
+ if ((to_process + processed) nbytes)
+ NX_CPB_FDM(csbcpb_aead) |= NX_FDM_INTERMEDIATE;
+ else
+ NX_CPB_FDM(csbcpb_aead) = ~NX_FDM_INTERMEDIATE;
+
+ nx_sg = nx_walk_and_build(nx_ctx-in_sg, nx_ctx-ap-sglen,
+ req-assoc, processed, to_process);
+ nx_ctx-op_aead.inlen = (nx_ctx-in_sg - nx_sg)
+ * sizeof(struct nx_sg);
+
+ rc = nx_hcall_sync(nx_ctx, nx_ctx-op_aead,
+ req-base.flags CRYPTO_TFM_REQ_MAY_SLEEP);
+ if (rc)
+ return rc;
+
+ memcpy(csbcpb_aead-cpb.aes_gca.in_pat,
+ csbcpb_aead-cpb.aes_gca.out_pat,
+ AES_BLOCK_SIZE);
+ NX_CPB_FDM(csbcpb_aead) |= NX_FDM_CONTINUATION;
+
+ atomic_inc((nx_ctx-stats-aes_ops));
+ atomic64_add(req-assoclen, (nx_ctx-stats-aes_bytes));
+
+ processed += to_process;
+ } while (processed nbytes);
memcpy(out, csbcpb_aead-cpb.aes_gca.out_pat, AES_BLOCK_SIZE);
+
+ return rc;
+}
+
+static int gcm_empty(struct aead_request *req, struct blkcipher_desc *desc,
+int enc)
+{
+ int rc;
+ struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(req-base.tfm);
+ struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
+
+ /* For scenarios where the input message is zero length, AES CTR mode
+* may be used. Set the source data to be a single block (16B) of all
+* zeros, and set the input IV value to be the same as the GMAC IV
+* value. - nx_wb 4.8.1.3 */
+ char src[AES_BLOCK_SIZE] = {};
+ struct scatterlist sg;
+
+ desc-tfm = crypto_alloc_blkcipher(ctr(aes), 0, 0);
+ if (IS_ERR(desc-tfm)) {
+ rc = -ENOMEM;
+
[PATCH 02/10] crypto: nx - fix limits to sg lists for AES-ECB
This patch updates the nx-aes-ecb implementation to perform several
hyper calls if needed in order to always respect the length limits for
scatter/gather lists.
Two different limits are considered:
- ibm,max-sg-len: maximum number of bytes of each scatter/gather
list.
- ibm,max-sync-cop:
- The total number of bytes that a scatter/gather list can hold.
- The maximum number of elements that a scatter/gather list can have.
Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-ecb.c | 48 ++
1 file changed, 30 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-ecb.c b/drivers/crypto/nx/nx-aes-ecb.c
index fe0d803..85a8d23 100644
--- a/drivers/crypto/nx/nx-aes-ecb.c
+++ b/drivers/crypto/nx/nx-aes-ecb.c
@@ -71,37 +71,49 @@ static int ecb_aes_nx_crypt(struct blkcipher_desc *desc,
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc-tfm);
struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
unsigned long irq_flags;
+ unsigned int processed = 0, to_process;
+ u32 max_sg_len;
int rc;
spin_lock_irqsave(nx_ctx-lock, irq_flags);
- if (nbytes nx_ctx-ap-databytelen) {
- rc = -EINVAL;
- goto out;
- }
+ max_sg_len = min_t(u32, nx_driver.of.max_sg_len/sizeof(struct nx_sg),
+ nx_ctx-ap-sglen);
if (enc)
NX_CPB_FDM(csbcpb) |= NX_FDM_ENDE_ENCRYPT;
else
NX_CPB_FDM(csbcpb) = ~NX_FDM_ENDE_ENCRYPT;
- rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes, 0, NULL);
- if (rc)
- goto out;
+ do {
+ to_process = min_t(u64, nbytes - processed,
+ nx_ctx-ap-databytelen);
+ to_process = min_t(u64, to_process,
+ NX_PAGE_SIZE * (max_sg_len - 1));
+ to_process = to_process ~(AES_BLOCK_SIZE - 1);
- if (!nx_ctx-op.inlen || !nx_ctx-op.outlen) {
- rc = -EINVAL;
- goto out;
- }
+ rc = nx_build_sg_lists(nx_ctx, desc, dst, src, to_process,
+ processed, NULL);
+ if (rc)
+ goto out;
- rc = nx_hcall_sync(nx_ctx, nx_ctx-op,
- desc-flags CRYPTO_TFM_REQ_MAY_SLEEP);
- if (rc)
- goto out;
+ if (!nx_ctx-op.inlen || !nx_ctx-op.outlen) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ rc = nx_hcall_sync(nx_ctx, nx_ctx-op,
+ desc-flags CRYPTO_TFM_REQ_MAY_SLEEP);
+ if (rc)
+ goto out;
+
+ atomic_inc((nx_ctx-stats-aes_ops));
+ atomic64_add(csbcpb-csb.processed_byte_count,
+(nx_ctx-stats-aes_bytes));
+
+ processed += to_process;
+ } while (processed nbytes);
- atomic_inc((nx_ctx-stats-aes_ops));
- atomic64_add(csbcpb-csb.processed_byte_count,
-(nx_ctx-stats-aes_bytes));
out:
spin_unlock_irqrestore(nx_ctx-lock, irq_flags);
return rc;
--
1.7.12
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 08/10] crypto: nx - fix XCBC for zero length messages
The NX XCBC implementation doesn't support zero length messages and
because of that NX is currently returning a hard-coded hash for zero
length messages. However this approach is incorrect since the hash value
also depends on which key is used.
This patch removes the hard-coded hash and replace it with an
implementation based on the RFC 3566 using ECB.
Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-xcbc.c | 84 +
1 file changed, 77 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-xcbc.c b/drivers/crypto/nx/nx-aes-xcbc.c
index 1a5d9e3..03c4bf5 100644
--- a/drivers/crypto/nx/nx-aes-xcbc.c
+++ b/drivers/crypto/nx/nx-aes-xcbc.c
@@ -56,6 +56,77 @@ static int nx_xcbc_set_key(struct crypto_shash *desc,
return 0;
}
+/*
+ * Based on RFC 3566, for a zero-length message:
+ *
+ * n = 1
+ * K1 = E(K, 0x01010101010101010101010101010101)
+ * K3 = E(K, 0x03030303030303030303030303030303)
+ * E[0] = 0x
+ * M[1] = 0x8000 (0 length message with padding)
+ * E[1] = (K1, M[1] ^ E[0] ^ K3)
+ * Tag = M[1]
+ */
+static int nx_xcbc_empty(struct shash_desc *desc, u8 *out)
+{
+ struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(desc-tfm-base);
+ struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
+ struct nx_sg *in_sg, *out_sg;
+ u8 keys[2][AES_BLOCK_SIZE];
+ u8 key[32];
+ int rc = 0;
+
+ /* Change to ECB mode */
+ csbcpb-cpb.hdr.mode = NX_MODE_AES_ECB;
+ memcpy(key, csbcpb-cpb.aes_xcbc.key, AES_BLOCK_SIZE);
+ memcpy(csbcpb-cpb.aes_ecb.key, key, AES_BLOCK_SIZE);
+ NX_CPB_FDM(csbcpb) |= NX_FDM_ENDE_ENCRYPT;
+
+ /* K1 and K3 base patterns */
+ memset(keys[0], 0x01, sizeof(keys[0]));
+ memset(keys[1], 0x03, sizeof(keys[1]));
+
+ /* Generate K1 and K3 encrypting the patterns */
+ in_sg = nx_build_sg_list(nx_ctx-in_sg, (u8 *) keys, sizeof(keys),
+nx_ctx-ap-sglen);
+ out_sg = nx_build_sg_list(nx_ctx-out_sg, (u8 *) keys, sizeof(keys),
+ nx_ctx-ap-sglen);
+ nx_ctx-op.inlen = (nx_ctx-in_sg - in_sg) * sizeof(struct nx_sg);
+ nx_ctx-op.outlen = (nx_ctx-out_sg - out_sg) * sizeof(struct nx_sg);
+
+ rc = nx_hcall_sync(nx_ctx, nx_ctx-op,
+ desc-flags CRYPTO_TFM_REQ_MAY_SLEEP);
+ if (rc)
+ goto out;
+ atomic_inc((nx_ctx-stats-aes_ops));
+
+ /* XOr K3 with the padding for a 0 length message */
+ keys[1][0] ^= 0x80;
+
+ /* Encrypt the final result */
+ memcpy(csbcpb-cpb.aes_ecb.key, keys[0], AES_BLOCK_SIZE);
+ in_sg = nx_build_sg_list(nx_ctx-in_sg, (u8 *) keys[1], sizeof(keys[1]),
+nx_ctx-ap-sglen);
+ out_sg = nx_build_sg_list(nx_ctx-out_sg, out, AES_BLOCK_SIZE,
+ nx_ctx-ap-sglen);
+ nx_ctx-op.inlen = (nx_ctx-in_sg - in_sg) * sizeof(struct nx_sg);
+ nx_ctx-op.outlen = (nx_ctx-out_sg - out_sg) * sizeof(struct nx_sg);
+
+ rc = nx_hcall_sync(nx_ctx, nx_ctx-op,
+ desc-flags CRYPTO_TFM_REQ_MAY_SLEEP);
+ if (rc)
+ goto out;
+ atomic_inc((nx_ctx-stats-aes_ops));
+
+out:
+ /* Restore XCBC mode */
+ csbcpb-cpb.hdr.mode = NX_MODE_AES_XCBC_MAC;
+ memcpy(csbcpb-cpb.aes_xcbc.key, key, AES_BLOCK_SIZE);
+ NX_CPB_FDM(csbcpb) = ~NX_FDM_ENDE_ENCRYPT;
+
+ return rc;
+}
+
static int nx_xcbc_init(struct shash_desc *desc)
{
struct xcbc_state *sctx = shash_desc_ctx(desc);
@@ -201,13 +272,12 @@ static int nx_xcbc_final(struct shash_desc *desc, u8 *out)
memcpy(csbcpb-cpb.aes_xcbc.cv,
csbcpb-cpb.aes_xcbc.out_cv_mac, AES_BLOCK_SIZE);
} else if (sctx-count == 0) {
- /* we've never seen an update, so this is a 0 byte op. The
-* hardware cannot handle a 0 byte op, so just copy out the
-* known 0 byte result. This is cheaper than allocating a
-* software context to do a 0 byte op */
- u8 data[] = { 0x75, 0xf0, 0x25, 0x1d, 0x52, 0x8a, 0xc0, 0x1c,
- 0x45, 0x73, 0xdf, 0xd5, 0x84, 0xd7, 0x9f, 0x29 };
- memcpy(out, data, sizeof(data));
+ /*
+* we've never seen an update, so this is a 0 byte op. The
+* hardware cannot handle a 0 byte op, so just ECB to
+* generate the hash.
+*/
+ rc = nx_xcbc_empty(desc, out);
goto out;
}
--
1.7.12
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 06/10] crypto: nx - fix limits to sg lists for AES-XCBC
From: Fionnuala Gunter f...@linux.vnet.ibm.com
This patch updates the NX driver to perform several hyper calls when necessary
so that the length limits of scatter/gather lists are respected.
Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com
Reviewed-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
Signed-off-by: Fionnuala Gunter f...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-xcbc.c | 107 +++-
1 file changed, 63 insertions(+), 44 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-xcbc.c b/drivers/crypto/nx/nx-aes-xcbc.c
index 658da0f..1a5d9e3 100644
--- a/drivers/crypto/nx/nx-aes-xcbc.c
+++ b/drivers/crypto/nx/nx-aes-xcbc.c
@@ -88,78 +88,97 @@ static int nx_xcbc_update(struct shash_desc *desc,
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(desc-tfm-base);
struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
struct nx_sg *in_sg;
- u32 to_process, leftover;
+ u32 to_process, leftover, total;
+ u32 max_sg_len;
unsigned long irq_flags;
int rc = 0;
spin_lock_irqsave(nx_ctx-lock, irq_flags);
- if (NX_CPB_FDM(csbcpb) NX_FDM_CONTINUATION) {
- /* we've hit the nx chip previously and we're updating again,
-* so copy over the partial digest */
- memcpy(csbcpb-cpb.aes_xcbc.cv,
- csbcpb-cpb.aes_xcbc.out_cv_mac, AES_BLOCK_SIZE);
- }
+
+ total = sctx-count + len;
/* 2 cases for total data len:
* 1: = AES_BLOCK_SIZE: copy into state, return 0
* 2: AES_BLOCK_SIZE: process X blocks, copy in leftover
*/
- if (len + sctx-count = AES_BLOCK_SIZE) {
+ if (total = AES_BLOCK_SIZE) {
memcpy(sctx-buffer + sctx-count, data, len);
sctx-count += len;
goto out;
}
- /* to_process: the AES_BLOCK_SIZE data chunk to process in this
-* update */
- to_process = (sctx-count + len) ~(AES_BLOCK_SIZE - 1);
- leftover = (sctx-count + len) (AES_BLOCK_SIZE - 1);
+ in_sg = nx_ctx-in_sg;
+ max_sg_len = min_t(u32, nx_driver.of.max_sg_len/sizeof(struct nx_sg),
+ nx_ctx-ap-sglen);
- /* the hardware will not accept a 0 byte operation for this algorithm
-* and the operation MUST be finalized to be correct. So if we happen
-* to get an update that falls on a block sized boundary, we must
-* save off the last block to finalize with later. */
- if (!leftover) {
- to_process -= AES_BLOCK_SIZE;
- leftover = AES_BLOCK_SIZE;
- }
+ do {
- if (sctx-count) {
- in_sg = nx_build_sg_list(nx_ctx-in_sg, sctx-buffer,
-sctx-count, nx_ctx-ap-sglen);
- in_sg = nx_build_sg_list(in_sg, (u8 *)data,
-to_process - sctx-count,
-nx_ctx-ap-sglen);
- nx_ctx-op.inlen = (nx_ctx-in_sg - in_sg) *
- sizeof(struct nx_sg);
- } else {
- in_sg = nx_build_sg_list(nx_ctx-in_sg, (u8 *)data, to_process,
-nx_ctx-ap-sglen);
+ /* to_process: the AES_BLOCK_SIZE data chunk to process in this
+* update */
+ to_process = min_t(u64, total, nx_ctx-ap-databytelen);
+ to_process = min_t(u64, to_process,
+ NX_PAGE_SIZE * (max_sg_len - 1));
+ to_process = to_process ~(AES_BLOCK_SIZE - 1);
+ leftover = total - to_process;
+
+ /* the hardware will not accept a 0 byte operation for this
+* algorithm and the operation MUST be finalized to be correct.
+* So if we happen to get an update that falls on a block sized
+* boundary, we must save off the last block to finalize with
+* later. */
+ if (!leftover) {
+ to_process -= AES_BLOCK_SIZE;
+ leftover = AES_BLOCK_SIZE;
+ }
+
+ if (sctx-count) {
+ in_sg = nx_build_sg_list(nx_ctx-in_sg,
+ (u8 *) sctx-buffer,
+ sctx-count,
+ max_sg_len);
+ }
+ in_sg = nx_build_sg_list(in_sg,
+ (u8 *) data,
+ to_process - sctx-count,
+ max_sg_len);
nx_ctx-op.inlen = (nx_ctx-in_sg - in_sg) *
sizeof(struct nx_sg);
- }
- NX_CPB_FDM(csbcpb) |= NX_FDM_INTERMEDIATE;
+ /* we've hit the nx chip previously and we're updating again,
+
[PATCH 09/10] crypto: nx - fix GCM for zero length messages
The NX CGM implementation doesn't support zero length messages and the
current implementation has two flaws:
- When the input data length is zero, it ignores the associated data.
- Even when both lengths are zero, it uses the Crypto API to encrypt a
zeroed block using ctr(aes) and because of this it allocates a new
transformation and sets the key for this new tfm. Both operations are
intended to be used only in user context, while the cryptographic
operations can be called in both user and softirq contexts.
This patch replaces the nested Crypto API use and adds two special
cases:
- When input data and associated data lengths are zero: it uses NX ECB
mode to emulate the encryption of a zeroed block using ctr(aes).
- When input data is zero and associated data is available: it uses NX
GMAC mode to calculate the associated data MAC.
Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-gcm.c | 132 ++---
1 file changed, 112 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-gcm.c b/drivers/crypto/nx/nx-aes-gcm.c
index 9e89bdf..025d9a8 100644
--- a/drivers/crypto/nx/nx-aes-gcm.c
+++ b/drivers/crypto/nx/nx-aes-gcm.c
@@ -187,40 +187,125 @@ static int nx_gca(struct nx_crypto_ctx *nx_ctx,
return rc;
}
+static int gmac(struct aead_request *req, struct blkcipher_desc *desc)
+{
+ int rc;
+ struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(req-base.tfm);
+ struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
+ struct nx_sg *nx_sg;
+ unsigned int nbytes = req-assoclen;
+ unsigned int processed = 0, to_process;
+ u32 max_sg_len;
+
+ /* Set GMAC mode */
+ csbcpb-cpb.hdr.mode = NX_MODE_AES_GMAC;
+
+ NX_CPB_FDM(csbcpb) = ~NX_FDM_CONTINUATION;
+
+ /* page_limit: number of sg entries that fit on one page */
+ max_sg_len = min_t(u32, nx_driver.of.max_sg_len/sizeof(struct nx_sg),
+ nx_ctx-ap-sglen);
+
+ /* Copy IV */
+ memcpy(csbcpb-cpb.aes_gcm.iv_or_cnt, desc-info, AES_BLOCK_SIZE);
+
+ do {
+ /*
+* to_process: the data chunk to process in this update.
+* This value is bound by sg list limits.
+*/
+ to_process = min_t(u64, nbytes - processed,
+ nx_ctx-ap-databytelen);
+ to_process = min_t(u64, to_process,
+ NX_PAGE_SIZE * (max_sg_len - 1));
+
+ if ((to_process + processed) nbytes)
+ NX_CPB_FDM(csbcpb) |= NX_FDM_INTERMEDIATE;
+ else
+ NX_CPB_FDM(csbcpb) = ~NX_FDM_INTERMEDIATE;
+
+ nx_sg = nx_walk_and_build(nx_ctx-in_sg, nx_ctx-ap-sglen,
+ req-assoc, processed, to_process);
+ nx_ctx-op.inlen = (nx_ctx-in_sg - nx_sg)
+ * sizeof(struct nx_sg);
+
+ csbcpb-cpb.aes_gcm.bit_length_data = 0;
+ csbcpb-cpb.aes_gcm.bit_length_aad = 8 * nbytes;
+
+ rc = nx_hcall_sync(nx_ctx, nx_ctx-op,
+ req-base.flags CRYPTO_TFM_REQ_MAY_SLEEP);
+ if (rc)
+ goto out;
+
+ memcpy(csbcpb-cpb.aes_gcm.in_pat_or_aad,
+ csbcpb-cpb.aes_gcm.out_pat_or_mac, AES_BLOCK_SIZE);
+ memcpy(csbcpb-cpb.aes_gcm.in_s0,
+ csbcpb-cpb.aes_gcm.out_s0, AES_BLOCK_SIZE);
+
+ NX_CPB_FDM(csbcpb) |= NX_FDM_CONTINUATION;
+
+ atomic_inc((nx_ctx-stats-aes_ops));
+ atomic64_add(req-assoclen, (nx_ctx-stats-aes_bytes));
+
+ processed += to_process;
+ } while (processed nbytes);
+
+out:
+ /* Restore GCM mode */
+ csbcpb-cpb.hdr.mode = NX_MODE_AES_GCM;
+ return rc;
+}
+
static int gcm_empty(struct aead_request *req, struct blkcipher_desc *desc,
int enc)
{
int rc;
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(req-base.tfm);
struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
+ char out[AES_BLOCK_SIZE];
+ struct nx_sg *in_sg, *out_sg;
/* For scenarios where the input message is zero length, AES CTR mode
* may be used. Set the source data to be a single block (16B) of all
* zeros, and set the input IV value to be the same as the GMAC IV
* value. - nx_wb 4.8.1.3 */
- char src[AES_BLOCK_SIZE] = {};
- struct scatterlist sg;
- desc-tfm = crypto_alloc_blkcipher(ctr(aes), 0, 0);
- if (IS_ERR(desc-tfm)) {
- rc = -ENOMEM;
- goto out;
- }
-
- crypto_blkcipher_setkey(desc-tfm, csbcpb-cpb.aes_gcm.key,
- NX_CPB_KEY_SIZE(csbcpb) == NX_KS_AES_128 ? 16 :
-
[PATCH 07/10] crypto: nx - fix limits to sg lists for AES-CCM
From: Fionnuala Gunter f...@linux.vnet.ibm.com
This patch updates the NX driver to perform several hyper calls when necessary
so that the length limits of scatter/gather lists are respected.
Reviewed-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
Signed-off-by: Joy Latten jmlat...@linux.vnet.ibm.com
Signed-off-by: Fionnuala Gunter f...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-ccm.c | 297 +
1 file changed, 215 insertions(+), 82 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-ccm.c b/drivers/crypto/nx/nx-aes-ccm.c
index 666a35b..5ecd4c2 100644
--- a/drivers/crypto/nx/nx-aes-ccm.c
+++ b/drivers/crypto/nx/nx-aes-ccm.c
@@ -179,13 +179,26 @@ static int generate_pat(u8 *iv,
struct nx_sg *nx_insg = nx_ctx-in_sg;
struct nx_sg *nx_outsg = nx_ctx-out_sg;
unsigned int iauth_len = 0;
- struct vio_pfo_op *op = NULL;
u8 tmp[16], *b1 = NULL, *b0 = NULL, *result = NULL;
int rc;
/* zero the ctr value */
memset(iv + 15 - iv[0], 0, iv[0] + 1);
+ /* page 78 of nx_wb.pdf has,
+* Note: RFC3610 allows the AAD data to be up to 2^64 -1 bytes
+* in length. If a full message is used, the AES CCA implementation
+* restricts the maximum AAD length to 2^32 -1 bytes.
+* If partial messages are used, the implementation supports
+* 2^64 -1 bytes maximum AAD length.
+*
+* However, in the cryptoapi's aead_request structure,
+* assoclen is an unsigned int, thus it cannot hold a length
+* value greater than 2^32 - 1.
+* Thus the AAD is further constrained by this and is never
+* greater than 2^32.
+*/
+
if (!req-assoclen) {
b0 = nx_ctx-csbcpb-cpb.aes_ccm.in_pat_or_b0;
} else if (req-assoclen = 14) {
@@ -195,7 +208,46 @@ static int generate_pat(u8 *iv,
b0 = nx_ctx-csbcpb-cpb.aes_ccm.in_pat_or_b0;
b1 = nx_ctx-priv.ccm.iauth_tag;
iauth_len = req-assoclen;
+ } else if (req-assoclen = 65280) {
+ /* if associated data is less than (2^16 - 2^8), we construct
+* B1 differently and feed in the associated data to a CCA
+* operation */
+ b0 = nx_ctx-csbcpb_aead-cpb.aes_cca.b0;
+ b1 = nx_ctx-csbcpb_aead-cpb.aes_cca.b1;
+ iauth_len = 14;
+ } else {
+ b0 = nx_ctx-csbcpb_aead-cpb.aes_cca.b0;
+ b1 = nx_ctx-csbcpb_aead-cpb.aes_cca.b1;
+ iauth_len = 10;
+ }
+ /* generate B0 */
+ rc = generate_b0(iv, req-assoclen, authsize, nbytes, b0);
+ if (rc)
+ return rc;
+
+ /* generate B1:
+* add control info for associated data
+* RFC 3610 and NIST Special Publication 800-38C
+*/
+ if (b1) {
+ memset(b1, 0, 16);
+ if (req-assoclen = 65280) {
+ *(u16 *)b1 = (u16)req-assoclen;
+ scatterwalk_map_and_copy(b1 + 2, req-assoc, 0,
+iauth_len, SCATTERWALK_FROM_SG);
+ } else {
+ *(u16 *)b1 = (u16)(0xfffe);
+ *(u32 *)b1[2] = (u32)req-assoclen;
+ scatterwalk_map_and_copy(b1 + 6, req-assoc, 0,
+iauth_len, SCATTERWALK_FROM_SG);
+ }
+ }
+
+ /* now copy any remaining AAD to scatterlist and call nx... */
+ if (!req-assoclen) {
+ return rc;
+ } else if (req-assoclen = 14) {
nx_insg = nx_build_sg_list(nx_insg, b1, 16, nx_ctx-ap-sglen);
nx_outsg = nx_build_sg_list(nx_outsg, tmp, 16,
nx_ctx-ap-sglen);
@@ -210,56 +262,74 @@ static int generate_pat(u8 *iv,
NX_CPB_FDM(nx_ctx-csbcpb) |= NX_FDM_ENDE_ENCRYPT;
NX_CPB_FDM(nx_ctx-csbcpb) |= NX_FDM_INTERMEDIATE;
- op = nx_ctx-op;
result = nx_ctx-csbcpb-cpb.aes_ccm.out_pat_or_mac;
- } else if (req-assoclen = 65280) {
- /* if associated data is less than (2^16 - 2^8), we construct
-* B1 differently and feed in the associated data to a CCA
-* operation */
- b0 = nx_ctx-csbcpb_aead-cpb.aes_cca.b0;
- b1 = nx_ctx-csbcpb_aead-cpb.aes_cca.b1;
- iauth_len = 14;
-
- /* remaining assoc data must have scatterlist built for it */
- nx_insg = nx_walk_and_build(nx_insg, nx_ctx-ap-sglen,
- req-assoc, iauth_len,
- req-assoclen - iauth_len);
- nx_ctx-op_aead.inlen = (nx_ctx-in_sg - nx_insg) *
+
+ rc = nx_hcall_sync(nx_ctx, nx_ctx-op,
+
[PATCH 10/10] crypto: nx - fix SHA-2 for chunks bigger than block size
Each call to the co-processor, with exception of the last call, needs to send data that is multiple of block size. As consequence, any remaining data is kept in the internal NX context. This patch fixes a bug in the driver that causes it to save incorrect data into the context when data is bigger than the block size. Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com --- drivers/crypto/nx/nx-sha256.c | 2 +- drivers/crypto/nx/nx-sha512.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/nx/nx-sha256.c b/drivers/crypto/nx/nx-sha256.c index 6547a71..da0b24a 100644 --- a/drivers/crypto/nx/nx-sha256.c +++ b/drivers/crypto/nx/nx-sha256.c @@ -129,7 +129,7 @@ static int nx_sha256_update(struct shash_desc *desc, const u8 *data, NX_CPB_FDM(csbcpb) |= NX_FDM_CONTINUATION; total -= to_process; - data += to_process; + data += to_process - sctx-count; sctx-count = 0; in_sg = nx_ctx-in_sg; } while (leftover = SHA256_BLOCK_SIZE); diff --git a/drivers/crypto/nx/nx-sha512.c b/drivers/crypto/nx/nx-sha512.c index 236e6af..4ae5b0f 100644 --- a/drivers/crypto/nx/nx-sha512.c +++ b/drivers/crypto/nx/nx-sha512.c @@ -131,7 +131,7 @@ static int nx_sha512_update(struct shash_desc *desc, const u8 *data, NX_CPB_FDM(csbcpb) |= NX_FDM_CONTINUATION; total -= to_process; - data += to_process; + data += to_process - sctx-count[0]; sctx-count[0] = 0; in_sg = nx_ctx-in_sg; } while (leftover = SHA512_BLOCK_SIZE); -- 1.7.12 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3] powerpc/mpc85xx: Update the clock device tree nodes
On Thu, Jun 06, 2013 at 09:06:51AM +0800, tang yuantian wrote:
From: Tang Yuantian yuantian.t...@freescale.com
The following SoCs will be affected: p2041, p3041, p4080,
p5020, p5040, b4420, b4860, t4240
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
v3:
- fix typo
v2:
- add t4240, b4420, b4860 support
- remove pll/4 clock from p2041, p3041 and p5020 board
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 32 -
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 32 -
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 54 ++-
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 54 ++-
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 100
+++-
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 +++
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 38 ++-
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 54 ++-
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 77 -
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12
16 files changed, 473 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
index 5a6615d..b69d6e5 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
@@ -85,7 +85,37 @@
};
clockgen: global-utilities@e1000 {
- compatible = fsl,b4420-clockgen, fsl,qoriq-clockgen-2.0;
+ compatible = fsl,b4420-clockgen, fsl,qoriq-clockgen-2.0,
+fixed-clock;
+ clock-output-names = sysclk;
+ #clock-cells = 0;
Does U-Boot fill in clock-frequency here?
+ #address-cells = 1;
+ #size-cells = 0;
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800;
+ compatible = fsl,core-pll-clock;
+ clocks = clockgen;
+ clock-output-names = pll0, pll0-div2, pll0-div4;
+ };
+ pll1: pll1@820 {
+ #clock-cells = 1;
+ reg = 0x820;
+ compatible = fsl,core-pll-clock;
+ clocks = clockgen;
+ clock-output-names = pll1, pll1-div2, pll1-div4;
+ };
Please leave a blank line between properties and nodes, and between
nodes.
What does reg represent? Where is the binding for this?
The compatible is too vague.
+ mux0: mux0@0 {
+ #clock-cells = 0;
+ reg = 0x0;
+ compatible = fsl,core-mux-clock;
+ clocks = pll0 0, pll0 1, pll0 2,
+ pll1 0, pll1 1, pll1 2;
+ clock-names = pll0_0, pll0_1, pll0_2,
+ pll1_0, pll1_1, pll1_2;
+ clock-output-names = cmux0;
+ };
What does reg represent? Where is the binding for this?
The compatible is too vague.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
Quoting Sascha Hauer (2013-08-23 07:01:28) On Fri, Aug 23, 2013 at 01:58:15PM +0100, Mark Rutland wrote: On Fri, Aug 23, 2013 at 07:34:21AM +0100, Sascha Hauer wrote: On Fri, Aug 23, 2013 at 12:49:19AM +0200, Tomasz Figa wrote: On Thursday 22 of August 2013 15:43:31 Mike Turquette wrote: Quoting Sascha Hauer (2013-08-22 14:00:35) On Thu, Aug 22, 2013 at 01:09:31PM +0100, Mark Rutland wrote: On Thu, Aug 22, 2013 at 08:19:10AM +0100, Mike Turquette wrote: Quoting Tomasz Figa (2013-08-21 14:34:55) On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote: On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote: Quoting Mark Rutland (2013-08-19 02:35:43) On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote: On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote: On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote: Also I would make this option required. Use a dummy clock for mux inputs that are grounded for a specific SoC. Some clocks are not from CCM and we haven't defined in imx6q-clk.txt, so in most cases we can't provide a phandle for them, eg: spdif_ext. I think it's a bit hard to force it to be 'required'. An 'optional' looks more flexible to me and a default one is ensured even if it's missing. clks 0 is the dummy clock. This can be used for all input clocks not defined by the SoC. Where does this assumption come from? Is it documented anywhere? This is how all i.MX clock bindings currently are. See Documentation/devicetree/bindings/clock/imx*-clock.txt OK, thanks. I guess we need some discussion on dummy clocks vs skipped clocks. I think we want some consistency on this, don't we? If we really need a dummy clock, then we might also want a generic way to specify it. What do we actually mean by a dummy clock? We already have bindings for fixed-clock and co friends describe relatively simple preconfigured clocks. Some platforms have a fake clock which defines noops callbacks and basically doesn't do anything. This is analogous to the dummy regulator implementation. A central one could be registered by the clock core, as is done by the regulator core. When you say some platforms, you presumably mean the platform code in Linux? A dummy clock sounds like a completely Linux-specific abstraction rather than a description of the hardware, and I don't see why we need that in the DT: * If a clock is wired up and running (as presumably the dummy clock is), then surely it's a fixed-clock (it's running, we and we have no control over it, but we presumably know its rate) and can be described as such? * If no clock is wired up, then we should be able to describe that. If a driver believes that a clock is required when it isn't (for some level of functionality), then that driver should be fixed up to support the clock as being optional. Am I missing something? I second that. Moreover, I don't think that device tree should deal with dummy anything. It should be able to describe hardware that is available on given system, not list what hardware is not available. I wasn't clear. The dummy clock IS a completely Linux-specific abstraction. I'm not advocating a dummy clock in DT. I am advocating consolidation of the implementation of a clock that does nothing into the clock core. This code could easily live in drivers/clk/clk.c instead of having everyone open-code it. As far as specifying a dummy clock in DT? I dunno. DT should describe real hardware so there isn't much use for a dummy clock.
Re: [PATCH][RFC] pci: fsl: rework PCIe driver compatible with Layerscape
On Mon, 2013-08-19 at 20:23 +0800, Minghuan Lian wrote:
The Freescale's Layerscape series processors will use ARM cores.
The LS1's PCIe controllers is the same as T4240's. So it's better
the PCIe controller driver can support PowerPC and ARM
simultaneously. This patch is for this purpose. It derives
the common functions from arch/powerpc/sysdev/fsl_pci.c to
drivers/pci/host/pcie-fsl.c and leaves several platform-dependent
functions which should be implemented in platform files.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
---
Based on upstream master 3.11-rc6
The function has been tested on P5020DS and P3041DS and T4240QDS boards
For mpc83xx and mpc86xx, I only did compile test.
I assume you'll test on these (and older mpc85xx) before this becomes
non-RFC?
arch/powerpc/Kconfig | 1 +
arch/powerpc/sysdev/fsl_pci.c | 591 ++
arch/powerpc/sysdev/fsl_pci.h | 91 --
drivers/edac/mpc85xx_edac.c | 10 -
drivers/pci/host/Kconfig | 4 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-fsl.c | 734
++
include/linux/fsl/fsl-pcie.h | 176 ++
8 files changed, 1008 insertions(+), 600 deletions(-)
create mode 100644 drivers/pci/host/pcie-fsl.c
create mode 100644 include/linux/fsl/fsl-pcie.h
Please use -M -C with git format-patch.
Why pcie rather than pci? Is non-express not supported by these new
files?
@@ -259,15 +258,6 @@ int mpc85xx_pci_err_probe(struct platform_device *op)
/* we only need the error registers */
r.start += 0xe00;
-
- if (!devm_request_mem_region(op-dev, r.start, resource_size(r),
- pdata-name)) {
- printk(KERN_ERR %s: Error while requesting mem region\n,
-__func__);
- res = -EBUSY;
- goto err;
- }
-
pdata-pci_vbase = devm_ioremap(op-dev, r.start, resource_size(r));
if (!pdata-pci_vbase) {
printk(KERN_ERR %s: Unable to setup PCI err regs\n, __func__);
Could you explain this part?
diff --git a/drivers/pci/host/pcie-fsl.c b/drivers/pci/host/pcie-fsl.c
new file mode 100644
index 000..6e767d4
--- /dev/null
+++ b/drivers/pci/host/pcie-fsl.c
@@ -0,0 +1,734 @@
+/*
+ * 85xx/86xx/LS PCI/PCIE common driver support
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Moved from arch/power/fsl_pci.c
That's not the right pathname.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/pci.h
+#include linux/string.h
+#include linux/init.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_pci.h
+#include linux/pci_regs.h
+#include linux/platform_device.h
+#include linux/resource.h
+#include linux/types.h
+#include linux/memblock.h
+#include linux/fsl/fsl-pcie.h
You don't need an fsl- prefix if it's in the fsl/ directory.
+static int fsl_pcie_write_config(struct fsl_pcie *pcie, int bus, int devfn,
+ int offset, int len, u32 val)
+{
+ void __iomem *cfg_data;
+ u32 bus_no, reg;
+
+ if (pcie-indirect_type INDIRECT_TYPE_NO_PCIE_LINK) {
+ if (bus != pcie-first_busno)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ if (devfn != 0)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ }
+
+ if (fsl_pci_exclude_device(pcie, bus, devfn))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ bus_no = (bus == pcie-first_busno) ?
+ pcie-self_busno : bus;
+
+ if (pcie-indirect_type INDIRECT_TYPE_EXT_REG)
+ reg = ((offset 0xf00) 16) | (offset 0xfc);
+ else
+ reg = offset 0xfc;
+
+ if (pcie-indirect_type INDIRECT_TYPE_BIG_ENDIAN)
+ out_be32(pcie-regs-config_addr,
+ (0x8000 | (bus_no 16) | (devfn 8) | reg));
+ else
+ out_le32(pcie-regs-config_addr,
+ (0x8000 | (bus_no 16) | (devfn 8) | reg));
Did you try building this on ARM? out_be32/le32() is PPC-specific. Use
iowrite32be()/iowrite32().
+ep_mode:
+ dev_info(pdev-dev, It works as EP mode\n);
This is a bit casually phrased... and where did this come from? This
patch should just be about moving code around and removing PPC
dependencies (ideally even those two would be separate). If there's
new functionality or other changes it should be a separate patch.
+static int __init fsl_pcie_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct fsl_pcie *pcie;
+
+ if (!of_device_is_available(pdev-dev.of_node)) {
+
Re: [PATCH v4 04/31] mtd: mpc5121_nfc: cleanup clock API use
On Tue, 6 Aug 2013 22:43:44 +0200 Gerhard Sittig g...@denx.de wrote: use devm_clk_get() for automatic put after device close, check for and propagate errors when enabling clocks, need to prepare clocks before they can get enabled, adjust error code paths to correctly balance get/put and prepare/unprepare and enable/disable calls Signed-off-by: Gerhard Sittig g...@denx.de --- drivers/mtd/nand/mpc5121_nfc.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) Applied to mpc5xxx tree, thanks! Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 05/31] [media] fsl-viu: cleanup clock API use
On Tue, 6 Aug 2013 22:43:45 +0200 Gerhard Sittig g...@denx.de wrote: use devm_clk_get() for automatic put after device close, check for and propagate errors when enabling clocks, need to prepare clocks before they can get enabled, adjust code paths to correctly balance get/put and prepare/unprepare and enable/disable calls Signed-off-by: Gerhard Sittig g...@denx.de --- drivers/media/platform/fsl-viu.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) Applied to mpc5xxx tree, thanks! Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 12/31] powerpc: mpc512x: array decl for MCLK registers in CCM
On Tue, 6 Aug 2013 22:43:52 +0200 Gerhard Sittig g...@denx.de wrote: reword the clock control module's registers declaration such that the MCLK related registers form an array and get indexed by PSC controller or CAN controller component number this change is in preparation to COMMON_CLK support for the MPC512x platform, the changed declaration remains neutral to existing code since the PSC and MSCAN CCR fields declared here aren't referenced anywhere Signed-off-by: Gerhard Sittig g...@denx.de --- arch/powerpc/include/asm/mpc5121.h | 18 ++ 1 file changed, 2 insertions(+), 16 deletions(-) Applied, thanks! Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 13/31] clk: wrap I/O access for improved portability
On Fri, 02 Aug 2013 15:30:00 -0700 Mike Turquette mturque...@linaro.org wrote: Quoting Gerhard Sittig (2013-07-22 05:14:40) the common clock drivers were motivated/initiated by ARM development and apparently assume little endian peripherals wrap register/peripherals access in the common code (div, gate, mux) in preparation of adding COMMON_CLK support for other platforms Signed-off-by: Gerhard Sittig g...@denx.de I've taken this into clk-next for testing. regmap deserves investigation but I don't think your series should be blocked on that. We can always overhaul the basic clock primitives with regmap support later on if that makes sense. Mike, I cannot see it in clk-next branch of git://git.linaro.org/people/mturquette/linux.git Can you please check? Or am I looking in the wrong place? Thanks, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 14/31] dts: mpc512x: prepare for preprocessor support
On Tue, 6 Aug 2013 22:43:54 +0200 Gerhard Sittig g...@denx.de wrote: prepare C preprocessor support when processing MPC512x DTS files - switch from DTS syntax to CPP syntax for include specs - create a symlink such that DTS processing can reference includes Signed-off-by: Gerhard Sittig g...@denx.de --- arch/powerpc/boot/dts/ac14xx.dts |2 +- arch/powerpc/boot/dts/include/dt-bindings |1 + arch/powerpc/boot/dts/mpc5121ads.dts |2 +- arch/powerpc/boot/dts/pdm360ng.dts|2 +- 4 files changed, 4 insertions(+), 3 deletions(-) create mode 12 arch/powerpc/boot/dts/include/dt-bindings Applied, thanks! Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH v2 06/11] pstore: Add decompression support to pstore
-Original Message- From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Aruna Balakrishnaiah Sent: Friday, August 16, 2013 9:18 AM To: linuxppc-...@ozlabs.org; tony.l...@intel.com; linux-ker...@vger.kernel.org; keesc...@chromium.org Cc: jkeni...@linux.vnet.ibm.com; ana...@in.ibm.com; b...@kernel.crashing.org; cbouatmai...@gmail.com; mah...@linux.vnet.ibm.com; ccr...@android.com Subject: [RFC PATCH v2 06/11] pstore: Add decompression support to pstore Based on the flag 'compressed' set or not, pstore will decompress the data returning a plain text file. If decompression fails for a particular record it will have the compressed data in the file which can be decompressed with 'openssl' command line tool. If the decompression fails and openssl doesn't work, the worst case is that users can't read the entry. In that case, pstore is meaningless at all. Also, for users who want to get a single panic message, a compression is not needed. So, I think we still have to support non-compression mode. (IMO, pstore can take kdump as a model. Kdump supports both compression and non-compression mode.) But, if you think my comment is outside this patchset, it's OK. We can make it with a separate patch. Seiji ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
-Original Message- From: Luck, Tony [mailto:tony.l...@intel.com] Sent: Thursday, August 22, 2013 7:17 PM To: Seiji Aguchi; Aruna Balakrishnaiah; linuxppc-...@ozlabs.org; linux-ker...@vger.kernel.org; keesc...@chromium.org Cc: jkeni...@linux.vnet.ibm.com; ana...@in.ibm.com; b...@kernel.crashing.org; cbouatmai...@gmail.com; mah...@linux.vnet.ibm.com; ccr...@android.com Subject: RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore 1[ 383.209057] RIP [813d3946] sysrq_handle_crash+0x16/0x20 4[ 383.209057] RSP 88006f551e80 4[ 383.209057] CR2: 4[ 383.209057] ---[ end trace 04a1cddad37b4b33 ]--- 3[ 383.209057] pstore: compression failed for Part 2 returned -5 3[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 2 3[ 383.209057] pstore: compression failed for Part 5 returned -5 Interesting. With ERST backend I didn't see these messages. Traces in pstore recovered files go as far as the line before the ---[ end trace 04a1cddad37b4b33 ]--- Why the difference depending on which back end is in use? I think the difference doesn't depend on the back end. Rather it depends on the environment. I tested on a kvm guest with OVMF. Seiji But I agree that we shouldn't have these messages. They use up space in the persistent store that could be better used saving some more lines from earlier in the console log. -Tony ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 V3] mmc:sdhc: get voltage from sdhc host
On 08/23/2013 09:48 AM, Anton Vorontsov wrote: On Mon, Aug 12, 2013 at 09:39:06AM +0800, Haijun Zhang wrote: We use host-ocr_mask to hold the voltage get from device-tree node, In case host-ocr_mask was available, we use host-ocr_mask as the final available voltage can be used by MMC/SD/SDIO card. Signed-off-by: Haijun Zhang haijun.zh...@freescale.com --- Reviewed-by: Anton Vorontsov an...@enomsg.org Thank you very much. -- Thanks Regards Haijun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
* callback from kmsg_dump. (s2,l2) has the most recently
* written bytes, older bytes are in (s1,l1). Save as much
@@ -148,23 +243,56 @@ static void pstore_dump(struct kmsg_dumper *dumper,
char *dst;
unsigned long size;
int hsize;
+ int zipped_len = -1;
size_t len;
- bool compressed = false;
+ bool compressed;
+ size_t total_len;
- dst = psinfo-buf;
- hsize = sprintf(dst, %s#%d Part%d\n, why, oopscount, part);
- size = psinfo-bufsize - hsize;
- dst += hsize;
+ if (big_oops_buf) {
+ dst = big_oops_buf;
+ hsize = sprintf(dst, %s#%d Part%d\n, why,
+ oopscount, part);
+ size = big_oops_buf_sz - hsize;
- if (!kmsg_dump_get_buffer(dumper, true, dst, size, len))
- break;
+ if (!kmsg_dump_get_buffer(dumper, true, dst + hsize,
+ size, len))
+ break;
+
+ zipped_len = pstore_compress(dst, psinfo-buf,
+ hsize + len, psinfo-bufsize);
+
+ if (zipped_len 0) {
+ compressed = true;
+ total_len = zipped_len;
+ } else {
+ pr_err(pstore: compression failed for Part %d
+ returned %d\n, part, zipped_len);
+ pr_err(pstore: Capture uncompressed
+ oops/panic report of Part %d\n,
part);
Why did you add these messages in pstore_dump()?
In my test case, they are not needed
snip
# cat dmesg-efi-1
Panic#2 Part1
4[ 383.209057] RBP: 88006f551e80 R08: 0002 R09:
4[ 383.209057] R10: 0382 R11: R12:
0063
4[ 383.209057] R13: 0286 R14: 000f R15:
4[ 383.209057] FS: 7f53317cc740() GS:88007c40()
knlGS:
4[ 383.209057] CS: 0010 DS: ES: CR0: 80050033
4[ 383.209057] CR2: CR3: 78a73000 CR4:
06f0
4[ 383.209057] Stack:
4[ 383.209057] 88006f551eb8 813d40a2 0002
7f53317db000
4[ 383.209057] 88006f551f50 0002
88006f551ed8
4[ 383.209057] 813d45aa 7f53317db000 88003f8c2b00
88006f551ef8
4[ 383.209057] Call Trace:
4[ 383.209057] [813d40a2] __handle_sysrq+0xa2/0x170
4[ 383.209057] [813d45aa] write_sysrq_trigger+0x4a/0x50
4[ 383.209057] [8121981d] proc_reg_write+0x3d/0x80
4[ 383.209057] [811aeb20] vfs_write+0xc0/0x1f0
4[ 383.209057] [811af59c] SyS_write+0x4c/0xa0
4[ 383.209057] [8168be82] system_call_fastpath+0x16/0x1b
4[ 383.209057] Code: ef e8 ff f7 ff ff eb d8 66 2e 0f 1f 84 00 00 00 00 00
0f 1f 00 0f 1f 44 00 00 55 c7 05 cc f3 c9 00 01 00 00 00 48 89 e5 0f ae f8 c6
04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e
1[ 383.209057] RIP [813d3946] sysrq_handle_crash+0x16/0x20
4[ 383.209057] RSP 88006f551e80
4[ 383.209057] CR2:
4[ 383.209057] ---[ end trace 04a1cddad37b4b33 ]---
3[ 383.209057] pstore: compression failed for Part 2 returned -5
3[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 2
3[ 383.209057] pstore: compression failed for Part 5 returned -5
3[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 5
3[ 383.209057] pstore: compression failed for Part 12 returned -5
3[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 12
0[ 383.209057] Kernel panic - not syncing: Fatal exception
3[ 383.209057] drm_kms_helper: panic occurred, switching back to text console
snip
In efi-pstore case, after rebooting a system,
we are able to know which entry failed to compress with 'C' or 'D' as below.
#ls /sys/firmware/efi/vars/ |grep dump
dump-type0-10-1-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-2-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-2-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-12-1-1377204734-D-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-2-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-12-2-1377204734-D-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-13-1-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-13-2-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1377204734-D-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
[PATCH 1/2] fs: implement inode uid/gid setting function
Supply a interface inode_set_user to set uid/gid of inode
structs.
Signed-off-by: Rui Xiang rui.xi...@huawei.com
---
fs/inode.c | 7 +++
include/linux/fs.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/fs/inode.c b/fs/inode.c
index e315c0a..3f90499 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -343,6 +343,13 @@ void inc_nlink(struct inode *inode)
}
EXPORT_SYMBOL(inc_nlink);
+void inode_set_user(struct inode *inode, kuid_t uid, kgid_t gid)
+{
+ inode-i_uid = uid;
+ inode-i_gid = gid;
+}
+EXPORT_SYMBOL(inode_set_user);
+
void address_space_init_once(struct address_space *mapping)
{
memset(mapping, 0, sizeof(*mapping));
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 729e81b..36ac51b 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2619,6 +2619,7 @@ void __inode_sub_bytes(struct inode *inode, loff_t bytes);
void inode_sub_bytes(struct inode *inode, loff_t bytes);
loff_t inode_get_bytes(struct inode *inode);
void inode_set_bytes(struct inode *inode, loff_t bytes);
+void inode_set_user(struct inode *inode, kuid_t uid, kgid_t gid);
extern int vfs_readdir(struct file *, filldir_t, void *);
extern int iterate_dir(struct file *, struct dir_context *);
--
1.8.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] fs: supply inode uid/gid setting interface
This patchset implements an accessor functions to set uid/gid in inode struct. Just finish code clean up. Rui Xiang (2): fs: implement inode uid/gid setting function fs: use inode_set_user to set uid/gid of inode arch/ia64/kernel/perfmon.c| 3 +-- arch/powerpc/platforms/cell/spufs/inode.c | 3 +-- arch/s390/hypfs/inode.c | 3 +-- drivers/infiniband/hw/qib/qib_fs.c| 3 +-- drivers/usb/gadget/f_fs.c | 3 +-- drivers/usb/gadget/inode.c| 5 +++-- fs/9p/vfs_inode.c | 6 ++ fs/adfs/inode.c | 3 +-- fs/affs/inode.c | 6 ++ fs/afs/inode.c| 6 ++ fs/anon_inodes.c | 3 +-- fs/autofs4/inode.c| 4 ++-- fs/befs/linuxvfs.c| 8 fs/ceph/caps.c| 5 +++-- fs/ceph/inode.c | 8 fs/cifs/inode.c | 6 ++ fs/configfs/inode.c | 3 +-- fs/debugfs/inode.c| 3 +-- fs/devpts/inode.c | 7 +++ fs/ext2/ialloc.c | 3 +-- fs/ext3/ialloc.c | 3 +-- fs/ext4/ialloc.c | 3 +-- fs/fat/inode.c| 6 ++ fs/fuse/control.c | 3 +-- fs/fuse/inode.c | 4 ++-- fs/hfs/inode.c| 6 ++ fs/hfsplus/inode.c| 3 +-- fs/hpfs/inode.c | 3 +-- fs/hpfs/namei.c | 12 fs/hugetlbfs/inode.c | 3 +-- fs/inode.c| 7 +++ fs/isofs/inode.c | 3 +-- fs/isofs/rock.c | 3 +-- fs/ncpfs/inode.c | 3 +-- fs/nfs/inode.c| 4 ++-- fs/ntfs/inode.c | 12 fs/ntfs/mft.c | 3 +-- fs/ntfs/super.c | 3 +-- fs/ocfs2/refcounttree.c | 3 +-- fs/omfs/inode.c | 3 +-- fs/pipe.c | 3 +-- fs/proc/base.c| 15 +-- fs/proc/fd.c | 8 fs/proc/inode.c | 3 +-- fs/proc/self.c| 3 +-- fs/stack.c| 3 +-- fs/sysfs/inode.c | 3 +-- fs/xfs/xfs_iops.c | 4 ++-- include/linux/fs.h| 1 + ipc/mqueue.c | 3 +-- kernel/cgroup.c | 3 +-- mm/shmem.c| 3 +-- net/socket.c | 3 +-- 53 files changed, 94 insertions(+), 142 deletions(-) -- 1.8.2.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] fs: use inode_set_user to set uid/gid of inode
Use the new interface to set i_uid/i_gid in inode struct. Signed-off-by: Rui Xiang rui.xi...@huawei.com --- arch/ia64/kernel/perfmon.c| 3 +-- arch/powerpc/platforms/cell/spufs/inode.c | 3 +-- arch/s390/hypfs/inode.c | 3 +-- drivers/infiniband/hw/qib/qib_fs.c| 3 +-- drivers/usb/gadget/f_fs.c | 3 +-- drivers/usb/gadget/inode.c| 5 +++-- fs/9p/vfs_inode.c | 6 ++ fs/adfs/inode.c | 3 +-- fs/affs/inode.c | 6 ++ fs/afs/inode.c| 6 ++ fs/anon_inodes.c | 3 +-- fs/autofs4/inode.c| 4 ++-- fs/befs/linuxvfs.c| 8 fs/ceph/caps.c| 5 +++-- fs/ceph/inode.c | 8 fs/cifs/inode.c | 6 ++ fs/configfs/inode.c | 3 +-- fs/debugfs/inode.c| 3 +-- fs/devpts/inode.c | 7 +++ fs/ext2/ialloc.c | 3 +-- fs/ext3/ialloc.c | 3 +-- fs/ext4/ialloc.c | 3 +-- fs/fat/inode.c| 6 ++ fs/fuse/control.c | 3 +-- fs/fuse/inode.c | 4 ++-- fs/hfs/inode.c| 6 ++ fs/hfsplus/inode.c| 3 +-- fs/hpfs/inode.c | 3 +-- fs/hpfs/namei.c | 12 fs/hugetlbfs/inode.c | 3 +-- fs/isofs/inode.c | 3 +-- fs/isofs/rock.c | 3 +-- fs/ncpfs/inode.c | 3 +-- fs/nfs/inode.c| 4 ++-- fs/ntfs/inode.c | 12 fs/ntfs/mft.c | 3 +-- fs/ntfs/super.c | 3 +-- fs/ocfs2/refcounttree.c | 3 +-- fs/omfs/inode.c | 3 +-- fs/pipe.c | 3 +-- fs/proc/base.c| 15 +-- fs/proc/fd.c | 8 fs/proc/inode.c | 3 +-- fs/proc/self.c| 3 +-- fs/stack.c| 3 +-- fs/sysfs/inode.c | 3 +-- fs/xfs/xfs_iops.c | 4 ++-- ipc/mqueue.c | 3 +-- kernel/cgroup.c | 3 +-- mm/shmem.c| 3 +-- net/socket.c | 3 +-- 51 files changed, 86 insertions(+), 142 deletions(-) diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c index 5a9ff1c..73e1e55 100644 --- a/arch/ia64/kernel/perfmon.c +++ b/arch/ia64/kernel/perfmon.c @@ -2202,8 +2202,7 @@ pfm_alloc_file(pfm_context_t *ctx) DPRINT((new inode ino=%ld @%p\n, inode-i_ino, inode)); inode-i_mode = S_IFCHR|S_IRUGO; - inode-i_uid = current_fsuid(); - inode-i_gid = current_fsgid(); + inode_set_user(inode, current_fsuid(), current_fsgid()); /* * allocate a new dcache entry diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c index 87ba7cf..4580c9b 100644 --- a/arch/powerpc/platforms/cell/spufs/inode.c +++ b/arch/powerpc/platforms/cell/spufs/inode.c @@ -101,8 +101,7 @@ spufs_new_inode(struct super_block *sb, umode_t mode) inode-i_ino = get_next_ino(); inode-i_mode = mode; - inode-i_uid = current_fsuid(); - inode-i_gid = current_fsgid(); + inode_set_user(inode, current_fsuid(), current_fsgid()); inode-i_atime = inode-i_mtime = inode-i_ctime = CURRENT_TIME; out: return inode; diff --git a/arch/s390/hypfs/inode.c b/arch/s390/hypfs/inode.c index 7a539f4..742e430 100644 --- a/arch/s390/hypfs/inode.c +++ b/arch/s390/hypfs/inode.c @@ -103,8 +103,7 @@ static struct inode *hypfs_make_inode(struct super_block *sb, umode_t mode) struct hypfs_sb_info *hypfs_info = sb-s_fs_info; ret-i_ino = get_next_ino(); ret-i_mode = mode; - ret-i_uid = hypfs_info-uid; - ret-i_gid = hypfs_info-gid; + inode_set_user(ret, hypfs_info-uid, hypfs_info-gid); ret-i_atime = ret-i_mtime = ret-i_ctime = CURRENT_TIME; if (S_ISDIR(mode)) set_nlink(ret, 2); diff --git a/drivers/infiniband/hw/qib/qib_fs.c b/drivers/infiniband/hw/qib/qib_fs.c index f247fc6e..6683837 100644 --- a/drivers/infiniband/hw/qib/qib_fs.c +++ b/drivers/infiniband/hw/qib/qib_fs.c @@ -61,13 +61,12 @@ static int qibfs_mknod(struct inode *dir, struct
Re: [PATCH 0/2] fs: supply inode uid/gid setting interface
On 2013/8/23 12:10, Greg KH wrote: On Fri, Aug 23, 2013 at 10:48:36AM +0800, Rui Xiang wrote: This patchset implements an accessor functions to set uid/gid in inode struct. Just finish code clean up. Why? It can introduce a new function to reduce some codes. Just clean up. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ppc64: remove __volatile__ in get_current()
On Sat, 10 Aug 2013, James Yang wrote:
Uses of get_current() that normally get optimized away still result in
a load instruction of the current pointer in 64-bit because the inline
asm uses __volatile__. This patch removes __volatile__ so that nop-ed
uses of get_current() don't actually result in a load of the pointer.
Signed-off-by: James Yang james.y...@freescale.com
---
arch/powerpc/include/asm/current.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/current.h
b/arch/powerpc/include/asm/current.h
index e2c7f06..bb250c8 100644
--- a/arch/powerpc/include/asm/current.h
+++ b/arch/powerpc/include/asm/current.h
@@ -19,7 +19,7 @@ static inline struct task_struct *get_current(void)
{
struct task_struct *task;
- __asm__ __volatile__(ld %0,%1(13)
+ __asm__ (ld %0,%1(13)
: =r (task)
: i (offsetof(struct paca_struct, __current)));
Hello,
Scott's been able to put enough doubt in me to think that this is not
entirely safe, even though the testing and code generation show it to
work. Please reject this patch.
I think there is still value in getting the unnecessary loads to be
removed since it would also allow unnecessary conditional branches to
be removed. I'll think about alternate ways to do this.
Regards,
--James
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
Scott Wood scottw...@freescale.com writes: --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt This should go in Documentation/devicetree/bindings/ata/fsl-sata.txt. Ok, will change. As for the property name, I'd prefer fsl,sata-speed-limit or fsl,sata-max-generation. In my original patch: http://article.gmane.org/gmane.linux.ports.ppc.embedded/58710 I used fsl,sata-max-gen. I thought Jeff disliked it, so I changed it be more generic -- but maybe I misread his complaint. (And while his opinions are still respected, new maintainers might have different tastes.) I think my logic was that there exist sata_spd_limit and related functions in the ata core, so I should mirror that in the dev tree. No guarantees, though -- it's been a while since I wrote that code. Shaohui, do the driver bits look OK? This patch should go via the linux-scsi list (note that Tejun Heo is now the SATA maintainer). linux-scsi, or linux-ide? My other recent change to sata_fsl went through the latter. Thanks for the review / comments. Let me know how you'd like to proceed on the above points, and I can resubmit (as a proper patch for easier tracking). Best regards, Anthony Foiani ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
On Fri, 2013-08-23 at 17:41 -0600, Anthony Foiani wrote: Scott Wood scottw...@freescale.com writes: --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt This should go in Documentation/devicetree/bindings/ata/fsl-sata.txt. Ok, will change. As for the property name, I'd prefer fsl,sata-speed-limit or fsl,sata-max-generation. In my original patch: http://article.gmane.org/gmane.linux.ports.ppc.embedded/58710 I used fsl,sata-max-gen. I thought Jeff disliked it, so I changed it be more generic -- but maybe I misread his complaint. (And while his opinions are still respected, new maintainers might have different tastes.) I didn't see anything to that effect from Jeff in that thread -- maybe it was elsewhere. I think my logic was that there exist sata_spd_limit and related functions in the ata core, so I should mirror that in the dev tree. No guarantees, though -- it's been a while since I wrote that code. The device tree describes the hardware, not the driver -- and thus should be free to use clearer wording. :-) As for fsl-specific versus generic, generic is fine but then it needs to be documented in a generic place. Shaohui, do the driver bits look OK? This patch should go via the linux-scsi list (note that Tejun Heo is now the SATA maintainer). linux-scsi, or linux-ide? My other recent change to sata_fsl went through the latter. Sorry, linux-ide. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ppc64: remove __volatile__ in get_current()
On Fri, 2013-08-23 at 18:40 -0500, James Yang wrote:
On Sat, 10 Aug 2013, James Yang wrote:
Uses of get_current() that normally get optimized away still result in
a load instruction of the current pointer in 64-bit because the inline
asm uses __volatile__. This patch removes __volatile__ so that nop-ed
uses of get_current() don't actually result in a load of the pointer.
Signed-off-by: James Yang james.y...@freescale.com
---
arch/powerpc/include/asm/current.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/current.h
b/arch/powerpc/include/asm/current.h
index e2c7f06..bb250c8 100644
--- a/arch/powerpc/include/asm/current.h
+++ b/arch/powerpc/include/asm/current.h
@@ -19,7 +19,7 @@ static inline struct task_struct *get_current(void)
{
struct task_struct *task;
- __asm__ __volatile__(ld %0,%1(13)
+ __asm__ (ld %0,%1(13)
: =r (task)
: i (offsetof(struct paca_struct, __current)));
Hello,
Scott's been able to put enough doubt in me to think that this is not
entirely safe, even though the testing and code generation show it to
work. Please reject this patch.
I think there is still value in getting the unnecessary loads to be
removed since it would also allow unnecessary conditional branches to
be removed. I'll think about alternate ways to do this.
Actually, I changed my mind in the other direction in parallel. :-P
I think it's probably safe.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] powerpc/85xx: Add P1023RDB board support
On Tue, Jul 30, 2013 at 07:40:29PM +0800, Chunhe Lan wrote:
P1023RDB Specification:
---
Memory subsystem:
512MB DDR3 (Fixed DDR on board)
64MB NOR flash
128MB NAND flash
Ethernet:
eTSEC1: Connected to Atheros AR8035 GETH PHY
eTSEC2: Connected to Atheros AR8035 GETH PHY
PCIe:
Three mini-PCIe slots
USB:
Two USB2.0 Type A ports
I2C:
AT24C08 8K Board EEPROM (8 bit address)
Signed-off-by: Chunhe Lan chunhe@freescale.com
Cc: Scott Wood scottw...@freescale.com
---
No changelog since v1...
+ nor@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x0400;
+ bank-width = 2;
+ device-width = 1;
+
+ partition@0 {
+ /* 48MB for JFFS2 based Root file System */
+ reg = 0x 0x0300;
+ label = NOR JFFS2 Root File System;
+ };
Don't specify JFFS2.
+ partition@100 {
+ /* 32MB for Compressed Root file System Image */
+ reg = 0x0100 0x0200;
+ label = NAND Compressed RFS Image;
+ };
+
+ partition@300 {
+ /* 64MB for JFFS2 based Root file System */
+ reg = 0x0300 0x0400;
+ label = NAND JFFS2 Root File System;
+ };
+
+ partition@700 {
+ /* 16MB for User Writable Area */
+ reg = 0x0700 0x0100;
+ label = NAND Writable User area;
+ };
Don't specify JFFS2.
Why three separate partitions instead of one? At least the two RFS
partitions should be merged.
+ board_pci1: pci1: pcie@ff609000 {
You don't need more than one label on a node.
diff --git a/arch/powerpc/configs/85xx/p1023_defconfig
b/arch/powerpc/configs/85xx/p1023_defconfig
new file mode 100644
index 000..ac29fb8
--- /dev/null
+++ b/arch/powerpc/configs/85xx/p1023_defconfig
While I can understand p1023 wanting a separate defconfig once we get
datapath support (it's the only e500v2 chip with datapath, so we probably
don't want to burden mpc85xx_smp_defconfig with it), but I don't see why
we need a separate config right now.
+# CONFIG_DEBUG_BUGVERBOSE is not set
Please don't disable this. It's very useful for interpreting bug reports
and has minimal cost.
diff --git a/arch/powerpc/configs/85xx/p1023rds_defconfig
b/arch/powerpc/configs/85xx/p1023rds_defconfig
deleted file mode 100644
index b80bcc6..000
--- a/arch/powerpc/configs/85xx/p1023rds_defconfig
+++ /dev/null
@@ -1,169 +0,0 @@
-CONFIG_PPC_85xx=y
-CONFIG_SMP=y
-CONFIG_NR_CPUS=2
Oh, you were just moving this. Please use -M -C with git format-patch
so such things are more obvious.
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index efdd37c..d6424e9 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -112,10 +112,10 @@ config P1022_RDK
reference board.
config P1023_RDS
- bool Freescale P1023 RDS
+ bool Freescale P1023 RDS (P1023 RDB)
select DEFAULT_UIMAGE
help
- This option enables support for the P1023 RDS board
+ This option enables support for the P1023 RDS (P1023 RDB) board
config SOCRATES
bool Socrates
I'd just say P1023 RDS/RDB.
+static int __init p1023_rdb_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, fsl,P1023RDB);
+
+}
Remove the blank line at the end of the function.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] powerpc/85xx: Add P1023RDB board support
On Fri, 2013-08-23 at 19:09 -0500, Scott Wood wrote: On Tue, Jul 30, 2013 at 07:40:29PM +0800, Chunhe Lan wrote: P1023RDB Specification: --- Memory subsystem: 512MB DDR3 (Fixed DDR on board) 64MB NOR flash 128MB NAND flash Ethernet: eTSEC1: Connected to Atheros AR8035 GETH PHY eTSEC2: Connected to Atheros AR8035 GETH PHY PCIe: Three mini-PCIe slots USB: Two USB2.0 Type A ports I2C: AT24C08 8K Board EEPROM (8 bit address) Signed-off-by: Chunhe Lan chunhe@freescale.com Cc: Scott Wood scottw...@freescale.com --- No changelog since v1... Sigh, and now I see there was a v3 right after this that addressed most of these issues. :-P -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ppc64: remove __volatile__ in get_current()
On Fri, 2013-08-23 at 18:40 -0500, James Yang wrote: Scott's been able to put enough doubt in me to think that this is not entirely safe, even though the testing and code generation show it to work. Please reject this patch. I think there is still value in getting the unnecessary loads to be removed since it would also allow unnecessary conditional branches to be removed. I'll think about alternate ways to do this. Hrm, The problem has to do with PACA accesses moving around accross preempt boundaries, it's a bit tricky, but in the case of current shouldn't be a problem... while the rest of the PACA might change (CPU# etc...) current remains stable for the point of view of a given thread. So I think the patch is fine. Scott ? Now, we do need some serious rework of PACA accesses. I'm very *VERY* nervous with what we have now. A bit of grepping shows dozens of cases where gcc copies r13 into another register or even saves/restores it, it scares the shit out of me :-) My thinking is to make r13 a hidden reg like we do (or used to) on ppc32 with r2 and break down paca access into two forms: - Direct access of a single field - asm loads/stores inline - Anything else, uses a get_paca/put_paca construct that includes a preempt_disable/enable (and maybe along with a __get_paca/__put_paca pair that doesn't). This basically does a mr of r13 into another register and basically hides the whole lot from gcc. The former would be used for single fields, the latter, while adding a potentially unnecessary mr, will be much safer vs. gcc playing games with r13. Any volunteer ? Haven't had time to do it myself so far :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Fri, Aug 23, 2013 at 02:41:44PM -0700, Mike Turquette wrote: Seems like the regulator framework is solving this with the new regulator_get_optional() call. This leaves the optional-versus-not-optional logic up to the driver. That is possibly for a slightly different case but perhaps not... The problem we've got with the regulator API is that an awful lot of regulators are always on and people generally don't want to go and hook everything up, especially when drivers don't yet have regulator support. This means that we end up with lots of complaints about having to add regultors and lots of pain adding regulator support to widely used devices, or drivers that just ignore errors which is not awesome. We don't want to provide dummies since if the driver genuinely does have optional regulators they tend to break them so we're adding that call to allow the core to know if it can just provide a stub and assume the board data was lazy. My impression with clocks on most platforms is that there are fewer of this sort of always on clock, though that said I know there has been a bit of an issue with some of the IP clocks when IPs are used in SoCs from less power sensitive environments that don't bother implementing gating even in hardware. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ppc64: remove __volatile__ in get_current()
On Fri, 2013-08-23 at 18:48 -0500, Scott Wood wrote: Actually, I changed my mind in the other direction in parallel. :-P I think it's probably safe. Yes, I think it is as well ... but only because current is special and whatever the r13 for the thread is, r13-current will always be the same value for that thread :-) Note: That would NOT work if we used a C construct such as local_paca-current, because in that case, gcc might be stupid enough to *copy* r13 to another reg, and later on dereference using that other reg. At that point, the paca pointer itself might become stale when used. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Pull request: scottwood/linux.git next
The following changes since commit afbcdd97bf117bc2d01b865a32f78f662437a4d8:
powerpc/wsp: Fix early debug build (2013-08-16 10:59:27 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to 622e03eb3498c32ee29de5c1d6d381f443e58fad:
powerpc/85xx: Add C293PCIE board support (2013-08-23 19:43:24 -0500)
Chunhe Lan (1):
powerpc/85xx: Add P1023RDB board support
Haijun.Zhang (1):
powerpc/85xx: Add support for 85xx cpu type detection
Mingkai Hu (3):
powerpc/85xx: Add SEC6.0 device tree
powerpc/85xx: Add silicon device tree for C293
powerpc/85xx: Add C293PCIE board support
Scott Wood (5):
powerpc/fsl-booke: Work around erratum A-006958
powerpc: Convert some mftb/mftbu into mfspr
powerpc/85xx: Remove -Wa,-me500
powerpc/booke64: Use appropriate -mcpu
powerpc/e500: Set -mcpu flag for 32-bit e500
Wang Dongsheng (1):
powerpc: add Book E support to 64-bit hibernation
.../devicetree/bindings/crypto/fsl-sec6.txt| 157 ++
arch/powerpc/Makefile | 18 +-
arch/powerpc/boot/dts/c293pcie.dts | 223
arch/powerpc/boot/dts/fsl/c293si-post.dtsi | 193 +
arch/powerpc/boot/dts/fsl/c293si-pre.dtsi | 63 ++
arch/powerpc/boot/dts/fsl/qoriq-sec6.0-0.dtsi | 56 +
arch/powerpc/boot/dts/p1023rdb.dts | 234 +
arch/powerpc/boot/ppc_asm.h| 3 +
arch/powerpc/boot/util.S | 10 +-
.../85xx/{p1023rds_defconfig = p1023_defconfig} | 24 ++-
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
arch/powerpc/include/asm/cputable.h| 9 +-
arch/powerpc/include/asm/mpc85xx.h | 92
arch/powerpc/include/asm/ppc_asm.h | 6 +-
arch/powerpc/include/asm/reg.h | 17 +-
arch/powerpc/include/asm/timex.h | 4 +-
arch/powerpc/kernel/swsusp_asm64.S | 45 +++-
arch/powerpc/kernel/vdso32/gettimeofday.S | 6 +-
arch/powerpc/platforms/85xx/Kconfig| 10 +-
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/c293pcie.c | 75 +++
arch/powerpc/platforms/85xx/p1023_rds.c| 24 ++-
arch/powerpc/platforms/85xx/smp.c | 25 +++
arch/powerpc/platforms/Kconfig.cputype | 13 ++
25 files changed, 1280 insertions(+), 30 deletions(-)
create mode 100644 Documentation/devicetree/bindings/crypto/fsl-sec6.txt
create mode 100644 arch/powerpc/boot/dts/c293pcie.dts
create mode 100644 arch/powerpc/boot/dts/fsl/c293si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/c293si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sec6.0-0.dtsi
create mode 100644 arch/powerpc/boot/dts/p1023rdb.dts
rename arch/powerpc/configs/85xx/{p1023rds_defconfig = p1023_defconfig} (88%)
create mode 100644 arch/powerpc/include/asm/mpc85xx.h
create mode 100644 arch/powerpc/platforms/85xx/c293pcie.c
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
