Re: [PATCH v2] iio:dac:ti-dac7612: Add driver for Texas Instruments DAC7612

[Ricardo Ribalda Delgado]

Hi Jonathan

On Sun, Jan 27, 2019 at 4:04 PM Jonathan Cameron  wrote:
>
> On Sat, 26 Jan 2019 22:34:50 +0100
> Ricardo Ribalda Delgado  wrote:
>
> > HI Jonathan
> >
> > Thanks for your review. I will make the changes and send it back to
> > you after testing it on Monday on real hardware.
> >
> > Until then I have pushed my changes to
> > https://github.com/ribalda/linux/tree/ribalda-iio-v3 in case you want
> > to see it before I send it to the list.
> > (I am still missing the dt-bindings)
> >
> > Some comments inline.
> Replies inline.
>
> >
> > Best regards!
> >
> > On Sat, Jan 26, 2019 at 9:42 PM Jonathan Cameron  wrote:
> > >
> > > On Fri, 25 Jan 2019 11:00:55 +0100
> > > Ricardo Ribalda Delgado  wrote:
> > >
> > > > It is a driver for Texas Instruments Dual, 12-Bit Serial Input
> > > > Digital-to-Analog Converter.
> > > >
> > > > Datasheet of this chip:
> > > > http://www.ti.com/lit/ds/sbas106/sbas106.pdf
> > > >
> > > > Signed-off-by: Ricardo Ribalda Delgado 
> > > Hi Ricardo,
> > >
> > > Various bits and pieces inline.
> > >
> > > Jonathan
> > >
> > > > ---
> > > >
> > > > v2: Fix range
> > > >  MAINTAINERS  |   6 ++
> > > >  drivers/iio/dac/Kconfig  |  10 +++
> > > >  drivers/iio/dac/Makefile |   1 +
> > > >  drivers/iio/dac/ti-dac7612.c | 169 +++
> > > >  4 files changed, 186 insertions(+)
> > > >  create mode 100644 drivers/iio/dac/ti-dac7612.c
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index d039f66a5cef..30ba5435906b 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -14877,6 +14877,12 @@ F:   
> > > > Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> > > >  F:   drivers/clk/keystone/sci-clk.c
> > > >  F:   drivers/reset/reset-ti-sci.c
> > > >
> > > > +Texas Instruments' DAC7612 DAC Driver
> > > > +M:   Ricardo Ribalda 
> > > > +L:   linux-...@vger.kernel.org
> > > > +S:   Supported
> > > > +F:   drivers/iio/dac/ti-dac7612.c
> > > > +
> > > >  THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
> > > >  M:   Hans Verkuil 
> > > >  L:   linux-me...@vger.kernel.org
> > > > diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> > > > index f28daf67db6a..fbef9107acad 100644
> > > > --- a/drivers/iio/dac/Kconfig
> > > > +++ b/drivers/iio/dac/Kconfig
> > > > @@ -375,6 +375,16 @@ config TI_DAC7311
> > > >
> > > > If compiled as a module, it will be called ti-dac7311.
> > > >
> > > > +config TI_DAC7612
> > > > + tristate "Texas Instruments 12-bit 2-channel DAC driver"
> > > > + depends on SPI_MASTER && GPIOLIB
> > > > + help
> > > > +   Driver for the Texas Instruments DAC7612, DAC7612U, DAC7612UB
> > > > +   The driver hand drive the load pin automatically, otherwise
> > > > +   it needs to be toggled manually.
> > >
> > > Given the driver doesn't load without that pin, do we need to give
> > > the otherwise?  I would drop this comment entirely.
> >
> > I am probing the gpio with devm_gpiod_get_optional() so the driver can
> > load without the pin
> Hmm. I thought that would blow up when you tried to set the output but
> it seems not as the gpiod function just returns without doing anything.
>
> So is this a an actual usecase you have?  My inclination would be to just
> make it non optional otherwise.  The thought of relying on a random pulse
> from another device doesn't seem like a good idea to me.

I am thinking on a usecase where both voltages need to be set at the
same time or on sync with an external event.
This is how our board was designed 6 years ago: http://ge.tt/28oRQCu2

But, up to date no one is using it that way :).

All that said, the only change to support that usecase is to use the
_optional() function, that does not affect the
readability of the code. But if it is a showstopper for you I will
remove it and make the gpio "mandatory"

Thanks and best regatrds!


>
> >
> > >
> > > > +
> > > > +   If compiled as a module, it will be called ti-dac7612.
> > > > +
> > > >  config VF610_DAC
> > > >   tristate "Vybrid vf610 DAC driver"
> > > >   depends on OF
> > > > diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> > > > index f0a37c93de8e..1369fa1d2f0e 100644
> > > > --- a/drivers/iio/dac/Makefile
> > > > +++ b/drivers/iio/dac/Makefile
> > > > @@ -41,4 +41,5 @@ obj-$(CONFIG_STM32_DAC) += stm32-dac.o
> > > >  obj-$(CONFIG_TI_DAC082S085) += ti-dac082s085.o
> > > >  obj-$(CONFIG_TI_DAC5571) += ti-dac5571.o
> > > >  obj-$(CONFIG_TI_DAC7311) += ti-dac7311.o
> > > > +obj-$(CONFIG_TI_DAC7612) += ti-dac7612.o
> > > >  obj-$(CONFIG_VF610_DAC) += vf610_dac.o
> > > > diff --git a/drivers/iio/dac/ti-dac7612.c b/drivers/iio/dac/ti-dac7612.c
> > > > new file mode 100644
> > > > index ..278406f69e0c
> > > > --- /dev/null
> > > > +++ b/drivers/iio/dac/ti-dac7612.c
> > > > @@ -0,0 +1,169 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * DAC7612 Dual, 12-Bit Serial input Digital-to-Analog Converter
> > 

Re: [PATCH 4/5] phy: tegra: xusb: Add support for power supplies

[Thierry Reding]

On Mon, Jan 28, 2019 at 03:22:09PM +0800, jckuo wrote:
> Hi Thierry,
> 
> I think any non-zero return value of
> regulator_bulk_enable()/devm_regulator_bulk_get() means error.
> 
> Thanks,
> 
> JC

Theoretically I think only regulator_bulk_enable() could return a
positive value, but even so it never will in practice because all of the
regulator_enable() (see _regulator_enable()) calls will only ever return
negative error codes.

I can change this and resend if you have strong concerns about this
possibly missing legitimate error cases.

Thierry

