Re: [PATCH v5 10/14] soc: mediatek: Add multiple step bus protection control
On Tue, Mar 19, 2019 at 4:02 PM Weiyi Lu wrote:
>
> Both MT8183 & MT6765 have more control steps of bus protection
> than previous project. And there add more bus protection registers
> reside at infracfg & smi-common. Also add new APIs for multiple
> step bus protection control with more customize arguments.
>
> Signed-off-by: Weiyi Lu
> ---
> drivers/soc/mediatek/Makefile | 2 +-
> drivers/soc/mediatek/mtk-scpsys-ext.c | 99 +
> drivers/soc/mediatek/mtk-scpsys.c | 24 ++
> include/linux/soc/mediatek/scpsys-ext.h | 39 ++
> 4 files changed, 163 insertions(+), 1 deletion(-)
> create mode 100644 drivers/soc/mediatek/mtk-scpsys-ext.c
> create mode 100644 include/linux/soc/mediatek/scpsys-ext.h
>
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 64ce5eeaba32..b9dbad6b12f9 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -1,4 +1,4 @@
> obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
> -obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
> +obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o mtk-scpsys-ext.o
> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> diff --git a/drivers/soc/mediatek/mtk-scpsys-ext.c
> b/drivers/soc/mediatek/mtk-scpsys-ext.c
> new file mode 100644
> index ..f630edb2f65d
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-scpsys-ext.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Owen Chen
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MTK_POLL_DELAY_US 10
> +#define MTK_POLL_TIMEOUTUSEC_PER_SEC
> +
> +static int set_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
> + u32 reg_set, u32 reg_sta, u32 reg_en)
> +{
> + u32 val;
> +
> + if (reg_set)
> + regmap_write(map, reg_set, mask);
> + else
> + regmap_update_bits(map, reg_en, mask, mask);
> +
> + return regmap_read_poll_timeout(map, reg_sta,
> + val, (val & ack_mask) == ack_mask,
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +static int clear_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
> + u32 reg_clr, u32 reg_sta, u32 reg_en)
> +{
> + u32 val;
> +
> + if (reg_clr)
> + regmap_write(map, reg_clr, mask);
> + else
> + regmap_update_bits(map, reg_en, mask, 0);
> +
> + return regmap_read_poll_timeout(map, reg_sta,
> + val, !(val & ack_mask),
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +int mtk_scpsys_ext_set_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common)
> +{
> + int i;
> +
> + for (i = 0; i < MAX_STEPS && bp_table[i].mask; i++) {
> + struct regmap *map;
> + int ret;
> +
> + if (bp_table[i].type == IFR_TYPE)
> + map = infracfg;
> + else if (bp_table[i].type == SMI_TYPE)
> + map = smi_common;
> + else
> + return -EINVAL;
> +
> + ret = set_bus_protection(map,
> + bp_table[i].mask, bp_table[i].mask,
> + bp_table[i].set_ofs, bp_table[i].sta_ofs,
> + bp_table[i].en_ofs);
> +
> + if (ret)
> + return ret;
Should you undo the rest of the operations and clear bus protection on
the ones that were already enabled?
> + }
> +
> + return 0;
> +}
> +
> +int mtk_scpsys_ext_clear_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common)
> +{
> + int i;
> +
> + for (i = MAX_STEPS - 1; i >= 0; i--) {
So when you set protection, you stop at the first bp_table[i].mask ==
0, but when you clear it, you call clear_bus_protection for those, as
well. You should just skip over the ones when bp_table[i].mask == 0?
e.g.
if (!bp_table[i].mask)
continue;
> + struct regmap *map;
> + int ret;
> +
> + if (bp_table[i].type == IFR_TYPE)
> + map = infracfg;
> + else if (bp_table[i].type == SMI_TYPE)
> + map = smi_common;
> + else
> + return -EINVAL;
> +
> + ret = clear_bus_protection(map,
> + bp_table[i].mask, bp_table[i].clr_ack_mask,
> + bp_table[i].clr_ofs, bp_table[i].sta_ofs,
> + bp_table[i].en_ofs);
> +
> + if (ret)
> + return ret;
Similar question, is it ok to just abort? Or should you try to clear
the protection on all others, too?
Re: [PATCH v4 4/5] soc: qcom: socinfo: Expose custom attributes
On Thu, 14 Mar 2019 at 21:28, Stephen Boyd wrote:
>
> Quoting Vaishali Thakkar (2019-03-14 04:25:16)
> > On Fri, 1 Mar 2019 at 03:02, Stephen Boyd wrote:
> > >
> > > Why can't we use the debugfs_create_u32 function? It would make things
> > > clearer if there was either a debugfs_create_le32() function or if the
> > > socinfo structure stored in smem was unmarshalled from little endian
> > > to the cpu native endian format during probe time and then all the rest
> > > of the code can treat it as a native endian u32 values.
> >
> > Thanks for the review. I've worked on the next version with all the
> > changes you suggested in the patchset but I'm kind of not sure
> > what would be the best solution in this case.
>
> Alright, thanks.
>
> >
> > I'm bit skeptical about introducing debugfs_create_le32 as we don't
> > really have any endian specific functions in the debugfs core at the
> > moment. And if I do that, should I also introduce debugfs_create_be32
> > [and to an extent debugfs_create_le{16,64}]? More importantly, would
> > it be useful to introduce them in core?
>
> I suppose it's ambiguous if the endianness should be swapped to be CPU
> native, or if it should just export them as little endian or big endian
> to userspace. I wouldn't introduce any APIs that aren't used, because
> it's just dead code. If the code is documented clearly and indicates
> what it does then it should be fine. This patch has pretty much already
> written the code, so it's just a matter of moving it into debugfs core
> now and getting gregkh to approve.
>
> >
> > In the case of converting it to cpu native during probe, I'll need to
> > declare an extra struct with u32 being the parsed version for it to be
> > correct. Wouldn't it add extra overhead?
>
> Yes it would be some small extra overhead that could be allocated on the
> kernel's heap. What's the maximum size? A hundred bytes or so?
>
> I don't see much of a problem with this approach. It simplifies the
> patch series because nothing new is introduced in debugfs core and the
> endian conversion is done once in one place instead of being scattered
> throughout the code. Sounds like a good improvement to me.
>
Yes, it's true that this approach is better than introducing new endian
functions in debugfs core but we should also keep in mind that this is
applicable only for 4 use cases. For other usecases, we want to print
string and hex values. So, I would either need new debugfs core
functions for the same. I tried introducing debugfs_create_str for string
values but we're ending up with introducing bunch of other helpers in
the core as simple_attr_read expects integer values. Similarly, for hex
values , I can't use debugfs_create_u32 as defined attributes in the
core has unsigned int as a specifier, will need to introduce some extra
helpers over there again.
Also, in case of keeping all other cases as it is, it'll look quite
asymmetric to use debugfs u32 function in init and using local macros
for other cases. I can have DEBUGFS_UINT_ADD like wrapper
macro for debugfs_create_u32 but again not sure if doing
all of this looks better than what we have at the moment as just having
3 local macros covering our all cases without having lot of duplicated
code.
Let me know if about your opinion on the same. Thanks.
Re: [PATCH V5 1/4] dt-bindings: memory-controllers: freescale: add MMDC binding doc
On Tue, Mar 12, 2019 at 02:24:08AM +, Anson Huang wrote: > Freescale MMDC (Multi Mode DDR Controller) driver is supported > since i.MX6Q, but not yet documented, this patch adds binding > doc for MMDC module driver. > > Signed-off-by: Anson Huang Applied all, thanks.
Re: [PATCH v2] thunderbolt: Fix to check return value of ida_simple_get
On Thu, Mar 21, 2019 at 02:09:41AM +0530, Mukesh Ojha wrote:
>
> On 3/20/2019 9:59 PM, Mika Westerberg wrote:
> > On Wed, Mar 20, 2019 at 11:24:45AM -0500, Aditya Pakki wrote:
> > > In enumerate_services, ida_simple_get on failure can return an error and
> > > leaks memory during device_register failure. The patch ensures that
> > > the dev_set_name is set on non failure cases, and releases memory in
> > > case of failure.
> > >
> > > Signed-off-by: Aditya Pakki
> > >
> > > ---
> > > v1: Missed cleanup of svc in case of allocation failure and
> > > device_register failure.
> > > ---
> > > drivers/thunderbolt/xdomain.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/thunderbolt/xdomain.c b/drivers/thunderbolt/xdomain.c
> > > index e27dd8beb94b..eb08275185bf 100644
> > > --- a/drivers/thunderbolt/xdomain.c
> > > +++ b/drivers/thunderbolt/xdomain.c
> > > @@ -740,6 +740,7 @@ static void enumerate_services(struct tb_xdomain *xd)
> > > struct tb_service *svc;
> > > struct tb_property *p;
> > > struct device *dev;
> > > + int id;
> > > /*
> > >* First remove all services that are not available anymore in
> > > @@ -768,7 +769,12 @@ static void enumerate_services(struct tb_xdomain *xd)
> > > break;
> > > }
> > > - svc->id = ida_simple_get(>service_ids, 0, 0, GFP_KERNEL);
> > > + id = ida_simple_get(>service_ids, 0, 0, GFP_KERNEL);
> > > + if (id < 0) {
> > > + kfree(svc);
> > > + break;
> > > + }
> > > + svc->id = id;
> > > svc->dev.bus = _bus_type;
> > > svc->dev.type = _service_type;
> > > svc->dev.parent = >dev;
> > > @@ -776,6 +782,7 @@ static void enumerate_services(struct tb_xdomain *xd)
> > > if (device_register(>dev)) {
> > > put_device(>dev);
> > > + kfree(svc);
> > You can't do this after device_register() is called. The put_device()
> > above is sufficient.
>
>
> If device_register fails, how would svc gets freed? we need to kfree svc
> here as well.
Please read the comment on top of device_register(). It should explain.
So no kfree here.
Re: [PATCH] mm/isolation: Remove redundant pfn_valid_within() in __first_valid_page()
On 03/21/2019 10:31 AM, Zi Yan wrote:
> On 20 Mar 2019, at 21:13, Anshuman Khandual wrote:
>
>> pfn_valid_within() calls pfn_valid() when CONFIG_HOLES_IN_ZONE making it
>> redundant for both definitions (w/wo CONFIG_MEMORY_HOTPLUG) of the helper
>> pfn_to_online_page() which either calls pfn_valid() or pfn_valid_within().
>> pfn_valid_within() being 1 when !CONFIG_HOLES_IN_ZONE is irrelevant either
>> way. This does not change functionality.
>>
>> Fixes: 2ce13640b3f4 ("mm: __first_valid_page skip over offline pages")
>
> I would not say this patch fixes the commit 2ce13640b3f4 from 2017,
> because the pfn_valid_within() in pfn_to_online_page() was introduced by
> a recent commit b13bc35193d9e last month. :)
Right, will update the tag with this commit.
Re: [PATCH V6 8/8] drm/mediatek: fix the rate of parent for hdmi phy in MT2701
Hi, Wangyan:
On Wed, 2019-03-06 at 18:13 +0800, CK Hu wrote:
> Hi, Wangyan:
>
> On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> > From: chunhui dai
> >
> > We should not change the rate of parent for hdmi phy when
> > doing round_rate for this clock. The parent clock of hdmi
> > phy must be the same as it. We change it when doing set_rate
> > only.
> >
> > Signed-off-by: chunhui dai
> > Signed-off-by: wangyan wang
> > ---
> > drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
> > drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 ---
> > drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 11 +++
> > drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
> > 4 files changed, 25 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > index 370309d684ec..ca8bc1489f37 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > @@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
> > .owner = THIS_MODULE,
> > };
> >
> > -long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> > -unsigned long *parent_rate)
> > -{
> > - struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > -
> > - hdmi_phy->pll_rate = rate;
> > - if (rate <= 7425)
> > - *parent_rate = rate;
> > - else
> > - *parent_rate = rate / 2;
> > -
> > - return rate;
> > -}
> > -
> > u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
> > {
> > return readl(hdmi_phy->regs + offset);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > index 446e2acd1926..c6061ad15ff0 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > @@ -50,9 +50,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy,
> > u32 offset,
> > void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> >u32 val, u32 mask);
> > struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
> > -long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> > -unsigned long *parent_rate);
> > -
> > extern struct platform_driver mtk_hdmi_phy_driver;
> > extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
> > extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > index 88dd9e812ca0..33893a180c2e 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > @@ -152,6 +152,17 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
> > unsigned long rate,
> > RG_HDMITX_DRV_IBIAS_MASK);
> > return 0;
> > }
> > +
> > +static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> > +unsigned long *parent_rate)
> > +{
> > + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > +
> > + hdmi_phy->pll_rate = rate;
>
> I think you don't need to save the rate into pll_rate here, pll_rate
> would be set in set_rate() or recalc_rate().
As offline discuss, you mention that this function just need to return
current rate. I think you could just remove this line
'hdmi_phy->pll_rate = rate;' and return rate only. You don't need to
assign hdmi_phy->pll_rate here because it would be set later in
set_rate().
Regards,
CK
>
> Regards,
> CK
>
> > +
> > + return rate;
> > +}
> > +
> > static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> >unsigned long parent_rate)
> > {
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > index 63dde42521b8..3a339f516613 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > @@ -285,6 +285,20 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
> > unsigned long rate,
> > return 0;
> > }
> >
> > +static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> > +unsigned long *parent_rate)
> > +{
> > + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > +
> > + hdmi_phy->pll_rate = rate;
> > + if (rate <= 7425)
> > + *parent_rate = rate;
> > + else
> > + *parent_rate = rate / 2;
> > +
> > + return rate;
> > +}
> > +
> > static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> >unsigned long parent_rate)
> > {
>
Re: general protection fault in __x86_indirect_thunk_rbx
syzbot has bisected this bug to:
commit dee160df820de41ff2f59a715643680822a0ab06
Author: NeilBrown
Date: Mon Nov 5 01:30:47 2018 +
locks: use properly initialized file_lock when unlocking.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13f39fd720
start commit: dee160df locks: use properly initialized file_lock when un..
git tree: linux-next
final crash:https://syzkaller.appspot.com/x/report.txt?x=100b9fd720
console output: https://syzkaller.appspot.com/x/log.txt?x=17f39fd720
kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437
dashboard link: https://syzkaller.appspot.com/bug?extid=83e12cf81d2c14842146
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15bd944740
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1121d82b40
Reported-by: syzbot+83e12cf81d2c14842...@syzkaller.appspotmail.com
Fixes: dee160df ("locks: use properly initialized file_lock when
unlocking.")
Re: [PATCH v4.4.y] perf bench: Copy kernel files needed to build mem{cpy,set} x86_64 benchmarks
On Wed, Mar 20, 2019 at 03:13:56PM -0600, Daniel Díaz wrote: > From: Arnaldo Carvalho de Melo > > commit 7d7d1bf1d1dabe435ef50efb051724b8664749cb upstream. > > We can't access kernel files directly from tools/, so copy the required > bits, and make sure that we detect when the original files, in the > kernel, gets modified. > > Cc: Adrian Hunter > Cc: David Ahern > Cc: Jiri Olsa > Cc: Namhyung Kim > Cc: Wang Nan > Link: http://lkml.kernel.org/n/tip-z7e76274ch5j4nugv048q...@git.kernel.org > Signed-off-by: Arnaldo Carvalho de Melo > Signed-off-by: Daniel Díaz Now applied, thanks. greg k-h
Re: [PATCH] tty: serial_core: Spelling correction
On 21. 03. 19, 4:59, hariprasadk wrote: > fix warning reported by checkpatch tool > > Signed-off-by: hariprasadk Please use your real name as per Documentation/process/submitting-patches.rst. > --- > drivers/tty/serial/serial_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/serial_core.c > b/drivers/tty/serial/serial_core.c > index 351843f..69f4871 100644 > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -1514,7 +1514,7 @@ static void uart_set_termios(struct tty_struct *tty, > } > > uart_change_speed(tty, state, old_termios); > - /* reload cflag from termios; port driver may have overriden flags */ > + /* reload cflag from termios; port driver may have overridden flags */ > cflag = tty->termios.c_cflag; > > /* Handle transition to B0 status */ > Otherwose looks good to me. thanks, -- js suse labs
Re: [PATCH] mm/isolation: Remove redundant pfn_valid_within() in __first_valid_page()
On 20 Mar 2019, at 21:13, Anshuman Khandual wrote:
pfn_valid_within() calls pfn_valid() when CONFIG_HOLES_IN_ZONE making
it
redundant for both definitions (w/wo CONFIG_MEMORY_HOTPLUG) of the
helper
pfn_to_online_page() which either calls pfn_valid() or
pfn_valid_within().
pfn_valid_within() being 1 when !CONFIG_HOLES_IN_ZONE is irrelevant
either
way. This does not change functionality.
Fixes: 2ce13640b3f4 ("mm: __first_valid_page skip over offline pages")
I would not say this patch fixes the commit 2ce13640b3f4 from 2017,
because the pfn_valid_within() in pfn_to_online_page() was introduced by
a recent commit b13bc35193d9e last month. :)
Signed-off-by: Anshuman Khandual
---
mm/page_isolation.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index ce323e56b34d..d9b02bb13d60 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -150,8 +150,6 @@ __first_valid_page(unsigned long pfn, unsigned
long nr_pages)
for (i = 0; i < nr_pages; i++) {
struct page *page;
- if (!pfn_valid_within(pfn + i))
- continue;
page = pfn_to_online_page(pfn + i);
if (!page)
continue;
This makes sense to me. You can add Reviewed-by: Zi Yan
.
--
Best Regards,
Yan Zi
Re: [PATCH v3] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected
On Thu, Mar 21, 2019 at 12:27 PM Alex G wrote: > > On 3/20/19 4:44 PM, Linus Torvalds wrote: > > On Wed, Mar 20, 2019 at 1:52 PM Bjorn Helgaas wrote: > >> > >> AFAICT, the consensus there was that it would be better to find some > >> sort of platform solution instead of dealing with it in individual > >> drivers. The PCI core isn't really a driver, but I think the same > >> argument applies to it: if we had a better way to recover from readl() > >> errors, that way would work equally well in nvme-pci and the PCI core. > > > > I think that patches with the pattern "if (disconnected) don't do IO" > > are fundamentally broken and we should look for alternatives in all > > cases. > > > > They are fundamentally broken because they are racy: if it's an actual > > sudden disconnect in the middle of IO, there's no guarantee that we'll > > even be notified in time. > > > > They are fundamentally broken because they add new magic special cases > > that very few people will ever test, and the people who do test them > > tend to do so with old irrelevant kernels. > > > > Finally, they are fundamentally broken because they always end up > > being just special cases. One or two special case accesses in a > > driver, or perhaps all accesses of a particular type in just _one_ > > special driver. > > > > Yes, yes, I realize that people want error reporting, and that > > hot-removal can cause various error conditions (perhaps just parity > > errors for the IO, but also perhaps other random errors caused by > > firmware perhaps doing special HW setup). > > > > But the "you get a fatal interrupt, so avoid the IO" kind of model is > > completely broken, and needs to just be fixed differently. See above > > why it's so completely broken. > > > > So if the hw is set up to send some kinf of synchronous interrupt or > > machine check that cannot sanely be handled (perhaps because it will > > just repeat forever), we should try to just disable said thing. > > > > PCIe allows for just polling for errors on the bridges, afaik. It's > > been years since I looked at it, and maybe I'm wrong. And I bet there > > are various "platform-specific value add" registers etc that may need > > tweaking outside of any standard spec for PCIe error reporting. But > > let's do that in a platform driver, to set up the platform to not do > > the silly "I'm just going to die if I see an error" thing. > > > > It's way better to have a model where you poll each bridge once a > > minute (or one an hour) and let people know "guys, your hardware > > reports errors", than make random crappy changes to random drivers > > because the hardware was set up to die on said errors. > > > > And if some MIS person wants the "hardware will die" setting, then > > they can damn well have that, and then it's not out problem, but it > > also means that we don't start changing random drivers for that insane > > setting. It's dead, Jim, and it was the users choice. > > > > Notice how in neither case does it make sense to try to do some "if > > (disconnected) dont_do_io()" model for the drivers. > > I disagree with the idea of doing something you know can cause an error > to propagate. That being said, in this particular case we have come to > rely a little too much on the if (disconnected) model. My main gripe with the if (disconnected) model is that it's only really good for inactive devices. If a device is being used then odds are the driver will do an MMIO before the pci core has had a chance to mark the device as broken so you crash anyway. > You mentioned in the other thread that fixing the GHES driver will pay > much higher dividends. I'm working on reviving a couple of changes to do > just that. Some industry folk were very concerned about the "don't > panic()" approach, and I want to make sure I fairly present their > arguments in the cover letter. > > I'm hoping one day we'll have the ability to use page tables to prevent > the situations that we're trying to fix today in less than ideal ways. > Although there are other places in msi.c that use if (disconnected), I'm > okay with dropping this change -- provided we come up with an equivalent > fix. What's the idea there? Scan the ioremap space for mappings over the device BARs and swap them with a normal memory page? > But even if FFS doesn't crash, do we really want to lose hundreds of > milliseconds to SMM --on all cores-- when all it takes is a couple of > cycles to check a flag? Using pci_dev_is_disconnected() to opportunistically avoid waiting for MMIO timeouts is fair enough IMO, even if it's a bit ugly. It would help your case if you did some measurements to show the improvement and look for other cases it might help. It might also be a good idea to document when it is appropriate to use pci_is_dev_disconnected() so we aren't stuck having the same argument again and again, but that's probably a job for Bjorn though. Oliver
RE: [PATCH] arm64: dts: imx8qxp: fix mbox-cells
Hi Shawn, > -Original Message- > From: Aisheng Dong > Sent: 2019年3月15日 18:24 > To: Peng Fan ; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de; > ker...@pengutronix.de; feste...@gmail.com; dl-linux-imx > ; Anson Huang ; Daniel Baluta > ; devicet...@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org > Cc: van.free...@gmail.com > Subject: RE: [PATCH] arm64: dts: imx8qxp: fix mbox-cells > > > From: Peng Fan > > > > Subject: [PATCH] arm64: dts: imx8qxp: fix mbox-cells > > > > Currently lsio_mu1 is used by Linux Kernel with mbox-cells as 2, but > > actually > > mu0-4 could be used to communicate with SCU. So fix the mbox-cells. > > > > Signed-off-by: Peng Fan > > Reviewed-by: Dong Aisheng Would you pick up this patch? Thanks, Peng. > > Regards > Dong Aisheng > > > --- > > arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi > > b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi > > index 4c3dd95ed488..16766838ac77 100644 > > --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi > > +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi > > @@ -328,7 +328,7 @@ > > compatible = "fsl,imx8qxp-mu", "fsl,imx6sx-mu"; > > reg = <0x5d1b 0x1>; > > interrupts = ; > > - #mbox-cells = <0>; > > + #mbox-cells = <2>; > > status = "disabled"; > > }; > > > > @@ -343,7 +343,7 @@ > > compatible = "fsl,imx8qxp-mu", "fsl,imx6sx-mu"; > > reg = <0x5d1e 0x1>; > > interrupts = ; > > - #mbox-cells = <0>; > > + #mbox-cells = <2>; > > status = "disabled"; > > }; > > > > @@ -351,7 +351,7 @@ > > compatible = "fsl,imx8qxp-mu", "fsl,imx6sx-mu"; > > reg = <0x5d1f 0x1>; > > interrupts = ; > > - #mbox-cells = <0>; > > + #mbox-cells = <2>; > > status = "disabled"; > > }; > > > > -- > > 2.16.4
RE: [PATCH] arm64: dts: imx8qxp: add lsio_mu2 node
Hi Shawn,
> -Original Message-
> From: Aisheng Dong
> Sent: 2019年3月15日 18:24
> To: Peng Fan ; robh...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de;
> ker...@pengutronix.de; feste...@gmail.com; dl-linux-imx
> ; Anson Huang ; Daniel Baluta
> ; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: van.free...@gmail.com
> Subject: RE: [PATCH] arm64: dts: imx8qxp: add lsio_mu2 node
>
> > From: Peng Fan
> >
> > Add lsio_mu2 node which could be used communicate with SCU.
> >
> > Signed-off-by: Peng Fan
>
> Reviewed-by: Dong Aisheng
Would you pick up this patch?
Thanks,
Peng.
>
> Regards
> Dong Aisheng
>
> > ---
> > arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > index 16766838ac77..64eecd6cb1e9 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > @@ -339,6 +339,14 @@
> > #mbox-cells = <2>;
> > };
> >
> > + lsio_mu2: mailbox@5d1d {
> > + compatible = "fsl,imx8qxp-mu", "fsl,imx6sx-mu";
> > + reg = <0x5d1d 0x1>;
> > + interrupts = ;
> > + #mbox-cells = <2>;
> > + status = "disabled";
> > + };
> > +
> > lsio_mu3: mailbox@5d1e {
> > compatible = "fsl,imx8qxp-mu", "fsl,imx6sx-mu";
> > reg = <0x5d1e 0x1>;
> > --
> > 2.16.4
[PATCH] arm64: setup min_low_pfn
When debugging with CONFIG_PAGE_OWNER, I noticed that the min_low_pfn on arm64 is always zero and the page owner scanning has to start from zero. We have to loop a while before we see the first valid pfn. (see: read_page_owner()) Setup min_low_pfn to save some loops. Before setting min_low_pfn: [ 21.265602] min_low_pfn=0, *ppos=0 Page allocated via order 0, mask 0x100cca(GFP_HIGHUSER_MOVABLE) PFN 262144 type Movable Block 512 type Movable Flags 0x8001e referenced|uptodate|dirty|lru|swapbacked) prep_new_page+0x13c/0x140 get_page_from_freelist+0x254/0x1068 __alloc_pages_nodemask+0xd4/0xcb8 After setting min_low_pfn: [ 11.025787] min_low_pfn=262144, *ppos=0 Page allocated via order 0, mask 0x100cca(GFP_HIGHUSER_MOVABLE) PFN 262144 type Movable Block 512 type Movable Flags 0x8001e referenced|uptodate|dirty|lru|swapbacked) prep_new_page+0x13c/0x140 get_page_from_freelist+0x254/0x1068 __alloc_pages_nodemask+0xd4/0xcb8 shmem_alloc_page+0x7c/0xa0 shmem_alloc_and_acct_page+0x124/0x1e8 shmem_getpage_gfp.isra.7+0x118/0x878 shmem_write_begin+0x38/0x68 Signed-off-by: Miles Chen --- arch/arm64/mm/init.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 6bc135042f5e..3dbd0c5ce780 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -440,6 +440,7 @@ void __init bootmem_init(void) early_memtest(min << PAGE_SHIFT, max << PAGE_SHIFT); max_pfn = max_low_pfn = max; + min_low_pfn = min; arm64_numa_init(); /* -- 2.18.0
[PATCH] mm/isolation: Remove redundant pfn_valid_within() in __first_valid_page()
pfn_valid_within() calls pfn_valid() when CONFIG_HOLES_IN_ZONE making it
redundant for both definitions (w/wo CONFIG_MEMORY_HOTPLUG) of the helper
pfn_to_online_page() which either calls pfn_valid() or pfn_valid_within().
pfn_valid_within() being 1 when !CONFIG_HOLES_IN_ZONE is irrelevant either
way. This does not change functionality.
Fixes: 2ce13640b3f4 ("mm: __first_valid_page skip over offline pages")
Signed-off-by: Anshuman Khandual
---
mm/page_isolation.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index ce323e56b34d..d9b02bb13d60 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -150,8 +150,6 @@ __first_valid_page(unsigned long pfn, unsigned long
nr_pages)
for (i = 0; i < nr_pages; i++) {
struct page *page;
- if (!pfn_valid_within(pfn + i))
- continue;
page = pfn_to_online_page(pfn + i);
if (!page)
continue;
--
2.20.1
Re: [PATCH] ELAN touchpad i2c_hid bugs fix
at 01:18, Andy Shevchenko wrote:
On Wed, Mar 20, 2019 at 6:55 PM Kai-Heng Feng
wrote:
at 23:39, Hans de Goede wrote:
On 3/20/19 3:37 PM, Benjamin Tissoires wrote:
Benjamin, what I find interesting here is that the BOGUS_IRQ quirk
is also used on Elan devices, I suspect that these Elan devices
likely also need the I2C_HID_QUIRK_FORCE_TRIGGER_FALLING quirk
and then they probably will no longer need the bogus IRQ flag,
if you know about bugreports with an acpidump for any of the devices
needing the bogus IRQ quirk, then I (or you) can check how the IRQ is
declared there, I suspect it will be declared as level-low, just like
with the laptop this patch was written for. And it probably need to
be edge-falling instead of level-low just like this case.
First, I’ve already tried using IRQF_TRIGGER_FALLING, unfortunately it
doesn’t solve the issue for me.
I talked to Elan once, and they confirm the correct IRQ trigger is level
low. So forcing falling trigger may break other platforms.
As far as I understood Vladislav the quirk he got from Elan as well.
Ok, then this is really weird.
Recently we found that Elan touchpad doesn’t like GpioInt() from its _CRS.
Once the Interrupt() is used instead, the issue goes away.
IIRC i2c core tries to get interrupt from Interrupt() resource and
then falls back to GpioInt().
See i2c_acpi_get_info() and i2c_device_probe().
Here’s its ASL:
Scope (\_SB.PCI0.I2C4)
{
Device (TPD0)
{
Name (_ADR, One) // _ADR: Address
Name (_HID, "DELL08AE") // _HID: Hardware ID
Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */) //
_CID: Compatible ID
Name (_UID, One) // _UID: Unique ID
Name (_S0W, 0x04) // _S0W: S0 Device Wake State
Name (SBFB, ResourceTemplate ()
{
I2cSerialBusV2 (0x002C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C4",
0x00, ResourceConsumer, , Exclusive,
)
})
Name (SBFG, ResourceTemplate ()
{
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullUp, 0x,
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0012
}
})
Name (SBFI, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow,
ExclusiveAndWake, ,, )
{
0x003C,
}
})
Method (_INI, 0, NotSerialized) // _INI: Initialize
{
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
If ((TCPD == One))
{
Return (0x0F)
}
Return (Zero)
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
If ((OSYS < 0x07DC))
{
Return (SBFI) /* \_SB_.PCI0.I2C4.TPD0.SBFI */
}
Return (ConcatenateResTemplate (SBFB, SBFG))
}
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If ((Arg0 == ToUUID ("3cdff6f7-4267-4555-ad05-b30a3d8938de") /*
HID I2C Device */))
{
If ((Arg2 == Zero))
{
If ((Arg1 == One))
{
Return (Buffer (One)
{
0x03
// .
})
}
Else
{
Return (Buffer (One)
{
0x00
// .
})
}
}
ElseIf ((Arg2 == One))
{
Return (0x20)
}
Else
{
Return (Buffer (One)
{
0x00
// .
})
}
}
ElseIf ((Arg0 == ToUUID
("ef87eb82-f951-46da-84ec-14871ac6f84b")))
{
If ((Arg2 == Zero))
{
If ((Arg1 == One))
{
Return (Buffer (One)
{
0x03
// .
})
}
}
[PATCH] mm: page_mkclean vs MADV_DONTNEED race
MADV_DONTNEED is handled with mmap_sem taken in read mode. We call page_mkclean without holding mmap_sem. MADV_DONTNEED implies that pages in the region are unmapped and subsequent access to the pages in that range is handled as a new page fault. This implies that if we don't have parallel access to the region when MADV_DONTNEED is run we expect those range to be unallocated. w.r.t page_mkclean we need to make sure that we don't break the MADV_DONTNEED semantics. MADV_DONTNEED check for pmd_none without holding pmd_lock. This implies we skip the pmd if we temporarily mark pmd none. Avoid doing that while marking the page clean. Keep the sequence same for dax too even though we don't support MADV_DONTNEED for dax mapping Signed-off-by: Aneesh Kumar K.V --- fs/dax.c | 2 +- mm/rmap.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/dax.c b/fs/dax.c index 01bfb2ac34f9..697bc2f59b90 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -814,7 +814,7 @@ static void dax_entry_mkclean(struct address_space *mapping, pgoff_t index, goto unlock_pmd; flush_cache_page(vma, address, pfn); - pmd = pmdp_huge_clear_flush(vma, address, pmdp); + pmd = pmdp_invalidate(vma, address, pmdp); pmd = pmd_wrprotect(pmd); pmd = pmd_mkclean(pmd); set_pmd_at(vma->vm_mm, address, pmdp, pmd); diff --git a/mm/rmap.c b/mm/rmap.c index b30c7c71d1d9..76c8dfd3ae1c 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -928,7 +928,7 @@ static bool page_mkclean_one(struct page *page, struct vm_area_struct *vma, continue; flush_cache_page(vma, address, page_to_pfn(page)); - entry = pmdp_huge_clear_flush(vma, address, pmd); + entry = pmdp_invalidate(vma, address, pmd); entry = pmd_wrprotect(entry); entry = pmd_mkclean(entry); set_pmd_at(vma->vm_mm, address, pmd, entry); -- 2.20.1
[PATCH] tty: serial_core: Spelling correction
fix warning reported by checkpatch tool Signed-off-by: hariprasadk --- drivers/tty/serial/serial_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 351843f..69f4871 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1514,7 +1514,7 @@ static void uart_set_termios(struct tty_struct *tty, } uart_change_speed(tty, state, old_termios); - /* reload cflag from termios; port driver may have overriden flags */ + /* reload cflag from termios; port driver may have overridden flags */ cflag = tty->termios.c_cflag; /* Handle transition to B0 status */ -- 2.7.4
Re: [PATCH v6] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
On Tue, Mar 19, 2019 at 12:04:01AM -0400, Kimberly Brown wrote: There are two methods for signaling the host: the monitor page mechanism and hypercalls. The monitor page mechanism is used by performance critical channels (storage, networking, etc.) because it provides improved throughput. However, latency is increased. Monitor pages are allocated to these channels. Monitor pages are not allocated to channels that do not use the monitor page mechanism. Therefore, these channels do not have a valid monitor id or valid monitor page data. In these cases, some of the "_show" functions return incorrect data. They return an invalid monitor id and data that is beyond the bounds of the hv_monitor_page array fields. The "channel->offermsg.monitor_allocated" value can be used to determine whether monitor pages have been allocated to a channel. Add "is_visible()" callback functions for the device-level and channel-level attribute groups. These functions will hide the monitor sysfs files when the monitor mechanism is not used. Remove ".default_attributes" from "vmbus_chan_attrs" and create a channel-level attribute group. These changes allow the new "is_visible()" callback function to be applied to the channel-level attributes. Call "sysfs_create_group()" in "vmbus_add_channel_kobj()" to create the channel's sysfs files. Add a new function, “vmbus_remove_channel_attr_group()”, and call it in "free_channel()" to remove the channel's sysfs files when the channel is closed. Signed-off-by: Kimberly Brown I've queued it up for hyperv-fixes, thanks Kimberly. Should this go in stable as well? -- Thanks, Sasha
[PATCH trivial] list/hashtable: minor documentation corrections.
hash_for_each_safe() and hash_for_each_possible_safe() need to be passed a temp 'struct hlist_node' pointer, but do not say that in the documentation - they just say a 'struct'. Also the documentation for hlist_for_each_entry_safe() describes @n as "another" hlist_node, but in reality it is the only one. Signed-off-by: NeilBrown --- include/linux/hashtable.h | 4 ++-- include/linux/list.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h index 417d2c4bc60d..78b6ea5fa8ba 100644 --- a/include/linux/hashtable.h +++ b/include/linux/hashtable.h @@ -145,7 +145,7 @@ static inline void hash_del_rcu(struct hlist_node *node) * hash entry * @name: hashtable to iterate * @bkt: integer to use as bucket loop cursor - * @tmp: a used for temporary storage + * @tmp: a hlist_node used for temporary storage * @obj: the type * to use as a loop cursor for each entry * @member: the name of the hlist_node within the struct */ @@ -197,7 +197,7 @@ static inline void hash_del_rcu(struct hlist_node *node) * same bucket safe against removals * @name: hashtable to iterate * @obj: the type * to use as a loop cursor for each entry - * @tmp: a used for temporary storage + * @tmp: a hlist_node used for temporary storage * @member: the name of the hlist_node within the struct * @key: the key of the objects to iterate over */ diff --git a/include/linux/list.h b/include/linux/list.h index 79626b5ab36c..894da1962f89 100644 --- a/include/linux/list.h +++ b/include/linux/list.h @@ -842,7 +842,7 @@ static inline void hlist_move_list(struct hlist_head *old, /** * hlist_for_each_entry_safe - iterate over list of given type safe against removal of list entry * @pos: the type * to use as a loop cursor. - * @n: another hlist_node to use as temporary storage + * @n: a hlist_node to use as temporary storage * @head: the head for your list. * @member:the name of the hlist_node within the struct. */ -- 2.14.0.rc0.dirty signature.asc Description: PGP signature
Re: [PATCH v3 3/3] Drivers: hv: vmbus: Fix race condition with new ring_buffer_info mutex
On Wed, Mar 20, 2019 at 01:06:19PM -0700, Stephen Hemminger wrote: > On Sat, 16 Mar 2019 21:49:28 -0400 > Kimberly Brown wrote: > > > On Thu, Mar 14, 2019 at 03:45:33PM -0700, Stephen Hemminger wrote: > > > On Thu, 14 Mar 2019 13:05:15 -0700 > > > "Kimberly Brown" wrote: > > > > > > > Fix a race condition that can result in a ring buffer pointer being set > > > > to null while a "_show" function is reading the ring buffer's data. This > > > > problem was discussed here: > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org > > > > %2Flkml%2F2018%2F10%2F18%2F779data=02%7C01%7Csthemmin%40microsoft.com > > > > %7C1d7557d667b741bdbb6008d6a8b8620f%7C72f988bf86f141af91ab2d7cd011db47%7C1 > > > > %7C0%7C636881907217609564sdata=1bUbLaxsODANM7lCBR8lxyYajNpufuwUW%2FOl > > > > vtGu2hU%3Dreserved=0 > > > > > > > > To fix the race condition, add a new mutex lock to the > > > > "hv_ring_buffer_info" struct. Add a new function, > > > > "hv_ringbuffer_pre_init()", where a channel's inbound and outbound > > > > ring_buffer_info mutex locks are initialized. > > > > > > > > ... snip ... > > > > > > Adding more locks will solve the problem but it seems like overkill. > > > Why not either use a reference count or an RCU style access for the > > > ring buffer? > > > > I agree that a reference count or RCU could also solve this problem. > > Using mutex locks seemed like the most straightforward solution, but > > I'll certainly switch to a different approach if it's better! > > > > Are you concerned about the extra memory required for the mutex locks, > > read performance, or something else? > > Locks in control path are ok, but my concern is performance of the > data path which puts packets in/out of rings. To keep reasonable performance, > no additional locking should be added in those paths. > > So if data path is using RCU, can/should the control operations also > use it? The data path doesn't use RCU to protect the ring buffers.
Re: [PATCH RESEND] eventfd: prepare id to userspace via fdinfo
Thank you for the comment. On Wed, 20 Mar 2019 12:05:25 -0700, Andrew Morton wrote: > On Wed, 20 Mar 2019 18:29:29 +0900 Masatake YAMATO wrote: > >> Finding endpoints of an IPC channel is one of essential task to >> understand how a user program works. Procfs and netlink socket provide >> enough hints to find endpoints for IPC channels like pipes, unix >> sockets, and pseudo terminals. However, there is no simple way to find >> endpoints for an eventfd file from userland. An inode number doesn't >> hint. Unlike pipe, all eventfd files share the same inode object. >> >> To provide the way to find endpoints of an eventfd file, this patch >> adds "eventfd-id" field to /proc/PID/fdinfo of eventfd as identifier. >> Address for eventfd context is used as id. >> >> A tool like lsof can utilize the information to print endpoints. >> >> ... >> >> --- a/fs/eventfd.c >> +++ b/fs/eventfd.c >> @@ -297,6 +297,7 @@ static void eventfd_show_fdinfo(struct seq_file *m, >> struct file *f) >> seq_printf(m, "eventfd-count: %16llx\n", >> (unsigned long long)ctx->count); >> spin_unlock_irq(>wqh.lock); >> +seq_printf(m, "eventfd-id: %p\n", ctx); >> } >> #endif > > Is it a good idea to use a bare kernel address for this? How does this > interact with printk pointer randomization and hashing? > My understanding is that an address printed with %p for a bare kernel address is stable after ptr_key in vsprintf.c is filled, and ptr_key is filled enough early stage. so, for my usecase, resolving IPC endpoints, printing a bare kernel address with %p may be enough. Am I missing something? For the same purpose, I submitted a ida based patch a year ago. (https://patchwork.kernel.org/patch/10413589/) I quote it here for getting comments: This one doesn't use any bare kernel addresses. I implemented new one (%p version) bacause is is much shorter. Do you think ida based one is better than %p based one? Masatake YAMATO
Re: [PATCH v3 2/2] [WIP] tools/power turbostat: Also read package power on AMD F17h (Zen)
> (I previously wrote that this would be easier to test with the patch > applied, because the package power is reported with the -Dump option, > but I'm not sure that's actually the case - the value might still only > be collected once per package?) Right -- we'd have to move it to a per-core or per-CPU data structure to capture it on a finer granularity than per package. Of course, if you want to see if you get different values on the cpus, you can always dump the raw values from each cpu using rdmsr(1). Unfortunately, I don't have that AMD hardware -- somebody with an interest in it can test it out. thanks, Len Brown, Intel Open Source Technology Center
Re: [PATCH] ARM: dts: imx6ull: Use the correct style for SPDX License Identifier
On Mon, Mar 11, 2019 at 07:57:04PM +0530, Nishad Kamdar wrote: > This patch corrects the SPDX License Identifier style > in imx6ull-pinfunc-snvs.h. > > Changes made by using a script provided by Joe Perches here: > https://lkml.org/lkml/2019/2/7/46 > and making some manual changes. > > Suggested-by: Joe Perches > Signed-off-by: Nishad Kamdar Applied, thanks.
Re: [PATCH] printk: Add caller information to printk() output.
Hi Tetsuo, Thanks for implementing this, it's really helpful. Tetsuo Handa writes: ... > From 91f85d2bd494df2f73c605d8b4747e8cc0a61ae2 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Tue, 18 Dec 2018 05:53:04 +0900 > Subject: [PATCH] printk: Add caller information to printk() output. > > Sometimes we want to print a series of printk() messages to consoles > without being disturbed by concurrent printk() from interrupts and/or > other threads. But we can't enforce printk() callers to use their local > buffers because we need to ask them to make too much changes. Also, even > buffering up to one line inside printk() might cause failing to emit > an important clue under critical situation. > > Therefore, instead of trying to help buffering, let's try to help > reconstructing messages by saving caller information as of calling > log_store() and adding it as "[T$thread_id]" or "[C$processor_id]" > upon printing to consoles. > > Some examples for console output: > > [1.222773][T1] x86: Booting SMP configuration: > [2.779635][T1] pci :00:01.0: PCI bridge to [bus 01] > [5.069193][ T268] Fusion MPT base driver 3.04.20 > [9.316504][C2] random: fast init done > [ 13.413336][ T3355] Initialized host personality > > Some examples for /dev/kmsg output: > > 6,496,1222773,-,caller=T1;x86: Booting SMP configuration: > 6,968,2779635,-,caller=T1;pci :00:01.0: PCI bridge to [bus 01] >SUBSYSTEM=pci >DEVICE=+pci::00:01.0 > 6,1353,5069193,-,caller=T268;Fusion MPT base driver 3.04.20 > 5,1526,9316504,-,caller=C2;random: fast init done > 6,1575,13413336,-,caller=T3355;Initialized host personality > > Note that this patch changes max length of messages which can be printed > by printk() or written to /dev/kmsg interface from 992 bytes to 976 bytes, > based on an assumption that userspace won't try to write messages hitting > that border line to /dev/kmsg interface. Do you have any plans to update dmesg or other userspace tools to show the caller information? cheers
Re: [PATCH v3] arm64: dts: ls1088a: add one more thermal zone node
On Mon, Mar 04, 2019 at 03:50:50PM +0800, Yuantian Tang wrote:
> Ls1088a has 2 thermal sensors, core cluster and SoC platform. Core cluster
> sensor is used to monitor the temperature of core and SoC platform is for
> platform. The current dts only support the first sensor.
> This patch adds the second sensor node to dts to enable it.
>
> Signed-off-by: Yuantian Tang
> ---
> v3:
> - use more descriptive name for each zone
> v2:
> - Add more information about sensors to description
> PS: In order to keep consistency to the first thermal-zone node, there will
> be "WARNING: line over 80 characters" warnings.
>
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 43 +--
> 1 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index 661137f..54f973b 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -129,19 +129,19 @@
> };
>
> thermal-zones {
> - cpu_thermal: cpu-thermal {
> + core_cluster_thermal {
We prefer to use hyphen instead of underscore in node name.
Shawn
> polling-delay-passive = <1000>;
> polling-delay = <5000>;
> thermal-sensors = < 0>;
>
> trips {
> - cpu_alert: cpu-alert {
> + core_cluster_alert: core_cluster-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> type = "passive";
> };
>
> - cpu_crit: cpu-crit {
> + core_cluster_crit: core_cluster-crit {
> temperature = <95000>;
> hysteresis = <2000>;
> type = "critical";
> @@ -150,7 +150,42 @@
>
> cooling-maps {
> map0 {
> - trip = <_alert>;
> + trip = <_cluster_alert>;
> + cooling-device =
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> +
> + platform-thermal {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = < 1>;
> +
> + trips {
> + platform_alert: platform-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + platform_crit: platform-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + map0 {
> + trip = <_alert>;
> cooling-device =
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> --
> 1.7.1
>
RE: [PATCH v2] ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286
Yes, you could use Reviewed-by.
-Original Message-
From: Jian-Hong Pan
Sent: Wednesday, March 20, 2019 1:06 PM
To: Takashi Iwai
Cc: Kailang ; alsa-de...@alsa-project.org; Linux
Upstreaming Team ; Linux Kernel
Subject: Re: [PATCH v2] ALSA: hda/realtek: Enable headset MIC of Acer AIO with
ALC286
Takashi Iwai 於 2019年3月15日 週五 下午7:24寫道：
>
> On Fri, 15 Mar 2019 10:51:09 +0100,
> Jian-Hong Pan wrote:
> >
> > Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
> > record sound from headset MIC. This patch adds the
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > v2: According to Realtek's suggestion, change the COEF 0x4f from 0xd429 to
> > 0x5029. Thanks to Realtek!
>
> It'd be nicer if we get either Acked-by or Reviewed-by tag from
> Realtek. Kailang?
Hi Kailang,
May we have your Acked-by or Reviewed-by tag for this patch?
Signed-off will also be great!
Thank you
Jian-Hong Pan
> thanks,
>
> Takashi
>
> >
> > sound/pci/hda/patch_realtek.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c
> > b/sound/pci/hda/patch_realtek.c index 384719d5c44e..191830d4fa40
> > 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -5687,6 +5687,7 @@ enum {
> > ALC225_FIXUP_DELL_WYSE_AIO_MIC_NO_PRESENCE,
> > ALC225_FIXUP_WYSE_AUTO_MUTE,
> > ALC225_FIXUP_WYSE_DISABLE_MIC_VREF,
> > + ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
> > };
> >
> > static const struct hda_fixup alc269_fixups[] = { @@ -6685,6
> > +6686,16 @@ static const struct hda_fixup alc269_fixups[] = {
> > .chained = true,
> > .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> > },
> > + [ALC286_FIXUP_ACER_AIO_HEADSET_MIC] = {
> > + .type = HDA_FIXUP_VERBS,
> > + .v.verbs = (const struct hda_verb[]) {
> > + { 0x20, AC_VERB_SET_COEF_INDEX, 0x4f },
> > + { 0x20, AC_VERB_SET_PROC_COEF, 0x5029 },
> > + { }
> > + },
> > + .chained = true,
> > + .chain_id = ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE
> > + },
> > };
> >
> > static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -6701,9
> > +6712,9 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> > SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
> > ALC282_FIXUP_ASPIRE_V5_PINS),
> > SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
> > ALC283_FIXUP_CHROME_BOOK),
> > - SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > - SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > - SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > + SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > + SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > + SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > + ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> > ALC255_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
> > SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
> > ALC275_FIXUP_DELL_XPS),
> > --
> > 2.20.1
> >
> >
--Please consider the environment before printing this e-mail.
[PATCH] pinctrl: intel: Implements gpio free function
When we use the gpio to control some peripheral devices,and try to
export the gpio first,then unexport the gpio, we test the signal with
oscilloscope,and find the signal can't meet the requirements,because
after we unexported the gpio,the gpio's register(tx and rx)value can't
be recovered,and this will infruence the device work flow.
We check the gpio's unexport code work flow, then find the gpio's free
hook function has not been implemented, After we add pinmux_ops' free
function to set exported gpio to recover its original value,the problem
is fixed.
Signed-off-by: zhuchangchun
---
drivers/pinctrl/intel/pinctrl-intel.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c
b/drivers/pinctrl/intel/pinctrl-intel.c
index 3b18181..002b9d3 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -480,6 +480,33 @@ static int intel_gpio_set_direction(struct pinctrl_dev
*pctldev,
return 0;
}
+static int intel_gpio_free(struct pinctrl_dev *pctldev, unsigned int pin)
+{
+ struct intel_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+ void __iomem *padcfg0;
+ unsigned long flags;
+ u32 value;
+
+ spin_lock_irqsave(>lock, flags);
+
+ if (!intel_pad_usable(pctrl, pin)) {
+ spin_unlock_irqrestore(>lock, flags);
+ return -EBUSY;
+ }
+ padcfg0 = intel_get_padcfg(pctrl, pin, PADCFG0);
+
+ /* Put the pad into GPIO mode */
+ value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
+ /* enable TX buffer and disable RX (this will be input) */
+ value |= PADCFG0_GPIORXDIS;
+ value &= ~PADCFG0_GPIOTXDIS;
+ writel(value, padcfg0);
+
+ spin_unlock_irqrestore(>lock, flags);
+
+ return 0;
+}
+
static const struct pinmux_ops intel_pinmux_ops = {
.get_functions_count = intel_get_functions_count,
.get_function_name = intel_get_function_name,
@@ -487,6 +514,7 @@ static const struct pinmux_ops intel_pinmux_ops = {
.set_mux = intel_pinmux_set_mux,
.gpio_request_enable = intel_gpio_request_enable,
.gpio_set_direction = intel_gpio_set_direction,
+ .free = intel_gpio_free,
};
static int intel_config_get(struct pinctrl_dev *pctldev, unsigned int pin,
--
2.7.4
[PATCH v2 2/2] perf cs-etm: return errcode in cs_etm__process_auxtrace_info()
From: YueHaibing
'err' is set in err path, but it's not returned to callers.
Don't always return -EINVAL, return err.
Fixes: cd8bfd8c973e ("perf tools: Add processing of coresight metadata")
Signed-off-by: YueHaibing
---
tools/perf/util/cs-etm.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index fd7f1da..2cc773a 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1965,8 +1965,10 @@ int cs_etm__process_auxtrace_info(union perf_event
*event,
session->auxtrace = >auxtrace;
etm->unknown_thread = thread__new(9, 9);
- if (!etm->unknown_thread)
+ if (!etm->unknown_thread) {
+ err = -ENOMEM;
goto err_free_queues;
+ }
/*
* Initialize list node so that at thread__zput() we can avoid
@@ -1978,8 +1980,10 @@ int cs_etm__process_auxtrace_info(union perf_event
*event,
if (err)
goto err_delete_thread;
- if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine)) {
+ err = -ENOMEM;
goto err_delete_thread;
+ }
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
@@ -2023,5 +2027,5 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
err_free_hdr:
zfree();
- return -EINVAL;
+ return err;
}
--
2.7.0
[PATCH v2 1/2] perf cs-etm: Remove errnoeous ERR_PTR() usage in cs_etm__process_auxtrace_info
From: YueHaibing
intlist__findnew() doesn't uses ERR_PTR() as a return mechanism
so its callers shouldn't try to extract the error using PTR_ERR(
ret) from intlist__findnew(), make cs_etm__process_auxtrace_info
return -ENOMEM instead.
Fixes: cd8bfd8c973e ("perf tools: Add processing of coresight metadata")
Signed-off-by: YueHaibing
---
tools/perf/util/cs-etm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 1108049..fd7f1da 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1908,7 +1908,7 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
/* Something went wrong, no need to continue */
if (!inode) {
- err = PTR_ERR(inode);
+ err = -ENOMEM;
goto err_free_metadata;
}
--
2.7.0
[PATCH v2 0/2] minor fixes for perf cs-etm
From: YueHaibing v2: - patch 1 fix commilt log - patch 2 use correct Fixes tag This patch series fixes two issue: 1. fix pass-zero-to-ERR_PTR warning 2. return correct errcode to upstream callers YueHaibing (2): perf cs-etm: Remove errnoeous ERR_PTR() usage in in cs_etm__process_auxtrace_info perf cs-etm: return errcode in cs_etm__process_auxtrace_info() tools/perf/util/cs-etm.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) -- 2.7.0
Re: [PATCH 2/2] mmc: dw_mmc-rockchip: fix transfer hangs on rk3188【请注意，邮件由linux-mmc-ow...@vger.kernel.org代发】
+ Caesar Wang
On 2019/3/21 1:48, Alexander Kochetkov wrote:
I've found that sometimes dw_mmc in my rk3188 based board stop transfer
any data with error:
kernel: dwmmc_rockchip 1021c000.dwmmc: Unexpected command timeout, state 3
Further digging into problem showed that sometimes one of EDMA-based
transfers hangs and abort with HTO error. I've made test, that 100%
I'm not sure what 100% means, but Caesar fired QA test for RK3036 with
EDMA-based dwmmc in vendor 4.4 kernel, and seems not big deal. The
vendor 4.4 kernel didn't patch anything else wrt EDMA code, but we did
enhance PL330 code and fix some bug there, so you may have a try.
reproduce the error. I found, that setting max_segs parameter to 1 fix
the problem.
I guess the problem is hardware related and relates to DMA controller
implementation for rk3188. Probably it can relates to missed FLUSHP,
see commit 271e1b86e691 ("dmaengine: pl330: add quirk for broken no
flushp"). It is possible that pl330 and dw_mmc become out of sync then
pl330 driver switch from one scatterlist to another. If we limit
scatterlist size to 1, we can avoid switching scatterlists and avoid
hardware problem. Setting max_segs to 1 tells mmc core to use maximum
one scatterlist for one transfer.
I guess that all other rk3xxx chips that lacks FLUSHP also affected by
the problem. So I made fix for all rk3xxx chips from rk2928 to rk3188.
Hard to find these acient platforms to test, expecially some was EOL
Signed-off-by: Alexander Kochetkov
---
drivers/mmc/host/dw_mmc-rockchip.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host/dw_mmc-rockchip.c
index 8c86a80..2eed922 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -292,6 +292,24 @@ static int dw_mci_rk3288_parse_dt(struct dw_mci *host)
return 0;
}
+static void dw_mci_rk2928_init_slot(struct dw_mci *host)
+{
+ struct mmc_host *mmc = host->slot->mmc;
+
+ if (host->use_dma == TRANS_MODE_EDMAC) {
+ /*
+* Using max_segs > 1 leads to rare EDMA transfer hangs
+* resulting in HTO errors.
+*/
+ mmc->max_segs = 1;
+ mmc->max_blk_size = 65535;
+ mmc->max_blk_count = 64 * 512;
+ mmc->max_req_size =
+ mmc->max_blk_size * mmc->max_blk_count;
+ mmc->max_seg_size = mmc->max_req_size;
+ }
+}
+
static int dw_mci_rockchip_init(struct dw_mci *host)
{
/* It is slot 8 on Rockchip SoCs */
@@ -314,6 +332,7 @@ static int dw_mci_rockchip_init(struct dw_mci *host)
static const struct dw_mci_drv_data rk2928_drv_data = {
.init = dw_mci_rockchip_init,
+ .init_slot = dw_mci_rk2928_init_slot,
};
static const struct dw_mci_drv_data rk3288_drv_data = {
[PATCH V9 2/4] watchdog: imx_sc: Add i.MX system controller watchdog support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and watchdog etc..
This patch adds i.MX system controller watchdog driver support,
watchdog operation needs to be done in secure EL3 mode via
ARM-Trusted-Firmware, using SMC call, CPU will trap into
ARM-Trusted-Firmware and then it will request system controller
to do watchdog operation via IPC.
Signed-off-by: Anson Huang
Reviewed-by: Guenter Roeck
---
Changes since V8:
- change timeout value to be from DT instead of from module parameter.
---
drivers/watchdog/Kconfig | 16
drivers/watchdog/Makefile | 1 +
drivers/watchdog/imx_sc_wdt.c | 177 ++
3 files changed, 194 insertions(+)
create mode 100644 drivers/watchdog/imx_sc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 242eea8..44a3158 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -641,6 +641,22 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config IMX_SC_WDT
+ tristate "IMX SC Watchdog"
+ depends on HAVE_ARM_SMCCC
+ select WATCHDOG_CORE
+ help
+ This is the driver for the system controller watchdog
+ on the NXP i.MX SoCs with system controller inside, the
+ watchdog driver will call ARM SMC API and trap into
+ ARM-Trusted-Firmware for operations, ARM-Trusted-Firmware
+ will request system controller to execute the operations.
+ If you have one of these processors and wish to have
+ watchdog support enabled, say Y, otherwise say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx_sc_wdt.
+
config UX500_WATCHDOG
tristate "ST-Ericsson Ux500 watchdog"
depends on MFD_DB8500_PRCMU
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index ba930e4..136d9f0 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o
obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
diff --git a/drivers/watchdog/imx_sc_wdt.c b/drivers/watchdog/imx_sc_wdt.c
new file mode 100644
index 000..86c2722
--- /dev/null
+++ b/drivers/watchdog/imx_sc_wdt.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEFAULT_TIMEOUT 60
+/*
+ * Software timer tick implemented in scfw side, support 10ms to 0x ms
+ * in theory, but for normal case, 1s~128s is enough, you can change this max
+ * value in case it's not enough.
+ */
+#define MAX_TIMEOUT 128
+
+#define IMX_SIP_TIMER 0xC202
+#define IMX_SIP_TIMER_START_WDOG 0x01
+#define IMX_SIP_TIMER_STOP_WDOG0x02
+#define IMX_SIP_TIMER_SET_WDOG_ACT 0x03
+#define IMX_SIP_TIMER_PING_WDOG0x04
+#define IMX_SIP_TIMER_SET_TIMEOUT_WDOG 0x05
+#define IMX_SIP_TIMER_GET_WDOG_STAT0x06
+#define IMX_SIP_TIMER_SET_PRETIME_WDOG 0x07
+
+#define SC_TIMER_WDOG_ACTION_PARTITION 0
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, );
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static int imx_sc_wdt_ping(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_PING_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+
+ return 0;
+}
+
+static int imx_sc_wdt_start(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_START_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+ if (res.a0)
+ return -EACCES;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_SET_WDOG_ACT,
+ SC_TIMER_WDOG_ACTION_PARTITION,
+ 0, 0, 0, 0, 0, );
+ return res.a0 ? -EACCES : 0;
+}
+
+static int imx_sc_wdt_stop(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_STOP_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+
+ return res.a0 ? -EACCES : 0;
+}
+
+static int imx_sc_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int timeout)
+{
+ struct arm_smccc_res res;
+
+ wdog->timeout = timeout;
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_SET_TIMEOUT_WDOG,
+ timeout * 1000,
[PATCH V9 3/4] arm64: defconfig: add support for i.MX system controller watchdog
Enable CONFIG_IMX_SC_WDT as module to support i.MX system controller watchdog. Signed-off-by: Anson Huang --- no changes. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index f575401..b4000aa 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -429,6 +429,7 @@ CONFIG_WATCHDOG=y CONFIG_ARM_SP805_WATCHDOG=y CONFIG_S3C2410_WATCHDOG=y CONFIG_IMX2_WDT=y +CONFIG_IMX_SC_WDT=m CONFIG_MESON_GXBB_WATCHDOG=m CONFIG_MESON_WATCHDOG=m CONFIG_RENESAS_WDT=y -- 2.7.4
[PATCH V9 4/4] arm64: dts: imx8qxp: add system controller watchdog support
Add i.MX8QXP system controller watchdog support.
Signed-off-by: Anson Huang
---
Changes since V8:
- add timeout property.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 019abce..ca4541e 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -473,4 +473,9 @@
power-domains = < IMX_SC_R_GPIO_7>;
};
};
+
+ watchdog {
+ compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
+ timeout-sec = <60>;
+ };
};
--
2.7.4
[PATCH V9 0/4] Add i.MX8QXP system controller watchdog
i.MX8QXP is an ARMv8 Cortex-A35 SoC with a Cortex-M4 system controller inside, the system controller manages overall power, clock, secure RTC and watchdog etc., so Linux kernel running on A35 needs to communicate with system controller for watchdog operation, this system controller watchdog will call SMC to trap to EL3 secure world ARM-Trusted-Firmware and then it will request system controller to do the watchdog operation via IPC. Changes since V8: - change the timeout value to be from DT instead of from module parameter, and also update the binding doc and dts to add timeout property. Anson Huang (4): dt-bindings: watchdog: add i.MX system controller watchdog watchdog: imx_sc: Add i.MX system controller watchdog support arm64: defconfig: add support for i.MX system controller watchdog arm64: dts: imx8qxp: add system controller watchdog support .../bindings/watchdog/fsl-imx-sc-wdt.txt | 24 +++ arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 5 + arch/arm64/configs/defconfig | 1 + drivers/watchdog/Kconfig | 16 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/imx_sc_wdt.c | 177 + 6 files changed, 224 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt create mode 100644 drivers/watchdog/imx_sc_wdt.c -- 2.7.4
[PATCH V9 1/4] dt-bindings: watchdog: add i.MX system controller watchdog
Add i.MX system controller watchdog binding doc.
Signed-off-by: Anson Huang
---
Changes since V8:
- add optional property "timeout-sec" according to driver change.
---
.../bindings/watchdog/fsl-imx-sc-wdt.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt
b/Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt
new file mode 100644
index 000..02b87e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt
@@ -0,0 +1,24 @@
+* Freescale i.MX System Controller Watchdog
+
+i.MX system controller watchdog is for i.MX SoCs with system controller inside,
+the watchdog is managed by system controller, users can ONLY communicate with
+system controller from secure mode for watchdog operations, so Linux i.MX
system
+controller watchdog driver will call ARM SMC API and trap into
ARM-Trusted-Firmware
+for watchdog operations, ARM-Trusted-Firmware is running at secure EL3 mode and
+it will request system controller to execute the watchdog operation passed from
+Linux kernel.
+
+Required properties:
+- compatible: Should be :
+ "fsl,imx8qxp-sc-wdt"
+ followed by "fsl,imx-sc-wdt";
+
+Optional properties:
+- timeout-sec : Contains the watchdog timeout in seconds.
+
+Examples:
+
+watchdog {
+ compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
+ timeout-sec = <60>;
+};
--
2.7.4
[PATCH] lz4: fix spelling and copy-paste errors in documentation
Fix a few spelling and grammar errors, and two places where fast/safe in the documentation did not match the function. Signed-off-by: Tom Levy Cc: Andrew Morton --- include/linux/lz4.h | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/include/linux/lz4.h b/include/linux/lz4.h index 394e3d9213b8..b16e15b9587a 100644 --- a/include/linux/lz4.h +++ b/include/linux/lz4.h @@ -278,7 +278,7 @@ int LZ4_decompress_fast(const char *source, char *dest, int originalSize); * @compressedSize: is the precise full size of the compressed block * @maxDecompressedSize: is the size of 'dest' buffer * - * Decompresses data fom 'source' into 'dest'. + * Decompresses data from 'source' into 'dest'. * If the source stream is detected malformed, the function will * stop decoding and return a negative result. * This function is protected against buffer overflow exploits, @@ -522,7 +522,7 @@ int LZ4_setStreamDecode(LZ4_streamDecode_t *LZ4_streamDecode, const char *dictionary, int dictSize); /** - * LZ4_decompress_fast_continue() - Decompress blocks in streaming mode + * LZ4_decompress_safe_continue() - Decompress blocks in streaming mode * @LZ4_streamDecode: the 'LZ4_streamDecode_t' structure * @source: source address of the compressed data * @dest: output buffer address of the uncompressed data @@ -530,7 +530,7 @@ int LZ4_setStreamDecode(LZ4_streamDecode_t *LZ4_streamDecode, * @compressedSize: is the precise full size of the compressed block * @maxDecompressedSize: is the size of 'dest' buffer * - * These decoding function allows decompression of multiple blocks + * This decoding function allows decompression of multiple blocks * in "streaming" mode. * Previously decoded blocks *must* remain available at the memory position * where they were decoded (up to 64 KB) @@ -569,7 +569,7 @@ int LZ4_decompress_safe_continue(LZ4_streamDecode_t *LZ4_streamDecode, * which must be already allocated with 'originalSize' bytes * @originalSize: is the original and therefore uncompressed size * - * These decoding function allows decompression of multiple blocks + * This decoding function allows decompression of multiple blocks * in "streaming" mode. * Previously decoded blocks *must* remain available at the memory position * where they were decoded (up to 64 KB) @@ -610,10 +610,10 @@ int LZ4_decompress_fast_continue(LZ4_streamDecode_t *LZ4_streamDecode, * @dictStart: pointer to the start of the dictionary in memory * @dictSize: size of dictionary * - * These decoding function works the same as + * This decoding function works the same as * a combination of LZ4_setStreamDecode() followed by * LZ4_decompress_safe_continue() - * It is stand-alone, and don'tn eed a LZ4_streamDecode_t structure. + * It is stand-alone, and doesn't need an LZ4_streamDecode_t structure. * * Return: number of bytes decompressed into destination buffer * (necessarily <= maxDecompressedSize) @@ -633,10 +633,10 @@ int LZ4_decompress_safe_usingDict(const char *source, char *dest, * @dictStart: pointer to the start of the dictionary in memory * @dictSize: size of dictionary * - * These decoding function works the same as + * This decoding function works the same as * a combination of LZ4_setStreamDecode() followed by - * LZ4_decompress_safe_continue() - * It is stand-alone, and don'tn eed a LZ4_streamDecode_t structure. + * LZ4_decompress_fast_continue() + * It is stand-alone, and doesn't need an LZ4_streamDecode_t structure. * * Return: number of bytes decompressed into destination buffer * (necessarily <= maxDecompressedSize) -- 2.11.0
linux-next: Tree for Mar 21
Hi all, Changes since 20190320: The amdgpu tree still had its build failure for which I reverted a commit. The scsi tree still had its build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 2187 1820 files changed, 61493 insertions(+), 30479 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 299 trees (counting Linus' and 70 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (54c490164523 Merge tag 'arc-5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc) Merging fixes/master (b352face4ca9 adfs: mark expected switch fall-throughs) Merging kspp-gustavo/for-next/kspp (1f7ae812f87e x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (9e98c678c2d6 Linux 5.1-rc1) Merging arc-current/for-curr (9a18b5a412ba arch: arc: Kconfig: pedantic formatting) Merging arm-current/fixes (d410a8a49e3e ARM: 8849/1: NOMMU: Fix encodings for PMSAv8's PRBAR4/PRLAR4) Merging arm64-fixes/for-next/fixes (e5a5af771861 arm64: remove obsolete selection of MULTI_IRQ_HANDLER) Merging m68k-current/for-linus (28713169d879 m68k: Add -ffreestanding to CFLAGS) Merging powerpc-fixes/fixes (4622a2d43101 powerpc/6xx: fix setup and use of SPRN_SPRG_PGDIR for hash32) Merging sparc/master (7d762d69145a afs: Fix manually set volume location server list) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (cb8075d934ec Merge branch 'ks8851-fixes') Merging bpf/master (f01a7dbe98ae bpf: Try harder when allocating memory for large maps) Merging ipsec/master (bfc01ddff2b0 Revert "net: xfrm: Add '_rcu' tag for rcu protected pointer in netns_xfrm") Merging netfilter/master (b25a31bf0ca0 netfilter: nf_tables: add missing ->release_ops() in error path of newrule()) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (7dfc45e6282a mt76x02: do not enable RTS/CTS by default) Merging mac80211/master (d235c48b40d3 net: dsa: mv88e6xxx: power serdes on/off for 10G interfaces on 6390X) Merging rdma-fixes/for-rc (ec4fe4bcc584 i40iw: Avoid panic when handling the inetdev event) Merging sound-current/for-linus (b5a236c175b0 ALSA: hda - Enforces runtime_resume after S3 and S4 for each codec) Merging sound-asoc-fixes/for-linus (c47255b61129 ASoC: stm32: dfsdm: fix debugfs warnings on entry creation) Merging regmap-fixes/for-linus (9e98c678c2d6 Linux 5.1-rc1) Merging regulator-fixes/for-linus (0bf41b432655 Merge branch 'regulator-5.1' into regulator-linus) Merging spi-fixes/for-linus (2bfce67d9a07 Merge branch 'spi-5.1' into spi-linus) Merging pci-current/for-linus (9e98c678c2d6 Linux 5.1-rc1) Merging driver-core.current/driver-core-linus (cd1b772d4881 driver core: remove BUS_ATTR()) Merging tty.current/tty-linus (93bcefd4c6ba serial: sh-sci: Fix setting SCSCR_TIE while transferring data) Merging usb.current/usb-linus (22feda47b574 usb: usb251xb: Remove unnecessary comparison of unsigned integer with >= 0) Merging usb-gadget-fixes/fixes (a53469a68eb8 usb: phy: am335x: fix race condition in _probe) Merging usb-serial-fixes/usb-linus (2908b076f519 USB: serial: mos7720: fix mos_parport refcount imbalance on error path) Merging
Re: [PATCH] drivers/acpi: Clear status of an event before enabling it
On Wed, Mar 20, 2019 at 5:11 PM Rafael J. Wysocki wrote:
>
> On Wed, Mar 20, 2019 at 11:34 PM Furquan Shaikh wrote:
> >
> > Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> > clearing ACPI IRQs during suspend/resume") was added to stop clearing
> > of event status bits unconditionally on suspend and resume paths. This
> > was done because of an issue
> > reported (https://bugzilla.kernel.org/show_bug.cgi?id=196249) where
> > lid status stays closed even on resume (which happens because event
> > status bits are cleared unconditionally on resume). Though this change
> > fixed the issue on suspend path, it introduced regressions on several
> > resume paths.
> >
> > First regression was reported and fixed on S5 path by the following
> > change: commit fa85015c0d95 ("ACPICA: Clear status of all events when
> > entering S5"). Next regression was reported and fixed on all legacy
> > sleep paths by the commit f317c7dc12b7 ("ACPICA: Clear status of all
> > events when entering sleep states"). However, regression still exists
> > on S0ix sleep path since it does not follow the legacy sleep path.
>
> What exactly is failing?
Here is the failure scenario:
1. Consider the case of trackpad which acts as a wake source.
2. Since the pad is configured for SCI, GPE_STS gets set for that pad
during normal interrupts as well (i.e. during probe at boot or when
using the trackpad)
3. Now, when the platform decides to enter S0ix, it enables the wake
on trackpad by enabling appropriate GPE_EN bit.
4. So, at this point, we are in a situation where GPE_EN as well as
GPE_STS are set.
5. Now, if the platform enters S0ix, having GPE_STS set will result in
unwanted wakes because of stale events.
This is similar to what was fixed on the legacy sleep path:
https://lkml.org/lkml/2018/8/12/42. However, as S0ix does not follow
the legacy sleep path, clearing of GPE status does not happen. Thus,
it is causing failures to go into S0ix on our platforms because of the
stale wake events as described above.
>
> > In case of S0ix, events are enabled as part of device suspend path. If
> > status bits for the events are set when they are enabled, it could
> > result in premature wake from S0ix. This change ensures that status is
> > cleared for any event that is being enabled so that any stale events
> > are cleared out.
> >
> > Signed-off-by: Furquan Shaikh
> > ---
> > drivers/acpi/acpica/evgpe.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
> > index 62d3aa74277b4..61455ab42fc87 100644
> > --- a/drivers/acpi/acpica/evgpe.c
> > +++ b/drivers/acpi/acpica/evgpe.c
> > @@ -81,8 +81,12 @@ acpi_status acpi_ev_enable_gpe(struct
> > acpi_gpe_event_info *gpe_event_info)
> >
> > ACPI_FUNCTION_TRACE(ev_enable_gpe);
> >
> > - /* Enable the requested GPE */
> > + /* Clear the GPE (of stale events) */
> > + status = acpi_hw_clear_gpe(gpe_event_info);
> > + if (ACPI_FAILURE(status))
> > + return_ACPI_STATUS(status);
>
> Well, this may cause events to be missed.
Won't those be stale events? i.e. any event that has occurred before
GPE is enabled should be ignored.
>
> >
> > + /* Enable the requested GPE */
> > status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_ENABLE);
> > return_ACPI_STATUS(status);
> > }
> > --
> > 2.21.0.225.g810b269d1ac-goog
> >
[RFC][PATCH] tracing/x86: Save CR2 before tracing irqsoff on error_entry
From: Steven Rostedt (VMware)
He Zhe reported a crash by enabling trace events and selecting
"userstacktrace" which will read the stack of userspace for every trace
event recorded. Zhe narrowed it down to:
c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and unify their
usage")
With the problem config, I was able to also reproduce the error. I
narrowed it down to just having to do the following:
# cd /sys/kernel/tracing
# echo 1 > options/userstacktrace
# echo 1 > events/preemptirq/irq_disable/enable
And sure enough, I triggered a crash. Well, it was systemd crashing
with a bad memory access??
systemd-journal[537]: segfault at ed8cb8 ip 7f7fffc9fef5 sp
7ffc4062cb10 error 7
And it would crash similarly each time I tried it, but always at a
different place. After spending the day on this, I finally figured it
out. The bug is happening in entry_64.S right after error_entry.
There's two TRACE_IRQS_OFF in that code path, which if I comment out,
the bug goes away. Then it dawned on me that the crash always happens
when systemd does a normal page fault. We had this bug before, and it
was with the exception trace points.
The issue is that a tracepoint can fault (reading vmalloc or whatever).
And doing a userspace stack trace most definitely will fault. But if we
are coming from a legitimate page fault, the address of that fault (in
the CR2 register) will be lost if we fault before we get to the page
fault handler. That's exactly what is happening.
To solve this, a TRACE_IRQS_OFF_CR2 (and ON for consistency) was added
that saves the CR2 register. A new trace_hardirqs_off_thunk_cr2 is
created that stores the cr2 register, calls the
trace_hardirqs_off_caller, then on return restores the cr2 register if
it changed, before returning.
On my tests this fixes the issue. I just want to know if this is a
legitimate fix or if someone can come up with a better fix?
Note: this also saves the exception context just like the
do_page_fault() function does.
Note2: This only gets enabled when lockdep or irq tracing is enabled,
which is not recommended for production environments.
Link:
http://lkml.kernel.org/r/897cf5cf-fc24-8a64-cb28-847f2d2e6...@windriver.com
Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and unify
their usage")
Signed-off-by: Steven Rostedt (VMware)
---
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 7bc105f47d21..7edffec328e2 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -292,6 +292,32 @@ __visible void do_syscall_64(unsigned long nr, struct
pt_regs *regs)
syscall_return_slowpath(regs);
}
+
+extern void trace_hardirqs_on_caller(unsigned long caller_addr);
+__visible void trace_hardirqs_on_caller_cr2(unsigned long caller_addr)
+{
+ unsigned long address = read_cr2(); /* Get the faulting address */
+ enum ctx_state prev_state;
+
+ prev_state = exception_enter();
+ trace_hardirqs_on_caller(caller_addr);
+ if (address != read_cr2())
+ write_cr2(address);
+ exception_exit(prev_state);
+}
+
+extern void trace_hardirqs_off_caller(unsigned long caller_addr);
+__visible void trace_hardirqs_off_caller_cr2(unsigned long caller_addr)
+{
+ unsigned long address = read_cr2(); /* Get the faulting address */
+ enum ctx_state prev_state;
+
+ prev_state = exception_enter();
+ trace_hardirqs_off_caller(caller_addr);
+ if (address != read_cr2())
+ write_cr2(address);
+ exception_exit(prev_state);
+}
#endif
#if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 1f0efdb7b629..73ddf24fed3e 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1248,12 +1248,12 @@ ENTRY(error_entry)
* we fix gsbase, and we should do it before enter_from_user_mode
* (which can take locks).
*/
- TRACE_IRQS_OFF
+ TRACE_IRQS_OFF_CR2
CALL_enter_from_user_mode
ret
.Lerror_entry_done:
- TRACE_IRQS_OFF
+ TRACE_IRQS_OFF_CR2
ret
/*
diff --git a/arch/x86/entry/thunk_64.S b/arch/x86/entry/thunk_64.S
index be36bf4e0957..1300b53b98cb 100644
--- a/arch/x86/entry/thunk_64.S
+++ b/arch/x86/entry/thunk_64.S
@@ -41,6 +41,8 @@
#ifdef CONFIG_TRACE_IRQFLAGS
THUNK trace_hardirqs_on_thunk,trace_hardirqs_on_caller,1
THUNK trace_hardirqs_off_thunk,trace_hardirqs_off_caller,1
+ THUNK trace_hardirqs_on_thunk_cr2,trace_hardirqs_on_caller_cr2,1
+ THUNK trace_hardirqs_off_thunk_cr2,trace_hardirqs_off_caller_cr2,1
#endif
#ifdef CONFIG_DEBUG_LOCK_ALLOC
diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 058e40fed167..dd511742ca2e 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -172,9 +172,13 @@ static inline int arch_irqs_disabled(void)
#ifdef CONFIG_TRACE_IRQFLAGS
# define
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On Wed, 13 Mar 2019 14:13:31 -0700 Nick Desaulniers
wrote:
> A recent optimization in Clang (r355672) lowers comparisons of the
> return value of memcmp against zero to comparisons of the return value
> of bcmp against zero. This helps some platforms that implement bcmp
> more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but
> an optimized implementation is in the works.
>
> This results in linkage failures for all targets with Clang due to the
> undefined symbol. For now, just implement bcmp as a tailcail to memcmp
> to unbreak the build. This routine can be further optimized in the
> future.
>
> Other ideas discussed:
> * A weak alias was discussed, but breaks for architectures that define
> their own implementations of memcmp since aliases to declarations are
> not permitted (only definitions). Arch-specific memcmp implementations
> typically declare memcmp in C headers, but implement them in assembly.
> * -ffreestanding also is used sporadically throughout the kernel.
> * -fno-builtin-bcmp doesn't work when doing LTO.
I guess we should backport this into -stable so that older kernels can
be built with newer Clang.
> ...
>
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -866,6 +866,26 @@ __visible int memcmp(const void *cs, const void *ct,
> size_t count)
> EXPORT_SYMBOL(memcmp);
> #endif
>
> +#ifndef __HAVE_ARCH_BCMP
> +/**
> + * bcmp - returns 0 if and only if the buffers have identical contents.
> + * @a: pointer to first buffer.
> + * @b: pointer to second buffer.
> + * @len: size of buffers.
> + *
> + * The sign or magnitude of a non-zero return value has no particular
> + * meaning, and architectures may implement their own more efficient bcmp().
> So
> + * while this particular implementation is a simple (tail) call to memcmp, do
> + * not rely on anything but whether the return value is zero or non-zero.
> + */
> +#undef bcmp
What is the undef for?
> +int bcmp(const void *a, const void *b, size_t len)
> +{
> + return memcmp(a, b, len);
> +}
> +EXPORT_SYMBOL(bcmp);
> +#endif
> +
> #ifndef __HAVE_ARCH_MEMSCAN
> /**
> * memscan - Find a character in an area of memory.
> --
> 2.21.0.360.g471c308f928-goog
Re:
-- I need your quick reply for a business transaction of $7Million USD, it is a genuine transaction and 100 percent risk free. You will have 40 percent share of the fund. please reply back to me urgently for the full details if you are capable.
Re: [PATCH 050/114] net: Kconfig: pedantic formatting
On Mon, Mar 11, 2019 at 10:26 PM Enrico Weigelt, metux IT consult wrote: > > Formatting of Kconfig files doesn't look so pretty, so let the > Great White Handkerchief come around and clean it up. > > Signed-off-by: Enrico Weigelt, metux IT consult > --- > net/Kconfig | 14 +-- > net/batman-adv/Kconfig | 10 +- > net/bluetooth/Kconfig | 2 +- > net/ife/Kconfig | 2 +- > net/ipv4/Kconfig| 231 > ++-- > net/ipv4/netfilter/Kconfig | 4 +- > net/ipv6/netfilter/Kconfig | 26 ++--- > net/mpls/Kconfig| 10 +- > net/netfilter/Kconfig | 10 +- > net/netfilter/ipset/Kconfig | 2 +- > net/netfilter/ipvs/Kconfig | 68 ++--- > net/nfc/hci/Kconfig | 14 +-- > net/rds/Kconfig | 4 +- > net/sched/Kconfig | 130 - > net/wireless/Kconfig| 38 > net/xfrm/Kconfig| 10 +- > 16 files changed, 287 insertions(+), 288 deletions(-) > > > config TCP_CONG_NV > - tristate "TCP NV" > - default n > - ---help--- > - TCP NV is a follow up to TCP Vegas. It has been modified to deal with > - 10G networks, measurement noise introduced by LRO, GRO and interrupt > - coalescence. In addition, it will decrease its cwnd multiplicatively > - instead of linearly. > + tristate "TCP NV" > + default n > + ---help--- You are touching this line, so i want you to replace it to 'help' to fix checkpatch.pl warning. WARNING: prefer 'help' over '---help---' for new help texts #560: FILE: net/ipv4/Kconfig:560: +config TCP_CONG_NV > + TCP NV is a follow up to TCP Vegas. It has been modified to deal > with > + 10G networks, measurement noise introduced by LRO, GRO and interrupt > + coalescence. In addition, it will decrease its cwnd multiplicatively > + instead of linearly. > > - Note that in general congestion avoidance (cwnd decreased when # > packets > - queued grows) cannot coexist with congestion control (cwnd decreased > only > - when there is packet loss) due to fairness issues. One scenario when > they > - can coexist safely is when the CA flows have RTTs << CC flows RTTs. > + Note that in general congestion avoidance (cwnd decreased when # > packets > + queued grows) cannot coexist with congestion control (cwnd > decreased only > + when there is packet loss) due to fairness issues. One scenario > when they > + can coexist safely is when the CA flows have RTTs << CC flows RTTs. > > - For further details see http://www.brakmo.org/networking/tcp-nv/ > + For further details see http://www.brakmo.org/networking/tcp-nv/ > -- Best Regards Masahiro Yamada
Re: virtio-blk: should num_vqs be limited by num_possible_cpus()?
On 3/20/19 8:53 PM, Jason Wang wrote:
>
> On 2019/3/19 上午10:22, Dongli Zhang wrote:
>> Hi Jason,
>>
>> On 3/18/19 3:47 PM, Jason Wang wrote:
>>> On 2019/3/15 下午8:41, Cornelia Huck wrote:
On Fri, 15 Mar 2019 12:50:11 +0800
Jason Wang wrote:
> Or something like I proposed several years ago?
> https://do-db2.lkml.org/lkml/2014/12/25/169
>
> Btw, for virtio-net, I think we actually want to go for having a maximum
> number of supported queues like what hardware did. This would be useful
> for e.g cpu hotplug or XDP (requires per cpu TX queue). But the current
> vector allocation doesn't support this which will results all virtqueues
> to share a single vector. We may indeed need more flexible policy here.
I think it should be possible for the driver to give the transport
hints how to set up their queues/interrupt structures. (The driver
probably knows best about its requirements.) Perhaps whether a queue is
high or low frequency, or whether it should be low latency, or even
whether two queues could share a notification mechanism without
drawbacks. It's up to the transport to make use of that information, if
possible.
>>>
>>> Exactly and it was what the above series tried to do by providing hints of
>>> e.g
>>> which queues want to share a notification.
>>>
>> I read about your patch set on providing more flexibility of queue-to-vector
>> mapping.
>>
>> One use case of the patch set is we would be able to enable more queues when
>> there is limited number of vectors.
>>
>> Another use case we may classify queues as hight priority or low priority as
>> mentioned by Cornelia.
>>
>> For virtio-blk, we may extend virtio-blk based on this patch set to enable
>> something similar to write_queues/poll_queues in nvme, when (set->nr_maps !=
>> 1).
>>
>>
>> Yet, the question I am asking in this email thread is for a difference
>> scenario.
>>
>> The issue is not we are not having enough vectors (although this is why only
>> 1
>> vector is allocated for all virtio-blk queues). As so far virtio-blk has
>> (set->nr_maps == 1), block layer would limit the number of hw queues by
>> nr_cpu_ids, we indeed do not need more than nr_cpu_ids hw queues in
>> virtio-blk.
>>
>> That's why I ask why not change the flow as below options when the number of
>> supported hw queues is more than nr_cpu_ids (and set->nr_maps == 1.
>> virtio-blk
>> does not set nr_maps and block layer would set it to 1 when the driver does
>> not
>> specify with a value):
>>
>> option 1:
>> As what nvme and xen-netfront do, limit the hw queue number by nr_cpu_ids.
>
>
> How do they limit the hw queue number? A command?
The max #queue is also limited by other factors, e.g., kernel param
configuration, xen dom0 configuration or nvme hardware support.
Here we would ignore those factors for simplicity and only talk about the
relation between #queue and #cpu.
About nvme pci:
Regardless about new write_queues and poll_queues, the default queue type number
is limited by num_possible_cpus() as line 2120 and 252.
2113 static int nvme_setup_io_queues(struct nvme_dev *dev)
2114 {
2115 struct nvme_queue *adminq = >queues[0];
2116 struct pci_dev *pdev = to_pci_dev(dev->dev);
2117 int result, nr_io_queues;
2118 unsigned long size;
2119
2120 nr_io_queues = max_io_queues();
2121 result = nvme_set_queue_count(>ctrl, _io_queues);
250 static unsigned int max_io_queues(void)
251 {
252 return num_possible_cpus() + write_queues + poll_queues;
253 }
The cons of this is there might be many unused hw queues and vectors when
num_possible_cpus() is very very large while only a small number of cpu are
online. I am looking if there is way to improve this.
About xen-blkfront:
Indeed the max #queue is limited by num_online_cpus() when xen-blkfront module
is loaded as line 2733 and 2736.
2707 static int __init xlblk_init(void)
... ...
2710 int nr_cpus = num_online_cpus();
... ...
2733 if (xen_blkif_max_queues > nr_cpus) {
2734 pr_info("Invalid max_queues (%d), will use default max:
%d.\n",
2735 xen_blkif_max_queues, nr_cpus);
2736 xen_blkif_max_queues = nr_cpus;
2737 }
The cons of this is the number of hw-queue/hctx is limited and cannot increase
after cpu hotplug. I am looking if there is way to improve this.
While both have cons for cpu hotplug, they are trying to make #vector
proportional to the number of cpu.
For xen-blkfront and virtio-blk, as (set=nr_maps == 1), the number of hw queue
is limited by nr_cpu_ids again at block layer.
As virtio-blk is a PCI device, can we use the solution in nvme, that is, to use
num_possible_cpus to limited the max queues in virtio-blk?
Thank you very much!
Dongli Zhang
>
>
>>
>> option 2:
>> If the vectors is not enough, use the max number vector (indeed nr_cpu_ids)
>> as
>> number of hw queues.
Re: [PATCH v2 2/3] coresight: funnel: Support static funnel
Hi Suzuki,
On Wed, Mar 20, 2019 at 01:52:58PM +, Suzuki K Poulose wrote:
>
>
> On 20/03/2019 12:38, Wanglai Shi wrote:
> > From: Leo Yan
> >
> > Since CoreSight hardware topology can use a 'hidden' funnel in the
> > trace data path, this kind funnel doesn't have register for accessing
> > and is used by default from hardware design perspective. Below is an
> > example for related hardware topology:
> >
> >+--+ +--+
> >| cpu0 |->| ETM |-\
> >+--+ +--+ \-> ++ +-+
> > .. | Funnel |->| ETF |-\Hidden funnel
> >+--+ +--+ /-> ++ +-+ \|
> >| cpu3 |->| ETM |-/ \ V
> >+--+ +--+ \-> ++
> > | Funnel |-> ...
> >+--+ +--+ /-> ++
> >| cpu4 |->| ETM |-\ /
> >+--+ +--+ \-> ++ +-+ /
> > .. | Funnel |->| ETF |-/
> >+--+ +--+ /-> ++ +-+
> >| cpu7 |->| ETM |-/
> >+--+ +--+
> >
> > The CoreSight funnel driver only supports dynamic funnel with
> > registration register resource, thus it cannot support for the static
> > funnel case and it's impossible to create trace data path for this case.
> >
> > This patch is to extend CoreSight funnel driver to support both for
> > static funnel and dynamic funnel. For the dynamic funnel it reuses the
> > code existed in the driver, for static funnel the driver will support
> > device probe if without providing register resource and the driver skips
> > registers accessing when detect the register base is NULL.
> >
> > Signed-off-by: Leo Yan
> > ---
>
> Suggested-by: Suzuki K Poulose
Will add the tag in next version, and very appreciate you shared me
offline the replicator code for reference!
> > -static const struct amba_id funnel_ids[] = {
> > +static int static_funnel_probe(struct platform_device *pdev)
> > +{
> > + int ret;
> > +
> > + pm_runtime_get_noresume(>dev);
> > + pm_runtime_set_active(>dev);
> > + pm_runtime_enable(>dev);
> > +
> > + /* Static funnel do not have programming base */
> > + ret = funnel_probe(>dev, NULL);
> > +
> > + if (ret) {
> > + pm_runtime_put_noidle(>dev);
> > + pm_runtime_disable(>dev);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static const struct of_device_id static_funnel_match[] = {
> > + {.compatible = "arm,coresight-funnel"},
>
> There is a potential issue with re-using the "compatible" string
> already reserved for the normal programmable funnel. We may handle
> a programmable funnel as non-programmable one, which is not good.
>
> Do we need to use "arm,coresight-static-funnel" ?
This suggestion makes sense, will do this.
> Otherwise, looks good to me.
Thanks for reviewing.
Thanks,
Leo Yan
Re: [PATCH 0/2] minor fixes for perf cs-etm
On 2019/3/21 0:16, Mathieu Poirier wrote: > On Wed, 20 Mar 2019 at 00:37, Yue Haibing wrote: >> >> From: YueHaibing >> >> This patch series fixes two issue: >> 1. fix pass-zero-to-ERR_PTR warning >> 2. return correct errcode to upstream callers >> >> YueHaibing (2): >> perf cs-etm: Remove errnoeous ERR_PTR() usage in in >> cs_etm__process_auxtrace_info >> perf cs-etm: return errcode in cs_etm__process_auxtrace_info() >> >> tools/perf/util/cs-etm.c | 12 >> 1 file changed, 8 insertions(+), 4 deletions(-) > > Please run your work through checkpatch and resend. > Sorry, I will check and resend v2. > Mathieu > >> >> -- >> 2.7.0 >> >> > > . >
[PATCH] perf: Change PMCR write to read-modify-write
Preserves the bitfields of PMCR_EL0(AArch64) during PMU reset. Reset routine should write a 1 to PMCR.C and PMCR.P fields only to reset the counters. Other fields should not be changed as they could be set before PMU initialization and their value must be preserved even after reset. Signed-off-by: Prasad Sodagudi --- arch/arm64/kernel/perf_event.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c index 4addb38..0c1afdd 100644 --- a/arch/arm64/kernel/perf_event.c +++ b/arch/arm64/kernel/perf_event.c @@ -868,8 +868,8 @@ static void armv8pmu_reset(void *info) * Initialize & Reset PMNC. Request overflow interrupt for * 64 bit cycle counter but cheat in armv8pmu_write_counter(). */ - armv8pmu_pmcr_write(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C | - ARMV8_PMU_PMCR_LC); + armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_P | + ARMV8_PMU_PMCR_C | ARMV8_PMU_PMCR_LC); } static int __armv8_pmuv3_map_event(struct perf_event *event, -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project
[PATCH v2 -next] ASoC: wm_adsp: Make some variables static
From: YueHaibing
Fix sparse warnings:
sound/soc/codecs/wm_adsp.c:309:20: warning: symbol 'wm_adsp1_ops' was not
declared. Should it be static?
sound/soc/codecs/wm_adsp.c:310:20: warning: symbol 'wm_adsp2_ops' was not
declared. Should it be static?
sound/soc/codecs/wm_adsp.c:311:20: warning: symbol 'wm_halo_ops' was not
declared. Should it be static?
Signed-off-by: YueHaibing
---
v2: make variables static
---
sound/soc/codecs/wm_adsp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
index 644aaf1..c41bffc 100644
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -306,9 +306,9 @@
#define HALO_MPU_VIO_ERR_SRC_MASK 0x7fff
#define HALO_MPU_VIO_ERR_SRC_SHIFT 0
-struct wm_adsp_ops wm_adsp1_ops;
-struct wm_adsp_ops wm_adsp2_ops[];
-struct wm_adsp_ops wm_halo_ops;
+static struct wm_adsp_ops wm_adsp1_ops;
+static struct wm_adsp_ops wm_adsp2_ops[];
+static struct wm_adsp_ops wm_halo_ops;
struct wm_adsp_buf {
struct list_head list;
@@ -4407,13 +4407,13 @@ irqreturn_t wm_halo_wdt_expire(int irq, void *data)
}
EXPORT_SYMBOL_GPL(wm_halo_wdt_expire);
-struct wm_adsp_ops wm_adsp1_ops = {
+static struct wm_adsp_ops wm_adsp1_ops = {
.validate_version = wm_adsp_validate_version,
.parse_sizes = wm_adsp1_parse_sizes,
.region_to_reg = wm_adsp_region_to_reg,
};
-struct wm_adsp_ops wm_adsp2_ops[] = {
+static struct wm_adsp_ops wm_adsp2_ops[] = {
{
.sys_config_size = sizeof(struct wm_adsp_system_config_xm_hdr),
.parse_sizes = wm_adsp2_parse_sizes,
@@ -4474,7 +4474,7 @@ struct wm_adsp_ops wm_adsp2_ops[] = {
},
};
-struct wm_adsp_ops wm_halo_ops = {
+static struct wm_adsp_ops wm_halo_ops = {
.sys_config_size = sizeof(struct wm_halo_system_config_xm_hdr),
.parse_sizes = wm_adsp2_parse_sizes,
.validate_version = wm_halo_validate_version,
--
2.7.0
Re: [PATCH 079/114] drivers: char: Kconfig: pedantic formatting
On Mon, Mar 11, 2019 at 10:23 PM Enrico Weigelt, metux IT consult wrote: > > Formatting of Kconfig files doesn't look so pretty, so let the > Great White Handkerchief come around and clean it up. > > Signed-off-by: Enrico Weigelt, metux IT consult > --- > drivers/char/Kconfig | 24 +- While you are touching this file, why don't you fix checkpatch.pl warnings? WARNING: prefer 'help' over '---help---' for new help texts #54: FILE: drivers/char/Kconfig:54: +config TTY_PRINTK WARNING: prefer 'help' over '---help---' for new help texts #77: FILE: drivers/char/Kconfig:77: +config PRINTER WARNING: prefer 'help' over '---help---' for new help texts #120: FILE: drivers/char/Kconfig:120: +config PPDEV WARNING: prefer 'help' over '---help---' for new help texts #245: FILE: drivers/char/Kconfig:245: +config NVRAM WARNING: prefer 'help' over '---help---' for new help texts #274: FILE: drivers/char/Kconfig:274: +config RTC WARNING: prefer 'help' over '---help---' for new help texts #300: FILE: drivers/char/Kconfig:300: +config JS_RTC > drivers/char/agp/Kconfig | 13 +++--- > drivers/char/hw_random/Kconfig | 24 +- > drivers/char/ipmi/Kconfig | 99 > +- > 4 files changed, 80 insertions(+), 80 deletions(-) > > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig > index 72866a0..ab33583 100644 > --- a/drivers/char/Kconfig > +++ b/drivers/char/Kconfig > @@ -35,18 +35,18 @@ config SGI_SNSC > say Y. Otherwise, say N. > > config SGI_TIOCX > - bool "SGI TIO CX driver support" > - depends on (IA64_SGI_SN2 || IA64_GENERIC) > - help > - If you have an SGI Altix and you have fpga devices attached > - to your TIO, say Y here, otherwise say N. > + bool "SGI TIO CX driver support" > + depends on (IA64_SGI_SN2 || IA64_GENERIC) > + help > + If you have an SGI Altix and you have fpga devices attached > + to your TIO, say Y here, otherwise say N. > > config SGI_MBCS > - tristate "SGI FPGA Core Services driver support" > - depends on SGI_TIOCX > - help > - If you have an SGI Altix with an attached SABrick > - say Y or M here, otherwise say N. > + tristate "SGI FPGA Core Services driver support" > + depends on SGI_TIOCX > + help > + If you have an SGI Altix with an attached SABrick > + say Y or M here, otherwise say N. > > source "drivers/tty/serial/Kconfig" > source "drivers/tty/serdev/Kconfig" > @@ -461,8 +461,8 @@ config RAW_DRIVER > Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O. > See the raw(8) manpage for more details. > > - Applications should preferably open the device (eg /dev/hda1) > - with the O_DIRECT flag. > + Applications should preferably open the device (eg /dev/hda1) > + with the O_DIRECT flag. > > config MAX_RAW_DEVS > int "Maximum number of RAW devices to support (1-65536)" > diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig > index 6231714..6da28d5 100644 > --- a/drivers/char/agp/Kconfig > +++ b/drivers/char/agp/Kconfig > @@ -63,7 +63,7 @@ config AGP_AMD64 > This option gives you AGP support for the GLX component of > X using the on-CPU northbridge of the AMD Athlon64/Opteron CPUs. > You still need an external AGP bridge like the AMD 8151, VIA > - K8T400M, SiS755. It may also support other AGP bridges when loaded > + K8T400M, SiS755. It may also support other AGP bridges when loaded > with agp_try_unsupported=1. > > config AGP_INTEL > @@ -151,13 +151,12 @@ config AGP_EFFICEON > series processors with integrated northbridges. > > config AGP_SGI_TIOCA > -tristate "SGI TIO chipset AGP support" > -depends on AGP && (IA64_SGI_SN2 || IA64_GENERIC) > -help > - This option gives you AGP GART support for the SGI TIO chipset > - for IA64 processors. > + tristate "SGI TIO chipset AGP support" > + depends on AGP && (IA64_SGI_SN2 || IA64_GENERIC) > + help > + This option gives you AGP GART support for the SGI TIO chipset > + for IA64 processors. > > config INTEL_GTT > tristate > depends on X86 && PCI > - > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig > index 25a7d8f..6265931 100644 > --- a/drivers/char/hw_random/Kconfig > +++ b/drivers/char/hw_random/Kconfig > @@ -156,15 +156,15 @@ config HW_RANDOM_OMAP > tristate "OMAP Random Number Generator support" > depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS || ARCH_MVEBU > default HW_RANDOM > - ---help--- > - This driver provides kernel-side support for the Random Number > + ---help--- > + This driver provides kernel-side support for the Random Number > Generator hardware found on OMAP16xx,
Re: [PATCH 034/114] arch: arm: Kconfig: pedantic formatting
On Mon, Mar 11, 2019 at 10:29 PM Enrico Weigelt, metux IT consult wrote: > > Formatting of Kconfig files doesn't look so pretty, so let the > Great White Handkerchief come around and clean it up. > > Signed-off-by: Enrico Weigelt, metux IT consult > --- > arch/arm/Kconfig | 24 +++--- While you are touching this file, why don't fix checkpatch.pl warning? WARNING: prefer 'help' over '---help---' for new help texts #1725: FILE: arch/arm/Kconfig:1725: +config SECCOMP > arch/arm/mach-aspeed/Kconfig | 10 - > arch/arm/mach-ep93xx/Kconfig | 8 > arch/arm/mach-hisi/Kconfig| 14 ++--- > arch/arm/mach-ixp4xx/Kconfig | 32 ++--- > arch/arm/mach-mmp/Kconfig | 2 +- > arch/arm/mach-omap1/Kconfig | 36 > arch/arm/mach-omap2/Kconfig | 12 +-- > arch/arm/mach-prima2/Kconfig | 6 +++--- > arch/arm/mach-s3c24xx/Kconfig | 32 ++--- > arch/arm/mach-s3c64xx/Kconfig | 16 +++ > arch/arm/mach-sa1100/Kconfig | 4 ++-- > arch/arm/mach-vt8500/Kconfig | 6 +++--- > arch/arm/mach-w90x900/Kconfig | 6 +++--- > arch/arm/mm/Kconfig | 48 > +-- > arch/arm/plat-samsung/Kconfig | 26 +++ > 16 files changed, 140 insertions(+), 142 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 5085a1e..c89f683 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1115,14 +1115,14 @@ config ARM_ERRATA_764369 > in the diagnostic control register of the SCU. > > config ARM_ERRATA_775420 > - bool "ARM errata: A data cache maintenance operation which aborts, > might lead to deadlock" > - depends on CPU_V7 > - help > -This option enables the workaround for the 775420 Cortex-A9 (r2p2, > -r2p6,r2p8,r2p10,r3p0) erratum. In case a date cache maintenance > -operation aborts with MMU exception, it might cause the processor > -to deadlock. This workaround puts DSB before executing ISB if > -an abort may occur on cache maintenance. > + bool "ARM errata: A data cache maintenance operation which aborts, > might lead to deadlock" > + depends on CPU_V7 > + help > + This option enables the workaround for the 775420 Cortex-A9 (r2p2, > + r2p6,r2p8,r2p10,r3p0) erratum. In case a date cache maintenance > + operation aborts with MMU exception, it might cause the processor > + to deadlock. This workaround puts DSB before executing ISB if > + an abort may occur on cache maintenance. > > config ARM_ERRATA_798181 > bool "ARM errata: TLBI/DSB failure on Cortex-A15" > @@ -1650,12 +1650,12 @@ config HW_PERF_EVENTS > depends on ARM_PMU > > config SYS_SUPPORTS_HUGETLBFS > - def_bool y > - depends on ARM_LPAE > + def_bool y > + depends on ARM_LPAE > > config HAVE_ARCH_TRANSPARENT_HUGEPAGE > - def_bool y > - depends on ARM_LPAE > + def_bool y > + depends on ARM_LPAE > > config ARCH_WANT_GENERAL_HUGETLB > def_bool y > diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig > index 2d5570e..f6eaf05 100644 > --- a/arch/arm/mach-aspeed/Kconfig > +++ b/arch/arm/mach-aspeed/Kconfig > @@ -18,9 +18,9 @@ config MACH_ASPEED_G4 > select CPU_ARM926T > select PINCTRL_ASPEED_G4 > help > -Say yes if you intend to run on an Aspeed ast2400 or similar > -fourth generation BMCs, such as those used by OpenPower Power8 > -systems. > + Say yes if you intend to run on an Aspeed ast2400 or similar > + fourth generation BMCs, such as those used by OpenPower Power8 > + systems. > > config MACH_ASPEED_G5 > bool "Aspeed SoC 5th Generation" > @@ -28,7 +28,7 @@ config MACH_ASPEED_G5 > select CPU_V6 > select PINCTRL_ASPEED_G5 > help > -Say yes if you intend to run on an Aspeed ast2500 or similar > -fifth generation Aspeed BMCs. > + Say yes if you intend to run on an Aspeed ast2500 or similar > + fifth generation Aspeed BMCs. > > endif > diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig > index c095236..597ea24 100644 > --- a/arch/arm/mach-ep93xx/Kconfig > +++ b/arch/arm/mach-ep93xx/Kconfig > @@ -125,10 +125,10 @@ config MACH_MICRO9S > Contec Micro9-Slim board. > > config MACH_SIM_ONE > -bool "Support Simplemachines Sim.One board" > -help > - Say 'Y' here if you want your kernel to support the > - Simplemachines Sim.One board. > + bool "Support Simplemachines Sim.One board" > + help > + Say 'Y' here if you want your kernel to support the > + Simplemachines Sim.One board. > > config MACH_SNAPPER_CL15 > bool "Support Bluewater Systems Snapper CL15 Module" > diff --git
[no subject]
subscribe linux-kernel
Re: [PATCH -next] ASoC: wm_adsp: Make some variables static
Pls ignore this, sorry.
On 2019/3/21 9:43, Yue Haibing wrote:
> From: YueHaibing
>
> Fix sparse warnings:
>
> sound/soc/codecs/wm_adsp.c:309:20: warning: symbol 'wm_adsp1_ops' was not
> declared. Should it be static?
> sound/soc/codecs/wm_adsp.c:310:20: warning: symbol 'wm_adsp2_ops' was not
> declared. Should it be static?
> sound/soc/codecs/wm_adsp.c:311:20: warning: symbol 'wm_halo_ops' was not
> declared. Should it be static?
>
> Signed-off-by: YueHaibing
> ---
> sound/soc/codecs/wm_adsp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
> index 644aaf1..4ed587f 100644
> --- a/sound/soc/codecs/wm_adsp.c
> +++ b/sound/soc/codecs/wm_adsp.c
> @@ -306,9 +306,9 @@
> #define HALO_MPU_VIO_ERR_SRC_MASK 0x7fff
> #define HALO_MPU_VIO_ERR_SRC_SHIFT 0
>
> -struct wm_adsp_ops wm_adsp1_ops;
> -struct wm_adsp_ops wm_adsp2_ops[];
> -struct wm_adsp_ops wm_halo_ops;
> +static struct wm_adsp_ops wm_adsp1_ops;
> +static struct wm_adsp_ops wm_adsp2_ops[];
> +static struct wm_adsp_ops wm_halo_ops;
>
> struct wm_adsp_buf {
> struct list_head list;
>
[PATCH -next] ASoC: wm_adsp: Make some variables static
From: YueHaibing
Fix sparse warnings:
sound/soc/codecs/wm_adsp.c:309:20: warning: symbol 'wm_adsp1_ops' was not
declared. Should it be static?
sound/soc/codecs/wm_adsp.c:310:20: warning: symbol 'wm_adsp2_ops' was not
declared. Should it be static?
sound/soc/codecs/wm_adsp.c:311:20: warning: symbol 'wm_halo_ops' was not
declared. Should it be static?
Signed-off-by: YueHaibing
---
sound/soc/codecs/wm_adsp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
index 644aaf1..4ed587f 100644
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -306,9 +306,9 @@
#define HALO_MPU_VIO_ERR_SRC_MASK 0x7fff
#define HALO_MPU_VIO_ERR_SRC_SHIFT 0
-struct wm_adsp_ops wm_adsp1_ops;
-struct wm_adsp_ops wm_adsp2_ops[];
-struct wm_adsp_ops wm_halo_ops;
+static struct wm_adsp_ops wm_adsp1_ops;
+static struct wm_adsp_ops wm_adsp2_ops[];
+static struct wm_adsp_ops wm_halo_ops;
struct wm_adsp_buf {
struct list_head list;
--
2.7.0
drm/Kconfig: Remove selection of BACKLIGHT_* options for DRM_RADEON
From e38df43127fd9a5db167f5873aee882b60f63f37 Mon Sep 17 00:00:00 2001 From: Alec Ari Date: Wed, 20 Mar 2019 20:19:48 -0500 Subject: drm/Kconfig: Remove selection of BACKLIGHT_* options for DRM_RADEON Backlight support is not required for base DRM_RADEON functionality. Tested on Acer Aspire One w/ Radeon HD 6290. Signed-off-by: Alec Ari --- drivers/gpu/drm/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index bd943a71756c..16dd978bd74e 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -193,8 +193,6 @@ config DRM_RADEON select DRM_TTM select POWER_SUPPLY select HWMON - select BACKLIGHT_CLASS_DEVICE - select BACKLIGHT_LCD_SUPPORT select INTERVAL_TREE help Choose this option if you have an ATI Radeon graphics card. There -- 2.20.1
Re: [PATCH v2 0/2] extcon: Introduce support of Basin Cove PMIC
Hi Andy, On 19. 3. 19. 오후 11:30, Andy Shevchenko wrote: > On Intel Merrifield platforms the Basin Cove PMIC responsible for USB DR > detection among other things. > > Here is the extcon driver to support USB DR and charger detection. > > Since v2: > - rebase on top of extcon-next > - update copyright year > - address most of Chanwoo's comments > (rest is left in similarity with other Intel extcon drivers) > > Andy Shevchenko (2): > extcon: intel: Split out some definitions to a common header > extcon: mrfld: Introduce extcon driver for Basin Cove PMIC > > drivers/extcon/Kconfig | 7 + > drivers/extcon/Makefile | 1 + > drivers/extcon/extcon-intel-cht-wc.c | 21 +- > drivers/extcon/extcon-intel-mrfld.c | 284 +++ > drivers/extcon/extcon-intel.h| 20 ++ > 5 files changed, 319 insertions(+), 14 deletions(-) > create mode 100644 drivers/extcon/extcon-intel-mrfld.c > create mode 100644 drivers/extcon/extcon-intel.h > Applied them to extcon-next branch. Thanks. -- Best Regards, Chanwoo Choi Samsung Electronics
[v3 PATCH] rhashtable: Still do rehash when we get EEXIST
On Wed, Mar 20, 2019 at 03:29:17PM -0700, Josh Hunt wrote:
>
> Herbert
>
> We're seeing this pretty regularly on 4.14 LTS kernels. I didn't see your
> change in any of the regular trees. Are there plans to submit this? If so,
> can it get queued up for 4.14 stable too?
Hi Josh:
Thanks for reminding me. Looks like this one slipped through the
cracks.
Dave, could you please apply this? Thanks!
---8<---
As it stands if a shrink is delayed because of an outstanding
rehash, we will go into a rescheduling loop without ever doing
the rehash.
This patch fixes this by still carrying out the rehash and then
rescheduling so that we can shrink after the completion of the
rehash should it still be necessary.
The return value of EEXIST captures this case and other cases
(e.g., another thread expanded/rehashed the table at the same
time) where we should still proceed with the rehash.
Fixes: da20420f83ea ("rhashtable: Add nested tables")
Reported-by: Josh Elsasser
Signed-off-by: Herbert Xu
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 852ffa5160f1..4edcf3310513 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -416,8 +416,12 @@ static void rht_deferred_worker(struct work_struct *work)
else if (tbl->nest)
err = rhashtable_rehash_alloc(ht, tbl, tbl->size);
- if (!err)
- err = rhashtable_rehash_table(ht);
+ if (!err || err == -EEXIST) {
+ int nerr;
+
+ nerr = rhashtable_rehash_table(ht);
+ err = err ?: nerr;
+ }
mutex_unlock(>mutex);
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 2/2] [WIP] tools/power turbostat: Also read package power on AMD F17h (Zen)
(Whoops, resending this message. Forgot that Gmail defaulted to
HTML...)
On Wed, 2019-03-20 at 19:36 -0400, Len Brown wrote:
> Hi Calvin,
> I'm inclined to apply this -- because it will not break anything,
> and it would at least enable testing by people, who have this
> hardware.
Hi Len,
By all means go ahead and apply the package power patch as well. I've
tested it on both Summit (single-die desktop) and Raven (desktop/laptop
apu) with good results. The worst case as it stands is that if the
multi-die packages (EPYC/TR) don't aggregate the value per package,
then package power will be under-reported.
(I previously wrote that this would be easier to test with the patch
applied, because the package power is reported with the -Dump option,
but I'm not sure that's actually the case - the value might still only
be collected once per package?)
Calvin.
>
> On Fri, Aug 17, 2018 at 12:35 PM Calvin Walton <
> calvin.wal...@kepstin.ca> wrote:
> > The package power can also be read from an MSR. It's not clear
> > exactly
> > what is included, and whether it's aggregated over all nodes or
> > reported separately.
> >
> > It does look like this is reported separately per CCX (I get a
> > single
> > value on the Ryzen R7 1700), but it might be reported separately
> > per-
> > die (node?) on larger processors. If that's the case, it would have
> > to
> > be recorded per node and aggregated for the socket.
> >
> > Note that although Zen has these MSRs reporting power, it looks
> > like
> > the actual RAPL configuration (power limits, configured TDP) is
> > done
> > through PCI configuration space. I have not yet found any public
> > documentation for this.
> >
> > Signed-off-by: Calvin Walton
> > ---
> > tools/power/x86/turbostat/turbostat.c | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/power/x86/turbostat/turbostat.c
> > b/tools/power/x86/turbostat/turbostat.c
> > index 89d4e2e75774..675c894b8595 100644
> > --- a/tools/power/x86/turbostat/turbostat.c
> > +++ b/tools/power/x86/turbostat/turbostat.c
> > @@ -1973,6 +1973,11 @@ int get_counters(struct thread_data *t,
> > struct core_data *c, struct pkg_data *p)
> > return -16;
> > p->rapl_dram_perf_status = msr & 0x;
> > }
> > + if (do_rapl & RAPL_AMD_F17H) {
> > + if (get_msr(cpu, MSR_PKG_ENERGY_STAT, ))
> > + return -13;
> > + p->energy_pkg = msr & 0x;
> > + }
> > if (DO_BIC(BIC_PkgTmp)) {
> > if (get_msr(cpu, MSR_IA32_PACKAGE_THERM_STATUS,
> > ))
> > return -17;
> > @@ -3986,10 +3991,13 @@ void rapl_probe_amd(unsigned int family,
> > unsigned int model)
> > switch (family) {
> > case 0x17: /* Zen, Zen+ */
> > do_rapl = RAPL_AMD_F17H | RAPL_PER_CORE_ENERGY;
> > - if (rapl_joules)
> > + if (rapl_joules) {
> > + BIC_PRESENT(BIC_Pkg_J);
> > BIC_PRESENT(BIC_Cor_J);
> > - else
> > + } else {
> > + BIC_PRESENT(BIC_PkgWatt);
> > BIC_PRESENT(BIC_CorWatt);
> > + }
> > break;
> > default:
> > return;
> > --
> > 2.18.0
> >
>
>
[PATCH v4] perf tools: Add missing case value
The following error was thrown when compiling `tools/perf` using OpenCSD
v0.11.1. This patch fixes said error.
```
CC util/intel-pt-decoder/intel-pt-log.o
CC util/cs-etm-decoder/cs-etm-decoder.o
util/cs-etm-decoder/cs-etm-decoder.c: In function
‘cs_etm_decoder__buffer_range’:
util/cs-etm-decoder/cs-etm-decoder.c:370:2: error: enumeration value
‘OCSD_INSTR_WFI_WFE’ not handled in switch [-Werror=switch-enum]
switch (elem->last_i_type) {
^~
CC util/intel-pt-decoder/intel-pt-decoder.o
cc1: all warnings being treated as errors
```
Because `OCSD_INSTR_WFI_WFE` case was added only in v0.11.0, the minimum
required OpenCSD library version for this patch is no longer v0.10.0.
Signed-off-by: Solomon Tan
---
tools/build/feature/test-libopencsd.c | 4 ++--
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/build/feature/test-libopencsd.c
b/tools/build/feature/test-libopencsd.c
index d68eb4fb40cc..2b0e02c38870 100644
--- a/tools/build/feature/test-libopencsd.c
+++ b/tools/build/feature/test-libopencsd.c
@@ -4,9 +4,9 @@
/*
* Check OpenCSD library version is sufficient to provide required features
*/
-#define OCSD_MIN_VER ((0 << 16) | (10 << 8) | (0))
+#define OCSD_MIN_VER ((0 << 16) | (11 << 8) | (0))
#if !defined(OCSD_VER_NUM) || (OCSD_VER_NUM < OCSD_MIN_VER)
-#error "OpenCSD >= 0.10.0 is required"
+#error "OpenCSD >= 0.11.0 is required"
#endif
int main(void)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index ba4c623cd8de..39fe21e1cf93 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -387,6 +387,7 @@ cs_etm_decoder__buffer_range(struct cs_etm_decoder *decoder,
break;
case OCSD_INSTR_ISB:
case OCSD_INSTR_DSB_DMB:
+ case OCSD_INSTR_WFI_WFE:
case OCSD_INSTR_OTHER:
default:
packet->last_instr_taken_branch = false;
--
2.19.1
publickey - solomonbstoner@protonmail.ch - 0xA77658B9.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v3] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected
On 3/20/19 4:44 PM, Linus Torvalds wrote: On Wed, Mar 20, 2019 at 1:52 PM Bjorn Helgaas wrote: AFAICT, the consensus there was that it would be better to find some sort of platform solution instead of dealing with it in individual drivers. The PCI core isn't really a driver, but I think the same argument applies to it: if we had a better way to recover from readl() errors, that way would work equally well in nvme-pci and the PCI core. I think that patches with the pattern "if (disconnected) don't do IO" are fundamentally broken and we should look for alternatives in all cases. They are fundamentally broken because they are racy: if it's an actual sudden disconnect in the middle of IO, there's no guarantee that we'll even be notified in time. They are fundamentally broken because they add new magic special cases that very few people will ever test, and the people who do test them tend to do so with old irrelevant kernels. Finally, they are fundamentally broken because they always end up being just special cases. One or two special case accesses in a driver, or perhaps all accesses of a particular type in just _one_ special driver. Yes, yes, I realize that people want error reporting, and that hot-removal can cause various error conditions (perhaps just parity errors for the IO, but also perhaps other random errors caused by firmware perhaps doing special HW setup). But the "you get a fatal interrupt, so avoid the IO" kind of model is completely broken, and needs to just be fixed differently. See above why it's so completely broken. So if the hw is set up to send some kinf of synchronous interrupt or machine check that cannot sanely be handled (perhaps because it will just repeat forever), we should try to just disable said thing. PCIe allows for just polling for errors on the bridges, afaik. It's been years since I looked at it, and maybe I'm wrong. And I bet there are various "platform-specific value add" registers etc that may need tweaking outside of any standard spec for PCIe error reporting. But let's do that in a platform driver, to set up the platform to not do the silly "I'm just going to die if I see an error" thing. It's way better to have a model where you poll each bridge once a minute (or one an hour) and let people know "guys, your hardware reports errors", than make random crappy changes to random drivers because the hardware was set up to die on said errors. And if some MIS person wants the "hardware will die" setting, then they can damn well have that, and then it's not out problem, but it also means that we don't start changing random drivers for that insane setting. It's dead, Jim, and it was the users choice. Notice how in neither case does it make sense to try to do some "if (disconnected) dont_do_io()" model for the drivers. I disagree with the idea of doing something you know can cause an error to propagate. That being said, in this particular case we have come to rely a little too much on the if (disconnected) model. You mentioned in the other thread that fixing the GHES driver will pay much higher dividends. I'm working on reviving a couple of changes to do just that. Some industry folk were very concerned about the "don't panic()" approach, and I want to make sure I fairly present their arguments in the cover letter. I'm hoping one day we'll have the ability to use page tables to prevent the situations that we're trying to fix today in less than ideal ways. Although there are other places in msi.c that use if (disconnected), I'm okay with dropping this change -- provided we come up with an equivalent fix. But even if FFS doesn't crash, do we really want to lose hundreds of milliseconds to SMM --on all cores-- when all it takes is a couple of cycles to check a flag? Alex
Re: [PATCH] kbuild: skip sub-make for in-tree build with GNU Make 4.x
On Tue, Mar 19, 2019 at 1:03 PM Masahiro Yamada
wrote:
>
> Commit 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
> annoyed people who want to wrap the top Makefile with GNUmakefile
> or something in order to customize it for their use.
>
> On second thought, we do not need to run the sub-make for in-tree
> build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
> on GNU Make 3.x.
>
> With this commit, people will get back the workflow, and the Debian
> make-kpkg will still work.
>
> Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
> Reported-by: Andreas Schwab
> Reported-by: David Howells
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild/fixes.
>
> Makefile | 31 +++
> 1 file changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 99c0530..d9591f2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -31,26 +31,12 @@ _all:
> # descending is started. They are now explicitly listed as the
> # prepare rule.
>
> -# Ugly workaround for Debian make-kpkg:
> -# make-kpkg directly includes the top Makefile of Linux kernel. In such a
> case,
> -# skip sub-make to support debian_* targets in ruleset/kernel_version.mk, but
> -# displays warning to discourage such abusage.
> -ifneq ($(word 2, $(MAKEFILE_LIST)),)
> -$(warning Do not include top Makefile of Linux Kernel)
> -sub-make-done := 1
> -MAKEFLAGS += -rR
> -endif
> -
> ifneq ($(sub-make-done),1)
>
> # Do not use make's built-in rules and variables
> # (this increases performance and avoids hard-to-debug behaviour)
> MAKEFLAGS += -rR
>
> -# 'MAKEFLAGS += -rR' does not become immediately effective for old
> -# GNU Make versions. Cancel implicit rules for this Makefile.
> -$(lastword $(MAKEFILE_LIST)): ;
> -
> # Avoid funny character set dependencies
> unexport LC_ALL
> LC_COLLATE=C
> @@ -153,6 +139,7 @@ $(if $(KBUILD_OUTPUT),, \
> # 'sub-make' below.
> MAKEFLAGS += --include-dir=$(CURDIR)
>
> +need-sub-make := 1
> else
>
> # Do not print "Entering directory ..." at all for in-tree build.
> @@ -160,6 +147,15 @@ MAKEFLAGS += --no-print-directory
>
> endif # ifneq ($(KBUILD_OUTPUT),)
>
> +ifneq ($(filter 3.%,$(MAKE_VERSION)),)
> +# 'MAKEFLAGS += -rR' does not immediately become effective for GNU Make 3.x
> +# We need to run sub-make to avoid implicit rules in the top Makefile.
> +need-sub-make := 1
> +# Cancel implicit rules for this Makefile.
> +$(lastword $(MAKEFILE_LIST)): ;
> +endif
> +
> +ifeq ($(need-sub-make),1)
> PHONY += $(MAKECMDGOALS) sub-make
>
> $(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all:
> sub-make
> @@ -171,8 +167,11 @@ sub-make:
> $(if $(KBUILD_OUTPUT),-C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR)) \
> -f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
>
> -else # sub-make-done
> +endif # need-sub-make
> +endif # sub-make-done
> +
> # We process the rest of the Makefile if this is the final invocation of make
> +ifeq ($(need-sub-make),)
>
> # Do not print "Entering directory ...",
> # but we want to display it when entering to the output directory
> @@ -1757,7 +1756,7 @@ existing-targets := $(wildcard $(sort $(targets)))
>
> endif # ifeq ($(config-targets),1)
> endif # ifeq ($(mixed-targets),1)
> -endif # sub-make-done
> +endif # need-sub-make
>
> PHONY += FORCE
> FORCE:
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
RE: [PATCH v2] arm64: dts: ls1088a: add one more thermal zone node
> -Original Message- > From: Shawn Guo > Sent: 2019年3月20日 22:49 > To: Andy Tang > Cc: Daniel Lezcano ; mark.rutl...@arm.com; > devicet...@vger.kernel.org; linux...@vger.kernel.org; > linux-kernel@vger.kernel.org; Leo Li ; > edubez...@gmail.com; robh...@kernel.org; rui.zh...@intel.com; > linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v2] arm64: dts: ls1088a: add one more thermal zone node > > On Wed, Mar 20, 2019 at 08:44:18AM +, Andy Tang wrote: > > > > Sensor ID placement > > > > 1 DDR controller 1 > > > > 2 DDR controller 2 > > > > 3 DDR controller 3 > > > > 4 core cluster 1 > > > > 5 core cluster 2 > > > > 6 core cluster 3 > > > > 7 core cluster 4 > > > > > > > > Apparently using CPU or CPU-cluster is not appropriate. Core-cluster is > better. > > > > > > So using CPU is appropriate for me, less confusing, more consistent > > > with other platforms. > > What about core cluster? We can't name it cpu0, cpu1 etc I think. > > Hmm, yes, that would be even more confusing. What about cpu-thermal-1, > cpu-thermal-2 ...? Cpu-thermal-x can't change anything better than cpuX. It can't reflect the concept of CLUSTER. I prefer to use core-cluster. It is a wild accepted term in ARM ecosystem. BR, Andy > > Shawn
Dear Friend,
Dear Friend, I am Mrs Clara David. am sending you this brief letter to solicit your partnership to transfer $18.5 million US Dollars.I shall send you more information and procedures when I receive positive response from you. please send me a message in my Email box (mrsclarad...@gmail.com) as i wait to hear from you. Best regard Mrs Clara David.
[PATCH V8 2/5] pwm: Add i.MX TPM PWM driver support
i.MX7ULP has TPM(Low Power Timer/Pulse Width Modulation Module)
inside, it can support multiple PWM channels, all the channels
share same counter and period setting, but each channel can
configure its duty and polarity independently.
There are several TPM modules in i.MX7ULP, the number of channels
in TPM modules are different, it can be read from each TPM module's
PARAM register.
Signed-off-by: Anson Huang
---
changes since V7:
- improve prescale computation;
- improve some register definitions;
- remove unnecessary check for period count check;
- improve function parameter to use pointer instead of value;
---
drivers/pwm/Kconfig | 11 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-imx-tpm.c | 435 ++
3 files changed, 447 insertions(+)
create mode 100644 drivers/pwm/pwm-imx-tpm.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 54f8238..3ea0391 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -210,6 +210,17 @@ config PWM_IMX27
To compile this driver as a module, choose M here: the module
will be called pwm-imx27.
+config PWM_IMX_TPM
+ tristate "i.MX TPM PWM support"
+ depends on ARCH_MXC || COMPILE_TEST
+ depends on HAVE_CLK && HAS_IOMEM
+ help
+ Generic PWM framework driver for i.MX7ULP TPM module, TPM's full
+ name is Low Power Timer/Pulse Width Modulation Module.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-imx-tpm.
+
config PWM_JZ4740
tristate "Ingenic JZ47xx PWM support"
depends on MACH_INGENIC
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 448825e..c368599 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_PWM_HIBVT) += pwm-hibvt.o
obj-$(CONFIG_PWM_IMG) += pwm-img.o
obj-$(CONFIG_PWM_IMX1) += pwm-imx1.o
obj-$(CONFIG_PWM_IMX27)+= pwm-imx27.o
+obj-$(CONFIG_PWM_IMX_TPM) += pwm-imx-tpm.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o
obj-$(CONFIG_PWM_LPC18XX_SCT) += pwm-lpc18xx-sct.o
diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
new file mode 100644
index 000..0efea36
--- /dev/null
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -0,0 +1,435 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018-2019 NXP.
+ *
+ * Limitations:
+ * - The TPM counter and period counter are shared between
+ * multiple channels, so all channels should use same period
+ * settings.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PWM_IMX_TPM_PARAM 0x4
+#define PWM_IMX_TPM_GLOBAL 0x8
+#define PWM_IMX_TPM_SC 0x10
+#define PWM_IMX_TPM_CNT0x14
+#define PWM_IMX_TPM_MOD0x18
+#define PWM_IMX_TPM_CnSC(n)(0x20 + (n) * 0x8)
+#define PWM_IMX_TPM_CnV(n) (0x24 + (n) * 0x8)
+
+#define PWM_IMX_TPM_PARAM_CHAN GENMASK(7, 0)
+
+#define PWM_IMX_TPM_SC_PS GENMASK(2, 0)
+#define PWM_IMX_TPM_SC_CMODGENMASK(4, 3)
+#define PWM_IMX_TPM_SC_CMOD_INC_EVERY_CLK FIELD_PREP(PWM_IMX_TPM_SC_CMOD,
1)
+#define PWM_IMX_TPM_SC_CPWMS BIT(5)
+
+#define PWM_IMX_TPM_CnSC_CHF BIT(7)
+#define PWM_IMX_TPM_CnSC_MSB BIT(5)
+#define PWM_IMX_TPM_CnSC_MSA BIT(4)
+
+/*
+ * The reference manual describes this field as two separate bits. The
+ * samantic of the two bits isn't orthogonal though, so they are treated
+ * together as a 2-bit field here.
+ */
+#define PWM_IMX_TPM_CnSC_ELS GENMASK(3, 2)
+#define PWM_IMX_TPM_CnSC_ELS_POLARITY_INVERSED 0x1
+#define PWM_IMX_TPM_CnSC_ELS_INVERSED FIELD_PREP(PWM_IMX_TPM_CnSC_ELS, 1)
+#define PWM_IMX_TPM_CnSC_ELS_NORMALFIELD_PREP(PWM_IMX_TPM_CnSC_ELS, 2)
+
+
+#define PWM_IMX_TPM_MOD_WIDTH 16
+#define PWM_IMX_TPM_MOD_MODGENMASK(PWM_IMX_TPM_MOD_WIDTH - 1, 0)
+
+struct imx_tpm_pwm_chip {
+ struct pwm_chip chip;
+ struct clk *clk;
+ void __iomem *base;
+ struct mutex lock;
+ u32 user_count;
+ u32 enable_count;
+ u32 real_period;
+};
+
+struct imx_tpm_pwm_param {
+ u8 prescale;
+ u32 mod;
+};
+
+static inline struct imx_tpm_pwm_chip *to_imx_tpm_pwm_chip(struct pwm_chip
*chip)
+{
+ return container_of(chip, struct imx_tpm_pwm_chip, chip);
+}
+
+static int pwm_imx_tpm_round_state(struct pwm_chip *chip,
+ struct imx_tpm_pwm_param *p,
+ struct pwm_state *state,
+ struct pwm_state *real_state)
+{
+ struct imx_tpm_pwm_chip *tpm = to_imx_tpm_pwm_chip(chip);
+ u32 rate, prescale, period_count, clock_unit;
+ u64 tmp;
+
+ rate = clk_get_rate(tpm->clk);
+ tmp = (u64)state->period
[PATCH V8 4/5] ARM: dts: imx7ulp: Add pwm0 support
Add i.MX7ULP EVK board PWM0 support.
Signed-off-by: Anson Huang
---
no changes.
---
arch/arm/boot/dts/imx7ulp.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index eb349fd..15d04fb 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -124,6 +124,16 @@
status = "disabled";
};
+ pwm0: pwm@4025 {
+ compatible = "fsl,imx-tpm";
+ reg = <0x4025 0x1000>;
+ assigned-clocks = < IMX7ULP_CLK_LPTPM4>;
+ assigned-clock-parents = <
IMX7ULP_CLK_SOSC_BUS_CLK>;
+ clocks = < IMX7ULP_CLK_LPTPM4>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
tpm5: tpm@4026 {
compatible = "fsl,imx7ulp-tpm";
reg = <0x4026 0x1000>;
--
2.7.4
[PATCH V8 5/5] ARM: dts: imx7ulp-evk: Add backlight support
This patch adds i.MX7ULP EVK board MIPI-DSI backlight support.
Signed-off-by: Anson Huang
---
no changes.
---
arch/arm/boot/dts/imx7ulp-evk.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp-evk.dts
b/arch/arm/boot/dts/imx7ulp-evk.dts
index a09026a..7c44ffa 100644
--- a/arch/arm/boot/dts/imx7ulp-evk.dts
+++ b/arch/arm/boot/dts/imx7ulp-evk.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "imx7ulp.dtsi"
+#include
/ {
model = "NXP i.MX7ULP EVK";
@@ -22,6 +23,14 @@
reg = <0x6000 0x4000>;
};
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = < 1 5 0>;
+ brightness-levels = <0 20 25 30 35 40 100>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+
reg_vsd_3v3: regulator-vsd-3v3 {
compatible = "regulator-fixed";
regulator-name = "VSD_3V3";
@@ -40,6 +49,12 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwm0>;
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_usdhc0>;
@@ -57,6 +72,12 @@
bias-pull-up;
};
+ pinctrl_pwm0: pwm0grp {
+ fsl,pins = <
+ IMX7ULP_PAD_PTF2__TPM4_CH1 0x2
+ >;
+ };
+
pinctrl_usdhc0: usdhc0grp {
fsl,pins = <
IMX7ULP_PAD_PTD1__SDHC0_CMD 0x43
--
2.7.4
[PATCH V8 3/5] ARM: imx_v6_v7_defconfig: Add TPM PWM support by default
Select CONFIG_PWM_IMX_TPM by default to support i.MX7ULP TPM PWM. Signed-off-by: Anson Huang --- no changes. --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 5586a50..57862c6 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -399,6 +399,7 @@ CONFIG_MPL3115=y CONFIG_PWM=y CONFIG_PWM_FSL_FTM=y CONFIG_PWM_IMX=y +CONFIG_PWM_IMX_TPM=y CONFIG_NVMEM_IMX_OCOTP=y CONFIG_NVMEM_VF610_OCOTP=y CONFIG_TEE=y -- 2.7.4
[PATCH V8 1/5] dt-bindings: pwm: Add i.MX TPM PWM binding
Add i.MX TPM(Low Power Timer/Pulse Width Modulation Module) PWM binding.
Signed-off-by: Anson Huang
---
no changes.
---
.../devicetree/bindings/pwm/imx-tpm-pwm.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
new file mode 100644
index 000..94f1ad5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
@@ -0,0 +1,22 @@
+Freescale i.MX TPM PWM controller
+
+Required properties:
+- compatible : Should be "fsl,imx-tpm".
+- reg: Physical base address and length of the controller's registers.
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
the cells format.
+- clocks : The clock provided by the SoC to drive the PWM.
+- interrupts: The interrupt for the PWM controller.
+
+Note: The TPM counter and period counter are shared between multiple channels,
so all channels
+should use same period setting.
+
+Example:
+
+pwm0: tpm@4025 {
+ compatible = "fsl,imx-tpm";
+ reg = <0x4025 0x1000>;
+ assigned-clocks = < IMX7ULP_CLK_LPTPM4>;
+ assigned-clock-parents = < IMX7ULP_CLK_SOSC_BUS_CLK>;
+ clocks = < IMX7ULP_CLK_LPTPM4>;
+ #pwm-cells = <3>;
+};
--
2.7.4
[PATCH V8 0/5] Add i.MX7ULP EVK PWM backlight support
i.MX7ULP EVK board has MIPI-DSI display, its backlight is supplied by TPM PWM module, this patch set enables i.MX7ULP TPM PWM driver support and also add backlight support for MIPI-DSI display. Changes since V7: - ONLY change the pwm driver patch. Anson Huang (5): dt-bindings: pwm: Add i.MX TPM PWM binding pwm: Add i.MX TPM PWM driver support ARM: imx_v6_v7_defconfig: Add TPM PWM support by default ARM: dts: imx7ulp: Add pwm0 support ARM: dts: imx7ulp-evk: Add backlight support .../devicetree/bindings/pwm/imx-tpm-pwm.txt| 22 ++ arch/arm/boot/dts/imx7ulp-evk.dts | 21 + arch/arm/boot/dts/imx7ulp.dtsi | 10 + arch/arm/configs/imx_v6_v7_defconfig | 1 + drivers/pwm/Kconfig| 11 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-imx-tpm.c | 435 + 7 files changed, 501 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt create mode 100644 drivers/pwm/pwm-imx-tpm.c -- 2.7.4
Re: [PATCH 5/8] scsi: lpfc: change snprintf to scnprintf for possible overflow
On 3/20/2019 10:39 AM, Greg KH wrote: On Tue, Jan 15, 2019 at 02:41:17PM -0800, James Smart wrote: On 1/14/2019 5:15 PM, Kees Cook wrote: On Sat, Jan 12, 2019 at 7:29 AM Willy Tarreau wrote: From: Silvio Cesare Change snprintf to scnprintf. There are generally two cases where using snprintf causes problems. 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...) In this case, if snprintf would have written more characters than what the buffer size (SIZE) is, then size will end up larger than SIZE. In later uses of snprintf, SIZE - size will result in a negative number, leading to problems. Note that size might already be too large by using size = snprintf before the code reaches a case of size += snprintf. 2) If size is ultimately used as a length parameter for a copy back to user space, then it will potentially allow for a buffer overflow and information disclosure when size is greater than SIZE. When the size is used to index the buffer directly, we can have memory corruption. This also means when size = snprintf... is used, it may also cause problems since size may become large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel configuration. The solution to these issues is to use scnprintf which returns the number of characters actually written to the buffer, so the size variable will never exceed SIZE. Signed-off-by: Silvio Cesare Cc: James Smart Cc: Dick Kennedy Cc: Dan Carpenter Cc: Kees Cook Cc: Will Deacon Cc: Greg KH Signed-off-by: Willy Tarreau I think this needs Cc: stable. Reviewed-by: Kees Cook -Kees Reviewed-by: James Smart What ever happened to this patch? Did it get dropped somehow? thanks, greg k-h I talked with them and will make sure it's pulled in shortly. -- james
what happened to SECURITY_DAC?
wow. Commit 70b62c25665f636c9f6c700b26af7df296b0887e from last Sept. 14, 2018, total commit description says: LoadPin: Initialize as ordered LSM This converts LoadPin from being a direct "minor" LSM into an ordered LSM. Nowhere does it say anything like "this also deletes any notions of DEFAULT_SECURITY and DAC." Was this deletion a (sekrit) security issue that was not being highlighted on purpose? and what do you recommend for simple DAC-like security? thanks. :( -- ~Randy
RE: [PATCH V8 2/4] watchdog: imx_sc: Add i.MX system controller watchdog support
Hi, Guenter Best Regards! Anson Huang > -Original Message- > From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter > Roeck > Sent: 2019年3月21日 8:32 > To: Anson Huang > Cc: w...@linux-watchdog.org; robh...@kernel.org; mark.rutl...@arm.com; > shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de; > feste...@gmail.com; catalin.mari...@arm.com; will.dea...@arm.com; > Aisheng Dong ; Daniel Baluta > ; he...@sntech.de; horms+rene...@verge.net.au; > Andy Gross ; maxime.rip...@bootlin.com; > o...@lixom.net; bjorn.anders...@linaro.org; ja...@amarulasolutions.com; > enric.balle...@collabora.com; ezequ...@collabora.com; > stefan.wah...@i2se.com; marc.w.gonza...@free.fr; linux- > watch...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; dl-linux-imx > > Subject: Re: [PATCH V8 2/4] watchdog: imx_sc: Add i.MX system controller > watchdog support > > On 3/20/19 5:22 PM, Anson Huang wrote: > > Hi, Guenter > > > > Best Regards! > > Anson Huang > > > >> -Original Message- > >> From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter > >> Roeck > >> Sent: 2019年3月20日 21:44 > >> To: Anson Huang > >> Cc: w...@linux-watchdog.org; robh...@kernel.org; > mark.rutl...@arm.com; > >> shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de; > >> feste...@gmail.com; catalin.mari...@arm.com; will.dea...@arm.com; > >> Aisheng Dong ; Daniel Baluta > >> ; he...@sntech.de; > horms+rene...@verge.net.au; > >> Andy Gross ; maxime.rip...@bootlin.com; > >> o...@lixom.net; bjorn.anders...@linaro.org; > >> ja...@amarulasolutions.com; enric.balle...@collabora.com; > >> ezequ...@collabora.com; stefan.wah...@i2se.com; > >> marc.w.gonza...@free.fr; linux- watch...@vger.kernel.org; > >> devicet...@vger.kernel.org; linux-arm- ker...@lists.infradead.org; > >> linux-kernel@vger.kernel.org; dl-linux-imx > >> Subject: Re: [PATCH V8 2/4] watchdog: imx_sc: Add i.MX system > >> controller watchdog support > >> > >> On Fri, Mar 15, 2019 at 06:17:25AM +, Anson Huang wrote: > >>> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller > >>> inside, the system controller is in charge of controlling power, > >>> clock and watchdog etc.. > >>> > >>> This patch adds i.MX system controller watchdog driver support, > >>> watchdog operation needs to be done in secure EL3 mode via > >>> ARM-Trusted-Firmware, using SMC call, CPU will trap into > >>> ARM-Trusted-Firmware and then it will request system controller to > >>> do watchdog operation via IPC. > >>> > >>> Signed-off-by: Anson Huang > >> > >> Reviewed-by: Guenter Roeck > >> > >> Waiting for bindings approval, though. Plus a minor comment below. > >> > >> Guenter > >> > >>> --- > >>> Changes since V7: > >>> - remove the dependence of IMX_SCU as it does NOT call SCU API > >> directly; > >>> - add more detail info into the help section of how this module works; > >>> - add back device id table since now we have watchdog node in DT. > >>> --- > >>> drivers/watchdog/Kconfig | 16 > >>> drivers/watchdog/Makefile | 1 + > >>> drivers/watchdog/imx_sc_wdt.c | 182 > >>> ++ > >>> 3 files changed, 199 insertions(+) > >>> create mode 100644 drivers/watchdog/imx_sc_wdt.c > >>> > >>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > >>> index > >>> 242eea8..44a3158 100644 > >>> --- a/drivers/watchdog/Kconfig > >>> +++ b/drivers/watchdog/Kconfig > >>> @@ -641,6 +641,22 @@ config IMX2_WDT > >>> To compile this driver as a module, choose M here: the > >>> module will be called imx2_wdt. > >>> > >>> +config IMX_SC_WDT > >>> + tristate "IMX SC Watchdog" > >>> + depends on HAVE_ARM_SMCCC > >>> + select WATCHDOG_CORE > >>> + help > >>> + This is the driver for the system controller watchdog > >>> + on the NXP i.MX SoCs with system controller inside, the > >>> + watchdog driver will call ARM SMC API and trap into > >>> + ARM-Trusted-Firmware for operations, ARM-Trusted-Firmware > >>> + will request system controller to execute the operations. > >>> + If you have one of these processors and wish to have > >>> + watchdog support enabled, say Y, otherwise say N. > >>> + > >>> + To compile this driver as a module, choose M here: the > >>> + module will be called imx_sc_wdt. > >>> + > >>> config UX500_WATCHDOG > >>> tristate "ST-Ericsson Ux500 watchdog" > >>> depends on MFD_DB8500_PRCMU > >>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > >>> index ba930e4..136d9f0 100644 > >>> --- a/drivers/watchdog/Makefile > >>> +++ b/drivers/watchdog/Makefile > >>> @@ -68,6 +68,7 @@ obj-$(CONFIG_NUC900_WATCHDOG) += > >> nuc900_wdt.o > >>> obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o > >>> obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o > >>> obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o > >>> +obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o > >>>
[PATCH v2 1/4] sched/cpufreq: Annotate cpufreq_update_util_data pointer with __rcu
Recently I added an RCU annotation check to rcu_assign_pointer(). All pointers assigned to RCU protected data are to be annotated with __rcu inorder to be able to use rcu_assign_pointer() similar to checks in other RCU APIs. This resulted in a sparse error: kernel//sched/cpufreq.c:41:9: sparse: error: incompatible types in comparison expression (different address spaces) Fix this by annotating cpufreq_update_util_data pointer with __rcu. This will also help sparse catch any future RCU misuage bugs. [From an RCU perspective] Reviewed-by: Paul E. McKenney Signed-off-by: Joel Fernandes (Google) --- kernel/sched/cpufreq.c | 2 +- kernel/sched/sched.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/cpufreq.c b/kernel/sched/cpufreq.c index 835671f0f917..b5dcd1d83c7f 100644 --- a/kernel/sched/cpufreq.c +++ b/kernel/sched/cpufreq.c @@ -7,7 +7,7 @@ */ #include "sched.h" -DEFINE_PER_CPU(struct update_util_data *, cpufreq_update_util_data); +DEFINE_PER_CPU(struct update_util_data __rcu *, cpufreq_update_util_data); /** * cpufreq_add_update_util_hook - Populate the CPU's update_util_data pointer. diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index efa686eeff26..713715dd00cf 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -2185,7 +2185,7 @@ static inline u64 irq_time_read(int cpu) #endif /* CONFIG_IRQ_TIME_ACCOUNTING */ #ifdef CONFIG_CPU_FREQ -DECLARE_PER_CPU(struct update_util_data *, cpufreq_update_util_data); +DECLARE_PER_CPU(struct update_util_data __rcu *, cpufreq_update_util_data); /** * cpufreq_update_util - Take a note about CPU utilization changes. -- 2.21.0.225.g810b269d1ac-goog
[PATCH v2 4/4] sched: Annotate perf_domain pointer with __rcu
This fixes the following sparse errors in sched/fair.c:
fair.c:6506:14: error: incompatible types in comparison expression
fair.c:8642:21: error: incompatible types in comparison expression
Using __rcu will also help sparse catch any future bugs.
[From an RCU perspective]
Reviewed-by: Paul E. McKenney
Signed-off-by: Joel Fernandes (Google)
---
kernel/sched/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 2b452d68ab2e..b52ed1ada0be 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -780,7 +780,7 @@ struct root_domain {
* NULL-terminated list of performance domains intersecting with the
* CPUs of the rd. Protected by RCU.
*/
- struct perf_domain *pd;
+ struct perf_domain __rcu *pd;
};
extern struct root_domain def_root_domain;
--
2.21.0.225.g810b269d1ac-goog
[PATCH v2 3/4] rcuwait: Annotate task_struct with __rcu
This suppresses sparse error generated due to the recently added
rcu_assign_pointer sparse check.
percpu-rwsem.c:162:9: sparse: error: incompatible types in comparison expression
exit.c:316:16: sparse: error: incompatible types in comparison expression
[From an RCU perspective]
Reviewed-by: Paul E. McKenney
Signed-off-by: Joel Fernandes (Google)
---
include/linux/rcuwait.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/rcuwait.h b/include/linux/rcuwait.h
index 90bfa3279a01..563290fc194f 100644
--- a/include/linux/rcuwait.h
+++ b/include/linux/rcuwait.h
@@ -18,7 +18,7 @@
* awoken.
*/
struct rcuwait {
- struct task_struct *task;
+ struct task_struct __rcu *task;
};
#define __RCUWAIT_INITIALIZER(name)\
--
2.21.0.225.g810b269d1ac-goog
[PATCH v2 2/4] sched_domain: Annotate RCU pointers properly
The scheduler uses RCU API in various places to access sched_domain
pointers. These cause sparse errors as below.
Many new errors show up because of an annotation check I added to
rcu_assign_pointer(). Let us annotate the pointers correctly which also
will help sparse catch any potential future bugs.
This fixes the following sparse errors:
rt.c:1681:9: error: incompatible types in comparison expression
deadline.c:1904:9: error: incompatible types in comparison expression
core.c:519:9: error: incompatible types in comparison expression
core.c:1634:17: error: incompatible types in comparison expression
fair.c:6193:14: error: incompatible types in comparison expression
fair.c:9883:22: error: incompatible types in comparison expression
fair.c:9897:9: error: incompatible types in comparison expression
sched.h:1287:9: error: incompatible types in comparison expression
topology.c:612:9: error: incompatible types in comparison expression
topology.c:615:9: error: incompatible types in comparison expression
sched.h:1300:9: error: incompatible types in comparison expression
topology.c:618:9: error: incompatible types in comparison expression
sched.h:1287:9: error: incompatible types in comparison expression
topology.c:621:9: error: incompatible types in comparison expression
sched.h:1300:9: error: incompatible types in comparison expression
topology.c:624:9: error: incompatible types in comparison expression
topology.c:671:9: error: incompatible types in comparison expression
stats.c:45:17: error: incompatible types in comparison expression
fair.c:5998:15: error: incompatible types in comparison expression
fair.c:5989:15: error: incompatible types in comparison expression
fair.c:5998:15: error: incompatible types in comparison expression
fair.c:5989:15: error: incompatible types in comparison expression
fair.c:6120:19: error: incompatible types in comparison expression
fair.c:6506:14: error: incompatible types in comparison expression
fair.c:6515:14: error: incompatible types in comparison expression
fair.c:6623:9: error: incompatible types in comparison expression
fair.c:5970:17: error: incompatible types in comparison expression
fair.c:8642:21: error: incompatible types in comparison expression
fair.c:9253:9: error: incompatible types in comparison expression
fair.c:9331:9: error: incompatible types in comparison expression
fair.c:9519:15: error: incompatible types in comparison expression
fair.c:9533:14: error: incompatible types in comparison expression
fair.c:9542:14: error: incompatible types in comparison expression
fair.c:9567:14: error: incompatible types in comparison expression
fair.c:9597:14: error: incompatible types in comparison expression
fair.c:9421:16: error: incompatible types in comparison expression
fair.c:9421:16: error: incompatible types in comparison expression
[From an RCU perspective]
Reviewed-by: Paul E. McKenney
Signed-off-by: Joel Fernandes (Google)
---
include/linux/sched/topology.h | 4 ++--
kernel/sched/sched.h | 14 +++---
kernel/sched/topology.c| 10 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index 57c7ed3fe465..cfc0a89a7159 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -76,8 +76,8 @@ struct sched_domain_shared {
struct sched_domain {
/* These fields must be setup */
- struct sched_domain *parent;/* top domain must be null terminated */
- struct sched_domain *child; /* bottom domain must be null
terminated */
+ struct sched_domain __rcu *parent; /* top domain must be null
terminated */
+ struct sched_domain __rcu *child; /* bottom domain must be null
terminated */
struct sched_group *groups; /* the balancing groups of the domain */
unsigned long min_interval; /* Minimum balance interval ms */
unsigned long max_interval; /* Maximum balance interval ms */
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 713715dd00cf..2b452d68ab2e 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -869,8 +869,8 @@ struct rq {
atomic_tnr_iowait;
#ifdef CONFIG_SMP
- struct root_domain *rd;
- struct sched_domain *sd;
+ struct root_domain *rd;
+ struct sched_domain __rcu *sd;
unsigned long cpu_capacity;
unsigned long cpu_capacity_orig;
@@ -1324,13 +1324,13 @@ static inline struct sched_domain
*lowest_flag_domain(int cpu, int flag)
return sd;
}
-DECLARE_PER_CPU(struct sched_domain *, sd_llc);
+DECLARE_PER_CPU(struct sched_domain __rcu *, sd_llc);
DECLARE_PER_CPU(int, sd_llc_size);
DECLARE_PER_CPU(int, sd_llc_id);
-DECLARE_PER_CPU(struct sched_domain_shared *, sd_llc_shared);
-DECLARE_PER_CPU(struct sched_domain *, sd_numa);
-DECLARE_PER_CPU(struct sched_domain *, sd_asym_packing);
[PATCH v2 0/4] RCU fixes for rcu_assign_pointer() usage
This is just a resend with scheduler patches split from the driver fixes and Paul's Reviewed-by(s) added. These patches fix various sparse errors ccaused as a result of the recent check to add rcu_check_sparse() to rcu_assign_pointer(). The errors are due to missing annotations. The annotations added in the series can also help avoid future incorrect usages and bugs so it is a good idea to do in any case. RFC v1 -> Patch v2: Made changes based on Peter Zijlstra review. Joel Fernandes (Google) (4): sched/cpufreq: Annotate cpufreq_update_util_data pointer with __rcu sched_domain: Annotate RCU pointers properly rcuwait: Annotate task_struct with __rcu sched: Annotate perf_domain pointer with __rcu include/linux/rcuwait.h| 2 +- include/linux/sched/topology.h | 4 ++-- kernel/sched/cpufreq.c | 2 +- kernel/sched/sched.h | 18 +- kernel/sched/topology.c| 10 +- 5 files changed, 18 insertions(+), 18 deletions(-) -- 2.21.0.225.g810b269d1ac-goog
Re: [PATCH V8 2/4] watchdog: imx_sc: Add i.MX system controller watchdog support
On 3/20/19 5:22 PM, Anson Huang wrote: Hi, Guenter Best Regards! Anson Huang -Original Message- From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter Roeck Sent: 2019年3月20日 21:44 To: Anson Huang Cc: w...@linux-watchdog.org; robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com; catalin.mari...@arm.com; will.dea...@arm.com; Aisheng Dong ; Daniel Baluta ; he...@sntech.de; horms+rene...@verge.net.au; Andy Gross ; maxime.rip...@bootlin.com; o...@lixom.net; bjorn.anders...@linaro.org; ja...@amarulasolutions.com; enric.balle...@collabora.com; ezequ...@collabora.com; stefan.wah...@i2se.com; marc.w.gonza...@free.fr; linux- watch...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org; dl-linux-imx Subject: Re: [PATCH V8 2/4] watchdog: imx_sc: Add i.MX system controller watchdog support On Fri, Mar 15, 2019 at 06:17:25AM +, Anson Huang wrote: i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller inside, the system controller is in charge of controlling power, clock and watchdog etc.. This patch adds i.MX system controller watchdog driver support, watchdog operation needs to be done in secure EL3 mode via ARM-Trusted-Firmware, using SMC call, CPU will trap into ARM-Trusted-Firmware and then it will request system controller to do watchdog operation via IPC. Signed-off-by: Anson Huang Reviewed-by: Guenter Roeck Waiting for bindings approval, though. Plus a minor comment below. Guenter --- Changes since V7: - remove the dependence of IMX_SCU as it does NOT call SCU API directly; - add more detail info into the help section of how this module works; - add back device id table since now we have watchdog node in DT. --- drivers/watchdog/Kconfig | 16 drivers/watchdog/Makefile | 1 + drivers/watchdog/imx_sc_wdt.c | 182 ++ 3 files changed, 199 insertions(+) create mode 100644 drivers/watchdog/imx_sc_wdt.c diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 242eea8..44a3158 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -641,6 +641,22 @@ config IMX2_WDT To compile this driver as a module, choose M here: the module will be called imx2_wdt. +config IMX_SC_WDT + tristate "IMX SC Watchdog" + depends on HAVE_ARM_SMCCC + select WATCHDOG_CORE + help + This is the driver for the system controller watchdog + on the NXP i.MX SoCs with system controller inside, the + watchdog driver will call ARM SMC API and trap into + ARM-Trusted-Firmware for operations, ARM-Trusted-Firmware + will request system controller to execute the operations. + If you have one of these processors and wish to have + watchdog support enabled, say Y, otherwise say N. + + To compile this driver as a module, choose M here: the + module will be called imx_sc_wdt. + config UX500_WATCHDOG tristate "ST-Ericsson Ux500 watchdog" depends on MFD_DB8500_PRCMU diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index ba930e4..136d9f0 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -68,6 +68,7 @@ obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o +obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o diff --git a/drivers/watchdog/imx_sc_wdt.c b/drivers/watchdog/imx_sc_wdt.c new file mode 100644 index 000..c8a087a --- /dev/null +++ b/drivers/watchdog/imx_sc_wdt.c @@ -0,0 +1,182 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright 2018-2019 NXP. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DEFAULT_TIMEOUT 60 +/* + * Software timer tick implemented in scfw side, support 10ms to +0x ms + * in theory, but for normal case, 1s~128s is enough, you can change +this max + * value in case it's not enough. + */ +#define MAX_TIMEOUT 128 + +#define IMX_SIP_TIMER 0xC202 +#define IMX_SIP_TIMER_START_WDOG 0x01 +#define IMX_SIP_TIMER_STOP_WDOG0x02 +#define IMX_SIP_TIMER_SET_WDOG_ACT 0x03 +#define IMX_SIP_TIMER_PING_WDOG0x04 +#define IMX_SIP_TIMER_SET_TIMEOUT_WDOG 0x05 +#define IMX_SIP_TIMER_GET_WDOG_STAT0x06 +#define IMX_SIP_TIMER_SET_PRETIME_WDOG 0x07 + +#define SC_TIMER_WDOG_ACTION_PARTITION 0 + +static bool nowayout = WATCHDOG_NOWAYOUT; module_param(nowayout, +bool, ); MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped +once started (default=" +
RE: [PATCH V8 2/4] watchdog: imx_sc: Add i.MX system controller watchdog support
Hi, Guenter Best Regards! Anson Huang > -Original Message- > From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter > Roeck > Sent: 2019年3月20日 21:44 > To: Anson Huang > Cc: w...@linux-watchdog.org; robh...@kernel.org; mark.rutl...@arm.com; > shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de; > feste...@gmail.com; catalin.mari...@arm.com; will.dea...@arm.com; > Aisheng Dong ; Daniel Baluta > ; he...@sntech.de; horms+rene...@verge.net.au; > Andy Gross ; maxime.rip...@bootlin.com; > o...@lixom.net; bjorn.anders...@linaro.org; ja...@amarulasolutions.com; > enric.balle...@collabora.com; ezequ...@collabora.com; > stefan.wah...@i2se.com; marc.w.gonza...@free.fr; linux- > watch...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; dl-linux-imx > > Subject: Re: [PATCH V8 2/4] watchdog: imx_sc: Add i.MX system controller > watchdog support > > On Fri, Mar 15, 2019 at 06:17:25AM +, Anson Huang wrote: > > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller > > inside, the system controller is in charge of controlling power, clock > > and watchdog etc.. > > > > This patch adds i.MX system controller watchdog driver support, > > watchdog operation needs to be done in secure EL3 mode via > > ARM-Trusted-Firmware, using SMC call, CPU will trap into > > ARM-Trusted-Firmware and then it will request system controller to do > > watchdog operation via IPC. > > > > Signed-off-by: Anson Huang > > Reviewed-by: Guenter Roeck > > Waiting for bindings approval, though. Plus a minor comment below. > > Guenter > > > --- > > Changes since V7: > > - remove the dependence of IMX_SCU as it does NOT call SCU API > directly; > > - add more detail info into the help section of how this module works; > > - add back device id table since now we have watchdog node in DT. > > --- > > drivers/watchdog/Kconfig | 16 > > drivers/watchdog/Makefile | 1 + > > drivers/watchdog/imx_sc_wdt.c | 182 > > ++ > > 3 files changed, 199 insertions(+) > > create mode 100644 drivers/watchdog/imx_sc_wdt.c > > > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index > > 242eea8..44a3158 100644 > > --- a/drivers/watchdog/Kconfig > > +++ b/drivers/watchdog/Kconfig > > @@ -641,6 +641,22 @@ config IMX2_WDT > > To compile this driver as a module, choose M here: the > > module will be called imx2_wdt. > > > > +config IMX_SC_WDT > > + tristate "IMX SC Watchdog" > > + depends on HAVE_ARM_SMCCC > > + select WATCHDOG_CORE > > + help > > + This is the driver for the system controller watchdog > > + on the NXP i.MX SoCs with system controller inside, the > > + watchdog driver will call ARM SMC API and trap into > > + ARM-Trusted-Firmware for operations, ARM-Trusted-Firmware > > + will request system controller to execute the operations. > > + If you have one of these processors and wish to have > > + watchdog support enabled, say Y, otherwise say N. > > + > > + To compile this driver as a module, choose M here: the > > + module will be called imx_sc_wdt. > > + > > config UX500_WATCHDOG > > tristate "ST-Ericsson Ux500 watchdog" > > depends on MFD_DB8500_PRCMU > > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > > index ba930e4..136d9f0 100644 > > --- a/drivers/watchdog/Makefile > > +++ b/drivers/watchdog/Makefile > > @@ -68,6 +68,7 @@ obj-$(CONFIG_NUC900_WATCHDOG) += > nuc900_wdt.o > > obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o > > obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o > > obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o > > +obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o > > obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o > > obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o > > obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o diff --git > > a/drivers/watchdog/imx_sc_wdt.c b/drivers/watchdog/imx_sc_wdt.c new > > file mode 100644 index 000..c8a087a > > --- /dev/null > > +++ b/drivers/watchdog/imx_sc_wdt.c > > @@ -0,0 +1,182 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright 2018-2019 NXP. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define DEFAULT_TIMEOUT 60 > > +/* > > + * Software timer tick implemented in scfw side, support 10ms to > > +0x ms > > + * in theory, but for normal case, 1s~128s is enough, you can change > > +this max > > + * value in case it's not enough. > > + */ > > +#define MAX_TIMEOUT 128 > > + > > +#define IMX_SIP_TIMER 0xC202 > > +#define IMX_SIP_TIMER_START_WDOG 0x01 > > +#define IMX_SIP_TIMER_STOP_WDOG0x02 > > +#define IMX_SIP_TIMER_SET_WDOG_ACT 0x03 > > +#define IMX_SIP_TIMER_PING_WDOG0x04 > > +#define IMX_SIP_TIMER_SET_TIMEOUT_WDOG 0x05 > >
RE: [PATCH v19,RESEND 24/27] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions
> On Wed, Mar 20, 2019 at 12:57:52PM -0700, Xing, Cedric wrote: > > > Using the untrusted stack as a way to exchange data is very > > > convenient, but that doesn't mean it's a good idea. Here are some > > > problems it > > > causes: > > > > > > - It prevents using a normal function to wrap enclave entry (as > > > we're seeing with this patch set). > > > > It doesn't prevent. > > Yes it does, keyword being "normal". Though I guess we could do a bit > of bikeshedding on the definition of normal... I don't understand what you mean by "normal". As I said, I tend to have a x86_64 ABI compliant version and by saying that I mean it'd be a 100% "normal" function callable from C. And the version I provided in this thread is a trimmed down version that doesn't preserve any registers except RSP/RBP so a C wrapper will be necessary. Other than that I'm not aware of any anomalies. Could you elaborate on what "abnormal" operations necessary to invoke this vDSO under what circumstances? And it'll be very helpful if you could present a "normal" function to demonstrate how your code could work with it while mine couldn't. > Actually, this series doesn't force anything on Intel's SDK, as there is > nothing in the documentation that states the vDSO *must* be used to > enter enclaves. In other words, unless it's expressly forbidden, > applications are free to enter enclaves directly and do as they wish > with the untrusted stack. The catch being that any such usage will need > to deal with enclave exceptions being delivered as signals, i.e. the > vDSO implementation is a carrot, not a stick. If you want to bike-shedding on *must*, well, no one *must* use *anything* from the *anyone*! But is that the expectation? Or if you don't expect your API to be used then what are you doing here? Intel SDK doesn't have to use this API. But we (the SDK team) are truly willing to use this API because we share the same concern with you over signals and would like to move to something better. > > AIUI, excepting libraries that want to manipulate the untrusted stack, > there is a general consensus that the proposed vDSO implementation is > the right approach, e.g. full x86_64 ABI compatibility was explored in > the past and was deemed to add unnecessary complexity and overhead. > > The vDSO *could* be written in such a way that it supports preserving > RBP or RSP, but for all intents and purposes such an implementation > would yield two distinct ABIs that just happen to be implemented in a > single function. > And *if* we want to deal with maintaining two ABIs, supporting the > kernel's existing signal ABI is a lot cleaner (from a kernel perspective) > than polluting the vDSO. Disagreed! What I'm proposing is one ABI - enclave preserves RBP! No requirements on RSP. Of course RSP is still interpreted as the line between vacant and used parts of the stack, or nothing will work regardless the proposal. The hosting process may have an agreement with the enclave to preserve RSP. But that would be completely between them, and would be just a coincidence instead of a consequence of the ABI from the perspective of this vDSO API. > > In other words, if there is a desire to support enclaves which modify > the untrusted stack, and it sounds like there is, then IMO our time is > better spent discussing whether or not to officially support the signal > ABI for enclaves. Disagreed! We share the same concern over signals so let's work this out! > > > > It assumes that the untrusted stack isn't further constrained by > > > various CFI mechanisms (e.g. CET), and, as of last time I checked, > > > the interaction between CET and SGX was still not specified. > > > > I was one of the architects participating in the CET ISA definition. > > The assembly provided was crafted with CET in mind and will be fully > > compatible with CET. > > > > > It also > > > assumes that the untrusted stack doesn't have ABI-imposed layout > > > restrictions related to unwinding, and, as far as I know, this means > > > that current enclaves with current enclave runtimes can interact > > > quite poorly with debuggers, exception handling, and various crash > > > dumping technologies. > > > > Per comments from the patch set, I guess it's been agreed that this > > vDSO function will NOT be x86_64 ABI compatible. So I'm not sure why > > stacking unwinding is relevant here. > > I think Andy's point is that a single PUSH (to save %rcx) won't break > unwinding, etc..., but unwinders and whantot will have a rough go of it > if %rsp points at complete garbage. The unwanders use CFI directives to determine frame pointers. RSP is the frame point by default but could be easily changed - e.g. by ".cfi_def_cfa_register %rbp". I could add proper CFI directives if so desired. I omitted them because you omitted them too in your code (in case you don't know, CFI directives are needed around push/pop %rcx in your code to stay compliant with ELF/DWARF spec),
Re: [PATCH] watchdog: alim7101: Mark expected switch fall-through
On 3/20/19 7:12 PM, Guenter Roeck wrote: > On 3/20/19 11:16 AM, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch >> cases where we are expecting to fall through. >> >> This patch fixes the following warning: >> >> drivers/watchdog/alim7101_wdt.c: In function ‘fop_ioctl’: >> drivers/watchdog/alim7101_wdt.c:279:3: warning: this statement may fall >> through [-Wimplicit-fallthrough=] >> wdt_keepalive(); >> ^~~ >> drivers/watchdog/alim7101_wdt.c:282:2: note: here >> case WDIOC_GETTIMEOUT: >> ^~~~ >> >> Notice that, in this particular case, the /* Fall through */ >> comment is placed at the very bottom of the case statement, >> which is what GCC is expecting to find. >> >> Warning level 3 was used: -Wimplicit-fallthrough=3 >> >> This patch is part of the ongoing efforts to enabling >> -Wimplicit-fallthrough. >> >> Signed-off-by: Gustavo A. R. Silva > > Reviewed-by: Guenter Roeck > Thanks, Guenter. :) -- Gustavo >> --- >> drivers/watchdog/alim7101_wdt.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/watchdog/alim7101_wdt.c >> b/drivers/watchdog/alim7101_wdt.c >> index 12f7ea62..f5ada07e9202 100644 >> --- a/drivers/watchdog/alim7101_wdt.c >> +++ b/drivers/watchdog/alim7101_wdt.c >> @@ -277,8 +277,8 @@ static long fop_ioctl(struct file *file, unsigned int >> cmd, unsigned long arg) >> return -EINVAL; >> timeout = new_timeout; >> wdt_keepalive(); >> - /* Fall through */ >> } >> + /* Fall through */ >> case WDIOC_GETTIMEOUT: >> return put_user(timeout, p); >> default: >> >
[PATCH v5 4/5] dt-bindings: display: rockchip: add document for rk3066 hdmi
This patch adds a binding that describes the HDMI controller for
rk3066.
Signed-off-by: Johan Jonker
Reviewed-by: Rob Herring
---
.../display/rockchip/rockchip,rk3066-hdmi.txt | 72 ++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
new file mode 100644
index 0..d1ad31bca
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
@@ -0,0 +1,72 @@
+Rockchip specific extensions for rk3066 HDMI
+
+
+Required properties:
+- compatible:
+ "rockchip,rk3066-hdmi";
+- reg:
+ Physical base address and length of the controller's registers.
+- clocks, clock-names:
+ Phandle to HDMI controller clock, name should be "hclk".
+- interrupts:
+ HDMI interrupt number.
+- power-domains:
+ Phandle to the RK3066_PD_VIO power domain.
+- rockchip,grf:
+ This soc uses GRF regs to switch the HDMI TX input between vop0 and
vop1.
+- ports:
+ Contains one port node with two endpoints, numbered 0 and 1,
+ connected respectively to vop0 and vop1.
+ Contains one port node with one endpoint
+ connected to a hdmi-connector node.
+- pinctrl-0, pinctrl-name:
+ Switch the iomux for the HPD/I2C pins to HDMI function.
+
+Example:
+ hdmi: hdmi@10116000 {
+ compatible = "rockchip,rk3066-hdmi";
+ reg = <0x10116000 0x2000>;
+ interrupts = ;
+ clocks = < HCLK_HDMI>;
+ clock-names = "hclk";
+ power-domains = < RK3066_PD_VIO>;
+ rockchip,grf = <>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_xfer>, <_hpd>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_vop0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_out_hdmi>;
+ };
+ hdmi_in_vop1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_out_hdmi>;
+ };
+ };
+ hdmi_out: port@1 {
+ reg = <1>;
+ hdmi_out_con: endpoint {
+ remote-endpoint = <_con_in>;
+ };
+ };
+ };
+ };
+
+ {
+ hdmi {
+ hdmi_hpd: hdmi-hpd {
+ rockchip,pins = <0 RK_PA0 1 _pull_default>;
+ };
+ hdmii2c_xfer: hdmii2c-xfer {
+ rockchip,pins = <0 RK_PA1 1 _pull_none>,
+ <0 RK_PA2 1 _pull_none>;
+ };
+ };
+};
--
2.11.0
Re: [PATCH] watchdog: alim7101: Mark expected switch fall-through
On 3/20/19 11:16 AM, Gustavo A. R. Silva wrote: In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/watchdog/alim7101_wdt.c: In function ‘fop_ioctl’: drivers/watchdog/alim7101_wdt.c:279:3: warning: this statement may fall through [-Wimplicit-fallthrough=] wdt_keepalive(); ^~~ drivers/watchdog/alim7101_wdt.c:282:2: note: here case WDIOC_GETTIMEOUT: ^~~~ Notice that, in this particular case, the /* Fall through */ comment is placed at the very bottom of the case statement, which is what GCC is expecting to find. Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva Reviewed-by: Guenter Roeck --- drivers/watchdog/alim7101_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/alim7101_wdt.c b/drivers/watchdog/alim7101_wdt.c index 12f7ea62..f5ada07e9202 100644 --- a/drivers/watchdog/alim7101_wdt.c +++ b/drivers/watchdog/alim7101_wdt.c @@ -277,8 +277,8 @@ static long fop_ioctl(struct file *file, unsigned int cmd, unsigned long arg) return -EINVAL; timeout = new_timeout; wdt_keepalive(); - /* Fall through */ } + /* Fall through */ case WDIOC_GETTIMEOUT: return put_user(timeout, p); default:
Re: [PATCH] irqchip: plic: Fix priority base offset
On Wed, Mar 20, 2019 at 4:49 PM Christoph Hellwig wrote: > > On Wed, Mar 20, 2019 at 10:39:52PM +, Alistair Francis wrote: > > According to the FU540 and E31 manuals the PLIC source priority > > address starts at an offset of 0x04 and not 0x00. To aviod confusion > > update the address and source offset to match the documentation. This > > causes no difference in functionality. > > Well, it starts at 0x00, but the first one is reserved. If you think > that is too confusing I'd rather throw in a comment explaining this > fact rather than making the calculating more complicated. It doesn't mention that it starts at 0 when you look here: https://sifive.cdn.prismic.io/sifive%2F834354f0-08e6-423c-bf1f-0cb58ef14061_fu540-c000-v1.0.pdf (pg. 61). I agree that it's the same as starting as 0 and reserving the first one, but this means that the macros are actually at the wrong address and we need to remember not to use 0. This ends up forgotten and I have seen bugs in OpenSBI and QEMU as they have a similar implementation. It's possible some future code update will forget this as well. I think it's much clearer to define the correct values and just subtract 1, the calculation really isn't more complicated. Alistair
[PATCH] ALSA: seq: oss: Fix Spectre v1 vulnerability
dev is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn:
potential spectre issue 'dp->synths' [w] (local cap)
Fix this by sanitizing dev before using it to index dp->synths.
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://lore.kernel.org/lkml/20180423164740.gy17...@dhcp22.suse.cz/
Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva
---
sound/core/seq/oss/seq_oss_synth.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/core/seq/oss/seq_oss_synth.c
b/sound/core/seq/oss/seq_oss_synth.c
index 278ebb993122..c93945917235 100644
--- a/sound/core/seq/oss/seq_oss_synth.c
+++ b/sound/core/seq/oss/seq_oss_synth.c
@@ -617,13 +617,14 @@ int
snd_seq_oss_synth_make_info(struct seq_oss_devinfo *dp, int dev, struct
synth_info *inf)
{
struct seq_oss_synth *rec;
+ struct seq_oss_synthinfo *info = get_synthinfo_nospec(dp, dev);
- if (dev < 0 || dev >= dp->max_synthdev)
+ if (!info)
return -ENXIO;
- if (dp->synths[dev].is_midi) {
+ if (info->is_midi) {
struct midi_info minf;
- snd_seq_oss_midi_make_info(dp, dp->synths[dev].midi_mapped,
);
+ snd_seq_oss_midi_make_info(dp, info->midi_mapped, );
inf->synth_type = SYNTH_TYPE_MIDI;
inf->synth_subtype = 0;
inf->nr_voices = 16;
--
2.21.0
[PATCH] PM / arch: x86: Rework the MSR_IA32_ENERGY_PERF_BIAS handling
From: Rafael J. Wysocki
The current handling of MSR_IA32_ENERGY_PERF_BIAS in the kernel is
problematic, because it may cause changes made by user space to that
MSR (with the help of the x86_energy_perf_policy tool, for example)
to be lost every time a CPU goes offline and then back online as well
as during system-wide power management transitions into sleep states
and back into the working state.
The first problem is that if the current EPB value for a CPU going
online is 0 ('performance'), the kernel will change it to 6 ('normal')
regardless of whether or not this is the first bring-up of that CPU.
That also happens during system-wide resume from sleep states
(including, but not limited to, hibernation). However, the EPB may
have been adjusted by user space this way and the kernel should not
blindly override that setting.
The second problem is that if the platform firmware resets the EPB
values for any CPUs during system-wide resume from a sleep state,
the kernel will not restore their previous EPB values that may
have been set by user space before the preceding system-wide
suspend transition. Again, that behavior may at least be confusing
from the user space perspective.
In order to address these issues, rework the handling of
MSR_IA32_ENERGY_PERF_BIAS so that the EPB value is saved on CPU
offline and restored on CPU online as well as (for the boot CPU)
during the syscore stages of system-wide suspend and resume
transitions, respectively.
However, retain the policy by which the EPB is set to 6 ('normal')
on the first bring-up of each CPU if its initial value is 0, based
on the observation that 0 may mean 'not initialized' just as well as
'performance' in that case.
While at it, move the MSR_IA32_ENERGY_PERF_BIAS handling code into
a separate file and document it in Documentation/admin-guide.
Fixes: abe48b108247 (x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS)
Fixes: b51ef52df71c (x86/cpu: Restore MSR_IA32_ENERGY_PERF_BIAS after resume)
Reported-by: Thomas Renninger
Signed-off-by: Rafael J. Wysocki
---
I do realize that this may be regarded as overly conservative, but
I'm quite reluctant to change the policy choice made in 2011 and
present since then without rock solid evidence that it would not
introduce regressions anywhere.
---
Documentation/admin-guide/pm/intel_epb.rst |6 +
Documentation/admin-guide/pm/working-state.rst |1
arch/x86/kernel/cpu/Makefile |2
arch/x86/kernel/cpu/common.c | 17 ---
arch/x86/kernel/cpu/cpu.h |1
arch/x86/kernel/cpu/intel.c| 34 --
arch/x86/kernel/cpu/intel_epb.c| 131 +
include/linux/cpuhotplug.h |1
8 files changed, 140 insertions(+), 53 deletions(-)
Index: linux-pm/include/linux/cpuhotplug.h
===
--- linux-pm.orig/include/linux/cpuhotplug.h
+++ linux-pm/include/linux/cpuhotplug.h
@@ -147,6 +147,7 @@ enum cpuhp_state {
CPUHP_AP_X86_VDSO_VMA_ONLINE,
CPUHP_AP_IRQ_AFFINITY_ONLINE,
CPUHP_AP_ARM_MVEBU_SYNC_CLOCKS,
+ CPUHP_AP_X86_INTEL_EPB_ONLINE,
CPUHP_AP_PERF_ONLINE,
CPUHP_AP_PERF_X86_ONLINE,
CPUHP_AP_PERF_X86_UNCORE_ONLINE,
Index: linux-pm/arch/x86/kernel/cpu/intel.c
===
--- linux-pm.orig/arch/x86/kernel/cpu/intel.c
+++ linux-pm/arch/x86/kernel/cpu/intel.c
@@ -596,36 +596,6 @@ detect_keyid_bits:
c->x86_phys_bits -= keyid_bits;
}
-static void init_intel_energy_perf(struct cpuinfo_x86 *c)
-{
- u64 epb;
-
- /*
-* Initialize MSR_IA32_ENERGY_PERF_BIAS if not already initialized.
-* (x86_energy_perf_policy(8) is available to change it at run-time.)
-*/
- if (!cpu_has(c, X86_FEATURE_EPB))
- return;
-
- rdmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
- if ((epb & 0xF) != ENERGY_PERF_BIAS_PERFORMANCE)
- return;
-
- pr_warn_once("ENERGY_PERF_BIAS: Set to 'normal', was 'performance'\n");
- pr_warn_once("ENERGY_PERF_BIAS: View and update with
x86_energy_perf_policy(8)\n");
- epb = (epb & ~0xF) | ENERGY_PERF_BIAS_NORMAL;
- wrmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
-}
-
-static void intel_bsp_resume(struct cpuinfo_x86 *c)
-{
- /*
-* MSR_IA32_ENERGY_PERF_BIAS is lost across suspend/resume,
-* so reinitialize it properly like during bootup:
-*/
- init_intel_energy_perf(c);
-}
-
static void init_cpuid_fault(struct cpuinfo_x86 *c)
{
u64 msr;
@@ -763,8 +733,6 @@ static void init_intel(struct cpuinfo_x8
if (cpu_has(c, X86_FEATURE_TME))
detect_tme(c);
- init_intel_energy_perf(c);
-
init_intel_misc_features(c);
}
@@ -1023,9 +991,7 @@ static const struct cpu_dev intel_cpu_de
.c_detect_tlb = intel_detect_tlb,
[RFT/RFC PATCH v3 5/5] RISC-V: Parse cpu topology during boot.
Currently, there are no topology defined for RISC-V.
Parse the cpu-map node from device tree and setup the
cpu topology.
CPU topology after applying the patch.
$cat /sys/devices/system/cpu/cpu2/topology/core_siblings_list
0-3
$cat /sys/devices/system/cpu/cpu3/topology/core_siblings_list
0-3
$cat /sys/devices/system/cpu/cpu3/topology/physical_package_id
0
$cat /sys/devices/system/cpu/cpu3/topology/core_id
3
Signed-off-by: Atish Patra
---
arch/riscv/Kconfig | 1 +
arch/riscv/kernel/smpboot.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index eb56c82d..ac87a0ec 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -47,6 +47,7 @@ config RISCV
select PCI_MSI if PCI
select RISCV_TIMER
select GENERIC_IRQ_MULTI_HANDLER
+ select GENERIC_ARCH_TOPOLOGY if SMP
select ARCH_HAS_PTE_SPECIAL
select HAVE_EBPF_JIT if 64BIT
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index f41eb193..a8fe590c 100644
--- a/arch/riscv/kernel/smpboot.c
+++ b/arch/riscv/kernel/smpboot.c
@@ -16,6 +16,7 @@
* GNU General Public License for more details.
*/
+#include
#include
#include
#include
@@ -43,6 +44,7 @@ static DECLARE_COMPLETION(cpu_running);
void __init smp_prepare_boot_cpu(void)
{
+ init_cpu_topology();
}
void __init smp_prepare_cpus(unsigned int max_cpus)
@@ -146,6 +148,7 @@ asmlinkage void __init smp_callin(void)
trap_init();
notify_cpu_starting(smp_processor_id());
+ update_siblings_masks(smp_processor_id());
set_cpu_online(smp_processor_id(), 1);
/*
* Remote TLB flushes are ignored while the CPU is offline, so emit
--
2.21.0
[RFT/RFC PATCH v3 2/5] dt-binding: cpu-topology: Move cpu-map to a common binding.
cpu-map binding can be used to described cpu topology for both
RISC-V & ARM. It makes more sense to move the binding to document
to a common place.
The relevant discussion can be found here.
https://lkml.org/lkml/2018/11/6/19
Signed-off-by: Atish Patra
Reviewed-by: Sudeep Holla
---
.../topology.txt => cpu/cpu-topology.txt} | 82 +++
1 file changed, 66 insertions(+), 16 deletions(-)
rename Documentation/devicetree/bindings/{arm/topology.txt =>
cpu/cpu-topology.txt} (86%)
diff --git a/Documentation/devicetree/bindings/arm/topology.txt
b/Documentation/devicetree/bindings/cpu/cpu-topology.txt
similarity index 86%
rename from Documentation/devicetree/bindings/arm/topology.txt
rename to Documentation/devicetree/bindings/cpu/cpu-topology.txt
index 3b8febb4..069addcc 100644
--- a/Documentation/devicetree/bindings/arm/topology.txt
+++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt
@@ -1,12 +1,12 @@
===
-ARM topology binding description
+CPU topology binding description
===
===
1 - Introduction
===
-In an ARM system, the hierarchy of CPUs is defined through three entities that
+In a SMP system, the hierarchy of CPUs is defined through three entities that
are used to describe the layout of physical CPUs in the system:
- socket
@@ -14,9 +14,6 @@ are used to describe the layout of physical CPUs in the
system:
- core
- thread
-The cpu nodes (bindings defined in [1]) represent the devices that
-correspond to physical CPUs and are to be mapped to the hierarchy levels.
-
The bottom hierarchy level sits at core or thread level depending on whether
symmetric multi-threading (SMT) is supported or not.
@@ -25,33 +22,31 @@ threads existing in the system and map to the hierarchy
level "thread" above.
In systems where SMT is not supported "cpu" nodes represent all cores present
in the system and map to the hierarchy level "core" above.
-ARM topology bindings allow one to associate cpu nodes with hierarchical groups
+CPU topology bindings allow one to associate cpu nodes with hierarchical groups
corresponding to the system hierarchy; syntactically they are defined as device
tree nodes.
-The remainder of this document provides the topology bindings for ARM, based
-on the Devicetree Specification, available from:
+Currently, only ARM/RISC-V intend to use this cpu topology binding but it may
be
+used for any other architecture as well.
-https://www.devicetree.org/specifications/
+The cpu nodes, as per bindings defined in [4], represent the devices that
+correspond to physical CPUs and are to be mapped to the hierarchy levels.
-If not stated otherwise, whenever a reference to a cpu node phandle is made its
-value must point to a cpu node compliant with the cpu node bindings as
-documented in [1].
A topology description containing phandles to cpu nodes that are not compliant
-with bindings standardized in [1] is therefore considered invalid.
+with bindings standardized in [4] is therefore considered invalid.
===
2 - cpu-map node
===
-The ARM CPU topology is defined within the cpu-map node, which is a direct
+The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a
direct
child of the cpus node and provides a container where the actual topology
nodes are listed.
- cpu-map node
- Usage: Optional - On ARM SMP systems provide CPUs topology to the OS.
- ARM uniprocessor systems do not require a topology
+ Usage: Optional - On SMP systems provide CPUs topology to the OS.
+ Uniprocessor systems do not require a topology
description and therefore should not define a
cpu-map node.
@@ -494,8 +489,63 @@ cpus {
};
};
+Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system)
+
+{
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "sifive,fu540g", "sifive,fu500";
+ model = "sifive,hifive-unleashed-a00";
+
+ ...
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <>;
+ };
+ core1 {
+ cpu = <>;
+ };
+ core2 {
+ cpu0 = <>;
+ };
+ core3 {
+ cpu0 = <>;
+ };
+ };
+ };
+
+ CPU1: cpu@1 {
+
[RFT/RFC PATCH v3 1/5] Documentation: DT: arm: add support for sockets defining package boundaries
From: Sudeep Holla
The current ARM DT topology description provides the operating system
with a topological view of the system that is based on leaf nodes
representing either cores or threads (in an SMT system) and a
hierarchical set of cluster nodes that creates a hierarchical topology
view of how those cores and threads are grouped.
However this hierarchical representation of clusters does not allow to
describe what topology level actually represents the physical package or
the socket boundary, which is a key piece of information to be used by
an operating system to optimize resource allocation and scheduling.
Lets add a new "socket" node type in the cpu-map node to describe the
same.
Signed-off-by: Sudeep Holla
Reviewed-by: Rob Herring
---
.../devicetree/bindings/arm/topology.txt | 52 ++-
1 file changed, 39 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/topology.txt
b/Documentation/devicetree/bindings/arm/topology.txt
index b0d80c0f..3b8febb4 100644
--- a/Documentation/devicetree/bindings/arm/topology.txt
+++ b/Documentation/devicetree/bindings/arm/topology.txt
@@ -9,6 +9,7 @@ ARM topology binding description
In an ARM system, the hierarchy of CPUs is defined through three entities that
are used to describe the layout of physical CPUs in the system:
+- socket
- cluster
- core
- thread
@@ -63,21 +64,23 @@ nodes are listed.
The cpu-map node's child nodes can be:
- - one or more cluster nodes
+ - one or more cluster nodes or
+ - one or more socket nodes in a multi-socket system
Any other configuration is considered invalid.
-The cpu-map node can only contain three types of child nodes:
+The cpu-map node can only contain 4 types of child nodes:
+- socket node
- cluster node
- core node
- thread node
whose bindings are described in paragraph 3.
-The nodes describing the CPU topology (cluster/core/thread) can only
-be defined within the cpu-map node and every core/thread in the system
-must be defined within the topology. Any other configuration is
+The nodes describing the CPU topology (socket/cluster/core/thread) can
+only be defined within the cpu-map node and every core/thread in the
+system must be defined within the topology. Any other configuration is
invalid and therefore must be ignored.
===
@@ -85,26 +88,44 @@ invalid and therefore must be ignored.
===
cpu-map child nodes must follow a naming convention where the node name
-must be "clusterN", "coreN", "threadN" depending on the node type (ie
-cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
-are siblings within a single common parent node must be given a unique and
+must be "socketN", "clusterN", "coreN", "threadN" depending on the node type
+(ie socket/cluster/core/thread) (where N = {0, 1, ...} is the node number;
nodes
+which are siblings within a single common parent node must be given a unique
and
sequential N value, starting from 0).
cpu-map child nodes which do not share a common parent node can have the same
name (ie same number N as other cpu-map child nodes at different device tree
levels) since name uniqueness will be guaranteed by the device tree hierarchy.
===
-3 - cluster/core/thread node bindings
+3 - socket/cluster/core/thread node bindings
===
-Bindings for cluster/cpu/thread nodes are defined as follows:
+Bindings for socket/cluster/cpu/thread nodes are defined as follows:
+
+- socket node
+
+Description: must be declared within a cpu-map node, one node
+ per physical socket in the system. A system can
+ contain single or multiple physical socket.
+ The association of sockets and NUMA nodes is beyond
+ the scope of this bindings, please refer [2] for
+ NUMA bindings.
+
+ This node is optional for a single socket system.
+
+ The socket node name must be "socketN" as described in 2.1 above.
+ A socket node can not be a leaf node.
+
+ A socket node's child nodes must be one or more cluster nodes.
+
+ Any other configuration is considered invalid.
- cluster node
Description: must be declared within a cpu-map node, one node
per cluster. A system can contain several layers of
- clustering and cluster nodes can be contained in parent
- cluster nodes.
+ clustering within a single physical socket and cluster
+ nodes can be contained in parent cluster nodes.
The cluster node name must be "clusterN" as described in 2.1 above.
A cluster node can not be a leaf node.
@@ -164,13 +185,15 @@ Bindings for cluster/cpu/thread nodes are defined as
Re: [PATCH] irqchip: plic: Fix priority base offset
On Wed, Mar 20, 2019 at 10:39:52PM +, Alistair Francis wrote: > According to the FU540 and E31 manuals the PLIC source priority > address starts at an offset of 0x04 and not 0x00. To aviod confusion > update the address and source offset to match the documentation. This > causes no difference in functionality. Well, it starts at 0x00, but the first one is reserved. If you think that is too confusing I'd rather throw in a comment explaining this fact rather than making the calculating more complicated.
[RFT/RFC PATCH v3 4/5] arm: Use common cpu_topology
Currently, ARM32 and ARM64 uses different data structures to
represent their cpu toplogies. Since, we are moving the ARM64
topology to common code to be used by other architectures, we
can reuse that for ARM32 as well.
Signed-off-by: Atish Patra
---
arch/arm/include/asm/topology.h | 22 +-
arch/arm/kernel/topology.c | 10 +-
include/linux/arch_topology.h | 10 +-
3 files changed, 15 insertions(+), 27 deletions(-)
diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index 2a786f54..52f99ec8 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -5,26 +5,6 @@
#ifdef CONFIG_ARM_CPU_TOPOLOGY
#include
-
-struct cputopo_arm {
- int thread_id;
- int core_id;
- int socket_id;
- cpumask_t thread_sibling;
- cpumask_t core_sibling;
-};
-
-extern struct cputopo_arm cpu_topology[NR_CPUS];
-
-#define topology_physical_package_id(cpu) (cpu_topology[cpu].socket_id)
-#define topology_core_id(cpu) (cpu_topology[cpu].core_id)
-#define topology_core_cpumask(cpu) (_topology[cpu].core_sibling)
-#define topology_sibling_cpumask(cpu) (_topology[cpu].thread_sibling)
-
-void init_cpu_topology(void);
-void store_cpu_topology(unsigned int cpuid);
-const struct cpumask *cpu_coregroup_mask(int cpu);
-
#include
/* Replace task scheduler's default frequency-invariant accounting */
@@ -38,7 +18,7 @@ const struct cpumask *cpu_coregroup_mask(int cpu);
#else
-static inline void init_cpu_topology(void) { }
+static inline void init_cpu_topology(void) {}
static inline void store_cpu_topology(unsigned int cpuid) { }
#endif
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 60e375ce..0ddb24c7 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -180,7 +180,7 @@ static inline void update_cpu_capacity(unsigned int cpuid)
{}
/*
* cpu topology table
*/
-struct cputopo_arm cpu_topology[NR_CPUS];
+struct cpu_topology cpu_topology[NR_CPUS];
EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
@@ -197,9 +197,9 @@ const struct cpumask *cpu_corepower_mask(int cpu)
return _topology[cpu].thread_sibling;
}
-static void update_siblings_masks(unsigned int cpuid)
+void update_siblings_masks(unsigned int cpuid)
{
- struct cputopo_arm *cpu_topo, *cpuid_topo = _topology[cpuid];
+ struct cpu_topology *cpu_topo, *cpuid_topo = _topology[cpuid];
int cpu;
/* update core and thread sibling masks */
@@ -230,7 +230,7 @@ static void update_siblings_masks(unsigned int cpuid)
*/
void store_cpu_topology(unsigned int cpuid)
{
- struct cputopo_arm *cpuid_topo = _topology[cpuid];
+ struct cpu_topology *cpuid_topo = _topology[cpuid];
unsigned int mpidr;
/* If the cpu topology has been already set, just return */
@@ -302,7 +302,7 @@ void __init init_cpu_topology(void)
/* init core mask and capacity */
for_each_possible_cpu(cpu) {
- struct cputopo_arm *cpu_topo = &(cpu_topology[cpu]);
+ struct cpu_topology *cpu_topo = &(cpu_topology[cpu]);
cpu_topo->thread_id = -1;
cpu_topo->core_id = -1;
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index d4e76e0a..7c850611 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -36,17 +36,25 @@ unsigned long topology_get_freq_scale(int cpu)
struct cpu_topology {
int thread_id;
int core_id;
+#ifdef CONFIG_ARM_CPU_TOPOLOGY
+ int socket_id;
+#else
int package_id;
int llc_id;
+ cpumask_t llc_sibling;
+#endif
cpumask_t thread_sibling;
cpumask_t core_sibling;
- cpumask_t llc_sibling;
};
#ifdef CONFIG_GENERIC_ARCH_TOPOLOGY
extern struct cpu_topology cpu_topology[NR_CPUS];
+#ifdef CONFIG_ARM_CPU_TOPOLOGY
+#define topology_physical_package_id(cpu) (cpu_topology[cpu].socket_id)
+#else
#define topology_physical_package_id(cpu) (cpu_topology[cpu].package_id)
+#endif
#define topology_core_id(cpu) (cpu_topology[cpu].core_id)
#define topology_core_cpumask(cpu) (_topology[cpu].core_sibling)
#define topology_sibling_cpumask(cpu) (_topology[cpu].thread_sibling)
--
2.21.0
[RFT/RFC PATCH v3 3/5] cpu-topology: Move cpu topology code to common code.
Both RISC-V & ARM64 are using cpu-map device tree to describe
their cpu topology. It's better to move the relevant code to
a common place instead of duplicate code.
Signed-off-by: Atish Patra
Tested-by: Jeffrey Hugo
---
arch/arm64/include/asm/topology.h | 23 ---
arch/arm64/kernel/topology.c | 303 +-
drivers/base/arch_topology.c | 298 -
drivers/base/topology.c | 1 +
include/linux/arch_topology.h | 28 +++
5 files changed, 330 insertions(+), 323 deletions(-)
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index 0524f243..a4d945db 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -4,29 +4,6 @@
#include
-struct cpu_topology {
- int thread_id;
- int core_id;
- int package_id;
- int llc_id;
- cpumask_t thread_sibling;
- cpumask_t core_sibling;
- cpumask_t llc_sibling;
-};
-
-extern struct cpu_topology cpu_topology[NR_CPUS];
-
-#define topology_physical_package_id(cpu) (cpu_topology[cpu].package_id)
-#define topology_core_id(cpu) (cpu_topology[cpu].core_id)
-#define topology_core_cpumask(cpu) (_topology[cpu].core_sibling)
-#define topology_sibling_cpumask(cpu) (_topology[cpu].thread_sibling)
-#define topology_llc_cpumask(cpu) (_topology[cpu].llc_sibling)
-
-void init_cpu_topology(void);
-void store_cpu_topology(unsigned int cpuid);
-void remove_cpu_topology(unsigned int cpuid);
-const struct cpumask *cpu_coregroup_mask(int cpu);
-
#ifdef CONFIG_NUMA
struct pci_bus;
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 0825c4a8..6b95c91e 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -14,250 +14,13 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
#include
#include
-static int __init get_cpu_for_node(struct device_node *node)
-{
- struct device_node *cpu_node;
- int cpu;
-
- cpu_node = of_parse_phandle(node, "cpu", 0);
- if (!cpu_node)
- return -1;
-
- cpu = of_cpu_node_to_id(cpu_node);
- if (cpu >= 0)
- topology_parse_cpu_capacity(cpu_node, cpu);
- else
- pr_crit("Unable to find CPU node for %pOF\n", cpu_node);
-
- of_node_put(cpu_node);
- return cpu;
-}
-
-static int __init parse_core(struct device_node *core, int package_id,
-int core_id)
-{
- char name[10];
- bool leaf = true;
- int i = 0;
- int cpu;
- struct device_node *t;
-
- do {
- snprintf(name, sizeof(name), "thread%d", i);
- t = of_get_child_by_name(core, name);
- if (t) {
- leaf = false;
- cpu = get_cpu_for_node(t);
- if (cpu >= 0) {
- cpu_topology[cpu].package_id = package_id;
- cpu_topology[cpu].core_id = core_id;
- cpu_topology[cpu].thread_id = i;
- } else {
- pr_err("%pOF: Can't get CPU for thread\n",
- t);
- of_node_put(t);
- return -EINVAL;
- }
- of_node_put(t);
- }
- i++;
- } while (t);
-
- cpu = get_cpu_for_node(core);
- if (cpu >= 0) {
- if (!leaf) {
- pr_err("%pOF: Core has both threads and CPU\n",
- core);
- return -EINVAL;
- }
-
- cpu_topology[cpu].package_id = package_id;
- cpu_topology[cpu].core_id = core_id;
- } else if (leaf) {
- pr_err("%pOF: Can't get CPU for leaf core\n", core);
- return -EINVAL;
- }
-
- return 0;
-}
-
-static int __init parse_cluster(struct device_node *cluster, int depth)
-{
- char name[10];
- bool leaf = true;
- bool has_cores = false;
- struct device_node *c;
- static int package_id __initdata;
- int core_id = 0;
- int i, ret;
-
- /*
-* First check for child clusters; we currently ignore any
-* information about the nesting of clusters and present the
-* scheduler with a flat list of them.
-*/
- i = 0;
- do {
- snprintf(name, sizeof(name), "cluster%d", i);
- c = of_get_child_by_name(cluster, name);
- if (c) {
- leaf = false;
- ret = parse_cluster(c, depth + 1);
- of_node_put(c);
- if (ret != 0)
-
[RFT/RFC PATCH v3 0/5] Unify CPU topology across ARM & RISC-V
The cpu-map DT entry in ARM can describe the CPU topology in much better
way compared to other existing approaches. RISC-V can easily adopt this
binding to represent its own CPU topology. Thus, both cpu-map DT
binding and topology parsing code can be moved to a common location so
that RISC-V or any other architecture can leverage that.
The relevant discussion regarding unifying cpu topology can be found in
[1].
arch_topology seems to be a perfect place to move the common code. I
have not introduced any significant functional changes in the moved code.
The only downside in this approach is that the capacity code will be
executed for RISC-V as well. But, it will exit immediately after not
able to find the appropriate DT node. If the overhead is considered too
much, we can always compile out capacity related functions under a
different config for the architectures that do not support them.
There was an opportunity to unify topology data structure for ARM32 done
by patch 3/4. But, I refrained from making any other changes as I am not
very well versed with original intention for some functions that
are present in arch_topology.c. I hope this patch series can be served
as a baseline for such changes in the future.
The patches have been tested for RISC-V and compile tested for ARM64,
ARM32 & x86.
The socket change[2] is also now part of this series.
[1] https://lkml.org/lkml/2018/11/6/19
[2] https://lkml.org/lkml/2018/11/7/918
QEMU changes for RISC-V topology are available at
https://github.com/atishp04/qemu/tree/riscv_topology_dt
HiFive Unleashed DT with topology node is available here.
https://github.com/atishp04/opensbi/tree/HiFive_unleashed_topology
It can be verified with OpenSBI with following additional compile time
option.
FW_PAYLOAD_FDT="unleashed_topology.dtb"
Changes from v2->v3
1. Cover letter update with experiment DT for topology changes.
2. Added the patch for [2].
Changes from v1->v2
1. ARM32 can now use the common code as well.
Atish Patra (4):
dt-binding: cpu-topology: Move cpu-map to a common binding.
cpu-topology: Move cpu topology code to common code.
arm: Use common cpu_topology
RISC-V: Parse cpu topology during boot.
Sudeep Holla (1):
Documentation: DT: arm: add support for sockets defining package
boundaries
.../topology.txt => cpu/cpu-topology.txt} | 134 ++--
arch/arm/include/asm/topology.h | 22 +-
arch/arm/kernel/topology.c| 10 +-
arch/arm64/include/asm/topology.h | 23 --
arch/arm64/kernel/topology.c | 303 +-
arch/riscv/Kconfig| 1 +
arch/riscv/kernel/smpboot.c | 3 +
drivers/base/arch_topology.c | 298 -
drivers/base/topology.c | 1 +
include/linux/arch_topology.h | 36 +++
10 files changed, 453 insertions(+), 378 deletions(-)
rename Documentation/devicetree/bindings/{arm/topology.txt =>
cpu/cpu-topology.txt} (66%)
--
2.21.0
Re: [PATCH v3] rcu: Allow to eliminate softirq processing from rcutree
On Wed, Mar 20, 2019 at 10:13:33PM +0100, Sebastian Andrzej Siewior wrote:
> Running RCU out of softirq is a problem for some workloads that would
> like to manage RCU core processing independently of other softirq
> work, for example, setting kthread priority. This commit therefore
> introduces the `rcunosoftirq' option which moves the RCU core work
> from softirq to a per-CPU/per-flavor SCHED_OTHER kthread named rcuc.
> The SCHED_OTHER approach avoids the scalability problems that appeared
> with the earlier attempt to move RCU core processing to from softirq
> to kthreads. That said, kernels built with RCU_BOOST=y will run the
> rcuc kthreads at the RCU-boosting priority.
>
> Reported-by: Thomas Gleixner
> Tested-by: Mike Galbraith
> Signed-off-by: Sebastian Andrzej Siewior
Thank you! I reverted v2 and applied this one with the same sort of
update. Testing is going well thus far aside from my failing to add
the required "=0" after the rcutree.use_softirq. I will probably not
be the only one who will run afoul of this, so I updated the commit log
and the documentation accordingly, as shown below.
Thanx, Paul
commit 5971694b716d34baa86f3f1dd44f8e587a17d8f0
Author: Sebastian Andrzej Siewior
Date: Wed Mar 20 22:13:33 2019 +0100
rcu: Enable elimination of Tree-RCU softirq processing
Some workloads need to change kthread priority for RCU core processing
without affecting other softirq work. This commit therefore introduces
the rcutree.use_softirq kernel boot parameter, which moves the RCU core
work from softirq to a per-CPU SCHED_OTHER kthread named rcuc. Use of
SCHED_OTHER approach avoids the scalability problems that appeared
with the earlier attempt to move RCU core processing to from softirq
to kthreads. That said, kernels built with RCU_BOOST=y will run the
rcuc kthreads at the RCU-boosting priority.
Note that rcutree.use_softirq=0 must be specified to move RCU core
processing to the rcuc kthreads: rcutree.use_softirq=1 is the default.
Reported-by: Thomas Gleixner
Tested-by: Mike Galbraith
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Paul E. McKenney
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index d377a2166b79..e2ffb1d9de03 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3672,6 +3672,12 @@
the propagation of recent CPU-hotplug changes up
the rcu_node combining tree.
+ rcutree.use_softirq=[KNL]
+ If set to zero, move all RCU_SOFTIRQ processing to
+ per-CPU rcuc kthreads. Defaults to a non-zero
+ value, meaning that RCU_SOFTIRQ is used by default.
+ Specify rcutree.use_softirq=0 to use rcuc kthreads.
+
rcutree.rcu_fanout_exact= [KNL]
Disable autobalancing of the rcu_node combining
tree. This is used by rcutorture, and might
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index ec77ec336f58..6bd05c9918cc 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -51,6 +51,12 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include "../time/tick-internal.h"
#include "tree.h"
#include "rcu.h"
@@ -92,6 +98,9 @@ struct rcu_state rcu_state = {
/* Dump rcu_node combining tree at boot to verify correct setup. */
static bool dump_tree;
module_param(dump_tree, bool, 0444);
+/* Move RCU_SOFTIRQ to rcuc kthreads. */
+static bool use_softirq = 1;
+module_param(use_softirq, bool, 0444);
/* Control rcu_node-tree auto-balancing at boot time. */
static bool rcu_fanout_exact;
module_param(rcu_fanout_exact, bool, 0444);
@@ -2253,7 +2262,7 @@ void rcu_force_quiescent_state(void)
EXPORT_SYMBOL_GPL(rcu_force_quiescent_state);
/* Perform RCU core processing work for the current CPU. */
-static __latent_entropy void rcu_core(struct softirq_action *unused)
+static __latent_entropy void rcu_core(void)
{
unsigned long flags;
struct rcu_data *rdp = raw_cpu_ptr(_data);
@@ -2295,6 +2304,34 @@ static __latent_entropy void rcu_core(struct
softirq_action *unused)
trace_rcu_utilization(TPS("End RCU core"));
}
+static void rcu_core_si(struct softirq_action *h)
+{
+ rcu_core();
+}
+
+static void rcu_wake_cond(struct task_struct *t, int status)
+{
+ /*
+* If the thread is yielding, only wake it when this
+* is invoked from idle
+*/
+ if (t && (status != RCU_KTHREAD_YIELDING || is_idle_task(current)))
+ wake_up_process(t);
+}
+
+static void invoke_rcu_core_kthread(void)
+{
+ struct task_struct *t;
+ unsigned
Re: [PATCH v3 2/2] [WIP] tools/power turbostat: Also read package power on AMD F17h (Zen)
Hi Calvin,
I'm inclined to apply this -- because it will not break anything,
and it would at least enable testing by people, who have this hardware.
thoughts?
-Len
On Fri, Aug 17, 2018 at 12:35 PM Calvin Walton wrote:
>
> The package power can also be read from an MSR. It's not clear exactly
> what is included, and whether it's aggregated over all nodes or
> reported separately.
>
> It does look like this is reported separately per CCX (I get a single
> value on the Ryzen R7 1700), but it might be reported separately per-
> die (node?) on larger processors. If that's the case, it would have to
> be recorded per node and aggregated for the socket.
>
> Note that although Zen has these MSRs reporting power, it looks like
> the actual RAPL configuration (power limits, configured TDP) is done
> through PCI configuration space. I have not yet found any public
> documentation for this.
>
> Signed-off-by: Calvin Walton
> ---
> tools/power/x86/turbostat/turbostat.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/tools/power/x86/turbostat/turbostat.c
> b/tools/power/x86/turbostat/turbostat.c
> index 89d4e2e75774..675c894b8595 100644
> --- a/tools/power/x86/turbostat/turbostat.c
> +++ b/tools/power/x86/turbostat/turbostat.c
> @@ -1973,6 +1973,11 @@ int get_counters(struct thread_data *t, struct
> core_data *c, struct pkg_data *p)
> return -16;
> p->rapl_dram_perf_status = msr & 0x;
> }
> + if (do_rapl & RAPL_AMD_F17H) {
> + if (get_msr(cpu, MSR_PKG_ENERGY_STAT, ))
> + return -13;
> + p->energy_pkg = msr & 0x;
> + }
> if (DO_BIC(BIC_PkgTmp)) {
> if (get_msr(cpu, MSR_IA32_PACKAGE_THERM_STATUS, ))
> return -17;
> @@ -3986,10 +3991,13 @@ void rapl_probe_amd(unsigned int family, unsigned int
> model)
> switch (family) {
> case 0x17: /* Zen, Zen+ */
> do_rapl = RAPL_AMD_F17H | RAPL_PER_CORE_ENERGY;
> - if (rapl_joules)
> + if (rapl_joules) {
> + BIC_PRESENT(BIC_Pkg_J);
> BIC_PRESENT(BIC_Cor_J);
> - else
> + } else {
> + BIC_PRESENT(BIC_PkgWatt);
> BIC_PRESENT(BIC_CorWatt);
> + }
> break;
> default:
> return;
> --
> 2.18.0
>
--
Len Brown, Intel Open Source Technology Center
Re: [PATCH] mtd: cfi_util: mark expected switch fall-throughs
On 3/20/19 6:25 PM, Richard Weinberger wrote: > Am Mittwoch, 20. März 2019, 22:23:21 CET schrieb Gustavo A. R. Silva: >> So, if this is too much of a burden for people, I can add all these >> MTD patches to my own tree for 5.2. > > Taking the patches via MTD is not a big deal, let's go that path. Cool. > For you it is more work to send many patches and getting them into the > individual > trees. :) > Here applies this wise phrase: It is what it is. :) Thanks -- Gustavo
Re: [PATCH v3 0/2] tools/power turbostat: Add support for AMD Fam 17h (Zen) RAPL
Applied, thanks! On Fri, Aug 17, 2018 at 12:35 PM Calvin Walton wrote: > > This is an updated version of my RAPL patchset for Zen CPUs, rebased on > top of the current state of kernel/git/lenb/linux.get turbostat branch. > (In particular, this fixes conflicts with the AMD APIC-id patch) > > I've split it into two patches now. The first patch only adds Cores > power reporting, since I'm fairly confident that this'll work on all of > the Zen chips. I think this part is ready to apply now. > > The second part is still a work in progress until I'm able to (or I'm > able to find someone else to) test the package power reporting on a > multi-die Zen chip. > > Calvin Walton (2): > tools/power turbostat: Add support for AMD Fam 17h (Zen) RAPL > [WIP] tools/power turbostat: Also read package power on AMD F17h (Zen) > > tools/power/x86/turbostat/turbostat.c | 167 +- > 1 file changed, 138 insertions(+), 29 deletions(-) > > -- > 2.18.0 > -- Len Brown, Intel Open Source Technology Center
Re: [PATCH] mtd: cfi_util: mark expected switch fall-throughs
Am Mittwoch, 20. März 2019, 22:23:21 CET schrieb Gustavo A. R. Silva: > So, if this is too much of a burden for people, I can add all these > MTD patches to my own tree for 5.2. Taking the patches via MTD is not a big deal, let's go that path. For you it is more work to send many patches and getting them into the individual trees. :) Thanks, //richard
Re: [PATCH v5 00/12] PCI: brcmstb: Add Broadcom Settopbox PCIe support (resend)
On 3/20/19 4:15 PM, Bjorn Helgaas wrote: > On Wed, Sep 19, 2018 at 10:31:55AM -0400, Jim Quinlan wrote: >> This patch series adds support for the Broadcom Settopbox PCIe host >> controller. It is targeted to Broadcom Settopbox chips running on >> ARM, ARM64, and MIPS platforms. > > Whatever happened with this series? I saw some discussion that suggests > it's not quite ready to be merged, but there's a lot of good work here, > so I hope it can get finished up. Thanks, these are encouraging words! We've been side tracked with a number of things but it is still planned to get this included upstream sooner rather than later. I am not sure how we will approach the mangling of DMA addresses to fit the PCIe's quirky address map, but hopefully with Christoph's latest chunk of work, there is even less to be done by drivers. -- Florian
Re: [PATCH v5 00/12] PCI: brcmstb: Add Broadcom Settopbox PCIe support (resend)
On Wed, Sep 19, 2018 at 10:31:55AM -0400, Jim Quinlan wrote: > This patch series adds support for the Broadcom Settopbox PCIe host > controller. It is targeted to Broadcom Settopbox chips running on > ARM, ARM64, and MIPS platforms. Whatever happened with this series? I saw some discussion that suggests it's not quite ready to be merged, but there's a lot of good work here, so I hope it can get finished up. Bjorn
