Re: [PATCH v4 6/10] dt-bindings: pwm: update bindings for MT7628 SoC
On Tue, Aug 20, 2019 at 09:40:21AM +0800, Sam Shih wrote: > From: sam shih > > This updates bindings for MT7628 pwm controller. > > Signed-off-by: Sam Shih Apart from different capitalisation in Author name and S-o-B, this patch looks fine. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v4 5/10] dt-bindings: pwm: add a property "num-pwms"
On Tue, Aug 20, 2019 at 09:40:20AM +0800, Sam Shih wrote: > From: Ryder Lee > > This adds a property "num-pwms" in example so that we could > specify the number of PWM channels via device tree. > > Signed-off-by: Ryder Lee > Signed-off-by: Sam Shih > Reviewed-by: Matthias Brugger Acked-by: Uwe Kleine-König Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
RE: [PATCH] pwm: mxs: use devm_platform_ioremap_resource() to simplify code
Gentle ping... > > From: anson.hu...@nxp.com > > Sent: Thursday, July 18, 2019 9:32 AM > > > > Use the new helper devm_platform_ioremap_resource() which wraps the > > platform_get_resource() and devm_ioremap_resource() together, to > > simplify the code. > > > > Signed-off-by: Anson Huang > > Reviewed-by: Dong Aisheng > > Regards > Aisheng
Re: [PATCH v4 4/10] pwm: mediatek: use pwm_mediatek as common prefix
On Tue, Aug 20, 2019 at 09:40:19AM +0800, Sam Shih wrote: > From: sam shih > > Use pwm_mediatek as common prefix to match the filename. > No functional change intended. > > Signed-off-by: Ryder Lee > Signed-off-by: Sam Shih > --- > drivers/pwm/pwm-mediatek.c | 117 ++--- > 1 file changed, 58 insertions(+), 59 deletions(-) > > diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c > index a70b69a975c1..d85761ad5283 100644 > --- a/drivers/pwm/pwm-mediatek.c > +++ b/drivers/pwm/pwm-mediatek.c > @@ -1,12 +1,10 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > - * Mediatek Pulse Width Modulator driver > + * MediaTek Pulse Width Modulator driver > * > * Copyright (C) 2015 John Crispin > * Copyright (C) 2017 Zhi Mao > * > - * This file is licensed under the terms of the GNU General Public > - * License version 2. This program is licensed "as is" without any > - * warranty of any kind, whether express or implied. The license stuff is a separate change. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v4 3/10] pwm: mediatek: allocate the clks array dynamically and fix mt7628 pwm
Hello,
On Tue, Aug 20, 2019 at 09:40:18AM +0800, Sam Shih wrote:
> From: Ryder Lee
>
> Instead of using fixed size of arrays, allocate the memory for them
> based on the information we get from the chips.
>
> Also fix mt7628 pwm during configure from userspace. The SoC
> is legacy MIPS and has no complex clock tree. This patch add property
> clock-frequency to the SoC specific data and legacy MIPS SoC need to
> configure it in DT. This property is use for period calculation.
This fix is worth a separate patch.
> Signed-off-by: Ryder Lee
> Signed-off-by: Sam Shih
> ---
> Changes since v4:
> - Follow reviewers's comments
> 1. use pc->soc->has_clks to check clocks exist or not.
> 2. Add error message when probe() unable to get clks
> - Fixes bug when SoC is old mips which has no complex clock tree.
> if clocks not exist, use the new property from DT to apply period caculation;
> otherwise, use clk_get_rate to get clock frequency and apply period
> caculation.
> ---
> drivers/pwm/pwm-mediatek.c | 94 +++---
> 1 file changed, 56 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> index f9d67fb66adb..a70b69a975c1 100644
> --- a/drivers/pwm/pwm-mediatek.c
> +++ b/drivers/pwm/pwm-mediatek.c
> @@ -35,25 +35,6 @@
>
> #define PWM_CLK_DIV_MAX 7
>
> -enum {
> - MTK_CLK_MAIN = 0,
> - MTK_CLK_TOP,
> - MTK_CLK_PWM1,
> - MTK_CLK_PWM2,
> - MTK_CLK_PWM3,
> - MTK_CLK_PWM4,
> - MTK_CLK_PWM5,
> - MTK_CLK_PWM6,
> - MTK_CLK_PWM7,
> - MTK_CLK_PWM8,
> - MTK_CLK_MAX,
> -};
> -
> -static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
> - "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5", "pwm6", "pwm7",
> - "pwm8"
> -};
> -
> struct mtk_pwm_platform_data {
> unsigned int fallback_npwms;
> bool pwm45_fixup;
> @@ -64,12 +45,17 @@ struct mtk_pwm_platform_data {
> * struct mtk_pwm_chip - struct representing PWM chip
> * @chip: linux PWM chip representation
> * @regs: base address of PWM chip
> - * @clks: list of clocks
> + * @clk_top: the top clock generator
> + * @clk_main: the clock used by PWM core
> + * @clk_pwms: the clock used by each PWM channel
> */
> struct mtk_pwm_chip {
> struct pwm_chip chip;
> void __iomem *regs;
> - struct clk *clks[MTK_CLK_MAX];
> + struct clk *clk_top;
> + struct clk *clk_main;
> + struct clk **clk_pwms;
> + unsigned int clk_freq;
> const struct mtk_pwm_platform_data *soc;
> };
>
> @@ -90,24 +76,24 @@ static int mtk_pwm_clk_enable(struct pwm_chip *chip,
> struct pwm_device *pwm)
> if (!pc->soc->has_clks)
> return 0;
>
> - ret = clk_prepare_enable(pc->clks[MTK_CLK_TOP]);
> + ret = clk_prepare_enable(pc->clk_top);
> if (ret < 0)
> return ret;
>
> - ret = clk_prepare_enable(pc->clks[MTK_CLK_MAIN]);
> + ret = clk_prepare_enable(pc->clk_main);
> if (ret < 0)
> goto disable_clk_top;
>
> - ret = clk_prepare_enable(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
> + ret = clk_prepare_enable(pc->clk_pwms[pwm->hwpwm]);
> if (ret < 0)
> goto disable_clk_main;
>
> return 0;
>
> disable_clk_main:
> - clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
> + clk_disable_unprepare(pc->clk_main);
> disable_clk_top:
> - clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
> + clk_disable_unprepare(pc->clk_top);
>
> return ret;
> }
> @@ -119,9 +105,9 @@ static void mtk_pwm_clk_disable(struct pwm_chip *chip,
> struct pwm_device *pwm)
> if (!pc->soc->has_clks)
> return;
>
> - clk_disable_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
> - clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
> - clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
> + clk_disable_unprepare(pc->clk_pwms[pwm->hwpwm]);
> + clk_disable_unprepare(pc->clk_main);
> + clk_disable_unprepare(pc->clk_top);
> }
>
> static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
> @@ -141,19 +127,24 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct
> pwm_device *pwm,
> int duty_ns, int period_ns)
> {
> struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
> - struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
> + unsigned int clk_freq;
> u32 clkdiv = 0, cnt_period, cnt_duty, reg_width = PWMDWIDTH,
> reg_thres = PWMTHRES;
> u64 resolution;
> int ret;
>
> + if (pc->soc->has_clks)
> + clk_freq = clk_get_rate(pc->clk_pwms[pwm->hwpwm]);
> + else
> + clk_freq = pc->clk_freq;
> +
> ret = mtk_pwm_clk_enable(chip, pwm);
> if (ret < 0)
> return ret;
>
> /* Using resolution in picosecond gets accuracy higher */
> resolution = (u64)NSEC_PER_SEC * 1000;
> - do_div(resolution, clk_get_rate(clk));
> +
Re: [PATCH 20/21] ASoC: sun4i-i2s: Add support for TDM slots
Hi, Maxime,
On 8/19/19 10:25 PM, Maxime Ripard wrote:
From: Maxime Ripard
The i2s controller supports TDM, for up to 8 slots. Let's support the TDM
API.
Signed-off-by: Maxime Ripard
---
sound/soc/sunxi/sun4i-i2s.c | 40 --
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 0dac09814b65..4f76daeaaed7 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -168,6 +168,8 @@ struct sun4i_i2s {
struct reset_control *rst;
unsigned int mclk_freq;
+ unsigned intslots;
+ unsigned intslot_width;
struct snd_dmaengine_dai_dma_data capture_dma_data;
struct snd_dmaengine_dai_dma_data playback_dma_data;
@@ -287,7 +289,7 @@ static bool sun4i_i2s_oversample_is_valid(unsigned int
oversample)
static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
unsigned int rate,
- unsigned int channels,
+ unsigned int slots,
unsigned int word_size)
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
@@ -335,7 +337,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
bclk_parent_rate = i2s->variant->get_bclk_parent_rate(i2s);
bclk_div = sun4i_i2s_get_bclk_div(i2s, bclk_parent_rate,
- rate, channels, word_size);
+ rate, slots, word_size);
if (bclk_div < 0) {
dev_err(dai->dev, "Unsupported BCLK divider: %d\n", bclk_div);
return -EINVAL;
@@ -419,6 +421,10 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s
*i2s,
const struct snd_pcm_hw_params *params)
{
unsigned int channels = params_channels(params);
+ unsigned int slots = channels;
+
+ if (i2s->slots)
+ slots = i2s->slots;
/* Map the channels for playback and capture */
regmap_write(i2s->regmap, SUN8I_I2S_TX_CHAN_MAP_REG, 0x76543210);
@@ -428,7 +434,6 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s
*i2s,
regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG,
SUN4I_I2S_CHAN_SEL_MASK,
SUN4I_I2S_CHAN_SEL(channels));
-
regmap_update_bits(i2s->regmap, SUN8I_I2S_RX_CHAN_SEL_REG,
SUN4I_I2S_CHAN_SEL_MASK,
SUN4I_I2S_CHAN_SEL(channels));
@@ -452,10 +457,18 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
*substream,
struct snd_soc_dai *dai)
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
+ unsigned int word_size = params_width(params);
unsigned int channels = params_channels(params);
+ unsigned int slots = channels;
int ret, sr, wss;
u32 width;
+ if (i2s->slots)
+ slots = i2s->slots;
+
+ if (i2s->slot_width)
+ word_size = i2s->slot_width;
+
ret = i2s->variant->set_chan_cfg(i2s, params);
if (ret < 0) {
dev_err(dai->dev, "Invalid channel configuration\n");
@@ -477,15 +490,14 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
*substream,
if (sr < 0)
return -EINVAL;
- wss = i2s->variant->get_wss(i2s, params_width(params));
+ wss = i2s->variant->get_wss(i2s, word_size);
if (wss < 0)
return -EINVAL;
regmap_field_write(i2s->field_fmt_wss, wss);
regmap_field_write(i2s->field_fmt_sr, sr);
- return sun4i_i2s_set_clk_rate(dai, params_rate(params),
- channels, params_width(params));
+ return sun4i_i2s_set_clk_rate(dai, params_rate(params), slots,
word_size);
}
static int sun4i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s,
@@ -785,10 +797,26 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai *dai,
int clk_id,
return 0;
}
+static int sun4i_i2s_set_tdm_slot(struct snd_soc_dai *dai,
+ unsigned int tx_mask, unsigned int rx_mask,
+ int slots, int slot_width)
+{
+ struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
+
+ if (slots > 8)
+ return -EINVAL;
+
+ i2s->slots = slots;
+ i2s->slot_width = slot_width;
+
+ return 0;
+}
+
static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
.hw_params = sun4i_i2s_hw_params,
.set_fmt= sun4i_i2s_set_fmt,
.set_sysclk = sun4i_i2s_set_sysclk,
+ .set_tdm_slot = sun4i_i2s_set_tdm_slot,
.trigger= sun4i_i2s_trigger,
};
it seems like you forgot to implement sun4i_i2s_dai_ops.set_bclk_ratio
because, as I far as I understand, it should alter tdm slots
functionality
Re: [RFC 02/11] dt-bindings: power: amlogic, meson-gx-pwrc: Add SM1 bindings
Hi Kevin,
On Tue, Aug 20, 2019 at 2:06 AM Kevin Hilman wrote:
[...]
> >> +ao_sysctrl: sys-ctrl@0 {
> >> + compatible = "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd";
> >> + reg = <0x0 0x0 0x0 0x100>;
> >> +
> >> + pwrc: power-controller {
> >> + compatible = "amlogic,meson-sm1-pwrc";
> >> + #power-domain-cells = <1>;
> >> + amlogic,hhi-sysctrl = <>;
> >> + };
> >> +};
> >
> > I'm not sure that we want to mix HHI and AO power domains in one driver
> > again
>
> We're not mixing here. These are all EE domains. They just have some
> control registers in the AO memory region.
looking at patch 04/11 I see what you mean
(I'm describing it in my own words to make sure I got it right)
we are controlling the EE power domains with this binding.
each power domain has 1 bit in the HHI registers and 2 more bits
("sleep" and "isolation") in the AO region
then it makes sense to describe this together
> > back in March I asked a few questions about modelling the power
> > domains and Kevin explained that we can implement them hierarchical:
> > [0]
> > unfortunately I didn't have the time to work on this - however, now
> > that we implement a new driver: should we follow this hierarchical
> > approach?
>
> The more I look at this, I don't think we have a commpelling need to
> model them hierarchically. The main reason being is that of the 3
> top-level domains I listed[0], we can only managing the EE domains in the
> kernel. It doesn't make sense to model/manage AO domains because, well,
> they are always-on (AO). The CPU domains are managed my the PSCI
> firmware, and we don't/won't have any control over that.
agreed, this is the same for the 32-bit SoCs except that we manage the
CPU domains in arch/arm/mach-meson/platsmp.c instead of PSCI firmware
(no problem here, I'm just mentioning it to get a complete picture)
> For that reason, I think it makes the most sense to have a generic
> driver that handles all the EE domains.
>
> IMO, the SM1 driver that Neil wrote in patch 4 of this series is 80%
> there. If we generalize that little more, it can be quite easily used
> for all the EE domains.
with your description above I agree.
for the 32-bit SoCs it would be beneficial if the register layout in
the bindings was swapped:
- have the power controller as child of HHI
- pass the AO syscon
my main points for this are:
- it seems that for some power domains there are no AO register bits,
for example the Ethernet Memory PD (GXBB datasheet [0] section 18.3 on
page 48 and Meson8b datasheet [1] section 5.4 on page 17)
- less confusion: if it's a power domain controller for the EE region
then it should be located there, even if it has additional bits
elsewhere
- (weakest argument though) on the 32-bit SoCs we currently don't have
a "big AO syscon" (and I don't see that we actually need it), but we
do have a "amlogic,meson8b-pmu", "syscon" binding which covers
AO_RTI_GEN_PWR_SLEEP0 (I should probably extend it so it covers
AO_RTI_GEN_PWR_ISO0 as well, that just extra 4 bytes)
What do you think?
Martin
[0] https://dn.odroid.com/S905/DataSheet/S905_Public_Datasheet_V1.1.4.pdf
[1] https://dn.odroid.com/S805/Datasheet/S805_Datasheet%20V0.8%2020150126.pdf
Re: [PATCH v4 2/10] pwm: mediatek: droping the check for of_device_get_match_data
Hello, On Tue, Aug 20, 2019 at 09:40:17AM +0800, Sam Shih wrote: > From: sam shih Your Signed-off-by and the mail's From uses capital letters. Can you please make them all match? > This patch drop the check for of_device_get_match_data. > Due to the only way call driver probe is compatible match, > In this case, the platform data should never be NULL. Yeah, all entries in the of_match_table have a .data pointer. Theoretically the driver could be bound by driver.name and then of_device_get_match_data returns NULL. It's still ok to drop this check if you want to, I just want to make sure this possibility is known. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v4] kasan: add memory corruption identification for software tag-based mode
On Tue, 2019-08-06 at 13:43 +0800, Walter Wu wrote: > This patch adds memory corruption identification at bug report for > software tag-based mode, the report show whether it is "use-after-free" > or "out-of-bound" error instead of "invalid-access" error. This will make > it easier for programmers to see the memory corruption problem. > > We extend the slab to store five old free pointer tag and free backtrace, > we can check if the tagged address is in the slab record and make a > good guess if the object is more like "use-after-free" or "out-of-bound". > therefore every slab memory corruption can be identified whether it's > "use-after-free" or "out-of-bound". > > == Changes > Change since v1: > - add feature option CONFIG_KASAN_SW_TAGS_IDENTIFY. > - change QUARANTINE_FRACTION to reduce quarantine size. > - change the qlist order in order to find the newest object in quarantine > - reduce the number of calling kmalloc() from 2 to 1 time. > - remove global variable to use argument to pass it. > - correct the amount of qobject cache->size into the byes of qlist_head. > - only use kasan_cache_shrink() to shink memory. > > Change since v2: > - remove the shinking memory function kasan_cache_shrink() > - modify the description of the CONFIG_KASAN_SW_TAGS_IDENTIFY > - optimize the quarantine_find_object() and qobject_free() > - fix the duplicating function name 3 times in the header. > - modify the function name set_track() to kasan_set_track() > > Change since v3: > - change tag-based quarantine to extend slab to identify memory corruption Hi,Andrey, Would you review the patch,please? This patch is to pre-allocate slub record(tag and free backtrace) during create slub object. When kernel has memory corruption, it will print correct corruption type and free backtrace. Thanks. Walter
Re: [RT PATCH v2] net/xfrm/xfrm_ipcomp: Protect scratch buffer with local_lock
Hi Juri, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc5 next-20190819] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Juri-Lelli/net-xfrm-xfrm_ipcomp-Protect-scratch-buffer-with-local_lock/20190820-113542 config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=ia64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> net//xfrm/xfrm_ipcomp.c:17:10: fatal error: linux/locallock.h: No such file >> or directory #include ^~~ compilation terminated. vim +17 net//xfrm/xfrm_ipcomp.c > 17 #include 18 #include 19 #include 20 #include 21 #include 22 #include 23 #include 24 #include 25 #include 26 #include 27 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
Leonardo Bras wrote: > If IPv6 is disabled on boot (ipv6.disable=1), but nft_fib_inet ends up > dealing with a IPv6 package, it causes a kernel panic in > fib6_node_lookup_1(), crashing in bad_page_fault. > > The panic is caused by trying to deference a very low address (0x38 > in ppc64le), due to ipv6.fib6_main_tbl = NULL. > BUG: Kernel NULL pointer dereference at 0x0038 > > Fix this behavior by dropping IPv6 packages if !ipv6_mod_enabled(). Wouldn't fib_netdev.c have the same problem? If so, might be better to place this test in both nft_fib6_eval_type and nft_fib6_eval.
[PATCH] ecryptfs: fix a memory leak bug
In ecryptfs_init_messaging(), if the allocation for 'ecryptfs_msg_ctx_arr'
fails, the previously allocated 'ecryptfs_daemon_hash' is not deallocated,
leading to a memory leak bug. To fix this issue, free
'ecryptfs_daemon_hash' before returning the error.
Signed-off-by: Wenwen Wang
---
fs/ecryptfs/messaging.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ecryptfs/messaging.c b/fs/ecryptfs/messaging.c
index d668e60..c05ca39 100644
--- a/fs/ecryptfs/messaging.c
+++ b/fs/ecryptfs/messaging.c
@@ -379,6 +379,7 @@ int __init ecryptfs_init_messaging(void)
* ecryptfs_message_buf_len),
GFP_KERNEL);
if (!ecryptfs_msg_ctx_arr) {
+ kfree(ecryptfs_daemon_hash);
rc = -ENOMEM;
goto out;
}
--
2.7.4
Re: [PATCH] nfc: st-nci: Fix an incorrect skb_buff size in 'st_nci_i2c_read()'
Le 12/08/2019 à 05:57, David Miller a écrit : From: Christophe JAILLET Date: Tue, 6 Aug 2019 16:16:40 +0200 In 'st_nci_i2c_read()', we allocate a sk_buff with a size of ST_NCI_I2C_MIN_SIZE + len. However, later on, we first 'skb_reserve()' ST_NCI_I2C_MIN_SIZE bytes, then we 'skb_put()' ST_NCI_I2C_MIN_SIZE bytes. Finally, if 'len' is not 0, we 'skb_put()' 'len' bytes. So we use ST_NCI_I2C_MIN_SIZE*2 + len bytes. This is incorrect and should already panic. I guess that it does not occur because of extra memory allocated because of some rounding. Fix it and allocate enough room for the 'skb_reserve()' and the 'skb_put()' calls. Signed-off-by: Christophe JAILLET --- This patch is LIKELY INCORRECT. So think twice to what is the correct solution before applying it. Maybe the skb_reserve should be axed or some other sizes are incorrect. There seems to be an issue, that's all I can say. The skb_reserve() should be removed, I don't fully understand the potential implications, but looks ok to me. At least, the allocated memory and the size of the used memory would match. What I don't understand is why is does not BUG_ON with the current code. Does my suspected "over allocation" because of rounding/aligment could hide the issue? A Tested-by: by someone who has the corresponding hardware would also be useful IMHO. and the second memcpy() should remove the " + ST_NCI_I2C_MIN_SIZE". Hmm, not sure on this one. The skb is manipulated only with skb_put. So only the tail pointer and len are updated. The data pointer remains at the same position, so there should effectively be an offset of ST_NCI_I2C_MIN_SIZE for the 2nd memcpy. Maybe, using skb_put_data would be cleaner here, in order to "concatenate" these 2 parts without having to handle by hand the right position in the buffer. If you agree, I'll send a V2. Thx for the review and comments. CJ This SKB just get sent down to ndlc_recv() so the content returned from I2C should places at skb->data to be processed. Pretty clear this code was never tested.
Re: [PATCH v4 1/10] pwm: mediatek: add a property "num-pwms"
Hello,
On Tue, Aug 20, 2019 at 09:40:16AM +0800, Sam Shih wrote:
> From: Ryder Lee
>
> This adds a property "num-pwms" to avoid having an endless
> list of compatibles with no differences for the same driver.
>
> Signed-off-by: Ryder Lee
> Signed-off-by: Sam Shih
> ---
> Used:
> https://patchwork.kernel.org/project/linux-mediatek/list/?series=68207
>
> Changes since v4:
> Follow reviewer's comments:
> Move the changes of droping the check for of_device_get_match_data
> returning non-NULL to next patch
> ---
> drivers/pwm/pwm-mediatek.c | 30 +-
> 1 file changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> index eb6674ce995f..287fda3674ce 100644
> --- a/drivers/pwm/pwm-mediatek.c
> +++ b/drivers/pwm/pwm-mediatek.c
> @@ -55,7 +55,7 @@ static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
> };
>
> struct mtk_pwm_platform_data {
> - unsigned int num_pwms;
> + unsigned int fallback_npwms;
> bool pwm45_fixup;
> bool has_clks;
> };
> @@ -226,10 +226,10 @@ static const struct pwm_ops mtk_pwm_ops = {
>
> static int mtk_pwm_probe(struct platform_device *pdev)
> {
> - const struct mtk_pwm_platform_data *data;
> + struct device_node *np = pdev->dev.of_node;
> struct mtk_pwm_chip *pc;
> struct resource *res;
> - unsigned int i;
> + unsigned int i, npwms;
> int ret;
>
> pc = devm_kzalloc(>dev, sizeof(*pc), GFP_KERNEL);
> @@ -246,7 +246,19 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> if (IS_ERR(pc->regs))
> return PTR_ERR(pc->regs);
>
> - for (i = 0; i < data->num_pwms + 2 && pc->soc->has_clks; i++) {
> + ret = of_property_read_u32(np, "num-pwms", );
> + if (ret < 0) {
> + /* It's deprecated, we should specify num_pwms via DT now. */
> + if (pc->soc->fallback_npwms) {
> + npwms = pc->soc->fallback_npwms;
> + dev_warn(>dev, "DT is outdated, please update
> it\n");
> + } else {
> + dev_err(>dev, "failed to get number of PWMs\n");
> + return ret;
> + }
> + }
I'd suggest to add here:
if (npwms > ARRAY_SIZE(mtk_pwm_clk_name) + 2)
npwms = ARRAY_SIZE(mtk_pwm_clk_name) + 2;
to ensure to not use mtk_pwm_clk_name[10].
Best regards
Uwe
> +
> + for (i = 0; i < npwms + 2 && pc->soc->has_clks; i++) {
> pc->clks[i] = devm_clk_get(>dev, mtk_pwm_clk_name[i]);
> if (IS_ERR(pc->clks[i])) {
> dev_err(>dev, "clock: %s fail: %ld\n",
> @@ -260,7 +272,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> pc->chip.dev = >dev;
> pc->chip.ops = _pwm_ops;
> pc->chip.base = -1;
> - pc->chip.npwm = data->num_pwms;
> + pc->chip.npwm = npwms;
>
> ret = pwmchip_add(>chip);
> if (ret < 0) {
> @@ -279,25 +291,25 @@ static int mtk_pwm_remove(struct platform_device *pdev)
> }
>
> static const struct mtk_pwm_platform_data mt2712_pwm_data = {
> - .num_pwms = 8,
> + .fallback_npwms = 8,
> .pwm45_fixup = false,
> .has_clks = true,
> };
>
> static const struct mtk_pwm_platform_data mt7622_pwm_data = {
> - .num_pwms = 6,
> + .fallback_npwms = 6,
> .pwm45_fixup = false,
> .has_clks = true,
> };
>
> static const struct mtk_pwm_platform_data mt7623_pwm_data = {
> - .num_pwms = 5,
> + .fallback_npwms = 5,
> .pwm45_fixup = true,
> .has_clks = true,
> };
>
> static const struct mtk_pwm_platform_data mt7628_pwm_data = {
> - .num_pwms = 4,
> + .fallback_npwms = 4,
> .pwm45_fixup = true,
> .has_clks = false,
> };
> --
> 2.17.1
>
>
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH] Add support for Macronix NAND randomizer
Macronix NANDs support randomizer operation for user data scrambled,
which can be enabled with a SET_FEATURE.
User data written to the NAND device without randomizer is still readable
after randomizer function enabled.
The penalty of randomizer are NOP = 1 instead of NOP = 4 and more time period
is needed in program operation and entering deep power-down mode.
i.e., tPROG 300us to 340us(randomizer enabled)
If subpage write not available with hardware ECC, for example,
NAND chip options NAND_NO_SUBPAGE_WRITE be set in driver and
randomizer function is recommended for high-reliability.
Driver checks byte 167 of Vendor Blocks in ONFI parameter page table
to see if this high-reliability function is supported.
Signed-off-by: Mason Yang
---
drivers/mtd/nand/raw/nand_macronix.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_macronix.c
b/drivers/mtd/nand/raw/nand_macronix.c
index 58511ae..b8b5bcb 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -11,6 +11,13 @@
#define MACRONIX_READ_RETRY_BIT BIT(0)
#define MACRONIX_NUM_READ_RETRY_MODES 6
+#define MACRONIX_RANDOMIZER_BIT BIT(1)
+#define ONFI_FEATURE_ADDR_MXIC_RANDOMIZER 0xB0
+#define MACRONIX_RANDOMIZER_ENPGM BIT(0)
+#define MACRONIX_RANDOMIZER_RANDEN BIT(1)
+#define MACRONIX_RANDOMIZER_RANDOPT BIT(2)
+#define MACRONIX_RANDOMIZER_MODE_EXIT 0
+
struct nand_onfi_vendor_macronix {
u8 reserved;
u8 reliability_func;
@@ -29,6 +36,42 @@ static int macronix_nand_setup_read_retry(struct nand_chip
*chip, int mode)
return nand_set_features(chip, ONFI_FEATURE_ADDR_READ_RETRY, feature);
}
+static void macronix_nand_randomizer_check_enable(struct nand_chip *chip)
+{
+ u8 feature[ONFI_SUBFEATURE_PARAM_LEN];
+ int ret;
+
+ ret = nand_get_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+ feature);
+ if (feature[0]) {
+ pr_info("Macronix NAND randomizer enabled:0x%x\n", feature[0]);
+ return;
+ }
+
+ feature[0] = MACRONIX_RANDOMIZER_ENPGM | MACRONIX_RANDOMIZER_RANDEN |
+MACRONIX_RANDOMIZER_RANDOPT;
+ ret = nand_set_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+ feature);
+ if (ret)
+ goto err;
+
+ feature[0] = 0x0;
+ ret = nand_prog_page_op(chip, 0, 0, feature, 1);
+ if (ret)
+ goto err;
+
+ feature[0] = MACRONIX_RANDOMIZER_MODE_EXIT;
+ ret = nand_set_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+ feature);
+ if (ret)
+ goto err;
+
+ pr_info("Macronix NAND randomizer enable ok\n");
+ return;
+err:
+ pr_err("Macronix NAND randomizer enable failed\n");
+}
+
static void macronix_nand_onfi_init(struct nand_chip *chip)
{
struct nand_parameters *p = >parameters;
@@ -38,6 +81,17 @@ static void macronix_nand_onfi_init(struct nand_chip *chip)
return;
mxic = (struct nand_onfi_vendor_macronix *)p->onfi->vendor;
+ if (chip->options & NAND_NO_SUBPAGE_WRITE &&
+ mxic->reliability_func & MACRONIX_RANDOMIZER_BIT) {
+ if (p->supports_set_get_features) {
+ bitmap_set(p->set_feature_list,
+ ONFI_FEATURE_ADDR_MXIC_RANDOMIZER, 1);
+ bitmap_set(p->get_feature_list,
+ ONFI_FEATURE_ADDR_MXIC_RANDOMIZER, 1);
+ macronix_nand_randomizer_check_enable(chip);
+ }
+ }
+
if ((mxic->reliability_func & MACRONIX_READ_RETRY_BIT) == 0)
return;
--
1.9.1
[PATCH] ecryptfs: fix a memory leak bug
In parse_tag_1_packet(), if tag 1 packet contains a key larger than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES, no cleanup is executed, leading to a memory leak on the allocated 'auth_tok_list_item'. To fix this issue, go to the label 'out_free' to perform the cleanup work. Signed-off-by: Wenwen Wang --- fs/ecryptfs/keystore.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c index 216fbe6..4dc0963 100644 --- a/fs/ecryptfs/keystore.c +++ b/fs/ecryptfs/keystore.c @@ -1304,7 +1304,7 @@ parse_tag_1_packet(struct ecryptfs_crypt_stat *crypt_stat, printk(KERN_WARNING "Tag 1 packet contains key larger " "than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES\n"); rc = -EINVAL; - goto out; + goto out_free; } memcpy((*new_auth_tok)->session_key.encrypted_key, [(*packet_size)], (body_size - (ECRYPTFS_SIG_SIZE + 2))); -- 2.7.4
[PATCH] iio: cros_ec: set calibscale for 3d MEMS to unit vector
By default, set the calibscale vector to unit vector.
It prevents sending 0 as calibscale when not initialized.
Signed-off-by: Gwendal Grignou
---
drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index fd833295bb173..d44ae126f4578 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -90,7 +90,7 @@ int cros_ec_sensors_core_init(struct platform_device *pdev,
struct cros_ec_dev *ec = dev_get_drvdata(pdev->dev.parent);
struct cros_ec_sensor_platform *sensor_platform = dev_get_platdata(dev);
u32 ver_mask;
- int ret;
+ int ret, i;
platform_set_drvdata(pdev, indio_dev);
@@ -136,6 +136,9 @@ int cros_ec_sensors_core_init(struct platform_device *pdev,
/* Set sign vector, only used for backward compatibility. */
memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS);
+ for (i = CROS_EC_SENSOR_X; i < CROS_EC_SENSOR_MAX_AXIS; i++)
+ state->calib[i].scale = MOTION_SENSE_DEFAULT_SCALE;
+
/* 0 is a correct value used to stop the device */
state->frequencies[0] = 0;
if (state->msg->version < 3) {
--
2.23.0.rc1.153.gdeed80330f-goog
Re: [PATCH v1 05/10] powerpc/mm: Do early ioremaps from top to bottom on PPC64 too.
Le 20/08/2019 à 02:20, Michael Ellerman a écrit : Nicholas Piggin writes: Christophe Leroy's on August 14, 2019 6:11 am: Until vmalloc system is up and running, ioremap basically allocates addresses at the border of the IOREMAP area. On PPC32, addresses are allocated down from the top of the area while on PPC64, addresses are allocated up from the base of the area. This series looks pretty good to me, but I'm not sure about this patch. It seems like quite a small divergence in terms of code, and it looks like the final result still has some ifdefs in these functions. Maybe you could just keep existing behaviour for this cleanup series so it does not risk triggering some obscure regression? Yeah that is also my feeling. Changing it *should* work, and I haven't found anything that breaks yet, but it's one of those things that's bound to break something for some obscure reason. Christophe do you think you can rework it to retain the different allocation directions at least for now? Yes I have started addressing the comments I received, and I think for now I'll keep all the machinery aside from the merge. Not sure yet if I'll leave it in pgtables_32/64.c or if I'll add ioremap_32/64.c Christophe
[PATCH v3] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan
---
v2:
Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
rtw_pci_interrupt_handler. Because the interrupts are already disabled
in the hardware interrupt handler.
v3:
Extend the spin lock protecting area for the TX path in
rtw_pci_interrupt_threadfn by Realtek's suggestion
drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..a8c17a01f318 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
spin_lock(>irq_lock);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+* thread function
+*/
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock(>irq_lock);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
+ spin_lock_irqsave(>irq_lock, flags);
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +908,10 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void
*dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(>irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(>irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1171,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, _pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1213,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
Re: [PATCH v2 4/4] clk: qcom: clk-rpmh: Add support for SM8150
On Mon 19 Aug 00:39 PDT 2019, Vinod Koul wrote:
> Add support for rpmh clocks found in SM8150
>
> Signed-off-by: Vinod Koul
> ---
> drivers/clk/qcom/clk-rpmh.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c
> index 16d689e5bb3c..3b304a3fb5c9 100644
> --- a/drivers/clk/qcom/clk-rpmh.c
> +++ b/drivers/clk/qcom/clk-rpmh.c
> @@ -374,6 +374,32 @@ static const struct clk_rpmh_desc clk_rpmh_sdm845 = {
> .num_clks = ARRAY_SIZE(sdm845_rpmh_clocks),
> };
>
> +DEFINE_CLK_RPMH_ARC(sm8150, bi_tcxo, bi_tcxo_ao, "xo.lvl", 0x3, 2);
> +DEFINE_CLK_RPMH_VRM(sm8150, ln_bb_clk2, ln_bb_clk2_ao, "lnbclka2", 2);
> +DEFINE_CLK_RPMH_VRM(sm8150, ln_bb_clk3, ln_bb_clk3_ao, "lnbclka3", 2);
> +DEFINE_CLK_RPMH_VRM(sm8150, rf_clk1, rf_clk1_ao, "rfclka1", 1);
> +DEFINE_CLK_RPMH_VRM(sm8150, rf_clk2, rf_clk2_ao, "rfclka2", 1);
> +DEFINE_CLK_RPMH_VRM(sm8150, rf_clk3, rf_clk3_ao, "rfclka3", 1);
> +
> +static struct clk_hw *sm8150_rpmh_clocks[] = {
> + [RPMH_CXO_CLK] = _bi_tcxo.hw,
> + [RPMH_CXO_CLK_A]= _bi_tcxo_ao.hw,
> + [RPMH_LN_BB_CLK2] = _ln_bb_clk2.hw,
> + [RPMH_LN_BB_CLK2_A] = _ln_bb_clk2_ao.hw,
> + [RPMH_LN_BB_CLK3] = _ln_bb_clk3.hw,
> + [RPMH_LN_BB_CLK3_A] = _ln_bb_clk3_ao.hw,
> + [RPMH_RF_CLK1] = _rf_clk1.hw,
> + [RPMH_RF_CLK1_A]= _rf_clk1_ao.hw,
> + [RPMH_RF_CLK2] = _rf_clk2.hw,
> + [RPMH_RF_CLK2_A]= _rf_clk2_ao.hw,
> + [RPMH_RF_CLK3] = _rf_clk3.hw,
> + [RPMH_RF_CLK3_A]= _rf_clk3_ao.hw,
> +};
> +
> +static const struct clk_rpmh_desc clk_rpmh_sm8150 = {
> + .clks = sm8150_rpmh_clocks,
> + .num_clks = ARRAY_SIZE(sm8150_rpmh_clocks),
> +};
Maybe an empty line here?
> static struct clk_hw *of_clk_rpmh_hw_get(struct of_phandle_args *clkspec,
>void *data)
> {
> @@ -453,6 +479,7 @@ static int clk_rpmh_probe(struct platform_device *pdev)
>
> static const struct of_device_id clk_rpmh_match_table[] = {
> { .compatible = "qcom,sdm845-rpmh-clk", .data = _rpmh_sdm845},
> + { .compatible = "qcom,sm8150-rpmh-clk", .data = _rpmh_sm8150},
> { }
> };
> MODULE_DEVICE_TABLE(of, clk_rpmh_match_table);
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> --
> 2.20.1
>
Re: [PATCH v2 3/4] dt-bindings: clock: Document SM8150 rpmh-clock compatible
On Mon 19 Aug 00:39 PDT 2019, Vinod Koul wrote: > Document the SM8150 rpmh-clock compatible for rpmh clock controller > found on SM8150 platforms. > > Signed-off-by: Vinod Koul Reviewed-by: Bjorn Andersson > --- > Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt > b/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt > index 8b97968f9c88..365bbde599b1 100644 > --- a/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt > +++ b/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt > @@ -6,7 +6,9 @@ some Qualcomm Technologies Inc. SoCs. It accepts clock > requests from > other hardware subsystems via RSC to control clocks. > > Required properties : > -- compatible : shall contain "qcom,sdm845-rpmh-clk" > +- compatible : must be one of: > +"qcom,sdm845-rpmh-clk" > +"qcom,sm8150-rpmh-clk" > > - #clock-cells : must contain 1 > - clocks: a list of phandles and clock-specifier pairs, > -- > 2.20.1 >
Re: [PATCH v2 2/4] clk: qcom: clk-rpmh: Convert to parent data scheme
On Mon 19 Aug 00:39 PDT 2019, Vinod Koul wrote:
> Convert the rpmh clock driver to use the new parent data scheme by
> specifying the parent data for board clock.
>
> Signed-off-by: Vinod Koul
> ---
> drivers/clk/qcom/clk-rpmh.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c
> index c3fd632af119..16d689e5bb3c 100644
> --- a/drivers/clk/qcom/clk-rpmh.c
> +++ b/drivers/clk/qcom/clk-rpmh.c
> @@ -95,7 +95,10 @@ static DEFINE_MUTEX(rpmh_clk_lock);
> .hw.init = &(struct clk_init_data){ \
> .ops = _rpmh_ops, \
> .name = #_name, \
> - .parent_names = (const char *[]){ "xo_board" }, \
> + .parent_data = &(const struct clk_parent_data){ \
> + .fw_name = "xo",\
> + .name = "xo", \
Shouldn't .name be "xo_board" to retain backwards compatibility?
Regards,
Bjorn
> + }, \
> .num_parents = 1, \
> }, \
> }; \
> @@ -110,7 +113,10 @@ static DEFINE_MUTEX(rpmh_clk_lock);
> .hw.init = &(struct clk_init_data){ \
> .ops = _rpmh_ops, \
> .name = #_name_active, \
> - .parent_names = (const char *[]){ "xo_board" }, \
> + .parent_data = &(const struct clk_parent_data){ \
> + .fw_name = "xo",\
> + .name = "xo", \
> + }, \
> .num_parents = 1, \
> }, \
> }
> --
> 2.20.1
>
Re: [PATCH v2 1/4] dt-bindings: clock: Document the parent clocks
On Mon 19 Aug 00:39 PDT 2019, Vinod Koul wrote: > With clock parent data scheme we must specify the parent clocks for the > rpmhcc nodes. So describe the parent clock for rpmhcc in the bindings. > Reviewed-by: Bjorn Andersson > Signed-off-by: Vinod Koul > --- > Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt > b/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt > index 3c007653da31..8b97968f9c88 100644 > --- a/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt > +++ b/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt > @@ -9,6 +9,9 @@ Required properties : > - compatible : shall contain "qcom,sdm845-rpmh-clk" > > - #clock-cells : must contain 1 > +- clocks: a list of phandles and clock-specifier pairs, > + one for each entry in clock-names. > +- clock-names: Parent board clock: "xo". > > Example : > > -- > 2.20.1 >
[PATCH] ubifs: fix a memory leak bug
In ubifs_mount(), 'c' is allocated through kzalloc() in alloc_ubifs_info().
However, it is not deallocated in the following execution if
ubifs_fill_super() fails, leading to a memory leak bug. To fix this issue,
free 'c' before going to the 'out_deact' label.
Signed-off-by: Wenwen Wang
---
fs/ubifs/super.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 2c0803b..46e30e2 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -2252,8 +2252,10 @@ static struct dentry *ubifs_mount(struct
file_system_type *fs_type, int flags,
}
} else {
err = ubifs_fill_super(sb, data, flags & SB_SILENT ? 1 : 0);
- if (err)
+ if (err) {
+ kfree(c);
goto out_deact;
+ }
/* We do not support atime */
sb->s_flags |= SB_ACTIVE;
if (IS_ENABLED(CONFIG_UBIFS_ATIME_SUPPORT))
--
2.7.4
[PATCH] PCI: Add PCIE ACS quirk for IPROC PAXB
From: Abhinav Ratna
IPROC PAXB RC doesn't support ACS capabilities and control registers.
Add quirk to have separate IOMMU groups for all EPs and functions connected
to root port, by masking RR/CR/SV/UF bits.
Signed-off-by: Abhinav Ratna
Signed-off-by: Srinath Mannam
---
drivers/pci/quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 0f16acc..f9584c0 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4466,6 +4466,21 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev
*dev, u16 acs_flags)
return acs_flags ? 0 : 1;
}
+static int pcie_quirk_brcm_bridge_acs(struct pci_dev *dev, u16 acs_flags)
+{
+ /*
+* IPROC PAXB RC doesn't support ACS capabilities and control registers.
+* Add quirk to to have separate IOMMU groups for all EPs and functions
+* connected to root port, by masking RR/CR/SV/UF bits.
+*/
+
+ u16 flags = (PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_SV);
+ int ret = acs_flags & ~flags ? 0 : 1;
+
+ return ret;
+}
+
+
static const struct pci_dev_acs_enabled {
u16 vendor;
u16 device;
@@ -4559,6 +4574,7 @@ static const struct pci_dev_acs_enabled {
{ PCI_VENDOR_ID_AMPERE, 0xE00A, pci_quirk_xgene_acs },
{ PCI_VENDOR_ID_AMPERE, 0xE00B, pci_quirk_xgene_acs },
{ PCI_VENDOR_ID_AMPERE, 0xE00C, pci_quirk_xgene_acs },
+ { PCI_VENDOR_ID_BROADCOM, 0xD714, pcie_quirk_brcm_bridge_acs },
{ 0 }
};
--
2.7.4
Re: [PATCH 1/4] resource: add a not device managed request_free_mem_region variant
On Mon, Aug 19, 2019 at 7:26 PM Christoph Hellwig wrote: > > On Mon, Aug 19, 2019 at 06:28:30PM -0700, Dan Williams wrote: > > > > Previously we would loudly crash if someone passed NULL to > > devm_request_free_mem_region(), but now it will silently work and the > > result will leak. Perhaps this wants a: > > We'd still instantly crash due to the dev_name dereference, right? Whoops, yes.
Re: [RFC PATCH] powerpc: Convert ____flush_dcache_icache_phys() to C
On Fri, 2019-08-16 at 15:52 +, Christophe Leroy wrote:
> Resulting code (8xx with 16 bytes per cacheline and 16k pages)
>
> 016c <__flush_dcache_icache_phys>:
> 16c: 54 63 00 22 rlwinm r3,r3,0,0,17
> 170: 7d 20 00 a6 mfmsr r9
> 174: 39 40 04 00 li r10,1024
> 178: 55 28 07 34 rlwinm r8,r9,0,28,26
> 17c: 7c 67 1b 78 mr r7,r3
> 180: 7d 49 03 a6 mtctr r10
> 184: 7d 00 01 24 mtmsr r8
> 188: 4c 00 01 2c isync
> 18c: 7c 00 18 6c dcbst 0,r3
> 190: 38 63 00 10 addir3,r3,16
> 194: 42 00 ff f8 bdnz18c <__flush_dcache_icache_phys+0x20>
> 198: 7c 00 04 ac hwsync
> 19c: 7d 49 03 a6 mtctr r10
> 1a0: 7c 00 3f ac icbi0,r7
> 1a4: 38 e7 00 10 addir7,r7,16
> 1a8: 42 00 ff f8 bdnz1a0 <__flush_dcache_icache_phys+0x34>
> 1ac: 7c 00 04 ac hwsync
> 1b0: 7d 20 01 24 mtmsr r9
> 1b4: 4c 00 01 2c isync
> 1b8: 4e 80 00 20 blr
>
> Signed-off-by: Christophe Leroy
> ---
> This patch is on top of Alastair's series "powerpc: convert cache
> asm to C"
> Patch 3 of that series should touch __flush_dcache_icache_phys and
> this
> patch could come just after patch 3.
>
> arch/powerpc/include/asm/cacheflush.h | 8 +
> arch/powerpc/mm/mem.c | 55
> ---
> 2 files changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cacheflush.h
> b/arch/powerpc/include/asm/cacheflush.h
> index 1826bf2cc137..bf4f2dc4eb76 100644
> --- a/arch/powerpc/include/asm/cacheflush.h
> +++ b/arch/powerpc/include/asm/cacheflush.h
> @@ -47,6 +47,14 @@ void flush_icache_user_range(struct vm_area_struct
> *vma,
> struct page *page, unsigned long
> addr,
> int len);
> void flush_dcache_icache_page(struct page *page);
> +#if defined(CONFIG_PPC32) && !defined(CONFIG_BOOKE)
> +void __flush_dcache_icache_phys(unsigned long physaddr);
> +#else
> +static inline void __flush_dcache_icache_phys(unsigned long
> physaddr)
> +{
> + BUG();
> +}
> +#endif
>
> /**
> * flush_dcache_range(): Write any modified data cache blocks out to
> memory and invalidate them.
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 43be99de7c9a..43009f9227c4 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -402,6 +402,50 @@ void flush_dcache_page(struct page *page)
> }
> EXPORT_SYMBOL(flush_dcache_page);
>
> +#if defined(CONFIG_PPC32) && !defined(CONFIG_BOOKE)
> +void __flush_dcache_icache_phys(unsigned long physaddr)
> +{
> + unsigned long bytes = l1_dcache_bytes();
> + unsigned long nb = PAGE_SIZE / bytes;
> + unsigned long addr = physaddr & PAGE_MASK;
> + unsigned long msr, msr0;
> + unsigned long loop1 = addr, loop2 = addr;
> +
> + if (cpu_has_feature(CPU_FTR_COHERENT_ICACHE)) {
> + /* For a snooping icache, we still need a dummy icbi to
> purge all the
> + * prefetched instructions from the ifetch buffers. We
> also need a sync
> + * before the icbi to order the the actual stores to
> memory that might
> + * have modified instructions with the icbi.
> + */
> + mb(); /* sync */
> + icbi((void *)addr);
> + mb(); /* sync */
> + isync();
> + return;
> + }
> + msr0 = mfmsr();
> + msr = msr0 & ~MSR_DR;
> + asm volatile(
> + " mtctr %2;"
> + " mtmsr %3;"
> + " isync;"
> + "0: dcbst 0, %0;"
> + " addi%0, %0, %4;"
> + " bdnz0b;"
> + " sync;"
> + " mtctr %2;"
> + "1: icbi0, %1;"
> + " addi%1, %1, %4;"
> + " bdnz1b;"
> + " sync;"
> + " mtmsr %5;"
> + " isync;"
> + : "+r" (loop1), "+r" (loop2)
> + : "r" (nb), "r" (msr), "i" (bytes), "r" (msr0)
> + : "ctr", "memory");
> +}
> +#endif
> +
> void flush_dcache_icache_page(struct page *page)
> {
> #ifdef CONFIG_HUGETLB_PAGE
> @@ -419,16 +463,7 @@ void flush_dcache_icache_page(struct page *page)
> __flush_dcache_icache(start);
> kunmap_atomic(start);
> } else {
> - unsigned long msr = mfmsr();
> -
> - /* Clear the DR bit so that we operate on physical
> - * rather than virtual addresses
> - */
> - mtmsr(msr & ~(MSR_DR));
> -
> - __flush_dcache_icache((void *)physaddr);
> -
> - mtmsr(msr);
> + __flush_dcache_icache_phys(page_to_pfn(page) <<
> PAGE_SHIFT);
> }
> #endif
> }
Thanks Christophe,
I'm trying a somewhat different approach that requires less knowledge
of assembler. Handling of CPU_FTR_COHERENT_ICACHE is outside this
function. The code below is not a patch as my tree is a bit messy,
sorry:
/**
* flush_dcache_icache_phys() -
Re: [PATCH v7 1/7] driver core: Add support for linking devices during device addition
On 8/19/19 5:00 PM, Saravana Kannan wrote:
> On Sun, Aug 18, 2019 at 8:38 PM Frank Rowand wrote:
>>
>> On 8/15/19 6:50 PM, Saravana Kannan wrote:
>>> On Wed, Aug 7, 2019 at 7:04 PM Frank Rowand wrote:
> Date: Tue, 23 Jul 2019 17:10:54 -0700
> Subject: [PATCH v7 1/7] driver core: Add support for linking devices
> during
> device addition
> From: Saravana Kannan
>
> When devices are added, the bus might want to create device links to track
> functional dependencies between supplier and consumer devices. This
> tracking of supplier-consumer relationship allows optimizing device probe
> order and tracking whether all consumers of a supplier are active. The
> add_links bus callback is added to support this.
Change above to:
When devices are added, the bus may create device links to track which
suppliers a consumer device depends upon. This
tracking of supplier-consumer relationship may be used to defer probing
the driver of a consumer device before the driver(s) for its supplier
device(s)
are probed. It may also be used by a supplier driver to determine if
all of its consumers have been successfully probed.
The add_links bus callback is added to create the supplier device links
>
> However, when consumer devices are added, they might not have a supplier
> device to link to despite needing mandatory resources/functionality from
> one or more suppliers. A waiting_for_suppliers list is created to track
> such consumers and retry linking them when new devices get added.
Change above to:
If a supplier device has not yet been created when the consumer device
attempts
to link it, the consumer device is added to the wait_for_suppliers list.
When supplier devices are created, the supplier device link will be added
to
the relevant consumer devices on the wait_for_suppliers list.
>>>
>>> I'll take these commit text suggestions if we decide to revert the
>>> entire series at the end of this review.
>>>
>
> Signed-off-by: Saravana Kannan
> ---
> drivers/base/core.c| 83 ++
> include/linux/device.h | 14 +++
> 2 files changed, 97 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index da84a73f2ba6..1b4eb221968f 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -44,6 +44,8 @@ early_param("sysfs.deprecated", sysfs_deprecated_setup);
> #endif
>
> /* Device links support. */
> +static LIST_HEAD(wait_for_suppliers);
> +static DEFINE_MUTEX(wfs_lock);
>
> #ifdef CONFIG_SRCU
> static DEFINE_MUTEX(device_links_lock);
> @@ -401,6 +403,51 @@ struct device_link *device_link_add(struct device
> *consumer,
> }
> EXPORT_SYMBOL_GPL(device_link_add);
>
> +/**
> + * device_link_wait_for_supplier - Mark device as waiting for supplier
* device_link_wait_for_supplier - Add device to wait_for_suppliers list
>>>
>>
>> As a meta-comment, I found this series very hard to understand in the context
>> of reading the new code for the first time. When I read the code again in
>> six months or a year or two years it will not be in near term memory and it
>> will be as if I am reading it for the first time. A lot of my suggestions
>> for changes of names are in that context -- the current names may be fine
>> when one has recently read the code, but not so much when trying to read
>> the whole thing again with a blank mind.
>
> Thanks for the context.
>
>> The code also inherits a good deal of complexity because it does not stand
>> alone in a nice discrete chunk, but instead delicately weaves into a more
>> complex body of code.
>
> I'll take this as a compliment :)
Please do!
>
>> When I was trying to understand the code, I wrote a lot of additional
>> comments within my reply email to provide myself context, information
>> about various things, and questions that I needed to answer (or if I
>> could not answer to then ask you). Then I ended up being able to remove
>> many of those notes before sending the reply.
>>
>>
>>> I intentionally chose "Mark device..." because that's a better
>>> description of the semantics of the function instead of trying to
>>> describe the implementation. Whether I'm using a linked list or some
>>> other data structure should not be the one line documentation of a
>>> function. Unless the function is explicitly about operating on that
>>> specific data structure.
>>
>> I agree with the intent of trying to describe the semantics of a function,
>> especially at the API level where other systems (or drivers) would be using
>> the function. But for this case the function is at the implementation level
>> and describing explicitly what it is doing makes this much more readable for
>> me.
>
> Are you
Re: linux-next: Tree for Aug 19 (drivers/net/netdevsim/dev.o)
On 8/19/19 2:18 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20190816: > on x86_64: # CONFIG_INET is not set ld: drivers/net/netdevsim/dev.o: in function `nsim_dev_trap_report_work': dev.c:(.text+0x52f): undefined reference to `ip_send_check' Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 5.3.0-rc5 Kernel Configuration # # # Compiler: gcc (SUSE Linux) 7.4.0 # CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=70400 CONFIG_CLANG_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_COMPILE_TEST=y CONFIG_HEADER_TEST=y # CONFIG_KERNEL_HEADER_TEST is not set CONFIG_LOCALVERSION="" CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_BZIP2=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SYSVIPC is not set CONFIG_POSIX_MQUEUE=y CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_SIM=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set # end of IRQ subsystem CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # end of Timers subsystem CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set CONFIG_IRQ_TIME_ACCOUNTING=y CONFIG_HAVE_SCHED_AVG_IRQ=y CONFIG_PSI=y CONFIG_PSI_DEFAULT_DISABLED=y # end of CPU/Task time and stats accounting # CONFIG_CPU_ISOLATION is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y # end of RCU Subsystem CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_IKHEADERS=y CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # CONFIG_UCLAMP_TASK=y CONFIG_UCLAMP_BUCKETS_COUNT=5 # end of Scheduler features CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_KMEM=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set CONFIG_RT_GROUP_SCHED=y # CONFIG_CGROUP_PIDS is not set CONFIG_CGROUP_RDMA=y # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_HUGETLB=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_BPF=y # CONFIG_CGROUP_DEBUG is not set CONFIG_SOCK_CGROUP_DATA=y # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y # CONFIG_RD_LZ4 is not set # CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y # CONFIG_MULTIUSER is not set # CONFIG_SGETMASK_SYSCALL is not set # CONFIG_SYSFS_SYSCALL is not set CONFIG_FHANDLE=y CONFIG_POSIX_TIMERS=y # CONFIG_PRINTK is not set CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set # CONFIG_SIGNALFD is not set CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_IO_URING is not set # CONFIG_ADVISE_SYSCALLS is not set # CONFIG_MEMBARRIER is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y CONFIG_KALLSYMS_BASE_RELATIVE=y CONFIG_BPF_SYSCALL=y CONFIG_USERFAULTFD=y CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y # CONFIG_RSEQ is not
[PATCH] rpmsg: glink-smem: Name the edge based on parent remoteproc
Naming the glink edge device on the parent of_node short name causes
collisions when multiple remoteproc instances with only different unit
address are described on the platform_bus in DeviceTree.
Base the edge's name on the parent remoteproc's name instead, to ensure
that it's unique.
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/qcom_glink_smem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rpmsg/qcom_glink_smem.c b/drivers/rpmsg/qcom_glink_smem.c
index 64a5ce324c7f..4238383d8685 100644
--- a/drivers/rpmsg/qcom_glink_smem.c
+++ b/drivers/rpmsg/qcom_glink_smem.c
@@ -201,7 +201,7 @@ struct qcom_glink *qcom_glink_smem_register(struct device
*parent,
dev->parent = parent;
dev->of_node = node;
dev->release = qcom_glink_smem_release;
- dev_set_name(dev, "%pOFn:%pOFn", node->parent, node);
+ dev_set_name(dev, "%s:%pOFn", dev_name(parent->parent), node);
ret = device_register(dev);
if (ret) {
pr_err("failed to register glink edge\n");
--
2.18.0
Re: [PATCH v3 0/3] genirq/vfio: Introduce update_irq_devid and optimize VFIO irq ops
在 2019/8/20 上午4:51, Alex Williamson 写道: On Thu, 15 Aug 2019 21:02:58 +0800 Ben Luo wrote: Currently, VFIO takes a lot of free-then-request-irq actions whenever a VM (with device passthru via VFIO) sets irq affinity or mask/unmask irq. Those actions only change the cookie data of irqaction or even change nothing. The free-then-request-irq not only adds more latency, but also increases the risk of losing interrupt, which may lead to a VM hung forever in waiting for IO completion What guest environment is generating this? Typically I don't see that Windows or Linux guests bounce the interrupt configuration much. Thanks, Alex By tracing centos5u8 on host, I found it keep masking and unmasking interrupt like this: [1566032533709879] index:28 irte_hi:00010004a601 irte_lo:adb54bc000b98001 [1566032533711242] index:28 irte_hi: irte_lo: [1566032533711258] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533711269] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533711291] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533711321] index:28 irte_hi: irte_lo: [1566032533711340] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533711361] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533711376] index:28 irte_hi:00010004a601 irte_lo:adb54bc000b98001 [1566032533713368] index:28 irte_hi: irte_lo: [1566032533713385] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533713396] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533713416] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533713447] index:28 irte_hi: irte_lo: [1566032533713464] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533713485] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533713499] index:28 irte_hi:00010004a601 irte_lo:adb54bc000b98001 [1566032533718855] index:28 irte_hi: irte_lo: [1566032533718871] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533718882] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533718902] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533718932] index:28 irte_hi: irte_lo: [1566032533718949] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533718969] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533718984] index:28 irte_hi:00010004a601 irte_lo:adb54bc000b98001 [1566032533719873] index:28 irte_hi: irte_lo: [1566032533719889] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533719900] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533719921] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533719954] index:28 irte_hi: irte_lo: [1566032533719971] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533719992] index:28 irte_hi:0004a601 irte_lo:3fff00ac002d [1566032533720007] index:28 irte_hi:00010004a601 irte_lo:adb54bc000b98001 "[1566032533720007]" is timestamp in μs, so centos5u8 tiggers 30+ irte modification within 10ms Thanks, Ben This patchset solved the issue by: Patch 2 introduces update_irq_devid to only update dev_id of irqaction Patch 3 make use of update_irq_devid and optimize irq operations in VFIO changes from v2: - reformat to avoid quoted string split across lines and etc. changes from v1: - add Patch 1 to enhance error recovery etc. in free irq per tglx's comments - enhance error recovery code and debugging info in update_irq_devid - use __must_check in external referencing of update_irq_devid - use EXPORT_SYMBOL_GPL for update_irq_devid - reformat code of patch 3 for better readability Ben Luo (3): genirq: enhance error recovery code in free irq genirq: introduce update_irq_devid() vfio_pci: make use of update_irq_devid and optimize irq ops drivers/vfio/pci/vfio_pci_intrs.c | 101 +- include/linux/interrupt.h | 3 ++ kernel/irq/manage.c | 110 +- 3 files changed, 164 insertions(+), 50 deletions(-)
Re: [PATCH 10/22] arm64: dts: qcom: pm8150b: Add pon and adc nodes
On 19-08-19, 10:56, Stephen Boyd wrote:
> Quoting Vinod Koul (2019-08-19 10:43:31)
> > On 14-08-19, 10:08, Stephen Boyd wrote:
> > >
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
> > > > b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
> > > > index c0a678b0f159..846197bd65cd 100644
> > > > --- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
> > > > @@ -2,6 +2,7 @@
> > > > // Copyright (c) 2017-2019, The Linux Foundation. All rights reserved.
> > > > // Copyright (c) 2019, Linaro Limited
> > > >
> > > > +#include
> > > > #include
> > > > #include
> > > >
> > > > @@ -11,6 +12,59 @@
> > > > reg = <0x2 SPMI_USID>;
> > > > #address-cells = <1>;
> > > > #size-cells = <0>;
> > > > +
> > > > + pon@800 {
> > >
> > > Maybe pon node name should be 'key' or 'power-on'?
> >
> > pon stands for power on device. See
> > Documentation/devicetree/bindings/power/reset/qcom,pon.txt
>
> Right. I was hoping for a more standard node name vs. an acronym that's
> SoC specific.
Sure that sounds better to me, I will make it "power-on"
--
~Vinod
Re: [v4, 7/8] cpufreq: mediatek: add opp notification for SVS support
On 13-08-19, 21:31, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng"
>
> cpufreq should listen opp notification and do proper actions
> when receiving disable and voltage adjustment events,
> which are triggered when SVS is enabled.
>
> Signed-off-by: Andrew-sh.Cheng
> ---
> drivers/cpufreq/mediatek-cpufreq.c | 78
> ++
> 1 file changed, 78 insertions(+)
>
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c
> b/drivers/cpufreq/mediatek-cpufreq.c
> index 4dce41b18369..9820c8003507 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -42,6 +42,10 @@ struct mtk_cpu_dvfs_info {
> struct list_head list_head;
> int intermediate_voltage;
> bool need_voltage_tracking;
> + struct mutex lock; /* avoid notify and policy race condition */
> + struct notifier_block opp_nb;
> + int opp_cpu;
> + unsigned long opp_freq;
> };
>
> static LIST_HEAD(dvfs_info_list);
> @@ -231,6 +235,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy
> *policy,
> vproc = dev_pm_opp_get_voltage(opp);
> dev_pm_opp_put(opp);
>
> + mutex_lock(>lock);
> /*
>* If the new voltage or the intermediate voltage is higher than the
>* current voltage, scale up voltage first.
> @@ -242,6 +247,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy
> *policy,
> pr_err("cpu%d: failed to scale up voltage!\n",
> policy->cpu);
> mtk_cpufreq_set_voltage(info, old_vproc);
> + mutex_unlock(>lock);
> return ret;
> }
> }
> @@ -253,6 +259,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy
> *policy,
> policy->cpu);
> mtk_cpufreq_set_voltage(info, old_vproc);
> WARN_ON(1);
> + mutex_unlock(>lock);
> return ret;
> }
>
> @@ -263,6 +270,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy
> *policy,
> policy->cpu);
> clk_set_parent(cpu_clk, armpll);
> mtk_cpufreq_set_voltage(info, old_vproc);
> + mutex_unlock(>lock);
> return ret;
> }
>
> @@ -273,6 +281,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy
> *policy,
> policy->cpu);
> mtk_cpufreq_set_voltage(info, inter_vproc);
> WARN_ON(1);
> + mutex_unlock(>lock);
> return ret;
> }
>
> @@ -288,15 +297,74 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy
> *policy,
> clk_set_parent(cpu_clk, info->inter_clk);
> clk_set_rate(armpll, old_freq_hz);
> clk_set_parent(cpu_clk, armpll);
> + mutex_unlock(>lock);
> return ret;
> }
> }
>
> + info->opp_freq = freq_hz;
> + mutex_unlock(>lock);
> +
> return 0;
> }
>
> #define DYNAMIC_POWER "dynamic-power-coefficient"
>
> +static int mtk_cpufreq_opp_notifier(struct notifier_block *nb,
> + unsigned long event, void *data)
> +{
> + struct dev_pm_opp *opp = data;
> + struct dev_pm_opp *opp_item;
> + struct mtk_cpu_dvfs_info *info =
> + container_of(nb, struct mtk_cpu_dvfs_info, opp_nb);
> + unsigned long freq, volt;
> + struct cpufreq_policy *policy;
> + int ret = 0;
> +
> + if (event == OPP_EVENT_ADJUST_VOLTAGE) {
> + freq = dev_pm_opp_get_freq(opp);
> +
> + mutex_lock(>lock);
> + if (info->opp_freq == freq) {
> + volt = dev_pm_opp_get_voltage(opp);
> + ret = mtk_cpufreq_set_voltage(info, volt);
> + if (ret)
> + dev_err(info->cpu_dev, "failed to scale
> voltage: %d\n",
> + ret);
> + }
> + mutex_unlock(>lock);
> + } else if (event == OPP_EVENT_DISABLE) {
Does this ever get called for your platform ? Why are you using opp disable ?
Maybe we can avoid it completely.
> + freq = info->opp_freq;
> + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev, );
> + if (!IS_ERR(opp_item))
> + dev_pm_opp_put(opp_item);
> + else
> + freq = 0;
> +
> + /* case of current opp is disabled */
> + if (freq == 0 || freq != info->opp_freq) {
> + // find an enable opp item
> + freq = 1;
> + opp_item = dev_pm_opp_find_freq_ceil(info->cpu_dev,
> + );
> + if (!IS_ERR(opp_item)) {
> + dev_pm_opp_put(opp_item);
> +
Re: [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-)
On Mon, Aug 19, 2019 at 08:09:33PM -0700, John Hubbard wrote: > On 8/19/19 6:20 PM, Dave Chinner wrote: > > On Mon, Aug 19, 2019 at 05:05:53PM -0700, John Hubbard wrote: > > > On 8/19/19 2:24 AM, Dave Chinner wrote: > > > > On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan Kara wrote: > > > > > On Sat 17-08-19 12:26:03, Dave Chinner wrote: > > > > > > On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira Weiny wrote: > > > > > > > On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote: > > > > > > > > On Wed 14-08-19 11:08:49, Ira Weiny wrote: > > > > > > > > > On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote: > > > ... > > > > > > Any thoughts about sockets? I'm looking at net/xdp/xdp_umem.c which pins > > > memory with FOLL_LONGTERM, and wondering how to make that work here. > > > > I'm not sure how this interacts with file mappings? I mean, this > > is just pinning anonymous pages for direct data placement into > > userspace, right? > > > > Are you asking "what if this pinned memory was a file mapping?", > > or something else? > > Yes, mainly that one. Especially since the FOLL_LONGTERM flag is > already there in xdp_umem_pin_pages(), unconditionally. So the > simple rules about struct *vaddr_pin usage (set it to NULL if FOLL_LONGTERM is > not set) are not going to work here. > > > > > > > These are close to files, in how they're handled, but just different > > > enough that it's not clear to me how to make work with this system. > > > > I'm guessing that if they are pinning a file backed mapping, they > > are trying to dma direct to the file (zero copy into page cache?) > > and so they'll need to either play by ODP rules or take layout > > leases, too > > > > OK. I was just wondering if there was some simple way to dig up a > struct file associated with a socket (I don't think so), but it sounds > like this is an exercise that's potentially different for each subsystem. AFAIA, there is no struct file here - the memory that has been pinned is just something mapped into the application's address space. It seems to me that the socket here is equivalent of the RDMA handle that that owns the hardware that pins the pages. Again, that RDMA handle is not aware of waht the mapping represents, hence need to hold a layout lease if it's a file mapping. SO from the filesystem persepctive, there's no difference between XDP or RDMA - if it's a FSDAX mapping then it is DMAing directly into the filesystem's backing store and that will require use of layout leases to perform safely. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
[PATCH] ubifs: fix a memory leak bug
In __ubifs_node_verify_hmac(), 'hmac' is allocated through kmalloc().
However, it is not deallocated in the following execution if
ubifs_node_calc_hmac() fails, leading to a memory leak bug. To fix this
issue, free 'hmac' before returning the error.
Signed-off-by: Wenwen Wang
---
fs/ubifs/auth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index d9af2de..8cdbd53 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -479,8 +479,10 @@ int __ubifs_node_verify_hmac(const struct ubifs_info *c,
const void *node,
return -ENOMEM;
err = ubifs_node_calc_hmac(c, node, len, ofs_hmac, hmac);
- if (err)
+ if (err) {
+ kfree(hmac);
return err;
+ }
err = crypto_memneq(hmac, node + ofs_hmac, hmac_len);
--
2.7.4
[PATCH v4 00/10] Allwinner sunxi message box support
This series adds support for the "hardware message box" in sun8i, sun9i, and sun50i SoCs, used for communication with the ARISC management processor (the platform's equivalent of the ARM SCP). The end goal is to use the arm_scpi driver as a client, communicating with firmware running on the AR100 CPU, or to use the mailbox to forward NMIs that the firmware picks up from R_INTC. Unfortunately, the ARM SCPI client no longer works with this driver since it now exposes all 8 hardware FIFOs individually. The SCPI client could be made to work (and I posted proof-of-concept code to that effect with v1 of this series), but that is a low priority, as Linux does not directly use SCPI with the current firmware version; all SCPI use goes through ATF via PSCI. As requested in the comments to v3 of this patchset, a demo client is provided in the final patch. This demo goes along with a toy firmware which shows that the driver does indeed work for two-way communication on all channels. To build the firmware component, run: git clone https://github.com/crust-firmware/meta meta git clone -b mailbox-demo https://github.com/crust-firmware/crust meta/crust cd meta make That will by default produce a U-Boot + ATF + SCP firmware image in [meta/]build/pinebook/u-boot-sunxi-with-spl.bin. See the top-level README.md for more information, such as cross-compiler setup. I've now used this driver with three separate clients over the past two years, and they all work. If there are no remaining concerns with the driver, I'd like it to get merged. Even without the driver, the clock patches (1-2) can go in at any time. Changes from v3: - Rebased on sunxi-next - Added Rob's Reviewed-by for patch 3 - Fixed a crash when receiving a message on a disabled channel - Cleaned up some comments/formatting in the driver - Fixed #mbox-cells in sunxi-h3-h5.dtsi (patch 7) - Removed the irqchip example (no longer relevant to the fw design) - Added a demo/example client that uses the driver and a toy firmware Changes from v2: - Merge patches 1-3 - Add a comment in the code explaining the CLK_IS_CRITICAL usage - Add a patch to mark the AR100 clocks as critical - Use YAML for the device tree binding - Include a not-for-merge example usage of the mailbox Changes from v1: - Marked message box clocks as critical instead of hacks in the driver - 8 unidirectional channels instead of 4 bidirectional pairs - Use per-SoC compatible strings and an A31 fallback compatible - Dropped the mailbox framework patch - Include DT patches for SoCs that document the message box Samuel Holland (10): clk: sunxi-ng: Mark msgbox clocks as critical clk: sunxi-ng: Mark AR100 clocks as critical dt-bindings: mailbox: Add a sunxi message box binding mailbox: sunxi-msgbox: Add a new mailbox driver ARM: dts: sunxi: a80: Add msgbox node ARM: dts: sunxi: a83t: Add msgbox node ARM: dts: sunxi: h3/h5: Add msgbox node arm64: dts: allwinner: a64: Add msgbox node arm64: dts: allwinner: h6: Add msgbox node [DO NOT MERGE] drivers: firmware: msgbox demo .../mailbox/allwinner,sunxi-msgbox.yaml | 79 + arch/arm/boot/dts/sun8i-a83t.dtsi | 10 + arch/arm/boot/dts/sun9i-a80.dtsi | 10 + arch/arm/boot/dts/sunxi-h3-h5.dtsi| 10 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 34 ++ arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 24 ++ arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 + drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 3 +- drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c| 2 +- drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 3 +- drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 3 +- drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 3 +- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 3 +- drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 3 +- drivers/clk/sunxi-ng/ccu-sun8i-r.c| 2 +- drivers/clk/sunxi-ng/ccu-sun9i-a80.c | 3 +- drivers/firmware/Kconfig | 6 + drivers/firmware/Makefile | 1 + drivers/firmware/sunxi_msgbox_demo.c | 307 + drivers/mailbox/Kconfig | 10 + drivers/mailbox/Makefile | 2 + drivers/mailbox/sunxi-msgbox.c| 323 ++ 22 files changed, 842 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml create mode 100644 drivers/firmware/sunxi_msgbox_demo.c create mode 100644 drivers/mailbox/sunxi-msgbox.c -- 2.21.0
[PATCH v4 02/10] clk: sunxi-ng: Mark AR100 clocks as critical
On sun8i, sun9i, and sun50i SoCs, system suspend/resume support requires
firmware running on the AR100 coprocessor (the "SCP"). Such firmware can
provide additional features, such as thermal monitoring and poweron/off
support for boards without a PMIC.
Since the AR100 may be running critical firmware, even if Linux does not
know about it or directly interact with it (all requests may go through
an intermediary interface such as PSCI), Linux must not turn off its
clock.
At this time, such power management firmware only exists for the A64 and
H5 SoCs. However, it makes sense to take care of all CCU drivers now
for consistency, and to ease the transition in the future once firmware
is ported to the other SoCs.
Leaving the clock running is safe even if no firmware is present, since
the AR100 stays in reset by default. In most cases, the AR100 clock is
kept enabled by Linux anyway, since it is the parent of all APB0 bus
peripherals. This change only prevents Linux from turning off the AR100
clock in the rare case that no peripherals are in use.
Signed-off-by: Samuel Holland
---
drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 2 +-
drivers/clk/sunxi-ng/ccu-sun8i-r.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
index 45a1ed3fe674..adf907020951 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
@@ -45,7 +45,7 @@ static struct ccu_div ar100_clk = {
.hw.init= CLK_HW_INIT_PARENTS("ar100",
ar100_r_apb2_parents,
_div_ops,
- 0),
+ CLK_IS_CRITICAL),
},
};
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r.c
b/drivers/clk/sunxi-ng/ccu-sun8i-r.c
index 4646fdc61053..feef4f750943 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r.c
@@ -45,7 +45,7 @@ static struct ccu_div ar100_clk = {
.hw.init= CLK_HW_INIT_PARENTS_DATA("ar100",
ar100_parents,
_div_ops,
- 0),
+ CLK_IS_CRITICAL),
},
};
--
2.21.0
[PATCH v4 06/10] ARM: dts: sunxi: a83t: Add msgbox node
The A83T SoC contains a message box that can be used to send messages
and interrupts back and forth between the ARM application CPUs and the
ARISC coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 523be6611c50..8871d1aaf7f5 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -583,6 +583,16 @@
reg = <0x1c14000 0x400>;
};
+ msgbox: mailbox@1c17000 {
+ compatible = "allwinner,sun8i-a83t-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x01c17000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
usb_otg: usb@1c19000 {
compatible = "allwinner,sun8i-a83t-musb",
"allwinner,sun8i-a33-musb";
--
2.21.0
[PATCH v4 09/10] arm64: dts: allwinner: h6: Add msgbox node
The H6 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 67b732e34091..2ff6a47e3cbf 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -215,6 +215,16 @@
#dma-cells = <1>;
};
+ msgbox: mailbox@3003000 {
+ compatible = "allwinner,sun50i-h6-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x03003000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
sid: efuse@3006000 {
compatible = "allwinner,sun50i-h6-sid";
reg = <0x03006000 0x400>;
--
2.21.0
[PATCH v4 05/10] ARM: dts: sunxi: a80: Add msgbox node
The A80 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sun9i-a80.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index c34d505c7efe..844a265dbd0e 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -318,6 +318,16 @@
};
};
+ msgbox: mailbox@803000 {
+ compatible = "allwinner,sun9i-a80-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x00803000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
gmac: ethernet@83 {
compatible = "allwinner,sun7i-a20-gmac";
reg = <0x0083 0x1054>;
--
2.21.0
[PATCH v4 01/10] clk: sunxi-ng: Mark msgbox clocks as critical
The msgbox clock is critical because the hardware it controls is shared between Linux and system firmware. The message box may be used by the EL3 secure monitor's PSCI implementation. On 64-bit sunxi SoCs, this is provided by ARM TF-A; 32-bit SoCs use a different implementation. The secure monitor uses the message box to forward requests to power management firmware running on a separate CPU. It is not enough for the secure monitor to enable the clock each time Linux performs a SMC into EL3, as both the firmware and Linux can run concurrently on separate CPUs. So it is never safe for Linux to turn this clock off, and it should be marked as critical. At this time, such power management firmware only exists for the A64 and H5 SoCs. However, it makes sense to take care of all CCU drivers now for consistency, and to ease the transition in the future once firmware is ported to the other SoCs. Signed-off-by: Samuel Holland --- drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 3 ++- drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 3 ++- drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 3 ++- drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 3 ++- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 3 ++- drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 3 ++- drivers/clk/sunxi-ng/ccu-sun9i-a80.c | 3 ++- 7 files changed, 14 insertions(+), 7 deletions(-) diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c index 49bd7a4c015c..045121b50da3 100644 --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c @@ -342,8 +342,9 @@ static SUNXI_CCU_GATE(bus_de_clk, "bus-de", "ahb1", 0x064, BIT(12), 0); static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu", "ahb1", 0x064, BIT(20), 0); +/* Used for communication between firmware components at runtime */ static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "ahb1", - 0x064, BIT(21), 0); + 0x064, BIT(21), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1", 0x064, BIT(22), 0); diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c index aebef4af9861..14f39bc4180f 100644 --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c @@ -340,8 +340,9 @@ static SUNXI_CCU_GATE(bus_vp9_clk, "bus-vp9", "psi-ahb1-ahb2", static SUNXI_CCU_GATE(bus_dma_clk, "bus-dma", "psi-ahb1-ahb2", 0x70c, BIT(0), 0); +/* Used for communication between firmware components at runtime */ static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "psi-ahb1-ahb2", - 0x71c, BIT(0), 0); + 0x71c, BIT(0), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk, "bus-spinlock", "psi-ahb1-ahb2", 0x72c, BIT(0), 0); diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c index 103aa504f6c8..5a28583f57e2 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c @@ -255,8 +255,9 @@ static SUNXI_CCU_GATE(bus_de_fe_clk,"bus-de-fe", "ahb1", 0x064, BIT(14), 0); static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu", "ahb1", 0x064, BIT(20), 0); +/* Used for communication between firmware components at runtime */ static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "ahb1", - 0x064, BIT(21), 0); + 0x064, BIT(21), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1", 0x064, BIT(22), 0); static SUNXI_CCU_GATE(bus_drc_clk, "bus-drc", "ahb1", diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c index 91838cd11037..50cf3726ef30 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c @@ -267,8 +267,9 @@ static SUNXI_CCU_GATE(bus_de_fe_clk,"bus-de-fe", "ahb1", 0x064, BIT(14), 0); static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu", "ahb1", 0x064, BIT(20), 0); +/* Used for communication between firmware components at runtime */ static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "ahb1", - 0x064, BIT(21), 0); + 0x064, BIT(21), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1", 0x064, BIT(22), 0); static SUNXI_CCU_GATE(bus_drc_clk, "bus-drc", "ahb1", diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c index 2b434521c5cc..4ab3a76f4ffa 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c @@ -339,8 +339,9 @@ static SUNXI_CCU_GATE(bus_de_clk, "bus-de", "ahb1", 0x064, BIT(12), 0); static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu",
[PATCH v4 03/10] dt-bindings: mailbox: Add a sunxi message box binding
This mailbox hardware is present in Allwinner sun8i, sun9i, and sun50i
SoCs. Add a device tree binding for it.
Reviewed-by: Rob Herring
Signed-off-by: Samuel Holland
---
.../mailbox/allwinner,sunxi-msgbox.yaml | 79 +++
1 file changed, 79 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml
diff --git
a/Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml
b/Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml
new file mode 100644
index ..f34a1909ab2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/allwinner,sunxi-msgbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner sunxi Message Box
+
+maintainers:
+ - Samuel Holland
+
+description: |
+ The hardware message box on sun6i and newer sunxi SoCs is a two-user mailbox
+ controller containing 8 unidirectional FIFOs. An interrupt is raised for
+ received messages, but software must poll to know when a transmitted message
+ has been acknowledged by the remote user. Each FIFO can hold four 32-bit
+ messages; when a FIFO is full, clients must wait before more transmissions.
+
+ Refer to ./mailbox.txt for generic information about mailbox device-tree
+ bindings.
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - enum:
+ - allwinner,sun8i-a83t-msgbox
+ - allwinner,sun8i-h3-msgbox
+ - allwinner,sun9i-a80-msgbox
+ - allwinner,sun50i-a64-msgbox
+ - allwinner,sun50i-h6-msgbox
+ - const: allwinner,sun6i-a31-msgbox
+ - items:
+ - const: allwinner,sun6i-a31-msgbox
+
+ reg:
+items:
+ - description: MMIO register range
+
+ clocks:
+maxItems: 1
+description: bus clock
+
+ resets:
+maxItems: 1
+description: bus reset
+
+ interrupts:
+maxItems: 1
+description: controller interrupt
+
+ '#mbox-cells':
+const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - interrupts
+ - '#mbox-cells'
+
+examples:
+ - |
+#include
+#include
+#include
+
+msgbox: mailbox@1c17000 {
+compatible = "allwinner,sun8i-h3-msgbox",
+ "allwinner,sun6i-a31-msgbox";
+reg = <0x01c17000 0x1000>;
+clocks = < CLK_BUS_MSGBOX>;
+resets = < RST_BUS_MSGBOX>;
+interrupts = ;
+#mbox-cells = <1>;
+};
+
+...
--
2.21.0
[PATCH v4 10/10] [DO NOT MERGE] drivers: firmware: msgbox demo
This driver provides a trivial mailbox client that can be used with the
mailbox-demo branch of https://github.com/crust-firmware/crust for
verifying the functionality of the sunxi-msgbox driver.
This is not a "real" driver, nor a "real" firmware protocol. This driver
is not intended to be merged. It is provided only as an example that
won't interfere with any other hardware.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 ++
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 24 ++
drivers/firmware/Kconfig | 6 +
drivers/firmware/Makefile | 1 +
drivers/firmware/sunxi_msgbox_demo.c | 310 ++
5 files changed, 365 insertions(+)
create mode 100644 drivers/firmware/sunxi_msgbox_demo.c
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 428f539a091a..78315d5512db 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -121,6 +121,30 @@
};
};
+ demo_0 {
+ compatible = "allwinner,sunxi-msgbox-demo";
+ mboxes = < 0>, < 1>;
+ mbox-names = "tx", "rx";
+ };
+
+ demo_1 {
+ compatible = "allwinner,sunxi-msgbox-demo";
+ mboxes = < 2>, < 3>;
+ mbox-names = "tx", "rx";
+ };
+
+ demo_2 {
+ compatible = "allwinner,sunxi-msgbox-demo";
+ mboxes = < 4>, < 5>;
+ mbox-names = "tx", "rx";
+ };
+
+ demo_3 {
+ compatible = "allwinner,sunxi-msgbox-demo";
+ mboxes = < 6>, < 7>;
+ mbox-names = "tx", "rx";
+ };
+
de: display-engine {
compatible = "allwinner,sun50i-a64-display-engine";
allwinner,pipelines = <>,
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index f002a496d7cb..5a2d85b7e0a1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -76,6 +76,30 @@
};
};
+ demo_0 {
+ compatible = "allwinner,sunxi-msgbox-demo";
+ mboxes = < 0>, < 1>;
+ mbox-names = "tx", "rx";
+ };
+
+ demo_1 {
+ compatible = "allwinner,sunxi-msgbox-demo";
+ mboxes = < 2>, < 3>;
+ mbox-names = "tx", "rx";
+ };
+
+ demo_2 {
+ compatible = "allwinner,sunxi-msgbox-demo";
+ mboxes = < 4>, < 5>;
+ mbox-names = "tx", "rx";
+ };
+
+ demo_3 {
+ compatible = "allwinner,sunxi-msgbox-demo";
+ mboxes = < 6>, < 7>;
+ mbox-names = "tx", "rx";
+ };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index ba8d3d0ef32c..e0f8f3c856c1 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -240,6 +240,12 @@ config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
Say Y here to enable "download mode" by default.
+config SUNXI_MSGBOX_DEMO
+ tristate "sunxi msgbox demo"
+ depends on MAILBOX
+ help
+ Demo client for demo firmware to use in mailbox driver validation.
+
config TI_SCI_PROTOCOL
tristate "TI System Control Interface (TISCI) Message Protocol"
depends on TI_MESSAGE_MANAGER
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 3fa0b34eb72f..6f8e17a854b6 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_QCOM_SCM)+= qcom_scm.o
obj-$(CONFIG_QCOM_SCM_64) += qcom_scm-64.o
obj-$(CONFIG_QCOM_SCM_32) += qcom_scm-32.o
CFLAGS_qcom_scm-32.o :=$(call as-instr,.arch armv7-a\n.arch_extension
sec,-DREQUIRES_SEC=1) -march=armv7-a
+obj-$(CONFIG_SUNXI_MSGBOX_DEMO)+= sunxi_msgbox_demo.o
obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o
diff --git a/drivers/firmware/sunxi_msgbox_demo.c
b/drivers/firmware/sunxi_msgbox_demo.c
new file mode 100644
index ..9431b1ef1841
--- /dev/null
+++ b/drivers/firmware/sunxi_msgbox_demo.c
@@ -0,0 +1,310 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2018-2019 Samuel Holland
+
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ OP_MAGIC,
+ OP_VERSION,
+ OP_LOOPBACK,
+ OP_LOOPBACK_INVERTED,
+ OP_TIME_SECONDS,
+ OP_TIME_TICKS,
+ OP_DELAY_MICROS,
+ OP_DELAY_MILLIS,
+ OP_ADDR_SET_LO,
+ OP_ADDR_SET_HI,
+ OP_ADDR_READ,
+ OP_ADDR_WRITE,
+ OP_INVALID_1,
+ OP_INVALID_2,
+ OP_RESET = 16,
+};
+
+struct msgbox_demo {
+ struct mbox_chan *rx_chan;
+
[PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver
Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
used for communication between the ARM CPUs and the ARISC management
coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
Add a driver for it, so it can be used for SCPI or other communication
protocols.
Signed-off-by: Samuel Holland
---
drivers/mailbox/Kconfig| 10 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/sunxi-msgbox.c | 323 +
3 files changed, 335 insertions(+)
create mode 100644 drivers/mailbox/sunxi-msgbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..57d12936175e 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -227,4 +227,14 @@ config ZYNQMP_IPI_MBOX
message to the IPI buffer and will access the IPI control
registers to kick the other processor or enquire status.
+config SUNXI_MSGBOX
+ tristate "Allwinner sunxi Message Box"
+ depends on ARCH_SUNXI || COMPILE_TEST
+ default ARCH_SUNXI
+ help
+ Mailbox implementation for the hardware message box present in
+ Allwinner sun8i, sun9i, and sun50i SoCs. The hardware message box is
+ used for communication between the application CPUs and the power
+ management coprocessor.
+
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..bec2d50b0976 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -48,3 +48,5 @@ obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
obj-$(CONFIG_MTK_CMDQ_MBOX)+= mtk-cmdq-mailbox.o
obj-$(CONFIG_ZYNQMP_IPI_MBOX) += zynqmp-ipi-mailbox.o
+
+obj-$(CONFIG_SUNXI_MSGBOX) += sunxi-msgbox.o
diff --git a/drivers/mailbox/sunxi-msgbox.c b/drivers/mailbox/sunxi-msgbox.c
new file mode 100644
index ..29a5101a5390
--- /dev/null
+++ b/drivers/mailbox/sunxi-msgbox.c
@@ -0,0 +1,323 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2017-2019 Samuel Holland
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NUM_CHANS 8
+
+#define CTRL_REG(n)(0x + 0x4 * ((n) / 4))
+#define CTRL_RX(n) BIT(0 + 8 * ((n) % 4))
+#define CTRL_TX(n) BIT(4 + 8 * ((n) % 4))
+
+#define REMOTE_IRQ_EN_REG 0x0040
+#define REMOTE_IRQ_STAT_REG0x0050
+#define LOCAL_IRQ_EN_REG 0x0060
+#define LOCAL_IRQ_STAT_REG 0x0070
+
+#define RX_IRQ(n) BIT(0 + 2 * (n))
+#define RX_IRQ_MASK0x
+#define TX_IRQ(n) BIT(1 + 2 * (n))
+#define TX_IRQ_MASK0x
+
+#define FIFO_STAT_REG(n) (0x0100 + 0x4 * (n))
+#define FIFO_STAT_MASK GENMASK(0, 0)
+
+#define MSG_STAT_REG(n)(0x0140 + 0x4 * (n))
+#define MSG_STAT_MASK GENMASK(2, 0)
+
+#define MSG_DATA_REG(n)(0x0180 + 0x4 * (n))
+
+#define mbox_dbg(mbox, ...)dev_dbg((mbox)->controller.dev, __VA_ARGS__)
+
+struct sunxi_msgbox {
+ struct mbox_controller controller;
+ struct clk *clk;
+ spinlock_t lock;
+ void __iomem *regs;
+};
+
+static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan);
+static bool sunxi_msgbox_peek_data(struct mbox_chan *chan);
+
+static inline int channel_number(struct mbox_chan *chan)
+{
+ return chan - chan->mbox->chans;
+}
+
+static inline struct sunxi_msgbox *channel_to_msgbox(struct mbox_chan *chan)
+{
+ return chan->con_priv;
+}
+
+static irqreturn_t sunxi_msgbox_irq(int irq, void *dev_id)
+{
+ struct sunxi_msgbox *mbox = dev_id;
+ uint32_t status;
+ int n;
+
+ /* Only examine channels that are currently enabled. */
+ status = readl(mbox->regs + LOCAL_IRQ_EN_REG) &
+readl(mbox->regs + LOCAL_IRQ_STAT_REG);
+
+ if (!(status & RX_IRQ_MASK))
+ return IRQ_NONE;
+
+ for (n = 0; n < NUM_CHANS; ++n) {
+ struct mbox_chan *chan = >controller.chans[n];
+
+ if (!(status & RX_IRQ(n)))
+ continue;
+
+ while (sunxi_msgbox_peek_data(chan)) {
+ uint32_t msg = readl(mbox->regs + MSG_DATA_REG(n));
+
+ mbox_dbg(mbox, "Channel %d received 0x%08x\n", n, msg);
+ mbox_chan_received_data(chan, );
+ }
+
+ /* The IRQ can be cleared only once the FIFO is empty. */
+ writel(RX_IRQ(n), mbox->regs + LOCAL_IRQ_STAT_REG);
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int sunxi_msgbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct sunxi_msgbox *mbox = channel_to_msgbox(chan);
+ int n = channel_number(chan);
+ uint32_t msg = *(uint32_t *)data;
+
+ /* Using a channel backwards gets the hardware into a bad state. */
+ if (WARN_ON_ONCE(!(readl(mbox->regs + CTRL_REG(n)) &
[PATCH v4 08/10] arm64: dts: allwinner: a64: Add msgbox node
The A64 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index ddb6f11e89df..428f539a091a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -487,6 +487,16 @@
reg = <0x1c14000 0x400>;
};
+ msgbox: mailbox@1c17000 {
+ compatible = "allwinner,sun50i-a64-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x01c17000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
usb_otg: usb@1c19000 {
compatible = "allwinner,sun8i-a33-musb";
reg = <0x01c19000 0x0400>;
--
2.21.0
[PATCH v4 07/10] ARM: dts: sunxi: h3/h5: Add msgbox node
The H3 and H5 SoCs contain a message box that can be used to send
messages and interrupts back and forth between the ARM application CPUs
and the ARISC coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 224e105a994a..f25876a8021a 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -232,6 +232,16 @@
reg = <0x1c14000 0x400>;
};
+ msgbox: mailbox@1c17000 {
+ compatible = "allwinner,sun8i-h3-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x01c17000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
usb_otg: usb@1c19000 {
compatible = "allwinner,sun8i-h3-musb";
reg = <0x01c19000 0x400>;
--
2.21.0
[PATCH] ARM: dts: vf610-zii-dev-rev-b: Drop redundant I2C properties
Drop redundant I2C properties that are already specified in
vf610-zii-dev.dtsi
Signed-off-by: Andrey Smirnov
Cc: Shawn Guo
Cc: Chris Healy
Cc: Fabio Estevam
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 48086c5e8549..e500911ce0a5 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -323,11 +323,6 @@
};
{
- clock-frequency = <10>;
- pinctrl-names = "default";
- pinctrl-0 = <_i2c0>;
- status = "okay";
-
gpio5: io-expander@20 {
compatible = "nxp,pca9554";
reg = <0x20>;
@@ -350,11 +345,6 @@
};
{
- clock-frequency = <10>;
- pinctrl-names = "default";
- pinctrl-0 = <_i2c2>;
- status = "okay";
-
tca9548@70 {
compatible = "nxp,pca9548";
pinctrl-0 = <_i2c_mux_reset>;
--
2.21.0
Re: [PATCH] Input: hyperv-keyboard: Use in-place iterator API in the channel callback
On Tue, Aug 20, 2019 at 03:01:23AM +, Dexuan Cui wrote:
> Simplify the ring buffer handling with the in-place API.
>
> Also avoid the dynamic allocation and the memory leak in the channel
> callback function.
>
> Signed-off-by: Dexuan Cui
> ---
>
> Hi Dmitry, can this patch go through Sasha's hyperv tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
>
> This is a purely Hyper-V specific change.
Sure, no problem.
Acked-by: Dmitry Torokhov
>
> drivers/input/serio/hyperv-keyboard.c | 35
> ++-
> 1 file changed, 6 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/input/serio/hyperv-keyboard.c
> b/drivers/input/serio/hyperv-keyboard.c
> index 88ae7c2..e486a8a 100644
> --- a/drivers/input/serio/hyperv-keyboard.c
> +++ b/drivers/input/serio/hyperv-keyboard.c
> @@ -237,40 +237,17 @@ static void hv_kbd_handle_received_packet(struct
> hv_device *hv_dev,
>
> static void hv_kbd_on_channel_callback(void *context)
> {
> + struct vmpacket_descriptor *desc;
> struct hv_device *hv_dev = context;
> - void *buffer;
> - int bufferlen = 0x100; /* Start with sensible size */
> u32 bytes_recvd;
> u64 req_id;
> - int error;
>
> - buffer = kmalloc(bufferlen, GFP_ATOMIC);
> - if (!buffer)
> - return;
> -
> - while (1) {
> - error = vmbus_recvpacket_raw(hv_dev->channel, buffer, bufferlen,
> - _recvd, _id);
> - switch (error) {
> - case 0:
> - if (bytes_recvd == 0) {
> - kfree(buffer);
> - return;
> - }
> -
> - hv_kbd_handle_received_packet(hv_dev, buffer,
> - bytes_recvd, req_id);
> - break;
> + foreach_vmbus_pkt(desc, hv_dev->channel) {
> + bytes_recvd = desc->len8 * 8;
> + req_id = desc->trans_id;
>
> - case -ENOBUFS:
> - kfree(buffer);
> - /* Handle large packet */
> - bufferlen = bytes_recvd;
> - buffer = kmalloc(bytes_recvd, GFP_ATOMIC);
> - if (!buffer)
> - return;
> - break;
> - }
> + hv_kbd_handle_received_packet(hv_dev, desc, bytes_recvd,
> + req_id);
> }
> }
>
> --
> 1.8.3.1
>
--
Dmitry
Re: [PATCH v1 1/2] dt-bindings: phy: intel-emmc-phy: Add new compatible for LGM eMMC PHY
On 20/8/2019 3:27 AM, Rob Herring wrote:
On Sun, Aug 18, 2019 at 10:44 PM Ramuthevar,Vadivel MuruganX
wrote:
From: Ramuthevar Vadivel Murugan
Add a new compatible to use the host controller driver with the
eMMC PHY on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../bindings/phy/intel-lgm-emmc-phy.yaml | 70 ++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
b/Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
new file mode 100644
index ..52156ff091ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0
Preference for new bindings is (GPL-2.0-only OR BSD-2-Clause)
Thanks a lot for the review comments, agreed, will update in the next
patch version.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel-lgm-emmc-phy.yaml#
Preferred filename is the compatible string (plus .yaml).
Agreed!
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM e-MMC PHY Device Tree Bindings
LGM is what?
Intel's Lightning Mountain(LGM) SoC.
+
+maintainers:
+ - Rob Herring
+ - Mark Rutland
I don't know anything about this h/w. Please put yourself here.
Agreed, will update.
+
+intel,syscon:
This will throw an error with 'make dt_binding_check'...
agreed, will remove
+ $ref: /schemas/types.yaml#definitions/phandle
+ description:
+- |
+ e-MMC phy module connected through chiptop. Phandle to a node that can
+ contain the following properties
+* reg, Access the e-MMC, get the base address from syscon.
+* reset, reset the e-MMC module.
+
+properties:
+ "#phy-cells":
+const: 0
+
+ compatible:
+const: intel,lgm-emmc-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: e-MMC phy module clock
+
+ clock-names:
+items:
+ - const: emmcclk
+
+ resets:
+maxItems: 1
+
+required:
+ - "#phy-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+sysconf: chiptop@e002 {
+compatible = "intel,chiptop-lgm", "syscon";
+reg = <0xe002 0x100>;
+#reset-cells = <1>;
+ };
+
+ - |
Looks like 1 example to me, not 2.
Agreed, I will keep the below one example.
Best Regards
Vadivel
+emmc_phy: emmc_phy {
+compatible = "intel,lgm-emmc-phy";
+intel,syscon = <>;
+clocks = <>;
+clock-names = "emmcclk";
+#phy-cells = <0>;
+};
+
+...
--
2.11.0
Re: [PATCH] powerpc: Don't add -mabi= flags when building with Clang
On Mon, Aug 19, 2019 at 04:19:31AM -0500, Segher Boessenkool wrote:
> On Sun, Aug 18, 2019 at 12:13:21PM -0700, Nathan Chancellor wrote:
> > When building pseries_defconfig, building vdso32 errors out:
> >
> > error: unknown target ABI 'elfv1'
> >
> > Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a
> > powerpc64le toolchain") added these flags to fix building GCC but
> > clang is multitargeted and does not need these flags. The ABI is
> > properly set based on the target triple, which is derived from
> > CROSS_COMPILE.
>
> You mean that LLVM does not *allow* you to select a different ABI, or
> different ABI options, you always have to use the default. (Everything
> else you say is true for GCC as well).
I need to improve the wording of the commit message as it is really that
clang does not allow a different ABI to be selected for 32-bit PowerPC,
as the setABI function is not overridden and it defaults to false.
https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0-rc2/clang/include/clang/Basic/TargetInfo.h#L1073-L1078
https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0-rc2/clang/lib/Basic/Targets/PPC.h#L327-L365
GCC appears to just silently ignores this flag (I think it is the
SUBSUBTARGET_OVERRIDE_OPTIONS macro in gcc/config/rs6000/linux64.h).
It can be changed for 64-bit PowerPC it seems but it doesn't need to be
with clang because everything is set properly internally (I'll find a
better way to clearly word that as I am sure I'm not quite getting that
subtlety right).
> (-mabi= does not set a "target ABI", fwiw, it is more subtle; please see
> the documentation. Unless LLVM is incompatible in that respect as well?)
Are you referring to the error message? I suppose I could file an LLVM
bug report on that but that message applies to all of the '-mabi='
options, which may refer to a target ABI.
Cheers,
Nathan
[PATCHv2 2/2] i915: do not leak module ref counter
Always put_filesystem() in i915_gemfs_init(). Signed-off-by: Sergey Senozhatsky --- - v2: rebased (i915 does not remount gemfs anymore) drivers/gpu/drm/i915/gem/i915_gemfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c b/drivers/gpu/drm/i915/gem/i915_gemfs.c index 5e6e8c91ab38..0a398e1e45fc 100644 --- a/drivers/gpu/drm/i915/gem/i915_gemfs.c +++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c @@ -30,6 +30,7 @@ int i915_gemfs_init(struct drm_i915_private *i915) */ gemfs = kern_mount(type); + put_filesystem(type); if (IS_ERR(gemfs)) return PTR_ERR(gemfs); -- 2.23.0
[PATCH] vsock: Fix a lockdep warning in __vsock_release()
Lockdep is unhappy if two locks from the same class are held.
Fix the below warning by making __vsock_release() non-recursive -- this
patch is kind of ugly, but it looks to me there is not a better way to
deal with the problem here.
WARNING: possible recursive locking detected
5.2.0+ #6 Not tainted
a.out/1020 is trying to acquire lock:
74731a98 (sk_lock-AF_VSOCK){+.+.}, at: hvs_release+0x10/0x120 [hv_sock]
but task is already holding lock:
14ff8397 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(sk_lock-AF_VSOCK);
lock(sk_lock-AF_VSOCK);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by a.out/1020:
#0: f8bceaa7 (>s_type->i_mutex_key#10){+.+.}, at:
__sock_release+0x2d/0xa0
#1: 14ff8397 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0
[vsock]
stack backtrace:
CPU: 7 PID: 1020 Comm: a.out Not tainted 5.2.0+ #6
Call Trace:
dump_stack+0x67/0x90
__lock_acquire.cold.66+0x14d/0x1f8
lock_acquire+0xb5/0x1c0
lock_sock_nested+0x6d/0x90
hvs_release+0x10/0x120 [hv_sock]
__vsock_release+0x24/0xf0 [vsock]
__vsock_release+0xa0/0xf0 [vsock]
vsock_release+0x12/0x30 [vsock]
__sock_release+0x37/0xa0
sock_close+0x14/0x20
__fput+0xc1/0x250
task_work_run+0x98/0xc0
do_exit+0x3dd/0xc60
do_group_exit+0x47/0xc0
get_signal+0x169/0xc60
do_signal+0x30/0x710
exit_to_usermode_loop+0x50/0xa0
do_syscall_64+0x1fc/0x220
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Signed-off-by: Dexuan Cui
---
net/vmw_vsock/af_vsock.c | 33 -
net/vmw_vsock/hyperv_transport.c | 2 +-
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index ab47bf3..420f605 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -638,6 +638,37 @@ struct sock *__vsock_create(struct net *net,
}
EXPORT_SYMBOL_GPL(__vsock_create);
+static void __vsock_release2(struct sock *sk)
+{
+ if (sk) {
+ struct sk_buff *skb;
+ struct vsock_sock *vsk;
+
+ vsk = vsock_sk(sk);
+
+ /* The release call is supposed to use lock_sock_nested()
+* rather than lock_sock(), if a lock should be acquired.
+*/
+ transport->release(vsk);
+
+ /* Use the nested version to avoid the warning
+* "possible recursive locking detected".
+*/
+ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
+ sock_orphan(sk);
+ sk->sk_shutdown = SHUTDOWN_MASK;
+
+ while ((skb = skb_dequeue(>sk_receive_queue)))
+ kfree_skb(skb);
+
+ /* This sk can not be a listener, so it's unnecessary
+* to call vsock_dequeue_accept().
+*/
+ release_sock(sk);
+ sock_put(sk);
+ }
+}
+
static void __vsock_release(struct sock *sk)
{
if (sk) {
@@ -659,7 +690,7 @@ static void __vsock_release(struct sock *sk)
/* Clean up any sockets that never were accepted. */
while ((pending = vsock_dequeue_accept(sk)) != NULL) {
- __vsock_release(pending);
+ __vsock_release2(pending);
sock_put(pending);
}
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 9d864eb..4b126b2 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -559,7 +559,7 @@ static void hvs_release(struct vsock_sock *vsk)
struct sock *sk = sk_vsock(vsk);
bool remove_sock;
- lock_sock(sk);
+ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
remove_sock = hvs_close_lock_held(vsk);
release_sock(sk);
if (remove_sock)
--
1.8.3.1
[PATCH] ARM: dts: vf610-zii-scu4-aib: Drop "rs485-rts-delay" property
LPUART driver does not support specifying "rs485-rts-delay" property. Drop it. Signed-off-by: Andrey Smirnov Cc: Shawn Guo Cc: Chris Healy Cc: Fabio Estevam Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- arch/arm/boot/dts/vf610-zii-scu4-aib.dts | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts index 666ec27a73e3..d8c38ef6a98a 100644 --- a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts +++ b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts @@ -685,7 +685,6 @@ linux,rs485-enabled-at-boot-time; pinctrl-names = "default"; pinctrl-0 = <_uart1>; - rs485-rts-delay = <0 200>; status = "okay"; }; @@ -693,7 +692,6 @@ linux,rs485-enabled-at-boot-time; pinctrl-names = "default"; pinctrl-0 = <_uart2>; - rs485-rts-delay = <0 200>; status = "okay"; }; -- 2.21.0
Re: [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-)
On 8/19/19 6:20 PM, Dave Chinner wrote: On Mon, Aug 19, 2019 at 05:05:53PM -0700, John Hubbard wrote: On 8/19/19 2:24 AM, Dave Chinner wrote: On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan Kara wrote: On Sat 17-08-19 12:26:03, Dave Chinner wrote: On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira Weiny wrote: On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote: On Wed 14-08-19 11:08:49, Ira Weiny wrote: On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote: ... Any thoughts about sockets? I'm looking at net/xdp/xdp_umem.c which pins memory with FOLL_LONGTERM, and wondering how to make that work here. I'm not sure how this interacts with file mappings? I mean, this is just pinning anonymous pages for direct data placement into userspace, right? Are you asking "what if this pinned memory was a file mapping?", or something else? Yes, mainly that one. Especially since the FOLL_LONGTERM flag is already there in xdp_umem_pin_pages(), unconditionally. So the simple rules about struct *vaddr_pin usage (set it to NULL if FOLL_LONGTERM is not set) are not going to work here. These are close to files, in how they're handled, but just different enough that it's not clear to me how to make work with this system. I'm guessing that if they are pinning a file backed mapping, they are trying to dma direct to the file (zero copy into page cache?) and so they'll need to either play by ODP rules or take layout leases, too OK. I was just wondering if there was some simple way to dig up a struct file associated with a socket (I don't think so), but it sounds like this is an exercise that's potentially different for each subsystem. thanks, -- John Hubbard NVIDIA
Re: [PATCH v1 2/2] phy: intel-lgm-emmc: Add support for eMMC PHY
On 20/8/2019 12:06 AM, Andy Shevchenko wrote:
On Mon, Aug 19, 2019 at 11:44:16AM +0800, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
Adds support for eMMC PHY on Intel's Lightning Mountain SoC.
Adds -> Add.
Thanks Andy, agreed.
+/* eMMC phy register definitions */
+#define EMMC_PHYCTRL0_REG 0xa8
+#define DR_TY_MASK GENMASK(30, 28)
+#define DR_TY_50OHM(x) ((~(x) << 28) & DR_TY_MASK)
+#define OTAPDLYENA BIT(14)
+#define OTAPDLYSEL_MASKGENMASK(13, 10)
+#define OTAPDLYSEL_SHIFT(x)(((x) << 10) & OTAPDLYSEL_MASK)
+
+#define EMMC_PHYCTRL1_REG 0xac
+#define PDB_MASK 1
BIT(0)
agreed.
+#define ENDLL_MASK BIT(7)
+#define ENDLL_VAL BIT(7)
+
+#define EMMC_PHYCTRL2_REG 0xb0
+#define FRQSEL_25M 0
+#define FRQSEL_150M3
+#define FRQSEL_MASKGENMASK(24, 22)
+#define FRQSEL_SHIFT(x)((x) << 22)
+
+#define EMMC_PHYSTAT_REG 0xbc
+#define CALDONE_MASK 1
+#define DLLRDY_MASK1
+#define IS_CALDONE(x) x) >> 9) & CALDONE_MASK) == 1)
+#define IS_DLLRDY(x) x) >> 8) & DLLRDY_MASK) == 1)
These are inconsistent with above:
#define CALDONE_MASKBIT(9)
...
#define IS_CALDONE ((x) & CALDONE_MASK)
Note redundant == part.
Agreed, will update.
+static int intel_emmc_phy_power(struct phy *phy, bool on_off)
+{
+* - PHY driver to probe
+* - SDHCI driver to start probe
+* - SDHCI driver to register it's clock
+* - SDHCI driver to get the PHY
+* - SDHCI driver to init the PHY
+*
+* The clock is optional, so upon any error we just set to NULL.
No, the clock framework will do it for you.
+*
+* NOTE: we don't do anything special for EPROBE_DEFER here. Given the
+* above expected use case, EPROBE_DEFER isn't sensible to expect, so
+* it's just like any other error.
This comment is not correct...
Agreed, re-structure the sentence.
+*/
+ priv->emmcclk = clk_get_optional(>dev, "emmcclk");
+ if (IS_ERR(priv->emmcclk)) {
+ dev_warn(>dev, "ERROR: getting emmcclk\n");
...because here you have to return an error...
Agreed.
+ priv->emmcclk = NULL;
...and here is redundant assignment.
Agreed.
+ }
+
+ return 0;
+}
When you send out patches, check that you do this for latest version you got
reviewed internally.
Thank you so much for the review comments, sure I will recheck and
recollect your review comments of different patches
for the same cases .
With Best Regards
vadivel
[PATCH] ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100kHz
Fiber-optic module attached to the bus is only rated to work at
100kHz, so drop the bus frequncy to accomodate that.
Signed-off-by: Andrey Smirnov
Cc: Shawn Guo
Cc: Chris Healy
Cc: Fabio Estevam
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
b/arch/arm/boot/dts/vf610-zii-cfu1.dts
index ff460a1de85a..28732249cfc0 100644
--- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
+++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
@@ -207,7 +207,7 @@
};
{
- clock-frequency = <40>;
+ clock-frequency = <10>;
pinctrl-names = "default";
pinctrl-0 = <_i2c0>;
status = "okay";
--
2.21.0
[PATCH] Drivers: hv: vmbus: Remove the unused "tsc_page" from struct hv_context
This field is no longer used after the commit
63ed4e0c67df ("Drivers: hv: vmbus: Consolidate all Hyper-V specific clocksource
code")
, because it's replaced by the global variable
"struct ms_hyperv_tsc_page *tsc_pg;" (now, the variable is in
drivers/clocksource/hyperv_timer.c).
Fixes: 63ed4e0c67df ("Drivers: hv: vmbus: Consolidate all Hyper-V specific
clocksource code")
Signed-off-by: Dexuan Cui
---
drivers/hv/hyperv_vmbus.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 362e70e..fb16a62 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -146,8 +146,6 @@ struct hv_context {
*/
u64 guestid;
- void *tsc_page;
-
struct hv_per_cpu_context __percpu *cpu_context;
/*
--
1.8.3.1
Re: [v2 PATCH] RISC-V: Optimize tlb flush path.
On Mon, Aug 19, 2019 at 05:47:35PM -0700, Atish Patra wrote:
> In RISC-V, tlb flush happens via SBI which is expensive.
> If the target cpumask contains a local hartid, some cost
> can be saved by issuing a local tlb flush as we do that
> in OpenSBI anyways. There is also no need of SBI call if
> cpumask is empty.
>
> Do a local flush first if current cpu is present in cpumask.
> Invoke SBI call only if target cpumask contains any cpus
> other than local cpu.
Btw, you can use up your 70-ish chars per line for commit logs..
> + if (cpumask_test_cpu(cpuid, cmask)) {
> + /* Save trap cost by issuing a local tlb flush here */
> + if ((start == 0 && size == -1) || (size > PAGE_SIZE))
> + local_flush_tlb_all();
> + else if (size == PAGE_SIZE)
> + local_flush_tlb_page(start);
> + }
This looks a little odd to m and assumes we never pass a size smaller
than PAGE_SIZE. Whule that is probably true, why not something like:
if (size < PAGE_SIZE && size != -1)
local_flush_tlb_page(start);
else
local_flush_tlb_all();
?
[PATCH] clk: add include guard to clk-conf.h
Add a header include guard just in case. Signed-off-by: Masahiro Yamada --- include/linux/clk/clk-conf.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/clk/clk-conf.h b/include/linux/clk/clk-conf.h index 85f8cf9d1226..eae9652c70cd 100644 --- a/include/linux/clk/clk-conf.h +++ b/include/linux/clk/clk-conf.h @@ -4,6 +4,9 @@ * Sylwester Nawrocki */ +#ifndef __CLK_CONF_H +#define __CLK_CONF_H + #include struct device_node; @@ -17,3 +20,5 @@ static inline int of_clk_set_defaults(struct device_node *node, return 0; } #endif + +#endif /* __CLK_CONF_H */ -- 2.17.1
Re: regression in ath10k dma allocation
Tobias, plase try this patch:
--
>From 88c590a2ecafc8279388f25bfbe1ead8ea3507a6 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Tue, 20 Aug 2019 11:45:49 +0900
Subject: dma-direct: fix zone selection after an unaddressable CMA allocation
The new dma_alloc_contiguous hides if we allocate CMA or regular
pages, and thus fails to retry a ZONE_NORMAL allocation if the CMA
allocation succeeds but isn't addressable. That means we either fail
outright or dip into a small zone that might not succeed either.
Thanks to Hillf Danton for debugging this issue.
Fixes: b1d2dc009dec ("dma-contiguous: add dma_{alloc,free}_contiguous()
helpers")
Reported-by: Tobias Klausmann
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 3 +++
include/linux/dma-contiguous.h | 5 +
kernel/dma/contiguous.c| 9 +++--
kernel/dma/direct.c| 7 ++-
4 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d991d40f797f..f68a62c3c32b 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -965,10 +965,13 @@ static void *iommu_dma_alloc_pages(struct device *dev,
size_t size,
{
bool coherent = dev_is_dma_coherent(dev);
size_t alloc_size = PAGE_ALIGN(size);
+ int node = dev_to_node(dev);
struct page *page = NULL;
void *cpu_addr;
page = dma_alloc_contiguous(dev, alloc_size, gfp);
+ if (!page)
+ page = alloc_pages_node(node, gfp, get_order(alloc_size));
if (!page)
return NULL;
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index c05d4e661489..03f8e98e3bcc 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -160,10 +160,7 @@ bool dma_release_from_contiguous(struct device *dev,
struct page *pages,
static inline struct page *dma_alloc_contiguous(struct device *dev, size_t
size,
gfp_t gfp)
{
- int node = dev ? dev_to_node(dev) : NUMA_NO_NODE;
- size_t align = get_order(PAGE_ALIGN(size));
-
- return alloc_pages_node(node, gfp, align);
+ return NULL;
}
static inline void dma_free_contiguous(struct device *dev, struct page *page,
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 2bd410f934b3..e6b450fdbeb6 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -230,9 +230,7 @@ bool dma_release_from_contiguous(struct device *dev, struct
page *pages,
*/
struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp)
{
- int node = dev ? dev_to_node(dev) : NUMA_NO_NODE;
- size_t count = PAGE_ALIGN(size) >> PAGE_SHIFT;
- size_t align = get_order(PAGE_ALIGN(size));
+ size_t count = size >> PAGE_SHIFT;
struct page *page = NULL;
struct cma *cma = NULL;
@@ -243,14 +241,12 @@ struct page *dma_alloc_contiguous(struct device *dev,
size_t size, gfp_t gfp)
/* CMA can be used only in the context which permits sleeping */
if (cma && gfpflags_allow_blocking(gfp)) {
+ size_t align = get_order(size);
size_t cma_align = min_t(size_t, align, CONFIG_CMA_ALIGNMENT);
page = cma_alloc(cma, count, cma_align, gfp & __GFP_NOWARN);
}
- /* Fallback allocation of normal pages */
- if (!page)
- page = alloc_pages_node(node, gfp, align);
return page;
}
@@ -258,6 +254,7 @@ struct page *dma_alloc_contiguous(struct device *dev,
size_t size, gfp_t gfp)
* dma_free_contiguous() - release allocated pages
* @dev: Pointer to device for which the pages were allocated.
* @page: Pointer to the allocated pages.
+ int node = dev ? dev_to_node(dev) : NUMA_NO_NODE;
* @size: Size of allocated pages.
*
* This function releases memory allocated by dma_alloc_contiguous(). As the
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 795c9b095d75..d82d184463ce 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -85,6 +85,8 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t
phys, size_t size)
struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
{
+ size_t alloc_size = PAGE_ALIGN(size);
+ int node = dev_to_node(dev);
struct page *page = NULL;
u64 phys_mask;
@@ -95,8 +97,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev,
size_t size,
gfp &= ~__GFP_ZERO;
gfp |= __dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
_mask);
+ page = dma_alloc_contiguous(dev, alloc_size, gfp);
+ if (page && dma_coherent_ok(dev, page_to_phys(page), size))
+ return page;
again:
- page = dma_alloc_contiguous(dev, size, gfp);
+ page = alloc_pages_node(node, gfp, get_order(alloc_size));
if (page &&
Re: [PATCH v10 2/7] powerpc/mce: Fix MCE handling for huge pages
Santosh Sivaraj's on August 20, 2019 11:47 am:
> Hi Nick,
>
> Nicholas Piggin writes:
>
>> Santosh Sivaraj's on August 15, 2019 10:39 am:
>>> From: Balbir Singh
>>>
>>> The current code would fail on huge pages addresses, since the shift would
>>> be incorrect. Use the correct page shift value returned by
>>> __find_linux_pte() to get the correct physical address. The code is more
>>> generic and can handle both regular and compound pages.
>>>
>>> Fixes: ba41e1e1ccb9 ("powerpc/mce: Hookup derror (load/store) UE errors")
>>> Signed-off-by: Balbir Singh
>>> [ar...@linux.ibm.com: Fixup pseries_do_memory_failure()]
>>> Signed-off-by: Reza Arbab
>>> Co-developed-by: Santosh Sivaraj
>>> Signed-off-by: Santosh Sivaraj
>>> Tested-by: Mahesh Salgaonkar
>>> Cc: sta...@vger.kernel.org # v4.15+
>>> ---
>>> arch/powerpc/include/asm/mce.h | 2 +-
>>> arch/powerpc/kernel/mce_power.c | 55 ++--
>>> arch/powerpc/platforms/pseries/ras.c | 9 ++---
>>> 3 files changed, 32 insertions(+), 34 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
>>> index a4c6a74ad2fb..f3a6036b6bc0 100644
>>> --- a/arch/powerpc/include/asm/mce.h
>>> +++ b/arch/powerpc/include/asm/mce.h
>>> @@ -209,7 +209,7 @@ extern void release_mce_event(void);
>>> extern void machine_check_queue_event(void);
>>> extern void machine_check_print_event_info(struct machine_check_event *evt,
>>>bool user_mode, bool in_guest);
>>> -unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr);
>>> +unsigned long addr_to_phys(struct pt_regs *regs, unsigned long addr);
>>> #ifdef CONFIG_PPC_BOOK3S_64
>>> void flush_and_reload_slb(void);
>>> #endif /* CONFIG_PPC_BOOK3S_64 */
>>> diff --git a/arch/powerpc/kernel/mce_power.c
>>> b/arch/powerpc/kernel/mce_power.c
>>> index a814d2dfb5b0..e74816f045f8 100644
>>> --- a/arch/powerpc/kernel/mce_power.c
>>> +++ b/arch/powerpc/kernel/mce_power.c
>>> @@ -20,13 +20,14 @@
>>> #include
>>>
>>> /*
>>> - * Convert an address related to an mm to a PFN. NOTE: we are in real
>>> - * mode, we could potentially race with page table updates.
>>> + * Convert an address related to an mm to a physical address.
>>> + * NOTE: we are in real mode, we could potentially race with page table
>>> updates.
>>> */
>>> -unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
>>> +unsigned long addr_to_phys(struct pt_regs *regs, unsigned long addr)
>>> {
>>> - pte_t *ptep;
>>> - unsigned long flags;
>>> + pte_t *ptep, pte;
>>> + unsigned int shift;
>>> + unsigned long flags, phys_addr;
>>> struct mm_struct *mm;
>>>
>>> if (user_mode(regs))
>>> @@ -35,14 +36,21 @@ unsigned long addr_to_pfn(struct pt_regs *regs,
>>> unsigned long addr)
>>> mm = _mm;
>>>
>>> local_irq_save(flags);
>>> - if (mm == current->mm)
>>> - ptep = find_current_mm_pte(mm->pgd, addr, NULL, NULL);
>>> - else
>>> - ptep = find_init_mm_pte(addr, NULL);
>>> + ptep = __find_linux_pte(mm->pgd, addr, NULL, );
>>> local_irq_restore(flags);
>>> +
>>> if (!ptep || pte_special(*ptep))
>>> return ULONG_MAX;
>>> - return pte_pfn(*ptep);
>>> +
>>> + pte = *ptep;
>>> + if (shift > PAGE_SHIFT) {
>>> + unsigned long rpnmask = (1ul << shift) - PAGE_SIZE;
>>> +
>>> + pte = __pte(pte_val(pte) | (addr & rpnmask));
>>> + }
>>> + phys_addr = pte_pfn(pte) << PAGE_SHIFT;
>>> +
>>> + return phys_addr;
>>> }
>>
>> This should remain addr_to_pfn I think. None of the callers care what
>> size page the EA was mapped with. 'pfn' is referring to the Linux pfn,
>> which is the small page number.
>>
>> if (shift > PAGE_SHIFT)
>> return (pte_pfn(*ptep) | ((addr & ((1UL << shift) - 1)) >> PAGE_SHIFT);
>> else
>> return pte_pfn(*ptep);
>>
>> Something roughly like that, then you don't have to change any callers
>> or am I missing something?
>
> Here[1] you asked to return the real address rather than pfn, which all
> callers care about. So made the changes accordingly.
>
> [1] https://www.spinics.net/lists/kernel/msg3187658.html
Ah I did suggest it, but I meant _exact_ physical address :) The one
matching the effective address you gave it.
As it is now, the physical address is truncated at the small page size,
so if you do that you might as well just keep it as a pfn and no change
to callers.
I would also prefer getting the pfn as above rather than constructing a
new pte, which is a neat hack but is not a normal pattern.
Thanks,
Nick
[PATCH] ubifs: fix a memory leak bug
In read_znode(), the indexing node 'idx' is allocated by kmalloc().
However, it is not deallocated in the following execution if
ubifs_node_check_hash() fails, leading to a memory leak bug. To fix this
issue, free 'idx' before returning the error.
Signed-off-by: Wenwen Wang
---
fs/ubifs/tnc_misc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ubifs/tnc_misc.c b/fs/ubifs/tnc_misc.c
index 6f293f6..49cb34c 100644
--- a/fs/ubifs/tnc_misc.c
+++ b/fs/ubifs/tnc_misc.c
@@ -284,6 +284,7 @@ static int read_znode(struct ubifs_info *c, struct
ubifs_zbranch *zzbr,
err = ubifs_node_check_hash(c, idx, zzbr->hash);
if (err) {
ubifs_bad_hash(c, idx, zzbr->hash, lnum, offs);
+ kfree(idx);
return err;
}
--
2.7.4
[PATCH] Input: hyperv-keyboard: Use in-place iterator API in the channel callback
Simplify the ring buffer handling with the in-place API.
Also avoid the dynamic allocation and the memory leak in the channel
callback function.
Signed-off-by: Dexuan Cui
---
Hi Dmitry, can this patch go through Sasha's hyperv tree:
https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
This is a purely Hyper-V specific change.
drivers/input/serio/hyperv-keyboard.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/input/serio/hyperv-keyboard.c
b/drivers/input/serio/hyperv-keyboard.c
index 88ae7c2..e486a8a 100644
--- a/drivers/input/serio/hyperv-keyboard.c
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -237,40 +237,17 @@ static void hv_kbd_handle_received_packet(struct
hv_device *hv_dev,
static void hv_kbd_on_channel_callback(void *context)
{
+ struct vmpacket_descriptor *desc;
struct hv_device *hv_dev = context;
- void *buffer;
- int bufferlen = 0x100; /* Start with sensible size */
u32 bytes_recvd;
u64 req_id;
- int error;
- buffer = kmalloc(bufferlen, GFP_ATOMIC);
- if (!buffer)
- return;
-
- while (1) {
- error = vmbus_recvpacket_raw(hv_dev->channel, buffer, bufferlen,
-_recvd, _id);
- switch (error) {
- case 0:
- if (bytes_recvd == 0) {
- kfree(buffer);
- return;
- }
-
- hv_kbd_handle_received_packet(hv_dev, buffer,
- bytes_recvd, req_id);
- break;
+ foreach_vmbus_pkt(desc, hv_dev->channel) {
+ bytes_recvd = desc->len8 * 8;
+ req_id = desc->trans_id;
- case -ENOBUFS:
- kfree(buffer);
- /* Handle large packet */
- bufferlen = bytes_recvd;
- buffer = kmalloc(bytes_recvd, GFP_ATOMIC);
- if (!buffer)
- return;
- break;
- }
+ hv_kbd_handle_received_packet(hv_dev, desc, bytes_recvd,
+ req_id);
}
}
--
1.8.3.1
Re: [PATCH v2 0/9] Exynos Adaptive Supply Voltage support
On 19-08-19, 15:39, Sylwester Nawrocki wrote: > Unfortunately not, the patch set as I see it is another way of updating > an OPP after it was parsed from DT. OPP remove/add could work equally > well in our use case. Adding OPPs dynamically has limitations, you can't set many values which are otherwise possible with DT. And removing/adding is not the right thing to do technically. > The problem is that we have the information on how to translate the > common OPP voltage to a voltage specific to given silicon encoded jointly > in the ASV tables and the CHIPID registers (efuse/OTP memory). > Additionally, algorithm of selecting ASV data (OPP voltage) based on > the "key" data from registers is not generic, it is usually different > per each SoC type. > > I tried to identify some patterns in those tables in order to simplify > possible DT binding, but that was not really successful. I ended up just > keeping whole tables. Sorry but I am unable to understand the difficulty you are facing now. So what I suggest is something like this. - Use DT to get a frequency and voltage for each frequency. - At runtime, based on SoC, registers, efuses, etc, update the voltage of the OPPs. - This algo can be different for each SoC, no one is stopping you from doing that. Am I missing something ? -- viresh
Re: [PATCH 2/2 v2] mm/zsmalloc.c: Fix race condition in zs_destroy_pool
On (08/09/19 11:17), Henry Burns wrote:
> In zs_destroy_pool() we call flush_work(>free_work). However, we
> have no guarantee that migration isn't happening in the background
> at that time.
>
> Since migration can't directly free pages, it relies on free_work
> being scheduled to free the pages. But there's nothing preventing an
> in-progress migrate from queuing the work *after*
> zs_unregister_migration() has called flush_work(). Which would mean
> pages still pointing at the inode when we free it.
>
> Since we know at destroy time all objects should be free, no new
> migrations can come in (since zs_page_isolate() fails for fully-free
> zspages). This means it is sufficient to track a "# isolated zspages"
> count by class, and have the destroy logic ensure all such pages have
> drained before proceeding. Keeping that state under the class
> spinlock keeps the logic straightforward.
>
> Fixes: 48b4800a1c6a ("zsmalloc: page migration support")
> Signed-off-by: Henry Burns
Reviewed-by: Sergey Senozhatsky
+ Andrew
-ss
[PATCH] HID: hyperv: Use in-place iterator API in the channel callback
Simplify the ring buffer handling with the in-place API.
Also avoid the dynamic allocation and the memory leak in the channel
callback function.
Signed-off-by: Dexuan Cui
---
Hi Jiri, Benjamin, can this patch go through Sasha's hyperv tree:
https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
This is a purely Hyper-V specific change.
drivers/hid/hid-hyperv.c | 56 +---
1 file changed, 10 insertions(+), 46 deletions(-)
diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
index 7795831..f363163 100644
--- a/drivers/hid/hid-hyperv.c
+++ b/drivers/hid/hid-hyperv.c
@@ -314,60 +314,24 @@ static void mousevsc_on_receive(struct hv_device *device,
static void mousevsc_on_channel_callback(void *context)
{
- const int packet_size = 0x100;
- int ret;
struct hv_device *device = context;
- u32 bytes_recvd;
- u64 req_id;
struct vmpacket_descriptor *desc;
- unsigned char *buffer;
- int bufferlen = packet_size;
-
- buffer = kmalloc(bufferlen, GFP_ATOMIC);
- if (!buffer)
- return;
-
- do {
- ret = vmbus_recvpacket_raw(device->channel, buffer,
- bufferlen, _recvd, _id);
-
- switch (ret) {
- case 0:
- if (bytes_recvd <= 0) {
- kfree(buffer);
- return;
- }
- desc = (struct vmpacket_descriptor *)buffer;
-
- switch (desc->type) {
- case VM_PKT_COMP:
- break;
-
- case VM_PKT_DATA_INBAND:
- mousevsc_on_receive(device, desc);
- break;
-
- default:
- pr_err("unhandled packet type %d, tid %llx len
%d\n",
- desc->type, req_id, bytes_recvd);
- break;
- }
+ foreach_vmbus_pkt(desc, device->channel) {
+ switch (desc->type) {
+ case VM_PKT_COMP:
break;
- case -ENOBUFS:
- kfree(buffer);
- /* Handle large packet */
- bufferlen = bytes_recvd;
- buffer = kmalloc(bytes_recvd, GFP_ATOMIC);
-
- if (!buffer)
- return;
+ case VM_PKT_DATA_INBAND:
+ mousevsc_on_receive(device, desc);
+ break;
+ default:
+ pr_err("Unhandled packet type %d, tid %llx len %d\n",
+ desc->type, desc->trans_id, desc->len8 * 8);
break;
}
- } while (1);
-
+ }
}
static int mousevsc_connect_to_vsp(struct hv_device *device)
--
1.8.3.1
Re: [PATCH 1/2 v2] mm/zsmalloc.c: Migration can leave pages in ZS_EMPTY indefinitely
On (08/09/19 11:17), Henry Burns wrote:
> In zs_page_migrate() we call putback_zspage() after we have finished
> migrating all pages in this zspage. However, the return value is ignored.
> If a zs_free() races in between zs_page_isolate() and zs_page_migrate(),
> freeing the last object in the zspage, putback_zspage() will leave the page
> in ZS_EMPTY for potentially an unbounded amount of time.
>
> To fix this, we need to do the same thing as zs_page_putback() does:
> schedule free_work to occur. To avoid duplicated code, move the
> sequence to a new putback_zspage_deferred() function which both
> zs_page_migrate() and zs_page_putback() call.
>
> Fixes: 48b4800a1c6a ("zsmalloc: page migration support")
> Signed-off-by: Henry Burns
Reviewed-by: Sergey Senozhatsky
+ Andrew
-ss
Re: [PATCH v3 bpf-next 1/4] tracing/probe: Add PERF_EVENT_IOC_QUERY_PROBE ioctl
On Mon, Aug 19, 2019 at 7:34 PM Daniel Xu wrote: > > Ah yes, sorry. Will add that. Also please fix build errors. It looks like buildbot is not happy about few things.
[PATCH] mtd: rawnand: sharpsl: add include guard to linux/mtd/sharpsl.h
Add a header include guard just in case.
Signed-off-by: Masahiro Yamada
---
include/linux/mtd/sharpsl.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/mtd/sharpsl.h b/include/linux/mtd/sharpsl.h
index 01306ebe266d..d2c3cf29e0d1 100644
--- a/include/linux/mtd/sharpsl.h
+++ b/include/linux/mtd/sharpsl.h
@@ -5,6 +5,9 @@
* Copyright (C) 2008 Dmitry Baryshkov
*/
+#ifndef _MTD_SHARPSL_H
+#define _MTD_SHARPSL_H
+
#include
#include
#include
@@ -16,3 +19,5 @@ struct sharpsl_nand_platform_data {
unsigned intnr_partitions;
const char *const *part_parsers;
};
+
+#endif /* _MTD_SHARPSL_H */
--
2.17.1
Re: [PATCH v4 2/2] rcuperf: Add kfree_rcu() performance Tests
On Mon, Aug 19, 2019 at 07:51:23PM -0400, Joel Fernandes wrote:
> On Mon, Aug 19, 2019 at 03:23:30PM -0700, Paul E. McKenney wrote:
> [snip]
> > > [snip]
> > > > > @@ -592,6 +593,175 @@ rcu_perf_shutdown(void *arg)
> > > > > return -EINVAL;
> > > > > }
> > > > >
> > > > > +/*
> > > > > + * kfree_rcu performance tests: Start a kfree_rcu loop on all CPUs
> > > > > for number
> > > > > + * of iterations and measure total time and number of GP for all
> > > > > iterations to complete.
> > > > > + */
> > > > > +
> > > > > +torture_param(int, kfree_nthreads, -1, "Number of threads running
> > > > > loops of kfree_rcu().");
> > > > > +torture_param(int, kfree_alloc_num, 8000, "Number of allocations and
> > > > > frees done in an iteration.");
> > > > > +torture_param(int, kfree_loops, 10, "Number of loops doing
> > > > > kfree_alloc_num allocations and frees.");
> > > > > +torture_param(int, kfree_no_batch, 0, "Use the non-batching (slower)
> > > > > version of kfree_rcu.");
> > > > > +
> > > > > +static struct task_struct **kfree_reader_tasks;
> > > > > +static int kfree_nrealthreads;
> > > > > +static atomic_t n_kfree_perf_thread_started;
> > > > > +static atomic_t n_kfree_perf_thread_ended;
> > > > > +
> > > > > +struct kfree_obj {
> > > > > + char kfree_obj[8];
> > > > > + struct rcu_head rh;
> > > > > +};
> > > >
> > > > (Aside from above, no need to change this part of the patch, at least
> > > > not
> > > > that I know of at the moment.)
> > > >
> > > > 24 bytes on a 64-bit system, 16 on a 32-bit system. So there might
> > > > have been 10 million extra objects awaiting free in the batching case
> > > > given the 400M-50M=350M excess for the batching approach. If freeing
> > > > each object took about 100ns, that could account for the additional
> > > > wall-clock time for the batching approach.
> > >
> > > Makes sense, and this comes down to 200-220MB range with the additional
> > > list.
> >
> > Which might even match the observed numbers?
>
> Yes, they would. Since those *are* the observed numbers :-D ;-) ;-)
;-)
> > > > > + do {
> > > > > + for (i = 0; i < kfree_alloc_num; i++) {
> > > > > + alloc_ptrs[i] = kmalloc(sizeof(struct
> > > > > kfree_obj), GFP_KERNEL);
> > > > > + if (!alloc_ptrs[i])
> > > > > + return -ENOMEM;
> > > > > + }
> > > > > +
> > > > > + for (i = 0; i < kfree_alloc_num; i++) {
> > > > > + if (!kfree_no_batch) {
> > > > > + kfree_rcu(alloc_ptrs[i], rh);
> > > > > + } else {
> > > > > + rcu_callback_t cb;
> > > > > +
> > > > > + cb = (rcu_callback_t)(unsigned
> > > > > long)offsetof(struct kfree_obj, rh);
> > > > > +
> > > > > kfree_call_rcu_nobatch(&(alloc_ptrs[i]->rh), cb);
> > > > > + }
> > > > > + }
> > > >
> > > > The point of allocating a large batch and then kfree_rcu()ing them in a
> > > > loop is to defeat the per-CPU pool optimization? Either way, a comment
> > > > would be very good!
> > >
> > > It was a reasoning like this, added it as a comment:
> > >
> > > /* While measuring kfree_rcu() time, we also end up measuring kmalloc()
> > >* time. So the strategy here is to do a few (kfree_alloc_num) number
> > >* of kmalloc() and kfree_rcu() every loop so that the current loop's
> > >* deferred kfree()ing overlaps with the next loop's kmalloc().
> > >*/
> >
> > The thought being that the CPU will be executing the two loops
> > concurrently? Up to a point, agreed, but how much of an effect is
> > that, really?
>
> Yes it may not matter much. It was just a small thought when I added the
> loop, I had to start somewhere, so I did it this way.
>
> > Or is the idea to time the kfree_rcu() loop separately? (I don't see
> > any such separate timing, though.)
>
> The kmalloc() times are included within the kfree loop. The timing of
> kfree_rcu() is not separate in my patch.
You lost me on this one. What happens when you just interleave the
kmalloc() and kfree_rcu(), without looping, compared to the looping
above? Does this get more expensive? Cheaper? More vulnerable to OOM?
Something else?
Thanx, Paul
[PATCH v2 3/3] tools: hv: add vmbus testing tool
This is a userspace tool to drive the testing. Currently it supports
introducing user specified delay in the host to guest communication
path on a per-channel basis.
Signed-off-by: Branden Bonaby
---
Changes in v2:
- Move testing location to new location in debugfs.
tools/hv/vmbus_testing | 334 +
1 file changed, 334 insertions(+)
create mode 100644 tools/hv/vmbus_testing
diff --git a/tools/hv/vmbus_testing b/tools/hv/vmbus_testing
new file mode 100644
index ..f615009b7393
--- /dev/null
+++ b/tools/hv/vmbus_testing
@@ -0,0 +1,334 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0
+#
+#Program to allow users to fuzz test Hyper-V drivers
+#by interfacing with Hyper-V debugfs directories
+#author: Branden Bonaby
+
+import os
+import cmd
+import argparse
+from collections import defaultdict
+from argparse import RawDescriptionHelpFormatter
+
+#debugfs paths for vmbus must exist (same as in lsvmbus)
+debugfs_sys_path = '/sys/kernel/debug/hyperv'
+if not os.path.isdir(debugfs_sys_path):
+print("{} doesn't exist/check
permissions".format(debugfs_sys_path))
+exit(-1)
+#Do not change unless, you change the debugfs attributes
+#in "/sys/kernel/debug/hyperv//". All fuzz testing
+#attributes will start with "fuzz_test".
+pathlen = len(debugfs_sys_path)
+fuzz_state_location = "fuzz_test_state"
+fuzz_states = {0 : "Disable", 1 : "Enable"}
+fuzz_methods ={1 : "Delay_testing"}
+fuzz_delay_types = {1 : "fuzz_test_buffer_interrupt_delay", 2
:"fuzz_test_message_delay"}
+
+def parse_args():
+parser = argparse.ArgumentParser(description = "vmbus_testing "\
+"[-s] [0|1] [-q] [-p] \n""vmbus_testing [-s]"\
+" [0|1] [-q][-p] delay [-d] [val][val]
[-E|-D]\n"
+"vmbus_testing [-q] disable-all\n"
+"vmbus_testing [-q] view [-v|-V]\n"\
+"vmbus_testing --version",
+epilog = "Current testing options {}".format(fuzz_methods),
+prog = 'vmbus_testing',
+formatter_class = RawDescriptionHelpFormatter)
+subparsers = parser.add_subparsers(dest="action")
+parser.add_argument('--version', action='version',\
+version = '%(prog)s 1.0')
+parser.add_argument("-q","--quiet",action = "store_true",\
+help = "silence none important test messages")
+parser.add_argument("-s","--state",metavar = "", type = int,\
+choices = range(0,2),\
+help = "Turn testing ON or OFF for a single device."\
+" The value (1) will turn testing ON. The value"\
+" of (0) will turn testing OFF with the default set"\
+" to (0).")
+parser.add_argument("-p","--path", metavar = "",\
+help = "Refers to the debugfs path to a vmbus device."
+" If the path is not a valid path to a vmbus device,"\
+" the program will exit. The path must be the"\
+" absolute path; use the lsvmbus command to find"\
+" the path.")
+parser_delay = subparsers.add_parser("delay",\
+help = "Delay buffer/message reads in microseconds.",
+description = "vmbus_testing -s [0|1] [-q] -p "\
+" delay -d "\
+"[buffer-delay-value] [message-delay-value]\n"
+"vmbus_testing [-q] delay [buffer-delay-value] "\
+"[message-delay-value] -E\n"
+"vmbus_testing [-q] delay [buffer-delay-value] "\
+"[message-delay-value] -D",
+formatter_class = RawDescriptionHelpFormatter)
+delay_group = parser_delay.add_mutually_exclusive_group()
+delay_group.add_argument("-E","--en-all-delay", action = "store_true",\
+help = "Enable Buffer/Message Delay testing on ALL"\
+" devices. Use -d option with this to set the values"\
+" for both the buffer delay and the message delay. No"\
+" value can be (0) or less than (-1). If testing is"\
+" disabled on a device prior to running this command,"\
+" testing will be enabled on the device as a result"\
+" of this command.")
+delay_group.add_argument("-D","--dis-all-delay", action="store_true",\
+help = "Disable Buffer/Message delay testing on ALL"\
+" devices. A value equal to (-1) will keep the"\
+" current delay value, and a value equal to (0) will"\
+" remove delay testing for the specfied delay column."\
+"
[PATCH v2 2/3] drivers: hv: vmbus: add test attributes to debugfs
Expose the test parameters as part of the debugfs channel attributes.
We will control the testing state via these attributes.
Signed-off-by: Branden Bonaby
---
Changes in v2:
- Move test attributes to debugfs.
- Wrap test code under #ifdef statements.
- Add new documentation file under Documentation/ABI/testing.
- Make commit message reflect the change from from sysfs to debugfs.
Documentation/ABI/testing/debugfs-hyperv | 21 +++
MAINTAINERS | 1 +
drivers/hv/vmbus_drv.c | 167 +++
3 files changed, 189 insertions(+)
create mode 100644 Documentation/ABI/testing/debugfs-hyperv
diff --git a/Documentation/ABI/testing/debugfs-hyperv
b/Documentation/ABI/testing/debugfs-hyperv
new file mode 100644
index ..b25f751fafa8
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-hyperv
@@ -0,0 +1,21 @@
+What: /sys/kernel/debug/hyperv//fuzz_test_state
+Date: August 2019
+KernelVersion: 5.3
+Contact:Branden Bonaby
+Description:Fuzz testing status of a vmbus device, whether its in an ON
+state or a OFF state
+Users: Debugging tools
+
+What:
/sys/kernel/debug/hyperv//delay/fuzz_test_buffer_interrupt_delay
+Date: August 2019
+KernelVersion: 5.3
+Contact:Branden Bonaby
+Description:Fuzz testing buffer delay value between 0 - 1000
+Users: Debugging tools
+
+What: /sys/kernel/debug/hyperv//delay/fuzz_test_message_delay
+Date: August 2019
+KernelVersion: 5.3
+Contact:Branden Bonaby
+Description:Fuzz testing message delay value between 0 - 1000
+Users: Debugging tools
diff --git a/MAINTAINERS b/MAINTAINERS
index e81e60bd7c26..120284a8185f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7460,6 +7460,7 @@ F:include/uapi/linux/hyperv.h
F: include/asm-generic/mshyperv.h
F: tools/hv/
F: Documentation/ABI/stable/sysfs-bus-vmbus
+F: Documentation/ABI/testing/debugfs-hyperv
HYPERBUS SUPPORT
M: Vignesh Raghavendra
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index ebd35fc35290..b6d023ae9664 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -919,6 +919,10 @@ static void vmbus_device_release(struct device *device)
struct hv_device *hv_dev = device_to_hv_device(device);
struct vmbus_channel *channel = hv_dev->channel;
+#ifdef CONFIG_HYPERV_TESTING
+ hv_debug_rm_dev_dir(hv_dev);
+#endif /* CONFIG_HYPERV_TESTING */
+
mutex_lock(_connection.channel_mutex);
hv_process_channel_removal(channel);
mutex_unlock(_connection.channel_mutex);
@@ -1727,6 +1731,9 @@ int vmbus_device_register(struct hv_device
*child_device_obj)
pr_err("Unable to register primary channeln");
goto err_kset_unregister;
}
+#ifdef CONFIG_HYPERV_TESTING
+ hv_debug_add_dev_dir(child_device_obj);
+#endif /* CONFIG_HYPERV_TESTING */
return 0;
@@ -2086,6 +2093,159 @@ static void hv_crash_handler(struct pt_regs *regs)
hyperv_cleanup();
};
+#ifdef CONFIG_HYPERV_TESTING
+
+struct dentry *hv_root;
+
+static int hv_debugfs_delay_get(void *data, u64 *val)
+{
+ *val = *(u32 *)data;
+ return 0;
+}
+
+static int hv_debugfs_delay_set(void *data, u64 val)
+{
+ if (val >= 1 && val <= 1000)
+ *(u32 *)data = val;
+ /*Best to not use else statement here since we want
+* the delay to remain the same if val > 1000
+*/
+ else if (val <= 0)
+ *(u32 *)data = 0;
+ return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(hv_debugfs_delay_fops, hv_debugfs_delay_get,
+hv_debugfs_delay_set, "%llu\n");
+
+/* Setup delay files to store test values */
+int hv_debug_delay_files(struct hv_device *dev, struct dentry *root)
+{
+ struct vmbus_channel *channel = dev->channel;
+ char *buffer = "fuzz_test_buffer_interrupt_delay";
+ char *message = "fuzz_test_message_delay";
+ int *buffer_val = >fuzz_testing_interrupt_delay;
+ int *message_val = >fuzz_testing_message_delay;
+ struct dentry *buffer_file, *message_file;
+
+ buffer_file = debugfs_create_file(buffer, 0644, root,
+ buffer_val,
+ _debugfs_delay_fops);
+ if (IS_ERR(buffer_file)) {
+ pr_debug("debugfs_hyperv: file %s not created\n", buffer);
+ return PTR_ERR(buffer_file);
+ }
+
+ message_file = debugfs_create_file(message, 0644, root,
+ message_val,
+ _debugfs_delay_fops);
+ if (IS_ERR(message_file)) {
+ pr_debug("debugfs_hyperv: file %s not created\n", message);
+ return PTR_ERR(message_file);
+ }
+
+ return 0;
+}
+
+/* Setup test state value for vmbus device */
[PATCH v2 0/3] hv: vmbus: add fuzz testing to hv device
This patchset introduces a testing framework for Hyper-V drivers. This framework allows us to introduce delays in the packet receive path on a per-device basis. While the current code only supports introducing arbitrary delays in the host/guest communication path, we intend to expand this to support error injection in the future. Changes in v2: Patch 1: As per Vitaly's suggestion, wrapped the test code under an #ifdef and updated the Kconfig file, so that the test code will only be used when the config option is set to true. (default is false). Updated hyperv_vmbus header to contain new #ifdef with new new functions for the test code. Patch 2: Moved code from under sysfs to debugfs and wrapped it under the new ifdef. Updated MAINTAINERS file with new debugfs-hyperv file under the section for hyperv. Patch 3: Updated testing tool with new debugfs location. Branden Bonaby (3): drivers: hv: vmbus: Introduce latency testing drivers: hv: vmbus: add fuzz test attributes to debugfs tools: hv: add vmbus testing tool Documentation/ABI/testing/debugfs-hyperv | 21 ++ MAINTAINERS | 1 + drivers/hv/Kconfig | 7 + drivers/hv/connection.c | 3 + drivers/hv/hyperv_vmbus.h| 20 ++ drivers/hv/ring_buffer.c | 7 + drivers/hv/vmbus_drv.c | 167 include/linux/hyperv.h | 21 ++ tools/hv/vmbus_testing | 334 +++ 9 files changed, 581 insertions(+) create mode 100644 Documentation/ABI/testing/debugfs-hyperv create mode 100644 tools/hv/vmbus_testing -- 2.17.1
[PATCH v2 1/3] drivers: hv: vmbus: Introduce latency testing
Introduce user specified latency in the packet reception path.
Signed-off-by: Branden Bonaby
---
Changes in v2:
- Add #ifdef in Kconfig file so test code will not interfere
with non-test code.
- Move test code functions for delay to hyperv_vmbus header
file.
- Wrap test code under #ifdef statement.
drivers/hv/Kconfig| 7 +++
drivers/hv/connection.c | 3 +++
drivers/hv/hyperv_vmbus.h | 20
drivers/hv/ring_buffer.c | 7 +++
include/linux/hyperv.h| 21 +
5 files changed, 58 insertions(+)
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 9a59957922d4..d97437ba0626 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -29,4 +29,11 @@ config HYPERV_BALLOON
help
Select this option to enable Hyper-V Balloon driver.
+config HYPERV_TESTING
+bool "Hyper-V testing"
+default n
+depends on HYPERV && DEBUG_FS
+help
+ Select this option to enable Hyper-V vmbus testing.
+
endmenu
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 09829e15d4a0..c9c63a4033cd 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -357,6 +357,9 @@ void vmbus_on_event(unsigned long data)
trace_vmbus_on_event(channel);
+#ifdef CONFIG_HYPERV_TESTING
+ hv_debug_delay_test(channel, INTERRUPT_DELAY);
+#endif /* CONFIG_HYPERV_TESTING */
do {
void (*callback_fn)(void *);
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 362e70e9d145..edf14f596d8c 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -357,4 +357,24 @@ enum hvutil_device_state {
HVUTIL_DEVICE_DYING, /* driver unload is in progress */
};
+#ifdef CONFIG_HYPERV_TESTING
+#include
+#include
+#include
+#define TESTING "hyperv"
+
+enum delay {
+ INTERRUPT_DELAY = 0,
+ MESSAGE_DELAY = 1,
+};
+
+int hv_debug_delay_files(struct hv_device *dev, struct dentry *root);
+int hv_debug_add_dev_dir(struct hv_device *dev);
+void hv_debug_rm_dev_dir(struct hv_device *dev);
+void hv_debug_rm_all_dir(void);
+void hv_debug_set_dir_dentry(struct hv_device *dev, struct dentry *root);
+void hv_debug_delay_test(struct vmbus_channel *channel, enum delay delay_type);
+
+#endif /* CONFIG_HYPERV_TESTING */
+
#endif /* _HYPERV_VMBUS_H */
diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 9a03b163cbbd..51adda23b398 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -396,6 +396,10 @@ struct vmpacket_descriptor *hv_pkt_iter_first(struct
vmbus_channel *channel)
struct hv_ring_buffer_info *rbi = >inbound;
struct vmpacket_descriptor *desc;
+#ifdef CONFIG_HYPERV_TESTING
+ hv_debug_delay_test(channel, MESSAGE_DELAY);
+#endif /* CONFIG_HYPERV_TESTING */
+
if (hv_pkt_iter_avail(rbi) < sizeof(struct vmpacket_descriptor))
return NULL;
@@ -421,6 +425,9 @@ __hv_pkt_iter_next(struct vmbus_channel *channel,
u32 packetlen = desc->len8 << 3;
u32 dsize = rbi->ring_datasize;
+#ifdef CONFIG_HYPERV_TESTING
+ hv_debug_delay_test(channel, MESSAGE_DELAY);
+#endif /* CONFIG_HYPERV_TESTING */
/* bump offset to next potential packet */
rbi->priv_read_index += packetlen + VMBUS_PKT_TRAILER;
if (rbi->priv_read_index >= dsize)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 6256cc34c4a6..6bf8ef5c780c 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -926,6 +926,21 @@ struct vmbus_channel {
* full outbound ring buffer.
*/
u64 out_full_first;
+
+#ifdef CONFIG_HYPERV_TESTING
+ /* enabling/disabling fuzz testing on the channel (default is false)*/
+ bool fuzz_testing_state;
+
+ /* Interrupt delay will delay the guest from emptying the ring buffer
+* for a specific amount of time. The delay is in microseconds and will
+* be between 1 to a maximum of 1000, its default is 0 (no delay).
+* The Message delay will delay guest reading on a per message basis
+* in microseconds between 1 to 1000 with the default being 0
+* (no delay).
+*/
+ u32 fuzz_testing_interrupt_delay;
+ u32 fuzz_testing_message_delay;
+#endif /* CONFIG_HYPERV_TESTING */
};
static inline bool is_hvsock_channel(const struct vmbus_channel *c)
@@ -1166,6 +1181,12 @@ struct hv_device {
struct vmbus_channel *channel;
struct kset *channels_kset;
+
+#ifdef CONFIG_HYPERV_TESTING
+ /* place holder to keep track of the dir for hv device in debugfs */
+ struct dentry *debug_dir;
+#endif /* CONFIG_HYPERV_TESTING */
+
};
--
2.17.1
Re: [PATCH v2 1/1] arm64: dts: rockchip: Add support for TB-96AI board
Hi Mani,
Thanks for your review. Please see comments inline.
在 8/5/2019 19:28, Manivannan Sadhasivam 写道:
Hi Elon,
Thanks for the v2. Still the DT needs to be cleaned up a bit. I have tested this
patch on TB96-AI SOM/Carrier board and found that the USB ports are not working
at all! Do we need to change any switch settings?
Yes. The USB ports can not work. I have already added all USB related
setting. I tried
rockchip internel rk3399.dtsi and the USB ports can work, so I think the
cause is SoC related
setting difference in mainline kernel.
I can not figure it out for now, should I remove the usb related node in
this patch?
Comments are inline.
On Mon, Aug 05, 2019 at 09:57:55AM +0800, Elon Zhang wrote:
Add devicetree support for RK3399Pro TB-96AI board, one of
the 96Boards family.
The TB-96AI board is a 96Boards Compute SOM design, launched
by Linaro, Rockchip and Beiqicloud.
More information can be obtained from the following websites:
1.https://www.96boards.org/product/tb-96ai/
2.http://t.rock-chips.com/
3.http://www.beiqicloud.com/
This patch add basic node for the board and support booting up
to Fedora.
Signed-off-by: Elon Zhang
---
changes since v1:
- remove needless node
- using a standard LED formats for 96Boards
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399pro-tb-96ai.dts | 560 ++
2 files changed, 561 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 5f2687acbf94..3d6c8d4363b5 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -27,3 +27,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-tb-96ai.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
new file mode 100644
index ..767b37b854ba
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
@@ -0,0 +1,560 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+#include "rk3399pro.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ compatible = "beiqi,rk3399pro-tb-96ai", "rockchip,rk3399pro";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ xin32k: xin32k {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-output-names = "xin32k";
+ #clock-cells = <0>;
+ };
+
+ vcc5v0_sys: vccsys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ leds {
Still the LEDs are not defined as per the format I shared before...
I am not very sure what the format exactly is. Is the LEDs format below
right?
49 leds {
50 compatible = "gpio-leds";
51 pinctrl-names = "default";
52 pinctrl-0 = <_led1>,<_led2>,<_led3>;
53
54 user_led1 {
55 label = "green:user1";
56 gpios = < 5 GPIO_ACTIVE_HIGH>;
57 retain-state-suspended;
58 };
59
60 user_led2 {
61 label = "green:user2";
62 gpios = < 4 GPIO_ACTIVE_HIGH>;
63 retain-state-suspended;
64 };
65
66 user_led3 {
67 label = "green:user3";
68 gpios = < 3 GPIO_ACTIVE_HIGH>;
69 retain-state-suspended;
70 };
71 };
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_led1>,<_led2>,<_led3>;
+
+ work_led1 {
+ gpios = < 5 GPIO_ACTIVE_HIGH>;
+ label = "system_work_led1";
+ retain-state-suspended;
+ };
+
+ work_led2 {
+ gpios = < 4 GPIO_ACTIVE_HIGH>;
+ label = "system_work_led2";
+ retain-state-suspended;
+ };
+
+ work_led3 {
+ gpios = < 3 GPIO_ACTIVE_HIGH>;
+ label = "system_work_led3";
+ retain-state-suspended;
+ };
+ };
+};
+
+_l0 {
+ cpu-supply = <_cpu_l>;
+};
+
+_l1 {
+
Re: [PATCH v3 bpf-next 1/4] tracing/probe: Add PERF_EVENT_IOC_QUERY_PROBE ioctl
On Mon Aug 19, 2019 at 6:26 PM Alexei Starovoitov wrote:
> On Fri, Aug 16, 2019 at 3:33 PM Daniel Xu wrote:
> >
> > It's useful to know [uk]probe's nmissed and nhit stats. For example with
> > tracing tools, it's important to know when events may have been lost.
> > debugfs currently exposes a control file to get this information, but
> > it is not compatible with probes registered with the perf API.
> >
> > While bpf programs may be able to manually count nhit, there is no way
> > to gather nmissed. In other words, it is currently not possible to
> > retrieve information about FD-based probes.
> >
> > This patch adds a new ioctl that lets users query nmissed (as well as
> > nhit for completeness). We currently only add support for [uk]probes
> > but leave the possibility open for other probes like tracepoint.
> >
> > Signed-off-by: Daniel Xu
> ...
> > +int perf_kprobe_event_query(struct perf_event *event, void __user *info)
> > +{
> > + struct perf_event_query_probe __user *uquery = info;
> > + struct perf_event_query_probe query = {};
> > + struct trace_event_call *call = event->tp_event;
> > + struct trace_kprobe *tk = (struct trace_kprobe *)call->data;
> > + u64 ncopy;
> > +
> > + if (!capable(CAP_SYS_ADMIN))
> > + return -EPERM;
> > + if (copy_from_user(, uquery,
> > + offsetofend(struct perf_event_query_probe,
> > size)))
> > + return -EFAULT;
> > +
> > + ncopy = min_t(u64, query.size, sizeof(query));
> > + query.nhit = trace_kprobe_nhit(tk);
> > + query.nmissed = tk->rp.kp.nmissed;
> > +
> > + if (copy_to_user(uquery, , ncopy))
> > + return -EFAULT;
>
> shouldn't kernel update query.size before copying back?
> Otherwise how user space would know which fields
> were populated?
Ah yes, sorry. Will add that.
Re: [RFC PATCH 08/15] drivers/acrn: add VM memory management for ACRN char device
On 2019年08月19日 15:39, Dan Carpenter wrote: On Mon, Aug 19, 2019 at 01:32:54PM +0800, Zhao, Yakui wrote: In fact as this driver is mainly used for embedded IOT usage, it doesn't handle the complex cleanup when such error is encountered. Instead the clean up is handled in free_guest_vm. A use after free here seems like a potential security problem. Security matters for IoT... :( Thanks for pointing out the issue. The cleanup will be considered carefully. regards, dan carpenter
RE: [EXT] Re: [PATCH net-next 0/1] net: fec: add C45 MDIO read/write support
From: Andrew Lunn > On Mon, Aug 19, 2019 at 05:11:14PM +, Marco Hartmann wrote: > > As of yet, the Fast Ethernet Controller (FEC) driver only supports > > Clause 22 conform MDIO transactions. IEEE 802.3ae Clause 45 defines a > > modified MDIO protocol that uses a two staged access model in order to > > increase the address space. > > > > This patch adds support for Clause 45 conform MDIO read and write > > operations to the FEC driver. > > Hi Marco > > Do all versions of the FEC hardware support C45? Or do we need to make use > of the quirk support in this driver to just enable it for some revisions of > FEC? > > Thanks > Andrew i.MX legacy platforms like i.MX6/7 series, they doesn't support Write & Read Increment. But for i.MX8MQ/MM series, it support C45 full features like Write & Read Increment. For the patch itself, it doesn't support Write & Read Increment, so I think the patch doesn't need to add quirk support. Andy
Re: [RFC PATCH 15/15] drivers/acrn: add the support of offline SOS cpu
On 2019年08月19日 18:34, Dan Carpenter wrote:
On Fri, Aug 16, 2019 at 10:25:56AM +0800, Zhao Yakui wrote:
diff --git a/drivers/staging/acrn/acrn_dev.c b/drivers/staging/acrn/acrn_dev.c
index 0602125..6868003 100644
--- a/drivers/staging/acrn/acrn_dev.c
+++ b/drivers/staging/acrn/acrn_dev.c
@@ -588,6 +588,41 @@ static const struct file_operations fops = {
#define SUPPORT_HV_API_VERSION_MAJOR 1
#define SUPPORT_HV_API_VERSION_MINOR 0
+static ssize_t
+offline_cpu_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+#ifdef CONFIG_X86
+ u64 cpu, lapicid;
+
+ if (kstrtoull(buf, 0, ) < 0)
+ return -EINVAL;
Thanks for the review.
Make sense.
The error code will be preserved.
Preserve the error code.
ret = kstrtoull(buf, 0, );
if (ret)
return ret;
+
+ if (cpu_possible(cpu)) {
You can't pass unchecked cpu values to cpu_possible() or it results in
an out of bounds read if cpu is >= than nr_cpu_ids.
OK. It will add the check of "cpu < num_possibles_cpu()" to avoid the
out of bounds.
regards,
dan carpenter
Re: [PATCH V5 0/9] Fixes for vhost metadata acceleration
On 2019/8/20 上午5:08, Michael S. Tsirkin wrote: On Tue, Aug 13, 2019 at 04:12:49PM +0800, Jason Wang wrote: On 2019/8/12 下午5:49, Michael S. Tsirkin wrote: On Mon, Aug 12, 2019 at 10:44:51AM +0800, Jason Wang wrote: On 2019/8/11 上午1:52, Michael S. Tsirkin wrote: On Fri, Aug 09, 2019 at 01:48:42AM -0400, Jason Wang wrote: Hi all: This series try to fix several issues introduced by meta data accelreation series. Please review. Changes from V4: - switch to use spinlock synchronize MMU notifier with accessors Changes from V3: - remove the unnecessary patch Changes from V2: - use seqlck helper to synchronize MMU notifier with vhost worker Changes from V1: - try not use RCU to syncrhonize MMU notifier with vhost worker - set dirty pages after no readers - return -EAGAIN only when we find the range is overlapped with metadata Jason Wang (9): vhost: don't set uaddr for invalid address vhost: validate MMU notifier registration vhost: fix vhost map leak vhost: reset invalidate_count in vhost_set_vring_num_addr() vhost: mark dirty pages during map uninit vhost: don't do synchronize_rcu() in vhost_uninit_vq_maps() vhost: do not use RCU to synchronize MMU notifier with worker vhost: correctly set dirty pages in MMU notifiers callback vhost: do not return -EAGAIN for non blocking invalidation too early drivers/vhost/vhost.c | 202 +- drivers/vhost/vhost.h | 6 +- 2 files changed, 122 insertions(+), 86 deletions(-) This generally looks more solid. But this amounts to a significant overhaul of the code. At this point how about we revert 7f466032dc9e5a61217f22ea34b2df932786bbfc for this release, and then re-apply a corrected version for the next one? If possible, consider we've actually disabled the feature. How about just queued those patches for next release? Thanks Sorry if I was unclear. My idea is that 1. I revert the disabled code 2. You send a patch readding it with all the fixes squashed 3. Maybe optimizations on top right away? 4. We queue *that* for next and see what happens. And the advantage over the patchy approach is that the current patches are hard to review. E.g. it's not reasonable to ask RCU guys to review the whole of vhost for RCU usage but it's much more reasonable to ask about a specific patch. Ok. Then I agree to revert. Thanks Great, so please send the following: - revert - squashed and fixed patch Just to confirm, do you want me to send a single series or two? Thanks
Re: [PATCH 1/4] resource: add a not device managed request_free_mem_region variant
On Mon, Aug 19, 2019 at 06:28:30PM -0700, Dan Williams wrote: > > Previously we would loudly crash if someone passed NULL to > devm_request_free_mem_region(), but now it will silently work and the > result will leak. Perhaps this wants a: We'd still instantly crash due to the dev_name dereference, right?
RE: [EXT] Re: [v2 2/3] clk: ls1028a: Add clock driver for Display output interface
> -Original Message-
> From: Stephen Boyd
> Sent: 2019年8月20日 2:30
> To: devicet...@vger.kernel.org; linux-...@vger.kernel.org;
> linux-de...@linux.nxdi.nxp.com; linux-kernel@vger.kernel.org; Mark Rutland
> ; Michael Turquette ;
> Rob Herring ; Shawn Guo ; Wen
> He
> Cc: Leo Li ; liviu.du...@arm.com
> Subject: RE: [EXT] Re: [v2 2/3] clk: ls1028a: Add clock driver for Display
> output
> interface
>
> Caution: EXT Email
>
> Quoting Wen He (2019-08-19 00:30:49)
> > > Quoting Wen He (2019-08-15 03:16:12)
> > > > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
> > > > 801fa1cd0321..3c95d8ec31d4 100644
> > > > --- a/drivers/clk/Kconfig
> > > > +++ b/drivers/clk/Kconfig
> > > > @@ -223,6 +223,16 @@ config CLK_QORIQ
> > > > This adds the clock driver support for Freescale QorIQ
> platforms
> > > > using common clock framework.
> > > >
> > > > +config CLK_LS1028A_PLLDIG
> > > > +bool "Clock driver for LS1028A Display output"
> > > > + depends on (ARCH_LAYERSCAPE || COMPILE_TEST) && OF
> > >
> > > Where is the OF dependency to build anything? Doesn't this still
> > > compile without CONFIG_OF set?
> >
> > Yes, current included some APIs of the OF, like of_get_parent_name()
>
> And there isn't a stub API for of_get_parent_name when OF isn't defined?
You are right, should be remove OF dependency.
>
> > > > +
> > > > +static int plldig_clk_probe(struct platform_device *pdev) {
> > > > + struct clk_plldig *data;
> > > > + struct resource *mem;
> > > > + const char *parent_name;
> > > > + struct clk_init_data init = {};
> > > > + struct device *dev = >dev;
> > > > + int ret;
> > > > +
> > > > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > > > + if (!data)
> > > > + return -ENOMEM;
> > > > +
> > > > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > + data->regs = devm_ioremap_resource(dev, mem);
> > > > + if (IS_ERR(data->regs))
> > > > + return PTR_ERR(data->regs);
> > > > +
> > > > + init.name = dev->of_node->name;
> > > > + init.ops = _clk_ops;
> > > > + parent_name = of_clk_get_parent_name(dev->of_node, 0);
> > > > + init.parent_names = _name;
> > >
> > > Can you use the new way of specifying clk parents with the
> > > parent_data member of clk_init?
> >
> > Of course, but I don't understand why need recommend to use this member?
> > Is that the member parent_names will be discard in future?
> >
> > Here are definition of the clk-provider.h
> > /* Only one of the following three should be assigned */
> > const char * const *parent_names;
> > const struct clk_parent_data*parent_data;
> > const struct clk_hw **parent_hws;
> >
> > For PLLDIG, it only has one parent.
>
> Yes. Can you use clk_parent_data array and specify a DT index of 0 and some
> name that would go into "clock-names" in the .fw_name member?
OK, but .fw_name used for to registering clk, current it registered with fixed
clk in dts .
I think should be specify a DT index of 0 and specify the unique name for .name
member.
I found have two ways to specify:
1. declare clk_parent_data variable parent_data, and initialization with
clk_init_data, like this:
parent_data.name = of_clk_get_parent_name(dev->of_node, 0);
parent_data.index = 0;
init.name = dev->of_node->name;
init.ops = _clk_ops;
init.parent_data = _data;
init.num_parents = 1;
2. Or use a static const array for here? And put the unique name and index like
this.
static const struct clk_parent_data parent_data[] = {
{.name = "phy_27m", .index = 0},
};
After then initialization with macro CLK_HW_INIT_PARENTS_DATA?
Best Regards,
Wen
Re: [PATCH] kbuild: enable unused-function warnings for W= build with Clang
On Tue, Aug 20, 2019 at 01:58:26AM +0900, Masahiro Yamada wrote:
> Hi Nathan,
>
> On Tue, Aug 20, 2019 at 1:09 AM Nathan Chancellor
> wrote:
> >
> > On Mon, Aug 19, 2019 at 07:51:38PM +0900, Masahiro Yamada wrote:
> > > GCC and Clang have different policy for -Wunused-function; GCC does
> > > not report unused-function warnings at all for the functions marked
> > > as 'static inline'. Clang does report unused-function warnings if they
> > > are defined in source files instead of headers.
> > >
> > > We could use Clang for detecting unused functions, but it has been
> > > suppressed since commit abb2ea7dfd82 ("compiler, clang: suppress
> > > warning for unused static inline functions").
> > >
> > > So, we never notice left-over code if functions in .c files are
> > > marked as inline.
> > >
> > > Let's remove __maybe_unused from the inline macro. As always, it is
> > > not a good idea to sprinkle warnings for the normal build. So, these
> > > warnings will be shown for the W= build.
> > >
> > > If you contribute to code clean-up, please run "make CC=clang W=1"
> > > and check -Wunused-function warnings. You will find lots of unused
> > > functions.
> > >
> > > Some of them are false-positives because the call-sites are disabled
> > > by #ifdef. I do not like to abuse the inline keyword for suppressing
> > > unused-function warnings because it might affect the compiler's
> > > optimization. When I need to fix unused-functions warnings, I prefer
> > > adding #ifdef or __maybe_unused to function definitions.
> > >
> > > Signed-off-by: Masahiro Yamada
> >
> > So if I understand everything correctly, this change allows us to start
> > finding unused static inline functions with clang at W=1 but disables
> > -Wunused-function by default... I am not sure that is a good tradeoff
> > as I am pretty sure that W=1 is fairly noisy for clang although I
> > haven't checked lately. I'd argue most regular developers do not build
> > with W=1 meaning -Wunused-function generally will not be run with clang
> > at all, missing stuff like this:
>
>
> Try "git log --grep=W=1"
>
> Some people are making efforts to fix W=1 warnings.
> I believe somebody will start to remove unused static inline functions.
Yes, it could be a good way to get people involved with working with
clang.
>
>
>
> >
> > https://lore.kernel.org/lkml/20190523010235.GA105588@archlinux-epyc/
> >
> > https://lore.kernel.org/lkml/1558574945-19275-1-git-send-email-skomatin...@nvidia.com/
> >
> > Furthermore, per the documemtation [1], -Wno-unused-function will also
> > disable -Wunneeded-internal-declaration, which can help find bugs like
> > commit 8289c4b6f2e5 ("platform/x86: mlx-platform: Properly use
> > mlxplat_mlxcpld_msn201x_items").
> >
> > [1]: https://clang.llvm.org/docs/DiagnosticsReference.html#wunused-function
>
>
> How about this?
>
> KBUILD_CFLAGS += -Wno-unused-function
> KBUILD_CFLAGS += -Wunneeded-internal-declaration
Yes, that would work.
>
>
>
> > Is there a way to conditionally remove __maybe_unused from the inline
> > defintion so that we keep the current behavior but we can still
> > selectively find potentially unused functions?
>
> It would be possible by tweaking include/linux/compiler_types.h
> but I am not a big fan of uglifying the 'inline' replacement any more.
I agree that ugly is not ideal but I think it is even less ideal to
weaken the default set of warnings for clang... Merely food for thought
though.
Cheers,
Nathan
Re: [PATCH 4/4] memremap: provide a not device managed memremap_pages
On Sun, Aug 18, 2019 at 2:12 AM Christoph Hellwig wrote: > > The kvmppc ultravisor code wants a device private memory pool that is > system wide and not attached to a device. Instead of faking up one > provide a low-level memremap_pages for it. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Ira Weiny Looks good, Reviewed-by: Dan Williams
Re: [PATCH] scsi: lpfc: fix "NULL check before some freeing functions is not needed"
Hariprasad, > As dma_pool_destroy and mempool_destroy functions has NULL check. We may > not need NULL check before calling them. Applied to 5.4/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 3/4] memremap: don't use a separate devm action for devmap_managed_enable_get
On Sun, Aug 18, 2019 at 2:12 AM Christoph Hellwig wrote: > > Just clean up for early failures and then piggy back on > devm_memremap_pages_release. This helps with a pending not device > managed version of devm_memremap_pages. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Ira Weiny Looks good, Reviewed-by: Dan Williams
Re: [patch 03/44] posix-timer: Use a callback for cancel synchronization
> + if (!WARN_ON_ONCE(kc->timer_wait_running)) > + kc->timer_wait_running(timer); This looks weird. The only place calling yor new method only does so after checking that it is not set and actually warns if it set?
Re: [patch 00/44] posix-cpu-timers: Cleanup and consolidation
On Mon, Aug 19, 2019 at 04:31:41PM +0200, Thomas Gleixner wrote: > The series applies on top of: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core > > and is available from git as well: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.timers/core It seems like this basically reverts the last patch in timers/core again. Do you really want to keep that or start with a better baseline?
Re: [PATCH] ata: ahci: Lookup PCS register offset based on PCI device ID
On Mon, Aug 19, 2019 at 9:30 AM Stephen Douthit
wrote:
>
> On 8/14/19 1:17 PM, Dan Williams wrote:
> >> Can you get someone from the controller design team to give us a clear
> >> answer on a revision where this PCS change happened?
> >>
> >> It would be nice if we could just check PCI_REVISION_ID or something
> >> similar.
> >
> > I don't think such a reliable association with rev-id exists, the> intent
> > was that the OS need never consider PCS.
>
> Can you please ask to confirm? It would be a much simpler check if it
> is possible.
No. Even if it were accidentally the case today the Linux driver can't
trust that rev-id across the different implementations will be
maintained for this purpose because the OS driver is not meant to
touch this register. Just look at a sampling of rev-id from a few
different systems, and note that rev-id applies to the chipset not
just the ahci controller.
rev 08
rev 11
rev 31
...which one of those is Denverton?
The intent is that PCS is a platform-firmware concern and that any
software that cares about PCS is caring about it by explicit
identification.
> > The way Linux is using
> > it is already broken with the assumption that it is performed after
> > every HOST_CTL based reset which only resets mmio space. At most it
> > should only be required at initial PCI discovery iff platform firmware
> > failed to run.
>
> This is a separate issue.
>
> It's broken in the sense that the code is called more often that it
> needs to be, but reset isn't a hot path, and there are no side effects
> to doing this multiple times that I can see.
The problem is that there is no known need to do it for Denverton, and
likely more platform implementations.
> And as you point out, no
> bug reports, so pretty benign all things considered.
>
> We could move the PCS quirk code to ahci_init_one() to address this
> concern once there's agreement on what the criteria is to run/not-run
> this code.
>
> > There are no bug reports with the current
> > implementation that only attempts to enable bits based on PORTS_IMPL,
> > so I think we are firmer ground trying to draw a line where the driver
> > just stops worrying about PCS rather than try to detect the layout.
>
> Someone at Intel is going to need to decide where/how to draw this line.
This is a case of Linux touching a "BIOS only" register and assuming
that the quirk is widely applicable. I think a reasonable fix is to
just whitelist all the known Intel ids, apply the PCS fixup assuming
the legacy configuration register location, and stop applying the
quirk by default.
Here is a proposed patch along these lines. I can send a
non-whitespace damaged version if this approach looks acceptable:
---
>From f40a7f287c97cfba71393ccb592ba521e43d807b Mon Sep 17 00:00:00 2001
From: Dan Williams
Date: Mon, 19 Aug 2019 11:30:37 -0700
Subject: [PATCH] libata/ahci: Drop PCS quirk for Denverton and beyond
The Linux ahci driver has historically implemented a configuration fixup
for platforms / platform-firmware that fails to enable the ports prior
to OS hand-off at boot. The fixup was originally implemented way back
before ahci moved from drivers/scsi/ to drivers/ata/, and was updated in
2007 via commit 49f290903935 "ahci: update PCS programming". The quirk
sets a port-enable bitmap in the PCS register at offset 0x92.
This quirk could be applied generically up until the arrival of the
Denverton (DNV) platform. The DNV AHCI controller architecture supports
more than 6 ports and along with that the PCS register location and
format were updated to allow for more possible ports in the bitmap. DNV
AHCI expands the register to 32-bits and moves it to offset 0x94.
As it stands there are no known problem reports with existing Linux
trying to set bits at offset 0x92 which indicates that the quirk is not
applicable. Likely it is not applicable on a wider range of platforms,
but it is difficult to discern which platforms if any still depend on
the quirk.
Rather than try to fix the PCS quirk to consider the DNV register layout
instead require explicit opt-in. The assumption is that the OS driver
need not touch this register, and platforms can be added to a whitelist
when / if problematic platforms are found in the future. The list in
ahci_intel_pcs_quirk() is populated with all the current explicit
device-ids with the expectation that class-code based detection need not
apply the quirk.
Reported-by: Stephen Douthit
Cc: Christoph Hellwig
Signed-off-by: Dan Williams
---
drivers/ata/ahci.c | 211 +++--
1 file changed, 184 insertions(+), 27 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index f7652baa6337..ceb38d205e1b 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -623,30 +623,6 @@ static void ahci_pci_save_initial_config(struct
pci_dev *pdev,
ahci_save_initial_config(>dev, hpriv);
}
-static int ahci_pci_reset_controller(struct ata_host *host)
-{
- struct
[PATCH] clk: imx: pll14xx: avoid glitch when set rate
From: Peng Fan
According to PLL1443XA and PLL1416X spec,
"When BYPASS is 0 and RESETB is changed from 0 to 1, FOUT starts to
output unstable clock until lock time passes. PLL1416X/PLL1443XA may
generate a glitch at FOUT."
So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
In the end of set rate, BYPASS will be cleared.
Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk-pll14xx.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index b7213023b238..bd072556bc44 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -191,6 +191,10 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw,
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
+ /* Enable BYPASS */
+ tmp |= BYPASS_MASK;
+ writel(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -250,6 +254,10 @@ static int clk_pll1443x_set_rate(struct clk_hw *hw,
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
+ /* Enable BYPASS */
+ tmp |= BYPASS_MASK;
+ writel_relaxed(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
--
2.16.4
[PATCH v4 16/16] powerpc/configs: Enable secure guest support in pseries and ppc64 defconfigs
From: Ryan Grimm Enables running as a secure guest in platforms with an Ultravisor. Signed-off-by: Ryan Grimm Signed-off-by: Ram Pai Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/configs/ppc64_defconfig | 1 + arch/powerpc/configs/pseries_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index dc83fefa04f7..b250e6f5a7ca 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -29,6 +29,7 @@ CONFIG_DTL=y CONFIG_SCANLOG=m CONFIG_PPC_SMLPAR=y CONFIG_IBMEBUS=y +CONFIG_PPC_SVM=y CONFIG_PPC_MAPLE=y CONFIG_PPC_PASEMI=y CONFIG_PPC_PASEMI_IOMMU=y diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig index 38abc9c1770a..26126b4d4de3 100644 --- a/arch/powerpc/configs/pseries_defconfig +++ b/arch/powerpc/configs/pseries_defconfig @@ -42,6 +42,7 @@ CONFIG_DTL=y CONFIG_SCANLOG=m CONFIG_PPC_SMLPAR=y CONFIG_IBMEBUS=y +CONFIG_PPC_SVM=y # CONFIG_PPC_PMAC is not set CONFIG_RTAS_FLASH=m CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
[PATCH v4 15/16] Documentation/powerpc: Ultravisor API
From: Sukadev Bhattiprolu POWER9 processor includes support for Protected Execution Facility (PEF). Attached documentation provides an overview of PEF and defines the API for various interfaces that must be implemented in the Ultravisor firmware as well as in the KVM Hypervisor. Based on input from Mike Anderson, Thiago Bauermann, Claudio Carvalho, Ben Herrenschmidt, Guerney Hunt, Paul Mackerras. Signed-off-by: Sukadev Bhattiprolu Signed-off-by: Ram Pai Signed-off-by: Guerney Hunt Reviewed-by: Claudio Carvalho Reviewed-by: Michael Anderson Reviewed-by: Thiago Bauermann Signed-off-by: Claudio Carvalho Signed-off-by: Thiago Jung Bauermann --- Documentation/powerpc/ultravisor.rst | 1055 ++ 1 file changed, 1055 insertions(+) diff --git a/Documentation/powerpc/ultravisor.rst b/Documentation/powerpc/ultravisor.rst new file mode 100644 index ..8d5246585b66 --- /dev/null +++ b/Documentation/powerpc/ultravisor.rst @@ -0,0 +1,1055 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. _ultravisor: + + +Protected Execution Facility + + +.. contents:: +:depth: 3 + +.. sectnum:: +:depth: 3 + +Protected Execution Facility + + +Protected Execution Facility (PEF) is an architectural change for +POWER 9 that enables Secure Virtual Machines (SVMs). When enabled, +PEF adds a new higher privileged mode, called Ultravisor mode, to +POWER architecture. Along with the new mode there is new firmware +called the Protected Execution Ultravisor (or Ultravisor for short). +Ultravisor mode is the highest privileged mode in POWER architecture. + + +--+ + | Privilege States | + +==+ + | Problem | + +--+ + | Supervisor | + +--+ + | Hypervisor | + +--+ + | Ultravisor | + +--+ + +PEF protects SVMs from the hypervisor, privileged users, and other +VMs in the system. SVMs are protected while at rest and can only be +executed by an authorized machine. All virtual machines utilize +hypervisor services. The Ultravisor filters calls between the SVMs +and the hypervisor to assure that information does not accidentally +leak. All hypercalls except H_RANDOM are reflected to the hypervisor. +H_RANDOM is not reflected to prevent the hypervisor from influencing +random values in the SVM. + +To support this there is a refactoring of the ownership of resources +in the CPU. Some of the resources which were previously hypervisor +privileged are now ultravisor privileged. + +Hardware + + +The hardware changes include the following: + +* There is a new bit in the MSR that determines whether the current + process is running in secure mode, MSR(S) bit 41. MSR(S)=1, process + is in secure mode, MSR(s)=0 process is in normal mode. + +* The MSR(S) bit can only be set by the Ultravisor. + +* HRFID cannot be used to set the MSR(S) bit. If the hypervisor needs + to return to a SVM it must use an ultracall. It can determine if + the VM it is returning to is secure. + +* There is a new Ultravisor privileged register, SMFCTRL, which has an + enable/disable bit SMFCTRL(E). + +* The privilege of a process is now determined by three MSR bits, + MSR(S, HV, PR). In each of the tables below the modes are listed + from least privilege to highest privilege. The higher privilege + modes can access all the resources of the lower privilege modes. + + **Secure Mode MSR Settings** + + +---+---+---+---+ + | S | HV| PR|Privilege | + +===+===+===+===+ + | 1 | 0 | 1 | Problem | + +---+---+---+---+ + | 1 | 0 | 0 | Privileged(OS)| + +---+---+---+---+ + | 1 | 1 | 0 | Ultravisor| + +---+---+---+---+ + | 1 | 1 | 1 | Reserved | + +---+---+---+---+ + + **Normal Mode MSR Settings** + + +---+---+---+---+ + | S | HV| PR|Privilege | + +===+===+===+===+ + | 0 | 0 | 1 | Problem | + +---+---+---+---+ + | 0 | 0 | 0 | Privileged(OS)| + +---+---+---+---+ + | 0 | 1 | 0 | Hypervisor| + +---+---+---+---+ + | 0 | 1 | 1 | Problem (HV) | + +---+---+---+---+ + +* Memory is partitioned into secure and normal memory. Only processes + that are running in secure mode can access secure memory. + +* The hardware does not allow anything that is not running secure to + access secure memory. This means that the Hypervisor cannot access + the memory of the SVM without using an ultracall (asking the + Ultravisor). The Ultravisor will only
[RFC PATCH v4 11/16] powerpc/pseries/svm: Export guest SVM status to user space via sysfs
From: Ryan Grimm
User space might want to know it's running in a secure VM. It can't do
a mfmsr because mfmsr is a privileged instruction.
The solution here is to create a cpu attribute:
/sys/devices/system/cpu/svm
which will read 0 or 1 based on the S bit of the current CPU.
Signed-off-by: Ryan Grimm
Signed-off-by: Thiago Jung Bauermann
---
.../ABI/testing/sysfs-devices-system-cpu | 10 ++
arch/powerpc/kernel/sysfs.c | 20 +++
2 files changed, 30 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu
b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 5f7d7b14fa44..06d0931119cc 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -562,3 +562,13 @@ Description: Umwait control
or C0.2 state. The time is an unsigned 32-bit number.
Note that a value of zero means there is no limit.
Low order two bits must be zero.
+
+What: /sys/devices/system/cpu/svm
+Date: August 2019
+Contact: Linux kernel mailing list
+ Linux for PowerPC mailing list
+Description: Secure Virtual Machine
+
+ If 1, it means the system is using the Protected Execution
+ Facility in POWER9 and newer processors. i.e., it is a Secure
+ Virtual Machine.
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index e2147d7c9e72..80a676da11cb 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "cacheinfo.h"
#include "setup.h"
@@ -715,6 +716,23 @@ static struct device_attribute pa6t_attrs[] = {
#endif /* HAS_PPC_PMC_PA6T */
#endif /* HAS_PPC_PMC_CLASSIC */
+#ifdef CONFIG_PPC_SVM
+static ssize_t show_svm(struct device *dev, struct device_attribute *attr,
char *buf)
+{
+ return sprintf(buf, "%u\n", is_secure_guest());
+}
+static DEVICE_ATTR(svm, 0444, show_svm, NULL);
+
+static void create_svm_file(void)
+{
+ device_create_file(cpu_subsys.dev_root, _attr_svm);
+}
+#else
+static void create_svm_file(void)
+{
+}
+#endif /* CONFIG_PPC_SVM */
+
static int register_cpu_online(unsigned int cpu)
{
struct cpu *c = _cpu(cpu_devices, cpu);
@@ -1058,6 +1076,8 @@ static int __init topology_init(void)
sysfs_create_dscr_default();
#endif /* CONFIG_PPC64 */
+ create_svm_file();
+
return 0;
}
subsys_initcall(topology_init);
[PATCH v4 12/16] powerpc/pseries/svm: Disable doorbells in SVM guests
From: Sukadev Bhattiprolu
Normally, the HV emulates some instructions like MSGSNDP, MSGCLRP
from a KVM guest. To emulate the instructions, it must first read
the instruction from the guest's memory and decode its parameters.
However for a secure guest (aka SVM), the page containing the
instruction is in secure memory and the HV cannot access directly.
It would need the Ultravisor (UV) to facilitate accessing the
instruction and parameters but the UV currently does not have
the support for such accesses.
Until the UV has such support, disable doorbells in SVMs. This might
incur a performance hit but that is yet to be quantified.
With this patch applied (needed only in SVMs not needed for HV) we
are able to launch SVM guests with multi-core support. Eg:
qemu -smp sockets=2,cores=2,threads=2.
Fix suggested by Benjamin Herrenschmidt. Thanks to input from
Paul Mackerras, Ram Pai and Michael Anderson.
Signed-off-by: Sukadev Bhattiprolu
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/platforms/pseries/smp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index 4b3ef8d9c63f..ad61e90032da 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include "pseries.h"
#include "offline_states.h"
@@ -221,7 +222,7 @@ static __init void pSeries_smp_probe_xics(void)
{
xics_smp_probe();
- if (cpu_has_feature(CPU_FTR_DBELL))
+ if (cpu_has_feature(CPU_FTR_DBELL) && !is_secure_guest())
smp_ops->cause_ipi = smp_pseries_cause_ipi;
else
smp_ops->cause_ipi = icp_ops->cause_ipi;
[PATCH v4 14/16] powerpc/pseries/svm: Force SWIOTLB for secure guests
From: Anshuman Khandual
SWIOTLB checks range of incoming CPU addresses to be bounced and sees if
the device can access it through its DMA window without requiring bouncing.
In such cases it just chooses to skip bouncing. But for cases like secure
guests on powerpc platform all addresses need to be bounced into the shared
pool of memory because the host cannot access it otherwise. Hence the need
to do the bouncing is not related to device's DMA window and use of bounce
buffers is forced by setting swiotlb_force.
Also, connect the shared memory conversion functions into the
ARCH_HAS_MEM_ENCRYPT hooks and call swiotlb_update_mem_attributes() to
convert SWIOTLB's memory pool to shared memory.
Signed-off-by: Anshuman Khandual
[ bauerman: Use ARCH_HAS_MEM_ENCRYPT hooks to share swiotlb memory pool. ]
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/mem_encrypt.h | 26 +++
arch/powerpc/platforms/pseries/Kconfig | 3 ++
arch/powerpc/platforms/pseries/svm.c | 45 ++
3 files changed, 74 insertions(+)
diff --git a/arch/powerpc/include/asm/mem_encrypt.h
b/arch/powerpc/include/asm/mem_encrypt.h
new file mode 100644
index ..ba9dab07c1be
--- /dev/null
+++ b/arch/powerpc/include/asm/mem_encrypt.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * SVM helper functions
+ *
+ * Copyright 2018 IBM Corporation
+ */
+
+#ifndef _ASM_POWERPC_MEM_ENCRYPT_H
+#define _ASM_POWERPC_MEM_ENCRYPT_H
+
+#include
+
+static inline bool mem_encrypt_active(void)
+{
+ return is_secure_guest();
+}
+
+static inline bool force_dma_unencrypted(struct device *dev)
+{
+ return is_secure_guest();
+}
+
+int set_memory_encrypted(unsigned long addr, int numpages);
+int set_memory_decrypted(unsigned long addr, int numpages);
+
+#endif /* _ASM_POWERPC_MEM_ENCRYPT_H */
diff --git a/arch/powerpc/platforms/pseries/Kconfig
b/arch/powerpc/platforms/pseries/Kconfig
index d09deb05bb66..9e35cf73 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -149,6 +149,9 @@ config PAPR_SCM
config PPC_SVM
bool "Secure virtual machine (SVM) support for POWER"
depends on PPC_PSERIES
+ select SWIOTLB
+ select ARCH_HAS_MEM_ENCRYPT
+ select ARCH_HAS_FORCE_DMA_UNENCRYPTED
help
There are certain POWER platforms which support secure guests using
the Protected Execution Facility, with the help of an Ultravisor
diff --git a/arch/powerpc/platforms/pseries/svm.c
b/arch/powerpc/platforms/pseries/svm.c
index 2b2b1a77ca1e..40c0637203d5 100644
--- a/arch/powerpc/platforms/pseries/svm.c
+++ b/arch/powerpc/platforms/pseries/svm.c
@@ -7,8 +7,53 @@
*/
#include
+#include
+#include
+#include
#include
+static int __init init_svm(void)
+{
+ if (!is_secure_guest())
+ return 0;
+
+ /* Don't release the SWIOTLB buffer. */
+ ppc_swiotlb_enable = 1;
+
+ /*
+* Since the guest memory is inaccessible to the host, devices always
+* need to use the SWIOTLB buffer for DMA even if dma_capable() says
+* otherwise.
+*/
+ swiotlb_force = SWIOTLB_FORCE;
+
+ /* Share the SWIOTLB buffer with the host. */
+ swiotlb_update_mem_attributes();
+
+ return 0;
+}
+machine_early_initcall(pseries, init_svm);
+
+int set_memory_encrypted(unsigned long addr, int numpages)
+{
+ if (!PAGE_ALIGNED(addr))
+ return -EINVAL;
+
+ uv_unshare_page(PHYS_PFN(__pa(addr)), numpages);
+
+ return 0;
+}
+
+int set_memory_decrypted(unsigned long addr, int numpages)
+{
+ if (!PAGE_ALIGNED(addr))
+ return -EINVAL;
+
+ uv_share_page(PHYS_PFN(__pa(addr)), numpages);
+
+ return 0;
+}
+
/* There's one dispatch log per CPU. */
#define NR_DTL_PAGE (DISPATCH_LOG_BYTES * CONFIG_NR_CPUS / PAGE_SIZE)
[PATCH v4 09/16] powerpc/pseries/svm: Use shared memory for Debug Trace Log (DTL)
From: Anshuman Khandual
Secure guests need to share the DTL buffers with the hypervisor. To that
end, use a kmem_cache constructor which converts the underlying buddy
allocated SLUB cache pages into shared memory.
Signed-off-by: Anshuman Khandual
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/svm.h | 5
arch/powerpc/platforms/pseries/Makefile | 1 +
arch/powerpc/platforms/pseries/setup.c | 5 +++-
arch/powerpc/platforms/pseries/svm.c| 40 +
4 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/svm.h b/arch/powerpc/include/asm/svm.h
index 2689d8d841f8..85580b30aba4 100644
--- a/arch/powerpc/include/asm/svm.h
+++ b/arch/powerpc/include/asm/svm.h
@@ -15,6 +15,9 @@ static inline bool is_secure_guest(void)
return mfmsr() & MSR_S;
}
+void dtl_cache_ctor(void *addr);
+#define get_dtl_cache_ctor() (is_secure_guest() ? dtl_cache_ctor : NULL)
+
#else /* CONFIG_PPC_SVM */
static inline bool is_secure_guest(void)
@@ -22,5 +25,7 @@ static inline bool is_secure_guest(void)
return false;
}
+#define get_dtl_cache_ctor() NULL
+
#endif /* CONFIG_PPC_SVM */
#endif /* _ASM_POWERPC_SVM_H */
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index ab3d59aeacca..a420ef4c9d8e 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_IBMVIO) += vio.o
obj-$(CONFIG_IBMEBUS) += ibmebus.o
obj-$(CONFIG_PAPR_SCM) += papr_scm.o
obj-$(CONFIG_PPC_SPLPAR) += vphn.o
+obj-$(CONFIG_PPC_SVM) += svm.o
ifdef CONFIG_PPC_PSERIES
obj-$(CONFIG_SUSPEND) += suspend.o
diff --git a/arch/powerpc/platforms/pseries/setup.c
b/arch/powerpc/platforms/pseries/setup.c
index f5940cc71c37..d8930c3a8a11 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -69,6 +69,7 @@
#include
#include
#include
+#include
#include "pseries.h"
#include "../../../../drivers/pci/pci.h"
@@ -297,8 +298,10 @@ static inline int alloc_dispatch_logs(void)
static int alloc_dispatch_log_kmem_cache(void)
{
+ void (*ctor)(void *) = get_dtl_cache_ctor();
+
dtl_cache = kmem_cache_create("dtl", DISPATCH_LOG_BYTES,
- DISPATCH_LOG_BYTES, 0, NULL);
+ DISPATCH_LOG_BYTES, 0, ctor);
if (!dtl_cache) {
pr_warn("Failed to create dispatch trace log buffer cache\n");
pr_warn("Stolen time statistics will be unreliable\n");
diff --git a/arch/powerpc/platforms/pseries/svm.c
b/arch/powerpc/platforms/pseries/svm.c
new file mode 100644
index ..2b2b1a77ca1e
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/svm.c
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Secure VM platform
+ *
+ * Copyright 2018 IBM Corporation
+ * Author: Anshuman Khandual
+ */
+
+#include
+#include
+
+/* There's one dispatch log per CPU. */
+#define NR_DTL_PAGE (DISPATCH_LOG_BYTES * CONFIG_NR_CPUS / PAGE_SIZE)
+
+static struct page *dtl_page_store[NR_DTL_PAGE];
+static long dtl_nr_pages;
+
+static bool is_dtl_page_shared(struct page *page)
+{
+ long i;
+
+ for (i = 0; i < dtl_nr_pages; i++)
+ if (dtl_page_store[i] == page)
+ return true;
+
+ return false;
+}
+
+void dtl_cache_ctor(void *addr)
+{
+ unsigned long pfn = PHYS_PFN(__pa(addr));
+ struct page *page = pfn_to_page(pfn);
+
+ if (!is_dtl_page_shared(page)) {
+ dtl_page_store[dtl_nr_pages] = page;
+ dtl_nr_pages++;
+ WARN_ON(dtl_nr_pages >= NR_DTL_PAGE);
+ uv_share_page(pfn, 1);
+ }
+}
[PATCH v4 13/16] powerpc/pseries/iommu: Don't use dma_iommu_ops on secure guests
Secure guest memory is inacessible to devices so regular DMA isn't possible. In that case set devices' dma_map_ops to NULL so that the generic DMA code path will use SWIOTLB to bounce buffers for DMA. Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/platforms/pseries/iommu.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c index 889dc2e44b89..8d9c2b17ad54 100644 --- a/arch/powerpc/platforms/pseries/iommu.c +++ b/arch/powerpc/platforms/pseries/iommu.c @@ -36,6 +36,7 @@ #include #include #include +#include #include "pseries.h" @@ -1318,7 +1319,15 @@ void iommu_init_early_pSeries(void) of_reconfig_notifier_register(_reconfig_nb); register_memory_notifier(_mem_nb); - set_pci_dma_ops(_iommu_ops); + /* +* Secure guest memory is inacessible to devices so regular DMA isn't +* possible. +* +* In that case keep devices' dma_map_ops as NULL so that the generic +* DMA code path will use SWIOTLB to bounce buffers for DMA. +*/ + if (!is_secure_guest()) + set_pci_dma_ops(_iommu_ops); } static int __init disable_multitce(char *str)
Re: [PATCH 4/4] arm64: implement KPROBES_ON_FTRACE
On Mon, 19 Aug 2019 22:22:12 +0530 "Naveen N. Rao" wrote: > > > Jisheng Zhang wrote: > > This patch implements KPROBES_ON_FTRACE for arm64. > > > > ~ # mount -t debugfs debugfs /sys/kernel/debug/ > > ~ # cd /sys/kernel/debug/ > > /sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events > > > > before the patch: > > > > /sys/kernel/debug # cat kprobes/list > > ff801009ff7c k _do_fork+0x4[DISABLED] > > This looks wrong -- we should not be allowing kprobe to be registered on Yes. I made a mistake when dumping this log. The kernel isn't as clean as "before the patch". > ftrace address without KPROBES_ON_FTRACE. Is _do_fork+0x4 the location > of ftrace entry on arm64? Indeed, w/o KPROBES_ON_FTRACE, it should be _do_fork+0x0 Thanks
[PATCH v4 01/16] powerpc/kernel: Add ucall_norets() ultravisor call handler
From: Claudio Carvalho
The ultracalls (ucalls for short) allow the Secure Virtual Machines
(SVM)s and hypervisor to request services from the ultravisor such as
accessing a register or memory region that can only be accessed when
running in ultravisor-privileged mode.
This patch adds the ucall_norets() ultravisor call handler. Like
plpar_hcall_norets(), it also saves and restores the Condition
Register (CR).
The specific service needed from an ucall is specified in register
R3 (the first parameter to the ucall). Other parameters to the
ucall, if any, are specified in registers R4 through R12.
Return value of all ucalls is in register R3. Other output values
from the ucall, if any, are returned in registers R4 through R12.
Each ucall returns specific error codes, applicable in the context
of the ucall. However, like with the PowerPC Architecture Platform
Reference (PAPR), if no specific error code is defined for a particular
situation, then the ucall will fallback to an erroneous
parameter-position based code. i.e U_PARAMETER, U_P2, U_P3 etc depending
on the ucall parameter that may have caused the error.
Every host kernel (powernv) needs to be able to do ucalls in case it
ends up being run in a machine with ultravisor enabled. Otherwise, the
kernel may crash early in boot trying to access ultravisor resources,
for instance, trying to set the partition table entry 0. Secure guests
also need to be able to do ucalls and its kernel may not have
CONFIG_PPC_POWERNV=y. For that reason, the ucall.S file is placed under
arch/powerpc/kernel.
If ultravisor is not enabled, the ucalls will be redirected to the
hypervisor which must handle/fail the call.
Thanks to inputs from Ram Pai and Michael Anderson.
Signed-off-by: Claudio Carvalho
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/asm-prototypes.h | 11 +++
arch/powerpc/include/asm/ultravisor-api.h | 23 +++
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/ucall.S | 20
4 files changed, 55 insertions(+)
diff --git a/arch/powerpc/include/asm/asm-prototypes.h
b/arch/powerpc/include/asm/asm-prototypes.h
index ec1c97a8e8cb..e698f48cbc6d 100644
--- a/arch/powerpc/include/asm/asm-prototypes.h
+++ b/arch/powerpc/include/asm/asm-prototypes.h
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
@@ -34,6 +35,16 @@ extern struct static_key hcall_tracepoint_key;
void __trace_hcall_entry(unsigned long opcode, unsigned long *args);
void __trace_hcall_exit(long opcode, long retval, unsigned long *retbuf);
+/* Ultravisor */
+#ifdef CONFIG_PPC_POWERNV
+long ucall_norets(unsigned long opcode, ...);
+#else
+static inline long ucall_norets(unsigned long opcode, ...)
+{
+ return U_NOT_AVAILABLE;
+}
+#endif
+
/* OPAL */
int64_t __opal_call(int64_t a0, int64_t a1, int64_t a2, int64_t a3,
int64_t a4, int64_t a5, int64_t a6, int64_t a7,
diff --git a/arch/powerpc/include/asm/ultravisor-api.h
b/arch/powerpc/include/asm/ultravisor-api.h
new file mode 100644
index ..88ffa78f9d61
--- /dev/null
+++ b/arch/powerpc/include/asm/ultravisor-api.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Ultravisor API.
+ *
+ * Copyright 2019, IBM Corporation.
+ *
+ */
+#ifndef _ASM_POWERPC_ULTRAVISOR_API_H
+#define _ASM_POWERPC_ULTRAVISOR_API_H
+
+#include
+
+/* Return codes */
+#define U_FUNCTION H_FUNCTION
+#define U_NOT_AVAILABLEH_NOT_AVAILABLE
+#define U_P2 H_P2
+#define U_P3 H_P3
+#define U_P4 H_P4
+#define U_P5 H_P5
+#define U_PARAMETERH_PARAMETER
+#define U_SUCCESS H_SUCCESS
+
+#endif /* _ASM_POWERPC_ULTRAVISOR_API_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index ea0c69236789..c6c4ea240b2a 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -156,6 +156,7 @@ endif
obj-$(CONFIG_EPAPR_PARAVIRT) += epapr_paravirt.o epapr_hcalls.o
obj-$(CONFIG_KVM_GUEST)+= kvm.o kvm_emul.o
+obj-$(CONFIG_PPC_POWERNV) += ucall.o
# Disable GCOV, KCOV & sanitizers in odd or sensitive code
GCOV_PROFILE_prom_init.o := n
diff --git a/arch/powerpc/kernel/ucall.S b/arch/powerpc/kernel/ucall.S
new file mode 100644
index ..de9133e45d21
--- /dev/null
+++ b/arch/powerpc/kernel/ucall.S
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Generic code to perform an ultravisor call.
+ *
+ * Copyright 2019, IBM Corporation.
+ *
+ */
+#include
+#include
+
+_GLOBAL(ucall_norets)
+EXPORT_SYMBOL_GPL(ucall_norets)
+ mfcrr0
+ stw r0,8(r1)
+
+ sc 2 /* Invoke the ultravisor */
+
+ lwz r0,8(r1)
+ mtcrf 0xff,r0
+ blr /* Return r3 = status */
[PATCH v4 08/16] powerpc/pseries/svm: Use shared memory for LPPACA structures
From: Anshuman Khandual
LPPACA structures need to be shared with the host. Hence they need to be in
shared memory. Instead of allocating individual chunks of memory for a
given structure from memblock, a contiguous chunk of memory is allocated
and then converted into shared memory. Subsequent allocation requests will
come from the contiguous chunk which will be always shared memory for all
structures.
While we are able to use a kmem_cache constructor for the Debug Trace Log,
LPPACAs are allocated very early in the boot process (before SLUB is
available) so we need to use a simpler scheme here.
Introduce helper is_svm_platform() which uses the S bit of the MSR to tell
whether we're running as a secure guest.
Signed-off-by: Anshuman Khandual
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/svm.h | 26
arch/powerpc/kernel/paca.c | 43 +-
2 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/svm.h b/arch/powerpc/include/asm/svm.h
new file mode 100644
index ..2689d8d841f8
--- /dev/null
+++ b/arch/powerpc/include/asm/svm.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * SVM helper functions
+ *
+ * Copyright 2018 Anshuman Khandual, IBM Corporation.
+ */
+
+#ifndef _ASM_POWERPC_SVM_H
+#define _ASM_POWERPC_SVM_H
+
+#ifdef CONFIG_PPC_SVM
+
+static inline bool is_secure_guest(void)
+{
+ return mfmsr() & MSR_S;
+}
+
+#else /* CONFIG_PPC_SVM */
+
+static inline bool is_secure_guest(void)
+{
+ return false;
+}
+
+#endif /* CONFIG_PPC_SVM */
+#endif /* _ASM_POWERPC_SVM_H */
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 612fc87ef785..949eceb254d8 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include "setup.h"
@@ -54,6 +56,41 @@ static void *__init alloc_paca_data(unsigned long size,
unsigned long align,
#define LPPACA_SIZE 0x400
+static void *__init alloc_shared_lppaca(unsigned long size, unsigned long
align,
+ unsigned long limit, int cpu)
+{
+ size_t shared_lppaca_total_size = PAGE_ALIGN(nr_cpu_ids * LPPACA_SIZE);
+ static unsigned long shared_lppaca_size;
+ static void *shared_lppaca;
+ void *ptr;
+
+ if (!shared_lppaca) {
+ memblock_set_bottom_up(true);
+
+ shared_lppaca =
+ memblock_alloc_try_nid(shared_lppaca_total_size,
+ PAGE_SIZE, MEMBLOCK_LOW_LIMIT,
+ limit, NUMA_NO_NODE);
+ if (!shared_lppaca)
+ panic("cannot allocate shared data");
+
+ memblock_set_bottom_up(false);
+ uv_share_page(PHYS_PFN(__pa(shared_lppaca)),
+ shared_lppaca_total_size >> PAGE_SHIFT);
+ }
+
+ ptr = shared_lppaca + shared_lppaca_size;
+ shared_lppaca_size += size;
+
+ /*
+* This is very early in boot, so no harm done if the kernel crashes at
+* this point.
+*/
+ BUG_ON(shared_lppaca_size >= shared_lppaca_total_size);
+
+ return ptr;
+}
+
/*
* See asm/lppaca.h for more detail.
*
@@ -83,7 +120,11 @@ static struct lppaca * __init new_lppaca(int cpu, unsigned
long limit)
if (early_cpu_has_feature(CPU_FTR_HVMODE))
return NULL;
- lp = alloc_paca_data(LPPACA_SIZE, 0x400, limit, cpu);
+ if (is_secure_guest())
+ lp = alloc_shared_lppaca(LPPACA_SIZE, 0x400, limit, cpu);
+ else
+ lp = alloc_paca_data(LPPACA_SIZE, 0x400, limit, cpu);
+
init_lppaca(lp);
return lp;
