* [PATCH] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-05-30 4:34 UTC (permalink / raw)
To: linux-arm-kernel
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 5 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 --
arch/x86/pci/early.c | 50 -------------------------
drivers/pci/pci.c | 4 ++
drivers/pci/pci.h | 2 +-
drivers/pci/probe.c | 19 ++++++++++
8 files changed, 25 insertions(+), 66 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index c247612..4459270 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2986,7 +2986,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h b/arch/x86/include/asm/pci-direct.h
index e1084f7..e5e2129 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -14,9 +14,4 @@ extern void write_pci_config(u8 bus, u8 slot, u8 func, u8 offset, u32 val);
extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
-extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..e20d449 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -51,53 +51,3 @@ void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val)
outw(val, 0xcfc + (offset&2));
}
-int early_pci_allowed(void)
-{
- return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
- PCI_PROBE_CONF1;
-}
-
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci 0000:%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256, false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0xffffffff)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
- if (func == 0) {
- type = read_pci_config_byte(bus, slot,
- func,
- PCI_HEADER_TYPE);
- if (!(type & 0x80))
- break;
- }
- }
- }
- }
-}
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7c03701..ae5a2ae 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,8 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+bool pci_early_dump;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5848,6 +5850,8 @@ static int __init pci_setup(char *str)
pcie_ats_disabled = true;
} else if (!strcmp(str, "noaer")) {
pci_no_aer();
+ } else if (!strcmp(str, "earlydump")) {
+ pci_early_dump = true;
} else if (!strncmp(str, "realloc=", 8)) {
pci_realloc_get_opt(str + 8);
} else if (!strncmp(str, "realloc", 7)) {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..9c66b7d 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -7,7 +7,7 @@
#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
extern const unsigned char pcie_link_speed[];
-
+extern bool pci_early_dump;
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
/* Functions internal to the PCI core code */
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 3840207..b1f068d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1549,6 +1549,22 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
return 0;
}
+static void early_dump_pci_device(struct pci_dev *pdev)
+{
+ u32 value[256 / 4];
+ int i;
+
+ dev_info(&pdev->dev, "pci 0000:%02x:%02x.%d config space:\n",
+ pdev->bus->number, PCI_SLOT(pdev->devfn),
+ PCI_FUNC(pdev->devfn));
+
+ for (i = 0; i < 256; i += 4)
+ pci_read_config_dword(pdev, i, &value[i / 4]);
+
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
+ 256, false);
+}
+
/**
* pci_setup_device - Fill in class and map information of a device
* @dev: the device structure to fill
@@ -1598,6 +1614,9 @@ int pci_setup_device(struct pci_dev *dev)
pci_printk(KERN_DEBUG, dev, "[%04x:%04x] type %02x class %#08x\n",
dev->vendor, dev->device, dev->hdr_type, dev->class);
+ if (pci_early_dump)
+ early_dump_pci_device(dev);
+
/* Need to have dev->class ready */
dev->cfg_size = pci_cfg_space_size(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-05-30 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527654876-26716-1-git-send-email-okaya@codeaurora.org>
On 5/29/2018 9:34 PM, Sinan Kaya wrote:
> -int early_pci_allowed(void)
> -{
> - return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
> - PCI_PROBE_CONF1;
> -}
I should have kept this. I'll wait for more feedback before posting the
next rev.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-30 4:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPcyV=fdRu7oLXHMimSFR9ktJ23uBriswTStkEkAMbTaNw@mail.gmail.com>
On 29-05-18, 15:18, Krzysztof Kozlowski wrote:
> Thanks for the patch.
>
> In case of Exynos, the booting CPU always has these information in DT
> and the booting CPU cannot be changed (chosen by firmware/hardware
> configuration).
But can the booting CPU be offlined ?
If yes, then this is how things are broken right now.
Build cpufreq driver as module, boot kernel, hotplug out CPU0, insert
cpufreq driver and that will try to find these properties in CPU1.
> Therefore there is no real risk of falling although
> for correctness of DT your change makes sense.
>
> It is too late for this cycle for me so I'll pick it up after merge window.
> Alternatively, arm-soc guys can pick it up directly with my tag:
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
No worries, you can pick it up later on.
--
viresh
^ permalink raw reply
* [PATCH] PCI: Add pci=safemode option
From: Sinan Kaya @ 2018-05-30 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530043103.GA19734@kroah.com>
On 5/29/2018 9:31 PM, Greg Kroah-Hartman wrote:
> On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
>> Adding pci=safemode kernel command line parameter to turn off all PCI
>> Express service driver as well as all optional PCIe features such as LTR,
>> Extended tags, Relaxed Ordering etc.
>>
>> Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
>> reconfigured with by the kernel in case BIOS hands off a broken
>> configuration.
>
> Why not fix the BIOS? That's what sane platforms do :)
>
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 2 ++
>> drivers/pci/pci.c | 7 +++++++
>> drivers/pci/pci.h | 2 ++
>> drivers/pci/pcie/portdrv_core.c | 2 +-
>> drivers/pci/probe.c | 6 ++++++
>> 5 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 641ec9c..247adbb 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -3153,6 +3153,8 @@
>> noari do not use PCIe ARI.
>> noats [PCIE, Intel-IOMMU, AMD-IOMMU]
>> do not use PCIe ATS (and IOMMU device IOTLB).
>> + safemode turns of all optinal PCI features. Useful
>> + for bringup/troubleshooting.
>
> s/optinal/optional/ ?
sure.
>
> And you should explain what exactly in PCI is "optional". Who defines
> this and where is that list and what can go wrong if those options are
> not enabled?
Bjorn and I discussed the need for such a "safe" mode feature when you
want to bring up PCI for a platform. You want to turn off everything as
a starter and just stick to bare minimum.
I can add a few words describing them. The goal of this option is to keep
base PCI features with MSI only. Things like PME, AER, ASPM, Extended
Tags, LTR, Relaxed Ordering, SRIOV are all considered optional. safemode
is certainly not intended for production environments.
I can taint the kernel as a suggestion.
I defined minimum as just booting a device and to be able to do DMA traffic
only with 0 optimization
>
> In looking at your patch, I can't determine that at all, so there's no
> way that someone just looking at this sentence will be able to
> understand.
>
> thanks,
>
> greg k-h
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: YaoJun @ 2018-05-30 4:48 UTC (permalink / raw)
To: linux-arm-kernel
To protect against KSMA(Kernel Space Mirroring Attack), make
tramp_pg_dir read-only. The principle of KSMA is to insert a
carefully constructed PGD entry into the translation table.
The type of this entry is block, which maps the kernel text
and its access permissions bits are 01. The user process can
then modify kernel text directly through this mapping. In this
way, an arbitrary write can be converted to multiple arbitrary
writes.
Signed-off-by: YaoJun <yaojun8558363@gmail.com>
---
arch/arm64/mm/mmu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..ac4b22c7e435 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
prot, pgd_pgtable_alloc, 0);
+ update_mapping_prot(__pa_symbol(tramp_pg_dir),
+ (unsigned long)tramp_pg_dir,
+ PGD_SIZE, PAGE_KERNEL_RO);
+
/* Map both the text and data into the kernel page table */
__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
--
2.17.0
^ permalink raw reply related
* [PATCH] PCI: Add pci=safemode option
From: Greg Kroah-Hartman @ 2018-05-30 4:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c317ed8-cca3-8862-5f3b-12cf14e4d53b@codeaurora.org>
On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote:
> On 5/29/2018 9:31 PM, Greg Kroah-Hartman wrote:
> > On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
> >> Adding pci=safemode kernel command line parameter to turn off all PCI
> >> Express service driver as well as all optional PCIe features such as LTR,
> >> Extended tags, Relaxed Ordering etc.
> >>
> >> Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
> >> reconfigured with by the kernel in case BIOS hands off a broken
> >> configuration.
> >
> > Why not fix the BIOS? That's what sane platforms do :)
> >
> >>
> >> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> >> ---
> >> Documentation/admin-guide/kernel-parameters.txt | 2 ++
> >> drivers/pci/pci.c | 7 +++++++
> >> drivers/pci/pci.h | 2 ++
> >> drivers/pci/pcie/portdrv_core.c | 2 +-
> >> drivers/pci/probe.c | 6 ++++++
> >> 5 files changed, 18 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index 641ec9c..247adbb 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -3153,6 +3153,8 @@
> >> noari do not use PCIe ARI.
> >> noats [PCIE, Intel-IOMMU, AMD-IOMMU]
> >> do not use PCIe ATS (and IOMMU device IOTLB).
> >> + safemode turns of all optinal PCI features. Useful
> >> + for bringup/troubleshooting.
> >
> > s/optinal/optional/ ?
>
> sure.
>
> >
> > And you should explain what exactly in PCI is "optional". Who defines
> > this and where is that list and what can go wrong if those options are
> > not enabled?
>
> Bjorn and I discussed the need for such a "safe" mode feature when you
> want to bring up PCI for a platform. You want to turn off everything as
> a starter and just stick to bare minimum.
>
> I can add a few words describing them. The goal of this option is to keep
> base PCI features with MSI only. Things like PME, AER, ASPM, Extended
> Tags, LTR, Relaxed Ordering, SRIOV are all considered optional. safemode
> is certainly not intended for production environments.
Ok, then you should say that here, or somewhere, so that people know
this. Otherwise people will see that "hey this lets my hardware boot!"
and then never change it :(
> I can taint the kernel as a suggestion.
I would not worry about that.
> I defined minimum as just booting a device and to be able to do DMA traffic
> only with 0 optimization
Ok, again, just document this really well, so that people do not have
questions and start wondering why their devices barely seem to work.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v3 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces
From: joro at 8bytes.org @ 2018-05-30 4:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527610139.14039.58.camel@hpe.com>
On Tue, May 29, 2018 at 04:10:24PM +0000, Kani, Toshi wrote:
> Can you explain why you think allocating a page here is a major problem?
Because a larger allocation is more likely to fail. And if you fail the
allocation, you also fail to free more pages, which _is_ a problem. So
better avoid any allocations in code paths that are about freeing
memory.
> If we just revert, please apply patch 1/3 first. This patch address the
> BUG_ON issue on PAE. This is a real issue that needs a fix ASAP.
It does not address the problem of dirty page-walk caches on x86-64.
> The page-directory cache issue on x64, which is addressed by patch 3/3,
> is a theoretical issue that I could not hit by putting ioremap() calls
> into a loop for a whole day. Nobody hit this issue, either.
How do you know you didn't hit that issue? It might cause silent data
corruption, which might not be easily detected.
> The simple revert patch Joerg posted a while ago causes
> pmd_free_pte_page() to fail on x64. This causes multiple pmd mappings
> to fall into pte mappings on my test systems. This can be seen as a
> degradation, and I am afraid that it is more harmful than good.
The plain revert just removes all the issues with the dirty TLB that the
original patch introduced and prevents huge mappings from being
established when there have been smaller mappings before. This is not
ideal, but at least its is consistent and does not leak pages and leaves
no dirty TLBs. So this is the easiest and most reliable fix for this
stage in the release process.
Regards,
Joerg
^ permalink raw reply
* linux-next: manual merge of the regulator tree with the arm-soc tree
From: Stephen Rothwell @ 2018-05-30 5:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the regulator tree got a conflict in:
arch/arm/mach-omap1/board-ams-delta.c
between commit:
0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
from the arm-soc tree and commit:
6059577cb28d ("regulator: fixed: Convert to use GPIO descriptor only")
from the regulator tree.
I fixed it up (see below - it may be better done) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/mach-omap1/board-ams-delta.c
index 80f54cb54276,759fa18f6ab4..000000000000
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@@ -203,10 -203,8 +203,10 @@@ static struct resource latch2_resources
},
};
- #define LATCH2_LABEL "latch2"
++#define LATCH2_LABEL "ams-delta-latch2"
+
static struct bgpio_pdata latch2_pdata = {
- .label = "ams-delta-latch2",
+ .label = LATCH2_LABEL,
.base = AMS_DELTA_LATCH2_GPIO_BASE,
.ngpio = AMS_DELTA_LATCH2_NGPIO,
};
@@@ -303,6 -288,16 +302,15 @@@ static struct platform_device modem_nre
},
};
+ static struct gpiod_lookup_table modem_nreset_gpiod_table = {
+ .dev_id = "reg-fixed-voltage",
+ .table = {
- /* The AMS_DELTA_GPIO_PIN_MODEM_NRESET is at offset 12 */
- GPIO_LOOKUP("ams-delta-latch2", 12,
++ GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_MODEM_NRESET,
+ "enable", GPIO_ACTIVE_HIGH),
+ { },
+ },
+ };
+
struct modem_private_data {
struct regulator *regulator;
};
@@@ -658,15 -581,7 +666,15 @@@ static int __init late_init(void
platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
+ /*
+ * As soon as devices have been registered, assign their dev_names
+ * to respective GPIO lookup tables before they are added.
+ */
+ ams_delta_lcd_gpio_table.dev_id = dev_name(&ams_delta_lcd_device.dev);
+ ams_delta_nand_gpio_table.dev_id = dev_name(&ams_delta_nand_device.dev);
+
+ gpiod_add_lookup_tables(late_gpio_tables, ARRAY_SIZE(late_gpio_tables));
-
+ gpiod_add_lookup_table(&modem_nreset_gpiod_table);
err = platform_device_register(&modem_nreset_device);
if (err) {
pr_err("Couldn't register the modem regulator device\n");
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/1b173abe/attachment-0001.sig>
^ permalink raw reply
* linux-next: manual merge of the irqchip tree with the arm-soc tree
From: Olof Johansson @ 2018-05-30 5:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1e7a14d-ea49-fc8e-a95c-2b4257096187@st.com>
Hi,
On Tue, May 29, 2018 at 5:20 AM, Ludovic BARRE <ludovic.barre@st.com> wrote:
>
>
> On 05/29/2018 10:55 AM, Alexandre Torgue wrote:
>>
>>
>>
>> On 05/29/2018 10:39 AM, Marc Zyngier wrote:
>>>
>>> On 29/05/18 09:16, Alexandre Torgue wrote:
>>>>
>>>> Hi Marc
>>>>
>>>> On 05/29/2018 09:47 AM, Marc Zyngier wrote:
>>>>>
>>>>> On 29/05/18 08:41, Alexandre Torgue wrote:
>>>>>>
>>>>>> Hi Stephen
>>>>>>
>>>>>> On 05/29/2018 07:52 AM, Stephen Rothwell wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Today's linux-next merge of the irqchip tree got a conflict in:
>>>>>>>
>>>>>>> arch/arm/boot/dts/stm32mp157c.dtsi
>>>>>>>
>>>>>>> between commit:
>>>>>>>
>>>>>>> 3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to
>>>>>>> stm32mp157c")
>>>>>>>
>>>>>>> from the arm-soc tree and commit:
>>>>>>>
>>>>>>> 5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for
>>>>>>> stm32mp157c")
>>>>>>>
>>>>>>> from the irqchip tree.
>>>>>>>
>>>>>>> I fixed it up (see below) and can carry the fix as necessary. This
>>>>>>> is now fixed as far as linux-next is concerned, but any non trivial
>>>>>>> conflicts should be mentioned to your upstream maintainer when your
>>>>>>> tree
>>>>>>> is submitted for merging. You may also want to consider cooperating
>>>>>>> with the maintainer of the conflicting tree to minimise any
>>>>>>> particularly
>>>>>>> complex conflicts.
>>>>>>>
>>>>>>
>>>>>> Thanks for the fix (I will reorder nodes in a future patch). My
>>>>>> opinion
>>>>>> is that all STM32 DT patches should come through my STM32 tree. It is
>>>>>> my
>>>>>> role to fix this kind of conflicts. I thought it was a common rule
>>>>>> (driver patches go to sub-system maintainer tree and DT to the Machine
>>>>>> maintainer). For incoming next-series which contain DT+driver patches
>>>>>> I
>>>>>> will indicate clearly that I take DT patch. I'm right ?
>>>>>
>>>>> Happy to oblige. Can you make sure you sync up with Ludovic and define
>>>>> what you want to do?
>>>>
>>>>
>>>> Sorry I don't understand your reply. I just say that for series
>>>> containing DT patches + drivers patches, to my point of view it is more
>>>> safe that driver patches are taken by sub-system maintainer (you in this
>>>> case) and that I take DT patches in my tree.
>>>
>>> And I'm happy to let you deal with these patches. I'm just asking you
>>> sync with Ludovic to split the series on whichever boundary you wish to
>>> enforce.
>>
>> ok
>>
>>>
>>>>> In the meantime, I'm dropping the series altogether.
>>>>>
>>>> Why? We could keep it as Stephen fixed the merge issue.
>>>
>>> Well, you seem to have a strong opinion about who deals with what. I'll
>>> let Ludovic repost what you and him decide should go via the irqchip
>>> tree.
>>
>>
>> It's not a "strong" opinion just my point of view and maybe not the good
>> one. I thought that's the way of working was like I explained. If you prefer
>> 2 series (one for driver patches and another one for DT patches) I will be
>> happy with that.
>>
>> Ludovic, what is your opinion ?
>
>
> Hi everybody
>
> For this serie, I think we could keep like that with
> Stephen fix. New stm32 irqchip will be integrated (thanks Marc)
> with no conflict with usb (thanks Stephen).
>
> For next series, we may split driver and DT to avoid misunderstanding.
The general rule that we try to use is to always merge DT through the
arm-soc tree, even if the driver gets merged through the subsystem
tree. There should be no harm in doing this for new drivers (i.e. a
new driver won't regress if the DT update is missing, it just won't
probe/configure). And that way we can keep the conflicts internal to
our tree (ideally to the SoC maintainer tree) and not cause overhead
for other maintainers and Stephen.
So yes, for the future please do not submit the DT updates with the
drivers, or at the very least be very clear when you post them that
you don't want the driver maintainer to apply them.
-Olof
^ permalink raw reply
* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 5:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d03576cf90f06afb1194301cb41fc31704def1d.1527040878.git.collinsd@codeaurora.org>
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins <collinsd@codeaurora.org> wrote:
> +========
> +Examples
> +========
> +
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +
> +&apps_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> + vdd-l7-l12-l14-l15-supply = <&pm8998_s5>;
> +
> + smps2 {
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1100000>;
> + };
> +
> + pm8998_s5: smps5 {
> + regulator-min-microvolt = <1904000>;
> + regulator-max-microvolt = <2040000>;
> + };
> +
> + ldo7 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>;
> + regulator-allowed-modes =
> + <RPMH_REGULATOR_MODE_LPM
> + RPMH_REGULATOR_MODE_HPM>;
> + regulator-allow-set-load;
> + qcom,regulator-drms-modes =
> + <RPMH_REGULATOR_MODE_LPM
> + RPMH_REGULATOR_MODE_HPM>;
> + qcom,drms-mode-max-microamps = <10000 1000000>;
Things look pretty good to me now. I'm still hesitant about the whole
need to list the modes twice (once using the unordered
"regulator-allowed-modes" and once to match up against the ordered
"qcom,drms-mode-max-microamps"). I'm also still of the opinion that
the whole "drms-mode-max-microamps" ought to be a standard property
(not a qcom specific one) and handled in the regulator core.
However, for both of these things I leave it to the discretion of Mark
to choose what he wants. Thus assuming Mark is OK with these two
things, feel free to add my Reviewed-by.
-Doug
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523155617.GN4828@sirena.org.uk>
Hi,
On Wed, May 23, 2018 at 8:56 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 23, 2018 at 08:50:22AM -0700, Doug Anderson wrote:
>> On Wed, May 23, 2018 at 8:40 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > It's got to be valid to think about the voltage of a disabled regulator
>> > since drivers want to be able make sure that the regulator gets enabled
>> > with a sensible config. With most hardware this is really easy since
>> > you can just look at the status reported by the hardware but the RPM
>> > makes this hard since there's so much write only stuff in there.
>
>> I should be more clear. Certainly it should be valid to set the
>> voltage before enabling it so, as you said, the regulator turns on at
>> the right voltage. I'm saying that it's weird (to me) to expect that
>> setting the voltage for a regulator that a client thinks is disabled
>> will affect any real voltages in the system until the regulator is
>> enabled. In RPMh apparently setting a voltage of a regulator you
>> think is disabled can affect the regulator output if another client
>> (unbeknownst to you) happens to have it enabled.
>
> Yes, that's definitely not what's expected but it's unfortunately what
> the firmware chose to implement so we may well be stuck with it
> unfortunately.
We're not really stuck with it if we do what I was suggesting. I was
suggesting that every time we disable the regulator in Linux we have
Linux vote for the lowest voltage it's comfortable with. Linux keeps
track of the true voltage that the driver wants and will always change
its vote back to that before enabling. Thus (assuming Linux is OK
with 1.2 V - 1.4 V for a rail):
Modem: want 1.3 V and enabled.
=> Modem votes for 1.3 V
=> Modem votes for enabled.
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.3V
=> True output: 1.3V
Linux: want 1.4 V and enabled.
=> Linux votes for 1.4 V
=> Linux votes for enabled
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.4V
=> True output: 1.4V
Linux: want disabled
=> Linux votes for disabled
=> Linux votes for 1.2 V (keeps 1.4 V in local var)
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.3V
=> True output: 1.3V
Linux: want enabled
=> Linux votes for 1.4 V (from local var)
=> Linux votes for enabled
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.4V
=> True output: 1.4V
...but I'll leave it to you if you think this is a big deal. If
you're happy with how David's driver works without my suggestion then
I won't push it.
-Doug
^ permalink raw reply
* [PATCH v4 2/2] regulator: add QCOM RPMh regulator driver
From: Doug Anderson @ 2018-05-30 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7489cd65fedb8a31488cf8188885759bcd4820ce.1527040878.git.collinsd@codeaurora.org>
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins <collinsd@codeaurora.org> wrote:
> + * @ever_enabled: Boolean indicating that the regulator has been
> + * explicitly enabled at least once. Voltage
> + * requests should be cached when this flag is not
> + * set.
Do you really need this extra boolean? Can't you just check if
"enabled" is still "-EINVAL"? If it is then you don't pass the
voltage along.
...this would mean that you'd also need to send the voltage vote when
the regulator core tries to disable unused regulators at the end of
bootup, but that should be OK right? If we never touched a regulator
anywhere at probe time and we're about to vote to disable it, we know
there's nobody requiring it to still be on. We can vote for the
voltage now without fear of messing up a vote that the BIOS left in
place.
In theory this should also allow you to assert your vote about the
voltage of a regulator that has never been enabled, which (if I
understand correctly) you consider to be a feature.
---
Other than that comment, everything else here looks good to go if Mark
is good with it. As per the previous threads there are some things
that I don't like a ton, but I feel it is between you and Mark to
decide if you're good with it. A summary of those issues are:
1. I still believe that when we disable a regulator in Linux we should
tell RPMh that we vote for the lowest voltage. ...but if Mark is
happy with the way the driver works now I won't push it.
2. As per my comments in the bindings patch, I still believe that
"qcom,drms-mode-max-microamps" belongs in the core. Again, up to
Mark.
3. As per my comments in the bindings patch, I still believe that
we're just adding lots of noise to the DT most of the time by
specifying both "qcom,regulator-drms-modes" and
"regulator-allowed-modes". Again, up to Mark.
-Doug
^ permalink raw reply
* [reset-control] How to initialize hardware state with the shared reset line?
From: Masahiro Yamada @ 2018-05-30 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCBAoRebScz+DTSKSgiU5DjeSHS1F3=2vt8KM-yCv+2A8g@mail.gmail.com>
2018-05-25 5:09 GMT+09:00 Martin Blumenstingl
<martin.blumenstingl@googlemail.com>:
> Hi Philipp,
>
> On Tue, May 22, 2018 at 4:04 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
>> Hi Martin,
>>
>> On Mon, 2018-05-21 at 12:40 +0200, Martin Blumenstingl wrote:
>>> Hello,
>>>
>>> On Mon, May 21, 2018 at 3:27 AM, Masahiro Yamada
>>> <yamada.masahiro@socionext.com> wrote:
>>> > Hi.
>>> >
>>> >
>>> > 2018-05-20 19:57 GMT+09:00 Martin Blumenstingl
>>> > <martin.blumenstingl@googlemail.com>:
>>> > > Hi,
>>> > >
>>> > > On Thu, May 10, 2018 at 11:16 AM, Masahiro Yamada
>>> > > <yamada.masahiro@socionext.com> wrote:
>>> > > [snip]
>>> > > > I may be missing something, but
>>> > > > one solution might be reset hogging on the
>>> > > > reset provider side. This allows us to describe
>>> > > > the initial state of reset lines in the reset controller.
>>> > > >
>>> > > > The idea for "reset-hog" is similar to:
>>> > > > - "gpio-hog" defined in
>>> > > > Documentation/devicetree/bindings/gpio/gpio.txt
>>> > > > - "assigned-clocks" defined in
>>> > > > Documetation/devicetree/bindings/clock/clock-bindings.txt
>>> > > >
>>> > > >
>>> > > >
>>> > > > For example,
>>> > > >
>>> > > > reset-controller {
>>> > > > ....
>>> > > >
>>> > > > line_a {
>>> > > > reset-hog;
>>> > > > resets = <1>;
>>> > > > reset-assert;
>>> > > > };
>>> > > > }
>>> > > >
>>> > > >
>>> > > > When the reset controller is registered,
>>> > > > the reset ID '1' is asserted.
>>> > > >
>>> > > >
>>> > > > So, all reset consumers that share the reset line '1'
>>> > > > will start from the asserted state
>>> > > > (i.e. defined state machine state).
>>> > >
>>> > > I wonder if a "reset hog" can be board specific:
>>> > > - GPIO hogs are definitely board specific (meson-gxbb-odroidc2.dts for
>>> > > example uses it to take the USB hub out of reset)
>>> > > - assigned-clock-parents (and the like) can also be board specific (I
>>> > > made up a use-case since I don't know of any actual examples: board A
>>> > > uses an external XTAL while board B uses some other internal
>>> > > clock-source because it doesn't have an external XTAL)
>>> > >
>>> > > however, can reset lines be board specific? or in other words: do we
>>> > > need to describe them in device-tree?
>>> >
>>> > Indeed.
>>> >
>>> > I did not come up with board-specific cases.
>>> >
>>> > The problem we are discussing is SoC-specific,
>>> > and reset-controller drivers are definitely SoC-specific.
>>> >
>>> > So, I think the initial state can be coded in drivers instead of DT.
>>>
>>> OK, let's also hear Philipp's (reset framework maintainer) opinion on this
>>
>> I'd like to know if there are other SoC families besides Amlogic Meson
>> that potentially could have this problem and about how many of the
>> resets that are documented in include/dt-bindings/reset/amlogic,meson*
>> we are actually talking. Are all of those initially deasserted and none
>> of the connected peripherals have power-on reset mechanisms?
> I cannot speak for other SoC families besides Amlogic
> Meson8/Meson8b/Meson8m2 and GX (disclaimer: I am a community
> contributor, I don't have access to Amlogic's internal datasheets - my
> knowledge is based on their public datasheets, their GPL kernel/u-boot
> sources and trial and error)
>
> it seems that at least "some" (but I don't know the exact number)
> resets are de-asserted by the bootloader
> Amlogic's u-boot for example also enables all gate clocks by default
>
> I CC'ed the Amlogic mailing list because I'm not sure if everyone
> working on that SoC family is watching the linux-arm-kernel mailing
> list
>
>>> > > we could extend struct reset_controller_dev (= reset controller
>>> > > driver) if they are not board specific:
>>> > > - either assert all reset lines by default except if they are listed
>>> > > in a new field (may break backwards compatibility, requires testing of
>>> > > all reset controller drivers)
>>> >
>>> > This is quite simple, but I am afraid there are some cases where the forcible
>>> > reset-assert is not preferred.
>>> >
>>> > For example, the earlycon. When we use earlycon, we would expect it has been
>>> > initialized by a boot-loader, or something.
>>> > If it is reset-asserted on the while, the console output
>>> > will not be good.
>>>
>>> indeed, so let's skip this idea
>>
>> Maybe we should at first add initial reset assertion to the Meson driver
>> on a case by case bases?
> this seems simple enough to test it - we can still generalize this
> later on (either by adding support to the reset framework, DT bindings
> or something else)
>
>> We can't add required reset hog DT bindings to the Meson reset
>> controller anyway without breaking DT backwards compatibility.
>>
>>> > > - specify a list of reset lines and their desired state (or to keep it
>>> > > easy: specify a list of reset lines that should be asserted)
>>> > > (I must admit that this is basically your idea but the definition is
>>> > > moved from device-tree to the reset controller driver)
>>> >
>>> > Yes, I think the list of "reset line ID" and "init state" pairs
>>> > would be nicer.
>>>
>>> $ grep -R "of_reset_n_cells = [^1]" drivers/reset/
>>> drivers/reset/reset-berlin.c: priv->rcdev.of_reset_n_cells = 2;
>>> drivers/reset/hisilicon/reset-hi3660.c: rc->rst.of_reset_n_cells = 2;
>>> drivers/reset/reset-ti-sci.c: data->rcdev.of_reset_n_cells = 2;
>>> drivers/reset/reset-lantiq.c: priv->rcdev.of_reset_n_cells = 2;
>>>
>>> everything else uses only one reset cell
>>> from the lantiq reset dt-binding documentation: "The first cell takes
>>> the reset set bit and the second cell takes the status bit."
>>>
>>> I'm not sure what to do with drivers that specify != 1 reset-cell
>>> though if we use a simple "init state pair"
>>> maybe Philipp can share his opinion on this one as well
>>
>> See above, so far I am not convinced (either way) whether this should be
>> described in the DT at all.
>>
>>> > > any "chip" specific differences could be expressed by using a
>>> > > different of_device_id
>>> > >
>>> > > one the other hand: your "reset hog" solution looks fine to me if
>>> > > reset lines can be board specific
>>> > >
>>> > > > From the discussion with Martin Blumenstingl
>>> > > > (https://lkml.org/lkml/2018/4/28/115),
>>> > > > the problem for Amlogic is that
>>> > > > the reset line is "de-asserted" by default.
>>> > > > If so, the 'reset-hog' would fix the problem,
>>> > > > and DWC3 driver would be able to use
>>> > > > shared, level reset, I think.
>>> > >
>>> > > I think you are right: if we could control the initial state then we
>>> > > should be able to use level resets
>>> >
>>> >
>>> > Even further, can we drop the shared reset_control_reset() support, maybe?
>>> > (in other words, revert commit 7da33a37b48f11)
>>>
>>> I believe we need to keep this if there's hardware out there:
>>> - where the reset controller only supports reset pulses
>>> - at least one reset line is shared between multiple devices
>>>
>>> I didn't have a closer look at the Amlogic Meson6 SoC yet, but I think
>>> it matches above criteria. as far as I know:
>>> - the USB situation there is similar to Meson8b (USB controllers and
>>> PHYs share a reset line)
>>> - it uses an older reset controller IP block which does not support
>>> level resets (only reset pulses)
>>
>> See my answer to Masahiro's first mail. I think somebody suggested in
>> the past to add a fallback from the deassert to the reset op. I think
>> this is something that should work in this case.
> this is an interesting idea - it should work for Meson6 (in case
> mainline ever gains support for this old SoC)
>
>
One more thing.
I want to remove reset_control_reset() entirely.
[1] Some reset consumers (e.g. drivers/ata/sata_gemini.c)
use reset_control_reset() to reset the HW.
[2] Some reset consumers (e.g. drivers/input/keyboard/tegra-kbc.c)
use the combination of reset_control_assert() and reset_control_deassert()
to reset the HW.
[1] is the only way if the reset controller only supports the pulse reset.
[2] is the only way if the reset controller only supports the level reset.
So, this is another strangeness because
the implementation of reset controller
affects reset consumers.
We do not need [1].
[2] is more flexible than [1] because hardware usually specifies
how long the reset line should be kept asserted.
For all reset consumers,
replace
reset_control_reset();
with
reset_control_assert();
reset_control_deassert();
and deprecate reset_control_reset().
I think this is the right thing to do.
The reset controller side should be implemented like this:
If your reset controller only supports the pulse reset,
.deassert hook should be no-op.
.assert hook should pulse the reset
Then .reset hook should be removed.
Or, we can keep the reset drivers as they are.
drivers/reset/core.c can take care of the proper fallback logic.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Ingo Molnar @ 2018-05-30 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529133622.26982-1-nixiaoming@huawei.com>
* nixiaoming <nixiaoming@huawei.com> wrote:
> mark_rodata_ro is only called by the function mark_readonly
> when CONFIG_STRICT_KERNEL_RWX=y
>
> if CONFIG_STRICT_KERNEL_RWX is not set
> a compile warning may be triggered: unused function
>
> Signed-off-by: nixiaoming <nixiaoming@huawei.com>
> ---
> arch/x86/mm/init_32.c | 2 ++
> arch/x86/mm/init_64.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index c893c6a..121c567 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -920,6 +920,7 @@ static void mark_nxdata_nx(void)
> set_pages_nx(virt_to_page(start), size >> PAGE_SHIFT);
> }
>
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> @@ -957,3 +958,4 @@ void mark_rodata_ro(void)
> if (__supported_pte_mask & _PAGE_NX)
> debug_checkwx();
> }
> +#endif /*end of CONFIG_STRICT_KERNEL_RWX*/
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 0a40060..1b7a1a7 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1245,6 +1245,7 @@ void set_kernel_text_ro(void)
> set_memory_ro(start, (end - start) >> PAGE_SHIFT);
> }
>
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> @@ -1298,6 +1299,7 @@ void mark_rodata_ro(void)
> */
> pti_clone_kernel_text();
> }
> +#endif
NAK, this is very ugly and the changelog doesn't appear to be true: the build
warning does not trigger in the default build, correct?
Thanks,
Ingo
^ permalink raw reply
* [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Ard Biesheuvel @ 2018-05-30 6:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530055815.GB6463@gmail.com>
On 30 May 2018 at 07:58, Ingo Molnar <mingo@kernel.org> wrote:
>
> * nixiaoming <nixiaoming@huawei.com> wrote:
>
>> mark_rodata_ro is only called by the function mark_readonly
>> when CONFIG_STRICT_KERNEL_RWX=y
>>
>> if CONFIG_STRICT_KERNEL_RWX is not set
>> a compile warning may be triggered: unused function
>>
>> Signed-off-by: nixiaoming <nixiaoming@huawei.com>
>> ---
>> arch/x86/mm/init_32.c | 2 ++
>> arch/x86/mm/init_64.c | 2 ++
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
>> index c893c6a..121c567 100644
>> --- a/arch/x86/mm/init_32.c
>> +++ b/arch/x86/mm/init_32.c
>> @@ -920,6 +920,7 @@ static void mark_nxdata_nx(void)
>> set_pages_nx(virt_to_page(start), size >> PAGE_SHIFT);
>> }
>>
>> +#ifdef CONFIG_STRICT_KERNEL_RWX
>> void mark_rodata_ro(void)
>> {
>> unsigned long start = PFN_ALIGN(_text);
>> @@ -957,3 +958,4 @@ void mark_rodata_ro(void)
>> if (__supported_pte_mask & _PAGE_NX)
>> debug_checkwx();
>> }
>> +#endif /*end of CONFIG_STRICT_KERNEL_RWX*/
>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
>> index 0a40060..1b7a1a7 100644
>> --- a/arch/x86/mm/init_64.c
>> +++ b/arch/x86/mm/init_64.c
>> @@ -1245,6 +1245,7 @@ void set_kernel_text_ro(void)
>> set_memory_ro(start, (end - start) >> PAGE_SHIFT);
>> }
>>
>> +#ifdef CONFIG_STRICT_KERNEL_RWX
>> void mark_rodata_ro(void)
>> {
>> unsigned long start = PFN_ALIGN(_text);
>> @@ -1298,6 +1299,7 @@ void mark_rodata_ro(void)
>> */
>> pti_clone_kernel_text();
>> }
>> +#endif
>
> NAK, this is very ugly and the changelog doesn't appear to be true: the build
> warning does not trigger in the default build, correct?
>
I don't see how the build warning could trigger at all, given that
mark_rodata_ro() has external linkage.
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: Fix hwrng register address
From: Joel Stanley @ 2018-05-30 6:17 UTC (permalink / raw)
To: linux-arm-kernel
The register address should be the full address of the rng, not the
offset from the start of the SCU.
Fixes: 5daa8212c08e ("ARM: dts: aspeed: Describe random number device")
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
Hi ARM maintainers, this was found when testing next-20180529 after the
merge of the aspeed 4.18 pull request. Can you please apply this one to
your -next tree?
I'll also send a PR with some defconfig updates so the rng driver is
enabled by default.
---
arch/arm/boot/dts/aspeed-g4.dtsi | 4 ++--
arch/arm/boot/dts/aspeed-g5.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 5e947ed496c2..75df1573380e 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -145,9 +145,9 @@
};
- rng: hwrng at 78 {
+ rng: hwrng at 1e6e2078 {
compatible = "timeriomem_rng";
- reg = <0x78 0x4>;
+ reg = <0x1e6e2078 0x4>;
period = <1>;
quality = <100>;
};
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 24eec00c4a95..17f2714d18a7 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -189,9 +189,9 @@
};
};
- rng: hwrng at 78 {
+ rng: hwrng at 1e6e2078 {
compatible = "timeriomem_rng";
- reg = <0x78 0x4>;
+ reg = <0x1e6e2078 0x4>;
period = <1>;
quality = <100>;
};
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem driver
From: Vishal Sagar @ 2018-05-30 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5bf470c0-8737-273e-c138-58a05d7d9a30@infradead.org>
Hi Randy,
Thanks for reviewing.
> -----Original Message-----
> From: Randy Dunlap [mailto:rdunlap at infradead.org]
> Sent: Wednesday, May 30, 2018 1:29 AM
> To: Vishal Sagar <vishal.sagar@xilinx.com>; Hyun Kwon <hyunk@xilinx.com>;
> laurent.pinchart at ideasonboard.com; michal.simek at xilinx.com; linux-
> media at vger.kernel.org; devicetree at vger.kernel.org
> Cc: sakari.ailus at linux.intel.com; hans.verkuil at cisco.com;
> mchehab at kernel.org; robh+dt at kernel.org; mark.rutland at arm.com; Dinesh
> Kumar <dineshk@xilinx.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem
> driver
>
> On 05/29/2018 11:54 AM, Vishal Sagar wrote:
> >
> > Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> > ---
> > drivers/media/platform/xilinx/Kconfig | 12 +
> > drivers/media/platform/xilinx/Makefile | 1 +
> > drivers/media/platform/xilinx/xilinx-csi2rxss.c | 1751
> +++++++++++++++++++++++
> > include/uapi/linux/xilinx-csi2rxss.h | 25 +
> > include/uapi/linux/xilinx-v4l2-controls.h | 14 +
> > 5 files changed, 1803 insertions(+)
> > create mode 100644 drivers/media/platform/xilinx/xilinx-csi2rxss.c
> > create mode 100644 include/uapi/linux/xilinx-csi2rxss.h
> >
> > diff --git a/drivers/media/platform/xilinx/Kconfig
> b/drivers/media/platform/xilinx/Kconfig
> > index a5d21b7..06d5944 100644
> > --- a/drivers/media/platform/xilinx/Kconfig
> > +++ b/drivers/media/platform/xilinx/Kconfig
> > @@ -8,6 +8,18 @@ config VIDEO_XILINX
> >
> > if VIDEO_XILINX
> >
> > +config VIDEO_XILINX_CSI2RXSS
> > + tristate "Xilinx CSI2 Rx Subsystem"
> > + depends on VIDEO_XILINX
> > + help
> > + Driver for Xilinx MIPI CSI2 Rx Subsystem. This is a V4L sub-device
> > + based driver that takes input from CSI2 Tx source and converts
> > + it into an AXI4-Stream. It has a DPHY (whose register interface
> > + can be enabled, an optional I2C controller and an optional Video
>
> can be enabled),
>
Noted. I will update in next revision of patch.
> > + Format Bridge which converts the AXI4-Stream data to Xilinx Video
> > + Bus formats based on UG934. The driver is used to set the number
> > + of active lanes and get short packet data.
> > +
> > config VIDEO_XILINX_TPG
> > tristate "Xilinx Video Test Pattern Generator"
> > depends on VIDEO_XILINX
>
>
>
> > This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
> recipient, do not read, copy, or forward this email message or any attachments.
> Delete this email message and any attachments immediately.
>
> :(
>
Sorry about that.
I will work with IT on getting this removed before sending v2 for the patches.
-- Vishal
> --
> ~Randy
^ permalink raw reply
* [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Marcel Holtmann @ 2018-05-30 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527175805.4607.103.camel@mtkswgap22>
Hi Sean,
>>>>>>
>>>>>> [ ... ]
>
> [ ... ]
>
>>> I post it as plain text as below
>>>
>>>
>>> Bluetooth monitor ver 5.37
>>> = Note: Linux version 4.16.0-rc1+ (aarch64) 0.641494
>>> = Note: Bluetooth subsystem version 2.22 0.641502
>>> = New Index: 00:00:46:76:22:01 (BR/EDR,UART,hci0) [hci0] 0.641505
>>> * Unknown packet (code 14 len 30) 0.641509
>>> 01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..............bl
>>> 75 65 74 6f 6f 74 68 64 00 00 00 00 00 00 uetoothd......
>>> * Unknown packet (code 14 len 30) 0.641592
>>> 02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..............bt
>>> 6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00 mon...........
>>> * Unknown packet (code 16 len 7) [hci0] 6.536771
>>> 01 00 00 00 05 00 01 .......
>>> = Open Index: 00:00:46:76:22:01 [hci0] 6.717019
>>> = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 6.717030
>>
>> can you try with the latest BlueZ 5.49 or git version. Seems it actually stumbles over the extra packet here. Fun fact is that I can not get a backtrace to pin-point the issue in btmon and why it crashes.
>>
>
> I had less experience updating user land BlueZ, but I can try it as possible and see whether Unknown packets still are present at newest version BlueZ. Hopefully I don't misunderstand your point here.
please use the latest btmon and check if it can read your trace.
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.741093
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.742088
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.743102
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.744105
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.745109
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.746104
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.747097
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.748090
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.749078
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.750070
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.751061
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.752054
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.753046
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.754038
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.755031
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.756025
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.757013
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758006
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758999
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.759991
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.760983
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.761975
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.762963
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.763956
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.764948
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.765941
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.766933
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.767926
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.768919
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.769914
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.770909
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.771908
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.772904
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.773898
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.774892
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.775890
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.776882
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.777877
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.778871
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.779869
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.780864
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.781858
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.782852
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.783850
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.784845
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.785839
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.786833
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.787831
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.788826
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.789820
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.790814
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.791813
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.792809
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.793803
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.794798
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.795797
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.796791
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.797786
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.798779
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.799778
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.800774
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.801769
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.802763
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.803761
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.804755
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.805749
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.806743
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.807741
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.808737
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.809731
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.810725
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.811725
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.812719
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.813714
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.814708
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.815705
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816378
>>> 02 01 01 00 00 .....
>>
>> Why do I see only HCI events here? Is this event conveying any useful information. It is kinda complicated that this is 0xe4 event code which is actually reserved for future use by the Bluetooth SIG. Are there any accompanying HCI commands for this and they just not make it into btmon?
>>
>
> I have made all vendor HCI commands go through BlueZ core in v2 patch.
>
> And for these HCI events, they are all corresponding to vendor ACL data, applied only to firmware setup packets, but they're not being sent via BlueZ core, so they are not being logged in btmon.
>
> As for its event, where heading 0xe4 refers to a vendor event and is used on notification of that either vendor ACL data or vendor HCI command have been done.
I would prefer if everything goes via the Bluetooth core since then we have it all properly scheduled. Sending things down the ACL data path however if kinda funky. Does your hardware accept sending command both via ACL data and as HCI command? If so, then I would prefer sending them as HCI commands since the speed improvement you think you are getting is neglectable on Linux (I have been down that path). This seems to be a pure optimization when Windows is driving the device.
And the vendor event 0xe4 is really only received during firmware download? It is not ever received during normal operation?
>
>>
>>
>>> < HCI Command: Vendor (0x3f|0x006f) plen 5 [hci0] 6.816413
>>> 01 07 01 00 04 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816536
>>> 02 07 01 00 00 .....
>>> < HCI Command: Vendor (0x3f|0x006f) plen 6 [hci0] 8.845071
>>> 01 06 02 00 00 01 ......
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 8.923456
>>> 02 06 01 00 00 .....
>>
>> Here it looks like you have 0x006f opcode with first octet 0x01 for command and then vendor event 0xe4 with first octet 0x02 for event. I assume the second octet is then the vendor command code for these.
>>
>
> Yes, you're right.
>
>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 10.861118
>>>> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.865763
>>> Reset (0x03|0x0003) ncmd 1
>>> Status: Success (0x00)
>>> < HCI Command: Read Local Supported Fe.. (0x04|0x0003) plen 0 [hci0] 10.865805
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.865965
>>> Read Local Supported Features (0x04|0x0003) ncmd 1
>>> Status: Success (0x00)
>>> Features: 0xbf 0x3e 0x8d 0xfe 0xdb 0xff 0x7b 0x87
>>> 3 slot packets
>>> 5 slot packets
>>> Encryption
>>> Slot offset
>>> Timing accuracy
>>> Role switch
>>> Sniff mode
>>> Power control requests
>>> Channel quality driven data rate (CQDDR)
>>> SCO link
>>> HV2 packets
>>> HV3 packets
>>> CVSD synchronous data
>>> Power control
>>> Transparent synchronous data
>>> Broadcast Encryption
>>> Enhanced Data Rate ACL 2 Mbps mode
>>> Enhanced Data Rate ACL 3 Mbps mode
>>> Enhanced inquiry scan
>>> Interlaced inquiry scan
>>> Interlaced page scan
>>> RSSI with inquiry results
>>> Extended SCO link (EV3 packets)
>>> EV4 packets
>>> EV5 packets
>>> AFH capable slave
>>> AFH classification slave
>>> LE Supported (Controller)
>>> 3-slot Enhanced Data Rate ACL packets
>>> 5-slot Enhanced Data Rate ACL packets
>>> Sniff subrating
>>> Pause encryption
>>> AFH capable master
>>> AFH classification master
>>> Enhanced Data Rate eSCO 2 Mbps mode
>>> Enhanced Data Rate eSCO 3 Mbps mode
>>> 3-slot Enhanced Data Rate eSCO packets
>>> Extended Inquiry Response
>>> Simultaneous LE and BR/EDR (Controller)
>>> Secure Simple Pairing
>>> Encapsulated PDU
>>> Erroneous Data Reporting
>>> Non-flushable Packet Boundary Flag
>>> Link Supervision Timeout Changed Event
>>> Inquiry TX Power Level
>>> Enhanced Power Control
>>> Extended features
>>> < HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0 [hci0] 10.865987
>>>> HCI Event: Vendor (0xff) plen 9 [hci0] 10.866259
>>> 29 19 09 17 20 48 07 11 00 )... H?
>>
>> Is this meant to happen here?
>>
>
> If event received is not expected as the specification defines, I think it's probably incorrect.
>
> But it requires more discussion with firmware people to make it clearer.
Please check and let them decode what this event means.
>
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.866372
>>> Read Local Version Information (0x04|0x0001) ncmd 1
>>> Status: Success (0x00)
>>> HCI version: Bluetooth 4.2 (0x08) - Revision 4359 (0x1107)
>>> LMP version: Bluetooth 4.2 (0x08) - Subversion 2329 (0x0919)
>>> Manufacturer: MediaTek, Inc. (70)
>>> < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 [hci0] 10.866391
>>>> HCI Event: Command Complete (0x0e) plen 10 [hci0] 10.866539
>>> Read BD ADDR (0x04|0x0009) ncmd 1
>>> Status: Success (0x00)
>>> Address: 00:00:46:76:22:01 (OLIVETTI NORTH AMERICA)
>>> < HCI Command: Read Buffer Size (0x04|0x0005) plen 0 [hci0] 10.866609
>>>> HCI Event: Command Complete (0x0e) plen 11 [hci0] 10.866754
>>> Read Buffer Size (0x04|0x0005) ncmd 1
>>> Status: Success (0x00)
>>> ACL MTU: 1021 ACL max packet: 8
>>> SCO MTU: 184 SCO max packet: 1
>>> < HCI Command: Read Class of Device (0x03|0x0023) plen 0 [hci0] 10.866775
>>>> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.866920
>>> Read Class of Device (0x03|0x0023) ncmd 1
>>> Status: Success (0x00)
>>> Class: 0x001f00
>>> Major class: Uncategorized, specific device code not specified
>>> Minor class: 0x00
>>> < HCI Command: Read Local Name (0x03|0x0014) plen 0 [hci0] 10.866939
>>>> HCI Event: Command Complete (0x0e) plen 252 [hci0] 10.867256
>>> Read Local Name (0x03|0x0014) ncmd 1
>>> Status: Success (0x00)
>>> Name: MTK MT7622 #1
>>> < HCI Command: Read Voice Setting (0x03|0x0025) plen 0 [hci0] 10.867308
>>>> HCI Event: Command Complete (0x0e) plen 6 [hci0] 10.867447
>>> Read Voice Setting (0x03|0x0025) ncmd 1
>>> Status: Success (0x00)
>>> Setting: 0x0060
>>> Input Coding: Linear
>>> Input Data Format: 2's complement
>>> Input Sample Size: 16-bit
>>> # of bits padding at MSB: 0
>>> Air Coding Format: CVSD
>>> < HCI Command: Read Number of Supporte.. (0x03|0x0038) plen 0 [hci0] 10.867474
>>>> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.867611
>>> Read Number of Supported IAC (0x03|0x0038) ncmd 1
>>> Status: Success (0x00)
>>> Number of IAC: 4
>>> < HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 [hci0] 10.867678
>>>> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.867865
>>> Read Current IAC LAP (0x03|0x0039) ncmd 1
>>> Status: Success (0x00)
>>> Number of IAC: 1
>>> Access code: 0x9e8b33 (General Inquiry)
>>> < HCI Command: Set Event Filter (0x03|0x0005) plen 1 [hci0] 10.867890
>>> Type: Clear All Filters (0x00)
>>>> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868033
>>> Set Event Filter (0x03|0x0005) ncmd 1
>>> Status: Success (0x00)
>>> < HCI Command: Write Connection Accept.. (0x03|0x0016) plen 2 [hci0] 10.868054
>>> Timeout: 20000.000 msec (0x7d00)
>>>> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868235
>>> Write Connection Accept Timeout (0x03|0x0016) ncmd 1
>>> Status: Success (0x00)
>>> < HCI Command: LE Read Buffer Size (0x08|0x0002) plen 0 [hci0] 10.868262
>>>> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.868392
>>> LE Read Buffer Size (0x08|0x0002) ncmd 1
>>> Status: Success (0x00)
>>> Data packet length: 251
>>> Num data packets: 8
>>> < HCI Command: LE Read Local Supported.. (0x08|0x0003) plen 0 [hci0] 10.868413
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868587
>>> LE Read Local Supported Features (0x08|0x0003) ncmd 1
>>> Status: Success (0x00)
>>> Features: 0xfd 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>>> LE Encryption
>>> Extended Reject Indication
>>> Slave-initiated Features Exchange
>>> LE Ping
>>> LE Data Packet Length Extension
>>> LL Privacy
>>> Extended Scanner Filter Policies
>>> < HCI Command: LE Read Supported States (0x08|0x001c) plen 0 [hci0] 10.868646
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868787
>>> LE Read Supported States (0x08|0x001c) ncmd 1
>>> Status: Success (0x00)
>>> States: 0x000000001fffffff
>>> Non-connectable Advertising State
>>> Scannable Advertising State
>>> Connectable Advertising State
>>> High Duty Cycle Directed Advertising State
>>> Passive Scanning State
>>> Active Scanning State
>>> Initiating State
>>> and Connection State (Master Role)
>>> Connection State (Slave Role)
>>> Non-connectable Advertising State
>>> and Passive Scanning State
>>> Scannable Advertising State
>>> and Passive Scanning State
>>> Connectable Advertising State
>>> and Passive Scanning State
>>> High Duty Cycle Directed Advertising State
>>> and Passive Scanning State
>>> Non-connectable Advertising State
>>> and Active Scanning State
>>> Scannable Advertising State
>>> and Active Scanning State
>>> Connectable Advertising State
>>> and Active Scanning State
>>> High Duty Cycle Directed Advertising State
>>> and Active Scanning State
>>> Non-connectable Advertising State
>>> and Initiating State
>>> Scannable Advertising State
>>> and Initiating State
>>> Non-connectable Advertising State
>>> and Connection State (Master Role)
>>> Scannable Advertising State
>>> and Connection State (Master Role)
>>> Non-connectable Advertising State
>>> and Connection State (Slave Role)
>>> Scannable Advertising State
>>> and Connection State (Slave Role)
>>> Passive Scanning State
>>> and Initiating State
>>> Active Scanning State
>>> and Initiating State
>>> Passive Scanning State
>>> and Connection State (Master Role)
>>> Active Scanning State
>>> and Connection State (Master Role)
>>> Passive Scanning State
>>> and Connection State (Slave Role)
>>> Active Scanning State
>>> and Connection State (Slave Role)
>>> Initiating State
>>> and Connection State (Master Role)
>>> and Master Role & Master Role
>>> < HCI Command: Read Local Supported Co.. (0x04|0x0002) plen 0 [hci0] 10.868807
>>>> HCI Event: Command Complete (0x0e) plen 68 [hci0] 10.868985
>>> Read Local Supported Commands (0x04|0x0002) ncmd 1
>>> Status: Success (0x00)
>>> Commands: 176 entries
>>> Inquiry (Octet 0 - Bit 0)
>>> Inquiry Cancel (Octet 0 - Bit 1)
>>> Periodic Inquiry Mode (Octet 0 - Bit 2)
>>> Exit Periodic Inquiry Mode (Octet 0 - Bit 3)
>>> Create Connection (Octet 0 - Bit 4)
>>> Disconnect (Octet 0 - Bit 5)
>>> Add SCO Connection (Octet 0 - Bit 6)
>>> Create Connection Cancel (Octet 0 - Bit 7)
>>> Accept Connection Request (Octet 1 - Bit 0)
>>> Reject Connection Request (Octet 1 - Bit 1)
>>> Link Key Request Reply (Octet 1 - Bit 2)
>>> Link Key Request Negative Reply (Octet 1 - Bit 3)
>>> PIN Code Request Reply (Octet 1 - Bit 4)
>>> PIN Code Request Negative Reply (Octet 1 - Bit 5)
>>> Change Connection Packet Type (Octet 1 - Bit 6)
>>> Authentication Requested (Octet 1 - Bit 7)
>>> Set Connection Encryption (Octet 2 - Bit 0)
>>> Change Connection Link Key (Octet 2 - Bit 1)
>>> Master Link Key (Octet 2 - Bit 2)
>>> Remote Name Request (Octet 2 - Bit 3)
>>> Remote Name Request Cancel (Octet 2 - Bit 4)
>>> Read Remote Supported Features (Octet 2 - Bit 5)
>>> Read Remote Extended Features (Octet 2 - Bit 6)
>>> Read Remote Version Information (Octet 2 - Bit 7)
>>> Read Clock Offset (Octet 3 - Bit 0)
>>> Read LMP Handle (Octet 3 - Bit 1)
>>> Sniff Mode (Octet 4 - Bit 2)
>>> Exit Sniff Mode (Octet 4 - Bit 3)
>>> QoS Setup (Octet 4 - Bit 6)
>>> Role Discovery (Octet 4 - Bit 7)
>>> Switch Role (Octet 5 - Bit 0)
>>> Read Link Policy Settings (Octet 5 - Bit 1)
>>> Write Link Policy Settings (Octet 5 - Bit 2)
>>> Read Default Link Policy Settings (Octet 5 - Bit 3)
>>> Write Default Link Policy Settings (Octet 5 - Bit 4)
>>> Flow Specification (Octet 5 - Bit 5)
>>> Set Event Mask (Octet 5 - Bit 6)
>>> Reset (Octet 5 - Bit 7)
>>> Set Event Filter (Octet 6 - Bit 0)
>>> Flush (Octet 6 - Bit 1)
>>> Read PIN Type (Octet 6 - Bit 2)
>>> Write PIN Type (Octet 6 - Bit 3)
>>> Create New Unit Key (Octet 6 - Bit 4)
>>> Read Stored Link Key (Octet 6 - Bit 5)
>>> Write Stored Link Key (Octet 6 - Bit 6)
>>> Delete Stored Link Key (Octet 6 - Bit 7)
>>> Write Local Name (Octet 7 - Bit 0)
>>> Read Local Name (Octet 7 - Bit 1)
>>> Read Connection Accept Timeout (Octet 7 - Bit 2)
>>> Write Connection Accept Timeout (Octet 7 - Bit 3)
>>> Read Page Timeout (Octet 7 - Bit 4)
>>> Write Page Timeout (Octet 7 - Bit 5)
>>> Read Scan Enable (Octet 7 - Bit 6)
>>> Write Scan Enable (Octet 7 - Bit 7)
>>> Read Page Scan Activity (Octet 8 - Bit 0)
>>> Write Page Scan Activity (Octet 8 - Bit 1)
>>> Read Inquiry Scan Activity (Octet 8 - Bit 2)
>>> Write Inquiry Scan Activity (Octet 8 - Bit 3)
>>> Read Authentication Enable (Octet 8 - Bit 4)
>>> Write Authentication Enable (Octet 8 - Bit 5)
>>> Read Encryption Mode (Octet 8 - Bit 6)
>>> Write Encryption Mode (Octet 8 - Bit 7)
>>> Read Class of Device (Octet 9 - Bit 0)
>>> Write Class of Device (Octet 9 - Bit 1)
>>> Read Voice Setting (Octet 9 - Bit 2)
>>> Write Voice Setting (Octet 9 - Bit 3)
>>> Read Automatic Flush Timeout (Octet 9 - Bit 4)
>>> Write Automatic Flush Timeout (Octet 9 - Bit 5)
>>> Read Num Broadcast Retransmissions (Octet 9 - Bit 6)
>>> Write Num Broadcast Retransmissions (Octet 9 - Bit 7)
>>> Read Transmit Power Level (Octet 10 - Bit 2)
>>> Read Sync Flow Control Enable (Octet 10 - Bit 3)
>>> Write Sync Flow Control Enable (Octet 10 - Bit 4)
>>> Set Controller To Host Flow Control (Octet 10 - Bit 5)
>>> Host Buffer Size (Octet 10 - Bit 6)
>>> Host Number of Completed Packets (Octet 10 - Bit 7)
>>> Read Link Supervision Timeout (Octet 11 - Bit 0)
>>> Write Link Supervision Timeout (Octet 11 - Bit 1)
>>> Read Number of Supported IAC (Octet 11 - Bit 2)
>>> Read Current IAC LAP (Octet 11 - Bit 3)
>>> Write Current IAC LAP (Octet 11 - Bit 4)
>>> Read Page Scan Mode (Octet 11 - Bit 7)
>>> Write Page Scan Mode (Octet 12 - Bit 0)
>>> Set AFH Host Channel Classification (Octet 12 - Bit 1)
>>> Read Inquiry Scan Type (Octet 12 - Bit 4)
>>> Write Inquiry Scan Type (Octet 12 - Bit 5)
>>> Read Inquiry Mode (Octet 12 - Bit 6)
>>> Write Inquiry Mode (Octet 12 - Bit 7)
>>> Read Page Scan Type (Octet 13 - Bit 0)
>>> Write Page Scan Type (Octet 13 - Bit 1)
>>> Read AFH Channel Assessment Mode (Octet 13 - Bit 2)
>>> Write AFH Channel Assessment Mode (Octet 13 - Bit 3)
>>> Read Local Version Information (Octet 14 - Bit 3)
>>> Read Local Supported Features (Octet 14 - Bit 5)
>>> Read Local Extended Features (Octet 14 - Bit 6)
>>> Read Buffer Size (Octet 14 - Bit 7)
>>> Read Country Code (Octet 15 - Bit 0)
>>> Read BD ADDR (Octet 15 - Bit 1)
>>> Read Failed Contact Counter (Octet 15 - Bit 2)
>>> Reset Failed Contact Counter (Octet 15 - Bit 3)
>>> Read Link Quality (Octet 15 - Bit 4)
>>> Read RSSI (Octet 15 - Bit 5)
>>> Read AFH Channel Map (Octet 15 - Bit 6)
>>> Read Clock (Octet 15 - Bit 7)
>>> Read Loopback Mode (Octet 16 - Bit 0)
>>> Write Loopback Mode (Octet 16 - Bit 1)
>>> Enable Device Under Test Mode (Octet 16 - Bit 2)
>>> Setup Synchronous Connection (Octet 16 - Bit 3)
>>> Accept Synchronous Connection Request (Octet 16 - Bit 4)
>>> Reject Synchronous Connection Request (Octet 16 - Bit 5)
>>> Read Extended Inquiry Response (Octet 17 - Bit 0)
>>> Write Extended Inquiry Response (Octet 17 - Bit 1)
>>> Refresh Encryption Key (Octet 17 - Bit 2)
>>> Sniff Subrating (Octet 17 - Bit 4)
>>> Read Simple Pairing Mode (Octet 17 - Bit 5)
>>> Write Simple Pairing Mode (Octet 17 - Bit 6)
>>> Read Local OOB Data (Octet 17 - Bit 7)
>>> Read Inquiry Response TX Power Level (Octet 18 - Bit 0)
>>> Write Inquiry Transmit Power Level (Octet 18 - Bit 1)
>>> Read Default Erroneous Data Reporting (Octet 18 - Bit 2)
>>> Write Default Erroneous Data Reporting (Octet 18 - Bit 3)
>>> IO Capability Request Reply (Octet 18 - Bit 7)
>>> User Confirmation Request Reply (Octet 19 - Bit 0)
>>> User Confirmation Request Neg Reply (Octet 19 - Bit 1)
>>> User Passkey Request Reply (Octet 19 - Bit 2)
>>> User Passkey Request Negative Reply (Octet 19 - Bit 3)
>>> Remote OOB Data Request Reply (Octet 19 - Bit 4)
>>> Write Simple Pairing Debug Mode (Octet 19 - Bit 5)
>>> Enhanced Flush (Octet 19 - Bit 6)
>>> Remote OOB Data Request Neg Reply (Octet 19 - Bit 7)
>>> Send Keypress Notification (Octet 20 - Bit 2)
>>> IO Capability Request Negative Reply (Octet 20 - Bit 3)
>>> Read Encryption Key Size (Octet 20 - Bit 4)
>>> Set Event Mask Page 2 (Octet 22 - Bit 2)
>>> Read Enhanced Transmit Power Level (Octet 24 - Bit 0)
>>> Enhanced Setup Synchronous Connection (Octet 29 - Bit 3)
>>> Enhanced Accept Synchronous Connection Request (Octet 29 - Bit 4)
>>> Read Local Supported Codecs (Octet 29 - Bit 5)
>>> Set Triggered Clock Capture (Octet 30 - Bit 5)
>>> Truncated Page (Octet 30 - Bit 6)
>>> Truncated Page Cancel (Octet 30 - Bit 7)
>>> Set Connectionless Slave Broadcast (Octet 31 - Bit 0)
>>> Start Synchronization Train (Octet 31 - Bit 2)
>>> Set Reserved LT_ADDR (Octet 31 - Bit 4)
>>> Delete Reserved LT_ADDR (Octet 31 - Bit 5)
>>> Set Connectionless Slave Broadcast Data (Octet 31 - Bit 6)
>>> Read Synchronization Train Parameters (Octet 31 - Bit 7)
>>> Write Synchronization Train Parameters (Octet 32 - Bit 0)
>>> Remote OOB Extended Data Request Reply (Octet 32 - Bit 1)
>>> Read Authenticated Payload Timeout (Octet 32 - Bit 4)
>>> Write Authenticated Payload Timeout (Octet 32 - Bit 5)
>>> Read Local OOB Extended Data (Octet 32 - Bit 6)
>>> Write Secure Connections Test Mode (Octet 32 - Bit 7)
>>> Read Extended Page Timeout (Octet 33 - Bit 0)
>>> Write Extended Page Timeout (Octet 33 - Bit 1)
>>> Read Extended Inquiry Length (Octet 33 - Bit 2)
>>> Write Extended Inquiry Length (Octet 33 - Bit 3)
>>> LE Set Data Length (Octet 33 - Bit 6)
>>> LE Read Suggested Default Data Length (Octet 33 - Bit 7)
>>> LE Write Suggested Default Data Length (Octet 34 - Bit 0)
>>> LE Read Local P-256 Public Key (Octet 34 - Bit 1)
>>> LE Generate DHKey (Octet 34 - Bit 2)
>>> LE Add Device To Resolving List (Octet 34 - Bit 3)
>>> LE Remove Device From Resolving List (Octet 34 - Bit 4)
>>> LE Clear Resolving List (Octet 34 - Bit 5)
>>> LE Read Resolving List Size (Octet 34 - Bit 6)
>>> LE Read Peer Resolvable Address (Octet 34 - Bit 7)
>>> LE Read Local Resolvable Address (Octet 35 - Bit 0)
>>> LE Set Address Resolution Enable (Octet 35 - Bit 1)
>>> LE Set Resolvable Private Address Timeout (Octet 35 - Bit 2)
>>> LE Read Maximum Data Length (Octet 35 - Bit 3)
>>> Octet 35 - Bit 4
>>> Octet 35 - Bit 5
>>> Octet 35 - Bit 6
>>> Octet 35 - Bit 7
>>> Octet 36 - Bit 0
>>
>> So you support the PHY commands, but do not indicate support LE 2M or LE Coded? Also these are Bluetooth 5.0 commands.
>>
>
> To be honest. When I ported the device into Bluez core, a unexpected event for LE read local feature would cause a fail at Bluez core, so I made a hack on Bluez core
>
> to allow that I can keeping bring up the device without be blocked by the issue most probably from firmware.
>
> Below code snippet is the only thing I added to avoid a fail at Bluez core to bring up the device.
>
> @@ -927,6 +927,8 @@ static void hci_cc_le_read_local_features(struct hci_dev *hdev,
> return;
>
> memcpy(hdev->le_features, rp->features, 8);
> + hdev->le_features[0] = 0;
> + hdev->le_features[1] = 0;
> }
Send me the trace where you didn?t clear the feature bits and I check what is going on. I doubt that we have a bug, but maybe some of the commands are optional and we should add an appropriate check. Or you guys need to fix your firmware. A new btmon should decode all bits properly.
Regards
Marcel
^ permalink raw reply
* [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Nixiaoming @ 2018-05-30 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-FvWoDbMV2veh8BzW7ihbvaw-cd+rK5x_TLq0UC99FNg@mail.gmail.com>
On 30 May 2018 at 2:07PM Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org] wrote:
>On 30 May 2018 at 07:58, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * nixiaoming <nixiaoming@huawei.com> wrote:
>>
>>> mark_rodata_ro is only called by the function mark_readonly
>>> when CONFIG_STRICT_KERNEL_RWX=y
>>>
>>> if CONFIG_STRICT_KERNEL_RWX is not set
>>> a compile warning may be triggered: unused function
>....
>>
>> NAK, this is very ugly and the changelog doesn't appear to be true: the build
>> warning does not trigger in the default build, correct?
>>
>
>I don't see how the build warning could trigger at all, given that
>mark_rodata_ro() has external linkage.
>
Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=x86_64
the build warning does not trigger in the default build,
but it should be more appropriate to add CONFIG control to the code.
^ permalink raw reply
* [PATCH v3 4/5] clocksource: add driver for i.MX EPIT timer
From: Vladimir Zapolskiy @ 2018-05-30 6:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529170436.22711-5-peron.clem@gmail.com>
Hi Cl?ment,
please find some more review comments.
On 05/29/2018 08:04 PM, Cl?ment P?ron wrote:
> From: Colin Didier <colin.didier@devialet.com>
>
> Add driver for NXP's EPIT timer used in i.MX 6 family of SoC.
>
> Signed-off-by: Colin Didier <colin.didier@devialet.com>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> ---
> drivers/clocksource/Kconfig | 12 ++
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-imx-epit.c | 283 +++++++++++++++++++++++++++
> 3 files changed, 296 insertions(+)
> create mode 100644 drivers/clocksource/timer-imx-epit.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 8e8a09755d10..920a0874f3a4 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -576,6 +576,18 @@ config H8300_TPU
> This enables the clocksource for the H8300 platform with the
> H8S2678 cpu.
>
> +config CLKSRC_IMX_EPIT
> + bool "Clocksource using i.MX EPIT"
> + depends on ARM && CLKDEV_LOOKUP && OF && (ARCH_MXC || COMPILE_TEST)
Here 'depends on ARM' can be removed, because ARCH_MXC implies it.
Also ARCH_MXC implies ARCH_MULTIPLATFORM, which implies USE_OF in turn,
so I would say that the following line is correct, sorry about a previous
comment asking to add an explicit OF dependency:
depends on CLKDEV_LOOKUP && (ARCH_MXC || COMPILE_TEST)
However most of the clocksource drivers follow 'bool "..." if COMPILE_TEST'
pattern, and it might be preferable to maintainers.
> + select TIMER_OF
The driver does not have this dependency.
> + select CLKSRC_MMIO
> + help
> + This enables EPIT support available on some i.MX platforms.
> + Normally you don't have a reason to do so as the EPIT has
> + the same features and uses the same clocks as the GPT.
> + Anyway, on some systems the GPT may be in use for other
> + purposes.
> +
> config CLKSRC_IMX_GPT
> bool "Clocksource using i.MX GPT" if COMPILE_TEST
> depends on ARM && CLKDEV_LOOKUP
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 00caf37e52f9..d9426f69ec69 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -69,6 +69,7 @@ obj-$(CONFIG_INTEGRATOR_AP_TIMER) += timer-integrator-ap.o
> obj-$(CONFIG_CLKSRC_VERSATILE) += versatile.o
> obj-$(CONFIG_CLKSRC_MIPS_GIC) += mips-gic-timer.o
> obj-$(CONFIG_CLKSRC_TANGO_XTAL) += tango_xtal.o
> +obj-$(CONFIG_CLKSRC_IMX_EPIT) += timer-imx-epit.o
> obj-$(CONFIG_CLKSRC_IMX_GPT) += timer-imx-gpt.o
> obj-$(CONFIG_CLKSRC_IMX_TPM) += timer-imx-tpm.o
> obj-$(CONFIG_ASM9260_TIMER) += asm9260_timer.o
> diff --git a/drivers/clocksource/timer-imx-epit.c b/drivers/clocksource/timer-imx-epit.c
> new file mode 100644
> index 000000000000..87025d5f3a97
> --- /dev/null
> +++ b/drivers/clocksource/timer-imx-epit.c
> @@ -0,0 +1,283 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * i.MX EPIT Timer
> + *
> + * Copyright (C) 2010 Sascha Hauer <s.hauer@pengutronix.de>
> + * Copyright (C) 2018 Colin Didier <colin.didier@devialet.com>
> + * Copyright (C) 2018 Cl?ment P?ron <clement.peron@devialet.com>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clockchips.h>
> +#include <linux/err.h>
The include above can be dropped.
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
The include above can be dropped.
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of.h>
The include above can be dropped.
> +#include <linux/sched_clock.h>
> +#include <linux/slab.h>
> +
> +#define EPITCR 0x00
> +#define EPITSR 0x04
> +#define EPITLR 0x08
> +#define EPITCMPR 0x0c
> +#define EPITCNR 0x10
> +
> +#define EPITCR_EN BIT(0)
> +#define EPITCR_ENMOD BIT(1)
> +#define EPITCR_OCIEN BIT(2)
> +#define EPITCR_RLD BIT(3)
> +#define EPITCR_PRESC(x) (((x) & 0xfff) << 4)
> +#define EPITCR_SWR BIT(16)
> +#define EPITCR_IOVW BIT(17)
> +#define EPITCR_DBGEN BIT(18)
> +#define EPITCR_WAITEN BIT(19)
> +#define EPITCR_RES BIT(20)
> +#define EPITCR_STOPEN BIT(21)
> +#define EPITCR_OM_DISCON (0 << 22)
> +#define EPITCR_OM_TOGGLE (1 << 22)
> +#define EPITCR_OM_CLEAR (2 << 22)
> +#define EPITCR_OM_SET (3 << 22)
> +#define EPITCR_CLKSRC_OFF (0 << 24)
> +#define EPITCR_CLKSRC_PERIPHERAL (1 << 24)
> +#define EPITCR_CLKSRC_REF_HIGH (2 << 24)
> +#define EPITCR_CLKSRC_REF_LOW (3 << 24)
> +
> +#define EPITSR_OCIF BIT(0)
> +
> +struct epit_timer {
> + void __iomem *base;
> + int irq;
> + struct clk *clk_per;
> + struct clock_event_device ced;
> + struct irqaction act;
> +};
> +
> +static void __iomem *sched_clock_reg;
> +
> +static inline struct epit_timer *to_epit_timer(struct clock_event_device *ced)
> +{
> + return container_of(ced, struct epit_timer, ced);
> +}
> +
> +static inline void epit_irq_disable(struct epit_timer *epittm)
> +{
> + u32 val;
> +
> + val = readl_relaxed(epittm->base + EPITCR);
> + writel_relaxed(val & ~EPITCR_OCIEN, epittm->base + EPITCR);
> +}
> +
> +static inline void epit_irq_enable(struct epit_timer *epittm)
> +{
> + u32 val;
> +
> + val = readl_relaxed(epittm->base + EPITCR);
> + writel_relaxed(val | EPITCR_OCIEN, epittm->base + EPITCR);
> +}
> +
> +static void epit_irq_acknowledge(struct epit_timer *epittm)
> +{
> + writel_relaxed(EPITSR_OCIF, epittm->base + EPITSR);
> +}
> +
> +static u64 notrace epit_read_sched_clock(void)
> +{
> + return ~readl_relaxed(sched_clock_reg);
> +}
> +
> +static int __init epit_clocksource_init(struct epit_timer *epittm)
> +{
> + unsigned int c = clk_get_rate(epittm->clk_per);
> +
> + sched_clock_reg = epittm->base + EPITCNR;
> + sched_clock_register(epit_read_sched_clock, 32, c);
> +
> + return clocksource_mmio_init(epittm->base + EPITCNR, "epit", c, 200, 32,
> + clocksource_mmio_readl_down);
> +}
> +
I would suggest to place epit_clocksource_init() function right before
epit_timer_init().
> +static int epit_set_next_event(unsigned long cycles,
> + struct clock_event_device *ced)
> +{
> + struct epit_timer *epittm = to_epit_timer(ced);
> + unsigned long tcmp;
> +
> + tcmp = readl_relaxed(epittm->base + EPITCNR) - cycles;
> + writel_relaxed(tcmp, epittm->base + EPITCMPR);
> +
> + return 0;
> +}
> +
> +/* Left event sources disabled, no more interrupts appear */
> +static int epit_shutdown(struct clock_event_device *ced)
> +{
> + struct epit_timer *epittm = to_epit_timer(ced);
> + unsigned long flags;
> +
> + /*
> + * The timer interrupt generation is disabled at least
> + * for enough time to call epit_set_next_event()
> + */
> + local_irq_save(flags);
> +
> + /* Disable interrupt in EPIT module */
> + epit_irq_disable(epittm);
> +
> + /* Clear pending interrupt */
> + epit_irq_acknowledge(epittm);
> +
> + local_irq_restore(flags);
> +
> + return 0;
> +}
> +
> +static int epit_set_oneshot(struct clock_event_device *ced)
> +{
> + struct epit_timer *epittm = to_epit_timer(ced);
> + unsigned long flags;
> +
> + /*
> + * The timer interrupt generation is disabled at least
> + * for enough time to call epit_set_next_event()
> + */
> + local_irq_save(flags);
> +
> + /* Disable interrupt in EPIT module */
> + epit_irq_disable(epittm);
> +
> + /* Clear pending interrupt, only while switching mode */
> + if (!clockevent_state_oneshot(ced))
> + epit_irq_acknowledge(epittm);
> +
> + /*
> + * Do not put overhead of interrupt enable/disable into
> + * epit_set_next_event(), the core has about 4 minutes
> + * to call epit_set_next_event() or shutdown clock after
> + * mode switching
> + */
> + epit_irq_enable(epittm);
> + local_irq_restore(flags);
> +
> + return 0;
> +}
> +
> +static irqreturn_t epit_timer_interrupt(int irq, void *dev_id)
> +{
> + struct clock_event_device *ced = dev_id;
> + struct epit_timer *epittm = to_epit_timer(ced);
> +
> + epit_irq_acknowledge(epittm);
> +
> + ced->event_handler(ced);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int __init epit_clockevent_init(struct epit_timer *epittm)
> +{
> + struct clock_event_device *ced = &epittm->ced;
> + struct irqaction *act = &epittm->act;
> +
> + ced->name = "epit";
> + ced->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_DYNIRQ;
> + ced->set_state_shutdown = epit_shutdown;
> + ced->tick_resume = epit_shutdown;
> + ced->set_state_oneshot = epit_set_oneshot;
> + ced->set_next_event = epit_set_next_event;
> + ced->rating = 200;
> + ced->cpumask = cpumask_of(0);
> + ced->irq = epittm->irq;
> + clockevents_config_and_register(ced, clk_get_rate(epittm->clk_per),
> + 0xff, 0xfffffffe);
Please indent the wrapped line.
> +
> + act->name = "i.MX EPIT Timer Tick",
> + act->flags = IRQF_TIMER | IRQF_IRQPOLL;
> + act->handler = epit_timer_interrupt;
> + act->dev_id = ced;
> +
> + /* Make irqs happen */
> + return setup_irq(epittm->irq, act);
> +}
> +
> +static int __init epit_timer_init(struct device_node *np)
> +{
> + struct epit_timer *epittm;
> + struct clk *clk_ipg;
> + int ret;
> +
> + epittm = kzalloc(sizeof(*epittm), GFP_KERNEL);
> + if (!epittm)
> + return -ENOMEM;
> +
> + epittm->base = of_iomap(np, 0);
> + if (!epittm->base) {
> + ret = -ENXIO;
> + goto out_kfree;
> + }
> +
> + epittm->irq = irq_of_parse_and_map(np, 0);
> + if (!epittm->irq) {
> + ret = -EINVAL;
> + goto out_iounmap;
> + }
> +
> + clk_ipg = of_clk_get_by_name(np, "ipg");
> + if (IS_ERR(clk_ipg)) {
> + pr_err("i.MX EPIT: unable to get clk_ipg\n");
> + ret = PTR_ERR(clk_ipg);
> + goto out_iounmap;
> + }
> +
> + ret = clk_prepare_enable(clk_ipg);
> + if (ret) {
> + pr_err("i.MX EPIT: unable to prepare+enable clk_ipg\n");
> + goto out_clk_ipg_disable;
> + }
> +
> + epittm->clk_per = of_clk_get_by_name(np, "per");
> + if (IS_ERR(epittm->clk_per)) {
> + pr_err("i.MX EPIT: unable to get clk_per\n");
> + ret = PTR_ERR(epittm->clk_per);
> + goto out_clk_ipg_disable;
> + }
> +
> + ret = clk_prepare_enable(epittm->clk_per);
> + if (ret) {
> + pr_err("i.MX EPIT: unable to prepare+enable clk_per\n");
> + goto out_clk_ipg_disable;
> + }
> +
> + /* Initialise to a known state (all timers off, and timing reset) */
> + writel_relaxed(0x0, epittm->base + EPITCR);
> + writel_relaxed(0xffffffff, epittm->base + EPITLR);
> + writel_relaxed(EPITCR_EN | EPITCR_CLKSRC_REF_HIGH | EPITCR_WAITEN,
> + epittm->base + EPITCR);
> +
> + ret = epit_clocksource_init(epittm);
> + if(ret) {
Add a space before left parenthesis.
> + pr_err("i.MX EPIT: failed to init clocksource\n");
> + goto out_clk_per_disable;
> + }
> +
> + ret = epit_clockevent_init(epittm);
> + if(ret) {
Add a space before left parenthesis.
> + pr_err("i.MX EPIT: failed to init clockevent\n");
> + goto out_clk_per_disable;
> + }
> +
> + return 0;
> +
> +out_clk_per_disable:
> + clk_disable_unprepare(epittm->clk_per);
> +out_clk_ipg_disable:
> + clk_disable_unprepare(clk_ipg);
> +out_iounmap:
> + iounmap(epittm->base);
> +out_kfree:
> + kfree(epittm);
> +
> + return ret;
> +}
> +TIMER_OF_DECLARE(mx6q_timer, "fsl,imx6q-epit", epit_timer_init);
>
Here "fsl,imx31-epit" would be way better than "fsl,imx6q-epit", please
fix it in the documentation as well.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v2 5/8] pinctrl: optionally stop deferring probe at end of initcalls
From: Linus Walleij @ 2018-05-30 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-6-robh@kernel.org>
On Thu, May 24, 2018 at 7:50 PM, Rob Herring <robh@kernel.org> wrote:
> If the pinctrl node in DT indicates that pin setup is optional and the
> defaults can be used with the 'pinctrl-use-default', then only defer probe
> until initcalls are done. This gives platforms the option to work without
> their pinctrl driver being enabled.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
I trust that you know what you're doing so I guess
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 4/4] mmc: sdhci-msm: Add sdhci msm register write APIs which wait for pwr irq
From: Vijay Viswanath @ 2018-05-30 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74a4fe0e-7ae8-9f49-5614-1e01ae977475@linaro.org>
Hi Georgi,
Thanks for testing the patch on 8096 and pointing out this issue.
The issue is coming because, when card is removed, the HOST_CONTROL2
register is retaining the 1.8V Signalling enable bit till SDHCI reset
happens after a new card is inserted.
Adding the change you suggested can avoid this wait, but I feel a better
solution is to clear the 1.8V signalling bit when the card is removed.
When a new card is inserted, we shouldn't be keeping the 1.8V bit set
until we send cmd11 to the SD card. A new SD card should start with 3V.
One solution is to explicitly clear the HOST_CONTROL2 register when card
is removed.
Other way is to revert the commit:
9718f84b85396e090ca42fafa730410d286d61e3 "mmc: sdhci-msm: Do not reset
the controller if no card in the slot"
The sdhci-msm doesn't require "SDHCI_QUIRK_NO_CARD_NO_RESET". The issue
which above commit is trying to avoid is fixed by the pwr-irq patches.
Resetting the controller will clear the HOST_CONTROL2 register and avoid
this issue.
Can you please try this ? I tested reverting the QUIRK on two platforms:
db410c(8916) and sdm845. SD card insert/remove worked fine after that
and I didn't get any "Reset 0x1 never completed" error during card
insert/remove or shutdown.
Thanks,
Vijay
On 5/29/2018 5:49 PM, Georgi Djakov wrote:
> Hello Vijay,
>
> On 09/27/2017 08:34 AM, Vijay Viswanath wrote:
>> Register writes which change voltage of IO lines or turn the IO bus
>> on/off require controller to be ready before progressing further. When
>> the controller is ready, it will generate a power irq which needs to be
>> handled. The thread which initiated the register write should wait for
>> power irq to complete. This will be done through the new sdhc msm write
>> APIs which will check whether the particular write can trigger a power
>> irq and wait for it with a timeout if it is expected.
>> The SDHC core power control IRQ gets triggered when -
>> * There is a state change in power control bit (bit 0)
>> of SDHCI_POWER_CONTROL register.
>> * There is a state change in 1.8V enable bit (bit 3) of
>> SDHCI_HOST_CONTROL2 register.
>> * Bit 1 of SDHCI_SOFTWARE_RESET is set.
>>
>> Also add support APIs which are used by sdhc msm write APIs to check
>> if power irq is expected to be generated and wait for the power irq
>> to come and complete if the irq is expected.
>>
>> This patch requires CONFIG_MMC_SDHCI_IO_ACCESSORS to be enabled.
>>
>> Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
>> Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
>> ---
>> drivers/mmc/host/sdhci-msm.c | 173 ++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 171 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
>
> [..]
>
>> +/*
>> + * sdhci_msm_check_power_status API should be called when registers writes
>> + * which can toggle sdhci IO bus ON/OFF or change IO lines HIGH/LOW happens.
>> + * To what state the register writes will change the IO lines should be passed
>> + * as the argument req_type. This API will check whether the IO line's state
>> + * is already the expected state and will wait for power irq only if
>> + * power irq is expected to be trigerred based on the current IO line state
>> + * and expected IO line state.
>> + */
>> +static void sdhci_msm_check_power_status(struct sdhci_host *host, u32 req_type)
>> +{
>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
>> + bool done = false;
>> +
>> + pr_debug("%s: %s: request %d curr_pwr_state %x curr_io_level %x\n",
>> + mmc_hostname(host->mmc), __func__, req_type,
>> + msm_host->curr_pwr_state, msm_host->curr_io_level);
>> +
>> + /*
>> + * The IRQ for request type IO High/LOW will be generated when -
>> + * there is a state change in 1.8V enable bit (bit 3) of
>> + * SDHCI_HOST_CONTROL2 register. The reset state of that bit is 0
>> + * which indicates 3.3V IO voltage. So, when MMC core layer tries
>> + * to set it to 3.3V before card detection happens, the
>> + * IRQ doesn't get triggered as there is no state change in this bit.
>> + * The driver already handles this case by changing the IO voltage
>> + * level to high as part of controller power up sequence. Hence, check
>> + * for host->pwr to handle a case where IO voltage high request is
>> + * issued even before controller power up.
>> + */
>> + if ((req_type & REQ_IO_HIGH) && !host->pwr) {
>> + pr_debug("%s: do not wait for power IRQ that never comes, req_type: %d\n",
>> + mmc_hostname(host->mmc), req_type);
>> + return;
>> + }
>> + if ((req_type & msm_host->curr_pwr_state) ||
>> + (req_type & msm_host->curr_io_level))
>> + done = true;
>> + /*
>> + * This is needed here to handle cases where register writes will
>> + * not change the current bus state or io level of the controller.
>> + * In this case, no power irq will be triggerred and we should
>> + * not wait.
>> + */
>> + if (!done) {
>> + if (!wait_event_timeout(msm_host->pwr_irq_wait,
>> + msm_host->pwr_irq_flag,
>> + msecs_to_jiffies(MSM_PWR_IRQ_TIMEOUT_MS)))
>> + __WARN_printf("%s: pwr_irq for req: (%d) timed out\n",
>> + mmc_hostname(host->mmc), req_type);
>
> I am seeing the above error message on a db820c device (apq8096). When i
> unplug the SD card and then plug it back in, there is a 5 sec card
> detection delay and a timeout. Here is a log:
>
> [ 50.253997] mmc0: card 59b4 removed
> [ 50.381874] mmc0: sdhci_msm_check_power_status: request 1
> curr_pwr_state 2 curr_io_level 4 sdhci_host_ctrl2 b
> [ 50.382656] mmc0: sdhci_msm_check_power_status: request 1 done
> [ 50.392493] mmc0: sdhci_msm_check_power_status: request 4
> curr_pwr_state 1 curr_io_level 4 sdhci_host_ctrl2 b
> [ 50.398258] mmc0: sdhci_msm_check_power_status: request 4 done
> [ 50.408728] mmc0: sdhci_msm_check_power_status: request 4
> curr_pwr_state 1 curr_io_level 4 sdhci_host_ctrl2 8
> [ 50.413865] mmc0: sdhci_msm_check_power_status: request 4 done
> [ 54.966316] mmc0: sdhci_msm_check_power_status: request 2
> curr_pwr_state 1 curr_io_level 4 sdhci_host_ctrl2 8 <-- card is plugged
> [ 54.967756] mmc0: sdhci_msm_check_power_status: request 2 done
> [ 54.976822] mmc0: sdhci_msm_check_power_status: request 4
> curr_pwr_state 2 curr_io_level 8 sdhci_host_ctrl2 8
> [ 60.132253] sdhci_msm 74a4900.sdhci: mmc0: pwr_irq for req: (4) timed out
> [ 60.132782] mmc0: sdhci_msm_check_power_status: request 4 done
> [ 60.139888] mmc0: sdhci_msm_check_power_status: request 4
> curr_pwr_state 2 curr_io_level 8 sdhci_host_ctrl2 8
> [ 65.252497] sdhci_msm 74a4900.sdhci: mmc0: pwr_irq for req: (4) timed out
>
> The following patch seem to "fix" it.
>
> -- >8 --
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index b2d875afae5f..ca8ad4edcf80 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -1049,6 +1049,11 @@ static void sdhci_msm_check_power_status(struct
> sdhci_host *host, u32 req_type)
> return;
> }
>
> + if (req_type & REQ_IO_LOW &&
> + msm_host->curr_pwr_state & REQ_BUS_ON &&
> + msm_host->curr_io_level & REQ_IO_HIGH &&
> + !host->pwr)
> + done = true;
> /*
> * The IRQ for request type IO High/LOW will be generated when -
> * there is a state change in 1.8V enable bit (bit 3) of
> -- >8 --
>
> Reverting this patch series or applying the above patch makes the issue
> go away. According to the log, there is no change in the
> sdhci_host_ctrl2 register. What do you think?
>
> Thanks,
> Georgi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/3] ARM: imx: add L2 page power control for GPC
From: Anson Huang @ 2018-05-30 7:12 UTC (permalink / raw)
To: linux-arm-kernel
Some platforms like i.MX6UL/i.MX6SLL have L2
page power control in GPC, it needs to be
disabled if ARM is power gated and L2 is NOT
flushed, add GPC interface to control it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/mach-imx/common.h | 1 +
arch/arm/mach-imx/gpc.c | 14 ++++++++++++++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index c8d68e9..a2716ec 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -58,6 +58,7 @@ struct device *imx_soc_device_init(void);
void imx6_enable_rbc(bool enable);
void imx_gpc_check_dt(void);
void imx_gpc_set_arm_power_in_lpm(bool power_off);
+void imx_gpc_set_l2_mem_power_in_lpm(bool power_off);
void imx_gpc_set_arm_power_up_timing(u32 sw2iso, u32 sw);
void imx_gpc_set_arm_power_down_timing(u32 sw2iso, u32 sw);
void imx25_pm_init(void);
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index de535cb..e11159d 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -20,6 +20,7 @@
#include "common.h"
#include "hardware.h"
+#define GPC_CNTR 0x0
#define GPC_IMR1 0x008
#define GPC_PGC_CPU_PDN 0x2a0
#define GPC_PGC_CPU_PUPSCR 0x2a4
@@ -27,6 +28,8 @@
#define GPC_PGC_SW2ISO_SHIFT 0x8
#define GPC_PGC_SW_SHIFT 0x0
+#define GPC_CNTR_L2_PGE_SHIFT 22
+
#define IMR_NUM 4
#define GPC_MAX_IRQS (IMR_NUM * 32)
@@ -51,6 +54,17 @@ void imx_gpc_set_arm_power_in_lpm(bool power_off)
writel_relaxed(power_off, gpc_base + GPC_PGC_CPU_PDN);
}
+void imx_gpc_set_l2_mem_power_in_lpm(bool power_off)
+{
+ u32 val;
+
+ val = readl_relaxed(gpc_base + GPC_CNTR);
+ val &= ~(1 << GPC_CNTR_L2_PGE_SHIFT);
+ if (power_off)
+ val |= 1 << GPC_CNTR_L2_PGE_SHIFT;
+ writel_relaxed(val, gpc_base + GPC_CNTR);
+}
+
void imx_gpc_pre_suspend(bool arm_power_off)
{
void __iomem *reg_imr1 = gpc_base + GPC_IMR1;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: imx: add cpu idle support for i.MX6SLL
From: Anson Huang @ 2018-05-30 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527664358-17844-1-git-send-email-Anson.Huang@nxp.com>
i.MX6SLL supports cpu idle with ARM power gated,
it can reuse i.MX6SX's cpu idle driver to support
below 3 states of cpu idle:
state0: WFI;
state1: WAIT mode with ARM power on;
state2: WAIT mode with ARM power off.
L2_PGE in GPC_CNTR needs to be cleared to support
state2 cpu idle.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/mach-imx/cpuidle-imx6sx.c | 1 +
arch/arm/mach-imx/mach-imx6sl.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/cpuidle-imx6sx.c b/arch/arm/mach-imx/cpuidle-imx6sx.c
index d0f14b7..243a108 100644
--- a/arch/arm/mach-imx/cpuidle-imx6sx.c
+++ b/arch/arm/mach-imx/cpuidle-imx6sx.c
@@ -103,6 +103,7 @@ int __init imx6sx_cpuidle_init(void)
{
imx6_set_int_mem_clk_lpm(true);
imx6_enable_rbc(false);
+ imx_gpc_set_l2_mem_power_in_lpm(false);
/*
* set ARM power up/down timing to the fastest,
* sw2iso and sw can be set to one 32K cycle = 31us
diff --git a/arch/arm/mach-imx/mach-imx6sl.c b/arch/arm/mach-imx/mach-imx6sl.c
index c7a1ef1..183540e 100644
--- a/arch/arm/mach-imx/mach-imx6sl.c
+++ b/arch/arm/mach-imx/mach-imx6sl.c
@@ -42,7 +42,10 @@ static void __init imx6sl_init_late(void)
if (IS_ENABLED(CONFIG_ARM_IMX6Q_CPUFREQ))
platform_device_register_simple("imx6q-cpufreq", -1, NULL, 0);
- imx6sl_cpuidle_init();
+ if (cpu_is_imx6sl())
+ imx6sl_cpuidle_init();
+ else
+ imx6sx_cpuidle_init();
}
static void __init imx6sl_init_machine(void)
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: imx: remove i.MX6SLL support in i.MX6SL cpu idle driver
From: Anson Huang @ 2018-05-30 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527664358-17844-1-git-send-email-Anson.Huang@nxp.com>
i.MX6SLL supports ARM power off in cpu idle, better to reuse
i.MX6SX cpu idle driver instead of i.MX6SL which does NOT
support ARM power off.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/mach-imx/cpuidle-imx6sl.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-imx/cpuidle-imx6sl.c b/arch/arm/mach-imx/cpuidle-imx6sl.c
index fa8ead1..8d866fb 100644
--- a/arch/arm/mach-imx/cpuidle-imx6sl.c
+++ b/arch/arm/mach-imx/cpuidle-imx6sl.c
@@ -12,7 +12,6 @@
#include "common.h"
#include "cpuidle.h"
-#include "hardware.h"
static int imx6sl_enter_wait(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
@@ -22,11 +21,9 @@ static int imx6sl_enter_wait(struct cpuidle_device *dev,
* Software workaround for ERR005311, see function
* description for details.
*/
- if (cpu_is_imx6sl())
- imx6sl_set_wait_clk(true);
+ imx6sl_set_wait_clk(true);
cpu_do_idle();
- if (cpu_is_imx6sl())
- imx6sl_set_wait_clk(false);
+ imx6sl_set_wait_clk(false);
imx6_set_lpm(WAIT_CLOCKED);
return index;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox