Re: [PATCH V4 1/3] mmc: sdhci: add support for using external DMA devices

[Chunyan Zhang]

On Thu, 27 Dec 2018 at 15:44, Adrian Hunter  wrote:
>
> On 11/12/18 11:12 AM, Chunyan Zhang wrote:
> > Some standard SD host controllers can support both external dma
> > controllers as well as ADMA/SDMA in which the SD host controller
> > acts as DMA master. TI's omap controller is the case as an example.
> >
> > Currently the generic SDHCI code supports ADMA/SDMA integrated in
> > the host controller but does not have any support for external DMA
> > controllers implemented using dmaengine, meaning that custom code is
> > needed for any systems that use an external DMA controller with SDHCI.
> >
> > Signed-off-by: Chunyan Zhang 
>
> FYI, I am waiting on successful testing before reviewing these patches again.

Yeah, that makes sense, thanks Adrian!

I intend to send out another new patchset after the holidays.
After had another look at omap_hsmmc, I knew something need to be
modified (emailed Faiz about this privately), but I was still not sure
if it can fix the problem Faiz found.

Happy new year to all,
Chunyan

Re: [PATCH] xfs: add a check for xfs_trans_commit

[Christoph Hellwig]

On Wed, Dec 26, 2018 at 12:05:16AM -0600, Kangjie Lu wrote:
> xfs_trans_commit could fails. The checks issues an error message upon
> its failure.
> 
> Signed-off-by: Kangjie Lu 

Please take a close look at what could fail in xfs_trans_commit, and how
those failures are logged inside the implementation.

Re: [PATCH] perf python: Do not force closing original perf descriptor in evlist.get_pollfd

[Jiri Olsa]

On Wed, Dec 26, 2018 at 12:21:21PM +0100, Jiri Olsa wrote:
> Ondřej reported that when compiled with python3, the python
> extension regress in evlist.get_pollfd function behaviour.
> 
> The evlist.get_pollfd creates file objects from evlist's fds
> and returns them in the list. The python3 version also sets
> them to 'close the original descriptor' when the object die
> (is closed), by passing True via 'closefd' arg in PyFile_FromFd
> call.
> 
> The python's closefd doc says:
>   If closefd is False, the underlying file descriptor will be kept open
>   when the file is closed.
> 
> That's why following line in python3 closes all evlist fds:
>   evlist.get_pollfd()
> 
> the returned list is immediately destroyed and that takes
> down the original events fds.
> 
> Passing closefd as False to PyFile_FromFd to fix this.
> 
> Reported-by: Ondřej Lysoněk 
> Link: http://lkml.kernel.org/n/tip-ru9hmsaliew8p01kr0050...@git.kernel.org
> Signed-off-by: Jiri Olsa 

oops, forgot to add.. and cc-ing Jaroslav Škarvada

Fixes: 66dfdff03d19 ("perf tools: Add Python 3 support")

jirka