> On 1/25/19 7:25 PM, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > Support enabling various supplies needed to provide power to the PLLs
> > and logic used to drive the USB, PCI and SATA pads.
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> >   drivers/phy/tegra/xusb.c | 34 +-
> >   drivers/phy/tegra/xusb.h |  5 +
> >   2 files changed, 38 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
> > index 57a2d08ef6da..e510629f4f1c 100644
> > --- a/drivers/phy/tegra/xusb.c
> > +++ b/drivers/phy/tegra/xusb.c
> > @@ -864,6 +864,7 @@ static int tegra_xusb_padctl_probe(struct 
> > platform_device *pdev)
> > struct tegra_xusb_padctl *padctl;
> > const struct of_device_id *match;
> > struct resource *res;
> > +   unsigned int i;
> > int err;
> > /* for backwards compatibility with old device trees */
> > @@ -901,14 +902,38 @@ static int tegra_xusb_padctl_probe(struct 
> > platform_device *pdev)
> > goto remove;
> > }
> > +   padctl->supplies = devm_kcalloc(&pdev->dev, padctl->soc->num_supplies,
> > +   sizeof(*padctl->supplies), GFP_KERNEL);
> > +   if (!padctl->supplies) {
> > +   err = -ENOMEM;
> > +   goto remove;
> > +   }
> > +
> > +   for (i = 0; i < padctl->soc->num_supplies; i++)
> > +   padctl->supplies[i].supply = padctl->soc->supply_names[i];
> > +
> > +   err = devm_regulator_bulk_get(&pdev->dev, padctl->soc->num_supplies,
> > + padctl->supplies);
> > +   if (err < 0) {
> > +   dev_err(&pdev->dev, "failed to get regulators: %d\n", err);
> > +   goto remove;
> > +   }
> > +
> > err = reset_control_deassert(padctl->rst);
> > if (err < 0)
> > goto remove;
> > +   err = regulator_bulk_enable(padctl->soc->num_supplies,
> > +   padctl->supplies);
> > +   if (err < 0) {
> > +   dev_err(&pdev->dev, "failed to enable supplies: %d\n", err);
> > +   goto reset;
> > +   }
> > +
> > err = tegra_xusb_setup_pads(padctl);
> > if (err < 0) {
> > dev_err(&pdev->dev, "failed to setup pads: %d\n", err);
> > -   goto reset;
> > +   goto power_down;
> > }
> > err = tegra_xusb_setup_ports(padctl);
> > @@ -921,6 +946,8 @@ static int tegra_xusb_padctl_probe(struct 
> > platform_device *pdev)
> >   remove_pads:
> > tegra_xusb_remove_pads(padctl);
> > +power_down:
> > +   regulator_bulk_disable(padctl->soc->num_supplies, padctl->supplies);
> >   reset:
> > reset_control_assert(padctl->rst);
> >   remove:
> > @@ -936,6 +963,11 @@ static int tegra_xusb_padctl_remove(struct 
> > platform_device *pdev)
> > tegra_xusb_remove_ports(padctl);
> > tegra_xusb_remove_pads(padctl);
> > +   err = regulator_bulk_disable(padctl->soc->num_supplies,
> > +padctl->supplies);
> > +   if (err < 0)
> > +   dev_err(&pdev->dev, "failed to disable supplies: %d\n", err);
> > +
> > err = reset_control_assert(padctl->rst);
> > if (err < 0)
> > dev_err(&pdev->dev, "failed to assert reset: %d\n", err);
> > diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
> > index bb60fc09c752..5d5d22f6cb41 100644
> > --- a/drivers/phy/tegra/xusb.h
> > +++ b/drivers/phy/tegra/xusb.h
> > @@ -370,6 +370,9 @@ struct tegra_xusb_padctl_soc {
> > } ports;
> > const struct tegra_xusb_padctl_ops *ops;
> > +
> > +   const char * const *supply_names;
> > +   unsigned int num_supplies;
> >   };
> >   struct tegra_xusb_padctl {
> > @@ -393,6 +396,8 @@ struct tegra_xusb_padctl {
> > unsigned int enable;
> > struct clk *clk;
> > +
> > +   struct regulator_bulk_data *supplies;
> >   };
> >   static inline void padctl_writel(struct tegra_xusb_padctl *padctl, u32 
> > value,


signature.asc
Description: PGP signature

Re: [RFC PATCH v2 10/10] watchdog: bd70528: Initial support for ROHM BD70528 watchdog block

[Matti Vaittinen]

On Sat, Jan 26, 2019 at 08:36:14AM -0800, Guenter Roeck wrote:
> On 1/25/19 3:06 AM, Matti Vaittinen wrote:
> > +/* Max time we can set is 1 hour, 59 minutes and 59 seconds */
> > +#define WDT_MAX_MS ((2 * 60 * 60 - 1) * 1000)
> > +/* Minimum time is 1 second */
> > +#define WDT_MIN_MS 1000
> > +#define DEFAULT_TIMEOUT 60
> > +
> > +static int bd70528_wdt_probe(struct platform_device *pdev)
> > +{
> > +   struct bd70528 *bd70528;
> > +   struct wdtbd70528 *w;
> > +   int ret;
> > +   unsigned int reg;
> > +   struct watchdog_device *wdt;
> > +
> > +   bd70528 = dev_get_drvdata(pdev->dev.parent);
> > +   if (!bd70528) {
> > +   dev_err(&pdev->dev, "No MFD driver data\n");
> > +   return -EINVAL;
> > +   }
> > +   w = devm_kzalloc(&pdev->dev, sizeof(*w), GFP_KERNEL);
> > +   if (!w)
> > +   return -ENOMEM;
> > +   w->bd = bd70528;
> 
> Unless I am missing something, only the mutex and the regmap pointer
> are used from struct bd70528. With that in mind, it might be desirable
> to copy those pointers to struct wdtbd70528 to avoid the additional
> dereferencing at runtime.

You are not missing anyting. If we ever add support for another PMIC
variant we will probably be using also the chip_type. Untill then only
the mutex and regmap. (And maybe the of_node if we have any RTC
properties in DT). So at this point we just use regmap and mutex. I will
change this.

> > +   w->dev = &pdev->dev;
> > +
> > +   wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
> > +   if (!wdt)
> > +   return -ENOMEM;
> > +
> 
> struct watchdog_device can be part of struct wdtbd70528. Two separate 
> allocations
> are not necessary.

Correct. Thanks for pointing that out. I'll simplify this.

> > +   wdt->info = &bd70528_wdt_info;
> > +   wdt->ops =  &bd70528_wdt_ops;
> > +   wdt->min_hw_heartbeat_ms = WDT_MIN_MS;
> > +   wdt->max_hw_heartbeat_ms = WDT_MAX_MS;
> > +   wdt->parent = pdev->dev.parent;
> > +   wdt->timeout = DEFAULT_TIMEOUT;
> > +   watchdog_set_drvdata(wdt, w);
> > +   watchdog_init_timeout(wdt, 0, pdev->dev.parent);
> > +
> > +   ret = bd70528_wdt_set_timeout(wdt, wdt->timeout);
> > +   if (ret) {
> > +   dev_err(&pdev->dev, "Failed to set the watchdog timeout\n");
> > +   return ret;
> > +   }
> > +
> > +   mutex_lock(&bd70528->rtc_timer_lock);
> > +   ret = regmap_read(bd70528->chip.regmap, BD70528_REG_WDT_CTRL, ®);
> > +   mutex_unlock(&bd70528->rtc_timer_lock);
> > +
> 
> I don't see the point for the above mutex locks. This is just reading a
> single register. regmap itself provides locking for that already.

It has a purpose here - but I'd better add a comment. We want to get the
initial state of WDG here. If the probe is executed when RTC time is being
set we may read the state just when RTC is (temporarily) disabling WDT -
and we might tell the WDT core that WDT is disabled - even if it is
actually enabled. The mutex prevents us from reading the WDT state when
RTC is being set.
 
Br,
Matti Vaittinen

Re: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain

[h...@infradead.org]

On Fri, Jan 25, 2019 at 09:45:26AM +, Peng Fan wrote:
> Just have a question, 
> 
> Since vmalloc_to_page is ok for cma area, no need to take cma and per device
> cma into consideration right? 

The CMA area itself it a physical memory region.  If it is a non-highmem
region you can call virt_to_page on the virtual addresses for it.  If
it is in highmem it doesn't even have a kernel virtual address by
default.

> we only need to implement a piece code to handle per device specific region
> using RESERVEDMEM_OF_DECLARE, just like:
> RESERVEDMEM_OF_DECLARE(rpmsg-dma, "rpmsg-dma-pool", 
> rmem_rpmsg_dma_setup);
> And implement the device_init call back and build a map between page and phys.
> Then in rpmsg driver, scatter list could use page structure, no need 
> vmalloc_to_page
> for per device dma.
> 
> Is this the right way?

I think this should work fine.  If you have the cycles for it I'd
actually love to be able to have generic CMA DT glue for non DMA API
driver allocations, as there obviously is a need for it.  So basically
the same as above, just added to kernel/cma.c as a generic API.

RE: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial

[Guan Yung Tseng]

> On Wed, Jan 23, 2019 at 5:18 PM Andy Shevchenko  
> wrote:
> >
> > On Mon, Jan 14, 2019 at 4:13 PM Guan Yung Tseng  
> > wrote:
> > >
> > > Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> > > The reason of doing this is because all NI multi port serial cards 
> > > use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the 
> > > serial_pci_is_class_communication test added in the commit 
> > > 7d8905d06405
> > > ("serial: 8250_pci: Enable device after we check black list").
> >
> > Guan, can you provide an output of the
> >
> > lspci -nk -xx -vv -s 
> >
> > of your device, where  is a PCI address in a form of 
> > bus:device.function?
>

Output of lspci before applied the patch

admin@NI-PXIe-8840Quad-Core-0308D657:~# lspci -nk -xx -vv -s 0d:0e.0
0d:0e.0 0780: 1093:70e8
Subsystem: 1093:70e8
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping
- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR-  While I'm still wondering of the above, can you also test the bellow patch if 
> it fixes your issue?

The patch fixes the issue. The devices bind to the serial kernel driver 
successfully.
Below is the output of lspci -nk -xx -vv -s  for the same devices after I 
applied the patch.

admin@NI-PXIe-8840Quad-Core-0308D657:~# lspci -nk -xx -vv -s 0d:0e.0
0d:0e.0 0780: 1093:70e8
Subsystem: 1093:70e8
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping
- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- 

Re: [PATCH v1 3/3] drivers/tty: increase priority for tty_buffer_worker

[Oleksij Rempel]

On 10.01.19 17:30, Greg Kroah-Hartman wrote:

On Thu, Jan 10, 2019 at 04:19:53PM +0100, Oleksij Rempel wrote:

My gut feel is that if somebody still cares deeply about serial line
latency, they should look at trying to see if they can do some of the
work directly without the bounce to the workqueue. We use workqueues
for a reason, but it's possible that some of it could be avoided at
least in special cases... And yours sounds like a special case.


It is for industrial low latency RS-422 based application. The loopback
test is just easy way to test/reproduce it without additional hardware.

What is good, mainlineable way to implement it?


What is the real problem your systems are having?  Are they serial-port
limited?  Is latency a big issue?  Trying to tune for a fake workload
isn't the best way to solve anything :)


The system in question is a high power laser cutter with live image-based 
inspection
and adjustment of the cutting process. In this setup the RS422 interface is 
used to
control parameters of the laser cutting unit in a tie control loop with the 
camera.
This loops needs to operate at 1000 Hz.

The xy-stage moves with a speed of approx. 60m/min, i.e. within 1ms it
moves about 1mm. For a high precision control process a jitter of ± 500 us (+/- 
0.5mm)
is unacceptable.

Kind regards,
Oleksij Rempel

--
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

RE: [PATCH] devfreq: Suspend all devices on system shutdown

[MyungJoo Ham]

>This way devfreq core ensures that all its devices will be set to safe
>operation points before reboot operation. There are board on which some
>aggressive power saving operation points are behind the capabilities of
>the bootloader to properly reset the hardware and boot the board. This
>way one can avoid board crash early after reboot.
>
>Similar pattern is used in CPUfreq subsystem.
>
>Reported-by: Markus Reichl 
>Signed-off-by: Marek Szyprowski 
>---

You are invoking ALL devfreq suspend callbacks at shutdown
with this commit.

Can you make it invoke only devices explicitly saying their needs
to handle "SHUTDOWN" event?

For example, we can add a flag at struct devfreq_dev_profile:
"uint32_t requirement"
, where
0x1: need to operate at the initial frequency for suspend
0x2: need to operate at the initial frequency for shutdown
0x4: it forgets its status at resume, reconfigure frequency at resume.
(or reverse 0x1's semantics for the backward compatibility)
...

Cheers,
MyungJoo

Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size

[Christoph Hellwig]

On Thu, Jan 24, 2019 at 10:51:51AM +0100, Joerg Roedel wrote:
> On Thu, Jan 24, 2019 at 09:42:21AM +0100, Christoph Hellwig wrote:
> > Yes.  But more importantly it would fix the limit for all other block
> > drivers that set large segment sizes when running over swiotlb.
> 
> True, so it would be something like the diff below? I havn't worked on
> the block layer, so I don't know if that needs additional checks for
> ->dev or anything.

Looks sensible.  Maybe for now we'll just do the virtio-blk case
that triggered it, and we'll do something like this patch for the
next merge window.  We'll also need to apply the same magic to the
DMA boundary.

RE: [PATCH] KVM: x86: Sync the pending Posted-Interrupts

[Kang, Luwei]

> > Some Posted-Interrupts from passthrough devices may be lost or
> > overwritten when the vCPU is in runnable state.
> >
> > The SN (Suppress Notification) of PID (Posted Interrupt Descriptor)
> > will be set when the vCPU is preempted (vCPU in KVM_MP_STATE_RUNNABLE
> > state but not running on physical CPU). If a posted interrupt coming
> > at this time, the irq remmaping facility will set the bit of PIR
> > (Posted Interrupt Requests) but ON (Outstanding Notification).
> > So this interrupt can't be sync to APIC virtualization register and
> > will not be handled by Guest because ON is zero.
> >
> > Signed-off-by: Luwei Kang 
> > ---
> >  arch/x86/kvm/vmx/vmx.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index
> > f6915f1..820a03b 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -6048,7 +6048,7 @@ static int vmx_sync_pir_to_irr(struct kvm_vcpu *vcpu)
> > bool max_irr_updated;
> >
> > WARN_ON(!vcpu->arch.apicv_active);
> > -   if (pi_test_on(&vmx->pi_desc)) {
> > +   if (!bitmap_empty((unsigned long *)vmx->pi_desc.pir, NR_VECTORS)) {
> > pi_clear_on(&vmx->pi_desc);
> > /*
> >  * IOMMU can write to PIR.ON, so the barrier matters even on UP.
> >
> 
> This is a very delicate path.  The bitmap check here is ordered after the 
> vcpu->mode write in vcpu_enter_guest, matching the check of
> vcpu->mode in vmx_deliver_posted_interrupt (which comes after a write of
> PIR.ON):
> 
>   sender  receiver
>   write PIR
>   write PIR.ONvcpu->mode = IN_GUEST_MODE
>   smp_mb()smp_mb()
>   read vcpu->mode sync_pir_to_irr
> read PIR.ON
> 
> What you did should work, since PIR is written after PIR.ON anyway.

Hi Paolo:
I think what you mentioned PIR.ON here is PID.ON;
PID: Posted Interrupt Descriptor (a structure for PI which include 512 bits)
ON:  Outstanding Notification  (one bit of PID)
PIR:  Posted Interrupt Requests (256 bits for each interrupt vector in PID)

Before VT-d irq remapping, there just have PIR and ON in PID. Posted 
interrupt introduced by APICv can be used for send IPI. The working flow of 
sent a posted interrupt show in vmx_deliver_posted_interrupt().
1. Set PIR of PID
2. Set ON of PID
3. Send a IPI to target vCPU with notification vector (POSTED_INTR_VECTOR) 
if target vCPU is Running on a pCPU; have no vm-exit and handed by guest 
interrupt handler directly.
4. if the target vCPU is not Running on pCPU, invoke kvm_vcpu_kick() to 
wake up this vCPU or send RESCHEDULE_VECTOR IPI to target pCPU to make the vCPU 
running as soon as possible.
5. follow 4. The vCPU prepare to run (vcpu_enter_guest) and sync the posted 
interrupt of ON is set.

It looks like work well. 
VT-d irq remapping facility introduce SN, NV, NDST in PID. These are used 
by irq remapping facility and CPU don’t care these flags.
6. The bit of SN will be set when vCPU id preempted (runnable but not 
running).
 commit 28b835d60fcc2498e717cf5e6f0c3691c24546f7
  KVM: Update Posted-Interrupts Descriptor when vCPU is preempted
7.  if a interrupt coming at this moment, irq remapping facility just set 
PIR but *not* set ON (VT-d spec 9.12).
So, here, the interrupt can't be sync to IRR because ON is 0.

I add some log here and found some interrupt recorded in PIR but ON is 
zero. It will impact the performance of pass through device.

> However, you should at least change the comment in vcpu_enter_guest to 
> mention "before reading PIR" instead of "before reading
> PIR.ON".

Will do that. I think the "checking PIR.ON" should be PID.ON. I will fix it.

> 
> Alternatively, would it be possible to instead set ON when SN is cleared?  
> The clearing of SN is in pi_clear_sn, and you would have instead
> something like

SN is cleared when the corresponding vCPU is running on pCPU. I think we can't 
set ON when SN is cleared.  Because there have some words in VT-d spec 9.12:
If ON is set at the time of hardware posting an interrupt to PIR field, 
notification event is not generated.

> 
>   WRITE_ONCE(u16 *)&pi_desc->on_sn, POSTED_INTR_ON);

We already have a function  (pi_test_on) to check the bit of POSTED_INTR_ON. So 
I think it is unnecessary.

Thanks,
Luwei Kang

> 
> where on_sn is added to struct pi_desc like this:
> 
> @@ -61,4 +60,5 @@ struct pi_desc {
>   u32 ndst;
>   };
> + u16 on_sn;
>   u64 control;
>   };
> 
> Paolo

Re: [PATCH v3 10/23] drm/qxl: move qxl_primary_apply_cursor to correct place

[Gerd Hoffmann]

> > The cursor must be set again after creating the primary surface.
> > Also drop the error message.

> > if (!bo->is_primary) {
> > -   if (!same_shadow)
> > +   if (!same_shadow) {
> > qxl_io_create_primary(qdev, 0, bo);
> > +   qxl_primary_apply_cursor(plane);
> > +   }
> > bo->is_primary = true;
> > }
> >  
> > 
> 
> I don't see how the commit message matches what you're doing. It gives
> the impression that it must be applied under yet another condition, but
> the condition for applying the cursor is changed from bo_old->is_primary
> to !bo->is_primary.

The qxl device ties the cursor to the primary surface.  Therefore
calling qxl_io_destroy_primary() and qxl_io_create_primary() to switch
the framebuffer causes the cursor information being lost and the driver
must re-apply it.

The correct call order to do that is qxl_io_destroy_primary() +
qxl_io_create_primary() + qxl_primary_apply_cursor().

The old code did qxl_io_destroy_primary() + qxl_primary_apply_cursor() +
qxl_io_create_primary().  Due to qxl_primary_apply_cursor request being
queued in a ringbuffer and qxl_io_create_primary() trapping to the
hypervisor instantly there is a high chance that qxl_io_create_primary()
is processed first even with the wrong call order.  But it's racy and
thus not reliable.

> It probably makes sense to someone that knows the driver.

If the above explains things better to you I should probably replace the
commit message with that.

> Acked-by: Noralf Trønnes 

thanks,
  Gerd

Re: [RFC PATCH v2 10/10] watchdog: bd70528: Initial support for ROHM BD70528 watchdog block

[Matti Vaittinen]

On Mon, Jan 28, 2019 at 10:00:35AM +0200, Matti Vaittinen wrote:
> On Sat, Jan 26, 2019 at 08:36:14AM -0800, Guenter Roeck wrote:
> > On 1/25/19 3:06 AM, Matti Vaittinen wrote:
> > > +/* Max time we can set is 1 hour, 59 minutes and 59 seconds */
> > > +#define WDT_MAX_MS ((2 * 60 * 60 - 1) * 1000)
> > > +/* Minimum time is 1 second */
> > > +#define WDT_MIN_MS 1000
> > > +#define DEFAULT_TIMEOUT 60
> > > +
> > > +static int bd70528_wdt_probe(struct platform_device *pdev)
> > > +{
> > > + struct bd70528 *bd70528;
> > > + struct wdtbd70528 *w;
> > > + int ret;
> > > + unsigned int reg;
> > > + struct watchdog_device *wdt;
> > > +
> > > + bd70528 = dev_get_drvdata(pdev->dev.parent);
> > > + if (!bd70528) {
> > > + dev_err(&pdev->dev, "No MFD driver data\n");
> > > + return -EINVAL;
> > > + }
> > > + w = devm_kzalloc(&pdev->dev, sizeof(*w), GFP_KERNEL);
> > > + if (!w)
> > > + return -ENOMEM;
> > > + w->bd = bd70528;
> > 
> > Unless I am missing something, only the mutex and the regmap pointer
> > are used from struct bd70528. With that in mind, it might be desirable
> > to copy those pointers to struct wdtbd70528 to avoid the additional
> > dereferencing at runtime.
> 
> You are not missing anyting. If we ever add support for another PMIC
> variant we will probably be using also the chip_type. Untill then only
> the mutex and regmap. (And maybe the of_node if we have any RTC
> properties in DT). So at this point we just use regmap and mutex. I will
> change this.

Oh, but actually we are also using the WDT state setting function
provided by MFD. And this is taking the struct bd70528 as parameter. So
maybe we can keep it like this afterall? 

> 
> > > + w->dev = &pdev->dev;
> > > +
> > > + wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
> > > + if (!wdt)
> > > + return -ENOMEM;
> > > +
> > 
> > struct watchdog_device can be part of struct wdtbd70528. Two separate 
> > allocations
> > are not necessary.
> 
> Correct. Thanks for pointing that out. I'll simplify this.
> 
> > > + wdt->info = &bd70528_wdt_info;
> > > + wdt->ops =  &bd70528_wdt_ops;
> > > + wdt->min_hw_heartbeat_ms = WDT_MIN_MS;
> > > + wdt->max_hw_heartbeat_ms = WDT_MAX_MS;
> > > + wdt->parent = pdev->dev.parent;
> > > + wdt->timeout = DEFAULT_TIMEOUT;
> > > + watchdog_set_drvdata(wdt, w);
> > > + watchdog_init_timeout(wdt, 0, pdev->dev.parent);
> > > +
> > > + ret = bd70528_wdt_set_timeout(wdt, wdt->timeout);
> > > + if (ret) {
> > > + dev_err(&pdev->dev, "Failed to set the watchdog timeout\n");
> > > + return ret;
> > > + }
> > > +
> > > + mutex_lock(&bd70528->rtc_timer_lock);
> > > + ret = regmap_read(bd70528->chip.regmap, BD70528_REG_WDT_CTRL, ®);
> > > + mutex_unlock(&bd70528->rtc_timer_lock);
> > > +
> > 
> > I don't see the point for the above mutex locks. This is just reading a
> > single register. regmap itself provides locking for that already.
> 
> It has a purpose here - but I'd better add a comment. We want to get the
> initial state of WDG here. If the probe is executed when RTC time is being
> set we may read the state just when RTC is (temporarily) disabling WDT -
> and we might tell the WDT core that WDT is disabled - even if it is
> actually enabled. The mutex prevents us from reading the WDT state when
> RTC is being set.
>  
> Br,
>   Matti Vaittinen

Re: [PATCH v5 0/4] Reduce NUMA related overhead in perf record profiling on large server systems

[Jiri Olsa]

On Mon, Jan 28, 2019 at 10:13:20AM +0300, Alexey Budankov wrote:

SNIP

> > ---
> > Alexey Budankov (4):
> >   perf record: allocate affinity masks
> >   perf record: bind the AIO user space buffers to nodes
> >   perf record: apply affinity masks when reading mmap buffers
> >   perf record: implement --affinity=node|cpu option
> > 
> >  tools/perf/Documentation/perf-record.txt |   5 ++
> >  tools/perf/builtin-record.c  |  45 +-
> >  tools/perf/perf.h|   8 ++
> >  tools/perf/util/cpumap.c |  10 +++
> >  tools/perf/util/cpumap.h |   1 +
> >  tools/perf/util/evlist.c |   6 +-
> >  tools/perf/util/evlist.h |   2 +-
> >  tools/perf/util/mmap.c   | 105 ++-
> >  tools/perf/util/mmap.h   |   3 +-
> >  9 files changed, 175 insertions(+), 10 deletions(-)
> > 
> > ---
> > Changes in v5:
> > - avoided multiple allocations of online cpu maps by 
> >   implementing it once in cpu_map__online()
> > - reduced indentation at record__parse_affinity()
> 
> Are there any more comments on this patch set?

sry for late reply.. there was a mayhem in here
last week because of the devconf ;-)

I'll review it today, but I think there were no more issues

jirka

Re: [PATCH] regulator: mcp16502: Include linux/gpio/consumer.h to fix build error

[Nicolas.Ferre]

On 27/01/2019 at 09:51, Axel Lin wrote:
> Fix below build error:
> drivers/regulator/mcp16502.c: In function ‘mcp16502_gpio_set_mode’:
> drivers/regulator/mcp16502.c:135:3: error: implicit declaration of function 
> ‘gpiod_set_value’; did you mean ‘gpio_set_value’? 
> [-Werror=implicit-function-declaration]
> gpiod_set_value(mcp->lpm, 0);
> ^~~
> gpio_set_value
> drivers/regulator/mcp16502.c: In function ‘mcp16502_probe’:
> drivers/regulator/mcp16502.c:486:13: error: implicit declaration of function 
> ‘devm_gpiod_get’; did you mean ‘devm_gpio_free’? 
> [-Werror=implicit-function-declaration]
>mcp->lpm = devm_gpiod_get(dev, "lpm", GPIOD_OUT_LOW);
>   ^~
>   devm_gpio_free
> drivers/regulator/mcp16502.c:486:40: error: ‘GPIOD_OUT_LOW’ undeclared (first 
> use in this function); did you mean ‘GPIOF_INIT_LOW’?
>mcp->lpm = devm_gpiod_get(dev, "lpm", GPIOD_OUT_LOW);
>  ^
>  GPIOF_INIT_LOW
> 
> Signed-off-by: Axel Lin 

Acked-by: Nicolas Ferre 

Thanks Alex!

> ---
>   drivers/regulator/mcp16502.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/regulator/mcp16502.c b/drivers/regulator/mcp16502.c
> index 3479ae009b0b..0fc4963bd5b0 100644
> --- a/drivers/regulator/mcp16502.c
> +++ b/drivers/regulator/mcp16502.c
> @@ -17,6 +17,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   #define VDD_LOW_SEL 0x0D
>   #define VDD_HIGH_SEL 0x3F
> 


-- 
Nicolas Ferre

Re: [PATCH] net: wireless: prefix header search paths with $(srctree)/

[Kalle Valo]

Masahiro Yamada  writes:

> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> that way, but not all. The goal of this work is to make the notation
> consistent, and finally get rid of the gross hacks.
>
> Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> ("kbuild: do not drop -I without parameter").
>
> I also removed one header search path in:
>
>   drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile
>
> I was able to compile without it.
>
> [1]: https://patchwork.kernel.org/patch/9632347/
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 4 ++--
>  drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 6 +++---
>  drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile | 4 +---
>  drivers/net/wireless/intel/iwlwifi/dvm/Makefile   | 2 +-
>  drivers/net/wireless/intel/iwlwifi/mvm/Makefile   | 2 +-
>  drivers/net/wireless/realtek/rtl818x/rtl8180/Makefile | 2 +-
>  drivers/net/wireless/realtek/rtl818x/rtl8187/Makefile | 2 +-
>  7 files changed, 10 insertions(+), 12 deletions(-)

Luca, is it ok if I take this to wireless-drivers-next even though it
touches iwlwifi makefiles?

-- 
Kalle Valo

Re: [PATCH v1 3/3] drivers/tty: increase priority for tty_buffer_worker

[Greg Kroah-Hartman]

On Mon, Jan 28, 2019 at 09:05:30AM +0100, Oleksij Rempel wrote:
> 
> 
> On 10.01.19 17:30, Greg Kroah-Hartman wrote:
> > On Thu, Jan 10, 2019 at 04:19:53PM +0100, Oleksij Rempel wrote:
> > > > My gut feel is that if somebody still cares deeply about serial line
> > > > latency, they should look at trying to see if they can do some of the
> > > > work directly without the bounce to the workqueue. We use workqueues
> > > > for a reason, but it's possible that some of it could be avoided at
> > > > least in special cases... And yours sounds like a special case.
> > > 
> > > It is for industrial low latency RS-422 based application. The loopback
> > > test is just easy way to test/reproduce it without additional hardware.
> > > 
> > > What is good, mainlineable way to implement it?
> > 
> > What is the real problem your systems are having?  Are they serial-port
> > limited?  Is latency a big issue?  Trying to tune for a fake workload
> > isn't the best way to solve anything :)
> 
> The system in question is a high power laser cutter with live image-based 
> inspection
> and adjustment of the cutting process. In this setup the RS422 interface is 
> used to
> control parameters of the laser cutting unit in a tie control loop with the 
> camera.
> This loops needs to operate at 1000 Hz.
> 
> The xy-stage moves with a speed of approx. 60m/min, i.e. within 1ms it
> moves about 1mm. For a high precision control process a jitter of ± 500 us 
> (+/- 0.5mm)
> is unacceptable.

Are you using the rt kernel patch for this type of thing?  That should
bound your jitter at a much more deterministic level.

thanks,

greg k-h

Re: [PATCH] net: wireless: prefix header search paths with $(srctree)/

[Luca Coelho]

On Mon, 2019-01-28 at 10:21 +0200, Kalle Valo wrote:
> Masahiro Yamada  writes:
> 
> > Currently, the Kbuild core manipulates header search paths in a
> > crazy
> > way [1].
> > 
> > To fix this mess, I want all Makefiles to add explicit $(srctree)/
> > to
> > the search paths in the srctree. Some Makefiles are already written
> > in
> > that way, but not all. The goal of this work is to make the
> > notation
> > consistent, and finally get rid of the gross hacks.
> > 
> > Having whitespaces after -I does not matter since commit
> > 48f6e3cf5bc6
> > ("kbuild: do not drop -I without parameter").
> > 
> > I also removed one header search path in:
> > 
> >   drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile
> > 
> > I was able to compile without it.
> > 
> > [1]: https://patchwork.kernel.org/patch/9632347/
> > 
> > Signed-off-by: Masahiro Yamada 
> > ---
> > 
> >  drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 4 ++--
> >  drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 6 +++-
> > --
> >  drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile | 4 +---
> >  drivers/net/wireless/intel/iwlwifi/dvm/Makefile   | 2 +-
> >  drivers/net/wireless/intel/iwlwifi/mvm/Makefile   | 2 +-
> >  drivers/net/wireless/realtek/rtl818x/rtl8180/Makefile | 2 +-
> >  drivers/net/wireless/realtek/rtl818x/rtl8187/Makefile | 2 +-
> >  7 files changed, 10 insertions(+), 12 deletions(-)
> 
> Luca, is it ok if I take this to wireless-drivers-next even though it
> touches iwlwifi makefiles?

Sure, it's much easier like that.

Acked-by: Luca Coelho 

--
Cheers,
Luca.

Re: [PATCH v3 00/16] block: sed-opal: support shadow MBR done flag and write

[David Kozub]

On Sun, 27 Jan 2019, Scott Bauer wrote:


On Tue, Jan 22, 2019 at 11:31:31PM +0100, David Kozub wrote:

David Kozub (8):
  block: sed-opal: fix typos and formatting
  block: sed-opal: close parameter list in cmd_finalize
  block: sed-opal: unify cmd start
  block: sed-opal: unify error handling of responses
  block: sed-opal: reuse response_get_token to decrease code duplication
  block: sed-opal: pass steps via argument rather than via opal_dev
  block: sed-opal: don't repeat opal_discovery0 in each steps array
  block: sed-opal: rename next to execute_steps



You forgot to send 16/16 again in v3. I pulled and tested off your github page.
If you send a v4 or just resend that patch you can add my reviewed-by, as I 
reviewed it
on my tree/from your github.


Hi Scott. Thank you for the review.

W.r.t. the 16th patch: I think I sent it, after all I also see it in 
lore.kernel.org:


https://lore.kernel.org/lkml/1548196307-12987-17-git-send-email-...@linux.fjfi.cvut.cz/

Anyway, if the best way forward is to send v4, I'll do it.

Best regards,
David

Re: [PATCH] x86/speculation: Update TIF_SPEC_IB before ibpb barrier

[Zhenzhong Duan]

On 2019/1/26 2:03, Thomas Gleixner wrote:

On Fri, 25 Jan 2019, Thomas Gleixner wrote:

On Wed, 23 Jan 2019, Thomas Gleixner wrote:


On Fri, 18 Jan 2019, Zhenzhong Duan wrote:


When a task is set for updating TIF_SPEC_IB throuth SECCOMP by others
and it's scheduled in the first time, a stale TIF_SPEC_IB value is
picked in cond_ibpb(). This is due to TIF_SPEC_IB is updated later at
__switch_to_xtra().

Add an extra call to speculation_ctrl_update_tif() to update it before
IBPB barrier.


Errm. No. It adds that call to speculation_ctrl_update_tif() for every
mm switch, most of the time for nothing.

If at all, and we discussed that before and decided not to worry about it
(because it gets fixed up on the next context switch), then you want to
handle ibpb() from there:


Actually we need to do that. It's not only the scheduled in first
problem. That whole thing might become completely stale in either
direction. Care to whip up a patch?


Bah, nonsense. Brain was clearly still out for lunch and I confused IBPB
and STIBP for a moment. cond_ibpb() is the thing issues in switch_mm() and
that is not leaving a stale MSR around because we only write to it when we
need the barrier. The bit is not stale because the barrier is only issued
with the write. The bit has not to be cleared.

So the only 'issue' what happens is that switch_to() either issues a
barrier too much or misses one. That's really not a problem.


Ok, yes, the purpose of this patch is to avoid the one missed barrier.
Thanks for your reply.

Zhenzhong

Re: KASAN: use-after-free Read in br_mdb_ip_get

[Dmitry Vyukov]

On Sun, Jan 27, 2019 at 10:34 PM Nikolay Aleksandrov
 wrote:
>
> On 27/01/2019 22:26, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:ba6069759381 Merge tag 'mmc-v5.0-rc2' of git://git.kernel...
> > git tree:   upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=17b342c4c0
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
> > dashboard link: https://syzkaller.appspot.com/bug?extid=bc5ab0af2dbf3b0ae897
> > compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> >
> >Unfortunately,I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+bc5ab0af2dbf3b0ae...@syzkaller.appspotmail.com
> >
> > bridge0: port 2(bridge_slave_1) entered blocking state
> > bridge0: port 2(bridge_slave_1) entered forwarding state
> > bridge0: port 1(bridge_slave_0) entered blocking state
> > bridge0: port 1(bridge_slave_0) entered forwarding state
> > ==
> > BUG: KASAN: use-after-free in memcmp+0xb3/0xc0 lib/string.c:862
> > Read of size 1 at addr 88809f1efe70 by task syz-executor1/8111
> >
> [snip]
> >
> >Allocated by task 8111:
> >  save_stack+0x45/0xd0 mm/kasan/common.c:73
> >  set_track mm/kasan/common.c:85 [inline]
> >  __kasan_kmalloc mm/kasan/common.c:496 [inline]
> >  __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
> >  kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504
> >  kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609
> >  kmalloc include/linux/slab.h:545 [inline]
> >  kzalloc include/linux/slab.h:740 [inline]
> >  br_multicast_new_group.part.0+0xdc/0x1a40 net/bridge/br_multicast.c:476
> >  br_multicast_new_group+0x19d/0x200 net/bridge/br_multicast.c:471
> >  br_multicast_add_group+0x4ce/0x7d0 net/bridge/br_multicast.c:552
> >br_ip6_multicast_add_group net/bridge/br_multicast.c:626 [inline]
> >  br_ip6_multicast_mld2_report net/bridge/br_multicast.c:1043 [inline]
> >  br_multicast_ipv6_rcv net/bridge/br_multicast.c:1667 [inline]
> >  br_multicast_rcv+0x24aa/0x4270 net/bridge/br_multicast.c:1705
> >  br_dev_xmit+0x7f4/0x1780 net/bridge/br_device.c:93
> >  __netdev_start_xmit include/linux/netdevice.h:4382 [inline]
> >  netdev_start_xmit include/linux/netdevice.h:4391 [inline]
> >  xmit_one net/core/dev.c:3278 [inline]
> >  dev_hard_start_xmit+0x261/0xc70 net/core/dev.c:3294
> >  __dev_queue_xmit+0x2f8a/0x3a60 net/core/dev.c:3864
> >  dev_queue_xmit+0x18/0x20 net/core/dev.c:3897
> >  neigh_resolve_output net/core/neighbour.c:1476 [inline]
> >  neigh_resolve_output+0x6a0/0xb30 net/core/neighbour.c:1456
> >  neigh_output include/net/neighbour.h:508 [inline]
> >  ip6_finish_output2+0xc56/0x28e0 net/ipv6/ip6_output.c:120
> >  ip6_finish_output+0x577/0xc30 net/ipv6/ip6_output.c:154
> >  NF_HOOK_COND include/linux/netfilter.h:278 [inline]
> >  ip6_output+0x23c/0xa00 net/ipv6/ip6_output.c:171
> >  dst_output include/net/dst.h:444 [inline]
> >  NF_HOOK include/linux/netfilter.h:289 [inline]
> >  NF_HOOK include/linux/netfilter.h:283 [inline]
> >  mld_sendpack+0xa44/0xfd0 net/ipv6/mcast.c:1683
> >  mld_send_cr net/ipv6/mcast.c:1979 [inline]
> >  mld_ifc_timer_expire+0x449/0x8a0 net/ipv6/mcast.c:2478
> >  call_timer_fn+0x254/0x900 kernel/time/timer.c:1325
> >  expire_timers kernel/time/timer.c:1362 [inline]
> >  __run_timers+0x6fc/0xd50 kernel/time/timer.c:1681
> >  run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1694
> >  __do_softirq+0x30b/0xb11 kernel/softirq.c:292
> >
> > Freed by task 8111:
> >  save_stack+0x45/0xd0 mm/kasan/common.c:73
> >  set_track mm/kasan/common.c:85 [inline]
> >  __kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
> >  kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
> >  __cache_free mm/slab.c:3487 [inline]
> >  kfree+0xcf/0x230 mm/slab.c:3806
> >  br_multicast_new_group.part.0+0x1489/0x1a40 net/bridge/br_multicast.c:486
>
>
> Weird, this is the kfree() on the error path of br_multicast_new_group()
> when rhashtable_lookup_insert_fast() fails, which means the entry should
> not be linked in the rhashtable or the hlist.
> All other frees are via kfree_rcu. I'll keep looking..

Humm +rhashtable.c maintianers

The code in br_multicast_new_group is effectively:

mp = kzalloc(sizeof(*mp), GFP_ATOMIC);
err = rhashtable_lookup_insert_fast(&br->mdb_hash_tbl, &mp->rhnode,
br_mdb_rht_params);
if (err)
kfree(mp);

So it looks like rhashtable_lookup_insert_fast both returned an error
and left the new object linked in the table. Since it happened only
once, it may have something to do with concurrent resizing/shrinking.


> >  br_multicast_new_group+0x19d/0x200 net/bridge/br_multicast.c:471
> >  br_multicast_add_group+0x4ce/0x7d0 net/bridge/br_multicast.c:552
> >  br_ip6_multicast_add_group net/bridge/br_multicast.c:626 [inline]
> >  br_ip6_multicast_mld2_report net/bridge/br_multicast.c:1043 [inline]
> >  br_multicast_ipv6_rcv net/bridge/b

Re: [PATCH v4 2/9] cpufreq: Auto-register the driver as a thermal cooling device if asked

[Daniel Lezcano]

On 28/01/2019 07:41, Amit Kucheria wrote:
> All cpufreq drivers do similar things to register as a cooling device.
> Provide a cpufreq driver flag so drivers can just ask the cpufreq core
> to register the cooling device on their behalf. This allows us to get
> rid of duplicated code in the drivers.
> 
> In order to allow this, we add a struct thermal_cooling_device pointer
> to struct cpufreq_policy so that drivers don't need to store it in a
> private data structure.
> 
> Suggested-by: Stephen Boyd 
> Suggested-by: Viresh Kumar 
> Signed-off-by: Amit Kucheria 
> Reviewed-by: Matthias Kaehlcke 
> Tested-by: Matthias Kaehlcke 
> ---

Reviewed-by: Daniel Lezcano 



>  drivers/cpufreq/cpufreq.c | 9 +
>  include/linux/cpufreq.h   | 9 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index e35a886e00bc..29ed78b0b77b 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -19,6 +19,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1318,6 +1319,9 @@ static int cpufreq_online(unsigned int cpu)
>   if (cpufreq_driver->ready)
>   cpufreq_driver->ready(policy);
>  
> + if (cpufreq_driver->flags & CPUFREQ_AUTO_REGISTER_COOLING_DEV)
> + policy->cdev = of_cpufreq_cooling_register(policy);
> +
>   pr_debug("initialization complete\n");
>  
>   return 0;
> @@ -1405,6 +1409,11 @@ static int cpufreq_offline(unsigned int cpu)
>   goto unlock;
>   }
>  
> + if (cpufreq_driver->flags & CPUFREQ_AUTO_REGISTER_COOLING_DEV) {
> + cpufreq_cooling_unregister(policy->cdev);
> + policy->cdev = NULL;
> + }
> +
>   if (cpufreq_driver->stop_cpu)
>   cpufreq_driver->stop_cpu(policy);
>  
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index bd7fbd6a4478..55ca61a64fc2 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -151,6 +151,9 @@ struct cpufreq_policy {
>  
>   /* For cpufreq driver's internal use */
>   void*driver_data;
> +
> + /* Pointer to the cooling device if used for thermal mitigation */
> + struct thermal_cooling_device *cdev;
>  };
>  
>  /* Only for ACPI */
> @@ -386,6 +389,12 @@ struct cpufreq_driver {
>   */
>  #define CPUFREQ_NO_AUTO_DYNAMIC_SWITCHINGBIT(6)
>  
> +/*
> + * Set by drivers that want the core to automatically register the cpufreq
> + * driver as a thermal cooling device.
> + */
> +#define CPUFREQ_AUTO_REGISTER_COOLING_DEVBIT(7)
> +
>  int cpufreq_register_driver(struct cpufreq_driver *driver_data);
>  int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
>  
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [Xen-devel] [PATCH] arch/arm/xen: Remove duplicate header

[Oleksandr Andrushchenko]

+Boris and Juergen who can also help getting it in

On 1/28/19 8:34 AM, Souptick Joarder wrote:

On Mon, Jan 14, 2019 at 4:08 PM Oleksandr Andrushchenko
 wrote:

On 1/7/19 7:37 PM, Souptick Joarder wrote:

Remove duplicate header which is included twice.

Signed-off-by: Souptick Joarder 

Reviewed-by: Oleksandr Andrushchenko 

Can we get this patch in queue for 5.1 ?

---
   arch/arm/xen/mm.c | 1 -
   1 file changed, 1 deletion(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index cb44aa2..e1d44b9 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -7,7 +7,6 @@
   #include 
   #include 
   #include 
-#include 
   #include 
   #include 

Re: [PATCH] media: ov5640: Fix set 15fps regression

[Jacopo Mondi]

Hi everyone,

On Mon, Jan 28, 2019 at 01:20:37PM +0530, Jagan Teki wrote:
> On Fri, Jan 25, 2019 at 9:10 PM Maxime Ripard  
> wrote:
> >
> > On Thu, Jan 24, 2019 at 11:28:01PM +0530, Jagan Teki wrote:
> > > The ov5640_try_frame_interval operation updates the FPS as per user
> > > input based on default ov5640_frame_rate, OV5640_30_FPS which is failed
> > > to update when user trigger 15fps.
> > >
> > > So, initialize the default ov5640_frame_rate to OV5640_15_FPS so-that
> > > it can satisfy to update all fps.
> > >
> > > Fixes: 5a3ad937bc78 ("media: ov5640: Make the return rate type more 
> > > explicit")
> > > Signed-off-by: Jagan Teki 
> >
> > I'm pretty sure I tested this and it was working fine. You're
> > mentionning a regression, but what regression is there exactly (ie,
> > what was working before that commit that doesn't work anymore?). What
> > tools/commands are you using to see this behaviour?
>

I think Jagan's right, here.

For the 15FPS use case, the below condition in the for loop of
ov5640_try_frame_interval() never gets satisfied (0 < 0 ?) and 'rate' retains
its initial value of 30FPS.

if (abs(curr_fps - fps) < abs(best_fps - fps)) {
best_fps = curr_fps;
rate = i;
}

To make more clear what's happening, I would initialize 'rate' just
before 'best_fps' before the for loop. Anyway, please add:
Acked-by: Jacopo Mondi 

Maxime, does this make sense to you?

Thanks
   j


> In fact I have mentioned this on your v9 [1], may be you missed it.
>
> I have reproduced with media-ctl, below is the full log. let me know
> if I still miss anything.
>
> Before this change:
> # media-ctl -p
> Media controller API version 5.0.0
>
> Media device information
> 
> driver  sun6i-csi
> model   Allwinner Video Capture Device
> serial
> bus info
> hw revision 0x0
> driver version  5.0.0
>
> Device topology
> - entity 1: sun6i-csi (1 pad, 1 link)
> type Node subtype V4L flags 0
> device node name /dev/video0
> pad0: Sink
> <- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]
>
> - entity 5: ov5640 1-003c (1 pad, 1 link)
> type V4L2 subdev subtype Sensor flags 0
> device node name /dev/v4l-subdev0
> pad0: Source
> [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb
> xfer:srgb ycbcr:601 quantization:full-range]
> -> "sun6i-csi":0 [ENABLED,IMMUTABLE]
>
> # media-ctl --set-v4l2 "'ov5640 1-003c':0[fmt:UYVY8_2X8/640x480@1/15 
> field:none]
> "
> # media-ctl -p
> Media controller API version 5.0.0
>
> Media device information
> 
> driver  sun6i-csi
> model   Allwinner Video Capture Device
> serial
> bus info
> hw revision 0x0
> driver version  5.0.0
>
> Device topology
> - entity 1: sun6i-csi (1 pad, 1 link)
> type Node subtype V4L flags 0
> device node name /dev/video0
> pad0: Sink
> <- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]
>
> - entity 5: ov5640 1-003c (1 pad, 1 link)
> type V4L2 subdev subtype Sensor flags 0
> device node name /dev/v4l-subdev0
> pad0: Source
> [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb
> xfer:srgb ycbcr:601 quantization:full-range]
> -> "sun6i-csi":0 [ENABLED,IMMUTABLE]
>
>
> After this change:
> # media-ctl -p
> Media controller API version 5.0.0
>
> Media device information
> 
> driver  sun6i-csi
> model   Allwinner Video Capture Device
> serial
> bus info
> hw revision 0x0
> driver version  5.0.0
>
> Device topology
> - entity 1: sun6i-csi (1 pad, 1 link)
> type Node subtype V4L flags 0
> device node name /dev/video0
> pad0: Sink
> <- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]
>
> - entity 5: ov5640 1-003c (1 pad, 1 link)
> type V4L2 subdev subtype Sensor flags 0
> device node name /dev/v4l-subdev0
> pad0: Source
> [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb
> xfer:srgb ycbcr:601 quantization:full-range]
> -> "sun6i-csi":0 [ENABLED,IMMUTABLE]
>
> # media-ctl --set-v4l2 "'ov5640 1-003c':0[fmt:UYVY8_2X8/640x480@1/15 
> field:none]
> "
> # media-ctl -p
> Media controller API version 5.0.0
>
> Media device information
> 
> driver  sun6i-csi
> model   Allwinner Video Capture Device
> serial
> bus info
> hw revision 0x0
> driver version  5.0.0
>
> Device topology
> - entity 1: sun6i-csi (1 pad, 1 link)
> type Node subtype V4L flags 0
> device node name /dev/video0
> pad0: Sink
> <- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]
>
> - entity 5: ov5640 1-003c (1 pad, 1 link)
> type V4L2 subdev subtype Sensor flags 0
> device node name /dev/v4l-subdev0

Re: [PATCH v4 2/9] cpufreq: Auto-register the driver as a thermal cooling device if asked

[Daniel Lezcano]

On 28/01/2019 07:41, Amit Kucheria wrote:
> All cpufreq drivers do similar things to register as a cooling device.
> Provide a cpufreq driver flag so drivers can just ask the cpufreq core
> to register the cooling device on their behalf. This allows us to get
> rid of duplicated code in the drivers.
> 
> In order to allow this, we add a struct thermal_cooling_device pointer
> to struct cpufreq_policy so that drivers don't need to store it in a
> private data structure.
> 
> Suggested-by: Stephen Boyd 
> Suggested-by: Viresh Kumar 
> Signed-off-by: Amit Kucheria 
> Reviewed-by: Matthias Kaehlcke 
> Tested-by: Matthias Kaehlcke 
> ---

[ ... ]

> +/*
> + * Set by drivers that want the core to automatically register the cpufreq
> + * driver as a thermal cooling device.
> + */
> +#define CPUFREQ_AUTO_REGISTER_COOLING_DEVBIT(7)
> +

Isn't the CPUFREQ_IS_COOLING_DEV more appropriate? We define a property
of the cpufreq driver and the resulting action is to auto-register, no?



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v4 3/9] cpufreq: qcom-hw: Register as a cpufreq cooling device

[Daniel Lezcano]

On 28/01/2019 07:41, Amit Kucheria wrote:
> Add the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow the cpufreq core
> to auto-register the driver as a cooling device.
> 
> Signed-off-by: Amit Kucheria 
> Reviewed-by: Matthias Kaehlcke 
> Tested-by: Matthias Kaehlcke 
> Reviewed-by: Stephen Boyd 

Reviewed-by: Daniel Lezcano 

> ---
>  drivers/cpufreq/qcom-cpufreq-hw.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
> b/drivers/cpufreq/qcom-cpufreq-hw.c
> index d83939a1b3d4..ed32849a3d40 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -231,7 +231,8 @@ static struct freq_attr *qcom_cpufreq_hw_attr[] = {
>  
>  static struct cpufreq_driver cpufreq_qcom_hw_driver = {
>   .flags  = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
> -   CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
> +   CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
> +   CPUFREQ_AUTO_REGISTER_COOLING_DEV,
>   .verify = cpufreq_generic_frequency_table_verify,
>   .target_index   = qcom_cpufreq_hw_target_index,
>   .get= qcom_cpufreq_hw_get,
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v5] arm64: dts: sdm845: add video nodes

[Sibi Sankar]

Hi Malathi,

Bjorn has a patch adding all reserved memory
nodes from version 10 so you can probably drop
the venus_region node from the patch.

https://patchwork.kernel.org/patch/10774869/

On 2019-01-25 13:41, Malathi Gottam wrote:

This adds video nodes to sdm845 based on the examples
in the bindings.

Signed-off-by: Malathi Gottam 
---
Changes:
Added video firmware node
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 38 


 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index b72bdb0..1af68f5 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -87,6 +87,11 @@
reg = <0 0x8620 0 0x2d0>;
no-map;
};
+
+   venus_region: memory@9580 {
+   reg = <0x0 0x9580 0x0 0x50>;
+   no-map;
+   };
};

cpus {
@@ -1403,5 +1408,38 @@
status = "disabled";
};
};
+
+   video-codec@aa0 {
+   compatible = "qcom,sdm845-venus";
+   reg = <0x0aa0 0xff000>;
+   interrupts = ;
+   power-domains = <&videocc VENUS_GDSC>;
+   clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
+<&videocc VIDEO_CC_VENUS_AHB_CLK>,
+<&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>;
+   clock-names = "core", "iface", "bus";
+   iommus = <&apps_smmu 0x10a0 0x8>,
+<&apps_smmu 0x10b0 0x0>;
+   memory-region = <&venus_region>;
+
+   video-core0 {
+   compatible = "venus-decoder";
+   clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
+<&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
+   clock-names = "core", "bus";
+   power-domains = <&videocc VCODEC0_GDSC>;
+   };
+
+   video-core1 {
+   compatible = "venus-encoder";
+   clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
+<&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
+   clock-names = "core", "bus";
+   power-domains = <&videocc VCODEC1_GDSC>;
+   };
+   video-firmware {
+   iommus = <&apps_smmu 0x10b2 0x0>;
+   };
+   };
};
 };


