* RE: [EXT] Re: SCMI & Devfreq
From: Sujeet Kumar Baranwal @ 2019-09-18 22:53 UTC (permalink / raw)
To: Sudeep Holla; +Cc: linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR18MB2438DC4E8CA4E90455F0345BAF8C0@BYAPR18MB2438.namprd18.prod.outlook.com>
Sudeep, One trivial question wrt SCMI-CPUFREQ framework.
The SCMI perf protocol would tell what are different frequencies the platform support in the beginning.
For example, the command :
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
shows:
280000 560000 840000 1120000 1400000 1820000 1960000 2240000 2520000 2800000
/* Attempt to change the frequency */
~ # echo 2240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
It works.
But in a scenario, where user tries a number which is not listed, SCP applies its own logic to get a nearby value frequency for CPU and returns.
My question is that could we add some print message in kernel that user wish is not exactly fulfilled, an approximation has been done so the user explicitly knows his command has been partially met. If this to happen, a patch might be needed in kernel. What is your opinion?
Regards
Sujeet
-----Original Message-----
From: Sujeet Kumar Baranwal
Sent: Monday, September 16, 2019 10:37 AM
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Subject: RE: [EXT] Re: SCMI & Devfreq
Ok, Sudeep. I would wait for your mail.
Regards
Sujeet
-----Original Message-----
From: Sudeep Holla <sudeep.holla@arm.com>
Sent: Monday, September 16, 2019 3:15 AM
To: Sujeet Kumar Baranwal <sbaranwal@marvell.com>
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: [EXT] Re: SCMI & Devfreq
On Mon, Sep 16, 2019 at 05:22:02AM +0000, Sujeet Kumar Baranwal wrote:
> Thanks Sudeep.
>
>>> Good, but just a quick question to check if this is ACPI or DT based
>>> platform ?
>
> DT based.
>
Good.
>>> Yes it needs some work and I do have some prototype, but with no
>>> users in the upstream, I haven't added it yet.
>>> What kind of devices are these ? There was some work around generic
>>> devfreq driver that I had seen >>on the list and my plan was to do
>>> something similar, I need to dig up details as it was while ago.
>
> These are devices needing dedicated clocks like dsp engines. There is
> a need for a userspace dev governor controlling the frequency in
> different situation.
Okay, thanks for the info.
> Could you please share your patches and any instructions if needed.
>
It needs some polishing before I post them externally, they are still hackish. I will do soonish.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: mt8183: Add node for the Mali GPU
From: Nicolas Boichat @ 2019-09-18 22:16 UTC (permalink / raw)
To: Alyssa Rosenzweig
Cc: Mark Rutland, devicetree, Dominik Behr,
linux-kernel@vger.kernel.org, Douglas Anderson, Rob Herring,
moderated list:ARM/Mediatek SoC support, Boris Brezillon,
Matthias Brugger, Nick Fan,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190913181729.GB3115@kevin>
Thanks Rob and Alyssa.
+Douglas Anderson +Dominik Behr who may be interested (if not already aware)
On Sat, Sep 14, 2019 at 2:17 AM Alyssa Rosenzweig
<alyssa.rosenzweig@collabora.com> wrote:
>
> > > > The binding we use with out-of-tree Mali drivers includes more
> > > > clocks, I assume this would be required eventually if we have an
> > > > in-tree driver:
> > >
> > > We have an in-tree driver...
> >
> > Right but AFAICT it does not support Bifrost GPU (yet?).
>
> By the time MT8183 shows up in more concrete devices, it will, certainly
> in kernel-space and likely in userspace as well. At present, the DDK can
> be modified to run on top of the in-tree Mali drivers, i.e. "Bifrost on
> mainline linux-next (+ page table/compatible patches), with blob
> userspace".
>
> While the open userspace isn't ready here quite yet, I would definitely
> encourage upstream kernel for ChromeOS, since then there's no need to
> maintain the out-of-tree GPU driver.
That's an interesting idea, I had no idea, thanks for the info!
Would that work with midgard as well? We have released hardware with
RK3288/3399, so it might be nice to experiment with these first.
>
> ---
>
> More immediately, per Rob's review, it's important that the bindings
> accepted upstream work with the in-tree Bifrost driver. Conceptually,
> once Mesa supports Bifrost, if I install Debian on a MT8183 board,
> everything should just work. I shouldn't need MT-specific changes / need
> to change names for the DT. Regardless of which kernel driver you end up
> using, minimally sharing the DT is good for everyone :-)
Yes. I'll try to dig further with MTK, but this may take some time.
>
> -Alyssa
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mfd: mt6360: add pmic mt6360 driver
From: kbuild test robot @ 2019-09-18 21:58 UTC (permalink / raw)
To: Gene Chen
Cc: gene_chen, Wilma.Wu, linux-kernel, linux-mediatek, kbuild-all,
matthias.bgg, lee.jones, linux-arm-kernel, shufan_lee
In-Reply-To: <1568801744-21380-1-git-send-email-gene.chen.richtek@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3146 bytes --]
Hi Gene,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190917]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Gene-Chen/mfd-mt6360-add-pmic-mt6360-driver/20190918-181850
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=ia64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from <command-line>:0:0:
include/linux/mfd/mt6360-private.h: In function 'mt6360_dt_parser_helper':
include/linux/mfd/mt6360-private.h:243:3: error: implicit declaration of function 'of_property_read_u32' [-Werror=implicit-function-declaration]
of_property_read_u32(np, props[i].name, data + props[i].offset);
^~~~~~~~~~~~~~~~~~~~
include/linux/mfd/mt6360-private.h: In function 'mt6360_pdata_apply_helper':
>> include/linux/mfd/mt6360-private.h:271:9: error: implicit declaration of function 'regmap_update_bits'; did you mean 'file_update_time'? [-Werror=implicit-function-declaration]
ret = regmap_update_bits(context,
^~~~~~~~~~~~~~~~~~
file_update_time
cc1: some warnings being treated as errors
vim +271 include/linux/mfd/mt6360-private.h
233
234 static inline void mt6360_dt_parser_helper(struct device_node *np, void *data,
235 const struct mt6360_val_prop *props,
236 int prop_cnt)
237 {
238 int i;
239
240 for (i = 0; i < prop_cnt; i++) {
241 if (unlikely(!props[i].name))
242 continue;
> 243 of_property_read_u32(np, props[i].name, data + props[i].offset);
244 }
245 }
246
247 #define MT6360_PDATA_VALPROP(name, type, reg, shift, mask, func, base) \
248 {offsetof(type, name), reg, shift, mask, func, base}
249
250 struct mt6360_pdata_prop {
251 size_t offset;
252 u8 reg;
253 u8 shift;
254 u8 mask;
255 u32 (*transform)(u32 val);
256 u8 base;
257 };
258
259 static inline int mt6360_pdata_apply_helper(void *context, void *pdata,
260 const struct mt6360_pdata_prop *prop,
261 int prop_cnt)
262 {
263 int i, ret;
264 u32 val;
265
266 for (i = 0; i < prop_cnt; i++) {
267 val = *(u32 *)(pdata + prop[i].offset);
268 if (prop[i].transform)
269 val = prop[i].transform(val);
270 val += prop[i].base;
> 271 ret = regmap_update_bits(context,
272 prop[i].reg, prop[i].mask, val << prop[i].shift);
273 if (ret < 0)
274 return ret;
275 }
276 return 0;
277 }
278
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 54645 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/8] PM / devfreq: Don't fail devfreq_dev_release if not in list
From: Matthias Kaehlcke @ 2019-09-18 21:41 UTC (permalink / raw)
To: Leonard Crestez
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan, linux-pm,
Viresh Kumar, Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park,
MyungJoo Ham, Alexandre Bailon, Georgi Djakov, linux-arm-kernel,
Jacky Bai
In-Reply-To: <60f8aa909fe209632734b6c637dffbc7554f996c.1568764439.git.leonard.crestez@nxp.com>
On Wed, Sep 18, 2019 at 03:18:21AM +0300, Leonard Crestez wrote:
> Right now devfreq_dev_release will print a warning and abort the rest of
> the cleanup if the devfreq instance is not part of the global
> devfreq_list. But this is a valid scenario, for example it can happen if
> the governor can't be found or on any other init error that happens
> after device_register.
>
> Initialize devfreq->node to an empty list head in devfreq_add_device so
> that list_del becomes a safe noop inside devfreq_dev_release and we can
> continue the rest of the cleanup.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
> drivers/devfreq/devfreq.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 665575228c4f..a715f27f35fd 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -582,15 +582,10 @@ static int devfreq_notifier_call(struct notifier_block *nb, unsigned long type,
> static void devfreq_dev_release(struct device *dev)
> {
> struct devfreq *devfreq = to_devfreq(dev);
>
> mutex_lock(&devfreq_list_lock);
> - if (IS_ERR(find_device_devfreq(devfreq->dev.parent))) {
> - mutex_unlock(&devfreq_list_lock);
> - dev_warn(&devfreq->dev, "releasing devfreq which doesn't exist\n");
> - return;
> - }
> list_del(&devfreq->node);
> mutex_unlock(&devfreq_list_lock);
>
> if (devfreq->profile->exit)
> devfreq->profile->exit(devfreq->dev.parent);
> @@ -641,10 +636,11 @@ struct devfreq *devfreq_add_device(struct device *dev,
> mutex_init(&devfreq->lock);
> mutex_lock(&devfreq->lock);
> devfreq->dev.parent = dev;
> devfreq->dev.class = devfreq_class;
> devfreq->dev.release = devfreq_dev_release;
> + INIT_LIST_HEAD(&devfreq->node);
> devfreq->profile = profile;
> strncpy(devfreq->governor_name, governor_name, DEVFREQ_NAME_LEN);
> devfreq->previous_freq = profile->initial_freq;
> devfreq->last_status.current_frequency = profile->initial_freq;
> devfreq->data = data;
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/8] PM / devfreq: Lock devfreq in trans_stat_show
From: Matthias Kaehlcke @ 2019-09-18 21:28 UTC (permalink / raw)
To: Leonard Crestez
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan, linux-pm,
Viresh Kumar, Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park,
MyungJoo Ham, Alexandre Bailon, Georgi Djakov, linux-arm-kernel,
Jacky Bai
In-Reply-To: <7d8f4d5c608d45ba19cdd52068fe6ffe30de67c1.1568764439.git.leonard.crestez@nxp.com>
Hi Leonard,
this series doesn't indicate the version, from the change history in
the cover letter I suppose it is v5.
On Wed, Sep 18, 2019 at 03:18:20AM +0300, Leonard Crestez wrote:
> There is no locking in this sysfs show function so stats printing can
> race with a devfreq_update_status called as part of freq switching or
> with initialization.
>
> Also add an assert in devfreq_update_status to make it clear that lock
> must be held by caller.
This and some other patches look like generic improvements and not
directly related to the series "PM / devfreq: Add dev_pm_qos
support". If there are no dependencies I think it is usually better to
send the improvements separately, it keeps the series more focussed
and might reduce version churn. Just my POV though ;-)
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
> drivers/devfreq/devfreq.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 2494ee16f502..665575228c4f 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -159,10 +159,11 @@ int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
> {
> int lev, prev_lev, ret = 0;
> unsigned long cur_time;
>
> cur_time = jiffies;
> + lockdep_assert_held(&devfreq->lock);
>
> /* Immediately exit if previous_freq is not initialized yet. */
> if (!devfreq->previous_freq)
> goto out;
>
> @@ -1415,15 +1416,20 @@ static ssize_t trans_stat_show(struct device *dev,
> struct devfreq *devfreq = to_devfreq(dev);
> ssize_t len;
> int i, j;
> unsigned int max_state = devfreq->profile->max_state;
>
> + mutex_lock(&devfreq->lock);
> if (!devfreq->stop_polling &&
> - devfreq_update_status(devfreq, devfreq->previous_freq))
> - return 0;
> - if (max_state == 0)
> - return sprintf(buf, "Not Supported.\n");
> + devfreq_update_status(devfreq, devfreq->previous_freq)) {
> + len = 0;
you could assign 'len' in the declaration instead, but it's just
another option, it'ss fine as is.
> + goto out;
> + }
> + if (max_state == 0) {
> + len = sprintf(buf, "Not Supported.\n");
> + goto out;
> + }
This leaves the general structure of the code as is, which is great,
but since you are already touching this part you can consider to
improve it: 'max_state' is constant after device creation, hence the
check could be done at the beginning, which IMO would be clearer, it
could also save an unnecessary devfreq_update_status() call and it
wouldn't be necessary to hold the lock (one goto less).
> len = sprintf(buf, " From : To\n");
> len += sprintf(buf + len, " :");
> for (i = 0; i < max_state; i++)
> len += sprintf(buf + len, "%10lu",
> @@ -1447,10 +1453,13 @@ static ssize_t trans_stat_show(struct device *dev,
> jiffies_to_msecs(devfreq->time_in_state[i]));
> }
>
> len += sprintf(buf + len, "Total transition : %u\n",
> devfreq->total_trans);
> +
> +out:
> + mutex_unlock(&devfreq->lock);
> return len;
> }
> static DEVICE_ATTR_RO(trans_stat);
>
> static struct attribute *devfreq_attrs[] = {
My only comments are possible improvements, but the change also looks
good as is, so:
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: Mimi Zohar @ 2019-09-18 21:21 UTC (permalink / raw)
To: Prakhar Srivastava, linux-kernel, linux-arm-kernel,
linux-integrity, kexec
Cc: mark.rutland, jean-philippe, arnd, takahiro.akashi, sboyd,
catalin.marinas, yamada.masahiro, kristina.martsenko, duwe,
bauerman, james.morse, tglx, allison
In-Reply-To: <1568816111.16709.68.camel@linux.ibm.com>
On Wed, 2019-09-18 at 10:15 -0400, Mimi Zohar wrote:
> > + uint64_t tmp_start, tmp_end;
> > +
> > + propStart = of_find_property(of_chosen, "linux,ima-kexec-buffer",
> > + NULL);
> > + if (propStart) {
> > + tmp_start = fdt64_to_cpu(*((const fdt64_t *) propStart));
> > + ret = of_remove_property(of_chosen, propStart);
> > + if (!ret) {
> > + return ret;
> > + }
> > +
> > + propEnd = of_find_property(of_chosen,
> > + "linux,ima-kexec-buffer-end", NULL);
> > + if (!propEnd) {
> > + return -EINVAL;
> > + }
> > +
> > + tmp_end = fdt64_to_cpu(*((const fdt64_t *) propEnd));
> > +
> > + ret = of_remove_property(of_chosen, propEnd);
> > + if (!ret) {
> > + return ret;
> > + }
>
> There seems to be quite a bit of code duplication in this function and
> in ima_get_kexec_buffer(). It could probably be cleaned up with some
> refactoring.
Sorry, my mistake. One calls of_get_property(), while the other calls
of_find_property().
Mimi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] of: restore old handling of cells_name=NULL in of_*_phandle_with_args()
From: Uwe Kleine-König @ 2019-09-18 20:19 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, Geert Uytterhoeven, Frank Rowand,
Joerg Roedel, linux-kernel@vger.kernel.org,
linux-mediatek@lists.infradead.org, kernel@pengutronix.de,
Matthias Brugger, Geert Uytterhoeven, Robin Murphy, Will Deacon,
Peter Rosin, linux-arm-kernel@lists.infradead.org,
Marek Szyprowski
In-Reply-To: <CAL_JsqJuJrOj+D4xkGACC1=zaB5OUkt=SNzCOiOiTVtM9E9z+A@mail.gmail.com>
On Wed, Sep 18, 2019 at 03:09:06PM -0500, Rob Herring wrote:
> On Wed, Sep 18, 2019 at 3:47 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > Before commit e42ee61017f5 ("of: Let of_for_each_phandle fallback to
> > non-negative cell_count") the iterator functions calling
> > of_for_each_phandle assumed a cell count of 0 if cells_name was NULL.
> > This corner case was missed when implementing the fallback logic in
> > e42ee61017f5 and resulted in an endless loop.
> >
> > Restore the old behaviour of of_count_phandle_with_args() and
> > of_parse_phandle_with_args() and add a check to
> > of_phandle_iterator_init() to prevent a similar failure as a safety
> > precaution. of_parse_phandle_with_args_map() doesn't need a similar fix
> > as cells_name isn't NULL there.
> >
> > Affected drivers are:
> > - drivers/base/power/domain.c
> > - drivers/base/power/domain.c
> > - drivers/clk/ti/clk-dra7-atl.c
> > - drivers/hwmon/ibmpowernv.c
> > - drivers/i2c/muxes/i2c-demux-pinctrl.c
> > - drivers/iommu/mtk_iommu.c
> > - drivers/net/ethernet/freescale/fman/mac.c
> > - drivers/opp/of.c
> > - drivers/perf/arm_dsu_pmu.c
> > - drivers/regulator/of_regulator.c
> > - drivers/remoteproc/imx_rproc.c
> > - drivers/soc/rockchip/pm_domains.c
> > - sound/soc/fsl/imx-audmix.c
> > - sound/soc/fsl/imx-audmix.c
> > - sound/soc/meson/axg-card.c
> > - sound/soc/samsung/tm2_wm5110.c
> > - sound/soc/samsung/tm2_wm5110.c
> >
> > Thanks to Geert Uytterhoeven for reporting the issue, Peter Rosin for
> > helping pinpoint the actual problem and the testers for confirming this
> > fix.
> >
> > Fixes: e42ee61017f5 ("of: Let of_for_each_phandle fallback to non-negative cell_count")
> > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> >
> > On Wed, Sep 18, 2019 at 08:01:05AM +0000, Peter Rosin wrote:
> > > On 2019-09-18 08:38, Uwe Kleine-König wrote:
> > > > EXPORT_SYMBOL(of_parse_phandle_with_args);
> > > >
> > > > @@ -1765,6 +1779,18 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
> > > > struct of_phandle_iterator it;
> > > > int rc, cur_index = 0;
> > > >
> > > > + /* If cells_name is NULL we assume a cell count of 0 */
> > > > + if (cells_name == NULL) {
> > >
> > > A couple of nits.
> > >
> > > I don't know if there are other considerations, but in the previous two
> > > hunks you use !cells_name instead of comparing explicitly with NULL.
> > > Personally, I find the shorter form more readable, and in the name of
> > > consistency bla bla...
> >
> > Ack, changed to !cells_name here, too.
> >
> > >
> > > Also, the comment explaining this NULL-check didn't really make sense
> > > to me until I realized that knowing the cell count to be zero makes
> > > counting trivial. Something along those lines should perhaps be in the
> > > comment?
> >
> > You're right, I extended the comment a bit.
> >
> > > But as I said, these are nits. Feel free to ignore.
> >
> > I considered resending already anyhow as I fatfingerd my email address.
> > this is fixed now, too. Additionally I fixed a typo in one of the
> > comments.
> >
> > Thanks for your feedback.
> >
> > Best regards
> > Uwe
> >
> > drivers/of/base.c | 35 +++++++++++++++++++++++++++++++++--
> > 1 file changed, 33 insertions(+), 2 deletions(-)
>
> Can I get a proper patch please.
I don't understand what is wrong with my patch. Can you please expand
what you are missing? I just tried to git-am it and the result looks
fine.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm: sun8i-ui/vi: Fix layer zpos change/atomic modesetting
From: Maxime Ripard @ 2019-09-18 20:16 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Chen-Yu Tsai, dri-devel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20190918152309.j2dbu63jaru6jn2t@core.my.home>
[-- Attachment #1.1: Type: text/plain, Size: 2176 bytes --]
On Wed, Sep 18, 2019 at 05:23:09PM +0200, Ondřej Jirman wrote:
> Hi,
>
> On Wed, Sep 18, 2019 at 04:17:34PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Sun, Sep 15, 2019 at 12:03:37AM +0200, megous@megous.com wrote:
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > There are various issues that this re-work of sun8i_[uv]i_layer_enable
> > > function fixes:
> > >
> > > - Make sure that we re-initialize zpos on reset
> > > - Minimize register updates by doing them only when state changes
> > > - Fix issue where DE pipe might get disabled even if it is no longer
> > > used by the layer that's currently calling sun8i_ui_layer_enable
> > > - .atomic_disable callback is not really needed because .atomic_update
> > > can do the disable too, so drop the duplicate code
> > >
> > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> >
> > It looks like these fixes should be in separate patches. Is there any
> > reason it's not the case?
>
> Bullet points just describe the resulting effect/benefits of the change to fix
> the pipe control register update issue (see the referenced e-mail).
It's definitely ok to have multiple patches needed to address a single
perceived issue.
A commit is not about what you're fixing but what you're changing. And
the fact that you have tha bullet list in the first place proves that
you have multiple logical changes in your patch.
And even then, your commit log mentions that you're fixing multiple
issues (without explaining them).
> I can maybe split off the first bullet point into a separate patch. But
> I can't guarantee it will not make the original issue worse, because it might
> have been hiding the other issue with register updates.
>
> The rest is just a result of the single logical change. It doesn't work
> individually, it all has the goal of fixing the issue as a whole.
>
> If I were to split it I would have to actually re-implement .atomic_disable
> callback only to remove it in the next patch. I don't see the benefit.
Your commit log says that you remove atomic_disable. Why would you
remove it, to add it back, to remove it again?
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] serial: bcm2835: Use devm_platform_ioremap_resource() in bcm2835aux_serial_probe()
From: Markus Elfring @ 2019-09-18 20:12 UTC (permalink / raw)
To: linux-serial, linux-rpi-kernel, linux-arm-kernel,
bcm-kernel-feedback-list, Eric Anholt, Florian Fainelli,
Greg Kroah-Hartman, Jiri Slaby, Martin Sperl, Ray Jui,
Scott Branden, Stefan Wahren, Stephen Boyd
Cc: Bartosz Golaszewski, kernel-janitors, LKML, Himanshu Jha
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 18 Sep 2019 22:00:14 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/tty/serial/8250/8250_bcm2835aux.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_bcm2835aux.c b/drivers/tty/serial/8250/8250_bcm2835aux.c
index 8ce700c1a7fc..e2c9d19fc8e9 100644
--- a/drivers/tty/serial/8250/8250_bcm2835aux.c
+++ b/drivers/tty/serial/8250/8250_bcm2835aux.c
@@ -25,7 +25,6 @@ struct bcm2835aux_data {
static int bcm2835aux_serial_probe(struct platform_device *pdev)
{
struct bcm2835aux_data *data;
- struct resource *res;
int ret;
/* allocate the custom structure */
@@ -61,12 +60,7 @@ static int bcm2835aux_serial_probe(struct platform_device *pdev)
data->uart.port.irq = ret;
/* map the main registers */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "memory resource not found");
- return -EINVAL;
- }
- data->uart.port.membase = devm_ioremap_resource(&pdev->dev, res);
+ data->uart.port.membase = devm_platform_ioremap_resource(pdev, 0);
ret = PTR_ERR_OR_ZERO(data->uart.port.membase);
if (ret)
return ret;
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] of: restore old handling of cells_name=NULL in of_*_phandle_with_args()
From: Rob Herring @ 2019-09-18 20:09 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: devicetree@vger.kernel.org, Geert Uytterhoeven, Will Deacon,
Joerg Roedel, linux-kernel@vger.kernel.org,
linux-mediatek@lists.infradead.org, kernel@pengutronix.de,
Matthias Brugger, Geert Uytterhoeven, Marek Szyprowski,
Frank Rowand, Peter Rosin, linux-arm-kernel@lists.infradead.org,
Robin Murphy
In-Reply-To: <20190918084748.hnjkiq7wc5b35wjh@pengutronix.de>
On Wed, Sep 18, 2019 at 3:47 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> Before commit e42ee61017f5 ("of: Let of_for_each_phandle fallback to
> non-negative cell_count") the iterator functions calling
> of_for_each_phandle assumed a cell count of 0 if cells_name was NULL.
> This corner case was missed when implementing the fallback logic in
> e42ee61017f5 and resulted in an endless loop.
>
> Restore the old behaviour of of_count_phandle_with_args() and
> of_parse_phandle_with_args() and add a check to
> of_phandle_iterator_init() to prevent a similar failure as a safety
> precaution. of_parse_phandle_with_args_map() doesn't need a similar fix
> as cells_name isn't NULL there.
>
> Affected drivers are:
> - drivers/base/power/domain.c
> - drivers/base/power/domain.c
> - drivers/clk/ti/clk-dra7-atl.c
> - drivers/hwmon/ibmpowernv.c
> - drivers/i2c/muxes/i2c-demux-pinctrl.c
> - drivers/iommu/mtk_iommu.c
> - drivers/net/ethernet/freescale/fman/mac.c
> - drivers/opp/of.c
> - drivers/perf/arm_dsu_pmu.c
> - drivers/regulator/of_regulator.c
> - drivers/remoteproc/imx_rproc.c
> - drivers/soc/rockchip/pm_domains.c
> - sound/soc/fsl/imx-audmix.c
> - sound/soc/fsl/imx-audmix.c
> - sound/soc/meson/axg-card.c
> - sound/soc/samsung/tm2_wm5110.c
> - sound/soc/samsung/tm2_wm5110.c
>
> Thanks to Geert Uytterhoeven for reporting the issue, Peter Rosin for
> helping pinpoint the actual problem and the testers for confirming this
> fix.
>
> Fixes: e42ee61017f5 ("of: Let of_for_each_phandle fallback to non-negative cell_count")
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
>
> On Wed, Sep 18, 2019 at 08:01:05AM +0000, Peter Rosin wrote:
> > On 2019-09-18 08:38, Uwe Kleine-König wrote:
> > > EXPORT_SYMBOL(of_parse_phandle_with_args);
> > >
> > > @@ -1765,6 +1779,18 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
> > > struct of_phandle_iterator it;
> > > int rc, cur_index = 0;
> > >
> > > + /* If cells_name is NULL we assume a cell count of 0 */
> > > + if (cells_name == NULL) {
> >
> > A couple of nits.
> >
> > I don't know if there are other considerations, but in the previous two
> > hunks you use !cells_name instead of comparing explicitly with NULL.
> > Personally, I find the shorter form more readable, and in the name of
> > consistency bla bla...
>
> Ack, changed to !cells_name here, too.
>
> >
> > Also, the comment explaining this NULL-check didn't really make sense
> > to me until I realized that knowing the cell count to be zero makes
> > counting trivial. Something along those lines should perhaps be in the
> > comment?
>
> You're right, I extended the comment a bit.
>
> > But as I said, these are nits. Feel free to ignore.
>
> I considered resending already anyhow as I fatfingerd my email address.
> this is fixed now, too. Additionally I fixed a typo in one of the
> comments.
>
> Thanks for your feedback.
>
> Best regards
> Uwe
>
> drivers/of/base.c | 35 +++++++++++++++++++++++++++++++++--
> 1 file changed, 33 insertions(+), 2 deletions(-)
Can I get a proper patch please.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/3] drm: Measure Self Refresh Entry/Exit times to avoid thrashing
From: Sean Paul @ 2019-09-18 20:07 UTC (permalink / raw)
To: dri-devel
Cc: heiko, linux-rockchip, Maxime Ripard, Daniel Vetter,
Maarten Lankhorst, Sandy Huang, linux-kernel, David Airlie,
Sean Paul, daniel, jekarl, Sean Paul, linux-arm-kernel
In-Reply-To: <20190918200734.149876-1-sean@poorly.run>
From: Sean Paul <seanpaul@chromium.org>
Currently the self refresh idle timer is a const set by the crtc. This
is fine if the self refresh entry/exit times are well-known for all
panels used on that crtc. However panels and workloads can vary quite a
bit, and a timeout which works well for one doesn't work well for
another.
In the extreme, if the timeout is too short we could get in a situation
where the self refresh exits are taking so long we queue up a self refresh
entry before the exit commit is even finished.
This patch changes the idle timeout to a moving average of the entry
times + a moving average of exit times + the crtc constant.
This patch was tested on rockchip, with a kevin CrOS panel the idle
delay averages out to about ~235ms (35 entry + 100 exit + 100 const). On
the same board, the bob panel idle delay lands around ~340ms (90 entry
+ 150 exit + 100 const).
WRT the dedicated mutex in self_refresh_data, it would be nice if we
could rely on drm_crtc.mutex to protect the average times, but there are
a few reasons why a separate lock is a better choice:
- We can't rely on drm_crtc.mutex being held if we're doing a nonblocking
commit
- We can't grab drm_crtc.mutex since drm_modeset_lock() doesn't tell us
whether the lock was already held in the acquire context (it eats
-EALREADY), so we can't tell if we should drop it or not
- We don't need such a heavy-handed lock for what we're trying to do,
commit ordering doesn't matter, so a point-of-use lock will be less
contentious
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-2-sean@poorly.run
Changes in v2:
- Migrate locking explanation from comment to commit msg (Daniel)
- Turf constant entry delay and multiply the avg times by 2 (Daniel)
---
drivers/gpu/drm/drm_atomic_helper.c | 20 ++++++
drivers/gpu/drm/drm_self_refresh_helper.c | 72 +++++++++++++++++++--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +-
include/drm/drm_self_refresh_helper.h | 6 +-
4 files changed, 90 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 9d7e4da6c292..3f13fa9a9e24 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -26,6 +26,7 @@
*/
#include <linux/dma-fence.h>
+#include <linux/ktime.h>
#include <drm/drm_atomic.h>
#include <drm/drm_atomic_helper.h>
@@ -1570,9 +1571,23 @@ static void commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
const struct drm_mode_config_helper_funcs *funcs;
+ ktime_t start;
+ s64 commit_time_ms;
funcs = dev->mode_config.helper_private;
+ /*
+ * We're measuring the _entire_ commit, so the time will vary depending
+ * on how many fences and objects are involved. For the purposes of self
+ * refresh, this is desirable since it'll give us an idea of how
+ * congested things are. This will inform our decision on how often we
+ * should enter self refresh after idle.
+ *
+ * These times will be averaged out in the self refresh helpers to avoid
+ * overreacting over one outlier frame
+ */
+ start = ktime_get();
+
drm_atomic_helper_wait_for_fences(dev, old_state, false);
drm_atomic_helper_wait_for_dependencies(old_state);
@@ -1582,6 +1597,11 @@ static void commit_tail(struct drm_atomic_state *old_state)
else
drm_atomic_helper_commit_tail(old_state);
+ commit_time_ms = ktime_ms_delta(ktime_get(), start);
+ if (commit_time_ms > 0)
+ drm_self_refresh_helper_update_avg_times(old_state,
+ (unsigned long)commit_time_ms);
+
drm_atomic_helper_commit_cleanup_done(old_state);
drm_atomic_state_put(old_state);
diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c b/drivers/gpu/drm/drm_self_refresh_helper.c
index 9095cebf2147..68f4765a5896 100644
--- a/drivers/gpu/drm/drm_self_refresh_helper.c
+++ b/drivers/gpu/drm/drm_self_refresh_helper.c
@@ -5,6 +5,7 @@
* Authors:
* Sean Paul <seanpaul@chromium.org>
*/
+#include <linux/average.h>
#include <linux/bitops.h>
#include <linux/slab.h>
#include <linux/workqueue.h>
@@ -50,10 +51,17 @@
* atomic_check when &drm_crtc_state.self_refresh_active is true.
*/
+#define SELF_REFRESH_AVG_SEED_MS 200
+
+DECLARE_EWMA(psr_time, 4, 4)
+
struct drm_self_refresh_data {
struct drm_crtc *crtc;
struct delayed_work entry_work;
- unsigned int entry_delay_ms;
+
+ struct mutex avg_mutex;
+ struct ewma_psr_time entry_avg_ms;
+ struct ewma_psr_time exit_avg_ms;
};
static void drm_self_refresh_helper_entry_work(struct work_struct *work)
@@ -121,6 +129,44 @@ static void drm_self_refresh_helper_entry_work(struct work_struct *work)
drm_modeset_acquire_fini(&ctx);
}
+/**
+ * drm_self_refresh_helper_update_avg_times - Updates a crtc's SR time averages
+ * @state: the state which has just been applied to hardware
+ * @commit_time_ms: the amount of time in ms that this commit took to complete
+ *
+ * Called after &drm_mode_config_funcs.atomic_commit_tail, this function will
+ * update the average entry/exit self refresh times on self refresh transitions.
+ * These averages will be used when calculating how long to delay before
+ * entering self refresh mode after activity.
+ */
+void drm_self_refresh_helper_update_avg_times(struct drm_atomic_state *state,
+ unsigned int commit_time_ms)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ int i;
+
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ struct drm_self_refresh_data *sr_data = crtc->self_refresh_data;
+ struct ewma_psr_time *time;
+
+ if (old_crtc_state->self_refresh_active ==
+ new_crtc_state->self_refresh_active)
+ continue;
+
+ if (new_crtc_state->self_refresh_active)
+ time = &sr_data->entry_avg_ms;
+ else
+ time = &sr_data->exit_avg_ms;
+
+ mutex_lock(&sr_data->avg_mutex);
+ ewma_psr_time_add(time, commit_time_ms);
+ mutex_unlock(&sr_data->avg_mutex);
+ }
+}
+EXPORT_SYMBOL(drm_self_refresh_helper_update_avg_times);
+
/**
* drm_self_refresh_helper_alter_state - Alters the atomic state for SR exit
* @state: the state currently being checked
@@ -152,6 +198,7 @@ void drm_self_refresh_helper_alter_state(struct drm_atomic_state *state)
for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
struct drm_self_refresh_data *sr_data;
+ unsigned int delay;
/* Don't trigger the entry timer when we're already in SR */
if (crtc_state->self_refresh_active)
@@ -161,8 +208,13 @@ void drm_self_refresh_helper_alter_state(struct drm_atomic_state *state)
if (!sr_data)
continue;
+ mutex_lock(&sr_data->avg_mutex);
+ delay = (ewma_psr_time_read(&sr_data->entry_avg_ms) +
+ ewma_psr_time_read(&sr_data->exit_avg_ms)) * 2;
+ mutex_unlock(&sr_data->avg_mutex);
+
mod_delayed_work(system_wq, &sr_data->entry_work,
- msecs_to_jiffies(sr_data->entry_delay_ms));
+ msecs_to_jiffies(delay));
}
}
EXPORT_SYMBOL(drm_self_refresh_helper_alter_state);
@@ -170,12 +222,10 @@ EXPORT_SYMBOL(drm_self_refresh_helper_alter_state);
/**
* drm_self_refresh_helper_init - Initializes self refresh helpers for a crtc
* @crtc: the crtc which supports self refresh supported displays
- * @entry_delay_ms: amount of inactivity to wait before entering self refresh
*
* Returns zero if successful or -errno on failure
*/
-int drm_self_refresh_helper_init(struct drm_crtc *crtc,
- unsigned int entry_delay_ms)
+int drm_self_refresh_helper_init(struct drm_crtc *crtc)
{
struct drm_self_refresh_data *sr_data = crtc->self_refresh_data;
@@ -189,8 +239,18 @@ int drm_self_refresh_helper_init(struct drm_crtc *crtc,
INIT_DELAYED_WORK(&sr_data->entry_work,
drm_self_refresh_helper_entry_work);
- sr_data->entry_delay_ms = entry_delay_ms;
sr_data->crtc = crtc;
+ mutex_init(&sr_data->avg_mutex);
+ ewma_psr_time_init(&sr_data->entry_avg_ms);
+ ewma_psr_time_init(&sr_data->exit_avg_ms);
+
+ /*
+ * Seed the averages so they're non-zero (and sufficiently large
+ * for even poorly performing panels). As time goes on, this will be
+ * averaged out and the values will trend to their true value.
+ */
+ ewma_psr_time_add(&sr_data->entry_avg_ms, SELF_REFRESH_AVG_SEED_MS);
+ ewma_psr_time_add(&sr_data->exit_avg_ms, SELF_REFRESH_AVG_SEED_MS);
crtc->self_refresh_data = sr_data;
return 0;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2f821c58007c..613404f86668 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -39,8 +39,6 @@
#include "rockchip_drm_vop.h"
#include "rockchip_rgb.h"
-#define VOP_SELF_REFRESH_ENTRY_DELAY_MS 100
-
#define VOP_WIN_SET(vop, win, name, v) \
vop_reg_set(vop, &win->phy->name, win->base, ~0, v, #name)
#define VOP_SCL_SET(vop, win, name, v) \
@@ -1563,8 +1561,7 @@ static int vop_create_crtc(struct vop *vop)
init_completion(&vop->line_flag_completion);
crtc->port = port;
- ret = drm_self_refresh_helper_init(crtc,
- VOP_SELF_REFRESH_ENTRY_DELAY_MS);
+ ret = drm_self_refresh_helper_init(crtc);
if (ret)
DRM_DEV_DEBUG_KMS(vop->dev,
"Failed to init %s with SR helpers %d, ignoring\n",
diff --git a/include/drm/drm_self_refresh_helper.h b/include/drm/drm_self_refresh_helper.h
index 397a583ccca7..5b79d253fb46 100644
--- a/include/drm/drm_self_refresh_helper.h
+++ b/include/drm/drm_self_refresh_helper.h
@@ -12,9 +12,9 @@ struct drm_atomic_state;
struct drm_crtc;
void drm_self_refresh_helper_alter_state(struct drm_atomic_state *state);
+void drm_self_refresh_helper_update_avg_times(struct drm_atomic_state *state,
+ unsigned int commit_time_ms);
-int drm_self_refresh_helper_init(struct drm_crtc *crtc,
- unsigned int entry_delay_ms);
-
+int drm_self_refresh_helper_init(struct drm_crtc *crtc);
void drm_self_refresh_helper_cleanup(struct drm_crtc *crtc);
#endif
--
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] udc: lpc32xx: fix 64-bit compiler warning
From: Arnd Bergmann @ 2019-09-18 20:01 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Vladimir Zapolskiy,
Sylvain Lemieux
Cc: linux-arm-kernel, linux-usb, Linus Torvalds, linux-kernel,
Arnd Bergmann
gcc points out a suspicious cast from a pointer to an 'int' when
compile-testing on 64-bit architectures.
drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_pop_fifo’:
drivers/usb/gadget/udc/lpc32xx_udc.c:1156:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_stuff_fifo’:
drivers/usb/gadget/udc/lpc32xx_udc.c:1257:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
The code works find, but it's easy enough to change the cast to
a uintptr_t to shut up that warning.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/usb/gadget/udc/Kconfig | 2 +-
drivers/usb/gadget/udc/lpc32xx_udc.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 868bdf7f42d0..ac0891a3dbf2 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -45,7 +45,7 @@ config USB_AT91
config USB_LPC32XX
tristate "LPC32XX USB Peripheral Controller"
- depends on ARCH_LPC32XX
+ depends on ARCH_LPC32XX || COMPILE_TEST
depends on I2C
select USB_ISP1301
help
diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c b/drivers/usb/gadget/udc/lpc32xx_udc.c
index b3e073fb88c6..2b1f3cc7819b 100644
--- a/drivers/usb/gadget/udc/lpc32xx_udc.c
+++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
@@ -1151,7 +1151,7 @@ static void udc_pop_fifo(struct lpc32xx_udc *udc, u8 *data, u32 bytes)
u32 *p32, tmp, cbytes;
/* Use optimal data transfer method based on source address and size */
- switch (((u32) data) & 0x3) {
+ switch (((uintptr_t) data) & 0x3) {
case 0: /* 32-bit aligned */
p32 = (u32 *) data;
cbytes = (bytes & ~0x3);
@@ -1252,7 +1252,7 @@ static void udc_stuff_fifo(struct lpc32xx_udc *udc, u8 *data, u32 bytes)
u32 *p32, tmp, cbytes;
/* Use optimal data transfer method based on source address and size */
- switch (((u32) data) & 0x3) {
+ switch (((uintptr_t) data) & 0x3) {
case 0: /* 32-bit aligned */
p32 = (u32 *) data;
cbytes = (bytes & ~0x3);
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] stmmac: selftest: avoid large stack usage
From: Arnd Bergmann @ 2019-09-18 19:54 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin
Cc: linux-arm-kernel, netdev, linux-stm32, Arnd Bergmann,
linux-kernel
Putting a struct stmmac_rss object on the stack is a bad idea,
as it exceeds the warning limit for a stack frame on 32-bit architectures:
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1221:12: error: stack frame size of 1208 bytes in function '__stmmac_test_l3filt' [-Werror,-Wframe-larger-than=]
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1338:12: error: stack frame size of 1208 bytes in function '__stmmac_test_l4filt' [-Werror,-Wframe-larger-than=]
As the object is the trivial empty case, change the called function
to accept a NULL pointer to mean the same thing and remove the
large variable in the two callers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 15 +++++++++++----
.../ethernet/stmicro/stmmac/stmmac_selftests.c | 14 ++++----------
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index d5173dd02a71..c2f648062049 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -523,25 +523,32 @@ static int dwxgmac2_rss_configure(struct mac_device_info *hw,
struct stmmac_rss *cfg, u32 num_rxq)
{
void __iomem *ioaddr = hw->pcsr;
- u32 *key = (u32 *)cfg->key;
int i, ret;
u32 value;
value = readl(ioaddr + XGMAC_RSS_CTRL);
- if (!cfg->enable) {
+ if (!cfg || !cfg->enable) {
value &= ~XGMAC_RSSE;
writel(value, ioaddr + XGMAC_RSS_CTRL);
return 0;
}
for (i = 0; i < (sizeof(cfg->key) / sizeof(u32)); i++) {
- ret = dwxgmac2_rss_write_reg(ioaddr, true, i, *key++);
+ if (cfg)
+ ret = dwxgmac2_rss_write_reg(ioaddr, true, i, cfg->key[i]);
+ else
+ ret = dwxgmac2_rss_write_reg(ioaddr, true, i, 0);
+
if (ret)
return ret;
}
for (i = 0; i < ARRAY_SIZE(cfg->table); i++) {
- ret = dwxgmac2_rss_write_reg(ioaddr, false, i, cfg->table[i]);
+ if (cfg)
+ ret = dwxgmac2_rss_write_reg(ioaddr, false, i, cfg->table[i]);
+ else
+ ret = dwxgmac2_rss_write_reg(ioaddr, false, i, 0);
+
if (ret)
return ret;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index c56e89e1ae56..9c8d210b2d6a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -1233,12 +1233,9 @@ static int __stmmac_test_l3filt(struct stmmac_priv *priv, u32 dst, u32 src,
return -EOPNOTSUPP;
if (!priv->dma_cap.l3l4fnum)
return -EOPNOTSUPP;
- if (priv->rss.enable) {
- struct stmmac_rss rss = { .enable = false, };
-
- stmmac_rss_configure(priv, priv->hw, &rss,
+ if (priv->rss.enable)
+ stmmac_rss_configure(priv, priv->hw, NULL,
priv->plat->rx_queues_to_use);
- }
dissector = kzalloc(sizeof(*dissector), GFP_KERNEL);
if (!dissector) {
@@ -1357,12 +1354,9 @@ static int __stmmac_test_l4filt(struct stmmac_priv *priv, u32 dst, u32 src,
return -EOPNOTSUPP;
if (!priv->dma_cap.l3l4fnum)
return -EOPNOTSUPP;
- if (priv->rss.enable) {
- struct stmmac_rss rss = { .enable = false, };
-
- stmmac_rss_configure(priv, priv->hw, &rss,
+ if (priv->rss.enable)
+ stmmac_rss_configure(priv, priv->hw, NULL,
priv->plat->rx_queues_to_use);
- }
dissector = kzalloc(sizeof(*dissector), GFP_KERNEL);
if (!dissector) {
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] MIPS: remove support for DMA_ATTR_WRITE_COMBINE
From: Maciej W. Rozycki @ 2019-09-18 19:50 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, Michael Ellerman, linuxppc-dev, linux-kernel,
Russell King, linux-mips, iommu, Paul Burton, Catalin Marinas,
James Hogan, Will Deacon, linux-arm-kernel, Robin Murphy
In-Reply-To: <20190807061602.31217-3-hch@lst.de>
On Wed, 7 Aug 2019, Christoph Hellwig wrote:
> Mips uses the KSEG1 kernel memory segment to map dma coherent
> allocations for non-coherent devices as uncacheable, and does not have
> any kind of special support for DMA_ATTR_WRITE_COMBINE in the allocation
> path. Thus supporting DMA_ATTR_WRITE_COMBINE in dma_mmap_attrs will
> lead to multiple mappings with different caching attributes.
FYI, AFAIK _CACHE_UNCACHED_ACCELERATED (where supported) is effectively
write-combine. Though IIUC someone would have to wire it in first.
Maciej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 5/5] soc: qcom: cmd-db: Map with read-only mappings
From: Evan Green @ 2019-09-18 19:40 UTC (permalink / raw)
To: Stephen Boyd
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, Will Deacon, LKML, Bjorn Andersson, Rob Herring,
Andy Gross, Catalin Marinas, Dan Williams, linux-arm Mailing List
In-Reply-To: <20190910160903.65694-6-swboyd@chromium.org>
On Tue, Sep 10, 2019 at 9:09 AM Stephen Boyd <swboyd@chromium.org> wrote:
>
> The command DB is read-only already to the kernel because everything is
> const marked once we map it. Let's go one step further and try to map
> the memory as read-only in the page tables. This should make it harder
> for random code to corrupt the database and change the contents.
>
> Cc: Evan Green <evgreen@chromium.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
> drivers/soc/qcom/cmd-db.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
> index 10a34d26b753..6365e8260282 100644
> --- a/drivers/soc/qcom/cmd-db.c
> +++ b/drivers/soc/qcom/cmd-db.c
> @@ -240,7 +240,8 @@ static int cmd_db_dev_probe(struct platform_device *pdev)
> {
> int ret = 0;
>
> - cmd_db_header = devm_memremap_reserved_mem(&pdev->dev, MEMREMAP_WB);
> + cmd_db_header = devm_memremap_reserved_mem(&pdev->dev,
> + MEMREMAP_RO | MEMREMAP_WB);
It seems weird to have both flags, like: "It's read-only, but if it
ever did get written to somehow, make it writeback".
> if (IS_ERR(cmd_db_header)) {
> ret = PTR_ERR(cmd_db_header);
> cmd_db_header = NULL;
> --
> Sent by a computer through tubes
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/5] memremap: Add support for read-only memory mappings
From: Evan Green @ 2019-09-18 19:37 UTC (permalink / raw)
To: Stephen Boyd
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, Will Deacon, LKML, Bjorn Andersson, Rob Herring,
Andy Gross, Catalin Marinas, Dan Williams, linux-arm Mailing List
In-Reply-To: <20190910160903.65694-4-swboyd@chromium.org>
On Tue, Sep 10, 2019 at 9:09 AM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Sometimes we have memories that are supposed to be read-only, but when
> we map these regions the best we can do is map them as write-back with
> MEMREMAP_WB. Introduce a read-only memory mapping (MEMREMAP_RO) that
> allows us to map reserved memory regions as read-only. This way, we're
> less likely to see these special memory regions become corrupted by
> stray writes to them.
>
> Cc: Evan Green <evgreen@chromium.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
> include/linux/io.h | 1 +
> kernel/iomem.c | 20 +++++++++++++++++---
> 2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/io.h b/include/linux/io.h
> index accac822336a..15a63efcd153 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -148,6 +148,7 @@ enum {
> MEMREMAP_WC = 1 << 2,
> MEMREMAP_ENC = 1 << 3,
> MEMREMAP_DEC = 1 << 4,
> + MEMREMAP_RO = 1 << 5,
> };
>
> void *memremap(resource_size_t offset, size_t size, unsigned long flags);
> diff --git a/kernel/iomem.c b/kernel/iomem.c
> index 62c92e43aa0d..6d76b7398714 100644
> --- a/kernel/iomem.c
> +++ b/kernel/iomem.c
> @@ -19,6 +19,13 @@ static void *arch_memremap_wb(resource_size_t offset, unsigned long size)
> }
> #endif
>
> +#ifndef arch_memremap_ro
> +static void *arch_memremap_ro(resource_size_t offset, unsigned long size)
> +{
> + return NULL;
> +}
> +#endif
> +
> #ifndef arch_memremap_can_ram_remap
> static bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
> unsigned long flags)
> @@ -45,7 +52,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size,
> * @offset: iomem resource start address
> * @size: size of remap
> * @flags: any of MEMREMAP_WB, MEMREMAP_WT, MEMREMAP_WC,
> - * MEMREMAP_ENC, MEMREMAP_DEC
> + * MEMREMAP_ENC, MEMREMAP_DEC, MEMREMAP_RO
> *
> * memremap() is "ioremap" for cases where it is known that the resource
> * being mapped does not have i/o side effects and the __iomem
> @@ -53,6 +60,9 @@ static void *try_ram_remap(resource_size_t offset, size_t size,
> * mapping types will be attempted in the order listed below until one of
> * them succeeds.
> *
> + * MEMREMAP_RO - establish a mapping whereby writes are ignored/rejected.
> + * Attempts to map System RAM with this mapping type will fail.
Why should attempts to map RAM with this flag fail? MEMREMAP_WB will
allow RAM and quietly give you back the direct mapping, so it seems
like at least some values in this function allow RAM.
Oh, I see a comment below about "Enforce that this mapping is not
aliasing System RAM". I guess this is worried about cache coloring?
But is that a problem with RO mappings? I guess the RO mappings could
get partially stale, so if the memory were being updated out from
under you, you might see some updates but not others. Was that the
rationale?
> + *
> * MEMREMAP_WB - matches the default mapping for System RAM on
> * the architecture. This is usually a read-allocate write-back cache.
> * Moreover, if MEMREMAP_WB is specified and the requested remap region is RAM
> @@ -84,7 +94,10 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
> }
>
> /* Try all mapping types requested until one returns non-NULL */
> - if (flags & MEMREMAP_WB) {
> + if ((flags & MEMREMAP_RO) && is_ram != REGION_INTERSECTS)
> + addr = arch_memremap_ro(offset, size);
> +
> + if (!addr && (flags & MEMREMAP_WB)) {
> /*
> * MEMREMAP_WB is special in that it can be satisfied
> * from the direct map. Some archs depend on the
> @@ -103,7 +116,8 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
> * address mapping. Enforce that this mapping is not aliasing
> * System RAM.
> */
> - if (!addr && is_ram == REGION_INTERSECTS && flags != MEMREMAP_WB) {
> + if (!addr && is_ram == REGION_INTERSECTS &&
> + (flags != MEMREMAP_WB || flags != MEMREMAP_RO)) {
Isn't this condition always true? Did you mean flags != MEM_REMAP_WB
&& flags != MEMREMAP_RO?
> WARN_ONCE(1, "memremap attempted on ram %pa size: %#lx\n",
> &offset, (unsigned long) size);
> return NULL;
> --
> Sent by a computer through tubes
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: kbuild test robot @ 2019-09-18 19:35 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Catalin Marinas, linux-mm, Punit Agrawal,
Will Deacon, Alex Van Brunt, Jia He, Marc Zyngier,
Anshuman Khandual, Matthew Wilcox, Jun Yao, Kaly Xin, hejianet,
Ralph Campbell, Suzuki Poulose,
=?unknown-8bit?B?SsOpcsO0bWU=?= Glisse, Thomas Gleixner,
linux-arm-kernel, linux-kernel, James Morse, kbuild-all,
Andrew Morton, Robin Murphy, Kirill A. Shutemov
In-Reply-To: <20190918131914.38081-4-justin.he@arm.com>
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]
Hi Jia,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190917]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jia-He/fix-double-page-fault-on-arm64/20190918-220036
config: arm64-allnoconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
mm/memory.o: In function `wp_page_copy':
>> memory.c:(.text+0x8fc): undefined reference to `cpu_has_hw_af'
memory.c:(.text+0x8fc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `cpu_has_hw_af'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 7916 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mfd: mt6360: add pmic mt6360 driver
From: kbuild test robot @ 2019-09-18 19:18 UTC (permalink / raw)
To: Gene Chen
Cc: gene_chen, Wilma.Wu, linux-kernel, linux-mediatek, kbuild-all,
matthias.bgg, lee.jones, linux-arm-kernel, shufan_lee
In-Reply-To: <1568801744-21380-1-git-send-email-gene.chen.richtek@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3481 bytes --]
Hi Gene,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190917]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Gene-Chen/mfd-mt6360-add-pmic-mt6360-driver/20190918-181850
config: x86_64-randconfig-s0-201937 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
In file included from <command-line>:0:0:
>> include/linux/mfd/mt6360-private.h:234:51: warning: 'struct device_node' declared inside parameter list will not be visible outside of this definition or declaration
static inline void mt6360_dt_parser_helper(struct device_node *np, void *data,
^~~~~~~~~~~
include/linux/mfd/mt6360-private.h: In function 'mt6360_dt_parser_helper':
>> include/linux/mfd/mt6360-private.h:243:3: error: implicit declaration of function 'of_property_read_u32' [-Werror=implicit-function-declaration]
of_property_read_u32(np, props[i].name, data + props[i].offset);
^~~~~~~~~~~~~~~~~~~~
include/linux/mfd/mt6360-private.h: In function 'mt6360_pdata_apply_helper':
>> include/linux/mfd/mt6360-private.h:271:9: error: implicit declaration of function 'regmap_update_bits'; did you mean 'work_data_bits'? [-Werror=implicit-function-declaration]
ret = regmap_update_bits(context,
^~~~~~~~~~~~~~~~~~
work_data_bits
cc1: some warnings being treated as errors
vim +/of_property_read_u32 +243 include/linux/mfd/mt6360-private.h
233
> 234 static inline void mt6360_dt_parser_helper(struct device_node *np, void *data,
235 const struct mt6360_val_prop *props,
236 int prop_cnt)
237 {
238 int i;
239
240 for (i = 0; i < prop_cnt; i++) {
241 if (unlikely(!props[i].name))
242 continue;
> 243 of_property_read_u32(np, props[i].name, data + props[i].offset);
244 }
245 }
246
247 #define MT6360_PDATA_VALPROP(name, type, reg, shift, mask, func, base) \
248 {offsetof(type, name), reg, shift, mask, func, base}
249
250 struct mt6360_pdata_prop {
251 size_t offset;
252 u8 reg;
253 u8 shift;
254 u8 mask;
255 u32 (*transform)(u32 val);
256 u8 base;
257 };
258
259 static inline int mt6360_pdata_apply_helper(void *context, void *pdata,
260 const struct mt6360_pdata_prop *prop,
261 int prop_cnt)
262 {
263 int i, ret;
264 u32 val;
265
266 for (i = 0; i < prop_cnt; i++) {
267 val = *(u32 *)(pdata + prop[i].offset);
268 if (prop[i].transform)
269 val = prop[i].transform(val);
270 val += prop[i].base;
> 271 ret = regmap_update_bits(context,
272 prop[i].reg, prop[i].mask, val << prop[i].shift);
273 if (ret < 0)
274 return ret;
275 }
276 return 0;
277 }
278
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 31934 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] staging: mt7621-pci-phy: Use devm_platform_ioremap_resource() in mt7621_pci_phy_probe()
From: Markus Elfring @ 2019-09-18 19:12 UTC (permalink / raw)
To: devel, linux-arm-kernel, linux-mediatek, Antti Keränen,
Emanuel Bennici, Greg Kroah-Hartman, Matthias Brugger, Neil Brown,
Sergio Paracuellos
Cc: Bartosz Golaszewski, kernel-janitors, LKML, Himanshu Jha
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 18 Sep 2019 21:01:32 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
index d2a07f145143..6ca4a33d13c3 100644
--- a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
+++ b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
@@ -324,7 +324,6 @@ static int mt7621_pci_phy_probe(struct platform_device *pdev)
const struct soc_device_attribute *attr;
struct phy_provider *provider;
struct mt7621_pci_phy *phy;
- struct resource *res;
int port;
void __iomem *port_base;
@@ -344,14 +343,7 @@ static int mt7621_pci_phy_probe(struct platform_device *pdev)
phy->dev = dev;
platform_set_drvdata(pdev, phy);
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "failed to get address resource\n");
- return -ENXIO;
- }
-
- port_base = devm_ioremap_resource(dev, res);
+ port_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(port_base)) {
dev_err(dev, "failed to remap phy regs\n");
return PTR_ERR(port_base);
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH][next] memory: exynos5422: fix spelling mistake "counld" -> "could"
From: Krzysztof Kozlowski @ 2019-09-18 18:57 UTC (permalink / raw)
To: Colin King
Cc: linux-samsung-soc, linux-pm, kernel-janitors, linux-kernel,
Lukasz Luba, Kukjin Kim, linux-arm-kernel
In-Reply-To: <20190916091249.31950-1-colin.king@canonical.com>
On Mon, Sep 16, 2019 at 10:12:49AM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a spelling mistake in a dev_err message. Fix it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/memory/samsung/exynos5422-dmc.c | 2 +-
Thanks, applied.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: exynos: fix too long line in memory device
From: Krzysztof Kozlowski @ 2019-09-18 18:55 UTC (permalink / raw)
To: Lukasz Luba
Cc: mark.rutland, devicetree, willy.mh.wolff.ml, linux-samsung-soc,
b.zolnierkie, linux-pm, linux-kernel, robh+dt, cw00.choi,
kyungmin.park, kgene, myungjoo.ham, s.nawrocki, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190916100704.26692-3-l.luba@partner.samsung.com>
On Mon, Sep 16, 2019 at 12:07:03PM +0200, Lukasz Luba wrote:
> Small fix moving the comment to line above making sure the lines do not
> exceed 80 characters.
>
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> ---
> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 3 ++-
Thanks, applied (squashed with previous).
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] memory: Exynos5422: minor fixes in DMC
From: Krzysztof Kozlowski @ 2019-09-18 18:55 UTC (permalink / raw)
To: Lukasz Luba
Cc: mark.rutland, devicetree, willy.mh.wolff.ml, linux-samsung-soc,
b.zolnierkie, linux-pm, linux-kernel, robh+dt, cw00.choi,
kyungmin.park, kgene, myungjoo.ham, s.nawrocki, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190916100704.26692-2-l.luba@partner.samsung.com>
On Mon, Sep 16, 2019 at 12:07:02PM +0200, Lukasz Luba wrote:
> Small fixes for issues captured by static analyzes:
> used kfree() insead of devm_kfree() and missing 'static' in the private
> function.
> Checks which show the issues:
> - drivers/memory/samsung/exynos5422-dmc.c:272 exynos5_init_freq_table()
> warn: passing devm_ allocated variable to kfree. 'dmc->opp'
> - drivers/memory/samsung/exynos5422-dmc.c:736:1: warning: symbol
> 'exynos5_dmc_align_init_freq' was not declared.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> ---
> drivers/memory/samsung/exynos5422-dmc.c | 4 ++--
Thanks, applied.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories
From: Krzysztof Kozlowski @ 2019-09-18 18:51 UTC (permalink / raw)
To: Lukasz Luba
Cc: mark.rutland, devicetree, willy.mh.wolff.ml,
linux-samsung-soc@vger.kernel.org,
Bartłomiej Żołnierkiewicz, linux-pm,
linux-kernel@vger.kernel.org, robh+dt, Chanwoo Choi,
kyungmin.park, kgene, myungjoo.ham, s.nawrocki, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20190916100704.26692-4-l.luba@partner.samsung.com>
On Mon, 16 Sep 2019 at 12:07, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>
> Add compatible for Samsung k3qf2f20db LPDDR3 memory bindings.
> Introduce minor fixes in the old documentation.
>
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> ---
> Documentation/devicetree/bindings/ddr/lpddr3.txt | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt b/Documentation/devicetree/bindings/ddr/lpddr3.txt
> index 3b2485b84b3f..49afe794daaa 100644
> --- a/Documentation/devicetree/bindings/ddr/lpddr3.txt
> +++ b/Documentation/devicetree/bindings/ddr/lpddr3.txt
> @@ -1,7 +1,9 @@
> * LPDDR3 SDRAM memories compliant to JEDEC JESD209-3C
>
> Required properties:
> -- compatible : Should be - "jedec,lpddr3"
> +- compatible : should be one of the following:
> + Generic default - "jedec,lpddr3".
The convention is first compatible, then description. I gave you the
example to base on - at25. Why making it different?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] pwm: stm32-lp: add check in case requested period cannot be achieved
From: Uwe Kleine-König @ 2019-09-18 18:40 UTC (permalink / raw)
To: Fabrice Gasnier
Cc: linux-pwm, alexandre.torgue, linux-kernel, thierry.reding,
linux-stm32, linux-arm-kernel
In-Reply-To: <1568818461-19995-1-git-send-email-fabrice.gasnier@st.com>
On Wed, Sep 18, 2019 at 04:54:21PM +0200, Fabrice Gasnier wrote:
> LPTimer can use a 32KHz clock for counting. It depends on clock tree
> configuration. In such a case, PWM output frequency range is limited.
> Although unlikely, nothing prevents user from requesting a PWM frequency
> above counting clock (32KHz for instance):
> - This causes (prd - 1) = 0xffff to be written in ARR register later in
> the apply() routine.
> This results in badly configured PWM period (and also duty_cycle).
> Add a check to report an error is such a case.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
If you are interested to improve the driver further, there are a few
things that I would welcome to see fixed in a tested patch:
- duty calculation uses requested instead of implemented period.
- stm32_pwm_lp_apply calls pwm_get_state
- Calculation of prd could be done without a loop
- A hint about relevant documentation in the driver's header would be
great
- Documentation about behaviour of the hardware is missing:
- Does the hardware complete the currently running period when
STM32_LPTIM_CR is cleared?
- Does the output stop in the inactive output level when the PWM is
stopped?
- clk_get_rate might be called without the clock being enabled.
- The driver does:
ret = regmap_write(priv->regmap, STM32_LPTIM_CMP, prd - (1 + dty));
That looks wrong. (Consider dty == prd.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
From: Gerald Schaefer @ 2019-09-18 18:22 UTC (permalink / raw)
To: Christophe Leroy
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, linux-arm-kernel, linux-snps-arc,
Kees Cook, Anshuman Khandual, Masahiro Yamada, Mark Brown,
Kirill A . Shutemov, Dan Williams, Vlastimil Babka,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
Dave Hansen, linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <64504101-d9dd-f273-02f9-e9a8b178eecc@c-s.fr>
On Wed, 18 Sep 2019 18:26:03 +0200
Christophe Leroy <christophe.leroy@c-s.fr> wrote:
[..]
> My suggestion was not to completely drop the #ifdef but to do like you
> did in pgd_clear_tests() for instance, ie to add the following test on
> top of the function:
>
> if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LEVEL_HACK))
> return;
>
Ah, very nice, this would also fix the remaining issues for s390. Since
we have dynamic page table folding, neither __PAGETABLE_PXX_FOLDED nor
__ARCH_HAS_XLEVEL_HACK is defined, but mm_pxx_folded() will work.
mm_alloc() returns with a 3-level page table by default on s390, so we
will run into issues in p4d_clear/populate_tests(), and also at the end
with p4d/pud_free() (double free).
So, adding the mm_pud_folded() check to p4d_clear/populate_tests(),
and also adding mm_p4d/pud_folded() checks at the end before calling
p4d/pud_free(), would make it all work on s390.
BTW, regarding p4d/pud_free(), I'm not sure if we should rather check
the folding inside our s390 functions, similar to how we do it for
p4d/pud_free_tlb(), instead of relying on not being called for folded
p4d/pud. So far, I see no problem with this behavior, all callers of
p4d/pud_free() should be fine because of our folding check within
p4d/pud_present/none(). But that doesn't mean that it is correct not
to check for the folding inside p4d/pud_free(). At least, with this
test module we do now have a caller of p4d/pud_free() on potentially
folded entries, so instead of adding pxx_folded() checks to this
test module, we could add them to our p4d/pud_free() functions.
Any thoughts on this?
Regards,
Gerald
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox