* linux-next: build failure after merge of the usb tree
From: Stephen Rothwell @ 2014-07-24 7:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi Greg,
After merging the usb tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/phy/phy-spear1310-miphy.c: In function 'spear1310_miphy_probe':
drivers/phy/phy-spear1310-miphy.c:232:14: warning: passing argument 2 of 'devm_phy_create' from incompatible pointer type
priv->phy = devm_phy_create(dev, &spear1310_miphy_ops, NULL);
^
In file included from drivers/phy/phy-spear1310-miphy.c:21:0:
include/linux/phy/phy.h:164:13: note: expected 'struct device_node *' but argument is of type 'struct phy_ops *'
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
^
drivers/phy/phy-spear1310-miphy.c:232:14: error: too few arguments to function 'devm_phy_create'
priv->phy = devm_phy_create(dev, &spear1310_miphy_ops, NULL);
^
In file included from drivers/phy/phy-spear1310-miphy.c:21:0:
include/linux/phy/phy.h:164:13: note: declared here
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
^
drivers/phy/phy-spear1340-miphy.c: In function 'spear1340_miphy_probe':
drivers/phy/phy-spear1340-miphy.c:264:14: warning: passing argument 2 of 'devm_phy_create' from incompatible pointer type
priv->phy = devm_phy_create(dev, &spear1340_miphy_ops, NULL);
^
In file included from drivers/phy/phy-spear1340-miphy.c:21:0:
include/linux/phy/phy.h:164:13: note: expected 'struct device_node *' but argument is of type 'struct phy_ops *'
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
^
drivers/phy/phy-spear1340-miphy.c:264:14: error: too few arguments to function 'devm_phy_create'
priv->phy = devm_phy_create(dev, &spear1340_miphy_ops, NULL);
^
In file included from drivers/phy/phy-spear1340-miphy.c:21:0:
include/linux/phy/phy.h:164:13: note: declared here
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
^
Caused by commit f0ed817638b5 ("phy: core: Let node ptr of PHY point to
PHY and not of PHY provider") interacting with commit 64562e99477f
("phy: Add drivers for PCIe and SATA phy on SPEAr13xx") from the
arm-soc tree.
I fixed that up and then got:
drivers/pinctrl/pinctrl-tegra-xusb.c: In function 'tegra_xusb_padctl_probe':
drivers/pinctrl/pinctrl-tegra-xusb.c:913:8: warning: passing argument 2 of 'devm_phy_create' from incompatible pointer type
phy = devm_phy_create(&pdev->dev, &pcie_phy_ops, NULL);
^
In file included from drivers/pinctrl/pinctrl-tegra-xusb.c:18:0:
include/linux/phy/phy.h:164:13: note: expected 'struct device_node *' but argument is of type 'const struct phy_ops *'
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
^
drivers/pinctrl/pinctrl-tegra-xusb.c:913:8: error: too few arguments to function 'devm_phy_create'
phy = devm_phy_create(&pdev->dev, &pcie_phy_ops, NULL);
^
In file included from drivers/pinctrl/pinctrl-tegra-xusb.c:18:0:
include/linux/phy/phy.h:164:13: note: declared here
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
^
drivers/pinctrl/pinctrl-tegra-xusb.c:922:8: warning: passing argument 2 of 'devm_phy_create' from incompatible pointer type
phy = devm_phy_create(&pdev->dev, &sata_phy_ops, NULL);
^
In file included from drivers/pinctrl/pinctrl-tegra-xusb.c:18:0:
include/linux/phy/phy.h:164:13: note: expected 'struct device_node *' but argument is of type 'const struct phy_ops *'
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
^
drivers/pinctrl/pinctrl-tegra-xusb.c:922:8: error: too few arguments to function 'devm_phy_create'
phy = devm_phy_create(&pdev->dev, &sata_phy_ops, NULL);
^
In file included from drivers/pinctrl/pinctrl-tegra-xusb.c:18:0:
include/linux/phy/phy.h:164:13: note: declared here
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
^
>From an interaction with commit dc0a39386687 ("pinctrl: Add NVIDIA
Tegra XUSB pad controller support") from the arm-soc tree.
Final merge fix patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 24 Jul 2014 16:55:16 +1000
Subject: [PATCH] phy: fix up for devm_phy_create api change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/phy/phy-spear1310-miphy.c | 2 +-
drivers/phy/phy-spear1340-miphy.c | 2 +-
drivers/pinctrl/pinctrl-tegra-xusb.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/phy-spear1310-miphy.c b/drivers/phy/phy-spear1310-miphy.c
index c58c869d57e0..6dcbfcddb372 100644
--- a/drivers/phy/phy-spear1310-miphy.c
+++ b/drivers/phy/phy-spear1310-miphy.c
@@ -229,7 +229,7 @@ static int spear1310_miphy_probe(struct platform_device *pdev)
return -EINVAL;
}
- priv->phy = devm_phy_create(dev, &spear1310_miphy_ops, NULL);
+ priv->phy = devm_phy_create(dev, NULL, &spear1310_miphy_ops, NULL);
if (IS_ERR(priv->phy)) {
dev_err(dev, "failed to create SATA PCIe PHY\n");
return PTR_ERR(priv->phy);
diff --git a/drivers/phy/phy-spear1340-miphy.c b/drivers/phy/phy-spear1340-miphy.c
index 8de98adf21c3..7135ba2603b6 100644
--- a/drivers/phy/phy-spear1340-miphy.c
+++ b/drivers/phy/phy-spear1340-miphy.c
@@ -261,7 +261,7 @@ static int spear1340_miphy_probe(struct platform_device *pdev)
return PTR_ERR(priv->misc);
}
- priv->phy = devm_phy_create(dev, &spear1340_miphy_ops, NULL);
+ priv->phy = devm_phy_create(dev, NULL, &spear1340_miphy_ops, NULL);
if (IS_ERR(priv->phy)) {
dev_err(dev, "failed to create SATA PCIe PHY\n");
return PTR_ERR(priv->phy);
diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c b/drivers/pinctrl/pinctrl-tegra-xusb.c
index 4a7daf577b49..a06620474845 100644
--- a/drivers/pinctrl/pinctrl-tegra-xusb.c
+++ b/drivers/pinctrl/pinctrl-tegra-xusb.c
@@ -910,7 +910,7 @@ static int tegra_xusb_padctl_probe(struct platform_device *pdev)
goto reset;
}
- phy = devm_phy_create(&pdev->dev, &pcie_phy_ops, NULL);
+ phy = devm_phy_create(&pdev->dev, NULL, &pcie_phy_ops, NULL);
if (IS_ERR(phy)) {
err = PTR_ERR(phy);
goto unregister;
@@ -919,7 +919,7 @@ static int tegra_xusb_padctl_probe(struct platform_device *pdev)
padctl->phys[TEGRA_XUSB_PADCTL_PCIE] = phy;
phy_set_drvdata(phy, padctl);
- phy = devm_phy_create(&pdev->dev, &sata_phy_ops, NULL);
+ phy = devm_phy_create(&pdev->dev, NULL, &sata_phy_ops, NULL);
if (IS_ERR(phy)) {
err = PTR_ERR(phy);
goto unregister;
--
2.0.1
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140724/8c977cb0/attachment.sig>
^ permalink raw reply related
* [PATCH] arm/mach-imx/iomux: Do not export symbol without public declaration
From: Alexander Stein @ 2014-07-24 7:05 UTC (permalink / raw)
To: linux-arm-kernel
The iomux function declarations are in headers only accessible in this
directory. Thus those can't be used in any module. None of the
objects in this directory is tristate. Neither can the header be included
in out-of-tree modules.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
arch/arm/mach-imx/iomux-imx31.c | 7 -------
arch/arm/mach-imx/iomux-v1.c | 2 --
arch/arm/mach-imx/iomux-v3.c | 2 --
3 files changed, 11 deletions(-)
diff --git a/arch/arm/mach-imx/iomux-imx31.c b/arch/arm/mach-imx/iomux-imx31.c
index 7c66805d2cc0..1657fe64cd0f 100644
--- a/arch/arm/mach-imx/iomux-imx31.c
+++ b/arch/arm/mach-imx/iomux-imx31.c
@@ -64,7 +64,6 @@ int mxc_iomux_mode(unsigned int pin_mode)
return ret;
}
-EXPORT_SYMBOL(mxc_iomux_mode);
/*
* This function configures the pad value for a IOMUX pin.
@@ -90,7 +89,6 @@ void mxc_iomux_set_pad(enum iomux_pins pin, u32 config)
spin_unlock(&gpio_mux_lock);
}
-EXPORT_SYMBOL(mxc_iomux_set_pad);
/*
* allocs a single pin:
@@ -116,7 +114,6 @@ int mxc_iomux_alloc_pin(unsigned int pin, const char *label)
return 0;
}
-EXPORT_SYMBOL(mxc_iomux_alloc_pin);
int mxc_iomux_setup_multiple_pins(const unsigned int *pin_list, unsigned count,
const char *label)
@@ -137,7 +134,6 @@ setup_error:
mxc_iomux_release_multiple_pins(pin_list, i);
return ret;
}
-EXPORT_SYMBOL(mxc_iomux_setup_multiple_pins);
void mxc_iomux_release_pin(unsigned int pin)
{
@@ -146,7 +142,6 @@ void mxc_iomux_release_pin(unsigned int pin)
if (pad < (PIN_MAX + 1))
clear_bit(pad, mxc_pin_alloc_map);
}
-EXPORT_SYMBOL(mxc_iomux_release_pin);
void mxc_iomux_release_multiple_pins(const unsigned int *pin_list, int count)
{
@@ -158,7 +153,6 @@ void mxc_iomux_release_multiple_pins(const unsigned int *pin_list, int count)
p++;
}
}
-EXPORT_SYMBOL(mxc_iomux_release_multiple_pins);
/*
* This function enables/disables the general purpose function for a particular
@@ -178,4 +172,3 @@ void mxc_iomux_set_gpr(enum iomux_gp_func gp, bool en)
__raw_writel(l, IOMUXGPR);
spin_unlock(&gpio_mux_lock);
}
-EXPORT_SYMBOL(mxc_iomux_set_gpr);
diff --git a/arch/arm/mach-imx/iomux-v1.c b/arch/arm/mach-imx/iomux-v1.c
index 2b156d1d9e21..ecd543664644 100644
--- a/arch/arm/mach-imx/iomux-v1.c
+++ b/arch/arm/mach-imx/iomux-v1.c
@@ -153,7 +153,6 @@ int mxc_gpio_mode(int gpio_mode)
return 0;
}
-EXPORT_SYMBOL(mxc_gpio_mode);
static int imx_iomuxv1_setup_multiple(const int *list, unsigned count)
{
@@ -178,7 +177,6 @@ int mxc_gpio_setup_multiple_pins(const int *pin_list, unsigned count,
ret = imx_iomuxv1_setup_multiple(pin_list, count);
return ret;
}
-EXPORT_SYMBOL(mxc_gpio_setup_multiple_pins);
int __init imx_iomuxv1_init(void __iomem *base, int numports)
{
diff --git a/arch/arm/mach-imx/iomux-v3.c b/arch/arm/mach-imx/iomux-v3.c
index 9dae74bf47fc..d61f9606fc56 100644
--- a/arch/arm/mach-imx/iomux-v3.c
+++ b/arch/arm/mach-imx/iomux-v3.c
@@ -55,7 +55,6 @@ int mxc_iomux_v3_setup_pad(iomux_v3_cfg_t pad)
return 0;
}
-EXPORT_SYMBOL(mxc_iomux_v3_setup_pad);
int mxc_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t *pad_list, unsigned count)
{
@@ -71,7 +70,6 @@ int mxc_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t *pad_list, unsigned count)
}
return 0;
}
-EXPORT_SYMBOL(mxc_iomux_v3_setup_multiple_pads);
void mxc_iomux_v3_init(void __iomem *iomux_v3_base)
{
--
1.8.5.5
^ permalink raw reply related
* [PATCH v2] cpufreq: tests: Providing cpufreq regression test
From: Lukasz Majewski @ 2014-07-24 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3777635.Nvoh2EpFlu@vostro.rjw.lan>
Hi Rafael,
> On Monday, July 21, 2014 09:02:34 AM Lukasz Majewski wrote:
> > This commit adds first regression test "cpufreq_freq_test.sh" for
> > the cpufreq subsystem.
>
> First of all, I'm not seeing any explanation why this script should be
> shipped with the kernel.
OK.
>
> What regressions it tests against in particular and
Do you require SHA's/commit messages of commits which were developed to
fix issues spotted with this test script?
> how it does that.
Is this information required in the commit message or can it stay in
the README file created in the same commit?
>
> Please write that down in the changelog. It doesn't need to be very
> detailed.
>
> Second, I'm not sure this is the first such test (someone already
> mentioned cpupower).
It's no problem for me to add such scripts to other work.
>
> > Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
> >
> > ---
> > Changes for v2:
> > - Replace *_PATCH with *_PATH for variables names
> > - Corrected mistakes in the README file
> > - Providing detailed explanation of the patch in the README file
> > ---
> > drivers/cpufreq/tests/README | 33 +++++++
> > drivers/cpufreq/tests/cpufreq_freq_test.sh | 149
> > +++++++++++++++++++++++++++++ 2 files changed, 182 insertions(+)
> > create mode 100644 drivers/cpufreq/tests/README
> > create mode 100755 drivers/cpufreq/tests/cpufreq_freq_test.sh
> >
> > diff --git a/drivers/cpufreq/tests/README
> > b/drivers/cpufreq/tests/README
>
> drivers/cpufreq/ is not a place for scripts.
>
> We have scripts/ for that and you can add a "power" subdirectory in
> there and put your script into it.
>
> Alternatively, you can use the existing tools/power/ directory for
> that (but then please add a subdirectory for your script).
Ok.
>
> > new file mode 100644
> > index 0000000..3e9cd80
> > --- /dev/null
> > +++ b/drivers/cpufreq/tests/README
> > @@ -0,0 +1,33 @@
> > +This file contains list of cpufreq's available regression tests
> > with a short +usage description.
> > +
> > +1. cpufreq_freq_test.sh
> > +
> > +Description:
> > +------------
> > +This script is supposed to test if cpufreq attributes exported by
> > sysfs are +exposing correct values.
> > +
> > +To achieve this goal it saves the current governor and changes it
> > to +"performance". Afterwards, it reads the
> > "scaling_available_frequencies" +property. With the list of
> > supported frequencies it is able to enforce each of +them by
> > writing to "scaling_max_freq" attribute. To make the test more
> > reliable +a superfluous load with gzip is created to be sure that
> > we are running with +highest possible frequency. This high load is
> > regulated with the 'sleep' +duration. After this time the
> > "cpufreq_cur_freq" is read and compared with the +original value.
> > As the last step the original governor is restored. + +This script
> > can work with or without BOOST enabled and helps in spotting errors
> > +related to cpufreq and common clock framework. +
> > +Used attributes:
> > +----------------
> > +- "scaling_available_frequencies"
> > +- "cpuinfo_cur_freq"
> > +- "scaling_governor"
> > +- "scaling_max_freq"
> > +
> > +Target devices:
> > +---------------
> > +
> > +All devices which exports mentioned above sysfs attributes.
> > \ No newline at end of file
> > diff --git a/drivers/cpufreq/tests/cpufreq_freq_test.sh
> > b/drivers/cpufreq/tests/cpufreq_freq_test.sh new file mode 100755
> > index 0000000..c25f05c
> > --- /dev/null
> > +++ b/drivers/cpufreq/tests/cpufreq_freq_test.sh
> > @@ -0,0 +1,149 @@
> > +#!/bin/bash
> > +#
> > +# This file provides a simple mean to test if all declared freqs at
> > +# "scaling_available_frequencies" can be set and if
> > "cpuinfo_cur_freq" +# returns this value.
> > +#
> > +# Usage: ./cpufreq_freq_test.sh
> > +# Requisite: Compiled in "performance" governor
> > +#
> > +# 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.
> > +#
> > +# This program is distributed in the hope that it will be useful,
> > +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > +# GNU General Public License for more details.
> > +#
> > +# You should have received a copy of the GNU General Public License
> > +# along with this program; if not, you can access it online at
> > +# http://www.gnu.org/licenses/gpl-2.0.html.
> > +#
> > +# Copyright (C) Samsung Electronics, 2014
> > +#
> > +# Author: Lukasz Majewski <l.majewski@samsung.com>
> > +
> > +set +x
> > +
> > +COLOUR_RED="\33[31m"
> > +COLOUR_BLUE="\33[34m"
> > +COLOUR_GREEN="\33[32m"
> > +COLOUR_DEFAULT="\33[0m"
> > +
> > +T_PATH=/sys/devices/system/cpu/cpu0/cpufreq
> > +BOOST_PATH=/sys/devices/system/cpu/cpufreq
> > +
> > +if [ ! -d "$T_PATH" ]; then
> > + printf " $COLOUR_RED No path to CPUFREQ $COLOUR_DEFAULT\n"
> > + exit 1
> > +fi
> > +
> > +ERRORS=0
> > +
> > +OLD_GOV=`cat $T_PATH/scaling_governor`
> > +echo "CURRENT GOVERNOR: $OLD_GOV"
> > +echo "SET GOVERNOR: performance"
> > +echo "performance" > $T_PATH/scaling_governor
> > +
> > +function test_freqs1 {
> > + FREQS=`cat $1`
> > + for I in $FREQS; do
> > + cpufreq_set_freq $I
> > + if [ "$2" ]; then
> > + printf "$COLOUR_BLUE BOOST $COLOUR_DEFAULT" $I
> > + fi
> > + cpufreq_test_freq $I
> > + done
> > +}
> > +
> > +function test_freqs2 {
> > + FREQ=`cat $1`
> > + FREQS_ARRAY=($FREQ)
> > +
> > + for freq in ${FREQS_ARRAY[@]}
> > + do
> > + echo "REFERENCE FREQ: $freq"
> > + for f in ${FREQS_ARRAY[@]}
> > + do
> > + cpufreq_set_freq $freq
> > + echo -n "----> "
> > + cpufreq_set_freq $f
> > + cpufreq_test_freq $f
> > + done
> > + done
> > +}
> > +
> > +function restore {
> > + if [ -f $BOOST_PATH/boost ]; then
> > + cpufreq_boost_state $BOOST_STATE
> > + fi
> > +
> > + echo "SET GOVERNOR: $OLD_GOV"
> > + echo $OLD_GOV > $T_PATH/scaling_governor
> > +}
> > +
> > +function die {
> > + printf " $COLOUR_RED FAILED $COLOUR_DEFAULT\n"
> > + restore_gov
> > + exit 1
> > +}
> > +
> > +function cpufreq_test_freq {
> > + gzip < /dev/urandom > /dev/null &
> > + pid=$!
> > + sleep 0.1
> > + CURR_FREQ=`cat $T_PATH/cpuinfo_cur_freq`
> > + if [ $1 -eq $CURR_FREQ ]; then
> > + printf "\t$COLOUR_GREEN OK $COLOUR_DEFAULT\n"
> > + else
> > + printf "$COLOUR_RED CURRENT $CURR_FREQ $COLOUR_DEFAULT\n"
> > + ERRORS=`expr $ERRORS + 1`
> > + #die
> > + fi
> > + kill -9 $pid
> > + wait $! 2>/dev/null
> > +}
> > +
> > +function cpufreq_set_freq {
> > + echo $1 > $T_PATH/scaling_max_freq || die $?
> > + printf "FREQ:$COLOUR_GREEN %s $COLOUR_DEFAULT" $1
> > +}
> > +
> > +function cpufreq_boost_state {
> > + echo $1 > $BOOST_PATH/boost
> > +}
> > +
> > +function cpufreq_boost_status {
> > + cat $BOOST_PATH/boost
> > +}
> > +
> > +if [ -f $BOOST_PATH/boost ]; then
> > + echo "######################################"
> > + echo "TEST BOOST OPERATION"
> > + echo "######################################"
> > +
> > + BOOST_STATE=$(cpufreq_boost_status)
> > + if [ $BOOST_STATE -eq 0 ]; then
> > + cpufreq_boost_state 1
> > + fi
> > + test_freqs1 $T_PATH/scaling_boost_frequencies 1
> > +fi
> > +
> > +echo "######################################"
> > +echo "TEST AVAILABLE FREQS"
> > +echo "######################################"
> > +test_freqs1 $T_PATH/scaling_available_frequencies
> > +
> > +echo "######################################"
> > +echo "TEST FREQS SWITCHING"
> > +echo "######################################"
> > +test_freqs2 $T_PATH/scaling_available_frequencies
> > +
> > +echo "######################################"
> > +echo "ERRORS: $ERRORS"
> > +echo "######################################"
> > +
> > +restore
> > +exit 0
> >
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply
* [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
From: Tony Lindgren @ 2014-07-24 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4101565.HEj9dhtF5Z@avalon>
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [140723 07:02]:
> Hi Joerg,
>
> On Wednesday 23 July 2014 15:52:17 Joerg Roedel wrote:
> > On Mon, Jul 21, 2014 at 11:19:29PM -0700, Tony Lindgren wrote:
> > > > Tony, is there still time to get this (and especially patch 2/3, which
> > > > touches arch/ code) in v3.17 ?
> > >
> > > Yes as long as Joerg is OK to merge that branch in :)
> >
> > Fine with me, I can take only patch 1 or all 3 into my arm/omap branch,
> > given Tony's Acked-by.
> >
> > Then you guys can merge in this branch wherever you want :)
>
> Thank you. Assuming there's currently no conflict to be resolved, I believe
> the easiest would be for both you and Tony to merge my branch in your trees.
Yes please merge that branch via the IOMMU tree, I only need to merge it
if I see merge conflicts with it.
Regards,
Tony
^ permalink raw reply
* [PATCHv4 4/5] of/mtd/nand: add generic binding and helper for NAND_BBT_NO_OOB_BBM
From: Lothar Waßmann @ 2014-07-24 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140724020627.GD3711@ld-irv-0074>
Hi,
Brian Norris wrote:
> (BTW, that's a mighty CC list you have! I'm not sure all CC'd parties
> are interested in this series; e.g., Russel and the ARM list seem
> unrelated)
>
> Hi Lothar,
>
> Sorry for the delay on this. I get busy enough that I can't/don't reply
> to everything quickly...
>
> On Thu, Jun 12, 2014 at 03:20:44PM +0200, Lothar Wa?mann wrote:
> > add a boolean property 'nand-no-oob-bbm' and helper function to be
> > able to set the NAND_BBT_NO_OOB_BBM flag in DT capable NAND drivers
> > and use it for i.MX and MXS nand drivers.
>
> If I'm understanding your previous conversations with Huang correctly,
> you *must* use NAND_BBT_NO_OOB_BBM if you're going to use the
> fsl,no-blockmark-swap option. Correct? If so, then you might not need
> a separate 'nand-no-oob-bbm' binding; your driver should imply from
> 'fsl,no-blockmark-swap' that it must also enable NAND_BBT_NO_OOB_BBM.
>
no-blockmark-swap implies NO_OOB_BBM but NO_OOB_BBM may also be used
independent from no-blockmark-swap.
IMO writing a bad block marker to flash (which is prevented by
the NAND_BBT_NO_OOB_BBM flag) is a misinterpretation of the purpose of
the BB mark in the first place. The manufacturer guarantees that blocks
which are initially bad will have at least one zero bit in the position
of the BB mark. That's all to it.
There is no guarantee, that you will even be able to write any
deterministic data to a block that has turned bad due to wearout or
other flash defects. It is rather bogus to rely on data written to a
known bad block to reflect the state of the block.
> Also, as I noted in [1], I don't really like exposing a ton of
> individual boolean DT properties like this. (At least this property is
> orthogonal to the bad block table; I was a little off-base in [1].)
>
How else should this information be conveyed to the flash drivers?
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH] ARM: zynq: DT: Add CAN node
From: Michal Simek @ 2014-07-24 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723160702.GA14564@xsjandreislx>
On 07/23/2014 06:07 PM, S?ren Brinkmann wrote:
> On Wed, 2014-07-23 at 03:05PM +0200, Michal Simek wrote:
>> Add node describing Zynq's CAN controller.
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> ---
>>
>> arch/arm/boot/dts/zynq-7000.dtsi | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
>> index 366ca6434f54..2287d9b4ed1a 100644
>> --- a/arch/arm/boot/dts/zynq-7000.dtsi
>> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
>> @@ -71,7 +71,18 @@
>> interrupts = <0 7 4>;
>> interrupt-parent = <&intc>;
>> clocks = <&clkc 12>;
>> - };
>> + };
>> +
>> + can0: can at e0008000 {
>> + compatible = "xlnx,zynq-can-1.0";
>> + clocks = <&clkc 19>, <&clkc 36>;
>> + clock-names = "can_clk", "pclk";
>> + reg = <0xe0008000 0x1000>;
>> + interrupts = <0 28 4>;
>> + interrupt-parent = <&intc>;
>> + tx-fifo-depth = <0x40>;
>> + rx-fifo-depth = <0x40>;
>> + };
>
> What about the second CAN core? You also probably want to add
> 'status = "disabled"' in the dtsi.
Second can core - yes.
I can add status = "disabled" but then question is if make
sense to change status for any zynq dts file. Or just
keep enable both.
In our repo is enabled can0 on zc702.
What do you think?
Thanks,
Michal
^ permalink raw reply
* [PATCH v2 1/2] clk: samsung: exynos4: Enable ARMCLK down feature
From: Krzysztof Kozlowski @ 2014-07-24 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140724001853.6419.551@quantum>
On ?ro, 2014-07-23 at 17:18 -0700, Mike Turquette wrote:
> Quoting Krzysztof Kozlowski (2014-07-18 07:36:32)
> > Enable ARMCLK down feature on all Exynos4 SoCs. The frequency of
> > ARMCLK will be reduced upon entering idle mode (WFI or WFE).
> >
> > The feature behaves like very fast cpufreq ondemand governor. In idle
> > mode this reduces energy consumption on full frequency chosen by
> > cpufreq governor by approximately:
> > - Trats2: 6.5% (153 mA -> 143 mA)
> > - Trats: 33.0% (180 mA -> 120 mA)
> > - Gear1: 27.0% (180 mA -> 130 mA)
>
> Nice power savings! Just a quick question on this feature: the clock
> frequency is changed in hardware as a result of WFI/WFE?
Yes. This feature makes changes in DIVCORE and DIVCORE2 clock dividers
when given core enters WFI/WFE.
> And this only
> happens when all CPUs in a cluster (e.g. all 4 CPUs in Exynos 4412) are
> in WFI/WFE state?
No, this is per-core. However measured energy savings above were in case
where all cores entered idle (WFI).
Best regards,
Krzysztof
>
> Thanks,
> Mike
>
> >
> > The patch uses simillar settings as Exynos5250 (clk-exynos5250.c),
> > except it disables clock up feature and on Exynos4412 ARMCLK down is
> > enabled for all 4 cores.
> >
> > Tested on Trats board (Exynos4210), Trats2 board (Exynos4412) and
> > Samsung Gear 1 (Exynos4212).
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> >
> > ---
> >
> > Changes since v1:
> > 1. Add PWR_CTRL registers to the list of saved clk registers on
> > Exynos4x12. Suggested by Tomasz Figa.
> > 2. Disable the clock up feature. (sug. Tomasz Figa)
> > 3. Use macros for setting clock down ratio. (sug. Tomasz Figa)
> > 4. Use num_possible_cpus() for exception on Exynos4x12. (sug. Tomasz
> > Figa)
> > 5. Enable the clock down feature also on Exynos4210 Trats board.
> > ---
> > drivers/clk/samsung/clk-exynos4.c | 46 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 46 insertions(+)
> >
> > diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
> > index 7f4a473a7ad7..86c7709dc6d6 100644
> > --- a/drivers/clk/samsung/clk-exynos4.c
> > +++ b/drivers/clk/samsung/clk-exynos4.c
> > @@ -114,11 +114,27 @@
> > #define DIV_CPU1 0x14504
> > #define GATE_SCLK_CPU 0x14800
> > #define GATE_IP_CPU 0x14900
> > +#define PWR_CTRL1 0x15020
> > +#define E4X12_PWR_CTRL2 0x15024
> > #define E4X12_DIV_ISP0 0x18300
> > #define E4X12_DIV_ISP1 0x18304
> > #define E4X12_GATE_ISP0 0x18800
> > #define E4X12_GATE_ISP1 0x18804
> >
> > +/* Below definitions are used for PWR_CTRL settings */
> > +#define PWR_CTRL1_CORE2_DOWN_RATIO(x) (((x) & 0x7) << 28)
> > +#define PWR_CTRL1_CORE1_DOWN_RATIO(x) (((x) & 0x7) << 16)
> > +#define PWR_CTRL1_DIV2_DOWN_EN (1 << 9)
> > +#define PWR_CTRL1_DIV1_DOWN_EN (1 << 8)
> > +#define PWR_CTRL1_USE_CORE3_WFE (1 << 7)
> > +#define PWR_CTRL1_USE_CORE2_WFE (1 << 6)
> > +#define PWR_CTRL1_USE_CORE1_WFE (1 << 5)
> > +#define PWR_CTRL1_USE_CORE0_WFE (1 << 4)
> > +#define PWR_CTRL1_USE_CORE3_WFI (1 << 3)
> > +#define PWR_CTRL1_USE_CORE2_WFI (1 << 2)
> > +#define PWR_CTRL1_USE_CORE1_WFI (1 << 1)
> > +#define PWR_CTRL1_USE_CORE0_WFI (1 << 0)
> > +
> > /* the exynos4 soc type */
> > enum exynos4_soc {
> > EXYNOS4210,
> > @@ -155,6 +171,7 @@ static unsigned long exynos4210_clk_save[] __initdata = {
> > E4210_GATE_IP_LCD1,
> > E4210_GATE_IP_PERIR,
> > E4210_MPLL_CON0,
> > + PWR_CTRL1,
> > };
> >
> > static unsigned long exynos4x12_clk_save[] __initdata = {
> > @@ -164,6 +181,8 @@ static unsigned long exynos4x12_clk_save[] __initdata = {
> > E4X12_DIV_ISP,
> > E4X12_DIV_CAM1,
> > E4X12_MPLL_CON0,
> > + PWR_CTRL1,
> > + E4X12_PWR_CTRL2,
> > };
> >
> > static unsigned long exynos4_clk_pll_regs[] __initdata = {
> > @@ -1164,6 +1183,32 @@ static struct samsung_pll_clock exynos4x12_plls[nr_plls] __initdata = {
> > VPLL_LOCK, VPLL_CON0, NULL),
> > };
> >
> > +static void __init exynos4_core_down_clock(enum exynos4_soc soc)
> > +{
> > + unsigned int tmp;
> > +
> > + /*
> > + * Enable arm clock down (in idle) and set arm divider
> > + * ratios in WFI/WFE state.
> > + */
> > + tmp = (PWR_CTRL1_CORE2_DOWN_RATIO(7) | PWR_CTRL1_CORE1_DOWN_RATIO(7) |
> > + PWR_CTRL1_DIV2_DOWN_EN | PWR_CTRL1_DIV1_DOWN_EN |
> > + PWR_CTRL1_USE_CORE1_WFE | PWR_CTRL1_USE_CORE0_WFE |
> > + PWR_CTRL1_USE_CORE1_WFI | PWR_CTRL1_USE_CORE0_WFI);
> > + /* On Exynos4412 enable it also on core 2 and 3 */
> > + if (num_possible_cpus() == 4)
> > + tmp |= PWR_CTRL1_USE_CORE3_WFE | PWR_CTRL1_USE_CORE2_WFE |
> > + PWR_CTRL1_USE_CORE3_WFI | PWR_CTRL1_USE_CORE2_WFI;
> > + __raw_writel(tmp, reg_base + PWR_CTRL1);
> > +
> > + /*
> > + * Disable the clock up feature on Exynos4x12, in case it was
> > + * enabled by bootloader.
> > + */
> > + if (exynos4_soc == EXYNOS4X12)
> > + __raw_writel(0x0, reg_base + E4X12_PWR_CTRL2);
> > +}
> > +
> > /* register exynos4 clocks */
> > static void __init exynos4_clk_init(struct device_node *np,
> > enum exynos4_soc soc)
> > @@ -1250,6 +1295,7 @@ static void __init exynos4_clk_init(struct device_node *np,
> > samsung_clk_register_alias(ctx, exynos4_aliases,
> > ARRAY_SIZE(exynos4_aliases));
> >
> > + exynos4_core_down_clock(soc);
> > exynos4_clk_sleep_init();
> >
> > pr_info("%s clocks: sclk_apll = %ld, sclk_mpll = %ld\n"
> > --
> > 1.9.1
> >
^ permalink raw reply
* linux-next: manual merge of the usb tree with the arm-soc tree
From: Greg KH @ 2014-07-24 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140724163329.03002387@canb.auug.org.au>
On Thu, Jul 24, 2014 at 04:33:29PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Thu, 24 Jul 2014 16:28:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the usb tree got a conflict in
> > drivers/phy/Kconfig between commit 64562e99477f ("phy: Add drivers for
> > PCIe and SATA phy on SPEAr13xx") from the arm-soc tree and commit
> > 1de990d8a169 ("phy: qcom: Add driver for QCOM APQ8064 SATA PHY") from
> > the usb tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
>
> Also drivers/phy/Makefile
Both look good, thanks.
greg k-h
^ permalink raw reply
* linux-next: manual merge of the usb tree with the arm-soc tree
From: Stephen Rothwell @ 2014-07-24 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140724162811.5e12107a@canb.auug.org.au>
Hi Greg,
On Thu, 24 Jul 2014 16:28:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the usb tree got a conflict in
> drivers/phy/Kconfig between commit 64562e99477f ("phy: Add drivers for
> PCIe and SATA phy on SPEAr13xx") from the arm-soc tree and commit
> 1de990d8a169 ("phy: qcom: Add driver for QCOM APQ8064 SATA PHY") from
> the usb tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Also drivers/phy/Makefile
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc drivers/phy/Makefile
index 241c741e6e39,971ad0aac388..000000000000
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@@ -18,8 -21,7 +21,10 @@@ phy-exynos-usb2-y += phy-samsung-usb2
phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
+phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
+obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
+obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
+ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
+ obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140724/866c4b30/attachment-0001.sig>
^ permalink raw reply
* [PATCHv3 3/7] clk: mvebu: extend clk-cpu for dynamic frequency scaling
From: Thomas Petazzoni @ 2014-07-24 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723235358.6419.26311@quantum>
Hello,
(Not sure why this e-mail comes with me as the From:, but anyway.)
On Wed, 23 Jul 2014 16:53:58 -0700, Thomas Petazzoni wrote:
> +static int clk_cpu_set_rate(struct clk_hw *hwclk, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + if (__clk_is_enabled(hwclk->clk))
> + return clk_cpu_on_set_rate(hwclk, rate, parent_rate);
> + else
> + return clk_cpu_off_set_rate(hwclk, rate, parent_rate);
>
> This is racy. You don't hold the clk_enable lock so it could be enable
> between the conditional check and executing clk_cpu_on_set_rate.
Right.
> How do you ensure that secondary CPU clocks are not enabled/disabled
> when changing rates?
In practice, this currently cannot happen: we enable the secondary CPU
clocks before starting the secondary CPUs, and we never ever disable or
re-enable again those clocks. So with the present code, I believe there
is no problem. Even when we do CPU hotplug, we don't turn off the CPU
clocks, simply because they cannot be turned off: the enable/disable
state is only used here as an indication so that the clock driver knows
which frequency change strategy it should apply.
But you're anyway right, I'll send a followup patch adding the lock.
Would that be OK for you?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH V2 1/2] power: twl4030_charger: detect battery presence prior to enabling charger
From: Tony Lindgren @ 2014-07-24 6:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723120326.GA18172@earth.universe>
* Sebastian Reichel <sre@kernel.org> [140723 05:05]:
> On Wed, Jul 23, 2014 at 02:24:20AM -0700, Tony Lindgren wrote:
> > * Nishanth Menon <nm@ti.com> [140528 14:48]:
> > > TWL4030's Battery Charger seems to be designed for non-hotpluggable
> > > batteries.
> > >
> > > If battery is not present in the system, BATSTS is always set with the
> > > expectation that software will take actions to move to a required safe
> > > state (could be power down or disable various charger paths).
> > >
> > > It does not seem possible even by manipulating the edge detection
> > > of the event (using BCIEDR2 register) to have a consistent hotplug
> > > handling. This seems to be the result of BATSTS interrupt generated
> > > when the thermistor of the battery pack is disconnected from the
> > > dedicated ADIN1 pin. Clearing the status just results in the status
> > > being regenerated by the monitoring ADC(MADC) and disabling the
> > > edges of event just makes hotplug no longer function. The only
> > > other option is to disable the detection of the MADC by disabling
> > > BCIMFEN4::BATSTSMCHGEN (battery presence detector) - but then, we can
> > > never again detect battery reconnection.
> > >
> > > So, detect battery presence based on precharge(which is hardware
> > > automatic state) or default main charger configuration at the time of
> > > probe and enable charger logic only if battery was present.
> > >
> > > Reported-by: Russell King <linux@arm.linux.org.uk>
> > > Tested-by: Tony Lindgren <tony@atomide.com>
> > > Signed-off-by: Nishanth Menon <nm@ti.com>
> >
> > Dmitry, can we please get this first patch merged? This is needed
> > on some omap3 platforms for DT based booting when no battery is
> > present.
> >
> > Only the second patch in this series is still being discussed AFAIK.
>
> applied to battery-2.6.git:
>
> http://git.infradead.org/battery-2.6.git/commit/61a7784efd3c89ffb6242f29bcee170dd7f55e6b
Thanks!
Tony
^ permalink raw reply
* [PATCHv3 2/7] ARM: mvebu: extend PMSU code to support dynamic frequency scaling
From: Thomas Petazzoni @ 2014-07-24 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723235026.6419.93364@quantum>
Dear Mike Turquette,
On Wed, 23 Jul 2014 16:50:26 -0700, Mike Turquette wrote:
> > * registers the frequency operating points supported by the CPU;
> >
> > * registers a clock notifier of the CPU clocks. The notifier function
>
> Where does this code register a clock notifier callback?
>
> > listens to the newly introduced APPLY_RATE_CHANGE event, and uses
>
> I don't see APPLY_RATE_CHANGE referenced.
Yes, this is a mistake of the commit log, due to remains of the v2 of
the patch series. Back in the v2, there was indeed a new clock notifier
being used. But Stephen Boyd argued against that, and instead suggested
to use a direct function call, which this v3 implements, as stated in
the cover letter:
- As suggested by Stephen Boyd, instead of using a new clock notifier
that somewhat "hides" the dependency of the clk-cpu clock driver on
the PMSU, use a direct call from the clk-cpu driver to the PMSU
driver.
The commit log of this commit was not adjusted consequently, and this
is my fault. Jason, is it still time to change this commit log?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* linux-next: manual merge of the usb tree with the arm-soc tree
From: Stephen Rothwell @ 2014-07-24 6:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
drivers/phy/Kconfig between commit 64562e99477f ("phy: Add drivers for
PCIe and SATA phy on SPEAr13xx") from the arm-soc tree and commit
1de990d8a169 ("phy: qcom: Add driver for QCOM APQ8064 SATA PHY") from
the usb tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc drivers/phy/Kconfig
index 86c22e26a243,cc97c897945a..000000000000
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@@ -124,53 -149,30 +149,40 @@@ config PHY_SUN4I_US
config PHY_SAMSUNG_USB2
tristate "Samsung USB 2.0 PHY driver"
depends on HAS_IOMEM
+ depends on USB_EHCI_EXYNOS || USB_OHCI_EXYNOS || USB_DWC2
select GENERIC_PHY
select MFD_SYSCON
+ default ARCH_EXYNOS
help
Enable this to support the Samsung USB 2.0 PHY driver for Samsung
- SoCs. This driver provides the interface for USB 2.0 PHY. Support for
- particular SoCs has to be enabled in addition to this driver. Number
- and type of supported phys depends on the SoC.
+ SoCs. This driver provides the interface for USB 2.0 PHY. Support
+ for particular PHYs will be enabled based on the SoC type in addition
+ to this driver.
+config PHY_S5PV210_USB2
+ bool "Support for S5PV210"
+ depends on PHY_SAMSUNG_USB2
+ depends on ARCH_S5PV210
+ help
+ Enable USB PHY support for S5PV210. This option requires that Samsung
+ USB 2.0 PHY driver is enabled and means that support for this
+ particular SoC is compiled in the driver. In case of S5PV210 two phys
+ are available - device and host.
+
config PHY_EXYNOS4210_USB2
- bool "Support for Exynos 4210"
+ bool
depends on PHY_SAMSUNG_USB2
- depends on CPU_EXYNOS4210
- help
- Enable USB PHY support for Exynos 4210. This option requires that
- Samsung USB 2.0 PHY driver is enabled and means that support for this
- particular SoC is compiled in the driver. In case of Exynos 4210 four
- phys are available - device, host, HSIC0 and HSIC1.
+ default CPU_EXYNOS4210
config PHY_EXYNOS4X12_USB2
- bool "Support for Exynos 4x12"
+ bool
depends on PHY_SAMSUNG_USB2
- depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412)
- help
- Enable USB PHY support for Exynos 4x12. This option requires that
- Samsung USB 2.0 PHY driver is enabled and means that support for this
- particular SoC is compiled in the driver. In case of Exynos 4x12 four
- phys are available - device, host, HSIC0 and HSIC1.
+ default SOC_EXYNOS3250 || SOC_EXYNOS4212 || SOC_EXYNOS4412
config PHY_EXYNOS5250_USB2
- bool "Support for Exynos 5250"
+ bool
depends on PHY_SAMSUNG_USB2
- depends on SOC_EXYNOS5250
- help
- Enable USB PHY support for Exynos 5250. This option requires that
- Samsung USB 2.0 PHY driver is enabled and means that support for this
- particular SoC is compiled in the driver. In case of Exynos 5250 four
- phys are available - device, host, HSIC0 and HSIC.
+ default SOC_EXYNOS5250 || SOC_EXYNOS5420
config PHY_EXYNOS5_USBDRD
tristate "Exynos5 SoC series USB DRD PHY driver"
@@@ -190,16 -194,18 +204,30 @@@ config PHY_XGEN
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_ST_SPEAR1310_MIPHY
+ tristate "ST SPEAR1310-MIPHY driver"
+ select GENERIC_PHY
+ help
+ Support for ST SPEAr1310 MIPHY which can be used for PCIe and SATA.
+
+config PHY_ST_SPEAR1340_MIPHY
+ tristate "ST SPEAR1340-MIPHY driver"
+ select GENERIC_PHY
+ help
+ Support for ST SPEAr1340 MIPHY which can be used for PCIe and SATA.
+
+ config PHY_QCOM_APQ8064_SATA
+ tristate "Qualcomm APQ8064 SATA SerDes/PHY driver"
+ depends on ARCH_QCOM
+ depends on HAS_IOMEM
+ depends on OF
+ select GENERIC_PHY
+
+ config PHY_QCOM_IPQ806X_SATA
+ tristate "Qualcomm IPQ806x SATA SerDes/PHY driver"
+ depends on ARCH_QCOM
+ depends on HAS_IOMEM
+ depends on OF
+ select GENERIC_PHY
+
endmenu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140724/a6029320/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: imx: Add alias for ethernet controller
From: Shawn Guo @ 2014-07-24 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140724035253.GA7484@kroah.com>
On Wed, Jul 23, 2014 at 08:52:53PM -0700, Greg KH wrote:
> On Thu, Jul 24, 2014 at 11:17:55AM +0800, Shawn Guo wrote:
> > On Thu, Jul 24, 2014 at 04:07:19AM +0200, Marek Vasut wrote:
> > > commit 22970070e027cbbb9b2878f8f7c31d0d7f29e94d upstream.
> > >
> > > Add alias for FEC ethernet on i.MX25, i.MX27, i.MX51 and i.MX53 to allow
> > > bootloaders (like U-Boot) patch-in the MAC address for FEC using this
> > > alias.
> > >
> > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > Cc: <stable@vger.kernel.org> # 3.14.x
> >
> > Since the patch is already on mainline, and the submitting target is
> > 3.14.x stable kernel, you should really send it to Greg.
>
> No, Marek did the right thing here by sending it to the stable at vger
> mailing list, never send stable patches only to me.
Oh, I did not mean sending the patch only to you, but have you on copy.
Shawn
^ permalink raw reply
* [PATCH v4 3/3] crypto: Add Allwinner Security System crypto accelerator
From: Herbert Xu @ 2014-07-24 6:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405169953-13695-4-git-send-email-clabbe.montjoie@gmail.com>
On Sat, Jul 12, 2014 at 02:59:13PM +0200, LABBE Corentin wrote:
>
> +/* sunxi_hash_init: initialize request context
> + * Activate the SS, and configure it for MD5 or SHA1
> + */
> +int sunxi_hash_init(struct ahash_request *areq)
> +{
> + const char *hash_type;
> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
> + struct sunxi_req_ctx *op = crypto_ahash_ctx(tfm);
> +
> + mutex_lock(&ss->lock);
> +
> + hash_type = crypto_tfm_alg_name(areq->base.tfm);
> +
> + op->byte_count = 0;
> + op->nbwait = 0;
> + op->waitbuf = 0;
> +
> + /* Enable and configure SS for MD5 or SHA1 */
> + if (strcmp(hash_type, "sha1") == 0)
> + op->mode = SS_OP_SHA1;
> + else
> + op->mode = SS_OP_MD5;
> +
> + writel(op->mode | SS_ENABLED, ss->base + SS_CTL);
> + return 0;
The hash driver is completely broken. You are modifying tfm
ctx data which is shared by all users of a single tfm. So
if two users conduct hashes in parallel they will step all
over each other.
Worse, the unpaired mutex_lock will quickly lead to dead locks.
You cannot assume that final will be called.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v5 1/3] arm64: ptrace: reload a syscall number after ptrace operations
From: AKASHI Takahiro @ 2014-07-24 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53D08358.4020902@amacapital.net>
On 07/24/2014 12:54 PM, Andy Lutomirski wrote:
> On 07/22/2014 02:14 AM, AKASHI Takahiro wrote:
>> Arm64 holds a syscall number in w8(x8) register. Ptrace tracer may change
>> its value either to:
>> * any valid syscall number to alter a system call, or
>> * -1 to skip a system call
>>
>> This patch implements this behavior by reloading that value into syscallno
>> in struct pt_regs after tracehook_report_syscall_entry() or
>> secure_computing(). In case of '-1', a return value of system call can also
>> be changed by the tracer setting the value to x0 register, and so
>> sys_ni_nosyscall() should not be called.
>>
>> See also:
>> 42309ab4, ARM: 8087/1: ptrace: reload syscall number after
>> secure_computing() check
>>
>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> ---
>> arch/arm64/kernel/entry.S | 2 ++
>> arch/arm64/kernel/ptrace.c | 13 +++++++++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index 5141e79..de8bdbc 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -628,6 +628,8 @@ ENDPROC(el0_svc)
>> __sys_trace:
>> mov x0, sp
>> bl syscall_trace_enter
>> + cmp w0, #-1 // skip syscall?
>> + b.eq ret_to_user
>
> Does this mean that skipped syscalls will cause exit tracing to be skipped?
Yes. (and I guess yes on arm, too)
> If so, then you risk (at least) introducing
> a nice user-triggerable OOPS if audit is enabled.
Can you please elaborate this?
Since I didn't find any definition of audit's behavior when syscall is
rewritten to -1, I thought it is reasonable to skip "exit tracing" of
"skipped" syscall.
(otherwise, "fake" seems to be more appropriate :)
-Takahiro AKASHI
> This bug existed for *years* on x86_32, and it amazes me that no one
> ever triggered it by accident. (Grr, audit.)
>
> --Andy
^ permalink raw reply
* [PATCH v5 3/3] arm64: Add seccomp support
From: AKASHI Takahiro @ 2014-07-24 5:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53D082E9.8090303@amacapital.net>
On 07/24/2014 12:52 PM, Andy Lutomirski wrote:
> On 07/22/2014 02:14 AM, AKASHI Takahiro wrote:
>> secure_computing() should always be called first in syscall_trace_enter().
>>
>> If secure_computing() returns -1, we should stop further handling. Then
>> that system call may eventually fail with a specified return value (errno),
>> be trapped or the process itself be killed depending on loaded rules.
>> In these cases, syscall_trace_enter() also returns -1, that results in
>> skiping a normal syscall handling as well as syscall_trace_exit().
>>
>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> ---
>> arch/arm64/Kconfig | 14 ++++++++++++++
>> arch/arm64/include/asm/seccomp.h | 25 +++++++++++++++++++++++++
>> arch/arm64/include/asm/unistd.h | 3 +++
>> arch/arm64/kernel/ptrace.c | 5 +++++
>> 4 files changed, 47 insertions(+)
>> create mode 100644 arch/arm64/include/asm/seccomp.h
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 3a18571..eeac003 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -32,6 +32,7 @@ config ARM64
>> select HAVE_ARCH_AUDITSYSCALL
>> select HAVE_ARCH_JUMP_LABEL
>> select HAVE_ARCH_KGDB
>> + select HAVE_ARCH_SECCOMP_FILTER
>> select HAVE_ARCH_TRACEHOOK
>> select HAVE_C_RECORDMCOUNT
>> select HAVE_DEBUG_BUGVERBOSE
>> @@ -259,6 +260,19 @@ config ARCH_HAS_CACHE_LINE_SIZE
>>
>> source "mm/Kconfig"
>>
>> +config SECCOMP
>> + bool "Enable seccomp to safely compute untrusted bytecode"
>> + ---help---
>> + This kernel feature is useful for number crunching applications
>> + that may need to compute untrusted bytecode during their
>> + execution. By using pipes or other transports made available to
>> + the process as file descriptors supporting the read/write
>> + syscalls, it's possible to isolate those applications in
>> + their own address space using seccomp. Once seccomp is
>> + enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
>> + and the task is only allowed to execute a few safe syscalls
>> + defined by each seccomp mode.
>> +
>> config XEN_DOM0
>> def_bool y
>> depends on XEN
>> diff --git a/arch/arm64/include/asm/seccomp.h b/arch/arm64/include/asm/seccomp.h
>> new file mode 100644
>> index 0000000..c76fac9
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/seccomp.h
>> @@ -0,0 +1,25 @@
>> +/*
>> + * arch/arm64/include/asm/seccomp.h
>> + *
>> + * Copyright (C) 2014 Linaro Limited
>> + * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> + *
>> + * 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.
>> + */
>> +#ifndef _ASM_SECCOMP_H
>> +#define _ASM_SECCOMP_H
>> +
>> +#include <asm/unistd.h>
>> +
>> +#ifdef CONFIG_COMPAT
>> +#define __NR_seccomp_read_32 __NR_compat_read
>> +#define __NR_seccomp_write_32 __NR_compat_write
>> +#define __NR_seccomp_exit_32 __NR_compat_exit
>> +#define __NR_seccomp_sigreturn_32 __NR_compat_rt_sigreturn
>> +#endif /* CONFIG_COMPAT */
>> +
>> +#include <asm-generic/seccomp.h>
>> +
>> +#endif /* _ASM_SECCOMP_H */
>> diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
>> index c980ab7..729c155 100644
>> --- a/arch/arm64/include/asm/unistd.h
>> +++ b/arch/arm64/include/asm/unistd.h
>> @@ -31,6 +31,9 @@
>> * Compat syscall numbers used by the AArch64 kernel.
>> */
>> #define __NR_compat_restart_syscall 0
>> +#define __NR_compat_exit 1
>> +#define __NR_compat_read 3
>> +#define __NR_compat_write 4
>> #define __NR_compat_sigreturn 119
>> #define __NR_compat_rt_sigreturn 173
>>
>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>> index 100d7d1..e477f6f 100644
>> --- a/arch/arm64/kernel/ptrace.c
>> +++ b/arch/arm64/kernel/ptrace.c
>> @@ -28,6 +28,7 @@
>> #include <linux/smp.h>
>> #include <linux/ptrace.h>
>> #include <linux/user.h>
>> +#include <linux/seccomp.h>
>> #include <linux/security.h>
>> #include <linux/init.h>
>> #include <linux/signal.h>
>> @@ -1115,6 +1116,10 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
>> saved_x0 = regs->regs[0];
>> saved_x8 = regs->regs[8];
>>
>> + if (secure_computing(regs->syscallno) == -1)
>> + /* seccomp failures shouldn't expose any additional code. */
>> + return -1;
>> +
>
> This will conflict with the fastpath stuff in Kees' tree. (Actually, it's likely to apply cleanly, but fail to
> compile.) The fix is trivial, but, given that the fastpath stuff is new, can you take a look and see if arm64 can use
> it effectively?
I will look into the code later.
> I suspect that the performance considerations are rather different on arm64 as compared to x86 (I really hope that x86
> is the only architecture with the absurd sysret vs. iret distinction), but at least the seccomp_data stuff ought to help
> anywhere. (It looks like there's a distinct fast path, too, so the two-phase thing might also be a fairly large win if
> it's supportable.)
>
> See:
>
> https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=seccomp/fastpath
>
> Also, I'll ask the usual question? What are all of the factors other than nr and args that affect syscall execution?
> What are the audit arch values? Do they match correctly?
As far as I know,
> For example, it looks like, if arm64 adds OABI support, you'll have a problem. (Note that arm currently disables audit
> and seccomp if OABI is enabled for exactly this reason.)
I don't think that arm64 will add OABI support in the future.
> Do any syscall implementations care whether the user code is LE or BE? Are the arguments encoded the same way?
when I implemented audit for arm64, the assumptions were
* If userspace is LE, then the kernel is also LE and if BE, then the kernel is BE.
* the syscall numbers and how arguments are encoded are the same btw BE and LE.
So syscall_get_arch() always return the same value.
> An arm-specific question: will there be any confusion as a result of the fact that compat syscalls seems to stick nr in
> w7, but arm64 puts them somewhere else?
I don't know, but syscall_get_arch() returns ARCH_ARM for 32-bit tasks.
Thanks,
-Takahiro AKASHI
> --Andy
^ permalink raw reply
* [PATCH v5 2/3] asm-generic: Add generic seccomp.h for secure computing mode 1
From: AKASHI Takahiro @ 2014-07-24 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5j+GuoxR5o8CZZFZAEwQA=rRwBmBM-ZDU+nFAfHoqf8z9Q@mail.gmail.com>
On 07/24/2014 01:41 PM, Kees Cook wrote:
> On Wed, Jul 23, 2014 at 8:40 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On 07/22/2014 02:14 AM, AKASHI Takahiro wrote:
>>>
>>> Those values (__NR_seccomp_*) are used solely in secure_computing()
>>> to identify mode 1 system calls. If compat system calls have different
>>> syscall numbers, asm/seccomp.h may override them.
>>>
>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
>>> ---
>>> include/asm-generic/seccomp.h | 28 ++++++++++++++++++++++++++++
>>> 1 file changed, 28 insertions(+)
>>> create mode 100644 include/asm-generic/seccomp.h
>>>
>>> diff --git a/include/asm-generic/seccomp.h b/include/asm-generic/seccomp.h
>>> new file mode 100644
>>> index 0000000..5e97022
>>> --- /dev/null
>>> +++ b/include/asm-generic/seccomp.h
>>> @@ -0,0 +1,28 @@
>>> +/*
>>> + * include/asm-generic/seccomp.h
>>> + *
>>> + * Copyright (C) 2014 Linaro Limited
>>> + * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
>>> + *
>>> + * 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.
>>> + */
>>> +#ifndef _ASM_GENERIC_SECCOMP_H
>>> +#define _ASM_GENERIC_SECCOMP_H
>>> +
>>> +#include <asm-generic/unistd.h>
>>> +
>>> +#if defined(CONFIG_COMPAT) && !defined(__NR_seccomp_read_32)
>>> +#define __NR_seccomp_read_32 __NR_read
>>> +#define __NR_seccomp_write_32 __NR_write
>>> +#define __NR_seccomp_exit_32 __NR_exit
>>> +#define __NR_seccomp_sigreturn_32 __NR_rt_sigreturn
>>> +#endif /* CONFIG_COMPAT && ! already defined */
>>> +
>>> +#define __NR_seccomp_read __NR_read
>>> +#define __NR_seccomp_write __NR_write
>>> +#define __NR_seccomp_exit __NR_exit
>>> +#define __NR_seccomp_sigreturn __NR_rt_sigreturn
>>
>>
>> I don't like these names. __NR_seccomp_read sounds like the number of a
>> syscall called seccomp_read.
>>
>> Also, shouldn't something be including this header? I'm confused.
>
> Ah! Good catch. These names are correct (see kernel/seccomp.c's
> mode1_syscalls and mode1_syscalls_32 arrays), but the location of this
> change was unexpected. I was expecting this file to live in
> arch/*/include/asm/seccomp.h, not in include/asm-generic/seccomp.h.
>
> However, since it's always the same list, it might make sense to
> consolidate them into a single place as a default to make arch porting
> easier.
Yeah, that is why I put this file under include/asm-generic.
> However, I think that should be a separate patch.
Do you mean that the code for all the existing archs should also be changed
to use this (common) header?
-Takahiro AKASHI
>
> -Kees
>
^ permalink raw reply
* [PATCH] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
From: Viresh Kumar @ 2014-07-24 5:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53D07737.70904@codeaurora.org>
On 24 July 2014 08:32, Saravana Kannan <skannan@codeaurora.org> wrote:
> Ok, I think I've figured this out. But one question. Is it possible to
> physically remove one CPU in a bunch of "related cpus" without also
> unplugging the rest? Put another way, can you unplug one core from a
> cluster?
Are we talking about doing this here:
echo 0 > /sys/devices/system/cpu/cpuX/online ??
If yes, then what's the confusion all about? Yes we do it all the time.
^ permalink raw reply
* [PATCH 00/14] arm64: eBPF JIT compiler
From: Z Lim @ 2014-07-24 4:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723103219.GA1366@localhost>
On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote:
>> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
[...]
>> >> This series applies against net-next and is tested working
>> >> with lib/test_bpf on ARMv8 Foundation Model.
>> >
>> > Looks like it works on my Juno board too, so:
>> >
>> > Acked-by: Will Deacon <will.deacon@arm.com>
>> >
>> > for the series.
>> >
>> > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which
>> > also means the dependency on -next isn't an issue). Perhaps you could repost
>> > around -rc3?
>>
>> Thanks for testing! Nice to see it working on real hw.
>> I'm not sure why you're proposing a 4+ week delay. The patches
>> will rot instead of getting used and tested. Imo it makes sense to
>> get them into net-next now for 3.17.
>> JIT is disabled by sysctl by default anyway.
>
> We normally like some patches (especially new functionality) to sit in
> linux-next for a while before the mering window (ideally starting with
> -rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17
> merging window.
>
> Another aspect is that the arm64/bpf branch depends on the net tree, so
> it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a
> problem).
Hi Catalin, I take it you prefer this series going through arm64 tree,
targeting 3.18, is that right?
I understand your preference to have it sitting in linux-next for a
longer period for arm64 material, I'll repost this again after 3.17 so
it gets more exposure in linux-next.
BTW, are you open to this series going through net tree? I'm
(preemptively) asking because during development of this series, I've
had to rebase a couple times against net-next to handle dependencies.
Or is the general practice to handle conflicts in linux-next itself?
>
> --
> Catalin
^ permalink raw reply
* DMA engine API issue (was: [PATCH/RFC 0/5] R-Car Gen2 DMAC hardware descriptor list support)
From: Vinod Koul @ 2014-07-24 4:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vbqna699.wl%kuninori.morimoto.gx@gmail.com>
On Wed, Jul 23, 2014 at 06:35:17PM -0700, Kuninori Morimoto wrote:
>
> Hi Laurent again
>
> > > > The rsnd_soc_dai_trigger() function takes a spinlock, making the context
> > > > atomic, which regmap doesn't like as it locks a mutex.
> > > >
> > > > It might be possible to fix this by setting the fast_io field in both the
> > > > regmap_config and regmap_bus structures in sound/soc/sh/rcar/gen.c. regmap
> > > > will then use a spinlock instead of a mutex. However, even if I believe that
> > > > change makes sense and should be done, another atomic context issue will
> > > > come from the rcar-dmac driver which allocates memory in the
> > > > prep_dma_cyclic function, called by rsnd_dma_start() from
> > > > rsnd_soc_dai_trigger() with the spinlock help.
> > > >
> > > > What context is the rsnd_soc_dai_trigger() function called in by the alsa
> > > > core ? If it's guaranteed to be a sleepable context, would it make sense to
> > > > replace the rsnd_priv spinlock with a mutex ?
> > >
> > > Answering myself here, that's not an option, as the trigger function is called
> > > in atomic context (replacing the spinlock with a mutex produced a clear BUG)
> > > due to snd_pcm_lib_write1() taking a spinlock.
> > >
> > > Now we have a core issue. On one side there's rsnd_soc_dai_trigger() being
> > > called in atomic context, and on the other side the function ends up calling
> > > dmaengine_prep_dma_cyclic() which needs to allocate memory. To make this more
> > > func the DMA engine API is undocumented and completely silent on whether the
> > > prep functions are allowed to sleep. The question is, who's wrong ?
> > >
> > > Now, if you're tempted to say that I'm wrong by allocating memory with
> > > GFP_KERNEL in the DMA engine driver, please read on first :-) I've tried
> > > replacing GFP_KERNEL with GFP_ATOMIC allocations, and then ran into a problem
> > > more complex to solve.
> > >
> > > The rcar-dmac DMA engine driver uses runtime PM. When not used, the device is
> > > suspended. The driver calls pm_runtime_get_sync() to resume the device, and
> > > needs to do so when a descriptor is submitted. This operation, currently
> > > performed in the tx_submit handler, could be moved to the prep_dma_cyclic or
> > > issue_pending handler, but the three operations are called in a row from
> > > rsnd_dma_start(), itself ultimately called from snd_pcm_lib_write1() with the
> > > spinlock held. This means I have no place in my DMA engine driver where I can
> > > resume the device.
> > >
> > > One could argue that the rcar-dmac driver could use a work queue to handle
> > > power management. That's correct, but the additional complexity, which would
> > > be required in *all* DMA engine drivers, seem too high to me. If we need to go
> > > that way, this is really a task that the DMA engine core should handle.
> > >
> > > Let's start by answering the background question and updating the DMA engine
> > > API documentation once and for good : in which context are drivers allowed to
> > > call the prep, tx_submit and issue_pending functions ?
> >
> > rsnd driver (and sound/soc/sh/fsi driver too) is using prep_dma_cyclic() now,
> > but, it had been used prep_slave_single() before.
> > Then, it used work queue in dai_trigger function.
> > How about to use same method in prep_dma_cyclic() ?
> > Do you think your issue will be solved if sound driver calls prep_dma_cyclic()
> > from work queue ?
>
> Sorry, this doesn't solve issue.
> dmaengine_prep_dma_cyclic() is used in
> ${LINUX}/sound/core/pcm_dmaengine.c,
> and the situation is same as ours.
>
> Hmm..
> In my quick check, other DMAEngine drivers are using GFP_ATOMIC
> in cyclic/prep_slave_sg functions...
And thats partially right. You need to use GFP_NOWAIT.
--
~Vinod
^ permalink raw reply
* DMA engine API issue (was: [PATCH/RFC 0/5] R-Car Gen2 DMAC hardware descriptor list support)
From: Vinod Koul @ 2014-07-24 4:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28702317.aD0C1Ga3DS@avalon>
On Wed, Jul 23, 2014 at 01:07:43PM +0200, Laurent Pinchart wrote:
> > The rsnd_soc_dai_trigger() function takes a spinlock, making the context
> > atomic, which regmap doesn't like as it locks a mutex.
> >
> > It might be possible to fix this by setting the fast_io field in both the
> > regmap_config and regmap_bus structures in sound/soc/sh/rcar/gen.c. regmap
> > will then use a spinlock instead of a mutex. However, even if I believe that
> > change makes sense and should be done, another atomic context issue will
> > come from the rcar-dmac driver which allocates memory in the
> > prep_dma_cyclic function, called by rsnd_dma_start() from
> > rsnd_soc_dai_trigger() with the spinlock help.
> >
> > What context is the rsnd_soc_dai_trigger() function called in by the alsa
> > core ? If it's guaranteed to be a sleepable context, would it make sense to
> > replace the rsnd_priv spinlock with a mutex ?
>
> Answering myself here, that's not an option, as the trigger function is called
> in atomic context (replacing the spinlock with a mutex produced a clear BUG)
> due to snd_pcm_lib_write1() taking a spinlock.
>
> Now we have a core issue. On one side there's rsnd_soc_dai_trigger() being
> called in atomic context, and on the other side the function ends up calling
> dmaengine_prep_dma_cyclic() which needs to allocate memory. To make this more
> func the DMA engine API is undocumented and completely silent on whether the
> prep functions are allowed to sleep. The question is, who's wrong ?
>
> Now, if you're tempted to say that I'm wrong by allocating memory with
> GFP_KERNEL in the DMA engine driver, please read on first :-) I've tried
> replacing GFP_KERNEL with GFP_ATOMIC allocations, and then ran into a problem
> more complex to solve.
>
> The rcar-dmac DMA engine driver uses runtime PM. When not used, the device is
> suspended. The driver calls pm_runtime_get_sync() to resume the device, and
> needs to do so when a descriptor is submitted. This operation, currently
> performed in the tx_submit handler, could be moved to the prep_dma_cyclic or
> issue_pending handler, but the three operations are called in a row from
> rsnd_dma_start(), itself ultimately called from snd_pcm_lib_write1() with the
> spinlock held. This means I have no place in my DMA engine driver where I can
> resume the device.
>
> One could argue that the rcar-dmac driver could use a work queue to handle
> power management. That's correct, but the additional complexity, which would
> be required in *all* DMA engine drivers, seem too high to me. If we need to go
> that way, this is really a task that the DMA engine core should handle.
>
> Let's start by answering the background question and updating the DMA engine
> API documentation once and for good : in which context are drivers allowed to
> call the prep, tx_submit and issue_pending functions ?
I think this was bought up sometime back and we have cleared that all
_prep functions can be invoked in atomic context.
This is the reason why we have been pushing folks to use GFP_NOWAIT is
memory allocations during prepare.
Thanks for pointing out documentation doesn't say so, will send a patch for
that.
On issue_pending and tx_submit, yes these should be allowed to be called
from atomic context too.
Lastly, just to clarify the callback invoked after descriptor is complete
can also be used to submit new descriptors, so folks are dropping locking
before invoking the callback
HTH
--
~Vinod
^ permalink raw reply
* [PATCH v5 2/3] asm-generic: Add generic seccomp.h for secure computing mode 1
From: Kees Cook @ 2014-07-24 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53D0802A.7070703@amacapital.net>
On Wed, Jul 23, 2014 at 8:40 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On 07/22/2014 02:14 AM, AKASHI Takahiro wrote:
>>
>> Those values (__NR_seccomp_*) are used solely in secure_computing()
>> to identify mode 1 system calls. If compat system calls have different
>> syscall numbers, asm/seccomp.h may override them.
>>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> ---
>> include/asm-generic/seccomp.h | 28 ++++++++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>> create mode 100644 include/asm-generic/seccomp.h
>>
>> diff --git a/include/asm-generic/seccomp.h b/include/asm-generic/seccomp.h
>> new file mode 100644
>> index 0000000..5e97022
>> --- /dev/null
>> +++ b/include/asm-generic/seccomp.h
>> @@ -0,0 +1,28 @@
>> +/*
>> + * include/asm-generic/seccomp.h
>> + *
>> + * Copyright (C) 2014 Linaro Limited
>> + * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> + *
>> + * 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.
>> + */
>> +#ifndef _ASM_GENERIC_SECCOMP_H
>> +#define _ASM_GENERIC_SECCOMP_H
>> +
>> +#include <asm-generic/unistd.h>
>> +
>> +#if defined(CONFIG_COMPAT) && !defined(__NR_seccomp_read_32)
>> +#define __NR_seccomp_read_32 __NR_read
>> +#define __NR_seccomp_write_32 __NR_write
>> +#define __NR_seccomp_exit_32 __NR_exit
>> +#define __NR_seccomp_sigreturn_32 __NR_rt_sigreturn
>> +#endif /* CONFIG_COMPAT && ! already defined */
>> +
>> +#define __NR_seccomp_read __NR_read
>> +#define __NR_seccomp_write __NR_write
>> +#define __NR_seccomp_exit __NR_exit
>> +#define __NR_seccomp_sigreturn __NR_rt_sigreturn
>
>
> I don't like these names. __NR_seccomp_read sounds like the number of a
> syscall called seccomp_read.
>
> Also, shouldn't something be including this header? I'm confused.
Ah! Good catch. These names are correct (see kernel/seccomp.c's
mode1_syscalls and mode1_syscalls_32 arrays), but the location of this
change was unexpected. I was expecting this file to live in
arch/*/include/asm/seccomp.h, not in include/asm-generic/seccomp.h.
However, since it's always the same list, it might make sense to
consolidate them into a single place as a default to make arch porting
easier. However, I think that should be a separate patch.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* [PATCH] ARM: dts: imx: Add alias for ethernet controller
From: Marek Vasut @ 2014-07-24 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140724035253.GA7484@kroah.com>
On Thursday, July 24, 2014 at 05:52:53 AM, Greg KH wrote:
> On Thu, Jul 24, 2014 at 11:17:55AM +0800, Shawn Guo wrote:
> > On Thu, Jul 24, 2014 at 04:07:19AM +0200, Marek Vasut wrote:
> > > commit 22970070e027cbbb9b2878f8f7c31d0d7f29e94d upstream.
> > >
> > > Add alias for FEC ethernet on i.MX25, i.MX27, i.MX51 and i.MX53 to
> > > allow bootloaders (like U-Boot) patch-in the MAC address for FEC using
> > > this alias.
> > >
> > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > Cc: <stable@vger.kernel.org> # 3.14.x
> >
> > Since the patch is already on mainline, and the submitting target is
> > 3.14.x stable kernel, you should really send it to Greg.
>
> No, Marek did the right thing here by sending it to the stable at vger
> mailing list, never send stable patches only to me.
Whew, I was really worried I messed the submission up. Thank you for confirming
this is the right way to do it.
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v5 0/2] i2c: add DMA support for freescale i2c driver
From: Marek Vasut @ 2014-07-24 4:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5547e015bf6447e9b4fc18e82ddce74@BL2PR03MB338.namprd03.prod.outlook.com>
On Thursday, July 24, 2014 at 05:36:34 AM, Yao Yuan wrote:
> Hi,
>
> Marek Vasut wrote:
> > On Wednesday, July 23, 2014 at 10:24:41 AM, Yuan Yao wrote:
> > > Changed in v5:
> > > - add "*chan_dev = dma->chan_using->device->dev" for reduce the call
> > > time.
> >
> > Did you check if the compiler generates different code ?
>
> Sorry, I didn't compare the assembly code. It's a subtle change.
> As you mentioned the "noodle" before.
>
> Old:
> dma_map_single(dma->chan_using->device->dev, ...);
> dma_mapping_error(dma->chan_using->device->dev, ...);
> dma_unmap_single(dma->chan_using->device->dev, ...);
>
> New:
> struct device *chan_dev = dma->chan_using->device->dev;
> dma_map_single(chan_dev, ...);
> dma_mapping_error(chan_dev, ...);
> dma_unmap_single(chan_dev, ...);
You should not use optimization and code cleanup interchangably. Thanks for
clarifying what this is.
Best regards,
Marek Vasut
^ 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