--
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH] kcov: convert kcov.refcount to refcount_t

[Dmitry Vyukov]

On Sun, Jan 27, 2019 at 7:41 PM Reshetova, Elena
 wrote:
>
> > On Mon, Jan 21, 2019 at 11:05:03AM -0500, Alan Stern wrote:
> > > On Mon, 21 Jan 2019, Peter Zijlstra wrote:
> >
> > > > Any additional ordering; like the one you have above; are not strictly
> > > > required for the proper functioning of the refcount. Rather, you rely on
> > > > additional ordering and will need to provide this explicitly:
> > > >
> > > >
> > > >   if (refcount_dec_and_text(&x->rc)) {
> > > >   /*
> > > >* Comment that explains what we order against
> > > >*/
> > > >   smp_mb__after_atomic();
> > > >   BUG_ON(!x->done*);
> > > >   free(x);
> > > >   }
> > > >
> > > >
> > > > Also; these patches explicitly mention that refcount_t is weaker,
> > > > specifically to make people aware of this difference.
> > > >
> > > > A full smp_mb() (or two) would also be much more expensive on a number
> > > > of platforms and in the vast majority of the cases it is not required.
> > >
> > > How about adding smp_rmb() into refcount_dec_and_test()?  That would
> > > give acq+rel semantics, which seems to be what people will expect.  And
> > >it wouldn't be nearly as expensive as a full smp_mb().
> >
> > Yes, that's a very good suggestion.
> >
> > I suppose we can add smp_acquire__after_ctrl_dep() on the true branch.
> > Then it reall does become rel_acq.
> >
> > A wee something like so (I couldn't find an arm64 refcount, even though
> > I have distinct memories of talk about it).
> >
> > This isn't compiled, and obviously needs comment/documentation updates
> > to go along with it.
> >
> > ---
> >  arch/x86/include/asm/refcount.h | 9 -
> >  lib/refcount.c  | 7 ++-
> >  2 files changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/refcount.h 
> > b/arch/x86/include/asm/refcount.h
> > index dbaed55c1c24..6f7a1eb345b4 100644
> > --- a/arch/x86/include/asm/refcount.h
> > +++ b/arch/x86/include/asm/refcount.h
> > @@ -74,9 +74,16 @@ bool refcount_sub_and_test(unsigned int i, refcount_t *r)
> >
> >  static __always_inline __must_check bool refcount_dec_and_test(refcount_t 
> > *r)
> >  {
> > - return GEN_UNARY_SUFFIXED_RMWcc(LOCK_PREFIX "decl",
> > + bool ret = GEN_UNARY_SUFFIXED_RMWcc(LOCK_PREFIX "decl",
> >
> >   REFCOUNT_CHECK_LT_ZERO,
> >   r-
> > >refs.counter, e, "cx");
> > +
> > + if (ret) {
> > + smp_acquire__after_ctrl_dep();
> > + return true;
> > + }
> > +
> > + return false;
> >  }
>
> Actually as I started to do this, any reason why the change here only for 
> dec_and_test and not
> for sub_and _test also? Should not the arch. specific logic follow the 
> generic?

I would say these should be exactly the same wrt semantics.
dec_and_test is just syntactic sugar for 1 decrement. If we change
dec_and_test, we should change sub_and_test the same way.

Re: [PATCH v4 4/9] cpufreq: imx6q: Use auto-registration of thermal cooling device

[Daniel Lezcano]

On 28/01/2019 07:41, Amit Kucheria wrote:
> Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
> automatically register as a thermal cooling device.
> 
> This allows removal of boiler plate code from the driver.
> 
> Signed-off-by: Amit Kucheria 

Reviewed-by: Daniel Lezcano 

> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 24 ++--
>  1 file changed, 2 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index 9fedf627e000..9935df234fa1 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -9,7 +9,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -52,7 +51,6 @@ static struct clk_bulk_data clks[] = {
>  };
>  
>  static struct device *cpu_dev;
> -static struct thermal_cooling_device *cdev;
>  static bool free_opp;
>  static struct cpufreq_frequency_table *freq_table;
>  static unsigned int max_freq;
> @@ -193,16 +191,6 @@ static int imx6q_set_target(struct cpufreq_policy 
> *policy, unsigned int index)
>   return 0;
>  }
>  
> -static void imx6q_cpufreq_ready(struct cpufreq_policy *policy)
> -{
> - cdev = of_cpufreq_cooling_register(policy);
> -
> - if (!cdev)
> - dev_err(cpu_dev,
> - "running cpufreq without cooling device: %ld\n",
> - PTR_ERR(cdev));
> -}
> -
>  static int imx6q_cpufreq_init(struct cpufreq_policy *policy)
>  {
>   int ret;
> @@ -214,22 +202,14 @@ static int imx6q_cpufreq_init(struct cpufreq_policy 
> *policy)
>   return ret;
>  }
>  
> -static int imx6q_cpufreq_exit(struct cpufreq_policy *policy)
> -{
> - cpufreq_cooling_unregister(cdev);
> -
> - return 0;
> -}
> -
>  static struct cpufreq_driver imx6q_cpufreq_driver = {
> - .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK,
> + .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK |
> +  CPUFREQ_AUTO_REGISTER_COOLING_DEV,
>   .verify = cpufreq_generic_frequency_table_verify,
>   .target_index = imx6q_set_target,
>   .get = cpufreq_generic_get,
>   .init = imx6q_cpufreq_init,
> - .exit = imx6q_cpufreq_exit,
>   .name = "imx6q-cpufreq",
> - .ready = imx6q_cpufreq_ready,
>   .attr = cpufreq_generic_attr,
>   .suspend = cpufreq_generic_suspend,
>  };
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] audit: always enable syscall auditing when supported and audit is enabled

[Sverdlin, Alexander (Nokia - DE/Ulm)]

Hello Paul,

On 08/12/2015 17:42, Paul Moore wrote:
> To the best of our knowledge, everyone who enables audit at compile
> time also enables syscall auditing; this patch simplifies the Kconfig
> menus by removing the option to disable syscall auditing when audit
> is selected and the target arch supports it.
> 
> Signed-off-by: Paul Moore 

this patch is responsible for massive performance degradation for those
who used only CONFIG_SECURITY_APPARMOR.

And the numbers are, take the following test for instance:

dd if=/dev/zero of=/dev/null count=2M

ARM64:  500MB/s -> 350MB/s
ARM:400MB/s -> 300MB/s

(with some particular CPU frequencies).

Should we revert this patch?

> ---
>  init/Kconfig |   11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> 
> --
> Linux-audit mailing list
> linux-au...@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index c24b6f7..d4663b1 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -299,20 +299,15 @@ config AUDIT
>   help
> Enable auditing infrastructure that can be used with another
> kernel subsystem, such as SELinux (which requires this for
> -   logging of avc messages output).  Does not do system-call
> -   auditing without CONFIG_AUDITSYSCALL.
> +   logging of avc messages output).  System call auditing is included
> +   on architectures which support it.
>  
>  config HAVE_ARCH_AUDITSYSCALL
>   bool
>  
>  config AUDITSYSCALL
> - bool "Enable system-call auditing support"
> + def_bool y
>   depends on AUDIT && HAVE_ARCH_AUDITSYSCALL
> - default y if SECURITY_SELINUX
> - help
> -   Enable low-overhead system-call auditing infrastructure that
> -   can be used independently or with another kernel subsystem,
> -   such as SELinux.
>  
>  config AUDIT_WATCH
>   def_bool y
> 

-- 
Best regards,
Alexander Sverdlin.

Re: [PATCH] sched/fair: Remove unneeded prototype of capacity_of()

[Valentin Schneider]

Hi,

