Re: [PATCH v5 4/4] zram: introduce zram memory tracking

[Minchan Kim]

On Fri, Apr 20, 2018 at 11:09:21AM +0900, Minchan Kim wrote:
> On Wed, Apr 18, 2018 at 02:07:15PM -0700, Andrew Morton wrote:
> > On Wed, 18 Apr 2018 10:26:36 +0900 Minchan Kim  wrote:
> > 
> > > Hi Andrew,
> > > 
> > > On Tue, Apr 17, 2018 at 02:59:21PM -0700, Andrew Morton wrote:
> > > > On Mon, 16 Apr 2018 18:09:46 +0900 Minchan Kim  
> > > > wrote:
> > > > 
> > > > > zRam as swap is useful for small memory device. However, swap means
> > > > > those pages on zram are mostly cold pages due to VM's LRU algorithm.
> > > > > Especially, once init data for application are touched for launching,
> > > > > they tend to be not accessed any more and finally swapped out.
> > > > > zRAM can store such cold pages as compressed form but it's pointless
> > > > > to keep in memory. Better idea is app developers free them directly
> > > > > rather than remaining them on heap.
> > > > > 
> > > > > This patch tell us last access time of each block of zram via
> > > > > "cat /sys/kernel/debug/zram/zram0/block_state".
> > > > > 
> > > > > The output is as follows,
> > > > >   30075.033841 .wh
> > > > >   30163.806904 s..
> > > > >   30263.806919 ..h
> > > > > 
> > > > > First column is zram's block index and 3rh one represents symbol
> > > > > (s: same page w: written page to backing store h: huge page) of the
> > > > > block state. Second column represents usec time unit of the block
> > > > > was last accessed. So above example means the 300th block is accessed
> > > > > at 75.033851 second and it was huge so it was written to the backing
> > > > > store.
> > > > > 
> > > > > Admin can leverage this information to catch cold|incompressible pages
> > > > > of process with *pagemap* once part of heaps are swapped out.
> > > > 
> > > > A few things..
> > > > 
> > > > - Terms like "Admin can" and "Admin could" are worrisome.  How do we
> > > >   know that admins *will* use this?  How do we know that we aren't
> > > >   adding a bunch of stuff which nobody will find to be (sufficiently)
> > > >   useful?  For example, is there some userspace tool to which you are
> > > >   contributing which will be updated to use this feature?
> > > 
> > > Actually, I used this feature two years ago to find memory hogger
> > > although the feature was very fast prototyping. It was very useful
> > > to reduce memory cost in embedded space.
> > > 
> > > The reason I am trying to upstream the feature is I need the feature
> > > again. :)
> > > 
> > > Yub, I have a userspace tool to use the feature although it was
> > > not compatible with this new version. It should be updated with
> > > new format. I will find a time to submit the tool.
> > 
> > hm, OK, can we get this info into the changelog?  
> 
> No problem. I will add as follows,
> 
> "I used the feature a few years ago to find memory hoggers in userspace
> to notice them what memory they have wasted without touch for a long time.
> With it, they could reduce unnecessary memory space. However, at that time,
> I hacked up zram for the feature but now I need the feature again so
> I decided it would be better to upstream rather than keeping it alone.
> I hope I submit the userspace tool to use the feature soon"
> 
> > 
> > > > 
> > > > - block_state's second column is in microseconds since some
> > > >   undocumented time.  But how is userspace to know how much time has
> > > >   elapsed since the access?  ie, "current time".
> > > 
> > > It's a sched_clock so it should be elapsed time since the system boot.
> > > I should have written it explictly.
> > > I will fix it.
> > > 
> > > > 
> > > > - Is the sched_clock() return value suitable for exporting to
> > > >   userspace?  Is it monotonic?  Is it consistent across CPUs, across
> > > >   CPU hotadd/remove, across suspend/resume, etc?  Does it run all the
> > > >   way up to 2^64 on all CPU types, or will some processors wrap it at
> > > >   (say) 32 bits?  etcetera.  Documentation/timers/timekeeping.txt
> > > >   points out that suspend/resume can mess it up and that the counter
> > > >   can drift between cpus.
> > > 
> > > Good point!
> > > 
> > > I just referenced it from ftrace because I thought the goal is similiar
> > > "no need to be exact unless the drift is frequent but wanted to be fast"
> > > 
> > > AFAIK, ftrace/printk is active user of the function so if the problem
> > > happens frequently, it might be serious. :)
> > 
> > It could be that ktime_get() is a better fit here - especially if
> > sched_clock() goes nuts after resume.  Unfortunately ktime_get()
> > appears to be totally undocumented :(
> > 
> 
> I will use ktime_get_boottime(). With it, zram is not demamaged by
> suspend/resume and code would be more simple/clear. For user, it
> would be more straightforward to parse the time.
> 
> Thanks for good suggestion, Andrew!
> 

Hey Andrew,

This is updated patch for 4/4.
If you want to replace full patchset, please tell me. I will send full
patchset.

Linux 4.9.95

[Greg KH]

I'm announcing the release of the 4.9.95 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/arm/include/asm/kvm_host.h |6 
 arch/arm/include/asm/kvm_mmu.h  |   10 
 arch/arm/include/asm/kvm_psci.h |   27 
 arch/arm/kvm/arm.c  |   11 
 arch/arm/kvm/handle_exit.c  |4 
 arch/arm/kvm/psci.c |  143 +
 arch/arm64/Kconfig  |   17 
 arch/arm64/crypto/sha256-core.S | 2061 
 arch/arm64/crypto/sha512-core.S | 1085 ++
 arch/arm64/include/asm/assembler.h  |   19 
 arch/arm64/include/asm/barrier.h|   23 
 arch/arm64/include/asm/cpucaps.h|3 
 arch/arm64/include/asm/cputype.h|6 
 arch/arm64/include/asm/futex.h  |9 
 arch/arm64/include/asm/kvm_host.h   |5 
 arch/arm64/include/asm/kvm_mmu.h|   38 
 arch/arm64/include/asm/kvm_psci.h   |   27 
 arch/arm64/include/asm/memory.h |   15 
 arch/arm64/include/asm/mmu.h|   39 
 arch/arm64/include/asm/processor.h  |   24 
 arch/arm64/include/asm/sysreg.h |2 
 arch/arm64/include/asm/uaccess.h|  153 -
 arch/arm64/kernel/Makefile  |4 
 arch/arm64/kernel/arm64ksyms.c  |4 
 arch/arm64/kernel/bpi.S |   75 
 arch/arm64/kernel/cpu_errata.c  |  189 +
 arch/arm64/kernel/cpufeature.c  |   10 
 arch/arm64/kernel/entry.S   |   25 
 arch/arm64/kvm/handle_exit.c|   16 
 arch/arm64/kvm/hyp/hyp-entry.S  |   20 
 arch/arm64/kvm/hyp/switch.c |5 
 arch/arm64/lib/clear_user.S |6 
 arch/arm64/lib/copy_in_user.S   |4 
 arch/arm64/mm/context.c |   12 
 arch/arm64/mm/fault.c   |   34 
 arch/arm64/mm/proc.S|7 
 arch/parisc/kernel/drivers.c|4 
 arch/s390/kernel/ipl.c  |1 
 drivers/acpi/nfit/core.c|   22 
 drivers/block/loop.c|   12 
 drivers/firmware/psci.c |   57 
 drivers/gpu/drm/radeon/radeon_object.c  |3 
 drivers/hv/channel_mgmt.c   |2 
 drivers/hwmon/ina2xx.c  |3 
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c   |4 
 drivers/net/phy/micrel.c|   42 
 drivers/net/slip/slhc.c |5 
 drivers/net/usb/cdc_ether.c |6 
 drivers/net/usb/lan78xx.c   |3 
 drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c  |2 
 drivers/s390/cio/qdio_main.c|   42 
 drivers/vhost/vhost.c   |8 
 fs/namei.c  |3 
 include/kvm/arm_psci.h  |   51 
 include/linux/arm-smccc.h   |  165 +
 include/linux/mm.h  |4 
 include/linux/psci.h|   14 
 include/net/bluetooth/hci_core.h|2 
 include/net/slhc_vj.h   |1 
 include/uapi/linux/psci.h   |3 
 kernel/events/core.c|6 
 net/bluetooth/hci_conn.c|   29 
 net/bluetooth/hci_event.c   |   15 
 net/bluetooth/l2cap_core.c  |2 
 net/rds/send.c  |   15 
 net/sunrpc/auth_gss/gss_krb5_crypto.c   |3 
 tools/perf/tests/code-reading.c |   20 
 tools/perf/util/intel-pt-decoder/intel-pt-decoder.c |   64 
 tools/perf/util/intel-pt-decoder/intel-pt-decoder.h |2 
 tools/perf/util/intel-pt.c  |   37 
 71 files changed, 4442 insertions(+), 350 deletions(-)

Adrian Hunter (4):
  perf intel-pt: Fix overlap detection to identify consecutive buffers 
correctly
  perf intel-pt: Fix sync_switch
  perf 

Re: [PATCH 4.9 00/66] 4.9.95-stable review

[Greg Kroah-Hartman]

On Thu, Apr 19, 2018 at 03:04:05PM -0500, Dan Rue wrote:
> On Thu, Apr 19, 2018 at 04:03:05PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Apr 19, 2018 at 04:42:56PM +0530, Naresh Kamboju wrote:
> > > >
> > > > Can you try 'git bisect'?  I'll hold off on releasing 4.9.y until this
> > > > gets figured out.
> > > 
> > > After reverting this patch, network started works on arm32 x15 device.
> > > d7ba3c00047d ("net: phy: micrel: Restore led_mode and clk_sel on resume")
> > 
> > Thanks for letting me know, I've now reverted that commit.
> 
> Alright here we go.
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Great, thanks for testing and letting me know.

greg k-h

[GIT PULL] MMC fixes for v.4.17-rc2

[Ulf Hansson]

Hi Linus,

Here's a PR with a couple of MMC fixes intended for v4.17-rc2. Details about
the highlights are as usual found in the signed tag.

Please pull this in!

Kind regards
Ulf Hansson


The following changes since commit fc167daff581c01ebce8695e9618231cae3561a1:

  mmc: tmio: Fix error handling when issuing CMD23 (2018-04-04 12:21:27 +0200)

are available in the git repository at:

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

for you to fetch changes up to 0cbc94daa55441c21999e96a07061952d873dcb7:

  mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs (2018-04-19 
14:57:17 +0200)


MMC host:
 - sdhci-pci: Fixup tuning for AMD for eMMC HS200 mode
 - renesas_sdhi_internal_dmac: Avoid data corruption by limiting DMA RX


Daniel Kurtz (1):
  mmc: sdhci-pci: Only do AMD tuning for HS200

Wolfram Sang (1):
  mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 39 ++-
 drivers/mmc/host/sdhci-pci-core.c | 25 +++--
 2 files changed, 56 insertions(+), 8 deletions(-)

Re: [PATCH] serial: imx: fix cached UCR2 read on software reset

[Uwe Kleine-König]

Hello Stefan,

On Thu, Apr 19, 2018 at 11:37:23PM +0200, Stefan Agner wrote:
> On 16.04.2018 17:35, Stefan Agner wrote:
> > To reset the UART the SRST needs be cleared (low active). According
> > to the documentation the bit will remain active for 4 module clocks
> > until it is cleared (set to 1).
> > 
> > Hence the real register need to be read in case the cached register
> > indcates that the SRST bit is zero.
> > 
> > This bug lead to wrong baudrate because the baud rate register got
> > restored before reset completed in imx_flush_buffer.
> 
> Given that you reviewed my other patch rather quickly, you might have
> overlooked this one?

no I didn't, still the ping was justified. I didn't look into it at once
because I didn't feel like opening the refman.
 
> Since it is a regression, this should go into v4.17 still...

That's right,

Reviewed-by: Uwe Kleine-König 

I wonder what is different on your side that made it break. I didn't see
any breakage and tested that on a handful of different machines.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH v3] gpio: dwapb: Add support for 1 interrupt per port A GPIO

[Hoan Tran]

Hi Phil,

On Thu, Apr 19, 2018 at 3:03 AM, Phil Edworthy
 wrote:
> Hi Hoan
>
> On 18 April 2018 08:03 Hoan Tran wrote:
>> On Fri, Apr 13, 2018 at 9:47 AM, Phil Edworthy wrote:
>> > On 13 April 2018 17:37 Hoan Tran wrote:
>> >> On Fri, Apr 13, 2018 at 1:51 AM, Phil Edworthy wrote:
>> >> > The DesignWare GPIO IP can be configured for either 1 interrupt or
>> >> > 1 per GPIO in port A, but the driver currently only supports 1 
>> >> > interrupt.
>> >> > See the DesignWare DW_apb_gpio Databook description of the
>> >> > 'GPIO_INTR_IO' parameter.
>> >> >
>> >> > This change allows the driver to work with up to 32 interrupts, it
>> >> > will get as many interrupts as specified in the DT 'interrupts' 
>> >> > property.
>> >> > It doesn't do anything clever with the different interrupts, it
>> >> > just calls the same handler used for single interrupt hardware.
>> >> >
>> >> > Signed-off-by: Phil Edworthy 
>> >> > ---
>> >> > One point to mention is that I have made it possible for users to
>> >> > have unconncted interrupts by specifying holes in the list of 
>> >> > interrupts.
>> >> > This is done by supporting the interrupts-extended DT prop.
>> >> > However, I have no use for this and had to hack some test case for this.
>> >> > Perhaps the driver should support 1 interrupt or all GPIOa as 
>> >> > interrupts?
>> >> >
>> >> > v3:
>> >> >  - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid
>> >> > bisect problems
>> >> > v2:
>> >> >  - Replaced interrupt-mask DT prop with support for the interrupts-
>> >> extended
>> >> >prop. This means replacing the call to irq_of_parse_and_map() with
>> calls
>> >> >to of_irq_parse_one() and irq_create_of_mapping().
>> >> >
>> >> > Note: There are a few *code* lines over 80 chars, but this is just
>> guidance,
>> >> >right? Especially as there are already some lines over 80 chars.
>> >> > ---
>> > [snip]
>> >
>> >> > -   if (has_acpi_companion(dev) && pp->idx == 0)
>> >> > -   pp->irq = 
>> >> > platform_get_irq(to_platform_device(dev), 0);
>> >> > +   if (has_acpi_companion(dev) && pp->idx == 0) {
>> >> > +   pp->irq[0] = 
>> >> > platform_get_irq(to_platform_device(dev),
>> 0);
>> >> > +   if (pp->irq[0])
>> >> > +   pp->has_irq = true;
>> >> > +   }
>> >>
>> >> It doesn't work for ACPI. Could you do the same logic for ACPI?
>> > I don’t have access to any device that was baked (i.e. fabbed) with
>> > multiple output interrupts from the Synopsys GPIO blocks and use ACPI.
>> > I don't know if any such device exists.
>>
>> Below code is tested on X-Gene system which supports 1 interrupt per GPIO
>> on Port A. You can update it into your patch.
>>
>> -   if (has_acpi_companion(dev) && pp->idx == 0)
>> -   pp->irq = platform_get_irq(to_platform_device(dev), 
>> 0);
>> +   if (has_acpi_companion(dev) && pp->idx == 0) {
>> +   unsigned int j;
>> +   for (j = 0; j < pp->ngpio; j++) {
>> +   pp->irq[j] =
>> platform_get_irq(to_platform_device(dev), j);
>> +   if (pp->irq[j])
>> +   pp->has_irq = true;
>> +   }
>> +   }
> Since I've already got some reviewed-by and acks for v4, I'll leave it to 
> Linus
> to decide if he wants me to roll your changes into this patch or for you to
> submit a separate patch.
>

I prefer this patch works for both DTB and ACPI. Btw let Linus decide.

Thanks
Hoan

> Thanks
> Phil
>
>
>> >> > pp->irq_shared  = false;
>> >> > pp->gpio_base   = -1;
>> >> > diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
>> >> > b/drivers/mfd/intel_quark_i2c_gpio.c
>> >> > index 90e35de..5bddb84 100644
>> >> > --- a/drivers/mfd/intel_quark_i2c_gpio.c
>> >> > +++ b/drivers/mfd/intel_quark_i2c_gpio.c
>> >> > @@ -233,7 +233,8 @@ static int intel_quark_gpio_setup(struct
>> >> > pci_dev
>> >> *pdev, struct mfd_cell *cell)
>> >> > pdata->properties->idx  = 0;
>> >> > pdata->properties->ngpio= INTEL_QUARK_MFD_NGPIO;
>> >> > pdata->properties->gpio_base=
>> INTEL_QUARK_MFD_GPIO_BASE;
>> >> > -   pdata->properties->irq  = pdev->irq;
>> >> > +   pdata->properties->irq[0]   = pdev->irq;
>> >> > +   pdata->properties->has_irq  = true;
>> >> > pdata->properties->irq_shared   = true;
>> >> >
>> >> > cell->platform_data = pdata; diff --git
>> >> > a/include/linux/platform_data/gpio-dwapb.h
>> >> > b/include/linux/platform_data/gpio-dwapb.h
>> >> > index 2dc7f4a..5a52d69 100644
>> >> > --- a/include/linux/platform_data/gpio-dwapb.h
>> >> > +++ b/include/linux/platform_data/gpio-dwapb.h
>> >> > @@ -19,7 +19,8 @@ struct dwapb_port_property {
>> >> > unsigned 

Re: [PATCH 06/61] crypto: simplify getting .drvdata

[Krzysztof Kozlowski]

On Thu, Apr 19, 2018 at 4:05 PM, Wolfram Sang
 wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang 
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
>  drivers/crypto/exynos-rng.c   | 6 ++
>  drivers/crypto/picoxcell_crypto.c | 6 ++
>  2 files changed, 4 insertions(+), 8 deletions(-)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v2] mmc: sdhci-cadence: fix logically and structurally dead code

[Adrian Hunter]

On 19/04/18 18:59, Gustavo A. R. Silva wrote:
> Currently, the code block inside the for loop will never execute
> more than once, because the function returns inmediately after
> the first iteration, hence the execution of the code at the second
> iteration is structurally dead and, code at line 281: return 0; is
> never reached.
> 
> Fix this by checking _ret_ before return.
> 
> Addresses-Coverity-ID: 1468009 ("Logically dead code")
> Addresses-Coverity-ID: 1468002 ("Structurally dead code")
> Suggested-by: Masahiro Yamada 
> Signed-off-by: Gustavo A. R. Silva 

Acked-by: Adrian Hunter 

> ---
> Changes in v2:
>  - Update changelog.
>  - Drop the 'Fixes' tag.
>  - Add check on ret instead of removing the "return ret;" line.
>  - Thanks to Masahiro Yamada for the feedback provided.
> 
>  drivers/mmc/host/sdhci-cadence.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-cadence.c 
> b/drivers/mmc/host/sdhci-cadence.c
> index bc30d16..7a343b8 100644
> --- a/drivers/mmc/host/sdhci-cadence.c
> +++ b/drivers/mmc/host/sdhci-cadence.c
> @@ -274,8 +274,8 @@ static int sdhci_cdns_set_tune_val(struct sdhci_host 
> *host, unsigned int val)
>   ret = readl_poll_timeout(reg, tmp,
>!(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
>0, 1);
> -
> - return ret;
> + if (ret)
> + return ret;
>   }
>  
>   return 0;
> 

RE: [PATCH][next] ASoC: rt5668: fix incorrect 'and' operator

[Bard Liao]

> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Sent: Thursday, April 19, 2018 10:35 PM
> To: Bard Liao; Oder Chiou; Liam Girdwood; Mark Brown; Jaroslav Kysela;
> Takashi Iwai; alsa-de...@alsa-project.org
> Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH][next] ASoC: rt5668: fix incorrect 'and' operator
> 
> From: Colin Ian King 
> 
> Currently logical and is being used instead of bitwise and. Fix this.
> 
> Detected by CoverityScan, CID#1468008 ("Logical vs bitwise operator")
> 
> Fixes: d59fb2856223 ("ASoC: rt5668: add rt5668B codec driver")
> Signed-off-by: Colin Ian King 

Acked-By: Bard Liao 

> ---
>  sound/soc/codecs/rt5668.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/codecs/rt5668.c b/sound/soc/codecs/rt5668.c
> index 52a343f96eb2..3c19d03f2446 100644
> --- a/sound/soc/codecs/rt5668.c
> +++ b/sound/soc/codecs/rt5668.c
> @@ -1194,7 +1194,7 @@ static int set_filter_clk(struct snd_soc_dapm_widget
> *w,
>   int ref, val, reg, idx = -EINVAL;
>   static const int div[] = {1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48};
> 
> - val = snd_soc_component_read32(component, RT5668_GPIO_CTRL_1)
> &&
> + val = snd_soc_component_read32(component, RT5668_GPIO_CTRL_1) &
>   RT5668_GP4_PIN_MASK;
>   if (w->shift == RT5668_PWR_ADC_S1F_BIT &&
>   val == RT5668_GP4_PIN_ADCDAT2)
> --
> 2.17.0
> 
> 
> --Please consider the environment before printing this e-mail.

Re: [PATCH v9 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 04/18/2018 05:40 PM, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 
> Reviewed-by: Laurent Pinchart 
> Reviewed-by: Rob Herring 
> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 
> ++
>  1 file changed, 60 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> 

Reviewed-by: Vladimir Zapolskiy 

--
With best wishes,
Vladimir

Re: 4.15.17 regression: bisected: timeout during microcode update

[Vitezslav Samel]

On Thu, Apr 19, 2018 at 06:37:34PM +0200, Borislav Petkov wrote:
> On Thu, Apr 19, 2018 at 03:46:27PM +0200, Vitezslav Samel wrote:
> > 
> > microcode: __reload_late: CPU0
> > microcode: __reload_late: CPU3
> > microcode: __reload_late: CPU2
> > microcode: __reload_late: CPU1
> > microcode: __reload_late: CPU0 reloading
> > microcode: __reload_late: CPU2 reloading
> > microcode: __reload_late: CPU1 reloading
> > microcode: __reload_late: CPU3 reloading
> > microcode: find_patch: CPU2, NADA
> 
> Ok, I think I have it. Please run the patch below, it still has the
> debugging output so please paste it here once you've done the exact same
> exercise.
> 
> It should not explode this time! (Famous last words :-))

  ;-)  This time it works.

(Ashok: all test were against stable 4.16.3)

--
microcode: __reload_late: CPU1
microcode: __reload_late: CPU0
microcode: __reload_late: CPU2
microcode: __reload_late: CPU3
microcode: __reload_late: CPU1 reloading
microcode: __reload_late: CPU0 reloading
microcode: __reload_late: CPU3 reloading
microcode: __reload_late: CPU2 reloading
microcode: find_patch: CPU0, phdr: 0x24, uci: 0x1c
microcode: find_patch: CPU0, find_matching_signature: sig: 0x306c3, pf: 0x2
microcode: find_patch: CPU0, found phdr: 0x24
microcode: updated to revision 0x24, date = 2018-01-21
microcode: __reload_late: CPU0 waiting to exit
microcode: find_patch: CPU3, phdr: 0x24, uci: 0x1c
microcode: find_patch: CPU3, find_matching_signature: sig: 0x306c3, pf: 0x2
microcode: find_patch: CPU3, found phdr: 0x24
microcode: __reload_late: CPU3 waiting to exit
microcode: find_patch: CPU2, phdr: 0x24, uci: 0x1c
microcode: find_patch: CPU2, find_matching_signature: sig: 0x306c3, pf: 0x2
microcode: find_patch: CPU2, found phdr: 0x24
microcode: __reload_late: CPU2 waiting to exit
microcode: find_patch: CPU1, phdr: 0x24, uci: 0x1c
microcode: find_patch: CPU1, find_matching_signature: sig: 0x306c3, pf: 0x2
microcode: find_patch: CPU1, found phdr: 0x24
microcode: __reload_late: CPU1 waiting to exit
x86/CPU: CPU features have changed after loading microcode, but might not take 
effect.
x86/CPU: Please consider either early loading through initrd/built-in or a 
potential BIOS update.
--

Thank you very much,

Vita


> Thx!
> 
> ---
>  arch/x86/kernel/cpu/microcode/core.c  | 11 +++
>  arch/x86/kernel/cpu/microcode/intel.c | 17 ++---
>  2 files changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/microcode/core.c 
> b/arch/x86/kernel/cpu/microcode/core.c
> index 10c4fc2c91f8..e84877b0f7d7 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -553,6 +553,8 @@ static int __reload_late(void *info)
>   enum ucode_state err;
>   int ret = 0;
>  
> + pr_info("%s: CPU%d\n", __func__, cpu);
> +
>   /*
>* Wait for all CPUs to arrive. A load will not be attempted unless all
>* CPUs show up.
> @@ -560,20 +562,21 @@ static int __reload_late(void *info)
>   if (__wait_for_cpus(_cpus_in, NSEC_PER_SEC))
>   return -1;
>  
> + pr_info("%s: CPU%d reloading\n", __func__, cpu);
> +
>   spin_lock(_lock);
>   apply_microcode_local();
>   spin_unlock(_lock);
>  
> + /* siblings return UCODE_OK because their engine got updated already */
>   if (err > UCODE_NFOUND) {
>   pr_warn("Error reloading microcode on CPU %d\n", cpu);
> - return -1;
> - /* siblings return UCODE_OK because their engine got updated already */
>   } else if (err == UCODE_UPDATED || err == UCODE_OK) {
>   ret = 1;
> - } else {
> - return ret;
>   }
>  
> + pr_info("%s: CPU%d waiting to exit\n", __func__, cpu);
> +
>   /*
>* Increase the wait timeout to a safe value here since we're
>* serializing the microcode update and that could take a while on a
> diff --git a/arch/x86/kernel/cpu/microcode/intel.c 
> b/arch/x86/kernel/cpu/microcode/intel.c
> index 32b8e5724f96..725e0bb6df03 100644
> --- a/arch/x86/kernel/cpu/microcode/intel.c
> +++ b/arch/x86/kernel/cpu/microcode/intel.c
> @@ -485,7 +485,6 @@ static void show_saved_mc(void)
>   */
>  static void save_mc_for_early(u8 *mc, unsigned int size)
>  {
> -#ifdef CONFIG_HOTPLUG_CPU
>   /* Synchronization during CPU hotplug. */
>   static DEFINE_MUTEX(x86_cpu_microcode_mutex);
>  
> @@ -495,7 +494,6 @@ static void save_mc_for_early(u8 *mc, unsigned int size)
>   show_saved_mc();
>  
>   mutex_unlock(_cpu_microcode_mutex);
> -#endif
>  }
>  
>  static bool load_builtin_intel_microcode(struct cpio_data *cp)
> @@ -727,21 +725,32 @@ static struct microcode_intel *find_patch(struct 
> ucode_cpu_info *uci)
>  {
>   struct microcode_header_intel *phdr;
>   struct ucode_patch *iter, 

Re: [PATCH v9 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Vladimir Zapolskiy]

Hi Jacopo,

On 04/18/2018 05:40 PM, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output converter.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/bridge/Kconfig|   6 +
>  drivers/gpu/drm/bridge/Makefile   |   1 +
>  drivers/gpu/drm/bridge/thc63lvd1024.c | 206 
> ++
>  3 files changed, 213 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

Reviewed-by: Vladimir Zapolskiy 

--
With best wishes,
Vladimir

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[David Herrmann]

Hi

On Fri, Apr 20, 2018 at 7:44 AM, Sergey Senozhatsky
 wrote:
> On (04/20/18 06:37), David Herrmann wrote:
>>
>> I get lots of timer-errors on Arch-Linux booting current master, after
>> a suspend/resume cycle. Just a selection of errors I see on resume:
>
> Hello David,
> Any chance you can revert the patches in question and test? I'm running
> ARCH (4.17.0-rc1-dbg-00042-gaa03ddd9c434) and suspend/resume cycle does
> not trigger any errors. Except for this one
>
> kernel: do_IRQ: 0.55 No irq handler for vector

I can easily reproduce it by sleeping for >5min, so the systemd
watchdog timers are triggered. The patches don't revert cleanly, so I
didn't look into booting without them, yet. I will try just linking
the monotonic clock to the monotonic_active clock later.

Also, doesn't this hunk in 72199320d49d need a 'break;':

diff --git a/kernel/time/posix-stubs.c b/kernel/time/posix-stubs.c
index b258bee13b02..6259dbc0191a 100644
--- a/kernel/time/posix-stubs.c
+++ b/kernel/time/posix-stubs.c
@@ -73,6 +73,8 @@ int do_clock_gettime(clockid_t which_clock, struct
timespec64 *tp)
case CLOCK_BOOTTIME:
get_monotonic_boottime64(tp);
break;
+   case CLOCK_MONOTONIC_ACTIVE:
+   ktime_get_active_ts64(tp);
default:
return -EINVAL;
}

Re: [PATCH v2] ARM64: dts: meson-axg: enable the eMMC controller

[Ulf Hansson]

On 19 April 2018 at 19:58, Kevin Hilman  wrote:
> Yixun Lan  writes:
>
>> From: Nan Li 
>>
>> The IP of eMMC controller in AXG is similiar to Meson-GX series.
>> Here we add the initial support of the HS200 mode with
>> clock running at 166MHz (to be safe), since we found some eMMC chip
>> fail to run at 200MHz due to tunning phase error.
>>
>> Signed-off-by: Nan Li 
>> Signed-off-by: Yixun Lan 
>
> Applied to v4.18/dt64
>
>> ---
>> Hi Kevin
>>   Please note this patch actually depend on the eMMC driver here [0].
>>   Still a few problem to solve, to improve the tuning phase driver to make
>> the clock running at 200MHz, and to further support the HS400 mode.
>> Anyway, this patch itself is quite independent.
>
> The driver changes are queued for v4.18 also.  Good!

Right, may I consider that as an ack? :-)

Kind regards
Uffe

>
> Kevin
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] serial: imx: enable IMX21_UCR3_RXDMUXSEL for non-dte-mode

[Uwe Kleine-König]

Hello Chris,

On Fri, Apr 20, 2018 at 09:07:59AM +0800, Chris Ruehl wrote:
> Fix a problem introduced with
> commit e61c38d85b73 ("serial: imx: setup DCEDTE early and ensure DCD and RI 
> irqs to be off")
> result in non dte-mode imx-uart fail receive data.
> By add back IMX21_UCR3_RXDMUXSEL the serial port works as expected.
> 
> Signed-off-by: Chris Ruehl 
> ---
>  drivers/tty/serial/imx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 91f3a1a..3d09933 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1391,7 +1391,7 @@ static int imx_uart_startup(struct uart_port *port)
>  
>   ucr3 = imx_uart_readl(sport, UCR3);
>  
> - ucr3 |= UCR3_DTRDEN | UCR3_RI | UCR3_DCD;
> + ucr3 |= IMX21_UCR3_RXDMUXSEL | UCR3_DTRDEN | UCR3_RI | UCR3_DCD;
>  
>   if (sport->dte_mode)
>   /* disable broken interrupts */

Doesn't 6df765dca378bddf994cfd2044acafa501bd800f fix this for you?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

linux-next: Tree for Apr 20

[Stephen Rothwell]

Hi all,

Changes since 20180419:

I have added a patch to the arm-current tree to fix build problems
discovered overnight.

Non-merge commits (relative to Linus' tree): 1278
 1324 files changed, 47025 insertions(+), 20625 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (87ef12027b9b Merge tag 'ceph-for-4.17-rc2' of 
git://github.com/ceph/ceph-client)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (28913ee8191a netfilter: nf_nat_snmp_basic: add 
correct dependency to Makefile)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (fe680ca02c1e ARM: replace unnecessary perl with sed 
and the shell $(( )) operator)
Applying: arm: check for A as well as B type sybols when calculating BSS size
Merging arm64-fixes/for-next/fixes (b2d71b3cda19 arm64: signal: don't force 
known signals to SIGKILL)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (56376c5864f8 powerpc/kvm: Fix lockups when running 
KVM guests on Power8)
Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (1255fcb2a655 net/smc: fix shutdown in state SMC_LISTEN)
Merging bpf/master (0a0a7e00a250 tools/bpf: fix test_sock and test_sock_addr.sh 
failure)
Merging ipsec/master (b48c05ab5d32 xfrm: Fix warning in xfrm6_tunnel_net_exit.)
Merging netfilter/master (d71efb599ad4 netfilter: nf_tables: fix out-of-bounds 
in nft_chain_commit_update)
Merging ipvs/master (765cca91b895 netfilter: conntrack: include kmemleak.h for 
kmemleak_not_leak())
Merging wireless-drivers/master (77e30e10ee28 iwlwifi: mvm: query regdb for wmm 
rule if needed)
Merging mac80211/master (83826469e36b cfg80211: fix possible memory leak in 
regdb_query_country())
Merging rdma-fixes/for-rc (60cc43fc8884 Linux 4.17-rc1)
Merging sound-current/for-linus (8a56ef4f3ffb ALSA: rawmidi: Fix missing input 
substream checks in compat ioctls)
Merging pci-current/for-linus (60cc43fc8884 Linux 4.17-rc1)
Merging driver-core.current/driver-core-linus (ed4564babeee drivers: change 
struct device_driver::coredump() return type to void)
Merging tty.current/tty-linus (60cc43fc8884 Linux 4.17-rc1)
Merging usb.current/usb-linus (60cc43fc8884 Linux 4.17-rc1)
Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: 
add binging for r8a77965)
Merging usb-serial-fixes/usb-linus (470b5d6f0cf4 USB: serial: ftdi_sio: use 
jtag quirk for Arrow USB Blaster)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes (60cc43fc8884 Linux 4.17-rc1)
Merging staging.current/staging-linus (edf5c17d866e staging: irda: remove 
remaining remants of irda code removal)
Merging char-misc.current/char-misc-linus (60cc43fc8884 Linux 4.17-rc1)
Merging input-current/for-linus (664b0bae0b87 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (f444ec106407 crypto: ccree - remove unused 

Re: [PATCH v3 1/5] clk: Extract OF clock helpers in

[Geert Uytterhoeven]

Hi Stephen, Rob,

On Fri, Apr 20, 2018 at 12:25 AM, Stephen Boyd  wrote:
> Quoting Geert Uytterhoeven (2018-04-18 07:50:01)
>> The use of of_clk_get_parent_{count,name}() and of_clk_init() is not
>> limited to clock providers.
>>
>> Hence move these helpers into their own header file, so callers that are
>> not clock providers no longer have to include .
>>
>> Suggested-by: Stephen Boyd 
>> Signed-off-by: Geert Uytterhoeven 
>> Reviewed-by: Heiko Stuebner 
>> ---
>> v3:
>>   - Add Reviewed-by,
>>   - Add SPDX-License-Identifier,
>>   - Add to clock section in MAINTAINERS (note that Rob is still listed
>> as a maintainer, too, due to the include/linux/of*.h catch-all
>> rule),
>
> Can you X: out this file so Rob is happy? Or that doesn't work?

I guess that should work.

My point here is that due to the catch-all rule, he's listed as maintainer
for of_{dma,gpio,irq,iommu,mdio,net,pci} too, which are all helpers for
other subsystems. Perhaps these should be X'd-out too?
Or is it OK without X-ing them out, as the clock maintainers are now shown, too?

Rob: What's your preference?

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Hello

[Mrs. Pamela Atuegbe]

Am Mrs.Pamela Atuegbe, I work in one of the prime bank here in burkina 
faso, i want the bank to transfer the money left by our late customer 
is a foreigner from Korea. can you investment this money and also help 
the poor' the amount value at $13,300,000.00 (Thirteen Million Three 
Hundred Thousand United States American Dollars), left in his account 
still unclaimed. more details will be giving to you if you are 
interested, I wait your reply thanks.


Yours sincerely

Name: Mrs. Pamela Atuegbe

Re: [PATCH] MAINTAINERS: Rakesh Iyer can't be reached anymore

[Jon Hunter]

On 19/04/18 18:42, Wolfram Sang wrote:
> The current mail address is rejected, last activity (with a different
> address) in git-history is from 2012. Remove this.
> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> If somebody knows a recent address, then we can simply update, of course.
> 
>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c4b6d379423e..0307426c2564 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13833,7 +13833,6 @@ S:Supported
>  F:   drivers/iommu/tegra*
>  
>  TEGRA KBC DRIVER
> -M:   Rakesh Iyer 
>  M:   Laxman Dewangan 
>  S:   Supported
>  F:   drivers/input/keyboard/tegra-kbc.c
> 

Acked-by: Jon Hunter 

Cheers!
Jon

Re: [v2] prctl: Deprecate non PR_SET_MM_MAP operations

[Cyrill Gorcunov]

On Fri, Apr 20, 2018 at 11:38:09AM +0900, Sergey Senozhatsky wrote:
> On (04/05/18 21:26), Cyrill Gorcunov wrote:
> [..]
> > -
> >  #ifdef CONFIG_CHECKPOINT_RESTORE
> > if (opt == PR_SET_MM_MAP || opt == PR_SET_MM_MAP_SIZE)
> > return prctl_set_mm_map(opt, (const void __user *)addr, arg4);
> >  #endif
> >  
> > -   if (!capable(CAP_SYS_RESOURCE))
> > -   return -EPERM;
> > -
> > -   if (opt == PR_SET_MM_EXE_FILE)
> > -   return prctl_set_mm_exe_file(mm, (unsigned int)addr);
> > -
> > -   if (opt == PR_SET_MM_AUXV)
> > -   return prctl_set_auxv(mm, addr, arg4);
> 
> Then validate_prctl_map() and prctl_set_mm_exe_file() can be moved
> under CONFIG_CHECKPOINT_RESTORE ifdef.

I don't mind. Could you please make the patch on top of linux-next?

Re: [PATCH] time: tick-sched: use bool for tick_stopped

[yuankuiz]

On 2018-04-20 09:47 AM, yuank...@codeaurora.org wrote:

On 2018-04-11 07:20 AM, yuank...@codeaurora.org wrote:

++
On 2018-04-11 07:09 AM, yuank...@codeaurora.org wrote:

++

On 2018-04-10 10:49 PM, yuank...@codeaurora.org wrote:

Typo...

On 2018-04-10 10:08 PM, yuank...@codeaurora.org wrote:

On 2018-04-10 07:06 PM, Thomas Gleixner wrote:

On Tue, 10 Apr 2018, yuank...@codeaurora.org wrote:

On 2018-04-10 05:10 PM, Thomas Gleixner wrote:
> On Tue, 10 Apr 2018, yuank...@codeaurora.org wrote:
> > On 2018-04-10 04:00 PM, Rafael J. Wysocki wrote:
> > > On Tue, Apr 10, 2018 at 9:33 AM,   wrote:
> > > > From: John Zhao 
> > > >
> > > > Variable tick_stopped returned by tick_nohz_tick_stopped
> > > > can have only true / false values. Since the return type
> > > > of the tick_nohz_tick_stopped is also bool, variable
> > > > tick_stopped nice to have data type as bool in place of unsigned int.
> > > > Moreover, the executed instructions cost could be minimal
> > > > without potiential data type conversion.
> > > >
> > > > Signed-off-by: John Zhao 
> > > > ---
> > > >  kernel/time/tick-sched.h | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/kernel/time/tick-sched.h b/kernel/time/tick-sched.h
> > > > index 6de959a..4d34309 100644
> > > > --- a/kernel/time/tick-sched.h
> > > > +++ b/kernel/time/tick-sched.h
> > > > @@ -48,8 +48,8 @@ struct tick_sched {
> > > > unsigned long   check_clocks;
> > > > enum tick_nohz_mode nohz_mode;
> > > >
> > > > +   booltick_stopped: 1;
> > > > unsigned intinidle  : 1;
> > > > -   unsigned inttick_stopped: 1;
> > > > unsigned intidle_active : 1;
> > > > unsigned intdo_timer_last   : 1;
> > > > unsigned intgot_idle_tick   : 1;
> > >
> > > I don't think this is a good idea at all.
> > >
> > > Please see https://lkml.org/lkml/2017/11/21/384 for example.
> > [ZJ] Thanks for this sharing. Looks like, this patch fall into the case of
> > "Maybe".
>
> This patch falls into the case 'pointless' because it adds extra storage
[ZJ] 1 bit vs 1 bit. no more.


Groan. No. Care to look at the data structure? You create a new 
storage,

[ZJ] Say, {unsigned int, unsigned int, unsigned int, unsigned int,
unsigned int} becomes
  {bool, unsigned int, unsigned int, unsigned int, 
unsigned int}
As specified by the rule No.10 at the section 6.7.2.1 of C99 TC2 
as:
"If enough space remains, a bit-field that immediately follows 
another

bit-field in a
structure shall be packed into adjacent bits of the same unit." 
What

is the new storage so far?

[ZJ] Further prototyping has been given based on gcc for both of
x86_64 and armv8-a,
 unsigned int and bool share the same 1 bytes without the
addtional storage for sure.
 Open this and welcome if any other difference behaviour could be 
captured.

[ZJ] Typo.. change 4 bytes above to 1 byte actually.


which is incidentally merged into the other bitfield by the 
compiler at a
different bit position, but there is no guarantee that a compiler 
does

that. It's free to use distinct storage for that bool based bit.

[ZJ] Per the rule No.10 at section 6.7.2.1 of C99 TC2 as:
" If insufficient space remains, whether  a  bit-field  that  does
not  fit  is  put  into
the  next  unit  or overlaps  adjacent  units  is 
implementation-defined."

So, implementation is never mind which type will be stored if any.


>> > for no benefit at all.
[ZJ] tick_stopped is returned by the tick_nohz_tick_stopped() 
which is bool.

The benefit is no any potiential type conversion could be minded.


A bit stays a bit. 'bool foo : 1;' or 'unsigned int foo : 1' has 
to be
evaluated as a bit. So there is a type conversion from BIT to bool 
required

because BIT != bool.

[ZJ] Per the rule No.9 at section 6.7.2.1 of C99 TC2 as:
"If  the  value  0  or  1  is  stored  into  a  nonzero-width
bit-field  of  types
_Bool, the value of the bit-field shall compare equal to the value 
stored."

Obviously, it is nothing related to type conversion actually.


By chance the evaluation can be done by evaluating the byte in 
which the
bit is placed just because the compiler knows that the remaining 
bits are
not used. There is no guarantee that this is done, it happens to 
be true

for a particular compiler.
[ZJ] Actually, such as GCC owe that kind of guarantee to be 
promised by ABI.
[ZJ] "-mone-byte-bool" could be used by alpha-linux-gcc to override the 
default bool size

 to become 1 byte for even Darwin / powerPC from it's manual.


But that does not make it any more interesting. It just makes the 
code

harder to read and eventually leads to bigger storage.

[ZJ] To get the benctifit to be profiled, it is given as:
number of 

Re: [PATCH] net: phy: TLK10X initial driver submission

[Måns Andersson]

On Thu, Apr 19, 2018 at 02:09:02PM +0200, Andrew Lunn wrote:
> On Thu, Apr 19, 2018 at 10:28:16AM +0200, Måns Andersson wrote:
> > From: Mans Andersson 
> > 
> > Add suport for the TI TLK105 and TLK106 10/100Mbit ethernet phys.
> > 
> > In addition the TLK10X needs to be removed from DP83848 driver as the
> > power back off support is added here for this device.
> > 
> > Datasheet:
> > http://www.ti.com/lit/gpn/tlk106
> > ---
> >  .../devicetree/bindings/net/ti,tlk10x.txt  |  27 +++
> >  drivers/net/phy/Kconfig|   5 +
> >  drivers/net/phy/Makefile   |   1 +
> >  drivers/net/phy/dp83848.c  |   3 -
> >  drivers/net/phy/tlk10x.c   | 209 
> > +
> >  5 files changed, 242 insertions(+), 3 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/net/ti,tlk10x.txt
> >  create mode 100644 drivers/net/phy/tlk10x.c
> > 
> > diff --git a/Documentation/devicetree/bindings/net/ti,tlk10x.txt 
> > b/Documentation/devicetree/bindings/net/ti,tlk10x.txt
> > new file mode 100644
> > index 000..371d0d7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/ti,tlk10x.txt
> > @@ -0,0 +1,27 @@
> > +* Texas Instruments - TLK105 / TLK106 ethernet PHYs
> > +
> > +Required properties:
> > +   - reg - The ID number for the phy, usually a small integer
> > +
> > +Optional properties:
> > +   - ti,power-back-off - Power Back Off Level
> > +   Please refer to data sheet chapter 8.6 and TI Application
> > +   Note SLLA3228
> > +   0 - Normal Operation
> > +   1 - Level 1 (up to 140m cable between TLK link partners)
> > +   2 - Level 2 (up to 100m cable between TLK link partners)
> > +   3 - Level 3 (up to 80m cable between TLK link partners)
> 
> Hi Måns
> 
> Device tree is all about board properties. In most cases, power back
> off is not a board properties, since it depends on the cable length
> and the peer board. If however, your board has two PHYs back to back,
> say to connect to an Ethernet switch, that would be a valid board
> property.
> 
> How are you using this?
> 
> I know of others who would like such a configuration. Marvell PHYs can
> do something similar. I've always suggested adding a PHY tunable. Pass
> the cable length in meters and let the PHY driver pick the nearest it
> can do, rounding up. The Marvell PHYs also support measuring the cable
> length as part of the cable diagnostics. So it would be good to
> reserve a configuration value to mean 'auto' - measure the cable and
> then pick the best power back off. Quickly scanning the data sheet, i
> see that this PHY also has the ability to measure the cable length.
>

Hi Andrew,

Thanks for your comments, highly appreciated!

I'm using this to lock down the PHY to the IEEE 802.3 100m standard cable
length, as opposed to the extended 150m which the PHY supports in its
default operation (see pg. 2 of the data sheet). The reason why I need this
is that the board has too high EMC emissions when running with the default
operation. For me the setting is therefore used as a board property, i.e.
it's not something that will be changed during operation.
 
> > +static int tlk10x_read(struct phy_device *phydev, int reg)
> > +{
> > +   if (reg & ~0x1f) {
> > +   /* Extended register */
> > +   phy_write(phydev, TLK10X_REGCR, 0x001F);
> > +   phy_write(phydev, TLK10X_ADDAR, reg);
> > +   phy_write(phydev, TLK10X_REGCR, 0x401F);
> > +   reg = TLK10X_ADDAR;
> > +   }
> > +
> > +   return phy_read(phydev, reg);
> > +}
> > +
> > +static int tlk10x_write(struct phy_device *phydev, int reg, int val)
> > +{
> > +   if (reg & ~0x1f) {
> > +   /* Extended register */
> > +   phy_write(phydev, TLK10X_REGCR, 0x001F);
> > +   phy_write(phydev, TLK10X_ADDAR, reg);
> > +   phy_write(phydev, TLK10X_REGCR, 0x401F);
> > +   reg = TLK10X_ADDAR;
> > +   }
> > +
> > +   return phy_write(phydev, reg, val);
> > +}
> 
> This looks to be phy_read_mmd() and phy_write_mmd(). If so, please use
> them, they get the locking correct.
>

Yes, that's correct, will fix that.

> 
> > +#ifdef CONFIG_OF_MDIO
> > +static int tlk10x_of_init(struct phy_device *phydev)
> > +{
> > +   struct tlk10x_private *tlk10x = phydev->priv;
> > +   struct device *dev = >mdio.dev;
> > +   struct device_node *of_node = dev->of_node;
> > +   int ret;
> > +
> > +   if (!of_node)
> > +   return 0;
> > +
> > +   ret = of_property_read_u32(of_node, "ti,power-back-off",
> > +  >pwrbo_level);
> > +   if (ret) {
> > +   dev_err(dev, "missing ti,power-back-off property");
> > +   tlk10x->pwrbo_level = 0;
> > +   }
> 
> If we decide to accept this, you should do range checking, and return
> -EINVAL if the value is out of range.

Ok, will fix that.

> 
> > +static int 

RE: [PATCH V2 1/2] clk: imx6sx: add missing lvds2 clock to the clock tree

[Anson Huang]

Anson Huang
Best Regards!


> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Thursday, April 19, 2018 10:57 PM
> To: Anson Huang 
> Cc: ker...@pengutronix.de; Fabio Estevam ;
> robh...@kernel.org; mark.rutl...@arm.com; li...@armlinux.org.uk;
> mturque...@baylibre.com; sb...@kernel.org; S.j. Wang
> ; dl-linux-imx ;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH V2 1/2] clk: imx6sx: add missing lvds2 clock to the clock 
> tree
> 
> On Mon, Mar 19, 2018 at 10:30:44AM +0800, Anson Huang wrote:
> > i.MX6SX has lvds2 (analog clock2), an I/O clock like lvds1.
> > And this lvds2, along with lvds1, can be used to provide external
> > clock source to the internal pll, such as pll4_audio and pll5_video.
> >
> > This patch mainly adds the lvds2 to the clock tree and fix its
> > relationship with pll accordingly.
> >
> > Signed-off-by: Anson Huang 
> > Signed-off-by: Shengjiu Wang 
> > ---
> >  drivers/clk/imx/clk-imx6sx.c | 8 ++--
> >  include/dt-bindings/clock/imx6sx-clock.h | 6 +-
> >  2 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/clk/imx/clk-imx6sx.c
> > b/drivers/clk/imx/clk-imx6sx.c index e6d389e..478ad0d 100644
> > --- a/drivers/clk/imx/clk-imx6sx.c
> > +++ b/drivers/clk/imx/clk-imx6sx.c
> > @@ -80,7 +80,7 @@ static const char *lvds_sels[]= {
> > "arm", "pll1_sys", "dummy", "dummy", "dummy", "dummy", "dummy",
> "pll5_video_div",
> > "dummy", "dummy", "pcie_ref_125m", "dummy", "usbphy1", "usbphy2",
> > }; -static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", };
> > +static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in",
> > +"lvds2_in", "dummy", };
> >  static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src",
> > };  static const char *pll2_bypass_sels[] = { "pll2",
> > "pll2_bypass_src", };  static const char *pll3_bypass_sels[] = {
> > "pll3", "pll3_bypass_src", }; @@ -158,8 +158,9 @@ static void __init
> imx6sx_clocks_init(struct device_node *ccm_node)
> > clks[IMX6SX_CLK_IPP_DI0] = of_clk_get_by_name(ccm_node, "ipp_di0");
> > clks[IMX6SX_CLK_IPP_DI1] = of_clk_get_by_name(ccm_node, "ipp_di1");
> >
> > -   /* Clock source from external clock via CLK1 PAD */
> > +   /* Clock source from external clock via CLK1/2 PAD */
> > clks[IMX6SX_CLK_ANACLK1] = imx_obtain_fixed_clock("anaclk1", 0);
> > +   clks[IMX6SX_CLK_ANACLK2] = imx_obtain_fixed_clock("anaclk2", 0);
> 
> It seems to me that anaclk clocks are similar to ipp_di, and could be handled 
> in
> the same way as ipp_di clocks.  If that's the case, I would suggest we do the
> following.
> 
> 1. Kill clocks container node by dropping 'reg' property and naming
>clock nodes uniquely.  This is not strictly related to what we try
>to do here, but just to address DT maintainers' concern on 'clocks'
>container node.
> 
>   clk_ckil: clock-ckil {
>   compatible = "fixed-clock";
>   #clock-cells = <0>;
>   clock-frequency = <32768>;
>   clock-output-names = "ckil";
>   };
> 
>   clk_osc: clock-osc {
>   compatible = "fixed-clock";
>   #clock-cells = <0>;
>   clock-frequency = <2400>;
>   clock-output-names = "osc";
>   };
> 
>   clk_ipp_di0: clock-ipp-di0 {
>   compatible = "fixed-clock";
>   #clock-cells = <0>;
>   clock-frequency = <0>;
>   clock-output-names = "ipp_di0";
>   };
> 
>   clk_ipp_di1: clock-ipp-di1 {
>   compatible = "fixed-clock";
>   #clock-cells = <0>;
>   clock-frequency = <0>;
>   clock-output-names = "ipp_di1";
>   };
> 
>   clks: ccm@20c4000 {
>   compatible = "fsl,imx6sx-ccm";
>   reg = <0x020c4000 0x4000>;
>   interrupts = ,
>;
>   #clock-cells = <1>;
>   clocks = <_ckil>, <_osc>, <_ipp_di0>, 
> <_ipp_di1>;
>   clock-names = "ckil", "osc", "ipp_di0", "ipp_di1";
>   };
> 
> 2. Patch clock driver to have anaclk1 and anaclk2 handled in the same
>way as ipp_di clocks.
> 
>   clks[IMX6SX_CLK_ANACLK1] = of_clk_get_by_name(ccm_node, "anaclk1");
>   clks[IMX6SX_CLK_ANACLK2] = of_clk_get_by_name(ccm_node, "anaclk2");
> 
> 3. Add anaclk1 and anaclk2 with clock-frequency being 0 by default, just
>like ipp_di clocks.
> 
>   clk_anaclk1: clock-anaclk1 {
>   compatible = "fixed-clock";
>   #clock-cells = <0>;
>   clock-frequency = <0>;
>   clock-output-names = "anaclk1";
>   };
> 
>   clk_anaclk2: clock-anaclk2 {
>   compatible = "fixed-clock";
>   

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

[Joel Fernandes]

Hi,

Thanks Matsami and Namhyung for the suggestions!

On Wed, Apr 18, 2018 at 10:43 PM, Namhyung Kim  wrote:
> On Wed, Apr 18, 2018 at 06:02:50PM +0900, Masami Hiramatsu wrote:
>> On Mon, 16 Apr 2018 21:07:47 -0700
>> Joel Fernandes  wrote:
>>
>> > With TRACE_IRQFLAGS, we call trace_ API too many times. We don't need
>> > to if local_irq_restore or local_irq_save didn't actually do anything.
>> >
>> > This gives around a 4% improvement in performance when doing the
>> > following command: "time find / > /dev/null"
>> >
>> > Also its best to avoid these calls where possible, since in this series,
>> > the RCU code in tracepoint.h seems to be call these quite a bit and I'd
>> > like to keep this overhead low.
>>
>> Can we assume that the "flags" has only 1 bit irq-disable flag?
>> Since it skips calling raw_local_irq_restore(flags); too,
>
> I don't know how many it impacts on performance but maybe we can have
> an arch-specific config option something like below?

The flags restoration I am hoping is "cheap" but I haven't measured
specifically the cost of this though.

>
>
>> if there is any state in the flags on any arch, it may change the
>> result. In that case, we can do it as below (just skipping trace_hardirqs_*)
>>
>> int disabled = irqs_disabled();
>
>   if (disabled == raw_irqs_disabled_flags(flags)) {
> #ifndef CONFIG_ARCH_CAN_SKIP_NESTED_IRQ_RESTORE
> raw_local_irq_restore(flags);
> #endif
> return;
>   }

Hmm, somehow I feel this part should be written generically enough
that it applies to all architectures (as a first step).

>
>>
>> if (!raw_irqs_disabled_flags(flags) && disabled)
>>   trace_hardirqs_on();
>>
>> raw_local_irq_restore(flags);
>>
>> if (raw_irqs_disabled_flags(flags) && !disabled)
>>   trace_hardirqs_off();

I like this idea since its a good thing to do the flag restoration
just to be safe and preserve the current behaviors. Also my goal was
to reduce the trace_ calls in this series, so its probably better I
just do as you're suggesting. I will do some experiments and make the
changes for the next series.

thanks,

- Joel

Re: [PATCH 00/61] tree-wide: simplify getting .drvdata

[Wolfram Sang]

> Can you throw this into scripts/coccinelle/ so we can have the build
> testers run this all the time?

Sure, I first wanted to check if there were comments regarding the
script.

Thanks!



signature.asc
Description: PGP signature

Re: [PATCH 40/61] platform: x86: simplify getting .drvdata

[Wolfram Sang]

> (I'm not sure what you mean by "Please apply individually")

Right, that is not very precise. "Individually" as "per subsystem
individually". I.e. I don't want to collect tags and push it upstream as
one huge pull-request.

Thanks!



signature.asc
Description: PGP signature

Re: [PATCH v2] KVM: Extend MAX_IRQ_ROUTES to 4096 for all archs

[Cornelia Huck]

On Thu, 19 Apr 2018 17:47:28 -0700
Wanpeng Li  wrote:

> From: Wanpeng Li 
> 
> Our virtual machines make use of device assignment by configuring
> 12 NVMe disks for high I/O performance. Each NVMe device has 129 
> MSI-X Table entries:
> Capabilities: [50] MSI-X: Enable+ Count=129 Masked-Vector table: BAR=0 
> offset=2000
> The windows virtual machines fail to boot since they will map the number of 
> MSI-table entries that the NVMe hardware reported to the bus to msi routing 
> table, this will exceed the 1024. This patch extends MAX_IRQ_ROUTES to 4096
> for all archs, in the future this might be extended again if needed.
> 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Tonny Lu 
> Cc: Cornelia Huck 
> Signed-off-by: Wanpeng Li 
> Signed-off-by: Tonny Lu 
> ---
> v1 -> v2:
>  * extend MAX_IRQ_ROUTES to 4096 for all archs 
> 
>  include/linux/kvm_host.h | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 6930c63..0a5c299 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1045,13 +1045,7 @@ static inline int mmu_notifier_retry(struct kvm *kvm, 
> unsigned long mmu_seq)
>  
>  #ifdef CONFIG_HAVE_KVM_IRQ_ROUTING
>  
> -#ifdef CONFIG_S390
>  #define KVM_MAX_IRQ_ROUTES 4096 //FIXME: we can have more than that...

What about /* might need extension/rework in the future */ instead of
the FIXME?

As far as I understand, 4096 should cover most architectures and the
sane end of s390 configurations, but will not be enough at the scarier
end of s390. (I'm not sure how much it matters in practice.)

Do we want to make this a tuneable in the future? Do some kind of
dynamic allocation? Not sure whether it is worth the trouble.

> -#elif defined(CONFIG_ARM64)
> -#define KVM_MAX_IRQ_ROUTES 4096
> -#else
> -#define KVM_MAX_IRQ_ROUTES 1024
> -#endif
>  
>  bool kvm_arch_can_set_irq_routing(struct kvm *kvm);
>  int kvm_set_irq_routing(struct kvm *kvm,

[PATCH v2 2/4] qxl: move qxl_send_monitors_config()

[Gerd Hoffmann]

Needed to avoid a forward declaration in a followup patch.
Pure code move, no functional change.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_display.c | 47 +++
 1 file changed, 23 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index dea757ef62..68db4d1965 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -258,6 +258,29 @@ static int qxl_add_common_modes(struct drm_connector 
*connector,
return i - 1;
 }
 
+static void qxl_send_monitors_config(struct qxl_device *qdev)
+{
+   int i;
+
+   BUG_ON(!qdev->ram_header->monitors_config);
+
+   if (qdev->monitors_config->count == 0)
+   return;
+
+   for (i = 0 ; i < qdev->monitors_config->count ; ++i) {
+   struct qxl_head *head = >monitors_config->heads[i];
+
+   if (head->y > 8192 || head->x > 8192 ||
+   head->width > 8192 || head->height > 8192) {
+   DRM_ERROR("head %d wrong: %dx%d+%d+%d\n",
+ i, head->width, head->height,
+ head->x, head->y);
+   return;
+   }
+   }
+   qxl_io_monitors_config(qdev);
+}
+
 static void qxl_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
@@ -378,30 +401,6 @@ static bool qxl_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }
 
-static void
-qxl_send_monitors_config(struct qxl_device *qdev)
-{
-   int i;
-
-   BUG_ON(!qdev->ram_header->monitors_config);
-
-   if (qdev->monitors_config->count == 0)
-   return;
-
-   for (i = 0 ; i < qdev->monitors_config->count ; ++i) {
-   struct qxl_head *head = >monitors_config->heads[i];
-
-   if (head->y > 8192 || head->x > 8192 ||
-   head->width > 8192 || head->height > 8192) {
-   DRM_ERROR("head %d wrong: %dx%d+%d+%d\n",
- i, head->width, head->height,
- head->x, head->y);
-   return;
-   }
-   }
-   qxl_io_monitors_config(qdev);
-}
-
 static void qxl_monitors_config_set(struct qxl_device *qdev,
int index,
unsigned x, unsigned y,
-- 
2.9.3

[PATCH v2 3/4] qxl: hook monitors_config updates into crtc, not encoder.

[Gerd Hoffmann]

The encoder callbacks are only called in case the video mode changes.
So any layout changes without mode changes will go unnoticed.

Add qxl_crtc_update_monitors_config(), based on the old
qxl_write_monitors_config_for_encoder() function.  Hook it into the
enable, disable and flush atomic crtc callbacks.  Remove monitors_config
updates from all other places.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1544322
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_cmd.c |   2 +
 drivers/gpu/drm/qxl/qxl_display.c | 156 --
 2 files changed, 66 insertions(+), 92 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index 850f8d7d37..95db20f214 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -371,6 +371,7 @@ void qxl_io_flush_surfaces(struct qxl_device *qdev)
 void qxl_io_destroy_primary(struct qxl_device *qdev)
 {
wait_for_io_cmd(qdev, 0, QXL_IO_DESTROY_PRIMARY_ASYNC);
+   qdev->primary_created = false;
 }
 
 void qxl_io_create_primary(struct qxl_device *qdev,
@@ -396,6 +397,7 @@ void qxl_io_create_primary(struct qxl_device *qdev,
create->type = QXL_SURF_TYPE_PRIMARY;
 
wait_for_io_cmd(qdev, 0, QXL_IO_CREATE_PRIMARY_ASYNC);
+   qdev->primary_created = true;
 }
 
 void qxl_io_memslot_add(struct qxl_device *qdev, uint8_t id)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 68db4d1965..06ee00b486 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -281,6 +281,66 @@ static void qxl_send_monitors_config(struct qxl_device 
*qdev)
qxl_io_monitors_config(qdev);
 }
 
+static void qxl_crtc_update_monitors_config(struct drm_crtc *crtc,
+   const char *reason)
+{
+   struct drm_device *dev = crtc->dev;
+   struct qxl_device *qdev = dev->dev_private;
+   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
+   struct qxl_head head;
+   int oldcount, i = qcrtc->index;
+
+   if (!qdev->primary_created) {
+   DRM_DEBUG_KMS("no primary surface, skip (%s)\n", reason);
+   return;
+   }
+
+   if (!qdev->monitors_config ||
+   qdev->monitors_config->max_allowed <= i)
+   return;
+
+   head.id = i;
+   head.flags = 0;
+   oldcount = qdev->monitors_config->count;
+   if (crtc->state->active) {
+   struct drm_display_mode *mode = >mode;
+   head.width = mode->hdisplay;
+   head.height = mode->vdisplay;
+   head.x = crtc->x;
+   head.y = crtc->y;
+   if (qdev->monitors_config->count < i + 1)
+   qdev->monitors_config->count = i + 1;
+   } else if (i > 0) {
+   head.width = 0;
+   head.height = 0;
+   head.x = 0;
+   head.y = 0;
+   if (qdev->monitors_config->count == i + 1)
+   qdev->monitors_config->count = i;
+   } else {
+   DRM_DEBUG_KMS("inactive head 0, skip (%s)\n", reason);
+   return;
+   }
+
+   if (head.width  == qdev->monitors_config->heads[i].width  &&
+   head.height == qdev->monitors_config->heads[i].height &&
+   head.x  == qdev->monitors_config->heads[i].x  &&
+   head.y  == qdev->monitors_config->heads[i].y  &&
+   oldcount== qdev->monitors_config->count)
+   return;
+
+   DRM_DEBUG_KMS("head %d, %dx%d, at +%d+%d, %s (%s)\n",
+ i, head.width, head.height, head.x, head.y,
+ crtc->state->active ? "on" : "off", reason);
+   if (oldcount != qdev->monitors_config->count)
+   DRM_DEBUG_KMS("active heads %d -> %d (%d total)\n",
+ oldcount, qdev->monitors_config->count,
+ qdev->monitors_config->max_allowed);
+
+   qdev->monitors_config->heads[i] = head;
+   qxl_send_monitors_config(qdev);
+}
+
 static void qxl_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
@@ -296,6 +356,8 @@ static void qxl_crtc_atomic_flush(struct drm_crtc *crtc,
drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irqrestore(>event_lock, flags);
}
+
+   qxl_crtc_update_monitors_config(crtc, "flush");
 }
 
 static void qxl_crtc_destroy(struct drm_crtc *crtc)
@@ -401,55 +463,20 @@ static bool qxl_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }
 
-static void qxl_monitors_config_set(struct qxl_device *qdev,
-   int index,
-   unsigned x, unsigned y,
-   unsigned width, unsigned height,
-   unsigned surf_id)
-{
-   

[PATCH v2 4/4] qxl: drop dummy functions

[Gerd Hoffmann]

These days drm core checks function pointers everywhere before calling
them.  So we can drop a bunch of dummy functions now.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_display.c | 50 ---
 1 file changed, 50 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 06ee00b486..af6e52af5f 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -456,13 +456,6 @@ qxl_framebuffer_init(struct drm_device *dev,
return 0;
 }
 
-static bool qxl_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
-   return true;
-}
-
 static void qxl_crtc_atomic_enable(struct drm_crtc *crtc,
   struct drm_crtc_state *old_state)
 {
@@ -476,7 +469,6 @@ static void qxl_crtc_atomic_disable(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs qxl_crtc_helper_funcs = {
-   .mode_fixup = qxl_crtc_mode_fixup,
.atomic_flush = qxl_crtc_atomic_flush,
.atomic_enable = qxl_crtc_atomic_enable,
.atomic_disable = qxl_crtc_atomic_disable,
@@ -620,12 +612,6 @@ static void qxl_primary_atomic_disable(struct drm_plane 
*plane,
}
 }
 
-static int qxl_plane_atomic_check(struct drm_plane *plane,
- struct drm_plane_state *state)
-{
-   return 0;
-}
-
 static void qxl_cursor_atomic_update(struct drm_plane *plane,
 struct drm_plane_state *old_state)
 {
@@ -831,7 +817,6 @@ static const uint32_t qxl_cursor_plane_formats[] = {
 };
 
 static const struct drm_plane_helper_funcs qxl_cursor_helper_funcs = {
-   .atomic_check = qxl_plane_atomic_check,
.atomic_update = qxl_cursor_atomic_update,
.atomic_disable = qxl_cursor_atomic_disable,
.prepare_fb = qxl_plane_prepare_fb,
@@ -956,28 +941,6 @@ static int qdev_crtc_init(struct drm_device *dev, int 
crtc_id)
return r;
 }
 
-static void qxl_enc_dpms(struct drm_encoder *encoder, int mode)
-{
-   DRM_DEBUG("\n");
-}
-
-static void qxl_enc_prepare(struct drm_encoder *encoder)
-{
-   DRM_DEBUG("\n");
-}
-
-static void qxl_enc_commit(struct drm_encoder *encoder)
-{
-   DRM_DEBUG("\n");
-}
-
-static void qxl_enc_mode_set(struct drm_encoder *encoder,
-   struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
-{
-   DRM_DEBUG("\n");
-}
-
 static int qxl_conn_get_modes(struct drm_connector *connector)
 {
unsigned pwidth = 1024;
@@ -1023,10 +986,6 @@ static struct drm_encoder *qxl_best_encoder(struct 
drm_connector *connector)
 
 
 static const struct drm_encoder_helper_funcs qxl_enc_helper_funcs = {
-   .dpms = qxl_enc_dpms,
-   .prepare = qxl_enc_prepare,
-   .mode_set = qxl_enc_mode_set,
-   .commit = qxl_enc_commit,
 };
 
 static const struct drm_connector_helper_funcs qxl_connector_helper_funcs = {
@@ -1059,14 +1018,6 @@ static enum drm_connector_status qxl_conn_detect(
 : connector_status_disconnected;
 }
 
-static int qxl_conn_set_property(struct drm_connector *connector,
-  struct drm_property *property,
-  uint64_t value)
-{
-   DRM_DEBUG("\n");
-   return 0;
-}
-
 static void qxl_conn_destroy(struct drm_connector *connector)
 {
struct qxl_output *qxl_output =
@@ -1081,7 +1032,6 @@ static const struct drm_connector_funcs 
qxl_connector_funcs = {
.dpms = drm_helper_connector_dpms,
.detect = qxl_conn_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
-   .set_property = qxl_conn_set_property,
.destroy = qxl_conn_destroy,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-- 
2.9.3

Re: [PATCH v1 3/4] drm/tegra: plane: Add custom colorkey properties for older Tegra's

[Daniel Vetter]

On Tue, Apr 17, 2018 at 08:08:27PM +0300, Dmitry Osipenko wrote:
> On 17.04.2018 12:00, Daniel Vetter wrote:
> > On Mon, Apr 16, 2018 at 03:16:27PM +0300, Dmitry Osipenko wrote:
> >> Colorkey'ing allows to draw on top of overlapping planes, like for example
> >> on top of a video plane. Older Tegra's have a limited colorkey'ing
> >> capability such that blending features are reduced when colorkey'ing is
> >> enabled. In particular dependent weighting isn't possible, meaning that
> >> cursors plane can't be displayed properly. In most cases it is more useful
> >> to display content on top of video overlay, sacrificing mouse cursor
> >> in the area of three planes intersection with colorkey mismatch. This
> >> patch adds a custom colorkey properties to primary plane and CRTC's of
> >> older Tegra's, allowing userspace like Opentegra Xorg driver to implement
> >> colorkey support for XVideo extension.
> >>
> >> Signed-off-by: Dmitry Osipenko 
> > 
> > Since this is your own uapi, where's the userspace per
> > 
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> 
> Userspace patches for colorkey and CSC utilization are in my personal github
> repos for now [0][1]. The longterm plan is to get Opentegra driver / libdrm 
> bits
> of [2] to repos on freedesktop.org, which should be considered as upstream. We
> have everything depending on libdrm-tegra and it is currently on hold because 
> of
> upcoming massive rework of Tegra DRM UAPI with further de-staging of jobs
> submission UAPI, that reworking should start with 4.18 kernel.
> 
> For now I wanted to get initial input on the patches. Once everyone is in
> agreement, I'd like to have colorkey / CSC supported by the upstream DRM 
> driver,
> so that at least grate-driver projects could utilize them right now.
> 
> > And why wo we need a tegra-private colorkey property here? I thought
> > other's have been discussing this in the context of other drivers.
> 
> At least older Tegra's have limitations in regards to colorkey, like planes
> blending capabilities are reduced a lot when colorkey'ing is enabled. I'm not
> sure whether we'd want to have it as a generic property, because generic
> userspace should be aware of those limitations, otherwise there is a good 
> chance
> to get undesirable result using colorkey. Though I'm not really sure how 
> widely
> colorkey property could be utilize by userspace and what kind of applications
> that userspace could have for it, maybe having colorkey as a generic property
> would be good enough after all.
> 
> I've looked up the DRI ML archive and seems the most recent colorkey-related
> patches are [3]. These patches are a bit odd to me because by generic 
> property I
> assume a property that is HW-agnostic and the patchset does opposite to it.
> Maybe I'm misunderstanding what is meant by 'generic' property then? Anyway 
> I've
> applied [3] and made Tegra to use that generic property, it works fine. I'll 
> be
> happy to switch to a generic property if we'll consider that it is a viable 
> way.
> 
> [0] https://github.com/digetx/xf86-video-opentegra/commits/ckey
> [1] https://github.com/digetx/libvdpau-tegra/commits/ckey
> [2] https://github.com/grate-driver
> [3] https://patchwork.kernel.org/patch/10117593/

Yes that's the patches I meant, thanks for surfacing them.

Please work together with Laurent, Maxime and Boris on this (jump on that
thread and Cc them on your own patches for the next round). And pls also
work together on a common userspace for this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC 0/2] dw_mmc: add multislot support

[Ulf Hansson]

[...]

>
> 2. Add missing stuff to support multislot mode in DesignWare MMC driver.
>  * Add missing slot switch to __dw_mci_start_request() function.
>  * Refactor set_ios function:
>a) Calculate common clock which is
>   suitable for all slots instead of directly use clock value
>   provided by mmc core. We calculate common clock as the minimum
>   among each used slot clocks. This clock is calculated in
>   dw_mci_calc_common_clock() function which is called
>   from set_ios()
>b) Disable clock only if no other slots are ON.
>c) Setup clock directly in set_ios() only if no other slots
>   are ON. Otherwise adjust clock in __dw_mci_start_request()
>   function before slot switch.
>d) Move timings and bus_width setup to separate funcions.
>  * Use timing field in each slot structure instead of common field in
>host structure.
>  * Add locks to serialize access to registers.

Sorry, but this is a hack to *try* to make multi-slot work and this
isn't sufficient. There were good reasons to why the earlier
non-working multi slot support was removed from dw_mmc.

Let me elaborate a bit for your understanding. The core uses a host
lock (mmc_claim|release_host()) to serialize operations and commands,
as to confirm to the SD/SDIO/(e)MMC specs. The above changes gives no
guarantees for this. To make that work, we would need a "mmc bus lock"
to be managed by the core.

However, inventing a "mmc bus lock" would lead to other problems
related to I/O scheduling for upper layers - it simply breaks. For
example, I/O requests for one card/slot can then starve I/O requests
reaching another card/slot.

[...]

Kind regards
Uffe

[PATCH] tty: Fix data race in tty_insert_flip_string_fixed_flag()

[daelyong jeong]

tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated
by th->used and updates tb->used.
But it is possible that tty_insert_flip_string_fixed_flag() is executed
concurrently and tb->used is updated improperly.
It leads slab-out-of-bound write in tty_insert_flip_string_fixed_flag or
slab-out-of-bounds read in flush_to_ldisc.

BUG: KASAN: slab-out-of-bounds in
tty_insert_flip_string_fixed_flag+0xb5/0x130
drivers/tty/tty_buffer.c:316 at addr 880114fcc121
Write of size 1792 by task syz-executor0/30017
CPU: 1 PID: 30017 Comm: syz-executor0 Not tainted 4.8.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
  88011638f888 81694cc3 88007d802140
 880114fcb300 880114fcc300 880114fcb300 88011638f8b0
 8130075c 88011638f940 88007d802140 880194fcc121
Call Trace:
 [] __dump_stack lib/dump_stack.c:15 [inline]
 [] dump_stack+0xb3/0x110 lib/dump_stack.c:51
 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
 [] print_address_description mm/kasan/report.c:194 [inline]
 [] kasan_report_error+0x1f7/0x4e0 mm/kasan/report.c:283
 [] kasan_report+0x36/0x40 mm/kasan/report.c:303
 [] check_memory_region_inline mm/kasan/kasan.c:292 [inline]
 [] check_memory_region+0x13e/0x1a0 mm/kasan/kasan.c:299
 [] memcpy+0x37/0x50 mm/kasan/kasan.c:335
 [] tty_insert_flip_string_fixed_flag+0xb5/0x130
drivers/tty/tty_buffer.c:316
 [] tty_insert_flip_string
include/linux/tty_flip.h:35 [inline]
 [] pty_write+0x7f/0xc0 drivers/tty/pty.c:115
 [] n_hdlc_send_frames+0x1d4/0x3b0 drivers/tty/n_hdlc.c:419
 [] n_hdlc_tty_wakeup+0x73/0xa0 drivers/tty/n_hdlc.c:496
 [] tty_wakeup+0x92/0xb0 drivers/tty/tty_io.c:601
 [] __start_tty.part.26+0x66/0x70 drivers/tty/tty_io.c:1018
 [] __start_tty+0x34/0x40 drivers/tty/tty_io.c:1013
 [] n_tty_ioctl_helper+0x146/0x1e0
drivers/tty/tty_ioctl.c:1138
 [] n_hdlc_tty_ioctl+0xb3/0x2b0 drivers/tty/n_hdlc.c:794
 [] tty_ioctl+0xa85/0x16d0 drivers/tty/tty_io.c:2992
 [] vfs_ioctl fs/ioctl.c:43 [inline]
 [] do_vfs_ioctl+0x13e/0xba0 fs/ioctl.c:679
 [] SYSC_ioctl fs/ioctl.c:694 [inline]
 [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
 [] entry_SYSCALL_64_fastpath+0x1f/0xbd

Call sequences are as follows.
CPU0CPU1
n_tty_ioctl_helper  n_tty_ioctl_helper
__start_tty tty_send_xchar
tty_wakeup  pty_write
n_hdlc_tty_wakeup   tty_insert_flip_string
n_hdlc_send_frames  tty_insert_flip_string_fixed_flag
pty_write
tty_insert_flip_string
tty_insert_flip_string_fixed_flag

Acquire tty->atomic_write_lock by calling tty_write_lock() before
__start_tty() since __start_tty() can sends frames.

Signed-off-by: Daelyong Jeong 
---
Rationale:
- Since tty_wakeup() called by __start_tty() sends frames, call
  tty_write_lock() before __start_tty().
- Since tty_write_lock() might sleep, locate tty_write_lock() before
  spin_lock_irq(>flow_lock).
- Since wake_up_interruptible_poll() is called by both tty_write_unlock()
  and __start_tty(), Prevent calling wake_up_interruptible_poll() twice
  by adding the wakeup flag to tty_write_unlock()

---
 drivers/tty/tty_io.c| 16 +---
 drivers/tty/tty_ioctl.c |  5 +
 include/linux/tty.h |  2 ++
 3 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 63114ea..41f83bd 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -873,13 +873,15 @@ static ssize_t tty_read(struct file *file, char
__user *buf, size_t count,
  return i;
 }

-static void tty_write_unlock(struct tty_struct *tty)
+void tty_write_unlock(struct tty_struct *tty, int wakeup)
 {
  mutex_unlock(>atomic_write_lock);
- wake_up_interruptible_poll(>write_wait, EPOLLOUT);
+ if (wakeup) {
+ wake_up_interruptible_poll(>write_wait, EPOLLOUT);
+ }
 }

-static int tty_write_lock(struct tty_struct *tty, int ndelay)
+int tty_write_lock(struct tty_struct *tty, int ndelay)
 {
  if (!mutex_trylock(>atomic_write_lock)) {
  if (ndelay)
@@ -973,7 +975,7 @@ static inline ssize_t do_tty_write(
  ret = written;
  }
 out:
- tty_write_unlock(tty);
+ tty_write_unlock(tty, 1);
  return ret;
 }

@@ -997,7 +999,7 @@ void tty_write_message(struct tty_struct *tty, char *msg)
  if (tty->ops->write && tty->count > 0)
  tty->ops->write(tty, msg, strlen(msg));
  tty_unlock(tty);
- tty_write_unlock(tty);
+ tty_write_unlock(tty, 1);
  }
  return;
 }
@@ -1092,7 +1094,7 @@ int tty_send_xchar(struct tty_struct *tty, char ch)
  if (was_stopped)
  stop_tty(tty);
  up_read(>termios_rwsem);
- tty_write_unlock(tty);
+ tty_write_unlock(tty, 1);
  return 0;
 }

@@ -2395,7 +2397,7 @@ static int send_break(struct tty_struct *tty,
unsigned int duration)
  msleep_interruptible(duration);
  retval = tty->ops->break_ctl(tty, 0);
 out:
- tty_write_unlock(tty);
+ tty_write_unlock(tty, 1);
  if 

bq27000: directory/files exists even when hardware is not available

[Pavel Machek]

Hi!

On droid4 (4.17-rc1), /sys/class/power_supply/bq27000-battery exists
even when hardware is not present (as on Droid 4).

Any ideas?
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

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Jani Nikula]

On Fri, 20 Apr 2018, Ian W MORRISON  wrote:
> I've performed backport testing and some additional analysis as follows:

What testing did you do beyond booting? Did you run igt?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: bq27000: directory/files exists even when hardware is not available

[Pali Rohár]

On Friday 20 April 2018 09:40:36 Pavel Machek wrote:
> Hi!
> 
> On droid4 (4.17-rc1), /sys/class/power_supply/bq27000-battery exists
> even when hardware is not present (as on Droid 4).
> 
> Any ideas?
>   Pavel

Somebody must have registered bq device into power_supply subsystem.
Maybe DT note is present?

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [PATCH 1/2] qxl: fix qxl_release_{map,unmap}

[Daniel Vetter]

On Wed, Apr 18, 2018 at 07:42:56AM +0200, Gerd Hoffmann wrote:
> s/PAGE_SIZE/PAGE_MASK/
> 
> Luckily release_offset is never larger than PAGE_SIZE, so the bug has no
> bad side effects and managed to stay unnoticed for years that way ...
> 
> Signed-off-by: Gerd Hoffmann 

Sweeet. Since the buggy code uses the same expression for page frame and
offset I don't think there's a security bug. You might still want to cc:
stable (since without you defacto can't ever use this feature).

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/qxl/qxl_ioctl.c   | 4 ++--
>  drivers/gpu/drm/qxl/qxl_release.c | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
> index e238a1a2ec..6cc9f3367f 100644
> --- a/drivers/gpu/drm/qxl/qxl_ioctl.c
> +++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
> @@ -182,9 +182,9 @@ static int qxl_process_single_command(struct qxl_device 
> *qdev,
>   goto out_free_reloc;
>  
>   /* TODO copy slow path code from i915 */
> - fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset 
> & PAGE_SIZE));
> + fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset 
> & PAGE_MASK));
>   unwritten = __copy_from_user_inatomic_nocache
> - (fb_cmd + sizeof(union qxl_release_info) + 
> (release->release_offset & ~PAGE_SIZE),
> + (fb_cmd + sizeof(union qxl_release_info) + 
> (release->release_offset & ~PAGE_MASK),
>u64_to_user_ptr(cmd->command), cmd->command_size);
>  
>   {
> diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
> b/drivers/gpu/drm/qxl/qxl_release.c
> index 5d84a66fed..a0b4244d28 100644
> --- a/drivers/gpu/drm/qxl/qxl_release.c
> +++ b/drivers/gpu/drm/qxl/qxl_release.c
> @@ -411,10 +411,10 @@ union qxl_release_info *qxl_release_map(struct 
> qxl_device *qdev,
>   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
> qxl_bo_list, tv.head);
>   struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
>  
> - ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
> PAGE_SIZE);
> + ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
> PAGE_MASK);
>   if (!ptr)
>   return NULL;
> - info = ptr + (release->release_offset & ~PAGE_SIZE);
> + info = ptr + (release->release_offset & ~PAGE_MASK);
>   return info;
>  }
>  
> @@ -426,7 +426,7 @@ void qxl_release_unmap(struct qxl_device *qdev,
>   struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
>   void *ptr;
>  
> - ptr = ((void *)info) - (release->release_offset & ~PAGE_SIZE);
> + ptr = ((void *)info) - (release->release_offset & ~PAGE_MASK);
>   qxl_bo_kunmap_atomic_page(qdev, bo, ptr);
>  }
>  
> -- 
> 2.9.3
> 
> ___
> 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

[PATCH 04/22] alpha: use dma_direct_ops for jensen

[Christoph Hellwig]

The generic dma_direct implementation does the same thing as the alpha
pci-noop implementation, just with more bells and whistles.  And unlike
the current code it at least has a theoretical chance to actually compile.

Signed-off-by: Christoph Hellwig 
---
 arch/alpha/Kconfig   |  1 +
 arch/alpha/include/asm/dma-mapping.h |  4 
 arch/alpha/kernel/pci-noop.c | 33 
 3 files changed, 5 insertions(+), 33 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index aa7df1a36fd0..94af0c7f494a 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -204,6 +204,7 @@ config ALPHA_EIGER
 config ALPHA_JENSEN
bool "Jensen"
depends on BROKEN
+   select DMA_DIRECT_OPS
help
  DEC PC 150 AXP (aka Jensen): This is a very old Digital system - one
  of the first-generation Alpha systems. A number of these systems
diff --git a/arch/alpha/include/asm/dma-mapping.h 
b/arch/alpha/include/asm/dma-mapping.h
index b78f61f20796..76ce923ecca1 100644
--- a/arch/alpha/include/asm/dma-mapping.h
+++ b/arch/alpha/include/asm/dma-mapping.h
@@ -6,7 +6,11 @@ extern const struct dma_map_ops *dma_ops;
 
 static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
 {
+#ifdef CONFIG_ALPHA_JENSEN
+   return _direct_ops;
+#else
return dma_ops;
+#endif
 }
 
 #endif /* _ALPHA_DMA_MAPPING_H */
diff --git a/arch/alpha/kernel/pci-noop.c b/arch/alpha/kernel/pci-noop.c
index b6ebb65127a8..c7c5879869d3 100644
--- a/arch/alpha/kernel/pci-noop.c
+++ b/arch/alpha/kernel/pci-noop.c
@@ -102,36 +102,3 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus, 
unsigned long, dfn,
else
return -ENODEV;
 }
