Re: [PATCHv1 1/8] arm64: dts: Fix various entry-method properties to reflect documentation
On Tue, May 14, 2019 at 12:09 AM Bjorn Andersson
wrote:
>
> On Fri 10 May 04:29 PDT 2019, Amit Kucheria wrote:
>
> Subject indicates pluralism, but this fixes a specific platform
> (board?). I think you should update that.
Copy paste from the previous cleanup commit :-) Will fix.
> > The idle-states binding documentation[1] mentions that the
> > 'entry-method' property is required on 64-bit platforms and must be set
> > to "psci".
> >
> > We fixed up all uses of the entry-method property in
> > commit e9880240e4f4 ("arm64: dts: Fix various entry-method properties to
> > reflect documentation"). But a new one has appeared. Fix it up.
> >
> > Cc: Sudeep Holla
>
> The message looks good though, so with a new subject you have my:
>
> Reviewed-by: Bjorn Andersson
Thanks
>
> > Signed-off-by: Amit Kucheria
> > ---
> > arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > index 2896bbcfa3bb..42e7822a0227 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > @@ -51,7 +51,7 @@
> >* PSCI node is not added default, U-boot will add missing
> >* parts if it determines to use PSCI.
> >*/
> > - entry-method = "arm,psci";
> > + entry-method = "psci";
> >
> > CPU_PH20: cpu-ph20 {
> > compatible = "arm,idle-state";
> > --
> > 2.17.1
> >
[PATCH v2] KVM: X86: Emulate MSR_IA32_MISC_ENABLE MWAIT bit
From: Wanpeng Li
MSR IA32_MSIC_ENABLE bit 18, according to SDM:
| When this bit is set to 0, the MONITOR feature flag is not set
(CPUID.01H:ECX[bit 3] = 0).
| This indicates that MONITOR/MWAIT are not supported.
|
| Software attempts to execute MONITOR/MWAIT will cause #UD when this bit is 0.
|
| When this bit is set to 1 (default), MONITOR/MWAIT are supported
(CPUID.01H:ECX[bit 3] = 1).
The CPUID.01H:ECX[bit 3] ought to mirror the value of the MSR bit,
CPUID.01H:ECX[bit 3] is a better guard than kvm_mwait_in_guest().
kvm_mwait_in_guest() affects the behavior of MONITOR/MWAIT, not its
guest visibility.
This patch implements toggling of the CPUID bit based on guest writes
to the MSR.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Sean Christopherson
Cc: Liran Alon
Cc: Konrad Rzeszutek Wilk
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* to configure MSR_IA32_MISC_ENABLE_MWAIT bit in userspace
* implements toggling of the CPUID bit based on guest writes to the MSR
arch/x86/kvm/cpuid.c | 8
arch/x86/kvm/x86.c | 9 +
2 files changed, 17 insertions(+)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index fd39516..0f82393 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -137,6 +137,14 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu)
(best->eax & (1 << KVM_FEATURE_PV_UNHALT)))
best->eax &= ~(1 << KVM_FEATURE_PV_UNHALT);
+ best = kvm_find_cpuid_entry(vcpu, 0x1, 0);
+ if (best) {
+ if (vcpu->arch.ia32_misc_enable_msr &
MSR_IA32_MISC_ENABLE_MWAIT)
+ best->ecx |= F(MWAIT);
+ else
+ best->ecx &= ~F(MWAIT);
+ }
+
/* Update physical-address width */
vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
kvm_mmu_reset_context(vcpu);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3bbf3ab..4ed45ab 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2506,6 +2506,15 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
}
break;
case MSR_IA32_MISC_ENABLE:
+ if ((vcpu->arch.ia32_misc_enable_msr ^ data) &
MSR_IA32_MISC_ENABLE_MWAIT) {
+ if ((vcpu->arch.ia32_misc_enable_msr &
MSR_IA32_MISC_ENABLE_MWAIT) &&
+ !(data & MSR_IA32_MISC_ENABLE_MWAIT)) {
+ if (!guest_cpuid_has(vcpu, X86_FEATURE_XMM3))
+ return 1;
+ }
+ vcpu->arch.ia32_misc_enable_msr = data;
+ kvm_update_cpuid(vcpu);
+ }
vcpu->arch.ia32_misc_enable_msr = data;
break;
case MSR_IA32_SMBASE:
--
2.7.4
[PATCH] Fixed https://bugzilla.kernel.org/show_bug.cgi?id=202935 allow write on the same file
Signed-off-by: Kovtunenko Oleksandr
---
fs/cifs/cifsfs.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index a05bf1d..2964438 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -1073,11 +1073,6 @@ ssize_t cifs_file_copychunk_range(unsigned int xid,
cifs_dbg(FYI, "copychunk range\n");
- if (src_inode == target_inode) {
- rc = -EINVAL;
- goto out;
- }
-
if (!src_file->private_data || !dst_file->private_data) {
rc = -EBADF;
cifs_dbg(VFS, "missing cifsFileInfo on copy range src file\n");
--
1.8.3.1
Re: [PATCH] PCI: altera-msi: Allow building as module
On Wed, Apr 24, 2019 at 12:57 PM Ley Foon Tan wrote:
>
> Altera MSI IP is a soft IP and is only available after
> FPGA image is programmed.
>
> Make driver modulable to support use case FPGA image is programmed
> after kernel is booted. User proram FPGA image in kernel then only load
> MSI driver module.
>
> Signed-off-by: Ley Foon Tan
> ---
> drivers/pci/controller/Kconfig | 2 +-
> drivers/pci/controller/pcie-altera-msi.c | 10 ++
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index 4b550f9cdd56..920546cb84e2 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -181,7 +181,7 @@ config PCIE_ALTERA
> FPGA.
>
> config PCIE_ALTERA_MSI
> - bool "Altera PCIe MSI feature"
> + tristate "Altera PCIe MSI feature"
> depends on PCIE_ALTERA
> depends on PCI_MSI_IRQ_DOMAIN
> help
> diff --git a/drivers/pci/controller/pcie-altera-msi.c
> b/drivers/pci/controller/pcie-altera-msi.c
> index 025ef7d9a046..16d938920ca5 100644
> --- a/drivers/pci/controller/pcie-altera-msi.c
> +++ b/drivers/pci/controller/pcie-altera-msi.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -288,4 +289,13 @@ static int __init altera_msi_init(void)
> {
> return platform_driver_register(_msi_driver);
> }
> +
> +static void __exit altera_msi_exit(void)
> +{
> + platform_driver_unregister(_msi_driver);
> +}
> +
> subsys_initcall(altera_msi_init);
> +MODULE_DEVICE_TABLE(of, altera_msi_of_match);
> +module_exit(altera_msi_exit);
> +MODULE_LICENSE("GPL v2");
> --
> 2.19.0
>
Hi
Any comment for this patch?
Regards
Ley Foon
Re: [PATCH] PCI: altera: Allow building as module
On Wed, Apr 24, 2019 at 12:57 PM Ley Foon Tan wrote:
>
> Altera PCIe Rootport IP is a soft IP and is only available after
> FPGA image is programmed.
>
> Make driver modulable to support use case FPGA image is programmed
> after kernel is booted. User proram FPGA image in kernel then only load
> PCIe driver module.
>
> Signed-off-by: Ley Foon Tan
> ---
> drivers/pci/controller/Kconfig | 2 +-
> drivers/pci/controller/pcie-altera.c | 28 ++--
> 2 files changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index 6012f3059acd..4b550f9cdd56 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -174,7 +174,7 @@ config PCIE_IPROC_MSI
> PCIe controller
>
> config PCIE_ALTERA
> - bool "Altera PCIe controller"
> + tristate "Altera PCIe controller"
> depends on ARM || NIOS2 || ARM64 || COMPILE_TEST
> help
> Say Y here if you want to enable PCIe controller support on Altera
> diff --git a/drivers/pci/controller/pcie-altera.c
> b/drivers/pci/controller/pcie-altera.c
> index 27edcebd1726..6c86bc69ace8 100644
> --- a/drivers/pci/controller/pcie-altera.c
> +++ b/drivers/pci/controller/pcie-altera.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -705,6 +706,13 @@ static int altera_pcie_init_irq_domain(struct
> altera_pcie *pcie)
> return 0;
> }
>
> +static int altera_pcie_irq_teardown(struct altera_pcie *pcie)
> +{
> + irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
> + irq_domain_remove(pcie->irq_domain);
> + irq_dispose_mapping(pcie->irq);
> +}
> +
> static int altera_pcie_parse_dt(struct altera_pcie *pcie)
> {
> struct device *dev = >pdev->dev;
> @@ -798,6 +806,7 @@ static int altera_pcie_probe(struct platform_device *pdev)
>
> pcie = pci_host_bridge_priv(bridge);
> pcie->pdev = pdev;
> + platform_set_drvdata(pdev, pcie);
>
> match = of_match_device(altera_pcie_of_match, >dev);
> if (!match)
> @@ -855,13 +864,28 @@ static int altera_pcie_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> +static int altera_pcie_remove(struct platform_device *pdev)
> +{
> + struct altera_pcie *pcie = platform_get_drvdata(pdev);
> + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
> +
> + pci_stop_root_bus(bridge->bus);
> + pci_remove_root_bus(bridge->bus);
> + pci_free_resource_list(>resources);
> + altera_pcie_irq_teardown(pcie);
> +
> + return 0;
> +}
> +
> static struct platform_driver altera_pcie_driver = {
> .probe = altera_pcie_probe,
> + .remove = altera_pcie_remove,
> .driver = {
> .name = "altera-pcie",
> .of_match_table = altera_pcie_of_match,
> - .suppress_bind_attrs = true,
> },
> };
>
> -builtin_platform_driver(altera_pcie_driver);
> +MODULE_DEVICE_TABLE(of, altera_pcie_of_match);
> +module_platform_driver(altera_pcie_driver);
> +MODULE_LICENSE("GPL v2");
> --
> 2.19.0
>
Hi
Any comment for this patch?
Regards
Ley Foon
Re: [PATCH V5 07/16] dt-bindings: PCI: designware: Add binding for CDM register check
On 5/13/2019 8:45 PM, Rob Herring wrote: On Tue, May 7, 2019 at 3:25 AM Vidya Sagar wrote: On 4/26/2019 8:02 PM, Rob Herring wrote: On Wed, Apr 24, 2019 at 10:49:55AM +0530, Vidya Sagar wrote: Add support to enable CDM (Configuration Dependent Module) registers check for any data corruption. CDM registers include standard PCIe configuration space registers, Port Logic registers and iATU and DMA registers. Refer Section S.4 of Synopsys DesignWare Cores PCI Express Controller Databook Version 4.90a Signed-off-by: Vidya Sagar --- Changes since [v4]: * None Changes since [v3]: * None Changes since [v2]: * Changed flag name from 'cdm-check' to 'enable-cdm-check' * Added info about Port Logic and DMA registers being part of CDM Changes since [v1]: * This is a new patch in v2 series Documentation/devicetree/bindings/pci/designware-pcie.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index 5561a1c060d0..85b872c42a9f 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -34,6 +34,11 @@ Optional properties: - clock-names: Must include the following entries: - "pcie" - "pcie_bus" +- enable-cdm-check: This is a boolean property and if present enables This needs a vendor prefix. Why only for this? Since this whole file is for Synopsys DesignWare core based PCIe IP, I thought there is specific prefix required. Am I wrong? Also, CDM checking is a feature of IP and DWC based implementations can choose either to enable this feature at hardware level or not. And whoever enabled it at hardware level (like Tegra194) can set this flag to enable corresponding software support. TBC, I meant a Synopsys vendor prefix, not NVIDIA. Any property that's not from a common binding should have a vendor prefix. That hasn't always happened, so we do have lots of examples without. Ok. got it. I'm going to take care of this in V7 series. Rob
Re: [PATCH V6 06/15] dt-bindings: PCI: designware: Add binding for CDM register check
On 5/13/2019 8:40 PM, Rob Herring wrote: On Mon, May 13, 2019 at 10:36:17AM +0530, Vidya Sagar wrote: Add support to enable CDM (Configuration Dependent Module) registers check for any data corruption. CDM registers include standard PCIe configuration space registers, Port Logic registers and iATU and DMA registers. Refer Section S.4 of Synopsys DesignWare Cores PCI Express Controller Databook Version 4.90a Signed-off-by: Vidya Sagar --- Changes since [v5]: * None Changes since [v4]: * None Changes since [v3]: * None Changes since [v2]: * Changed flag name from 'cdm-check' to 'enable-cdm-check' * Added info about Port Logic and DMA registers being part of CDM Changes since [v1]: * This is a new patch in v2 series Documentation/devicetree/bindings/pci/designware-pcie.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index 5561a1c060d0..85b872c42a9f 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -34,6 +34,11 @@ Optional properties: - clock-names: Must include the following entries: - "pcie" - "pcie_bus" +- enable-cdm-check: This is a boolean property and if present enables + automatic checking of CDM (Configuration Dependent Module) registers + for data corruption. CDM registers include standard PCIe configuration + space registers, Port Logic registers, DMA and iATU (internal Address + Translation Unit) registers. snps,enable-cdm-check Ok. Done. RC mode: - num-viewport: number of view ports configured in hardware. If a platform does not specify it, the driver assumes 2. -- 2.17.1
Re: [Qemu-devel] [PATCH v8 3/6] libnvdimm: add dax_dev sync flag
> > > > > > Hi Dan, > > > > While testing device mapper with DAX, I faced a bug with the commit: > > > > commit ad428cdb525a97d15c0349fdc80f3d58befb50df > > Author: Dan Williams > > Date: Wed Feb 20 21:12:50 2019 -0800 > > > > When I reverted the condition to old code[1] it worked for me. I > > am thinking when we map two different devices (e.g with device mapper), > > will > > start & end pfn still point to same pgmap? Or there is something else which > > I am missing here. > > > > Note: I tested only EXT4. > > > > [1] > > > > - if (pgmap && pgmap->type == MEMORY_DEVICE_FS_DAX) > > + end_pgmap = get_dev_pagemap(pfn_t_to_pfn(end_pfn), NULL); > > + if (pgmap && pgmap == end_pgmap && pgmap->type == > > MEMORY_DEVICE_FS_DAX > > + && pfn_t_to_page(pfn)->pgmap == pgmap > > + && pfn_t_to_page(end_pfn)->pgmap == pgmap > > + && pfn_t_to_pfn(pfn) == > > PHYS_PFN(__pa(kaddr)) > > + && pfn_t_to_pfn(end_pfn) == > > PHYS_PFN(__pa(end_kaddr))) > > Ugh, yes, device-mapper continues to be an awkward fit for dax (or > vice versa). We would either need a way to have a multi-level pfn to > pagemap lookup for composite devices, or a way to discern that even > though the pagemap is different that the result is still valid / not > an indication that we have leaked into an unassociated address range. > Perhaps a per-daxdev callback for ->dax_supported() so that > device-mapper internals can be used for this validation. Yes, Will look at it. > > We need to get that fixed up, but I don't see it as a blocker / > pre-requisite for virtio-pmem. Agree. Will send virtio-pmem patch series. Thank you, Pankaj > >
Re: INFO: task hung in __get_super
Hello, Jan.
syzbot is still reporting livelocks inside __getblk_gfp() [1] (similar to
commit 04906b2f542c2362 ("blockdev: Fix livelocks on loop device")).
[1]
https://syzkaller.appspot.com/bug?id=835a0b9e75b14b55112661cbc61ca8b8f0edf767
A debug printk() patch shown below revealed that since bdev->bd_inode->i_blkbits
is unexpectedly modified, __find_get_block_slow() is failing to find buffer
pages
created by grow_dev_page(). I guess that opening a loop device (while somebody
is
doing mount operation on that loop device) can trigger set_init_blocksize() from
__blkdev_get().
diff --git a/fs/buffer.c b/fs/buffer.c
index 0faa41fb4c88..8e197c771476 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -190,7 +190,7 @@ EXPORT_SYMBOL(end_buffer_write_sync);
* succeeds, there is no need to take private_lock.
*/
static struct buffer_head *
-__find_get_block_slow(struct block_device *bdev, sector_t block)
+__find_get_block_slow(struct block_device *bdev, sector_t block, unsigned size)
{
struct inode *bd_inode = bdev->bd_inode;
struct address_space *bd_mapping = bd_inode->i_mapping;
@@ -204,12 +204,20 @@ __find_get_block_slow(struct block_device *bdev, sector_t
block)
index = block >> (PAGE_SHIFT - bd_inode->i_blkbits);
page = find_get_page_flags(bd_mapping, index, FGP_ACCESSED);
- if (!page)
+ if (!page) {
+ if (fatal_signal_pending(current) && __ratelimit(_warned))
+ printk("%s:%u block=%llu bd_inode->i_blkbits=%u
index=%lu size=%u\n",
+ __FILE__, __LINE__, block, bd_inode->i_blkbits,
index, size);
goto out;
+ }
spin_lock(_mapping->private_lock);
- if (!page_has_buffers(page))
+ if (!page_has_buffers(page)) {
+ if (fatal_signal_pending(current) && __ratelimit(_warned))
+ printk("%s:%u block=%llu bd_inode->i_blkbits=%u
index=%lu size=%u page=%p\n",
+ __FILE__, __LINE__, block, bd_inode->i_blkbits,
index, size, page);
goto out_unlock;
+ }
head = page_buffers(page);
bh = head;
do {
@@ -934,6 +942,8 @@ grow_dev_page(struct block_device *bdev, sector_t block,
sector_t end_block;
int ret = 0;/* Will call free_more_memory() */
gfp_t gfp_mask;
+ static DEFINE_RATELIMIT_STATE(last_warned1, HZ, 1);
+ static DEFINE_RATELIMIT_STATE(last_warned2, HZ, 1);
gfp_mask = mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS) | gfp;
@@ -946,11 +956,15 @@ grow_dev_page(struct block_device *bdev, sector_t block,
gfp_mask |= __GFP_NOFAIL;
page = find_or_create_page(inode->i_mapping, index, gfp_mask);
+ if (fatal_signal_pending(current) && __ratelimit(_warned1))
+ printk("%s:%u block=%llu inode->i_blkbits=%u index=%lu
size=%u\n", __FILE__, __LINE__, block, inode->i_blkbits, index, size);
BUG_ON(!PageLocked(page));
if (page_has_buffers(page)) {
bh = page_buffers(page);
+ if (fatal_signal_pending(current) && __ratelimit(_warned2))
+ printk("%s:%u block=%llu index=%lu size=%u
bh->b_size=%lu\n", __FILE__, __LINE__, block, index, size, bh->b_size);
if (bh->b_size == size) {
end_block = init_page_buffers(page, bdev,
(sector_t)index << sizebits,
@@ -1292,7 +1306,7 @@ __find_get_block(struct block_device *bdev, sector_t
block, unsigned size)
if (bh == NULL) {
/* __find_get_block_slow will mark the page accessed */
- bh = __find_get_block_slow(bdev, block);
+ bh = __find_get_block_slow(bdev, block, size);
if (bh)
bh_lru_install(bh);
} else
[ 89.805981][ T7388] __find_get_block_slow: 1278192 callbacks suppressed
[ 89.805987][ T7388] fs/buffer.c:218 block=1 bd_inode->i_blkbits=12 index=1
size=512 page=cd89a24d
[ 90.716164][ T7388] grow_dev_page: 1295496 callbacks suppressed
[ 90.716167][ T7388] fs/buffer.c:960 block=1 inode->i_blkbits=12 index=0
size=512
[ 90.735989][ T7388] grow_dev_page: 1296140 callbacks suppressed
[ 90.735991][ T7388] fs/buffer.c:967 block=1 index=0 size=512 bh->b_size=512
[ 90.815859][ T7388] __find_get_block_slow: 1312165 callbacks suppressed
[ 90.815862][ T7388] fs/buffer.c:218 block=1 bd_inode->i_blkbits=12 index=1
size=512 page=cd89a24d
[ 91.726006][ T7388] grow_dev_page: 1306138 callbacks suppressed
[ 91.726022][ T7388] fs/buffer.c:960 block=1 inode->i_blkbits=12 index=0
size=512
[ 91.745856][ T7388] grow_dev_page: 1305423 callbacks suppressed
[ 91.745859][ T7388] fs/buffer.c:967 block=1 index=0 size=512 bh->b_size=512
[
Re: [PATCH 2/3 v5] add a new template field buf to contain the buffer
On Mon, May 13, 2019 at 6:48 AM Roberto Sassu wrote: > > On 5/11/2019 12:37 AM, Prakhar Srivastava wrote: > > From: Prakhar Srivastava > > > > The buffer(cmdline args) added to the ima log cannot be attested > > without having the actual buffer. Thus to make the measured buffer > > available to store/read a new ima template (buf) is added. > > Hi Prakhar > > please fix the typos. More comments below. > > > > + buffer_event_data->type = IMA_XATTR_BUFFER; > > + buffer_event_data->buf_length = size; > > + memcpy(buffer_event_data->buf, buf, size); > > + > > + event_data.xattr_value = (struct evm_ima_xattr_data > > *)buffer_event_data; > > + event_data.xattr_len = alloc_length; > > I would prefer that you introduce two new fields in the ima_event_data > structure. You can initialize them directly with the parameters of > process_buffer_measurement(). I will make the edits, this will definitely save the kzalloc in this code path. > > ima_write_template_field_data() will make > a copy. > Since event_data->type is used to distinguish what the template field should contain. Removing the type and subsequent check in the template_init, buf template fmt will result in the whole event_Data structure being added to the log, which is not the expected output. For buffer entries, the buf templet fmt will contains the buffer itself. > > > + .field_show = ima_show_template_buf}, > > Please update Documentation/security/IMA-templates.rst Will update the documentation. Thanks, Prakhar Srivastava > > Thanks > > Roberto
[PATCH V5 1/4] spi: tegra114: add support for gpio based CS
This patch adds support for GPIO based CS control through SPI core function spi_set_cs. Signed-off-by: Sowjanya Komatineni --- drivers/spi/spi-tegra114.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c index b1f31bb16659..f47417dd9edb 100644 --- a/drivers/spi/spi-tegra114.c +++ b/drivers/spi/spi-tegra114.c @@ -776,6 +776,10 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device *spi, } else tegra_spi_writel(tspi, command1, SPI_COMMAND1); + /* GPIO based chip select control */ + if (spi->cs_gpiod) + gpiod_set_value(spi->cs_gpiod, 1); + command1 |= SPI_CS_SW_HW; if (spi->mode & SPI_CS_HIGH) command1 |= SPI_CS_SW_VAL; @@ -864,6 +868,10 @@ static int tegra_spi_setup(struct spi_device *spi) } spin_lock_irqsave(>lock, flags); + /* GPIO based chip select control */ + if (spi->cs_gpiod) + gpiod_set_value(spi->cs_gpiod, 0); + val = tspi->def_command1_reg; if (spi->mode & SPI_CS_HIGH) val &= ~SPI_CS_POL_INACTIVE(spi->chip_select); @@ -893,6 +901,10 @@ static void tegra_spi_transfer_end(struct spi_device *spi) struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master); int cs_val = (spi->mode & SPI_CS_HIGH) ? 0 : 1; + /* GPIO based chip select control */ + if (spi->cs_gpiod) + gpiod_set_value(spi->cs_gpiod, 0); + if (cs_val) tspi->command1_reg |= SPI_CS_SW_VAL; else @@ -1199,6 +1211,7 @@ static int tegra_spi_probe(struct platform_device *pdev) master->max_speed_hz = 2500; /* 25MHz */ /* the spi->mode bits understood by this driver: */ + master->use_gpio_descriptors = true; master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST | SPI_TX_DUAL | SPI_RX_DUAL | SPI_3WIRE; master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32); -- 2.7.4
[PATCH V5 0/4] additional features to Tegra SPI
[V5] : This patch series version includes - Updated GPIO based chip select control using GPIO descriptor. - HW based chip select implementation is same as V3 but V5 has this patch updated to be on top of above changes. - HW CS timing implementation is same as V3 but V5 has this patch updated to be on top of above changes. - support for TX and RX trimmers implementation is same as V3 but V5 has this patch updated to be on top of above changes and updated commit description. [V4] : This version went out accidentally. Please discard. [V3] : This patch series version includes - only patches that are not applied from V2. - splitted expanding mode and adding LSByte First support in separate patches and removed DT property for selecting LSByte First. - Updated GPIO based chip select control to use spi_set_cs from SPI core. - HW based chip select implementation is same as V2 but V3 has this patch updated to be on top of above changes. - HW CS timing implementation is same as V2 but V3 has this patch updated to be on top of above changes. - support for TX and RX trimmers implementation is same as V2 but V3 has this patch updated to be on top of above changes and updated commit description. [V2] : This patch series version includes - only patches that are not applied from V1. - changed order of patches to include all fixes prior to new features support. - Removed HW CS timing from DT properties and created set_cs_timing SPI master optional method for SPI controllers to implement and created API spi_cs_timing for SPI client drivers to request CS setup, hold and inactive delay timing configuration. - Fixed HW based CS decision to be based on single transfer and cs_change. Remove selection of HW based CS through DT. Sowjanya Komatineni (4): spi: tegra114: add support for gpio based CS spi: tegra114: add support for hw based cs spi: tegra114: add support for HW CS timing spi: tegra114: add support for TX and RX trimmers drivers/spi/spi-tegra114.c | 167 - 1 file changed, 151 insertions(+), 16 deletions(-) -- 2.7.4
[PATCH V5 3/4] spi: tegra114: add support for HW CS timing
This patch implements set_cs_timing SPI controller method to allow
SPI client driver to configure device specific SPI CS timings.
Signed-off-by: Sowjanya Komatineni
---
drivers/spi/spi-tegra114.c | 48 --
1 file changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 0cb0932d32fd..e59ff7c1cee6 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -95,8 +95,10 @@
(reg = (((val) & 0x1) << ((cs) * 8 + 5)) | \
((reg) & ~(1 << ((cs) * 8 + 5
#define SPI_SET_CYCLES_BETWEEN_PACKETS(reg, cs, val) \
- (reg = (((val) & 0xF) << ((cs) * 8)) | \
- ((reg) & ~(0xF << ((cs) * 8
+ (reg = (((val) & 0x1F) << ((cs) * 8)) | \
+ ((reg) & ~(0x1F << ((cs) * 8
+#define MAX_SETUP_HOLD_CYCLES 16
+#define MAX_INACTIVE_CYCLES32
#define SPI_TRANS_STATUS 0x010
#define SPI_BLK_CNT(val) (((val) >> 0) & 0x)
@@ -206,6 +208,8 @@ struct tegra_spi_data {
u32 command1_reg;
u32 dma_control_reg;
u32 def_command1_reg;
+ u32 spi_cs_timing1;
+ u32 spi_cs_timing2;
struct completion xfer_completion;
struct spi_transfer *curr_xfer;
@@ -723,6 +727,43 @@ static void tegra_spi_deinit_dma_param(struct
tegra_spi_data *tspi,
dma_release_channel(dma_chan);
}
+static void tegra_spi_set_hw_cs_timing(struct spi_device *spi, u8 setup_dly,
+ u8 hold_dly, u8 inactive_dly)
+{
+ struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master);
+ u32 setup_hold;
+ u32 spi_cs_timing;
+ u32 inactive_cycles;
+ u8 cs_state;
+
+ setup_dly = min_t(u8, setup_dly, MAX_SETUP_HOLD_CYCLES);
+ hold_dly = min_t(u8, hold_dly, MAX_SETUP_HOLD_CYCLES);
+ if (setup_dly && hold_dly) {
+ setup_hold = SPI_SETUP_HOLD(setup_dly - 1, hold_dly - 1);
+ spi_cs_timing = SPI_CS_SETUP_HOLD(tspi->spi_cs_timing1,
+ spi->chip_select,
+ setup_hold);
+ if (tspi->spi_cs_timing1 != spi_cs_timing) {
+ tspi->spi_cs_timing1 = spi_cs_timing;
+ tegra_spi_writel(tspi, spi_cs_timing, SPI_CS_TIMING1);
+ }
+ }
+
+ inactive_cycles = min_t(u8, inactive_dly, MAX_INACTIVE_CYCLES);
+ if (inactive_cycles)
+ inactive_cycles--;
+ cs_state = inactive_cycles ? 0 : 1;
+ spi_cs_timing = tspi->spi_cs_timing2;
+ SPI_SET_CS_ACTIVE_BETWEEN_PACKETS(spi_cs_timing, spi->chip_select,
+ cs_state);
+ SPI_SET_CYCLES_BETWEEN_PACKETS(spi_cs_timing, spi->chip_select,
+ inactive_cycles);
+ if (tspi->spi_cs_timing2 != spi_cs_timing) {
+ tspi->spi_cs_timing2 = spi_cs_timing;
+ tegra_spi_writel(tspi, spi_cs_timing, SPI_CS_TIMING2);
+ }
+}
+
static u32 tegra_spi_setup_transfer_one(struct spi_device *spi,
struct spi_transfer *t,
bool is_first_of_msg,
@@ -1232,6 +1273,7 @@ static int tegra_spi_probe(struct platform_device *pdev)
master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
master->setup = tegra_spi_setup;
master->transfer_one_message = tegra_spi_transfer_one_message;
+ master->set_cs_timing = tegra_spi_set_hw_cs_timing;
master->num_chipselect = MAX_CHIP_SELECT;
master->auto_runtime_pm = true;
bus_num = of_alias_get_id(pdev->dev.of_node, "spi");
@@ -1307,6 +1349,8 @@ static int tegra_spi_probe(struct platform_device *pdev)
reset_control_deassert(tspi->rst);
tspi->def_command1_reg = SPI_M_S;
tegra_spi_writel(tspi, tspi->def_command1_reg, SPI_COMMAND1);
+ tspi->spi_cs_timing1 = tegra_spi_readl(tspi, SPI_CS_TIMING1);
+ tspi->spi_cs_timing2 = tegra_spi_readl(tspi, SPI_CS_TIMING2);
pm_runtime_put(>dev);
ret = request_threaded_irq(tspi->irq, tegra_spi_isr,
tegra_spi_isr_thread, IRQF_ONESHOT,
--
2.7.4
[PATCH V5 2/4] spi: tegra114: add support for hw based cs
Tegra SPI controller supports both HW and SW based CS control
for SPI transfers.
This patch adds support for HW based CS control where CS is driven
to active state during the transfer and is driven inactive at the
end of the transfer directly by the HW.
This patch enables the use of HW based CS only for single transfers
without cs_change request.
Signed-off-by: Sowjanya Komatineni
---
drivers/spi/spi-tegra114.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index f47417dd9edb..0cb0932d32fd 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -193,6 +193,7 @@ struct tegra_spi_data {
unsigneddma_buf_size;
unsignedmax_buf_size;
boolis_curr_dma_xfer;
+ booluse_hw_based_cs;
struct completion rx_dma_complete;
struct completion tx_dma_complete;
@@ -723,7 +724,9 @@ static void tegra_spi_deinit_dma_param(struct
tegra_spi_data *tspi,
}
static u32 tegra_spi_setup_transfer_one(struct spi_device *spi,
- struct spi_transfer *t, bool is_first_of_msg)
+ struct spi_transfer *t,
+ bool is_first_of_msg,
+ bool is_single_xfer)
{
struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master);
u32 speed = t->speed_hz;
@@ -780,11 +783,17 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device
*spi,
if (spi->cs_gpiod)
gpiod_set_value(spi->cs_gpiod, 1);
- command1 |= SPI_CS_SW_HW;
- if (spi->mode & SPI_CS_HIGH)
- command1 |= SPI_CS_SW_VAL;
- else
- command1 &= ~SPI_CS_SW_VAL;
+ if (is_single_xfer && !(t->cs_change)) {
+ tspi->use_hw_based_cs = true;
+ command1 &= ~(SPI_CS_SW_HW | SPI_CS_SW_VAL);
+ } else {
+ tspi->use_hw_based_cs = false;
+ command1 |= SPI_CS_SW_HW;
+ if (spi->mode & SPI_CS_HIGH)
+ command1 |= SPI_CS_SW_VAL;
+ else
+ command1 &= ~SPI_CS_SW_VAL;
+ }
tegra_spi_writel(tspi, 0, SPI_COMMAND2);
} else {
@@ -905,11 +914,14 @@ static void tegra_spi_transfer_end(struct spi_device *spi)
if (spi->cs_gpiod)
gpiod_set_value(spi->cs_gpiod, 0);
- if (cs_val)
- tspi->command1_reg |= SPI_CS_SW_VAL;
- else
- tspi->command1_reg &= ~SPI_CS_SW_VAL;
- tegra_spi_writel(tspi, tspi->command1_reg, SPI_COMMAND1);
+ if (!tspi->use_hw_based_cs) {
+ if (cs_val)
+ tspi->command1_reg |= SPI_CS_SW_VAL;
+ else
+ tspi->command1_reg &= ~SPI_CS_SW_VAL;
+ tegra_spi_writel(tspi, tspi->command1_reg, SPI_COMMAND1);
+ }
+
tegra_spi_writel(tspi, tspi->def_command1_reg, SPI_COMMAND1);
}
@@ -936,16 +948,19 @@ static int tegra_spi_transfer_one_message(struct
spi_master *master,
struct spi_device *spi = msg->spi;
int ret;
bool skip = false;
+ int single_xfer;
msg->status = 0;
msg->actual_length = 0;
+ single_xfer = list_is_singular(>transfers);
list_for_each_entry(xfer, >transfers, transfer_list) {
u32 cmd1;
reinit_completion(>xfer_completion);
- cmd1 = tegra_spi_setup_transfer_one(spi, xfer, is_first_msg);
+ cmd1 = tegra_spi_setup_transfer_one(spi, xfer, is_first_msg,
+ single_xfer);
if (!xfer->len) {
ret = 0;
--
2.7.4
[PATCH V5 4/4] spi: tegra114: add support for TX and RX trimmers
Tegra SPI master controller has programmable trimmers to adjust the
data with respect to the clock.
These trimmers are programmed in TX_CLK_TAP_DELAY and RX_CLK_TAP_DELAY
fields of COMMAND2 register.
SPI TX trimmer is to adjust the outgoing data with respect to the
outgoing clock and SPI RX trimmer is to adjust the loopback clock with
respect to the incoming data from the slave device.
These trimmers vary based on trace lengths of the platform design for
each of the slaves on the SPI bus and optimal value programmed is from
the platform validation across PVT.
This patch adds support for configuring TX and RX clock delay trimmers
through the device tree properties.
Signed-off-by: Sowjanya Komatineni
---
drivers/spi/spi-tegra114.c | 67 --
1 file changed, 65 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index e59ff7c1cee6..253a7f182fc9 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -169,6 +169,11 @@ struct tegra_spi_soc_data {
bool has_intr_mask_reg;
};
+struct tegra_spi_client_data {
+ int tx_clk_tap_delay;
+ int rx_clk_tap_delay;
+};
+
struct tegra_spi_data {
struct device *dev;
struct spi_master *master;
@@ -208,8 +213,10 @@ struct tegra_spi_data {
u32 command1_reg;
u32 dma_control_reg;
u32 def_command1_reg;
+ u32 def_command2_reg;
u32 spi_cs_timing1;
u32 spi_cs_timing2;
+ u8 last_used_cs;
struct completion xfer_completion;
struct spi_transfer *curr_xfer;
@@ -770,10 +777,12 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device
*spi,
bool is_single_xfer)
{
struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master);
+ struct tegra_spi_client_data *cdata = spi->controller_data;
u32 speed = t->speed_hz;
u8 bits_per_word = t->bits_per_word;
- u32 command1;
+ u32 command1, command2;
int req_mode;
+ u32 tx_tap = 0, rx_tap = 0;
if (speed != tspi->cur_speed) {
clk_set_rate(tspi->clk, speed);
@@ -836,7 +845,18 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device
*spi,
command1 &= ~SPI_CS_SW_VAL;
}
- tegra_spi_writel(tspi, 0, SPI_COMMAND2);
+ if (tspi->last_used_cs != spi->chip_select) {
+ if (cdata && cdata->tx_clk_tap_delay)
+ tx_tap = cdata->tx_clk_tap_delay;
+ if (cdata && cdata->rx_clk_tap_delay)
+ rx_tap = cdata->rx_clk_tap_delay;
+ command2 = SPI_TX_TAP_DELAY(tx_tap) |
+ SPI_RX_TAP_DELAY(rx_tap);
+ if (command2 != tspi->def_command2_reg)
+ tegra_spi_writel(tspi, command2, SPI_COMMAND2);
+ tspi->last_used_cs = spi->chip_select;
+ }
+
} else {
command1 = tspi->command1_reg;
command1 &= ~SPI_BIT_LENGTH(~0);
@@ -892,9 +912,42 @@ static int tegra_spi_start_transfer_one(struct spi_device
*spi,
return ret;
}
+static struct tegra_spi_client_data
+ *tegra_spi_parse_cdata_dt(struct spi_device *spi)
+{
+ struct tegra_spi_client_data *cdata;
+ struct device_node *slave_np;
+
+ slave_np = spi->dev.of_node;
+ if (!slave_np) {
+ dev_dbg(>dev, "device node not found\n");
+ return NULL;
+ }
+
+ cdata = kzalloc(sizeof(*cdata), GFP_KERNEL);
+ if (!cdata)
+ return NULL;
+
+ of_property_read_u32(slave_np, "nvidia,tx-clk-tap-delay",
+>tx_clk_tap_delay);
+ of_property_read_u32(slave_np, "nvidia,rx-clk-tap-delay",
+>rx_clk_tap_delay);
+ return cdata;
+}
+
+static void tegra_spi_cleanup(struct spi_device *spi)
+{
+ struct tegra_spi_client_data *cdata = spi->controller_data;
+
+ spi->controller_data = NULL;
+ if (spi->dev.of_node)
+ kfree(cdata);
+}
+
static int tegra_spi_setup(struct spi_device *spi)
{
struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master);
+ struct tegra_spi_client_data *cdata = spi->controller_data;
u32 val;
unsigned long flags;
int ret;
@@ -905,6 +958,11 @@ static int tegra_spi_setup(struct spi_device *spi)
spi->mode & SPI_CPHA ? "" : "~",
Re: [PATCH -tip v8 0/6] tracing/probes: uaccess: Add support user-space access
On Mon, 13 May 2019 15:38:24 -0300 Arnaldo Carvalho de Melo wrote: > Em Fri, May 10, 2019 at 12:12:49AM +0900, Masami Hiramatsu escreveu: > > Hi, > > > > Here is the v8 series of probe-event to support user-space access. > > Previous version is here. > > > > https://lkml.kernel.org/r/155732230159.12756.15040196512285621636.stgit@devnote2 > > > > In this version, I fixed some typos/style issues and renamed fields > > according to Ingo's comment, and added Ack from Steve. > > > > Also this version is rebased on the latest -tip/master tree. > > Ingo, since this touches 'perf probe' and Steven already provided an > Acked-by, if you're ok with it I can process these, testing the 'perf > probe' changes and then ship it to you in my next pull req, ok? Thanks Arnaldo! For the perf probe enhancement, it should work on the kernel which doesn't support 'u' prefix. :) Thank you, > > - Arnaldo > > > Changes in v8: > > [2/6] Fix style issues and typos according to Ingo's comment. > > [3/6] Fix style issues according to Ingo's comment. > > [6/6] Fix a typo and rename user field to user_access field. > > > > > > In summary, strncpy_from_user() should work as below > > > > - strncpy_from_user() can access user memory with set_fs(USER_DS) > >in task context > > > > - strncpy_from_user() can access kernel memory with set_fs(KERNEL_DS) > >in task context (e.g. devtmpfsd and init) > > > > - strncpy_from_user() can access user/kernel memory (depends on DS) > >in IRQ context if pagefault is disabled. (both verified) > > > > Note that this changes the warning behavior when > > CONFIG_DEBUG_ATOMIC_SLEEP=y, it still warns when > > __copy_from_user_inatomic() is called in IRQ context, but don't > > warn if pagefault is disabled because it will not sleep in > > atomic. > > > > > > Kprobe event user-space memory access features: > > > > For user-space access extension, this series adds 2 features, > > "ustring" type and user-space dereference syntax. "ustring" is > > used for recording a null-terminated string in user-space from > > kprobe events. > > > > "ustring" type is easy, it is able to use instead of "string" > > type, so if you want to record a user-space string via > > "__user char *", you can use ustring type instead of string. > > For example, > > > > echo 'p do_sys_open path=+0($arg2):ustring' >> kprobe_events > > > > will record the path string from user-space. > > > > The user-space dereference syntax is also simple. Thi just > > adds 'u' prefix before an offset value. > > > >+|-u() > > > > e.g. +u8(%ax), +u0(+0(%si)) > > > > This is more generic. If you want to refer the variable in user- > > space from its address or access a field in data structure in > > user-space, you need to use this. > > > > For example, if you probe do_sched_setscheduler(pid, policy, > > param) and record param->sched_priority, you can add new > > probe as below; > > > >p do_sched_setscheduler priority=+u0($arg3) > > > > Actually, with this feature, "ustring" type is not absolutely > > necessary, because these are same meanings. > > > > +0($arg2):ustring == +u0($arg2):string > > > > Note that kprobe event provides these methods, but it doesn't > > change it from kernel to user automatically because we do not > > know whether the given address is in userspace or kernel on > > some arch. > > > > > > Thank you, > > > > --- > > > > Masami Hiramatsu (6): > > x86/uaccess: Allow access_ok() in irq context if pagefault_disabled > > uaccess: Add non-pagefault user-space read functions > > tracing/probe: Add ustring type for user-space string > > tracing/probe: Support user-space dereference > > selftests/ftrace: Add user-memory access syntax testcase > > perf-probe: Add user memory access attribute support > > > > > > Documentation/trace/kprobetrace.rst| 28 - > > Documentation/trace/uprobetracer.rst | 10 +- > > arch/x86/include/asm/uaccess.h |4 - > > include/linux/uaccess.h| 19 +++ > > kernel/trace/trace.c |7 + > > kernel/trace/trace_kprobe.c| 37 ++ > > kernel/trace/trace_probe.c | 37 +- > > kernel/trace/trace_probe.h |3 > > kernel/trace/trace_probe_tmpl.h| 37 +- > > kernel/trace/trace_uprobe.c| 19 +++ > > mm/maccess.c | 122 > > +++- > > tools/perf/Documentation/perf-probe.txt|3 > > tools/perf/util/probe-event.c | 11 ++ > > tools/perf/util/probe-event.h |2 > > tools/perf/util/probe-file.c |7 + > > tools/perf/util/probe-file.h |1 > > tools/perf/util/probe-finder.c | 19 ++-
Re: [PATCH v1 4/8] soc/fsl/qbman: Use index when accessing device tree properties
On Mon, 2019-05-13 at 17:40 +, Roy Pledge wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On 5/13/2019 12:40 PM, Joakim Tjernlund wrote:
> > On Mon, 2019-05-13 at 16:09 +, Roy Pledge wrote:
> > > The index value should be passed to the of_parse_phandle()
> > > function to ensure the correct property is read.
> > Is this a bug fix? Maybe for stable too?
> >
> > Jocke
> Yes this could go to stable. I will include sta...@vger.kernel.org when
> I send the next version.
I think you need to send this patch separately then. The whole series cannot go
to stable.
Jocke
> > > Signed-off-by: Roy Pledge
> > > ---
> > > drivers/soc/fsl/qbman/dpaa_sys.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/soc/fsl/qbman/dpaa_sys.c
> > > b/drivers/soc/fsl/qbman/dpaa_sys.c
> > > index 3e0a7f3..0b901a8 100644
> > > --- a/drivers/soc/fsl/qbman/dpaa_sys.c
> > > +++ b/drivers/soc/fsl/qbman/dpaa_sys.c
> > > @@ -49,7 +49,7 @@ int qbman_init_private_mem(struct device *dev, int idx,
> > > dma_addr_t *addr,
> > > idx, ret);
> > > return -ENODEV;
> > > }
> > > - mem_node = of_parse_phandle(dev->of_node, "memory-region", 0);
> > > + mem_node = of_parse_phandle(dev->of_node, "memory-region", idx);
> > > if (mem_node) {
> > > ret = of_property_read_u64(mem_node, "size", );
> > > if (ret) {
> > > --
> > > 2.7.4
> > >
[PATCH] arm64: dts: imx8qxp: Add gpio alias
Add i.MX8QXP GPIO alias for kernel GPIO driver usage.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index b17c22e..923705e 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -22,6 +22,14 @@
mmc2 =
serial0 = _lpuart0;
mu1 = _mu1;
+ gpio0 = _gpio0;
+ gpio1 = _gpio1;
+ gpio2 = _gpio2;
+ gpio3 = _gpio3;
+ gpio4 = _gpio4;
+ gpio5 = _gpio5;
+ gpio6 = _gpio6;
+ gpio7 = _gpio7;
};
cpus {
--
2.7.4
Re: [PATCH 1/3 v5] add a new ima hook and policy to measure the cmdline
On Mon, May 13, 2019 at 9:56 AM Mimi Zohar wrote:
>
> On Fri, 2019-05-10 at 15:37 -0700, Prakhar Srivastava wrote:
>
> > +/*
> > + * process_buffer_measurement - Measure the buffer passed to ima log.
>
> "passed to ima log" is unnecessary.
>
> > + * (Instead of using the file hash use the buffer hash).
>
> This comment, if needed, belongs in the text description area below,
> not here.
>
> > + * @buf - The buffer that needs to be added to the log
> > + * @size - size of buffer(in bytes)
> > + * @eventname - event name to be used for buffer.
>
> Missing are the other fields.
>
> > + *
> > + * The buffer passed is added to the ima log.
> > + *
> > + * On success return 0.
> > + * On error cases surface errors from ima calls.
>
> Only IMA-appraise returns errors to the caller. There's no point in
> returning an error.
>
>
> > + */
> > +static int process_buffer_measurement(const void *buf, int size,
> > + const char *eventname, const struct cred
> > *cred,
> > + u32 secid)
>
> This should be "static void".
>
> > +{
> > +
> > + if (action & IMA_MEASURE)
> > + ret = ima_store_template(entry, violation, NULL, buf, pcr);
> > +
> > + if (action & IMA_AUDIT)
> > + ima_audit_measurement(iint, event_data.filename);
>
> The cover letter and patch description say this patch set is limited
> to measuring the boot command line - IMA-measurement.
> ima_audit_measurement() adds file hashes in the audit log, which can
> be used for security analytics and/or forensics. This is part of IMA-
> audit. The call to ima_audit_measurement() is inappropriate.
>
To clarify, in one of the previous versions you mentioned it
might be helpful to add audit.
I might have misunderstood you, but i will remove the
audit_measurement and make other corrections.
Thankyou for your feedback.
- Thanks,
Prakhar Srivastava
Mimi
Re: linux-next: build failure after merge of the ecryptfs tree
Hi Masahiro, On Tue, 14 May 2019 13:16:37 +0900 Masahiro Yamada wrote: > > If you are talking about the rebuild of > .tmp_versions/*.mod files, > yes, they are cleaned up every time. > > # Create temporary dir for module support files > # clean it up only when building all modules > cmd_crmodverdir = $(Q)mkdir -p $(MODVERDIR) \ > $(if $(KBUILD_MODULES),; rm -f $(MODVERDIR)/*) > > > I think the reason is that > we want to make sure stale modules are not remaining > when CONFIG_MY_DRIVER=m is turned into CONFIG_MY_DRIVER=n > > > Rebuilding .mod files is not expensive. > > I think this behavior can be improved, but > that is how it has been working for a long time. when you say "not expensive", how long is that? Because an x86_64 allmodconfig build currently produces 7313 of those files, so at .01 seconds each (for example) that would add over a minute to each of my builds ... and I do lots of builds every day. OK, so it may not be that significant (so a millisecond each is obviously not a problem), but just wondering if it can be avoided. -- Cheers, Stephen Rothwell pgpg_qedlyCoj.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the thermal-soc tree with Linus' tree
Hi Eduardo, On Mon, 13 May 2019 20:44:11 -0700 Eduardo Valentin wrote: > > Thanks for spotting this. I am re-doing the branch based off v5.1-rc7, > where the last conflict went in with my current queue. Its really not worth the rebase. Just fix the build problem and send it all to Linus. -- Cheers, Stephen Rothwell pgpfBu77TsHdj.pgp Description: OpenPGP digital signature
Re: [v2 PATCH] mm: vmscan: correct nr_reclaimed for THP
On Mon, May 13, 2019 at 2:45 PM Michal Hocko wrote:
>
> On Mon 13-05-19 14:09:59, Yang Shi wrote:
> [...]
> > I think we can just account 512 base pages for nr_scanned for
> > isolate_lru_pages() to make the counters sane since PGSCAN_KSWAPD/DIRECT
> > just use it.
> >
> > And, sc->nr_scanned should be accounted as 512 base pages too otherwise we
> > may have nr_scanned < nr_to_reclaim all the time to result in false-negative
> > for priority raise and something else wrong (e.g. wrong vmpressure).
>
> Be careful. nr_scanned is used as a pressure indicator to slab shrinking
> AFAIR. Maybe this is ok but it really begs for much more explaining
I don't know why my company mailbox didn't receive this email, so I
replied with my personal email.
It is not used to double slab pressure any more since commit
9092c71bb724 ("mm: use sc->priority for slab shrink targets"). It uses
sc->priority to determine the pressure for slab shrinking now.
So, I think we can just remove that "double slab pressure" code. It is
not used actually and looks confusing now. Actually, the "double slab
pressure" does something opposite. The extra inc to sc->nr_scanned
just prevents from raising sc->priority.
> than "it should be fine". This should have happened when THP swap out
> was implemented...
>
> --
> Michal Hocko
> SUSE Labs
>
[PATCH V4 0/4] additional features to Tegra SPI
[V4] : This patch series version includes - Updated GPIO based chip select control using GPIO descriptor. - HW based chip select implementation is same as V3 but V4 has this patch updated to be on top of above changes. - HW CS timing implementation is same as V3 but V4 has this patch updated to be on top of above changes. - support for TX and RX trimmers implementation is same as V3 but V4 has this patch updated to be on top of above changes and updated commit description. [V3] : This patch series version includes - only patches that are not applied from V2. - splitted expanding mode and adding LSByte First support in separate patches and removed DT property for selecting LSByte First. - Updated GPIO based chip select control to use spi_set_cs from SPI core. - HW based chip select implementation is same as V2 but V3 has this patch updated to be on top of above changes. - HW CS timing implementation is same as V2 but V3 has this patch updated to be on top of above changes. - support for TX and RX trimmers implementation is same as V2 but V3 has this patch updated to be on top of above changes and updated commit description. [V2] : This patch series version includes - only patches that are not applied from V1. - changed order of patches to include all fixes prior to new features support. - Removed HW CS timing from DT properties and created set_cs_timing SPI master optional method for SPI controllers to implement and created API spi_cs_timing for SPI client drivers to request CS setup, hold and inactive delay timing configuration. - Fixed HW based CS decision to be based on single transfer and cs_change. Remove selection of HW based CS through DT. Sowjanya Komatineni (4): spi: tegra114: add support for gpio based CS spi: tegra114: add support for hw based cs spi: tegra114: add support for HW CS timing spi: tegra114: add support for TX and RX trimmers drivers/spi/spi-tegra114.c | 169 - 1 file changed, 153 insertions(+), 16 deletions(-) -- 2.7.4
linux-next: Tree for May 14
Hi all, Please do not add any v5.3 material to your linux-next included trees/branches until after v5.2-rc1 has been released. Changes since 20190513: The thermal-soc tree still had its build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 2499 2385 files changed, 77440 insertions(+), 25834 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 298 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (a13f0655503a Merge tag 'iommu-updates-v5.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/joro/iommu) Merging fixes/master (d15da9d3fb74 kernel/compat.c: mark expected switch fall-throughs) Merging kspp-gustavo/for-next/kspp (ccaa75187a5f memstick: mark expected switch fall-throughs) Merging kbuild-current/fixes (a2d635decbfa Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm) Merging arc-current/for-curr (ea4bb8f4c41b ARC: mm: SIGSEGV userspace trying to access kernel virtual memory) Merging arm-current/fixes (e17b1af96b2a ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache) Merging arm64-fixes/for-next/fixes (4e69ecf4da1e arm64/module: ftrace: deal with place relative nature of PLTs) Merging m68k-current/for-linus (fdd20ec8786a Documentation/features/time: Mark m68k having modern-timekeeping) Merging powerpc-fixes/fixes (12f363511d47 powerpc/32s: Fix BATs setting with CONFIG_STRICT_KERNEL_RWX) Merging sparc/master (b970afcfcabd Merge tag 'powerpc-5.2-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/powerpc/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (d4c26eb6e721 net: ethernet: stmmac: dwmac-sun8i: enable support of unicast filtering) Merging bpf/master (69dda13fdaff Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging ipsec/master (9b3040a6aafd ipv4: Define __ipv4_neigh_lookup_noref when CONFIG_INET is disabled) Merging netfilter/master (d4c26eb6e721 net: ethernet: stmmac: dwmac-sun8i: enable support of unicast filtering) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (7a0f8ad5ff63 Merge ath-current from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git) Merging mac80211/master (5f05836831f6 net/sched: avoid double free on matchall reoffload) Merging rdma-fixes/for-rc (2557fabd6e29 RDMA/hns: Bugfix for mapping user db) Merging sound-current/for-linus (ed180abba7f1 ALSA: hda: Fix race between creating and refreshing sysfs entries) Merging sound-asoc-fixes/for-linus (28776b33e575 Merge branch 'asoc-5.1' into asoc-linus) Merging regmap-fixes/for-linus (1d6106cafb37 Merge branch 'regmap-5.1' into regmap-linus) Merging regulator-fixes/for-linus (c7b5128f72ef Merge branch 'regulator-5.1' into regulator-linus) Merging spi-fixes/for-linus (3de0496378eb Merge branch 'spi-5.1' into spi-linus) Merging pci-current/for-linus (9c9c5fc89b09 PCI/LINK: Add Kconfig option (default off)) Merging driver-core.current/driver-core-linus (d7a02fa0a8f9 Merge tag 'upstream-5.2-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/rw/ubifs) Merging tty.current/tty-linus (d7a02fa0a8f9 Merge tag 'upstr
[PATCH V4 2/4] spi: tegra114: add support for hw based cs
Tegra SPI controller supports both HW and SW based CS control
for SPI transfers.
This patch adds support for HW based CS control where CS is driven
to active state during the transfer and is driven inactive at the
end of the transfer directly by the HW.
This patch enables the use of HW based CS only for single transfers
without cs_change request.
Signed-off-by: Sowjanya Komatineni
---
drivers/spi/spi-tegra114.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index f47417dd9edb..0cb0932d32fd 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -193,6 +193,7 @@ struct tegra_spi_data {
unsigneddma_buf_size;
unsignedmax_buf_size;
boolis_curr_dma_xfer;
+ booluse_hw_based_cs;
struct completion rx_dma_complete;
struct completion tx_dma_complete;
@@ -723,7 +724,9 @@ static void tegra_spi_deinit_dma_param(struct
tegra_spi_data *tspi,
}
static u32 tegra_spi_setup_transfer_one(struct spi_device *spi,
- struct spi_transfer *t, bool is_first_of_msg)
+ struct spi_transfer *t,
+ bool is_first_of_msg,
+ bool is_single_xfer)
{
struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master);
u32 speed = t->speed_hz;
@@ -780,11 +783,17 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device
*spi,
if (spi->cs_gpiod)
gpiod_set_value(spi->cs_gpiod, 1);
- command1 |= SPI_CS_SW_HW;
- if (spi->mode & SPI_CS_HIGH)
- command1 |= SPI_CS_SW_VAL;
- else
- command1 &= ~SPI_CS_SW_VAL;
+ if (is_single_xfer && !(t->cs_change)) {
+ tspi->use_hw_based_cs = true;
+ command1 &= ~(SPI_CS_SW_HW | SPI_CS_SW_VAL);
+ } else {
+ tspi->use_hw_based_cs = false;
+ command1 |= SPI_CS_SW_HW;
+ if (spi->mode & SPI_CS_HIGH)
+ command1 |= SPI_CS_SW_VAL;
+ else
+ command1 &= ~SPI_CS_SW_VAL;
+ }
tegra_spi_writel(tspi, 0, SPI_COMMAND2);
} else {
@@ -905,11 +914,14 @@ static void tegra_spi_transfer_end(struct spi_device *spi)
if (spi->cs_gpiod)
gpiod_set_value(spi->cs_gpiod, 0);
- if (cs_val)
- tspi->command1_reg |= SPI_CS_SW_VAL;
- else
- tspi->command1_reg &= ~SPI_CS_SW_VAL;
- tegra_spi_writel(tspi, tspi->command1_reg, SPI_COMMAND1);
+ if (!tspi->use_hw_based_cs) {
+ if (cs_val)
+ tspi->command1_reg |= SPI_CS_SW_VAL;
+ else
+ tspi->command1_reg &= ~SPI_CS_SW_VAL;
+ tegra_spi_writel(tspi, tspi->command1_reg, SPI_COMMAND1);
+ }
+
tegra_spi_writel(tspi, tspi->def_command1_reg, SPI_COMMAND1);
}
@@ -936,16 +948,19 @@ static int tegra_spi_transfer_one_message(struct
spi_master *master,
struct spi_device *spi = msg->spi;
int ret;
bool skip = false;
+ int single_xfer;
msg->status = 0;
msg->actual_length = 0;
+ single_xfer = list_is_singular(>transfers);
list_for_each_entry(xfer, >transfers, transfer_list) {
u32 cmd1;
reinit_completion(>xfer_completion);
- cmd1 = tegra_spi_setup_transfer_one(spi, xfer, is_first_msg);
+ cmd1 = tegra_spi_setup_transfer_one(spi, xfer, is_first_msg,
+ single_xfer);
if (!xfer->len) {
ret = 0;
--
2.7.4
[PATCH V4 3/4] spi: tegra114: add support for HW CS timing
This patch implements set_cs_timing SPI controller method to allow
SPI client driver to configure device specific SPI CS timings.
Signed-off-by: Sowjanya Komatineni
---
drivers/spi/spi-tegra114.c | 48 --
1 file changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 0cb0932d32fd..e59ff7c1cee6 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -95,8 +95,10 @@
(reg = (((val) & 0x1) << ((cs) * 8 + 5)) | \
((reg) & ~(1 << ((cs) * 8 + 5
#define SPI_SET_CYCLES_BETWEEN_PACKETS(reg, cs, val) \
- (reg = (((val) & 0xF) << ((cs) * 8)) | \
- ((reg) & ~(0xF << ((cs) * 8
+ (reg = (((val) & 0x1F) << ((cs) * 8)) | \
+ ((reg) & ~(0x1F << ((cs) * 8
+#define MAX_SETUP_HOLD_CYCLES 16
+#define MAX_INACTIVE_CYCLES32
#define SPI_TRANS_STATUS 0x010
#define SPI_BLK_CNT(val) (((val) >> 0) & 0x)
@@ -206,6 +208,8 @@ struct tegra_spi_data {
u32 command1_reg;
u32 dma_control_reg;
u32 def_command1_reg;
+ u32 spi_cs_timing1;
+ u32 spi_cs_timing2;
struct completion xfer_completion;
struct spi_transfer *curr_xfer;
@@ -723,6 +727,43 @@ static void tegra_spi_deinit_dma_param(struct
tegra_spi_data *tspi,
dma_release_channel(dma_chan);
}
+static void tegra_spi_set_hw_cs_timing(struct spi_device *spi, u8 setup_dly,
+ u8 hold_dly, u8 inactive_dly)
+{
+ struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master);
+ u32 setup_hold;
+ u32 spi_cs_timing;
+ u32 inactive_cycles;
+ u8 cs_state;
+
+ setup_dly = min_t(u8, setup_dly, MAX_SETUP_HOLD_CYCLES);
+ hold_dly = min_t(u8, hold_dly, MAX_SETUP_HOLD_CYCLES);
+ if (setup_dly && hold_dly) {
+ setup_hold = SPI_SETUP_HOLD(setup_dly - 1, hold_dly - 1);
+ spi_cs_timing = SPI_CS_SETUP_HOLD(tspi->spi_cs_timing1,
+ spi->chip_select,
+ setup_hold);
+ if (tspi->spi_cs_timing1 != spi_cs_timing) {
+ tspi->spi_cs_timing1 = spi_cs_timing;
+ tegra_spi_writel(tspi, spi_cs_timing, SPI_CS_TIMING1);
+ }
+ }
+
+ inactive_cycles = min_t(u8, inactive_dly, MAX_INACTIVE_CYCLES);
+ if (inactive_cycles)
+ inactive_cycles--;
+ cs_state = inactive_cycles ? 0 : 1;
+ spi_cs_timing = tspi->spi_cs_timing2;
+ SPI_SET_CS_ACTIVE_BETWEEN_PACKETS(spi_cs_timing, spi->chip_select,
+ cs_state);
+ SPI_SET_CYCLES_BETWEEN_PACKETS(spi_cs_timing, spi->chip_select,
+ inactive_cycles);
+ if (tspi->spi_cs_timing2 != spi_cs_timing) {
+ tspi->spi_cs_timing2 = spi_cs_timing;
+ tegra_spi_writel(tspi, spi_cs_timing, SPI_CS_TIMING2);
+ }
+}
+
static u32 tegra_spi_setup_transfer_one(struct spi_device *spi,
struct spi_transfer *t,
bool is_first_of_msg,
@@ -1232,6 +1273,7 @@ static int tegra_spi_probe(struct platform_device *pdev)
master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
master->setup = tegra_spi_setup;
master->transfer_one_message = tegra_spi_transfer_one_message;
+ master->set_cs_timing = tegra_spi_set_hw_cs_timing;
master->num_chipselect = MAX_CHIP_SELECT;
master->auto_runtime_pm = true;
bus_num = of_alias_get_id(pdev->dev.of_node, "spi");
@@ -1307,6 +1349,8 @@ static int tegra_spi_probe(struct platform_device *pdev)
reset_control_deassert(tspi->rst);
tspi->def_command1_reg = SPI_M_S;
tegra_spi_writel(tspi, tspi->def_command1_reg, SPI_COMMAND1);
+ tspi->spi_cs_timing1 = tegra_spi_readl(tspi, SPI_CS_TIMING1);
+ tspi->spi_cs_timing2 = tegra_spi_readl(tspi, SPI_CS_TIMING2);
pm_runtime_put(>dev);
ret = request_threaded_irq(tspi->irq, tegra_spi_isr,
tegra_spi_isr_thread, IRQF_ONESHOT,
--
2.7.4
[PATCH V4 1/4] spi: tegra114: add support for gpio based CS
This patch adds support for GPIO based CS control through SPI core function spi_set_cs. Signed-off-by: Sowjanya Komatineni --- drivers/spi/spi-tegra114.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c index b1f31bb16659..f47417dd9edb 100644 --- a/drivers/spi/spi-tegra114.c +++ b/drivers/spi/spi-tegra114.c @@ -776,6 +776,10 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device *spi, } else tegra_spi_writel(tspi, command1, SPI_COMMAND1); + /* GPIO based chip select control */ + if (spi->cs_gpiod) + gpiod_set_value(spi->cs_gpiod, 1); + command1 |= SPI_CS_SW_HW; if (spi->mode & SPI_CS_HIGH) command1 |= SPI_CS_SW_VAL; @@ -864,6 +868,10 @@ static int tegra_spi_setup(struct spi_device *spi) } spin_lock_irqsave(>lock, flags); + /* GPIO based chip select control */ + if (spi->cs_gpiod) + gpiod_set_value(spi->cs_gpiod, 0); + val = tspi->def_command1_reg; if (spi->mode & SPI_CS_HIGH) val &= ~SPI_CS_POL_INACTIVE(spi->chip_select); @@ -893,6 +901,10 @@ static void tegra_spi_transfer_end(struct spi_device *spi) struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master); int cs_val = (spi->mode & SPI_CS_HIGH) ? 0 : 1; + /* GPIO based chip select control */ + if (spi->cs_gpiod) + gpiod_set_value(spi->cs_gpiod, 0); + if (cs_val) tspi->command1_reg |= SPI_CS_SW_VAL; else @@ -1199,6 +1211,7 @@ static int tegra_spi_probe(struct platform_device *pdev) master->max_speed_hz = 2500; /* 25MHz */ /* the spi->mode bits understood by this driver: */ + master->use_gpio_descriptors = true; master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST | SPI_TX_DUAL | SPI_RX_DUAL | SPI_3WIRE; master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32); -- 2.7.4
[PATCH V4 4/4] spi: tegra114: add support for TX and RX trimmers
Tegra SPI master controller has programmable trimmers to adjust the
data with respect to the clock.
These trimmers are programmed in TX_CLK_TAP_DELAY and RX_CLK_TAP_DELAY
fields of COMMAND2 register.
SPI TX trimmer is to adjust the outgoing data with respect to the
outgoing clock and SPI RX trimmer is to adjust the loopback clock with
respect to the incoming data from the slave device.
These trimmers vary based on trace lengths of the platform design for
each of the slaves on the SPI bus and optimal value programmed is from
the platform validation across PVT.
This patch adds support for configuring TX and RX clock delay trimmers
through the device tree properties.
Signed-off-by: Sowjanya Komatineni
---
drivers/spi/spi-tegra114.c | 69 --
1 file changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index e59ff7c1cee6..377fcc026794 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -169,6 +169,11 @@ struct tegra_spi_soc_data {
bool has_intr_mask_reg;
};
+struct tegra_spi_client_data {
+ int tx_clk_tap_delay;
+ int rx_clk_tap_delay;
+};
+
struct tegra_spi_data {
struct device *dev;
struct spi_master *master;
@@ -208,8 +213,10 @@ struct tegra_spi_data {
u32 command1_reg;
u32 dma_control_reg;
u32 def_command1_reg;
+ u32 def_command2_reg;
u32 spi_cs_timing1;
u32 spi_cs_timing2;
+ u8 last_used_cs;
struct completion xfer_completion;
struct spi_transfer *curr_xfer;
@@ -770,10 +777,12 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device
*spi,
bool is_single_xfer)
{
struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master);
+ struct tegra_spi_client_data *cdata = spi->controller_data;
u32 speed = t->speed_hz;
u8 bits_per_word = t->bits_per_word;
- u32 command1;
+ u32 command1, command2;
int req_mode;
+ u32 tx_tap = 0, rx_tap = 0;
if (speed != tspi->cur_speed) {
clk_set_rate(tspi->clk, speed);
@@ -836,7 +845,18 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device
*spi,
command1 &= ~SPI_CS_SW_VAL;
}
- tegra_spi_writel(tspi, 0, SPI_COMMAND2);
+ if (tspi->last_used_cs != spi->chip_select) {
+ if (cdata && cdata->tx_clk_tap_delay)
+ tx_tap = cdata->tx_clk_tap_delay;
+ if (cdata && cdata->rx_clk_tap_delay)
+ rx_tap = cdata->rx_clk_tap_delay;
+ command2 = SPI_TX_TAP_DELAY(tx_tap) |
+ SPI_RX_TAP_DELAY(rx_tap);
+ if (command2 != tspi->def_command2_reg)
+ tegra_spi_writel(tspi, command2, SPI_COMMAND2);
+ tspi->last_used_cs = spi->chip_select;
+ }
+
} else {
command1 = tspi->command1_reg;
command1 &= ~SPI_BIT_LENGTH(~0);
@@ -892,9 +912,42 @@ static int tegra_spi_start_transfer_one(struct spi_device
*spi,
return ret;
}
+static struct tegra_spi_client_data
+ *tegra_spi_parse_cdata_dt(struct spi_device *spi)
+{
+ struct tegra_spi_client_data *cdata;
+ struct device_node *slave_np;
+
+ slave_np = spi->dev.of_node;
+ if (!slave_np) {
+ dev_dbg(>dev, "device node not found\n");
+ return NULL;
+ }
+
+ cdata = kzalloc(sizeof(*cdata), GFP_KERNEL);
+ if (!cdata)
+ return NULL;
+
+ of_property_read_u32(slave_np, "nvidia,tx-clk-tap-delay",
+>tx_clk_tap_delay);
+ of_property_read_u32(slave_np, "nvidia,rx-clk-tap-delay",
+>rx_clk_tap_delay);
+ return cdata;
+}
+
+static void tegra_spi_cleanup(struct spi_device *spi)
+{
+ struct tegra_spi_client_data *cdata = spi->controller_data;
+
+ spi->controller_data = NULL;
+ if (spi->dev.of_node)
+ kfree(cdata);
+}
+
static int tegra_spi_setup(struct spi_device *spi)
{
struct tegra_spi_data *tspi = spi_master_get_devdata(spi->master);
+ struct tegra_spi_client_data *cdata = spi->controller_data;
u32 val;
unsigned long flags;
int ret;
@@ -905,6 +958,11 @@ static int tegra_spi_setup(struct spi_device *spi)
spi->mode & SPI_CPHA ? "" : "~",
Re: linux-next: build failure after merge of the ecryptfs tree
Hi Stephen, On Tue, May 14, 2019 at 10:04 AM Stephen Rothwell wrote: > > Hi Masahiro, > > Also, this: > > On Tue, 14 May 2019 09:40:53 +0900 Masahiro Yamada > wrote: > > > > > Mind you, I have no itdea why this file was begin rebuilt, the merge > > > only touched these files: > > > > > > fs/ecryptfs/crypto.c > > > fs/ecryptfs/keystore.c > > Its a bit annoying that the module was even being looked at given > nothing it files depend upon had been modified. If you are talking about the rebuild of .tmp_versions/*.mod files, yes, they are cleaned up every time. # Create temporary dir for module support files # clean it up only when building all modules cmd_crmodverdir = $(Q)mkdir -p $(MODVERDIR) \ $(if $(KBUILD_MODULES),; rm -f $(MODVERDIR)/*) I think the reason is that we want to make sure stale modules are not remaining when CONFIG_MY_DRIVER=m is turned into CONFIG_MY_DRIVER=n Rebuilding .mod files is not expensive. I think this behavior can be improved, but that is how it has been working for a long time. -- Best Regards Masahiro Yamada
[PATCH 1/2] cifs:smbd When reconnecting to server, call smbd_destroy() after all MIDs have been called
From: Long Li
commit 214bab448476 ("cifs: Call MID callback before destroying transport")
assumes that the MID callback should not take srv_mutex, this may not always
be true. SMB Direct requires the MID callback completed before calling
transport so all pending memory registration can be freed. So restore the
orignal calling sequence so TCP transport will use the same code, but moving
smbd_destroy() after all MID has been called.
fixes: 214bab448476 ("cifs: Call MID callback before destroying transport")
Signed-off-by: Long Li
---
fs/cifs/connect.c | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 084756cfdaee..0b3ac8b76d18 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -528,6 +528,21 @@ cifs_reconnect(struct TCP_Server_Info *server)
/* do not want to be sending data on a socket we are freeing */
cifs_dbg(FYI, "%s: tearing down socket\n", __func__);
mutex_lock(>srv_mutex);
+ if (server->ssocket) {
+ cifs_dbg(FYI, "State: 0x%x Flags: 0x%lx\n",
+server->ssocket->state, server->ssocket->flags);
+ kernel_sock_shutdown(server->ssocket, SHUT_WR);
+ cifs_dbg(FYI, "Post shutdown state: 0x%x Flags: 0x%lx\n",
+server->ssocket->state, server->ssocket->flags);
+ sock_release(server->ssocket);
+ server->ssocket = NULL;
+ }
+ server->sequence_number = 0;
+ server->session_estab = false;
+ kfree(server->session_key.response);
+ server->session_key.response = NULL;
+ server->session_key.len = 0;
+ server->lstrp = jiffies;
/* mark submitted MIDs for retry and issue callback */
INIT_LIST_HEAD(_list);
@@ -540,6 +555,7 @@ cifs_reconnect(struct TCP_Server_Info *server)
list_move(_entry->qhead, _list);
}
spin_unlock(_Lock);
+ mutex_unlock(>srv_mutex);
cifs_dbg(FYI, "%s: issuing mid callbacks\n", __func__);
list_for_each_safe(tmp, tmp2, _list) {
@@ -548,24 +564,11 @@ cifs_reconnect(struct TCP_Server_Info *server)
mid_entry->callback(mid_entry);
}
- if (server->ssocket) {
- cifs_dbg(FYI, "State: 0x%x Flags: 0x%lx\n",
-server->ssocket->state, server->ssocket->flags);
- kernel_sock_shutdown(server->ssocket, SHUT_WR);
- cifs_dbg(FYI, "Post shutdown state: 0x%x Flags: 0x%lx\n",
-server->ssocket->state, server->ssocket->flags);
- sock_release(server->ssocket);
- server->ssocket = NULL;
- } else if (cifs_rdma_enabled(server))
+ if (cifs_rdma_enabled(server)) {
+ mutex_lock(>srv_mutex);
smbd_destroy(server);
- server->sequence_number = 0;
- server->session_estab = false;
- kfree(server->session_key.response);
- server->session_key.response = NULL;
- server->session_key.len = 0;
- server->lstrp = jiffies;
-
- mutex_unlock(>srv_mutex);
+ mutex_unlock(>srv_mutex);
+ }
do {
try_to_freeze();
--
2.17.1
[PATCH 2/2] cifs:smbd Use the correct DMA direction when sending data
From: Long Li
When sending data, use the DMA_TO_DEVICE to map buffers. Also log the number
of requests in a compounding request from upper layer.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c
index 251ef1223206..caac37b1de8c 100644
--- a/fs/cifs/smbdirect.c
+++ b/fs/cifs/smbdirect.c
@@ -903,7 +903,7 @@ static int smbd_create_header(struct smbd_connection *info,
request->sge[0].addr = ib_dma_map_single(info->id->device,
(void *)packet,
header_length,
-DMA_BIDIRECTIONAL);
+DMA_TO_DEVICE);
if (ib_dma_mapping_error(info->id->device, request->sge[0].addr)) {
mempool_free(request, info->request_mempool);
rc = -EIO;
@@ -1005,7 +1005,7 @@ static int smbd_post_send_sgl(struct smbd_connection
*info,
for_each_sg(sgl, sg, num_sgs, i) {
request->sge[i+1].addr =
ib_dma_map_page(info->id->device, sg_page(sg),
- sg->offset, sg->length, DMA_BIDIRECTIONAL);
+ sg->offset, sg->length, DMA_TO_DEVICE);
if (ib_dma_mapping_error(
info->id->device, request->sge[i+1].addr)) {
rc = -EIO;
@@ -2110,8 +2110,10 @@ int smbd_send(struct TCP_Server_Info *server,
goto done;
}
- rqst_idx = 0;
+ log_write(INFO, "num_rqst=%d total length=%u\n",
+ num_rqst, remaining_data_length);
+ rqst_idx = 0;
next_rqst:
rqst = _array[rqst_idx];
iov = rqst->rq_iov;
--
2.17.1
Re: linux-next: manual merge of the thermal-soc tree with Linus' tree
Stephen,
On Mon, May 13, 2019 at 10:49:28AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the thermal-soc tree got a conflict in:
>
> MAINTAINERS
>
> between commit:
>
> f23afd75fc99 ("RDMA/efa: Add driver to Kconfig/Makefile")
>
> from Linus' tree and commit:
>
> 7e34eb7dd067 ("thermal: Introduce Amazon's Annapurna Labs Thermal Driver")
>
> from the thermal-soc 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 spotting this. I am re-doing the branch based off v5.1-rc7,
where the last conflict went in with my current queue.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc MAINTAINERS
> index 2ff031b5e620,7defe065470d..
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@@ -745,15 -744,12 +745,21 @@@ S:Supporte
> F: Documentation/networking/device_drivers/amazon/ena.txt
> F: drivers/net/ethernet/amazon/
>
> + AMAZON ANNAPURNA LABS THERMAL MMIO DRIVER
> + M: Talel Shenhar
> + S: Maintained
> + F: Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
> + F: drivers/thermal/thermal_mmio.c
> +
> +AMAZON RDMA EFA DRIVER
> +M: Gal Pressman
> +R: Yossi Leybovich
> +L: linux-r...@vger.kernel.org
> +Q: https://patchwork.kernel.org/project/linux-rdma/list/
> +S: Supported
> +F: drivers/infiniband/hw/efa/
> +F: include/uapi/rdma/efa-abi.h
> +
> AMD CRYPTOGRAPHIC COPROCESSOR (CCP) DRIVER
> M: Tom Lendacky
> M: Gary Hook
Re: [PATCH v3 3/3] thermal: cpu_cooling: Migrate to using the EM framework
On Fri, May 03, 2019 at 10:44:09AM +0100, Quentin Perret wrote:
> The newly introduced Energy Model framework manages power cost tables in
> a generic way. Moreover, it supports a several types of models since the
> tables can come from DT or firmware (through SCMI) for example. On the
> other hand, the cpu_cooling subsystem manages its own power cost tables
> using only DT data.
>
> In order to avoid the duplication of data in the kernel, and in order to
> enable IPA with EMs coming from more than just DT, remove the private
> tables from cpu_cooling.c and migrate it to using the centralized EM
> framework.
>
> The case where the thermal subsystem is used without an Energy Model
> (cpufreq_cooling_ops) is handled by looking directly at CPUFreq's
> frequency table which is already a dependency for cpu_cooling.c anyway.
> Since the thermal framework expects the cooling states in a particular
> order, bail out whenever the CPUFreq table is unsorted, since that is
> fairly uncommon in general, and there are currently no users of
> cpu_cooling for this use-case.
Will this break DT in any way? After this change, are the existing DTs
still compatible with this cpu cooling?
>
> Signed-off-by: Quentin Perret
> ---
> drivers/thermal/Kconfig | 1 +
> drivers/thermal/cpu_cooling.c | 238 --
> 2 files changed, 82 insertions(+), 157 deletions(-)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 653aa27a25a4..d695bd33c440 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -144,6 +144,7 @@ config THERMAL_GOV_USER_SPACE
>
> config THERMAL_GOV_POWER_ALLOCATOR
> bool "Power allocator thermal governor"
> + depends on ENERGY_MODEL
> help
> Enable this to manage platform thermals by dynamically
> allocating and limiting power to devices.
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index f7c1f49ec87f..322ea89dd078 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -48,19 +49,6 @@
> * ...
> */
>
> -/**
> - * struct freq_table - frequency table along with power entries
> - * @frequency: frequency in KHz
> - * @power: power in mW
> - *
> - * This structure is built when the cooling device registers and helps
> - * in translating frequency to power and vice versa.
> - */
> -struct freq_table {
> - u32 frequency;
> - u32 power;
> -};
> -
> /**
> * struct time_in_idle - Idle time stats
> * @time: previous reading of the absolute time that this cpu was idle
> @@ -82,7 +70,7 @@ struct time_in_idle {
> * frequency.
> * @max_level: maximum cooling level. One less than total number of valid
> * cpufreq frequencies.
> - * @freq_table: Freq table in descending order of frequencies
> + * @em: Reference on the Energy Model of the device
> * @cdev: thermal_cooling_device pointer to keep track of the
> * registered cooling device.
> * @policy: cpufreq policy.
> @@ -98,7 +86,7 @@ struct cpufreq_cooling_device {
> unsigned int cpufreq_state;
> unsigned int clipped_freq;
> unsigned int max_level;
> - struct freq_table *freq_table; /* In descending order */
> + struct em_perf_domain *em;
> struct thermal_cooling_device *cdev;
> struct cpufreq_policy *policy;
> struct list_head node;
> @@ -121,14 +109,14 @@ static LIST_HEAD(cpufreq_cdev_list);
> static unsigned long get_level(struct cpufreq_cooling_device *cpufreq_cdev,
> unsigned int freq)
> {
> - struct freq_table *freq_table = cpufreq_cdev->freq_table;
> - unsigned long level;
> + int i;
>
> - for (level = 1; level <= cpufreq_cdev->max_level; level++)
> - if (freq > freq_table[level].frequency)
> + for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
> + if (freq > cpufreq_cdev->em->table[i].frequency)
> break;
> + }
>
> - return level - 1;
> + return cpufreq_cdev->max_level - i - 1;
> }
>
> /**
> @@ -184,105 +172,30 @@ static int cpufreq_thermal_notifier(struct
> notifier_block *nb,
> return NOTIFY_OK;
> }
>
> -/**
> - * update_freq_table() - Update the freq table with power numbers
> - * @cpufreq_cdev:the cpufreq cooling device in which to update the table
> - * @capacitance: dynamic power coefficient for these cpus
> - *
> - * Update the freq table with power numbers. This table will be used in
> - * cpu_power_to_freq() and cpu_freq_to_power() to convert between power and
> - * frequency efficiently. Power is stored in mW, frequency in KHz. The
> - * resulting table is in descending order.
> - *
> - * Return: 0 on success, -EINVAL if there are no OPPs for any CPUs,
> - * or -ENOMEM if we run out of memory.
> - */
> -static int update_freq_table(struct cpufreq_cooling_device
[PATCH] arm64: dts: imx8mq: Add gpio alias
Add i.MX8MQ GPIO alias for kernel GPIO driver usage.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 6d635ba..df33672 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -30,6 +30,11 @@
spi0 =
spi1 =
spi2 =
+ gpio0 =
+ gpio1 =
+ gpio2 =
+ gpio3 =
+ gpio4 =
};
ckil: clock-ckil {
--
2.7.4
Re: [PATCH V6 02/15] PCI/PME: Export pcie_pme_disable_msi() & pcie_pme_no_msi() APIs
On 5/13/2019 12:55 PM, Christoph Hellwig wrote: On Mon, May 13, 2019 at 10:36:13AM +0530, Vidya Sagar wrote: Export pcie_pme_disable_msi() & pcie_pme_no_msi() APIs to enable drivers using these APIs be able to build as loadable modules. But this is a global setting. If you root port is broken you need a per-rootport quirk instead. There is nothing broken in Tegra194 root port as such, rather, this is more of software configuration choice and we are going with legacy interrupts than MSI interrupts (as Tegra194 doesn't support raising PME interrupts through MSI and please note that this doesn't mean root port is broken). Since Tegra194 has only Synopsys DesignWare core based host controllers and not any other hosts, I think it is fine to call this API in driver. Also, since this is a global setting, calling this APIs from anywhere (be it from quirk or from driver) would have the same effect, or did I miss anything here?
[PATCH] tty: serial: uartlite: avoid null pointer dereference during rmmod
After commit 415b43bdb008 "tty: serial: uartlite: Move uart register to
probe", calling uart_unregister_driver unconditionally will trigger a
null pointer dereference due to ulite_uart_driver may not registed.
CPU: 1 PID: 3755 Comm: syz-executor.0 Not tainted 5.1.0+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xa9/0x10e lib/dump_stack.c:113
__kasan_report+0x171/0x18d mm/kasan/report.c:321
kasan_report+0xe/0x20 mm/kasan/common.c:614
tty_unregister_driver+0x19/0x100 drivers/tty/tty_io.c:3383
uart_unregister_driver+0x30/0xc0 drivers/tty/serial/serial_core.c:2579
__do_sys_delete_module kernel/module.c:1027 [inline]
__se_sys_delete_module kernel/module.c:970 [inline]
__x64_sys_delete_module+0x244/0x330 kernel/module.c:970
do_syscall_64+0x72/0x2a0 arch/x86/entry/common.c:298
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Call uart_unregister_driver only if ulite_uart_driver.state not null to
fix it.
Cc: Peter Korsgaard
Cc: Shubhrajyoti Datta
Cc: Greg Kroah-Hartman
Reported-by: Hulk Robot
Fixes: 415b43bdb008 ("tty: serial: uartlite: Move uart register to probe")
Signed-off-by: Kefeng Wang
---
drivers/tty/serial/uartlite.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c
index b8b912b5a8b9..06e79c11141d 100644
--- a/drivers/tty/serial/uartlite.c
+++ b/drivers/tty/serial/uartlite.c
@@ -897,7 +897,8 @@ static int __init ulite_init(void)
static void __exit ulite_exit(void)
{
platform_driver_unregister(_platform_driver);
- uart_unregister_driver(_uart_driver);
+ if (ulite_uart_driver.state)
+ uart_unregister_driver(_uart_driver);
}
module_init(ulite_init);
--
2.20.1
Re: [PATCH] kbuild: terminate Kconfig when $(CC) or $(LD) is missing
On Mon, May 13, 2019 at 1:47 PM Nathan Chancellor
wrote:
>
> On Thu, May 09, 2019 at 04:35:55PM +0900, Masahiro Yamada wrote:
> > If the compiler specified by $(CC) is not present, the Kconfig stage
> > sprinkles 'not found' messages, then succeeds.
> >
> > $ make CROSS_COMPILE=foo defconfig
> > /bin/sh: 1: foogcc: not found
> > /bin/sh: 1: foogcc: not found
> > *** Default configuration is based on 'x86_64_defconfig'
> > ./scripts/gcc-version.sh: 17: ./scripts/gcc-version.sh: foogcc: not found
> > ./scripts/gcc-version.sh: 18: ./scripts/gcc-version.sh: foogcc: not found
> > ./scripts/gcc-version.sh: 19: ./scripts/gcc-version.sh: foogcc: not found
> > ./scripts/gcc-version.sh: 17: ./scripts/gcc-version.sh: foogcc: not found
> > ./scripts/gcc-version.sh: 18: ./scripts/gcc-version.sh: foogcc: not found
> > ./scripts/gcc-version.sh: 19: ./scripts/gcc-version.sh: foogcc: not found
> > ./scripts/clang-version.sh: 11: ./scripts/clang-version.sh: foogcc: not
> > found
> > ./scripts/gcc-plugin.sh: 11: ./scripts/gcc-plugin.sh: foogcc: not found
> > init/Kconfig:16:warning: 'GCC_VERSION': number is invalid
> > #
> > # configuration written to .config
> > #
> >
> > Terminate parsing files immediately if $(CC) or $(LD) is not found.
> > "make *config" will fail more nicely.
> >
> > $ make CROSS_COMPILE=foo defconfig
> > *** Default configuration is based on 'x86_64_defconfig'
> > scripts/Kconfig.include:34: compiler 'foogcc' not found
> > make[1]: *** [scripts/kconfig/Makefile;82: defconfig] Error 1
> > make: *** [Makefile;557: defconfig] Error 2
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > Makefile| 2 +-
> > scripts/Kconfig.include | 8
> > 2 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 28965187c528..bd7ae11947cb 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -537,7 +537,7 @@ endif
> > # Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
> > # CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
> > # and from include/config/auto.conf.cmd to detect the compiler upgrade.
> > -CC_VERSION_TEXT = $(shell $(CC) --version | head -n 1)
> > +CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1)
> >
> > ifeq ($(config-targets),1)
> > #
> > ===
> > diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> > index 87ff1dcc6bd5..0b267fb27f07 100644
> > --- a/scripts/Kconfig.include
> > +++ b/scripts/Kconfig.include
> > @@ -18,6 +18,10 @@ if-success = $(shell,{ $(1); } >/dev/null 2>&1 && echo
> > "$(2)" || echo "$(3)")
> > # Return y if exits with 0, n otherwise
> > success = $(if-success,$(1),y,n)
> >
> > +# $(failure,)
> > +# Return n if exits with 0, y otherwise
> > +failure = $(if-success,$(1),n,y)
> > +
> > # $(cc-option,)
> > # Return y if the compiler supports , n otherwise
> > cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null)
> > @@ -26,5 +30,9 @@ cc-option = $(success,$(CC) -Werror $(1) -E -x c
> > /dev/null -o /dev/null)
> > # Return y if the linker supports , n otherwise
> > ld-option = $(success,$(LD) -v $(1))
> >
> > +# check if $(CC) and $(LD) exist
> > +$(error-if,$(failure,command -v $(CC)),compiler '$(CC)' not found)
> > +$(error-if,$(failure,command -v $(LD)),linker '$(LD)' not found)
>
> As mentioned in the other thread, $(AS) should be checked as well since
> it's possible that neither $(CC) nor $(LD) will involve $(CROSS_COMPILE),
> like the combination of clang + ld.lld, whereas $(AS) will (currently)
> always involve $(CROSS_COMPILE).
Indeed.
This patch cannot check the presence of the intended gnu toolchains
if CC=clang LD=ld.lld
The reason for $(CC) / $(LD) checks in Kconfig
is because it evaluates some $(cc-option, ...) and $(ld-option, ...) calls.
Currently, Kconfig does not have as-option, but I will add it
sooner or later, so I am fine with adding
$(error-if,$(failure,command -v $(AS)),assembler '$(AS)' not found)
> > +
> > # gcc version including patch level
> > gcc-version := $(shell,$(srctree)/scripts/gcc-version.sh $(CC))
> > --
> > 2.17.1
> >
--
Best Regards
Masahiro Yamada
ERROR: "uio_unregister_device" [drivers/staging/kpc2000/kpc2000/kpc2000.ko] undefined!
Hi Greg, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 63863ee8e2f6f6ae47be3dff4af2f2806f5ca2dd commit: 91b6cb7216cd8bad027bc9ef88e2834786c8eeaf staging: kpc2000: fix up build problems with readq() date: 13 days ago config: i386-randconfig-k1-05131404 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout 91b6cb7216cd8bad027bc9ef88e2834786c8eeaf # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> ERROR: "uio_unregister_device" [drivers/staging/kpc2000/kpc2000/kpc2000.ko] >> undefined! >> ERROR: "__uio_register_device" [drivers/staging/kpc2000/kpc2000/kpc2000.ko] >> undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v12 3/3] dt-bindings: mfd: Document Renesas R-Car Gen3 RPC-IF MFD bindings
Hi Geert, > Subject > > Re: [PATCH v12 3/3] dt-bindings: mfd: Document Renesas R-Car Gen3 RPC-IF MFD bindings > > Hi Mason, > > Note that if you send multipart/text+html emails, they will be dropped silently > by most Linux mailing lists. > Hence I'm quoting your last email fully, to give other people a chance > reading it (and commenting). Thanks for your remind ! I have configured my Lotus Notes to plain text mode only and it should be OK for Linux mailing lists now. thanks & best regards, Mason CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. = CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =
[PATCH 2/2] scsi: libsas: delete sas port if expander discover failed
The sas_port(phy->port) allocated in sas_ex_discover_expander() will not
be deleted when the expander failed to discover. This will cause
resource leak and a further issue of kernel BUG like below:
[159785.843156] port-2:17:29: trying to add phy phy-2:17:29 fails: it's
already part of another port
[159785.852144] [ cut here ]
[159785.856833] kernel BUG at drivers/scsi/scsi_transport_sas.c:1086!
[159785.863000] Internal error: Oops - BUG: 0 [#1] SMP
[159785.867866] CPU: 39 PID: 16993 Comm: kworker/u96:2 Tainted: G
W OE 4.19.25-vhulk1901.1.0.h111.aarch64 #1
[159785.878458] Hardware name: Huawei Technologies Co., Ltd.
Hi1620EVBCS/Hi1620EVBCS, BIOS Hi1620 CS B070 1P TA 03/21/2019
[159785.889231] Workqueue: :74:02.0_disco_q sas_discover_domain
[159785.895224] pstate: 40c9 (nZcv daif +PAN +UAO)
[159785.900094] pc : sas_port_add_phy+0x188/0x1b8
[159785.904524] lr : sas_port_add_phy+0x188/0x1b8
[159785.908952] sp : 0001120e3b80
[159785.912341] x29: 0001120e3b80 x28:
[159785.917727] x27: 802ade8f5400 x26: 681b7560
[159785.923111] x25: 802adf11a800 x24: 680e8000
[159785.928496] x23: 802ade8f5728 x22: 802ade8f5708
[159785.933880] x21: 802adea2db40 x20: 802ade8f5400
[159785.939264] x19: 802adea2d800 x18: 0010
[159785.944649] x17: 821bf734 x16: 6714faa0
[159785.950033] x15: e8ab4ecf x14: 7261702079646165
[159785.955417] x13: 726c612073277469 x12: 6887b830
[159785.960802] x11: 6773eaa0 x10: 7968702079687020
[159785.966186] x9 : 2453 x8 : 726f702072656874
[159785.971570] x7 : 6f6e6120666f2074 x6 : 802bcfb21290
[159785.976955] x5 : 802bcfb21290 x4 :
[159785.982339] x3 : 802bcfb298c8 x2 : 337752b234c2ab00
[159785.987723] x1 : 337752b234c2ab00 x0 :
[159785.993108] Process kworker/u96:2 (pid: 16993, stack limit =
0x72dae094)
[159786.000576] Call trace:
[159786.003097] sas_port_add_phy+0x188/0x1b8
[159786.007179] sas_ex_get_linkrate.isra.5+0x134/0x140
[159786.012130] sas_ex_discover_expander+0x128/0x408
[159786.016906] sas_ex_discover_dev+0x218/0x4c8
[159786.021249] sas_ex_discover_devices+0x9c/0x1a8
[159786.025852] sas_discover_root_expander+0x134/0x160
[159786.030802] sas_discover_domain+0x1b8/0x1e8
[159786.035148] process_one_work+0x1b4/0x3f8
[159786.039230] worker_thread+0x54/0x470
[159786.042967] kthread+0x134/0x138
[159786.046269] ret_from_fork+0x10/0x18
[159786.049918] Code: 91322300 f0004402 91178042 97fe4c9b (d421)
[159786.056083] Modules linked in: hns3_enet_ut(OE) hclge(OE) hnae3(OE)
hisi_sas_test_hw(OE) hisi_sas_test_main(OE) serdes(OE)
[159786.067202] ---[ end trace 03622b9e2d99e196 ]---
[159786.071893] Kernel panic - not syncing: Fatal exception
[159786.077190] SMP: stopping secondary CPUs
[159786.081192] Kernel Offset: disabled
[159786.084753] CPU features: 0x2,a2a00a38
Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
Reported-by: Jian Luo
Signed-off-by: Jason Yan
CC: John Garry
---
drivers/scsi/libsas/sas_expander.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/libsas/sas_expander.c
b/drivers/scsi/libsas/sas_expander.c
index 83f2fd70ce76..9f7e2457360e 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -1019,6 +1019,8 @@ static struct domain_device *sas_ex_discover_expander(
list_del(>dev_list_node);
spin_unlock_irq(>port->dev_list_lock);
sas_put_device(child);
+ sas_port_delete(phy->port);
+ phy->port = NULL;
return NULL;
}
list_add_tail(>siblings, >ex_dev.children);
--
2.17.2
Re: [PATCH] vsprintf: Do not break early boot with probing addresses
On (05/14/19 11:07), Sergey Senozhatsky wrote: > How about this: > > if ptr < PAGE_SIZE -> "(null)" No, this is totally stupid. Forget about it. Sorry. > if IS_ERR_VALUE(ptr)-> "(fault)" But Steven's "(fault)" is nice. -ss
[PATCH 1/2] scsi: libsas: only clear phy->in_shutdown after shutdown event done
When the event queue is full of phy up and down events and reached the
threshold, we will queue a shutdown-event, and set phy->in_shutdown so
that we will not queue a shutdown-event again. But before the
shutdown-event can be executed, every phy-down event will clear
phy->in_shutdown and a new shutdown-event will be queued. The queue will
be full of these shutdown-events.
Fix this by only clear phy->in_shutdown in sas_phye_shutdown(), that is
after the first shutdown-event has been executed.
Fixes: f12486e06ae8 ("scsi: libsas: shut down the PHY if events reached the
threshold")
Signed-off-by: Jason Yan
CC: John Garry
CC: Johannes Thumshirn
CC: Ewan Milne
CC: Christoph Hellwig
CC: Tomas Henzl
CC: Dan Williams
CC: Hannes Reinecke
Reviewed-by: John Garry
---
drivers/scsi/libsas/sas_phy.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/libsas/sas_phy.c b/drivers/scsi/libsas/sas_phy.c
index e030e1452136..b71f5ac6c7dc 100644
--- a/drivers/scsi/libsas/sas_phy.c
+++ b/drivers/scsi/libsas/sas_phy.c
@@ -35,7 +35,6 @@ static void sas_phye_loss_of_signal(struct work_struct *work)
struct asd_sas_event *ev = to_asd_sas_event(work);
struct asd_sas_phy *phy = ev->phy;
- phy->in_shutdown = 0;
phy->error = 0;
sas_deform_port(phy, 1);
}
@@ -45,7 +44,6 @@ static void sas_phye_oob_done(struct work_struct *work)
struct asd_sas_event *ev = to_asd_sas_event(work);
struct asd_sas_phy *phy = ev->phy;
- phy->in_shutdown = 0;
phy->error = 0;
}
@@ -126,6 +124,7 @@ static void sas_phye_shutdown(struct work_struct *work)
ret);
} else
pr_notice("phy%d is not enabled, cannot shutdown\n", phy->id);
+ phy->in_shutdown = 0;
}
/* -- Phy class registration -- */
--
2.17.2
Re: [PATCH v1] mtd: rawnand: Add Macronix NAND read retry support
Hi Miquel,
> > > > > > +
> > > > > > + if (mxic->reliability_func & MACRONIX_READ_RETRY_BIT) {
> > > > > > + chip->read_retries = MACRONIX_READ_RETRY_MODE + 1;
> > > > >
> > > > > Why +1 here, I am missing something?
> > > >
> > > >
> > > > Without + 1, read retry mode is up to 4 rather than 5.
> > > > But this NAND device support read retry mode up to 5.
> > > >
> > >
> > > If there are 5 modes, you need to set 5 to chip->read_retries, not
6.
> > >
> > > If only 4 modes are used, there is probably a bug in the core that
> > > must be fixed, please do not workaround it in the driver!
> >
> >
> > It seems some patches is needed in nand_base.c
> >
-
> > diff --git a/drivers/mtd/nand/raw/nand_base.c
> > b/drivers/mtd/nand/raw/nand_base.c
> > index ddd396e..56be3a9 100644
> > --- a/drivers/mtd/nand/raw/nand_base.c
> > +++ b/drivers/mtd/nand/raw/nand_base.c
> > @@ -3101,7 +3101,8 @@ static int nand_setup_read_retry(struct
nand_chip
> > *chip, int retry_mode)
> > {
> > pr_debug("setting READ RETRY mode %d\n", retry_mode);
> >
> > - if (retry_mode >= chip->read_retries)
> > + if (retry_mode > chip->read_retries)
>
> If I understand correctly, chip->read_retries is the total number of
> 'modes' so the last valid mode is indeed chip->read_retries -1.
>
> I thought the problem would come from the core but I was wrong, you
> actually need a MACRONIX_NUM_READ_RETRY_MODES set to 6. Please have two
> defines if you need both (the first one being something like
> MACRONIX_MAXIMUM_READ_RETRY_MODE set to 5).
I have checked one of Micron's datasheet and it defined read-retry number
= 8,
mode 0 ~ 7, 0 mean to disable read-retry.
Therefore, I will patch MACRONIX_NUM_READ_RETRY_MODES = 6.
thanks & best regards,
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or
personal data, which is protected by applicable laws. Please be reminded that
duplication, disclosure, distribution, or use of this e-mail (and/or its
attachments) or any part thereof is prohibited. If you receive this e-mail in
error, please notify us immediately and delete this mail as well as its
attachment(s) from your system. In addition, please be informed that
collection, processing, and/or use of personal data is prohibited unless
expressly permitted by personal data protection laws. Thank you for your
attention and cooperation.
Macronix International Co., Ltd.
=
fs/ubifs/dir.c:799: undefined reference to `ubifs_purge_xattrs'
Hi Richard,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 63863ee8e2f6f6ae47be3dff4af2f2806f5ca2dd
commit: 9ca2d732644484488db31123ecd3bf122b551566 ubifs: Limit number of xattrs
per inode
date: 6 days ago
config: i386-randconfig-c0-05140716 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 9ca2d732644484488db31123ecd3bf122b551566
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
ld: fs/ubifs/dir.o: in function `ubifs_unlink':
>> fs/ubifs/dir.c:799: undefined reference to `ubifs_purge_xattrs'
ld: fs/ubifs/dir.o: in function `do_rename':
fs/ubifs/dir.c:1296: undefined reference to `ubifs_purge_xattrs'
ld: fs/ubifs/dir.o: in function `ubifs_rmdir':
fs/ubifs/dir.c:907: undefined reference to `ubifs_purge_xattrs'
vim +799 fs/ubifs/dir.c
773
774 static int ubifs_unlink(struct inode *dir, struct dentry *dentry)
775 {
776 struct ubifs_info *c = dir->i_sb->s_fs_info;
777 struct inode *inode = d_inode(dentry);
778 struct ubifs_inode *dir_ui = ubifs_inode(dir);
779 int err, sz_change, budgeted = 1;
780 struct ubifs_budget_req req = { .mod_dent = 1, .dirtied_ino = 2
};
781 unsigned int saved_nlink = inode->i_nlink;
782 struct fscrypt_name nm;
783
784 /*
785 * Budget request settings: deletion direntry, deletion inode
(+1 for
786 * @dirtied_ino), changing the parent directory inode. If
budgeting
787 * fails, go ahead anyway because we have extra space reserved
for
788 * deletions.
789 */
790
791 dbg_gen("dent '%pd' from ino %lu (nlink %d) in dir ino %lu",
792 dentry, inode->i_ino,
793 inode->i_nlink, dir->i_ino);
794
795 err = fscrypt_setup_filename(dir, >d_name, 1, );
796 if (err)
797 return err;
798
> 799 err = ubifs_purge_xattrs(inode);
800 if (err)
801 return err;
802
803 sz_change = CALC_DENT_SIZE(fname_len());
804
805 ubifs_assert(c, inode_is_locked(dir));
806 ubifs_assert(c, inode_is_locked(inode));
807 err = dbg_check_synced_i_size(c, inode);
808 if (err)
809 goto out_fname;
810
811 err = ubifs_budget_space(c, );
812 if (err) {
813 if (err != -ENOSPC)
814 goto out_fname;
815 budgeted = 0;
816 }
817
818 lock_2_inodes(dir, inode);
819 inode->i_ctime = current_time(dir);
820 drop_nlink(inode);
821 dir->i_size -= sz_change;
822 dir_ui->ui_size = dir->i_size;
823 dir->i_mtime = dir->i_ctime = inode->i_ctime;
824 err = ubifs_jnl_update(c, dir, , inode, 1, 0);
825 if (err)
826 goto out_cancel;
827 unlock_2_inodes(dir, inode);
828
829 if (budgeted)
830 ubifs_release_budget(c, );
831 else {
832 /* We've deleted something - clean the "no space" flags
*/
833 c->bi.nospace = c->bi.nospace_rp = 0;
834 smp_wmb();
835 }
836 fscrypt_free_filename();
837 return 0;
838
839 out_cancel:
840 dir->i_size += sz_change;
841 dir_ui->ui_size = dir->i_size;
842 set_nlink(inode, saved_nlink);
843 unlock_2_inodes(dir, inode);
844 if (budgeted)
845 ubifs_release_budget(c, );
846 out_fname:
847 fscrypt_free_filename();
848 return err;
849 }
850
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC KVM 00/27] KVM Address Space Isolation
On Mon, May 13, 2019 at 2:09 PM Liran Alon wrote: > > > > > On 13 May 2019, at 21:17, Andy Lutomirski wrote: > > > >> I expect that the KVM address space can eventually be expanded to include > >> the ioctl syscall entries. By doing so, and also adding the KVM page table > >> to the process userland page table (which should be safe to do because the > >> KVM address space doesn't have any secret), we could potentially handle the > >> KVM ioctl without having to switch to the kernel pagetable (thus > >> effectively > >> eliminating KPTI for KVM). Then the only overhead would be if a VM-Exit has > >> to be handled using the full kernel address space. > >> > > > > In the hopefully common case where a VM exits and then gets re-entered > > without needing to load full page tables, what code actually runs? > > I'm trying to understand when the optimization of not switching is > > actually useful. > > > > Allowing ioctl() without switching to kernel tables sounds... > > extremely complicated. It also makes the dubious assumption that user > > memory contains no secrets. > > Let me attempt to clarify what we were thinking when creating this patch > series: > > 1) It is never safe to execute one hyperthread inside guest while it’s > sibling hyperthread runs in a virtual address space which contains secrets of > host or other guests. > This is because we assume that using some speculative gadget (such as > half-Spectrev2 gadget), it will be possible to populate *some* CPU core > resource which could then be *somehow* leaked by the hyperthread running > inside guest. In case of L1TF, this would be data populated to the L1D cache. > > 2) Because of (1), every time a hyperthread runs inside host kernel, we must > make sure it’s sibling is not running inside guest. i.e. We must kick the > sibling hyperthread outside of guest using IPI. > > 3) From (2), we should have theoretically deduced that for every #VMExit, > there is a need to kick the sibling hyperthread also outside of guest until > the #VMExit is completed. Such a patch series was implemented at some point > but it had (obviously) significant performance hit. > > 4) The main goal of this patch series is to preserve (2), but to avoid the overhead specified in (3). > > The way this patch series achieves (4) is by observing that during the run of > a VM, most #VMExits can be handled rather quickly and locally inside KVM and > doesn’t need to reference any data that is not relevant to this VM or KVM > code. Therefore, if we will run these #VMExits in an isolated virtual address > space (i.e. KVM isolated address space), there is no need to kick the sibling > hyperthread from guest while these #VMExits handlers run. Thanks! This clarifies a lot of things. > The hope is that the very vast majority of #VMExit handlers will be able to > completely run without requiring to switch to full address space. Therefore, > avoiding the performance hit of (2). > However, for the very few #VMExits that does require to run in full kernel > address space, we must first kick the sibling hyperthread outside of guest > and only then switch to full kernel address space and only once all > hyperthreads return to KVM address space, then allow then to enter into guest. What exactly does "kick" mean in this context? It sounds like you're going to need to be able to kick sibling VMs from extremely atomic contexts like NMI and MCE.
Re: [PATCH] vsprintf: Do not break early boot with probing addresses
On (05/13/19 14:42), Petr Mladek wrote: > > The "(null)" is good enough by itself and already an established > > practice.. > > (efault) made more sense with the probe_kernel_read() that > checked wide range of addresses. Well, I still think that > it makes sense to distinguish a pure NULL. And it still > used also for IS_ERR_VALUE(). Wouldn't anything within first PAGE_SIZE bytes be reported as a NULL deref? char *p = (char *)(PAGE_SIZE - 2); *p = 'a'; gives kernel: BUG: kernel NULL pointer dereference, address = 0ffe kernel: #PF: supervisor-privileged write access from kernel code kernel: #PF: error_code(0x0002) - not-present page And I like Steven's "(fault)" idea. How about this: if ptr < PAGE_SIZE -> "(null)" if IS_ERR_VALUE(ptr)-> "(fault)" -ss
Re: [RFC KVM 24/27] kvm/isolation: KVM page fault handler
On Mon, May 13, 2019 at 2:26 PM Liran Alon wrote: > > > > > On 13 May 2019, at 18:15, Peter Zijlstra wrote: > > > > On Mon, May 13, 2019 at 04:38:32PM +0200, Alexandre Chartre wrote: > >> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c > >> index 46df4c6..317e105 100644 > >> --- a/arch/x86/mm/fault.c > >> +++ b/arch/x86/mm/fault.c > >> @@ -33,6 +33,10 @@ > >> #define CREATE_TRACE_POINTS > >> #include > >> > >> +bool (*kvm_page_fault_handler)(struct pt_regs *regs, unsigned long > >> error_code, > >> + unsigned long address); > >> +EXPORT_SYMBOL(kvm_page_fault_handler); > > > > NAK NAK NAK NAK > > > > This is one of the biggest anti-patterns around. > > I agree. > I think that mm should expose a mm_set_kvm_page_fault_handler() or something > (give it a better name). > Similar to how arch/x86/kernel/irq.c have > kvm_set_posted_intr_wakeup_handler(). > > -Liran > This sounds like a great use case for static_call(). PeterZ, do you suppose we could wire up static_call() with the module infrastructure to make it easy to do "static_call to such-and-such GPL module symbol if that symbol is in a loaded module, else nop"?
Re: ext3/ext4 filesystem corruption under post 5.1.0 kernels
Apologies, I had forgotten to got bisect - - hard origin/master I am still seeing the corruption leading to the invalid block error on 5.1.0+ kernels on both my machines. Arthur. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH 3/3] KVM: LAPIC: Optimize timer latency further
On Tue, 14 May 2019 at 03:54, Sean Christopherson
wrote:
>
> On Thu, May 09, 2019 at 07:29:21PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Advance lapic timer tries to hidden the hypervisor overhead between host
> > timer fires and the guest awares the timer is fired. However, it just hidden
> > the time between apic_timer_fn/handle_preemption_timer -> wait_lapic_expire,
> > instead of the real position of vmentry which is mentioned in the orignial
> > commit d0659d946be0 ("KVM: x86: add option to advance tscdeadline hrtimer
> > expiration"). There is 700+ cpu cycles between the end of wait_lapic_expire
> > and before world switch on my haswell desktop, it will be 2400+ cycles if
> > vmentry_l1d_flush is tuned to always.
> >
> > This patch tries to narrow the last gap, it measures the time between
> > the end of wait_lapic_expire and before world switch, we take this
> > time into consideration when busy waiting, otherwise, the guest still
> > awares the latency between wait_lapic_expire and world switch, we also
> > consider this when adaptively tuning the timer advancement. The patch
> > can reduce 50% latency (~1600+ cycles to ~800+ cycles on a haswell
> > desktop) for kvm-unit-tests/tscdeadline_latency when testing busy waits.
> >
> > Cc: Paolo Bonzini
> > Cc: Radim Krčmář
> > Cc: Sean Christopherson
> > Cc: Liran Alon
> > Signed-off-by: Wanpeng Li
> > ---
> > arch/x86/kvm/lapic.c | 23 +--
> > arch/x86/kvm/lapic.h | 8
> > arch/x86/kvm/vmx/vmx.c | 2 ++
> > 3 files changed, 31 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index e7a0660..01d3a87 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -1545,13 +1545,19 @@ void wait_lapic_expire(struct kvm_vcpu *vcpu)
> >
> > tsc_deadline = apic->lapic_timer.expired_tscdeadline;
> > apic->lapic_timer.expired_tscdeadline = 0;
> > - guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc());
> > + guest_tsc = kvm_read_l1_tsc(vcpu,
> > (apic->lapic_timer.measure_delay_done == 2) ?
> > + rdtsc() + apic->lapic_timer.vmentry_delay : rdtsc());
> > trace_kvm_wait_lapic_expire(vcpu->vcpu_id, guest_tsc - tsc_deadline);
> >
> > if (guest_tsc < tsc_deadline)
> > __wait_lapic_expire(vcpu, tsc_deadline - guest_tsc);
> >
> > adaptive_tune_timer_advancement(vcpu, guest_tsc, tsc_deadline);
> > +
> > + if (!apic->lapic_timer.measure_delay_done) {
> > + apic->lapic_timer.measure_delay_done = 1;
> > + apic->lapic_timer.vmentry_delay = rdtsc();
> > + }
> > }
> >
> > static void start_sw_tscdeadline(struct kvm_lapic *apic)
> > @@ -1837,6 +1843,18 @@ static void apic_manage_nmi_watchdog(struct
> > kvm_lapic *apic, u32 lvt0_val)
> > }
> > }
> >
> > +void kvm_lapic_measure_vmentry_delay(struct kvm_vcpu *vcpu)
> > +{
> > + struct kvm_timer *ktimer = >arch.apic->lapic_timer;
>
> This will #GP if the APIC is not in-kernel, i.e. @apic is NULL.
>
> > +
> > + if (ktimer->measure_delay_done == 1) {
> > + ktimer->vmentry_delay = rdtsc() -
> > + ktimer->vmentry_delay;
> > + ktimer->measure_delay_done = 2;
>
> Measuring the delay a single time is bound to result in random outliers,
> e.g. if an NMI happens to occur after wait_lapic_expire().
>
> Rather than reinvent the wheel, can we simply move the call to
> wait_lapic_expire() into vmx.c and svm.c? For VMX we'd probably want to
> support the advancement if enable_unrestricted_guest=true so that we avoid
> the emulation_required case, but other than that I don't see anything that
> requires wait_lapic_expire() to be called where it is.
I also considered to move wait_lapic_expire() into vmx.c and svm.c
before, what do you think, Paolo, Radim?
Regards,
Wanpeng Li
>
> > + }
> > +}
> > +EXPORT_SYMBOL_GPL(kvm_lapic_measure_vmentry_delay);
> > +
> > int kvm_lapic_reg_write(struct kvm_lapic *apic, u32 reg, u32 val)
> > {
> > int ret = 0;
> > @@ -2318,7 +2336,8 @@ int kvm_create_lapic(struct kvm_vcpu *vcpu, int
> > timer_advance_ns)
> > apic->lapic_timer.timer_advance_ns = timer_advance_ns;
> > apic->lapic_timer.timer_advance_adjust_done = true;
> > }
> > -
> > + apic->lapic_timer.vmentry_delay = 0;
> > + apic->lapic_timer.measure_delay_done = 0;
> >
> > /*
> >* APIC is created enabled. This will prevent kvm_lapic_set_base from
> > diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
> > index d6d049b..f1d037b 100644
> > --- a/arch/x86/kvm/lapic.h
> > +++ b/arch/x86/kvm/lapic.h
> > @@ -35,6 +35,13 @@ struct kvm_timer {
> > atomic_t pending; /* accumulated triggered
> > timers */
> > bool hv_timer_in_use;
> > bool timer_advance_adjust_done;
> > + /**
> > + * 0 unstart measure
> > + * 1 start record
> > + * 2 get delta
> > + */
> > + u32
Re: [PATCH 2/2] pinctrl: mediatek: Update cur_mask in mask/mask ops
On Tue, May 14, 2019 at 6:29 AM Stephen Boyd wrote:
>
> Quoting Nicolas Boichat (2019-04-28 20:55:15)
> > During suspend/resume, mtk_eint_mask may be called while
> > wake_mask is active. For example, this happens if a wake-source
> > with an active interrupt handler wakes the system:
> > irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so
> > that it can be handled later on in the resume flow.
> >
> > However, this may happen before mtk_eint_do_resume is called:
> > in this case, wake_mask is loaded, and cur_mask is restored
> > from an older copy, re-enabling the interrupt, and causing
> > an interrupt storm (especially for level interrupts).
> >
> > Instead, we just record mask/unmask changes in cur_mask. This
> > also avoids the need to read the current mask in eint_do_suspend,
> > and we can remove mtk_eint_chip_read_mask function.
> >
> > Signed-off-by: Nicolas Boichat
>
> It looks an awful lot like you should just use IRQCHIP_MASK_ON_SUSPEND
> here. Isn't that what's happening? All non-wake irqs should be masked at
> the hardware level so they can't cause a wakeup during suspend and on
> resume they can be unmasked?
No, this is for an line that has both wake and interrupt enabled. To
reword the commit message above:
1. cur_mask[irq] = 1; wake_mask[irq] = 1; EINT_EN[irq] = 1 (interrupt
enabled at hardware level)
2. System suspends, resumes due to that line (at this stage EINT_HW
== wake_mask)
3. irq_pm_check_wakeup is called, and disables the interrupt =>
EINT_EN[irq] = 0, but we still have cur_mask[irq] = 1
4. mtk_eint_do_resume is called, and restores EINT_EN = cur_mask, so
it reenables EINT_EN[irq] = 1 => interrupt storm.
This patch fixes the issue in step 3. So that the interrupt can be
re-enabled properly later on, sometimes after mtk_eint_do_resume, when
the driver is ready to handle it.
Also, IRQCHIP_MASK_ON_SUSPEND does not handle lines that are enabled
as a wake source, but without interrupt enabled (e.g. cros_ec driver
does that), which we do want to support.
> > diff --git a/drivers/pinctrl/mediatek/mtk-eint.c
> > b/drivers/pinctrl/mediatek/mtk-eint.c
> > index 737385e86beb807..7e526bcf5e0b55c 100644
> > --- a/drivers/pinctrl/mediatek/mtk-eint.c
> > +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> > @@ -113,6 +113,8 @@ static void mtk_eint_mask(struct irq_data *d)
> > void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq,
> > eint->regs->mask_set);
> >
> > + eint->cur_mask[d->hwirq >> 5] &= ~mask;
> > +
> > writel(mask, reg);
> > }
> >
> > @@ -123,6 +125,8 @@ static void mtk_eint_unmask(struct irq_data *d)
> > void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq,
> > eint->regs->mask_clr);
> >
> > + eint->cur_mask[d->hwirq >> 5] |= mask;
> > +
> > writel(mask, reg);
> >
> > if (eint->dual_edge[d->hwirq])
> > @@ -384,7 +375,6 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
> >
> > int mtk_eint_do_suspend(struct mtk_eint *eint)
> > {
> > - mtk_eint_chip_read_mask(eint, eint->base, eint->cur_mask);
> > mtk_eint_chip_write_mask(eint, eint->base, eint->wake_mask);
> >
>
>
> This alone looks like, write out the mask to only allow wake interrupts.
Yes, and enable wake interrupts that may not be in cur_mask.
RE: [Patch (resend) 5/5] cifs: Call MID callback before destroying transport
>>>-Original Message-
>>>From: Pavel Shilovsky
>>>Sent: Thursday, May 9, 2019 11:01 AM
>>>To: Long Li
>>>Cc: Steve French ; linux-cifs >>c...@vger.kernel.org>; samba-technical ;
>>>Kernel Mailing List
>>>Subject: Re: [Patch (resend) 5/5] cifs: Call MID callback before destroying
>>>transport
>>>
>>>пт, 5 апр. 2019 г. в 14:39, Long Li :
From: Long Li
When transport is being destroyed, it's possible that some processes
may hold memory registrations that need to be deregistred.
Call them first so nobody is using transport resources, and it can be
destroyed.
Signed-off-by: Long Li
---
fs/cifs/connect.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index
33e4d98..084756cf 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -528,22 +528,6 @@ cifs_reconnect(struct TCP_Server_Info *server)
/* do not want to be sending data on a socket we are freeing */
cifs_dbg(FYI, "%s: tearing down socket\n", __func__);
mutex_lock(>srv_mutex);
- if (server->ssocket) {
- cifs_dbg(FYI, "State: 0x%x Flags: 0x%lx\n",
-server->ssocket->state, server->ssocket->flags);
- kernel_sock_shutdown(server->ssocket, SHUT_WR);
- cifs_dbg(FYI, "Post shutdown state: 0x%x Flags: 0x%lx\n",
-server->ssocket->state, server->ssocket->flags);
- sock_release(server->ssocket);
- server->ssocket = NULL;
- } else if (cifs_rdma_enabled(server))
- smbd_destroy(server);
- server->sequence_number = 0;
- server->session_estab = false;
- kfree(server->session_key.response);
- server->session_key.response = NULL;
- server->session_key.len = 0;
- server->lstrp = jiffies;
/* mark submitted MIDs for retry and issue callback */
INIT_LIST_HEAD(_list);
@@ -556,7 +540,6 @@ cifs_reconnect(struct TCP_Server_Info *server)
list_move(_entry->qhead, _list);
}
spin_unlock(_Lock);
- mutex_unlock(>srv_mutex);
cifs_dbg(FYI, "%s: issuing mid callbacks\n", __func__);
list_for_each_safe(tmp, tmp2, _list) { @@ -565,6 +548,25
@@ cifs_reconnect(struct TCP_Server_Info *server)
mid_entry->callback(mid_entry);
}
>>>
>>>The original call was issuing callbacks without holding srv_mutex - callbacks
>>>may take this mutex for its internal needs. With the proposed patch the
>>>code will deadlock.
>>>
>>>Also the idea of destroying the socket first is to allow possible retries
>>>(from
>>>callbacks) to return a proper error instead of trying to send anything
>>>through
>>>the reconnecting socket.
I will send a patch to revert this and follow your suggestion on putting
smbd_destroy() to after all MIDs have been called. Your suggestion tested well.
Thanks
Long
>>>
+ if (server->ssocket) {
+ cifs_dbg(FYI, "State: 0x%x Flags: 0x%lx\n",
+server->ssocket->state, server->ssocket->flags);
+ kernel_sock_shutdown(server->ssocket, SHUT_WR);
+ cifs_dbg(FYI, "Post shutdown state: 0x%x Flags: 0x%lx\n",
+server->ssocket->state, server->ssocket->flags);
+ sock_release(server->ssocket);
+ server->ssocket = NULL;
+ } else if (cifs_rdma_enabled(server))
+ smbd_destroy(server);
>>>
>>>If we need to call smbd_destroy() *after* callbacks, let's just move it alone
>>>without the rest of the code.
>>>
>>>
+ server->sequence_number = 0;
+ server->session_estab = false;
+ kfree(server->session_key.response);
+ server->session_key.response = NULL;
+ server->session_key.len = 0;
+ server->lstrp = jiffies;
+
+ mutex_unlock(>srv_mutex);
+
do {
try_to_freeze();
--
2.7.4
>>>
>>>
>>>--
>>>Best regards,
>>>Pavel Shilovsky
Re: [PATCH 01/17] locking/lockdep: Add lock type enum to explicitly specify read or write locks
Thanks for review. On Mon, 13 May 2019 at 19:45, Peter Zijlstra wrote: > > On Mon, May 13, 2019 at 05:11:47PM +0800, Yuyang Du wrote: > > + * Note that we have an assumption that a lock class cannot ever be both > > + * read and recursive-read. > > We have such locks in the kernel... see: > > kernel/qrwlock.c:queued_read_lock_slowpath() > > And yes, that is somewhat unfortunate, but hard to get rid of due to > hysterical raisins. That is ok, then LOCK_TYPE_RECURSIVE has to be 3 such that LOCK_TYPE_RECURSIVE & LOCK_TYPE_READ != 0. I thought to do this in the first place without assuming. Anyway, it is better to know. And I guess in a task: (1) read(X); recursive_read(x); /* this is ok ? */ (2) recursive_read(x); read(x) /* not ok ? */ Either way, very small change may need to be made.
Re: linux-next: build failure after merge of the ecryptfs tree
Stephen,
I wasn't aware of the other asix module when submitting the phy driver.
The phy module gets autoloaded based on the PHY ID, so there's no reason
why it couldn't be renamed.
May I suggest ax88796b for the new module name?
Cheers,
Michael
On 14/05/19 12:56 PM, Stephen Rothwell wrote:
Hi all,
[excessive quoting for new CC's]
On Tue, 14 May 2019 09:40:53 +0900 Masahiro Yamada
wrote:
On Tue, May 14, 2019 at 9:16 AM Stephen Rothwell wrote:
I don't know why this suddenly appeared after mergeing the ecryptfs tree
since nothin has changed in that tree for some time (and nothing in that
tree seems relevant).
After merging the ecryptfs tree, today's linux-next build (x86_64
allmodconfig) failed like this:
scripts/Makefile.modpost:112: target '.tmp_versions/asix.mod' doesn't match the
target pattern
scripts/Makefile.modpost:113: warning: overriding recipe for target
'.tmp_versions/asix.mod'
scripts/Makefile.modpost:100: warning: ignoring old recipe for target
'.tmp_versions/asix.mod'
scripts/Makefile.modpost:127: target '.tmp_versions/asix.mod' doesn't match the
target pattern
scripts/Makefile.modpost:128: warning: overriding recipe for target
'.tmp_versions/asix.mod'
scripts/Makefile.modpost:113: warning: ignoring old recipe for target
'.tmp_versions/asix.mod'
make[2]: Circular .tmp_versions/asix.mod <- __modpost dependency dropped.
Binary file .tmp_versions/asix.mod matches: No such file or directory
make[2]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
make[1]: *** [Makefile:1290: modules] Error 2
The only clue I can see is that asix.o gets built in two separate
directories (drivers/net/{phy,usb}).
Module name should be unique.
If both are compiled as a module,
they have the same module names:
drivers/net/phy/asix.ko
drivers/net/usb/asix.ko
If you see .tmp_version directory,
you will see asix.mod
Perhaps, one overwrote the other,
or it already got broken somehow.
So, the latter of these drivers (drivers/net/phy/asix.c) was added in
v4.18-rc1 by commit
31dd83b96641 ("net-next: phy: new Asix Electronics PHY driver")
If we can't have 2 modules with the same base name, is it too late to
change its name?
I am sort of suprised that noone else has hit this in the past year.
I have the following files in the object directory:
./.tmp_versions/asix.mod
./drivers/net/usb/asix.ko
./drivers/net/usb/asix.mod.o
./drivers/net/usb/asix.o
./drivers/net/usb/asix_common.o
./drivers/net/usb/asix_devices.o
./drivers/net/usb/.asix.ko.cmd
./drivers/net/usb/.asix.mod.o.cmd
./drivers/net/usb/.asix.o.cmd
./drivers/net/usb/asix.mod.c
./drivers/net/usb/.asix_common.o.cmd
./drivers/net/usb/.asix_devices.o.cmd
./drivers/net/phy/asix.ko
./drivers/net/phy/asix.o
./drivers/net/phy/.asix.ko.cmd
./drivers/net/phy/.asix.mod.o.cmd
./drivers/net/phy/asix.mod.o
./drivers/net/phy/asix.mod.c
./drivers/net/phy/.asix.o.cmd
./.tmp_versions/asix.mod
Looks like this:
--
drivers/net/phy/asix.ko
drivers/net/phy/asix.o
--
What you can't see above are the 256 NUL bytes at the end of the file
(followed by a NL).
This is from a -j 80 build. Surely there is a race condition here if the
file in .tmp_versions is only named for the base name of the module and
we have 2 modules with the same base name.
I removed that file and redid the build and it succeeded.
Mind you, I have no itdea why this file was begin rebuilt, the merge
only touched these files:
fs/ecryptfs/crypto.c
fs/ecryptfs/keystore.c
Puzzled ... :-(
Re: [v2 PATCH] RISC-V: Add a PE/COFF compliant Image header.
On 5/13/19 5:40 PM, Paul Walmsley wrote:
On Mon, 13 May 2019, Atish Patra wrote:
On 5/13/19 5:09 PM, Paul Walmsley wrote:
What are the semantics of those reserved fields?
+struct riscv_image_header {
+ u32 code0;
+ u32 code1;
+ u64 text_offset;
+ u64 image_size;
+ u64 res1;
+ u64 res2;
+ u64 res3;
+ u64 magic;
+ u32 res4; ---> We can use this for versioning when required
+ u32 res5; ---> This is reserved for PE/COFF header
+};
I saw that in your patch. The problem is that this doesn't describe what
other software might expect in those fields. Can anything at all be
placed in those reserved fields?
Yes. The reserved fields can be used for anything that boot loaders and
Linux kernel can agree with each other. If you look at the ARM64, they
have "Informative flags" in place of res1.
Do we need to add it now or add it later when we actually need a version
number. My preference is to add it later based on requirement.
If it isn't added now, how would bootloaders know whether it was there or
not?
Here is the corresponding U-Boot Patch
https://patchwork.ozlabs.org/patch/1096087/
Currently, boot loader doesn't care about versioning. Since we are updating a
reserved field, offsets will not change. If a boot loader want to use the
versioning, it should be patched along with the kernel patch.
Any other boot loader that doesn't care about the version, it can continue to
do so without any change.
My idea is to enable the minimum required fields in this patch and keep
everything else as reserved so that it can be amended in future as required.
If those fields really are reserved for implementors to do whatever they
want with them, then that might be a reasonable approach. That seems
unlikely, however, since specification authors usually reserve the right
to use reserved fields for their own purposes in later versions.
Technically, we are just implementing the "DOS" header part of PE/COFF
format for now. It only mandates a magic string "MZ" at the top and a
32bit value at offset 0x3c tells us offset of PE/COFF header in image.
Anything in between is implementation specific.
For example, it will be updated to support EFI stub as described in the
commit text,
"In order to support EFI stub, code0 should be replaced with "MZ" magic
string and res5(at offset 0x3c) should point to the rest of the PE/COFF
header (which will be added during EFI support)."
Regards,
Atish
- Paul
Re: linux-next: build failure after merge of the ecryptfs tree
Hi Masahiro, Also, this: On Tue, 14 May 2019 09:40:53 +0900 Masahiro Yamada wrote: > > > Mind you, I have no itdea why this file was begin rebuilt, the merge > > only touched these files: > > > > fs/ecryptfs/crypto.c > > fs/ecryptfs/keystore.c Its a bit annoying that the module was even being looked at given nothing it files depend upon had been modified. -- Cheers, Stephen Rothwell pgpRl3IeTUyz2.pgp Description: OpenPGP digital signature
Re: [PATCH 1/3] KVM: LAPIC: Extract adaptive tune timer advancement logic
On Tue, 14 May 2019 at 03:39, Sean Christopherson
wrote:
>
> On Thu, May 09, 2019 at 07:29:19PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Extract adaptive tune timer advancement logic to a single function.
>
> Why?
Just because the function wait_lapic_expire() is too complex now.
Regards,
Wanpeng Li
>
> >
> > Cc: Paolo Bonzini
> > Cc: Radim Krčmář
> > Cc: Sean Christopherson
> > Cc: Liran Alon
> > Signed-off-by: Wanpeng Li
> > ---
> > arch/x86/kvm/lapic.c | 57
> > ++--
> > 1 file changed, 33 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index bd13fdd..e7a0660 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -1501,11 +1501,41 @@ static inline void __wait_lapic_expire(struct
> > kvm_vcpu *vcpu, u64 guest_cycles)
> > }
> > }
> >
> > -void wait_lapic_expire(struct kvm_vcpu *vcpu)
> > +static inline void adaptive_tune_timer_advancement(struct kvm_vcpu *vcpu,
> > + u64 guest_tsc, u64 tsc_deadline)
> > {
> > struct kvm_lapic *apic = vcpu->arch.apic;
> > u32 timer_advance_ns = apic->lapic_timer.timer_advance_ns;
> > - u64 guest_tsc, tsc_deadline, ns;
> > + u64 ns;
> > +
> > + if (!apic->lapic_timer.timer_advance_adjust_done) {
> > + /* too early */
> > + if (guest_tsc < tsc_deadline) {
> > + ns = (tsc_deadline - guest_tsc) * 100ULL;
> > + do_div(ns, vcpu->arch.virtual_tsc_khz);
> > + timer_advance_ns -= min((u32)ns,
> > + timer_advance_ns /
> > LAPIC_TIMER_ADVANCE_ADJUST_STEP);
> > + } else {
> > + /* too late */
> > + ns = (guest_tsc - tsc_deadline) * 100ULL;
> > + do_div(ns, vcpu->arch.virtual_tsc_khz);
> > + timer_advance_ns += min((u32)ns,
> > + timer_advance_ns /
> > LAPIC_TIMER_ADVANCE_ADJUST_STEP);
> > + }
> > + if (abs(guest_tsc - tsc_deadline) <
> > LAPIC_TIMER_ADVANCE_ADJUST_DONE)
> > + apic->lapic_timer.timer_advance_adjust_done =
> > true;
> > + if (unlikely(timer_advance_ns > 5000)) {
> > + timer_advance_ns = 0;
> > + apic->lapic_timer.timer_advance_adjust_done =
> > true;
> > + }
> > + apic->lapic_timer.timer_advance_ns = timer_advance_ns;
> > + }
>
> This whole block is indented too far.
>
> > +}
> > +
> > +void wait_lapic_expire(struct kvm_vcpu *vcpu)
> > +{
> > + struct kvm_lapic *apic = vcpu->arch.apic;
> > + u64 guest_tsc, tsc_deadline;
> >
> > if (apic->lapic_timer.expired_tscdeadline == 0)
> > return;
> > @@ -1521,28 +1551,7 @@ void wait_lapic_expire(struct kvm_vcpu *vcpu)
> > if (guest_tsc < tsc_deadline)
> > __wait_lapic_expire(vcpu, tsc_deadline - guest_tsc);
> >
> > - if (!apic->lapic_timer.timer_advance_adjust_done) {
> > - /* too early */
> > - if (guest_tsc < tsc_deadline) {
> > - ns = (tsc_deadline - guest_tsc) * 100ULL;
> > - do_div(ns, vcpu->arch.virtual_tsc_khz);
> > - timer_advance_ns -= min((u32)ns,
> > - timer_advance_ns /
> > LAPIC_TIMER_ADVANCE_ADJUST_STEP);
> > - } else {
> > - /* too late */
> > - ns = (guest_tsc - tsc_deadline) * 100ULL;
> > - do_div(ns, vcpu->arch.virtual_tsc_khz);
> > - timer_advance_ns += min((u32)ns,
> > - timer_advance_ns /
> > LAPIC_TIMER_ADVANCE_ADJUST_STEP);
> > - }
> > - if (abs(guest_tsc - tsc_deadline) <
> > LAPIC_TIMER_ADVANCE_ADJUST_DONE)
> > - apic->lapic_timer.timer_advance_adjust_done = true;
> > - if (unlikely(timer_advance_ns > 5000)) {
> > - timer_advance_ns = 0;
> > - apic->lapic_timer.timer_advance_adjust_done = true;
> > - }
> > - apic->lapic_timer.timer_advance_ns = timer_advance_ns;
> > - }
> > + adaptive_tune_timer_advancement(vcpu, guest_tsc, tsc_deadline);
> > }
> >
> > static void start_sw_tscdeadline(struct kvm_lapic *apic)
> > --
> > 2.7.4
> >
Re: linux-next: build failure after merge of the ecryptfs tree
Hi all,
[excessive quoting for new CC's]
On Tue, 14 May 2019 09:40:53 +0900 Masahiro Yamada
wrote:
>
> On Tue, May 14, 2019 at 9:16 AM Stephen Rothwell
> wrote:
> >
> > I don't know why this suddenly appeared after mergeing the ecryptfs tree
> > since nothin has changed in that tree for some time (and nothing in that
> > tree seems relevant).
> >
> > After merging the ecryptfs tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > scripts/Makefile.modpost:112: target '.tmp_versions/asix.mod' doesn't match
> > the target pattern
> > scripts/Makefile.modpost:113: warning: overriding recipe for target
> > '.tmp_versions/asix.mod'
> > scripts/Makefile.modpost:100: warning: ignoring old recipe for target
> > '.tmp_versions/asix.mod'
> > scripts/Makefile.modpost:127: target '.tmp_versions/asix.mod' doesn't match
> > the target pattern
> > scripts/Makefile.modpost:128: warning: overriding recipe for target
> > '.tmp_versions/asix.mod'
> > scripts/Makefile.modpost:113: warning: ignoring old recipe for target
> > '.tmp_versions/asix.mod'
> > make[2]: Circular .tmp_versions/asix.mod <- __modpost dependency dropped.
> > Binary file .tmp_versions/asix.mod matches: No such file or directory
> > make[2]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
> > make[1]: *** [Makefile:1290: modules] Error 2
> >
> > The only clue I can see is that asix.o gets built in two separate
> > directories (drivers/net/{phy,usb}).
>
> Module name should be unique.
>
> If both are compiled as a module,
> they have the same module names:
>
> drivers/net/phy/asix.ko
> drivers/net/usb/asix.ko
>
> If you see .tmp_version directory,
> you will see asix.mod
>
> Perhaps, one overwrote the other,
> or it already got broken somehow.
So, the latter of these drivers (drivers/net/phy/asix.c) was added in
v4.18-rc1 by commit
31dd83b96641 ("net-next: phy: new Asix Electronics PHY driver")
If we can't have 2 modules with the same base name, is it too late to
change its name?
I am sort of suprised that noone else has hit this in the past year.
> > I have the following files in the object directory:
> >
> > ./.tmp_versions/asix.mod
> > ./drivers/net/usb/asix.ko
> > ./drivers/net/usb/asix.mod.o
> > ./drivers/net/usb/asix.o
> > ./drivers/net/usb/asix_common.o
> > ./drivers/net/usb/asix_devices.o
> > ./drivers/net/usb/.asix.ko.cmd
> > ./drivers/net/usb/.asix.mod.o.cmd
> > ./drivers/net/usb/.asix.o.cmd
> > ./drivers/net/usb/asix.mod.c
> > ./drivers/net/usb/.asix_common.o.cmd
> > ./drivers/net/usb/.asix_devices.o.cmd
> > ./drivers/net/phy/asix.ko
> > ./drivers/net/phy/asix.o
> > ./drivers/net/phy/.asix.ko.cmd
> > ./drivers/net/phy/.asix.mod.o.cmd
> > ./drivers/net/phy/asix.mod.o
> > ./drivers/net/phy/asix.mod.c
> > ./drivers/net/phy/.asix.o.cmd
> >
> > ./.tmp_versions/asix.mod
> >
> > Looks like this:
> >
> > --
> > drivers/net/phy/asix.ko
> > drivers/net/phy/asix.o
> >
> >
> > --
> >
> > What you can't see above are the 256 NUL bytes at the end of the file
> > (followed by a NL).
> >
> > This is from a -j 80 build. Surely there is a race condition here if the
> > file in .tmp_versions is only named for the base name of the module and
> > we have 2 modules with the same base name.
> >
> > I removed that file and redid the build and it succeeded.
> >
> > Mind you, I have no itdea why this file was begin rebuilt, the merge
> > only touched these files:
> >
> > fs/ecryptfs/crypto.c
> > fs/ecryptfs/keystore.c
> >
> > Puzzled ... :-(
--
Cheers,
Stephen Rothwell
pgps02eN0Oqke.pgp
Description: OpenPGP digital signature
Re: [Proposal] end of file checks by checkpatch.pl
On Tue, May 14, 2019 at 9:01 AM Joe Perches wrote: > > On Tue, 2019-05-14 at 08:46 +0900, Masahiro Yamada wrote: > > So, I think these two checks can be done for > > all file types. > [] > > checkpatch.pl misses to report most of them. > > (the majority of the warning source is *.json) > > Perhaps the json files should be ignored as more than > half of the .json files in the tree are missing the > newline at EOF. I guess they are accident. I do not think missing newline in *.json is syntactically significant. If we are unsure, it is better to ask the maintainers. > And at least some of those json files use spaces for > indentation and not tabs. This is different stuff. Indentation and newline at EOF are not linked. -- Best Regards Masahiro Yamada
[PATCH] dt-bindings: gpio: Convert Arm PL061 to json-schema
Convert the Arm PL061 GPIO controller binding to json-schema format. As I'm the author for all but the gpio-ranges line, make the schema dual GPL/BSD license. Cc: Linus Walleij Cc: Bartosz Golaszewski Cc: linux-g...@vger.kernel.org Signed-off-by: Rob Herring --- This warns on a few platforms missing clocks, interrupt-controller and/or #interrupt-cells. We could not make those required, but really they should be IMO. OTOH, it's platforms like Spear and Calxeda which aren't too active, so I don't know that we want to fix them. .../devicetree/bindings/gpio/pl061-gpio.txt | 10 --- .../devicetree/bindings/gpio/pl061-gpio.yaml | 69 +++ 2 files changed, 69 insertions(+), 10 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/pl061-gpio.txt create mode 100644 Documentation/devicetree/bindings/gpio/pl061-gpio.yaml diff --git a/Documentation/devicetree/bindings/gpio/pl061-gpio.txt b/Documentation/devicetree/bindings/gpio/pl061-gpio.txt deleted file mode 100644 index 89058d375b7c.. --- a/Documentation/devicetree/bindings/gpio/pl061-gpio.txt +++ /dev/null @@ -1,10 +0,0 @@ -ARM PL061 GPIO controller - -Required properties: -- compatible : "arm,pl061", "arm,primecell" -- #gpio-cells : Should be two. The first cell is the pin number and the - second cell is used to specify optional parameters: - - bit 0 specifies polarity (0 for normal, 1 for inverted) -- gpio-controller : Marks the device node as a GPIO controller. -- interrupts : Interrupt mapping for GPIO IRQ. -- gpio-ranges : Interaction with the PINCTRL subsystem. diff --git a/Documentation/devicetree/bindings/gpio/pl061-gpio.yaml b/Documentation/devicetree/bindings/gpio/pl061-gpio.yaml new file mode 100644 index ..313b17229247 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/pl061-gpio.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/pl061-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM PL061 GPIO controller + +maintainers: + - Linus Walleij + - Rob Herring + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: +compatible: + contains: +const: arm,pl061 + required: +- compatible + +properties: + $nodename: +pattern: "^gpio@[0-9a-f]+$" + + compatible: +items: + - const: arm,pl061 + - const: arm,primecell + + reg: +maxItems: 1 + + interrupts: +oneOf: + - maxItems: 1 + - maxItems: 8 + + interrupt-controller: true + + "#interrupt-cells": +const: 2 + + clocks: +maxItems: 1 + + clock-names: true + + "#gpio-cells": +const: 2 + + gpio-controller: true + + gpio-ranges: +maxItems: 8 + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - "#interrupt-cells" + - clocks + - "#gpio-cells" + - gpio-controller + +additionalProperties: false + +... -- 2.20.1
Re: [stable/4.14.y PATCH 0/3] mmc: Fix a potential resource leak when shutting down request queue.
On Mon, May 13, 2019 at 11:55:18AM -0600, Raul E Rangel wrote: I think we should cherry-pick 41e3efd07d5a02c80f503e29d755aa1bbb4245de https://lore.kernel.org/patchwork/patch/856512/ into 4.14. It fixes a potential resource leak when shutting down the request queue. Once this patch is applied, there is a potential for a null pointer dereference. That's what the second patch fixes. The third patch is just an optimization to stop processing earlier. Is this actually part of a fix? Why do we want this optimization? -- Thanks, Sasha
Re: linux-next: build failure after merge of the ecryptfs tree
Hi Stephen,
On Tue, May 14, 2019 at 9:16 AM Stephen Rothwell wrote:
>
> Hi all,
>
> I don't know why this suddenly appeared after mergeing the ecryptfs tree
> since nothin has changed in that tree for some time (and nothing in that
> tree seems relevant).
>
> After merging the ecryptfs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> scripts/Makefile.modpost:112: target '.tmp_versions/asix.mod' doesn't match
> the target pattern
> scripts/Makefile.modpost:113: warning: overriding recipe for target
> '.tmp_versions/asix.mod'
> scripts/Makefile.modpost:100: warning: ignoring old recipe for target
> '.tmp_versions/asix.mod'
> scripts/Makefile.modpost:127: target '.tmp_versions/asix.mod' doesn't match
> the target pattern
> scripts/Makefile.modpost:128: warning: overriding recipe for target
> '.tmp_versions/asix.mod'
> scripts/Makefile.modpost:113: warning: ignoring old recipe for target
> '.tmp_versions/asix.mod'
> make[2]: Circular .tmp_versions/asix.mod <- __modpost dependency dropped.
> Binary file .tmp_versions/asix.mod matches: No such file or directory
> make[2]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
> make[1]: *** [Makefile:1290: modules] Error 2
>
> The only clue I can see is that asix.o gets built in two separate
> directories (drivers/net/{phy,usb}).
Module name should be unique.
If both are compiled as a module,
they have the same module names:
drivers/net/phy/asix.ko
drivers/net/usb/asix.ko
If you see .tmp_version directory,
you will see asix.mod
Perhaps, one overwrote the other,
or it already got broken somehow.
Thanks.
> I have the following files in the object directory:
>
> ./.tmp_versions/asix.mod
> ./drivers/net/usb/asix.ko
> ./drivers/net/usb/asix.mod.o
> ./drivers/net/usb/asix.o
> ./drivers/net/usb/asix_common.o
> ./drivers/net/usb/asix_devices.o
> ./drivers/net/usb/.asix.ko.cmd
> ./drivers/net/usb/.asix.mod.o.cmd
> ./drivers/net/usb/.asix.o.cmd
> ./drivers/net/usb/asix.mod.c
> ./drivers/net/usb/.asix_common.o.cmd
> ./drivers/net/usb/.asix_devices.o.cmd
> ./drivers/net/phy/asix.ko
> ./drivers/net/phy/asix.o
> ./drivers/net/phy/.asix.ko.cmd
> ./drivers/net/phy/.asix.mod.o.cmd
> ./drivers/net/phy/asix.mod.o
> ./drivers/net/phy/asix.mod.c
> ./drivers/net/phy/.asix.o.cmd
>
> ./.tmp_versions/asix.mod
>
> Looks like this:
>
> --
> drivers/net/phy/asix.ko
> drivers/net/phy/asix.o
>
>
> --
>
> What you can't see above are the 256 NUL bytes at the end of the file
> (followed by a NL).
>
> This is from a -j 80 build. Surely there is a race condition here if the
> file in .tmp_versions is only named for the base name of the module and
> we have 2 modules with the same base name.
>
> I removed that file and redid the build and it succeeded.
>
> Mind you, I have no itdea why this file was begin rebuilt, the merge
> only touched these files:
>
> fs/ecryptfs/crypto.c
> fs/ecryptfs/keystore.c
>
> Puzzled ... :-(
>
> --
> Cheers,
> Stephen Rothwell
--
Best Regards
Masahiro Yamada
Re: [v2 PATCH] RISC-V: Add a PE/COFF compliant Image header.
On Mon, 13 May 2019, Atish Patra wrote:
> On 5/13/19 5:09 PM, Paul Walmsley wrote:
>
> > What are the semantics of those reserved fields?
>
> +struct riscv_image_header {
> + u32 code0;
> + u32 code1;
> + u64 text_offset;
> + u64 image_size;
> + u64 res1;
> + u64 res2;
> + u64 res3;
> + u64 magic;
> + u32 res4; ---> We can use this for versioning when required
> + u32 res5; ---> This is reserved for PE/COFF header
> +};
I saw that in your patch. The problem is that this doesn't describe what
other software might expect in those fields. Can anything at all be
placed in those reserved fields?
> > > Do we need to add it now or add it later when we actually need a version
> > > number. My preference is to add it later based on requirement.
> >
> > If it isn't added now, how would bootloaders know whether it was there or
> > not?
> >
> >
> Here is the corresponding U-Boot Patch
> https://patchwork.ozlabs.org/patch/1096087/
>
> Currently, boot loader doesn't care about versioning. Since we are updating a
> reserved field, offsets will not change. If a boot loader want to use the
> versioning, it should be patched along with the kernel patch.
>
> Any other boot loader that doesn't care about the version, it can continue to
> do so without any change.
>
> My idea is to enable the minimum required fields in this patch and keep
> everything else as reserved so that it can be amended in future as required.
If those fields really are reserved for implementors to do whatever they
want with them, then that might be a reasonable approach. That seems
unlikely, however, since specification authors usually reserve the right
to use reserved fields for their own purposes in later versions.
- Paul
[PATCH] perf/x86/intel: allow PEBS multi-entry in watermark mode
This patch fixes an issue introduced with:
583feb08e7f7 ("perf/x86/intel: Fix handling of wakeup_events for multi-entry
PEBS")
The original patch prevented using multi-entry PEBS when wakeup_events != 0.
However given that wakeup_events is part of a union with wakeup_watermark, it
means that in watermark mode, PEBS multi-entry is also disabled which is not the
intent. This patch fixes this by checking is watermark mode is enabled.
Signed-off-by: Stephane Eranian
Change-Id: I8362bbcf9035c860b64b4c2e8faf310ebd74c234
---
arch/x86/events/intel/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 416233f92b3c..613fabba2c99 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3280,7 +3280,7 @@ static int intel_pmu_hw_config(struct perf_event *event)
return ret;
if (event->attr.precise_ip) {
- if (!(event->attr.freq || event->attr.wakeup_events)) {
+ if (!(event->attr.freq || (event->attr.wakeup_events &&
!event->attr.watermark))) {
event->hw.flags |= PERF_X86_EVENT_AUTO_RELOAD;
if (!(event->attr.sample_type &
~intel_pmu_large_pebs_flags(event)))
Re: [v2 PATCH] RISC-V: Add a PE/COFF compliant Image header.
On 5/13/19 5:09 PM, Paul Walmsley wrote:
On Mon, 13 May 2019, Atish Patra wrote:
On 5/13/19 3:31 PM, Paul Walmsley wrote:
On Wed, 1 May 2019, Atish Patra wrote:
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot flows.
Add a PE/COFF compliant image header that boot loaders can parse and
directly load kernel flat Image. The existing booting methods will
continue
to work as it is.
Another goal of this header is to support EFI stub for RISC-V in future.
EFI specification needs PE/COFF image header in the beginning of the
kernel
image in order to load it as an EFI application. In order to support
EFI stub, code0 should be replaced with "MZ" magic string and res5(at
offset 0x3c) should point to the rest of the PE/COFF header (which will
be added during EFI support).
Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
Signed-off-by: Atish Patra
Seems like we're stuck with this basic format for EFI, etc. Even though
we may be stuck with it, I think we should take the opportunity to add the
possibility to extending this header format by adding fields after the
basic PE/COFF header ends.
In particular, at the very least, I'd suggest adding a u32 after the
PE/COFF header ends, to represent a "RISC-V header format version number".
Then if we add more fields that follow the PE/COFF header -- for example,
to represent the RISC-V instruction set extensions that are required to
run this binary -- we can just bump that RISC-V-specific version number
field to indicate to bootloaders that there's more there.
That would be inventing our RISC-V specific header format. However, we
can always use the one of the reserved fields in proposed header (res4)
for this purpose.
What are the semantics of those reserved fields?
+struct riscv_image_header {
+ u32 code0;
+ u32 code1;
+ u64 text_offset;
+ u64 image_size;
+ u64 res1;
+ u64 res2;
+ u64 res3;
+ u64 magic;
+ u32 res4; ---> We can use this for versioning when required
+ u32 res5; ---> This is reserved for PE/COFF header
+};
Do we need to add it now or add it later when we actually need a version
number. My preference is to add it later based on requirement.
If it isn't added now, how would bootloaders know whether it was there or
not?
Here is the corresponding U-Boot Patch
https://patchwork.ozlabs.org/patch/1096087/
Currently, boot loader doesn't care about versioning. Since we are
updating a reserved field, offsets will not change. If a boot loader
want to use the versioning, it should be patched along with the kernel
patch.
Any other boot loader that doesn't care about the version, it can
continue to do so without any change.
My idea is to enable the minimum required fields in this patch and keep
everything else as reserved so that it can be amended in future as required.
Regards,
Atish
- Paul
Re: [PATCH] scsi: smartpqi: Reporting unhandled SCSI errors
>> When a HARDWARE_ERROR is triggered for asc=0x3e, the actual code is >> only considering the case where ascq=0x1. >> >> Following the http://www.t10.org/lists/asc-num.htm#ASC_3E >> specification, other values may occur like a timeout (ascq=0x2). >> >> This patch is about printing an error message when a non-handled >> message is received. This could help diagnose a possible >> miss-behavior of the controller and/or a missing implementation in >> the Linux Kernel. >> >> This patch keeps the exact same error handling but prints a message >> if an ascq != 1 income. >> >> Signed-off-by: Erwan Velu > Acked-by: Don Brace Applied to 5.2/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
[RFC Patch] perf_event: fix a cgroup switch warning
We have been consistently triggering the warning
WARN_ON_ONCE(cpuctx->cgrp) in perf_cgroup_switch() for a rather
long time, although we still have no clue on how to reproduce it.
Looking into the code, it seems the only possibility here is that
the process calling perf_event_open() with a cgroup target exits
before the process in the target cgroup exits but after it gains
CPU to run. This is because we use the atomic counter
perf_cgroup_events as an indication of whether cgroup perf event
has enabled or not, which is inaccurate, illustrated as below:
CPU 0 CPU 1
// open perf events with a cgroup
// target for all CPU's
perf_event_open():
account_event_cpu()
// perf_cgroup_events == 1
// Schedule in a process in the target cgroup
perf_cgroup_switch()
perf_event_release_kernel():
unaccount_event_cpu()
// perf_cgroup_events == 0
// schedule out
// but perf_cgroup_sched_out() is skipped
// cpuctx->cgrp left as non-NULL
// schedule in another process
perf_cgroup_switch() // WARN triggerred
The proposed fix is kinda ugly, as it adds a flag in each process to
indicate whether this process has to go through perf_cgroup_sched_out()
when perf_cgroup_events is false negative. The other possible fix is
to force a reschedule on each target CPU before decreasing the counter
perf_cgroup_events, but this is expensive.
Suggestions? Thoughts?
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Signed-off-by: Cong Wang
---
include/linux/sched.h | 3 +++
kernel/events/core.c | 5 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a2cd15855bad..835bdf15f92c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -733,6 +733,9 @@ struct task_struct {
/* to be used once the psi infrastructure lands upstream. */
unsigneduse_memdelay:1;
#endif
+#ifdef CONFIG_PERF_EVENTS
+ unsignedperf_cgroup_sched_in:1;
+#endif
unsigned long atomic_flags; /* Flags requiring atomic
access. */
diff --git a/kernel/events/core.c b/kernel/events/core.c
index abbd4b3b96c2..9b86b043018e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -817,6 +817,7 @@ static void perf_cgroup_switch(struct task_struct *task,
int mode)
* to event_filter_match() in event_sched_out()
*/
cpuctx->cgrp = NULL;
+ task->perf_cgroup_sched_in = 0;
}
if (mode & PERF_CGROUP_SWIN) {
@@ -831,6 +832,7 @@ static void perf_cgroup_switch(struct task_struct *task,
int mode)
cpuctx->cgrp = perf_cgroup_from_task(task,
>ctx);
cpu_ctx_sched_in(cpuctx, EVENT_ALL, task);
+ task->perf_cgroup_sched_in = 1;
}
perf_pmu_enable(cpuctx->ctx.pmu);
perf_ctx_unlock(cpuctx, cpuctx->task_ctx);
@@ -3233,7 +3235,8 @@ void __perf_event_task_sched_out(struct task_struct *task,
* to check if we have to switch out PMU state.
* cgroup event are system-wide mode only
*/
- if (atomic_read(this_cpu_ptr(_cgroup_events)))
+ if (atomic_read(this_cpu_ptr(_cgroup_events)) ||
+ task->perf_cgroup_sched_in)
perf_cgroup_sched_out(task, next);
}
--
2.21.0
linux-next: build failure after merge of the ecryptfs tree
Hi all,
I don't know why this suddenly appeared after mergeing the ecryptfs tree
since nothin has changed in that tree for some time (and nothing in that
tree seems relevant).
After merging the ecryptfs tree, today's linux-next build (x86_64
allmodconfig) failed like this:
scripts/Makefile.modpost:112: target '.tmp_versions/asix.mod' doesn't match the
target pattern
scripts/Makefile.modpost:113: warning: overriding recipe for target
'.tmp_versions/asix.mod'
scripts/Makefile.modpost:100: warning: ignoring old recipe for target
'.tmp_versions/asix.mod'
scripts/Makefile.modpost:127: target '.tmp_versions/asix.mod' doesn't match the
target pattern
scripts/Makefile.modpost:128: warning: overriding recipe for target
'.tmp_versions/asix.mod'
scripts/Makefile.modpost:113: warning: ignoring old recipe for target
'.tmp_versions/asix.mod'
make[2]: Circular .tmp_versions/asix.mod <- __modpost dependency dropped.
Binary file .tmp_versions/asix.mod matches: No such file or directory
make[2]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
make[1]: *** [Makefile:1290: modules] Error 2
The only clue I can see is that asix.o gets built in two separate
directories (drivers/net/{phy,usb}).
I have the following files in the object directory:
./.tmp_versions/asix.mod
./drivers/net/usb/asix.ko
./drivers/net/usb/asix.mod.o
./drivers/net/usb/asix.o
./drivers/net/usb/asix_common.o
./drivers/net/usb/asix_devices.o
./drivers/net/usb/.asix.ko.cmd
./drivers/net/usb/.asix.mod.o.cmd
./drivers/net/usb/.asix.o.cmd
./drivers/net/usb/asix.mod.c
./drivers/net/usb/.asix_common.o.cmd
./drivers/net/usb/.asix_devices.o.cmd
./drivers/net/phy/asix.ko
./drivers/net/phy/asix.o
./drivers/net/phy/.asix.ko.cmd
./drivers/net/phy/.asix.mod.o.cmd
./drivers/net/phy/asix.mod.o
./drivers/net/phy/asix.mod.c
./drivers/net/phy/.asix.o.cmd
./.tmp_versions/asix.mod
Looks like this:
--
drivers/net/phy/asix.ko
drivers/net/phy/asix.o
--
What you can't see above are the 256 NUL bytes at the end of the file
(followed by a NL).
This is from a -j 80 build. Surely there is a race condition here if the
file in .tmp_versions is only named for the base name of the module and
we have 2 modules with the same base name.
I removed that file and redid the build and it succeeded.
Mind you, I have no itdea why this file was begin rebuilt, the merge
only touched these files:
fs/ecryptfs/crypto.c
fs/ecryptfs/keystore.c
Puzzled ... :-(
--
Cheers,
Stephen Rothwell
pgpZqcWtugHme.pgp
Description: OpenPGP digital signature
Re: [v2 PATCH] RISC-V: Add a PE/COFF compliant Image header.
On Mon, 13 May 2019, Atish Patra wrote: > On 5/13/19 3:31 PM, Paul Walmsley wrote: > > On Wed, 1 May 2019, Atish Patra wrote: > > > > > Currently, last stage boot loaders such as U-Boot can accept only > > > uImage which is an unnecessary additional step in automating boot flows. > > > > > > Add a PE/COFF compliant image header that boot loaders can parse and > > > directly load kernel flat Image. The existing booting methods will > > > continue > > > to work as it is. > > > > > > Another goal of this header is to support EFI stub for RISC-V in future. > > > EFI specification needs PE/COFF image header in the beginning of the > > > kernel > > > image in order to load it as an EFI application. In order to support > > > EFI stub, code0 should be replaced with "MZ" magic string and res5(at > > > offset 0x3c) should point to the rest of the PE/COFF header (which will > > > be added during EFI support). > > > > > > Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux. > > > > > > Signed-off-by: Atish Patra > > > > Seems like we're stuck with this basic format for EFI, etc. Even though > > we may be stuck with it, I think we should take the opportunity to add the > > possibility to extending this header format by adding fields after the > > basic PE/COFF header ends. > > > > In particular, at the very least, I'd suggest adding a u32 after the > > PE/COFF header ends, to represent a "RISC-V header format version number". > > Then if we add more fields that follow the PE/COFF header -- for example, > > to represent the RISC-V instruction set extensions that are required to > > run this binary -- we can just bump that RISC-V-specific version number > > field to indicate to bootloaders that there's more there. > > > That would be inventing our RISC-V specific header format. However, we > can always use the one of the reserved fields in proposed header (res4) > for this purpose. What are the semantics of those reserved fields? > Do we need to add it now or add it later when we actually need a version > number. My preference is to add it later based on requirement. If it isn't added now, how would bootloaders know whether it was there or not? - Paul
Re: [Proposal] end of file checks by checkpatch.pl
On Tue, 2019-05-14 at 08:46 +0900, Masahiro Yamada wrote: > So, I think these two checks can be done for > all file types. [] > checkpatch.pl misses to report most of them. > (the majority of the warning source is *.json) Perhaps the json files should be ignored as more than half of the .json files in the tree are missing the newline at EOF. And at least some of those json files use spaces for indentation and not tabs.
[GIT PULL] PCI changes for v5.2
Enumeration changes: - Add _HPX Type 3 settings support, which gives firmware more influence over device configuration (Alexandru Gagniuc) - Support fixed bus numbers from bridge Enhanced Allocation capabilities (Subbaraya Sundeep) - Add "external-facing" DT property to identify cases where we require IOMMU protection against untrusted devices (Jean-Philippe Brucker) - Enable PCIe services for host controller drivers that use managed host bridge alloc (Jean-Philippe Brucker) - Log PCIe port service messages with pci_dev, not the pcie_device (Frederick Lawler) - Convert pciehp from pciehp_debug module parameter to generic dynamic debug (Frederick Lawler) Peer-to-peer DMA: - Add whitelist of Root Complexes that support peer-to-peer DMA between Root Ports (Christian König) Native controller drivers: - Add PCI host bridge DMA ranges for bridges that can't DMA everywhere, e.g., iProc (Srinath Mannam) - Add Amazon Annapurna Labs PCIe host controller driver (Jonathan Chocron) - Fix Tegra MSI target allocation so DMA doesn't generate unwanted MSIs (Vidya Sagar) - Fix of_node reference leaks (Wen Yang) - Fix Hyper-V module unload & device removal issues (Dexuan Cui) - Cleanup R-Car driver (Marek Vasut) - Cleanup Keystone driver (Kishon Vijay Abraham I) - Cleanup i.MX6 driver (Andrey Smirnov) Significant bug fixes: - Reset Lenovo ThinkPad P50 GPU so nouveau works after reboot (Lyude Paul) - Fix Switchtec firmware update performance issue (Wesley Sheng) - Work around Pericom switch link retraining erratum (Stefan Mätje) The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v5.2-changes for you to fetch changes up to c7a1c2bbb65e25551d585fba0fd36a01e0a22690: Merge branch 'pci/trivial' (2019-05-13 18:34:48 -0500) pci-v5.2-changes Alexandru Gagniuc (4): PCI/ACPI: Do not export pci_get_hp_params() PCI/ACPI: Remove the need for 'struct hotplug_params' PCI/ACPI: Implement _HPX Type 3 Setting Record PCI/ACPI: Advertise _HPX Type 3 support via _OSC Andrey Smirnov (11): PCI: imx6: Simplify imx7d_pcie_wait_for_phy_pll_lock() PCI: imx6: Drop imx6_pcie_wait_for_link() PCI: imx6: Return -ETIMEOUT from imx6_pcie_wait_for_speed_change() PCI: imx6: Remove PCIE_PL_PFLR_* constants PCI: dwc: imx6: Share PHY debug register definitions PCI: imx6: Make use of BIT() in constant definitions PCI: imx6: Simplify bit operations in PHY functions PCI: imx6: Simplify pcie_phy_poll_ack() PCI: imx6: Restrict PHY register data to 16-bit PCI: imx6: Use flags to indicate support for suspend PCI: imx6: Use usleep_range() in imx6_pcie_enable_ref_clk() Bjorn Helgaas (35): PCI/MSI: Remove unused __write_msi_msg() and write_msi_msg() PCI/MSI: Remove unused mask_msi_irq() and unmask_msi_irq() PCI: Cleanup register definition width and whitespace PCI: Fix comment typos CPER: Add UEFI spec references CPER: Remove unnecessary use of user-space types PCI: Use dev_printk() when possible PCI: pciehp: Remove pciehp_debug uses PCI: pciehp: Remove pointless PCIE_MODULE_NAME definition PCI: pciehp: Remove pointless MY_NAME definition Merge branch 'pci/aer' Merge branch 'pci/enumeration' Merge branch 'pci/hotplug' Merge branch 'pci/msi' Merge branch 'pci/misc' Merge branch 'pci/peer-to-peer' Merge branch 'pci/portdrv' Merge branch 'pci/switchtec' Merge branch 'pci/virtualization' Merge branch 'pci/host/al' Merge branch 'remotes/lorenzo/pci/controller-fixes' Merge branch 'pci/dwc' Merge branch 'remotes/lorenzo/pci/imx' Merge branch 'remotes/lorenzo/pci/iproc' Merge branch 'remotes/lorenzo/pci/keystone' Merge branch 'remotes/lorenzo/pci/mediatek' Merge branch 'remotes/lorenzo/pci/rcar' Merge branch 'remotes/lorenzo/pci/rockchip' Merge branch 'remotes/lorenzo/pci/tegra' Merge branch 'remotes/lorenzo/pci/xilinx' Merge branch 'remotes/lorenzo/pci/misc' Merge branch 'pci/iova-dma-ranges' Merge branch 'pci/printk' Merge branch 'pci/printk-portdrv' Merge branch 'pci/trivial' Christian König (1): PCI/P2PDMA: Allow P2P DMA between any devices under AMD ZEN Root Complex Chunfeng Yun (1): PCI: mediatek: Get optional clocks with devm_clk_get_optional() Colin Ian King (1): PCI: rockchip: Fix rockchip_pcie_ep_assert_intx() bitwise operations Dexuan Cui (3): PCI: hv: Fix a memory leak in hv_eject_device_work() PCI: hv: Add
Re: [PATCH] lkdtm: support llvm-objcopy
On Mon, May 13, 2019 at 4:29 PM Nathan Chancellor
wrote:
>
> On Mon, May 13, 2019 at 03:21:09PM -0700, 'Nick Desaulniers' via Clang Built
> Linux wrote:
> > With CONFIG_LKDTM=y and make OBJCOPY=llvm-objcopy, llvm-objcopy errors:
> > llvm-objcopy: error: --set-section-flags=.text conflicts with
> > --rename-section=.text=.rodata
> >
> > Rather than support setting flags then renaming sections vs renaming
> > then setting flags, it's simpler to just change both at the same time
> > via --rename-section.
> >
> > This can be verified with:
> > $ readelf -S drivers/misc/lkdtm/rodata_objcopy.o
> > ...
> > Section Headers:
> > [Nr] Name Type Address Offset
> >Size EntSize Flags Link Info Align
> > ...
> > [ 1] .rodata PROGBITS 0040
> >0004 A 0 0 4
> > ...
> >
> > Which shows in the Flags field that .text is now renamed .rodata, the
> > append flag A is set, and the section is not flagged as writeable W.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/448
> > Reported-by: Nathan Chancellor
>
> This should be natechancel...@gmail.com (although I think I do own that
> email, just haven't been into it for 10+ years...)
Sorry, I should have looked it up. I'll just fix this, my earlier
mistake, and collect Kee's reviewed by tag in a v2 sent directly to
GKH.
>
> > Suggested-by: Jordan Rupprect
> > Signed-off-by: Nick Desaulniers
> > ---
> > drivers/misc/lkdtm/Makefile | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/misc/lkdtm/Makefile b/drivers/misc/lkdtm/Makefile
> > index 951c984de61a..89dee2a9d88c 100644
> > --- a/drivers/misc/lkdtm/Makefile
> > +++ b/drivers/misc/lkdtm/Makefile
> > @@ -15,8 +15,7 @@ KCOV_INSTRUMENT_rodata.o:= n
> >
> > OBJCOPYFLAGS :=
> > OBJCOPYFLAGS_rodata_objcopy.o:= \
> > - --set-section-flags .text=alloc,readonly \
> > - --rename-section .text=.rodata
> > + --rename-section .text=.rodata,alloc,readonly
> > targets += rodata.o rodata_objcopy.o
> > $(obj)/rodata_objcopy.o: $(obj)/rodata.o FORCE
> > $(call if_changed,objcopy)
> > --
> > 2.21.0.1020.gf2820cf01a-goog
> >
>
> I ran this script to see if there was any change for GNU objcopy and it
> looks like .rodata's type gets changed, is this intentional? Otherwise,
> this works for llvm-objcopy like you show.
>
> ---
>
> 1c1
> < There are 11 section headers, starting at offset 0x240:
> ---
> > There are 11 section headers, starting at offset 0x230:
> 8c8
> < [ 1] .rodata PROGBITS 0040
> ---
> > [ 1] .rodata NOBITS 0040
> 10c10
Interesting find. the .rodata of vmlinux itself is marked PROGBITS,
so its curious that GNU binutils changes the "Type" after the rename.
I doubt the code in question relies on NOBITS for this section. Kees,
can you clarify? Jordan, do you know what the differences are between
PROGBITS vs NOBITS?
https://people.redhat.com/mpolacek/src/devconf2012.pdf seems to
suggest NOBITS zero initializes data but I'm not sure that's what this
code wants.
>
> ---
>
> #!/bin/bash
>
> TMP1=$(mktemp)
> TMP2=$(mktemp)
>
> git checkout next-20190513
>
> make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=out mrproper
> allyesconfig drivers/misc/lkdtm/
> readelf -S out/drivers/misc/lkdtm/rodata_objcopy.o > ${TMP1}
>
> curl -LSs
> https://lore.kernel.org/lkml/20190513222109.110020-1-ndesaulni...@google.com/raw
> | git am -3
>
> make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=out mrproper
> allyesconfig drivers/misc/lkdtm/
> readelf -S out/drivers/misc/lkdtm/rodata_objcopy.o > ${TMP2}
>
> diff ${TMP1} ${TMP2}
--
Thanks,
~Nick Desaulniers
Re: [PATCH] lkdtm: support llvm-objcopy
On Mon, May 13, 2019 at 04:38:54PM -0700, Jordan Rupprecht wrote:
> Nathan: is your version of llvm-objcopy later than r359639 (April 30)?
>
>
> From: Nathan Chancellor
> Date: Mon, May 13, 2019 at 4:29 PM
> To: Nick Desaulniers
> Cc: , ,
> Nathan Chancellor, Jordan Rupprect, Arnd Bergmann, Greg Kroah-Hartman,
>
>
> > On Mon, May 13, 2019 at 03:21:09PM -0700, 'Nick Desaulniers' via Clang
> > Built Linux wrote:
> > > With CONFIG_LKDTM=y and make OBJCOPY=llvm-objcopy, llvm-objcopy errors:
> > > llvm-objcopy: error: --set-section-flags=.text conflicts with
> > > --rename-section=.text=.rodata
> > >
> > > Rather than support setting flags then renaming sections vs renaming
> > > then setting flags, it's simpler to just change both at the same time
> > > via --rename-section.
> > >
> > > This can be verified with:
> > > $ readelf -S drivers/misc/lkdtm/rodata_objcopy.o
> > > ...
> > > Section Headers:
> > > [Nr] Name Type Address Offset
> > >Size EntSize Flags Link Info Align
> > > ...
> > > [ 1] .rodata PROGBITS 0040
> > >0004 A 0 0 4
> > > ...
> > >
> > > Which shows in the Flags field that .text is now renamed .rodata, the
> > > append flag A is set, and the section is not flagged as writeable W.
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/448
> > > Reported-by: Nathan Chancellor
> >
> > This should be natechancel...@gmail.com (although I think I do own that
> > email, just haven't been into it for 10+ years...)
> >
> > > Suggested-by: Jordan Rupprect
> > > Signed-off-by: Nick Desaulniers
> > > ---
> > > drivers/misc/lkdtm/Makefile | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/misc/lkdtm/Makefile b/drivers/misc/lkdtm/Makefile
> > > index 951c984de61a..89dee2a9d88c 100644
> > > --- a/drivers/misc/lkdtm/Makefile
> > > +++ b/drivers/misc/lkdtm/Makefile
> > > @@ -15,8 +15,7 @@ KCOV_INSTRUMENT_rodata.o:= n
> > >
> > > OBJCOPYFLAGS :=
> > > OBJCOPYFLAGS_rodata_objcopy.o:= \
> > > - --set-section-flags .text=alloc,readonly \
> > > - --rename-section .text=.rodata
> > > + --rename-section .text=.rodata,alloc,readonly
> > > targets += rodata.o rodata_objcopy.o
> > > $(obj)/rodata_objcopy.o: $(obj)/rodata.o FORCE
> > > $(call if_changed,objcopy)
> > > --
> > > 2.21.0.1020.gf2820cf01a-goog
> > >
> >
> > I ran this script to see if there was any change for GNU objcopy and it
> > looks like .rodata's type gets changed, is this intentional? Otherwise,
> > this works for llvm-objcopy like you show.
> >
> > ---
> >
> > 1c1
> > < There are 11 section headers, starting at offset 0x240:
> > ---
> > > There are 11 section headers, starting at offset 0x230:
> > 8c8
> > < [ 1] .rodata PROGBITS 0040
> > ---
> > > [ 1] .rodata NOBITS 0040
> > 10c10
> >
> > ---
> >
> > #!/bin/bash
> >
> > TMP1=$(mktemp)
> > TMP2=$(mktemp)
> >
> > git checkout next-20190513
> >
> > make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=out mrproper
> > allyesconfig drivers/misc/lkdtm/
> > readelf -S out/drivers/misc/lkdtm/rodata_objcopy.o > ${TMP1}
> >
> > curl -LSs
> > https://lore.kernel.org/lkml/20190513222109.110020-1-ndesaulni...@google.com/raw
> > | git am -3
> >
> > make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=out mrproper
> > allyesconfig drivers/misc/lkdtm/
> > readelf -S out/drivers/misc/lkdtm/rodata_objcopy.o > ${TMP2}
> >
> > diff ${TMP1} ${TMP2}
Hi Jordan,
Yes but that output was purely with GNU objcopy (checking section
headers before and after this patch). This is the section header
for llvm-objcopy after this patch:
[ 1] .rodata PROGBITS 0040
0004 A 0 0 4
Cheers,
Nathan
Re: [Proposal] end of file checks by checkpatch.pl
Hi Joe, On Tue, May 14, 2019 at 4:23 AM Joe Perches wrote: > > On Mon, 2019-05-13 at 19:11 +0900, Masahiro Yamada wrote: > > Hi Joe, > > Hello again. > > > On Fri, May 10, 2019 at 2:20 AM Joe Perches wrote: > > > On Fri, 2019-05-10 at 00:27 +0900, Masahiro Yamada wrote: > > > > Does it make sense to check the following > > > > by checkpatch.pl ? > > > > [1] blank line at end of file > > > > [2] no new line at end of file > > > > > > I'm pretty sure checkpatch does one this already. > [] > > Looks like the report depends on the file type. > > > > scripts/checkpatch.pl -f arch/sparc/lib/NG4clear_page.S > > scripts/checkpatch.pl -f tools/power/cpupower/bench/cpufreq-bench_plot.sh > > > > reported it, but > > > > scripts/checkpatch.pl -f drivers/media/dvb-frontends/cxd2880/Kconfig > > scripts/checkpatch.pl -f drivers/parport/Makefile > > > > did not. > > Yes, this check is after a test for filename extension. > > Currently the only file types it reports as missing an EOF > newline are done on files with the following extensions: > > .h > .c > .s > .S > .sh > .dtsi > .dts > > So the existing test is not done on many file types. > The same file types are used for the proposed patch. > > It's possible to have the existing missing newline at EOF > test and the proposed test for a blank line at EOF to be > done on all file types. > > Is this reasonable or could it cause some other issue > for any other file types? I do not know cases where missing newline at EOF or blank line at EOF is useful. (Even if there are some, checkpatch.pl is allowed to report false positives in my opinion.) So, I think these two checks can be done for all file types. Currently, the following is the list of missing newline at EOF. checkpatch.pl misses to report most of them. (the majority of the warning source is *.json) ./arch/arm/boot/dts/vexpress-v2m.dtsi ./arch/sparc/lib/NG4clear_page.S ./Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 ./Documentation/ABI/testing/sysfs-class-leds-gt683r ./Documentation/ABI/testing/sysfs-power ./Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt ./Documentation/devicetree/bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt ./Documentation/devicetree/bindings/regulator/pv88060.txt ./Documentation/devicetree/bindings/sound/cs42l73.txt ./Documentation/docutils.conf ./drivers/gpu/drm/amd/display/modules/power/Makefile ./drivers/media/dvb-frontends/cxd2880/Kconfig ./drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile ./drivers/parport/Makefile ./drivers/staging/mt7621-dts/TODO ./drivers/staging/rts5208/TODO ./drivers/staging/vt6655/test ./sound/soc/mediatek/common/Makefile ./sound/soc/tegra/Makefile ./sound/usb/bcd2000/Makefile ./tools/firmware/Makefile ./tools/perf/pmu-events/arch/powerpc/power9/cache.json ./tools/perf/pmu-events/arch/powerpc/power9/floating-point.json ./tools/perf/pmu-events/arch/powerpc/power9/frontend.json ./tools/perf/pmu-events/arch/powerpc/power9/marked.json ./tools/perf/pmu-events/arch/powerpc/power9/memory.json ./tools/perf/pmu-events/arch/powerpc/power9/other.json ./tools/perf/pmu-events/arch/powerpc/power9/pipeline.json ./tools/perf/pmu-events/arch/powerpc/power9/pmc.json ./tools/perf/pmu-events/arch/powerpc/power9/translation.json ./tools/perf/pmu-events/arch/x86/bonnell/cache.json ./tools/perf/pmu-events/arch/x86/bonnell/floating-point.json ./tools/perf/pmu-events/arch/x86/bonnell/frontend.json ./tools/perf/pmu-events/arch/x86/bonnell/memory.json ./tools/perf/pmu-events/arch/x86/bonnell/other.json ./tools/perf/pmu-events/arch/x86/bonnell/pipeline.json ./tools/perf/pmu-events/arch/x86/bonnell/virtual-memory.json ./tools/perf/pmu-events/arch/x86/broadwell/cache.json ./tools/perf/pmu-events/arch/x86/broadwellde/cache.json ./tools/perf/pmu-events/arch/x86/broadwellde/floating-point.json ./tools/perf/pmu-events/arch/x86/broadwellde/frontend.json ./tools/perf/pmu-events/arch/x86/broadwellde/memory.json ./tools/perf/pmu-events/arch/x86/broadwellde/other.json ./tools/perf/pmu-events/arch/x86/broadwellde/pipeline.json ./tools/perf/pmu-events/arch/x86/broadwellde/virtual-memory.json ./tools/perf/pmu-events/arch/x86/broadwell/floating-point.json ./tools/perf/pmu-events/arch/x86/broadwell/frontend.json ./tools/perf/pmu-events/arch/x86/broadwell/memory.json ./tools/perf/pmu-events/arch/x86/broadwell/other.json ./tools/perf/pmu-events/arch/x86/broadwell/pipeline.json ./tools/perf/pmu-events/arch/x86/broadwell/uncore.json ./tools/perf/pmu-events/arch/x86/broadwell/virtual-memory.json ./tools/perf/pmu-events/arch/x86/broadwellx/cache.json ./tools/perf/pmu-events/arch/x86/broadwellx/floating-point.json ./tools/perf/pmu-events/arch/x86/broadwellx/frontend.json ./tools/perf/pmu-events/arch/x86/broadwellx/memory.json ./tools/perf/pmu-events/arch/x86/broadwellx/other.json ./tools/perf/pmu-events/arch/x86/broadwellx/pipeline.json ./tools/perf/pmu-events/arch/x86/broadwellx/virtual-memory.json
Re: [PATCH 1/2] arm64: dts: meson: sei510: consistently order nodes
Neil Armstrong writes: > On 11/05/2019 17:52, Jerome Brunet wrote: >> On Fri, 2019-05-10 at 14:43 -0700, Kevin Hilman wrote: >>> minor nit: I kind of like "aliases" and "chosen" at the top since they >>> are kind of special nodes, but honestly, I can't think of a really good >>> reason other than personal preference, so keeping things sorted as >>> you've done here is probably better. >>> >> >> You thought the same, then thought maybe memory was important too. But going >> down that path, you end up sorting by feeling. It is going to be difficult >> to all agree on which nodes are special. >> >> In the end, we just want/need something that is easy to respect and verify. > > I think it would be better to have the same layout for aliases and memory over > all the amlogic DTS, it's common over all socs to have these nodes on top. aliases, chosen, memory and reserved-memory are ones that are typically on the top for convience sake, but looking around we have not been terribly consistent there either. At this point, to continue the tradition, I'm not going to be too picky about enforcing "standards" that are loosely defined (or undefined) and will generally accept cleanups that are moving us towards consistency and ease of rebasing. Kevin
Re: [PATCH] lkdtm: support llvm-objcopy
Nathan: is your version of llvm-objcopy later than r359639 (April 30)?
From: Nathan Chancellor
Date: Mon, May 13, 2019 at 4:29 PM
To: Nick Desaulniers
Cc: , ,
Nathan Chancellor, Jordan Rupprect, Arnd Bergmann, Greg Kroah-Hartman,
> On Mon, May 13, 2019 at 03:21:09PM -0700, 'Nick Desaulniers' via Clang Built
> Linux wrote:
> > With CONFIG_LKDTM=y and make OBJCOPY=llvm-objcopy, llvm-objcopy errors:
> > llvm-objcopy: error: --set-section-flags=.text conflicts with
> > --rename-section=.text=.rodata
> >
> > Rather than support setting flags then renaming sections vs renaming
> > then setting flags, it's simpler to just change both at the same time
> > via --rename-section.
> >
> > This can be verified with:
> > $ readelf -S drivers/misc/lkdtm/rodata_objcopy.o
> > ...
> > Section Headers:
> > [Nr] Name Type Address Offset
> >Size EntSize Flags Link Info Align
> > ...
> > [ 1] .rodata PROGBITS 0040
> >0004 A 0 0 4
> > ...
> >
> > Which shows in the Flags field that .text is now renamed .rodata, the
> > append flag A is set, and the section is not flagged as writeable W.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/448
> > Reported-by: Nathan Chancellor
>
> This should be natechancel...@gmail.com (although I think I do own that
> email, just haven't been into it for 10+ years...)
>
> > Suggested-by: Jordan Rupprect
> > Signed-off-by: Nick Desaulniers
> > ---
> > drivers/misc/lkdtm/Makefile | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/misc/lkdtm/Makefile b/drivers/misc/lkdtm/Makefile
> > index 951c984de61a..89dee2a9d88c 100644
> > --- a/drivers/misc/lkdtm/Makefile
> > +++ b/drivers/misc/lkdtm/Makefile
> > @@ -15,8 +15,7 @@ KCOV_INSTRUMENT_rodata.o:= n
> >
> > OBJCOPYFLAGS :=
> > OBJCOPYFLAGS_rodata_objcopy.o:= \
> > - --set-section-flags .text=alloc,readonly \
> > - --rename-section .text=.rodata
> > + --rename-section .text=.rodata,alloc,readonly
> > targets += rodata.o rodata_objcopy.o
> > $(obj)/rodata_objcopy.o: $(obj)/rodata.o FORCE
> > $(call if_changed,objcopy)
> > --
> > 2.21.0.1020.gf2820cf01a-goog
> >
>
> I ran this script to see if there was any change for GNU objcopy and it
> looks like .rodata's type gets changed, is this intentional? Otherwise,
> this works for llvm-objcopy like you show.
>
> ---
>
> 1c1
> < There are 11 section headers, starting at offset 0x240:
> ---
> > There are 11 section headers, starting at offset 0x230:
> 8c8
> < [ 1] .rodata PROGBITS 0040
> ---
> > [ 1] .rodata NOBITS 0040
> 10c10
>
> ---
>
> #!/bin/bash
>
> TMP1=$(mktemp)
> TMP2=$(mktemp)
>
> git checkout next-20190513
>
> make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=out mrproper
> allyesconfig drivers/misc/lkdtm/
> readelf -S out/drivers/misc/lkdtm/rodata_objcopy.o > ${TMP1}
>
> curl -LSs
> https://lore.kernel.org/lkml/20190513222109.110020-1-ndesaulni...@google.com/raw
> | git am -3
>
> make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=out mrproper
> allyesconfig drivers/misc/lkdtm/
> readelf -S out/drivers/misc/lkdtm/rodata_objcopy.o > ${TMP2}
>
> diff ${TMP1} ${TMP2}
smime.p7s
Description: S/MIME Cryptographic Signature
RE: [PATCH RESEND 1/2] soc: imx: Add SCU SoC info driver support
Hi, Daniel
> -Original Message-
> From: Daniel Baluta [mailto:daniel.bal...@gmail.com]
> Sent: Monday, May 13, 2019 10:30 PM
> To: Anson Huang
> Cc: catalin.mari...@arm.com; will.dea...@arm.com;
> shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de;
> feste...@gmail.com; maxime.rip...@bootlin.com; agr...@kernel.org;
> o...@lixom.net; horms+rene...@verge.net.au;
> ja...@amarulasolutions.com; bjorn.anders...@linaro.org; Leonard Crestez
> ; marc.w.gonza...@free.fr;
> dingu...@kernel.org; enric.balle...@collabora.com; Aisheng Dong
> ; r...@kernel.org; Abel Vesa
> ; l.st...@pengutronix.de; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; dl-linux-imx
> ; Daniel Baluta
> Subject: Re: [PATCH RESEND 1/2] soc: imx: Add SCU SoC info driver support
>
>
>
> > +
> > +static u32 imx8qxp_soc_revision(void) {
> > + struct imx_sc_msg_misc_get_soc_id msg;
> > + struct imx_sc_rpc_msg *hdr =
> > + u32 rev = 0;
> > + int ret;
> > +
> > + hdr->ver = IMX_SC_RPC_VERSION;
> > + hdr->svc = IMX_SC_RPC_SVC_MISC;
> > + hdr->func = IMX_SC_MISC_FUNC_GET_CONTROL;
> > + hdr->size = 3;
> > +
> > + msg.data.send.control = IMX_SC_C_ID;
> > + msg.data.send.resource = IMX_SC_R_SYSTEM;
> > +
> > + ret = imx_scu_call_rpc(soc_ipc_handle, , true);
> > + if (ret) {
> > + dev_err(_scu_soc_pdev->dev,
> > + "get soc info failed, ret %d\n", ret);
> > + return rev;
>
> So you return 0 (rev = 0) here in case of error? This doesn't seem to be
> right.
> Maybe return ret?
This is intentional, similar with current i.MX8MQ soc info driver, when getting
revision
failed, just return 0 as revision info and it will show "unknown" in sysfs.
Thanks,
Anson.
Re: [PATCH V1] elan_i2c: Increment wakeup count if wake source.
Hi Ravi,
On Mon, May 13, 2019 at 3:06 PM Ravi Chandra Sadineni
wrote:
>
> Notify the PM core that this dev is the wake source. This helps
> userspace daemon tracking the wake source to identify the origin of the
> wake.
I wonder if we could do that form the i2c core instead of individual drivers?
>
> Signed-off-by: Ravi Chandra Sadineni
> ---
> drivers/input/mouse/elan_i2c_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c
> b/drivers/input/mouse/elan_i2c_core.c
> index f9525d6f0bfe..2c0561e20b7f 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -981,6 +981,8 @@ static irqreturn_t elan_isr(int irq, void *dev_id)
> if (error)
> goto out;
>
> + pm_wakeup_event(dev, 0);
> +
> switch (report[ETP_REPORT_ID_OFFSET]) {
> case ETP_REPORT_ID:
> elan_report_absolute(data, report);
> --
> 2.20.1
>
Thanks.
--
Dmitry
Re: [PATCH] lkdtm: support llvm-objcopy
On Mon, May 13, 2019 at 03:21:09PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> With CONFIG_LKDTM=y and make OBJCOPY=llvm-objcopy, llvm-objcopy errors:
> llvm-objcopy: error: --set-section-flags=.text conflicts with
> --rename-section=.text=.rodata
>
> Rather than support setting flags then renaming sections vs renaming
> then setting flags, it's simpler to just change both at the same time
> via --rename-section.
>
> This can be verified with:
> $ readelf -S drivers/misc/lkdtm/rodata_objcopy.o
> ...
> Section Headers:
> [Nr] Name Type Address Offset
>Size EntSize Flags Link Info Align
> ...
> [ 1] .rodata PROGBITS 0040
>0004 A 0 0 4
> ...
>
> Which shows in the Flags field that .text is now renamed .rodata, the
> append flag A is set, and the section is not flagged as writeable W.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/448
> Reported-by: Nathan Chancellor
This should be natechancel...@gmail.com (although I think I do own that
email, just haven't been into it for 10+ years...)
> Suggested-by: Jordan Rupprect
> Signed-off-by: Nick Desaulniers
> ---
> drivers/misc/lkdtm/Makefile | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/misc/lkdtm/Makefile b/drivers/misc/lkdtm/Makefile
> index 951c984de61a..89dee2a9d88c 100644
> --- a/drivers/misc/lkdtm/Makefile
> +++ b/drivers/misc/lkdtm/Makefile
> @@ -15,8 +15,7 @@ KCOV_INSTRUMENT_rodata.o:= n
>
> OBJCOPYFLAGS :=
> OBJCOPYFLAGS_rodata_objcopy.o:= \
> - --set-section-flags .text=alloc,readonly \
> - --rename-section .text=.rodata
> + --rename-section .text=.rodata,alloc,readonly
> targets += rodata.o rodata_objcopy.o
> $(obj)/rodata_objcopy.o: $(obj)/rodata.o FORCE
> $(call if_changed,objcopy)
> --
> 2.21.0.1020.gf2820cf01a-goog
>
I ran this script to see if there was any change for GNU objcopy and it
looks like .rodata's type gets changed, is this intentional? Otherwise,
this works for llvm-objcopy like you show.
---
1c1
< There are 11 section headers, starting at offset 0x240:
---
> There are 11 section headers, starting at offset 0x230:
8c8
< [ 1] .rodata PROGBITS 0040
---
> [ 1] .rodata NOBITS 0040
10c10
---
#!/bin/bash
TMP1=$(mktemp)
TMP2=$(mktemp)
git checkout next-20190513
make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=out mrproper
allyesconfig drivers/misc/lkdtm/
readelf -S out/drivers/misc/lkdtm/rodata_objcopy.o > ${TMP1}
curl -LSs
https://lore.kernel.org/lkml/20190513222109.110020-1-ndesaulni...@google.com/raw
| git am -3
make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=out mrproper
allyesconfig drivers/misc/lkdtm/
readelf -S out/drivers/misc/lkdtm/rodata_objcopy.o > ${TMP2}
diff ${TMP1} ${TMP2}
Re: [v2 PATCH] RISC-V: Add a PE/COFF compliant Image header.
On 5/13/19 3:31 PM, Paul Walmsley wrote: On Wed, 1 May 2019, Atish Patra wrote: Currently, last stage boot loaders such as U-Boot can accept only uImage which is an unnecessary additional step in automating boot flows. Add a PE/COFF compliant image header that boot loaders can parse and directly load kernel flat Image. The existing booting methods will continue to work as it is. Another goal of this header is to support EFI stub for RISC-V in future. EFI specification needs PE/COFF image header in the beginning of the kernel image in order to load it as an EFI application. In order to support EFI stub, code0 should be replaced with "MZ" magic string and res5(at offset 0x3c) should point to the rest of the PE/COFF header (which will be added during EFI support). Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux. Signed-off-by: Atish Patra Seems like we're stuck with this basic format for EFI, etc. Even though we may be stuck with it, I think we should take the opportunity to add the possibility to extending this header format by adding fields after the basic PE/COFF header ends. In particular, at the very least, I'd suggest adding a u32 after the PE/COFF header ends, to represent a "RISC-V header format version number". Then if we add more fields that follow the PE/COFF header -- for example, to represent the RISC-V instruction set extensions that are required to run this binary -- we can just bump that RISC-V-specific version number field to indicate to bootloaders that there's more there. That would be inventing our RISC-V specific header format. However, we can always use the one of the reserved fields in proposed header (res4) for this purpose. Do we need to add it now or add it later when we actually need a version number. My preference is to add it later based on requirement. One other observation - if what's here was copied from some other architecture, like ARM, please acknowledge the source in the patch description. Sure. I will update the patch. Regards, Atish thanks - Paul
Re: C3600, sata controller
On 2019-05-12 5:15 p.m., Carlo Pisani wrote: >> The c3600 doesn't have any PCI-X slots (only PCI) as far as I can tell from >> user manuals. > PCI-32/33 device I/O bus > PCI-64/33 high-performance device I/O bus <- this is > PCI-X, 64bit 5V > PCI-64/66 high-performance graphics I/O bus <- this is > PCI-X, 64bit 3.3V > > https://www.openpa.net/systems/hp-visualize_b1000_c3000_c3600.html I think that you are wrong. HP would have said the slots were PCI-X compatible if they were. They did in c8000. The issue is probably the signalling voltage and clock rate capability. 33 MHz always uses 5V signalling whereas PCX-X cards typically support 66 and 133 MHz. Thus, I think PCI-X cards use CMOS 3.3V signalling although they may accept 5V on their inputs. If the c3600 uses older TTL logic, it is likely that 3.3V CMOS logic can't provide the high level for 5V TTL logic. I suspect the only slot that might work with a PCI-X card is the 3.3V SL2. However, if you see I/O errors in the PIM dump following a HPMC, then it's not compatible. So, probably you would have better luck with the PCI Syba SD-SATA150R in c3600. However, it is similar to the Adaptec 1210SA which works. Maybe they differ in RAID capability. Dave -- John David Anglin dave.ang...@bell.net
Re: [GIT PULL] gcc-plugins fixes for v5.2-rc1
The pull request you sent on Mon, 13 May 2019 14:05:25 -0700: > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git > tags/gcc-plugins-v5.2-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/63863ee8e2f6f6ae47be3dff4af2f2806f5ca2dd Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] lkdtm: support llvm-objcopy
On Mon, May 13, 2019 at 03:21:09PM -0700, Nick Desaulniers wrote: > With CONFIG_LKDTM=y and make OBJCOPY=llvm-objcopy, llvm-objcopy errors: > llvm-objcopy: error: --set-section-flags=.text conflicts with > --rename-section=.text=.rodata > > Rather than support setting flags then renaming sections vs renaming > then setting flags, it's simpler to just change both at the same time > via --rename-section. > > This can be verified with: > $ readelf -S drivers/misc/lkdtm/rodata_objcopy.o > ... > Section Headers: > [Nr] Name Type Address Offset >Size EntSize Flags Link Info Align > ... > [ 1] .rodata PROGBITS 0040 >0004 A 0 0 4 > ... > > Which shows in the Flags field that .text is now renamed .rodata, the > append flag A is set, and the section is not flagged as writeable W. > > Link: https://github.com/ClangBuiltLinux/linux/issues/448 > Reported-by: Nathan Chancellor > Suggested-by: Jordan Rupprect > Signed-off-by: Nick Desaulniers Thanks! This looks good. Greg, can you please take this for drivers/misc? Acked-by: Kees Cook -Kees > --- > drivers/misc/lkdtm/Makefile | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/misc/lkdtm/Makefile b/drivers/misc/lkdtm/Makefile > index 951c984de61a..89dee2a9d88c 100644 > --- a/drivers/misc/lkdtm/Makefile > +++ b/drivers/misc/lkdtm/Makefile > @@ -15,8 +15,7 @@ KCOV_INSTRUMENT_rodata.o:= n > > OBJCOPYFLAGS := > OBJCOPYFLAGS_rodata_objcopy.o:= \ > - --set-section-flags .text=alloc,readonly \ > - --rename-section .text=.rodata > + --rename-section .text=.rodata,alloc,readonly > targets += rodata.o rodata_objcopy.o > $(obj)/rodata_objcopy.o: $(obj)/rodata.o FORCE > $(call if_changed,objcopy) > -- > 2.21.0.1020.gf2820cf01a-goog > -- Kees Cook
Re: [v2 PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush
On 5/13/19 9:38 AM, Will Deacon wrote:
On Fri, May 10, 2019 at 07:26:54AM +0800, Yang Shi wrote:
diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
index 99740e1..469492d 100644
--- a/mm/mmu_gather.c
+++ b/mm/mmu_gather.c
@@ -245,14 +245,39 @@ void tlb_finish_mmu(struct mmu_gather *tlb,
{
/*
* If there are parallel threads are doing PTE changes on same range
-* under non-exclusive lock(e.g., mmap_sem read-side) but defer TLB
-* flush by batching, a thread has stable TLB entry can fail to flush
-* the TLB by observing pte_none|!pte_dirty, for example so flush TLB
-* forcefully if we detect parallel PTE batching threads.
+* under non-exclusive lock (e.g., mmap_sem read-side) but defer TLB
+* flush by batching, one thread may end up seeing inconsistent PTEs
+* and result in having stale TLB entries. So flush TLB forcefully
+* if we detect parallel PTE batching threads.
+*
+* However, some syscalls, e.g. munmap(), may free page tables, this
+* needs force flush everything in the given range. Otherwise this
+* may result in having stale TLB entries for some architectures,
+* e.g. aarch64, that could specify flush what level TLB.
*/
- if (mm_tlb_flush_nested(tlb->mm)) {
- __tlb_reset_range(tlb);
- __tlb_adjust_range(tlb, start, end - start);
+ if (mm_tlb_flush_nested(tlb->mm) && !tlb->fullmm) {
+ /*
+* Since we can't tell what we actually should have
+* flushed, flush everything in the given range.
+*/
+ tlb->freed_tables = 1;
+ tlb->cleared_ptes = 1;
+ tlb->cleared_pmds = 1;
+ tlb->cleared_puds = 1;
+ tlb->cleared_p4ds = 1;
+
+ /*
+* Some architectures, e.g. ARM, that have range invalidation
+* and care about VM_EXEC for I-Cache invalidation, need force
+* vma_exec set.
+*/
+ tlb->vma_exec = 1;
+
+ /* Force vma_huge clear to guarantee safer flush */
+ tlb->vma_huge = 0;
+
+ tlb->start = start;
+ tlb->end = end;
}
Whilst I think this is correct, it would be interesting to see whether
or not it's actually faster than just nuking the whole mm, as I mentioned
before.
At least in terms of getting a short-term fix, I'd prefer the diff below
if it's not measurably worse.
I did a quick test with ebizzy (96 threads with 5 iterations) on my x86
VM, it shows slightly slowdown on records/s but much more sys time spent
with fullmm flush, the below is the data.
nofullmm fullmm
ops (records/s) 225606 225119
sys (s) 0.69 1.14
It looks the slight reduction of records/s is caused by the increase of
sys time.
Will
--->8
diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
index 99740e1dd273..cc251422d307 100644
--- a/mm/mmu_gather.c
+++ b/mm/mmu_gather.c
@@ -251,8 +251,9 @@ void tlb_finish_mmu(struct mmu_gather *tlb,
* forcefully if we detect parallel PTE batching threads.
*/
if (mm_tlb_flush_nested(tlb->mm)) {
+ tlb->fullmm = 1;
__tlb_reset_range(tlb);
- __tlb_adjust_range(tlb, start, end - start);
+ tlb->freed_tables = 1;
}
tlb_flush_mmu(tlb);
Re: [GIT PULL] percpu changes for v5.2-rc1
The pull request you sent on Mon, 13 May 2019 14:52:41 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/dennis/percpu.git for-5.2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3aff5fac54d722f363eac7db94536bffb55ca43f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT] Networking
The pull request you sent on Mon, 13 May 2019 10:08:08 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git refs/heads/master has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a3958f5e13e23f6e68c3cc1210639f63728a950f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] Input updates for v5.2-rc0
The pull request you sent on Mon, 13 May 2019 13:12:35 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0aed4b28187078565cafbfe86b62f941d580d840 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [RFC 2/3] arm64: dts: qcom: sdm845-cheza: Re-add reserved memory
Hi,
On Thu, May 9, 2019 at 11:44 AM Rob Clark wrote:
> From: Douglas Anderson
>
> Let's fixup the reserved memory to re-add the things we deleted in
> ("CHROMIUM: arm64: dts: qcom: sdm845-cheza: Temporarily delete
> reserved-mem changes") in a way that plays nicely with the new
> upstream definitions.
The message above makes no sense since that commit you reference isn't
in upstream.
...but in any case, why not squash this in with the previous commit?
> Signed-off-by: Douglas Anderson
> Reviewed-by: Stephen Boyd
> Signed-off-by: Rob Clark
Remove Stephen's Reviewed-by. In general reviews that happen in the
Chrome OS gerrit shouldn't be carried over when things are posted
upstream.
> +/* Increase the size from 2MB to 8MB */
> +_mem {
> + reg = <0 0x88f0 0 0x80>;
> +};
> +
> +/ {
> + reserved-memory {
> + venus_mem: memory@9600 {
> + reg = <0 0x9600 0 0x50>;
> + no-map;
> + };
> + };
> +};
nit: blank line?
-Doug
Re: [PATCH] gfs2: Fix error path kobject memory leak
On Mon, May 13, 2019 at 3:37 PM Andreas Gruenbacher wrote: > > Sorry, I should have been more explicit. Would you mind taking this > patch, please? If it's more convenient or more appropriate, I'll send > a pull request instead. Done. However,I'd like to point out that when I see patches from people who I normally get a pull request from, I usually ignore them. Particularly when they are in some thread with discussion, I'll often just assume that th epatch is part of the thread, not really meant for me in particular. In this case I happened to notice that suddenly my participation status changed, which is why I asked, but in general I might hav ejust archived the thread with the assumption that I'll be getting the patch later as a git pull. Just so you'll be aware of this in the future, in case I don't react... Linus
Re: [PATCH 1/2] fdomain: Remove BIOS-related code from core
Hi Ondrej, > Move all BIOS signature and base handling to (currently not merged) > ISA bus driver. Please submit a complete (core/PCI/ISA) series with the kbuild warnings addressed and Christoph's tags added. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [RFC 1/3] arm64: dts: qcom: sdm845-cheza: add initial cheza dt
Hi,
On Thu, May 9, 2019 at 11:44 AM Rob Clark wrote:
> From: Rob Clark
>
> This is essentialy a squash of a bunch of history of cheza dt updates
> from chromium kernel, some of which were themselves squashes of history
> from older chromium kernels.
>
> I don't claim any credit other than wanting to more easily boot upstream
> kernel on cheza to have an easier way to test upstream driver work ;-)
>
> I've added below in Cc tags all the original actual authors (apologies
> if I missed any).
>
> Cc: Douglas Anderson
> Cc: Sibi Sankar
> Cc: Evan Green
> Cc: Matthias Kaehlcke
> Cc: Abhinav Kumar
> Cc: Brian Norris
> Cc: Venkat Gopalakrishnan
> Cc: Rajendra Nayak
> Signed-off-by: Rob Clark
> ---
> arch/arm64/boot/dts/qcom/Makefile|3 +
> arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts | 238
> arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts | 238
> arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts | 180 +++
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 1317 ++
> 5 files changed, 1976 insertions(+)
In general I am supportive of getting cheza dts landed upstream.
One question is how much cleanup we want to do while landing upstream.
We have a few TODO / HACK comments currently. Do we want to land what
we have and clean these up in separate commits, or should we try to do
cleanup beforehand. Bjron / Andy: do you have any opinions? I've
commented on a few below.
> diff --git a/arch/arm64/boot/dts/qcom/Makefile
> b/arch/arm64/boot/dts/qcom/Makefile
> index b3fe72ff2955..7a038cf81543 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -8,6 +8,9 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8994-angler-rev-101.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= msm8998-mtp.dtb
> +dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r1.dtb
> +dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
> +dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-1000.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-4000.dtb
Something about the above makes "git am" unhappy and "patch -p1" think
this is a malformed patch. When I delete the part touching the
Makefile then I can apply OK.
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
> b/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
> new file mode 100644
> index ..35bb4629edd4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
> @@ -0,0 +1,238 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Google Cheza board device tree source
> + *
> + * Copyright 2018 Google LLC.
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm845-cheza.dtsi"
> +
> +/ {
> + model = "Google Cheza (rev1)";
> + compatible = "google,cheza-rev1", "google,cheza", "qcom,sdm845";
See below for rev 3, but I think this might be better as:
compatible = "google,cheza-rev1", "qcom,sdm845";
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
> b/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
> new file mode 100644
> index ..4359a82d4bb4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
> @@ -0,0 +1,238 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Google Cheza board device tree source
> + *
> + * Copyright 2018 Google LLC.
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm845-cheza.dtsi"
> +
> +/ {
> + model = "Google Cheza (rev2)";
> + compatible = "google,cheza-rev2", "google,cheza", "qcom,sdm845";
See above and below, but probably:
compatible = "google,cheza-rev2", "qcom,sdm845";
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
> b/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
> new file mode 100644
> index ..2c3f815b90c1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
> @@ -0,0 +1,180 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Google Cheza board device tree source
> + *
> + * Copyright 2018 Google LLC.
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm845-cheza.dtsi"
> +
> +/ {
> + model = "Google Cheza (rev3+)";
> + compatible = "google,cheza-rev15", "google,cheza-rev14",
> +"google,cheza-rev13", "google,cheza-rev12",
> +"google,cheza-rev11", "google,cheza-rev10",
> +"google,cheza-rev9", "google,cheza-rev8",
> +"google,cheza-rev7", "google,cheza-rev6",
> +"google,cheza-rev5", "google,cheza-rev4",
> +"google,cheza-rev3", "google,cheza", "qcom,sdm845";
Julius Werner suggested that a better solution is that the newest dts
should specify no revision. Thus this should be just:
compatible = "google,cheza", "qcom,sdm845";
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> new file mode 100644
> index
Re: [PATCH 4/5] ceph: fix improper use of smp_mb__before_atomic()
> >>> /* > >>> * XXX: the comment that explain this barrier goes here. > >>> */ > >>> > >> > >>makes sure operations that setup readdir cache (update page cache and > >>i_size) are strongly ordered with following atomic64_set. > > > >Thanks for the suggestion, Yan. > > > >To be clear: would you like me to integrate your comment and resend? > >any other suggestions? > > > > Yes, please Will do: I'll let the merge window close and send v2 on top of -rc1. Thanks, Andrea
Re: [PATCH] scsi: myrs: Fix uninitialized variable
YueHaibing, > If ev->ev_code is not 0x1C, sshdr.sense_key may be used > uninitialized. Fix this by initializing variable 'sshdr' to 0. Applied to 5.2/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v3 23/30] coresight: Add support for releasing platform specific data
On Tue, May 07, 2019 at 11:52:50AM +0100, Suzuki K Poulose wrote:
> Add a helper to clean up the platform specific data provided
> by the firmware. This will be later used for dropping the necessary
> references when we switch to the fwnode handles for tracking
> connections.
>
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/hwtracing/coresight/coresight-platform.c | 6 +-
> drivers/hwtracing/coresight/coresight-priv.h | 4
> drivers/hwtracing/coresight/coresight.c | 3 +++
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-platform.c
> b/drivers/hwtracing/coresight/coresight-platform.c
> index f500de6..53d6eed 100644
> --- a/drivers/hwtracing/coresight/coresight-platform.c
> +++ b/drivers/hwtracing/coresight/coresight-platform.c
> @@ -17,6 +17,7 @@
> #include
> #include
>
> +#include "coresight-priv.h"
> /*
> * coresight_alloc_conns: Allocate connections record for each output
> * port from the device.
> @@ -311,7 +312,7 @@ struct coresight_platform_data *
> coresight_get_platform_data(struct device *dev)
> {
> int ret = -ENOENT;
> - struct coresight_platform_data *pdata;
> + struct coresight_platform_data *pdata = NULL;
> struct fwnode_handle *fwnode = dev_fwnode(dev);
>
> if (IS_ERR_OR_NULL(fwnode))
> @@ -329,6 +330,9 @@ coresight_get_platform_data(struct device *dev)
> if (!ret)
> return pdata;
> error:
> + if (!IS_ERR_OR_NULL(pdata))
> + /* Cleanup the connection information */
> + coresight_release_platform_data(pdata);
> return ERR_PTR(ret);
> }
> EXPORT_SYMBOL_GPL(coresight_get_platform_data);
> diff --git a/drivers/hwtracing/coresight/coresight-priv.h
> b/drivers/hwtracing/coresight/coresight-priv.h
> index e0684d0..c216421 100644
> --- a/drivers/hwtracing/coresight/coresight-priv.h
> +++ b/drivers/hwtracing/coresight/coresight-priv.h
> @@ -200,4 +200,8 @@ static inline void *coresight_get_uci_data(const struct
> amba_id *id)
> return 0;
> }
>
> +static inline void
> +coresight_release_platform_data(struct coresight_platform_data *pdata)
> +{}
> +
> #endif
> diff --git a/drivers/hwtracing/coresight/coresight.c
> b/drivers/hwtracing/coresight/coresight.c
> index 96e1515..526141c 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight.c
> @@ -1250,6 +1250,8 @@ struct coresight_device *coresight_register(struct
> coresight_desc *desc)
> err_free_csdev:
> kfree(csdev);
> err_out:
> + /* Cleanup the connection information */
> + coresight_release_platform_data(desc->pdata);
> return ERR_PTR(ret);
> }
> EXPORT_SYMBOL_GPL(coresight_register);
> @@ -1259,6 +1261,7 @@ void coresight_unregister(struct coresight_device
> *csdev)
> etm_perf_del_symlink_sink(csdev);
> /* Remove references of that device in the topology */
> coresight_remove_conns(csdev);
> + coresight_release_platform_data(csdev->pdata);
> device_unregister(>dev);
> }
> EXPORT_SYMBOL_GPL(coresight_unregister);
Reviewed-by: Mathieu Poirier
> --
> 2.7.4
>
Re: [PATCH v3 29/30] coresight: acpi: Support for AMBA components
On Tue, May 07, 2019 at 11:52:56AM +0100, Suzuki K Poulose wrote:
> All AMBA devices are handled via ACPI AMBA scan notifier
> infrastructure. The platform devices get the ACPI id
> added to their driver.
>
> Cc: "Rafael J. Wysocki"
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/acpi/acpi_amba.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
> index 7f77c07..eef5a69 100644
> --- a/drivers/acpi/acpi_amba.c
> +++ b/drivers/acpi/acpi_amba.c
> @@ -24,6 +24,15 @@
>
> static const struct acpi_device_id amba_id_list[] = {
> {"ARMH0061", 0}, /* PL061 GPIO Device */
> + {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
> + {"ARMHC501", 0}, /* ARM CoreSight ETR */
> + {"ARMHC502", 0}, /* ARM CoreSight STM */
> + {"ARMHC503", 0}, /* ARM CoreSight Debug */
> + {"ARMHC979", 0}, /* ARM CoreSight TPIU */
> + {"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
> + {"ARMHC98D", 0}, /* ARM CoreSight Dynamic Replicator */
> + {"ARMHC9CA", 0}, /* ARM CoreSight CATU */
> + {"ARMHC9FF", 0}, /* ARM CoreSight Funnel */
> {"", 0},
Reviewed-by: Mathieu Poirier
> };
>
> --
> 2.7.4
>
Re: [PATCH -next] scsi: qedi: remove set but not used variables 'cdev' and 'udev'
Yue, > From: YueHaibing > > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/scsi/qedi/qedi_iscsi.c: In function 'qedi_ep_connect': > drivers/scsi/qedi/qedi_iscsi.c:813:23: warning: variable 'udev' set but not > used [-Wunused-but-set-variable] > drivers/scsi/qedi/qedi_iscsi.c:812:18: warning: variable 'cdev' set but not > used [-Wunused-but-set-variable] Applied to 5.2/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: qedi: remove memset/memcpy to nfunc and use func instead
Yue, > KASAN report this: > > BUG: KASAN: global-out-of-bounds in qedi_dbg_err+0xda/0x330 [qedi] > Read of size 31 at addr c12b0ae0 by task syz-executor.0/2429 Applied to 5.2/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [v2 PATCH] RISC-V: Add a PE/COFF compliant Image header.
On Wed, 1 May 2019, Atish Patra wrote: > Currently, last stage boot loaders such as U-Boot can accept only > uImage which is an unnecessary additional step in automating boot flows. > > Add a PE/COFF compliant image header that boot loaders can parse and > directly load kernel flat Image. The existing booting methods will continue > to work as it is. > > Another goal of this header is to support EFI stub for RISC-V in future. > EFI specification needs PE/COFF image header in the beginning of the kernel > image in order to load it as an EFI application. In order to support > EFI stub, code0 should be replaced with "MZ" magic string and res5(at > offset 0x3c) should point to the rest of the PE/COFF header (which will > be added during EFI support). > > Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux. > > Signed-off-by: Atish Patra Seems like we're stuck with this basic format for EFI, etc. Even though we may be stuck with it, I think we should take the opportunity to add the possibility to extending this header format by adding fields after the basic PE/COFF header ends. In particular, at the very least, I'd suggest adding a u32 after the PE/COFF header ends, to represent a "RISC-V header format version number". Then if we add more fields that follow the PE/COFF header -- for example, to represent the RISC-V instruction set extensions that are required to run this binary -- we can just bump that RISC-V-specific version number field to indicate to bootloaders that there's more there. One other observation - if what's here was copied from some other architecture, like ARM, please acknowledge the source in the patch description. thanks - Paul
Re: [PATCH 2/2] pinctrl: mediatek: Update cur_mask in mask/mask ops
Quoting Nicolas Boichat (2019-04-28 20:55:15)
> During suspend/resume, mtk_eint_mask may be called while
> wake_mask is active. For example, this happens if a wake-source
> with an active interrupt handler wakes the system:
> irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so
> that it can be handled later on in the resume flow.
>
> However, this may happen before mtk_eint_do_resume is called:
> in this case, wake_mask is loaded, and cur_mask is restored
> from an older copy, re-enabling the interrupt, and causing
> an interrupt storm (especially for level interrupts).
>
> Instead, we just record mask/unmask changes in cur_mask. This
> also avoids the need to read the current mask in eint_do_suspend,
> and we can remove mtk_eint_chip_read_mask function.
>
> Signed-off-by: Nicolas Boichat
It looks an awful lot like you should just use IRQCHIP_MASK_ON_SUSPEND
here. Isn't that what's happening? All non-wake irqs should be masked at
the hardware level so they can't cause a wakeup during suspend and on
resume they can be unmasked?
> diff --git a/drivers/pinctrl/mediatek/mtk-eint.c
> b/drivers/pinctrl/mediatek/mtk-eint.c
> index 737385e86beb807..7e526bcf5e0b55c 100644
> --- a/drivers/pinctrl/mediatek/mtk-eint.c
> +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> @@ -113,6 +113,8 @@ static void mtk_eint_mask(struct irq_data *d)
> void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq,
> eint->regs->mask_set);
>
> + eint->cur_mask[d->hwirq >> 5] &= ~mask;
> +
> writel(mask, reg);
> }
>
> @@ -123,6 +125,8 @@ static void mtk_eint_unmask(struct irq_data *d)
> void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq,
> eint->regs->mask_clr);
>
> + eint->cur_mask[d->hwirq >> 5] |= mask;
> +
> writel(mask, reg);
>
> if (eint->dual_edge[d->hwirq])
> @@ -384,7 +375,6 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
>
> int mtk_eint_do_suspend(struct mtk_eint *eint)
> {
> - mtk_eint_chip_read_mask(eint, eint->base, eint->cur_mask);
> mtk_eint_chip_write_mask(eint, eint->base, eint->wake_mask);
>
This alone looks like, write out the mask to only allow wake interrupts.
Re: [PATCH v3 28/30] coresight: Support for ACPI bindings
On Tue, May 07, 2019 at 11:52:55AM +0100, Suzuki K Poulose wrote:
> Add support for parsing the ACPI platform description
> for CoreSight. The connections are encoded in a DSD graph
> property with CoreSight specific variation of the property.
>
> The ETMs are listed as the children device of the respective
> CPU.
>
> Cc: "Rafael J. Wysocki"
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/hwtracing/coresight/coresight-platform.c | 464
> +++
> 1 file changed, 464 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-platform.c
> b/drivers/hwtracing/coresight/coresight-platform.c
> index 49112a5..6fef873 100644
> --- a/drivers/hwtracing/coresight/coresight-platform.c
> +++ b/drivers/hwtracing/coresight/coresight-platform.c
> @@ -3,6 +3,7 @@
> * Copyright (c) 2012, The Linux Foundation. All rights reserved.
> */
>
> +#include
> #include
> #include
> #include
> @@ -308,10 +309,471 @@ of_get_coresight_platform_data(struct device *dev,
> }
> #endif
>
> +#ifdef CONFIG_ACPI
> +
> +#include
> +#include
> +
> +/* ACPI Graph _DSD UUID : "ab02a46b-74c7-45a2-bd68-f7d344ef2153" */
> +static const guid_t acpi_graph_uuid = GUID_INIT(0xab02a46b, 0x74c7, 0x45a2,
> + 0xbd, 0x68, 0xf7, 0xd3,
> + 0x44, 0xef, 0x21, 0x53);
> +/* Coresight ACPI Graph UUID : "3ecbc8b6-1d0e-4fb3-8107-e627f805c6cd" */
> +static const guid_t coresight_graph_uuid = GUID_INIT(0x3ecbc8b6, 0x1d0e,
> 0x4fb3,
> + 0x81, 0x07, 0xe6, 0x27,
> + 0xf8, 0x05, 0xc6, 0xcd);
> +#define ACPI_CORESIGHT_LINK_SLAVE0
> +#define ACPI_CORESIGHT_LINK_MASTER 1
> +
> +static inline bool is_acpi_guid(const union acpi_object *obj)
> +{
> + return (obj->type == ACPI_TYPE_BUFFER) && (obj->buffer.length == 16);
> +}
> +
> +/*
> + * acpi_guid_matches - Checks if the given object is a GUID object and
> + * that it matches the supplied the GUID.
> + */
> +static inline bool acpi_guid_matches(const union acpi_object *obj,
> +const guid_t *guid)
> +{
> + return is_acpi_guid(obj) &&
> +guid_equal((guid_t *)obj->buffer.pointer, guid);
> +}
> +
> +static inline bool is_acpi_dsd_graph_guid(const union acpi_object *obj)
> +{
> + return acpi_guid_matches(obj, _graph_uuid);
> +}
> +
> +static inline bool is_acpi_coresight_graph_guid(const union acpi_object *obj)
> +{
> + return acpi_guid_matches(obj, _graph_uuid);
> +}
> +
> +static inline bool is_acpi_coresight_graph(const union acpi_object *obj)
> +{
> + const union acpi_object *graphid, *guid, *links;
> +
> + if (obj->type != ACPI_TYPE_PACKAGE ||
> + obj->package.count < 3)
> + return false;
> +
> + graphid = >package.elements[0];
> + guid = >package.elements[1];
> + links = >package.elements[2];
> +
> + if (graphid->type != ACPI_TYPE_INTEGER ||
> + links->type != ACPI_TYPE_INTEGER)
> + return false;
> +
> + return is_acpi_coresight_graph_guid(guid);
> +}
> +
> +/*
> + * acpi_validate_dsd_graph - Make sure the given _DSD graph conforms
> + * to the ACPI _DSD Graph specification.
> + *
> + * ACPI Devices Graph property has the following format:
> + * {
> + * Revision- Integer, must be 0
> + * NumberOfGraphs - Integer, N indicating the following list.
> + * Graph[1],
> + *...
> + * Graph[N]
> + * }
> + *
> + * And each Graph entry has the following format:
> + * {
> + * GraphID - Integer, identifying a graph the device belongs to.
> + * UUID- UUID identifying the specification that governs
> + * this graph. (e.g, see is_acpi_coresight_graph())
> + * NumberOfLinks - Number "N" of connections on this node of the graph.
> + * Links[1]
> + * ...
> + * Links[N]
> + * }
> + *
> + * Where each "Links" entry has the following format:
> + *
> + * {
> + * SourcePortAddress - Integer
> + * DestinationPortAddress - Integer
> + * DestinationDeviceName - Reference to another device
> + * ( --- CoreSight specific extensions below ---)
> + * DirectionOfFlow - Integer 1 for output(master)
> + * 0 for input(slave)
> + * }
> + *
> + * e.g:
> + * For a Funnel device
> + *
> + * Device(MFUN) {
> + * ...
> + *
> + * Name (_DSD, Package() {
> + * // DSD Package contains tuples of { Proeprty_Type_UUID, Package() }
> + * ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), //Std. Property UUID
> + * Package() {
> + * Package(2) { "property-name", }
> + * },
> + *
> + * ToUUID("ab02a46b-74c7-45a2-bd68-f7d344ef2153"), // ACPI Graph UUID
> + * Package() {
> + * 0,// Revision
> + * 1,// NumberOfGraphs.
> + * Package() { // Graph[0] Package
> + *1, // GraphID
Re: [PATCH] lkdtm: support llvm-objcopy
On Mon, May 13, 2019 at 3:21 PM Nick Desaulniers wrote: > > With CONFIG_LKDTM=y and make OBJCOPY=llvm-objcopy, llvm-objcopy errors: > llvm-objcopy: error: --set-section-flags=.text conflicts with > --rename-section=.text=.rodata > > Rather than support setting flags then renaming sections vs renaming > then setting flags, it's simpler to just change both at the same time > via --rename-section. > > This can be verified with: > $ readelf -S drivers/misc/lkdtm/rodata_objcopy.o > ... > Section Headers: > [Nr] Name Type Address Offset >Size EntSize Flags Link Info Align > ... > [ 1] .rodata PROGBITS 0040 >0004 A 0 0 4 > ... > > Which shows in the Flags field that .text is now renamed .rodata, the > append flag A is set, and the section is not flagged as writeable W. Probably should've been: Which shows that .text is now renamed .rodata, the append flag A is set, and the section is not flagged as writeable W. -- Thanks, ~Nick Desaulniers
