* Re: [PATCH 2/3] pwm: Add PWM driver for Intel Keem Bay
From: Uwe Kleine-König @ 2020-05-23 21:40 UTC (permalink / raw)
To: vineetha.g.jaya.kumaran
Cc: thierry.reding, robh+dt, linux-pwm, devicetree,
wan.ahmad.zainie.wan.mohamad, andriy.shevchenko
In-Reply-To: <1589723560-5734-3-git-send-email-vineetha.g.jaya.kumaran@intel.com>
Hello,
On Sun, May 17, 2020 at 09:52:39PM +0800, vineetha.g.jaya.kumaran@intel.com wrote:
> From: "Lai, Poey Seng" <poey.seng.lai@intel.com>
>
> Enable PWM support for the Intel Keem Bay SoC.
>
> Signed-off-by: Lai, Poey Seng <poey.seng.lai@intel.com>
> Signed-off-by: Vineetha G. Jaya Kumaran <vineetha.g.jaya.kumaran@intel.com>
> ---
> drivers/pwm/Kconfig | 9 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-keembay.c | 308 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 318 insertions(+)
> create mode 100644 drivers/pwm/pwm-keembay.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index c13d146..5311975 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -569,4 +569,13 @@ config PWM_ZX
> To compile this driver as a module, choose M here: the module
> will be called pwm-zx.
>
> +config PWM_KEEMBAY
> + tristate "Intel Keem Bay PWM driver"
> + depends on ARM64
Support for COMPILE_TEST would be nice here.
> + help
> + The platform driver for Intel Keem Bay PWM controller.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-keembay.
> +
> endif
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index a59c710..0c84ff2 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -55,3 +55,4 @@ obj-$(CONFIG_PWM_TWL) += pwm-twl.o
> obj-$(CONFIG_PWM_TWL_LED) += pwm-twl-led.o
> obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
> obj-$(CONFIG_PWM_ZX) += pwm-zx.o
> +obj-$(CONFIG_PWM_KEEMBAY) += pwm-keembay.o
> diff --git a/drivers/pwm/pwm-keembay.c b/drivers/pwm/pwm-keembay.c
> new file mode 100644
> index 0000000..39c7310
> --- /dev/null
> +++ b/drivers/pwm/pwm-keembay.c
> @@ -0,0 +1,308 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Intel Keem Bay PWM driver
> + *
> + * Copyright (C) 2020 Intel Corporation
> + * Authors: Lai Poey Seng <poey.seng.lai@intel.com>
> + * Vineetha G. Jaya Kumaran <vineetha.g.jaya.kumaran@intel.com>
Is there publically available documentation? If so, please add a link
here.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/regmap.h>
> +
> +#define TOTAL_PWM_CHANNELS 6
> +#define LEAD_IN_DEFAULT 0
> +#define PWM_COUNT_MAX 65535
please use a unique prefix for all defines in your driver. The names as
they are are too generic.
> +
> +#define KEEMBAY_PWM_EN_BIT 31
> +
> +/* Mask */
> +#define KEEMBAY_PWM_RPT_CNT_MASK GENMASK(15, 0)
> +#define KEEMBAY_PWM_LEAD_IN_MASK GENMASK(30, 16)
> +#define KEEMBAY_PWM_HIGH_MASK GENMASK(31, 16)
> +#define KEEMBAY_PWM_LOW_MASK GENMASK(15, 0)
> +
> +/* PWM Register offset */
> +#define PWM_LEADIN0_OFFSET 0x00
> +#define PWM_LEADIN1_OFFSET 0x04
> +#define PWM_LEADIN2_OFFSET 0x08
> +#define PWM_LEADIN3_OFFSET 0x0c
> +#define PWM_LEADIN4_OFFSET 0x10
> +#define PWM_LEADIN5_OFFSET 0x14
> +
> +#define PWM_HIGHLOW0_OFFSET 0x20
> +#define PWM_HIGHLOW1_OFFSET 0x24
> +#define PWM_HIGHLOW2_OFFSET 0x28
> +#define PWM_HIGHLOW3_OFFSET 0x2c
> +#define PWM_HIGHLOW4_OFFSET 0x30
> +#define PWM_HIGHLOW5_OFFSET 0x34
> +
> +struct keembay_pwm {
> + struct pwm_chip chip;
> + struct device *dev;
> + struct clk *clk;
> + void __iomem *regmap;
I'd call this member "base" instead of "regmap" as the latter has a
different meaning in the kernel.
> +};
> +
> +static inline struct keembay_pwm *to_keembay_pwm_dev(struct pwm_chip *chip)
> +{
> + return container_of(chip, struct keembay_pwm, chip);
> +}
> +
> +static inline void keembay_pwm_enable_channel(struct keembay_pwm *priv, int ch)
> +{
> + u32 buff, offset;
> + void __iomem *address;
> +
> + offset = PWM_LEADIN0_OFFSET + ch * 4;
> + address = priv->regmap + offset;
> + buff = readl(address);
> + buff |= BIT(KEEMBAY_PWM_EN_BIT);
> + writel(buff, address);
> +}
> +
> +static inline void keembay_pwm_disable_channel(struct keembay_pwm *priv, int ch)
> +{
> + u32 buff, offset;
> + void __iomem *address;
> +
> + offset = PWM_LEADIN0_OFFSET + ch * 4;
> + address = priv->regmap + offset;
> + buff = readl(address);
> + buff &= ~BIT(KEEMBAY_PWM_EN_BIT);
> + writel(buff, address);
> +}
The two functions above could make use of keembay_pwm_update_bits().
> +
> +static inline void keembay_pwm_update_bits(struct keembay_pwm *priv, u32 mask,
> + u32 val, u32 reg, int ch)
> +{
> + u32 buff, offset, tmp;
> + void __iomem *address;
> +
> + offset = reg + ch * 4;
> + address = priv->regmap + offset;
> + buff = readl(address);
> + tmp = buff & ~mask;
> + tmp |= FIELD_PREP(mask, val);
> + writel(tmp, address);
> +}
> +
> +static inline u32 keembay_pwm_config_min(struct keembay_pwm *priv)
> +{
> + unsigned long long divd, divs;
> +
> + divd = NSEC_PER_SEC;
> + divs = clk_get_rate(priv->clk);
> + do_div(divd, divs);
Given that both NSEC_PER_SEC and the return value of clk_get_rate fit
into an unsigned long, this seems too much.
> + return (u32)divd;
> +}
> +
> +static inline u16 keembay_pwm_config_duty_cycle(struct keembay_pwm *priv,
> + int duty_ns, u32 ns_min)
> +{
> + unsigned long long divd;
> +
> + divd = duty_ns;
> + do_div(divd, ns_min);
> + if ((u16)divd == 0)
> + return 0;
> +
> + return (u16)divd - 1;
missing range checking.
> +}
> +
> +static inline u16 keembay_pwm_config_period(struct keembay_pwm *priv,
> + int period_ns,
> + int duty_ns,
> + u32 ns_min)
> +{
> + unsigned long long divd;
> +
> + divd = period_ns - duty_ns;
> + do_div(divd, ns_min);
> + if ((u16)divd == 0)
> + return 0;
> +
> + return (u16)divd - 1;
I wonder if both keembay_pwm_config_duty_cycle() and
keembay_pwm_config_period() would be easier to understand if they were not
separate functions but unrolled into their only user.
As above there is no range checking.
> +}
> +
> +/*
> + * For calculating "high time" register value:
> + * High time (quotient only) = duty_cycle / ns_min
> + *
> + * For calculating "low time" register value:
> + * Low time (quotient only) = (period - duty_cycle) / ns_min
> + *
> + * All values used are in nanoseconds for calculation.
> + */
> +static int keembay_pwm_config(struct keembay_pwm *priv, int ch,
> + int duty_ns, int period_ns, int count)
this function is only called once, I wonder if it can better be folded
into its only user.
> +{
> + u32 ns_min;
> + u16 pwm_h_count, pwm_l_count;
> +
> + /* Write to lead in */
> + keembay_pwm_update_bits(priv, KEEMBAY_PWM_LEAD_IN_MASK,
> + LEAD_IN_DEFAULT,
> + PWM_LEADIN0_OFFSET, ch);
What is the effect of this "lead in"?
> + /* Write the number of PWM pulse repetition */
> + keembay_pwm_update_bits(priv, KEEMBAY_PWM_RPT_CNT_MASK, count,
> + PWM_LEADIN0_OFFSET, ch);
Is this racy? E.g. if the PWM is already running and just after you
update the repetition count completes a period?
This writes to the same register as the lead in above. Can this be done
in a single register access?
> + /* Calculate min */
> + ns_min = keembay_pwm_config_min(priv);
What is "min"?
> + /* For duty cycle */
> + pwm_h_count = keembay_pwm_config_duty_cycle(priv, duty_ns, ns_min);
this is ineffective and less exact as possible. ns_min is the result of
a division and in keembay_pwm_config_duty_cycle you divide by it.
> + /* Write to high registers */
> + keembay_pwm_update_bits(priv, KEEMBAY_PWM_HIGH_MASK, pwm_h_count,
> + PWM_HIGHLOW0_OFFSET, ch);
> +
> + /* For period */
> + pwm_l_count = keembay_pwm_config_period(priv, period_ns, duty_ns,
> + ns_min);
> +
> + /* Write to low registers */
> + keembay_pwm_update_bits(priv, KEEMBAY_PWM_LOW_MASK, pwm_l_count,
> + PWM_HIGHLOW0_OFFSET, ch);
Can you please explain in a comment what's the resulting wave form for a
given value of this register?
Can writing h_count and l_count be combined in a single register access?
(And if not, what happens if a period completes between the two
updates?)
How does the hardware behave on a change here? Is the currently running
period completed before the new values take effect?
> +
> + return 0;
> +}
> +
> +static int keembay_pwm_enable(struct keembay_pwm *priv, int ch)
> +{
> + int ret;
> +
> + ret = clk_enable(priv->clk);
> + if (ret)
> + return ret;
> +
> + /* Enable channel */
> + keembay_pwm_enable_channel(priv, ch);
> +
> + return 0;
> +}
> +
> +static void keembay_pwm_disable(struct keembay_pwm *priv, int ch)
> +{
> + /* Disable channel */
> + keembay_pwm_disable_channel(priv, ch);
> +
> + clk_disable(priv->clk);
> +}
> +
> +static int keembay_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct keembay_pwm *priv = to_keembay_pwm_dev(chip);
> +
> + if (!state->enabled && pwm_is_enabled(pwm)) {
Please don't call API functions in the driver.
> + keembay_pwm_disable(priv, pwm->hwpwm);
Is a currently running period completed here? How does the output behave
on disable? (i.e. does it go in its inactive state?)
> + return 0;
> + }
> +
> + if (state->count > PWM_COUNT_MAX)
> + return -EINVAL;
> +
> + if (state->polarity != pwm_get_polarity(pwm))
Using:
if (state->polarity != PWM_POLARITY_NORMAL)
seems both more robust and easier to understand.
> + return -ENOSYS;
> +
> + keembay_pwm_config(priv, pwm->hwpwm, state->duty_cycle,
> + state->period, state->count);
> +
> + if (state->enabled && !pwm_is_enabled(pwm))
> + return keembay_pwm_enable(priv, pwm->hwpwm);
> +
> + return 0;
> +}
> +
> +static const struct pwm_ops keembay_pwm_ops = {
> + .owner = THIS_MODULE,
> + .apply = keembay_pwm_apply,
Please implement .get_state().
> +};
> +
> +static int keembay_pwm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct keembay_pwm *priv;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(priv->clk))
Error message please. (Something like:
int ret = PTR_ERR(ret);
if (ret != -EPROBE_DEFER)
dev_err(pdev->dev, "Failed to get clk: %pE\n", priv->clk);
return ret;
)
> + return PTR_ERR(priv->clk);
> +
> + /*
> + * Prepare clock here, and carry out clock enabling/disabling
> + * during channel enablement/disablement.
> + * The clock will not be unprepared due to shared usage with GPIO.
What has this clock to do with GPIO? If the GPIO drivers gets and
enables this clock itself there should be no problem.
> + */
> + ret = clk_prepare(priv->clk);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to prepare PWM clock\n");
Please include the error code in the message (preferably using %pE as
above).
> + return ret;
> + }
> +
> + priv->regmap = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(priv->regmap))
> + return PTR_ERR(priv->regmap);
> +
> + priv->chip.base = -1;
> + priv->chip.dev = dev;
> + priv->chip.ops = &keembay_pwm_ops;
> + priv->chip.npwm = TOTAL_PWM_CHANNELS;
> +
> + ret = pwmchip_add(&priv->chip);
> + if (ret < 0) {
> + dev_err(dev, "Failed to add PWM chip: %d\n", ret);
%pE please.
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, priv);
> +
> + return 0;
> +}
> +
> +static int keembay_pwm_remove(struct platform_device *pdev)
> +{
> + struct keembay_pwm *priv = platform_get_drvdata(pdev);
> + unsigned int i;
> +
> + for (i = 0; i < priv->chip.npwm; i++)
> + pwm_disable(&priv->chip.pwms[i]);
That's wrong. It's the responsibility of the consumer to disable the
clock.
> +
> + pwmchip_remove(&priv->chip);
clk_unprepare missing here.
> +
> + return 0;
> +}
> +
> +static const struct of_device_id keembay_pwm_of_match[] = {
> + { .compatible = "intel,keembay-pwm" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, keembay_pwm_of_match);
> +
> +static struct platform_driver keembay_pwm_driver = {
> + .probe = keembay_pwm_probe,
> + .remove = keembay_pwm_remove,
> + .driver = {
> + .name = "pwm-keembay",
> + .of_match_table = keembay_pwm_of_match,
> + },
> +};
> +module_platform_driver(keembay_pwm_driver);
> +
> +MODULE_ALIAS("platform:keembay");
> +MODULE_DESCRIPTION("Intel Keem Bay PWM driver");
> +MODULE_LICENSE("GPL v2");
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-05-23 21:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, hkallweit1, davem, robh, netdev, linux-kernel,
devicetree
In-Reply-To: <20200523150951.GK610998@lunn.ch>
Andrew
On 5/23/20 10:09 AM, Andrew Lunn wrote:
>>>> + dp83869->tx_id_delay = DP83869_RGMII_CLK_DELAY_INV;
>>>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
>>>> + &dp83869->tx_id_delay);
>>>> + if (!ret && dp83869->tx_id_delay > dp83869_internal_delay[delay_size]) {
>>>> + phydev_err(phydev,
>>>> + "tx-internal-delay value of %u out of range\n",
>>>> + dp83869->tx_id_delay);
>>>> + return -EINVAL;
>>>> + }
>>> This is the kind of validation that I would be expecting from the PHY
>>> library to do, in fact, since you use Device Tree standard property, I
>>> would expect you only need to pass the maximum delay value and some
>>> storage for your array of delays.
>> Actually the PHY library will return either the 0th index if the value is to
>> small or the max index if the value is to large
>>
>> based on the array passed in so maybe this check is unnecessary.
> Hi Dan
>
> I'm not sure the helper is implementing the best behaviour. Rounded to
> the nearest when within the supported range is O.K. But if the request
> is outside the range, i would report an error.
Hope this email does not bounce.
> Any why is your PHY special, in that is does care about out of range
> delays, when others using new the new core helper don't?
We are not rounding to nearest here. Basically the helper works to find
the best match
If the delay passed in is less than or equal to the smallest delay then
return the smallest delay index
If the delay passed in is greater then the largest delay then return the
max delay index
Not sure what you mean about this PHY being special. This helper is not
PHY specific.
After I think about this more I am thinking a helper may be over kill
here and the delay to setting should be done within the PHY driver itself
Dan
> Andrew
^ permalink raw reply
* Re: [PATCH 1/3] pwm: Add count attribute in sysfs for Intel Keem Bay
From: Uwe Kleine-König @ 2020-05-23 21:05 UTC (permalink / raw)
To: vineetha.g.jaya.kumaran
Cc: thierry.reding, robh+dt, linux-pwm, devicetree,
wan.ahmad.zainie.wan.mohamad, andriy.shevchenko
In-Reply-To: <1589723560-5734-2-git-send-email-vineetha.g.jaya.kumaran@intel.com>
On Sun, May 17, 2020 at 09:52:38PM +0800, vineetha.g.jaya.kumaran@intel.com wrote:
> From: "Lai, Poey Seng" <poey.seng.lai@intel.com>
>
> In Keem Bay, the number of repetitions for the period/waveform
> can be configured from userspace. This requires addition of a sysfs
> attribute to get/set the repetition count. Setting this value to 0
> will result in continuous repetition of the waveform until the
> channel is disabled or reconfigured.
There is nothing specific for Keem Bay in this patch, the only special
thing here is that this driver is the first implementor.
IMHO all drivers that don't support count should be changed to fail if
a count > 0 is passed and introducing support in the sysfs interface
should be a separate change.
Having said that I'm not convinced this is a good idea given that only
very few driver can support this interface. Also this needs
documentation, e.g. what is expected from .get_state().
You should also motivate what this functionality is used for in the
commit log and I'd prefer to see an in-tree user (apart from sysfs which
I don't count as such).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] dt-bindings: dma: uart: mtk: fix example
From: matthias.bgg @ 2020-05-23 20:15 UTC (permalink / raw)
To: sean.wang, vkoul, robh+dt
Cc: matthias.bgg, dmaengine, linux-arm-kernel, linux-mediatek,
devicetree, linux-kernel, Matthias Brugger
From: Matthias Brugger <mbrugger@suse.com>
The binding example is missing the fallback compatible.
This is needed as the driver only matches against mt6577.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
---
Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
index 5d6f98c43e3d..2117db0ce4f2 100644
--- a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
+++ b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
@@ -21,7 +21,8 @@ Required properties:
Examples:
apdma: dma-controller@11000400 {
- compatible = "mediatek,mt2712-uart-dma";
+ compatible = "mediatek,mt2712-uart-dma",
+ "mediatek,mt6577-uart-dma";
reg = <0 0x11000400 0 0x80>,
<0 0x11000480 0 0x80>,
<0 0x11000500 0 0x80>,
--
2.26.2
^ permalink raw reply related
* Re: [PATCH V3] arm64: dts: mediatek: add cpufreq and cci devfreq nodes for mt8183
From: Matthias Brugger @ 2020-05-23 19:04 UTC (permalink / raw)
To: Andrew-sh.Cheng, Rob Herring, Mark Rutland, devicetree
Cc: linux-arm-kernel, linux-mediatek, linux-kernel, srv_heupstream
In-Reply-To: <1576826785-3867-1-git-send-email-andrew-sh.cheng@mediatek.com>
On 20/12/2019 08:26, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com>
>
> add cpufreq and cci devfreq nodes for mt8183
>
> Depend on regulator node patch:
> https://patchwork.kernel.org/patch/11284617/
>
> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 36 ++++
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 245 ++++++++++++++++++++++++++++
> 2 files changed, 281 insertions(+)
>
[...]
> +
> + cci: cci {
> + compatible = "mediatek,mt8183-cci";
I wasn't able to find anyprovider for this compatible.
I'll drop this patch from my queue.
Regards,
Matthias
^ permalink raw reply
* Re: [PATCH V6 7/7] arm64: dts: sc7180: Add interconnect for QUP and QSPI
From: kbuild test robot @ 2020-05-23 14:05 UTC (permalink / raw)
To: Akash Asthana, gregkh, agross, bjorn.andersson, wsa, broonie,
mark.rutland, robh+dt
Cc: kbuild-all, clang-built-linux, linux-i2c, linux-spi, devicetree,
swboyd, mgautam, linux-arm-msm, linux-serial, mka, dianders
In-Reply-To: <1590049764-20912-8-git-send-email-akashast@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
Hi Akash,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tty/tty-testing]
[also build test ERROR on spi/for-next wsa/i2c/for-next usb/usb-testing driver-core/driver-core-testing linus/master v5.7-rc6]
[cannot apply to next-20200522]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Akash-Asthana/Add-interconnect-support-to-QSPI-and-QUP-drivers/20200521-163523
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
config: arm64-randconfig-r026-20200521 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 3393cc4cebf9969db94dc424b7a2b6195589c33b)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> Error: arch/arm64/boot/dts/qcom/sc7180.dtsi:430.31-32 syntax error
>> FATAL ERROR: Unable to parse input tree
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 42362 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sm8250: change ufs node name to ufshc
From: Jonathan Marek @ 2020-05-23 17:52 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
The ufs-qcom driver checks that the name matches the androidboot.bootdevice
parameter provided by the bootloader, which uses the name ufshc. Without
this change UFS fails to probe.
I think this is broken behavior from the ufs-qcom driver, but using the
name ufshc is consistent with dts for sdm845/sm8150/etc.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index e0344d3ba159..3bdce658c08a 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -309,7 +309,7 @@ uart2: serial@a90000 {
};
};
- ufs_mem_hc: ufs@1d84000 {
+ ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sm8250-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
reg = <0 0x01d84000 0 0x3000>;
--
2.26.1
^ permalink raw reply related
* Re: [PATCH net-next v2 1/4] dt-bindings: net: Add tx and rx internal delays
From: Andrew Lunn @ 2020-05-23 15:13 UTC (permalink / raw)
To: Dan Murphy
Cc: f.fainelli, hkallweit1, davem, robh, netdev, linux-kernel,
devicetree
In-Reply-To: <20200522122534.3353-2-dmurphy@ti.com>
On Fri, May 22, 2020 at 07:25:31AM -0500, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
>
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
> controller that the PHY will add the internal delay for the connection.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v2 - updated to add -ps
>
> .../bindings/net/ethernet-controller.yaml | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> index ac471b60ed6a..70702a4ef5e8 100644
> --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> @@ -143,6 +143,20 @@ properties:
> Specifies the PHY management type. If auto is set and fixed-link
> is not specified, it uses MDIO for management.
>
> + rx-internal-delay-ps:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description: |
> + RGMII Receive PHY Clock Delay defined in pico seconds. This is used for
> + PHY's that have configurable RX internal delays. This property is only
> + used when the phy-mode or phy-connection-type is rgmii-id or rgmii-rxid.
Hi Dan
Please add a comment about rounding to the nearest supported value.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: dp83869: Add RGMII internal delay configuration
From: Andrew Lunn @ 2020-05-23 15:09 UTC (permalink / raw)
To: Dan Murphy
Cc: Florian Fainelli, hkallweit1, davem, robh, netdev, linux-kernel,
devicetree
In-Reply-To: <948bfa24-97ad-ba35-f06c-25846432e506@ti.com>
> > > + dp83869->tx_id_delay = DP83869_RGMII_CLK_DELAY_INV;
> > > + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
> > > + &dp83869->tx_id_delay);
> > > + if (!ret && dp83869->tx_id_delay > dp83869_internal_delay[delay_size]) {
> > > + phydev_err(phydev,
> > > + "tx-internal-delay value of %u out of range\n",
> > > + dp83869->tx_id_delay);
> > > + return -EINVAL;
> > > + }
> > This is the kind of validation that I would be expecting from the PHY
> > library to do, in fact, since you use Device Tree standard property, I
> > would expect you only need to pass the maximum delay value and some
> > storage for your array of delays.
>
> Actually the PHY library will return either the 0th index if the value is to
> small or the max index if the value is to large
>
> based on the array passed in so maybe this check is unnecessary.
Hi Dan
I'm not sure the helper is implementing the best behaviour. Rounded to
the nearest when within the supported range is O.K. But if the request
is outside the range, i would report an error.
Any why is your PHY special, in that is does care about out of range
delays, when others using new the new core helper don't?
Andrew
^ permalink raw reply
* Re: [RFC PATCH net-next 4/4] net: dp83869: Add RGMII internal delay configuration
From: Andrew Lunn @ 2020-05-23 14:58 UTC (permalink / raw)
To: Dan Murphy
Cc: f.fainelli, hkallweit1, davem, robh, netdev, linux-kernel,
devicetree
In-Reply-To: <20200521174834.3234-5-dmurphy@ti.com>
On Thu, May 21, 2020 at 12:48:34PM -0500, Dan Murphy wrote:
> Add RGMII internal delay configuration for Rx and Tx.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> drivers/net/phy/dp83869.c | 101 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 101 insertions(+)
>
> diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
> index cfb22a21a2e6..40c34fefffe4 100644
> --- a/drivers/net/phy/dp83869.c
> +++ b/drivers/net/phy/dp83869.c
> @@ -99,6 +99,14 @@
> #define DP83869_OP_MODE_MII BIT(5)
> #define DP83869_SGMII_RGMII_BRIDGE BIT(6)
>
> +/* RGMIIDCTL bits */
> +#define DP83869_RGMII_TX_CLK_DELAY_SHIFT 4
> +#define DP83869_RGMII_CLK_DELAY_INV 0
> +
> +static int dp83869_internal_delay[] = {250, 500, 750, 1000, 1250, 1500, 1750,
> + 2000, 2250, 2500, 2750, 3000, 3250,
> + 3500, 3750, 4000};
> +
> enum {
> DP83869_PORT_MIRRORING_KEEP,
> DP83869_PORT_MIRRORING_EN,
> @@ -108,6 +116,8 @@ enum {
> struct dp83869_private {
> int tx_fifo_depth;
> int rx_fifo_depth;
> + u32 rx_id_delay;
> + u32 tx_id_delay;
> int io_impedance;
> int port_mirroring;
> bool rxctrl_strap_quirk;
> @@ -182,6 +192,7 @@ static int dp83869_of_init(struct phy_device *phydev)
> struct dp83869_private *dp83869 = phydev->priv;
> struct device *dev = &phydev->mdio.dev;
> struct device_node *of_node = dev->of_node;
> + int delay_size = ARRAY_SIZE(dp83869_internal_delay);
> int ret;
>
> if (!of_node)
> @@ -232,6 +243,26 @@ static int dp83869_of_init(struct phy_device *phydev)
> &dp83869->tx_fifo_depth))
> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>
> + dp83869->rx_id_delay = DP83869_RGMII_CLK_DELAY_INV;
> + ret = of_property_read_u32(of_node, "rx-internal-delay",
> + &dp83869->rx_id_delay);
> + if (!ret && dp83869->rx_id_delay > dp83869_internal_delay[delay_size]) {
> + phydev_err(phydev,
> + "rx-internal-delay value of %u out of range\n",
> + dp83869->rx_id_delay);
> + return -EINVAL;
> + }
Hi Dan
Seems like the helper should be doing the range check, and printing
the message. It should be common to all PHY drivers using delays
looked up in a list.
I also wonder about putting the of_property_read_u32 inside a
helper. Something like
of_get_phy_rgmii_delays(struct device_node *np, phy_interface_t interface,
u32 *rx_delay, u32 *tx_delay)
And maybe a third helper which combines phy_get_delay_index() and
of_get_phy_rgmii_delays().
> +static int dp83869_verify_rgmii_cfg(struct phy_device *phydev)
> +{
> + struct dp83869_private *dp83869 = phydev->priv;
> +
> + /* RX delay *must* be specified if internal delay of RX is used. */
No. As i said last time, default to 2ns, if there is no specific delay
value in DT.
Andrew
^ permalink raw reply
* Re: [PATCH v2 4/5] net: devres: provide devm_register_netdev()
From: Markus Elfring @ 2020-05-23 14:34 UTC (permalink / raw)
To: Bartosz Golaszewski, devicetree, linux-arm-kernel, linux-mediatek,
netdev
Cc: Andrew Perepech, Arnd Bergmann, Bartosz Golaszewski,
Jonathan Corbet, David S. Miller, Edwin Peer, Fabien Parent,
Heiner Kallweit, John Crispin, Jakub Kicinski, Mark Lee,
Matthias Brugger, Pedro Tsai, Sean Wang, Stephane Le Provost,
linux-kernel, kernel-janitors
…
> +++ b/net/devres.c
> @@ -38,3 +38,58 @@ struct net_device *devm_alloc_etherdev_mqs(struct device *dev, int sizeof_priv,
…
> + * This is a devres variant of register_netdev() for which the unregister
> + * function will be call automatically when the managing device is
Is the following wording variant more appropriate?
+ * function will be automatically called when the managing device is
Regards,
Markus
^ permalink raw reply
* [PATCH v2 2/5] net: move devres helpers into a separate source file
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
There's currently only a single devres helper in net/ - devm variant
of alloc_etherdev. Let's move it to net/devres.c with the intention of
assing a second one: devm_register_netdev(). This new routine will need
to know the address of the release function of devm_alloc_etherdev() so
that it can verify (using devres_find()) that the struct net_device
that's being passed to it is also resource managed.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
net/Makefile | 2 +-
net/devres.c | 36 ++++++++++++++++++++++++++++++++++++
net/ethernet/eth.c | 28 ----------------------------
3 files changed, 37 insertions(+), 29 deletions(-)
create mode 100644 net/devres.c
diff --git a/net/Makefile b/net/Makefile
index 07ea48160874..5744bf1997fd 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -6,7 +6,7 @@
# Rewritten to use lists instead of if-statements.
#
-obj-$(CONFIG_NET) := socket.o core/
+obj-$(CONFIG_NET) := devres.o socket.o core/
tmp-$(CONFIG_COMPAT) := compat.o
obj-$(CONFIG_NET) += $(tmp-y)
diff --git a/net/devres.c b/net/devres.c
new file mode 100644
index 000000000000..c1465d9f9019
--- /dev/null
+++ b/net/devres.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * This file contains all networking devres helpers.
+ */
+
+#include <linux/device.h>
+#include <linux/etherdevice.h>
+#include <linux/netdevice.h>
+
+static void devm_free_netdev(struct device *dev, void *res)
+{
+ free_netdev(*(struct net_device **)res);
+}
+
+struct net_device *devm_alloc_etherdev_mqs(struct device *dev, int sizeof_priv,
+ unsigned int txqs, unsigned int rxqs)
+{
+ struct net_device **dr;
+ struct net_device *netdev;
+
+ dr = devres_alloc(devm_free_netdev, sizeof(*dr), GFP_KERNEL);
+ if (!dr)
+ return NULL;
+
+ netdev = alloc_etherdev_mqs(sizeof_priv, txqs, rxqs);
+ if (!netdev) {
+ devres_free(dr);
+ return NULL;
+ }
+
+ *dr = netdev;
+ devres_add(dev, dr);
+
+ return netdev;
+}
+EXPORT_SYMBOL(devm_alloc_etherdev_mqs);
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index c8b903302ff2..dac65180c4ef 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -400,34 +400,6 @@ struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
}
EXPORT_SYMBOL(alloc_etherdev_mqs);
-static void devm_free_netdev(struct device *dev, void *res)
-{
- free_netdev(*(struct net_device **)res);
-}
-
-struct net_device *devm_alloc_etherdev_mqs(struct device *dev, int sizeof_priv,
- unsigned int txqs, unsigned int rxqs)
-{
- struct net_device **dr;
- struct net_device *netdev;
-
- dr = devres_alloc(devm_free_netdev, sizeof(*dr), GFP_KERNEL);
- if (!dr)
- return NULL;
-
- netdev = alloc_etherdev_mqs(sizeof_priv, txqs, rxqs);
- if (!netdev) {
- devres_free(dr);
- return NULL;
- }
-
- *dr = netdev;
- devres_add(dev, dr);
-
- return netdev;
-}
-EXPORT_SYMBOL(devm_alloc_etherdev_mqs);
-
ssize_t sysfs_format_mac(char *buf, const unsigned char *addr, int len)
{
return scnprintf(buf, PAGE_SIZE, "%*phC\n", len, addr);
--
2.25.0
^ permalink raw reply related
* [PATCH v2 5/5] net: ethernet: mtk_star_emac: use devm_register_netdev()
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Use the new devres variant of register_netdev() in the mtk-star-emac
driver and shrink the code by a couple lines.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/net/ethernet/mediatek/mtk_star_emac.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c
index 789c77af501f..b74349cede28 100644
--- a/drivers/net/ethernet/mediatek/mtk_star_emac.c
+++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
@@ -1519,13 +1519,6 @@ static void mtk_star_mdiobus_unregister(void *data)
mdiobus_unregister(priv->mii);
}
-static void mtk_star_unregister_netdev(void *data)
-{
- struct net_device *ndev = data;
-
- unregister_netdev(ndev);
-}
-
static int mtk_star_probe(struct platform_device *pdev)
{
struct device_node *of_node;
@@ -1641,15 +1634,7 @@ static int mtk_star_probe(struct platform_device *pdev)
netif_napi_add(ndev, &priv->napi, mtk_star_poll, MTK_STAR_NAPI_WEIGHT);
- ret = register_netdev(ndev);
- if (ret)
- return ret;
-
- ret = devm_add_action_or_reset(dev, mtk_star_unregister_netdev, ndev);
- if (ret)
- return ret;
-
- return 0;
+ return devm_register_netdev(dev, ndev);
}
static const struct of_device_id mtk_star_of_match[] = {
--
2.25.0
^ permalink raw reply related
* [PATCH v2 4/5] net: devres: provide devm_register_netdev()
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Provide devm_register_netdev() - a device resource managed variant
of register_netdev(). This new helper will only work for net_device
structs that are also already managed by devres.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../driver-api/driver-model/devres.rst | 1 +
include/linux/netdevice.h | 2 +
net/devres.c | 55 +++++++++++++++++++
3 files changed, 58 insertions(+)
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index 50df28d20fa7..fc242ed4bde5 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -375,6 +375,7 @@ MUX
NET
devm_alloc_etherdev()
devm_alloc_etherdev_mqs()
+ devm_register_netdev()
PER-CPU MEM
devm_alloc_percpu()
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index a18f8fdf4260..1a96e9c4ec36 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -4280,6 +4280,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
int register_netdev(struct net_device *dev);
void unregister_netdev(struct net_device *dev);
+int devm_register_netdev(struct device *dev, struct net_device *ndev);
+
/* General hardware address lists handling functions */
int __hw_addr_sync(struct netdev_hw_addr_list *to_list,
struct netdev_hw_addr_list *from_list, int addr_len);
diff --git a/net/devres.c b/net/devres.c
index b97b0c5a8216..57a6a88d11f6 100644
--- a/net/devres.c
+++ b/net/devres.c
@@ -38,3 +38,58 @@ struct net_device *devm_alloc_etherdev_mqs(struct device *dev, int sizeof_priv,
return dr->ndev;
}
EXPORT_SYMBOL(devm_alloc_etherdev_mqs);
+
+static void devm_netdev_release(struct device *dev, void *this)
+{
+ struct net_device_devres *res = this;
+
+ unregister_netdev(res->ndev);
+}
+
+static int netdev_devres_match(struct device *dev, void *this, void *match_data)
+{
+ struct net_device_devres *res = this;
+ struct net_device *ndev = match_data;
+
+ return ndev == res->ndev;
+}
+
+/**
+ * devm_register_netdev - resource managed variant of register_netdev()
+ * @dev: managing device for this netdev - usually the parent device
+ * @ndev: device to register
+ *
+ * This is a devres variant of register_netdev() for which the unregister
+ * function will be call automatically when the managing device is
+ * detached. Note: the net_device used must also be resource managed by
+ * the same struct device.
+ */
+int devm_register_netdev(struct device *dev, struct net_device *ndev)
+{
+ struct net_device_devres *dr;
+ int ret;
+
+ /* struct net_device must itself be managed. For now a managed netdev
+ * can only be allocated by devm_alloc_etherdev_mqs() so the check is
+ * straightforward.
+ */
+ if (WARN_ON(!devres_find(dev, devm_free_netdev,
+ netdev_devres_match, ndev)))
+ return -EINVAL;
+
+ dr = devres_alloc(devm_netdev_release, sizeof(*dr), GFP_KERNEL);
+ if (!dr)
+ return -ENOMEM;
+
+ ret = register_netdev(ndev);
+ if (ret) {
+ devres_free(dr);
+ return ret;
+ }
+
+ dr->ndev = ndev;
+ devres_add(ndev->dev.parent, dr);
+
+ return 0;
+}
+EXPORT_SYMBOL(devm_register_netdev);
--
2.25.0
^ permalink raw reply related
* [PATCH v2 3/5] net: devres: define a separate devres structure for devm_alloc_etherdev()
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Not using a proxy structure to store struct net_device doesn't save
anything in terms of compiled code size or memory usage but significantly
decreases the readability of the code with all the pointer casting.
Define struct net_device_devres and use it in devm_alloc_etherdev_mqs().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
net/devres.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/net/devres.c b/net/devres.c
index c1465d9f9019..b97b0c5a8216 100644
--- a/net/devres.c
+++ b/net/devres.c
@@ -7,30 +7,34 @@
#include <linux/etherdevice.h>
#include <linux/netdevice.h>
-static void devm_free_netdev(struct device *dev, void *res)
+struct net_device_devres {
+ struct net_device *ndev;
+};
+
+static void devm_free_netdev(struct device *dev, void *this)
{
- free_netdev(*(struct net_device **)res);
+ struct net_device_devres *res = this;
+
+ free_netdev(res->ndev);
}
struct net_device *devm_alloc_etherdev_mqs(struct device *dev, int sizeof_priv,
unsigned int txqs, unsigned int rxqs)
{
- struct net_device **dr;
- struct net_device *netdev;
+ struct net_device_devres *dr;
dr = devres_alloc(devm_free_netdev, sizeof(*dr), GFP_KERNEL);
if (!dr)
return NULL;
- netdev = alloc_etherdev_mqs(sizeof_priv, txqs, rxqs);
- if (!netdev) {
+ dr->ndev = alloc_etherdev_mqs(sizeof_priv, txqs, rxqs);
+ if (!dr->ndev) {
devres_free(dr);
return NULL;
}
- *dr = netdev;
devres_add(dev, dr);
- return netdev;
+ return dr->ndev;
}
EXPORT_SYMBOL(devm_alloc_etherdev_mqs);
--
2.25.0
^ permalink raw reply related
* [PATCH v2 1/5] Documentation: devres: add a missing section for networking helpers
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add a new section for networking devres helpers to devres.rst and list
the two existing devm functions.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
Documentation/driver-api/driver-model/devres.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index 46c13780994c..50df28d20fa7 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -372,6 +372,10 @@ MUX
devm_mux_chip_register()
devm_mux_control_get()
+NET
+ devm_alloc_etherdev()
+ devm_alloc_etherdev_mqs()
+
PER-CPU MEM
devm_alloc_percpu()
devm_free_percpu()
--
2.25.0
^ permalink raw reply related
* [PATCH v2 0/5] net: provide a devres variant of register_netdev()
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Using devres helpers allows to shrink the probing code, avoid memory leaks in
error paths make sure the order in which resources are freed is the exact
opposite of their allocation. This series proposes to add a devres variant
of register_netdev() that will only work with net_device structures whose
memory is also managed.
First we add the missing documentation entry for the only other networking
devres helper: devm_alloc_etherdev().
Next we move devm_alloc_etherdev() into a separate source file.
We then use a proxy structure in devm_alloc_etherdev() to improve readability.
Last: we implement devm_register_netdev() and use it in mtk-eth-mac driver.
v1 -> v2:
- rebase on top of net-next after driver rename, no functional changes
Bartosz Golaszewski (5):
Documentation: devres: add a missing section for networking helpers
net: move devres helpers into a separate source file
net: devres: define a separate devres structure for
devm_alloc_etherdev()
net: devres: provide devm_register_netdev()
net: ethernet: mtk_star_emac: use devm_register_netdev()
.../driver-api/driver-model/devres.rst | 5 +
drivers/net/ethernet/mediatek/mtk_star_emac.c | 17 +---
include/linux/netdevice.h | 2 +
net/Makefile | 2 +-
net/devres.c | 95 +++++++++++++++++++
net/ethernet/eth.c | 28 ------
6 files changed, 104 insertions(+), 45 deletions(-)
create mode 100644 net/devres.c
--
2.25.0
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sm8250: sort nodes by physical address
From: Jonathan Marek @ 2020-05-23 13:22 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Other dts have nodes sorted by physical address, be consistent with that.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 176 +++++++++++++--------------
1 file changed, 88 insertions(+), 88 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index a273b99bf1e6..bc8a14df60e5 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -379,6 +379,12 @@ ufs_mem_phy_lanes: lanes@1d87400 {
};
};
+ tcsr_mutex: hwlock@1f40000 {
+ compatible = "qcom,tcsr-mutex";
+ reg = <0x0 0x01f40000 0x0 0x40000>;
+ #hwlock-cells = <1>;
+ };
+
usb_1_hsphy: phy@88e3000 {
compatible = "qcom,sm8250-usb-hs-phy",
"qcom,usb-snps-hs-7nm-phy";
@@ -559,15 +565,6 @@ usb_2_dwc3: dwc3@a800000 {
};
};
- intc: interrupt-controller@17a00000 {
- compatible = "arm,gic-v3";
- #interrupt-cells = <3>;
- interrupt-controller;
- reg = <0x0 0x17a00000 0x0 0x10000>, /* GICD */
- <0x0 0x17a60000 0x0 0x100000>; /* GICR * 8 */
- interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
- };
-
pdc: interrupt-controller@b220000 {
compatible = "qcom,sm8250-pdc", "qcom,pdc";
reg = <0 0x0b220000 0 0x30000>, <0 0x17c000f0 0 0x60>;
@@ -596,85 +593,6 @@ spmi_bus: qcom,spmi@c440000 {
#interrupt-cells = <4>;
};
- apps_rsc: rsc@18200000 {
- label = "apps_rsc";
- compatible = "qcom,rpmh-rsc";
- reg = <0x0 0x18200000 0x0 0x10000>,
- <0x0 0x18210000 0x0 0x10000>,
- <0x0 0x18220000 0x0 0x10000>;
- reg-names = "drv-0", "drv-1", "drv-2";
- interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
- qcom,tcs-offset = <0xd00>;
- qcom,drv-id = <2>;
- qcom,tcs-config = <ACTIVE_TCS 2>, <SLEEP_TCS 3>,
- <WAKE_TCS 3>, <CONTROL_TCS 1>;
-
- rpmhcc: clock-controller {
- compatible = "qcom,sm8250-rpmh-clk";
- #clock-cells = <1>;
- clock-names = "xo";
- clocks = <&xo_board>;
- };
-
- rpmhpd: power-controller {
- compatible = "qcom,sm8250-rpmhpd";
- #power-domain-cells = <1>;
- operating-points-v2 = <&rpmhpd_opp_table>;
-
- rpmhpd_opp_table: opp-table {
- compatible = "operating-points-v2";
-
- rpmhpd_opp_ret: opp1 {
- opp-level = <RPMH_REGULATOR_LEVEL_RETENTION>;
- };
-
- rpmhpd_opp_min_svs: opp2 {
- opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
- };
-
- rpmhpd_opp_low_svs: opp3 {
- opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
- };
-
- rpmhpd_opp_svs: opp4 {
- opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
- };
-
- rpmhpd_opp_svs_l1: opp5 {
- opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
- };
-
- rpmhpd_opp_nom: opp6 {
- opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
- };
-
- rpmhpd_opp_nom_l1: opp7 {
- opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
- };
-
- rpmhpd_opp_nom_l2: opp8 {
- opp-level = <RPMH_REGULATOR_LEVEL_NOM_L2>;
- };
-
- rpmhpd_opp_turbo: opp9 {
- opp-level = <RPMH_REGULATOR_LEVEL_TURBO>;
- };
-
- rpmhpd_opp_turbo_l1: opp10 {
- opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L1>;
- };
- };
- };
- };
-
- tcsr_mutex: hwlock@1f40000 {
- compatible = "qcom,tcsr-mutex";
- reg = <0x0 0x01f40000 0x0 0x40000>;
- #hwlock-cells = <1>;
- };
-
tlmm: pinctrl@f100000 {
compatible = "qcom,sm8250-pinctrl";
reg = <0 0x0f100000 0 0x300000>,
@@ -690,6 +608,15 @@ tlmm: pinctrl@f100000 {
wakeup-parent = <&pdc>;
};
+ intc: interrupt-controller@17a00000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x0 0x17a00000 0x0 0x10000>, /* GICD */
+ <0x0 0x17a60000 0x0 0x100000>; /* GICR * 8 */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
timer@17c20000 {
#address-cells = <2>;
#size-cells = <2>;
@@ -749,6 +676,79 @@ frame@17c2d000 {
};
};
+ apps_rsc: rsc@18200000 {
+ label = "apps_rsc";
+ compatible = "qcom,rpmh-rsc";
+ reg = <0x0 0x18200000 0x0 0x10000>,
+ <0x0 0x18210000 0x0 0x10000>,
+ <0x0 0x18220000 0x0 0x10000>;
+ reg-names = "drv-0", "drv-1", "drv-2";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ qcom,tcs-offset = <0xd00>;
+ qcom,drv-id = <2>;
+ qcom,tcs-config = <ACTIVE_TCS 2>, <SLEEP_TCS 3>,
+ <WAKE_TCS 3>, <CONTROL_TCS 1>;
+
+ rpmhcc: clock-controller {
+ compatible = "qcom,sm8250-rpmh-clk";
+ #clock-cells = <1>;
+ clock-names = "xo";
+ clocks = <&xo_board>;
+ };
+
+ rpmhpd: power-controller {
+ compatible = "qcom,sm8250-rpmhpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&rpmhpd_opp_table>;
+
+ rpmhpd_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ rpmhpd_opp_ret: opp1 {
+ opp-level = <RPMH_REGULATOR_LEVEL_RETENTION>;
+ };
+
+ rpmhpd_opp_min_svs: opp2 {
+ opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
+ };
+
+ rpmhpd_opp_low_svs: opp3 {
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ };
+
+ rpmhpd_opp_svs: opp4 {
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ };
+
+ rpmhpd_opp_svs_l1: opp5 {
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ };
+
+ rpmhpd_opp_nom: opp6 {
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+ };
+
+ rpmhpd_opp_nom_l1: opp7 {
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
+ };
+
+ rpmhpd_opp_nom_l2: opp8 {
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM_L2>;
+ };
+
+ rpmhpd_opp_turbo: opp9 {
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO>;
+ };
+
+ rpmhpd_opp_turbo_l1: opp10 {
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L1>;
+ };
+ };
+ };
+ };
+
cpufreq_hw: cpufreq@18591000 {
compatible = "qcom,cpufreq-hw";
reg = <0 0x18591000 0 0x1000>,
--
2.26.1
^ permalink raw reply related
* [PATCH] arm64: dts: qcom: sm8250: rename spmi node to spmi_bus
From: Jonathan Marek @ 2020-05-23 13:21 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
The pm8150 dtsi files refer to it as spmi_bus, so change it.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 04c9c215ffcd..a273b99bf1e6 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -578,7 +578,7 @@ pdc: interrupt-controller@b220000 {
interrupt-controller;
};
- spmi: qcom,spmi@c440000 {
+ spmi_bus: qcom,spmi@c440000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0 0x0c440000 0x0 0x0001100>,
<0x0 0x0c600000 0x0 0x2000000>,
--
2.26.1
^ permalink raw reply related
* Re: [PATCH 0/5] net: provide a devres variant of register_netdev()
From: Bartosz Golaszewski @ 2020-05-23 13:14 UTC (permalink / raw)
To: David Miller
Cc: Jonathan Corbet, Matthias Brugger, John Crispin, Sean Wang,
Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer, devicetree,
Linux Kernel Mailing List, netdev, Linux ARM,
moderated list:ARM/Mediatek SoC..., Stephane Le Provost,
Pedro Tsai, Andrew Perepech, Bartosz Golaszewski
In-Reply-To: <20200522.153653.998395486877096103.davem@davemloft.net>
sob., 23 maj 2020 o 00:36 David Miller <davem@davemloft.net> napisał(a):
>
> From: Bartosz Golaszewski <brgl@bgdev.pl>
> Date: Wed, 20 May 2020 13:44:10 +0200
>
> > net: ethernet: mtk_eth_mac: use devm_register_netdev()
>
> This patch doesn't apply to net-next.
>
> Neither the source file drivers/net/ethernet/mediatek/mtk_eth_mac.c,
> nor the function mtk_mac_probe() even exist in the net-next GIT
> tree.
Indeed. The driver got renamed in v5. I didn't resend a new version of
this series because I thought there would be a discussion about its
usefulness. I'll send a rebased version then.
Bartosz
^ permalink raw reply
* Re: [PATCH v5 00/11] mediatek: add support for MediaTek Ethernet MAC
From: Matthias Brugger @ 2020-05-23 13:14 UTC (permalink / raw)
To: David Miller
Cc: brgl, robh+dt, john, sean.wang, Mark-MC.Lee, kuba, arnd, fparent,
hkallweit1, edwin.peer, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-mediatek, stephane.leprovost, pedro.tsai,
andrew.perepech, bgolaszewski
In-Reply-To: <20200522.143656.1986528672037093503.davem@davemloft.net>
On 5/22/20 11:36 PM, David Miller wrote:
> From: Matthias Brugger <matthias.bgg@gmail.com>
> Date: Fri, 22 May 2020 23:31:50 +0200
>
>>
>>
>> On 22/05/2020 23:20, David Miller wrote:
>>> From: Bartosz Golaszewski <brgl@bgdev.pl>
>>> Date: Fri, 22 May 2020 14:06:49 +0200
>>>
>>>> This series adds support for the STAR Ethernet Controller present on MediaTeK
>>>> SoCs from the MT8* family.
>>>
>>> Series applied to net-next, thank you.
>>>
>>
>> If you say "series applied" do you mean you also applied the device tree parts?
>> These should go through my branch, because there could be conflicts if there are
>> other device tree patches from other series, not related with network, touching
>> the same files.
>
> It's starting to get rediculous and tedious to manage the DT changes
> when they are tied to new networking drivers and such.
>
> And in any event, it is the patch series submitter's responsibility to
> sort these issues out, separate the patches based upon target tree, and
> clearly indicate this in the introductory posting and Subject lines.
>
My experience in with other subsystems is that the DTS changes which
enables de device are part of the series.
They are normally prefixed with "arm64: dts:" or "ARM: dts:" for 32 bit
SoCs. That also normally the way I detect patches which should through
my tree.
Anyway I'll try to remember submitters in the future to send DTS patches
for network devices as separate series. That makes my life a bit more
complicated as I afterwards have to find the related DTS series to the
driver you accepted, but I'll try.
Regards,
Matthias
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sm8250: use dt-bindings defines for clocks
From: Jonathan Marek @ 2020-05-23 13:12 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Use the dt-bindings defines for qupv3_id_1 node's clocks.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 9c210fbac65e..04c9c215ffcd 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -292,7 +292,8 @@ qupv3_id_1: geniqup@ac0000 {
compatible = "qcom,geni-se-qup";
reg = <0x0 0x00ac0000 0x0 0x6000>;
clock-names = "m-ahb", "s-ahb";
- clocks = <&gcc 133>, <&gcc 134>;
+ clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
+ <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
@@ -302,7 +303,7 @@ uart2: serial@a90000 {
compatible = "qcom,geni-debug-uart";
reg = <0x0 0x00a90000 0x0 0x4000>;
clock-names = "se";
- clocks = <&gcc 113>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
--
2.26.1
^ permalink raw reply related
* Re: [PATCH v3 0/6] sc16is7xx: IrDA mode and threaded IRQs
From: Daniel Mack @ 2020-05-23 12:27 UTC (permalink / raw)
To: Greg KH
Cc: devicetree, linux-serial, robh+dt, jslaby, jringle, m.brock,
pascal.huerst
In-Reply-To: <20200522090755.GA1189521@kroah.com>
On 5/22/20 11:07 AM, Greg KH wrote:
> On Thu, May 21, 2020 at 11:11:46AM +0200, Daniel Mack wrote:
>> This is v3 of the series.
>>
>> v3:
>>
>> * Add my s-o-b to the first two patches
>>
>> v2:
>>
>> * Change single bool properties into an array
>> (suggested by Rob Herring)
>> * Add a patch first try TRIGGER_LOW and SHARED interrupts, and then
>> fall back to FALLING edge if the IRQ controller fails to provide the
>> former (suggested by Maarten Brock)
>> * Add a patch to check for the device presence
>>
>> Daniel Mack (4):
>> sc16is7xx: Always use falling edge IRQ
>> sc16is7xx: Use threaded IRQ
>> sc16is7xx: Allow sharing the IRQ line
>> sc16is7xx: Read the LSR register for basic device presence check
>>
>> Pascal Huerst (2):
>> dt-bindings: sc16is7xx: Add flag to activate IrDA mode
>> sc16is7xx: Add flag to activate IrDA mode
>
> As I have to wait for the DT addition to be reviewed before applying the
> first 2 patches here, I've taken the other 4 instead at the moment. If
> you could rebase the first two and resend when they get acked, so that I
> could apply them, that would be great.
Sure, will do. Thanks :)
Daniel
^ permalink raw reply
* Re: [PATCH v11 2/6] mfd: mp2629: Add support for mps battery charger
From: saravanan sekar @ 2020-05-23 12:20 UTC (permalink / raw)
To: Lee Jones
Cc: andy.shevchenko, robh+dt, jic23, knaack.h, lars, pmeerw, sre,
devicetree, linux-kernel, linux-iio, linux-pm
In-Reply-To: <20200519103741.GW271301@dell>
Hi Lee,
On 19/05/20 12:37 pm, Lee Jones wrote:
> On Thu, 30 Apr 2020, Saravanan Sekar wrote:
>
>> mp2629 is a highly-integrated switching-mode battery charge management
>> device for single-cell Li-ion or Li-polymer battery.
>>
>> Add MFD core enables chip access for ADC driver for battery readings,
>> and a power supply battery-charger driver
>>
>> Signed-off-by: Saravanan Sekar <sravanhome@gmail.com>
>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>> ---
>> drivers/mfd/Kconfig | 9 +++++
>> drivers/mfd/Makefile | 2 +
>> drivers/mfd/mp2629.c | 79 ++++++++++++++++++++++++++++++++++++++
>> include/linux/mfd/mp2629.h | 17 ++++++++
>> 4 files changed, 107 insertions(+)
>> create mode 100644 drivers/mfd/mp2629.c
>> create mode 100644 include/linux/mfd/mp2629.h
> For my own reference (apply this as-is to your sign-off block):
>
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
>
Do I have to resend with above sign-off in all the patch?
Thanks,
Saravanan
^ permalink raw reply
* Re: [PATCH v4 1/6] printk: Collapse shutdown types into a single dump reason
From: Michael Ellerman @ 2020-05-23 11:16 UTC (permalink / raw)
To: Kees Cook, Pavel Tatashin
Cc: Kees Cook, Petr Mladek, Anton Vorontsov, Colin Cross, Tony Luck,
Jonathan Corbet, Benson Leung, Rob Herring,
Benjamin Herrenschmidt, Paul Mackerras, Enric Balletbo i Serra,
Sergey Senozhatsky, Steven Rostedt, linux-doc, linux-kernel,
devicetree, linuxppc-dev
In-Reply-To: <20200515184434.8470-2-keescook@chromium.org>
Kees Cook <keescook@chromium.org> writes:
> To turn the KMSG_DUMP_* reasons into a more ordered list, collapse
> the redundant KMSG_DUMP_(RESTART|HALT|POWEROFF) reasons into
> KMSG_DUMP_SHUTDOWN. The current users already don't meaningfully
> distinguish between them, so there's no need to, as discussed here:
> https://lore.kernel.org/lkml/CA+CK2bAPv5u1ih5y9t5FUnTyximtFCtDYXJCpuyjOyHNOkRdqw@mail.gmail.com/
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> arch/powerpc/kernel/nvram_64.c | 4 +---
> fs/pstore/platform.c | 8 ++------
> include/linux/kmsg_dump.h | 4 +---
> kernel/reboot.c | 6 +++---
> 4 files changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
> index fb4f61096613..0cd1c88bfc8b 100644
> --- a/arch/powerpc/kernel/nvram_64.c
> +++ b/arch/powerpc/kernel/nvram_64.c
> @@ -655,9 +655,7 @@ static void oops_to_nvram(struct kmsg_dumper *dumper,
> int rc = -1;
>
> switch (reason) {
> - case KMSG_DUMP_RESTART:
> - case KMSG_DUMP_HALT:
> - case KMSG_DUMP_POWEROFF:
> + case KMSG_DUMP_SHUTDOWN:
> /* These are almost always orderly shutdowns. */
> return;
> case KMSG_DUMP_OOPS:
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
^ 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