Re: [PATCH v2] hexagon: switch to NO_BOOTMEM
On Wed, Jul 25, 2018 at 08:44:57PM -0500, Richard Kuo wrote: > On Wed, Jul 25, 2018 at 08:29:54AM +0300, Mike Rapoport wrote: > > This patch adds registration of the system memory with memblock, eliminates > > bootmem initialization and converts early memory reservations from bootmem > > to memblock. > > > > Signed-off-by: Mike Rapoport > > --- > > v2: fix calculation of the reserved memory size > > > > arch/hexagon/Kconfig | 3 +++ > > arch/hexagon/mm/init.c | 20 > > 2 files changed, 11 insertions(+), 12 deletions(-) > > > > Looks good, I can take this through my tree. Thanks. The hexagon tree seems the most appropriate :) > Acked-by: Richard Kuo > -- Sincerely yours, Mike.
Re: [PATCH v2 3/4] dma: Add Actions Semi Owl family S900 DMA driver
Hi Vinod,
On Tue, Jul 24, 2018 at 06:39:43PM +0530, Vinod wrote:
> somehow this got stuck so sending again...
>
> On 24-07-18, 18:16, Vinod wrote:
> > On 23-07-18, 09:47, Manivannan Sadhasivam wrote:
> >
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> >
> > do you need this?
> >
Not now ;-) will remove this.
> > > +/* OWL_DMAX_MODE Bits */
> > > +#define OWL_DMA_MODE_TS(x) (((x) & 0x3f) << 0)
> > > +#define OWL_DMA_MODE_ST(x) (((x) & 0x3) << 8)
> > > +#define OWL_DMA_MODE_ST_DEV OWL_DMA_MODE_ST(0)
> > > +#define OWL_DMA_MODE_ST_DCU OWL_DMA_MODE_ST(2)
> > > +#define OWL_DMA_MODE_ST_SRAMOWL_DMA_MODE_ST(3)
> >
> > what are you trying to do with this? Generally we would define register
> > bits using BIT and GENMASK here..
> >
Okay. Not sure about BIT() but I can use GENMASK() here.
> > > +/* Extract the bit field to new shift */
> > > +#define BIT_FIELD(val, width, shift, newshift) \
> > > + val) >> (shift)) & ((BIT(width)) - 1)) << (newshift))
> >
> > why new shift? I guess you want to extract bits from a register here and
> > use those, right?
> >
No. Here we are trying to pack two bit fields in a single word. So, the
`shift` is for the first Bit field and the `newshift` is for the second
one. Will modify the comment accordingly!
> > > +struct owl_dma_lli_hw {
> > > + u32 next_lli; /* physical address of the next link list */
> > > + u32 saddr; /* source physical address */
> > > + u32 daddr; /* destination physical address */
> > > + u32 flen:20;/* frame length */
> > > + u32 fcnt:12;/* frame count */
> > > + u32 src_stride; /* source stride */
> > > + u32 dst_stride; /* destination stride */
> > > + u32 ctrla; /* dma_mode and linklist ctrl */
> > > + u32 ctrlb; /* interrupt control */
> > > + u32 const_num; /* data for constant fill */
> >
> > i think you can skip comment here or kernel-doc style, please pick one
> > and not both
> >
Ack. Will remove the per member comment.
> > > +struct owl_dma_txd {
> > > + struct virt_dma_descvd;
> > > + struct list_headlli_list;
> >
> > why do you need this list. vd has its own list as well!
> >
Yes, but vd's list is named as node and that will create ambiguity since we
will be using it as a list. So, I guess we would need lli_list.
> > > +static void pchan_update(void __iomem *reg, u32 val, bool state)
> >
> > why does this not use pchan as arg as the name of API implies (you did
> > that on the other two)
> >
I wanted to just update the reg without using too many arguments.
Anyway, I can modify it to use pchan as the argument.
> > > +static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> > > + struct owl_dma_lli *lli,
> > > + dma_addr_t src, dma_addr_t dst,
> > > + u32 len, enum dma_transfer_direction dir)
> > > +{
> > > + struct owl_dma_lli_hw *hw = >hw;
> > > + u32 mode;
> > > +
> > > + mode = OWL_DMA_MODE_PW(0);
> > > +
> > > + switch (dir) {
> > > + case DMA_MEM_TO_MEM:
> > > + mode |= OWL_DMA_MODE_TS(0) | OWL_DMA_MODE_ST_DCU |
> > > + OWL_DMA_MODE_DT_DCU | OWL_DMA_MODE_SAM_INC |
> > > + OWL_DMA_MODE_DAM_INC;
> > > +
> > > + break;
> > > + default:
> > > + return -EINVAL;
> > > + }
> > > +
> > > + hw->next_lli = 0; /* One link list by default */
> > > + hw->saddr = src;
> > > + hw->daddr = dst;
> > > +
> > > + hw->fcnt = 1; /* Frame count fixed as 1 */
> > > + hw->flen = len; /* Max frame length is 1MB */
> >
> > are you checking that somewhere?
> >
No need to check since we allow only max size in the caller. The
following line does the job:
bytes = min_t(size_t, (len - offset), OWL_DMA_FRAME_MAX_LENGTH);
> > > +static struct owl_dma_pchan *owl_dma_get_pchan(struct owl_dma *od,
> > > +struct owl_dma_vchan *vchan)
> > > +{
> > > + struct owl_dma_pchan *pchan;
> > > + unsigned long flags;
> > > + int i;
> > > +
> > > + for (i = 0; i < od->nr_pchans; i++) {
> > > + pchan = >pchans[i];
> > > +
> > > + spin_lock_irqsave(>lock, flags);
> > > + if (!pchan->vchan) {
> > > + pchan->vchan = vchan;
> > > + spin_unlock_irqrestore(>lock, flags);
> > > + break;
> > > + }
> > > +
> > > + spin_unlock_irqrestore(>lock, flags);
> > > + }
> > > +
> > > + if (i == od->nr_pchans) {
> > > + /* No physical channel available, cope with it */
> > > + dev_dbg(od->dma.dev, "no physical channel available\n");
> >
> > not sure about this. The
Re: [PATCH 1/2] drivers: clk: st: warn on iomap failure
On Wed, Jul 25, 2018 at 01:41:38PM -0700, Stephen Boyd wrote: > Quoting Nicholas Mc Guire (2018-07-15 03:18:23) > > While the return value of clkgen_get_register_base() is being checked > > at the call site, there is no indication of failure cause thus making > > diagnosis of the issues hard. The WARN_ON() allows to determine the > > cause of failure. > > > > Signed-off-by: Nicholas Mc Guire > > --- > > > > Problem found by an experimental coccinelle script > > > > Patch was compile tested with: multi_v7_defconfig (implies > > CONFIG_ARCH_STI=y) > > > > Patch is against 4.18-rc4 (localversion-next is next-20180713) > > > > drivers/clk/st/clkgen-pll.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c > > index cbb5184..aeb30ab 100644 > > --- a/drivers/clk/st/clkgen-pll.c > > +++ b/drivers/clk/st/clkgen-pll.c > > @@ -647,6 +647,7 @@ static void __iomem * __init clkgen_get_register_base( > > return NULL; > > > > reg = of_iomap(pnode, 0); > > + WARN_ON(!reg); > > > > of_node_put(pnode); > > return reg; > > Shouldn't the caller blow up on NULL pointer access? This patch doesn't > seem useful, sorry. > if you look at the call chain then there is a check for !NULL along the way - but never any information - no pr_*/printk or the like so ultimately you would get a failure but not know where that failure came from - the intent of the WARN_ON() is to allow you to locate the trigger event. Blowing up with a BUG_ON() is not necessary as the call chain does check for !NULL along the way. thx! hofrat
Re: [PATCH 10/14] arm64: dts: meson-axg: add linein codec
On Wed, 2018-07-25 at 21:18 +0200, Martin Blumenstingl wrote:
> Hi Jerome,
>
> On Tue, Jul 24, 2018 at 3:09 PM Jerome Brunet wrote:
> >
> > Add the es7241 analog to digital converter which is fed by the
> > lienin jack of the s400
> >
> > Signed-off-by: Jerome Brunet
> > ---
> > arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> > b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> > index 7489b88f27d7..fb101a1c6660 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> > @@ -178,6 +178,16 @@
> > gpios = <_speaker 2 0>;
> > };
> > };
> > +
> > + linein: audio-codec@0 {
>
> there is a unit-address but no reg property - I am wondering if this is
> allowed?
> for the regulators we're using regulator- instead of
> regulator@
>
> (this applies to other patches in this series as well)
I did that because I tried to keep node-name generic as described in the DT
spec. The idea of numbering the nodes (without a reg property) in such a way
came from :
Documentation/devicetree/bindings/sound/simple-card.txt:
=> look at the multi dai link example. I'm doing exactly the same on the axg
card's dai-links. Nothing new here.
that being said, section 2.2.1 of the DT specs says:
" If the node has no reg property, the @unit-address must be omitted and the
node-name alone differentiates the node from other nodes at the same level in
the tree "
So apparently, this is used but not ok ?
I could make 'linein' the node-name instead of the label but that wouldn't be
very generic.
We could also have dai-link-2 instead dai-link@2 (audio-codec-3 instead of
audio-codec@3). I seems to be OK with the spec, but it also looks weird ...
Rob, do you have opinion on this ?
>
> > + #sound-dai-cells = <0>;
> > + compatible = "everest,es7241";
> > + VDDA-supply = <_3v3>;
> > + VDDP-supply = <_3v3>;
> > + VDDD-supply = <_3v3>;
> > + status = "okay";
> > + sound-name-prefix = "Linein";
>
> SPDIF output uses capital letters "SPDIFOUT"
> I am not familiar with the sound subsystem (thus I'm not sure where
> this shows up) so I am wondering if the naming should be consistent?
This string is used to prefix the name of the different widgets and controls
provided. It is useful when several devices provides component and control with
the same names. It happens when several instances of a component are used but
also with classic names, such as "Playback"
I don't think there is a rule regarding capitalization.
Some name are all capital in ASoC, some just have the first letter in upper
case. It doesn't change anything technically, and I personally don't care.
>
> Regards
> Martin
Re: [PATCH] fsi: master-ast-cf: Fix memory leak
On 07/25/2018 06:45 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2018-07-25 at 08:38 -0500, Gustavo A. R. Silva wrote:
>> In case memory resources for *fw* were allocated, release them
>> before return.
>>
>> Addresses-Coverity-ID: 1472044 ("Resource leak")
>> Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed
>> ColdFire")
>> Signed-off-by: Gustavo A. R. Silva
>
> Thanks Gustavo !
>
Glad to help. :)
> I'll apply before I send my next pull request to Greg !
>
Thanks
--
Gustavo
Re: [PATCH] reset: hisilicon: fix potential NULL pointer dereference
Hi Stephen,
On 07/25/2018 06:45 PM, Stephen Boyd wrote:
> Quoting Gustavo A. R. Silva (2018-07-18 18:58:45)
>> There is a potential execution path in which function
>> platform_get_resource() returns NULL. If this happens,
>> we will end up having a NULL pointer dereference.
>>
>> Fix this by adding asanity check in order to avoid a
>> NULL pointer dereference.
>>
>> This code was detected with the help of Coccinelle.
>>
>> Cc: sta...@vger.kernel.org
>> Fixes: 97b7129cd2af ("reset: hisilicon: change the definition of
>> hisi_reset_init")
>> Signed-off-by: Gustavo A. R. Silva
>> ---
>> drivers/clk/hisilicon/reset.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
>> index 2a5015c..5dfb48b 100644
>> --- a/drivers/clk/hisilicon/reset.c
>> +++ b/drivers/clk/hisilicon/reset.c
>> @@ -109,6 +109,9 @@ struct hisi_reset_controller *hisi_reset_init(struct
>> platform_device *pdev)
>> return NULL;
>>
>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + return NULL;
>> +
>> rstc->membase = devm_ioremap(>dev,
>> res->start, resource_size(res));
>
> Why can't we use devm_ioremap_resource() here instead?
>
You're right. I think we can perfectly use devm_ioremap_resource here and
remove the null check.
I'll send patch for this shortly.
Thanks
--
Gustavo
Re: [PATCH mmc-next 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
On Wed, 25 Jul 2018 17:47:49 +0800 Jisheng Zhang wrote:
> When using DMA, if the DMA addr spans 128MB boundary, we have to split
> the DMA transfer into two so that each one doesn't exceed the boundary.
>
> Signed-off-by: Jisheng Zhang
> ---
> drivers/mmc/host/sdhci-of-dwcmshc.c | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c
> b/drivers/mmc/host/sdhci-of-dwcmshc.c
> index 1b7cd144fb01..01b5cb772554 100644
> --- a/drivers/mmc/host/sdhci-of-dwcmshc.c
> +++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
> @@ -13,16 +13,45 @@
>
> #include "sdhci-pltfm.h"
>
> +#define BOUNDARY_OK(addr, len) \
> + ((addr | (SZ_128M - 1)) == ((addr + len) | (SZ_128M - 1)))
this should be
((addr | (SZ_128M - 1)) == ((addr + len - 1) | (SZ_128M - 1)))
> +
> struct dwcmshc_priv {
> struct clk *bus_clk;
> };
>
> +/*
> + * if DMA addr spans 128MB boundary, we split the DMA transfer into two
> + * so that the DMA transfer doesn't exceed the boundary.
> + */
> +static unsigned int dwcmshc_adma_write_desc(struct sdhci_host *host,
> + void *desc, dma_addr_t addr,
> + int len, unsigned int cmd)
> +{
> + int tmplen, offset;
> +
> + if (BOUNDARY_OK(addr, len))
> + return _sdhci_adma_write_desc(host, desc, addr, len, cmd);
> +
> + offset = addr & (SZ_128M - 1);
> + tmplen = SZ_128M - offset;
> + _sdhci_adma_write_desc(host, desc, addr, tmplen, cmd);
> +
> + addr += tmplen;
> + len -= tmplen;
> + desc += host->desc_sz;
> + _sdhci_adma_write_desc(host, desc, addr, len, cmd);
> +
> + return host->desc_sz * 2;
> +}
> +
> static const struct sdhci_ops sdhci_dwcmshc_ops = {
> .set_clock = sdhci_set_clock,
> .set_bus_width = sdhci_set_bus_width,
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .reset = sdhci_reset,
> + .adma_write_desc= dwcmshc_adma_write_desc,
> };
>
> static const struct sdhci_pltfm_data sdhci_dwcmshc_pdata = {
> @@ -36,12 +65,24 @@ static int dwcmshc_probe(struct platform_device *pdev)
> struct sdhci_host *host;
> struct dwcmshc_priv *priv;
> int err;
> + u32 extra;
>
> host = sdhci_pltfm_init(pdev, _dwcmshc_pdata,
> sizeof(struct dwcmshc_priv));
> if (IS_ERR(host))
> return PTR_ERR(host);
>
> + /*
> + * The DMA descriptor table number is calculated as the maximum
> + * number of segments times 2, to allow for an alignment
> + * descriptor for each segment, plus 1 for a nop end descriptor,
> + * plus extra number for cross 128M boundary handling.
> + */
> + extra = totalram_pages / (SZ_128M / PAGE_SIZE) + 1;
will use DIV_ROUND_UP instead.
> + if (extra > SDHCI_MAX_SEGS)
> + extra = SDHCI_MAX_SEGS;
> + host->adma_table_num = SDHCI_MAX_SEGS * 2 + 1 + extra;
> +
> pltfm_host = sdhci_priv(host);
> priv = sdhci_pltfm_priv(pltfm_host);
>
Re: [PATCH 3/6] irqchip: RISC-V Local Interrupt Controller Driver
On Wed, Jul 25, 2018 at 4:54 PM, Christoph Hellwig wrote: > On Wed, Jul 25, 2018 at 12:18:39PM +0100, Marc Zyngier wrote: >> This feels odd. It means that you cannot have the following sequence: >> >> local_irq_disable(); >> enable_irq(x); // where x is owned by a remote hart >> >> as smp_call_function_single() requires interrupts to be enabled. >> >> More fundamentally, why are you trying to make these interrupts look >> global while they aren't? arm/arm64 have similar restrictions with GICv2 >> and earlier, and treats these interrupts as per-cpu. >> >> Given that the drivers that deal with drivers connected to the per-hart >> irqchip are themselves likely to be aware of the per-cpu aspect, it >> would make sense to align things (we've been through that same >> discussion about the clocksource driver a few weeks back). > > Right now the only direct consumers are said clocksource, the PLIC > driver later in this series and the RISC-V arch IPI code. None of them > is going to do a manual enable_irq, so I guess the remote case of the > code is simply dead code. I'll take a look at converting them to > per-cpu. I guess the GICv2 driver is the best template? Actually, RISCV HLIC and PLIC are very similar to RPi2 and RPi3 SOCs. On RPi2 and RPi3, we have per-CPU BCM2836 local intc and the global interrupts are managed using BCM2835 intc. You should certainly have a look a this drivers because these very simple compared to GICv2 and GICv3 drivers. Regards, Anup
Re: [PATCH] watchdog: sp805: Add clock-frequency property
Hi Guenter,
It was my mistake sorry for that. I thought to add as Rivewed-by your name..
Many changes are made based on your review comments and suggestions.
So, Can I add your name in Reviewed list?
I will modify and send next patchset.
thank you.
Regards,
Srinath.
On Thu, Jul 26, 2018 at 10:12 AM, Guenter Roeck wrote:
> On 07/23/2018 01:37 AM, Srinath Mannam wrote:
>>
>> Use clock-frequency property given in _DSD object
>> of ACPI device to calculate Watchdog rate as binding
>> clock devices are not available as device tree.
>>
>> Note: There is no formal review process for _DSD
>> properties
>>
>> Signed-off-by: Srinath Mannam
>> Signed-off-by: Guenter Roeck
>
>
> I just noticed this. This is completely inappropriate. It is
> the equivalent of forging a signature on a check.
>
> _Never_ add a Signed-off-by: statement for anyone but yourself.
>
> Guenter
>
>> Reviewed-by: Guenter Roeck
>> Reviewed-by: Ray Jui
>> Reviewed-by: Scott Branden
>> ---
>> drivers/watchdog/sp805_wdt.c | 35 +--
>> 1 file changed, 25 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
>> index 9849db0..a896b1c 100644
>> --- a/drivers/watchdog/sp805_wdt.c
>> +++ b/drivers/watchdog/sp805_wdt.c
>> @@ -11,6 +11,7 @@
>>* warranty of any kind, whether express or implied.
>>*/
>> +#include
>> #include
>> #include
>> #include
>> @@ -22,6 +23,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -65,6 +67,7 @@ struct sp805_wdt {
>> spinlock_t lock;
>> void __iomem*base;
>> struct clk *clk;
>> + u64 rate;
>> struct amba_device *adev;
>> unsigned intload_val;
>> };
>> @@ -80,7 +83,7 @@ static int wdt_setload(struct watchdog_device *wdd,
>> unsigned int timeout)
>> struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>> u64 load, rate;
>> - rate = clk_get_rate(wdt->clk);
>> + rate = wdt->rate;
>> /*
>> * sp805 runs counter with given value twice, after the end of
>> first
>> @@ -106,9 +109,7 @@ static int wdt_setload(struct watchdog_device *wdd,
>> unsigned int timeout)
>> static unsigned int wdt_timeleft(struct watchdog_device *wdd)
>> {
>> struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>> - u64 load, rate;
>> -
>> - rate = clk_get_rate(wdt->clk);
>> + u64 load;
>> spin_lock(>lock);
>> load = readl_relaxed(wdt->base + WDTVALUE);
>> @@ -118,7 +119,7 @@ static unsigned int wdt_timeleft(struct
>> watchdog_device *wdd)
>> load += wdt->load_val + 1;
>> spin_unlock(>lock);
>> - return div_u64(load, rate);
>> + return div_u64(load, wdt->rate);
>> }
>> static int
>> @@ -228,11 +229,25 @@ sp805_wdt_probe(struct amba_device *adev, const
>> struct amba_id *id)
>> if (IS_ERR(wdt->base))
>> return PTR_ERR(wdt->base);
>> - wdt->clk = devm_clk_get(>dev, NULL);
>> - if (IS_ERR(wdt->clk)) {
>> - dev_warn(>dev, "Clock not found\n");
>> - ret = PTR_ERR(wdt->clk);
>> - goto err;
>> + if (adev->dev.of_node) {
>> + wdt->clk = devm_clk_get(>dev, NULL);
>> + if (IS_ERR(wdt->clk)) {
>> + dev_err(>dev, "Clock not found\n");
>> + return PTR_ERR(wdt->clk);
>> + }
>> + wdt->rate = clk_get_rate(wdt->clk);
>> + } else if (has_acpi_companion(>dev)) {
>> + /*
>> +* When Driver probe with ACPI device, clock devices
>> +* are not available, so watchdog rate get from
>> +* clock-frequency property given in _DSD object.
>> +*/
>> + device_property_read_u64(>dev, "clock-frequency",
>> +>rate);
>> + if (!wdt->rate) {
>> + dev_err(>dev, "no clock-frequency
>> property\n");
>> + return -ENODEV;
>> + }
>> }
>> wdt->adev = adev;
>>
>
[PATCH v2] watchdog: sp805: Add clock-frequency property
Use clock-frequency property given in _DSD object
of ACPI device to calculate Watchdog rate as binding
clock devices are not available as device tree.
Note: There is no formal review process for _DSD
properties
Signed-off-by: Srinath Mannam
Reviewed-by: Guenter Roeck
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/watchdog/sp805_wdt.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 9849db0..a896b1c 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -11,6 +11,7 @@
* warranty of any kind, whether express or implied.
*/
+#include
#include
#include
#include
@@ -22,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -65,6 +67,7 @@ struct sp805_wdt {
spinlock_t lock;
void __iomem*base;
struct clk *clk;
+ u64 rate;
struct amba_device *adev;
unsigned intload_val;
};
@@ -80,7 +83,7 @@ static int wdt_setload(struct watchdog_device *wdd, unsigned
int timeout)
struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
u64 load, rate;
- rate = clk_get_rate(wdt->clk);
+ rate = wdt->rate;
/*
* sp805 runs counter with given value twice, after the end of first
@@ -106,9 +109,7 @@ static int wdt_setload(struct watchdog_device *wdd,
unsigned int timeout)
static unsigned int wdt_timeleft(struct watchdog_device *wdd)
{
struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
- u64 load, rate;
-
- rate = clk_get_rate(wdt->clk);
+ u64 load;
spin_lock(>lock);
load = readl_relaxed(wdt->base + WDTVALUE);
@@ -118,7 +119,7 @@ static unsigned int wdt_timeleft(struct watchdog_device
*wdd)
load += wdt->load_val + 1;
spin_unlock(>lock);
- return div_u64(load, rate);
+ return div_u64(load, wdt->rate);
}
static int
@@ -228,11 +229,25 @@ sp805_wdt_probe(struct amba_device *adev, const struct
amba_id *id)
if (IS_ERR(wdt->base))
return PTR_ERR(wdt->base);
- wdt->clk = devm_clk_get(>dev, NULL);
- if (IS_ERR(wdt->clk)) {
- dev_warn(>dev, "Clock not found\n");
- ret = PTR_ERR(wdt->clk);
- goto err;
+ if (adev->dev.of_node) {
+ wdt->clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(wdt->clk)) {
+ dev_err(>dev, "Clock not found\n");
+ return PTR_ERR(wdt->clk);
+ }
+ wdt->rate = clk_get_rate(wdt->clk);
+ } else if (has_acpi_companion(>dev)) {
+ /*
+* When Driver probe with ACPI device, clock devices
+* are not available, so watchdog rate get from
+* clock-frequency property given in _DSD object.
+*/
+ device_property_read_u64(>dev, "clock-frequency",
+>rate);
+ if (!wdt->rate) {
+ dev_err(>dev, "no clock-frequency property\n");
+ return -ENODEV;
+ }
}
wdt->adev = adev;
--
2.7.4
[PATCH] ASoC: AMD: Fix build warning
Fixes
sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_probe':
sound/soc/amd/acp-da7219-max98357a.c:367:3: warning: 'ret' may
be used uninitialized in this function [-Wmaybe-uninitialized]
dev_err(>dev, "Failed to register regulator: %d\n",
ret);
Signed-off-by: Akshu Agrawal
---
sound/soc/amd/acp-da7219-max98357a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/amd/acp-da7219-max98357a.c
b/sound/soc/amd/acp-da7219-max98357a.c
index cd3cf6e..48c1d94 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -365,7 +365,7 @@ static int cz_probe(struct platform_device *pdev)
_da7219_cfg);
if (IS_ERR(rdev)) {
dev_err(>dev, "Failed to register regulator: %d\n",
- ret);
+ (int)PTR_ERR(rdev);
return -EINVAL;
}
--
1.9.1
linux-next: manual merge of the block tree with the rdma tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/nvme/target/rdma.c
between commit:
23f96d1f15a7 ("nvmet-rdma: Simplify ib_post_(send|recv|srq_recv)() calls")
202093848cac ("nvmet-rdma: add an error flow for post_recv failures")
from the rdma tree and commits:
2fc464e2162c ("nvmet-rdma: add unlikely check in the fast path")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/nvme/target/rdma.c
index 1a642e214a4c,e7f43d1e1779..
--- a/drivers/nvme/target/rdma.c
+++ b/drivers/nvme/target/rdma.c
@@@ -382,13 -435,22 +435,21 @@@ static void nvmet_rdma_free_rsps(struc
static int nvmet_rdma_post_recv(struct nvmet_rdma_device *ndev,
struct nvmet_rdma_cmd *cmd)
{
- struct ib_recv_wr *bad_wr;
+ int ret;
+
ib_dma_sync_single_for_device(ndev->device,
cmd->sge[0].addr, cmd->sge[0].length,
DMA_FROM_DEVICE);
if (ndev->srq)
- return ib_post_srq_recv(ndev->srq, >wr, NULL);
- return ib_post_recv(cmd->queue->cm_id->qp, >wr, NULL);
- ret = ib_post_srq_recv(ndev->srq, >wr, _wr);
++ ret = ib_post_srq_recv(ndev->srq, >wr, NULL);
+ else
- ret = ib_post_recv(cmd->queue->cm_id->qp, >wr, _wr);
++ ret = ib_post_recv(cmd->queue->cm_id->qp, >wr, NULL);
+
+ if (unlikely(ret))
+ pr_err("post_recv cmd failed\n");
+
+ return ret;
}
static void nvmet_rdma_process_wr_wait_list(struct nvmet_rdma_queue *queue)
@@@ -491,7 -553,7 +552,7 @@@ static void nvmet_rdma_queue_response(s
rsp->send_sge.addr, rsp->send_sge.length,
DMA_TO_DEVICE);
- if (ib_post_send(cm_id->qp, first_wr, NULL)) {
- if (unlikely(ib_post_send(cm_id->qp, first_wr, _wr))) {
++ if (unlikely(ib_post_send(cm_id->qp, first_wr, NULL))) {
pr_err("sending cmd response failed\n");
nvmet_rdma_release_rsp(rsp);
}
pgpCvQwUaa8BX.pgp
Description: OpenPGP digital signature
Re: [PATCH] watchdog: sp805: Add clock-frequency property
On 07/25/2018 09:47 PM, Srinath Mannam wrote:
Hi Guenter,
It was my mistake sorry for that. I thought to add as Rivewed-by your name..
Many changes are made based on your review comments and suggestions.
So, Can I add your name in Reviewed list?
You did that already below, and I am ok with that.
Guenter
I will modify and send next patchset.
thank you.
Regards,
Srinath.
On Thu, Jul 26, 2018 at 10:12 AM, Guenter Roeck wrote:
On 07/23/2018 01:37 AM, Srinath Mannam wrote:
Use clock-frequency property given in _DSD object
of ACPI device to calculate Watchdog rate as binding
clock devices are not available as device tree.
Note: There is no formal review process for _DSD
properties
Signed-off-by: Srinath Mannam
Signed-off-by: Guenter Roeck
I just noticed this. This is completely inappropriate. It is
the equivalent of forging a signature on a check.
_Never_ add a Signed-off-by: statement for anyone but yourself.
Guenter
Reviewed-by: Guenter Roeck
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/watchdog/sp805_wdt.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 9849db0..a896b1c 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -11,6 +11,7 @@
* warranty of any kind, whether express or implied.
*/
+#include
#include
#include
#include
@@ -22,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -65,6 +67,7 @@ struct sp805_wdt {
spinlock_t lock;
void __iomem*base;
struct clk *clk;
+ u64 rate;
struct amba_device *adev;
unsigned intload_val;
};
@@ -80,7 +83,7 @@ static int wdt_setload(struct watchdog_device *wdd,
unsigned int timeout)
struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
u64 load, rate;
- rate = clk_get_rate(wdt->clk);
+ rate = wdt->rate;
/*
* sp805 runs counter with given value twice, after the end of
first
@@ -106,9 +109,7 @@ static int wdt_setload(struct watchdog_device *wdd,
unsigned int timeout)
static unsigned int wdt_timeleft(struct watchdog_device *wdd)
{
struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
- u64 load, rate;
-
- rate = clk_get_rate(wdt->clk);
+ u64 load;
spin_lock(>lock);
load = readl_relaxed(wdt->base + WDTVALUE);
@@ -118,7 +119,7 @@ static unsigned int wdt_timeleft(struct
watchdog_device *wdd)
load += wdt->load_val + 1;
spin_unlock(>lock);
- return div_u64(load, rate);
+ return div_u64(load, wdt->rate);
}
static int
@@ -228,11 +229,25 @@ sp805_wdt_probe(struct amba_device *adev, const
struct amba_id *id)
if (IS_ERR(wdt->base))
return PTR_ERR(wdt->base);
- wdt->clk = devm_clk_get(>dev, NULL);
- if (IS_ERR(wdt->clk)) {
- dev_warn(>dev, "Clock not found\n");
- ret = PTR_ERR(wdt->clk);
- goto err;
+ if (adev->dev.of_node) {
+ wdt->clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(wdt->clk)) {
+ dev_err(>dev, "Clock not found\n");
+ return PTR_ERR(wdt->clk);
+ }
+ wdt->rate = clk_get_rate(wdt->clk);
+ } else if (has_acpi_companion(>dev)) {
+ /*
+* When Driver probe with ACPI device, clock devices
+* are not available, so watchdog rate get from
+* clock-frequency property given in _DSD object.
+*/
+ device_property_read_u64(>dev, "clock-frequency",
+>rate);
+ if (!wdt->rate) {
+ dev_err(>dev, "no clock-frequency
property\n");
+ return -ENODEV;
+ }
}
wdt->adev = adev;
RE: [PATCH v3 2/2] fpga: zynq-fpga: Add support for readback
Hi Alan, Thanks for the review... > > In Zynq Case it supports two types of the readback (Configuration registers, > Configuration data(fpga image)) which may not be the same case for other > vendors. > > Since I need to support both the use cases I have differentiated them using > module param in the zynq-fpga driver. > > > > As you said we shouldn't change the attribute's function, So in the > > zynq-fpga driver, I am planning to add another debugfs attribute for > reading back of configuration registers as it is vendor specific readback > type. > > (Configuration registers Usage: > /sys/kernel/debug/fpga/zynq-fpga/cfgreg_summary) > > Is it called '...summary' because it is not all the registers? Could just be > "cfg_regs"? Sure will make it cfg_regs... Are you ok with the above proposal?? if you are ok will make changes accordingly and will post v4... > > > (Configuration data(fpga image) Usage: > /sys/kernel/debug/fpga/fpga0/image) > > Please let me know your thoughts for the same... > > > >> > >> > One other option is sysfs. Do you want me to implement sysfs path??? > >> > Any other suggestions??? > >> > >> You could implement another sysfs attribute for reading FPGA registers > >> with a separate ops callback. Please clarify what it is doing (not > >> all FPGAs have this function) and what that will look like when the > >> user reads the from the sysfs > > > > AFAIK we shouldn't add another sysfs/debugfs attribute for vendor-specific > readback type in the FPGA manager ops. > > Please correct me if my understanding is wrong. > > You are not wrong :) Thanks Regards, Kedar. > > > > > Regards, > > Kedar. > > > >> > >> Alan
Re: [PATCH] watchdog: sp805: Add clock-frequency property
Hi Guenter,
Thank you.. I sent next version patch with modification.
Regards,
Srinath.
On Thu, Jul 26, 2018 at 10:39 AM, Guenter Roeck wrote:
> On 07/25/2018 09:47 PM, Srinath Mannam wrote:
>>
>> Hi Guenter,
>>
>> It was my mistake sorry for that. I thought to add as Rivewed-by your
>> name..
>> Many changes are made based on your review comments and suggestions.
>> So, Can I add your name in Reviewed list?
>
>
> You did that already below, and I am ok with that.
>
> Guenter
>
>> I will modify and send next patchset.
>>
>> thank you.
>>
>> Regards,
>> Srinath.
>>
>> On Thu, Jul 26, 2018 at 10:12 AM, Guenter Roeck
>> wrote:
>>>
>>> On 07/23/2018 01:37 AM, Srinath Mannam wrote:
Use clock-frequency property given in _DSD object
of ACPI device to calculate Watchdog rate as binding
clock devices are not available as device tree.
Note: There is no formal review process for _DSD
properties
Signed-off-by: Srinath Mannam
Signed-off-by: Guenter Roeck
>>>
>>>
>>>
>>> I just noticed this. This is completely inappropriate. It is
>>> the equivalent of forging a signature on a check.
>>>
>>> _Never_ add a Signed-off-by: statement for anyone but yourself.
>>>
>>> Guenter
>>>
Reviewed-by: Guenter Roeck
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/watchdog/sp805_wdt.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 9849db0..a896b1c 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -11,6 +11,7 @@
* warranty of any kind, whether express or implied.
*/
+#include
#include
#include
#include
@@ -22,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -65,6 +67,7 @@ struct sp805_wdt {
spinlock_t lock;
void __iomem*base;
struct clk *clk;
+ u64 rate;
struct amba_device *adev;
unsigned intload_val;
};
@@ -80,7 +83,7 @@ static int wdt_setload(struct watchdog_device *wdd,
unsigned int timeout)
struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
u64 load, rate;
- rate = clk_get_rate(wdt->clk);
+ rate = wdt->rate;
/*
* sp805 runs counter with given value twice, after the end of
first
@@ -106,9 +109,7 @@ static int wdt_setload(struct watchdog_device *wdd,
unsigned int timeout)
static unsigned int wdt_timeleft(struct watchdog_device *wdd)
{
struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
- u64 load, rate;
-
- rate = clk_get_rate(wdt->clk);
+ u64 load;
spin_lock(>lock);
load = readl_relaxed(wdt->base + WDTVALUE);
@@ -118,7 +119,7 @@ static unsigned int wdt_timeleft(struct
watchdog_device *wdd)
load += wdt->load_val + 1;
spin_unlock(>lock);
- return div_u64(load, rate);
+ return div_u64(load, wdt->rate);
}
static int
@@ -228,11 +229,25 @@ sp805_wdt_probe(struct amba_device *adev, const
struct amba_id *id)
if (IS_ERR(wdt->base))
return PTR_ERR(wdt->base);
- wdt->clk = devm_clk_get(>dev, NULL);
- if (IS_ERR(wdt->clk)) {
- dev_warn(>dev, "Clock not found\n");
- ret = PTR_ERR(wdt->clk);
- goto err;
+ if (adev->dev.of_node) {
+ wdt->clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(wdt->clk)) {
+ dev_err(>dev, "Clock not found\n");
+ return PTR_ERR(wdt->clk);
+ }
+ wdt->rate = clk_get_rate(wdt->clk);
+ } else if (has_acpi_companion(>dev)) {
+ /*
+* When Driver probe with ACPI device, clock devices
+* are not available, so watchdog rate get from
+* clock-frequency property given in _DSD object.
+*/
+ device_property_read_u64(>dev, "clock-frequency",
+>rate);
+ if (!wdt->rate) {
+ dev_err(>dev, "no clock-frequency
property\n");
+ return -ENODEV;
+ }
}
wdt->adev = adev;
>>>
>>
>
[PATCH v2 2/3] selftest/ftrace: Move kprobe selftest function to separate compile unit
From: Francis Deslauriers
Move selftest function to its own compile unit so it can be compiled
with the ftrace cflags (CC_FLAGS_FTRACE) allowing it to be probed
during the ftrace startup tests.
Signed-off-by: Francis Deslauriers
Acked-by: Masami Hiramatsu
---
kernel/trace/Makefile|5 +
kernel/trace/trace_kprobe.c | 12 +---
kernel/trace/trace_kprobe_selftest.c | 10 ++
kernel/trace/trace_kprobe_selftest.h |7 +++
4 files changed, 23 insertions(+), 11 deletions(-)
create mode 100644 kernel/trace/trace_kprobe_selftest.c
create mode 100644 kernel/trace/trace_kprobe_selftest.h
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index e2538c7638d4..e38771eccb2f 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -13,6 +13,11 @@ obj-y += trace_selftest_dynamic.o
endif
endif
+ifdef CONFIG_FTRACE_STARTUP_TEST
+CFLAGS_trace_kprobe_selftest.o = $(CC_FLAGS_FTRACE)
+obj-$(CONFIG_KPROBE_EVENTS) += trace_kprobe_selftest.o
+endif
+
# If unlikely tracing is enabled, do not trace these files
ifdef CONFIG_TRACING_BRANCHES
KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 1f1b4d712a7e..859f7c310a00 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -23,6 +23,7 @@
#include
#include
+#include "trace_kprobe_selftest.h"
#include "trace_probe.h"
#define KPROBE_EVENT_SYSTEM "kprobes"
@@ -1573,17 +1574,6 @@ fs_initcall(init_kprobe_trace);
#ifdef CONFIG_FTRACE_STARTUP_TEST
-/*
- * The "__used" keeps gcc from removing the function symbol
- * from the kallsyms table. 'noinline' makes sure that there
- * isn't an inlined version used by the test method below
- */
-static __used __init noinline int
-kprobe_trace_selftest_target(int a1, int a2, int a3, int a4, int a5, int a6)
-{
- return a1 + a2 + a3 + a4 + a5 + a6;
-}
-
static __init struct trace_event_file *
find_trace_probe_file(struct trace_kprobe *tk, struct trace_array *tr)
{
diff --git a/kernel/trace/trace_kprobe_selftest.c
b/kernel/trace/trace_kprobe_selftest.c
new file mode 100644
index ..16548ee4c8c6
--- /dev/null
+++ b/kernel/trace/trace_kprobe_selftest.c
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Function used during the kprobe self test. This function is in a separate
+ * compile unit so it can be compile with CC_FLAGS_FTRACE to ensure that it
+ * can be probed by the selftests.
+ */
+int kprobe_trace_selftest_target(int a1, int a2, int a3, int a4, int a5, int
a6)
+{
+ return a1 + a2 + a3 + a4 + a5 + a6;
+}
diff --git a/kernel/trace/trace_kprobe_selftest.h
b/kernel/trace/trace_kprobe_selftest.h
new file mode 100644
index ..4e10ec41c013
--- /dev/null
+++ b/kernel/trace/trace_kprobe_selftest.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Function used during the kprobe self test. This function is in a separate
+ * compile unit so it can be compile with CC_FLAGS_FTRACE to ensure that it
+ * can be probed by the selftests.
+ */
+int kprobe_trace_selftest_target(int a1, int a2, int a3, int a4, int a5, int
a6);
BUG: soft lockup in snd_virmidi_output_trigger
Reporting the crash: BUG: soft lockup in snd_virmidi_output_trigger This crash has been found in v4.18-rc3 using RaceFuzzer (a modified version of Syzkaller), which we describe more at the end of this report. Note that this bug is previously reported by Syzkaller a few month ago. (https://syzkaller.appspot.com/bug?id=642c927972318775e0ea1b4779ccd8624ce9e6f5) Nonetheless, the crash still can be detected. We guess that the crash has not fixed yet. We report the crash log and the attached reproducer with a hope that they are helpful to diagnose the crash and to fix a bug. C Reproducer: https://kiwi.cs.purdue.edu/static/race-fuzzer/repro-dab082.c Kernel config: https://kiwi.cs.purdue.edu/static/race-fuzzer/config-dab082 (Please disregard all code related to "should_hypercall" in the C repro, as this is only for our debugging purposes using our own hypervisor.) Crash log: == watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [syz-executor0:24261] Modules linked in: irq event stamp: 6692 hardirqs last enabled at (6691): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 [inline] hardirqs last enabled at (6691): [] _raw_spin_unlock_irqrestore+0x62/0x90 kernel/locking/spinlock.c:184 hardirqs last disabled at (6692): [] interrupt_entry+0xb5/0xf0 arch/x86/entry/entry_64.S:625 softirqs last enabled at (1468): [] __do_softirq+0x5ff/0x7f4 kernel/softirq.c:314 softirqs last disabled at (1455): [] invoke_softirq kernel/softirq.c:368 [inline] softirqs last disabled at (1455): [] irq_exit+0x126/0x130 kernel/softirq.c:408 CPU: 1 PID: 24261 Comm: syz-executor0 Not tainted 4.18.0-rc3 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 [inline] RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0x7d/0x90 kernel/locking/spinlock.c:184 Code: 0d c8 ce 16 7b 5b 41 5c 5d c3 e8 3e 0f 52 fc 48 c7 c7 68 b0 71 86 e8 62 4c 8d fc 48 83 3d 42 91 86 01 00 74 0e 48 89 df 57 9d <0f> 1f 44 00 00 eb cd 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 55 48 89 RSP: 0018:8801b8e4f7e8 EFLAGS: 0282 ORIG_RAX: ff13 RAX: RBX: 0282 RCX: 84eb1f1e RDX: dc00 RSI: dc00 RDI: 0282 RBP: 8801b8e4f7f8 R08: ed002573a06a R09: R10: R11: R12: 88012b9d0348 R13: 8801e6417580 R14: 8801b8e4f868 R15: 8801e64175a8 FS: 7f3447a49700() GS:8801f6d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f3447a48db8 CR3: 0001ee58d000 CR4: 06e0 Call Trace: spin_unlock_irqrestore include/linux/spinlock.h:365 [inline] snd_virmidi_output_trigger+0x37d/0x420 sound/core/seq/seq_virmidi.c:205 snd_rawmidi_output_trigger sound/core/rawmidi.c:150 [inline] snd_rawmidi_kernel_write1+0x383/0x410 sound/core/rawmidi.c:1288 snd_rawmidi_write+0x249/0xa50 sound/core/rawmidi.c:1338 __vfs_write+0xf9/0x5d0 fs/read_write.c:485 vfs_write+0x195/0x380 fs/read_write.c:549 ksys_write+0xdb/0x1d0 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x43/0x50 fs/read_write.c:607 do_syscall_64+0x182/0x540 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x44b939 Code: 8d 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f3447a48b48 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 0071bfa0 RCX: 0044b939 RDX: 210b RSI: 2100 RDI: 0013 RBP: b7a8 R08: R09: R10: R11: 0246 R12: 7f3447a496d4 R13: R14: 006f7848 R15: = About RaceFuzzer RaceFuzzer is a customized version of Syzkaller, specifically tailored to find race condition bugs in the Linux kernel. While we leverage many different technique, the notable feature of RaceFuzzer is in leveraging a custom hypervisor (QEMU/KVM) to interleave the scheduling. In particular, we modified the hypervisor to intentionally stall a per-core execution, which is similar to supporting per-core breakpoint functionality. This allows RaceFuzzer to force the kernel to deterministically trigger racy condition (which may rarely happen in practice due to randomness in scheduling).
[PATCH v2 1/3] tracing: kprobes: Prohibit probing on notrace function
Prohibit kprobe-events probing on notrace function.
Since probing on the notrace function can cause recursive
event call. In most case those are just skipped, but
in some case it falls into infinit recursive call.
This protection can be disabled by the kconfig
CONFIG_KPROBE_EVENTS_ON_NOTRACE=y, but it is highly
recommended to keep it "n" for normal kernel.
Signed-off-by: Masami Hiramatsu
Tested-by: Francis Deslauriers
---
Changes from v1
- Add CONFIG_KPROBE_EVENTS_ON_NOTRACE kconfig for knocking down
the protection.
---
kernel/trace/Kconfig| 18 ++
kernel/trace/trace_kprobe.c | 23 +++
2 files changed, 41 insertions(+)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index dcc0166d1997..24d5a58467a3 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -456,6 +456,24 @@ config KPROBE_EVENTS
This option is also required by perf-probe subcommand of perf tools.
If you want to use perf tools, this option is strongly recommended.
+config KPROBE_EVENTS_ON_NOTRACE
+ bool "Do NOT protect notrace function from kprobe events"
+ depends on KPROBE_EVENTS
+ default n
+ help
+ This is only for the developers who want to debug ftrace itself
+ using kprobe events.
+
+ Usually, ftrace related functions are protected from kprobe-events
+ to prevent an infinit recursion or any unexpected execution path
+ which leads to a kernel crash.
+
+ This option disables such protection and allows you to put kprobe
+ events on ftrace functions for debugging ftrace by itself.
+ Note that this might let you shoot yourself in the foot.
+
+ If unsure, say N.
+
config UPROBE_EVENTS
bool "Enable uprobes-based dynamic events"
depends on ARCH_SUPPORTS_UPROBES
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 27ace4513c43..1f1b4d712a7e 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -496,6 +496,23 @@ disable_trace_kprobe(struct trace_kprobe *tk, struct
trace_event_file *file)
return ret;
}
+#ifdef CONFIG_KPROBE_EVENTS_ON_NOTRACE
+#define within_notrace_func(tk)(false)
+#else
+static bool within_notrace_func(struct trace_kprobe *tk)
+{
+ unsigned long offset, size, addr;
+
+ addr = kallsyms_lookup_name(trace_kprobe_symbol(tk));
+ addr += trace_kprobe_offset(tk);
+
+ if (!kallsyms_lookup_size_offset(addr, , ))
+ return true;/* Out of range. */
+
+ return !ftrace_location_range(addr - offset, addr - offset + size);
+}
+#endif
+
/* Internal register function - just handle k*probes and flags */
static int __register_trace_kprobe(struct trace_kprobe *tk)
{
@@ -504,6 +521,12 @@ static int __register_trace_kprobe(struct trace_kprobe *tk)
if (trace_probe_is_registered(>tp))
return -EINVAL;
+ if (within_notrace_func(tk)) {
+ pr_warn("Could not probe notrace function %s\n",
+ trace_kprobe_symbol(tk));
+ return -EINVAL;
+ }
+
for (i = 0; i < tk->tp.nr_args; i++)
traceprobe_update_arg(>tp.args[i]);
Re: [PATCH 2/2] drivers: clk: st: address sparse warnings
On Wed, Jul 25, 2018 at 01:40:53PM -0700, Stephen Boyd wrote:
> Quoting Nicholas Mc Guire (2018-07-15 03:18:24)
> > Refactoring of code to make it more readable and at the same time make
> > sparse happy again.
> >
> > Signed-off-by: Nicholas Mc Guire
> > ---
> >
> > sparse complained about:
> > drivers/clk/st/clkgen-pll.c:225:12: warning: context imbalance in
> > 'clkgen_pll_enable' - different lock contexts for basic block
> > drivers/clk/st/clkgen-pll.c:267:9: warning: context imbalance in
> > 'clkgen_pll_disable' - different lock contexts for basic block
> > drivers/clk/st/clkgen-pll.c:413:9: warning: context imbalance in
> > 'set_rate_stm_pll3200c32' - different lock contexts for basic block
> > drivers/clk/st/clkgen-pll.c:570:9: warning: context imbalance in
> > 'set_rate_stm_pll4600c28' - different lock contexts for basic block
> >
> > Which are technically false positives as the pll->lock which is being
> > checked is determined at configuration time, thus the locks are balanced.
> > Never the less the refactored code seems more readable and was
> > commented to make it clear.
>
> This stuff above should go into the commit text.
ok - then I´ll resend that with that moved into the commit message.
>
> >
> > Patch was compile tested with: multi_v7_defconfig (implies
> > CONFIG_ARCH_STI=y)
> >
> > Patch is against 4.18-rc4 (localversion-next is next-20180713)
> >
> > drivers/clk/st/clkgen-pll.c | 51
> > +
> > 1 file changed, 28 insertions(+), 23 deletions(-)
>
> I believe this driver is in stasis mode. Not sure anyone is testing this
> right now. Please Cc people who have worked on this driver, like Gabriel
> Fernandez.
>
> >
> > diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
> > index 7a7106dc..cbb5184 100644
> > --- a/drivers/clk/st/clkgen-pll.c
> > +++ b/drivers/clk/st/clkgen-pll.c
> > @@ -228,13 +228,13 @@ static int clkgen_pll_enable(struct clk_hw *hw)
> > unsigned long flags = 0;
> > int ret = 0;
> >
> > - if (pll->lock)
> > + if (pll->lock) {
> > + /* stih418 and stih407 */
> > spin_lock_irqsave(pll->lock, flags);
> > -
> > - ret = __clkgen_pll_enable(hw);
> > -
> > - if (pll->lock)
> > + ret = __clkgen_pll_enable(hw);
> > spin_unlock_irqrestore(pll->lock, flags);
> > + } else
> > + ret = __clkgen_pll_enable(hw);
> >
> > return ret;
> > }
> > @@ -259,13 +259,13 @@ static void clkgen_pll_disable(struct clk_hw *hw)
> > struct clkgen_pll *pll = to_clkgen_pll(hw);
> > unsigned long flags = 0;
> >
> > - if (pll->lock)
> > + if (pll->lock) {
> > + /* stih418 and stih407 */
> > spin_lock_irqsave(pll->lock, flags);
> > -
> > - __clkgen_pll_disable(hw);
> > -
> > - if (pll->lock)
> > + __clkgen_pll_disable(hw);
> > spin_unlock_irqrestore(pll->lock, flags);
> > + } else
> > + __clkgen_pll_disable(hw);
> > }
> >
> > static int clk_pll3200c32_get_params(unsigned long input, unsigned long
> > output,
> > @@ -400,15 +400,18 @@ static int set_rate_stm_pll3200c32(struct clk_hw *hw,
> > unsigned long rate,
> >
> > __clkgen_pll_disable(hw);
> >
> > - if (pll->lock)
> > + if (pll->lock) {
> > + /* stih407 and stih418 */
> > spin_lock_irqsave(pll->lock, flags);
> > -
> > - CLKGEN_WRITE(pll, ndiv, pll->ndiv);
> > - CLKGEN_WRITE(pll, idf, pll->idf);
> > - CLKGEN_WRITE(pll, cp, pll->cp);
> > -
> > - if (pll->lock)
> > + CLKGEN_WRITE(pll, ndiv, pll->ndiv);
> > + CLKGEN_WRITE(pll, idf, pll->idf);
> > + CLKGEN_WRITE(pll, cp, pll->cp);
> > spin_unlock_irqrestore(pll->lock, flags);
> > + } else {
> > + CLKGEN_WRITE(pll, ndiv, pll->ndiv);
> > + CLKGEN_WRITE(pll, idf, pll->idf);
> > + CLKGEN_WRITE(pll, cp, pll->cp);
> > + }
>
> Please don't duplicate this code. The sparse warnings can be fixed by
> adding a fake lock acquire to the else of the if condition. We do this
> in drivers/clk/clk.c so you should be able to copy it from there.
the duplication is not a mater of the sparse warning only - the inetnt was
to improve readability - atleast for the one-line cases it seems more
readable to have it this way than to have the two lock checks - notably
as you can then comment what the difference here really is.
I agree that for this case with the three lines in the body it is not
that reasonable - this was simply a matter of consistency as the other lock
checks were moved into a if-else construct for readability and commenting.
thx!
hofrat
[PATCH v2 3/3] selftests/ftrace: Fix kprobe string testcase to not probe notrace function
Fix kprobe string argument testcase to not probe notrace
function. Instead, it probes tracefs function which must
be available with ftrace.
Signed-off-by: Masami Hiramatsu
---
.../ftrace/test.d/kprobe/kprobe_args_string.tc | 30
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
index a0002563e9ee..1ad70cdaf442 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
@@ -9,28 +9,22 @@ echo > kprobe_events
case `uname -m` in
x86_64)
- ARG2=%si
- OFFS=8
+ ARG1=%di
;;
i[3456]86)
- ARG2=%cx
- OFFS=4
+ ARG1=%ax
;;
aarch64)
- ARG2=%x1
- OFFS=8
+ ARG1=%x0
;;
arm*)
- ARG2=%r1
- OFFS=4
+ ARG1=%r0
;;
ppc64*)
- ARG2=%r4
- OFFS=8
+ ARG1=%r3
;;
ppc*)
- ARG2=%r4
- OFFS=4
+ ARG1=%r3
;;
*)
echo "Please implement other architecture here"
@@ -38,17 +32,17 @@ ppc*)
esac
: "Test get argument (1)"
-echo "p:testprobe create_trace_kprobe arg1=+0(+0(${ARG2})):string" >
kprobe_events
+echo "p:testprobe tracefs_create_dir arg1=+0(${ARG1}):string" > kprobe_events
echo 1 > events/kprobes/testprobe/enable
-! echo test >> kprobe_events
-tail -n 1 trace | grep -qe "testprobe.* arg1=\"test\""
+echo "p:test _do_fork" >> kprobe_events
+grep -qe "testprobe.* arg1=\"test\"" trace
echo 0 > events/kprobes/testprobe/enable
: "Test get argument (2)"
-echo "p:testprobe create_trace_kprobe arg1=+0(+0(${ARG2})):string
arg2=+0(+${OFFS}(${ARG2})):string" > kprobe_events
+echo "p:testprobe tracefs_create_dir arg1=+0(${ARG1}):string
arg2=+0(${ARG1}):string" > kprobe_events
echo 1 > events/kprobes/testprobe/enable
-! echo test1 test2 >> kprobe_events
-tail -n 1 trace | grep -qe "testprobe.* arg1=\"test1\" arg2=\"test2\""
+echo "p:test _do_fork" >> kprobe_events
+grep -qe "testprobe.* arg1=\"test\" arg2=\"test\"" trace
echo 0 > events/enable
echo > kprobe_events
[PATCH v2 0/3] tracing: kprobes: Prohibit probing on notrace functions
Hello, this is the 2nd version of the series to prohibit kprobe on notrace functions which Francis sent before. Here is v1 series: https://lkml.org/lkml/2018/7/12/678 In this version, I've add a kconfig option to remove notrace protection just for debugging, and also fix ftracetest testcase to not probe notrace function. Thank you, --- Francis Deslauriers (1): selftest/ftrace: Move kprobe selftest function to separate compile unit Masami Hiramatsu (2): tracing: kprobes: Prohibit probing on notrace function selftests/ftrace: Fix kprobe string testcase to not probe notrace function kernel/trace/Kconfig | 18 ++ kernel/trace/Makefile |5 +++ kernel/trace/trace_kprobe.c| 35 ++-- kernel/trace/trace_kprobe_selftest.c | 10 ++ kernel/trace/trace_kprobe_selftest.h |7 .../ftrace/test.d/kprobe/kprobe_args_string.tc | 30 +++-- 6 files changed, 76 insertions(+), 29 deletions(-) create mode 100644 kernel/trace/trace_kprobe_selftest.c create mode 100644 kernel/trace/trace_kprobe_selftest.h -- Masami Hiramatsu (Linaro)
Re: [PATCH 0/3] PTI for x86-32 Fixes and Updates
On Mon, 2018-07-23 at 09:29 +0200, Joerg Roedel wrote: > Hey David, > > On Sun, Jul 22, 2018 at 11:49:00PM -0400, David H. Gutteridge wrote: > > Unfortunately, I can trigger a bug in KVM+QEMU with the Bochs VGA > > driver. (This is the same VM definition I shared with you in a PM > > back on Feb. 20th, except note that 4.18 kernels won't successfully > > boot with QEMU's IDE device, so I'm using SATA instead. That's a > > regression totally unrelated to your change sets, or to the general > > booting issue with 4.18 RC5, since it occurs in vanilla RC4 as > > well.) > > Yes, this needs the fixes in the tip/x86/mm branch as well. Can you > that branch in and test again, please? Sorry, I didn't realize I needed those changes, too. I've re-tested with those applied and haven't encountered any issues. I'm now re-testing again with your newer patch set from the 25th. No issues so far with those, either; I'll confirm in that email thread after the laptop has seen some more use. Dave
[PATCH v5] ARM: mvebu: use dt_fixup to provide fallback for enable-method
We need to maintain backwards compatibility with device trees that don't
define an enable method. At the same time we want the device tree to be
able to specify an enable-method and have it stick.
Previously by having smp assigned in the DT_MACHINE definition this
would be picked up by setup_arch() and override whatever
arm_dt_init_cpu_maps() had configured. Now we move the initial
assignment of default smp_ops to a dt_fixup and let
arm_dt_init_cpu_maps() override that if the device tree defines an
enable-method.
Signed-off-by: Chris Packham
---
Pervious versions
v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/300182.html
v2:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/300480.html
v3:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/302945.html
v4:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/303899.html
Changes since v4:
- drop "RFC"
arch/arm/mach-mvebu/board-v7.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index ccca95173e17..5bbde5e5258e 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -145,6 +145,11 @@ static void __init mvebu_dt_init(void)
i2c_quirk();
}
+static void __init armada_370_xp_dt_fixup(void)
+{
+ smp_set_ops(smp_ops(armada_xp_smp_ops));
+}
+
static const char * const armada_370_xp_dt_compat[] __initconst = {
"marvell,armada-370-xp",
NULL,
@@ -153,17 +158,12 @@ static const char * const armada_370_xp_dt_compat[]
__initconst = {
DT_MACHINE_START(ARMADA_370_XP_DT, "Marvell Armada 370/XP (Device Tree)")
.l2c_aux_val= 0,
.l2c_aux_mask = ~0,
-/*
- * The following field (.smp) is still needed to ensure backward
- * compatibility with old Device Trees that were not specifying the
- * cpus enable-method property.
- */
- .smp= smp_ops(armada_xp_smp_ops),
.init_machine = mvebu_dt_init,
.init_irq = mvebu_init_irq,
.restart= mvebu_restart,
.reserve= mvebu_memblock_reserve,
.dt_compat = armada_370_xp_dt_compat,
+ .dt_fixup = armada_370_xp_dt_fixup,
MACHINE_END
static const char * const armada_375_dt_compat[] __initconst = {
--
2.18.0
[PATCH 2/4] ARM: dts: mvebu: db-dxbc2: use new style nand binding
Update the nand flash binding to the new style.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-db-dxbc2.dts | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
b/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
index 944e0a9c9dac..8a3aa616bbd0 100644
--- a/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
+++ b/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
@@ -70,12 +70,16 @@
_controller {
status = "okay";
- label = "pxa3xx_nand-0";
- num-cs = <1>;
- marvell,nand-keep-config;
- nand-on-flash-bbt;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
+
+ nand@0 {
+ reg = <0>;
+ label = "pxa3xx_nand-0";
+ nand-rb = <0>;
+ marvell,nand-keep-config;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ };
};
{
--
2.18.0
[PATCH 3/4] ARM: dts: mvebu: db-xc3-24g4: use new style nand binding
Update the nand flash binding to the new style.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
index d58ea48cb151..df048050615f 100644
--- a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
+++ b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
@@ -69,12 +69,16 @@
_controller {
status = "okay";
- label = "pxa3xx_nand-0";
- num-cs = <1>;
- marvell,nand-keep-config;
- nand-on-flash-bbt;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
+
+ nand@0 {
+ reg = <0>;
+ label = "pxa3xx_nand-0";
+ nand-rb = <0>;
+ marvell,nand-keep-config;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ };
};
{
--
2.18.0
[PATCH 4/4] ARM: dts: mvebu: Add device tree for db-88f6820-amc board
This board is a plugin card for some of Marvell's switch development
kits. It's similar to the non-amc board except that it has no SATA
support.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/armada-385-db-88f6820-amc.dts| 147 ++
2 files changed, 148 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-db-88f6820-amc.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 37a3de760d40..e4212b7b7d9e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1126,6 +1126,7 @@ dtb-$(CONFIG_MACH_ARMADA_370) += \
dtb-$(CONFIG_MACH_ARMADA_375) += \
armada-375-db.dtb
dtb-$(CONFIG_MACH_ARMADA_38X) += \
+ armada-385-db-88f6820-amc.dtb \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
diff --git a/arch/arm/boot/dts/armada-385-db-88f6820-amc.dts
b/arch/arm/boot/dts/armada-385-db-88f6820-amc.dts
new file mode 100644
index ..d87614057e3f
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-db-88f6820-amc.dts
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Marvell Armada 385 AMC board
+ * (DB-88F6820-AMC)
+ *
+ * Copyright (C) 2017 Allied Telesis Labs
+ */
+
+/dts-v1/;
+#include "armada-385.dtsi"
+
+#include
+
+/ {
+ model = "Marvell Armada 385 AMC";
+ compatible = "marvell,a385-db-amc", "marvell,armada385",
"marvell,armada380";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ spi1 =
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x8000>; /* 2GB */
+ };
+
+ soc {
+ ranges = ;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ /*
+* Exported on the micro USB connector CON3
+* through an FTDI
+*/
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+
+ {
+ pinctrl-names = "default";
+ /*
+* The Reference Clock 0 is used to provide a
+* clock to the PHY
+*/
+ pinctrl-0 = <_rgmii_pins>, <_clk0_pins>;
+ status = "okay";
+ phy = <>;
+ phy-mode = "rgmii-id";
+};
+
+ {
+ status = "okay";
+ phy = <>;
+ phy-mode = "sgmii";
+};
+
+ {
+ status = "okay";
+};
+
+
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ phy0: ethernet-phy@1 {
+ reg = <1>;
+ };
+
+ phy1: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+_controller {
+ status = "okay";
+
+ nand@0 {
+ reg = <0>;
+ label = "pxa3xx_nand-0";
+ nand-rb = <0>;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+
+ partition@user {
+ reg = <0x 0x4000>;
+ label = "user";
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ /* Port 0, Lane 0 */
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <5000>;
+ m25p,fast-read;
+
+ partition@u-boot {
+ reg = <0x 0x0010>;
+ label = "u-boot";
+ };
+ partition@u-boot-env {
+ reg = <0x0010 0x0004>;
+ label = "u-boot-env";
+ };
+ };
+};
+
+ {
+ clock-frequency = <2000>;
+};
--
2.18.0
Re: [PATCH] watchdog: sp805: Add clock-frequency property
On 07/23/2018 01:37 AM, Srinath Mannam wrote:
Use clock-frequency property given in _DSD object
of ACPI device to calculate Watchdog rate as binding
clock devices are not available as device tree.
Note: There is no formal review process for _DSD
properties
Signed-off-by: Srinath Mannam
Signed-off-by: Guenter Roeck
I just noticed this. This is completely inappropriate. It is
the equivalent of forging a signature on a check.
_Never_ add a Signed-off-by: statement for anyone but yourself.
Guenter
Reviewed-by: Guenter Roeck
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/watchdog/sp805_wdt.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 9849db0..a896b1c 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -11,6 +11,7 @@
* warranty of any kind, whether express or implied.
*/
+#include
#include
#include
#include
@@ -22,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -65,6 +67,7 @@ struct sp805_wdt {
spinlock_t lock;
void __iomem*base;
struct clk *clk;
+ u64 rate;
struct amba_device *adev;
unsigned intload_val;
};
@@ -80,7 +83,7 @@ static int wdt_setload(struct watchdog_device *wdd, unsigned
int timeout)
struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
u64 load, rate;
- rate = clk_get_rate(wdt->clk);
+ rate = wdt->rate;
/*
* sp805 runs counter with given value twice, after the end of first
@@ -106,9 +109,7 @@ static int wdt_setload(struct watchdog_device *wdd,
unsigned int timeout)
static unsigned int wdt_timeleft(struct watchdog_device *wdd)
{
struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
- u64 load, rate;
-
- rate = clk_get_rate(wdt->clk);
+ u64 load;
spin_lock(>lock);
load = readl_relaxed(wdt->base + WDTVALUE);
@@ -118,7 +119,7 @@ static unsigned int wdt_timeleft(struct watchdog_device
*wdd)
load += wdt->load_val + 1;
spin_unlock(>lock);
- return div_u64(load, rate);
+ return div_u64(load, wdt->rate);
}
static int
@@ -228,11 +229,25 @@ sp805_wdt_probe(struct amba_device *adev, const struct
amba_id *id)
if (IS_ERR(wdt->base))
return PTR_ERR(wdt->base);
- wdt->clk = devm_clk_get(>dev, NULL);
- if (IS_ERR(wdt->clk)) {
- dev_warn(>dev, "Clock not found\n");
- ret = PTR_ERR(wdt->clk);
- goto err;
+ if (adev->dev.of_node) {
+ wdt->clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(wdt->clk)) {
+ dev_err(>dev, "Clock not found\n");
+ return PTR_ERR(wdt->clk);
+ }
+ wdt->rate = clk_get_rate(wdt->clk);
+ } else if (has_acpi_companion(>dev)) {
+ /*
+* When Driver probe with ACPI device, clock devices
+* are not available, so watchdog rate get from
+* clock-frequency property given in _DSD object.
+*/
+ device_property_read_u64(>dev, "clock-frequency",
+>rate);
+ if (!wdt->rate) {
+ dev_err(>dev, "no clock-frequency property\n");
+ return -ENODEV;
+ }
}
wdt->adev = adev;
linux-next: build failure after merge of the block tree
Hi all,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/nvme/target/rdma.c: In function 'nvmet_rdma_find_get_device':
drivers/nvme/target/rdma.c:894:26: error: 'struct ib_device_attr' has no member
named 'max_sge'; did you mean 'max_cqe'?
cm_id->device->attrs.max_sge) - 1;
^
drivers/nvme/target/rdma.c:893:21: note: in expansion of macro 'max'
inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
^~~
In file included from include/linux/list.h:9:0,
from include/linux/module.h:9,
from drivers/nvme/host/rdma.c:15:
drivers/nvme/host/rdma.c: In function 'nvme_rdma_find_get_device':
drivers/nvme/host/rdma.c:381:23: error: 'struct ib_device_attr' has no member
named 'max_sge'; did you mean 'max_cqe'?
ndev->dev->attrs.max_sge - 1);
^
drivers/nvme/host/rdma.c:380:30: note: in expansion of macro 'min'
ndev->num_inline_segments = min(NVME_RDMA_MAX_INLINE_SEGMENTS,
^~~
Caused by commits
64a741c1eaa8 ("nvme-rdma: support up to 4 segments of inline data")
0d5ee2b2ab4f ("nvmet-rdma: support max(16KB, PAGE_SIZE) inline data")
interacting with commit
33023fb85a42 ("IB/core: add max_send_sge and max_recv_sge attributes")
from the rdma tree.
I have applied the following merge fix patch for today:
From: Stephen Rothwell
Date: Thu, 26 Jul 2018 14:32:15 +1000
Subject: [PATCH] nvme-dma: merge fix up for replacement of max_sge
Signed-off-by: Stephen Rothwell
---
drivers/nvme/host/rdma.c | 2 +-
drivers/nvme/target/rdma.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index cfa0319fcd1c..368fe5ac0c6b 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -378,7 +378,7 @@ nvme_rdma_find_get_device(struct rdma_cm_id *cm_id)
}
ndev->num_inline_segments = min(NVME_RDMA_MAX_INLINE_SEGMENTS,
- ndev->dev->attrs.max_sge - 1);
+ ndev->dev->attrs.max_send_sge - 1);
list_add(>entry, _list);
out_unlock:
mutex_unlock(_list_mutex);
diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
index 86121a7a19b2..8c30ac7d8078 100644
--- a/drivers/nvme/target/rdma.c
+++ b/drivers/nvme/target/rdma.c
@@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)
inline_page_count = num_pages(port->inline_data_size);
inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
- cm_id->device->attrs.max_sge) - 1;
+ cm_id->device->attrs.max_send_sge) - 1;
if (inline_page_count > inline_sge_count) {
pr_warn("inline_data_size %d cannot be supported by device %s.
Reducing to %lu.\n",
port->inline_data_size, cm_id->device->name,
--
2.18.0
--
Cheers,
Stephen Rothwell
pgpcIpnrcEv73.pgp
Description: OpenPGP digital signature
Re: [PATCH] net/rds/Kconfig: RDS should depend on IPV6
On 07/26/2018 06:36 AM, Santosh Shilimkar wrote:
On 7/25/2018 3:20 PM, Anders Roxell wrote:
Build error, implicit declaration of function __inet6_ehashfn shows up
When RDS is enabled but not IPV6.
net/rds/connection.c: In function ‘rds_conn_bucket’:
net/rds/connection.c:67:9: error: implicit declaration of function
‘__inet6_ehashfn’; did you mean ‘__inet_ehashfn’?
[-Werror=implicit-function-declaration]
hash = __inet6_ehashfn(lhash, 0, fhash, 0, rds_hash_secret);
^~~
__inet_ehashfn
Current code adds IPV6 as a depends on in config RDS.
Fixes: eee2fa6ab322 ("rds: Changing IP address internal representation
to struct in6_addr")
Signed-off-by: Anders Roxell
---
net/rds/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rds/Kconfig b/net/rds/Kconfig
index 41f75563b54b..607128f10bcd 100644
--- a/net/rds/Kconfig
+++ b/net/rds/Kconfig
@@ -1,7 +1,7 @@
config RDS
tristate "The RDS Protocol"
- depends on INET
+ depends on INET && CONFIG_IPV6
This should build without CONFIG_IPV6 too.
Hi Ka-cheong,
Can you please loot at it ? I know you modified
lookup function to take always in6_addr now, but
probably hashing with '__inet_ehashfn' should
work too for non IPV6 address(s).
I guess for now, let's add this dependency first. I
will do a follow up patch to remove this dependency.
Thanks.
--
K. Poon
ka-cheong.p...@oracle.com
Re: linux-next: build warning after merge of the rdma tree
On Wed, 2018-07-25 at 21:05 -0600, Jason Gunthorpe wrote:
> On Thu, Jul 26, 2018 at 10:55:53AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the rdma tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > net/sunrpc/xprtrdma/svc_rdma_rw.c: In function 'svc_rdma_post_chunk_ctxt':
> > net/sunrpc/xprtrdma/svc_rdma_rw.c:350:5: warning: 'bad_wr' may be used
> > uninitialized in this function [-Wmaybe-uninitialized]
> > if (bad_wr != first_wr)
> > ^
>
> Huh. I'm quite surprised 0-day build service didn't warn on this.
>
> > Introduced by commit
> >
> > ed288d74a9e5 ("net/xprtrdma: Simplify ib_post_(send|recv|srq_recv)()
> > calls")
> >
> > This is an actual problem.
>
> Yes, for sure. Bart?
Thanks Stephen for having reported this. I propose to revert the changes in
net/sunrpc/xprtrdma/svc_rdma_rw.c. Jason, do you want me to submit the below
as a formal patch?
Thanks,
Bart.
diff --git a/net/sunrpc/xprtrdma/svc_rdma_rw.c
b/net/sunrpc/xprtrdma/svc_rdma_rw.c
index 80975427f523..ce3ea8419704 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_rw.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_rw.c
@@ -329,7 +329,7 @@ static int svc_rdma_post_chunk_ctxt(struct
svc_rdma_chunk_ctxt *cc)
do {
if (atomic_sub_return(cc->cc_sqecount,
>sc_sq_avail) > 0) {
- ret = ib_post_send(rdma->sc_qp, first_wr, NULL);
+ ret = ib_post_send(rdma->sc_qp, first_wr, _wr);
trace_svcrdma_post_rw(>cc_cqe,
cc->cc_sqecount, ret);
if (ret)
Re: [PATCH] ACPI / LPSS: Avoid PM quirks on suspend and resume from S3
Hi Rafael,
> On 2018Jul24, at 18:36, Rafael J. Wysocki wrote:
>
> On Tuesday, July 24, 2018 11:13:42 AM CEST Rafael J. Wysocki wrote:
>> On Tuesday, July 24, 2018 10:46:09 AM CEST Kai Heng Feng wrote:
>>> Hi Rafael,
>>>
On Jun 13, 2018, at 7:17 PM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
It is reported that commit a192aa923b66a (ACPI / LPSS: Consolidate
runtime PM and system sleep handling) introduced a system suspend
regression on some machines, but the only functional change made by
it was to cause the PM quirks in the LPSS to also be used during
system suspend and resume. While that should always work for
suspend-to-idle, it turns out to be problematic for S3
(suspend-to-RAM).
To address that issue restore the previous S3 suspend and resume
behavior of the LPSS to avoid applying PM quirks then.
>>>
>>> The users reported that this patch does fix the S3 issue, but the S4 still
>>> fails.
>>>
>>> Please refer to [1] for more for user's testing result.
>>>
>>> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950/comments/60
>>
>> Please ask the users to test the patch below, then, on top of the $subject
>> one.
>
> There was a mistake in the previous patch I posted, sorry about that.
>
> Please test this one instead:
The result is positive, thanks!
Kai-Heng
>
> ---
> drivers/acpi/acpi_lpss.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> Index: linux-pm/drivers/acpi/acpi_lpss.c
> ===
> --- linux-pm.orig/drivers/acpi/acpi_lpss.c
> +++ linux-pm/drivers/acpi/acpi_lpss.c
> @@ -879,6 +879,7 @@ static void acpi_lpss_dismiss(struct dev
> #define LPSS_GPIODEF0_DMA_LLP BIT(13)
>
> static DEFINE_MUTEX(lpss_iosf_mutex);
> +static bool lpss_iosf_d3_entered;
>
> static void lpss_iosf_enter_d3_state(void)
> {
> @@ -921,6 +922,9 @@ static void lpss_iosf_enter_d3_state(voi
>
> iosf_mbi_modify(LPSS_IOSF_UNIT_LPIOEP, MBI_CR_WRITE,
> LPSS_IOSF_GPIODEF0, value1, mask1);
> +
> + lpss_iosf_d3_entered = true;
> +
> exit:
> mutex_unlock(_iosf_mutex);
> }
> @@ -935,6 +939,11 @@ static void lpss_iosf_exit_d3_state(void
>
> mutex_lock(_iosf_mutex);
>
> + if (!lpss_iosf_d3_entered)
> + goto exit;
> +
> + lpss_iosf_d3_entered = false;
> +
> iosf_mbi_modify(LPSS_IOSF_UNIT_LPIOEP, MBI_CR_WRITE,
> LPSS_IOSF_GPIODEF0, value1, mask1);
>
> @@ -944,13 +953,13 @@ static void lpss_iosf_exit_d3_state(void
> iosf_mbi_modify(LPSS_IOSF_UNIT_LPIO1, MBI_CFG_WRITE,
> LPSS_IOSF_PMCSR, value2, mask2);
>
> +exit:
> mutex_unlock(_iosf_mutex);
> }
>
> -static int acpi_lpss_suspend(struct device *dev, bool runtime)
> +static int acpi_lpss_suspend(struct device *dev, bool wakeup)
> {
> struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> - bool wakeup = runtime || device_may_wakeup(dev);
> int ret;
>
> if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
> @@ -963,14 +972,14 @@ static int acpi_lpss_suspend(struct devi
>* wrong status for devices being about to be powered off. See
>* lpss_iosf_enter_d3_state() for further information.
>*/
> - if ((runtime || !pm_suspend_via_firmware()) &&
> + if (acpi_target_system_state() == ACPI_STATE_S0 &&
> lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
> lpss_iosf_enter_d3_state();
>
> return ret;
> }
>
> -static int acpi_lpss_resume(struct device *dev, bool runtime)
> +static int acpi_lpss_resume(struct device *dev)
> {
> struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> int ret;
> @@ -979,8 +988,7 @@ static int acpi_lpss_resume(struct devic
>* This call is kept first to be in symmetry with
>* acpi_lpss_runtime_suspend() one.
>*/
> - if ((runtime || !pm_resume_via_firmware()) &&
> - lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
> + if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
> lpss_iosf_exit_d3_state();
>
> ret = acpi_dev_resume(dev);
> @@ -1004,12 +1012,12 @@ static int acpi_lpss_suspend_late(struct
> return 0;
>
> ret = pm_generic_suspend_late(dev);
> - return ret ? ret : acpi_lpss_suspend(dev, false);
> + return ret ? ret : acpi_lpss_suspend(dev, device_may_wakeup(dev));
> }
>
> static int acpi_lpss_resume_early(struct device *dev)
> {
> - int ret = acpi_lpss_resume(dev, false);
> + int ret = acpi_lpss_resume(dev);
>
> return ret ? ret : pm_generic_resume_early(dev);
> }
> @@ -1024,7 +1032,7 @@ static int acpi_lpss_runtime_suspend(str
>
> static int acpi_lpss_runtime_resume(struct device *dev)
> {
> - int ret = acpi_lpss_resume(dev, true);
> + int
[PATCH 1/4] ARM: dts: mvebu: 98dx3236: Rename nand controller node
Update the 98dx3236 SoC and dependent boards to use
"nand-controller" instead of "nand".
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-db-dxbc2.dts | 2 +-
arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
index 8d708cc22495..eb03a5773903 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -189,7 +189,7 @@
};
};
- nand: nand@d {
+ nand_controller: nand-controller@d {
clocks = <_coredivclk 0>;
};
diff --git a/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
b/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
index f42fc6118b7c..944e0a9c9dac 100644
--- a/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
+++ b/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
@@ -68,7 +68,7 @@
status = "okay";
};
- {
+_controller {
status = "okay";
label = "pxa3xx_nand-0";
num-cs = <1>;
diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
index 8432f517e346..d58ea48cb151 100644
--- a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
+++ b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
@@ -67,7 +67,7 @@
status = "okay";
};
- {
+_controller {
status = "okay";
label = "pxa3xx_nand-0";
num-cs = <1>;
--
2.18.0
[PATCH 0/4] ARM: dts: mvebu: updates and new board
This series updates the armada-xp-98dx3236 SoC and related boards to use the new style dts bindings for nand. I've also added a new db-88f6820-amc board which is an Armada-385 based reference board from Marvell's switch team. It's a plugin card for either the db-dxbc2 or db-xc3-24g4 which can be used if you disable the internal CPU on those platforms. Chris Packham (4): ARM: dts: mvebu: 98dx3236: Rename nand controller node ARM: dts: mvebu: db-dxbc2: use new style nand binding ARM: dts: mvebu: db-xc3-24g4: use new style nand binding ARM: dts: mvebu: Add device tree for db-88f6820-amc board arch/arm/boot/dts/Makefile| 1 + .../boot/dts/armada-385-db-88f6820-amc.dts| 184 ++ arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +- arch/arm/boot/dts/armada-xp-db-dxbc2.dts | 18 +- arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 18 +- 5 files changed, 208 insertions(+), 15 deletions(-) create mode 100644 arch/arm/boot/dts/armada-385-db-88f6820-amc.dts -- 2.18.0
[PATCH v3 1/4] dt-bindings: dmaengine: Add binding for Actions Semi Owl SoCs
Add devicetree binding for Actions Semi Owl SoCs DMA controller.
Signed-off-by: Manivannan Sadhasivam
---
.../devicetree/bindings/dma/owl-dma.txt | 47 +++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.txt
b/Documentation/devicetree/bindings/dma/owl-dma.txt
new file mode 100644
index ..03e9bb12b75f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/owl-dma.txt
@@ -0,0 +1,47 @@
+* Actions Semi Owl SoCs DMA controller
+
+This binding follows the generic DMA bindings defined in dma.txt.
+
+Required properties:
+- compatible: Should be "actions,s900-dma".
+- reg: Should contain DMA registers location and length.
+- interrupts: Should contain 4 interrupts shared by all channel.
+- #dma-cells: Must be <1>. Used to represent the number of integer
+ cells in the dmas property of client device.
+- dma-channels: Physical channels supported.
+- dma-requests: Number of DMA request signals supported by the controller.
+Refer to Documentation/devicetree/bindings/dma/dma.txt
+- clocks: Phandle and Specifier of the clock feeding the DMA controller.
+
+Example:
+
+Controller:
+dma: dma-controller@e026 {
+compatible = "actions,s900-dma";
+reg = <0x0 0xe026 0x0 0x1000>;
+interrupts = ,
+ ,
+ ,
+ ;
+#dma-cells = <1>;
+dma-channels = <12>;
+dma-requests = <46>;
+clocks = < CLK_DMAC>;
+};
+
+Client:
+
+DMA clients connected to the Actions Semi Owl SoCs DMA controller must
+use the format described in the dma.txt file, using a two-cell specifier
+for each channel.
+
+The two cells in order are:
+1. A phandle pointing to the DMA controller.
+2. The channel id.
+
+uart5: serial@e012a000 {
+...
+dma-names = "tx", "rx";
+dmas = < 26>, < 27>;
+...
+};
--
2.17.1
[PATCH v3 2/4] arm64: dts: actions: Add Actions Semi S900 DMA Controller
Add DMA controller node for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index 7ae8b931f000..2e8178e50832 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -191,6 +191,19 @@
;
};
+ dma: dma-controller@e026 {
+ compatible = "actions,s900-dma";
+ reg = <0x0 0xe026 0x0 0x1000>;
+ interrupts = ,
+,
+,
+;
+ #dma-cells = <1>;
+ dma-channels = <12>;
+ dma-requests = <46>;
+ clocks = < CLK_DMAC>;
+ };
+
timer: timer@e0228000 {
compatible = "actions,s900-timer";
reg = <0x0 0xe0228000 0x0 0x8000>;
--
2.17.1
[PATCH v3 0/4] Add Actions Semi Owl family S900 DMA Controller support
This patchset adds DMA controller support for Actions Semi Owl family S900 SoC. This driver has been structured in a way such that there will be only one controller driver for the whole Owl family series (S500, S700 and S900 SoCs). There are 12 physical channels and 46 logical channels supported by the DMA controller. The DMA controller also supports 4 software configurable interrupt lines for the priority based DMA usecase. But the DMA driver supports only 1 interrupt for simplification. By default, the driver uses Linked list mode for all transfers. Right now only MEMCPY support has been added and the rest (SLAVE, CYCLIC) will be added in upcoming patches. The driver has been tested using dmatest utility on the Bubblegum-96 board. The DTS patches in this series depends on the pinctrl DTS patches submitted [1], which is yet to be merged by the platform maintainer Andreas. Since the DMA driver goes through DMA tree and the relevant DTS patches goes through ARM-SoC tree, Andreas will pick it up once it has been reviewed. For the reference, I have queued up all reviewed dts patches so far in my repo [2] from which Andreas is picking them for 4.19. Thanks, Mani [1] https://patchwork.kernel.org/patch/10322937/ [2] https://git.linaro.org/people/manivannan.sadhasivam/linux.git/log/?h=s900-for-next Changes in v3: As per Vinod's review: * Removed unused header and API's * Used GENMASK for defines * Removed per member comment for structs * Modified pchan* and dma* API's to use corresponding containers as arguments * Removed error messages regarding the no free channels * Added devm_free_irq in dma_remove * Used dmaengine instead of dma for commit titles Changes in v2: * Fixed up the multi-line alignments according to `checkpatch --strict` Manivannan Sadhasivam (4): dt-bindings: dmaengine: Add binding for Actions Semi Owl SoCs arm64: dts: actions: Add Actions Semi S900 DMA Controller dmaengine: Add Actions Semi Owl family S900 DMA driver MAINTAINERS: Add entry for Actions Semi Owl SoCs DMA driver .../devicetree/bindings/dma/owl-dma.txt | 47 + MAINTAINERS | 2 + arch/arm64/boot/dts/actions/s900.dtsi | 13 + drivers/dma/Kconfig | 8 + drivers/dma/Makefile | 1 + drivers/dma/owl-dma.c | 971 ++ 6 files changed, 1042 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt create mode 100644 drivers/dma/owl-dma.c -- 2.17.1
[PATCH v3 3/4] dmaengine: Add Actions Semi Owl family S900 DMA driver
Add Actions Semi Owl family S900 DMA driver. Signed-off-by: Manivannan Sadhasivam --- drivers/dma/Kconfig | 8 + drivers/dma/Makefile | 1 + drivers/dma/owl-dma.c | 971 ++ 3 files changed, 980 insertions(+) create mode 100644 drivers/dma/owl-dma.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index ca1680afa20a..92a278e6618c 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -413,6 +413,14 @@ config NBPFAXI_DMA help Support for "Type-AXI" NBPF DMA IPs from Renesas +config OWL_DMA + tristate "Actions Semi Owl SoCs DMA support" + depends on ARCH_ACTIONS + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + help + Enable support for the Actions Semi Owl SoCs DMA controller. + config PCH_DMA tristate "Intel EG20T PCH / LAPIS Semicon IOH(ML7213/ML7223/ML7831) DMA" depends on PCI && (X86_32 || COMPILE_TEST) diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index 203a99d68315..c91702d88b95 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_MV_XOR_V2) += mv_xor_v2.o obj-$(CONFIG_MXS_DMA) += mxs-dma.o obj-$(CONFIG_MX3_IPU) += ipu/ obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o +obj-$(CONFIG_OWL_DMA) += owl-dma.o obj-$(CONFIG_PCH_DMA) += pch_dma.o obj-$(CONFIG_PL330_DMA) += pl330.o obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/ diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c new file mode 100644 index ..7812a6338acd --- /dev/null +++ b/drivers/dma/owl-dma.c @@ -0,0 +1,971 @@ +// SPDX-License-Identifier: GPL-2.0+ +// +// Actions Semi Owl SoCs DMA driver +// +// Copyright (c) 2014 Actions Semi Inc. +// Author: David Liu +// +// Copyright (c) 2018 Linaro Ltd. +// Author: Manivannan Sadhasivam + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "virt-dma.h" + +#define OWL_DMA_FRAME_MAX_LENGTH 0xf + +/* Global DMA Controller Registers */ +#define OWL_DMA_IRQ_PD00x00 +#define OWL_DMA_IRQ_PD10x04 +#define OWL_DMA_IRQ_PD20x08 +#define OWL_DMA_IRQ_PD30x0C +#define OWL_DMA_IRQ_EN00x10 +#define OWL_DMA_IRQ_EN10x14 +#define OWL_DMA_IRQ_EN20x18 +#define OWL_DMA_IRQ_EN30x1C +#define OWL_DMA_SECURE_ACCESS_CTL 0x20 +#define OWL_DMA_NIC_QOS0x24 +#define OWL_DMA_DBGSEL 0x28 +#define OWL_DMA_IDLE_STAT 0x2C + +/* Channel Registers */ +#define OWL_DMA_CHAN_BASE(i) (0x100 + (i) * 0x100) +#define OWL_DMAX_MODE 0x00 +#define OWL_DMAX_SOURCE0x04 +#define OWL_DMAX_DESTINATION 0x08 +#define OWL_DMAX_FRAME_LEN 0x0C +#define OWL_DMAX_FRAME_CNT 0x10 +#define OWL_DMAX_REMAIN_FRAME_CNT 0x14 +#define OWL_DMAX_REMAIN_CNT0x18 +#define OWL_DMAX_SOURCE_STRIDE 0x1C +#define OWL_DMAX_DESTINATION_STRIDE0x20 +#define OWL_DMAX_START 0x24 +#define OWL_DMAX_PAUSE 0x28 +#define OWL_DMAX_CHAINED_CTL 0x2C +#define OWL_DMAX_CONSTANT 0x30 +#define OWL_DMAX_LINKLIST_CTL 0x34 +#define OWL_DMAX_NEXT_DESCRIPTOR 0x38 +#define OWL_DMAX_CURRENT_DESCRIPTOR_NUM0x3C +#define OWL_DMAX_INT_CTL 0x40 +#define OWL_DMAX_INT_STATUS0x44 +#define OWL_DMAX_CURRENT_SOURCE_POINTER0x48 +#define OWL_DMAX_CURRENT_DESTINATION_POINTER 0x4C + +/* OWL_DMAX_MODE Bits */ +#define OWL_DMA_MODE_TS(x) (((x) & GENMASK(5, 0)) << 0) +#define OWL_DMA_MODE_ST(x) (((x) & GENMASK(1, 0)) << 8) +#defineOWL_DMA_MODE_ST_DEV OWL_DMA_MODE_ST(0) +#defineOWL_DMA_MODE_ST_DCU OWL_DMA_MODE_ST(2) +#defineOWL_DMA_MODE_ST_SRAMOWL_DMA_MODE_ST(3) +#define OWL_DMA_MODE_DT(x) (((x) & GENMASK(1, 0)) << 10) +#defineOWL_DMA_MODE_DT_DEV OWL_DMA_MODE_DT(0) +#defineOWL_DMA_MODE_DT_DCU OWL_DMA_MODE_DT(2) +#defineOWL_DMA_MODE_DT_SRAMOWL_DMA_MODE_DT(3) +#define OWL_DMA_MODE_SAM(x)(((x) & GENMASK(1, 0)) << 16) +#defineOWL_DMA_MODE_SAM_CONST OWL_DMA_MODE_SAM(0) +#defineOWL_DMA_MODE_SAM_INCOWL_DMA_MODE_SAM(1) +#defineOWL_DMA_MODE_SAM_STRIDE
Re: [PATCH] mmc: host: iproc: Add ACPI support to IPROC SDHCI
Hi Ulf Hansson,
Kindly review this patch.
Thank you,
Regards,
Srinath.
On Tue, Jul 17, 2018 at 10:15 PM, Srinath Mannam
wrote:
> Add ACPI support to all IPROC SDHCI varients
>
> Signed-off-by: Srinath Mannam
> Reviewed-by: Ray Jui
> Reviewed-by: Scott Branden
> Reviewed-by: Vladimir Olovyannikov
> ---
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-iproc.c | 187
> -
> 2 files changed, 128 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 0581c19..bc6702e 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -334,6 +334,7 @@ config MMC_SDHCI_IPROC
> tristate "SDHCI support for the BCM2835 & iProc SD/MMC Controller"
> depends on ARCH_BCM2835 || ARCH_BCM_IPROC || COMPILE_TEST
> depends on MMC_SDHCI_PLTFM
> + depends on OF || ACPI
> default ARCH_BCM_IPROC
> select MMC_SDHCI_IO_ACCESSORS
> help
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index d0e83db..7c5c923 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -15,6 +15,7 @@
> * iProc SDHCI platform driver
> */
>
> +#include
> #include
> #include
> #include
> @@ -162,9 +163,19 @@ static void sdhci_iproc_writeb(struct sdhci_host *host,
> u8 val, int reg)
> sdhci_iproc_writel(host, newval, reg & ~3);
> }
>
> +static unsigned int sdhci_iproc_get_max_clock(struct sdhci_host *host)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> +
> + if (pltfm_host->clk)
> + return sdhci_pltfm_clk_get_max_clock(host);
> + else
> + return pltfm_host->clock;
> +}
> +
> static const struct sdhci_ops sdhci_iproc_ops = {
> .set_clock = sdhci_set_clock,
> - .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> + .get_max_clock = sdhci_iproc_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> .reset = sdhci_reset,
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> @@ -178,34 +189,24 @@ static const struct sdhci_ops sdhci_iproc_32only_ops = {
> .write_w = sdhci_iproc_writew,
> .write_b = sdhci_iproc_writeb,
> .set_clock = sdhci_set_clock,
> - .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> + .get_max_clock = sdhci_iproc_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> .reset = sdhci_reset,
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> };
>
> +enum sdhci_pltfm_type {
> + SDHCI_PLTFM_IPROC_CYGNUS,
> + SDHCI_PLTFM_IPROC,
> + SDHCI_PLTFM_BCM2835,
> +};
> +
> static const struct sdhci_pltfm_data sdhci_iproc_cygnus_pltfm_data = {
> .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
> .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN | SDHCI_QUIRK2_HOST_OFF_CARD_ON,
> .ops = _iproc_32only_ops,
> };
>
> -static const struct sdhci_iproc_data iproc_cygnus_data = {
> - .pdata = _iproc_cygnus_pltfm_data,
> - .caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
> - & SDHCI_MAX_BLOCK_MASK) |
> - SDHCI_CAN_VDD_330 |
> - SDHCI_CAN_VDD_180 |
> - SDHCI_CAN_DO_SUSPEND |
> - SDHCI_CAN_DO_HISPD |
> - SDHCI_CAN_DO_ADMA2 |
> - SDHCI_CAN_DO_SDMA,
> - .caps1 = SDHCI_DRIVER_TYPE_C |
> -SDHCI_DRIVER_TYPE_D |
> -SDHCI_SUPPORT_DDR50,
> - .mmc_caps = MMC_CAP_1_8V_DDR,
> -};
> -
> static const struct sdhci_pltfm_data sdhci_iproc_pltfm_data = {
> .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
> @@ -213,21 +214,6 @@ static const struct sdhci_pltfm_data
> sdhci_iproc_pltfm_data = {
> .ops = _iproc_ops,
> };
>
> -static const struct sdhci_iproc_data iproc_data = {
> - .pdata = _iproc_pltfm_data,
> - .caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
> - & SDHCI_MAX_BLOCK_MASK) |
> - SDHCI_CAN_VDD_330 |
> - SDHCI_CAN_VDD_180 |
> - SDHCI_CAN_DO_SUSPEND |
> - SDHCI_CAN_DO_HISPD |
> - SDHCI_CAN_DO_ADMA2 |
> - SDHCI_CAN_DO_SDMA,
> - .caps1 = SDHCI_DRIVER_TYPE_C |
> -SDHCI_DRIVER_TYPE_D |
> -SDHCI_SUPPORT_DDR50,
> -};
> -
> static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = {
> .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
> SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> @@ -237,38 +223,104 @@ static const struct sdhci_pltfm_data
> sdhci_bcm2835_pltfm_data = {
> .ops = _iproc_32only_ops,
> };
>
> -static const struct sdhci_iproc_data bcm2835_data = {
> - .pdata = _bcm2835_pltfm_data,
> - .caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
> - & SDHCI_MAX_BLOCK_MASK) |
> -
[PATCH v3 4/4] MAINTAINERS: Add entry for Actions Semi Owl SoCs DMA driver
Add entry for Actions Semi Owl SoCs DMA driver under ARM/ACTIONS. Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 09b54e9ebc6f..56d9c7715c2a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1145,12 +1145,14 @@ F: arch/arm/boot/dts/owl-* F: arch/arm64/boot/dts/actions/ F: drivers/clk/actions/ F: drivers/clocksource/owl-* +F: drivers/dma/owl-dma.c F: drivers/pinctrl/actions/* F: drivers/soc/actions/ F: include/dt-bindings/power/owl-* F: include/linux/soc/actions/ F: Documentation/devicetree/bindings/arm/actions.txt F: Documentation/devicetree/bindings/clock/actions,s900-cmu.txt +F: Documentation/devicetree/bindings/dma/owl-dma.txt F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt F: Documentation/devicetree/bindings/power/actions,owl-sps.txt F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt -- 2.17.1
Re: linux-next: build warning after merge of the sound-asoc tree
On 7/26/2018 7:49 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_probe':
> sound/soc/amd/acp-da7219-max98357a.c:367:3: warning: 'ret' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>dev_err(>dev, "Failed to register regulator: %d\n",
>^
> ret);
>
>
> Introduced by commit
>
> 7b5317aa809f ("ASoC: AMD: Add a fix voltage regulator for DA7219 and
> ADAU7002")
>
> This is a real bug.
>
Posted the fix for the above warning message:
https://patchwork.kernel.org/patch/10545235/
Thanks,
Akshu
Re: [PATCH 2/3] mm: calculate deferred pages after skipping mirrored memory
On Tue, 24 Jul 2018 21:46:25 -0400 Pavel Tatashin
wrote:
> > > +static inline bool defer_init(int nid, unsigned long pfn, unsigned long
> > > end_pfn)
> > > {
> > > + static unsigned long prev_end_pfn, nr_initialised;
> >
> > So answer me quick, what happens with a static variable in an inlined
> > function? Is there one copy kernel-wide? One copy per invocation
> > site? One copy per compilation unit?
> >
> > Well I didn't know so I wrote a little test. One copy per compilation
> > unit (.o file), it appears.
> >
> > It's OK in this case because the function is in .c (and has only one
> > call site). But if someone moves it into a header and uses it from a
> > different .c file, they have problems.
> >
> > So it's dangerous, and poor practice. I'll make this non-static
> > __meminit.
>
> I agree, it should not be moved to header it is dangerous.
>
> But, on the other hand this is a hot-path. memmap_init_zone() might
> need to go through billions of struct pages early in boot, and I did
> not want us to waste time on function calls. With defer_init() this is
> not a problem, because if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set
> memmap_init_zone() won't have much work to do, but for
> overlap_memmap_init() this is a problem, especially because I expect
> compiler to optimize the pfn dereference usage in inline function.
Well. The compiler will just go and inline defer_init() anwyay - it
has a single callsite and is in the same __meminint section as its
calling function. My gcc-7.2.0 does this. Marking it noninline
__meminit is basically syntactic fluff designed to encourage people to
think twice.
> >
> > ---
> > a/mm/page_alloc.c~mm-calculate-deferred-pages-after-skipping-mirrored-memory-fix
> > +++ a/mm/page_alloc.c
> > @@ -309,7 +309,8 @@ static inline bool __meminit early_page_
> > * Returns true when the remaining initialisation should be deferred until
> > * later in the boot cycle when it can be parallelised.
> > */
> > -static inline bool defer_init(int nid, unsigned long pfn, unsigned long
> > end_pfn)
> > +static bool __meminit
> > +defer_init(int nid, unsigned long pfn, unsigned long end_pfn)
> > {
> > static unsigned long prev_end_pfn, nr_initialised;
> >
> >
> > Also, what locking protects these statics? Our knowledge that this
> > code is single-threaded, presumably?
>
> Correct, this is called only from "context == MEMMAP_EARLY", way
> before smp_init().
Might be worth a little comment to put readers minds at ease.
Re: [PATCH -next] fs/epoll: simply CONFIG_NET_RX_BUSY_POLL ifdefery
On Wed, 25 Jul 2018 13:06:33 -0700 Davidlohr Bueso wrote:
> >> +#else
> >> +#define ep_busy_loop(ep, nonblock)do { } while (0)
> >> +#define ep_reset_busy_poll_napi_id(ep)do { } while (0)
> >> +#define ep_set_busy_poll_napi_id(epi) do { } while (0)
> >> +
> >> +#endif /* CONFIG_NET_RX_BUSY_POLL */
> >
> >inlines are preferred. Because macros are fugly and can cause
> >unused-var warnings when the stub versions are used.
>
> Fair enough.
>
> >This?
>
> Do you want me to send a v2 or will you fold in the below?
I queued both patches.
Re: [PATCH v2 0/6] kaddr and pfn can be NULL to ->direct_access()
Pretty straight forward series. Huaisheng, I can apply the whole series to libnvdimm if we can get ack's from maintainer of dcssblk and dm-writecache for the respective bits. On 07/25/2018 09:28 AM, Huaisheng Ye wrote: > From: Huaisheng Ye > > Changes since v1 [1]: > * Involve the previous patches for pfn can be NULL. > * Reword the patch descriptions according to Christian's comment. > * According to Ross's suggestion, replace local pointer dummy_addr > with NULL within md/dm-writecache for direct_access. > > [1]: https://lkml.org/lkml/2018/7/24/199 > > Some functions within fs/dax, dax/super and md/dm-writecache don't > need to get local pointer kaddr or variable pfn from direct_access. > Assigning NULL to kaddr or pfn to ->direct_access() is more > straightforward and simple than offering a useless local pointer or > variable. > > So all ->direct_access() need to check the validity of pointer kaddr > and pfn for NULL assignment. If either of them is equal to NULL, that > is to say callers may have no need for kaddr or pfn, so this series of > patch are prepared for allowing them to pass in NULL instead of having > to pass in a local pointer or variable that they then just throw away. > > Huaisheng Ye (6): > libnvdimm, pmem: kaddr and pfn can be NULL to ->direct_access() > s390, dcssblk: kaddr and pfn can be NULL to ->direct_access() > tools/testing/nvdimm: kaddr and pfn can be NULL to ->direct_access() > dax/super: Do not request a pointer kaddr when not required > md/dm-writecache: Don't request pointer dummy_addr when not required > filesystem-dax: Do not request kaddr and pfn when not required > > drivers/dax/super.c | 3 +-- > drivers/md/dm-writecache.c | 3 +-- > drivers/nvdimm/pmem.c | 7 +-- > drivers/s390/block/dcssblk.c| 8 +--- > fs/dax.c| 13 - > tools/testing/nvdimm/pmem-dax.c | 12 > 6 files changed, 24 insertions(+), 22 deletions(-) >
Re: [PATCH 1/6] RISC-V: simplify software interrupt / IPI code
On Wed, 25 Jul 2018 02:36:44 PDT (-0700), Christoph Hellwig wrote:
Rename handle_ipi to riscv_software_interrupt, drop the unused return
value and provide a stub for the !SMP build. This allows simplifying
the upcoming interrupt controller driver by not providing a wrapper
for it.
Signed-off-by: Christoph Hellwig
---
arch/riscv/include/asm/smp.h | 13 +++--
arch/riscv/kernel/smp.c | 6 ++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index 85e4220839b0..80ecb957fe9f 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -44,8 +44,17 @@ void arch_send_call_function_single_ipi(int cpu);
*/
#define raw_smp_processor_id() (*((int*)((char*)get_current() + TASK_TI_CPU)))
-/* Interprocessor interrupt handler */
-irqreturn_t handle_ipi(void);
+/* Software interrupt handler */
+void riscv_software_interrupt(void);
+
+#else /* CONFIG_SMP */
+
+/*
+ * We currently only use software interrupts to pass inter-processor
+ * interrupts, so if a non-SMP system gets a software interrupt then we
+ * don't know what to do.
+ */
+#define riscv_software_interrupt() WARN_ON()
#endif /* CONFIG_SMP */
diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index 6d3962435720..906fe21ea21b 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -45,7 +45,7 @@ int setup_profiling_timer(unsigned int multiplier)
return -EINVAL;
}
-irqreturn_t handle_ipi(void)
+void riscv_software_interrupt(void)
{
unsigned long *pending_ipis = _data[smp_processor_id()].bits;
@@ -60,7 +60,7 @@ irqreturn_t handle_ipi(void)
ops = xchg(pending_ipis, 0);
if (ops == 0)
- return IRQ_HANDLED;
+ return;
if (ops & (1 << IPI_RESCHEDULE))
scheduler_ipi();
@@ -73,8 +73,6 @@ irqreturn_t handle_ipi(void)
/* Order data access and bit testing. */
mb();
}
-
- return IRQ_HANDLED;
}
static void
Acked-by: Palmer Dabbelt
I think it's probably easier to have the whole patch set go through the IRQ
tree, so I won't put these in the RISC-V tree unless someone says something.
Re: [PATCH 2/6] RISC-V: remove INTERRUPT_CAUSE_* defines from asm/irq.h
On Wed, 25 Jul 2018 02:36:45 PDT (-0700), Christoph Hellwig wrote: These are only of use to the local irq controller driver, so add them in that driver implementation instead, which will be submitted soon. Signed-off-by: Christoph Hellwig --- arch/riscv/include/asm/irq.h | 4 1 file changed, 4 deletions(-) diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h index 4dee9d4c13c0..93eb75eac4ff 100644 --- a/arch/riscv/include/asm/irq.h +++ b/arch/riscv/include/asm/irq.h @@ -17,10 +17,6 @@ #define NR_IRQS 0 -#define INTERRUPT_CAUSE_SOFTWARE1 -#define INTERRUPT_CAUSE_TIMER 5 -#define INTERRUPT_CAUSE_EXTERNAL9 - void riscv_timer_interrupt(void); #include Acked-by: Palmer Dabbelt
Re: [PATCH v1 1/4] igb: Remove unnecessary include of
On Wed, 2018-07-25 at 14:52 -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > The igb driver doesn't need anything provided by pci-aspm.h, so > remove > the unnecessary include of it. > > Signed-off-by: Bjorn Helgaas Acked-by: Jeff Kirsher I am fine with you picking up this change. > --- > drivers/net/ethernet/intel/igb/igb_main.c |1 - > 1 file changed, 1 deletion(-) signature.asc Description: This is a digitally signed message part
OOM in secondary cgroup leading to networking lose
Hi friends, We observed a sequence of events starting from an OOM in a secondary cgroup which ends up in the bond interface being down for a period of up to 12 seconds. Below is some piece of dmesg about when the bond interface went down: [Wed Jul 25 19:20:45 2018] Call Trace: [Wed Jul 25 19:20:45 2018] [Wed Jul 25 19:20:45 2018] ? dev_deactivate_queue.constprop.29+0x60/0x60 [Wed Jul 25 19:20:45 2018] call_timer_fn+0x30/0x120 [Wed Jul 25 19:20:45 2018] run_timer_softirq+0x3c8/0x420 [Wed Jul 25 19:20:45 2018] ? timerqueue_add+0x52/0x80 [Wed Jul 25 19:20:45 2018] ? enqueue_hrtimer+0x37/0x80 [Wed Jul 25 19:20:45 2018] ? recalibrate_cpu_khz+0x10/0x10 [Wed Jul 25 19:20:45 2018] __do_softirq+0xde/0x2b3 [Wed Jul 25 19:20:45 2018] irq_exit+0xae/0xb0 [Wed Jul 25 19:20:45 2018] smp_apic_timer_interrupt+0x70/0x120 [Wed Jul 25 19:20:45 2018] apic_timer_interrupt+0x7d/0x90 [Wed Jul 25 19:20:45 2018] [Wed Jul 25 19:20:45 2018] RIP: 0010:cpuidle_enter_state+0xa2/0x2e0 [Wed Jul 25 19:20:45 2018] RSP: 0018:9c403eb0 EFLAGS: 0246 ORIG_RAX: ff10 [Wed Jul 25 19:20:45 2018] RAX: 9075c0821a40 RBX: 0006cdb159b6000e RCX: 001f [Wed Jul 25 19:20:45 2018] RDX: 0006cdb159b6000e RSI: ffed6f2696159a35 RDI: [Wed Jul 25 19:20:45 2018] RBP: d3edc100b900 R08: 0f48 R09: 0cfe [Wed Jul 25 19:20:45 2018] R10: 9c403e90 R11: 0f12 R12: 0003 [Wed Jul 25 19:20:45 2018] R13: 9c4b03d8 R14: R15: 0006cdb159783c8e [Wed Jul 25 19:20:45 2018] do_idle+0x181/0x1e0 [Wed Jul 25 19:20:45 2018] cpu_startup_entry+0x19/0x20 [Wed Jul 25 19:20:45 2018] start_kernel+0x400/0x408 [Wed Jul 25 19:20:45 2018] secondary_startup_64+0xa5/0xb0 [Wed Jul 25 19:20:45 2018] Code: 63 8e 60 04 00 00 eb 8f 4c 89 f7 c6 05 79 c7 b8 00 01 e8 00 7c fd ff 89 d9 48 89 c2 4c 89 f6 48 c7 c7 f0 38 28 9c e8 c7 a3 b6 ff <0f> 0b eb bd 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 57 41 56 [Wed Jul 25 19:20:45 2018] ---[ end trace 2ad2942fe3431402 ]--- [Wed Jul 25 19:20:45 2018] ixgbe :19:00.1 eno2: initiating reset due to tx timeout [Wed Jul 25 19:20:45 2018] ixgbe :19:00.1 eno2: Reset adapter [Wed Jul 25 19:20:48 2018] ixgbe :19:00.0 eno1: initiating reset due to tx timeout [Wed Jul 25 19:20:53 2018] ixgbe :19:00.0 eno1: initiating reset due to tx timeout We have observed a similar behavior on a 4.15.11 kernel we were running on a different machine, the current machine these logs are from runs a 4.14.52 kernel. A more detailed dmesg content can be found here: https://gist.github.com/bjhaid/49a1c58742ef2458984339503290ef9a I will appreciate any help in figuring out the cause and fix of this issue. Extra bit of information is the machines are Kubernetes nodes running docker. Thanks! Abejide Ayodele It always seems impossible until it's done. --Nelson Mandela
Re: [PATCH v1 2/3] thermal: tsens: switch from of_iomap() to devm_ioremap_resource()
On Wed, Jul 18, 2018 at 12:55:02PM +0530, Amit Kucheria wrote:
> devm_ioremap_resources() automatically requests resources (so that the I/O
> region shows up in /proc/iomem) and devm_ wrappers do better error handling
> and unmapping of the I/O region when needed.
>
> Signed-off-by: Amit Kucheria
> ---
> drivers/thermal/qcom/tsens-common.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens-common.c
> b/drivers/thermal/qcom/tsens-common.c
> index 25e7f24..6207d8d 100644
> --- a/drivers/thermal/qcom/tsens-common.c
> +++ b/drivers/thermal/qcom/tsens-common.c
> @@ -127,13 +127,11 @@ static const struct regmap_config tsens_config = {
> int __init init_common(struct tsens_device *tmdev)
> {
> void __iomem *base;
> + struct resource *res;
> struct platform_device *op =
> of_find_device_by_node(tmdev->dev->of_node);
>
> if (!op)
> return -EINVAL;
> - base = of_iomap(tmdev->dev->of_node, 0);
> - if (!base)
> - return -EINVAL;
>
> /* The driver only uses the TM register address space for now */
> if (op->num_resources > 1) {
> @@ -143,11 +141,14 @@ int __init init_common(struct tsens_device *tmdev)
> tmdev->tm_offset = 0x1000;
> }
>
> + res = platform_get_resource(op, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> tmdev->map = devm_regmap_init_mmio(tmdev->dev, base, _config);
> - if (IS_ERR(tmdev->map)) {
> - iounmap(base);
> + if (IS_ERR(tmdev->map))
> return PTR_ERR(tmdev->map);
> - }
>
> return 0;
> }
Reviewed-by: Matthias Kaehlcke
[PATCH v1] checkpatch: check for #if 0/#if 1
The #if 0 or #if 1 is used to toggle features. Warn if #if 0 or #if 1
is present and suggest that they can be removed.
Signed-off-by: Abhijeet Dharmapurikar
Signed-off-by: Prakruthi Deepak Heragu
---
Changes in v1:
- Rephrase the warning message to fit in a single line without
80 column limit
scripts/checkpatch.pl | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3394ed8..72513c2 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5383,9 +5383,14 @@ sub process {
# warn about #if 0
if ($line =~ /^.\s*\#\s*if\s+0\b/) {
- CHK("REDUNDANT_CODE",
- "if this code is redundant consider removing it\n" .
- $herecurr);
+ WARN("IF_0",
+"Consider removing the #if 0 and its #endif\n".
$herecurr);
+ }
+
+# warn about #if 1
+ if ($line =~ /^.\s*\#\s*if\s+1\b/) {
+ WARN("IF_1",
+"Consider removing the #if 1 and its #endif\n".
$herecurr);
}
# check for needless "if () fn()" uses
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] dt-bindings: thermal: qcom-spmi-temp-alarm: Improve thermal zone in example
Hi, On Tue, Jul 24, 2018 at 4:50 PM, Matthias Kaehlcke wrote: > The current example for a thermal zone isn't very useful as reference > since it would result in a hardware shutdown at 145°C, instead of > allowing the system to try to shutdown gracefully. Without an ADC > channel a maximum of two trip points is useful in practice for this > sensor, with temperatures corresponding to the stage 1 and stage 2 > 'hardware trip points'. A critical trip point at stage 2 may allow the > system to shutdown before a hardware shutdown at stage 3 kicks in. It > should be noted though that by default the chip performs a 'partial > shutdown' when the temperature reaches stage 2, which may prevent an > orderly shutdown. The 'partial shutdown' can be disabled by software. > > Signed-off-by: Matthias Kaehlcke > --- > .../bindings/thermal/qcom-spmi-temp-alarm.txt | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) Assuming your patch to disable the partial shutdown lands, then: Reviewed-by: Douglas Anderson ...if that patch doesn't land (or if someone disagrees with me and thinks we need an extra property to disable the partial shutdown) then we would need the example to be different. Because of that, maybe this should be appended to the end of your series which includes the patch to disable partial shutdown? -Doug
Re: [PATCH] clk: tegra: probe deferral error reporting
Quoting Marcel Ziswiler (2018-07-20 00:54:22)
> From: Marcel Ziswiler
>
> Actually report the error code from devm_regulator_get() which may as
> well just be a probe deferral.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> drivers/clk/tegra/clk-dfll.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
> index 48ee43734e05..b2123084e175 100644
> --- a/drivers/clk/tegra/clk-dfll.c
> +++ b/drivers/clk/tegra/clk-dfll.c
> @@ -1609,8 +1609,9 @@ int tegra_dfll_register(struct platform_device *pdev,
>
> td->vdd_reg = devm_regulator_get(td->dev, "vdd-cpu");
> if (IS_ERR(td->vdd_reg)) {
> - dev_err(td->dev, "couldn't get vdd_cpu regulator\n");
> - return PTR_ERR(td->vdd_reg);
> + ret = PTR_ERR(td->vdd_reg);
> + dev_err(td->dev, "couldn't get vdd_cpu regulator: %d\n", ret);
Do you want to know that a probe defer is happening? Usually patches are
sent to make that error path silent.
Re: [PATCH] clk: uniphier: add clock frequency support for SPI
Quoting Keiji Hayashibara (2018-07-18 22:23:48) > From: Kunihiko Hayashi > > Add clock control for SPI controller on UniPhier SoCs. > > Signed-off-by: Kunihiko Hayashi > Signed-off-by: Masahiro Yamada > --- Signed-off-by chain is a little weird, but I'll go with it. Applied to clk-next
Re: [PATCH] thermal: qcom-spmi: Delete unused field 'prev_stage'
Hi, On Tue, Jul 24, 2018 at 4:56 PM, Matthias Kaehlcke wrote: > The field 'prev_stage' in struct qpnp_tm_chip is not used, remove it. > > Signed-off-by: Matthias Kaehlcke > --- > drivers/thermal/qcom-spmi-temp-alarm.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Douglas Anderson
Re: linux-next: Signed-off-by missing for commit in the xarray tree
On Thu, Jul 26, 2018 at 07:28:14AM +1000, Stephen Rothwell wrote:
> Hi Matthew,
>
> Commits
>
> 890e537e2b42 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
> aaf149902c79 ("filesystem-dax: Set page->index")
>
> are missing a Signed-off-by from their committers.
Oh, hah. I assume this is an automated email?
These two commits I cherry-picked from the nvdimm tree so that XArray can
be rebased on top of it. Is there some other way I should be doing this,
like rebasing on top of the nvdimm tree?
Re: [PATCH] input: pxrc - do not store USB device in private struct
On Tue, Jul 24, 2018 at 08:09:59PM +0200, Marcus Folkesson wrote: > Hello Dmitry, > > On Tue, Jul 24, 2018 at 02:38:04AM +, Dmitry Torokhov wrote: > > Hi Marcus, > > > > On Mon, Jul 16, 2018 at 04:40:14PM +0200, Marcus Folkesson wrote: > > > The USB device is only needed during setup, so put it back after > > > initialization and do not store it in our private struct. > > > > > > Also, the USB device is a parent of USB interface so our driver > > > model rules ensure that USB device should not disappear while > > > interface device is still there. > > > So not keep a refcount on the device is safe. > > > > > > Reported-by: Alexey Khoroshilov > > > Signed-off-by: Marcus Folkesson > > > --- > > > drivers/input/joystick/pxrc.c | 22 -- > > > 1 file changed, 12 insertions(+), 10 deletions(-) > > > > > > diff --git a/drivers/input/joystick/pxrc.c b/drivers/input/joystick/pxrc.c > > > index 07a0dbd3ced2..46a7acb747bf 100644 > > > --- a/drivers/input/joystick/pxrc.c > > > +++ b/drivers/input/joystick/pxrc.c > > ... > > > > > @@ -204,23 +204,25 @@ static int pxrc_probe(struct usb_interface *intf, > > > return -ENOMEM; > > > > > > mutex_init(>pm_mutex); > > > - pxrc->udev = usb_get_dev(interface_to_usbdev(intf)); > > > + udev = usb_get_dev(interface_to_usbdev(intf)); > > > > There is really no need to "get" device for the probe duration, or in > > general, when you are not storing the reference to it. > > > > I posted series with an updated version of this patch plus couple more > > cleanups/fixes, and would appreciate if you could give it a spin. > > Thank you for doing this. > > I have reviewed the patchset and tested on real hardware, and it looks good > to me. > > For what it's worth: > > Reviewed-by: Marcus Folkesson > Tested-by: Marcus Folkesson > > On the whole patchset. Excellent, thank you. -- Dmitry
Re: [PATCH v1 3/3] thermal: tsens: Fix negative temperature reporting
On Wed, Jul 18, 2018 at 12:55:03PM +0530, Amit Kucheria wrote:
> The current code will always return 0x in case of negative
> temperatures due to a bug in how the binary sign extension is being done.
>
> Use sign_extend32() instead.
>
> Signed-off-by: Amit Kucheria
> ---
> drivers/thermal/qcom/tsens-v2.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
> index 908e3dc..46abc21 100644
> --- a/drivers/thermal/qcom/tsens-v2.c
> +++ b/drivers/thermal/qcom/tsens-v2.c
> @@ -5,19 +5,20 @@
> */
>
> #include
> +#include
> #include "tsens.h"
>
> #define STATUS_OFFSET0xa0
> #define LAST_TEMP_MASK 0xfff
> #define STATUS_VALID_BIT BIT(21)
> -#define CODE_SIGN_BITBIT(11)
>
> static int get_temp_tsens_v2(struct tsens_device *tmdev, int id, int *temp)
> {
> struct tsens_sensor *s = >sensor[id];
> u32 code;
> unsigned int status_reg;
> - int last_temp = 0, last_temp2 = 0, last_temp3 = 0, ret;
> + u32 last_temp = 0, last_temp2 = 0, last_temp3 = 0;
> + int ret;
>
> status_reg = tmdev->tm_offset + STATUS_OFFSET + s->hw_id * 4;
> ret = regmap_read(tmdev->map, status_reg, );
> @@ -54,12 +55,8 @@ static int get_temp_tsens_v2(struct tsens_device *tmdev,
> int id, int *temp)
> else if (last_temp2 == last_temp3)
> last_temp = last_temp3;
> done:
> - /* Code sign bit is the sign extension for a negative value */
> - if (last_temp & CODE_SIGN_BIT)
> - last_temp |= ~CODE_SIGN_BIT;
> -
> - /* Temperatures are in deciCelicius */
> - *temp = last_temp * 100;
> + /* Convert temperatures to milliCelicius */
nits:
s/temperatures/temperature/
s/milliCelicius/milliCelsius/
> + *temp = sign_extend32(last_temp, fls(LAST_TEMP_MASK) - 1) * 100;
>
> return 0;
> }
Reviewed-by: Matthias Kaehlcke
Re: [PATCH v2] EDAC, sb_edac: Add support for systems with segmented PCI buses
Hi Boris,
On 07/25/2018 05:22 AM, Borislav Petkov wrote:
> On Tue, Jul 24, 2018 at 03:02:13PM -0400, Masayoshi Mizuma wrote:
>> [*] KASAN report is as follows.
>
> That KASAN report is an arbitrary side-effect from the missing segmented
> support so I ripped it out from the commit message and ended up
> committing this:
Thank you so much!
- Masa
>
> ---
> From: Masayoshi Mizuma
> Date: Tue, 24 Jul 2018 15:02:13 -0400
> Subject: [PATCH] EDAC, sb_edac: Add support for systems with segmented PCI
> buses
>
> Extend the driver to check whether segment number and bus number matches
> when deciding how to group memory controller PCI devices to CPU sockets.
>
> Signed-off-by: Masayoshi Mizuma
> Reviewed-by: Tony Luck
> Cc: Mauro Carvalho Chehab
> Cc: linux-edac
> Link: http://lkml.kernel.org/r/20180724190213.26359-1-msys.miz...@gmail.com
> [ Cleanup commit message. ]
> Signed-off-by: Borislav Petkov
> ---
> drivers/edac/sb_edac.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index 4a89c8093307..07726fb00321 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -352,6 +352,7 @@ struct pci_id_table {
>
> struct sbridge_dev {
> struct list_headlist;
> + int seg;
> u8 bus, mc;
> u8 node_id, source_id;
> struct pci_dev **pdev;
> @@ -729,7 +730,8 @@ static inline int numcol(u32 mtr)
> return 1 << cols;
> }
>
> -static struct sbridge_dev *get_sbridge_dev(u8 bus, enum domain dom, int
> multi_bus,
> +static struct sbridge_dev *get_sbridge_dev(int seg, u8 bus, enum domain dom,
> +int multi_bus,
> struct sbridge_dev *prev)
> {
> struct sbridge_dev *sbridge_dev;
> @@ -747,14 +749,15 @@ static struct sbridge_dev *get_sbridge_dev(u8 bus, enum
> domain dom, int multi_bu
> : sbridge_edac_list.next, struct
> sbridge_dev, list);
>
> list_for_each_entry_from(sbridge_dev, _edac_list, list) {
> - if (sbridge_dev->bus == bus && (dom == SOCK || dom ==
> sbridge_dev->dom))
> + if ((sbridge_dev->seg == seg) && (sbridge_dev->bus == bus) &&
> + (dom == SOCK || dom == sbridge_dev->dom))
> return sbridge_dev;
> }
>
> return NULL;
> }
>
> -static struct sbridge_dev *alloc_sbridge_dev(u8 bus, enum domain dom,
> +static struct sbridge_dev *alloc_sbridge_dev(int seg, u8 bus, enum domain
> dom,
>const struct pci_id_table *table)
> {
> struct sbridge_dev *sbridge_dev;
> @@ -771,6 +774,7 @@ static struct sbridge_dev *alloc_sbridge_dev(u8 bus, enum
> domain dom,
> return NULL;
> }
>
> + sbridge_dev->seg = seg;
> sbridge_dev->bus = bus;
> sbridge_dev->dom = dom;
> sbridge_dev->n_devs = table->n_devs_per_imc;
> @@ -2246,6 +2250,7 @@ static int sbridge_get_onedevice(struct pci_dev **prev,
> struct sbridge_dev *sbridge_dev = NULL;
> const struct pci_id_descr *dev_descr = >descr[devno];
> struct pci_dev *pdev = NULL;
> + int seg = 0;
> u8 bus = 0;
> int i = 0;
>
> @@ -2276,10 +2281,12 @@ static int sbridge_get_onedevice(struct pci_dev
> **prev,
> /* End of list, leave */
> return -ENODEV;
> }
> + seg = pci_domain_nr(pdev->bus);
> bus = pdev->bus->number;
>
> next_imc:
> - sbridge_dev = get_sbridge_dev(bus, dev_descr->dom, multi_bus,
> sbridge_dev);
> + sbridge_dev = get_sbridge_dev(seg, bus, dev_descr->dom,
> + multi_bus, sbridge_dev);
> if (!sbridge_dev) {
> /* If the HA1 wasn't found, don't create EDAC second memory
> controller */
> if (dev_descr->dom == IMC1 && devno != 1) {
> @@ -2292,7 +2299,7 @@ static int sbridge_get_onedevice(struct pci_dev **prev,
> if (dev_descr->dom == SOCK)
> goto out_imc;
>
> - sbridge_dev = alloc_sbridge_dev(bus, dev_descr->dom, table);
> + sbridge_dev = alloc_sbridge_dev(seg, bus, dev_descr->dom,
> table);
> if (!sbridge_dev) {
> pci_dev_put(pdev);
> return -ENOMEM;
>
Re: [PATCH 0/10] psi: pressure stall information for CPU, memory, and IO v2
On 7/25/18 1:15 AM, Johannes Weiner wrote: > Hi Balbir, > > On Tue, Jul 24, 2018 at 07:14:02AM +1000, Balbir Singh wrote: >> Does the mechanism scale? I am a little concerned about how frequently >> this infrastructure is monitored/read/acted upon. > > I expect most users to poll in the frequency ballpark of the running > averages (10s, 1m, 5m). Our OOMD defaults to 5s polling of the 10s > average; we collect the 1m average once per minute from our machines > and cgroups to log the system/workload health trends in our fleet. > > Suren has been experimenting with adaptive polling down to the > millisecond range on Android. > I think this is a bad way of doing things, polling only adds to overheads, there needs to be an event driven mechanism and the selection of the events need to happen in user space. >> Why aren't existing mechanisms sufficient > > Our existing stuff gives a lot of indication when something *may* be > an issue, like the rate of page reclaim, the number of refaults, the > average number of active processes, one task waiting on a resource. > > But the real difference between an issue and a non-issue is how much > it affects your overall goal of making forward progress or reacting to > a request in time. And that's the only thing users really care > about. It doesn't matter whether my system is doing 2314 or 6723 page > refaults per minute, or scanned 8495 pages recently. I need to know > whether I'm losing 1% or 20% of my time on overcommitted memory. > > Delayacct is time-based, so it's a step in the right direction, but it > doesn't aggregate tasks and CPUs into compound productivity states to > tell you if only parts of your workload are seeing delays (which is > often tolerable for the purpose of ensuring maximum HW utilization) or > your system overall is not making forward progress. That aggregation > isn't something you can do in userspace with polled delayacct data. By aggregation you mean cgroup aggregation? > >> -- why is the avg delay calculation in the kernel? > > For one, as per above, most users will probably be using the standard > averaging windows, and we already have this highly optimizd > infrastructure from the load average. I don't see why we shouldn't use > that instead of exporting an obscure number that requires most users > to have an additional library or copy-paste the loadavg code. > > I also mentioned the OOM killer as a likely in-kernel user of the > pressure percentages to protect from memory livelocks out of the box, > in which case we have to do this calculation in the kernel anyway. > >> There is no talk about the overhead this introduces in general, may be >> the details are in the patches. I'll read through them > > I sent an email on benchmarks and overhead in one of the subthreads, I > will include that information in the cover letter in v3. > > https://lore.kernel.org/lkml/20180718215644.gb2...@cmpxchg.org/ Thanks, I'll take a look Balbir Singh.
Re: [PATCH] tracing: do not leak kernel addresses
On Wed, 25 Jul 2018 13:22:36 -0700 Mark Salyzyn wrote: > From: Nick Desaulniers > > Switch from 0x%lx to 0x%pK to print the kernel addresses. > > Fixes: CVE-2017-0630 Wait This breaks perf and trace-cmd! They require this to be able to print various strings in trace events. This file is root read only, as the CVE says. NAK for this fix. Come up with something that doesn't break perf and trace-cmd. That will not be trivial, as the format is stored in the ring buffer with an address, then referenced directly. It also handles trace_printk() functions that simply point to the string format itself. A fix would require having a pointer be the same that is referenced inside the kernel as well as in this file. Maybe make the format string placed in a location that doesn't leak where the rest of the kernel exists? -- Steve > Signed-off-by: Mark Salyzyn > Cc: Nick Desaulniers > Cc: Steven Rostedt > Cc: Ingo Molnar > Cc: > Cc: # 3.18, 4.4, 4.9, 4.14 > Cc: > > --- > kernel/trace/trace_printk.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c > index ad1d6164e946..93698023baf1 100644 > --- a/kernel/trace/trace_printk.c > +++ b/kernel/trace/trace_printk.c > @@ -304,7 +304,7 @@ static int t_show(struct seq_file *m, void *v) > if (!*fmt) > return 0; > > - seq_printf(m, "0x%lx : \"", *(unsigned long *)fmt); > + seq_printf(m, "0x%pK : \"", *(unsigned long *)fmt); > > /* >* Tabs and new lines need to be converted.
[PATCH 09/10] staging:rtl8192u: Remove typedef of struct cmpk_intr_sta_t - Style
Remove the typedef of struct cmpk_intr_sta_t. This clears the checkpatch
issue with creating new types in code. The change is purely a coding
style change and should have no impact on runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/r819xU_cmdpkt.c | 6 +++---
drivers/staging/rtl8192u/r819xU_cmdpkt.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
index 44709068128c..1f33353bc135 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
@@ -225,7 +225,7 @@ static void cmdpkt_beacontimerinterrupt_819xusb(struct
net_device *dev)
*/
static void cmpk_handle_interrupt_status(struct net_device *dev, u8 *pmsg)
{
- cmpk_intr_sta_t rx_intr_status; /* */
+ struct cmpk_intr_sta_t rx_intr_status; /* */
struct r8192_priv *priv = ieee80211_priv(dev);
DMESG("---> cmpk_Handle_Interrupt_Status()\n");
@@ -236,7 +236,7 @@ static void cmpk_handle_interrupt_status(struct net_device
*dev, u8 *pmsg)
* endian type before copy the message copy.
*/
rx_intr_status.length = pmsg[1];
- if (rx_intr_status.length != (sizeof(cmpk_intr_sta_t) - 2)) {
+ if (rx_intr_status.length != (sizeof(struct cmpk_intr_sta_t) - 2)) {
DMESG("cmpk_Handle_Interrupt_Status: wrong length!\n");
return;
}
@@ -528,7 +528,7 @@ u32 cmpk_message_handle_rx(struct net_device *dev,
case RX_INTERRUPT_STATUS:
cmpk_handle_interrupt_status(dev, pcmd_buff);
- cmd_length = sizeof(cmpk_intr_sta_t);
+ cmd_length = sizeof(struct cmpk_intr_sta_t);
break;
case BOTH_QUERY_CONFIG:
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
index 40edf96451e3..7854530f4745 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
@@ -55,12 +55,12 @@ struct cmpk_txfb_t {
/* 2. RX side: Interrupt status packet. It includes Beacon State,
* Beacon Timer Interrupt and other useful information in MAC ISR Reg.
*/
-typedef struct tag_cmd_pkt_interrupt_status {
+struct cmpk_intr_sta_t {
u8 element_id; /* Command packet type. */
u8 length; /* Command packet length. */
u16 reserve;
u32 interrupt_status; /* Interrupt Status. */
-} cmpk_intr_sta_t;
+};
/* 3. TX side: Set configuration packet. */
typedef struct tag_cmd_pkt_set_configuration {
--
2.18.0
[PATCH 04/10] staging:rtl8192u: Removed unused CMPK_RX_DBG_MSG_SIZE - Style
Remove the unused macro definition CMPK_RX_DBG_MSG_SIZE. This is a coding style change which should have no impact on runtime code execution. Signed-off-by: John Whitmore --- drivers/staging/rtl8192u/r819xU_cmdpkt.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h b/drivers/staging/rtl8192u/r819xU_cmdpkt.h index 198bbcf3ba30..eb73b6a6d324 100644 --- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h +++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h @@ -5,7 +5,6 @@ #defineCMPK_RX_TX_FB_SIZE sizeof(struct cmpk_txfb_t) /* 20 */ #defineCMPK_BOTH_QUERY_CONFIG_SIZE sizeof(cmpk_set_cfg_t) /* 16 */ #defineCMPK_RX_TX_STS_SIZE sizeof(cmpk_tx_status_t) -#defineCMPK_RX_DBG_MSG_SIZE sizeof(cmpk_rx_dbginfo_t) #defineCMPK_TX_RAHIS_SIZE sizeof(cmpk_tx_rahis_t) /* 2008/05/08 amy For USB constant. */ -- 2.18.0
[PATCH 00/10] staging:rtl8192u: Coding style - r819xU_cmdpkt.h
This series of patches contain purely simple coding style changes. I considered renaming the struct cmpk_set_cfg_t as it is never actually used. Following its definition however it is used in a #define: #define cmpk_query_cfg_tcmpk_set_cfg_t So whilst the struct cmpk_set_cfg_t is never used, cmpk_query_cfg_t is. I left it because the comments described this. I was also tempted to remove comments at the end of lines pushing the lines over 80 character length. The comments are at the end of sizeof operators which explicitly state the size. I'm not sure much is gained by the comment, but I left them in: #define ... sizeof(struct cmpk_txfb_t)/* 20 */ #define ... sizeof(struct cmpk_set_cfg_t) /* 16 */ *** BLURB HERE *** John Whitmore (10): staging:rtl8192u: Remove typedef of struct cmpk_txfb_t - Style staging:rtl8192u: Remove unused CMPK_TX_SET_CONFIG_SIZE - Style staging:rtl8192u: Rename bit definition ISR_TxBcnOk - Style staging:rtl8192u: Removed unused CMPK_RX_DBG_MSG_SIZE - Style staging:rtl8192u: Rename ISR_TxBcnErr bit definition - Style staging:rtl8192u: Rename ISR_BcnTimerIntr - Style staging:rtl8192u: Remove multiple blank lines - Style staging:rtl8192u: Correct spelling in comments - style staging:rtl8192u: Remove typedef of struct cmpk_intr_sta_t - Style staging:rtl8192u: Remove typedef from struct cmpk_set_cfg_t - Style drivers/staging/rtl8192u/r819xU_cmdpkt.c | 22 - drivers/staging/rtl8192u/r819xU_cmdpkt.h | 31 ++-- 2 files changed, 24 insertions(+), 29 deletions(-) -- 2.18.0
[PATCH 07/10] staging:rtl8192u: Remove multiple blank lines - Style
Remove multiple blank lines, raise a checkpatch issue. This is purely
a coding style change which should not impact runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/r819xU_cmdpkt.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
index e9e0548ce96e..672c8db804e1 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
@@ -12,7 +12,6 @@
#define ISR_TX_BCN_ERR BIT(26) /* Transmit Beacon Error */
#define ISR_BCN_TIMER_INTR BIT(13) /* Beacon Timer Interrupt */
-
/* Define element ID of command packet. */
/*--Define structure*/
@@ -63,7 +62,6 @@ typedef struct tag_cmd_pkt_interrupt_status {
u32 interrupt_status; /* Interrupt Status. */
} cmpk_intr_sta_t;
-
/* 3. TX side: Set configuration packet. */
typedef struct tag_cmd_pkt_set_configuration {
u8 element_id; /* Command packet type. */
@@ -189,5 +187,4 @@ u32 cmpk_message_handle_rx(struct net_device *dev,
rt_status SendTxCommandPacket(struct net_device *dev,
void *pData, u32 DataLen);
-
#endif
--
2.18.0
[PATCH 08/10] staging:rtl8192u: Correct spelling in comments - style
Correct the spelling of a number of comments, which caused a checkpatch
issue. This is purely a coding style change which should have no impact
on runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/r819xU_cmdpkt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
index 672c8db804e1..40edf96451e3 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
@@ -53,7 +53,7 @@ struct cmpk_txfb_t {
};
/* 2. RX side: Interrupt status packet. It includes Beacon State,
- * Beacon Timer Interrupt and other useful informations in MAC ISR Reg.
+ * Beacon Timer Interrupt and other useful information in MAC ISR Reg.
*/
typedef struct tag_cmd_pkt_interrupt_status {
u8 element_id; /* Command packet type. */
@@ -80,7 +80,7 @@ typedef struct tag_cmd_pkt_set_configuration {
u32 mask;
} cmpk_set_cfg_t;
-/* 4. Both side : TX/RX query configuraton packet. The query structure is the
+/* 4. Both side : TX/RX query configuration packet. The query structure is the
*same as set configuration.
*/
#definecmpk_query_cfg_tcmpk_set_cfg_t
--
2.18.0
[PATCH 06/10] staging:rtl8192u: Rename ISR_BcnTimerIntr - Style
Rename the bit definition ISR_BcnTimerIntr to ISR_BCN_TIMER_INTR. This change clears the checkpatch issue with CamelCase naming. The change is purely a style change and should not impact runtime code execution. Signed-off-by: John Whitmore --- drivers/staging/rtl8192u/r819xU_cmdpkt.c | 2 +- drivers/staging/rtl8192u/r819xU_cmdpkt.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.c b/drivers/staging/rtl8192u/r819xU_cmdpkt.c index ef777fd4b99d..44709068128c 100644 --- a/drivers/staging/rtl8192u/r819xU_cmdpkt.c +++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.c @@ -257,7 +257,7 @@ static void cmpk_handle_interrupt_status(struct net_device *dev, u8 *pmsg) priv->stats.txbeaconerr++; } - if (rx_intr_status.interrupt_status & ISR_BcnTimerIntr) + if (rx_intr_status.interrupt_status & ISR_BCN_TIMER_INTR) cmdpkt_beacontimerinterrupt_819xusb(dev); } diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h b/drivers/staging/rtl8192u/r819xU_cmdpkt.h index 4a0a1c24eb34..e9e0548ce96e 100644 --- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h +++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h @@ -10,7 +10,7 @@ /* 2008/05/08 amy For USB constant. */ #define ISR_TX_BCN_OK BIT(27) /* Transmit Beacon OK */ #define ISR_TX_BCN_ERR BIT(26) /* Transmit Beacon Error */ -#define ISR_BcnTimerIntr BIT(13) /* Beacon Timer Interrupt */ +#define ISR_BCN_TIMER_INTR BIT(13) /* Beacon Timer Interrupt */ /* Define element ID of command packet. */ -- 2.18.0
[PATCH 10/10] staging:rtl8192u: Remove typedef from struct cmpk_set_cfg_t - Style
Remove the typedef from struct cmpk_set_cfg_t. This change clears the
checkpatch issue with defining new types. The change is purely a coding
style change which should have no impact on runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/r819xU_cmdpkt.c | 2 +-
drivers/staging/rtl8192u/r819xU_cmdpkt.h | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
index 1f33353bc135..490ee399169b 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
@@ -288,7 +288,7 @@ static void cmpk_handle_interrupt_status(struct net_device
*dev, u8 *pmsg)
*/
static void cmpk_handle_query_config_rx(struct net_device *dev, u8 *pmsg)
{
- cmpk_query_cfg_trx_query_cfg;
+ struct cmpk_query_cfg_t rx_query_cfg;
/* 1. Extract TX feedback info from RFD to temp structure buffer. */
/* It seems that FW use big endian(MIPS) and DRV use little endian in
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
index 7854530f4745..17d28244cb36 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
@@ -3,7 +3,7 @@
#define R819XUSB_CMDPKT_H
/* Different command packet have dedicated message length and definition. */
#defineCMPK_RX_TX_FB_SIZE sizeof(struct
cmpk_txfb_t) /* 20 */
-#defineCMPK_BOTH_QUERY_CONFIG_SIZE sizeof(cmpk_set_cfg_t)
/* 16 */
+#defineCMPK_BOTH_QUERY_CONFIG_SIZE sizeof(struct
cmpk_set_cfg_t) /* 16 */
#defineCMPK_RX_TX_STS_SIZE sizeof(cmpk_tx_status_t)
#defineCMPK_TX_RAHIS_SIZE sizeof(cmpk_tx_rahis_t)
@@ -63,7 +63,7 @@ struct cmpk_intr_sta_t {
};
/* 3. TX side: Set configuration packet. */
-typedef struct tag_cmd_pkt_set_configuration {
+struct cmpk_set_cfg_t {
u8 element_id; /* Command packet type. */
u8 length; /* Command packet length. */
u16 reserve1;
@@ -78,7 +78,7 @@ typedef struct tag_cmd_pkt_set_configuration {
u8 cfg_offset;
u32 value;
u32 mask;
-} cmpk_set_cfg_t;
+};
/* 4. Both side : TX/RX query configuration packet. The query structure is the
*same as set configuration.
--
2.18.0
[PATCH 02/10] staging:rtl8192u: Remove unused CMPK_TX_SET_CONFIG_SIZE - Style
Remove the unused macro CMPK_TX_SET_CONFIG_SIZE. This is a coding style change which should not impact runtime code execution. Signed-off-by: John Whitmore --- drivers/staging/rtl8192u/r819xU_cmdpkt.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h b/drivers/staging/rtl8192u/r819xU_cmdpkt.h index 3f366e8317e6..095664a086e1 100644 --- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h +++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h @@ -3,7 +3,6 @@ #define R819XUSB_CMDPKT_H /* Different command packet have dedicated message length and definition. */ #defineCMPK_RX_TX_FB_SIZE sizeof(struct cmpk_txfb_t) /* 20 */ -#defineCMPK_TX_SET_CONFIG_SIZE sizeof(cmpk_set_cfg_t) /* 16 */ #defineCMPK_BOTH_QUERY_CONFIG_SIZE sizeof(cmpk_set_cfg_t) /* 16 */ #defineCMPK_RX_TX_STS_SIZE sizeof(cmpk_tx_status_t) #defineCMPK_RX_DBG_MSG_SIZE sizeof(cmpk_rx_dbginfo_t) -- 2.18.0
[PATCH 01/10] staging:rtl8192u: Remove typedef of struct cmpk_txfb_t - Style
Remove the typedef of the structure cmpk_txfb_t. This clears the
checkpatch issue with defining new types. This change is purely
a coding style change which should not impact runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/r819xU_cmdpkt.c | 8
drivers/staging/rtl8192u/r819xU_cmdpkt.h | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
index 80672100ea26..0e3fccd4a55c 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
@@ -66,7 +66,7 @@ rt_status SendTxCommandPacket(struct net_device *dev, void
*pData, u32 DataLen)
* Overview:
*
* Input: PADAPTER pAdapter
- * CMPK_TXFB_T*psTx_FB
+ * STRUCT CMPK_TXFB_T *psTx_FB
*
* Output: NONE
*
@@ -78,7 +78,7 @@ rt_status SendTxCommandPacket(struct net_device *dev, void
*pData, u32 DataLen)
*
*---
*/
-static void cmpk_count_txstatistic(struct net_device *dev, cmpk_txfb_t
*pstx_fb)
+static void cmpk_count_txstatistic(struct net_device *dev, struct cmpk_txfb_t
*pstx_fb)
{
struct r8192_priv *priv = ieee80211_priv(dev);
#ifdef ENABLE_PS
@@ -163,7 +163,7 @@ static void cmpk_count_txstatistic(struct net_device *dev,
cmpk_txfb_t *pstx_fb)
static void cmpk_handle_tx_feedback(struct net_device *dev, u8 *pmsg)
{
struct r8192_priv *priv = ieee80211_priv(dev);
- cmpk_txfb_t rx_tx_fb;
+ struct cmpk_txfb_t rx_tx_fb;
priv->stats.txfeedback++;
@@ -173,7 +173,7 @@ static void cmpk_handle_tx_feedback(struct net_device *dev,
u8 *pmsg)
* endian type before copy the message copy.
*/
/* Use pointer to transfer structure memory. */
- memcpy((u8 *)_tx_fb, pmsg, sizeof(cmpk_txfb_t));
+ memcpy((u8 *)_tx_fb, pmsg, sizeof(struct cmpk_txfb_t));
/* 2. Use tx feedback info to count TX statistics. */
cmpk_count_txstatistic(dev, _tx_fb);
/* Comment previous method for TX statistic function. */
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
index 85fb49ca7bc8..3f366e8317e6 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
@@ -2,7 +2,7 @@
#ifndef R819XUSB_CMDPKT_H
#define R819XUSB_CMDPKT_H
/* Different command packet have dedicated message length and definition. */
-#defineCMPK_RX_TX_FB_SIZE sizeof(cmpk_txfb_t)
/* 20 */
+#defineCMPK_RX_TX_FB_SIZE sizeof(struct
cmpk_txfb_t) /* 20 */
#defineCMPK_TX_SET_CONFIG_SIZE sizeof(cmpk_set_cfg_t)
/* 16 */
#defineCMPK_BOTH_QUERY_CONFIG_SIZE sizeof(cmpk_set_cfg_t)
/* 16 */
#defineCMPK_RX_TX_STS_SIZE sizeof(cmpk_tx_status_t)
@@ -20,7 +20,7 @@
/*--Define structure*/
/* Define different command packet structure. */
/* 1. RX side: TX feedback packet. */
-typedef struct tag_cmd_pkt_tx_feedback {
+struct cmpk_txfb_t {
/* DWORD 0 */
u8 element_id; /* Command packet type. */
u8 length; /* Command packet length. */
@@ -53,7 +53,7 @@ typedef struct tag_cmd_pkt_tx_feedback {
/* DWORD 5 */
u16 reserve3;
u16 duration;
-} cmpk_txfb_t;
+};
/* 2. RX side: Interrupt status packet. It includes Beacon State,
* Beacon Timer Interrupt and other useful informations in MAC ISR Reg.
--
2.18.0
[PATCH 03/10] staging:rtl8192u: Rename bit definition ISR_TxBcnOk - Style
Rename the bit definition ISR_TxBcnOk to ISR_TX_BCN_OK. This change
clears the checkpatch issue with CamelCase naming. The change is a
coding style change which should not impact runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/r819xU_cmdpkt.c | 2 +-
drivers/staging/rtl8192u/r819xU_cmdpkt.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
index 0e3fccd4a55c..96f705c85bb3 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
@@ -249,7 +249,7 @@ static void cmpk_handle_interrupt_status(struct net_device
*dev, u8 *pmsg)
DMESG("interrupt status = 0x%x\n",
rx_intr_status.interrupt_status);
- if (rx_intr_status.interrupt_status & ISR_TxBcnOk) {
+ if (rx_intr_status.interrupt_status & ISR_TX_BCN_OK) {
priv->ieee80211->bibsscoordinator = true;
priv->stats.txbeaconokint++;
} else if (rx_intr_status.interrupt_status & ISR_TxBcnErr) {
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
index 095664a086e1..198bbcf3ba30 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
@@ -9,7 +9,7 @@
#defineCMPK_TX_RAHIS_SIZE sizeof(cmpk_tx_rahis_t)
/* 2008/05/08 amy For USB constant. */
-#define ISR_TxBcnOkBIT(27) /* Transmit Beacon OK */
+#define ISR_TX_BCN_OK BIT(27) /* Transmit Beacon OK */
#define ISR_TxBcnErr BIT(26) /* Transmit Beacon Error */
#define ISR_BcnTimerIntr BIT(13) /* Beacon Timer Interrupt */
--
2.18.0
[PATCH 05/10] staging:rtl8192u: Rename ISR_TxBcnErr bit definition - Style
Rename the bit definition ISR_TxBcnErr to ISR_TX_BCN_ERR. This change
clears the checkpatch issue with CamelCase naming. The change is purely
a coding style change which should not impact runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/r819xU_cmdpkt.c | 2 +-
drivers/staging/rtl8192u/r819xU_cmdpkt.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
index 96f705c85bb3..ef777fd4b99d 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
@@ -252,7 +252,7 @@ static void cmpk_handle_interrupt_status(struct net_device
*dev, u8 *pmsg)
if (rx_intr_status.interrupt_status & ISR_TX_BCN_OK) {
priv->ieee80211->bibsscoordinator = true;
priv->stats.txbeaconokint++;
- } else if (rx_intr_status.interrupt_status & ISR_TxBcnErr) {
+ } else if (rx_intr_status.interrupt_status & ISR_TX_BCN_ERR) {
priv->ieee80211->bibsscoordinator = false;
priv->stats.txbeaconerr++;
}
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
index eb73b6a6d324..4a0a1c24eb34 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
@@ -9,7 +9,7 @@
/* 2008/05/08 amy For USB constant. */
#define ISR_TX_BCN_OK BIT(27) /* Transmit Beacon OK */
-#define ISR_TxBcnErr BIT(26) /* Transmit Beacon Error */
+#define ISR_TX_BCN_ERR BIT(26) /* Transmit Beacon Error */
#define ISR_BcnTimerIntr BIT(13) /* Beacon Timer Interrupt */
--
2.18.0
Re: [PATCH 1/1] rpmsg: virtio_rpmsg_bus: Fix rpmsg_remove() release order
Hi Loic,
On 07/25/2018 04:07 PM, Loic Pallardy wrote:
> In rpmsg_remove() procedure, children are removed then Name
> Service announcement endpoint is destroyed and device released.
>
> Issue with current implementation is if a NS announcement
> creation request is ongoing (received before virtio reset),
> child device could be created after children removing.
> In that case rpmsg_remove() is freeing rpmsg_virtio_bus,
> leading to an inconsistent state.
>
> This patch is destroying NS announcement service endpoint before
> removing children to guarantee that list of child devices is
> fixed and all of them will be correctly removed before cleaning
> resources.
I do not think this is the right fix for the problem you explained.
The removal of rpmsg devices can actually invoke the announce_destroy
in the rpmsg_dev_remove().
regards
Suman
>
> fixes: bcabbccabffe ("rpmsg: Split off generic tail of create_channel()")
>
> Signed-off-by: Loic Pallardy
> ---
> drivers/rpmsg/virtio_rpmsg_bus.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 664f957..f5d481f 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -1004,13 +1004,13 @@ static void rpmsg_remove(struct virtio_device *vdev)
>
> vdev->config->reset(vdev);
>
> + if (vrp->ns_ept)
> + __rpmsg_destroy_ept(vrp, vrp->ns_ept);
> +
> ret = device_for_each_child(>dev, NULL, rpmsg_remove_device);
> if (ret)
> dev_warn(>dev, "can't remove rpmsg device: %d\n", ret);
>
> - if (vrp->ns_ept)
> - __rpmsg_destroy_ept(vrp, vrp->ns_ept);
> -
> idr_destroy(>endpoints);
>
> vdev->config->del_vqs(vrp->vdev);
>
Re: [PATCH] tracing: Fix double free of event_trigger_data
On Wed, 25 Jul 2018 15:53:21 -0400
Steven Rostedt wrote:
> On Wed, 25 Jul 2018 15:29:04 -0400
> Steven Rostedt wrote:
>
> > Nope, this doesn't work. It's a little more complex than the other one.
> > I'll just leave it, and fix the reg code for 4.19.
>
> I take this back. Looks like it just needs to be handled slightly
> differently. Thoughts?
Ah, I see, the filter should be cleared :)
OK, this should work.
Reivewed-by: Masami Hiramatsu
Thanks,
>
> -- Steve
>
> diff --git a/kernel/trace/trace_events_trigger.c
> b/kernel/trace/trace_events_trigger.c
> index d18ec0e58be2..5dea177cef53 100644
> --- a/kernel/trace/trace_events_trigger.c
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -1420,6 +1420,9 @@ int event_enable_trigger_func(struct event_command
> *cmd_ops,
> goto out;
> }
>
> + /* Up the trigger_data count to make sure nothing frees it on failure */
> + event_trigger_init(trigger_ops, trigger_data);
> +
> if (trigger) {
> number = strsep(, ":");
>
> @@ -1470,6 +1473,7 @@ int event_enable_trigger_func(struct event_command
> *cmd_ops,
> goto out_disable;
> /* Just return zero, not the number of enabled functions */
> ret = 0;
> + event_trigger_free(trigger_ops, trigger_data);
> out:
> return ret;
>
> @@ -1480,7 +1484,7 @@ int event_enable_trigger_func(struct event_command
> *cmd_ops,
> out_free:
> if (cmd_ops->set_filter)
> cmd_ops->set_filter(NULL, trigger_data, NULL);
> - kfree(trigger_data);
> + event_trigger_free(trigger_ops, trigger_data);
> kfree(enable_data);
> goto out;
> }
--
Masami Hiramatsu
Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB
On Wed, 25 Jul 2018, Linus Torvalds wrote: > > Mitigate userspace-userspace attacks by always unconditionally filling RSB > > on > > context switch when generic spectrev2 mitigation has been enabled. > > Shouldn't this also do something like > > x86_spec_ctrl_base |= x86_spec_ctrl_mask & SPEC_CTRL_STIBP; > > if we have HT enabled? So IIUC your comment is not really tightly related to spectreRSB, is it? If you're making a more general remark about things that we'd also have to do in order to improve userspace-userspace spectrev2 prevention, then I agree. It probably wouldn't be as simple as adding it to x86_spec_ctrl_base I think though, as the VM switching also has to save/restore it properly (the same way we handle SSBD). So I'd rather handle this separately, as it really is in principle a completely different protection. STIBP is plugging much smaller hole than spectreRSB (as the bigger part is already plugged by IBPB), so I'd rather have that one in first, and look at improving STIBP later if noone beats me to it. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH v5 1/3] thermal: qcom-spmi: Use PMIC thermal stage 2 for critical trip points
Hi,
On Tue, Jul 24, 2018 at 4:46 PM, Matthias Kaehlcke wrote:
> +static int qpnp_tm_update_critical_trip_temp(struct qpnp_tm_chip *chip,
> +int temp)
> +{
> + u8 reg;
> + bool disable_s2_shutdown = false;
> + int ret;
> +
> + WARN_ON(!mutex_is_locked(>lock));
> +
> + /*
> +* Default: S2 and S3 shutdown enabled, thresholds at
> +* 105C/125C/145C, monitoring at 25Hz
> +*/
> + reg = SHUTDOWN_CTRL1_RATE_25HZ;
> +
> + if ((temp == THERMAL_TEMP_INVALID) ||
> + (temp < STAGE2_THRESHOLD_MIN)) {
> + chip->thresh = THRESH_MIN;
> + goto skip;
> + }
> +
> + if (temp <= STAGE2_THRESHOLD_MAX) {
> + chip->thresh = THRESH_MAX -
> + ((STAGE2_THRESHOLD_MAX - temp) /
> +TEMP_THRESH_STEP);
> + disable_s2_shutdown = true;
> + } else {
> + chip->thresh = THRESH_MAX;
> +
> + if (!IS_ERR(chip->adc))
> + disable_s2_shutdown = true;
> + else
> + dev_warn(chip->dev,
> +"No ADC is configured and critical
> temperature is above the maximum stage 2 threshold of 140°C! Configuring
> stage 2 shutdown at 140°C.\n");
Putting a non-ASCII character (the degree symbol) in your commit
message is one thing, but are you sure it's wise to put it in the
kernel logs?
> + }
> +
> +skip:
> + reg |= chip->thresh;
> + if (disable_s2_shutdown)
> + reg |= SHUTDOWN_CTRL1_OVERRIDE_S2;
> +
> + ret = qpnp_tm_write(chip, QPNP_TM_REG_SHUTDOWN_CTRL1, reg);
> + if (ret < 0)
> + return ret;
> +
> + return ret;
Simplify the above lines to:
return qpnp_tm_write(chip, QPNP_TM_REG_SHUTDOWN_CTRL1, reg);
> @@ -313,12 +441,7 @@ static int qpnp_tm_probe(struct platform_device *pdev)
> if (ret < 0)
> return ret;
>
> - chip->tz_dev = devm_thermal_zone_of_sensor_register(>dev, 0,
> chip,
> - _tm_sensor_ops);
> - if (IS_ERR(chip->tz_dev)) {
> - dev_err(>dev, "failed to register sensor\n");
> - return PTR_ERR(chip->tz_dev);
> - }
> + chip->initialized = true;
Should we add "thermal_zone_device_update(chip->tz_dev,
THERMAL_EVENT_UNSPECIFIED);" here
...also: do we care about any type of locking for chip->initialized?
Technically we can be running on weakly ordered memory so if
qpnp_tm_update_temp_no_adc() is running on a different processor then
possibly it could still keep returning the default temperature for a
little while. We could try to analyze whether there's some sort of
implicit barrier or we could add manual memory barriers, but generally
I try to avoid that and just do the simple locking... What about just
setting chip-Initialized = true at the end of qpnp_tm_init() while the
mutex is still held?
I'd also love to hear from someone with more thermal framework
experience to make sure it's legit to return a default value if
someone calls us while we're initting. It seems sane to me but nice
to confirm it's OK.
Overall I like the idea of this patch so hopefully others do too.
Thanks for sending it out!
-Doug
Re: [PATCH 1/3] clk: s2mps11: Fix matching when built as module and DT node contains compatible
Quoting Krzysztof Kozlowski (2018-07-25 08:55:15)
> When driver is built as module and DT node contains clocks compatible
> (e.g. "samsung,s2mps11-clk"), the module will not be autoloaded because
> module aliases won't match.
>
> The modalias from uevent: of:NclocksTCsamsung,s2mps11-clk
> The modalias from driver: platform:s2mps11-clk
>
> The devices are instantiated by parent's MFD. However both Device Tree
> bindings and parent define the compatible for clocks devices. In case
> of module matching this DT compatible will be used.
>
> The issue will not happen if this is built-in (no need for module
> matching) or when clocks DT node does not contain compatible (not
> correct from bindings perspective but working for driver).
>
> Note when backporting to stable kernels: adjust the list of device ID
> entries.
>
> Cc:
> Fixes: 53c31b3437a6 ("mfd: sec-core: Add of_compatible strings for clock MFD
> cells")
> Signed-off-by: Krzysztof Kozlowski
> ---
Acked-by: Stephen Boyd
[PATCH v4 1/9] proc/kcore: don't grab lock for kclist_add()
From: Omar Sandoval
kclist_add() is only called at init time, so there's no point in
grabbing any locks. We're also going to replace the rwlock with a rwsem,
which we don't want to try grabbing during early boot.
While we're here, mark kclist_add() with __init so that we'll get a
warning if it's called from non-init code.
Reviewed-by: Andrew Morton
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 7 +++
include/linux/kcore.h | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 66c373230e60..b0b9a76f28d6 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -62,16 +62,15 @@ static LIST_HEAD(kclist_head);
static DEFINE_RWLOCK(kclist_lock);
static int kcore_need_update = 1;
-void
-kclist_add(struct kcore_list *new, void *addr, size_t size, int type)
+/* This doesn't grab kclist_lock, so it should only be used at init time. */
+void __init kclist_add(struct kcore_list *new, void *addr, size_t size,
+ int type)
{
new->addr = (unsigned long)addr;
new->size = size;
new->type = type;
- write_lock(_lock);
list_add_tail(>list, _head);
- write_unlock(_lock);
}
static size_t get_kcore_size(int *nphdr, size_t *elf_buflen)
diff --git a/include/linux/kcore.h b/include/linux/kcore.h
index 8de55e4b5ee9..c20f296438fb 100644
--- a/include/linux/kcore.h
+++ b/include/linux/kcore.h
@@ -35,7 +35,7 @@ struct vmcoredd_node {
};
#ifdef CONFIG_PROC_KCORE
-extern void kclist_add(struct kcore_list *, void *, size_t, int type);
+void __init kclist_add(struct kcore_list *, void *, size_t, int type);
#else
static inline
void kclist_add(struct kcore_list *new, void *addr, size_t size, int type)
--
2.18.0
Re: Reminder to review a few patches sent two weeks ago
On 2018-07-24 17:33, Joe Perches wrote:
On Tue, 2018-07-24 at 14:56 -0700, pher...@codeaurora.org wrote:
A reminder to review a few patches I had sent last week. Below are the
links for the patches.
https://lkml.org/lkml/2018/7/5/798
I have no fundamental object to this one, but
the 80 column use is unnecessary and should be
coalesced before it can be applied.
Perhaps:
# warn about #if 1
if ($line =~ /^.\s*\#\s*if\s+1\b/) {
WARN("IF_1",
"Consider removing the #if 1 and its #endif\n" .
$herecurr);
}
http://lists-archives.com/linux-kernel/29168320-checkpatch-check-for-invalid-return-codes.html
This one has I think too many existing uses of
things like "return -1;"
$ git grep -P "return\s*\-\d+\s*;" | wc -l
9929
How many of these are actually appropriate?
I did go through a few of the files which return -1 in their functions,
I observed that most of them were inappropriate and there was a case
where actually the use of return -1 was
incorrect(kernel/arch/ia64/mm/contig.c
in the function find_bootmap_location()). We could actually catch such
errors
from now on if we use this patch.
Also, no space is required between return and -1
by c90 and this should use $Int so it should be:
if ($line =~ /\breturn\s*\-\$Int\s*;/) {
etc...
Re: [PATCH 1/2] tracing: kprobes: Prohibit probing on notrace functions
On Fri, 13 Jul 2018 08:18:03 -0400 Steven Rostedt wrote: > On Fri, 13 Jul 2018 11:53:01 +0900 > Masami Hiramatsu wrote: > > > On Thu, 12 Jul 2018 13:54:12 -0400 > > Francis Deslauriers wrote: > > > > > From: Masami Hiramatsu > > > > > > Prohibit kprobe-events probing on notrace function. > > > Since probing on the notrace function can cause recursive > > > event call. In most case those are just skipped, but > > > in some case it falls into infinite recursive call. > > > > BTW, I'm considering to add an option to allow putting > > kprobes on notrace function - just for debugging > > ftrace by kprobes. That is "developer only" option > > so generally it should be disabled, but for debugging > > the ftrace, we still need it. Or should I introduce > > another kprobes module for debugging it? > > No, I think the former is better (to add an option to allow putting > kprobes on notrace functions). By default we let people protect > themselves. But if then provide a switch that lets you do things that > might let you shoot yourself in the foot. I'm adding CONFIG_KPROBE_EVENTS_ON_NOTRACE kconfig which allows kprobes on notrace function. I think we don't need to make it online switchable, since it is only good for ftrace developers. Thank you, > > BTW, I'm now leaving on vacation. I'll be back on the 23rd and will be > looking for patches that I should be pulling in then. > > Thanks! > > -- Steve -- Masami Hiramatsu
linux-next: build warning after merge of the rdma tree
Hi all,
After merging the rdma tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
net/sunrpc/xprtrdma/svc_rdma_rw.c: In function 'svc_rdma_post_chunk_ctxt':
net/sunrpc/xprtrdma/svc_rdma_rw.c:350:5: warning: 'bad_wr' may be used
uninitialized in this function [-Wmaybe-uninitialized]
if (bad_wr != first_wr)
^
Introduced by commit
ed288d74a9e5 ("net/xprtrdma: Simplify ib_post_(send|recv|srq_recv)() calls")
This is an actual problem.
--
Cheers,
Stephen Rothwell
pgpBpaF3FlVqx.pgp
Description: OpenPGP digital signature
Re: Showing /sys/fs/cgroup/memory/memory.stat very slow on some machines
On 7/19/18 3:40 AM, Bruce Merry wrote: > On 18 July 2018 at 17:49, Shakeel Butt wrote: >> On Wed, Jul 18, 2018 at 8:37 AM Bruce Merry wrote: >>> That sounds promising. Is there any way to tell how many zombies there >>> are, and is there any way to deliberately create zombies? If I can >>> produce zombies that might give me a reliable way to reproduce the >>> problem, which could then sensibly be tested against newer kernel >>> versions. >>> >> >> Yes, very easy to produce zombies, though I don't think kernel >> provides any way to tell how many zombies exist on the system. >> >> To create a zombie, first create a memcg node, enter that memcg, >> create a tmpfs file of few KiBs, exit the memcg and rmdir the memcg. >> That memcg will be a zombie until you delete that tmpfs file. > > Thanks, that makes sense. I'll see if I can reproduce the issue. Do > you expect the same thing to happen with normal (non-tmpfs) files that > are sitting in the page cache, and/or dentries? > Do you by any chance have use_hierarch=1? memcg_stat_show should just rely on counters inside the memory cgroup and the the LRU sizes for each node. Balbir Singh.
Re: [PATCH 1/2] tracing: kprobes: Prohibit probing on notrace functions
On Thu, 26 Jul 2018 09:41:06 +0900 Masami Hiramatsu wrote: > On Fri, 13 Jul 2018 08:18:03 -0400 > Steven Rostedt wrote: > > > On Fri, 13 Jul 2018 11:53:01 +0900 > > Masami Hiramatsu wrote: > > > > > On Thu, 12 Jul 2018 13:54:12 -0400 > > > Francis Deslauriers wrote: > > > > > > > From: Masami Hiramatsu > > > > > > > > Prohibit kprobe-events probing on notrace function. > > > > Since probing on the notrace function can cause recursive > > > > event call. In most case those are just skipped, but > > > > in some case it falls into infinite recursive call. > > > > > > BTW, I'm considering to add an option to allow putting > > > kprobes on notrace function - just for debugging > > > ftrace by kprobes. That is "developer only" option > > > so generally it should be disabled, but for debugging > > > the ftrace, we still need it. Or should I introduce > > > another kprobes module for debugging it? > > > > No, I think the former is better (to add an option to allow putting > > kprobes on notrace functions). By default we let people protect > > themselves. But if then provide a switch that lets you do things that > > might let you shoot yourself in the foot. > > I'm adding CONFIG_KPROBE_EVENTS_ON_NOTRACE kconfig which allows > kprobes on notrace function. I think we don't need to make it > online switchable, since it is only good for ftrace developers. > Works for me. Thanks! -- Steve
Re: [PATCH v5 1/3] thermal: qcom-spmi: Use PMIC thermal stage 2 for critical trip points
Hi Doug,
On Wed, Jul 25, 2018 at 04:19:56PM -0700, Doug Anderson wrote:
> On Tue, Jul 24, 2018 at 4:46 PM, Matthias Kaehlcke wrote:
> > +static int qpnp_tm_update_critical_trip_temp(struct qpnp_tm_chip *chip,
> > +int temp)
> > +{
> > + u8 reg;
> > + bool disable_s2_shutdown = false;
> > + int ret;
> > +
> > + WARN_ON(!mutex_is_locked(>lock));
> > +
> > + /*
> > +* Default: S2 and S3 shutdown enabled, thresholds at
> > +* 105C/125C/145C, monitoring at 25Hz
> > +*/
> > + reg = SHUTDOWN_CTRL1_RATE_25HZ;
> > +
> > + if ((temp == THERMAL_TEMP_INVALID) ||
> > + (temp < STAGE2_THRESHOLD_MIN)) {
> > + chip->thresh = THRESH_MIN;
> > + goto skip;
> > + }
> > +
> > + if (temp <= STAGE2_THRESHOLD_MAX) {
> > + chip->thresh = THRESH_MAX -
> > + ((STAGE2_THRESHOLD_MAX - temp) /
> > +TEMP_THRESH_STEP);
> > + disable_s2_shutdown = true;
> > + } else {
> > + chip->thresh = THRESH_MAX;
> > +
> > + if (!IS_ERR(chip->adc))
> > + disable_s2_shutdown = true;
> > + else
> > + dev_warn(chip->dev,
> > +"No ADC is configured and critical
> > temperature is above the maximum stage 2 threshold of 140°C! Configuring
> > stage 2 shutdown at 140°C.\n");
>
> Putting a non-ASCII character (the degree symbol) in your commit
> message is one thing, but are you sure it's wise to put it in the
> kernel logs?
A few other drivers also do this
(drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c,
drivers/macintosh/windfarm_pm121.c), however that doesn't mean it's a
good idea. Will change to degC or C.
> > + }
> > +
> > +skip:
> > + reg |= chip->thresh;
> > + if (disable_s2_shutdown)
> > + reg |= SHUTDOWN_CTRL1_OVERRIDE_S2;
> > +
> > + ret = qpnp_tm_write(chip, QPNP_TM_REG_SHUTDOWN_CTRL1, reg);
> > + if (ret < 0)
> > + return ret;
> > +
> > + return ret;
>
> Simplify the above lines to:
>
> return qpnp_tm_write(chip, QPNP_TM_REG_SHUTDOWN_CTRL1, reg);
Ouch, my code is indeed dumb ...
> > @@ -313,12 +441,7 @@ static int qpnp_tm_probe(struct platform_device *pdev)
> > if (ret < 0)
> > return ret;
> >
> > - chip->tz_dev = devm_thermal_zone_of_sensor_register(>dev, 0,
> > chip,
> > -
> > _tm_sensor_ops);
> > - if (IS_ERR(chip->tz_dev)) {
> > - dev_err(>dev, "failed to register sensor\n");
> > - return PTR_ERR(chip->tz_dev);
> > - }
> > + chip->initialized = true;
>
> Should we add "thermal_zone_device_update(chip->tz_dev,
> THERMAL_EVENT_UNSPECIFIED);" here
Seems reasonable, will do.
> ...also: do we care about any type of locking for chip->initialized?
> Technically we can be running on weakly ordered memory so if
> qpnp_tm_update_temp_no_adc() is running on a different processor then
> possibly it could still keep returning the default temperature for a
> little while. We could try to analyze whether there's some sort of
> implicit barrier or we could add manual memory barriers, but generally
> I try to avoid that and just do the simple locking... What about just
> setting chip-Initialized = true at the end of qpnp_tm_init() while the
> mutex is still held?
Thanks for pointing that out. I agree that we should keep things
simple, chip->initialized to true at the end of qpnp_tm_init() sounds
good to me.
> I'd also love to hear from someone with more thermal framework
> experience to make sure it's legit to return a default value if
> someone calls us while we're initting. It seems sane to me but nice
> to confirm it's OK.
An alternative could be to return THERMAL_TEMP_INVALID, however I
don't see this handled outside of thermal_core.c, not sure if it could
throw some other code off.
Comments from thermal folks on either approach (or alternatives) are
definitely welcome :)
> Overall I like the idea of this patch so hopefully others do too.
> Thanks for sending it out!
Thanks for the review!
Matthias
Re: [PATCH v1] checkpatch: check for #if 0/#if 1
On Wed, 2018-07-25 at 16:14 -0700, Prakruthi Deepak Heragu wrote:
> The #if 0 or #if 1 is used to toggle features. Warn if #if 0 or #if 1
> is present and suggest that they can be removed.
>
> Signed-off-by: Abhijeet Dharmapurikar
> Signed-off-by: Prakruthi Deepak Heragu
> ---
> Changes in v1:
> - Rephrase the warning message to fit in a single line without
> 80 column limit
>
> scripts/checkpatch.pl | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 3394ed8..72513c2 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5383,9 +5383,14 @@ sub process {
>
> # warn about #if 0
> if ($line =~ /^.\s*\#\s*if\s+0\b/) {
> - CHK("REDUNDANT_CODE",
> - "if this code is redundant consider removing it\n" .
> - $herecurr);
> + WARN("IF_0",
> + "Consider removing the #if 0 and its #endif\n".
> $herecurr);
No, this wording is not correct at all.
The entire block, i.e.: 'this code' should be considered
to be removed, not just the #if 0 and its #endif.
For #if 1 code, then just the #if 1 and the #endif should
be removed.
> + }
> +
> +# warn about #if 1
> + if ($line =~ /^.\s*\#\s*if\s+1\b/) {
> + WARN("IF_1",
> + "Consider removing the #if 1 and its #endif\n".
> $herecurr);
> }
>
> # check for needless "if () fn()" uses
Re: [PATCHv3 0/2] Stackleak for arm64
On 07/25/2018 04:49 AM, Will Deacon wrote:
Hi Laura,
On Tue, Jul 24, 2018 at 05:38:07PM +0100, Will Deacon wrote:
On Fri, Jul 20, 2018 at 02:41:52PM -0700, Laura Abbott wrote:
This is the version of stackleak for arm64, hopefully ready for queueing
Thanks. I'll push these into linux-next tomorrow, once I've had a chance
to test my conflict resolution in entry.S.
I've run into a couple of issues with this series:
1. I had to install libmpc-dev to get GCC_PLUGINS to appear, otherwise the
hostcc check would silently fail. I guess that's a general observation,
but it might be nice to print a message about the missing dependencies.
2. It breaks arm64 allmodconfig build. Log below.
Please can you take a look at the build failure? Otherwise, the patches
look good to me.
Cheers,
Will
--->8
arch/arm64/kernel/sdei.c: In function ‘on_sdei_normal_stack’:
arch/arm64/kernel/sdei.c:101:7: error: dereferencing pointer to incomplete type
‘struct stack_info’
info->low = low;
^~
arch/arm64/kernel/sdei.c:103:16: error: ‘STACK_TYPE_SDEI_NORMAL’ undeclared
(first use in this function); did you mean ‘SCHED_NORMAL’?
info->type = STACK_TYPE_SDEI_NORMAL;
^~
SCHED_NORMAL
arch/arm64/kernel/sdei.c:103:16: note: each undeclared identifier is reported
only once for each function it appears in
arch/arm64/kernel/sdei.c: In function ‘on_sdei_critical_stack’:
arch/arm64/kernel/sdei.c:121:16: error: ‘STACK_TYPE_SDEI_CRITICAL’ undeclared
(first use in this function)
info->type = STACK_TYPE_SDEI_CRITICAL;
^~~~
arch/arm64/kernel/sdei.c: At top level:
arch/arm64/kernel/sdei.c:127:6: error: conflicting types for ‘_on_sdei_stack’
bool _on_sdei_stack(unsigned long sp,
^~
In file included from ./include/linux/arm_sdei.h:14:0,
from arch/arm64/kernel/sdei.c:5:
./arch/arm64/include/asm/sdei.h:45:6: note: previous declaration of
‘_on_sdei_stack’ was here
bool _on_sdei_stack(unsigned long sp, struct stack_info *info);
^~
arch/arm64/kernel/sdei.c: In function ‘_on_sdei_stack’:
arch/arm64/kernel/sdei.c:136:33: error: ‘info’ undeclared (first use in this
function); did you mean ‘int’?
if (on_sdei_critical_stack(sp, info))
^~~~
int
arch/arm64/kernel/sdei.c:131:21: warning: unused variable ‘high’
[-Wunused-variable]
unsigned long low, high;
^~~~
arch/arm64/kernel/sdei.c:131:16: warning: unused variable ‘low’
[-Wunused-variable]
unsigned long low, high;
^~~
make[1]: *** [arch/arm64/kernel/sdei.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [arch/arm64/kernel] Error 2
Ugh this was a failure that I missed folding in, sorry about that
--- 8<
diff --git a/arch/arm64/kernel/sdei.c b/arch/arm64/kernel/sdei.c
index 7154fee1cb2b..a94a868f0532 100644
--- a/arch/arm64/kernel/sdei.c
+++ b/arch/arm64/kernel/sdei.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -125,11 +126,8 @@ bool on_sdei_critical_stack(unsigned long sp,
}
bool _on_sdei_stack(unsigned long sp,
- unsigned long *stack_low,
- unsigned long *stack_high)
+ struct stack_info *info)
{
- unsigned long low, high;
-
if (!IS_ENABLED(CONFIG_VMAP_STACK))
return false;
Re: [PATCH v2 1/1] remoteproc: correct rproc_free_vring() to avoid invalid kernel paging
Hi Loic,
On 07/06/2018 02:46 AM, Loic Pallardy wrote:
> If rproc_start() failed, rproc_resource_cleanup() is called to clean
> debugfs entries, then associated iommu mappings, carveouts and vdev.
> Issue occurs when rproc_free_vring() is trying to reset vring resource
> table entry.
> At this time, table_ptr is pointing on loaded resource table and carveouts
> already released, so access to loaded resource table is generating a kernel
> paging error:
Are you using a device specific CMA pool or carveout, and if so, where
the pool is? If not, where is the default CMA pool? I am trying to
reproduce the issue on my platform with the start failure as you
suggested, but haven't seen it so far. That said, I have seen the exact
same crash when using HighMEM CMA pools on my downstream kernel when
stopping the processor, and the root cause is essentially the same as
what you summarized here. The issue was present with LowMem pools as
well, but got masked because of the kernel linear mapping.
>
> [ 12.696535] Unable to handle kernel paging request at virtual address
> f0f357cc
> [ 12.696540] pgd = (ptrval)
> [ 12.696542] [f0f357cc] *pgd=6d2d0811, *pte=, *ppte=
> [ 12.696558] Internal error: Oops: 807 [#1] SMP ARM
> [ 12.696563] Modules linked in: rpmsg_core v4l2_mem2mem
> videobuf2_dma_contig sti_drm v4l2_common vida
> [ 12.696598] CPU: 1 PID: 48 Comm: kworker/1:1 Tainted: GW
> 4.18.0-rc2-00018-g3170fdd-8
> [ 12.696602] Hardware name: STi SoC with Flattened Device Tree
> [ 12.696625] Workqueue: events request_firmware_work_func
> [ 12.696659] PC is at rproc_free_vring+0x84/0xbc [remoteproc]
> [ 12.696667] LR is at rproc_free_vring+0x70/0xbc [remoteproc]
>
> This patch proposes to simply remove reset of resource table vring entries,
> as firmware and resource table are reloaded at each rproc boot.
> rproc_trigger_recovery() not impacted as resources not touched during recovery
> procedure.
And error recovery doesn't work for me after the rproc_start, stop got
introduced.
regards
Suman
>
> Signed-off-by: Loic Pallardy
> ---
> Changes from V1: typo fixes in commit message
>
> drivers/remoteproc/remoteproc_core.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index a9609d9..9a8b47c 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -289,16 +289,10 @@ void rproc_free_vring(struct rproc_vring *rvring)
> {
> int size = PAGE_ALIGN(vring_size(rvring->len, rvring->align));
> struct rproc *rproc = rvring->rvdev->rproc;
> - int idx = rvring->rvdev->vring - rvring;
> - struct fw_rsc_vdev *rsc;
>
> dma_free_coherent(rproc->dev.parent, size, rvring->va, rvring->dma);
> idr_remove(>notifyids, rvring->notifyid);
>
> - /* reset resource entry info */
> - rsc = (void *)rproc->table_ptr + rvring->rvdev->rsc_offset;
> - rsc->vring[idx].da = 0;
> - rsc->vring[idx].notifyid = -1;
> }
>
> static int rproc_vdev_do_probe(struct rproc_subdev *subdev)
>
Re: [PATCH 5/7] x86/vdso: Add vDSO functions for direct store instructions
On Mon, Jul 23, 2018 at 10:27:34PM -0700, Andy Lutomirski wrote: > On Mon, Jul 23, 2018 at 8:42 PM, Fenghua Yu wrote: > > On Mon, Jul 23, 2018 at 06:48:00PM -0700, Andy Lutomirski wrote: > >> On 07/23/2018 05:55 AM, Fenghua Yu wrote: > >> >The instructions can be implemented in intrinsic functions in future > >> >GCC. But the vDSO interfaces are available to user without the > >> I'm not convinced that any of this belongs in the vDSO at all. You could > >> just add AT_HWCAP (or AT_HWCAP2) flags for the new instructions. Or user > > > > Thomas asked to use vDSO. Please see the discussion thread: > > https://lkml.org/lkml/2018/6/19/316 > > I think he meant that, if these helpers belong in the kernel at all, > then they belong in the vDSO. But I think they mostly don't belong in > the kernel. I think both you and Thomas are right. I misunderstood Thomas's comments. I will remove the APIs/functions from next version of patch set. They don't belong to kernel and will be implemented in either GCC or glibc. GCC8 already implemented movdiri and movdir64b instruction intrinsics. GCC9 will implement user wait instruction intrinsics. If user wants to use those instinsics now, this GCC link has them: https://gcc.gnu.org/git/?p=gcc.git;a=summary If user wants to use the intrinsics in native code, the user needs to check availability of the features (i.e. movdiri, movdir64b, waitpkg) by running cpuid or a glibc interface that is going to be available in newer glibc. Thank you for your comments! -Fenghua
[PATCH v2 2/3] pinctrl: msm: Mux out gpio function with gpio_request()
We rely on devices to use pinmuxing configurations in DT to select the
GPIO function (function 0) if they're going to use the gpio in GPIO
mode. Let's simplify things for driver authors by implementing
gpio_request_enable() for this pinctrl driver to mux out the GPIO
function when the gpio is use from gpiolib.
Cc: Bjorn Andersson
Cc: Doug Anderson
Signed-off-by: Stephen Boyd
---
Changes from v1:
* None
drivers/pinctrl/qcom/pinctrl-msm.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 3970dc599092..1d7367149268 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -176,11 +176,27 @@ static int msm_pinmux_set_mux(struct pinctrl_dev *pctldev,
return 0;
}
+static int msm_pinmux_request_gpio(struct pinctrl_dev *pctldev,
+ struct pinctrl_gpio_range *range,
+ unsigned offset)
+{
+ struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+ const struct msm_pingroup *g = >soc->groups[offset];
+
+ /* No funcs? Probably ACPI so can't do anything here */
+ if (!g->nfuncs)
+ return 0;
+
+ /* For now assume function 0 is GPIO because it always is */
+ return msm_pinmux_set_mux(pctldev, 0, offset);
+}
+
static const struct pinmux_ops msm_pinmux_ops = {
.request= msm_pinmux_request,
.get_functions_count= msm_get_functions_count,
.get_function_name = msm_get_function_name,
.get_function_groups= msm_get_function_groups,
+ .gpio_request_enable= msm_pinmux_request_gpio,
.set_mux= msm_pinmux_set_mux,
};
--
Sent by a computer through tubes
[PATCH v2 1/3] pinctrl: msm: Really mask level interrupts to prevent latching
The interrupt controller hardware in this pin controller has two status
enable bits. The first "normal" status enable bit enables or disables
the summary interrupt line being raised when a gpio interrupt triggers
and the "raw" status enable bit allows or prevents the hardware from
latching an interrupt into the status register for a gpio interrupt.
Currently we just toggle the "normal" status enable bit in the mask and
unmask ops so that the summary irq interrupt going to the CPU's
interrupt controller doesn't trigger for the masked gpio interrupt.
For a level triggered interrupt, the flow would be as follows: the pin
controller sees the interrupt, latches the status into the status
register, raises the summary irq to the CPU, summary irq handler runs
and calls handle_level_irq(), handle_level_irq() masks and acks the gpio
interrupt, the interrupt handler runs, and finally unmask the interrupt.
When the interrupt handler completes, we expect that the interrupt line
level will go back to the deasserted state so the genirq code can unmask
the interrupt without it triggering again.
If we only mask the interrupt by clearing the "normal" status enable bit
then we'll ack the interrupt but it will continue to show up as pending
in the status register because the raw status bit is enabled, the
hardware hasn't deasserted the line, and thus the asserted state latches
into the status register again. When the hardware deasserts the
interrupt the pin controller still thinks there is a pending unserviced
level interrupt because it latched it earlier. This behavior causes
software to see an extra interrupt for level type interrupts each time
the interrupt is handled.
Let's fix this by clearing the raw status enable bit for level type
interrupts so that the hardware stops latching the status of the
interrupt after we ack it. We don't do this for edge type interrupts
because it seems that toggling the raw status enable bit for edge type
interrupts causes spurious edge interrupts.
Cc: Bjorn Andersson
Cc: Doug Anderson
Signed-off-by: Stephen Boyd
---
Changes from v1:
- Squashed raw_status_bit write into same write on unmask (Doug
Andersson)
drivers/pinctrl/qcom/pinctrl-msm.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 2155a30c282b..3970dc599092 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -634,6 +634,19 @@ static void msm_gpio_irq_mask(struct irq_data *d)
raw_spin_lock_irqsave(>lock, flags);
val = readl(pctrl->regs + g->intr_cfg_reg);
+ /*
+* Leaving the RAW_STATUS_EN bit enabled causes level interrupts that
+* are still asserted to re-latch after we ack them. Clear the raw
+* status enable bit too so the interrupt can't even latch into the
+* hardware while it's masked, but only do this for level interrupts
+* because edge interrupts have a problem with the raw status bit
+* toggling and causing spurious interrupts.
+*/
+ if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK) {
+ val &= ~BIT(g->intr_raw_status_bit);
+ writel(val, pctrl->regs + g->intr_cfg_reg);
+ }
+
val &= ~BIT(g->intr_enable_bit);
writel(val, pctrl->regs + g->intr_cfg_reg);
@@ -655,6 +668,7 @@ static void msm_gpio_irq_unmask(struct irq_data *d)
raw_spin_lock_irqsave(>lock, flags);
val = readl(pctrl->regs + g->intr_cfg_reg);
+ val |= BIT(g->intr_raw_status_bit);
val |= BIT(g->intr_enable_bit);
writel(val, pctrl->regs + g->intr_cfg_reg);
--
Sent by a computer through tubes
RE: [PATCH] clk: Add functions to get optional clocks
Quoting Phil Edworthy (2018-07-18 06:56:26) > Hi Russell, > > On 18 July 2018 14:19, Geert Uytterhoeven wrote: > > On Wed, Jul 18, 2018 at 3:02 PM Russell King - ARM Linux wrote: > > > On Wed, Jul 18, 2018 at 01:57:38PM +0100, Phil Edworthy wrote: > > > > Behaves the same as (devm_)clk_get except where there is no clock > > > > producer. In this case, instead of returning -ENOENT, the function > > > > returns NULL. This makes error checking simpler and allows > > > > clk_prepare_enable, etc to be called on the returned reference > > > > without additional checks. > > > > > > How does this work with non-DT systems, where looking a clock up which > > > isn't yet registered with clkdev returns -ENOENT ? > > > > > > (clkdev doesn't know when all clocks are registered with it.) > > > > Good question. > > > > I guess all drivers trying to handle optional clocks this way are already > > broken > > on non-DT systems where clocks may be registered late... > > So how do non-DT systems that look a clock up which isn't yet > registered with clkdev, determine that an optional clock is there > or not? > Short answer is they don't. I'd still prefer we have this API though. Can you rework this patch to be a little more invasive into the clk_get() path, perhaps by reworking __of_clk_get_by_name() a little to take an 'optional' argument, so that it only returns NULL when the clk is looked up from DT? The fallback path in clkdev where we have a DT based system looking up a clk through clkdev lookups doesn't seem to be a real scenario that we should worry about here. I think sometimes people use clkdev lookups when they're migrating to DT systems and things aren't wired up properly in DT, but that isn't the norm.
Re: [PATCH 1/1] rpmsg: virtio_rpmsg_bus: Fix rpmsg_create_channel memory leak
Hi Loic,
On 07/25/2018 04:08 PM, Loic Pallardy wrote:
> In case of rpmsg_register_device() failure, vch previously
> allocated must be free.
>
Isn't this already handled through the virtio_rpmsg_release_device()
callback as part of the put_device() in rpmsg_register_device() failure.
regards
Suman
> fixes: 6eed598a0491 ("rpmsg: Split off generic tail of create_channel()")
>
> Signed-off-by: Loic Pallardy
> ---
> drivers/rpmsg/virtio_rpmsg_bus.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 664f957..10f927e 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -431,8 +431,10 @@ static struct rpmsg_device *rpmsg_create_channel(struct
> virtproc_info *vrp,
> rpdev->dev.parent = >vdev->dev;
> rpdev->dev.release = virtio_rpmsg_release_device;
> ret = rpmsg_register_device(rpdev);
> - if (ret)
> + if (ret) {
> + kfree(vch);
> return NULL;
> + }
>
> return rpdev;
> }
>
Re: [PATCH v1 1/3] thermal: tsens: Rename variable
On Wed, Jul 18, 2018 at 12:55:01PM +0530, Amit Kucheria wrote:
> We're actually reading the temperature from the status register. Fix the
> variable name to reflect that.
>
> Signed-off-by: Amit Kucheria
> ---
> drivers/thermal/qcom/tsens-common.c | 6 +++---
> drivers/thermal/qcom/tsens-v2.c | 10 +-
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens-common.c
> b/drivers/thermal/qcom/tsens-common.c
> index c22dc18..25e7f24 100644
> --- a/drivers/thermal/qcom/tsens-common.c
> +++ b/drivers/thermal/qcom/tsens-common.c
> @@ -104,11 +104,11 @@ int get_temp_common(struct tsens_device *tmdev, int id,
> int *temp)
> {
> struct tsens_sensor *s = >sensor[id];
> u32 code;
> - unsigned int sensor_addr;
> + unsigned int status_reg;
> int last_temp = 0, ret;
>
> - sensor_addr = S0_ST_ADDR + s->hw_id * SN_ADDR_OFFSET;
> - ret = regmap_read(tmdev->map, sensor_addr, );
> + status_reg = S0_ST_ADDR + s->hw_id * SN_ADDR_OFFSET;
> + ret = regmap_read(tmdev->map, status_reg, );
> if (ret)
> return ret;
> last_temp = code & SN_ST_TEMP_MASK;
> diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
> index f40150f..908e3dc 100644
> --- a/drivers/thermal/qcom/tsens-v2.c
> +++ b/drivers/thermal/qcom/tsens-v2.c
> @@ -16,11 +16,11 @@ static int get_temp_tsens_v2(struct tsens_device *tmdev,
> int id, int *temp)
> {
> struct tsens_sensor *s = >sensor[id];
> u32 code;
> - unsigned int sensor_addr;
> + unsigned int status_reg;
> int last_temp = 0, last_temp2 = 0, last_temp3 = 0, ret;
>
> - sensor_addr = tmdev->tm_offset + STATUS_OFFSET + s->hw_id * 4;
> - ret = regmap_read(tmdev->map, sensor_addr, );
> + status_reg = tmdev->tm_offset + STATUS_OFFSET + s->hw_id * 4;
> + ret = regmap_read(tmdev->map, status_reg, );
> if (ret)
> return ret;
> last_temp = code & LAST_TEMP_MASK;
> @@ -28,7 +28,7 @@ static int get_temp_tsens_v2(struct tsens_device *tmdev,
> int id, int *temp)
> goto done;
>
> /* Try a second time */
> - ret = regmap_read(tmdev->map, sensor_addr, );
> + ret = regmap_read(tmdev->map, status_reg, );
> if (ret)
> return ret;
> if (code & STATUS_VALID_BIT) {
> @@ -39,7 +39,7 @@ static int get_temp_tsens_v2(struct tsens_device *tmdev,
> int id, int *temp)
> }
>
> /* Try a third/last time */
> - ret = regmap_read(tmdev->map, sensor_addr, );
> + ret = regmap_read(tmdev->map, status_reg, );
> if (ret)
> return ret;
> if (code & STATUS_VALID_BIT) {
Reviewed-by: Matthias Kaehlcke
[PATCH] PCI: Equalize hotplug memory for non/occupied slots
Currently, a hotplug bridge will be given hpmemsize additional memory if
available, in order to satisfy any future hotplug allocation
requirements.
These calculations don't consider the current memory size of the hotplug
bridge/slot, so hotplug bridges/slots which have downstream devices will
get their current allocation in addition to the hpmemsize value.
This makes for possibly undesirable results with a mix of unoccupied and
occupied slots (ex, with hpmemsize=2M):
02:03.0 PCI bridge: <-- Occupied
Memory behind bridge: d620-d64f [size=3M]
02:04.0 PCI bridge: <-- Unoccupied
Memory behind bridge: d650-d66f [size=2M]
This change considers the current allocation size when using the
hpmemsize parameter to make the reservations predictable for the mix of
unoccupied and occupied slots:
02:03.0 PCI bridge: <-- Occupied
Memory behind bridge: d620-d63f [size=2M]
02:04.0 PCI bridge: <-- Unoccupied
Memory behind bridge: d640-d65f [size=2M]
Signed-off-by: Jon Derrick
---
Original RFC here:
https://patchwork.ozlabs.org/patch/945374/
I split this bit out from the RFC while awaiting the pci string handling
enhancements to handle per-device settings
Changed from RFC is a simpler algo
drivers/pci/setup-bus.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 79b1824..5ae39e6 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -831,7 +831,8 @@ static resource_size_t calculate_iosize(resource_size_t
size,
static resource_size_t calculate_memsize(resource_size_t size,
resource_size_t min_size,
- resource_size_t size1,
+ resource_size_t add_size,
+ resource_size_t children_add_size,
resource_size_t old_size,
resource_size_t align)
{
@@ -841,7 +842,7 @@ static resource_size_t calculate_memsize(resource_size_t
size,
old_size = 0;
if (size < old_size)
size = old_size;
- size = ALIGN(size + size1, align);
+ size = ALIGN(max(size, add_size) + children_add_size, align);
return size;
}
@@ -1079,12 +1080,10 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
min_align = calculate_mem_align(aligns, max_order);
min_align = max(min_align, window_alignment(bus, b_res->flags));
- size0 = calculate_memsize(size, min_size, 0, resource_size(b_res),
min_align);
+ size0 = calculate_memsize(size, min_size, 0, 0, resource_size(b_res),
min_align);
add_align = max(min_align, add_align);
- if (children_add_size > add_size)
- add_size = children_add_size;
- size1 = (!realloc_head || (realloc_head && !add_size)) ? size0 :
- calculate_memsize(size, min_size, add_size,
+ size1 = (!realloc_head || (realloc_head && !add_size &&
!children_add_size)) ? size0 :
+ calculate_memsize(size, min_size, add_size, children_add_size,
resource_size(b_res), add_align);
if (!size0 && !size1) {
if (b_res->start || b_res->end)
--
1.8.3.1
Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting
Hi,
On Wed, Jul 25, 2018 at 07:48:21AM +1000, NeilBrown wrote:
> On Tue, Jul 24 2018, Brian Norris wrote:
> > On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote:
> >> On Tue, Jul 24 2018, Boris Brezillon wrote:
> >> > On Tue, 24 Jul 2018 08:46:33 +1000
> >> > NeilBrown wrote:
> >> >> One possibility that occurred to me when I was exploring this issue is
> >> >> to revert to 3-byte mode whenever 4-byte was not actively in use.
> >> >> So any access beyond 16Meg is:
> >> >> switch-to-4-byte ; perform IO ; switch to 3-byte
> >> >> or similar. On my hardware it would be more efficient to
> >> >> use the 4-byte opcode to perform the IO, then reset the cached
> >> >> 4th address byte that the NOR chip transparently remembered.
> >
> > Do these chips cache the last 4th-byte used? I don't recall reading
> > that, but that would be interesting. It also sounds like that would make
> > things even more difficult to do robustly.
>
> That is how the Winbond W25Q256FV appears to behave in my experiments.
> Any time you use a 4-byte address, the high byte is saved. Any time you
> use a 3-byte address, the saved high-byte is used.
> The data sheet seems to support this understanding, as detailed in
>
> Commit: f134fbbb4ff8 ("mtd: spi-nor: clear Winbond Extended Address Reg on
> switch to 3-byte addressing.")
Thanks for the notes. I never really paid attention to that section of
the datasheet, since I always relied on a hardware reset.
By the way, doesn't this part support the dedicated (non-stateful)
4-byte address commands? Why not use those and avoid the problem
entirely? Although, it's not actually clear to me from the datasheet
whether, e.g., Fast Read with 4-byte Address (0Ch) will set the Extended
Address Register.
> >> >> This adds a little overhead, but should be fairly robust.
> >> >> It doesn't help if something goes terribly wrong while IO is happening,
> >> >> but I don't think any other software solution does either.
> >> >>
> >> >> How would you see that approach?
> >> >
> >> > I think the problem stands: people that have proper HW mitigation for
> >> > this problem (NOR chip is reset when the Processor is reset) don't want
> >> > to pay the overhead. So, even if we go for this approach, we probably
> >> > want to only do that for broken HW.
> >
> > If it actually saves bytes on the wire to stay in 3-byte mode more
> > often, then that could be helpful to all systems. But otherwise, yes, it
> > doesn't really belong on a properly-designed system.
>
> I'm not sure exactly what you encompass by the term "properly-designed",
I consider all systems with >16MiB SPI flash that have stateful
addressing modes and don't have a useful HW RESET signal to be
improperly designed. These SPI flash never had a standardized (or
easily-determined) software reset, so it's nearly impossible to write
robust software for them that is compatible with a relatively generic
boot ROM and/or bootloader.
> but with the SOC that I have (mt7621) and the flash chip (Winbond
> W25Q256FV) it is not possible to wire them up in any way that will work
> reliably without software support for leaving 3-byte mode.
> The SOC does not have an out-going reset line that signals a general
> system reset - it only has one that signals watchdog reset.
> The flash chip has an incoming reset line, but it shares a pin with
> "hold", and that is the default use. So we would need to program the
(BTW, you could probably choose to reprogram the HOLD# line to RESET#
before switching to 4-byte mode. That still doesn't resolve the SoC
reset line issue on its own.)
> flash to listen for reset, and it would only catch a watchdog reset.
> For any other reset, the CPU is (should be) in complete control (even
> after a panic!) and it needs to reprogram the flash chip before
> resetting the system.
"Even after a panic" is a bit dubious. That presumes that the cause of
the panic didn't also corrupt your exception code, driver code, driver
data structures, etc., that would be needed to reset the SPI chip
without double-faulting. And what about a panic in your SPI flash
driver?
Overall, my point is that the existence of such non-hardware-resettable
flash guarantees the possibility of a hard enough crash that you cannot
possibly reset it to 3-byte addressing before system reset.
> But maybe you think either the SOC and/or the flash chip is not
> "properly-designed" - and you may be correct..
Yes, I believe I do. If your watchdog reset pin was routed to the flash
HOLD/RESET pin, then I suppose it would be *possible* to have robust
software. But otherwise, I believe it's impossible.
Brian
Re: [PATCH 1/2] clk: uniphier: add NAND 200MHz clock
Quoting Masahiro Yamada (2018-07-20 01:37:35) > The Denali NAND controller IP needs three clocks: > > - clk: controller core clock > > - clk_x: bus interface clock > > - ecc_clk: clock at which ECC circuitry is run > > Currently, only the first one (50MHz) is provided. The rest of the > two clock ports must be connected to the 200MHz clock line. Add this. > > Signed-off-by: Masahiro Yamada > --- Applied to clk-next
Re: [PATCH 2/2] clk: uniphier: add more USB3 PHY clocks
Quoting Masahiro Yamada (2018-07-20 01:37:36) > Add USB3 PHY clocks where missing. Use fixed-factor clocks for those > without gating. > > For clarification, prefix clock names with 'ss' or 'hs'. > > Signed-off-by: Masahiro Yamada > --- Applied to clk-next
Re: [PATCH v7 1/5] clk: actions: Add missing REGMAP_MMIO dependency
Quoting Saravanan Sekar (2018-07-19 02:06:45)
> Add REGMAP_MMIO as dependency to avoid undefined
> reference to regmap symbols.
>
> Fixes: d85d20053e19 ("clk: actions: Add S900 SoC clock support")
> Signed-off-by: Saravanan Sekar
> Reviewed-by: Andreas Färber
> Reviewed-by: Manivannan Sadhasivam
> ---
Applied to clk-next
Re: [PATCH v7 2/5] dt-bindings: clock: Add S700 support for Actions Semi Soc's
Quoting Saravanan Sekar (2018-07-19 02:06:46) > Add clock bindings constants for action S700 > Maintain common clock dt-bindings for Actions Semi SoC's > S700 and S900. > > Signed-off-by: Parthiban Nallathambi > Signed-off-by: Saravanan Sekar > Reviewed-by: Rob Herring > --- Applied to clk-next
Re: [PATCH v7 3/5] clk: actions: Add S700 SoC clock support
Quoting Saravanan Sekar (2018-07-19 02:06:47) > Add Actions Semi S700 SoC clock support > > Signed-off-by: Parthiban Nallathambi > Signed-off-by: Saravanan Sekar > Reviewed-by: Manivannan Sadhasivam > --- Applied to clk-next
Re: [PATCH] clk: tegra: probe deferral error reporting
On 7/25/2018 7:24 PM, Stephen Boyd wrote:
Quoting Marcel Ziswiler (2018-07-20 00:54:22)
From: Marcel Ziswiler
Actually report the error code from devm_regulator_get() which may as
well just be a probe deferral.
Signed-off-by: Marcel Ziswiler
---
drivers/clk/tegra/clk-dfll.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
index 48ee43734e05..b2123084e175 100644
--- a/drivers/clk/tegra/clk-dfll.c
+++ b/drivers/clk/tegra/clk-dfll.c
@@ -1609,8 +1609,9 @@ int tegra_dfll_register(struct platform_device *pdev,
td->vdd_reg = devm_regulator_get(td->dev, "vdd-cpu");
if (IS_ERR(td->vdd_reg)) {
- dev_err(td->dev, "couldn't get vdd_cpu regulator\n");
- return PTR_ERR(td->vdd_reg);
+ ret = PTR_ERR(td->vdd_reg);
+ dev_err(td->dev, "couldn't get vdd_cpu regulator: %d\n", ret);
Do you want to know that a probe defer is happening? Usually patches are
sent to make that error path silent.
Just asking as the newbie here, but shouldn't probe deferral be
regulated to dev_debug?
Then pass any other error code as dev_err.
Re: linux-next: Signed-off-by missing for commit in the xarray tree
On 07/25/2018 05:03 PM, Stephen Rothwell wrote:
> Hi Matthew,
>
> On Wed, 25 Jul 2018 16:36:21 -0700 Matthew Wilcox wrote:
>>
>> On Thu, Jul 26, 2018 at 07:28:14AM +1000, Stephen Rothwell wrote:
>>>
>>> Commits
>>>
>>> 890e537e2b42 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
>>> aaf149902c79 ("filesystem-dax: Set page->index")
>>>
>>> are missing a Signed-off-by from their committers.
>>
>> Oh, hah. I assume this is an automated email?
>
> Well, semi-automatic :-)
>
>> These two commits I cherry-picked from the nvdimm tree so that XArray can
>> be rebased on top of it. Is there some other way I should be doing this,
>> like rebasing on top of the nvdimm tree?
>
> Ideally, the nvdimm tree would have just those two commits in a branch
> that you could merge (so that you both have the same commits (as
> opposed to patches)) that way these changes cannot cause conflicts when
> the files are further modifed in either tree. Alternatively, if you do
> have to cherry-pick them, then you need to add your Signed-off-by to
> the copy that you commit.
>
> As things are now, you could merge commit
>
> c2a7d2a11552 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
>
> from the nvdimm tree into your tree before the conflicting commits in
> your tree (or just rebase your tree on top of that commit). You need
> to make sure that Dan and/or Dave (cc'd) will never rebase that part of
> their tree. Also, you will pick up some other commits (which may not
> be a problem for you).
>
I have all the acks I need for that branch for Dan's patches. So that
branch shouldn't change anymore AFAIK.
