Re: [PATCH 1/2] PM-runtime: Take suppliers into account in __pm_runtime_set_status()
On Tue, 12 Feb 2019 at 00:05, Rafael J. Wysocki wrote: > > On Mon, Feb 11, 2019 at 4:51 PM Ulf Hansson wrote: > > > > On Mon, 11 Feb 2019 at 14:27, Ulf Hansson wrote: > > > > > > On Thu, 7 Feb 2019 at 19:46, Rafael J. Wysocki wrote: > > > > > > > > From: Rafael J. Wysocki > > > > > > > > If the target device has any suppliers, as reflected by device links > > > > to them, __pm_runtime_set_status() does not take them into account, > > > > which is not consistent with the other parts of the PM-runtime > > > > framework and may lead to programming mistakes. > > > > > > > > Modify __pm_runtime_set_status() to take suppliers into account by > > > > activating them upfront if the new status is RPM_ACTIVE and > > > > deactivating them on exit if the new status is RPM_SUSPENDED. > > > > > > > > If the activation of one of the suppliers fails, the new status > > > > will be RPM_SUSPENDED and the (remaining) suppliers will be > > > > deactivated on exit (the child count of the device's parent > > > > will be dropped too then). > > > > > > > > Of course, adding device links locking to __pm_runtime_set_status() > > > > means that it cannot be run fron interrupt context, so make it use > > > > spin_lock_irq() and spin_unlock_irq() instead of spin_lock_irqsave() > > > > and spin_unlock_irqrestore(), respectively. > > > > > > > > Signed-off-by: Rafael J. Wysocki > > > > > > Rafael, thanks for working on this! > > > > > > I am running some tests at my side, but still not achieving the > > > behavior I expect to. Will let you know when I have more details, but > > > first some comments below. > > > > Alright, this is what I found. > > > > When I call pm_runtime_set_suspended(), in the ->probe() error path of > > my RPM test driver (I am removing the device link afterwards), then my > > expectation was that this should allow the supplier to become runtime > > suspended (sooner or later). This isn't the case, as it turns out the > > runtime PM usage count of the supplier, still remains 1 after the > > probe failure. > > > > My observation is that with $subject patch, the link->rpm_active count > > is now reaching 1, before it stayed at 2 - so one step forward. :-) > > > > However, the reason to why the runtime PM usage count never reaches 0, > > is because of the call to pm_runtime_get_noresume(supplier) in > > device_link_rpm_prepare(), which is called from device_link_add(). > > That was there previously, I've just moved it to device_link_rpm_prepare(). Correct. The problem been there before. Even without using DL_FLAG_RPM_ACTIVE. > > But good catch! > > > To solve the problem, it seems like we need to call > > pm_runtime_put(supplier), in case the device link is deleted while the > > consumer is still probing. > > I'd rather change the way pm_runtime_get/put_suppliers() work, so that > they use the rpm_active refcount, but pm_runtime_put_suppliers() only > drops it by one - unless it is one already. That seems like a very reasonable approach! The mix between calling pm_runtime_get/put*() on the supplier device directly vs using the path with the rpm_active count, is to me rather confusing. Using only the latter, would be a nice cleanup anyway, I think. > > Then, when adding a new link with DL_FLAG_RPM_ACTIVE, > device_link_add() only needs to increment its rpm_active *twice* > (instead of doing that once as to does now), so it will stay above one > after the subsequent pm_runtime_put_suppliers() - and if it goes away > in the meantime, then it will be cleaned up by the removal. Assuming you will add a check for "consumer->links.status == DL_DEV_PROBING" to understand if rpm_active should by be decreased. Yes, it seems reasonable. > > In turn, if a link is created without DL_FLAG_RPM_ACTIVE, its > rpm_active is one and then pm_runtime_put_suppliers() will just skip > it. > > A patch will follow. :-) Great, I am here to review it. :-) Kind regards Uffe
Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs
On 12.02.19 at 01:56, Andrew Morton wrote: On Sat, 9 Feb 2019 12:35:03 +0200 Andy Shevchenko wrote: On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton wrote: On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko wrote: On Tue, Oct 30, 2018 at 5:22 PM David Engraf wrote: Unpacking an external initrd may fail e.g. not enough memory. This leads to an incomplete rootfs because some files might be extracted already. Fixed by cleaning the rootfs so the kernel is not using an incomplete rootfs. This breaks my setup where I have U-boot provided more size of initramfs than needed. This allows a bit of flexibility to increase or decrease initramfs compressed image without taking care of bootloader. The proper solution is to do this if we sure that we didn't get enough memory, otherwise I can't consider the error fatal to clean up rootfs. OK, thanks. Maybe David can suggest a fix - I'll queue up a revert meanwhile. I don't really understand the failure. Why does an oversized initramfs cause unpack_to_rootfs() to fail? In my case I have got "Junk in compressed archive". I don't know (I would check if needed) which exact condition I got since there are three places with this message. Well that's a plain irritating screwup right there. Could someone please cook up a patch to give us three distinct (and hopefully more informative) error messages? Done. BTW "invalid magic at start of compressed archive" is the error we get with the patch. Best regards - David
Re: [PATCH v2 0/4] Add max77620 charging & low battery support
On Tue, 12 Feb 2019, Mark Zhang wrote: > On 2/7/2019 4:48 PM, Lee Jones wrote: > > On Tue, 29 Jan 2019, Mark Zhang wrote: > > > >> This patch set adds support for max77620 backup battery charging and > >> low battery monitoring. > >> > >> Changes in v2: > >> - Add devicetree binding documentation > >> > >> Mark Zhang (4): > >> mfd: max77620: Add backup battery charger support > >> mfd: max77620: add documentation for backup battery charging > >> mfd: max77620: Add low battery monitor support > >> mfd: max77620: add documentation for low battery monitoring > >> > >> .../devicetree/bindings/mfd/max77620.txt | 34 + > >> drivers/mfd/max77620.c| 137 +- > > > > All of this needs moving out to the correct subsystem. > > > > drivers/power/supply/max77620-battery.c looks right. > > Actually max77620 is not a power supply device. This patch set adds 2 > features: > - Backup battery charger. The RTC in max77620 is supplied from a backup > battery and consumes 2.0uA when no other power sources are available. So > basically this is not a system battery charger, it's just for RTC. > - Low battery monitoring. This is for monitoring the system main battery > voltage, so max77620 can shutdown or reset the SoC accordingly. But I > think this doesn't conform the idea of "power supply" driver as well. Most other battery handling seems to happen in drivers/power/supply/*.battery*. If that's not the right location, then you need to find a place for it to go. MFDs do not provide useful functionality per say - that is the role of the child devices. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mmc: mmc: Fix HS setting in mmc_hs400_to_hs200()
On 12/02/19 4:04 AM, Chaotian Jing wrote: > On Tue, 2019-02-05 at 15:42 +0200, Adrian Hunter wrote: >> On 5/02/19 3:06 PM, Ulf Hansson wrote: >>> On Mon, 4 Feb 2019 at 14:42, Adrian Hunter wrote: On 4/02/19 12:54 PM, Ulf Hansson wrote: > On Mon, 4 Feb 2019 at 10:58, Adrian Hunter > wrote: >> >> On 1/02/19 10:10 AM, Ulf Hansson wrote: >>> On Fri, 1 Feb 2019 at 02:38, Chaotian Jing >>> wrote: On Thu, 2019-01-31 at 16:58 +0100, Ulf Hansson wrote: > On Thu, 31 Jan 2019 at 08:53, Chaotian Jing > wrote: >> >> mmc_hs400_to_hs200() begins with the card and host in HS400 mode. >> Therefore, any commands sent to the card should use HS400 timing. >> It is incorrect to reduce frequency to 50Mhz before sending the >> switch >> command, in this case, only reduce clock frequency to 50Mhz but >> without >> host timming change, host is still in hs400 mode but clock changed >> from >> 200Mhz to 50Mhz, which makes the tuning result unsuitable and cause >> the switch command gets response CRC error. > > According the eMMC spec there is no violation by decreasing the clock > frequency like this. We can use whatever value <=200MHz. > > However, perhaps in practice this becomes an issue, due to the tuning > for HS400 has been done on the "current" frequency. > > As as start, I think you need to clarify this in the changelog. > Yes, reduce clock frequency to 50Mhz is no Spec violation, but it may cause __mmc_switch() gets response CRC error, decreasing the clock but without HOST mode change, on the host side, host driver do not know what's operation the core layer want to do and can only set current bus clock to 50Mhz, without tuning parameter change, it has a chance lead to response CRC error. even lower clock frequency, but with the wrong tuning parameter setting(the setting is of hs400 tuning @200Mhz). >>> >>> Right, makes sense. >>> >> >> this patch refers to mmc_select_hs400(), make the reduce clock >> frequency >> after card timing change. >> >> Signed-off-by: Chaotian Jing >> --- >> drivers/mmc/core/mmc.c | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c >> index da892a5..21b811e 100644 >> --- a/drivers/mmc/core/mmc.c >> +++ b/drivers/mmc/core/mmc.c >> @@ -1239,10 +1239,6 @@ int mmc_hs400_to_hs200(struct mmc_card *card) >> int err; >> u8 val; >> >> - /* Reduce frequency to HS */ >> - max_dtr = card->ext_csd.hs_max_dtr; >> - mmc_set_clock(host, max_dtr); >> - > > As far as I can tell, the reason to why we change the clock frequency > *before* the call to __mmc_switch() below, is probably to try to be on > the safe side and conform to the spec. > Agree, it Must be more safe with lower clock frequency, but the precondition is to make the host side recognize current timing is not HS400 mode. it has no method to find a safe setting to ensure no response CRC error when reduce clock from 200Mhz to 50Mhz. > However, I think you have a point, as the call to __mmc_switch(), > passes the "send_status" parameter as false, no other command than the > CMD6 is sent to the card. > yes, the send status command was sent only after __mmc_switch() done. >> /* Switch HS400 to HS DDR */ >> val = EXT_CSD_TIMING_HS; >> err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, >> EXT_CSD_HS_TIMING, >> @@ -1253,6 +1249,10 @@ int mmc_hs400_to_hs200(struct mmc_card *card) >> >> mmc_set_timing(host, MMC_TIMING_MMC_DDR52); >> >> + /* Reduce frequency to HS */ >> + max_dtr = card->ext_csd.hs_max_dtr; >> + mmc_set_clock(host, max_dtr); >> + > > Perhaps it's even more correct to change the clock frequency before > the call to mmc_set_timing(host, MMC_TIMING_MMC_DDR52). Otherwise you > will be using the DDR52 timing in the controller, but with a too high > frequency. > for Our host, it has no impact to change the clock before or after change timing, as the mmc_set_timing() is only for host side, not related to MMC card side and no commands sent do card before the timing/clock change completed. >>> >>> Alright. After a second thought, it actually looks more consistent >>> with mmc_select_hs400() to do it af
Re: [PATCH v3 1/4] mfd: max77620: Add backup battery charger support
On Tue, 12 Feb 2019, Mark Zhang wrote: > Add PMIC configurations for backup battery charger, which > is a constant voltage and constant current style charger > with a series output resistance. > > The max77620 register CNFGBBC(addr: 0x04) defines the > parameters of backup battery charger. This patch adds > support for it. > > Signed-off-by: Laxman Dewangan > Signed-off-by: Venkat Reddy Talla > Signed-off-by: Mark Zhang > --- > drivers/mfd/max77620.c | 80 ++ > 1 file changed, 80 insertions(+) My previous review comments still apply. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v9 1/3] /proc/pid/status: Add support for architecture specific output
On Tue, 12 Feb 2019, Aubrey Li wrote:
> The architecture specific information of the running processes could
> be useful to the userland. Add support to examine process architecture
> specific information externally.
>
> Signed-off-by: Aubrey Li
> Cc: Peter Zijlstra
> Cc: Andi Kleen
> Cc: Tim Chen
> Cc: Dave Hansen
> Cc: Arjan van de Ven
> ---
> fs/proc/array.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index 0ceb3b6b37e7..d8cb5b5fd7bb 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -392,6 +392,10 @@ static inline void task_core_dumping(struct seq_file *m,
> struct mm_struct *mm)
> seq_putc(m, '\n');
> }
>
> +void __weak arch_proc_pid_status(struct seq_file *m, struct task_struct
> *task)
> +{
> +}
This still lacks a prototype.
Thanks,
tglx
Re: RFC: drop ISA support in the synlink tty driver?
On 12. 02. 19, 8:51, Greg Kroah-Hartman wrote: > On Mon, Feb 11, 2019 at 02:25:33PM +0100, Christoph Hellwig wrote: >> Hi Greg and Jiri, >> >> I've been working hard to get rid of the remaining callers the pass a >> NULL struct device to the DMA mapping functions and am almost done. >> >> The only non-trivial driver is the synclink driver, which has legacy >> early 90s style ISA support that doesn't use the device model at all. >> >> In theory we could convert it to an isa_driver, but without testing >> that seems rather dangerous. So for now I would suggest that we >> remove the ISA support in this driver - if anyone cares enough we >> can resurrect it from the git history and convert it to use the driver >> model. > > No objection from me at all, I'll go queue this up now, thanks. Agreed, but I would kill also the MGSL_BUS_TYPE_ISA macro proper. thanks, -- js suse labs
Re: [PATCH v2 1/3] mmc: sdhci: use WP GPIO in sdhci_check_ro()
On 11/02/19 3:23 PM, Thomas Petazzoni wrote:
> Even though SDHCI controllers may have a dedicated WP pin that can be
> queried using the SDHCI_PRESENT_STATE register, some platforms may
> chose to use a separate regular GPIO to route the WP signal. Such a
> GPIO is typically represented using the wp-gpios property in the
> Device Tree.
>
> Unfortunately, the current sdhci_check_ro() function does not make use
> of such GPIO when available: it either uses a host controller specific
> ->get_ro() operation, or uses the SDHCI_PRESENT_STATE. Several host
> controller specific ->get_ro() functions are implemented just to check
> a WP GPIO state.
>
> Instead of pushing this to more controller-specific implementations,
> let's handle this in the core SDHCI code, just like it is already done
> for the CD GPIO in sdhci_get_cd().
>
> The below patch simply changes sdhci_check_ro() to use the value of
> the WP GPIO if available. We need to adjust the prototype of the
> function to use a mmc_host* as argument instead of sdhci_host*, since
> the mmc_can_gpio_ro() and mmc_gpio_get_ro() helpers take a mmc_host*.
>
> Signed-off-by: Thomas Petazzoni
> ---
> Changes since v1:
>
> - As suggested by Adrian Hunter, call the ->get_ro() if it exists
>before falling back to using mmc_gpio_get_ro(). Indeed, if the
>controller-specific code has implemented a ->get_ro() callback, it
>should take precedence over what the SDHCI core does.
>
>Due to this change, I have not added Thierry Redding Reviewed-by.
>
> - Fix typo in the commit log noticed by Thierry Redding.
> ---
> drivers/mmc/host/sdhci.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index df05352b6a4a..e6682ea5f7c0 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2022,8 +2022,9 @@ static int sdhci_get_cd(struct mmc_host *mmc)
> return !!(sdhci_readl(host, SDHCI_PRESENT_STATE) & SDHCI_CARD_PRESENT);
> }
>
> -static int sdhci_check_ro(struct sdhci_host *host)
> +static int sdhci_check_ro(struct mmc_host *mmc)
Please let's not change the parameter.
> {
> + struct sdhci_host *host = mmc_priv(mmc);
> unsigned long flags;
> int is_readonly;
>
> @@ -2033,6 +2034,8 @@ static int sdhci_check_ro(struct sdhci_host *host)
> is_readonly = 0;
> else if (host->ops->get_ro)
> is_readonly = host->ops->get_ro(host);
> + else if (mmc_can_gpio_ro(mmc))
> + is_readonly = mmc_gpio_get_ro(mmc);
Just make it 'host->mmc' instead of 'mmc'
> else
> is_readonly = !(sdhci_readl(host, SDHCI_PRESENT_STATE)
> & SDHCI_WRITE_PROTECT);
> @@ -2052,11 +2055,11 @@ static int sdhci_get_ro(struct mmc_host *mmc)
> int i, ro_count;
>
> if (!(host->quirks & SDHCI_QUIRK_UNSTABLE_RO_DETECT))
> - return sdhci_check_ro(host);
> + return sdhci_check_ro(mmc);
>
> ro_count = 0;
> for (i = 0; i < SAMPLE_COUNT; i++) {
> - if (sdhci_check_ro(host)) {
> + if (sdhci_check_ro(mmc)) {
> if (++ro_count > SAMPLE_COUNT / 2)
> return 1;
> }
>
Re: [PATCHv13 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
On Tue, 2019-02-12 at 08:46 +0100, Daniel Vetter wrote:
> On Tue, Feb 12, 2019 at 10:36:23AM +0800, Hean-Loong, Ong via dri-
> devel wrote:
> > From: Ong, Hean Loong
> >
> > Driver for Intel FPGA Video and Image Processing Suite Frame Buffer
> > II.
> > The driver only supports the Intel Arria10 devkit and its variants.
> > This driver can be either loaded staticlly or in modules.
> > The OF device tree binding is located at:
> > Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> >
> > Signed-off-by: Ong, Hean Loong
>
> It looks like your cover letter and patch 2 didn't make it to the
> list
> somehow. Please check those aren't stuck on your side (list admins
> didn't
> see them yet).
>
That's weird my git send-email says everything was okay
> > ---
> > drivers/gpu/drm/Kconfig |2 +
> > drivers/gpu/drm/Makefile |1 +
> > drivers/gpu/drm/ivip/Kconfig | 14 ++
> > drivers/gpu/drm/ivip/Makefile |6 +
> > drivers/gpu/drm/ivip/intel_vip_conn.c | 91 +
> > drivers/gpu/drm/ivip/intel_vip_drv.c | 332
> > +
> > drivers/gpu/drm/ivip/intel_vip_drv.h | 73 +++
> > 7 files changed, 519 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/gpu/drm/ivip/Kconfig
> > create mode 100644 drivers/gpu/drm/ivip/Makefile
> > create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
> > create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.c
> > create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 4385f00..0251a9f 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -235,6 +235,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
> >
> > source "drivers/gpu/drm/i915/Kconfig"
> >
> > +source "drivers/gpu/drm/ivip/Kconfig"
> > +
> > config DRM_VGEM
> > tristate "Virtual GEM provider"
> > depends on DRM
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index ce8d1d3..85a5694 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -63,6 +63,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
> > obj-$(CONFIG_DRM_MGA) += mga/
> > obj-$(CONFIG_DRM_I810) += i810/
> > obj-$(CONFIG_DRM_I915) += i915/
> > +obj-$(CONFIG_DRM_IVIP) += ivip/
> > obj-$(CONFIG_DRM_MGAG200) += mgag200/
> > obj-$(CONFIG_DRM_V3D) += v3d/
> > obj-$(CONFIG_DRM_VC4) += vc4/
> > diff --git a/drivers/gpu/drm/ivip/Kconfig
> > b/drivers/gpu/drm/ivip/Kconfig
> > new file mode 100644
> > index 000..1d08b90
> > --- /dev/null
> > +++ b/drivers/gpu/drm/ivip/Kconfig
> > @@ -0,0 +1,14 @@
> > +config DRM_IVIP
> > +tristate "Intel FGPA Video and Image Processing"
> > +depends on DRM && OF
> > +select DRM_GEM_CMA_HELPER
> > +select DRM_KMS_HELPER
> > +select DRM_KMS_FB_HELPER
> > +select DRM_KMS_CMA_HELPER
> > +help
> > + Choose this option if you have an Intel FPGA
> > Arria 10 system
> > + and above with an Intel Display Port IP. This
> > does not support
> > + legacy Intel FPGA Cyclone V display port.
> > Currently only single
> > + frame buffer is supported. Note that ACPI and
> > X_86 architecture
> > + is not supported for Arria10. If M is selected
> > the module will be
> > + called ivip.
> > diff --git a/drivers/gpu/drm/ivip/Makefile
> > b/drivers/gpu/drm/ivip/Makefile
> > new file mode 100644
> > index 000..8c54e11
> > --- /dev/null
> > +++ b/drivers/gpu/drm/ivip/Makefile
> > @@ -0,0 +1,6 @@
> > +#
> > +# Makefile for the drm device driver. This driver provides
> > support for the
> > +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and
> > higher.
> > +
> > +obj-$(CONFIG_DRM_IVIP) += ivip.o
> > +ivip-objs := intel_vip_drv.o intel_vip_conn.o
> > diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
> > b/drivers/gpu/drm/ivip/intel_vip_conn.c
> > new file mode 100644
> > index 000..93ce0b3
> > --- /dev/null
> > +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
> > @@ -0,0 +1,91 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Intel Corporation.
> > + *
> > + * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
> > + * Frame Buffer II driver
> > + *
> > + * This driver supports the Intel VIP Frame Reader component.
> > + * More info on the hardware can be found in the Intel Video
> > + * and Image Processing Suite User Guide at this address
> > + * http://www.altera.com/literature/ug/ug_vip.pdf.
> > + *
> > + * Authors:
> > + * Walter Goossens
> > + * Thomas Chou
> > + * Chris Rauer
> > + * Ong, Hean-Loong
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static enum drm_connector_status
> > +intelvipfb_drm_connector_detect(struct drm_connector *connector,
> > bool force)
> > +{
> > + return connecto
Re: [PATCH v6 4/5] i2c: ocores: add SPDX tag
On Monday, February 11, 2019 5:54:54 PM CET Wolfram Sang wrote: > On Mon, Feb 11, 2019 at 05:49:12PM +0100, Federico Vaga wrote: > > It adds the SPDX tag and it removes the old text about the GPLv2. > > > > Signed-off-by: Federico Vaga > > I can convert the platform_data header to SPDX again. No need to resend > because of that. Sorry, and thanks
Re: [PATCHv4 10/13] node: Add memory caching attributes
Le 11/02/2019 à 16:23, Keith Busch a écrit : > On Sun, Feb 10, 2019 at 09:19:58AM -0800, Jonathan Cameron wrote: >> On Sat, 9 Feb 2019 09:20:53 +0100 >> Brice Goglin wrote: >> >>> Hello Keith >>> >>> Could we ever have a single side cache in front of two NUMA nodes ? I >>> don't see a way to find that out in the current implementation. Would we >>> have an "id" and/or "nodemap" bitmask in the sidecache structure ? >> This is certainly a possible thing for hardware to do. >> >> ACPI IIRC doesn't provide any means of representing that - your best >> option is to represent it as two different entries, one for each of the >> memory nodes. Interesting question of whether you would then claim >> they were half as big each, or the full size. Of course, there are >> other possible ways to get this info beyond HMAT, so perhaps the interface >> should allow it to be exposed if available? > HMAT doesn't do this, but I want this interface abstracted enough from > HMAT to express whatever is necessary. > > The CPU cache is the closest existing exported attributes to this, > and they provide "shared_cpu_list". To that end, I can export a > "shared_node_list", though previous reviews strongly disliked multi-value > sysfs entries. :( > > Would shared-node symlinks capture the need, and more acceptable? As a user-space guy reading these files/symlinks, I would prefer reading a bitmask just like we do for CPU cache "cpumap" or CPU "siblings" files (or sibling_list). Reading a directory and looking for dentries matching "foo%d" is far less convenient in C. If all these files are inside a dedicated subdirectory, it's better but still not as easy. Brice
Re: [PATCH v2 2/3] mmc: sdhci-omap: drop ->get_ro() implementation
On 11/02/19 3:23 PM, Thomas Petazzoni wrote: > The SDHCI core is now properly checking for the state of a WP GPIO, > so there is no longer any need for the sdhci-omap code to implement > ->get_ro() using mmc_gpio_get_ro(). > > Signed-off-by: Thomas Petazzoni > Reviewed-by: Thierry Reding Acked-by: Adrian Hunter > --- > Changes since v1: > - Added Reviewed-by from Thierry Reding > - Fix typo in commit log s/know/now/ noticed by Thierry Reding > > Note: this patch has only been compiled tested, as I don't have the > hardware to test it. > --- > drivers/mmc/host/sdhci-omap.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c > index d264391616f9..c2a28930086f 100644 > --- a/drivers/mmc/host/sdhci-omap.c > +++ b/drivers/mmc/host/sdhci-omap.c > @@ -987,7 +987,6 @@ static int sdhci_omap_probe(struct platform_device *pdev) > goto err_put_sync; > } > > - host->mmc_host_ops.get_ro = mmc_gpio_get_ro; > host->mmc_host_ops.start_signal_voltage_switch = > sdhci_omap_start_signal_voltage_switch; > host->mmc_host_ops.set_ios = sdhci_omap_set_ios; >
Re: [PATCH v2 3/3] mmc: sdhci-tegra: drop ->get_ro() implementation
On 11/02/19 3:23 PM, Thomas Petazzoni wrote:
> The SDHCI core is know properly checking for the state of a WP GPIO,
> so there is no longer any need for the sdhci-tegra code to implement
> ->get_ro() using mmc_gpio_get_ro().
>
> Signed-off-by: Thomas Petazzoni
> Tested-by: Thierry Reding
> Acked-by: Thierry Reding
Acked-by: Adrian Hunter
> ---
> Changes since v1:
> - Added Tested-by/Acked-by from Thierry Reding
>
> Note: this patch has only been compiled tested, as I don't have the
> hardware to test it.
> ---
> drivers/mmc/host/sdhci-tegra.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index e6ace31e2a41..6ed7323bf030 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -237,11 +237,6 @@ static void tegra210_sdhci_writew(struct sdhci_host
> *host, u16 val, int reg)
> }
> }
>
> -static unsigned int tegra_sdhci_get_ro(struct sdhci_host *host)
> -{
> - return mmc_gpio_get_ro(host->mmc);
> -}
> -
> static bool tegra_sdhci_is_pad_and_regulator_valid(struct sdhci_host *host)
> {
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> @@ -837,7 +832,6 @@ static void tegra_sdhci_voltage_switch(struct sdhci_host
> *host)
> }
>
> static const struct sdhci_ops tegra_sdhci_ops = {
> - .get_ro = tegra_sdhci_get_ro,
> .read_w = tegra_sdhci_readw,
> .write_l= tegra_sdhci_writel,
> .set_clock = tegra_sdhci_set_clock,
> @@ -893,7 +887,6 @@ static const struct sdhci_tegra_soc_data soc_data_tegra30
> = {
> };
>
> static const struct sdhci_ops tegra114_sdhci_ops = {
> - .get_ro = tegra_sdhci_get_ro,
> .read_w = tegra_sdhci_readw,
> .write_w= tegra_sdhci_writew,
> .write_l= tegra_sdhci_writel,
> @@ -947,7 +940,6 @@ static const struct sdhci_tegra_soc_data
> soc_data_tegra124 = {
> };
>
> static const struct sdhci_ops tegra210_sdhci_ops = {
> - .get_ro = tegra_sdhci_get_ro,
> .read_w = tegra_sdhci_readw,
> .write_w= tegra210_sdhci_writew,
> .write_l= tegra_sdhci_writel,
> @@ -980,7 +972,6 @@ static const struct sdhci_tegra_soc_data
> soc_data_tegra210 = {
> };
>
> static const struct sdhci_ops tegra186_sdhci_ops = {
> - .get_ro = tegra_sdhci_get_ro,
> .read_w = tegra_sdhci_readw,
> .write_l= tegra_sdhci_writel,
> .set_clock = tegra_sdhci_set_clock,
>
Re: [PATCH 2/2] mfd: Add leds MFD cell for intel_soc_pmic_chtwc
On Sun, 10 Feb 2019, Yauhen Kharuzhy wrote:
> Add MFD cell for LEDs driver to the Intel Cherry Trail Whiskey Cove PMIC
> mfd device driver.
>
> Signed-off-by: Yauhen Kharuzhy
> ---
> drivers/mfd/intel_soc_pmic_chtwc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mfd/intel_soc_pmic_chtwc.c
> b/drivers/mfd/intel_soc_pmic_chtwc.c
> index 64a3aece9c5e..68b54173edd8 100644
> --- a/drivers/mfd/intel_soc_pmic_chtwc.c
> +++ b/drivers/mfd/intel_soc_pmic_chtwc.c
> @@ -60,6 +60,8 @@ static struct mfd_cell cht_wc_dev[] = {
> .resources = cht_wc_ext_charger_resources,
> },
> { .name = "cht_wcove_region", },
> +
Nit: No need for the blank line, please remove it.
> + { .name = "cht_wcove_leds", },
> };
>
> /*
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 2/3] mmc: sdhci-omap: drop ->get_ro() implementation
On 12/02/19 1:41 PM, Adrian Hunter wrote: > On 11/02/19 3:23 PM, Thomas Petazzoni wrote: >> The SDHCI core is now properly checking for the state of a WP GPIO, >> so there is no longer any need for the sdhci-omap code to implement >> ->get_ro() using mmc_gpio_get_ro(). >> >> Signed-off-by: Thomas Petazzoni >> Reviewed-by: Thierry Reding > > Acked-by: Adrian Hunter Acked-by: Kishon Vijay Abraham I > >> --- >> Changes since v1: >> - Added Reviewed-by from Thierry Reding >> - Fix typo in commit log s/know/now/ noticed by Thierry Reding >> >> Note: this patch has only been compiled tested, as I don't have the >> hardware to test it. >> --- >> drivers/mmc/host/sdhci-omap.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c >> index d264391616f9..c2a28930086f 100644 >> --- a/drivers/mmc/host/sdhci-omap.c >> +++ b/drivers/mmc/host/sdhci-omap.c >> @@ -987,7 +987,6 @@ static int sdhci_omap_probe(struct platform_device *pdev) >> goto err_put_sync; >> } >> >> -host->mmc_host_ops.get_ro = mmc_gpio_get_ro; >> host->mmc_host_ops.start_signal_voltage_switch = >> sdhci_omap_start_signal_voltage_switch; >> host->mmc_host_ops.set_ios = sdhci_omap_set_ios; >> >
Re: [PATCH v9 1/3] /proc/pid/status: Add support for architecture specific output
On Tue, 12 Feb 2019, Thomas Gleixner wrote:
> On Tue, 12 Feb 2019, Aubrey Li wrote:
>
> > The architecture specific information of the running processes could
> > be useful to the userland. Add support to examine process architecture
> > specific information externally.
> >
> > Signed-off-by: Aubrey Li
> > Cc: Peter Zijlstra
> > Cc: Andi Kleen
> > Cc: Tim Chen
> > Cc: Dave Hansen
> > Cc: Arjan van de Ven
> > ---
> > fs/proc/array.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/fs/proc/array.c b/fs/proc/array.c
> > index 0ceb3b6b37e7..d8cb5b5fd7bb 100644
> > --- a/fs/proc/array.c
> > +++ b/fs/proc/array.c
> > @@ -392,6 +392,10 @@ static inline void task_core_dumping(struct seq_file
> > *m, struct mm_struct *mm)
> > seq_putc(m, '\n');
> > }
> >
> > +void __weak arch_proc_pid_status(struct seq_file *m, struct task_struct
> > *task)
> > +{
> > +}
>
> This still lacks a prototype.
Aside of that this doesn't apply to tip or Linus tree
Thanks,
tglx
Re: [PATCH 1/2] signal: Always notice exiting tasks
ebied...@xmission.com (Eric W. Biederman) writes:
> Oleg Nesterov writes:
>
>> sorry again for delay...
>>
>> On 02/07, Eric W. Biederman wrote:
>>>
>>> --- a/kernel/signal.c
>>> +++ b/kernel/signal.c
>>> @@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig)
>>> goto relock;
>>> }
>>>
>>> + /* Has this task already been marked for death? */
>>> + ksig->info.si_signo = signr = SIGKILL;
>>> + if (signal_group_exit(signal))
>>> + goto fatal;
>>> +
>>> for (;;) {
>>> struct k_sigaction *ka;
>>>
>>> @@ -2488,6 +2493,7 @@ bool get_signal(struct ksignal *ksig)
>>> continue;
>>> }
>>>
>>> + fatal:
>>> spin_unlock_irq(&sighand->siglock);
>>
>> Eric, but this is wrong. At least this is the serious user-visible
>> change.
>>
>> Afaics, with this patch the tracee will never stop in PTRACE_EVENT_EXIT in
>> case
>> of group_exit/exec, because schedule() in TASK_TRACED state won't block due
>> to
>> __fatal_signal_pending().
>>
>> Yes, yes, as I said many times the semantics of PTRACE_EVENT_EXIT was never
>> really
>> defined, it depends on /dev/random, but still I don't think we should break
>> it even
>> more.
>
> Well it changes PTRACE_EVENT_EXIT I grant that. It looks like that
> changes makes PTRACE_EVENT_EXIT is less than useful.
>
> The only way to perfectly preserve the previous semantics is probably to
> do something like my JOBCTL_TASK_EXIT proposal.
>
> That said I don't think even adding a JOBCTL_TASK_EXIT is enough to have
> a reliable stop of ptrace_event_exit after a process has exited. As any
> other pending signal can cause problems there as well.
>
> I have received a report that strace -f in some cases is not noticing
> children before they die and it looks like a stop in PTRACE_EVENT_EXIT
> would fix that strace behavior.
>
> Sigh.
>
> Here I was trying for the simple minimal change and I hit this landmine.
> Which leaves me with the question of what should be semantics of signal
> handling after exit.
>
> I think from dim memory of previous conversations the desired semantics
> look like:
> a) Ignore all signal state except for SIGKILL.
> b) Letting SIGKILL wake up the process should be sufficient.
>
> I will see if I can reproduce the strace failure and see if I can cook
> up something minimal that addresses just that. If you have suggestions
> I would love to hear them.
>
> As this was a minimal fix for SIGKILL being broken I have already sent
> the fix to Linus. So we are looking at an incremental fix at this
> point.
In my testing I found something that concerns me. Because we wind up
with SIGKILL in shard_pending we can not kill a process in do_exit that
has stopped at PTRACE_EVENT_EXIT. That bug seems to go back a long ways.
Other than that, it looks like we can do the following to fix the
regression I introduced.
Oleg any ideas on how to make PTRACE_EVENT_EXIT reliably killable?
diff --git a/kernel/signal.c b/kernel/signal.c
index 99fa8ff06fd9..a1f154dca73c 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2544,6 +2544,9 @@ bool get_signal(struct ksignal *ksig)
}
fatal:
+ /* No more signals can be pending past this point */
+ sigdelset(¤t->pending.signal, SIGKILL);
+ clear_tsk_thread_flag(current, TIF_SIGPENDING);
spin_unlock_irq(&sighand->siglock);
/*
Eric
Re: [PATCH 1/7] thermal: mediatek: fix register index error
On Mon, 2019-02-04 at 18:24 +0100, Matthias Brugger wrote:
>
> On 01/02/2019 08:38, michael@mediatek.com wrote:
> > From: Michael Kao
> >
> > The index of msr and adcpnp should match the sensor
> > which belongs to the selected bank in the for loop.
> >
>
> If I get that right, this fixes
> b7cf0053738c ("thermal: Add Mediatek thermal driver for mt2701.")
>
> So please add a fixes tag to the commit.
It is true that the patch is fix b7cf0053738c.
I will add
Fixes: b7cf0053738c ("thermal: Add Mediatek thermal driver for mt2701.")
to the commit message of next version.
> Thanks,
> Matthias
>
> > Signed-off-by: Michael Kao
> > ---
> > drivers/thermal/mtk_thermal.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> > index 0691f26..f646436 100644
> > --- a/drivers/thermal/mtk_thermal.c
> > +++ b/drivers/thermal/mtk_thermal.c
> > @@ -431,7 +431,8 @@ static int mtk_thermal_bank_temperature(struct
> > mtk_thermal_bank *bank)
> > u32 raw;
> >
> > for (i = 0; i < conf->bank_data[bank->id].num_sensors; i++) {
> > - raw = readl(mt->thermal_base + conf->msr[i]);
> > + raw = readl(mt->thermal_base +
> > + conf->msr[conf->bank_data[bank->id].sensors[i]]);
> >
> > temp = raw_to_mcelsius(mt,
> >conf->bank_data[bank->id].sensors[i],
> > @@ -568,7 +569,8 @@ static void mtk_thermal_init_bank(struct mtk_thermal
> > *mt, int num,
> >
> > for (i = 0; i < conf->bank_data[num].num_sensors; i++)
> > writel(conf->sensor_mux_values[conf->bank_data[num].sensors[i]],
> > - mt->thermal_base + conf->adcpnp[i]);
> > + mt->thermal_base +
> > + conf->adcpnp[conf->bank_data[num].sensors[i]]);
> >
> > writel((1 << conf->bank_data[num].num_sensors) - 1,
> >mt->thermal_base + TEMP_MONCTL0);
> >
Re: [PATCH v2 11/11] mfd: pm8xxx: revert "disassociate old virq if hwirq mapping already exists"
On Thu, 07 Feb 2019, Brian Masney wrote:
> Now that ssbi-gpio is a proper hierarchical IRQ chip, and all in-tree
> users of device tree have been updated, we can now drop the hack that
> was introduced to disassociate the old Linux virq if a hwirq mapping
> already exists. That patch was introduced to not break git bisect for
> any existing boards.
>
> This change was tested on an APQ8060 DragonBoard.
>
> Signed-off-by: Brian Masney
> Tested-by: Linus Walleij
> ---
> Changes since v1:
> - None
>
> drivers/mfd/qcom-pm8xxx.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 2f99a98ccee5..8eb2528793f9 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
> @@ -380,12 +380,6 @@ static void pm8xxx_irq_domain_map(struct pm_irq_chip
> *chip,
> struct irq_domain *domain, unsigned int irq,
> irq_hw_number_t hwirq, unsigned int type)
> {
> - unsigned int old_virq;
> -
> - old_virq = irq_find_mapping(domain, hwirq);
> - if (old_virq)
> - irq_domain_disassociate(domain, old_virq);
> -
For Linus:
Acked-by: Lee Jones
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 5/8] usb: ohci-da8xx: add vbus and overcurrent gpios
On 11/02/19 4:06 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > There are two users upstream which register external callbacks for > switching the port power on/off and overcurrent protection. Both > users only use two GPIOs for that. Instead of having that functionality > in the board files, move the logic into the OHCI driver - including > the interrupt handler for overcurrent detection. > > Signed-off-by: Bartosz Golaszewski > Acked-by: Alan Stern > --- > drivers/usb/host/ohci-da8xx.c | 99 ++- > 1 file changed, 50 insertions(+), 49 deletions(-) > > diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c > index e8ede0b5e3f0..80c23307fbfe 100644 > --- a/drivers/usb/host/ohci-da8xx.c > +++ b/drivers/usb/host/ohci-da8xx.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > #include > #include Added the new include in alphabetical order. With that minor fix, series is applied to my v5.1/soc branch. Thanks, Sekhar
Re: [PATCH] ARM: davinci: da850-evm: use GPIO hogs instead of the legacy API
On 05/02/19 6:11 PM, Linus Walleij wrote: > On Tue, Feb 5, 2019 at 10:49 AM Bartosz Golaszewski wrote: >> From: Bartosz Golaszewski >> >> In order to drop the hard-coded GPIO base values from the davinci GPIO >> driver's platform data, we first need to get rid of all calls to the >> legacy GPIO functions. Convert the mdio configuration to hogging the >> relevant GPIO line in the da850-evm board file. >> >> Signed-off-by: Bartosz Golaszewski > > Reviewed-by: Linus Walleij Applied to my v5.1/soc branch. Thanks, Sekhar
Re: [PATCH v9 2/3] x86,/proc/pid/status: Add AVX-512 usage elapsed time
On Tue, 12 Feb 2019, Aubrey Li wrote:
> diff --git a/arch/x86/include/asm/processor.h
> b/arch/x86/include/asm/processor.h
> index d53c54b842da..60ee932070fe 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -996,5 +996,7 @@ enum l1tf_mitigations {
> };
>
> extern enum l1tf_mitigations l1tf_mitigation;
> +/* Add support for architecture specific output in /proc/pid/status */
> +extern void arch_proc_pid_status(struct seq_file *m, struct task_struct
> *task);
Sigh. This is absolutely the wrong place. The weak function is declared and
used in fs/proc/... So the prototype wants to be in a header which is
included from there independent of x86...
Thanks,
tglx
Re: [PATCH v4 06/10] power: supply: max77650: add support for battery charger
Sebastian,
Just waiting on your Ack for the set.
Could you review this please?
> From: Bartosz Golaszewski
>
> Add basic support for the battery charger for max77650 PMIC.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/power/supply/Kconfig| 7 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/max77650-charger.c | 355
> 3 files changed, 363 insertions(+)
> create mode 100644 drivers/power/supply/max77650-charger.c
>
> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
> index e901b9879e7e..0230c96fa94d 100644
> --- a/drivers/power/supply/Kconfig
> +++ b/drivers/power/supply/Kconfig
> @@ -499,6 +499,13 @@ config CHARGER_DETECTOR_MAX14656
> Revision 1.2 and can be found e.g. in Kindle 4/5th generation
> readers and certain LG devices.
>
> +config CHARGER_MAX77650
> + tristate "Maxim MAX77650 battery charger driver"
> + depends on MFD_MAX77650
> + help
> + Say Y to enable support for the battery charger control of MAX77650
> + PMICs.
> +
> config CHARGER_MAX77693
> tristate "Maxim MAX77693 battery charger driver"
> depends on MFD_MAX77693
> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
> index b731c2a9b695..b73eb8c5c1a9 100644
> --- a/drivers/power/supply/Makefile
> +++ b/drivers/power/supply/Makefile
> @@ -70,6 +70,7 @@ obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o
> obj-$(CONFIG_CHARGER_LTC3651)+= ltc3651-charger.o
> obj-$(CONFIG_CHARGER_MAX14577) += max14577_charger.o
> obj-$(CONFIG_CHARGER_DETECTOR_MAX14656) += max14656_charger_detector.o
> +obj-$(CONFIG_CHARGER_MAX77650) += max77650-charger.o
> obj-$(CONFIG_CHARGER_MAX77693) += max77693_charger.o
> obj-$(CONFIG_CHARGER_MAX8997)+= max8997_charger.o
> obj-$(CONFIG_CHARGER_MAX8998)+= max8998_charger.o
> diff --git a/drivers/power/supply/max77650-charger.c
> b/drivers/power/supply/max77650-charger.c
> new file mode 100644
> index ..7055c9b5ee24
> --- /dev/null
> +++ b/drivers/power/supply/max77650-charger.c
> @@ -0,0 +1,355 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2018 BayLibre SAS
> +// Author: Bartosz Golaszewski
> +//
> +// Battery charger driver for MAXIM 77650/77651 charger/power-supply.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX77650_CHARGER_ENABLED BIT(0)
> +#define MAX77650_CHARGER_DISABLED0x00
> +#define MAX77650_CHARGER_CHG_EN_MASK BIT(0)
> +
> +#define MAX77650_CHARGER_CHG_DTLS_MASK GENMASK(7, 4)
> +#define MAX77650_CHARGER_CHG_DTLS_BITS(_reg) \
> + (((_reg) & MAX77650_CHARGER_CHG_DTLS_MASK) >> 4)
> +
> +#define MAX77650_CHARGER_CHG_OFF 0x00
> +#define MAX77650_CHARGER_CHG_PREQ0x01
> +#define MAX77650_CHARGER_CHG_ON_CURR 0x02
> +#define MAX77650_CHARGER_CHG_ON_JCURR0x03
> +#define MAX77650_CHARGER_CHG_ON_VOLT 0x04
> +#define MAX77650_CHARGER_CHG_ON_JVOLT0x05
> +#define MAX77650_CHARGER_CHG_ON_TOPOFF 0x06
> +#define MAX77650_CHARGER_CHG_ON_JTOPOFF 0x07
> +#define MAX77650_CHARGER_CHG_DONE0x08
> +#define MAX77650_CHARGER_CHG_JDONE 0x09
> +#define MAX77650_CHARGER_CHG_SUSP_PF 0x0a
> +#define MAX77650_CHARGER_CHG_SUSP_FCF0x0b
> +#define MAX77650_CHARGER_CHG_SUSP_BTF0x0c
> +
> +#define MAX77650_CHARGER_CHGIN_DTLS_MASK GENMASK(3, 2)
> +#define MAX77650_CHARGER_CHGIN_DTLS_BITS(_reg) \
> + (((_reg) & MAX77650_CHARGER_CHGIN_DTLS_MASK) >> 2)
> +
> +#define MAX77650_CHARGER_CHGIN_UVL 0x00
> +#define MAX77650_CHARGER_CHGIN_OVL 0x01
> +#define MAX77650_CHARGER_CHGIN_OKAY 0x11
> +
> +#define MAX77650_CHARGER_CHG_MASKBIT(1)
> +#define MAX77650_CHARGER_CHG_CHARGING(_reg) \
> + (((_reg) & MAX77650_CHARGER_CHG_MASK) > 1)
> +
> +#define MAX77650_CHARGER_VCHGIN_MIN_MASK 0xc0
> +#define MAX77650_CHARGER_VCHGIN_MIN_SHIFT(_val) ((_val) << 5)
> +
> +#define MAX77650_CHARGER_ICHGIN_LIM_MASK 0x1c
> +#define MAX77650_CHARGER_ICHGIN_LIM_SHIFT(_val) ((_val) << 2)
> +
> +struct max77650_charger_data {
> + struct regmap *map;
> + struct device *dev;
> +};
> +
> +static enum power_supply_property max77650_charger_properties[] = {
> + POWER_SUPPLY_PROP_STATUS,
> + POWER_SUPPLY_PROP_ONLINE,
> + POWER_SUPPLY_PROP_CHARGE_TYPE
> +};
> +
> +static const unsigned int max77650_charger_vchgin_min_table[] = {
> + 400, 410, 420, 430, 440, 450, 460, 470
> +};
> +
> +static const unsigned int max77650_charger_ichgin_lim_table[] = {
> + 95000, 19, 285000, 38, 475000
> +};
> +
> +static int max77650_charger_set_vchgin_min(struct max77650_charger_data *chg,
> +
Re: [PATCH 1/3] dt-bindings: dmaengine: Add one new cell to present hardware slave id
Hi Arnd,
On Fri, 1 Feb 2019 at 19:53, Baolin Wang wrote:
>
> Hi Arnd,
> On Thu, 31 Jan 2019 at 00:52, Arnd Bergmann wrote:
> >
> > On Tue, Jan 22, 2019 at 2:21 PM Baolin Wang wrote:
> > >
> > > The DMA engine clients can trigger DMA engine automatically by setting
> > > the corresponding hardware slave id for the DMA engine. Thus add one
> > > cell to present the hardware slave id for DMA clients.
> > >
> > > Signed-off-by: Baolin Wang
> > > ---
> > > Documentation/devicetree/bindings/dma/sprd-dma.txt | 12 +++-
> > > 1 file changed, 7 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/dma/sprd-dma.txt
> > > b/Documentation/devicetree/bindings/dma/sprd-dma.txt
> > > index 7a10fea..7812cf0 100644
> > > --- a/Documentation/devicetree/bindings/dma/sprd-dma.txt
> > > +++ b/Documentation/devicetree/bindings/dma/sprd-dma.txt
> > > @@ -6,8 +6,8 @@ Required properties:
> > > - compatible: Should be "sprd,sc9860-dma".
> > > - reg: Should contain DMA registers location and length.
> > > - interrupts: Should contain one interrupt shared by all channel.
> > > -- #dma-cells: must be <1>. Used to represent the number of integer
> > > - cells in the dmas property of client device.
> > > +- #dma-cells: must be <2>. Used to represent the channel id and slave id
> > > + of integer cells in the dmas property of client device.
> > > - #dma-channels : Number of DMA channels supported. Should be 32.
> > > - clock-names: Should contain the clock of the DMA controller.
> > > - clocks: Should contain a clock specifier for each entry in clock-names.
> > > @@ -28,14 +28,16 @@ apdma: dma-controller@2010 {
> > >
> > > Client:
> > > DMA clients connected to the Spreadtrum DMA controller must use the
> > > format
> > > -described in the dma.txt file, using a two-cell specifier for each
> > > channel.
> > > -The two cells in order are:
> > > +described in the dma.txt file, using a three-cell specifier for each
> > > channel.
> > > +The three cells in order are:
> > > 1. A phandle pointing to the DMA controller.
> > > 2. The channel id.
> > > +3. The hardware slave id which is used for clients to trigger DMA engine
> > > +automatically.
> >
> > I notice that this is an incompatible binding change. Is that necessary?
> > If the current code works, I'd suggest allowing both #dma-cells=<2>
> > and <3>, and then implementing both in the driver.
>
> Yes, this is necessary.
>
> Yes, current code can work, but the problem is that the DMA clients
> must add one property (something like "sprd,slave-id") to specify the
> slave id. So considering this, we want to change the dma-cells to 2,
> including dma channel and dma slave id, which can avoid introducing
> some similar properties for DMA clients.
>
> Now there are no DMA clients in mainline for Spreadtrum platform, and
> we want to upstream our first DMA clients: SPI controller. So no other
> drivers need to change when we changing dma cells. Thanks.
Do you have any other concerns about this patch set? If not, I think
Vinod can apply this patch set. Thanks.
--
Baolin Wang
Best Regards
Re: [RESEND PATCH v2 00/33] ARM: davinci: modernize the irq support
On 11/02/19 5:55 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > NOTE: resending due to missing irqchip maintainers in Cc > > This series ports the davinci platform to using SPARSE_IRQ, cleans up > the irqchip drivers and moves them over to drivers/irqchip. > > The series can be logically split into four parts. The first (1-8) aims > at introducing support for SPARSE_IRQ. It contains a couple changes > required for that functionality and the final patch actually selecting > it. > > Second part (9-19) makes the aintc driver suitable for drivers/irqchip > and eventually moves it over there. > > Part 3 (20-32) does the same for the cp-intc driver. > > Last patch removes unnecessary code. > > The series has been tested on da850-lcdk (for cp-intc) and > dm365-evm (for aintc). There is build breakage in drivers/input/keyboard/davinci_keyscan.c after this series due to removal. Thanks, Sekhar
Re: RFC: drop ISA support in the synlink tty driver?
On Tue, Feb 12, 2019 at 09:08:41AM +0100, Jiri Slaby wrote: > On 12. 02. 19, 8:51, Greg Kroah-Hartman wrote: > > On Mon, Feb 11, 2019 at 02:25:33PM +0100, Christoph Hellwig wrote: > >> Hi Greg and Jiri, > >> > >> I've been working hard to get rid of the remaining callers the pass a > >> NULL struct device to the DMA mapping functions and am almost done. > >> > >> The only non-trivial driver is the synclink driver, which has legacy > >> early 90s style ISA support that doesn't use the device model at all. > >> > >> In theory we could convert it to an isa_driver, but without testing > >> that seems rather dangerous. So for now I would suggest that we > >> remove the ISA support in this driver - if anyone cares enough we > >> can resurrect it from the git history and convert it to use the driver > >> model. > > > > No objection from me at all, I'll go queue this up now, thanks. > > Agreed, but I would kill also the MGSL_BUS_TYPE_ISA macro proper. It's just a #define, in a uapi file, so we should probably leave it as userspace programs _might_ depend on it. I have no idea why, but oh well... thanks, greg k-h
Re: [PATCH 5/5] riscv: use for_each_of_cpu_node iterator
On Mon, Feb 11, 2019 at 11:13:39PM -0800, Christoph Hellwig wrote: > On Fri, Jan 18, 2019 at 03:03:08PM +0100, Johan Hovold wrote: > > Use the new for_each_of_cpu_node() helper to iterate over cpu nodes > > instead of open coding. Note that this will allow matching also on the > > node name instead of the (for FDT) deprecated device_type property. > > > > Signed-off-by: Johan Hovold > > I think this is going to conflict with the ELF caps changes from > Atish. Maybe the riscv_fill_hwcap hunk should be included in his > patch? Since that patch had some issues (e.g. the node reference underflow) it may be better to rebase it on top of this series. The changes are otherwise distinct after all. > Otherwise looks good: > > Reviewed-by: Christoph Hellwig Thanks for reviewing! Johan
Re: [PATCH 1/2] PM-runtime: Take suppliers into account in __pm_runtime_set_status()
On Mon, 11 Feb 2019 at 23:41, Rafael J. Wysocki wrote:
>
> On Mon, Feb 11, 2019 at 2:28 PM Ulf Hansson wrote:
> >
> > On Thu, 7 Feb 2019 at 19:46, Rafael J. Wysocki wrote:
> > >
> > > From: Rafael J. Wysocki
> > >
> > > If the target device has any suppliers, as reflected by device links
> > > to them, __pm_runtime_set_status() does not take them into account,
> > > which is not consistent with the other parts of the PM-runtime
> > > framework and may lead to programming mistakes.
> > >
> > > Modify __pm_runtime_set_status() to take suppliers into account by
> > > activating them upfront if the new status is RPM_ACTIVE and
> > > deactivating them on exit if the new status is RPM_SUSPENDED.
> > >
> > > If the activation of one of the suppliers fails, the new status
> > > will be RPM_SUSPENDED and the (remaining) suppliers will be
> > > deactivated on exit (the child count of the device's parent
> > > will be dropped too then).
> > >
> > > Of course, adding device links locking to __pm_runtime_set_status()
> > > means that it cannot be run fron interrupt context, so make it use
> > > spin_lock_irq() and spin_unlock_irq() instead of spin_lock_irqsave()
> > > and spin_unlock_irqrestore(), respectively.
> > >
> > > Signed-off-by: Rafael J. Wysocki
> >
> > Rafael, thanks for working on this!
> >
> > I am running some tests at my side, but still not achieving the
> > behavior I expect to. Will let you know when I have more details, but
> > first some comments below.
> >
> > > ---
> > > drivers/base/power/runtime.c | 45
> > > ++-
> > > 1 file changed, 40 insertions(+), 5 deletions(-)
> > >
> > > Index: linux-pm/drivers/base/power/runtime.c
> > > ===
> > > --- linux-pm.orig/drivers/base/power/runtime.c
> > > +++ linux-pm/drivers/base/power/runtime.c
> > > @@ -1102,20 +1102,43 @@ EXPORT_SYMBOL_GPL(pm_runtime_get_if_in_u
> > > * and the device parent's counter of unsuspended children is modified to
> > > * reflect the new status. If the new status is RPM_SUSPENDED, an idle
> > > * notification request for the parent is submitted.
> > > + *
> > > + * If @dev has any suppliers (as reflected by device links to them), and
> > > @status
> > > + * is RPM_ACTIVE, they will be activated upfront and if the activation
> > > of one
> > > + * of them fails, the status of @dev will be changed to RPM_SUSPENDED
> > > (instead
> > > + * of the @status value) and the suppliers will be deacticated on exit.
> > > The
> > > + * error returned by the failing supplier activation will be returned in
> > > that
> > > + * case.
> > > */
> > > int __pm_runtime_set_status(struct device *dev, unsigned int status)
> > > {
> > > struct device *parent = dev->parent;
> > > - unsigned long flags;
> > > bool notify_parent = false;
> > > int error = 0;
> > >
> > > if (status != RPM_ACTIVE && status != RPM_SUSPENDED)
> > > return -EINVAL;
> > >
> > > - spin_lock_irqsave(&dev->power.lock, flags);
> > > + /*
> > > +* If the new status is RPM_ACTIVE, the suppliers can be activated
> > > +* upfront regardless of the current status, because next time
> > > +* rpm_put_suppliers() runs, the rpm_active refcounts of the links
> > > +* involved will be dropped down to one anyway.
> > > +*/
> > > + if (status == RPM_ACTIVE) {
> > > + int idx = device_links_read_lock();
> > > +
> > > + error = rpm_get_suppliers(dev);
> > > + if (error)
> > > + status = RPM_SUSPENDED;
> > > +
> > > + device_links_read_unlock(idx);
> > > + }
> >
> > This doesn't look right to me, and more importantly, this isn't
> > consistent with how we treat a parent/child.
>
> It cannot be entirely consistent with that, because you cannot walk
> the suppliers under the device's power.lock.
>
> The idea here is that activating suppliers upfront if the new status
> is RPM_ACTIVE shouldn't hurt regardless.
I see. However, perhaps we can just read out the needed flags/states
(within device's power.lock) before walking the suppliers.
In principle, those flags/states shouldn't really change, in case
runtime PM have been properly disabled by the caller.
>
> > More precisely, I think you need to check "if
> > (!dev->power.runtime_error && !dev->power.disable_depth)" and also
> > whether "dev->power.runtime_status == status", before deciding to call
> > rpm_get_suppliers() above. Otherwise you may end up resuming suppliers
> > and/or increasing the link->rpm_active count, when you shouldn't.
>
> Resuming suppliers unnecessarily is not particularly efficient, but it
> is not incorrect. Incrementing their rpm_active temporarily also
> isn't incorrect as long as the rpm_active values are correct on exit
> (and note that incementing them if the consumer's status is RPM_ACTIVE
> does
Re: [RESEND PATCH v2 02/33] ARM: davinci: aintc: use irq domain
On 11/02/19 5:55 PM, Bartosz Golaszewski wrote:
> @@ -74,6 +75,7 @@ void __init davinci_irq_init(void)
> {
> unsigned i, j;
> const u8 *davinci_def_priorities = davinci_soc_info.intc_irq_prios;
> + int rv, irq_base;
>
> davinci_intc_type = DAVINCI_INTC_TYPE_AINTC;
> davinci_intc_base = ioremap(davinci_soc_info.intc_base, SZ_4K);
> @@ -110,8 +112,25 @@ void __init davinci_irq_init(void)
> davinci_irq_writel(pri, i);
> }
>
> + irq_base = irq_alloc_descs(-1, 0, davinci_soc_info.intc_irq_num, 0);
> + if (WARN_ON(irq_base < 0))
> + return;
> +
> + davinci_irq_domain = irq_domain_add_legacy(NULL,
> + davinci_soc_info.intc_irq_num,
> + irq_base, 0, &irq_domain_simple_ops,
> + NULL);
> + if (WARN_ON(!davinci_irq_domain))
> + return;
> +
> + rv = irq_alloc_domain_generic_chips(davinci_irq_domain, 32, 1,
> + "AINTC", handle_edge_irq,
> + IRQ_NOREQUEST | IRQ_NOPROBE, 0, 0);
> + if (WARN_ON(rv))
> + return;
Like you have done in other places, use "ret" instead of "rv" for
consistency.
Thanks,
Sekhar
Re: [PATCH v2 1/9] irq/irq_sim: don't share the irq_chip structure between simulators
pon., 11 lut 2019 o 23:28 Marc Zyngier napisał(a):
>
> On Tue, 29 Jan 2019 09:44:03 +0100
> Bartosz Golaszewski wrote:
>
> > From: Bartosz Golaszewski
> >
> > We want to support multiple instances of irq_sim. Make struct irq_chip
> > part of the irq_sim structure.
>
> Why? There is nothing dynamic in an irqchip structure. It is all code
> that is set in stone for the lifetime of the irqchip.
>
> I've sure you have a use for such indirection, so why don't you explain
> what you have in mind?
>
No you're right, this can be dropped.
Bart
> Thanks,
>
> M.
>
> >
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > include/linux/irq_sim.h | 2 ++
> > kernel/irq/irq_sim.c| 12 +---
> > 2 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/irq_sim.h b/include/linux/irq_sim.h
> > index 4500d453a63e..eda132c22b57 100644
> > --- a/include/linux/irq_sim.h
> > +++ b/include/linux/irq_sim.h
> > @@ -6,6 +6,7 @@
> > #ifndef _LINUX_IRQ_SIM_H
> > #define _LINUX_IRQ_SIM_H
> >
> > +#include
> > #include
> > #include
> >
> > @@ -25,6 +26,7 @@ struct irq_sim_irq_ctx {
> > };
> >
> > struct irq_sim {
> > + struct irq_chip chip;
> > struct irq_sim_work_ctx work_ctx;
> > int irq_base;
> > unsigned intirq_count;
> > diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c
> > index 98a20e1594ce..b732e4e2e45b 100644
> > --- a/kernel/irq/irq_sim.c
> > +++ b/kernel/irq/irq_sim.c
> > @@ -25,12 +25,6 @@ static void irq_sim_irqunmask(struct irq_data *data)
> > irq_ctx->enabled = true;
> > }
> >
> > -static struct irq_chip irq_sim_irqchip = {
> > - .name = "irq_sim",
> > - .irq_mask = irq_sim_irqmask,
> > - .irq_unmask = irq_sim_irqunmask,
> > -};
> > -
> > static void irq_sim_handle_irq(struct irq_work *work)
> > {
> > struct irq_sim_work_ctx *work_ctx;
> > @@ -74,6 +68,10 @@ int irq_sim_init(struct irq_sim *sim, unsigned int
> > num_irqs)
> > return sim->irq_base;
> > }
> >
> > + sim->chip.name = "irq_sim";
> > + sim->chip.irq_mask = irq_sim_irqmask;
> > + sim->chip.irq_unmask = irq_sim_irqunmask;
> > +
> > sim->work_ctx.pending = bitmap_zalloc(num_irqs, GFP_KERNEL);
> > if (!sim->work_ctx.pending) {
> > kfree(sim->irqs);
> > @@ -84,7 +82,7 @@ int irq_sim_init(struct irq_sim *sim, unsigned int
> > num_irqs)
> > for (i = 0; i < num_irqs; i++) {
> > sim->irqs[i].irqnum = sim->irq_base + i;
> > sim->irqs[i].enabled = false;
> > - irq_set_chip(sim->irq_base + i, &irq_sim_irqchip);
> > + irq_set_chip(sim->irq_base + i, &sim->chip);
> > irq_set_chip_data(sim->irq_base + i, &sim->irqs[i]);
> > irq_set_handler(sim->irq_base + i, &handle_simple_irq);
> > irq_modify_status(sim->irq_base + i,
>
>
>
> --
> Without deviation from the norm, progress is not possible.
Re: [PATCH v2 0/4] Add max77620 charging & low battery support
On 2/12/2019 4:04 PM, Lee Jones wrote: > On Tue, 12 Feb 2019, Mark Zhang wrote: > >> On 2/7/2019 4:48 PM, Lee Jones wrote: >>> On Tue, 29 Jan 2019, Mark Zhang wrote: >>> This patch set adds support for max77620 backup battery charging and low battery monitoring. Changes in v2: - Add devicetree binding documentation Mark Zhang (4): mfd: max77620: Add backup battery charger support mfd: max77620: add documentation for backup battery charging mfd: max77620: Add low battery monitor support mfd: max77620: add documentation for low battery monitoring .../devicetree/bindings/mfd/max77620.txt | 34 + drivers/mfd/max77620.c| 137 +- >>> >>> All of this needs moving out to the correct subsystem. >>> >>> drivers/power/supply/max77620-battery.c looks right. >> >> Actually max77620 is not a power supply device. This patch set adds 2 >> features: >> - Backup battery charger. The RTC in max77620 is supplied from a backup >> battery and consumes 2.0uA when no other power sources are available. So >> basically this is not a system battery charger, it's just for RTC. >> - Low battery monitoring. This is for monitoring the system main battery >> voltage, so max77620 can shutdown or reset the SoC accordingly. But I >> think this doesn't conform the idea of "power supply" driver as well. > > Most other battery handling seems to happen in > drivers/power/supply/*.battery*. If that's not the right location, > then you need to find a place for it to go. MFDs do not provide > useful functionality per say - that is the role of the child devices. > Understood. Looking at "enum power_supply_property", battery handling drivers are able to get battery capacity/current voltage/temperature/status/... and etc, which is making sense. But my patch set doesn't do this kind of things at all so I think the power supply framework doesn't fit here. Let me check other similar device drivers... hope to get inspired. Thanks Lee. Mark
Re: [PATCH] PCI: pciehp: Do not turn off slot if presence comes up after link
On Mon, Feb 11, 2019 at 11:48:12PM +, alex_gagn...@dellteam.com wrote: > On 2/9/19 5:58 AM, Lukas Wunner wrote: > ECN [1] was approved last November, so it's normative spec text. Sorry > if the Ukranians didn't get ahold of it yet. I'll try to explain the delta. > There's an in-band PD supported/disable set of bits. If 'supported' is > set, then you can set 'disable', which removes the 'logical OR" and now > PD is only out-of-band presence. I see, thanks a lot for relaying this information. The PCI SIG should probably consider granting access to specs to open source developers to ease adoption of new features in Linux et al. > > Table 4-14 in sec 4.2.6 is also important because it shows the difference > > between Link Up and in-band presence. > > So, we'd expect PD to come up at the same time or before DLL? Per table 4-14 and figure 4-23 (immediately below the table) in r4.0, PDC ought to be signaled before DLLSC. As said, Linux can handle PDC after DLLSC if they're not too far apart (100 ms, see pcie_wait_for_link()). > I'd like a generic solution. I suspect supporting 'in-band PD disabled' > and quirking for that would be a saner way to do things. If we support > it, then we need to handle PDSC after DLLSC scenarios anyway. I agree, having support for this new ECN would be great. If you look at struct controller in drivers/pci/hotplug/pciehp.h, there's a section labelled /* capabilities and quirks */. An idea would be to add an unsigned int there to indicate whether in-band presence is disabled. An alternative would be to add a flag to struct pci_dev. Instead of modifying the logic in pciehp_handle_presence_or_link_change(), you could amend pcie_wait_for_link() to poll PDS until it's set, in addition to DLLLA. The rationale would be that although the link is up, the hot-added device cannot really be considered accessible until PDS is also set. Unfortunately we cannot do this for all devices because (as I've said before), some broken devices hardwire PDS to zero. But it should be safe to constrain it to those which can disable in-band presence. Be mindful however that pcie_wait_for_link() is also called from the DPC driver. Keith should be able to judge whether a change to that function breaks DPC. You'll probably also need to add code to disable in-band presence if that is supported, either in pcie_init() in pciehp_hpc.c or in generic PCI code. Thanks, Lukas
[GIT PULL V2] csky fixes for v5.0-rc6
The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9:
Linux 5.0-rc6 (2019-02-10 14:42:20 -0800)
are available in the git repository at:
g...@github.com:c-sky/csky-linux.git tags/csky-for-linus-5.0-rc6
for you to fetch changes up to 749e649084d0acb8c5d28c0ec502d9cc023bff86:
csky: Fixup dead loop in show_stack (2019-02-12 10:25:37 +0800)
arch/csky patches for 5.0-rc6
Here is some fixup patches for 5.0-rc6:
Guo Ren (10):
csky: Fixup _PAGE_GLOBAL bit for 610 tlb entry
irqchip/csky: Optimize remove unnecessary loop irq handle
irqchip/irq-csky-mpintc: Add triger type and priority
dt-bindings: interrupt-controller: Update csky mpintc
csky: Fixup wrong pt_regs size
csky: coding convention: Use task_stack_page
dt-bindings: csky,apb-intc: Add vector irq mode
irqchip/csky: Add support-vector-irq for apb-intc
csky: Fixup io-range page attribute for mmap("/dev/mem")
csky: Fixup dead loop in show_stack
Signed-off-by: Guo Ren
Guo Ren (10):
csky: Fixup _PAGE_GLOBAL bit for 610 tlb entry
irqchip/csky: Optimize remove unnecessary loop irq handle
irqchip/irq-csky-mpintc: Add triger type and priority
dt-bindings: interrupt-controller: Update csky mpintc
csky: Fixup wrong pt_regs size
csky: coding convention: Use task_stack_page
dt-bindings: csky,apb-intc: Add vector irq mode
irqchip/csky: Add support-vector-irq for apb-intc
csky: Fixup io-range page attribute for mmap("/dev/mem")
csky: Fixup dead loop in show_stack
.../interrupt-controller/csky,apb-intc.txt | 3 +
.../bindings/interrupt-controller/csky,mpintc.txt | 21 +++-
arch/csky/include/asm/pgtable.h| 9 +-
arch/csky/include/asm/processor.h | 4 +-
arch/csky/kernel/dumpstack.c | 4 +
arch/csky/kernel/ptrace.c | 3 +-
arch/csky/kernel/smp.c | 3 +-
arch/csky/mm/ioremap.c | 14 +++
drivers/irqchip/irq-csky-apb-intc.c| 59 +++
drivers/irqchip/irq-csky-mpintc.c | 113 +++--
10 files changed, 196 insertions(+), 37 deletions(-)
Re: [PATCH v2 2/9] irq/irq_sim: use irq domain
pon., 11 lut 2019 o 23:26 Marc Zyngier napisał(a):
>
> On Tue, 29 Jan 2019 09:44:04 +0100
> Bartosz Golaszewski wrote:
>
> > From: Bartosz Golaszewski
> >
> > Delegate the offset to virq number mapping to the provided framework
> > instead of handling it locally. Use the legacy domain as we want to
> > preallocate the irq descriptors.
>
> Why?
>
> >
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > include/linux/irq_sim.h | 6 +--
> > kernel/irq/irq_sim.c| 94 +
> > 2 files changed, 71 insertions(+), 29 deletions(-)
> >
> > diff --git a/include/linux/irq_sim.h b/include/linux/irq_sim.h
> > index eda132c22b57..b96c2f752320 100644
> > --- a/include/linux/irq_sim.h
> > +++ b/include/linux/irq_sim.h
> > @@ -8,6 +8,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> >
> > /*
> > @@ -21,16 +22,15 @@ struct irq_sim_work_ctx {
> > };
> >
> > struct irq_sim_irq_ctx {
> > - int irqnum;
> > boolenabled;
> > };
> >
> > struct irq_sim {
> > struct irq_chip chip;
> > + struct irq_domain *domain;
> > struct irq_sim_work_ctx work_ctx;
> > - int irq_base;
> > + int virq_base;
> > unsigned intirq_count;
> > - struct irq_sim_irq_ctx *irqs;
> > };
> >
> > int irq_sim_init(struct irq_sim *sim, unsigned int num_irqs);
> > diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c
> > index b732e4e2e45b..2bcdbab1bc5a 100644
> > --- a/kernel/irq/irq_sim.c
> > +++ b/kernel/irq/irq_sim.c
> > @@ -44,6 +44,43 @@ static void irq_sim_handle_irq(struct irq_work *work)
> > }
> > }
> >
> > +static int irq_sim_domain_map(struct irq_domain *domain,
> > + unsigned int virq, irq_hw_number_t hw)
> > +{
> > + struct irq_sim *sim = domain->host_data;
> > + struct irq_sim_irq_ctx *ctx;
> > +
> > + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> > + if (!ctx)
> > + return -ENOMEM;
> > +
> > + irq_set_chip(virq, &sim->chip);
> > + irq_set_chip_data(virq, ctx);
> > + irq_set_handler(virq, handle_simple_irq);
>
> Consider using modern APIs such as irq_domain_set_info().
>
> > + irq_modify_status(virq, IRQ_NOREQUEST | IRQ_NOAUTOEN, IRQ_NOPROBE);
>
> Where is this requirement coming from?
>
> > +
> > + return 0;
> > +}
> > +
> > +static void irq_sim_domain_free(struct irq_domain *domain,
> > + unsigned int virq, unsigned int num_irqs)
> > +{
> > + struct irq_sim_irq_ctx *ctx;
> > + struct irq_data *irq;
> > + int i;
> > +
> > + for (i = 0; i < num_irqs; i++) {
> > + irq = irq_domain_get_irq_data(domain, virq + i);
> > + ctx = irq_data_get_irq_chip_data(irq);
> > + kfree(ctx);
> > + }
> > +}
> > +
> > +static const struct irq_domain_ops irq_sim_domain_ops = {
> > + .map = irq_sim_domain_map,
> > + .free = irq_sim_domain_free,
>
> The intended use of the v2 API is to have alloc and free as a pair, and
> no map. So please choose which version of the API you're using here.
> The safest bet would be to move what you do on map into alloc.
>
> > +};
> > +
> > /**
> > * irq_sim_init - Initialize the interrupt simulator: allocate a range of
> > *dummy interrupts.
> > @@ -56,16 +93,15 @@ static void irq_sim_handle_irq(struct irq_work *work)
> > */
> > int irq_sim_init(struct irq_sim *sim, unsigned int num_irqs)
> > {
> > - int i;
> > -
> > - sim->irqs = kmalloc_array(num_irqs, sizeof(*sim->irqs), GFP_KERNEL);
> > - if (!sim->irqs)
> > + sim->virq_base = irq_alloc_descs(-1, 0, num_irqs, 0);
> > + if (sim->virq_base < 0)
> > + return sim->virq_base;
> > +
> > + sim->domain = irq_domain_add_legacy(NULL, num_irqs, sim->virq_base,
> > + 0, &irq_sim_domain_ops, sim);
>
> Why do you need a legacy domain? As far as I can tell, this is new
> code, hence it has no legacy.
>
> > + if (!sim->domain) {
> > + irq_free_descs(sim->virq_base, num_irqs);
> > return -ENOMEM;
> > -
> > - sim->irq_base = irq_alloc_descs(-1, 0, num_irqs, 0);
> > - if (sim->irq_base < 0) {
> > - kfree(sim->irqs);
> > - return sim->irq_base;
> > }
> >
> > sim->chip.name = "irq_sim";
> > @@ -74,25 +110,15 @@ int irq_sim_init(struct irq_sim *sim, unsigned int
> > num_irqs)
> >
> > sim->work_ctx.pending = bitmap_zalloc(num_irqs, GFP_KERNEL);
> > if (!sim->work_ctx.pending) {
> > - kfree(sim->irqs);
> > - irq_free_descs(sim->irq_base, num_irqs);
> > + irq_domain_remove(sim->domain);
> > + irq_free_descs(sim->virq_base, num_irqs);
> > return -ENOMEM;
> > }
> >
> > - for (i = 0; i < num_irqs; i++) {
> > - sim->irqs[i].irqnum = sim->irq_base + i;
> > -
Re: [PATCH v2 3/3] pwm: core: add consumer device link
On 2/11/19 8:06 PM, Uwe Kleine-König wrote:
> Hello Fabrice,
>
> On Mon, Feb 11, 2019 at 05:12:02PM +0100, Fabrice Gasnier wrote:
>> Add a device link between the PWM consumer and the PWM provider. This
>> enforces the PWM user to get suspended before the PWM provider. It
>> allows proper synchronization of suspend/resume sequences: the PWM user
>> is responsible for properly stopping PWM, before the provider gets
>> suspended: see [1]. Add the device link in:
>> - pwm_get()
>> - devm_pwm_get()
>> - devm_of_pwm_get()
>> as it requires a reference to the device for the PWM consumer.
>>
>> [1] https://lkml.org/lkml/2019/2/5/770
>>
>> Suggested-by: Thierry Reding
>> Signed-off-by: Fabrice Gasnier
>> ---
>> drivers/pwm/core.c | 13 +++--
>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
>> index 1581f6a..2835e27 100644
>> --- a/drivers/pwm/core.c
>> +++ b/drivers/pwm/core.c
>> @@ -770,8 +770,13 @@ struct pwm_device *pwm_get(struct device *dev, const
>> char *con_id)
>> int err;
>>
>> /* look up via DT first */
>> -if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
>> -return of_pwm_get(dev->of_node, con_id);
>> +if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node) {
>> +pwm = of_pwm_get(dev->of_node, con_id);
>> +if (!IS_ERR(pwm))
>> +device_link_add(dev, pwm->chip->dev,
>> +DL_FLAG_AUTOREMOVE_CONSUMER);
>> +return pwm;
>> +}
>>
>> /*
>> * We look up the provider in the static table typically provided by
>> @@ -851,6 +856,8 @@ struct pwm_device *pwm_get(struct device *dev, const
>> char *con_id)
>> pwm->args.period = chosen->period;
>> pwm->args.polarity = chosen->polarity;
>>
>> +device_link_add(dev, pwm->chip->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
>> +
>> return pwm;
>> }
>> EXPORT_SYMBOL_GPL(pwm_get);
>> @@ -943,6 +950,8 @@ struct pwm_device *devm_of_pwm_get(struct device *dev,
>> struct device_node *np,
>> if (!IS_ERR(pwm)) {
>> *ptr = pwm;
>> devres_add(dev, ptr);
>> +device_link_add(dev, pwm->chip->dev,
>> +DL_FLAG_AUTOREMOVE_CONSUMER);
>
> IMHO it's surprising that devm_of_pwm_get() does more than of_pwm_get()
> + devres stuff. I'd put device_link_add() into of_pwm_get().
Hi Uwe,
I also agree with this. But I think this implies modifying the API for
of_pwm_get():
/**
* of_pwm_get() - request a PWM via the PWM framework
+ * @dev: device for PWM consumer
* @np: device node to get the PWM from
* @con_id: consumer name
It seems there aren't much of_pwm_get() users currently.
Does this look sensible ?
Best regards,
Fabrice
>
> Best regards
> Uwe
>
Re: [RESEND PATCH v2 00/33] ARM: davinci: modernize the irq support
wt., 12 lut 2019 o 09:24 Sekhar Nori napisał(a): > > On 11/02/19 5:55 PM, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > NOTE: resending due to missing irqchip maintainers in Cc > > > > This series ports the davinci platform to using SPARSE_IRQ, cleans up > > the irqchip drivers and moves them over to drivers/irqchip. > > > > The series can be logically split into four parts. The first (1-8) aims > > at introducing support for SPARSE_IRQ. It contains a couple changes > > required for that functionality and the final patch actually selecting > > it. > > > > Second part (9-19) makes the aintc driver suitable for drivers/irqchip > > and eventually moves it over there. > > > > Part 3 (20-32) does the same for the cp-intc driver. > > > > Last patch removes unnecessary code. > > > > The series has been tested on da850-lcdk (for cp-intc) and > > dm365-evm (for aintc). > > There is build breakage in drivers/input/keyboard/davinci_keyscan.c > after this series due to removal. > > Thanks, > Sekhar Thanks, I'll fix that. Bart
Re: [PATCH v2] mm/memory-hotplug: Add sysfs hot-remove trigger
On Mon 11-02-19 17:50:46, Robin Murphy wrote:
> ARCH_MEMORY_PROBE is a useful thing for testing and debugging hotplug,
> but being able to exercise the (arguably trickier) hot-remove path would
> be even more useful. Extend the feature to allow removal of offline
> sections to be triggered manually to aid development.
>
> Since process dictates the new sysfs entry be documented, let's also
> document the existing probe entry to match - better 13-and-a-half years
> late than never, as they say...
The probe sysfs is quite dubious already TBH. Apart from testing, is
anybody using it for something real? Do we need to keep an API for
something testing only? Why isn't a customer testing module enough for
such a purpose?
In other words, why do we have to add an API that has to be maintained
for ever for a testing only purpose?
Besides that, what is the reason to use __remove_memory rather than the
exported remove_memory which does an additional locking. Also, we do
trust root to do sane things but are we sure that the current BUG-land
mines in the hotplug code are ready enough to be exported for playing?
> Signed-off-by: Robin Murphy
> ---
>
> v2: Use is_memblock_offlined() helper, write up documentation
>
> .../ABI/testing/sysfs-devices-memory | 25 +++
> drivers/base/memory.c | 42 ++-
> 2 files changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-memory
> b/Documentation/ABI/testing/sysfs-devices-memory
> index deef3b5723cf..02a4250964e0 100644
> --- a/Documentation/ABI/testing/sysfs-devices-memory
> +++ b/Documentation/ABI/testing/sysfs-devices-memory
> @@ -91,3 +91,28 @@ Description:
> memory section directory. For example, the following symbolic
> link is created for memory section 9 on node0.
> /sys/devices/system/node/node0/memory9 -> ../../memory/memory9
> +
> +What:/sys/devices/system/memory/probe
> +Date:October 2005
> +Contact: Linux Memory Management list
> +Description:
> + The file /sys/devices/system/memory/probe is write-only, and
> + when written will simulate a physical hot-add of a memory
> + section at the given address. For example, assuming a section
> + of unused memory exists at physical address 0x8000, it can
> + be introduced to the kernel with the following command:
> + # echo 0x8000 > /sys/devices/system/memory/probe
> +Users: Memory hotplug testing and development
> +
> +What:/sys/devices/system/memory/memoryX/remove
> +Date:February 2019
> +Contact: Linux Memory Management list
> +Description:
> + The file /sys/devices/system/memory/memoryX/remove is
> + write-only, and when written with a boolean 'true' value will
> + simulate a physical hot-remove of that memory section. For
> + example, assuming a 1GB section size, the section added by the
> + above "probe" example could be removed again with the following
> + command:
> + # echo 1 > /sys/devices/system/memory/memory2/remove
> +Users: Memory hotplug testing and development
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 048cbf7d5233..1ba9d1a6ba5e 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -521,7 +521,44 @@ static ssize_t probe_store(struct device *dev, struct
> device_attribute *attr,
> }
>
> static DEVICE_ATTR_WO(probe);
> -#endif
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +static ssize_t remove_store(struct device *dev, struct device_attribute
> *attr,
> + const char *buf, size_t count)
> +{
> + struct memory_block *mem = to_memory_block(dev);
> + unsigned long start_pfn = section_nr_to_pfn(mem->start_section_nr);
> + bool remove;
> + int ret;
> +
> + ret = kstrtobool(buf, &remove);
> + if (ret)
> + return ret;
> + if (!remove)
> + return count;
> +
> + if (!is_memblock_offlined(mem))
> + return -EBUSY;
> +
> + ret = lock_device_hotplug_sysfs();
> + if (ret)
> + return ret;
> +
> + if (device_remove_file_self(dev, attr)) {
> + __remove_memory(pfn_to_nid(start_pfn), PFN_PHYS(start_pfn),
> + MIN_MEMORY_BLOCK_SIZE * sections_per_block);
> + ret = count;
> + } else {
> + ret = -EBUSY;
> + }
> +
> + unlock_device_hotplug();
> + return ret;
> +}
> +
> +static DEVICE_ATTR_WO(remove);
> +#endif /* CONFIG_MEMORY_HOTREMOVE */
> +#endif /* CONFIG_ARCH_MEMORY_PROBE */
>
> #ifdef CONFIG_MEMORY_FAILURE
> /*
> @@ -615,6 +652,9 @@ static struct attribute *memory_memblk_attrs[] = {
> &dev_attr_removable.attr,
> #ifdef CONFIG_MEMORY_HOTREMOVE
> &dev_attr_valid_zones.attr
Re: [PATCH] mm,memory_hotplug: Explicitly pass the head to isolate_huge_page
On Fri 08-02-19 10:06:04, Oscar Salvador wrote:
> isolate_huge_page() expects we pass the head of hugetlb page to it:
>
> bool isolate_huge_page(...)
> {
> ...
> VM_BUG_ON_PAGE(!PageHead(page), page);
> ...
> }
>
> While I really cannot think of any situation where we end up with a
> non-head page between hands in do_migrate_range(), let us make sure
> the code is as sane as possible by explicitly passing the Head.
> Since we already got the pointer, it does not take us extra effort.
>
> Signed-off-by: Oscar Salvador
Acked-by: Michal Hocko
Btw.
> ---
> mm/memory_hotplug.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 656ff386ac15..d5f7afda67db 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1378,12 +1378,12 @@ do_migrate_range(unsigned long start_pfn, unsigned
> long end_pfn)
>
> if (PageHuge(page)) {
> struct page *head = compound_head(page);
> - pfn = page_to_pfn(head) + (1< if (compound_order(head) > PFN_SECTION_SHIFT) {
> ret = -EBUSY;
> break;
> }
Why are we doing this, btw?
> - isolate_huge_page(page, &source);
> + pfn = page_to_pfn(head) + (1< + isolate_huge_page(head, &source);
> continue;
> } else if (PageTransHuge(page))
> pfn = page_to_pfn(compound_head(page))
> --
> 2.13.7
--
Michal Hocko
SUSE Labs
Re: [LSF/MM TOPIC] Non standard size THP
On Fri, Feb 08, 2019 at 07:43:57AM +0530, Anshuman Khandual wrote: > Hello, > > THP is currently supported for > > - PMD level pages (anon and file) > - PUD level pages (file - DAX file system) > > THP is a single entry mapping at standard page table levels (either PMD or > PUD) > > But architectures like ARM64 supports non-standard page table level huge pages > with contiguous bits. > > - These are created as multiple entries at either PTE or PMD level > - These multiple entries carry pages which are physically contiguous > - A special PTE bit (PTE_CONT) is set indicating single entry to be contiguous > > These multiple contiguous entries create a huge page size which is different > than standard PMD/PUD level but they provide benefits of huge memory like > less number of faults, bigger TLB coverage, less TLB miss etc. > > Currently they are used as HugeTLB pages because > > - HugeTLB page sizes is carried in the VMA > - Page table walker can operate on multiple PTE or PMD entries given > its size in VMA > - Irrespective of HugeTLB page size its operated with set_huge_pte_at() > at any level > - set_huge_pte_at() is arch specific which knows how to encode multiple > consecutive entries > > But not as THP huge pages because > > - THP size is not encoded any where like VMA > - Page table walker expects it to be either at PUD (HPAGE_PUD_SIZE) or > at PMD (HPAGE_PMD_SIZE) > - Page table operates directly with set_pmd_at() or set_pud_at() > - Direct faulted or promoted huge pages is verified with > [pmd|pud]_trans_huge() > > How non-standard huge pages can be supported for THP > > - THP starts recognizing non standard huge page (exported by arch) like > HPAGE_CONT_(PMD|PTE)_SIZE > - THP starts operating for either on HPAGE_PMD_SIZE or > HPAGE_CONT_PMD_SIZE or HPAGE_CONT_PTE_SIZE > - set_pmd_at() only recognizes HPAGE_PMD_SIZE hence replace > set_pmd_at() with set_huge_pmd_at() > - set_huge_pmd_at() could differentiate between HPAGE_PMD_SIZE or > HPAGE_CONT_PMD_SIZE > - In case for HPAGE_CONT_PTE_SIZE extend page table walker till PTE > level > - Use set_huge_pte_at() which can operate on multiple contiguous PTE > bits You only listed trivial things. All tricky stuff is what make THP transparent. To consider it seriously we need to understand what it means for split_huge_p?d()/split_huge_page()? How khugepaged will deal with this? In particular, I'm worry to expose (to user or CPU) page table state in the middle of conversion (huge->small or small->huge). Handling this on page table level provides a level atomicity that you will not have. Honestly, I'm very skeptical about the idea. It took a lot of time to stabilize THP for singe page size, equal to PMD page table, but this looks like a new can of worms. :P It *might* be possible to support it for DAX, but beyond that... -- Kirill A. Shutemov
Re: [RESEND PATCH v2 08/33] ARM: davinci: make irqs.h a local header
On 11/02/19 5:55 PM, Bartosz Golaszewski wrote: > diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c > index 9d4a58a3113a..cde72ba35dc3 100644 > --- a/arch/arm/mach-davinci/usb.c > +++ b/arch/arm/mach-davinci/usb.c > @@ -5,13 +5,14 @@ > #include > #include > #include > - > +#include > #include > > #include > -#include > #include > -#include > + > + Drop one extra empty line here. > +#include "irqs.h" Thanks, Sekhar
Re: [PATCH v4 05/10] mfd: max77650: new core mfd driver
On Tue, 05 Feb 2019, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Add the core mfd driver for max77650 PMIC. We define five sub-devices
> for which the drivers will be added in subsequent patches.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/mfd/Kconfig | 11 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/max77650.c | 342 +++
> include/linux/mfd/max77650.h | 59 ++
> 4 files changed, 413 insertions(+)
> create mode 100644 drivers/mfd/max77650.c
> create mode 100644 include/linux/mfd/max77650.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 76f9909cf396..a80c3fe80fbe 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -734,6 +734,17 @@ config MFD_MAX77620
> provides common support for accessing the device; additional drivers
> must be enabled in order to use the functionality of the device.
>
> +config MFD_MAX77650
> + tristate "Maxim MAX77650/77651 PMIC Support"
> + depends on I2C
> + depends on OF || COMPILE_TEST
> + select MFD_CORE
> + select REGMAP_I2C
> + help
> + Say yes here to add support for Maxim Semiconductor MAX77650 and
> + MAX77651 Power Management ICs. This is the core multifunction
> + driver for interacting with the device.
> +
> config MFD_MAX77686
> tristate "Maxim Semiconductor MAX77686/802 PMIC Support"
> depends on I2C
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 12980a4ad460..3b912a4015d1 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -151,6 +151,7 @@ obj-$(CONFIG_MFD_DA9150) += da9150-core.o
>
> obj-$(CONFIG_MFD_MAX14577) += max14577.o
> obj-$(CONFIG_MFD_MAX77620) += max77620.o
> +obj-$(CONFIG_MFD_MAX77650) += max77650.o
> obj-$(CONFIG_MFD_MAX77686) += max77686.o
> obj-$(CONFIG_MFD_MAX77693) += max77693.o
> obj-$(CONFIG_MFD_MAX77843) += max77843.o
> diff --git a/drivers/mfd/max77650.c b/drivers/mfd/max77650.c
> new file mode 100644
> index ..7c6164f1fde4
> --- /dev/null
> +++ b/drivers/mfd/max77650.c
> @@ -0,0 +1,342 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2018 BayLibre SAS
> +// Author: Bartosz Golaszewski
> +//
> +// Core MFD driver for MAXIM 77650/77651 charger/power-supply.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX77650_INT_GPI_F_MSK BIT(0)
> +#define MAX77650_INT_GPI_R_MSK BIT(1)
> +#define MAX77650_INT_GPI_MSK \
> + (MAX77650_INT_GPI_F_MSK | MAX77650_INT_GPI_R_MSK)
> +#define MAX77650_INT_nEN_F_MSK BIT(2)
> +#define MAX77650_INT_nEN_R_MSK BIT(3)
> +#define MAX77650_INT_TJAL1_R_MSK BIT(4)
> +#define MAX77650_INT_TJAL2_R_MSK BIT(5)
> +#define MAX77650_INT_DOD_R_MSK BIT(6)
> +
> +#define MAX77650_INT_THM_MSK BIT(0)
> +#define MAX77650_INT_CHG_MSK BIT(1)
> +#define MAX77650_INT_CHGIN_MSK BIT(2)
> +#define MAX77650_INT_TJ_REG_MSK BIT(3)
> +#define MAX77650_INT_CHGIN_CTRL_MSK BIT(4)
> +#define MAX77650_INT_SYS_CTRL_MSKBIT(5)
> +#define MAX77650_INT_SYS_CNFG_MSKBIT(6)
> +
> +#define MAX77650_INT_GLBL_OFFSET 0
> +#define MAX77650_INT_CHG_OFFSET 1
> +
> +#define MAX77650_SBIA_LPM_MASK BIT(5)
> +#define MAX77650_SBIA_LPM_DISABLED 0x00
> +
> +enum {
> + MAX77650_INT_GPI = 0,
> + MAX77650_INT_nEN_F,
> + MAX77650_INT_nEN_R,
> + MAX77650_INT_TJAL1_R,
> + MAX77650_INT_TJAL2_R,
> + MAX77650_INT_DOD_R,
> + MAX77650_INT_THM,
> + MAX77650_INT_CHG,
> + MAX77650_INT_CHGIN,
> + MAX77650_INT_TJ_REG,
> + MAX77650_INT_CHGIN_CTRL,
> + MAX77650_INT_SYS_CTRL,
> + MAX77650_INT_SYS_CNFG,
> +};
> +
> +enum {
> + MAX77650_CELL_REGULATOR = 0,
> + MAX77650_CELL_CHARGER,
> + MAX77650_CELL_GPIO,
> + MAX77650_CELL_LED,
> + MAX77650_CELL_ONKEY,
> + MAX77650_NUM_CELLS,
> +};
> +
> +struct max77650_irq_mapping {
> + int cell_num;
> + const int *irqs;
> + const char *const *irq_names;
> + unsigned int num_irqs;
> +};
> +
> +static const int max77650_charger_irqs[] = {
> + MAX77650_INT_CHG,
> + MAX77650_INT_CHGIN,
> +};
> +
> +static const int max77650_gpio_irqs[] = {
> + MAX77650_INT_GPI,
> +};
> +
> +static const int max77650_onkey_irqs[] = {
> + MAX77650_INT_nEN_F,
> + MAX77650_INT_nEN_R,
> +};
> +
> +static const char *const max77650_charger_irq_names[] = {
> + "CHG",
> + "CHGIN",
> +};
> +
> +static const char *const max77650_gpio_irq_names[] = {
> + "GPI",
> +};
> +
> +static const char *const max77650_onkey_irq_names[] = {
> + "nEN_F",
> + "nEN_R",
> +};
> +
> +static const struct max77650_irq_mapping max77650_irq_mapping_table[] = {
> + {
> + .cell_num = MAX77650_CELL_CHARGER,
>
[PATCH v6 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Cadence OSPI controller IP supports Octal IO (x8 IO lines),
It also has an integrated PHY. IP register layout is very
similar to existing QSPI IP except for additional bits to support Octal
and Octal DDR mode. Therefore, extend current driver to support Octal
mode. Only Octal SDR read (1-1-8)mode is supported for now.
Tested with mt35xu512aba Octal flash on TI's AM654 EVM.
Signed-off-by: Vignesh R
---
v6: Return error when driver data is not found
drivers/mtd/spi-nor/cadence-quadspi.c | 59 +--
1 file changed, 47 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 04cedd3a2bf6..c8b81e0a76cc 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -44,6 +44,12 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+/* Capabilities mask */
+#define CQSPI_BASE_HWCAPS_MASK \
+ (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
+ SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
+ SNOR_HWCAPS_PP)
+
struct cqspi_st;
struct cqspi_flash_pdata {
@@ -93,6 +99,11 @@ struct cqspi_st {
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
+struct cqspi_driver_platdata {
+ u32 hwcaps_mask;
+ u8 quirks;
+};
+
/* Operation timeout value */
#define CQSPI_TIMEOUT_MS 500
#define CQSPI_READ_TIMEOUT_MS 10
@@ -101,6 +112,7 @@ struct cqspi_st {
#define CQSPI_INST_TYPE_SINGLE 0
#define CQSPI_INST_TYPE_DUAL 1
#define CQSPI_INST_TYPE_QUAD 2
+#define CQSPI_INST_TYPE_OCTAL 3
#define CQSPI_DUMMY_CLKS_PER_BYTE 8
#define CQSPI_DUMMY_BYTES_MAX 4
@@ -911,6 +923,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
int read)
case SNOR_PROTO_1_1_4:
f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
break;
+ case SNOR_PROTO_1_1_8:
+ f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
+ break;
default:
return -EINVAL;
}
@@ -1213,21 +1228,23 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
{
- const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ |
- SNOR_HWCAPS_READ_FAST |
- SNOR_HWCAPS_READ_1_1_2 |
- SNOR_HWCAPS_READ_1_1_4 |
- SNOR_HWCAPS_PP,
- };
struct platform_device *pdev = cqspi->pdev;
struct device *dev = &pdev->dev;
+ const struct cqspi_driver_platdata *ddata;
+ struct spi_nor_hwcaps hwcaps;
struct cqspi_flash_pdata *f_pdata;
struct spi_nor *nor;
struct mtd_info *mtd;
unsigned int cs;
int i, ret;
+ ddata = of_device_get_match_data(dev);
+ if (!ddata) {
+ dev_err(dev, "Couldnt't find driver data\n");
+ return -EINVAL;
+ }
+ hwcaps.mask = ddata->hwcaps_mask;
+
/* Get flash device data */
for_each_available_child_of_node(dev->of_node, np) {
ret = of_property_read_u32(np, "reg", &cs);
@@ -1310,7 +1327,7 @@ static int cqspi_probe(struct platform_device *pdev)
struct cqspi_st *cqspi;
struct resource *res;
struct resource *res_ahb;
- unsigned long data;
+ const struct cqspi_driver_platdata *ddata;
int ret;
int irq;
@@ -1377,8 +1394,8 @@ static int cqspi_probe(struct platform_device *pdev)
}
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
- data = (unsigned long)of_device_get_match_data(dev);
- if (data & CQSPI_NEEDS_WR_DELAY)
+ ddata = of_device_get_match_data(dev);
+ if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
cqspi->master_ref_clk_hz);
@@ -1460,14 +1477,32 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
#define CQSPI_DEV_PM_OPS NULL
#endif
+static const struct cqspi_driver_platdata cdns_qspi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+};
+
+static const struct cqspi_driver_platdata k2g_qspi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
+static const struct cqspi_driver_platdata am654_ospi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK | SNOR_HWCAPS_READ_1_1_8,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
- .data = (void *)0,
+ .data = &cdns_qspi,
},
[PATCH v6 0/2] cadence-quadspi: Add Octal mode support
This series adds support for OSPI version of Cadence QSPI controller IP. Tested with AM654 EVM with MT35x512 Octal flash Changes: v5: Fix comments from by on v4. v4: Fix comments on v3 by Tudor. Rebase on top latest linux-next(all dependencies are now part of -next) v3: Rebase on top of v7 of Yogesh's series[1] v2: spi-nor core patches dropped, are now part of Yogesh's series [1] Declare Octal mode capability based on compatible. Vignesh R (2): dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 59 +++ 2 files changed, 48 insertions(+), 12 deletions(-) -- 2.20.1
[PATCH v6 1/2] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R Reviewed-by: Rob Herring --- v6: No change Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.20.1
Re: [PATCH v2 04/11] mfd: pm8xxx: convert to v2 irq interfaces to support hierarchical IRQ chips
On Thu, 07 Feb 2019, Brian Masney wrote: > Convert the PM8XXX IRQ code to use the version 2 IRQ interface in order > to support hierarchical IRQ chips. This is necessary so that ssbi-gpio > can be setup as a hierarchical IRQ chip with PM8xxx as the parent. IRQ > chips in device tree should be usable from the start without having to > make an additional call to gpio[d]_to_irq() to get the proper IRQ on the > parent. > > pm8821_irq_domain_ops and pm8821_irq_domain_map are removed by this > patch since the irq_chip is now contained in the pm_irq_data struct, and > that allows us to use a common IRQ mapping function. > > This change was tested on an APQ8060 DragonBoard. > > Signed-off-by: Brian Masney > Tested-by: Linus Walleij > --- > Changes since v1: > - Put u8 config[0] at end along with a comment > - Hardcode the IRQ flow handler as handle_level_irq like the original > code. > - Don't set IRQ handler in pm8xxx_irq_set_type() since this is already > done in pm8xxx_irq_domain_map(). Linus: This is different than what > you tested but this *should* be fine. > > drivers/mfd/qcom-pm8xxx.c | 75 --- > 1 file changed, 38 insertions(+), 37 deletions(-) For Linus: Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
RE: [PATCH] uprobes: convert uprobe.ref to refcount_t
On Mon, 11 Feb 2019 13:49:27 -0800 > Kees Cook wrote: > > > On Mon, Feb 11, 2019 at 12:28 PM Steven Rostedt wrote: > > > > > > On Mon, 11 Feb 2019 15:27:25 -0500 > > > Steven Rostedt wrote: > > > > > > > On Mon, 11 Feb 2019 12:21:32 -0800 > > > > Kees Cook wrote: > > > > > > > > > > > Looks good to me. > > > > > > > > > > > > > > Reviewed-by: Srikar Dronamraju > > > > > > > > > > > > Thank you very much Srikar! > > > > > > Would you be able to take this patch to integration? > > > > > > > > > > Steve can you pick this up with Srikar's Reviewed-by? > > > > > > > > Yep. And I'll also add Oleg's acked-by. (Currently doing my "urgent" > > > > patches now). > > > > > > > > > > Or is this something that can wait till the next merge window? > > > > I wouldn't classify the change as _urgent_, no. For "next merge > > window" you mean v5.1, I assume? I think that'd be fine unless Elena > > sees something I don't. > > OK, then I'll just place this in the "for-next" branch of mine. Still > need to test what I current have ;-) Sure, thank you very much! It is not any urgent stuff! Best Regards, Elena.
Re: [PATCH v2 05/11] mfd: pm8xxx: disassociate old virq if hwirq mapping already exists
On Thu, 07 Feb 2019, Brian Masney wrote: > Check to see if the hwirq is already associated with another virq on > this IRQ domain. If so, then disassociate it before associating the > hwirq with the new virq. > > This is a temporary hack that is needed in order to not break git > bisect for existing boards. The next patch in this series converts > ssbi-gpio to be a hierarchical IRQ chip, then there are several patches > to update all of the device tree files, and finally this patch will be > reverted within the same patch series. > > IRQs for ssbi-gpio are all initially setup without an IRQ hierarchy > this driver is probed due to the interrupts property in device tree. > Once ssbi-gpio is converted to be a hierarchical IRQ chip in the next > patch, existing users of gpio[d]_to_irq() will call pmic_gpio_to_irq(), > and that will use the new IRQ chip code in ssbi-gpio that sets up the > IRQ in an IRQ hierarchy. The hwirq is now associated with two Linux > virqs and interrupts will not work as expected. This patch corrects > that issue. > > This change was tested on an APQ8060 DragonBoard. > > Signed-off-by: Brian Masney > Tested-by: Linus Walleij > --- > Changes since v1: > - None > > drivers/mfd/qcom-pm8xxx.c | 6 ++ > 1 file changed, 6 insertions(+) For Linus: Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 0/4] Add new device nodes for Spreadtrum SC9860 platform
Hi Mark,
Sorry for late reply.
On Fri, 1 Feb 2019 at 21:05, Mark Brown wrote:
>
> On Fri, Feb 01, 2019 at 08:05:30PM +0800, Baolin Wang wrote:
>
> > On Spreadtrum platform, we use one mfd driver [1] to populate the
> > SC27XX series PMICs including SC2731, SC2721, SC2720 and SC2730. So we
> > use sc27xx to be compatible with different PMICs' devices, otherwise
> > it will be difficult to define the mfd cell arrays in mfd driver. Do
> > you have any good suggestion? Thanks.
>
> You can just list all the individual device names in the of_match_table
> for the MFD and then it can bind to any of them. You can always map
> them onto the same behaviour in the MFD driver if they are identical
> from a software point of view.
If I understood correctly, as you suggested, we should add new
mfd_cell groups to list all different PMICs' device names. Something
like:
static const struct mfd_cell sprd_pmic_sc2731_devs[] = {
{
.name = "sc27xx-wdt",
.of_compatible = "sprd,sc2731-wdt",
}, {
.name = "sc27xx-rtc",
.of_compatible = "sprd,sc2731-rtc",
}, {
.name = "sc27xx-charger",
.of_compatible = "sprd,sc2731-charger",
}, {
.name = "sc27xx-fast-chg",
.of_compatible = "sprd,sc2731-fast-chg",
}, {
.name = "sc27xx-typec",
.of_compatible = "sprd,sc2731-typec",
}, {
.name = "sc27xx-eic",
.of_compatible = "sprd,sc2731-eic",
},
...
};
static const struct mfd_cell sprd_pmic_sc2730_devs[] = {
{
.name = "sc27xx-wdt",
.of_compatible = "sprd,sc2730-wdt",
}, {
.name = "sc27xx-rtc",
.of_compatible = "sprd,sc2730-rtc",
}, {
.name = "sc27xx-charger",
.of_compatible = "sprd,sc2730-charger",
}, {
.name = "sc27xx-fast-chg",
.of_compatible = "sprd,sc2730-fast-chg",
}, {
.name = "sc27xx-typec",
.of_compatible = "sprd,sc2730-typec",
}, {
.name = "sc27xx-eic",
.of_compatible = "sprd,sc2730-eic",
},
...
};
..
But from my point, they are just some meaningless duplication, and
will waste lots of code there.
--
Baolin Wang
Best Regards
Re: RFC: drop ISA support in the synlink tty driver?
On 12. 02. 19, 9:25, Greg Kroah-Hartman wrote: > It's just a #define, in a uapi file, so we should probably leave it as > userspace programs _might_ depend on it. I have no idea why, but oh > well... Uh, I didn't even think this could be in a uapi header. Ok, it makes sense then. thanks, -- js suse labs
Re: [PATCH] ser_gigaset: mark expected switch fall-through
Gustavo A. R. Silva schreef op ma 11-02-2019 om 16:34 [-0600]:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warning:
>
> drivers/isdn/gigaset/ser-gigaset.c: In function ‘gigaset_tty_ioctl’:
> drivers/isdn/gigaset/ser-gigaset.c:627:3: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
>switch (arg) {
>^~
> drivers/isdn/gigaset/ser-gigaset.c:638:2: note: here
> default:
> ^~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Paul Bolle
Thanks,
Paul Bolle
Re: [PATCH 5/5] riscv: use for_each_of_cpu_node iterator
On 2/12/19 12:26 AM, Johan Hovold wrote: On Mon, Feb 11, 2019 at 11:13:39PM -0800, Christoph Hellwig wrote: On Fri, Jan 18, 2019 at 03:03:08PM +0100, Johan Hovold wrote: Use the new for_each_of_cpu_node() helper to iterate over cpu nodes instead of open coding. Note that this will allow matching also on the node name instead of the (for FDT) deprecated device_type property. Signed-off-by: Johan Hovold I think this is going to conflict with the ELF caps changes from Atish. Maybe the riscv_fill_hwcap hunk should be included in his patch? Since that patch had some issues (e.g. the node reference underflow) it may be better to rebase it on top of this series. The changes are otherwise distinct after all. I have fixed the node reference underflow issue and made some more changes based on comments. Some other patches(1,3,4,5) in this series may conflict with my series as well. I can rebase my series on top of yours and send it as one series if that's okay with you and Palmer. Regards, Atish Otherwise looks good: Reviewed-by: Christoph Hellwig Thanks for reviewing! Johan
Re: [PATCH] checkpatch: Properly detect /* */ style SPDX header.
On Fri, Feb 1, 2019 at 12:54 AM Joe Perches wrote: > > On Thu, 2019-01-31 at 17:56 +0800, Pi-Hsun Shih wrote: > > Currently for a header line "/* SPDX-License-Identifier: GPL-2.0 */", > > only the part starting from "SPDX-" is passed to spdxcheck.py, and cause > > false warning. Fix this by passing the whole line to spdxcheck.py > > instead. > > Thanks but I submitted a different patch: > > https://lore.kernel.org/lkml/8b02899853247a2c67669561761f354dd3bd110e.ca...@perches.com/ > I tried your patch, but when running checkpatch.pl on https://patchwork.kernel.org/patch/10790203/, I still get: WARNING: 'SPDX-License-Identifier: GPL-2.0 */' is not supported in LICENSES/... #75: FILE: drivers/remoteproc/mtk_common.h:1: +/* SPDX-License-Identifier: GPL-2.0 */ Feels that these two patches fix different issues.
[PATCH 1/2] chardev: fix an overlap misjudgement case in __register_chrdev_region()
Current overlap check of minor range cannot correctly
handle a case which is baseminor < existing baseminor &&
baseminor + minorct > existing baseminor + minorct.
Fix it and meanwhile do some code cleanups.
Fixes: 01d553d0fe9f90 ("Chardev checking of overlapping ranges")
Signed-off-by: Chengguang Xu
Cc: sta...@vger.kernel.org
---
fs/char_dev.c | 94 ---
1 file changed, 44 insertions(+), 50 deletions(-)
diff --git a/fs/char_dev.c b/fs/char_dev.c
index a279c58fe360..b25b1da097d5 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -88,86 +88,80 @@ static int find_dynamic_major(void)
/*
* Register a single major with a specified minor range.
*
- * If major == 0 this functions will dynamically allocate a major and return
- * its number.
- *
- * If major > 0 this function will attempt to reserve the passed range of
- * minors and will return zero on success.
+ * If major == 0 this function will dynamically allocate an unused major,
+ * otherwise attempt to reserve the range of minors with given major.
*
- * Returns a -ve errno on failure.
*/
static struct char_device_struct *
__register_chrdev_region(unsigned int major, unsigned int baseminor,
int minorct, const char *name)
{
- struct char_device_struct *cd, **cp;
- int ret = 0;
+ struct char_device_struct *new, *curr, *prev = NULL;
+ int ret = -EBUSY;
int i;
- cd = kzalloc(sizeof(struct char_device_struct), GFP_KERNEL);
- if (cd == NULL)
+ if (major >= CHRDEV_MAJOR_MAX) {
+ pr_err("CHRDEV \"%s\" major requested (%u) is greater than the
maximum (%u)\n",
+ name, major, CHRDEV_MAJOR_MAX-1);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (minorct > MINORMASK + 1 - baseminor) {
+ pr_err("CHRDEV \"%s\" minor range requested (%u-%u) is out of
range of maximum range (%u-%u) for a single major\n",
+ name, baseminor, baseminor + minorct - 1, 0, MINORMASK);
+ return ERR_PTR(-EINVAL);
+ }
+
+ new = kzalloc(sizeof(struct char_device_struct), GFP_KERNEL);
+ if (new == NULL)
return ERR_PTR(-ENOMEM);
mutex_lock(&chrdevs_lock);
if (major == 0) {
- ret = find_dynamic_major();
- if (ret < 0) {
+ major = find_dynamic_major();
+ if (major < 0) {
pr_err("CHRDEV \"%s\" dynamic allocation region is
full\n",
name);
goto out;
}
- major = ret;
}
- if (major >= CHRDEV_MAJOR_MAX) {
- pr_err("CHRDEV \"%s\" major requested (%u) is greater than the
maximum (%u)\n",
- name, major, CHRDEV_MAJOR_MAX-1);
- ret = -EINVAL;
- goto out;
- }
-
- cd->major = major;
- cd->baseminor = baseminor;
- cd->minorct = minorct;
- strlcpy(cd->name, name, sizeof(cd->name));
-
i = major_to_index(major);
+ for (curr = chrdevs[i]; curr; prev = curr, curr = curr->next) {
+ if (curr->major < major)
+ continue;
- for (cp = &chrdevs[i]; *cp; cp = &(*cp)->next)
- if ((*cp)->major > major ||
- ((*cp)->major == major &&
-(((*cp)->baseminor >= baseminor) ||
- ((*cp)->baseminor + (*cp)->minorct > baseminor
+ if (curr->major > major)
break;
- /* Check for overlapping minor ranges. */
- if (*cp && (*cp)->major == major) {
- int old_min = (*cp)->baseminor;
- int old_max = (*cp)->baseminor + (*cp)->minorct - 1;
- int new_min = baseminor;
- int new_max = baseminor + minorct - 1;
+ if (curr->baseminor + curr->minorct <= baseminor)
+ continue;
- /* New driver overlaps from the left. */
- if (new_max >= old_min && new_max <= old_max) {
- ret = -EBUSY;
- goto out;
- }
+ if (curr->baseminor >= baseminor + minorct)
+ break;
- /* New driver overlaps from the right. */
- if (new_min <= old_max && new_min >= old_min) {
- ret = -EBUSY;
- goto out;
- }
+ goto out;
+ }
+
+ new->major = major;
+ new->baseminor = baseminor;
+ new->minorct = minorct;
+ strlcpy(new->name, name, sizeof(new->name));
+
+ if (!prev) {
+ new->next = curr;
+ chrdevs[i] = new;
+ } else {
+ new->next = prev->next;
+ prev->next = new;
}
- cd->next = *cp;
- *cp = cd;
mutex_unlock(&chrde
[PATCH 2/2] chardev: showing minor range for chardev in the output of /proc/devices
Currently chardev allows to share major, showing
major with minor range for chardev will be more
helpful.
Signed-off-by: Chengguang Xu
---
fs/char_dev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/char_dev.c b/fs/char_dev.c
index b25b1da097d5..6f00acdeb308 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -55,7 +55,9 @@ void chrdev_show(struct seq_file *f, off_t offset)
mutex_lock(&chrdevs_lock);
for (cd = chrdevs[major_to_index(offset)]; cd; cd = cd->next) {
if (cd->major == offset)
- seq_printf(f, "%3d %s\n", cd->major, cd->name);
+ seq_printf(f, "%3d %s (%u-%u)\n", cd->major, cd->name,
+ cd->baseminor,
+ cd->baseminor + cd->minorct - 1);
}
mutex_unlock(&chrdevs_lock);
}
--
2.20.1
Re: [PATCH 4.20 282/352] fs/proc/base.c: use ns_capable instead of capable for timerslack_ns
On Mon, Feb 11, 2019 at 07:02:06PM -0600, Eric W. Biederman wrote: > Greg Kroah-Hartman writes: > > > 4.20-stable review patch. If anyone has any objections, please let me > > know. > > No objection. But I think of this as a feature addition rather than a > fix for something. As a feature that we now allow something we > previously did not does this qualify for a backport to stable? > > It is probably no more harmful in this instance than adding PCI IDs to a > driver. So I am not worried. I am curious the current guidelines > are. > > In most cases a small relaxation of permissions like this requires a lot > of bug fixing as typically code protected by capable(CAP_XXX) has been > written and tested assuming a trusted root user. Those bug fixes are > many times too large for a stable backport. Fair enough, patch is now dropped, thanks for the review. greg k-h
Re: [PATCH v1] mfd: intel-lpss: Move linux/pm.h to the local header
On Fri, 08 Feb 2019, Andy Shevchenko wrote:
> On Fri, Feb 01, 2019 at 03:08:17PM +, Lee Jones wrote:
> > On Fri, 01 Feb 2019, Andy Shevchenko wrote:
> > > On Fri, Feb 1, 2019 at 11:50 AM Lee Jones wrote:
> > > > On Thu, 24 Jan 2019, Andy Shevchenko wrote:
> > > >
> > > > > We now using a common macro for PM operations in Intel LPSS driver,
> > > > > and, since that macro relies on the definition and macro from
> > > > > linux/pm.h
> > > > > header file, it's logical to include it directly in intel-lpss.h.
> > > > > Otherwise it's a bit fragile and requires a proper ordering
> > > > > of header inclusion in C files.
> > > >
> > > > I don't agree with this. File which use various headers should
> > > > explicitly include them. Inheriting header files is non-optimal.
> > > >
> > >
> > > intel-lpss.h _is_ using pm.h.
> > > I don't see a contradiction here.
> >
> > Then it should be including in there *also*.
>
> Why?
>
> intel-lpss-*.c are not direct users of this header.
They're not? That's is where the miscommunication lies then.
If a C-file isn't using the offerings of a headerfile, obviously there
is no need for the C-file to include it.
> > My point is that if drivers/mfd/intel-lpss-{acpi,pci}.c use the header
> > file, it should include it explicitly.
>
> They are using it indirectly.
Indirectly is fine.
> As far as I know we don't, for example, include "asm/*.h" to each of our
> C-file
> because they are in _indirect_ use of.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCHv4 10/13] node: Add memory caching attributes
On Mon, 11 Feb 2019 08:23:04 -0700 Keith Busch wrote: > On Sun, Feb 10, 2019 at 09:19:58AM -0800, Jonathan Cameron wrote: > > On Sat, 9 Feb 2019 09:20:53 +0100 > > Brice Goglin wrote: > > > > > Hello Keith > > > > > > Could we ever have a single side cache in front of two NUMA nodes ? I > > > don't see a way to find that out in the current implementation. Would we > > > have an "id" and/or "nodemap" bitmask in the sidecache structure ? > > > > This is certainly a possible thing for hardware to do. > > > > ACPI IIRC doesn't provide any means of representing that - your best > > option is to represent it as two different entries, one for each of the > > memory nodes. Interesting question of whether you would then claim > > they were half as big each, or the full size. Of course, there are > > other possible ways to get this info beyond HMAT, so perhaps the interface > > should allow it to be exposed if available? > > HMAT doesn't do this, but I want this interface abstracted enough from > HMAT to express whatever is necessary. > > The CPU cache is the closest existing exported attributes to this, > and they provide "shared_cpu_list". To that end, I can export a > "shared_node_list", though previous reviews strongly disliked multi-value > sysfs entries. :( > > Would shared-node symlinks capture the need, and more acceptable? My inclination is that it's better to follow an existing pattern than invent a new one that breaks people's expectations. However, don't feel that strongly about it as long as the interface is functional and intuitive. > > > Also, don't know if it's just me, but calling these sidecaches is > > downright confusing. In ACPI at least they are always > > specifically referred to as Memory Side Caches. > > I'd argue there should even by a hyphen Memory-Side Caches, the point > > being that that they are on the memory side of the interconnected > > rather than the processor side. Of course an implementation > > choice might be to put them off to the side (as implied by sidecaches) > > in some sense, but it's not the only one. > > > > :) > > Now that you mention it, I agree "side" is ambiguous. Maybe call it > "numa_cache" or "node_cache"? I'm not sure any of the options work well. My inclination would be to use the full name and keep the somewhat redundant memory there. The other two feel like they could just as easily be coherent caches at accelerators for example... memory_side_cache? The fun of naming ;) Jonathan
Re: [PATCH v1] mfd: intel-lpss: Move linux/pm.h to the local header
On Thu, 24 Jan 2019, Andy Shevchenko wrote: > We now using a common macro for PM operations in Intel LPSS driver, > and, since that macro relies on the definition and macro from linux/pm.h > header file, it's logical to include it directly in intel-lpss.h. > Otherwise it's a bit fragile and requires a proper ordering > of header inclusion in C files. > > Signed-off-by: Andy Shevchenko > --- > drivers/mfd/intel-lpss-acpi.c | 1 - > drivers/mfd/intel-lpss-pci.c | 1 - > drivers/mfd/intel-lpss.h | 2 ++ > 3 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 6/9] usb: roles: Find the muxes by also matching against the device node
Hi,
On Tue, Feb 12, 2019 at 06:03:42AM +, Jun Li wrote:
> > > return dev_fwnode(dev->parent) == fwnode;
> >
> > That's actually not the case. struct usb_role_switch_desc has a member for
> > fwnode,
> > and that's what we use with the actual mux device. Check
> > usb_role_switch_register():
> >
> > ...
> > sw->dev.fwnode = desc->fwnode;
> > ...
> >
> > Sorry for not realizing it before.
>
> So desc->fwnode should be initialized before do usb_role_switch_register()?
> But seems usb_role_switch_desc is a read-only object so can't be set at
> runtime.
It can. Even though usb_role_switch_register() takes read-only
parameter, nothing's preventing you from passing data even from the
stack (the content of the descriptor is copied in any case).
Expecting the descriptor to be read-only just means it can be
read-only, but it does not have to be.
> usb_controller_node {
> ...
> usb-role-switch;
>
> port {
> sw_provider_node: endpoint {
> remote-endpoint = <&sw_consumer_node>;
> };
> };
> };
>
> typec_node {
> ...
> port {
> sw_consumer_node: endpoint {
> remote-endpoint = <&sw_provider_node>;
> };
> };
> };
That looks roughly correct to me.
thanks,
--
heikki
Re: [PATCH 4.20 081/352] f2fs: avoid build warn of fall_through
On Tue, Feb 12, 2019 at 07:21:00AM +1100, Stephen Rothwell wrote: > Hi all, > > On Tue, 12 Feb 2019 07:18:58 +1100 Stephen Rothwell > wrote: > > > > Does the 4.20 stable tree use -Wimplicit-fallthrough? I assume not > > (since v4.20 doesn't), so this warning does not happen in that tree. > > Ditto for 4.19, 4.14 and 4.9. You are right, I thought this was needed for a later patch in the series, but it wasn't, so I'll go drop it from all trees now, thanks. greg k-h
Re: [PATCH v2 2/9] irq/irq_sim: use irq domain
Bartosz,
On Tue, 12 Feb 2019 08:30:32 +,
Bartosz Golaszewski wrote:
>
> pon., 11 lut 2019 o 23:26 Marc Zyngier napisał(a):
> >
> > On Tue, 29 Jan 2019 09:44:04 +0100
> > Bartosz Golaszewski wrote:
> >
> > > From: Bartosz Golaszewski
> > >
> > > Delegate the offset to virq number mapping to the provided framework
> > > instead of handling it locally. Use the legacy domain as we want to
> > > preallocate the irq descriptors.
> >
> > Why?
> >
> > >
> > > Signed-off-by: Bartosz Golaszewski
> > > ---
> > > include/linux/irq_sim.h | 6 +--
> > > kernel/irq/irq_sim.c| 94 +
> > > 2 files changed, 71 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/include/linux/irq_sim.h b/include/linux/irq_sim.h
> > > index eda132c22b57..b96c2f752320 100644
> > > --- a/include/linux/irq_sim.h
> > > +++ b/include/linux/irq_sim.h
> > > @@ -8,6 +8,7 @@
> > >
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
> > > /*
> > > @@ -21,16 +22,15 @@ struct irq_sim_work_ctx {
> > > };
> > >
> > > struct irq_sim_irq_ctx {
> > > - int irqnum;
> > > boolenabled;
> > > };
> > >
> > > struct irq_sim {
> > > struct irq_chip chip;
> > > + struct irq_domain *domain;
> > > struct irq_sim_work_ctx work_ctx;
> > > - int irq_base;
> > > + int virq_base;
> > > unsigned intirq_count;
> > > - struct irq_sim_irq_ctx *irqs;
> > > };
> > >
> > > int irq_sim_init(struct irq_sim *sim, unsigned int num_irqs);
> > > diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c
> > > index b732e4e2e45b..2bcdbab1bc5a 100644
> > > --- a/kernel/irq/irq_sim.c
> > > +++ b/kernel/irq/irq_sim.c
> > > @@ -44,6 +44,43 @@ static void irq_sim_handle_irq(struct irq_work *work)
> > > }
> > > }
> > >
> > > +static int irq_sim_domain_map(struct irq_domain *domain,
> > > + unsigned int virq, irq_hw_number_t hw)
> > > +{
> > > + struct irq_sim *sim = domain->host_data;
> > > + struct irq_sim_irq_ctx *ctx;
> > > +
> > > + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> > > + if (!ctx)
> > > + return -ENOMEM;
> > > +
> > > + irq_set_chip(virq, &sim->chip);
> > > + irq_set_chip_data(virq, ctx);
> > > + irq_set_handler(virq, handle_simple_irq);
> >
> > Consider using modern APIs such as irq_domain_set_info().
> >
> > > + irq_modify_status(virq, IRQ_NOREQUEST | IRQ_NOAUTOEN, IRQ_NOPROBE);
> >
> > Where is this requirement coming from?
> >
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void irq_sim_domain_free(struct irq_domain *domain,
> > > + unsigned int virq, unsigned int num_irqs)
> > > +{
> > > + struct irq_sim_irq_ctx *ctx;
> > > + struct irq_data *irq;
> > > + int i;
> > > +
> > > + for (i = 0; i < num_irqs; i++) {
> > > + irq = irq_domain_get_irq_data(domain, virq + i);
> > > + ctx = irq_data_get_irq_chip_data(irq);
> > > + kfree(ctx);
> > > + }
> > > +}
> > > +
> > > +static const struct irq_domain_ops irq_sim_domain_ops = {
> > > + .map = irq_sim_domain_map,
> > > + .free = irq_sim_domain_free,
> >
> > The intended use of the v2 API is to have alloc and free as a pair, and
> > no map. So please choose which version of the API you're using here.
> > The safest bet would be to move what you do on map into alloc.
> >
> > > +};
> > > +
> > > /**
> > > * irq_sim_init - Initialize the interrupt simulator: allocate a range of
> > > *dummy interrupts.
> > > @@ -56,16 +93,15 @@ static void irq_sim_handle_irq(struct irq_work *work)
> > > */
> > > int irq_sim_init(struct irq_sim *sim, unsigned int num_irqs)
> > > {
> > > - int i;
> > > -
> > > - sim->irqs = kmalloc_array(num_irqs, sizeof(*sim->irqs), GFP_KERNEL);
> > > - if (!sim->irqs)
> > > + sim->virq_base = irq_alloc_descs(-1, 0, num_irqs, 0);
> > > + if (sim->virq_base < 0)
> > > + return sim->virq_base;
> > > +
> > > + sim->domain = irq_domain_add_legacy(NULL, num_irqs, sim->virq_base,
> > > + 0, &irq_sim_domain_ops, sim);
> >
> > Why do you need a legacy domain? As far as I can tell, this is new
> > code, hence it has no legacy.
> >
> > > + if (!sim->domain) {
> > > + irq_free_descs(sim->virq_base, num_irqs);
> > > return -ENOMEM;
> > > -
> > > - sim->irq_base = irq_alloc_descs(-1, 0, num_irqs, 0);
> > > - if (sim->irq_base < 0) {
> > > - kfree(sim->irqs);
> > > - return sim->irq_base;
> > > }
> > >
> > > sim->chip.name = "irq_sim";
> > > @@ -74,25 +110,15 @@ int irq_sim_init(struct irq_sim *sim, unsigned int
> > > num_irqs)
> > >
> > > sim->work_ctx.pending = bitmap_zalloc(num_irqs, GFP_KERNEL);
> > > if (!sim->work_ctx.pending) {
>
Re: [PATCH v4 05/10] mfd: max77650: new core mfd driver
wt., 12 lut 2019 o 09:36 Lee Jones napisał(a):
>
> On Tue, 05 Feb 2019, Bartosz Golaszewski wrote:
>
> > From: Bartosz Golaszewski
> >
> > Add the core mfd driver for max77650 PMIC. We define five sub-devices
> > for which the drivers will be added in subsequent patches.
> >
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > drivers/mfd/Kconfig | 11 ++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/max77650.c | 342 +++
> > include/linux/mfd/max77650.h | 59 ++
> > 4 files changed, 413 insertions(+)
> > create mode 100644 drivers/mfd/max77650.c
> > create mode 100644 include/linux/mfd/max77650.h
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 76f9909cf396..a80c3fe80fbe 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -734,6 +734,17 @@ config MFD_MAX77620
> > provides common support for accessing the device; additional drivers
> > must be enabled in order to use the functionality of the device.
> >
> > +config MFD_MAX77650
> > + tristate "Maxim MAX77650/77651 PMIC Support"
> > + depends on I2C
> > + depends on OF || COMPILE_TEST
> > + select MFD_CORE
> > + select REGMAP_I2C
> > + help
> > + Say yes here to add support for Maxim Semiconductor MAX77650 and
> > + MAX77651 Power Management ICs. This is the core multifunction
> > + driver for interacting with the device.
> > +
> > config MFD_MAX77686
> > tristate "Maxim Semiconductor MAX77686/802 PMIC Support"
> > depends on I2C
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 12980a4ad460..3b912a4015d1 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -151,6 +151,7 @@ obj-$(CONFIG_MFD_DA9150) += da9150-core.o
> >
> > obj-$(CONFIG_MFD_MAX14577) += max14577.o
> > obj-$(CONFIG_MFD_MAX77620) += max77620.o
> > +obj-$(CONFIG_MFD_MAX77650) += max77650.o
> > obj-$(CONFIG_MFD_MAX77686) += max77686.o
> > obj-$(CONFIG_MFD_MAX77693) += max77693.o
> > obj-$(CONFIG_MFD_MAX77843) += max77843.o
> > diff --git a/drivers/mfd/max77650.c b/drivers/mfd/max77650.c
> > new file mode 100644
> > index ..7c6164f1fde4
> > --- /dev/null
> > +++ b/drivers/mfd/max77650.c
> > @@ -0,0 +1,342 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +//
> > +// Copyright (C) 2018 BayLibre SAS
> > +// Author: Bartosz Golaszewski
> > +//
> > +// Core MFD driver for MAXIM 77650/77651 charger/power-supply.
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MAX77650_INT_GPI_F_MSK BIT(0)
> > +#define MAX77650_INT_GPI_R_MSK BIT(1)
> > +#define MAX77650_INT_GPI_MSK \
> > + (MAX77650_INT_GPI_F_MSK | MAX77650_INT_GPI_R_MSK)
> > +#define MAX77650_INT_nEN_F_MSK BIT(2)
> > +#define MAX77650_INT_nEN_R_MSK BIT(3)
> > +#define MAX77650_INT_TJAL1_R_MSK BIT(4)
> > +#define MAX77650_INT_TJAL2_R_MSK BIT(5)
> > +#define MAX77650_INT_DOD_R_MSK BIT(6)
> > +
> > +#define MAX77650_INT_THM_MSK BIT(0)
> > +#define MAX77650_INT_CHG_MSK BIT(1)
> > +#define MAX77650_INT_CHGIN_MSK BIT(2)
> > +#define MAX77650_INT_TJ_REG_MSK BIT(3)
> > +#define MAX77650_INT_CHGIN_CTRL_MSK BIT(4)
> > +#define MAX77650_INT_SYS_CTRL_MSKBIT(5)
> > +#define MAX77650_INT_SYS_CNFG_MSKBIT(6)
> > +
> > +#define MAX77650_INT_GLBL_OFFSET 0
> > +#define MAX77650_INT_CHG_OFFSET 1
> > +
> > +#define MAX77650_SBIA_LPM_MASK BIT(5)
> > +#define MAX77650_SBIA_LPM_DISABLED 0x00
> > +
> > +enum {
> > + MAX77650_INT_GPI = 0,
> > + MAX77650_INT_nEN_F,
> > + MAX77650_INT_nEN_R,
> > + MAX77650_INT_TJAL1_R,
> > + MAX77650_INT_TJAL2_R,
> > + MAX77650_INT_DOD_R,
> > + MAX77650_INT_THM,
> > + MAX77650_INT_CHG,
> > + MAX77650_INT_CHGIN,
> > + MAX77650_INT_TJ_REG,
> > + MAX77650_INT_CHGIN_CTRL,
> > + MAX77650_INT_SYS_CTRL,
> > + MAX77650_INT_SYS_CNFG,
> > +};
> > +
> > +enum {
> > + MAX77650_CELL_REGULATOR = 0,
> > + MAX77650_CELL_CHARGER,
> > + MAX77650_CELL_GPIO,
> > + MAX77650_CELL_LED,
> > + MAX77650_CELL_ONKEY,
> > + MAX77650_NUM_CELLS,
> > +};
> > +
> > +struct max77650_irq_mapping {
> > + int cell_num;
> > + const int *irqs;
> > + const char *const *irq_names;
> > + unsigned int num_irqs;
> > +};
> > +
> > +static const int max77650_charger_irqs[] = {
> > + MAX77650_INT_CHG,
> > + MAX77650_INT_CHGIN,
> > +};
> > +
> > +static const int max77650_gpio_irqs[] = {
> > + MAX77650_INT_GPI,
> > +};
> > +
> > +static const int max77650_onkey_irqs[] = {
> > + MAX77650_INT_nEN_F,
> > + MAX77650_INT_nEN_R,
> > +};
> > +
> > +static const char *const max77650_charger_irq_names[] = {
> > + "CHG",
> > + "CHGIN",
> > +
Re: [PATCH 5/5] riscv: use for_each_of_cpu_node iterator
On Tue, Feb 12, 2019 at 12:47:09AM -0800, Atish Patra wrote: > On 2/12/19 12:26 AM, Johan Hovold wrote: > > On Mon, Feb 11, 2019 at 11:13:39PM -0800, Christoph Hellwig wrote: > >> On Fri, Jan 18, 2019 at 03:03:08PM +0100, Johan Hovold wrote: > >>> Use the new for_each_of_cpu_node() helper to iterate over cpu nodes > >>> instead of open coding. Note that this will allow matching also on the > >>> node name instead of the (for FDT) deprecated device_type property. > >>> > >>> Signed-off-by: Johan Hovold > >> > >> I think this is going to conflict with the ELF caps changes from > >> Atish. Maybe the riscv_fill_hwcap hunk should be included in his > >> patch? > > > > Since that patch had some issues (e.g. the node reference underflow) it > > may be better to rebase it on top of this series. The changes are > > otherwise distinct after all. > > > > I have fixed the node reference underflow issue and made some more > changes based on comments. > > Some other patches(1,3,4,5) in this series may conflict with my series > as well. I can rebase my series on top of yours and send it as one > series if that's okay with you and Palmer. No need for you to resend these patches as they are reviewed any ready to be merged. Just rebase your series and mention the dependency in the cover letter as I did with Andreas's patch which this series depended on. Thanks, Johan
Re: [PATCH 2/2] PCI: imx6: limit DBI register length
Hi Bjorn,
Am Montag, den 11.02.2019, 15:39 -0600 schrieb Bjorn Helgaas:
> On Wed, Feb 06, 2019 at 10:57:32AM +0100, Stefan Agner wrote:
> > Define the length of the DBI registers. This makes sure that
> > the kernel does not access registers beyond that point, avoiding
> > the following abort on a i.MX 6Quad:
> > # cat /sys/devices/soc0/soc/1ffc000.pcie/pci\:00/\:00\:00.0/config
> > [ 100.021433] Unhandled fault: imprecise external abort (0x1406) at
> > 0xb6ea7000
> > ...
> > [ 100.056423] PC is at dw_pcie_read+0x50/0x84
> > [ 100.060790] LR is at dw_pcie_rd_own_conf+0x44/0x48
> > ...
>
> I assume this problem happens when using the pci_read_config() path or
> something similar?
>
> Could this be solved using pci_dev.cfg_size instead of building a new
> dwc-specific mechanism? There are some quirks that set dev->cfg_size
> to keep from reading past certain points in config space, e.g.,
> quirk_citrine(), quirk_nfp6000().
>
> I'm not necessarily opposed to doing it in dwc, but maybe there's some
> advantage in reducing the number of ways of doing the same thing.
This actually started out as a quirk changing the cfg size. But the
valid config space size seems to be different between root ports that
share the same (broken) device ID (Synopsys abcd), so I doubt that this
would be easier and/or any cleaner to implement as a quirk.
Regards,
Lucas
> > Signed-off-by: Stefan Agner
> > > > Reviewed-by: Lucas Stach
> > ---
> > Changes in v3:
> > - Rebase on pci/dwc
> > Changes in v4:
> > - Rebase on pci/dwc
> > Changes in v5:
> > - Rebased ontop of pci/dwc
> > - Use DBI length of 0x200
> >
> > drivers/pci/controller/dwc/pci-imx6.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index c1d434ba3642..1ef7be1232f3 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -55,6 +55,7 @@ enum imx6_pcie_variants {
> > struct imx6_pcie_drvdata {
> > > > enum imx6_pcie_variants variant;
> > > > u32 flags;
> > > > + int dbi_length;
> > };
> >
> > struct imx6_pcie {
> > @@ -1087,6 +1088,8 @@ static int imx6_pcie_probe(struct platform_device
> > *pdev)
> > > > break;
> > > > }
> >
> > > > + pci->dbi_length = imx6_pcie->drvdata->dbi_length;
> > +
> > > > /* Grab turnoff reset */
> > > > imx6_pcie->turnoff_reset =
> > > > devm_reset_control_get_optional_exclusive(dev, "turnoff");
> > > > if (IS_ERR(imx6_pcie->turnoff_reset)) {
> > @@ -1170,6 +1173,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
> > > > .variant = IMX6Q,
> > > > .flags = IMX6_PCIE_FLAG_IMX6_PHY |
> > > > IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
> > > > + .dbi_length = 0x200,
> > > > },
> > > > [IMX6SX] = {
> > > > .variant = IMX6SX,
> > --
> > 2.20.1
> >
Re: [PATCH v2 2/9] irq/irq_sim: use irq domain
wt., 12 lut 2019 o 09:53 Marc Zyngier napisał(a):
>
> Bartosz,
>
> On Tue, 12 Feb 2019 08:30:32 +,
> Bartosz Golaszewski wrote:
> >
> > pon., 11 lut 2019 o 23:26 Marc Zyngier napisał(a):
> > >
> > > On Tue, 29 Jan 2019 09:44:04 +0100
> > > Bartosz Golaszewski wrote:
> > >
> > > > From: Bartosz Golaszewski
> > > >
> > > > Delegate the offset to virq number mapping to the provided framework
> > > > instead of handling it locally. Use the legacy domain as we want to
> > > > preallocate the irq descriptors.
> > >
> > > Why?
> > >
> > > >
> > > > Signed-off-by: Bartosz Golaszewski
> > > > ---
> > > > include/linux/irq_sim.h | 6 +--
> > > > kernel/irq/irq_sim.c| 94 +
> > > > 2 files changed, 71 insertions(+), 29 deletions(-)
> > > >
> > > > diff --git a/include/linux/irq_sim.h b/include/linux/irq_sim.h
> > > > index eda132c22b57..b96c2f752320 100644
> > > > --- a/include/linux/irq_sim.h
> > > > +++ b/include/linux/irq_sim.h
> > > > @@ -8,6 +8,7 @@
> > > >
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > >
> > > > /*
> > > > @@ -21,16 +22,15 @@ struct irq_sim_work_ctx {
> > > > };
> > > >
> > > > struct irq_sim_irq_ctx {
> > > > - int irqnum;
> > > > boolenabled;
> > > > };
> > > >
> > > > struct irq_sim {
> > > > struct irq_chip chip;
> > > > + struct irq_domain *domain;
> > > > struct irq_sim_work_ctx work_ctx;
> > > > - int irq_base;
> > > > + int virq_base;
> > > > unsigned intirq_count;
> > > > - struct irq_sim_irq_ctx *irqs;
> > > > };
> > > >
> > > > int irq_sim_init(struct irq_sim *sim, unsigned int num_irqs);
> > > > diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c
> > > > index b732e4e2e45b..2bcdbab1bc5a 100644
> > > > --- a/kernel/irq/irq_sim.c
> > > > +++ b/kernel/irq/irq_sim.c
> > > > @@ -44,6 +44,43 @@ static void irq_sim_handle_irq(struct irq_work *work)
> > > > }
> > > > }
> > > >
> > > > +static int irq_sim_domain_map(struct irq_domain *domain,
> > > > + unsigned int virq, irq_hw_number_t hw)
> > > > +{
> > > > + struct irq_sim *sim = domain->host_data;
> > > > + struct irq_sim_irq_ctx *ctx;
> > > > +
> > > > + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> > > > + if (!ctx)
> > > > + return -ENOMEM;
> > > > +
> > > > + irq_set_chip(virq, &sim->chip);
> > > > + irq_set_chip_data(virq, ctx);
> > > > + irq_set_handler(virq, handle_simple_irq);
> > >
> > > Consider using modern APIs such as irq_domain_set_info().
> > >
> > > > + irq_modify_status(virq, IRQ_NOREQUEST | IRQ_NOAUTOEN,
> > > > IRQ_NOPROBE);
> > >
> > > Where is this requirement coming from?
> > >
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static void irq_sim_domain_free(struct irq_domain *domain,
> > > > + unsigned int virq, unsigned int num_irqs)
> > > > +{
> > > > + struct irq_sim_irq_ctx *ctx;
> > > > + struct irq_data *irq;
> > > > + int i;
> > > > +
> > > > + for (i = 0; i < num_irqs; i++) {
> > > > + irq = irq_domain_get_irq_data(domain, virq + i);
> > > > + ctx = irq_data_get_irq_chip_data(irq);
> > > > + kfree(ctx);
> > > > + }
> > > > +}
> > > > +
> > > > +static const struct irq_domain_ops irq_sim_domain_ops = {
> > > > + .map = irq_sim_domain_map,
> > > > + .free = irq_sim_domain_free,
> > >
> > > The intended use of the v2 API is to have alloc and free as a pair, and
> > > no map. So please choose which version of the API you're using here.
> > > The safest bet would be to move what you do on map into alloc.
> > >
> > > > +};
> > > > +
> > > > /**
> > > > * irq_sim_init - Initialize the interrupt simulator: allocate a range
> > > > of
> > > > *dummy interrupts.
> > > > @@ -56,16 +93,15 @@ static void irq_sim_handle_irq(struct irq_work
> > > > *work)
> > > > */
> > > > int irq_sim_init(struct irq_sim *sim, unsigned int num_irqs)
> > > > {
> > > > - int i;
> > > > -
> > > > - sim->irqs = kmalloc_array(num_irqs, sizeof(*sim->irqs),
> > > > GFP_KERNEL);
> > > > - if (!sim->irqs)
> > > > + sim->virq_base = irq_alloc_descs(-1, 0, num_irqs, 0);
> > > > + if (sim->virq_base < 0)
> > > > + return sim->virq_base;
> > > > +
> > > > + sim->domain = irq_domain_add_legacy(NULL, num_irqs,
> > > > sim->virq_base,
> > > > + 0, &irq_sim_domain_ops, sim);
> > >
> > > Why do you need a legacy domain? As far as I can tell, this is new
> > > code, hence it has no legacy.
> > >
> > > > + if (!sim->domain) {
> > > > + irq_free_descs(sim->virq_base, num_irqs);
> > > > return -ENOMEM;
> > > > -
> > > > - sim->irq_base = irq_alloc_descs(-1, 0, num_irqs, 0);
> > > > - if (sim-
Re: [PATCH 4.9 034/137] ARM: mmp/mmp2: dt: enable the clock
On Mon, Feb 11, 2019 at 09:51:25PM +0100, Pavel Machek wrote: > Hi! > > > 4.9-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > [ Upstream commit f36797ee43802b367e59f0f9a9805304a4ff0c98 ] > > > > The device-tree booted MMP2 needs to enable the timer clock, otherwise > > it would stop ticking when the boot finishes. > > > > It can also use the clock rate from the clk, the non-DT boards need to > > keep using the hardcoded rates. > > > > Signed-off-by: Lubomir Rintel > > Acked-by: Pavel Machek > > Signed-off-by: Olof Johansson > > Signed-off-by: Sasha Levin > > While I agree this is good idea for mainline (thus my ack), I don't > think it is suitable for stable, as older kernels will not run on OLPC > in useful way, anyway. > > Not-acked-for-stable-by: Pavel Machek > > So I don't think this and ARM: dts: mmp2: fix TWSI2 is good idea for > stable kernels. Ok, I'll drop this, and the follow-on patch that fixed this one up, from all queues. thanks, greg k-h
Re: [PATCH 1/2] dt-bindings: imx6q-pcie: Add "pcie_aux" clock for imx8mq
Am Montag, den 11.02.2019, 17:51 -0800 schrieb Andrey Smirnov:
> Add a binding for an extra clock required on i.MX8MQ.
>
> Signed-off-by: Andrey Smirnov
> Cc: Bjorn Helgaas
> Cc: Fabio Estevam
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Leonard Crestez
> Cc: "A.s. Dong"
> Cc: Richard Zhu
> Cc: linux-...@nxp.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
Reviewed-by: Lucas Stach
> ---
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> index 920ca93870a8..933d98328e07 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -55,6 +55,10 @@ Additional required properties for imx7d-pcie and
> imx8mq-pcie:
> - "apps"
> - "turnoff"
>
> +Additional required properties for imx8mq-pcie:
> +- clock-names: Must include the following additional entries:
> + - "pcie_aux"
> +
> Example:
>
> pcie@0100 {
Re: [PATCHv13 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
On Tue, Feb 12, 2019 at 9:08 AM Ong, Hean Loong wrote: > On Tue, 2019-02-12 at 08:46 +0100, Daniel Vetter wrote: > > On Tue, Feb 12, 2019 at 10:36:23AM +0800, Hean-Loong, Ong via dri- > > devel wrote: > > > From: Ong, Hean Loong > > > > > > Driver for Intel FPGA Video and Image Processing Suite Frame Buffer > > > II. > > > The driver only supports the Intel Arria10 devkit and its variants. > > > This driver can be either loaded staticlly or in modules. > > > The OF device tree binding is located at: > > > Documentation/devicetree/bindings/display/altr,vip-fb2.txt > > > > > > Signed-off-by: Ong, Hean Loong > > > > It looks like your cover letter and patch 2 didn't make it to the > > list > > somehow. Please check those aren't stuck on your side (list admins > > didn't > > see them yet). > > > That's weird my git send-email says everything was okay > > > > --- > > > drivers/gpu/drm/Kconfig |2 + > > > drivers/gpu/drm/Makefile |1 + > > > drivers/gpu/drm/ivip/Kconfig | 14 ++ > > > drivers/gpu/drm/ivip/Makefile |6 + > > > drivers/gpu/drm/ivip/intel_vip_conn.c | 91 + > > > drivers/gpu/drm/ivip/intel_vip_drv.c | 332 > > > + > > > drivers/gpu/drm/ivip/intel_vip_drv.h | 73 +++ > > > 7 files changed, 519 insertions(+), 0 deletions(-) > > > create mode 100644 drivers/gpu/drm/ivip/Kconfig > > > create mode 100644 drivers/gpu/drm/ivip/Makefile > > > create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c > > > create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.c > > > create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h > > > > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > > > index 4385f00..0251a9f 100644 > > > --- a/drivers/gpu/drm/Kconfig > > > +++ b/drivers/gpu/drm/Kconfig > > > @@ -235,6 +235,8 @@ source "drivers/gpu/drm/nouveau/Kconfig" > > > > > > source "drivers/gpu/drm/i915/Kconfig" > > > > > > +source "drivers/gpu/drm/ivip/Kconfig" > > > + > > > config DRM_VGEM > > > tristate "Virtual GEM provider" > > > depends on DRM > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > > > index ce8d1d3..85a5694 100644 > > > --- a/drivers/gpu/drm/Makefile > > > +++ b/drivers/gpu/drm/Makefile > > > @@ -63,6 +63,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/ > > > obj-$(CONFIG_DRM_MGA) += mga/ > > > obj-$(CONFIG_DRM_I810) += i810/ > > > obj-$(CONFIG_DRM_I915) += i915/ > > > +obj-$(CONFIG_DRM_IVIP) += ivip/ > > > obj-$(CONFIG_DRM_MGAG200) += mgag200/ > > > obj-$(CONFIG_DRM_V3D) += v3d/ > > > obj-$(CONFIG_DRM_VC4) += vc4/ > > > diff --git a/drivers/gpu/drm/ivip/Kconfig > > > b/drivers/gpu/drm/ivip/Kconfig > > > new file mode 100644 > > > index 000..1d08b90 > > > --- /dev/null > > > +++ b/drivers/gpu/drm/ivip/Kconfig > > > @@ -0,0 +1,14 @@ > > > +config DRM_IVIP > > > +tristate "Intel FGPA Video and Image Processing" > > > +depends on DRM && OF > > > +select DRM_GEM_CMA_HELPER > > > +select DRM_KMS_HELPER > > > +select DRM_KMS_FB_HELPER > > > +select DRM_KMS_CMA_HELPER > > > +help > > > + Choose this option if you have an Intel FPGA > > > Arria 10 system > > > + and above with an Intel Display Port IP. This > > > does not support > > > + legacy Intel FPGA Cyclone V display port. > > > Currently only single > > > + frame buffer is supported. Note that ACPI and > > > X_86 architecture > > > + is not supported for Arria10. If M is selected > > > the module will be > > > + called ivip. > > > diff --git a/drivers/gpu/drm/ivip/Makefile > > > b/drivers/gpu/drm/ivip/Makefile > > > new file mode 100644 > > > index 000..8c54e11 > > > --- /dev/null > > > +++ b/drivers/gpu/drm/ivip/Makefile > > > @@ -0,0 +1,6 @@ > > > +# > > > +# Makefile for the drm device driver. This driver provides > > > support for the > > > +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and > > > higher. > > > + > > > +obj-$(CONFIG_DRM_IVIP) += ivip.o > > > +ivip-objs := intel_vip_drv.o intel_vip_conn.o > > > diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c > > > b/drivers/gpu/drm/ivip/intel_vip_conn.c > > > new file mode 100644 > > > index 000..93ce0b3 > > > --- /dev/null > > > +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c > > > @@ -0,0 +1,91 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * Copyright (C) 2019 Intel Corporation. > > > + * > > > + * intel_vip_conn.c -- Intel Video and Image Processing(VIP) > > > + * Frame Buffer II driver > > > + * > > > + * This driver supports the Intel VIP Frame Reader component. > > > + * More info on the hardware can be found in the Intel Video > > > + * and Image Processing Suite User Guide at this address > > > + * http://www.altera.com/literature/ug/ug_vip.pdf. > > > + * > > > + * Authors: > > > + * Walter Goossens > > > + * Thomas Chou > > > + * Chris Rauer
Re: [PATCH 1/2] chardev: fix an overlap misjudgement case in __register_chrdev_region()
On Tue, Feb 12, 2019 at 04:47:38PM +0800, Chengguang Xu wrote: > Current overlap check of minor range cannot correctly > handle a case which is baseminor < existing baseminor && > baseminor + minorct > existing baseminor + minorct. > Fix it and meanwhile do some code cleanups. Ick, don't do a fix and "code cleanups" in the same patch, that makes it almost impossible to see what the "fix" really was. That should be two separate patches, please break this up. thanks, greg k-h
Re: [PATCH 2/2] chardev: showing minor range for chardev in the output of /proc/devices
On Tue, Feb 12, 2019 at 04:47:39PM +0800, Chengguang Xu wrote:
> Currently chardev allows to share major, showing
> major with minor range for chardev will be more
> helpful.
>
> Signed-off-by: Chengguang Xu
> ---
> fs/char_dev.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/char_dev.c b/fs/char_dev.c
> index b25b1da097d5..6f00acdeb308 100644
> --- a/fs/char_dev.c
> +++ b/fs/char_dev.c
> @@ -55,7 +55,9 @@ void chrdev_show(struct seq_file *f, off_t offset)
> mutex_lock(&chrdevs_lock);
> for (cd = chrdevs[major_to_index(offset)]; cd; cd = cd->next) {
> if (cd->major == offset)
> - seq_printf(f, "%3d %s\n", cd->major, cd->name);
> + seq_printf(f, "%3d %s (%u-%u)\n", cd->major, cd->name,
> +cd->baseminor,
> +cd->baseminor + cd->minorct - 1);
You are changing the format of a userspace file, what tools are going to
break when you do this?
thanks,
greg k-h
Re: [PATCH v2 3/3] pwm: core: add consumer device link
Hello Fabrice,
On Tue, Feb 12, 2019 at 09:31:37AM +0100, Fabrice Gasnier wrote:
> On 2/11/19 8:06 PM, Uwe Kleine-König wrote:
> > On Mon, Feb 11, 2019 at 05:12:02PM +0100, Fabrice Gasnier wrote:
> >> @@ -943,6 +950,8 @@ struct pwm_device *devm_of_pwm_get(struct device *dev,
> >> struct device_node *np,
> >>if (!IS_ERR(pwm)) {
> >>*ptr = pwm;
> >>devres_add(dev, ptr);
> >> + device_link_add(dev, pwm->chip->dev,
> >> + DL_FLAG_AUTOREMOVE_CONSUMER);
> >
> > IMHO it's surprising that devm_of_pwm_get() does more than of_pwm_get()
> > + devres stuff. I'd put device_link_add() into of_pwm_get().
>
> Hi Uwe,
>
> I also agree with this. But I think this implies modifying the API for
> of_pwm_get():
> /**
> * of_pwm_get() - request a PWM via the PWM framework
> + * @dev: device for PWM consumer
> * @np: device node to get the PWM from
> * @con_id: consumer name
>
> It seems there aren't much of_pwm_get() users currently.
> Does this look sensible ?
In my eyes this looks sensible, yes.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
RE: [RFC][Patch v8 0/7] KVM: Guest Free Page Hinting
On Tuesday, February 5, 2019 4:19 AM, Nitesh Narayan Lal wrote: > The following patch-set proposes an efficient mechanism for handing freed > memory between the guest and the host. It enables the guests with no page > cache to rapidly free and reclaims memory to and from the host respectively. > > Benefit: > With this patch-series, in our test-case, executed on a single system and > single NUMA node with 15GB memory, we were able to successfully launch > atleast 5 guests when page hinting was enabled and 3 without it. (Detailed > explanation of the test procedure is provided at the bottom). > > Changelog in V8: > In this patch-series, the earlier approach [1] which was used to capture and > scan the pages freed by the guest has been changed. The new approach is > briefly described below: > > The patch-set still leverages the existing arch_free_page() to add this > functionality. It maintains a per CPU array which is used to store the pages > freed by the guest. The maximum number of entries which it can hold is > defined by MAX_FGPT_ENTRIES(1000). When the array is completely filled, it > is scanned and only the pages which are available in the buddy are stored. > This process continues until the array is filled with pages which are part of > the buddy free list. After which it wakes up a kernel per-cpu-thread. > This kernel per-cpu-thread rescans the per-cpu-array for any re-allocation > and if the page is not reallocated and present in the buddy, the kernel > thread attempts to isolate it from the buddy. If it is successfully isolated, > the > page is added to another per-cpu array. Once the entire scanning process is > complete, all the isolated pages are reported to the host through an existing > virtio-balloon driver. Hi Nitesh, Have you guys thought about something like below, which would be simpler: - use bitmaps to record free pages, e.g. xbitmap: https://lkml.org/lkml/2018/1/9/304. The bitmap can be indexed by the guest pfn, and it's globally accessed by all the CPUs; - arch_free_page(): set the bits of the freed pages from the bitmap (no per-CPU array with hardcoded fixed length and no per-cpu scanning thread) - arch_alloc_page(): clear the related bits from the bitmap - expose 2 APIs for the callers: -- unsigned long get_free_page_hints(unsigned long pfn_start, unsigned int nr); This API searches for the next free page chunk (@nr of pages), starting from @pfn_start. Bits of those free pages will be cleared after this function returns. -- void put_free_page_hints(unsigned long pfn_start, unsigned int nr); This API sets the @nr continuous bits starting from pfn_start. Usage example with balloon: 1) host requests to start ballooning; 2) balloon driver get_free_page_hints and report the hints to host via report_vq; 3) host calls madvise(pfn_start, DONTNEED) for each reported chunk of free pages and put back pfn_start to ack_vq; 4) balloon driver receives pfn_start and calls put_free_page_hints(pfn_start) to have the related bits from the bitmap to be set, indicating that those free pages are ready to be allocated. In above 2), get_free_page_hints clears the bits which indicates that those pages are not ready to be used by the guest yet. Why? This is because 3) will unmap the underlying physical pages from EPT. Normally, when guest re-visits those pages, EPT violations and QEMU page faults will get a new host page to set up the related EPT entry. If guest uses that page before the page gets unmapped (i.e. right before step 3), no EPT violation happens and the guest will use the same physical page that will be unmapped and given to other host threads. So we need to make sure that the guest free page is usable only after step 3 finishes. Back to arch_alloc_page(), it needs to check if the allocated pages have "1" set in the bitmap, if that's true, just clear the bits. Otherwise, it means step 2) above has happened and step 4) hasn't been reached. In this case, we can either have arch_alloc_page() busywaiting a bit till 4) is done for that page Or better to have a balloon callback which prioritize 3) and 4) to make this page usable by the guest. Using bitmaps to record free page hints don't need to take the free pages off the buddy list and return them later, which needs to go through the long allocation/free code path. Best, Wei
Re: [PATCH net-next 0/3] Remove getting SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS
Mon, Feb 11, 2019 at 10:17:46PM CET, f.faine...@gmail.com wrote: >Hi all, > >AFAICT there is no code that attempts to get the value of the attribute >SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS while it is used with >switchdev_port_attr_set(). > >This is effectively no doing anything and it can slow down future work >that tries to make modifications in these areas so remove that. > >David, there should be no dependency with previous patch series, but >again, feedback from Ido and Jiri would be welcome in case this was >added for a reason. It was originally used by: switchdev_port_bridge_getlink() removed by: commit 29ab586c3d83f81c435e269cace9a1619afb5bbd Author: Arkadi Sharshevsky Date: Sun Aug 6 16:15:51 2017 +0300 net: switchdev: Remove bridge bypass support from switchdev So these are just leftovers. Let's flush them.
Re: [PATCH net-next 1/3] mlxsw: spectrum_switchdev: Remove getting PORT_BRIDGE_FLAGS
Mon, Feb 11, 2019 at 10:17:47PM CET, f.faine...@gmail.com wrote: >There is no code that will query the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS >attribute remove support for that. > >Signed-off-by: Florian Fainelli Acked-by: Jiri Pirko
Re: [PATCH v2 06/15] clocksource/drivers/timer-milbeaut: Introduce timer for Milbeaut SoCs
On 08/02/2019 13:26, Sugaya Taichi wrote:
> Add timer driver for Milbeaut SoCs series.
>
> The timer has two 32-bit width down counters, one of which is configured
> as a clockevent device and the other is configured as a clock source.
>
> Signed-off-by: Sugaya Taichi
Do want me to take it through my tree?
> ---
> drivers/clocksource/Kconfig | 9 ++
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-milbeaut.c | 161
> +++
> 3 files changed, 171 insertions(+)
> create mode 100644 drivers/clocksource/timer-milbeaut.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index a9e26f6..9101b8f 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -634,4 +634,13 @@ config GX6605S_TIMER
> help
> This option enables support for gx6605s SOC's timer.
>
> +config MILBEAUT_TIMER
> + bool "Milbeaut timer driver" if COMPILE_TEST
> + depends on OF
> + depends on ARM
> + select TIMER_OF
> + select CLKSRC_MMIO
> + help
> + Enables the support for Milbeaut timer driver.
> +
> endmenu
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index cdd210f..6f2543b 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -55,6 +55,7 @@ obj-$(CONFIG_CLKSRC_TI_32K) += timer-ti-32k.o
> obj-$(CONFIG_CLKSRC_NPS) += timer-nps.o
> obj-$(CONFIG_OXNAS_RPS_TIMER)+= timer-oxnas-rps.o
> obj-$(CONFIG_OWL_TIMER) += timer-owl.o
> +obj-$(CONFIG_MILBEAUT_TIMER) += timer-milbeaut.o
> obj-$(CONFIG_SPRD_TIMER) += timer-sprd.o
> obj-$(CONFIG_NPCM7XX_TIMER) += timer-npcm7xx.o
> obj-$(CONFIG_RDA_TIMER) += timer-rda.o
> diff --git a/drivers/clocksource/timer-milbeaut.c
> b/drivers/clocksource/timer-milbeaut.c
> new file mode 100644
> index 000..f2019a8
> --- /dev/null
> +++ b/drivers/clocksource/timer-milbeaut.c
> @@ -0,0 +1,161 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Socionext Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "timer-of.h"
> +
> +#define MLB_TMR_TMCSR_OFS0x0
> +#define MLB_TMR_TMR_OFS 0x4
> +#define MLB_TMR_TMRLR1_OFS 0x8
> +#define MLB_TMR_TMRLR2_OFS 0xc
> +#define MLB_TMR_REGSZPCH 0x10
> +
> +#define MLB_TMR_TMCSR_OUTL BIT(5)
> +#define MLB_TMR_TMCSR_RELD BIT(4)
> +#define MLB_TMR_TMCSR_INTE BIT(3)
> +#define MLB_TMR_TMCSR_UF BIT(2)
> +#define MLB_TMR_TMCSR_CNTE BIT(1)
> +#define MLB_TMR_TMCSR_TRGBIT(0)
> +
> +#define MLB_TMR_TMCSR_CSL_DIV2 0
> +#define MLB_TMR_DIV_CNT 2
> +
> +#define MLB_TMR_SRC_CH (1)
> +#define MLB_TMR_EVT_CH (0)
> +
> +#define MLB_TMR_SRC_CH_OFS (MLB_TMR_REGSZPCH * MLB_TMR_SRC_CH)
> +#define MLB_TMR_EVT_CH_OFS (MLB_TMR_REGSZPCH * MLB_TMR_EVT_CH)
> +
> +#define MLB_TMR_SRC_TMCSR_OFS(MLB_TMR_SRC_CH_OFS + MLB_TMR_TMCSR_OFS)
> +#define MLB_TMR_SRC_TMR_OFS (MLB_TMR_SRC_CH_OFS + MLB_TMR_TMR_OFS)
> +#define MLB_TMR_SRC_TMRLR1_OFS (MLB_TMR_SRC_CH_OFS +
> MLB_TMR_TMRLR1_OFS)
> +#define MLB_TMR_SRC_TMRLR2_OFS (MLB_TMR_SRC_CH_OFS +
> MLB_TMR_TMRLR2_OFS)
> +
> +#define MLB_TMR_EVT_TMCSR_OFS(MLB_TMR_EVT_CH_OFS + MLB_TMR_TMCSR_OFS)
> +#define MLB_TMR_EVT_TMR_OFS (MLB_TMR_EVT_CH_OFS + MLB_TMR_TMR_OFS)
> +#define MLB_TMR_EVT_TMRLR1_OFS (MLB_TMR_EVT_CH_OFS +
> MLB_TMR_TMRLR1_OFS)
> +#define MLB_TMR_EVT_TMRLR2_OFS (MLB_TMR_EVT_CH_OFS +
> MLB_TMR_TMRLR2_OFS)
> +
> +#define MLB_TIMER_RATING 500
> +
> +static irqreturn_t mlb_timer_interrupt(int irq, void *dev_id)
> +{
> + struct clock_event_device *clk = dev_id;
> + struct timer_of *to = to_timer_of(clk);
> + u32 val;
> +
> + val = readl_relaxed(timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS);
> + val &= ~MLB_TMR_TMCSR_UF;
> + writel_relaxed(val, timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS);
> +
> + clk->event_handler(clk);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int mlb_set_state_periodic(struct clock_event_device *clk)
> +{
> + struct timer_of *to = to_timer_of(clk);
> + u32 val = MLB_TMR_TMCSR_CSL_DIV2;
> +
> + writel_relaxed(val, timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS);
> +
> + writel_relaxed(to->of_clk.period, timer_of_base(to) +
> + MLB_TMR_EVT_TMRLR1_OFS);
> + val |= MLB_TMR_TMCSR_RELD | MLB_TMR_TMCSR_CNTE |
> + MLB_TMR_TMCSR_TRG | MLB_TMR_TMCSR_INTE;
> + writel_relaxed(val, timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS);
> + return 0;
> +}
> +
> +static int mlb_set_state_oneshot(struct clock_event_device *clk)
> +{
> + struct timer_of *to = to_timer_of(clk);
> + u32 val = MLB_TMR_TMCSR_CSL_DIV2;
> +
> + writel_relaxed(val, timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS);
> + return 0;
> +}
> +
> +static int mlb_clkevt_next_event(unsigned long event,
> +struct clock_ev
Re: [PATCH net-next 2/3] rocker: Remove getting PORT_BRIDGE_FLAGS
Mon, Feb 11, 2019 at 10:17:48PM CET, f.faine...@gmail.com wrote: >There is no code that attempts to get the >SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute, remove support for that. > >Signed-off-by: Florian Fainelli Acked-by: Jiri Pirko
Re: [PATCH net-next 3/3] staging: fsl-dpaa2: ethsw: Remove getting PORT_BRIDGE_FLAGS
Mon, Feb 11, 2019 at 10:17:49PM CET, f.faine...@gmail.com wrote: >There is no code that tries to get the attribute >SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS, remove support for doing that. > >Signed-off-by: Florian Fainelli Acked-by: Jiri Pirko
Re: [PATCH v2] driver: platform: Support parsing GpioInt 0 in platform_get_irq()
On Mon, Feb 11, 2019 at 11:01:12AM -0800, egran...@chromium.org wrote: > From: Enrico Granata > > ACPI 5 added support for GpioInt resources as a way to provide > information about interrupts mediated via a GPIO controller. > > Several device buses (e.g. SPI, I2C) have support for retrieving > an IRQ specified via this type of resource, and providing it > directly to the driver as an IRQ number. > > This is not currently done for the platform drivers, as platform_get_irq() > does not try to parse GpioInt() resources. This requires drivers to > either have to support only one possible IRQ resource, or to have code > in place to try both as a failsafe. > > While there is a possibility of ambiguity for devices that exposes > multiple IRQs, it is easy and feasible to support the common case > of devices that only expose one IRQ which would be of either type > depending on the underlying system's architecture. > > This commit adds support for parsing a GpioInt resource in order > to fulfill a request for the index 0 IRQ for a platform device. > > Signed-off-by: Enrico Granata Reviewed-by: Mika Westerberg
Re: [PATCH 1/3] clocksource: timer-ti-dm: Fix pwm dmtimer usage of fck reparenting
On 22/01/2019 18:57, Tony Lindgren wrote:
> Commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
> them with ti-sysc") moved some omap4 timers to probe with ti-sysc
> interconnect target module. Turns out this broke pwm-omap-dmtimer
> where we now try to reparent the clock to itself with the following:
>
> omap_dm_timer_of_set_source: failed to set parent
>
> With ti-sysc, we can now configure the clock sources in the dts
> with assigned-clocks and assigned-clock-parents. So we should be able
> to remove omap_dm_timer_of_set_source with clean-up patches later on.
> But for now, let's just fix it first by checking if parent and fck
> are the same and bail out of so.
>
> Fixes: 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
> them with ti-sysc")
> Cc: Bartosz Golaszewski
> Cc: Daniel Lezcano
> Cc: H. Nikolaus Schaller
> Cc: Keerthy
> Cc: Ladislav Michl
> Cc: Pavel Machek
> Cc: Sebastian Reichel
> Cc: Tero Kristo
> Cc: Thierry Reding
> Cc: Thomas Gleixner
> Reported-by: H. Nikolaus Schaller
> Signed-off-by: Tony Lindgren
> ---
Do you want me to take it through my tree (1 et 3)?
> drivers/clocksource/timer-ti-dm.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/clocksource/timer-ti-dm.c
> b/drivers/clocksource/timer-ti-dm.c
> --- a/drivers/clocksource/timer-ti-dm.c
> +++ b/drivers/clocksource/timer-ti-dm.c
> @@ -154,6 +154,10 @@ static int omap_dm_timer_of_set_source(struct
> omap_dm_timer *timer)
> if (IS_ERR(parent))
> return -ENODEV;
>
> + /* Bail out if both clocks point to fck */
> + if (clk_is_match(parent, timer->fclk))
> + return 0;
> +
> ret = clk_set_parent(timer->fclk, parent);
> if (ret < 0)
> pr_err("%s: failed to set parent\n", __func__);
>
--
Facebook |
Twitter |
Re: [PATCH 0/2] Adding DTS to support STMPE811 ADC on Toradex Boards
On Fri, Feb 01, 2019 at 11:36:34AM +0800, Shawn Guo wrote: > On Tue, Jan 22, 2019 at 02:21:33PM +0100, Philippe Schenker wrote: > > Philippe Schenker (2): > > ARM: dts: Add stmpe-adc DT node to Toradex iMX6 modules > > ARM: dts: Add stmpe-adc DT node to Toradex T30 modules > > Applied both, thanks. Sorry, the T30 one shouldn't be applied by me. Dropped from my tree. Shawn
Re: [PATCH v2 3/9] irq/irq_sim: provide irq_sim_fire_type()
On 29/01/2019 08:44, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Provide a more specialized variant of irq_sim_fire() that allows to
> specify the type of the fired interrupt. The type is stored in the
> dummy irq context struct via the set_type callback.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> include/linux/irq_sim.h | 9 -
> kernel/irq/irq_sim.c| 26 ++
> 2 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/irq_sim.h b/include/linux/irq_sim.h
> index b96c2f752320..647a6c8ffb31 100644
> --- a/include/linux/irq_sim.h
> +++ b/include/linux/irq_sim.h
> @@ -23,6 +23,7 @@ struct irq_sim_work_ctx {
>
> struct irq_sim_irq_ctx {
> boolenabled;
> + unsigned inttype;
> };
>
> struct irq_sim {
> @@ -37,7 +38,13 @@ int irq_sim_init(struct irq_sim *sim, unsigned int
> num_irqs);
> int devm_irq_sim_init(struct device *dev, struct irq_sim *sim,
> unsigned int num_irqs);
> void irq_sim_fini(struct irq_sim *sim);
> -void irq_sim_fire(struct irq_sim *sim, unsigned int offset);
> +void irq_sim_fire_type(struct irq_sim *sim,
> +unsigned int offset, unsigned int type);
> int irq_sim_irqnum(struct irq_sim *sim, unsigned int offset);
>
> +static inline void irq_sim_fire(struct irq_sim *sim, unsigned int offset)
> +{
> + irq_sim_fire_type(sim, offset, IRQ_TYPE_DEFAULT);
> +}
> +
> #endif /* _LINUX_IRQ_SIM_H */
> diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c
> index 2bcdbab1bc5a..e3160b5e59b8 100644
> --- a/kernel/irq/irq_sim.c
> +++ b/kernel/irq/irq_sim.c
> @@ -25,6 +25,15 @@ static void irq_sim_irqunmask(struct irq_data *data)
> irq_ctx->enabled = true;
> }
>
> +static int irq_sim_set_type(struct irq_data *data, unsigned int type)
> +{
> + struct irq_sim_irq_ctx *irq_ctx = irq_data_get_irq_chip_data(data);
> +
> + irq_ctx->type = type;
> +
> + return 0;
> +}
> +
> static void irq_sim_handle_irq(struct irq_work *work)
> {
> struct irq_sim_work_ctx *work_ctx;
> @@ -107,6 +116,7 @@ int irq_sim_init(struct irq_sim *sim, unsigned int
> num_irqs)
> sim->chip.name = "irq_sim";
> sim->chip.irq_mask = irq_sim_irqmask;
> sim->chip.irq_unmask = irq_sim_irqunmask;
> + sim->chip.irq_set_type = irq_sim_set_type;
>
> sim->work_ctx.pending = bitmap_zalloc(num_irqs, GFP_KERNEL);
> if (!sim->work_ctx.pending) {
> @@ -192,21 +202,29 @@ irq_sim_get_ctx(struct irq_sim *sim, unsigned int
> offset)
> }
>
> /**
> - * irq_sim_fire - Enqueue an interrupt.
> + * irq_sim_fire_type - Enqueue an interrupt.
> *
> * @sim:The interrupt simulator object.
> * @offset: Offset of the simulated interrupt which should be fired.
> + * @type:Type of the fired interrupt. Must be one of the following:
> + * IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING,
> + * IRQ_TYPE_EDGE_BOTH, IRQ_TYPE_LEVEL_HIGH,
> + * IRQ_TYPE_LEVEL_LOW, IRQ_TYPE_DEFAULT
> */
> -void irq_sim_fire(struct irq_sim *sim, unsigned int offset)
> +void irq_sim_fire_type(struct irq_sim *sim,
> +unsigned int offset, unsigned int type)
> {
> struct irq_sim_irq_ctx *ctx = irq_sim_get_ctx(sim, offset);
>
> - if (ctx->enabled) {
> + /* Only care about relevant flags. */
> + type &= IRQ_TYPE_SENSE_MASK;
> +
> + if (ctx->enabled && (ctx->type & type)) {
I wonder how realistic this is, given that you do not track the release
of a level. In short, mo matter what the type is, you treat everything
as edge.
What is the point of this?
> set_bit(offset, sim->work_ctx.pending);
> irq_work_queue(&sim->work_ctx.work);
> }
> }
> -EXPORT_SYMBOL_GPL(irq_sim_fire);
> +EXPORT_SYMBOL_GPL(irq_sim_fire_type);
>
> /**
> * irq_sim_irqnum - Get the allocated number of a dummy interrupt.
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH v3 2/2] drm/panel: Add driver for Samsung S6E63M0 panel
On 11.02.2019 17:07, Paweł Chmiel wrote: > On poniedziałek, 11 lutego 2019 16:35:19 CET Andrzej Hajda wrote: >> On 02.02.2019 15:27, Paweł Chmiel wrote: >>> This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over >>> spi. It's based on already removed, non dt s6e63m0 driver and >>> panel-samsung-ld9040. It can be found for example in some of Samsung >>> Aries based phones. >>> >>> Signed-off-by: Paweł Chmiel >>> Reviewed-by: Sam Ravnborg >>> --- >>> Changes from v2: >>> - VIDEOMODE_HELPERS is not needed in Kconfig >>> - Added help text to Kconfig >>> - Remove unneeded videomode includes/fields >>> - Add sentinel comment in s6e63m0_of_match struct >>> - Handle errors during registration of backlight device. We shouldn't >>> register panel if we fail to register backlight device >>> - Added Reviewed-by >>> >>> Changes from v1: >>> - Correct order of Kconfig/Makefile entry >>> - Fix SPDX tag, so it matches value of MODULE_LICENSE >>> - Remove inclusion of drmP.h >>> - Fix code formatting >>> - Use DRM_DEV_ERROR/DEBUG >>> - Extract hardcoded values >>> - Remove possibility to change gamma through sysfs, leaving only one >>> gamma table values >>> - Fix reset_gpio handling, so it'll be asserted in power_on and >>> deasserted in power_off. Also do it before turning voltage on. >>> - Disable backlight and enter sleep mode in disable callback. >>> Previously it was done in unprepare >>> - Enable display and backlight in enable callback. Previously it was >>> done in prepare >>> - Hardcode display timings and delays. Previously they were readed >>> from device tree >>> - We're using SPDX, so we don't need to have license body >>> - Use MIPI_DCS_EXIT_SLEEP_MODE and MIPI_DCS_SET_DISPLAY_ON >>> - Rename MAX_GAMMA_LEVEL to NUM_GAMMA_LEVELS >>> - Ommit get_brightness callback >>> - Use backlight_enable/disable API, like it's done in other panel >>> drivers (for example panel-simple) >>> - Make set_brightness called only from backlight api, like it's done >>> in other panel drivers (for example panel-simple). >>> - Reset gpio should be set to GPIOD_OUT_HIGH. It's declared as active >>> low in device tree >>> - Don't call power_off in remove callback >>> --- >>> drivers/gpu/drm/panel/Kconfig | 9 + >>> drivers/gpu/drm/panel/Makefile| 1 + >>> drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 517 ++ >>> 3 files changed, 527 insertions(+) >>> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c >>> >>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig >>> index 3f3537719beb..45e9ab4b7857 100644 >>> --- a/drivers/gpu/drm/panel/Kconfig >>> +++ b/drivers/gpu/drm/panel/Kconfig >>> @@ -158,6 +158,15 @@ config DRM_PANEL_SAMSUNG_S6E63J0X03 >>> depends on BACKLIGHT_CLASS_DEVICE >>> select VIDEOMODE_HELPERS >>> >>> +config DRM_PANEL_SAMSUNG_S6E63M0 >>> + tristate "Samsung S6E63M0 RGB/SPI panel" >>> + depends on OF >>> + depends on SPI >>> + depends on BACKLIGHT_CLASS_DEVICE >>> + help >>> + Say Y here if you want to enable support for Samsung s6e63m0 >>> + AMOLED LCD panel. >>> + >>> config DRM_PANEL_SAMSUNG_S6E8AA0 >>> tristate "Samsung S6E8AA0 DSI video mode panel" >>> depends on OF >>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile >>> index 4396658a7996..4507a2d253ac 100644 >>> --- a/drivers/gpu/drm/panel/Makefile >>> +++ b/drivers/gpu/drm/panel/Makefile >>> @@ -16,6 +16,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += >>> panel-samsung-ld9040.o >>> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) += panel-samsung-s6d16d0.o >>> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o >>> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o >>> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0) += panel-samsung-s6e63m0.o >>> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o >>> obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o >>> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o >>> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c >>> b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c >>> new file mode 100644 >>> index ..4312aa3e4386 >>> --- /dev/null >>> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c >>> @@ -0,0 +1,517 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * S6E63M0 AMOLED LCD drm_panel driver. >>> + * >>> + * Copyright (C) 2019 Paweł Chmiel >>> + * Derived from drivers/gpu/drm/panel-samsung-ld9040.c >>> + * >>> + * Andrzej Hajda >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> + >>> +/* Manufacturer Command Set */ >>> +#define MCS_ELVSS_ON0xb1 >>> +#define MCS_ACL_CTRL0xc0 >>> +#define MCS_DISPLAY_
Re: [PATCH v6 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
On 02/12/2019 10:38 AM, Vignesh R wrote:
> Cadence OSPI controller IP supports Octal IO (x8 IO lines),
> It also has an integrated PHY. IP register layout is very
> similar to existing QSPI IP except for additional bits to support Octal
> and Octal DDR mode. Therefore, extend current driver to support Octal
> mode. Only Octal SDR read (1-1-8)mode is supported for now.
>
> Tested with mt35xu512aba Octal flash on TI's AM654 EVM.
>
> Signed-off-by: Vignesh R
Reviewed-by: Tudor Ambarus
> ---
> v6: Return error when driver data is not found
>
> drivers/mtd/spi-nor/cadence-quadspi.c | 59 +--
> 1 file changed, 47 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
> b/drivers/mtd/spi-nor/cadence-quadspi.c
> index 04cedd3a2bf6..c8b81e0a76cc 100644
> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -44,6 +44,12 @@
> /* Quirks */
> #define CQSPI_NEEDS_WR_DELAY BIT(0)
>
> +/* Capabilities mask */
> +#define CQSPI_BASE_HWCAPS_MASK \
> + (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
> + SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
> + SNOR_HWCAPS_PP)
> +
> struct cqspi_st;
>
> struct cqspi_flash_pdata {
> @@ -93,6 +99,11 @@ struct cqspi_st {
> struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
> };
>
> +struct cqspi_driver_platdata {
> + u32 hwcaps_mask;
> + u8 quirks;
> +};
> +
> /* Operation timeout value */
> #define CQSPI_TIMEOUT_MS 500
> #define CQSPI_READ_TIMEOUT_MS10
> @@ -101,6 +112,7 @@ struct cqspi_st {
> #define CQSPI_INST_TYPE_SINGLE 0
> #define CQSPI_INST_TYPE_DUAL 1
> #define CQSPI_INST_TYPE_QUAD 2
> +#define CQSPI_INST_TYPE_OCTAL3
>
> #define CQSPI_DUMMY_CLKS_PER_BYTE8
> #define CQSPI_DUMMY_BYTES_MAX4
> @@ -911,6 +923,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
> int read)
> case SNOR_PROTO_1_1_4:
> f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
> break;
> + case SNOR_PROTO_1_1_8:
> + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
> + break;
> default:
> return -EINVAL;
> }
> @@ -1213,21 +1228,23 @@ static void cqspi_request_mmap_dma(struct cqspi_st
> *cqspi)
>
> static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
> {
> - const struct spi_nor_hwcaps hwcaps = {
> - .mask = SNOR_HWCAPS_READ |
> - SNOR_HWCAPS_READ_FAST |
> - SNOR_HWCAPS_READ_1_1_2 |
> - SNOR_HWCAPS_READ_1_1_4 |
> - SNOR_HWCAPS_PP,
> - };
> struct platform_device *pdev = cqspi->pdev;
> struct device *dev = &pdev->dev;
> + const struct cqspi_driver_platdata *ddata;
> + struct spi_nor_hwcaps hwcaps;
> struct cqspi_flash_pdata *f_pdata;
> struct spi_nor *nor;
> struct mtd_info *mtd;
> unsigned int cs;
> int i, ret;
>
> + ddata = of_device_get_match_data(dev);
> + if (!ddata) {
> + dev_err(dev, "Couldnt't find driver data\n");
> + return -EINVAL;
> + }
> + hwcaps.mask = ddata->hwcaps_mask;
> +
> /* Get flash device data */
> for_each_available_child_of_node(dev->of_node, np) {
> ret = of_property_read_u32(np, "reg", &cs);
> @@ -1310,7 +1327,7 @@ static int cqspi_probe(struct platform_device *pdev)
> struct cqspi_st *cqspi;
> struct resource *res;
> struct resource *res_ahb;
> - unsigned long data;
> + const struct cqspi_driver_platdata *ddata;
> int ret;
> int irq;
>
> @@ -1377,8 +1394,8 @@ static int cqspi_probe(struct platform_device *pdev)
> }
>
> cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
> - data = (unsigned long)of_device_get_match_data(dev);
> - if (data & CQSPI_NEEDS_WR_DELAY)
> + ddata = of_device_get_match_data(dev);
> + if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
> cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
> cqspi->master_ref_clk_hz);
>
> @@ -1460,14 +1477,32 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
> #define CQSPI_DEV_PM_OPS NULL
> #endif
>
> +static const struct cqspi_driver_platdata cdns_qspi = {
> + .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
> +};
> +
> +static const struct cqspi_driver_platdata k2g_qspi = {
> + .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
> + .quirks = CQSPI_NEEDS_WR_DELAY,
> +};
> +
> +static const struct cqspi_driver_platdata am654_ospi = {
> + .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK | SNOR_HWCAPS_READ_1_1_8,
> + .qu
Re: [PATCH v9 2/3] x86,/proc/pid/status: Add AVX-512 usage elapsed time
On 2019/2/12 16:22, Thomas Gleixner wrote:
> On Tue, 12 Feb 2019, Aubrey Li wrote:
>> diff --git a/arch/x86/include/asm/processor.h
>> b/arch/x86/include/asm/processor.h
>> index d53c54b842da..60ee932070fe 100644
>> --- a/arch/x86/include/asm/processor.h
>> +++ b/arch/x86/include/asm/processor.h
>> @@ -996,5 +996,7 @@ enum l1tf_mitigations {
>> };
>>
>> extern enum l1tf_mitigations l1tf_mitigation;
>> +/* Add support for architecture specific output in /proc/pid/status */
>> +extern void arch_proc_pid_status(struct seq_file *m, struct task_struct
>> *task);
>
> Sigh. This is absolutely the wrong place. The weak function is declared and
> used in fs/proc/... So the prototype wants to be in a header which is
> included from there independent of x86...
Can the prototype be in the architecture header if they want to call the
function?
Like the following? arch_report_meminfo() is used in fs/proc/... as well.
$ find . -name *.h | xargs grep arch_report_meminfo
./arch/s390/include/asm/pgtable.h:void arch_report_meminfo(struct seq_file *m);
./arch/x86/include/asm/pgtable_types.h:extern void arch_report_meminfo(struct
seq_file *m);
./arch/parisc/include/asm/pgtable.h:extern void arch_report_meminfo(struct
seq_file *m);
Thanks,
-Aubrey
Re: [PATCH] clocksource/arm_arch_timer: Store physical timer IRQ number for KVM on VHE
On 24/01/2019 14:46, Christoffer Dall wrote:
> From: Andre Przywara
>
> A host running in VHE mode gets the EL2 physical timer as its time
> source (accessed using the EL1 sysreg accessors, which get re-directed
> to the EL2 sysregs by VHE).
>
> The EL1 physical timer remains unused by the host kernel, allowing us to
> pass that on directly to a KVM guest and saves us from emulating this
> timer for the guest on VHE systems.
>
> Store the EL1 Physical Timer's IRQ number in
> struct arch_timer_kvm_info on VHE systems to allow KVM to use it.
>
> Signed-off-by: Andre Przywara
> Signed-off-by: Marc Zyngier
> Signed-off-by: Christoffer Dall
> ---
> Patches in preparation for nested virtualization on KVM/Arm depend on this
> change, so we would like to merge this via the kvmarm tree or have a stable
> branch including this patch.
>
> Please let us know your preference. Thanks.
Hi Christopher,
sorry for the delay. I'm fine if you want to take it through your tree.
Acked-by: Daniel Lezcano
> drivers/clocksource/arm_arch_timer.c | 11 +--
> include/clocksource/arm_arch_timer.h | 1 +
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 9a7d4dc00b6e..b9243e2328b4 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -1206,6 +1206,13 @@ static enum arch_timer_ppi_nr __init
> arch_timer_select_ppi(void)
> return ARCH_TIMER_PHYS_SECURE_PPI;
> }
>
> +static void __init arch_timer_populate_kvm_info(void)
> +{
> + arch_timer_kvm_info.virtual_irq = arch_timer_ppi[ARCH_TIMER_VIRT_PPI];
> + if (is_kernel_in_hyp_mode())
> + arch_timer_kvm_info.physical_irq =
> arch_timer_ppi[ARCH_TIMER_PHYS_NONSECURE_PPI];
> +}
> +
> static int __init arch_timer_of_init(struct device_node *np)
> {
> int i, ret;
> @@ -1220,7 +1227,7 @@ static int __init arch_timer_of_init(struct device_node
> *np)
> for (i = ARCH_TIMER_PHYS_SECURE_PPI; i < ARCH_TIMER_MAX_TIMER_PPI; i++)
> arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
>
> - arch_timer_kvm_info.virtual_irq = arch_timer_ppi[ARCH_TIMER_VIRT_PPI];
> + arch_timer_populate_kvm_info();
>
> rate = arch_timer_get_cntfrq();
> arch_timer_of_configure_rate(rate, np);
> @@ -1550,7 +1557,7 @@ static int __init arch_timer_acpi_init(struct
> acpi_table_header *table)
> arch_timer_ppi[ARCH_TIMER_HYP_PPI] =
> acpi_gtdt_map_ppi(ARCH_TIMER_HYP_PPI);
>
> - arch_timer_kvm_info.virtual_irq = arch_timer_ppi[ARCH_TIMER_VIRT_PPI];
> + arch_timer_populate_kvm_info();
>
> /*
>* When probing via ACPI, we have no mechanism to override the sysreg
> diff --git a/include/clocksource/arm_arch_timer.h
> b/include/clocksource/arm_arch_timer.h
> index 349e5957c949..702967d996bb 100644
> --- a/include/clocksource/arm_arch_timer.h
> +++ b/include/clocksource/arm_arch_timer.h
> @@ -74,6 +74,7 @@ enum arch_timer_spi_nr {
> struct arch_timer_kvm_info {
> struct timecounter timecounter;
> int virtual_irq;
> + int physical_irq;
> };
>
> struct arch_timer_mem_frame {
>
--
Facebook |
Twitter |
Re: [PATCH v3 3/4] uaccess: Check no rescheduling function is called in unsafe region
On 11/02/2019 13:51, Peter Zijlstra wrote:
> On Mon, Feb 11, 2019 at 02:45:27PM +0100, Ingo Molnar wrote:
>>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>>> index a674c7db..b1bb7e9 100644
>>> --- a/kernel/sched/core.c
>>> +++ b/kernel/sched/core.c
>>> @@ -3289,6 +3289,14 @@ static inline void schedule_debug(struct task_struct
>>> *prev)
>>> __schedule_bug(prev);
>>> preempt_count_set(PREEMPT_DISABLED);
>>> }
>>> +
>>> + if (IS_ENABLED(CONFIG_DEBUG_UACCESS_SLEEP) &&
>>> + unlikely(unsafe_user_region_active())) {
>>> + printk(KERN_ERR "BUG: scheduling while user_access enabled:
>>> %s/%d/0x%08x\n",
>>> + prev->comm, prev->pid, preempt_count());
>>> + dump_stack();
>>> + }
>>> +
>>> rcu_sleep_check();
>>>
>>> profile_hit(SCHED_PROFILING, __builtin_return_address(0));
>>> @@ -6151,6 +6159,20 @@ void ___might_sleep(const char *file, int line, int
>>> preempt_offset)
>>> EXPORT_SYMBOL(___might_sleep);
>>> #endif
>>>
>>> +#ifdef CONFIG_DEBUG_UACCESS_SLEEP
>>> +void __might_resched(const char *file, int line)
>>> +{
>>> + if (!unsafe_user_region_active())
>>> + return;
>>
>> Could you please more clearly explain why you want/need an exception from
>> the __might_resched() debug warning?
So, the scenarios I'm trying to avoid are of the following flavour:
if (user_access_begin(ptr, size)) {
[...]
// Calling a function that might call schedule()
[...]
user_access_end();
}
The thing is, as I understand, not all function that call schedule() are
annotated with might_resched(), and on the other hand, not every time we
call a function that might_resched() will it call schedule().
Now with Peter's remark I think I might have been overzealous.
>
> In specific; how is the addition in schedule_debug() not triggering on
> PREEMPT=y kernels?
>
> If code is preemptible, you can (get) schedule(d). If it is not
> preemptible; you do not need these additional tests.
>
Yes that sounds right, might_resched() only potentially reschedules if
in a suitable context, so best case I issue two warnings, worst case I
actually be warn when the caller took care to disable preemption or
interrupts before calling a might_resched().
I guess I got a bit confused with might_sleep() which is "if you call
this in the wrong context I warn" whereas might_resched() is just "if
you call this in preemptible context, lets resched".
I guess I'll drop the might_resched() part of this patch if that sounds
alright.
Thanks,
--
Julien Thierry
Re: [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
On Fri, 08 Feb 2019, Matti Vaittinen wrote:
> Hello Lee,
>
> On Fri, Feb 08, 2019 at 10:57:43AM +, Lee Jones wrote:
> > >
> > > This is needed by both RTC and WDT drivers as RTC driver must stop the
> > > WDT when it sets RTC. WDT HW is using RTC counter and might trigger
> > > timeout/reset when RTC is set. Options are to dublicate the
> > > enable/disable to both drivers or to export a function or share a
> > > function pointer. I didn't want dublication or dependency between RTC
> > > and WDT drivers. Thus I thought that MFD is best place for this code as
> > > both RTC and WDT require it anyways. Perhaps this should be commented
> > > here?
> >
> > I think an exported function with comments would be better.
>
> So do you mean you would prefer exported function over the pointer from
Yes please. Call-back pointers for non-subsystem level actions are a
bit messy IMHO.
> MFD? I guess I can do it but I would still like to keep the code in the
> MFD as I would rather not introduce dependency from WDT driver to RTC or
> other way around. I can easily think of cases where WDT or RTC drivers
> would be unnecessary and user might want to drop one of them out of
Sounds fine.
> configuration. And I wonder if export actually makes any real
> improvement as we need to share the mutex between RTC and WDT anyways.
They all (parent (MFD), RTC and WDT) have shared data anyway.
> > [...]
> >
> > > > > + irqs[BD70528_INT_GPIO3].type.type_reg_offset = 6;
> > > > > + irqs[BD70528_INT_GPIO3].type.type_rising_val = 0x20;
> > > > > + irqs[BD70528_INT_GPIO3].type.type_falling_val = 0x10;
> > > > > + irqs[BD70528_INT_GPIO3].type.type_level_high_val = 0x40;
> > > > > + irqs[BD70528_INT_GPIO3].type.type_level_low_val = 0x50;
> > > > > + irqs[BD70528_INT_GPIO3].type.types_supported =
> > > > > (IRQ_TYPE_EDGE_BOTH |
> > > > > + IRQ_TYPE_LEVEL_HIGH |
> > > > > IRQ_TYPE_LEVEL_LOW);
> > > >
> > > > Could you please explain:
> > > >
> > > > a) what you're doing here
> > >
> > > Regmap-irq gained support for type-setting. On bd70528 the type setting
> > > makes sense only for GPIO interrupts - so we must not populate type
> > > setting information for the rest of the IRQs. The macro REGMAP_IRQ_REG
> > > is nice and makes the irq struct initialization cleaner. Thus it is used.
> > > It does not allow populating the type information - hence we do it here.
> > >
> > > I can change this if you think some other way would be cleaner?
> >
> > It's pretty fugly. Can the REGMAP_IRQ_REG be expanded upon?
>
> I was thinking of that but for vast majority of REGMAP_IRQ_REG users
> initializing type regs would be just unnecessary burden (giving 6
> zeroes for unsupported fields for each IRQ gets dull quite soon) I
No, I don't mean edit REGMAP_IRQ_REG directly. I'm proposing to
create another, separate MACRO based on REGMAP_IRQ_REG.
> was also thinking of adding another macro to be used in cases where
> we have type setting supported - but macros with 9 parameters won't fit
> on a line and (in my opinion) will not bring much improvement over
> plain assignment.
I think a 2 line MACRO is better than the current imp.
> > > > b) why you don't mass assign them
> > > > - seeing as most of the data is identical.
> > >
> > > Maybe I am a bit slow today - but I don't know how the 'mass assignment'
> > > should be done?
> >
> > Something like (completely untested):
> >
> > unsigned int type_reg_offset_inc = 0;
> > for (i = BD70528_INT_GPIO0; i <= BD70528_INT_GPIO3; i++) {
> > irqs[i].type.type_reg_offset = type_reg_offset_inc;
> > irqs[i].type.type_rising_val = 0x20;
> > irqs[i].type.type_falling_val= 0x10;
> > irqs[i].type.type_level_high_val = 0x40;
> > irqs[i].type.type_level_low_val = 0x50;
> > irqs[i].type.types_supported =
> > (IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW);
> > type_reg_offset_inc += 2;
> > }
>
> Right. I did this this morning =)
>
> > It's still fugly though.
>
> Agree.
>
> > If we can do this via MACROs, it would be better.
>
> I just dont see how to do a nice macro for this. Truth is that there is
> 6 fields to initialize - and the values can't be guessed so each value
> needs to be given. In best case the macro can somewhat shorten the
> assignment (but no way it'd still fit nicely on one row) - in worst
Don't get hung up on MACROS existing on a single line.
> case it just hides the meaning of values we are passing as arguments.
> With raw assignment we at least have some idea what the 0x40 or 0x20 are
> referring to =)
Well I do agree with your last comment.
Maybe doing the following would help with the ugliness (i.e. the shear
number of chars):
unsigned int type_reg_offset_inc = 0;
for (i = BD70528_INT_GPIO0; i <= BD70528_INT_GPIO3; i++) {
*t = irqs[i].type;
t->type_reg_offset = type_reg_offset_inc;
t->type_rising_val = 0x20;
Re: [PATCH v2] uio:remove unneeded variable ret
On Tue, Jan 22, 2019 at 10:33:57PM +0800, Bo Wang wrote: > From: wangbo > > In uio_dmem_genirq_open the variable ret is unneeded,remove it now. > > Signed-off-by: Bo Wang This name does not match up with the "From:" line :( Please fix up and resend. thanks greg k-h
Re: [PATCH 0/2] Adding DTS to support STMPE811 ADC on Toradex Boards
On Tue, 2019-02-12 at 17:09 +0800, Shawn Guo wrote: > On Fri, Feb 01, 2019 at 11:36:34AM +0800, Shawn Guo wrote: > > On Tue, Jan 22, 2019 at 02:21:33PM +0100, Philippe Schenker wrote: > > > Philippe Schenker (2): > > > ARM: dts: Add stmpe-adc DT node to Toradex iMX6 modules > > > ARM: dts: Add stmpe-adc DT node to Toradex T30 modules > > > > Applied both, thanks. > > Sorry, the T30 one shouldn't be applied by me. Dropped from my tree. > > Shawn @Thierry could you then please pull "ARM: dts: Add stmpe-adc DT node to Toradex T30 modules" ? Thanks a lot! Philippe
Re: [PATCH v2] driver: platform: Support parsing GpioInt 0 in platform_get_irq()
On Mon, Feb 11, 2019 at 8:01 PM wrote: > > From: Enrico Granata > > ACPI 5 added support for GpioInt resources as a way to provide > information about interrupts mediated via a GPIO controller. > > Several device buses (e.g. SPI, I2C) have support for retrieving > an IRQ specified via this type of resource, and providing it > directly to the driver as an IRQ number. > > This is not currently done for the platform drivers, as platform_get_irq() > does not try to parse GpioInt() resources. This requires drivers to > either have to support only one possible IRQ resource, or to have code > in place to try both as a failsafe. > > While there is a possibility of ambiguity for devices that exposes > multiple IRQs, it is easy and feasible to support the common case > of devices that only expose one IRQ which would be of either type > depending on the underlying system's architecture. > > This commit adds support for parsing a GpioInt resource in order > to fulfill a request for the index 0 IRQ for a platform device. > > Signed-off-by: Enrico Granata Reviewed-by: Rafael J. Wysocki > --- > Changes in v2: > - only support IRQ index 0 > > drivers/base/platform.c | 15 ++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > index 1c958eb33ef4d..0d3611cd1b3bc 100644 > --- a/drivers/base/platform.c > +++ b/drivers/base/platform.c > @@ -127,7 +127,20 @@ int platform_get_irq(struct platform_device *dev, > unsigned int num) > irqd_set_trigger_type(irqd, r->flags & IORESOURCE_BITS); > } > > - return r ? r->start : -ENXIO; > + if (r) > + return r->start; > + > + /* > +* For the index 0 interrupt, allow falling back to GpioInt > +* resources. While a device could have both Interrupt and GpioInt > +* resources, making this fallback ambiguous, in many common cases > +* the device will only expose one IRQ, and this fallback > +* allows a common code path across either kind of resource. > +*/ > + if (num == 0 && has_acpi_companion(&dev->dev)) > + return acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num); > + > + return -ENXIO; > #endif > } > EXPORT_SYMBOL_GPL(platform_get_irq); > -- > 2.20.1.791.gb4d0f1c61a-goog >
Re: [PATCH v2 3/9] irq/irq_sim: provide irq_sim_fire_type()
wt., 12 lut 2019 o 10:10 Marc Zyngier napisał(a):
>
> On 29/01/2019 08:44, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Provide a more specialized variant of irq_sim_fire() that allows to
> > specify the type of the fired interrupt. The type is stored in the
> > dummy irq context struct via the set_type callback.
> >
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > include/linux/irq_sim.h | 9 -
> > kernel/irq/irq_sim.c| 26 ++
> > 2 files changed, 30 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/irq_sim.h b/include/linux/irq_sim.h
> > index b96c2f752320..647a6c8ffb31 100644
> > --- a/include/linux/irq_sim.h
> > +++ b/include/linux/irq_sim.h
> > @@ -23,6 +23,7 @@ struct irq_sim_work_ctx {
> >
> > struct irq_sim_irq_ctx {
> > boolenabled;
> > + unsigned inttype;
> > };
> >
> > struct irq_sim {
> > @@ -37,7 +38,13 @@ int irq_sim_init(struct irq_sim *sim, unsigned int
> > num_irqs);
> > int devm_irq_sim_init(struct device *dev, struct irq_sim *sim,
> > unsigned int num_irqs);
> > void irq_sim_fini(struct irq_sim *sim);
> > -void irq_sim_fire(struct irq_sim *sim, unsigned int offset);
> > +void irq_sim_fire_type(struct irq_sim *sim,
> > +unsigned int offset, unsigned int type);
> > int irq_sim_irqnum(struct irq_sim *sim, unsigned int offset);
> >
> > +static inline void irq_sim_fire(struct irq_sim *sim, unsigned int offset)
> > +{
> > + irq_sim_fire_type(sim, offset, IRQ_TYPE_DEFAULT);
> > +}
> > +
> > #endif /* _LINUX_IRQ_SIM_H */
> > diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c
> > index 2bcdbab1bc5a..e3160b5e59b8 100644
> > --- a/kernel/irq/irq_sim.c
> > +++ b/kernel/irq/irq_sim.c
> > @@ -25,6 +25,15 @@ static void irq_sim_irqunmask(struct irq_data *data)
> > irq_ctx->enabled = true;
> > }
> >
> > +static int irq_sim_set_type(struct irq_data *data, unsigned int type)
> > +{
> > + struct irq_sim_irq_ctx *irq_ctx = irq_data_get_irq_chip_data(data);
> > +
> > + irq_ctx->type = type;
> > +
> > + return 0;
> > +}
> > +
> > static void irq_sim_handle_irq(struct irq_work *work)
> > {
> > struct irq_sim_work_ctx *work_ctx;
> > @@ -107,6 +116,7 @@ int irq_sim_init(struct irq_sim *sim, unsigned int
> > num_irqs)
> > sim->chip.name = "irq_sim";
> > sim->chip.irq_mask = irq_sim_irqmask;
> > sim->chip.irq_unmask = irq_sim_irqunmask;
> > + sim->chip.irq_set_type = irq_sim_set_type;
> >
> > sim->work_ctx.pending = bitmap_zalloc(num_irqs, GFP_KERNEL);
> > if (!sim->work_ctx.pending) {
> > @@ -192,21 +202,29 @@ irq_sim_get_ctx(struct irq_sim *sim, unsigned int
> > offset)
> > }
> >
> > /**
> > - * irq_sim_fire - Enqueue an interrupt.
> > + * irq_sim_fire_type - Enqueue an interrupt.
> > *
> > * @sim:The interrupt simulator object.
> > * @offset: Offset of the simulated interrupt which should be fired.
> > + * @type:Type of the fired interrupt. Must be one of the following:
> > + * IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING,
> > + * IRQ_TYPE_EDGE_BOTH, IRQ_TYPE_LEVEL_HIGH,
> > + * IRQ_TYPE_LEVEL_LOW, IRQ_TYPE_DEFAULT
> > */
> > -void irq_sim_fire(struct irq_sim *sim, unsigned int offset)
> > +void irq_sim_fire_type(struct irq_sim *sim,
> > +unsigned int offset, unsigned int type)
> > {
> > struct irq_sim_irq_ctx *ctx = irq_sim_get_ctx(sim, offset);
> >
> > - if (ctx->enabled) {
> > + /* Only care about relevant flags. */
> > + type &= IRQ_TYPE_SENSE_MASK;
> > +
> > + if (ctx->enabled && (ctx->type & type)) {
>
> I wonder how realistic this is, given that you do not track the release
> of a level. In short, mo matter what the type is, you treat everything
> as edge.
>
> What is the point of this?
>
When userspace wants to monitor GPIO line interrupts, the GPIO
framework requests a threaded interrupt with IRQF_TRIGGER_FALLING,
IRQF_TRIGGER_RISING or both. The testing module tries to act like real
hardware and so if we pass only one of the *_TRIGGER_* flags, we want
the simulated interrupt of corresponding type to be fired.
Another solution - if you don't like this one - would be to have more
specialized functions: irq_sim_fire_rising() and
irq_sim_fire_falling(). How about that?
Bart
> > set_bit(offset, sim->work_ctx.pending);
> > irq_work_queue(&sim->work_ctx.work);
> > }
> > }
> > -EXPORT_SYMBOL_GPL(irq_sim_fire);
> > +EXPORT_SYMBOL_GPL(irq_sim_fire_type);
> >
> > /**
> > * irq_sim_irqnum - Get the allocated number of a dummy interrupt.
> >
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
Re: [PATCH 5/5] riscv: use for_each_of_cpu_node iterator
On 2/12/19 12:53 AM, Johan Hovold wrote: On Tue, Feb 12, 2019 at 12:47:09AM -0800, Atish Patra wrote: On 2/12/19 12:26 AM, Johan Hovold wrote: On Mon, Feb 11, 2019 at 11:13:39PM -0800, Christoph Hellwig wrote: On Fri, Jan 18, 2019 at 03:03:08PM +0100, Johan Hovold wrote: Use the new for_each_of_cpu_node() helper to iterate over cpu nodes instead of open coding. Note that this will allow matching also on the node name instead of the (for FDT) deprecated device_type property. Signed-off-by: Johan Hovold I think this is going to conflict with the ELF caps changes from Atish. Maybe the riscv_fill_hwcap hunk should be included in his patch? Since that patch had some issues (e.g. the node reference underflow) it may be better to rebase it on top of this series. The changes are otherwise distinct after all. I have fixed the node reference underflow issue and made some more changes based on comments. Some other patches(1,3,4,5) in this series may conflict with my series as well. I can rebase my series on top of yours and send it as one series if that's okay with you and Palmer. No need for you to resend these patches as they are reviewed any ready to be merged. Just rebase your series and mention the dependency in the cover letter as I did with Andreas's patch which this series depended on. Sure. I will do that. Regards, Atish Thanks, Johan
Re: [PULL] topic/component-typed
On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote: > Hi all, > > Here's the typed component topic branch. > > drm-intel maintainers: Please pull, I need this for the mei hdcp work from > Ram. > > drm-misc maintainers: Please pull, there's a drm doc patch follow-up > that I want to stuff into drm-misc-next. > > Greg: The drm side missed our feature cutoff, so will only land in 5.2. > Probably good if you pull this into drivers-core so it lands a bit > quicker. You&Arnd will also get a topic pull later on with the MEI bits > for char-misc tree, which needs to be based on top of this tree here. > > Takashi: Since the drm side only lands in 5.2 might be good if you > pull this in too to avoid conflicts. > > Cheers, Daniel Pulled into drm-misc, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v3] [media] v4l: add I / P frame min max QP definitions
Got it, I'll submit another patch after your patch merged.
Thanks,
Fish
Hans Verkuil 於 2019年2月8日 週五 下午5:58寫道：
>
> On 1/30/19 10:11 AM, Fish Lin wrote:
> > Add following V4L2 QP parameters for H.264:
> > * V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP
> > * V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP
> > * V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP
> > * V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP
> >
> > These controls will limit QP range for intra and inter frame,
> > provide more manual control to improve video encode quality.
> >
> > Signed-off-by: Fish Lin
> > ---
> > Changelog since v2:
> > - Add interaction with V4L2_CID_MPEG_VIDEO_H264_MIN/MAX_QP
> > description in the document.
> >
> > Changelog since v1:
> > - Add description in document.
> >
> > .../media/uapi/v4l/extended-controls.rst | 24 +++
> > drivers/media/v4l2-core/v4l2-ctrls.c | 4
> > include/uapi/linux/v4l2-controls.h| 6 +
> > 3 files changed, 34 insertions(+)
> >
> > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst
> > b/Documentation/media/uapi/v4l/extended-controls.rst
> > index 286a2dd7ec36..402e41eb24ee 100644
> > --- a/Documentation/media/uapi/v4l/extended-controls.rst
> > +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> > @@ -1214,6 +1214,30 @@ enum v4l2_mpeg_video_h264_entropy_mode -
> > Quantization parameter for an B frame for H264. Valid range: from 0
> > to 51.
> >
> > +``V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP (integer)``
> > +Minimum quantization parameter for H264 I frame, to limit I frame
> > +quality in a range. Valid range: from 0 to 51. If
> > +V4L2_CID_MPEG_VIDEO_H264_MIN_QP is set, the quantization parameter
>
> is set -> is also set
>
> > +should be chosen to meet both of the requirement.
>
> both of the requirement -> both requirements
>
> Ditto for the other three controls below.
>
> However, you might want to wait a little bit since I have this patch pending:
>
> https://patchwork.linuxtv.org/patch/54388/
>
> which will require a rebase of your patch anyway.
>
> Regards,
>
> Hans
>
> > +
> > +``V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP (integer)``
> > +Maximum quantization parameter for H264 I frame, to limit I frame
> > +quality in a range. Valid range: from 0 to 51. If
> > +V4L2_CID_MPEG_VIDEO_H264_MAX_QP is set, the quantization parameter
> > +should be chosen to meet both of the requirement.
> > +
> > +``V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP (integer)``
> > +Minimum quantization parameter for H264 P frame, to limit P frame
> > +quality in a range. Valid range: from 0 to 51. If
> > +V4L2_CID_MPEG_VIDEO_H264_MIN_QP is set, the quantization parameter
> > +should be chosen to meet both of the requirement.
> > +
> > +``V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP (integer)``
> > +Maximum quantization parameter for H264 P frame, to limit P frame
> > +quality in a range. Valid range: from 0 to 51. If
> > +V4L2_CID_MPEG_VIDEO_H264_MAX_QP is set, the quantization parameter
> > +should be chosen to meet both of the requirement.
> > +
> > ``V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP (integer)``
> > Quantization parameter for an I frame for MPEG4. Valid range: from 1
> > to 31.
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 5e3806feb5d7..e2b0af0d2283 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -825,6 +825,10 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER:return "H264
> > Number of HC Layers";
> > case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP:
> > return "H264
> > Set QP Value for HC Layers";
> > + case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP: return "H264
> > I-Frame Minimum QP Value";
> > + case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP: return "H264
> > I-Frame Maximum QP Value";
> > + case V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP: return "H264
> > P-Frame Minimum QP Value";
> > + case V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP: return "H264
> > P-Frame Maximum QP Value";
> > case V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP: return "MPEG4
> > I-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP: return "MPEG4
> > P-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_MPEG4_B_FRAME_QP: return "MPEG4
> > B-Frame QP Value";
> > diff --git a/include/uapi/linux/v4l2-controls.h
> > b/include/uapi/linux/v4l2-controls.h
> > index 3dcfc6148f99..9519673e6437 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -533,6 +533,12 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type {
> > };
> > #define V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAY
Re: [RFC][Patch v8 0/7] KVM: Guest Free Page Hinting
On 12.02.19 10:03, Wang, Wei W wrote: > On Tuesday, February 5, 2019 4:19 AM, Nitesh Narayan Lal wrote: >> The following patch-set proposes an efficient mechanism for handing freed >> memory between the guest and the host. It enables the guests with no page >> cache to rapidly free and reclaims memory to and from the host respectively. >> >> Benefit: >> With this patch-series, in our test-case, executed on a single system and >> single NUMA node with 15GB memory, we were able to successfully launch >> atleast 5 guests when page hinting was enabled and 3 without it. (Detailed >> explanation of the test procedure is provided at the bottom). >> >> Changelog in V8: >> In this patch-series, the earlier approach [1] which was used to capture and >> scan the pages freed by the guest has been changed. The new approach is >> briefly described below: >> >> The patch-set still leverages the existing arch_free_page() to add this >> functionality. It maintains a per CPU array which is used to store the pages >> freed by the guest. The maximum number of entries which it can hold is >> defined by MAX_FGPT_ENTRIES(1000). When the array is completely filled, it >> is scanned and only the pages which are available in the buddy are stored. >> This process continues until the array is filled with pages which are part of >> the buddy free list. After which it wakes up a kernel per-cpu-thread. >> This kernel per-cpu-thread rescans the per-cpu-array for any re-allocation >> and if the page is not reallocated and present in the buddy, the kernel >> thread attempts to isolate it from the buddy. If it is successfully >> isolated, the >> page is added to another per-cpu array. Once the entire scanning process is >> complete, all the isolated pages are reported to the host through an existing >> virtio-balloon driver. > > Hi Nitesh, > > Have you guys thought about something like below, which would be simpler: Responding because I'm the first to stumble over this mail, hah! :) > > - use bitmaps to record free pages, e.g. xbitmap: > https://lkml.org/lkml/2018/1/9/304. > The bitmap can be indexed by the guest pfn, and it's globally accessed by > all the CPUs; Global means all VCPUs will be competing potentially for a single lock when freeing/allocating a page, no? What if you have 64VCPUs allocating/freeing memory like crazy? (I assume some kind of locking is required even if the bitmap would be atomic. Also, doesn't xbitmap mean that we eventually have to allocate memory at places where we don't want to - e.g. from arch_free_page ?) That's the big benefit of taking the pages of the buddy free list. Other VCPUs won't stumble over them, waiting for them to get freed in the hypervisor. > - arch_free_page(): set the bits of the freed pages from the bitmap > (no per-CPU array with hardcoded fixed length and no per-cpu scanning thread) > - arch_alloc_page(): clear the related bits from the bitmap > - expose 2 APIs for the callers: > -- unsigned long get_free_page_hints(unsigned long pfn_start, unsigned int > nr); > This API searches for the next free page chunk (@nr of pages), starting > from @pfn_start. > Bits of those free pages will be cleared after this function returns. > -- void put_free_page_hints(unsigned long pfn_start, unsigned int nr); > This API sets the @nr continuous bits starting from pfn_start. > > Usage example with balloon: > 1) host requests to start ballooning; > 2) balloon driver get_free_page_hints and report the hints to host via > report_vq; > 3) host calls madvise(pfn_start, DONTNEED) for each reported chunk of free > pages and put back pfn_start to ack_vq; > 4) balloon driver receives pfn_start and calls put_free_page_hints(pfn_start) > to have the related bits from the bitmap to be set, indicating that those > free pages are ready to be allocated. This sounds more like "the host requests to get free pages once in a while" compared to "the host is always informed about free pages". At the time where the host actually has to ask the guest (e.g. because the host is low on memory), it might be to late to wait for guest action. Nitesh uses MADV_FREE here (as far as I recall :) ), to only mark pages as candidates for removal and if the host is low on memory, only scanning the guest page tables is sufficient to free up memory. But both points might just be an implementation detail in the example you describe. > > In above 2), get_free_page_hints clears the bits which indicates that those > pages are not ready to be used by the guest yet. Why? > This is because 3) will unmap the underlying physical pages from EPT. > Normally, when guest re-visits those pages, EPT violations and QEMU page > faults will get a new host page to set up the related EPT entry. If guest > uses that page before the page gets unmapped (i.e. right before step 3), no > EPT violation happens and the guest will use the same physical page that will > be unmapped and given to other host threads. So we n
Re: [PATCH] tty/nozomi: use pci_iomap instead of ioremap_nocache
On Sun, Feb 10, 2019 at 10:45:00PM +0100, Hugo Lefeuvre wrote: > > Use pci_iomap instead of ioremap_nocache in nozomi_card_init(). This > > is a cleaner way to do PCI MMIO (performs additional checks) and > > allows to drop the manual call to pci_resource_start. > > > > pci_iomap relies on ioremap for MMIO and thus has uncached behavior. > > there's still something unclear to me about dc->card_type being used as > size argument to ioremap_nocache(). > > dc->base_addr is the sum of all six io region lengths, not the size of > region 0 which we are trying to map here. Why not using the size of region > 0 instead ? No idea, that might just be how the card is layed out. > If the goal is to map all six regions "at once", I'm not sure how this is > supposed to work. Is there any kind of guarantee that all six regions will > be adjacent? For some reason, it must happen that way, otherwise the driver would not work very well :) > If this is a bug then this patch "somehow" already adresses it since > pci_iomap calls pci_resource_len itself. Otherwise this patch is broken. Let's apply it and see if anyone screams... thanks, greg k-h
[PATCH] sched: Use non-atomic cpumask_{set,clear}_cpu()
The cpumasks updated here are not subject to concurrency and using
atomic bitops for them is pointless and expensive. Use the non-atomic
variants instead.
Suggested-by: Peter Zijlstra
Signed-off-by: Viresh Kumar
---
kernel/sched/fair.c | 6 +++---
kernel/sched/isolation.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8abd1c271499..8213ff6e365d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6097,7 +6097,7 @@ static int select_idle_core(struct task_struct *p, struct
sched_domain *sd, int
bool idle = true;
for_each_cpu(cpu, cpu_smt_mask(core)) {
- cpumask_clear_cpu(cpu, cpus);
+ __cpumask_clear_cpu(cpu, cpus);
if (!available_idle_cpu(cpu))
idle = false;
}
@@ -9105,7 +9105,7 @@ static int load_balance(int this_cpu, struct rq *this_rq,
if ((env.flags & LBF_DST_PINNED) && env.imbalance > 0) {
/* Prevent to re-select dst_cpu via env's CPUs */
- cpumask_clear_cpu(env.dst_cpu, env.cpus);
+ __cpumask_clear_cpu(env.dst_cpu, env.cpus);
env.dst_rq = cpu_rq(env.new_dst_cpu);
env.dst_cpu = env.new_dst_cpu;
@@ -9132,7 +9132,7 @@ static int load_balance(int this_cpu, struct rq *this_rq,
/* All tasks on this runqueue were pinned by CPU affinity */
if (unlikely(env.flags & LBF_ALL_PINNED)) {
- cpumask_clear_cpu(cpu_of(busiest), cpus);
+ __cpumask_clear_cpu(cpu_of(busiest), cpus);
/*
* Attempting to continue load balancing at the current
* sched_domain level only makes sense if there are
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index 81faddba9e20..b02d148e7672 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -80,7 +80,7 @@ static int __init housekeeping_setup(char *str, enum hk_flags
flags)
cpumask_andnot(housekeeping_mask,
cpu_possible_mask, non_housekeeping_mask);
if (cpumask_empty(housekeeping_mask))
- cpumask_set_cpu(smp_processor_id(), housekeeping_mask);
+ __cpumask_set_cpu(smp_processor_id(),
housekeeping_mask);
} else {
cpumask_var_t tmp;
--
2.20.1.321.g9e740568ce00
Re: [PATCH] drm/mediatek: add mipi_tx driver for mt8183
On 12/02/2019 07:19, Jitao Shi wrote: > This patch adds mipi tx driver support for mt8183. > > Mipi_tx of mt8183 is very different to mt8173. > 1.Separate mipi tx setting to mtk_mt8173_mipi_tx.c for mt8173 > 2.Separate mipi tx setting to mtk_mt8183_mipi_tx.c for mt8183 > 3.To reuse the common code, make the common functions in mtk_mipi_tx.c > I hadn't a look on the code, but this commit message already indicates, that you should split this up in several patches. Something like this: 1. patch: carve out common functions to mtk_mipi_tx.c at this point only used by mt8173 2. patch: add support for mt8183 Regards, Matthias > Signed-off-by: Jitao Shi > --- > drivers/gpu/drm/mediatek/Makefile | 2 + > drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 352 ++ > drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 52 +++ > drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c | 290 +++ > drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 168 + > 5 files changed, 549 insertions(+), 315 deletions(-) > create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c > > diff --git a/drivers/gpu/drm/mediatek/Makefile > b/drivers/gpu/drm/mediatek/Makefile > index 82ae49c64221..8067a4be8311 100644 > --- a/drivers/gpu/drm/mediatek/Makefile > +++ b/drivers/gpu/drm/mediatek/Makefile > @@ -12,6 +12,8 @@ mediatek-drm-y := mtk_disp_color.o \ > mtk_drm_plane.o \ > mtk_dsi.o \ > mtk_mipi_tx.o \ > + mtk_mt8173_mipi_tx.o \ > + mtk_mt8183_mipi_tx.o \ > mtk_dpi.o > > obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o > diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c > b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c > index 90e913108950..7591a38ca565 100644 > --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c > +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c > @@ -11,292 +11,45 @@ > * GNU General Public License for more details. > */ > > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#define MIPITX_DSI_CON 0x00 > -#define RG_DSI_LDOCORE_ENBIT(0) > -#define RG_DSI_CKG_LDOOUT_EN BIT(1) > -#define RG_DSI_BCLK_SEL (3 << 2) > -#define RG_DSI_LD_IDX_SEL(7 << 4) > -#define RG_DSI_PHYCLK_SEL(2 << 8) > -#define RG_DSI_DSICLK_FREQ_SEL BIT(10) > -#define RG_DSI_LPTX_CLMP_EN BIT(11) > - > -#define MIPITX_DSI_CLOCK_LANE0x04 > -#define MIPITX_DSI_DATA_LANE00x08 > -#define MIPITX_DSI_DATA_LANE10x0c > -#define MIPITX_DSI_DATA_LANE20x10 > -#define MIPITX_DSI_DATA_LANE30x14 > -#define RG_DSI_LNTx_LDOOUT_ENBIT(0) > -#define RG_DSI_LNTx_CKLANE_ENBIT(1) > -#define RG_DSI_LNTx_LPTX_IPLUS1 BIT(2) > -#define RG_DSI_LNTx_LPTX_IPLUS2 BIT(3) > -#define RG_DSI_LNTx_LPTX_IMINUS BIT(4) > -#define RG_DSI_LNTx_LPCD_IPLUS BIT(5) > -#define RG_DSI_LNTx_LPCD_IMINUS BIT(6) > -#define RG_DSI_LNTx_RT_CODE (0xf << 8) > - > -#define MIPITX_DSI_TOP_CON 0x40 > -#define RG_DSI_LNT_INTR_EN BIT(0) > -#define RG_DSI_LNT_HS_BIAS_ENBIT(1) > -#define RG_DSI_LNT_IMP_CAL_ENBIT(2) > -#define RG_DSI_LNT_TESTMODE_EN BIT(3) > -#define RG_DSI_LNT_IMP_CAL_CODE (0xf << 4) > -#define RG_DSI_LNT_AIO_SEL (7 << 8) > -#define RG_DSI_PAD_TIE_LOW_ENBIT(11) > -#define RG_DSI_DEBUG_INPUT_ENBIT(12) > -#define RG_DSI_PRESERVE (7 << 13) > - > -#define MIPITX_DSI_BG_CON0x44 > -#define RG_DSI_BG_CORE_ENBIT(0) > -#define RG_DSI_BG_CKEN BIT(1) > -#define RG_DSI_BG_DIV(0x3 << 2) > -#define RG_DSI_BG_FAST_CHARGEBIT(4) > -#define RG_DSI_VOUT_MSK (0x3 << 5) > -#define RG_DSI_V12_SEL (7 << 5) > -#define RG_DSI_V10_SEL (7 << 8) > -#define RG_DSI_V072_SEL (7 << 11) > -#define RG_DSI_V04_SEL (7 << 14) > -#define RG_DSI_V032_SEL (7 << 17) > -#define RG_DSI_V02_SEL (7 << 20) > -#define RG_DSI_BG_R1_TRIM(0xf << 24) > -#define RG_DSI_BG_R2_TRIM(0xf << 28) > - > -#define MIPITX_DSI_PLL_CON0 0x50 > -#define RG_DSI_MPPLL_PLL_EN BIT(0) > -#define RG_DSI_MPPLL_DIV_MSK (0x1ff << 1) > -#define RG_DSI_MPPLL_PREDIV (3 << 1) > -#define RG_DSI_MPPLL_TXDIV0 (3 << 3) > -#define RG_DSI_MPPLL_TXDIV1 (3 << 5) > -#define RG_DSI_MPPLL_POSDIV (7 << 7) > -#define RG_DSI_MPPLL_MONVC_ENBIT(10) > -#define RG_DSI_MPPLL_MONREF_
Re: [PATCH] mei: expand minor range when registering chrdev region
On Tue, Feb 12, 2019 at 02:02:52PM +0800, Chengguang Xu wrote:
> Actually, total amount of available minor number
> for a single major is MINORMARK + 1. So expand
> minor range when registering chrdev region.
>
> Signed-off-by: Chengguang Xu
> ---
> drivers/misc/mei/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
> index 87281b3695e6..3df54f1e1a8b 100644
> --- a/drivers/misc/mei/main.c
> +++ b/drivers/misc/mei/main.c
> @@ -869,7 +869,7 @@ static const struct file_operations mei_fops = {
>
> static struct class *mei_class;
> static dev_t mei_devt;
> -#define MEI_MAX_DEVS MINORMASK
> +#define MEI_MAX_DEVS (MINORMASK + 1)
Why is this needed? Have you really run out of that many minor nodes
for this driver?
thanks,
greg k-h
Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
On Mon, Feb 11, 2019 at 07:37:57PM +0530, Jagan Teki wrote: > Hi Maxime, > > On Fri, Feb 1, 2019 at 8:01 PM Maxime Ripard > wrote: > > > > On Tue, Jan 29, 2019 at 11:01:31PM +0530, Jagan Teki wrote: > > > On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard > > > wrote: > > > > > > > > On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote: > > > > > 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. > > > > > > > > It looks like the A64 has the same divider of 4: > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L12 > > > > > > > > I think you're confusing it with the ratio between the pixel clock and > > > > the dotclock, called dsi_div: > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L198 > > > > > > Ahh.. I thought this initially but as far as DSI clock computation is > > > concern, the L12 tcon_div is local variable which is used for edge0 > > > computation in burst mode and not for the dsi clock computation. Since > > > the BSP is unable to get the tcon_div during edge0 computation, they > > > defined it locally I think. > > > > > > You can see the lcd_clk_config() code [2], where we can see DSI clock > > > computation using dsi_div value. > > > > > > Here is dump after the in Line 792 which is after computation[3] > > > [ 10.800737] lcd_clk_config: dsi_div = 6, tcon_div = 4, lcd_div = 1 > > > [ 10.800743] lcd_clk_config: lcd_dclk_freq = 55, dclk_rate = 5500 > > > [ 10.800749] lcd_clk_config: lcd_rate = 33000, pll_rate = 33000 > > > > > > The above dump the lcd_rate 330MHz is computed with panel clock, 55MHz > > > into dsi_div 6. So this can be our actual divider values dclk_min_div, > > > dclk_max_div in sun4i_dclk_round_rate (from > > > drivers/gpu/drm/sun4i/s