On 02/01/2019 13:55, Valentin Schneider wrote:
> The prototype of that function was already hoisted up in
> 
>   commit 3b1baa6496e6 ("sched/fair: Add 'group_misfit_task' load-balance 
> type")
> 
> but that seems to have been missed. Get rid of the extra prototype.
> 
> Fixes: 2802bf3cd936 ("sched/fair: Add over-utilization/tipping point 
> indicator")
> Signed-off-by: Valentin Schneider 

I had forgotten about that one... Ping.

> ---
>  kernel/sched/fair.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 6483834f1278..6d653947a829 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5083,7 +5083,6 @@ static inline void hrtick_update(struct rq *rq)
>  
>  #ifdef CONFIG_SMP
>  static inline unsigned long cpu_util(int cpu);
> -static unsigned long capacity_of(int cpu);
>  
>  static inline bool cpu_overutilized(int cpu)
>  {
> --
> 2.20.1
> 

Re: [PATCH v4 5/9] cpufreq: cpufreq-dt: Use auto-registration of thermal cooling device

[Daniel Lezcano]

On 28/01/2019 07:41, Amit Kucheria wrote:
> Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
> automatically register as a thermal cooling device.
> 
> This allows removal of boiler plate code from the driver.
> 
> Signed-off-by: Amit Kucheria 

Reviewed-by: Daniel Lezcano 

> ---
>  drivers/cpufreq/cpufreq-dt.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index e58bfcb1169e..2a4c4ea7980b 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -13,7 +13,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -30,7 +29,6 @@
>  struct private_data {
>   struct opp_table *opp_table;
>   struct device *cpu_dev;
> - struct thermal_cooling_device *cdev;
>   const char *reg_name;
>   bool have_static_opps;
>  };
> @@ -301,7 +299,6 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
>  {
>   struct private_data *priv = policy->driver_data;
>  
> - cpufreq_cooling_unregister(priv->cdev);
>   dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
>   if (priv->have_static_opps)
>   dev_pm_opp_of_cpumask_remove_table(policy->related_cpus);
> @@ -314,21 +311,14 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
>   return 0;
>  }
>  
> -static void cpufreq_ready(struct cpufreq_policy *policy)
> -{
> - struct private_data *priv = policy->driver_data;
> -
> - priv->cdev = of_cpufreq_cooling_register(policy);
> -}
> -
>  static struct cpufreq_driver dt_cpufreq_driver = {
> - .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK,
> + .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
> +  CPUFREQ_AUTO_REGISTER_COOLING_DEV,
>   .verify = cpufreq_generic_frequency_table_verify,
>   .target_index = set_target,
>   .get = cpufreq_generic_get,
>   .init = cpufreq_init,
>   .exit = cpufreq_exit,
> - .ready = cpufreq_ready,
>   .name = "cpufreq-dt",
>   .attr = cpufreq_dt_attr,
>   .suspend = cpufreq_generic_suspend,
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Hello Friend.

[Davis Douglas]

Hello Friend.
Please is this your personal email address? I have a confidential
matter to discuss with you.
Thanks,
Davies Douglas

Re: [PATCH v4 6/9] cpufreq: mediatek: Use auto-registration of thermal cooling device

[Daniel Lezcano]

On 28/01/2019 07:41, Amit Kucheria wrote:
> Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
> automatically register as a thermal cooling device.
> 
> This allows removal of boiler plate code from the driver.
> 
> Signed-off-by: Amit Kucheria 

Reviewed-by: Daniel Lezcano 


> ---
>  drivers/cpufreq/mediatek-cpufreq.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c 
> b/drivers/cpufreq/mediatek-cpufreq.c
> index eb8920d39818..9a937f4c63e7 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -14,7 +14,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -48,7 +47,6 @@ struct mtk_cpu_dvfs_info {
>   struct regulator *sram_reg;
>   struct clk *cpu_clk;
>   struct clk *inter_clk;
> - struct thermal_cooling_device *cdev;
>   struct list_head list_head;
>   int intermediate_voltage;
>   bool need_voltage_tracking;
> @@ -307,13 +305,6 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy 
> *policy,
>  
>  #define DYNAMIC_POWER "dynamic-power-coefficient"
>  
> -static void mtk_cpufreq_ready(struct cpufreq_policy *policy)
> -{
> - struct mtk_cpu_dvfs_info *info = policy->driver_data;
> -
> - info->cdev = of_cpufreq_cooling_register(policy);
> -}
> -
>  static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
>  {
>   struct device *cpu_dev;
> @@ -472,7 +463,6 @@ static int mtk_cpufreq_exit(struct cpufreq_policy *policy)
>  {
>   struct mtk_cpu_dvfs_info *info = policy->driver_data;
>  
> - cpufreq_cooling_unregister(info->cdev);
>   dev_pm_opp_free_cpufreq_table(info->cpu_dev, &policy->freq_table);
>  
>   return 0;
> @@ -480,13 +470,13 @@ static int mtk_cpufreq_exit(struct cpufreq_policy 
> *policy)
>  
>  static struct cpufreq_driver mtk_cpufreq_driver = {
>   .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
> -  CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
> +  CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
> +  CPUFREQ_AUTO_REGISTER_COOLING_DEV,
>   .verify = cpufreq_generic_frequency_table_verify,
>   .target_index = mtk_cpufreq_set_target,
>   .get = cpufreq_generic_get,
>   .init = mtk_cpufreq_init,
>   .exit = mtk_cpufreq_exit,
> - .ready = mtk_cpufreq_ready,
>   .name = "mtk-cpufreq",
>   .attr = cpufreq_generic_attr,
>  };
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] x86/speculation: Update TIF_SPEC_IB before ibpb barrier

[Thomas Gleixner]

On Mon, 28 Jan 2019, Zhenzhong Duan wrote:
> On 2019/1/26 2:03, Thomas Gleixner wrote:
> > Bah, nonsense. Brain was clearly still out for lunch and I confused IBPB
> > and STIBP for a moment. cond_ibpb() is the thing issues in switch_mm() and
> > that is not leaving a stale MSR around because we only write to it when we
> > need the barrier. The bit is not stale because the barrier is only issued
> > with the write. The bit has not to be cleared.
> > 
> > So the only 'issue' what happens is that switch_to() either issues a
> > barrier too much or misses one. That's really not a problem.
> 
> Ok, yes, the purpose of this patch is to avoid the one missed barrier.

And that missed barrier is not worth it to do extra work in switch_to/mm
simply because it's a one off event and there is no way to exploit that
reliably.

Thanks,

tglx

Re: [PATCH v4 7/9] cpufreq: qoriq: Use auto-registration of thermal cooling device

[Daniel Lezcano]

On 28/01/2019 07:41, Amit Kucheria wrote:
> Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
> automatically register as a thermal cooling device.
> 
> This allows removal of boiler plate code from the driver.
> 
> Signed-off-by: Amit Kucheria 

Reviewed-by: Daniel Lezcano 


> ---
>  drivers/cpufreq/qoriq-cpufreq.c | 15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
> index 3d773f64b4df..b206e6cb55f0 100644
> --- a/drivers/cpufreq/qoriq-cpufreq.c
> +++ b/drivers/cpufreq/qoriq-cpufreq.c
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -31,7 +30,6 @@
>  struct cpu_data {
>   struct clk **pclk;
>   struct cpufreq_frequency_table *table;
> - struct thermal_cooling_device *cdev;
>  };
>  
>  /*
> @@ -239,7 +237,6 @@ static int qoriq_cpufreq_cpu_exit(struct cpufreq_policy 
> *policy)
>  {
>   struct cpu_data *data = policy->driver_data;
>  
> - cpufreq_cooling_unregister(data->cdev);
>   kfree(data->pclk);
>   kfree(data->table);
>   kfree(data);
> @@ -258,23 +255,15 @@ static int qoriq_cpufreq_target(struct cpufreq_policy 
> *policy,
>   return clk_set_parent(policy->clk, parent);
>  }
>  
> -
> -static void qoriq_cpufreq_ready(struct cpufreq_policy *policy)
> -{
> - struct cpu_data *cpud = policy->driver_data;
> -
> - cpud->cdev = of_cpufreq_cooling_register(policy);
> -}
> -
>  static struct cpufreq_driver qoriq_cpufreq_driver = {
>   .name   = "qoriq_cpufreq",
> - .flags  = CPUFREQ_CONST_LOOPS,
> + .flags  = CPUFREQ_CONST_LOOPS |
> +   CPUFREQ_AUTO_REGISTER_COOLING_DEV,
>   .init   = qoriq_cpufreq_cpu_init,
>   .exit   = qoriq_cpufreq_cpu_exit,
>   .verify = cpufreq_generic_frequency_table_verify,
>   .target_index   = qoriq_cpufreq_target,
>   .get= cpufreq_generic_get,
> - .ready  = qoriq_cpufreq_ready,
>   .attr   = cpufreq_generic_attr,
>  };
>  
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v4 8/9] cpufreq: scmi: Use auto-registration of thermal cooling device

[Daniel Lezcano]

On 28/01/2019 07:41, Amit Kucheria wrote:
> Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
> automatically register as a thermal cooling device.
> 
> This allows removal of boiler plate code from the driver.
> 
> Signed-off-by: Amit Kucheria 
> Acked-by: Sudeep Holla 

Reviewed-by: Daniel Lezcano 

> ---
>  drivers/cpufreq/scmi-cpufreq.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index 242c3370544e..b19e9d129f8f 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -22,7 +21,6 @@
>  struct scmi_data {
>   int domain_id;
>   struct device *cpu_dev;
> - struct thermal_cooling_device *cdev;
>  };
>  
>  static const struct scmi_handle *handle;
> @@ -185,7 +183,6 @@ static int scmi_cpufreq_exit(struct cpufreq_policy 
> *policy)
>  {
>   struct scmi_data *priv = policy->driver_data;
>  
> - cpufreq_cooling_unregister(priv->cdev);
>   dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
>   kfree(priv);
>   dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
> @@ -193,17 +190,11 @@ static int scmi_cpufreq_exit(struct cpufreq_policy 
> *policy)
>   return 0;
>  }
>  
> -static void scmi_cpufreq_ready(struct cpufreq_policy *policy)
> -{
> - struct scmi_data *priv = policy->driver_data;
> -
> - priv->cdev = of_cpufreq_cooling_register(policy);
> -}
> -
>  static struct cpufreq_driver scmi_cpufreq_driver = {
>   .name   = "scmi",
>   .flags  = CPUFREQ_STICKY | CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
> -   CPUFREQ_NEED_INITIAL_FREQ_CHECK,
> +   CPUFREQ_NEED_INITIAL_FREQ_CHECK |
> +   CPUFREQ_AUTO_REGISTER_COOLING_DEV,
>   .verify = cpufreq_generic_frequency_table_verify,
>   .attr   = cpufreq_generic_attr,
>   .target_index   = scmi_cpufreq_set_target,
> @@ -211,7 +202,6 @@ static struct cpufreq_driver scmi_cpufreq_driver = {
>   .get= scmi_cpufreq_get_rate,
>   .init   = scmi_cpufreq_init,
>   .exit   = scmi_cpufreq_exit,
> - .ready  = scmi_cpufreq_ready,
>  };
>  
>  static int scmi_cpufreq_probe(struct scmi_device *sdev)
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v5 0/4] Reduce NUMA related overhead in perf record profiling on large server systems

[Alexey Budankov]

On 28.01.2019 11:20, Jiri Olsa wrote:
> On Mon, Jan 28, 2019 at 10:13:20AM +0300, Alexey Budankov wrote:
> 
> SNIP
> 
>>> ---
>>> Alexey Budankov (4):
>>>   perf record: allocate affinity masks
>>>   perf record: bind the AIO user space buffers to nodes
>>>   perf record: apply affinity masks when reading mmap buffers
>>>   perf record: implement --affinity=node|cpu option
>>>
>>>  tools/perf/Documentation/perf-record.txt |   5 ++
>>>  tools/perf/builtin-record.c  |  45 +-
>>>  tools/perf/perf.h|   8 ++
>>>  tools/perf/util/cpumap.c |  10 +++
>>>  tools/perf/util/cpumap.h |   1 +
>>>  tools/perf/util/evlist.c |   6 +-
>>>  tools/perf/util/evlist.h |   2 +-
>>>  tools/perf/util/mmap.c   | 105 ++-
>>>  tools/perf/util/mmap.h   |   3 +-
>>>  9 files changed, 175 insertions(+), 10 deletions(-)
>>>
>>> ---
>>> Changes in v5:
>>> - avoided multiple allocations of online cpu maps by 
>>>   implementing it once in cpu_map__online()
>>> - reduced indentation at record__parse_affinity()
>>
>> Are there any more comments on this patch set?
> 
> sry for late reply.. there was a mayhem in here
> last week because of the devconf ;-)

Aww, I see. Thanks for update.

-Alexey

> 
> I'll review it today, but I think there were no more issues
> 
> jirka
> 

Re: [PATCH v4 9/9] cpufreq: scpi: Use auto-registration of thermal cooling device

[Daniel Lezcano]

On 28/01/2019 07:41, Amit Kucheria wrote:
> Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
> automatically register as a thermal cooling device.
> 
> This allows removal of boiler plate code from the driver.
> 
> Signed-off-by: Amit Kucheria 
> Acked-by: Sudeep Holla 

Reviewed-by: Daniel Lezcano 


> ---
>  drivers/cpufreq/scpi-cpufreq.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c
> index 99449738faa4..82420e8e5f0d 100644
> --- a/drivers/cpufreq/scpi-cpufreq.c
> +++ b/drivers/cpufreq/scpi-cpufreq.c
> @@ -22,7 +22,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -34,7 +33,6 @@
>  struct scpi_data {
>   struct clk *clk;
>   struct device *cpu_dev;
> - struct thermal_cooling_device *cdev;
>  };
>  
>  static struct scpi_ops *scpi_ops;
> @@ -186,7 +184,6 @@ static int scpi_cpufreq_exit(struct cpufreq_policy 
> *policy)
>  {
>   struct scpi_data *priv = policy->driver_data;
>  
> - cpufreq_cooling_unregister(priv->cdev);
>   clk_put(priv->clk);
>   dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
>   kfree(priv);
> @@ -195,23 +192,16 @@ static int scpi_cpufreq_exit(struct cpufreq_policy 
> *policy)
>   return 0;
>  }
>  
> -static void scpi_cpufreq_ready(struct cpufreq_policy *policy)
> -{
> - struct scpi_data *priv = policy->driver_data;
> -
> - priv->cdev = of_cpufreq_cooling_register(policy);
> -}
> -
>  static struct cpufreq_driver scpi_cpufreq_driver = {
>   .name   = "scpi-cpufreq",
>   .flags  = CPUFREQ_STICKY | CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
> -   CPUFREQ_NEED_INITIAL_FREQ_CHECK,
> +   CPUFREQ_NEED_INITIAL_FREQ_CHECK |
> +   CPUFREQ_AUTO_REGISTER_COOLING_DEV,
>   .verify = cpufreq_generic_frequency_table_verify,
>   .attr   = cpufreq_generic_attr,
>   .get= scpi_cpufreq_get_rate,
>   .init   = scpi_cpufreq_init,
>   .exit   = scpi_cpufreq_exit,
> - .ready  = scpi_cpufreq_ready,
>   .target_index   = scpi_cpufreq_set_target,
>  };
>  
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 05/15] habanalabs: add command buffer module

[Mike Rapoport]

On Mon, Jan 28, 2019 at 09:55:23AM +0200, Oded Gabbay wrote:
> On Sun, Jan 27, 2019 at 8:49 AM Mike Rapoport  wrote:
> >
> > On Fri, Jan 25, 2019 at 11:47:03PM +0200, Oded Gabbay wrote:
> > > On Wed, Jan 23, 2019 at 2:28 PM Mike Rapoport  wrote:
> > > >
> > > > On Wed, Jan 23, 2019 at 02:00:47AM +0200, Oded Gabbay wrote:
> > > > > This patch adds the CB module, which allows the user to create and
> > > > > destroy CBs and to map them to the user's process address-space.
> > > >
> > > > Can you please spell "command buffer" at least first time it's 
> > > > mentioned?
> > > fixed
> > > >
> > > > > A command buffer is a memory blocks that reside in DMA-able 
> > > > > address-space
> > > > > and is physically contiguous so it can be accessed by the device 
> > > > > without
> > > > > MMU translation. The command buffer memory is allocated using the
> > > > > coherent DMA API.
> > > > >
> > > > > When creating a new CB, the IOCTL returns a handle of it, and the
> > > > > user-space process needs to use that handle to mmap the buffer to get 
> > > > > a VA
> > > > > in the user's address-space.
> > > > >
> > > > > Before destroying (freeing) a CB, the user must unmap the CB's VA 
> > > > > using the
> > > > > CB handle.
> > > > >
> > > > > Each CB has a reference counter, which tracks its usage in command
> > > > > submissions and also its mmaps (only a single mmap is allowed).
> > > > >
> > > > > The driver maintains a pool of pre-allocated CBs in order to reduce
> > > > > latency during command submissions. In case the pool is empty, the 
> > > > > driver
> > > > > will go to the slow-path of allocating a new CB, i.e. calling
> > > > > dma_alloc_coherent.
> > > > >
> > > > > Signed-off-by: Oded Gabbay 
> > > > > ---
> > > > >  drivers/misc/habanalabs/Makefile   |   3 +-
> > > > >  drivers/misc/habanalabs/command_buffer.c   | 414 
> > > > > +
> > > > >  drivers/misc/habanalabs/device.c   |  43 ++-
> > > > >  drivers/misc/habanalabs/goya/goya.c|  28 ++
> > > > >  drivers/misc/habanalabs/habanalabs.h   |  95 -
> > > > >  drivers/misc/habanalabs/habanalabs_drv.c   |   2 +
> > > > >  drivers/misc/habanalabs/habanalabs_ioctl.c | 102 +
> > > > >  include/uapi/misc/habanalabs.h |  62 +++
> > > > >  8 files changed, 746 insertions(+), 3 deletions(-)
> > > > >  create mode 100644 drivers/misc/habanalabs/command_buffer.c
> > > > >  create mode 100644 drivers/misc/habanalabs/habanalabs_ioctl.c
> > > > >  create mode 100644 include/uapi/misc/habanalabs.h
> >
> > [ ... ]
> >
> > > > > +int hl_cb_create(struct hl_device *hdev, struct hl_cb_mgr *mgr,
> > > > > + u32 cb_size, u64 *handle, int ctx_id)
> > > > > +{
> > > > > + struct hl_cb *cb;
> > > > > + bool alloc_new_cb = true;
> > > > > + int rc;
> > > > > +
> > > > > + if (hdev->disabled) {
> > > > > + dev_warn_ratelimited(hdev->dev,
> > > > > + "Device is disabled !!! Can't create new 
> > > > > CBs\n");
> > > > > + rc = -EBUSY;
> > > > > + goto out_err;
> > > > > + }
> > > > > +
> > > > > + /* Minimum allocation must be PAGE SIZE */
> > > > > + if (cb_size < PAGE_SIZE)
> > > > > + cb_size = PAGE_SIZE;
> > > > > +
> > > > > + if (ctx_id == HL_KERNEL_ASID_ID &&
> > > > > + cb_size <= hdev->asic_prop.cb_pool_cb_size) {
> > > > > +
> > > > > + spin_lock(&hdev->cb_pool_lock);
> > > > > + if (!list_empty(&hdev->cb_pool)) {
> > > > > + cb = list_first_entry(&hdev->cb_pool, 
> > > > > typeof(*cb),
> > > > > + pool_list);
> > > > > + list_del(&cb->pool_list);
> > > > > + spin_unlock(&hdev->cb_pool_lock);
> > > > > + alloc_new_cb = false;
> > > > > + } else {
> > > > > + spin_unlock(&hdev->cb_pool_lock);
> > > > > + dev_warn_once(hdev->dev, "CB pool is empty\n");
> > > >
> > > > Isn't it going to be a false alarm when you allocate the cb for the 
> > > > first
> > > > time?
> > > Why ?
> > > The cb_pool list holds a list of available CBs. See hl_cb_pool_init()
> > > - it adds newly allocated CBs to this pool list.
> > >
> > > if (!list_empty(&hdev->cb_pool)) {   -  this checks whether the
> > > pool is not empty so we can take an available CB from it. If the list
> > > is empty (hence the pool is empty), we print the warning.
> >
> > Sorry if it's too much nitpicking, but why the allocation of the first cb
> > should be a warning? There's nothing wrong there... Maybe dev_dbg()
> > instead?
> Yeah, that's a fair point. The issue is I would like to know if we
> reach to this state and dev_dbg isn't usually enabled.
> Still, I get what you are saying and I'll change this to dev_dbg.
> 
> >
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + if (alloc_new_cb) {
> > >

Re: [PATCH] x86/speculation: Update TIF_SPEC_IB before ibpb barrier

[Zhenzhong Duan]

On 2019/1/28 16:36, Thomas Gleixner wrote:

On Mon, 28 Jan 2019, Zhenzhong Duan wrote:

On 2019/1/26 2:03, Thomas Gleixner wrote:

Bah, nonsense. Brain was clearly still out for lunch and I confused IBPB
and STIBP for a moment. cond_ibpb() is the thing issues in switch_mm() and
that is not leaving a stale MSR around because we only write to it when we
need the barrier. The bit is not stale because the barrier is only issued
with the write. The bit has not to be cleared.

So the only 'issue' what happens is that switch_to() either issues a
barrier too much or misses one. That's really not a problem.


Ok, yes, the purpose of this patch is to avoid the one missed barrier.


And that missed barrier is not worth it to do extra work in switch_to/mm
simply because it's a one off event and there is no way to exploit that
reliably.


Got it.

Thanks
Zhenzhong

[PATCH 3/3] Input: st1232 - add Martin as module author

[Martin Kepplinger]

From: Martin Kepplinger 

This adds myself as an author of the st1232 driver module as Tony's
email address doesn't seem to work anymore.

Signed-off-by: Martin Kepplinger 
---
 drivers/input/touchscreen/st1232.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/touchscreen/st1232.c 
b/drivers/input/touchscreen/st1232.c
index 19a665d48dad..906b233970aa 100644
--- a/drivers/input/touchscreen/st1232.c
+++ b/drivers/input/touchscreen/st1232.c
@@ -346,5 +346,6 @@ static struct i2c_driver st1232_ts_driver = {
 module_i2c_driver(st1232_ts_driver);
 
 MODULE_AUTHOR("Tony SIM ");
+MODULE_AUTHOR("Martin Kepplinger ");
 MODULE_DESCRIPTION("SITRONIX ST1232 Touchscreen Controller Driver");
 MODULE_LICENSE("GPL v2");
-- 
2.20.1

[PATCH 2/3] Input: st1232 - add support for st1633

[Martin Kepplinger]

From: Martin Kepplinger 

Add support for the Sitronix ST1633 touchscreen controller to the st1232
driver. A protocol spec can be found here:
www.ampdisplay.com/documents/pdf/AM-320480B6TZQW-TC0H.pdf

Signed-off-by: Martin Kepplinger 
---
 drivers/input/touchscreen/Kconfig  |   6 +-
 drivers/input/touchscreen/st1232.c | 122 +
 2 files changed, 94 insertions(+), 34 deletions(-)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 068dbbc610fc..7c597a49c265 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -1168,11 +1168,11 @@ config TOUCHSCREEN_SIS_I2C
  module will be called sis_i2c.
 
 config TOUCHSCREEN_ST1232
-   tristate "Sitronix ST1232 touchscreen controllers"
+   tristate "Sitronix ST1232 or ST1633 touchscreen controllers"
depends on I2C
help
- Say Y here if you want to support Sitronix ST1232
- touchscreen controller.
+ Say Y here if you want to support the Sitronix ST1232
+ or ST1633 touchscreen controller.
 
  If unsure, say N.
 
diff --git a/drivers/input/touchscreen/st1232.c 
b/drivers/input/touchscreen/st1232.c
index 11ff32c68025..19a665d48dad 100644
--- a/drivers/input/touchscreen/st1232.c
+++ b/drivers/input/touchscreen/st1232.c
@@ -23,13 +23,15 @@
 #include 
 
 #define ST1232_TS_NAME "st1232-ts"
+#define ST1633_TS_NAME "st1633-ts"
+
+enum {
+   st1232,
+   st1633,
+};
 
 #define MIN_X  0x00
 #define MIN_Y  0x00
-#define MAX_X  0x31f   /* (800 - 1) */
-#define MAX_Y  0x1df   /* (480 - 1) */
-#define MAX_AREA   0xff
-#define MAX_FINGERS2
 
 struct st1232_ts_finger {
u16 x;
@@ -38,12 +40,24 @@ struct st1232_ts_finger {
bool is_valid;
 };
 
+struct st_chip_info {
+   boolhave_z;
+   u16 max_x;
+   u16 max_y;
+   u16 max_area;
+   u16 max_fingers;
+   u8  start_reg;
+};
+
 struct st1232_ts_data {
struct i2c_client *client;
struct input_dev *input_dev;
-   struct st1232_ts_finger finger[MAX_FINGERS];
struct dev_pm_qos_request low_latency_req;
int reset_gpio;
+   const struct st_chip_info *chip_info;
+   int read_buf_len;
+   u8 *read_buf;
+   struct st1232_ts_finger *finger;
 };
 
 static int st1232_ts_read_data(struct st1232_ts_data *ts)
@@ -52,40 +66,35 @@ static int st1232_ts_read_data(struct st1232_ts_data *ts)
struct i2c_client *client = ts->client;
struct i2c_msg msg[2];
int error;
-   u8 start_reg;
-   u8 buf[10];
+   int i, y;
+   u8 start_reg = ts->chip_info->start_reg;
+   u8 *buf = ts->read_buf;
 
-   /* read touchscreen data from ST1232 */
+   /* read touchscreen data */
msg[0].addr = client->addr;
msg[0].flags = 0;
msg[0].len = 1;
msg[0].buf = &start_reg;
-   start_reg = 0x10;
 
msg[1].addr = ts->client->addr;
msg[1].flags = I2C_M_RD;
-   msg[1].len = sizeof(buf);
+   msg[1].len = ts->read_buf_len;
msg[1].buf = buf;
 
error = i2c_transfer(client->adapter, msg, 2);
if (error < 0)
return error;
 
-   /* get "valid" bits */
-   finger[0].is_valid = buf[2] >> 7;
-   finger[1].is_valid = buf[5] >> 7;
+   for (i = 0, y = 0; i < ts->chip_info->max_fingers; i++, y += 3) {
+   finger[i].is_valid = buf[i + y] >> 7;
+   if (finger[i].is_valid) {
+   finger[i].x = ((buf[i + y] & 0x0070) << 4) | buf[i + 1];
+   finger[i].y = ((buf[i + y] & 0x0007) << 8) | buf[i + 2];
 
-   /* get xy coordinate */
-   if (finger[0].is_valid) {
-   finger[0].x = ((buf[2] & 0x0070) << 4) | buf[3];
-   finger[0].y = ((buf[2] & 0x0007) << 8) | buf[4];
-   finger[0].t = buf[8];
-   }
-
-   if (finger[1].is_valid) {
-   finger[1].x = ((buf[5] & 0x0070) << 4) | buf[6];
-   finger[1].y = ((buf[5] & 0x0007) << 8) | buf[7];
-   finger[1].t = buf[9];
+   /* st1232 includes a z-axis / touch strength */
+   if (ts->chip_info->have_z)
+   finger[i].t = buf[i + 6];
+   }
}
 
return 0;
@@ -104,11 +113,14 @@ static irqreturn_t st1232_ts_irq_handler(int irq, void 
*dev_id)
goto end;
 
/* multi touch protocol */
-   for (i = 0; i < MAX_FINGERS; i++) {
+   for (i = 0; i < ts->chip_info->max_fingers; i++) {
if (!finger[i].is_valid)
continue;
 
-   input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, finger[i].t);
+   if (ts->chip_info->have_z)
+   input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR,
+finger[i].t);
+
input_report_abs

[PATCH 1/3] dt-bindings: input: sitronix-st1232: add compatible string for ST1633

[Martin Kepplinger]

From: Martin Kepplinger 

The st1232 driver gains support for the ST1633 controller too; update
the bindings doc accordingly.

Signed-off-by: Martin Kepplinger 
---
 .../bindings/input/touchscreen/sitronix-st1232.txt  | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt 
b/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt
index 64ad48b824a2..e73e826e0f2a 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt
@@ -1,7 +1,9 @@
-* Sitronix st1232 touchscreen controller
+* Sitronix st1232 or st1633 touchscreen controller
 
 Required properties:
-- compatible: must be "sitronix,st1232"
+- compatible: must contain one of
+  * "sitronix,st1232"
+  * "sitronix,st1633"
 - reg: I2C address of the chip
 - interrupts: interrupt to which the chip is connected
 
-- 
2.20.1

DMA Engine Documentation: TX Descriptor and Submission

[Federico Vaga]

Hi,

I have a new question concerning documentation.

https://www.kernel.org/doc/html/latest/driver-api/dmaengine/client.html

>From this document it is not really clear, at least to me, if clients can 
consider valid the `struct dma_async_tx_descriptor` after submission to the 
DMA engine.

Clients get a TX descriptor from a DMA engine using things like 
`dmaengine_prep_*`. These calls - may - allocate new descriptors and return 
them to the caller; this may include other structures which are not visible to 
clients. So, if my understanding is correct, this means that it's the DMA 
engine that, on TX completion, releases any TX descriptor allocated by 
`dmaengine_prep_*`. This implies that the pointer that the client is using 
must be considered invalid right after `dmaengine_submit()`.

If what I understood by reading the documentation and the code is correct, 
then I think that this should be mentioned in the Documentation.
If I'm wrong, please tell me where :)

Thanks

Re: ipu3-imgu 0000:00:05.0: required queues are disabled

[Kieran Bingham]

Hi Kai-Heng,

On 27/01/2019 05:56, Kai-Heng Feng wrote:
> Hi,
> 
> We have a bug report [1] that the ipu3 doesn’t work.
> Does ipu3 need special userspace to work?

Yes, it will need further userspace support to configure the pipeline,
and to provide 3A algorithms for white balance, focus, and exposure
times to the sensor.

We are developing a stack called libcamera [0] to support this, but it's
still in active development and not yet ready for use. Fortunately
however, IPU3 is one of our primary initial targets.

[0] https://www.libcamera.org/

> [1] https://bugs.launchpad.net/bugs/1812114

I have reported similar information to the launchpad bug entry.

It might help if we can get hold of a Dell 7275 sometime although I
think Mauro at least has one ?

If this is a priority for Canonical, please contact us directly.

> Kai-Heng
--
Regards

Kieran

AW: [PATCH 2/3] Input: st1232 - add support for st1633

[Kepplinger Martin]

Von: Martin Kepplinger [mart...@posteo.de]
Gesendet: Montag, 28. Jänner 2019 09:44
An: devicet...@vger.kernel.org; linux-in...@vger.kernel.org
Cc: dmitry.torok...@gmail.com; robh...@kernel.org; mark.rutl...@arm.com; 
linux-kernel@vger.kernel.org; Kepplinger Martin
Betreff: [PATCH 2/3] Input: st1232 - add support for st1633

From: Martin Kepplinger 

Add support for the Sitronix ST1633 touchscreen controller to the st1232
driver. A protocol spec can be found here:
www.ampdisplay.com/documents/pdf/AM-320480B6TZQW-TC0H.pdf

Signed-off-by: Martin Kepplinger 
---

sorry, this is v3 of this series.

anyways, the of_device.h header isn't directly need now neither. thanks Dmitry!

 martin


revision history

v3: implement Dmitry's suggestion for i2c probe from v2 review
v2: use device_get_match_data(), invent an internal "have_z" bool property
v1: initial idea for the change



 drivers/input/touchscreen/Kconfig  |   6 +-
 drivers/input/touchscreen/st1232.c | 122 +
 2 files changed, 94 insertions(+), 34 deletions(-)



smime.p7s
Description: S/MIME cryptographic signature

[PATCH v2] sysctl: Add panic-fatal-signals

[Vincent Whitchurch]

Add a sysctl which asks the kernel to panic when any userspace process
receives a fatal signal which would trigger a core dump.  This has
proven to be quite useful when debugging problems seen during testing of
embedded systems:  When combined with kernel core dumps (saved due to
the panic), it allows easier debugging of crashes which have their
origin in system-wide problems such as buggy drivers or other kernel or
hardware-related issues.

The crashing process's core dump can be extracted from the kernel core
dump using tools such as the crash utility's gcore extension.

Signed-off-by: Vincent Whitchurch 
---
v2: Put the sysctl behind a config option

 include/linux/signal.h |  1 +
 init/Kconfig   | 14 ++
 kernel/signal.c|  5 -
 kernel/sysctl.c|  9 +
 4 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/include/linux/signal.h b/include/linux/signal.h
index cc7e2c1cd444..109efd1432e9 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -10,6 +10,7 @@ struct task_struct;
 
 /* for sysctl */
 extern int print_fatal_signals;
+extern int panic_fatal_signals;
 
 static inline void copy_siginfo(kernel_siginfo_t *to,
const kernel_siginfo_t *from)
diff --git a/init/Kconfig b/init/Kconfig
index d47cb77a220e..875442f6ab53 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1242,6 +1242,20 @@ config SYSCTL_SYSCALL
 
  If unsure say N here.
 
+config SYSCTL_PANIC_FATAL_SIGNALS
+   bool "panic-fatal-signals sysctl" if EXPERT
+   depends on PROC_SYSCTL
+   help
+ If you say Y here, a kernel.panic-fatal-signals sysctl will be
+ offered.  If this sysctl is turned on, the kernel will panic if any
+ userspace process receives a fatal signal which would trigger a core
+ dump.
+
+ When used together with kernel core dumps, this can be useful for
+ debugging some system-wide problems, primarily on embedded systems.
+
+ If unsure, say N.
+
 config FHANDLE
bool "open by fhandle syscalls" if EXPERT
select EXPORTFS
diff --git a/kernel/signal.c b/kernel/signal.c
index e1d7ad8e6ab1..83c6877b0182 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -59,6 +59,7 @@
 static struct kmem_cache *sigqueue_cachep;
 
 int print_fatal_signals __read_mostly;
+int panic_fatal_signals __read_mostly;
 
 static void __user *sig_handler(struct task_struct *t, int sig)
 {
@@ -2497,8 +2498,10 @@ bool get_signal(struct ksignal *ksig)
current->flags |= PF_SIGNALED;
 
if (sig_kernel_coredump(signr)) {
-   if (print_fatal_signals)
+   if (print_fatal_signals || panic_fatal_signals)
print_fatal_signal(ksig->info.si_signo);
+   if (panic_fatal_signals)
+   panic("Fatal signal and panic_fatal_signals=1");
proc_coredump_connector(current);
/*
 * If it was able to dump core, this kills all
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ba4d9e85feb8..48023bad5b08 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -557,6 +557,15 @@ static struct ctl_table kern_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec,
},
+#ifdef CONFIG_SYSCTL_PANIC_FATAL_SIGNALS
+   {
+   .procname   = "panic-fatal-signals",
+   .data   = &panic_fatal_signals,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
+#endif
 #ifdef CONFIG_SPARC
{
.procname   = "reboot-cmd",
-- 
2.20.0

Re: [PATCH V3,4/8] drm/mediatek: fix the rate and divder of hdmi phy for MT2701

[CK Hu]

On Fri, 2019-01-25 at 12:02 +0800, Wangyan Wang wrote:
> From: chunhui dai 
> 
> Due to a clerical error,there is one zero less for 1280.
> Fix it for 12800.
> 

Reviewed-by: CK Hu 

> Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623")
> Signed-off-by: chunhui dai 
> Signed-off-by: wangyan wang 
> ---
>  drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index 43bc058d5528..88dd9e812ca0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -114,8 +114,8 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>  
>   if (rate <= 6400)
>   pos_div = 3;
> - else if (rate <= 1280)
> - pos_div = 1;
> + else if (rate <= 12800)
> + pos_div = 2;
>   else
>   pos_div = 1;
>  

[linux-next] kcompactd0 stuck in a CPU-burning loop

[Sergey Senozhatsky]

Hello,

next-20190125

kcompactd0 is spinning on something, burning CPUs in the meantime:

 %CPU TIME+  COMMAND
 100.0   0.0  34:04.20 R [kcompactd0]

Not sure I know how to reproduce it; so am probably not going to
be a very helpful tester.

I tried to ftrace kcompactd0 PID, and I see the same path all over
the tracing file:

 2)   0.119 us|unlock_page();
 2)   0.109 us|unlock_page();
 2)   0.096 us|compaction_free();
 2)   0.104 us|___might_sleep();
 2)   0.121 us|compaction_alloc();
 2)   0.111 us|page_mapped();
 2)   0.105 us|page_mapped();
 2)   |move_to_new_page() {
 2)   0.102 us|  page_mapping();
 2)   |  buffer_migrate_page_norefs() {
 2)   |__buffer_migrate_page() {
 2)   |  expected_page_refs() {
 2)   0.118 us|page_mapping();
 2)   0.321 us|  }
 2)   |  __might_sleep() {
 2)   0.122 us|___might_sleep();
 2)   0.332 us|  }
 2)   |  _raw_spin_lock() {
 2)   0.115 us|preempt_count_add();
 2)   0.321 us|  }
 2)   |  _raw_spin_unlock() {
 2)   0.114 us|preempt_count_sub();
 2)   0.321 us|  }
 2)   |  invalidate_bh_lrus() {
 2)   |on_each_cpu_cond() {
 2)   |  on_each_cpu_cond_mask() {
 2)   |__might_sleep() {
 2)   0.114 us|  ___might_sleep();
 2)   0.316 us|}
 2)   0.109 us|preempt_count_add();
 2)   0.128 us|has_bh_in_lru();
 2)   0.105 us|has_bh_in_lru();
 2)   0.124 us|has_bh_in_lru();
 2)   0.103 us|has_bh_in_lru();
 2)   0.125 us|has_bh_in_lru();
 2)   0.105 us|has_bh_in_lru();
 2)   0.123 us|has_bh_in_lru();
 2)   0.107 us|has_bh_in_lru();
 2)   |on_each_cpu_mask() {
 2)   0.104 us|  preempt_count_add();
 2)   0.110 us|  smp_call_function_many();
 2)   0.105 us|  preempt_count_sub();
 2)   0.764 us|}
 2)   0.116 us|preempt_count_sub();
 2)   3.676 us|  }
 2)   3.889 us|}
 2)   4.087 us|  }
 2)   |  _raw_spin_lock() {
 2)   0.112 us|preempt_count_add();
 2)   0.315 us|  }
 2)   |  _raw_spin_unlock() {
 2)   0.108 us|preempt_count_sub();
 2)   0.309 us|  }
 2)   |  unlock_buffer() {
 2)   |wake_up_bit() {
 2)   0.118 us|  __wake_up_bit();
 2)   0.317 us|}
 2)   0.513 us|  }
 2)   7.440 us|}
 2)   7.643 us|  }
 2)   8.070 us|}


PG migration fails a lot:

pgmigrate_success 111063
pgmigrate_fail 269841559
compact_migrate_scanned 536253365
compact_free_scanned 360889
compact_isolated 270072733
compact_stall 0
compact_fail 0
compact_success 0
compact_daemon_wake 56
compact_daemon_migrate_scanned 536253365
compact_daemon_free_scanned 360889

Let me know if I can help with anything else. I'll keep the the box alive
for a while, but will have to power it off eventually.

-ss

Re: [PATCH v9 22/26] irqchip/gic-v3: Allow interrupts to be set as pseudo-NMI

[Julien Thierry]

Hi,

On 26/01/2019 10:19, liwei (GF) wrote:
> 
> 
> On 2019/1/21 23:33, Julien Thierry wrote:
>> Implement NMI callbacks for GICv3 irqchip. Install NMI safe handlers
>> when setting up interrupt line as NMI.
>>
>> Only SPIs and PPIs are allowed to be set up as NMI.
>>
>> Signed-off-by: Julien Thierry 
>> Cc: Thomas Gleixner 
>> Cc: Jason Cooper 
>> Cc: Marc Zyngier 
>> ---
>>  drivers/irqchip/irq-gic-v3.c | 84 
>> 
>>  1 file changed, 84 insertions(+)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>> index 4df1e94..447d8ab 100644
>> --- a/drivers/irqchip/irq-gic-v3.c
>> +++ b/drivers/irqchip/irq-gic-v3.c
> (snip)
>>  
>> +static int gic_irq_nmi_setup(struct irq_data *d)
>> +{
>> +struct irq_desc *desc = irq_to_desc(d->irq);
>> +
>> +if (!gic_supports_nmi())
>> +return -EINVAL;
>> +
>> +if (gic_peek_irq(d, GICD_ISENABLER)) {
>> +pr_err("Cannot set NMI property of enabled IRQ %u\n", d->irq);
>> +return -EINVAL;
>> +}
>> +
>> +/*
>> + * A secondary irq_chip should be in charge of LPI request,
>> + * it should not be possible to get there
>> + */
>> +if (WARN_ON(gic_irq(d) >= 8192))
>> +return -EINVAL;
>> +
>> +/* desc lock should already be held */
>> +if (gic_irq(d) < 32) {
>> +/* Setting up PPI as NMI, only switch handler for first NMI */
>> +if (!refcount_inc_not_zero(&ppi_nmi_refs[gic_irq(d) - 16])) {
>> +refcount_set(&ppi_nmi_refs[gic_irq(d) - 16], 1);
>> +desc->handle_irq = handle_percpu_devid_fasteoi_nmi;
>> +}
>> +} else {
>> +desc->handle_irq = handle_fasteoi_nmi;
>> +}
>> +
>> +gic_set_irq_prio(gic_irq(d), gic_dist_base(d), GICD_INT_NMI_PRI);
>> +
>> +return 0;
>> +}
>> +
>> +static void gic_irq_nmi_teardown(struct irq_data *d)
>> +{
>> +struct irq_desc *desc = irq_to_desc(d->irq);
>> +
>> +if (WARN_ON(!gic_supports_nmi()))
>> +return;
>> +
>> +if (gic_peek_irq(d, GICD_ISENABLER)) {
>> +pr_err("Cannot set NMI property of enabled IRQ %u\n", d->irq);
>> +return;
>> +}
>> +
>> +/*
>> + * A secondary irq_chip should be in charge of LPI request,
>> + * it should not be possible to get there
>> + */
>> +if (WARN_ON(gic_irq(d) >= 8192))
>> +return;
>> +
>> +/* desc lock should already be held */
>> +if (gic_irq(d) < 32) {
>> +/* Tearing down NMI, only switch handler for last NMI */
>> +if (refcount_dec_and_test(&ppi_nmi_refs[gic_irq(d) - 16]))
>> +desc->handle_irq = handle_percpu_devid_irq;
>> +} else {
>> +desc->handle_irq = handle_fasteoi_irq;
>> +}
>> +
>> +gic_set_irq_prio(gic_irq(d), gic_dist_base(d), GICD_INT_DEF_PRI);
>> +}
>> +
> 
> Hello Julien,
> I am afraid the setting of priority is not correct here. If the irq is in 
> redistributor(gic_irq(d) < 32),
> we should set the priority on each cpu, while we just set the priority on the 
> current cpu here.

As Marc stated, to work with PPIs, the core IRQ API provides a set of
*_percpu_irq functions (request, enable, disable...).

The current idea is that the driver is in charge of calling
ready_percpu_nmi() before enabling on the correct CPU, in a similar
manner that the driver is in charge of calling enable_percpu_irq() and
disable_percpu_irq() on the correct CPU.


> static inline void __iomem *gic_dist_base(struct irq_data *d)
> {
>   if (gic_irq_in_rdist(d))/* SGI+PPI -> SGI_base for this CPU */
>   return gic_data_rdist_sgi_base();
> 
>   if (d->hwirq <= 1023)   /* SPI -> dist_base */
>   return gic_data.dist_base;
> 
>   return NULL;
> }
> 
> I tried to add a smp_call_function here, but the kernel reported a warning as 
> we have disabled irq
> when calling raw_spin_lock_irqsave in request_nmi or ready_percpu_nmi.
> [2.137262] Call trace:
> [2.137265]  smp_call_function_many+0xf8/0x3a0
> [2.137267]  smp_call_function+0x40/0x58
> [2.137271]  gic_irq_nmi_setup+0xe8/0x118
> [2.137275]  ready_percpu_nmi+0x6c/0xf0> [2.137279]  
> armpmu_request_irq+0x228/0x250

Your issue lies here, if your PMU IRQ is a PPI, you shouldn't be calling
ready_percpu_nmi() at the time you request but probably somewhere like
arm_perf_starting_cpu().

And you wouldn't need the smp_call to set the priority.

Hope this helps.

> [2.137281]  arm_pmu_acpi_init+0x150/0x2f0
> [2.137284]  do_one_initcall+0x54/0x218
> [2.137289]  kernel_init_freeable+0x230/0x354
> [2.137293]  kernel_init+0x18/0x118
> [2.137295]  ret_from_fork+0x10/0x18
> 

Thanks,

-- 
Julien Thierry

[PATCH v8 0/5] media/sun6i: Allwinner A64 CSI support

[Jagan Teki]

Add CSI support for Allwinner A64. Here is previous series[1]

Changes for v8:
- update proper enable and disable sequnce for clk_mod
- fix warning for patch "media: sun6i: Add A64 CSI block support"
- collect Maxime Acked-by
Changes for v7:
- Drop quirk change, and add as suggusted by Maxime
- Use csi instead csi0 in pinctrl function
Changes for v6:
- set the mod rate in seett_power instead of probe
Changes for v5:
- Add mod_rate quirk for better handling clk_set code
Changes for v4:
- update the compatible string order
- add proper commit message
- included BPI-M64 patch
- skipped amarula-a64 patch
Changes for v3:
- update dt-bindings for A64
- set mod clock via csi driver
- remove assign clocks from dtsi
- remove i2c-gpio opendrian
- fix avdd and dovdd supplies
- remove vcc-csi pin group supply

[1] https://patchwork.kernel.org/cover/10779831/

Jagan Teki (5):
  dt-bindings: media: sun6i: Add A64 CSI compatible
  media: sun6i: Add A64 CSI block support
  arm64: dts: allwinner: a64: Add A64 CSI controller
  arm64: dts: allwinner: a64: Add pinmux setting for CSI MCLK on PE1
  [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Add HDF5640 camera module

 .../devicetree/bindings/media/sun6i-csi.txt   |  1 +
 .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 65 +++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 25 +++
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 11 
 4 files changed, 102 insertions(+)

-- 
2.18.0.321.gffc6fa0e3

[PATCH v8 1/5] dt-bindings: media: sun6i: Add A64 CSI compatible

[Jagan Teki]

Allwinner A64 CSI is a single channel time-multiplexed BT.656
protocol interface.

Add separate compatible string for A64 since it require explicit
change in sun6i_csi driver to update default CSI_SCLK rate.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
Acked-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/media/sun6i-csi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
index cc37cf7fd051..0dd540bb03db 100644
--- a/Documentation/devicetree/bindings/media/sun6i-csi.txt
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -8,6 +8,7 @@ Required properties:
 * "allwinner,sun6i-a31-csi"
 * "allwinner,sun8i-h3-csi"
 * "allwinner,sun8i-v3s-csi"
+* "allwinner,sun50i-a64-csi"
   - reg: base address and size of the memory-mapped region.
   - interrupts: interrupt associated to this IP
   - clocks: phandles to the clocks feeding the CSI
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v4] kbuild: Add support for DT binding schema checks

[Geert Uytterhoeven]

Hi Rob,

On Sun, Jan 27, 2019 at 4:00 AM Rob Herring  wrote:
> On Wed, Jan 23, 2019 at 9:33 AM Geert Uytterhoeven  
> wrote:
> > On Tue, Dec 11, 2018 at 9:24 PM Rob Herring  wrote:
> > > This adds the build infrastructure for checking DT binding schema
> > > documents and validating dts files using the binding schema.
> > >
> > > Check DT binding schema documents:
> > > make dt_binding_check
> > >
> > > Build dts files and check using DT binding schema:
> > > make dtbs_check
> > >
> > > Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
> > > use for validation. This makes it easier to find and fix errors
> > > generated by a specific schema.
> > >
> > > Currently, the validation targets are separate from a normal build to
> > > avoid a hard dependency on the external DT schema project and because
> > > there are lots of warnings generated.
> >
> > Thanks, I'm giving this a try, and get errors like:
> >
> >   DTC arch/arm/boot/dts/emev2-kzm9d.dt.yaml
> > FATAL ERROR: No markers present in property 'cpu0' value
> >
> > and
> >
> >   DTC arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dt.yaml
> > FATAL ERROR: No markers present in property 'audio_clk_a' value
> >
> > Do you have a clue?
>
> That's really strange because those aren't even properties. Are other
> dts files okay? This is the in tree dtc?
>
> The only time you should be missing markers is if you did a dts -> dts
> -> dt.yaml.

Found it: make dtbs_check doesn't play well with my local change to
add symbols for DT overlays:

--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -285,6 +285,10 @@ cmd_dt_S_dtb=
 \
 $(obj)/%.dtb.S: $(obj)/%.dtb FORCE
$(call if_changed,dt_S_dtb)

+ifeq ($(CONFIG_OF_OVERLAY),y)
+DTC_FLAGS += -@
+endif
+
 quiet_cmd_dtc = DTC $@
 cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
$(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o
$(dtc-tmp) $< ; \

Do you see a way to handle that better?

Apart from a few expected issues, I'm seeing one other strange message:

arch/arm/boot/dts/sh73a0-kzm9g.dt.yaml: interrupts: [[2, 4], [3,
4]] is too long

This is the interrupts property in the adi,adxl345 node in
arch/arm/boot/dts/sh73a0-kzm9g.dts.
Apparently the check complains if more than one interrupt is listed here.
Is this a known issue?

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

[PATCH v8 3/5] arm64: dts: allwinner: a64: Add A64 CSI controller

[Jagan Teki]

Add dts node details for Allwinner A64 CSI controller.

A64 CSI has similar features as like in H3, but the CSI_SCLK
need to update it to 300MHz than default clock rate.

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 +++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 839b2ae88583..62fdf850e9e5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -558,6 +558,12 @@
interrupt-controller;
#interrupt-cells = <3>;
 
+   csi_pins: csi-pins {
+   pins = "PE0", "PE2", "PE3", "PE4", "PE5", "PE6",
+  "PE7", "PE8", "PE9", "PE10", "PE11";
+   function = "csi";
+   };
+
i2c0_pins: i2c0_pins {
pins = "PH0", "PH1";
function = "i2c0";
@@ -925,6 +931,20 @@
status = "disabled";
};
 
+   csi: csi@1cb {
+   compatible = "allwinner,sun50i-a64-csi";
+   reg = <0x01cb 0x1000>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_CSI_SCLK>,
+<&ccu CLK_DRAM_CSI>;
+   clock-names = "bus", "mod", "ram";
+   resets = <&ccu RST_BUS_CSI>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&csi_pins>;
+   status = "disabled";
+   };
+
hdmi: hdmi@1ee {
compatible = "allwinner,sun50i-a64-dw-hdmi",
 "allwinner,sun8i-a83t-dw-hdmi";
-- 
2.18.0.321.gffc6fa0e3

[PATCH v8 2/5] media: sun6i: Add A64 CSI block support

[Jagan Teki]

CSI block in Allwinner A64 has similar features as like in H3,
but the default CSI_SCLK rate cannot work properly to drive the
connected sensor interface.

The tested mod cock rate is 300 MHz and BSP vfe media driver is also
using the same rate. Unfortunately there is no valid information about
clock rate in manual or any other sources except the BSP driver. so more
faith on BSP code, because same has tested in mainline.

So, add support for A64 CSI block by setting updated mod clock rate.

Signed-off-by: Jagan Teki 
---
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index ee882b66a5ea..5ecdfbf9f6ae 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -154,6 +155,7 @@ bool sun6i_csi_is_format_supported(struct sun6i_csi *csi,
 int sun6i_csi_set_power(struct sun6i_csi *csi, bool enable)
 {
struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
+   struct device *dev = sdev->dev;
struct regmap *regmap = sdev->regmap;
int ret;
 
@@ -161,6 +163,9 @@ int sun6i_csi_set_power(struct sun6i_csi *csi, bool enable)
regmap_update_bits(regmap, CSI_EN_REG, CSI_EN_CSI_EN, 0);
 
clk_disable_unprepare(sdev->clk_ram);
+   if (of_device_is_compatible(dev->of_node,
+   "allwinner,sun50i-a64-csi"))
+   clk_rate_exclusive_put(sdev->clk_mod);
clk_disable_unprepare(sdev->clk_mod);
reset_control_assert(sdev->rstc_bus);
return 0;
@@ -172,6 +177,9 @@ int sun6i_csi_set_power(struct sun6i_csi *csi, bool enable)
return ret;
}
 
+   if (of_device_is_compatible(dev->of_node, "allwinner,sun50i-a64-csi"))
+   clk_set_rate_exclusive(sdev->clk_mod, 3);
+
ret = clk_prepare_enable(sdev->clk_ram);
if (ret) {
dev_err(sdev->dev, "Enable clk_dram_csi clk err %d\n", ret);
@@ -191,6 +199,8 @@ int sun6i_csi_set_power(struct sun6i_csi *csi, bool enable)
 clk_ram_disable:
clk_disable_unprepare(sdev->clk_ram);
 clk_mod_disable:
+   if (of_device_is_compatible(dev->of_node, "allwinner,sun50i-a64-csi"))
+   clk_rate_exclusive_put(sdev->clk_mod);
clk_disable_unprepare(sdev->clk_mod);
return ret;
 }
@@ -895,6 +905,7 @@ static const struct of_device_id sun6i_csi_of_match[] = {
{ .compatible = "allwinner,sun6i-a31-csi", },
{ .compatible = "allwinner,sun8i-h3-csi", },
{ .compatible = "allwinner,sun8i-v3s-csi", },
+   { .compatible = "allwinner,sun50i-a64-csi", },
{},
 };
 MODULE_DEVICE_TABLE(of, sun6i_csi_of_match);
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v3 17/23] drm/qxl: use generic fbdev emulation

[Gerd Hoffmann]

On Fri, Jan 25, 2019 at 06:25:27PM +0100, Noralf Trønnes wrote:
> 
> 
> Den 18.01.2019 13.20, skrev Gerd Hoffmann:
> > Switch qxl over to the new generic fbdev emulation.
> > 
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  drivers/gpu/drm/qxl/qxl_display.c | 7 ---
> >  drivers/gpu/drm/qxl/qxl_drv.c | 2 ++
> >  2 files changed, 2 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
> > b/drivers/gpu/drm/qxl/qxl_display.c
> > index ef832f98ab..9c751f01e3 100644
> > --- a/drivers/gpu/drm/qxl/qxl_display.c
> > +++ b/drivers/gpu/drm/qxl/qxl_display.c
> > @@ -1221,18 +1221,11 @@ int qxl_modeset_init(struct qxl_device *qdev)
> > qxl_display_read_client_monitors_config(qdev);
> >  
> > drm_mode_config_reset(&qdev->ddev);
> > -
> > -   /* primary surface must be created by this point, to allow
> > -* issuing command queue commands and having them read by
> > -* spice server. */
> > -   qxl_fbdev_init(qdev);
> > return 0;
> >  }
> >  
> >  void qxl_modeset_fini(struct qxl_device *qdev)
> >  {
> > -   qxl_fbdev_fini(qdev);
> > -
> > qxl_destroy_monitors_object(qdev);
> > drm_mode_config_cleanup(&qdev->ddev);
> >  }
> > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> > index 13c8a662f9..3fce7d16df 100644
> > --- a/drivers/gpu/drm/qxl/qxl_drv.c
> > +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> > @@ -93,6 +93,8 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
> > pci_device_id *ent)
> > if (ret)
> > goto modeset_cleanup;
> >  
> > +   drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
> 
> I couldn't find that this was part of old fbdev code, so it would be
> nice to mention it in the commit message.

It actually is, but a bit hidden because it doesn't use a helper you can
easily grep for.  Instead sets fb_info->apertures->ranges[0] in
qxlfb_create(), which has the same effect.

cheers,
  Gerd

[PATCH v8 4/5] arm64: dts: allwinner: a64: Add pinmux setting for CSI MCLK on PE1

[Jagan Teki]

Some camera modules have the SoC feeding a master clock to the sensor
instead of having a standalone crystal. This clock signal is generated
from the clock control unit and output from the CSI MCLK function of
pin PE1.

Add a pinmux setting for it for camera sensors to reference.

Signed-off-by: Jagan Teki 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 62fdf850e9e5..6e5a608f56f2 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -564,6 +564,11 @@
function = "csi";
};
 
+   csi_mclk_pin: csi-mclk {
+   pins = "PE1";
+   function = "csi";
+   };
+
i2c0_pins: i2c0_pins {
pins = "PH0", "PH1";
function = "i2c0";
-- 
2.18.0.321.gffc6fa0e3

[DO NOT MERGE] [PATCH v8 5/5] arm64: dts: allwinner: bananapi-m64: Add HDF5640 camera module

[Jagan Teki]

Bananapi M64 comes with an optional sensor based on the ov5640,
add support for it with below pin information.

- PE13, PE12 via i2c-gpio bitbanging
- CLK_CSI_MCLK as external clock
- PE1 as external clock pin muxing
- DLDO3 as AVDD supply
- ALDO1 as DOVDD supply
- ELDO3 as DVDD supply
- PE16 gpio for reset pin
- PE17 gpio for powerdown pin

Signed-off-by: Jagan Teki 
---
 .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 65 +++
 1 file changed, 65 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 9d0afd7d50ec..c99f66271287 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -60,6 +60,41 @@
stdout-path = "serial0:115200n8";
};
 
+   i2c-csi {
+   compatible = "i2c-gpio";
+   sda-gpios = <&pio 4 13 GPIO_ACTIVE_HIGH>; /* CSI0-SDA: PE13 */
+   scl-gpios = <&pio 4 12 GPIO_ACTIVE_HIGH>; /* CSI0-SCK: PE12 */
+   i2c-gpio,delay-us = <5>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ov5640: camera@3c {
+   compatible = "ovti,ov5640";
+   reg = <0x3c>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&csi_mclk_pin>;
+   clocks = <&ccu CLK_CSI_MCLK>;
+   clock-names = "xclk";
+
+   AVDD-supply = <®_dldo3>;
+   DOVDD-supply = <®_aldo1>;
+   DVDD-supply = <®_eldo3>;
+   reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* CSI0-RST: 
PE16 */
+   powerdown-gpios = <&pio 4 17 GPIO_ACTIVE_HIGH>; /* 
CSI0-PWDN: PE17 */
+
+   port {
+   ov5640_ep: endpoint {
+   remote-endpoint = <&csi_ep>;
+   bus-width = <8>;
+   hsync-active = <1>; /* Active high */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+   };
+   };
+
hdmi-connector {
compatible = "hdmi-connector";
type = "a";
@@ -108,6 +143,24 @@
status = "okay";
 };
 
+&csi {
+   status = "okay";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   csi_ep: endpoint {
+   remote-endpoint = <&ov5640_ep>;
+   bus-width = <8>;
+   hsync-active = <1>; /* Active high */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+};
+
 &dai {
status = "okay";
 };
@@ -298,6 +351,12 @@
regulator-name = "vcc-wifi";
 };
 
+®_dldo3 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "avdd-csi";
+};
+
 ®_dldo4 {
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
@@ -315,6 +374,12 @@
regulator-name = "cpvdd";
 };
 
+®_eldo3 {
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "dvdd-csi";
+};
+
 ®_fldo1 {
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v4 2/9] cpufreq: Auto-register the driver as a thermal cooling device if asked

[Rafael J. Wysocki]

On Mon, Jan 28, 2019 at 7:44 AM Amit Kucheria  wrote:
>
> All cpufreq drivers do similar things to register as a cooling device.
> Provide a cpufreq driver flag so drivers can just ask the cpufreq core
> to register the cooling device on their behalf. This allows us to get
> rid of duplicated code in the drivers.
>
> In order to allow this, we add a struct thermal_cooling_device pointer
> to struct cpufreq_policy so that drivers don't need to store it in a
> private data structure.
>
> Suggested-by: Stephen Boyd 
> Suggested-by: Viresh Kumar 
> Signed-off-by: Amit Kucheria 
> Reviewed-by: Matthias Kaehlcke 
> Tested-by: Matthias Kaehlcke 
> ---
>  drivers/cpufreq/cpufreq.c | 9 +
>  include/linux/cpufreq.h   | 9 +
>  2 files changed, 18 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index e35a886e00bc..29ed78b0b77b 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -19,6 +19,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1318,6 +1319,9 @@ static int cpufreq_online(unsigned int cpu)
> if (cpufreq_driver->ready)
> cpufreq_driver->ready(policy);
>
> +   if (cpufreq_driver->flags & CPUFREQ_AUTO_REGISTER_COOLING_DEV)

It would be good to use IS_ENABLED(CONFIG_CPU_THERMAL) here and below
as a hint for the compiler.

> +   policy->cdev = of_cpufreq_cooling_register(policy);
> +
> pr_debug("initialization complete\n");
>
> return 0;
> @@ -1405,6 +1409,11 @@ static int cpufreq_offline(unsigned int cpu)
> goto unlock;
> }
>
> +   if (cpufreq_driver->flags & CPUFREQ_AUTO_REGISTER_COOLING_DEV) {
> +   cpufreq_cooling_unregister(policy->cdev);
> +   policy->cdev = NULL;
> +   }
> +
> if (cpufreq_driver->stop_cpu)
> cpufreq_driver->stop_cpu(policy);
>

Re: [PATCH] pinctrl.txt: Remove outdated information

[Linus Walleij]

On Mon, Jan 21, 2019 at 3:38 PM Ramon Fried  wrote:

> Returning -EAGAIN is no longer supported by pin_config_group_set()
> since ad42fc6c8479 ("pinctrl: rip out the direct pinconf API")
>
> Remove the relevant section from the documentation.
>
> Signed-off-by: Ramon Fried 

Patch applied!

Yours,
Linus Walleij

RE: [PATCH v5 2/4] perf: add arm64 smmuv3 pmu driver

[Shameerali Kolothum Thodi]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 25 January 2019 15:14
> To: Shameerali Kolothum Thodi ;
> lorenzo.pieral...@arm.com
> Cc: jean-philippe.bruc...@arm.com; will.dea...@arm.com;
> mark.rutl...@arm.com; Guohanjun (Hanjun Guo) ;
> John Garry ; pa...@codeaurora.org;
> vkil...@codeaurora.org; rruig...@codeaurora.org; linux-a...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Linuxarm
> ; neil.m.lee...@gmail.com
> Subject: Re: [PATCH v5 2/4] perf: add arm64 smmuv3 pmu driver
> 
> On 30/11/2018 15:47, Shameer Kolothum wrote:
> > From: Neil Leeder 
> >
> > Adds a new driver to support the SMMUv3 PMU and add it into the
> > perf events framework.
> >
> > Each SMMU node may have multiple PMUs associated with it, each of
> > which may support different events.
> >
> > SMMUv3 PMCG devices are named as smmuv3_pmcg_
> where
> >  is the physical page address of the SMMU PMCG
> > wrapped to 4K boundary. For example, the PMCG at 0xff8884 is
> > named smmuv3_pmcg_ff88840
> >
> > Filtering by stream id is done by specifying filtering parameters
> > with the event. options are:
> > filter_enable- 0 = no filtering, 1 = filtering enabled
> > filter_span  - 0 = exact match, 1 = pattern match
> > filter_stream_id - pattern to filter against
> >
> > Example: perf stat -e smmuv3_pmcg_ff88840/transaction,filter_enable=1,
> > filter_span=1,filter_stream_id=0x42/ -a
> netperf
> >
> > Applies filter pattern 0x42 to transaction events, which means events
> > matching stream ids 0x42 & 0x43 are counted as only upper StreamID
> > bits are required to match the given filter. Further filtering
> > information is available in the SMMU documentation.
> >
> > SMMU events are not attributable to a CPU, so task mode and sampling
> > are not supported.
> >
> > Signed-off-by: Neil Leeder 
> > Signed-off-by: Shameer Kolothum 
> > ---
> >   drivers/perf/Kconfig  |   9 +
> >   drivers/perf/Makefile |   1 +
> >   drivers/perf/arm_smmuv3_pmu.c | 778
> ++
> >   3 files changed, 788 insertions(+)
> >   create mode 100644 drivers/perf/arm_smmuv3_pmu.c
> >
> > diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
> > index 08ebaf7..92be6a3 100644
> > --- a/drivers/perf/Kconfig
> > +++ b/drivers/perf/Kconfig
> > @@ -52,6 +52,15 @@ config ARM_PMU_ACPI
> > depends on ARM_PMU && ACPI
> > def_bool y
> >
> > +config ARM_SMMU_V3_PMU
> > +bool "ARM SMMUv3 Performance Monitors Extension"
> > +depends on ARM64 && ACPI && ARM_SMMU_V3
> > +  help
> > +  Provides support for the SMMU version 3 performance monitor unit
> (PMU)
> > +  on ARM-based systems.
> > +  Adds the SMMU PMU into the perf events subsystem for
> > +  monitoring SMMU performance events.
> > +
> >   config ARM_DSU_PMU
> > tristate "ARM DynamIQ Shared Unit (DSU) PMU"
> > depends on ARM64
> > diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
> > index b3902bd..f10a932 100644
> > --- a/drivers/perf/Makefile
> > +++ b/drivers/perf/Makefile
> > @@ -4,6 +4,7 @@ obj-$(CONFIG_ARM_CCN) += arm-ccn.o
> >   obj-$(CONFIG_ARM_DSU_PMU) += arm_dsu_pmu.o
> >   obj-$(CONFIG_ARM_PMU) += arm_pmu.o arm_pmu_platform.o
> >   obj-$(CONFIG_ARM_PMU_ACPI) += arm_pmu_acpi.o
> > +obj-$(CONFIG_ARM_SMMU_V3_PMU) += arm_smmuv3_pmu.o
> >   obj-$(CONFIG_HISI_PMU) += hisilicon/
> >   obj-$(CONFIG_QCOM_L2_PMU) += qcom_l2_pmu.o
> >   obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
> > diff --git a/drivers/perf/arm_smmuv3_pmu.c
> b/drivers/perf/arm_smmuv3_pmu.c
> > new file mode 100644
> > index 000..fb9dcd8
> > --- /dev/null
> > +++ b/drivers/perf/arm_smmuv3_pmu.c
> > @@ -0,0 +1,778 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/*
> > + * This driver adds support for perf events to use the Performance
> > + * Monitor Counter Groups (PMCG) associated with an SMMUv3 node
> > + * to monitor that node.
> > + *
> > + * SMMUv3 PMCG devices are named as smmuv3_pmcg_
> where
> > + *  is the physical page address of the SMMU PMCG
> wrapped
> > + * to 4K boundary. For example, the PMCG at 0xff8884 is named
> > + * smmuv3_pmcg_ff88840
> > + *
> > + * Filtering by stream id is done by specifying filtering parameters
> > + * with the event. options are:
> > + *   filter_enable- 0 = no filtering, 1 = filtering enabled
> > + *   filter_span  - 0 = exact match, 1 = pattern match
> > + *   filter_stream_id - pattern to filter against
> > + *
> > + * To match a partial StreamID where the X most-significant bits must match
> > + * but the Y least-significant bits might differ, STREAMID is programmed
> > + * with a value that contains:
> > + *  STREAMID[Y - 1] == 0.
> > + *  STREAMID[Y - 2:0] == 1 (where Y > 1).
> > + * The remainder of implemented bits of STREAMID (X bits, from bit Y
> upwards)
> > + * contain a value to match from the corresponding bits of event StreamID.
> > + *
> > + *

Re: [PATCH 01/11] clk: sunxi-ng: sun8i-a23: Enable PLL-MIPI LDOs when ungating it

[Jagan Teki]

On Fri, Jan 25, 2019 at 8:54 AM Chen-Yu Tsai  wrote:
>
> The PLL-MIPI clock is somewhat special as it has its own LDOs which
> need to be turned on for this PLL to actually work and output a clock
> signal.
>
> Add the 2 LDO enable bits to the gate bits.
>
> Fixes: 5690879d93e8 ("clk: sunxi-ng: Add A23 CCU")
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c 
> b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
> index a4fa2945f230..4b5f8f4e4ab8 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
> @@ -144,7 +144,7 @@ static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_mipi_clk, 
> "pll-mipi",
> 8, 4,   /* N */
> 4, 2,   /* K */
> 0, 4,   /* M */
> -   BIT(31),/* gate */
> +   BIT(31) | BIT(23) | BIT(22), /* gate */

Reviewed-by: Jagan Teki 

Re: [PATCH] mtd: rawnand: mark expected switch fall-throughs

[Miquel Raynal]

Hi Boris,

Boris Brezillon  wrote on Sat, 26 Jan 2019
17:54:29 +0100:

> On Sat, 26 Jan 2019 07:48:50 -0600
> "Gustavo A. R. Silva"  wrote:
> 
> > Hey Boris,
> > 
> > On 1/26/19 3:52 AM, Boris Brezillon wrote:  
> > > On Fri, 25 Jan 2019 15:09:50 -0600
> > > "Gustavo A. R. Silva"  wrote:
> > > 
> > >> diff --git a/drivers/mtd/nand/raw/nandsim.c 
> > >> b/drivers/mtd/nand/raw/nandsim.c
> > >> index 933d1a629c51..d33e15dc4cdc 100644
> > >> --- a/drivers/mtd/nand/raw/nandsim.c
> > >> +++ b/drivers/mtd/nand/raw/nandsim.c
> > >> @@ -2251,9 +2251,10 @@ static int __init ns_init_module(void)
> > >>  
> > >>  switch (bbt) {
> > >>  case 2:
> > >> - chip->bbt_options |= NAND_BBT_NO_OOB;
> > >> +chip->bbt_options |= NAND_BBT_NO_OOB;
> > >> +/* fall through */
> > >>  case 1:
> > >> - chip->bbt_options |= NAND_BBT_USE_FLASH;
> > >> +chip->bbt_options |= NAND_BBT_USE_FLASH;
> > > 
> > > You miss a '/* fall through */' here.
> > > 
> > 
> > Not really.  Notice that in this case the code falls through
> > to a break statement.  
> 
> Still find it weird to mandate fall through comments in all cases but
> this one...

Yes please, even if there is no GCC warning I think you can add one
here.


Thanks,
Miquèl

Re: [PATCH v2] HID: debug: fix the ring buffer implementation

[Benjamin Tissoires]

On Sat, Jan 26, 2019 at 6:07 PM Vladis Dronov  wrote:
>
> Ring buffer implementation in hid_debug_event() and hid_debug_events_read()
> is strange allowing lost or corrupted data. After commit 717adfdaf147
> ("HID: debug: check length before copy_to_user()") it is possible to enter
> an infinite loop in hid_debug_events_read() by providing 0 as count, this
> locks up a system. Fix this by rewriting the ring buffer implementation
> with kfifo and simplify the code.
>
> This fixes CVE-2019-3819.
>
> v2: fix an execution logic and add a comment

Thanks for the respin.
v2 looks good to me.
Oleg, can you provide some feedback before I push this?

Cheers,
Benjamin

>
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187
> Cc: sta...@vger.kernel.org # v4.18+
> Fixes: cd667ce24796 ("HID: use debugfs for events/reports dumping")
> Fixes: 717adfdaf147 ("HID: debug: check length before copy_to_user()")
> Signed-off-by: Vladis Dronov 
> ---
>  drivers/hid/hid-debug.c   | 116 ++
>  include/linux/hid-debug.h |   9 ++-
>  2 files changed, 47 insertions(+), 78 deletions(-)
>
> diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
> index c530476edba6..08870c909268 100644
> --- a/drivers/hid/hid-debug.c
> +++ b/drivers/hid/hid-debug.c
> @@ -30,6 +30,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -661,17 +662,12 @@ EXPORT_SYMBOL_GPL(hid_dump_device);
>  /* enqueue string to 'events' ring buffer */
>  void hid_debug_event(struct hid_device *hdev, char *buf)
>  {
> -   unsigned i;
> struct hid_debug_list *list;
> unsigned long flags;
>
> spin_lock_irqsave(&hdev->debug_list_lock, flags);
> -   list_for_each_entry(list, &hdev->debug_list, node) {
> -   for (i = 0; buf[i]; i++)
> -   list->hid_debug_buf[(list->tail + i) % 
> HID_DEBUG_BUFSIZE] =
> -   buf[i];
> -   list->tail = (list->tail + i) % HID_DEBUG_BUFSIZE;
> -}
> +   list_for_each_entry(list, &hdev->debug_list, node)
> +   kfifo_in(&list->hid_debug_fifo, buf, strlen(buf));
> spin_unlock_irqrestore(&hdev->debug_list_lock, flags);
>
> wake_up_interruptible(&hdev->debug_wait);
> @@ -722,8 +718,7 @@ void hid_dump_input(struct hid_device *hdev, struct 
> hid_usage *usage, __s32 valu
> hid_debug_event(hdev, buf);
>
> kfree(buf);
> -wake_up_interruptible(&hdev->debug_wait);
> -
> +   wake_up_interruptible(&hdev->debug_wait);
>  }
>  EXPORT_SYMBOL_GPL(hid_dump_input);
>
> @@ -1083,8 +1078,8 @@ static int hid_debug_events_open(struct inode *inode, 
> struct file *file)
> goto out;
> }
>
> -   if (!(list->hid_debug_buf = kzalloc(HID_DEBUG_BUFSIZE, GFP_KERNEL))) {
> -   err = -ENOMEM;
> +   err = kfifo_alloc(&list->hid_debug_fifo, HID_DEBUG_FIFOSIZE, 
> GFP_KERNEL);
> +   if (err) {
> kfree(list);
> goto out;
> }
> @@ -1104,77 +1099,57 @@ static ssize_t hid_debug_events_read(struct file 
> *file, char __user *buffer,
> size_t count, loff_t *ppos)
>  {
> struct hid_debug_list *list = file->private_data;
> -   int ret = 0, len;
> +   int ret = 0, copied;
> DECLARE_WAITQUEUE(wait, current);
>
> mutex_lock(&list->read_mutex);
> -   while (ret == 0) {
> -   if (list->head == list->tail) {
> -   add_wait_queue(&list->hdev->debug_wait, &wait);
> -   set_current_state(TASK_INTERRUPTIBLE);
> -
> -   while (list->head == list->tail) {
> -   if (file->f_flags & O_NONBLOCK) {
> -   ret = -EAGAIN;
> -   break;
> -   }
> -   if (signal_pending(current)) {
> -   ret = -ERESTARTSYS;
> -   break;
> -   }
> -
> -   if (!list->hdev || !list->hdev->debug) {
> -   ret = -EIO;
> -   set_current_state(TASK_RUNNING);
> -   goto out;
> -   }
> -
> -   /* allow O_NONBLOCK from other threads */
> -   mutex_unlock(&list->read_mutex);
> -   schedule();
> -   mutex_lock(&list->read_mutex);
> -   set_current_state(TASK_INTERRUPTIBLE);
> -   }
> -
> -   set_current_state(TASK_RUNNING);
> -   remove_wait_queue(&list->hdev->debug_wait, &wait);
> -   }
> -
> -   if (ret)
> -   goto out;
> + 

Re: [PATCH v8 01/26] arm64: Fix HCR.TGE status for NMI contexts

[Marc Zyngier]

On Tue, 08 Jan 2019 14:07:19 +,
Julien Thierry  wrote:
> 
> When using VHE, the host needs to clear HCR_EL2.TGE bit in order
> to interract with guest TLBs, switching from EL2&0 translation regime
> to EL1&0.
> 
> However, some non-maskable asynchronous event could happen while TGE is
> cleared like SDEI. Because of this address translation operations
> relying on EL2&0 translation regime could fail (tlb invalidation,
> userspace access, ...).
> 
> Fix this by properly setting HCR_EL2.TGE when entering NMI context and
> clear it if necessary when returning to the interrupted context.
> 
> Signed-off-by: Julien Thierry 
> Suggested-by: Marc Zyngier 
> Cc: Arnd Bergmann 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Marc Zyngier 
> Cc: James Morse 
> Cc: linux-a...@vger.kernel.org
> Cc: sta...@vger.kernel.org

Reviewed-by: Marc Zyngier 

Thanks,

M.

-- 
Jazz is not dead, it just smell funny.

Re: [PATCH] x86/kvmclock: set offset for kvm unstable clock

[Paolo Bonzini]

On 26/01/19 18:49, Pavel Tatashin wrote:
> VMs may show incorrect uptime and dmesg printk offsets on hypervisors with
> unstable clock. The problem is produced when VM is rebooted without exiting
> from qemu.
> 
> The fix is to calculate clock offset not only for stable clock but for
> unstable clock as well, and use kvm_sched_clock_read() which substracts
> the offset for both clocks.
> 
> This is safe, because pvclock_clocksource_read() does the right thing and
> makes sure that clock always goes forward, so once offset is calculated
> with unstable clock, we won't get new reads that are smaller than offset,
> and thus won't get negative results.
> 
> Thank you Jon DeVree for helping to reproduce this issue.
> 
> Fixes: 857baa87b642 ("sched/clock: Enable sched clock early")
> 
> Reported-by: Dominique Martinet 
> Signed-off-by: Pavel Tatashin 
> ---
>  arch/x86/kernel/kvmclock.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> index e811d4d1c824..d908a37bf3f3 100644
> --- a/arch/x86/kernel/kvmclock.c
> +++ b/arch/x86/kernel/kvmclock.c
> @@ -104,12 +104,8 @@ static u64 kvm_sched_clock_read(void)
>  
>  static inline void kvm_sched_clock_init(bool stable)
>  {
> - if (!stable) {
> - pv_ops.time.sched_clock = kvm_clock_read;
> + if (!stable)
>   clear_sched_clock_stable();
> - return;
> - }
> -
>   kvm_sched_clock_offset = kvm_clock_read();
>   pv_ops.time.sched_clock = kvm_sched_clock_read;
>  
> 

Queued, thanks.

Pa

Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu?

[Jan Kara]

On Sun 27-01-19 16:36:34, valdis.kletni...@vt.edu wrote:
> On Sun, 27 Jan 2019 17:00:27 +0100, Pavel Machek said:
> > > > I've noticed this as well on earlier kernels (next-20181224 to 20190115)
> > > > Some more info:
> > > > 1) echo 3 > /proc/sys/vm/drop_caches  unwedges kcompactd in 1-3 seconds.
> > > This aspect is curious as it indicates that kcompactd could potentially
> > > be infinite looping but it's not something I've experienced myself. By
> > > any chance is there a preditable reproduction case for this?
> >
> > I seen it exactly once, so not sure how reproducible this is. x86-32
> > machine, running chromium browser, so yes, there was some swapping
> > involved.
> 
> I don't have a surefire replicator, but my laptop (x86_64, so it's not a 
> 32-bit
> only issue) triggers it fairly often, up to multiple times a day. Doesn't 
> seem to
> be just the Chrome browser that triggers it - usually I'm doing other stuff as
> well, like a compile or similar.  The fact that 'drop_caches' clears it  
> makes me
> wonder if we're hitting a corner case where cache data isn't being 
> automatically
> cleared and clogging something up.

So my buffer_migrate_page_norefs() is certainly buggy in its current
incarnation (as a result block device page cache is not migratable at all).
I've sent Andrew a patch over week ago but so far it got ignored. The patch
is attached, can you give it a try whether it changes something for you?
Thanks!

Honza
-- 
Jan Kara 
SUSE Labs, CR
>From 59ab3a8504c35e2215af6c251bdb2a8a1caca1dd Mon Sep 17 00:00:00 2001
From: Jan Kara 
Date: Wed, 16 Jan 2019 11:02:48 +0100
Subject: [PATCH] mm: migrate: Make buffer_migrate_page_norefs() actually
 succeed

Currently, buffer_migrate_page_norefs() was constantly failing because
buffer_migrate_lock_buffers() grabbed reference on each buffer. In fact,
there's no reason for buffer_migrate_lock_buffers() to grab any buffer
references as the page is locked during all our operation and thus
nobody can reclaim buffers from the page. So remove grabbing of buffer
references which also makes buffer_migrate_page_norefs() succeed.

Fixes: 89cb0888ca14 "mm: migrate: provide buffer_migrate_page_norefs()"
Signed-off-by: Jan Kara 
---
 mm/migrate.c | 5 -
 1 file changed, 5 deletions(-)

Andrew, can you please merge this patch? Sadly my previous testing only tested
that page migration in general didn't get broken but I forgot to test whether
the new migrate page callback actually results in more successful migrations
for block device pages. So the bug got only revealed by customer testing. Now
I've reproduced the workload internally and verified that the patch indeed
fixes the issue.

diff --git a/mm/migrate.c b/mm/migrate.c
index a16b15090df3..712b231a7376 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -709,7 +709,6 @@ static bool buffer_migrate_lock_buffers(struct buffer_head *head,
 	/* Simple case, sync compaction */
 	if (mode != MIGRATE_ASYNC) {
 		do {
-			get_bh(bh);
 			lock_buffer(bh);
 			bh = bh->b_this_page;
 
@@ -720,18 +719,15 @@ static bool buffer_migrate_lock_buffers(struct buffer_head *head,
 
 	/* async case, we cannot block on lock_buffer so use trylock_buffer */
 	do {
-		get_bh(bh);
 		if (!trylock_buffer(bh)) {
 			/*
 			 * We failed to lock the buffer and cannot stall in
 			 * async migration. Release the taken locks
 			 */
 			struct buffer_head *failed_bh = bh;
-			put_bh(failed_bh);
 			bh = head;
 			while (bh != failed_bh) {
 unlock_buffer(bh);
-put_bh(bh);
 bh = bh->b_this_page;
 			}
 			return false;
@@ -818,7 +814,6 @@ static int __buffer_migrate_page(struct address_space *mapping,
 	bh = head;
 	do {
 		unlock_buffer(bh);
-		put_bh(bh);
 		bh = bh->b_this_page;
 
 	} while (bh != head);
-- 
2.16.4

Re: [PATCH] KVM: x86: Sync the pending Posted-Interrupts

[Paolo Bonzini]

On 28/01/19 09:08, Kang, Luwei wrote:
>> However, you should at least change the comment in vcpu_enter_guest to 
>> mention "before reading PIR" instead of "before reading
>> PIR.ON".
> 
> Will do that. I think the "checking PIR.ON" should be PID.ON. I will fix it.

Yes.

>> Alternatively, would it be possible to instead set ON when SN is
>> cleared?  The clearing of SN is in pi_clear_sn, and you would have instead
>> something like

> 
> SN is cleared when the corresponding vCPU is running on pCPU. I think we 
> can't set ON when SN is cleared.  Because there have some words in VT-d spec 
> 9.12:
> If ON is set at the time of hardware posting an interrupt to PIR field, 
> notification event is not generated.

This is okay, because you are setting ON and vmx_sync_pir_to_irr will
read ON before the next vCPU entry and move the interrupts from PIR to IRR.

Paolo

>>
>>  WRITE_ONCE(u16 *)&pi_desc->on_sn, POSTED_INTR_ON);
> 
> We already have a function  (pi_test_on) to check the bit of POSTED_INTR_ON. 
> So I think it is unnecessary.
> 
> Thanks,
> Luwei Kang
> 
>>
>> where on_sn is added to struct pi_desc like this:
>>
>> @@ -61,4 +60,5 @@ struct pi_desc {
>>  u32 ndst;
>>  };
>> +u16 on_sn;
>>  u64 control;
>>  };
>>
>> Paolo

[PATCH V2 2/6] clocksource: tegra: add Tegra210 timer driver

[Joseph Lo]

Add support for the Tegra210 timer that runs at oscillator clock
(TMR10-TMR13). We need these timers to work as clock event device and to
replace the ARMv8 architected timer due to it can't survive across the
power cycle of the CPU core or CPUPORESET signal. So it can't be a wake-up
source when CPU suspends in power down state.

Based on the work of Antti P Miettinen 

Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Joseph Lo 
---
v2:
 * add error clean-up code
---
 drivers/clocksource/Kconfig  |   3 +
 drivers/clocksource/Makefile |   1 +
 drivers/clocksource/timer-tegra210.c | 268 +++
 include/linux/cpuhotplug.h   |   1 +
 4 files changed, 273 insertions(+)
 create mode 100644 drivers/clocksource/timer-tegra210.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a9e26f6a81a1..e6e3e64b6320 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -135,6 +135,9 @@ config TEGRA_TIMER
help
  Enables support for the Tegra driver.
 
+config TEGRA210_TIMER
+   def_bool ARCH_TEGRA_210_SOC
+
 config VT8500_TIMER
bool "VT8500 timer driver" if COMPILE_TEST
depends on HAS_IOMEM
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index cdd210ff89ea..95de59c8a47b 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_SUN4I_TIMER) += timer-sun4i.o
 obj-$(CONFIG_SUN5I_HSTIMER)+= timer-sun5i.o
 obj-$(CONFIG_MESON6_TIMER) += timer-meson6.o
 obj-$(CONFIG_TEGRA_TIMER)  += timer-tegra20.o
+obj-$(CONFIG_TEGRA210_TIMER)   += timer-tegra210.o
 obj-$(CONFIG_VT8500_TIMER) += timer-vt8500.o
 obj-$(CONFIG_NSPIRE_TIMER) += timer-zevio.o
 obj-$(CONFIG_BCM_KONA_TIMER)   += bcm_kona_timer.o
diff --git a/drivers/clocksource/timer-tegra210.c 
b/drivers/clocksource/timer-tegra210.c
new file mode 100644
index ..477b164e540b
--- /dev/null
+++ b/drivers/clocksource/timer-tegra210.c
@@ -0,0 +1,268 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2014-2019, NVIDIA CORPORATION.  All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static u32 tegra210_timer_freq;
+static void __iomem *tegra210_timer_reg_base;
+static u32 usec_config;
+
+#define TIMER_PTV  0x0
+#define TIMER_PTV_EN   BIT(31)
+#define TIMER_PTV_PER  BIT(30)
+#define TIMER_PCR  0x4
+#define TIMER_PCR_INTR_CLR BIT(30)
+#define TIMERUS_CNTR_1US   0x10
+#define TIMERUS_USEC_CFG   0x14
+
+#define TIMER10_OFFSET 0x90
+#define TIMER10_IRQ_IDX10
+
+#define TIMER_FOR_CPU(cpu) (TIMER10_OFFSET + (cpu) * 8)
+#define IRQ_IDX_FOR_CPU(cpu)   (TIMER10_IRQ_IDX + cpu)
+
+struct tegra210_clockevent {
+   struct clock_event_device evt;
+   char name[20];
+   void __iomem *reg_base;
+};
+#define to_tegra_cevt(p) (container_of(p, struct tegra210_clockevent, evt))
+
+static struct tegra210_clockevent __percpu *tegra210_evt;
+
+static int tegra210_timer_set_next_event(unsigned long cycles,
+struct clock_event_device *evt)
+{
+   struct tegra210_clockevent *tevt;
+
+   tevt = to_tegra_cevt(evt);
+   writel(TIMER_PTV_EN |
+  ((cycles > 1) ? (cycles - 1) : 0), /* n+1 scheme */
+  tevt->reg_base + TIMER_PTV);
+
+   return 0;
+}
+
+static inline void timer_shutdown(struct tegra210_clockevent *tevt)
+{
+   writel(0, tevt->reg_base + TIMER_PTV);
+}
+
+static int tegra210_timer_shutdown(struct clock_event_device *evt)
+{
+   struct tegra210_clockevent *tevt;
+
+   tevt = to_tegra_cevt(evt);
+   timer_shutdown(tevt);
+
+   return 0;
+}
+
+static int tegra210_timer_set_periodic(struct clock_event_device *evt)
+{
+   struct tegra210_clockevent *tevt;
+
+   tevt = to_tegra_cevt(evt);
+   writel(TIMER_PTV_EN | TIMER_PTV_PER | ((tegra210_timer_freq / HZ) - 1),
+  tevt->reg_base + TIMER_PTV);
+
+   return 0;
+}
+
+static irqreturn_t tegra210_timer_isr(int irq, void *dev_id)
+{
+   struct tegra210_clockevent *tevt;
+
+   tevt = dev_id;
+   writel(TIMER_PCR_INTR_CLR, tevt->reg_base + TIMER_PCR);
+   tevt->evt.event_handler(&tevt->evt);
+
+   return IRQ_HANDLED;
+}
+
+static int tegra210_timer_setup(unsigned int cpu)
+{
+   struct tegra210_clockevent *tevt = per_cpu_ptr(tegra210_evt, cpu);
+
+   irq_force_affinity(tevt->evt.irq, cpumask_of(cpu));
+   enable_irq(tevt->evt.irq);
+
+   clockevents_config_and_register(&tevt->evt, tegra210_timer_freq,
+   1, /* min */
+   0x1fff); /* 29 bits */
+
+   return 0;
+}
+
+static int tegra210_timer_stop(unsigned int cpu)
+{
+   struct tegra210_clockevent *tevt = per_

Re: [linux-next] kcompactd0 stuck in a CPU-burning loop

[Vlastimil Babka]

On 1/28/19 9:57 AM, Sergey Senozhatsky wrote:
> Hello,
> 
> next-20190125
> 
> kcompactd0 is spinning on something, burning CPUs in the meantime:

Hi, could you check/add this to the earlier thread? Thanks.

https://lore.kernel.org/lkml/2019012625.GB27513@amd/T/#u

> 
>  %CPU TIME+  COMMAND
>  100.0   0.0  34:04.20 R [kcompactd0]
> 
> Not sure I know how to reproduce it; so am probably not going to
> be a very helpful tester.
> 
> I tried to ftrace kcompactd0 PID, and I see the same path all over
> the tracing file:
> 
>  2)   0.119 us|unlock_page();
>  2)   0.109 us|unlock_page();
>  2)   0.096 us|compaction_free();
>  2)   0.104 us|___might_sleep();
>  2)   0.121 us|compaction_alloc();
>  2)   0.111 us|page_mapped();
>  2)   0.105 us|page_mapped();
>  2)   |move_to_new_page() {
>  2)   0.102 us|  page_mapping();
>  2)   |  buffer_migrate_page_norefs() {
>  2)   |__buffer_migrate_page() {
>  2)   |  expected_page_refs() {
>  2)   0.118 us|page_mapping();
>  2)   0.321 us|  }
>  2)   |  __might_sleep() {
>  2)   0.122 us|___might_sleep();
>  2)   0.332 us|  }
>  2)   |  _raw_spin_lock() {
>  2)   0.115 us|preempt_count_add();
>  2)   0.321 us|  }
>  2)   |  _raw_spin_unlock() {
>  2)   0.114 us|preempt_count_sub();
>  2)   0.321 us|  }
>  2)   |  invalidate_bh_lrus() {
>  2)   |on_each_cpu_cond() {
>  2)   |  on_each_cpu_cond_mask() {
>  2)   |__might_sleep() {
>  2)   0.114 us|  ___might_sleep();
>  2)   0.316 us|}
>  2)   0.109 us|preempt_count_add();
>  2)   0.128 us|has_bh_in_lru();
>  2)   0.105 us|has_bh_in_lru();
>  2)   0.124 us|has_bh_in_lru();
>  2)   0.103 us|has_bh_in_lru();
>  2)   0.125 us|has_bh_in_lru();
>  2)   0.105 us|has_bh_in_lru();
>  2)   0.123 us|has_bh_in_lru();
>  2)   0.107 us|has_bh_in_lru();
>  2)   |on_each_cpu_mask() {
>  2)   0.104 us|  preempt_count_add();
>  2)   0.110 us|  smp_call_function_many();
>  2)   0.105 us|  preempt_count_sub();
>  2)   0.764 us|}
>  2)   0.116 us|preempt_count_sub();
>  2)   3.676 us|  }
>  2)   3.889 us|}
>  2)   4.087 us|  }
>  2)   |  _raw_spin_lock() {
>  2)   0.112 us|preempt_count_add();
>  2)   0.315 us|  }
>  2)   |  _raw_spin_unlock() {
>  2)   0.108 us|preempt_count_sub();
>  2)   0.309 us|  }
>  2)   |  unlock_buffer() {
>  2)   |wake_up_bit() {
>  2)   0.118 us|  __wake_up_bit();
>  2)   0.317 us|}
>  2)   0.513 us|  }
>  2)   7.440 us|}
>  2)   7.643 us|  }
>  2)   8.070 us|}
> 
> 
> PG migration fails a lot:
> 
> pgmigrate_success 111063
> pgmigrate_fail 269841559
> compact_migrate_scanned 536253365
> compact_free_scanned 360889
> compact_isolated 270072733
> compact_stall 0
> compact_fail 0
> compact_success 0
> compact_daemon_wake 56
> compact_daemon_migrate_scanned 536253365
> compact_daemon_free_scanned 360889
> 
> Let me know if I can help with anything else. I'll keep the the box alive
> for a while, but will have to power it off eventually.
> 
>   -ss
> 

[PATCH V2 1/6] dt-bindings: timer: add Tegra210 timer

[Joseph Lo]

The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit
timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived
from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock
(TMR10-TMR13). Each TMR can be programmed to generate one-shot periodic,
or watchdog interrupts.

Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: Joseph Lo 
Reviewed-by: Rob Herring 
---
v2:
 * list all the interrupts that are supported by tegra210 timers block
 * add RB tag from Rob.
---
 .../bindings/timer/nvidia,tegra210-timer.txt  | 36 +++
 1 file changed, 36 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt 
b/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt
new file mode 100644
index ..032cda96fe0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt
@@ -0,0 +1,36 @@
+NVIDIA Tegra210 timer
+
+The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit
+timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived
+from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock
+(TMR10-TMR13). Each TMR can be programmed to generate one-shot, periodic,
+or watchdog interrupts.
+
+Required properties:
+- compatible : "nvidia,tegra210-timer".
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 14 interrupts; one per each timer channels 0 through
+  13.
+- clocks : Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
+
+timer@60005000 {
+   compatible = "nvidia,tegra210-timer";
+   reg = <0x0 0x60005000 0x0 0x400>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   clocks = <&tegra_car TEGRA210_CLK_TIMER>;
+   clock-names = "timer";
+};
-- 
2.20.1

Re: [PATCH 3/6] x86: kvm: no need to check return value of debugfs_create functions

[Paolo Bonzini]

On 26/01/19 14:53, Greg Kroah-Hartman wrote:
> Ah, yes, sorry, I missed that.  I'll respin the patch with this change
> in it in a few days.

Just drop this patch.  I'll post the kvm_vm_ioctl_create_vcpu patch as a
replacement for this one and your other debugfs_create patch for virt/kvm.

Thanks,

Paolo

Re: [PATCH v9 02/26] arm64: Remove unused daif related functions/macros

[Marc Zyngier]

On Mon, 21 Jan 2019 15:33:21 +,
Julien Thierry  wrote:
> 
> There are some helpers to modify PSR.[DAIF] bits that are not referenced
> anywhere. The less these bits are available outside of local_irq_*
> functions the better.
> 
> Get rid of those unused helpers.
> 
> Signed-off-by: Julien Thierry 
> Reviewed-by: Mark Rutland 
> Acked-by: Catalin Marinas 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: James Morse 

Acked-by: Marc Zyngier 

M.

-- 
Jazz is not dead, it just smell funny.

Add Ingenic X1000 serial support.

[Zhou Yanjie]

Add Ingenic X1000 serial support.

Re: [PATCH v1 3/3] drivers/tty: increase priority for tty_buffer_worker

[Oleksij Rempel]

On 28.01.19 09:23, Greg Kroah-Hartman wrote:

On Mon, Jan 28, 2019 at 09:05:30AM +0100, Oleksij Rempel wrote:



On 10.01.19 17:30, Greg Kroah-Hartman wrote:

On Thu, Jan 10, 2019 at 04:19:53PM +0100, Oleksij Rempel wrote:

My gut feel is that if somebody still cares deeply about serial line
latency, they should look at trying to see if they can do some of the
work directly without the bounce to the workqueue. We use workqueues
for a reason, but it's possible that some of it could be avoided at
least in special cases... And yours sounds like a special case.


It is for industrial low latency RS-422 based application. The loopback
test is just easy way to test/reproduce it without additional hardware.

What is good, mainlineable way to implement it?


What is the real problem your systems are having?  Are they serial-port
limited?  Is latency a big issue?  Trying to tune for a fake workload
isn't the best way to solve anything :)


The system in question is a high power laser cutter with live image-based 
inspection
and adjustment of the cutting process. In this setup the RS422 interface is 
used to
control parameters of the laser cutting unit in a tie control loop with the 
camera.
This loops needs to operate at 1000 Hz.

The xy-stage moves with a speed of approx. 60m/min, i.e. within 1ms it
moves about 1mm. For a high precision control process a jitter of ± 500 us (+/- 
0.5mm)
is unacceptable.


Are you using the rt kernel patch for this type of thing?  That should
bound your jitter at a much more deterministic level.


Yes, I tested it with different linux-rt version with mostly similar results:
kernel 4.8.15-rt10+
latency histogram:
0 ... < 250 usec : 1933104 transmissions
  250 ... < 500 usec : 21339 transmissions
  500 ... < 750 usec : 8952 transmissions
  750 ... <1000 usec : 6226 transmissions
 1000 ... <1500 usec : 7688 transmissions
 1500 ... <2000 usec : 5236 transmissions
 2000 ... <5000 usec : 11724 transmissions
 5000 ... <   1 usec : 3588 transmissions
1 ... <   5 usec : 2123 transmissions
5 ... < 100 usec : 20 transmissions
 >= 100 usec : 0 transmissions

kernel 4.9.0-rt1+
latency histogram:
0 ... < 250 usec : 1950222 transmissions
  250 ... < 500 usec : 15041 transmissions
  500 ... < 750 usec : 5968 transmissions
  750 ... <1000 usec : 4437 transmissions
 1000 ... <1500 usec : 6022 transmissions
 1500 ... <2000 usec : 4185 transmissions
 2000 ... <5000 usec : 9864 transmissions
 5000 ... <   1 usec : 2773 transmissions
1 ... <   5 usec : 1462 transmissions
5 ... < 100 usec : 26 transmissions
 >= 100 usec : 0 transmissions

4.19.10-rt8
latency histogram:
0 ... < 250 usec : 1906861 transmissions
  250 ... < 500 usec : 35271 transmissions
  500 ... < 750 usec : 13103 transmissions
  750 ... <1000 usec : 9084 transmissions
 1000 ... <1500 usec : 9434 transmissions
 1500 ... <2000 usec : 5644 transmissions
 2000 ... <5000 usec : 12737 transmissions
 5000 ... <   1 usec : 4511 transmissions
1 ... <   5 usec : 3201 transmissions
5 ... < 100 usec : 154 transmissions
 >= 100 usec : 0 transmissions


without extra CPU load the result on kernel 4.19.10-rt8 will be:
latency histogram:
0 ... < 250 usec : 192 transmissions
  250 ... < 500 usec : 8 transmissions
  500 ... < 750 usec : 0 transmissions
  750 ... <1000 usec : 0 transmissions
 1000 ... <1500 usec : 0 transmissions
 1500 ... <2000 usec : 0 transmissions
 2000 ... <5000 usec : 0 transmissions
 5000 ... <   1 usec : 0 transmissions
1 ... <   5 usec : 0 transmissions
5 ... < 100 usec : 0 transmissions
 >= 100 usec : 0 transmissions
=


test results with same load and replaced kworker with kthread and assigned an 
RT priority

min latency: 0 sec : 75 usec
max latency: 0 sec : 125 usec
average latency: 81 usec
latency measure cycles overall: 7900
latency histogram:
0 ... < 250 usec : 7900 transmissions
  250 ... < 500 usec : 0 transmissions
  500 ... < 750 usec : 0 transmissions
  750 ... <1000 usec : 0 transmissions
 1000 ... <1500 usec : 0 transmissions
 1500 ... <2000 usec : 0 transmissions
 2000 ... <5000 usec : 0 transmissions
 5000 ... <   1 usec : 0 transmissions
  

Re: [PATCH v9 03/26] arm64: cpufeature: Set SYSREG_GIC_CPUIF as a boot system feature

[Marc Zyngier]

On Mon, 21 Jan 2019 15:33:22 +,
Julien Thierry  wrote:
> 
> It is not supported to have some CPUs using GICv3 sysreg CPU interface
> while some others do not.
> 
> Once ICC_SRE_EL1.SRE is set on a CPU, the bit cannot be cleared. Since
> matching this feature require setting ICC_SRE_EL1.SRE, it cannot be
> turned off if found on a CPU.
> 
> Set the feature as STRICT_BOOT, if boot CPU has it, all other CPUs are
> required to have it.
> 
> Signed-off-by: Julien Thierry 
> Suggested-by: Daniel Thompson 
> Reviewed-by: Suzuki K Poulose 
> Reviewed-by: Mark Rutland 
> Acked-by: Catalin Marinas 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Suzuki K Poulose 
> Cc: Marc Zyngier 

Acked-by: Marc Zyngier 

M.

-- 
Jazz is not dead, it just smell funny.

[PATCH 2/2] Serial: Ingenic: Add support for the X1000.

[Zhou Yanjie]

Add support for probing the 8250_ingenic driver on the
X1000 Soc from Ingenic.

Signed-off-by: Zhou Yanjie 
---
 Documentation/devicetree/bindings/serial/ingenic,uart.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/serial/ingenic,uart.txt 
b/Documentation/devicetree/bindings/serial/ingenic,uart.txt
index c3c6406..24ed876 100644
--- a/Documentation/devicetree/bindings/serial/ingenic,uart.txt
+++ b/Documentation/devicetree/bindings/serial/ingenic,uart.txt
@@ -6,7 +6,8 @@ Required properties:
   - "ingenic,jz4760-uart",
   - "ingenic,jz4770-uart",
   - "ingenic,jz4775-uart",
-  - "ingenic,jz4780-uart".
+  - "ingenic,jz4780-uart",
+  - "ingenic,x1000-uart".
 - reg : offset and length of the register set for the device.
 - interrupts : should contain uart interrupt.
 - clocks : phandles to the module & baud clocks.
-- 
2.7.4

[PATCH 1/2] Serial: Ingenic: Add support for the X1000.

[Zhou Yanjie]

Add support for probing the 8250_ingenic driver on the
X1000 Soc from Ingenic.

Signed-off-by: Zhou Yanjie 
---
 drivers/tty/serial/8250/8250_ingenic.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_ingenic.c 
b/drivers/tty/serial/8250/8250_ingenic.c
index 15a8c8d..1999e3b 100644
--- a/drivers/tty/serial/8250/8250_ingenic.c
+++ b/drivers/tty/serial/8250/8250_ingenic.c
@@ -145,6 +145,10 @@ EARLYCON_DECLARE(jz4780_uart, ingenic_early_console_setup);
 OF_EARLYCON_DECLARE(jz4780_uart, "ingenic,jz4780-uart",
ingenic_early_console_setup);
 
+EARLYCON_DECLARE(x1000_uart, ingenic_early_console_setup);
+OF_EARLYCON_DECLARE(x1000_uart, "ingenic,x1000-uart",
+   ingenic_early_console_setup);
+
 static void ingenic_uart_serial_out(struct uart_port *p, int offset, int value)
 {
int ier;
@@ -328,12 +332,18 @@ static const struct ingenic_uart_config 
jz4780_uart_config = {
.fifosize = 64,
 };
 
+static const struct ingenic_uart_config x1000_uart_config = {
+   .tx_loadsz = 32,
+   .fifosize = 64,
+};
+
 static const struct of_device_id of_match[] = {
{ .compatible = "ingenic,jz4740-uart", .data = &jz4740_uart_config },
{ .compatible = "ingenic,jz4760-uart", .data = &jz4760_uart_config },
{ .compatible = "ingenic,jz4770-uart", .data = &jz4760_uart_config },
{ .compatible = "ingenic,jz4775-uart", .data = &jz4760_uart_config },
{ .compatible = "ingenic,jz4780-uart", .data = &jz4780_uart_config },
+   { .compatible = "ingenic,x1000-uart", .data = &x1000_uart_config },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, of_match);
-- 
2.7.4

Re: [PATCH v9 04/26] arm64: cpufeature: Add cpufeature for IRQ priority masking

[Marc Zyngier]

On Mon, 21 Jan 2019 15:33:23 +,
Julien Thierry  wrote:
> 
> Add a cpufeature indicating whether a cpu supports masking interrupts
> by priority.
> 
> The feature will be properly enabled in a later patch.
> 
> Signed-off-by: Julien Thierry 
> Reviewed-by: Suzuki K Poulose 
> Reviewed-by: Mark Rutland 
> Acked-by: Catalin Marinas 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Marc Zyngier 
> Cc: Suzuki K Poulose 

Acked-by: Marc Zyngier 

M.

-- 
Jazz is not dead, it just smell funny.

RE: [PATCH v5 4/4] perf/smmuv3_pmu: Enable HiSilicon Erratum 162001800 quirk

[Shameerali Kolothum Thodi]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 25 January 2019 18:33
> To: Shameerali Kolothum Thodi ;
> lorenzo.pieral...@arm.com
> Cc: jean-philippe.bruc...@arm.com; will.dea...@arm.com;
> mark.rutl...@arm.com; Guohanjun (Hanjun Guo) ;
> John Garry ; pa...@codeaurora.org;
> vkil...@codeaurora.org; rruig...@codeaurora.org; linux-a...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Linuxarm
> ; neil.m.lee...@gmail.com
> Subject: Re: [PATCH v5 4/4] perf/smmuv3_pmu: Enable HiSilicon Erratum
> 162001800 quirk
> 
> On 30/11/2018 15:47, Shameer Kolothum wrote:
> > HiSilicon erratum 162001800 describes the limitation of
> > SMMUv3 PMCG implementation on HiSilicon Hip08 platforms.
> >
> > On these platforms, the PMCG event counter registers
> > (SMMU_PMCG_EVCNTRn) are read only and as a result it
> > is not possible to set the initial counter period value
> > on event monitor start.
> >
> > To work around this, the current value of the counter
> > is read and used for delta calculations. OEM information
> > from ACPI header is used to identify the affected hardware
> > platforms.
> >
> > Signed-off-by: Shameer Kolothum 
> > ---
> >   drivers/acpi/arm64/iort.c | 30 +++---
> >   drivers/perf/arm_smmuv3_pmu.c | 35
> +--
> >   include/linux/acpi_iort.h |  3 +++
> >   3 files changed, 59 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 2da08e1..d174379 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -1364,6 +1364,22 @@ static void __init
> arm_smmu_v3_pmcg_init_resources(struct resource *res,
> >ACPI_EDGE_SENSITIVE, &res[2]);
> >   }
> >
> > +static struct acpi_platform_list pmcg_evcntr_rdonly_list[] __initdata = {
> > +   /* HiSilicon Erratum 162001800 */
> > +   {"HISI  ", "HIP08   ", 0, ACPI_SIG_IORT, greater_than_or_equal},
> > +   { }
> > +};
> > +
> > +static int __init arm_smmu_v3_pmcg_add_platdata(struct platform_device
> *pdev)
> > +{
> > +   u32 options = 0;
> > +
> > +   if (acpi_match_platform_list(pmcg_evcntr_rdonly_list) >= 0)
> > +   options |= IORT_PMCG_EVCNTR_RDONLY;
> 
> Hmm, do we want IORT code to have to understand a (potential) whole load
> of PMCG-specific quirks directly, or do we really only need to pass some
> unambiguous identifier for the PMCG implementation, and let the driver
> handle the details in private - much like the SMMU model field, only
> without an external spec to constrain us :)

Could do that, but was not sure about coming up with an identifier which is not
really part of the spec and placing that in IORT code. Personally I prefer 
having
all this private to driver rather than in IORT code. But I see your point that 
this
will be more like smmu if we can pass identifiers here. 

