Re: [PATCH] PM / core: fix kerneldoc comment for dpm_watchdog_handler()
On Monday, March 18, 2019 1:16:54 PM CEST Pavel Machek wrote: > > --w3uUfsyyY1Pqa/ej > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri 2019-03-15 23:37:51, Yangtao Li wrote: > > This brings the kernel doc in line with the function signature. > >=20 > > Signed-off-by: Yangtao Li > > Acked-by: Pavel Machek Patch applied, thanks!
Re: [PATCH] PM / core: fix kerneldoc comment for device_pm_wait_for_dev
On Monday, March 18, 2019 1:17:10 PM CEST Pavel Machek wrote: > > --Qf1oXS95uex85X0R > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri 2019-03-15 23:48:41, Yangtao Li wrote: > > Rearrange comment to make the comment style consistent, the previous > > function parameters are described first. > >=20 > > Signed-off-by: Yangtao Li > > Acked-by: Pavel Machek Patch applied, thanks!
Re: [PATCH 2/2] x86/pci: Clean up usage of X86_DEV_DMA_OPS
(+Cc. Patch quoted below. Acked-by from an x86 perspective.)
* Christoph Hellwig wrote:
> We have supported per-device dma_map_ops in generic code for a long
> time, and this symbol just guards the inclusion of the dma_map_ops
> registry used for vmd. Stop enabling it for anything but vmd.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/x86/Kconfig | 3 ---
> drivers/misc/mic/Kconfig | 4 ++--
> drivers/pci/controller/Kconfig | 1 +
> drivers/pci/controller/vmd.c | 7 ---
> 4 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 38c62ff8a3f0..d8e2e6519a61 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -28,7 +28,6 @@ config X86_64
> select MODULES_USE_ELF_RELA
> select NEED_DMA_MAP_STATE
> select SWIOTLB
> - select X86_DEV_DMA_OPS
> select ARCH_HAS_SYSCALL_WRAPPER
>
> #
> @@ -703,7 +702,6 @@ config STA2X11
> bool "STA2X11 Companion Chip Support"
> depends on X86_32_NON_STANDARD && PCI
> select ARCH_HAS_PHYS_TO_DMA
> - select X86_DEV_DMA_OPS
> select SWIOTLB
> select MFD_STA2X11
> select GPIOLIB
> @@ -2877,7 +2875,6 @@ config HAVE_ATOMIC_IOMAP
>
> config X86_DEV_DMA_OPS
> bool
> - depends on X86_64 || STA2X11
>
> config HAVE_GENERIC_GUP
> def_bool y
> diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig
> index 242dcee14689..6736f72cc14a 100644
> --- a/drivers/misc/mic/Kconfig
> +++ b/drivers/misc/mic/Kconfig
> @@ -4,7 +4,7 @@ comment "Intel MIC Bus Driver"
>
> config INTEL_MIC_BUS
> tristate "Intel MIC Bus Driver"
> - depends on 64BIT && PCI && X86 && X86_DEV_DMA_OPS
> + depends on 64BIT && PCI && X86
> help
> This option is selected by any driver which registers a
> device or driver on the MIC Bus, such as CONFIG_INTEL_MIC_HOST,
> @@ -21,7 +21,7 @@ comment "SCIF Bus Driver"
>
> config SCIF_BUS
> tristate "SCIF Bus Driver"
> - depends on 64BIT && PCI && X86 && X86_DEV_DMA_OPS
> + depends on 64BIT && PCI && X86
> help
> This option is selected by any driver which registers a
> device or driver on the SCIF Bus, such as CONFIG_INTEL_MIC_HOST
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index 6012f3059acd..011c57cae4b0 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -267,6 +267,7 @@ config PCIE_TANGO_SMP8759
>
> config VMD
> depends on PCI_MSI && X86_64 && SRCU
> + select X86_DEV_DMA_OPS
> tristate "Intel Volume Management Device Driver"
> ---help---
> Adds support for the Intel Volume Management Device (VMD). VMD is a
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index cf6816b55b5e..999a5509e57e 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -95,10 +95,8 @@ struct vmd_dev {
> struct irq_domain *irq_domain;
> struct pci_bus *bus;
>
> -#ifdef CONFIG_X86_DEV_DMA_OPS
> struct dma_map_ops dma_ops;
> struct dma_domain dma_domain;
> -#endif
> };
>
> static inline struct vmd_dev *vmd_from_bus(struct pci_bus *bus)
> @@ -293,7 +291,6 @@ static struct msi_domain_info vmd_msi_domain_info = {
> .chip = _msi_controller,
> };
>
> -#ifdef CONFIG_X86_DEV_DMA_OPS
> /*
> * VMD replaces the requester ID with its own. DMA mappings for devices in a
> * VMD domain need to be mapped for the VMD, not the device requiring
> @@ -438,10 +435,6 @@ static void vmd_setup_dma_ops(struct vmd_dev *vmd)
> add_dma_domain(domain);
> }
> #undef ASSIGN_VMD_DMA_OPS
> -#else
> -static void vmd_teardown_dma_ops(struct vmd_dev *vmd) {}
> -static void vmd_setup_dma_ops(struct vmd_dev *vmd) {}
> -#endif
>
> static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus *bus,
> unsigned int devfn, int reg, int len)
> --
> 2.20.1
>
Re: [PATCH 2/2] panic: Enable to print out all printk msg in buffer
On (04/10/19 10:02), Petr Mladek wrote: > On Wed 2019-04-10 10:59:26, Sergey Senozhatsky wrote: > > On (04/09/19 16:14), Petr Mladek wrote: > > > We should: > > > > > >+ Flush the latest messages before we replay the log. > > > > Do you mean the pending messages? When we replay the log we also should > > print "header line" and panic-cpu backtrace. So we will print panic-cpu > > oops twice > > console_flush_on_panic() is just the last resort. I believe > that the panic header and backtrace reach the console even > without it in most cases. Explicit flush before reply > would just make it consistent. I would agree. On big systems console_sem is usually unlocked (no fbcon, no DRI, no tty writers, etc.) On desktops, laptops, and embedded device, however, killing the kernel with console_sem locked is not entirely uncommon. > The panic() message is usually the most important one for debugging. > I feel a bit uneasy that we would delay it until full replay that > might get killed from several reasons: > >+ external monitoring system would force reboot > >+ user might realize, e.g. after 20 minutes, that the full > log reply was probably not worth it. > > I understand that people enabling this option would most likely > wait but still. I do not see it as a big deal to repeat > the messages. Well, OK, this sounds reasonable. At the same time this option depends on panic_print, which is probably debugging option anyway and panic_print output can get a bit large and time consuming, so maybe external monitors are not part of the picture when panic_print is used. But no real objections; need to make sure that no one else, except panic, will ever use that new symbol. -ss
Re: [PATCH 09/10] PCI: tegra: Add Tegra194 PCIe support
On Wed, Apr 10, 2019 at 11:40:40AM +0530, Vidya Sagar wrote:
> On 4/9/2019 6:56 PM, Bjorn Helgaas wrote:
> > On Tue, Apr 09, 2019 at 05:00:53PM +0530, Vidya Sagar wrote:
> > > On 4/6/2019 12:28 AM, Bjorn Helgaas wrote:
> > > > On Fri, Apr 05, 2019 at 01:23:51AM +0530, Vidya Sagar wrote:
> > > > > On 4/3/2019 11:06 PM, Bjorn Helgaas wrote:
> > > > > > On Wed, Apr 03, 2019 at 03:13:09PM +0530, Vidya Sagar wrote:
> > > > > > > On 4/3/2019 12:01 AM, Bjorn Helgaas wrote:
> > > > > > > > On Tue, Apr 02, 2019 at 12:47:48PM +0530, Vidya Sagar wrote:
> > > > > > > > > On 3/30/2019 2:22 AM, Bjorn Helgaas wrote:
> > > > > > > > > > On Tue, Mar 26, 2019 at 08:43:26PM +0530, Vidya Sagar wrote:
> > > > > > > > > > > Add support for Synopsys DesignWare core IP based PCIe
> > > > > > > > > > > host controller
> > > > > > > > > > > present in Tegra194 SoC.
> > > > > > > >
> > > > > > > > - Why does this chip require pcie_pme_disable_msi()? The
> > > > > > > > only other
> > > > > > > > use is a DMI quirk for "MSI Wind U-100", added by
> > > > > > > > c39fae1416d5
> > > > > > > > ("PCI PM: Make it possible to force using INTx for PCIe
> > > > > > > > PME
> > > > > > > > signaling").
> > > > > > >
> > > > > > > Because Tegra194 doesn't support raising PME interrupts through
> > > > > > > MSI line.
> >
> > > > There's something wrong here. Either the question of how PME is
> > > > signaled is generic and the spec provides a way for the OS to discover
> > > > that method, or it's part of the device-specific architecture that
> > > > each host bridge driver has to know about its device. If the former,
> > > > we need to make the PCI core smart enough to figure it out. If the
> > > > latter, we need a better interface than this ad hoc
> > > > pcie_pme_disable_msi() thing. But if it is truly the latter, your
> > > > current code is sufficient and we can refine it over time.
> > >
> > > In case of Tegra194, it is the latter case.
> >
> > This isn't a Tegra194 question; it's a question of whether this
> > behavior is covered by the PCIe spec.
> AFAIU the spec and what I heard from Nvidia hardware folks is that spec
> doesn't
> explicitly talk about this and it was a design choice made by Nvidia hardware
> folks to route these interrupts through legacy line instead of MSI line.
>
> >
> > > > What I suspect should happen eventually is the DWC driver should call
> > > > devm_pci_alloc_host_bridge() directly, as all the non-DWC drivers do.
> > > > That would require a little reorganization of the DWC data structures,
> > > > but it would be good to be more consistent.
> > > >
> > > > For now, I think stashing the pointer in pcie_port or dw_pcie would be
> > > > OK. I'm not 100% clear on the difference, but it looks like either
> > > > should be common across all the DWC drivers, which is what we want.
> > >
> > > Since dw_pcie is common for both root port and end point mode structures,
> > > I think it makes sense to keep the pointer in pcie_port as this structure
> > > is specific to root port mode of operation.
> > > I'll make a note to reorganize code to have devm_pci_alloc_host_bridge()
> > > used in the beginning itself to be inline with non-DWC implementations.
> > > But, I'll take it up later (after I'm done with upstreaming current
> > > series)
> >
> > Fair enough.
> >
> > > > > .remove() internally calls pm_runtime_put_sync() API which calls
> > > > > .runtime_suspend(). I made a new patch to add a host_deinit() call
> > > > > which make all these calls. Since host_init() is called from inside
> > > > > .runtime_resume() of this driver, to be in sync, I'm now calling
> > > > > host_deinit() from inside .runtime_suspend() API.
> > > >
> > > > I think this is wrong. pci_stop_root_bus() will detach all the
> > > > drivers from all the devices. We don't want to do that if we're
> > > > merely runtime suspending the host bridge, do we?
> > >
> > > In the current driver, the scenarios in which .runtime_suspend() is called
> > > are
> > > a) during .remove() call and
> >
> > It makes sense that you should call pci_stop_root_bus() during
> > .remove(), i.e., when the host controller driver is being removed,
> > because the PCI bus will no longer be accessible. I think you should
> > call it *directly* from tegra_pcie_dw_remove() because that will match
> > what other drivers do.
> >
> > > b) when there is no endpoint found and controller would be shutdown
> > > In both cases, it is required to stop the root bus and remove all devices,
> > > so, instead of having same call present in respective paths, I kept them
> > > in .runtime_suspend() itself to avoid code duplication.
> >
> > I don't understand this part. We should be able to runtime suspend
> > the host controller without detaching drivers for child devices.
> >
> > If you shutdown the controller completely and detach the *host
> > controller driver*, sure, it makes sense to detach drivers from child
> > devices.
RE: [PATCH 1/1] spi: pxa2xx: add driver enabling message
Hi Jarkko, > > > >> Hi > >> > >> On 4/8/19 6:22 PM, Flavio Suligoi wrote: > >>> Add an info message for the PXA2xx device driver start-up, > >>> with the indication of the transfer mode used (DMA or GPIO). > >>> > >>> This info is useful to individuate the timing when > >>> the module starts. > >>> > >>> Signed-off-by: Flavio Suligoi > >>> --- > >>>drivers/spi/spi-pxa2xx.c | 3 +++ > >>>1 file changed, 3 insertions(+) > >>> > >>> diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c > >>> index f7068cc..d449501 100644 > >>> --- a/drivers/spi/spi-pxa2xx.c > >>> +++ b/drivers/spi/spi-pxa2xx.c > >>> @@ -1826,6 +1826,9 @@ static int pxa2xx_spi_probe(struct > platform_device > >> *pdev) > >>> goto out_error_clock_enabled; > >>> } > >>> > >>> + dev_info(dev, "PXA2xx SPI master controller (%s mode)\n", > >>> + platform_info->enable_dma ? "DMA" : "PIO"); > >>> + > >>> return status; > >>> > >> Would this look better if moved before devm_spi_register_controller() > >> call? > > > > Ok, so in case of SPI registering failure, we have two messages, as: > > > > pxa2xx-spi 80860F0E:00: PXA2xx SPI master controller (DMA mode) > > pxa2xx-spi 80860F0E:00: problem registering spi controller > > > > Do you think that it is more explicative? > > > I think yes and it should not cause confusion since the error message is > the last one. > > I was thinking the successful registration case when DMA is not > available. First there is a warning, followed by a debug message from > SPI core (if CONFIG_SPI_DEBUG) and then info message. > > [9.506895] pxa2xx-spi pxa2xx-spi.13: no DMA channels available, > using PIO > [9.516770] pxa2xx-spi pxa2xx-spi.13: registered master spi2 > [9.518527] pxa2xx-spi pxa2xx-spi.13: PXA2xx SPI master controller > (PIO mode) I have added this message because, using an x86 machine, the message: "pxa2xx-spi pxa2xx-spi.13: registered master spi2" doesn't appear in the kernel messages! > Actually this info message doesn't necessarily tell will the driver end > up using DMA for transfers. See pxa2xx_spi_can_dma() and > pxa2xx_spi_transfer_one(). > > How about replacing "no DMA channels available, using PIO" and have > instead single info message telling is the DMA available or does the > driver use PIO only? Ok, it's a good idea, to avoid to many similar messages. So I can simply remove the: "no DMA channels available, using PIO" and leave only the new: " pxa2xx-spi pxa2xx-spi.13: PXA2xx SPI master controller (PIO mode)" Flavio
Re: [PATCH] x86/tsc: mark tsc reliable on CoffeeLake
On 2019/4/8 8:03 PM, Thomas Gleixner wrote: > On Mon, 8 Apr 2019, You-Sheng Yang wrote: > >> From: You-Sheng Yang >> >> On Intel CoffeeLake it's observed tsc is always marked unstable >> unexpectedly after entering idle state Package C10(PC10), and then clock >> source is switched to hpet. This patch marks tsc as reliable when CPUID >> matches CoffeeLake. > > This lacks a proper analysis: > > 1) Why is it marked unstable Usually the differences between wd_nsec and cs_nsec in function clocksource_watchdog in kernel/time/clocksource.c would be less than a few thousand nanoseconds. However, when CPU is entering deeper idle state, PC10, the hpet clocksource readings starts to give inaccurate values for unknown reason, and the differences to cs_nsec varies from a few hundred nanoseconds to several hundred millisecond, which is larger than WATCHDOG_THRESHOLD (62.5ms) and finally results in tsc being marked unreliable. No HPET overflow is found when this occurs. > 2) Why is it correct to set that for coffeelake So far this strange behaviour is only found on coffeelake. Besides this, no much I can tell actually. This could be probably wrong, but may serve as a start to bring up some more discussion/investigation to solve the problem. I would be more than willing to help verifying further appropriate fixes. Thank you. You-Sheng Yang
[PATCH] ASoC: stm32: sai: fix master clock management
When master clock is used, master clock rate is set exclusively.
Parent clocks of master clock cannot be changed after a call to
clk_set_rate_exclusive(). So the parent clock of SAI kernel clock
must be set before.
Ensure also that exclusive rate operations are balanced
in STM32 SAI driver.
Signed-off-by: Olivier Moysan
---
sound/soc/stm/stm32_sai_sub.c | 64 +++
1 file changed, 47 insertions(+), 17 deletions(-)
diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm/stm32_sai_sub.c
index 3dd54bc54fa1..77aa38183955 100644
--- a/sound/soc/stm/stm32_sai_sub.c
+++ b/sound/soc/stm/stm32_sai_sub.c
@@ -70,6 +70,7 @@
#define SAI_IEC60958_STATUS_BYTES 24
#define SAI_MCLK_NAME_LEN 32
+#define SAI_RATE_11K 11025
/**
* struct stm32_sai_sub_data - private data of SAI sub block (block A or B)
@@ -311,6 +312,25 @@ static int stm32_sai_set_clk_div(struct stm32_sai_sub_data
*sai,
return ret;
}
+static int stm32_sai_set_parent_clock(struct stm32_sai_sub_data *sai,
+ unsigned int rate)
+{
+ struct platform_device *pdev = sai->pdev;
+ struct clk *parent_clk = sai->pdata->clk_x8k;
+ int ret;
+
+ if (!(rate % SAI_RATE_11K))
+ parent_clk = sai->pdata->clk_x11k;
+
+ ret = clk_set_parent(sai->sai_ck, parent_clk);
+ if (ret)
+ dev_err(>dev, " Error %d setting sai_ck parent clock. %s",
+ ret, ret == -EBUSY ?
+ "Active stream rates conflict\n" : "\n");
+
+ return ret;
+}
+
static long stm32_sai_mclk_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
@@ -492,25 +512,29 @@ static int stm32_sai_set_sysclk(struct snd_soc_dai
*cpu_dai,
struct stm32_sai_sub_data *sai = snd_soc_dai_get_drvdata(cpu_dai);
int ret;
- if (dir == SND_SOC_CLOCK_OUT) {
+ if (dir == SND_SOC_CLOCK_OUT && sai->sai_mclk) {
ret = regmap_update_bits(sai->regmap, STM_SAI_CR1_REGX,
SAI_XCR1_NODIV,
(unsigned int)~SAI_XCR1_NODIV);
if (ret < 0)
return ret;
- dev_dbg(cpu_dai->dev, "SAI MCLK frequency is %uHz\n", freq);
- sai->mclk_rate = freq;
+ /* If master clock is used, set parent clock now */
+ ret = stm32_sai_set_parent_clock(sai, freq);
+ if (ret)
+ return ret;
- if (sai->sai_mclk) {
- ret = clk_set_rate_exclusive(sai->sai_mclk,
-sai->mclk_rate);
- if (ret) {
- dev_err(cpu_dai->dev,
- "Could not set mclk rate\n");
- return ret;
- }
+ ret = clk_set_rate_exclusive(sai->sai_mclk, freq);
+ if (ret) {
+ dev_err(cpu_dai->dev,
+ ret == -EBUSY ?
+ "Active streams have incompatible rates" :
+ "Could not set mclk rate\n");
+ return ret;
}
+
+ dev_dbg(cpu_dai->dev, "SAI MCLK frequency is %uHz\n", freq);
+ sai->mclk_rate = freq;
}
return 0;
@@ -917,11 +941,13 @@ static int stm32_sai_configure_clock(struct snd_soc_dai
*cpu_dai,
int div = 0, cr1 = 0;
int sai_clk_rate, mclk_ratio, den;
unsigned int rate = params_rate(params);
+ int ret;
- if (!(rate % 11025))
- clk_set_parent(sai->sai_ck, sai->pdata->clk_x11k);
- else
- clk_set_parent(sai->sai_ck, sai->pdata->clk_x8k);
+ if (!sai->sai_mclk) {
+ ret = stm32_sai_set_parent_clock(sai, rate);
+ if (ret)
+ return ret;
+ }
sai_clk_rate = clk_get_rate(sai->sai_ck);
if (STM_SAI_IS_F4(sai->pdata)) {
@@ -1080,9 +1106,13 @@ static void stm32_sai_shutdown(struct snd_pcm_substream
*substream,
regmap_update_bits(sai->regmap, STM_SAI_CR1_REGX, SAI_XCR1_NODIV,
SAI_XCR1_NODIV);
- clk_disable_unprepare(sai->sai_ck);
+ /* Release mclk rate only if rate was actually set */
+ if (sai->mclk_rate) {
+ clk_rate_exclusive_put(sai->sai_mclk);
+ sai->mclk_rate = 0;
+ }
- clk_rate_exclusive_put(sai->sai_mclk);
+ clk_disable_unprepare(sai->sai_ck);
spin_lock_irqsave(>irq_lock, flags);
sai->substream = NULL;
--
2.7.4
Re: [PATCH v1 1/4] mm/memory_hotplug: Release memory resource after arch_remove_memory()
On 10.04.19 00:41, Andrew Morton wrote:
> On Tue, 9 Apr 2019 12:01:45 +0200 David Hildenbrand wrote:
>
>> __add_pages() doesn't add the memory resource, so __remove_pages()
>> shouldn't remove it. Let's factor it out. Especially as it is a special
>> case for memory used as system memory, added via add_memory() and
>> friends.
>>
>> We now remove the resource after removing the sections instead of doing
>> it the other way around. I don't think this change is problematic.
>>
>> add_memory()
>> register memory resource
>> arch_add_memory()
>>
>> remove_memory
>> arch_remove_memory()
>> release memory resource
>>
>> While at it, explain why we ignore errors and that it only happeny if
>> we remove memory in a different granularity as we added it.
>
> Seems sane.
>
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -1820,6 +1806,25 @@ void try_offline_node(int nid)
>> }
>> EXPORT_SYMBOL(try_offline_node);
>>
>> +static void __release_memory_resource(u64 start, u64 size)
>> +{
>> +int ret;
>> +
>> +/*
>> + * When removing memory in the same granularity as it was added,
>> + * this function never fails. It might only fail if resources
>> + * have to be adjusted or split. We'll ignore the error, as
>> + * removing of memory cannot fail.
>> + */
>> +ret = release_mem_region_adjustable(_resource, start, size);
>> +if (ret) {
>> +resource_size_t endres = start + size - 1;
>> +
>> +pr_warn("Unable to release resource <%pa-%pa> (%d)\n",
>> +, , ret);
>> +}
>> +}
>
> The types seem confused here. Should `start' and `size' be
> resource_size_t? Or maybe phys_addr_t.
Hmm, right now it has the same prototype as register_memory_resource. I
guess using resource_size_t is the right thing to do.
>
> release_mem_region_adjustable() takes resource_size_t's.
>
> Is %pa the way to print a resource_size_t? I guess it happens to work
> because resource_size_t happens to map onto phys_addr_t, which isn't
> ideal.
Documentation/core-api/printk-formats.rst
"
%pa[p] 0x01234567 or 0x0123456789abcdef
For printing a phys_addr_t type (and its derivatives, such as
resource_size_t) ...
"
Care to fixup both u64 to resource_size_t? Or should I send a patch?
Whatever you prefer.
Thanks!
--
Thanks,
David / dhildenb
Re: [RFC][PATCH 13/16] sched: Add core wide task selection and scheduling.
On Tue, Apr 09, 2019 at 11:09:45AM -0700, Tim Chen wrote: > Now that we have accumulated quite a number of different fixes to your orginal > posted patches. Would you like to post a v2 of the core scheduler with the > fixes? Well, I was promised someome else was going to carry all this, also, while you're all having fun playing with this, I've not yet had answers to the important questions of how L1TF complete we want to be and if all this crud actually matters one way or the other. Also, I still don't see this stuff working for high context switch rate workloads, and that is exactly what some people were aiming for..
Re: [PATCH v1] mfd: intel-lpss: Add Intel Comet Lake PCI IDs
On 4/9/19 6:11 PM, Andy Shevchenko wrote:
Intel Comet Lake has the same LPSS than Intel Cannon Lake.
Add the new IDs to the list of supported devices.
Signed-off-by: Andy Shevchenko
---
drivers/mfd/intel-lpss-pci.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index a67f67c90ec4..50a907f93da9 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -129,6 +129,19 @@ static const struct intel_lpss_platform_info cnl_i2c_info
= {
};
static const struct pci_device_id intel_lpss_pci_ids[] = {
+ /* CML */
+ { PCI_VDEVICE(INTEL, 0x02a8), (kernel_ulong_t)_uart_info },
+ { PCI_VDEVICE(INTEL, 0x02a9), (kernel_ulong_t)_uart_info },
+ { PCI_VDEVICE(INTEL, 0x02aa), (kernel_ulong_t)_info },
+ { PCI_VDEVICE(INTEL, 0x02ab), (kernel_ulong_t)_info },
+ { PCI_VDEVICE(INTEL, 0x02c5), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x02c6), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x02c7), (kernel_ulong_t)_uart_info },
+ { PCI_VDEVICE(INTEL, 0x02e8), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x02e9), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x02ea), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x02eb), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x02fb), (kernel_ulong_t)_info },
/* BXT A-Step */
{ PCI_VDEVICE(INTEL, 0x0aac), (kernel_ulong_t)_i2c_info },
{ PCI_VDEVICE(INTEL, 0x0aae), (kernel_ulong_t)_i2c_info },
Let's hold a bit. I'd like to double check does the I2C controller use
Skylake or Broxton derived input clocks.
--
Jarkko
RE: [PATCH 1/2] dt-bindings: rtc: add battery-low-hw-alarm property
Hi Rob, > On Mon, Apr 8, 2019 at 2:22 AM Flavio Suligoi wrote: > > > > HI, > > > > > On 06/04/2019 01:07:13-0500, Rob Herring wrote: > > > > On Wed, Apr 03, 2019 at 04:52:44PM +0200, Flavio Suligoi wrote: > > > > > Some RTC devices have a battery-low automatic detection circuit. > > > > > The battery-low event is usually reported with: > > > > > > > > > > - a bit change in a RTC status register > > > > > - a hw signaling (generally using an interrupt generation), > changing > > > > > the hw level of a specific pin; > > > > > > > > > > The new property "battery-low-hw-alarm" enable the RTC to generate > the > > > > > hw signaling in case of battery-low event. > > > > > > > > > > Signed-off-by: Flavio Suligoi > > > > > --- > > > > > Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++ > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt > > > b/Documentation/devicetree/bindings/rtc/rtc.txt > > > > > index a97fc6a..f93a44d 100644 > > > > > --- a/Documentation/devicetree/bindings/rtc/rtc.txt > > > > > +++ b/Documentation/devicetree/bindings/rtc/rtc.txt > > > > > @@ -31,6 +31,9 @@ below. > > > > > expressed in femto Farad (fF). > > > > > The default value shall be listed (if > > > optional), > > > > > and likewise all valid values. > > > > > +- battery-low-hw-alarm :Enable the "battery-low" output pin. > This > > > function > > > > > +is available on the following > devices: > > > > > +- pcf2127 - pin used for alarm: INTn > > > > > > > > Boolean? If there's cases where which pin is selectable, then we'd > need > > > > this to take a value. Not sure how likely that is? > > > > > > > > > > Indeed, there is at least the pcf85363 that has two possible pins for > > > that interrupt. How would you select the pin then? a zero based index? > a > > > string? > > I prefer an index. Ok, so we can call this property as: low-voltage-alarm and we can select the pin using a zero-base index, also for future developments. > > > I think the string could be clearer for the final user and would give > > more freedom for future changes. > > For example, we can call this property, instead of "battery-low-alarm" > or > > "low-voltage-alarm", simply: "alarm-pin_1" and then the string argument > > can describe the function used; for example: > > > > alarm-pin_1 = "backup-supply-low-voltage-alarm"; > > alarm-pin_2 = ".."; > > How many pins and functions then? And how does this relate to any > interrupts? If we use index, we don't use strings any more.
Re: [PATCH RESEND 1/1] PCI: Add ATS-disable quirk for AMD Radeon R7 GPUs
[+cc] linux-kernel@, linux-pci@ 10.04.2019 10:26, Nikolai Kostrigin пишет: > Hello! > > 10.04.2019 00:59, Bjorn Helgaas пишет: >> [+cc Alex] >> >> This claims to be a resend, but I don't see a previous posting. > For some reason, unknown to me, my previous letter didn't appear > neither in linux-kernel@, nor in linux-pci@ mailing lists. I'm sorry. Now it's obvious I didn't manage to turn HTML formatting off before. > >> There *was* discussion when the quirk was added two years ago for a >> different device. As part of that, Alex thought only that device >> would be affected and ATS was validated on other GPUs: >> >> >> https://lore.kernel.org/lkml/bn6pr12mb165278346be8a76b1e4412aff7...@bn6pr12mb1652.namprd12.prod.outlook.com/ > I'm aware of that and it was Joerg who pointed me to the above thread > when I asked him for help. > In my case both devices mentioned in quirks are present in a laptop. > Unfortunately I have no hardware with standalone AMD R7 GPU > (0102:6900) to check whether unpatched kernel would fail > the same way with both ATS and IOMMU enabled. > >> On Mon, Apr 08, 2019 at 01:37:25PM +0300, Nikolai Kostrigin wrote: >>> ATS is broken on this hardware (at least for Stoney Ridge >>> based laptop) and causes IOMMU stalls and >>> system failure. Disable ATS on these devices to make them >>> usable again with IOMMU enabled >>> Thanks to Joerg Roedel for help. >>> >>> https://bugzilla.kernel.org/show_bug.cgi?id=194521 >>> >>> Signed-off-by: Nikolai Kostrigin >> Joerg, I'm happy to merge this if you would review or ack it. I don't >> know enough to conclude that this is the root cause It'd be nice to >> have an actual AMD erratum. Maybe it would even have a list of >> affected devices so we could get them all at once so people wouldn't >> have to trip over them one by one. >> >>> --- >>> drivers/pci/quirks.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >>> index 4700d24e5d55..abb2532e16bf 100644 >>> --- a/drivers/pci/quirks.c >>> +++ b/drivers/pci/quirks.c >>> @@ -4876,6 +4876,7 @@ static void quirk_no_ats(struct pci_dev *pdev) >>> >>> /* AMD Stoney platform GPU */ >>> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_no_ats); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x6900, quirk_no_ats); >>> #endif /* CONFIG_PCI_ATS */ >>> >>> /* Freescale PCIe doesn't support MSI in RC mode */ >>> -- >>> 2.21.0 >>> > > -- > Best regards, > Nikolai Kostrigin -- Best regards, Nikolai Kostrigin
Re: [PATCH 2/2] panic: Enable to print out all printk msg in buffer
On Wed 2019-04-10 10:59:26, Sergey Senozhatsky wrote: > On (04/09/19 16:14), Petr Mladek wrote: > > We should: > > > >+ Flush the latest messages before we replay the log. > > Do you mean the pending messages? When we replay the log we also should > print "header line" and panic-cpu backtrace. So we will print panic-cpu > oops twice console_flush_on_panic() is just the last resort. I believe that the panic header and backtrace reach the console even without it in most cases. Explicit flush before reply would just make it consistent. > // from panic-cpu flush_on_panic > [header] > backtrace > [end of header] > > // from console_replay > then all logbuf messages > and then the same header/backtrace one more time > > [header] > backtrace] > [end of backtrace] > > Is there any particular reason to flush pending messages before > we play the buffer? Replaying the logbuf can take some time, so > my guess would be that you want to print panic-cpu backtrace as > soon as possible. Is there something else? The panic() message is usually the most important one for debugging. I feel a bit uneasy that we would delay it until full replay that might get killed from several reasons: + external monitoring system would force reboot + user might realize, e.g. after 20 minutes, that the full log reply was probably not worth it. I understand that people enabling this option would most likely wait but still. I do not see it as a big deal to repeat the messages. Best Regards, Petr
[PATCH 1/2] x86: Remove the unused X86_DMA_REMAP kconfig symbol
Signed-off-by: Christoph Hellwig --- arch/x86/Kconfig | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5ad92419be19..38c62ff8a3f0 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -704,7 +704,6 @@ config STA2X11 depends on X86_32_NON_STANDARD && PCI select ARCH_HAS_PHYS_TO_DMA select X86_DEV_DMA_OPS - select X86_DMA_REMAP select SWIOTLB select MFD_STA2X11 select GPIOLIB @@ -2880,10 +2879,6 @@ config X86_DEV_DMA_OPS bool depends on X86_64 || STA2X11 -config X86_DMA_REMAP - bool - depends on STA2X11 - config HAVE_GENERIC_GUP def_bool y -- 2.20.1
[PATCH 2/2] x86/pci: Clean up usage of X86_DEV_DMA_OPS
We have supported per-device dma_map_ops in generic code for a long
time, and this symbol just guards the inclusion of the dma_map_ops
registry used for vmd. Stop enabling it for anything but vmd.
Signed-off-by: Christoph Hellwig
---
arch/x86/Kconfig | 3 ---
drivers/misc/mic/Kconfig | 4 ++--
drivers/pci/controller/Kconfig | 1 +
drivers/pci/controller/vmd.c | 7 ---
4 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 38c62ff8a3f0..d8e2e6519a61 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -28,7 +28,6 @@ config X86_64
select MODULES_USE_ELF_RELA
select NEED_DMA_MAP_STATE
select SWIOTLB
- select X86_DEV_DMA_OPS
select ARCH_HAS_SYSCALL_WRAPPER
#
@@ -703,7 +702,6 @@ config STA2X11
bool "STA2X11 Companion Chip Support"
depends on X86_32_NON_STANDARD && PCI
select ARCH_HAS_PHYS_TO_DMA
- select X86_DEV_DMA_OPS
select SWIOTLB
select MFD_STA2X11
select GPIOLIB
@@ -2877,7 +2875,6 @@ config HAVE_ATOMIC_IOMAP
config X86_DEV_DMA_OPS
bool
- depends on X86_64 || STA2X11
config HAVE_GENERIC_GUP
def_bool y
diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig
index 242dcee14689..6736f72cc14a 100644
--- a/drivers/misc/mic/Kconfig
+++ b/drivers/misc/mic/Kconfig
@@ -4,7 +4,7 @@ comment "Intel MIC Bus Driver"
config INTEL_MIC_BUS
tristate "Intel MIC Bus Driver"
- depends on 64BIT && PCI && X86 && X86_DEV_DMA_OPS
+ depends on 64BIT && PCI && X86
help
This option is selected by any driver which registers a
device or driver on the MIC Bus, such as CONFIG_INTEL_MIC_HOST,
@@ -21,7 +21,7 @@ comment "SCIF Bus Driver"
config SCIF_BUS
tristate "SCIF Bus Driver"
- depends on 64BIT && PCI && X86 && X86_DEV_DMA_OPS
+ depends on 64BIT && PCI && X86
help
This option is selected by any driver which registers a
device or driver on the SCIF Bus, such as CONFIG_INTEL_MIC_HOST
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 6012f3059acd..011c57cae4b0 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -267,6 +267,7 @@ config PCIE_TANGO_SMP8759
config VMD
depends on PCI_MSI && X86_64 && SRCU
+ select X86_DEV_DMA_OPS
tristate "Intel Volume Management Device Driver"
---help---
Adds support for the Intel Volume Management Device (VMD). VMD is a
diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index cf6816b55b5e..999a5509e57e 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -95,10 +95,8 @@ struct vmd_dev {
struct irq_domain *irq_domain;
struct pci_bus *bus;
-#ifdef CONFIG_X86_DEV_DMA_OPS
struct dma_map_ops dma_ops;
struct dma_domain dma_domain;
-#endif
};
static inline struct vmd_dev *vmd_from_bus(struct pci_bus *bus)
@@ -293,7 +291,6 @@ static struct msi_domain_info vmd_msi_domain_info = {
.chip = _msi_controller,
};
-#ifdef CONFIG_X86_DEV_DMA_OPS
/*
* VMD replaces the requester ID with its own. DMA mappings for devices in a
* VMD domain need to be mapped for the VMD, not the device requiring
@@ -438,10 +435,6 @@ static void vmd_setup_dma_ops(struct vmd_dev *vmd)
add_dma_domain(domain);
}
#undef ASSIGN_VMD_DMA_OPS
-#else
-static void vmd_teardown_dma_ops(struct vmd_dev *vmd) {}
-static void vmd_setup_dma_ops(struct vmd_dev *vmd) {}
-#endif
static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus *bus,
unsigned int devfn, int reg, int len)
--
2.20.1
Re: [PATCH 0/1] mm: Remove the SLAB allocator
On 4/10/19 4:47 AM, Tobin C. Harding wrote: > Recently a 2 year old bug was found in the SLAB allocator that crashes > the kernel. This seems to imply that not that many people are using the > SLAB allocator. AFAIK that bug required CONFIG_DEBUG_SLAB_LEAK, not just SLAB. That seems to imply not that many people are using SLAB when debugging and yeah, SLUB has better debugging support. But I wouldn't dare to make the broader implication :) > Currently we have 3 slab allocators. Two is company three is a crowd - > let's get rid of one. > > - The SLUB allocator has been the default since 2.6.23 Yeah, with a sophisticated reasoning :) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0acd820807680d2ccc4ef3448387fcdbf152c73 > - The SLOB allocator is kinda sexy. Its only 664 LOC, the general >design is outlined in KnR, and there is an optimisation taken from >Knuth - say no more. > > If you are using the SLAB allocator please speak now or forever hold your > peace ... FWIW, our enterprise kernel use it (latest is 4.12 based), and openSUSE kernels as well (with openSUSE Tumbleweed that includes latest kernel.org stables). AFAIK we don't enable SLAB_DEBUG even in general debug kernel flavours as it's just too slow. IIRC last time Mel evaluated switching to SLUB, it wasn't a clear winner, but I'll just CC him for details :) > Testing: > > Build kernel with `make defconfig` (on x86_64 machine) followed by `make > kvmconfig`. Then do the same and manually select SLOB. Boot both > kernels in Qemu. > > > thanks, > Tobin. > > > Tobin C. Harding (1): > mm: Remove SLAB allocator > > include/linux/slab.h | 26 - > kernel/cpu.c |5 - > mm/slab.c| 4493 -- > mm/slab.h| 31 +- > mm/slab_common.c | 20 +- > 5 files changed, 5 insertions(+), 4570 deletions(-) > delete mode 100644 mm/slab.c >
two small DMA-related Kconfig cleanups for x86
Just cleaning up the Kconfig files for some of the changes happening over the last years..
[PATCH v2] Input: uinput: Avoid Object-Already-Free with a global lock
uinput_destroy_device() gets called from two places. In one place, uinput_ioctl_handler() where it is protected under a lock udev->mutex but there is no protection on udev device from freeing inside uinput_release(). This can result in Object-Already-Free case where uinput parent device already got freed while a child being inserted inside it. That result in a double free case for parent while kernfs_put() being done for child in a failure path of adding a node. [ 160.093398] Call trace: [ 160.093417] kernfs_get+0x64/0x88 [ 160.093438] kernfs_new_node+0x94/0xc8 [ 160.093450] kernfs_create_dir_ns+0x44/0xfc [ 160.093463] sysfs_create_dir_ns+0xa8/0x130 [ 160.093479] kobject_add_internal+0x278/0x650 [ 160.093491] kobject_add_varg+0xe0/0x130 [ 160.093502] kobject_add+0x15c/0x1d0 [ 160.093518] device_add+0x2bc/0xde0 [ 160.093533] input_register_device+0x5f4/0xa0c [ 160.093547] uinput_ioctl_handler+0x1184/0x2198 [ 160.093560] uinput_ioctl+0x38/0x48 [ 160.093573] vfs_ioctl+0x7c/0xb4 [ 160.093585] do_vfs_ioctl+0x9ec/0x2350 [ 160.093597] SyS_ioctl+0x6c/0xa4 [ 160.093610] el0_svc_naked+0x34/0x38 [ 160.093621] ---[ end trace bccf0093cda2c538 ]--- [ 160.099041] = [ 160.107459] BUG kernfs_node_cache (Tainted: G S W O ): Object already free [ 160.115235] - [ 160.115235] [ 160.125151] Disabling lock debugging due to kernel taint [ 160.130626] INFO: Allocated in __kernfs_new_node+0x8c/0x3c0 age=11 cpu=2 pid=7098 [ 160.138314] kmem_cache_alloc+0x358/0x388 [ 160.142445] __kernfs_new_node+0x8c/0x3c0 [ 160.146590] kernfs_new_node+0x80/0xc8 [ 160.150462] kernfs_create_dir_ns+0x44/0xfc [ 160.154777] sysfs_create_dir_ns+0xa8/0x130 [ 160.158416] CPU5: update max cpu_capacity 1024 [ 160.159085] kobject_add_internal+0x278/0x650 [ 160.163567] kobject_add_varg+0xe0/0x130 [ 160.167606] kobject_add+0x15c/0x1d0 [ 160.168452] CPU5: update max cpu_capacity 780 [ 160.171287] get_device_parent+0x2d0/0x34c [ 160.175510] device_add+0x240/0xde0 [ 160.178371] CPU6: update max cpu_capacity 916 [ 160.179108] input_register_device+0x5f4/0xa0c [ 160.183686] uinput_ioctl_handler+0x1184/0x2198 [ 160.188346] uinput_ioctl+0x38/0x48 [ 160.191941] vfs_ioctl+0x7c/0xb4 [ 160.195261] do_vfs_ioctl+0x9ec/0x2350 [ 160.199111] SyS_ioctl+0x6c/0xa4 [ 160.202436] INFO: Freed in kernfs_put+0x2c8/0x434 age=14 cpu=0 pid=7096 [ 160.209230] kernfs_put+0x2c8/0x434 [ 160.212825] kobject_del+0x50/0xcc [ 160.216332] cleanup_glue_dir+0x124/0x16c [ 160.220456] device_del+0x55c/0x5c8 [ 160.224047] __input_unregister_device+0x274/0x2a8 [ 160.228974] input_unregister_device+0x90/0xd0 [ 160.233553] uinput_destroy_device+0x15c/0x1dc [ 160.238131] uinput_release+0x44/0x5c [ 160.241898] __fput+0x1f4/0x4e4 [ 160.245127] fput+0x20/0x2c [ 160.248358] task_work_run+0x9c/0x174 [ 160.252127] do_notify_resume+0x104/0x6bc [ 160.256253] work_pending+0x8/0x14 [ 160.259751] INFO: Slab 0xffbf0215ff00 objects=33 used=11 fp=0xffc0857ffd08 flags=0x8101 [ 160.268693] INFO: Object 0xffc0857ffd08 @offset=15624 fp=0xffc0857fefb0 [ 160.268693] [ 160.277721] Redzone ffc0857ffd00: bb bb bb bb bb bb bb bb [ 160.286656] Object ffc0857ffd08: 00 00 00 00 01 00 00 80 58 a2 37 45 c1 ff ff ff X.7E [ 160.296207] Object ffc0857ffd18: ae 21 10 0b 90 ff ff ff 20 fd 7f 85 c0 ff ff ff .!.. ... [ 160.305780] Object ffc0857ffd28: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 160.315342] Object ffc0857ffd38: 00 00 00 00 00 00 00 00 7d a3 25 69 00 00 00 00 }.%i [ 160.324896] Object ffc0857ffd48: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 160.334446] Object ffc0857ffd58: 80 c0 28 47 c1 ff ff ff 00 00 00 00 00 00 00 00 ..(G [ 160.344000] Object ffc0857ffd68: 80 4a ce d1 c0 ff ff ff dc 32 01 00 01 00 00 00 .J...2.. [ 160.353554] Object ffc0857ffd78: 11 00 ed 41 00 00 00 00 00 00 00 00 00 00 00 00 ...A [ 160.363099] Redzone ffc0857ffd88: bb bb bb bb bb bb bb bb [ 160.372032] Padding ffc0857ffee0: 5a 5a 5a 5a 5a 5a 5a 5a [ 160.378299] CPU6: update max cpu_capacity 780 [ 160.380971] CPU: 4 PID: 7098 Comm: syz-executor Tainted: G S B W O 4.14.98+ #1 So, avoid the race by taking a global lock inside uinput_release(). Signed-off-by: Mukesh Ojha Cc: Gaurav Kohli Cc: Peter Hutterer Cc: Martin Kepplinger Cc: "Paul E. McKenney" --- Also, if this looks good we can further use this global lock inside read/write in separate patches and release can happen at any time. Changes from v1->v2: - Mistakenly added udev lock replaced by global lock.
Re: [RFC PATCH v3 3/4] x86: Use HYPERVISOR_CALLBACK_VECTOR for acrn_guest upcall vector
On 2019年04月08日 23:00, Borislav Petkov wrote: You can prefix your subject now like this: x86/acrn: Use ... Thanks for suggestion. It will be updated in next version. On Mon, Apr 08, 2019 at 04:12:10PM +0800, Zhao Yakui wrote: Linux kernel uses the HYPERVISOR_CALLBACK_VECTOR for hypervisor upcall vector. And it is already used for Xen and HyperV. After Acrn hypervisor is detected, it will also use this defined vector to notify kernel. Co-developed-by: Jason Chen CJ Signed-off-by: Jason Chen CJ Signed-off-by: Zhao Yakui --- V1->V2: Remove the unused API definition of acrn_setup_intr_handler and acrn_remove_intr_handler. Adjust the order of header file Add the declaration of acrn_hv_vector_handler and tracing definition of acrn_hv_callback_vector. --- arch/x86/Kconfig | 1 + arch/x86/entry/entry_64.S| 5 + arch/x86/include/asm/acrnhyper.h | 19 +++ arch/x86/kernel/cpu/acrn.c | 22 ++ 4 files changed, 47 insertions(+) create mode 100644 arch/x86/include/asm/acrnhyper.h diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d77d215..ae4d38b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -848,6 +848,7 @@ config JAILHOUSE_GUEST config ACRN_GUEST bool "ACRN Guest support" depends on X86_64 + select X86_HV_CALLBACK_VECTOR help This option allows to run Linux as guest in ACRN hypervisor. Enabling this will allow the kernel to boot in virtualized environment under diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 1f0efdb..d1b8ad3 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -1129,6 +1129,11 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \ hv_stimer0_callback_vector hv_stimer0_vector_handler #endif /* CONFIG_HYPERV */ +#if IS_ENABLED(CONFIG_ACRN_GUEST) +apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \ + acrn_hv_callback_vector acrn_hv_vector_handler +#endif + idtentry debugdo_debug has_error_code=0paranoid=1 shift_ist=DEBUG_STACK idtentry int3 do_int3 has_error_code=0 idtentry stack_segmentdo_stack_segmenthas_error_code=1 diff --git a/arch/x86/include/asm/acrnhyper.h b/arch/x86/include/asm/acrnhyper.h new file mode 100644 index 000..9f9c239 --- /dev/null +++ b/arch/x86/include/asm/acrnhyper.h Simply .../acrn.h I'd say. OK. The simplifed file name(acrn.h) will be used in next version. @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_X86_ACRNHYPER_H +#define _ASM_X86_ACRNHYPER_H + +#include +#include +#include +#include + +#ifdef CONFIG_ACRN_GUEST Why is that ifdef needed? It is used to avoid that one function declaration has no definition when asm/acrnhyper.h is included and ACRN_GUEST is not enabled. +void acrn_hv_callback_vector(void); +#ifdef CONFIG_TRACING +#define trace_acrn_hv_callback_vector acrn_hv_callback_vector +#endif + +void acrn_hv_vector_handler(struct pt_regs *regs); end marker: #endif /* _ASM_X86_ACRNHYPER_H */ It will be added in next version. diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c index 3956567..7a233b5 100644 --- a/arch/x86/kernel/cpu/acrn.c +++ b/arch/x86/kernel/cpu/acrn.c @@ -9,7 +9,11 @@ * */ +#include #include +#include +#include +#include What's the sorting order here? Length or alphabetic? Or none? :) Sorry that I don't consider the oder. The required new header file is appended one by one. Of course linux/ path and asm / are appended separately. Do you have any suggestion about the header order? linux/ path includes still need to come first, of course.
[PATCH] lib/Kconfig.debug: Fix build error without CONFIG_BLOCK
From: YueHaibing
If CONFIG_TEST_KMOD is set to M, while CONFIG_BLOCK is not set,
XFS and BTRFS can not be compiled successly.
Reported-by: Hulk Robot
Fixes: d9c6a72d6fa2 ("kmod: add test driver to stress test the module loader")
Signed-off-by: YueHaibing
---
lib/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2020d76..65ad61b 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1939,6 +1939,7 @@ config TEST_KMOD
tristate "kmod stress tester"
depends on m
depends on NETDEVICES && NET_CORE && INET # for TUN
+ depends on BLOCK
select TEST_LKM
select XFS_FS
select TUN
--
2.7.4
Re: [PATCH 1/1] spi: pxa2xx: add driver enabling message
On 4/9/19 5:11 PM, Flavio Suligoi wrote: Hi Jarkko, Hi On 4/8/19 6:22 PM, Flavio Suligoi wrote: Add an info message for the PXA2xx device driver start-up, with the indication of the transfer mode used (DMA or GPIO). This info is useful to individuate the timing when the module starts. Signed-off-by: Flavio Suligoi --- drivers/spi/spi-pxa2xx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c index f7068cc..d449501 100644 --- a/drivers/spi/spi-pxa2xx.c +++ b/drivers/spi/spi-pxa2xx.c @@ -1826,6 +1826,9 @@ static int pxa2xx_spi_probe(struct platform_device *pdev) goto out_error_clock_enabled; } + dev_info(dev, "PXA2xx SPI master controller (%s mode)\n", +platform_info->enable_dma ? "DMA" : "PIO"); + return status; Would this look better if moved before devm_spi_register_controller() call? Ok, so in case of SPI registering failure, we have two messages, as: pxa2xx-spi 80860F0E:00: PXA2xx SPI master controller (DMA mode) pxa2xx-spi 80860F0E:00: problem registering spi controller Do you think that it is more explicative? I think yes and it should not cause confusion since the error message is the last one. I was thinking the successful registration case when DMA is not available. First there is a warning, followed by a debug message from SPI core (if CONFIG_SPI_DEBUG) and then info message. [9.506895] pxa2xx-spi pxa2xx-spi.13: no DMA channels available, using PIO [9.516770] pxa2xx-spi pxa2xx-spi.13: registered master spi2 [9.518527] pxa2xx-spi pxa2xx-spi.13: PXA2xx SPI master controller (PIO mode) Actually this info message doesn't necessarily tell will the driver end up using DMA for transfers. See pxa2xx_spi_can_dma() and pxa2xx_spi_transfer_one(). How about replacing "no DMA channels available, using PIO" and have instead single info message telling is the DMA available or does the driver use PIO only? -- Jarkko
Re: [PATCH -next v2] acpi/hmat: fix memory leaks in hmat_init()
On Wed, Apr 10, 2019 at 4:15 AM Qian Cai wrote:
>
> The commit 665ac7e92757 ("acpi/hmat: Register processor domain to its
> memory") introduced some memory leaks below due to it fails to release
> the heap memory in an error path, and then those statically-allocated
> __initdata memory which reference them get freed during boot renders
> those heap memory as leaks. Since it is valid to pass NULL to
> acpi_put_table(), it is fine to call it even if acpi_get_table() returns
> an error.
>
> unreferenced object 0xc8ff8008349e9400 (size 128):
> comm "swapper/0", pid 1, jiffies 4294709236 (age 48121.476s)
> hex dump (first 32 bytes):
> 00 d0 9e 34 08 80 ff 84 d8 00 43 11 00 10 ff ff ...4..C.
> 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00
> backtrace:
> [<869d4503>] __kmalloc+0x568/0x600
> [<70fd6afb>] alloc_memory_target+0x50/0xd8
> [] srat_parse_mem_affinity+0x58/0x5c
> [<8bfaef74>] acpi_parse_entries_array+0x1c8/0x2c0
> [<22804877>] acpi_table_parse_entries_array+0x11c/0x138
> [] acpi_table_parse_entries+0x7c/0xac
> [] hmat_init+0x90/0x174
> [<694a86c1>] do_one_initcall+0x2d8/0x5f8
> [<24889da9>] do_initcall_level+0x37c/0x3fc
> [<9be02908>] do_basic_setup+0x38/0x50
> [<37b3ac0a>] kernel_init_freeable+0x194/0x258
> [] kernel_init+0x18/0x334
> [<7b30f423>] ret_from_fork+0x10/0x18
> [<6c7147a8>] 0x
>
Fixes: 665ac7e92757 ("acpi/hmat: Register processor domain to its memory")
> Signed-off-by: Qian Cai
Acked-by: Rafael J. Wysocki
Greg, the patch fixed by this is in your tree, so can you apply this
one too, please?
> ---
>
> v2: goto out_put per Rafael.
>
> drivers/acpi/hmat/hmat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/hmat/hmat.c b/drivers/acpi/hmat/hmat.c
> index b7824a0309f7..69cdb3cea545 100644
> --- a/drivers/acpi/hmat/hmat.c
> +++ b/drivers/acpi/hmat/hmat.c
> @@ -637,7 +637,7 @@ static __init int hmat_init(void)
>
> status = acpi_get_table(ACPI_SIG_HMAT, 0, );
> if (ACPI_FAILURE(status))
> - return 0;
> + goto out_put;
>
> hmat_revision = tbl->revision;
> switch (hmat_revision) {
> --
> 2.17.2 (Apple Git-113)
>
Re: [PATCH 2/2] perf/x86/intel: Add Tremont core PMU support
On Tue, Apr 09, 2019 at 06:10:00PM -0700, kan.li...@linux.intel.com wrote:
> The generic purpose counter 0 and fixed counter 0 have less skid.
> Force :ppp events on generic purpose counter 0.
> Force instruction:ppp always on fixed counter 0.
> +static struct event_constraint *
> +tnt_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
> + struct perf_event *event)
> +{
> + struct event_constraint *c;
> +
> + /*
> + * :ppp means to do reduced skid PEBS,
> + * which is available at PMC0 and fixed counter 0.
> + */
> + if (event->attr.precise_ip == 3) {
> + /* Force instruction:ppp in Fixed counter 0 */
> + if (event->hw.config == X86_CONFIG(.event=0xc0))
> + return _counter0_constraint;
> +
> + return _constraint;
I'm confused, 0xc0 is the architectural 'instructions' event, surely we
can program that on pmc0 too?
Did we want a fixed0_counter0_constraint for that?
> + }
> +
> + c = intel_get_event_constraints(cpuc, idx, event);
> +
> + return c;
> +}
Re: [PATCH] drivers: fix a typo in the kernel doc for devm_platform_ioremap_resource()
pon., 1 kwi 2019 o 12:23 Mukesh Ojha napisał(a):
>
>
> On 4/1/2019 1:46 PM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > It should have been 'management' not 'managemend'.
> >
> > Fixes: 7945f929f1a7 ("drivers: provide devm_platform_ioremap_resource()")
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > drivers/base/platform.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index dab0a5abc391..09c00d91094c 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -84,7 +84,7 @@ EXPORT_SYMBOL_GPL(platform_get_resource);
> >* device
> >*
> >* @pdev: platform device to use both for memory resource lookup as well
> > as
> > - *resource managemend
> > + *resource management
>
>
> :-)
>
> Reviewed-by: Mukesh Ojha
>
> Cheers,
> -Mukesh
>
> >* @index: resource index
> >*/
> > #ifdef CONFIG_HAS_IOMEM
Hi Greg,
can you pick this one up into your tree?
Thanks in advance,
Bartosz
[PATCH] gpio: eic: sprd: Fix incorrect irq type setting for the sync EIC
When setting sync EIC as IRQ_TYPE_EDGE_BOTH type, we missed to set the
SPRD_EIC_SYNC_INTMODE register to 0, which means detecting edge signals.
Thus this patch fixes the issue.
Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
Cc:
Signed-off-by: Baolin Wang
---
drivers/gpio/gpio-eic-sprd.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-eic-sprd.c b/drivers/gpio/gpio-eic-sprd.c
index f0223ce..7709226 100644
--- a/drivers/gpio/gpio-eic-sprd.c
+++ b/drivers/gpio/gpio-eic-sprd.c
@@ -414,6 +414,7 @@ static int sprd_eic_irq_set_type(struct irq_data *data,
unsigned int flow_type)
irq_set_handler_locked(data, handle_edge_irq);
break;
case IRQ_TYPE_EDGE_BOTH:
+ sprd_eic_update(chip, offset, SPRD_EIC_SYNC_INTMODE, 0);
sprd_eic_update(chip, offset, SPRD_EIC_SYNC_INTBOTH, 1);
irq_set_handler_locked(data, handle_edge_irq);
break;
--
1.7.9.5
Re: [PATCH] misc: rtsx: Fixed rts5260 power saving parameter and sd glitch
at 16:56, ricky...@realtek.com wrote:
From: RickyWu
this patch fixes rts5260 power saving parameter
make power saving function work on L1.1, L1.2
Signed-off-by: RickyWu
---
drivers/misc/cardreader/rts5260.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/misc/cardreader/rts5260.c
b/drivers/misc/cardreader/rts5260.c
index da22bcb62b04..b510d3f46587 100644
--- a/drivers/misc/cardreader/rts5260.c
+++ b/drivers/misc/cardreader/rts5260.c
@@ -195,7 +195,7 @@ static int sd_set_sample_push_timing_sd30(struct
rtsx_pcr *pcr)
| SD_ASYNC_FIFO_NOT_RST, SD_30_MODE | SD_ASYNC_FIFO_NOT_RST);
rtsx_pci_write_register(pcr, CLK_CTL, CLK_LOW_FREQ, CLK_LOW_FREQ);
rtsx_pci_write_register(pcr, CARD_CLK_SOURCE, 0xFF,
- CRC_VAR_CLK0 | SD30_FIX_CLK | SAMPLE_VAR_CLK1);
+ CRC_VAR_CLK0 | SD30_FIX_CLK | SAMPLE_VAR_CLK1);
Just a nit, seems to be an unnecessary change.
rtsx_pci_write_register(pcr, CLK_CTL, CLK_LOW_FREQ, 0);
return 0;
@@ -238,8 +238,8 @@ static int rts5260_card_power_on(struct rtsx_pcr
*pcr, int card)
/* Reset SD_CFG3 register */
rtsx_pci_write_register(pcr, SD_CFG3, SD30_CLK_END_EN, 0);
rtsx_pci_write_register(pcr, REG_SD_STOP_SDCLK_CFG,
- SD30_CLK_STOP_CFG_EN | SD30_CLK_STOP_CFG1 |
- SD30_CLK_STOP_CFG0, 0);
+ SD30_CLK_STOP_CFG_EN | SD30_CLK_STOP_CFG1 |
+ SD30_CLK_STOP_CFG0, 0);
Ditto.
rtsx_pci_write_register(pcr, REG_PRE_RW_MODE, EN_INFINITE_MODE, 0);
@@ -315,12 +315,12 @@ static void rts5260_init_ocp(struct rtsx_pcr *pcr)
rtsx_pci_write_register(pcr, RTS5260_DVCC_CTRL,
- RTS5260_DVCC_OCP_THD_MASK,
- option->sd_800mA_ocp_thd);
+ RTS5260_DVCC_OCP_THD_MASK,
+ option->sd_800mA_ocp_thd);
Ditto.
rtsx_pci_write_register(pcr, RTS5260_DV331812_CFG,
- RTS5260_DV331812_OCP_THD_MASK,
- RTS5260_DV331812_OCP_THD_270);
+ RTS5260_DV331812_OCP_THD_MASK,
+ RTS5260_DV331812_OCP_THD_270);
Ditto.
That said, the patch works,
Tested-by: Kai-Heng Feng
mask = SD_OCP_GLITCH_MASK;
val = pcr->hw_param.ocp_glitch;
@@ -451,6 +451,7 @@ static void rts5260_pwr_saving_setting(struct
rtsx_pcr *pcr)
lss_l1_2 = rtsx_check_dev_flag(pcr, ASPM_L1_2_EN)
| rtsx_check_dev_flag(pcr, PM_L1_2_EN);
+ rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, 0xFF, 0);
if (lss_l1_2) {
pcr_dbg(pcr, "Set parameters for L1.2.");
rtsx_pci_write_register(pcr, PWR_GLOBAL_CTRL,
@@ -573,10 +574,10 @@ static int rts5260_extra_init_hw(struct rtsx_pcr
*pcr)
* to drive low, and we forcibly request clock.
*/
if (option->force_clkreq_0)
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
+ rtsx_pci_write_register(pcr, PETXCFG,
FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW);
else
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
+ rtsx_pci_write_register(pcr, PETXCFG,
FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_HIGH);
return 0;
@@ -704,7 +705,7 @@ void rts5260_init_params(struct rtsx_pcr *pcr)
option->ocp_en = 1;
if (option->ocp_en)
hw_param->interrupt_en |= SD_OC_INT_EN;
- hw_param->ocp_glitch = SDVIO_OCP_GLITCH_800U | SDVIO_OCP_GLITCH_800U;
+ hw_param->ocp_glitch = SD_OCP_GLITCH_100U | SDVIO_OCP_GLITCH_800U;
option->sd_400mA_ocp_thd = RTS5260_DVCC_OCP_THD_550;
option->sd_800mA_ocp_thd = RTS5260_DVCC_OCP_THD_970;
}
--
2.17.1
RE: [EXT] Re: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal binding
Hi, Rui/ Eduardo I just resent the V11 patch series as I found previous patch series has conflict on the dt-binding patch, can NOT be applied directly, sorry for the inconvenience. Best Regards! Anson Huang > -Original Message- > From: Anson Huang > Sent: 2019年4月10日 14:06 > To: Zhang Rui ; Rob Herring ; > edubez...@gmail.com > Cc: mark.rutl...@arm.com; shawn...@kernel.org; > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com; > catalin.mari...@arm.com; will.dea...@arm.com; > daniel.lezc...@linaro.org; Aisheng Dong ; > ulf.hans...@linaro.org; sb...@kernel.org; Daniel Baluta > ; Andy Gross ; > horms+rene...@verge.net.au; he...@sntech.de; a...@arndb.de; > maxime.rip...@bootlin.com; bjorn.anders...@linaro.org; > ja...@amarulasolutions.com; enric.balle...@collabora.com; > marc.w.gonza...@free.fr; o...@lixom.net; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > p...@vger.kernel.org; dl-linux-imx > Subject: RE: [EXT] Re: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal > binding > > Hi, Rui/Eduardo > I just sent out a V11 patch series following Rob's suggestion, please > help review it. > So if the HW resource ID can be as phandle's argument, then go with > V11 patch series, if it MUST be virtual ID starting from 0-N, then pick V10 > patch series. > Thanks for your time. > > Best Regards! > Anson Huang > > > -Original Message- > > From: Zhang Rui [mailto:rui.zh...@intel.com] > > Sent: 2019年4月9日 15:29 > > To: Anson Huang ; Rob Herring > ; > > edubez...@gmail.com > > Cc: mark.rutl...@arm.com; shawn...@kernel.org; > s.ha...@pengutronix.de; > > ker...@pengutronix.de; feste...@gmail.com; catalin.mari...@arm.com; > > will.dea...@arm.com; daniel.lezc...@linaro.org; Aisheng Dong > > ; ulf.hans...@linaro.org; sb...@kernel.org; > > Daniel Baluta ; Andy Gross > > ; > > horms+rene...@verge.net.au; he...@sntech.de; a...@arndb.de; > > maxime.rip...@bootlin.com; bjorn.anders...@linaro.org; > > ja...@amarulasolutions.com; enric.balle...@collabora.com; > > marc.w.gonza...@free.fr; o...@lixom.net; devicet...@vger.kernel.org; > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > > linux- p...@vger.kernel.org; dl-linux-imx > > Subject: [EXT] Re: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal > > binding > > > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > > attachments unless you recognize the sender and know the content is safe. > > > > > > > > On 二, 2019-04-09 at 05:28 +, Anson Huang wrote: > > > Ping... > > > Can anyone provide some suggestion about how to proceed next? > > > > > Hi, Eduardo, > > > > I guess you will comment on this patch, right? > > Or else I will take the patch following Rob' suggestion. > > > > thanks, > > rui > > > > > > > Best Regards! > > > Anson Huang > > > > > > > > > > > -Original Message- > > > > From: Anson Huang > > > > Sent: 2019年3月26日 10:45 > > > > To: 'Rob Herring' ; 'edubez...@gmail.com' > > > > > > > > Cc: 'mark.rutl...@arm.com' ; > > > > 'shawn...@kernel.org' ; > > 's.hauer@pengutronix.d > > > > e' > > > > ; 'ker...@pengutronix.de' > > > > ; 'feste...@gmail.com' > > ; > > > > 'catalin.mari...@arm.com' ; > > > > 'will.dea...@arm.com' ; > 'rui.zh...@intel.com' > > > > ; 'edubez...@gmail.com' > > ; > > > > 'daniel.lezc...@linaro.org' ; Aisheng > > > > Dong ; 'ulf.hans...@linaro.org' > > > > ; 'sb...@kernel.org' ; > > > > Daniel Baluta ; Andy Gross > > > > ; 'horms+rene...@verge.net.au' > > > > ; 'he...@sntech.de' > ; > > > > 'a...@arndb.de' > > > >; > > > > 'maxime.rip...@bootlin.com' ; > > > > 'bjorn.anders...@linaro.org' ; > > > > 'ja...@amarulasolutions.com' ; > > > > 'enric.balle...@collabora.com' ; > > > > 'marc.w.gonza...@free.fr' ; > > > > 'o...@lixom.ne t' > > > > ; 'devicet...@vger.kernel.org' > > > > ; 'linux-kernel@vger.kernel.org' > > > > > > > ker...@vger.kernel.org>; 'linux-arm-ker...@lists.infradead.org' > > > > > > > ker...@lists.infradead.org>; 'linux...@vger.kernel.org' > > > p...@vger.kernel.org>; dl-linux-imx > > > > Subject: RE: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal > > > > binding > > > > > > > > Ping... > > > > > > > > Hi, Eduardo > > > > What is your opinion about where to put the HW resource ID in > > > > DT? > > > > > > > > Best Regards! > > > > Anson Huang > > > > > > > > > > > > > > -Original Message- > > > > > From: Anson Huang > > > > > Sent: 2019年3月13日 16:12 > > > > > To: 'Rob Herring' ; 'edubez...@gmail.com' > > > > > > > > > > Cc: 'mark.rutl...@arm.com' ; > > > > > 'shawn...@kernel.org' ; > > > > 's.ha...@pengutronix.de' > > > > > > > > > > ; 'ker...@pengutronix.de' > > > > > ; 'feste...@gmail.com' > > > > > > >; > > > > > 'catalin.mari...@arm.com' ; > > > > > 'will.dea...@arm.com' ; > > > > > 'rui.zh...@intel.com ' > > > > > ; 'edubez...@gmail.com' > > > > > > >; > > > > > 'daniel.lezc...@linaro.org' ; Aisheng > > > > > Dong ;
[PATCH RESEND V11 4/4] arm64: dts: imx: add i.MX8QXP thermal support
Add i.MX8QXP CPU thermal zone support.
Signed-off-by: Anson Huang
---
Changes since V10:
- remove property "imx,sensor-resource-id" and put HW resource ID
inside each
thermal-sensors' phandle argument.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 33 ++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 70ef3db..cc1d877 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <>;
@@ -149,6 +150,11 @@
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+ tsens: thermal-sensor {
+ compatible = "fsl,imx8qxp-sc-thermal",
"fsl,imx-sc-thermal";
+ #thermal-sensor-cells = <1>;
+ };
};
timer {
@@ -484,4 +490,31 @@
power-domains = < IMX_SC_R_GPIO_7>;
};
};
+
+ thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = < IMX_SC_R_SYSTEM>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ cooling-maps {
+ map0 {
+ trip = <_alert0>;
+ cooling-device =
+ <_0 THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
};
--
2.7.4
[PATCH RESEND V11 1/4] dt-bindings: fsl: scu: add thermal binding
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from thermal sensors, this patch adds
binding doc for i.MX system controller thermal driver.
Signed-off-by: Anson Huang
---
Changes since V10:
- remove property "imx,sensor-resource-id".
---
.../devicetree/bindings/arm/freescale/fsl,scu.txt| 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 72d481c..023fb5c 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -122,6 +122,17 @@ RTC bindings based on SCU Message Protocol
Required properties:
- compatible: should be "fsl,imx8qxp-sc-rtc";
+Thermal bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible: Should be :
+ "fsl,imx8qxp-sc-thermal"
+ followed by "fsl,imx-sc-thermal";
+
+- #thermal-sensor-cells: See
Documentation/devicetree/bindings/thermal/thermal.txt
+ for a description.
+
Example (imx8qxp):
-
lsio_mu1: mailbox@5d1c {
@@ -168,6 +179,11 @@ firmware {
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+ tsens: thermal-sensor {
+ compatible = "fsl,imx8qxp-sc-thermal",
"fsl,imx-sc-thermal";
+ #thermal-sensor-cells = <1>;
+ };
};
};
--
2.7.4
[PATCH RESEND V11 2/4] thermal: imx_sc: add i.MX system controller thermal support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to get each thermal sensor's temperature,
it supports multiple sensors which are passed from device tree,
please see the binding doc for details.
Signed-off-by: Anson Huang
---
Changes since V10:
- remove "imx,sensor-resource-id" property, put the HW resource ID
inside thermal-zones node,
and driver needs to parse the phandle argument to get HW resource ID
and use it to register
thermal zone.
---
drivers/thermal/Kconfig | 11 +++
drivers/thermal/Makefile | 1 +
drivers/thermal/imx_sc_thermal.c | 159 +++
3 files changed, 171 insertions(+)
create mode 100644 drivers/thermal/imx_sc_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 653aa27..4e4fa7e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -223,6 +223,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config IMX_SC_THERMAL
+ tristate "Temperature sensor driver for NXP i.MX SoCs with System
Controller"
+ depends on (ARCH_MXC && IMX_SCU) || COMPILE_TEST
+ depends on OF
+ help
+ Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
+ system controller inside, Linux kernel has to communicate with system
+ controller via MU (message unit) IPC to get temperature from thermal
+ sensor. It supports one critical trip point and one
+ passive trip point for each thermal sensor.
+
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 486d682..4062627 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
new file mode 100644
index 000..0af0f09
--- /dev/null
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+#define IMX_SC_MISC_FUNC_GET_TEMP 13
+#define IMX_SC_C_TEMP 0
+
+static struct imx_sc_ipc *thermal_ipc_handle;
+
+struct imx_sc_sensor {
+ struct thermal_zone_device *tzd;
+ u32 resource_id;
+};
+
+struct req_get_temp {
+ u16 resource_id;
+ u8 type;
+} __packed;
+
+struct resp_get_temp {
+ u16 celsius;
+ u8 tenths;
+} __packed;
+
+struct imx_sc_msg_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ union {
+ struct req_get_temp req;
+ struct resp_get_temp resp;
+ } data;
+} __packed;
+
+static int imx_sc_thermal_get_temp(void *data, int *temp)
+{
+ struct imx_sc_msg_misc_get_temp msg;
+ struct imx_sc_rpc_msg *hdr =
+ struct imx_sc_sensor *sensor = data;
+ int ret;
+
+ msg.data.req.resource_id = sensor->resource_id;
+ msg.data.req.type = IMX_SC_C_TEMP;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
+ hdr->size = 2;
+
+ ret = imx_scu_call_rpc(thermal_ipc_handle, , true);
+ if (ret) {
+ pr_err("read temp sensor %d failed, ret %d\n",
+ sensor->resource_id, ret);
+ return ret;
+ }
+
+ *temp = msg.data.resp.celsius * 1000 + msg.data.resp.tenths * 100;
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
+ .get_temp = imx_sc_thermal_get_temp,
+};
+
+static int imx_sc_thermal_get_sensor_id(struct device_node *sensor_np, u32 *id)
+{
+ struct of_phandle_args sensor_specs;
+ int ret;
+
+ ret = of_parse_phandle_with_args(sensor_np,
+"thermal-sensors",
+"#thermal-sensor-cells",
+0,
+_specs);
+ if (ret)
+ return ret;
+
+ if (sensor_specs.args_count >= 1) {
+
[PATCH RESEND V11 3/4] defconfig: arm64: add i.MX system controller thermal support
This patch enables CONFIG_IMX_SC_THERMAL as module. Signed-off-by: Anson Huang --- No changes. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 9e313f5..d4c404a 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -415,6 +415,7 @@ CONFIG_SENSORS_INA2XX=m CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y +CONFIG_IMX_SC_THERMAL=m CONFIG_ROCKCHIP_THERMAL=m CONFIG_RCAR_THERMAL=y CONFIG_RCAR_GEN3_THERMAL=y -- 2.7.4
Re: [PATCH 1/2] perf/x86/intel: Support adaptive PEBS for fixed counters
On Tue, Apr 09, 2019 at 06:09:59PM -0700, kan.li...@linux.intel.com wrote:
> From: Kan Liang
>
> Fixed counters can also generate adaptive PEBS record, if the
> corresponding bit in IA32_FIXED_CTR_CTRL is set.
> Otherwise, only basic record is generated.
>
> Unconditionally set the bit when PEBS is enabled on fixed counters.
> Let MSR_PEBS_CFG decide which format of PEBS record should be generated.
> There is no harmful to leave the bit set.
I'll merge this back into:
Subject: perf/x86/intel: Support adaptive PEBSv4
such that this bug never existed, ok?
>
> Signed-off-by: Kan Liang
> ---
> arch/x86/events/intel/core.c | 5 +
> arch/x86/include/asm/perf_event.h | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 56df0f6..f34d92b 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -2174,6 +2174,11 @@ static void intel_pmu_enable_fixed(struct perf_event
> *event)
> bits <<= (idx * 4);
> mask = 0xfULL << (idx * 4);
>
> + if (x86_pmu.intel_cap.pebs_baseline && event->attr.precise_ip) {
> + bits |= ICL_FIXED_0_ADAPTIVE << (idx * 4);
> + mask |= ICL_FIXED_0_ADAPTIVE << (idx * 4);
> + }
> +
> rdmsrl(hwc->config_base, ctrl_val);
> ctrl_val &= ~mask;
> ctrl_val |= bits;
> diff --git a/arch/x86/include/asm/perf_event.h
> b/arch/x86/include/asm/perf_event.h
> index dcb8bac..ce0dc88 100644
> --- a/arch/x86/include/asm/perf_event.h
> +++ b/arch/x86/include/asm/perf_event.h
> @@ -33,6 +33,7 @@
> #define HSW_IN_TX(1ULL << 32)
> #define HSW_IN_TX_CHECKPOINTED (1ULL << 33)
> #define ICL_EVENTSEL_ADAPTIVE(1ULL << 34)
> +#define ICL_FIXED_0_ADAPTIVE (1ULL << 32)
>
> #define AMD64_EVENTSEL_INT_CORE_ENABLE (1ULL << 36)
> #define AMD64_EVENTSEL_GUESTONLY (1ULL << 40)
> --
> 2.7.4
>
Re: [PATCH] ARM: dts: imx6qdl-nitrogen6_max: Disable LVDS channels
Hi,
On Tue, Apr 9, 2019 at 2:07 AM Robert Foss wrote:
>
> Hey Fabio,
>
> On 4/8/19 10:37 PM, Fabio Estevam wrote:
> > Hi Robert,
> >
> > [Adding Gary]
Adding Troy, I'm no longer a full-time employee at Boundary Devices.
> > On Mon, Apr 8, 2019 at 2:54 PM Robert Foss
> > wrote:
> >>
> >> If a LVDS device is not connected, having the LVDS channels
> >> enabled will prevent imx-ldb from probing correctly even
> >> if other CRTCs are connected.
> >>
> >> Signed-off-by: Robert Foss
> >> ---
> >> arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> >> b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> >> index 39200e5dc896..5b413cf4c250 100644
> >> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> >> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> >> @@ -703,7 +703,7 @@
> >> status = "okay";
> >>
> >> lvds-channel@0 {
> >> - status = "okay";
> >> + status = "disabled";
> >>
> >> port@4 {
> >> reg = <4>;
> >> @@ -715,7 +715,7 @@
> >> };
> >>
> >> lvds-channel@1 {
> >> - status = "okay";
> >> + status = "disabled";
> >
> > I am not sure I understood what you are trying to fix.
>
> If CONFIG_DRM_IMX_LDB is enabled, LVDS DT channels are enabled
> and no LVDS-panels are connected the imx-ldb driver will
> fail to bind.
>
> This is a problem, since it will prevent other actually connected
> display output from being used, even if they bind properly.
>
> >
> > Could you please share some logs when imx-ldb fails to probe correctly?
>
>
> [2.119563] component_bind_all() trying to bind: ldb
> [2.124600] imx-drm display-subsystem: binding ldb (ops imx_ldb_ops)
> [2.146169] drm_of_find_panel_or_bridge() np->name=lvds-channel
> np->type=
> [2.153709] drm_of_find_panel_or_bridge() no panel found for remote
> [2.160081] drm_of_find_panel_or_bridge() bridge needed
> [2.162043] drm_of_find_panel_or_bridge() bridge not found
> [2.165331] drm_of_find_panel_or_bridge() failed
> [2.170023] imx-drm display-subsystem: failed to bind ldb (ops
> imx_ldb_ops): -517
>
> This at the same time as HDMI binds properly:
>
> [4.458954] dwhdmi-imx 12.hdmi: Detected HDMI TX controller v1.30a with
> HDCP (DWC HDMI 3D TX PHY)
> [4.469633] imx-drm display-subsystem: bound 12.hdmi (ops
> dw_hdmi_imx_ops)
>
> Which in the end causes the IMX driver to not initialize properly
> and ignore the HDMI connection that bound properly.
> This in turn prevents us from having any graphical output while there
> is no LVDS panel connected.
Does this happen if the LVDS is disabled in cmdline? (adding "video=LVDS-1:d")
Note that a bootscript was written for mainline kernel that takes care
of display configuration [1].
Currently this bootscript disables all the displays that aren't used.
It was tested with HDMI, where LVDS and LCD display are disabled, and
it *used to* work.
If this doesn't work then there's most likely a regression somewhere.
Regards,
Gary
[1]
https://github.com/boundarydevices/u-boot-imx6/blob/boundary-v2018.07/board/boundary/bootscripts/bootscript-mainline.txt#L90
Re: [PATCH v2 2/5] arm64, mm: Move generic mmap layout functions to mm
On 04/10/2019 08:59 AM, Christoph Hellwig wrote: On Thu, Apr 04, 2019 at 01:51:25AM -0400, Alexandre Ghiti wrote: - fix the case where stack randomization should not be taken into account. Hmm. This sounds a bit vague. It might be better if something considered a fix is split out to a separate patch with a good description. Ok, I will move this fix in another patch. +config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT + bool + help + This allows to use a set of generic functions to determine mmap base + address by giving priority to top-down scheme only if the process + is not in legacy mode (compat task, unlimited stack size or + sysctl_legacy_va_layout). Given that this is an option that is just selected by other Kconfig options the help text won't ever be shown. I'd just move it into a comment bove the definition. Oh yes, it does not appear, thanks, I'll move it above the definition. +#ifdef CONFIG_MMU +#ifdef CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT I don't think we need the #ifdef CONFIG_MMU here, CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT should only be selected if the MMU is enabled to start with. Ok, thanks. +#ifdef CONFIG_ARCH_HAS_ELF_RANDOMIZE +unsigned long arch_mmap_rnd(void) Now that a bunch of architectures use a version in common code the arch_ prefix is a bit mislead. Probably not worth changing here, but some time in the future it could use a new name. Ok I'll keep it in mind for later, Thanks for your time, Alex
Re: [PATCH 08/10] x86-64: select DYNAMIC_DEBUG_RELATIVE_POINTERS
* Rasmus Villemoes wrote: > This reduces the size of struct _ddebug from 56 to 40 bytes. There's > one such struct for each pr_debug(), netdev_debug() etc. in a > CONFIG_DYNAMIC_DEBUG kernel. An Ubuntu 4.15 kernel has about 2550 > entries in the __verbose section of vmlinux, amounting to ~40K > saved. (Modules also become smaller, but it's harder to quantify how > much that yields at runtime.) > > For comparison, the __bug_table section of that Ubuntu kernel is 75576 > bytes, i.e. 6298 12-byte bug_entrys, so GENERIC_BUG_RELATIVE_POINTERS > saves ~50K. > > Due to the build-time sanity checks in asm-generic/dynamic_debug.h, we > need to add another #undef to vclock_gettime.c. > > Signed-off-by: Rasmus Villemoes > --- > arch/x86/Kconfig| 1 + > arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + > arch/x86/include/asm/Kbuild | 1 + > 3 files changed, 3 insertions(+) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 5ad92419be19..eb5488b4577d 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -30,6 +30,7 @@ config X86_64 > select SWIOTLB > select X86_DEV_DMA_OPS > select ARCH_HAS_SYSCALL_WRAPPER > + select DYNAMIC_DEBUG_RELATIVE_POINTERS Acked-by: Ingo Molnar Thanks, Ingo
Re: [PATCH 19/23] watchdog: st_lpc_wdt: Convert to use device managed functions
Hi Guenter
On 4/9/19 7:23 PM, Guenter Roeck wrote:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare
> - Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatedly
> - Use devm_watchdog_register_driver() to register watchdog device
>
> Cc: Patrice Chotard
> Signed-off-by: Guenter Roeck
> ---
> drivers/watchdog/st_lpc_wdt.c | 47
> ---
> 1 file changed, 26 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/watchdog/st_lpc_wdt.c b/drivers/watchdog/st_lpc_wdt.c
> index 196fb4b72c5d..9a5ed95c3403 100644
> --- a/drivers/watchdog/st_lpc_wdt.c
> +++ b/drivers/watchdog/st_lpc_wdt.c
> @@ -142,10 +142,16 @@ static struct watchdog_device st_wdog_dev = {
> .ops= _wdog_ops,
> };
>
> +static void st_clk_disable_unprepare(void *data)
> +{
> + clk_disable_unprepare(data);
> +}
> +
> static int st_wdog_probe(struct platform_device *pdev)
> {
> + struct device *dev = >dev;
> const struct of_device_id *match;
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = dev->of_node;
> struct st_wdog *st_wdog;
> struct regmap *regmap;
> struct clk *clk;
> @@ -155,7 +161,7 @@ static int st_wdog_probe(struct platform_device *pdev)
>
> ret = of_property_read_u32(np, "st,lpc-mode", );
> if (ret) {
> - dev_err(>dev, "An LPC mode must be provided\n");
> + dev_err(dev, "An LPC mode must be provided\n");
> return -EINVAL;
> }
>
> @@ -163,13 +169,13 @@ static int st_wdog_probe(struct platform_device *pdev)
> if (mode != ST_LPC_MODE_WDT)
> return -ENODEV;
>
> - st_wdog = devm_kzalloc(>dev, sizeof(*st_wdog), GFP_KERNEL);
> + st_wdog = devm_kzalloc(dev, sizeof(*st_wdog), GFP_KERNEL);
> if (!st_wdog)
> return -ENOMEM;
>
> - match = of_match_device(st_wdog_match, >dev);
> + match = of_match_device(st_wdog_match, dev);
> if (!match) {
> - dev_err(>dev, "Couldn't match device\n");
> + dev_err(dev, "Couldn't match device\n");
> return -ENODEV;
> }
> st_wdog->syscfg = (struct st_wdog_syscfg *)match->data;
> @@ -180,17 +186,17 @@ static int st_wdog_probe(struct platform_device *pdev)
>
> regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> if (IS_ERR(regmap)) {
> - dev_err(>dev, "No syscfg phandle specified\n");
> + dev_err(dev, "No syscfg phandle specified\n");
> return PTR_ERR(regmap);
> }
>
> - clk = devm_clk_get(>dev, NULL);
> + clk = devm_clk_get(dev, NULL);
> if (IS_ERR(clk)) {
> - dev_err(>dev, "Unable to request clock\n");
> + dev_err(dev, "Unable to request clock\n");
> return PTR_ERR(clk);
> }
>
> - st_wdog->dev= >dev;
> + st_wdog->dev= dev;
> st_wdog->base = base;
> st_wdog->clk= clk;
> st_wdog->regmap = regmap;
> @@ -198,39 +204,40 @@ static int st_wdog_probe(struct platform_device *pdev)
> st_wdog->clkrate= clk_get_rate(st_wdog->clk);
>
> if (!st_wdog->clkrate) {
> - dev_err(>dev, "Unable to fetch clock rate\n");
> + dev_err(dev, "Unable to fetch clock rate\n");
> return -EINVAL;
> }
> st_wdog_dev.max_timeout = 0x / st_wdog->clkrate;
> - st_wdog_dev.parent = >dev;
> + st_wdog_dev.parent = dev;
>
> ret = clk_prepare_enable(clk);
> if (ret) {
> - dev_err(>dev, "Unable to enable clock\n");
> + dev_err(dev, "Unable to enable clock\n");
> return ret;
> }
> + ret = devm_add_action_or_reset(dev, st_clk_disable_unprepare, clk);
> + if (ret)
> + return ret;
>
> watchdog_set_drvdata(_wdog_dev, st_wdog);
> watchdog_set_nowayout(_wdog_dev, WATCHDOG_NOWAYOUT);
>
> /* Init Watchdog timeout with value in DT */
> - ret = watchdog_init_timeout(_wdog_dev, 0, >dev);
> + ret = watchdog_init_timeout(_wdog_dev, 0, dev);
> if (ret) {
> - dev_err(>dev, "Unable to initialise watchdog timeout\n");
> - clk_disable_unprepare(clk);
> + dev_err(dev, "Unable to initialise watchdog timeout\n");
> return ret;
> }
>
> - ret = watchdog_register_device(_wdog_dev);
> + ret = devm_watchdog_register_device(dev, _wdog_dev);
> if (ret) {
> -
[PATCH] arm64: dts: sprd: Add clock properties for serial devices
We've introduced power management logics for the Spreadtrum serial
controller by commit 062ec2774c8a ("serial: sprd: Add power management
for the Spreadtrum serial controller"), thus add related clock properties
to support this feature.
Signed-off-by: Baolin Wang
---
arch/arm64/boot/dts/sprd/whale2.dtsi | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/sprd/whale2.dtsi
b/arch/arm64/boot/dts/sprd/whale2.dtsi
index 34b6ca0..b5c5dce 100644
--- a/arch/arm64/boot/dts/sprd/whale2.dtsi
+++ b/arch/arm64/boot/dts/sprd/whale2.dtsi
@@ -75,7 +75,9 @@
"sprd,sc9836-uart";
reg = <0x0 0x100>;
interrupts = ;
- clocks = <_26m>;
+ clock-names = "enable", "uart", "source";
+ clocks = <_gate CLK_UART0_EB>,
+ <_clk CLK_UART0>, <_26m>;
status = "disabled";
};
@@ -84,7 +86,9 @@
"sprd,sc9836-uart";
reg = <0x10 0x100>;
interrupts = ;
- clocks = <_26m>;
+ clock-names = "enable", "uart", "source";
+ clocks = <_gate CLK_UART1_EB>,
+ <_clk CLK_UART1>, <_26m>;
status = "disabled";
};
@@ -93,7 +97,9 @@
"sprd,sc9836-uart";
reg = <0x20 0x100>;
interrupts = ;
- clocks = <_26m>;
+ clock-names = "enable", "uart", "source";
+ clocks = <_gate CLK_UART2_EB>,
+ <_clk CLK_UART2>, <_26m>;
status = "disabled";
};
@@ -102,7 +108,9 @@
"sprd,sc9836-uart";
reg = <0x30 0x100>;
interrupts = ;
- clocks = <_26m>;
+ clock-names = "enable", "uart", "source";
+ clocks = <_gate CLK_UART3_EB>,
+ <_clk CLK_UART3>, <_26m>;
status = "disabled";
};
};
--
1.7.9.5
Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry and randomizer support
On Wed, 10 Apr 2019 09:14:14 +0800 masonccy...@mxic.com.tw wrote: > Hi Boris, > > > > > Subject > > > > Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry and randomizer > support > > > > On Tue, 9 Apr 2019 17:35:39 +0800 > > masonccy...@mxic.com.tw wrote: > > > > > > > + > > > > > +static const struct kobj_attribute sysfs_mxic_nand = > > > > > + __ATTR(nand_random, S_IRUGO | S_IWUSR, > > > > > + mxic_nand_rand_type_show, > > > > > + mxic_nand_rand_type_store); > > > > > > > > No, we don't want to expose that through a sysfs file, especially > since > > > > changing the randomizer config means making the NAND unreadable for > > > > those that have used it before the change. > > > > > > > > > > Our on-die randomizer is still readable from user after the function > > > is enabled. > > > > You mean the memory is still readable no matter the randomizer state. > > Not sure how that's possible, but okay. > > > > > This randomizer is just like a internal memory cell > > > reliability enhanced. > > > > Why don't you enable it by default then? > > The penalty of randomizer is read/write performance down. > i.e,. tPROG 300 us to 340 us (randomizer enable) > therefore, disable it by default. I'm a bit puzzled. On the NAND I've seen that required data randomization it's not something you'd want to disable as this implied poor data retention. What's the use case here? Are we talking about SLC or MLC NANDs? Should we enable this feature once we start seeing that the NAND starts being less reliable (basically when read-retry happens more often)? I really think this is something you should decide kernel side, because users have no clue when it's appropriate to switch this feature on/off. > > > > > > It could be enable at any time with OTP bit function and that's why > > > we patch it by sys-fs. > > > > Sorry, but that's not a good reason to expose that through sysfs. > > Any good way to expose randomizer function for user ? Don't expose it :P.
Re: [PATCH 0/6] objtool: Add support for Arm64
On 10/04/2019 04:37, Josh Poimboeuf wrote: > On Tue, Apr 09, 2019 at 10:43:18AM -0700, Ard Biesheuvel wrote: >> On Tue, 9 Apr 2019 at 06:53, Raphael Gault wrote: >>> >>> Hi, >>> >>> As of now, objtool only supports the x86_64 architecture but the >>> groundwork has already been done in order to add support for other >>> architecture without too much effort. >>> >>> This series of patches adds support for the arm64 architecture >>> based on the Armv8.5 Architecture Reference Manual. >>> >> >> I think it makes sense to clarify *why* we want this on arm64. Also, >> we should identify things that objtool does today that maybe we don't >> want on arm64, rather than buy into all of it by default. > > Agreed, the "why" should at least be in the cover letter. From my > perspective, the "why" includes: > > - Live patching - objtool stack validation is the foundation for a > reliable unwinder > Yes, as I understand Live patching is a work in progress for arm64. Having objtool to provide more guarantees would be nice. > - ORC unwinder - benefits include presumed improved overall performance > from disabling frame pointers, and the ability to unwind across > interrupts and exceptions > I'm unsure this will be part of the plan. I believe so far arm64 code heavily relies on the presence of frame pointers. It's also part of the Aarch64 Procedure Call Standard. But who knows. > - PeterZ's new uaccess validation? > Yes, we've reverted twice our implementation of user_access_begin/end() on arm64 because of the issue of potentially calling sleeping functions. Once we have the base of objtool work, this would be one of the next work items. Thanks, -- Julien Thierry
Re: [PATCH v2 5/5] riscv: Make mmap allocation top-down by default
On 04/10/2019 08:59 AM, Christoph Hellwig wrote: Looks good, Reviewed-by: Christoph Hellwig Thanks Christoph, Alex
Re: [PATCH v2 1/5] mm, fs: Move randomize_stack_top from fs to mm
On 04/10/2019 08:54 AM, Christoph Hellwig wrote: Looks good, Reviewed-by: Christoph Hellwig Thanks Christoph, Alex
Re: [PATCH] perf/report: [RFC] Handling OOM in perf report
On 4/9/19 12:42 PM, Jiri Olsa wrote:
> On Mon, Apr 01, 2019 at 04:20:00PM +0200, Thomas Richter wrote:
>
> SNIP
>
>> perf_session__process_event() returns to its caller, where -ENOMEM is
>> changed to -EINVAL and processing stops:
>>
>> if ((skip = perf_session__process_event(session, event, head)) < 0) {
>> pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
>> head, event->header.size, event->header.type);
>> err = -EINVAL;
>> goto out_err;
>> }
>>
>> This occured in the FINISHED_ROUND event when it has to process some
>> 1 entries and ran out of memory.
>>
>> I understand that my perf.data file might just be too big, but I would
>> like to see some error message indicating OOM error instead of
>> processing failure of a unrelated event.
>
> you can limit the size of the report queue via ~/.perfconfig file:
>
> [report]
> queue-size=1M
>
> above should use only 1M for the queue management data the data
> for sample still get allocated thought.. but it could help
>
>>
>> However this patch just does what the pr_debug() statement indicates,
>> the event is skipped and processing continues.
>> But at least the root cause is indicated and also shows up in the
>> GUI.
>>
>> Signed-off-by: Thomas Richter
>> ---
>> tools/perf/builtin-report.c | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
>> index 4054eb1f98ac..7a27b815f7a8 100644
>> --- a/tools/perf/builtin-report.c
>> +++ b/tools/perf/builtin-report.c
>> @@ -283,8 +283,13 @@ static int process_sample_event(struct perf_tool *tool,
>> al.map->dso->hit = 1;
>>
>> ret = hist_entry_iter__add(, , rep->max_stack, rep);
>> -if (ret < 0)
>> +if (ret < 0) {
>> pr_debug("problem adding hist entry, skipping event\n");
>> +if (ret == -ENOMEM) {
>> +pr_err("Running out of memory\n");
>> +ret = 0;
>> +}
>> +}
>
>
> I think we can propagate the error completely (like below),
> and even warn about ENOMEM specificaly
>
> but I think we should bail out in case of ENOMEM, because
> the data are incomplete and misleading
>
> jirka
>
>
> ---
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index b17f1c9bc965..eea247a26ad8 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -1933,7 +1933,7 @@ reader__process_events(struct reader *rd, struct
> perf_session *session,
> pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
> file_offset + head, event->header.size,
> event->header.type);
> - err = -EINVAL;
> + err = skip;
> goto out;
> }
>
>
Above patch does not help, you simply return -ENOMEM instead of -EINVAL and
processing
stops with no indication that perf ran out of memory. Bailing out in this case
is ok.
I am fine with your patch, as long as it gives a reason why processing stopped.
In the GUI it shows on the bottom line the reason:
0xf4198 [0x8]: failed to process type: 68 [Cannot allocate memory]
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index b17f1c9bc965..e89716175588 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1930,10 +1930,10 @@ reader__process_events(struct reader *rd, struct
perf_session *session,
if (size < sizeof(struct perf_event_header) ||
(skip = rd->process(session, event, file_pos)) < 0) {
- pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
+ pr_err("%#" PRIx64 " [%#x]: failed to process type: %d [%s]\n",
file_offset + head, event->header.size,
- event->header.type);
- err = -EINVAL;
+ event->header.type, strerror(-skip));
+ err = skip;
goto out;
}
[root@m35lp76 perf]#
--
Thomas Richter, Dept 3252, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB
243294
Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry and randomizer support
Hi Mason, masonccy...@mxic.com.tw wrote on Wed, 10 Apr 2019 09:14:14 +0800: > Hi Boris, > > > > > Subject > > > > Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry and randomizer > support > > > > On Tue, 9 Apr 2019 17:35:39 +0800 > > masonccy...@mxic.com.tw wrote: > > > > > > > + > > > > > +static const struct kobj_attribute sysfs_mxic_nand = > > > > > + __ATTR(nand_random, S_IRUGO | S_IWUSR, > > > > > + mxic_nand_rand_type_show, > > > > > + mxic_nand_rand_type_store); > > > > > > > > No, we don't want to expose that through a sysfs file, especially > since > > > > changing the randomizer config means making the NAND unreadable for > > > > those that have used it before the change. > > > > > > > > > > Our on-die randomizer is still readable from user after the function > > > is enabled. > > > > You mean the memory is still readable no matter the randomizer state. > > Not sure how that's possible, but okay. So if you write non-randomized data to the NAND chip, then enable the randomizer en read back the data, all will be ok? And if randomized data is written to the NAND chip and we disable the randomizer, then the data will also be correct? > > > > > This randomizer is just like a internal memory cell > > > reliability enhanced. > > > > Why don't you enable it by default then? > > The penalty of randomizer is read/write performance down. > i.e,. tPROG 300 us to 340 us (randomizer enable) > therefore, disable it by default. Is this info somewhere in the ONFI param page? I suppose once randomization is enabled we should also tweak the timings and verify that the controller supports it. > > > It could be enable at any time with OTP bit function and that's why > > > we patch it by sys-fs. > > > > Sorry, but that's not a good reason to expose that through sysfs. > > Any good way to expose randomizer function for user ? > > thanks & best regards, > Mason > Thanks, Miquèl
Re: [PATCH v7 6/7] platform/chrome: cros_ec: add EC host command support using rpmsg.
Hi,
On Thu, Mar 28, 2019 at 7:16 PM Enric Balletbo Serra
wrote:
>
> Hi
>
> Thanks for sending this upstream, Some few comments and questions
> below. Apart from these LGTM.
>
> Missatge de Peter Shih del dia dc., 27 de març
> 2019 a les 6:17:
> >
> > From: Pi-Hsun Shih
> >
> > Add EC host command support through rpmsg.
> >
> > Signed-off-by: Pi-Hsun Shih
> > ---
> > ...
> > diff --git a/drivers/platform/chrome/cros_ec_rpmsg.c
> > b/drivers/platform/chrome/cros_ec_rpmsg.c
> > new file mode 100644
> > index ..2ecae806cfc5
> > --- /dev/null
> > +++ b/drivers/platform/chrome/cros_ec_rpmsg.c
> > ...
> > +static int cros_ec_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
> > + int len, void *priv, u32 src)
> > +{
> > + struct cros_ec_device *ec_dev = dev_get_drvdata(>dev);
> > + struct cros_ec_rpmsg *ec_rpmsg = ec_dev->priv;
> > + struct cros_ec_rpmsg_response *resp;
> > +
> > + if (!len) {
> > + dev_warn(ec_dev->dev, "rpmsg received empty response");
>
> Is this is unlikely to happen?
Yes this should not happen unless the firmware is broken. Should I
change this to `if(unlikely(!len))`, or use dev_err instead ?
>
> > + return -EINVAL;
> > + }
> > +
> > + resp = data;
> > + len -= offsetof(struct cros_ec_rpmsg_response, data);
> > + if (resp->type == HOST_COMMAND_MARK) {
> > + if (len > ec_dev->din_size) {
> > + dev_warn(
> > + ec_dev->dev,
> > + "received length %d > din_size %d,
> > truncating",
> > + len, ec_dev->din_size);
>
> How often this warning appears? Should be this a dev_dbg?
This also should not happen unless the firmware is broken, so I think
it's better to have a warning here when there's something wrong.
>
> > + len = ec_dev->din_size;
> > + }
> > +
> > + memcpy(ec_dev->din, resp->data, len);
> > + complete(_rpmsg->xfer_ack);
> > + } else if (resp->type == HOST_EVENT_MARK) {
> > + schedule_work(_rpmsg->host_event_work);
> > + } else {
> > + dev_warn(ec_dev->dev, "rpmsg received invalid type = %d",
> > +resp->type);
>
> Is this is unlikely to happen?
Same as above, this should not happen unless the firmware is broken.
>
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int cros_ec_rpmsg_probe(struct rpmsg_device *rpdev)
> > +{
> > + struct device *dev = >dev;
> > + struct cros_ec_device *ec_dev;
> > + struct cros_ec_rpmsg *ec_rpmsg;
> > + int ret;
> > +
> > + ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
> > + if (!ec_dev)
> > + return -ENOMEM;
> > +
> > + ec_rpmsg = devm_kzalloc(dev, sizeof(*ec_rpmsg), GFP_KERNEL);
> > + if (!ec_rpmsg)
> > + return -ENOMEM;
> > +
> > + ec_dev->dev = dev;
> > + ec_dev->priv = ec_rpmsg;
> > + ec_dev->cmd_xfer = cros_ec_cmd_xfer_rpmsg;
> > + ec_dev->pkt_xfer = cros_ec_pkt_xfer_rpmsg;
> > + ec_dev->phys_name = dev_name(>dev);
> > + ec_dev->din_size = sizeof(struct ec_host_response) +
> > + sizeof(struct ec_response_get_protocol_info);
> > + ec_dev->dout_size = sizeof(struct ec_host_request);
> > + dev_set_drvdata(dev, ec_dev);
> > +
> > + ec_rpmsg->rpdev = rpdev;
> > + init_completion(_rpmsg->xfer_ack);
> > + INIT_WORK(_rpmsg->host_event_work,
> > + cros_ec_rpmsg_host_event_function);
> > +
> > + ret = cros_ec_register(ec_dev);
> > + if (ret) {
> > + dev_err(dev, "cannot register EC\n");
> > + return ret;
> > + }
> > +
> > + return 0;
>
> cros_ec_register returns 0 on success and prints an error message if
> something went wrong. Remove the above and just do:
>
> return cros_ec_register(ec_dev);
>
Ack, would change this in v7.
>
> > +}
> > +
> > +static void cros_ec_rpmsg_remove(struct rpmsg_device *rpdev)
> > +{
> > + struct cros_ec_device *ec_dev = dev_get_drvdata(>dev);
> > + struct cros_ec_rpmsg *ec_rpmsg = ec_dev->priv;
> > +
> > + cancel_work_sync(_rpmsg->host_event_work);
> > +}
> > +
> > +static const struct of_device_id cros_ec_rpmsg_of_match[] = {
> > + { .compatible = "google,cros-ec-rpmsg", },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, cros_ec_rpmsg_of_match);
> > +
> > +static struct rpmsg_driver cros_ec_driver_rpmsg = {
> > + .drv = {
> > + .name = KBUILD_MODNAME,
> > + .of_match_table = cros_ec_rpmsg_of_match,
> > + },
> > + .probe = cros_ec_rpmsg_probe,
> > + .remove = cros_ec_rpmsg_remove,
> > + .callback = cros_ec_rpmsg_callback,
> > +};
> > +
> >
[PATCH v2 1/2] ARM: dts: colibri/apalis: convert to SPDX license tags
Replace boiler plate licenses texts with the SPDX license identifiers in Colibri/Apalis DTS files. Signed-off-by: Igor Opaniuk --- arch/arm/boot/dts/imx6q-apalis-eval.dts | 40 +- arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts | 40 +- arch/arm/boot/dts/imx6q-apalis-ixora.dts | 40 +- arch/arm/boot/dts/imx6qdl-apalis.dtsi | 40 +- arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 39 +- arch/arm/boot/dts/imx7-colibri.dtsi | 39 +- arch/arm/boot/dts/imx7d-colibri-eval-v3.dts | 39 +- arch/arm/boot/dts/imx7d-colibri.dtsi | 41 +-- arch/arm/boot/dts/imx7s-colibri-eval-v3.dts | 41 +-- arch/arm/boot/dts/imx7s-colibri.dtsi | 41 +-- arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 40 +- arch/arm/boot/dts/vf-colibri.dtsi | 38 + arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 40 +- arch/arm/boot/dts/vf500-colibri.dtsi | 39 +- arch/arm/boot/dts/vf610-colibri-eval-v3.dts | 38 + arch/arm/boot/dts/vf610-colibri.dtsi | 40 +- arch/arm/boot/dts/vf610m4-colibri.dts | 40 +- 17 files changed, 29 insertions(+), 646 deletions(-) diff --git a/arch/arm/boot/dts/imx6q-apalis-eval.dts b/arch/arm/boot/dts/imx6q-apalis-eval.dts index 0edd3043d9c1..621e9ee5bbeb 100644 --- a/arch/arm/boot/dts/imx6q-apalis-eval.dts +++ b/arch/arm/boot/dts/imx6q-apalis-eval.dts @@ -1,44 +1,8 @@ +// SPDX-License-Identifier: (GPL-2.0 OR X11) /* - * Copyright 2014-2017 Toradex AG + * Copyright 2014-2019 Toradex AG * Copyright 2012 Freescale Semiconductor, Inc. * Copyright 2011 Linaro Ltd. - * - * This file is dual-licensed: you can use it either under the terms - * of the GPL or the X11 license, at your option. Note that this dual - * licensing only applies to this file, and not this project as a - * whole. - * - * a) This file is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * version 2 as published by the Free Software Foundation. - * - * This file is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * Or, alternatively, - * - * b) Permission is hereby granted, free of charge, to any person - * obtaining a copy of this software and associated documentation - * files (the "Software"), to deal in the Software without - * restriction, including without limitation the rights to use, - * copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following - * conditions: - * - * The above copyright notice and this permission notice shall be - * included in all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES - * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, - * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR - * OTHER DEALINGS IN THE SOFTWARE. */ /dts-v1/; diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts b/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts index b94bb687be6b..1e365e2636c4 100644 --- a/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts +++ b/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts @@ -1,44 +1,8 @@ +// SPDX-License-Identifier: (GPL-2.0 OR X11) /* - * Copyright 2014-2017 Toradex AG + * Copyright 2014-2019 Toradex AG * Copyright 2012 Freescale Semiconductor, Inc. * Copyright 2011 Linaro Ltd. - * - * This file is dual-licensed: you can use it either under the terms - * of the GPL or the X11 license, at your option. Note that this dual - * licensing only applies to this file, and not this project as a - * whole. - * - * a) This file is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * version 2 as published by the Free Software Foundation. - * - * This file is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * Or, alternatively, - * - * b) Permission is hereby granted, free of
[PATCH v2 2/2] ARM: dts: tegra124-apalis: convert to SPDX license tags
Replace boiler plate licenses texts with the SPDX license
identifiers in Colibri/Apalis DTS files.
Signed-off-by: Igor Opaniuk
---
arch/arm/boot/dts/tegra124-apalis-emc.dtsi | 39 ++---
arch/arm/boot/dts/tegra124-apalis-eval.dts | 40 ++
arch/arm/boot/dts/tegra124-apalis.dtsi | 40 ++
3 files changed, 6 insertions(+), 113 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
b/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
index ca2c3a557895..36211f876e33 100644
--- a/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
@@ -1,42 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
/*
- * Copyright 2016 Toradex AG
+ * Copyright 2016-2019 Toradex AG
*
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This file is distributed in the hope that it will be useful
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
/ {
diff --git a/arch/arm/boot/dts/tegra124-apalis-eval.dts
b/arch/arm/boot/dts/tegra124-apalis-eval.dts
index eaee10ef6512..e2388368d635 100644
--- a/arch/arm/boot/dts/tegra124-apalis-eval.dts
+++ b/arch/arm/boot/dts/tegra124-apalis-eval.dts
@@ -1,42 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0 OR X11)
/*
- * Copyright 2016-2018 Toradex AG
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This file is distributed in the hope that it will be useful
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
+ * Copyright 2016-2019 Toradex AG
*/
/dts-v1/;
diff --git
Re: [RFC PATCH v3 1/4] x86: Add new config symbol to unify conditional definition of hv_irq_callback_count
On 2019年04月08日 17:35, Borislav Petkov wrote: Subject: x86/kconfig: Add ... On Mon, Apr 08, 2019 at 04:12:08PM +0800, Zhao Yakui wrote: Now the CONFIG_HYPERV and CONFIG_XEN can be used to control the definition /usage of hv_irq_callback_count. If another linux guest also needs to use the hv_irq_callback_count, current conditional definition looks unreadable. Rewrite that to: "Add a special Kconfig symbol X86_HV_CALLBACK_VECTOR which guests using the hypervisor interrupt callback counter can select and thus enable that counter. Select it when xen or hyperv support is enabled. No functional changes." with that fixed you can add: Reviewed-by: Borislav Petkov Thanks for your review. Will update the title and commit log as you suggested. Thanks Thx.
Re: [PATCH v3 1/4] x86: kdump: move reserve_crashkernel_low() into kexec_core.c
* Chen Zhou wrote: > In preparation for supporting more than one crash kernel regions > in arm64 as x86_64 does, move reserve_crashkernel_low() into > kexec/kexec_core.c. > > Signed-off-by: Chen Zhou > --- > arch/x86/include/asm/kexec.h | 3 ++ > arch/x86/kernel/setup.c | 66 > +--- > include/linux/kexec.h| 1 + > kernel/kexec_core.c | 53 +++ > 4 files changed, 64 insertions(+), 59 deletions(-) No objections for this to be merged via the ARM tree, as long as x86 functionality is kept intact. Thanks, Ingo
Re: [PATCH 22/23] watchdog: sunxi_wdt: Use 'dev' instead of dereferencing it repeatedly
On Tue, Apr 09, 2019 at 10:24:00AM -0700, Guenter Roeck wrote: > Introduce local variable 'struct device *dev' and use it instead of > dereferencing it repeatedly. > > The conversion was done automatically with coccinelle using the > following semantic patches. The semantic patches and the scripts > used to generate this commit log are available at > https://github.com/groeck/coccinelle-patches > > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Signed-off-by: Guenter Roeck Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [RFC PATCH v2 12/14] x86/watchdog/hardlockup/hpet: Determine if HPET timer caused NMI
On Tue, Apr 09, 2019 at 06:19:57PM -0700, Ricardo Neri wrote:
> On Tue, Apr 09, 2019 at 01:28:17PM +0200, Peter Zijlstra wrote:
> > > @@ -147,6 +161,14 @@ static void set_periodic(struct hpet_hld_data *hdata)
> > > */
> > > static bool is_hpet_wdt_interrupt(struct hpet_hld_data *hdata)
> > > {
> > > + if (smp_processor_id() == hdata->handling_cpu) {
> > > + unsigned long tsc_curr;
> >
> > TSC is u64
>
> In x86_64, isn't u64 an unsigned long? Do you mean to consider the
> 32-bit case?
Unless none of this code is available for x86_32, you pretty much have
to consider 32bit.
But even then, using u64 for 64bit values is the right thing.
Re: [PATCH v2 5/5] riscv: Make mmap allocation top-down by default
Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH 3/4] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
On Wed, Apr 10, 2019 at 01:17:19PM +1000, Alastair D'Silva wrote:
> @@ -107,7 +108,7 @@ EXPORT_SYMBOL(bin2hex);
> * string if enough space had been available.
> */
> int hex_dump_to_buffer(const void *buf, size_t len, int rowsize, int
> groupsize,
> -char *linebuf, size_t linebuflen, bool ascii)
> +char *linebuf, size_t linebuflen, u64 flags)
> {
> const u8 *ptr = buf;
> int ngroups;
> @@ -184,7 +185,7 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
> rowsize, int groupsize,
> if (j)
> lx--;
> }
> - if (!ascii)
> + if (!flags & HEXDUMP_ASCII)
^^
This is a precedence bug. It should be if (!(flags & HEXDUMP_ASCII)).
> goto nil;
>
regards,
dan carpenter
Re: [PATCH v2 2/5] arm64, mm: Move generic mmap layout functions to mm
On Thu, Apr 04, 2019 at 01:51:25AM -0400, Alexandre Ghiti wrote: > - fix the case where stack randomization should not be taken into > account. Hmm. This sounds a bit vague. It might be better if something considered a fix is split out to a separate patch with a good description. > +config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT > + bool > + help > + This allows to use a set of generic functions to determine mmap base > + address by giving priority to top-down scheme only if the process > + is not in legacy mode (compat task, unlimited stack size or > + sysctl_legacy_va_layout). Given that this is an option that is just selected by other Kconfig options the help text won't ever be shown. I'd just move it into a comment bove the definition. > +#ifdef CONFIG_MMU > +#ifdef CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT I don't think we need the #ifdef CONFIG_MMU here, CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT should only be selected if the MMU is enabled to start with. > +#ifdef CONFIG_ARCH_HAS_ELF_RANDOMIZE > +unsigned long arch_mmap_rnd(void) Now that a bunch of architectures use a version in common code the arch_ prefix is a bit mislead. Probably not worth changing here, but some time in the future it could use a new name.
[v3 PATCH] PCI: mediatek: get optional clock by devm_clk_get_optional()
Use devm_clk_get_optional() to get optional clock
Cc: Ryder Lee
Cc: Honghui Zhang
Signed-off-by: Chunfeng Yun
Acked-by: Ryder Lee
Acked-by: Honghui Zhang
---
v3: add Acked-by Ryder and Honghui
---
drivers/pci/controller/pcie-mediatek.c | 50 --
1 file changed, 15 insertions(+), 35 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c
b/drivers/pci/controller/pcie-mediatek.c
index 0b6c72804e03..adb6cb15daa2 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -915,49 +915,29 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
/* sys_ck might be divided into the following parts in some chips */
snprintf(name, sizeof(name), "ahb_ck%d", slot);
- port->ahb_ck = devm_clk_get(dev, name);
- if (IS_ERR(port->ahb_ck)) {
- if (PTR_ERR(port->ahb_ck) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- port->ahb_ck = NULL;
- }
+ port->ahb_ck = devm_clk_get_optional(dev, name);
+ if (IS_ERR(port->ahb_ck))
+ return PTR_ERR(port->ahb_ck);
snprintf(name, sizeof(name), "axi_ck%d", slot);
- port->axi_ck = devm_clk_get(dev, name);
- if (IS_ERR(port->axi_ck)) {
- if (PTR_ERR(port->axi_ck) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- port->axi_ck = NULL;
- }
+ port->axi_ck = devm_clk_get_optional(dev, name);
+ if (IS_ERR(port->axi_ck))
+ return PTR_ERR(port->axi_ck);
snprintf(name, sizeof(name), "aux_ck%d", slot);
- port->aux_ck = devm_clk_get(dev, name);
- if (IS_ERR(port->aux_ck)) {
- if (PTR_ERR(port->aux_ck) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- port->aux_ck = NULL;
- }
+ port->aux_ck = devm_clk_get_optional(dev, name);
+ if (IS_ERR(port->aux_ck))
+ return PTR_ERR(port->aux_ck);
snprintf(name, sizeof(name), "obff_ck%d", slot);
- port->obff_ck = devm_clk_get(dev, name);
- if (IS_ERR(port->obff_ck)) {
- if (PTR_ERR(port->obff_ck) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- port->obff_ck = NULL;
- }
+ port->obff_ck = devm_clk_get_optional(dev, name);
+ if (IS_ERR(port->obff_ck))
+ return PTR_ERR(port->obff_ck);
snprintf(name, sizeof(name), "pipe_ck%d", slot);
- port->pipe_ck = devm_clk_get(dev, name);
- if (IS_ERR(port->pipe_ck)) {
- if (PTR_ERR(port->pipe_ck) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- port->pipe_ck = NULL;
- }
+ port->pipe_ck = devm_clk_get_optional(dev, name);
+ if (IS_ERR(port->pipe_ck))
+ return PTR_ERR(port->pipe_ck);
snprintf(name, sizeof(name), "pcie-rst%d", slot);
port->reset = devm_reset_control_get_optional_exclusive(dev, name);
--
2.21.0
Re: [PATCH v2 1/5] mm, fs: Move randomize_stack_top from fs to mm
Looks good, Reviewed-by: Christoph Hellwig
Re: rseq/x86: choosing rseq code signature
On Tue, Apr 09, 2019 at 04:43:42PM -0400, Mathieu Desnoyers wrote: > +/* > + * RSEQ_SIG is used with the following privileged instructions, which trap > in user-space: > + * x86-32:0f 01 3d 53 30 05 53 invlpg 0x53053053 > + * x86-64:0f 01 3d 53 30 05 53 invlpg 0x53053053(%rip) > + */ Right, and the alternative is: 0f b9 3d $SIG, which decodes to: UD1 $SIG(%rip),%edi which will trap unconditionally. The only problem is that gas will not actually assemble it, but since we're .byte coding it, it doesn't matter. UD1 is specified by both AMD and Intel to take a ModR/M, unlike UD0 where they disagree on the ModR/M.
Re: [PATCH 3/3] riscv/signal: Fixup additional syscall restarting
Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH] Staging: rtl8723bs: Remove typedef in struct sdio_data
On Tue, Apr 09, 2019 at 11:16:17AM -0500, Madhumitha Prabakaran wrote: > diff --git a/drivers/staging/rtl8723bs/include/drv_types.h > b/drivers/staging/rtl8723bs/include/drv_types.h > index bafb2c30e7fb..b0623c936940 100644 > --- a/drivers/staging/rtl8723bs/include/drv_types.h > +++ b/drivers/staging/rtl8723bs/include/drv_types.h > @@ -220,7 +220,7 @@ struct registry_priv > #define BSSID_SZ(field) sizeof(((struct wlan_bssid_ex *) 0)->field) > > #include > -#define INTF_DATA SDIO_DATA > +#define INTF_DATA struct sdio_data > Just get rid of INTF_DATA data as well. It's only used once a bit lower in the file. (Get rid of the ifdef around it). regards, dan carpenter
Re: [PATCH 2/3] clk: rockchip: Make rkpwm a critical clock on rk3288
hi,
在 2019/4/10 上午4:47, Douglas Anderson 写道:
Most rk3288-based boards are derived from the EVB and thus use a PWM
regulator for the logic rail. However, most rk3288-based boards don't
specify the PWM regulator in their device tree. We'll deal with that
by making it critical.
NOTE: it's important to make it critical and not just IGNORE_UNUSED
because all PWMs in the system share the same clock. We don't want
another PWM user to turn the clock on and off and kill the logic rail.
This change is in preparation for actually having the PWMs in the
rk3288 device tree actually point to the proper PWM clock. Up until
now they've all pointed to the clock for the old IP block and they've
all worked due to the fact that rkpwm was IGNORE_UNUSED and that the
clock rates for both clocks were the same.
Signed-off-by: Douglas Anderson
---
drivers/clk/rockchip/clk-rk3288.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 06287810474e..c3321eade23e 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -697,7 +697,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
GATE(PCLK_TZPC, "pclk_tzpc", "pclk_cpu", 0, RK3288_CLKGATE_CON(11), 3,
GFLAGS),
GATE(PCLK_UART2, "pclk_uart2", "pclk_cpu", 0, RK3288_CLKGATE_CON(11),
9, GFLAGS),
GATE(PCLK_EFUSE256, "pclk_efuse_256", "pclk_cpu", 0,
RK3288_CLKGATE_CON(11), 10, GFLAGS),
- GATE(PCLK_RKPWM, "pclk_rkpwm", "pclk_cpu", CLK_IGNORE_UNUSED,
RK3288_CLKGATE_CON(11), 11, GFLAGS),
+ GATE(PCLK_RKPWM, "pclk_rkpwm", "pclk_cpu", 0, RK3288_CLKGATE_CON(11),
11, GFLAGS),
/* ddrctrl [DDR Controller PHY clock] gates */
GATE(0, "nclk_ddrupctl0", "ddrphy", CLK_IGNORE_UNUSED,
RK3288_CLKGATE_CON(11), 4, GFLAGS),
@@ -837,6 +837,7 @@ static const char *const rk3288_critical_clocks[]
__initconst = {
"pclk_alive_niu",
"pclk_pd_pmu",
"pclk_pmu_niu",
+ "pclk_rkpwm",
pwm have device node, can enable and disable it in the pwm drivers.
pwm regulator use pwm node as:
pwms = < 0 25000 1>
when set Logic voltage:
pwm_regulator_set_voltage()
--> pwm_apply_state()
-->clk_enable()
-->pwm_enable()
-->pwm_config()
-->pinctrl_select()
--
For mark pclk_rkpwm as critical,do you have any questions, or provides
some log or more information.
};
static void __iomem *rk3288_cru_base;
Re: [PATCH 10/23] watchdog: of_xilinx_wdt: Convert to use device managed functions and other improvements
On 09. 04. 19 19:23, Guenter Roeck wrote:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
> Other improvements as listed below.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Drop assignments to otherwise unused variables
> - Drop empty remove function
> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare
> - Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatedly
> - Use devm_watchdog_register_driver() to register watchdog device
>
> Cc: Michal Simek
> Signed-off-by: Guenter Roeck
> ---
> drivers/watchdog/of_xilinx_wdt.c | 58
> ++--
> 1 file changed, 26 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/watchdog/of_xilinx_wdt.c
> b/drivers/watchdog/of_xilinx_wdt.c
> index 5c977164b3e5..03786992b701 100644
> --- a/drivers/watchdog/of_xilinx_wdt.c
> +++ b/drivers/watchdog/of_xilinx_wdt.c
> @@ -151,41 +151,46 @@ static u32 xwdt_selftest(struct xwdt_device *xdev)
> return XWT_TIMER_FAILED;
> }
>
> +static void xwdt_clk_disable_unprepare(void *data)
> +{
> + clk_disable_unprepare(data);
> +}
> +
> static int xwdt_probe(struct platform_device *pdev)
> {
> + struct device *dev = >dev;
> int rc;
> u32 pfreq = 0, enable_once = 0;
> struct xwdt_device *xdev;
> struct watchdog_device *xilinx_wdt_wdd;
>
> - xdev = devm_kzalloc(>dev, sizeof(*xdev), GFP_KERNEL);
> + xdev = devm_kzalloc(dev, sizeof(*xdev), GFP_KERNEL);
> if (!xdev)
> return -ENOMEM;
>
> xilinx_wdt_wdd = >xilinx_wdt_wdd;
> xilinx_wdt_wdd->info = _wdt_ident;
> xilinx_wdt_wdd->ops = _wdt_ops;
> - xilinx_wdt_wdd->parent = >dev;
> + xilinx_wdt_wdd->parent = dev;
>
> xdev->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(xdev->base))
> return PTR_ERR(xdev->base);
>
> - rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
> + rc = of_property_read_u32(dev->of_node, "xlnx,wdt-interval",
> >wdt_interval);
> if (rc)
> - dev_warn(>dev,
> - "Parameter \"xlnx,wdt-interval\" not found\n");
> + dev_warn(dev, "Parameter \"xlnx,wdt-interval\" not found\n");
>
> - rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
> + rc = of_property_read_u32(dev->of_node, "xlnx,wdt-enable-once",
> _once);
> if (rc)
> - dev_warn(>dev,
> + dev_warn(dev,
>"Parameter \"xlnx,wdt-enable-once\" not found\n");
>
> watchdog_set_nowayout(xilinx_wdt_wdd, enable_once);
>
> - xdev->clk = devm_clk_get(>dev, NULL);
> + xdev->clk = devm_clk_get(dev, NULL);
> if (IS_ERR(xdev->clk)) {
> if (PTR_ERR(xdev->clk) != -ENOENT)
> return PTR_ERR(xdev->clk);
> @@ -196,10 +201,10 @@ static int xwdt_probe(struct platform_device *pdev)
>*/
> xdev->clk = NULL;
>
> - rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",
> + rc = of_property_read_u32(dev->of_node, "clock-frequency",
> );
> if (rc)
> - dev_warn(>dev,
> + dev_warn(dev,
>"The watchdog clock freq cannot be
> obtained\n");
> } else {
> pfreq = clk_get_rate(xdev->clk);
> @@ -218,44 +223,34 @@ static int xwdt_probe(struct platform_device *pdev)
>
> rc = clk_prepare_enable(xdev->clk);
> if (rc) {
> - dev_err(>dev, "unable to enable clock\n");
> + dev_err(dev, "unable to enable clock\n");
> return rc;
> }
> + rc = devm_add_action_or_reset(dev, xwdt_clk_disable_unprepare,
> + xdev->clk);
> + if (rc)
> + return rc;
>
> rc = xwdt_selftest(xdev);
> if (rc == XWT_TIMER_FAILED) {
> - dev_err(>dev, "SelfTest routine error\n");
> - goto err_clk_disable;
> + dev_err(dev, "SelfTest routine error\n");
> + return rc;
> }
>
> - rc = watchdog_register_device(xilinx_wdt_wdd);
> + rc = devm_watchdog_register_device(dev, xilinx_wdt_wdd);
> if (rc) {
> - dev_err(>dev, "Cannot register watchdog (err=%d)\n", rc);
> - goto err_clk_disable;
> + dev_err(dev, "Cannot register watchdog (err=%d)\n", rc);
> + return rc;
> }
>
> clk_disable(xdev->clk);
>
> - dev_info(>dev, "Xilinx Watchdog Timer at %p with
Re: linux-next: manual merge of the staging tree with the staging.current tree
On Tue, Apr 9, 2019 at 6:40 PM Andy Shevchenko wrote: > > On Mon, Apr 08, 2019 at 01:01:51PM +0100, Jonathan Cameron wrote: > > On Mon, 8 Apr 2019 13:34:37 +0300 > > Andy Shevchenko wrote: > > > On Mon, Apr 08, 2019 at 11:14:39AM +0100, Jonathan Cameron wrote: > > > > On Mon, 8 Apr 2019 13:01:21 +0300 > > > > Andy Shevchenko wrote: > > > > > On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote: > > > > > > On Mon, 8 Apr 2019 13:02:12 +1000 > > > > > > Stephen Rothwell wrote: > > > > > > > That is the correct resolution. > > > > > > > > > > I think it still misses the following fix: > > > > > > > Is that actually a problem given it's copied over from > > > > buffer->scan_mask just after allocation? > > > > The two masks are the same length so I don't think we have a problem > > > > with this one. > > > > Am I missing something? > > > > > > Hmm... I didn't get why the commit 20ea39ef9f2f fixes anything. > > > > > Good point. I'm don't think it ever did. > > > > Alex, any thoughts? > Hey, This seems to have been in the context of our tree. We have this patch: https://github.com/analogdevicesinc/linux/commit/81d00795b1537 That removes bitmap_copy() . See here: https://github.com/analogdevicesinc/linux/commit/81d00795b1537#diff-0a87744ce945d2c1c89ea19f21fb35bbL397 This change is not upstreamed yet. I guess I am slowly going nuts with trying to sync multiple trees [ our master, upstream IIO & some internal temp-branches ]. To give a bit of background: we've noticed this weird behavior while testing a AD7193 chip with the AD7192 driver and some weird things were happening. At the time, this patch seemed easy to send upstream, so I sent it. Sorry for the noise. I guess the conclusion is, that in the context of the mainline IIO tree, commit 20ea39ef9f2f is not needed. Thanks Alex > I have a thought that it might be possible that somewhere code is still > broken, > i.e. accessing bitmap behind the size (for example, iterating by unsigned long > without bitmap size being aligned to size of unsigned long). > > If this is a case, the mentioned patch has a symptomatic healing and not > fixing > a root cause. > > -- > With Best Regards, > Andy Shevchenko > >
linux-next: Tree for Apr 10
Hi all, Changes since 20190409: The printk tree gained conflicts against Linus' tree. The drm tree still had its build failure for which I disabled a driver. The drm-misc tree still had its build failure for which I marked a driver as BROKEN. The scsi tree inherited a build failure form the scsi-mkp tree for which I reverted a commit. Non-merge commits (relative to Linus' tree): 5793 5700 files changed, 183935 insertions(+), 90633 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 298 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (869e3305f23d Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (15ade5d2e777 Linux 5.1-rc4) Merging kspp-gustavo/for-next/kspp (a01bcfd6990d NFC: st21nfca: Fix fall-through warnings) Merging kbuild-current/fixes (79a3aaa7b82e Linux 5.1-rc3) Merging arc-current/for-curr (55c0c4c793b5 ARC: memset: fix build with L1_CACHE_SHIFT != 6) Merging arm-current/fixes (d410a8a49e3e ARM: 8849/1: NOMMU: Fix encodings for PMSAv8's PRBAR4/PRLAR4) Merging arm64-fixes/for-next/fixes (1e6f5440a681 arm64: backtrace: Don't bother trying to unwind the userspace stack) Merging m68k-current/for-linus (28713169d879 m68k: Add -ffreestanding to CFLAGS) Merging powerpc-fixes/fixes (dd9a994fc68d powerpc/vdso32: fix CLOCK_MONOTONIC on PPC64) Merging sparc/master (7d762d69145a afs: Fix manually set volume location server list) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (c03fd0171ba6 Merge tag 'mac80211-for-davem-2019-04-09' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging bpf/master (bbd669a868bb ibmvnic: Fix completion structure initialization) Merging ipsec/master (8742dc86d0c7 xfrm4: Fix uninitialized memory read in _decode_session4) Merging netfilter/master (b1a6e8f91313 MAINTAINERS: ieee802154: update documentation file pattern) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (4837696f6b54 Merge tag 'iwlwifi-for-kalle-2019-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (78ad2341521d mac80211: Honor SW_CRYPTO_CONTROL for unicast keys in AP VLAN mode) Merging rdma-fixes/for-rc (00fb67ec6b98 RDMA/hns: Bugfix for SCC hem free) Merging sound-current/for-linus (cae30527901d ALSA: hda - Add two more machines to the power_save_blacklist) Merging sound-asoc-fixes/for-linus (f94d9457b2ea Merge branch 'asoc-5.1' into asoc-linus) Merging regmap-fixes/for-linus (34fd5ecd01f0 Merge branch 'regmap-5.1' into regmap-linus) Merging regulator-fixes/for-linus (37654b55d953 Merge branch 'regulator-5.1' into regulator-linus) Merging spi-fixes/for-linus (ee284f8d2c31 Merge branch 'spi-5.1' into spi-linus) Merging pci-current/for-linus (9cde402a5977 PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller) Merging driver-core.current/driver-core-linus (79a3aaa7b82e Linux 5.1-rc3) Merging tty.current/tty-linus (79a3aaa7b82e Linux 5.1-rc3) Merging usb.current/usb-linus (79a3aaa7b82e Linux 5.1-rc3) Merging usb-gadget-fixes/fixes (072684e8c58d USB: gadget: f_hid: fix deadlock in f_hidg_write()) Merging usb-serial-fixes/usb-linus
Re: [PATCH v2 2/4] opp: add API which get max freq by voltage
On 29-03-19, 14:46, Andrew-sh.Cheng wrote:
> This API will get voltage as input parameter.
> Search all opp items for the item which with max frequency,
> and the voltae is smaller than provided voltage.
>
> Signed-off-by: Andrew-sh.Cheng
> ---
> drivers/opp/core.c | 55
> ++
> include/linux/pm_opp.h | 8
> 2 files changed, 63 insertions(+)
I have applied this patch with some modifications, here is the diff:
---
drivers/opp/core.c | 29 ++---
include/linux/pm_opp.h | 8
2 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 7323cd9aabf9..0e7703fe733f 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -527,31 +527,30 @@ struct dev_pm_opp *dev_pm_opp_find_freq_floor(struct
device *dev,
EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_floor);
/**
- * dev_pm_opp_find_max_freq_by_volt() - Search for a opp with max freq
- * under provided voltage
- * @dev: device for which we do this operation
- * @u_volt:provided voltage
+ * dev_pm_opp_find_freq_ceil_by_volt() - Find OPP with highest frequency for
+ * target voltage.
+ * @dev: Device for which we do this operation.
+ * @u_volt:Target voltage.
+ *
+ * Search for OPP with highest (ceil) frequency and has voltage <= u_volt.
*
- * Search for the matching available OPP which provide voltage can support.
+ * Return: matching *opp, else returns ERR_PTR in case of error which should be
+ * handled using IS_ERR.
*
- * Return: matching *opp, else returns ERR_PTR in case of error
- * and should be handled using IS_ERR.
* Error return values can be:
- * EINVAL: for bad pointer
- * ERANGE: no match found for search
- * ENODEV: if device not found in list of registered devices
+ * EINVAL: bad parameters
*
* The callers are required to call dev_pm_opp_put() for the returned OPP after
* use.
*/
-struct dev_pm_opp *dev_pm_opp_find_max_freq_by_volt(struct device *dev,
- unsigned long u_volt)
+struct dev_pm_opp *dev_pm_opp_find_freq_ceil_by_volt(struct device *dev,
+unsigned long u_volt)
{
struct opp_table *opp_table;
struct dev_pm_opp *temp_opp, *opp = ERR_PTR(-ERANGE);
if (!dev || !u_volt) {
- dev_err(dev, "%s: Invalid argument volt=%d\n", __func__,
+ dev_err(dev, "%s: Invalid argument volt=%lu\n", __func__,
u_volt);
return ERR_PTR(-EINVAL);
}
@@ -564,7 +563,6 @@ struct dev_pm_opp *dev_pm_opp_find_max_freq_by_volt(struct
device *dev,
list_for_each_entry(temp_opp, _table->opp_list, node) {
if (temp_opp->available) {
- /* go to the next node, before choosing prev */
if (temp_opp->supplies[0].u_volt > u_volt)
break;
opp = temp_opp;
@@ -574,12 +572,13 @@ struct dev_pm_opp
*dev_pm_opp_find_max_freq_by_volt(struct device *dev,
/* Increment the reference count of OPP */
if (!IS_ERR(opp))
dev_pm_opp_get(opp);
+
mutex_unlock(_table->lock);
dev_pm_opp_put_opp_table(opp_table);
return opp;
}
-EXPORT_SYMBOL_GPL(dev_pm_opp_find_max_freq_by_volt);
+EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_ceil_by_volt);
static int _set_opp_voltage(struct device *dev, struct regulator *reg,
struct dev_pm_opp_supply *supply)
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 57deef9cf5d3..b150fe97ce5a 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -102,8 +102,8 @@ struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device
*dev,
struct dev_pm_opp *dev_pm_opp_find_freq_floor(struct device *dev,
unsigned long *freq);
-struct dev_pm_opp *dev_pm_opp_find_max_freq_by_volt(struct device *dev,
- unsigned long u_volt);
+struct dev_pm_opp *dev_pm_opp_find_freq_ceil_by_volt(struct device *dev,
+unsigned long u_volt);
struct dev_pm_opp *dev_pm_opp_find_freq_ceil(struct device *dev,
unsigned long *freq);
@@ -209,8 +209,8 @@ static inline struct dev_pm_opp
*dev_pm_opp_find_freq_floor(struct device *dev,
return ERR_PTR(-ENOTSUPP);
}
-static inline struct dev_pm_opp *dev_pm_opp_find_max_freq_by_volt(struct
device *dev,
- unsigned long u_volt)
+static inline struct dev_pm_opp *dev_pm_opp_find_freq_ceil_by_volt(struct
device *dev,
+ unsigned long u_volt)
{
return ERR_PTR(-ENOTSUPP);
}
Re: [PATCH ghak10 v7 2/2] ntp: Audit NTP parameters adjustment
On Tue, 9 Apr 2019, Ondrej Mosnacek wrote:
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 2c62c046..1c372ad7ebe9 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -86,6 +86,26 @@ struct audit_field {
> u32 op;
> };
>
> +#define AUDIT_NTP_OFFSET 0
> +#define AUDIT_NTP_FREQ 1
> +#define AUDIT_NTP_STATUS 2
> +#define AUDIT_NTP_TAI3
> +#define AUDIT_NTP_TICK 4
> +#define AUDIT_NTP_ADJUST 5
> +#define AUDIT_NTP_NVALS 6 /* count */
That should be an named enum and the id argument should be the same type.
> @@ -720,14 +721,29 @@ int __do_adjtimex(struct __kernel_timex *txc, const
> struct timespec64 *ts,
> /* adjtime() is independent from ntp_adjtime() */
> time_adjust = txc->offset;
> ntp_update_frequency();
> +
> + audit_ntp_set_old(ad, AUDIT_NTP_ADJUST, save_adjust);
> + audit_ntp_set_new(ad, AUDIT_NTP_ADJUST, time_adjust);
> }
> txc->offset = save_adjust;
> } else {
> -
> /* If there are input parameters, then process them: */
> - if (txc->modes)
> + if (txc->modes) {
> + audit_ntp_set_old(ad, AUDIT_NTP_OFFSET, time_offset);
> + audit_ntp_set_old(ad, AUDIT_NTP_FREQ, time_freq);
> + audit_ntp_set_old(ad, AUDIT_NTP_STATUS, time_status);
> + audit_ntp_set_old(ad, AUDIT_NTP_TAI,*time_tai);
> + audit_ntp_set_old(ad, AUDIT_NTP_TICK, tick_usec);
> +
> process_adjtimex_modes(txc, time_tai);
>
> + audit_ntp_set_new(ad, AUDIT_NTP_OFFSET, time_offset);
> + audit_ntp_set_new(ad, AUDIT_NTP_FREQ, time_freq);
> + audit_ntp_set_new(ad, AUDIT_NTP_STATUS, time_status);
> + audit_ntp_set_new(ad, AUDIT_NTP_TAI,*time_tai);
> + audit_ntp_set_new(ad, AUDIT_NTP_TICK, tick_usec);
> + }
Yes, that looks much more palatable! Nice work!
With the above addressed:
Reviewed-by: Thomas Gleixner
Re: [PATCH 1/3] Revert "clk: rockchip: mark noc and some special clk as critical on rk3288"
hi,
在 2019/4/10 上午4:47, Douglas Anderson 写道:
This reverts commit 55bb6a633c33caf68ab470907ecf945289cb733d.
The clocks that were enabled by that patch are pretty questionable.
Specifically looking at what has been shipping on rk3288-veyron
Chromebooks almost all of these clocks are safely turned off and cause
no apparent problems. If some boards need these clocks turned on for
some reason then it seems like we should figure out how to do that at
a board level.
NOTE: turning these clocks off doesn't seem to do a whole lot in terms
of power savings (checking the power on the logic rail). It appears
to save maybe 1-2mW. ...but still it seems like we should turn the
clocks off if they aren't needed.
Digging into the clocks here to describe why they shouldn't need to be
left on:
atclk: No documentation about this clock other than that it goes to
the CPU. CPU functions fine without it on.
jtag: Presumably this clock is only needed if you're debugging with
JTAG. It doesn't seem like it makes sense to waste power for every
rk3288 user. Perhaps this could be turned on with a CONFIG option?
pclk_dbg, pclk_core_niu: On veyron Chromebooks we turn these two
clocks on only during kernel panics in order to access some coresight
registers. Since nothing in the upstream kernel does this we should
be able to leave them off safely.
hsicphy12m_xin12m: There is no indication of why this clock would need
to be turned on for boards that don't use HSIC.
pclk_ddrupctl[0-1], pclk_publ0[0-1]: On veyron Chromebooks we turn
these 4 clocks on only when doing DDR transitions and they are off
otherwise. I see no reason why they'd need to be on in the upstream
kernel which doesn't support DDRFreq.
pmu_hclk_otg0: A "chip design defect" is mentioned in the original
patch but no details. This clock has always been gated in shipping
veyron Chromebooks so presumably this chip defect doesn't affect all
boards.
Signed-off-by: Douglas Anderson
---
drivers/clk/rockchip/clk-rk3288.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 5a67b7869960..06287810474e 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -313,13 +313,13 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
COMPOSITE_NOMUX(0, "aclk_core_mp", "armclk", CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(0), 4, 4, DFLAGS |
CLK_DIVIDER_READ_ONLY,
RK3288_CLKGATE_CON(12), 6, GFLAGS),
- COMPOSITE_NOMUX(0, "atclk", "armclk", CLK_IGNORE_UNUSED,
+ COMPOSITE_NOMUX(0, "atclk", "armclk", 0,
RK3288_CLKSEL_CON(37), 4, 5, DFLAGS |
CLK_DIVIDER_READ_ONLY,
RK3288_CLKGATE_CON(12), 7, GFLAGS),
COMPOSITE_NOMUX(0, "pclk_dbg_pre", "armclk", CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(37), 9, 5, DFLAGS |
CLK_DIVIDER_READ_ONLY,
RK3288_CLKGATE_CON(12), 8, GFLAGS),
- GATE(0, "pclk_dbg", "pclk_dbg_pre", CLK_IGNORE_UNUSED,
+ GATE(0, "pclk_dbg", "pclk_dbg_pre", 0,
RK3288_CLKGATE_CON(12), 9, GFLAGS),
GATE(0, "cs_dbg", "pclk_dbg_pre", CLK_IGNORE_UNUSED,
RK3288_CLKGATE_CON(12), 10, GFLAGS),
@@ -647,7 +647,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
INVERTER(SCLK_HSADC, "sclk_hsadc", "sclk_hsadc_out",
RK3288_CLKSEL_CON(22), 7, IFLAGS),
- GATE(0, "jtag", "ext_jtag", CLK_IGNORE_UNUSED,
+ GATE(0, "jtag", "ext_jtag", 0,
RK3288_CLKGATE_CON(4), 14, GFLAGS),
CLK_IGNORE_UNUSED:
Whether to close the unused clk after clk init complete. not affect
there own enable/disable.
JTAG is not have device node, when need jtag to debug, may be the system
is crashed, there is no way to turn on this clk.
COMPOSITE_NODIV(SCLK_USBPHY480M_SRC, "usbphy480m_src", mux_usbphy480m_p, 0,
@@ -656,7 +656,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
COMPOSITE_NODIV(SCLK_HSICPHY480M, "sclk_hsicphy480m",
mux_hsicphy480m_p, 0,
RK3288_CLKSEL_CON(29), 0, 2, MFLAGS,
RK3288_CLKGATE_CON(3), 6, GFLAGS),
- GATE(0, "hsicphy12m_xin12m", "xin12m", CLK_IGNORE_UNUSED,
+ GATE(0, "hsicphy12m_xin12m", "xin12m", 0,
RK3288_CLKGATE_CON(13), 9, GFLAGS),
DIV(0, "hsicphy12m_usbphy", "sclk_hsicphy480m", 0,
RK3288_CLKSEL_CON(11), 8, 6, DFLAGS),
@@ -837,12 +837,6 @@ static const char *const rk3288_critical_clocks[]
__initconst = {
"pclk_alive_niu",
"pclk_pd_pmu",
"pclk_pmu_niu",
- "pclk_core_niu",
- "pclk_ddrupctl0",
- "pclk_publ0",
- "pclk_ddrupctl1",
- "pclk_publ1",
These clks needed enable, device node not use this clk, so we mark it as
[PATCH] csky: Fixup wrong update_mmu_cache implementation
From: Guo Ren
In our stress test, we found some crash problem caused by:
if (!(vma->vm_flags & VM_EXEC))
return;
in update_mmu_cache().
Seems current update_mmu_cache implementation is wrong and we retread
to the conservative implementation.
Also the usage of kmap_atomic in update_mmu_cache is risky, page-virtual
may be scheduled out and changed, so we must use preempt_disable &
pagefault_disable which is called by kmap_atomic().
Signed-off-by: Guo Ren
Cc: Arnd Bergmann
---
arch/csky/abiv2/cacheflush.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/csky/abiv2/cacheflush.c b/arch/csky/abiv2/cacheflush.c
index d22c95f..5bb887b 100644
--- a/arch/csky/abiv2/cacheflush.c
+++ b/arch/csky/abiv2/cacheflush.c
@@ -34,10 +34,6 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned
long address,
{
unsigned long addr, pfn;
struct page *page;
- void *va;
-
- if (!(vma->vm_flags & VM_EXEC))
- return;
pfn = pte_pfn(*pte);
if (unlikely(!pfn_valid(pfn)))
@@ -47,14 +43,9 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned
long address,
if (page == ZERO_PAGE(0))
return;
- va = page_address(page);
- addr = (unsigned long) va;
-
- if (va == NULL && PageHighMem(page))
- addr = (unsigned long) kmap_atomic(page);
+ addr = (unsigned long) kmap_atomic(page);
cache_wbinv_range(addr, addr + PAGE_SIZE);
- if (va == NULL && PageHighMem(page))
- kunmap_atomic((void *) addr);
+ kunmap_atomic((void *) addr);
}
--
2.7.4
[PATCH V2] csky: Add perf_arch_fetch_caller_regs support
From: Mao Han
In trace events as tracepoints context are not able to
be retrieve with task_pt_regs. Without arch caller regs
support the pt_regs context will be all zero, perf can
not parsing the callchain and resolving the symbols
correctly, some time will even get into deadlock
while handling the page fault, eg:
perf kmem —page record ls
Changelog
- Add test case cmd in comment
- Use regs_fp(regs) which is defined in abi/regdef.h
Signed-off-by: Mao Han
Signed-off-by: Guo Ren
---
arch/csky/abiv1/inc/abi/regdef.h | 1 +
arch/csky/abiv2/inc/abi/regdef.h | 1 +
arch/csky/include/asm/perf_event.h | 8
3 files changed, 10 insertions(+)
diff --git a/arch/csky/abiv1/inc/abi/regdef.h b/arch/csky/abiv1/inc/abi/regdef.h
index 729b1c3..104707f 100644
--- a/arch/csky/abiv1/inc/abi/regdef.h
+++ b/arch/csky/abiv1/inc/abi/regdef.h
@@ -6,6 +6,7 @@
#define syscallid r1
#define regs_syscallid(regs) regs->regs[9]
+#define regs_fp(regs) regs->regs[2]
/*
* PSR format:
diff --git a/arch/csky/abiv2/inc/abi/regdef.h b/arch/csky/abiv2/inc/abi/regdef.h
index 77cb178..d7328bb 100644
--- a/arch/csky/abiv2/inc/abi/regdef.h
+++ b/arch/csky/abiv2/inc/abi/regdef.h
@@ -6,6 +6,7 @@
#define syscallid r7
#define regs_syscallid(regs) regs->regs[3]
+#define regs_fp(regs) regs->regs[4]
/*
* PSR format:
diff --git a/arch/csky/include/asm/perf_event.h
b/arch/csky/include/asm/perf_event.h
index ea81931..572093e 100644
--- a/arch/csky/include/asm/perf_event.h
+++ b/arch/csky/include/asm/perf_event.h
@@ -4,4 +4,12 @@
#ifndef __ASM_CSKY_PERF_EVENT_H
#define __ASM_CSKY_PERF_EVENT_H
+#include
+
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+ (regs)->pc = (__ip); \
+ regs_fp(regs) = (unsigned long) __builtin_frame_address(0); \
+ asm volatile("mov %0, sp\n":"=r"((regs)->usp)); \
+}
+
#endif /* __ASM_PERF_EVENT_ELF_H */
--
2.7.4
[v2 PATCH 3/4] phy: socionext: get optional clock by devm_clk_get_optional()
Use devm_clk_get_optional() to get optional clock
Cc: Kunihiko Hayashi
Signed-off-by: Chunfeng Yun
Reviewed-by: Kunihiko Hayashi
---
v2: add Reviewed-by Kunihiko Hayashi
---
drivers/phy/socionext/phy-uniphier-usb3hs.c | 10 +++---
drivers/phy/socionext/phy-uniphier-usb3ss.c | 10 +++---
2 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/phy/socionext/phy-uniphier-usb3hs.c
b/drivers/phy/socionext/phy-uniphier-usb3hs.c
index b1b048be6166..50f379fc4e06 100644
--- a/drivers/phy/socionext/phy-uniphier-usb3hs.c
+++ b/drivers/phy/socionext/phy-uniphier-usb3hs.c
@@ -335,13 +335,9 @@ static int uniphier_u3hsphy_probe(struct platform_device
*pdev)
if (IS_ERR(priv->clk_parent))
return PTR_ERR(priv->clk_parent);
- priv->clk_ext = devm_clk_get(dev, "phy-ext");
- if (IS_ERR(priv->clk_ext)) {
- if (PTR_ERR(priv->clk_ext) == -ENOENT)
- priv->clk_ext = NULL;
- else
- return PTR_ERR(priv->clk_ext);
- }
+ priv->clk_ext = devm_clk_get_optional(dev, "phy-ext");
+ if (IS_ERR(priv->clk_ext))
+ return PTR_ERR(priv->clk_ext);
priv->rst = devm_reset_control_get_shared(dev, "phy");
if (IS_ERR(priv->rst))
diff --git a/drivers/phy/socionext/phy-uniphier-usb3ss.c
b/drivers/phy/socionext/phy-uniphier-usb3ss.c
index 4be95679c7d8..ec231e40ef2a 100644
--- a/drivers/phy/socionext/phy-uniphier-usb3ss.c
+++ b/drivers/phy/socionext/phy-uniphier-usb3ss.c
@@ -238,13 +238,9 @@ static int uniphier_u3ssphy_probe(struct platform_device
*pdev)
if (IS_ERR(priv->clk))
return PTR_ERR(priv->clk);
- priv->clk_ext = devm_clk_get(dev, "phy-ext");
- if (IS_ERR(priv->clk_ext)) {
- if (PTR_ERR(priv->clk_ext) == -ENOENT)
- priv->clk_ext = NULL;
- else
- return PTR_ERR(priv->clk_ext);
- }
+ priv->clk_ext = devm_clk_get_optional(dev, "phy-ext");
+ if (IS_ERR(priv->clk_ext))
+ return PTR_ERR(priv->clk_ext);
priv->rst = devm_reset_control_get_shared(dev, "phy");
if (IS_ERR(priv->rst))
--
2.21.0
[v2 PATCH 4/4] phy: phy-meson-gxl-usb2: get optional clock by devm_clk_get_optional()
Use devm_clk_get_optional() to get optional clock
Cc: Martin Blumenstingl
Signed-off-by: Chunfeng Yun
Acked-by: Martin Blumenstingl
---
v2: add Acked-by Martin Blumenstingl
---
drivers/phy/amlogic/phy-meson-gxl-usb2.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/phy/amlogic/phy-meson-gxl-usb2.c
b/drivers/phy/amlogic/phy-meson-gxl-usb2.c
index 148ef0bdb9c1..4cbee412f2b0 100644
--- a/drivers/phy/amlogic/phy-meson-gxl-usb2.c
+++ b/drivers/phy/amlogic/phy-meson-gxl-usb2.c
@@ -261,14 +261,9 @@ static int phy_meson_gxl_usb2_probe(struct platform_device
*pdev)
if (IS_ERR(priv->regmap))
return PTR_ERR(priv->regmap);
- priv->clk = devm_clk_get(dev, "phy");
- if (IS_ERR(priv->clk)) {
- ret = PTR_ERR(priv->clk);
- if (ret == -ENOENT)
- priv->clk = NULL;
- else
- return ret;
- }
+ priv->clk = devm_clk_get_optional(dev, "phy");
+ if (IS_ERR(priv->clk))
+ return PTR_ERR(priv->clk);
priv->reset = devm_reset_control_get_optional_shared(dev, "phy");
if (IS_ERR(priv->reset))
--
2.21.0
[v2 PATCH 2/4] phy: qcom-qusb2: get optional clock by devm_clk_get_optional()
Use devm_clk_get_optional() to get optional clock
Cc: Andy Gross
Cc: David Brown
Cc: Vivek Gautam
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/phy/qualcomm/phy-qcom-qusb2.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 8fd7ce139772..1cbf1d6f28ce 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -822,14 +822,9 @@ static int qusb2_phy_probe(struct platform_device *pdev)
return ret;
}
- qphy->iface_clk = devm_clk_get(dev, "iface");
- if (IS_ERR(qphy->iface_clk)) {
- ret = PTR_ERR(qphy->iface_clk);
- if (ret == -EPROBE_DEFER)
- return ret;
- qphy->iface_clk = NULL;
- dev_dbg(dev, "failed to get iface clk, %d\n", ret);
- }
+ qphy->iface_clk = devm_clk_get_optional(dev, "iface");
+ if (IS_ERR(qphy->iface_clk))
+ return PTR_ERR(qphy->iface_clk);
qphy->phy_reset = devm_reset_control_get_by_index(>dev, 0);
if (IS_ERR(qphy->phy_reset)) {
--
2.21.0
[v2 PATCH 1/4] phy: phy-mtk-tphy: get optional clock by devm_clk_get_optional()
Use devm_clk_get_optional() to get optional clock
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/phy/mediatek/phy-mtk-tphy.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 5b6a470ca145..cb2ed3b25068 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -1103,13 +1103,9 @@ static int mtk_tphy_probe(struct platform_device *pdev)
}
/* it's deprecated, make it optional for backward compatibility */
- tphy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
- if (IS_ERR(tphy->u3phya_ref)) {
- if (PTR_ERR(tphy->u3phya_ref) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- tphy->u3phya_ref = NULL;
- }
+ tphy->u3phya_ref = devm_clk_get_optional(dev, "u3phya_ref");
+ if (IS_ERR(tphy->u3phya_ref))
+ return PTR_ERR(tphy->u3phya_ref);
tphy->src_ref_clk = U3P_REF_CLK;
tphy->src_coef = U3P_SLEW_RATE_COEF;
--
2.21.0
Re: [PATCH 09/10] PCI: tegra: Add Tegra194 PCIe support
On 4/9/2019 6:56 PM, Bjorn Helgaas wrote:
On Tue, Apr 09, 2019 at 05:00:53PM +0530, Vidya Sagar wrote:
On 4/6/2019 12:28 AM, Bjorn Helgaas wrote:
On Fri, Apr 05, 2019 at 01:23:51AM +0530, Vidya Sagar wrote:
On 4/3/2019 11:06 PM, Bjorn Helgaas wrote:
On Wed, Apr 03, 2019 at 03:13:09PM +0530, Vidya Sagar wrote:
On 4/3/2019 12:01 AM, Bjorn Helgaas wrote:
On Tue, Apr 02, 2019 at 12:47:48PM +0530, Vidya Sagar wrote:
On 3/30/2019 2:22 AM, Bjorn Helgaas wrote:
On Tue, Mar 26, 2019 at 08:43:26PM +0530, Vidya Sagar wrote:
Add support for Synopsys DesignWare core IP based PCIe host controller
present in Tegra194 SoC.
- Why does this chip require pcie_pme_disable_msi()? The only other
use is a DMI quirk for "MSI Wind U-100", added by c39fae1416d5
("PCI PM: Make it possible to force using INTx for PCIe PME
signaling").
Because Tegra194 doesn't support raising PME interrupts through MSI line.
There's something wrong here. Either the question of how PME is
signaled is generic and the spec provides a way for the OS to discover
that method, or it's part of the device-specific architecture that
each host bridge driver has to know about its device. If the former,
we need to make the PCI core smart enough to figure it out. If the
latter, we need a better interface than this ad hoc
pcie_pme_disable_msi() thing. But if it is truly the latter, your
current code is sufficient and we can refine it over time.
In case of Tegra194, it is the latter case.
This isn't a Tegra194 question; it's a question of whether this
behavior is covered by the PCIe spec.
AFAIU the spec and what I heard from Nvidia hardware folks is that spec doesn't
explicitly talk about this and it was a design choice made by Nvidia hardware
folks to route these interrupts through legacy line instead of MSI line.
What I suspect should happen eventually is the DWC driver should call
devm_pci_alloc_host_bridge() directly, as all the non-DWC drivers do.
That would require a little reorganization of the DWC data structures,
but it would be good to be more consistent.
For now, I think stashing the pointer in pcie_port or dw_pcie would be
OK. I'm not 100% clear on the difference, but it looks like either
should be common across all the DWC drivers, which is what we want.
Since dw_pcie is common for both root port and end point mode structures,
I think it makes sense to keep the pointer in pcie_port as this structure
is specific to root port mode of operation.
I'll make a note to reorganize code to have devm_pci_alloc_host_bridge()
used in the beginning itself to be inline with non-DWC implementations.
But, I'll take it up later (after I'm done with upstreaming current series)
Fair enough.
.remove() internally calls pm_runtime_put_sync() API which calls
.runtime_suspend(). I made a new patch to add a host_deinit() call
which make all these calls. Since host_init() is called from inside
.runtime_resume() of this driver, to be in sync, I'm now calling
host_deinit() from inside .runtime_suspend() API.
I think this is wrong. pci_stop_root_bus() will detach all the
drivers from all the devices. We don't want to do that if we're
merely runtime suspending the host bridge, do we?
In the current driver, the scenarios in which .runtime_suspend() is called
are
a) during .remove() call and
It makes sense that you should call pci_stop_root_bus() during
.remove(), i.e., when the host controller driver is being removed,
because the PCI bus will no longer be accessible. I think you should
call it *directly* from tegra_pcie_dw_remove() because that will match
what other drivers do.
b) when there is no endpoint found and controller would be shutdown
In both cases, it is required to stop the root bus and remove all devices,
so, instead of having same call present in respective paths, I kept them
in .runtime_suspend() itself to avoid code duplication.
I don't understand this part. We should be able to runtime suspend
the host controller without detaching drivers for child devices.
If you shutdown the controller completely and detach the *host
controller driver*, sure, it makes sense to detach drivers from child
devices. But that would be handled by the host controller .remove()
method, not by the runtime suspend method.
I think it is time I give some background about why I chose to implement
.runtime_suspend() and .runtime_resume() APIs in the first place. We wanted to
powerdown PCIe controller if there is no link up (i.e. slot is open and no
endpoint
devices are connected). We want to achieve this without returning a failure in
.probe() call. Given PCIe IP power partitioning is handled by generic power
domain
framework, power partition gets unpowergated before .probe() gets called and
gets
powergated either when a failure is returned in .probe() or when
pm_runtime_put_sync()
is called. So, I chose to call pm_runtime_put_sync() in no-link-up scenario and
chose
to implement .runtime_suspend() to
Re: [PATCH 1/3] RISC-V: Add separate defconfig for 32bit systems
On Tue, Apr 9, 2019 at 10:14 PM Palmer Dabbelt wrote: > > On Tue, 12 Mar 2019 15:08:12 PDT (-0700), Anup Patel wrote: > > This patch adds rv32_defconfig for 32bit systems. The only > > difference between rv32_defconfig and defconfig is that > > rv32_defconfig has CONFIG_ARCH_RV32I=y. > > Thanks. I think it makes sense to have this in 5.1 so I'm going to take it > into the next RC. Thanks, Palmer. Can you consider "[PATCH v3] RISC-V: Fix Maximum Physical Memory 2GiB option for 64bit systems" for 5.1? Refer, https://patchwork.kernel.org/patch/10886895/ The above patch is also required for 64bit system with more than 128GiB memory (i.e. server-class system). We can remove "Maximum Physical Memory 2GiB" option as separate patch. Regards, Anup
Re: [External] Re: Basics : Memory Configuration
From: Christopher Lameter Sent: 09 April 2019 21:31 To: Pankaj Suryawanshi Cc: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: [External] Re: Basics : Memory Configuration On Tue, 9 Apr 2019, Pankaj Suryawanshi wrote: > I am confuse about memory configuration and I have below questions Hmmm... Yes some of the terminology that you use is a bit confusing. > 1. if 32-bit os maximum virtual address is 4GB, When i have 4 gb of ram > for 32-bit os, What about the virtual memory size ? is it required > virtual memory(disk space) or we can directly use physical memory ? The virtual memory size is the maximum virtual size of a single process. Multiple processes can run and each can use different amounts of physical memory. So both are actually independent. The size of the virtual memory space per process is configurable on x86 32 bit (2G, 3G, 4G). Thus the possible virtual process size may vary depending on the hardware architecture and the configuration of the kernel. If i have configures VMSPLIT = 2G/2G what does it mean ? Virtual memory uses disk space ? let say for 32-bit os i have 4GB ram than what is the use case of virtual memory ? If i have 32-bit and 2gb/3gb ram than virtual memory is useful because its less than 4GB ? > 2. In 32-bit os 12 bits are offset because page size=4k i.e 2^12 and > 2^20 for page addresses >What about 64-bit os, What is offset size ? What is page size ? How it > calculated. 12 bits are passed through? Thats what you mean? The remainder of the bits are used to lookup the physical frame number(PFN) in the page tables. 64 bit is the same. However, the number of bits used for lookups in the page tables are much higher. for 32-bit os page size is 4k, what is the page size for 64-bit os ? page size and offset is related to each other ? if i increase the page size from 4k to 8k, does it change the offset size that it 2^12 to 2^13 ? Why only 48 bits are used in 64-bit os ? > 3. What is PAE? If enabled how to decide size of PAE, what is maximum > and minimum size of extended memory. PAE increases the physical memory size that can be addressed through a page table lookup. The number of bits that can be specified in the PFN is increased and thus more than 4GB of physical memory can be used by the operating system. However, the virtual memory size stays the same and an individual process still cannot use more memory. Let say i have ,enabled PAE for 32-bit os with 6GB ram.Virtual size is same 4GB, 32-bit os cant address more thatn 4gb, Than what is the use of 6GB with PAE enabled. * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
RE: [EXT] Re: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal binding
Hi, Rui/Eduardo I just sent out a V11 patch series following Rob's suggestion, please help review it. So if the HW resource ID can be as phandle's argument, then go with V11 patch series, if it MUST be virtual ID starting from 0-N, then pick V10 patch series. Thanks for your time. Best Regards! Anson Huang > -Original Message- > From: Zhang Rui [mailto:rui.zh...@intel.com] > Sent: 2019年4月9日 15:29 > To: Anson Huang ; Rob Herring ; > edubez...@gmail.com > Cc: mark.rutl...@arm.com; shawn...@kernel.org; > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com; > catalin.mari...@arm.com; will.dea...@arm.com; > daniel.lezc...@linaro.org; Aisheng Dong ; > ulf.hans...@linaro.org; sb...@kernel.org; Daniel Baluta > ; Andy Gross ; > horms+rene...@verge.net.au; he...@sntech.de; a...@arndb.de; > maxime.rip...@bootlin.com; bjorn.anders...@linaro.org; > ja...@amarulasolutions.com; enric.balle...@collabora.com; > marc.w.gonza...@free.fr; o...@lixom.net; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > p...@vger.kernel.org; dl-linux-imx > Subject: [EXT] Re: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal binding > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > On 二, 2019-04-09 at 05:28 +, Anson Huang wrote: > > Ping... > > Can anyone provide some suggestion about how to proceed next? > > > Hi, Eduardo, > > I guess you will comment on this patch, right? > Or else I will take the patch following Rob' suggestion. > > thanks, > rui > > > > Best Regards! > > Anson Huang > > > > > > > > -Original Message- > > > From: Anson Huang > > > Sent: 2019年3月26日 10:45 > > > To: 'Rob Herring' ; 'edubez...@gmail.com' > > > > > > Cc: 'mark.rutl...@arm.com' ; > > > 'shawn...@kernel.org' ; > 's.hauer@pengutronix.d > > > e' > > > ; 'ker...@pengutronix.de' > > > ; 'feste...@gmail.com' > ; > > > 'catalin.mari...@arm.com' ; > > > 'will.dea...@arm.com' ; 'rui.zh...@intel.com' > > > ; 'edubez...@gmail.com' > ; > > > 'daniel.lezc...@linaro.org' ; Aisheng > > > Dong ; 'ulf.hans...@linaro.org' > > > ; 'sb...@kernel.org' ; > > > Daniel Baluta ; Andy Gross > > > ; 'horms+rene...@verge.net.au' > > > ; 'he...@sntech.de' ; > > > 'a...@arndb.de' > > >; > > > 'maxime.rip...@bootlin.com' ; > > > 'bjorn.anders...@linaro.org' ; > > > 'ja...@amarulasolutions.com' ; > > > 'enric.balle...@collabora.com' ; > > > 'marc.w.gonza...@free.fr' ; 'o...@lixom.ne > > > t' > > > ; 'devicet...@vger.kernel.org' > > > ; 'linux-kernel@vger.kernel.org' > > > > > ker...@vger.kernel.org>; 'linux-arm-ker...@lists.infradead.org' > > > > > ker...@lists.infradead.org>; 'linux...@vger.kernel.org' > > p...@vger.kernel.org>; dl-linux-imx > > > Subject: RE: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal > > > binding > > > > > > Ping... > > > > > > Hi, Eduardo > > > What is your opinion about where to put the HW resource ID in > > > DT? > > > > > > Best Regards! > > > Anson Huang > > > > > > > > > > > -Original Message- > > > > From: Anson Huang > > > > Sent: 2019年3月13日 16:12 > > > > To: 'Rob Herring' ; 'edubez...@gmail.com' > > > > > > > > Cc: 'mark.rutl...@arm.com' ; > > > > 'shawn...@kernel.org' ; > > > 's.ha...@pengutronix.de' > > > > > > > > ; 'ker...@pengutronix.de' > > > > ; 'feste...@gmail.com' > > > > >; > > > > 'catalin.mari...@arm.com' ; > > > > 'will.dea...@arm.com' ; 'rui.zh...@intel.com > > > > ' > > > > ; 'edubez...@gmail.com' > > > > >; > > > > 'daniel.lezc...@linaro.org' ; Aisheng > > > > Dong ; 'ulf.hans...@linaro.org' > > > > ; 'sb...@kernel.org' ; > > > > Daniel Baluta ; Andy Gross > > > > ; 'horms+rene...@verge.net.au' > > > > ; 'he...@sntech.de' > > > > ; 'a...@arndb.de' ; 'maxime.rip...@bootlin.com' > > > > ; 'bjorn.anders...@linaro.org' > > > > ; 'ja...@amarulasolutions.com' > > > > ; 'enric.balle...@collabora.com' > > > > ; 'marc.w.gonza...@free.fr' > > > ; 'o...@lixom.net' > > > > > > > > ; 'devicet...@vger.kernel.org' > > > > ; 'linux-kernel@vger.kernel.org' > > > > > > > ker...@vger.kernel.org>; 'linux-arm-ker...@lists.infradead.org' > > > > ; 'linux...@vger.kernel.or > > > > g' > > > > ; dl-linux-imx > > > > Subject: RE: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal > > > > binding > > > > > > > > Ping... > > > > Hi, Eduardo > > > > Can you take a look at this thread? Thanks. > > > > > > > > > > > > Best Regards! > > > > Anson Huang > > > > > > > > > > > > > > -Original Message- > > > > > From: Anson Huang > > > > > Sent: 2019年3月6日 13:27 > > > > > To: 'Rob Herring' ; 'edubez...@gmail.com' > > > > > > > > > > Cc: 'mark.rutl...@arm.com' ; > > > > > 'shawn...@kernel.org' ; > > > > 's.ha...@pengutronix.de' > > > > > > > > > > ; 'ker...@pengutronix.de' > > > > > ; 'feste...@gmail.com' > > > ; > > > > > > > > > > > > > > 'catalin.mari...@arm.com' ; > > > > > 'will.dea...@arm.com' ;
[PATCH V11 4/4] arm64: dts: imx: add i.MX8QXP thermal support
Add i.MX8QXP CPU thermal zone support.
Signed-off-by: Anson Huang
---
Changes since V10:
- remove property "imx,sensor-resource-id" and put HW resource ID
inside each
thermal-sensors' phandle argument.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 33 ++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 70ef3db..cc1d877 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <>;
@@ -149,6 +150,11 @@
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+ tsens: thermal-sensor {
+ compatible = "fsl,imx8qxp-sc-thermal",
"fsl,imx-sc-thermal";
+ #thermal-sensor-cells = <1>;
+ };
};
timer {
@@ -484,4 +490,31 @@
power-domains = < IMX_SC_R_GPIO_7>;
};
};
+
+ thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = < IMX_SC_R_SYSTEM>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ cooling-maps {
+ map0 {
+ trip = <_alert0>;
+ cooling-device =
+ <_0 THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
};
--
2.7.4
[PATCH V11 2/4] thermal: imx_sc: add i.MX system controller thermal support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to get each thermal sensor's temperature,
it supports multiple sensors which are passed from device tree,
please see the binding doc for details.
Signed-off-by: Anson Huang
---
Changes since V10:
- remove "imx,sensor-resource-id" property, put the HW resource ID
inside thermal-zones node,
and driver needs to parse the phandle argument to get HW resource ID
and use it to register
thermal zone.
---
drivers/thermal/Kconfig | 11 +++
drivers/thermal/Makefile | 1 +
drivers/thermal/imx_sc_thermal.c | 159 +++
3 files changed, 171 insertions(+)
create mode 100644 drivers/thermal/imx_sc_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 653aa27..4e4fa7e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -223,6 +223,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config IMX_SC_THERMAL
+ tristate "Temperature sensor driver for NXP i.MX SoCs with System
Controller"
+ depends on (ARCH_MXC && IMX_SCU) || COMPILE_TEST
+ depends on OF
+ help
+ Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
+ system controller inside, Linux kernel has to communicate with system
+ controller via MU (message unit) IPC to get temperature from thermal
+ sensor. It supports one critical trip point and one
+ passive trip point for each thermal sensor.
+
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 486d682..4062627 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
new file mode 100644
index 000..0af0f09
--- /dev/null
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+#define IMX_SC_MISC_FUNC_GET_TEMP 13
+#define IMX_SC_C_TEMP 0
+
+static struct imx_sc_ipc *thermal_ipc_handle;
+
+struct imx_sc_sensor {
+ struct thermal_zone_device *tzd;
+ u32 resource_id;
+};
+
+struct req_get_temp {
+ u16 resource_id;
+ u8 type;
+} __packed;
+
+struct resp_get_temp {
+ u16 celsius;
+ u8 tenths;
+} __packed;
+
+struct imx_sc_msg_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ union {
+ struct req_get_temp req;
+ struct resp_get_temp resp;
+ } data;
+} __packed;
+
+static int imx_sc_thermal_get_temp(void *data, int *temp)
+{
+ struct imx_sc_msg_misc_get_temp msg;
+ struct imx_sc_rpc_msg *hdr =
+ struct imx_sc_sensor *sensor = data;
+ int ret;
+
+ msg.data.req.resource_id = sensor->resource_id;
+ msg.data.req.type = IMX_SC_C_TEMP;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
+ hdr->size = 2;
+
+ ret = imx_scu_call_rpc(thermal_ipc_handle, , true);
+ if (ret) {
+ pr_err("read temp sensor %d failed, ret %d\n",
+ sensor->resource_id, ret);
+ return ret;
+ }
+
+ *temp = msg.data.resp.celsius * 1000 + msg.data.resp.tenths * 100;
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
+ .get_temp = imx_sc_thermal_get_temp,
+};
+
+static int imx_sc_thermal_get_sensor_id(struct device_node *sensor_np, u32 *id)
+{
+ struct of_phandle_args sensor_specs;
+ int ret;
+
+ ret = of_parse_phandle_with_args(sensor_np,
+"thermal-sensors",
+"#thermal-sensor-cells",
+0,
+_specs);
+ if (ret)
+ return ret;
+
+ if (sensor_specs.args_count >= 1) {
+
[PATCH V11 3/4] defconfig: arm64: add i.MX system controller thermal support
This patch enables CONFIG_IMX_SC_THERMAL as module. Signed-off-by: Anson Huang --- No changes. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 9e313f5..d4c404a 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -415,6 +415,7 @@ CONFIG_SENSORS_INA2XX=m CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y +CONFIG_IMX_SC_THERMAL=m CONFIG_ROCKCHIP_THERMAL=m CONFIG_RCAR_THERMAL=y CONFIG_RCAR_GEN3_THERMAL=y -- 2.7.4
[PATCH V11 1/4] dt-bindings: fsl: scu: add thermal binding
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from thermal sensors, this patch adds
binding doc for i.MX system controller thermal driver.
Signed-off-by: Anson Huang
---
Changes since V10:
- remove property "imx,sensor-resource-id".
--
.../devicetree/bindings/arm/freescale/fsl,scu.txt| 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 5d7dbab..f4fb6d5 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -133,6 +133,17 @@ RTC bindings based on SCU Message Protocol
Required properties:
- compatible: should be "fsl,imx8qxp-sc-rtc";
+Thermal bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible: Should be :
+ "fsl,imx8qxp-sc-thermal"
+ followed by "fsl,imx-sc-thermal";
+
+- #thermal-sensor-cells: See
Documentation/devicetree/bindings/thermal/thermal.txt
+ for a description.
+
Example (imx8qxp):
-
aliases {
@@ -185,6 +196,11 @@ firmware {
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+ tsens: thermal-sensor {
+ compatible = "fsl,imx8qxp-sc-thermal",
"fsl,imx-sc-thermal";
+ #thermal-sensor-cells = <1>;
+ };
};
};
--
2.7.4
