Re: [PATCH] rcu: Make jiffies_till_sched_qs writable
On Mon, Jul 08, 2019 at 09:03:59AM -0400, Joel Fernandes wrote:
> > Actually, the intent was to only allow this to be changed at boot time.
> > Of course, if there is now a good reason to adjust it, it needs
> > to be adjustable. So what situation is making you want to change
> > jiffies_till_sched_qs at runtime? To what values is it proving useful
> > to adjust it? What (if any) relationships between this timeout and the
> > various other RCU timeouts need to be maintained? What changes to
> > rcutorture should be applied in order to test the ability to change
> > this at runtime?
>
> I am also interested in the context, are you changing it at runtime for
> experimentation? I recently was doing some performance experiments and it is
> quite interesting how reducing this value can shorten grace period times :)
Hi Joel,
I've read a thread talking about your experiment to see how the grace
periods change depending on the tunnable variables which was interesting
to me. While reading it, I found out jiffies_till_sched_qs is not
tunnable at runtime unlike jiffies_till_{first,next}_fqs which looks
like non-sense to me that's why I tried this patch. :)
Hi Paul,
IMHO, as much as we want to tune the time for fqs to be initiated, we
can also want to tune the time for the help from scheduler to start.
I thought only difference between them is a level of urgency. I might be
wrong. It would be appreciated if you let me know if I miss something.
And it's ok even if the patch is turned down based on your criteria. :)
Thanks,
Byungchul
> Joel
>
>
> > Thanx, Paul
> >
> > > The function for setting jiffies_to_sched_qs,
> > > adjust_jiffies_till_sched_qs() will be called only if
> > > the value from sysfs != ULONG_MAX. And the value won't be adjusted
> > > unlike first/next fqs jiffies.
> > >
> > > While at it, changed the positions of two module_param()s downward.
> > >
> > > Signed-off-by: Byungchul Park
> > > ---
> > > kernel/rcu/tree.c | 22 --
> > > 1 file changed, 20 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index a2f8ba2..a28e2fe 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -422,9 +422,7 @@ static int rcu_is_cpu_rrupt_from_idle(void)
> > > * quiescent-state help from rcu_note_context_switch().
> > > */
> > > static ulong jiffies_till_sched_qs = ULONG_MAX;
> > > -module_param(jiffies_till_sched_qs, ulong, 0444);
> > > static ulong jiffies_to_sched_qs; /* See adjust_jiffies_till_sched_qs().
> > > */
> > > -module_param(jiffies_to_sched_qs, ulong, 0444); /* Display only! */
> > >
> > > /*
> > > * Make sure that we give the grace-period kthread time to detect any
> > > @@ -450,6 +448,18 @@ static void adjust_jiffies_till_sched_qs(void)
> > > WRITE_ONCE(jiffies_to_sched_qs, j);
> > > }
> > >
> > > +static int param_set_sched_qs_jiffies(const char *val, const struct
> > > kernel_param *kp)
> > > +{
> > > + ulong j;
> > > + int ret = kstrtoul(val, 0, );
> > > +
> > > + if (!ret && j != ULONG_MAX) {
> > > + WRITE_ONCE(*(ulong *)kp->arg, j);
> > > + adjust_jiffies_till_sched_qs();
> > > + }
> > > + return ret;
> > > +}
> > > +
> > > static int param_set_first_fqs_jiffies(const char *val, const struct
> > > kernel_param *kp)
> > > {
> > > ulong j;
> > > @@ -474,6 +484,11 @@ static int param_set_next_fqs_jiffies(const char
> > > *val, const struct kernel_param
> > > return ret;
> > > }
> > >
> > > +static struct kernel_param_ops sched_qs_jiffies_ops = {
> > > + .set = param_set_sched_qs_jiffies,
> > > + .get = param_get_ulong,
> > > +};
> > > +
> > > static struct kernel_param_ops first_fqs_jiffies_ops = {
> > > .set = param_set_first_fqs_jiffies,
> > > .get = param_get_ulong,
> > > @@ -484,8 +499,11 @@ static int param_set_next_fqs_jiffies(const char
> > > *val, const struct kernel_param
> > > .get = param_get_ulong,
> > > };
> > >
> > > +module_param_cb(jiffies_till_sched_qs, _qs_jiffies_ops,
> > > _till_sched_qs, 0644);
> > > module_param_cb(jiffies_till_first_fqs, _fqs_jiffies_ops,
> > > _till_first_fqs, 0644);
> > > module_param_cb(jiffies_till_next_fqs, _fqs_jiffies_ops,
> > > _till_next_fqs, 0644);
> > > +
> > > +module_param(jiffies_to_sched_qs, ulong, 0444); /* Display only! */
> > > module_param(rcu_kick_kthreads, bool, 0644);
> > >
> > > static void force_qs_rnp(int (*f)(struct rcu_data *rdp));
> > > --
> > > 1.9.1
> > >
> >
Re: [PATCH v1 6/6] cpuidle: tegra: Remove CPUIDLE_FLAG_TIMER_STOP from all states
08.07.2019 2:38, Dmitry Osipenko пишет:
> The Tegra's clocksource driver got some rework recently and now the
> internal/local CPU timers usage is discouraged on Tegra20/30 SoCs in
> a favor of the platform-specific timers that are assigned as per-CPU
> clocksources because they do not suffer from the CPU-freq changes and
> are always-ON during of CPU-idling. That happened in the commit
> f6d50ec5f85c ("clocksource/drivers/tegra: Support per-CPU timers on all
> Tegra's"). The Tegra's clocksource driver is the essential arch-driver
> that is guaranteed to always present on all Tegra SoCs up to Tegra124.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/cpuidle/cpuidle-tegra.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle-tegra.c b/drivers/cpuidle/cpuidle-tegra.c
> index 464b2376905a..e2aa46231c05 100644
> --- a/drivers/cpuidle/cpuidle-tegra.c
> +++ b/drivers/cpuidle/cpuidle-tegra.c
> @@ -143,7 +143,6 @@ static struct cpuidle_driver tegra_idle_driver = {
> .exit_latency = 2000,
> .target_residency = 2200,
> .power_usage= 0,
> - .flags = CPUIDLE_FLAG_TIMER_STOP,
> .name = "powered-down",
> .desc = "CPU core powered-off",
> },
> @@ -152,8 +151,7 @@ static struct cpuidle_driver tegra_idle_driver = {
> .exit_latency = 5000,
> .target_residency = 1,
> .power_usage= 0,
> - .flags = CPUIDLE_FLAG_COUPLED |
> - CPUIDLE_FLAG_TIMER_STOP,
> + .flags = CPUIDLE_FLAG_COUPLED,
> .name = "powered-down",
> .desc = "CPU cluster powered-off",
> },
>
Actually, it should be fine to keep this flag because I found that
tick_broadcast_oneshot_control() checks for the C3STOP flag and thus
CPUIDLE_FLAG_TIMER_STOP has no effect in that case. Will drop this patch in the
next revision.
Re: [PATCH v2 1/2] firmware: imx: Add DSP IPC protocol interface
Hi Oleksij,
Any comments on this?
On Thu, Jun 27, 2019 at 11:14 AM Daniel Baluta wrote:
>
> Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain
> the Tensilica HiFi4 DSP for advanced pre- and post-audio
> processing.
>
> The communication between Host CPU and DSP firmware is
> taking place using a shared memory area for message passing
> and a dedicated Messaging Unit for notifications.
>
> DSP IPC protocol driver offers a doorbell interface using
> imx-mailbox API.
>
> We use 4 MU channels (2 x TXDB, 2 x RXDB) to implement a
> request-reply protocol.
>
> Connection 0 (txdb0, rxdb0):
> - Host writes messasge to shared memory [SHMEM]
> - Host sends a request [MU]
> - DSP handles request [SHMEM]
> - DSP sends reply [MU]
>
> Connection 1 (txdb1, rxdb1):
> - DSP writes a message to shared memory [SHMEM]
> - DSP sends a request [MU]
> - Host handles request [SHMEM]
> - Host sends reply [MU]
>
> The protocol driver will be used by a Host client to
> communicate with the DSP. First client will be the i.MX8
> part from Sound Open Firmware infrastructure.
>
> The protocol drivers offers the following interface:
>
> On Tx:
>- imx_dsp_ring_doorbell, will be called to notify the DSP
>that it needs to handle a request.
>
> On Rx:
>- clients need to provide two callbacks:
> .handle_reply
> .handle_request
> - the callbacks will be used by the protocol driver on
> notification arrival from DSP.
>
> Signed-off-by: Daniel Baluta
> ---
> drivers/firmware/imx/Kconfig | 11 +++
> drivers/firmware/imx/Makefile| 1 +
> drivers/firmware/imx/imx-dsp.c | 142 +++
> include/linux/firmware/imx/dsp.h | 67 +++
> 4 files changed, 221 insertions(+)
> create mode 100644 drivers/firmware/imx/imx-dsp.c
> create mode 100644 include/linux/firmware/imx/dsp.h
>
> diff --git a/drivers/firmware/imx/Kconfig b/drivers/firmware/imx/Kconfig
> index 42b566f8903f..ddb241708c31 100644
> --- a/drivers/firmware/imx/Kconfig
> +++ b/drivers/firmware/imx/Kconfig
> @@ -1,4 +1,15 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +config IMX_DSP
> + bool "IMX DSP Protocol driver"
> + depends on IMX_MBOX
> + help
> + This enables DSP IPC protocol between host CPU (Linux)
> + and the firmware running on DSP.
> + DSP exists on some i.MX8 processors (e.g i.MX8QM, i.MX8QXP).
> +
> + It acts like a doorbell. Client might use shared memory to
> + exchange information with DSP side.
> +
> config IMX_SCU
> bool "IMX SCU Protocol driver"
> depends on IMX_MBOX
> diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
> index 802c4ad8e8f9..08bc9ddfbdfb 100644
> --- a/drivers/firmware/imx/Makefile
> +++ b/drivers/firmware/imx/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_IMX_DSP) += imx-dsp.o
> obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
> obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> diff --git a/drivers/firmware/imx/imx-dsp.c b/drivers/firmware/imx/imx-dsp.c
> new file mode 100644
> index ..c4d34a2fbff3
> --- /dev/null
> +++ b/drivers/firmware/imx/imx-dsp.c
> @@ -0,0 +1,142 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 NXP
> + * Author: Daniel Baluta
> + *
> + * Implementation of the DSP IPC interface (host side)
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * imx_dsp_ring_doorbell - triggers an interrupt on the other side (DSP)
> + *
> + * @dsp: DSP IPC handle
> + * @chan_idx: index of the channel where to trigger the interrupt
> + *
> + * Returns non-negative value for success, negative value for error
> + */
> +int imx_dsp_ring_doorbell(struct imx_dsp_ipc *ipc, unsigned int idx)
> +{
> + int ret;
> + struct imx_dsp_chan *dsp_chan;
> +
> + if (idx >= DSP_MU_CHAN_NUM)
> + return -EINVAL;
> +
> + dsp_chan = >chans[idx];
> + ret = mbox_send_message(dsp_chan->ch, NULL);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(imx_dsp_ring_doorbell);
> +
> +/*
> + * imx_dsp_handle_rx - rx callback used by imx mailbox
> + *
> + * @c: mbox client
> + * @msg: message received
> + *
> + * Users of DSP IPC will need to privde handle_reply and handle_request
> + * callbacks.
> + */
> +static void imx_dsp_handle_rx(struct mbox_client *c, void *msg)
> +{
> + struct imx_dsp_chan *chan = container_of(c, struct imx_dsp_chan, cl);
> +
> + if (chan->idx == 0) {
> + chan->ipc->ops->handle_reply(chan->ipc);
> + } else {
> + chan->ipc->ops->handle_request(chan->ipc);
> + imx_dsp_ring_doorbell(chan->ipc, 1);
> + }
> +}
> +
> +static int imx_dsp_probe(struct platform_device *pdev)
> +{
> + struct device *dev =
[GIT PULL] parisc architecture patches for kernel v5.3
Hi Linus, please pull enhancements for the parisc architecture for kernel 5.3 from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-5.3-1 Dynamic ftrace support by Sven Schnelle and a header guard fix by Denis Efremov. Thanks, Helge Denis Efremov (1): parisc: asm: psw.h: missing header guard Sven Schnelle (6): parisc: add support for patching multiple words parisc: add spinlock to patch function parisc: add WARN_ON() to clear_fixmap parisc: use pr_debug() in kernel/module.c compiler.h: add CC_USING_PATCHABLE_FUNCTION_ENTRY parisc: add dynamic ftrace arch/parisc/Kconfig | 2 + arch/parisc/Makefile | 18 ++ arch/parisc/include/asm/ftrace.h | 15 - arch/parisc/include/asm/patch.h | 4 +- arch/parisc/include/asm/psw.h | 2 +- arch/parisc/kernel/Makefile | 9 +-- arch/parisc/kernel/entry.S| 64 +++ arch/parisc/kernel/ftrace.c | 129 +++--- arch/parisc/kernel/module.c | 64 +++ arch/parisc/kernel/module.lds | 7 +++ arch/parisc/kernel/patch.c| 88 +- arch/parisc/kernel/vmlinux.lds.S | 2 + arch/parisc/mm/fixmap.c | 7 ++- include/asm-generic/vmlinux.lds.h | 7 +++ include/linux/compiler_types.h| 2 + 15 files changed, 359 insertions(+), 61 deletions(-) create mode 100644 arch/parisc/kernel/module.lds
Re: [PATCH 03/14] power: supply: sc27xx: Introduce local variable 'struct device *dev'
On Mon, 8 Jul 2019 at 20:33, Fuqian Huang wrote:
>
> Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatly.
>
> Signed-off-by: Fuqian Huang
Looks good to me. Thanks.
Reviewed-by: Baolin Wang
> ---
> drivers/power/supply/sc27xx_fuel_gauge.c | 47
>
> 1 file changed, 24 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c
> b/drivers/power/supply/sc27xx_fuel_gauge.c
> index 24895cc3b41e..9c184d80088b 100644
> --- a/drivers/power/supply/sc27xx_fuel_gauge.c
> +++ b/drivers/power/supply/sc27xx_fuel_gauge.c
> @@ -957,81 +957,82 @@ static int sc27xx_fgu_hw_init(struct sc27xx_fgu_data
> *data)
>
> static int sc27xx_fgu_probe(struct platform_device *pdev)
> {
> - struct device_node *np = pdev->dev.of_node;
> + struct device *dev = >dev;
> + struct device_node *np = dev->of_node;
> struct power_supply_config fgu_cfg = { };
> struct sc27xx_fgu_data *data;
> int ret, irq;
>
> - data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> if (!data)
> return -ENOMEM;
>
> - data->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> + data->regmap = dev_get_regmap(dev->parent, NULL);
> if (!data->regmap) {
> - dev_err(>dev, "failed to get regmap\n");
> + dev_err(dev, "failed to get regmap\n");
> return -ENODEV;
> }
>
> - ret = device_property_read_u32(>dev, "reg", >base);
> + ret = device_property_read_u32(dev, "reg", >base);
> if (ret) {
> - dev_err(>dev, "failed to get fgu address\n");
> + dev_err(dev, "failed to get fgu address\n");
> return ret;
> }
>
> - data->channel = devm_iio_channel_get(>dev, "bat-temp");
> + data->channel = devm_iio_channel_get(dev, "bat-temp");
> if (IS_ERR(data->channel)) {
> - dev_err(>dev, "failed to get IIO channel\n");
> + dev_err(dev, "failed to get IIO channel\n");
> return PTR_ERR(data->channel);
> }
>
> - data->charge_chan = devm_iio_channel_get(>dev, "charge-vol");
> + data->charge_chan = devm_iio_channel_get(dev, "charge-vol");
> if (IS_ERR(data->charge_chan)) {
> - dev_err(>dev, "failed to get charge IIO channel\n");
> + dev_err(dev, "failed to get charge IIO channel\n");
> return PTR_ERR(data->charge_chan);
> }
>
> - data->gpiod = devm_gpiod_get(>dev, "bat-detect", GPIOD_IN);
> + data->gpiod = devm_gpiod_get(dev, "bat-detect", GPIOD_IN);
> if (IS_ERR(data->gpiod)) {
> - dev_err(>dev, "failed to get battery detection GPIO\n");
> + dev_err(dev, "failed to get battery detection GPIO\n");
> return PTR_ERR(data->gpiod);
> }
>
> ret = gpiod_get_value_cansleep(data->gpiod);
> if (ret < 0) {
> - dev_err(>dev, "failed to get gpio state\n");
> + dev_err(dev, "failed to get gpio state\n");
> return ret;
> }
>
> data->bat_present = !!ret;
> mutex_init(>lock);
> - data->dev = >dev;
> + data->dev = dev;
> platform_set_drvdata(pdev, data);
>
> fgu_cfg.drv_data = data;
> fgu_cfg.of_node = np;
> - data->battery = devm_power_supply_register(>dev,
> _fgu_desc,
> + data->battery = devm_power_supply_register(dev, _fgu_desc,
>_cfg);
> if (IS_ERR(data->battery)) {
> - dev_err(>dev, "failed to register power supply\n");
> + dev_err(dev, "failed to register power supply\n");
> return PTR_ERR(data->battery);
> }
>
> ret = sc27xx_fgu_hw_init(data);
> if (ret) {
> - dev_err(>dev, "failed to initialize fgu hardware\n");
> + dev_err(dev, "failed to initialize fgu hardware\n");
> return ret;
> }
>
> - ret = devm_add_action(>dev, sc27xx_fgu_disable, data);
> + ret = devm_add_action(dev, sc27xx_fgu_disable, data);
> if (ret) {
> sc27xx_fgu_disable(data);
> - dev_err(>dev, "failed to add fgu disable action\n");
> + dev_err(dev, "failed to add fgu disable action\n");
> return ret;
> }
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> - dev_err(>dev, "no irq resource specified\n");
> + dev_err(dev, "no irq resource specified\n");
> return irq;
> }
>
> @@ -1046,17 +1047,17 @@ static int sc27xx_fgu_probe(struct platform_device
> *pdev)
>
> irq = gpiod_to_irq(data->gpiod);
> if (irq < 0) {
> - dev_err(>dev, "failed to
Re: [PATCH 04/14] power: supply: sc27xx: Replace devm_add_action() followed by failure action with devm_add_action_or_reset()
Hi Fuqian,
On Mon, 8 Jul 2019 at 20:33, Fuqian Huang wrote:
>
> devm_add_action_or_reset() is introduced as a helper function which
> internally calls devm_add_action(). If devm_add_action() fails
> then it will execute the action mentioned and return the error code.
> This reduce source code size (avoid writing the action twice)
> and reduce the likelyhood of bugs.
>
> Signed-off-by: Fuqian Huang
Looks good to me. Thanks.
Reviewed-by: Baolin Wang
> ---
> drivers/power/supply/sc27xx_fuel_gauge.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c
> b/drivers/power/supply/sc27xx_fuel_gauge.c
> index 9c184d80088b..58b2970cd359 100644
> --- a/drivers/power/supply/sc27xx_fuel_gauge.c
> +++ b/drivers/power/supply/sc27xx_fuel_gauge.c
> @@ -1023,9 +1023,8 @@ static int sc27xx_fgu_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> - ret = devm_add_action(dev, sc27xx_fgu_disable, data);
> + ret = devm_add_action_or_reset(dev, sc27xx_fgu_disable, data);
> if (ret) {
> - sc27xx_fgu_disable(data);
> dev_err(dev, "failed to add fgu disable action\n");
> return ret;
> }
> --
> 2.11.0
>
--
Baolin Wang
Best Regards
Re: [PATCH 1/3] opp: core: add regulators enable and disable
On 08-07-19, 16:11, k.koniec...@partner.samsung.com wrote:
> From: Kamil Konieczny
>
> Add enable regulators to dev_pm_opp_set_regulators() and disable
> regulators to dev_pm_opp_put_regulators(). This prepares for
> converting exynos-bus devfreq driver to use dev_pm_opp_set_rate().
>
> Signed-off-by: Kamil Konieczny
> ---
> drivers/opp/core.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 0e7703fe733f..947cac452854 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -1580,8 +1580,19 @@ struct opp_table *dev_pm_opp_set_regulators(struct
> device *dev,
> if (ret)
> goto free_regulators;
>
> + for (i = 0; i < opp_table->regulator_count; i++) {
> + ret = regulator_enable(opp_table->regulators[i]);
> + if (ret < 0)
> + goto disable;
> + }
I am wondering on why is this really required as this isn't done for
any other platform, probably because the regulators are enabled by
bootloader and are always on.
--
viresh
Re: [PATCH 8/8] nfsd: Fix misuse of strlcpy
On Mon, 2019-07-08 at 23:14 -0400, J. Bruce Fields wrote:
> On Thu, Jul 04, 2019 at 04:57:48PM -0700, Joe Perches wrote:
> > Probable cut typo - use the correct field size.
>
> Huh, that's been there forever, I wonder why we haven't seen crashes?
> Oh, I see, name and authname both have the same size.
>
> Anyway, makes sense, thanks. Will apply for 5.3.
>
> (Unless someone else is getting this; I didn't get copied on the rest of
> the series.)
It's generally hard to cc everyone on treewide fixes like this.
There's no good mechanism I know of.
vger mailing lists reject emails with too many addressees.
Do you have an opinion on adding the stracpy macro which
could avoid many of these defects?
---
include/linux/string.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index 4deb11f7976b..ef01bd6f19df 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -35,6 +35,22 @@ ssize_t strscpy(char *, const char *, size_t);
/* Wraps calls to strscpy()/memset(), no arch specific code required */
ssize_t strscpy_pad(char *dest, const char *src, size_t count);
+#define stracpy(to, from) \
+({ \
+ size_t size = ARRAY_SIZE(to); \
+ BUILD_BUG_ON(!__same_type(typeof(*to), char)); \
+ \
+ strscpy(to, from, size);\
+})
+
+#define stracpy_pad(to, from) \
+({ \
+ size_t size = ARRAY_SIZE(to); \
+ BUILD_BUG_ON(!__same_type(typeof(*to), char)); \
+ \
+ strscpy_pad(to, from, size);\
+})
+
#ifndef __HAVE_ARCH_STRCAT
extern char * strcat(char *, const char *);
#endif
RE: [PATCH 2/2] arm64: dts: imx8mm: Assign highest opp as suspend opp
Hi, Viresh > On 08-07-19, 08:54, Anson Huang wrote: > > Each OPP has "opp-supported-hw" property as below, the first value > > needs to be checked with speed grading fuse, and the second one needs > > to be checked with market segment fuse, ONLY both of them passed, then > > this OPP is supported. It calls dev_pm_opp_set_supported_hw() to tell > > OPP framework to parse the OPP table, this is my understanding. > > > > opp-supported-hw = <0x8>, <0x3>; > > Right, so that's what I was expecting. > > One thing we can do is change the binding of OPP core a bit to allow multiple > OPP nodes to contain the "opp-suspend" property and select the one finally > with the highest frequency. That would be a better as a generic solution IMO. > > And then a small OPP core patch will fix it. Looks good, I will try to generate a patch for of OPP core. Thanks, Anson
Re: [RFC 0/2] Optimize the idle CPU search
On 7/9/19 5:38 AM, Subhra Mazumdar wrote: > > On 7/8/19 10:24 AM, Parth Shah wrote: >> When searching for an idle_sibling, scheduler first iterates to search for >> an idle core and then for an idle CPU. By maintaining the idle CPU mask >> while iterating through idle cores, we can mark non-idle CPUs for which >> idle CPU search would not have to iterate through again. This is especially >> true in a moderately load system >> >> Optimize idle CPUs search by marking already found non idle CPUs during >> idle core search. This reduces iteration count when searching for idle >> CPUs, resulting in lower iteration count. >> > I believe this can co-exist with latency-nice? We can derive the 'nr' in > select_idle_cpu from latency-nice and use the new mask to iterate. > I agree, can be done with latency-nice. Maybe something like below? smt = nr_cpus / nr_cores nr = smt + (p->latency_nice * (total_cpus-smt) / max_latency_nice) This limits lower bounds to 1 core and goes through all the cores if latency_nice is maximum for a task. Thanks Parth
Re: [PATCH 4/4] tty: n_gsm: add ioctl to map serial device to mux'ed tty
On 08. 07. 19, 21:02, Martin Hundebøll wrote: > Guessing the base tty for a gsm0710 multiplexed serial device is not > currently possible, which makes it racy to use with multiple modems. > > Add a way to map the physical serial tty to its related mux devices > using a ioctl. ... > --- a/Documentation/serial/n_gsm.rst > +++ b/Documentation/serial/n_gsm.rst ... > @@ -58,6 +61,11 @@ Major parts of the initialization program : > c.mtu = 127; > /* set the new configuration */ > ioctl(fd, GSMIOC_SETCONF, ); > + /* get and print base gsmtty device node */ > + ioctl(fd, GSMIOC_GETBASE, ); > + /* the base node is used for mux control by the driver */ > + printf(first muxed line: /dev/gsmtty%i\n", base + 1); Missing " there. > --- a/drivers/tty/n_gsm.c > +++ b/drivers/tty/n_gsm.c ... > @@ -2623,6 +2624,11 @@ static int gsmld_ioctl(struct tty_struct *tty, struct > file *file, > if (copy_from_user(, (void *)arg, sizeof(c))) > return -EFAULT; > return gsm_config(gsm, ); > + case GSMIOC_GETBASE: > + base = mux_num_to_base(gsm); > + if (copy_to_user((void *)arg, , sizeof(base))) put_user would be more appropriate (and easier) for an int here. thanks, -- js suse labs
Re: [PATCH v3 1/3] cpuidle-powernv : forced wakeup for stop states
Hi Nick,
Will post next version with the changes you have suggested.
There is a comment below.
On 07/07/2019 03:43 PM, Nicholas Piggin wrote:
Abhishek Goel's on July 4, 2019 7:18 pm:
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics that depend on the idle history on
that CPU. Given that no predictive heuristic is perfect, there are cases
where the governor predicts a shallow idle state, hoping that the CPU will
be busy soon. However, if no new workload is scheduled on that CPU in the
near future, the CPU may end up in the shallow state.
This is problematic, when the predicted state in the aforementioned
scenario is a shallow stop state on a tickless system. As we might get
stuck into shallow states for hours, in absence of ticks or interrupts.
To address this, We forcefully wakeup the cpu by setting the
decrementer. The decrementer is set to a value that corresponds with the
residency of the next available state. Thus firing up a timer that will
forcefully wakeup the cpu. Few such iterations will essentially train the
governor to select a deeper state for that cpu, as the timer here
corresponds to the next available cpuidle state residency. Thus, cpu will
eventually end up in the deepest possible state.
Signed-off-by: Abhishek Goel
---
Auto-promotion
v1 : started as auto promotion logic for cpuidle states in generic
driver
v2 : Removed timeout_needed and rebased the code to upstream kernel
Forced-wakeup
v1 : New patch with name of forced wakeup started
v2 : Extending the forced wakeup logic for all states. Setting the
decrementer instead of queuing up a hrtimer to implement the logic.
v3 : Cleanly handle setting/resetting of decrementer so as to not break
irq work
arch/powerpc/include/asm/time.h | 2 ++
arch/powerpc/kernel/time.c| 40 +++
drivers/cpuidle/cpuidle-powernv.c | 32 +
3 files changed, 74 insertions(+)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 54f4ec1f9..a3bd4f3c0 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -188,6 +188,8 @@ static inline unsigned long tb_ticks_since(unsigned long
tstamp)
extern u64 mulhdu(u64, u64);
#endif
+extern int set_dec_before_idle(u64 timeout);
+extern void reset_dec_after_idle(void);
extern void div128_by_32(u64 dividend_high, u64 dividend_low,
unsigned divisor, struct div_result *dr);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 694522308..814de3469 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -576,6 +576,46 @@ void arch_irq_work_raise(void)
#endif /* CONFIG_IRQ_WORK */
+/*
+ * Returns 1 if we have reprogrammed the decrementer for idle.
+ * Returns 0 if the decrementer is unchanged.
+ */
+int set_dec_before_idle(u64 timeout)
+{
+ u64 *next_tb = this_cpu_ptr(_next_tb);
+ u64 now = get_tb_or_rtc();
+
+ /*
+* Ensure that the timeout is at least one microsecond
+* before the current decrement value. Else, we will
+* unnecesarily wakeup again within a microsecond.
+*/
+ if (now + timeout + 512 > *next_tb)
I would pass this 512 in as a parameter and put the comment in the
idle code. Timer code does not know/care.
Maybe return bool and call it try_set_dec_before_idle.
+ return 0;
+
+ set_dec(timeout);
This needs to have
if (test_irq_work_pending())
set_dec(1);
here AFAIKS
+
+ return 1;
+}
+
+void reset_dec_after_idle(void)
+{
+ u64 now;
+ u64 *next_tb;
+
+ if (test_irq_work_pending())
+ return;
+
+ now = get_tb_or_rtc();
+ next_tb = this_cpu_ptr(_next_tb);
+ if (now >= *next_tb)
+ return;
Are you sure it's okay to escape early in this case?
Yeah, It looks safe. In power9_idle_type, we call irq_set_pending_from_srr1
which sets the irq_happened. If reason is IRQ_DEC, in __check_irq_replay,
decrementer_check_overflow will be called which will set dec to a positive
valid value.
Also, we typically disable MSR EE before entering stop. And if a decrementer
wakes us up, before we enable EE, check for pending interrupt will be done.
And we finally reset dec to a positive value before we set EE=1.
Thanks,
Nick
Thanks,
Abhishek
[PATCH 3/7] Drivers: hv: vmbus: Split hv_synic_init/cleanup into regs and timer settings
There is only one functional change: the unnecessary check
"if (sctrl.enable != 1) return -EFAULT;" is removed, because when we're in
hv_synic_cleanup(), we're absolutely sure sctrl.enable must be 1.
The new functions hv_synic_disable/enable_regs() will be used by a later patch
to support hibernation.
Signed-off-by: Dexuan Cui
---
drivers/hv/hv.c | 66 ++-
drivers/hv/hyperv_vmbus.h | 2 ++
2 files changed, 39 insertions(+), 29 deletions(-)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 6188fb7..fcc5279 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -154,7 +154,7 @@ void hv_synic_free(void)
* retrieve the initialized message and event pages. Otherwise, we create and
* initialize the message and event pages.
*/
-int hv_synic_init(unsigned int cpu)
+void hv_synic_enable_regs(unsigned int cpu)
{
struct hv_per_cpu_context *hv_cpu
= per_cpu_ptr(hv_context.cpu_context, cpu);
@@ -196,6 +196,11 @@ int hv_synic_init(unsigned int cpu)
sctrl.enable = 1;
hv_set_synic_state(sctrl.as_uint64);
+}
+
+int hv_synic_init(unsigned int cpu)
+{
+ hv_synic_enable_regs(cpu);
hv_stimer_init(cpu);
@@ -205,20 +210,45 @@ int hv_synic_init(unsigned int cpu)
/*
* hv_synic_cleanup - Cleanup routine for hv_synic_init().
*/
-int hv_synic_cleanup(unsigned int cpu)
+void hv_synic_disable_regs(unsigned int cpu)
{
union hv_synic_sint shared_sint;
union hv_synic_simp simp;
union hv_synic_siefp siefp;
union hv_synic_scontrol sctrl;
+
+ hv_get_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
+
+ shared_sint.masked = 1;
+
+ /* Need to correctly cleanup in the case of SMP!!! */
+ /* Disable the interrupt */
+ hv_set_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
+
+ hv_get_simp(simp.as_uint64);
+ simp.simp_enabled = 0;
+ simp.base_simp_gpa = 0;
+
+ hv_set_simp(simp.as_uint64);
+
+ hv_get_siefp(siefp.as_uint64);
+ siefp.siefp_enabled = 0;
+ siefp.base_siefp_gpa = 0;
+
+ hv_set_siefp(siefp.as_uint64);
+
+ /* Disable the global synic bit */
+ hv_get_synic_state(sctrl.as_uint64);
+ sctrl.enable = 0;
+ hv_set_synic_state(sctrl.as_uint64);
+}
+
+int hv_synic_cleanup(unsigned int cpu)
+{
struct vmbus_channel *channel, *sc;
bool channel_found = false;
unsigned long flags;
- hv_get_synic_state(sctrl.as_uint64);
- if (sctrl.enable != 1)
- return -EFAULT;
-
/*
* Search for channels which are bound to the CPU we're about to
* cleanup. In case we find one and vmbus is still connected we need to
@@ -249,29 +279,7 @@ int hv_synic_cleanup(unsigned int cpu)
hv_stimer_cleanup(cpu);
- hv_get_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
-
- shared_sint.masked = 1;
-
- /* Need to correctly cleanup in the case of SMP!!! */
- /* Disable the interrupt */
- hv_set_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
-
- hv_get_simp(simp.as_uint64);
- simp.simp_enabled = 0;
- simp.base_simp_gpa = 0;
-
- hv_set_simp(simp.as_uint64);
-
- hv_get_siefp(siefp.as_uint64);
- siefp.siefp_enabled = 0;
- siefp.base_siefp_gpa = 0;
-
- hv_set_siefp(siefp.as_uint64);
-
- /* Disable the global synic bit */
- sctrl.enable = 0;
- hv_set_synic_state(sctrl.as_uint64);
+ hv_synic_disable_regs(cpu);
return 0;
}
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 362e70e..26ea161 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -171,8 +171,10 @@ extern int hv_post_message(union hv_connection_id
connection_id,
extern void hv_synic_free(void);
+extern void hv_synic_enable_regs(unsigned int cpu);
extern int hv_synic_init(unsigned int cpu);
+extern void hv_synic_disable_regs(unsigned int cpu);
extern int hv_synic_cleanup(unsigned int cpu);
/* Interface */
--
1.8.3.1
Re: [PATCH 4/4] powerpc/64: reuse PPC32 static inline flush_dcache_range()
On Tue, Jul 9, 2019 at 12:52 PM Aneesh Kumar K.V wrote: > > On 7/9/19 7:50 AM, Oliver O'Halloran wrote: > > On Tue, Jul 9, 2019 at 12:22 AM Aneesh Kumar K.V > > wrote: > >> > >> Christophe Leroy writes: > >> > >>> *snip* > >>> + if (IS_ENABLED(CONFIG_PPC64)) > >>> + isync(); > >>> } > >> > >> > >> Was checking with Michael about why we need that extra isync. Michael > >> pointed this came via > >> > >> https://github.com/mpe/linux-fullhistory/commit/faa5ee3743ff9b6df9f9a03600e34fdae596cfb2#diff-67c7ffa8e420c7d4206cae4a9e888e14 > >> > >> for 970 which doesn't have coherent icache. So possibly isync there is > >> to flush the prefetch instructions? But even so we would need an icbi > >> there before that isync. > > > > I don't think it's that, there's some magic in flush_icache_range() to > > handle dropping prefetched instructions on 970. > > > >> So overall wondering why we need that extra barriers there. > > > > I think the isync is needed there because the architecture only > > requires sync to provide ordering. A sync alone doesn't guarantee the > > dcbfs have actually completed so the isync is necessary to ensure the > > flushed cache lines are back in memory. That said, as far as I know > > all the IBM book3s chips from power4 onwards will wait for pending > > dcbfs when they hit a sync, but that might change in the future. > > > > ISA doesn't list that as the sequence. Only place where isync was > mentioned was w.r.t icbi where want to discards the prefetch. doesn't list that as the sequence for what? > > If it's a problem we could add a cpu-feature section around the isync > > to no-op it in the common case. However, when I had a look with perf > > it always showed that the sync was the hotspot so I don't think it'll > > help much. > > > > What about the preceding barriers (sync; isync;) before dcbf? Why are > they needed? Dunno, the sync might just be to ensure ordering between prior stores and the dcbf. > > -aneesh
[PATCH 1/7] x86/hyper-v: Suspend/resume the hypercall page for hibernation
This is needed for hibernation, e.g. when we resume the old kernel, we need
to disable the "current" kernel's hypercall page and then resume the old
kernel's.
Signed-off-by: Dexuan Cui
---
arch/x86/hyperv/hv_init.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 0e033ef..3005871 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
void *hv_hypercall_pg;
@@ -214,6 +215,34 @@ static int __init hv_pci_init(void)
return 1;
}
+static int hv_suspend(void)
+{
+ union hv_x64_msr_hypercall_contents hypercall_msr;
+
+ /* Reset the hypercall page */
+ rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+ hypercall_msr.enable = 0;
+ wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+
+ return 0;
+}
+
+static void hv_resume(void)
+{
+ union hv_x64_msr_hypercall_contents hypercall_msr;
+
+ /* Re-enable the hypercall page */
+ rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+ hypercall_msr.enable = 1;
+ hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
+ wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+}
+
+static struct syscore_ops hv_syscore_ops = {
+ .suspend = hv_suspend,
+ .resume = hv_resume,
+};
+
/*
* This function is to be invoked early in the boot sequence after the
* hypervisor has been detected.
@@ -294,6 +323,9 @@ void __init hyperv_init(void)
/* Register Hyper-V specific clocksource */
hv_init_clocksource();
+
+ register_syscore_ops(_syscore_ops);
+
return;
remove_cpuhp_state:
@@ -313,6 +345,8 @@ void hyperv_cleanup(void)
{
union hv_x64_msr_hypercall_contents hypercall_msr;
+ unregister_syscore_ops(_syscore_ops);
+
/* Reset our OS id */
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
--
1.8.3.1
Re: [PATCH 1/4] tty: n_gsm: remove obsolete mknod doc example
On 08. 07. 19, 21:02, Martin Hundebøll wrote:
> The n_gsm driver handles registration of /dev/gsmttyX nodes, so there's
> no need to do mknod manually.
>
> Signed-off-by: Martin Hundebøll
> ---
> Documentation/serial/n_gsm.rst | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/Documentation/serial/n_gsm.rst b/Documentation/serial/n_gsm.rst
> index f3ad9fd26408..78f91ce06956 100644
> --- a/Documentation/serial/n_gsm.rst
> +++ b/Documentation/serial/n_gsm.rst
> @@ -63,16 +63,6 @@ Major parts of the initialization program :
> daemon(0,0);
> pause();
>
> -4. create the devices corresponding to the "virtual" serial ports (take care,
> - each modem has its configuration and some DLC have dedicated functions,
> - for example GPS), starting with minor 1 (DLC0 is reserved for the
> management
> - of the mux)::
> -
> - MAJOR=`cat /proc/devices |grep gsmtty | awk '{print $1}`
> - for i in `seq 1 4`; do
> - mknod /dev/ttygsm$i c $MAJOR $i
> - done
> -
> 5. use these devices as plain serial ports.
So you should renumber the rest now...
thanks,
--
js
suse labs
[PATCH 4/7] Drivers: hv: vmbus: Suspend/resume the synic for hibernation
This is needed when we resume the old kernel from the "current" kernel.
Signed-off-by: Dexuan Cui
---
drivers/hv/vmbus_drv.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 72d5a7c..1c2d935 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include "hyperv_vmbus.h"
@@ -2088,6 +2089,41 @@ static void hv_crash_handler(struct pt_regs *regs)
hyperv_cleanup();
};
+static int hv_synic_suspend(void)
+{
+ /*
+* Here we only need to care about CPU0: when the other CPUs are
+* offlined, hv_synic_cleanup() has been called for them, and the
+* timers on them have been automatically disabled and deleted in
+* tick_cleanup_dead_cpu().
+*/
+ hv_stimer_cleanup(0);
+
+ hv_synic_disable_regs(0);
+
+ return 0;
+}
+
+static void hv_synic_resume(void)
+{
+ /*
+* Here we only need to care about CPU0: when the other CPUs are
+* onlined, hv_synic_init() has been called, and the timers are
+* added there.
+*
+* Note: we don't need to call hv_stimer_init() for stimer0, because
+* it is not deleted before hibernation and it's resumed in
+* timekeeping_resume().
+*/
+ hv_synic_enable_regs(0);
+}
+
+/* The callbacks run only on CPU0, with irqs_disabled. */
+static struct syscore_ops hv_synic_syscore_ops = {
+ .suspend = hv_synic_suspend,
+ .resume = hv_synic_resume,
+};
+
static int __init hv_acpi_init(void)
{
int ret, t;
@@ -2118,6 +2154,8 @@ static int __init hv_acpi_init(void)
hv_setup_kexec_handler(hv_kexec_handler);
hv_setup_crash_handler(hv_crash_handler);
+ register_syscore_ops(_synic_syscore_ops);
+
return 0;
cleanup:
@@ -2130,6 +2168,8 @@ static void __exit vmbus_exit(void)
{
int cpu;
+ unregister_syscore_ops(_synic_syscore_ops);
+
hv_remove_kexec_handler();
hv_remove_crash_handler();
vmbus_connection.conn_state = DISCONNECTED;
--
1.8.3.1
[PATCH 0/7] Enhance the hv_vmbus driver to support hibernation
Hi, This is the first patchset to enable hibernation when Linux VM runs on Hyper-V. A second patchset to enhance the high-level VSC drivers (hv_netvsc, hv_storvsc, etc.) for hibernation will be posted later. The second patchset depends on this first patchset, so I hope this pathset can be accepted soon. The changes in this patchset are mostly straightforward new code that only runs when the VM enters hibernation, so IMHO it's pretty safe to have this patchset, because the hibernation feature never worked for Linux VM running on Hyper-V. The patchset is rebased on Linus's tree today. Please review. Thanks, Dexuan Dexuan Cui (7): x86/hyper-v: Suspend/resume the hypercall page for hibernation clocksource/drivers: Suspend/resume Hyper-V clocksource for hibernation Drivers: hv: vmbus: Split hv_synic_init/cleanup into regs and timer settings Drivers: hv: vmbus: Suspend/resume the synic for hibernation Drivers: hv: vmbus: Ignore the offers when resuming from hibernation Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation Drivers: hv: vmbus: Implement suspend/resume for VSC drivers for hibernation arch/x86/hyperv/hv_init.c | 34 +++ drivers/clocksource/hyperv_timer.c | 25 drivers/hv/channel_mgmt.c | 28 - drivers/hv/connection.c| 3 +- drivers/hv/hv.c| 66 +++- drivers/hv/hyperv_vmbus.h | 4 ++ drivers/hv/vmbus_drv.c | 122 + include/linux/hyperv.h | 3 + 8 files changed, 253 insertions(+), 32 deletions(-) -- 1.8.3.1
[PATCH 2/7] clocksource/drivers: Suspend/resume Hyper-V clocksource for hibernation
This is needed for hibernation, e.g. when we resume the old kernel, we need
to disable the "current" kernel's TSC page and then resume the old kernel's.
Signed-off-by: Dexuan Cui
---
drivers/clocksource/hyperv_timer.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/clocksource/hyperv_timer.c
b/drivers/clocksource/hyperv_timer.c
index ba2c79e6..41c31a7 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -237,12 +237,37 @@ static u64 read_hv_clock_tsc(struct clocksource *arg)
return read_hv_sched_clock_tsc();
}
+static void suspend_hv_clock_tsc(struct clocksource *arg)
+{
+ u64 tsc_msr;
+
+ /* Disable the TSC page */
+ hv_get_reference_tsc(tsc_msr);
+ tsc_msr &= ~BIT_ULL(0);
+ hv_set_reference_tsc(tsc_msr);
+}
+
+
+static void resume_hv_clock_tsc(struct clocksource *arg)
+{
+ phys_addr_t phys_addr = page_to_phys(vmalloc_to_page(tsc_pg));
+ u64 tsc_msr;
+
+ /* Re-enable the TSC page */
+ hv_get_reference_tsc(tsc_msr);
+ tsc_msr &= GENMASK_ULL(11, 0);
+ tsc_msr |= BIT_ULL(0) | (u64)phys_addr;
+ hv_set_reference_tsc(tsc_msr);
+}
+
static struct clocksource hyperv_cs_tsc = {
.name = "hyperv_clocksource_tsc_page",
.rating = 400,
.read = read_hv_clock_tsc,
.mask = CLOCKSOURCE_MASK(64),
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
+ .suspend= suspend_hv_clock_tsc,
+ .resume = resume_hv_clock_tsc,
};
#endif
--
1.8.3.1
[PATCH 6/7] Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation
This is needed when we resume the old kernel from the "current" kernel.
Signed-off-by: Dexuan Cui
---
drivers/hv/connection.c | 3 +--
drivers/hv/hyperv_vmbus.h | 2 ++
drivers/hv/vmbus_drv.c| 40
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 09829e1..806319c 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -59,8 +59,7 @@ static __u32 vmbus_get_next_version(__u32 current_version)
}
}
-static int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo,
- __u32 version)
+int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo, u32 version)
{
int ret = 0;
unsigned int cur_cpu;
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 26ea161..e657197 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -274,6 +274,8 @@ struct vmbus_msginfo {
extern struct vmbus_connection vmbus_connection;
+int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo, u32
version);
+
static inline void vmbus_send_interrupt(u32 relid)
{
sync_set_bit(relid, vmbus_connection.send_int_page);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 1c2d935..1730e7b 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -2045,6 +2045,41 @@ static int vmbus_acpi_add(struct acpi_device *device)
return ret_val;
}
+static int vmbus_bus_suspend(struct device *dev)
+{
+ vmbus_initiate_unload(false);
+
+ vmbus_connection.conn_state = DISCONNECTED;
+
+ return 0;
+}
+
+static int vmbus_bus_resume(struct device *dev)
+{
+ struct vmbus_channel_msginfo *msginfo;
+ size_t msgsize;
+ int ret;
+
+ msgsize = sizeof(*msginfo) +
+ sizeof(struct vmbus_channel_initiate_contact);
+
+ msginfo = kzalloc(msgsize, GFP_KERNEL);
+
+ if (msginfo == NULL)
+ return -ENOMEM;
+
+ ret = vmbus_negotiate_version(msginfo, vmbus_proto_version);
+
+ kfree(msginfo);
+
+ if (ret != 0)
+ return ret;
+
+ vmbus_request_offers();
+
+ return 0;
+}
+
static const struct acpi_device_id vmbus_acpi_device_ids[] = {
{"VMBUS", 0},
{"VMBus", 0},
@@ -2052,6 +2087,10 @@ static int vmbus_acpi_add(struct acpi_device *device)
};
MODULE_DEVICE_TABLE(acpi, vmbus_acpi_device_ids);
+static const struct dev_pm_ops vmbus_bus_pm = {
+ SET_SYSTEM_SLEEP_PM_OPS(vmbus_bus_suspend, vmbus_bus_resume)
+};
+
static struct acpi_driver vmbus_acpi_driver = {
.name = "vmbus",
.ids = vmbus_acpi_device_ids,
@@ -2059,6 +2098,7 @@ static int vmbus_acpi_add(struct acpi_device *device)
.add = vmbus_acpi_add,
.remove = vmbus_acpi_remove,
},
+ .drv.pm = _bus_pm,
};
static void hv_kexec_handler(void)
--
1.8.3.1
[PATCH 7/7] Drivers: hv: vmbus: Implement suspend/resume for VSC drivers for hibernation
The high-level VSC drivers will implement device-specific callbacks.
Signed-off-by: Dexuan Cui
---
drivers/hv/vmbus_drv.c | 42 ++
include/linux/hyperv.h | 3 +++
2 files changed, 45 insertions(+)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 1730e7b..e29e2171 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -911,6 +911,43 @@ static void vmbus_shutdown(struct device *child_device)
drv->shutdown(dev);
}
+/*
+ * vmbus_suspend - Suspend a vmbus device
+ */
+static int vmbus_suspend(struct device *child_device)
+{
+ struct hv_driver *drv;
+ struct hv_device *dev = device_to_hv_device(child_device);
+
+ /* The device may not be attached yet */
+ if (!child_device->driver)
+ return 0;
+
+ drv = drv_to_hv_drv(child_device->driver);
+ if (!drv->suspend)
+ return -EOPNOTSUPP;
+
+ return drv->suspend(dev);
+}
+
+/*
+ * vmbus_resume - Resume a vmbus device
+ */
+static int vmbus_resume(struct device *child_device)
+{
+ struct hv_driver *drv;
+ struct hv_device *dev = device_to_hv_device(child_device);
+
+ /* The device may not be attached yet */
+ if (!child_device->driver)
+ return 0;
+
+ drv = drv_to_hv_drv(child_device->driver);
+ if (!drv->resume)
+ return -EOPNOTSUPP;
+
+ return drv->resume(dev);
+}
/*
* vmbus_device_release - Final callback release of the vmbus child device
@@ -926,6 +963,10 @@ static void vmbus_device_release(struct device *device)
kfree(hv_dev);
}
+static const struct dev_pm_ops vmbus_pm = {
+ SET_SYSTEM_SLEEP_PM_OPS(vmbus_suspend, vmbus_resume)
+};
+
/* The one and only one */
static struct bus_type hv_bus = {
.name = "vmbus",
@@ -936,6 +977,7 @@ static void vmbus_device_release(struct device *device)
.uevent = vmbus_uevent,
.dev_groups = vmbus_dev_groups,
.drv_groups = vmbus_drv_groups,
+ .pm = _pm,
};
struct onmessage_work_context {
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 6256cc3..94443c4 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1149,6 +1149,9 @@ struct hv_driver {
int (*remove)(struct hv_device *);
void (*shutdown)(struct hv_device *);
+ int (*suspend)(struct hv_device *);
+ int (*resume)(struct hv_device *);
+
};
/* Base device object */
--
1.8.3.1
[PATCH 5/7] Drivers: hv: vmbus: Ignore the offers when resuming from hibernation
When the VM resumes, the host re-sends the offers. We should not add the
offers to the global vmbus_connection.chn_list again.
Added some debug code, in case the host screws up the exact info related to
the offers.
Signed-off-by: Dexuan Cui
---
drivers/hv/channel_mgmt.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index addcef5..a9aeeab 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -854,12 +854,38 @@ void vmbus_initiate_unload(bool crash)
static void vmbus_onoffer(struct vmbus_channel_message_header *hdr)
{
struct vmbus_channel_offer_channel *offer;
- struct vmbus_channel *newchannel;
+ struct vmbus_channel *oldchannel, *newchannel;
+ size_t offer_sz;
offer = (struct vmbus_channel_offer_channel *)hdr;
trace_vmbus_onoffer(offer);
+ mutex_lock(_connection.channel_mutex);
+ oldchannel = relid2channel(offer->child_relid);
+ mutex_unlock(_connection.channel_mutex);
+
+ if (oldchannel != NULL) {
+ atomic_dec(_connection.offer_in_progress);
+
+ /*
+* We're resuming from hibernation: we expect the host to send
+* exactly the same offers that we had before the hibernation.
+*/
+ offer_sz = sizeof(*offer);
+ if (memcmp(offer, >offermsg, offer_sz) == 0)
+ return;
+
+ pr_err("Mismatched offer from the host (relid=%d)!\n",
+ offer->child_relid);
+
+ print_hex_dump_debug("Old vmbus offer: ", DUMP_PREFIX_OFFSET, 4,
+4, >offermsg, offer_sz, false);
+ print_hex_dump_debug("New vmbus offer: ", DUMP_PREFIX_OFFSET, 4,
+4, offer, offer_sz, false);
+ return;
+ }
+
/* Allocate the channel object and save this offer. */
newchannel = alloc_channel();
if (!newchannel) {
--
1.8.3.1
RE: [PATCH 1/2] rtc/fsl: add FTM alarm driver as the wakeup source
-Original Message-
From: Leo Li
Sent: 2019年7月9日 3:41
To: Biwen Li ; a.zu...@towertech.it;
alexandre.bell...@bootlin.com
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Xiaobo Xie
; Jiafei Pan ; Ran Wang
; Biwen Li
Subject: RE: [PATCH 1/2] rtc/fsl: add FTM alarm driver as the wakeup source
> -Original Message-
> From: Biwen Li
> Sent: Friday, July 5, 2019 5:18 AM
> To: a.zu...@towertech.it; alexandre.bell...@bootlin.com; Leo Li
>
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Xiaobo
> Xie ; Jiafei Pan ; Ran Wang
> ; Biwen Li
> Subject: [PATCH 1/2] rtc/fsl: add FTM alarm driver as the wakeup
> source
>
> For the paltforms including LS1012A, LS1021A, LS1028A, LS1043A,
> LS1046A, LS1088A, LS208xA that has the FlexTimer module, implementing
> alarm functions within RTC subsystem to wakeup the system when system
> going to sleep.
>
> Signed-off-by: Biwen Li
> ---
> drivers/rtc/Kconfig | 14 ++
> drivers/rtc/Makefile| 1 +
> drivers/rtc/rtc-fsl-ftm-alarm.c | 417
>
> 3 files changed, 432 insertions(+)
> create mode 100644 drivers/rtc/rtc-fsl-ftm-alarm.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index
> 03b60d5..0758a08
> 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1313,6 +1313,20 @@ config RTC_DRV_IMXDI
> This driver can also be built as a module, if so, the module
> will be called "rtc-imxdi".
>
> +config RTC_DRV_FSL_FTM_ALARM
> + tristate "Freescale FlexTimer alarm timer"
> + depends on ARCH_LAYERSCAPE
> + default y
> + help
> +For the FlexTimer in LS1012A, LS1021A, LS1028A, LS1043A, LS1046A,
> +LS1088A, LS208xA, we can use FTM as the wakeup source.
> +
> +Say y here to enable FTM alarm support. The FTM alarm provides
> +alarm functions for wakeup system from deep sleep.
> +
> +This driver can also be built as a module, if so, the module
> +will be called "rtc-fsl-ftm-alarm".
> +
> config RTC_DRV_MESON
> tristate "Amlogic Meson RTC"
> depends on (ARM && ARCH_MESON) || COMPILE_TEST diff --git
> a/drivers/rtc/Makefile b/drivers/rtc/Makefile index 9d997fa..5cccb07
> 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -79,6 +79,7 @@ obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-
> hid-sensor-time.o
> obj-$(CONFIG_RTC_DRV_HYM8563)+= rtc-hym8563.o
> obj-$(CONFIG_RTC_DRV_IMXDI) += rtc-imxdi.o
> obj-$(CONFIG_RTC_DRV_IMX_SC) += rtc-imx-sc.o
> +obj-$(CONFIG_RTC_DRV_FSL_FTM_ALARM) += rtc-fsl-ftm-alarm.o
> obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
> obj-$(CONFIG_RTC_DRV_ISL12026) += rtc-isl12026.o
> obj-$(CONFIG_RTC_DRV_ISL1208)+= rtc-isl1208.o
> diff --git a/drivers/rtc/rtc-fsl-ftm-alarm.c
> b/drivers/rtc/rtc-fsl-ftm-alarm.c new file mode 100644 index
> 000..e4075f0
> --- /dev/null
> +++ b/drivers/rtc/rtc-fsl-ftm-alarm.c
> @@ -0,0 +1,417 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Freescale FlexTimer Module (FTM) alarm device driver.
> + *
> + * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2019 NXP
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define FTM_SC_CLK(c)((c) << FTM_SC_CLK_MASK_SHIFT)
> +
> +/*
> + * Select Fixed frequency clock as clock source
> + * of FlexTimer Module
> + */
> +#define FTM_SC_CLKS_FIXED_FREQ 0x02
> +
> +#define FIXED_FREQ_CLK 32000
> +#define MAX_FREQ_DIV (1 << FTM_SC_PS_MASK)
> +#define MAX_COUNT_VAL0x
> +
> +struct ftm_rtc {
> + struct rtc_device *rtc_dev;
> + void __iomem *base;
> + bool endian;
> + u32 alarm_freq;
> +};
> +
> +enum pmu_endian_type {
> + BIG_ENDIAN,
> + LITTLE_ENDIAN,
> +};
> +
> +/*
> + * rcpm (Run Control and Power Management)
> + * is another IP block,different IP block
> + * has different endianness,so add new element
> + * big_endian to struct rcpm_cfg.
> + */
> +struct rcpm_cfg {
> + enum pmu_endian_type big_endian; /* Big/Little endian of PMU
> module */
> + u32 flextimer_set_bit; /* FTM is not powerdown during device
> sleep */
> +};
> +
> +static struct rcpm_cfg default_rcpm_cfg = {
> + .big_endian = LITTLE_ENDIAN,
> + .flextimer_set_bit = 0x4000,
> +};
> +
> +static struct rcpm_cfg ls1012a_rcpm_cfg = {
> + .big_endian = BIG_ENDIAN,
> + .flextimer_set_bit = 0x2,
> +};
> +
> +static struct rcpm_cfg ls1021a_rcpm_cfg = {
> + .big_endian = BIG_ENDIAN,
> + .flextimer_set_bit =
Re: [PATCH] rtc: bd70528: fix link error
Hello Arnd,
(Added Randy who also sent a patch to fix this)
On Mon, 2019-07-08 at 18:10 +0200, Arnd Bergmann wrote:
> On Mon, Jul 8, 2019 at 3:24 PM Vaittinen, Matti
> wrote:
>
> > On Mon, 2019-07-08 at 14:41 +0200, Arnd Bergmann wrote:
> > > With CONFIG_BD70528_WATCHDOG=m, a built-in rtc driver cannot call
> > > into the low-level functions that are part of the watchdog
> > > module:
> > >
> > > drivers/rtc/rtc-bd70528.o: In function `bd70528_set_time':
> > > rtc-bd70528.c:(.text+0x22c): undefined reference to
> > > `bd70528_wdt_lock'
> > > rtc-bd70528.c:(.text+0x2a8): undefined reference to
> > > `bd70528_wdt_unlock'
> > > drivers/rtc/rtc-bd70528.o: In function
> > > `bd70528_set_rtc_based_timers':
> > > rtc-bd70528.c:(.text+0x50c): undefined reference to
> > > `bd70528_wdt_set'
> > >
> > > Add a Kconfig dependency on this driver, but still allow compile-
> > > testing
> > > without it.
> > >
> > > Fixes: 32a4a4ebf768 ("rtc: bd70528: Initial support for ROHM
> > > bd70528
> > > RTC")
> > > Signed-off-by: Arnd Bergmann
> > > ---
> > > drivers/rtc/Kconfig | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > > index 3bfc04a86529..7b071cc74422 100644
> > > --- a/drivers/rtc/Kconfig
> > > +++ b/drivers/rtc/Kconfig
> > > @@ -498,8 +498,10 @@ config RTC_DRV_M41T80_WDT
> > > help
> > > If you say Y here you will get support for the
> > > watchdog timer in the ST M41T60 and M41T80 RTC chips
> > > series.
> > > +
> > > config RTC_DRV_BD70528
> > > tristate "ROHM BD70528 PMIC RTC"
> > > + depends on BD70528_WATCHDOG || (COMPILE_TEST &&
> > > !BD70528_WATCHDOG)
> >
> > I am not fan of this. There may well be use-cases where it is
> > desirable
> > to leave the watchdog out but still compile in the RTC. This is why
> > we
> > have static inline stubs in the header for cases where WDG is not
> > compiled in. (RTC does not need to stop WDG if WDG driver is not
> > included)
> >
> > Adding dependency from RTC to MFD for BD70528 should be done - this
> > will avoid most of the issues (And there has been few patches sent
> > for
> > this already). But that's still not complete solution because
> > configuring RTC and MFD to be built in-kernel and WDG as a module
> > will
> > cause errors again.
> >
> > Is there a way to force WDG in-kernel if RTC is in-kernel? (Or
> > disallow configuring RTC in-kernel if WDG is a module - while still
> > allow RTC to be built without WDG?
>
> We could make this
>
> depends on BD70528_WATCHDOG || !BD70528_WATCHDOG
>
> which would allow building with or without watchdog, even when not
> compile-testing, but still disallow the combination of
> .
Thanks for teaching me Arnd! That is clever :) We need something like
depends on MFD_ROHM_BD70528 && (BD70528_WATCHDOG || !BD70528_WATCHDOG)
(I'm not sure if parenthesis are Ok and respected in Kconfig). I would
never have thought of BD70528_WATCHDOG || !BD70528_WATCHDOG - it looks
awkward at first sight but indeed - depends on BD70528_WATCHDOG
disallows BD70528_WATCHDOG=m with RTC_DRV_BD70528=y while
!BD70528_WATCHDOG allows BD70528_WATCHDOG=n. Brilliant and exactly what
we need :) Thanks a bunch!
>
>Arnd
Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption
On 2019/07/08 18:42, Eiichi Tsukata wrote:
>
>
> On 2019/07/08 17:58, Eiichi Tsukata wrote:
>
>>
>> By the way, is there possibility that the WARNING(#GP in execve(2)) which
>> Steven
>> previously hit? :
>> https://lore.kernel.org/lkml/20190321095502.47b51...@gandalf.local.home/
>>
>> Even if there were, it will *Not* be the bug introduced by this patch series,
>> but the bug revealed by this series.
>>
>
> I reproduced with the kernel:
> -
> https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=x86/core=057b48d544b384c47ed921f616128b802ab1fdc3
>
> Reproducer:
>
> # echo 1 > events/preemptirq/irq_disable/enable
> # echo userstacktrace > trace_options
> # service sshd restart
>
> [ 20.338200] [ cut here ]
> [ 20.339471] General protection fault in user access. Non-canonical address?
> [ 20.339488] WARNING: CPU: 1 PID: 1957 at arch/x86/mm/extable.c:126
> ex_handler_uaccess+0x52/0x60
> [ 20.342550] Modules linked in:
> [ 20.343209] CPU: 1 PID: 1957 Comm: systemctl Tainted: GW
> 5.2.0-rc7+ #48
> [ 20.344935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.12.0-2.fc30 04/01/2014
> [ 20.346688] RIP: 0010:ex_handler_uaccess+0x52/0x60
> [ 20.347667] Code: c4 08 b8 01 00 00 00 5b 5d c3 80 3d b6 8c 94 01 00 75 db
> 48 c7 c7 b8 e4 6f aa 48 89 75 f0 c6 05 ad
> [ 20.351508] RSP: 0018:b28940453688 EFLAGS: 00010082
> [ 20.352707] RAX: RBX: aa2023c0 RCX:
> 0001
> [ 20.354478] RDX: RSI: RDI:
> aa7dab8d
> [ 20.355706] RBP: b28940453698 R08: R09:
> 0001
> [ 20.356665] R10: R11: R12:
> b28940453728
> [ 20.357594] R13: R14: 000d R15:
>
> [ 20.358876] FS: 7fec9fa248c0() GS:921d3d80()
> knlGS:
> [ 20.360573] CS: 0010 DS: ES: CR0: 80050033
> [ 20.361792] CR2: 0004 CR3: 74d4e000 CR4:
> 06e0
> [ 20.363300] Call Trace:
> [ 20.363830] fixup_exception+0x4a/0x61
> [ 20.364637] __idt_do_general_protection+0x65/0x1d0
> [ 20.365684] do_general_protection+0x1e/0x30
> [ 20.366654] general_protection+0x1e/0x30
> [ 20.367513] RIP: 0010:arch_stack_walk_user+0x7a/0x100
> [ 20.368583] Code: 00 01 1f 00 0f 85 8d 00 00 00 49 8b 87 98 16 00 00 48 83
> e8 10 49 39 c6 77 32 41 83 87 d0 15 00 04
> [ 20.372797] RSP: 0018:b289404537d0 EFLAGS: 00010046
> [ 20.374027] RAX: RBX: 921d383bcb00 RCX:
> 0074726174736572
> [ 20.375674] RDX: 921d38393b84 RSI: 7265732e64687373 RDI:
> b28940453818
> [ 20.377179] RBP: b28940453808 R08: 0001 R09:
> 921d3d169c00
> [ 20.378681] R10: 0b60 R11: 921d38393b70 R12:
> b28940453818
> [ 20.380195] R13: b28940453f58 R14: 0074726174736572 R15:
> 921d383bcb00
> [ 20.381703] ? profile_setup.cold+0x9b/0x9b
> [ 20.382604] stack_trace_save_user+0x60/0x7d
> [ 20.383520] trace_buffer_unlock_commit_regs+0x17b/0x220
> [ 20.384686] trace_event_buffer_commit+0x6b/0x200
> [ 20.385741] trace_event_raw_event_preemptirq_template+0x7b/0xc0
> [ 20.387067] ? get_page_from_freelist+0x10a/0x13b0
> [ 20.388129] ? __alloc_pages_nodemask+0x178/0x380
> [ 20.389132] trace_hardirqs_off+0xc6/0x100
> [ 20.390006] get_page_from_freelist+0x10a/0x13b0
> [ 20.390997] ? kvm_clock_read+0x18/0x30
> [ 20.391813] ? sched_clock+0x9/0x10
> [ 20.392647] __alloc_pages_nodemask+0x178/0x380
> [ 20.393706] alloc_pages_current+0x87/0xe0
> [ 20.394609] __page_cache_alloc+0xcd/0x110
> [ 20.395491] __do_page_cache_readahead+0xa1/0x1a0
> [ 20.396547] ondemand_readahead+0x220/0x540
> [ 20.397486] page_cache_sync_readahead+0x35/0x50
> [ 20.398511] generic_file_read_iter+0x8d8/0xbd0
> [ 20.399335] ? __might_sleep+0x4b/0x80
> [ 20.400110] ext4_file_read_iter+0x35/0x40
> [ 20.400937] new_sync_read+0x10f/0x1a0
> [ 20.401833] __vfs_read+0x29/0x40
> [ 20.402608] vfs_read+0xc0/0x170
> [ 20.403319] kernel_read+0x31/0x50
The cause was obvious as Linus already said in:
https://lore.kernel.org/lkml/CAHk-=whvxjjbbomqssrb-xhkc6xm8zghsbrgpxh14usey_g...@mail.gmail.com/
stack_trace_save_user() is called after set_fs(KERNEL_DS).
I don't know why systemctl alyways hit this, but user space process can make up
stack
as it like, so we have to check it by ourselves?
ssize_t kernel_read(struct file *file, void *buf, size_t count, loff_t *pos)
{
mm_segment_t old_fs;
ssize_t result;
old_fs = get_fs();
set_fs(KERNEL_DS);
/* The cast to a user pointer is valid due to the set_fs() */
result = vfs_read(file, (void __user *)buf, count, pos);
set_fs(old_fs);
return result;
}
EXPORT_SYMBOL(kernel_read);
> [ 20.404128] prepare_binprm+0x150/0x190
> [
Re: [PATCH v3] perf cs-etm: Improve completeness for kernel address space
Hi Mathieu, On Mon, Jul 08, 2019 at 11:33:59AM -0600, Mathieu Poirier wrote: > On Wed, 19 Jun 2019 at 21:45, Leo Yan wrote: > > > > Arm and arm64 architecture reserve some memory regions prior to the > > symbol '_stext' and these memory regions later will be used by device > > module and BPF jit. The current code misses to consider these memory > > regions thus any address in the regions will be taken as user space > > mode, but perf cannot find the corresponding dso with the wrong CPU > > mode so we misses to generate samples for device module and BPF > > related trace data. > > > > This patch parse the link scripts to get the memory size prior to start > > address and reduce this size from 'etmq->etm->kernel_start', then can > > get a fixed up kernel start address which contain memory regions for > > device module and BPF. Finally, cs_etm__cpu_mode() can return right > > mode for these memory regions and perf can successfully generate > > samples. > > > > The reason for parsing the link scripts is Arm architecture changes text > > offset dependent on different platforms, which define multiple text > > offsets in $kernel/arch/arm/Makefile. This offset is decided when build > > kernel and the final value is extended in the link script, so we can > > extract the used value from the link script. We use the same way to > > parse arm64 link script as well. If fail to find the link script, the > > pre start memory size is assumed as zero, in this case it has no any > > change caused with this patch. > > > > Below is detailed info for testing this patch: > > > > - Build LLVM/Clang 8.0 or later version; > > > > - Configure perf with ~/.perfconfig: > > > > root@debian:~# cat ~/.perfconfig > > # this file is auto-generated. > > [llvm] > > clang-path = /mnt/build/llvm-build/build/install/bin/clang > > kbuild-dir = /mnt/linux-kernel/linux-cs-dev/ > > clang-opt = "-g" > > dump-obj = true > > > > [trace] > > show_zeros = yes > > show_duration = no > > no_inherit = yes > > show_timestamp = no > > show_arg_names = no > > args_alignment = 40 > > show_prefix = yes > > > > - Run 'perf trace' command with eBPF event: > > > > root@debian:~# perf trace -e string \ > > -e $kernel/tools/perf/examples/bpf/augmented_raw_syscalls.c > > > > - Read eBPF program memory mapping in kernel: > > > > root@debian:~# echo 1 > /proc/sys/net/core/bpf_jit_kallsyms > > root@debian:~# cat /proc/kallsyms | grep -E "bpf_prog_.+_sys_[enter|exit]" > > 00086a84 t bpf_prog_f173133dc38ccf87_sys_enter [bpf] > > 00088618 t bpf_prog_c1bd85c092d6e4aa_sys_exit [bpf] > > > > - Launch any program which accesses file system frequently so can hit > > the system calls trace flow with eBPF event; > > > > - Capture CoreSight trace data with filtering eBPF program: > > > > root@debian:~# perf record -e cs_etm/@2007.etr/ \ > > --filter 'filter 0x00086a84/0x800' -a sleep 5s > > > > - Annotate for symbol 'bpf_prog_f173133dc38ccf87_sys_enter': > > > > root@debian:~# perf report > > Then select 'branches' samples and press 'a' to annotate symbol > > 'bpf_prog_f173133dc38ccf87_sys_enter', press 'P' to print to the > > bpf_prog_f173133dc38ccf87_sys_enter.annotation file: > > > > root@debian:~# cat bpf_prog_f173133dc38ccf87_sys_enter.annotation > > > > bpf_prog_f173133dc38ccf87_sys_enter() bpf_prog_f173133dc38ccf87_sys_enter > > Event: branches > > > > Percent int sys_enter(struct syscall_enter_args *args) > > stp x29, x30, [sp, #-16]! > > > > int key = 0; > > mov x29, sp > > > >augmented_args = > > bpf_map_lookup_elem(_filename_map, ); > > stp x19, x20, [sp, #-16]! > > > >augmented_args = > > bpf_map_lookup_elem(_filename_map, ); > > stp x21, x22, [sp, #-16]! > > > > stp x25, x26, [sp, #-16]! > > > > return bpf_get_current_pid_tgid(); > > mov x25, sp > > > > return bpf_get_current_pid_tgid(); > > mov x26, #0x0 // #0 > > > > sub sp, sp, #0x10 > > > > return bpf_map_lookup_elem(pids, ) != NULL; > > add x19, x0, #0x0 > > > > mov x0, #0x0 // #0 > > > > mov x10, #0xfff8 // #-8 > > > > if (pid_filter__has(_filtered, getpid())) > > str w0, [x25, x10] > > > > probe_read(_args->args, > > sizeof(augmented_args->args), args); > > add x1, x25, #0x0 > > > > probe_read(_args->args, > > sizeof(augmented_args->args), args); > > mov x10, #0xfff8 // #-8 > > > > syscall =
Re: [GIT PULL] signal: Removing the task parameter from force_sig
The pull request you sent on Mon, 08 Jul 2019 12:40:05 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git > siginfo-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5ad18b2e60b75c7297a998dea702451d33a052ed Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v2] powerpc: slightly improve cache helpers
Le 08/07/2019 à 21:14, Nathan Chancellor a écrit : On Mon, Jul 08, 2019 at 11:19:30AM +1000, Michael Ellerman wrote: On Fri, 2019-05-10 at 09:24:48 UTC, Christophe Leroy wrote: Cache instructions (dcbz, dcbi, dcbf and dcbst) take two registers that are summed to obtain the target address. Using 'Z' constraint and '%y0' argument gives GCC the opportunity to use both registers instead of only one with the second being forced to 0. Suggested-by: Segher Boessenkool Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/6c5875843b87c3adea2beade9d1b8b3d4523900a cheers This patch causes a regression with clang: Is that a Clang bug ? Do you have a disassembly of the code both with and without this patch in order to compare ? Segher, any idea ? Christophe https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/213944668 I've attached my local bisect/build log. Cheers, Nathan
linux-next: please clean up the mali-dp tree
Hi, Now that a rebased copy of the mali-dp tree has been merged into the drm tree, please clean up the mali-dp tree as it is causing conflicts. -- Cheers, Stephen Rothwell pgpPThBmE24nb.pgp Description: OpenPGP digital signature
Re: [PATCH v5 06/12] S.A.R.A.: WX protection
On Sun, Jul 07, 2019 at 05:49:35PM +0200, Salvatore Mesoraca wrote:
> Al Viro wrote:
> >
> > On Sat, Jul 06, 2019 at 12:54:47PM +0200, Salvatore Mesoraca wrote:
> >
> > > +#define sara_warn_or_return(err, msg) do { \
> > > + if ((sara_wxp_flags & SARA_WXP_VERBOSE))\
> > > + pr_wxp(msg);\
> > > + if (!(sara_wxp_flags & SARA_WXP_COMPLAIN)) \
> > > + return -err;\
> > > +} while (0)
> > > +
> > > +#define sara_warn_or_goto(label, msg) do { \
> > > + if ((sara_wxp_flags & SARA_WXP_VERBOSE))\
> > > + pr_wxp(msg);\
> > > + if (!(sara_wxp_flags & SARA_WXP_COMPLAIN)) \
> > > + goto label; \
> > > +} while (0)
> >
> > No. This kind of "style" has no place in the kernel.
> >
> > Don't hide control flow. It's nasty enough to reviewers,
> > but it's pure hell on anyone who strays into your code while
> > chasing a bug or doing general code audit. In effect, you
> > are creating your oh-so-private C dialect and assuming that
> > everyone who ever looks at your code will start with learning
> > that *AND* incorporating it into their mental C parser.
> > I'm sorry, but you are not that important.
> >
> > If it looks like a function call, a casual reader will assume
> > that this is exactly what it is. And when one is scanning
> > through a function (e.g. to tell if handling of some kind
> > of refcounts is correct, with twentieth grep through the
> > tree having brought something in your code into the view),
> > the last thing one wants is to switch between the area-specific
> > C dialects. Simply because looking at yours is sandwiched
> > between digging through some crap in drivers/target/ and that
> > weird thing in kernel/tracing/, hopefully staying limited
> > to 20 seconds of glancing through several functions in your
> > code.
> >
> > Don't Do That. Really.
>
> I understand your concerns.
> The first version of SARA didn't use these macros,
> they were added because I was asked[1] to do so.
>
> I have absolutely no problems in reverting this change.
> I just want to make sure that there is agreement on this matter.
> Maybe Kees can clarify his stance.
>
> Thank you for your suggestions.
>
> [1]
> https://lkml.kernel.org/r/CAGXu5jJuQx2qOt_aDqDQDcqGOZ5kmr5rQ9Zjv=mrrcj65er...@mail.gmail.com
I just didn't like how difficult it was to review the repeated checking.
I thought then (and still think now) it's worth the unusual style to
improve the immediate readability. Obviously Al disagrees. I'm not
against dropping my suggestion; it's just a pain to review it and it
seems like an area that would be highly prone to subtle typos. Perhaps
some middle ground:
#define sara_warn(msg) ({ \
if ((sara_wxp_flags & SARA_WXP_VERBOSE))\
pr_wxp(msg);\
!(sara_wxp_flags & SARA_WXP_COMPLAIN); \
})
...
if (unlikely(sara_wxp_flags & SARA_WXP_WXORX &&
vm_flags & VM_WRITE &&
vm_flags & VM_EXEC &&
sara_warn("W^X")))
return -EPERM;
that way the copy/pasting isn't present but the control flow is visible?
--
Kees Cook
Re: Procedure questions - new filesystem driver..
On Mon, Jul 08, 2019 at 08:37:42PM -0400, Valdis Klētnieks wrote: > I have an out-of-tree driver for the exfat file system that I beaten into > shape > for upstreaming. The driver works, and passes sparse and checkpatch (except > for a number of line-too-long complaints). > > Do you want this taken straight to the fs/ tree, or through drivers/staging? How have you dealt with the patent claims which Microsoft has asserted[1] on the exFAT file system design? [1] https://www.microsoft.com/en-us/legal/intellectualproperty/mtl/exfat-licensing.aspx I am not making any claims about the validity of Microsoft's patent assertions on exFAT, one way or another. But it might be a good idea for some laywers from the Linux Foundation to render some legal advice to their employees (namely Greg K-H and Linus Torvalds) regarding the advisability of taking exFAT into the official Linux tree. Personally, if Microsoft is going to be unfriendly about not wanting others to use their file system technology by making patent claims, why should we reward them by making their file system better by improvings its interoperability? (My personal opinion only.) Cheers, - Ted
Re: [PATCH v3] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()
Wen Yang writes:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> v3: fix a leaked reference.
> v2: clean up the code according to the advice of viresh.
>
> drivers/cpufreq/pasemi-cpufreq.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/pasemi-cpufreq.c
> b/drivers/cpufreq/pasemi-cpufreq.c
> index 6b1e4ab..9dc5163 100644
> --- a/drivers/cpufreq/pasemi-cpufreq.c
> +++ b/drivers/cpufreq/pasemi-cpufreq.c
> @@ -128,20 +128,20 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
> int cur_astate, idx;
> struct resource res;
> struct device_node *cpu, *dn;
> - int err = -ENODEV;
> + int err;
>
> cpu = of_get_cpu_node(policy->cpu, NULL);
> -
> - of_node_put(cpu);
> if (!cpu)
> - goto out;
> + return -ENODEV;
I don't think introducing another exit path is an improvement.
> dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
> if (!dn)
> dn = of_find_compatible_node(NULL, NULL,
>"pasemi,pwrficient-sdc");
> - if (!dn)
> + if (!dn) {
> + err = -ENODEV;
> goto out;
> + }
> err = of_address_to_resource(dn, 0, );
> of_node_put(dn);
> if (err)
> @@ -196,6 +196,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
> policy->cur = pas_freqs[cur_astate].frequency;
> ppc_proc_freq = policy->cur * 1000ul;
>
> + of_node_put(cpu);
> return cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
>
> out_unmap_sdcpwr:
> @@ -204,6 +205,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
> out_unmap_sdcasr:
> iounmap(sdcasr_mapbase);
> out:
> + of_node_put(cpu);
> return err;
> }
Notice that cpu is only used for the max_freq calculation, so we could
instead do:
diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 6b1e4abe3248..42a0a4b8e87d 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -131,11 +131,20 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
*policy)
int err = -ENODEV;
cpu = of_get_cpu_node(policy->cpu, NULL);
-
- of_node_put(cpu);
if (!cpu)
goto out;
+ max_freqp = of_get_property(cpu, "clock-frequency", NULL);
+ if (!max_freqp) {
+ of_node_put(cpu);
+ err = -EINVAL;
+ goto out;
+ }
+
+ /* we need the freq in kHz */
+ max_freq = *max_freqp / 1000;
+ of_node_put(cpu);
+
dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
if (!dn)
dn = of_find_compatible_node(NULL, NULL,
@@ -172,15 +181,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
*policy)
pr_debug("init cpufreq on CPU %d\n", policy->cpu);
- max_freqp = of_get_property(cpu, "clock-frequency", NULL);
- if (!max_freqp) {
- err = -EINVAL;
- goto out_unmap_sdcpwr;
- }
-
- /* we need the freq in kHz */
- max_freq = *max_freqp / 1000;
-
pr_debug("max clock-frequency is at %u kHz\n", max_freq);
pr_debug("initializing frequency table\n");
Though arguably this function should hold a reference to cpu anyway,
because it doesn't want the CPU to removed out from under it. It's a
CPUfreq driver after all.
cheers
Re: [GIT PULL] cgroup changes for v5.3-rc1
The pull request you sent on Mon, 8 Jul 2019 10:10:05 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-5.3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/92c1d6522135050cb377a18cc6e30d08dfb87efb Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] workqueue changes for v5.3-rc1
The pull request you sent on Mon, 8 Jul 2019 09:56:20 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-5.3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/df2a40f549e6b73aad98b0c03f400c00d284816b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 2/2] arm64: dts: imx8mm: Assign highest opp as suspend opp
On 08-07-19, 08:54, Anson Huang wrote: > Each OPP has "opp-supported-hw" property as below, the first value needs to be > checked with speed grading fuse, and the second one needs to be checked with > market segment fuse, ONLY both of them passed, then this OPP is supported. It > calls dev_pm_opp_set_supported_hw() to tell OPP framework to parse the OPP > table, this is my understanding. > > opp-supported-hw = <0x8>, <0x3>; Right, so that's what I was expecting. One thing we can do is change the binding of OPP core a bit to allow multiple OPP nodes to contain the "opp-suspend" property and select the one finally with the highest frequency. That would be a better as a generic solution IMO. And then a small OPP core patch will fix it. -- viresh
Re: [GIT] Crypto Update for 5.3
The pull request you sent on Mon, 8 Jul 2019 23:08:00 +0800: > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4d2fa8b44b891f0da5ceda3e5a1402ccf0ab6f26 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 5.1 00/96] 5.1.17-stable review
On Mon, 8 Jul 2019 at 21:02, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.17 release. > There are 96 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 10 Jul 2019 03:03:52 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.17-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.1.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.1.17-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.1.y git commit: b64119f8dffe14ab62bbe65e01e72c102be085a9 git describe: v5.1.16-97-gb64119f8dffe Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.1-oe/build/v5.1.16-97-gb64119f8dffe No regressions (compared to build v5.1.16) No fixes (compared to build v5.1.16) Ran 18086 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * network-basic-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 2/2] x86/numa: instance all parsed numa node
On Tue, Jul 9, 2019 at 1:53 AM Andy Lutomirski wrote: > > > > > On Jul 8, 2019, at 3:35 AM, Thomas Gleixner wrote: > > > >> On Mon, 8 Jul 2019, Pingfan Liu wrote: > >>> On Mon, Jul 8, 2019 at 3:44 AM Thomas Gleixner wrote: > >>> > On Fri, 5 Jul 2019, Pingfan Liu wrote: > > I hit a bug on an AMD machine, with kexec -l nr_cpus=4 option. nr_cpus > option > is used to speed up kdump process, so it is not a rare case. > >>> > >>> But fundamentally wrong, really. > >>> > >>> The rest of the CPUs are in a half baken state and any broadcast event, > >>> e.g. MCE or a stray IPI, will result in a undiagnosable crash. > >> Very appreciate if you can pay more word on it? I tried to figure out > >> your point, but fail. > >> > >> For "a half baked state", I think you concern about LAPIC state, and I > >> expand this point like the following: > > > > It's not only the APIC state. It's the state of the CPUs in general. > > > >> For IPI: when capture kernel BSP is up, the rest cpus are still loop > >> inside crash_nmi_callback(), so there is no way to eject new IPI from > >> these cpu. Also we disable_local_APIC(), which effectively prevent the > >> LAPIC from responding to IPI, except NMI/INIT/SIPI, which will not > >> occur in crash case. > > > > Fair enough for the IPI case. > > > >> For MCE, I am not sure whether it can broadcast or not between cpus, > >> but as my understanding, it can not. Then is it a problem? > > > > It can and it does. > > > > That's the whole point why we bring up all CPUs in the 'nosmt' case and > > shut the siblings down again after setting CR4.MCE. Actually that's in fact > > a 'let's hope no MCE hits before that happened' approach, but that's all we > > can do. > > > > If we don't do that then the MCE broadcast can hit a CPU which has some > > firmware initialized state. The result can be a full system lockup, triple > > fault etc. > > > > So when the MCE hits a CPU which is still in the crashed kernel lala state, > > then all hell breaks lose. > > > >> From another view point, is there any difference between nr_cpus=1 and > >> nr_cpus> 1 in crashing case? If stray IPI raises issue to nr_cpus>1, > >> it does for nr_cpus=1. > > > > Anything less than the actual number of present CPUs is problematic except > > you use the 'let's hope nothing happens' approach. We could add an option > > to stop the bringup at the early online state similar to what we do for > > 'nosmt'. > > > > > > How about we change nr_cpus to do that instead so we never have to have this > conversation again? Are you interest in implementing this? Thanks, Pingfan
[PATCH 09/11] kbuild: remove the first line of *.mod files
The current format of *.mod is like this:
line 1: directory path to the .ko file
line 2: a list of objects linked into this module
line 3: unresolved symbols (only when CONFIG_TRIM_UNSED_SYMBOLS=y)
Now that *.mod and *.ko are created in the same directory, the line 1
provides no valuable information. It can be derived by replacing the
extension .mod with .ko.
Cut the first line.
Signed-off-by: Masahiro Yamada
---
scripts/Makefile.build | 4 ++--
scripts/adjust_autoksyms.sh | 2 +-
scripts/mod/sumversion.c| 9 ++---
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 1d01324455d1..f34f941c3b9b 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -281,7 +281,7 @@ $(obj)/%.o: $(src)/%.c $(recordmcount_source)
$(objtool_dep) FORCE
$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep)
FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
- @{ echo $(@:.o=.ko); echo $@; \
+ @{ echo $@; \
$(cmd_undef_syms); } > $(patsubst %.o,%.mod,$@)
quiet_cmd_cc_lst_c = MKLST $@
@@ -463,7 +463,7 @@ cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter
%.o,$^) $(cmd_secanalysis
$(multi-used-m): FORCE
$(call if_changed,link_multi-m)
- @{ echo $(@:.o=.ko); echo $(filter %.o,$^); \
+ @{ echo $(filter %.o,$^); \
$(cmd_undef_syms); } > $(patsubst %.o,%.mod,$@)
$(call multi_depend, $(multi-used-m), .o, -objs -y -m)
diff --git a/scripts/adjust_autoksyms.sh b/scripts/adjust_autoksyms.sh
index d3561ff4089c..147de8908797 100755
--- a/scripts/adjust_autoksyms.sh
+++ b/scripts/adjust_autoksyms.sh
@@ -48,7 +48,7 @@ cat > "$new_ksyms_file" << EOT
EOT
sed 's/ko$/mod/' modules.order |
-xargs -r -n1 sed -n -e '3{s/ /\n/g;/^$/!p;}' |
+xargs -r -n1 sed -n -e '2{s/ /\n/g;/^$/!p;}' |
sort -u |
sed -e 's/\(.*\)/#define __KSYM_\1 1/' >> "$new_ksyms_file"
diff --git a/scripts/mod/sumversion.c b/scripts/mod/sumversion.c
index 166f3fa247a9..63062024ce0e 100644
--- a/scripts/mod/sumversion.c
+++ b/scripts/mod/sumversion.c
@@ -398,7 +398,7 @@ void get_src_version(const char *modname, char sum[],
unsigned sumlen)
char *sources, *end, *fname;
char filelist[PATH_MAX + 1];
- /* objects for a module are listed in the second line of *.mod file. */
+ /* objects for a module are listed in the first line of *.mod file. */
snprintf(filelist, sizeof(filelist), "%.*smod",
(int)strlen(modname) - 1, modname);
@@ -407,13 +407,8 @@ void get_src_version(const char *modname, char sum[],
unsigned sumlen)
/* not a module or .mod file missing - ignore */
return;
- sources = strchr(file, '\n');
- if (!sources) {
- warn("malformed versions file for %s\n", modname);
- goto release;
- }
+ sources = file;
- sources++;
end = strchr(sources, '\n');
if (!end) {
warn("bad ending versions file for %s\n", modname);
--
2.17.1
[PATCH 07/11] kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod
Towards the goal of removing MODVERDIR, read out modules.order to get the list of modules to be processed. This is simpler than parsing *.mod files in $(MODVERDIR). For external modules, $(KBUILD_EXTMOD)/modules.order should be read. Signed-off-by: Masahiro Yamada --- scripts/Makefile.modpost | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost index fec6ec2ffa47..2ab1694a7df3 100644 --- a/scripts/Makefile.modpost +++ b/scripts/Makefile.modpost @@ -8,9 +8,10 @@ # b) A .o file which is the .o files above linked together # c) A .mod file in $(MODVERDIR)/, listing the name of the #the preliminary .o file, plus all .o files +# d) modules.order, which lists all the modules # Stage 2 is handled by this file and does the following -# 1) Find all modules from the files listed in $(MODVERDIR)/ +# 1) Find all modules listed in modules.order # 2) modpost is then used to # 3) create one .mod.c file pr. module # 4) create one Module.symvers file with CRC for all exported symbols @@ -60,10 +61,10 @@ include scripts/Makefile.lib kernelsymfile := $(objtree)/Module.symvers modulesymfile := $(firstword $(KBUILD_EXTMOD))/Module.symvers -# Step 1), find all modules listed in $(MODVERDIR)/ -MODLISTCMD := find $(MODVERDIR) -name '*.mod' | xargs -r grep -h '\.ko$$' | sort -u -__modules := $(shell $(MODLISTCMD)) -modules := $(patsubst %.o,%.ko, $(wildcard $(__modules:.ko=.o))) +modorder := $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/)modules.order + +# Step 1), find all modules listed in modules.order +modules := $(sort $(shell cat $(modorder))) # Stop after building .o files if NOFINAL is set. Makes compile tests quicker _modpost: $(if $(KBUILD_MODPOST_NOFINAL), $(modules:.ko:.o),$(modules)) @@ -84,7 +85,7 @@ MODPOST_OPT=$(subst -i,-n,$(filter -i,$(MAKEFLAGS))) # We can go over command line length here, so be careful. quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux FORCE, $^)) modules - cmd_modpost = $(MODLISTCMD) | sed 's/\.ko$$/.o/' | $(modpost) $(MODPOST_OPT) -s -T - + cmd_modpost = sed 's/ko$$/o/' $(modorder) | $(modpost) $(MODPOST_OPT) -s -T - PHONY += __modpost __modpost: $(modules:.ko=.o) FORCE -- 2.17.1
[PATCH 04/11] scsi: remove pointless $(MODVERDIR)/$(obj)/53c700.ver
Nothing depends on this, so it is dead code. Signed-off-by: Masahiro Yamada --- I will apply this to kbuild tree since it is trivial. drivers/scsi/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index 8826111fdf4a..acdd57e647f8 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -183,7 +183,7 @@ zalon7xx-objs := zalon.o ncr53c8xx.o # Files generated that shall be removed upon make clean clean-files := 53c700_d.h 53c700_u.h scsi_devinfo_tbl.c -$(obj)/53c700.o $(MODVERDIR)/$(obj)/53c700.ver: $(obj)/53c700_d.h +$(obj)/53c700.o: $(obj)/53c700_d.h $(obj)/scsi_sysfs.o: $(obj)/scsi_devinfo_tbl.c -- 2.17.1
[PATCH 05/11] kbuild: modinst: read modules.order instead of $(MODVERDIR)/*.mod
Towards the goal of removing MODVERDIR, read out modules.order to get the list of modules to be installed. This is simpler than parsing *.mod files in $(MODVERDIR). For external modules, $(KBUILD_EXTMOD)/modules.order should be read. Signed-off-by: Masahiro Yamada --- scripts/Makefile.modinst | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst index 0dae402661f3..5a4579e76485 100644 --- a/scripts/Makefile.modinst +++ b/scripts/Makefile.modinst @@ -8,10 +8,7 @@ __modinst: include scripts/Kbuild.include -# - -__modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard $(MODVERDIR)/*.mod))) -modules := $(patsubst %.o,%.ko,$(wildcard $(__modules:.ko=.o))) +modules := $(sort $(shell cat $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/)modules.order)) PHONY += $(modules) __modinst: $(modules) -- 2.17.1
[PATCH 11/11] kbuild: split out *.mod out of {single,multi}-used-m rules
Currently, *.mod is created as a side-effect of obj-m.
Split out *.mod as a dedicated build rule, which allows to
unify the %.c -> %.o rule, and remove the single-used-m rule.
This also makes the incremental build of allmodconfig faster because
it saves $(NM) invocation when there is no change in the module.
Signed-off-by: Masahiro Yamada
---
scripts/Makefile.build | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index f34f941c3b9b..00bd3bc1d6ba 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -69,8 +69,10 @@ modorder-target := $(obj)/modules.order
endif
endif
+mod-targets := $(patsubst %.o, %.mod, $(obj-m))
+
__build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y)) \
-$(if $(KBUILD_MODULES),$(obj-m) $(modorder-target)) \
+$(if $(KBUILD_MODULES),$(obj-m) $(mod-targets) $(modorder-target)) \
$(subdir-ym) $(always)
@:
@@ -268,7 +270,7 @@ endef
# List module undefined symbols (or empty line if not enabled)
ifdef CONFIG_TRIM_UNUSED_KSYMS
-cmd_undef_syms = $(NM) $@ | sed -n 's/^ *U //p' | xargs echo
+cmd_undef_syms = $(NM) $< | sed -n 's/^ *U //p' | xargs echo
else
cmd_undef_syms = echo
endif
@@ -278,11 +280,15 @@ $(obj)/%.o: $(src)/%.c $(recordmcount_source)
$(objtool_dep) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
-$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep)
FORCE
- $(call cmd,force_checksrc)
- $(call if_changed_rule,cc_o_c)
- @{ echo $@; \
- $(cmd_undef_syms); } > $(patsubst %.o,%.mod,$@)
+cmd_mod = { \
+ echo $(if $($*-objs)$($*-y)$($*-m), $(addprefix $(obj)/, $($*-objs)
$($*-y) $($*-m)), $(@:.mod=.o)); \
+ $(cmd_undef_syms); \
+ } > $@
+
+$(obj)/%.mod: $(obj)/%.o FORCE
+ $(call if_changed,mod)
+
+targets += $(mod-targets)
quiet_cmd_cc_lst_c = MKLST $@
cmd_cc_lst_c = $(CC) $(c_flags) -g -c -o $*.o $< && \
@@ -463,8 +469,6 @@ cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter
%.o,$^) $(cmd_secanalysis
$(multi-used-m): FORCE
$(call if_changed,link_multi-m)
- @{ echo $(filter %.o,$^); \
- $(cmd_undef_syms); } > $(patsubst %.o,%.mod,$@)
$(call multi_depend, $(multi-used-m), .o, -objs -y -m)
targets += $(multi-used-m)
--
2.17.1
[PATCH 03/11] kbuild: remove duplication from modules.order in sub-directories
Currently, only the top-level modules.order drops duplicated entries.
The modules.order files in sub-directories potentially contain
duplication. To list out the paths of all modules, I want to use
modules.order instead of parsing *.mod files in $(MODVERDIR).
To achieve this, I want to rip off duplication from modules.order
of external modules too.
Signed-off-by: Masahiro Yamada
---
scripts/Makefile.build | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index d827b7a36892..1492e37c3927 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -425,13 +425,10 @@ endif # builtin-target
#
# Create commands to either record .ko file or cat modules.order from
# a subdirectory
-modorder-cmds =\
- $(foreach m, $(modorder), \
- $(if $(filter %/modules.order, $m), \
- cat $m;, echo $m;))
-
$(modorder-target): $(subdir-ym) FORCE
- $(Q)(cat /dev/null; $(modorder-cmds)) > $@
+ $(Q){ $(foreach m, $(modorder), \
+ $(if $(filter %/modules.order, $m), cat $m, echo $m);) :; } \
+ | $(AWK) '!x[$$0]++' - > $@
#
# Rule to compile a set of .o files into one .a file (with symbol table)
--
2.17.1
[PATCH 10/11] kbuild: remove 'prepare1' target
Now that there is no rule for 'prepare1', it can go away. Signed-off-by: Masahiro Yamada --- Makefile | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 958fafa605b9..b284863e7ea0 100644 --- a/Makefile +++ b/Makefile @@ -1094,7 +1094,7 @@ scripts: scripts_basic scripts_dtc # archprepare is used in arch Makefiles and when processed asm symlink, # version.h and scripts_basic is processed / created. -PHONY += prepare archprepare prepare1 prepare3 +PHONY += prepare archprepare prepare3 # prepare3 is used to check if we are building in a separate output directory, # and if so do: @@ -,10 +,8 @@ ifneq ($(srctree),.) fi; endif -prepare1: prepare3 outputmakefile asm-generic $(version_h) $(autoksyms_h) \ - include/generated/utsrelease.h - -archprepare: archheaders archscripts prepare1 scripts +archprepare: archheaders archscripts scripts prepare3 outputmakefile \ + asm-generic $(version_h) $(autoksyms_h) include/generated/utsrelease.h prepare0: archprepare $(Q)$(MAKE) $(build)=scripts/mod -- 2.17.1
[PATCH 06/11] kbuild: modsign: read modules.order instead of $(MODVERDIR)/*.mod
Towards the goal of removing MODVERDIR, read out modules.order to get the list of modules to be signed. This is simpler than parsing *.mod files in $(MODVERDIR). The modules_sign target is only supported for in-kernel modules. So, this commit does not take care of external modules. Signed-off-by: Masahiro Yamada --- scripts/Makefile.modsign | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/scripts/Makefile.modsign b/scripts/Makefile.modsign index da56aa78d245..d7325cefe709 100644 --- a/scripts/Makefile.modsign +++ b/scripts/Makefile.modsign @@ -8,8 +8,7 @@ __modsign: include scripts/Kbuild.include -__modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard $(MODVERDIR)/*.mod))) -modules := $(patsubst %.o,%.ko,$(wildcard $(__modules:.ko=.o))) +modules := $(sort $(shell cat modules.order)) PHONY += $(modules) __modsign: $(modules) -- 2.17.1
[PATCH 08/11] kbuild: create *.mod with full directory path and remove MODVERDIR
While descending directories, Kbuild produces objects for modules,
but final *.ko files are linked in the modpost.
To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR)
for every module it is building. Some post-processing steps read the
necessary information from *.mod files. This avoids descending into
directories again. This mechanism was introduced in 2003 or so.
Later, commit 551559e13af1 ("kbuild: implement modules.order") added
modules.order. So, we can simply read it out to know all the modules
with directory paths. This is easier than parsing the first line of
*.mod files.
$(MODVERDIR) has a flat structure. This is based on the assumption
that the module name is unique. This assumption is really fragile.
Stephen Rothwell reported a race condition caused by a module name
conflict:
https://lkml.org/lkml/2019/5/13/991
In parallel building, two different threads could write to the same
$(MODVERDIR)/*.mod simultaneously.
Non-unique module names are the source of all kind of troubles, hence
commit 3a48a91901c5 ("kbuild: check uniqueness of module names")
introduced a new checker script.
However, it is still fragile in the build system point of view because
this race happens before scripts/modules-check.sh is invoked. If it
happens again, the modpost will emit unclear error messages.
To fix this issue completely, create *.mod in the same directory as
*.ko so that two threads never attempt to write to the same .mod file.
$(MODVERDIR) is no longer needed.
Since modules with directory paths are listed in modules.order, Kbuild
is still able to find *.mod files without additional descending.
Signed-off-by: Masahiro Yamada
---
.gitignore | 1 +
Documentation/dontdiff | 1 +
Makefile| 20 +++-
scripts/Makefile.build | 8 ++--
scripts/Makefile.modpost| 4 ++--
scripts/adjust_autoksyms.sh | 11 ---
scripts/mod/sumversion.c| 16 +++-
scripts/package/mkspec | 2 +-
8 files changed, 17 insertions(+), 46 deletions(-)
diff --git a/.gitignore b/.gitignore
index 7587ef56b92d..8f5422cba6e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,6 +30,7 @@
*.lz4
*.lzma
*.lzo
+*.mod
*.mod.c
*.o
*.o.*
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 5eba889ea84d..9f4392876099 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -30,6 +30,7 @@
*.lzo
*.mo
*.moc
+*.mod
*.mod.c
*.o
*.o.*
diff --git a/Makefile b/Makefile
index 2f40cf704119..958fafa605b9 100644
--- a/Makefile
+++ b/Makefile
@@ -488,11 +488,6 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE
KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
export KBUILD_ARFLAGS
-# When compiling out-of-tree modules, put MODVERDIR in the module
-# tree rather than in the kernel tree. The kernel tree might
-# even be read-only.
-export MODVERDIR := $(if $(KBUILD_EXTMOD),$(firstword
$(KBUILD_EXTMOD))/).tmp_versions
-
# Files to ignore in find ... statements
export RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o
\
@@ -1034,7 +1029,7 @@ vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_OBJS)
$(KBUILD_VMLINUX_LIBS)
# Recurse until adjust_autoksyms.sh is satisfied
PHONY += autoksyms_recursive
-autoksyms_recursive: $(vmlinux-deps)
+autoksyms_recursive: $(vmlinux-deps) modules.order
ifdef CONFIG_TRIM_UNUSED_KSYMS
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
"$(MAKE) -f $(srctree)/Makefile vmlinux"
@@ -1118,7 +1113,6 @@ endif
prepare1: prepare3 outputmakefile asm-generic $(version_h) $(autoksyms_h) \
include/generated/utsrelease.h
- $(cmd_crmodverdir)
archprepare: archheaders archscripts prepare1 scripts
@@ -1376,7 +1370,7 @@ endif # CONFIG_MODULES
# make distclean Remove editor backup files, patch leftover files and the like
# Directories & files removed with 'make clean'
-CLEAN_DIRS += $(MODVERDIR) include/ksym
+CLEAN_DIRS += include/ksym
CLEAN_FILES += modules.builtin.modinfo
# Directories & files removed with 'make mrproper'
@@ -1637,7 +1631,6 @@ PHONY += $(clean-dirs) clean
$(clean-dirs):
$(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@)
-clean: rm-dirs := $(MODVERDIR)
clean: rm-files := $(KBUILD_EXTMOD)/Module.symvers
PHONY += help
@@ -1651,8 +1644,6 @@ help:
@echo ''
PHONY += prepare
-prepare:
- $(cmd_crmodverdir)
endif # KBUILD_EXTMOD
clean: $(clean-dirs)
@@ -1663,7 +1654,7 @@ clean: $(clean-dirs)
-o -name '*.ko.*' \
-o -name '*.dtb' -o -name '*.dtb.S' -o -name '*.dt.yaml' \
-o -name '*.dwo' -o -name '*.lst' \
- -o -name '*.su' \
+ -o -name '*.su' -o -name '*.mod' \
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
-o -name '*.lex.c' -o -name '*.tab.[ch]' \
-o -name '*.asn1.[ch]' \
@@
[PATCH 01/11] kbuild: do not create empty modules.order in the prepare stage
Currently, $(objtree)/modules.order is touched in two places. In the 'prepare0' rule, scripts/Makefile.build creates an empty modules.order while processing 'obj=.' In the 'modules' rule, the top-level Makefile overwrites it with the correct list of modules. It might be a good side-effect that modules.order is made empty every time (probably this is not intended functionality), but I personally do not like this behavior. Kbuild descends into some directories in the preparation stage, where created modules.order files may be broken. Export 'preparing' while running the 'prepare' target, and when it is defined, do not touch modules.order at all. Signed-off-by: Masahiro Yamada --- Makefile | 1 + scripts/Makefile.build | 2 ++ 2 files changed, 3 insertions(+) diff --git a/Makefile b/Makefile index 5c75ea7177f6..a31b672d512b 100644 --- a/Makefile +++ b/Makefile @@ -1000,6 +1000,7 @@ ifdef CONFIG_STACK_VALIDATION endif PHONY += prepare0 +prepare: export preparing=1 ifeq ($(KBUILD_EXTMOD),) core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/ diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 776842b7e6a3..93c20664bcbb 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -64,8 +64,10 @@ builtin-target := $(obj)/built-in.a endif ifdef CONFIG_MODULES +ifndef preparing modorder-target := $(obj)/modules.order endif +endif # We keep a list of all modules in $(MODVERDIR) -- 2.17.1
[PATCH 02/11] kbuild: get rid of kernel/ prefix from in-tree modules.{order,builtin}
Removing the 'kernel/' prefix will make our life easier because we can
simply do 'cat modules.order' to get all built modules with full paths.
Currently, we parse the first line of '*.mod' files in $(MODVERDIR).
Since we have duplicated functionality here, I plan to remove MODVERDIR
entirely.
In fact, modules.order is generated also for external modules in a
broken format. It adds the 'kernel/' prefix to the absolute path of
the module, like this:
kernel//path/to/your/external/module/foo.ko
This is fine for now since modules.order is not used for external
modules. However, I want to sanitize the format everywhere towards
the goal of removing MODVERDIR.
We cannot change the format of installed module.{order,builtin}.
So, 'make modules_install' will add the 'kernel/' prefix while copying
them to $(MODLIB)/.
Signed-off-by: Masahiro Yamada
---
Makefile| 4 ++--
scripts/Makefile.build | 2 +-
scripts/Makefile.modbuiltin | 2 +-
scripts/modules-check.sh| 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index a31b672d512b..2f40cf704119 100644
--- a/Makefile
+++ b/Makefile
@@ -1334,8 +1334,8 @@ _modinst_:
rm -f $(MODLIB)/build ; \
ln -s $(CURDIR) $(MODLIB)/build ; \
fi
- @cp -f $(objtree)/modules.order $(MODLIB)/
- @cp -f $(objtree)/modules.builtin $(MODLIB)/
+ @sed 's:^:kernel/:' modules.order > $(MODLIB)/modules.order
+ @sed 's:^:kernel/:' modules.builtin > $(MODLIB)/modules.builtin
@cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 93c20664bcbb..d827b7a36892 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -428,7 +428,7 @@ endif # builtin-target
modorder-cmds =\
$(foreach m, $(modorder), \
$(if $(filter %/modules.order, $m), \
- cat $m;, echo kernel/$m;))
+ cat $m;, echo $m;))
$(modorder-target): $(subdir-ym) FORCE
$(Q)(cat /dev/null; $(modorder-cmds)) > $@
diff --git a/scripts/Makefile.modbuiltin b/scripts/Makefile.modbuiltin
index ea90a90b41a0..12ac300fe51b 100644
--- a/scripts/Makefile.modbuiltin
+++ b/scripts/Makefile.modbuiltin
@@ -40,7 +40,7 @@ __modbuiltin: $(modbuiltin-target) $(subdir-ym)
@:
$(modbuiltin-target): $(subdir-ym) FORCE
- $(Q)(for m in $(modbuiltin-mods); do echo kernel/$$m; done; \
+ $(Q)(for m in $(modbuiltin-mods); do echo $$m; done;\
cat /dev/null $(modbuiltin-subdirs)) > $@
PHONY += FORCE
diff --git a/scripts/modules-check.sh b/scripts/modules-check.sh
index 39e8cb36ba19..f51f446707b8 100755
--- a/scripts/modules-check.sh
+++ b/scripts/modules-check.sh
@@ -9,7 +9,7 @@ check_same_name_modules()
for m in $(sed 's:.*/::' modules.order | sort | uniq -d)
do
echo "warning: same module names found:" >&2
- sed -n "/\/$m/s:^kernel/: :p" modules.order >&2
+ sed -n "/\/$m/s:^: :p" modules.order >&2
done
}
--
2.17.1
[PATCH 00/11] kbuild: create *.mod with directory path and remove MODVERDIR
This series kills the long standing MODVERDIR.
Since MODVERDIR has a flat structure, it cannot avoid a race
condition when somebody introduces a module name conflict.
Kbuild now reads modules.order to get the list of all modules.
The post-processing/installation stages will be more robust
and simpler.
Masahiro Yamada (11):
kbuild: do not create empty modules.order in the prepare stage
kbuild: get rid of kernel/ prefix from in-tree modules.{order,builtin}
kbuild: remove duplication from modules.order in sub-directories
scsi: remove pointless $(MODVERDIR)/$(obj)/53c700.ver
kbuild: modinst: read modules.order instead of $(MODVERDIR)/*.mod
kbuild: modsign: read modules.order instead of $(MODVERDIR)/*.mod
kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod
kbuild: create *.mod with full directory path and remove MODVERDIR
kbuild: remove the first line of *.mod files
kbuild: remove 'prepare1' target
kbuild: split out *.mod out of {single,multi}-used-m rules
.gitignore | 1 +
Documentation/dontdiff | 1 +
Makefile| 33 +
drivers/scsi/Makefile | 2 +-
scripts/Makefile.build | 33 -
scripts/Makefile.modbuiltin | 2 +-
scripts/Makefile.modinst| 5 +
scripts/Makefile.modpost| 17 +
scripts/Makefile.modsign| 3 +--
scripts/adjust_autoksyms.sh | 11 ---
scripts/mod/sumversion.c| 23 ---
scripts/modules-check.sh| 2 +-
scripts/package/mkspec | 2 +-
13 files changed, 50 insertions(+), 85 deletions(-)
--
2.17.1
Re: WARNING in mark_chain_precision
Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: WARNING in bpf_jit_free WARNING: CPU: 0 PID: 9077 at kernel/bpf/core.c:851 bpf_jit_free+0x157/0x1b0 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 9077 Comm: kworker/0:3 Not tainted 5.2.0-rc6+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events bpf_prog_free_deferred Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 panic+0x2cb/0x744 kernel/panic.c:219 __warn.cold+0x20/0x4d kernel/panic.c:576 report_bug+0x263/0x2b0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] fixup_bug arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986 RIP: 0010:bpf_jit_free+0x157/0x1b0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5d 48 b8 00 02 00 00 00 00 ad de 48 39 43 70 0f 84 05 ff ff ff e8 09 7f f4 ff <0f> 0b e9 f9 fe ff ff e8 2d 02 2e 00 e9 d9 fe ff ff 48 89 7d e0 e8 RSP: 0018:888084affcb0 EFLAGS: 00010293 RAX: 88808a622100 RBX: 88809639d580 RCX: 817b0b0d RDX: RSI: 817c4557 RDI: 88809639d5f0 RBP: 888084affcd0 R08: 1150daa8 R09: fbfff150daa9 R10: fbfff150daa8 R11: 8a86d547 R12: c90001921000 R13: 88809639d5e8 R14: 8880a0589800 R15: 8880ae834d40 bpf_prog_free_deferred+0x27a/0x350 kernel/bpf/core.c:1982 process_one_work+0x989/0x1790 kernel/workqueue.c:2269 worker_thread+0x98/0xe40 kernel/workqueue.c:2415 kthread+0x354/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Kernel Offset: disabled Rebooting in 86400 seconds.. Tested on: commit: b9321614 bpf: fix precision bit propagation for BPF_ST ins.. git tree: https://github.com/anakryiko/linux bpf-fix-precise-bpf_st console output: https://syzkaller.appspot.com/x/log.txt?x=112f0dfda0 kernel config: https://syzkaller.appspot.com/x/.config?x=6bb3e6e7997c14f9 compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Re: [PATCH 4.19 00/90] 4.19.58-stable review
On Mon, 8 Jul 2019 at 20:58, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.58 release. > There are 90 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 10 Jul 2019 03:03:52 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.58-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.19.58-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: c4064b6569551279bd81da840126527a77b0ad20 git describe: v4.19.57-91-gc4064b656955 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.57-91-gc4064b656955 No regressions (compared to build v4.19.57) No fixes (compared to build v4.19.57) Ran 24004 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-containers-tests * ltp-dio-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-mm-tests * ltp-cap_bounds-tests * ltp-commands-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * network-basic-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] selftests/seccomp/seccomp_bpf: update for PTRACE_GET_SYSCALL_INFO
On Mon, Jul 08, 2019 at 09:29:04PM +0300, Dmitry V. Levin wrote: > The syscall entry/exit is now exposed via PTRACE_GETEVENTMSG, > update the test accordingly. Oh yes, thank you! Acked-by: Kees Cook -Kees > > Reported-by: kernel test robot > Signed-off-by: Dmitry V. Levin > --- > tools/testing/selftests/seccomp/seccomp_bpf.c | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c > b/tools/testing/selftests/seccomp/seccomp_bpf.c > index dc66fe852768..6ef7f16c4cf5 100644 > --- a/tools/testing/selftests/seccomp/seccomp_bpf.c > +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c > @@ -1775,13 +1775,18 @@ void tracer_ptrace(struct __test_metadata *_metadata, > pid_t tracee, > unsigned long msg; > static bool entry; > > - /* Make sure we got an empty message. */ > + /* > + * The traditional way to tell PTRACE_SYSCALL entry/exit > + * is by counting. > + */ > + entry = !entry; > + > + /* Make sure we got an appropriate message. */ > ret = ptrace(PTRACE_GETEVENTMSG, tracee, NULL, ); > EXPECT_EQ(0, ret); > - EXPECT_EQ(0, msg); > + EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY > + : PTRACE_EVENTMSG_SYSCALL_EXIT, msg); > > - /* The only way to tell PTRACE_SYSCALL entry/exit is by counting. */ > - entry = !entry; > if (!entry) > return; > > -- > ldv -- Kees Cook
RE: [PATCH v9 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
>Hi,
>
>Pawel Laszczak writes:
+void cdns3_role_stop(struct cdns3 *cdns)
>>>
>>>not static? Why is it so that _start() is static but _stop() is not?
>>>Looks fishy
>>
>> This function is used in cdns3_role_stop in debugfs.c file so it can't
>> be static.
>
>it's still super fishy. Why don't you need _start() from debugfs.c? In
>any case, the role framework would remove the need for any of this, I
>suppose.
Yes, I'm going to use the role framework so it will be probably changed.
>
+static int cdns3_idle_role_start(struct cdns3 *cnds)
+{ /* Hold PHY in RESET */
>>>
>>>huh?
>>>
+ return 0;
+}
+
+static void cdns3_idle_role_stop(struct cdns3 *cnds)
+{
+ /* Program Lane swap and bring PHY out of RESET */
>>>
>>>double huh?
>>>
>>
>> These functions were added for consistency with FSM described in controller
>> specification.
>> Yes, I know that you don't like empty functions :), but it could be helpful
>> in
>> understanding how this controller work.
>
>frankly, it really doesn't. An empty function doesn't really help IMHO.
I will change it.
>
+static const char *const cdns3_mode[] = {
+ [USB_DR_MODE_UNKNOWN] = "unknown",
+ [USB_DR_MODE_OTG] = "otg",
+ [USB_DR_MODE_HOST] = "host",
+ [USB_DR_MODE_PERIPHERAL]= "device",
+};
>>>
>>>don't we have a generic version of this under usb/common ?
>>>
>> Yes, there is a similar array, but it is defined also as static
>> and there is no function for converting value to string.
>> There is only function for converting string to value.
>
>right. You can add the missing interface generically instead of
>duplicating the enumeration.
Patch adding such extension has posted.
>
>> There is also:
>> [USB_DR_MODE_UNKNOWN]= "",
>> Instead of:
>> [USB_DR_MODE_UNKNOWN]= "unknown",
>>
>> So, for USB_DR_MODE_UNKNOWN user will not see anything information.
>
>But that's what "unknown" means :-) We don't know the information.
>
+static irqreturn_t cdns3_drd_irq(int irq, void *data)
+{
+ irqreturn_t ret = IRQ_NONE;
+ struct cdns3 *cdns = data;
+ u32 reg;
+
+ if (cdns->dr_mode != USB_DR_MODE_OTG)
+ return ret;
+
+ reg = readl(>otg_regs->ivect);
+
+ if (!reg)
+ return ret;
+
+ if (reg & OTGIEN_ID_CHANGE_INT) {
+ dev_dbg(cdns->dev, "OTG IRQ: new ID: %d\n",
+ cdns3_get_id(cdns));
+
+ ret = IRQ_HANDLED;
+ }
+
+ if (reg & (OTGIEN_VBUSVALID_RISE_INT | OTGIEN_VBUSVALID_FALL_INT)) {
+ dev_dbg(cdns->dev, "OTG IRQ: new VBUS: %d\n",
+ cdns3_get_vbus(cdns));
+
+ ret = IRQ_HANDLED;
+ }
+
+ if (ret == IRQ_HANDLED)
+ queue_work(system_freezable_wq, >role_switch_wq);
+
+ writel(~0, >otg_regs->ivect);
+ return ret;
+}
>>>
>>>seems like you could use threaded irq to avoid this workqueue.
>>
>>
>> This function is also called in cdns3_mode_write (debugfs.c file),
>> therefor after changing it to threaded irq I will still need workqueue.
>
>Why? debugfs writes are not atomic. They run in process context, right?
>Just don't disable interrupts while running this and you should be fine.
Yes, It should work.
>
+ cdns->desired_dr_mode = cdns->dr_mode;
+ cdns->current_dr_mode = USB_DR_MODE_UNKNOWN;
+
+ ret = devm_request_threaded_irq(cdns->dev, cdns->otg_irq,
+ cdns3_drd_irq,
+ NULL, IRQF_SHARED,
>>>
>>>if you don't have a threaded handler, you should set IRQF_ONESHOT. I
>>>would prefer if you implement a threaded handler that doesn't require
>>>IRQF_ONESHOT, though.
>>>
>>
>> IRQF_ONESHOT can be used only in threaded handled.
>> "
>> * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler
>> finished.
>> *Used by threaded interrupts which need to keep the
>> *irq line disabled until the threaded handler has been run.
>> "
>
>so?
I don't understand why If I don't have threaded handler why I need
IRQF_ONESHOT.
Why interrupt cannot be reenabled after hardirq handler finished ?
I do not use threaded handler so this flag seem unnecessary.
>
+ } else {
+ struct usb_request *request;
+
+ if (priv_dev->eps[index]->flags & EP_WEDGE) {
+ cdns3_select_ep(priv_dev, 0x00);
+ return 0;
+ }
+
+ cdns3_dbg(priv_ep->cdns3_dev, "Clear Stalled endpoint %s\n",
+priv_ep->name);
>>>
>>>why do you need your own wrapper around dev_dbg()? This looks quite
>>>unnecessary.
>>
>> It's generic function used for adding message to trace.log. It's not
>> wrapper to dev_dbg
>>
>> void cdns3_dbg(struct cdns3_device
Re: [PATCH v6 4/4] x86/xen: Add "nopv" support for HVM guest
On 2019/7/8 21:46, Boris Ostrovsky wrote:
On 7/7/19 5:15 AM, Zhenzhong Duan wrote:
+static uint32_t __init xen_platform_hvm(void)
+{
+ if (xen_pv_domain())
+ return 0;
+
+ if (xen_pvh_domain() && nopv) {
+ /* Guest booting via the Xen-PVH boot entry goes here */
+ pr_info("\"nopv\" parameter is ignored in PVH guest\n");
+ nopv = false;
+ } else if (nopv) {
+ /*
+* Guest booting via normal boot entry (like via grub2) goes
+* here.
+*/
+ x86_init.hyper.guest_late_init = xen_hvm_guest_late_init;
+ return 0;
After staring at this some more I don't think we can do this.
Hypervisor-specific code should not muck with with x86_init.hyper, it's
layering violation. That's what init_hypervisor_platform() is for.
Ok, I see.
So we may have to create another hypervisor_x86 ops structure for Xen
nopv (which I don't find very appealing TBH). Or update
x86_hyper_xen_hvm and return xen_cpuid_base() instead of zero (but then
you'd need to update all these structs from __initconst to _init or some
such). Or something else.
I choose the second. I made below changes, not clear if it's also a
layering violation
as use x86_init.hyper as source for memcpy. I choose memcpy instead of
updating
functions pointers one-by-one because if x86_hyper_init interface
functions extends
in the future we need no changes. Let me know if you prefer updating
pointers directly.
This isn't a formal patch for review, just want to get answer of above
question.
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 1756cf7..8416640d 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -231,14 +231,6 @@ bool __init xen_hvm_need_lapic(void)
return true;
}
-static uint32_t __init xen_platform_hvm(void)
-{
- if (xen_pv_domain())
- return 0;
-
- return xen_cpuid_base();
-}
-
static __init void xen_hvm_guest_late_init(void)
{
#ifdef CONFIG_XEN_PVH
@@ -250,6 +242,9 @@ static __init void xen_hvm_guest_late_init(void)
/* PVH detected. */
xen_pvh = true;
+ if (nopv)
+ panic("\"nopv\" and \"xen_nopv\" parameters are
unsupported in PVH guest.");
+
/* Make sure we don't fall back to (default) ACPI_IRQ_MODEL_PIC. */
if (!nr_ioapics && acpi_irq_model == ACPI_IRQ_MODEL_PIC)
acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
@@ -259,7 +254,36 @@ static __init void xen_hvm_guest_late_init(void)
#endif
}
-const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
+static uint32_t __init xen_platform_hvm(void)
+{
+ uint32_t xen_domain = xen_cpuid_base();
+ struct x86_hyper_init *h = _hyper_xen_hvm.init;
+
+ if (xen_pv_domain())
+ return 0;
+
+ if (xen_pvh_domain() && nopv) {
+ /* Guest booting via the Xen-PVH boot entry goes here */
+ pr_info("\"nopv\" parameter is ignored in PVH guest\n");
+ nopv = false;
+ } else if (nopv && xen_domain) {
+ /*
+ * Guest booting via normal boot entry (like via grub2) goes
+ * here.
+ *
+ * Use interface functions for bare hardware if nopv,
+ * xen_hvm_guest_late_init is an exception as we need to
+ * detect PVH and panic there.
+ */
+ memcpy(h, (void *)_init.hyper, sizeof(x86_init.hyper));
+ memcpy(_hyper_xen_hvm.runtime, (void
*)_platform.hyper,
+ sizeof(x86_platform.hyper));
+ h->guest_late_init = xen_hvm_guest_late_init;
+ }
+ return xen_domain;
+}
+
+struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {
.name = "Xen HVM",
.detect = xen_platform_hvm,
.type = X86_HYPER_XEN_HVM,
@@ -268,4 +292,5 @@ static __init void xen_hvm_guest_late_init(void)
.init.init_mem_mapping = xen_hvm_init_mem_mapping,
.init.guest_late_init = xen_hvm_guest_late_init,
.runtime.pin_vcpu = xen_pin_vcpu,
+ .ignore_nopv = true,
};
Thanks
Zhenzhong
[GIT PULL] loadpin update for v5.3-rc1
Hi Linus, Please pull this loadpin update for v5.3-rc1. Details below... Thanks! -Kees The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07: Linux 5.2-rc2 (2019-05-26 16:49:19 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/loadpin-v5.3-rc1 for you to fetch changes up to 0ff9848067b7b950a4ed70de7f5028600a2157e3: security/loadpin: Allow to exclude specific file types (2019-05-31 13:57:40 -0700) security/loadpin improvement - Allow exclusion of specific file types (Ke Wu) Ke Wu (1): security/loadpin: Allow to exclude specific file types Documentation/admin-guide/LSM/LoadPin.rst | 10 +++ security/loadpin/loadpin.c| 48 +++ 2 files changed, 58 insertions(+) -- Kees Cook
Re: [PATCH 2/2] x86/numa: instance all parsed numa node
On Mon, Jul 8, 2019 at 5:35 PM Thomas Gleixner wrote: > > On Mon, 8 Jul 2019, Pingfan Liu wrote: > > On Mon, Jul 8, 2019 at 3:44 AM Thomas Gleixner wrote: > > > > > > On Fri, 5 Jul 2019, Pingfan Liu wrote: > > > > > > > I hit a bug on an AMD machine, with kexec -l nr_cpus=4 option. nr_cpus > > > > option > > > > is used to speed up kdump process, so it is not a rare case. > > > > > > But fundamentally wrong, really. > > > > > > The rest of the CPUs are in a half baken state and any broadcast event, > > > e.g. MCE or a stray IPI, will result in a undiagnosable crash. > > Very appreciate if you can pay more word on it? I tried to figure out > > your point, but fail. > > > > For "a half baked state", I think you concern about LAPIC state, and I > > expand this point like the following: > > It's not only the APIC state. It's the state of the CPUs in general. For other states, "kexec -l " is a kind of boot loader and the boot cpu complies with the kernel boot up provision. As for the rest AP, they are pinged at loop before receiving #INIT IPI. Then the left things is the same as SMP boot up. > > > For IPI: when capture kernel BSP is up, the rest cpus are still loop > > inside crash_nmi_callback(), so there is no way to eject new IPI from > > these cpu. Also we disable_local_APIC(), which effectively prevent the > > LAPIC from responding to IPI, except NMI/INIT/SIPI, which will not > > occur in crash case. > > Fair enough for the IPI case. > > > For MCE, I am not sure whether it can broadcast or not between cpus, > > but as my understanding, it can not. Then is it a problem? > > It can and it does. > > That's the whole point why we bring up all CPUs in the 'nosmt' case and > shut the siblings down again after setting CR4.MCE. Actually that's in fact > a 'let's hope no MCE hits before that happened' approach, but that's all we > can do. > > If we don't do that then the MCE broadcast can hit a CPU which has some > firmware initialized state. The result can be a full system lockup, triple > fault etc. > > So when the MCE hits a CPU which is still in the crashed kernel lala state, > then all hell breaks lose. Thank you for the comprehensive explain. With your guide, now, I have a full understanding of the issue. But when I tried to add something to enable CR4.MCE in crash_nmi_callback(), I realized that it is undo-able in some case (if crashed, we will not ask an offline smt cpu to online), also it is needless. "kexec -l/-p" takes the advantage of the cpu state in the first kernel, where all logical cpu has CR4.MCE=1. So kexec is exempt from this bug if the first kernel already do it. > > > From another view point, is there any difference between nr_cpus=1 and > > nr_cpus> 1 in crashing case? If stray IPI raises issue to nr_cpus>1, > > it does for nr_cpus=1. > > Anything less than the actual number of present CPUs is problematic except > you use the 'let's hope nothing happens' approach. We could add an option > to stop the bringup at the early online state similar to what we do for > 'nosmt'. Yes, we should do something about nr_cpus param for the first kernel. Thanks, Pingfan
Re: [PATCH 4.14 00/56] 4.14.133-stable review
On Mon, 8 Jul 2019 at 20:53, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.133 release. > There are 56 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 10 Jul 2019 03:03:52 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.133-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.14.133-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 5c87156a66f25c493e12b023972fc2ccae813204 git describe: v4.14.132-57-g5c87156a66f2 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.132-57-g5c87156a66f2 No regressions (compared to build v4.14.132) No fixes (compared to build v4.14.132) Ran 23716 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * v4l2-compliance * ltp-cve-tests * ltp-fs-tests * network-basic-tests * spectre-meltdown-checker-test * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
[GIT PULL] pstore updates for v5.3-rc1
Hi Linus, Please pull these pstore updates for v5.3-rc1. Details below... Thanks! -Kees The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008: Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.3-rc1 for you to fetch changes up to 4c6d80e1144bdf48cae6b602ae30d41f3e5c76a9: pstore: Fix double-free in pstore_mkfile() failure path (2019-07-08 21:04:42 -0700) pstore improvements - Improve backward compatibility with older Chromebooks (Douglas Anderson) - Refactor debugfs initialization (Greg KH) - Fix double-free in pstore_mkfile() failure path (Norbert Manthey) Douglas Anderson (1): pstore/ram: Improve backward compatibility with older Chromebooks Greg Kroah-Hartman (1): pstore: no need to check return value of debugfs_create functions Norbert Manthey (1): pstore: Fix double-free in pstore_mkfile() failure path fs/pstore/ftrace.c | 18 ++ fs/pstore/inode.c | 13 ++--- fs/pstore/ram.c| 21 + 3 files changed, 29 insertions(+), 23 deletions(-) -- Kees Cook
Re: WARNING in __mark_chain_precision
Hello, syzbot has tested the proposed patch and the reproducer did not trigger crash: Reported-and-tested-by: syzbot+4da3ff23081bafe74...@syzkaller.appspotmail.com Tested on: commit: b9321614 bpf: fix precision bit propagation for BPF_ST ins.. git tree: https://github.com/anakryiko/linux bpf-fix-precise-bpf_st kernel config: https://syzkaller.appspot.com/x/.config?x=6bb3e6e7997c14f9 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Note: testing is done by a robot and is best-effort only.
[PATCH] ASoC: Intel: Atom: read timestamp moved to period_elapsed
sst_platform_pcm_pointer is called from both snd_pcm_period_elapsed and
from snd_pcm_ioctl. Calling read timestamp results in recalculating
pcm_delay and buffer_ptr (sst_calc_tstamp) which consumes buffers in a
faster rate than intended.
In a tested BSW system with chtrt5650, for a rate of 48000, the
measured rate was sometimes 10 times more than that.
After moving the timestamp read to period elapsed, buffer consumption is
as expected.
Signed-off-by: Alex Levin
---
sound/soc/intel/atom/sst-mfld-platform-pcm.c | 23 +---
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
index 0e8b1c5eec88..196af0b30b41 100644
--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
@@ -265,16 +265,28 @@ static void sst_period_elapsed(void *arg)
{
struct snd_pcm_substream *substream = arg;
struct sst_runtime_stream *stream;
- int status;
+ struct snd_soc_pcm_runtime *rtd;
+ int status, ret_val;
if (!substream || !substream->runtime)
return;
stream = substream->runtime->private_data;
if (!stream)
return;
+
+ rtd = substream->private_data;
+ if (!rtd)
+ return;
+
status = sst_get_stream_status(stream);
if (status != SST_PLATFORM_RUNNING)
return;
+
+ ret_val = stream->ops->stream_read_tstamp(sst->dev,
>stream_info);
+ if (ret_val) {
+ dev_err(rtd->dev, "stream_read_tstamp err code = %d\n",
ret_val);
+ return;
+ }
snd_pcm_period_elapsed(substream);
}
@@ -658,20 +670,15 @@ static snd_pcm_uframes_t sst_platform_pcm_pointer
(struct snd_pcm_substream *substream)
{
struct sst_runtime_stream *stream;
- int ret_val, status;
+ int status;
struct pcm_stream_info *str_info;
- struct snd_soc_pcm_runtime *rtd = substream->private_data;
stream = substream->runtime->private_data;
status = sst_get_stream_status(stream);
if (status == SST_PLATFORM_INIT)
return 0;
+
str_info = >stream_info;
- ret_val = stream->ops->stream_read_tstamp(sst->dev, str_info);
- if (ret_val) {
- dev_err(rtd->dev, "sst: error code = %d\n", ret_val);
- return ret_val;
- }
substream->runtime->delay = str_info->pcm_delay;
return str_info->buffer_ptr;
}
--
2.22.0.410.gd8fdbe21b5-goog
Re: linux-next: build failure after merge of the netfilter-next tree
Hi all, On Mon, 8 Jul 2019 13:39:58 +1000 Stephen Rothwell wrote: > > After merging the netfilter-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > In file included from : > include/net/netfilter/nft_meta.h:6:21: warning: 'key' is narrower than values > of its type > enum nft_meta_keys key:8; > ^~~ > include/net/netfilter/nft_meta.h:6:21: error: field 'key' has incomplete type > include/net/netfilter/nft_meta.h:8:22: warning: 'dreg' is narrower than > values of its type >enum nft_registers dreg:8; > ^~~~ > include/net/netfilter/nft_meta.h:8:22: error: field 'dreg' has incomplete type > include/net/netfilter/nft_meta.h:9:22: warning: 'sreg' is narrower than > values of its type >enum nft_registers sreg:8; > ^~~~ > include/net/netfilter/nft_meta.h:9:22: error: field 'sreg' has incomplete type > include/net/netfilter/nft_meta.h:13:32: error: array type has incomplete > element type 'struct nla_policy' > extern const struct nla_policy nft_meta_policy[]; > ^~~ > include/net/netfilter/nft_meta.h:17:22: warning: 'struct nlattr' declared > inside parameter list will not be visible outside of this definition or > declaration > const struct nlattr * const tb[]); > ^~ > include/net/netfilter/nft_meta.h:16:22: warning: 'struct nft_expr' declared > inside parameter list will not be visible outside of this definition or > declaration > const struct nft_expr *expr, > ^~~~ > include/net/netfilter/nft_meta.h:15:36: warning: 'struct nft_ctx' declared > inside parameter list will not be visible outside of this definition or > declaration > int nft_meta_get_init(const struct nft_ctx *ctx, > ^~~ > include/net/netfilter/nft_meta.h:21:22: warning: 'struct nlattr' declared > inside parameter list will not be visible outside of this definition or > declaration > const struct nlattr * const tb[]); > ^~ > include/net/netfilter/nft_meta.h:20:22: warning: 'struct nft_expr' declared > inside parameter list will not be visible outside of this definition or > declaration > const struct nft_expr *expr, > ^~~~ > include/net/netfilter/nft_meta.h:19:36: warning: 'struct nft_ctx' declared > inside parameter list will not be visible outside of this definition or > declaration > int nft_meta_set_init(const struct nft_ctx *ctx, > ^~~ > include/net/netfilter/nft_meta.h:24:22: warning: 'struct nft_expr' declared > inside parameter list will not be visible outside of this definition or > declaration > const struct nft_expr *expr); > ^~~~ > include/net/netfilter/nft_meta.h:23:30: warning: 'struct sk_buff' declared > inside parameter list will not be visible outside of this definition or > declaration > int nft_meta_get_dump(struct sk_buff *skb, > ^~~ > include/net/netfilter/nft_meta.h:27:22: warning: 'struct nft_expr' declared > inside parameter list will not be visible outside of this definition or > declaration > const struct nft_expr *expr); > ^~~~ > include/net/netfilter/nft_meta.h:26:30: warning: 'struct sk_buff' declared > inside parameter list will not be visible outside of this definition or > declaration > int nft_meta_set_dump(struct sk_buff *skb, > ^~~ > include/net/netfilter/nft_meta.h:31:23: warning: 'struct nft_pktinfo' > declared inside parameter list will not be visible outside of this definition > or declaration > const struct nft_pktinfo *pkt); >^~~ > include/net/netfilter/nft_meta.h:30:17: warning: 'struct nft_regs' declared > inside parameter list will not be visible outside of this definition or > declaration > struct nft_regs *regs, > ^~~~ > include/net/netfilter/nft_meta.h:29:37: warning: 'struct nft_expr' declared > inside parameter list will not be visible outside of this definition or > declaration > void nft_meta_get_eval(const struct nft_expr *expr, > ^~~~ > include/net/netfilter/nft_meta.h:35:23: warning: 'struct nft_pktinfo' > declared inside parameter list will not be visible outside of this definition > or declaration > const struct nft_pktinfo *pkt); >^~~ > include/net/netfilter/nft_meta.h:34:17: warning: 'struct nft_regs' declared > inside parameter list will not be visible outside of this definition or > declaration > struct nft_regs *regs, > ^~~~ > include/net/netfilter/nft_meta.h:33:37: warning: 'struct nft_expr' declared > inside parameter list will not be visible outside of this
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/infiniband/sw/siw/siw_cm.c: In function 'siw_create_listen':
drivers/infiniband/sw/siw/siw_cm.c:1978:3: error: implicit declaration of
function 'for_ifa'; did you mean 'fork_idle'?
[-Werror=implicit-function-declaration]
for_ifa(in_dev)
^~~
fork_idle
drivers/infiniband/sw/siw/siw_cm.c:1978:18: error: expected ';' before '{' token
for_ifa(in_dev)
^
;
{
~
Caused by commit
6c52fdc244b5 ("rdma/siw: connection management")
from the rdma tree. I don't know why this didn't fail after I mereged
that tree.
I have marked that driver as depending on BROKEN for today.
--
Cheers,
Stephen Rothwell
pgpa6cNqQInQN.pgp
Description: OpenPGP digital signature
Re: WARNING in mark_chain_precision
#syz test: https://github.com/anakryiko/linux bpf-fix-precise-bpf_st
Re: [GIT PULL] integrity subsystem updates for v5.3
The pull request you sent on Mon, 08 Jul 2019 08:58:58 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git > next-integrity has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8b68150883ca466a23e90902dd4113b22e692f04 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: WARNING in __mark_chain_precision
#syz test: https://github.com/anakryiko/linux bpf-fix-precise-bpf_st
Re: linux-next: build failure after merge of the tip tree
Hi all,
On Tue, 25 Jun 2019 16:04:32 +1000 Stephen Rothwell
wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data':
> drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration
> of function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'?
> [-Werror=implicit-function-declaration]
>rx_status->boottime_ns = ktime_get_boot_ns();
> ^
> ktime_get_raw_ns
>
> Caused by commit
>
> c11c75ec784e ("p54: Support boottime in scan results")
>
> from the wireless-drivers-next tree interacting with commit
>
> 9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions")
>
> from the tip tree.
>
> I have added the following merge fix patch:
>
> From: Stephen Rothwell
> Date: Tue, 25 Jun 2019 15:55:36 +1000
> Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/net/wireless/intersil/p54/txrx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intersil/p54/txrx.c
> b/drivers/net/wireless/intersil/p54/txrx.c
> index be6968454282..873fea59894f 100644
> --- a/drivers/net/wireless/intersil/p54/txrx.c
> +++ b/drivers/net/wireless/intersil/p54/txrx.c
> @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct
> sk_buff *skb)
>
> fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
> if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc))
> - rx_status->boottime_ns = ktime_get_boot_ns();
> + rx_status->boottime_ns = ktime_get_boottime_ns();
>
> if (unlikely(priv->hw->conf.flags & IEEE80211_CONF_PS))
> p54_pspoll_workaround(priv, skb);
This patch is now needed in the merge between the net-next tree and
Linus' tree.
--
Cheers,
Stephen Rothwell
pgptZuNOQUmRV.pgp
Description: OpenPGP digital signature
Re: [PATCH V2 2/2] ASoC: fsl_esai: recover the channel swap after xrun
> > > > + > > > > + /* restore registers by regcache_sync */ > > > > + fsl_esai_register_restore(esai_priv); > > > > + > > > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, > > > > +ESAI_xCR_xPR_MASK, 0); > > > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR, > > > > +ESAI_xCR_xPR_MASK, 0); > > > > > > And just for curious, can (or shall) we stuff this personal reset to > > > the reset() function? I found this one is a part of the reset > > > routine being mentioned in the RM -- it was done after ESAI reset is > done via ECR register. > > > > > > > There is a problem to do this, TPR/RPR need to be clear after > > configure the control register. (TCCR, TCR). So it seems not only one > > place (reset function) need to be changed. > > Do you know (or remember) why we suddenly involve this TPR/PRP? > The driver has no problem so far, even if we don't have them. > > The "personal reset" sounds like a feature that we would use to reset TX or > RX individually, while this hw_reset() does a full reset for both TX and RX. > So I wonder whether they're necessary. The hw_reset flow is suggested by design team, so involve TRP/RPP is from them, I don't know the detail. Best regards Wang shengjiu
[PATCH v2 00/10] net: hisilicon: Add support for HI13X1 to hip04_eth
The main purpose of this patch series is to extend the hip04_eth driver to support HI13X1_GMAC. The offset and bitmap of some registers of HI13X1_GMAC are different from hip04_eth common soc. In addition, the definition of send descriptor and parsing descriptor are different from hip04_eth common soc. So the macro of the register offset is redefined to adapt the HI13X1_GMAC. Clean up the sparse warning by the way. Change since v1: * Add a cover letter. Jiangfeng Xiao (10): net: hisilicon: Add support for HI13X1 to hip04_eth net: hisilicon: Cleanup for got restricted __be32 net: hisilicon: Cleanup for cast to restricted __be32 net: hisilicon: HI13X1_GMAX skip write LOCAL_PAGE_REG net: hisilicon: HI13X1_GMAX need dreq reset at first net: hisilicon: dt-bindings: Add an field of port-handle net: hisilicon: Add group field to adapt HI13X1_GMAC net: hisilicon: Offset buf address to adapt HI13X1_GMAC net: hisilicon: Add an rx_desc to adapt HI13X1_GMAC net: hisilicon: Add an tx_desc to adapt HI13X1_GMAC .../bindings/net/hisilicon-hip04-net.txt | 7 +- drivers/net/ethernet/hisilicon/Kconfig | 10 ++ drivers/net/ethernet/hisilicon/hip04_eth.c | 142 ++--- 3 files changed, 136 insertions(+), 23 deletions(-) -- 1.8.5.6
[PATCH v2 10/10] net: hisilicon: Add an tx_desc to adapt HI13X1_GMAC
HI13X1 changed the offsets and bitmaps for tx_desc
registers in the same peripheral device on different
models of the hip04_eth.
Signed-off-by: Jiangfeng Xiao
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 34 +++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 780fc46..6256357 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -76,8 +76,15 @@
/* TX descriptor config */
#define TX_FREE_MEMBIT(0)
#define TX_READ_ALLOC_L3 BIT(1)
-#define TX_FINISH_CACHE_INVBIT(2)
+#if defined(CONFIG_HI13X1_GMAC)
+#define TX_CLEAR_WBBIT(7)
+#define TX_RELEASE_TO_PPE BIT(4)
+#define TX_FINISH_CACHE_INVBIT(6)
+#define TX_POOL_SHIFT 16
+#else
#define TX_CLEAR_WBBIT(4)
+#define TX_FINISH_CACHE_INVBIT(2)
+#endif
#define TX_L3_CHECKSUM BIT(5)
#define TX_LOOP_BACK BIT(11)
@@ -124,6 +131,7 @@
/* buf unit size is cache_line_size, which is 64, so the shift is 6 */
#define PPE_BUF_SIZE_SHIFT 6
#define PPE_TX_BUF_HOLDBIT(31)
+#define CACHE_LINE_MASK0x3F
#else
#define PPE_CFG_QOS_VMID_GRP_SHIFT 8
#define PPE_CFG_RX_CTRL_ALIGN_SHIFT11
@@ -163,11 +171,22 @@
#define HIP04_MIN_TX_COALESCE_FRAMES 100
struct tx_desc {
+#if defined(CONFIG_HI13X1_GMAC)
+ u32 reserved1[2];
+ u32 send_addr;
+ u16 send_size;
+ u16 data_offset;
+ u32 reserved2[7];
+ u32 cfg;
+ u32 wb_addr;
+ u32 reserved3[3];
+#else
u32 send_addr;
u32 send_size;
u32 next_addr;
u32 cfg;
u32 wb_addr;
+#endif
} __aligned(64);
struct rx_desc {
@@ -505,11 +524,20 @@ static void hip04_start_tx_timer(struct hip04_priv *priv)
priv->tx_skb[tx_head] = skb;
priv->tx_phys[tx_head] = phys;
- desc->send_addr = (__force u32)cpu_to_be32(phys);
+
desc->send_size = (__force u32)cpu_to_be32(skb->len);
+#if defined(CONFIG_HI13X1_GMAC)
+ desc->cfg = (__force u32)cpu_to_be32(TX_CLEAR_WB | TX_FINISH_CACHE_INV
+ | TX_RELEASE_TO_PPE | priv->port << TX_POOL_SHIFT);
+ desc->data_offset = (__force u32)cpu_to_be32(phys & CACHE_LINE_MASK);
+ desc->send_addr = (__force u32)cpu_to_be32(phys & ~CACHE_LINE_MASK);
+#else
desc->cfg = (__force u32)cpu_to_be32(TX_CLEAR_WB | TX_FINISH_CACHE_INV);
+ desc->send_addr = (__force u32)cpu_to_be32(phys);
+#endif
phys = priv->tx_desc_dma + tx_head * sizeof(struct tx_desc);
- desc->wb_addr = (__force u32)cpu_to_be32(phys);
+ desc->wb_addr = (__force u32)cpu_to_be32(phys +
+ offsetof(struct tx_desc, send_addr));
skb_tx_timestamp(skb);
hip04_set_xmit_desc(priv, phys);
--
1.8.5.6
[PATCH v2 04/10] net: hisilicon: HI13X1_GMAX skip write LOCAL_PAGE_REG
HI13X1_GMAC changed the offsets and bitmaps for GE_TX_LOCAL_PAGE_REG registers in the same peripheral device on different models of the hip04_eth. With the default configuration, HI13X1_GMAC can also work without any writes to the GE_TX_LOCAL_PAGE_REG register. Signed-off-by: Jiangfeng Xiao --- drivers/net/ethernet/hisilicon/hip04_eth.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c index d8f0619..fe61b01 100644 --- a/drivers/net/ethernet/hisilicon/hip04_eth.c +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c @@ -308,8 +308,10 @@ static void hip04_config_fifo(struct hip04_priv *priv) val |= GE_RX_STRIP_PAD | GE_RX_PAD_EN; writel_relaxed(val, priv->base + GE_RECV_CONTROL_REG); +#ifndef CONFIG_HI13X1_GMAC val = GE_AUTO_NEG_CTL; writel_relaxed(val, priv->base + GE_TX_LOCAL_PAGE_REG); +#endif } static void hip04_mac_enable(struct net_device *ndev) -- 1.8.5.6
[PATCH v2 07/10] net: hisilicon: Add group field to adapt HI13X1_GMAC
In general, group is the same as the port, but some
boards specify a special group for better load
balancing of each processing unit.
Signed-off-by: Jiangfeng Xiao
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 19d8cfd..5328219 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -178,6 +178,7 @@ struct hip04_priv {
int phy_mode;
int chan;
unsigned int port;
+ unsigned int group;
unsigned int speed;
unsigned int duplex;
unsigned int reg_inten;
@@ -278,10 +279,10 @@ static void hip04_config_fifo(struct hip04_priv *priv)
val |= PPE_CFG_STS_RX_PKT_CNT_RC;
writel_relaxed(val, priv->base + PPE_CFG_STS_MODE);
- val = BIT(priv->port);
+ val = BIT(priv->group);
regmap_write(priv->map, priv->port * 4 + PPE_CFG_POOL_GRP, val);
- val = priv->port << PPE_CFG_QOS_VMID_GRP_SHIFT;
+ val = priv->group << PPE_CFG_QOS_VMID_GRP_SHIFT;
val |= PPE_CFG_QOS_VMID_MODE;
writel_relaxed(val, priv->base + PPE_CFG_QOS_VMID_GEN);
@@ -876,7 +877,7 @@ static int hip04_mac_probe(struct platform_device *pdev)
}
#endif
- ret = of_parse_phandle_with_fixed_args(node, "port-handle", 2, 0, );
+ ret = of_parse_phandle_with_fixed_args(node, "port-handle", 3, 0, );
if (ret < 0) {
dev_warn(d, "no port-handle\n");
goto init_fail;
@@ -884,6 +885,7 @@ static int hip04_mac_probe(struct platform_device *pdev)
priv->port = arg.args[0];
priv->chan = arg.args[1] * RX_DESC_NUM;
+ priv->group = arg.args[2];
hrtimer_init(>tx_coalesce_timer, CLOCK_MONOTONIC,
HRTIMER_MODE_REL);
--
1.8.5.6
[PATCH v2 09/10] net: hisilicon: Add an rx_desc to adapt HI13X1_GMAC
HI13X1 changed the offsets and bitmaps for rx_desc
registers in the same peripheral device on different
models of the hip04_eth.
Signed-off-by: Jiangfeng Xiao
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
b/drivers/net/ethernet/hisilicon/hip04_eth.c
index c578934..780fc46 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -171,11 +171,20 @@ struct tx_desc {
} __aligned(64);
struct rx_desc {
+#if defined(CONFIG_HI13X1_GMAC)
+ u32 reserved1[3];
+ u16 pkt_len;
+ u16 reserved_16;
+ u32 reserved2[6];
+ u32 pkt_err;
+ u32 reserved3[5];
+#else
u16 reserved_16;
u16 pkt_len;
u32 reserve1[3];
u32 pkt_err;
u32 reserve2[4];
+#endif
};
struct hip04_priv {
--
1.8.5.6
[PATCH v2 01/10] net: hisilicon: Add support for HI13X1 to hip04_eth
Extend the hip04_eth driver to support HI13X1_GMAC. Enable it with CONFIG_HI13X1_GMAC option. Signed-off-by: Jiangfeng Xiao --- drivers/net/ethernet/hisilicon/Kconfig | 10 drivers/net/ethernet/hisilicon/hip04_eth.c | 37 -- 2 files changed, 40 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/Kconfig b/drivers/net/ethernet/hisilicon/Kconfig index a0d780c..3892a20 100644 --- a/drivers/net/ethernet/hisilicon/Kconfig +++ b/drivers/net/ethernet/hisilicon/Kconfig @@ -46,6 +46,16 @@ config HIP04_ETH If you wish to compile a kernel for a hardware with hisilicon p04 SoC and want to use the internal ethernet then you should answer Y to this. +config HI13X1_GMAC + bool "Hisilicon HI13X1 Network Device Support" + depends on HIP04_ETH + help + If you wish to compile a kernel for a hardware with hisilicon hi13x1_gamc + then you should answer Y to this. This makes this driver suitable for use + on certain boards such as the HI13X1. + + If you are unsure, say N. + config HNS_MDIO tristate select PHYLIB diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c index e1f2978..2b5112b 100644 --- a/drivers/net/ethernet/hisilicon/hip04_eth.c +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c @@ -33,10 +33,23 @@ #define GE_MODE_CHANGE_REG 0x1b4 #define GE_RECV_CONTROL_REG0x1e0 #define GE_STATION_MAC_ADDRESS 0x210 -#define PPE_CFG_CPU_ADD_ADDR 0x580 -#define PPE_CFG_MAX_FRAME_LEN_REG 0x408 + #define PPE_CFG_BUS_CTRL_REG 0x424 #define PPE_CFG_RX_CTRL_REG0x428 + +#if defined(CONFIG_HI13X1_GMAC) +#define PPE_CFG_CPU_ADD_ADDR 0x6D0 +#define PPE_CFG_MAX_FRAME_LEN_REG 0x500 +#define PPE_CFG_RX_PKT_MODE_REG0x504 +#define PPE_CFG_QOS_VMID_GEN 0x520 +#define PPE_CFG_RX_PKT_INT 0x740 +#define PPE_INTEN 0x700 +#define PPE_INTSTS 0x708 +#define PPE_RINT 0x704 +#define PPE_CFG_STS_MODE 0x880 +#else +#define PPE_CFG_CPU_ADD_ADDR 0x580 +#define PPE_CFG_MAX_FRAME_LEN_REG 0x408 #define PPE_CFG_RX_PKT_MODE_REG0x438 #define PPE_CFG_QOS_VMID_GEN 0x500 #define PPE_CFG_RX_PKT_INT 0x538 @@ -44,6 +57,8 @@ #define PPE_INTSTS 0x608 #define PPE_RINT 0x604 #define PPE_CFG_STS_MODE 0x700 +#endif /* CONFIG_HI13X1_GMAC */ + #define PPE_HIS_RX_PKT_CNT 0x804 /* REG_INTERRUPT */ @@ -93,18 +108,26 @@ #define GE_RX_PORT_EN BIT(1) #define GE_TX_PORT_EN BIT(2) -#define PPE_CFG_STS_RX_PKT_CNT_RC BIT(12) - #define PPE_CFG_RX_PKT_ALIGN BIT(18) -#define PPE_CFG_QOS_VMID_MODE BIT(14) + +#if defined(CONFIG_HI13X1_GMAC) +#define PPE_CFG_QOS_VMID_GRP_SHIFT 4 +#define PPE_CFG_RX_CTRL_ALIGN_SHIFT7 +#define PPE_CFG_STS_RX_PKT_CNT_RC BIT(0) +#define PPE_CFG_QOS_VMID_MODE BIT(15) +#define PPE_CFG_BUS_LOCAL_REL (BIT(9) | BIT(15) | BIT(19) | BIT(23)) +#else #define PPE_CFG_QOS_VMID_GRP_SHIFT 8 +#define PPE_CFG_RX_CTRL_ALIGN_SHIFT11 +#define PPE_CFG_STS_RX_PKT_CNT_RC BIT(12) +#define PPE_CFG_QOS_VMID_MODE BIT(14) +#define PPE_CFG_BUS_LOCAL_REL BIT(14) +#endif /* CONFIG_HI13X1_GMAC */ #define PPE_CFG_RX_FIFO_FSFU BIT(11) #define PPE_CFG_RX_DEPTH_SHIFT 16 #define PPE_CFG_RX_START_SHIFT 0 -#define PPE_CFG_RX_CTRL_ALIGN_SHIFT11 -#define PPE_CFG_BUS_LOCAL_REL BIT(14) #define PPE_CFG_BUS_BIG_ENDIEN BIT(0) #define RX_DESC_NUM128 -- 1.8.5.6
[PATCH v2 08/10] net: hisilicon: Offset buf address to adapt HI13X1_GMAC
The buf unit size of HI13X1_GMAC is cache_line_size,
which is 64, so the address we write to the buf register
needs to be shifted right by 6 bits.
The 31st bit of the PPE_CFG_CPU_ADD_ADDR register
of HI13X1_GMAC indicates whether to release the buffer
of the message, and the low indicates that it is valid.
Signed-off-by: Jiangfeng Xiao
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 5328219..c578934 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -120,12 +120,20 @@
#define PPE_CFG_STS_RX_PKT_CNT_RC BIT(0)
#define PPE_CFG_QOS_VMID_MODE BIT(15)
#define PPE_CFG_BUS_LOCAL_REL (BIT(9) | BIT(15) | BIT(19) | BIT(23))
+
+/* buf unit size is cache_line_size, which is 64, so the shift is 6 */
+#define PPE_BUF_SIZE_SHIFT 6
+#define PPE_TX_BUF_HOLDBIT(31)
#else
#define PPE_CFG_QOS_VMID_GRP_SHIFT 8
#define PPE_CFG_RX_CTRL_ALIGN_SHIFT11
#define PPE_CFG_STS_RX_PKT_CNT_RC BIT(12)
#define PPE_CFG_QOS_VMID_MODE BIT(14)
#define PPE_CFG_BUS_LOCAL_REL BIT(14)
+
+/* buf unit size is 1, so the shift is 6 */
+#define PPE_BUF_SIZE_SHIFT 0
+#define PPE_TX_BUF_HOLD0
#endif /* CONFIG_HI13X1_GMAC */
#define PPE_CFG_RX_FIFO_FSFU BIT(11)
@@ -286,7 +294,7 @@ static void hip04_config_fifo(struct hip04_priv *priv)
val |= PPE_CFG_QOS_VMID_MODE;
writel_relaxed(val, priv->base + PPE_CFG_QOS_VMID_GEN);
- val = RX_BUF_SIZE;
+ val = RX_BUF_SIZE >> PPE_BUF_SIZE_SHIFT;
regmap_write(priv->map, priv->port * 4 + PPE_CFG_RX_BUF_SIZE, val);
val = RX_DESC_NUM << PPE_CFG_RX_DEPTH_SHIFT;
@@ -369,12 +377,18 @@ static void hip04_mac_disable(struct net_device *ndev)
static void hip04_set_xmit_desc(struct hip04_priv *priv, dma_addr_t phys)
{
- writel(phys, priv->base + PPE_CFG_CPU_ADD_ADDR);
+ u32 val;
+
+ val = phys >> PPE_BUF_SIZE_SHIFT | PPE_TX_BUF_HOLD;
+ writel(val, priv->base + PPE_CFG_CPU_ADD_ADDR);
}
static void hip04_set_recv_desc(struct hip04_priv *priv, dma_addr_t phys)
{
- regmap_write(priv->map, priv->port * 4 + PPE_CFG_RX_ADDR, phys);
+ u32 val;
+
+ val = phys >> PPE_BUF_SIZE_SHIFT;
+ regmap_write(priv->map, priv->port * 4 + PPE_CFG_RX_ADDR, val);
}
static u32 hip04_recv_cnt(struct hip04_priv *priv)
--
1.8.5.6
[PATCH v2 05/10] net: hisilicon: HI13X1_GMAX need dreq reset at first
HI13X1_GMAC delete request for soft reset at first,
otherwise, the subsequent initialization will not
take effect.
Signed-off-by: Jiangfeng Xiao
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
b/drivers/net/ethernet/hisilicon/hip04_eth.c
index fe61b01..19d8cfd 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -16,6 +16,8 @@
#include
#include
+#define SC_PPE_RESET_DREQ 0x026C
+
#define PPE_CFG_RX_ADDR0x100
#define PPE_CFG_POOL_GRP 0x300
#define PPE_CFG_RX_BUF_SIZE0x400
@@ -61,6 +63,8 @@
#define PPE_HIS_RX_PKT_CNT 0x804
+#define RESET_DREQ_ALL 0x
+
/* REG_INTERRUPT */
#define RCV_INTBIT(10)
#define RCV_NOBUF BIT(8)
@@ -168,6 +172,9 @@ struct rx_desc {
struct hip04_priv {
void __iomem *base;
+#if defined(CONFIG_HI13X1_GMAC)
+ void __iomem *sysctrl_base;
+#endif
int phy_mode;
int chan;
unsigned int port;
@@ -244,6 +251,13 @@ static void hip04_config_port(struct net_device *ndev, u32
speed, u32 duplex)
writel_relaxed(val, priv->base + GE_MODE_CHANGE_REG);
}
+static void hip04_reset_dreq(struct hip04_priv *priv)
+{
+#if defined(CONFIG_HI13X1_GMAC)
+ writel_relaxed(RESET_DREQ_ALL, priv->sysctrl_base + SC_PPE_RESET_DREQ);
+#endif
+}
+
static void hip04_reset_ppe(struct hip04_priv *priv)
{
u32 val, tmp, timeout = 0;
@@ -853,6 +867,15 @@ static int hip04_mac_probe(struct platform_device *pdev)
goto init_fail;
}
+#if defined(CONFIG_HI13X1_GMAC)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ priv->sysctrl_base = devm_ioremap_resource(d, res);
+ if (IS_ERR(priv->sysctrl_base)) {
+ ret = PTR_ERR(priv->sysctrl_base);
+ goto init_fail;
+ }
+#endif
+
ret = of_parse_phandle_with_fixed_args(node, "port-handle", 2, 0, );
if (ret < 0) {
dev_warn(d, "no port-handle\n");
@@ -921,6 +944,7 @@ static int hip04_mac_probe(struct platform_device *pdev)
ndev->irq = irq;
netif_napi_add(ndev, >napi, hip04_rx_poll, NAPI_POLL_WEIGHT);
+ hip04_reset_dreq(priv);
hip04_reset_ppe(priv);
if (priv->phy_mode == PHY_INTERFACE_MODE_MII)
hip04_config_port(ndev, SPEED_100, DUPLEX_FULL);
--
1.8.5.6
[PATCH v2 06/10] net: hisilicon: dt-bindings: Add an field of port-handle
In general, group is the same as the port, but some
boards specify a special group for better load
balancing of each processing unit.
Signed-off-by: Jiangfeng Xiao
---
Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
b/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
index d1df8a0..464c0da 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
@@ -10,6 +10,7 @@ Required properties:
phandle, specifies a reference to the syscon ppe node
port, port number connected to the controller
channel, recv channel start from channel * number (RX_DESC_NUM)
+ group, field in the pkg desc, in general, it is the same as the port.
- phy-mode: see ethernet.txt [1].
Optional properties:
@@ -66,7 +67,7 @@ Example:
reg = <0x28b 0x1>;
interrupts = <0 413 4>;
phy-mode = "mii";
- port-handle = < 31 0>;
+ port-handle = < 31 0 31>;
};
ge0: ethernet@280 {
@@ -74,7 +75,7 @@ Example:
reg = <0x280 0x1>;
interrupts = <0 402 4>;
phy-mode = "sgmii";
- port-handle = < 0 1>;
+ port-handle = < 0 1 0>;
phy-handle = <>;
};
@@ -83,6 +84,6 @@ Example:
reg = <0x288 0x1>;
interrupts = <0 410 4>;
phy-mode = "sgmii";
- port-handle = < 8 2>;
+ port-handle = < 8 2 8>;
phy-handle = <>;
};
--
1.8.5.6
[PATCH v2 03/10] net: hisilicon: Cleanup for cast to restricted __be32
This patch fixes the following warning from sparse:
hip04_eth.c:533:23: warning: cast to restricted __be16
hip04_eth.c:533:23: warning: cast to restricted __be16
hip04_eth.c:533:23: warning: cast to restricted __be16
hip04_eth.c:533:23: warning: cast to restricted __be16
hip04_eth.c:534:23: warning: cast to restricted __be32
hip04_eth.c:534:23: warning: cast to restricted __be32
hip04_eth.c:534:23: warning: cast to restricted __be32
hip04_eth.c:534:23: warning: cast to restricted __be32
hip04_eth.c:534:23: warning: cast to restricted __be32
hip04_eth.c:534:23: warning: cast to restricted __be32
Signed-off-by: Jiangfeng Xiao
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 31f13cf..d8f0619 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -530,8 +530,8 @@ static int hip04_rx_poll(struct napi_struct *napi, int
budget)
priv->rx_phys[priv->rx_head] = 0;
desc = (struct rx_desc *)skb->data;
- len = be16_to_cpu(desc->pkt_len);
- err = be32_to_cpu(desc->pkt_err);
+ len = be16_to_cpu((__force __be16)desc->pkt_len);
+ err = be32_to_cpu((__force __be32)desc->pkt_err);
if (0 == len) {
dev_kfree_skb_any(skb);
--
1.8.5.6
[PATCH v2 02/10] net: hisilicon: Cleanup for got restricted __be32
This patch fixes the following warning from sparse: hip04_eth.c:468:25: warning: incorrect type in assignment hip04_eth.c:468:25:expected unsigned int [usertype] send_addr hip04_eth.c:468:25:got restricted __be32 [usertype] hip04_eth.c:469:25: warning: incorrect type in assignment hip04_eth.c:469:25:expected unsigned int [usertype] send_size hip04_eth.c:469:25:got restricted __be32 [usertype] hip04_eth.c:470:19: warning: incorrect type in assignment hip04_eth.c:470:19:expected unsigned int [usertype] cfg hip04_eth.c:470:19:got restricted __be32 [usertype] hip04_eth.c:472:23: warning: incorrect type in assignment hip04_eth.c:472:23:expected unsigned int [usertype] wb_addr hip04_eth.c:472:23:got restricted __be32 [usertype] Signed-off-by: Jiangfeng Xiao --- drivers/net/ethernet/hisilicon/hip04_eth.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c index 2b5112b..31f13cf 100644 --- a/drivers/net/ethernet/hisilicon/hip04_eth.c +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c @@ -465,11 +465,11 @@ static void hip04_start_tx_timer(struct hip04_priv *priv) priv->tx_skb[tx_head] = skb; priv->tx_phys[tx_head] = phys; - desc->send_addr = cpu_to_be32(phys); - desc->send_size = cpu_to_be32(skb->len); - desc->cfg = cpu_to_be32(TX_CLEAR_WB | TX_FINISH_CACHE_INV); + desc->send_addr = (__force u32)cpu_to_be32(phys); + desc->send_size = (__force u32)cpu_to_be32(skb->len); + desc->cfg = (__force u32)cpu_to_be32(TX_CLEAR_WB | TX_FINISH_CACHE_INV); phys = priv->tx_desc_dma + tx_head * sizeof(struct tx_desc); - desc->wb_addr = cpu_to_be32(phys); + desc->wb_addr = (__force u32)cpu_to_be32(phys); skb_tx_timestamp(skb); hip04_set_xmit_desc(priv, phys); -- 1.8.5.6
linux-next: build failure after merge of the rdma tree
Hi all,
After merging the rdma tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from /home/sfr/next/next/include/rdma/rdma_counter.h:12,
from :
/home/sfr/next/next/include/rdma/ib_verbs.h:2126:27: error: field
'port_counter' has incomplete type
struct rdma_port_counter port_counter;
^~~~
Caused by commit
413d3347503b ("RDMA/counter: Add set/clear per-port auto mode support")
rdma_counter.h include ib_verbs.h which in turn needs rdma_port_counter
from rdma_counter.h, but it is not defined yet :-(
I have applied the following patch for today.
From: Stephen Rothwell
Date: Tue, 9 Jul 2019 13:17:49 +1000
Subject: [PATCH] RDMA: don't try to build rdma_counter.h for now
rdma_counter.h include ib_verbs.h which in turn needs rdma_port_counter
from rdma_counter.h, but it is not defined yet :-(
Signed-off-by: Stephen Rothwell
---
include/Kbuild | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/Kbuild b/include/Kbuild
index 78434c59701f..8dab85cdf4f4 100644
--- a/include/Kbuild
+++ b/include/Kbuild
@@ -939,6 +939,7 @@ header-test-+= rdma/ib.h
header-test- += rdma/iw_portmap.h
header-test- += rdma/opa_port_info.h
header-test- += rdma/rdmavt_cq.h
+header-test- += rdma/rdma_counter.h
header-test- += rdma/restrack.h
header-test- += rdma/signature.h
header-test- += rdma/tid_rdma_defs.h
--
2.20.1
--
Cheers,
Stephen Rothwell
pgp7gXOiihi4Z.pgp
Description: OpenPGP digital signature
Re: keyrings pull requests for the next merge window
[ Adding a few mailing lists, since the thrust of my email is about more people being around and involved, and the pull requests themselves were indeed cc'd to the mailing lists too ] On Thu, Jul 4, 2019 at 9:15 AM David Howells wrote: > > I have a bunch of keyrings patches to be pulled in during the merge window. I > believe you want security patches to go directly to you rather than through > James now? > > I've divided these patches into four logical sets, though due to conflicting > changes the sets are in a sequence, built one upon another. > > How do you want them presenting? Do you want a pull request for each set, one > for all of them or would you prefer they go through James's security tree? So I was traveling when this email came in, but in the meantime you sent the four pull requests and I have now pulled them all. You should have gotten the pr-tracker-bot notification already (or it will happen soon). An initial very positive comment: the pull requests themselves with all the explanations were very good. That part of the process worked very well, I think. I felt like I got an explanation of what I pulled, and I think the merge commits themselves are the better for it, so that the explanation now remains in the git history, and other people too can see what got merged and why. HOWEVER. There are parts I really didn't much like was when I look at all the individual commits themselves. Again, the commit messages there are good and that part all looks fine. BUT. The history itself looks questionable. The dates don't make sense, and the different branches were obviously all done together as a linear history, rebased, and worked on as one single branch, . Fine - it was then at least partitioned into sensible parts, and sometimes this is how it really ends up working, but I did get the feeling that this was all very artificial and more importantly I get the feeling that none of the commits had any real-life exposure. That lack of real-life exposure also shows in the almost complete lack of any reviews, any commentary from other people, and absolutely nobody else seems to have been involved. Not as an author, but not in any other capacity either. There were a couple of initial commits that had reviewed-by's, but apart from that there really was *no* sign of any outside involvement at all. I looked up a couple of the patches on patchwork too, and saw zero discussion. Maybe the ones I picked just happened to have none, but I really get the feeling that pretty much none of this had any external input what-so-ever. And that makes me unhappy. In other words: the pull requests, the explanations, everything looked very good and I enjoyed that part. I don't see any new warnings, and everything built fine at every stage. I have no real technical complaints from that angle. But I absolutely abhor how this seems to all have been developed in a complete and utter vacuum. That just fundamentally worries me. I can't point to anything being bad, but the lack of any kind of work from anybody else just makes me antsy. Is there really nobody else working or caring about this at all? This is not new, and I do note that your afs work tends to have the same pattern (but honestly, when it comes to one particular odd filesystem or driver, it's not something I react to). It's just perhaps more noticeable to me now that I pull directly, and it's much more noticeable when it's a _subsystem_ rather than something like a end-point driver/filesystem. I think the pulls themselves worked, and I don't mind the direct pulling, but I *do* notice that I end up minding the fact that now with the direct pulls, there's even _less_ of a "at least somebody else looked and cared". Put another way: I'd like other people to be involved. Either as reviewers, or as intermediate people, or _something_. The "David Howells lives in his own world and nobody else looks at it and then he sends it directly to Linus" model makes me somewhat unhappy. Again, I'd like to stress that the pull requests themselves were fine, and I have no complaints on that side and I have (at least as of yet) no reason to worry about the code itself. It's really the "lone developer sends directly to me" that stands out as not happening elsewhere that I'm worried about. Hmm? Linus
[PATCH 5/5] arm: dts: add jpeg enc device tree node
add jpeg enc device tree node
Signed-off-by: Xia Jiang
---
arch/arm/boot/dts/mt2701.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 51e1305c6471..560f27fd9d9e 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -569,6 +569,18 @@
< MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
+ jpegenc: jpegenc@1500a000 {
+ compatible = "mediatek,mt2701-jpgenc", "mediatek,mtk-jpgenc";
+ reg = <0 0x1500a000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_IMG_VENC>;
+ clock-names = "jpgenc";
+ power-domains = < MT2701_POWER_DOMAIN_ISP>;
+ mediatek,larb = <>;
+ iommus = < MT2701_M4U_PORT_JPGENC_RDMA>,
+ < MT2701_M4U_PORT_JPGENC_BSDMA>;
+ };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
--
2.18.0
[PATCH 3/5] media: platform: Add jpeg enc feature
Add mtk jpeg encode v4l2 driver based on jpeg decode, because that jpeg
decode and encode have great similarities with function operation.
add EXIF enable control for jpeg encode.
Signed-off-by: Xia Jiang
---
drivers/media/platform/mtk-jpeg/Makefile | 5 +-
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 733 ++
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 114 ++-
.../media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h | 7 +-
.../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c | 175 +
.../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h | 60 ++
.../platform/mtk-jpeg/mtk_jpeg_enc_reg.h | 49 ++
drivers/media/v4l2-core/v4l2-ctrls.c | 1 +
include/uapi/linux/v4l2-controls.h| 2 +
9 files changed, 979 insertions(+), 167 deletions(-)
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_reg.h
diff --git a/drivers/media/platform/mtk-jpeg/Makefile
b/drivers/media/platform/mtk-jpeg/Makefile
index 994fcd66069c..c2d7774e59fb 100644
--- a/drivers/media/platform/mtk-jpeg/Makefile
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -1,2 +1,5 @@
-mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_dec_hw.o mtk_jpeg_dec_parse.o
+mtk_jpeg-objs := mtk_jpeg_core.o \
+mtk_jpeg_dec_hw.o \
+mtk_jpeg_dec_parse.o \
+mtk_jpeg_enc_hw.o
obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 49e3b5284006..ef54802bd813 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -2,6 +2,7 @@
* Copyright (c) 2016 MediaTek Inc.
* Author: Ming Hsiu Tsai
* Rick Chang
+ * Xia Jiang
*
* 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
@@ -31,6 +32,7 @@
#include
#include
+#include "mtk_jpeg_enc_hw.h"
#include "mtk_jpeg_dec_hw.h"
#include "mtk_jpeg_core.h"
#include "mtk_jpeg_dec_parse.h"
@@ -39,7 +41,8 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
{
.fourcc = V4L2_PIX_FMT_JPEG,
.colplanes = 1,
- .flags = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+ .flags = MTK_JPEG_FMT_FLAG_DEC_OUTPUT |
+ MTK_JPEG_FMT_FLAG_ENC_CAPTURE,
},
{
.fourcc = V4L2_PIX_FMT_YUV420M,
@@ -59,6 +62,42 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
.v_align= 3,
.flags = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
},
+ {
+ .fourcc = V4L2_PIX_FMT_NV12M,
+ .h_sample = {4, 2, 2},
+ .v_sample = {4, 2, 2},
+ .colplanes = 2,
+ .h_align= 4,
+ .v_align= 4,
+ .flags = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_NV21M,
+ .h_sample = {4, 2, 2},
+ .v_sample = {4, 2, 2},
+ .colplanes = 2,
+ .h_align= 4,
+ .v_align= 4,
+ .flags = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .h_sample = {4, 2, 2},
+ .v_sample = {4, 4, 4},
+ .colplanes = 1,
+ .h_align= 4,
+ .v_align= 3,
+ .flags = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .h_sample = {4, 2, 2},
+ .v_sample = {4, 4, 4},
+ .colplanes = 1,
+ .h_align= 4,
+ .v_align= 3,
+ .flags = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+ },
};
#define MTK_JPEG_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_formats)
@@ -73,11 +112,19 @@ struct mtk_jpeg_src_buf {
struct list_head list;
int flags;
struct mtk_jpeg_dec_param dec_param;
+ struct mtk_jpeg_enc_param enc_param;
};
+#define MTK_MAX_CTRLS_HINT 20
+
static int debug;
module_param(debug, int, 0644);
+static inline struct mtk_jpeg_ctx *ctrl_to_ctx(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl->handler, struct mtk_jpeg_ctx, ctrl_hdl);
+}
+
static inline struct mtk_jpeg_ctx *mtk_jpeg_fh_to_ctx(struct v4l2_fh *fh)
{
return container_of(fh, struct mtk_jpeg_ctx, fh);
@@ -94,10 +141,81 @@ static int mtk_jpeg_querycap(struct file *file, void *priv,
{
struct mtk_jpeg_dev *jpeg = video_drvdata(file);
-
[PATCH 4/5] media: platform: change GPLv2 license to SPDX
Switch GPLv2 license to SPDX license. Signed-off-by: Xia Jiang --- drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 9 + drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 9 + drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c| 9 + drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h| 9 + drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c | 9 + drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h | 9 + drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h | 9 + 7 files changed, 7 insertions(+), 56 deletions(-) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c index ef54802bd813..9094eb7bd00f 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c @@ -1,17 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Copyright (c) 2016 MediaTek Inc. * Author: Ming Hsiu Tsai * Rick Chang * Xia Jiang * - * 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. - * - * 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. */ #include diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h index 65ef920651a5..34cd139ee502 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h @@ -1,17 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2016 MediaTek Inc. * Author: Ming Hsiu Tsai * Rick Chang * Xia Jiang * - * 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. - * - * 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. */ #ifndef _MTK_JPEG_CORE_H diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c index aad834d98059..0a8200a0a5c6 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c @@ -1,16 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Copyright (c) 2016 MediaTek Inc. * Author: Ming Hsiu Tsai * Rick Chang * - * 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. - * - * 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. */ #include diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h index 725ce94fd58f..be9a756d6242 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h @@ -1,17 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2016 MediaTek Inc. * Author: Ming Hsiu Tsai * Rick Chang * Xia Jiang * - * 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. - * - * 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. */ #ifndef _MTK_JPEG_DEC_HW_H diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c index c887f90c3a66..c63d61a957a5 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c @@ -1,16 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Copyright (c) 2016 MediaTek Inc. * Author: Ming Hsiu Tsai * Rick Chang * - * 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. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or
[PATCH 2/5] media: platform: Rename jpeg dec file name
Rename the files which are for decode feature. This is a preparing
patch since the jpeg enc patch will be added later.
Signed-off-by: Xia Jiang
---
drivers/media/platform/mtk-jpeg/Makefile | 2 +-
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
.../platform/mtk-jpeg/{mtk_jpeg_hw.c => mtk_jpeg_dec_hw.c}| 2 +-
.../platform/mtk-jpeg/{mtk_jpeg_hw.h => mtk_jpeg_dec_hw.h}| 2 +-
.../mtk-jpeg/{mtk_jpeg_parse.c => mtk_jpeg_dec_parse.c} | 2 +-
.../mtk-jpeg/{mtk_jpeg_parse.h => mtk_jpeg_dec_parse.h} | 2 +-
.../platform/mtk-jpeg/{mtk_jpeg_reg.h => mtk_jpeg_dec_reg.h} | 0
7 files changed, 7 insertions(+), 7 deletions(-)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_hw.c => mtk_jpeg_dec_hw.c}
(99%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_hw.h => mtk_jpeg_dec_hw.h}
(98%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_parse.c =>
mtk_jpeg_dec_parse.c} (99%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_parse.h =>
mtk_jpeg_dec_parse.h} (96%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_reg.h => mtk_jpeg_dec_reg.h}
(100%)
diff --git a/drivers/media/platform/mtk-jpeg/Makefile
b/drivers/media/platform/mtk-jpeg/Makefile
index b2e6069f3959..994fcd66069c 100644
--- a/drivers/media/platform/mtk-jpeg/Makefile
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -1,2 +1,2 @@
-mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_dec_hw.o mtk_jpeg_dec_parse.o
obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index f761e4d8bf2a..49e3b5284006 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -31,9 +31,9 @@
#include
#include
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
#include "mtk_jpeg_core.h"
-#include "mtk_jpeg_parse.h"
+#include "mtk_jpeg_dec_parse.h"
static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
{
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
similarity index 99%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
index 77b4cc6a8873..aad834d98059 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
@@ -17,7 +17,7 @@
#include
#include
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
#define MTK_JPEG_DUNUM_MASK(val) (((val) - 1) & 0x3)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
similarity index 98%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
index 37152a630dea..bff6a4aab57a 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
@@ -19,7 +19,7 @@
#include
#include "mtk_jpeg_core.h"
-#include "mtk_jpeg_reg.h"
+#include "mtk_jpeg_dec_reg.h"
enum {
MTK_JPEG_DEC_RESULT_EOF_DONE= 0,
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
similarity index 99%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
index 38868547f5d4..c887f90c3a66 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
@@ -16,7 +16,7 @@
#include
#include
-#include "mtk_jpeg_parse.h"
+#include "mtk_jpeg_dec_parse.h"
#define TEM0x01
#define SOF0 0xc0
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
similarity index 96%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
index 5d92340ea81b..fdad7f2da6be 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
@@ -16,7 +16,7 @@
#ifndef _MTK_JPEG_PARSE_H
#define _MTK_JPEG_PARSE_H
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
bool mtk_jpeg_parse(struct mtk_jpeg_dec_param *param, u8 *src_addr_va,
u32 src_size);
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h
similarity index 100%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h
--
2.18.0
[PATCH 1/5] media: dt-bindings: Add JPEG ENC device tree node document
Add JPEG ENC device tree node document.
Signed-off-by: Xia Jiang
---
.../bindings/media/mediatek-jpeg-encoder.txt | 33 +++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
new file mode 100644
index ..1231fedb70bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
@@ -0,0 +1,33 @@
+* MediaTek JPEG Encoder
+
+MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs
+
+Required properties:
+- compatible : must be "mediatek,mtk-jpgenc"
+- reg : physical base address of the JPEG encoder registers and length of
+ memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+ Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgenc". It is the clock of JPEG encoder.
+- power-domains: a phandle to the power domain, see
+ Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current SoCs, see
+ Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+ for details.
+- iommus: should point to the respective IOMMU block with master port as
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ for details.
+
+Example:
+ jpegenc: jpegenc@1500a000 {
+ compatible = "mediatek,mtk-jpgenc";
+ reg = <0 0x1500a000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_IMG_VENC>;
+ clock-names = "jpgenc";
+ power-domains = < MT2701_POWER_DOMAIN_ISP>;
+ mediatek,larb = <>;
+ iommus = < MT2701_M4U_PORT_JPGENC_RDMA>,
+ < MT2701_M4U_PORT_JPGENC_BSDMA>;
+ };
--
2.18.0
[PATCH 0/5]Add support for mt2701 JPEG ENC support
This patchset add support for mt2701 JPEG ENC support. This is the compliance test result for jpeg dec and enc. The JPEG dec log: v4l2-compliance -d /dev/video0 v4l2-compliance SHA: 08fed4d0edb1492b91d9d1054c36fed95c372eaa, 32 bits Compliance test for mtk-jpeg device /dev/video0: Driver Info: Driver name : mtk-jpeg Card type: mtk-jpeg decoder Bus info : platform:15004000.jpegdec Driver version : 5.2.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Detected JPEG Decoder Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video0 open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK test Scaling: OK Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: fail: v4l2-test-buffers.cpp(713): q.create_bufs(node, 1, ) != EINVAL test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL test VIDIOC_EXPBUF: OK test Requests: OK (Not Supported) Total for mtk-jpeg device /dev/video0: 44, Succeeded: 43, Failed: 1, Warnings: 0 The JPEG enc log: v4l2-compliance -d /dev/video1 v4l2-compliance SHA: 08fed4d0edb1492b91d9d1054c36fed95c372eaa, 32 bits Compliance test for mtk-jpeg device /dev/video1: Driver Info: Driver name : mtk-jpeg Card type: mtk-jpeg encoder Bus info : platform:1500a000.jpegenc Driver version : 5.2.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Detected JPEG Encoder Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video1 open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO:
Re: [PATCH] r8169: add enable_aspm parameter
Heiner Kallweit 於 2019年7月9日 週二 上午2:27寫道：
>
> On 08.07.2019 08:37, AceLan Kao wrote:
> > We have many commits in the driver which enable and then disable ASPM
> > function over and over again.
> >commit b75bb8a5b755 ("r8169: disable ASPM again")
> >commit 0866cd15029b ("r8169: enable ASPM on RTL8106E")
> >commit 94235460f9ea ("r8169: Align ASPM/CLKREQ setting function with
> > vendor driver")
> >commit aa1e7d2c31ef ("r8169: enable ASPM on RTL8168E-VL")
> >commit f37658da21aa ("r8169: align ASPM entry latency setting with
> > vendor driver")
> >commit a99790bf5c7f ("r8169: Reinstate ASPM Support")
> >commit 671646c151d4 ("r8169: Don't disable ASPM in the driver")
> >commit 4521e1a94279 ("Revert "r8169: enable internal ASPM and clock
> > request settings".")
> >commit d64ec841517a ("r8169: enable internal ASPM and clock request
> > settings")
> >
> > This function is very important for production, and if we can't come out
> > a solution to make both happy, I'd suggest we add a parameter in the
> > driver to toggle it.
> >
> The usage of a module parameter to control ASPM is discouraged.
> There have been more such attempts in the past that have been declined.
>
> Pending with the PCI maintainers is a series adding ASPM control
> via sysfs, see here: https://www.spinics.net/lists/linux-pci/msg83228.html
Cool, I'll try your patches and reply on that thread.
>
> Also more details than just stating "it's important for production"
> would have been appreciated in the commit message, e.g. which
> power-savings you can achieve with ASPM on which systems.
I should use more specific wordings rather than "important for
production", thanks.
Re: [PATCH v7 12/12] KVM/VMX/vPMU: support to report GLOBAL_STATUS_LBRS_FROZEN
On 07/08/2019 11:09 PM, Peter Zijlstra wrote: On Mon, Jul 08, 2019 at 09:23:19AM +0800, Wei Wang wrote: This patch enables the LBR related features in Arch v4 in advance, though the current vPMU only has v2 support. Other arch v4 related support will be enabled later in another series. Arch v4 supports streamlined Freeze_LBR_on_PMI. According to the SDM, the LBR_FRZ bit is set to global status when debugctl.freeze_lbr_on_pmi has been set and a PMI is generated. The CTR_FRZ bit is set when debugctl.freeze_perfmon_on_pmi is set and a PMI is generated. (that's still a misnomer; it is: freeze_perfmon_on_overflow) OK. (but that was directly copied from the sdm 18.2.4.1) Why? Who uses that v4 crud? I saw the native perf driver has been updated to v4. After the vPMU gets updated to v4, the guest perf would use that. If you prefer to hold on this patch until vPMU v4 support, we could do that as well. It's broken. It looses events between overflow and PMI. Do you mean it's a v4 hardware issue? Best, Wei
Re: [PATCH v2 1/6] dt-bindings: Remove unused compatible strings
Le lun. 8 juil. 2019 à 22:04, Rob Herring a écrit : On Fri, Jun 07, 2019 at 05:44:05PM +0200, Paul Cercueil wrote: Right now none of the Ingenic-based boards probe this driver from devicetree. This driver defined three compatible strings for the exact same behaviour. Before these strings are used, we can remove two of them. Signed-off-by: Paul Cercueil --- Notes: v2: Rebase on v5.2-rc3 Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt b/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt index 7d9d3f90641b..493bec80d59b 100644 --- a/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt @@ -2,10 +2,7 @@ Ingenic JZ47xx PWM Controller = Required properties: -- compatible: One of: - * "ingenic,jz4740-pwm" - * "ingenic,jz4770-pwm" - * "ingenic,jz4780-pwm" +- compatible: Should be "ingenic,jz4740-pwm" Are you sure all 3 chips are exactly the same features and bugs? The hardware on these chips have tiny differences, but the current driver code works on all the SoCs. The correct thing to do here generally is the 4770 and 4780 would also have ingenic,jz4740-pwm as a fallback compatible. Then the driver can match on that until you find some difference and can use the more specific compatible. Why not just update the devicetree with the new compatible string when a difference is found? - #pwm-cells: Should be 3. See pwm.txt in this directory for a description of the cells format. - clocks : phandle to the external clock. -- 2.21.0.593.g511ec345e18
Re: [PATCH net-next] net: dsa: vsc73xx: Fix Kconfig warning and build errors
On Tue, Jul 09, 2019 at 11:02:24AM +0800, YueHaibing wrote:
> Fix Kconfig dependency warning and subsequent build errors
> caused by OF is not set:
>
> WARNING: unmet direct dependencies detected for NET_DSA_VITESSE_VSC73XX
> Depends on [n]: NETDEVICES [=y] && HAVE_NET_DSA [=y] && OF [=n] && NET_DSA
> [=m]
> Selected by [m]:
> - NET_DSA_VITESSE_VSC73XX_PLATFORM [=m] && NETDEVICES [=y] && HAVE_NET_DSA
> [=y] && HAS_IOMEM [=y]
>
> Make NET_DSA_VITESSE_VSC73XX_SPI and NET_DSA_VITESSE_VSC73XX_PLATFORM
> depends on NET_DSA_VITESSE_VSC73XX to fix this.
>
> Reported-by: Hulk Robot
> Suggested-by: Andrew Lunn
> Fixes: 95711cd5f0b4 ("net: dsa: vsc73xx: Split vsc73xx driver")
> Signed-off-by: YueHaibing
Reviewed-by: Andrew Lunn
Andrew
Re: [GIT PULL] Keys: Set 3 - Keyrings namespacing for 5.3
The pull request you sent on Fri, 05 Jul 2019 22:20:44 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > tags/keys-namespace-20190627 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2e12256b9a76584fa3a6da19210509d4775aee36 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Audit patches for v5.3
The pull request you sent on Tue, 2 Jul 2019 13:28:33 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git > tags/audit-pr-20190702 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/61fc5771f5e729a2ce235af42f69c8506725e84a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] SELinux patches for v5.3
The pull request you sent on Tue, 2 Jul 2019 13:28:37 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git > tags/selinux-pr-20190702 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7c0f89634892693fc0b46f25e0a6d57bd6dd5698 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Keys: Set 2 - request_key() improvements for 5.3
The pull request you sent on Fri, 05 Jul 2019 22:13:34 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > tags/keys-request-20190626 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f771fde82051976a6fc0fd570f8b86de4a92124b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Keys: Set 1 - Miscellany for 5.3
The pull request you sent on Fri, 05 Jul 2019 22:03:39 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > tags/keys-misc-20190619 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/504b69eb3c95180bc59f1ae9096ad4b10bbbf254 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] tpmdd updates for Linux v5.3
The pull request you sent on Thu, 27 Jun 2019 01:50:47 +0300: > git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190625 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/884922591e2b58fd7f1018701f957446d1ffac4d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Keys: Set 4 - Key ACLs for 5.3
The pull request you sent on Fri, 05 Jul 2019 22:30:39 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > tags/keys-acl-20190703 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0f75ef6a9cff49ff612f7ce0578bced9d0b38325 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 8/8] nfsd: Fix misuse of strlcpy
On Thu, Jul 04, 2019 at 04:57:48PM -0700, Joe Perches wrote: > Probable cut typo - use the correct field size. Huh, that's been there forever, I wonder why we haven't seen crashes? Oh, I see, name and authname both have the same size. Anyway, makes sense, thanks. Will apply for 5.3. (Unless someone else is getting this; I didn't get copied on the rest of the series.) --b. > > Signed-off-by: Joe Perches > --- > fs/nfsd/nfs4idmap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/nfsd/nfs4idmap.c b/fs/nfsd/nfs4idmap.c > index 2961016097ac..d1f285245af8 100644 > --- a/fs/nfsd/nfs4idmap.c > +++ b/fs/nfsd/nfs4idmap.c > @@ -83,7 +83,7 @@ ent_init(struct cache_head *cnew, struct cache_head *citm) > new->type = itm->type; > > strlcpy(new->name, itm->name, sizeof(new->name)); > - strlcpy(new->authname, itm->authname, sizeof(new->name)); > + strlcpy(new->authname, itm->authname, sizeof(new->authname)); > } > > static void > -- > 2.15.0
RE: [PATCH] cpufreq: imx-cpufreq-dt: Assign max supported frequency as suspend frequency
Hi, Leonard
> On 7/8/2019 10:55 AM, anson.hu...@nxp.com wrote:
> > To reduce the suspend/resume latency, CPU's max supported frequency
> > should be used during low level suspend/resume phase, "opp-suspend"
> > property is NOT feasible since OPP defined in DT could be NOT
> > supported according to speed garding and market segment fuse settings.
> > So we can assign the cpufreq policy's suspend_freq with max available
> > frequency provided by cpufreq driver.
> >
> > Signed-off-by: Anson Huang
>
> > diff --git a/drivers/cpufreq/imx-cpufreq-dt.c
> > b/drivers/cpufreq/imx-cpufreq-dt.c
>
> > +static int __init imx_cpufreq_dt_setup_suspend_opp(void)
> > +{
> > + struct cpufreq_policy *policy = cpufreq_cpu_get(0);
> > +
> > + policy->suspend_freq = cpufreq_quick_get_max(0);
> > +
> > + return 0;
> > +}
> > +late_initcall(imx_cpufreq_dt_setup_suspend_opp);
>
> The imx-cpufreq-dt driver is built as a module by default and this patch
> produces an error:
>
> In file included from ../drivers/cpufreq/imx-cpufreq-dt.c:11:
> ../include/linux/module.h:131:42: error: redefinition of ‘__inittest’
>static inline initcall_t __maybe_unused __inittest(void) \
>^~
> ../include/linux/device.h:1656:1: note: in expansion of macro ‘module_init’
> module_init(__driver##_init); \
> ^~~
>
> As far as I can tell late_initcall is not supported for modules.
Ah, yes, I have NOT test the module build, I ONLY tested the built-in case,
thanks for
reminder.
>
> Viresh: "max freq as suspend freq" is something that could be useful for
> other SOC families. The hardware can suspend at any freq; it's just that the
> highest one makes sense because it makes suspend/resume slightly faster.
Agree.
>
> Could this behavior be pushed to cpufreq-dt as a bool flag inside struct
> cpufreq_dt_platform_data?
>
> Only a few other platforms use this, most others pass NULL like imx. But
> passing custom SOC-specific flags to cpufreq-dt makes a lot of sense
Although we have other methods to make it work for i.MX platforms, like setting
the suspend freq as this patch did but ONLY be called before suspend, but if
common
cpufreq-dt can handle this case, that would benefit us and other platforms a
lot, waiting
for your opinion.
Thanks,
Anson