-
-static void *alpha_noop_alloc_coherent(struct device *dev, size_t size,
-  dma_addr_t *dma_handle, gfp_t gfp,
-  unsigned long attrs)
-{
-   void *ret;
-
-   if (!dev || *dev->dma_mask >= 0xUL)
-   gfp &= ~GFP_DMA;
-   ret = (void *)__get_free_pages(gfp, get_order(size));
-   if (ret) {
-   memset(ret, 0, size);
-   *dma_handle = virt_to_phys(ret);
-   }
-   return ret;
-}
-
-static int alpha_noop_supported(struct device *dev, u64 mask)
-{
-   return mask < 0x00ffUL ? 0 : 1;
-}
-
-const struct dma_map_ops alpha_noop_ops = {
-   .alloc  = alpha_noop_alloc_coherent,
-   .free   = dma_noop_free_coherent,
-   .map_page   = dma_noop_map_page,
-   .map_sg = dma_noop_map_sg,
-   .mapping_error  = dma_noop_mapping_error,
-   .dma_supported  = alpha_noop_supported,
-};
-
-const struct dma_map_ops *dma_ops = _noop_ops;
-EXPORT_SYMBOL(dma_ops);
-- 
2.17.0

[PATCH 03/22] dma-mapping: provide a generic dma-noncoherent implementation

[Christoph Hellwig]

Add a new dma_map_ops implementation that uses dma-direct for the
address mapping of streaming mappings, and which requires arch-specific
implemenations of coherent allocate/free.

Architectures have to provide flushing helpers to ownership trasnfers
to the device and/or CPU, and can provide optional implementations of
the coherent mmap functionality, and the cache_flush routines for
non-coherent long term allocations.

Signed-off-by: Christoph Hellwig 
---
 MAINTAINERS   |   2 +
 include/asm-generic/dma-mapping.h |   9 +++
 include/linux/dma-direct.h|   7 ++-
 include/linux/dma-mapping.h   |   1 +
 include/linux/dma-noncoherent.h   |  47 ++
 lib/Kconfig   |  20 ++
 lib/Makefile  |   1 +
 lib/dma-direct.c  |   8 +--
 lib/dma-noncoherent.c | 101 ++
 9 files changed, 191 insertions(+), 5 deletions(-)
 create mode 100644 include/linux/dma-noncoherent.h
 create mode 100644 lib/dma-noncoherent.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d948bb..bbaf5459d297 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4327,12 +4327,14 @@ W:  
http://git.infradead.org/users/hch/dma-mapping.git
 S: Supported
 F: lib/dma-debug.c
 F: lib/dma-direct.c
+F: lib/dma-noncoherent.c
 F: lib/dma-virt.c
 F: drivers/base/dma-mapping.c
 F: drivers/base/dma-coherent.c
 F: include/asm-generic/dma-mapping.h
 F: include/linux/dma-direct.h
 F: include/linux/dma-mapping.h
+F: include/linux/dma-noncoherent.h
 
 DME1737 HARDWARE MONITOR DRIVER
 M: Juerg Haefliger 
diff --git a/include/asm-generic/dma-mapping.h 
b/include/asm-generic/dma-mapping.h
index 880a292d792f..ad2868263867 100644
--- a/include/asm-generic/dma-mapping.h
+++ b/include/asm-generic/dma-mapping.h
@@ -4,7 +4,16 @@
 
 static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
 {
+   /*
+* Use the non-coherent ops if available.  If an architecture wants a
+* more fine-grained selection of operations it will have to implement
+* get_arch_dma_ops itself or use the per-device dma_ops.
+*/
+#ifdef CONFIG_DMA_NONCOHERENT_OPS
+   return _noncoherent_ops;
+#else
return _direct_ops;
+#endif
 }
 
 #endif /* _ASM_GENERIC_DMA_MAPPING_H */
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 53ad6a47f513..8d9f33febde5 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -59,6 +59,11 @@ void *dma_direct_alloc(struct device *dev, size_t size, 
dma_addr_t *dma_handle,
gfp_t gfp, unsigned long attrs);
 void dma_direct_free(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_addr, unsigned long attrs);
+dma_addr_t dma_direct_map_page(struct device *dev, struct page *page,
+   unsigned long offset, size_t size, enum dma_data_direction dir,
+   unsigned long attrs);
+int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
+   enum dma_data_direction dir, unsigned long attrs);
 int dma_direct_supported(struct device *dev, u64 mask);
-
+int dma_direct_mapping_error(struct device *dev, dma_addr_t dma_addr);
 #endif /* _LINUX_DMA_DIRECT_H */
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 25a9a2b04f78..4be070df5fc5 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -136,6 +136,7 @@ struct dma_map_ops {
 };
 
 extern const struct dma_map_ops dma_direct_ops;
+extern const struct dma_map_ops dma_noncoherent_ops;
 extern const struct dma_map_ops dma_virt_ops;
 
 #define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
new file mode 100644
index ..10b2654d549b
--- /dev/null
+++ b/include/linux/dma-noncoherent.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_DMA_NONCOHERENT_H
+#define _LINUX_DMA_NONCOHERENT_H 1
+
+#include 
+
+void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
+   gfp_t gfp, unsigned long attrs);
+void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
+   dma_addr_t dma_addr, unsigned long attrs);
+
+#ifdef CONFIG_DMA_NONCOHERENT_MMAP
+int arch_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+   void *cpu_addr, dma_addr_t dma_addr, size_t size,
+   unsigned long attrs);
+#else
+#define arch_dma_mmap NULL
+#endif /* CONFIG_DMA_NONCOHERENT_MMAP */
+
+#ifdef CONFIG_DMA_NONCOHERENT_CACHE_SYNC
+void arch_dma_cache_sync(struct device *dev, void *vaddr, size_t size,
+   enum dma_data_direction direction);
+#else
+#define arch_dma_cache_sync NULL
+#endif /* CONFIG_DMA_NONCOHERENT_CACHE_SYNC */
+
+#ifdef CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE
+void 

[PATCH 06/22] arc: use generic dma_noncoherent_ops

[Christoph Hellwig]

Switch to the generic noncoherent direct mapping implementation.

Signed-off-by: Christoph Hellwig 
---
 arch/arc/Kconfig   |   4 +
 arch/arc/include/asm/Kbuild|   1 +
 arch/arc/include/asm/dma-mapping.h |  21 -
 arch/arc/mm/dma.c  | 141 +++--
 4 files changed, 19 insertions(+), 148 deletions(-)
 delete mode 100644 arch/arc/include/asm/dma-mapping.h

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 7498aca4b887..89d47eac18b2 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -9,11 +9,15 @@
 config ARC
def_bool y
select ARC_TIMERS
+   select ARCH_HAS_SYNC_DMA_FOR_CPU
+   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_HAS_SG_CHAIN
select ARCH_SUPPORTS_ATOMIC_RMW if ARC_HAS_LLSC
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
select COMMON_CLK
+   select DMA_NONCOHERENT_OPS
+   select DMA_NONCOHERENT_MMAP
select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
select GENERIC_CLOCKEVENTS
select GENERIC_FIND_FIRST_BIT
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index 4bd5d4369e05..bbdcb955e18f 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -2,6 +2,7 @@
 generic-y += bugs.h
 generic-y += device.h
 generic-y += div64.h
+generic-y += dma-mapping.h
 generic-y += emergency-restart.h
 generic-y += extable.h
 generic-y += fb.h
diff --git a/arch/arc/include/asm/dma-mapping.h 
b/arch/arc/include/asm/dma-mapping.h
deleted file mode 100644
index 7a16824bfe98..
--- a/arch/arc/include/asm/dma-mapping.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * DMA Mapping glue for ARC
- *
- * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef ASM_ARC_DMA_MAPPING_H
-#define ASM_ARC_DMA_MAPPING_H
-
-extern const struct dma_map_ops arc_dma_ops;
-
-static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
-{
-   return _dma_ops;
-}
-
-#endif
diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 1dcc404b5aec..ecfeb5585cc7 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -16,13 +16,12 @@
  * The default DMA address == Phy address which is 0x8000_ based.
  */
 
-#include 
+#include 
 #include 
 #include 
 
-
-static void *arc_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
+void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
+   gfp_t gfp, unsigned long attrs)
 {
unsigned long order = get_order(size);
struct page *page;
@@ -89,7 +88,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
return kvaddr;
 }
 