> ---
>  tools/perf/util/python.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
> index 47628e85c5eb..dda0ac978b1e 100644
> --- a/tools/perf/util/python.c
> +++ b/tools/perf/util/python.c
> @@ -939,7 +939,8 @@ static PyObject *pyrf_evlist__get_pollfd(struct 
> pyrf_evlist *pevlist,
>  
>   file = PyFile_FromFile(fp, "perf", "r", NULL);
>  #else
> - file = PyFile_FromFd(evlist->pollfd.entries[i].fd, "perf", "r", 
> -1, NULL, NULL, NULL, 1);
> + file = PyFile_FromFd(evlist->pollfd.entries[i].fd, "perf", "r", 
> -1,
> +  NULL, NULL, NULL, 0);
>  #endif
>   if (file == NULL)
>   goto free_list;
> -- 
> 2.17.2
> 

Re: [PATCH 15/18] drm/mediatek: add RDMA1 fifo size into RDMA private data

[CK Hu]

Hi, Yongqiang:

On Mon, 2018-12-24 at 16:08 +0800, Yongqiang Niu wrote:
> This patch add RDMA1 fifo size into RDMA private data
> 
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index b0a5cff..3f9b4d4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -53,12 +53,14 @@
>  #define RDMA_FIFO_PSEUDO_SIZE(bytes) (((bytes) / 16) << 16)
>  #define RDMA_OUTPUT_VALID_FIFO_THRESHOLD(bytes)  ((bytes) / 16)
>  #define RDMA_FIFO_SIZE(rdma) ((rdma)->data->fifo_size)
> +#define RDMA_FIFO_SIZE1(rdma)
> ((rdma)->data->fifo_size1)
>  #define DISP_RDMA_MEM_START_ADDR 0x0f00
>  
>  #define RDMA_MEM_GMC 0x40402020
>  
>  struct mtk_disp_rdma_data {
>   unsigned int fifo_size;
> + unsigned int fifo_size1;
>  };
>  
>  /**
> @@ -137,11 +139,17 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
> unsigned int width,
>  {
>   unsigned int threshold;
>   unsigned int reg;
> + unsigned int rdma_fifo_size;
>   struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
>  
>   rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
>   rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xf, height);
>  
> + if (comp->id == DDP_COMPONENT_RDMA1)
> + rdma_fifo_size = RDMA_FIFO_SIZE1(rdma);
> + else
> + rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
> +

It looks like that mt81830-rdma0 and mt8183-rdma1 are different in
hardware, so I think fifo_size should be decided by something from
device tree rather than from its name. Maybe add a property 'FIFO_SIZE'
in rdma device node or create an additional compatible string for
mt8183-rdma1.

Regards,
CK

>   /*
>* Enable FIFO underflow since DSI and DPI can't be blocked.
>* Keep the FIFO pseudo size reset default of 8 KiB. Set the
> @@ -149,8 +157,12 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
> unsigned int width,
>* account for blanking, and with a pixel depth of 4 bytes:
>*/
>   threshold = width * height * vrefresh * 4 * 7 / 100;
> +
> + if (threshold > rdma_fifo_size)
> + threshold = rdma_fifo_size;
> +
>   reg = RDMA_FIFO_UNDERFLOW_EN |
> -   RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
> +   RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
> RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
>   writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
>  }
> @@ -330,10 +342,12 @@ static int mtk_disp_rdma_remove(struct platform_device 
> *pdev)
>  
>  static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
>   .fifo_size = SZ_4K,
> + .fifo_size1 = SZ_4K,
>  };
>  
>  static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
>   .fifo_size = SZ_8K,
> + .fifo_size1 = SZ_8K,
>  };
>  
>  static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {

Re: [PATCH 1/5] perf session: Get rid of file_size variable

[Jiri Olsa]

On Wed, Dec 26, 2018 at 04:43:42PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 26, 2018 at 02:51:28PM +0100, Jiri Olsa escreveu:
> > It's not needed and removing it makes the code little
> > more simple for upcoming changes.
> > 
> > It's safe to replace file_size with data_size, because
> > perf_data__size value is never smaller than data_offset
> > + data_size.
> 
> This is not applying to my perf/core branch, can you check?

hum, I've got clean rebase, pushed in perf/fixes

jirka

> 
> - Arnaldo
>  
> > Link: http://lkml.kernel.org/n/tip-ocz7zwwkkx11v0mkxrtcd...@git.kernel.org
> > Signed-off-by: Jiri Olsa 
> > ---
> >  tools/perf/util/session.c | 12 +---
> >  1 file changed, 5 insertions(+), 7 deletions(-)
> > 
> > diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> > index 3972f081a8f4..d6c1d3853f27 100644
> > --- a/tools/perf/util/session.c
> > +++ b/tools/perf/util/session.c
> > @@ -1818,7 +1818,6 @@ static int __perf_session__process_events(struct 
> > perf_session *session)
> > struct ordered_events *oe = &session->ordered_events;
> > struct perf_tool *tool = session->tool;
> > int fd = perf_data__fd(session->data);
> > -   u64 file_size = perf_data__size(session->data);
> > u64 data_offset = session->header.data_offset;
> > u64 data_size = session->header.data_size;
> > u64 head, page_offset, file_offset, file_pos, size;
> > @@ -1838,14 +1837,13 @@ static int __perf_session__process_events(struct 
> > perf_session *session)
> > if (data_size == 0)
> > goto out;
> >  
> > -   if (data_offset + data_size < file_size)
> > -   file_size = data_offset + data_size;
> > +   ui_progress__init_size(&prog, data_size, "Processing events...");
> >  
> > -   ui_progress__init_size(&prog, file_size, "Processing events...");
> > +   data_size += data_offset;
> >  
> > mmap_size = MMAP_SIZE;
> > -   if (mmap_size > file_size) {
> > -   mmap_size = file_size;
> > +   if (mmap_size > data_size) {
> > +   mmap_size = data_size;
> > session->one_mmap = true;
> > }
> >  
> > @@ -1910,7 +1908,7 @@ static int __perf_session__process_events(struct 
> > perf_session *session)
> > if (session_done())
> > goto out;
> >  
> > -   if (file_pos < file_size)
> > +   if (file_pos < data_size)
> > goto more;
> >  
> >  out:
> > -- 
> > 2.17.2
> 
> -- 
> 
> - Arnaldo

Re: [PATCH V5 1/3] mmc: sdhci: Fix sdhci_do_enable_v4_mode

[Adrian Hunter]

On 21/12/18 3:25 AM, Sowjanya Komatineni wrote:
> V4_MODE is Bit-15 of SDHCI_HOST_CONTROL2 register.
> Need to perform word access to this register.
> 
> Signed-off-by: Sowjanya Komatineni 

This patch has already been applied.

> ---
>  drivers/mmc/host/sdhci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 99bdae53fa2e..fde984d10619 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -127,12 +127,12 @@ static void sdhci_do_enable_v4_mode(struct sdhci_host 
> *host)
>  {
>   u16 ctrl2;
>  
> - ctrl2 = sdhci_readb(host, SDHCI_HOST_CONTROL2);
> + ctrl2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
>   if (ctrl2 & SDHCI_CTRL_V4_MODE)
>   return;
>  
>   ctrl2 |= SDHCI_CTRL_V4_MODE;
> - sdhci_writeb(host, ctrl2, SDHCI_HOST_CONTROL);
> + sdhci_writew(host, ctrl2, SDHCI_HOST_CONTROL2);
>  }
>  
>  /*
> 

[regression from v4.19] Re: 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?

[Pavel Machek]

Hi!

> > > > If you think it is useful, I can try to update my machine to
> > > > linux-next.
> > > 
> > > linux-next is closer to drm-tip, so it's better. Do you have some
> > > specific reason for not wanting to run drm-tip (but linux-next is still
> > > ok)?
> > 
> > I already have build/update scripts for -next, and I trust -next not
> > to store screenshots of my desktop in my master boot record :-).
> > 
> > Anyway, it does happen with -next. This time, chromiums were running,
> > and crash happened minute? after I exited flightgear. It can be seen
> > in the logs.
> > 
> > Oh and I might want to mention -- machine was rather deep in swap this
> > time, as in "mouse jumping when starting fgfs" and "could feel the
> > chromium being swapped back in". I might have had this situation
> > before, and just powercycled the machine "because it is so deep in
> > swap that it will not recover".
> > 
> > top says:
> > 
> > top - 19:18:24 up 2 days,  8:03,  2 users,  load average: 3.02, 3.45,
> > 3.21
> > Tasks: 141 total,   1 running,  86 sleeping,   0 stopped,   2 zombie
> > %Cpu(s): 18.8 us,  7.6 sy,  3.0 ni, 68.4 id,  1.3 wa,  0.0 hi,  0.9
> > si,  0.0 st
> > KiB Mem:   5967968 total,   663244 used,  5304724 free,48876
> > buffers
> > KiB Swap:  1681428 total,   170904 used,  1510524 free.   446280
> > cached Mem
> > 
> > but of course that memory is free once everything died.
> > 
> > Any ideas? Should I go back to v4.19 to see if it happens there, too?
> 
> linux-next includes very much the same code as drm-tip. There's nobody
> magically reviewing the code more than it is reviewed for inclusion into
> drm-tip, when it is fed into linux-next. So thinking linux-next would be
> some way safer is an illusion.
> 
> It sounds like having memory pressure expedites the corruption, which
> should make it easier to reproduce and thus fix.
> 
> So if you could please try drm-tip reproducing AND open a bug in Bugzilla.
> If you are unwilling to do that, it is very difficult to help you
> more.

Website says I have to read and agree to two different pieces of
legalesee, and I'd need to keep track of yet another password... so
you can "communicate" with me.

But you can already communicate with me, over email.

I verified v4.19 is stable -- it worked ok for way more than two days
it usually takes to crash.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] regmap: regmap-irq: silently ignore unsupported type settings

[Matti Vaittinen]

Do not return error if irq-type setting is requested for
controlloer which does not support this. This is how
regmap-irq has previously handled the undupported type
settings and existing drivers seem to be upset if failure
is now reported.

Fixes: 1c2928e3e321 ("regmap: regmap-irq/gpio-max77620: add level-irq support")
Signed-off-by: Matti Vaittinen 
---

Geert reported that 1c2928e3e321 breaks da9063-rtc on the Renesas
Koelsch board:

https://lore.kernel.org/lkml/20181227075648.GB2461@localhost.localdomain/T/#m194616cc88d7b4c2a78f7ce07907608fdb64a092

Geert, do you know if anyone vould to test this?

 drivers/base/regmap/regmap-irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index 1bd1145ad8b5..d2d0014b0d23 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -258,7 +258,7 @@ static int regmap_irq_set_type(struct irq_data *data, 
unsigned int type)
const struct regmap_irq_type *t = &irq_data->type;
 
if ((t->types_supported & type) != type)
-   return -ENOTSUPP;
+   return 0;
 
reg = t->type_reg_offset / map->reg_stride;
 
-- 
2.14.3


-- 
Matti Vaittinen
ROHM Semiconductors

~~~ "I don't think so," said Rene Descartes.  Just then, he vanished ~~~

Re: [PATCH v4 2/5] leds: Add helper for getting default pattern from Device Tree

[Krzysztof Kozlowski]

On Tue, 18 Dec 2018 at 16:27, Krzysztof Kozlowski  wrote:
>
> Multiple LED triggers might need to access default pattern so add a
> helper for that.
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/leds/led-class.c | 42 ++

As pointed out by 0day-ci this has to be in leds-core.c.

I'll fix it.

Best regards,
Krzysztof

[PATCH] ALSA: hda/realtek: Enable the headset mic auto detection for ASUS laptops

[Jian-Hong Pan]

The headset mic of ASUS laptops like UX533FD, UX433FN and UX333FA, whose
CODEC is Realtek ALC294 has jack auto detection feature. This patch
enables the feature.

Signed-off-by: Daniel Drake 
Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index a4f4a9dd488d..aee4cbd29d53 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6501,7 +6501,7 @@ static const struct hda_fixup alc269_fixups[] = {
[ALC294_FIXUP_ASUS_HEADSET_MIC] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
-   { 0x19, 0x01a1113c }, /* use as headset mic, without 
its own jack detect */
+   { 0x19, 0x01a1103c }, /* use as headset mic */
{ }
},
.chained = true,
-- 
2.11.0

[PATCH v3] Optimize C3 entry on Centaur CPUs

[David Wang]

For new Centaur CPUs the ucode will take care of the preservation of cache 
coherence
between CPU cores in C-states regardless of how deep the C-states are. So, it 
is not
necessary to flush the caches in software befor entering C3. And this useless 
operation
will cause performance drop for the cores which share some caches with the 
idling core.  

Signed-off-by: David Wang 
Reviewed-by: Thomas Gleixner 

Changes from v2 to v3:
*1, Replace "c->x86_mask" with "c->x86_stepping".

Changes from v1 to v2:
* 1, Add some Family/Model/Stepping contrains to let this patch only apply
* to new centaur CPUs.
* 2, The arbiter disable/enable operations maybe needed for old VIA/Centaur
* platform. So, delete "flags->bm_control=0" in patch v1.

---
 arch/x86/kernel/acpi/cstate.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index 158ad14..ed17640 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -51,6 +51,18 @@ void acpi_processor_power_init_bm_check(struct 
acpi_processor_flags *flags,
if (c->x86_vendor == X86_VENDOR_INTEL &&
(c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
flags->bm_control = 0;
+   /*
+   * For all recent Centaur CPUs, the ucode will make sure that each
+   * core can keep cache coherence with each other while entering C3
+   * type state. So, set bm_check to 1 to indicate that the kernel
+   * need not execute a cache flush operation (WBINVD) when entering
+   * C3 type state.
+   */
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   if (c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0x0f &&
+   c->x86_stepping >= 0x0e))
+   flags->bm_check = 1;
+   }
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
 
-- 
1.9.1

Re: [PATCH] drivers: base: swnode: check if pointer p is null before dereferencing it

[Rafael J. Wysocki]

On Sat, Dec 22, 2018 at 1:49 PM Colin King  wrote:
>
> From: Colin Ian King 
>
> The pointer p can be potentially null macro to_software_node can return
> null.  Add null check on p before dereferencing it to avoid any null
> pointer dereferences.
>
> Detected by CoverityScan, CID#1476039 ("Explicit null dereferenced")
>
> Fixes: 59abd83672f7 ("drivers: base: Introducing software nodes to the 
> firmware node framework")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/base/swnode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> index 204aa7d049e0..89ad8dee6ad5 100644
> --- a/drivers/base/swnode.c
> +++ b/drivers/base/swnode.c
> @@ -488,7 +488,7 @@ software_node_get_next_child(const struct fwnode_handle 
> *fwnode,
> struct software_node *p = to_software_node(fwnode);
> struct software_node *c = to_software_node(child);
>
> -   if (list_empty(&p->children) ||
> +   if (!p || list_empty(&p->children) ||
> (c && list_is_last(&c->entry, &p->children)))
> return NULL;
>
> --

Applied, thanks!

Re: [PATCH][next] drivers: base: swnode: check if swnode is null before dereferencing it

[Rafael J. Wysocki]

On Sat, Dec 22, 2018 at 1:43 PM Colin King  wrote:
>
> From: Colin Ian King 
>
> The macro to_software_mode can potentially return NULL, so also add
> a null check on the swnode before dereferencing it to avoid any null
> pointer dereferences.
>
> Detected by CoverityScan, CID#1476052 ("Explicit null dereferenced")
>
> Fixes: 59abd83672f7 ("drivers: base: Introducing software nodes to the 
> firmware node framework")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/base/swnode.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> index 306bb93287af..204aa7d049e0 100644
> --- a/drivers/base/swnode.c
> +++ b/drivers/base/swnode.c
> @@ -477,7 +477,8 @@ software_node_get_parent(const struct fwnode_handle 
> *fwnode)
>  {
> struct software_node *swnode = to_software_node(fwnode);
>
> -   return swnode->parent ? &swnode->parent->fwnode : NULL;
> +   return swnode ? (swnode->parent ? &swnode->parent->fwnode : NULL) :
> +   NULL;
>  }
>
>  struct fwnode_handle *
> --

Applied, thanks!

Re: [PATCH V5 3/3] mmc: tegra: HW Command Queue Support for Tegra SDMMC

[Adrian Hunter]

On 21/12/18 3:25 AM, Sowjanya Komatineni wrote:
> This patch adds HW Command Queue for supported Tegra SDMMC
> controllers.
> 
> Tegra SDHCI with Quirk SDHCI_QUIRK2_BROKEN_64_BIT_DMA disables the
> use of 64_BIT DMA to disable 64-bit addressing mode access to the
> system memory and sdhci_cqe_enable using flag SDHCI_USE_64_BIT_DMA
> for ADMA32/ADMA2 Vs ADMA64/ADMA3 DMA selection.
> 
> CQE need to use ADMA3 as it need to fetch task descriptor along
> with transfer descriptor, so this patch forces DMA Select to be
> ADMA3 for CQE.
> 
> Tegra SDMMC Host design prevents write access to BLOCK_COUNT
> register when CQE is enabled to prevent SW from updating block
> size during Command Queue mode. As per eMMC5.1 device spec, block
> size of 512 B need to be set prior to enabling Command Queue.
> 
> Signed-off-by: Sowjanya Komatineni 

Just a couple of minor comments below.

> ---
>  drivers/mmc/host/Kconfig   |   1 +
>  drivers/mmc/host/sdhci-tegra.c | 138 
> -
>  2 files changed, 138 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 1b58739d9744..5aa2de2c7609 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -250,6 +250,7 @@ config MMC_SDHCI_TEGRA
>   depends on ARCH_TEGRA
>   depends on MMC_SDHCI_PLTFM
>   select MMC_SDHCI_IO_ACCESSORS
> + select MMC_CQHCI
>   help
> This selects the Tegra SD/MMC controller. If you have a Tegra
> platform with SD or MMC devices, say Y or M here.
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index 7b95d088fdef..68b328df05ed 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -33,6 +33,7 @@
>  #include 
>  
>  #include "sdhci-pltfm.h"
> +#include "cqhci.h"
>  
>  /* Tegra SDHOST controller vendor register definitions */
>  #define SDHCI_TEGRA_VENDOR_CLOCK_CTRL0x100
> @@ -89,6 +90,9 @@
>  #define NVQUIRK_NEEDS_PAD_CONTROLBIT(7)
>  #define NVQUIRK_DIS_CARD_CLK_CONFIG_TAP  BIT(8)
>  
> +/* SDMMC CQE Base Address for Tegra Host Ver 4.1 and Higher */
> +#define SDHCI_TEGRA_CQE_BASE_ADDR0xF000
> +
>  struct sdhci_tegra_soc_data {
>   const struct sdhci_pltfm_data *pdata;
>   u32 nvquirks;
> @@ -128,6 +132,7 @@ struct sdhci_tegra {
>   u32 default_tap;
>   u32 default_trim;
>   u32 dqs_trim;
> + bool enable_hwcq;
>  };
>  
>  static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
> @@ -836,6 +841,80 @@ static void tegra_sdhci_voltage_switch(struct sdhci_host 
> *host)
>   tegra_host->pad_calib_required = true;
>  }
>  
> +static void sdhci_tegra_cqe_enable(struct mmc_host *mmc)
> +{
> + struct sdhci_host *host = mmc_priv(mmc);
> + struct cqhci_host *cq_host = mmc->cqe_private;
> + unsigned long flags;
> + u8 ctrl;
> + u32 cqcfg = 0;
> +
> + spin_lock_irqsave(&host->lock, flags);
> +
> + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> + ctrl &= ~SDHCI_CTRL_DMA_MASK;
> + if ((host->flags & SDHCI_USE_64_BIT_DMA) ||
> + (host->quirks2 & SDHCI_QUIRK2_BROKEN_64_BIT_DMA))

You are selecting 64-bit DMA if 64-bit DMA is broken.  Is that intended?
Maybe add a comment.

> + ctrl |= SDHCI_CTRL_ADMA64;
> + else
> + ctrl |= SDHCI_CTRL_ADMA32;
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> +
> + /* Tegra SDMMC Controller design prevents write access to BLOCK_COUNT
> +  * registers when CQE is enabled.
> +  */
> + cqcfg = cqhci_readl(cq_host, CQHCI_CFG);
> + if (cqcfg & CQHCI_ENABLE)
> + cqhci_writel(cq_host, (cqcfg & ~CQHCI_ENABLE), CQHCI_CFG);
> +
> + sdhci_writew(host, SDHCI_MAKE_BLKSZ(host->sdma_boundary, 512),
> +  SDHCI_BLOCK_SIZE);
> +
> + if (cqcfg & CQHCI_ENABLE)
> + cqhci_writel(cq_host, cqcfg, CQHCI_CFG);
> +
> + /* Set maximum timeout */
> + sdhci_writeb(host, 0xE, SDHCI_TIMEOUT_CONTROL);
> +
> + host->ier = host->cqe_ier;
> +
> + sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
> + sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
> +
> + host->cqe_on = true;
> +
> + pr_debug("%s: sdhci: CQE on, IRQ mask %#x, IRQ status %#x\n",
> +  mmc_hostname(mmc), host->ier,
> +  sdhci_readl(host, SDHCI_INT_STATUS));
> +
> + mmiowb();
> + spin_unlock_irqrestore(&host->lock, flags);

Most of this is the same as sdhci_cqe_enable().  Did you consider
rearranging things and calling sdhci_cqe_enable()?

> +}
> +
> +static void sdhci_tegra_dumpregs(struct mmc_host *mmc)
> +{
> + sdhci_dumpregs(mmc_priv(mmc));
> +}
> +
> +static u32 sdhci_tegra_cqhci_irq(struct sdhci_host *host, u32 intmask)
> +{
> + int cmd_error = 0;
> + int data_error = 0;
> +
> + if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
> +   

4.19.5 and later has tons of false messages "BUG: non-zero pgtables_bytes on freeing mm: -16384"

[Christian Borntraeger]

Martin,

Right now you get a message 
"BUG: non-zero pgtables_bytes on freeing mm: -16384"
for EVERY process that exits in 4.19.5 and later.

bisect points to 
commit 4136161d676a93fc8df6bdb80d720c15522d6c24
Author: Martin Schwidefsky 
Date:   Mon Oct 15 11:09:16 2018 +0200

s390/mm: fix mis-accounting of pgtable_bytes

[ Upstream commit e12e4044aede97974feb7f0ed726a5179a32 ]

Turns out that this patch requires several dependencies so the autoselection of 
this
patch was missing that. 

Can we either revert this patch or add the dependencies?

Christian

Re: [PATCH] sched: fix infinity loop in update_blocked_averages

[Vincent Guittot]

Hi Xie,

On Thu, 27 Dec 2018 at 03:57, Xie XiuQi  wrote:
>
> Zhepeng Xie report a bug, there is a infinity loop in
> update_blocked_averages().
>
> PID: 14233  TASK: 800b2de08fc0  CPU: 1   COMMAND: "docker"
>  #0 [2213b9d0] update_blocked_averages at 0811e4a8
>  #1 [2213ba60] pick_next_task_fair at 0812a3b4
>  #2 [2213baf0] __schedule at 08deaa88
>  #3 [2213bb70] schedule at 08deb1b8
>  #4 [2213bb80] futex_wait_queue_me at 08180754
>  #5 [2213bbd0] futex_wait at 0818192c
>  #6 [2213bd00] do_futex at 08183ee4
>  #7 [2213bde0] __arm64_sys_futex at 08184398
>  #8 [2213be60] el0_svc_common at 080979ac
>  #9 [2213bea0] el0_svc_handler at 08097a6c
>  #10 [2213bff0] el0_svc at 08084044
>
> rq->tmp_alone_branch introduced in 4.10, used to point to
> the new beg of the list. If this cfs_rq is deleted somewhere
> else, then the tmp_alone_branch will be illegal and cause
> a list_add corruption.

shouldn't all the sequence  be protected by rq_lock ?


>
> (When enabled DEBUG_LIST, we fould this list_add corruption)
>
> [ 2546.741103] list_add corruption. next->prev should be prev
> (800b4d61ad40), but was 800ba434fa38. (next=800b6a95e740).
> [ 2546.741130] [ cut here ]
> [ 2546.741132] kernel BUG at lib/list_debug.c:25!
> [ 2546.741136] Internal error: Oops - BUG: 0 [#1] SMP
> [ 2546.742870] CPU: 1 PID: 29428 Comm: docker-runc Kdump: loaded Tainted: G E 
>  4.19.5-1.aarch64 #1
> [ 2546.745415] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
> [ 2546.747402] pstate: 4085 (nZcv daIf -PAN -UAO)
> [ 2546.749015] pc : __list_add_valid+0x50/0x90
> [ 2546.750485] lr : __list_add_valid+0x50/0x90
> [ 2546.751975] sp : 1b5eb910
> [ 2546.753286] x29: 1b5eb910 x28: 800abacf
> [ 2546.754976] x27: 1b5ebbb0 x26: 0957
> [ 2546.756665] x25: 0960d000 x24: 0250f41ca8f8
> [ 2546.758366] x23: 800b6a95e740 x22: 800b4d61ad40
> [ 2546.760066] x21: 800b4d61ad40 x20: 800ba434f080
> [ 2546.761742] x19: 800b4d61ac00 x18: 
> [ 2546.763425] x17:  x16: 
> [ 2546.765089] x15: 09570748 x14: 662073617720
> [ 2546.766755] x13: 747562202c293034 x12: 6461313664346230
> [ 2546.768429] x11: 30382820 x10: 
> [ 2546.770124] x9 : 0001 x8 : 09f34a0f
> [ 2546.771831] x7 :  x6 : 250d
> [ 2546.773525] x5 :  x4 : 
> [ 2546.775227] x3 :  x2 : 70ef7f624013ca00
> [ 2546.776929] x1 :  x0 : 0075
> [ 2546.778623] Process docker-runc (pid: 29428, stack limit = 
> 0x293494a2)
> [ 2546.780742] Call trace:
> [ 2546.781955]  __list_add_valid+0x50/0x90
> [ 2546.783469]  enqueue_entity+0x4a0/0x6e8
> [ 2546.784957]  enqueue_task_fair+0xac/0x610
> [ 2546.786502]  sched_move_task+0x134/0x178
> [ 2546.787993]  cpu_cgroup_attach+0x40/0x78
> [ 2546.789540]  cgroup_migrate_execute+0x378/0x3a8
> [ 2546.791169]  cgroup_migrate+0x6c/0x90
> [ 2546.792663]  cgroup_attach_task+0x148/0x238
> [ 2546.794211]  __cgroup1_procs_write.isra.2+0xf8/0x160
> [ 2546.795935]  cgroup1_procs_write+0x38/0x48
> [ 2546.797492]  cgroup_file_write+0xa0/0x170
> [ 2546.799010]  kernfs_fop_write+0x114/0x1e0
> [ 2546.800558]  __vfs_write+0x60/0x190
> [ 2546.801977]  vfs_write+0xac/0x1c0
> [ 2546.803341]  ksys_write+0x6c/0xd8
> [ 2546.804674]  __arm64_sys_write+0x24/0x30
> [ 2546.806146]  el0_svc_common+0x78/0x100
> [ 2546.807584]  el0_svc_handler+0x38/0x88
> [ 2546.809017]  el0_svc+0x8/0xc
>

Have you got more details about the sequence that generates this bug ?
Is it easily reproducible ?

> In this patch, we move rq->tmp_alone_branch point to its prev before delete it
> from list.
>
> Reported-by: Zhipeng Xie 
> Cc: Bin Li 
> Cc: [4.10+]
> Fixes: 9c2791f936ef (sched/fair: Fix hierarchical order in 
> rq->leaf_cfs_rq_list)

If it only happens in update_blocked_averages(), the del leaf has been added by:
a9e7f6544b9c (sched/fair: Fix O(nr_cgroups) in load balance path)

> Signed-off-by: Xie XiuQi 
> Tested-by: Zhipeng Xie 
> ---
>  kernel/sched/fair.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index ac855b2..7a72702 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -347,6 +347,11 @@ static inline void list_add_leaf_cfs_rq(struct cfs_rq 
> *cfs_rq)
>  static inline void list_del_leaf_cfs_rq(struct cfs_rq *cfs_rq)
>  {
> if (cfs_rq->on_list) {
> +   struct rq *rq = rq_of(cfs_rq);
> +
> +   if (rq->tmp_alone_branch == &cfs_rq->leaf_cfs_rq_list)
> +   rq->tmp_alone_branch = cfs_rq->leaf_cfs_rq_list.prev;
> +
> list_del_rcu(&cfs_rq->leaf_cfs_rq_l

[GIT PULL] GPIO bulk changes for the v4.21 kernel

[Linus Walleij]

Hi Linus,

this is the main part of the v4.21 GPIO changes.

Details are in the signed tag.

Some interesting changes have already trickled in
through the Regulator and MMC/SD trees but get
mentioned in the signed tag nevertheless.

Please pull it in!

Yours,
Linus Walleij

The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:

  Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/gpio-v4.21-1

for you to fetch changes up to a7c23f8d154f7919c5fcfceea6e0897be2d5ab71:

  gpio: sama5d2-piobu: Depend on OF_GPIO (2018-12-22 11:08:06 +0100)


This is the bulk of GPIO changes for the v4.21 kernel series:

Core changes:

- Some core changes are already in outside of this pull
  request as they came through the regulator tree, most
  notably devm_gpiod_unhinge() that removes devres refcount
  management from a GPIO descriptor. This is needed in
  subsystems such as regulators where the regulator core
  need to take over the reference counting and lifecycle
  management for a GPIO descriptor.

- We dropped devm_gpiochip_remove() and devm_gpio_chip_match()
  as nothing needs it. We can bring it back if need be.

- Add a global TODO so people see where we are going. This
  helps setting the direction now that we are two GPIO
  maintainers.

- Handle the MMC CD/WP properties in the device tree core.
  (The bulk of patches activating this code is already
  merged through the MMC/SD tree.)

- Augment gpiochip_request_own_desc() to pass a flag so
  we as gpiochips can request lines as active low or open
  drain etc even from ourselves.

New drivers:

- New driver for Cadence GPIO blocks.

- New driver for Atmel SAMA5D2 PIOBU GPIO lines.

Driver improvements:

- A major refactoring of the PCA953x driver - this driver has
  been around for ages, and is now modernized to reduce code
  duplication that has stacked up and is using regmap to read
  write and cache registers.

- Intel drivers are now maintained in a separate tree and
  start with a round of cleanups and unifications.


A.s. Dong (2):
  dt-bindings: gpio: vf610: add optional clocks property
  gpio: vf610: add optional clock support

andrei.stefane...@microchip.com (2):
  dt-bindings: arm: atmel: describe SECUMOD usage as a GPIO controller
  gpio: add driver for SAMA5D2 PIOBU pins

Andy Shevchenko (27):
  MAINTAINERS: Do maintain Intel GPIO drivers via separate tree
  gpio: pch: Convert to use managed functions pcim_* and devm_*
  gpio: sodaville: Convert to use managed functions pcim_* and devm_*
  gpio: pch: Convert to dev_pm_ops
  gpio: lynxpoint: Use for_each_set_bit() in IRQ handler
  gpio: pch: Use for_each_set_bit() in IRQ handler
  gpio: sodaville: Use for_each_set_bit() in IRQ handler
  gpio: ich: Simplify error handling in ichx_write_bit()
  gpio: ich: Switch to use struct device instead of platform_device
  gpio: ich: Convert pr_ to dev_
  gpio: ich: Join string literals back
  gpio: pch: Remove redundant __func__ from debug print
  gpio: pch: Remove duplicate assignments
  gpio: intel-mid: Remove linux/module.h and sort headers
  gpio: lynxpoint: Remove linux/init.h and sort headers
  gpio: merrifield: Remove linux/init.h
  gpio: sch: Remove linux/init.h and sort headers
  gpio: ich: Sort headers alphabetically
  gpio: pch: Sort headers alphabetically
  gpio: sodaville: Sort headers alphabetically
  gpio: ich: Convert to use SPDX identifier
  gpio: intel-mid: Convert to use SPDX identifier
  gpio: lynxpoint: Convert to use SPDX identifier
  gpio: merrifield: Convert to use SPDX identifier
  gpio: pch: Convert to use SPDX identifier
  gpio: sch: Convert to use SPDX identifier
  gpio: sodaville: Convert to use SPDX identifier

Anson Huang (1):
  gpio: mxc: move gpio noirq suspend/resume to syscore phase

Bartosz Golaszewski (1):
  MAINTAINERS: remove a duplicate entry for gpio-mockup

Brajeswar Ghosh (1):
  drivers/gpio/gpio-grgpio.c: Remove duplicate header

Brandon Maier (1):
  gpio: zynq: Report gpio direction at boot

Colin Ian King (2):
  gpio: sch311x: clean an indentation issue, remove extraneous space
  gpiolib-acpi: remove unused variable 'err', cleans up build warning

Fabrizio Castro (1):
  dt-bindings: gpio: rcar: Add r8a774c0 (RZ/G2E) support

Jan Kotas (2):
  dt-bindings: gpio: Add bindings for Cadence GPIO
  gpio: Add Cadence GPIO driver

Johan Hovold (1):
  gpio: drop broken to_gpio_irq_chip() helper

Krzysztof Kozlowski (1):
  gpiolib: Fix return value of gpio_to_desc() stub if !GPIOLIB

Kuninori Morimoto (1):
  gpio: rcar: convert to SPDX identifiers

Laurent Pinchart (1):
  gpio: drop devm_gpio_chip_match()

答复: [PATCH] gpu: drm: fix an improper check of amdgpu_bo_create_kernel

[Qu, Jim]

Comments in line.

Thanks
JimQu

发件人: amd-gfx  代表 Kangjie Lu 

发送时间: 2018年12月26日 14:23
收件人: k...@umn.edu
抄送: Zhou, David(ChunMing); David Airlie; Xu, Feifei; Francis, David; 
linux-kernel@vger.kernel.org; amd-...@lists.freedesktop.org; Huang, Ray; 
dri-de...@lists.freedesktop.org; Daniel Vetter; pakki...@umn.edu; Deucher, 
Alexander; Gao, Likun; Zhu, Rex; Koenig, Christian; Zhang, Hawking
主题: [PATCH] gpu: drm: fix an improper check of amdgpu_bo_create_kernel

adev->firmware.fw_buf being not NULL may not indicate kernel buffer is
created successful. A better way is to check the status (return value)
of it. The fix does so.

Signed-off-by: Kangjie Lu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 7b33867036e7..ba3c1cfb2c35 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -422,13 +422,19 @@ static int amdgpu_ucode_patch_jt(struct 
amdgpu_firmware_info *ucode,

 int amdgpu_ucode_create_bo(struct amdgpu_device *adev)
 {
+   int ret;
+
if (adev->firmware.load_type != AMDGPU_FW_LOAD_DIRECT) {
-   amdgpu_bo_create_kernel(adev, adev->firmware.fw_size, PAGE_SIZE,
-   amdgpu_sriov_vf(adev) ? AMDGPU_GEM_DOMAIN_VRAM : 
AMDGPU_GEM_DOMAIN_GTT,
-   &adev->firmware.fw_buf,
-   &adev->firmware.fw_buf_mc,
-   &adev->firmware.fw_buf_ptr);
-   if (!adev->firmware.fw_buf) {
+   ret =
+   amdgpu_bo_create_kernel(adev,
+ adev->firmware.fw_size,
+ PAGE_SIZE,
+ amdgpu_sriov_vf(adev) ? AMDGPU_GEM_DOMAIN_VRAM :
+   AMDGPU_GEM_DOMAIN_GTT,
+ &adev->firmware.fw_buf,
+ &adev->firmware.fw_buf_mc,
+   &adev->firmware.fw_buf_ptr);
+   if (ret) {

JimQu: Look into amdgpu_bo_create_kernel(), new bo will be created only if 
*bo_ptr = NULL, So if you encounter the issue the adev->firmware.fw_buf != NULL 
but new bo is not created, the only problem I can see are:

1. there is bug in amdgpu_bo_create_kernel()
2. adev->firmware.fw_buf != NULL before it is transferred into 
amdgpu_bo_create_kernel().

Could you commit what is environment you encounter the issue?

Thanks
JimQu 
dev_err(adev->dev, "failed to create kernel buffer for 
firmware.fw_buf\n");
return -ENOMEM;
} else if (amdgpu_sriov_vf(adev)) {
--
2.17.2 (Apple Git-113)

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 4.19.5 and later has tons of false messages "BUG: non-zero pgtables_bytes on freeing mm: -16384"

[Christian Borntraeger]

On 27.12.2018 10:13, Christian Borntraeger wrote:
> Martin,
> 
> Right now you get a message 
> "BUG: non-zero pgtables_bytes on freeing mm: -16384"
> for EVERY process that exits in 4.19.5 and later.
> 
> bisect points to 
> commit 4136161d676a93fc8df6bdb80d720c15522d6c24
> Author: Martin Schwidefsky 
> Date:   Mon Oct 15 11:09:16 2018 +0200
> 
> s390/mm: fix mis-accounting of pgtable_bytes
> 
> [ Upstream commit e12e4044aede97974feb7f0ed726a5179a32 ]
> 
> Turns out that this patch requires several dependencies so the autoselection 
> of this
> patch was missing that. 
> 
> Can we either revert this patch or add the dependencies?
> 
> Christian
> 

It seems that adding 

commit 6d212db11947ae5464e4717536ed9faf61c01e86 ("mm: add mm_pxd_folded checks 
to pgtable_bytes accounting functions") 
fixes the issue. 

Martin, do we need more?

Christian

Re: [PATCH net V2 4/4] vhost: log dirty page correctly

[Jason Wang]

On 2018/12/26 下午9:46, Michael S. Tsirkin wrote:

On Wed, Dec 26, 2018 at 01:43:26PM +0800, Jason Wang wrote:

On 2018/12/26 上午12:25, Michael S. Tsirkin wrote:

On Tue, Dec 25, 2018 at 05:43:25PM +0800, Jason Wang wrote:

On 2018/12/25 上午1:41, Michael S. Tsirkin wrote:

On Mon, Dec 24, 2018 at 11:43:31AM +0800, Jason Wang wrote:

On 2018/12/14 下午9:20, Michael S. Tsirkin wrote:

On Fri, Dec 14, 2018 at 10:43:03AM +0800, Jason Wang wrote:

On 2018/12/13 下午10:31, Michael S. Tsirkin wrote:

Just to make sure I understand this. It looks to me we should:

- allow passing GIOVA->GPA through UAPI

- cache GIOVA->GPA somewhere but still use GIOVA->HVA in device IOTLB for
performance

Is this what you suggest?

Thanks

Not really. We already have GPA->HVA, so I suggested a flag to pass
GIOVA->GPA in the IOTLB.

This has advantages for security since a single table needs
then to be validated to ensure guest does not corrupt
QEMU memory.


I wonder how much we can gain through this. Currently, qemu IOMMU gives
GIOVA->GPA mapping, and qemu vhost code will translate GPA to HVA then pass
GIOVA->HVA to vhost. It looks no difference to me.

Thanks

The difference is in security not in performance.  Getting a bad HVA
corrupts QEMU memory and it might be guest controlled. Very risky.

How can this be controlled by guest? HVA was generated from qemu ram blocks
which is totally under the control of qemu memory core instead of guest.


Thanks

It is ultimately under guest influence as guest supplies IOVA->GPA
translations.  qemu translates GPA->HVA and gives the translated result
to the kernel.  If it's not buggy and kernel isn't buggy it's all
fine.

If qemu provides buggy GPA->HVA, we can't workaround this. And I don't get
the point why we even want to try this. Buggy qemu code can crash itself in
many ways.



But that's the approach that was proven not to work in the 20th century.
In the 21st century we are trying defence in depth approach.

My point is that a single code path that is responsible for
the HVA translations is better than two.


So the difference whether or not use memory table information:

Current:

1) SET_MEM_TABLE: GPA->HVA

2) Qemu GIOVA->GPA

3) Qemu GPA->HVA

4) IOTLB_UPDATE: GIOVA->HVA

If I understand correctly you want to drop step 3 consider it might be buggy
which is just 19 lines of code in qemu (vhost_memory_region_lookup()). This
will ends up:

1) Do GPA->HVA translation in IOTLB_UPDATE path (I believe we won't want to
do it during device IOTLB lookup).

2) Extra bits to enable this capability.

So this looks need more codes in kernel than what qemu did in userspace.  Is
this really worthwhile?

Thanks

So there are several points I would like to make

1. At the moment without an iommu it is possible to
 change GPA-HVA mappings and everything keeps working
 because a change in memory tables flushes the rings.


Interesting, I don't know this before. But when can this happen?


It doesn't happen with existing qemu. But it seems like a valid
thing to do to remap memory at a different address.



Ok.



 However I don't see the iotlb cache being invalidated
 on that path - did I miss it? If it is not there it's
 a related minor bug.


It might have a bug. But a question is consider the case without IOMMU. We
only update mem table (SET_MEM_TABLE), but not vring address. This looks
like a bug as well?

I think that without an iommu it can only work without races if backend is
stopped or if the vring isn't in guest memory with ring aliasing).



Right.





2. qemu already has a GPA. Discarding it and re-calculating
 when logging is on just seems wrong.
 However if you would like to *also* keep the HVA in the iotlb
 to avoid doing extra translations, that sounds like a
 reasonable optimization.


Yes, traverse GPA->HVA mapping seems unnecessary.



3. it also means that the hva->gpa translation only runs
 when logging is enabled. That is a rarely excercised
 path so any bugs there will not be caught.


I wonder maybe some kind of unit-test may help here.



So I really would like us long term to move away from
hva->gpa translations, keep them for legacy userspace only
but I don't really mind how we do it.

How about
- a new flag to pass an iotlb with *both* a gpa and hva
- for legacy userspace, calculate the gpa on iotlb update
so the device then uses a shared code path

what do you think?



I don't object this idea so I can try, just want to figure out why it was a
must.

Thanks

Not a must but I think it's a good interface extension.



Ok. let me try to do this.

Thanks

Re: CPUs blocking in update_blocked_averages -- 4.19.12

[Sargun Dhillon]

>
> We're seeing an issue introduced in 4.18, and that still persists in
> 4.19.12 (we upgraded from 4.9), where update_blocked_averages is
> blocking. We're running a workload where a majority of our workloads
> are  confined by cgroups. This exhibits itself due to a softlockup on
> a CPU which is waiting on a lock that's held by
> update_blocked_averages. I don't have access to any bare metal
> hardware at the moment, and these are all systems running under KVM.
> This kernel has CONFIG_FAIR_GROUP_SCHED on.
>
> The Softlocked CPU:
> crash> bt
> PID: 29314  TASK: 99b5f0671f00  CPU: 0   COMMAND: "ag"
>  #0 [99b67b203d58] machine_kexec at 91a602f3
>  #1 [99b67b203db0] __crash_kexec at 91b49011
>  #2 [99b67b203e70] panic at 91a896d1
>  #3 [99b67b203ef8] watchdog_timer_fn at 91b816af
>  #4 [99b67b203f28] __hrtimer_run_queues at 91b26359
>  #5 [99b67b203f88] hrtimer_interrupt at 91b26de2
>  #6 [99b67b203fd8] smp_apic_timer_interrupt at 92402b06
>  #7 [99b67b203ff0] apic_timer_interrupt at 92401a9f
> ---  ---
>  #8 [a49fa1acbc08] apic_timer_interrupt at 92401a9f
> [exception RIP: smp_call_function_many+543]
> RIP: 91b3e84f  RSP: a49fa1acbcb0  RFLAGS: 0202
> RAX: 0010  RBX: 99b67b224fc0  RCX: 99b67b6286a0
> RDX: 0001  RSI: 0200  RDI: 99b67b224fc8
> RBP: 99b67b224fc8   R8: 0001   R9: 
> R10:   R11:   R12: 00025080
> R13: a49fa1acbd00  R14: 0001  R15: 0200
> ORIG_RAX: ff13  CS: 0010  SS: 0018
>  #9 [a49fa1acbcf8] flush_tlb_mm_range at 91a7853c
> #10 [a49fa1acbd90] free_pgtables at 91c4ac3b
> #11 [a49fa1acbdc8] unmap_region at 91c54439
> #12 [a49fa1acbe90] do_munmap at 91c56355
> #13 [a49fa1acbee0] vm_munmap at 91c56587
> #14 [a49fa1acbf20] __x64_sys_munmap at 91c565e2
> #15 [a49fa1acbf38] do_syscall_64 at 91a04590
> #16 [a49fa1acbf50] entry_SYSCALL_64_after_hwframe at 9240008d
> RIP: 7f43e94de747  RSP: 7f43e91d7e28  RFLAGS: 0213
> RAX: ffda  RBX: 011a6f30  RCX: 7f43e94de747
> RDX: 0001  RSI: 0ade  RDI: 7f43ea47d000
> RBP: 0005   R8: 7f43e8c0   R9: 7f43e91d7d00
> R10: 011a53b0  R11: 0213  R12: 7f43ea47d000
> R13: 0ade  R14: 7f43e91d89c0  R15: 0060
> ORIG_RAX: 000b  CS: 0033  SS: 002b
>
> This is waiting on CPU 16:
> crash> bt
> PID: 29299  TASK: 99b5dffd1f00  CPU: 16  COMMAND: "ag"
>  #0 [fe2c8e38] crash_nmi_callback at 91a54202
>  #1 [fe2c8e50] nmi_handle at 91a32ee2
>  #2 [fe2c8ea0] default_do_nmi at 91a333ea
>  #3 [fe2c8ec0] do_nmi at 91a33553
>  #4 [fe2c8ef0] end_repeat_nmi at 924014e8
> [exception RIP: native_queued_spin_lock_slowpath+33]
> RIP: 91af2dc1  RSP: a49fa1a93948  RFLAGS: 0002
> RAX: 0001  RBX: 99b67b763f40  RCX: 4f19a57a
> RDX: 0001  RSI: 0001  RDI: 99b67b763f40
> RBP: 0082   R8: 0001   R9: 
> R10: a49fa1a938f8  R11: 91aca4a7  R12: 0015
> R13: 99b67b764940  R14: a49fa1a93a60  R15: 0015
> ORIG_RAX:   CS: 0010  SS: 
> ---  ---
>  #5 [a49fa1a93948] native_queued_spin_lock_slowpath at 91af2dc1
>  #6 [a49fa1a93948] do_raw_spin_lock at 91af48dd
>  #7 [a49fa1a93958] _raw_spin_lock_irqsave at 923c1154
>  #8 [a49fa1a93978] update_blocked_averages at 91aca4a7
>  #9 [a49fa1a93a10] update_nohz_stats at 91acaa3d
> #10 [a49fa1a93a20] find_busiest_group at 91ad2137
> #11 [a49fa1a93bb8] load_balance at 91ad2be0
> #12 [a49fa1a93cf0] pick_next_task_fair at 91ad41e6
> #13 [a49fa1a93da0] mark_held_locks at 91aeebe4
> #14 [a49fa1a93de8] schedule at 923b9ec2
> #15 [a49fa1a93df8] rwsem_down_read_failed at 923be859
> #16 [a49fa1a93e80] call_rwsem_down_read_failed at 923ae944
> #17 [a49fa1a93ec8] down_read at 923bdf0b
> #18 [a49fa1a93ee0] __do_page_fault at 91a71083
> #19 [a49fa1a93f50] async_page_fault at 924010ee
> RIP: 7f43e945f786  RSP: 7ffde2b50070  RFLAGS: 00010206
> RAX: 00015f41  RBX: 7f43e97a1b20  RCX: 0111
> RDX: 011affb0  RSI: 011b00c0  RDI: 
> RBP: 0111   R8: 7f43e97a1bd8   R9: 
> R10: 7f43e97a1b78  R11: 7f43e97a1b78  R12: 7f43e97a1b78
> R

RE: [PATCH v2 5/5] usb:cdns3 Add Cadence USB3 DRD Driver

[Pawel Laszczak]

Hi,

>> > +
>> > +   if (ret)
>> > +   return ret;
>> > +
>> > +   state = readl(&cdns->otg_regs->sts);
>> > +   if (OTGSTS_OTG_NRDY(state) != 0) {
>> > +   dev_err(cdns->dev, "Cadence USB3 OTG device not ready\n");
>> > +   return -ENODEV;
>> > +   }
>> > +
>> > +   ret = cdns3_drd_update_mode(cdns);
>> > +
>>
>> Calling this function, it is timeout for waiting OTGSTS_XHCI_READY at otgsts,
>> do you know possible reasons?  After commenting out this function, my
>> xHCI function
>> works.
>>
>
>Pawel, since OTG compliance (Known as HNP/SRP)  has not been used
>widely, Linux kernel does not
>maintain it from some time ago (maybe 1-2 years). In software design,
>we do not need to consider it from
>hardware point, eg, kinds of OTG timer. For dual-role switch on the
>fly,  through /sys is enough.
>
>Through the debug, we find it needs to wait 1s after setting de-select
>the host or gadget before request
>XHCI at otg_regs->cmd, and enable fast simulate can reduce delay to
>2-3ms. Would you please help
>to check with your hardware team this behavior. With below changes, I
>can get OTGSTS_XHCI_READY at otgsts.
>
>@@ -141,6 +143,7 @@ static int cdns3_drd_switch_host(struct cdns3 *cdns, int 
>on)
>writel(OTGCMD_HOST_BUS_DROP | OTGCMD_DEV_BUS_DROP |
>   OTGCMD_DEV_POWER_OFF | OTGCMD_HOST_POWER_OFF,
>   &cdns->otg_regs->cmd);
>+   usleep_range(3000, 4000);
>}
>
>return 0;
>@@ -178,6 +181,7 @@ static int cdns3_drd_switch_gadget(struct cdns3
>*cdns, int on)
>writel(OTGCMD_HOST_BUS_DROP | OTGCMD_DEV_BUS_DROP |
>   OTGCMD_DEV_POWER_OFF | OTGCMD_HOST_POWER_OFF,
>   &cdns->otg_regs->cmd);
>+   usleep_range(3000, 4000);
>}
>
>@@ -299,6 +306,7 @@ int cdns3_drd_init(struct cdns3 *cdns)
>cdns->version  = CDNS3_CONTROLLER_V0;
>cdns->otg_v1_regs = NULL;
>cdns->otg_regs = regs;
>+   writel(0x1, &cdns->otg_v0_regs->simulate);
>dev_info(cdns->dev, "DRD version v0 (%08x)\n",
> readl(&cdns->otg_v0_regs->version));
>} else {

I have confirmation from HW team that time that driver should wait after 
de-selecting mode 
is 2-3ms for simulate mode. It's time when FSM is in DRD_H_WAIT_VBUS_FAIL. 
Driver cannot re-enable the host/device mode before this time has elapsed. 

3 ms is the maximum time. Additionally, you can confirm the current FSM state 
by reading the
host_otg_state (bit 5:3) or dev_otg_state (2:0)  from OTGSTATE register. 

If bit 0 in simulate register is cleared the time is exactly 1s.

Cheers,
Pawel

Re: [PATCH] backlight: (adp8870) fix a missing check for adp8870_write

[Sam Ravnborg]

Hi Kangjie

> adp8870_write() may fail. This fix checks if adp8870_write fails, and if
> so, returns its error code.
> 
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/video/backlight/adp8870_bl.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/backlight/adp8870_bl.c 
> b/drivers/video/backlight/adp8870_bl.c
> index 8d50e0299578..79901fb4fcd1 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -811,9 +811,14 @@ static ssize_t 
> adp8870_bl_ambient_light_zone_store(struct device *dev,
>   if (!ret) {
>   reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
>   reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> - adp8870_write(data->client, ADP8870_CFGR, reg_val);
> - }
> - mutex_unlock(&data->lock);
> + ret = adp8870_write(data->client,
> + ADP8870_CFGR, reg_val);
> + if (ret) {
> + mutex_unlock(&data->lock);
> + return ret;
> + }
> + }   else
> + mutex_unlock(&data->lock);
>   }

Something looks wrong with the indent.
If you have braces around first part of if () then use
barces also after else. Then it is easier to follow the code.
In this case please consider another approach where you
have only a single mutex_unlock() both in the good and
in the error case.

Sam

Re: [PATCH] pinctrl: freescale: Break dependency on SOC_IMX8MQ for i.MX8MQ

[Linus Walleij]

On Sun, Dec 23, 2018 at 8:08 AM Abel Vesa  wrote:

> The CONFIG_SOC_IMX8MQ will go away, so the dependency can be based on
> ARCH_MXC && ARM64.
>
> Signed-off-by: Abel Vesa 

Patch applied with Dong's and Fabio's ACKs.

Yours,
Linus Walleij

Re: [PATCH net-next 3/3] vhost: access vq metadata through kernel virtual address

[Jason Wang]

On 2018/12/26 下午11:02, Michael S. Tsirkin wrote:

On Wed, Dec 26, 2018 at 11:57:32AM +0800, Jason Wang wrote:

On 2018/12/25 下午8:50, Michael S. Tsirkin wrote:

On Tue, Dec 25, 2018 at 06:05:25PM +0800, Jason Wang wrote:

On 2018/12/25 上午2:10, Michael S. Tsirkin wrote:

On Mon, Dec 24, 2018 at 03:53:16PM +0800, Jason Wang wrote:

On 2018/12/14 下午8:36, Michael S. Tsirkin wrote:

On Fri, Dec 14, 2018 at 11:57:35AM +0800, Jason Wang wrote:

On 2018/12/13 下午11:44, Michael S. Tsirkin wrote:

On Thu, Dec 13, 2018 at 06:10:22PM +0800, Jason Wang wrote:

It was noticed that the copy_user() friends that was used to access
virtqueue metdata tends to be very expensive for dataplane
implementation like vhost since it involves lots of software check,
speculation barrier, hardware feature toggling (e.g SMAP). The
extra cost will be more obvious when transferring small packets.

This patch tries to eliminate those overhead by pin vq metadata pages
and access them through vmap(). During SET_VRING_ADDR, we will setup
those mappings and memory accessors are modified to use pointers to
access the metadata directly.

Note, this was only done when device IOTLB is not enabled. We could
use similar method to optimize it in the future.

Tests shows about ~24% improvement on TX PPS when using virtio-user +
vhost_net + xdp1 on TAP (CONFIG_HARDENED_USERCOPY is not enabled):

Before: ~5.0Mpps
After:  ~6.1Mpps

Signed-off-by: Jason Wang
---
  drivers/vhost/vhost.c | 178 ++
  drivers/vhost/vhost.h |  11 +++
  2 files changed, 189 insertions(+)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index bafe39d2e637..1bd24203afb6 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -443,6 +443,9 @@ void vhost_dev_init(struct vhost_dev *dev,
vq->indirect = NULL;
vq->heads = NULL;
vq->dev = dev;
+   memset(&vq->avail_ring, 0, sizeof(vq->avail_ring));
+   memset(&vq->used_ring, 0, sizeof(vq->used_ring));
+   memset(&vq->desc_ring, 0, sizeof(vq->desc_ring));
mutex_init(&vq->mutex);
vhost_vq_reset(dev, vq);
if (vq->handle_kick)
@@ -614,6 +617,102 @@ static void vhost_clear_msg(struct vhost_dev *dev)
spin_unlock(&dev->iotlb_lock);
  }
+static int vhost_init_vmap(struct vhost_vmap *map, unsigned long uaddr,
+  size_t size, int write)
+{
+   struct page **pages;
+   int npages = DIV_ROUND_UP(size, PAGE_SIZE);
+   int npinned;
+   void *vaddr;
+
+   pages = kmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
+   if (!pages)
+   return -ENOMEM;
+
+   npinned = get_user_pages_fast(uaddr, npages, write, pages);
+   if (npinned != npages)
+   goto err;
+

As I said I have doubts about the whole approach, but this
implementation in particular isn't a good idea
as it keeps the page around forever.

The pages wil be released during set features.



So no THP, no NUMA rebalancing,

For THP, we will probably miss 2 or 4 pages, but does this really matter
consider the gain we have?

We as in vhost? networking isn't the only thing guest does.
We don't even know if this guest does a lot of networking.
You don't
know what else is in this huge page. Can be something very important
that guest touches all the time.

Well, the probability should be very small consider we usually give several
gigabytes to guest. The rest of the pages that doesn't sit in the same
hugepage with metadata can still be merged by THP.  Anyway, I can test the
differences.

Thanks!


For NUMA rebalancing, I'm even not quite sure if
it can helps for the case of IPC (vhost). It looks to me the worst case it
may cause page to be thrash between nodes if vhost and userspace are running
in two nodes.

So again it's a gain for vhost but has a completely unpredictable effect on
other functionality of the guest.

That's what bothers me with this approach.

So:

- The rest of the pages could still be balanced to other nodes, no?

- try to balance metadata pages (belongs to co-operate processes) itself is
still questionable

I am not sure why. It should be easy enough to force the VCPU and vhost
to move (e.g. start them pinned to 1 cpu, then pin them to another one).
Clearly sometimes this would be necessary for load balancing reasons.


Yes, but it looks to me the part of motivation of auto NUMA is to avoid
manual pinning.

... of memory. Yes.



With autonuma after a while (could take seconds but it will happen) the
memory will migrate.


Yes. As you mentioned during the discuss, I wonder we could do it similarly
through mmu notifier like APIC access page in commit c24ae0dcd3e ("kvm: x86:
Unpin and remove kvm_arch->apic_access_page")

That would be a possible approach.



Yes, this looks possible, and the conversion seems not hard. Let me have 
a try with this.



[...]



I don't see how a kthread 

Re: [PATCH] rtc: fix a missing check of clk_prepare

[Linus Walleij]

On Wed, Dec 26, 2018 at 3:44 AM Kangjie Lu  wrote:

> clk_prepare() could fail, so let's check its status and if it fails
> return its error code upstream.
>
> Signed-off-by: Kangjie Lu 

Acked-by: Linus Walleij 

Yours,
Linus Walleij

Re: [PATCH RFC 1/2] virtio-net: bql support

[Jason Wang]

On 2018/12/26 下午11:15, Michael S. Tsirkin wrote:

On Thu, Dec 06, 2018 at 04:17:36PM +0800, Jason Wang wrote:

On 2018/12/6 上午6:54, Michael S. Tsirkin wrote:

When use_napi is set, let's enable BQLs.  Note: some of the issues are
similar to wifi.  It's worth considering whether something similar to
commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift") might be
benefitial.


I've played a similar patch several days before. The tricky part is the mode
switching between napi and no napi. We should make sure when the packet is
sent and trakced by BQL,  it should be consumed by BQL as well. I did it by
tracking it through skb->cb.  And deal with the freeze by reset the BQL
status. Patch attached.

But when testing with vhost-net, I don't very a stable performance, it was
probably because we batch the used ring updating so tx interrupt may come
randomly. We probably need to implement time bounded coalescing mechanism
which could be configured from userspace.

Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR
regression on machine without APICv, (haven't found time to test APICv
machine). But consider it was for correctness, I think it's acceptable? Then
we can do optimization on top?


Thanks

I don't see how it's for correctness to be frank.



Socket accounting is wrong in the case. This should be a bug in fact.



What if we just do the bulk free? Does that fix the regression?



I can test it.






Signed-off-by: Michael S. Tsirkin 
---
   drivers/net/virtio_net.c | 27 +++
   1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cecfd77c9f3c..b657bde6b94b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1325,7 +1325,8 @@ static int virtnet_receive(struct receive_queue *rq, int 
budget,
return stats.packets;
   }
-static void free_old_xmit_skbs(struct send_queue *sq)
+static void free_old_xmit_skbs(struct send_queue *sq, struct netdev_queue *txq,
+  bool use_napi)
   {
struct sk_buff *skb;
unsigned int len;
@@ -1347,6 +1348,9 @@ static void free_old_xmit_skbs(struct send_queue *sq)
if (!packets)
return;
+   if (use_napi)
+   netdev_tx_completed_queue(txq, packets, bytes);
+
u64_stats_update_begin(&sq->stats.syncp);
sq->stats.bytes += bytes;
sq->stats.packets += packets;
@@ -1364,7 +1368,7 @@ static void virtnet_poll_cleantx(struct receive_queue *rq)
return;
if (__netif_tx_trylock(txq)) {
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, true);
__netif_tx_unlock(txq);
}
@@ -1440,7 +1444,7 @@ static int virtnet_poll_tx(struct napi_struct *napi, int 
budget)
struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
__netif_tx_lock(txq, raw_smp_processor_id());
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, true);
__netif_tx_unlock(txq);
virtqueue_napi_complete(napi, sq->vq, 0);
@@ -1505,13 +1509,15 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, 
struct net_device *dev)
struct send_queue *sq = &vi->sq[qnum];
int err;
struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
-   bool kick = !skb->xmit_more;
+   bool more = skb->xmit_more;
bool use_napi = sq->napi.weight;
+   unsigned int bytes = skb->len;
+   bool kick;
/* Free up any pending old buffers before queueing new ones. */
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, use_napi);
-   if (use_napi && kick)
+   if (use_napi && !more)
virtqueue_enable_cb_delayed(sq->vq);
/* timestamp packet in software */
@@ -1552,7 +1558,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct 
net_device *dev)
if (!use_napi &&
unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
/* More just got used, free them then recheck. */
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, false);
if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
netif_start_subqueue(dev, qnum);
virtqueue_disable_cb(sq->vq);
@@ -1560,7 +1566,12 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, 
struct net_device *dev)
}
}
-   if (kick || netif_xmit_stopped(txq)) {
+   if (use_napi)
+   kick = __netdev_tx_sent_queue(txq, bytes, more);
+   else
+   kick = !more || netif_xmit_stopped(txq);
+
+   if (kick) {
if (virtqueue_kick_prepare(sq->vq) && virtqueue_notify(sq->vq)) 
{
u64_stats_update_begin(&sq->stats.syncp);
sq->stats.kicks++;

Re: CPUs blocking in update_blocked_averages -- 4.19.12

[Vincent Guittot]

Hi Sargun,

On Thu, 27 Dec 2018 at 10:36, Sargun Dhillon  wrote:
>
> >
> > We're seeing an issue introduced in 4.18, and that still persists in
> > 4.19.12 (we upgraded from 4.9), where update_blocked_averages is
> > blocking. We're running a workload where a majority of our workloads
> > are  confined by cgroups. This exhibits itself due to a softlockup on
> > a CPU which is waiting on a lock that's held by
> > update_blocked_averages. I don't have access to any bare metal
> > hardware at the moment, and these are all systems running under KVM.
> > This kernel has CONFIG_FAIR_GROUP_SCHED on.

Your report looks similar to Xie ones:
https://lkml.org/lkml/2018/12/26/541

> >
> > The Softlocked CPU:
> > crash> bt
> > PID: 29314  TASK: 99b5f0671f00  CPU: 0   COMMAND: "ag"
> >  #0 [99b67b203d58] machine_kexec at 91a602f3
> >  #1 [99b67b203db0] __crash_kexec at 91b49011
> >  #2 [99b67b203e70] panic at 91a896d1
> >  #3 [99b67b203ef8] watchdog_timer_fn at 91b816af
> >  #4 [99b67b203f28] __hrtimer_run_queues at 91b26359
> >  #5 [99b67b203f88] hrtimer_interrupt at 91b26de2
> >  #6 [99b67b203fd8] smp_apic_timer_interrupt at 92402b06
> >  #7 [99b67b203ff0] apic_timer_interrupt at 92401a9f
> > ---  ---
> >  #8 [a49fa1acbc08] apic_timer_interrupt at 92401a9f
> > [exception RIP: smp_call_function_many+543]
> > RIP: 91b3e84f  RSP: a49fa1acbcb0  RFLAGS: 0202
> > RAX: 0010  RBX: 99b67b224fc0  RCX: 99b67b6286a0
> > RDX: 0001  RSI: 0200  RDI: 99b67b224fc8
> > RBP: 99b67b224fc8   R8: 0001   R9: 
> > R10:   R11:   R12: 00025080
> > R13: a49fa1acbd00  R14: 0001  R15: 0200
> > ORIG_RAX: ff13  CS: 0010  SS: 0018
> >  #9 [a49fa1acbcf8] flush_tlb_mm_range at 91a7853c
> > #10 [a49fa1acbd90] free_pgtables at 91c4ac3b
> > #11 [a49fa1acbdc8] unmap_region at 91c54439
> > #12 [a49fa1acbe90] do_munmap at 91c56355
> > #13 [a49fa1acbee0] vm_munmap at 91c56587
> > #14 [a49fa1acbf20] __x64_sys_munmap at 91c565e2
> > #15 [a49fa1acbf38] do_syscall_64 at 91a04590
> > #16 [a49fa1acbf50] entry_SYSCALL_64_after_hwframe at 9240008d
> > RIP: 7f43e94de747  RSP: 7f43e91d7e28  RFLAGS: 0213
> > RAX: ffda  RBX: 011a6f30  RCX: 7f43e94de747
> > RDX: 0001  RSI: 0ade  RDI: 7f43ea47d000
> > RBP: 0005   R8: 7f43e8c0   R9: 7f43e91d7d00
> > R10: 011a53b0  R11: 0213  R12: 7f43ea47d000
> > R13: 0ade  R14: 7f43e91d89c0  R15: 0060
> > ORIG_RAX: 000b  CS: 0033  SS: 002b
> >
> > This is waiting on CPU 16:
> > crash> bt
> > PID: 29299  TASK: 99b5dffd1f00  CPU: 16  COMMAND: "ag"
> >  #0 [fe2c8e38] crash_nmi_callback at 91a54202
> >  #1 [fe2c8e50] nmi_handle at 91a32ee2
> >  #2 [fe2c8ea0] default_do_nmi at 91a333ea
> >  #3 [fe2c8ec0] do_nmi at 91a33553
> >  #4 [fe2c8ef0] end_repeat_nmi at 924014e8
> > [exception RIP: native_queued_spin_lock_slowpath+33]
> > RIP: 91af2dc1  RSP: a49fa1a93948  RFLAGS: 0002
> > RAX: 0001  RBX: 99b67b763f40  RCX: 4f19a57a
> > RDX: 0001  RSI: 0001  RDI: 99b67b763f40
> > RBP: 0082   R8: 0001   R9: 
> > R10: a49fa1a938f8  R11: 91aca4a7  R12: 0015
> > R13: 99b67b764940  R14: a49fa1a93a60  R15: 0015
> > ORIG_RAX:   CS: 0010  SS: 
> > ---  ---
> >  #5 [a49fa1a93948] native_queued_spin_lock_slowpath at 91af2dc1
> >  #6 [a49fa1a93948] do_raw_spin_lock at 91af48dd
> >  #7 [a49fa1a93958] _raw_spin_lock_irqsave at 923c1154
> >  #8 [a49fa1a93978] update_blocked_averages at 91aca4a7
> >  #9 [a49fa1a93a10] update_nohz_stats at 91acaa3d
> > #10 [a49fa1a93a20] find_busiest_group at 91ad2137
> > #11 [a49fa1a93bb8] load_balance at 91ad2be0
> > #12 [a49fa1a93cf0] pick_next_task_fair at 91ad41e6
> > #13 [a49fa1a93da0] mark_held_locks at 91aeebe4
> > #14 [a49fa1a93de8] schedule at 923b9ec2
> > #15 [a49fa1a93df8] rwsem_down_read_failed at 923be859
> > #16 [a49fa1a93e80] call_rwsem_down_read_failed at 923ae944
> > #17 [a49fa1a93ec8] down_read at 923bdf0b
> > #18 [a49fa1a93ee0] __do_page_fault at 91a71083
> > #19 [a49fa1a93f50] async_page_fault at 924010ee
> > RIP: 7f43e945f786  RSP: 7ffde2b50070  RFLAGS: 0001020

Re: [PATCH RFC 1/2] virtio-net: bql support

[Jason Wang]

On 2018/12/26 下午11:19, Michael S. Tsirkin wrote:

On Thu, Dec 06, 2018 at 04:17:36PM +0800, Jason Wang wrote:

On 2018/12/6 上午6:54, Michael S. Tsirkin wrote:

When use_napi is set, let's enable BQLs.  Note: some of the issues are
similar to wifi.  It's worth considering whether something similar to
commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift") might be
benefitial.


I've played a similar patch several days before. The tricky part is the mode
switching between napi and no napi. We should make sure when the packet is
sent and trakced by BQL,  it should be consumed by BQL as well. I did it by
tracking it through skb->cb.  And deal with the freeze by reset the BQL
status. Patch attached.

But when testing with vhost-net, I don't very a stable performance,

So how about increasing TSQ pacing shift then?



I can test this. But changing default TCP value is much more than a 
virtio-net specific thing.






it was
probably because we batch the used ring updating so tx interrupt may come
randomly. We probably need to implement time bounded coalescing mechanism
which could be configured from userspace.

I don't think it's reasonable to expect userspace to be that smart ...
Why do we need time bounded? used ring is always updated when ring
becomes empty.



We don't add used when means BQL may not see the consumed packet in 
time. And the delay varies based on the workload since we count packets 
not bytes or time before doing the batched updating.


Thanks





Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR
regression on machine without APICv, (haven't found time to test APICv
machine). But consider it was for correctness, I think it's acceptable? Then
we can do optimization on top?


Thanks



Signed-off-by: Michael S. Tsirkin 
---
   drivers/net/virtio_net.c | 27 +++
   1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cecfd77c9f3c..b657bde6b94b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1325,7 +1325,8 @@ static int virtnet_receive(struct receive_queue *rq, int 
budget,
return stats.packets;
   }
-static void free_old_xmit_skbs(struct send_queue *sq)
+static void free_old_xmit_skbs(struct send_queue *sq, struct netdev_queue *txq,
+  bool use_napi)
   {
struct sk_buff *skb;
unsigned int len;
@@ -1347,6 +1348,9 @@ static void free_old_xmit_skbs(struct send_queue *sq)
if (!packets)
return;
+   if (use_napi)
+   netdev_tx_completed_queue(txq, packets, bytes);
+
u64_stats_update_begin(&sq->stats.syncp);
sq->stats.bytes += bytes;
sq->stats.packets += packets;
@@ -1364,7 +1368,7 @@ static void virtnet_poll_cleantx(struct receive_queue *rq)
return;
if (__netif_tx_trylock(txq)) {
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, true);
__netif_tx_unlock(txq);
}
@@ -1440,7 +1444,7 @@ static int virtnet_poll_tx(struct napi_struct *napi, int 
budget)
struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
__netif_tx_lock(txq, raw_smp_processor_id());
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, true);
__netif_tx_unlock(txq);
virtqueue_napi_complete(napi, sq->vq, 0);
@@ -1505,13 +1509,15 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, 
struct net_device *dev)
struct send_queue *sq = &vi->sq[qnum];
int err;
struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
-   bool kick = !skb->xmit_more;
+   bool more = skb->xmit_more;
bool use_napi = sq->napi.weight;
+   unsigned int bytes = skb->len;
+   bool kick;
/* Free up any pending old buffers before queueing new ones. */
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, use_napi);
-   if (use_napi && kick)
+   if (use_napi && !more)
virtqueue_enable_cb_delayed(sq->vq);
/* timestamp packet in software */
@@ -1552,7 +1558,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct 
net_device *dev)
if (!use_napi &&
unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
/* More just got used, free them then recheck. */
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, false);
if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
netif_start_subqueue(dev, qnum);
virtqueue_disable_cb(sq->vq);
@@ -1560,7 +1566,12 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, 
struct net_device *dev)
}
}
-   if (kick || netif_xmit_stopped(txq)) {
+   if (use_napi)
+   kick = __netdev_tx_sent_queue(txq, bytes, more);
+   else

Re: [PATCH v1 4/7] drm: remove include of drmP.h from bridge/dw_hdmi.h

[Laurent Pinchart]

Hi Sam,

Thank you for the patch.

On Wednesday, 26 December 2018 23:03:50 EET Sam Ravnborg wrote:
> Add missing includes in dw_hdmi.h and
> fix fallout in drivers.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Kieran Bingham 
> Cc: Fabio Estevam 
> Cc: Neil Armstrong 
> Cc: Maxime Ripard 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 4 
>  drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  | 1 +
>  include/drm/bridge/dw_hdmi.h| 5 -
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index
> 8f9c8a6b46de..c61ec4caaa84 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> @@ -8,6 +8,10 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   */
> +
> +#include 
> +#include 
> +
>  #include 
> 
>  #include 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c index 75490a3e0a2a..f5b07a2e3f59
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -8,6 +8,7 @@
>   */
> 
>  #include 
> +#include 

Nitpicking, _ comes before u.

>  #include 
> 
>  #include 
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index ccb5aa8468e0..b0218ee75a65 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -10,7 +10,10 @@
>  #ifndef __DW_HDMI__
>  #define __DW_HDMI__
> 
> -#include 
> +#include 

I think you can replace this with a forward declaration of struct 
platform_device. You will likely need to handle more fallout.

> +#include 
> +#include 

Please add forward definitions for structures used in this file and not 
defined in the above headers. I'm thinking about struct regmap and struct 
drm_encoder. They may be defined in headers included from the above three, or 
from headers included from files including dw_hdmi.h, but we shouldn't rely on 
that as it may change.

With this fixed,

Reviewed-by: Laurent Pinchart 

>  struct dw_hdmi;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v1 6/7] drm: remove include of drmP.h from drm_modeset_helper.h

