Applied "ASoC: tas2770: Fix snd_soc_update_bits error handling" to the asoc tree
The patch
ASoC: tas2770: Fix snd_soc_update_bits error handling
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From edd6d5393206ec9bfc74776f6f20a57f11327e1b Mon Sep 17 00:00:00 2001
From: Dan Murphy
Date: Mon, 7 Oct 2019 12:11:55 -0500
Subject: [PATCH] ASoC: tas2770: Fix snd_soc_update_bits error handling
According the documentation for snd_soc_update_bits the API
will return a 1 if the update was successful with a value change,
a 0 if the update was successful with no value change or a negative
if the command just failed.
So the value of return in the driver needs to be checked for being less
then 0 or the caller may indicate failure when the value actually
changed.
Signed-off-by: Dan Murphy
Link: https://lore.kernel.org/r/20191007171157.17813-1-dmur...@ti.com
Signed-off-by: Mark Brown
---
sound/soc/codecs/tas2770.c | 46 +-
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/sound/soc/codecs/tas2770.c b/sound/soc/codecs/tas2770.c
index f3a665b64fd6..ad76f22fcfac 100644
--- a/sound/soc/codecs/tas2770.c
+++ b/sound/soc/codecs/tas2770.c
@@ -83,7 +83,8 @@ static int tas2770_codec_suspend(struct snd_soc_component
*component)
TAS2770_PWR_CTRL,
TAS2770_PWR_CTRL_MASK,
TAS2770_PWR_CTRL_SHUTDOWN);
- if (ret)
+
+ if (ret < 0)
return ret;
return 0;
@@ -97,8 +98,9 @@ static int tas2770_codec_resume(struct snd_soc_component
*component)
TAS2770_PWR_CTRL,
TAS2770_PWR_CTRL_MASK,
TAS2770_PWR_CTRL_ACTIVE);
- if (ret)
- return -EINVAL;
+
+ if (ret < 0)
+ return ret;
return 0;
}
@@ -150,7 +152,10 @@ static int tas2770_dac_event(struct snd_soc_dapm_widget *w,
}
end:
- return ret;
+ if (ret < 0)
+ return ret;
+
+ return 0;
}
static const struct snd_kcontrol_new isense_switch =
@@ -200,7 +205,10 @@ static int tas2770_mute(struct snd_soc_dai *dai, int mute)
TAS2770_PWR_CTRL_MASK,
TAS2770_PWR_CTRL_ACTIVE);
- return ret;
+ if (ret < 0)
+ return ret;
+
+ return 0;
}
static int tas2770_set_bitwidth(struct tas2770_priv *tas2770, int bitwidth)
@@ -253,7 +261,10 @@ static int tas2770_set_bitwidth(struct tas2770_priv
*tas2770, int bitwidth)
tas2770->i_sense_slot);
end:
- return ret;
+ if (ret < 0)
+ return ret;
+
+ return 0;
}
static int tas2770_set_samplerate(struct tas2770_priv *tas2770, int samplerate)
@@ -345,9 +356,11 @@ static int tas2770_set_samplerate(struct tas2770_priv
*tas2770, int samplerate)
}
end:
- if (!ret)
- tas2770->sampling_rate = samplerate;
- return ret;
+ if (ret < 0)
+ return ret;
+
+ tas2770->sampling_rate = samplerate;
+ return 0;
}
static int tas2770_hw_params(struct snd_pcm_substream *substream,
@@ -401,7 +414,7 @@ static int tas2770_set_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
ret = snd_soc_component_update_bits(component, TAS2770_TDM_CFG_REG1,
TAS2770_TDM_CFG_REG1_RX_MASK,
asi_cfg_1);
- if (ret)
+ if (ret < 0)
return ret;
switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
@@ -426,7 +439,7 @@ static int tas2770_set_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
ret = snd_soc_component_update_bits(component, TAS2770_TDM_CFG_REG1,
TAS2770_TDM_CFG_REG1_MASK,
(tdm_rx_start_slot << TAS2770_TDM_CFG_REG1_51_SHIFT));
- if (ret)
+ if (ret < 0)
return ret;
tas2770->asi_format = fmt;
@@ -470,12 +483,12 @@ static int tas2770_set_dai_tdm_slot(struct snd_soc_dai
*dai,
ret = snd_soc_component_update_bits(component, TAS2770_TDM_CFG_REG3,
TAS2770_TDM_CFG_REG3_30_MASK,
(left_slot << TAS2770_TDM_CFG_REG3_30_SHIFT));
- if (ret)
+ if (ret < 0)
return ret;
ret =
Applied "ASoc: tas2770: Remove unused defines and variables" to the asoc tree
The patch
ASoc: tas2770: Remove unused defines and variables
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 40f90ef0a77bab65c8f959ba1d264bb674f7234b Mon Sep 17 00:00:00 2001
From: Dan Murphy
Date: Mon, 7 Oct 2019 12:11:57 -0500
Subject: [PATCH] ASoc: tas2770: Remove unused defines and variables
Remove unused defines and structure variables that are not
referenced by the code. If these are needed for future
enhancements then they should be added at that time.
Signed-off-by: Dan Murphy
Link: https://lore.kernel.org/r/20191007171157.17813-3-dmur...@ti.com
Signed-off-by: Mark Brown
---
sound/soc/codecs/tas2770.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/sound/soc/codecs/tas2770.h b/sound/soc/codecs/tas2770.h
index d597a8280707..cbb858369fe6 100644
--- a/sound/soc/codecs/tas2770.h
+++ b/sound/soc/codecs/tas2770.h
@@ -125,40 +125,19 @@
#define ERROR_UNDER_VOLTAGE 0x008
#define ERROR_BROWNOUT 0x010
#define ERROR_CLASSD_PWR0x020
-#define TAS2770_SLOT_16BIT 16
-#define TAS2770_SLOT_32BIT 32
-#define TAS2770_I2C_RETRY_COUNT 3
-
-struct tas2770_register {
- int book;
- int page;
- int reg;
-};
-
-struct tas2770_dai_cfg {
- unsigned int dai_fmt;
- unsigned int tdm_delay;
-};
struct tas2770_priv {
struct device *dev;
struct regmap *regmap;
- struct snd_soc_codec *codec;
struct snd_soc_component *component;
- struct mutex dev_lock;
- struct hrtimer mtimer;
int power_state;
int asi_format;
struct gpio_desc *reset_gpio;
int sampling_rate;
- int frame_size;
int channel_size;
int slot_width;
int v_sense_slot;
int i_sense_slot;
- bool runtime_suspend;
- unsigned int err_code;
- struct mutex codec_lock;
};
#endif /* __TAS2770__ */
--
2.20.1
Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()
On Mon, Oct 7, 2019 at 10:34 AM Al Viro wrote:
>
> Tangentially related: copy_regster_to_user() and copy_regset_from_user().
Not a worry. It's not performance-critical code, and if it ever is, it
needs to be rewritten anyway.
> The former variant tends to lead to few calls
> of __copy_{to,from}_user(); the latter... On x86 it ends up doing
> this:
Just replace the __put_user() with a put_user() and be done with it.
That code isn't acceptable, and if somebody ever complains about
performance it's not the lack of __put_user that is the problem.
Linus
Re: [PATCH v11 14/22] mm: pagewalk: Add 'depth' parameter to pte_hole
On Mon, Oct 07, 2019 at 05:20:30PM +0100, Steven Price wrote:
> On 07/10/2019 17:10, Jason Gunthorpe wrote:
> > On Mon, Oct 07, 2019 at 04:38:14PM +0100, Steven Price wrote:
> >> diff --git a/mm/hmm.c b/mm/hmm.c
> >> index 902f5fa6bf93..34fe904dd417 100644
> >> +++ b/mm/hmm.c
> >> @@ -376,7 +376,7 @@ static void hmm_range_need_fault(const struct
> >> hmm_vma_walk *hmm_vma_walk,
> >> }
> >>
> >> static int hmm_vma_walk_hole(unsigned long addr, unsigned long end,
> >> - struct mm_walk *walk)
> >> + __always_unused int depth, struct mm_walk *walk)
> >
> > It this __always_unused on function arguments something we are doing
> > now?
>
> $ git grep __always_unused | wc -l
> 191
>
> It's elsewhere in the kernel tree. It seems like a good way of both
> documenting and silencing compiler warnings. But I'm open to other
> suggestions.
The normal kernel build doesn't generate warnings for unused function
parameters because there are alot of false positives, IIRC. So, seems
weird to see things like this.
> > Can we have negative depth? Should it be unsigned?
>
> As per the documentation added in this patch:
>
> * @pte_hole: if set, called for each hole at all levels,
> *depth is -1 if not known, 0:PGD, 1:P4D, 2:PUD, 3:PMD
> *4:PTE. Any folded depths (where PTRS_PER_P?D is equal
> *to 1) are skipped.
>
> So it's signed to allow "-1" in the cases where pte_hole is called
> without knowing the actual depth. This is used in the function
> walk_page_test() because it don't walk the actual page tables, but is
> called on a VMA instead. This means that there may not be a single depth
> for the range provided.
So are the depth values below OK? I would have expected -1 by this
definition
> >> {
> >>struct hmm_vma_walk *hmm_vma_walk = walk->private;
> >>struct hmm_range *range = hmm_vma_walk->range;
> >> @@ -564,7 +564,7 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
> >> again:
> >>pmd = READ_ONCE(*pmdp);
> >>if (pmd_none(pmd))
> >> - return hmm_vma_walk_hole(start, end, walk);
> >> + return hmm_vma_walk_hole(start, end, 0, walk);
> >>
> >>if (thp_migration_supported() && is_pmd_migration_entry(pmd)) {
> >>bool fault, write_fault;
> >> @@ -666,7 +666,7 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long
> >> start, unsigned long end,
> >> again:
> >>pud = READ_ONCE(*pudp);
> >>if (pud_none(pud))
> >> - return hmm_vma_walk_hole(start, end, walk);
> >> + return hmm_vma_walk_hole(start, end, 0, walk);
> >>
> >>if (pud_huge(pud) && pud_devmap(pud)) {
> >>unsigned long i, npages, pfn;
> >> @@ -674,7 +674,7 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long
> >> start, unsigned long end,
> >>bool fault, write_fault;
> >>
> >>if (!pud_present(pud))
> >> - return hmm_vma_walk_hole(start, end, walk);
> >> + return hmm_vma_walk_hole(start, end, 0, walk);
> >>
> >>i = (addr - range->start) >> PAGE_SHIFT;
> >>npages = (end - addr) >> PAGE_SHIFT;
Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()
On Mon, Oct 7, 2019 at 8:40 AM David Laight wrote: > > You don't really want an extra access_ok() for every 'word' of a copy. Yes you do. > Some copies have to be done a word at a time. Completely immaterial. If you can't see the access_ok() close to the __get/put_user(), you have a bug. Plus the access_ok() is cheap. The real cost is the STAC/CLAC. So stop with the access_ok() "optimizations". They are broken garbage. Really. I've been very close to just removing __get_user/__put_user several times, exactly because people do completely the wrong thing with them - not speeding code up, but making it unsafe and buggy. The new "user_access_begin/end()" model is much better, but it also has actual STATIC checking that there are no function calls etc inside th4e region, so it forces you to do the loop properly and tightly, and not the incorrect "I checked the range somewhere else, now I'm doing an unsafe copy". And it actually speeds things up, unlike the access_ok() games. Linus
Re: [PATCH -next 16/34] rtc: meson: use devm_platform_ioremap_resource() to simplify code
YueHaibing writes: > Use devm_platform_ioremap_resource() to simplify the code a bit. > This is detected by coccinelle. > > Signed-off-by: YueHaibing Reviewed-by: Kevin Hilman > --- > drivers/rtc/rtc-meson.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/rtc/rtc-meson.c b/drivers/rtc/rtc-meson.c > index e08b981..9bd8478 100644 > --- a/drivers/rtc/rtc-meson.c > +++ b/drivers/rtc/rtc-meson.c > @@ -292,7 +292,6 @@ static int meson_rtc_probe(struct platform_device *pdev) > }; > struct device *dev = >dev; > struct meson_rtc *rtc; > - struct resource *res; > void __iomem *base; > int ret; > u32 tm; > @@ -312,8 +311,7 @@ static int meson_rtc_probe(struct platform_device *pdev) > rtc->rtc->ops = _rtc_ops; > rtc->rtc->range_max = U32_MAX; > > - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - base = devm_ioremap_resource(dev, res); > + base = devm_platform_ioremap_resource(pdev, 0); > if (IS_ERR(base)) > return PTR_ERR(base); > > -- > 2.7.4
Re: [PATCH v22 09/24] x86/sgx: Add functions to allocate and free EPC pages
On Mon, Oct 07, 2019 at 08:55:55PM +0300, Jarkko Sakkinen wrote: > But checkpatch.pl will complain about it... You should not take checkpatch.pl messages to the letter but always sanity-check them with common sense. In this particular example, readability is much more important than some tool measuring line length. Sure, if you can make the line fit into 80 columns, then fine, but having to chop it into unreadability just to make some tool happy is certainly not what the goal should be. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH 1/4] net: sctp: Rename fallthrough label to unhandled
On Sat, Oct 5, 2019 at 9:46 AM Joe Perches wrote:
>
> fallthrough may become a pseudo reserved keyword so this only use of
> fallthrough is better renamed to allow it.
>
> Signed-off-by: Joe Perches
> ---
> net/sctp/sm_make_chunk.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index e41ed2e0ae7d..48d63956a68c 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -2155,7 +2155,7 @@ static enum sctp_ierror sctp_verify_param(struct net
> *net,
> case SCTP_PARAM_SET_PRIMARY:
> if (ep->asconf_enable)
> break;
> - goto fallthrough;
> + goto unhandled;
>
> case SCTP_PARAM_HOST_NAME_ADDRESS:
> /* Tell the peer, we won't support this param. */
> @@ -2166,11 +2166,11 @@ static enum sctp_ierror sctp_verify_param(struct net
> *net,
> case SCTP_PARAM_FWD_TSN_SUPPORT:
> if (ep->prsctp_enable)
> break;
> - goto fallthrough;
> + goto unhandled;
>
> case SCTP_PARAM_RANDOM:
> if (!ep->auth_enable)
> - goto fallthrough;
> + goto unhandled;
>
> /* SCTP-AUTH: Secion 6.1
> * If the random number is not 32 byte long the association
> @@ -2187,7 +2187,7 @@ static enum sctp_ierror sctp_verify_param(struct net
> *net,
>
> case SCTP_PARAM_CHUNKS:
> if (!ep->auth_enable)
> - goto fallthrough;
> + goto unhandled;
>
> /* SCTP-AUTH: Section 3.2
> * The CHUNKS parameter MUST be included once in the INIT or
> @@ -2203,7 +2203,7 @@ static enum sctp_ierror sctp_verify_param(struct net
> *net,
>
> case SCTP_PARAM_HMAC_ALGO:
> if (!ep->auth_enable)
> - goto fallthrough;
> + goto unhandled;
>
> hmacs = (struct sctp_hmac_algo_param *)param.p;
> n_elt = (ntohs(param.p->length) -
> @@ -2226,7 +2226,7 @@ static enum sctp_ierror sctp_verify_param(struct net
> *net,
> retval = SCTP_IERROR_ABORT;
> }
> break;
> -fallthrough:
> +unhandled:
> default:
Interesting control flow (goto from one case to the default case, not
sure "fallthrough" was ever the right word for that). Thanks for the
patch.
Reviewed-by: Nick Desaulniers
> pr_debug("%s: unrecognized param:%d for chunk:%d\n",
> __func__, ntohs(param.p->type), cid);
> --
> 2.15.0
>
--
Thanks,
~Nick Desaulniers
[RFC 0/1] s390/purgatory: Make sure we fail the build if purgatory has missing symbols
Hi s390 maintainers, This patch mirrors a similar patch for x86, but it has been untested because I do not have a mainframe to compile on :) In 5.4-rc1 the 2 different sha256 implementations for the purgatory resp. for crypto/sha256_generic.c have been consolidated into 1 single shared implementation under lib/crypto/sha256.c . At least on x86 this was causing silent corruption of the purgatory due to a missing memzero_explicit symbol in the purgatory string.c/.o file. With the x86 equivalent of this patch applied a x86 build of 5.4-rc1 now correctly fails: CHK arch/x86/purgatory/purgatory.ro ld: arch/x86/purgatory/purgatory.ro: in function `sha256_transform': sha256.c:(.text+0x1c0c): undefined reference to `memzero_explicit' make[2]: *** [arch/x86/purgatory/Makefile:72: arch/x86/purgatory/kexec-purgatory.c] Error 1 make[1]: *** [scripts/Makefile.build:509: arch/x86/purgatory] Error 2 make: *** [Makefile:1650: arch/x86] Error 2 It would be great if the s390 maintainers can test this equivalent patch on s390. As for fixing the missing memzero_explicit symbol, we are currently discussing making memzero_explicit a static inline wrapper of memset in string.h, so that we do not need to implement it in multiple places. This discussion is Cc-ed to the generic linux-kernel@vger.kernel.org list, it is happening in the "[PATCH v2 5.4 regression fix] x86/boot: Provide memzero_explicit" thread. Regards, Hans
[RFC] s390/purgatory: Make sure we fail the build if purgatory has missing symbols
Since we link purgatory with -r aka we enable "incremental linking" no checks for unresolved symbols are done while linking the purgatory. This commit adds an extra check for unresolved symbols by calling ld without -r before running objcopy to generate purgatory.ro. This will help us catch missing symbols in the purgatory sooner. Note this commit also removes --no-undefined from LDFLAGS_purgatory.ro as that has no effect. Signed-off-by: Hans de Goede --- arch/s390/purgatory/Makefile | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/s390/purgatory/Makefile b/arch/s390/purgatory/Makefile index bc0d7a0d0394..d5405fe7b2e2 100644 --- a/arch/s390/purgatory/Makefile +++ b/arch/s390/purgatory/Makefile @@ -26,15 +26,21 @@ KBUILD_CFLAGS += $(CLANG_FLAGS) KBUILD_CFLAGS += $(call cc-option,-fno-PIE) KBUILD_AFLAGS := $(filter-out -DCC_USING_EXPOLINE,$(KBUILD_AFLAGS)) -LDFLAGS_purgatory := -r --no-undefined -nostdlib -z nodefaultlib -T +LDFLAGS_purgatory := -r -nostdlib -z nodefaultlib -T $(obj)/purgatory: $(obj)/purgatory.lds $(PURGATORY_OBJS) FORCE $(call if_changed,ld) +# Since we link purgatory with -r unresolved symbols are not checked, +# so we check this before generating purgatory.ro instead +quiet_cmd_check_purgatory = CHK $< + cmd_check_purgatory = ld -e purgatory_start $< + OBJCOPYFLAGS_purgatory.ro := -O elf64-s390 OBJCOPYFLAGS_purgatory.ro += --remove-section='*debug*' OBJCOPYFLAGS_purgatory.ro += --remove-section='.comment' OBJCOPYFLAGS_purgatory.ro += --remove-section='.note.*' $(obj)/purgatory.ro: $(obj)/purgatory FORCE + $(call if_changed,check_purgatory) $(call if_changed,objcopy) $(obj)/kexec-purgatory.o: $(obj)/kexec-purgatory.S $(obj)/purgatory.ro FORCE -- 2.23.0
Re: [PATCH v3 09/10] sched/fair: use load instead of runnable load in wakeup path
On Mon, 2019-10-07 at 17:27 +0200, Vincent Guittot wrote: > On Mon, 7 Oct 2019 at 17:14, Rik van Riel wrote: > > On Thu, 2019-09-19 at 09:33 +0200, Vincent Guittot wrote: > > > runnable load has been introduced to take into account the case > > > where > > > blocked load biases the wake up path which may end to select an > > > overloaded > > > CPU with a large number of runnable tasks instead of an > > > underutilized > > > CPU with a huge blocked load. > > > > > > Tha wake up path now starts to looks for idle CPUs before > > > comparing > > > runnable load and it's worth aligning the wake up path with the > > > load_balance. > > > > > > Signed-off-by: Vincent Guittot > > > > On a single socket system, patches 9 & 10 have the > > result of driving a woken up task (when wake_wide is > > true) to the CPU core with the lowest blocked load, > > even when there is an idle core the task could run on > > right now. > > > > With the whole series applied, I see a 1-2% regression > > in CPU use due to that issue. > > > > With only patches 1-8 applied, I see a 1% improvement in > > CPU use for that same workload. > > Thanks for testing. > patch 8-9 have just replaced runnable load by blocked load and then > removed the duplicated metrics in find_idlest_group. > I'm preparing an additional patch that reworks find_idlest_group() > to > behave similarly to find_busiest_group(). It gathers statistics what > it already does, then classifies the groups and finally selects the > idlest one. This should fix the problem that you mentioned above when > it selects a group with lowest blocked load whereas there are idle > cpus in another group with high blocked load. That should do the trick! > > Given that it looks like select_idle_sibling and > > find_idlest_group_cpu do roughly the same thing, I > > wonder if it is enough to simply add an additional > > test to find_idlest_group to have it return the > > LLC sg, if it is called on the LLC sd on a single > > socket system. > > That make sense to me > > > That way find_idlest_group_cpu can still find an > > idle core like it does today. > > > > Does that seem like a reasonable thing? > > That's worth testing I'll give it a try. Doing the full find_idlest_group heuristic inside an LLC seems like it would be overkill, anyway. -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 1/2] fpga: fpga-mgr: Add readback support
Hi Moritz, On 9/27/19 1:23 PM, Moritz Fischer wrote: Thor, On Fri, Sep 27, 2019 at 09:32:11AM -0500, Thor Thayer wrote: Hi Kedar & Moritz, On 9/27/19 12:13 AM, Appana Durga Kedareswara Rao wrote: Hi Alan, Did you get a chance to send your framework changes to upstream? No they weren't upstreamed. @Moritz Fischer: If Alan couldn't send his patch series, Can we take this patch series?? Please let me know your thoughts on this. Alan had some comments RE: #defines, I'll have to take another look. Regards, Kedar. I'd like to see some mechanism added as well. Our CvP driver needs a way to load images to the FPGA over the PCIe bus. Can you elaborate a bit on the CvP use-case and how that would work? Who would use the device how after loading the bitstream? Generally there are several use cases that I have collected mentally over the years: I) DFL use case: - Mixed-set of drivers: Kernel and Userspace - FPGA logic is discoverable through DFL - Userspace application wants to reprogram FPGA II) DT configfs use case: - Mixed-set of drivers: Kernel and Userspace - FPGA logic is *not* discoverable (hence DT overlay) - Userspace application wants to reprogram FPGA III) Thomas' case: - Kernel only drivers (pcie bridge, pcie drivers, ...) - FPGA logic is fully discoverable (i.e. PCIe endpoint implemented in FPGA, connected to SoC via PCIe) - Userspace application wants to reprogram FPGA IV) VFIO case: - Usually exposes either entire device via vfio-pci or part via vfio-mdev - Loading (basic) bitstream at boot from flash - vfio-mdev case can use FPGA region interface + ioctl - Full VFIO case is similar to III) How does your CvP use case fit in? Collecting all the use-cases would help with moving forward on coming up with an API :) The CvP case is the same as III) Thomas' case. The FPGA configuration bitstream is downloaded over the PCIe. The one difference in my case is that there isn't an SoC. This is a Intel host processor connecting to a non-SoC Stratix10/Arria10. The non-SoC A10/S10, boots a minimal image (CvP) setting up the peripheral pins and enabling the PCIe endpoint for CvP downloads. The host can then download bitstreams using the FPGA Manager through debugFS and when the bitstream finishes downloading and the FPGA enters User Mode, the functionality is available for the host to use. It wasn't clear to me from the discussion on Alan's patchset[1] that the debugfs was acceptable to the mainline. I'd be happy to resurrect that patchset with the suggested changes. Back then we decided to not move forward with the debugfs patchset since it's essentially cat foo.bin > /dev/xdevcfg / cat bar.rbf > /dev/fpga0 in disguise. Which is why I vetoed it back then. Since debugfs isn't enabled for production, are there any alternatives? Alan sent a RFC [2] for loading FIT images through the sysfs. The RFC described a FIT image that included FPGA image specific information to be included with the image (for systems running without device tree like our PCIe bus FPGA CvP). Yeah I had originally suggested that as a mechanim to make FPGA images discoverable by the kernel. I still think the idea has merit, however it will run into the same issues that the configfs interface ran into w.r.t using dt-overlays. Generally I'd like to see a solution that exposes the *same* interface to DT and not DT systems to userspace. Using FIT headers one could go ahead and design something along the lines of what DFL is doing, except for instead of parsing the DFL in the logic, one would parse the FIT header to create subdevices. Unfortunately, I believe this has the same uphill battle that the Device Tree Overlay patches[3] have to getting accepted. See above. While I'm happy to discuss this more I atm don't have the bandwidth to push the DT work any further. Understood. I'm still coming up to speed on the variations of FPGA enablement but I'm happy to help where I can. Thanks. Thanks, Moritz
Re: [PATCH v2 1/1] s390/cio: fix virtio-ccw DMA without PV
On 30.09.19 17:38, Halil Pasic wrote:
> Commit 37db8985b211 ("s390/cio: add basic protected virtualization
> support") breaks virtio-ccw devices with VIRTIO_F_IOMMU_PLATFORM for non
> Protected Virtualization (PV) guests. The problem is that the dma_mask
> of the ccw device, which is used by virtio core, gets changed from 64 to
> 31 bit, because some of the DMA allocations do require 31 bit
> addressable memory. For PV the only drawback is that some of the virtio
> structures must end up in ZONE_DMA because we have the bounce the
> buffers mapped via DMA API anyway.
>
> But for non PV guests we have a problem: because of the 31 bit mask
> guests bigger than 2G are likely to try bouncing buffers. The swiotlb
> however is only initialized for PV guests, because we don't want to
> bounce anything for non PV guests. The first such map kills the guest.
>
> Since the DMA API won't allow us to specify for each allocation whether
> we need memory from ZONE_DMA (31 bit addressable) or any DMA capable
> memory will do, let us use coherent_dma_mask (which is used for
> allocations) to force allocating form ZONE_DMA while changing dma_mask
> to DMA_BIT_MASK(64) so that at least the streaming API will regard
> the whole memory DMA capable.
>
> Signed-off-by: Halil Pasic
> Reported-by: Marc Hartmayer
> Suggested-by: Robin Murphy
> Fixes: 37db8985b211 ("s390/cio: add basic protected virtualization support")
Thanks applied to the s390 tree. (pending some regression tests)
> ---
>
> v1 --> v2:
> * Fixed comment: dropped the sentence with workaround.
>
> The idea of enabling the client code to specify on s390 whether a chunk
> of allocated DMA memory is to be allocated form ZONE_DMA for each
> allocation was not well received [1].
>
> Making the streaming API threat all addresses as DMA capable, while
> restricting the DMA API allocations to ZONE_DMA (regardless of needed
> or not) is the next best thing we can do (from s390 perspective).
>
> [1] https://lkml.org/lkml/2019/9/23/531
> ---
> ---
> drivers/s390/cio/cio.h| 1 +
> drivers/s390/cio/css.c| 7 ++-
> drivers/s390/cio/device.c | 2 +-
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/s390/cio/cio.h b/drivers/s390/cio/cio.h
> index ba7d2480613b..dcdaba689b20 100644
> --- a/drivers/s390/cio/cio.h
> +++ b/drivers/s390/cio/cio.h
> @@ -113,6 +113,7 @@ struct subchannel {
> enum sch_todo todo;
> struct work_struct todo_work;
> struct schib_config config;
> + u64 dma_mask;
> char *driver_override; /* Driver name to force a match */
> } __attribute__ ((aligned(8)));
>
> diff --git a/drivers/s390/cio/css.c b/drivers/s390/cio/css.c
> index 22c55816100b..a05dbf2e97db 100644
> --- a/drivers/s390/cio/css.c
> +++ b/drivers/s390/cio/css.c
> @@ -232,7 +232,12 @@ struct subchannel *css_alloc_subchannel(struct
> subchannel_id schid,
>* belong to a subchannel need to fit 31 bit width (e.g. ccw).
>*/
> sch->dev.coherent_dma_mask = DMA_BIT_MASK(31);
> - sch->dev.dma_mask = >dev.coherent_dma_mask;
> + /*
> + * But we don't have such restrictions imposed on the stuff that
> + * is handled by the streaming API.
> + */
> + sch->dma_mask = DMA_BIT_MASK(64);
> + sch->dev.dma_mask = >dma_mask;
> return sch;
>
> err:
> diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
> index 131430bd48d9..0c6245fc7706 100644
> --- a/drivers/s390/cio/device.c
> +++ b/drivers/s390/cio/device.c
> @@ -710,7 +710,7 @@ static struct ccw_device *
> io_subchannel_allocate_dev(struct subchannel *sch)
> if (!cdev->private)
> goto err_priv;
> cdev->dev.coherent_dma_mask = sch->dev.coherent_dma_mask;
> - cdev->dev.dma_mask = >dev.coherent_dma_mask;
> + cdev->dev.dma_mask = sch->dev.dma_mask;
> dma_pool = cio_gp_dma_create(>dev, 1);
> if (!dma_pool)
> goto err_dma_pool;
>
Re: [PATCH v2] dt-bindings: iio: maxbotix,mb1232.yaml: transform to yaml
On Mon, Oct 7, 2019 at 12:00 PM Andreas Klinger wrote: > > Hi Rob, > > i don't get this error. Is there anything i'm doing wrong here? > > ak@arbad:/project/opt-sw/linux-robh$ make O=../build-wega-robh/ > dt_binding_check > make[1]: Verzeichnis „/project/opt-sw/build-wega-robh“ wird betreten > SCHEMA Documentation/devicetree/bindings/processed-schema.yaml > > /project/opt-sw/linux-robh/Documentation/devicetree/bindings/net/adi,adin.yaml: > ignoring, error in schema 'adi,fifo-depth-bits' > warning: no schema found in file: > > /project/opt-sw/linux-robh/Documentation/devicetree/bindings/net/adi,adin.yaml > > /project/opt-sw/linux-robh/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml: > ignoring, error in schema '0' > warning: no schema found in file: > > /project/opt-sw/linux-robh/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml > CHKDT > Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml > CHKDT [...] It would be in the later stage when dtc builds the exmaple. The unrelated errors here may be making things error out before that. BTW, update dtschema and it will fix the first error. The 2nd one is pending in linux-next still. Rob
[PATCH 02/10] perf tools: Support PERF_SAMPLE_LBR_TOS
From: Kan Liang
Support new sample type PERF_SAMPLE_LBR_TOS.
Enable LBR_TOS by default in LBR call stack mode.
If kernel doesn't support the sample type, switching it off.
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
tools/include/uapi/linux/perf_event.h | 4 +++-
tools/perf/util/event.h | 1 +
tools/perf/util/evsel.c | 16 +++-
tools/perf/util/evsel.h | 1 +
tools/perf/util/perf_event_attr_fprintf.c | 2 +-
tools/perf/util/synthetic-events.c| 8
6 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/tools/include/uapi/linux/perf_event.h
b/tools/include/uapi/linux/perf_event.h
index bb7b271397a6..fe36ebb7dc2e 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -141,8 +141,9 @@ enum perf_event_sample_format {
PERF_SAMPLE_TRANSACTION = 1U << 17,
PERF_SAMPLE_REGS_INTR = 1U << 18,
PERF_SAMPLE_PHYS_ADDR = 1U << 19,
+ PERF_SAMPLE_LBR_TOS = 1U << 20,
- PERF_SAMPLE_MAX = 1U << 20, /* non-ABI */
+ PERF_SAMPLE_MAX = 1U << 21, /* non-ABI */
__PERF_SAMPLE_CALLCHAIN_EARLY = 1ULL << 63, /* non-ABI;
internal use */
};
@@ -864,6 +865,7 @@ enum perf_event_type {
* { u64 abi; # enum perf_sample_regs_abi
*u64 regs[weight(mask)]; } &&
PERF_SAMPLE_REGS_INTR
* { u64 phys_addr;} && PERF_SAMPLE_PHYS_ADDR
+* { u64 tos;} && PERF_SAMPLE_LBR_TOS
* };
*/
PERF_RECORD_SAMPLE = 9,
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index a0a0c91cde4a..268c1715e032 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -130,6 +130,7 @@ struct perf_sample {
u32 raw_size;
u64 data_src;
u64 phys_addr;
+ u64 tos;
u32 flags;
u16 insn_len;
u8 cpumode;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index abc7fda4a0fe..0752417bbc45 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -709,6 +709,7 @@ static void __perf_evsel__config_callchain(struct evsel
*evsel,
"Falling back to framepointers.\n");
} else {
perf_evsel__set_sample_bit(evsel, BRANCH_STACK);
+ perf_evsel__set_sample_bit(evsel, LBR_TOS);
attr->branch_sample_type =
PERF_SAMPLE_BRANCH_USER |
PERF_SAMPLE_BRANCH_CALL_STACK |
PERF_SAMPLE_BRANCH_NO_CYCLES |
@@ -762,6 +763,7 @@ perf_evsel__reset_callgraph(struct evsel *evsel,
perf_evsel__reset_sample_bit(evsel, CALLCHAIN);
if (param->record_mode == CALLCHAIN_LBR) {
perf_evsel__reset_sample_bit(evsel, BRANCH_STACK);
+ perf_evsel__reset_sample_bit(evsel, LBR_TOS);
attr->branch_sample_type &= ~(PERF_SAMPLE_BRANCH_USER |
PERF_SAMPLE_BRANCH_CALL_STACK);
}
@@ -1641,6 +1643,8 @@ int evsel__open(struct evsel *evsel, struct perf_cpu_map
*cpus,
evsel->core.attr.ksymbol = 0;
if (perf_missing_features.bpf)
evsel->core.attr.bpf_event = 0;
+ if (perf_missing_features.lbr_tos)
+ perf_evsel__reset_sample_bit(evsel, LBR_TOS);
retry_sample_id:
if (perf_missing_features.sample_id_all)
evsel->core.attr.sample_id_all = 0;
@@ -1752,7 +1756,11 @@ int evsel__open(struct evsel *evsel, struct perf_cpu_map
*cpus,
* Must probe features in the order they were added to the
* perf_event_attr interface.
*/
- if (!perf_missing_features.aux_output && evsel->core.attr.aux_output) {
+ if (!perf_missing_features.lbr_tos && (evsel->core.attr.sample_type &
PERF_SAMPLE_LBR_TOS)) {
+ perf_missing_features.lbr_tos = true;
+ pr_debug2("switching off LBR TOS support\n");
+ goto fallback_missing_features;
+ } else if (!perf_missing_features.aux_output &&
evsel->core.attr.aux_output) {
perf_missing_features.aux_output = true;
pr_debug2("Kernel has no attr.aux_output support, bailing
out\n");
goto out_close;
@@ -2206,6 +2214,12 @@ int perf_evsel__parse_sample(struct evsel *evsel, union
perf_event *event,
array++;
}
+ data->tos = -1ULL;
+ if (type & PERF_SAMPLE_LBR_TOS) {
+ data->tos = *array;
+ array++;
+ }
+
return 0;
}
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index
[PATCH 03/10] perf pmu: Add support for PMU capabilities
From: Kan Liang
The PMU capabilities information, which is located at
/sys/bus/event_source/devices//caps, is required by perf tool.
For example, the max LBR information is required to stitch LBR call
stack.
Add perf_pmu__caps_parse() to parse the PMU capabilities information.
The information is stored in a list.
Add perf_pmu__scan_caps() to scan the capabilities once by one.
The following patch will store the capabilities information in perf
header.
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
tools/perf/util/pmu.c | 87 +++
tools/perf/util/pmu.h | 12 ++
2 files changed, 99 insertions(+)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 5608da82ad23..d3dc9d4f9479 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -847,6 +847,7 @@ static struct perf_pmu *pmu_lookup(const char *name)
INIT_LIST_HEAD(>format);
INIT_LIST_HEAD(>aliases);
+ INIT_LIST_HEAD(>caps);
list_splice(, >format);
list_splice(, >aliases);
list_add_tail(>list, );
@@ -1552,3 +1553,89 @@ int perf_pmu__scan_file(struct perf_pmu *pmu, const char
*name, const char *fmt,
va_end(args);
return ret;
}
+
+static int perf_pmu__new_caps(struct list_head *list, char *name, char *value)
+{
+ struct perf_pmu_caps *caps;
+
+ caps = zalloc(sizeof(*caps));
+ if (!caps)
+ return -ENOMEM;
+
+ caps->name = strdup(name);
+ caps->value = strndup(value, strlen(value) - 1);
+ list_add_tail(>list, list);
+ return 0;
+}
+
+/*
+ * Reading/parsing the given pmu capabilities, which should be located at:
+ * /sys/bus/event_source/devices//caps as sysfs group attributes.
+ * Return the number of capabilities
+ */
+int perf_pmu__caps_parse(struct perf_pmu *pmu)
+{
+ struct stat st;
+ char caps_path[PATH_MAX];
+ const char *sysfs = sysfs__mountpoint();
+ DIR *caps_dir;
+ struct dirent *evt_ent;
+ int nr_caps = 0;
+
+ if (!sysfs)
+ return -1;
+
+ snprintf(caps_path, PATH_MAX,
+"%s" EVENT_SOURCE_DEVICE_PATH "%s/caps", sysfs, pmu->name);
+
+ if (stat(caps_path, ) < 0)
+ return 0; /* no error if caps does not exist */
+
+ caps_dir = opendir(caps_path);
+ if (!caps_dir)
+ return -EINVAL;
+
+ while ((evt_ent = readdir(caps_dir)) != NULL) {
+ char *name = evt_ent->d_name;
+ char path[PATH_MAX];
+ char value[128];
+ FILE *file;
+
+ if (!strcmp(name, ".") || !strcmp(name, ".."))
+ continue;
+
+ snprintf(path, PATH_MAX, "%s/%s", caps_path, name);
+
+ file = fopen(path, "r");
+ if (!file)
+ break;
+
+ if (!fgets(value, sizeof(value), file) ||
+ (perf_pmu__new_caps(>caps, name, value) < 0)) {
+ fclose(file);
+ break;
+ }
+
+ nr_caps++;
+ fclose(file);
+ }
+
+ closedir(caps_dir);
+
+ return nr_caps;
+}
+
+struct perf_pmu_caps *perf_pmu__scan_caps(struct perf_pmu *pmu,
+ struct perf_pmu_caps *caps)
+{
+ if (!pmu)
+ return NULL;
+
+ if (!caps)
+ caps = list_prepare_entry(caps, >caps, list);
+
+ list_for_each_entry_continue(caps, >caps, list)
+ return caps;
+
+ return NULL;
+}
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index f36ade6df76d..5ded4e3e28e4 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -21,6 +21,12 @@ enum {
struct perf_event_attr;
+struct perf_pmu_caps {
+ char *name;
+ char *value;
+ struct list_head list;
+};
+
struct perf_pmu {
char *name;
__u32 type;
@@ -31,6 +37,7 @@ struct perf_pmu {
struct perf_cpu_map *cpus;
struct list_head format; /* HEAD struct perf_pmu_format -> list */
struct list_head aliases; /* HEAD struct perf_pmu_alias -> list */
+ struct list_head caps;/* HEAD struct perf_pmu_caps -> list */
struct list_head list;/* ELEM */
};
@@ -98,4 +105,9 @@ struct pmu_events_map *perf_pmu__find_map(struct perf_pmu
*pmu);
int perf_pmu__convert_scale(const char *scale, char **end, double *sval);
+int perf_pmu__caps_parse(struct perf_pmu *pmu);
+
+struct perf_pmu_caps *perf_pmu__scan_caps(struct perf_pmu *pmu,
+ struct perf_pmu_caps *caps);
+
#endif /* __PMU_H */
--
2.17.1
[PATCH 05/10] perf machine: Refine the function for LBR call stack reconstruction
From: Kan Liang
LBR only collect the user call stack. To reconstruct a call stack, both
kernel call stack and user call stack are required. The function
resolve_lbr_callchain_sample() mix the kernel call stack and user
call stack. Now, with the help of TOS, perf tool can reconstruct a more
complete call stack by adding some user call stack from previous sample.
However, current implementation is hard to be extended to support it.
Abstract two new functions to resolve user call stack and kernel
call stack respectively.
No functional changes.
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
tools/perf/util/machine.c | 186 --
1 file changed, 119 insertions(+), 67 deletions(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 70a9f8716a4b..e3e516e30093 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -2183,6 +2183,96 @@ static int remove_loops(struct branch_entry *l, int nr,
return nr;
}
+
+static int lbr_callchain_add_kernel_ip(struct thread *thread,
+ struct callchain_cursor *cursor,
+ struct perf_sample *sample,
+ struct symbol **parent,
+ struct addr_location *root_al,
+ bool callee, int end)
+{
+ struct ip_callchain *chain = sample->callchain;
+ u8 cpumode = PERF_RECORD_MISC_USER;
+ int err, i;
+
+ if (callee) {
+ for (i = 0; i < end + 1; i++) {
+ err = add_callchain_ip(thread, cursor, parent,
+ root_al, , chain->ips[i],
+ false, NULL, NULL, 0);
+ if (err)
+ return err;
+ }
+ } else {
+ for (i = end; i >= 0; i--) {
+ err = add_callchain_ip(thread, cursor, parent,
+ root_al, , chain->ips[i],
+ false, NULL, NULL, 0);
+ if (err)
+ return err;
+ }
+ }
+
+ return 0;
+}
+
+static int lbr_callchain_add_lbr_ip(struct thread *thread,
+ struct callchain_cursor *cursor,
+ struct perf_sample *sample,
+ struct symbol **parent,
+ struct addr_location *root_al,
+ bool callee)
+{
+ struct branch_stack *lbr_stack = sample->branch_stack;
+ u8 cpumode = PERF_RECORD_MISC_USER;
+ int lbr_nr = lbr_stack->nr;
+ struct branch_flags *flags;
+ u64 ip, branch_from = 0;
+ int err, i;
+
+ if (callee) {
+ ip = lbr_stack->entries[0].to;
+ flags = _stack->entries[0].flags;
+ branch_from = lbr_stack->entries[0].from;
+ err = add_callchain_ip(thread, cursor, parent,
+ root_al, , ip,
+ true, flags, NULL, branch_from);
+ if (err)
+ return err;
+
+ for (i = 0; i < lbr_nr; i++) {
+ ip = lbr_stack->entries[i].from;
+ flags = _stack->entries[i].flags;
+ err = add_callchain_ip(thread, cursor, parent,
+ root_al, , ip,
+ true, flags, NULL, branch_from);
+ if (err)
+ return err;
+ }
+ } else {
+ for (i = lbr_nr - 1; i >= 0; i--) {
+ ip = lbr_stack->entries[i].from;
+ flags = _stack->entries[i].flags;
+ err = add_callchain_ip(thread, cursor, parent,
+ root_al, , ip,
+ true, flags, NULL, branch_from);
+ if (err)
+ return err;
+ }
+
+ ip = lbr_stack->entries[0].to;
+ flags = _stack->entries[0].flags;
+ branch_from = lbr_stack->entries[0].from;
+ err = add_callchain_ip(thread, cursor, parent,
+ root_al, , ip,
+ true, flags, NULL, branch_from);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
/*
* Recolve LBR callstack chain sample
* Return:
@@ -2198,82 +2288,44 @@ static int resolve_lbr_callchain_sample(struct thread
*thread,
int max_stack)
{
struct ip_callchain *chain =
[PATCH 10/10] perf c2c: Add option to enable the LBR stitching approach
From: Kan Liang
With the LBR stitching approach, the reconstructed LBR call stack
can break the HW limitation. However, it may reconstruct invalid call
stacks in some cases, e.g. exception handing such as setjmp/longjmp.
Also, it may impact the processing time especially when the number of
samples with stitched LBRs are huge.
Add an option to enable the approach.
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
tools/perf/Documentation/perf-c2c.txt | 11 +++
tools/perf/builtin-c2c.c | 6 ++
2 files changed, 17 insertions(+)
diff --git a/tools/perf/Documentation/perf-c2c.txt
b/tools/perf/Documentation/perf-c2c.txt
index e6150f21267d..2133eb320cb0 100644
--- a/tools/perf/Documentation/perf-c2c.txt
+++ b/tools/perf/Documentation/perf-c2c.txt
@@ -111,6 +111,17 @@ REPORT OPTIONS
--display::
Switch to HITM type (rmt, lcl) to display and sort on. Total HITMs as
default.
+--stitch-lbr::
+ Show callgraph with stitched LBRs, which may have more complete
+ callgraph. The perf.data file must have been obtained using
+ perf c2c record --call-graph lbr.
+ Disabled by default. In common cases with call stack overflows,
+ it can recreate better call stacks than the default lbr call stack
+ output. But this approach is not full proof. There can be cases
+ where it creates incorrect call stacks from incorrect matches.
+ The known limitations include exception handing such as
+ setjmp/longjmp will have calls/returns not match.
+
C2C RECORD
--
The perf c2c record command setup options related to HITM cacheline analysis
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 3542b6ab9813..c3658986c38a 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -95,6 +95,7 @@ struct perf_c2c {
bool use_stdio;
bool stats_only;
bool symbol_full;
+ bool stitch_lbr;
/* HITM shared clines stats */
struct c2c_statshitm_stats;
@@ -273,6 +274,9 @@ static int process_sample_event(struct perf_tool *tool
__maybe_unused,
return -1;
}
+ if (c2c.stitch_lbr)
+ al.thread->lbr_stitch_enable = true;
+
ret = sample__resolve_callchain(sample, _cursor, NULL,
evsel, ,
sysctl_perf_event_max_stack);
if (ret)
@@ -2746,6 +2750,8 @@ static int perf_c2c__report(int argc, const char **argv)
OPT_STRING('c', "coalesce", , "coalesce fields",
"coalesce fields: pid,tid,iaddr,dso"),
OPT_BOOLEAN('f', "force", _conf.force, "don't complain, do it"),
+ OPT_BOOLEAN(0, "stitch-lbr", _lbr,
+ "Enable LBR callgraph stitching approach"),
OPT_PARENT(c2c_options),
OPT_END()
};
--
2.17.1
[PATCH 09/10] perf top: Add option to enable the LBR stitching approach
From: Kan Liang
With the LBR stitching approach, the reconstructed LBR call stack
can break the HW limitation. However, it may reconstruct invalid call
stacks in some cases, e.g. exception handing such as setjmp/longjmp.
Also, it may impact the processing time especially when the number of
samples with stitched LBRs are huge.
Add an option to enable the approach.
The option must be used with --call-graph lbr.
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
tools/perf/Documentation/perf-top.txt | 9 +
tools/perf/builtin-top.c | 11 +++
tools/perf/util/top.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/tools/perf/Documentation/perf-top.txt
b/tools/perf/Documentation/perf-top.txt
index 5596129a71cf..80b57f942a86 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -304,6 +304,15 @@ Default is to monitor all CPUS.
go straight to the histogram browser, just like 'perf top' with no
events
explicitely specified does.
+--stitch-lbr::
+ Show callgraph with stitched LBRs, which may have more complete
+ callgraph. The option must be used with --call-graph lbr recording.
+ Disabled by default. In common cases with call stack overflows,
+ it can recreate better call stacks than the default lbr call stack
+ output. But this approach is not full proof. There can be cases
+ where it creates incorrect call stacks from incorrect matches.
+ The known limitations include exception handing such as
+ setjmp/longjmp will have calls/returns not match.
INTERACTIVE PROMPTING KEYS
--
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 611d03030abc..539670377e0f 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -33,6 +33,7 @@
#include "util/map.h"
#include "util/mmap.h"
#include "util/session.h"
+#include "util/thread.h"
#include "util/symbol.h"
#include "util/synthetic-events.h"
#include "util/top.h"
@@ -764,6 +765,9 @@ static void perf_event__process_sample(struct perf_tool
*tool,
if (machine__resolve(machine, , sample) < 0)
return;
+ if (top->stitch_lbr)
+ al.thread->lbr_stitch_enable = true;
+
if (!machine->kptr_restrict_warned &&
symbol_conf.kptr_restrict &&
al.cpumode == PERF_RECORD_MISC_KERNEL) {
@@ -1537,6 +1541,8 @@ int cmd_top(int argc, const char **argv)
"number of thread to run event synthesize"),
OPT_BOOLEAN(0, "namespaces", >record_namespaces,
"Record namespaces events"),
+ OPT_BOOLEAN(0, "stitch-lbr", _lbr,
+ "Enable LBR callgraph stitching approach"),
OPTS_EVSWITCH(),
OPT_END()
};
@@ -1599,6 +1605,11 @@ int cmd_top(int argc, const char **argv)
}
}
+ if (top.stitch_lbr && !(callchain_param.record_mode == CALLCHAIN_LBR)) {
+ pr_err("Error: --stitch-lbr must be used with --call-graph
lbr\n");
+ goto out_delete_evlist;
+ }
+
if (opts->branch_stack && callchain_param.enabled)
symbol_conf.show_branchflag_count = true;
diff --git a/tools/perf/util/top.h b/tools/perf/util/top.h
index f117d4f4821e..45dc84ddff37 100644
--- a/tools/perf/util/top.h
+++ b/tools/perf/util/top.h
@@ -36,6 +36,7 @@ struct perf_top {
bool use_tui, use_stdio;
bool vmlinux_warned;
bool dump_symtab;
+ bool stitch_lbr;
struct hist_entry *sym_filter_entry;
struct evsel *sym_evsel;
struct perf_session *session;
--
2.17.1
[PATCH 07/10] perf report: Add option to enable the LBR stitching approach
From: Kan Liang
With the LBR stitching approach, the reconstructed LBR call stack
can break the HW limitation. However, it may reconstruct invalid call
stacks in some cases, e.g. exception handing such as setjmp/longjmp.
Also, it may impact the processing time especially when the number of
samples with stitched LBRs are huge.
Add an option to enable the approach.
# To display the perf.data header info, please use
# --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 6K of event 'cycles'
# Event count (approx.): 6492797701
#
# Children Self Command Shared Object Symbol
# ... ..
# .
#
99.99%99.99% tchain_edit tchain_edit[.] f43
|
---main
f1
f2
f3
f4
f5
f6
f7
f8
f9
f10
f11
f12
f13
f14
f15
f16
f17
f18
f19
f20
f21
f22
f23
f24
f25
f26
f27
f28
f29
f30
f31
|
--99.65%--f32
f33
f34
f35
f36
f37
f38
f39
f40
f41
f42
f43
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
tools/perf/Documentation/perf-report.txt | 11 +++
tools/perf/builtin-report.c | 6 ++
2 files changed, 17 insertions(+)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 7315f155803f..c0651b68ed5d 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -476,6 +476,17 @@ include::itrace.txt[]
This option extends the perf report to show reference callgraphs,
which collected by reference event, in no callgraph event.
+--stitch-lbr::
+ Show callgraph with stitched LBRs, which may have more complete
+ callgraph. The perf.data file must have been obtained using
+ perf record --call-graph lbr.
+ Disabled by default. In common cases with call stack overflows,
+ it can recreate better call stacks than the default lbr call stack
+ output. But this approach is not full proof. There can be cases
+ where it creates incorrect call stacks from incorrect matches.
+ The known limitations include exception handing such as
+ setjmp/longjmp will have calls/returns not match.
+
--socket-filter::
Only report the samples on the processor socket that match with this
filter
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index aae0e57c60fb..0d4275a46645 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -83,6 +83,7 @@ struct report {
boolheader_only;
boolnonany_branch_mode;
boolgroup_set;
+ boolstitch_lbr;
int max_stack;
struct perf_read_values show_threads_values;
struct annotation_options annotation_opts;
@@ -263,6 +264,9 @@ static int process_sample_event(struct perf_tool *tool,
return -1;
}
+ if (rep->stitch_lbr)
+ al.thread->lbr_stitch_enable = true;
+
if (symbol_conf.hide_unresolved && al.sym == NULL)
goto out_put;
@@ -1183,6 +1187,8 @@ int cmd_report(int argc, const char **argv)
"Show full source file name path for source lines"),
OPT_BOOLEAN(0, "show-ref-call-graph", _conf.show_ref_callgraph,
"Show callgraph from reference event"),
+ OPT_BOOLEAN(0, "stitch-lbr", _lbr,
+ "Enable LBR callgraph stitching approach"),
OPT_INTEGER(0, "socket-filter", _filter,
"only show processor socket that match with this filter"),
OPT_BOOLEAN(0, "raw-trace", _conf.raw_trace,
--
2.17.1
[PATCH 08/10] perf script: Add option to enable the LBR stitching approach
From: Kan Liang
With the LBR stitching approach, the reconstructed LBR call stack
can break the HW limitation. However, it may reconstruct invalid call
stacks in some cases, e.g. exception handing such as setjmp/longjmp.
Also, it may impact the processing time especially when the number of
samples with stitched LBRs are huge.
Add an option to enable the approach.
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
tools/perf/Documentation/perf-script.txt | 11 +++
tools/perf/builtin-script.c | 6 ++
2 files changed, 17 insertions(+)
diff --git a/tools/perf/Documentation/perf-script.txt
b/tools/perf/Documentation/perf-script.txt
index 2599b057e47b..472f20f1e479 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -426,6 +426,17 @@ include::itrace.txt[]
--show-on-off-events::
Show the --switch-on/off events too.
+--stitch-lbr::
+ Show callgraph with stitched LBRs, which may have more complete
+ callgraph. The perf.data file must have been obtained using
+ perf record --call-graph lbr.
+ Disabled by default. In common cases with call stack overflows,
+ it can recreate better call stacks than the default lbr call stack
+ output. But this approach is not full proof. There can be cases
+ where it creates incorrect call stacks from incorrect matches.
+ The known limitations include exception handing such as
+ setjmp/longjmp will have calls/returns not match.
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-script-perl[1],
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 67be8d31afab..0fc4d07864d1 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1641,6 +1641,7 @@ struct perf_script {
boolshow_bpf_events;
boolallocated;
boolper_event_dump;
+ boolstitch_lbr;
struct evswitch evswitch;
struct perf_cpu_map *cpus;
struct perf_thread_map *threads;
@@ -1867,6 +1868,9 @@ static void process_event(struct perf_script *script,
if (PRINT_FIELD(IP)) {
struct callchain_cursor *cursor = NULL;
+ if (script->stitch_lbr)
+ al->thread->lbr_stitch_enable = true;
+
if (symbol_conf.use_callchain && sample->callchain &&
thread__resolve_callchain(al->thread, _cursor,
evsel,
sample, NULL, NULL,
scripting_max_stack) == 0)
@@ -3556,6 +3560,8 @@ int cmd_script(int argc, const char **argv)
"file", "file saving guest os /proc/kallsyms"),
OPT_STRING(0, "guestmodules", _conf.default_guest_modules,
"file", "file saving guest os /proc/modules"),
+ OPT_BOOLEAN('\0', "stitch-lbr", _lbr,
+ "Enable LBR callgraph stitching approach"),
OPTS_EVSWITCH(),
OPT_END()
};
--
2.17.1
[PATCH 01/10] perf/core, x86: Add PERF_SAMPLE_LBR_TOS
From: Kan Liang
In LBR call stack mode, the depth of reconstructed LBR call stack limits
to the number of LBR registers. With LBR Top-of-Stack (TOS) information,
perf tool may stitch the stacks of two samples. The reconstructed LBR
call stack can break the HW limitation.
Add a new sample type for LBR TOS.
PEBS record doesn't store TOS information. For single PEBS, TOS can be
directly read from MSR, because the PMI is triggered immediately after
PEBS is written. TOS MSR is still unchanged.
For large PEBS, TOS MSR has stale value. Set -1ULL to indicate that the
TOS information is not available.
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
arch/x86/events/intel/lbr.c | 9 +
include/linux/perf_event.h | 1 +
include/uapi/linux/perf_event.h | 4 +++-
kernel/events/core.c| 12
4 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index ea54634eabf3..4640ff1c9ecb 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -562,6 +562,7 @@ static void intel_pmu_lbr_read_32(struct cpu_hw_events
*cpuc)
cpuc->lbr_entries[i].reserved = 0;
}
cpuc->lbr_stack.nr = i;
+ cpuc->lbr_stack.tos = tos;
}
/*
@@ -657,6 +658,7 @@ static void intel_pmu_lbr_read_64(struct cpu_hw_events
*cpuc)
out++;
}
cpuc->lbr_stack.nr = out;
+ cpuc->lbr_stack.tos = tos;
}
void intel_pmu_lbr_read(void)
@@ -1097,6 +1099,13 @@ void intel_pmu_store_pebs_lbrs(struct pebs_lbr *lbr)
int i;
cpuc->lbr_stack.nr = x86_pmu.lbr_nr;
+
+ /* Cannot get TOS for large PEBS */
+ if (cpuc->n_pebs == cpuc->n_large_pebs)
+ cpuc->lbr_stack.tos = -1ULL;
+ else
+ cpuc->lbr_stack.tos = intel_pmu_lbr_tos();
+
for (i = 0; i < x86_pmu.lbr_nr; i++) {
u64 info = lbr->lbr[i].info;
struct perf_branch_entry *e = >lbr_entries[i];
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 61448c19a132..ee9ef0c4cb08 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -100,6 +100,7 @@ struct perf_raw_record {
*/
struct perf_branch_stack {
__u64 nr;
+ __u64 tos;
struct perf_branch_entryentries[0];
};
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index bb7b271397a6..fe36ebb7dc2e 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -141,8 +141,9 @@ enum perf_event_sample_format {
PERF_SAMPLE_TRANSACTION = 1U << 17,
PERF_SAMPLE_REGS_INTR = 1U << 18,
PERF_SAMPLE_PHYS_ADDR = 1U << 19,
+ PERF_SAMPLE_LBR_TOS = 1U << 20,
- PERF_SAMPLE_MAX = 1U << 20, /* non-ABI */
+ PERF_SAMPLE_MAX = 1U << 21, /* non-ABI */
__PERF_SAMPLE_CALLCHAIN_EARLY = 1ULL << 63, /* non-ABI;
internal use */
};
@@ -864,6 +865,7 @@ enum perf_event_type {
* { u64 abi; # enum perf_sample_regs_abi
*u64 regs[weight(mask)]; } &&
PERF_SAMPLE_REGS_INTR
* { u64 phys_addr;} && PERF_SAMPLE_PHYS_ADDR
+* { u64 tos;} && PERF_SAMPLE_LBR_TOS
* };
*/
PERF_RECORD_SAMPLE = 9,
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 275eae05af20..6ab0913c7b36 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6468,6 +6468,15 @@ void perf_output_sample(struct perf_output_handle
*handle,
if (sample_type & PERF_SAMPLE_PHYS_ADDR)
perf_output_put(handle, data->phys_addr);
+ if (sample_type & PERF_SAMPLE_LBR_TOS) {
+ u64 tos = -1ULL;
+
+ if (data->br_stack)
+ tos = data->br_stack->tos;
+
+ perf_output_put(handle, tos);
+ }
+
if (!event->attr.watermark) {
int wakeup_events = event->attr.wakeup_events;
@@ -6656,6 +6665,9 @@ void perf_prepare_sample(struct perf_event_header *header,
if (sample_type & PERF_SAMPLE_PHYS_ADDR)
data->phys_addr = perf_virt_to_phys(data->addr);
+
+ if (sample_type & PERF_SAMPLE_LBR_TOS)
+ header->size += sizeof(u64);
}
static __always_inline int
--
2.17.1
[PATCH 00/10] Stitch LBR call stack
From: Kan Liang
Start from Haswell, Linux perf can utilize the existing Last Branch
Record (LBR) facility to record call stack. However, the depth of the
reconstructed LBR call stack limits to the number of LBR registers.
E.g. on skylake, the depth of reconstructed LBR call stack is <= 32
That's because HW will overwrite the oldest LBR registers when it's
full.
However, the overwritten LBRs may still be retrieved from previous
sample. At that moment, HW hasn't overwritten the LBR registers yet.
Perf tools can stitch those overwritten LBRs on current call stacks to
get a more complete call stack.
To determine if LBRs can be stitched, the physical index of LBR
registers is required. A new sample type is introduced in patch 1 & 2
to dump the LBR Top-of-Stack (TOS) information for perf tools.
Besides, the maximum number of LBRs is required as well. Patch 3 & 4
retrieve the capabilities information from sysfs and save them in perf
header.
Patch 5 & 6 implements the LBR stitching approach.
Users can use the options introduced in patch 7-10 to enable the LBR
stitching approach for perf report, script, top and c2c.
The stitching approach base on LBR call stack technology. The known
limitations of LBR call stack technology still apply to the approach,
e.g. Exception handing such as setjmp/longjmp will have calls/returns
not match.
This approach is not full proof. There can be cases where it creates
incorrect call stacks from incorrect matches. There is no attempt
to validate any matches in another way. So it is not enabled by default.
However in many common cases with call stack overflows it can recreate
better call stacks than the default lbr call stack output. So if there
are problems with LBR overflows this is a possible workaround.
Performance impact:
The processing time may increase with the LBR stitching approach
enabled. The impact depends on the number of samples with stitched LBRs.
For sqlite's tcltest,
perf record --call-graph lbr -- make tcltest
perf report --stitch-lbr
There are 4.11% samples has stitched LBRs.
Total number of samples:2833728
The number of samples with stitched LBRs116478
The processing time of perf report increases 6.8%
Without --stitch-lbr: 55906106 usec
With --stitch-lbr: 59728701 usec
For a simple test case tchain_edit with 43 depth of call stacks.
perf record --call-graph lbr -- ./tchain_edit
perf report --stitch-lbr
There are 99.9% samples has stitched LBRs.
Total number of samples:10915
The number of samples with stitched LBRs10905
The processing time of perf report increases 67.4%
Without --stitch-lbr: 11970508 usec
With --stitch-lbr: 20036055 usec
The source code of tchain_edit.c is something like as below.
noinline void f43(void)
{
int i;
for (i = 0; i < 1;) {
if(i%2)
i++;
else
i++;
}
}
noinline void f42(void)
{
int i;
for (i = 0; i < 100; i++) {
f43();
f43();
f43();
}
}
noinline void f41(void)
{
int i;
for (i = 0; i < 100; i++) {
f42();
f42();
f42();
}
}
noinline void f40(void)
{
f41();
}
... ...
noinline void f32(void)
{
f33();
}
noinline void f31(void)
{
int i;
for (i = 0; i < 1; i++) {
if(i%2)
i++;
else
i++;
}
f32();
}
noinline void f30(void)
{
f31();
}
... ...
noinline void f1(void)
{
f2();
}
int main()
{
f1();
}
Kan Liang (10):
perf/core, x86: Add PERF_SAMPLE_LBR_TOS
perf tools: Support PERF_SAMPLE_LBR_TOS
perf pmu: Add support for PMU capabilities
perf header: Support CPU PMU capabilities
perf machine: Refine the function for LBR call stack reconstruction
perf tools: Stitch LBR call stack
perf report: Add option to enable the LBR stitching approach
perf script: Add option to enable the LBR stitching approach
perf top: Add option to enable the LBR stitching approach
perf c2c: Add option to enable the LBR stitching approach
arch/x86/events/intel/lbr.c | 9 +
include/linux/perf_event.h| 1 +
include/uapi/linux/perf_event.h | 4 +-
kernel/events/core.c | 12 +
tools/include/uapi/linux/perf_event.h | 4 +-
tools/perf/Documentation/perf-c2c.txt | 11 +
tools/perf/Documentation/perf-report.txt | 11 +
tools/perf/Documentation/perf-script.txt | 11 +
tools/perf/Documentation/perf-top.txt | 9 +
.../Documentation/perf.data-file-format.txt | 16 +
tools/perf/builtin-c2c.c | 6 +
tools/perf/builtin-record.c
[PATCH 06/10] perf tools: Stitch LBR call stack
From: Kan Liang
In LBR call stack mode, the depth of reconstructed LBR call stack limits
to the number of LBR registers.
For example, on skylake, the depth of reconstructed LBR call stack is
always <= 32.
# To display the perf.data header info, please use
# --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 6K of event 'cycles'
# Event count (approx.): 6487119731
#
# Children Self Command Shared Object Symbol
# ... ..
#
99.97%99.97% tchain_edit tchain_edit[.] f43
|
--99.64%--f11
f12
f13
f14
f15
f16
f17
f18
f19
f20
f21
f22
f23
f24
f25
f26
f27
f28
f29
f30
f31
f32
f33
f34
f35
f36
f37
f38
f39
f40
f41
f42
f43
For a call stack which is deeper than LBR limit, HW will overwrite the
LBR register with oldest branch. Only partial call stacks can be
reconstructed.
However, the overwritten LBRs may still be retrieved from previous
sample. At that moment, HW hasn't overwritten the LBR registers yet.
Perf tools can stitch those overwritten LBRs on current call stacks to
get a more complete call stack.
To determine if LBRs can be stitched, perf tools need to compare current
sample with previous sample.
- They should have identical LBR records (Same from, to and flags
values, and the same physical index of LBR registers).
- The searching starts from the base-of-stack of current sample.
Add prev_sample in struct thread to save the previous sample.
Add lbr_stitch_lists to save the LBRs can be used to stitch.
lbr_stitch_enable is used to indicate whether enable LBR stitch
approach, which is disabled by default. The following patch will
introduce a new option to enable the LBR stitch approach.
This is because,
- The stitching approach base on LBR call stack technology. The known
limitations of LBR call stack technology still apply to the approach,
e.g. Exception handing such as setjmp/longjmp will have calls/returns
not match.
- This approach is not full proof. There can be cases where it creates
incorrect call stacks from incorrect matches. There is no attempt
to validate any matches in another way. So it is not enabled by default.
However in many common cases with call stack overflows it can recreate
better call stacks than the default lbr call stack output. So if there
are problems with LBR overflows this is a possible workaround.
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
tools/perf/util/branch.h | 10 ++-
tools/perf/util/machine.c | 125 +-
tools/perf/util/thread.c | 3 +
tools/perf/util/thread.h | 18 ++
4 files changed, 152 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/branch.h b/tools/perf/util/branch.h
index 88e00d268f6f..a9c399703281 100644
--- a/tools/perf/util/branch.h
+++ b/tools/perf/util/branch.h
@@ -34,7 +34,15 @@ struct branch_info {
struct branch_entry {
u64 from;
u64 to;
- struct branch_flags flags;
+ union {
+ struct branch_flags flags;
+ u64 flags_value;
+ };
+};
+
+struct stitch_list {
+ struct list_headnode;
+ struct branch_entry br_entry;
};
struct branch_stack {
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index e3e516e30093..02bd1740d547 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -2273,6 +2273,98 @@ static int lbr_callchain_add_lbr_ip(struct thread
*thread,
return 0;
}
+static int lbr_callchain_add_stitched_lbr_ip(struct thread *thread,
+struct callchain_cursor *cursor,
+struct symbol **parent,
+struct addr_location *root_al)
+{
+ u8 cpumode = PERF_RECORD_MISC_USER;
+ struct stitch_list *stitch_node;
+ struct branch_flags *flags;
+ int err;
+ u64 ip;
+
+ list_for_each_entry(stitch_node, >lbr_stitch_lists, node) {
+ ip = stitch_node->br_entry.from;
+ flags = _node->br_entry.flags;
+
+
[PATCH 04/10] perf header: Support CPU PMU capabilities
From: Kan Liang
To stitch LBR call stack, the max LBR information is required. So the
CPU PMU capabilities information has to be stored in perf header.
Add a new feature HEADER_CPU_PMU_CAPS for CPU PMU capabilities.
Retrieve all CPU PMU capabilities, not just max LBR information.
Add variable max_branches to facilitate future usage.
The CPU PMU capabilities information is only useful for LBR call stack
mode. Clear the feature for perf stat and other perf record mode.
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
.../Documentation/perf.data-file-format.txt | 16 +++
tools/perf/builtin-record.c | 3 +
tools/perf/builtin-stat.c | 1 +
tools/perf/util/env.h | 3 +
tools/perf/util/header.c | 110 ++
tools/perf/util/header.h | 1 +
6 files changed, 134 insertions(+)
diff --git a/tools/perf/Documentation/perf.data-file-format.txt
b/tools/perf/Documentation/perf.data-file-format.txt
index b0152e1095c5..b6472e463284 100644
--- a/tools/perf/Documentation/perf.data-file-format.txt
+++ b/tools/perf/Documentation/perf.data-file-format.txt
@@ -373,6 +373,22 @@ struct {
Indicates that trace contains records of PERF_RECORD_COMPRESSED type
that have perf_events records in compressed form.
+ HEADER_CPU_PMU_CAPS = 28,
+
+ A list of cpu PMU capabilities. The format of data is as below.
+
+struct {
+ u32 nr_cpu_pmu_caps;
+ {
+ charname[];
+ charvalue[];
+ } [nr_cpu_pmu_caps]
+};
+
+
+Example:
+ cpu pmu capabilities: branches=32, max_precise=3, pmu_name=icelake
+
other bits are reserved and should ignored for now
HEADER_FEAT_BITS= 256,
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 23332861de6e..fbbeb1e625ef 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1057,6 +1057,9 @@ static void record__init_features(struct record *rec)
if (!record__comp_enabled(rec))
perf_header__clear_feat(>header, HEADER_COMPRESSED);
+ if (!callchain_param.enabled || (callchain_param.record_mode !=
CALLCHAIN_LBR))
+ perf_header__clear_feat(>header, HEADER_CPU_PMU_CAPS);
+
perf_header__clear_feat(>header, HEADER_STAT);
}
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 468fc49420ce..26bb9794e95a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1418,6 +1418,7 @@ static void init_features(struct perf_session *session)
perf_header__clear_feat(>header, HEADER_TRACING_DATA);
perf_header__clear_feat(>header, HEADER_BRANCH_STACK);
perf_header__clear_feat(>header, HEADER_AUXTRACE);
+ perf_header__clear_feat(>header, HEADER_CPU_PMU_CAPS);
}
static int __cmd_record(int argc, const char **argv)
diff --git a/tools/perf/util/env.h b/tools/perf/util/env.h
index a3059dc1abe5..dae64e20b280 100644
--- a/tools/perf/util/env.h
+++ b/tools/perf/util/env.h
@@ -48,6 +48,7 @@ struct perf_env {
char*cpuid;
unsigned long long total_mem;
unsigned intmsr_pmu_type;
+ unsigned intmax_branches;
int nr_cmdline;
int nr_sibling_cores;
@@ -57,12 +58,14 @@ struct perf_env {
int nr_memory_nodes;
int nr_pmu_mappings;
int nr_groups;
+ int nr_cpu_pmu_caps;
char*cmdline;
const char **cmdline_argv;
char*sibling_cores;
char*sibling_dies;
char*sibling_threads;
char*pmu_mappings;
+ char*cpu_pmu_caps;
struct cpu_topology_map *cpu;
struct cpu_cache_level *caches;
int caches_cnt;
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 86d9396cb131..b8d0487f0cea 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1402,6 +1402,39 @@ static int write_compressed(struct feat_fd *ff
__maybe_unused,
return do_write(ff, &(ff->ph->env.comp_mmap_len),
sizeof(ff->ph->env.comp_mmap_len));
}
+static int write_cpu_pmu_caps(struct feat_fd *ff,
+ struct evlist *evlist __maybe_unused)
+{
+ struct perf_pmu_caps *caps = NULL;
+ struct perf_pmu *cpu_pmu;
+ int nr_caps;
+ int ret;
+
+ cpu_pmu = perf_pmu__find("cpu");
+ if (!cpu_pmu)
+ return -ENOENT;
+
+ nr_caps = perf_pmu__caps_parse(cpu_pmu);
+ if (nr_caps < 0)
+ return nr_caps;
+
+ ret = do_write(ff, _caps, sizeof(nr_caps));
+ if (ret < 0)
+ return ret;
+
+ while ((caps =
Re: [RESEND PATCH 0/5] Add bluetooth support for Orange Pi 3
On Mon, Oct 07, 2019 at 04:11:53PM +0200, Ondřej Jirman wrote: > Hi Maxime, > > On Fri, Aug 23, 2019 at 12:31:34PM +0200, megous hlavni wrote: > > From: Ondrej Jirman > > > > (Resend to add missing lists, sorry for the noise.) > > > > This series implements bluetooth support for Xunlong Orange Pi 3 board. > > > > The board uses AP6256 WiFi/BT 5.0 chip. > > > > Summary of changes: > > > > - add more delay to let initialize the chip > > - let the kernel detect firmware file path > > - add new compatible and update dt-bindings > > - update Orange Pi 3 / H6 DTS > > Please consider the DTS patches for 5.5. Can you resend them? I don't have access to my old mailbox anymore Maxime signature.asc Description: PGP signature
Re: [PATCH] mips: check for dsp presence only once before save/restore
Hello,
Aurabindo Jayamohanan wrote:
> {save,restore}_dsp() internally checks if the cpu has dsp support.
> Therefore, explicit check is not required before calling them in
> {save,restore}_processor_state()
Applied to mips-next.
> commit 9662dd752c14
> https://git.kernel.org/mips/c/9662dd752c14
>
> Signed-off-by: Aurabindo Jayamohanan
> Signed-off-by: Paul Burton
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.bur...@mips.com to report it. ]
Re: ehci-pci breakage with dma-mapping changes in 5.4-rc2
On Mon, Oct 07, 2019 at 10:56:30AM -0700, Christoph Hellwig wrote: > On Mon, Oct 07, 2019 at 07:55:28PM +0200, Christoph Hellwig wrote: > > On Mon, Oct 07, 2019 at 01:54:32PM -0400, Arvind Sankar wrote: > > > It doesn't boot with the patch. Won't it go > > > dma_get_required_mask > > > -> intel_get_required_mask > > > -> iommu_need_mapping > > > -> dma_get_required_mask > > > ? > > > > > > Should the call to dma_get_required_mask in iommu_need_mapping be > > > replaced with dma_direct_get_required_mask on top of your patch? > > > > Yes, sorry. > > Actually my patch already calls dma_direct_get_required_mask. > How did you get the loop? The function iommu_need_mapping (not changed by your patch) calls dma_get_required_mask internally, to check whether the device's dma_mask is big enough or not. That's the call I was asking whether it needs to be changed.
Re: [PATCH v2 1/5] arm64: dts: qcom: sdm845: Add unit name to soc node
On Mon, Oct 7, 2019 at 12:44 PM John Stultz wrote:
>
> On Tue, Jul 23, 2019 at 9:51 PM Vinod Koul wrote:
> >
> > We get a warning about missing unit name for soc node, so add it.
> >
> > arch/arm64/boot/dts/qcom/sdm845.dtsi:623.11-2814.4: Warning
> > (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit
> > name
> >
> > Signed-off-by: Vinod Koul
> > Reviewed-by: Stephen Boyd
> > ---
> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index 601cfb078bd5..e81f4a6d08ce 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -620,7 +620,7 @@
> > method = "smc";
> > };
> >
> > - soc: soc {
> > + soc: soc@0 {
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges = <0 0 0 0 0x10 0>;
>
> So Amit Pundir noted that this patch is causing 5.4-rc to no longer
> boot on db845 w/ AOSP, due to it changing the userland sysfs paths
> from "/devices/platform/soc/1a0.mdss" to
> "/devices/platform/soc@0/1a0.mdss"
>
> Is there a better solution here that might not break userspace?
Other than doing the right thing of not relying on
/sys/devices/platform/* paths, implement per target/file DTC_FLAGS
similar to CFLAGS. There is another want for this in order to enable
dtc symbols for overlays on a per board basis.
Rob
Re: [PATCH] rcu/nocb: Fix dump_tree hierarchy print always active
On 07/10/2019 03:26, Paul E. McKenney wrote:
>
> On Fri, Oct 04, 2019 at 03:24:02PM -0700, Paul E. McKenney wrote:
>> On Fri, Oct 04, 2019 at 07:49:10PM +, Stefan Reiter wrote:
>>> Commit 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if
>>> dump_tree") added print statements to rcu_organize_nocb_kthreads for
>>> debugging, but incorrectly guarded them, causing the function to always
>>> spew out its message.
>>>
>>> This patch fixes it by guarding both pr_alert statements with dump_tree,
>>> while also changing the second pr_alert to a pr_cont, to print the
>>> hierarchy in a single line (assuming that's how it was supposed to
>>> work).
>>>
>>> Fixes: 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if dump_tree")
>>> Signed-off-by: Stefan Reiter
>>
>> Queued for testing and review, thank you!
>
> And here is an updated version to make the special case of a nocb GP
> kthread having no other nocb CB kthreads look less strange. Does this
> work for you?
Tested just now, works for me. Thanks for the additional fix!
>
> Thanx, Paul
>
>
>
> commit e6223b0705369750990c32ddc80251942e61be30
> Author: Stefan Reiter
> Date: Fri Oct 4 19:49:10 2019 +
>
> rcu/nocb: Fix dump_tree hierarchy print always active
>
> Commit 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if
> dump_tree") added print statements to rcu_organize_nocb_kthreads for
> debugging, but incorrectly guarded them, causing the function to always
> spew out its message.
>
> This patch fixes it by guarding both pr_alert statements with dump_tree,
> while also changing the second pr_alert to a pr_cont, to print the
> hierarchy in a single line (assuming that's how it was supposed to
> work).
>
> Fixes: 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if
> dump_tree")
> Signed-off-by: Stefan Reiter
> [ paulmck: Make single-nocbs-CPU GP kthreads look less erroneous. ]
> Signed-off-by: Paul E. McKenney
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index d5334e4..d43f4e0 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -2295,6 +2295,8 @@ static void __init rcu_organize_nocb_kthreads(void)
> {
> int cpu;
> bool firsttime = true;
> + bool gotnocbs = false;
> + bool gotnocbscbs = true;
> int ls = rcu_nocb_gp_stride;
> int nl = 0; /* Next GP kthread. */
> struct rcu_data *rdp;
> @@ -2317,21 +2319,31 @@ static void __init rcu_organize_nocb_kthreads(void)
> rdp = per_cpu_ptr(_data, cpu);
> if (rdp->cpu >= nl) {
> /* New GP kthread, set up for CBs & next GP. */
> + gotnocbs = true;
> nl = DIV_ROUND_UP(rdp->cpu + 1, ls) * ls;
> rdp->nocb_gp_rdp = rdp;
> rdp_gp = rdp;
> - if (!firsttime && dump_tree)
> - pr_cont("\n");
> - firsttime = false;
> - pr_alert("%s: No-CB GP kthread CPU %d:", __func__, cpu);
> + if (dump_tree) {
> + if (!firsttime)
> + pr_cont("%s\n", gotnocbscbs
> + ? "" : " (self only)");
> + gotnocbscbs = false;
> + firsttime = false;
> + pr_alert("%s: No-CB GP kthread CPU %d:",
> + __func__, cpu);
> + }
> } else {
> /* Another CB kthread, link to previous GP kthread. */
> + gotnocbscbs = true;
> rdp->nocb_gp_rdp = rdp_gp;
> rdp_prev->nocb_next_cb_rdp = rdp;
> - pr_alert(" %d", cpu);
> + if (dump_tree)
> + pr_cont(" %d", cpu);
> }
> rdp_prev = rdp;
> }
> + if (gotnocbs && dump_tree)
> + pr_cont("%s\n", gotnocbscbs ? "" : " (self only)");
> }
>
> /*
>
Re: ehci-pci breakage with dma-mapping changes in 5.4-rc2
On Mon, Oct 07, 2019 at 07:55:28PM +0200, Christoph Hellwig wrote: > On Mon, Oct 07, 2019 at 01:54:32PM -0400, Arvind Sankar wrote: > > It doesn't boot with the patch. Won't it go > > dma_get_required_mask > > -> intel_get_required_mask > > -> iommu_need_mapping > > -> dma_get_required_mask > > ? > > > > Should the call to dma_get_required_mask in iommu_need_mapping be > > replaced with dma_direct_get_required_mask on top of your patch? > > Yes, sorry. Actually my patch already calls dma_direct_get_required_mask. How did you get the loop?
Re: [PATCH v22 09/24] x86/sgx: Add functions to allocate and free EPC pages
On Sat, Oct 05, 2019 at 06:44:08PM +0200, Borislav Petkov wrote: > > +static struct sgx_epc_page *sgx_section_get_page( > > That fits into 80 cols (oh well, 81) and even if not, a trailing opening > arg brace is ugly. But checkpatch.pl will complain about it... /Jarkko
[RFC][PATCH v2 0/5] dwc3: Changes for HiKey960 support
I've been carrying for awhile some patches that Yu Chen was previously pushing upstream to enable USB on the HiKey960 board and I wanted to try to nudge them forward as I'm not sure as to what his plans are. This series is just the simpler parts of the patch set that I wanted to send out to see if we could make some progress on while I continue to work on the more complex bits. You can find the full set of changes to get USB working on the board here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?id=ef858be80f202b7bffb7d03c168ee72457a0ef3e This series is just the more trivial changes, along with some missing binding documentation that I've added. I'd greatly appreciate any review or feedback on this series! thanks -john New in v2: * Tweaked binding clock name as clk_usb3phy_ref didn't seem right. Cc: Greg Kroah-Hartman Cc: Felipe Balbi Cc: Andy Shevchenko Cc: Rob Herring Cc: Mark Rutland Cc: Yu Chen Cc: Matthias Brugger Cc: Chunfeng Yun Cc: linux-...@vger.kernel.org Cc: devicet...@vger.kernel.org John Stultz (2): dt-bindings: usb: dwc3: Add a property to do a CGTL soft reset on mode switching dt-bindings: usb: dwc3: of-simple: add compatible for HiSi Yu Chen (3): usb: dwc3: Execute GCTL Core Soft Reset while switch mdoe for Hisilicon Kirin Soc usb: dwc3: Increase timeout for CmdAct cleared by device controller usb: dwc3: dwc3-of-simple: Add support for dwc3 of Hisilicon Soc Platform .../devicetree/bindings/usb/dwc3.txt | 2 + .../devicetree/bindings/usb/hisi,dwc3.txt | 52 +++ drivers/usb/dwc3/core.c | 20 +++ drivers/usb/dwc3/core.h | 3 ++ drivers/usb/dwc3/dwc3-of-simple.c | 4 +- drivers/usb/dwc3/gadget.c | 2 +- 6 files changed, 81 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/hisi,dwc3.txt -- 2.17.1
[RFC][PATCH v2 3/5] usb: dwc3: Increase timeout for CmdAct cleared by device controller
From: Yu Chen
It needs more time for the device controller to clear the CmdAct of
DEPCMD on Hisilicon Kirin Soc.
Cc: Greg Kroah-Hartman
Cc: Felipe Balbi
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: Yu Chen
Cc: Matthias Brugger
Cc: Chunfeng Yun
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: Yu Chen
Signed-off-by: John Stultz
---
drivers/usb/dwc3/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 8adb59f8e4f1..81907e163252 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -270,7 +270,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned
cmd,
{
const struct usb_endpoint_descriptor *desc = dep->endpoint.desc;
struct dwc3 *dwc = dep->dwc;
- u32 timeout = 1000;
+ u32 timeout = 5000;
u32 saved_config = 0;
u32 reg;
--
2.17.1
[RFC][PATCH v2 1/5] dt-bindings: usb: dwc3: Add a property to do a CGTL soft reset on mode switching
Provide a dt-binding for quirk needed to do a GCTL soft reset on mode switching Cc: Greg Kroah-Hartman Cc: Felipe Balbi Cc: Andy Shevchenko Cc: Rob Herring Cc: Mark Rutland Cc: Yu Chen Cc: Matthias Brugger Cc: Chunfeng Yun Cc: linux-...@vger.kernel.org Cc: devicet...@vger.kernel.org Signed-off-by: John Stultz --- Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 66780a47ad85..cf4ef6c22fb3 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -77,6 +77,8 @@ Optional properties: during HS transmit. - snps,dis_metastability_quirk: when set, disable metastability workaround. CAUTION: use only if you are absolutely sure of it. + - snps,gctl-reset-quirk: when set, GCTL soft reset will be executed on mode + switch. - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal utmi_l1_suspend_n, false when asserts utmi_sleep_n - snps,hird-threshold: HIRD threshold -- 2.17.1
[RFC][PATCH v2 4/5] dt-bindings: usb: dwc3: of-simple: add compatible for HiSi
Add necessary compatible flag for HiSi's DWC3 so
dwc3-of-simple will probe.
Cc: Greg Kroah-Hartman
Cc: Felipe Balbi
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: Yu Chen
Cc: Matthias Brugger
Cc: Chunfeng Yun
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: John Stultz
---
v2: Tweaked clock names as clk_usb3phy_ref didn't seem right.
---
.../devicetree/bindings/usb/hisi,dwc3.txt | 52 +++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/hisi,dwc3.txt
diff --git a/Documentation/devicetree/bindings/usb/hisi,dwc3.txt
b/Documentation/devicetree/bindings/usb/hisi,dwc3.txt
new file mode 100644
index ..3a3e5c320f2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/hisi,dwc3.txt
@@ -0,0 +1,52 @@
+HiSi SuperSpeed DWC3 USB SoC controller
+
+Required properties:
+- compatible: should contain "hisilicon,hi3660-dwc3" for HiSi SoC
+- clocks: A list of phandle + clock-specifier pairs for the
+ clocks listed in clock-names
+- clock-names: Should contain the following:
+ "clk_abb_usb"USB reference clk
+ "aclk_usb3otg" USB3 OTG aclk
+
+- assigned-clocks: Should be:
+ HI3660_ACLK_GATE_USB3OTG
+- assigned-clock-rates: Should be:
+ 229Mhz (22900) for HI3660_ACLK_GATE_USB3OTG
+
+Optional properties:
+- resets: Phandle to reset control that resets core and wrapper.
+
+Required child node:
+A child node must exist to represent the core DWC3 IP block. The name of
+the node is not important. The content of the node is defined in dwc3.txt.
+
+Example device nodes:
+
+ usb3: hisi_dwc3 {
+ compatible = "hisilicon,hi3660-dwc3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ clocks = <_ctrl HI3660_CLK_ABB_USB>,
+<_ctrl HI3660_ACLK_GATE_USB3OTG>;
+ clock-names = "clk_abb_usb", "aclk_usb3otg";
+
+ assigned-clocks = <_ctrl HI3660_ACLK_GATE_USB3OTG>;
+ assigned-clock-rates = <229 000 000>;
+ resets = <_rst 0x90 8>,
+<_rst 0x90 7>,
+<_rst 0x90 6>,
+<_rst 0x90 5>;
+
+ dwc3: dwc3@ff10 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xff10 0x0 0x10>;
+ interrupts = <0 159 4>, <0 161 4>;
+ phys = <_phy>;
+ phy-names = "usb3-phy";
+ dr_mode = "otg";
+
+ ...
+ };
+ };
--
2.17.1
[RFC][PATCH v2 2/5] usb: dwc3: Execute GCTL Core Soft Reset while switch mdoe for Hisilicon Kirin Soc
From: Yu Chen
A GCTL soft reset should be executed when switch mode for dwc3 core
of Hisilicon Kirin Soc.
Cc: Greg Kroah-Hartman
Cc: Felipe Balbi
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: Yu Chen
Cc: Matthias Brugger
Cc: Chunfeng Yun
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: Yu Chen
Signed-off-by: John Stultz
---
drivers/usb/dwc3/core.c | 20
drivers/usb/dwc3/core.h | 3 +++
2 files changed, 23 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 999ce5e84d3c..440261432421 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -112,6 +112,19 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
dwc->current_dr_role = mode;
}
+static void dwc3_gctl_core_soft_reset(struct dwc3 *dwc)
+{
+ u32 reg;
+
+ reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+ reg |= DWC3_GCTL_CORESOFTRESET;
+ dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+
+ reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+ reg &= ~DWC3_GCTL_CORESOFTRESET;
+ dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+}
+
static void __dwc3_set_mode(struct work_struct *work)
{
struct dwc3 *dwc = work_to_dwc(work);
@@ -156,6 +169,10 @@ static void __dwc3_set_mode(struct work_struct *work)
dwc3_set_prtcap(dwc, dwc->desired_dr_role);
+ /* Execute a GCTL Core Soft Reset when switch mode */
+ if (dwc->gctl_reset_quirk)
+ dwc3_gctl_core_soft_reset(dwc);
+
spin_unlock_irqrestore(>lock, flags);
switch (dwc->desired_dr_role) {
@@ -1316,6 +1333,9 @@ static void dwc3_get_properties(struct dwc3 *dwc)
dwc->dis_metastability_quirk = device_property_read_bool(dev,
"snps,dis_metastability_quirk");
+ dwc->gctl_reset_quirk = device_property_read_bool(dev,
+ "snps,gctl-reset-quirk");
+
dwc->lpm_nyet_threshold = lpm_nyet_threshold;
dwc->tx_de_emphasis = tx_de_emphasis;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 1c8b349379af..b3cb6eec3f8f 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1029,6 +1029,7 @@ struct dwc3_scratchpad_array {
* 2 - No de-emphasis
* 3 - Reserved
* @dis_metastability_quirk: set to disable metastability quirk.
+ * @gctl_reset_quirk: set to do a gctl soft-reset while switch operation mode.
* @imod_interval: set the interrupt moderation interval in 250ns
* increments or 0 to disable.
*/
@@ -1219,6 +1220,8 @@ struct dwc3 {
unsigneddis_metastability_quirk:1;
+ unsignedgctl_reset_quirk:1;
+
u16 imod_interval;
};
--
2.17.1
[RFC][PATCH v2 5/5] usb: dwc3: dwc3-of-simple: Add support for dwc3 of Hisilicon Soc Platform
From: Yu Chen
This patch adds support for the poweron and shutdown of dwc3 core
on Hisilicon Soc Platform.
Cc: Greg Kroah-Hartman
Cc: Felipe Balbi
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: Yu Chen
Cc: Matthias Brugger
Cc: Chunfeng Yun
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: Yu Chen
Signed-off-by: John Stultz
---
drivers/usb/dwc3/dwc3-of-simple.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
b/drivers/usb/dwc3/dwc3-of-simple.c
index bdac3e7d7b18..78617500edee 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -51,7 +51,8 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
* Some controllers need to toggle the usb3-otg reset before trying to
* initialize the PHY, otherwise the PHY times out.
*/
- if (of_device_is_compatible(np, "rockchip,rk3399-dwc3"))
+ if (of_device_is_compatible(np, "rockchip,rk3399-dwc3") ||
+ of_device_is_compatible(np, "hisilicon,hi3660-dwc3"))
simple->need_reset = true;
if (of_device_is_compatible(np, "amlogic,meson-axg-dwc3") ||
@@ -183,6 +184,7 @@ static const struct of_device_id of_dwc3_simple_match[] = {
{ .compatible = "amlogic,meson-axg-dwc3" },
{ .compatible = "amlogic,meson-gxl-dwc3" },
{ .compatible = "allwinner,sun50i-h6-dwc3" },
+ { .compatible = "hisilicon,hi3660-dwc3" },
{ /* Sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
--
2.17.1
Re: ehci-pci breakage with dma-mapping changes in 5.4-rc2
On Mon, Oct 07, 2019 at 01:54:32PM -0400, Arvind Sankar wrote: > It doesn't boot with the patch. Won't it go > dma_get_required_mask > -> intel_get_required_mask > -> iommu_need_mapping > -> dma_get_required_mask > ? > > Should the call to dma_get_required_mask in iommu_need_mapping be > replaced with dma_direct_get_required_mask on top of your patch? Yes, sorry.
[PATCH] x86/purgatory: Make sure we fail the build if purgatory.ro has missing symbols
Since we link purgatory.ro with -r aka we enable "incremental linking" no checks for unresolved symbols is done while linking purgatory.ro. Changes to the sha256 code has caused the purgatory in 5.4-rc1 to have a missing symbol on memzero_explicit, yet things still happily build. This commit adds an extra check for unresolved symbols by calling ld without -r before running bin2c to generate kexec-purgatory.c. This causes a build of 5.4-rc1 with this patch added to fail as it should: CHK arch/x86/purgatory/purgatory.ro ld: arch/x86/purgatory/purgatory.ro: in function `sha256_transform': sha256.c:(.text+0x1c0c): undefined reference to `memzero_explicit' make[2]: *** [arch/x86/purgatory/Makefile:72: arch/x86/purgatory/kexec-purgatory.c] Error 1 make[1]: *** [scripts/Makefile.build:509: arch/x86/purgatory] Error 2 make: *** [Makefile:1650: arch/x86] Error 2 This will help us catch missing symbols in the purgatory sooner. Note this commit also removes --no-undefined from LDFLAGS_purgatory.ro as that has no effect. Signed-off-by: Hans de Goede --- arch/x86/purgatory/Makefile | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile index fb4ee5444379..0da0794ef1f0 100644 --- a/arch/x86/purgatory/Makefile +++ b/arch/x86/purgatory/Makefile @@ -14,7 +14,7 @@ $(obj)/sha256.o: $(srctree)/lib/crypto/sha256.c FORCE CFLAGS_sha256.o := -D__DISABLE_EXPORTS -LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostdlib -z nodefaultlib +LDFLAGS_purgatory.ro := -e purgatory_start -r -nostdlib -z nodefaultlib targets += purgatory.ro KASAN_SANITIZE := n @@ -60,10 +60,16 @@ $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE targets += kexec-purgatory.c +# Since we link purgatory.ro with -r unresolved symbols are not checked, +# so we check this before generating kexec-purgatory.c instead +quiet_cmd_check_purgatory = CHK $< + cmd_check_purgatory = ld -e purgatory_start $< + quiet_cmd_bin2c = BIN2C $@ cmd_bin2c = $(objtree)/scripts/bin2c kexec_purgatory < $< > $@ $(obj)/kexec-purgatory.c: $(obj)/purgatory.ro FORCE + $(call if_changed,check_purgatory) $(call if_changed,bin2c) obj-$(CONFIG_KEXEC_FILE) += kexec-purgatory.o -- 2.23.0
Re: ehci-pci breakage with dma-mapping changes in 5.4-rc2
On Mon, Oct 07, 2019 at 09:34:48AM +0200, Christoph Hellwig wrote:
> Hi Arvind,
>
> can you try the patch below?
>
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 3f974919d3bd..52b709bf2b55 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -3775,6 +3775,13 @@ static int intel_map_sg(struct device *dev, struct
> scatterlist *sglist, int nele
> return nelems;
> }
>
> +static u64 intel_get_required_mask(struct device *dev)
> +{
> + if (!iommu_need_mapping(dev))
> + return dma_direct_get_required_mask(dev);
> + return DMA_BIT_MASK(32);
> +}
> +
> static const struct dma_map_ops intel_dma_ops = {
> .alloc = intel_alloc_coherent,
> .free = intel_free_coherent,
> @@ -3787,6 +3794,7 @@ static const struct dma_map_ops intel_dma_ops = {
> .dma_supported = dma_direct_supported,
> .mmap = dma_common_mmap,
> .get_sgtable = dma_common_get_sgtable,
> + .get_required_mask = intel_get_required_mask,
> };
>
> static void
It doesn't boot with the patch. Won't it go
dma_get_required_mask
-> intel_get_required_mask
-> iommu_need_mapping
-> dma_get_required_mask
?
Should the call to dma_get_required_mask in iommu_need_mapping be
replaced with dma_direct_get_required_mask on top of your patch?
Re: [PATCH v2 4/5] MIPS: CI20: DTS: Add Leds
Hello, Alexandre GRIVEAUX wrote: > Adding leds and related triggers. Applied to mips-next. > commit 24b0cb4f883a > https://git.kernel.org/mips/c/24b0cb4f883a > > Signed-off-by: Alexandre GRIVEAUX > Signed-off-by: Paul Burton Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH v2 3/5] MIPS: CI20: DTS: Add IW8103 Wifi + bluetooth
Hello, Alexandre GRIVEAUX wrote: > Add IW8103 Wifi + bluetooth module to device tree and related power domain. Applied to mips-next. > commit 948f2708f945 > https://git.kernel.org/mips/c/948f2708f945 > > Signed-off-by: Alexandre GRIVEAUX > Signed-off-by: Paul Burton Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH v2 2/5] MIPS: CI20: DTS: Add I2C nodes
Hello, Alexandre GRIVEAUX wrote: > Adding missing I2C nodes and some peripheral: > - PMU > - RTC Applied to mips-next. > commit 73f2b940474d > https://git.kernel.org/mips/c/73f2b940474d > > Signed-off-by: Alexandre GRIVEAUX > Signed-off-by: Paul Burton Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH 1/2] MIPS: SGI-IP27: remove not used stuff inherited from IRIX
Hello, Thomas Bogendoerfer wrote: > Most of the SN/SN0 header files are inherited from IRIX header files, > but not all of that stuff is useful for Linux. Remove not used parts. Series applied to mips-next. > MIPS: SGI-IP27: remove not used stuff inherited from IRIX > commit 46a73e9e6ccc > https://git.kernel.org/mips/c/46a73e9e6ccc > > Signed-off-by: Thomas Bogendoerfer > Signed-off-by: Paul Burton > > MIPS: SGI-IP27: get rid of compact node ids > commit 4bf841ebf17a > https://git.kernel.org/mips/c/4bf841ebf17a > > Signed-off-by: Thomas Bogendoerfer > Signed-off-by: Paul Burton Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH v2 1/5] MIPS: JZ4780: DTS: Add I2C nodes
Hello, Alexandre GRIVEAUX wrote: > Add the devicetree nodes for the I2C core of the JZ4780 SoC, disabled > by default. Applied to mips-next. > commit f56a040c9faf > https://git.kernel.org/mips/c/f56a040c9faf > > Signed-off-by: Alexandre GRIVEAUX > Signed-off-by: Paul Burton Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH v2] mips: sgi-ip27: switch from DISCONTIGMEM to SPARSEMEM
Hello, Mike Rapoport wrote: > From: Mike Rapoport > > The memory initialization of SGI-IP27 is already half-way to support > SPARSEMEM. It only had free_bootmem_with_active_regions() left-overs > interfering with sparse_memory_present_with_active_regions(). > > Replace these calls with simpler memblocks_present() call in prom_meminit() > and adjust arch/mips/Kconfig to enable SPARSEMEM and SPARSEMEM_EXTREME for > SGI-IP27. Applied to mips-next. > commit 397dc00e249e > https://git.kernel.org/mips/c/397dc00e249e > > Co-developed-by: Thomas Bogendoerfer > Signed-off-by: Thomas Bogendoerfer > Signed-off-by: Mike Rapoport > Signed-off-by: Paul Burton Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH] PCI: endpoint: cast the page number to phys_addr_t
> PCI memory size 128M 0x20 Correction: PCI memory size 128G 0x20
Re: [PATCH v2 00/36] MIPS: barriers & atomics cleanups
Hello,
Paul Burton wrote:
> This series consists of a bunch of cleanups to the way we handle memory
> barriers (though no changes to the sync instructions we use to implement
> them) & atomic memory accesses. One major goal was to ensure the
> Loongson3 LL/SC errata workarounds are applied in a safe manner from
> within inline-asm & that we can automatically verify the resulting
> kernel binary looks reasonable. Many patches are cleanups found along
> the way.
>
> Applies atop v5.4-rc1.
>
> Changes in v2:
> - Keep our fls/ffs implementations. Turns out GCC's builtins call
> intrinsics in some configurations, and if we'd need to go implement
> those then using the generic fls/ffs doesn't seem like such a win.
> - De-string __WEAK_LLSC_MB to allow use with __SYNC_ELSE().
> - Only try to build the loongson3-llsc-check tool from
> arch/mips/Makefile when CONFIG_CPU_LOONGSON3_WORKAROUNDS is enabled.
>
> Paul Burton (36):
> MIPS: Unify sc beqz definition
> MIPS: Use compact branch for LL/SC loops on MIPSr6+
> MIPS: barrier: Add __SYNC() infrastructure
> MIPS: barrier: Clean up rmb() & wmb() definitions
> MIPS: barrier: Clean up __smp_mb() definition
> MIPS: barrier: Remove fast_mb() Octeon #ifdef'ery
> MIPS: barrier: Clean up __sync() definition
> MIPS: barrier: Clean up sync_ginv()
> MIPS: atomic: Fix whitespace in ATOMIC_OP macros
> MIPS: atomic: Handle !kernel_uses_llsc first
> MIPS: atomic: Use one macro to generate 32b & 64b functions
> MIPS: atomic: Emit Loongson3 sync workarounds within asm
> MIPS: atomic: Use _atomic barriers in atomic_sub_if_positive()
> MIPS: atomic: Unify 32b & 64b sub_if_positive
> MIPS: atomic: Deduplicate 32b & 64b read, set, xchg, cmpxchg
> MIPS: bitops: Handle !kernel_uses_llsc first
> MIPS: bitops: Only use ins for bit 16 or higher
> MIPS: bitops: Use MIPS_ISA_REV, not #ifdefs
> MIPS: bitops: ins start position is always an immediate
> MIPS: bitops: Implement test_and_set_bit() in terms of _lock variant
> MIPS: bitops: Allow immediates in test_and_{set,clear,change}_bit
> MIPS: bitops: Use the BIT() macro
> MIPS: bitops: Avoid redundant zero-comparison for non-LLSC
> MIPS: bitops: Abstract LL/SC loops
> MIPS: bitops: Use BIT_WORD() & BITS_PER_LONG
> MIPS: bitops: Emit Loongson3 sync workarounds within asm
> MIPS: bitops: Use smp_mb__before_atomic in test_* ops
> MIPS: cmpxchg: Emit Loongson3 sync workarounds within asm
> MIPS: cmpxchg: Omit redundant barriers for Loongson3
> MIPS: futex: Emit Loongson3 sync workarounds within asm
> MIPS: syscall: Emit Loongson3 sync workarounds within asm
> MIPS: barrier: Remove loongson_llsc_mb()
> MIPS: barrier: Make __smp_mb__before_atomic() a no-op for Loongson3
> MIPS: genex: Add Loongson3 LL/SC workaround to ejtag_debug_handler
> MIPS: genex: Don't reload address unnecessarily
> MIPS: Check Loongson3 LL/SC errata workaround correctness
>
> arch/mips/Makefile | 3 +
> arch/mips/Makefile.postlink| 10 +-
Series applied to mips-next.
> MIPS: Unify sc beqz definition
> commit 878f75c7a253
> https://git.kernel.org/mips/c/878f75c7a253
>
> Signed-off-by: Paul Burton
>
> MIPS: Use compact branch for LL/SC loops on MIPSr6+
> commit ef85d057a605
> https://git.kernel.org/mips/c/ef85d057a605
>
> Signed-off-by: Paul Burton
>
> MIPS: barrier: Add __SYNC() infrastructure
> commit bf92927251b3
> https://git.kernel.org/mips/c/bf92927251b3
>
> Signed-off-by: Paul Burton
>
> MIPS: barrier: Clean up rmb() & wmb() definitions
> commit 21e3134b3ec0
> https://git.kernel.org/mips/c/21e3134b3ec0
>
> Signed-off-by: Paul Burton
>
> MIPS: barrier: Clean up __smp_mb() definition
> commit 05e6da742b5b
> https://git.kernel.org/mips/c/05e6da742b5b
>
> Signed-off-by: Paul Burton
>
> MIPS: barrier: Remove fast_mb() Octeon #ifdef'ery
> commit 5c12a6eff6ae
> https://git.kernel.org/mips/c/5c12a6eff6ae
>
> Signed-off-by: Paul Burton
>
> MIPS: barrier: Clean up __sync() definition
> commit fe0065e56227
> https://git.kernel.org/mips/c/fe0065e56227
>
> Signed-off-by: Paul Burton
>
> MIPS: barrier: Clean up sync_ginv()
> commit 185d7d7a5819
> https://git.kernel.org/mips/c/185d7d7a5819
>
> Signed-off-by: Paul Burton
>
> MIPS: atomic: Fix whitespace in ATOMIC_OP macros
> commit 36d3295c5a0d
> https://git.kernel.org/mips/c/36d3295c5a0d
>
> Signed-off-by: Paul Burton
>
> MIPS: atomic: Handle !kernel_uses_llsc first
> commit 9537db24c65a
> https://git.kernel.org/mips/c/9537db24c65a
>
> Signed-off-by: Paul Burton
>
> MIPS: atomic: Use one macro to generate 32b & 64b functions
> commit a38ee6bb14a4
> https://git.kernel.org/mips/c/a38ee6bb14a4
>
> Signed-off-by: Paul Burton
>
> MIPS: atomic: Emit Loongson3 sync workarounds within asm
> commit 4d1dbfe6cbec
> https://git.kernel.org/mips/c/4d1dbfe6cbec
>
> Signed-off-by: Paul Burton
>
> MIPS:
Re: [PATCH 05/11] of: Ratify of_dma_configure() interface
On Thu, 2019-10-03 at 20:53 -0500, Rob Herring wrote:
> > > > But I think that with this series, given the fact that we now treat the
> > > > lack
> > > > of
> > > > dma-ranges as a 1:1 mapping instead of an error, we could rewrite the
> > > > function
> > > > like this:
> > >
> > > Now, I'm reconsidering allowing this abuse... It's better if the code
> > > which understands the bus structure in DT for a specific bus passes in
> > > the right thing. Maybe I should go back to Robin's version (below).
> > > OTOH, the existing assumption that 'dma-ranges' was in the immediate
> > > parent was an assumption on the bus structure which maybe doesn't
> > > always apply.
> > >
> > > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > > index a45261e21144..6951450bb8f3 100644
> > > --- a/drivers/of/device.c
> > > +++ b/drivers/of/device.c
> > > @@ -98,12 +98,15 @@ int of_dma_configure(struct device *dev, struct
> > > device_node *parent, bool force_
> > > u64 mask;
> > >
> > > np = dev->of_node;
> > > - if (!np)
> > > - np = parent;
> > > + if (np)
> > > + parent = of_get_dma_parent(np);
> > > + else
> > > + np = of_node_get(parent);
> > > if (!np)
> > > return -ENODEV;
> > >
> > > - ret = of_dma_get_range(np, _addr, , );
> > > + ret = of_dma_get_range(parent, _addr, , );
> > > + of_node_put(parent);
> > > if (ret < 0) {
> > > /*
> > > * For legacy reasons, we have to assume some devices need
> >
> > I spent some time thinking about your comments and researching. I came to
> > the
> > realization that both these solutions break the usage in
> > drivers/gpu/drm/sun4i/sun4i_backend.c:805. In that specific case both
> > 'dev->of_node' and 'parent' exist yet the device receiving the configuration
> > and 'parent' aren't related in any way.
>
> I knew there was some reason I didn't like those virtual DT nodes...
>
> That does seem to be the oddest case. Several of the others are just
> non-DT child platform devices. Perhaps we need a "copy the DMA config
> from another struct device (or parent struct device)" function to
> avoid using a DT function on a non-DT device.
>
> > IOW we can't just use 'dev->of_node' as a starting point to walk upwards the
> > tree. We always have to respect whatever DT node the bus provided, and start
> > there. This clashes with the current solutions, as they are based on the
> > fact
> > that we can use dev->of_node when present.
>
> Yes, you are right.
>
> > My guess at this point, if we're forced to honor that behaviour, is that we
> > have to create a new API for the PCI use case. Something the likes of
> > of_dma_configure_parent().
>
> I think of_dma_configure just has to work with the device_node of
> either the device or the device parent and dev->of_node is never used
> unless the caller sets it.
Fine, so given the following two distinct uses of
of_dma_configure(struct device *dev, struct device_node *np, bool ...):
- dev->of_node == np: Platform bus' typical use, we imperatively have to start
parsing dma-ranges from np's DMA parent, as the device we're configuring
might be a bus containing dma-ranges himself. For example a platform PCIe bus.
- dev->of_node != np: Here the bus is pulling some trick. The device might or
might not be represented in DT and np might be a bus or a device. But one
thing I realised is that device being configured never represents a memory
mapped bus. Assuming this assumption is acceptable, we can traverse the DT
tree starting from np and get a correct configuration as long as dma-ranges
not being present is interpreted as a 1:1 mapping.
The resulting code, which I tested on an RPi4, Freescale Layerscape and passes
OF's unit tests, looks like this:
int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
{
u64 dma_addr, paddr, size = 0;
struct device_node *parent;
u64 mask;
int ret;
if (!np)
return -ENODEV;
parent = of_node_get(np);
if (dev->of_node == parent)
parent = of_get_next_dma_parent(np);
ret = of_dma_get_range(parent, _addr, , );
of_node_put(parent);
[...]
}
Would that be acceptable?
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] MIPS: include: Mark __cmpxchd as __always_inline
Hello,
Thomas Bogendoerfer wrote:
> Commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
> forcibly") allows compiler to uninline functions marked as 'inline'.
> In cace of cmpxchg this would cause to reference function
> __cmpxchg_called_with_bad_pointer, which is a error case
> for catching bugs and will not happen for correct code, if
> __cmpxchg is inlined.
Applied to mips-fixes.
> commit 88356d09904b
> https://git.kernel.org/mips/c/88356d09904b
>
> Signed-off-by: Thomas Bogendoerfer
> [paul.bur...@mips.com: s/__cmpxchd/__cmpxchg in subject]
> Signed-off-by: Paul Burton
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.bur...@mips.com to report it. ]
[PATCH v2] nvme-pci: Shutdown when removing dead controller
Shutdown the controller when nvme_remove_dead_controller is
reached.
If nvme_remove_dead_controller() is called, the controller won't
be comming back online, so we should shut it down rather than just
disabling.
Remove nvme_kill_queues() as nvme_dev_remove() will take care of
unquiescing queues.
Signed-off-by: Tyler Ramer
---
Changes since v1:
* Clean up commit message
* Remove nvme_kill_queues()
---
drivers/nvme/host/pci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index c0808f9eb8ab..68d5fb880d80 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2509,8 +2509,7 @@ static void nvme_pci_free_ctrl(struct nvme_ctrl *ctrl)
static void nvme_remove_dead_ctrl(struct nvme_dev *dev)
{
nvme_get_ctrl(>ctrl);
- nvme_dev_disable(dev, false);
- nvme_kill_queues(>ctrl);
+ nvme_dev_disable(dev, true);
if (!queue_work(nvme_wq, >remove_work))
nvme_put_ctrl(>ctrl);
}
--
2.23.0
Re: [PATCH v5 0/6] arm64: vdso32: Address various issues
Hi Will, On 07/10/2019 15:37, Vincenzo Frascino wrote: > On 07/10/2019 15:15, Will Deacon wrote: >> On Mon, Oct 07, 2019 at 02:54:29PM +0100, Vincenzo Frascino wrote: >>> On 07/10/2019 14:31, Will Deacon wrote: On Thu, Oct 03, 2019 at 06:48:32PM +0100, Vincenzo Frascino wrote: > This patch series is meant to address the various compilation issues > reported recently for arm64 vdso32 [1]. > > From v4, the series contains a cleanup of lib/vdso Kconfig as well since > CROSS_COMPILE_COMPAT_VDSO is not required anymore by any architecture. I've queued this up as fixes for 5.4, but I ended up making quite a few additional changes to address some other issues and minor inconsistencies I ran into. In particular, with my changes, you can now easily build the kernel with clang but the compat vDSO with gcc. The header files still need sorting out properly, but I think this is a decent starting point: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/fixes Please have a look. >>> >>> Thank you for letting me know, I will have a look. >> >> Thanks. >> >>> I see acked-by Catalin on the patches, did you post them in review >>> somewhere? I >>> could not find them. Sorry >> >> I pushed them out to a temporary vdso branch on Friday and Catalin looked at >> that. If you'd like me to post them as well, please let me know, although >> I'm keen to get this stuff sorted out by -rc3 without disabling the compat >> vDSO altogether (i.e. [1]). In other words, if you're ok with my changes on >> top of yours then let's go for that, otherwise let's punt this to 5.5 and >> try to fix the header mess at the same time. >> > > No need to repost them. I just got confused by the fact that they got acked > and > I could not find them anywhere, hence my question. > > I am keen to sort this thing as well, my personal preference is to not disable > compat vdso in 5.4. > > I will download your tree, have a look at it and let you know my thoughts. > I tested your patches and they look fine to me. I have just one request, in the commit message of patch were you rename COMPATCC to CC_COMPAT could you please add the make command with the update variable? $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ CROSS_COMPILE_COMPAT=arm-linux-gnueabihf- CC=clang \ CC_COMPAT=arm-linux-gnueabihf-gcc It took me a while to understand that the command in the commit message (c71e88c43796 "arm64: vdso32: Don't use KBUILD_CPPFLAGS unconditionally") was not working because of the renaming. Thanks! If it is not too late you can add my reviewed-by and tested-by ;) >> Will >> >> [1] https://lkml.kernel.org/r/20190925130926.50674-1-catalin.mari...@arm.com >> > -- Regards, Vincenzo pEpkey.asc Description: application/pgp-keys
[PATCH v2 for 5.4 3/4] media: hantro: Fix motion vectors usage condition
From: Francois Buergisser
The setting of the motion vectors usage and the setting of motion
vectors address are currently done under different conditions.
When decoding pre-recorded videos, this results of leaving the motion
vectors address unset, resulting in faulty memory accesses. Fix it
by using the same condition everywhere, which matches the profiles
that support motion vectors.
Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Francois Buergisser
Signed-off-by: Ezequiel Garcia
---
v2:
* New patch.
drivers/staging/media/hantro/hantro_g1_h264_dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 7ab534936843..c92460407613 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -35,7 +35,7 @@ static void set_params(struct hantro_ctx *ctx)
if (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD)
reg |= G1_REG_DEC_CTRL0_SEQ_MBAFF_E;
reg |= G1_REG_DEC_CTRL0_PICORD_COUNT_E;
- if (dec_param->nal_ref_idc)
+ if (sps->profile_idc > 66)
reg |= G1_REG_DEC_CTRL0_WRITE_MVS_E;
if (!(sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY) &&
--
2.22.0
[PATCH v2 for 5.4 4/4] media: hantro: Fix picture order count table enable
From: Francois Buergisser
The picture order count table only makes sense for profiles
higher than Baseline. This is confirmed by the H.264 specification
(See 8.2.1 Decoding process for picture order count), which
clarifies how POC are used for features not present in Baseline.
"""
Picture order counts are used to determine initial picture orderings
for reference pictures in the decoding of B slices, to represent picture
order differences between frames or fields for motion vector derivation
in temporal direct mode, for implicit mode weighted prediction in B slices,
and for decoder conformance checking.
"""
As a side note, this change matches various vendors downstream codebases,
including ChromiumOS and IMX VPU libraries.
Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Francois Buergisser
Signed-off-by: Ezequiel Garcia
---
v2:
* New patch.
drivers/staging/media/hantro/hantro_g1_h264_dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index c92460407613..05576dbd39e2 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -34,9 +34,9 @@ static void set_params(struct hantro_ctx *ctx)
reg = G1_REG_DEC_CTRL0_DEC_AXI_WR_ID(0x0);
if (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD)
reg |= G1_REG_DEC_CTRL0_SEQ_MBAFF_E;
- reg |= G1_REG_DEC_CTRL0_PICORD_COUNT_E;
if (sps->profile_idc > 66)
- reg |= G1_REG_DEC_CTRL0_WRITE_MVS_E;
+ reg = G1_REG_DEC_CTRL0_PICORD_COUNT_E |
+ G1_REG_DEC_CTRL0_WRITE_MVS_E;
if (!(sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY) &&
(sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD ||
--
2.22.0
[PATCH v2 for 5.4 2/4] media: hantro: Fix H264 max frmsize supported on RK3288
From: Jonas Karlman
TRM specify supported image size 48x48 to 4096x2304 at step size 16 pixels,
change frmsize max_width/max_height to match TRM.
Fixes: 760327930e10 ("media: hantro: Enable H264 decoding on rk3288")
Signed-off-by: Jonas Karlman
---
v2:
* No changes.
drivers/staging/media/hantro/rk3288_vpu_hw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/hantro/rk3288_vpu_hw.c
b/drivers/staging/media/hantro/rk3288_vpu_hw.c
index 6bfcc47d1e58..ebb017b8a334 100644
--- a/drivers/staging/media/hantro/rk3288_vpu_hw.c
+++ b/drivers/staging/media/hantro/rk3288_vpu_hw.c
@@ -67,10 +67,10 @@ static const struct hantro_fmt rk3288_vpu_dec_fmts[] = {
.max_depth = 2,
.frmsize = {
.min_width = 48,
- .max_width = 3840,
+ .max_width = 4096,
.step_width = H264_MB_DIM,
.min_height = 48,
- .max_height = 2160,
+ .max_height = 2304,
.step_height = H264_MB_DIM,
},
},
--
2.22.0
Re: [PATCH] ARM: dts: Set status to disable for MMC3
* Emmanuel Vadot [191007 17:30]: > On Mon, 7 Oct 2019 09:58:59 -0700 > Tony Lindgren wrote: > > There should be no need to do that for SoC internal devices, the > > the default status = "okay" should be just fine. Setting the > > status = "disabled" for SoC internal devices and then enabling them > > again for tens of board specific dts files just generates tons of > > pointless extra churn for the board specific configuration. > > Setting the status = "okay" means that you can use the device. What's > the point of enabling a device if you can't use it ? Or worse can't > probe it like i2c or spi ? The main reasons for not setting SoC internal devices with status = "disabled" are: 1. The SoC internal device is there for sure and also accessible for the kernel 2. Setting an SoC internal device with status = "disabled" makes the kernel completely ignore it and it cannot be idled for PM if left on from the bootloader 3. We avoid tens of lines of pointess repetive status = "okay" tinkering for multiple devices per each board specic dts file making them more readable and easier to maintain > Is the plan for TI dts to have every (or almost) device tree node > enabled even if the device isn't usable on the board ? This has always been the case with omap3, 4, and 5. I don't know when folks started tagging am33xx SoC internal devices as disabled but that should have never been necessary. Few years back I suggested some patches for status = "incomplete" to deal with cases where the device is there but not pinned out or otherwise not complete. But so far we've gotten away without that, so probably not needed. > > > In this case it's FreeBSD being because (I think) we have bad support > > > for the clocks for this module so we panic when we read from it as the > > > module isn't clocked. And since I find it wrong to have device enabled > > > while it isn't present I've sent this patch. > > > > Thanks for clarifying what happens. OK, sounds like FreeBSD might be > > missing clock handling for some devices then. > > > > What Linux does is probe the internal devices and then idle the > > unused ones as bootloaders often leave many things enabled. Otherwise > > the SoC power management won't work properly because device clocks > > will block deeper SoC idle states. > > I can understand stand but then the bootload should be fixed to not > enable devices that aren't enabled in the DTS if it does that. This is not doable as in many cases the bootloader cannot be updated as it can be signed for phones like n900 and droid4. Regards, Tony
[PATCH v2 for 5.4 1/4] media: hantro: Fix s_fmt for dynamic resolution changes
Commit 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders")
changed the conditions under S_FMT was allowed for OUTPUT
CAPTURE buffers.
However, and according to the mem-to-mem stateless decoder specification,
in order to support dynamic resolution changes, S_FMT should be allowed
even if OUTPUT buffers have been allocated.
Relax decoder S_FMT restrictions on OUTPUT buffers, allowing a resolution
modification, provided the pixel format stays the same.
Tested on RK3288 platforms using ChromiumOS Video Decode/Encode Accelerator
Unittests.
Fixes: 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders")
Signed-off-by: Ezequiel Garcia
--
v2:
* Call try_fmt_out before using the format,
pointed out by Philipp.
drivers/staging/media/hantro/hantro_v4l2.c | 28 +++---
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c
b/drivers/staging/media/hantro/hantro_v4l2.c
index 3dae52abb96c..586d243cc3cc 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -367,19 +367,26 @@ vidioc_s_fmt_out_mplane(struct file *file, void *priv,
struct v4l2_format *f)
{
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct hantro_ctx *ctx = fh_to_ctx(priv);
+ struct vb2_queue *vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, f->type);
const struct hantro_fmt *formats;
unsigned int num_fmts;
- struct vb2_queue *vq;
int ret;
- /* Change not allowed if queue is busy. */
- vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, f->type);
- if (vb2_is_busy(vq))
- return -EBUSY;
+ ret = vidioc_try_fmt_out_mplane(file, priv, f);
+ if (ret)
+ return ret;
if (!hantro_is_encoder_ctx(ctx)) {
struct vb2_queue *peer_vq;
+ /*
+* In other to support dynamic resolution change,
+* the decoder admits a resolution change, as long
+* as the pixelformat remains. Can't be done if streaming.
+*/
+ if (vb2_is_streaming(vq) || (vb2_is_busy(vq) &&
+ pix_mp->pixelformat != ctx->src_fmt.pixelformat))
+ return -EBUSY;
/*
* Since format change on the OUTPUT queue will reset
* the CAPTURE queue, we can't allow doing so
@@ -389,12 +396,15 @@ vidioc_s_fmt_out_mplane(struct file *file, void *priv,
struct v4l2_format *f)
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
if (vb2_is_busy(peer_vq))
return -EBUSY;
+ } else {
+ /*
+* The encoder doesn't admit a format change if
+* there are OUTPUT buffers allocated.
+*/
+ if (vb2_is_busy(vq))
+ return -EBUSY;
}
- ret = vidioc_try_fmt_out_mplane(file, priv, f);
- if (ret)
- return ret;
-
formats = hantro_get_formats(ctx, _fmts);
ctx->vpu_src_fmt = hantro_find_format(formats, num_fmts,
pix_mp->pixelformat);
--
2.22.0
[PATCH v2 for 5.4 0/4] media: hantro: Collected fixes for v5.4
Some pending fixes. The first patch is needed to allow dynamic resolution changes, as per the upcoming stateless decoder API. This patch was posted before and received some comments from Philipp Zabel. The second patch was posted by Jonas Karlman as part of his series to add support for interlaced content. The fix can be applied independently so I'm including it here. Patches 3 and 4 correspond to fixes found by Francois Buergisser while doing some tests on ChromeOS. Ezequiel Garcia (1): media: hantro: Fix s_fmt for dynamic resolution changes Francois Buergisser (2): media: hantro: Fix motion vectors usage condition media: hantro: Fix picture order count table enable Jonas Karlman (1): media: hantro: Fix H264 max frmsize supported on RK3288 .../staging/media/hantro/hantro_g1_h264_dec.c | 6 ++-- drivers/staging/media/hantro/hantro_v4l2.c| 28 +-- drivers/staging/media/hantro/rk3288_vpu_hw.c | 4 +-- 3 files changed, 24 insertions(+), 14 deletions(-) -- 2.22.0
Re: [PATCH] PCI: endpoint: cast the page number to phys_addr_t
On Fri, Oct 4, 2019 at 6:49 PM Alan Mikhak wrote: > > From: Alan Mikhak > > Modify pci_epc_mem_alloc_addr() to cast the variable 'pageno' > from type 'int' to 'phys_addr_t' before shifting left. This > cast is needed to avoid treating bit 31 of 'pageno' as the > sign bit which would otherwise get sign-extended to produce > a negative value. When added to the base address of PCI memory > space, the negative value would produce an invalid physical > address which falls before the start of the PCI memory space. > > Signed-off-by: Alan Mikhak > --- > drivers/pci/endpoint/pci-epc-mem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pci/endpoint/pci-epc-mem.c > b/drivers/pci/endpoint/pci-epc-mem.c > index 2bf8bd1f0563..d2b174ce15de 100644 > --- a/drivers/pci/endpoint/pci-epc-mem.c > +++ b/drivers/pci/endpoint/pci-epc-mem.c > @@ -134,7 +134,7 @@ void __iomem *pci_epc_mem_alloc_addr(struct pci_epc *epc, > if (pageno < 0) > return NULL; > > - *phys_addr = mem->phys_base + (pageno << page_shift); > + *phys_addr = mem->phys_base + ((phys_addr_t)pageno << page_shift); > virt_addr = ioremap(*phys_addr, size); > if (!virt_addr) > bitmap_release_region(mem->bitmap, pageno, order); > -- > 2.7.4 > Hi Kishon, This issue was observed when requesting pci_epc_mem_alloc_addr() to allocate a region of size 0x4001ULL (1GB + 64KB) from a 128GB PCI address space with page sizes being 64KB. This resulted in 'pageno' value of '0x8000' as the first available page in a contiguous region for the requested size due to other smaller regions having been allocated earlier. With 64KB page sizes, the variable 'page_shift' holds a value of 0x10. Shifting 'pageno' 16 bits to the left results in an 'int' value whose bit 31 is set. [ 10.565256] __pci_epc_mem_init: mem size 0x20 page_size 0x1 [ 10.571613] __pci_epc_mem_init: mem pages 0x20 bitmap_size 0x4 page_shift 0x10 PCI memory base 0x20 PCI memory size 128M 0x20 page_size 64K 0x1 page_shift 16 0x10 pages 2M 0x20 bitmap_size 256K 0x4 [ 702.050299] pci_epc_mem_alloc_addr: size 0x1 order 0x0 pageno 0x4 virt_add 0xffd0047b phys_addr 0x24 [ 702.061424] pci_epc_mem_alloc_addr: size 0x1 order 0x0 pageno 0x5 virt_add 0xffd0047d phys_addr 0x25 [ 702.203933] pci_epc_mem_alloc_addr: size 0x4001 order 0xf pageno 0x8000 virt_add 0xffd00480 phys_addr 0x1f8000 [ 702.216547] Oops - store (or AMO) access fault [#1] ::: [ 702.310198] sstatus: 00020120 sbadaddr: ffd004804000 scause: 0007 Regards, Alan
Re: [PATCH v2 1/5] arm64: dts: qcom: sdm845: Add unit name to soc node
On Tue, Jul 23, 2019 at 9:51 PM Vinod Koul wrote:
>
> We get a warning about missing unit name for soc node, so add it.
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi:623.11-2814.4: Warning
> (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit
> name
>
> Signed-off-by: Vinod Koul
> Reviewed-by: Stephen Boyd
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 601cfb078bd5..e81f4a6d08ce 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -620,7 +620,7 @@
> method = "smc";
> };
>
> - soc: soc {
> + soc: soc@0 {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges = <0 0 0 0 0x10 0>;
So Amit Pundir noted that this patch is causing 5.4-rc to no longer
boot on db845 w/ AOSP, due to it changing the userland sysfs paths
from "/devices/platform/soc/1a0.mdss" to
"/devices/platform/soc@0/1a0.mdss"
Is there a better solution here that might not break userspace?
thanks
-john
[PATCH] perf data: Fix babeltrace detection
From: Andi Kleen The symbol the feature file checks for is now actually in -lbabeltrace, not -lbabeltrace-ctf, at least as of libbabeltrace-1.5.6-2.fc30.x86_64 Always add both libraries to fix the feature detection. Signed-off-by: Andi Kleen --- tools/perf/Makefile.config | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index bf8caa7d17f6..71638917e18a 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -155,7 +155,7 @@ ifdef LIBBABELTRACE_DIR LIBBABELTRACE_LDFLAGS := -L$(LIBBABELTRACE_DIR)/lib endif FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS) -FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) -lbabeltrace-ctf +FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) -lbabeltrace-ctf -lbabeltrace ifdef LIBZSTD_DIR LIBZSTD_CFLAGS := -I$(LIBZSTD_DIR)/lib @@ -895,7 +895,7 @@ ifndef NO_LIBBABELTRACE ifeq ($(feature-libbabeltrace), 1) CFLAGS += -DHAVE_LIBBABELTRACE_SUPPORT $(LIBBABELTRACE_CFLAGS) LDFLAGS += $(LIBBABELTRACE_LDFLAGS) -EXTLIBS += -lbabeltrace-ctf +EXTLIBS += -lbabeltrace-ctf -lbabeltrace $(call detected,CONFIG_LIBBABELTRACE) else msg := $(warning No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev); -- 2.21.0
RE: [PATCH 0/2] Drivers: hv: vmbus: Miscellaneous improvements
> From: linux-hyperv-ow...@vger.kernel.org > On Behalf Of Andrea Parri > Sent: Monday, October 7, 2019 9:31 AM > > Hi all, > > The patchset: > > - simplifies/refactors the VMBus negotiation code by introducing > the table of VMBus protocol versions (patch 1/2), > > - enables VMBus protocol versions 5.1 and 5.2 (patch 2/2). > > Thanks, > Andrea > > Andrea Parri (2): > Drivers: hv: vmbus: Introduce table of VMBus protocol versions > Drivers: hv: vmbus: Enable VMBus protocol versions 5.1 and 5.2 Should we add a module parameter to allow the user to specify a lower protocol version, when the VM runs on the latest host? This can be useful for testing and debugging purpose: the variable "vmbus_proto_version" is referenced by the vmbus driver itself and some VSC drivers: if we always use the latest available proto version, some code paths can not be tested on the latest hosts. Thanks, -- Dexuan
Re: [PATCH] mm: vmalloc: Use the vmap_area_lock to protect ne_fit_preload_node
On 2019-10-07 18:56:11 [+0200], Uladzislau Rezki wrote: > Actually there is a high lock contention on vmap_area_lock, because it > is still global. You can have a look at last slide: > > https://linuxplumbersconf.org/event/4/contributions/547/attachments/287/479/Reworking_of_KVA_allocator_in_Linux_kernel.pdf > > so this change will make it a bit higher. From the other hand i agree > that for rt it should be fixed, probably it could be done like: > > ifdef PREEMPT_RT > migrate_disable() > #else > preempt_disable() > ... > > but i am not sure it is good either. What is to be expected on average? Is the lock acquired and then released again because the slot is empty and memory needs to be allocated or can it be assumed that this hardly happens? Sebastian
Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()
On Sun, Oct 06, 2019 at 08:11:42PM -0700, Linus Torvalds wrote:
> > So do we want to bother with separation between raw_copy_to_user() and
> > unsafe_copy_to_user()? After all, __copy_to_user() also has only few
> > callers, most of them in arch/*
>
> No, you're right. Just switch over.
>
> > I'll take a look into that tomorrow - half-asleep right now...
>
> Thanks. No huge hurry.
Tangentially related: copy_regster_to_user() and copy_regset_from_user().
That's where we do access_ok(), followed by calls of ->get() and
->set() resp. Those tend to either use user_regset_copy{out,in}(),
or open-code those. The former variant tends to lead to few calls
of __copy_{to,from}_user(); the latter... On x86 it ends up doing
this:
static int genregs_get(struct task_struct *target,
const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
if (kbuf) {
unsigned long *k = kbuf;
while (count >= sizeof(*k)) {
*k++ = getreg(target, pos);
count -= sizeof(*k);
pos += sizeof(*k);
}
} else {
unsigned long __user *u = ubuf;
while (count >= sizeof(*u)) {
if (__put_user(getreg(target, pos), u++))
return -EFAULT;
count -= sizeof(*u);
pos += sizeof(*u);
}
}
return 0;
}
Potentially doing arseloads of stac/clac as it goes. OTOH, getreg()
(and setreg()) in there are not entirely trivial, so blanket
user_access_begin()/user_access_end() over the entire loop might be
a bad idea...
How hot is that codepath? I know that arch/um used to rely on it
(== PTRACE_[GS]ETREGS) quite a bit...
Re: [PATCH TRIVIAL v2] gpu: Fix Kconfig indentation
On Mon, 7 Oct 2019 at 18:09, Alex Deucher wrote: > > On Mon, Oct 7, 2019 at 7:39 AM Jani Nikula > wrote: > > > > On Fri, 04 Oct 2019, Krzysztof Kozlowski wrote: > > > drivers/gpu/drm/i915/Kconfig | 12 +- > > > drivers/gpu/drm/i915/Kconfig.debug | 144 +++ > > > > Please split these out to a separate patch. Can't speak for others, but > > the patch looks like it'll be conflicts galore and a problem to manage > > if merged in one big lump. > > Yes, it would be nice to have the amd patch separate as well. I'll split the AMD and i915 although I am not sure if it is sense to split such trivial patch per each driver. Best regards, Krzysztof
[PATCH v2 1/3] tools/power/x86/intel-speed-select: Base-freq feature auto mode
Introduce --auto|-a option to base-freq enable feature, so that it
does in one step for users who are OK by setting all cores with higher
base frequency to be set in CLOS 0 and remaining in CLOS 3. This option
also sets corresponding clos.min to CLOS 0 and CLOS3. In this way, users
don't have to take multiple steps to enable base-freq feature. For users
who want more fine grain control, they can always use core-power feature
to set custom CLOS configuration and assignment.
Also adjust cpufreq/scaling_min_freq for higher and lower priority cores.
For example user can use:
intel-speed-select base-freq enable --auto
Signed-off-by: Srinivas Pandruvada
---
.../x86/intel-speed-select/isst-config.c | 232 +-
1 file changed, 223 insertions(+), 9 deletions(-)
diff --git a/tools/power/x86/intel-speed-select/isst-config.c
b/tools/power/x86/intel-speed-select/isst-config.c
index 21fcfe621d3a..82502a38446e 100644
--- a/tools/power/x86/intel-speed-select/isst-config.c
+++ b/tools/power/x86/intel-speed-select/isst-config.c
@@ -39,6 +39,7 @@ static unsigned long long fact_trl;
static int out_format_json;
static int cmd_help;
static int force_online_offline;
+static int auto_mode;
/* clos related */
static int current_clos = -1;
@@ -855,23 +856,227 @@ static void dump_pbf_config(void)
isst_ctdp_display_information_end(outf);
}
+static int set_clos_param(int cpu, int clos, int epp, int wt, int min, int max)
+{
+ struct isst_clos_config clos_config;
+ int ret;
+
+ ret = isst_pm_get_clos(cpu, clos, _config);
+ if (ret) {
+ perror("isst_pm_get_clos");
+ return ret;
+ }
+ clos_config.clos_min = min;
+ clos_config.clos_max = max;
+ clos_config.epp = epp;
+ clos_config.clos_prop_prio = wt;
+ ret = isst_set_clos(cpu, clos, _config);
+ if (ret) {
+ perror("isst_pm_set_clos");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int set_cpufreq_cpuinfo_scaling_min(int cpu, int max)
+{
+ char buffer[128], min_freq[16];
+ int fd, ret, len;
+
+ if (!CPU_ISSET_S(cpu, present_cpumask_size, present_cpumask))
+ return -1;
+
+ if (max)
+ snprintf(buffer, sizeof(buffer),
+
"/sys/devices/system/cpu/cpu%d/cpufreq/cpuinfo_max_freq", cpu);
+ else
+ snprintf(buffer, sizeof(buffer),
+
"/sys/devices/system/cpu/cpu%d/cpufreq/cpuinfo_min_freq", cpu);
+
+ fd = open(buffer, O_RDONLY);
+ if (fd < 0)
+ return fd;
+
+ len = read(fd, min_freq, sizeof(min_freq));
+ close(fd);
+
+ if (len < 0)
+ return len;
+
+ snprintf(buffer, sizeof(buffer),
+"/sys/devices/system/cpu/cpu%d/cpufreq/scaling_min_freq", cpu);
+
+ fd = open(buffer, O_WRONLY);
+ if (fd < 0)
+ return fd;
+
+ len = strlen(min_freq);
+ ret = write(fd, min_freq, len);
+ if (ret == -1) {
+ close(fd);
+ return ret;
+ }
+ close(fd);
+
+ return 0;
+}
+
+static void set_scaling_min_to_cpuinfo_max(int cpu)
+{
+ int i, pkg_id, die_id;
+
+ pkg_id = get_physical_package_id(cpu);
+ die_id = get_physical_die_id(cpu);
+ for (i = 0; i < get_topo_max_cpus(); ++i) {
+ if (pkg_id != get_physical_package_id(i) ||
+ die_id != get_physical_die_id(i))
+ continue;
+
+ set_cpufreq_cpuinfo_scaling_min(i, 1);
+ }
+}
+
+static void set_scaling_min_to_cpuinfo_min(int cpu)
+{
+ int i, pkg_id, die_id;
+
+ pkg_id = get_physical_package_id(cpu);
+ die_id = get_physical_die_id(cpu);
+ for (i = 0; i < get_topo_max_cpus(); ++i) {
+ if (pkg_id != get_physical_package_id(i) ||
+ die_id != get_physical_die_id(i))
+ continue;
+
+ set_cpufreq_cpuinfo_scaling_min(i, 0);
+ }
+}
+
+static int set_core_priority_and_min(int cpu, int mask_size,
+cpu_set_t *cpu_mask, int min_high,
+int min_low)
+{
+ int pkg_id, die_id, ret, i;
+
+ if (!CPU_COUNT_S(mask_size, cpu_mask))
+ return -1;
+
+ ret = set_clos_param(cpu, 0, 0, 0, min_high, 0xff);
+ if (ret)
+ return ret;
+
+ ret = set_clos_param(cpu, 1, 15, 0, min_low, 0xff);
+ if (ret)
+ return ret;
+
+ ret = set_clos_param(cpu, 2, 15, 0, min_low, 0xff);
+ if (ret)
+ return ret;
+
+ ret = set_clos_param(cpu, 3, 15, 0, min_low, 0xff);
+ if (ret)
+ return ret;
+
+ pkg_id = get_physical_package_id(cpu);
+ die_id = get_physical_die_id(cpu);
+ for (i = 0; i < get_topo_max_cpus(); ++i) {
+ int clos;
+
+ if (pkg_id !=
[PATCH v2 0/3] tools/power/x86/intel-speed-select: Auto mode
v2 The sequence should be opposite than what was submitted in v1. First enable core-power than enable turbo-freq and base-freq for the auto mode. Firmware may give error if the core-power feature is not enabled first. Also need to set the core_power property of thread siblings. Othewise it will be reset if user forgot to add those siblings as part of command line CPUs. Srinivas Pandruvada (3): tools/power/x86/intel-speed-select: Base-freq feature auto mode tools/power/x86/intel-speed-select: Turbo-freq feature auto mode tools/power/x86/intel-speed-select: Refuse to disable core-power when getting used .../x86/intel-speed-select/isst-config.c | 384 -- .../power/x86/intel-speed-select/isst-core.c | 21 + 2 files changed, 368 insertions(+), 37 deletions(-) -- 2.17.2
[PATCH v2 2/3] tools/power/x86/intel-speed-select: Turbo-freq feature auto mode
Introduce --auto|-a option to turbo-freq enable feature, so that it
does in one step for users who are OK by setting all passed target cores
as high priority and set in CLOS 0 and remaining in CLOS 3. In this way,
users don't have to take multiple steps to enable turbo-freq feature. For
users who want more fine grain control, they can always use core-power
feature to set custom CLOS configuration and assignment.
While here also print the error to output when clos configuration fails.
For example
intel-speed-select -c 0-4 turbo-freq enable --auto
The above command will enable turbo-freq and core-power feature. Also
mark CPU 0 to CPU 4 as high priority.
Signed-off-by: Srinivas Pandruvada
---
.../x86/intel-speed-select/isst-config.c | 152 ++
1 file changed, 124 insertions(+), 28 deletions(-)
diff --git a/tools/power/x86/intel-speed-select/isst-config.c
b/tools/power/x86/intel-speed-select/isst-config.c
index 82502a38446e..e1ca7c5b8037 100644
--- a/tools/power/x86/intel-speed-select/isst-config.c
+++ b/tools/power/x86/intel-speed-select/isst-config.c
@@ -1173,40 +1173,58 @@ static void set_fact_for_cpu(int cpu, void *arg1, void
*arg2, void *arg3,
int ret;
int status = *(int *)arg4;
+ if (auto_mode) {
+ if (status) {
+ ret = isst_pm_qos_config(cpu, 1, 1);
+ if (ret)
+ goto disp_results;
+ } else {
+ isst_pm_qos_config(cpu, 0, 0);
+ }
+ }
+
ret = isst_set_pbf_fact_status(cpu, 0, status);
- if (ret)
+ if (ret) {
perror("isst_set_fact");
- else {
- if (status) {
- struct isst_pkg_ctdp pkg_dev;
+ if (auto_mode)
+ isst_pm_qos_config(cpu, 0, 0);
- ret = isst_get_ctdp_levels(cpu, _dev);
- if (ret) {
- isst_display_result(cpu, outf, "turbo-freq",
- "enable", ret);
- return;
- }
+ goto disp_results;
+ }
+
+ /* Set TRL */
+ if (status) {
+ struct isst_pkg_ctdp pkg_dev;
+
+ ret = isst_get_ctdp_levels(cpu, _dev);
+ if (!ret)
ret = isst_set_trl(cpu, fact_trl);
- isst_display_result(cpu, outf, "turbo-freq", "enable",
- ret);
- } else {
- /* Since we modified TRL during Fact enable, restore it
*/
- isst_set_trl_from_current_tdp(cpu, fact_trl);
- isst_display_result(cpu, outf, "turbo-freq", "disable",
- ret);
- }
+ if (ret && auto_mode)
+ isst_pm_qos_config(cpu, 0, 0);
+ }
+
+disp_results:
+ if (status) {
+ isst_display_result(cpu, outf, "turbo-freq", "enable", ret);
+ } else {
+ /* Since we modified TRL during Fact enable, restore it */
+ isst_set_trl_from_current_tdp(cpu, fact_trl);
+ isst_display_result(cpu, outf, "turbo-freq", "disable", ret);
}
}
static void set_fact_enable(void)
{
- int status = 1;
+ int status = 1, i, ret;
if (cmd_help) {
fprintf(stderr,
"Enable Intel Speed Select Technology Turbo frequency
feature\n");
fprintf(stderr,
"Optional: -t|--trl : Specify turbo ratio limit\n");
+ fprintf(stderr,
+ "\tOptional Arguments: -a|--auto : Designate specified
target CPUs with");
+ fprintf(stderr, "-C|--cpu option as as high priority using
core-power feature\n");
exit(0);
}
@@ -1218,6 +1236,83 @@ static void set_fact_enable(void)
for_each_online_package_in_set(set_fact_for_cpu, NULL, NULL,
NULL, );
isst_ctdp_display_information_end(outf);
+
+ if (auto_mode) {
+ /*
+* When we adjust CLOS param, we have to set for siblings also.
+* So for the each user specified CPU, also add the sibling
+* in the present_cpu_mask.
+*/
+ for (i = 0; i < get_topo_max_cpus(); ++i) {
+ char buffer[128], sibling_list[128], *cpu_str;
+ int fd, len;
+
+ if (!CPU_ISSET_S(i, target_cpumask_size,
target_cpumask))
+ continue;
+
+ snprintf(buffer, sizeof(buffer),
+
"/sys/devices/system/cpu/cpu%d/topology/thread_siblings_list", i);
+
+ fd =
[PATCH v2 3/3] tools/power/x86/intel-speed-select: Refuse to disable core-power when getting used
The turbo-freq feature is dependent on the core-power feature. If the
core-power feature is disabled while the turbo-freq feature is enabled,
this will break the turbo-freq feature. This is a firmware limitation,
where they can't return error under this scenario.
So when trying to disable core-power, make sure that the turbo-freq
feature is not enabled. If it enabled, return error if user is trying to
disable the core-power feature.
Signed-off-by: Srinivas Pandruvada
---
.../power/x86/intel-speed-select/isst-core.c | 21 +++
1 file changed, 21 insertions(+)
diff --git a/tools/power/x86/intel-speed-select/isst-core.c
b/tools/power/x86/intel-speed-select/isst-core.c
index 6dee5332c9d3..67d32f2b9bea 100644
--- a/tools/power/x86/intel-speed-select/isst-core.c
+++ b/tools/power/x86/intel-speed-select/isst-core.c
@@ -649,6 +649,27 @@ int isst_pm_qos_config(int cpu, int enable_clos, int
priority_type)
unsigned int req, resp;
int ret;
+ if (!enable_clos) {
+ struct isst_pkg_ctdp pkg_dev;
+ struct isst_pkg_ctdp_level_info ctdp_level;
+
+ ret = isst_get_ctdp_levels(cpu, _dev);
+ if (ret) {
+ debug_printf("isst_get_ctdp_levels\n");
+ return ret;
+ }
+
+ ret = isst_get_ctdp_control(cpu, pkg_dev.current_level,
+ _level);
+ if (ret)
+ return ret;
+
+ if (ctdp_level.fact_enabled) {
+ debug_printf("Turbo-freq feature must be disabled
first\n");
+ return -EINVAL;
+ }
+ }
+
ret = isst_send_mbox_command(cpu, CONFIG_CLOS, CLOS_PM_QOS_CONFIG, 0, 0,
);
if (ret)
--
2.17.2
Re: [PATCH] ARM: dts: Set status to disable for MMC3
On Mon, 7 Oct 2019 09:58:59 -0700
Tony Lindgren wrote:
> * Emmanuel Vadot [191007 16:39]:
> > On Mon, 7 Oct 2019 09:16:34 -0700
> > Tony Lindgren wrote:
> >
> > > Hi,
> > >
> > > * Emmanuel Vadot [191007 08:04]:
> > > > Commit 5b63fb90adb95 ("ARM: dts: Fix incomplete dts data for am3 and
> > > > am4 mmc")
> > > > fixed the mmc instances on the l3 interconnect but removed the disabled
> > > > status.
> > > > Fix this and let boards properly define it if it have it.
> > >
> > > The dts default is "okay", and should be fine for all the
> > > internal devices even if not pinned out on the board. This
> > > way the devices get properly idled during boot, and we
> > > avoid repeating status = "enabled" over and over again in
> > > the board specific dts files.
> >
> > That is not correct, if a status != "disabled" then pinmuxing will be
> > configured for this device and if multiple devices share the same pin
> > then you have a problem. Note that I have (almost) no knowledge on Ti
> > SoC but I doubt that this is not the case on them.
>
> Hmm well, that should not be needed. The pinmux configuration is always
> done in a board specific dts file.
For TI it seems to be that way, but clearly not for other brand.
> > Also every other boards that I work with use the standard of setting
> > every node to disabled in the dtsi and let the board enable them at
> > will. Is there something different happening in the TI world ?
>
> There should be no need to do that for SoC internal devices, the
> the default status = "okay" should be just fine. Setting the
> status = "disabled" for SoC internal devices and then enabling them
> again for tens of board specific dts files just generates tons of
> pointless extra churn for the board specific configuration.
Setting the status = "okay" means that you can use the device. What's
the point of enabling a device if you can't use it ? Or worse can't
probe it like i2c or spi ?
Is the plan for TI dts to have every (or almost) device tree node
enabled even if the device isn't usable on the board ?
> > > Then the board specific dts files might want to configure
> > > devices with status = "disabled" if really needed. But this
> > > should be only done for devices that Linux must not use,
> > > such as crypto acclerators on secure devices if claimed by
> > > the secure mode.
> > >
> > > So if this fixes something, it's almost certainly a sign
> > > of something else being broken?
> >
> > In this case it's FreeBSD being because (I think) we have bad support
> > for the clocks for this module so we panic when we read from it as the
> > module isn't clocked. And since I find it wrong to have device enabled
> > while it isn't present I've sent this patch.
>
> Thanks for clarifying what happens. OK, sounds like FreeBSD might be
> missing clock handling for some devices then.
>
> What Linux does is probe the internal devices and then idle the
> unused ones as bootloaders often leave many things enabled. Otherwise
> the SoC power management won't work properly because device clocks
> will block deeper SoC idle states.
I can understand stand but then the bootload should be fixed to not
enable devices that aren't enabled in the DTS if it does that.
> Regards,
>
> Tony
>
> > > > Fixes: 5b63fb90adb95 ("ARM: dts: Fix incomplete dts data for am3 and
> > > > am4 mmc")
> > > > Signed-off-by: Emmanuel Vadot
> > > > ---
> > > > arch/arm/boot/dts/am33xx.dtsi | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/am33xx.dtsi
> > > > b/arch/arm/boot/dts/am33xx.dtsi
> > > > index fb6b8aa12cc5..b3a1fd9e39fa 100644
> > > > --- a/arch/arm/boot/dts/am33xx.dtsi
> > > > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > > > @@ -260,6 +260,7 @@
> > > > ti,needs-special-reset;
> > > > interrupts = <29>;
> > > > reg = <0x0 0x1000>;
> > > > + status = "disabled";
> > > > };
> > > > };
> > > >
> > > > --
> > > > 2.22.0
> > > >
> >
> >
> > --
> > Emmanuel Vadot
--
Emmanuel Vadot
[RFC PATCH v2] e1000e: Use rtnl_lock to prevent race conditions between net and pci/pm
From: Alexander Duyck
This patch is meant to address possible race conditions that can exist
between network configuration and power management. A similar issue was
fixed for igb in commit 9474933caf21 ("igb: close/suspend race in
netif_device_detach").
In addition it consolidates the code so that the PCI error handling code
will essentially perform the power management freeze on the device prior to
attempting a reset, and will thaw the device afterwards if that is what it
is planning to do. Otherwise when we call close on the interface it should
see it is detached and not attempt to call the logic to down the interface
and free the IRQs again.
>From what I can tell the check that was adding the check for __E1000_DOWN
in e1000e_close was added when runtime power management was added. However
it should not be relevant for us as we perform a call to
pm_runtime_get_sync before we call e1000_down/free_irq so it should always
be back up before we call into this anyway.
Signed-off-by: Alexander Duyck
---
RFC v2: Dropped some unused variables
Added logic to check for device present before removing to pm_freeze
Fixed misplaced err_irq to before rtnl_unlock()
drivers/net/ethernet/intel/e1000e/netdev.c | 40 +++-
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index d7d56e42a6aa..8b4e589aca36 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4715,12 +4715,12 @@ int e1000e_close(struct net_device *netdev)
pm_runtime_get_sync(>dev);
- if (!test_bit(__E1000_DOWN, >state)) {
+ if (netif_device_present(netdev)) {
e1000e_down(adapter, true);
e1000_free_irq(adapter);
/* Link status message must follow this format */
- pr_info("%s NIC Link is Down\n", adapter->netdev->name);
+ pr_info("%s NIC Link is Down\n", netdev->name);
}
napi_disable(>napi);
@@ -6298,10 +6298,14 @@ static int e1000e_pm_freeze(struct device *dev)
{
struct net_device *netdev = dev_get_drvdata(dev);
struct e1000_adapter *adapter = netdev_priv(netdev);
+ bool present;
+ rtnl_lock();
+
+ present = netif_device_present(netdev);
netif_device_detach(netdev);
- if (netif_running(netdev)) {
+ if (present && netif_running(netdev)) {
int count = E1000_CHECK_RESET_COUNT;
while (test_bit(__E1000_RESETTING, >state) && count--)
@@ -6313,6 +6317,8 @@ static int e1000e_pm_freeze(struct device *dev)
e1000e_down(adapter, false);
e1000_free_irq(adapter);
}
+ rtnl_unlock();
+
e1000e_reset_interrupt_capability(adapter);
/* Allow time for pending master requests to run */
@@ -6626,27 +6632,31 @@ static int __e1000_resume(struct pci_dev *pdev)
return 0;
}
-#ifdef CONFIG_PM_SLEEP
static int e1000e_pm_thaw(struct device *dev)
{
struct net_device *netdev = dev_get_drvdata(dev);
struct e1000_adapter *adapter = netdev_priv(netdev);
+ int rc = 0;
e1000e_set_interrupt_capability(adapter);
- if (netif_running(netdev)) {
- u32 err = e1000_request_irq(adapter);
- if (err)
- return err;
+ rtnl_lock();
+ if (netif_running(netdev)) {
+ rc = e1000_request_irq(adapter);
+ if (rc)
+ goto err_irq;
e1000e_up(adapter);
}
netif_device_attach(netdev);
+err_irq:
+ rtnl_unlock();
- return 0;
+ return rc;
}
+#ifdef CONFIG_PM_SLEEP
static int e1000e_pm_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
@@ -6818,16 +6828,11 @@ static void e1000_netpoll(struct net_device *netdev)
static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
{
- struct net_device *netdev = pci_get_drvdata(pdev);
- struct e1000_adapter *adapter = netdev_priv(netdev);
-
- netif_device_detach(netdev);
+ e1000e_pm_freeze(>dev);
if (state == pci_channel_io_perm_failure)
return PCI_ERS_RESULT_DISCONNECT;
- if (netif_running(netdev))
- e1000e_down(adapter, true);
pci_disable_device(pdev);
/* Request a slot slot reset. */
@@ -6893,10 +6898,7 @@ static void e1000_io_resume(struct pci_dev *pdev)
e1000_init_manageability_pt(adapter);
- if (netif_running(netdev))
- e1000e_up(adapter);
-
- netif_device_attach(netdev);
+ e1000e_pm_thaw(>dev);
/* If the controller has AMT, do not set DRV_LOAD until the interface
* is up. For all other cases, let the f/w know that the
Re: [RFC v2 1/2] ARM: dts: omap3: Add cpu trips and cooling map for omap3 family
On Mon, Oct 7, 2019 at 10:45 AM H. Nikolaus Schaller wrote:
>
>
> > Am 07.10.2019 um 17:11 schrieb Adam Ford :
> >
> > On Sat, Sep 14, 2019 at 11:12 AM Adam Ford wrote:
> >>
> >> On Sat, Sep 14, 2019 at 9:38 AM H. Nikolaus Schaller
> >> wrote:
> >>>
> >>>
> Am 14.09.2019 um 15:42 schrieb Adam Ford :
>
> On Sat, Sep 14, 2019 at 4:20 AM H. Nikolaus Schaller
> wrote:
> >
> >
> >> Am 13.09.2019 um 17:37 schrieb Adam Ford :
> >>
> >> The OMAP3530, AM3517 and DM3730 all show thresholds of 90C and 105C
> >> depending on commercial or industrial temperature ratings. This
> >> patch expands the thermal information to the limits of 90 and 105
> >> for alert and critical.
> >>
> >
> > Tom / anyone from TI,
> >
> > I am going to rebase this patch from the current 5.4-RC branch, remove
> > the AM3517 references, and leave the throttling only applicable to
> > omap34xx and 36xx (like it is now), and remove the RFC. Before I do
> > that, I was hoping for some feedback on whether or not there is a
> > reason to not do this while acknowledging the thermal sensor isn't
> > very accurate.
>
> I wonder if there is a more precise definition what "isn't very accurate"
> means?
That's what I was trying to get by asking TI for feedback.
>
> Is it just because the TI_BANDGAP_FEATURE_UNRELIABLE bit is set in
> the driver and we assume that it is right?
The bandgap sensor is disabled by default and, when enabled, it throws
a comment saying 'You've been warned' so I mostly want to acknowledge
that in the patch.
>
> Of course the "junction temperature" (TJ) is not well defined (at which
> edge? in which area?) and the bandgap sensor can only report a single point
> of the die. So e.g. the GPU or the NEON unit may be hotter or cooler.
I look forward to running the GPU again. ;-)
>
> And, the bandgap sensor + ADC is unlikely to be well calibrated to
> 0.1°C precision.
>
> But in my experiments there seems to be not much noise and values rise
> or fall monotonic according to expectations of processor load.
>
> So a report of 90°C may not be exactly 90°C and some parts of the SoC
> may be hotter.
>
> I would also assume that the TJ limits of 90°C have some safety margin
> but there seems to be no information in the data sheet.
>
> So, IMHO an "unreliable" bandgap sensor is better than no sensor and
> no trips / cooling maps.
I completely agree.
>
> One more thing is with the omap3 bandgap sensor (driver?). It appears to
> report the value of the previous measurement. So unless it is regularily
> polled (like cpufreq seems to do) it will report outdated values. The
> first read hours after boot may report the value during probe while booting.
>
> This is also a source of missing accuracy of course. But I haven't
> investigated this (can only be tested if thermal management is turned
> off) because I think it has no practical influence if cpufreq is polling.
>
> >
> > Does anyone have any objections to this?
> >
> > Other than the omap mailing list, are there other lists that should be CC'd?
> >
> > adam
> >
> >> For boards who never use industrial temperatures, these can be
> >> changed on their respective device trees with something like:
> >>
> >> _alert0 {
> >> temperature = <85000>; /* millicelsius */
> >> };
> >>
> >> _crit {
> >> temperature = <9>; /* millicelsius */
> >> };
> >>
> >> Signed-off-by: Adam Ford
> >> ---
> >> V2: Change the CPU reference to instead of
> >>
> >> diff --git a/arch/arm/boot/dts/omap3-cpu-thermal.dtsi
> >> b/arch/arm/boot/dts/omap3-cpu-thermal.dtsi
> >> index 235ecfd61e2d..dfbd0cb0b00b 100644
> >> --- a/arch/arm/boot/dts/omap3-cpu-thermal.dtsi
> >> +++ b/arch/arm/boot/dts/omap3-cpu-thermal.dtsi
> >> @@ -17,4 +17,25 @@ cpu_thermal: cpu_thermal {
> >>
> >> /* sensor ID */
> >> thermal-sensors = < 0>;
> >> +
> >> + cpu_trips: trips {
> >> + cpu_alert0: cpu_alert {
> >> + temperature = <9>; /* millicelsius */
> >> + hysteresis = <2000>; /* millicelsius */
> >> + type = "passive";
> >> + };
> >> + cpu_crit: cpu_crit {
> >> + temperature = <105000>; /* millicelsius */
> >> + hysteresis = <2000>; /* millicelsius */
> >> + type = "critical";
> >> + };
> >> + };
> >> +
> >> + cpu_cooling_maps: cooling-maps {
> >> + map0 {
> >> + trip = <_alert0>;
> >> + cooling-device =
> >> + < THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> >> + };
> >> + };
> >> };
> >> --
> >> 2.17.1
> >>
> >
> > Here is my test log (GTA04A5 with
RE: [PATCH 1/2] Drivers: hv: vmbus: Introduce table of VMBus protocol versions
> From: linux-hyperv-ow...@vger.kernel.org
> On Behalf Of Andrea Parri
> Sent: Monday, October 7, 2019 9:31 AM
>
> +/*
> + * Table of VMBus versions listed from newest to oldest; the table
> + * must terminate with VERSION_INVAL.
> + */
> +__u32 vmbus_versions[] = {
> + VERSION_WIN10_V5,
This should be "static"?
Thanks,
Dexuan
Re: [RFC PATCH] e1000e: Use rtnl_lock to prevent race conditions between net and pci/pm
On Mon, Oct 7, 2019 at 10:12 AM David Z. Dai wrote: > > On Mon, 2019-10-07 at 10:02 -0700, Alexander Duyck wrote: > > On Mon, Oct 7, 2019 at 8:51 AM David Z. Dai wrote: > > > > > > > > > > > > We have tested on one of the test box. > > > With this patch, it doesn't crash kernel anymore, which is good! > > > > > > However we see this warning message from the log file for irq number 0: > > > [10206.317270] Trying to free already-free IRQ 0 > > > > > > With this stack: > > > [10206.317344] NIP [c018cbf8] __free_irq+0x308/0x370 > > > [10206.317346] LR [c018cbf4] __free_irq+0x304/0x370 > > > [10206.317347] Call Trace: > > > [10206.317348] [c0008b92b970] [c018cbf4] __free_irq > > > +0x304/0x370 (unreliable) > > > [10206.317351] [c0008b92ba00] [c018cd84] free_irq+0x84/0xf0 > > > [10206.317358] [c0008b92ba30] [d7449e60] e1000_free_irq > > > +0x98/0xc0 [e1000e] > > > [10206.317365] [c0008b92ba60] [d7458a70] e1000e_pm_freeze > > > +0xb8/0x100 [e1000e] > > > [10206.317372] [c0008b92baa0] [d7458b6c] > > > e1000_io_error_detected+0x34/0x70 [e1000e] > > > [10206.317375] [c0008b92bad0] [c0040358] eeh_report_failure > > > +0xc8/0x190 > > > [10206.317377] [c0008b92bb20] [c003eb2c] eeh_pe_dev_traverse > > > +0x9c/0x170 > > > [10206.317379] [c0008b92bbb0] [c0040d84] > > > eeh_handle_normal_event+0xe4/0x580 > > > [10206.317382] [c0008b92bc60] [c0041330] eeh_handle_event > > > +0x30/0x340 > > > [10206.317384] [c0008b92bd10] [c0041780] eeh_event_handler > > > +0x140/0x200 > > > [10206.317386] [c0008b92bdc0] [c01397c8] kthread+0x1a8/0x1b0 > > > [10206.317389] [c0008b92be30] [c000b560] > > > ret_from_kernel_thread+0x5c/0x7c > > > > > > Thanks! - David > > > > Hmm. I wonder if it is possibly calling the report > > e1000_io_error_detected multiple times. If so then the secondary calls > > to e1000_pm_freeze would cause issues. > > > > I will add a check so that we only down the interface and free the > > IRQs if the interface is in the present and running state. > > > > I'll submit an update patch shortly. > > > > Thanks. > > > > - Alex > It only complains about IRQ number 0 in the log. I suspect that is because the IRQ is already freed. So there are no other interrupts enabled and it thinks it is running in legacy IRQ mode. > Could you please let me know the actual place where you will add the > check? > I can retest it again. > > Thanks! - David So I will need to add another variable called "present" to e1000_pm_freeze, I will assign netif_device_present() to it after taking the rtnl_lock and before I detach the interface, and will test for it and netif_running() before calling the logic that calls e1000_down and e1000_free_irq. - Alex
Re: [PATCH] mm: vmalloc: Use the vmap_area_lock to protect ne_fit_preload_node
On Mon, Oct 07, 2019 at 06:56:11PM +0200, Uladzislau Rezki wrote: > On Mon, Oct 07, 2019 at 06:34:43PM +0200, Daniel Wagner wrote: > > I supppose, one thing which would help in this discussion, is what do > > you gain by using preempt_disable() instead of moving the lock up? > > Do you have performance numbers which could justify the code? > > > Actually there is a high lock contention on vmap_area_lock, because it > is still global. You can have a look at last slide: > > https://linuxplumbersconf.org/event/4/contributions/547/attachments/287/479/Reworking_of_KVA_allocator_in_Linux_kernel.pdf > > so this change will make it a bit higher. Thanks! I suspected something like this :( On the todo-list page you stating that vmap_area_lock could be splitted and therefore reduce the contention. If you could avoid those preempt_disable() tricks and just use plain spin_locks() to protect it would be really helpful. > From the other hand i agree > that for rt it should be fixed, probably it could be done like: > > ifdef PREEMPT_RT > migrate_disable() > #else > preempt_disable() > ... > > but i am not sure it is good either. I don't think this way to go. I guess Sebastian and Thomas have a better idea how to address this for PREEMPT_RT.
Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting
On Mon, Oct 7, 2019 at 10:07 AM Nitesh Narayan Lal wrote:
>
>
> On 10/7/19 12:27 PM, Alexander Duyck wrote:
> > On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
> >> On 10/7/19 11:33 AM, Alexander Duyck wrote:
> >>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
> On 10/2/19 10:25 AM, Alexander Duyck wrote:
> page_reporting.c change:
> @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct
> page_reporting_config
> *phconf,
> /* Process only if the page is still online */
> page = pfn_to_online_page((setbit <<
> PAGE_REPORTING_MIN_ORDER) +
> zone->base_pfn);
> - if (!page)
> + if (!page || !PageBuddy(page)) {
> + clear_bit(setbit, zone->bitmap);
> + atomic_dec(>free_pages);
> continue;
> + }
>
> >>> I suspect the zone->free_pages is going to be expensive for you to deal
> >>> with. It is a global atomic value and is going to have the cacheline
> >>> bouncing that it is contained in. As a result thinks like setting the
> >>> bitmap with be more expensive as every tome a CPU increments free_pages it
> >>> will likely have to take the cache line containing the bitmap pointer as
> >>> well.
> >> I see I will have to explore this more. I am wondering if there is a way to
> >> measure this If its effect is not visible in will-it-scale/page_fault1. If
> >> there is a noticeable amount of degradation, I will have to address this.
> > If nothing else you might look at seeing if you can split up the
> > structures so that the bitmap and nr_bits is in a different region
> > somewhere since those are read-mostly values.
>
> ok, I will try to understand the issue and your suggestion.
> Thank you for bringing this up.
>
> > Also you are now updating the bitmap and free_pages both inside and
> > outside of the zone lock so that will likely have some impact.
>
> So as per your previous suggestion, I have made the bitmap structure
> object as a rcu protected pointer. So we are safe from that side.
> The other downside which I can think of is a race where one page
> trying to increment free_pages and other trying to decrements it.
> However, being an atomic variable that should not be a problem.
> Did I miss anything?
I'm not so much worried about a race as the cache line bouncing
effect. Basically your notifier combined within this hinting thread
will likely result in more time spent by the thread that holds the
lock since it will be trying to access the bitmap to set the bit and
the free_pages to report the bit, but at the same time you will have
this thread clearing bits and decrementing the free_pages values.
One thing you could consider in your worker thread would be to do
reallocate and replace the bitmap every time you plan to walk it. By
doing that you would avoid the cacheline bouncing on the bitmap since
you would only have to read it, and you would no longer have another
thread dirtying it. You could essentially reset the free_pages at the
same time you replace the bitmap. It would need to all happen with the
zone lock held though when you swap it out.
- Alex
Re: [PATCH 1/2] Drivers: hv: vmbus: Introduce table of VMBus protocol versions
Andrea Parri writes:
> The technique used to get the next VMBus version seems increasisly
> clumsy as the number of VMBus versions increases. Performance is
> not a concern since this is only done once during system boot; it's
> just that we'll end up with more lines of code than is really needed.
>
> As an alternative, introduce a table with the version numbers listed
> in order (from the most recent to the oldest). vmbus_connect() loops
> through the versions listed in the table until it gets an accepted
> connection or gets to the end of the table (invalid version).
>
> Suggested-by: Michael Kelley
> Signed-off-by: Andrea Parri
> ---
> drivers/hv/connection.c | 51 +++--
> include/linux/hyperv.h | 2 --
> 2 files changed, 19 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
> index 6e4c015783ffc..90a32c9d79403 100644
> --- a/drivers/hv/connection.c
> +++ b/drivers/hv/connection.c
> @@ -40,29 +40,19 @@ EXPORT_SYMBOL_GPL(vmbus_connection);
> __u32 vmbus_proto_version;
> EXPORT_SYMBOL_GPL(vmbus_proto_version);
>
> -static __u32 vmbus_get_next_version(__u32 current_version)
> -{
> - switch (current_version) {
> - case (VERSION_WIN7):
> - return VERSION_WS2008;
> -
> - case (VERSION_WIN8):
> - return VERSION_WIN7;
> -
> - case (VERSION_WIN8_1):
> - return VERSION_WIN8;
> -
> - case (VERSION_WIN10):
> - return VERSION_WIN8_1;
> -
> - case (VERSION_WIN10_V5):
> - return VERSION_WIN10;
> -
> - case (VERSION_WS2008):
> - default:
> - return VERSION_INVAL;
> - }
> -}
> +/*
> + * Table of VMBus versions listed from newest to oldest; the table
> + * must terminate with VERSION_INVAL.
> + */
> +__u32 vmbus_versions[] = {
> + VERSION_WIN10_V5,
> + VERSION_WIN10,
> + VERSION_WIN8_1,
> + VERSION_WIN8,
> + VERSION_WIN7,
> + VERSION_WS2008,
> + VERSION_INVAL
> +};
>
> int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo, u32
> version)
> {
> @@ -169,8 +159,8 @@ int vmbus_negotiate_version(struct vmbus_channel_msginfo
> *msginfo, u32 version)
> */
> int vmbus_connect(void)
> {
> - int ret = 0;
> struct vmbus_channel_msginfo *msginfo = NULL;
> + int i, ret = 0;
> __u32 version;
>
> /* Initialize the vmbus connection */
> @@ -244,21 +234,18 @@ int vmbus_connect(void)
>* version.
>*/
>
> - version = VERSION_CURRENT;
> + for (i = 0; ; i++) {
> + version = vmbus_versions[i];
> + if (version == VERSION_INVAL)
> + goto cleanup;
If you use e.g. ARRAY_SIZE() you can get rid of VERSION_INVAL - and make
this code look more natural.
>
> - do {
> ret = vmbus_negotiate_version(msginfo, version);
> if (ret == -ETIMEDOUT)
> goto cleanup;
>
> if (vmbus_connection.conn_state == CONNECTED)
> break;
> -
> - version = vmbus_get_next_version(version);
> - } while (version != VERSION_INVAL);
> -
> - if (version == VERSION_INVAL)
> - goto cleanup;
> + }
>
> vmbus_proto_version = version;
> pr_info("Vmbus version:%d.%d\n",
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index b4a017093b697..7073f1eb3618c 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -194,8 +194,6 @@ static inline u32 hv_get_avail_to_write_percent(
>
> #define VERSION_INVAL -1
>
> -#define VERSION_CURRENT VERSION_WIN10_V5
> -
> /* Make maximum size of pipe payload of 16K */
> #define MAX_PIPE_DATA_PAYLOAD(sizeof(u8) * 16384)
--
Vitaly
Re: [PATCH] drm: panels: fix spi aliases of former omap panels
On Mon, 7 Oct 2019 19:04:46 +0200
Sebastian Reichel wrote:
> Hi,
>
> On Mon, Oct 07, 2019 at 06:41:30PM +0200, Andreas Kemnade wrote:
> > When the panels were moved from omap/displays/ to panel/
> > omapdss prefix was stripped, which cause spi modalias
> > to not contain the vendor-prefix anymore.
> >
> > so we had e.g. in former times:
> > compatible=omapdss,tpo,td028ttec1 -> modalias=spi:tpo,td028ttec1
> > now:
> > compatible=tpo,td028ttec1 -> modalias=spi:td028ttec1
> >
> > This is consistent with other drivers. Tested the td028ttec.c
> > only, but the pattern looks the same for the other ones.
> >
> > Fixes: 45f16c82db7e8 ("drm/omap: displays: Remove unused panel drivers")
> > Signed-off-by: Andreas Kemnade
> > ---
>
> Patch looks good to me, but you have one false positive.
>
> > [...]
> >
> > diff --git a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> > b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> > index 46cd9a2501298..838d39a263f53 100644
> > --- a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> > +++ b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> > @@ -204,7 +204,7 @@ static int ls037v7dw01_remove(struct platform_device
> > *pdev)
> > }
> >
> > static const struct of_device_id ls037v7dw01_of_match[] = {
> > - { .compatible = "sharp,ls037v7dw01", },
> > + { .compatible = "ls037v7dw01", },
> > { /* sentinel */ },
> > };
> >
>
> The DT compatible should have a vendor prefix.
>
oops, sorry, but I it seems that Laurent already has submitted a fix.
Regards,
Andreas
Re: [PATCH 09/16] x86/vmx: Introduce VMX_FEATURES_*
On Mon, Oct 07, 2019 at 07:08:28PM +0200, Paolo Bonzini wrote: > On 04/10/19 23:56, Sean Christopherson wrote: > > +#define VMX_FEATURE_RDSEED_EXITING ( 2*32+ 16) /* "" VM-Exit on RDSEED */ > > +#define VMX_FEATURE_PAGE_MOD_LOGGING ( 2*32+ 17) /* "pml" Log dirty > > pages into buffer */ > > +#define VMX_FEATURE_EPT_VIOLATION_VE ( 2*32+ 18) /* "" Conditionally > > reflect EPT violations as #VE exceptions */ > > +#define VMX_FEATURE_PT_CONCEAL_VMX ( 2*32+ 19) /* "" Suppress VMX > > indicators in Processor Trace */ > > +#define VMX_FEATURE_XSAVES ( 2*32+ 20) /* "" Enable XSAVES and > > XRSTORS in guest */ > > +#define VMX_FEATURE_RESERVED_PIN_21( 2*32+ 21) /* "" Reserved */ > > +#define VMX_FEATURE_MODE_BASED_EPT_EXEC( 2*32+ 22) /* Enable separate > > EPT EXEC bits for supervisor vs. user */ > > +#define VMX_FEATURE_RESERVED_PIN_23( 2*32+ 23) /* "" Reserved */ > > +#define VMX_FEATURE_PT_USE_GPA ( 2*32+ 24) /* "" Processor > > Trace logs GPAs */ > > +#define VMX_FEATURE_TSC_SCALING( 2*32+ 25) /* Scale hardware > > TSC when read in guest */ > > +#define VMX_FEATURE_RESERVED_PIN_26( 2*32+ 26) /* "" Reserved */ > > +#define VMX_FEATURE_RESERVED_PIN_27( 2*32+ 27) /* "" Reserved */ > > +#define VMX_FEATURE_ENCLV_EXITING ( 2*32+ 28) /* "" VM-Exit on ENCLV > > (leaf dependent) */ > > +#define VMX_FEATURE_RESERVED_PIN_29( 2*32+ 29) /* "" Reserved */ > > +#define VMX_FEATURE_RESERVED_PIN_30( 2*32+ 30) /* "" Reserved */ > > +#define VMX_FEATURE_RESERVED_PIN_31( 2*32+ 31) /* "" Reserved */ > > Pasto on the reserved bit names, but in general why is it useful to > define them? Doh. It was mostly so that I could more easily cross-reference the SDM and visually see that I wasn't skipping bits. No argument from me if it'd be preferably to omit them.
Re: [RFC PATCH] e1000e: Use rtnl_lock to prevent race conditions between net and pci/pm
On Mon, 2019-10-07 at 10:02 -0700, Alexander Duyck wrote: > On Mon, Oct 7, 2019 at 8:51 AM David Z. Dai wrote: > > > > > > > We have tested on one of the test box. > > With this patch, it doesn't crash kernel anymore, which is good! > > > > However we see this warning message from the log file for irq number 0: > > [10206.317270] Trying to free already-free IRQ 0 > > > > With this stack: > > [10206.317344] NIP [c018cbf8] __free_irq+0x308/0x370 > > [10206.317346] LR [c018cbf4] __free_irq+0x304/0x370 > > [10206.317347] Call Trace: > > [10206.317348] [c0008b92b970] [c018cbf4] __free_irq > > +0x304/0x370 (unreliable) > > [10206.317351] [c0008b92ba00] [c018cd84] free_irq+0x84/0xf0 > > [10206.317358] [c0008b92ba30] [d7449e60] e1000_free_irq > > +0x98/0xc0 [e1000e] > > [10206.317365] [c0008b92ba60] [d7458a70] e1000e_pm_freeze > > +0xb8/0x100 [e1000e] > > [10206.317372] [c0008b92baa0] [d7458b6c] > > e1000_io_error_detected+0x34/0x70 [e1000e] > > [10206.317375] [c0008b92bad0] [c0040358] eeh_report_failure > > +0xc8/0x190 > > [10206.317377] [c0008b92bb20] [c003eb2c] eeh_pe_dev_traverse > > +0x9c/0x170 > > [10206.317379] [c0008b92bbb0] [c0040d84] > > eeh_handle_normal_event+0xe4/0x580 > > [10206.317382] [c0008b92bc60] [c0041330] eeh_handle_event > > +0x30/0x340 > > [10206.317384] [c0008b92bd10] [c0041780] eeh_event_handler > > +0x140/0x200 > > [10206.317386] [c0008b92bdc0] [c01397c8] kthread+0x1a8/0x1b0 > > [10206.317389] [c0008b92be30] [c000b560] > > ret_from_kernel_thread+0x5c/0x7c > > > > Thanks! - David > > Hmm. I wonder if it is possibly calling the report > e1000_io_error_detected multiple times. If so then the secondary calls > to e1000_pm_freeze would cause issues. > > I will add a check so that we only down the interface and free the > IRQs if the interface is in the present and running state. > > I'll submit an update patch shortly. > > Thanks. > > - Alex It only complains about IRQ number 0 in the log. Could you please let me know the actual place where you will add the check? I can retest it again. Thanks! - David
Re: [PATCH 11/16] x86/cpu: Print VMX features as separate line item in /proc/cpuinfo
On 04/10/19 23:56, Sean Christopherson wrote:
> Add support for generating VMX feature names in capflags.c and printing
> the resulting names in /proc/cpuinfo as "vmx flags" when VMX support is
> detected. Do not print VMX flags if no bits are set in word 0, which
> includes Pin controls. INTR and NMI exiting are fundamental pillars of
> virtualization, if they're not supported then the CPU is broken, it does
> not actually support VMX, or the kernel wasn't built with support for
> the target CPU.
>
> Remove all code which sets the synthetic VMX flags in cpufeatures so
> that duplicate VMX features are not printed in "flags" and "vmx flags".
>
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/boot/mkcpustr.c | 1 +
> arch/x86/kernel/cpu/Makefile | 5 ++--
> arch/x86/kernel/cpu/centaur.c | 35 --
> arch/x86/kernel/cpu/intel.c | 49 ---
> arch/x86/kernel/cpu/mkcapflags.sh | 15 +++---
> arch/x86/kernel/cpu/proc.c| 15 ++
> arch/x86/kernel/cpu/zhaoxin.c | 35 --
> 7 files changed, 30 insertions(+), 125 deletions(-)
>
> diff --git a/arch/x86/boot/mkcpustr.c b/arch/x86/boot/mkcpustr.c
> index 9caa10e82217..da0ccc5de538 100644
> --- a/arch/x86/boot/mkcpustr.c
> +++ b/arch/x86/boot/mkcpustr.c
> @@ -15,6 +15,7 @@
> #include "../include/asm/required-features.h"
> #include "../include/asm/disabled-features.h"
> #include "../include/asm/cpufeatures.h"
> +#include "../include/asm/vmxfeatures.h"
> #include "../kernel/cpu/capflags.c"
>
> int main(void)
> diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
> index df5ad0cfe3e9..025cbfd45687 100644
> --- a/arch/x86/kernel/cpu/Makefile
> +++ b/arch/x86/kernel/cpu/Makefile
> @@ -54,11 +54,12 @@ obj-$(CONFIG_ACRN_GUEST) += acrn.o
>
> ifdef CONFIG_X86_FEATURE_NAMES
> quiet_cmd_mkcapflags = MKCAP $@
> - cmd_mkcapflags = $(CONFIG_SHELL) $(srctree)/$(src)/mkcapflags.sh $< $@
> + cmd_mkcapflags = $(CONFIG_SHELL) $(srctree)/$(src)/mkcapflags.sh $@ $^
>
> cpufeature = $(src)/../../include/asm/cpufeatures.h
> +vmxfeature = $(src)/../../include/asm/vmxfeatures.h
>
> -$(obj)/capflags.c: $(cpufeature) $(src)/mkcapflags.sh FORCE
> +$(obj)/capflags.c: $(cpufeature) $(vmxfeature) $(src)/mkcapflags.sh FORCE
> $(call if_changed,mkcapflags)
> endif
> targets += capflags.c
> diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
> index a6ca4c31c1b6..be11c796926b 100644
> --- a/arch/x86/kernel/cpu/centaur.c
> +++ b/arch/x86/kernel/cpu/centaur.c
> @@ -18,13 +18,6 @@
> #define RNG_ENABLED (1 << 3)
> #define RNG_ENABLE (1 << 6)/* MSR_VIA_RNG */
>
> -#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW 0x0020
> -#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
> -#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
> -#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC 0x0001
> -#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
> -#define X86_VMX_FEATURE_PROC_CTLS2_VPID 0x0020
> -
> static void init_c3(struct cpuinfo_x86 *c)
> {
> u32 lo, hi;
> @@ -119,31 +112,6 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
> }
> }
>
> -static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c)
> -{
> - u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
> -
> - rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
> - msr_ctl = vmx_msr_high | vmx_msr_low;
> -
> - if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
> - set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
> - if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
> - set_cpu_cap(c, X86_FEATURE_VNMI);
> - if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
> - rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
> - vmx_msr_low, vmx_msr_high);
> - msr_ctl2 = vmx_msr_high | vmx_msr_low;
> - if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
> - (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
> - set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
> - if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
> - set_cpu_cap(c, X86_FEATURE_EPT);
> - if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
> - set_cpu_cap(c, X86_FEATURE_VPID);
> - }
> -}
> -
> static void init_centaur(struct cpuinfo_x86 *c)
> {
> #ifdef CONFIG_X86_32
> @@ -251,9 +219,6 @@ static void init_centaur(struct cpuinfo_x86 *c)
> #endif
>
> init_feature_control_msr(c);
> -
> - if (cpu_has(c, X86_FEATURE_VMX))
> - centaur_detect_vmx_virtcap(c);
> }
>
> #ifdef CONFIG_X86_32
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 15d59224e2f8..594d2686ad52 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -494,52 +494,6 @@ static void
Re: [PATCH 10/16] x86/cpu: Detect VMX features on Intel, Centaur and Zhaoxin CPUs
On 04/10/19 23:56, Sean Christopherson wrote: > + /* > + * The high bits contain the allowed-1 settings, i.e. features that can > + * be turned on. The low bits contain the allowed-0 settings, i.e. > + * features that can be turned off. Ignore the allowed-0 settings, > + * if a feature can be turned on then it's supported. > + */ > + rdmsr(MSR_IA32_VMX_PINBASED_CTLS, ign, supported); For QEMU, we're defining a feature as supported if a feature can be turned both on and off. Since msr_low and msr_high can be defined respectively as must-be-one and can-be-one, the features become "msr_high & ~msr_low". Also, shouldn't this use the "true" feature availability MSRs if available? Paolo
Re: [PATCH v2 2/2] pinctrl: iproc: use unique name for irq chip
On 2019-10-07 1:14 a.m., Marc Zyngier wrote:
On Mon, 07 Oct 2019 08:30:50 +0100,
Geert Uytterhoeven wrote:
Hi Chris,
CC MarcZ
On Thu, Oct 3, 2019 at 2:03 AM Chris Packham
wrote:
Use the dev_name(dev) for the irqc->name so that we get unique names
when we have multiple instances of this driver.
Signed-off-by: Chris Packham
A while ago, Marc Zyngier pointed out that the irq_chip .name field
should contain the device's class name, not the instance's name.
Hence the current code is correct?
Thanks Geert for looping me in. The main reasons why I oppose this
kind of "let's show as much information as we can in /proc/interrupts"
are:
- It clutters the output badly: the formatting of this file, which is
bad enough when you have a small number of CPUs, becomes unreadable
when you have a large number of them *and* stupidly long strings
that only make sense on a given platform.
- Like it or not, /proc is ABI. We don't change things randomly there
without a good reason, and debugging isn't one of them.
- Debug information belongs to debugfs, where we already have plenty
of stuff (see CONFIG_GENERIC_IRQ_DEBUGFS). I'd rather we improve
this infrastructure if needed, rather than add platform specific
hacks.
Thanks,
M.
Thanks Marc/Geert. Sounds like we should drop patch 2 from series.
See also "[PATCH 0/4] irqchip: renesas: Use proper irq_chip name and parent"
(https://lore.kernel.org/lkml/20190607095858.10028-1-geert+rene...@glider.be/)
Note that the irqchip patches in that series have been applied; the gpio
patches haven't been applied yet.
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -858,7 +858,7 @@ static int iproc_gpio_probe(struct platform_device *pdev)
struct gpio_irq_chip *girq;
irqc = >irqchip;
- irqc->name = "bcm-iproc-gpio";
+ irqc->name = dev_name(dev);
irqc->irq_ack = iproc_gpio_irq_ack;
irqc->irq_mask = iproc_gpio_irq_mask;
irqc->irq_unmask = iproc_gpio_irq_unmask;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 01/16] x86/intel: Initialize IA32_FEATURE_CONTROL MSR at boot
On Mon, Oct 07, 2019 at 07:05:32PM +0200, Paolo Bonzini wrote: > On 04/10/19 23:56, Sean Christopherson wrote: > > Always lock IA32_FEATURE_CONTROL if it exists, even if the CPU doesn't > > support VMX, so that other existing and future kernel code that queries > > IA32_FEATURE_CONTROL can assume it's locked. > > Possibly stupid question: why bother locking it? It makes sense to lock > the MSR bits to _off_ in the firmware, but if the BIOS hasn't locked it, > why should the OS? > > It seems to me that locking introduces a lot of complication. None of the enable bits take effect until the MSR is locked. If I had to guess, ucode likely goes and pokes the enabled features during the WRMSR with the lock bit set, as opposed to the relevant features querying the MSR value as needed (querying the MSR is likely slow).
Re: krzysztof/for-next boot bisection: v5.4-rc1-48-g0bc9c79979ea on peach-pi
On Mon, 7 Oct 2019 at 02:43, kernelci.org bot wrote:
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer:*
> * Reported-by: "kernelci.org bot" *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> krzysztof/for-next boot bisection: v5.4-rc1-48-g0bc9c79979ea on peach-pi
>
> Summary:
> Start: 0bc9c79979ea Merge branch 'for-v5.5/memory-samsung-dmc-dt' into
> for-next
> Details:https://kernelci.org/boot/id/5d9a50af59b5141ce5857c07
> Plain log:
> https://storage.kernelci.org//krzysztof/for-next/v5.4-rc1-48-g0bc9c79979ea/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-exynos5800-peach-pi.txt
> HTML log:
> https://storage.kernelci.org//krzysztof/for-next/v5.4-rc1-48-g0bc9c79979ea/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-exynos5800-peach-pi.html
> Result: 0899a480ac65 ARM: dts: exynos: Add initial data for coupled
> regulators for Exynos5422/5800
Thanks for the report. Marek Szyprowski reported it on last Friday. I
dropped the patch as of now as it exposes some deadlock in regulator
code.
Best regards,
Krzysztof
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: krzysztof
> URL:https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
> Branch: for-next
> Target: peach-pi
> CPU arch: arm
> Lab:lab-collabora
> Compiler: gcc-8
> Config: multi_v7_defconfig
> Test suite: boot
>
> Breaking commit found:
>
> ---
> commit 0899a480ac658144b1fa351bb880c2858d43f824
> Author: Marek Szyprowski
> Date: Thu Oct 3 12:08:14 2019 +0200
>
> ARM: dts: exynos: Add initial data for coupled regulators for
> Exynos5422/5800
>
> Declare Exynos5422/5800 voltage ranges for opp points for big cpu core and
> bus wcore and couple their voltage supllies as vdd_arm and vdd_int should
> be in 300mV range.
>
> Signed-off-by: Marek Szyprowski
> [k.konieczny: add missing patch description]
> Signed-off-by: Kamil Konieczny
> Reviewed-by: Chanwoo Choi
> Signed-off-by: Krzysztof Kozlowski
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 2c131ad78c09..d08101b1018c 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -48,62 +48,62 @@
>
> opp-18 {
> opp-hz = /bits/ 64 <18>;
> - opp-microvolt = <125>;
> + opp-microvolt = <125 125 150>;
> clock-latency-ns = <14>;
> };
> opp-17 {
> opp-hz = /bits/ 64 <17>;
> - opp-microvolt = <1212500>;
> + opp-microvolt = <1212500 1212500 150>;
> clock-latency-ns = <14>;
> };
> opp-16 {
> opp-hz = /bits/ 64 <16>;
> - opp-microvolt = <1175000>;
> + opp-microvolt = <1175000 1175000 150>;
> clock-latency-ns = <14>;
> };
> opp-15 {
> opp-hz = /bits/ 64 <15>;
> - opp-microvolt = <1137500>;
> + opp-microvolt = <1137500 1137500 150>;
> clock-latency-ns = <14>;
> };
> opp-14 {
> opp-hz = /bits/ 64 <14>;
> - opp-microvolt = <1112500>;
> + opp-microvolt = <1112500 1112500 150>;
> clock-latency-ns = <14>;
> };
> opp-13 {
> opp-hz = /bits/ 64 <13>;
> - opp-microvolt = <1062500>;
> + opp-microvolt = <1062500 1062500 150>;
> clock-latency-ns = <14>;
> };
> opp-12 {
> opp-hz = /bits/ 64 <12>;
> - opp-microvolt = <1037500>;
> + opp-microvolt = <1037500 1037500 150>;
> clock-latency-ns = <14>;
>
[PATCH v2 2/3] ASoC: tas2770: Remove unneeded read of the TDM_CFG3 register
Remove the unneeded and incorrect read of the TDM_CFG3 register.
The read is done but the value is never used.
Signed-off-by: Dan Murphy
---
v2 - New patch no v1
sound/soc/codecs/tas2770.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/sound/soc/codecs/tas2770.c b/sound/soc/codecs/tas2770.c
index 361d0bba72b3..c1e28dd0b73e 100644
--- a/sound/soc/codecs/tas2770.c
+++ b/sound/soc/codecs/tas2770.c
@@ -386,7 +386,6 @@ static int tas2770_set_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
{
u8 tdm_rx_start_slot = 0, asi_cfg_1 = 0;
int ret;
- int value = 0;
struct snd_soc_component *component = dai->component;
struct tas2770_priv *tas2770 =
snd_soc_component_get_drvdata(component);
@@ -442,8 +441,6 @@ static int tas2770_set_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
if (ret < 0)
return ret;
- value = snd_soc_component_read32(component, TAS2770_TDM_CFG_REG3);
-
tas2770->asi_format = fmt;
return 0;
--
2.22.0.214.g8dca754b1e
[PATCH v2 3/3] ASoc: tas2770: Remove unused defines and variables
Remove unused defines and structure variables that are not
referenced by the code. If these are needed for future
enhancements then they should be added at that time.
Signed-off-by: Dan Murphy
---
v2 - New patch no v1
sound/soc/codecs/tas2770.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/sound/soc/codecs/tas2770.h b/sound/soc/codecs/tas2770.h
index d597a8280707..cbb858369fe6 100644
--- a/sound/soc/codecs/tas2770.h
+++ b/sound/soc/codecs/tas2770.h
@@ -125,40 +125,19 @@
#define ERROR_UNDER_VOLTAGE 0x008
#define ERROR_BROWNOUT 0x010
#define ERROR_CLASSD_PWR0x020
-#define TAS2770_SLOT_16BIT 16
-#define TAS2770_SLOT_32BIT 32
-#define TAS2770_I2C_RETRY_COUNT 3
-
-struct tas2770_register {
- int book;
- int page;
- int reg;
-};
-
-struct tas2770_dai_cfg {
- unsigned int dai_fmt;
- unsigned int tdm_delay;
-};
struct tas2770_priv {
struct device *dev;
struct regmap *regmap;
- struct snd_soc_codec *codec;
struct snd_soc_component *component;
- struct mutex dev_lock;
- struct hrtimer mtimer;
int power_state;
int asi_format;
struct gpio_desc *reset_gpio;
int sampling_rate;
- int frame_size;
int channel_size;
int slot_width;
int v_sense_slot;
int i_sense_slot;
- bool runtime_suspend;
- unsigned int err_code;
- struct mutex codec_lock;
};
#endif /* __TAS2770__ */
--
2.22.0.214.g8dca754b1e
[PATCH v2 1/3] ASoC: tas2770: Fix snd_soc_update_bits error handling
According the documentation for snd_soc_update_bits the API
will return a 1 if the update was successful with a value change,
a 0 if the update was successful with no value change or a negative
if the command just failed.
So the value of return in the driver needs to be checked for being less
then 0 or the caller may indicate failure when the value actually
changed.
Signed-off-by: Dan Murphy
---
v2 - Missed one update_bit return issue.
sound/soc/codecs/tas2770.c | 46 +-
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/sound/soc/codecs/tas2770.c b/sound/soc/codecs/tas2770.c
index dbbb21fe0548..361d0bba72b3 100644
--- a/sound/soc/codecs/tas2770.c
+++ b/sound/soc/codecs/tas2770.c
@@ -82,7 +82,8 @@ static int tas2770_codec_suspend(struct snd_soc_component
*component)
TAS2770_PWR_CTRL,
TAS2770_PWR_CTRL_MASK,
TAS2770_PWR_CTRL_SHUTDOWN);
- if (ret)
+
+ if (ret < 0)
return ret;
return 0;
@@ -96,8 +97,9 @@ static int tas2770_codec_resume(struct snd_soc_component
*component)
TAS2770_PWR_CTRL,
TAS2770_PWR_CTRL_MASK,
TAS2770_PWR_CTRL_ACTIVE);
- if (ret)
- return -EINVAL;
+
+ if (ret < 0)
+ return ret;
return 0;
}
@@ -149,7 +151,10 @@ static int tas2770_dac_event(struct snd_soc_dapm_widget *w,
}
end:
- return ret;
+ if (ret < 0)
+ return ret;
+
+ return 0;
}
static const struct snd_kcontrol_new isense_switch =
@@ -199,7 +204,10 @@ static int tas2770_mute(struct snd_soc_dai *dai, int mute)
TAS2770_PWR_CTRL_MASK,
TAS2770_PWR_CTRL_ACTIVE);
- return ret;
+ if (ret < 0)
+ return ret;
+
+ return 0;
}
static int tas2770_set_bitwidth(struct tas2770_priv *tas2770, int bitwidth)
@@ -252,7 +260,10 @@ static int tas2770_set_bitwidth(struct tas2770_priv
*tas2770, int bitwidth)
tas2770->i_sense_slot);
end:
- return ret;
+ if (ret < 0)
+ return ret;
+
+ return 0;
}
static int tas2770_set_samplerate(struct tas2770_priv *tas2770, int samplerate)
@@ -344,9 +355,11 @@ static int tas2770_set_samplerate(struct tas2770_priv
*tas2770, int samplerate)
}
end:
- if (!ret)
- tas2770->sampling_rate = samplerate;
- return ret;
+ if (ret < 0)
+ return ret;
+
+ tas2770->sampling_rate = samplerate;
+ return 0;
}
static int tas2770_hw_params(struct snd_pcm_substream *substream,
@@ -401,7 +414,7 @@ static int tas2770_set_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
ret = snd_soc_component_update_bits(component, TAS2770_TDM_CFG_REG1,
TAS2770_TDM_CFG_REG1_RX_MASK,
asi_cfg_1);
- if (ret)
+ if (ret < 0)
return ret;
switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
@@ -426,7 +439,7 @@ static int tas2770_set_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
ret = snd_soc_component_update_bits(component, TAS2770_TDM_CFG_REG1,
TAS2770_TDM_CFG_REG1_MASK,
(tdm_rx_start_slot << TAS2770_TDM_CFG_REG1_51_SHIFT));
- if (ret)
+ if (ret < 0)
return ret;
value = snd_soc_component_read32(component, TAS2770_TDM_CFG_REG3);
@@ -472,12 +485,12 @@ static int tas2770_set_dai_tdm_slot(struct snd_soc_dai
*dai,
ret = snd_soc_component_update_bits(component, TAS2770_TDM_CFG_REG3,
TAS2770_TDM_CFG_REG3_30_MASK,
(left_slot << TAS2770_TDM_CFG_REG3_30_SHIFT));
- if (ret)
+ if (ret < 0)
return ret;
ret = snd_soc_component_update_bits(component, TAS2770_TDM_CFG_REG3,
TAS2770_TDM_CFG_REG3_RXS_MASK,
(right_slot << TAS2770_TDM_CFG_REG3_RXS_SHIFT));
- if (ret)
+ if (ret < 0)
return ret;
switch (slot_width) {
@@ -511,10 +524,11 @@ static int tas2770_set_dai_tdm_slot(struct snd_soc_dai
*dai,
ret = -EINVAL;
}
- if (!ret)
- tas2770->slot_width = slot_width;
+ if (ret < 0)
+ return ret;
- return ret;
+ tas2770->slot_width = slot_width;
+ return 0;
}
static struct snd_soc_dai_ops tas2770_dai_ops = {
--
2.22.0.214.g8dca754b1e
Re: [PATCH 09/16] x86/vmx: Introduce VMX_FEATURES_*
On 04/10/19 23:56, Sean Christopherson wrote: > +#define VMX_FEATURE_RDSEED_EXITING ( 2*32+ 16) /* "" VM-Exit on RDSEED */ > +#define VMX_FEATURE_PAGE_MOD_LOGGING ( 2*32+ 17) /* "pml" Log dirty pages > into buffer */ > +#define VMX_FEATURE_EPT_VIOLATION_VE ( 2*32+ 18) /* "" Conditionally reflect > EPT violations as #VE exceptions */ > +#define VMX_FEATURE_PT_CONCEAL_VMX ( 2*32+ 19) /* "" Suppress VMX > indicators in Processor Trace */ > +#define VMX_FEATURE_XSAVES ( 2*32+ 20) /* "" Enable XSAVES and > XRSTORS in guest */ > +#define VMX_FEATURE_RESERVED_PIN_21 ( 2*32+ 21) /* "" Reserved */ > +#define VMX_FEATURE_MODE_BASED_EPT_EXEC ( 2*32+ 22) /* Enable separate > EPT EXEC bits for supervisor vs. user */ > +#define VMX_FEATURE_RESERVED_PIN_23 ( 2*32+ 23) /* "" Reserved */ > +#define VMX_FEATURE_PT_USE_GPA ( 2*32+ 24) /* "" Processor > Trace logs GPAs */ > +#define VMX_FEATURE_TSC_SCALING ( 2*32+ 25) /* Scale hardware > TSC when read in guest */ > +#define VMX_FEATURE_RESERVED_PIN_26 ( 2*32+ 26) /* "" Reserved */ > +#define VMX_FEATURE_RESERVED_PIN_27 ( 2*32+ 27) /* "" Reserved */ > +#define VMX_FEATURE_ENCLV_EXITING( 2*32+ 28) /* "" VM-Exit on ENCLV > (leaf dependent) */ > +#define VMX_FEATURE_RESERVED_PIN_29 ( 2*32+ 29) /* "" Reserved */ > +#define VMX_FEATURE_RESERVED_PIN_30 ( 2*32+ 30) /* "" Reserved */ > +#define VMX_FEATURE_RESERVED_PIN_31 ( 2*32+ 31) /* "" Reserved */ Pasto on the reserved bit names, but in general why is it useful to define them? Paolo
Re: [PATCH] thermal-generic-adc: Silent error message for EPROBE_DEFER
On Tue, Sep 10, 2019 at 12:59 AM Hsin-Yi Wang wrote: > > If devm_iio_channel_get() or devm_thermal_zone_of_sensor_register() > fail with EPROBE_DEFER, we shouldn't print an error message, as the > device will be probed again later. > > Signed-off-by: Hsin-Yi Wang > --- Ping on the thread. Any suggestion for this patch? Thanks
Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/7/19 12:27 PM, Alexander Duyck wrote: > On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote: >> On 10/7/19 11:33 AM, Alexander Duyck wrote: >>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote: On 10/2/19 10:25 AM, Alexander Duyck wrote: >> [...] You don't have to, I can fix the issues in my patch-set. :) > Sounds good. Hopefully the stuff I pointed out above helps you to get > a reproduction and resolve the issues. So I did observe a significant drop in running my v12 path-set [1] with the suggested test setup. However, on making certain changes the performance improved significantly. I used my v12 patch-set which I have posted earlier and made the following changes: 1. Started reporting only (MAX_ORDER - 1) pages and increased the number of pages that can be reported at a time to 32 from 16. The intent of making these changes was to bring my configuration closer to what Alexander is using. >>> The increase from 16 to 32 is valid. No point in working in too small of >>> batches. However tightening the order to only test for MAX_ORDER - 1 seems >>> like a step in the wrong direction. The bitmap approach doesn't have much >>> value if it can only work with the highest order page. I realize it is >>> probably necessary in order to make the trick for checking on page_buddy >>> work, but it seems very limiting. >> If using (pageblock_order - 1) is a better way to do this, then I can >> probably >> switch to that. >> I will agree with the fact that we have to make the reporting order >> configurable, atleast to an extent. > I think you mean pageblock_order, not pageblock_order - 1. The problem > with pageblock_order - 1 is that it will have a negative impact on > performance as it would disable THP. Ah, I see. Yes my bad. > 2. I made an additional change in my bitmap scanning logic to prevent acquiring spinlock if the page is already allocated. >>> Again, not a fan. It basically means you can only work with MAX_ORDER - 1 >>> and there will be no ability to work with anything smaller. >>> Setup: On a 16 vCPU 30 GB single NUMA guest affined to a single host NUMA, I ran the modified will-it-scale/page_fault number of times and calculated the average of the number of process and threads launched on the 16th core to compare the impact of my patch-set against an unmodified kernel. Conclusion: %Drop in number of processes launched on 16th vCPU = 1-2% %Drop in number of threads launched on 16th vCPU = 5-6% >>> These numbers don't make that much sense to me. Are you talking about a >>> fully functioning setup that is madvsing away the memory in the >>> hypervisor? >> Without making this change I was observing a significant amount of drop >> in the number of processes and specifically in the number of threads. >> I did a double-check of the configuration which I have shared. >> I was also observing the "AnonHugePages" via meminfo to check the THP usage. >> Any more suggestions about what else I can do to verify? >> I will be more than happy to try them out. > So what was the size of your guest? One thing that just occurred to me is > that you might be running a much smaller guest than I was. I am running a 30 GB guest. > >>> If so I would have expected a much higher difference versus >>> baseline as zeroing/faulting the pages in the host gets expensive fairly >>> quick. What is the host kernel you are running your test on? I'm just >>> wondering if there is some additional overhead currently limiting your >>> setup. My host kernel was just the same kernel I was running in the guest, >>> just built without the patches applied. >> Right now I have a different host-kernel. I can install the same kernel to >> the >> host as well and see if that changes anything. > The host kernel will have a fairly significant impact as I recall. For > example running a stock CentOS kernel lowered the performance compared to > running a linux-next kernel. As a result the numbers looked better since > the overall baseline was lower to begin with as the host OS was > introducing additional overhead. I see in that case I will try by installing the same guest kernel to the host as well. > Other observations: - I also tried running Alexander's latest v11 page-reporting patch set and observe a similar amount of average degradation in the number of processes and threads. - I didn't include the linear component recorded by will-it-scale because for some reason it was fluctuating too much even when I was using an unmodified kernel. If required I can investigate this further. Note: If there is a better way to analyze the will-it-scale/page_fault results then please do let me know. >>> Honestly I have mostly just focused on the processes
Re: [PATCH] mm: export cma alloc and release
On 10/7/19 9:53 AM, Christoph Hellwig wrote: On Mon, Oct 07, 2019 at 09:50:31AM -0700, Mark Salyzyn wrote: On 10/5/19 1:37 AM, Christoph Hellwig wrote: On Thu, Oct 03, 2019 at 09:55:28AM +0100, Catalin Marinas wrote: Aren't drivers supposed to use the DMA API for such allocations rather than invoking cma_*() directly? Yes, they are. We have an engineer assigned to rewriting the ion memory driver to use dma_buf interfaces. Hopefully that effort will solve the problem of requiring these interfaces to be exported so that that driver (and others) can be modularized. Thanks for the reviews, drop this patch from the list and we will regroup, and accept that standing code in the kernel can not be modularized for the moment. How is that different from the "DMA-BUF Heaps (destaging ION)" series floating around? IDK, I am asking around because I am only superficially aware of that effort. Please view this as the left hand does not know what the right hand is doing. My issue was with a series of out-of-tree drivers that use the calls, and noted that currently the ion driver is using them as well, as rationalization for a 'user' for the export. I am pushing back on those out-of-tree drivers to switch their CMA interfaces to a modern approach as a result of these reviews; the result of this review had a positive effect because I was considering exporting them in the Android distro as a minimum, and now I am soundly rejecting that approach. Sincerely -- Mark Salyzyn
Re: [Discussion v2] Usecases for the per-task latency-nice attribute
On 10/2/19 9:11 AM, David Laight wrote: > From: Parth Shah >> Sent: 30 September 2019 11:44 > ... >> 5> Separating AVX512 tasks and latency sensitive tasks on separate cores >> ( -Tim Chen ) >> === >> Another usecase we are considering is to segregate those workload that will >> pull down core cpu frequency (e.g. AVX512) from workload that are latency >> sensitive. There are certain tasks that need to provide a fast response >> time (latency sensitive) and they are best scheduled on cpu that has a >> lighter load and not have other tasks running on the sibling cpu that could >> pull down the cpu core frequency. >> >> Some users are running machine learning batch tasks with AVX512, and have >> observed that these tasks affect the tasks needing a fast response. They >> have to rely on manual CPU affinity to separate these tasks. With >> appropriate latency hint on task, the scheduler can be taught to separate >> them. > > Has this been diagnosed properly? > I can't really see how the frequency drop from AVX512 significantly affects > latency. > Most tasks that require low latency probably don't do a lot of work. > It is much more likely that the latency issues happen because the AVX512 tasks > are doing very few system calls so can't be pre-empted even by a high > priority task. This problem was conveyed to us by several customers. The issue is not that you are slow to preempt an AVX512 task on the same logical cpu thread, but the AVX512 tasks on the sibling CPU thread is dropping the CPU frequency and lowering the performance and response. Let's say that you make the latency sensitive task a real time task with high priority so it will immediately run on a cpu after being woken. But it will be slower if there's an AVX512 running on the sibling versus if other kind of tasks are running on sibling. This is the noisy neighbor effect. So it is better to isolate the latency sensitive tasks on cores that AVX512 tasks don't run on. Tim > This 'feature' is hinted by this: >> 2> TurboSched >> ( -Parth Shah ) >> >> TurboSched [2] tries to minimize the number of active cores in a socket by >> packing an un-important and low-utilization (named jitter) task on an >> already active core and thus refrains from waking up of a new core if >> possible. > > Consider this example of a process that requires low latency (sub 1ms would > be good): > - A hardware interrupt (or timer interrupt) wakes up on thread. > - When that thread wakes it wakes up other threads that are sleeping. > - All the threads 'beaver away' for a few ms (processing RTP and other audio). > - They all sleep for the rest of a 10ms period. > > The affinities are set so each thread runs on a separate cpu, and all are > SCHED_RR. > Now loop all the cpus in userspace (run: while :; do :; done) and see what > happens to the latencies. > You really want the SCHED_RR threads to immediately pre-empt the running > processes. > But I suspect nothing happens until a timer interrupt to the target cpu. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 > 1PT, UK > Registration No: 1397386 (Wales) >
Re: [PATCH 01/16] x86/intel: Initialize IA32_FEATURE_CONTROL MSR at boot
On 04/10/19 23:56, Sean Christopherson wrote: > Always lock IA32_FEATURE_CONTROL if it exists, even if the CPU doesn't > support VMX, so that other existing and future kernel code that queries > IA32_FEATURE_CONTROL can assume it's locked. Possibly stupid question: why bother locking it? It makes sense to lock the MSR bits to _off_ in the firmware, but if the BIOS hasn't locked it, why should the OS? It seems to me that locking introduces a lot of complication. Paolo
Re: [PATCH v10 12/16] leds: lp55xx: Add multicolor framework support to lp55xx
Jacek
On 10/6/19 2:52 PM, Jacek Anaszewski wrote:
Dan,
On 10/1/19 4:56 PM, Dan Murphy wrote:
Add multicolor framework support for the lp55xx family.
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 1 +
drivers/leds/leds-lp55xx-common.c | 169 +++---
drivers/leds/leds-lp55xx-common.h | 11 ++
include/linux/platform_data/leds-lp55xx.h | 6 +
4 files changed, 163 insertions(+), 24 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 84f60e35c5ee..dc3d9f2194cd 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -377,6 +377,7 @@ config LEDS_LP50XX
config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
+ depends on LEDS_CLASS_MULTI_COLOR && OF
select FW_LOADER
select FW_LOADER_USER_HELPER
help
diff --git a/drivers/leds/leds-lp55xx-common.c
b/drivers/leds/leds-lp55xx-common.c
index 44ced02b49f9..5de4f1789a44 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++ b/drivers/leds/leds-lp55xx-common.c
@@ -131,14 +131,50 @@ static struct attribute *lp55xx_led_attrs[] = {
};
ATTRIBUTE_GROUPS(lp55xx_led);
+struct led_mc_color_conversion color_component[LP55XX_MAX_GROUPED_CHAN];
Why is this global? Please move it to lp55xx_set_brightness().
ACK
+
+static int lp55xx_get_channel(struct lp55xx_led *led, int color_id)
+{
+ int i;
+
+ for (i = 0; i < led->mc_cdev.num_leds; i++) {
+ if (led->channel_color[i] == color_id)
+ return led->grouped_channels[i];
+ }
+
+ return -EINVAL;
+}
+
static int lp55xx_set_brightness(struct led_classdev *cdev,
enum led_brightness brightness)
{
struct lp55xx_led *led = cdev_to_lp55xx_led(cdev);
struct lp55xx_device_config *cfg = led->chip->cfg;
+ int channel_num;
+ int ret;
+ int i;
- led->brightness = (u8)brightness;
- return cfg->brightness_fn(led);
+ if (led->mc_cdev.num_leds > 1) {
+ led_mc_calc_brightness(>mc_cdev, brightness,
+ _component[0]);
s/_component[0]/color_component/
ACK
+
+ for (i = 0; i < led->mc_cdev.num_leds; i++) {
+ channel_num = lp55xx_get_channel(led,
+ color_component[i].color_id);
+ if (channel_num < 0)
+ return channel_num;
+
+ ret = cfg->color_intensity_fn(led, channel_num,
+color_component[i].brightness);
If you passed struct led_mc_color_conversion instead of brightness,
then in the color_intensity_fn op you could obtain channel numbers
by calling lp55xx_get_channel in a loop. And you could setup the whole
cluster in a single call.
Hmm. How would that be an improvement? Maybe the answer lies down
below in my response and we will not have to get the channel_num as we
can make the output part of the mc_color_conversion struct.
As I pointed out in v9 "Beyond that in coding this and thinking about
the design it is better to have the lp55xx_common code to do all the
heavy lifting and the children to just perform the action on the device
itself"
https://lore.kernel.org/linux-leds/4186e454-48fd-1578-cd26-083b54c70...@gmail.com/T/#u
The children should not have to know if the LED is registered to the LED
class, MC Class or Flash class only the common code should know this
information. Just need to keep the child code simple. This is why I
pass in the values as opposed to having the child figure it out.
+ if (ret)
+ return ret;
+ }
+ } else {
+ led->brightness = (u8)brightness;
+ ret = cfg->brightness_fn(led);
+ }
+
+ return ret;
}
static int lp55xx_init_led(struct lp55xx_led *led,
@@ -147,9 +183,9 @@ static int lp55xx_init_led(struct lp55xx_led *led,
struct lp55xx_platform_data *pdata = chip->pdata;
struct lp55xx_device_config *cfg = chip->cfg;
struct device *dev = >cl->dev;
+ int max_channel = cfg->max_channel;
char name[32];
int ret;
- int max_channel = cfg->max_channel;
if (chan >= max_channel) {
dev_err(dev, "invalid channel: %d / %d\n", chan, max_channel);
@@ -159,10 +195,37 @@ static int lp55xx_init_led(struct lp55xx_led *led,
if (pdata->led_config[chan].led_current == 0)
return 0;
+ if (pdata->led_config[chan].name) {
+ led->cdev.name = pdata->led_config[chan].name;
+ } else {
+ snprintf(name, sizeof(name), "%s:channel%d",
+ pdata->label ? : chip->cl->name, chan);
+ led->cdev.name = name;
Re: spi: Add call to spi_slave_abort() function when spidev driver is released
On Fri, Sep 27, 2019 at 12:38:49AM +0200, Lukasz Majewski wrote: > Maybe, it would be sufficient for now to move the spi_slave_abort() in > spi_release() before we decrease (spidev->users--) the use count? I think that should be OK, or possibly safer to do it at the start of the if (!spidev->users) section to avoid problems with fork()/exec() combinations. It'll need an if (spidev->spi) check as well, if we manage to hit that we've pretty much lost anyway though and I'm not sure I see a route to sensible error handling. signature.asc Description: PGP signature
[PATCH v3] dt-bindings: iio: maxbotix,mb1232.yaml: transform to yaml
transform existing documentation of maxbotix,mb1232 ultrasonic ranger
from text documentation format into yaml.
Changes in v3:
- add a i2c node around device node to set up #address-cells and
#size-cells for omitting error during make dt_binding_check
Changes in v2:
- removed description of reg property
- added a line:
additionalProperties: false
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/maxbotix,mb1232.txt | 29 ---
.../bindings/iio/proximity/maxbotix,mb1232.yaml| 60 ++
2 files changed, 60 insertions(+), 29 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
create mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
deleted file mode 100644
index dd1058fbe9c3..
--- a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
- mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
- for ranging
-
-Required properties:
- - compatible: "maxbotix,mb1202",
- "maxbotix,mb1212",
- "maxbotix,mb1222",
- "maxbotix,mb1232",
- "maxbotix,mb1242",
- "maxbotix,mb7040" or
- "maxbotix,mb7137"
-
- - reg:i2c address of the device, see also i2c/i2c.txt
-
-Optional properties:
- - interrupts: Interrupt used to announce the preceding reading
- request has finished and that data is available.
- If no interrupt is specified the device driver
- falls back to wait a fixed amount of time until
- data can be retrieved.
-
-Example:
-proximity@70 {
- compatible = "maxbotix,mb1232";
- reg = <0x70>;
- interrupt-parent = <>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
-};
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
new file mode 100644
index ..3eac248f291d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/maxbotix,mb1232.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MaxBotix I2CXL-MaxSonar ultrasonic distance sensor
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
+ mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
+ for ranging
+
+ Specifications about the devices can be found at:
+ https://www.maxbotix.com/documents/I2CXL-MaxSonar-EZ_Datasheet.pdf
+
+properties:
+ compatible:
+enum:
+ - maxbotix,mb1202
+ - maxbotix,mb1212
+ - maxbotix,mb1222
+ - maxbotix,mb1232
+ - maxbotix,mb1242
+ - maxbotix,mb7040
+ - maxbotix,mb7137
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description:
+ Interrupt used to announce the preceding reading request has finished
+ and that data is available. If no interrupt is specified the device
+ driver falls back to wait a fixed amount of time until data can be
+ retrieved.
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ proximity@70 {
+compatible = "maxbotix,mb1232";
+reg = <0x70>;
+interrupt-parent = <>;
+interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
--
2.11.0
Re: [RFC PATCH] e1000e: Use rtnl_lock to prevent race conditions between net and pci/pm
On Mon, Oct 7, 2019 at 8:51 AM David Z. Dai wrote: > > We have tested on one of the test box. > With this patch, it doesn't crash kernel anymore, which is good! > > However we see this warning message from the log file for irq number 0: > [10206.317270] Trying to free already-free IRQ 0 > > With this stack: > [10206.317344] NIP [c018cbf8] __free_irq+0x308/0x370 > [10206.317346] LR [c018cbf4] __free_irq+0x304/0x370 > [10206.317347] Call Trace: > [10206.317348] [c0008b92b970] [c018cbf4] __free_irq > +0x304/0x370 (unreliable) > [10206.317351] [c0008b92ba00] [c018cd84] free_irq+0x84/0xf0 > [10206.317358] [c0008b92ba30] [d7449e60] e1000_free_irq > +0x98/0xc0 [e1000e] > [10206.317365] [c0008b92ba60] [d7458a70] e1000e_pm_freeze > +0xb8/0x100 [e1000e] > [10206.317372] [c0008b92baa0] [d7458b6c] > e1000_io_error_detected+0x34/0x70 [e1000e] > [10206.317375] [c0008b92bad0] [c0040358] eeh_report_failure > +0xc8/0x190 > [10206.317377] [c0008b92bb20] [c003eb2c] eeh_pe_dev_traverse > +0x9c/0x170 > [10206.317379] [c0008b92bbb0] [c0040d84] > eeh_handle_normal_event+0xe4/0x580 > [10206.317382] [c0008b92bc60] [c0041330] eeh_handle_event > +0x30/0x340 > [10206.317384] [c0008b92bd10] [c0041780] eeh_event_handler > +0x140/0x200 > [10206.317386] [c0008b92bdc0] [c01397c8] kthread+0x1a8/0x1b0 > [10206.317389] [c0008b92be30] [c000b560] > ret_from_kernel_thread+0x5c/0x7c > > Thanks! - David Hmm. I wonder if it is possibly calling the report e1000_io_error_detected multiple times. If so then the secondary calls to e1000_pm_freeze would cause issues. I will add a check so that we only down the interface and free the IRQs if the interface is in the present and running state. I'll submit an update patch shortly. Thanks. - Alex
Re: [PATCH v2] dt-bindings: iio: maxbotix,mb1232.yaml: transform to yaml
Hi Rob,
i don't get this error. Is there anything i'm doing wrong here?
ak@arbad:/project/opt-sw/linux-robh$ make O=../build-wega-robh/ dt_binding_check
make[1]: Verzeichnis „/project/opt-sw/build-wega-robh“ wird betreten
SCHEMA Documentation/devicetree/bindings/processed-schema.yaml
/project/opt-sw/linux-robh/Documentation/devicetree/bindings/net/adi,adin.yaml:
ignoring, error in schema 'adi,fifo-depth-bits'
warning: no schema found in file:
/project/opt-sw/linux-robh/Documentation/devicetree/bindings/net/adi,adin.yaml
/project/opt-sw/linux-robh/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml:
ignoring, error in schema '0'
warning: no schema found in file:
/project/opt-sw/linux-robh/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
CHKDT Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
CHKDT [...]
But anyway i've fixed and send it out again.
Andreas
Rob Herring schrieb am Mo, 07. Okt 07:42:
> On Sun, Oct 6, 2019 at 9:27 AM Andreas Klinger wrote:
> >
> > transform existing documentation of maxbotix,mb1232 ultrasonic ranger
> > from text documentation format into yaml.
> >
> > Changes in v2:
> > - removed description of reg property
> > - added a line:
> > additionalProperties: false
> >
> > Signed-off-by: Andreas Klinger
> > ---
> > .../bindings/iio/proximity/maxbotix,mb1232.txt | 29 ---
> > .../bindings/iio/proximity/maxbotix,mb1232.yaml| 56
> > ++
> > 2 files changed, 56 insertions(+), 29 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
> > create mode 100644
> > Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
> > b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
> > deleted file mode 100644
> > index dd1058fbe9c3..
> > --- a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
> > +++ /dev/null
> > @@ -1,29 +0,0 @@
> > -* MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
> > - mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
> > - for ranging
> > -
> > -Required properties:
> > - - compatible: "maxbotix,mb1202",
> > - "maxbotix,mb1212",
> > - "maxbotix,mb1222",
> > - "maxbotix,mb1232",
> > - "maxbotix,mb1242",
> > - "maxbotix,mb7040" or
> > - "maxbotix,mb7137"
> > -
> > - - reg:i2c address of the device, see also
> > i2c/i2c.txt
> > -
> > -Optional properties:
> > - - interrupts: Interrupt used to announce the preceding reading
> > - request has finished and that data is available.
> > - If no interrupt is specified the device driver
> > - falls back to wait a fixed amount of time until
> > - data can be retrieved.
> > -
> > -Example:
> > -proximity@70 {
> > - compatible = "maxbotix,mb1232";
> > - reg = <0x70>;
> > - interrupt-parent = <>;
> > - interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> > -};
> > diff --git
> > a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
> > b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
> > new file mode 100644
> > index ..e2fb1f6d4dbe
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
> > @@ -0,0 +1,56 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/proximity/maxbotix,mb1232.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MaxBotix I2CXL-MaxSonar ultrasonic distance sensor
> > +
> > +maintainers:
> > + - Andreas Klinger
> > +
> > +description: |
> > + MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
> > + mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
> > + for ranging
> > +
> > + Specifications about the devices can be found at:
> > + https://www.maxbotix.com/documents/I2CXL-MaxSonar-EZ_Datasheet.pdf
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - maxbotix,mb1202
> > + - maxbotix,mb1212
> > + - maxbotix,mb1222
> > + - maxbotix,mb1232
> > + - maxbotix,mb1242
> > + - maxbotix,mb7040
> > + - maxbotix,mb7137
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +description:
> > + Interrupt used to announce the preceding reading request has finished
> > + and that data is available. If no interrupt is specified the device
> > + driver falls back to wait a fixed amount of time until data can be
> > + retrieved.
> > +maxItems: 1
> > +
> > +required:
> > + -