-static void arc_dma_free(struct device *dev, size_t size, void *vaddr,
+void arch_dma_free(struct device *dev, size_t size, void *vaddr,
dma_addr_t dma_handle, unsigned long attrs)
 {
phys_addr_t paddr = dma_handle;
@@ -105,9 +104,9 @@ static void arc_dma_free(struct device *dev, size_t size, 
void *vaddr,
__free_pages(page, get_order(size));
 }
 
-static int arc_dma_mmap(struct device *dev, struct vm_area_struct *vma,
-   void *cpu_addr, dma_addr_t dma_addr, size_t size,
-   unsigned long attrs)
+int arch_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+   void *cpu_addr, dma_addr_t dma_addr, size_t size,
+   unsigned long attrs)
 {
unsigned long user_count = vma_pages(vma);
unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
@@ -135,7 +134,7 @@ static int arc_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
  * CPU accesses page via normal paddr, thus needs to explicitly made
  * consistent before each use
  */
-static void _dma_cache_sync(phys_addr_t paddr, size_t size,
+static void _dma_cache_sync(struct device *dev, phys_addr_t paddr size_t size,
enum dma_data_direction dir)
 {
switch (dir) {
@@ -153,126 +152,14 @@ static void _dma_cache_sync(phys_addr_t paddr, size_t 
size,
}
 }
 
-/*
- * arc_dma_map_page - map a portion of a page for streaming DMA
- *
- * Ensure that any data held in the cache is appropriately discarded
- * or written back.
- *
- * The device owns this memory once this call has completed.  The CPU
- * can regain ownership by calling dma_unmap_page().
- *
- * Note: while it takes struct page as arg, caller can "abuse" it to pass
- * a region larger than PAGE_SIZE, provided it is physically contiguous
- * and this still works correctly
- */
-static dma_addr_t arc_dma_map_page(struct device *dev, struct page *page,
-   unsigned long offset, size_t size, enum 

[PATCH 07/22] arm-nommu: use generic dma_noncoherent_ops

[Christoph Hellwig]

Switch to the generic noncoherent direct mapping implementation for
the nommu dma map implementation.

Signed-off-by: Christoph Hellwig 
---
 arch/arc/Kconfig|   1 +
 arch/arm/Kconfig|   4 +
 arch/arm/mm/dma-mapping-nommu.c | 139 +---
 3 files changed, 23 insertions(+), 121 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 89d47eac18b2..3a492a9aeaad 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -9,6 +9,7 @@
 config ARC
def_bool y
select ARC_TIMERS
+   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_HAS_SG_CHAIN
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f91f69174630..eacc45ac4e77 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -12,6 +12,8 @@ config ARM
select ARCH_HAS_PHYS_TO_DMA
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
select ARCH_HAS_STRICT_MODULE_RWX if MMU
+   select ARCH_HAS_SYNC_DMA_FOR_CPU if !MMU
+   select ARCH_HAS_SYNC_DMA_FOR_DEVICE if !MMU
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_HAS_GCOV_PROFILE_ALL
@@ -27,6 +29,8 @@ config ARM
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
select DMA_DIRECT_OPS if !MMU
+   select DMA_NONCOHERENT_OPS if !MMU
+   select DMA_NONCOHERENT_MMAP if !MMU
select EDAC_SUPPORT
select EDAC_ATOMIC_SCRUB
select GENERIC_ALLOCATOR
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index f448a0663b10..a74ed6632982 100644
--- a/arch/arm/mm/dma-mapping-nommu.c
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -26,18 +27,16 @@
  *   - MMU/MPU is off
  *   - cpu is v7m w/o cache support
  *   - device is coherent
- *  otherwise arm_nommu_dma_ops is used.
+ *  otherwise dma_noncoherent_ops is used.
  *
- *  arm_nommu_dma_ops rely on consistent DMA memory (please, refer to
+ *  dma_noncoherent_ops rely on consistent DMA memory (please, refer to
  *  [1] on how to declare such memory).
  *
  *  [1] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
  */
 
-static void *arm_nommu_dma_alloc(struct device *dev, size_t size,
-dma_addr_t *dma_handle, gfp_t gfp,
-unsigned long attrs)
-
+void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
+   gfp_t gfp, unsigned long attrs)
 {
void *ret;
 
@@ -65,9 +64,8 @@ static void *arm_nommu_dma_alloc(struct device *dev, size_t 
size,
return ret;
 }
 
-static void arm_nommu_dma_free(struct device *dev, size_t size,
-  void *cpu_addr, dma_addr_t dma_addr,
-  unsigned long attrs)
+void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
+   dma_addr_t dma_addr, unsigned long attrs)
 {
if (attrs & DMA_ATTR_NON_CONSISTENT) {
dma_direct_free(dev, size, cpu_addr, dma_addr, attrs);
@@ -81,9 +79,9 @@ static void arm_nommu_dma_free(struct device *dev, size_t 
size,
return;
 }
 
-static int arm_nommu_dma_mmap(struct device *dev, struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size,
- unsigned long attrs)
+int arch_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+   void *cpu_addr, dma_addr_t dma_addr, size_t size,
+   unsigned long attrs)
 {
int ret;
 
@@ -93,9 +91,8 @@ static int arm_nommu_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
 }
 
-
-static void __dma_page_cpu_to_dev(phys_addr_t paddr, size_t size,
- enum dma_data_direction dir)
+void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
+   size_t size, enum dma_data_direction dir)
 {
dmac_map_area(__va(paddr), size, dir);
 
@@ -105,8 +102,8 @@ static void __dma_page_cpu_to_dev(phys_addr_t paddr, size_t 
size,
outer_clean_range(paddr, paddr + size);
 }
 
-static void __dma_page_dev_to_cpu(phys_addr_t paddr, size_t size,
- enum dma_data_direction dir)
+void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr,
+   size_t size, enum dma_data_direction dir)
 {
if (dir != DMA_TO_DEVICE) {
outer_inv_range(paddr, paddr + size);
@@ -114,110 +111,9 @@ static void __dma_page_dev_to_cpu(phys_addr_t paddr, 
size_t size,
}
 }
 
-static dma_addr_t arm_nommu_dma_map_page(struct device *dev, struct page *page,
- 

[PATCH 08/22] c6x: use generic dma_noncoherent_ops

[Christoph Hellwig]

Switch to the generic noncoherent direct mapping implementation.

Signed-off-by: Christoph Hellwig 
---
 arch/c6x/Kconfig   |   3 +
 arch/c6x/include/asm/Kbuild|   1 +
 arch/c6x/include/asm/dma-mapping.h |  28 --
 arch/c6x/include/asm/setup.h   |   2 +
 arch/c6x/kernel/Makefile   |   2 +-
 arch/c6x/kernel/dma.c  | 138 -
 arch/c6x/mm/dma-coherent.c |  40 -
 7 files changed, 44 insertions(+), 170 deletions(-)
 delete mode 100644 arch/c6x/include/asm/dma-mapping.h
 delete mode 100644 arch/c6x/kernel/dma.c

diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index c6b4dd1418b4..8d7a3b38810f 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -6,7 +6,10 @@
 
 config C6X
def_bool y
+   select ARCH_HAS_SYNC_DMA_FOR_CPU
+   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select CLKDEV_LOOKUP
+   select DMA_NONCOHERENT_OPS
select GENERIC_ATOMIC64
select GENERIC_IRQ_SHOW
select HAVE_ARCH_TRACEHOOK
diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild
index fd4c840de837..434600e47662 100644
--- a/arch/c6x/include/asm/Kbuild
+++ b/arch/c6x/include/asm/Kbuild
@@ -5,6 +5,7 @@ generic-y += current.h
 generic-y += device.h
 generic-y += div64.h
 generic-y += dma.h
+generic-y += dma-mapping.h
 generic-y += emergency-restart.h
 generic-y += exec.h
 generic-y += extable.h
diff --git a/arch/c6x/include/asm/dma-mapping.h 
b/arch/c6x/include/asm/dma-mapping.h
deleted file mode 100644
index 05daf1038111..
--- a/arch/c6x/include/asm/dma-mapping.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/*
- *  Port on Texas Instruments TMS320C6x architecture
- *
- *  Copyright (C) 2004, 2009, 2010, 2011 Texas Instruments Incorporated
- *  Author: Aurelien Jacquiot 
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2 as
- *  published by the Free Software Foundation.
- *
- */
-#ifndef _ASM_C6X_DMA_MAPPING_H
-#define _ASM_C6X_DMA_MAPPING_H
-
-extern const struct dma_map_ops c6x_dma_ops;
-
-static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
-{
-   return _dma_ops;
-}
-
-extern void coherent_mem_init(u32 start, u32 size);
-void *c6x_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
-   gfp_t gfp, unsigned long attrs);
-void c6x_dma_free(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_handle, unsigned long attrs);
-
-#endif /* _ASM_C6X_DMA_MAPPING_H */
diff --git a/arch/c6x/include/asm/setup.h b/arch/c6x/include/asm/setup.h
index 852afb209afb..350f34debb19 100644
--- a/arch/c6x/include/asm/setup.h
+++ b/arch/c6x/include/asm/setup.h
@@ -28,5 +28,7 @@ extern unsigned char c6x_fuse_mac[6];
 extern void machine_init(unsigned long dt_ptr);
 extern void time_init(void);
 
+extern void coherent_mem_init(u32 start, u32 size);
+
 #endif /* !__ASSEMBLY__ */
 #endif /* _ASM_C6X_SETUP_H */
diff --git a/arch/c6x/kernel/Makefile b/arch/c6x/kernel/Makefile
index 02f340d7b8fe..fbe74174de87 100644
--- a/arch/c6x/kernel/Makefile
+++ b/arch/c6x/kernel/Makefile
@@ -8,6 +8,6 @@ extra-y := head.o vmlinux.lds
 obj-y := process.o traps.o irq.o signal.o ptrace.o
 obj-y += setup.o sys_c6x.o time.o devicetree.o
 obj-y += switch_to.o entry.o vectors.o c6x_ksyms.o
-obj-y += soc.o dma.o
+obj-y += soc.o
 
 obj-$(CONFIG_MODULES)   += module.o
diff --git a/arch/c6x/kernel/dma.c b/arch/c6x/kernel/dma.c
deleted file mode 100644
index 31e1a9ec3a9c..
--- a/arch/c6x/kernel/dma.c
+++ /dev/null
@@ -1,138 +0,0 @@
-/*
- *  Copyright (C) 2011 Texas Instruments Incorporated
- *  Author: Mark Salter 
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2 as
- *  published by the Free Software Foundation.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-static void c6x_dma_sync(dma_addr_t handle, size_t size,
-enum dma_data_direction dir)
-{
-   unsigned long paddr = handle;
-
-   BUG_ON(!valid_dma_direction(dir));
-
-   switch (dir) {
-   case DMA_FROM_DEVICE:
-   L2_cache_block_invalidate(paddr, paddr + size);
-   break;
-   case DMA_TO_DEVICE:
-   L2_cache_block_writeback(paddr, paddr + size);
-   break;
-   case DMA_BIDIRECTIONAL:
-   L2_cache_block_writeback_invalidate(paddr, paddr + size);
-   break;
-   default:
-   break;
-   }
-}
-
-static dma_addr_t c6x_dma_map_page(struct device *dev, struct page *page,
-   unsigned long offset, size_t size, enum dma_data_direction dir,
-   unsigned long attrs)
-{
-   dma_addr_t handle = virt_to_phys(page_address(page) + offset);
-
-   if (!(attrs & 

Re: [RFC] perf/core: what is exclude_idle supposed to do

[Peter Zijlstra]

On Mon, Apr 16, 2018 at 10:04:53PM +, Stephane Eranian wrote:
> Hi,
> 
> I am trying to understand what the exclude_idle event attribute is supposed
> to accomplish.
> As per the definition in the header file:
> 
> exclude_idle   :  1, /* don't count when idle */
> 
> Naively, I thought it would simply stop the event when running in the
> context of the idle task (swapper, pid 0) on any CPU. That would seem to
> match the succinct description.
> 
> However, running a simple:
> 
> $ perf record -a -e cycles:I sleep 5
> perf_event_attr:
> sample_type  IP|TID|TIME|CPU|PERIOD
>read_format  TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING|ID
>exclude_idle 1
> 
> on an idle machine, showed me that this is not what is actually happening:
> $ perf  script
>   swapper 0 [000] 1132634.287442:  1 cycles:I:
>   8100b1fb __intel_pmu_enable_all.isra.17 ([kernel.kallsyms])
>   swapper 0 [001] 1132634.287498:  1 cycles:I:
>   8100b1fb __intel_pmu_enable_all.isra.17 ([kernel.kallsyms])
> 
> 
> After looking at the code, it all made sense, it seems to current
> implementation is only relevant for sw events. I don't understand why.
> 
> I am left wondering what is the goal of exclude_idle?

A "git grep exclude_idle" seems to suggest powerpc/arm have it
immplemented for their PMU. If we then look at commit:

  2743a5b0fa6f ("perfcounters: provide expansion room in the ABI")

It was Paul who introduced the bit.

So I'm thinking that if x86 doesn't implement it, we should at least
error out on it. Of course, so far we've allowed it, so who knows what
all will break if we start asserting that :/

Re: [patch V2 7/8] dm verity fec: Check result of init_rs()

[Thomas Gleixner]

On Fri, 20 Apr 2018, NeilBrown wrote:
> On Thu, Apr 19 2018, Thomas Gleixner wrote:
> > The analysis above forgot to look at the mempool->alloc() callback. So yes,
> > while the NOIO is good at the mempool level, but init_rs() uses GPF_KERNEL
> > so there might be a different can of wurms lurking.
> 
> The ->alloc call back is not relevant to the question of when
> mempool_alloc() can return NULL.
> If the ->alloc() callback returns a non-NULL value, it will be returned
> by mempool_alloc().
> If it returns NULL, that will not be returned.

Yes, as I said before, I missed the NOIO flag.

> 
> mempool_alloc() *only* returns NULL in one place:
> 
>   if (!(gfp_mask & __GFP_DIRECT_RECLAIM)) {
>   spin_unlock_irqrestore(>lock, flags);
>   return NULL;
>   }
> 
> so a NULL return is purely dependent on the GFP flags passed.
> GFP_NOIO contains __GFP_DIRECT_RECLAIM, so NULL cannot be returned.
> 
> It seems quite broken that init_rs() uses GFP_KERNEL. It should take a
> gfp_t arg for the allocation.

Well, init_rs() was that way before somebody used it in a mempool_alloc()
callback. And all other users are fine with GFP_KERNEL AFAICT.

> If the mempool_alloc() above really needs GFP_NOIO, then it could
> theoretically deadlock as it performs a GFP_KERNEL allocation inside
> rs_init().  So in that sense, the code is not correct as-is.
> It could possibly be fixed by calling memalloc_noio_save() /
> memalloc_noio_restore() around the call to init_rs() in fec_rs_alloc().

No, we surely can add a gfp aware version of init_rs(). It's trivial enough
to do.

Thanks,

tglx

[PATCH] arm64: defconfig: Enable CONFIG_PINCTRL_MT7622 by default

[sean.wang]

From: Sean Wang 

Recently kernelCI reported the board mt7622-rfb1 has a fail test with
kernel: ERROR: did not start booting whose details could be seen at [1].

The cause is that UART0 can't output anything when it's missing a proper
pin setup with current DTS, so the essential driver is always getting
enabled to fix up the issue.

[1] https://kernelci.org/boot/id/5ad7d62759b51461bfb1f829/

Cc: Kevin Hilman 
Cc: sta...@vger.kernel.org
Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device 
nodes")
Signed-off-by: Sean Wang 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ecf6137..fe005df 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -320,6 +320,7 @@ CONFIG_PINCTRL_MAX77620=y
 CONFIG_PINCTRL_MSM8916=y
 CONFIG_PINCTRL_MSM8994=y
 CONFIG_PINCTRL_MSM8996=y
+CONFIG_PINCTRL_MT7622=y
 CONFIG_PINCTRL_QDF2XXX=y
 CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
 CONFIG_GPIO_DWAPB=y
-- 
2.7.4

Re: [PATCH 2/2] drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+

[Daniel Vetter]

On Thu, Apr 19, 2018 at 12:20:35PM -0700, Eric Anholt wrote:
> This driver will be used to support Mesa on the Broadcom 7268 and 7278
> platforms.
> 
> V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's
> complicated CL/shader validation scheme.  This massively changes the
> GEM behavior, so I've forked off to a new driver.
> 
> Signed-off-by: Eric Anholt 

Read through the entire thing, ignored the hw details, but dropped a few
comments all over. With those addressed one way or another this has my

Acked-by: Daniel Vetter 

Can I call in a return favour for
https://patchwork.freedesktop.org/series/41219/ ?

Cheers, Daniel

> ---
>  Documentation/gpu/drivers.rst  |   1 +
>  MAINTAINERS|   9 +
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/v3d/Kconfig|   9 +
>  drivers/gpu/drm/v3d/Makefile   |  18 +
>  drivers/gpu/drm/v3d/v3d_bo.c   | 392 +++
>  drivers/gpu/drm/v3d/v3d_debugfs.c  | 191 +++
>  drivers/gpu/drm/v3d/v3d_drv.c  | 371 ++
>  drivers/gpu/drm/v3d/v3d_drv.h  | 305 +++
>  drivers/gpu/drm/v3d/v3d_fence.c|  58 +++
>  drivers/gpu/drm/v3d/v3d_gem.c  | 671 +
>  drivers/gpu/drm/v3d/v3d_irq.c  | 211 
>  drivers/gpu/drm/v3d/v3d_mmu.c  | 122 +
>  drivers/gpu/drm/v3d/v3d_regs.h | 295 +++
>  drivers/gpu/drm/v3d/v3d_sched.c| 230 +
>  drivers/gpu/drm/v3d/v3d_trace.h|  82 +++
>  drivers/gpu/drm/v3d/v3d_trace_points.c |   9 +
>  include/uapi/drm/v3d_drm.h | 191 +++
>  19 files changed, 3168 insertions(+)
>  create mode 100644 drivers/gpu/drm/v3d/Kconfig
>  create mode 100644 drivers/gpu/drm/v3d/Makefile
>  create mode 100644 drivers/gpu/drm/v3d/v3d_bo.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_debugfs.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_drv.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_drv.h
>  create mode 100644 drivers/gpu/drm/v3d/v3d_fence.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_gem.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_irq.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_mmu.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_regs.h
>  create mode 100644 drivers/gpu/drm/v3d/v3d_sched.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_trace.h
>  create mode 100644 drivers/gpu/drm/v3d/v3d_trace_points.c
>  create mode 100644 include/uapi/drm/v3d_drm.h
> 
> diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
> index d3ab6abae838..f982558fc25d 100644
> --- a/Documentation/gpu/drivers.rst
> +++ b/Documentation/gpu/drivers.rst
> @@ -10,6 +10,7 @@ GPU Driver Documentation
> tegra
> tinydrm
> tve200
> +   v3d
> vc4
> bridge/dw-hdmi
> xen-front
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bca3c32fb141..7314d66833fd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4795,6 +4795,15 @@ S: Maintained
>  F:   drivers/gpu/drm/omapdrm/
>  F:   Documentation/devicetree/bindings/display/ti/
>  
> +DRM DRIVERS FOR V3D
> +M:   Eric Anholt 
> +T:   git git://github.com/anholt/linux

This one also official? If it's just for now I'd drop it ...

> +S:   Supported
> +F:   drivers/gpu/drm/v3d/
> +F:   include/uapi/drm/v3d_drm.h
> +F:   Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +
>  DRM DRIVERS FOR VC4
>  M:   Eric Anholt 
>  T:   git git://github.com/anholt/linux
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 757825ac60df..1c73a455fdb1 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -267,6 +267,8 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig"
>  
>  source "drivers/gpu/drm/imx/Kconfig"
>  
> +source "drivers/gpu/drm/v3d/Kconfig"
> +
>  source "drivers/gpu/drm/vc4/Kconfig"
>  
>  source "drivers/gpu/drm/etnaviv/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 9d66657ea117..7a401edd8761 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_DRM_MGA)   += mga/
>  obj-$(CONFIG_DRM_I810)   += i810/
>  obj-$(CONFIG_DRM_I915)   += i915/
>  obj-$(CONFIG_DRM_MGAG200) += mgag200/
> +obj-$(CONFIG_DRM_V3D)  += v3d/
>  obj-$(CONFIG_DRM_VC4)  += vc4/
>  obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
>  obj-$(CONFIG_DRM_SIS)   += sis/
> diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
> new file mode 100644
> index ..a0c0259355bd
> --- /dev/null
> +++ b/drivers/gpu/drm/v3d/Kconfig
> @@ -0,0 +1,9 @@
> +config DRM_V3D
> + tristate "Broadcom V3D 3.x and newer"
> + depends on ARCH_BCM || ARCH_BCMSTB || COMPILE_TEST
> + depends on DRM
> + depends on COMMON_CLK
> + select DRM_SCHED
> + help
> +   

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christian König]

Am 20.04.2018 um 09:13 schrieb Daniel Vetter:

On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:

On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:

We've broken that assumption in i915 years ago. Not struct page backed
gpu memory is very real.

Of course we'll never feed such a strange sg table to a driver which
doesn't understand it, but allowing sg_page == NULL works perfectly
fine. At least for gpu drivers.

For GPU drivers on x86 with no dma coherency problems, sure.  But not
all the world is x86.  We already have problems due to dmabugs use
of the awkward get_sgtable interface (see the common on
arm_dma_get_sgtable that I fully agree with), and doing this for memory
that doesn't have a struct page at all will make things even worse.

x86 dma isn't coherent either, if you're a GPU :-) Flushing gpu caches
tends to be too expensive, so there's pci-e support and chipset support to
forgo it. Plus drivers flushing caches themselves.

The dma_get_sgtable thing is indeed fun, right solution would probably be
to push the dma-buf export down into the dma layer. The comment for
arm_dma_get_sgtable is also not a realy concern, because dma-buf also
abstracts away the flushing (or well is supposed to), so there really
shouldn't be anyone calling the streaming apis on the returned sg table.
That's why dma-buf gives you an sg table that's mapped already.


If that's not acceptable then I guess we could go over the entire tree
and frob all the gpu related code to switch over to a new struct
sg_table_might_not_be_struct_page_backed, including all the other
functions we added over the past few years to iterate over sg tables.
But seems slightly silly, given that sg tables seem to do exactly what
we need.

It isn't silly.  We will have to do some surgery like that anyway
because the current APIs don't work.  So relax, sit back and come up
with an API that solves the existing issues and serves us well in
the future.

So we should just implement a copy of sg table for dma-buf, since I still
think it does exactly what we need for gpus?

Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into  dma-buf", but that doesn't render the interface a bad idea.


Completely agree on that.

What we need is an sg_alloc_table_from_resources(dev, resources, 
num_resources) which does the handling common to all drivers.


Christian.


-Daniel

Re: [PATCH v3 0/4] regulator: bd9571mwv: Add support for DDR backup mode

[Lee Jones]

On Fri, 20 Apr 2018, Geert Uytterhoeven wrote:
> On Fri, Apr 20, 2018 at 9:49 AM, Lee Jones  wrote:
> > On Wed, 18 Apr 2018, Geert Uytterhoeven wrote:
> >> The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB
> >> development boards supports DDR Backup Power, which means that the DDR
> >> power rails can be kept powered while the main SoC is powered down.
> >
> > Should this set be applied together, or can the MFD patches be applied
> > on their own, without the Regulator patch?
> 
> The regulator patch depends on the MFD patches, so it's best for them to
> go in together.
> 
> > If the former, then we're going to need an Ack from Mark.
> 
> Alternative, as you've already supplied (some form of) your Ack for the firs
> 3 patches, they can go in through Mark? All of it is enhancing the
> regulator part.

Yes, that's fine too:

Acked-by: Lee Jones 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v1 0/4] Add DMAv2 and DMAMUX Support on STM32MP157C

[Pierre-Yves MORDRET]

This patch adds DMAv2 and DMAMUX support on STM32MP157C with configs and device 
tree.
---
  Version history:
 v1:
* Initial
---

Pierre-Yves MORDRET (4):
  ARM: configs: stm32: Add DMAv2 support on STM32MP157C machine
  ARM: configs: stm32: Add DMAMUX support on STM32MP157C
  ARM: dts: stm32: Add DMAv2 support on STM32MP157C
  ARM: dts: stm32: Add DMAMUX support on STM32MP157C

 arch/arm/boot/dts/stm32mp157c.dtsi | 44 ++
 arch/arm/mach-stm32/Kconfig|  2 ++
 2 files changed, 46 insertions(+)

-- 
2.7.4

Re: [PATCH] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()

[Juri Lelli]

Hi Kirill,

On 19/04/18 20:29, Kirill Tkhai wrote:
> tg_rt_schedulable() iterates over all child task groups,
> while tg_has_rt_tasks() iterates over all linked tasks.
> In case of systems with big number of tasks, this may
> take a lot of time.
> 
> I observed hard LOCKUP on machine with 2+ processes
> after write to "cpu.rt_period_us" of cpu cgroup with
> 39 children. The problem occurred because of tasklist_lock
> is held for a long time and other processes can't do fork().
> 
> PID: 1036268  TASK: 88766c31  CPU: 36  COMMAND: "criu"
>  #0 [887f7f408e48] crash_nmi_callback at 81050601
>  #1 [887f7f408e58] nmi_handle at 816e0cc7
>  #2 [887f7f408eb0] do_nmi at 816e0fb0
>  #3 [887f7f408ef0] end_repeat_nmi at 816e00b9
> [exception RIP: tg_rt_schedulable+463]
> RIP: 810bf49f  RSP: 886537ad7d50  RFLAGS: 0202
> RAX:   RBX: 3b9aca00  RCX: 883e9cb4b1b0
> RDX: 887d0be43608  RSI: 886537ad7dd8  RDI: 8840a6ad
> RBP: 886537ad7d68   R8: 887d0be431b0   R9: 000e7ef0
> R10: 88164fc39400  R11: 00023380  R12: 81ef8d00
> R13: 810bea40  R14:   R15: 8840a6ad
> ORIG_RAX:   CS: 0010  SS: 0018
> ---  ---
>  #4 [886537ad7d50] tg_rt_schedulable at 810bf49f
>  #5 [886537ad7d70] walk_tg_tree_from at 810c6c91
>  #6 [886537ad7dc0] tg_set_rt_bandwidth at 810c6dd0
>  #7 [886537ad7e28] cpu_rt_period_write_uint at 810c6eea
>  #8 [886537ad7e38] cgroup_file_write at 8111cfd3
>  #9 [886537ad7ec8] vfs_write at 8121eced
> #10 [886537ad7f08] sys_write at 8121faff
> #11 [886537ad7f50] system_call_fastpath at 816e8a7d
> 
> The patch reworks tg_has_rt_tasks() and makes it to check
> for rt_rq::rt_nr_running instead of iteration over task list.
> This makes the function to scale well, and its execution time
> does not depend on number of processes in the system.
> 
> Note, that since tasklist_lock doesn't protect a task against
> sched_class changing, we don't introduce new races in comparison
> to that we had before. Also, rt_rq::rt_nr_running contains queued
> child cfs_rq in additional to queued task. Since tg_has_rt_tasks()

s/cfs_/rt_/ , right?

> is used in case of !runtime case:
> 
>   if (rt_bandwidth_enabled() && !runtime && tg_has_rt_tasks(tg))
>   return -EBUSY;
> 
> the behaviour won't change. The only change is that walk_tg_tree()
> calling tg_rt_schedulable() will break its iteration on parent cfs_rq,

Ditto.

> i.e. earlier.
> 
> Signed-off-by: Kirill Tkhai 
> ---
>  kernel/sched/rt.c |   22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 7aef6b4e885a..601151bb9322 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -2395,10 +2395,10 @@ const struct sched_class rt_sched_class = {
>   */
>  static DEFINE_MUTEX(rt_constraints_mutex);
>  
> -/* Must be called with tasklist_lock held */
>  static inline int tg_has_rt_tasks(struct task_group *tg)
>  {
> - struct task_struct *g, *p;
> + struct rt_rq *rt_rq;
> + int cpu, ret = 0;
>  
>   /*
>* Autogroups do not have RT tasks; see autogroup_create().
> @@ -2406,12 +2406,18 @@ static inline int tg_has_rt_tasks(struct task_group 
> *tg)
>   if (task_group_is_autogroup(tg))
>   return 0;
>  
> - for_each_process_thread(g, p) {
> - if (rt_task(p) && task_group(p) == tg)
> - return 1;
> + preempt_disable();
> +
> + for_each_online_cpu(cpu) {
> + rt_rq = tg->rt_rq[cpu];
> + if (READ_ONCE(rt_rq->rt_nr_running)) {

Isn't this however checking against the current (dynamic) number of
runnable tasks/groups instead of the "static" group membership (which
shouldn't be affected by a task running state)?

Best,

- Juri

[PATCH] regulator: wm8350: fix missing increment of loop index i

[Colin King]

From: Colin Ian King 

It seems that the loop index i is not being incremented and hence
potentially the while loop could spin forever. Fortunately with the
data being used this does not appear to happen at the moment.

Fixes: da09155ac8d3 ("regulator: Add WM8350 regulator support")
Signed-off-by: Colin Ian King 
---
 drivers/regulator/wm8350-regulator.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/wm8350-regulator.c 
b/drivers/regulator/wm8350-regulator.c
index da9106bd2109..8ad11b074b49 100644
--- a/drivers/regulator/wm8350-regulator.c
+++ b/drivers/regulator/wm8350-regulator.c
@@ -911,6 +911,7 @@ static unsigned int get_mode(int uA, const struct 
wm8350_dcdc_efficiency *eff)
while (eff[i].uA_load_min != -1) {
if (uA >= eff[i].uA_load_min && uA <= eff[i].uA_load_max)
return eff[i].mode;
+   i++;
}
return REGULATOR_MODE_NORMAL;
 }
-- 
2.17.0

Re: [PATCH] iommu/amd: fix unused-variable warning

[Sebastian Andrzej Siewior]

On 2018-04-20 11:28:36 [+0200], Tobias Regnery wrote:
> The iommu_table_lock is only used by code inside an ifdef CONFIG_IRQ_REMAP
> block. This leads to the following warning with CONFIG_IRQ_REMAP=n:
> 
> amd_iommu.c:86:24: warning: 'iommu_table_lock' defined but not used 
> [-Wunused-variable]
> 
> Guard the spinlock definition with the same ifdef.
> 
> Fixes: ea6166f4b83e9 ("iommu/amd: Split irq_lookup_table out of the 
> amd_iommu_devtable_lock")
> Signed-off-by: Tobias Regnery 

Thank you for spotting this, I am waiting for Jörg to pick up this
instead:
  http://lkml.kernel.org/r/20180404105713.633983-1-a...@arndb.de

Sebastian

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
> > We've broken that assumption in i915 years ago. Not struct page backed
> > gpu memory is very real.
> > 
> > Of course we'll never feed such a strange sg table to a driver which
> > doesn't understand it, but allowing sg_page == NULL works perfectly
> > fine. At least for gpu drivers.
> 
> For GPU drivers on x86 with no dma coherency problems, sure.  But not
> all the world is x86.  We already have problems due to dmabugs use
> of the awkward get_sgtable interface (see the common on
> arm_dma_get_sgtable that I fully agree with), and doing this for memory
> that doesn't have a struct page at all will make things even worse.

x86 dma isn't coherent either, if you're a GPU :-) Flushing gpu caches
tends to be too expensive, so there's pci-e support and chipset support to
forgo it. Plus drivers flushing caches themselves.

The dma_get_sgtable thing is indeed fun, right solution would probably be
to push the dma-buf export down into the dma layer. The comment for
arm_dma_get_sgtable is also not a realy concern, because dma-buf also
abstracts away the flushing (or well is supposed to), so there really
shouldn't be anyone calling the streaming apis on the returned sg table.
That's why dma-buf gives you an sg table that's mapped already.

> > If that's not acceptable then I guess we could go over the entire tree
> > and frob all the gpu related code to switch over to a new struct
> > sg_table_might_not_be_struct_page_backed, including all the other
> > functions we added over the past few years to iterate over sg tables.
> > But seems slightly silly, given that sg tables seem to do exactly what
> > we need.
> 
> It isn't silly.  We will have to do some surgery like that anyway
> because the current APIs don't work.  So relax, sit back and come up
> with an API that solves the existing issues and serves us well in
> the future.

So we should just implement a copy of sg table for dma-buf, since I still
think it does exactly what we need for gpus?

Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into  dma-buf", but that doesn't render the interface a bad idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 10/61] gpio: simplify getting .drvdata

[Michal Simek]

Hi Wolfram,

On 19.4.2018 16:05, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> Build tested only. buildbot is happy. Please apply individually.
> 
>  drivers/gpio/gpio-dwapb.c |  6 ++
>  drivers/gpio/gpio-lynxpoint.c |  3 +--
>  drivers/gpio/gpio-omap.c  | 12 
>  drivers/gpio/gpio-tegra.c |  6 ++
>  drivers/gpio/gpio-zynq.c  |  6 ++
>  5 files changed, 11 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
> index 226977f78482..caaabb79e31f 100644
> --- a/drivers/gpio/gpio-dwapb.c
> +++ b/drivers/gpio/gpio-dwapb.c
> @@ -732,8 +732,7 @@ static int dwapb_gpio_remove(struct platform_device *pdev)
>  #ifdef CONFIG_PM_SLEEP
>  static int dwapb_gpio_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dwapb_gpio *gpio = platform_get_drvdata(pdev);
> + struct dwapb_gpio *gpio = dev_get_drvdata(dev);
>   struct gpio_chip *gc= >ports[0].gc;
>   unsigned long flags;
>   int i;
> @@ -777,8 +776,7 @@ static int dwapb_gpio_suspend(struct device *dev)
>  
>  static int dwapb_gpio_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct dwapb_gpio *gpio = platform_get_drvdata(pdev);
> + struct dwapb_gpio *gpio = dev_get_drvdata(dev);
>   struct gpio_chip *gc= >ports[0].gc;
>   unsigned long flags;
>   int i;
> diff --git a/drivers/gpio/gpio-lynxpoint.c b/drivers/gpio/gpio-lynxpoint.c
> index 1e557b10d73e..55fa33b7209f 100644
> --- a/drivers/gpio/gpio-lynxpoint.c
> +++ b/drivers/gpio/gpio-lynxpoint.c
> @@ -408,8 +408,7 @@ static int lp_gpio_runtime_resume(struct device *dev)
>  
>  static int lp_gpio_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct lp_gpio *lg = platform_get_drvdata(pdev);
> + struct lp_gpio *lg = dev_get_drvdata(dev);
>   unsigned long reg;
>   int i;
>  
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 35971a341c40..b4f8a048a2a1 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -856,8 +856,7 @@ static void omap_gpio_unmask_irq(struct irq_data *d)
>  
>  static int omap_mpuio_suspend_noirq(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct gpio_bank*bank = platform_get_drvdata(pdev);
> + struct gpio_bank*bank = dev_get_drvdata(dev);
>   void __iomem*mask_reg = bank->base +
>   OMAP_MPUIO_GPIO_MASKIT / bank->stride;
>   unsigned long   flags;
> @@ -871,8 +870,7 @@ static int omap_mpuio_suspend_noirq(struct device *dev)
>  
>  static int omap_mpuio_resume_noirq(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct gpio_bank*bank = platform_get_drvdata(pdev);
> + struct gpio_bank*bank = dev_get_drvdata(dev);
>   void __iomem*mask_reg = bank->base +
>   OMAP_MPUIO_GPIO_MASKIT / bank->stride;
>   unsigned long   flags;
> @@ -1284,8 +1282,7 @@ static void omap_gpio_restore_context(struct gpio_bank 
> *bank);
>  
>  static int omap_gpio_runtime_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct gpio_bank *bank = platform_get_drvdata(pdev);
> + struct gpio_bank *bank = dev_get_drvdata(dev);
>   u32 l1 = 0, l2 = 0;
>   unsigned long flags;
>   u32 wake_low, wake_hi;
> @@ -1352,8 +1349,7 @@ static void omap_gpio_init_context(struct gpio_bank *p);
>  
>  static int omap_gpio_runtime_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct gpio_bank *bank = platform_get_drvdata(pdev);
> + struct gpio_bank *bank = dev_get_drvdata(dev);
>   u32 l = 0, gen, gen0, gen1;
>   unsigned long flags;
>   int c;
> diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
> index 94396caaca75..04c963f03b68 100644
> --- a/drivers/gpio/gpio-tegra.c
> +++ b/drivers/gpio/gpio-tegra.c
> @@ -403,8 +403,7 @@ static void tegra_gpio_irq_handler(struct irq_desc *desc)
>  #ifdef CONFIG_PM_SLEEP
>  static int tegra_gpio_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct tegra_gpio_info *tgi = platform_get_drvdata(pdev);
> + struct tegra_gpio_info *tgi = dev_get_drvdata(dev);
>   unsigned long flags;
>   unsigned int b, p;
>  
> @@ -443,8 +442,7 @@ static int tegra_gpio_resume(struct device *dev)
>  
>  static int tegra_gpio_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = 

[PATCH v2] platform/x86: dell-wmi: Ignore new rfkill and fn-lock events

[Kai-Heng Feng]

There are two new events generated by dell-wmi, rfkill and fn-lock, from
Dell Systems.

When Fn-lock hotkey gets pressed to switch to function mode:
[85951.591542] dell_wmi: Unknown key with type 0x0010 and code 0xe035
pressed
[85951.591546] dell_wmi: Unknown key with type 0x0010 and code 0x
pressed

When Fn-lock hotkey gets pressed to switch to multimedia mode:
[85956.667686] dell_wmi: Unknown key with type 0x0010 and code 0xe035
pressed
[85956.667690] dell_wmi: Unknown key with type 0x0010 and code 0x0001
pressed

When radio hotkey gets pressed:
[85974.430220] dell_wmi: Unknown key with type 0x0010 and code 0xe008
pressed

These events are for notification purpose, so we can ignore them.

This patch is tested on XPS 9370.

Signed-off-by: Kai-Heng Feng 
---
v2: Reorder alphabetically.
More detailed changelog.

 drivers/platform/x86/dell-wmi.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 8d102195a392..ba8e6725d7ac 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -261,6 +261,12 @@ static const u16 bios_to_linux_keycode[256] = {
  * override them.
  */
 static const struct key_entry dell_wmi_keymap_type_0010[] = {
+   /* Fn-lock switched to function keys */
+   { KE_IGNORE, 0x0, { KEY_RESERVED } },
+
+   /* Fn-lock switched to multimedia keys */
+   { KE_IGNORE, 0x1, { KEY_RESERVED } },
+
/* Mic mute */
{ KE_KEY, 0x150, { KEY_MICMUTE } },
 
@@ -296,6 +302,14 @@ static const struct key_entry dell_wmi_keymap_type_0010[] 
= {
{ KE_KEY,0x851, { KEY_PROG2 } },
{ KE_KEY,0x852, { KEY_PROG3 } },
 
+   /*
+* Radio disable (notify only -- there is no model for which the
+* WMI event is supposed to trigger an action).
+*/
+   { KE_IGNORE, 0xe008, { KEY_RFKILL } },
+
+   /* Fn-lock */
+   { KE_IGNORE, 0xe035, { KEY_RESERVED } },
 };
 
 /*
-- 
2.17.0

Re: [RFC PATCH 3/4] acpi: apei: Do not panic() in NMI because of GHES messages

[James Morse]

Hi Alex,

On 04/16/2018 10:59 PM, Alex G. wrote:
> On 04/13/2018 11:38 AM, James Morse wrote:
>> This assumes a cache-invalidate will clear the error, which I don't 
think we're

>> guaranteed on arm.
>> It also destroys any adjacent data, "everyone's happy" includes the 
thread that
>> got a chunk of someone-else's stack frame, I don't think it will be 
happy for

>> very long!
>
> Hmm, no cache-line (or page) invalidation on arm64? How does
> dma_map/unmap_*() work then? You may not guarantee to fix the error, but

There are cache-invalidate instructions, but I don't think 'solving' a 
RAS error with them is the right thing to do.



> I don't buy into the "let's crash without trying" argument.

Our 'cache writeback granule' may be as large as 2K, so we may have to 
invalidate up to 2K of data to convince the hardware this address is 
okay again.


All we've done here is differently-corrupt the data so that it no longer 
generates a RAS fault, it just gives you the wrong data instead. 
Cache-invalidation is destructive.


I don't think there is a one-size-fits-all solution here.


>> (this is a side issue for AER though)
>
> Somebody muddled up AER with these tables, so we now have to worry about
> it. :)

Eh? I see there is a v2, maybe I'll understand this comment once I read it.


>>> How does FFS handle race conditions that can occur when accessing HW
>>> concurrently with the OS? I'm told it's the main reasons why BIOS
>>> doesn't release unused cores from SMM early.
>>
>> This is firmware's problem, it depends on whether there is any 
hardware that is
>> shared with the OS. Some hardware can be marked 'secure' in which 
case only
>> firmware can access it, alternatively firmware can trap or just 
disable the OS's

>> access to the shared hardware.
>
> It's everyone's problem. It's the firmware's responsibility.

It depends on the SoC design. If there is no hardware that the OS and 
firmware both need to access to handle an error then I don't think 
firmware needs to do this.



>> For example, with the v8.2 RAS Extensions, there are some per-cpu error
>> registers. Firmware can disable these for the OS, so that it always 
reads 0 from

>> them. Instead firmware takes the error via FF, reads the registers from
>> firmware, and dumps CPER records into the OS's memory.
>>
>> If there is a shared hardware resource that both the OS and firmware 
may be
>> accessing, yes firmware needs to pull the other CPUs in, but this 
depends on the

>> SoC design, it doesn't necessarily happen.
>
> The problem with shared resources is just a problem. I've seen systems
> where all 100 cores are held up for 300+ ms. In latency-critical
> applications reliability drops exponentially. Am I correct in assuming
> your answer would be to "hide" more stuff from the OS?

No, I'm not a fan of firmware cycle stealing. If you can design the SoC or
firmware so that the 'all CPUs' stuff doesn't need to happen, then you 
won't get
these issues. (I don't design these things, I'm sure they're much more 
complicated

than I think!)

Because the firmware is SoC-specific, so it only needs to do exactly 
what is necessary.



>>> I think the idea of firmware-first is broken. But it's there, it's
>>> shipping in FW, so we have to accommodate it in SW.
>>
>> Part of our different-views here is firmware-first is taking 
something away from

>> you, whereas for me its giving me information that would otherwise be in
>> secret-soc-specific registers.
>
> Under this interpretation, FFS is a band-aid to the problem of "secret"
> registers. "Secret" hardware doesn't really fit well into the idea of an
> OS [1].

Sorry, I'm being sloppy with my terminology, by secret-soc-specific I 
mean either Linux can't access them (firmware privilege-level only) or 
Linux can't reasonably know where these registers are, as they're 
soc-specific and vary by manufacture.



>>> And linux can handle a wide subset of MCEs just fine, so the
>>> ghes_is_deferrable() logic would, under my argument, agree to pass
>>> execution to the actual handlers.
>>
>> For some classes of error we can't safely get there.
>
> Optimize for the common case.

At the expense of reliability?


Thanks,

James

Re: [PATCH 5/5] f2fs: fix to avoid race during access gc_thread pointer

[Chao Yu]

On 2018/4/20 11:54, Jaegeuk Kim wrote:
> On 04/20, Chao Yu wrote:
>> On 2018/4/20 11:19, Jaegeuk Kim wrote:
>>> On 04/18, Chao Yu wrote:
 Thread A   Thread BThread C
 - f2fs_remount
  - stop_gc_thread
- f2fs_sbi_store
- issue_discard_thread
sbi->gc_thread = NULL;
  sbi->gc_thread->gc_wake = 1
  access 
 sbi->gc_thread->gc_urgent
>>>
>>> Do we simply need a lock for this?
>>
>> Code will be more complicated for handling existed and new coming fields with
>> the sbi->gc_thread pointer, and causing unneeded lock overhead, right?
>>
>> So let's just allocate memory during fill_super?
> 
> No, the case is when stopping the thread. We can keep the gc_thread and 
> indicate
> its state as "disabled". Then, we need to handle other paths with the state?

After this patch, we use f2fs_gc_kthread.f2fs_gc_task to indicate whether GC
thread is existed, so you mean if we do that change, we also need to add a lock,
and access/update other fields in f2fs_gc_kthread after we check
f2fs_gc_kthread.f2fs_gc_task with a lock, right?

Like:

f2fs_sbi_store:

if (!strcmp(a->attr.name, "gc_urgent") && t == 1) {
gc_context_lock()
if (GC_I(sbi)->f2fs_gc_task) {
GC_I(sbi)->gc_wake = 1;
...
}
gc_context_unlock()

Do you mean that?

Thanks,

> 
>>
>> Thanks,
>>
>>>

 Previously, we allocate memory for sbi->gc_thread based on background
 gc thread mount option, the memory can be released if we turn off
 that mount option, but still there are several places access gc_thread
 pointer without considering race condition, result in NULL point
 dereference.

 In order to fix this issue, keep gc_thread structure valid in sbi all
 the time instead of alloc/free it dynamically.

 Signed-off-by: Chao Yu 
 ---
  fs/f2fs/debug.c   |  3 +--
  fs/f2fs/f2fs.h|  7 +++
  fs/f2fs/gc.c  | 58 
 +--
  fs/f2fs/segment.c |  4 ++--
  fs/f2fs/super.c   | 13 +++--
  fs/f2fs/sysfs.c   |  8 
  6 files changed, 60 insertions(+), 33 deletions(-)

 diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
 index 715beb85e9db..7bb036a3bb81 100644
 --- a/fs/f2fs/debug.c
 +++ b/fs/f2fs/debug.c
 @@ -223,8 +223,7 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
si->cache_mem = 0;
  
/* build gc */
 -  if (sbi->gc_thread)
 -  si->cache_mem += sizeof(struct f2fs_gc_kthread);
 +  si->cache_mem += sizeof(struct f2fs_gc_kthread);
  
/* build merge flush thread */
if (SM_I(sbi)->fcc_info)
 diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
 index 567c6bb57ae3..c553f63199e8 100644
 --- a/fs/f2fs/f2fs.h
 +++ b/fs/f2fs/f2fs.h
 @@ -1412,6 +1412,11 @@ static inline struct sit_info *SIT_I(struct 
 f2fs_sb_info *sbi)
return (struct sit_info *)(SM_I(sbi)->sit_info);
  }
  
 +static inline struct f2fs_gc_kthread *GC_I(struct f2fs_sb_info *sbi)
 +{
 +  return (struct f2fs_gc_kthread *)(sbi->gc_thread);
 +}
 +
  static inline struct free_segmap_info *FREE_I(struct f2fs_sb_info *sbi)
  {
return (struct free_segmap_info *)(SM_I(sbi)->free_info);
 @@ -2954,6 +2959,8 @@ bool f2fs_overwrite_io(struct inode *inode, loff_t 
 pos, size_t len);
  /*
   * gc.c
   */
 +int init_gc_context(struct f2fs_sb_info *sbi);
 +void destroy_gc_context(struct f2fs_sb_info * sbi);
  int start_gc_thread(struct f2fs_sb_info *sbi);
  void stop_gc_thread(struct f2fs_sb_info *sbi);
  block_t start_bidx_of_node(unsigned int node_ofs, struct inode *inode);
 diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
 index da89ca16a55d..7d310e454b77 100644
 --- a/fs/f2fs/gc.c
 +++ b/fs/f2fs/gc.c
 @@ -26,8 +26,8 @@
  static int gc_thread_func(void *data)
  {
struct f2fs_sb_info *sbi = data;
 -  struct f2fs_gc_kthread *gc_th = sbi->gc_thread;
 -  wait_queue_head_t *wq = >gc_thread->gc_wait_queue_head;
 +  struct f2fs_gc_kthread *gc_th = GC_I(sbi);
 +  wait_queue_head_t *wq = _th->gc_wait_queue_head;
unsigned int wait_ms;
  
wait_ms = gc_th->min_sleep_time;
 @@ -114,17 +114,15 @@ static int gc_thread_func(void *data)
return 0;
  }
  
 -int start_gc_thread(struct f2fs_sb_info *sbi)
 +int init_gc_context(struct f2fs_sb_info *sbi)
  {
struct f2fs_gc_kthread *gc_th;
 -  dev_t dev = sbi->sb->s_bdev->bd_dev;
 -  int err = 0;
  
gc_th = f2fs_kmalloc(sbi, sizeof(struct f2fs_gc_kthread), GFP_KERNEL);
 -  

Re: [PATCH v7 0/5] add compression algorithm zBeWalgo

[Minchan Kim]

Hi Benjamin,

Today I tried your new patchset but I couldn't go further due to below
problem. Unfortunately, I don't have the time to look into.
Could you check on it?

Thanks.

[  169.597064] zram0: detected capacity change from 1073741824 to 0
[  177.523268] zram0: detected capacity change from 0 to 1073741824
[  181.312545] BUG: sleeping function called from invalid context at 
mm/page-writeback.c:2274
[  181.315578] in_atomic(): 1, irqs_disabled(): 0, pid: 2051, name: dd
[  181.317804] 1 lock held by dd/2051:
[  181.318973]  #0: d83cd3cb (>bd_mutex){+.+.}, at: 
__blkdev_put+0x41/0x1f0
[  181.321590] CPU: 5 PID: 2051 Comm: dd Not tainted 4.16.0-mm1+ #202
[  181.323599] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[  181.326295] Call Trace:
[  181.327117]  dump_stack+0x67/0x9b
[  181.328246]  ___might_sleep+0x149/0x230
[  181.329475]  write_cache_pages+0x31d/0x620
[  181.330726]  ? tag_pages_for_writeback+0x140/0x140
[  181.332201]  ? __lock_acquire+0x2b5/0x1300
[  181.333466]  generic_writepages+0x5f/0x90
[  181.334695]  ? do_writepages+0x4b/0xf0
[  181.335840]  ? blkdev_readpages+0x20/0x20
[  181.337077]  do_writepages+0x4b/0xf0
[  181.338174]  ? __filemap_fdatawrite_range+0xb4/0x100
[  181.339672]  ? __blkdev_put+0x41/0x1f0
[  181.340826]  ? __filemap_fdatawrite_range+0xc1/0x100
[  181.342251]  __filemap_fdatawrite_range+0xc1/0x100
[  181.343610]  filemap_write_and_wait+0x2c/0x70
[  181.344867]  __blkdev_put+0x71/0x1f0
[  181.345891]  blkdev_close+0x21/0x30
[  181.346889]  __fput+0xeb/0x220
[  181.347769]  task_work_run+0x93/0xc0
[  181.348803]  exit_to_usermode_loop+0x8d/0x90
[  181.350009]  do_syscall_64+0x16b/0x1b0
[  181.351080]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
[  181.352498] RIP: 0033:0x7f5e88e028f0
[  181.353512] RSP: 002b:7fff448399d8 EFLAGS: 0246 ORIG_RAX: 
0003
[  181.355501] RAX:  RBX: 0001 RCX: 7f5e88e028f0
[  181.357382] RDX: 1000 RSI:  RDI: 0001
[  181.359254] RBP: 7f5e892e2698 R08: 0117e000 R09: 7fff448f2080
[  181.361134] R10: 086f R11: 0246 R12: 
[  181.362995] R13:  R14:  R15: 
[  181.365448] show_signal_msg: 12 callbacks suppressed
[  181.365452] dd[2051]: segfault at 7f5e88d78d70 ip 7f5e88d78d70 sp 
7fff44839548 error 14 in libc-2.23.so[7f5e88d0b000+1c]
[  181.369877] BUG: scheduling while atomic: dd/2051/0x0002
[  181.371734] no locks held by dd/2051.
[  181.372658] Modules linked in:
[  181.373503] CPU: 5 PID: 2051 Comm: dd Tainted: GW 
4.16.0-mm1+ #202
[  181.375379] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[  181.377454] Call Trace:
[  181.378055]  dump_stack+0x67/0x9b
[  181.378854]  __schedule_bug+0x5d/0x80
[  181.379731]  __schedule+0x7b5/0xbd0
[  181.380569]  ? find_held_lock+0x2d/0x90
[  181.381503]  ? try_to_wake_up+0x56/0x510
[  181.382437]  ? wait_for_completion+0x112/0x1a0
[  181.383486]  schedule+0x2f/0x90
[  181.384237]  schedule_timeout+0x22b/0x550
[  181.385198]  ? find_held_lock+0x2d/0x90
[  181.386105]  ? wait_for_completion+0x132/0x1a0
[  181.387158]  ? wait_for_completion+0x112/0x1a0
[  181.388221]  wait_for_completion+0x13a/0x1a0
[  181.389236]  ? wake_up_q+0x70/0x70
[  181.390008]  call_usermodehelper_exec+0x13b/0x170
[  181.391067]  do_coredump+0xaed/0x1040
[  181.391893]  ? try_to_wake_up+0x56/0x510
[  181.392815]  ? __lock_is_held+0x55/0x90
[  181.393694]  get_signal+0x32f/0x8e0
[  181.394485]  ? page_fault+0x2f/0x50
[  181.395271]  do_signal+0x36/0x6f0
[  181.396021]  ? force_sig_info_fault+0x97/0xf0
[  181.397018]  ? __bad_area_nosemaphore+0x19e/0x1b0
[  181.398074]  ? __do_page_fault+0xde/0x4b0
[  181.398977]  ? page_fault+0x2f/0x50
[  181.399780]  exit_to_usermode_loop+0x62/0x90
[  181.400770]  prepare_exit_to_usermode+0xbf/0xd0
[  181.401734]  retint_user+0x8/0x18
[  181.402446] RIP: 0033:0x7f5e88d78d70
[  181.403213] RSP: 002b:7fff44839548 EFLAGS: 00010246
[  181.404319] RAX: 7fff4483956f RBX: 7fff44839550 RCX: 007361696c612e65
[  181.405827] RDX:  RSI: 7f5e88e97733 RDI: 7fff44839550
[  181.407245] RBP: 7fff44839790 R08: 656c61636f6c2f65 R09: feff7e5cff372c00
[  181.408920] R10:  R11:  R12: 0117df30
[  181.410817] R13: 7fff44839860 R14: 7fff44839880 R15: 



On Fri, Apr 13, 2018 at 05:48:35PM +0200, Benjamin Warnke wrote:
> This patch series adds a new compression algorithm to the kernel and to
> the crypto api.
> 
> Changes since v6:
> - Fixed git apply error due to other recently applied patches
> 
> Changes since v5:
> - Fixed compile-error due to variable definitions inside #ifdef 
> CONFIG_ZRAM_WRITEBACK
> 
> Changes since v4:
> - Fix mismatching function-prototypes
> - Fix mismatching License errors
> - Add static to global 

Re: [PATCH] drm/sun4i: Add missing frontend compatibles for A10, A13, A20 and A31

[Paul Kocialkowski]

Hi,

On Thu, 2018-04-19 at 17:07 +0200, Maxime Ripard wrote:
> On Thu, Apr 19, 2018 at 02:56:38PM +0200, Paul Kocialkowski wrote:
> > Although frontend nodes are defined in the device-trees of the
> > aforementioned platforms, there are no matching compatibles defined
> > in
> > the driver. This makes it impossible to probe the frontend on these
> > platforms.
> > 
> > Adding the appropriate compatibles to the driver fixes the issue.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/sun4i/sun4i_frontend.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> > b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> > index 85f75046712c..c5a3de11817d 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> > @@ -658,6 +658,10 @@ static const struct dev_pm_ops
> > sun4i_frontend_pm_ops = {
> >  };
> >  
> >  const struct of_device_id sun4i_frontend_of_table[] = {
> > +   { .compatible = "allwinner,sun7i-a10-display-frontend" },
> > +   { .compatible = "allwinner,sun7i-a13-display-frontend" },
> > +   { .compatible = "allwinner,sun7i-a20-display-frontend" },
> > +   { .compatible = "allwinner,sun7i-a31-display-frontend" },
> 
> Most of these compatibles are wrong, so it won't really work :)

Sorry for screwing up so bad...

> If you only tested it on the A20, just add it. We didn't add all of
> them because there's some slight variations between the generations
> that are not yet taken into account.

That makes sense. I will thus send v2 with A20 only and send follow-up
patches for other platforms when tested and properly working.

Thanks!

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek  wrote:
> > Hi!
> >
> >> Thanks.
> >>
> >> Ok, let me try to bisect it. Compile-problem should be easy...
> >>
> >> Hmm. And as it is compile-problem in single file, it should even be
> >> reasonably fast. I did not realize how easy it would be:
> >>
> >> #!/bin/bash
> >> set -e
> >> cp config.ok .config
> >> yes '' | ARCH=arm make lib/string.o
> >>
> >> And the winner is:
> >>
> >> ee333554fed5a986a90bb097ac7f9d6f05bf is the first bad commit
> >> commit ee333554fed5a986a90bb097ac7f9d6f05bf
> >> Author: Jinbum Park 
> >> Date:   Tue Mar 6 01:39:24 2018 +0100
> > ...
> >
> >> Acked-by: Kees Cook 
> >> Signed-off-by: Jinbum Park 
> >> Signed-off-by: Russell King 
> >
> > So I bisect a problem in -next, and patch is merged to Linus,
> > _anyway_, breaking compilation there? Neither Jinbum nor Russell even
> > bother to comment.
> 
> Hi! Sorry I lost this email in my inbox. It seems this is specific to
> a particular subset of arm architectures? (My local builds of arm all
> succeed, for example. Can you send your failing config?) I'll take a
> closer look on Monday if Daniel doesn't beat me to it.

Daniel, Kees: any news?

I'm aware you did not specify which Monday :-).
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

Re: [PATCH v1 4/4] drm/tegra: plane: Add custom CSC BLOB property

[Daniel Vetter]

On Tue, Apr 17, 2018 at 08:31:11PM +0300, Dmitry Osipenko wrote:
> On 17.04.2018 12:01, Daniel Vetter wrote:
> > On Mon, Apr 16, 2018 at 03:16:28PM +0300, Dmitry Osipenko wrote:
> >> This new property allows userspace to apply custom color conversion
> >> coefficients per plane, making possible to utilize display controller
> >> for color adjustments of a video overlay.
> >>
> >> Signed-off-by: Dmitry Osipenko 
> > 
> > Same here, this needs corresponding userspace:
> > 
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> > 
> > And again there's even more people who discussed extending the existing
> > color management support for crtcs to planes. I think we definitely want a
> > standard interface for this, not each driver doing their own thing.
> 
> Could you please point me to where that discussion is happening?

https://patchwork.freedesktop.org/patch/209469/

is one I've found, but I think there's other efforts.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH V3 2/2] ARM: dts: imx6sx-sabreauto: add external 24MHz clock source

[Anson Huang]

On i.MX6SX SabreAuto board, there is external 24MHz clock
source for analog clock2, add this clock source to clock tree
and remove "clocks" container for all input clocks.

Signed-off-by: Anson Huang 
---
changes since V2:
remove "clocks" container and use new way for all input clocks 
definition.
 arch/arm/boot/dts/imx6sx-sabreauto.dts |  4 ++
 arch/arm/boot/dts/imx6sx.dtsi  | 71 ++
 2 files changed, 42 insertions(+), 33 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts 
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 72da5ac..57d1ea0 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -37,6 +37,10 @@
};
 };
 
+ {
+   clock-frequency = <24576000>;
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_uart1>;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 49c7205..7e463d2 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -104,41 +104,46 @@
interrupt-parent = <>;
};
 
-   clocks {
-   #address-cells = <1>;
-   #size-cells = <0>;
+   ckil: clock-ckil {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "ckil";
+   };
 
-   ckil: clock@0 {
-   compatible = "fixed-clock";
-   reg = <0>;
-   #clock-cells = <0>;
-   clock-frequency = <32768>;
-   clock-output-names = "ckil";
-   };
+   osc: clock-osc {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2400>;
+   clock-output-names = "osc";
+   };
 
-   osc: clock@1 {
-   compatible = "fixed-clock";
-   reg = <1>;
-   #clock-cells = <0>;
-   clock-frequency = <2400>;
-   clock-output-names = "osc";
-   };
+   ipp_di0: clock-ipp-di0 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   clock-output-names = "ipp_di0";
+   };
 
-   ipp_di0: clock@2 {
-   compatible = "fixed-clock";
-   reg = <2>;
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   clock-output-names = "ipp_di0";
-   };
+   ipp_di1: clock-ipp-di1 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   clock-output-names = "ipp_di1";
+   };
 
-   ipp_di1: clock@3 {
-   compatible = "fixed-clock";
-   reg = <3>;
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   clock-output-names = "ipp_di1";
-   };
+   anaclk1: clock-anaclk1 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   clock-output-names = "anaclk1";
+   };
+
+   anaclk2: clock-anaclk2 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   clock-output-names = "anaclk2";
};
 
tempmon: tempmon {
@@ -575,8 +580,8 @@
interrupts = ,
 ;
#clock-cells = <1>;
-   clocks = <>, <>, <_di0>, 
<_di1>;
-   clock-names = "ckil", "osc", "ipp_di0", 
"ipp_di1";
+   clocks = <>, <>, <_di0>, 
<_di1>, <>, <>;
+   clock-names = "ckil", "osc", "ipp_di0", 
"ipp_di1", "anaclk1", "anaclk2";
};
 
anatop: anatop@20c8000 {
-- 
2.7.4

Re: [RFC 0/2] dw_mmc: add multislot support

[Alexey Brodkin]

Hi Ulf,

On Fri, 2018-04-20 at 09:35 +0200, Ulf Hansson wrote:
> [...]
> 
> > 
> > 2. Add missing stuff to support multislot mode in DesignWare MMC driver.
> >  * Add missing slot switch to __dw_mci_start_request() function.
> >  * Refactor set_ios function:
> >a) Calculate common clock which is
> >   suitable for all slots instead of directly use clock value
> >   provided by mmc core. We calculate common clock as the minimum
> >   among each used slot clocks. This clock is calculated in
> >   dw_mci_calc_common_clock() function which is called
> >   from set_ios()
> >b) Disable clock only if no other slots are ON.
> >c) Setup clock directly in set_ios() only if no other slots
> >   are ON. Otherwise adjust clock in __dw_mci_start_request()
> >   function before slot switch.
> >d) Move timings and bus_width setup to separate funcions.
> >  * Use timing field in each slot structure instead of common field in
> >host structure.
> >  * Add locks to serialize access to registers.
> 
> Sorry, but this is a hack to *try* to make multi-slot work and this
> isn't sufficient. There were good reasons to why the earlier
> non-working multi slot support was removed from dw_mmc.
> 
> Let me elaborate a bit for your understanding. The core uses a host
> lock (mmc_claim|release_host()) to serialize operations and commands,
> as to confirm to the SD/SDIO/(e)MMC specs. The above changes gives no
> guarantees for this. To make that work, we would need a "mmc bus lock"
> to be managed by the core.
> 
> However, inventing a "mmc bus lock" would lead to other problems
> related to I/O scheduling for upper layers - it simply breaks. For
> example, I/O requests for one card/slot can then starve I/O requests
> reaching another card/slot.

So are you saying that multi-slot support is a no go in general or it is only
applicable to DW MMC (I really doubt that's a case)?

BTW there're other controllers that seem to support multi-slot like Atmel etc.

-Alexey

[PATCH V3 1/2] clk: imx6sx: add missing lvds2 clock to the clock tree

[Anson Huang]

i.MX6SX has lvds2 (analog clock2), an I/O clock like lvds1.
And this lvds2, along with lvds1, can be used to provide
external clock source to the internal pll, such as pll4_audio
and pll5_video.

This patch mainly adds the lvds2 to the clock tree and fix its
relationship with pll accordingly.

Signed-off-by: Anson Huang 
Signed-off-by: Shengjiu Wang 
Reviewed-by: Rob Herring 
---
changes since V2:
use of_clk_get_by_name instead of imx_obtain_fixed_clock for anaclkX 
node.
 drivers/clk/imx/clk-imx6sx.c | 10 +++---
 include/dt-bindings/clock/imx6sx-clock.h |  6 +-
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index bc3f9eb..0178ee2 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -80,7 +80,7 @@ static const char *lvds_sels[]= {
"arm", "pll1_sys", "dummy", "dummy", "dummy", "dummy", "dummy", 
"pll5_video_div",
"dummy", "dummy", "pcie_ref_125m", "dummy", "usbphy1", "usbphy2",
 };
-static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", };
+static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", "lvds2_in", 
"dummy", };
 static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src", };
 static const char *pll2_bypass_sels[] = { "pll2", "pll2_bypass_src", };
 static const char *pll3_bypass_sels[] = { "pll3", "pll3_bypass_src", };
@@ -158,8 +158,9 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_IPP_DI0] = of_clk_get_by_name(ccm_node, "ipp_di0");
clks[IMX6SX_CLK_IPP_DI1] = of_clk_get_by_name(ccm_node, "ipp_di1");
 
-   /* Clock source from external clock via CLK1 PAD */
-   clks[IMX6SX_CLK_ANACLK1] = imx_obtain_fixed_clock("anaclk1", 0);
+   /* Clock source from external clock via CLK1/2 PAD */
+   clks[IMX6SX_CLK_ANACLK1] = of_clk_get_by_name(ccm_node, "anaclk1");
+   clks[IMX6SX_CLK_ANACLK2] = of_clk_get_by_name(ccm_node, "anaclk2");
 
np = of_find_compatible_node(NULL, NULL, "fsl,imx6sx-anatop");
base = of_iomap(np, 0);
@@ -228,7 +229,9 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_PCIE_REF_125M] = imx_clk_gate("pcie_ref_125m", 
"pcie_ref", base + 0xe0, 19);
 
clks[IMX6SX_CLK_LVDS1_OUT] = imx_clk_gate_exclusive("lvds1_out", 
"lvds1_sel", base + 0x160, 10, BIT(12));
+   clks[IMX6SX_CLK_LVDS2_OUT] = imx_clk_gate_exclusive("lvds2_out", 
"lvds2_sel", base + 0x160, 11, BIT(13));
clks[IMX6SX_CLK_LVDS1_IN]  = imx_clk_gate_exclusive("lvds1_in",  
"anaclk1",   base + 0x160, 12, BIT(10));
+   clks[IMX6SX_CLK_LVDS2_IN]  = imx_clk_gate_exclusive("lvds2_in",  
"anaclk2",   base + 0x160, 13, BIT(11));
 
clks[IMX6SX_CLK_ENET_REF] = clk_register_divider_table(NULL, 
"enet_ref", "pll6_enet", 0,
base + 0xe0, 0, 2, 0, clk_enet_ref_table,
@@ -270,6 +273,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
 
/*name
reg   shift   width   parent_names   num_parents */
clks[IMX6SX_CLK_LVDS1_SEL]  = imx_clk_mux("lvds1_sel",
base + 0x160, 0,  5,  lvds_sels, ARRAY_SIZE(lvds_sels));
+   clks[IMX6SX_CLK_LVDS2_SEL]  = imx_clk_mux("lvds2_sel",
base + 0x160, 5,  5,  lvds_sels, ARRAY_SIZE(lvds_sels));
 
np = ccm_node;
base = of_iomap(np, 0);
diff --git a/include/dt-bindings/clock/imx6sx-clock.h 
b/include/dt-bindings/clock/imx6sx-clock.h
index 36f0324..cd2d6c5 100644
--- a/include/dt-bindings/clock/imx6sx-clock.h
+++ b/include/dt-bindings/clock/imx6sx-clock.h
@@ -275,6 +275,10 @@
 #define IMX6SX_PLL6_BYPASS 262
 #define IMX6SX_PLL7_BYPASS 263
 #define IMX6SX_CLK_SPDIF_GCLK  264
-#define IMX6SX_CLK_CLK_END 265
+#define IMX6SX_CLK_LVDS2_SEL   265
+#define IMX6SX_CLK_LVDS2_OUT   266
+#define IMX6SX_CLK_LVDS2_IN267
+#define IMX6SX_CLK_ANACLK2 268
+#define IMX6SX_CLK_CLK_END 269
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6SX_H */
-- 
2.7.4

Re: [PATCH v3 04/17] y2038: s390: Remove unneeded ipc uapi header files

[Heiko Carstens]

On Thu, Apr 19, 2018 at 04:37:24PM +0200, Arnd Bergmann wrote:
> The s390 msgbuf/sembuf/shmbuf header files are all identical to the
> version from asm-generic.
> 
> This patch removes the files and replaces them with 'generic-y'
> statements, to avoid having to modify each copy when we extend sysvipc
> to deal with 64-bit time_t in 32-bit user space.
> 
> Note that unlike alpha and ia64, the ipcbuf.h header file is slightly
> different here, so I'm leaving the private copy.
> 
> To deal with 32-bit compat tasks, we also have to adapt the definitions
> of compat_{shm,sem,msg}id_ds to match the changes to the respective
> asm-generic files.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  arch/s390/include/asm/compat.h  | 32 
>  arch/s390/include/uapi/asm/Kbuild   |  3 +++
>  arch/s390/include/uapi/asm/msgbuf.h | 38 
>  arch/s390/include/uapi/asm/sembuf.h | 30 ---
>  arch/s390/include/uapi/asm/shmbuf.h | 49 
> -
>  5 files changed, 19 insertions(+), 133 deletions(-)
>  delete mode 100644 arch/s390/include/uapi/asm/msgbuf.h
>  delete mode 100644 arch/s390/include/uapi/asm/sembuf.h
>  delete mode 100644 arch/s390/include/uapi/asm/shmbuf.h

FWIW,

Acked-by: Heiko Carstens 

[PATCH 01/22] dma-debug: move initialization to common code

[Christoph Hellwig]

Most mainstream architectures are using 65536 entries, so lets stick to
that.  If someone is really desperate to override it that can still be
done through , but I'd rather see a really good
rationale for that.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/mm/dma-mapping-nommu.c |  9 -
 arch/arm/mm/dma-mapping.c   |  9 -
 arch/arm64/mm/dma-mapping.c | 10 --
 arch/c6x/kernel/dma.c   | 11 ---
 arch/ia64/kernel/dma-mapping.c  | 10 --
 arch/microblaze/kernel/dma.c| 11 ---
 arch/mips/mm/dma-default.c  | 10 --
 arch/openrisc/kernel/dma.c  | 11 ---
 arch/powerpc/kernel/dma.c   |  3 ---
 arch/s390/pci/pci_dma.c |  9 -
 arch/sh/mm/consistent.c |  9 -
 arch/sparc/kernel/Makefile  |  2 --
 arch/sparc/kernel/dma.c | 13 -
 arch/x86/kernel/pci-dma.c   |  4 
 arch/xtensa/kernel/pci-dma.c|  9 -
 include/linux/dma-debug.h   |  6 --
 lib/dma-debug.c | 21 ++---
 17 files changed, 14 insertions(+), 143 deletions(-)
 delete mode 100644 arch/sparc/kernel/dma.c

diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index 619f24a42d09..f448a0663b10 100644
--- a/arch/arm/mm/dma-mapping-nommu.c
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -241,12 +241,3 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, 
u64 size,
 void arch_teardown_dma_ops(struct device *dev)
 {
 }
-
-#define PREALLOC_DMA_DEBUG_ENTRIES 4096
-
-static int __init dma_debug_do_init(void)
-{
-   dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
-   return 0;
-}
-core_initcall(dma_debug_do_init);
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 8c398fedbbb6..c26bf83f44ca 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1165,15 +1165,6 @@ int arm_dma_supported(struct device *dev, u64 mask)
return __dma_supported(dev, mask, false);
 }
 
-#define PREALLOC_DMA_DEBUG_ENTRIES 4096
-
-static int __init dma_debug_do_init(void)
-{
-   dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
-   return 0;
-}
-core_initcall(dma_debug_do_init);
-
 #ifdef CONFIG_ARM_DMA_USE_IOMMU
 
 static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index a96ec0181818..db01f2709842 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -508,16 +508,6 @@ static int __init arm64_dma_init(void)
 }
 arch_initcall(arm64_dma_init);
 
-#define PREALLOC_DMA_DEBUG_ENTRIES 4096
-
-static int __init dma_debug_do_init(void)
-{
-   dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
-   return 0;
-}
-fs_initcall(dma_debug_do_init);
-
-
 #ifdef CONFIG_IOMMU_DMA
 #include 
 #include 
diff --git a/arch/c6x/kernel/dma.c b/arch/c6x/kernel/dma.c
index 9fff8be75f58..31e1a9ec3a9c 100644
--- a/arch/c6x/kernel/dma.c
+++ b/arch/c6x/kernel/dma.c
@@ -136,14 +136,3 @@ const struct dma_map_ops c6x_dma_ops = {
.sync_sg_for_cpu= c6x_dma_sync_sg_for_cpu,
 };
 EXPORT_SYMBOL(c6x_dma_ops);
-
-/* Number of entries preallocated for DMA-API debugging */
-#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
-
-static int __init dma_init(void)
-{
-   dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
-
-   return 0;
-}
-fs_initcall(dma_init);
diff --git a/arch/ia64/kernel/dma-mapping.c b/arch/ia64/kernel/dma-mapping.c
index f2d57e66fd86..7a471d8d67d4 100644
--- a/arch/ia64/kernel/dma-mapping.c
+++ b/arch/ia64/kernel/dma-mapping.c
@@ -9,16 +9,6 @@ int iommu_detected __read_mostly;
 const struct dma_map_ops *dma_ops;
 EXPORT_SYMBOL(dma_ops);
 
-#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
-
-static int __init dma_init(void)
-{
-   dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
-
-   return 0;
-}
-fs_initcall(dma_init);
-
 const struct dma_map_ops *dma_get_ops(struct device *dev)
 {
return dma_ops;
diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
index c91e8cef98dd..3145e7dc8ab1 100644
--- a/arch/microblaze/kernel/dma.c
+++ b/arch/microblaze/kernel/dma.c
@@ -184,14 +184,3 @@ const struct dma_map_ops dma_nommu_ops = {
.sync_sg_for_device = dma_nommu_sync_sg_for_device,
 };
 EXPORT_SYMBOL(dma_nommu_ops);
-
-/* Number of entries preallocated for DMA-API debugging */
-#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
-
-static int __init dma_init(void)
-{
-   dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
-
-   return 0;
-}
-fs_initcall(dma_init);
diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index dcafa43613b6..f9fef0028ca2 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -402,13 +402,3 @@ static const struct dma_map_ops mips_default_dma_map_ops = 
{
 
 const struct dma_map_ops *mips_dma_map_ops = _default_dma_map_ops;
 EXPORT_SYMBOL(mips_dma_map_ops);
-
-#define PREALLOC_DMA_DEBUG_ENTRIES (1 

[PATCH 02/22] dma-mapping: simplify Kconfig dependencies

[Christoph Hellwig]

ARCH_DMA_ADDR_T_64BIT is always true for 64-bit architectures now, so we
can skip the clause requiring it.  'n' is the default default, so no need
to explicitly state it.

Signed-off-by: Christoph Hellwig 
---
 lib/Kconfig | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index 01a37920949c..726b0562caa7 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -443,13 +443,11 @@ config IOMMU_HELPER
 
 config DMA_DIRECT_OPS
bool
-   depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
-   default n
+   depends on HAS_DMA
 
 config DMA_VIRT_OPS
bool
-   depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
-   default n
+   depends on HAS_DMA
 
 config ARCH_HAS_SWIOTLB
bool
-- 
2.17.0

[no subject]

[Christoph Hellwig]

To: io...@lists.linux-foundation.org
Cc: linux-a...@vger.kernel.org
Cc: Michal Simek 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: linux-al...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c6x-...@linux-c6x.org
Cc: linux-hexa...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: nios2-...@lists.rocketboards.org
Cc: openr...@lists.librecores.org
Cc: linux-par...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-xte...@linux-xtensa.org
Cc: linux-kernel@vger.kernel.org
Subject: [RFC] common non-cache coherent direct dma mapping ops

Hi all,

this series continues consolidating the dma-mapping code, with a focus
on architectures that do not (always) provide cache coherence for DMA.
Three architectures (arm, mips and powerpc) are still left to be
converted later due to complexity of their dma ops selection.

The dma-noncoherent ops calls the dma-direct ops for the actual
translation of streaming mappins and allow the architecture to provide
any cache flushing required for cpu to device and/or device to cpu
ownership transfers.  The dma coherent allocator is for now still left
entirely to architecture supplied implementations due the amount of
variations.  Hopefully we can do some consolidation for them later on
as well.

A lot of architectures are currently doing very questionable things
in their dma mapping routines, which are documented in the changelogs
for each patch.  Please review them very careful and correct me on
incorrect assumptions.

Because this series sits on top of two previously submitted series
a git tree might be useful to actually test it.  It is provided here:

git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent

Gitweb:


http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

[Michal Hocko]

On Fri 20-04-18 14:42:39, Minchan Kim wrote:
[...]
> When I see replies of this thread, it's arguble to add such one-line
> warn so if you want it strongly, could you handle by yourself?

I do not feel strongly about it to argue as well. So the patch Andrew
added with a better explanation is sufficient from my POV.
-- 
Michal Hocko
SUSE Labs

[PATCH 15/22] openrisc: use generic dma_noncoherent_ops

[Christoph Hellwig]

Switch to the generic noncoherent direct mapping implementation.

Fix sync_single_for_device to do the same cache coherency operations as
the more tested map_single path, as both should transfer ownership to
the device.

Remove the sync_single_for_cpu implementation as no cache coherency
operations are used in the more commonly used unmap_single case, both
of which transfer ownership to the CPU.

Implement the missing sync_sg_for_device operation, matching the cache
coherency operations in sync_single_for_device and map_{single,sg}.

Signed-off-by: Christoph Hellwig 
---
 arch/openrisc/Kconfig   |   2 +
 arch/openrisc/include/asm/Kbuild|   1 +
 arch/openrisc/include/asm/dma-mapping.h |  35 
 arch/openrisc/kernel/dma.c  | 109 +++-
 4 files changed, 13 insertions(+), 134 deletions(-)
 delete mode 100644 arch/openrisc/include/asm/dma-mapping.h

diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 9ecad05bfc73..65e3c574c9d3 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -6,6 +6,8 @@
 
 config OPENRISC
def_bool y
+   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
+   select DMA_NONCOHERENT_OPS
select OF
select OF_EARLY_FLATTREE
select IRQ_DOMAIN
diff --git a/arch/openrisc/include/asm/Kbuild b/arch/openrisc/include/asm/Kbuild
index f05c722a21f8..e663a996b612 100644
--- a/arch/openrisc/include/asm/Kbuild
+++ b/arch/openrisc/include/asm/Kbuild
@@ -6,6 +6,7 @@ generic-y += current.h
 generic-y += device.h
 generic-y += div64.h
 generic-y += dma.h
+generic-y += dma-mapping.h
 generic-y += emergency-restart.h
 generic-y += exec.h
 generic-y += extable.h
diff --git a/arch/openrisc/include/asm/dma-mapping.h 
b/arch/openrisc/include/asm/dma-mapping.h
deleted file mode 100644
index e212a1f0b6d2..
--- a/arch/openrisc/include/asm/dma-mapping.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * OpenRISC Linux
- *
- * Linux architectural port borrowing liberally from similar works of
- * others.  All original copyrights apply as per the original source
- * declaration.
- *
- * OpenRISC implementation:
- * Copyright (C) 2010-2011 Jonas Bonn 
- *
- * 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.
- */
-
-#ifndef __ASM_OPENRISC_DMA_MAPPING_H
-#define __ASM_OPENRISC_DMA_MAPPING_H
-
-/*
- * See Documentation/DMA-API-HOWTO.txt and
- * Documentation/DMA-API.txt for documentation.
- */
-
-#include 
-#include 
-
-extern const struct dma_map_ops or1k_dma_map_ops;
-
-static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
-{
-   return _dma_map_ops;
-}
-
-#endif /* __ASM_OPENRISC_DMA_MAPPING_H */
diff --git a/arch/openrisc/kernel/dma.c b/arch/openrisc/kernel/dma.c
index ec7fd45704d2..cce99405edf4 100644
--- a/arch/openrisc/kernel/dma.c
+++ b/arch/openrisc/kernel/dma.c
@@ -19,9 +19,7 @@
  * the only thing implemented properly.  The rest need looking into...
  */
 
-#include 
-#include 
-#include 
+#include 
 
 #include 
 #include 
@@ -80,10 +78,9 @@ page_clear_nocache(pte_t *pte, unsigned long addr,
  * is being ignored for now; uncached but write-combined memory is a
  * missing feature of the OR1K.
  */
-static void *
-or1k_dma_alloc(struct device *dev, size_t size,
-  dma_addr_t *dma_handle, gfp_t gfp,
-  unsigned long attrs)
+void *
+arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
+   gfp_t gfp, unsigned long attrs)
 {
unsigned long va;
void *page;
@@ -115,9 +112,9 @@ or1k_dma_alloc(struct device *dev, size_t size,
return (void *)va;
 }
 
-static void
-or1k_dma_free(struct device *dev, size_t size, void *vaddr,
- dma_addr_t dma_handle, unsigned long attrs)
+void
+arch_dma_free(struct device *dev, size_t size, void *vaddr,
+   dma_addr_t dma_handle, unsigned long attrs)
 {
unsigned long va = (unsigned long)vaddr;
struct mm_walk walk = {
@@ -133,18 +130,11 @@ or1k_dma_free(struct device *dev, size_t size, void 
*vaddr,
free_pages_exact(vaddr, size);
 }
 
-static dma_addr_t
-or1k_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size,
- enum dma_data_direction dir,
- unsigned long attrs)
+void arch_sync_dma_for_device(struct device *dev, phys_addr_t addr, size_t 
size,
+   enum dma_data_direction dir)
 {
-   unsigned long cl;
-   dma_addr_t addr = page_to_phys(page) + offset;
struct cpuinfo_or1k *cpuinfo = _or1k[smp_processor_id()];
-
-   if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
-   return addr;
+   unsigned long cl;
 
switch (dir) {
case DMA_TO_DEVICE:
@@ -167,83 +157,4 @@ or1k_map_page(struct device 

[PATCH 13/22] nds32: use generic dma_noncoherent_ops

[Christoph Hellwig]

Switch to the generic noncoherent direct mapping implementation.

This makes sure kmap_atomic_pfn is consistently used for access to
virtual addresses instead of either using the slower plain kmap
or blindly expecting page_address() to work.

This makes sure the cache_sync routines is called in the unmap_sg
case, to match the unmap_single and sync_{single,sg}_to_cpu cases.

Signed-off-by: Christoph Hellwig 
---
 arch/nds32/Kconfig   |   3 +
 arch/nds32/include/asm/Kbuild|   1 +
 arch/nds32/include/asm/dma-mapping.h |  14 ---
 arch/nds32/kernel/dma.c  | 182 ++-
 4 files changed, 39 insertions(+), 161 deletions(-)
 delete mode 100644 arch/nds32/include/asm/dma-mapping.h

diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
index 249f38d3388f..67d0ac0a989c 100644
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@ -5,10 +5,13 @@
 
 config NDS32
 def_bool y
+   select ARCH_HAS_SYNC_DMA_FOR_CPU
+   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_WANT_FRAME_POINTERS if FTRACE
select CLKSRC_MMIO
select CLONE_BACKWARDS
select COMMON_CLK
+   select DMA_NONCOHERENT_OPS
select GENERIC_ATOMIC64
select GENERIC_CPU_DEVICES
select GENERIC_CLOCKEVENTS
diff --git a/arch/nds32/include/asm/Kbuild b/arch/nds32/include/asm/Kbuild
index 06bdf8167f5a..b3e951f805f8 100644
--- a/arch/nds32/include/asm/Kbuild
+++ b/arch/nds32/include/asm/Kbuild
@@ -13,6 +13,7 @@ generic-y += cputime.h
 generic-y += device.h
 generic-y += div64.h
 generic-y += dma.h
+generic-y += dma-mapping.h
 generic-y += emergency-restart.h
 generic-y += errno.h
 generic-y += exec.h
diff --git a/arch/nds32/include/asm/dma-mapping.h 
b/arch/nds32/include/asm/dma-mapping.h
deleted file mode 100644
index 2dd47d245c25..
--- a/arch/nds32/include/asm/dma-mapping.h
+++ /dev/null
@@ -1,14 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-// Copyright (C) 2005-2017 Andes Technology Corporation
-
-#ifndef ASMNDS32_DMA_MAPPING_H
-#define ASMNDS32_DMA_MAPPING_H
-
-extern struct dma_map_ops nds32_dma_ops;
-
-static inline struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
-{
-   return _dma_ops;
-}
-
-#endif
diff --git a/arch/nds32/kernel/dma.c b/arch/nds32/kernel/dma.c
index d291800fc621..688f1a03dee6 100644
--- a/arch/nds32/kernel/dma.c
+++ b/arch/nds32/kernel/dma.c
@@ -3,17 +3,14 @@
 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /*
@@ -22,11 +19,6 @@
 static pte_t *consistent_pte;
 static DEFINE_RAW_SPINLOCK(consistent_lock);
 
-enum master_type {
-   FOR_CPU = 0,
-   FOR_DEVICE = 1,
-};
-
 /*
  * VM region handling support.
  *
@@ -124,10 +116,8 @@ static struct arch_vm_region *vm_region_find(struct 
arch_vm_region *head,
return c;
 }
 
-/* FIXME: attrs is not used. */
-static void *nds32_dma_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t * handle, gfp_t gfp,
- unsigned long attrs)
+void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
+   gfp_t gfp, unsigned long attrs)
 {
struct page *page;
struct arch_vm_region *c;
@@ -232,8 +222,8 @@ static void *nds32_dma_alloc_coherent(struct device *dev, 
size_t size,
return NULL;
 }
 
-static void nds32_dma_free(struct device *dev, size_t size, void *cpu_addr,
-  dma_addr_t handle, unsigned long attrs)
+void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
+   dma_addr_t handle, unsigned long attrs)
 {
struct arch_vm_region *c;
unsigned long flags, addr;
@@ -333,145 +323,43 @@ static int __init consistent_init(void)
 }
 
 core_initcall(consistent_init);
-static void consistent_sync(void *vaddr, size_t size, int direction, int 
master_type);
-static dma_addr_t nds32_dma_map_page(struct device *dev, struct page *page,
-unsigned long offset, size_t size,
-enum dma_data_direction dir,
-unsigned long attrs)
-{
-   if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
-   consistent_sync((void *)(page_address(page) + offset), size, 
dir, FOR_DEVICE);
-   return page_to_phys(page) + offset;
-}
-
-static void nds32_dma_unmap_page(struct device *dev, dma_addr_t handle,
-size_t size, enum dma_data_direction dir,
-unsigned long attrs)
-{
-   if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
-   consistent_sync(phys_to_virt(handle), size, dir, FOR_CPU);
-}
 
-/*
- * Make an area consistent for devices.
- */
-static void consistent_sync(void *vaddr, size_t size, int direction, int 
master_type)
+void arch_sync_dma_for_device(struct device *dev, phys_addr_t 

[PATCH 17/22] sh: introduce a sh_cacheop_vaddr helper

[Christoph Hellwig]

And use it in the maple bus code to avoid a dma API dependency.

Signed-off-by: Christoph Hellwig 
---
 arch/sh/include/asm/cacheflush.h | 7 +++
 arch/sh/mm/consistent.c  | 5 +
 drivers/sh/maple/maple.c | 7 ---
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/sh/include/asm/cacheflush.h b/arch/sh/include/asm/cacheflush.h
index d103ab5a4e4b..b932e42ef028 100644
--- a/arch/sh/include/asm/cacheflush.h
+++ b/arch/sh/include/asm/cacheflush.h
@@ -101,5 +101,12 @@ void kunmap_coherent(void *kvaddr);
 
 void cpu_cache_init(void);
 
+static inline void *sh_cacheop_vaddr(void *vaddr)
+{
+   if (__in_29bit_mode())
+   vaddr = (void *)CAC_ADDR((unsigned long)vaddr);
+   return vaddr;
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_SH_CACHEFLUSH_H */
diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index af2f28572119..516d481525e1 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c
@@ -69,10 +69,7 @@ void dma_generic_free_coherent(struct device *dev, size_t 
size,
 void sh_sync_dma_for_device(void *vaddr, size_t size,
enum dma_data_direction direction)
 {
-   void *addr;
-
-   addr = __in_29bit_mode() ?
-  (void *)CAC_ADDR((unsigned long)vaddr) : vaddr;
+   void *addr = sh_cacheop_vaddr(vaddr);
 
switch (direction) {
case DMA_FROM_DEVICE:   /* invalidate only */
diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
index 7525039d812c..c9c354bd713a 100644
--- a/drivers/sh/maple/maple.c
+++ b/drivers/sh/maple/maple.c
@@ -300,8 +300,8 @@ static void maple_send(void)
mutex_unlock(_wlist_lock);
if (maple_packets > 0) {
for (i = 0; i < (1 << MAPLE_DMA_PAGES); i++)
-   sh_sync_dma_for_device(maple_sendbuf + i * PAGE_SIZE,
-  PAGE_SIZE, DMA_BIDIRECTIONAL);
+   __flush_purge_region(maple_sendbuf + i * PAGE_SIZE,
+   PAGE_SIZE);
}
 
 finish:
@@ -642,7 +642,8 @@ static void maple_dma_handler(struct work_struct *work)
list_for_each_entry_safe(mq, nmq, _sentq, list) {
mdev = mq->dev;
recvbuf = mq->recvbuf->buf;
-   sh_sync_dma_for_device(recvbuf, 0x400, DMA_FROM_DEVICE);
+   __flush_invalidate_region(sh_cacheop_vaddr(recvbuf),
+   0x400);
code = recvbuf[0];
kfree(mq->sendbuf);
list_del_init(>list);
-- 
2.17.0

Re: [PATCH] tty: Fix data race in tty_insert_flip_string_fixed_flag()

[Greg KH]

On Fri, Apr 20, 2018 at 04:40:56PM +0900, daelyong jeong wrote:
> tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated
> by th->used and updates tb->used.
> But it is possible that tty_insert_flip_string_fixed_flag() is executed
> concurrently and tb->used is updated improperly.
> It leads slab-out-of-bound write in tty_insert_flip_string_fixed_flag or
> slab-out-of-bounds read in flush_to_ldisc.
> 
> BUG: KASAN: slab-out-of-bounds in
> tty_insert_flip_string_fixed_flag+0xb5/0x130
> drivers/tty/tty_buffer.c:316 at addr 880114fcc121
> Write of size 1792 by task syz-executor0/30017
> CPU: 1 PID: 30017 Comm: syz-executor0 Not tainted 4.8.0 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
>   88011638f888 81694cc3 88007d802140
>  880114fcb300 880114fcc300 880114fcb300 88011638f8b0
>  8130075c 88011638f940 88007d802140 880194fcc121
> Call Trace:
>  [] __dump_stack lib/dump_stack.c:15 [inline]
>  [] dump_stack+0xb3/0x110 lib/dump_stack.c:51
>  [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
>  [] print_address_description mm/kasan/report.c:194 [inline]
>  [] kasan_report_error+0x1f7/0x4e0 mm/kasan/report.c:283
>  [] kasan_report+0x36/0x40 mm/kasan/report.c:303
>  [] check_memory_region_inline mm/kasan/kasan.c:292 [inline]
>  [] check_memory_region+0x13e/0x1a0 mm/kasan/kasan.c:299
>  [] memcpy+0x37/0x50 mm/kasan/kasan.c:335
>  [] tty_insert_flip_string_fixed_flag+0xb5/0x130
> drivers/tty/tty_buffer.c:316
>  [] tty_insert_flip_string
> include/linux/tty_flip.h:35 [inline]
>  [] pty_write+0x7f/0xc0 drivers/tty/pty.c:115
>  [] n_hdlc_send_frames+0x1d4/0x3b0 drivers/tty/n_hdlc.c:419
>  [] n_hdlc_tty_wakeup+0x73/0xa0 drivers/tty/n_hdlc.c:496
>  [] tty_wakeup+0x92/0xb0 drivers/tty/tty_io.c:601
>  [] __start_tty.part.26+0x66/0x70 drivers/tty/tty_io.c:1018
>  [] __start_tty+0x34/0x40 drivers/tty/tty_io.c:1013
>  [] n_tty_ioctl_helper+0x146/0x1e0
> drivers/tty/tty_ioctl.c:1138
>  [] n_hdlc_tty_ioctl+0xb3/0x2b0 drivers/tty/n_hdlc.c:794
>  [] tty_ioctl+0xa85/0x16d0 drivers/tty/tty_io.c:2992
>  [] vfs_ioctl fs/ioctl.c:43 [inline]
>  [] do_vfs_ioctl+0x13e/0xba0 fs/ioctl.c:679
>  [] SYSC_ioctl fs/ioctl.c:694 [inline]
>  [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
>  [] entry_SYSCALL_64_fastpath+0x1f/0xbd
> 
> Call sequences are as follows.
> CPU0CPU1
> n_tty_ioctl_helper  n_tty_ioctl_helper
> __start_tty tty_send_xchar
> tty_wakeup  pty_write
> n_hdlc_tty_wakeup   tty_insert_flip_string
> n_hdlc_send_frames  tty_insert_flip_string_fixed_flag
> pty_write
> tty_insert_flip_string
> tty_insert_flip_string_fixed_flag
> 
> Acquire tty->atomic_write_lock by calling tty_write_lock() before
> __start_tty() since __start_tty() can sends frames.
> 
> Signed-off-by: Daelyong Jeong 
> ---
> Rationale:
> - Since tty_wakeup() called by __start_tty() sends frames, call
>   tty_write_lock() before __start_tty().
> - Since tty_write_lock() might sleep, locate tty_write_lock() before
>   spin_lock_irq(>flow_lock).
> - Since wake_up_interruptible_poll() is called by both tty_write_unlock()
>   and __start_tty(), Prevent calling wake_up_interruptible_poll() twice
>   by adding the wakeup flag to tty_write_unlock()
> 
> ---
>  drivers/tty/tty_io.c| 16 +---
>  drivers/tty/tty_ioctl.c |  5 +
>  include/linux/tty.h |  2 ++
>  3 files changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 63114ea..41f83bd 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -873,13 +873,15 @@ static ssize_t tty_read(struct file *file, char
> __user *buf, size_t count,
>   return i;
>  }
> 
> -static void tty_write_unlock(struct tty_struct *tty)
> +void tty_write_unlock(struct tty_struct *tty, int wakeup)
>  {
>   mutex_unlock(>atomic_write_lock);
> - wake_up_interruptible_poll(>write_wait, EPOLLOUT);
> + if (wakeup) {
> + wake_up_interruptible_poll(>write_wait, EPOLLOUT);
> + }
>  }

Patch is still totally corrupted :(

Please read the kernel documentation for how to handle broken email
clients (like gmail), and send the patch to yourself first to verify
that it works before sending it out to everyone else.

thanks,

greg k-h

Re: [RFC PATCH v2 3/6] sched: Add over-utilization/tipping point indicator

[Joel Fernandes]

On Fri, Apr 20, 2018 at 1:13 AM, Joel Fernandes  wrote:
> On Wed, Apr 18, 2018 at 4:17 AM, Quentin Perret  
> wrote:
>> On Friday 13 Apr 2018 at 16:56:39 (-0700), Joel Fernandes wrote:
>>> Hi,
>>>
>>> On Fri, Apr 6, 2018 at 8:36 AM, Dietmar Eggemann
>>>  wrote:
>>> > From: Thara Gopinath 
>>> >
>>> > Energy-aware scheduling should only operate when the system is not
>>> > overutilized. There must be cpu time available to place tasks based on
>>> > utilization in an energy-aware fashion, i.e. to pack tasks on
>>> > energy-efficient cpus without harming the overall throughput.
>>> >
>>> > In case the system operates above this tipping point the tasks have to
>>> > be placed based on task and cpu load in the classical way of spreading
>>> > tasks across as many cpus as possible.
>>> >
>>> > The point in which a system switches from being not overutilized to
>>> > being overutilized is called the tipping point.
>>> >
>>> > Such a tipping point indicator on a sched domain as the system
>>> > boundary is introduced here. As soon as one cpu of a sched domain is
>>> > overutilized the whole sched domain is declared overutilized as well.
>>> > A cpu becomes overutilized when its utilization is higher that 80%
>>> > (capacity_margin) of its capacity.
>>> >
>>> > The implementation takes advantage of the shared sched domain which is
>>> > shared across all per-cpu views of a sched domain level. The new
>>> > overutilized flag is placed in this shared sched domain.
>>> >
>>> > Load balancing is skipped in case the energy model is present and the
>>> > sched domain is not overutilized because under this condition the
>>> > predominantly load-per-capacity driven load-balancer should not
>>> > interfere with the energy-aware wakeup placement based on utilization.
>>> >
>>> > In case the total utilization of a sched domain is greater than the
>>> > total sched domain capacity the overutilized flag is set at the parent
>>> > sched domain level to let other sched groups help getting rid of the
>>> > overutilization of cpus.
>>> >
>>> > Signed-off-by: Thara Gopinath 
>>> > Signed-off-by: Dietmar Eggemann 
>>> > ---
>>> >  include/linux/sched/topology.h |  1 +
>>> >  kernel/sched/fair.c| 62 
>>> > --
>>> >  kernel/sched/sched.h   |  1 +
>>> >  kernel/sched/topology.c| 12 +++-
>>> >  4 files changed, 65 insertions(+), 11 deletions(-)
>>> >
>>> > diff --git a/include/linux/sched/topology.h 
>>> > b/include/linux/sched/topology.h
>>> > index 26347741ba50..dd001c232646 100644
>>> > --- a/include/linux/sched/topology.h
>>> > +++ b/include/linux/sched/topology.h
>>> > @@ -72,6 +72,7 @@ struct sched_domain_shared {
>>> > atomic_tref;
>>> > atomic_tnr_busy_cpus;
>>> > int has_idle_cores;
>>> > +   int overutilized;
>>> >  };
>>> >
>>> >  struct sched_domain {
>>> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> > index 0a76ad2ef022..6960e5ef3c14 100644
>>> > --- a/kernel/sched/fair.c
>>> > +++ b/kernel/sched/fair.c
>>> > @@ -5345,6 +5345,28 @@ static inline void hrtick_update(struct rq *rq)
>>> >  }
>>> >  #endif
>>> >
>>> > +#ifdef CONFIG_SMP
>>> > +static inline int cpu_overutilized(int cpu);
>>> > +
>>> > +static inline int sd_overutilized(struct sched_domain *sd)
>>> > +{
>>> > +   return READ_ONCE(sd->shared->overutilized);
>>> > +}
>>> > +
>>> > +static inline void update_overutilized_status(struct rq *rq)
>>> > +{
>>> > +   struct sched_domain *sd;
>>> > +
>>> > +   rcu_read_lock();
>>> > +   sd = rcu_dereference(rq->sd);
>>> > +   if (sd && !sd_overutilized(sd) && cpu_overutilized(rq->cpu))
>>> > +   WRITE_ONCE(sd->shared->overutilized, 1);
>>> > +   rcu_read_unlock();
>>> > +}
>>> > +#else
>>> > +static inline void update_overutilized_status(struct rq *rq) {}
>>> > +#endif /* CONFIG_SMP */
>>> > +
>>> >  /*
>>> >   * The enqueue_task method is called before nr_running is
>>> >   * increased. Here we update the fair scheduling stats and
>>> > @@ -5394,8 +5416,10 @@ enqueue_task_fair(struct rq *rq, struct 
>>> > task_struct *p, int flags)
>>> > update_cfs_group(se);
>>> > }
>>> >
>>> > -   if (!se)
>>> > +   if (!se) {
>>> > add_nr_running(rq, 1);
>>> > +   update_overutilized_status(rq);
>>> > +   }
>>>
>>> I'm wondering if it makes sense for considering scenarios whether
>>> other classes cause CPUs in the domain to go above the tipping point.
>>> Then in that case also, it makes sense to not to do EAS in that domain
>>> because of the overutilization.
>>>
>>> I guess task_fits using cpu_util which is PELT only at the moment...
>>> so may require some other method like aggregation of CFS PELT, with
>>> RT-PELT and DL running bw or 

Re: [PATCH v2 4/4] qxl: drop dummy functions

[Daniel Vetter]

On Fri, Apr 20, 2018 at 09:19:04AM +0200, Gerd Hoffmann wrote:
> These days drm core checks function pointers everywhere before calling
> them.  So we can drop a bunch of dummy functions now.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/qxl/qxl_display.c | 50 
> ---
>  1 file changed, 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 06ee00b486..af6e52af5f 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -456,13 +456,6 @@ qxl_framebuffer_init(struct drm_device *dev,
>   return 0;
>  }
>  
> -static bool qxl_crtc_mode_fixup(struct drm_crtc *crtc,
> -   const struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode)
> -{
> - return true;
> -}
> -
>  static void qxl_crtc_atomic_enable(struct drm_crtc *crtc,
>  struct drm_crtc_state *old_state)
>  {
> @@ -476,7 +469,6 @@ static void qxl_crtc_atomic_disable(struct drm_crtc *crtc,
>  }
>  
>  static const struct drm_crtc_helper_funcs qxl_crtc_helper_funcs = {
> - .mode_fixup = qxl_crtc_mode_fixup,
>   .atomic_flush = qxl_crtc_atomic_flush,
>   .atomic_enable = qxl_crtc_atomic_enable,
>   .atomic_disable = qxl_crtc_atomic_disable,
> @@ -620,12 +612,6 @@ static void qxl_primary_atomic_disable(struct drm_plane 
> *plane,
>   }
>  }
>  
> -static int qxl_plane_atomic_check(struct drm_plane *plane,
> -   struct drm_plane_state *state)
> -{
> - return 0;
> -}
> -
>  static void qxl_cursor_atomic_update(struct drm_plane *plane,
>struct drm_plane_state *old_state)
>  {
> @@ -831,7 +817,6 @@ static const uint32_t qxl_cursor_plane_formats[] = {
>  };
>  
>  static const struct drm_plane_helper_funcs qxl_cursor_helper_funcs = {
> - .atomic_check = qxl_plane_atomic_check,
>   .atomic_update = qxl_cursor_atomic_update,
>   .atomic_disable = qxl_cursor_atomic_disable,
>   .prepare_fb = qxl_plane_prepare_fb,
> @@ -956,28 +941,6 @@ static int qdev_crtc_init(struct drm_device *dev, int 
> crtc_id)
>   return r;
>  }
>  
> -static void qxl_enc_dpms(struct drm_encoder *encoder, int mode)
> -{
> - DRM_DEBUG("\n");
> -}
> -
> -static void qxl_enc_prepare(struct drm_encoder *encoder)
> -{
> - DRM_DEBUG("\n");
> -}
> -
> -static void qxl_enc_commit(struct drm_encoder *encoder)
> -{
> - DRM_DEBUG("\n");
> -}
> -
> -static void qxl_enc_mode_set(struct drm_encoder *encoder,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> - DRM_DEBUG("\n");
> -}
> -
>  static int qxl_conn_get_modes(struct drm_connector *connector)
>  {
>   unsigned pwidth = 1024;
> @@ -1023,10 +986,6 @@ static struct drm_encoder *qxl_best_encoder(struct 
> drm_connector *connector)
>  
>  
>  static const struct drm_encoder_helper_funcs qxl_enc_helper_funcs = {

Hm, I thought even the vtable itself is optional? We do have tons of if
(!funcs) checks all over the place at least.


> - .dpms = qxl_enc_dpms,
> - .prepare = qxl_enc_prepare,
> - .mode_set = qxl_enc_mode_set,
> - .commit = qxl_enc_commit,
>  };
>  
>  static const struct drm_connector_helper_funcs qxl_connector_helper_funcs = {
> @@ -1059,14 +1018,6 @@ static enum drm_connector_status qxl_conn_detect(
>: connector_status_disconnected;
>  }
>  
> -static int qxl_conn_set_property(struct drm_connector *connector,
> -struct drm_property *property,
> -uint64_t value)
> -{
> - DRM_DEBUG("\n");
> - return 0;
> -}
> -
>  static void qxl_conn_destroy(struct drm_connector *connector)
>  {
>   struct qxl_output *qxl_output =
> @@ -1081,7 +1032,6 @@ static const struct drm_connector_funcs 
> qxl_connector_funcs = {
>   .dpms = drm_helper_connector_dpms,
>   .detect = qxl_conn_detect,
>   .fill_modes = drm_helper_probe_single_connector_modes,
> - .set_property = qxl_conn_set_property,

This is a legacy callback anyway. I kinda wonder whether we should have a
bunch of WARN_ON checks for this, so that atomic drivers don't have these
hanging around anymore.

Anyway, patch looks pretty.

Reviewed-by: Daniel Vetter 
>   .destroy = qxl_conn_destroy,
>   .reset = drm_atomic_helper_connector_reset,
>   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> -- 
> 2.9.3
> 
> ___
> 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

Re: [PATCH] kernel: event: core: Change return type to vm_fault_t

[Peter Zijlstra]

On Sun, Apr 15, 2018 at 01:58:31AM +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler and
> page_mkwrite handler in struct vm_operations_struct.
> 
> Signed-off-by: Souptick Joarder 
> Reviewed-by: Matthew Wilcox 
> ---
>  kernel/events/core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 96db9ae..d09f1c4 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4918,11 +4918,11 @@ void perf_event_update_userpage(struct perf_event 
> *event)
>  }
>  EXPORT_SYMBOL_GPL(perf_event_update_userpage);
> 
> -static int perf_mmap_fault(struct vm_fault *vmf)
> +static vm_fault_t perf_mmap_fault(struct vm_fault *vmf)

I'm fine with the patch, but shouldn't this be part of a larger series /
cocinelle script?

Even if not everything that has a (struct vm_fault *) argument is a
fault handler, you could still match on the function being assigned to
vm_operations_struct::fault.

So ACK on the patch, but please don't do this with a slow trickle of
individual patches.

[PATCH v2] x86/Centaur: show more HW features in /proc/cpuinfo

[David Wang]

Centaur CPU has some intel compatible capabilities,include PMC and some
CPU virtualization capabilities. These capabilities should be initialized
in the centaur init function.

Signed-off-by: David Wang 

Changes from v1 to v2:
*1, move some defines outside the centaur_detect_vmx_virtcap;
*2, Delete some unuseful cap clear operaions in centaur_detect_vmx_virtcap;
*3, other little changes according to sugesstions from tglx;
---
 arch/x86/kernel/cpu/centaur.c | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index e5ec0f1..80d5110 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -18,6 +18,13 @@
 #define RNG_ENABLED(1 << 3)
 #define RNG_ENABLE (1 << 6)/* MSR_VIA_RNG */
 
+#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW   0x0020
+#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
+#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
+#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC   0x0001
+#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
+#define X86_VMX_FEATURE_PROC_CTLS2_VPID0x0020
+
 static void init_c3(struct cpuinfo_x86 *c)
 {
u32  lo, hi;
@@ -112,6 +119,31 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
}
 }
 
+static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c)
+{
+   u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
+
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
+   msr_ctl = vmx_msr_high | vmx_msr_low;
+
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
+   set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
+   set_cpu_cap(c, X86_FEATURE_VNMI);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
+ vmx_msr_low, vmx_msr_high);
+   msr_ctl2 = vmx_msr_high | vmx_msr_low;
+   if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
+   (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
+   set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
+   set_cpu_cap(c, X86_FEATURE_EPT);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
+   set_cpu_cap(c, X86_FEATURE_VPID);
+   }
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -128,6 +160,19 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+
+   if (c->cpuid_level > 9) {
+   unsigned int eax = cpuid_eax(10);
+
+   /*
+* Check for version and the number of counters
+* Version(eax[7:0]) can't be 0;
+* Counters(eax[15:8]) should be greater than 1;
+*/
+   if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
+   set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
+   }
+
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
@@ -199,6 +244,9 @@ static void init_centaur(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 #endif
+
+   if (cpu_has(c, X86_FEATURE_VMX))
+   centaur_detect_vmx_virtcap(c);
 }
 
 #ifdef CONFIG_X86_32
-- 
1.9.1

Re: [RFC] perf/core: what is exclude_idle supposed to do

[Peter Zijlstra]

On Wed, Apr 18, 2018 at 11:10:20AM -0400, Vince Weaver wrote:
> On Tue, 17 Apr 2018, Jiri Olsa wrote:
> 
> > On Mon, Apr 16, 2018 at 10:04:53PM +, Stephane Eranian wrote:
> > > Hi,
> > > 
> > > I am trying to understand what the exclude_idle event attribute is 
> > > supposed
> > > to accomplish.
> > > As per the definition in the header file:
> > > 
> > > exclude_idle   :  1, /* don't count when idle */
> > 
> > AFAICS it's not implemented
> 
> so just to be completely clear hear, we're saying that the "exclude_idle" 
> modifier has never done anything useful and still doesn't?

AFAICT it works on Power and possibly ARM.

Re: [PATCH v2 3/7] powerpc: use task_pid_nr() for TID allocation

[Andrew Donnellan]

[+ Sukadev, Christophe]

On 18/04/18 11:08, Alastair D'Silva wrote:

From: Alastair D'Silva 

The current implementation of TID allocation, using a global IDR, may
result in an errant process starving the system of available TIDs.
Instead, use task_pid_nr(), as mentioned by the original author. The
scenario described which prevented it's use is not applicable, as
set_thread_tidr can only be called after the task struct has been
populated.

Signed-off-by: Alastair D'Silva 


So it's too late in the evening for me to completely get my head around 
what's going on here enough to give my Reviewed-by:, but my current 
thinking is:


- In the first version of the patch to add TIDR support 
(https://patchwork.ozlabs.org/patch/799494/), it was originally proposed 
to call assign_thread_id() (as it was then called) from copy_thread()


- The comment block documents the reason why we can't use task_pid_nr() 
but assumes that we're trying to assign a TIDR from within copy_thread()


- The final patch that was accepted 
(https://patchwork.ozlabs.org/patch/835552/, 
ec233ede4c8654894610ea54f4dae7adc954ac62) instead sets the TIDR to 0 
from copy_thread(), so the original reasoning regarding not using 
task_pid_nr() within copy_thread() is no longer applicable.


Sukadev: does this sound right?


Andrew



---
  arch/powerpc/include/asm/switch_to.h |  1 -
  arch/powerpc/kernel/process.c| 97 +---
  2 files changed, 1 insertion(+), 97 deletions(-)

diff --git a/arch/powerpc/include/asm/switch_to.h 
b/arch/powerpc/include/asm/switch_to.h
index be8c9fa23983..5b03d8a82409 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -94,6 +94,5 @@ static inline void clear_task_ebb(struct task_struct *t)
  extern int set_thread_uses_vas(void);
  
  extern int set_thread_tidr(struct task_struct *t);

-extern void clear_thread_tidr(struct task_struct *t);
  
  #endif /* _ASM_POWERPC_SWITCH_TO_H */

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 3b00da47699b..87f047fd2762 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1496,103 +1496,12 @@ int set_thread_uses_vas(void)
  }
  
  #ifdef CONFIG_PPC64

-static DEFINE_SPINLOCK(vas_thread_id_lock);
-static DEFINE_IDA(vas_thread_ida);
-
-/*
- * We need to assign a unique thread id to each thread in a process.
- *
- * This thread id, referred to as TIDR, and separate from the Linux's tgid,
- * is intended to be used to direct an ASB_Notify from the hardware to the
- * thread, when a suitable event occurs in the system.
- *
- * One such event is a "paste" instruction in the context of Fast Thread
- * Wakeup (aka Core-to-core wake up in the Virtual Accelerator Switchboard
- * (VAS) in POWER9.
- *
- * To get a unique TIDR per process we could simply reuse task_pid_nr() but
- * the problem is that task_pid_nr() is not yet available copy_thread() is
- * called. Fixing that would require changing more intrusive arch-neutral
- * code in code path in copy_process()?.
- *
- * Further, to assign unique TIDRs within each process, we need an atomic
- * field (or an IDR) in task_struct, which again intrudes into the arch-
- * neutral code. So try to assign globally unique TIDRs for now.
- *
- * NOTE: TIDR 0 indicates that the thread does not need a TIDR value.
- *  For now, only threads that expect to be notified by the VAS
- *  hardware need a TIDR value and we assign values > 0 for those.
- */
-#define MAX_THREAD_CONTEXT ((1 << 16) - 1)
-static int assign_thread_tidr(void)
-{
-   int index;
-   int err;
-   unsigned long flags;
-
-again:
-   if (!ida_pre_get(_thread_ida, GFP_KERNEL))
-   return -ENOMEM;
-
-   spin_lock_irqsave(_thread_id_lock, flags);
-   err = ida_get_new_above(_thread_ida, 1, );
-   spin_unlock_irqrestore(_thread_id_lock, flags);
-
-   if (err == -EAGAIN)
-   goto again;
-   else if (err)
-   return err;
-
-   if (index > MAX_THREAD_CONTEXT) {
-   spin_lock_irqsave(_thread_id_lock, flags);
-   ida_remove(_thread_ida, index);
-   spin_unlock_irqrestore(_thread_id_lock, flags);
-   return -ENOMEM;
-   }
-
-   return index;
-}
-
-static void free_thread_tidr(int id)
-{
-   unsigned long flags;
-
-   spin_lock_irqsave(_thread_id_lock, flags);
-   ida_remove(_thread_ida, id);
-   spin_unlock_irqrestore(_thread_id_lock, flags);
-}
-
-/*
- * Clear any TIDR value assigned to this thread.
- */
-void clear_thread_tidr(struct task_struct *t)
-{
-   if (!t->thread.tidr)
-   return;
-
-   if (!cpu_has_feature(CPU_FTR_P9_TIDR)) {
-   WARN_ON_ONCE(1);
-   return;
-   }
-
-   mtspr(SPRN_TIDR, 0);
-   free_thread_tidr(t->thread.tidr);
-   t->thread.tidr = 0;
-}
-
-void 

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

[Arnd Bergmann]

On Fri, Apr 20, 2018 at 12:12 AM, Eric W. Biederman
 wrote:
> Arnd Bergmann  writes:
>
>> On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann  wrote:
>>> On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman  
>>> wrote:
 I suspect you want to use __kernel_ulong_t here instead of a raw
 unsigned long.  If nothing else it seems inconsistent to use typedefs
 in one half of the structure and no typedefs in the other half.
>>>
>>> Good catch, there is definitely something wrong here, but I think using
>>> __kernel_ulong_t for all members would also be wrong, as that
>>> still changes the layout on x32, which effectively is
>>>
>>> struct msqid64_ds {
>>>  ipc64_perm msg_perm;
>>>  u64 msg_stime;
>>>  u32 __unused1;
>>>  /* 32 bit implict padding */
>>>  u64 msg_rtime;
>>>  u32 __unused2;
>>>  /* 32 bit implict padding */
>>>  u64 msg_ctime;
>>>  u32 __unused3;
>>>  /* 32 bit implict padding */
>>>  __kernel_pid_t  shm_cpid;   /* pid of creator */
>>>  __kernel_pid_t  shm_lpid;   /* pid of last operator */
>>>  
>>> };
>>>
>>> The choices here would be to either use a mix of
>>> __kernel_ulong_t and unsigned long, or taking the x32
>>> version back into arch/x86/include/uapi/asm/ so the
>>> generic version at least makes some sense.
>>>
>>> I can't use __kernel_time_t for the lower half on 32-bit
>>> since it really should be unsigned.
>>
>> After thinking about it some more, I conclude that the structure is simply
>> incorrect on x32: The __kernel_ulong_t usage was introduced in 2013
>> in commit b9cd5ca22d67 ("uapi: Use __kernel_ulong_t in struct
>> msqid64_ds") and apparently was correct initially as __BITS_PER_LONG
>> evaluated to 64, but it broke with commit f4b4aae18288 ("x86/headers/uapi:
>> Fix __BITS_PER_LONG value for x32 builds") that changed the value
>> of __BITS_PER_LONG and introduced the extra padding in 2015.
>>
>> The same change apparently also broke a lot of other definitions, e.g.
>>
>> $ echo "#include " | gcc -mx32 -E -xc - | grep -A3
>> __kernel_size_t
>> typedef unsigned int __kernel_size_t;
>> typedef int __kernel_ssize_t;
>> typedef int __kernel_ptrdiff_t;
>>
>> Those used to be defined as 'unsigned long long' and 'long long'
>> respectively, so now all kernel interfaces using those on x32
>> became incompatible!
>
> Is this just for the uapi header as seen by userspace?  I expect we are
> using the a normal kernel interface with 64bit longs and 64bit pointers
> when we build the kernel.

Yes, that patch shouldn't have changed anything in the kernel, which
continues to be built with __BITS_PER_LONG=64. I haven't
checked the vdso, which is the only bit of the kernel that gets built
with -mx32, but I assume it's fine as well.

> If this is just a header as seen from userspace mess it seems
> unfortunate but fixable.

Right. I'll fix the IPC stuff for this series to make it work with
any value of __BITS_PER_LONG on x32, but I don't plan to
do anything about the rest of x32. The patch that caused the
problem was intended as a bugfix, so we can't just revert it
without first understanding how to properly fix the original bug,
and which other interfaces have now come to rely on
__BITS_PER_LONG=32 for x32.

Adding a few other folks that have been involved in the x32
kernel support or the Debian port in the past. Maybe one of
them is motivated to figure out how to fix this properly.

   Arnd

[PATCH 2/2] ubi: introduce ubi.nocheck parameter to skip CRC check when attaching ubi vol

[Quentin Schulz]

There's already ECC on NAND pages so there may be no need for one to
check the CRC of a UBI volume.

Let's introduce a ubi.nocheck parameter that let one skip the CRC check
when attaching a UBI volume.

This also drastically speeds kernel boot by removing a potentially
useless check, e.g. I gained 3.2s on boot time of a SPEAr600-based board
for a ~20MB UBI volume used as rootfs.

Signed-off-by: Quentin Schulz 
---
 drivers/mtd/ubi/kapi.c | 70 +++-
 drivers/mtd/ubi/ubi.h  |  6 -
 drivers/mtd/ubi/vtbl.c | 24 ++-
 3 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c
index d4b2e87..d604cd5 100644
--- a/drivers/mtd/ubi/kapi.c
+++ b/drivers/mtd/ubi/kapi.c
@@ -28,6 +28,9 @@
 #include 
 #include "ubi.h"
 
+struct ubivol_param ubinocheck_param[UBIVOL_MAX_DEVICES];
+int ubinocheck_devs;
+
 /**
  * ubi_do_get_device_info - get information about UBI device.
  * @ubi: UBI device description object
@@ -865,3 +868,70 @@ int ubi_unregister_volume_notifier(struct notifier_block 
*nb)
return blocking_notifier_chain_unregister(_notifiers, nb);
 }
 EXPORT_SYMBOL_GPL(ubi_unregister_volume_notifier);
+
+static int __init ubinocheckvol_set_param(const char *val,
+ const struct kernel_param *kp)
+{
+   int i, ret;
+   size_t len;
+   struct ubivol_param *param;
+   char buf[UBIVOL_PARAM_LEN];
+   char *pbuf = [0];
+   char *tokens[UBIVOL_PARAM_COUNT];
+
+   if (!val)
+   return -EINVAL;
+
+   len = strnlen(val, UBIVOL_PARAM_LEN);
+   if (len == 0) {
+   pr_warn("UBI: nocheck: empty 'nocheck=' parameter - ignored\n");
+   return 0;
+   }
+
+   if (len == UBIVOL_PARAM_LEN) {
+   pr_err("UBI: nocheck: parameter \"%s\" is too long, max. is 
%d\n",
+  val, UBIVOL_PARAM_LEN);
+   return -EINVAL;
+   }
+
+   strcpy(buf, val);
+
+   /* Get rid of the final newline */
+   if (buf[len - 1] == '\n')
+   buf[len - 1] = '\0';
+
+   for (i = 0; i < UBIVOL_PARAM_COUNT; i++)
+   tokens[i] = strsep(, ",");
+
+   param = _param[ubinocheck_devs];
+   if (tokens[1]) {
+   /* Two parameters: can be 'ubi, vol_id' or 'ubi, vol_name' */
+   ret = kstrtoint(tokens[0], 10, >ubi_num);
+   if (ret < 0)
+   return -EINVAL;
+
+   /* Second param can be a number or a name */
+   ret = kstrtoint(tokens[1], 10, >vol_id);
+   if (ret < 0) {
+   param->vol_id = -1;
+   strcpy(param->name, tokens[1]);
+   }
+   }
+
+   ubinocheck_devs++;
+
+   return 0;
+}
+
+static const struct kernel_param_ops ubinocheckvol_param_ops = {
+   .set= ubinocheckvol_set_param,
+};
+module_param_cb(nocheck, _param_ops, NULL, 0);
+MODULE_PARM_DESC(nocheck,
+"Disable CRC check for UBI volumes. Parameter format: 
nocheck=dev,[num|name]>.\n"
+"Multiple \"nocheck\" parameters may be specified.\n"
+"Examples\n"
+"Using the UBI device, and the volume name:\n"
+"ubi.nocheck=0,rootfs\n"
+"Using both UBI device number and UBI volume number:\n"
+"ubi.nocheck=0,0\n");
diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
index 4cc6ec9..2bd89b4 100644
--- a/drivers/mtd/ubi/ubi.h
+++ b/drivers/mtd/ubi/ubi.h
@@ -825,6 +825,12 @@ struct ubivol_param {
char name[UBIVOL_PARAM_LEN + 1];
 };
 
+/* Numbers of elements set in the @ubinocheck_param array */
+extern int ubinocheck_devs;
+
+/* MTD devices specification parameters */
+extern struct ubivol_param ubinocheck_param[UBIVOL_MAX_DEVICES];
+
 #include "debug.h"
 
 extern struct kmem_cache *ubi_wl_entry_slab;
diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
index 263743e..06b6cfd 100644
--- a/drivers/mtd/ubi/vtbl.c
+++ b/drivers/mtd/ubi/vtbl.c
@@ -534,9 +534,10 @@ static int init_volumes(struct ubi_device *ubi,
const struct ubi_attach_info *ai,
const struct ubi_vtbl_record *vtbl)
 {
-   int i, reserved_pebs = 0;
+   int i, j, reserved_pebs = 0;
struct ubi_ainf_volume *av;
struct ubi_volume *vol;
+   struct ubivol_param *param;
 
for (i = 0; i < ubi->vtbl_slots; i++) {
cond_resched();
@@ -620,6 +621,27 @@ static int init_volumes(struct ubi_device *ubi,
(long long)(vol->used_ebs - 1) * vol->usable_leb_size;
vol->used_bytes += av->last_data_size;
vol->last_eb_bytes = av->last_data_size;
+
+   for (j = 0; j < ubinocheck_devs; j++) {
+   param = _param[j];
+
+   if (vol->ubi->ubi_num != 

[PATCH 1/2] ubi: move constants for ubi vol parsing from kernel param to ubi.h

[Quentin Schulz]

The constants used to parse ubi.block parameters from the kernel command
line are not specific to UBI block devices but rather to UBI volumes
(on which block devices are "based").

So let's rename UBIBLOCK_* constants used in parameter parsing to
UBIVOL_*.

Let's move the constants to ubi.h so that they can be used to parse
other parameters impacting UBI volumes.

Signed-off-by: Quentin Schulz 
---
 drivers/mtd/ubi/block.c | 33 +
 drivers/mtd/ubi/ubi.h   | 15 +++
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
index d0b63bb..836272c 100644
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -54,21 +54,6 @@
 #include "ubi-media.h"
 #include "ubi.h"
 
-/* Maximum number of supported devices */
-#define UBIBLOCK_MAX_DEVICES 32
-
-/* Maximum length of the 'block=' parameter */
-#define UBIBLOCK_PARAM_LEN 63
-
-/* Maximum number of comma-separated items in the 'block=' parameter */
-#define UBIBLOCK_PARAM_COUNT 2
-
-struct ubiblock_param {
-   int ubi_num;
-   int vol_id;
-   char name[UBIBLOCK_PARAM_LEN+1];
-};
-
 struct ubiblock_pdu {
struct work_struct work;
struct ubi_sgl usgl;
@@ -78,7 +63,7 @@ struct ubiblock_pdu {
 static int ubiblock_devs __initdata;
 
 /* MTD devices specification parameters */
-static struct ubiblock_param ubiblock_param[UBIBLOCK_MAX_DEVICES] __initdata;
+static struct ubivol_param ubiblock_param[UBIVOL_MAX_DEVICES] __initdata;
 
 struct ubiblock {
struct ubi_volume_desc *desc;
@@ -109,23 +94,23 @@ static int __init ubiblock_set_param(const char *val,
 {
int i, ret;
size_t len;
-   struct ubiblock_param *param;
-   char buf[UBIBLOCK_PARAM_LEN];
+   struct ubivol_param *param;
+   char buf[UBIVOL_PARAM_LEN];
char *pbuf = [0];
-   char *tokens[UBIBLOCK_PARAM_COUNT];
+   char *tokens[UBIVOL_PARAM_COUNT];
 
if (!val)
return -EINVAL;
 
-   len = strnlen(val, UBIBLOCK_PARAM_LEN);
+   len = strnlen(val, UBIVOL_PARAM_LEN);
if (len == 0) {
pr_warn("UBI: block: empty 'block=' parameter - ignored\n");
return 0;
}
 
-   if (len == UBIBLOCK_PARAM_LEN) {
+   if (len == UBIVOL_PARAM_LEN) {
pr_err("UBI: block: parameter \"%s\" is too long, max. is %d\n",
-  val, UBIBLOCK_PARAM_LEN);
+  val, UBIVOL_PARAM_LEN);
return -EINVAL;
}
 
@@ -135,7 +120,7 @@ static int __init ubiblock_set_param(const char *val,
if (buf[len - 1] == '\n')
buf[len - 1] = '\0';
 
-   for (i = 0; i < UBIBLOCK_PARAM_COUNT; i++)
+   for (i = 0; i < UBIVOL_PARAM_COUNT; i++)
tokens[i] = strsep(, ",");
 
param = _param[ubiblock_devs];
@@ -599,7 +584,7 @@ open_volume_desc(const char *name, int ubi_num, int vol_id)
 static void __init ubiblock_create_from_param(void)
 {
int i, ret = 0;
-   struct ubiblock_param *p;
+   struct ubivol_param *p;
struct ubi_volume_desc *desc;
struct ubi_volume_info vi;
 
diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
index 5fe6265..4cc6ec9 100644
--- a/drivers/mtd/ubi/ubi.h
+++ b/drivers/mtd/ubi/ubi.h
@@ -810,6 +810,21 @@ struct ubi_work {
int anchor;
 };
 
+/* Maximum number of supported devices */
+#define UBIVOL_MAX_DEVICES 32
+
+/* Maximum length of the vol parameter */
+#define UBIVOL_PARAM_LEN 63
+
+/* Maximum number of comma-separated items in a vol parameter */
+#define UBIVOL_PARAM_COUNT 2
+
+struct ubivol_param {
+   int ubi_num;
+   int vol_id;
+   char name[UBIVOL_PARAM_LEN + 1];
+};
+
 #include "debug.h"
 
 extern struct kmem_cache *ubi_wl_entry_slab;

base-commit: 559d97996f1b75731195d813158eee7cc8a1f316
-- 
git-series 0.9.1

lainoja

[Ronald Bernstein]

Olen Ronald Bernstein, olen lainanantaja, annan lainoja yksittäisille ja 
yrityksille, liike- ja henkilökohtaisiin tarkoituksiin, ota yhteyttä minuun, 
jos tarvitset minkäänlaista lainaa. Annan lainoja yleisölle 2 prosentin 
korolla. Ota yhteyttä minuun

[PATCH v1 1/3] ARM: dts: stm32: Append additional I2Cs for STM32F746 SoC

[Pierre-Yves MORDRET]

Append 3 additional I2C instance for STM32F746 SoC.

Signed-off-by: Pierre-Yves MORDRET 
---
  Version history:
 v1:
* Initial
---
---
 arch/arm/boot/dts/stm32f746.dtsi | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index 4be2ee5..1479e3e 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -345,6 +345,42 @@
status = "disabled";
};
 
+   i2c2: i2c@40005800 {
+   compatible = "st,stm32f7-i2c";
+   reg = <0x40005800 0x400>;
+   interrupts = <33>,
+<34>;
+   resets = < STM32F7_APB1_RESET(I2C2)>;
+   clocks = < 1 CLK_I2C2>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@40005C00 {
+   compatible = "st,stm32f7-i2c";
+   reg = <0x40005C00 0x400>;
+   interrupts = <72>,
+<73>;
+   resets = < STM32F7_APB1_RESET(I2C3)>;
+   clocks = < 1 CLK_I2C3>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c4: i2c@40006000 {
+   compatible = "st,stm32f7-i2c";
+   reg = <0x40006000 0x400>;
+   interrupts = <95>,
+<96>;
+   resets = < STM32F7_APB1_RESET(I2C4)>;
+   clocks = < 1 CLK_I2C4>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
cec: cec@40006c00 {
compatible = "st,stm32-cec";
reg = <0x40006C00 0x400>;
-- 
2.7.4

[PATCH v1 2/2] ARM: dts: stm32: Add I2C1 support for STM32H743I-EVAL Board

[Pierre-Yves MORDRET]

Add I2C1 support for STM32H743I-EVAL Board

Signed-off-by: Pierre-Yves MORDRET 
---
  Version history:
 v1:
* Initial
---
---
 arch/arm/boot/dts/stm32h743i-eval.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/stm32h743i-eval.dts 
b/arch/arm/boot/dts/stm32h743i-eval.dts
index c7187e1..3f8e0c4 100644
--- a/arch/arm/boot/dts/stm32h743i-eval.dts
+++ b/arch/arm/boot/dts/stm32h743i-eval.dts
@@ -92,6 +92,14 @@
clock-frequency = <2500>;
 };
 
+ {
+   pinctrl-0 = <_pins_a>;
+   pinctrl-names = "default";
+   i2c-scl-rising-time-ns = <185>;
+   i2c-scl-falling-time-ns = <20>;
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.7.4

[PATCH v1 1/2] ARM: dts: stm32: Add I2C support for STM32H743 SoC

[Pierre-Yves MORDRET]

Add I2C support for STM32H743 SoC

Signed-off-by: Pierre-Yves MORDRET 
---
  Version history:
 v1:
* Initial
---
---
 arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 10 +++
 arch/arm/boot/dts/stm32h743.dtsi | 48 
 2 files changed, 58 insertions(+)

diff --git a/arch/arm/boot/dts/stm32h743-pinctrl.dtsi 
b/arch/arm/boot/dts/stm32h743-pinctrl.dtsi
index 0f15dfb..24be8e6 100644
--- a/arch/arm/boot/dts/stm32h743-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32h743-pinctrl.dtsi
@@ -163,6 +163,16 @@
#interrupt-cells = <2>;
};
 
+   i2c1_pins_a: i2c1@0 {
+   pins {
+   pinmux = , 
/* I2C1_SCL */
+; 
/* I2C1_SDA */
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <0>;
+   };
+   };
+
usart1_pins: usart1@0 {
pins1 {
pinmux = ; 
/* USART1_TX */
diff --git a/arch/arm/boot/dts/stm32h743.dtsi b/arch/arm/boot/dts/stm32h743.dtsi
index 2bb103e..7b64af0 100644
--- a/arch/arm/boot/dts/stm32h743.dtsi
+++ b/arch/arm/boot/dts/stm32h743.dtsi
@@ -130,6 +130,42 @@
clocks = < USART2_CK>;
};
 
+   i2c1: i2c@40005400 {
+   compatible = "st,stm32f7-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40005400 0x400>;
+   interrupts = <31>,
+<32>;
+   resets = < STM32H7_APB1L_RESET(I2C1)>;
+   clocks = < I2C1_CK>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@40005800 {
+   compatible = "st,stm32f7-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40005800 0x400>;
+   interrupts = <33>,
+<34>;
+   resets = < STM32H7_APB1L_RESET(I2C2)>;
+   clocks = < I2C2_CK>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@40005C00 {
+   compatible = "st,stm32f7-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40005C00 0x400>;
+   interrupts = <72>,
+<73>;
+   resets = < STM32H7_APB1L_RESET(I2C3)>;
+   clocks = < I2C3_CK>;
+   status = "disabled";
+   };
+
dac: dac@40007400 {
compatible = "st,stm32h7-dac-core";
reg = <0x40007400 0x400>;
@@ -323,6 +359,18 @@
status = "disabled";
};
 
+   i2c4: i2c@58001C00 {
+   compatible = "st,stm32f7-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x58001C00 0x400>;
+   interrupts = <95>,
+<96>;
+   resets = < STM32H7_APB4_RESET(I2C4)>;
+   clocks = < I2C4_CK>;
+   status = "disabled";
+   };
+
lptimer2: timer@58002400 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.4

[PATCH v1 0/4] Add DMAv2 and DMAMUX Support on STM32MP157C

[Pierre-Yves MORDRET]

This patch adds DMAv2 and DMAMUX support on STM32MP157C with configs and device 
tree.
---
  Version history:
 v1:
* Initial
---

Pierre-Yves MORDRET (4):
  ARM: configs: stm32: Add DMAv2 support on STM32MP157C machine
  ARM: configs: stm32: Add DMAMUX support on STM32MP157C
  ARM: dts: stm32: Add DMAv2 support on STM32MP157C
  ARM: dts: stm32: Add DMAMUX support on STM32MP157C

 arch/arm/boot/dts/stm32mp157c.dtsi | 44 ++
 arch/arm/mach-stm32/Kconfig|  2 ++
 2 files changed, 46 insertions(+)

-- 
2.7.4

[PATCH v1 0/3] Append additional I2C instances and activate I2C1.

[Pierre-Yves MORDRET]

This patch intends to appends 3 additional I2C instances (2, 3 and 4).
In the same time I2C1 is setup for both STM32F746 and STM32F769 Discovery
boards.
---
  Version history:
 v1:
* Initial
---

Pierre-Yves MORDRET (3):
  ARM: dts: stm32: Append additional I2Cs for STM32F746 SoC
  ARM: dts: stm32: Add I2C1 support for STM32F769-DISCO Board
  ARM: dts: stm32: Add I2C1 support for STM32F746-DISCO Board

 arch/arm/boot/dts/stm32f746-disco.dts |  8 
 arch/arm/boot/dts/stm32f746.dtsi  | 36 +++
 arch/arm/boot/dts/stm32f769-disco.dts |  8 
 3 files changed, 52 insertions(+)

-- 
2.7.4

[PATCH v1 0/2] Add I2C support for STM32H743

[Pierre-Yves MORDRET]

Add I2C support on STM32H743 SoC.
Activate I2C1 on STM32H743I Evaluation Board.
---
  Version history:
 v1:
* Initial
---

Pierre-Yves MORDRET (2):
  ARM: dts: stm32: Add I2C support for STM32H743 SoC
  ARM: dts: stm32: Add I2C1 support for STM32H743I-EVAL Board

 arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 10 +++
 arch/arm/boot/dts/stm32h743.dtsi | 48 
 arch/arm/boot/dts/stm32h743i-eval.dts|  8 ++
 3 files changed, 66 insertions(+)

-- 
2.7.4

[PATCH] ARM: dts: stm32: add reset binding on stm32mp157c

[gabriel.fernandez]

From: Gabriel Fernandez 

This patch adds reset binding file.

Signed-off-by: Gabriel Fernandez 
---
 arch/arm/boot/dts/stm32mp157c.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi 
b/arch/arm/boot/dts/stm32mp157c.dtsi
index bc3eddc..7e91fd6 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -5,6 +5,7 @@
  */
 #include 
 #include 
+#include 
 
 / {
#address-cells = <1>;
-- 
1.9.1

Re: [PATCH] printk: Ratelimit messages printed by console drivers

[Petr Mladek]

On Fri 2018-04-20 11:15:11, Sergey Senozhatsky wrote:
> On (04/19/18 14:53), Petr Mladek wrote:
> > > > > 
> > > > > Besides 100 lines is absolutely not enough for any real lockdep splat.
> > > > > My call would be - up to 1000 lines in a 1 minute interval.
> > 
> > But this would break the intention of this patch.
> 
> You picked an arbitrary value and now you are saying that any other
> value will not work?

Yes, my number was arbitrary. The important thing is that it was long
enough. Or do you know about an console that will not be able to write
100 lines within one hour?

On the other hand. Let's take a classic 9600 baud console
1000 lines 80 characters long. If I count correctly,
the console would need:

  80 * 1000 * 8 / 9600 = 66.666 seconds

You might argue that average lines are below 80 characters.
But there eveidently is a non-trivial risk that 1000 lines
per minute ratelimiting would not help.


> > Come on guys! The first reaction how to fix the infinite loop was
> > to fix the console drivers and remove the recursive messages. We are
> > talking about messages that should not be there or they should
> > get replaced by WARN_ONCE(), print_once() or so. This patch only
> > give us a chance to see the problem and do not blow up immediately.
> > 
> > I am fine with increasing the number of lines. But we need to keep
^^

> > the timeout long. In fact, 1 hour is still rather short from my POV.
> 
> Disagree.
> 
> I saw 3 or 4 lockdep reports coming from console drivers. "100 lines"
> is way too restrictive.

As I already wrote. I am fine with increasing the number of lines.
Will 1000 lines within 1 hour be enough for you, please?


> > > > Well, if we want to basically turn printk_safe() into 
> > > > printk_safe_ratelimited().
> > > > I'm not so sure about it.
> > 
> > No, it is not about printk_safe(). The ratelimit is active when
> > console_owner == current. It triggers when printk() is called
> > inside
> 
> "console_owner == current" is exactly the point when we call console
> drivers and add scheduler, networking, timekeeping, etc. locks to the
> picture. And so far all of the lockdeps reports that we had were from
> call_console_drivers(). So it very much is about printk_safe().

I am lost. In the mail
https://lkml.kernel.org/r/20180416014729.GB1034@jagdpanzerIV
you wrote:


Chatty console drivers is not exactly the case which printk_safe() was
meant to fix. I'm pretty sure I put call_console_drivers() under printk_safe
just because we call console_drivers with local IRQs disabled anyway and I
was too lazy to do something like this


My understanding of the older mail is that you called
console_drivers() in printk_safe() context only because it was
easier to disable printk_safe context later together with
enabling irqs.

My understanding of today's mail is that it is important
to call console drivers in printk_safe() context.

It is a contradiction. Could you please explain?


> > > > Besides the patch also rate limits printk_nmi->logbuf - the logbuf
> > > > PRINTK_NMI_DEFERRED_CONTEXT_MASK bypass, which is way too important
> > > > to rate limit it - for no reason.
> > 
> > Again. It has the effect only when console_owner == current. It means
> > that it affects "only" NMIs that interrupt console_unlock() when calling
> > console drivers.
> 
> What is your objection here? NMIs can come anytime.

Why do you completely ignore that I put "only" into quotation marks?
Why did you comment only the first paragraph and removed the
following paragraph from my reply?:


Anyway, it needs to get fixed. I suggest to update the check in
printk_func():

if (console_owner == current && !in_nmi() &&
!__ratelimit(_console))
return 0;



What is you real intention, please? Do you just want to show me as
an idiot or solve the problem? Is this some politics game?


> > > One more thing,
> > > I'd really prefer to rate limit the function which flushes per-CPU
> > > printk_safe buffers; not the function that appends new messages to
> > > the per-CPU printk_safe buffers.
> > 
> > I wonder if this opinion is still valid after explaining the
> > dependency on printk_safe(). In each case, it sounds weird
> > to block printk_safe buffers with some "unwanted" messages.
> > Or maybe I miss something.
> 
> I'm not following.
> 
> The fact that some consoles under some circumstances can add unwanted
> messages to the buffer does not look like a good enough reason to start
> rate limiting _all_ messages and to potentially discard the _important_
> ones.

Could you please read the original patch again? The ratelimiting
happens only when console_owner == current. This will be true
only if you print a message from the small context of
console_unlock() where console drivers are called?

What do you mean by _all_ messages, please?

Best Regards,
Petr

[PATCH] mfd: tps65911-comparator: Fix a build error

[Dan Carpenter]

In 2012, we changed the tps65910 API and fixed most drivers but forgot
to update this one.

Fixes: 3f7e82759c69 ("mfd: Commonize tps65910 regmap access through header")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/mfd/tps65911-comparator.c 
b/drivers/mfd/tps65911-comparator.c
index 887409c3938d..90cfdd1f88c6 100644
--- a/drivers/mfd/tps65911-comparator.c
+++ b/drivers/mfd/tps65911-comparator.c
@@ -74,7 +74,7 @@ static int comp_threshold_set(struct tps65910 *tps65910, int 
id, int voltage)
return -EINVAL;
 
val = index << 1;
-   ret = tps65910->write(tps65910, tps_comp.reg, 1, );
+   ret = tps65910_reg_write(tps65910, tps_comp.reg, val);
 
return ret;
 }
@@ -82,10 +82,10 @@ static int comp_threshold_set(struct tps65910 *tps65910, 
int id, int voltage)
 static int comp_threshold_get(struct tps65910 *tps65910, int id)
 {
struct comparator tps_comp = tps_comparators[id - 1];
+   unsigned int val;
int ret;
-   u8 val;
 
-   ret = tps65910->read(tps65910, tps_comp.reg, 1, );
+   ret = tps65910_reg_read(tps65910, tps_comp.reg, );
if (ret < 0)
return ret;
 

Re: [linux-sunxi] Re: [PATCH v2 14/16] arm: dts: sun8i: h3: enable H3 sid controller

[Philipp Rossak]

Hi Kyle,

I'm already working on a Version 3 of this patch series. Right now this 
slowed down since I'm very busy and the ToDo-List is still very long.


My plan is to send out a version during this release cycle.

If you need it right now feel free to submit patches!

Philipp

On 19.04.2018 17:19, Kyle Evans wrote:

On Thu, Apr 19, 2018 at 10:13 AM, Icenowy Zheng  wrote:



于 2018年4月19日 GMT+08:00 下午11:11:22, Kyle Evans  写到:

On Mon, Jan 29, 2018 at 6:03 AM, Philipp Rossak 
wrote:



On 29.01.2018 10:52, Maxime Ripard wrote:


On Mon, Jan 29, 2018 at 12:29:17AM +0100, Philipp Rossak wrote:


This patch enables the the sid controller in the H3. It can be used
for thermal calibration data.

Signed-off-by: Philipp Rossak 
---
   arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
   1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
b/arch/arm/boot/dts/sun8i-h3.dtsi
index 3f83f6a27c74..9bb5cc29fec5 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -72,6 +72,13 @@
 };
 };
   + soc {
+   sid: eeprom@1c14000 {
+   compatible = "allwinner,sun8i-h3-sid";
+   reg = <0x01c14000 0x400>;
+   };
+   };
+



Shouldn't you also use a nvmem-cells property to the THS node?

Maxime



Oh seems like I forgot that.
As related to the wiki [1] this should be 64 bit wide at the address

0x34. I

will add that in the next version.


[1]: http://linux-sunxi.org/SID_Register_Guide#eFUSE

Thanks,
Philipp



Hi,

Any chance this will see a v3 soon? I'm kind of interested in sid node
for h3. =)


This patch is independent and can be easily sent out
by its own.



Right- I had considered doing so, but wanted to make sure I wasn't
going to collide with this series if a v3 is imminent.

RE: [PATCH resend] usb: chipidea: Don't select EXTCON

[Peter Chen]

 
> >
> > Sorry to reply late, are you really care 2KB code side? Since many
> > users use EXTCON to handle vbus and id, it is hard just delete it. I
> > could accept patch for your specific platforms, like:
> >
> > +   select EXTCON if !ARCH_
> 
> The patch doesn't remove extcon support from chipidea driver.
> I just want to not select EXTCON unconditionally, but let the users choose. 
> If the
> users need extcon, they could enable EXTCON themselves
> 
> I just searched all the dts in arch/arm/boot/dts and arch/arm64/boot/dts only 
> the four
> dts give extcon phandle to chipidea host, other users don't make use of it:
> 
> arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> 
> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> 
> arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
> 
> arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts
> 

I see, but I do not want to break msm platforms. You may try to create Glue 
driver Kconfig
entry for chipidea like dwc3, and let msm depends on EXTCON.

Peter

Re: [PATCH] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()

[Kirill Tkhai]

Hi, Juri,

On 20.04.2018 12:25, Juri Lelli wrote:
> Hi Kirill,
> 
> On 19/04/18 20:29, Kirill Tkhai wrote:
>> tg_rt_schedulable() iterates over all child task groups,
>> while tg_has_rt_tasks() iterates over all linked tasks.
>> In case of systems with big number of tasks, this may
>> take a lot of time.
>>
>> I observed hard LOCKUP on machine with 2+ processes
>> after write to "cpu.rt_period_us" of cpu cgroup with
>> 39 children. The problem occurred because of tasklist_lock
>> is held for a long time and other processes can't do fork().
>>
>> PID: 1036268  TASK: 88766c31  CPU: 36  COMMAND: "criu"
>>  #0 [887f7f408e48] crash_nmi_callback at 81050601
>>  #1 [887f7f408e58] nmi_handle at 816e0cc7
>>  #2 [887f7f408eb0] do_nmi at 816e0fb0
>>  #3 [887f7f408ef0] end_repeat_nmi at 816e00b9
>> [exception RIP: tg_rt_schedulable+463]
>> RIP: 810bf49f  RSP: 886537ad7d50  RFLAGS: 0202
>> RAX:   RBX: 3b9aca00  RCX: 883e9cb4b1b0
>> RDX: 887d0be43608  RSI: 886537ad7dd8  RDI: 8840a6ad
>> RBP: 886537ad7d68   R8: 887d0be431b0   R9: 000e7ef0
>> R10: 88164fc39400  R11: 00023380  R12: 81ef8d00
>> R13: 810bea40  R14:   R15: 8840a6ad
>> ORIG_RAX:   CS: 0010  SS: 0018
>> ---  ---
>>  #4 [886537ad7d50] tg_rt_schedulable at 810bf49f
>>  #5 [886537ad7d70] walk_tg_tree_from at 810c6c91
>>  #6 [886537ad7dc0] tg_set_rt_bandwidth at 810c6dd0
>>  #7 [886537ad7e28] cpu_rt_period_write_uint at 810c6eea
>>  #8 [886537ad7e38] cgroup_file_write at 8111cfd3
>>  #9 [886537ad7ec8] vfs_write at 8121eced
>> #10 [886537ad7f08] sys_write at 8121faff
>> #11 [886537ad7f50] system_call_fastpath at 816e8a7d
>>
>> The patch reworks tg_has_rt_tasks() and makes it to check
>> for rt_rq::rt_nr_running instead of iteration over task list.
>> This makes the function to scale well, and its execution time
>> does not depend on number of processes in the system.
>>
>> Note, that since tasklist_lock doesn't protect a task against
>> sched_class changing, we don't introduce new races in comparison
>> to that we had before. Also, rt_rq::rt_nr_running contains queued
>> child cfs_rq in additional to queued task. Since tg_has_rt_tasks()
> 
> s/cfs_/rt_/ , right?
> 
>> is used in case of !runtime case:
>>
>>  if (rt_bandwidth_enabled() && !runtime && tg_has_rt_tasks(tg))
>>  return -EBUSY;
>>
>> the behaviour won't change. The only change is that walk_tg_tree()
>> calling tg_rt_schedulable() will break its iteration on parent cfs_rq,
> 
> Ditto.
> 
>> i.e. earlier.
>>
>> Signed-off-by: Kirill Tkhai 
>> ---
>>  kernel/sched/rt.c |   22 --
>>  1 file changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
>> index 7aef6b4e885a..601151bb9322 100644
>> --- a/kernel/sched/rt.c
>> +++ b/kernel/sched/rt.c
>> @@ -2395,10 +2395,10 @@ const struct sched_class rt_sched_class = {
>>   */
>>  static DEFINE_MUTEX(rt_constraints_mutex);
>>  
>> -/* Must be called with tasklist_lock held */
>>  static inline int tg_has_rt_tasks(struct task_group *tg)
>>  {
>> -struct task_struct *g, *p;
>> +struct rt_rq *rt_rq;
>> +int cpu, ret = 0;
>>  
>>  /*
>>   * Autogroups do not have RT tasks; see autogroup_create().
>> @@ -2406,12 +2406,18 @@ static inline int tg_has_rt_tasks(struct task_group 
>> *tg)
>>  if (task_group_is_autogroup(tg))
>>  return 0;
>>  
>> -for_each_process_thread(g, p) {
>> -if (rt_task(p) && task_group(p) == tg)
>> -return 1;
>> +preempt_disable();
>> +
>> +for_each_online_cpu(cpu) {
>> +rt_rq = tg->rt_rq[cpu];
>> +if (READ_ONCE(rt_rq->rt_nr_running)) {
> 
> Isn't this however checking against the current (dynamic) number of
> runnable tasks/groups instead of the "static" group membership (which
> shouldn't be affected by a task running state)?

Ah, you are sure. I forgot that rt_nr_running does not contain sleeping tasks.
We need to check something else here. I'll try to find another way.

Thanks,
Kirill

[PATCH v4 1/3] dell-led: Change dell-led.h to dell-common.h

[Kai-Heng Feng]

This header will be used for more than just led. Change it to a more
generic name.

Cc: Mario Limonciello 
Signed-off-by: Kai-Heng Feng 
---
v4: Change the commit message to clarify there's no more runtime pm
warning.
Also skip the check for thunderbolt attached devices.

v3: Simplify dell_switchable_gfx_is_enabled() by returning bool instead
of error code.
Use DMI_DEV_TYPE_OEM_STRING to match Dell System.

v2: Mario suggested to squash the HDA part into the same series.

 drivers/platform/x86/dell-laptop.c  | 2 +-
 include/linux/{dell-led.h => dell-common.h} | 4 ++--
 sound/pci/hda/dell_wmi_helper.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)
 rename include/linux/{dell-led.h => dell-common.h} (61%)

diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index c52c6723374b..8ba820e6c3d0 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -29,7 +29,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include "dell-rbtn.h"
diff --git a/include/linux/dell-led.h b/include/linux/dell-common.h
similarity index 61%
rename from include/linux/dell-led.h
rename to include/linux/dell-common.h
index 92521471517f..37e4b614dd74 100644
--- a/include/linux/dell-led.h
+++ b/include/linux/dell-common.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __DELL_LED_H__
-#define __DELL_LED_H__
+#ifndef __DELL_COMMON_H__
+#define __DELL_COMMON_H__
 
 int dell_micmute_led_set(int on);
 
diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
index 1b48a8c19d28..56050cc3c0ee 100644
--- a/sound/pci/hda/dell_wmi_helper.c
+++ b/sound/pci/hda/dell_wmi_helper.c
@@ -4,7 +4,7 @@
  */
 
 #if IS_ENABLED(CONFIG_DELL_LAPTOP)
-#include 
+#include 
 
 enum {
MICMUTE_LED_ON,
-- 
2.17.0

[PATCH v4 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics

[Kai-Heng Feng]

Some Dell platforms (Preicsion 7510/7710/7520/7720) have a BIOS option
"Switchable Graphics" (SG).

When SG is enabled, we have:
00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04)
00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.  [AMD/ATI] 
Ellesmere [Polaris10]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon 
RX 580]

The Intel Audio outputs all the sound, including HDMI audio. The audio
controller comes with AMD graphics doesn't get used.

When SG is disabled, we have:
00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.  [AMD/ATI] 
Ellesmere [Polaris10]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon 
RX 580]

Now it's a typical discrete-only system. HDMI audio comes from AMD audio
controller, others from Intel audio controller.

When SG is enabled, the unused AMD audio contoller still exposes its
sysfs, so userspace still opens the control file and stream. If
userspace tries to output sound through the stream, it hangs the system.

Since the discrete audio controller isn't useful when SG is enabled, we
should just disable the device.

Signed-off-by: Kai-Heng Feng 
---
v4: Change the commit message to clarify there's no more runtime pm
warning.
Also skip the check for thunderbolt attached devices.

v3: Simplify dell_switchable_gfx_is_enabled() by returning bool instead
of error code.
Use DMI_DEV_TYPE_OEM_STRING to match Dell System.

v2: Mario suggested to squash the HDA part into the same series.

 sound/pci/hda/hda_intel.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 7a111a1b5836..3981193c8d29 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -49,6 +49,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_X86
 /* for snoop control */
@@ -1627,6 +1629,42 @@ static void check_msi(struct azx *chip)
}
 }
 
+#if IS_ENABLED(CONFIG_DELL_LAPTOP)
+static bool check_dell_switchable_gfx(struct pci_dev *pdev)
+{
+   bool (*dell_switchable_gfx_is_enabled_func)(void);
+   bool enabled;
+
+   /* Thunderbolt devices won't be switchable */
+   if (pci_is_thunderbolt_attached(pdev))
+   return false;
+
+   /* Only check for Dell laptops and AIOs */
+   if (!dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "Dell System", NULL) ||
+   !(dmi_match(DMI_CHASSIS_TYPE, "10") ||
+ dmi_match(DMI_CHASSIS_TYPE, "13")) ||
+   !(pdev->vendor == PCI_VENDOR_ID_ATI ||
+ pdev->vendor == PCI_VENDOR_ID_NVIDIA))
+   return false;
+
+   dell_switchable_gfx_is_enabled_func =
+   symbol_request(dell_switchable_gfx_is_enabled);
+   if (!dell_switchable_gfx_is_enabled_func)
+   return false;
+
+   enabled = dell_switchable_gfx_is_enabled_func();
+
+   symbol_put(dell_switchable_gfx_is_enabled);
+
+   return enabled;
+}
+#else
+static bool check_dell_switchable_gfx(struct pci_dev *pdev)
+{
+   return false;
+}
+#endif
+
 /* check the snoop mode availability */
 static void azx_check_snoop_available(struct azx *chip)
 {
@@ -1709,6 +1747,11 @@ static int azx_create(struct snd_card *card, struct 
pci_dev *pci,
if (err < 0)
return err;
 
+   if (check_dell_switchable_gfx(pci)) {
+   pci_disable_device(pci);
+   return -ENODEV;
+   }
+
hda = kzalloc(sizeof(*hda), GFP_KERNEL);
if (!hda) {
pci_disable_device(pci);
-- 
2.17.0

[PATCH v4 2/3] platform/x86: dell-*: Add interface for switchable graphics status query

[Kai-Heng Feng]

On some Dell platforms, there's a BIOS option "Enable Switchable
Graphics". This information is useful if we want to do different things
based on this value, e.g. disable unused audio controller that comes
with the discrete graphics.

Cc: Mario Limonciello 
Signed-off-by: Kai-Heng Feng 
---
v4: Change the commit message to clarify there's no more runtime pm
warning.
Also skip the check for thunderbolt attached devices.

v3: Simplify dell_switchable_gfx_is_enabled() by returning bool instead
of error code.
Use DMI_DEV_TYPE_OEM_STRING to match Dell System.

v2: Mario suggested to squash the HDA part into the same series.

 drivers/platform/x86/dell-laptop.c  | 17 +
 drivers/platform/x86/dell-smbios-base.c |  2 ++
 drivers/platform/x86/dell-smbios.h  |  2 ++
 include/linux/dell-common.h |  1 +
 4 files changed, 22 insertions(+)

diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index 8ba820e6c3d0..033a27b190cc 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -2116,6 +2116,23 @@ int dell_micmute_led_set(int state)
 }
 EXPORT_SYMBOL_GPL(dell_micmute_led_set);
 
+bool dell_switchable_gfx_is_enabled(void)
+{
+   struct calling_interface_buffer buffer;
+   struct calling_interface_token *token;
+
+   token = dell_smbios_find_token(SWITCHABLE_GRAPHICS_ENABLE);
+   if (!token)
+   return false;
+
+   dell_fill_request(, token->location, 0, 0, 0);
+   if (dell_send_request(, CLASS_TOKEN_READ, SELECT_TOKEN_STD))
+   return false;
+
+   return !!buffer.output[1];
+}
+EXPORT_SYMBOL_GPL(dell_switchable_gfx_is_enabled);
+
 static int __init dell_init(void)
 {
struct calling_interface_token *token;
diff --git a/drivers/platform/x86/dell-smbios-base.c 
b/drivers/platform/x86/dell-smbios-base.c
index 33fb2a20458a..881ce42f0ca7 100644
--- a/drivers/platform/x86/dell-smbios-base.c
+++ b/drivers/platform/x86/dell-smbios-base.c
@@ -86,6 +86,8 @@ struct token_range {
 static struct token_range token_whitelist[] = {
/* used by userspace: fwupdate */
{CAP_SYS_ADMIN, CAPSULE_EN_TOKEN,   CAPSULE_DIS_TOKEN},
+   /* can indicate to userspace Switchable Graphics enable status */
+   {CAP_SYS_ADMIN, SWITCHABLE_GRAPHICS_ENABLE, 
SWITCHABLE_GRAPHICS_DISABLE},
/* can indicate to userspace that WMI is needed */
{0x,WSMT_EN_TOKEN,  WSMT_DIS_TOKEN}
 };
diff --git a/drivers/platform/x86/dell-smbios.h 
b/drivers/platform/x86/dell-smbios.h
index d8adaf959740..7863e6a7cff8 100644
--- a/drivers/platform/x86/dell-smbios.h
+++ b/drivers/platform/x86/dell-smbios.h
@@ -37,6 +37,8 @@
 #define KBD_LED_AUTO_100_TOKEN 0x02F6
 #define GLOBAL_MIC_MUTE_ENABLE 0x0364
 #define GLOBAL_MIC_MUTE_DISABLE0x0365
+#define SWITCHABLE_GRAPHICS_ENABLE 0x037A
+#define SWITCHABLE_GRAPHICS_DISABLE0x037B
 
 struct notifier_block;
 
diff --git a/include/linux/dell-common.h b/include/linux/dell-common.h
index 37e4b614dd74..1a90bc9a3bea 100644
--- a/include/linux/dell-common.h
+++ b/include/linux/dell-common.h
@@ -3,5 +3,6 @@
 #define __DELL_COMMON_H__
 
 int dell_micmute_led_set(int on);
+bool dell_switchable_gfx_is_enabled(void);
 
 #endif
-- 
2.17.0

Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays

[Tomi Valkeinen]

Hi Sebastian,

On 30/03/18 20:18, Sebastian Reichel wrote:
> This adds the required infrastructure for manually
> updated displays, such as DSI command mode panels.
> 
> While those panels often support partial updates
> we currently always do a full refresh. Display
> will be refreshed when something calls the dirty
> callback, such as libdrm's drmModeDirtyFB().
> 
> This is currently being implemented for the kernel
> console and for Xorg. Weston currently does not
> implement this and is known not to work on manually
> updated displays.
> 
> Tested-by: Tony Lindgren 
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 107 
> +---
>  drivers/gpu/drm/omapdrm/omap_crtc.h |   1 +
>  drivers/gpu/drm/omapdrm/omap_fb.c   |  20 +++
>  3 files changed, 120 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index b893985e4efb..1b91bff5bac6 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -51,6 +51,7 @@ struct omap_crtc {
>   bool pending;
>   wait_queue_head_t pending_wait;
>   struct drm_pending_vblank_event *event;
> + struct delayed_work update_work;
>  
>   void (*framedone_handler)(void *);
>   void *framedone_handler_data;
> @@ -146,6 +147,25 @@ static void omap_crtc_dss_disconnect(struct 
> omap_drm_private *priv,
>  static void omap_crtc_dss_start_update(struct omap_drm_private *priv,
>  enum omap_channel channel)
>  {
> + priv->dispc_ops->mgr_enable(priv->dispc, channel, true);
> +}
> +
> +static bool omap_crtc_is_manually_updated(struct drm_crtc *crtc)
> +{
> + struct drm_connector *connector;
> + struct drm_connector_list_iter conn_iter;
> + bool result = false;
> +
> + drm_connector_list_iter_begin(crtc->dev, _iter);
> + drm_for_each_connector_iter(connector, _iter) {
> + if (connector->state->crtc != crtc)
> + continue;
> + result = omap_connector_get_manually_updated(connector);
> + break;
> + }
> + drm_connector_list_iter_end(_iter);

It would be much nicer if the is-manual flag was somehow conveyed from
connector/encoder to the crtc when doing modesetting. I don't know how
or where, so just thinking out loud. However, if we need to do such loop
as above, I think we should just do it once, perhaps in
omap_crtc_atomic_enable, and store the value in omap_crtc's private data.

> +
> + return result;
>  }
>  
>  /* Called only from the encoder enable/disable and suspend/resume handlers. 
> */
> @@ -157,12 +177,17 @@ static void omap_crtc_set_enabled(struct drm_crtc 
> *crtc, bool enable)
>   enum omap_channel channel = omap_crtc->channel;
>   struct omap_irq_wait *wait;
>   u32 framedone_irq, vsync_irq;
> + bool is_manual = omap_crtc_is_manually_updated(crtc);
> + enum omap_display_type type = omap_crtc_output[channel]->output_type;
>   int ret;
>  
>   if (WARN_ON(omap_crtc->enabled == enable))
>   return;
>  
> - if (omap_crtc_output[channel]->output_type == OMAP_DISPLAY_TYPE_HDMI) {
> + if (is_manual)
> + omap_irq_enable_framedone(crtc, enable);
> +
> + if (is_manual || type == OMAP_DISPLAY_TYPE_HDMI) {
>   priv->dispc_ops->mgr_enable(priv->dispc, channel, enable);
>   omap_crtc->enabled = enable;
>   return;

This doesn't look correct, omap_crtc_dss_start_update() already sets the
enable bit for manual update displays. And you don't want to set the
enable to false with manual update displays.

HDMI handling here is already a special case due to HW issues, so I'd
rather see the manual update handled separately from the HDMI.

> @@ -214,7 +239,6 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
> bool enable)
>   }
>  }
>  
> -
>  static int omap_crtc_dss_enable(struct omap_drm_private *priv,
>   enum omap_channel channel)
>  {
> @@ -378,6 +402,53 @@ void omap_crtc_framedone_irq(struct drm_crtc *crtc, 
> uint32_t irqstatus)
>   wake_up(_crtc->pending_wait);
>  }
>  
> +void omap_crtc_flush(struct drm_crtc *crtc)
> +{
> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> +
> + if (!omap_crtc_is_manually_updated(crtc))
> + return;
> +
> + if (!delayed_work_pending(_crtc->update_work))
> + schedule_delayed_work(_crtc->update_work, 0);
> +}

Why delayed work here?

It's actually not quite clear to me how manual update displays work with
DRM...

As far as I see, we have essentially two cases: 1) single buffering,
where the userspace must set an area in the fb dirty, which then
triggers the update, 2) multi buffering, which doesn't need fb dirty,
but just a page flip which triggers the update.

In the 2) case (which I think is the 

Re: [PATCH v2] mmc: sdhci-cadence: fix logically and structurally dead code

[Ulf Hansson]

On 19 April 2018 at 17:59, Gustavo A. R. Silva  wrote:
> Currently, the code block inside the for loop will never execute
> more than once, because the function returns inmediately after
> the first iteration, hence the execution of the code at the second
> iteration is structurally dead and, code at line 281: return 0; is
> never reached.
>
> Fix this by checking _ret_ before return.
>
> Addresses-Coverity-ID: 1468009 ("Logically dead code")
> Addresses-Coverity-ID: 1468002 ("Structurally dead code")
> Suggested-by: Masahiro Yamada 
> Signed-off-by: Gustavo A. R. Silva 

Thanks, applied for next and by fixing the minor spelling mistake in
the changelog.

Kind regards
Uffe

> ---
> Changes in v2:
>  - Update changelog.
>  - Drop the 'Fixes' tag.
>  - Add check on ret instead of removing the "return ret;" line.
>  - Thanks to Masahiro Yamada for the feedback provided.
>
>  drivers/mmc/host/sdhci-cadence.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-cadence.c 
> b/drivers/mmc/host/sdhci-cadence.c
> index bc30d16..7a343b8 100644
> --- a/drivers/mmc/host/sdhci-cadence.c
> +++ b/drivers/mmc/host/sdhci-cadence.c
> @@ -274,8 +274,8 @@ static int sdhci_cdns_set_tune_val(struct sdhci_host 
> *host, unsigned int val)
> ret = readl_poll_timeout(reg, tmp,
>  !(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
>  0, 1);
> -
> -   return ret;
> +   if (ret)
> +   return ret;
> }
>
> return 0;
> --
> 2.7.4
>