[Laurent Pinchart]

Hi Sam,

Thank you for the patch.

On Wednesday, 26 December 2018 23:03:52 EET Sam Ravnborg wrote:
> Fix fallout in various files/drivers by adding missing include files.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Alexey Brodkin 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: Kieran Bingham 
> ---
>  drivers/gpu/drm/arc/arcpgu_sim.c | 1 +
>  drivers/gpu/drm/bridge/cdns-dsi.c| 2 ++
>  drivers/gpu/drm/drm_modeset_helper.c | 2 ++
>  drivers/gpu/drm/rcar-du/rcar_lvds.c  | 1 +
>  include/drm/drm_modeset_helper.h | 2 --
>  5 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c
> b/drivers/gpu/drm/arc/arcpgu_sim.c index 68629e614990..3b7556f62230 100644
> --- a/drivers/gpu/drm/arc/arcpgu_sim.c
> +++ b/drivers/gpu/drm/arc/arcpgu_sim.c
> @@ -14,6 +14,7 @@
>   *
>   */
> 
> +#include 
>  #include 
>  #include 
> 
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c index ce9496d13986..4b73d0969468 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -8,11 +8,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/drm_modeset_helper.c
> b/drivers/gpu/drm/drm_modeset_helper.c index f1c24ab0ef09..680cb6a5978c
> 100644
> --- a/drivers/gpu/drm/drm_modeset_helper.c
> +++ b/drivers/gpu/drm/drm_modeset_helper.c
> @@ -23,8 +23,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> 
>  /**
>   * DOC: aux kms helpers
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 173d7ad0b991..f1043458cbd8
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/include/drm/drm_modeset_helper.h
> b/include/drm/drm_modeset_helper.h index efa337f03129..82ead67dfa36 100644
> --- a/include/drm/drm_modeset_helper.h
> +++ b/include/drm/drm_modeset_helper.h
> @@ -23,8 +23,6 @@
>  #ifndef __DRM_KMS_HELPER_H__
>  #define __DRM_KMS_HELPER_H__
> 
> -#include 

Please add forward declarations for all structures used as pointers in this 
file. We shouldn't rely on the files including drm_modeset_helper.h to provide 
definitions or declarations for those structures.

With that fixed,

Reviewed-by: Laurent Pinchart 

>  void drm_helper_move_panel_connectors_to_head(struct drm_device *);
> 
>  void drm_helper_mode_fill_fb_struct(struct drm_device *dev,

-- 
Regards,

Laurent Pinchart

Re: [PATCH RFC 1/2] virtio-net: bql support

[Jason Wang]

On 2018/12/26 下午11:22, Michael S. Tsirkin wrote:

On Thu, Dec 06, 2018 at 04:17:36PM +0800, Jason Wang wrote:

On 2018/12/6 上午6:54, Michael S. Tsirkin wrote:

When use_napi is set, let's enable BQLs.  Note: some of the issues are
similar to wifi.  It's worth considering whether something similar to
commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift") might be
benefitial.


I've played a similar patch several days before. The tricky part is the mode
switching between napi and no napi. We should make sure when the packet is
sent and trakced by BQL,  it should be consumed by BQL as well.


I just went over the patch again and I don't understand this comment.
This patch only enabled BQL with tx napi.

Thus there's no mode switching.

What did I miss?



Consider the case:


TX NAPI is disabled:

send N packets

turn TX NAPI on:

get tx interrupt

BQL try to consume those packets when lead WARN for dql.


Thanks







I did it by
tracking it through skb->cb.  And deal with the freeze by reset the BQL
status. Patch attached.

But when testing with vhost-net, I don't very a stable performance, it was
probably because we batch the used ring updating so tx interrupt may come
randomly. We probably need to implement time bounded coalescing mechanism
which could be configured from userspace.

Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR
regression on machine without APICv, (haven't found time to test APICv
machine). But consider it was for correctness, I think it's acceptable? Then
we can do optimization on top?


Thanks



Signed-off-by: Michael S. Tsirkin 
---
   drivers/net/virtio_net.c | 27 +++
   1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cecfd77c9f3c..b657bde6b94b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1325,7 +1325,8 @@ static int virtnet_receive(struct receive_queue *rq, int 
budget,
return stats.packets;
   }
-static void free_old_xmit_skbs(struct send_queue *sq)
+static void free_old_xmit_skbs(struct send_queue *sq, struct netdev_queue *txq,
+  bool use_napi)
   {
struct sk_buff *skb;
unsigned int len;
@@ -1347,6 +1348,9 @@ static void free_old_xmit_skbs(struct send_queue *sq)
if (!packets)
return;
+   if (use_napi)
+   netdev_tx_completed_queue(txq, packets, bytes);
+
u64_stats_update_begin(&sq->stats.syncp);
sq->stats.bytes += bytes;
sq->stats.packets += packets;
@@ -1364,7 +1368,7 @@ static void virtnet_poll_cleantx(struct receive_queue *rq)
return;
if (__netif_tx_trylock(txq)) {
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, true);
__netif_tx_unlock(txq);
}
@@ -1440,7 +1444,7 @@ static int virtnet_poll_tx(struct napi_struct *napi, int 
budget)
struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
__netif_tx_lock(txq, raw_smp_processor_id());
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, true);
__netif_tx_unlock(txq);
virtqueue_napi_complete(napi, sq->vq, 0);
@@ -1505,13 +1509,15 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, 
struct net_device *dev)
struct send_queue *sq = &vi->sq[qnum];
int err;
struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
-   bool kick = !skb->xmit_more;
+   bool more = skb->xmit_more;
bool use_napi = sq->napi.weight;
+   unsigned int bytes = skb->len;
+   bool kick;
/* Free up any pending old buffers before queueing new ones. */
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, use_napi);
-   if (use_napi && kick)
+   if (use_napi && !more)
virtqueue_enable_cb_delayed(sq->vq);
/* timestamp packet in software */
@@ -1552,7 +1558,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct 
net_device *dev)
if (!use_napi &&
unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
/* More just got used, free them then recheck. */
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, txq, false);
if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
netif_start_subqueue(dev, qnum);
virtqueue_disable_cb(sq->vq);
@@ -1560,7 +1566,12 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, 
struct net_device *dev)
}
}
-   if (kick || netif_xmit_stopped(txq)) {
+   if (use_napi)
+   kick = __netdev_tx_sent_queue(txq, bytes, more);
+   else
+   kick = !more || netif_xmit_stopped(txq);
+
+   if (kick) {
if (virtqueue_kick_prepare(sq->vq) && virtqueue_notify(sq->vq)) 
{

Re: WIP Droid 4 voice calls, GNSS & PM with a TS 27.010 serdev driver

[Pavel Machek]

Hi!

> So the little elves have been slowly working to get voice calls
> working on droid 4 with the mainline kernel. And just in time for the
> upcoming holidays, it might be possible to call friends and
> relatives.

Thanks a lot for the Christmas present :-).

> 2. Test a voice call
> 
> $ minicom -D /dev/motmdm1 # Then Ctrl-a-e to enable local echo
> AT# Case sensitive AT commands..
> :OK   # Response uses : as separator..
> AT+CFUN=1 # Enable radio
> +CFUN:OK
> ~+RSSI=1,9,108,99,0,0,0
> ...
> ATD1234567890 # Dial some phone number
> D:OK
> ...
> ATH   # Hang up
> H:OK

Ok, I really need SMS messages, too.

Fortunately, they are on /dev/motmdm9, in PDU format. Quite
logical. And you probably need to acknowledge them, using PDU,
too... (because otherwise you'll just get the same SMS over and over
and over). Which is also logical, but hard to do from shell/python.

Proper solution involves special support for ofonod...


Fortunately ttyUSB4 still works, so I can still use my old code... and
I started logging motmdm1 and 9 to a file as a backup... that should
be better than my existing solution. (But I don't get power benefits
etc.)

Best regards,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

ath10_pci: WARN(() on resume from S3

[Gabriel C]

Hello ,

on a QCA9377 card I hit WARN() on each resume from S3.

This is on kernel 4.19.X and now on 4.20.0 too.
On kernel 4.19.x I see just the first WARN() while on
4.20.0 I see now two.

Also I see Unknown eventid: xxx and on 4.20.0
a unsupported HTC service id: xxx message(s).


...

[   45.740910] ACPI: Waking up from system sleep state S3
[   45.743781] ACPI: EC: interrupt unblocked
[   46.125319] ACPI: EC: event unblocked
[   46.125659] sd 0:0:0:0: [sda] Starting disk
[   46.357351] usb 1-6: reset high-speed USB device number 3 using xhci_hcd
[   46.432399] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   46.432718] ata1.00: supports DRM functions and may not be fully accessible
[   46.432792] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   46.434757] ata2.00: configured for UDMA/133
[   46.435943] ata1.00: supports DRM functions and may not be fully accessible
[   46.438678] ata1.00: configured for UDMA/133
[   46.438718] ata1.00: Enabling discard_zeroes_data
[   46.485511] r8169 :02:00.0 enp2s0: Link is Down
[   46.597393] usb 1-5: reset high-speed USB device number 2 using xhci_hcd
[   46.837432] usb 1-7: reset full-speed USB device number 4 using xhci_hcd
[   48.375066] ath10k_pci :03:00.0: unsupported HTC service id: 1536
[   48.390223] ath10k_pci :03:00.0: Unknown eventid: 118809
[   48.393133] ath10k_pci :03:00.0: Unknown eventid: 90118
[   48.415625] WARNING: CPU: 2 PID: 1251 at 
drivers/net/wireless/ath/ath10k/mac.c:5650 ath10k_bss_info_changed+0xc8b/0xef0 
[ath10k_core]
[   48.415626] Modules linked in: ctr ccm cmac af_packet arc4 amdgpu chash 
amd_iommu_v2 gpu_sched joydev snd_hda_codec_hdmi snd_hda_codec_conexant bnep 
snd_hda_codec_generic radeon ath10k_pci ath10k_core ath iTCO_wdt 
iTCO_vendor_support i915 mac80211 coretemp snd_soc_skl intel_rapl 
x86_pkg_temp_thermal intel_powerclamp snd_soc_hdac_hda snd_hda_ext_core btusb 
snd_soc_skl_ipc btrtl btbcm snd_soc_sst_ipc btintel snd_soc_sst_dsp kvm_intel 
kvmgt snd_soc_acpi_intel_match snd_soc_acpi vfio_mdev mdev nls_utf8 bluetooth 
vfio_iommu_type1 vfio uvcvideo nls_cp437 vfat videobuf2_vmalloc fat 
snd_soc_core ttm videobuf2_memops videobuf2_v4l2 kvm cec snd_compress rc_core 
snd_pcm_dmaengine videobuf2_common snd_hda_intel drm_kms_helper videodev 
rtsx_usb_ms ecdh_generic snd_hda_codec memstick cfg80211 drm irqbypass 
efi_pstore pcspkr psmouse intel_gtt media r8169 snd_hda_core agpgart evdev 
mac_hid snd_hwdep intel_wmi_thunderbolt efivars i2c_i801 i2c_algo_bit hwmon 
libphy ideapad_laptop fb_sys_fops syscopyarea
[   48.415659]  sparse_keymap sysfillrect rfkill sysimgblt battery i2c_core ac 
intel_pch_thermal acpi_pad button thermal pcc_cpufreq ppdev sch_fq_codel fuse 
snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi_event 
snd_seq snd_seq_device snd_timer snd soundcore lp parport_pc parport 
binfmt_misc sg ext4 crc32c_generic crc16 mbcache jbd2 fscrypto rtsx_usb_sdmmc 
mmc_core rtsx_usb sr_mod sd_mod cdrom crct10dif_pclmul crc32_pclmul 
crc32c_intel ghash_clmulni_intel ahci libahci libata xhci_pci xhci_hcd 
aesni_intel scsi_mod usbcore aes_x86_64 crypto_simd cryptd glue_helper 
serio_raw wmi video dm_mirror dm_region_hash dm_log dm_mod efivarfs unix 
sha256_ssse3 sha256_generic sha1_ssse3 sha1_generic hmac ipv6 autofs4
[   48.415688] CPU: 2 PID: 1251 Comm: kworker/u8:19 Not tainted 4.20-fw1 #1
[   48.415689] Hardware name: LENOVO 80UD/LNVNB161216, BIOS 1TCN27WW(V2.08) 
07/06/2018
[   48.415692] Workqueue: events_unbound async_run_entry_fn
[   48.415698] RIP: 0010:ath10k_bss_info_changed+0xc8b/0xef0 [ath10k_core]
[   48.415700] Code: ff ff b8 a1 ff ff ff e9 a9 f4 ff ff b8 a1 ff ff ff e9 05 
f6 ff ff b8 a1 ff ff ff e9 3f f5 ff ff b8 a1 ff ff ff e9 6e f6 ff ff <0f> 0b e9 
da f6 ff ff b8 a1 ff ff ff e9 73 f9 ff ff b8 a1 ff ff ff
[   48.415701] RSP: :aadd43597cd8 EFLAGS: 00010282
[   48.415702] RAX: fffe RBX: 8fa9f27a1380 RCX: 
[   48.415703] RDX: 0001 RSI: aadd43597cf8 RDI: 8fa9f27a1380
[   48.415704] RBP: 030674ff R08: 0020 R09: 
[   48.415705] R10: 001f R11: 8fa9cf7cf500 R12: 8fa9f27a1388
[   48.415706] R13: 8fa9ee552558 R14: 8fa9ee551580 R15: 8fa9ee551580
[   48.415707] FS:  () GS:8fa9f730() 
knlGS:
[   48.415708] CS:  0010 DS:  ES:  CR0: 80050033
[   48.415709] CR2:  CR3: 00011700a001 CR4: 003606e0
[   48.415710] Call Trace:
[   48.415717]  ? ath10k_conf_tx+0x12d/0x4c0 [ath10k_core]
[   48.415729]  ieee80211_bss_info_change_notify+0xa9/0x1c0 [mac80211]
[   48.415744]  ieee80211_reconfig+0xa4f/0x1560 [mac80211]
[   48.415757]  wiphy_resume+0x7e/0x150 [cfg80211]
[   48.415767]  ? wiphy_namespace+0x10/0x10 [cfg80211]
[   48.415770]  dpm_run_callback+0x2e/0x130
[   48.415772]  device_resume+0x97/0x190
[   48.415774]  async_resume+0x19/0x40
[   48.415776]  async_r

Re: KASAN: use-after-free Write in __xfrm_policy_unlink

[Dmitry Vyukov]

On Wed, Dec 26, 2018 at 11:42 AM Florian Westphal  wrote:
>
> syzbot  wrote:
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit:ce28bb445388 Merge git://git.kernel.org/pub/scm/linux/kern..
> > git tree:   net-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1673fb1b40
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=67a2081147a23142
> > dashboard link: https://syzkaller.appspot.com/bug?extid=9d971dd21eb26567036b
> > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1134dcc740
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=126986ed40
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+9d971dd21eb265670...@syzkaller.appspotmail.com
>
> I've fixed this one.  Chances are that at least some of the other
> reports are duplicates of this one.
>
> I will continue to look at other reports over the next few days and plan
> to send out fixes and test cases next week.

Thanks for the update, Florian. Sounds great, let's kill them all!

Re: [PATCH] sched: fix infinity loop in update_blocked_averages

[Vincent Guittot]

Le Thursday 27 Dec 2018 à 10:21:53 (+0100), Vincent Guittot a écrit :
> Hi Xie,
> 
> On Thu, 27 Dec 2018 at 03:57, Xie XiuQi  wrote:
> >
> > Zhepeng Xie report a bug, there is a infinity loop in
> > update_blocked_averages().
> >
> > PID: 14233  TASK: 800b2de08fc0  CPU: 1   COMMAND: "docker"
> >  #0 [2213b9d0] update_blocked_averages at 0811e4a8
> >  #1 [2213ba60] pick_next_task_fair at 0812a3b4
> >  #2 [2213baf0] __schedule at 08deaa88
> >  #3 [2213bb70] schedule at 08deb1b8
> >  #4 [2213bb80] futex_wait_queue_me at 08180754
> >  #5 [2213bbd0] futex_wait at 0818192c
> >  #6 [2213bd00] do_futex at 08183ee4
> >  #7 [2213bde0] __arm64_sys_futex at 08184398
> >  #8 [2213be60] el0_svc_common at 080979ac
> >  #9 [2213bea0] el0_svc_handler at 08097a6c
> >  #10 [2213bff0] el0_svc at 08084044
> >
> > rq->tmp_alone_branch introduced in 4.10, used to point to
> > the new beg of the list. If this cfs_rq is deleted somewhere
> > else, then the tmp_alone_branch will be illegal and cause
> > a list_add corruption.
> 
> shouldn't all the sequence  be protected by rq_lock ?
> 
> 
> >
> > (When enabled DEBUG_LIST, we fould this list_add corruption)
> >
> > [ 2546.741103] list_add corruption. next->prev should be prev
> > (800b4d61ad40), but was 800ba434fa38. (next=800b6a95e740).
> > [ 2546.741130] [ cut here ]
> > [ 2546.741132] kernel BUG at lib/list_debug.c:25!
> > [ 2546.741136] Internal error: Oops - BUG: 0 [#1] SMP
> > [ 2546.742870] CPU: 1 PID: 29428 Comm: docker-runc Kdump: loaded Tainted: G 
> > E  4.19.5-1.aarch64 #1
> > [ 2546.745415] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 
> > 02/06/2015
> > [ 2546.747402] pstate: 4085 (nZcv daIf -PAN -UAO)
> > [ 2546.749015] pc : __list_add_valid+0x50/0x90
> > [ 2546.750485] lr : __list_add_valid+0x50/0x90
> > [ 2546.751975] sp : 1b5eb910
> > [ 2546.753286] x29: 1b5eb910 x28: 800abacf
> > [ 2546.754976] x27: 1b5ebbb0 x26: 0957
> > [ 2546.756665] x25: 0960d000 x24: 0250f41ca8f8
> > [ 2546.758366] x23: 800b6a95e740 x22: 800b4d61ad40
> > [ 2546.760066] x21: 800b4d61ad40 x20: 800ba434f080
> > [ 2546.761742] x19: 800b4d61ac00 x18: 
> > [ 2546.763425] x17:  x16: 
> > [ 2546.765089] x15: 09570748 x14: 662073617720
> > [ 2546.766755] x13: 747562202c293034 x12: 6461313664346230
> > [ 2546.768429] x11: 30382820 x10: 
> > [ 2546.770124] x9 : 0001 x8 : 09f34a0f
> > [ 2546.771831] x7 :  x6 : 250d
> > [ 2546.773525] x5 :  x4 : 
> > [ 2546.775227] x3 :  x2 : 70ef7f624013ca00
> > [ 2546.776929] x1 :  x0 : 0075
> > [ 2546.778623] Process docker-runc (pid: 29428, stack limit = 
> > 0x293494a2)
> > [ 2546.780742] Call trace:
> > [ 2546.781955]  __list_add_valid+0x50/0x90
> > [ 2546.783469]  enqueue_entity+0x4a0/0x6e8
> > [ 2546.784957]  enqueue_task_fair+0xac/0x610
> > [ 2546.786502]  sched_move_task+0x134/0x178
> > [ 2546.787993]  cpu_cgroup_attach+0x40/0x78
> > [ 2546.789540]  cgroup_migrate_execute+0x378/0x3a8
> > [ 2546.791169]  cgroup_migrate+0x6c/0x90
> > [ 2546.792663]  cgroup_attach_task+0x148/0x238
> > [ 2546.794211]  __cgroup1_procs_write.isra.2+0xf8/0x160
> > [ 2546.795935]  cgroup1_procs_write+0x38/0x48
> > [ 2546.797492]  cgroup_file_write+0xa0/0x170
> > [ 2546.799010]  kernfs_fop_write+0x114/0x1e0
> > [ 2546.800558]  __vfs_write+0x60/0x190
> > [ 2546.801977]  vfs_write+0xac/0x1c0
> > [ 2546.803341]  ksys_write+0x6c/0xd8
> > [ 2546.804674]  __arm64_sys_write+0x24/0x30
> > [ 2546.806146]  el0_svc_common+0x78/0x100
> > [ 2546.807584]  el0_svc_handler+0x38/0x88
> > [ 2546.809017]  el0_svc+0x8/0xc
> >
> 
> Have you got more details about the sequence that generates this bug ?
> Is it easily reproducible ?
> 
> > In this patch, we move rq->tmp_alone_branch point to its prev before delete 
> > it
> > from list.
> >
> > Reported-by: Zhipeng Xie 
> > Cc: Bin Li 
> > Cc: [4.10+]
> > Fixes: 9c2791f936ef (sched/fair: Fix hierarchical order in 
> > rq->leaf_cfs_rq_list)
> 
> If it only happens in update_blocked_averages(), the del leaf has been added 
> by:
> a9e7f6544b9c (sched/fair: Fix O(nr_cgroups) in load balance path)
> 
> > Signed-off-by: Xie XiuQi 
> > Tested-by: Zhipeng Xie 
> > ---
> >  kernel/sched/fair.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index ac855b2..7a72702 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -347,6 +347,11 @@ static inline void list_add_leaf_cfs_rq(struct cfs_rq 
> > *cfs_rq)
> >  static inline void list_del_leaf_cfs_rq(struct cfs_rq *cfs_rq

Re: [PATCH] sched: fix infinity loop in update_blocked_averages

[Vincent Guittot]

Adding Sargun and Dimitry who faced similar problem
Adding Tejun

On Thu, 27 Dec 2018 at 11:21, Vincent Guittot
 wrote:
>
> Le Thursday 27 Dec 2018 à 10:21:53 (+0100), Vincent Guittot a écrit :
> > Hi Xie,
> >
> > On Thu, 27 Dec 2018 at 03:57, Xie XiuQi  wrote:
> > >
> > > Zhepeng Xie report a bug, there is a infinity loop in
> > > update_blocked_averages().
> > >
> > > PID: 14233  TASK: 800b2de08fc0  CPU: 1   COMMAND: "docker"
> > >  #0 [2213b9d0] update_blocked_averages at 0811e4a8
> > >  #1 [2213ba60] pick_next_task_fair at 0812a3b4
> > >  #2 [2213baf0] __schedule at 08deaa88
> > >  #3 [2213bb70] schedule at 08deb1b8
> > >  #4 [2213bb80] futex_wait_queue_me at 08180754
> > >  #5 [2213bbd0] futex_wait at 0818192c
> > >  #6 [2213bd00] do_futex at 08183ee4
> > >  #7 [2213bde0] __arm64_sys_futex at 08184398
> > >  #8 [2213be60] el0_svc_common at 080979ac
> > >  #9 [2213bea0] el0_svc_handler at 08097a6c
> > >  #10 [2213bff0] el0_svc at 08084044
> > >
> > > rq->tmp_alone_branch introduced in 4.10, used to point to
> > > the new beg of the list. If this cfs_rq is deleted somewhere
> > > else, then the tmp_alone_branch will be illegal and cause
> > > a list_add corruption.
> >
> > shouldn't all the sequence  be protected by rq_lock ?
> >
> >
> > >
> > > (When enabled DEBUG_LIST, we fould this list_add corruption)
> > >
> > > [ 2546.741103] list_add corruption. next->prev should be prev
> > > (800b4d61ad40), but was 800ba434fa38. (next=800b6a95e740).
> > > [ 2546.741130] [ cut here ]
> > > [ 2546.741132] kernel BUG at lib/list_debug.c:25!
> > > [ 2546.741136] Internal error: Oops - BUG: 0 [#1] SMP
> > > [ 2546.742870] CPU: 1 PID: 29428 Comm: docker-runc Kdump: loaded Tainted: 
> > > G E  4.19.5-1.aarch64 #1
> > > [ 2546.745415] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 
> > > 02/06/2015
> > > [ 2546.747402] pstate: 4085 (nZcv daIf -PAN -UAO)
> > > [ 2546.749015] pc : __list_add_valid+0x50/0x90
> > > [ 2546.750485] lr : __list_add_valid+0x50/0x90
> > > [ 2546.751975] sp : 1b5eb910
> > > [ 2546.753286] x29: 1b5eb910 x28: 800abacf
> > > [ 2546.754976] x27: 1b5ebbb0 x26: 0957
> > > [ 2546.756665] x25: 0960d000 x24: 0250f41ca8f8
> > > [ 2546.758366] x23: 800b6a95e740 x22: 800b4d61ad40
> > > [ 2546.760066] x21: 800b4d61ad40 x20: 800ba434f080
> > > [ 2546.761742] x19: 800b4d61ac00 x18: 
> > > [ 2546.763425] x17:  x16: 
> > > [ 2546.765089] x15: 09570748 x14: 662073617720
> > > [ 2546.766755] x13: 747562202c293034 x12: 6461313664346230
> > > [ 2546.768429] x11: 30382820 x10: 
> > > [ 2546.770124] x9 : 0001 x8 : 09f34a0f
> > > [ 2546.771831] x7 :  x6 : 250d
> > > [ 2546.773525] x5 :  x4 : 
> > > [ 2546.775227] x3 :  x2 : 70ef7f624013ca00
> > > [ 2546.776929] x1 :  x0 : 0075
> > > [ 2546.778623] Process docker-runc (pid: 29428, stack limit = 
> > > 0x293494a2)
> > > [ 2546.780742] Call trace:
> > > [ 2546.781955]  __list_add_valid+0x50/0x90
> > > [ 2546.783469]  enqueue_entity+0x4a0/0x6e8
> > > [ 2546.784957]  enqueue_task_fair+0xac/0x610
> > > [ 2546.786502]  sched_move_task+0x134/0x178
> > > [ 2546.787993]  cpu_cgroup_attach+0x40/0x78
> > > [ 2546.789540]  cgroup_migrate_execute+0x378/0x3a8
> > > [ 2546.791169]  cgroup_migrate+0x6c/0x90
> > > [ 2546.792663]  cgroup_attach_task+0x148/0x238
> > > [ 2546.794211]  __cgroup1_procs_write.isra.2+0xf8/0x160
> > > [ 2546.795935]  cgroup1_procs_write+0x38/0x48
> > > [ 2546.797492]  cgroup_file_write+0xa0/0x170
> > > [ 2546.799010]  kernfs_fop_write+0x114/0x1e0
> > > [ 2546.800558]  __vfs_write+0x60/0x190
> > > [ 2546.801977]  vfs_write+0xac/0x1c0
> > > [ 2546.803341]  ksys_write+0x6c/0xd8
> > > [ 2546.804674]  __arm64_sys_write+0x24/0x30
> > > [ 2546.806146]  el0_svc_common+0x78/0x100
> > > [ 2546.807584]  el0_svc_handler+0x38/0x88
> > > [ 2546.809017]  el0_svc+0x8/0xc
> > >
> >
> > Have you got more details about the sequence that generates this bug ?
> > Is it easily reproducible ?
> >
> > > In this patch, we move rq->tmp_alone_branch point to its prev before 
> > > delete it
> > > from list.
> > >
> > > Reported-by: Zhipeng Xie 
> > > Cc: Bin Li 
> > > Cc: [4.10+]
> > > Fixes: 9c2791f936ef (sched/fair: Fix hierarchical order in 
> > > rq->leaf_cfs_rq_list)
> >
> > If it only happens in update_blocked_averages(), the del leaf has been 
> > added by:
> > a9e7f6544b9c (sched/fair: Fix O(nr_cgroups) in load balance path)
> >
> > > Signed-off-by: Xie XiuQi 
> > > Tested-by: Zhipeng Xie 
> > > ---
> > >  kernel/sched/fair.c | 5 +
> > >  1 file changed, 5 inse

Re: [PATCH v3 0/2] perf tests: Check for ARM [vectors] page

[Namhyung Kim]

Hello,

On Thu, Dec 20, 2018 at 07:43:35PM -0800, Florian Fainelli wrote:
> Hi all,
> 
> I just painfully learned that perf would segfault when
> CONFIG_KUSER_HELPERS is disabled because it unconditionally makes use of

Could you please elaborate?

Thanks,
Namhyung


> it. This patch series adds an ARM test for that by leveraging the
> existing find_vdso_map() function and making it more generic and capable
> of location any map within /proc/self/maps.
> 
> Changes in v3:
> 
> - remove find_vdso_map() call find_map() with VDSO__MAP_NAME
> 
> Changes in v2:
> 
> - use strlen() instead of sizeof() -1 since we made the page name a
>   parameter
> - use TEST_OK/TEST_FAIL in lieu of 0/-1
> - added an error message indicating CONFIG_KUSER_HELPERS might be
>   disabled
> 
> Florian Fainelli (2):
>   perf tools: Make find_vdso_map() more modular
>   perf tests: Add a test for the ARM 32-bit [vectors] page
> 
>  tools/perf/Makefile.perf  |  4 ++--
>  tools/perf/arch/arm/tests/Build   |  1 +
>  tools/perf/arch/arm/tests/arch-tests.c|  4 
>  tools/perf/arch/arm/tests/vectors-page.c  | 24 +++
>  tools/perf/perf-read-vdso.c   |  6 ++---
>  tools/perf/tests/tests.h  |  5 
>  .../perf/util/{find-vdso-map.c => find-map.c} |  7 +++---
>  tools/perf/util/vdso.c|  6 ++---
>  8 files changed, 45 insertions(+), 12 deletions(-)
>  create mode 100644 tools/perf/arch/arm/tests/vectors-page.c
>  rename tools/perf/util/{find-vdso-map.c => find-map.c} (71%)
> 
> -- 
> 2.17.1
> 

[PATCH v4 4/5] irqchip: sifive-plic: Differentiate between PLIC handler and context

[Anup Patel]

We explicitly differentiate between PLIC handler and context because
PLIC context is for given mode of HART whereas PLIC handler is per-CPU
software construct meant for handling interrupts from a particular
PLIC context.

To achieve this differentiation, we rename "nr_handlers" to "nr_contexts"
and "nr_mapped" to "nr_handlers" in plic_init().

Signed-off-by: Anup Patel 
---
 drivers/irqchip/irq-sifive-plic.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/irqchip/irq-sifive-plic.c 
b/drivers/irqchip/irq-sifive-plic.c
index b9a0bcefe426..24c906f4be93 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -177,7 +177,7 @@ static int plic_find_hart_id(struct device_node *node)
 static int __init plic_init(struct device_node *node,
struct device_node *parent)
 {
-   int error = 0, nr_handlers, nr_mapped = 0, i;
+   int error = 0, nr_contexts, nr_handlers = 0, i;
u32 nr_irqs;
 
if (plic_regs) {
@@ -194,10 +194,10 @@ static int __init plic_init(struct device_node *node,
if (WARN_ON(!nr_irqs))
goto out_iounmap;
 
-   nr_handlers = of_irq_count(node);
-   if (WARN_ON(!nr_handlers))
+   nr_contexts = of_irq_count(node);
+   if (WARN_ON(!nr_contexts))
goto out_iounmap;
-   if (WARN_ON(nr_handlers < num_possible_cpus()))
+   if (WARN_ON(nr_contexts < num_possible_cpus()))
goto out_iounmap;
 
error = -ENOMEM;
@@ -206,7 +206,7 @@ static int __init plic_init(struct device_node *node,
if (WARN_ON(!plic_irqdomain))
goto out_iounmap;
 
-   for (i = 0; i < nr_handlers; i++) {
+   for (i = 0; i < nr_contexts; i++) {
struct of_phandle_args parent;
struct plic_handler *handler;
irq_hw_number_t hwirq;
@@ -245,11 +245,11 @@ static int __init plic_init(struct device_node *node,
writel(0, handler->hart_base + CONTEXT_THRESHOLD);
for (hwirq = 1; hwirq <= nr_irqs; hwirq++)
plic_toggle(handler, hwirq, 0);
-   nr_mapped++;
+   nr_handlers++;
}
 
-   pr_info("mapped %d interrupts to %d (out of %d) handlers.\n",
-   nr_irqs, nr_mapped, nr_handlers);
+   pr_info("mapped %d interrupts with %d handlers for %d contexts.\n",
+   nr_irqs, nr_handlers, nr_contexts);
set_handle_irq(plic_handle_irq);
return 0;
 
-- 
2.17.1

[PATCH v4 2/5] irqchip: sifive-plic: Don't inline plic_toggle() and plic_irq_toggle()

[Anup Patel]

The plic_toggle() uses raw_spin_lock() and plic_irq_toggle has a
for loop so both these functions are not suitable for being inline
hence this patch removes the inline keyword.

Signed-off-by: Anup Patel 
---
 drivers/irqchip/irq-sifive-plic.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-sifive-plic.c 
b/drivers/irqchip/irq-sifive-plic.c
index c23a293a2aae..01ffbcae 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -69,8 +69,8 @@ struct plic_handler {
 };
 static DEFINE_PER_CPU(struct plic_handler, plic_handlers);
 
-static inline void plic_toggle(struct plic_handler *handler,
-   int hwirq, int enable)
+static void plic_toggle(struct plic_handler *handler,
+   int hwirq, int enable)
 {
u32 __iomem *reg = handler->enable_base + (hwirq / 32) * sizeof(u32);
u32 hwirq_mask = 1 << (hwirq % 32);
@@ -83,7 +83,7 @@ static inline void plic_toggle(struct plic_handler *handler,
raw_spin_unlock(&handler->enable_lock);
 }
 
-static inline void plic_irq_toggle(struct irq_data *d, int enable)
+static void plic_irq_toggle(struct irq_data *d, int enable)
 {
int cpu;
 
-- 
2.17.1

[PATCH v4 5/5] irqchip: sifive-plic: Implement irq_set_affinity() for SMP host

[Anup Patel]

Currently on SMP host, all CPUs take external interrupts routed via
PLIC. All CPUs will try to claim a given external interrupt but only
one of them will succeed while other CPUs would simply resume whatever
they were doing before. This means if we have N CPUs then for every
external interrupt N-1 CPUs will always fail to claim it and waste
their CPU time.

Instead of above, external interrupts should be taken by only one CPU
and we should have provision to explicitly specify IRQ affinity from
kernel-space or user-space.

This patch provides irq_set_affinity() implementation for PLIC driver.
It also updates irq_enable() such that PLIC interrupts are only enabled
for one of CPUs specified in IRQ affinity mask.

With this patch in-place, we can change IRQ affinity at any-time from
user-space using procfs.

Example:

/ # cat /proc/interrupts
   CPU0   CPU1   CPU2   CPU3
  8: 44  0  0  0  SiFive PLIC   8  virtio0
 10: 48  0  0  0  SiFive PLIC  10  ttyS0
IPI0:55663 58363  Rescheduling interrupts
IPI1: 0  1  3 16  Function call interrupts
/ #
/ #
/ # echo 4 > /proc/irq/10/smp_affinity
/ #
/ # cat /proc/interrupts
   CPU0   CPU1   CPU2   CPU3
  8: 45  0  0  0  SiFive PLIC   8  virtio0
 10:160  0 17  0  SiFive PLIC  10  ttyS0
IPI0:68693 77410  Rescheduling interrupts
IPI1: 0  2  3 16  Function call interrupts

Signed-off-by: Anup Patel 
---
 drivers/irqchip/irq-sifive-plic.c | 44 ++-
 1 file changed, 38 insertions(+), 6 deletions(-)

diff --git a/drivers/irqchip/irq-sifive-plic.c 
b/drivers/irqchip/irq-sifive-plic.c
index 24c906f4be93..47da70795145 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -83,29 +83,58 @@ static void plic_toggle(struct plic_handler *handler,
raw_spin_unlock(&handler->enable_lock);
 }
 
-static void plic_irq_toggle(struct irq_data *d, int enable)
+static void plic_irq_toggle(const struct cpumask *mask, int hwirq, int enable)
 {
int cpu;
 
-   writel(enable, plic_regs + PRIORITY_BASE + d->hwirq * PRIORITY_PER_ID);
-   for_each_cpu(cpu, irq_data_get_affinity_mask(d)) {
+   writel(enable, plic_regs + PRIORITY_BASE + hwirq * PRIORITY_PER_ID);
+   for_each_cpu(cpu, mask) {
struct plic_handler *handler = per_cpu_ptr(&plic_handlers, cpu);
 
if (handler->present)
-   plic_toggle(handler, d->hwirq, enable);
+   plic_toggle(handler, hwirq, enable);
}
 }
 
 static void plic_irq_enable(struct irq_data *d)
 {
-   plic_irq_toggle(d, 1);
+   unsigned int cpu = cpumask_any_and(irq_data_get_affinity_mask(d),
+  cpu_online_mask);
+   if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
+   return;
+   plic_irq_toggle(cpumask_of(cpu), d->hwirq, 1);
 }
 
 static void plic_irq_disable(struct irq_data *d)
 {
-   plic_irq_toggle(d, 0);
+   plic_irq_toggle(cpu_possible_mask, d->hwirq, 0);
 }
 
+#ifdef CONFIG_SMP
+static int plic_set_affinity(struct irq_data *d,
+const struct cpumask *mask_val, bool force)
+{
+   unsigned int cpu;
+
+   if (!force)
+   cpu = cpumask_any_and(mask_val, cpu_online_mask);
+   else
+   cpu = cpumask_first(mask_val);
+
+   if (cpu >= nr_cpu_ids)
+   return -EINVAL;
+
+   if (!irqd_irq_disabled(d)) {
+   plic_irq_toggle(cpu_possible_mask, d->hwirq, 0);
+   plic_irq_toggle(cpumask_of(cpu), d->hwirq, 1);
+   }
+
+   irq_data_update_effective_affinity(d, cpumask_of(cpu));
+
+   return IRQ_SET_MASK_OK_DONE;
+}
+#endif
+
 static struct irq_chip plic_chip = {
.name   = "SiFive PLIC",
/*
@@ -114,6 +143,9 @@ static struct irq_chip plic_chip = {
 */
.irq_enable = plic_irq_enable,
.irq_disable= plic_irq_disable,
+#ifdef CONFIG_SMP
+   .irq_set_affinity = plic_set_affinity,
+#endif
 };
 
 static int plic_irqdomain_map(struct irq_domain *d, unsigned int irq,
-- 
2.17.1

[PATCH v4 3/5] irqchip: sifive-plic: Add warning in plic_init() if handler already present

[Anup Patel]

We have two enteries (one for M-mode and another for S-mode) in the
interrupts-extended DT property of PLIC DT node for each HART. It is
expected that firmware/bootloader will set M-mode HWIRQ line of each
HART to 0x (i.e. -1) in interrupts-extended DT property
because Linux runs in S-mode only.

If firmware/bootloader is buggy then it will not correctly update
interrupts-extended DT property which might result in a plic_handler
configured twice. This patch adds a warning in plic_init() if a
plic_handler is already marked present. This warning provides us
a hint about incorrectly updated interrupts-extended DT property.

Signed-off-by: Anup Patel 
Reviewed-by: Christoph Hellwig 
---
 drivers/irqchip/irq-sifive-plic.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/irqchip/irq-sifive-plic.c 
b/drivers/irqchip/irq-sifive-plic.c
index 01ffbcae..b9a0bcefe426 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -229,6 +229,11 @@ static int __init plic_init(struct device_node *node,
 
cpu = riscv_hartid_to_cpuid(hartid);
handler = per_cpu_ptr(&plic_handlers, cpu);
+   if (handler->present) {
+   pr_warn("handler already present for context %d.\n", i);
+   continue;
+   }
+
handler->present = true;
handler->hart_base =
plic_regs + CONTEXT_BASE + i * CONTEXT_PER_HART;
-- 
2.17.1

[PATCH v4 1/5] irqchip: sifive-plic: Pre-compute context hart base and enable base

[Anup Patel]

This patch does following optimizations:
1. Pre-compute hart base for each context handler
2. Pre-compute enable base for each context handler
3. Have enable lock for each context handler instead
of global plic_toggle_lock

Signed-off-by: Anup Patel 
---
 drivers/irqchip/irq-sifive-plic.c | 47 ++-
 1 file changed, 21 insertions(+), 26 deletions(-)

diff --git a/drivers/irqchip/irq-sifive-plic.c 
b/drivers/irqchip/irq-sifive-plic.c
index 357e9daf94ae..c23a293a2aae 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -59,37 +59,28 @@ static void __iomem *plic_regs;
 
 struct plic_handler {
boolpresent;
-   int ctxid;
+   void __iomem*hart_base;
+   /*
+* Protect mask operations on the registers given that we can't
+* assume atomic memory operations work on them.
+*/
+   raw_spinlock_t  enable_lock;
+   void __iomem*enable_base;
 };
 static DEFINE_PER_CPU(struct plic_handler, plic_handlers);
 
-static inline void __iomem *plic_hart_offset(int ctxid)
-{
-   return plic_regs + CONTEXT_BASE + ctxid * CONTEXT_PER_HART;
-}
-
-static inline u32 __iomem *plic_enable_base(int ctxid)
-{
-   return plic_regs + ENABLE_BASE + ctxid * ENABLE_PER_HART;
-}
-
-/*
- * Protect mask operations on the registers given that we can't assume that
- * atomic memory operations work on them.
- */
-static DEFINE_RAW_SPINLOCK(plic_toggle_lock);
-
-static inline void plic_toggle(int ctxid, int hwirq, int enable)
+static inline void plic_toggle(struct plic_handler *handler,
+   int hwirq, int enable)
 {
-   u32 __iomem *reg = plic_enable_base(ctxid) + (hwirq / 32);
+   u32 __iomem *reg = handler->enable_base + (hwirq / 32) * sizeof(u32);
u32 hwirq_mask = 1 << (hwirq % 32);
 
-   raw_spin_lock(&plic_toggle_lock);
+   raw_spin_lock(&handler->enable_lock);
if (enable)
writel(readl(reg) | hwirq_mask, reg);
else
writel(readl(reg) & ~hwirq_mask, reg);
-   raw_spin_unlock(&plic_toggle_lock);
+   raw_spin_unlock(&handler->enable_lock);
 }
 
 static inline void plic_irq_toggle(struct irq_data *d, int enable)
@@ -101,7 +92,7 @@ static inline void plic_irq_toggle(struct irq_data *d, int 
enable)
struct plic_handler *handler = per_cpu_ptr(&plic_handlers, cpu);
 
if (handler->present)
-   plic_toggle(handler->ctxid, d->hwirq, enable);
+   plic_toggle(handler, d->hwirq, enable);
}
 }
 
@@ -150,7 +141,7 @@ static struct irq_domain *plic_irqdomain;
 static void plic_handle_irq(struct pt_regs *regs)
 {
struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
-   void __iomem *claim = plic_hart_offset(handler->ctxid) + CONTEXT_CLAIM;
+   void __iomem *claim = handler->hart_base + CONTEXT_CLAIM;
irq_hw_number_t hwirq;
 
WARN_ON_ONCE(!handler->present);
@@ -239,12 +230,16 @@ static int __init plic_init(struct device_node *node,
cpu = riscv_hartid_to_cpuid(hartid);
handler = per_cpu_ptr(&plic_handlers, cpu);
handler->present = true;
-   handler->ctxid = i;
+   handler->hart_base =
+   plic_regs + CONTEXT_BASE + i * CONTEXT_PER_HART;
+   raw_spin_lock_init(&handler->enable_lock);
+   handler->enable_base =
+   plic_regs + ENABLE_BASE + i * ENABLE_PER_HART;
 
/* priority must be > threshold to trigger an interrupt */
-   writel(0, plic_hart_offset(i) + CONTEXT_THRESHOLD);
+   writel(0, handler->hart_base + CONTEXT_THRESHOLD);
for (hwirq = 1; hwirq <= nr_irqs; hwirq++)
-   plic_toggle(i, hwirq, 0);
+   plic_toggle(handler, hwirq, 0);
nr_mapped++;
}
 
-- 
2.17.1

[PATCH v4 0/5] IRQ affinity support in PLIC driver

[Anup Patel]

This patchset primarily adds IRQ affinity support in PLIC driver and
other improvements.

It gives mechanism for explicitly route external interrupts to particular
CPUs using smp_affinity attribute of each Linux IRQs. Also, we can now
use IRQ balancer from kernel-space or user-space.

The patchset is tested on QEMU virt machine. It is based on Linux-4.20
and can be found at riscv_plic_irq_affinity_v4 branch of:
https://github.com/avpatel/linux.git

Changes since v3:
 - Dropped PATCH2
 - Added PATCH to not inline plic_toggle() and plic_irq_toggle()
 - Moved PATCH3 changes to PATCH6
 - Used WARN_ON_ONCE() instead of WARN_ON() in PATCH5

Changes since v2:
 - Fixed incorrect address of enable registers using sizeof(u32) in PATCH1
 - Retained comment about need for locking in PATCH1
 - Split PATCH2 into two patches
 - Split PATCH3 into two patches
 - Minor fix in commit description of PATCH4

Changes since v1:
 - Removed few whitspace changes from PATCH1
 - Keep use of DEFINE_PER_CPU() as it is

Anup Patel (5):
  irqchip: sifive-plic: Pre-compute context hart base and enable base
  irqchip: sifive-plic: Don't inline plic_toggle() and plic_irq_toggle()
  irqchip: sifive-plic: Add warning in plic_init() if handler already
present
  irqchip: sifive-plic: Differentiate between PLIC handler and context
  irqchip: sifive-plic: Implement irq_set_affinity() for SMP host

 drivers/irqchip/irq-sifive-plic.c | 110 +++---
 1 file changed, 71 insertions(+), 39 deletions(-)

-- 
2.17.1

[PATCH 1/2] test_sysctl: add tests for >32-bit values written to 32-bit integers

[Zev Weiss]

At present this exposes a bug in do_proc_dointvec_minmax_conv() (it
fails to check for values that are too wide to fit in an int).

Signed-off-by: Zev Weiss 
---
 tools/testing/selftests/sysctl/sysctl.sh | 37 
 1 file changed, 37 insertions(+)

diff --git a/tools/testing/selftests/sysctl/sysctl.sh 
b/tools/testing/selftests/sysctl/sysctl.sh
index 584eb8ea780a..a7d0da25975c 100755
--- a/tools/testing/selftests/sysctl/sysctl.sh
+++ b/tools/testing/selftests/sysctl/sysctl.sh
@@ -290,6 +290,40 @@ run_numerictests()
test_rc
 }
 
+check_failure()
+{
+   echo -n "Testing that $1 fails as expected..."
+   reset_vals
+   TEST_STR="$1"
+   orig="$(cat $TARGET)"
+   echo -n "$TEST_STR" > $TARGET 2> /dev/null
+
+   # write should fail and $TARGET should retain its original value
+   if [ $? = 0 ] || [ "$(cat $TARGET)" != "$orig" ]; then
+   echo "FAIL" >&2
+   rc=1
+   else
+   echo "ok"
+   fi
+   test_rc
+}
+
+run_wideint_tests()
+{
+   # check negative and positive 64-bit values, with and without
+   # bits set in the lower 31, and with and without bit 31 (sign
+   # bit of a 32-bit int) set.  None of these are representable
+   # in 32 bits, and hence all should fail.
+   check_failure 0x0100
+   check_failure 0x01008000
+   check_failure 0x01ff7fff
+   check_failure 0x01ff
+   check_failure 0x7fff
+   check_failure 0x
+   check_failure 0xff00
+   check_failure 0xff008000
+}
+
 # Your test must accept digits 3 and 4 to use this
 run_limit_digit()
 {
@@ -556,6 +590,7 @@ sysctl_test_0001()
TEST_STR=$(( $ORIG + 1 ))
 
run_numerictests
+   run_wideint_tests
run_limit_digit
 }
 
@@ -580,6 +615,7 @@ sysctl_test_0003()
TEST_STR=$(( $ORIG + 1 ))
 
run_numerictests
+   run_wideint_tests
run_limit_digit
run_limit_digit_int
 }
@@ -592,6 +628,7 @@ sysctl_test_0004()
TEST_STR=$(( $ORIG + 1 ))
 
run_numerictests
+   run_wideint_tests
run_limit_digit
run_limit_digit_uint
 }
-- 
2.20.1

[PATCH 2/2] kernel/sysctl.c: define minmax conv functions in terms of non-minmax versions

[Zev Weiss]

do_proc_do[u]intvec_minmax_conv() had included open-coded versions of
do_proc_do[u]intvec_conv(), though the signed one omitted the check
that the value is in [INT_MIN, INT_MAX].  Rather than increase the
duplication further by copying the additional check, we can instead
refactor both to be defined in terms of their non-bounded counterparts
(plus the added check).

Signed-off-by: Zev Weiss 
---
 kernel/sysctl.c | 50 ++---
 1 file changed, 27 insertions(+), 23 deletions(-)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 5fc724e4e454..4a0261d32401 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2562,23 +2562,26 @@ static int do_proc_dointvec_minmax_conv(bool *negp, 
unsigned long *lvalp,
int *valp,
int write, void *data)
 {
+   int tmp, ret;
struct do_proc_dointvec_minmax_conv_param *param = data;
+
+   /*
+* First write to a temporary local int so we can bounds-check it
+* before touching *valp.
+*/
+   int *ip = write ? &tmp : valp;
+
+   ret = do_proc_dointvec_conv(negp, lvalp, ip, write, data);
+   if (ret)
+   return ret;
+
if (write) {
-   int val = *negp ? -*lvalp : *lvalp;
-   if ((param->min && *param->min > val) ||
-   (param->max && *param->max < val))
+   if ((param->min && *param->min > tmp) ||
+   (param->max && *param->max < tmp))
return -EINVAL;
-   *valp = val;
-   } else {
-   int val = *valp;
-   if (val < 0) {
-   *negp = true;
-   *lvalp = -(unsigned long)val;
-   } else {
-   *negp = false;
-   *lvalp = (unsigned long)val;
-   }
+   *valp = tmp;
}
+
return 0;
 }
 
@@ -2627,22 +2630,23 @@ static int do_proc_douintvec_minmax_conv(unsigned long 
*lvalp,
 unsigned int *valp,
 int write, void *data)
 {
+   int ret;
+   unsigned int tmp;
struct do_proc_douintvec_minmax_conv_param *param = data;
 
-   if (write) {
-   unsigned int val = *lvalp;
+   /* write via temporary local uint for bounds-checking */
+   unsigned int *up = write ? &tmp : valp;
 
-   if (*lvalp > UINT_MAX)
-   return -EINVAL;
+   ret = do_proc_douintvec_conv(lvalp, up, write, data);
+   if (ret)
+   return ret;
 
-   if ((param->min && *param->min > val) ||
-   (param->max && *param->max < val))
+   if (write) {
+   if ((param->min && *param->min > tmp) ||
+   (param->max && *param->max < tmp))
return -ERANGE;
 
-   *valp = val;
-   } else {
-   unsigned int val = *valp;
-   *lvalp = (unsigned long) val;
+   *valp = tmp;
}
 
return 0;
-- 
2.20.1

Re: ath10_pci: WARN(() on resume from S3

[DeX77]

Hi,



4.20.0 I see now two.

Also I see Unknown eventid: xxx and on 4.20.0
a unsupported HTC service id: xxx message(s).


I have a similar trace on my Dell XPS 13:

[31530.551292] ath10k_pci :3a:00.0: unsupported HTC service id: 1536
[31530.566621] ath10k_pci :3a:00.0: Unknown eventid: 118809
[31530.589165] WARNING: CPU: 0 PID: 6424 at 
drivers/net/wireless/ath/ath10k/mac.c:5687 
ath10k_bss_info_changed+0xad4/0xef0 [ath10k_core]
[31530.589166] Modules linked in: tun ctr ccm cmac bnep uvcvideo 
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev 
btusb media btrtl btbcm btintel bluetooth ecdh_generic crc16 af_packet 
joydev arc4 nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct 
xt_tcpudp xt_state xt_conntrack nf_conntrack nf_tables_set nf_defrag_ipv6 
nf_defrag_ipv4 iptable_filter nf_tables ip_tables x_tables nfnetlink 
snd_hda_codec_hdmi iTCO_wdt iTCO_vendor_support ath10k_pci 
i2c_designware_platform i2c_designware_core ath10k_core snd_soc_skl 
snd_soc_hdac_hda coretemp intel_rapl snd_hda_ext_core x86_pkg_temp_thermal 
intel_powerclamp snd_soc_skl_ipc kvm_intel snd_soc_sst_ipc snd_soc_sst_dsp 
ath snd_soc_acpi_intel_match snd_soc_acpi mac80211 dell_laptop kvm 
snd_soc_core nls_utf8 nls_cp437 snd_hda_codec_realtek vfat 
snd_hda_codec_generic fat snd_compress dell_wmi snd_pcm_dmaengine 
dell_smbios snd_hda_intel dcdbas cfg80211 snd_hda_codec irqbypass 
efi_pstore intel_wmi_thunderbolt rfkill
[31530.589196]  efivars snd_hda_core dell_wmi_descriptor wmi_bmof pcspkr 
hwmon rtsx_pci_ms ucsi_acpi snd_hwdep i2c_i801 memstick typec_ucsi thermal 
typec mei_wdt battery soc_button_array intel_vbtn evdev 
pinctrl_sunrisepoint mac_hid pinctrl_intel intel_hid 
processor_thermal_device int3403_thermal sparse_keymap int3400_thermal 
acpi_pad idma64 acpi_thermal_rel pcc_cpufreq int340x_thermal_zone ac button 
intel_soc_dts_iosf intel_pch_thermal intel_lpss_pci intel_lpss ppdev 
sch_fq_codel binfmt_misc btrfs libcrc32c crc32c_generic xor raid6_pq 
dm_crypt algif_skcipher af_alg hid_multitouch hid_generic usbhid i915 
rtsx_pci_sdmmc mmc_core intel_gtt i2c_algo_bit cec rc_core drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops drm crct10dif_pclmul xhci_pci 
xhci_hcd crc32_pclmul ghash_clmulni_intel aesni_intel usbcore aes_x86_64 
crypto_simd cryptd glue_helper serio_raw i2c_hid agpgart rtsx_pci hid 
i2c_core wmi video dm_mirror dm_region_hash dm_log dm_mod fuse crc32c_intel 
snd_pcm_oss snd_mixer_oss
[31530.589230]  snd_pcm snd_seq_oss snd_seq_midi_event snd_seq snd_timer 
snd_seq_device snd soundcore lp parport_pc parport efivarfs unix 
sha256_ssse3 sha256_generic sha1_ssse3 sha1_generic hmac ipv6 autofs4
[31530.589240] CPU: 0 PID: 6424 Comm: kworker/u8:4 Tainted: GW  
  4.20-fw1 #1
[31530.589241] Hardware name: Dell Inc. XPS 13 9360/06CC14, BIOS 2.9.0 
07/09/2018

[31530.589245] Workqueue: events_unbound async_run_entry_fn
[31530.589250] RIP: 0010:ath10k_bss_info_changed+0xad4/0xef0 [ath10k_core]
[31530.589251] Code: 00 00 e8 af 0c fc d1 e9 94 f8 ff ff 8b b5 68 01 00 00 
89 f2 89 c1 48 c7 c6 70 ef 0f c1 48 89 df e8 e1 35 00 00 e9 eb f5 ff ff 
<0f> 0b 4c 89 f7 e8 f2 8f 5b d2 e9 4f f9 ff ff 66 83 f8 0a 0f 85 27

[31530.589252] RSP: 0018:b733c428fcd8 EFLAGS: 00010282
[31530.589253] RAX: fffe RBX: 91ed1d781580 RCX: 

[31530.589254] RDX: 91ed1d7818f8 RSI: b733c428fcf8 RDI: 
91ed17073380
[31530.589255] RBP: 91ed17073380 R08: 0020 R09: 

[31530.589256] R10: 001f R11: 91eb26c1b600 R12: 
0020
[31530.589256] R13: 91ed17073388 R14: 91ed1d782558 R15: 
91ed1d781580
[31530.589258] FS:  () GS:91ed2e20() 
knlGS:

[31530.589258] CS:  0010 DS:  ES:  CR0: 80050033
[31530.589259] CR2: 56125129f4d6 CR3: 0002b200a002 CR4: 
003606f0

[31530.589260] Call Trace:
[31530.589266]  ? ath10k_conf_tx+0x12d/0x4c0 [ath10k_core]
[31530.589284]  ieee80211_bss_info_change_notify+0xa9/0x1c0 [mac80211]
[31530.589297]  ieee80211_reconfig+0xa4f/0x1560 [mac80211]
[31530.589313]  wiphy_resume+0x7e/0x150 [cfg80211]
[31530.589322]  ? wiphy_namespace+0x10/0x10 [cfg80211]
[31530.589325]  dpm_run_callback+0x2e/0x130
[31530.589327]  device_resume+0x97/0x190
[31530.589329]  async_resume+0x19/0x40
[31530.589331]  async_run_entry_fn+0x37/0xe0
[31530.589334]  process_one_work+0x1e9/0x410
[31530.589336]  worker_thread+0x2d/0x3d0
[31530.589338]  ? process_one_work+0x410/0x410
[31530.589340]  kthread+0x113/0x130
[31530.589341]  ? kthread_park+0x90/0x90
[31530.589344]  ret_from_fork+0x35/0x40
[31530.589346] ---[ end trace e8c7a75d6d802f88 ]---


Please keep me CC, as I'm currently not subscribed. Thx.

Greetings
DeX

[PATCH 0/2] sysctl: fix range-checking in do_proc_dointvec_minmax_conv()

[Zev Weiss]

Hello,

After being left with an unusable system after a typo executing
something like 'echo $((1<<24)) > /proc/sys/vm/max_map_count', I found
that do_proc_dointvec_minmax_conv() was missing a check to ensure that
the converted value actually fits in an int.

The first of the following patches enhances the sysctl selftest such
that it detects this problem; the second fixes it (wasn't entirely
sure if this would meet the criteria of something that should be sent
to -stable; input welcome).


Thanks,
Zev Weiss

Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting

[Christian Borntraeger]

This patch triggers random crashes in the guest kernel on s390 early during 
boot.
No migration and no setting of the balloon is involved.




On 27.08.2018 03:32, Wei Wang wrote:
> The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this
> series enables the virtio-balloon driver to report hints of guest free
> pages to host. It can be used to accelerate virtual machine (VM) live
> migration. Here is an introduction of this usage:
> 
> Live migration needs to transfer the VM's memory from the source machine
> to the destination round by round. For the 1st round, all the VM's memory
> is transferred. From the 2nd round, only the pieces of memory that were
> written by the guest (after the 1st round) are transferred. One method
> that is popularly used by the hypervisor to track which part of memory is
> written is to have the hypervisor write-protect all the guest memory.
> 
> This feature enables the optimization by skipping the transfer of guest
> free pages during VM live migration. It is not concerned that the memory
> pages are used after they are given to the hypervisor as a hint of the
> free pages, because they will be tracked by the hypervisor and transferred
> in the subsequent round if they are used and written.
> 
> * Tests
> 1 Test Environment
> Host: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
> Migration setup: migrate_set_speed 100G, migrate_set_downtime 400ms
> 
> 2 Test Results (results are averaged over several repeated runs)
> 2.1 Guest setup: 8G RAM, 4 vCPU
> 2.1.1 Idle guest live migration time
> Optimization v.s. Legacy = 620ms vs 2970ms
> --> ~79% reduction
> 2.1.2 Guest live migration with Linux compilation workload
>   (i.e. make bzImage -j4) running
>   1) Live Migration Time:
>  Optimization v.s. Legacy = 2273ms v.s. 4502ms
>  --> ~50% reduction
>   2) Linux Compilation Time:
>  Optimization v.s. Legacy = 8min42s v.s. 8min43s
>  --> no obvious difference
> 
> 2.2 Guest setup: 128G RAM, 4 vCPU
> 2.2.1 Idle guest live migration time
> Optimization v.s. Legacy = 5294ms vs 41651ms
> --> ~87% reduction
> 2.2.2 Guest live migration with Linux compilation workload
>   1) Live Migration Time:
> Optimization v.s. Legacy = 8816ms v.s. 54201ms
> --> 84% reduction
>   2) Linux Compilation Time:
>  Optimization v.s. Legacy = 8min30s v.s. 8min36s
>  --> no obvious difference
> 
> ChangeLog:
> v36->v37:
> - free the reported pages to mm when receives a DONE cmd from host.
>   Please see patch 1's commit log for reasons. Please see patch 1's
>   commit for detailed explanations.
> 
> For ChangeLogs from v22 to v36, please reference
> https://lkml.org/lkml/2018/7/20/199
> 
> For ChangeLogs before v21, please reference
> https://lwn.net/Articles/743660/
> 
> Wei Wang (3):
>   virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
>   mm/page_poison: expose page_poisoning_enabled to kernel modules
>   virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
> 
>  drivers/virtio/virtio_balloon.c | 374 
> 
>  include/uapi/linux/virtio_balloon.h |   8 +
>  mm/page_poison.c|   6 +
>  3 files changed, 355 insertions(+), 33 deletions(-)
> 

bug report: hugetlbfs: use i_mmap_rwsem for more pmd sharing, synchronization

[Colin Ian King]

Hi,

Static analysis with CoverityScan on linux-next detected a potential
null pointer dereference with the following commit:

>From d8a1051ed4ba55679ef24e838a1942c9c40f0a14 Mon Sep 17 00:00:00 2001
From: Mike Kravetz 
Date: Sat, 22 Dec 2018 10:55:57 +1100
Subject: [PATCH] hugetlbfs: use i_mmap_rwsem for more pmd sharing

The earlier check implies that "mapping" may be a null pointer:

var_compare_op: Comparing mapping to null implies that mapping might be
null.

1008if (!(flags & MF_MUST_KILL) && !PageDirty(hpage) && mapping &&
1009mapping_cap_writeback_dirty(mapping)) {

..however later "mapper" is dereferenced when it may be potentially null:

1034/*
1035 * For hugetlb pages, try_to_unmap could potentially
call
1036 * huge_pmd_unshare.  Because of this, take semaphore in
1037 * write mode here and set TTU_RMAP_LOCKED to
indicate we
1038 * have taken the lock at this higer level.
1039 */
CID 1476097 (#1 of 1): Dereference after null check (FORWARD_NULL)

var_deref_model: Passing null pointer mapping to
i_mmap_lock_write, which dereferences it.

1040i_mmap_lock_write(mapping);
1041unmap_success = try_to_unmap(hpage,
ttu|TTU_RMAP_LOCKED);
1042i_mmap_unlock_write(mapping);


Colin

Re: [PATCH] drm/drm_drv.c: Remove duplicate header

[Daniel Vetter]

On Mon, Dec 24, 2018 at 08:06:36PM +0530, Brajeswar Ghosh wrote:
> Remove drm_crtc_internal.h which is included more than once
> 
> Signed-off-by: Brajeswar Ghosh 

Applied, thanks for your patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 4126bb6e1a4a..75f4e6bf67ca 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -41,7 +41,6 @@
>  #include "drm_crtc_internal.h"
>  #include "drm_legacy.h"
>  #include "drm_internal.h"
> -#include "drm_crtc_internal.h"
>  
>  /*
>   * drm_debug: Enable debug output.
> -- 
> 2.17.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip

[Eric Wong]

I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
chipset) and hit some kernel panics while trying to view
image/animation-intensive stuff in Firefox (X11) unless I use
"iommu_intel=igfx_off".

With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
(4.17.17-1~bpo9+1) has no problems.  But "linux-image-4.18.0-0.bpo.3-amd64"
(4.18.20-2~bpo9+1) gives a blank screen before I can login via agetty
and run startx.

Building 4.19.12 myself got me into X11 and able to start
Firefox to panic the kernel.  I also updated to the latest BIOS
(1.40), but it's an EOL laptop (but it's still the most powerful
laptop I use).  I intend to replace the BIOS with Coreboot soon...

Initially, I thought I was hitting another GPU hang from 4.18+:

https://bugs.freedesktop.org/show_bug.cgi?id=107945

But building drm-tip @ commit 28bb1fc015cedadf3b099b8bd0bb27609849f362
("drm-tip: 2018y-12m-25d-08h-12m-37s UTC integration manifest")
I was still able to reproduce the panic unless I use iommu_intel=igfx_off
"i915.reset=1" did not help matters, either.

Below is what I got from netconsole while on drm-tip:

Kernel panic - not syncing: DMAR hardware is malfunctioning
Shutting down cpus with NMI
Kernel Offset: disabled
---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]---
[ cut here ]
sched: Unexpected reschedule of offline CPU#3!
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
Modules linked in: netconsole ccm snd_hda_codec_hdmi snd_hda_codec_conexant 
snd_hda_codec_generic intel_powerclamp coretemp kvm_intel kvm irqbypass 
crc32_pclmul crc32c_intel ghash_clmulni_intel arc4 iwldvm aesni_intel 
aes_x86_64 crypto_simd cryptd mac80211 glue_helper intel_cstate iwlwifi 
intel_uncore i915 intel_gtt i2c_algo_bit iosf_mbi drm_kms_helper cfbfillrect 
syscopyarea intel_ips cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea 
thinkpad_acpi prime_numbers cfg80211 ledtrig_audio i2c_i801 sg snd_hda_intel 
led_class snd_hda_codec drm ac drm_panel_orientation_quirks snd_hwdep battery 
e1000e agpgart snd_hda_core snd_pcm snd_timer ptp snd soundcore pps_core 
ehci_pci ehci_hcd lpc_ich video mfd_core button acpi_cpufreq ecryptfs ip_tables 
x_tables ipv6 evdev thermal [last unloaded: netconsole]
CPU: 0 PID: 105 Comm: kworker/u8:3 Not tainted 4.20.0-rc7b1+ #1
Hardware name: LENOVO 3680FBU/3680FBU, BIOS 6QET70WW (1.40 ) 10/11/2012
Workqueue: i915 __i915_gem_free_work [i915]
RIP: 0010:native_smp_send_reschedule+0x34/0x40
Code: 05 69 c6 c9 00 73 15 48 8b 05 18 2d b3 00 be fd 00 00 00 48 8b 40 30 e9 
9a 58 7d 00 89 fe 48 c7 c7 78 73 af 81 e8 dc c2 01 00 <0f> 0b c3 66 0f 1f 84 00 
00 00 00 00 66 66 66 66 90 8b 05 0d 7d df
RSP: 0018:888075003d98 EFLAGS: 00010092
RAX: 002e RBX: 8880751a0740 RCX: 0006
RDX: 0007 RSI: 0082 RDI: 888075015440
RBP: 88806e823700 R08:  R09: 888072fc07c0
R10: 888075003d60 R11: fff5c002 R12: 8880751a0740
R13: 8880751a0740 R14:  R15: 0003
FS:  () GS:88807500() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fdb1f53f000 CR3: 01c0a004 CR4: 000206f0
Call Trace:
 
 ? check_preempt_curr+0x4e/0x90
 ? ttwu_do_wakeup.isra.19+0x14/0xf0
 ? try_to_wake_up+0x323/0x410
 ? autoremove_wake_function+0xe/0x30
 ? __wake_up_common+0x8d/0x140
 ? __wake_up_common_lock+0x6c/0x90
 ? irq_work_run_list+0x49/0x80
 ? tick_sched_handle.isra.6+0x50/0x50
 ? update_process_times+0x3b/0x50
 ? tick_sched_handle.isra.6+0x30/0x50
 ? tick_sched_timer+0x3b/0x80
 ? __hrtimer_run_queues+0xea/0x270
 ? hrtimer_interrupt+0x101/0x240
 ? smp_apic_timer_interrupt+0x6a/0x150
 ? apic_timer_interrupt+0xf/0x20
 
 ? panic+0x1ca/0x212
 ? panic+0x1c7/0x212
 ? __iommu_flush_iotlb+0x19e/0x1c0
 ? iommu_flush_iotlb_psi+0x96/0xf0
 ? intel_unmap+0xbf/0xf0
 ? i915_gem_object_put_pages_gtt+0x36/0x220 [i915]
 ? drm_ht_remove+0x20/0x20 [drm]
 ? drm_mm_remove_node+0x1ad/0x310 [drm]
 ? __pm_runtime_resume+0x54/0x70
 ? __i915_gem_object_unset_pages+0x129/0x170 [i915]
 ? __i915_gem_object_put_pages+0x70/0xa0 [i915]
 ? __i915_gem_free_objects+0x245/0x4e0 [i915]
 ? __switch_to_asm+0x24/0x60
 ? __i915_gem_free_work+0x65/0xa0 [i915]
 ? process_one_work+0x1fd/0x410
 ? worker_thread+0x49/0x3f0
 ? kthread+0xf8/0x130
 ? process_one_work+0x410/0x410
 ? kthread_park+0x90/0x90
 ? ret_from_fork+0x35/0x40
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
---[ end trace 7dd2184d8c86cef5 ]---
[ cut here ]
sched: Unexpected reschedule of offline CPU#2!
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
Modules linked in: netconsole ccm snd_hda_codec_hdmi snd_hda_codec_conexant 
snd_hda_codec_generic intel_powerclamp coretemp kvm_intel kvm irqbypass 
crc32_pclmul crc32c_intel ghash_clmulni_intel arc4 iwldvm aesni_intel 
aes_x86_64 crypto_simd cryptd mac80211 glue

Re: [PATCH 2/3] drm/amd: validate user pitch alignment

[Michel Dänzer]

On 2018-12-23 10:44 p.m., Yu Zhao wrote:
> On Fri, Dec 21, 2018 at 10:07:26AM +0100, Michel Dänzer wrote:
>> On 2018-12-21 4:10 a.m., Yu Zhao wrote:
>>> Userspace may request pitch alignment that is not supported by GPU.
>>> Some requests 32, but GPU ignores it and uses default 64 when cpp is
>>> 4. If GEM object is allocated based on the smaller alignment, GPU
>>> DMA will go out of bound.
>>>
>>> For GPU that does frame buffer compression, DMA writing out of bound
>>> memory will cause memory corruption.
>>>
>>> Signed-off-by: Yu Zhao 
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 +
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> index e309d26170db..755daa332f8a 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> @@ -527,6 +527,15 @@ amdgpu_display_user_framebuffer_create(struct 
>>> drm_device *dev,
>>> struct drm_gem_object *obj;
>>> struct amdgpu_framebuffer *amdgpu_fb;
>>> int ret;
>>> +   struct amdgpu_device *adev = dev->dev_private;
>>> +   int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
>>> +   int pitch = amdgpu_align_pitch(adev, mode_cmd->width, cpp, false);
>>
>> Also, this needs to use mode_cmd->pitches[0] instead of mode_cmd->width,
>> otherwise it'll spuriously fail for larger but well-aligned pitches.
> 
> Actually mode_cmd->pitches[0] is aligned mode_cmd->width multiplied
> by cpp. So we can't just use mode_cmd->pitches[0].

Use mode_cmd->pitches[0] / cpp then?


> And I'm not sure if the hardware works with larger alignment

It does.

> (it certainly ignores smaller alignment).

Yeah, pitch must be >= width. Maybe this patch could check that as well.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [PATCH 2/3] dt-bindings: gpu: samsung-rotator: Document s5pv210 support

[Paweł Chmiel]

Dnia środa, 19 grudnia 2018 17:22:51 CET Krzysztof Kozlowski pisze:
> On Wed, 19 Dec 2018 at 17:04, Paweł Chmiel
>  wrote:
> >
> > This commit documents new compatible for s5pv210 soc,
> > which will be also supported by this driver.
> >
> > Signed-off-by: Paweł Chmiel 
> > ---
> >  Documentation/devicetree/bindings/gpu/samsung-rotator.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt 
> > b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> > index 82cd1ed0be93..78658dec6941 100644
> > --- a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> > +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> > @@ -5,6 +5,7 @@ Required properties:
> > (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
> > (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
> > (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250
> > +   (d) "samsung,s5pv210-rotator" for Rotator IP in S5PV210
> 
> How about putting it at beginning as the oldest chipset? This would
> require reordering the list so maybe let's remove the a/b/c list
> enumerations? They are kind of useless.
Ok, i'll send v2 of patchset with this change.
> 
> Best regards,
> Krzysztof

[GIT PULL] Please pull powerpc/linux.git powerpc-4.21-1 tag

[Michael Ellerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Linus,

Please pull powerpc updates for 4.21:

The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:

  Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.21-1

for you to fetch changes up to 12526b0d6c580df860b31e59d68e5696e16c6e5b:

  Merge branch 'next' of 
https://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux into next 
(2018-12-24 14:14:45 +1100)


There are two conflicts I'm aware of.

The first is in arch/powerpc/mm/fault.c, the resolution is to add the 0xe00 case
to the switch and use the pr_alert() version of the printk.

The other is in arch/powerpc/kernel/iommu.c, where we deleted some code that was
modified in the iommu tree to use a new accessor.

cheers

- --
powerpc updates for 4.21

Notable changes:

 - Mitigations for Spectre v2 on some Freescale (NXP) CPUs.

 - A large series adding support for pass-through of Nvidia V100 GPUs to guests
   on Power9.

 - Another large series to enable hardware assistance for TLB table walk on
   MPC8xx CPUs.

 - Some preparatory changes to our DMA code, to make way for further cleanups
   from Christoph.

 - Several fixes for our Transactional Memory handling discovered by fuzzing the
   signal return path.

 - Support for generating our system call table(s) from a text file like other
   architectures.

 - A fix to our page fault handler so that instead of generating a WARN_ON_ONCE,
   user accesses of kernel addresses instead print a ratelimited and
   appropriately scary warning.

 - A cosmetic change to make our unhandled page fault messages more similar to
   other arches and also more compact and informative.

 - Freescale updates from Scott:
   "Highlights include elimination of legacy clock bindings use from dts
files, an 83xx watchdog handler, fixes to old dts interrupt errors, and
some minor cleanup."

And many clean-ups, reworks and minor fixes etc.

Thanks to:
 Alexandre Belloni, Alexey Kardashevskiy, Andrew Donnellan, Aneesh Kumar K.V,
 Arnd Bergmann, Benjamin Herrenschmidt, Breno Leitao, Christian Lamparter,
 Christophe Leroy, Christoph Hellwig, Daniel Axtens, Darren Stevens, David
 Gibson, Diana Craciun, Dmitry V. Levin, Firoz Khan, Geert Uytterhoeven, Greg
 Kurz, Gustavo Romero, Hari Bathini, Joel Stanley, Kees Cook, Madhavan
 Srinivasan, Mahesh Salgaonkar, Markus Elfring, Mathieu Malaterre, Michal
 Suchánek, Naveen N. Rao, Nick Desaulniers, Oliver O'Halloran, Paul Mackerras,
 Ram Pai, Ravi Bangoria, Rob Herring, Russell Currey, Sabyasachi Gupta, Sam
 Bobroff, Satheesh Rajendran, Scott Wood, Segher Boessenkool, Stephen Rothwell,
 Tang Yuantian, Thiago Jung Bauermann, Yangtao Li, Yuantian Tang, Yue Haibing.

- --
Alexandre Belloni (2):
  powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"
  powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"

Alexey Kardashevskiy (26):
  powerpc/powernv/ioda: Allocate indirect TCE levels of cached userspace 
addresses on demand
  powerpc/powernv/npu: Remove unused headers and a macro.
  vfio/spapr_tce: Get rid of possible infinite loop
  powerpc/powernv/ioda1: Remove dead code for a single device PE
  powerpc/powernv/ioda: Reduce a number of hooks in pnv_phb
  powerpc/powernv/eeh/npu: Fix uninitialized variables in 
opal_pci_eeh_freeze_status
  powerpc/ioda/npu: Call skiboot's hot reset hook when disabling NPU2
  powerpc/mm/iommu/vfio_spapr_tce: Change mm_iommu_get to reference a region
  powerpc/vfio/iommu/kvm: Do not pin device memory
  powerpc/powernv: Move npu struct from pnv_phb to pci_controller
  powerpc/powernv/npu: Move OPAL calls away from context manipulation
  powerpc/pseries/iommu: Use memory@ nodes in max RAM address calculation
  powerpc/pseries/npu: Enable platform support
  powerpc/pseries: Remove IOMMU API support for non-LPAR systems
  powerpc/powernv/pseries: Rework device adding to IOMMU groups
  powerpc/iommu_api: Move IOMMU groups setup to a single place
  powerpc/powernv: Reference iommu_table while it is linked to a group
  powerpc/powernv/npu: Move single TVE handling to NPU PE
  powerpc/powernv/npu: Convert NPU IOMMU helpers to iommu_table_group_ops
  powerpc/powernv/npu: Add compound IOMMU groups
  powerpc/powernv/npu: Add release_ownership hook
  powerpc/powernv/npu: Check mmio_atsd array bounds when populating
  powerpc/powernv/npu: Fault user page into the hypervisor's pagetable
  vfio_pci: Allow mapping extra regions
  vfio_pci: Allow regions to add own capabilities
  vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver

Aneesh Kumar K.V (1):
  powerpc/mm/hash: Handle user access of kernel address gracef

Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting

[Christian Borntraeger]

On 27.12.2018 12:31, Christian Borntraeger wrote:
> This patch triggers random crashes in the guest kernel on s390 early during 
> boot.
> No migration and no setting of the balloon is involved.
> 

Adding Conny and Halil,

As the QEMU provides no PAGE_HINT feature yet, this quick hack makes the
guest boot fine again:


diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 728ecd1eea305..aa2e1864c5736 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -492,7 +492,7 @@ static int init_vqs(struct virtio_balloon *vb)
callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
}
 
-   err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
+   err = vb->vdev->config->find_vqs(vb->vdev, 3, //VIRTIO_BALLOON_VQ_MAX,
 vqs, callbacks, names, NULL, NULL);
if (err)
return err;


To me it looks like that virtio_ccw_find_vqs will abort if any of the 
virtqueues 
that it is been asked for does not exist (including the earlier ones).


Christian

> 
> On 27.08.2018 03:32, Wei Wang wrote:
>> The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this
>> series enables the virtio-balloon driver to report hints of guest free
>> pages to host. It can be used to accelerate virtual machine (VM) live
>> migration. Here is an introduction of this usage:
>>
>> Live migration needs to transfer the VM's memory from the source machine
>> to the destination round by round. For the 1st round, all the VM's memory
>> is transferred. From the 2nd round, only the pieces of memory that were
>> written by the guest (after the 1st round) are transferred. One method
>> that is popularly used by the hypervisor to track which part of memory is
>> written is to have the hypervisor write-protect all the guest memory.
>>
>> This feature enables the optimization by skipping the transfer of guest
>> free pages during VM live migration. It is not concerned that the memory
>> pages are used after they are given to the hypervisor as a hint of the
>> free pages, because they will be tracked by the hypervisor and transferred
>> in the subsequent round if they are used and written.
>>
>> * Tests
>> 1 Test Environment
>> Host: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
>> Migration setup: migrate_set_speed 100G, migrate_set_downtime 400ms
>>
>> 2 Test Results (results are averaged over several repeated runs)
>> 2.1 Guest setup: 8G RAM, 4 vCPU
>> 2.1.1 Idle guest live migration time
>> Optimization v.s. Legacy = 620ms vs 2970ms
>> --> ~79% reduction
>> 2.1.2 Guest live migration with Linux compilation workload
>>   (i.e. make bzImage -j4) running
>>   1) Live Migration Time:
>>  Optimization v.s. Legacy = 2273ms v.s. 4502ms
>>  --> ~50% reduction
>>   2) Linux Compilation Time:
>>  Optimization v.s. Legacy = 8min42s v.s. 8min43s
>>  --> no obvious difference
>>
>> 2.2 Guest setup: 128G RAM, 4 vCPU
>> 2.2.1 Idle guest live migration time
>> Optimization v.s. Legacy = 5294ms vs 41651ms
>> --> ~87% reduction
>> 2.2.2 Guest live migration with Linux compilation workload
>>   1) Live Migration Time:
>> Optimization v.s. Legacy = 8816ms v.s. 54201ms
>> --> 84% reduction
>>   2) Linux Compilation Time:
>>  Optimization v.s. Legacy = 8min30s v.s. 8min36s
>>  --> no obvious difference
>>
>> ChangeLog:
>> v36->v37:
>> - free the reported pages to mm when receives a DONE cmd from host.
>>   Please see patch 1's commit log for reasons. Please see patch 1's
>>   commit for detailed explanations.
>>
>> For ChangeLogs from v22 to v36, please reference
>> https://lkml.org/lkml/2018/7/20/199
>>
>> For ChangeLogs before v21, please reference
>> https://lwn.net/Articles/743660/
>>
>> Wei Wang (3):
>>   virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
>>   mm/page_poison: expose page_poisoning_enabled to kernel modules
>>   virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
>>
>>  drivers/virtio/virtio_balloon.c | 374 
>> 
>>  include/uapi/linux/virtio_balloon.h |   8 +
>>  mm/page_poison.c|   6 +
>>  3 files changed, 355 insertions(+), 33 deletions(-)
>>

Re: [RFC PATCH 1/2] drm/fb-helper: Bring back workaround for bugs of SDL 1.2

[Daniel Vetter]

On Wed, Dec 26, 2018 at 05:11:23PM +0500, Ivan Mironov wrote:
> SDL 1.2 sets all fields related to the pixel format to zero in some
> cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
> pixel format changing requests"), there was an unintentional workaround
> for this that existed for more than a decade. First in device-specific DRM
> drivers, then here in drm_fb_helper.c.
> 
> Previous code containing this workaround just ignores pixel format fields
> from userspace code. Not a good thing either, as this way, driver may
> silently use pixel format different from what client actually requested,
> and this in turn will lead to displaying garbage on the screen. I think
> that returning EINVAL to userspace in this particular case is the right
> option, so I decided to left code from problematic commit untouched
> instead of just reverting it entirely.
> 
> [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c,
> FB_SetVideoMode()
> 
> Reported-by: saahriktu 
> Suggested-by: saahriktu 
> Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing 
> requests")
> Signed-off-by: Ivan Mironov 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 146 
>  1 file changed, 93 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index d3af098b0922..aff576c3c4fb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1621,6 +1621,64 @@ static bool drm_fb_pixel_format_equal(const struct 
> fb_var_screeninfo *var_1,
>  var_1->transp.msb_right == var_2->transp.msb_right;
>  }
>  
> +static void drm_fb_helper_fill_pixel_fmt(struct fb_var_screeninfo *var,
> +  u8 depth)
> +{
> + switch (depth) {
> + case 8:
> + var->red.offset = 0;
> + var->green.offset = 0;
> + var->blue.offset = 0;
> + var->red.length = 8; /* 8bit DAC */
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 0;
> + var->transp.length = 0;
> + break;
> + case 15:
> + var->red.offset = 10;
> + var->green.offset = 5;
> + var->blue.offset = 0;
> + var->red.length = 5;
> + var->green.length = 5;
> + var->blue.length = 5;
> + var->transp.offset = 15;
> + var->transp.length = 1;
> + break;
> + case 16:
> + var->red.offset = 11;
> + var->green.offset = 5;
> + var->blue.offset = 0;
> + var->red.length = 5;
> + var->green.length = 6;
> + var->blue.length = 5;
> + var->transp.offset = 0;
> + break;
> + case 24:
> + var->red.offset = 16;
> + var->green.offset = 8;
> + var->blue.offset = 0;
> + var->red.length = 8;
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 0;
> + var->transp.length = 0;
> + break;
> + case 32:
> + var->red.offset = 16;
> + var->green.offset = 8;
> + var->blue.offset = 0;
> + var->red.length = 8;
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 24;
> + var->transp.length = 8;
> + break;
> + default:
> + break;
> + }
> +}
> +
>  /**
>   * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
>   * @var: screeninfo to check
> @@ -1654,6 +1712,40 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
> *var,
>   return -EINVAL;
>   }
>  
> + /*
> +  * Workaround for SDL 1.2, which is known to be setting all pixel format
> +  * fields values to zero in some cases. We treat this situation as a
> +  * kind of "use some reasonable autodetected values".
> +  */
> + if (!var->red.offset && !var->green.offset&&
> + !var->blue.offset&& !var->transp.offset   &&
> + !var->red.length && !var->green.length&&
> + !var->blue.length&& !var->transp.length   &&
> + !var->red.msb_right  && !var->green.msb_right &&
> + !var->blue.msb_right && !var->transp.msb_right) {
> + u8 depth;
> +
> + /*
> +  * There is no way to guess the right value for depth when
> +  * bpp is 16 or 32. So we just restore the behaviour previously
> +  * introduced here by commit 785b93ef8c309. In fact, this was
> +  * implemented even earlier in various device drivers.
> +  */
> + switch (var->bits_per_pixel) {
> + case 16:
> + depth = 15;
> + break;
> + case 32:
> +   

Re: [PATCH v37 1/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

[Christian Borntraeger]

On 27.08.2018 03:32, Wei Wang wrote:
>  static int init_vqs(struct virtio_balloon *vb)
>  {
> - struct virtqueue *vqs[3];
> - vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request 
> };
> - static const char * const names[] = { "inflate", "deflate", "stats" };
> - int err, nvqs;
> + struct virtqueue *vqs[VIRTIO_BALLOON_VQ_MAX];
> + vq_callback_t *callbacks[VIRTIO_BALLOON_VQ_MAX];
> + const char *names[VIRTIO_BALLOON_VQ_MAX];
> + int err;
> 
>   /*
> -  * We expect two virtqueues: inflate and deflate, and
> -  * optionally stat.
> +  * Inflateq and deflateq are used unconditionally. The names[]
> +  * will be NULL if the related feature is not enabled, which will
> +  * cause no allocation for the corresponding virtqueue in find_vqs.
>*/

This might be true for virtio-pci, but it is not for virtio-ccw.

> - nvqs = virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ) ? 3 : 2;
> - err = virtio_find_vqs(vb->vdev, nvqs, vqs, callbacks, names, NULL);
> + callbacks[VIRTIO_BALLOON_VQ_INFLATE] = balloon_ack;
> + names[VIRTIO_BALLOON_VQ_INFLATE] = "inflate";
> + callbacks[VIRTIO_BALLOON_VQ_DEFLATE] = balloon_ack;
> + names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
> + names[VIRTIO_BALLOON_VQ_STATS] = NULL;
> + names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> +
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> + names[VIRTIO_BALLOON_VQ_STATS] = "stats";
> + callbacks[VIRTIO_BALLOON_VQ_STATS] = stats_request;
> + }
> +
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
> + names[VIRTIO_BALLOON_VQ_FREE_PAGE] = "free_page_vq";
> + callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> + }
> +
> + err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
[...]

Re: [PATCH v1 1/7] drm: move DRM_IF_VERSION to drm_internal.h

[Daniel Vetter]

On Wed, Dec 26, 2018 at 10:03:47PM +0100, Sam Ravnborg wrote:
> Move DRM_IF_VERSION out of drmP.h to allow users
> to get rid of the drmP include.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 

Applied to drm-misc-next, thanks for your patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_internal.h | 2 ++
>  include/drm/drmP.h | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 51e06defc8d8..e9374cd43610 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -26,6 +26,8 @@
>  #define DRM_IF_MAJOR 1
>  #define DRM_IF_MINOR 4
>  
> +#define DRM_IF_VERSION(maj, min) (maj << 16 | min)
> +
>  struct drm_prime_file_private;
>  struct dma_buf;
>  
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 05350424a4d3..b6b8436b5123 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -95,8 +95,6 @@ struct dma_buf_attachment;
>  struct pci_dev;
>  struct pci_controller;
>  
> -#define DRM_IF_VERSION(maj, min) (maj << 16 | min)
> -
>  #define DRM_SWITCH_POWER_ON 0
>  #define DRM_SWITCH_POWER_OFF 1
>  #define DRM_SWITCH_POWER_CHANGING 2
> -- 
> 2.12.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v1 2/7] drm: move DRM_SWITCH_POWER defines to drm_device.h

[Daniel Vetter]

On Wed, Dec 26, 2018 at 10:03:48PM +0100, Sam Ravnborg wrote:
> Move DRM_SWITCH_POWER out of drmP.h to allow users
> to get rid of the drmP include.
> 
> DRM_SWITCH_POWER defines are used in combination
> with drm_device.switch_power_state.
> 
> Move the DRM_SWITCH_POWER defines to the file where
> drm_device.switch_power_state is defined.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> ---
>  include/drm/drmP.h   | 5 -
>  include/drm/drm_device.h | 9 +
>  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index b6b8436b5123..2ba786820052 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -95,11 +95,6 @@ struct dma_buf_attachment;
>  struct pci_dev;
>  struct pci_controller;
>  
> -#define DRM_SWITCH_POWER_ON 0
> -#define DRM_SWITCH_POWER_OFF 1
> -#define DRM_SWITCH_POWER_CHANGING 2
> -#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
> -
>  /* returns true if currently okay to sleep */
>  static inline bool drm_can_sleep(void)
>  {
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 42411b3ea0c8..c3da194d25f9 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -24,6 +24,13 @@ struct inode;
>  struct pci_dev;
>  struct pci_controller;
>  
> +
> +/* Used by drm_device.switch_power_state */
> +#define DRM_SWITCH_POWER_ON 0
> +#define DRM_SWITCH_POWER_OFF 1
> +#define DRM_SWITCH_POWER_CHANGING 2
> +#define DRM_SWITCH_POWER_DYNAMIC_OFF 3

Since this isn't uapi it'd be nice to change it to an enum, which we can
then properly kernel-doc and make your references links in the resulting
html. Otherwise lgtm.

Would need an include stanza for drm_device.h in drm-internals.rst, plus a
bit of kernel-doc cleanup in here I think (which iirc is why I didn't yet
do this).
-Daniel

> +
>  /**
>   * DRM device structure. This structure represent a complete card that
>   * may contain multiple heads.
> @@ -222,6 +229,8 @@ struct drm_device {
>   struct idr object_name_idr;
>   struct drm_vma_offset_manager *vma_offset_manager;
>   /*@} */
> +
> + /* See DRM_SWITCH_POWER defines */
>   int switch_power_state;
>  
>   /**
> -- 
> 2.12.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v1 3/7] drm: move drm_can_sleep() to drm_util.h

[Daniel Vetter]

On Wed, Dec 26, 2018 at 10:03:49PM +0100, Sam Ravnborg wrote:
> Move drm_can_sleep() out of drmP.h to allow users
> to get rid of the drmP.h include.
> 
> There was no header file that was a good match for this helper function.
> So add this to drm_util with the relevant includes.
> 
> Add include of drm_util.h to all users.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Gerd Hoffmann 
> Cc: Rob Clark 
> Cc: Tomi Valkeinen 
> Cc: Eric Anholt 
> ---
>  drivers/gpu/drm/amd/amdgpu/atom.c   |  2 ++
>  drivers/gpu/drm/ast/ast_fb.c|  1 +
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c   |  1 +
>  drivers/gpu/drm/drm_flip_work.c |  1 +
>  drivers/gpu/drm/mgag200/mgag200_fb.c|  1 +
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  1 +
>  drivers/gpu/drm/omapdrm/omap_fbdev.c|  1 +
>  drivers/gpu/drm/qxl/qxl_cmd.c   |  2 ++
>  drivers/gpu/drm/radeon/atom.c   |  2 ++
>  drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  1 +
>  drivers/gpu/drm/vc4/vc4_drv.h   |  1 +
>  include/drm/drmP.h  |  8 
>  include/drm/drm_util.h  | 13 +
>  13 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index e9934de1b9cf..dd30f4e61a8c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #define ATOM_DEBUG
>  
>  #include "atom.h"
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index de26df0c6044..fb56fe848e81 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -38,6 +38,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "ast_drv.h"
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 68ab1821e15b..1544fa55d1ff 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -10,6 +10,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/drm_flip_work.c b/drivers/gpu/drm/drm_flip_work.c
> index 12dea16f22a8..3da3bf5af405 100644
> --- a/drivers/gpu/drm/drm_flip_work.c
> +++ b/drivers/gpu/drm/drm_flip_work.c
> @@ -22,6 +22,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  
>  /**
> diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
> b/drivers/gpu/drm/mgag200/mgag200_fb.c
> index 30726c9fe28c..6893934b26c0 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_fb.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
> @@ -12,6 +12,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> index 96c2b828dba4..fa2d1d8995ee 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> @@ -16,6 +16,7 @@
>   * this program.  If not, see .
>   */
>  
> +#include 
>  
>  #include "mdp5_kms.h"
>  #include "mdp5_smp.h"
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> index aee99194499f..851c59f07eb1 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -16,6 +16,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  
>  #include "omap_drv.h"
> diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
> index 208af9f37914..d17676824377 100644
> --- a/drivers/gpu/drm/qxl/qxl_cmd.c
> +++ b/drivers/gpu/drm/qxl/qxl_cmd.c
> @@ -25,6 +25,8 @@
>  
>  /* QXL cmd/ring handling */
>  
> +#include 
> +
>  #include "qxl_drv.h"
>  #include "qxl_object.h"
>  
> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> index e55cbeee7a53..ac98ad561870 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #define ATOM_DEBUG
>  
>  #include "atom.h"
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index 222a1fa41d7c..7e3257e8fd56 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -24,6 +24,7 @@
>   *  Alex Deucher
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "radeon.h"
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index bd6ef1f31822..79c6bcc4f509 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -9,6 +9,7 @

Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting

[Christian Borntraeger]

On 27.12.2018 12:59, Christian Borntraeger wrote:
> On 27.12.2018 12:31, Christian Borntraeger wrote:
>> This patch triggers random crashes in the guest kernel on s390 early during 
>> boot.
>> No migration and no setting of the balloon is involved.
>>
> 
> Adding Conny and Halil,
> 
> As the QEMU provides no PAGE_HINT feature yet, this quick hack makes the
> guest boot fine again:
> 
> 
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 728ecd1eea305..aa2e1864c5736 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -492,7 +492,7 @@ static int init_vqs(struct virtio_balloon *vb)
> callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> }
>  
> -   err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
> +   err = vb->vdev->config->find_vqs(vb->vdev, 3, //VIRTIO_BALLOON_VQ_MAX,
>  vqs, callbacks, names, NULL, NULL);
> if (err)
> return err;
> 
> 
> To me it looks like that virtio_ccw_find_vqs will abort if any of the 
> virtqueues 
> that it is been asked for does not exist (including the earlier ones).
> 

This "hack" makes the random crashes go away, but the balloon interface itself
does not work. (setting the value to anything will hang the guest). 
As patch 1 also modifies the main path, there seem to be additional issues, 
maybe
endianess

Looking at things like

+   vb->cmd_id_received = VIRTIO_BALLOON_CMD_ID_STOP;
+   vb->cmd_id_active = cpu_to_virtio32(vb->vdev,
+ VIRTIO_BALLOON_CMD_ID_STOP);
+   vb->cmd_id_stop = cpu_to_virtio32(vb->vdev,
+ VIRTIO_BALLOON_CMD_ID_STOP);


Why is cmd_id_received not using cpu_to_virtio32?

Re: [PATCH] perf python: Do not force closing original perf descriptor in evlist.get_pollfd

[Arnaldo Carvalho de Melo]

Em Thu, Dec 27, 2018 at 09:06:38AM +0100, Jiri Olsa escreveu:
> On Wed, Dec 26, 2018 at 12:21:21PM +0100, Jiri Olsa wrote:
> > Ondřej reported that when compiled with python3, the python
> > extension regress in evlist.get_pollfd function behaviour.
> > 
> > The evlist.get_pollfd creates file objects from evlist's fds
> > and returns them in the list. The python3 version also sets
> > them to 'close the original descriptor' when the object die
> > (is closed), by passing True via 'closefd' arg in PyFile_FromFd
> > call.
> > 
> > The python's closefd doc says:
> >   If closefd is False, the underlying file descriptor will be kept open
> >   when the file is closed.
> > 
> > That's why following line in python3 closes all evlist fds:
> >   evlist.get_pollfd()
> > 
> > the returned list is immediately destroyed and that takes
> > down the original events fds.
> > 
> > Passing closefd as False to PyFile_FromFd to fix this.
> > 
> > Reported-by: Ondřej Lysoněk 
> > Link: http://lkml.kernel.org/n/tip-ru9hmsaliew8p01kr0050...@git.kernel.org
> > Signed-off-by: Jiri Olsa 
> 
> oops, forgot to add.. and cc-ing Jaroslav Škarvada
> 
> Fixes: 66dfdff03d19 ("perf tools: Add Python 3 support")

Thanks, added the Fixes: and Cc: Jaroslav,

- Arnaldo

Re: [PATCH] drm/i915_request.h: Remove duplicate header

[Chris Wilson]

Quoting Brajeswar Ghosh (2018-12-25 13:23:40)
> Remove i915_scheduler.h which is included more than once
> 
> Signed-off-by: Brajeswar Ghosh 

Thanks for the patch, pushed to dinq.
-Chris

[PATCH] media: secocec: fix ir address shift

[Ettore Chimenti]

The actual value of the RC5 System Number (address) is stored in the
IR_READ_DATA common register masked with 0x1F00 so it have to be shifted
by 8 bits.

Signed-off-by: Ettore Chimenti 
---
 drivers/media/platform/seco-cec/seco-cec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/seco-cec/seco-cec.h 
b/drivers/media/platform/seco-cec/seco-cec.h
index e632c4a2a044..843de8c7dfd4 100644
--- a/drivers/media/platform/seco-cec/seco-cec.h
+++ b/drivers/media/platform/seco-cec/seco-cec.h
@@ -106,7 +106,7 @@
 #define SECOCEC_IR_COMMAND_MASK0x007F
 #define SECOCEC_IR_COMMAND_SHL 0
 #define SECOCEC_IR_ADDRESS_MASK0x1F00
-#define SECOCEC_IR_ADDRESS_SHL 7
+#define SECOCEC_IR_ADDRESS_SHL 8
 #define SECOCEC_IR_TOGGLE_MASK 0x8000
 #define SECOCEC_IR_TOGGLE_SHL  15
 
-- 
2.20.1

[PATCH 1/2] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings

[shun-chih.yu]

From: Shun-Chih Yu 

Document the devicetree bindings for MediaTek Command-Queue DMA controller
which could be found on MT6765 SoC or other similar Mediatek SoCs.

Change-Id: I9736c8cac9be160358feeab935fabaffc5730519
Signed-off-by: Shun-Chih Yu 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/dma/mtk-cqdma.txt  |   31 
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.txt

diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.txt 
b/Documentation/devicetree/bindings/dma/mtk-cqdma.txt
new file mode 100644
index 000..fb12927
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.txt
@@ -0,0 +1,31 @@
+MediaTek Command-Queue DMA Controller
+==
+
+Required properties:
+
+- compatible:  Must be "mediatek,mt6765-cqdma" for MT6765.
+- reg: Should contain the base address and length for each channel.
+- interrupts:  Should contain references to the interrupts for each channel.
+- clocks:  Should be the clock specifiers corresponding to the entry in
+   clock-names property.
+- clock-names: Should contain "cqdma" entries.
+- dma-channels: The number of DMA channels supported by the controller.
+- dma-requests: The number of DMA request supported by the controller.
+- #dma-cells:  The length of the DMA specifier, must be <1>. This one cell
+   in dmas property of a client device represents the channel
+   number.
+Example:
+
+cqdma: dma-controller@10212000 {
+   compatible = "mediatek,mt6765-cqdma";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ,
+   ;
+   clocks = <&infracfg CLK_IFR_CQ_DMA>;
+   clock-names = "cqdma";
+   dma-channels = <2>;
+   dma-requests = <32>;
+   #dma-cells = <1>;
+   };
+
+DMA clients must use the format described in dma/dma.txt file.
-- 
1.7.9.5

[PATCH 2/2] dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC

[shun-chih.yu]

From: Shun-Chih Yu 

MediaTek Command-Queue DMA controller (CQDMA) on MT6765 SoC is dedicated
to memory-to-memory transfer through queue based descriptor management.

There are only 3 physical channels inside CQDMA, while the driver is
extended to support 32 virtual channels for multiple dma users to issue
dma requests onto the CQDMA simultaneously.

Change-Id: I1e8d116c5ecbbc49190ffc925cb59a0d035d886b
Signed-off-by: Shun-Chih Yu 
Reviewed-by: Vinod Koul 

---
 drivers/dma/mediatek/Kconfig |   12 +
 drivers/dma/mediatek/Makefile|1 +
 drivers/dma/mediatek/mtk-cqdma.c |  867 ++
 3 files changed, 880 insertions(+)
 create mode 100644 drivers/dma/mediatek/mtk-cqdma.c

diff --git a/drivers/dma/mediatek/Kconfig b/drivers/dma/mediatek/Kconfig
index 27bac0b..4a1582d 100644
--- a/drivers/dma/mediatek/Kconfig
+++ b/drivers/dma/mediatek/Kconfig
@@ -11,3 +11,15 @@ config MTK_HSDMA
  This controller provides the channels which is dedicated to
  memory-to-memory transfer to offload from CPU through ring-
  based descriptor management.
+
+config MTK_CQDMA
+   tristate "MediaTek Command-Queue DMA controller support"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for Command-Queue DMA controller on MediaTek
+ SoCs.
+
+ This controller provides the channels which is dedicated to
+ memory-to-memory transfer to offload from CPU.
diff --git a/drivers/dma/mediatek/Makefile b/drivers/dma/mediatek/Makefile
index 6e778f8..41bb381 100644
--- a/drivers/dma/mediatek/Makefile
+++ b/drivers/dma/mediatek/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_MTK_HSDMA) += mtk-hsdma.o
+obj-$(CONFIG_MTK_CQDMA) += mtk-cqdma.o
diff --git a/drivers/dma/mediatek/mtk-cqdma.c b/drivers/dma/mediatek/mtk-cqdma.c
new file mode 100644
index 000..304eb0a
--- /dev/null
+++ b/drivers/dma/mediatek/mtk-cqdma.c
@@ -0,0 +1,867 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018-2019 MediaTek Inc.
+
+/*
+ * Driver for MediaTek Command-Queue DMA Controller
+ *
+ * Author: Shun-Chih Yu 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../virt-dma.h"
+
+#define MTK_CQDMA_USEC_POLL10
+#define MTK_CQDMA_TIMEOUT_POLL 1000
+#define MTK_CQDMA_DMA_BUSWIDTHSBIT(DMA_SLAVE_BUSWIDTH_4_BYTES)
+#define MTK_CQDMA_ALIGN_SIZE   1
+
+/* The default number of virtual channel */
+#define MTK_CQDMA_NR_VCHANS32
+
+/* The default number of physical channel */
+#define MTK_CQDMA_NR_PCHANS3
+
+/* Registers for underlying dma manipulation */
+#define MTK_CQDMA_INT_FLAG 0x0
+#define MTK_CQDMA_INT_EN   0x4
+#define MTK_CQDMA_EN   0x8
+#define MTK_CQDMA_RESET0xc
+#define MTK_CQDMA_FLUSH0x14
+#define MTK_CQDMA_SRC  0x1c
+#define MTK_CQDMA_DST  0x20
+#define MTK_CQDMA_LEN1 0x24
+#define MTK_CQDMA_LEN2 0x28
+#define MTK_CQDMA_SRC2 0x60
+#define MTK_CQDMA_DST2 0x64
+
+/* Registers setting */
+#define MTK_CQDMA_EN_BIT   BIT(0)
+#define MTK_CQDMA_INT_FLAG_BIT BIT(0)
+#define MTK_CQDMA_INT_EN_BIT   BIT(0)
+#define MTK_CQDMA_FLUSH_BITBIT(0)
+
+#define MTK_CQDMA_WARM_RST_BIT BIT(0)
+#define MTK_CQDMA_HARD_RST_BIT BIT(1)
+
+#define MTK_CQDMA_MAX_LEN  GENMASK(27, 0)
+#define MTK_CQDMA_ADDR_LIMIT   GENMASK(31, 0)
+#define MTK_CQDMA_ADDR2_SHFIT  (32)
+
+/**
+ * struct mtk_cqdma_vdesc - The struct holding info describing virtual
+ * descriptor (CVD)
+ * @vd:An instance for struct virt_dma_desc
+ * @len:   The total data size device wants to move
+ * @dest:  The destination address device wants to move to
+ * @src:   The source address device wants to move from
+ * @ch:The pointer to the corresponding dma channel
+ * @node:  To build linked-list for PC queue
+ */
+struct mtk_cqdma_vdesc {
+   struct virt_dma_desc vd;
+   size_t len;
+   dma_addr_t dest;
+   dma_addr_t src;
+   struct dma_chan *ch;
+
+   /* protected by pc.lock */
+   struct list_head node;
+};
+
+/**
+ * struct mtk_cqdma_pchan - The struct holding info describing physical
+ * channel (PC)
+ * @queue: Queue for the CVDs issued to this PC
+ * @base:  The mapped register I/O base of this PC
+ * @irq:   The IRQ that this PC are using
+ * @refcnt:Track how many VCs are using this PC
+ * @lock: Lock protect agai

[PATCH v4] add support for Mediatek Command-Queue DMA controller on MT6765 SoC

[shun-chih.yu]

Changes since v3:
- simplify the ISR and management on descriptors by removing tasklet and 
ASYNC_TX_ENABLE_CHANNEL_SWITCH
- remove useless field in mtk_cqdma_vdesc structure
- change dev_info to dev_dbg
- fix typos

Changes since v2:
- fix build warning for kernel with DMA address in 32-bit

Changes since v1:
- remove unused macros, typos
- leverage ASYNC_TX_ENABLE_CHANNEL_SWITCH to maintain DMA descriptor list


Shun-Chih Yu (2):
  dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller
bindings
  dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for
MT6765 SoC

 .../devicetree/bindings/dma/mtk-cqdma.txt |  31 +
 drivers/dma/mediatek/Kconfig  |  12 +
 drivers/dma/mediatek/Makefile |   1 +
 drivers/dma/mediatek/mtk-cqdma.c  | 867 ++
 4 files changed, 911 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.txt
 create mode 100644 drivers/dma/mediatek/mtk-cqdma.c

RE: [PATCH v2 5/5] usb:cdns3 Add Cadence USB3 DRD Driver

[Pawel Laszczak]

HI,

>>
>> The host side of USBSS-DRD controller is compliance
>> with XHCI specification, so it works with
>> standard XHCI linux driver.
>>
>
>After adding my glue layer change (with my phy part) and make one
>change for this code,
>the xHCI can work at my platform. I list the comments from today's
>review and debug.
>The comments are at  Makefile and drd.c.
>
>> + If you choose to build this driver as module it will
>> + be dynamically linked and module will be called cdns3-pci.ko
>> +
>> +endif
>> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
>> new file mode 100644
>> index ..3f63baa24294
>> --- /dev/null
>> +++ b/drivers/usb/cdns3/Makefile
>> @@ -0,0 +1,16 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +# define_trace.h needs to know how to find our header
>> +CFLAGS_trace.o := -I$(src)
>> +
>> +obj-$(CONFIG_USB_CDNS3)+= cdns3.o
>> +obj-$(CONFIG_USB_CDNS3_PCI_WRAP)   += cdns3-pci.o
>> +
>> +cdns3-y:= core.o drd.o trace.o
>> +
>> +ifneq ($(CONFIG_DEBUG_FS),)
>> +   cdns3-y += debugfs.o
>> +endif
>> +
>> +cdns3-$(CONFIG_USB_CDNS3_GADGET)   += gadget.o ep0.o
>> +cdns3-$(CONFIG_USB_CDNS3_HOST) += host.o
>> +cdns3-pci-y:= cdns3-pci-wrap.o
>
>Why do you want add two lines for pci_wrap? I change this Makefile like below:

I don't need these two lines. I will change it as you suggested. 

>
># SPDX-License-Identifier: GPL-2.0
># define_trace.h needs to know how to find our header
>CFLAGS_trace.o  := -I$(src)
>
>cdns3-y := core.o drd.o trace.o
>obj-$(CONFIG_USB_CDNS3) += cdns3.o
>ifneq ($(CONFIG_DEBUG_FS),)
>cdns3-y += debugfs.o
>endif
>
>cdns3-$(CONFIG_USB_CDNS3_GADGET)+= gadget.o ep0.o
>cdns3-$(CONFIG_USB_CDNS3_HOST)  += host.o
>obj-$(CONFIG_USB_CDNS3_PCI_WRAP)+= cdns3-pci-wrap.o
>obj-$(CONFIG_USB_CDNS3_IMX_WRAP)+= cdns3-imx.o
>
>and below is the diff:
>
>diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
>index 3f63baa24294..d1bca2829f57 100644
>--- a/drivers/usb/cdns3/Makefile
>+++ b/drivers/usb/cdns3/Makefile
>@@ -2,15 +2,13 @@
> # define_trace.h needs to know how to find our header
> CFLAGS_trace.o := -I$(src)
>
>-obj-$(CONFIG_USB_CDNS3)+= cdns3.o
>-obj-$(CONFIG_USB_CDNS3_PCI_WRAP)   += cdns3-pci.o
>-
> cdns3-y:= core.o drd.o trace.o
>-
>+obj-$(CONFIG_USB_CDNS3)+= cdns3.o
> ifneq ($(CONFIG_DEBUG_FS),)
>cdns3-y += debugfs.o
> endif
>
> cdns3-$(CONFIG_USB_CDNS3_GADGET)   += gadget.o ep0.o
> cdns3-$(CONFIG_USB_CDNS3_HOST) += host.o
>-cdns3-pci-y:= cdns3-pci-wrap.o
>+obj-$(CONFIG_USB_CDNS3_PCI_WRAP)   += cdns3-pci-wrap.o
>+obj-$(CONFIG_USB_CDNS3_IMX_WRAP)   += cdns3-imx.o
>
>
>> diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
>> new file mode 100644
>> index ..b0c32302eb0b
>> --- /dev/null
>> +++ b/drivers/usb/cdns3/drd.c
>> @@ -0,0 +1,350 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Cadence USBSS DRD Driver.
>> + *
>> + * Copyright (C) 2018 Cadence.
>> + *
>> + * Author: Pawel Laszczak > + *
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "gadget.h"
>> +#include "drd.h"
>> +#include "core.h"
>> +
>> +static int cdns3_drd_switch_gadget(struct cdns3 *cdns, int on);
>> +static int cdns3_drd_switch_host(struct cdns3 *cdns, int on);
>> +
>> +/**
>> + * cdns3_set_mode - change mode of OTG Core
>> + * @cdns: pointer to context structure
>> + * @mode: selected mode from cdns_role
>> + */
>> +void cdns3_set_mode(struct cdns3 *cdns, enum usb_dr_mode mode)
>> +{
>> +   u32 reg;
>> +
>> +   cdns->current_dr_mode = mode;
>> +
>> +   switch (mode) {
>> +   case USB_DR_MODE_PERIPHERAL:
>> +   dev_info(cdns->dev, "Set controller to Gadget mode\n");
>> +   cdns3_drd_switch_gadget(cdns, 1);
>> +   break;
>> +   case USB_DR_MODE_HOST:
>> +   dev_info(cdns->dev, "Set controller to Host mode\n");
>> +   cdns3_drd_switch_host(cdns, 1);
>> +   break;
>> +   case USB_DR_MODE_OTG:
>> +   dev_info(cdns->dev, "Set controller to OTG mode\n");
>> +   if (cdns->version == CDNS3_CONTROLLER_V1) {
>> +   reg = readl(&cdns->otg_v1_regs->override);
>> +   reg |= OVERRIDE_IDPULLUP;
>> +   writel(reg, &cdns->otg_v1_regs->override);
>> +   } else {
>> +   reg = readl(&cdns->otg_v0_regs->ctrl1);
>> +   reg |= OVERRIDE_IDPULLUP_V0;
>> +   writel(reg, &cdns->otg_v0_regs->ctrl1);

Re: [PATCH 00/20] drop useless LIST_HEAD

[Dan Carpenter]

On Tue, Dec 25, 2018 at 11:12:20PM +0100, Tom Psyborg wrote:
> there was discussion about this just some days ago. CC 4-5 lists is
> more than enough
> 

I don't know who you were discussing this with...

You should CC the 0th patch to all the mailinglists.  That much is a
clear rule.

For the rest, Julia's position is the more conservative one.  I was in
a conversation in RL and they were like, "CC everyone for all the
patches".  It depends on the context, of course.  If the patches are
dependent on each other then you *have* to CC everyone for everything.

If we really have other clear rules, then it should be encoded into
get_maintainer.pl so that it's automatic.

My other question is why do the linux-arm-ker...@lists.infradead.org
people feel like they need to be CC'd about every driver???  I always
remove them from the CC list unless it's an arch/arm issue.

regards,
dan carpenter

PS:  Please, no more top posting.

Re: [PATCH] i2c: bcm2835: Clear current message and count after a transaction

[Stefan Wahren]

Hi Paul,

> Paul Kocialkowski  hat am 24. Dezember 2018 um 
> 10:10 geschrieben:
> 
> 
> Hi,
> 
> On Sat, 2018-12-22 at 13:19 +0100, Stefan Wahren wrote:
> > Hi Paul,
> > 
> > > Paul Kocialkowski  hat am 21. Dezember 
> > > 2018 um 13:11 geschrieben:
> > > 
> > > 
> > > The driver's interrupt handler checks whether a message is currently
> > > being handled with the curr_msg pointer. When it is NULL, the interrupt
> > > is considered to be unexpected. Similarly, the i2c_start_transfer
> > > routine checks for the remaining number of messages to handle in
> > > num_msgs.
> > > 
> > > However, these values are never cleared and always keep the message and
> > > number relevant to the latest transfer (which might be done already and
> > > the underlying message memory might have been freed).
> > > 
> > > When an unexpected interrupt hits with the DONE bit set, the isr will
> > > then try to access the flags field of the curr_msg structure, leading
> > > to a fatal page fault.
> > > 
> > > Fix the issue by systematically clearing curr_msg and num_msgs in the
> > > driver-wide device structure when a transfer is considered complete.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  drivers/i2c/busses/i2c-bcm2835.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/i2c/busses/i2c-bcm2835.c 
> > > b/drivers/i2c/busses/i2c-bcm2835.c
> > > index 44deae78913e..5486252f5f2f 100644
> > > --- a/drivers/i2c/busses/i2c-bcm2835.c
> > > +++ b/drivers/i2c/busses/i2c-bcm2835.c
> > > @@ -298,6 +298,9 @@ static int bcm2835_i2c_xfer(struct i2c_adapter *adap, 
> > > struct i2c_msg msgs[],
> > >   return -ETIMEDOUT;
> > >   }
> > >  
> > > + i2c_dev->curr_msg = NULL;
> > > + i2c_dev->num_msgs = 0;
> > 
> > AFAIU this would reduce the chance of a use-after-free dramatically but not 
> > completely.
> 
> Do you have a specific case of use-after-free related to these
> variables in mind that this cleanup would not fix (except for the
> timeout case)?

okay i was wrong about the use-after-free. But i'm not sure about this scenario 
on the I2C bus shared with the VC4:

1. ARM core starts I2C transfer (bcm2835_i2c_start_transfer)
2. VC4 triggers a BCM2835_I2C_S_DONE interrupt
3. ARM core catches this interrupt before the VC4

Stefan

> 
> The msg_buf element (in association with msg_buf_remaining keeping its
> previous value) could also lead to similar problems, so I'm thinking of
> making a bcm2835_i2c_finish_transfer function to group all the cleanups
> and call that right after wait_for_completion_timeout.
> 
> > Btw: Why did you leave of the i2c transfer timeout case?
> 
> I should definitely have included it, actually.
> 
> Cheers,
> 
> Paul
> 
> > Thanks
> > Stefan
> > 
> > > +
> > >   if (!i2c_dev->msg_err)
> > >   return num;
> > >  
> > > -- 
> > > 2.20.1
> > > 
> -- 
> Paul Kocialkowski, Bootlin (formerly Free Electrons)
> Embedded Linux and kernel engineering
> https://bootlin.com
>

iMX6 FEC driver Linux-fslc 4.17 - IPV6 Multicast not working when unplugging/plugging ethernet cable

[Stefano Cappa]

Hi everyone,
I already posted this in NXP forum as a comment
(https://community.nxp.com/thread/359397), in yocto mailing list
(https://lists.yoctoproject.org/pipermail/yocto/2018-December/043664.html)
and in meta-freescale mailing list
(https://lists.yoctoproject.org/pipermail/meta-freescale/2018-December/023625.html)
A user in meta-freescale's mailing list suggested to resend this
message to the emails obtained running "./scripts/get_maintainer.pl -F
drivers/net/ethernet/freescale/fec_main.c".


The problem is:

If I boot my iMX6 device with ethernet cable attached and I execute "ping6
ff02::fb" to ping the multicast address I get this response:
~# ping6 ff02::fb
PING ff02::fb (ff02::fb): 56 data bytes
64 bytes from fe80::c2f:eff:fe11:2d71: seq=0 ttl=64 time=2.057 ms
64 bytes from fe80::809:1bfb:8d4c:ae54: seq=0 ttl=64 time=73.101 ms (DUP!)
64 bytes from fe80::3e28:6dff:feed:5b97: seq=0 ttl=64 time=150.772 ms
(DUP!)


Otherwise, If I unplug and plug again ethernet cable, I cannot ping the
multicast ipv6 address anymore.
The result is:
~# ping6 ff02::fb
PING ff02::fb (ff02::fb): 56 data bytes
ping6: sendto: Network is unreachable


The original NXP discussion was about older version of Linux, however
this issue is happening with both Linux 4.9.88 and Linux 4.17.
Probably also with the latest version, but I didn't try.


Do you have any suggestions? Is this a bug? This is really a
frustrating and I'm really
surprised to see the same problem also on Linux 4.17.


PS: I'm sorry for the double email, but the previous one was in html
and it was rejected.

Thank u.

Re: [PATCH v3 7/9] drm/komeda: Attach komeda_dev to DRM-KMS

[Liviu Dudau]

On Thu, Dec 27, 2018 at 07:09:07AM +, james qian wang (Arm Technology 
China) wrote:
> On Mon, Dec 24, 2018 at 08:32:14PM +0800, Liviu Dudau wrote:
> > On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology 
> > China) wrote:
> > > Add komeda_kms abstracton to attach komeda_dev to DRM-KMS
> > >   CRTC: according to the komeda_pipeline
> > >   PLANE: according to komeda_layer (layer input pipeline)
> > >   PRIVATE_OBJS: komeda_pipeline/component all will be treat as 
> > > private_objs
> > > 
> > > komeda_kms is for connecting DRM-KMS and komeda_dev, like reporting the
> > > kms object properties according to the komeda_dev, and pass/convert KMS's
> > > requirement to komeda_dev.
> > > 
> > > Changes in v3:
> > > - Fixed style problem found by checkpatch.pl --strict.
> > > 
> > > Changes in v2:
> > > - Unified abbreviation of "pipeline" to "pipe".
> > > 
> > > Signed-off-by: James (Qian) Wang 
> > > ---
> > >  drivers/gpu/drm/arm/display/komeda/Makefile   |   6 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 106 +++
> > >  .../gpu/drm/arm/display/komeda/komeda_drv.c   |  19 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 169 ++
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.h   | 113 
> > >  .../drm/arm/display/komeda/komeda_pipeline.h  |   3 +
> > >  .../gpu/drm/arm/display/komeda/komeda_plane.c | 109 +++
> > >  .../arm/display/komeda/komeda_private_obj.c   |  88 +
> > >  8 files changed, 608 insertions(+), 5 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> > >  create mode 100644 
> > > drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> > > 
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
> > > b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > index 25beae900ed2..1b875e5dc0f6 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> > > +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > @@ -9,7 +9,11 @@ komeda-y := \
> > >   komeda_dev.o \
> > >   komeda_format_caps.o \
> > >   komeda_pipeline.o \
> > > - komeda_framebuffer.o
> > > + komeda_framebuffer.o \
> > > + komeda_kms.o \
> > > + komeda_crtc.o \
> > > + komeda_plane.o \
> > > + komeda_private_obj.o
> > >  
> > >  komeda-y += \
> > >   d71/d71_dev.o
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > new file mode 100644
> > > index ..5bb5a55f6b31
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > @@ -0,0 +1,106 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> > > + * Author: James.Qian.Wang 
> > > + *
> > > + */
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "komeda_dev.h"
> > > +#include "komeda_kms.h"
> > > +
> > > +struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
> > > +};
> > > +
> > > +static const struct drm_crtc_funcs komeda_crtc_funcs = {
> > > +};
> > > +
> > > +int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> > > +struct komeda_dev *mdev)
> > > +{
> > > + struct komeda_crtc *crtc;
> > > + struct komeda_pipeline *master;
> > > + char str[16];
> > > + int i;
> > > +
> > > + kms->n_crtcs = 0;
> > > +
> > > + for (i = 0; i < mdev->n_pipelines; i++) {
> > > + crtc = &kms->crtcs[kms->n_crtcs];
> > > + master = mdev->pipelines[i];
> > > +
> > > + crtc->master = master;
> > > + crtc->slave  = NULL;
> > > +
> > > + if (crtc->slave)
> > > + sprintf(str, "pipe-%d", crtc->slave->id);
> > > + else
> > > + sprintf(str, "None");
> > > +
> > > + DRM_INFO("crtc%d: master(pipe-%d) slave(%s) output: %s.\n",
> > > +  kms->n_crtcs, master->id, str,
> > > +  master->of_output_dev ?
> > > +  master->of_output_dev->full_name : "None");
> > > +
> > > + kms->n_crtcs++;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static struct drm_plane *
> > > +get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *crtc)
> > > +{
> > > + struct komeda_plane *kplane;
> > > + struct drm_plane *plane;
> > > +
> > > + drm_for_each_plane(plane, &kms->base) {
> > > + if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> > > + continue;
> > > +
> > > + kplane = to_kplane(plane);
> > > + /* only master can be primary */
> > > + if (kplane->layer->base.pipeline == crtc->master)
> > > + return plane;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> > > +
> > 

Re: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization

[Dmitry Vyukov]

On Sun, Nov 25, 2018 at 6:31 PM Paolo Bonzini  wrote:
>
> On 20/11/18 09:34, Wanpeng Li wrote:
> > From: Wanpeng Li 
> > ...
> > This patch fixes it by bailing out scan ioapic if ioapic is not initialized 
> > in
> > kernel.
> > Reported-by: Wei Wu 

+Linus, Greg

I want to point out that this was reported more then 3 months ago by syzbot:
https://groups.google.com/forum/#!msg/syzkaller-bugs/cPT7tmaz-gQ/SzOyhM0YBAAJ
then the report was lost on kernel mailing lists and then re-reported
by somebody else:
https://www.spinics.net/lists/kvm/msg177705.html
and only then fixed.

Lots of kernel bug reports routinely get lost on mailing lists, which is bad.

Another bug was reported by syzbot in April:
https://groups.google.com/forum/#!msg/syzkaller-bugs/-9XIT9gwq7M/sqvBXSZWBgAJ
then get lost and then re-reported in November:
https://www.spinics.net/lists/kvm/msg177704.html
and only then fixed.

Not specific for KVM, another bug in kernel/trace reported by syzbot,
lost for months, then re-reported and fixed:
https://groups.google.com/forum/#!msg/syzkaller-bugs/o_-OeMyoTwg/Ugh432hlAgAJ
https://bugzilla.kernel.org/show_bug.cgi?id=200019

And, no, it's not that people ignore just syzbot reports. It's just
that syzbot reports can be tracked so it's easier to spot such cases,
for manually reported bugs nobody usually knows anything after few
weeks. Here is an example of bug report by a human, which was even
replied but then slipped from somebody's attention set for a moment
and then complete oblivion. Months later happened to be re-reported by
syzbot and then fixed:
https://groups.google.com/forum/#!msg/syzkaller-bugs/wFUedfOK2Rw/waUrQYOxAQAJ

Re-reported a year later bugs can cause security problems and large
amounts of work to backport the fix to thousands of downstream kernel
forks. Not re-reported bugs are even worse as they are just not fixed.

This Plumbers I was approached by Doug Ledford from Redhat, who said
literally that there was a bunch of syzbot reports in rdma subsystem
but since they were reported some time ago, now nobody knows
what/where are they. So while the bugs are still presumably there, now
they are completely unactionable and kernel development process is
incapable of dealing with this. While syzbot reports have some chances
of being recovered, this equally applies to human-reported bugs and
they can't be easily recovered.

This does not looks like how things should be for the most critical
and fundamental software project in the world. Lost bugs/patches
should not be a thing. There are known working solutions for this in
the form of tooling and procedures, namely bug tracking. Any bug
tracking systems allows to answer the main question: what are the
active bugs, sorted by priority, in subsystem X/assigned to me; and
lots of other useful questions.

And, yes, I know we have bugazilla. But it's not being used as a bug
tracking system as of now. And when used, sometimes cause more trouble
because nobody expects bugs to be there:
https://lwn.net/ml/linux-kernel/20181208115629.ga3...@kroah.com/

Re: [PATCH v3 7/9] drm/komeda: Attach komeda_dev to DRM-KMS

[Liviu Dudau]

On Thu, Dec 27, 2018 at 07:09:07AM +, james qian wang (Arm Technology 
China) wrote:
> On Mon, Dec 24, 2018 at 08:32:14PM +0800, Liviu Dudau wrote:
> > On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology 
> > China) wrote:
> > > Add komeda_kms abstracton to attach komeda_dev to DRM-KMS
> > >   CRTC: according to the komeda_pipeline
> > >   PLANE: according to komeda_layer (layer input pipeline)
> > >   PRIVATE_OBJS: komeda_pipeline/component all will be treat as 
> > > private_objs
> > > 
> > > komeda_kms is for connecting DRM-KMS and komeda_dev, like reporting the
> > > kms object properties according to the komeda_dev, and pass/convert KMS's
> > > requirement to komeda_dev.
> > > 
> > > Changes in v3:
> > > - Fixed style problem found by checkpatch.pl --strict.
> > > 
> > > Changes in v2:
> > > - Unified abbreviation of "pipeline" to "pipe".
> > > 
> > > Signed-off-by: James (Qian) Wang 
> > > ---
> > >  drivers/gpu/drm/arm/display/komeda/Makefile   |   6 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 106 +++
> > >  .../gpu/drm/arm/display/komeda/komeda_drv.c   |  19 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 169 ++
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.h   | 113 
> > >  .../drm/arm/display/komeda/komeda_pipeline.h  |   3 +
> > >  .../gpu/drm/arm/display/komeda/komeda_plane.c | 109 +++
> > >  .../arm/display/komeda/komeda_private_obj.c   |  88 +
> > >  8 files changed, 608 insertions(+), 5 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> > >  create mode 100644 
> > > drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> > > 
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
> > > b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > index 25beae900ed2..1b875e5dc0f6 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> > > +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > @@ -9,7 +9,11 @@ komeda-y := \
> > >   komeda_dev.o \
> > >   komeda_format_caps.o \
> > >   komeda_pipeline.o \
> > > - komeda_framebuffer.o
> > > + komeda_framebuffer.o \
> > > + komeda_kms.o \
> > > + komeda_crtc.o \
> > > + komeda_plane.o \
> > > + komeda_private_obj.o
> > >  
> > >  komeda-y += \
> > >   d71/d71_dev.o
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > new file mode 100644
> > > index ..5bb5a55f6b31
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > @@ -0,0 +1,106 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> > > + * Author: James.Qian.Wang 
> > > + *
> > > + */
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "komeda_dev.h"
> > > +#include "komeda_kms.h"
> > > +
> > > +struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
> > > +};
> > > +
> > > +static const struct drm_crtc_funcs komeda_crtc_funcs = {
> > > +};
> > > +
> > > +int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> > > +struct komeda_dev *mdev)
> > > +{
> > > + struct komeda_crtc *crtc;
> > > + struct komeda_pipeline *master;
> > > + char str[16];
> > > + int i;
> > > +
> > > + kms->n_crtcs = 0;
> > > +
> > > + for (i = 0; i < mdev->n_pipelines; i++) {
> > > + crtc = &kms->crtcs[kms->n_crtcs];
> > > + master = mdev->pipelines[i];
> > > +
> > > + crtc->master = master;
> > > + crtc->slave  = NULL;
> > > +
> > > + if (crtc->slave)
> > > + sprintf(str, "pipe-%d", crtc->slave->id);
> > > + else
> > > + sprintf(str, "None");
> > > +
> > > + DRM_INFO("crtc%d: master(pipe-%d) slave(%s) output: %s.\n",
> > > +  kms->n_crtcs, master->id, str,
> > > +  master->of_output_dev ?
> > > +  master->of_output_dev->full_name : "None");
> > > +
> > > + kms->n_crtcs++;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static struct drm_plane *
> > > +get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *crtc)
> > > +{
> > > + struct komeda_plane *kplane;
> > > + struct drm_plane *plane;
> > > +
> > > + drm_for_each_plane(plane, &kms->base) {
> > > + if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> > > + continue;
> > > +
> > > + kplane = to_kplane(plane);
> > > + /* only master can be primary */
> > > + if (kplane->layer->base.pipeline == crtc->master)
> > > + return plane;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> > > +
> > 

[GIT PULL] MMC updates for v4.21

[Ulf Hansson]

Hi Linus,

Here's the PR with MMC updates for v4.21. Details about the highlights are as
usual found in the signed tag. Please pull this in!

This time, the PR contains changes crossing subsystems/archs/platforms, which
is mainly because of a bigger modernization of moving from legacy GPIO to GPIO
descriptors for MMC (by Linus Walleij). Additionally, again, I am funneling
changes to drivers/misc/cardreader/* and drivers/memstick/*, through my MMC
tree, mostly due to that we lack a maintainer for these. Perhaps, I should
simply volunteer and make that the formal process, let's see.

Happy holidays!

Kind regards
Ulf Hansson


The following changes since commit e3ae3401aa19432ee4943eb0bbc2ec704d07d793:

  mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrl (2018-12-17 
08:59:42 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.21

for you to fetch changes up to 5215b2e952f3f94d74cac1a59494eb8ac647e216:

  mmc: mediatek: Add MMC_CAP_SDIO_IRQ support (2018-12-19 10:16:15 +0100)


MMC core:
 - Cleanup BKOPS support
 - Introduce MMC_CAP_SYNC_RUNTIME_PM
 - slot-gpio: Delete legacy slot GPIO handling

MMC host:
 - alcor: Add new mmc host driver for Alcor Micro PCI based cardreader
 - bcm2835: Several improvements to better recover from errors
 - jz4740: Rework and fixup pre|post_req support
 - mediatek: Add support for SDIO IRQs
 - meson-gx: Improve clock phase management
 - meson-gx: Stop descriptor on errors
 - mmci: Complete the sbc error path by sending a stop command
 - renesas_sdhi/tmio: Fixup reset/resume operations
 - renesas_sdhi: Add support for r8a774c0 and R7S9210
 - renesas_sdhi: Whitelist R8A77990 SDHI
 - renesas_sdhi: Fixup eMMC HS400 compatibility issues for H3 and M3-W
 - rtsx_usb_sdmmc: Re-work card detection/removal support
 - rtsx_usb_sdmmc: Re-work runtime PM support
 - sdhci: Fix timeout loops for some variant drivers
 - sdhci: Improve support for error handling due to failing commands
 - sdhci-acpi/pci: Disable LED control for Intel BYT-based controllers
 - sdhci_am654: Add new SDHCI variant driver to support TI's AM654 SOCs
 - sdhci-of-esdhc: Add support for eMMC HS400 mode
 - sdhci-omap: Fixup reset support
 - sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures
 - sdhci-msm: Fixup sporadic write transfers issues for SDR104/HS200
 - sdhci-msm: Fixup dynamical clock gating issues
 - various: Complete converting all hosts into using slot GPIO descriptors

Other:
 - Move GPIO mmc platform data for mips/sh/arm to GPIO descriptors
 - Add new Alcor Micro cardreader PCI driver
 - Support runtime power management for memstick rtsx_usb_ms driver
 - Use USB remote wakeups for card detection for rtsx_usb misc driver


A.s. Dong (1):
  dt-bindings: mmc: fsl-imx-esdhc: add imx8qxp compatible string

Adrian Hunter (10):
  mmc: sdhci: Fix data command CRC error handling
  mmc: sdhci: Rename SDHCI_ACMD12_ERR and SDHCI_INT_ACMD12ERR
  mmc: sdhci: Handle auto-command errors
  mmc: sdhci-pci: Add max-frequency device property for Intel controllers
  mmc: sdhci-of-esdhc: Fix timeout checks
  mmc: sdhci-omap: Fix timeout checks
  mmc: sdhci-xenon: Fix timeout checks
  mmc: sdhci: Add quirk to disable LED control
  mmc: sdhci-pci: Disable LED control for Intel BYT-based controllers
  mmc: sdhci-acpi: Disable LED control for Intel BYT-based controllers

Arnd Bergmann (1):
  mmc: sdhci-msm: avoid unused function warning

Biju Das (1):
  mmc: renesas_sdhi_internal_dmac: Whitelist r8a774c0

Chris Brandt (2):
  mmc: renesas_sdhi_internal_dmac: Add R7S9210 support
  dt-bindings: mmc: tmio_mmc: Document Renesas R7S9210

Chunyan Zhang (1):
  mmc: sdhci: Convert sdhci_allocate_bounce_buffer() to return void

Colin Ian King (2):
  mmc: sdhci-of-esdhc: fix spelling mistake "upsupported" -> "unsupported"
  misc: alcor_pci: fix spelling mistake "invailid" -> "invalid"

Evan Green (1):
  dt-bindings: mmc: sdhci-msm: Clarify register requirements

Ezequiel Garcia (1):
  mmc: jz4740: rework pre_req/post_req implementation

Fabrizio Castro (1):
  dt-bindings: mmc: renesas_sdhi: Add r8a774c0 support

Faiz Abbas (7):
  mmc: sdhci-omap: Add platform specific reset callback
  mmc: sdhci-omap: Remove redundant structure assignments
  dt-bindings: mmc: sdhci-am654: Document bindings for the host controllers 
on TI's AM654 SOCs
  dt-bindings: mmc: sdhci-of-arasan: Add deprecated message for AM65
  mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver
  dt-bindings: sdhci-omap: Add note for cpu_thermal
  mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures 
(i929)

Jerome Brunet (4):
  mmc: meson-gx: make sure the descriptor is stopped on errors
  mmc: meson-gx: rem

[PATCH 1/2] USB: storage: don't insert sane sense for SPC3+ when bad sense specified

[Icenowy Zheng]

Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
which claims SPC4, will show strange behavior with 96-byte sense
(put the chip into a wrong state that cannot read/write anything).

Check the presence of US_FL_BAD_SENSE when assuming US_FL_SANE_SENSE on
SPC4+ devices.

Signed-off-by: Icenowy Zheng 
---
 drivers/usb/storage/scsiglue.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index fde2e71a6ade..699fe9557127 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -236,7 +236,8 @@ static int slave_configure(struct scsi_device *sdev)
sdev->try_rc_10_first = 1;
 
/* assume SPC3 or latter devices support sense size > 18 */
-   if (sdev->scsi_level > SCSI_SPC_2)
+   if (sdev->scsi_level > SCSI_SPC_2 &&
+   !(us->fflags & US_FL_BAD_SENSE))
us->fflags |= US_FL_SANE_SENSE;
 
/*
-- 
2.18.1

[PATCH 2/2] USB: storage: add quirk for SMI SM3350

[Icenowy Zheng]

The SMI SM3350 USB-UFS bridge controller cannot handle long sense request
correctly and will make the chip refuse to do read/write when requested
long sense.

Add a bad sense quirk for it.

Signed-off-by: Icenowy Zheng 
---
 drivers/usb/storage/unusual_devs.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index f7f83b21dc74..ea0d27a94afe 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1265,6 +1265,18 @@ UNUSUAL_DEV( 0x090c, 0x1132, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),
 
+/*
+ * Reported by Icenowy Zheng 
+ * The SMI SM3350 USB-UFS bridge controller will enter a wrong state
+ * that do not process read/write command if a long sense is requested,
+ * so force to use 18-byte sense.
+ */
+UNUSUAL_DEV(  0x090c, 0x3350, 0x, 0x,
+   "SMI",
+   "SM3350 UFS-to-USB-Mass-Storage bridge",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_BAD_SENSE ),
+
 /*
  * Reported by Paul Hartman 
  * This card reader returns "Illegal Request, Logical Block Address
-- 
2.18.1

[PATCH 0/2] USB Storage quirk for SMI SM3350

[Icenowy Zheng]

SMI SM3350 UFS-USB bridge controller cannot handle REQUEST SENSE command
with long sense (96-bytes) well, and will even trap the controller into
a state that refuses to do read/write command.

Currently Linux uncondintionally set US_FL_SANE_SENSE for devices
claiming SPC3+, which makes simply add US_FL_BAD_SENSE for SM3350 fail
(as it claims SPC4).

Fix this conflicting quirk issue, and add the quirk for SM3350.

Icenowy Zheng (2):
  USB: storage: don't insert sane sense for SPC3+ when bad sense
specified
  USB: storage: add quirk for SMI SM3350

 drivers/usb/storage/scsiglue.c |  3 ++-
 drivers/usb/storage/unusual_devs.h | 12 
 2 files changed, 14 insertions(+), 1 deletion(-)

-- 
2.18.1

Re: [PATCH 1/2] USB: storage: don't insert sane sense for SPC3+ when bad sense specified

[Icenowy Zheng]

在 2018-12-27四的 22:34 +0800，Icenowy Zheng写道：
> Currently the code will set US_FL_SANE_SENSE flag unconditionally if
> device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
> prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
> which claims SPC4, will show strange behavior with 96-byte sense
> (put the chip into a wrong state that cannot read/write anything).
> 
> Check the presence of US_FL_BAD_SENSE when assuming US_FL_SANE_SENSE
> on
> SPC4+ devices.
> 
> Signed-off-by: Icenowy Zheng 
> ---

I forgot to:

Cc: sta...@vger.kernel.org

>  drivers/usb/storage/scsiglue.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/storage/scsiglue.c
> b/drivers/usb/storage/scsiglue.c
> index fde2e71a6ade..699fe9557127 100644
> --- a/drivers/usb/storage/scsiglue.c
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -236,7 +236,8 @@ static int slave_configure(struct scsi_device
> *sdev)
>   sdev->try_rc_10_first = 1;
>  
>   /* assume SPC3 or latter devices support sense size >
> 18 */
> - if (sdev->scsi_level > SCSI_SPC_2)
> + if (sdev->scsi_level > SCSI_SPC_2 &&
> + !(us->fflags & US_FL_BAD_SENSE))
>   us->fflags |= US_FL_SANE_SENSE;
>  
>   /*

Re: [PATCH 2/2] USB: storage: add quirk for SMI SM3350

[Icenowy Zheng]

在 2018-12-27四的 22:34 +0800，Icenowy Zheng写道：
> The SMI SM3350 USB-UFS bridge controller cannot handle long sense
> request
> correctly and will make the chip refuse to do read/write when
> requested
> long sense.
> 
> Add a bad sense quirk for it.
> 
> Signed-off-by: Icenowy Zheng 
> ---

I forgot to:

Cc: sta...@vger.kernel.org

>  drivers/usb/storage/unusual_devs.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/usb/storage/unusual_devs.h
> b/drivers/usb/storage/unusual_devs.h
> index f7f83b21dc74..ea0d27a94afe 100644
> --- a/drivers/usb/storage/unusual_devs.h
> +++ b/drivers/usb/storage/unusual_devs.h
> @@ -1265,6 +1265,18 @@ UNUSUAL_DEV( 0x090c, 0x1132, 0x, 0x,
>   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>   US_FL_FIX_CAPACITY ),
>  
> +/*
> + * Reported by Icenowy Zheng 
> + * The SMI SM3350 USB-UFS bridge controller will enter a wrong state
> + * that do not process read/write command if a long sense is
> requested,
> + * so force to use 18-byte sense.
> + */
> +UNUSUAL_DEV(  0x090c, 0x3350, 0x, 0x,
> + "SMI",
> + "SM3350 UFS-to-USB-Mass-Storage bridge",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_BAD_SENSE ),
> +
>  /*
>   * Reported by Paul Hartman 
>   * This card reader returns "Illegal Request, Logical Block Address

Re: + proc-commit-to-genradix.patch added to -mm tree

[Alexey Dobriyan]

On Mon, Dec 17, 2018 at 12:54:58PM -0800, a...@linux-foundation.org wrote:
> http://ozlabs.org/~akpm/mmots/broken-out/proc-commit-to-genradix.patch
> Subject: proc: commit to genradix
> 
> The new generic radix trees have a simpler API and implementation, and no
> limitations on number of elements, so all flex_array users are being
> converted

> --- a/fs/proc/base.c~proc-commit-to-genradix
> +++ a/fs/proc/base.c
> @@ -2142,11 +2142,12 @@ proc_map_files_readdir(struct file *file
>   struct task_struct *task;
>   struct mm_struct *mm;
>   unsigned long nr_files, pos, i;
> - struct flex_array *fa = NULL;
> - struct map_files_info info;
> + GENRADIX(struct map_files_info) fa;
>   struct map_files_info *p;
>   int ret;
>  
> + genradix_init(&fa);

Reviewed-by: Alexey Dobriyan 

I'll try to check performance after New Year.

Re: [PATCH 1/2] ARM: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro

[Donglin Peng]

On Wed, Jun 13, 2018 at 9:15 AM Peng Donglin  wrote:
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Peng Donglin 
> ---
>  arch/arm/mm/ptdump_debugfs.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
> index be8d87b..79002fe 100644
> --- a/arch/arm/mm/ptdump_debugfs.c
> +++ b/arch/arm/mm/ptdump_debugfs.c
> @@ -11,18 +11,7 @@ static int ptdump_show(struct seq_file *m, void *v)
> ptdump_walk_pgd(m, info);
> return 0;
>  }
> -
> -static int ptdump_open(struct inode *inode, struct file *file)
> -{
> -   return single_open(file, ptdump_show, inode->i_private);
> -}
> -
> -static const struct file_operations ptdump_fops = {
> -   .open   = ptdump_open,
> -   .read   = seq_read,
> -   .llseek = seq_lseek,
> -   .release= single_release,
> -};
> +DEFINE_SHOW_ATTRIBUTE(ptdump);
>
>  int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
>  {
> --
> 2.7.4
>

any suggestion?

Re: [PATCH] i2c: bcm2835: Clear current message and count after a transaction

[Paul Kocialkowski]

Hi Stefan,

On Thu, 2018-12-27 at 15:05 +0100, Stefan Wahren wrote:
> Hi Paul,
> 
> > Paul Kocialkowski  hat am 24. Dezember 2018 
> > um 10:10 geschrieben:
> > 
> > 
> > Hi,
> > 
> > On Sat, 2018-12-22 at 13:19 +0100, Stefan Wahren wrote:
> > > Hi Paul,
> > > 
> > > > Paul Kocialkowski  hat am 21. Dezember 
> > > > 2018 um 13:11 geschrieben:
> > > > 
> > > > 
> > > > The driver's interrupt handler checks whether a message is currently
> > > > being handled with the curr_msg pointer. When it is NULL, the interrupt
> > > > is considered to be unexpected. Similarly, the i2c_start_transfer
> > > > routine checks for the remaining number of messages to handle in
> > > > num_msgs.
> > > > 
> > > > However, these values are never cleared and always keep the message and
> > > > number relevant to the latest transfer (which might be done already and
> > > > the underlying message memory might have been freed).
> > > > 
> > > > When an unexpected interrupt hits with the DONE bit set, the isr will
> > > > then try to access the flags field of the curr_msg structure, leading
> > > > to a fatal page fault.
> > > > 
> > > > Fix the issue by systematically clearing curr_msg and num_msgs in the
> > > > driver-wide device structure when a transfer is considered complete.
> > > > 
> > > > Signed-off-by: Paul Kocialkowski 
> > > > ---
> > > >  drivers/i2c/busses/i2c-bcm2835.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/drivers/i2c/busses/i2c-bcm2835.c 
> > > > b/drivers/i2c/busses/i2c-bcm2835.c
> > > > index 44deae78913e..5486252f5f2f 100644
> > > > --- a/drivers/i2c/busses/i2c-bcm2835.c
> > > > +++ b/drivers/i2c/busses/i2c-bcm2835.c
> > > > @@ -298,6 +298,9 @@ static int bcm2835_i2c_xfer(struct i2c_adapter 
> > > > *adap, struct i2c_msg msgs[],
> > > > return -ETIMEDOUT;
> > > > }
> > > >  
> > > > +   i2c_dev->curr_msg = NULL;
> > > > +   i2c_dev->num_msgs = 0;
> > > 
> > > AFAIU this would reduce the chance of a use-after-free dramatically but 
> > > not completely.
> > 
> > Do you have a specific case of use-after-free related to these
> > variables in mind that this cleanup would not fix (except for the
> > timeout case)?
> 
> okay i was wrong about the use-after-free. But i'm not sure about this 
> scenario on the I2C bus shared with the VC4:
> 
> 1. ARM core starts I2C transfer (bcm2835_i2c_start_transfer)
> 2. VC4 triggers a BCM2835_I2C_S_DONE interrupt
> 3. ARM core catches this interrupt before the VC4

Well, I thought the VC4 has precedence over the ARM core, so if the
interrupts hits in hardware, it should be seen by the VC4 first and
forwarded to the ARM core if needed (I might be wrong though). So in
that case, perhaps the ARM core wouldn't see the interrupt and just
timeout?

Either way, I'm don't think that having both the VC4 and the ARM core
poke on the same bus is a scenario we can realisticly aim to support.
Although it should definitely not make our driver crash if that
happens.

The HDMI DDC bus is an I2C bus shared between the ARM core and VC4, but
the VC4 firmware should detect from the device-tree that Linux will
attempt to drive the bus and let the ARM core deal with it without
interference.

Thanks for your feedback!

Cheers,

Paul

> > The msg_buf element (in association with msg_buf_remaining keeping its
> > previous value) could also lead to similar problems, so I'm thinking of
> > making a bcm2835_i2c_finish_transfer function to group all the cleanups
> > and call that right after wait_for_completion_timeout.
> > 
> > > Btw: Why did you leave of the i2c transfer timeout case?
> > 
> > I should definitely have included it, actually.
> > 
> > Cheers,
> > 
> > Paul
> > 
> > > Thanks
> > > Stefan
> > > 
> > > > +
> > > > if (!i2c_dev->msg_err)
> > > > return num;
> > > >  
> > > > -- 
> > > > 2.20.1
> > > > 
> > -- 
> > Paul Kocialkowski, Bootlin (formerly Free Electrons)
> > Embedded Linux and kernel engineering
> > https://bootlin.com
> > 
-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

[PATCH v4 1/3] i2c: at91: segregate master mode specific code from probe and init func

[Ludovic Desroches]

From: Juergen Fitschen 

In order to implement slave mode support for the at91 hardware we have to
segregate all master mode specific function parts from the general parts.
The upcoming slave mode patch will call its sepcific probe resp. init
function instead of the master mode functions after the shared general
code has been executed.

This concept has been influenced by the i2c-designware driver.

Signed-off-by: Juergen Fitschen 
Signed-off-by: Ludovic Desroches 
---
 drivers/i2c/busses/i2c-at91.c | 90 +--
 1 file changed, 55 insertions(+), 35 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 3f3e8b3bf5ff..bc74184462c6 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -174,10 +174,8 @@ static void at91_twi_irq_restore(struct at91_twi_dev *dev)
at91_twi_write(dev, AT91_TWI_IER, dev->imr);
 }
 
-static void at91_init_twi_bus(struct at91_twi_dev *dev)
+static void at91_init_twi_bus_master(struct at91_twi_dev *dev)
 {
-   at91_disable_twi_interrupts(dev);
-   at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SWRST);
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_FIFOEN);
@@ -186,6 +184,14 @@ static void at91_init_twi_bus(struct at91_twi_dev *dev)
at91_twi_write(dev, AT91_TWI_CWGR, dev->twi_cwgr_reg);
 }
 
+static void at91_init_twi_bus(struct at91_twi_dev *dev)
+{
+   at91_disable_twi_interrupts(dev);
+   at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SWRST);
+
+   at91_init_twi_bus_master(dev);
+}
+
 /*
  * Calculate symmetric clock as stated in datasheet:
  * twi_clk = F_MAIN / (2 * (cdiv * (1 << ckdiv) + offset))
@@ -1046,18 +1052,56 @@ static struct at91_twi_pdata *at91_twi_get_driver_data(
return (struct at91_twi_pdata *) 
platform_get_device_id(pdev)->driver_data;
 }
 
+static int at91_twi_probe_master(struct platform_device *pdev,
+u32 phy_addr, struct at91_twi_dev *dev)
+{
+   int rc;
+   u32 bus_clk_rate;
+
+   init_completion(&dev->cmd_complete);
+
+   rc = devm_request_irq(&pdev->dev, dev->irq, atmel_twi_interrupt, 0,
+ dev_name(dev->dev), dev);
+   if (rc) {
+   dev_err(dev->dev, "Cannot get irq %d: %d\n", dev->irq, rc);
+   return rc;
+   }
+
+   if (dev->dev->of_node) {
+   rc = at91_twi_configure_dma(dev, phy_addr);
+   if (rc == -EPROBE_DEFER)
+   return rc;
+   }
+
+   if (!of_property_read_u32(pdev->dev.of_node, "atmel,fifo-size",
+ &dev->fifo_size)) {
+   dev_info(dev->dev, "Using FIFO (%u data)\n", dev->fifo_size);
+   }
+
+   rc = of_property_read_u32(dev->dev->of_node, "clock-frequency",
+ &bus_clk_rate);
+   if (rc)
+   bus_clk_rate = DEFAULT_TWI_CLK_HZ;
+
+   at91_calc_twi_clock(dev, bus_clk_rate);
+
+   dev->adapter.algo = &at91_twi_algorithm;
+   dev->adapter.quirks = &at91_twi_quirks;
+
+   return 0;
+}
+
 static int at91_twi_probe(struct platform_device *pdev)
 {
struct at91_twi_dev *dev;
struct resource *mem;
int rc;
u32 phy_addr;
-   u32 bus_clk_rate;
 
dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
if (!dev)
return -ENOMEM;
-   init_completion(&dev->cmd_complete);
+
dev->dev = &pdev->dev;
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1077,13 +1121,6 @@ static int at91_twi_probe(struct platform_device *pdev)
if (dev->irq < 0)
return dev->irq;
 
-   rc = devm_request_irq(&pdev->dev, dev->irq, atmel_twi_interrupt, 0,
-dev_name(dev->dev), dev);
-   if (rc) {
-   dev_err(dev->dev, "Cannot get irq %d: %d\n", dev->irq, rc);
-   return rc;
-   }
-
platform_set_drvdata(pdev, dev);
 
dev->clk = devm_clk_get(dev->dev, NULL);
@@ -1095,38 +1132,21 @@ static int at91_twi_probe(struct platform_device *pdev)
if (rc)
return rc;
 
-   if (dev->dev->of_node) {
-   rc = at91_twi_configure_dma(dev, phy_addr);
-   if (rc == -EPROBE_DEFER) {
-   clk_disable_unprepare(dev->clk);
-   return rc;
-   }
-   }
-
-   if (!of_property_read_u32(pdev->dev.of_node, "atmel,fifo-size",
- &dev->fifo_size)) {
-   dev_info(dev->dev, "Using FIFO (%u data)\n", dev->fifo_size);
-   }
-
-   rc = of_property_read_u32(dev->dev->of_node, "clock-frequency",
-   &bus_clk_rate);
-   if (rc)
-   bus_clk_rate = DEFAULT_TWI_CLK_HZ;
-
-   at91_calc_twi_clock(dev, bus_clk_rate);
-   at91_init_tw

[PATCH v4 0/3] i2c: at91: slave mode support

[Ludovic Desroches]

[Ludovic Desroches: see Changes section]

Based on the discussion we had on the i2c-linux list [1], I wrote a patch for
AT91 hardware and tried to fulfill the Linux I2C slave interface description
[2] as good as possible. This enables aforementioned hardware to act as an I2C
slave that can be accessed by a remote I2C master.

I have tested this patchset successfully on an ATSAMA5D27.

 ^  3.3V   ^  3.3V
+---+| | +---+
| Slave: ATSAMA5D27 |   +-+   +-+| Master: ATSAMA5D35|
| with i2c-slave-eeprom |   | | 100k  | | 100k   | with i2cset   |
+---+-+-+   +-+   +-++-+-+---+
| |  | |   | |
| +--+-|---(SDA)---+ |
+--+---(SCL)-+

Schematic: Connection of slave and master with 100kOhm pullup resistors.

On the master the following BASH script has been used to stress the slave.

root@emblinux:~# cat ./stress.sh
#!/bin/bash
I=0
while true
do
if i2cset -y -r 1 0x64 0 $I w | grep mismatch
then
echo "$(date): Error in transmission ${I}"
fi
((I++))
if [ $I -eq 65536 ]
then
I=0
echo "$(date): Sent 65536 transmissions"
fi
done

After running the script for some time I had the following output. To me this
looks promising :)

root@emblinux:~# ./stress.sh
Thu Nov  9 13:58:45 CTE 2017: Sent 65536 transmissions
Thu Nov  9 14:35:20 CTE 2017: Sent 65536 transmissions
Thu Nov  9 15:12:11 CTE 2017: Sent 65536 transmissions
Thu Nov  9 15:49:04 CTE 2017: Sent 65536 transmissions
Thu Nov  9 16:26:00 CTE 2017: Sent 65536 transmissions
Thu Nov  9 17:03:07 UTC 2017: Sent 65536 transmissions
Thu Nov  9 17:40:15 UTC 2017: Sent 65536 transmissions

If you have some hardware with an at91-i2c interface included at hand, 
I really
would appreciate if you can run the test script on your hardware and 
test this
driver.
Thu Nov  9 17:40:15 UTC 2017: Sent 65536 transmissions

If you have some hardware with an at91-i2c interface included at hand, 
I really
would appreciate if you can run the test script on your hardware and 
test this
driver.

Best regards
  Juergen


[Ludovic Desroches]
Changes in v4:
 - rebased on next-20181224
 - update Kconfig part to state that this feature is experimental.
 - tested quickly on a single board, SAMA5D2 Xplained, i2c-gpio as master, OK.
Changes in v3:
 - rebase (cherry-pick was enough)
 - fix checkpatch errors
 - tests:
   - hangs with a SAMA5D4 (master and slave on different busses) after about
   100 transfers. It's the first time I do this test.
   - some mismatches with a SAMA5D4 as slave and a SAMA5D2 as master
   I don't know if it's a regression. I don't remember having seen this
   behavior previously.
   I think it's worth taking those patches even if there are some possible
   bugs. It'll allow to get more people using it and so to consolidate the
   slave mode support.

Changes in v2:
 - Implemented all suggestions made by Ludovic. (Thank you!)
 - Reworked the IRQ handler completely. Have a look in patch 3 fort further
   details.

[1] https://marc.info/?t=15082400481&r=1&w=1
[2] https://www.kernel.org/doc/Documentation/i2c/slave-interface



Juergen Fitschen (3):
  i2c: at91: segregate master mode specific code from probe and init
func
  i2c: at91: split driver into core and master file
  i2c: at91: added slave mode support

 MAINTAINERS   |   3 +-
 drivers/i2c/busses/Kconfig|  13 +
 drivers/i2c/busses/Makefile   |   4 +
 drivers/i2c/busses/i2c-at91-core.c| 380 +++
 .../busses/{i2c-at91.c => i2c-at91-master.c}  | 453 +-
 drivers/i2c/busses/i2c-at91-slave.c   | 147 ++
 drivers/i2c/busses/i2c-at91.h | 179 +++
 7 files changed, 732 insertions(+), 447 deletions(-)
 create mode 100644 drivers/i2c/busses/i2c-at91-core.c
 rename drivers/i2c/busses/{i2c-at91.c => i2c-at91-master.c} (67%)
 create mode 100644 drivers/i2c/busses/i2c-at91-slave.c
 create mode 100644 drivers/i2c/busses/i2c-at91.h

-- 
2.20.1

[PATCH v4 2/3] i2c: at91: split driver into core and master file

[Ludovic Desroches]

From: Juergen Fitschen 

The single file i2c-at91.c has been split into core code (i2c-at91-core.c)
and master mode specific code (i2c-at91-master.c). This should enhance
maintainability and reduce ifdeffery for slave mode related code.

The code itself hasn't been touched. Shared functions only had to be made
non-static. Furthermore, includes have been cleaned up.

Signed-off-by: Juergen Fitschen 
[ludovic.desroc...@microchip.com: fix checkpatch errors]
Signed-off-by: Ludovic Desroches 
---
 MAINTAINERS   |   3 +-
 drivers/i2c/busses/Makefile   |   1 +
 drivers/i2c/busses/i2c-at91-core.c| 373 ++
 .../busses/{i2c-at91.c => i2c-at91-master.c}  | 467 +-
 drivers/i2c/busses/i2c-at91.h | 151 ++
 5 files changed, 531 insertions(+), 464 deletions(-)
 create mode 100644 drivers/i2c/busses/i2c-at91-core.c
 rename drivers/i2c/busses/{i2c-at91.c => i2c-at91-master.c} (67%)
 create mode 100644 drivers/i2c/busses/i2c-at91.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 82dc44b09a7e..d61941db6933 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9873,7 +9873,8 @@ MICROCHIP I2C DRIVER
 M: Ludovic Desroches 
 L: linux-...@vger.kernel.org
 S: Supported
-F: drivers/i2c/busses/i2c-at91.c
+F: drivers/i2c/busses/i2c-at91.h
+F: drivers/i2c/busses/i2c-at91-*.c
 
 MICROCHIP ISC DRIVER
 M: Eugen Hristev 
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 5f0cb6915969..ea75a777940e 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_I2C_POWERMAC)+= i2c-powermac.o
 obj-$(CONFIG_I2C_ALTERA)   += i2c-altera.o
 obj-$(CONFIG_I2C_ASPEED)   += i2c-aspeed.o
 obj-$(CONFIG_I2C_AT91) += i2c-at91.o
+i2c-at91-objs  := i2c-at91-core.o i2c-at91-master.o
 obj-$(CONFIG_I2C_AU1550)   += i2c-au1550.o
 obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
 obj-$(CONFIG_I2C_BCM2835)  += i2c-bcm2835.o
diff --git a/drivers/i2c/busses/i2c-at91-core.c 
b/drivers/i2c/busses/i2c-at91-core.c
new file mode 100644
index ..5d9c6c81e6ab
--- /dev/null
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -0,0 +1,373 @@
+/*
+ *  i2c Support for Atmel's AT91 Two-Wire Interface (TWI)
+ *
+ *  Copyright (C) 2011 Weinmann Medical GmbH
+ *  Author: Nikolaus Voss 
+ *
+ *  Evolved from original work by:
+ *  Copyright (C) 2004 Rick Bronson
+ *  Converted to 2.6 by Andrew Victor 
+ *
+ *  Borrowed heavily from original work by:
+ *  Copyright (C) 2000 Philip Edelbrock 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "i2c-at91.h"
+
+unsigned at91_twi_read(struct at91_twi_dev *dev, unsigned reg)
+{
+   return readl_relaxed(dev->base + reg);
+}
+
+void at91_twi_write(struct at91_twi_dev *dev, unsigned reg, unsigned val)
+{
+   writel_relaxed(val, dev->base + reg);
+}
+
+void at91_disable_twi_interrupts(struct at91_twi_dev *dev)
+{
+   at91_twi_write(dev, AT91_TWI_IDR, AT91_TWI_INT_MASK);
+}
+
+void at91_twi_irq_save(struct at91_twi_dev *dev)
+{
+   dev->imr = at91_twi_read(dev, AT91_TWI_IMR) & AT91_TWI_INT_MASK;
+   at91_disable_twi_interrupts(dev);
+}
+
+void at91_twi_irq_restore(struct at91_twi_dev *dev)
+{
+   at91_twi_write(dev, AT91_TWI_IER, dev->imr);
+}
+
+void at91_init_twi_bus(struct at91_twi_dev *dev)
+{
+   at91_disable_twi_interrupts(dev);
+   at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SWRST);
+
+   at91_init_twi_bus_master(dev);
+}
+
+static struct at91_twi_pdata at91rm9200_config = {
+   .clk_max_div = 5,
+   .clk_offset = 3,
+   .has_unre_flag = true,
+   .has_alt_cmd = false,
+   .has_hold_field = false,
+};
+
+static struct at91_twi_pdata at91sam9261_config = {
+   .clk_max_div = 5,
+   .clk_offset = 4,
+   .has_unre_flag = false,
+   .has_alt_cmd = false,
+   .has_hold_field = false,
+};
+
+static struct at91_twi_pdata at91sam9260_config = {
+   .clk_max_div = 7,
+   .clk_offset = 4,
+   .has_unre_flag = false,
+   .has_alt_cmd = false,
+   .has_hold_field = false,
+};
+
+static struct at91_twi_pdata at91sam9g20_config = {
+   .clk_max_div = 7,
+   .clk_offset = 4,
+   .has_unre_flag = false,
+   .has_alt_cmd = false,
+   .has_hold_field = false,
+};
+
+static struct at91_twi_pdata at91sam9g10_config = {
+   .clk_max_div = 7,
+   .clk_offset = 4,
+   .has_unre_flag = false,
+   .has_alt_cmd = false,
+   .has_hold_field = false,
+};
+
+static const struct platform_device_id at91_twi_devtypes[] = {
+   {
+   .name = "

[PATCH v4 3/3] i2c: at91: added slave mode support

[Ludovic Desroches]

From: Juergen Fitschen 

Slave mode driver is based on the concept of i2c-designware driver.

Signed-off-by: Juergen Fitschen 
[ludovic.desroc...@microchip.com: rework Kconfig]
Signed-off-by: Ludovic Desroches 
---
 drivers/i2c/busses/Kconfig  |  13 +++
 drivers/i2c/busses/Makefile |   3 +
 drivers/i2c/busses/i2c-at91-core.c  |  13 ++-
 drivers/i2c/busses/i2c-at91-slave.c | 147 
 drivers/i2c/busses/i2c-at91.h   |  30 +-
 5 files changed, 202 insertions(+), 4 deletions(-)
 create mode 100644 drivers/i2c/busses/i2c-at91-slave.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index f2c681971201..6b1f6dcdf533 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -387,6 +387,19 @@ config I2C_AT91
  the latency to fill the transmission register is too long. If you
  are facing this situation, use the i2c-gpio driver.
 
+config I2C_AT91_SLAVE_EXPERIMENTAL
+   tristate "Microchip AT91 I2C experimental slave mode"
+   depends on I2C_AT91
+   select I2C_SLAVE
+   help
+ If you say yes to this option, support for the slave mode will be
+ added. Caution: do not use it for production. This feature has not
+ been tested in a heavy way, help wanted.
+ There are known bugs:
+   - It can hang, on a SAMA5D4, after several transfers.
+   - There are some mismtaches with a SAMA5D4 as slave and a SAMA5D2 as
+   master.
+
 config I2C_AU1550
tristate "Au1550/Au1200/Au1300 SMBus interface"
depends on MIPS_ALCHEMY
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index ea75a777940e..59b22fbef90a 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -36,6 +36,9 @@ obj-$(CONFIG_I2C_ALTERA)  += i2c-altera.o
 obj-$(CONFIG_I2C_ASPEED)   += i2c-aspeed.o
 obj-$(CONFIG_I2C_AT91) += i2c-at91.o
 i2c-at91-objs  := i2c-at91-core.o i2c-at91-master.o
+ifeq ($(CONFIG_I2C_AT91_SLAVE_EXPERIMENTAL),y)
+   i2c-at91-objs   += i2c-at91-slave.o
+endif
 obj-$(CONFIG_I2C_AU1550)   += i2c-au1550.o
 obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
 obj-$(CONFIG_I2C_BCM2835)  += i2c-bcm2835.o
diff --git a/drivers/i2c/busses/i2c-at91-core.c 
b/drivers/i2c/busses/i2c-at91-core.c
index 5d9c6c81e6ab..c74283fa567f 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -60,8 +60,10 @@ void at91_init_twi_bus(struct at91_twi_dev *dev)
 {
at91_disable_twi_interrupts(dev);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SWRST);
-
-   at91_init_twi_bus_master(dev);
+   if (dev->slave_detected)
+   at91_init_twi_bus_slave(dev);
+   else
+   at91_init_twi_bus_master(dev);
 }
 
 static struct at91_twi_pdata at91rm9200_config = {
@@ -243,7 +245,12 @@ static int at91_twi_probe(struct platform_device *pdev)
dev->adapter.timeout = AT91_I2C_TIMEOUT;
dev->adapter.dev.of_node = pdev->dev.of_node;
 
-   rc = at91_twi_probe_master(pdev, phy_addr, dev);
+   dev->slave_detected = i2c_detect_slave_mode(&pdev->dev);
+
+   if (dev->slave_detected)
+   rc = at91_twi_probe_slave(pdev, phy_addr, dev);
+   else
+   rc = at91_twi_probe_master(pdev, phy_addr, dev);
if (rc)
return rc;
 
diff --git a/drivers/i2c/busses/i2c-at91-slave.c 
b/drivers/i2c/busses/i2c-at91-slave.c
new file mode 100644
index ..4b4808e0c8f7
--- /dev/null
+++ b/drivers/i2c/busses/i2c-at91-slave.c
@@ -0,0 +1,147 @@
+/*
+ *  i2c slave support for Atmel's AT91 Two-Wire Interface (TWI)
+ *
+ *  Copyright (C) 2017 Juergen Fitschen 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "i2c-at91.h"
+
+static irqreturn_t atmel_twi_interrupt_slave(int irq, void *dev_id)
+{
+   struct at91_twi_dev *dev = dev_id;
+   const unsigned status = at91_twi_read(dev, AT91_TWI_SR);
+   const unsigned irqstatus = status & at91_twi_read(dev, AT91_TWI_IMR);
+   u8 value;
+
+   if (!irqstatus)
+   return IRQ_NONE;
+
+   /* slave address has been detected on I2C bus */
+   if (irqstatus & AT91_TWI_SVACC) {
+   if (status & AT91_TWI_SVREAD) {
+   i2c_slave_event(dev->slave,
+   I2C_SLAVE_READ_REQUESTED, &value);
+   writeb_relaxed(value, dev->base + AT91_TWI_THR);
+   at91_twi_write(dev, AT91_TWI_IER,
+  AT91_TWI_TXRDY | AT91_TWI_EOSACC);
+   } else {
+   i2c_slave_event(dev->slave,
+

[PATCH 1/2] hwmon: (hih6130) add dtb compatibility tables

[Andreas Kemnade]

This allows the hih6130 to be used in devicetree files and auto-probed
that way.

Signed-off-by: Andreas Kemnade 
---
 drivers/hwmon/hih6130.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/hih6130.c b/drivers/hwmon/hih6130.c
index 0ae1ee1dbf76..de1b50ddc740 100644
--- a/drivers/hwmon/hih6130.c
+++ b/drivers/hwmon/hih6130.c
@@ -254,8 +254,17 @@ static const struct i2c_device_id hih6130_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, hih6130_id);
 
+static const struct of_device_id hih6130_of_match[] = {
+   { .compatible = "honeywell,hih6130", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, hih6130_of_match);
+
 static struct i2c_driver hih6130_driver = {
-   .driver.name = "hih6130",
+   .driver = {
+   .name = "hih6130",
+   .of_match_table = of_match_ptr(hih6130_of_match),
+   },
.probe   = hih6130_probe,
.id_table= hih6130_id,
 };
-- 
2.11.0

[PATCH 2/2] devicetree: hwmon: Add bindings documentation for HIH6130

[Andreas Kemnade]

Add bindings documentation for HIH6130 driver.

Signed-off-by: Andreas Kemnade 
---
 Documentation/devicetree/bindings/hwmon/hih6130.txt | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/hih6130.txt

diff --git a/Documentation/devicetree/bindings/hwmon/hih6130.txt 
b/Documentation/devicetree/bindings/hwmon/hih6130.txt
new file mode 100644
index ..2c43837af4c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/hih6130.txt
@@ -0,0 +1,12 @@
+Honeywell Humidicon HIH-6130 humidity/temperature sensor
+
+
+Requires node properties:
+- compatible : "honeywell,hi6130"
+- reg : the I2C address of the device. This is 0x27.
+
+Example:
+   hih6130@27 {
+   compatible = "honeywell,hih6130";
+   reg = <0x27>;
+   };
-- 
2.11.0

[PATCH 0/2] hwmon: devicetree support for hih6130

[Andreas Kemnade]

This patch set adds devicetree support for hih6130, so it can
be properly auto-probed using devicetree files

Andreas Kemnade (2):
  hwmon: (hih6130) add dtb compatibility tables
  devicetree: hwmon: Add bindings documentation for HIH6130

 Documentation/devicetree/bindings/hwmon/hih6130.txt | 12 
 drivers/hwmon/hih6130.c | 11 ++-
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/hih6130.txt

-- 
2.11.0

Re: [RFC PATCH 0/1] mm: add a warning about high order allocations

[Konstantin Khorenko]

Hi Michal,

thank you very much for your questions, please see my notes below.

On 12/26/2018 11:35 AM, Michal Hocko wrote:
> On Tue 25-12-18 18:39:26, Konstantin Khorenko wrote:
>> Q: Why do we need to bother at all?
>> A: If a node is highly loaded and its memory is significantly fragmented
>> (unfortunately almost any node with serious load has highly fragmented 
>> memory)
>> then any high order memory allocation can trigger massive memory shrink and
>> result in quite a big allocation latency. And the node becomes less 
>> responsive
>> and users don't like it.
>> The ultimate solution here is to get rid of large allocations, but we need an
>> instrument to detect them.
>
> Can you point to an example of the problem you are referring here? At
> least for costly orders we do bail out early and try to not cause
> massive reclaim. So what is the order that you are concerned about?

Well, this is the most difficult question to answer.
Unfortunately i don't have a reproducer for that, usually we get into situation
when someone experiences significant node slowdown, nodes most often have a lot 
of RAM,
we check what is going on there and see the node is busy with reclaim.
And almost every time the reason was - fragmented memory and high order 
allocations.
Mostly of 2nd and 3rd (which is still considered not costly) order.

Recent related issues we faced were about FUSE dev pipe:
d6d931adce11 ("fuse: use kvmalloc to allocate array of pipe_buffer structs.")

and about bnx driver + mtu 9000 which for each packet required page of 2nd order
(and it even failed sometimes, though it was not the root cause):
 kswapd0: page allocation failure: order:2, mode:0x4020
 Call Trace:
 dump_stack+0x19/0x1b
 warn_alloc_failed+0x110/0x180
 __alloc_pages_nodemask+0x7bf/0xc60
 alloc_pages_current+0x98/0x110
 kmalloc_order+0x18/0x40
 kmalloc_order_trace+0x26/0xa0
 __kmalloc+0x279/0x290
 bnx2x_frag_alloc.isra.61+0x2a/0x40 [bnx2x]
 bnx2x_rx_int+0x227/0x17c0 [bnx2x]
 bnx2x_poll+0x1dd/0x260 [bnx2x]
 net_rx_action+0x179/0x390
 __do_softirq+0x10f/0x2aa
 call_softirq+0x1c/0x30
 do_softirq+0x65/0xa0
 irq_exit+0x105/0x110
 do_IRQ+0x56/0xe0
 common_interrupt+0x6d/0x6d

And as both places were called very often - the system latency was high.

This warning can be also used to catch allocation of 4th order and higher which 
may
easily fail. Those places which are ready to get allocation errors and have
fallbacks are marked with __GFP_NOWARN.

>> Q: Why warning? Use tracepoints!
>> A: Well, this is a matter of magic defaults.
>> Yes, you can use tracepoints to catch large allocations, but you need to do 
>> this
>> on purpose and regularly and this is to be done by every developer which is
>> quite unreal.
>> On the other hand if you develop something and get a warning, you'll have to
>> think about the reason and either succeed with reworking the code to use
>> smaller allocation sizes (and thus decrease allocation latency!) or just use
>> kvmalloc() if you don't really need physically continuos chunk or come to the
>> conclusion you definitely need physically continuos memory and shut up the
>> warning.
>
> Well, not really. For one thing, there are systems to panic on warning
> and you really do not want to blow up just because somebody is doing a
> large order allocation.

Well, on one hand - yes, i agree with you. That's why i don't suggest to enable
the warning by default right now - until all (most) of large allocations are 
marked
properly.
But after it's done and there are no (almost) unmarked high order allocations -
why not? This will reveal new cases of high order allocations soon.
i think people who run systems with "kernel.panic_on_warn" enabled do care
about reporting issues.

>> Q: Why compile time config option?
>> A: In order not to decrease the performance even a bit in case someone does 
>> not
>> want to hunt for large allocations.
>> In an ideal life i'd prefer this check/warning is enabled by default and may 
>> be
>> even without a config option so it works on every node. Once we find and 
>> rework
>> or mark all large allocations that would be good by default. Until that 
>> though
>> it will be noisy.
>
> So who is going to enable this option?

At the beginning - people who want to debug kernel and verify their fallbacks on
memory allocations failures in the code or just speed up their code on nodes
with fragmented memory - for 2nd and 3rd orders.

mm performance issues are tough, you know, and this is just another way to
gain more performance. It won't avoid the necessity of digging mm for sure,
but might decrease the pressure level.

Later (i hope) i could be enabled by default so all big new allocations
are verified sooner and either reworked or marked with __GFP_NOWARN if the code 
is
ready.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

>> Another

Re: [PATCH -mmotm] arm64: skip kmemleak for KASAN again

[Andrey Konovalov]

On Wed, Dec 26, 2018 at 3:06 AM Qian Cai  wrote:
>
> Due to 871ac3d540f (kasan: initialize shadow to 0xff for tag-based
> mode), kmemleak is broken again with KASAN. It needs a similar fix
> from e55058c2983 (mm/memblock.c: skip kmemleak for kasan_init()).
>
> Signed-off-by: Qian Cai 

Hi Qian,

Sorry, didn't see your first kmemleak fix. I can merge this fix into
my series if I end up resending it.

In any case:

Acked-by: Andrey Konovalov 

Thanks!

> ---
>  arch/arm64/mm/kasan_init.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index 48d8f2fa0d14..4b55b15707a3 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -47,8 +47,7 @@ static phys_addr_t __init kasan_alloc_raw_page(int node)
>  {
> void *p = memblock_alloc_try_nid_raw(PAGE_SIZE, PAGE_SIZE,
> __pa(MAX_DMA_ADDRESS),
> -   MEMBLOCK_ALLOC_ACCESSIBLE,
> -   node);
> +   MEMBLOCK_ALLOC_KASAN, node);
> return __pa(p);
>  }
>
> --
> 2.17.2 (Apple Git-113)
>

Re: [PATCH ghak90 (was ghak32) V4 09/10] audit: NETFILTER_PKT: record each container ID associated with a netNS

[Richard Guy Briggs]

On 2018-10-31 15:30, Richard Guy Briggs wrote:
> On 2018-10-19 19:18, Paul Moore wrote:
> > On Sun, Aug 5, 2018 at 4:33 AM Richard Guy Briggs  wrote:
> > > Add audit container identifier auxiliary record(s) to NETFILTER_PKT
> > > event standalone records.  Iterate through all potential audit container
> > > identifiers associated with a network namespace.
> > >
> > > Signed-off-by: Richard Guy Briggs 
> > > ---
> > >  include/linux/audit.h|  5 +
> > >  kernel/audit.c   | 26 ++
> > >  net/netfilter/xt_AUDIT.c | 12 ++--
> > >  3 files changed, 41 insertions(+), 2 deletions(-)
> > 
> > ...
> > 
> > > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > > index 9a02095..8755f4d 100644
> > > --- a/include/linux/audit.h
> > > +++ b/include/linux/audit.h
> > > @@ -169,6 +169,8 @@ extern int audit_log_contid(struct audit_context 
> > > *context,
> > >  extern void audit_netns_contid_add(struct net *net, u64 contid);
> > >  extern void audit_netns_contid_del(struct net *net, u64 contid);
> > >  extern void audit_switch_task_namespaces(struct nsproxy *ns, struct 
> > > task_struct *p);
> > > +extern void audit_log_netns_contid_list(struct net *net,
> > > +struct audit_context *context);
> > >
> > >  extern int audit_update_lsm_rules(void);
> > >
> > > @@ -228,6 +230,9 @@ static inline void audit_netns_contid_del(struct net 
> > > *net, u64 contid)
> > >  { }
> > >  static inline void audit_switch_task_namespaces(struct nsproxy *ns, 
> > > struct task_struct *p)
> > >  { }
> > > +static inline void audit_log_netns_contid_list(struct net *net,
> > > +   struct audit_context *context)
> > > +{ }
> > >
> > >  #define audit_enabled AUDIT_OFF
> > >  #endif /* CONFIG_AUDIT */
> > > diff --git a/kernel/audit.c b/kernel/audit.c
> > > index c5fed3b..b23711c 100644
> > > --- a/kernel/audit.c
> > > +++ b/kernel/audit.c
> > > @@ -392,6 +392,32 @@ void audit_switch_task_namespaces(struct nsproxy 
> > > *ns, struct task_struct *p)
> > > audit_netns_contid_add(new->net_ns, contid);
> > >  }
> > >
> > > +void audit_log_netns_contid_list(struct net *net, struct audit_context 
> > > *context)
> > > +{
> > > +   spinlock_t *lock = audit_get_netns_contid_list_lock(net);
> > > +   struct audit_buffer *ab;
> > > +   struct audit_contid *cont;
> > > +   bool first = true;
> > > +
> > > +   /* Generate AUDIT_CONTAINER record with container ID CSV list */
> > > +   ab = audit_log_start(context, GFP_ATOMIC, AUDIT_CONTAINER);
> > > +   if (!ab) {
> > > +   audit_log_lost("out of memory in 
> > > audit_log_netns_contid_list");
> > > +   return;
> > > +   }
> > > +   audit_log_format(ab, "contid=");
> > > +   spin_lock(lock);
> > > +   list_for_each_entry(cont, audit_get_netns_contid_list(net), list) 
> > > {
> > > +   if (!first)
> > > +   audit_log_format(ab, ",");
> > > +   audit_log_format(ab, "%llu", cont->id);
> > > +   first = false;
> > > +   }
> > > +   spin_unlock(lock);
> > 
> > This is looking like potentially a lot of work to be doing under a
> > spinlock, not to mention a single spinlock that is shared across CPUs.
> > Considering that I expect changes to the list to be somewhat
> > infrequent, this might be a good candidate for a RCU based locking
> > scheme.
> 
> Would something like this look reasonable?
> (This is on top of a patch to make contid list lock and unlock
> functions.)

Paul, could I please get your review on this locking approach I proposed
almost two months ago so I can be more reassured that it won't be an
issue in v5?  Thanks!

> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index be5d6eb..9428fc3 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -92,6 +92,7 @@ struct audit_contid {
>   struct list_headlist;
>   u64 id;
>   refcount_t  refcount;
> + struct rcu_head rcu;
>  };
>  
>  extern int is_audit_feature_set(int which);
> diff --git a/kernel/audit.c b/kernel/audit.c
> index d5b58163..6f84c25 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -106,7 +106,6 @@
>  struct audit_net {
>   struct sock *sk;
>   struct list_head contid_list;
> - spinlock_t contid_list_lock;
>  };
>  
>  /**
> @@ -327,26 +326,6 @@ struct list_head *audit_get_netns_contid_list(const 
> struct net *net)
>   return &aunet->contid_list;
>  }
>  
> -static int audit_netns_contid_lock(const struct net *net)
> -{
> - struct audit_net *aunet = net_generic(net, audit_net_id);
> -
> - if (!aunet)
> - return -EINVAL;
> - spin_lock(aunet->contid_list_lock);
> - return 0;
> -}
> -
> -static int audit_netns_contid_unlock(const struct net *net)
> -{
> - struct audit_net *aunet = net_generic(net, audit_net_id)

[PATCH v2] i2c: bcm2835: Clear current buffer pointers and counts after a transfer

[Paul Kocialkowski]

The driver's interrupt handler checks whether a message is currently
being handled with the curr_msg pointer. When it is NULL, the interrupt
is considered to be unexpected. Similarly, the i2c_start_transfer
routine checks for the remaining number of messages to handle in
num_msgs.

However, these values are never cleared and always keep the message and
number relevant to the latest transfer (which might be done already and
the underlying message memory might have been freed).

When an unexpected interrupt hits with the DONE bit set, the isr will
then try to access the flags field of the curr_msg structure, leading
to a fatal page fault.

The msg_buf and msg_buf_remaining fields are also never cleared at the
end of the transfer, which can lead to similar pitfalls.

Fix these issues by introducing a cleanup function and always calling
it after a transfer is finished.

Fixes: e2474541032d ("i2c: bcm2835: Fix hang for writing messages larger than 
16 bytes")
Signed-off-by: Paul Kocialkowski 
---

Changes since v1:
* Added cleanup of msg_buf and msg_buf_remaining;
* Moved cleanups to a dedicated function;
* Performed cleanup on timeout as well;
* Added Fixes tag.

 drivers/i2c/busses/i2c-bcm2835.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index 44deae78913e..4d19254f78c8 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -191,6 +191,15 @@ static void bcm2835_i2c_start_transfer(struct 
bcm2835_i2c_dev *i2c_dev)
bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C, c);
 }
 
+static void bcm2835_i2c_finish_transfer(struct bcm2835_i2c_dev *i2c_dev)
+{
+   i2c_dev->curr_msg = NULL;
+   i2c_dev->num_msgs = 0;
+
+   i2c_dev->msg_buf = NULL;
+   i2c_dev->msg_buf_remaining = 0;
+}
+
 /*
  * Note about I2C_C_CLEAR on error:
  * The I2C_C_CLEAR on errors will take some time to resolve -- if you were in
@@ -291,6 +300,9 @@ static int bcm2835_i2c_xfer(struct i2c_adapter *adap, 
struct i2c_msg msgs[],
 
time_left = wait_for_completion_timeout(&i2c_dev->completion,
adap->timeout);
+
+   bcm2835_i2c_finish_transfer(i2c_dev);
+
if (!time_left) {
bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C,
   BCM2835_I2C_C_CLEAR);
-- 
2.20.1

Re: [PATCH 1/1] mm/page_alloc: add a warning about high order allocations

[Konstantin Khorenko]

On 12/26/2018 11:40 AM, Michal Hocko wrote:
> Appart from general comments as a reply to the cover (btw. this all
> should be in the changelog because this is the _why_ part of the
> justification which should be _always_ part of the changelog).

Thank you, will add in the next version of the patch alltogether
with other changes if any.

> On Tue 25-12-18 18:39:27, Konstantin Khorenko wrote:
> [...]
>> +config WARN_HIGH_ORDER
>> +bool "Enable complains about high order memory allocations"
>> +depends on !LOCKDEP
>
> Why?

LOCKDEP makes structures big, so if we see a high order allocation warning
on a debug kernel with lockdep, it does not give us a lot - lockdep enabled
kernel performance is not our target.
i can remove !LOCKDEP dependence here, but then need to adjust default
warning level i think, or logs will be spammed.

>> +default n
>> +help
>> +  Enables warnings on high order memory allocations. This allows to
>> +  determine users of large memory chunks and rework them to decrease
>> +  allocation latency. Note, some debug options make kernel structures
>> +  fat.
>> +
>> +config WARN_HIGH_ORDER_LEVEL
>> +int "Define page order level considered as too high"
>> +depends on WARN_HIGH_ORDER
>> +default 3
>> +help
>> +  Defines page order starting which the system to complain about.
>> +  Default is current PAGE_ALLOC_COSTLY_ORDER.
>> +
>>  config HWPOISON_INJECT
>>  tristate "HWPoison pages injector"
>>  depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index e95b5b7c9c3d..258892adb861 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -4341,6 +4341,30 @@ static inline void finalise_ac(gfp_t gfp_mask, struct 
>> alloc_context *ac)
>>  ac->high_zoneidx, ac->nodemask);
>>  }
>>
>> +#ifdef CONFIG_WARN_HIGH_ORDER
>> +int warn_order = CONFIG_WARN_HIGH_ORDER_LEVEL;
>> +
>> +/*
>> + * Complain if we allocate a high order page unless there is a __GFP_NOWARN
>> + * flag provided.
>> + *
>> + * Shuts up after 32 complains.
>> + */
>> +static __always_inline void warn_high_order(int order, gfp_t gfp_mask)
>> +{
>> +static atomic_t warn_count = ATOMIC_INIT(32);
>> +
>> +if (order >= warn_order && !(gfp_mask & __GFP_NOWARN))
>> +WARN(atomic_dec_if_positive(&warn_count) >= 0,
>> + "order %d >= %d, gfp 0x%x\n",
>> + order, warn_order, gfp_mask);
>> +}
>
> We do have ratelimit functionality, so why cannot you use it?

Well, my idea was to really shut up the warning after some number of messages
(if a node is in production and its uptime, say, a year, i don't want to see
many warnings in logs, first several is enough - let's fix them first).

If i use printk_ratelimited() i could get 24 days delay at most AFAIK,
but okay, i can switch to printk_ratelimited() if you prefer.

struct ratelimit_state {
 int interval;

(gdb) p ((1LL<<31) -1)/1000/60/60/24
$11 = 24

>> +#else
>> +static __always_inline void warn_high_order(int order, gfp_t gfp_mask)
>> +{
>> +}
>> +#endif
>> +
>>  /*
>>   * This is the 'heart' of the zoned buddy allocator.
>>   */
>> @@ -4361,6 +4385,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int 
>> order, int preferred_nid,
>>  WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
>>  return NULL;
>>  }
>> +warn_high_order(order, gfp_mask);
>>
>>  gfp_mask &= gfp_allowed_mask;
>>  alloc_mask = gfp_mask;
>
> Why do you warn about all allocations in the hot path? I thought you
> want to catch expensive allocations so I would assume that you would
> stick that into a slow path after we are not able to allocate anything
> after the first round of compaction.

The idea is to catch big allocations soon and preferably during testing,
not on production nodes under high load, that's why i've chosen hot path.

And if we switch to the slow path, we'll have to run all tests under
additional serious load - to generate memory fragmentation.
Not so convenient.

> Also do you want to warn about opportunistic GFP_NOWAIT allocations that
> have a reasonable fallback?

Yes, i would like to. Sometimes allocation flags come from upper level and
it's not always evident if there is GFP_NOWAIT flag or not, so let's we
are noticed about such a case and verify if it's legal and not called often.
If yes - we'll just mark it with NO_WARN.


 > And forgot to mention other opportunistic allocations like THP of
 > course.

hugepages are allocated with NOWARN already, AFAIK.
alloc_fresh_huge_page_node(), __hugetlb_alloc_buddy_huge_page()


Thank you once again, Michal.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

Re: [PATCH v4 05/13] firmware: ti_sci: Add helper apis to manage resources

[Nishanth Menon]

On 11:43-20181227, Lokesh Vutla wrote:
> Each resource with in the device can be uniquely identified
> by a type and subtype as defined by TISCI. Since this is generic
> across the devices, resource allocation also can be made generic
> instead of each client driver handling the resource. So add helper
> apis to manage the resource.
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  drivers/firmware/ti_sci.c  | 126 +
>  include/linux/soc/ti/ti_sci_protocol.h |  48 ++
>  2 files changed, 174 insertions(+)
> 
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index c2f0815edab6..b6804c214be9 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -2480,6 +2480,132 @@ const struct ti_sci_handle 
> *devm_ti_sci_get_by_phandle(struct device *dev,
>  }
>  EXPORT_SYMBOL_GPL(devm_ti_sci_get_by_phandle);
>  
> +/*
> + * ti_sci_get_free_resource() - Get a free resource from TISCI resource.
> + * @res: Pointer to the TISCI resource
> + *
> + * Return: resource num if all went ok else TI_SCI_RESOURCE_NULL.
> + */
> +u16 ti_sci_get_free_resource(struct ti_sci_resource *res)
> +{
> + unsigned long flags;
> + u16 set, free_bit;
> +
> + raw_spin_lock_irqsave(&res->lock, flags);
> + for (set = 0; set < res->sets; set++) {
> + free_bit = find_first_zero_bit(res->desc[set].res_map,
> +res->desc[set].num);
> + if (free_bit != res->desc[set].num) {
> + set_bit(free_bit, res->desc[set].res_map);
> + raw_spin_unlock_irqrestore(&res->lock, flags);
> + return res->desc[set].start + free_bit;
> + }
> + }
> + raw_spin_unlock_irqrestore(&res->lock, flags);
> +
> + return TI_SCI_RESOURCE_NULL;
> +}
> +EXPORT_SYMBOL_GPL(ti_sci_get_free_resource);
> +
> +/**
> + * ti_sci_release_resource() - Release a resource from TISCI resource.
> + * @res: Pointer to the TISCI resource
> + */
> +void ti_sci_release_resource(struct ti_sci_resource *res, u16 id)
> +{
> + unsigned long flags;
> + u16 set;
> +
> + raw_spin_lock_irqsave(&res->lock, flags);
> + for (set = 0; set < res->sets; set++) {
> + if (res->desc[set].start <= id &&
> + (res->desc[set].num + res->desc[set].start) > id)
> + clear_bit(id - res->desc[set].start,
> +   res->desc[set].res_map);
> + }
> + raw_spin_unlock_irqrestore(&res->lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(ti_sci_release_resource);
> +
> +/**
> + * devm_ti_sci_get_of_resource() - Get a TISCI resource assigned to a device
> + * @handle:  TISCI handle
> + * @dev: Device pointer to which the resource is assigned
> + * @of_prop: property name by which the resource are represented
> + *
> + * Note: This function expects of_prop to be in the form of tuples
> + *   . Allocates and initializes ti_sci_resource structure
> + *   for each of_prop. Client driver can directly call
> + *   ti_sci_(get_free, release)_resource apis for handling the resource.
> + *
> + * Return: Pointer to ti_sci_resource if all went well else appropriate
> + *  error pointer.
> + */
> +struct ti_sci_resource *
> +devm_ti_sci_get_of_resource(const struct ti_sci_handle *handle,
> + struct device *dev, u32 dev_id, char *of_prop)
> +{
> + struct ti_sci_resource *res;
> + u32 resource_subtype;
> + u16 resource_type;
> + int i, ret;
> +
> + res = devm_kzalloc(dev, sizeof(*res), GFP_KERNEL);
> + if (!res)
> + return ERR_PTR(-ENOMEM);
> +
> + res->sets = of_property_count_elems_of_size(dev_of_node(dev), of_prop,
> + sizeof(u32));
> + if (res->sets < 0) {
> + dev_err(dev, "%s resource type ids not available\n", of_prop);
> + return ERR_PTR(res->sets);
> + }
> +
> + res->desc = devm_kcalloc(dev, res->sets, sizeof(*res->desc),
> +  GFP_KERNEL);
> + if (!res->desc)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = ti_sci_get_resource_type(handle_to_ti_sci_info(handle), dev_id,
> +&resource_type);
> + if (ret) {
> + dev_err(dev, "No valid resource type for %u\n", dev_id);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + for (i = 0; i < res->sets; i++) {
> + 

[PATCH] bitmap: Add bitmap_valloc(), bitmap_vzalloc() and bitmap_vfree()

[Peng Wang]

Introduce bitmap alloc/free helpers when contiguous
memory is not necessary.

Signed-off-by: Peng Wang 
---
 include/linux/bitmap.h |  3 +++
 lib/bitmap.c   | 19 +++
 2 files changed, 22 insertions(+)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index f58e97446abc..aaad1b33dfd5 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -111,6 +111,9 @@
 extern unsigned long *bitmap_alloc(unsigned int nbits, gfp_t flags);
 extern unsigned long *bitmap_zalloc(unsigned int nbits, gfp_t flags);
 extern void bitmap_free(const unsigned long *bitmap);
+extern unsigned long *bitmap_valloc(unsigned int nbits, gfp_t flags);
+extern unsigned long *bitmap_vzalloc(unsigned int nbits, gfp_t flags);
+extern void bitmap_vfree(const unsigned long *bitmap);
 
 /*
  * lib/bitmap.c provides these functions:
diff --git a/lib/bitmap.c b/lib/bitmap.c
index eead55aa7170..739597e436ad 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -1139,6 +1139,25 @@ void bitmap_free(const unsigned long *bitmap)
 }
 EXPORT_SYMBOL(bitmap_free);
 
+unsigned long *bitmap_valloc(unsigned int nbits, gfp_t flags)
+{
+   return kvmalloc_array(BITS_TO_LONGS(nbits), sizeof(unsigned long),
+flags);
+}
+EXPORT_SYMBOL(bitmap_valloc);
+
+unsigned long *bitmap_vzalloc(unsigned int nbits, gfp_t flags)
+{
+   return bitmap_valloc(nbits, flags | __GFP_ZERO);
+}
+EXPORT_SYMBOL(bitmap_vzalloc);
+
+void bitmap_vfree(const unsigned long *bitmap)
+{
+   kvfree(bitmap);
+}
+EXPORT_SYMBOL(bitmap_vfree);
+
 #if BITS_PER_LONG == 64
 /**
  * bitmap_from_arr32 - copy the contents of u32 array of bits to bitmap
-- 
2.19.1

[PATCH] csky: fix refcount leak in setup_smp()

[Yangtao Li]

The of_find_node_by_type() returns a node pointer with refcount
incremented, but there is the lack of use of the of_node_put() when
done. Add the missing of_node_put() to release the refcount.

Signed-off-by: Yangtao Li 
---
 arch/csky/kernel/smp.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/csky/kernel/smp.c b/arch/csky/kernel/smp.c
index 36ebaf9834e1..adec56df613b 100644
--- a/arch/csky/kernel/smp.c
+++ b/arch/csky/kernel/smp.c
@@ -139,11 +139,17 @@ void __init setup_smp(void)
int cpu;
 
while ((node = of_find_node_by_type(node, "cpu"))) {
-   if (!of_device_is_available(node))
+   if (!of_device_is_available(node)) {
+   of_node_put(node);
continue;
+   }
 
-   if (of_property_read_u32(node, "reg", &cpu))
+   if (of_property_read_u32(node, "reg", &cpu)) {
+   of_node_put(node);
continue;
+   }
+
+   of_node_put(node);
 
if (cpu >= NR_CPUS)
continue;
-- 
2.17.0

Re: [PATCH v1 7/7] drm: remove include of drmP.h from drm_gem_cma_helper.h

[David Lechner]

On 12/26/18 3:03 PM, Sam Ravnborg wrote:

Fix fallout in various files/drivers.



What fallout is being fixed? It would be helpful if we received the full
patch series for context. It would also be nice to have a more detailed
description in this commit message.