> If we ever want to have named imp-def events, we'd need to do something
> like that anyway, so perhaps we might be better off taking that approach
> to begin with (and if so, I'd be inclined to push the basic platdata
> initialisation for "generic PMCG" into patch #1).

Ok. I will give that a try in next respin.

> > +
> > +   return platform_device_add_data(pdev, &options, sizeof(options));
> > +}
> > +
> >   struct iort_dev_config {
> > const char *name;
> > int (*dev_init)(struct acpi_iort_node *node);
> > @@ -1374,6 +1390,7 @@ struct iort_dev_config {
> >  struct acpi_iort_node *node);
> > void (*dev_set_proximity)(struct device *dev,
> > struct acpi_iort_node *node);
> > +   int (*dev_add_platdata)(struct platform_device *pdev);
> >   };
> >
> >   static const struct iort_dev_config iort_arm_smmu_v3_cfg __initconst = {
> > @@ -1395,6 +1412,7 @@ static const struct iort_dev_config
> iort_arm_smmu_v3_pmcg_cfg __initconst = {
> > .name = "arm-smmu-v3-pmu",
> > .dev_count_resources = arm_smmu_v3_pmcg_count_resources,
> > .dev_init_resources = arm_smmu_v3_pmcg_init_resources,
> > +   .dev_add_platdata   = arm_smmu_v3_pmcg_add_platdata,
> >   };
> >
> >   static __init const struct iort_dev_config *iort_get_dev_cfg(
> > @@ -1455,10 +1473,16 @@ static int __init
> iort_add_platform_device(struct acpi_iort_node *node,
> > goto dev_put;
> >
> > /*
> > -* Add a copy of IORT node pointer to platform_data to
> > -* be used to retrieve IORT data information.
> > +* Platform devices based on PMCG nodes uses platform_data to
> > +* pass quirk flags to the driver. For others, add a copy of
> > +* IORT node pointer to platform_data to be used to retrieve
> > +* IORT data information.
> >  */
> > -   ret = platform_device_add_data(pdev, &node, sizeof(node));
> > +   if (ops->dev_add_platdata)
> > +   ret = ops->dev_add_platdata(pdev);
> > +   else
> > +   ret = platform_devi

Re: [PATCH v9 05/26] arm/arm64: gic-v3: Add PMR and RPR accessors

[Marc Zyngier]

On Mon, 21 Jan 2019 15:33:24 +,
Julien Thierry  wrote:
> 
> Add helper functions to access system registers related to interrupt
> priorities: PMR and RPR.
> 
> Signed-off-by: Julien Thierry 
> Reviewed-by: Mark Rutland 
> Acked-by: Catalin Marinas 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Marc Zyngier 

Reviewed-by: Marc Zyngier 

M.

-- 
Jazz is not dead, it just smell funny.

Re: [PATCH 5/5] dax: "Hotplug" persistent memory for use like normal RAM

[Michal Hocko]

On Fri 25-01-19 11:15:08, Dan Williams wrote:
[...]
> However, we should consider this along with the userspace enabling to
> control which device-dax instances are set aside for hotplug. It would
> make sense to have a "clear errors before hotplug" configuration
> option.

I am not sure I understand. Do you mean to clear HWPoison when the
memory is hotadded (add_pages) or onlined (resp. move_pfn_range_to_zone)?
-- 
Michal Hocko
SUSE Labs

Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller

[Miquel Raynal]

Hi Naga,

Naga Sureshkumar Relli  wrote on Mon, 28 Jan 2019
06:04:53 +:

> Hi Boris & Miquel,
> 
> Could you please provide your thoughts on this driver to support HW-ECC?
> As I said previously, there is no way to detect errors beyond N bit.
> I am ok to update the driver based on your inputs.

We won't support the ECC engine. It simply cannot be used reliably.

I am working on a generic ECC engine object. It's gonna take a few
months until it gets merged but after that you could update the
controller driver to drop any ECC-related function. Although the ECC
engine part is blocking, raw access still look wrong and the driver
still needs changes.


Thanks,
Miquèl

Re: [PATCH V3,0/8] make mt7623 clock of HDMI stable

[CK Hu]

Hi, Wangyan:

How do you prove that this series would make mt7623 HDMI clock more
stable? By experience result? I would like to prove it by the source
code.

Does 'stable' means that hardware could generate the frequency most
close to the target frequency? If it does, I think you could compare the
frequency generated by original code and applying this series for all
the usually-used frequency. I also need you to show the clock tree and
all setting of each divider so we could review that is this series good
enough. Also, describe these in cover latter.

You have mail to dri-devel [1] and linux-mediatek [2], but these patches
does not show in web site. Maybe your mail is not plain text, please fix
this and resend patches.

[1] https://lists.freedesktop.org/archives/dri-devel/
[2] http://lists.infradead.org/pipermail/linux-mediatek/

Regards,
CK

On Fri, 2019-01-25 at 12:01 +0800, Wangyan Wang wrote:
> V3 adopt maintainer's suggestion.
> Here is the change list between V2 & V3:
> 1. add "Signed-off-by: wangyan wang "
> in commit message
> 
> 2. add modify description in patch 
> "drm/mediatek: fix the rate and divder ..."
>  
> chunhui dai (8):
>   drm/mediatek: recalculate hdmi phy clock of MT2701 by querying
> hardware
>   drm/mediatek: move the setting of fixed divider
>   drm/mediatek: using different flags of clk for HDMI phy
>   drm/mediatek: fix the rate and divder of hdmi phy for MT2701
>   clk: mediatek: add MUX_GATE_FLAGS_2
>   clk: mediatek: using CLK_MUX_ROUND_CLOSEST for the clock of dpi1_sel
>   drm/mediatek: using new factor for tvdpll in MT2701
>   drm/mediatek: fix the rate of parent for hdmi phy in MT2701
> 
>  drivers/clk/mediatek/clk-mt2701.c |  4 +-
>  drivers/clk/mediatek/clk-mtk.c|  2 +-
>  drivers/clk/mediatek/clk-mtk.h| 20 +--
>  drivers/gpu/drm/mediatek/mtk_dpi.c|  8 +--
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.c   | 34 +++
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.h   |  7 +--
>  .../gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c| 56 +--
>  .../gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c| 23 
>  8 files changed, 102 insertions(+), 52 deletions(-)
> 

Re: [PATCH] kcov: convert kcov.refcount to refcount_t

[Peter Zijlstra]

On Sun, Jan 27, 2019 at 06:41:38PM +, Reshetova, Elena wrote:
> > On Mon, Jan 21, 2019 at 11:05:03AM -0500, Alan Stern wrote:
> > > On Mon, 21 Jan 2019, Peter Zijlstra wrote:

> > Yes, that's a very good suggestion.
> > 
> > I suppose we can add smp_acquire__after_ctrl_dep() on the true branch.
> > Then it reall does become rel_acq.
> > 
> > A wee something like so (I couldn't find an arm64 refcount, even though
> > I have distinct memories of talk about it).
> > 
> > This isn't compiled, and obviously needs comment/documentation updates
> > to go along with it.
> > 
> > ---
> >  arch/x86/include/asm/refcount.h | 9 -
> >  lib/refcount.c  | 7 ++-
> >  2 files changed, 14 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/refcount.h 
> > b/arch/x86/include/asm/refcount.h
> > index dbaed55c1c24..6f7a1eb345b4 100644
> > --- a/arch/x86/include/asm/refcount.h
> > +++ b/arch/x86/include/asm/refcount.h
> > @@ -74,9 +74,16 @@ bool refcount_sub_and_test(unsigned int i, refcount_t *r)
> > 
> >  static __always_inline __must_check bool refcount_dec_and_test(refcount_t 
> > *r)
> >  {
> > -   return GEN_UNARY_SUFFIXED_RMWcc(LOCK_PREFIX "decl",
> > +   bool ret = GEN_UNARY_SUFFIXED_RMWcc(LOCK_PREFIX "decl",
> > 
> > REFCOUNT_CHECK_LT_ZERO,
> > r-
> > >refs.counter, e, "cx");
> > +
> > +   if (ret) {
> > +   smp_acquire__after_ctrl_dep();
> > +   return true;
> > +   }
> > +
> > +   return false;
> >  }
> 
> Actually as I started to do this, any reason why the change here only
> for dec_and_test and not for sub_and _test also? Should not the arch.
> specific logic follow the generic?

Yes, sub_and_test also needs it; I simply overlooked it.

Re: [PATCH v5 1/5] dmaengine: imx-sdma: add clock ratio 1:1 check

[Lucas Stach]

Am Sonntag, den 27.01.2019, 23:08 -0700 schrieb Angus Ainslie (Purism):
> On i.mx8 mscale B0 chip, AHB/SDMA clock ratio 2:1 can't be supportted,
> since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach
> to 500Mhz, so use 1:1 instead.
> 
> Based on NXP commit MLK-16841-1 by Robin Gong 
> 
> Signed-off-by: Angus Ainslie (Purism) 

Reviewed-by: Lucas Stach 

> ---
>  drivers/dma/imx-sdma.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 0b3a67ff8e82..757fad2fbfae 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -440,6 +440,8 @@ struct sdma_engine {
>   unsigned intirq;
>   dma_addr_t  bd0_phys;
>   struct sdma_buffer_descriptor   *bd0;
> + /* clock ratio for AHB:SDMA core. 1:1 is 1, 2:1 is 0*/
> + boolclk_ratio;
>  };
>  
>  static int sdma_config_write(struct dma_chan *chan,
> @@ -662,8 +664,11 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
>   dev_err(sdma->dev, "Timeout waiting for CH0 ready\n");
>  
>   /* Set bits of CONFIG register with dynamic context switching */
> - if (readl(sdma->regs + SDMA_H_CONFIG) == 0)
> - writel_relaxed(SDMA_H_CONFIG_CSM, sdma->regs + SDMA_H_CONFIG);
> + reg = readl(sdma->regs + SDMA_H_CONFIG);
> + if ((reg & SDMA_H_CONFIG_CSM) == 0) {
> + reg |= SDMA_H_CONFIG_CSM;
> + writel_relaxed(reg, sdma->regs + SDMA_H_CONFIG);
> + }
>  
>   return ret;
>  }
> @@ -1840,6 +1845,9 @@ static int sdma_init(struct sdma_engine *sdma)
>   if (ret)
>   goto disable_clk_ipg;
>  
> + if (clk_get_rate(sdma->clk_ahb) == clk_get_rate(sdma->clk_ipg))
> + sdma->clk_ratio = 1;
> +
>   /* Be sure SDMA has not started yet */
>   writel_relaxed(0, sdma->regs + SDMA_H_C0PTR);
>  
> @@ -1880,8 +1888,10 @@ static int sdma_init(struct sdma_engine *sdma)
>   writel_relaxed(0x4050, sdma->regs + SDMA_CHN0ADDR);
>  
>   /* Set bits of CONFIG register but with static context switching */
> - /* FIXME: Check whether to set ACR bit depending on clock ratios */
> - writel_relaxed(0, sdma->regs + SDMA_H_CONFIG);
> + if (sdma->clk_ratio)
> + writel_relaxed(SDMA_H_CONFIG_ACR, sdma->regs + SDMA_H_CONFIG);
> + else
> + writel_relaxed(0, sdma->regs + SDMA_H_CONFIG);
>  
>   writel_relaxed(ccb_phys, sdma->regs + SDMA_H_C0PTR);
>  

Re: [PATCH 1/2] Serial: Ingenic: Add support for the X1000.

[Greg KH]

On Mon, Jan 28, 2019 at 05:19:35PM +0800, Zhou Yanjie wrote:
> Add support for probing the 8250_ingenic driver on the
> X1000 Soc from Ingenic.
> 
> Signed-off-by: Zhou Yanjie 
> ---
>  drivers/tty/serial/8250/8250_ingenic.c | 10 ++
>  1 file changed, 10 insertions(+)

You sent two different patches with the same subject: line, yet they did
totally different things.

Please fix this up and resend with a better set of subject lines.

thanks,

greg k-h

Re: [PATCH v9 06/26] irqchip/gic-v3: Switch to PMR masking before calling IRQ handler

[Marc Zyngier]

On Mon, 21 Jan 2019 15:33:25 +,
Julien Thierry  wrote:
> 
> Mask the IRQ priority through PMR and re-enable IRQs at CPU level,
> allowing only higher priority interrupts to be received during interrupt
> handling.
> 
> Signed-off-by: Julien Thierry 
> Acked-by: Catalin Marinas 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Thomas Gleixner 
> Cc: Jason Cooper 
> Cc: Marc Zyngier 

Acked-by: Marc Zyngier 

M.

-- 
Jazz is not dead, it just smell funny.

Re: [PATCH v5 2/5] dmaengine: imx-sdma: add imx8mq sdma compatible parts

[Lucas Stach]

Am Sonntag, den 27.01.2019, 23:08 -0700 schrieb Angus Ainslie (Purism):
> This is identical to the imx7d.

So it can be dropped and the i.MX8M DT should just specify the
"fsl,imx7d-sdma" as a fallback compatible for the SDMA codes.

If both the imx8m and imx7d compatible are present in the DT, we can
introduce a more specific matchic when we actually need it. No need to
pollute the code with this from the start.

Regards,
Lucas

> Signed-off-by: Angus Ainslie (Purism) 
> ---
>  drivers/dma/imx-sdma.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 757fad2fbfae..c4db4fe6bcc9 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -578,6 +578,9 @@ static const struct platform_device_id
> sdma_devtypes[] = {
>   }, {
>   .name = "imx7d-sdma",
>   .driver_data = (unsigned long)&sdma_imx7d,
> + }, {
> + .name = "imx8mq-sdma",
> + .driver_data = (unsigned long)&sdma_imx7d,
>   }, {
>   /* sentinel */
>   }
> @@ -592,6 +595,7 @@ static const struct of_device_id sdma_dt_ids[] =
> {
>   { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, },
>   { .compatible = "fsl,imx25-sdma", .data = &sdma_imx25, },
>   { .compatible = "fsl,imx7d-sdma", .data = &sdma_imx7d, },
> + { .compatible = "fsl,imx8mq-sdma", .data = &sdma_imx7d, },
>   { /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, sdma_dt_ids);

Re: [PATCH v5 4/5] dmaengine: imx-sdma: add a test for imx8mq multi sdma devices

[Lucas Stach]

Am Sonntag, den 27.01.2019, 23:08 -0700 schrieb Angus Ainslie (Purism):
> On i.mx8mq, there are two sdma instances, and the common dma framework
> will get a channel dynamically from any available sdma instance whether
> it's the first sdma device or the second sdma device. Some IPs like
> SAI only work with sdma2 not sdma1. To make sure the sdma channel is from
> the correct sdma device, use the node pointer to match.
> 
> Signed-off-by: Angus Ainslie (Purism) 

Reviewed-by: Lucas Stach 

> ---
>  drivers/dma/imx-sdma.c| 6 ++
>  include/linux/platform_data/dma-imx.h | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index c4db4fe6bcc9..d5f86becf59e 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -1918,11 +1918,16 @@ static int sdma_init(struct sdma_engine *sdma)
>  static bool sdma_filter_fn(struct dma_chan *chan, void *fn_param)
>  {
>   struct sdma_channel *sdmac = to_sdma_chan(chan);
> + struct sdma_engine *sdma = sdmac->sdma;
>   struct imx_dma_data *data = fn_param;
>  
>   if (!imx_dma_is_general_purpose(chan))
>   return false;
>  
> + /* return false if it's not the right device */
> + if (sdma->dev->of_node != data->of_node)
> + return false;
> +
>   sdmac->data = *data;
>   chan->private = &sdmac->data;
>  
> @@ -1950,6 +1955,7 @@ static struct dma_chan *sdma_xlate(struct 
> of_phandle_args *dma_spec,
>* be set to sdmac->event_id1.
>*/
>   data.dma_request2 = 0;
> + data.of_node = ofdma->of_node;
>  
>   return dma_request_channel(mask, sdma_filter_fn, &data);
>  }
> diff --git a/include/linux/platform_data/dma-imx.h 
> b/include/linux/platform_data/dma-imx.h
> index 7d964e787299..9daea8d42a10 100644
> --- a/include/linux/platform_data/dma-imx.h
> +++ b/include/linux/platform_data/dma-imx.h
> @@ -55,6 +55,7 @@ struct imx_dma_data {
>   int dma_request2; /* secondary DMA request line */
>   enum sdma_peripheral_type peripheral_type;
>   int priority;
> + struct device_node *of_node;
>  };
>  
>  static inline int imx_dma_is_ipu(struct dma_chan *chan)

[PATCH RESEND] KVM: MMU: Introduce single thread to zap collapsible sptes

[Wanpeng Li]

From: Wanpeng Li 

Last year guys from huawei reported that the call of 
memory_global_dirty_log_start/stop() 
takes 13s for 4T memory and cause guest freeze too long which increases the 
unacceptable 
migration downtime. [1] [2]

Guangrong pointed out:

| collapsible_sptes zaps 4k mappings to make memory-read happy, it is not
| required by the semanteme of KVM_SET_USER_MEMORY_REGION and it is not
| urgent for vCPU's running, it could be done in a separate thread and use
| lock-break technology.

Several TB memory guest is common now after NVDIMM is deployed in cloud 
environment.
This patch utilizes worker thread to zap collapsible sptes in order to lazy 
collapse 
small sptes into large sptes during roll-back after live migration fails.

[1] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05249.html
[2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg449994.html

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
Note:
I ever consider to add a list of memslots to be zapped, delete from the list
and add in kvm_mmu_zap_collapsible_sptes(). However, i observe a lot of races 
here, the memslot can disappear/modify underneath before the worker thread
start to zap even if i introduce lock to protect the list. This patch delays 
the worker thread by 60s(to assume memory_global_dirty_log_stop can absolutely 
complete) to coalesce all the zap requirements after live migration fails.

 arch/x86/include/asm/kvm_host.h |  3 +++
 arch/x86/kvm/mmu.c  | 37 -
 arch/x86/kvm/x86.c  |  4 
 3 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index fbda5a9..dde32f9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -892,6 +892,8 @@ struct kvm_arch {
u64 master_cycle_now;
struct delayed_work kvmclock_update_work;
struct delayed_work kvmclock_sync_work;
+   struct delayed_work kvm_mmu_zap_collapsible_sptes_work;
+   bool zap_in_progress;
 
struct kvm_xen_hvm_config xen_hvm_config;
 
@@ -1247,6 +1249,7 @@ void kvm_mmu_zap_all(struct kvm *kvm);
 void kvm_mmu_invalidate_mmio_sptes(struct kvm *kvm, struct kvm_memslots 
*slots);
 unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm);
 void kvm_mmu_change_mmu_pages(struct kvm *kvm, unsigned int kvm_nr_mmu_pages);
+void zap_collapsible_sptes_fn(struct work_struct *work);
 
 int load_pdptrs(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, unsigned long cr3);
 bool pdptrs_changed(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7c03c0f..fe87dd3 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5679,14 +5679,41 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm 
*kvm,
return need_tlb_flush;
 }
 
+void zap_collapsible_sptes_fn(struct work_struct *work)
+{
+   struct kvm_memory_slot *memslot;
+   struct kvm_memslots *slots;
+   struct delayed_work *dwork = to_delayed_work(work);
+   struct kvm_arch *ka = container_of(dwork, struct kvm_arch,
+  kvm_mmu_zap_collapsible_sptes_work);
+   struct kvm *kvm = container_of(ka, struct kvm, arch);
+   int i;
+
+   mutex_lock(&kvm->slots_lock);
+   for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
+   spin_lock(&kvm->mmu_lock);
+   slots = __kvm_memslots(kvm, i);
+   kvm_for_each_memslot(memslot, slots) {
+   slot_handle_leaf(kvm, (struct kvm_memory_slot *)memslot,
+   kvm_mmu_zap_collapsible_spte, true);
+   if (need_resched() || spin_needbreak(&kvm->mmu_lock))
+   cond_resched_lock(&kvm->mmu_lock);
+   }
+   spin_unlock(&kvm->mmu_lock);
+   }
+   kvm->arch.zap_in_progress = false;
+   mutex_unlock(&kvm->slots_lock);
+}
+
+#define KVM_MMU_ZAP_DELAYED (60 * HZ)
 void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
   const struct kvm_memory_slot *memslot)
 {
-   /* FIXME: const-ify all uses of struct kvm_memory_slot.  */
-   spin_lock(&kvm->mmu_lock);
-   slot_handle_leaf(kvm, (struct kvm_memory_slot *)memslot,
-kvm_mmu_zap_collapsible_spte, true);
-   spin_unlock(&kvm->mmu_lock);
+   if (!kvm->arch.zap_in_progress) {
+   kvm->arch.zap_in_progress = true;
+   
schedule_delayed_work(&kvm->arch.kvm_mmu_zap_collapsible_sptes_work,
+   KVM_MMU_ZAP_DELAYED);
+   }
 }
 
 void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d029377..c2af289 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9019,6 +9019,9 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
 
INIT_DELAYED_WORK(&kvm->arch.kvmclock_update_work, kvmclock_updat

RE: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller

[Naga Sureshkumar Relli]

Hi Miquel,


> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Monday, January 28, 2019 2:58 PM
> To: Naga Sureshkumar Relli 
> Cc: r...@kernel.org; marek.va...@gmail.com; rich...@nod.at; 
> martin.lund@keep-it-
> simple.com; linux-kernel@vger.kernel.org; Boris Brezillon 
> ;
> linux-...@lists.infradead.org; nagasures...@gmail.com; Michal Simek
> ; computersforpe...@gmail.com; dw...@infradead.org
> Subject: Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for 
> Arasan
> NAND Flash Controller
> 
> Hi Naga,
> 
> Naga Sureshkumar Relli  wrote on Mon, 28 Jan 2019
> 06:04:53 +:
> 
> > Hi Boris & Miquel,
> >
> > Could you please provide your thoughts on this driver to support HW-ECC?
> > As I said previously, there is no way to detect errors beyond N bit.
> > I am ok to update the driver based on your inputs.
> 
> We won't support the ECC engine. It simply cannot be used reliably.
> 
> I am working on a generic ECC engine object. It's gonna take a few months 
> until it gets
> merged but after that you could update the controller driver to drop any 
> ECC-related
> function. Although the ECC engine part is blocking, raw access still look 
> wrong and the
> driver still needs changes.

Thank you for the update.
Yes, currently ECC engine part is blocking.
Also whenever you have time, please provide your comments to the driver v12 
patch.
I will update those.

Thanks,
Naga Sureshkumar Relli
> 
> 
> Thanks,
> Miquèl

Re: [-next] mtd: docg3: Fix passing zero to 'PTR_ERR' warning in doc_probe_device

[Boris Brezillon]

On Wed, 2019-01-23 at 06:58:27 UTC, YueHaibing wrote:
> Fix a static code checker warning:
> drivers/mtd/devices/docg3.c:1875
>  doc_probe_device() warn: passing zero to 'ERR_PTR'
> 
> Fixes: ae9d4934b2d7 ("mtd: docg3: add multiple floor support")
> Signed-off-by: YueHaibing 
> Acked-by: Robert Jarzmik 

Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks.

Boris

Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI

[Jagan Teki]

On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard  wrote:
>
> On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote:
> > Minimum PLL used for MIPI is 500MHz, as per manual, but
> > lowering the min rate by 300MHz can result proper working
> > nkms divider with the help of desired dclock rate from
> > panel driver.
> >
> > Signed-off-by: Jagan Teki 
> > Acked-by: Stephen Boyd 
>
> Going 200MHz below the minimum doesn't seem really reasonable. What
> is the issue that you are trying to fix here?
>
> It looks like it's picking bad dividers, but if that's the case, this
> isn't the proper fix.

As I stated in earlier patches, the whole idea is pick the desired
dclk divider based dclk rate. So the dotclock, sun4i_dclk_round_rate
is unable to get the proper dclk divider at the end, so it eventually
picking up wrong divider value and fired vblank timeout.

So, we come-up with optimal and working min_rate 300MHz in pll-mipi to
get the desired clock something like below.
[2.415773] [drm] No driver support for vblank timestamp query.
[2.424116] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = 5500
[2.424172] ideal = 22000, rounded = 0
[2.424176] ideal = 27500, rounded = 0
[2.424194] ccu_nkm_round_rate: rate = 33000
[2.424197] ideal = 33000, rounded = 33000
[2.424201] sun4i_dclk_round_rate: div = 6 rate = 5500
[2.424205] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = 5500
[2.424209] ideal = 22000, rounded = 0
[2.424213] ideal = 27500, rounded = 0
[2.424230] ccu_nkm_round_rate: rate = 33000
[2.424233] ideal = 33000, rounded = 33000
[2.424236] sun4i_dclk_round_rate: div = 6 rate = 5500
[2.424253] ccu_nkm_round_rate: rate = 33000
[2.424270] ccu_nkm_round_rate: rate = 33000
[2.424278] sun4i_dclk_recalc_rate: val = 1, rate = 33000
[2.424281] sun4i_dclk_recalc_rate: val = 1, rate = 33000
[2.424306] ccu_nkm_set_rate: rate = 33000, parent_rate = 29700
[2.424309] ccu_nkm_set_rate: _nkm.n = 5
[2.424311] ccu_nkm_set_rate: _nkm.k = 2
[2.424313] ccu_nkm_set_rate: _nkm.m = 9
[2.424661] sun4i_dclk_set_rate div 6
[2.424668] sun4i_dclk_recalc_rate: val = 6, rate = 5500

But look like this wouldn't valid for all other dclock rates, say BPI
panel has 30MHz clock that would failed with this logic.

On the other side Allwinner BSP calculating dclk divider based on the
SoC's. for A33 [1] it is fixed dclk divider of 4 and for A64 is is
calculated based on the bpp/lanes.

Since the above min_rate is not desired for possible panels clock, I
think we can rely on BSP to make a move here. I'm planning to do these
changes in next version.

Let me know if you have any comments here?

[1] https://patchwork.kernel.org/patch/10777519/

Re: [v4,-next] mtd: docg3: fix a possible memory leak of mtd->name

[Boris Brezillon]

On Fri, 2019-01-25 at 02:12:42 UTC, YueHaibing wrote:
> In case DOC_CHIPID_G3, mtd->name is not freed in err handling path,
> which is alloced by kasprintf(). Fix this by using devm_kasprintf().
> 
> Fixes: ae9d4934b2d7 ("mtd: docg3: add multiple floor support")
> Signed-off-by: YueHaibing 

Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks.

Boris

Re: [PATCH v9 07/26] arm64: ptrace: Provide definitions for PMR values

[Marc Zyngier]

On Mon, 21 Jan 2019 15:33:26 +,
Julien Thierry  wrote:
> 
> Introduce fixed values for PMR that are going to be used to mask and
> unmask interrupts by priority.
> 
> The current priority given to GIC interrupts is 0xa0, so clearing PMR's
> most significant bit is enough to mask interrupts.
> 
> Signed-off-by: Julien Thierry 
> Suggested-by: Daniel Thompson 
> Acked-by: Catalin Marinas 
> Cc: Oleg Nesterov 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> ---
>  arch/arm64/include/asm/ptrace.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index fce22c4..05cf913 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -25,6 +25,18 @@
>  #define CurrentEL_EL1(1 << 2)
>  #define CurrentEL_EL2(2 << 2)
>  
> +/*
> + * PMR values used to mask/unmask interrupts.
> + *
> + * GIC priority masking works as follows: if an IRQ's priority is a higher 
> value
> + * than the value held in PMR, that interrupt is masked. A lower value of PMR
> + * means more IRQ priorities are masked.

Nit: It is not the priorities that are masked, but interrupts that
have a priority higher than that of PMR.

> + *
> + * To mask priorities, we clear the most significant bit of PMR.
> + */
> +#define GIC_PRIO_IRQON   0xf0
> +#define GIC_PRIO_IRQOFF  (GIC_PRIO_IRQON & ~0x80)
> +
>  /* Additional SPSR bits not exposed in the UABI */
>  #define PSR_IL_BIT   (1 << 20)
>  
> -- 
> 1.9.1
> 

Otherwise:

Acked-by: Marc Zyngier 

M.

-- 
Jazz is not dead, it just smell funny.

Re: [PATCH v9 08/26] arm64: Make PMR part of task context

[Marc Zyngier]

On Mon, 21 Jan 2019 15:33:27 +,
Julien Thierry  wrote:
> 
> In order to replace PSR.I interrupt disabling/enabling with ICC_PMR_EL1
> interrupt masking, ICC_PMR_EL1 needs to be saved/restored when
> taking/returning from an exception. This mimics the way hardware saves
> and restores PSR.I bit in spsr_el1 for exceptions and ERET.
> 
> Add PMR to the registers to save in the pt_regs struct upon kernel entry,
> and restore it before ERET. Also, initialize it to a sane value when
> creating new tasks.
> 
> Signed-off-by: Julien Thierry 
> Reviewed-by: Catalin Marinas 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Oleg Nesterov 
> Cc: Dave Martin 

Reviewed-by: Marc Zyngier 

M.

-- 
Jazz is not dead, it just smell funny.

[PATCH] iommu/io-pgtable-arm-v7s: only kmemleak_ignore L2 tables

[Nicolas Boichat]

L1 tables are allocated with __get_dma_pages, and therefore already
ignored by kmemleak.

Without this, the kernel would print this error message on boot,
when the first L1 table is allocated:

[2.810533] kmemleak: Trying to color unknown object at 0xffd652388000 
as Black
[2.818190] CPU: 5 PID: 39 Comm: kworker/5:0 Tainted: G S
4.19.16 #8
[2.831227] Workqueue: events deferred_probe_work_func
[2.836353] Call trace:
...
[2.852532]  paint_ptr+0xa0/0xa8
[2.855750]  kmemleak_ignore+0x38/0x6c
[2.859490]  __arm_v7s_alloc_table+0x168/0x1f4
[2.863922]  arm_v7s_alloc_pgtable+0x114/0x17c
[2.868354]  alloc_io_pgtable_ops+0x3c/0x78
...

Fixes: e5fc9753b1a8314 ("iommu/io-pgtable: Add ARMv7 short descriptor support")
Signed-off-by: Nicolas Boichat 
---

I only tested this on top of my other series
(https://patchwork.kernel.org/patch/10720495/), but I think the same fix
applies. I'm still a bit confused as to why this only shows up now, as IIUC,
the kmemleak_ignore call was always wrong with L1 tables.

 drivers/iommu/io-pgtable-arm-v7s.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c 
b/drivers/iommu/io-pgtable-arm-v7s.c
index cec29bf45c9bd7..98a4a4a0dfb0c1 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -217,7 +217,8 @@ static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
if (dma != phys)
goto out_unmap;
}
-   kmemleak_ignore(table);
+   if (lvl == 2)
+   kmemleak_ignore(table);
return table;
 
 out_unmap:
-- 
2.20.1.495.gaa96b0ce6b-goog

Re: [PATCH] mtd: nand: fix kernel-doc warnings

[Boris Brezillon]

On Sun, 27 Jan 2019 18:21:42 -0800
Randy Dunlap  wrote:

> From: Randy Dunlap 
> 
> Fix kernel-doc warnings in drivers/mtd/nand/raw:
> 
> ../drivers/mtd/nand/raw/nand_base.c:420: warning: Function parameter or 
> member 'chip' not described in 'nand_fill_oob'
> ../drivers/mtd/nand/raw/nand_bbt.c:173: warning: Function parameter or member 
> 'this' not described in 'read_bbt'
> ../drivers/mtd/nand/raw/nand_bbt.c:173: warning: Excess function parameter 
> 'chip' description in 'read_bbt'
> 
> Signed-off-by: Randy Dunlap 
> Cc: Boris Brezillon 
> Cc: Miquel Raynal 
> Cc: Richard Weinberger 
> Cc: linux-...@lists.infradead.org
> ---
> Do you want Fixes: tags for these:
> 
> Fixes: 0813621ba898a ("mtd: rawnand: Stop passing mtd_info objects to 
> internal functions")

Will add this one.

> Fixes: 99f3351a6d6e0 ("mtd: rawnand: Reorganize code to avoid forward 
> declarations")

Well, I don't think that one is responsible for the new warnings since
all I did was moving code around.

Thanks,

Boris

> 
>  drivers/mtd/nand/raw/nand_base.c |1 +
>  drivers/mtd/nand/raw/nand_bbt.c  |2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> --- lnx-50-rc4.orig/drivers/mtd/nand/raw/nand_base.c
> +++ lnx-50-rc4/drivers/mtd/nand/raw/nand_base.c
> @@ -410,6 +410,7 @@ static int nand_check_wp(struct nand_chi
>  
>  /**
>   * nand_fill_oob - [INTERN] Transfer client buffer to oob
> + * @chip: NAND chip object
>   * @oob: oob data buffer
>   * @len: oob data write length
>   * @ops: oob ops structure
> --- lnx-50-rc4.orig/drivers/mtd/nand/raw/nand_bbt.c
> +++ lnx-50-rc4/drivers/mtd/nand/raw/nand_bbt.c
> @@ -158,7 +158,7 @@ static u32 add_marker_len(struct nand_bb
>  
>  /**
>   * read_bbt - [GENERIC] Read the bad block table starting from page
> - * @chip: NAND chip object
> + * @this: NAND chip object
>   * @buf: temporary buffer
>   * @page: the starting page
>   * @num: the number of bbt descriptors to read
> 
> 
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v4] kbuild: Add support for DT binding schema checks

[Geert Uytterhoeven]

Hi Rob,

On Tue, Dec 11, 2018 at 9:24 PM Rob Herring  wrote:
> This adds the build infrastructure for checking DT binding schema
> documents and validating dts files using the binding schema.
>
> Check DT binding schema documents:
> make dt_binding_check
>
> Build dts files and check using DT binding schema:
> make dtbs_check
>
> Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
> use for validation. This makes it easier to find and fix errors
> generated by a specific schema.
>
> Currently, the validation targets are separate from a normal build to
> avoid a hard dependency on the external DT schema project and because
> there are lots of warnings generated.
>
> Cc: Jonathan Corbet 
> Cc: Mark Rutland 
> Cc: Masahiro Yamada 
> Cc: Michal Marek 
> Cc: linux-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kbu...@vger.kernel.org
> Signed-off-by: Rob Herring 

BTW, what are the CONFIG dependencies for this to work?
E.g. defconfig on x86_64 fails, even after enabling CONFIG_OF:

$ make dt_binding_check
  SCHEMA  Documentation/devicetree/bindings/processed-schema.yaml
  CHKDT   Documentation/devicetree/bindings/arm/primecell.yaml
  ...
  CHKDT   Documentation/devicetree/bindings/trivial-devices.yaml
make[1]: *** No rule to make target
'Documentation/devicetree/bindings/arm/primecell.example.dtb', needed
by '__build'.  Stop.

Obviously it does work for arm/arm64.

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

Re: [PATCH v9 09/26] arm64: Unmask PMR before going idle

[Marc Zyngier]

On Mon, 21 Jan 2019 15:33:28 +,
Julien Thierry  wrote:
> 
> CPU does not received signals for interrupts with a priority masked by
> ICC_PMR_EL1. This means the CPU might not come back from a WFI
> instruction.
> 
> Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI.
> 
> Since the logic of cpu_do_idle is becoming a bit more complex than just
> two instructions, lets turn it from ASM to C.
> 
> Signed-off-by: Julien Thierry 
> Suggested-by: Daniel Thompson 
> Cc: Catalin Marinas 
> Cc: Will Deacon 

Reviewed-by: Marc Zyngier 

M.

-- 
Jazz is not dead, it just smell funny.