* [PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8
From: Hanjun Guo @ 2016-10-18 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475875882-2604-6-git-send-email-tbaicar@codeaurora.org>
Hi Tyler,
On 2016/10/8 5:31, Tyler Baicar wrote:
> ARM APEI extension proposal added SEA (Synchrounous External
> Abort) notification type for ARMv8.
> Add a new GHES error source handling function for SEA. If an error
> source's notification type is SEA, then this function can be registered
> into the SEA exception handler. That way GHES will parse and report
> SEA exceptions when they occur.
Does this SEA is replayed by the firmware (firmware first handling)
or directly triggered by the hardware when error is happened?
Thanks
Hanjun
^ permalink raw reply
* [PATCH v2 6/9] dt-bindings: pinctrl: Deprecate sunxi pinctrl bindings
From: Rob Herring @ 2016-10-18 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ee6d214a14ed31689c5f70fc6ee5736c3d26737b.1476200742.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 11, 2016 at 05:46:04PM +0200, Maxime Ripard wrote:
> The generic pin configuration and multiplexing should be preferred now,
> even though we still support the old one.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+), 0 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 01/10] mm: remove write/force parameters from __get_user_pages_locked()
From: Jan Kara @ 2016-10-18 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013002020.3062-2-lstoakes@gmail.com>
On Thu 13-10-16 01:20:11, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from __get_user_pages_locked()
> to make the use of FOLL_FORCE explicit in callers as use of this flag can result
> in surprising behaviour (and hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Looks good. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-10-18 12:34 UTC (permalink / raw)
To: linux-arm-kernel
From: LABBE Corentin <clabbe.montjoie@gmail.com>
The Security System have a PRNG.
This patch add support for it as an hwrng.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/Kconfig | 8 ++++
drivers/crypto/sunxi-ss/Makefile | 1 +
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 14 +++++++
drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c | 70 ++++++++++++++++++++++++++++++++
drivers/crypto/sunxi-ss/sun4i-ss.h | 8 ++++
5 files changed, 101 insertions(+)
create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4d2b81f..38f7aca 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -538,6 +538,14 @@ config CRYPTO_DEV_SUN4I_SS
To compile this driver as a module, choose M here: the module
will be called sun4i-ss.
+config CRYPTO_DEV_SUN4I_SS_PRNG
+ bool "Support for Allwinner Security System PRNG"
+ depends on CRYPTO_DEV_SUN4I_SS
+ select HW_RANDOM
+ help
+ This driver provides kernel-side support for the Pseudo-Random
+ Number Generator found in the Security System.
+
config CRYPTO_DEV_ROCKCHIP
tristate "Rockchip's Cryptographic Engine driver"
depends on OF && ARCH_ROCKCHIP
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
index 8f4c7a2..ca049ee 100644
--- a/drivers/crypto/sunxi-ss/Makefile
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sun4i-ss.o
sun4i-ss-y += sun4i-ss-core.o sun4i-ss-hash.o sun4i-ss-cipher.o
+sun4i-ss-$(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) += sun4i-ss-hwrng.o
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 3ac6c6c..fa739de 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -359,6 +359,16 @@ static int sun4i_ss_probe(struct platform_device *pdev)
}
}
platform_set_drvdata(pdev, ss);
+
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+ /* Voluntarily made the PRNG optional */
+ err = sun4i_ss_hwrng_register(&ss->hwrng);
+ if (!err)
+ dev_info(ss->dev, "sun4i-ss PRNG loaded");
+ else
+ dev_err(ss->dev, "sun4i-ss PRNG failed");
+#endif
+
return 0;
error_alg:
i--;
@@ -386,6 +396,10 @@ static int sun4i_ss_remove(struct platform_device *pdev)
int i;
struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+ sun4i_ss_hwrng_remove(&ss->hwrng);
+#endif
+
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
switch (ss_algs[i].type) {
case CRYPTO_ALG_TYPE_ABLKCIPHER:
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
new file mode 100644
index 0000000..95fadb7
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
@@ -0,0 +1,70 @@
+#include "sun4i-ss.h"
+
+static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
+{
+ struct sun4i_ss_ctx *ss;
+
+ ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+ get_random_bytes(ss->seed, SS_SEED_LEN);
+
+ return 0;
+}
+
+static int sun4i_ss_hwrng_read(struct hwrng *hwrng, void *buf,
+ size_t max, bool wait)
+{
+ int i;
+ u32 v;
+ u32 *data = buf;
+ const u32 mode = SS_OP_PRNG | SS_PRNG_CONTINUE | SS_ENABLED;
+ size_t len;
+ struct sun4i_ss_ctx *ss;
+
+ ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+ len = min_t(size_t, SS_DATA_LEN, max);
+
+ spin_lock_bh(&ss->slock);
+
+ writel(mode, ss->base + SS_CTL);
+
+ /* write the seed */
+ for (i = 0; i < SS_SEED_LEN / 4; i++)
+ writel(ss->seed[i], ss->base + SS_KEY0 + i * 4);
+ writel(mode | SS_PRNG_START, ss->base + SS_CTL);
+
+ /* Read the random data */
+ readsl(ss->base + SS_TXFIFO, data, len / 4);
+
+ if (len % 4 > 0) {
+ v = readl(ss->base + SS_TXFIFO);
+ memcpy(data + len / 4, &v, len % 4);
+ }
+
+ /* Update the seed */
+ for (i = 0; i < SS_SEED_LEN / 4; i++) {
+ v = readl(ss->base + SS_KEY0 + i * 4);
+ ss->seed[i] = v;
+ }
+
+ writel(0, ss->base + SS_CTL);
+ spin_unlock_bh(&ss->slock);
+ return len;
+}
+
+int sun4i_ss_hwrng_register(struct hwrng *hwrng)
+{
+ hwrng->name = "sun4i Security System PRNG";
+ hwrng->init = sun4i_ss_hwrng_init;
+ hwrng->read = sun4i_ss_hwrng_read;
+ hwrng->quality = 1000;
+
+ /* Cannot use devm_hwrng_register() since we need to hwrng_unregister
+ * before stopping clocks/regulator
+ */
+ return hwrng_register(hwrng);
+}
+
+void sun4i_ss_hwrng_remove(struct hwrng *hwrng)
+{
+ hwrng_unregister(hwrng);
+}
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss.h b/drivers/crypto/sunxi-ss/sun4i-ss.h
index f04c0f8..1297510 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss.h
+++ b/drivers/crypto/sunxi-ss/sun4i-ss.h
@@ -23,6 +23,7 @@
#include <linux/scatterlist.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/hw_random.h>
#include <crypto/md5.h>
#include <crypto/sha.h>
#include <crypto/hash.h>
@@ -125,6 +126,9 @@
#define SS_RXFIFO_EMP_INT_ENABLE (1 << 2)
#define SS_TXFIFO_AVA_INT_ENABLE (1 << 0)
+#define SS_SEED_LEN (192 / 8)
+#define SS_DATA_LEN (160 / 8)
+
struct sun4i_ss_ctx {
void __iomem *base;
int irq;
@@ -134,6 +138,8 @@ struct sun4i_ss_ctx {
struct device *dev;
struct resource *res;
spinlock_t slock; /* control the use of the device */
+ struct hwrng hwrng;
+ u32 seed[SS_SEED_LEN / 4];
};
struct sun4i_ss_alg_template {
@@ -199,3 +205,5 @@ int sun4i_ss_des_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
unsigned int keylen);
int sun4i_ss_des3_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
unsigned int keylen);
+int sun4i_ss_hwrng_register(struct hwrng *hwrng);
+void sun4i_ss_hwrng_remove(struct hwrng *hwrng);
--
2.7.3
^ permalink raw reply related
* [PATCH v4 3/9] drm/hisilicon/hibmc: Add support for frame buffer
From: Daniel Vetter @ 2016-10-18 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58060529.5010708@huawei.com>
On Tue, Oct 18, 2016 at 07:19:05PM +0800, Rongrong Zou wrote:
> Hi Daniel,
>
> Thanks for your review!
>
> ? 2016/10/18 15:49, Daniel Vetter ??:
> > On Tue, Oct 18, 2016 at 12:01:18PM +0800, Rongrong Zou wrote:
> > > Add support for fbdev and framebuffer.
> > >
> > > Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> > > ---
> > > drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
> > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 25 +++
> > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 25 +++
> > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 257 ++++++++++++++++++++++
> > > drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 67 ++++++
> > > 5 files changed, 375 insertions(+), 1 deletion(-)
> > > create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
> > >
> > > diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile b/drivers/gpu/drm/hisilicon/hibmc/Makefile
> > > index d5c40b8..810a37e 100644
> > > --- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
> > > +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
> > > @@ -1,5 +1,5 @@
> > > ccflags-y := -Iinclude/drm
> > > -hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_power.o hibmc_ttm.o
> > > +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_fbdev.o hibmc_drm_power.o hibmc_ttm.o
> > >
> > > obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
> > > #obj-y += hibmc-drm.o
> > > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> > > index e118f3b..8ddb763 100644
> > > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> > > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> > > @@ -66,11 +66,31 @@ static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
> > >
> > > static int hibmc_pm_suspend(struct device *dev)
> > > {
> > > + struct pci_dev *pdev = to_pci_dev(dev);
> > > + struct drm_device *drm_dev = pci_get_drvdata(pdev);
> > > + struct hibmc_drm_device *hidev = drm_dev->dev_private;
> > > +
> > > + if (hidev->fbdev.initialized) {
> >
> > What do you need these checks for? This looks a bit fishy tbh ...
>
> It is delivered from the bochs driver, and I will fix if there are
> any problems, Thanks.
Yeah, existing drivers aren't up to latest best practices. Not sure why
that was added to bochs really ...
>
> >
> > > + console_lock();
> > > + drm_fb_helper_set_suspend(&hidev->fbdev.helper, 1);
> > > + console_unlock();
> >
> > drm_fb_helper_set_suspend_unlocked is the new fancy one. Please use that
> > one instead. Also, that has the check you might need already included,
> > which means you can nuke this entire function here and just call it
> > directly.
>
> So it should be wrote as:
> static int hibmc_pm_suspend(struct device *dev)
> {
> ...
> drm_kms_helper_poll_disable(drm_dev);
> drm_fb_helper_set_suspend_unlocked(&hidev->fbdev.helper, 1);
> ...
> }
>
> static int hibmc_pm_resume(struct device *dev)
> {
> ...
> drm_helper_resume_force_mode(drm_dev);
> drm_fb_helper_set_suspend_unlocked(&hidev->fbdev.helper, 0);
> drm_kms_helper_poll_enable(drm_dev);
> ...
> }, is it ?
Yup.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
From: Michael Niewöhner @ 2016-10-18 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4d744ae-d043-b652-3073-f29ebe76f865@codeaurora.org>
Hi,
On Mon, 2016-10-17 at 15:21 +0530, Vivek Gautam wrote:
>
> On 10/17/2016 01:38 PM, Felipe Balbi wrote:
> > Hi,
> >
> > Michael Niew?hner <linux@mniewoehner.de> writes:
> > > Hi Felipe,
> > > On Fri, 2016-10-07 at 22:26 +0200, Michael Niew?hner wrote:
> > > > Hi Felipe,
> > > >
> > > > On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote:
> > > > > Hi,
> > > > >
> > > > > Michael Niew?hner <linux@mniewoehner.de> writes:
> > > > > > > The clocks are same across working/non-working.
> > > > > > > Is it possible to bisect the commit that's causing hang for 4.8x ?
> > > > > >
> > > > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init and exit paths
> > > > > > This patch causes both the hang on reboot and the lsusb hang.
> > > > >
> > > > > How to reproduce? Why don't we see this on x86 and TI boards? I'm
> > > > > guessing this is failed bisection, as I can't see anything in that
> > > > > commit that would cause reboot hang. Also, that code path is *NOT*
> > > > > executed when you run lsusb.
> > > > >
> > > >
> > > > I've tested this procedure multiple times to be sure:
> > > >
> > > > - checkout c499ff71, compile, boot the odroid
> > > > - run lsusb -v => lsusb hangs, can't terminate with ctrl-c
> > > > - hard reset, after boot run poweroff or reboot => board does not completely power off / reboot (see log below)
> > > > - revert c499ff71, mrproper, compile, boot the odroid
> > > > - run lsusb -v => shows full output, not hanging
> > > > - run reboot or poweroff => board powers off / reboots just fine
> > > >
> > > >
> > > > dmesg poweroff not working:
> > > > ...
> > > > [??120.733519] systemd-journald[144]: systemd-journald stopped as pid 144
> > > > [??120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
> > > > [??120.769212] systemd-shutdown[1]: Unmounting file systems.
> > > > [??120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.
> > > > [??120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.
> > > > [??121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.101014] systemd-shutdown[1]: All filesystems unmounted.
> > > > [??121.106523] systemd-shutdown[1]: Deactivating swaps.
> > > > [??121.111585] systemd-shutdown[1]: All swaps deactivated.
> > > > [??121.116661] systemd-shutdown[1]: Detaching loop devices.
> > > > [??121.126395] systemd-shutdown[1]: All loop devices detached.
> > > > [??121.130525] systemd-shutdown[1]: Detaching DM devices.
> > > > [??121.135824] systemd-shutdown[1]: All DM devices detached.
> > > > [??121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.
> > > > [??121.171739] systemd-shutdown[1]: Powering off.
> > > >
> > > > => at this point removing the sd card would show a message
> > > > "removed mmc0" (not sure what the real message was...) so the board is not completely off.
> > > >
> > > >
> > > > dmesg poweroff working:
> > > > ...
> > > > [??120.733519] systemd-journald[144]: systemd-journald stopped as pid 144
> > > > [??120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
> > > > [??120.769212] systemd-shutdown[1]: Unmounting file systems.
> > > > [??120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.
> > > > [??120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.
> > > > [??121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.101014] systemd-shutdown[1]: All filesystems unmounted.
> > > > [??121.106523] systemd-shutdown[1]: Deactivating swaps.
> > > > [??121.111585] systemd-shutdown[1]: All swaps deactivated.
> > > > [??121.116661] systemd-shutdown[1]: Detaching loop devices.
> > > > [??121.126395] systemd-shutdown[1]: All loop devices detached.
> > > > [??121.130525] systemd-shutdown[1]: Detaching DM devices.
> > > > [??121.135824] systemd-shutdown[1]: All DM devices detached.
> > > > [??121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.
> > > > [??121.171739] systemd-shutdown[1]: Powering off.
> > > > [??121.182331] rebo?
> > > >
> > > >
> > > >
> > > > Best regards
> > > > Michael Niew?hner
> > >
> > > I did some more tests with next-20161016. Reverting / commenting out
> > > one part of your patch "solves" the lsusb hang, the reboot problem
> > > and also the "debounce failed" message. [1]
> > > Another "solution" is to call phy_power_off before phy_power_on. [2]
> > >
> > > Disclaimer: I have no idea what I was doing ;-) These were just some
> > > simple trial-and-error attempts that maybe help to find the real
> > > cause of the problems.
> > >
> > > [1]
> > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > index 7287a76..5ef589d 100644
> > > --- a/drivers/usb/dwc3/core.c
> > > +++ b/drivers/usb/dwc3/core.c
> > > @@ -724,6 +724,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
> > > ?? /* Adjust Frame Length */
> > > ?? dwc3_frame_length_adjustment(dwc);
> > > ??
> > > +/*
> > > ?? usb_phy_set_suspend(dwc->usb2_phy, 0);
> > > ?? usb_phy_set_suspend(dwc->usb3_phy, 0);
> > > ?? ret = phy_power_on(dwc->usb2_generic_phy);
> > > @@ -733,6 +734,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
> > > ?? ret = phy_power_on(dwc->usb3_generic_phy);
> > > ?? if (ret < 0)
> > > ?? goto err3;
> > > +*/
> > > ??
> > > ?? ret = dwc3_event_buffers_setup(dwc);
> > > ?? if (ret) {
> > >
> > > [2]
> > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > index 7287a76..f6c8e13 100644
> > > --- a/drivers/usb/dwc3/core.c
> > > +++ b/drivers/usb/dwc3/core.c
> > > @@ -726,6 +726,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
> > > ??
> > > ?????????usb_phy_set_suspend(dwc->usb2_phy, 0);
> > > ?????????usb_phy_set_suspend(dwc->usb3_phy, 0);
> > > +???????phy_power_off(dwc->usb2_generic_phy);
> > > +???????phy_power_off(dwc->usb3_generic_phy);
> >
> > This looks like a PHY driver bug to me. Which PHY driver are you using?
> >
>
> The exynos5-usbdrd phy driver is used for exynos platforms.
> Looks like something is not right with the phy driver even
> after applying the phy_calibrate patches.
>
> Michael, are you using the last set of patches for phy calibration [1]?
> [1] https://lkml.org/lkml/2015/2/2/257.
yes, I'm using the original LOS level patch.
The phy patch doesn't apply to next, so I use this adapted patch:
https://github.com/c0d3z3r0/linux/commit/8b7a0b2a19e235c308b9082a14ffe73477e2c9ed
>
>
> Thanks
> Vivek
>
Michael
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-18 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018114932.GG10115@e104818-lin.cambridge.arm.com>
On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
>> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
>> currently work, or have ever worked correctly when built for big endian. So this
>> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
>> well, and an additional fix for XTS which escaped my attention before.
>>
>> Each of these patches carries a fixes tag, and could be backported to stable.
>> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
>> fix is compatible with, not the patch that introduced the algorithm.
>
> I think for future reference, the Fixes tag should denote the commit
> that introduced the issue. An explicit Cc: stable tag would state how
> far back it should be applied.
>
OK, that sounds reasonable.
>> Ard Biesheuvel (8):
>> crypto: arm64/aes-ce - fix for big endian
>> crypto: arm64/ghash-ce - fix for big endian
>> crypto: arm64/sha1-ce - fix for big endian
>> crypto: arm64/sha2-ce - fix for big endian
>> crypto: arm64/aes-ccm-ce: fix for big endian
>> crypto: arm64/aes-neon - fix for big endian
>> crypto: arm64/aes-xts-ce: fix for big endian
>> crypto: arm/aes-ce - fix for big endian
>
> The changes look fine to me but I can't claim I fully understand these
> algorithms. FWIW:
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> (Will may pick them up for 4.9-rcX)
Thanks, although I was kind of expecting Herbert to pick these up,
given that #8 affects ARM not arm64.
But if you (or Will) can pick up #1 to #7, that is also fine, then I
can drop #8 into rmk's patch database.
Thanks,
Ard,
^ permalink raw reply
* [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Ziji Hu @ 2016-10-18 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ec7a2658-5af3-bff8-3cb8-adb72406df5c@intel.com>
Hi Adrian,
On 2016/10/17 16:14, Adrian Hunter wrote:
> On 13/10/16 08:38, Ziji Hu wrote:
>> Hi Adrian,
>>
>> On 2016/10/12 21:07, Adrian Hunter wrote:
>>> On 12/10/16 14:58, Ziji Hu wrote:
>>>> Hi Adrian,
>>>>
>>>> Thank you very much for your review.
>>>> I will firstly fix the typo.
>>>>
>>>> On 2016/10/11 20:37, Adrian Hunter wrote:
>> <snip>
>>>>>> +
>>>>>> +static int xenon_start_signal_voltage_switch(struct mmc_host *mmc,
>>>>>> + struct mmc_ios *ios)
>>>>>> +{
>>>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>>>> +
>>>>>> + /*
>>>>>> + * Before SD/SDIO set signal voltage, SD bus clock should be
>>>>>> + * disabled. However, sdhci_set_clock will also disable the Internal
>>>>>> + * clock in mmc_set_signal_voltage().
>>>>>> + * If Internal clock is disabled, the 3.3V/1.8V bit can not be updated.
>>>>>> + * Thus here manually enable internal clock.
>>>>>> + *
>>>>>> + * After switch completes, it is unnecessary to disable internal clock,
>>>>>> + * since keeping internal clock active obeys SD spec.
>>>>>> + */
>>>>>> + enable_xenon_internal_clk(host);
>>>>>> +
>>>>>> + if (priv->card_candidate) {
>>>>>
>>>>> mmc_power_up() calls __mmc_set_signal_voltage() calls
>>>>> host->ops->start_signal_voltage_switch so priv->card_candidate could be an
>>>>> invalid reference to an old card.
>>>>>
>>>>> So that's not going to work if the card changes - not only for removable
>>>>> cards but even for eMMC if init fails and retries.
>>>>>
>>>> As you point out, this piece of code have defects, even though it actually works on Marvell multiple platforms, unless eMMC card is removable.
>>>>
>>>> I can add a property to explicitly indicate eMMC type in DTS.
>>>> Then card_candidate access can be removed here.
>>>> Does it sounds more reasonable to you?
>>>
>>> Sure
>>>
>>>>
>>>>>> + if (mmc_card_mmc(priv->card_candidate))
>>>>>> + return xenon_emmc_signal_voltage_switch(mmc, ios);
>>>>>
>>>>> So if all you need to know is whether it is a eMMC, why can't DT tell you?
>>>>>
>>>> I can add an eMMC type property in DTS, to remove the card_candidate access here.
>>>>
>>>>>> + }
>>>>>> +
>>>>>> + return sdhci_start_signal_voltage_switch(mmc, ios);
>>>>>> +}
>>>>>> +
>>>>>> +/*
>>>>>> + * After determining which slot is used for SDIO,
>>>>>> + * some additional task is required.
>>>>>> + */
>>>>>> +static void xenon_init_card(struct mmc_host *mmc, struct mmc_card *card)
>>>>>> +{
>>>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>>>> + u32 reg;
>>>>>> + u8 slot_idx;
>>>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>>>> +
>>>>>> + /* Link the card for delay adjustment */
>>>>>> + priv->card_candidate = card;
>>>>>
>>>>> You really need a better way to get the card. I suggest you take up the
>>>>> issue with Ulf. One possibility is to have mmc core set host->card = card
>>>>> much earlier.
>>>>>
>>>> Could you please tell me if any issue related to card_candidate still exists, after the card_candidate is removed from xenon_start_signal_voltage_switch() in above?
>>>> It seems that when init_card is called, the structure card has already been updated and stable in MMC/SD/SDIO initialization sequence.
>>>> May I keep it here?
>>>
>>> It works by accident rather than by design. We can do better.
>>>
>> Could you please tell me some details which are satisfied about card_candidate?
>>
>> I must admit that card_candidate in xenon_start_signal_voltage_switch() is imperfect.
>> But card_candidate in init_card() and later in set_ios() work by design, rather than by accident. We did a lot of tests on several platforms.
>>
>> The structure mmc_card passed in here is a stable one. Thus in my very own opinion, it is safe and stable to use mmc_card here.
>> card_candidate is used only in card initialization. It is not active in later transfers after initialization is done.
>> It will always updated with mmc_card in next card initialization.
>
> Ok, so maybe just add some comments and more explanation of how it works.
>
>
Sure. I will add more detailed comments.
>>
>>>>
>>>>>> + /* Set tuning functionality of this slot */
>>>>>> + xenon_slot_tuning_setup(host);
>>>>>> +
>>>>>> + slot_idx = priv->slot_idx;
>>>>>> + if (!mmc_card_sdio(card)) {
>>>>>> + /* Re-enable the Auto-CMD12 cap flag. */
>>>>>> + host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
>>>>>> + host->flags |= SDHCI_AUTO_CMD12;
>>>>>> +
>>>>>> + /* Clear SDIO Card Inserted indication */
>>>>>> + reg = sdhci_readl(host, SDHC_SYS_CFG_INFO);
>>>>>> + reg &= ~(1 << (slot_idx + SLOT_TYPE_SDIO_SHIFT));
>>>>>> + sdhci_writel(host, reg, SDHC_SYS_CFG_INFO);
>>>>>> +
>>>>>> + if (mmc_card_mmc(card)) {
>>>>>> + mmc->caps |= MMC_CAP_NONREMOVABLE;
>>>>>> + if (!(host->quirks2 & SDHCI_QUIRK2_NO_1_8_V))
>>>>>> + mmc->caps |= MMC_CAP_1_8V_DDR;
>>>>>> + /*
>>>>>> + * Force to clear BUS_TEST to
>>>>>> + * skip bus_test_pre and bus_test_post
>>>>>> + */
>>>>>> + mmc->caps &= ~MMC_CAP_BUS_WIDTH_TEST;
>>>>>> + mmc->caps2 |= MMC_CAP2_HC_ERASE_SZ |
>>>>>> + MMC_CAP2_PACKED_CMD;
>>>>>> + if (mmc->caps & MMC_CAP_8_BIT_DATA)
>>>>>> + mmc->caps2 |= MMC_CAP2_HS400_1_8V;
>>>>>> + }
>>>>>> + } else {
>>>>>> + /*
>>>>>> + * Delete the Auto-CMD12 cap flag.
>>>>>> + * Otherwise, when sending multi-block CMD53,
>>>>>> + * Driver will set Transfer Mode Register to enable Auto CMD12.
>>>>>> + * However, SDIO device cannot recognize CMD12.
>>>>>> + * Thus SDHC will time-out for waiting for CMD12 response.
>>>>>> + */
>>>>>> + host->quirks &= ~SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
>>>>>> + host->flags &= ~SDHCI_AUTO_CMD12;
>>>>>
>>>>> sdhci_set_transfer_mode() won't enable auto-CMD12 for CMD53 anyway, so is
>>>>> this needed?
>>>>>
>>>> In Xenon driver, Auto-CMD12 flag is set to enable full support to Auto-CMD feature, both Auto-CMD12 and Auto-CMD23.
>>>> As a result, when Xenon SDHC slot can both support SD and SDIO, Auto-CMD12 is disabled when SDIO card is inserted, and renabled when SD is inserted.
>>>>
>>>> I recheck the sdhci code to set Auto-CMD bit in Transfer Mode register, in sdhci_set_transfer_mode():
>>>> if (mmc_op_multi(cmd->opcode) || data->blocks > 1)
>>>> As you can see, as long as it is CMD18/CMD25 OR there are multiple data blocks, Auto-CMD field will be set.
>>>> CMD53 doesn't have CMD23. Thus Auto-CMD12 is selected since Auto-CMD12 flag is set.
>>>> Thus I have to clear Auto-CMD12 to avoid issuing Auto-CMD12 in SDIO transfer.
>>>
>>>
>>> The code is:
>>>
>>> if (mmc_op_multi(cmd->opcode) || data->blocks > 1) {
>>> mode = SDHCI_TRNS_BLK_CNT_EN | SDHCI_TRNS_MULTI;
>>> /*
>>> * If we are sending CMD23, CMD12 never gets sent
>>> * on successful completion (so no Auto-CMD12).
>>> */
>>> if (sdhci_auto_cmd12(host, cmd->mrq) &&
>>> (cmd->opcode != SD_IO_RW_EXTENDED))
>>> mode |= SDHCI_TRNS_AUTO_CMD12;
>>> else if (cmd->mrq->sbc && (host->flags & SDHCI_AUTO_CMD23)) {
>>> mode |= SDHCI_TRNS_AUTO_CMD23;
>>> sdhci_writel(host, cmd->mrq->sbc->arg, SDHCI_ARGUMENT2);
>>> }
>>> }
>>>
>>> You can see the check for SD_IO_RW_EXTENDED which is CMD53.
>>>
>> Sorry. I didn't notice CMD53 check was added.
>> I introduced this Auto-CMD12 hack since kernel 3.8. It seems that this check is not added in kernel 3.8.
>> Thanks for the information. I will remove the Auto-CMD12 hack.
>>
>>>>
>>>> I just meet a similar issue in RPMB.
>>>> When Auto-CMD12 flag is set, eMMC RPMB access will trigger Auto-CMD12, since CMD25 is in use.
>>>> It will cause RPMB access failed.
>>>
>>> Can you explain more about the RPMB issue. Doesn't it use CMD23, so CMD12
>>> wouldn't be used - auto or manually.
>>>
>> RPMB go through the MMC ioctl routine.
>> Unlike normal data transfer, MMC ioctl for RPMB explicitly issues CMD23. When CMD25 is issued, there is neither data->sbc nor Auto-CMD23.
>> As a result, sdhci driver will automatically enable Auto-CMD12 for RPMB CMD25 if Auto-CMD12 flag is set.
>
> OK, so SDHCI should also not allow auto-cmd12 if there is no stop command
> i.e. data->stop is null.
>
data->stop and cmd->stop are forced to be NULL if Auto-CMD12 is enabled.
Instead, currently I use cmd->arg to check if it is a RPMB CMD25. If CMD25 argument is NULL, it should be RPMB access.
But I only verified it on Marvell platform. Please help check it when later I propose the formal patch.
>>
>>>>
>>>> One possible solution is to drop Auto-CMD12 support and use Auto-CMD23 only, in Xenon driver.
>>>> May I know you opinion, please?
>>>
>>> I don't use auto-CMD12 because I don't know if it provides any benefit and
>>> sdhci does not seem to have implemented Auto CMD12 Error Recovery, although
>>> I have never looked at it closely.
>>>
>> Actually, Auto-CMD23 is always used on our Xenon. Auto-CMD12 is not used at all.
>> But since this driver is a general one for all Marvell products, Auto-CMD12 is also supported in case that Auto-CMD23 is not available.
>>
>>
>
^ permalink raw reply
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Neil Armstrong @ 2016-10-18 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018115115.GF1641@makrotopia.org>
On 10/18/2016 01:51 PM, Daniel Golle wrote:
> Hi Neil,
>
> On Tue, Oct 18, 2016 at 01:24:22PM +0200, Neil Armstrong wrote:
>> On 10/18/2016 01:08 PM, Daniel Golle wrote:
>>> Hi Neil,
>>>
>>> great to see progress towards supporting OX820!
>>> The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
>>> looks very similar, see
>>>
>>> https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c;h=f5a142950e32227fee304de731e619278350a91b;hb=refs/heads/oxnas-nand
>>>
>>> To me therefore this looks quite good, just one small question below.
>>
>> Hi Daniel,
>>
>> Yes, I work step by step, I hope to have something booting for 4.10 !
>>
>> Indeed, they look identical except the part_probes[] stuff, are they necessary ?
>
> Nah, this was dropped around kernel 4.7 from most drivers in favour of
> using the default partition probes (ie. cmdline and dt) afaik.
>
>>
>> My primary source of code was Ma Haiju's tree and OPenWRT's tree, but would some people like to push some of the openwrt driver upstream somehow ?
>
> I was planning this somehow, but lack the resources to seriously move
> forward. I've mostly been focussing on cleaning up Ma Haiju's code and
> improving support for the SATA driver (ie. adding support for both
> ports) and re-factoring the stmmac-based Ethernet driver to match the
> current kernel driver's style.
> However, I'm still using platform-specific includes (hardware.h) and
> thus look forward to rebase SATA and Ethernet support on top of your
> tree, as that would unluck ox820 support in multi-v6 instead of having
> a platform-specific kernel.
I made a fork of the SATA driver for the OX810SE who needs the external DMA
to work since it lacks the SATA-sgdma as used in OX820.
But it seems having Ethernet support would be easy, I can rework it and post it.
Yes, It would be great to sync with the upstream tree at some point, please tell
me how my work could be useful.
I only own a PogoPlug v3 to support the basic OX820, but I will lack hardware to
support PCIe and the dual SATA setup at some point.
The next work I plan to do once the basic OX820 boot is merged is to push the USB,
and the PLL support in the clock driver. The SATA and PCIe would be a natural following work.
>
> Currently there are problems with the NAND driver failing to detect the
> chip on non-PCIe platform like the PogoPlug V3 (non-Pro), MitraStar
> STG-212 and probably other non-PCIe boards which I didn't check yet.
> This magically happened when switching from kernel 4.1 to 4.4, I'm
> bisecting this since, but the problem seems to be hidden somewhere
> between the lines (ie. probe-order-related or such)...
> Did you test your NAND driver on any non-PCIe boards and did it work?
Actually I tested only on non-PCIe, since I only own a PogoPlug v3 (non-pro) and the
probe works perfectly on 4.9-rc1 :
[...]
nand: Could not find valid ONFI parameter page; aborting
nand: device found, Manufacturer ID: 0xad, Chip ID: 0xf1
nand: Hynix NAND 128MiB 3,3V 8-bit
nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
Scanning device for bad blocks
Bad eraseblock 511 at 0x000003fe0000
2 ofpart partitions found on MTD device 41000000.nand
Creating 2 MTD partitions on "41000000.nand":
0x000000000000-0x000000e00000 : "boot"
0x000000e00000-0x000008000000 : "ubi"
[...]
# ubiattach -p /dev/mtd1
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 9, need 19
ubi0: attached mtd1 (name "ubi", size 114 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
ubi0: good PEBs: 911, bad PEBs: 1, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 0
ubi0: available PEBs: 0, total reserved PEBs: 911, PEBs reserved for bad PEB handling: 9
ubi0: background thread "ubi_bgt0d" started, PID 824
UBI device number 0, total 911 LEBs (117540864 bytes, 112.1 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
[...]
>
>
> For a more or less complete history of the changes I made since
> branching of Ma Haijun's tree, see
>
> https://git.lede-project.org/?p=lede/dangole/staging.git;a=history;f=target/linux/oxnas;hb=refs/heads/oxnas-nand
>
> and for the very early history, prior to the merge into the official
> OpenWrt tree, see
>
> http://gitorious.org/openwrt-oxnas/openwrt-oxnas.git
>
Great, thanks for the hints.
I did set up a ML for the upstream work at linux-oxnas at lists.tuxfamily.org and a patchwork interface https://patchwork.kernel.org/project/linux-oxnas/list/ if it can be helpful.
I also idle on #linux-oxnas on freenode...
Neil
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ziji Hu @ 2016-10-18 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <63e2bacf-6ad9-5e20-2c49-e77eb362ccfc@intel.com>
Hi Adrian,
On 2016/10/17 15:55, Adrian Hunter wrote:
> On 12/10/16 15:17, Ziji Hu wrote:
>> Hi Adrian,
>>
>> On 2016/10/11 20:39, Adrian Hunter wrote:
<snip>
>>>> +static int __xenon_emmc_delay_adj_test(struct mmc_card *card)
>>>> +{
>>>> + int err;
>>>> + u8 *ext_csd = NULL;
>>>> +
>>>> + err = mmc_get_ext_csd(card, &ext_csd);
>>>> + kfree(ext_csd);
>>>> +
>>>> + return err;
>>>> +}
>>>> +
>>>> +static int __xenon_sdio_delay_adj_test(struct mmc_card *card)
>>>> +{
>>>> + struct mmc_command cmd = {0};
>>>> + int err;
>>>> +
>>>> + cmd.opcode = SD_IO_RW_DIRECT;
>>>> + cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
>>>> +
>>>> + err = mmc_wait_for_cmd(card->host, &cmd, 0);
>>>> + if (err)
>>>> + return err;
>>>> +
>>>> + if (cmd.resp[0] & R5_ERROR)
>>>> + return -EIO;
>>>> + if (cmd.resp[0] & R5_FUNCTION_NUMBER)
>>>> + return -EINVAL;
>>>> + if (cmd.resp[0] & R5_OUT_OF_RANGE)
>>>> + return -ERANGE;
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int __xenon_sd_delay_adj_test(struct mmc_card *card)
>>>> +{
>>>> + struct mmc_command cmd = {0};
>>>> + int err;
>>>> +
>>>> + cmd.opcode = MMC_SEND_STATUS;
>>>> + cmd.arg = card->rca << 16;
>>>> + cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
>>>> +
>>>> + err = mmc_wait_for_cmd(card->host, &cmd, 0);
>>>> + return err;
>>>> +}
>>>> +
>>>> +static int xenon_delay_adj_test(struct mmc_card *card)
>>>> +{
>>>> + WARN_ON(!card);
>>>> + WARN_ON(!card->host);
>>>> +
>>>> + if (mmc_card_mmc(card))
>>>> + return __xenon_emmc_delay_adj_test(card);
>>>> + else if (mmc_card_sd(card))
>>>> + return __xenon_sd_delay_adj_test(card);
>>>> + else if (mmc_card_sdio(card))
>>>> + return __xenon_sdio_delay_adj_test(card);
>>>> + else
>>>> + return -EINVAL;
>>>> +}
>>>
>>> So you are issuing commands from the ->set_ios() callback. I would want to
>>> get Ulf's OK for that before going further.
>>>
>> Yes, you are correct.
>> In some speed mode, Xenon SDHC has to send a series of transfers to search for a perfect sampling point in PHY delay line.
>> It is like tuning process.
>>
>>> One thing: you will need to ensure you don't trigger get HS400 re-tuning
>>> because it will call back into ->set_ios().
>>>
>> Could you please make the term "HS400 re-tuning" more detailed?
>> In current MMC driver, "HS400 re-tuning" will go back to HS200, execute HS200 tuning and come back to HS400.
>> I'm sure our Xenon SDHC will not execute it.
>
> Currently, re-tuning is automatically enabled whenever tuning is executed,
> and then re-tuning will be done periodically or after CRC errors. The
> function to disable re-tuning mmc_retune_disable() is not exported, however
> if you have you are determining the sampling point your own way, you could
> simply not implement ->execute_tuning() and then there would be no tuning
> and no re-tuning.
>
It is a little complex in our Xenon SDHC.
For the speed mode which requests tuning, such as SDR104 and HS200, our driver will execute standard tuning as spec requires.
However, for those speed mode in which tuning is not requested in spec, our driver has to issues commands to search for the best sampling point.
It seems that HS400 re-tuning/tuning is disabled by default. Is it correct?
>>
>> However, in coming eMMC 5.2, there is a real HS400 re-tuning, in which tuning can be directly executed in HS400 mode.
>> Our Xenon SDHC will neither trigger this HS400 re-tuning.
>> But since so far there is no such feature in MMC driver, I cannot give you a 100% guarantee now.
>>
>>> And you have the problem that you need to get a reference to the card before
>>> the card device has been added. As I wrote in response to the previous
>>> patch, you should get Ulf's help with that too.
>>>
>> Sure.
>> I will get card_candidate solved at first.
>> Thank you again for your review and help.
>>
>> Thank you.
>>
>> Best regards,
>> Hu Ziji
>>>
>>
>
^ permalink raw reply
* [PATCH v7 0/5] ARM: dts: imx6q: Add Engicam i.CoreM6 dts
From: Jagan Teki @ 2016-10-18 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476437243-13297-1-git-send-email-jteki@openedev.com>
Hi Shawn,
On Fri, Oct 14, 2016 at 2:57 PM, Jagan Teki <jteki@openedev.com> wrote:
> This is series add dts support for Engicam I.Core M6 qdl modules. just
> rebased on top of linux-next of previous set[1].
>
> [1] http://www.spinics.net/lists/kernel/msg2358233.html
>
> Jagan Teki (5):
> ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
> ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
> ARM: dts: imx6qdl-icore: Add usbhost support
> ARM: dts: imx6qdl-icore: Add usbotg support
> ARM: dts: imx6qdl-icore: Add FEC support
>
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/imx6dl-icore.dts | 59 ++++++++
> arch/arm/boot/dts/imx6q-icore.dts | 59 ++++++++
> arch/arm/boot/dts/imx6qdl-icore.dtsi | 271 +++++++++++++++++++++++++++++++++++
> 4 files changed, 391 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-icore.dts
> create mode 100644 arch/arm/boot/dts/imx6q-icore.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-icore.dtsi
Can you pick this series?
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Daniel Golle @ 2016-10-18 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c377cb60-a359-62c1-dc6b-7b0be8b8e228@baylibre.com>
Hi Neil,
On Tue, Oct 18, 2016 at 01:24:22PM +0200, Neil Armstrong wrote:
> On 10/18/2016 01:08 PM, Daniel Golle wrote:
> > Hi Neil,
> >
> > great to see progress towards supporting OX820!
> > The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
> > looks very similar, see
> >
> > https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c;h=f5a142950e32227fee304de731e619278350a91b;hb=refs/heads/oxnas-nand
> >
> > To me therefore this looks quite good, just one small question below.
>
> Hi Daniel,
>
> Yes, I work step by step, I hope to have something booting for 4.10 !
>
> Indeed, they look identical except the part_probes[] stuff, are they necessary ?
Nah, this was dropped around kernel 4.7 from most drivers in favour of
using the default partition probes (ie. cmdline and dt) afaik.
>
> My primary source of code was Ma Haiju's tree and OPenWRT's tree, but would some people like to push some of the openwrt driver upstream somehow ?
I was planning this somehow, but lack the resources to seriously move
forward. I've mostly been focussing on cleaning up Ma Haiju's code and
improving support for the SATA driver (ie. adding support for both
ports) and re-factoring the stmmac-based Ethernet driver to match the
current kernel driver's style.
However, I'm still using platform-specific includes (hardware.h) and
thus look forward to rebase SATA and Ethernet support on top of your
tree, as that would unluck ox820 support in multi-v6 instead of having
a platform-specific kernel.
Currently there are problems with the NAND driver failing to detect the
chip on non-PCIe platform like the PogoPlug V3 (non-Pro), MitraStar
STG-212 and probably other non-PCIe boards which I didn't check yet.
This magically happened when switching from kernel 4.1 to 4.4, I'm
bisecting this since, but the problem seems to be hidden somewhere
between the lines (ie. probe-order-related or such)...
Did you test your NAND driver on any non-PCIe boards and did it work?
For a more or less complete history of the changes I made since
branching of Ma Haijun's tree, see
https://git.lede-project.org/?p=lede/dangole/staging.git;a=history;f=target/linux/oxnas;hb=refs/heads/oxnas-nand
and for the very early history, prior to the merge into the official
OpenWrt tree, see
http://gitorious.org/openwrt-oxnas/openwrt-oxnas.git
Cheers
Daniel
>
> Thanks,
> Neil
>
> >
> > Cheers
> >
> > Daniel
> >
> >
> > On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
> >> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
> >> This is a simple memory mapped NAND controller with single chip select and
> >> software ECC.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
> >> drivers/mtd/nand/Kconfig | 5 +
> >> drivers/mtd/nand/Makefile | 1 +
> >> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
> >> 4 files changed, 174 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> >> create mode 100644 drivers/mtd/nand/oxnas_nand.c
> >>
>
> [...]
>
> >> diff --git a/drivers/mtd/nand/oxnas_nand.c b/drivers/mtd/nand/oxnas_nand.c
> >> new file mode 100644
> >> index 0000000..ee402ab
> >> --- /dev/null
> >> +++ b/drivers/mtd/nand/oxnas_nand.c
> >> @@ -0,0 +1,144 @@
> >> +/*
> >> + * Oxford Semiconductor OXNAS NAND driver
> >> + *
> >> + * Heavily based on plat_nand.c :
> >> + * Author: Vitaly Wool <vitalywool@gmail.com>
>
> Hmm, I forgot the OpenWRT and Ma Haijun copyrights here...
>
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + */
> >> +
> >> +#include <linux/err.h>
> >> +#include <linux/io.h>
> >> +#include <linux/module.h>
> >> +#include <linux/platform_device.h>
> >> +#include <linux/slab.h>
> >> +#include <linux/clk.h>
> >> +#include <linux/reset.h>
> >> +#include <linux/mtd/mtd.h>
> >> +#include <linux/mtd/nand.h>
> >> +#include <linux/mtd/partitions.h>
> >> +
> >> +/* nand commands */
> >> +#define NAND_CMD_ALE BIT(18)
> >> +#define NAND_CMD_CLE BIT(19)
> >> +#define NAND_CMD_CS 0
> >> +#define NAND_CMD_RESET 0xff
> >> +#define NAND_CMD (NAND_CMD_CS | NAND_CMD_CLE)
> >> +#define NAND_ADDR (NAND_CMD_CS | NAND_CMD_ALE)
> >> +#define NAND_DATA (NAND_CMD_CS)
> >> +
> >> +struct oxnas_nand_data {
> >> + struct nand_chip chip;
> >> + void __iomem *io_base;
> >
> > Why do you redundantly keep io_base in platform data rather than
> > just using chip.IO_ADDR_R and >chip.IO_ADDR_W?
>
> For no reason since it's not used in oxnas_nand_cmd_ctrl...
> Will remove !
>
> >
> >
> >> + struct clk *clk;
> >> +};
> >> +
> >> +static void oxnas_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
> >> + unsigned int ctrl)
> >> +{
> >> + struct nand_chip *this = mtd->priv;
> >> + unsigned long nandaddr = (unsigned long) this->IO_ADDR_W;
> >> +
> >> + if (ctrl & NAND_CTRL_CHANGE) {
> >> + nandaddr &= ~(NAND_CMD | NAND_ADDR);
> >> + if (ctrl & NAND_CLE)
> >> + nandaddr |= NAND_CMD;
> >> + else if (ctrl & NAND_ALE)
> >> + nandaddr |= NAND_ADDR;
> >> + this->IO_ADDR_W = (void __iomem *) nandaddr;
> >> + }
> >> +
> >> + if (cmd != NAND_CMD_NONE)
> >> + writeb(cmd, (void __iomem *) nandaddr);
> >> +}
> [...]
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Catalin Marinas @ 2016-10-18 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> currently work, or have ever worked correctly when built for big endian. So this
> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> well, and an additional fix for XTS which escaped my attention before.
>
> Each of these patches carries a fixes tag, and could be backported to stable.
> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> fix is compatible with, not the patch that introduced the algorithm.
I think for future reference, the Fixes tag should denote the commit
that introduced the issue. An explicit Cc: stable tag would state how
far back it should be applied.
> Ard Biesheuvel (8):
> crypto: arm64/aes-ce - fix for big endian
> crypto: arm64/ghash-ce - fix for big endian
> crypto: arm64/sha1-ce - fix for big endian
> crypto: arm64/sha2-ce - fix for big endian
> crypto: arm64/aes-ccm-ce: fix for big endian
> crypto: arm64/aes-neon - fix for big endian
> crypto: arm64/aes-xts-ce: fix for big endian
> crypto: arm/aes-ce - fix for big endian
The changes look fine to me but I can't claim I fully understand these
algorithms. FWIW:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
(Will may pick them up for 4.9-rcX)
^ permalink raw reply
* [PATCH v2 4/4] cpufreq: pxa: convert to clock API
From: Viresh Kumar @ 2016-10-18 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476561450-28407-5-git-send-email-robert.jarzmik@free.fr>
On 15-10-16, 21:57, Robert Jarzmik wrote:
> As the clock settings have been introduced into the clock pxa drivers,
> which are now available to change the CPU clock by themselves, remove
> the clock handling from this driver, and rely on pxa clock drivers.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> Since v1: added !OF Kconfig dependency
> ---
> drivers/cpufreq/Kconfig.arm | 2 +-
> drivers/cpufreq/pxa2xx-cpufreq.c | 191 ++++++++-------------------------------
> 2 files changed, 40 insertions(+), 153 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: pxa: add pxa25x cpu operating points
From: Viresh Kumar @ 2016-10-18 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476561450-28407-3-git-send-email-robert.jarzmik@free.fr>
On 15-10-16, 21:57, Robert Jarzmik wrote:
> Add the relevant data taken from the PXA 25x Electrical, Mechanical, and
> Thermal Specfication. This will be input data for cpufreq-dt driver.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> arch/arm/boot/dts/pxa25x.dtsi | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/pxa25x.dtsi b/arch/arm/boot/dts/pxa25x.dtsi
> index 0d1e012178c4..16b4e8bad4a5 100644
> --- a/arch/arm/boot/dts/pxa25x.dtsi
> +++ b/arch/arm/boot/dts/pxa25x.dtsi
> @@ -89,4 +89,29 @@
> clocks = <&clktimer>;
> status = "okay";
> };
> +
> + pxa250_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> +
> + opp at 99500 {
We have been keeping the values in ^^^ same as the values present
below. Any specific reason for making it different here ?
> + opp-hz = /bits/ 64 <99532800>;
> + opp-microvolt = <950000 1000000 1650000>;
> + clock-latency-ns = <20>;
> + };
> + opp at 199100 {
> + opp-hz = /bits/ 64 <199065600>;
> + opp-microvolt = <1000000 950000 1650000>;
> + clock-latency-ns = <20>;
> + };
> + opp at 298600 {
> + opp-hz = /bits/ 64 <298598400>;
> + opp-microvolt = <1100000 1045000 1650000>;
> + clock-latency-ns = <20>;
> + };
> + opp at 398100 {
> + opp-hz = /bits/ 64 <398131200>;
> + opp-microvolt = <1300000 1235000 1650000>;
> + clock-latency-ns = <20>;
> + };
> + };
> };
> --
> 2.1.4
--
viresh
^ permalink raw reply
* [PATCH v2 1/4] cpufreq: pxa: use generic platdev driver for device-tree
From: Viresh Kumar @ 2016-10-18 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476561450-28407-2-git-send-email-robert.jarzmik@free.fr>
On 15-10-16, 21:57, Robert Jarzmik wrote:
> For device-tree based pxa25x and pxa27x platforms, cpufreq-dt driver is
> doing the job as well as pxa2xx-cpufreq, so add these platforms to the
> compatibility list.
>
> This won't work for legacy non device-tree platforms where
> pxa2xx-cpufreq is still required.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 0bb44d5b5df4..356825b5c9b8 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -32,6 +32,8 @@ static const struct of_device_id machines[] __initconst = {
> { .compatible = "fsl,imx7d", },
>
> { .compatible = "marvell,berlin", },
> + { .compatible = "marvell,pxa250", },
> + { .compatible = "marvell,pxa270", },
>
> { .compatible = "samsung,exynos3250", },
> { .compatible = "samsung,exynos4210", },
Isn't there a race between cpufreq-dt and the platform driver to
register first ?
Also, it seems that atleast the next two patches are required before
applying this? You need to fix the order if that is the case.
--
viresh
^ permalink raw reply
* [PATCH 1/2] iommu/mediatek: Convert M4Uv2 to iommu_fwspec
From: Yong Wu @ 2016-10-18 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0205bf6404b16bdebe8039bfc65570a2a6f9f960.1476704508.git.robin.murphy@arm.com>
On Mon, 2016-10-17 at 12:49 +0100, Robin Murphy wrote:
> Our per-device data consists of the M4U instance and firmware-provided
> list of LARB IDs, which is a perfect fit for the generic iommu_fwspec
> machinery. Use that directly as a simpler alternative to the custom
> archdata code.
>
> CC: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>
> These are fairly mechanical cleanups, so I'm pretty confident, but it
> still bears mentioning that they're only compile-tested as I don't have
> the relevant hardware.
Thanks for the improvement.
Tested-by: Yong Wu <yong.wu@mediatek.com>
>
> Robin.
>
> drivers/iommu/mtk_iommu.c | 75 ++++++++++++-----------------------------------
> 1 file changed, 18 insertions(+), 57 deletions(-)
>
[...]
^ permalink raw reply
* [PATCH 2/3] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC
From: Viresh Kumar @ 2016-10-18 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476629958-25368-3-git-send-email-yamada.masahiro@socionext.com>
On 16-10-16, 23:59, Masahiro Yamada wrote:
> + cluster0_opp: opp_table {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp at 245000000 {
> + opp-hz = /bits/ 64 <245000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 250000000 {
> + opp-hz = /bits/ 64 <250000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 490000000 {
> + opp-hz = /bits/ 64 <490000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 500000000 {
> + opp-hz = /bits/ 64 <500000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 653333333 {
Why isn't ^^ matching with below values ? Same in next patch as well.
> + opp-hz = /bits/ 64 <653334000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 666666666 {
> + opp-hz = /bits/ 64 <666667000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 980000000 {
> + opp-hz = /bits/ 64 <980000000>;
> + clock-latency-ns = <300>;
> + };
> + };
> +
> clocks {
> refclk: ref {
> compatible = "fixed-clock";
> --
> 1.9.1
--
viresh
^ permalink raw reply
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Neil Armstrong @ 2016-10-18 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018110807.GD1641@makrotopia.org>
On 10/18/2016 01:08 PM, Daniel Golle wrote:
> Hi Neil,
>
> great to see progress towards supporting OX820!
> The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
> looks very similar, see
>
> https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c;h=f5a142950e32227fee304de731e619278350a91b;hb=refs/heads/oxnas-nand
>
> To me therefore this looks quite good, just one small question below.
Hi Daniel,
Yes, I work step by step, I hope to have something booting for 4.10 !
Indeed, they look identical except the part_probes[] stuff, are they necessary ?
My primary source of code was Ma Haiju's tree and OPenWRT's tree, but would some people like to push some of the openwrt driver upstream somehow ?
Thanks,
Neil
>
> Cheers
>
> Daniel
>
>
> On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
>> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
>> This is a simple memory mapped NAND controller with single chip select and
>> software ECC.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
>> drivers/mtd/nand/Kconfig | 5 +
>> drivers/mtd/nand/Makefile | 1 +
>> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
>> 4 files changed, 174 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
>> create mode 100644 drivers/mtd/nand/oxnas_nand.c
>>
[...]
>> diff --git a/drivers/mtd/nand/oxnas_nand.c b/drivers/mtd/nand/oxnas_nand.c
>> new file mode 100644
>> index 0000000..ee402ab
>> --- /dev/null
>> +++ b/drivers/mtd/nand/oxnas_nand.c
>> @@ -0,0 +1,144 @@
>> +/*
>> + * Oxford Semiconductor OXNAS NAND driver
>> + *
>> + * Heavily based on plat_nand.c :
>> + * Author: Vitaly Wool <vitalywool@gmail.com>
Hmm, I forgot the OpenWRT and Ma Haijun copyrights here...
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/clk.h>
>> +#include <linux/reset.h>
>> +#include <linux/mtd/mtd.h>
>> +#include <linux/mtd/nand.h>
>> +#include <linux/mtd/partitions.h>
>> +
>> +/* nand commands */
>> +#define NAND_CMD_ALE BIT(18)
>> +#define NAND_CMD_CLE BIT(19)
>> +#define NAND_CMD_CS 0
>> +#define NAND_CMD_RESET 0xff
>> +#define NAND_CMD (NAND_CMD_CS | NAND_CMD_CLE)
>> +#define NAND_ADDR (NAND_CMD_CS | NAND_CMD_ALE)
>> +#define NAND_DATA (NAND_CMD_CS)
>> +
>> +struct oxnas_nand_data {
>> + struct nand_chip chip;
>> + void __iomem *io_base;
>
> Why do you redundantly keep io_base in platform data rather than
> just using chip.IO_ADDR_R and >chip.IO_ADDR_W?
For no reason since it's not used in oxnas_nand_cmd_ctrl...
Will remove !
>
>
>> + struct clk *clk;
>> +};
>> +
>> +static void oxnas_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
>> + unsigned int ctrl)
>> +{
>> + struct nand_chip *this = mtd->priv;
>> + unsigned long nandaddr = (unsigned long) this->IO_ADDR_W;
>> +
>> + if (ctrl & NAND_CTRL_CHANGE) {
>> + nandaddr &= ~(NAND_CMD | NAND_ADDR);
>> + if (ctrl & NAND_CLE)
>> + nandaddr |= NAND_CMD;
>> + else if (ctrl & NAND_ALE)
>> + nandaddr |= NAND_ADDR;
>> + this->IO_ADDR_W = (void __iomem *) nandaddr;
>> + }
>> +
>> + if (cmd != NAND_CMD_NONE)
>> + writeb(cmd, (void __iomem *) nandaddr);
>> +}
[...]
^ permalink raw reply
* [RFC] reduce latency in __purge_vmap_area_lazy
From: Jisheng Zhang @ 2016-10-18 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476773771-11470-1-git-send-email-hch@lst.de>
On Tue, 18 Oct 2016 08:56:05 +0200 Christoph Hellwig wrote:
> Hi all,
>
> this is my spin at sorting out the long lock hold times in
> __purge_vmap_area_lazy. It is based on the patch from Joel sent this
> week. I don't have any good numbers for it, but it survived an
> xfstests run on XFS which is a significant vmalloc user. The
> changelogs could still be improved as well, but I'd rather get it
> out quickly for feedback and testing.
I just tested this series, the preempt off ftrace log doesn't complain
__purge_vmap_area_lazy any more in my test case, this latency is removed!
So feel free to add
Tested-by: Jisheng Zhang <jszhang@marvell.com>
^ permalink raw reply
* [PATCH v4 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index 5450367..3b23b32 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
&davinci_mdio {
dp83867_0: ethernet-phy at 2 {
reg = <2>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
reg = <3>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index 064b322..5450367 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
};
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
/* Extended Registers */
#define DP83867_RGMIICTL 0x0032
#define DP83867_RGMIIDCTL 0x0086
+#define DP83867_IO_MUX_CFG 0x0170
#define DP83867_SW_RESET BIT(15)
#define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
/* RGMIIDCTL bits */
#define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
+
struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+ int io_impedance;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
+ dp83867->io_impedance = -EINVAL;
+
+ /* Optional configuration */
+ if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+ else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
DP83867_DEVADDR, delay);
+
+ if (dp83867->io_impedance >= 0) {
+ val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR);
+
+ val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+ val |= dp83867->io_impedance &
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+ phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR, val);
+ }
}
return 0;
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
Add documention of ti,min-output-impedance and ti,max-output-impedance
which can be used to correct MAC impedance mismatch using phy extended
registers.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
+Optional property:
+ - ti,min-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ minimum value (35 ohms).
+ - ti,max-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+ exclusive. When both properties are present ti,max-output-impedance
+ takes precedence.
+
Default child nodes are standard Ethernet PHY device
nodes as described in Documentation/devicetree/bindings/net/phy.txt
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Changes from v3:
* Fixup change log text and no code changes.
Changes from v2:
* Fixed a typo in dts and driver.
Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.
[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23343139/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v4
Mugunthan V N (4):
net: phy: dp83867: Add documentation for optional impedance control
net: phy: dp83867: add support for MAC impedance configuration
ARM: dts: dra72-evm-revc: add phy impedance settings
ARM: dts: dra72-evm-revc: fix correct phy delay
.../devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++
arch/arm/boot/dts/dra72-evm-revc.dts | 10 ++++----
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++
3 files changed, 46 insertions(+), 4 deletions(-)
--
2.10.1.445.g3cdd5d1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox