[PATCH] ARM: rockchip: disable dapswjdp during suspend
Reset dapswjdp is controlled by JTAG_TRSTN, if the iomux of this pin is not "jtag_trstn". the AP would think this pin is always high, so it can not reset before resume. When system resume, but the dapswjdp is not in a default state, it may Access some illegal address, it cause system crash during resume. Let's disable this jtag function by clear the dapdeviceen bit, it prohibit the dapswjdp to access memory and registers. This bit would be enable in MASKROM, so we need clear it in suspend everytime. Signed-off-by: Chris Zhong --- arch/arm/mach-rockchip/pm.c | 7 +++ arch/arm/mach-rockchip/pm.h | 4 2 files changed, 11 insertions(+) diff --git a/arch/arm/mach-rockchip/pm.c b/arch/arm/mach-rockchip/pm.c index b07d886..b0dcbe2 100644 --- a/arch/arm/mach-rockchip/pm.c +++ b/arch/arm/mach-rockchip/pm.c @@ -83,6 +83,13 @@ static void rk3288_slp_mode_set(int level) SGRF_PCLK_WDT_GATE | SGRF_FAST_BOOT_EN | SGRF_PCLK_WDT_GATE_WRITE | SGRF_FAST_BOOT_EN_WRITE); + /* +* The dapswjdp can not auto reset before resume, that cause it may +* access some illegal address during resume. Let's disable it before +* suspend, and the MASKROM will enable it back. +*/ + regmap_write(sgrf_regmap, RK3288_SGRF_CPU_CON0, SGRF_DAPDEVICEEN_WRITE); + /* booting address of resuming system is from this register value */ regmap_write(sgrf_regmap, RK3288_SGRF_FAST_BOOT_ADDR, rk3288_bootram_phy); diff --git a/arch/arm/mach-rockchip/pm.h b/arch/arm/mach-rockchip/pm.h index 03ff31d..3e8d39c 100644 --- a/arch/arm/mach-rockchip/pm.h +++ b/arch/arm/mach-rockchip/pm.h @@ -55,6 +55,10 @@ static inline void rockchip_suspend_init(void) #define SGRF_FAST_BOOT_EN BIT(8) #define SGRF_FAST_BOOT_EN_WRITEBIT(24) +#define RK3288_SGRF_CPU_CON0 (0x40) +#define SGRF_DAPDEVICEEN BIT(0) +#define SGRF_DAPDEVICEEN_WRITE BIT(16) + #define RK3288_CRU_MODE_CON0x50 #define RK3288_CRU_SEL0_CON0x60 #define RK3288_CRU_SEL1_CON0x64 -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/kconfig/Makefile: Fix spelling of Qt
Thanks, that gives me hope, I'll wait patiently then. BTW, if you want any reference for how this is written, see this: http://en.wikipedia.org/wiki/Qt_%28software%29 Thanks, Diego On Wed, Apr 15, 2015 at 2:36 AM, Jiri Kosina wrote: > On Wed, 15 Apr 2015, Diego Viola wrote: > >> I apologize for being impatient, but I sent my first patch a week ago >> and then I sent another after a week. >> >> I realize the patch is trivial, but I still want to see it merged >> regardless, and this is my first contribution to the mailing list, so >> I apologize for any inconvenience. >> >> I thought my patch was being ignored and I didn't want to see it lost >> with all the other emails/patches so I thought about resending it. >> >> Should I send it again after a week if this one is ignored? > > It's very trivial patch indeed, and that's exactly why it's not on the top > of the TODO list of everybody on CC. > > Plus we are just now in the middle of merge window, which is exactly the > time when everyone is focusing on merging with Linus, and postpones even > looking at patches which are not urgent bugfixes. > > Don't worry about us not seeing your endless stream of pings about this > typo. We are rather good in not losing e-mails, and you are trying really > hard not to be overlooked. > > Patience is a virtue. > > -- > Jiri Kosina > SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On 04/15/2015 08:57 AM, Dave Young wrote: Again, I think it is bad to use old page table, below issues need consider: 1) make sure old page table are reliable across crash 2) do not allow writing oldmem after crash Please correct me if I'm wrong, or if above is not doable I think I will vote for resetting pci bus. Thanks Dave Hi Dave, When updating the context tables, we have to write their address to root tables, this will cause writing to old mem. Resetting the pci bus has been discussed, please check this: http://lists.infradead.org/pipermail/kexec/2014-October/012752.html https://lkml.org/lkml/2014/10/21/890 Thanks Zhenhua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next 1/4] infiniband/ipoib: fix possible NULL pointer dereference in ipoib_get_iflink
On 4/14/2015 11:41 PM, Jason Gunthorpe wrote: Erez, you basically rewrote this, please make a proper patch with the Fixes and Reported-By credit for Honggang. Lets merge this through Dave M's tree right away. Agree, Erez, add proper Fixes: XXX note and send a patch to netdev against net-next. No need for the lengthy crash dump there. Nicolas, next time you patch IPoIB, please cc linux-rdma. Or. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dmaengine: imx-sdma: Add DMA event remapping for imx6sx-sdma
The SDMA on imx6sx has a few DMA event remapping configurations
inside the GPR (General Purpose Register) of that SoC. When users
want to use a non-default DMA event, they need to configure the
GPR register. So this patch gives an interface of the GPR and
implements it in the SDMA driver so as to finish the DMA event
remapping.
Signed-off-by: Nicolin Chen
---
.../devicetree/bindings/dma/fsl-imx-sdma.txt | 9
drivers/dma/imx-sdma.c | 58 ++
2 files changed, 67 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index dc8d3aa..03315a6 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -8,6 +8,7 @@ Required properties:
"fsl,imx51-sdma"
"fsl,imx53-sdma"
"fsl,imx6q-sdma"
+ "fsl,imx6sx-sdma"
The -to variants should be preferred since they allow to determine the
correct ROM script addresses needed for the driver to work without additional
firmware.
@@ -19,6 +20,14 @@ Required properties:
- fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
scripts firmware
+Optional properties:
+- fsl, sdma-event-remap : List of one or more DMA event remapping
+ configurations. Its format: < addr shift val>
+ gpr : the gpr phandle
+ addr : the register address of the GPR
+ shift : the bit shift of the GPR register
+ val : the value of that bit
+
The second cell of dma phandle specifies the peripheral type of DMA transfer.
The full ID of peripheral types can be found below.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 62bbd79..f0339ab 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -39,6 +40,7 @@
#include
#include
+#include
#include
#include
@@ -440,12 +442,16 @@ static struct platform_device_id sdma_devtypes[] = {
.name = "imx6q-sdma",
.driver_data = (unsigned long)_imx6q,
}, {
+ .name = "imx6sx-sdma",
+ .driver_data = (unsigned long)_imx6q,
+ }, {
/* sentinel */
}
};
MODULE_DEVICE_TABLE(platform, sdma_devtypes);
static const struct of_device_id sdma_dt_ids[] = {
+ { .compatible = "fsl,imx6sx-sdma", .data = _imx6q, },
{ .compatible = "fsl,imx6q-sdma", .data = _imx6q, },
{ .compatible = "fsl,imx53-sdma", .data = _imx53, },
{ .compatible = "fsl,imx51-sdma", .data = _imx51, },
@@ -1337,6 +1343,54 @@ err_firmware:
release_firmware(fw);
}
+static int sdma_event_remap(struct sdma_engine *sdma)
+{
+ struct device_node *np = sdma->dev->of_node;
+ char propname[] = "fsl,sdma-event-remap";
+ struct of_phandle_args gpr_spec;
+ struct regmap *gpr;
+ int i = 0, ret = 0;
+
+ /* Only support DT */
+ if (IS_ERR(np))
+ return ret;
+
+ /* Only apply to imx6sx platform */
+ if (!of_device_is_compatible(np, "fsl,imx6sx-sdma"))
+ return ret;
+
+ /* Bypass if no need to remap */
+ if (!of_find_property(np, propname, NULL))
+ return ret;
+
+ /* Fetch the remap configurations of GPR */
+ ret = of_parse_phandle_with_args(np, propname, "#gpr-cells", i++,
+_spec);
+ if (ret) {
+ dev_err(sdma->dev, "failed to get a correct %s property: %d\n",
+ propname, ret);
+ return ret;
+ }
+
+next:
+ gpr = syscon_node_to_regmap(gpr_spec.np);
+ if (IS_ERR(gpr)) {
+ ret = PTR_ERR(gpr);
+ dev_err(sdma->dev, "failed to get gpr regmap: %d\n", reg);
+ return ret;
+ }
+
+ /* 0 : Register address, 1 : Bit shift, 2 : Bit value */
+ regmap_update_bits(gpr, gpr_spec.args[0], BIT(gpr_spec.args[1]),
+ gpr_spec.args[2] << gpr_spec.args[1]);
+
+ if (!of_parse_phandle_with_args(np, propname, "#gpr-cells", i++,
+ _spec))
+ goto next;
+
+ return ret;
+}
+
static int sdma_get_firmware(struct sdma_engine *sdma,
const char *fw_name)
{
@@ -1551,6 +1605,10 @@ static int sdma_probe(struct platform_device *pdev)
if (ret)
goto err_init;
+ ret = sdma_event_remap(sdma);
+ if (ret)
+ goto err_init;
+
if (sdma->drvdata->script_addrs)
sdma_add_scripts(sdma, sdma->drvdata->script_addrs);
if (pdata && pdata->script_addrs)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH] scripts/kconfig/Makefile: Fix spelling of Qt
On Wed, 15 Apr 2015, Diego Viola wrote: > I apologize for being impatient, but I sent my first patch a week ago > and then I sent another after a week. > > I realize the patch is trivial, but I still want to see it merged > regardless, and this is my first contribution to the mailing list, so > I apologize for any inconvenience. > > I thought my patch was being ignored and I didn't want to see it lost > with all the other emails/patches so I thought about resending it. > > Should I send it again after a week if this one is ignored? It's very trivial patch indeed, and that's exactly why it's not on the top of the TODO list of everybody on CC. Plus we are just now in the middle of merge window, which is exactly the time when everyone is focusing on merging with Linus, and postpones even looking at patches which are not urgent bugfixes. Don't worry about us not seeing your endless stream of pings about this typo. We are rather good in not losing e-mails, and you are trying really hard not to be overlooked. Patience is a virtue. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] iio: ti_am335x_adc: Add optional DT properties for tscadc
> Hi Hannes, Hi Vignesh, thanks for answer. > >> > >> would it be possible to add some more channel-specific settings ? > >> > >> It would be nice to have allmost full control to the STEPCONFIGx > > register. > >> > >> At least we need to write the bits > >> > >> SEL_RFM_SWC_1_0 > >> SEL_INM_SWC_3_0 > >> SEL_RFP_SWC_2_0 > >> > >> In the current mainline version only (SEL_INP_SWC_3_0) is written. > >> So for the other bits "0" is value is used, for my point of view this is > > not correct. > >> > >> For example if we want to read a value from AIN5 the negative pin from > > adc is > >> muxed allways to AIN0. > > Sorry... I didn't understand what you meant by"AIN5 is muxed always with > AIN0"? Have a look to the TRM (spruh73k.pdf) Page 1740 / Figure 12-2. Functional Block Diagram. There you can see that the ADC-cell which has two inputs, one positive and one negative. Also there are two reference inputs, one positive - one negative. All this "pins" are muxed, because only one channel per time can be sampled. This muxes are controlled through the STEPCONFIGx registers. If you want for example take some measurement from AIN5 the driver muxes the positive input from the ADC to AIN5 by setting the bits for SEL_INP<3:0> - this is ok. But the bits for SEL_INM<3:0> are still 'zero'. In summary this results in following mux-setting (regarding page 1771 in TRM): positive-reference muxed to VDDA negative-reference muxed to VSSA positive-input muxed to AIN5 negative-input muxed to AIN0 >From this setup we run into 2 problems: - the negative input terminal is muxed maybe to wrong potential In much cases we have a single-ended signal so this setup looks good at first, because the "Diff_CNTRL" bit is also false. In fact there is an influence to the reading if the negative input-terminal isn't setup correctly (to VSSA or REFN). Maybe i interpret the "Diff_CNTRL" not correctly, there is no detailed description within the TRM - maybe some of your workmates can explain you the functionality of this bit. - reference is allways taken from VDDA/VSSA For a precision measurement you dont't use in normal case the analog-supply. This rail brings noise, drift - all things whicht we don't need for accurate measurement. > > >> In fact i can readout heavy jitter even if AIN5 is connected to ground - > > after > >> setting up negative adc pin within code (to use REFN) the readout value > > is 0 > >> as expected without nameable jitter. > >> If i short AIN0 also to ground, jitter is also eliminated. > > Hmmm... nobody has reported such behavior before. ADC support for > am335x-evm/beaglebone has been there for quite long time, but nobody > reported any jitter on AIN5 line. I think this may be specific to > your setup. Can you provide more info with regard to your setup? > Which kernel? Is it am335x-evm or beaglebone or a custom board? Maybe nobody does some precision measurement with beaglebone. For operating some touchscreen or readout a potentiometer for evaluation purpose it is still good enough. Kernel is current mainline, 4.0 Board is some custom board of my company. But all this parameters shouldn't have some influence to the case. > >> > >> Maybe this is also some fault of TI SoC ... in normal case somebody > > could > >> expect, that negative adc pin is equal even the Diff_CNTRL bit isn't set > > - but > >> in practice it isn't. > >> > >> Also actually it isn't possible to make some accurate measurement due to > > the > >> fact that allways VDDA_ADC is used as positive reference. > >> > >> So it would be nice to have control around this bits. > >> Whats your opinion around that? > > Sorry, I am not yet clear on your bug/use-case. > > Please comment inline while replying on mailing list okay so ? > Regards > Vignesh best regards, Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] uio: pruss: Drop depends on ARCH_DAVINCI_DA850 from config
> From: Matwey V. Kornilov [mailto:matwey.korni...@gmail.com] > mach-dependent stuff has been removed by > 2eb2478d471e45e1d0c8bb3defbf82bf7204e13d > So, there is no need to keep > depends on ARCH_DAVINCI_DA850 > > Signed-off-by: Matwey V. Kornilov > --- > drivers/uio/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 8a15c32..9c9178a > 100644 > --- a/drivers/uio/Kconfig > +++ b/drivers/uio/Kconfig > @@ -126,7 +126,6 @@ config UIO_FSL_ELBC_GPCM_NETX5152 > > config UIO_PRUSS > tristate "Texas Instruments PRUSS driver" > - depends on ARCH_DAVINCI_DA850 > select GENERIC_ALLOCATOR > help > PRUSS driver for OMAPL138/DA850/AM18XX devices Acked-by: Pratheesh Gangadhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next v3] mlx5: wrong page mask if CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for 32Bit architectures
Acked-by: Eli Cohen
On Wed, Apr 15, 2015 at 11:19:17AM +0800, Honggang Li wrote:
> If CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for x86 systems and physical
> memory is more than 4GB, dma_map_page may return a valid memory
> address which greater than 0x. As a result, the mlx5 device page
> allocator RB tree will be initialized with valid addresses greater than
> 0xfff.
>
> However, (addr & PAGE_MASK) set the high four bytes to zeros. So, it's
> impossible for the function, free_4k, to release the pages whose
> addresses greater than 4GB. Memory leaks. And mlx5_ib module can't
> release the pages when user try to remove the module, as a result,
> system hang.
>
> [root@rdma05 root]# dmesg | grep addr | head
> addr = 3fe384000
> addr & PAGE_MASK = fe384000
> [root@rdma05 root]# rmmod mlx5_ib < hang on
>
> -- cosnole log -
> mlx5_ib :04:00.0: irq 138 for MSI/MSI-X
> alloc irq_desc for 139 on node -1
> alloc kstat_irqs on node -1
> mlx5_ib :04:00.0: irq 139 for MSI/MSI-X
> :04:00.0:free_4k:221:(pid 1519): page not found
> :04:00.0:free_4k:221:(pid 1519): page not found
> :04:00.0:free_4k:221:(pid 1519): page not found
> :04:00.0:free_4k:221:(pid 1519): page not found
> -- cosnole log -
>
> Fix(bf0bf77 mlx5: Support communicating arbitrary host page size to
> firmware)
>
> Signed-off-by: Honggang Li
> ---
> .../net/ethernet/mellanox/mlx5/core/pagealloc.c| 10 ++
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
> b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
> index df22383..8a64542 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
> @@ -211,26 +211,28 @@ static int alloc_4k(struct mlx5_core_dev *dev, u64
> *addr)
> return 0;
> }
>
> +#define MLX5_U64_4K_PAGE_MASK ((~(u64)0U) << PAGE_SHIFT)
> +
> static void free_4k(struct mlx5_core_dev *dev, u64 addr)
> {
> struct fw_page *fwp;
> int n;
>
> - fwp = find_fw_page(dev, addr & PAGE_MASK);
> + fwp = find_fw_page(dev, addr & MLX5_U64_4K_PAGE_MASK);
> if (!fwp) {
> mlx5_core_warn(dev, "page not found\n");
> return;
> }
>
> - n = (addr & ~PAGE_MASK) >> MLX5_ADAPTER_PAGE_SHIFT;
> + n = (addr & ~MLX5_U64_4K_PAGE_MASK) >> MLX5_ADAPTER_PAGE_SHIFT;
> fwp->free_count++;
> set_bit(n, >bitmask);
> if (fwp->free_count == MLX5_NUM_4K_IN_PAGE) {
> rb_erase(>rb_node, >priv.page_root);
> if (fwp->free_count != 1)
> list_del(>list);
> - dma_unmap_page(>pdev->dev, addr & PAGE_MASK, PAGE_SIZE,
> -DMA_BIDIRECTIONAL);
> + dma_unmap_page(>pdev->dev, addr & MLX5_U64_4K_PAGE_MASK,
> +PAGE_SIZE, DMA_BIDIRECTIONAL);
> __free_page(fwp->page);
> kfree(fwp);
> } else if (fwp->free_count == 1) {
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the xen-tip tree
Hi all,
On Mon, 13 Apr 2015 16:36:58 +0800 Bob Liu wrote:
>
> On 04/13/2015 04:09 PM, Stephen Rothwell wrote:
> >
> > After merging the xen-tip tree, today's linux-next build (x86_64
> > allmodconfig)
> > failed like this:
> >
> > drivers/char/tpm/xen-tpmfront.c: In function 'setup_ring':
> > drivers/char/tpm/xen-tpmfront.c:203:7: warning: passing argument 2 of
> > 'xenbus_grant_ring' makes pointer from integer without a cast
> >rv = xenbus_grant_ring(dev, virt_to_mfn(priv->shr));
> > ^
> > In file included from drivers/char/tpm/xen-tpmfront.c:17:0:
> > include/xen/xenbus.h:206:5: note: expected 'void *' but argument is of type
> > 'long unsigned int'
> > int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
> > ^
> > drivers/char/tpm/xen-tpmfront.c:203:7: error: too few arguments to function
> > 'xenbus_grant_ring'
> >rv = xenbus_grant_ring(dev, virt_to_mfn(priv->shr));
> > ^
> > In file included from drivers/char/tpm/xen-tpmfront.c:17:0:
> > include/xen/xenbus.h:206:5: note: declared here
> > int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
> > ^
> >
> > Caused by commit 1b1586eeeb8c ("xenbus_client: Extend interface to
> > support multi-page ring").
> >
> > I have used the xen-tip tree from next-20150410 for today.
> >
>
> Sorry for this issue, I missed the xentpm-front.c file in that patch.
> (Original patch from Wei Liu already included the right modification
> which didn't exist in Paul's.)
>
> Attached patch should fix this build failure.
I am still getting this failure :-(
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpQyDRc5Hf36.pgp
Description: OpenPGP digital signature
[PATCH] fs/file.c: remove useless xchg and NULL check in close_files
Since the table is about to be freed, there is no reason to set file
pointer to NULL on closing.
At this point open_fd map is supposed to indicate whether a file is
installed, so NULL-checking it is unnecessary.
Signed-off-by: Mateusz Guzik
---
fs/file.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index 93c5f89..35a024a 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -364,11 +364,8 @@ static struct fdtable *close_files(struct files_struct *
files)
set = fdt->open_fds[j++];
while (set) {
if (set & 1) {
- struct file * file = xchg(>fd[i], NULL);
- if (file) {
- filp_close(file, files);
- cond_resched_rcu_qs();
- }
+ filp_close(fdt->fd[i], files);
+ cond_resched_rcu_qs();
}
i++;
set >>= 1;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/10] latched RB-trees and __module_address()
Peter Zijlstra writes: > On Tue, Apr 14, 2015 at 12:27:05PM +0930, Rusty Russell wrote: > >> I was tempted to sneak in those module rcu fixes for 4.1, but seeing >> Ingo's comments I'll wait for 4.2. > > I can get you a new version of that if you want. See below. The fixups > are unmodified of the posting (patches 2,3). Another last-minute module-next patch just blew up some archs, so I'm erring back to being conservative :) I've put those three patches (2,3,1 for bisectability) into my pending-rebases tree for now. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
Hi Dave,
On Wed, 15 Apr 2015 00:16:50 -0400 (EDT) David Miller
wrote:
>
> The first has to do with Stephen Rothwells movement of trace entries
> into individual files while meanwhile the wireless folks were adding
> new ones or changing the signature of existing ones.
Umm, it wasn't me moving stuff, I just coped :-)
> For net/mac80211/trace.h, keep the hunk that adds the
> drv_wake_tx_queue trace event. Then remove the hunk from "#ifdef
> CONFIG_MAC80211_MESSAGE_TRACING" until the "#endif" closing that
> ifdef.
>
> For drivers/net/wireless/iwlwifi/iwl-devtrace.h, take the trace entry
> definition for iwlwifi_dev_ucode_error from my tree and use it to replace
> what is in drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h Then
> remove everything else in the conflict section of iwl-devtrace.h
or for drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h, apply this:
diff --git a/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
b/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
index 6cb66a988271..223b8752f924 100644
--- a/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
+++ b/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
@@ -116,11 +116,11 @@ TRACE_EVENT(iwlwifi_dev_ucode_error,
TP_PROTO(const struct device *dev, u32 desc, u32 tsf_low,
u32 data1, u32 data2, u32 line, u32 blink1,
u32 blink2, u32 ilink1, u32 ilink2, u32 bcon_time,
-u32 gp1, u32 gp2, u32 gp3, u32 ucode_ver, u32 hw_ver,
+u32 gp1, u32 gp2, u32 gp3, u32 major, u32 minor, u32 hw_ver,
u32 brd_ver),
TP_ARGS(dev, desc, tsf_low, data1, data2, line,
blink1, blink2, ilink1, ilink2, bcon_time, gp1, gp2,
- gp3, ucode_ver, hw_ver, brd_ver),
+ gp3, major, minor, hw_ver, brd_ver),
TP_STRUCT__entry(
DEV_ENTRY
__field(u32, desc)
@@ -136,7 +136,8 @@ TRACE_EVENT(iwlwifi_dev_ucode_error,
__field(u32, gp1)
__field(u32, gp2)
__field(u32, gp3)
- __field(u32, ucode_ver)
+ __field(u32, major)
+ __field(u32, minor)
__field(u32, hw_ver)
__field(u32, brd_ver)
),
@@ -155,21 +156,22 @@ TRACE_EVENT(iwlwifi_dev_ucode_error,
__entry->gp1 = gp1;
__entry->gp2 = gp2;
__entry->gp3 = gp3;
- __entry->ucode_ver = ucode_ver;
+ __entry->major = major;
+ __entry->minor = minor;
__entry->hw_ver = hw_ver;
__entry->brd_ver = brd_ver;
),
TP_printk("[%s] #%02d %010u data 0x%08X 0x%08X line %u, "
"blink 0x%05X 0x%05X ilink 0x%05X 0x%05X "
- "bcon_tm %010u gp 0x%08X 0x%08X 0x%08X uCode 0x%08X "
- "hw 0x%08X brd 0x%08X",
+ "bcon_tm %010u gp 0x%08X 0x%08X 0x%08X major 0x%08X "
+ "minor 0x%08X hw 0x%08X brd 0x%08X",
__get_str(dev), __entry->desc, __entry->tsf_low,
__entry->data1,
__entry->data2, __entry->line, __entry->blink1,
__entry->blink2, __entry->ilink1, __entry->ilink2,
__entry->bcon_time, __entry->gp1, __entry->gp2,
- __entry->gp3, __entry->ucode_ver, __entry->hw_ver,
- __entry->brd_ver)
+ __entry->gp3, __entry->major, __entry->minor,
+ __entry->hw_ver, __entry->brd_ver)
);
TRACE_EVENT(iwlwifi_dev_ucode_event,
> The second set of conflicts have to do with BPF stuff.
>
> samples/bpf/Makefile - Trivial, overlapping additions.
> include/uapi/linux/bpf.h - Likewise.
>
> In kernel/events/core.c you'll have to change "prog->aux->prog_type"
> into "prog->type".
i.e. apply this:
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 06917d537302..81aa3a4ece9f 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6729,7 +6729,7 @@ static int perf_event_set_bpf_prog(struct perf_event
*event, u32 prog_fd)
if (IS_ERR(prog))
return PTR_ERR(prog);
- if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
+ if (prog->type != BPF_PROG_TYPE_KPROBE) {
/* valid fd, but invalid bpf program type */
bpf_prog_put(prog);
return -EINVAL;
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpDWQMnhB_14.pgp
Description: OpenPGP digital signature
Re: [PATCH] scripts/kconfig/Makefile: Fix spelling of Qt
I apologize for being impatient, but I sent my first patch a week ago and then I sent another after a week. I realize the patch is trivial, but I still want to see it merged regardless, and this is my first contribution to the mailing list, so I apologize for any inconvenience. I thought my patch was being ignored and I didn't want to see it lost with all the other emails/patches so I thought about resending it. Should I send it again after a week if this one is ignored? Thanks, Diego On Mon, Apr 13, 2015 at 5:14 AM, Paul Bolle wrote: > On Sun, 2015-04-12 at 22:24 -0300, Diego Viola wrote: >> Ping? > > Two pings within minutes? > >> On Sun, Apr 12, 2015 at 10:22 PM, Diego Viola wrote: >> > Ping? > > The patch is trivial. Handling trivial patches might take some time. > Please show some patience. And, if MAINTAINERS is to be believed, you > should have put something like "[TRIVIAL]" somewhere in the subject > line. Perhaps that's why Jiri is silent. > > (You sent at least three versions of this patch within a week. Why did > you do that? And, no, you shouldn't resend directly with a proper > Subject: line. Wait a week or two first.) > > Thanks, > > > Paul Bolle > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables
On Fri, Apr 3, 2015 at 2:36 AM, Ivan.khoronzhuk
wrote:
>
>
> On 02.04.15 15:57, Ivan Khoronzhuk wrote:
>>
>> Some utils, like dmidecode and smbios, need to access SMBIOS entry
>> table area in order to get information like SMBIOS version, size, etc.
>> Currently it's done via /dev/mem. But for situation when /dev/mem
>> usage is disabled, the utils have to use dmi sysfs instead, which
>> doesn't represent SMBIOS entry and adds code/delay redundancy when direct
>> access for table is needed.
>>
>> So this patch creates dmi/tables and adds SMBIOS entry point to allow
>> utils in question to work correctly without /dev/mem. Also patch adds
>> raw dmi table to simplify dmi table processing in user space, as
>> proposed by Jean Delvare.
>>
I have made modifications to dmidecode to support this interface, and it
works quite nicely for dmidecode. (changes posted to dmidecode-devel list)
The only open issue I am aware of is how the SMBIOS v3 entry point
will be handled,
especially in cases where there is a v2 and a v3 entry point.
In principal I think this a good change - are there any other open issues?
Thanks,
Roy
>> Signed-off-by: Ivan Khoronzhuk
>> ---
>> .../ABI/testing/sysfs-firmware-dmi-tables | 22 ++
>> drivers/firmware/dmi-sysfs.c | 11 ++-
>> drivers/firmware/dmi_scan.c| 80
>> ++
>> include/linux/dmi.h| 1 +
>> 4 files changed, 107 insertions(+), 7 deletions(-)
>> create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables
>>
>> diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables
>> b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
>> new file mode 100644
>> index 000..f46158c
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
>> @@ -0,0 +1,22 @@
>> +What: /sys/firmware/dmi/tables/
>> +Date: April 2015
>> +Contact: Ivan Khoronzhuk
>> +Description:
>> + The firmware provides DMI structures as a packed list of
>> + data referenced by a SMBIOS table entry point. The SMBIOS
>> + entry point contains general information, like SMBIOS
>> + version, DMI table size, etc. The structure, content and
>> + size of SMBIOS entry point is dependent on SMBIOS version.
>> + The format of SMBIOS entry point, equal as DMI structures
>> + can be read in SMBIOS specification.
>> +
>> + The dmi/tables provides raw SMBIOS entry point and DMI
>> tables
>> + through sysfs as an alternative to utilities reading them
>> + from /dev/mem. The raw SMBIOS entry point and DMI table
>> are
>> + presented as raw attributes and are accessible via:
>> +
>> + /sys/firmware/dmi/tables/smbios_entry_point
>> + /sys/firmware/dmi/tables/DMI
>> +
>> + The complete DMI information can be taken using these two
>> + tables.
>> diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
>> index e0f1cb3..8e1a411 100644
>> --- a/drivers/firmware/dmi-sysfs.c
>> +++ b/drivers/firmware/dmi-sysfs.c
>> @@ -566,7 +566,6 @@ static struct kobj_type dmi_sysfs_entry_ktype = {
>> .default_attrs = dmi_sysfs_entry_attrs,
>> };
>> -static struct kobject *dmi_kobj;
>> static struct kset *dmi_kset;
>> /* Global count of all instances seen. Only for setup */
>> @@ -651,10 +650,11 @@ static int __init dmi_sysfs_init(void)
>> int error = -ENOMEM;
>> int val;
>> - /* Set up our directory */
>> - dmi_kobj = kobject_create_and_add("dmi", firmware_kobj);
>> - if (!dmi_kobj)
>> + if (!dmi_kobj) {
>> + pr_err("dmi-sysfs: dmi entry is absent.\n");
>> + error = -ENOSYS;
>> goto err;
>> + }
>> dmi_kset = kset_create_and_add("entries", NULL, dmi_kobj);
>> if (!dmi_kset)
>> @@ -675,7 +675,6 @@ static int __init dmi_sysfs_init(void)
>> err:
>> cleanup_entry_list();
>> kset_unregister(dmi_kset);
>> - kobject_put(dmi_kobj);
>> return error;
>> }
>> @@ -685,8 +684,6 @@ static void __exit dmi_sysfs_exit(void)
>> pr_debug("dmi-sysfs: unloading.\n");
>> cleanup_entry_list();
>> kset_unregister(dmi_kset);
>> - kobject_del(dmi_kobj);
>> - kobject_put(dmi_kobj);
>> }
>> module_init(dmi_sysfs_init);
>> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
>> index d3aae09..bb19f8b 100644
>> --- a/drivers/firmware/dmi_scan.c
>> +++ b/drivers/firmware/dmi_scan.c
>> @@ -10,6 +10,9 @@
>> #include
>> #include
>> +struct kobject *dmi_kobj;
>> +EXPORT_SYMBOL_GPL(dmi_kobj);
>> +
>> /*
>>* DMI stands for "Desktop Management Interface". It is part
>>* of and an antecedent to, SMBIOS, which stands for System
>> @@ -20,6 +23,9 @@ static
Re: [GIT PULL] RCU changes for v4.1
On Tue, Apr 14, 2015 at 08:19:57PM -0700, Linus Torvalds wrote: > On Tue, Apr 14, 2015 at 7:55 PM, Paul E. McKenney > wrote: > > > > Does the (currently being tested) patch below fix things up? If not, > > please fill me in on the further error of my ways. > > Looks ok. > > That said, couldn't that last dummy gp_init_delay variable: > > > +/* Delay in jiffies for grace-period initialization delays, debug only. */ > > +#ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT > > +static int gp_init_delay = CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY; > > module_param(gp_init_delay, int, 0644); > > +#else /* #ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT */ > > +static const int gp_init_delay; > > +#endif /* #else #ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT */ > > be just a > > #define gp_init_delay 0 > > for the non-CONFIG_RCU_TORTURE_TEST_SLOW_INIT case, so that the code > that then does > > + if (gp_init_delay > 0 && > + !(rsp->gpnum % (rcu_num_nodes * PER_RCU_NODE_PERIOD))) > > would just trivially compile away. > > I guess the compiler *might* see a 'static const int' that is never > touched and realize it's always zero, but it's not obvious that will > be the case. Well, if I attempt to modify gp_init_delay in its const guise, for example, using gp_init_delay++, I get the following: /media/homes/git/linux-2.6-tip/kernel/rcu/tree.c: In function ‘rcu_gp_init’: /media/homes/git/linux-2.6-tip/kernel/rcu/tree.c:1849:3: error: increment of read-only variable ‘gp_init_delay’ make[2]: *** [kernel/rcu/tree.o] Error 1 make[1]: *** [kernel/rcu/tree.o] Error 2 make[1]: Leaving directory `/tmp/b' make: *** [sub-make] Error 2 So the compiler knows that it cannot change. And if I compile with CONFIG_RCU_TORTURE_TEST_SLOW_INIT=y, then: $ nm /tmp/b/kernel/rcu/tree.o | grep gp_init_delay 0060 r __param_gp_init_delay 00e3 r __param_str_gp_init_delay 0444 d gp_init_delay On the other hand, compiling with CONFIG_RCU_TORTURE_TEST_SLOW_INIT=n results in: $ nm /tmp/b/kernel/rcu/tree.o | grep gp_init_delay So the compiler isn't creating a variable in the const case. >From what I can see, at -O1 or better, gcc optimizes the const variable away. At -O0, gcc allocates space for it and actually tests it. But if you prefer #define, not a problem. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm tree with the v4l-dvb tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
include/uapi/linux/media-bus-format.h between commits 7b0fd4568bee
("[media] v4l: Add RBG and RGB 8:8:8 media bus formats on 24 and 32 bit
busses"), e8b2d7a565ae ("[media] v4l: Sort YUV formats of
v4l2_mbus_pixelcode") and 2dca0551e4e2 ("[media] v4l: Add VUY8 24 bits
bus format") from the v4l-dvb tree and commits 4b3a81a917a5 ("Add
RGB444_1X12 and RGB565_1X16 media bus formats"), b295c22978b8 ("Add
LVDS RGB media bus formats"), 08c38458be7e ("Add BGR888_1X24 and
GBR888_1X24 media bus formats") and 203508ef52e3 ("Add
RGB666_1X24_CPADHI media bus format") from the drm tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
(what a mess :-()
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/uapi/linux/media-bus-format.h
index d391893064a0,83ea46f4be51..
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@@ -43,12 -45,16 +45,18 @@@
#define MEDIA_BUS_FMT_RGB565_2X8_BE 0x1007
#define MEDIA_BUS_FMT_RGB565_2X8_LE 0x1008
#define MEDIA_BUS_FMT_RGB666_1X18 0x1009
+#define MEDIA_BUS_FMT_RBG888_1X24 0x100e
+ #define MEDIA_BUS_FMT_RGB666_1X24_CPADHI 0x1015
+ #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG 0x1010
+ #define MEDIA_BUS_FMT_BGR888_1X24 0x1013
+ #define MEDIA_BUS_FMT_GBR888_1X24 0x1014
#define MEDIA_BUS_FMT_RGB888_1X24 0x100a
#define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b
#define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c
+ #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG 0x1011
+ #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012
#define MEDIA_BUS_FMT_ARGB_1X32 0x100d
+#define MEDIA_BUS_FMT_RGB888_1X32_PADHI 0x100f
/* YUV (including grey) - next is 0x2025 */
#define MEDIA_BUS_FMT_Y8_1X8 0x2001
@@@ -80,7 -82,13 +88,8 @@@
#define MEDIA_BUS_FMT_VYUY10_1X20 0x201b
#define MEDIA_BUS_FMT_YUYV10_1X20 0x200d
#define MEDIA_BUS_FMT_YVYU10_1X20 0x200e
+ #define MEDIA_BUS_FMT_YUV8_1X24 0x2024
-#define MEDIA_BUS_FMT_YUV10_1X30 0x2016
-#define MEDIA_BUS_FMT_AYUV8_1X32 0x2017
-#define MEDIA_BUS_FMT_UYVY12_2X12 0x201c
-#define MEDIA_BUS_FMT_VYUY12_2X12 0x201d
-#define MEDIA_BUS_FMT_YUYV12_2X12 0x201e
-#define MEDIA_BUS_FMT_YVYU12_2X12 0x201f
+#define MEDIA_BUS_FMT_VUY8_1X24 0x2024
#define MEDIA_BUS_FMT_UYVY12_1X24 0x2020
#define MEDIA_BUS_FMT_VYUY12_1X24 0x2021
#define MEDIA_BUS_FMT_YUYV12_1X24 0x2022
pgpgAETM4NarS.pgp
Description: OpenPGP digital signature
Crypto Update for 4.1
Hi Linus:
Here is the crypto update for 4.1:
* Added user-space interface for AEAD.
* Added user-space interface for RNG (i.e., pseudo RNG).
* Prevent internal helper algos from being exposed to user-space.
* Merged common code from assembly/C SHA implementations .
* Added ARMv8 SHA1/256.
* Added ARMv8 AES.
* Added ARMv8 GHASH.
* Added ARM assmelber and NEON SHA256.
* Added MIPS OCTEON SHA1/256/512.
* Added MIPS img-hash SHA1/256 and MD5.
* Added Power 8 VMX AES/CBC/CTR/GHASH.
* Added PPC assembler AES, SHA1/256 and MD5.
* Added Broadcom IPROC RNG driver.
* Misc fixes.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
Aaro Koskinen (7):
crypto: octeon - don't disable bottom half in octeon-md5
crypto: octeon - always disable preemption when using crypto engine
crypto: octeon - add instruction definitions for SHA1/256/512
crypto: octeon - add SHA1 module
crypto: octeon - add SHA256 module
crypto: octeon - add SHA512 module
crypto: octeon - enable OCTEON SHA1/256/512 module selection
Allan, Bruce W (10):
crypto: qat - remove duplicate definition of Intel PCI vendor id
crypto: qat - fix typo in string
crypto: qat - make error and info log messages more descriptive
crypto: qat - fix typo
crypto: qat - fix checkpatch CHECK_SPACING issues
crypto: qat - checkpatch PARENTHESIS_ALIGNMENT and LOGICAL_CONTINUATIONS
crypto: qat - fix checkpatch CONCATENATED_STRING issues
crypto: qat - fix checkpatch BIT_MACRO issues
crypto: qat - fix checkpatch COMPARISON_TO_NULL issue
crypto: qat - fix checkpatch CODE_INDENT issue
Ameen Ali (1):
crypto: sha1-mb - Syntax error
Andre Wolokita (2):
hwrng: omap - Change RNG_CONFIG_REG to RNG_CONTROL_REG when checking and
disabling TRNG
hwrng: omap - Change RNG_CONFIG_REG to RNG_CONTROL_REG in init
Ard Biesheuvel (23):
crypto: arm - move ARM specific Kconfig definitions to a dedicated file
crypto: arm - add support for SHA1 using ARMv8 Crypto Instructions
crypto: arm - add support for SHA-224/256 using ARMv8 Crypto Extensions
crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions
crypto: arm - add support for GHASH using ARMv8 Crypto Extensions
crypto: arm/ghash - fix big-endian bug in ghash
crypto: sha1 - implement base layer for SHA-1
crypto: sha256 - implement base layer for SHA-256
crypto: sha512 - implement base layer for SHA-512
crypto: sha1-generic - move to generic glue implementation
crypto: sha256-generic - move to generic glue implementation
crypto: sha512-generic - move to generic glue implementation
crypto: arm/sha1 - move SHA-1 ARM asm implementation to base layer
crypto: arm/sha1_neon - move SHA-1 NEON implementation to base layer
crypto: arm/sha1-ce - move SHA-1 ARMv8 implementation to base layer
crypto: arm/sha256 - move SHA-224/256 ASM/NEON implementation to base
layer
crypto: arm/sha2-ce - move SHA-224/256 ARMv8 implementation to base layer
crypto: arm64/sha1-ce - move SHA-1 ARMv8 implementation to base layer
crypto: arm64/sha2-ce - move SHA-224/256 ARMv8 implementation to base
layer
crypto: x86/sha1_ssse3 - move SHA-1 SSSE3 implementation to base layer
crypto: x86/sha256_ssse3 - move SHA-224/256 SSSE3 implementation to base
layer
crypto: x86/sha512_ssse3 - move SHA-384/512 SSSE3 implementation to base
layer
crypto: arm - workaround for building with old binutils
Arnd Bergmann (1):
crypto: arm/sha256 - avoid sha256 code on ARMv7-M
Colin Ian King (1):
crypto: atmel - fix typo in dev_err error message
Dan Carpenter (2):
crypto: img-hash - fix some compile warnings
crypto: img-hash - shift wrapping bug in img_hash_hw_init()
Dmitry Torokhov (12):
hwrng: omap - remove incorrect __exit markups
hwrng: octeon - remove incorrect __exit markups
hwrng: pseries - remove incorrect __init/__exit markups
crypto: qat - remove incorrect __exit markup
crypto: amcc - remove incorrect __init/__exit markups
hwrng: omap - remove #ifdefery around PM methods
hwrng: add devm_* interfaces
hwrng: bcm63xx - make use of devm_hwrng_register
hwrng: exynos - make use of devm_hwrng_register
hwrng: msm - make use of devm_hwrng_register
hwrng: iproc-rng200 - do not use static structure
hwrng: iproc-rng200 - make use of devm_hwrng_register
Feng Kan (1):
hwrng: xgene - add ACPI support for APM X-Gene RNG unit
Florian Fainelli (4):
hwrng: bcm63xx - drop bcm_{readl,writel} macros
hwrng: bcm63xx - move register definitions to driver
MIPS: BCM63xx: remove RSET_RNG register definitions
hwrng: bcm63xx - use devm_* helpers
Geert Uytterhoeven (1):
crypto: ux500 - Update error message for dmaengine_prep_slave_sg() API
Herbert Xu (6):
linux-next: Tree
Re: [PATCH v3 0/6] virtio_balloon: virtio 1 support
"Michael S. Tsirkin" writes:
> On Tue, Apr 14, 2015 at 11:50:53AM +0200, Cornelia Huck wrote:
>> On Tue, 14 Apr 2015 11:21:11 +0200
>> "Michael S. Tsirkin" wrote:
>>
>> > diff --git a/include/uapi/linux/virtio_balloon.h
>> > b/include/uapi/linux/virtio_balloon.h
>> > index f81b220..164e0c2 100644
>> > --- a/include/uapi/linux/virtio_balloon.h
>> > +++ b/include/uapi/linux/virtio_balloon.h
>> > @@ -52,15 +52,31 @@ struct virtio_balloon_config {
>> > #define VIRTIO_BALLOON_S_MEMTOT 5 /* Total amount of memory */
>> > #define VIRTIO_BALLOON_S_NR 6
>> >
>> > +/*
>> > + * Memory statistics structure.
>> > + * Driver fills an array of these structures and passes to device.
>> > + *
>> > + * NOTE: fields are laid out in a way that would make compiler add padding
>> > + * between and after fields, so we have to use compiler-specific
>> > attributes to
>> > + * pack it, to disable this padding. This also often causes compiler to
>> > + * generate suboptimal code.
>> > + *
>> > + * We maintain this for backwards compatibility, but don't follow this
>> > example.
>>
>> s/this/the existing statistics structure/
>
> existing seems redundant. What else? non-existing?
>
>> > + *
>> > + * Do something like the below instead:
>>
>> If you want to implement a similar structure, do...
>>
>> Just that nobody gets the idea that they are supposed to implement new
>> balloon statistics ;)
>>
>> > + * struct virtio_balloon_stat {
>> > + * __virtio16 tag;
>> > + * __u8 reserved[6];
>> > + * __virtio64 val;
>> > + * };
>>
>> (...)
>>
>> > @@ -225,13 +219,8 @@ static inline void update_stat(struct virtio_balloon
>> > *vb, int idx,
>> > u16 tag, u64 val)
>> > {
>> >BUG_ON(idx >= VIRTIO_BALLOON_S_NR);
>> > - if (virtio_has_feature(vb->vdev, VIRTIO_F_VERSION_1)) {
>> > - vb->stats[idx].tag = cpu_to_le32(tag);
>> > - vb->stats[idx].val = cpu_to_le64(val);
>> > - } else {
>> > - vb->legacy_stats[idx].tag = tag;
>> > - vb->legacy_stats[idx].val = val;
>> > - }
>> > + vb->stats[idx].tag = cpu_to_virtio16(vb->vdev, tag);
>>
>> Seems that nobody seemed to care much about statistics...
>
> Or about BE guests ;)
>
>> > + vb->stats[idx].val = cpu_to_virtio64(vb->vdev, val);
>> > }
>> >
>> > #define pages_to_bytes(x) ((u64)(x) << PAGE_SHIFT)
>> >
>>
>> With these changes merged in:
>>
>> Acked-by: Cornelia Huck
>
>
> OK, here's an updated incremental patch: only comment
> changed.
OK, I've merged this with one change:
+static void stats_sg_init(struct virtio_balloon *vb, struct scatterlist *sg)
+{
+ sg_init_one(sg, vb->stats, sizeof(vb->stats));
+}
+
...
- sg_init_one(, vb->stats, sizeof(vb->stats));
+ stats_sg_init(vb, );
This is no longer a meaningful change, so I removed it.
Here's the final result:
From: Michael S. Tsirkin
Subject: virtio_balloon: transitional interface
Virtio 1.0 doesn't include a modern balloon device.
But it's not a big change to support a transitional
balloon device: this has the advantage of supporting
existing drivers, transparently.
Signed-off-by: Michael S. Tsirkin
Acked-by: Cornelia Huck
Signed-off-by: Rusty Russell
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 6a356e344f82..9db546ebe5a1 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -214,8 +219,8 @@ static inline void update_stat(struct virtio_balloon *vb,
int idx,
u16 tag, u64 val)
{
BUG_ON(idx >= VIRTIO_BALLOON_S_NR);
- vb->stats[idx].tag = tag;
- vb->stats[idx].val = val;
+ vb->stats[idx].tag = cpu_to_virtio16(vb->vdev, tag);
+ vb->stats[idx].val = cpu_to_virtio64(vb->vdev, val);
}
#define pages_to_bytes(x) ((u64)(x) << PAGE_SHIFT)
@@ -283,18 +288,27 @@ static void virtballoon_changed(struct virtio_device
*vdev)
static inline s64 towards_target(struct virtio_balloon *vb)
{
- __le32 v;
s64 target;
+ u32 num_pages;
- virtio_cread(vb->vdev, struct virtio_balloon_config, num_pages, );
+ virtio_cread(vb->vdev, struct virtio_balloon_config, num_pages,
+_pages);
- target = le32_to_cpu(v);
+ /* Legacy balloon config space is LE, unlike all other devices. */
+ if (!virtio_has_feature(vb->vdev, VIRTIO_F_VERSION_1))
+ num_pages = le32_to_cpu((__force __le32)num_pages);
+
+ target = num_pages;
return target - vb->num_pages;
}
static void update_balloon_size(struct virtio_balloon *vb)
{
- __le32 actual = cpu_to_le32(vb->num_pages);
+ u32 actual = vb->num_pages;
+
+ /* Legacy balloon config space is LE, unlike all other devices. */
+ if (!virtio_has_feature(vb->vdev, VIRTIO_F_VERSION_1))
+ actual = (__force u32)cpu_to_le32(actual);
virtio_cwrite(vb->vdev, struct virtio_balloon_config, actual,
linux-next: manual merge of the drm tree with the v4l-dvb tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
Documentation/DocBook/media/v4l/subdev-formats.xml between commit
7b0fd4568bee ("[media] v4l: Add RBG and RGB 8:8:8 media bus formats on
24 and 32 bit busses") and e8b2d7a565ae ("[media] v4l: Sort YUV formats
of v4l2_mbus_pixelcode") from the v4l-dvb tree and commits 08c38458be7e
("Add BGR888_1X24 and GBR888_1X24 media bus formats"), 0fc63eb104d7
("Add YUV8_1X24 media bus format") and 203508ef52e3 ("Add
RGB666_1X24_CPADHI media bus format") from the drm tree.
I fixed it up (almost certainly incorrectly - see below) and can carry
the fix as necessary. Please sort out who "owns" this file and try to
coordinate updates to it.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc Documentation/DocBook/media/v4l/subdev-formats.xml
index bc8d3fb9e4a9,18b71aff48c9..
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@@ -440,36 -482,96 +482,126 @@@ see .b1
b0
+
+MEDIA_BUS_FMT_RBG888_1X24
+0x100e
+
+
+r7
+r6
+r5
+r4
+r3
+r2
+r1
+r0
+b7
+b6
+b5
+b4
+b3
+b2
+b1
+b0
+g7
+g6
+g5
+g4
+g3
+g2
+g1
+g0
+
+
+ MEDIA_BUS_FMT_RGB666_1X24_CPADHI
+ 0x1015
+
+
+ 0
+ 0
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+ 0
+ 0
+ g5
+ g4
+ g3
+ g2
+ g1
+ g0
+ 0
+ 0
+ b5
+ b4
+ b3
+ b2
+ b1
+ b0
+
+
+ MEDIA_BUS_FMT_BGR888_1X24
+ 0x1013
+
+
+ b7
+ b6
+ b5
+ b4
+ b3
+ b2
+ b1
+ b0
+ g7
+ g6
+ g5
+ g4
+ g3
+ g2
+ g1
+ g0
+ r7
+ r6
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+
+
+ MEDIA_BUS_FMT_GBR888_1X24
+ 0x1014
+
+
+ g7
+ g6
+ g5
+ g4
+ g3
+ g2
+ g1
+ g0
+ b7
+ b6
+ b5
+ b4
+ b3
+ b2
+ b1
+ b0
+ r7
+ r6
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+
MEDIA_BUS_FMT_RGB888_1X24
0x100a
@@@ -2719,33 -3047,92 +3106,92 @@@
u1
u0
+
+MEDIA_BUS_FMT_YDYUYDYV8_1X16
+0x2014
+
+
+y7
+y6
+y5
+y4
+y3
+y2
+y1
+y0
++d
++d
++d
++d
++d
++d
++d
++d
++
+
+ MEDIA_BUS_FMT_YUV8_1X24
+ 0x2024
+
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ y7
+ y6
+ y5
+ y4
+ y3
+ y2
+ y1
+ y0
+ u7
+ u6
+ u5
+ u4
+ u3
+ u2
+ u1
+ u0
+ v7
+ v6
+ v5
+ v4
+ v3
+ v2
+ v1
+ v0
+
+
+ MEDIA_BUS_FMT_YUV10_1X30
+ 0x2016
+
--
--
-y9
-y8
++
+ y7
+ y6
+ y5
+ y4
+ y3
+ y2
+ y1
+ y0
-u9
-u8
-u7
-u6
-u5
-u4
-u3
-u2
-u1
-u0
-v9
-v8
-v7
-v6
-v5
-v4
-v3
-v2
-v1
-v0
+
Re: [PATCH] virtio_balloon: drop virtio_balloon_stat_modern
Cornelia Huck writes: > On Tue, 14 Apr 2015 12:01:13 +0200 > "Michael S. Tsirkin" wrote: > >> Looks like we are better off sticking with the misaligned stat struct, >> to reduce the amount of virtio 1 specific code in balloon. So let's do >> it. >> >> Add a detailed comment to reduce the chance people copy this bad example. >> >> This also fixes a bug on BE architectures: tag should use >> cpu_to_le16, not cpu_to_le32. >> >> Acked-by: Cornelia Huck >> Signed-off-by: Michael S. Tsirkin >> --- >> >> Just reposting so it's easier to apply. >> Feel free to squash into previous patch if you think it's >> neater. > > +1 for squashing from me. My A-b would also apply to the squashed patch. Yes, I already squashed. TBH, I would have squashed the next patches into one too, that simply got rid of the virtio_device_is_legacy_only() function and all callers. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] modpost: handle relocations mismatch in __ex_table.
Quentin Casasnovas writes: > On Tue, Apr 14, 2015 at 02:14:14PM +0200, Thierry Reding wrote: >> On Tue, Mar 17, 2015 at 01:40:02PM +0100, Quentin Casasnovas wrote: >> > If one of these addresses point to a non-executable section, something is >> > seriously wrong since it either means the kernel will never fault from >> > there or it will not be able to jump to there. As both cases are serious >> > enough, we simply error out in these cases so the build fails and the >> > developper has to fix the issue. >> > >> > Signed-off-by: Quentin Casasnovas >> > --- >> > scripts/mod/modpost.c | 141 >> > ++ >> > 1 file changed, 141 insertions(+) >> >> This causes a bunch of mismatch warnings on 32-bit and 64-bit ARM >> because there are two additional sections, .text.fixup and >> .exception.text that store executable code. I've attached a patch >> to fix those, but feel free to squash that into the original commit >> if that's still possible. >> > > Thanks Thierry! > > Your patch looks good to me, though I was wondering if we should just add > .text.* in the TEXT_SECTIONS macro. Some architectures define > -ffunction-sections (parisc, score, metag and frv) so there are tons of > useless warnings on these.. It also means the current modpost sanity > checks don't run for those so it might even uncover some real mismatch ;) Yes, but this adds ".exception.text" so a .text.* wildcard won't quite cover it. I've applied his patch, then the following: modpost: handle -ffunction-sections 52dc0595d540 introduced OTHER_TEXT_SECTIONS for identifying what sections could validly have __ex_table entries. Unfortunately, it wasn't tested with -ffunction-sections, which some architectures use. Reported-by: kbuild test robot Cc: Quentin Casasnovas Signed-off-by: Rusty Russell diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index cbd53e08769d..22dbc604cdb9 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -876,7 +876,7 @@ static void check_section(const char *modname, struct elf_info *elf, #define TEXT_SECTIONS ".text", ".text.unlikely", ".sched.text", \ ".kprobes.text" #define OTHER_TEXT_SECTIONS ".ref.text", ".head.text", ".spinlock.text", \ - ".fixup", ".entry.text" + ".fixup", ".entry.text", ".exception.text", ".text.*" #define INIT_SECTIONS ".init.*" #define MEM_INIT_SECTIONS ".meminit.*" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] param: fixup quote parsing of kernel arguments
Arthur Gautier writes:
> On Wed, Apr 08, 2015 at 03:29:43PM +0930, Rusty Russell wrote:
>> Arthur Gautier writes:
>> > When starting kernel with arguments like:
>> > init=/bin/sh -c "echo arguments"
>> > the trailing double quote is not removed which results in following command
>> > being executed:
>> > /bin/sh -c 'echo arguments"'
>> >
>> > This commit removes the trailing double quote.
>> >
>> > Signed-off-by: Arthur Gautier
>>
>> Hi Arthur,
>>
>> Thanks, I'd not considered quotes outside '='. But this
>> fixes it in a weird way: we handle quotes below, we just don't do
>> anything for the "raw value" case:
>>
>> for (i = 0; args[i]; i++) {
>> if (isspace(args[i]) && !in_quote)
>> break;
>> if (equals == 0) {
>> if (args[i] == '=')
>> equals = i;
>> }
>> if (args[i] == '"')
>> in_quote = !in_quote;
>> }
>>
>> *param = args;
>> if (!equals)
>> *val = NULL;
>> else {
>> args[equals] = '\0';
>> *val = args + equals + 1;
>>
>> /* Don't include quotes in value. */
>> if (**val == '"') {
>> (*val)++;
>> if (args[i-1] == '"')
>> args[i-1] = '\0';
>> }
>> if (quoted && args[i-1] == '"')
>> args[i-1] = '\0';
>> }
>>
>> The logical fix is to just always remove the close quotes in both
>> cases:
>>
>> diff --git a/kernel/params.c b/kernel/params.c
>> index 728e05b167de..a22d6a759b1a 100644
>> --- a/kernel/params.c
>> +++ b/kernel/params.c
>> @@ -173,9 +173,9 @@ static char *next_arg(char *args, char **param, char
>> **val)
>> if (args[i-1] == '"')
>> args[i-1] = '\0';
>> }
>> -if (quoted && args[i-1] == '"')
>> -args[i-1] = '\0';
>> }
>> +if (quoted && args[i-1] == '"')
>> +args[i-1] = '\0';
>>
>> if (args[i]) {
>> args[i] = '\0';
>>
>> Does this work for you?
>>
>
> Hi Rusty,
>
> This does indeed fixes my issue and I agree with the fix but I've also
> noticed a problem when parsing commands like:
>
> char * input = "var0=\"val=ue\" \"var1\"=value \"var2=value\" \"echo foo\"";
> char buf[255];
> char *args = buf;
> char * param, *val;
>
> memcpy(buf, input, strlen(input)+1);
>
> while(*args)
> {
> args = next_arg(args, , );
> printf("%s=%s\n", param, val);
> }
>
> This parses commandline like:
>
> var0=val=ue
> var1"=value
> var2=value
> echo foo=(null)
>
> As you may notice when using doublequote for keys, the final doublequote
> is not removed. I'm not sure this should be considered as a problem nor
> this should be expected but my patch was fixing this issue as well.
Indeed. And the following isn't parse correctly either:
foo="one ""two"
Though it *looks* like the code handles this, it doesn't: you'll get
'one ""two'.
Your first case was interesting because it was a more practical example.
I've applied my simple fix for now; if you want to do more thorough quote
handling (ie. use memmove), I'd love to see patches.
Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection
On Tue, Apr 14, 2015 at 08:29:34PM +0900, Chanwoo Choi wrote: > On 04/14/2015 07:38 PM, Roger Quadros wrote: > > On 14/04/15 13:31, Chanwoo Choi wrote: > >> On 04/14/2015 07:02 PM, Roger Quadros wrote: > >>> Fixed Kishon's id. > >>> > >>> On 14/04/15 13:01, Roger Quadros wrote: > On 10/04/15 12:18, Chanwoo Choi wrote: > > On 04/10/2015 05:46 PM, Robert Baldyga wrote: > >> On 04/10/2015 10:10 AM, Chanwoo Choi wrote: > >>> On 04/10/2015 04:45 PM, Robert Baldyga wrote: > On 04/10/2015 09:17 AM, Chanwoo Choi wrote: > > Hi Robert, > > > > On 04/09/2015 06:24 PM, Robert Baldyga wrote: > >> Hi Chanwoo, > >> > >> On 04/09/2015 11:07 AM, Chanwoo Choi wrote: > >>> Hi Robert, > >>> > >>> On 04/09/2015 04:57 PM, Robert Baldyga wrote: > Hi Chanwoo, > > On 04/09/2015 04:12 AM, Chanwoo Choi wrote: > > Hi Robert, > > > >>> > >>> [snip] > >>> > > But, I have one question about case[3] > > > > If id is low and vbus is high, this patch will update the state > > of both USB and USB-HOST cable as attached state. > > Is it possible that two different cables (both USB and > > USB-HOST) are connected to one port simultaneously? > > > > It's because state of single USB cable connection cannot be > completely > described using single extcon cable. USB cable state has two > bits (VBUS > and ID), so we need to use two cables for single cable > connection. We > use following convention: > cable "USB" = VBUS > cable "USB-HOST" = !ID. > >>> > >>> I think that extcon provider driver have to update the only one > >>> cable state > >>> of either USB or USB-HOST because USB and USB-HOST feature can > >>> not be used > >>> at the same time through one h/w port. > >>> > >>> If extcon-usb-gpio.c update two connected event of both USB and > >>> USB-HOST cable > >>> at the same time, the extcon consumer driver can not decide what > >>> handle either USB or USB-HOST. > >>> > >> > >> It can. USB OTG allows for that. Moreover device can be host even > >> if > >> ID=1 (so detected cable type is USB device), or peripheral when > >> ID=0 (so > >> detected cable type is USB host). Devices would need to have > >> complete > >> information about USB cable connection, because OTG state machine > >> needs > > > > As I knew, USB OTG port don't send the attached cable of both USB > > and USB-HOST > > at the same time. The case3 in your patch update two cable state > > about one h/w port. > > > > It's because simple "USB" or "USB-HOST" means nothing for USB OTG > machine. It needs to know exact VBUS and ID states, which cannot be > concluded basing on cable type only. That's why I have used > "USB-HOST" > name together with "USB" to pass additional information about USB > cable > connection. > >>> > >>> I think this method is not proper to support this case. > >>> It may cause the confusion about other case using USB/USB-HOST cable > >>> state > >>> except of you commented case. > >> > >> That's why I finally proposed to use "USB-ID" and "USB-VBUS" in > >> parallel > >> with old names. It seems to be simpler solution than adding new > >> mechanism notifying about VBUS and ID states changes. > > > > > > As I commented on previous reply, I don't agree to use 'USB-ID' and > > 'USB-VBUS'. > > If we add new strange 'USB-ID' and 'USB-VBUS' name, we would add > > non-general cable > > name continuoulsy. > > > > I think that extcon core provide the helper API to get the value of > > VBUS. > > But I need to consider it. > > Now it is starting to look like existing extcon states are not suitable > for USB/PHY drivers to deliver > VBUS and ID information reliably. > This is because based on your comments the "USB" and "USB-HOST" states > look like some fuzzy states > and have no direct correspondence with "VBUS" and "ID". The fact that > they can't become > attached simultaneously makes me conclude that "USB" and "USB-HOST" > cable states are really > capturing only the ID pin state. > > I can suggest the following options > a) let "USB" and "USB-HOST" only indicate ID pin status. Add a new cable > state for "VBUS" notification. > Maybe call it "USB-POWER" or something. > >> > >> We must discuss it before
Re: linux-next: manual merge of the ftrace tree with the net-next tree
From: Steven Rostedt
Date: Tue, 14 Apr 2015 23:06:29 -0400
> I also noted this coming conflict in my pull request. So Linus should
> be very well aware of it.
>
> https://lkml.org/lkml/2015/4/13/652
>
> "Also there's a conflict with commit 7e1223b50089 ("iwlwifi: mvm: new
> Alive / error table API") that Stephen found and he resolved it with
> cd98c1ef4ec1a4d08e920060b70e47a5a4e69377."
>
> That is, if that commit sha1 still exists.
I'll be sure to explain this to Linus.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: jz4780: Fix build for m68k and sparc64
Fix:
drivers/i2c/busses/i2c-jz4780.c: In function 'jz4780_i2c_readw':
drivers/i2c/busses/i2c-jz4780.c:181:2: error:
implicit declaration of function 'readw'
drivers/i2c/busses/i2c-jz4780.c: In function 'jz4780_i2c_writew':
drivers/i2c/busses/i2c-jz4780.c:187:2: error:
implicit declaration of function 'writew'
seen with sparc64:allmodconfig and m68k:allmodconfig.
The driver depends on HAS_IOMEM, and must include linux/io.h.
Fixes: ba9ed63a ("i2c: jz4780: Add i2c bus controller driver
for Ingenic JZ4780")
Cc: Zubair Lutfullah Kakakhel
Signed-off-by: Guenter Roeck
---
drivers/i2c/busses/Kconfig | 1 +
drivers/i2c/busses/i2c-jz4780.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2255af23b9c7..c78b6cbd1106 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -586,6 +586,7 @@ config I2C_IOP3XX
config I2C_JZ4780
tristate "JZ4780 I2C controller interface support"
depends on MACH_JZ4780 || COMPILE_TEST
+ depends on HAS_IOMEM
help
If you say yes to this option, support will be included for the
Ingenic JZ4780 I2C controller.
diff --git a/drivers/i2c/busses/i2c-jz4780.c b/drivers/i2c/busses/i2c-jz4780.c
index ce1d69324169..f2761ab2ef32 100644
--- a/drivers/i2c/busses/i2c-jz4780.c
+++ b/drivers/i2c/busses/i2c-jz4780.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] RCU changes for v4.1
On Tue, Apr 14, 2015 at 7:55 PM, Paul E. McKenney wrote: > > Does the (currently being tested) patch below fix things up? If not, > please fill me in on the further error of my ways. Looks ok. That said, couldn't that last dummy gp_init_delay variable: > +/* Delay in jiffies for grace-period initialization delays, debug only. */ > +#ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT > +static int gp_init_delay = CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY; > module_param(gp_init_delay, int, 0644); > +#else /* #ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT */ > +static const int gp_init_delay; > +#endif /* #else #ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT */ be just a #define gp_init_delay 0 for the non-CONFIG_RCU_TORTURE_TEST_SLOW_INIT case, so that the code that then does + if (gp_init_delay > 0 && + !(rsp->gpnum % (rcu_num_nodes * PER_RCU_NODE_PERIOD))) would just trivially compile away. I guess the compiler *might* see a 'static const int' that is never touched and realize it's always zero, but it's not obvious that will be the case. Linus Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH linux-next v3] mlx5: wrong page mask if CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for 32Bit architectures
If CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for x86 systems and physical
memory is more than 4GB, dma_map_page may return a valid memory
address which greater than 0x. As a result, the mlx5 device page
allocator RB tree will be initialized with valid addresses greater than
0xfff.
However, (addr & PAGE_MASK) set the high four bytes to zeros. So, it's
impossible for the function, free_4k, to release the pages whose
addresses greater than 4GB. Memory leaks. And mlx5_ib module can't
release the pages when user try to remove the module, as a result,
system hang.
[root@rdma05 root]# dmesg | grep addr | head
addr = 3fe384000
addr & PAGE_MASK = fe384000
[root@rdma05 root]# rmmod mlx5_ib < hang on
-- cosnole log -
mlx5_ib :04:00.0: irq 138 for MSI/MSI-X
alloc irq_desc for 139 on node -1
alloc kstat_irqs on node -1
mlx5_ib :04:00.0: irq 139 for MSI/MSI-X
:04:00.0:free_4k:221:(pid 1519): page not found
:04:00.0:free_4k:221:(pid 1519): page not found
:04:00.0:free_4k:221:(pid 1519): page not found
:04:00.0:free_4k:221:(pid 1519): page not found
-- cosnole log -
Fix(bf0bf77 mlx5: Support communicating arbitrary host page size to
firmware)
Signed-off-by: Honggang Li
---
.../net/ethernet/mellanox/mlx5/core/pagealloc.c| 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
index df22383..8a64542 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
@@ -211,26 +211,28 @@ static int alloc_4k(struct mlx5_core_dev *dev, u64 *addr)
return 0;
}
+#define MLX5_U64_4K_PAGE_MASK ((~(u64)0U) << PAGE_SHIFT)
+
static void free_4k(struct mlx5_core_dev *dev, u64 addr)
{
struct fw_page *fwp;
int n;
- fwp = find_fw_page(dev, addr & PAGE_MASK);
+ fwp = find_fw_page(dev, addr & MLX5_U64_4K_PAGE_MASK);
if (!fwp) {
mlx5_core_warn(dev, "page not found\n");
return;
}
- n = (addr & ~PAGE_MASK) >> MLX5_ADAPTER_PAGE_SHIFT;
+ n = (addr & ~MLX5_U64_4K_PAGE_MASK) >> MLX5_ADAPTER_PAGE_SHIFT;
fwp->free_count++;
set_bit(n, >bitmask);
if (fwp->free_count == MLX5_NUM_4K_IN_PAGE) {
rb_erase(>rb_node, >priv.page_root);
if (fwp->free_count != 1)
list_del(>list);
- dma_unmap_page(>pdev->dev, addr & PAGE_MASK, PAGE_SIZE,
- DMA_BIDIRECTIONAL);
+ dma_unmap_page(>pdev->dev, addr & MLX5_U64_4K_PAGE_MASK,
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
__free_page(fwp->page);
kfree(fwp);
} else if (fwp->free_count == 1) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next v2] mlx5: wrong page mask if CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for 32Bit architectures
On Tue, Apr 14, 2015 at 10:23:16PM +0300, Eli Cohen wrote:
> On Mon, Apr 13, 2015 at 05:21:58PM +0800, Honggang Li wrote:
> > @@ -241,7 +243,7 @@ static void free_4k(struct mlx5_core_dev *dev, u64 addr)
> > static int alloc_system_page(struct mlx5_core_dev *dev, u16 func_id)
> > {
> > struct page *page;
> > - u64 addr;
> > + u64 addr = 0;
> > int err;
> > int nid = dev_to_node(>pdev->dev);
> >
>
> I really don't see any reason why you need to set addr to 0. Can you
> please explain this?
> Other than that the patch is ok.
Sorry, I trid my best to explain it. But failed. I'm fine to remove it.
New patch will be submit. And I will insert a fix tag in it.
Fix(bf0bf77 mlx5: Support communicating arbitrary host page size to
firmware)
thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the ftrace tree with the net-next tree
On Wed, 15 Apr 2015 11:23:23 +1000
Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 13 Apr 2015 17:52:24 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the ftrace tree got a conflict in
> > drivers/net/wireless/iwlwifi/iwl-devtrace.h between commit 7e1223b50089
> > ("iwlwifi: mvm: new Alive / error table API") from the net-next tree
> > and commit c5ef935d01a2 ("iwlwifi: Move each system tracepoints to
> > their own header") from the ftrace tree.
> >
> > I fixed it up (see patch below, since this code was moved to a new file)
> > and can carry the fix as necessary (no action is required).
> >
> > From: Stephen Rothwell
> > Date: Mon, 13 Apr 2015 17:21:30 +1000
> > Subject: [PATCH] iwlwifi: mvm: fix up for tracing split
> >
> > Signed-off-by: Stephen Rothwell
> This patch is now needed when the net-next tree is merged with Linus'
> tree ...
I also noted this coming conflict in my pull request. So Linus should
be very well aware of it.
https://lkml.org/lkml/2015/4/13/652
"Also there's a conflict with commit 7e1223b50089 ("iwlwifi: mvm: new
Alive / error table API") that Stephen found and he resolved it with
cd98c1ef4ec1a4d08e920060b70e47a5a4e69377."
That is, if that commit sha1 still exists.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the regulator tree
On 14 April 2015 at 19:40, Mark Brown wrote: > On Tue, Apr 14, 2015 at 11:22:41AM +1000, Stephen Rothwell wrote: >> On Mon, 13 Apr 2015 18:07:06 -0700 Bjorn Andersson >> wrote: > >> > Your patch looks correct and should preferrably be added to the drm >> > tree, or the last patch in my series that drops the API wrapper should >> > be held back until rc1(?) > >> It needs to be sent to Linus as a merge fix when the drm tree is merged. > > Or the DRM tree could pull my tree I guess - Rob/David, I can make a tag > specifically for this branch if you like? I can just backmerge Linus's tree before I send it to him, and stick this patch on top. seems like the best answer. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] RCU changes for v4.1
On Tue, Apr 14, 2015 at 05:25:12PM -0700, Linus Torvalds wrote: > On Tue, Apr 14, 2015 at 5:22 PM, Linus Torvalds > wrote: > > > >depends on RCU_TORTURE_TEST_SLOW_INIT > > > > would seem to be called for. > > Side note, you'll obviously also need to fix the actual bogus > 'gp_init_delay' use in kernel/rcu/tree.c. > > That code is horrible. I was getting too cute in an attempt to avoid a #ifdef. :-/ Does the (currently being tested) patch below fix things up? If not, please fill me in on the further error of my ways. Thanx, Paul "it seemed like at good idea a the time" McKenney rcu: Control grace-period delays directly from value In a misguided attempt to avoid an #ifdef, the use of the gp_init_delay module parameter was conditioned on the corresponding RCU_TORTURE_TEST_SLOW_INIT Kconfig variable, using IS_ENABLED() at the point of use in the code. This meant that the compiler always saw the delay, which meant that RCU_TORTURE_TEST_SLOW_INIT_DELAY had to be unconditionally defined. This in turn caused "make oldconfig" to ask pointless questions about the value of RCU_TORTURE_TEST_SLOW_INIT_DELAY in cases where it was not even used. This commit avoids these pointless questions by defining gp_init_delay under #ifdef. In one branch, gp_init_delay is initialized to RCU_TORTURE_TEST_SLOW_INIT_DELAY and is also a module parameter (thus allowing boot-time modification), and in the other branch gp_init_delay is a const variable initialized by default to zero. This approach also simplifies the code at the delay point by eliminating the IS_DEFINED(). Because gp_init_delay is constant zero in the no-delay case intended for production use, the "gp_init_delay > 0" check causes the delay to become dead code, as desired in this case. In addition, this commit replaces magic constant "10" with the preprocessor variable PER_RCU_NODE_PERIOD, which controls the number of grace periods that are allowed to elapse at full speed before a delay is inserted. Reported-by: Linus Torvalds Signed-off-by: Paul E. McKenney diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 233165da782f..8cf7304b2867 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -162,11 +162,14 @@ static void invoke_rcu_callbacks(struct rcu_state *rsp, struct rcu_data *rdp); static int kthread_prio = CONFIG_RCU_KTHREAD_PRIO; module_param(kthread_prio, int, 0644); -/* Delay in jiffies for grace-period initialization delays. */ -static int gp_init_delay = IS_ENABLED(CONFIG_RCU_TORTURE_TEST_SLOW_INIT) - ? CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY - : 0; +/* Delay in jiffies for grace-period initialization delays, debug only. */ +#ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT +static int gp_init_delay = CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY; module_param(gp_init_delay, int, 0644); +#else /* #ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT */ +static const int gp_init_delay; +#endif /* #else #ifdef CONFIG_RCU_TORTURE_TEST_SLOW_INIT */ +#define PER_RCU_NODE_PERIOD 10 /* Number of grace periods between delays. */ /* * Track the rcutorture test sequence number and the update version @@ -1843,9 +1846,8 @@ static int rcu_gp_init(struct rcu_state *rsp) raw_spin_unlock_irq(>lock); cond_resched_rcu_qs(); ACCESS_ONCE(rsp->gp_activity) = jiffies; - if (IS_ENABLED(CONFIG_RCU_TORTURE_TEST_SLOW_INIT) && - gp_init_delay > 0 && - !(rsp->gpnum % (rcu_num_nodes * 10))) + if (gp_init_delay > 0 && + !(rsp->gpnum % (rcu_num_nodes * PER_RCU_NODE_PERIOD))) schedule_timeout_uninterruptible(gp_init_delay); } diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 1ad74c0df01f..5f5ff7d7e5eb 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1268,6 +1268,7 @@ config RCU_TORTURE_TEST_SLOW_INIT_DELAY int "How much to slow down RCU grace-period initialization" range 0 5 default 3 + depends on RCU_TORTURE_TEST_SLOW_INIT help This option specifies the number of jiffies to wait between each rcu_node structure initialization. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] selftests/x86: fix cross build logic
Hi Andy, On 14 April 2015 at 17:33, Andy Lutomirski wrote: > On 04/14/2015 03:52 PM, Tyler Baker wrote: >> >> x86 tests should not be built when ARCH != x86. Reused the logic from >> breakpoints to determine when it's appropriate to build. > > > In the future, please cc the author of recently-written code that you're > fixing :) My apologies, thanks for keeping me in line ;) > > This patch is really weird. You're generating ARCH, then you're modifying > it part way through, and you're changing the rule for all_32 and all_64 to > print an error (and succeed!) if run on the wrong arch. > > I don't see the point of the latter at all. Just let all have no > dependencies if you're on the wrong ARCH. Ok, this should make life simpler. All this logic stems from the breakpoints test (x86 only as well) so it seems like we should do the same for it as well. > > As for the former, can you do this more cleanly? This is really ugly. It > looks to me (on naive reading) like 64-bit hosts won't do the right thing. > (The right thing is to build both bitnesses of tests.) It does build both bitnesses on a 64 bit host, however I do agree this could be cleaned up based on the comments above. > > --Andy > > >> >> Signed-off-by: Tyler Baker >> --- >> tools/testing/selftests/x86/Makefile | 35 >> +++ >> 1 file changed, 23 insertions(+), 12 deletions(-) >> >> diff --git a/tools/testing/selftests/x86/Makefile >> b/tools/testing/selftests/x86/Makefile >> index f0a7918..7be67a0 100644 >> --- a/tools/testing/selftests/x86/Makefile >> +++ b/tools/testing/selftests/x86/Makefile >> @@ -7,31 +7,36 @@ BINARIES_64 := $(TARGETS_C_BOTHBITS:%=%_64) >> >> CFLAGS := -O2 -g -std=gnu99 -pthread -Wall >> >> -UNAME_P := $(shell uname -p) >> - >> -# Always build 32-bit tests >> +# Taken from perf makefile >> +uname_M := $(shell uname -m 2>/dev/null || echo not) >> +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/) >> +ifeq ($(ARCH),i386) >> +ARCH := x86 >> all: all_32 >> - >> +endif >> +ifeq ($(ARCH),x86_64) >> +ARCH := x86 >> # If we're on a 64-bit host, build 64-bit tests as well >> -ifeq ($(shell uname -p),x86_64) >> -all: all_64 >> +all: all_32 all_64 >> endif >> >> all_32: check_build32 $(BINARIES_32) >> >> all_64: $(BINARIES_64) >> >> -clean: >> - $(RM) $(BINARIES_32) $(BINARIES_64) >> - >> -run_tests: >> - ./run_x86_tests.sh >> - >> $(TARGETS_C_BOTHBITS:%=%_32): %_32: %.c >> +ifeq ($(ARCH),x86) >> $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl >> +else >> + echo "Not an x86 target, can't build x86 tests" >> +endif >> >> $(TARGETS_C_BOTHBITS:%=%_64): %_64: %.c >> +ifeq ($(ARCH),x86) >> $(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl >> +else >> + echo "Not an x86 target, can't build x86 tests" >> +endif >> >> check_build32: >> @if ! $(CC) -m32 -o /dev/null trivial_32bit_program.c; then \ >> @@ -46,3 +51,9 @@ check_build32: >> echo " yum install glibc-devel.*i686"; \ >> exit 1; \ >> fi >> + >> +run_tests: >> + ./run_x86_tests.sh >> + >> +clean: >> + $(RM) $(BINARIES_32) $(BINARIES_64) >> > I'll wait to see if there any other comments on this series before sending an update. Thanks, Tyler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] kvm: mmu: don't do memslot overflow check
As Andres pointed out:
| I don't understand the value of this check here. Are we looking for a
| broken memslot? Shouldn't this be a BUG_ON? Is this the place to care
| about these things? npages is capped to KVM_MEM_MAX_NR_PAGES, i.e.
| 2^31. A 64 bit overflow would be caused by a gigantic gfn_start which
| would be trouble in many other ways.
This patch drops the memslot overflow check to make the codes more simple.
Reviewed-by: Andres Lagar-Cavilla
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* Fix Andres's name
* Add Andres's Reviewed-by
arch/x86/kvm/mmu.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2a0d77e..9265fda 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4505,19 +4505,12 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
bool flush = false;
unsigned long *rmapp;
unsigned long last_index, index;
- gfn_t gfn_start, gfn_end;
spin_lock(>mmu_lock);
- gfn_start = memslot->base_gfn;
- gfn_end = memslot->base_gfn + memslot->npages - 1;
-
- if (gfn_start >= gfn_end)
- goto out;
-
rmapp = memslot->arch.rmap[0];
- last_index = gfn_to_index(gfn_end, memslot->base_gfn,
- PT_PAGE_TABLE_LEVEL);
+ last_index = gfn_to_index(memslot->base_gfn + memslot->npages - 1,
+ memslot->base_gfn, PT_PAGE_TABLE_LEVEL);
for (index = 0; index <= last_index; ++index, ++rmapp) {
if (*rmapp)
@@ -4535,7 +4528,6 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
if (flush)
kvm_flush_remote_tlbs(kvm);
-out:
spin_unlock(>mmu_lock);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] sched, timer: Remove usages of ACCESS_ONCE in the scheduler
On Tue, 14 Apr 2015 19:12:33 -0700
Jason Low wrote:
> Hi Steven,
>
> On Tue, 2015-04-14 at 19:59 -0400, Steven Rostedt wrote:
> > On Tue, 14 Apr 2015 16:09:44 -0700
> > Jason Low wrote:
> >
> >
> > > @@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node,
> > > int pages, int flags)
> > >
> > > static void reset_ptenuma_scan(struct task_struct *p)
> > > {
> > > - ACCESS_ONCE(p->mm->numa_scan_seq)++;
> > > + WRITE_ONCE(p->mm->numa_scan_seq, READ_ONCE(p->mm->numa_scan_seq) + 1);
> >
> > Is the READ_ONCE() inside the WRITE_ONCE() really necessary?
>
> Yeah, I think so to be safe, otherwise, the access of
> p->mm->numa_scan_seq in the 2nd parameter doesn't have the volatile
> cast.
You are correct. Now I'm thinking that the WRITE_ONCE() is not needed,
and just a:
p->mm->numa_scan_seq = READ_ONCE(p->numa_scan_seq) + 1;
Can be done. But I'm still trying to wrap my head around why this is
needed here. Comments would have been really helpful. We should make
all READ_ONCE() WRITE_ONCE and obsolete ACCESS_ONCE() have mandatory
comments just like we do with memory barriers.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the ftrace tree with the net-next tree
From: Stephen Rothwell Date: Wed, 15 Apr 2015 11:23:23 +1000 > This patch is now needed when the net-next tree is merged with Linus' > tree ... Yeah I noticed this while working on test merges into Linus's tree, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm64: add KASan support
>>> + pgd = __pgd(__pa(kasan_zero_pmd) | PAGE_KERNEL);
>>> +#else
>>> + pgd = __pgd(__pa(kasan_zero_pte) | PAGE_KERNEL);
>>> +#endif
>>> +
>>> + for (i = pgd_index(start); start < end; i++) {
>>> + set_pgd([i], pgd);
>>> + start += PGDIR_SIZE;
>>> + }
>>> +}
>>
>> Same problem as above with PAGE_KERNEL. You should just use
>> pgd_populate().
Any suggestion what the correct flag setting would be here for a 4K mapping?
I tried fixing this by changing this to pud and setting the PMD_TYPE_TABLE flag
for kasan_zero_pmd. However the MMU doesn't like it and I get a first level
address translation fault.
If you have any updated patches to share I'd be glad to try them out.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the pm tree
Hi Len,
On Mon, 13 Apr 2015 14:24:42 +1000 Stephen Rothwell
wrote:
>
> Hi Rafael,
>
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from arch/x86/include/asm/msr.h:131:0,
> from arch/x86/include/asm/processor.h:20,
> from arch/x86/include/asm/thread_info.h:23,
> from include/linux/thread_info.h:54,
> from arch/x86/include/asm/preempt.h:6,
> from include/linux/preempt.h:18,
> from include/linux/smp.h:55,
> from include/linux/kernel_stat.h:4,
> from drivers/cpufreq/intel_pstate.c:14:
> drivers/cpufreq/intel_pstate.c: In function 'knl_get_turbo_pstate':
> drivers/cpufreq/intel_pstate.c:622:9: error: 'MSR_NHM_TURBO_RATIO_LIMIT'
> undeclared (first use in this function)
> rdmsrl(MSR_NHM_TURBO_RATIO_LIMIT, value);
> ^
> arch/x86/include/asm/paravirt.h:153:26: note: in definition of macro 'rdmsrl'
> val = paravirt_read_msr(msr, &_err); \
> ^
> drivers/cpufreq/intel_pstate.c:622:9: note: each undeclared identifier is
> reported only once for each function it appears in
> rdmsrl(MSR_NHM_TURBO_RATIO_LIMIT, value);
> ^
> arch/x86/include/asm/paravirt.h:153:26: note: in definition of macro 'rdmsrl'
> val = paravirt_read_msr(msr, &_err); \
> ^
>
> Caused by commit 6acfd09a439a ("tools/power turbostat: define and dump
> MSR_TURBO_RATIO_LIMIT2") interacting with commit b34ef932d79a
> ("intel_pstate: Knights Landing support"). This should have been
> resolved in commit 08fb40f3fbeb ("Merge branches 'powercap' and
> 'pm-tools'").
>
> I have added the following patch for today:
>
> From: Stephen Rothwell
> Date: Mon, 13 Apr 2015 14:11:11 +1000
> Subject: [PATCH] intel_pstate: fix bad merge (MSR_NHM_TURBO_RATIO_LIMIT
> rename)
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/cpufreq/intel_pstate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 875154d5f60b..5ecd2689a8fc 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -619,7 +619,7 @@ static int knl_get_turbo_pstate(void)
> u64 value;
> int nont, ret;
>
> - rdmsrl(MSR_NHM_TURBO_RATIO_LIMIT, value);
> + rdmsrl(MSR_TURBO_RATIO_LIMIT, value);
> nont = core_get_max_pstate();
> ret = (((value) >> 8) & 0xFF);
> if (ret <= nont)
This is now required after the merge of the idle tree (since the code
was removed from the pm tree).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpUDb6TTNJOT.pgp
Description: OpenPGP digital signature
Re: [patch v2] net: hip04: Make tx coalesce timer actually work
On 2015/4/15 3:42, Thomas Gleixner wrote:
> The code sets the expiry value of the timer to a relative value and
> starts it with hrtimer_start_expires. That's fine, but that only works
> once. The timer is started in relative mode, so the expiry value gets
> overwritten with the absolut expiry time (now + expiry).
>
> So once the timer expired, a new call to hrtimer_start_expires results
> in an immidiately expired timer, because the expiry value is
> already in the past.
>
> Use the proper mechanisms to (re)start the timer in the intended way.
>
Acked-by: Ding Tianhong
> Signed-off-by: Thomas Gleixner
> Cc: "David S. Miller"
> Cc: dingtianhong
> Cc: Arnd Bergmann
> Cc: Zhangfei Gao
> Cc: Dan Carpenter
> Cc: net...@vger.kernel.org
> ---
> drivers/net/ethernet/hisilicon/hip04_eth.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> Index: linux/drivers/net/ethernet/hisilicon/hip04_eth.c
> ===
> --- linux.orig/drivers/net/ethernet/hisilicon/hip04_eth.c
> +++ linux/drivers/net/ethernet/hisilicon/hip04_eth.c
> @@ -413,6 +413,15 @@ out:
> return count;
> }
>
> +static void hip04_start_tx_timer(struct hip04_priv *priv)
> +{
> + unsigned long ns = priv->tx_coalesce_usecs * NSEC_PER_USEC / 2;
> +
> + /* allow timer to fire after half the time at the earliest */
> + hrtimer_start_range_ns(>tx_coalesce_timer, ns_to_ktime(ns),
> +ns, HRTIMER_MODE_REL);
> +}
> +
> static int hip04_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> {
> struct hip04_priv *priv = netdev_priv(ndev);
> @@ -466,8 +475,7 @@ static int hip04_mac_start_xmit(struct s
> }
> } else if (!hrtimer_is_queued(>tx_coalesce_timer)) {
> /* cleanup not pending yet, start a new timer */
> - hrtimer_start_expires(>tx_coalesce_timer,
> - HRTIMER_MODE_REL);
> + hip04_start_tx_timer(priv);
> }
>
> return NETDEV_TX_OK;
> @@ -549,7 +557,7 @@ done:
> /* clean up tx descriptors and start a new timer if necessary */
> tx_remaining = hip04_tx_reclaim(ndev, false);
> if (rx < budget && tx_remaining)
> - hrtimer_start_expires(>tx_coalesce_timer,
> HRTIMER_MODE_REL);
> + hip04_start_tx_timer(priv);
>
> return rx;
> }
> @@ -809,7 +817,6 @@ static int hip04_mac_probe(struct platfo
> struct hip04_priv *priv;
> struct resource *res;
> unsigned int irq;
> - ktime_t txtime;
> int ret;
>
> ndev = alloc_etherdev(sizeof(struct hip04_priv));
> @@ -846,9 +853,6 @@ static int hip04_mac_probe(struct platfo
>*/
> priv->tx_coalesce_frames = TX_DESC_NUM * 3 / 4;
> priv->tx_coalesce_usecs = 200;
> - /* allow timer to fire after half the time at the earliest */
> - txtime = ktime_set(0, priv->tx_coalesce_usecs * NSEC_PER_USEC / 2);
> - hrtimer_set_expires_range(>tx_coalesce_timer, txtime, txtime);
> priv->tx_coalesce_timer.function = tx_done;
>
> priv->map = syscon_node_to_regmap(arg.np);
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] iommu/mediatek: Add mt8173 IOMMU driver
On Tue, Apr 14, 2015 at 3:31 PM, Yong Wu wrote: >> >> >> >> > + >> >> > + piommu->protect_va = devm_kmalloc(piommu->dev, >> >> > MTK_PROTECT_PA_ALIGN*2, >> >> >> >> style: Operators like * should have space on both sides. >> >> >> >> > + GFP_KERNEL); >> >> >> >> Shouldn't dma_alloc_coherent() be used for this? >> > We don't care the data in it. I think they are the same. Could you >> > help tell me why dma_alloc_coherent may be better. >> >> Can you guarantee that at the time you allocate the memory using >> devm_kmalloc() the memory is not dirty (i.e. some write back data are >> stored in CPU cache) and is not going to be written back in some time, >> overwriting data put there by IOMMU hardware? >> > As I noted in the function "mtk_iommu_hw_init": > >/* protect memory,HW will write here while translation fault */ >protectpa = __virt_to_phys(piommu->protect_va); > > We don’t care the content of this buffer, It is ok even though its > data is dirty. > It seem to be a the protect memory. While a translation fault > happened, The iommu HW will overwrite here instead of writing to the > fault physical address which may be 0 or some random address. > Do you mean that it's just a dummy page for hardware behind the IOMMU to access when the mapping is not available? How would that work with potential on demand paging when the hardware needs to be blocked until the mapping is created? Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compiler: add support for gcc 6
On Wed, 2015-04-15 at 07:32 +1000, Anton Blanchard wrote: > gcc has recently bumped its major version and this is causing kernel > build errors. Create include/linux/compiler-gcc6.h which is a copy > of compiler-gcc5.h, minus a few comments that no longer apply. I still think it'd be better to use a single file https://lkml.org/lkml/2014/9/5/693 and https://lkml.org/lkml/2014/9/4/675 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] livepatch: Fix the bug if the function name is larger than KSYM_NAME_LEN-1
On 04/14/15 at 08:41pm, Petr Mladek wrote:
> On Wed 2015-04-15 01:01:39, Minfei Huang wrote:
> > On 04/14/15 at 06:27pm, Petr Mladek wrote:
> > > On Tue 2015-04-14 23:55:36, Minfei Huang wrote:
> > > > On 04/14/15 at 10:11P, Josh Poimboeuf wrote:
> > > > > On Tue, Apr 14, 2015 at 01:45:49PM +0800, Minfei Huang wrote:
> > > > > > On 04/14/15 at 12:32P, Josh Poimboeuf wrote:
> > > > > > > On Tue, Apr 14, 2015 at 01:29:50PM +0800, Minfei Huang wrote:
> > > > > > > >
> > > > > > > > For end user, they may know litter about restriction of
> > > > > > > > kallsyms and
> > > > > > > > livepatch. How can they know the restriction that function name
> > > > > > > > is
> > > > > > > > limited to 127?
> > > > > > >
> > > > > > > As I mentioned above, I think kallsyms.c should fail the build if
> > > > > > > it
> > > > > > > encounters a symbol longer than KSYM_NAME_LEN.
> > > > > > >
> > > > > >
> > > > > > I dont think it is a good idea to handle this case like that. The
> > > > > > function name is only for human recognization. Why the compiler
> > > > > > fails
> > > > > > to build it?
> > > > >
> > > > > Well, the function name isn't only for human recognition.
> > > > > kpatch-build
> > > > > generates patch modules automatically. It assumes that the compiled
> > > > > function name matches the kallsyms name. And I'd guess that a lot of
> > > > > other code (both in-kernel and user space tools) make the same
> > > > > assumption.
> > > > >
> > > > > Not to mention that most humans would also make the same assumption...
> > > >
> > > > Yes. The assumption is correct for most case.
> > > >
> > > > It is significance for livepatch to support extra module, because in my
> > > > opinion kernel is more stable than the third module.
> > > >
> > > > So it is more important, if the livepatch can patch all sorts of patch.
> > > > For dynamic function name, I think it is simple to avoid it.
> > >
> > > Do you have some really existing module with such a crazy long
> > > function names or is this debate pure theoretical, please?
> > >
> >
> > No, I do not have such running module which function name is exceed to
> > 127.
> >
> > Again, we can not predict what end user do to name the function name. I
> > think the overlength function name is valid for linux kernel, if the
> > module can be installed.
>
> My position on this is that using >127 length function names is
> insane. I would be scared to use such a module on a production system.
> If we refuse patching, we actually do a favor for the user.
> Instead of fixing live patch for such a scenario, we should suggest
> the user to use more trustful modules.
Yes, the function name can be changed, before the extra module is
installed to the production system.
We discuss around and around, there are still some confusion with it.
1) How does end user know that livepatch can _not_ support the function
which length is larger than 127. We can not enforce the end user
to know the livepatch and kallsyms code in detail.
2) How does end user use livepatch to patch running extra module, once
the module is running in the production system, if the function name
is insane.
3) The error message is ambiguity, if we try to patch the overlength
function. We can give the error message clearly, once the function
name is overlength.
I think it is better that we can take more time on the people who will
use livepatch frequently.
Attaching a patch to make error message explictly for the overlength
function name.
>From d46a230499303657a914d6939c3afbeff906796c Mon Sep 17 00:00:00 2001
From: Minfei Huang
Date: Wed, 15 Apr 2015 10:02:43 +0800
Subject: [PATCH] livepatch: Make error message explicitly for the overlength
function name
For not, livepatch do not support the function which name is larger than
KSYM_NAME_LEN-1. It may be confusion user with error message
"livepatch: symbol 'xxx(function name)' not found in symbol table".
Make error message explicitly for overlength issue.
Signed-off-by: Minfei Huang
---
kernel/livepatch/core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 3f9f1d6..d1f2404 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -789,6 +789,12 @@ static int klp_init_object(struct klp_patch *patch, struct
klp_object *obj)
return -ENOMEM;
for (func = obj->funcs; func->old_name; func++) {
+ if (strlen(func->old_name) > (KSYM_NAME_LEN-1)) {
+ pr_err("%s is overlength, the max to be supported is %d\n",
+ func->old_name, KSYM_NAME_LEN-1);
+ ret = -EINVAL;
+ goto free;
+ }
ret = klp_init_func(obj, func);
if (ret)
goto free;
--
2.2.2
>
> Best Regards,
> Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 1/3] sched, timer: Remove usages of ACCESS_ONCE in the scheduler
Hi Steven,
On Tue, 2015-04-14 at 19:59 -0400, Steven Rostedt wrote:
> On Tue, 14 Apr 2015 16:09:44 -0700
> Jason Low wrote:
>
>
> > @@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node,
> > int pages, int flags)
> >
> > static void reset_ptenuma_scan(struct task_struct *p)
> > {
> > - ACCESS_ONCE(p->mm->numa_scan_seq)++;
> > + WRITE_ONCE(p->mm->numa_scan_seq, READ_ONCE(p->mm->numa_scan_seq) + 1);
>
> Is the READ_ONCE() inside the WRITE_ONCE() really necessary?
Yeah, I think so to be safe, otherwise, the access of
p->mm->numa_scan_seq in the 2nd parameter doesn't have the volatile
cast.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv6 0/1] Intel Quark X1000 DTS thermal driver
Dear maintainers & communities, This patch introduces DTS thermal driver for Intel Quark X1000. The code implementation is based on intel_soc_dts_thermal.c. Intel Quark X1000 has one on-die DTS with two configurable trip points: critical and hot trip points. However, todate, UEFI BIOS for Quark X1000 uses only critical trip point. UEFI BIOS always lock DTS register before hand-over to Linux kernel. The minimalist thermal design is meant to trigger Linux distro to gracefully power-down the system when its DTS temperature exceeds the configured critical trip point. In anticipation that other variant of Quark platform may come with UEFI BIOS that does not lock DTS register during hand-over, this DTS driver is built with logics to handle such case too. I have tested v4 of the patch on Intel Galileo Gen v2 board and found it satisfactory with logs below: root@quark:/sys/class/thermal/thermal_zone0# echo disabled > mode [ 46.276881] intel_quark_dts_thermal: DTS is locked. Cannot disable DTS -sh: echo: write error: Operation not permitted root@quark:/sys/class/thermal/thermal_zone0# root@quark:/sys/class/thermal/thermal_zone0# cat temp 53 root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_0_temp 105 root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_0_type critical root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_1_temp 20 root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_1_type hot root@quark:/sys/class/thermal/thermal_zone0# cat type quark_dts root@quark:/sys/class/thermal/thermal_zone0# echo 105 > emul_temp [ 179.372981] thermal thermal_zone0: critical temperature reached(0 C),shutting down root@quark:/sys/class/thermal/thermal_zone0# [ OK ] Stopped target Multi-User System. Stopping Telephony service... Stopping Lightning Fast Webserver With Light System Requirements... Stopping Target Communication Framework agent... Stopping Galileo Arduino Layer... [ OK ] Stopped target Login Prompts. Stopping Getty on tty1... Stopping Serial Getty on ttyS1... Stopping Login Service... Stopping D-Bus System Message Bus... Starting Store Sound Card State... [ OK ] Stopped Telephony service. [ OK ] Stopped Galileo Arduino Layer. [ OK ] Stopped Login Service. [ OK ] Stopped D-Bus System Message Bus. [ OK ] Stopped Target Communication Framework agent. [ OK ] Stopped Lightning Fast Webserver With Light System Requirements. [ OK ] Stopped WPA supplicant. [ OK ] Stopped Getty on tty1. [ OK ] Stopped Serial Getty on ttyS1. Please kindly review the patch at your convenient time and provide me feedback for improvement. Appreciate your time and effort. Thank You Ong Boon Leong Intel Corp. --- Changes in v6: * Revised to use the recommended dual license style per feedback from Rui. Thanks! Changes in v5: * Added BSD License as reported by Paul Bolle . Changes in v4: * Fixed unused variable 'aux_entry' as reported by kbuild-...@01.org in line 287 by remove it. * Added reviewed-by tag from Kweh Hock Leong since v3. Changes in v3: * Kconfig dependency changed to X86_INTEL_QUARK Changes in v2: * Fix several commit write-up grammar, choice of words. * Ensure "int ret" in correct order * Add comment to explain DTS register field read/write bit operation * Change to Dual BSD/GPL license * Add logic to ensure safe trip point threshold value being set Ong Boon Leong (1): thermal: intel Quark SoC X1000 DTS thermal driver drivers/thermal/Kconfig | 10 + drivers/thermal/Makefile |1 + drivers/thermal/intel_quark_dts_thermal.c | 473 + 3 files changed, 484 insertions(+) create mode 100644 drivers/thermal/intel_quark_dts_thermal.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv6 1/1] thermal: intel Quark SoC X1000 DTS thermal driver
In Intel Quark SoC X1000, there is one on-die digital temperature sensor(DTS). The DTS offers both hot & critical trip points. However, in current distribution of UEFI BIOS for Quark platform, only critical trip point is configured to be 105 degree Celsius (based on Quark SW ver1.0.1 and hot trip point is not used due to lack of IRQ. There is no active cooling device for Quark SoC, so Quark SoC thermal management logic expects Linux distro to orderly power-off when temperature of the DTS exceeds the configured critical trip point. Kernel param "polling_delay" in milliseconds is used to control the frequency the DTS temperature is read by thermal framework. It defaults to 2-second. To change it, use kernel boot param "intel_quark_dts_thermal.polling_delay=X". User interacts with Quark SoC DTS thermal driver through sysfs via: /sys/class/thermal/thermal_zone0/ For example: - to read DTS temperature $ cat temp - to read critical trip point $ cat trip_point_0_temp - to read trip point type $ cat trip_point_0_type - to emulate temperature raise to test orderly shutdown by Linux distro $ echo 105 > emul_temp Tested-by: Bryan O'Donoghue Signed-off-by: Ong Boon Leong Reviewed-by: Bryan O'Donoghue Reviewed-by: Kweh, Hock Leong --- drivers/thermal/Kconfig | 10 + drivers/thermal/Makefile |1 + drivers/thermal/intel_quark_dts_thermal.c | 473 + 3 files changed, 484 insertions(+) create mode 100644 drivers/thermal/intel_quark_dts_thermal.c diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index af40db0..f72b352 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -261,6 +261,16 @@ config INTEL_SOC_DTS_THERMAL notification methods.The other trip is a critical trip point, which was set by the driver based on the TJ MAX temperature. +config INTEL_QUARK_DTS_THERMAL + tristate "Intel Quark DTS thermal driver" + depends on X86_INTEL_QUARK + help + Enable this to register Intel Quark SoC (e.g. X1000) platform digital + temperature sensor (DTS). For X1000 SoC, it has one on-die DTS. + The DTS will be registered as a thermal zone. There are two trip points: + hot & critical. The critical trip point default value is set by + underlying BIOS/Firmware. + config INT340X_THERMAL tristate "ACPI INT340X thermal drivers" depends on X86 && ACPI diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index fa0dc48..17d3f92 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -35,6 +35,7 @@ obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o obj-$(CONFIG_INTEL_SOC_DTS_THERMAL)+= intel_soc_dts_thermal.o +obj-$(CONFIG_INTEL_QUARK_DTS_THERMAL) += intel_quark_dts_thermal.o obj-$(CONFIG_TI_SOC_THERMAL) += ti-soc-thermal/ obj-$(CONFIG_INT340X_THERMAL) += int340x_thermal/ obj-$(CONFIG_ST_THERMAL) += st/ diff --git a/drivers/thermal/intel_quark_dts_thermal.c b/drivers/thermal/intel_quark_dts_thermal.c new file mode 100644 index 000..4434ec8 --- /dev/null +++ b/drivers/thermal/intel_quark_dts_thermal.c @@ -0,0 +1,473 @@ +/* + * intel_quark_dts_thermal.c + * + * This file is provided under a dual BSD/GPLv2 license. When using or + * redistributing this file, you may do so under either license. + * + * GPL LICENSE SUMMARY + * + * Copyright(c) 2015 Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * Contact Information: + * Ong Boon Leong + * Intel Malaysia, Penang + * + * BSD LICENSE + * + * Copyright(c) 2015 Intel Corporation. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of Intel Corporation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
Re: [PATCH] [PATCH v3] mtd:spi-nor: Add Altera Quad SPI Driver
Hi,
Could you please help me to review this patch?
Thanks
On Mon, Mar 16, 2015 at 4:40 PM, Viet Nga Dao wrote:
> On Mon, Mar 16, 2015 at 4:35 PM, Rafał Miłecki wrote:
>> On 16 March 2015 at 09:16, wrote:
>>> +static struct flash_device flash_devices[] = {
>>> + FLASH_ID("epcq16-nonjedec", 2, 0x15),
>>> + FLASH_ID("epcq32-nonjedec", 2, 0x16),
>>> + FLASH_ID("epcq64-nonjedec", 2, 0x17),
>>> + FLASH_ID("epcq128-nonjedec", 2, 0x18),
>>> + FLASH_ID("epcq256-nonjedec", 2, 0x19),
>>> + FLASH_ID("epcq512-nonjedec", 2, 0x20),
>>
>> You could probably use EPCQ_OPCODE_ID
>>
>>
>>> +
>>> + FLASH_ID("epcs16-nonjedec", 1, 0x14),
>>> + FLASH_ID("epcs64-nonjedec", 1, 0x16),
>>> + FLASH_ID("epcs128-nonjedec", 1, 0x18),
>>
>> And EPCS_OPCODE_ID here.
>>
> Noted
>>
>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>>> index 43bb552..ad0c274 100644
>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>> @@ -683,6 +683,17 @@ static const struct spi_device_id spi_nor_ids[] = {
>>> { "cat25c09", CAT25_INFO( 128, 8, 32, 2, SPI_NOR_NO_ERASE |
>>> SPI_NOR_NO_FR) },
>>> { "cat25c17", CAT25_INFO( 256, 8, 32, 2, SPI_NOR_NO_ERASE |
>>> SPI_NOR_NO_FR) },
>>> { "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE |
>>> SPI_NOR_NO_FR) },
>>> +
>>> + /* Altera EPCQ/EPCS Flashes */
>>> + { "epcq16-nonjedec", INFO(0, 0, 0x1, 32, 0) },
>>> + { "epcq32-nonjedec", INFO(0, 0, 0x1, 64, 0) },
>>> + { "epcq64-nonjedec", INFO(0, 0, 0x1, 128, 0) },
>>> + { "epcq128-nonjedec", INFO(0, 0, 0x1, 256, 0) },
>>> + { "epcq256-nonjedec", INFO(0, 0, 0x1, 512, 0) },
>>> + { "epcq512-nonjedec", INFO(0, 0, 0x1, 1024, 0) },
>>> + { "epcs16-nonjedec", INFO(0, 0, 0x1, 32, 0) },
>>> + { "epcs64-nonjedec", INFO(0, 0, 0x1, 128, 0) },
>>> + { "epcs128-nonjedec", INFO(0, 0, 0x4, 256, 0) },
>>> { },
>>> };
>>
>> But mostly, I just wanted to say I like your integration with spi-nor.
>> Nice work :)
>>
>> --
>> Rafał
>
> Thank you. This is all thanks to you and Brian for helpful comments. I
> learned a lot :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] Input: elan_i2c - Correct the x and y trace number.
The trace number does not need to subtract 1 now. Signed-off-by: Duson Lin --- drivers/input/mouse/elan_i2c_i2c.c |4 ++-- drivers/input/mouse/elan_i2c_smbus.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/input/mouse/elan_i2c_i2c.c b/drivers/input/mouse/elan_i2c_i2c.c index 029941f..550f905 100644 --- a/drivers/input/mouse/elan_i2c_i2c.c +++ b/drivers/input/mouse/elan_i2c_i2c.c @@ -356,8 +356,8 @@ static int elan_i2c_get_num_traces(struct i2c_client *client, return error; } - *x_traces = val[0] - 1; - *y_traces = val[1] - 1; + *x_traces = val[0]; + *y_traces = val[1]; return 0; } diff --git a/drivers/input/mouse/elan_i2c_smbus.c b/drivers/input/mouse/elan_i2c_smbus.c index 06a2bcd..0b04151 100644 --- a/drivers/input/mouse/elan_i2c_smbus.c +++ b/drivers/input/mouse/elan_i2c_smbus.c @@ -268,8 +268,8 @@ static int elan_smbus_get_num_traces(struct i2c_client *client, return error; } - *x_traces = val[1] - 1; - *y_traces = val[2] - 1; + *x_traces = val[1]; + *y_traces = val[2]; return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / Hiberante : optimize swsusp_free()
On Saturday, April 11, 2015 09:20 AM Rafael J. Wysocki worte:
On Wednesday, March 25, 2015 01:49:36 AM Yeon, JeHyeon wrote:
From 6cb5fffc41911a29212be52d4ce7e481f5077ccf Mon Sep 17 00:00:00 2001
From: "Tom(JeHyeon) Yeon"
Date: Thu, 19 Mar 2015 17:10:45 +0900
Subject: [PATCH] PM / Hiberante : optimize swsusp_free()
Our team developed the snapshot booting.
Fisrt of all, make a snapshot image, compress it and finally save it
in the storage(like mmc).
When the system is booting next time, bootloader read it from mmc,
decompress it and jump to the kernel.
In this circumstance, mili seconds is very important.
So, I prepared this patch, but not applied because I missed the time
to apply it.
And, I came across to find commit fdd64ed.
It's very similar to the patch I prepared.
So the part of the changelog above this line is not really relevant.
But the below is OK.
Ok, I'll get rid of the upper changelog.
I think do { ... } while (fb_pfn != fr_pfn) operation is very similar
to my patch. but, it takes a little more time to iterate.
So suggest to iterate one of two maps and check whether the other map
has the same pfn, finally free the page.
Signed-off-by: Tom(JeHyeon) Yeon
As for the patch itself ->
---
kernel/power/snapshot.c | 43 ++-
1 file changed, 10 insertions(+), 33 deletions(-)
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index c24d5a2..a1ad801 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -726,14 +726,6 @@ static void memory_bm_clear_bit(struct memory_bitmap *bm,
unsigned long pfn)
clear_bit(bit, addr);
}
-static void memory_bm_clear_current(struct memory_bitmap *bm)
-{
- int bit;
-
- bit = max(bm->cur.node_bit - 1, 0);
- clear_bit(bit, bm->cur.node->data);
-}
-
static int memory_bm_test_bit(struct memory_bitmap *bm, unsigned long pfn)
{
void *addr;
@@ -1342,36 +1334,21 @@ static struct memory_bitmap copy_bm;
void swsusp_free(void)
{
- unsigned long fb_pfn, fr_pfn;
+ unsigned long pfn;
if (!forbidden_pages_map || !free_pages_map)
goto out;
memory_bm_position_reset(forbidden_pages_map);
- memory_bm_position_reset(free_pages_map);
-
-loop:
- fr_pfn = memory_bm_next_pfn(free_pages_map);
- fb_pfn = memory_bm_next_pfn(forbidden_pages_map);
-
- /*
-* Find the next bit set in both bitmaps. This is guaranteed to
-* terminate when fb_pfn == fr_pfn == BM_END_OF_MAP.
-*/
- do {
- if (fb_pfn < fr_pfn)
- fb_pfn = memory_bm_next_pfn(forbidden_pages_map);
- if (fr_pfn < fb_pfn)
- fr_pfn = memory_bm_next_pfn(free_pages_map);
- } while (fb_pfn != fr_pfn);
-
- if (fr_pfn != BM_END_OF_MAP && pfn_valid(fr_pfn)) {
- struct page *page = pfn_to_page(fr_pfn);
-
- memory_bm_clear_current(forbidden_pages_map);
- memory_bm_clear_current(free_pages_map);
- __free_page(page);
- goto loop;
+ for ( ; ; ) {
+ pfn = memory_bm_next_pfn(forbidden_pages_map);
+ if (BM_END_OF_MAP == pfn)
-> First, the usual way of writing such things is
if (pfn == BM_END_OF_MAP)
(ie. the variable on the left-hand side of the operator).
Is there any rules for this this in kernel?
Sometime, human makes a mistake like "if (pfn = BM_END_OF_MAP)"
that's why I wrote like that even though the compiler may notice about it.
Second, don't you need to do the pfn_valid() check here too?
hmm. I can add pfn_valid() check. but I don't think that pfn_valid()
should be checked in this stage.
I think forbidden_pages_map & free_pages_map should be always valid.
Is there any possibility those are not valid in this stage?
+ break;
+ if (memory_bm_test_bit(free_pages_map, pfn)) {
+ memory_bm_clear_bit(forbidden_pages_map, pfn);
+ memory_bm_clear_bit(free_pages_map, pfn);
+ __free_page(pfn_to_page(pfn));
+ }
}
out:
thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] kdbus for 4.1-rc1
On Mon, Apr 13, 2015 at 1:22 PM, Al Viro wrote: > On Mon, Apr 13, 2015 at 09:42:17PM +0200, Greg Kroah-Hartman wrote: >> > I remain opposed to this half thought out trash of an ABI for the >> > meta-data. >> >> You don't have to enable the metadata if you don't want to use it, it's >> an option :) > > OK, _that_ argument needs to be stomped out. It had been used before, > and it was a deliberate scam. There is no such thing as optional kernel > interface, especially when udev/dbus/systemd crowd is nearby. We'd been > through that excuse before; remember how devtmpfs was pushed in as "optional"? > > This is a huge red flag. On the level of "I need your account information > to transfer $200M you might have inherited from my deceased client". > > Just to recap how it went the last time around: Kay kept pushing his piece of > code into the tree, claiming that it was optional, that nobody who doesn't > like it has to enable it, so what's the problem? OK, in it went. And pretty > soon udev (maintained by the same... meticulously honorable person) had > stopped working on the kernels that didn't have that enabled. > > We had been there before. To paraphrase another... meticulously honorable > person, "if you didn't want something relied upon, why have you put it into > the > kernel?" Said person is on the record as having no problem whatsoever with > adding dependencies to the bottom of userland stack. It appears that, if kdbus is merged, upstream udev may end up requiring it: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html Grumble. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the vfs tree with the ext4 tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in
fs/ext4/symlink.c between commit 48e72c7a0127 ("ext4 crypto: Add
symlink encryption") from the ext4 tree and commit 5dd3dc06371a ("VFS:
normal filesystems (and lustre): d_inode() annotations") from the vfs
tree.
[The ext4 tree commit has been modified.]
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/ext4/symlink.c
index a7b3a646dde0,57f50091b8d1..
--- a/fs/ext4/symlink.c
+++ b/fs/ext4/symlink.c
@@@ -21,100 -21,11 +21,100 @@@
#include
#include "ext4.h"
#include "xattr.h"
+#include "ext4_crypto.h"
+#ifdef CONFIG_EXT4_FS_ENCRYPTION
static void *ext4_follow_link(struct dentry *dentry, struct nameidata *nd)
{
+ struct page *cpage = NULL;
+ char *caddr, *paddr = NULL;
+ struct ext4_str cstr, pstr;
- struct inode *inode = dentry->d_inode;
++ struct inode *inode = d_inode(dentry);
+ struct ext4_fname_crypto_ctx *ctx = NULL;
+ struct ext4_encrypted_symlink_data *sd;
+ loff_t size = min_t(loff_t, i_size_read(inode), PAGE_SIZE - 1);
+ int res;
+ u32 plen, max_size = inode->i_sb->s_blocksize;
+
+ if (!ext4_encrypted_inode(inode))
+ return page_follow_link_light(dentry, nd);
+
+ ctx = ext4_get_fname_crypto_ctx(inode, inode->i_sb->s_blocksize);
+ if (IS_ERR(ctx))
+ return ctx;
+
+ if (ext4_inode_is_fast_symlink(inode)) {
- caddr = (char *) EXT4_I(dentry->d_inode)->i_data;
- max_size = sizeof(EXT4_I(dentry->d_inode)->i_data);
++ caddr = (char *) EXT4_I(d_inode(dentry))->i_data;
++ max_size = sizeof(EXT4_I(d_inode(dentry))->i_data);
+ } else {
+ cpage = read_mapping_page(inode->i_mapping, 0, NULL);
+ if (IS_ERR(cpage)) {
+ ext4_put_fname_crypto_ctx();
+ return cpage;
+ }
+ caddr = kmap(cpage);
+ caddr[size] = 0;
+ }
+
+ /* Symlink is encrypted */
+ sd = (struct ext4_encrypted_symlink_data *)caddr;
+ cstr.name = sd->encrypted_path;
+ cstr.len = le32_to_cpu(sd->len);
+ if ((cstr.len +
+ sizeof(struct ext4_encrypted_symlink_data) - 1) >
+ max_size) {
+ /* Symlink data on the disk is corrupted */
+ res = -EIO;
+ goto errout;
+ }
+ plen = (cstr.len < EXT4_FNAME_CRYPTO_DIGEST_SIZE*2) ?
+ EXT4_FNAME_CRYPTO_DIGEST_SIZE*2 : cstr.len;
+ paddr = kmalloc(plen + 1, GFP_NOFS);
+ if (!paddr) {
+ res = -ENOMEM;
+ goto errout;
+ }
+ pstr.name = paddr;
+ res = _ext4_fname_disk_to_usr(ctx, , );
+ if (res < 0)
+ goto errout;
+ /* Null-terminate the name */
+ if (res <= plen)
+ paddr[res] = '\0';
+ nd_set_link(nd, paddr);
+ ext4_put_fname_crypto_ctx();
+ if (cpage) {
+ kunmap(cpage);
+ page_cache_release(cpage);
+ }
+ return NULL;
+errout:
+ ext4_put_fname_crypto_ctx();
+ if (cpage) {
+ kunmap(cpage);
+ page_cache_release(cpage);
+ }
+ kfree(paddr);
+ return ERR_PTR(res);
+}
+
+static void ext4_put_link(struct dentry *dentry, struct nameidata *nd,
+void *cookie)
+{
+ struct page *page = cookie;
+
+ if (!page) {
+ kfree(nd_get_link(nd));
+ } else {
+ kunmap(page);
+ page_cache_release(page);
+ }
+}
+#endif
+
+static void *ext4_follow_fast_link(struct dentry *dentry, struct nameidata
*nd)
+{
- struct ext4_inode_info *ei = EXT4_I(dentry->d_inode);
+ struct ext4_inode_info *ei = EXT4_I(d_inode(dentry));
nd_set_link(nd, (char *) ei->i_data);
return NULL;
}
pgp9s5UaJtXo4.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 1/4] of: unittest: overlay: Keep track of created overlays
On Tue, Apr 7, 2015 at 2:23 PM, Pantelis Antoniou
wrote:
> During the course of the overlay selftests some of them remain
> applied. While this does not pose a real problem, make sure you track
> them and destroy them at the end of the test.
>
> Signed-off-by: Pantelis Antoniou
I've applied this one. Patch 2 is okay, but the rest still needs some work.
Rob
> ---
> drivers/of/unittest.c | 62
> +++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index fdb5977..995cc73 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +#include
> +
> #include "of_private.h"
>
> static struct unittest_results {
> @@ -1095,6 +1097,59 @@ static const char *overlay_path(int nr)
>
> static const char *bus_path = "/testcase-data/overlay-node/test-bus";
>
> +/* it is guaranteed that overlay ids are assigned in sequence */
> +#define MAX_UNITTEST_OVERLAYS 256
> +static unsigned long overlay_id_bits[BITS_TO_LONGS(MAX_UNITTEST_OVERLAYS)];
> +static int overlay_first_id = -1;
> +
> +static void of_unittest_track_overlay(int id)
> +{
> + if (overlay_first_id < 0)
> + overlay_first_id = id;
> + id -= overlay_first_id;
> +
> + /* we shouldn't need that many */
> + BUG_ON(id >= MAX_UNITTEST_OVERLAYS);
> + overlay_id_bits[BIT_WORD(id)] |= BIT_MASK(id);
> +}
> +
> +static void of_unittest_untrack_overlay(int id)
> +{
> + if (overlay_first_id < 0)
> + return;
> + id -= overlay_first_id;
> + BUG_ON(id >= MAX_UNITTEST_OVERLAYS);
> + overlay_id_bits[BIT_WORD(id)] &= ~BIT_MASK(id);
> +}
> +
> +static void of_unittest_destroy_tracked_overlays(void)
> +{
> + int id, ret, defers;
> +
> + if (overlay_first_id < 0)
> + return;
> +
> + /* try until no defers */
> + do {
> + defers = 0;
> + /* remove in reverse order */
> + for (id = MAX_UNITTEST_OVERLAYS - 1; id >= 0; id--) {
> + if (!(overlay_id_bits[BIT_WORD(id)] & BIT_MASK(id)))
> + continue;
> +
> + ret = of_overlay_destroy(id + overlay_first_id);
> + if (ret != 0) {
> + defers++;
> + pr_warn("%s: overlay destroy failed for
> #%d\n",
> + __func__, id + overlay_first_id);
> + continue;
> + }
> +
> + overlay_id_bits[BIT_WORD(id)] &= ~BIT_MASK(id);
> + }
> + } while (defers > 0);
> +}
> +
> static int of_unittest_apply_overlay(int unittest_nr, int overlay_nr,
> int *overlay_id)
> {
> @@ -1116,6 +1171,7 @@ static int of_unittest_apply_overlay(int unittest_nr,
> int overlay_nr,
> goto out;
> }
> id = ret;
> + of_unittest_track_overlay(id);
>
> ret = 0;
>
> @@ -1329,6 +1385,7 @@ static void of_unittest_overlay_6(void)
> return;
> }
> ov_id[i] = ret;
> + of_unittest_track_overlay(ov_id[i]);
> }
>
> for (i = 0; i < 2; i++) {
> @@ -1353,6 +1410,7 @@ static void of_unittest_overlay_6(void)
> PDEV_OVERLAY));
> return;
> }
> + of_unittest_untrack_overlay(ov_id[i]);
> }
>
> for (i = 0; i < 2; i++) {
> @@ -1397,6 +1455,7 @@ static void of_unittest_overlay_8(void)
> return;
> }
> ov_id[i] = ret;
> + of_unittest_track_overlay(ov_id[i]);
> }
>
> /* now try to remove first overlay (it should fail) */
> @@ -1419,6 +1478,7 @@ static void of_unittest_overlay_8(void)
> PDEV_OVERLAY));
> return;
> }
> + of_unittest_untrack_overlay(ov_id[i]);
> }
>
> unittest(1, "overlay test %d passed\n", 8);
> @@ -1841,6 +1901,8 @@ static void __init of_unittest_overlay(void)
> of_unittest_overlay_i2c_cleanup();
> #endif
>
> + of_unittest_destroy_tracked_overlays();
> +
> out:
> of_node_put(bus_np);
> }
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
On Tue, Mar 17, 2015 at 06:41:51PM -0700, Tony Lindgren wrote: > Yeah agreed. I suggest discussing the binding and the generic > parsing code for it first :) > > It seems with the generic binding the actual driver should be > just the hardware specific code hopefully. Did this thread go anywhere in the last month? I am certainly looking forward to seeing what the resolution is to this, given for our use the boot loader setup is not appealing at all. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/2] perf: report/annotate: fix segfault problem.
Ping?
On 2015/4/10 11:53, Wang Nan wrote:
> perf report and perf annotate are easy to trigger segfault if trace data
> contain kernel module information like this:
>
> # perf report -D -i ./perf.data
> ...
> 0 0 0x188 [0x50]: PERF_RECORD_MMAP -1/0: [0xffbff1018000(0xf068000) @
> 0]: x [test_module]
> ...
>
> # perf report -i ./perf.data --objdump=/path/to/objdump
> --kallsyms=/path/to/kallsyms
>
> perf: Segmentation fault
> backtrace
> /path/to/perf[0x503478]
> /lib64/libc.so.6(+0x3545f)[0x7fb201f3745f]
> /path/to/perf[0x499b56]
> /path/to/perf(dso__load_kallsyms+0x13c)[0x49b56c]
> /path/to/perf(dso__load+0x72e)[0x49c21e]
> /path/to/perf(map__load+0x6e)[0x4ae9ee]
> /path/to/perf(thread__find_addr_map+0x24c)[0x47deec]
> /path/to/perf(perf_event__preprocess_sample+0x88)[0x47e238]
> /path/to/perf[0x43ad02]
> /path/to/perf[0x4b55bc]
> /path/to/perf(ordered_events__flush+0xca)[0x4b57ea]
> /path/to/perf[0x4b1a01]
> /path/to/perf(perf_session__process_events+0x3be)[0x4b428e]
> /path/to/perf(cmd_report+0xf11)[0x43bfc1]
> /path/to/perf[0x474702]
> /path/to/perf(main+0x5f5)[0x42de95]
> /lib64/libc.so.6(__libc_start_main+0xf4)[0x7fb201f23bd4]
> /path/to/perf[0x42dfc4]
>
> This is because __kmod_path__parse regard '[' leading name as kernel
> instead of kernel module. If perf.data contain build information and
> the buildid of such modules can be found, the DSO of it will be treated
> as kernel, not kernel module. It will then be passed to
> dso__load_kernel_sym() then dso__load_kcore() because of --kallsyms
> argument. The segfault is triggered because the kmap structure is not
> initialized.
>
> Although in --vmlinux case such segfault can be avoided, the symbols in
> the kernel module are unable to be retrived since the attribute of DSO
> is incorrect.
>
> This patch fixes __kmod_path__parse, make it to treat names like
> '[test_module]' as kernel modules.
>
> kmod-path.c is also update to reflect the above changes.
>
> Signed-off-by: Wang Nan
> ---
>
> Different from v4: checks cpumode in is_kernel_module(), makes code simpler.
>Appends tests of is_kernel_module().
> ---
> tools/perf/tests/kmod-path.c | 72
>
> tools/perf/util/dso.c| 42 +++---
> tools/perf/util/dso.h| 2 +-
> tools/perf/util/header.c | 8 ++---
> tools/perf/util/machine.c| 16 +-
> 5 files changed, 130 insertions(+), 10 deletions(-)
>
> diff --git a/tools/perf/tests/kmod-path.c b/tools/perf/tests/kmod-path.c
> index e8d7cbb..08c433b 100644
> --- a/tools/perf/tests/kmod-path.c
> +++ b/tools/perf/tests/kmod-path.c
> @@ -34,9 +34,21 @@ static int test(const char *path, bool alloc_name, bool
> alloc_ext,
> return 0;
> }
>
> +static int test_is_kernel_module(const char *path, int cpumode, bool expect)
> +{
> + TEST_ASSERT_VAL("is_kernel_module",
> + (!!is_kernel_module(path, cpumode)) == (!!expect));
> + pr_debug("%s (cpumode: %d) - is_kernel_module: %s\n",
> + path, cpumode, expect ? "true" : "false");
> + return 0;
> +}
> +
> #define T(path, an, ae, k, c, n, e) \
> TEST_ASSERT_VAL("failed", !test(path, an, ae, k, c, n, e))
>
> +#define M(path, c, e) \
> + TEST_ASSERT_VAL("failed", !test_is_kernel_module(path, c, e))
> +
> int test__kmod_path__parse(void)
> {
> /* pathalloc_name alloc_ext kmod comp name
> ext */
> @@ -44,30 +56,90 @@ int test__kmod_path__parse(void)
> T("///x-x.ko", false , true , true, false, NULL ,
> NULL);
> T("///x-x.ko", true , false , true, false, "[x_x]",
> NULL);
> T("///x-x.ko", false , false , true, false, NULL ,
> NULL);
> + M("///x-x.ko", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
> + M("///x-x.ko", PERF_RECORD_MISC_KERNEL, true);
> + M("///x-x.ko", PERF_RECORD_MISC_USER, false);
>
> /* pathalloc_name alloc_ext kmod comp name ext */
> T("///x.ko.gz", true , true , true, true, "[x]", "gz");
> T("///x.ko.gz", false, true , true, true, NULL , "gz");
> T("///x.ko.gz", true , false , true, true, "[x]", NULL);
> T("///x.ko.gz", false, false , true, true, NULL , NULL);
> + M("///x.ko.gz", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
> + M("///x.ko.gz", PERF_RECORD_MISC_KERNEL, true);
> + M("///x.ko.gz", PERF_RECORD_MISC_USER, false);
>
> /* path alloc_name alloc_ext kmod comp nameext */
> T("///x.gz", true , true , false, true, "x.gz" ,"gz");
> T("///x.gz", false , true , false, true, NULL ,"gz");
> T("///x.gz", true , false, false, true, "x.gz" , NULL);
> T("///x.gz",
Re: [PATCH v2 3/4] of: overlay: Add sysfs attributes
On Tue, Apr 7, 2015 at 2:23 PM, Pantelis Antoniou
wrote:
> Implement a number of sysfs attributes for overlays.
>
> * A throw once master enable switch to protect against any
> further overlay applications if the administrator desires so.
This one should be a separate patch.
> * A per overlay targets sysfs attribute listing the targets of
> the installed overlay.
What are targets? "targets lists targets" does not help me. The
documentation doesn't help me either.
> * A per overlay can_remove sysfs attribute that reports whether
> the overlay can be removed or not due to another overlapping overlay.
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/of/overlay.c | 167
> ++-
> 1 file changed, 166 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index f17f5ef..c54d097 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> #include "of_private.h"
>
> @@ -55,8 +56,12 @@ struct of_overlay {
> struct kobject kobj;
> };
>
> +/* master enable switch; once set to 0 can't be re-enabled */
> +static atomic_t ov_enable = ATOMIC_INIT(1);
> +
> static int of_overlay_apply_one(struct of_overlay *ov,
> struct device_node *target, const struct device_node
> *overlay);
> +static int overlay_removal_is_ok(struct of_overlay *ov);
>
> static int of_overlay_apply_single_property(struct of_overlay *ov,
> struct device_node *target, struct property *prop)
> @@ -345,6 +350,144 @@ static struct kobj_type of_overlay_ktype = {
>
> static struct kset *ov_kset;
>
> +static ssize_t enable_read(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t offset, size_t count)
> +{
> + char tbuf[3];
> +
> + if (offset < 0)
> + return -EINVAL;
> +
> + if (offset >= sizeof(tbuf))
> + return 0;
> +
> + if (count > sizeof(tbuf) - offset)
> + count = sizeof(tbuf) - offset;
> +
> + /* fill in temp */
> + tbuf[0] = '0' + atomic_read(_enable);
> + tbuf[1] = '\n';
> + tbuf[2] = '\0';
> +
> + /* copy to buffer */
> + memcpy(buf, tbuf + offset, count);
> +
> + return count;
> +}
> +
> +static ssize_t enable_write(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t off, size_t count)
> +{
> + unsigned int new_enable;
> +
> + if (off != 0 || (buf[0] != '0' && buf[0] != '1'))
> + return -EINVAL;
> +
> + new_enable = (unsigned int)(buf[0] - '0');
> + if (new_enable > 1)
> + return -EINVAL;
> +
> + /* NOP for same value */
> + if (new_enable == atomic_read(_enable))
> + return count;
> +
> + /* if we've disabled it, no going back */
> + if (atomic_read(_enable) == 0)
> + return -EPERM;
> +
> + atomic_set(_enable, new_enable);
> + return count;
> +}
> +
> +/* just a single char + '\n' + '\0' */
> +static BIN_ATTR_RW(enable, 3);
Why are you using bin attribute? You are complicating the
implementation needlessly.
> +
> +static ssize_t targets_read(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t offset, size_t count)
> +{
> + struct of_overlay *ov = kobj_to_overlay(kobj);
> + struct of_overlay_info *ovinfo;
> + char *tmpbuf, *s, *e;
> + const char *name;
> + ssize_t ret;
> + int i, len;
> +
> + /* allocate work buffer; we know that PAGE_SIZE is enough */
> + tmpbuf = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (tmpbuf == NULL)
> + return -ENOMEM;
> +
> + s = tmpbuf;
> + e = tmpbuf + PAGE_SIZE;
> +
> + mutex_lock(_mutex);
> +
> + /* targets */
> + for (i = 0; i < ov->count; i++) {
> + ovinfo = >ovinfo_tab[i];
> +
> + name = of_node_full_name(ovinfo->target);
> + len = strlen(name);
> + if (s + len + 1 >= e)
> + return -ENOMEM;
Leaking memory here and holding the mutex.
> + memcpy(s, name, len);
> + s += len;
> + *s++ = '\n';
> + }
> + if (s + 1 >= e)
> + return -ENOMEM;
And here.
> + *s++ = '\0';
> +
> + /* the buffer is zero terminated */
> + len = s - tmpbuf;
> +
> + mutex_unlock(_mutex);
> +
> + /* perform the read */
> + ret = memory_read_from_buffer(buf, count, , tmpbuf, len);
> +
> + /* free the temporary buffer */
> + kfree(tmpbuf);
> +
> + return ret;
> +}
> +
> +/* targets property */
> +static BIN_ATTR_RO(targets, PAGE_SIZE);
> +
> +static ssize_t can_remove_read(struct file *filp, struct
Re: linux-next: build failure after merge of the tip tree
Hi all,
On Wed, 8 Apr 2015 15:03:27 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann
> wrote:
> >
> > On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> > > On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> > >> [ Cc'ing Dave, fyi ]
> > >>
> > >> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> > >>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
> > >>> wrote:
> > On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> > > * Stephen Rothwell wrote:
> > >
> > >> After merging the tip tree, today's linux-next build (powerpc
> > >> ppc64_defconfig) failed like this:
> > >>
> > >> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> > >> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
> > >> member named 'prog_type'
> > >> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > >> ^
> > >>
> > >> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> > >> attached to kprobes").
> > >
> > > Note, this must be some (rarely triggered) aspect of the ppc64
> > > defconfig that neither x86 randconfigs nor most other arch defconfigs
> > > expose?
> >
> > Note, this is a merge conflict with the work that went via net-next
> > tree,
> > i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
> > bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
> >
> > You should be able to resolve it in linux-next by changing the test to:
> >
> > if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
> > >>>
> > >>> Thanks Daniel, I will do that tomorrow. Someone will have to remember
> > >>> to tell Linus.
> > >>
> > >> Yes, indeed, depending which tree is merged first.
> > >
> > > Daniel analysis is correct, but the fix for kernel/events/core.c
> > > should be:
> > > - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > > + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> > > instead of 'prog->prog_type'
> >
> > Yes, absolutely, thanks!
>
> So I have applied that as a merge fix patch.
This patch is now needed when the net-next tree is merged with Linus'
tree.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp8FB_rqTH9Y.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the ftrace tree with the net-next tree
Hi all,
On Mon, 13 Apr 2015 17:52:24 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the ftrace tree got a conflict in
> drivers/net/wireless/iwlwifi/iwl-devtrace.h between commit 7e1223b50089
> ("iwlwifi: mvm: new Alive / error table API") from the net-next tree
> and commit c5ef935d01a2 ("iwlwifi: Move each system tracepoints to
> their own header") from the ftrace tree.
>
> I fixed it up (see patch below, since this code was moved to a new file)
> and can carry the fix as necessary (no action is required).
>
> From: Stephen Rothwell
> Date: Mon, 13 Apr 2015 17:21:30 +1000
> Subject: [PATCH] iwlwifi: mvm: fix up for tracing split
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
> b/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
> index 6cb66a988271..223b8752f924 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
> +++ b/drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
> @@ -116,11 +116,11 @@ TRACE_EVENT(iwlwifi_dev_ucode_error,
> TP_PROTO(const struct device *dev, u32 desc, u32 tsf_low,
>u32 data1, u32 data2, u32 line, u32 blink1,
>u32 blink2, u32 ilink1, u32 ilink2, u32 bcon_time,
> - u32 gp1, u32 gp2, u32 gp3, u32 ucode_ver, u32 hw_ver,
> + u32 gp1, u32 gp2, u32 gp3, u32 major, u32 minor, u32 hw_ver,
>u32 brd_ver),
> TP_ARGS(dev, desc, tsf_low, data1, data2, line,
> blink1, blink2, ilink1, ilink2, bcon_time, gp1, gp2,
> - gp3, ucode_ver, hw_ver, brd_ver),
> + gp3, major, minor, hw_ver, brd_ver),
> TP_STRUCT__entry(
> DEV_ENTRY
> __field(u32, desc)
> @@ -136,7 +136,8 @@ TRACE_EVENT(iwlwifi_dev_ucode_error,
> __field(u32, gp1)
> __field(u32, gp2)
> __field(u32, gp3)
> - __field(u32, ucode_ver)
> + __field(u32, major)
> + __field(u32, minor)
> __field(u32, hw_ver)
> __field(u32, brd_ver)
> ),
> @@ -155,21 +156,22 @@ TRACE_EVENT(iwlwifi_dev_ucode_error,
> __entry->gp1 = gp1;
> __entry->gp2 = gp2;
> __entry->gp3 = gp3;
> - __entry->ucode_ver = ucode_ver;
> + __entry->major = major;
> + __entry->minor = minor;
> __entry->hw_ver = hw_ver;
> __entry->brd_ver = brd_ver;
> ),
> TP_printk("[%s] #%02d %010u data 0x%08X 0x%08X line %u, "
> "blink 0x%05X 0x%05X ilink 0x%05X 0x%05X "
> - "bcon_tm %010u gp 0x%08X 0x%08X 0x%08X uCode 0x%08X "
> - "hw 0x%08X brd 0x%08X",
> + "bcon_tm %010u gp 0x%08X 0x%08X 0x%08X major 0x%08X "
> + "minor 0x%08X hw 0x%08X brd 0x%08X",
> __get_str(dev), __entry->desc, __entry->tsf_low,
> __entry->data1,
> __entry->data2, __entry->line, __entry->blink1,
> __entry->blink2, __entry->ilink1, __entry->ilink2,
> __entry->bcon_time, __entry->gp1, __entry->gp2,
> - __entry->gp3, __entry->ucode_ver, __entry->hw_ver,
> - __entry->brd_ver)
> + __entry->gp3, __entry->major, __entry->minor,
> + __entry->hw_ver, __entry->brd_ver)
> );
>
> TRACE_EVENT(iwlwifi_dev_ucode_event,
This patch is now needed when the net-next tree is merged with Linus'
tree ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpn6wxDilwxX.pgp
Description: OpenPGP digital signature
[PATCH v2 1/1] stmmac: fix oops on rmmod after assigning ip addr
An oops exists in the flow of stmmac_release(). phy_ethtool_get_wol() depends on phydev->drv. phydev->drv will be null after stmmac_mdio_unreg() completes. Steps to reproduce on Quark X1000: 1. ifconfig eth0 192.168.0.1 2. rmmod stmmac_pci To fix this stmmac_mdio_unreg() should be run after unregister_netdev(). Signed-off-by: Bryan O'Donoghue Reported-by: Dan O'Donovan --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index a0ea84f..3ab3e4a8 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -2958,14 +2958,14 @@ int stmmac_dvr_remove(struct net_device *ndev) priv->hw->dma->stop_tx(priv->ioaddr); stmmac_set_mac(priv->ioaddr, false); - if (priv->pcs != STMMAC_PCS_RGMII && priv->pcs != STMMAC_PCS_TBI && - priv->pcs != STMMAC_PCS_RTBI) - stmmac_mdio_unregister(ndev); netif_carrier_off(ndev); unregister_netdev(ndev); if (priv->stmmac_rst) reset_control_assert(priv->stmmac_rst); clk_disable_unprepare(priv->stmmac_clk); + if (priv->pcs != STMMAC_PCS_RGMII && priv->pcs != STMMAC_PCS_TBI && + priv->pcs != STMMAC_PCS_RTBI) + stmmac_mdio_unregister(ndev); free_netdev(ndev); return 0; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/1] stmmac: rmmod oops after ifconfig
We have an oops with stmmac on Quark X1000/Galileo, triggered by rmmod after ifconfig. Fix for issue contained in next mail. root@clanton:~# ifconfig eth0 192.168.0.1 root@clanton:~# rmmod stmmac_pci [ 39.257871] stmmac_dvr_remove: removing driver [ 39.263618] BUG: unable to handle kernel NULL pointer dereference at 0060 [ 39.271030] IP: [] phy_ethtool_get_wol+0x2/0x20 [ 39.272391] *pdpt = 0e682001 *pde = [ 39.272391] Oops: [#1] [ 39.272391] Modules linked in: evdev usbhid btusb bluetooth iwlwifi cfg80211 rfkill ad7298 industrialio_triggered_buffer kfifo_buf industrialio spi_s [ 39.272391] CPU: 0 PID: 1245 Comm: rmmod Not tainted 4.0.0 #26 [ 39.272391] Hardware name: Intel Corp. QUARK/Galileo, BIOS 0x0350 01/01/2014 [ 39.272391] task: ce52a9e0 ti: cea64000 task.ti: cea64000 [ 39.272391] EIP: 0060:[] EFLAGS: 00010292 CPU: 0 [ 39.272391] EIP is at phy_ethtool_get_wol+0x2/0x20 [ 39.272391] EAX: ce59e400 EBX: ce59e400 ECX: EDX: cea65ddc [ 39.272391] ESI: EDI: cea65e80 EBP: cea65df8 ESP: cea65dd8 [ 39.272391] DS: 007b ES: 007b FS: GS: 0033 SS: 0068 [ 39.272391] CR0: 8005003b CR2: 0060 CR3: 0e641000 CR4: 00100030 [ 39.272391] Stack: [ 39.272391] c1255908 0005 ce59e400 ce85b4e0 [ 39.272391] cea65e04 c125597c ce59e400 cea65e10 c12559cf ce85b000 cea65e24 e07a9dd8 [ 39.272391] cea65e38 ce85b000 cea65e80 cea65e44 c12a7639 cea0cc60 cdd4a180 c009ad00 [ 39.272391] Call Trace: [ 39.272391] [] ? phy_suspend+0x38/0x70 [ 39.272391] [] phy_detach+0x3c/0x60 [ 39.272391] [] phy_disconnect+0x2f/0x40 [ 39.272391] [] stmmac_release+0x38/0x150 [stmmac] [ 39.272391] [] __dev_close_many+0x69/0xb0 [ 39.272391] [] dev_close_many+0x5d/0xd0 [ 39.272391] [] rollback_registered_many+0xda/0x240 [ 39.272391] [] rollback_registered+0x1f/0x30 [ 39.272391] [] unregister_netdevice_queue+0x47/0xb0 [ 39.272391] [] ? mutex_lock+0xb/0x19 [ 39.272391] [] unregister_netdev+0x14/0x20 [ 39.272391] [] stmmac_dvr_remove+0x6d/0xb0 [stmmac] [ 39.272391] [] stmmac_pci_remove+0xe/0x10 [stmmac_pci] [ 39.272391] [] pci_device_remove+0x28/0xa0 [ 39.272391] [] __device_release_driver+0x5a/0xb0 [ 39.272391] [] driver_detach+0x6f/0x80 [ 39.272391] [] bus_remove_driver+0x3b/0x80 [ 39.272391] [] driver_unregister+0x23/0x60 [ 39.272391] [] ? find_module_all+0x5a/0x80 [ 39.272391] [] pci_unregister_driver+0xf/0x50 [ 39.272391] [] stmmac_pci_driver_exit+0xd/0xc3a [stmmac_pci] [ 39.272391] [] SyS_delete_module+0x15c/0x1b0 [ 39.272391] [] syscall_call+0x7/0x7 [ 39.272391] Code: 42 12 31 c0 c3 8d 74 26 00 8b 08 8b 49 5c 85 c9 74 07 55 89 e5 ff d1 5d c3 b8 a1 ff ff ff c3 8d 76 00 8d bc 27 00 00 00 00 8b 08 <0 [ 39.272391] EIP: [] phy_ethtool_get_wol+0x2/0x20 SS:ESP 0068:cea65dd8 [ 39.272391] CR2: 0060 [ 39.551363] ---[ end trace 98d1260353bf4fec ]--- Killed Bryan O'Donoghue (1): stmmac: bugfix oops on rmmod after ifconfig drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] pin control bulk changes for v4.1
On Tue, Apr 14, 2015 at 7:57 AM, Linus Walleij wrote: > Hi Linus, > > here is the big pull request for v4.1 pin control changes. It is very clearly broken: warning: (PINCTRL_AT91 && PINCTRL_MESON && PINCTRL_NOMADIK && PINCTRL_MTK_COMMON && GPIO_TB10X) selects OF_GPIO which has unmet direct dependencies (GPIOLIB && OF) and you'll need to add the proper "depends on OF && GPIOLIB". I pulled it because it still ends up working for my normal test-cases, but it's wrong. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] ACPI and power management updates for v4.1-rc1
On Wednesday, April 15, 2015 02:56:27 AM Rafael J. Wysocki wrote: > Hi Linus, > > Please pull from > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ > pm+acpi-4.1-rc1 > > to receive the first batch of power management and ACPI material for > v4.1-rc1 with top-most commit b5e82233cab43c25fc0a1c28d9136a086db4aa52 A mistake here. That should be commit 518b4e272d99dcb13699b229ea480bc845c141f6. Should I resend? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On 04/10/15 at 04:42pm, Li, Zhen-Hua wrote: > This patchset is an update of Bill Sumner's patchset, implements a fix for: > If a kernel boots with intel_iommu=on on a system that supports intel vt-d, > when a panic happens, the kdump kernel will boot with these faults: > > dmar: DRHD: handling fault status reg 102 > dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr fff8 > DMAR:[fault reason 01] Present bit in root entry is clear > > dmar: DRHD: handling fault status reg 2 > dmar: INTR-REMAP: Request device [[61:00.0] fault index 42 > INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear > > On some system, the interrupt remapping fault will also happen even if the > intel_iommu is not set to on, because the interrupt remapping will be enabled > when x2apic is needed by the system. > > The cause of the DMA fault is described in Bill's original version, and the > INTR-Remap fault is caused by a similar reason. In short, the initialization > of vt-d drivers causes the in-flight DMA and interrupt requests get wrong > response. > > To fix this problem, we modifies the behaviors of the intel vt-d in the > crashdump kernel: > > For DMA Remapping: > 1. To accept the vt-d hardware in an active state, > 2. Do not disable and re-enable the translation, keep it enabled. > 3. Use the old root entry table, do not rewrite the RTA register. > 4. Malloc and use new context entry table, copy data from the old ones that >used by the old kernel. > 5. Keep using the old page tables before driver is loaded. > 6. After device driver is loaded, when it issues the first dma_map command, >free the dmar_domain structure for this device, and generate a new one, so >that the device can be assigned a new and empty page table. > 7. When a new context entry table is generated, we also save its address to >the old root entry table. > > For Interrupt Remapping: > 1. To accept the vt-d hardware in an active state, > 2. Do not disable and re-enable the interrupt remapping, keep it enabled. > 3. Use the old interrupt remapping table, do not rewrite the IRTA register. > 4. When ioapic entry is setup, the interrupt remapping table is changed, and >the updated data will be stored to the old interrupt remapping table. > > Advantages of this approach: > 1. All manipulation of the IO-device is done by the Linux device-driver >for that device. > 2. This approach behaves in a manner very similar to operation without an >active iommu. > 3. Any activity between the IO-device and its RMRR areas is handled by the >device-driver in the same manner as during a non-kdump boot. > 4. If an IO-device has no driver in the kdump kernel, it is simply left alone. >This supports the practice of creating a special kdump kernel without >drivers for any devices that are not required for taking a crashdump. > 5. Minimal code-changes among the existing mainline intel vt-d code. > > Summary of changes in this patch set: > 1. Added some useful function for root entry table in code intel-iommu.c > 2. Added new members to struct root_entry and struct irte; > 3. Functions to load old root entry table to iommu->root_entry from the > memory >of old kernel. > 4. Functions to malloc new context entry table and copy the data from the old >ones to the malloced new ones. > 5. Functions to enable support for DMA remapping in kdump kernel. > 6. Functions to load old irte data from the old kernel to the kdump kernel. > 7. Some code changes that support other behaviours that have been listed. > 8. In the new functions, use physical address as "unsigned long" type, not >pointers. > > Original version by Bill Sumner: > https://lkml.org/lkml/2014/1/10/518 > https://lkml.org/lkml/2014/4/15/716 > https://lkml.org/lkml/2014/4/24/836 > > Zhenhua's updates: > https://lkml.org/lkml/2014/10/21/134 > https://lkml.org/lkml/2014/12/15/121 > https://lkml.org/lkml/2014/12/22/53 > https://lkml.org/lkml/2015/1/6/1166 > https://lkml.org/lkml/2015/1/12/35 > https://lkml.org/lkml/2015/3/19/33 > > Changelog[v10]: > 1. Do not use CONFIG_CRASH_DUMP and is_kdump_kernel(). >Use one flag which stores the te and ir status in last kernel: >iommu->pre_enabled_trans >iommu->pre_enabled_ir > > Changelog[v9]: > 1. Add new function iommu_attach_domain_with_id. > 2. Do not copy old page tables, keep using the old ones. > 3. Remove functions: >intel_iommu_did_to_domain_values_entry >intel_iommu_get_dids_from_old_kernel >device_to_domain_id >copy_page_addr >copy_page_table >copy_context_entry >copy_context_entry_table > 4. Add new function device_to_existing_context_entry. > > Changelog[v8]: > 1. Add a missing __iommu_flush_cache in function copy_page_table. > > Changelog[v7]: > 1. Use __iommu_flush_cache to
[GIT PULL] ACPI and power management updates for v4.1-rc1
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm+acpi-4.1-rc1 to receive the first batch of power management and ACPI material for v4.1-rc1 with top-most commit b5e82233cab43c25fc0a1c28d9136a086db4aa52 Merge branches 'powercap' and 'pm-devfreq' on top of commit 39a8804455fb23f09157341d3ba7db6d7ae6ee76 Linux 4.0 These are mostly fixes and cleanups all over, although there are a few items that sort of fall into the new feature category. First off, we have new callbacks for PM domains that should help us to handle some issues related to device initialization in a better way. There also is some consolidation in the unified device properties API area allowing us to use that inferface for accessing data coming from platform initialization code in addition to firmware-provided data. We have some new device/CPU IDs in a few drivers, support for new chips and a new cpufreq driver too. Specifics: - Generic PM domains support update including new PM domain callbacks to handle device initialization better (Russell King, Rafael J Wysocki, Kevin Hilman). - Unified device properties API update including a new mechanism for accessing data provided by platform initialization code (Rafael J Wysocki, Adrian Hunter). - ARM cpuidle update including ARM32/ARM64 handling consolidation (Daniel Lezcano). - intel_idle update including support for the Silvermont Core in the Baytrail SOC and for the Airmont Core in the Cherrytrail and Braswell SOCs (Len Brown, Mathias Krause). - New cpufreq driver for Hisilicon ACPU (Leo Yan). - intel_pstate update including support for the Knights Landing chip (Dasaratharaman Chandramouli, Kristen Carlson Accardi). - QorIQ cpufreq driver update (Tang Yuantian, Arnd Bergmann). - powernv cpufreq driver update (Shilpasri G Bhat). - devfreq update including Tegra support changes (Tomeu Vizoso, MyungJoo Ham, Chanwoo Choi). - powercap RAPL (Running-Average Power Limit) driver update including support for Intel Broadwell server chips (Jacob Pan, Mathias Krause). - ACPI device enumeration update related to the handling of the special PRP0001 device ID allowing DT-style 'compatible' property to be used for ACPI device identification (Rafael J Wysocki). - ACPI EC driver update including limited _DEP support (Lan Tianyu, Lv Zheng). - ACPI backlight driver update including a new mechanism to allow native backlight handling to be forced on non-Windows 8 systems and a new quirk for Lenovo Ideapad Z570 (Aaron Lu, Hans de Goede). - New Windows Vista compatibility quirk for Sony VGN-SR19XN (Chen Yu). - Assorted ACPI fixes and cleanups (Aaron Lu, Martin Kepplinger, Masanari Iida, Mika Westerberg, Nan Li, Rafael J Wysocki). - Fixes related to suspend-to-idle for the iTCO watchdog driver and the ACPI core system suspend/resume code (Rafael J Wysocki, Chen Yu). - PM tracing support for the suspend phase of system suspend/resume transitions (Zhonghui Fu). - Configurable delay for the system suspend/resume testing facility (Brian Norris). - PNP subsystem cleanups (Peter Huewe, Rafael J Wysocki). Thanks! --- Aaron Lu (2): ACPI / scan: fix fixed event handler return value ACPI / video: Allow forcing native backlight on non win8 machines Adrian Hunter (2): ACPI: Add acpi_device_uid() for convenience driver core: Add comments about returning array counts Arnd Bergmann (1): cpufreq: fix qoriq uniprocessor build Brian Norris (1): PM / sleep: add configurable delay for pm_test Chanwoo Choi (1): PM / devfreq: event: Add const keyword for devfreq_event_ops structure Chen Yu (2): ACPI / blacklist: Disable Vista compatibility for Sony VGN-SR19XN. ACPI / PM: Enable all wakeup GPEs in suspend-to-idle Daniel Lezcano (8): ARM: cpuidle: Remove duplicate header inclusion ARM: cpuidle: Add a cpuidle ops structure to be used for DT ARM64: cpuidle: Replace cpu_suspend by the common ARM/ARM64 function ARM64: cpuidle: Rename cpu_init_idle to a common function name ARM64: cpuidle: Remove arm64 reference ARM: cpuidle: Enable the ARM64 driver for both ARM32/ARM64 ARM: cpuidle: Register per cpuidle device ARM: cpuidle: Document the code Dasaratharaman Chandramouli (1): intel_pstate: Knights Landing support Hans de Goede (1): ACPI / video: Add force native backlight quirk for Lenovo Ideapad Z570 Jacob Pan (1): powercap / RAPL: add ID for Broadwell server Kevin Hilman (1): MAINTAINERS: add entry for Generic PM domains (genpd) Kristen Carlson Accardi (1): intel_pstate: remove MSR test Lan Tianyu (1): ACPI / EC: Call acpi_walk_dep_device_list() after installing EC opregion handler Len Brown (2): intel_idle: Update support for Silvermont Core in Baytrail SOC intel_idle: Add support for the Airmont Core in the
Re: [v3, 01/11] powerpc/8xx: remove remaining unnecessary code in FixupDAR
On Tue, 2015-04-14 at 00:19 +0200, leroy christophe wrote:
>
> Le 13/04/2015 22:26, Scott Wood a écrit :
> > On Sun, 2015-04-12 at 18:16 +0200, leroy christophe wrote:
> >> Le 26/03/2015 22:32, Scott Wood a écrit :
> >>> On Tue, Feb 03, 2015 at 12:38:16PM +0100, LEROY Christophe wrote:
> Since commit 33fb845a6f01 ("powerpc/8xx: Don't use MD_TWC for walk"),
> MD_EPN and
> MD_TWC are not writen anymore in FixupDAR so saving r3 has become
> useless.
>
> Signed-off-by: Christophe Leroy
> ---
> v2: no change
> v3: no change
> >>> This doesn't apply cleanly.
> >>>
> >>>
> >> You already applied part of that patchset it in your next tree,
> >> including that one (commit 2374d0a).
> >> You told me to re-submit a patchset with only the remaining ones,
> >> therefore I sent v4 on the 4th of Feb, based on your tree.
> > OK. I applied v2, and didn't remember that when I came across v3 in
> > patchwork.
> >
> >
> What about v4 (the remaining ones) ? You got comments on the last one of
> the set, have you applied the other ones or shall I re-sumbit a full v5 ?
I haven't applied them yet.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86_64/efi: enforce 32 bit address for command line buffer
The boot_params structure has a 32 bit field for storing the address of
the kernel command line. When the EFI stub allocates memory for the command
line, it allocates at as low and address as possible, but does not ensure
that the address of memory allocated is below 4G.
This patch enforces this limit, and the stub now returns an error if the
command line buffer is allocated at too high of an address.
For 32 bit systems, the EFI mandated 1-1 memory mapping ensures
that all memory is 32 bit addressable, so we don't have a problem.
Also, mixed-mode booting on EFI platforms does not use the stub
code, so we don't need to handle the case of booting a 32 bit
kernel on a 64 bit EFI platform.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ef17683..82dbe27 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -1108,6 +1108,19 @@ struct boot_params *make_boot_params(struct efi_config
*c)
cmdline_ptr = efi_convert_cmdline(sys_table, image, _size);
if (!cmdline_ptr)
goto fail;
+
+#ifdef CONFIG_X86_64
+ /*
+* hdr->cmd_line_ptr is a 32 bit field, so on 64 bit systems we need
+* to ensure that the allocated buffer for the commandline is 32 bit
+* addressable.
+ */
+ if ((u64)(cmdline_ptr) + options_size > (u64)U32_MAX) {
+ efi_printk(sys_table, "Failed to alloc lowmem for command
line\n");
+ efi_free(sys_table, options_size, (unsigned long)cmdline_ptr);
+ goto fail;
+ }
+#endif /* CONFIG_X86_64 */
hdr->cmd_line_ptr = (unsigned long)cmdline_ptr;
hdr->ramdisk_image = 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI / hotplug: Propagate the "ignore hotplug" setting to parent
On Tuesday, April 14, 2015 12:28:12 PM Henrique de Moraes Holschuh wrote: > On Mon, Apr 13, 2015, at 11:23, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Refine the mechanism introduced by commit f244d8b623da (ACPIPHP / radeon > > / nouveau: Fix VGA switcheroo problem related to hotplug) to propagate > > the ignore_hotplug setting of the device to its parent bridge in case > > hotplug notifications related to the graphics adapter switching are > > given for the bridge rather than for the device itself (the need to > > be ignored in both cases). > > I do apologise if this is a stupid question, but is there any chance the > bridge will be connected to other devices that do require hotplug handling, > and not just to the GPU? The bridge is actually a downstream PCIe port holding the GPU, so no. :-) Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] More precise timestamps for nested writes
On 04/14/2015 12:13 PM, Peter Zijlstra wrote:
> On Mon, Apr 13, 2015 at 09:38:01PM -0500, Suresh E. Warrier wrote:
>> +static u64 *get_write_timestamp(struct ring_buffer_per_cpu *cpu_buffer,
>> +unsigned long *flags)
>> +{
>> +if (rb_precise_nested_write_ts()) {
>> +/*
>> + * Ensure that we are not preempted until after we update
>> + * the write timestamp.
>> + */
>> +local_irq_save(*flags);
>> +return _buffer->last_stamp;
>
> Yeah, ever hear about NMIs? This isn't going to work.
That is a good point! If a NMI can come in and start running a handler
that can generate a trace event, this code is indeed broken.
Some architectures like PowerPC don't have NMIs like Intel and so
I hadn't thought of that. Thanks for catching that!
Let me update the patch to handle NMIs - trace events from NMI code
cannot be made precise (the behavior will be the same as without the
patch).
-suresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] selftests/x86: fix cross build logic
On 04/14/2015 03:52 PM, Tyler Baker wrote: x86 tests should not be built when ARCH != x86. Reused the logic from breakpoints to determine when it's appropriate to build. In the future, please cc the author of recently-written code that you're fixing :) This patch is really weird. You're generating ARCH, then you're modifying it part way through, and you're changing the rule for all_32 and all_64 to print an error (and succeed!) if run on the wrong arch. I don't see the point of the latter at all. Just let all have no dependencies if you're on the wrong ARCH. As for the former, can you do this more cleanly? This is really ugly. It looks to me (on naive reading) like 64-bit hosts won't do the right thing. (The right thing is to build both bitnesses of tests.) --Andy Signed-off-by: Tyler Baker --- tools/testing/selftests/x86/Makefile | 35 +++ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index f0a7918..7be67a0 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -7,31 +7,36 @@ BINARIES_64 := $(TARGETS_C_BOTHBITS:%=%_64) CFLAGS := -O2 -g -std=gnu99 -pthread -Wall -UNAME_P := $(shell uname -p) - -# Always build 32-bit tests +# Taken from perf makefile +uname_M := $(shell uname -m 2>/dev/null || echo not) +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/) +ifeq ($(ARCH),i386) +ARCH := x86 all: all_32 - +endif +ifeq ($(ARCH),x86_64) +ARCH := x86 # If we're on a 64-bit host, build 64-bit tests as well -ifeq ($(shell uname -p),x86_64) -all: all_64 +all: all_32 all_64 endif all_32: check_build32 $(BINARIES_32) all_64: $(BINARIES_64) -clean: - $(RM) $(BINARIES_32) $(BINARIES_64) - -run_tests: - ./run_x86_tests.sh - $(TARGETS_C_BOTHBITS:%=%_32): %_32: %.c +ifeq ($(ARCH),x86) $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl +else + echo "Not an x86 target, can't build x86 tests" +endif $(TARGETS_C_BOTHBITS:%=%_64): %_64: %.c +ifeq ($(ARCH),x86) $(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl +else + echo "Not an x86 target, can't build x86 tests" +endif check_build32: @if ! $(CC) -m32 -o /dev/null trivial_32bit_program.c; then \ @@ -46,3 +51,9 @@ check_build32: echo " yum install glibc-devel.*i686"; \ exit 1; \ fi + +run_tests: + ./run_x86_tests.sh + +clean: + $(RM) $(BINARIES_32) $(BINARIES_64) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86_64: Question about fixmaps
On 04/14/2015 06:16 AM, Alexander Kuleshov wrote: Hello All, I'm reading x86_64 source code and trying to understand where are fixmaps space in the virtual memory space. If I understand correctly (but i'm really not sure about it), fixmap space is after vsyscall space. As Documentation/x86/x86_64/mm.txt says vsyscall virtual space is: ff60 - ffdf (=8 MB) vsyscalls With 'earlyprintk' i got FIXADDR_START and FIXADDR_TOP and they are: FIXADDR_START - 0xff779000L FIXADDR_TOP - 0xff7ff000L with these addressess FIXADDR_START/FIXADDR_TOP overlap vsyscalls area. Is it correct case that fixmaps are in vsyscal virtual memory space or I'm wrong somewhere? It's the other way around. vsyscalls are in the fixmap. I should fix the docs. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] RCU changes for v4.1
On Tue, Apr 14, 2015 at 5:22 PM, Linus Torvalds wrote: > >depends on RCU_TORTURE_TEST_SLOW_INIT > > would seem to be called for. Side note, you'll obviously also need to fix the actual bogus 'gp_init_delay' use in kernel/rcu/tree.c. That code is horrible. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] RCU changes for v4.1
On Mon, Apr 13, 2015 at 5:14 AM, Ingo Molnar wrote: > > Please pull the latest core-rcu-for-linus git tree from: This is very annoying: ... torture tests for RCU (RCU_TORTURE_TEST) [N/m/y/?] n How much to slow down RCU grace-period initialization (RCU_TORTURE_TEST_SLOW_INIT_DELAY) [3] (NEW) ... please make things like this pointless value depend on the option that makes them relevant! So a simple depends on RCU_TORTURE_TEST_SLOW_INIT would seem to be called for. It's not like we don't already have annoying and unanswerable questions for RCU (RCU_KTHREAD_PRIO), let's not add the completely stupid *pointless* ones too. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Input updates for 4.1-rc0
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get the following new drivers: Qualcomm PM8941 power key drver, ChipOne icn8318 touchscreen controller driver, Broadcom iProc touchscreen and keypad drivers, and Semtech SX8654 I2C touchscreen controller driver. ALPS driver now supports newer SS4 devices; Elantech got a fix that should make it work on some ASUS laptops; and a slew of other enhancements and random fixes. Changelog: - Aaron Sierra (1): Input: tsc2007 - Convert msecs to jiffies only once Aleksei Mamlin (2): Input: goodix - use max touch number from device config Input: goodix - add device tree support Benjamin Tissoires (3): Input: MT - make slot assignment work for overcovered solutions Input: Revert "Revert "synaptics - use dmax in input_mt_assign_slots"" Input: synaptics - allocate 3 slots to keep stability in image sensors Brian K. Turner (1): Input: lifebook - fix tabbing issue Charlie Mooney (1): Input: elants_i2c - append hw_version to FW file Courtney Cavin (1): Input: add Qualcomm PM8941 power key driver Dan Carpenter (1): Input: sx8654 - signedness bug in sx8654_irq() Dmitry Torokhov (5): Input: psmouse - when comparing PNP IDs ignore case Input: synaptics - switch ForcePad detection to PNP IDs Input: pwm-beeper - remove unneeded PWM_BEEPER_PM_OPS define Input: mma8450 - convert to using managed resources Input: atkbd - document "no new force-release quirks" policy Duson Lin (2): Input: elan_i2c - return error code when resume fails Input: elan_i2c - remove duplicate repeat code Fabian Frederick (1): Input: constify of_device_id arrays Fengguang Wu (1): Input: ALPS - make alps_get_pkt_id_ss4_v2() and others static Hans de Goede (6): Input: sun4i-ts - A10 (sun4i) has a different temperature curve Input: sun4i-ts - really fix A10 temperature reporting Input: touchscreen DT binding - add touchscreen-swapped-x-y property Input: add support for ChipOne icn8318 based touchscreens Input: alps - fix touchpad buttons getting stuck when used with trackpoint Input: alps - non interleaved V2 dualpoint has separate stick button bits Jaewon Kim (1): Input: add haptic support for max77843 Jens Thiele (1): Input: sun4i-ts - allow controlling filter and sensitivity via DT Jonathan Richardson (1): Input: add Broadcom iProc touchscreen driver Lars Poeschel (1): Input: usbtouchscreen - add new model from IRTOUCHSYSTEMS Linus Walleij (3): Input: driver for microcontroller keys on the iPaq h3xxx Input: tc3589x - localize platform data mfd: tc3589x: enforce device-tree only mode Masaki Ota (3): Input: ALPS - refactor alps_set_abs_params_mt() Input: ALPS - add support for SS4 touchpad devices Input: ALPS - V7 devices can report 5-finger taps Maxime Ripard (4): Input: of_touchscreen - rework the DT parsing function Input: of_touchscreen - register multitouch axes Input: edt-ft5x06 - allow to setting the maximum axes value through the DT Input: edt-ft5x06 - remove EV_SYN event report Michael S. Tsirkin (1): Input: gscps2 - drop pci_ids dependency Nick Dyer (1): Input: atmel_mxt_ts - implement support for T100 touch object Nicolas Iooss (1): Input: elan_i2c - fix typo in include header guard Olivier Sobrie (1): Input: pwm-beeper - remove useless call to pwm_config() Rafael J. Wysocki (1): Input: i8042 - allow KBD and AUX ports to wake up from suspend-to-idle Scott Branden (1): Input: add driver for Broadcom keypad controller Sjoerd Simons (1): Input: atmel_mxt_ts - split out touchpad initialisation logic Stefan Brüns (2): Input: rename KEY_DIRECTION to KEY_ROTATE_DISPLAY Input: use more descriptive KEY_ROTATE_DISPLAY instead of KEY_DIRECTION Sébastien Szymanski (1): Input: add support for Semtech SX8654 I2C touchscreen controller Tomeu Vizoso (1): Input: cros_ec_keyb - fix clearing keyboard state on wakeup Ulrik De Bie (1): Input: elantech - fix absolute mode setting on some ASUS laptops Diffstat: .../devicetree/bindings/input/brcm,bcm-keypad.txt | 108 + .../bindings/input/qcom,pm8941-pwrkey.txt | 43 ++ .../input/touchscreen/brcm,iproc-touchscreen.txt | 76 +++ .../bindings/input/touchscreen/chipone_icn8318.txt | 46 ++ .../bindings/input/touchscreen/goodix.txt | 29 ++ .../bindings/input/touchscreen/sun4i.txt | 22 +- .../bindings/input/touchscreen/sx8654.txt | 16 + .../bindings/input/touchscreen/touchscreen.txt | 2 + .../devicetree/bindings/vendor-prefixes.txt| 2 + MAINTAINERS| 7 + drivers/gpio/Kconfig
[GIT PULL] Security subsystem update for 4.1
Hi Linus,
Highlights for this window:
o Improved AVC hashing for SELinux by John Brooks and Stephen Smalley
o Addition of an unconfined label to Smack
o Smack documentation update
o TPM driver updates
Please pull.
---
The following changes since commit 80dcc31fbe55932ac9204daee5f2ebc0c49b6da3:
Merge tag 'gfs2-merge-window' of
git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2 (2015-04-14
16:09:18 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next
Casey Schaufler (2):
Smack: Allow an unconfined label in bringup mode
Smack: Updates for Smack documentation
Christophe Ricard (6):
tpm/tpm_i2c_stm_st33: Replace access to io_lpcpd from struct
st33zp24_platform_data to tpm_stm_dev
tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy)
tpm/st33zp24/spi: Add st33zp24 spi phy
tpm/st33zp24/dts/st33zp24-spi: Add dts documentation for st33zp24 spi phy
tpm/st33zp24: Add proper wait for ordinal duration in case of irq mode
tpm/st33zp24/spi: Add missing device table for spi phy.
James Morris (3):
Merge tag 'yama-4.0' of git://git.kernel.org/.../kees/linux into next
Merge branch 'smack-for-4.1' of git://github.com/cschaufler/smack-next
into next
Merge branch 'tomoyo-cleanup' of git://git.kernel.org/.../mmarek/kbuild
into next
Jarkko Sakkinen (2):
tpm: fix call order in tpm-chip.c
tpm: fix: sanitized code paths in tpm_chip_register()
Jeff Vander Stoep (1):
selinux: remove unnecessary pointer reassignment
John Brooks (1):
selinux: Use a better hash function for avtab
José Bollo (1):
Smack: getting the Smack security context of keys
Kees Cook (1):
Yama: do not modify global sysctl table entry
Marcin Lis (1):
Smack: Assign smack_known_web as default smk_in label for kernel thread's
socket
Michal Marek (3):
tomoyo: Use bin2c to generate builtin-policy.h
tomoyo: Use if_changed when generating builtin-policy.h
tomoyo: Do not generate empty policy files
Paul Gortmaker (1):
smack: Fix gcc warning from unused smack_syslog_lock mutex in smackfs.c
Paul Moore (1):
selinux: reconcile security_netlbl_secattr_to_sid() and
mls_import_netlbl_cat()
Peter Huewe (3):
tpm: Update KConfig text to include TPM2.0 FIFO chips
MAINTAINERS: Add Jason as designated reviewer for TPM
tpm/tpm_infineon: Use struct dev_pm_ops for power management
Richard Guy Briggs (1):
lsm: copy comm before calling audit_log to avoid race in string printing
Stephen Smalley (3):
security/yama: Remove unnecessary selects from Kconfig.
selinux: convert avtab hash table to flex_array
selinux: increase avtab max buckets
jmlat...@linux.vnet.ibm.com (1):
tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send
.../bindings/security/tpm/st33zp24-spi.txt | 34 +
Documentation/security/Smack.txt | 129 ++--
MAINTAINERS|1 +
drivers/char/tpm/Kconfig | 20 +-
drivers/char/tpm/Makefile |2 +-
drivers/char/tpm/st33zp24/Kconfig | 30 +
drivers/char/tpm/st33zp24/Makefile | 12 +
drivers/char/tpm/st33zp24/i2c.c| 276 ++
drivers/char/tpm/st33zp24/spi.c| 399 +
drivers/char/tpm/st33zp24/st33zp24.c | 698 +++
drivers/char/tpm/st33zp24/st33zp24.h | 37 +
drivers/char/tpm/tpm-chip.c| 92 ++-
drivers/char/tpm/tpm_i2c_stm_st33.c| 911
drivers/char/tpm/tpm_ibmvtpm.c | 10 +-
drivers/char/tpm/tpm_ibmvtpm.h |6 +-
drivers/char/tpm/tpm_infineon.c| 34 +-
.../platform_data/{tpm_stm_st33.h => st33zp24.h} | 21 +-
security/lsm_audit.c | 15 +-
security/selinux/avc.c |6 +-
security/selinux/ss/avtab.c| 72 ++-
security/selinux/ss/avtab.h|8 +-
security/selinux/ss/mls.c | 10 +-
security/selinux/ss/services.c |6 +-
security/smack/smack.h |8 +
security/smack/smack_access.c | 43 +-
security/smack/smack_lsm.c | 99 ++-
security/smack/smackfs.c | 97 ++-
security/tomoyo/.gitignore |2 +-
security/tomoyo/Kconfig|1 +
security/tomoyo/Makefile | 55 +-
.../tomoyo/policy/exception_policy.conf.default|2 +
security/yama/Kconfig |2 -
security/yama/yama_lsm.c | 13 +-
33 files
Re: [PATCH 1/3] sched, timer: Remove usages of ACCESS_ONCE in the scheduler
On Tue, 14 Apr 2015 16:09:44 -0700
Jason Low wrote:
> @@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node, int
> pages, int flags)
>
> static void reset_ptenuma_scan(struct task_struct *p)
> {
> - ACCESS_ONCE(p->mm->numa_scan_seq)++;
> + WRITE_ONCE(p->mm->numa_scan_seq, READ_ONCE(p->mm->numa_scan_seq) + 1);
Is the READ_ONCE() inside the WRITE_ONCE() really necessary?
> p->mm->numa_scan_offset = 0;
> }
>
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lsm: copy comm before calling audit_log to avoid race in string printing
On Tue, 14 Apr 2015, Richard Guy Briggs wrote: > When task->comm is passed directly to audit_log_untrustedstring() without > getting a copy or using the task_lock, there is a race that could happen that > would output a NULL (\0) in the middle of the output string that would > effectively truncate the rest of the report text after the comm= field in the > audit log message, losing fields. > > Using get_task_comm() to get a copy while acquiring the task_lock to prevent > this and to prevent the result from being a mixture of old and new values of > comm would incur potentially unacceptable overhead, considering that the value > can be influenced by userspace and therefore untrusted anyways. > > Copy the value before passing it to audit_log_untrustedstring() ensures that a > local copy is used to calculate the length *and* subsequently printed. Even > if > this value contains a mix of old and new values, it will only calculate and > copy up to the first NULL, preventing the rest of the audit log message being > truncated. > > Use a second local copy of comm to avoid a race between the first and second > calls to audit_log_untrustedstring() with comm. > > Reported-by: Tetsuo Handa > Signed-off-by: Richard Guy Briggs Applied. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] sched, timer: Improve scalability of itimers
On Tue, Apr 14, 2015 at 4:09 PM, Jason Low wrote: > This patchset improves the scalability of itimers, thread_group_cputimer > and addresses a performance issue we found while running a database > workload where more than 30% of total time is spent in the kernel > trying to acquire the thread_group_cputimer spinlock. I'm ok with this series, but I'm going to assume that I'll get it through the scheduler tree. Ingo? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: no trees Thursday and Friday
Hi all, Just to let you all know that I will not be releasing linux-next trees on Thursday or Friday (nor probably over the weekend as usual). Sorry about that. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp7cE909e8di.pgp Description: OpenPGP digital signature
Re: [PATCH 1/7] sched/deadline: fix try to pull pinned dl tasks in pull algorithm
Ping Juri for this patchset, :)
On Mon, Apr 06, 2015 at 04:53:13PM +0800, Wanpeng Li wrote:
>Function pick_next_earliest_dl_task is used to pick earliest and pushable
>dl task from overloaded cpus in pull algorithm, however, it traverses
>runqueue rbtree instead of pushable task rbtree which is also ordered by
>tasks' deadlines. This will result in getting no candidates from overloaded
>cpus if all the dl tasks on the overloaded cpus are pinned. This patch fix
>it by traversing pushable task rbtree which is also ordered by tasks'
>deadlines.
>
>Signed-off-by: Wanpeng Li
>---
> kernel/sched/deadline.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
>diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
>index 5e95145..b57ceba 100644
>--- a/kernel/sched/deadline.c
>+++ b/kernel/sched/deadline.c
>@@ -1230,6 +1230,33 @@ next_node:
> return NULL;
> }
>
>+/*
>+ * Return the earliest pushable rq's task, which is suitable to be executed
>+ * on the cpu, NULL otherwse
>+ */
>+static struct task_struct *pick_earliest_pushable_dl_task(struct rq *rq,
>+ int cpu)
>+{
>+ struct rb_node *next_node = rq->dl.pushable_dl_tasks_leftmost;
>+ struct task_struct *p = NULL;
>+
>+ if (!has_pushable_dl_tasks(rq))
>+ return NULL;
>+
>+next_node:
>+ if (next_node) {
>+ p = rb_entry(next_node, struct task_struct, pushable_dl_tasks);
>+
>+ if (pick_dl_task(rq, p, cpu))
>+ return p;
>+
>+ next_node = rb_next(next_node);
>+ goto next_node;
>+ }
>+
>+ return NULL;
>+}
>+
> static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask_dl);
>
> static int find_later_rq(struct task_struct *task)
>@@ -1514,7 +1541,7 @@ static int pull_dl_task(struct rq *this_rq)
> if (src_rq->dl.dl_nr_running <= 1)
> goto skip;
>
>- p = pick_next_earliest_dl_task(src_rq, this_cpu);
>+ p = pick_earliest_pushable_dl_task(src_rq, this_cpu);
>
> /*
>* We found a task to be pulled if:
>--
>1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GFS2: Pull request (merge window)
On Tue, Apr 14, 2015 at 10:47 AM, Bob Peterson wrote: > > 12 files changed, 184 insertions(+), 95 deletions(-) Oh, and this was incorrect. You had apparently limited the statistics to the fs/gfs2 directory, and thus missed the changes to the MAINTAINERS file. Don't do that - include all the changes. It's what I see and compare against when I actually do the pull anyway. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS2: Pull request (merge window)
On Tue, Apr 14, 2015 at 10:47 AM, Bob Peterson wrote: > > There's another that adds me as a GFS2 co-maintainer [...] So generally, when I start getting pull requests from different people, I'd like to see a previous separate heads-up or confirmation from the previous person just so that I'm not taken by surprise. Rather than this kind of "as part of the pull request, make the thing official". Yes, yes, I can see that you use the same script that Steven did, and I can see that you've been the main developer lately, but still.. Anyway. Pulled. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] timer: Avoid waking up an idle-core by migrate running timer
On Tue, 31 Mar 2015, Viresh Kumar wrote:
> @@ -1189,12 +1195,41 @@ static inline void __run_timers(struct tvec_base
> *base)
> cascade(base, >tv5, INDEX(3));
> ++base->timer_jiffies;
> list_replace_init(base->tv1.vec + index, head);
> +
> +again:
> while (!list_empty(head)) {
> void (*fn)(unsigned long);
> unsigned long data;
> bool irqsafe;
>
> - timer = list_first_entry(head, struct timer_list,entry);
> + timer = list_first_entry(head, struct timer_list,
> entry);
> +
> + if (unlikely(timer_running(timer))) {
> + /*
> + * The only way to get here is if the handler,
> + * running on another base, re-queued itself on
> + * this base, and the handler hasn't finished
> + * yet.
> + */
> +
> + if (list_is_last(>entry, head)) {
> + /*
> + * Drop lock, so that TIMER_RUNNING can
> + * be cleared on another base.
> + */
> + spin_unlock(>lock);
> +
> + while (timer_running(timer))
> + cpu_relax();
> +
> + spin_lock(>lock);
> + } else {
> + /* Rotate the list and try someone else
> */
> + list_move_tail(>entry, head);
> + }
Can we please stick that timer into the next bucket and be done with it?
> + goto again;
"continue;" is old school, right?
> + }
> +
> fn = timer->function;
> data = timer->data;
> irqsafe = tbase_get_irqsafe(timer->base);
> @@ -1202,6 +1237,7 @@ static inline void __run_timers(struct tvec_base *base)
> timer_stats_account_timer(timer);
>
> base->running_timer = timer;
> + timer_set_running(timer);
> detach_expired_timer(timer, base);
>
> if (irqsafe) {
> @@ -1213,6 +1249,25 @@ static inline void __run_timers(struct tvec_base *base)
> call_timer_fn(timer, fn, data);
> spin_lock_irq(>lock);
> }
> +
> + /*
> + * Handler running on this base, re-queued itself on
> + * another base ?
> + */
> + if (unlikely(timer->base != base)) {
> + unsigned long flags;
> + struct tvec_base *tbase;
> +
> + spin_unlock(>lock);
> +
> + tbase = lock_timer_base(timer, );
> + timer_clear_running(timer);
> + spin_unlock(>lock);
> +
> + spin_lock(>lock);
> + } else {
> + timer_clear_running(timer);
> + }
Aside of the above this is really horrible. Why not doing the obvious:
__mod_timer()
if (base != newbase) {
if (timer_running()) {
list_add(>migration_list);
goto out_unlock;
}
.
__run_timers()
while(!list_empty(head)) {
}
if (unlikely(!list_empty(>migration_list)) {
/* dequeue and requeue again */
}
Simple, isn't it?
No new flags in the timer base, no concurrent expiry, no extra
conditionals in the expiry path. Just a single extra check at the end
of the softirq handler for this rare condition instead of imposing all
that nonsense to the hotpath.
We might even optimize that:
if (timer_running()) {
list_add(>migration_list);
base->preferred_target = newbase;
goto out_unlock;
}
if (unlikely(!list_empty(>migration_list)) {
/* dequeue and requeue again */
while (!list_empty(>migration_list)) {
dequeue_timer();
newbase = base->preferred_target;
unlock(base);
lock(newbase);
enqueue(newbase);
unlock(newbase);
lock(base);
}
}
Thanks,
tglx
--
To
[PATCH 3/3] sched, timer: Use cmpxchg to do updates in update_gt_cputime()
Note: The chance that the race which this patch addresses seems very
unlikely to occur, especially after the change in patch 2 which sets
the running field after calling this update_gt_cputimer().
However, I am including this patch if we want to be completely safe
from concurrent updates.
-
Since we're now updating thread group cputimer values without a lock,
there is now a potential race that can occur in update_gt_cputime() where
the cputimers are concurrently being updated in account_group_*_time().
This can occur when the ->running field transitions from 1 -> 0 -> 1. If the
cputimer->running field is set while thread 1 runs run_posix_cpu_timers(),
but another thread, thread 2, turns off cputimer->running before thread 1
enters thread_group_cputimer(), and another thread, thread 3, enables it
after thread 1 checks !cputimer->running in thread_group_cputimer(), then
there is a possibility that update_gt_cputime() is updating the cputimers
while the cputimer is running.
This patch uses cmpxchg and retry logic to ensure that update_gt_cputime()
is making its updates atomically.
Signed-off-by: Jason Low
---
kernel/time/posix-cpu-timers.c | 26 ++
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 7e96082..130d717 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -196,16 +196,26 @@ static int cpu_clock_sample(const clockid_t which_clock,
struct task_struct *p,
return 0;
}
-static void update_gt_cputime(struct thread_group_cputimer *cputimer, struct
task_cputime *sum)
+static inline void __update_gt_cputime(atomic64_t *cputime, u64 sum_cputime)
{
- if (sum->utime > atomic64_read(>utime))
- atomic64_set(>utime, sum->utime);
-
- if (sum->stime > atomic64_read(>stime))
- atomic64_set(>stime, sum->stime);
+ u64 curr_cputime;
+ /*
+* Set cputime to sum_cputime if sum_cputime > cputime. Use cmpxchg
+* to avoid race conditions with concurrent updates to cputime.
+*/
+retry:
+ curr_cputime = atomic64_read(cputime);
+ if (sum_cputime > curr_cputime) {
+ if (atomic64_cmpxchg(cputime, curr_cputime, sum_cputime) !=
curr_cputime)
+ goto retry;
+ }
+}
- if (sum->sum_exec_runtime > atomic64_read(>sum_exec_runtime))
- atomic64_set(>sum_exec_runtime,
sum->sum_exec_runtime);
+static void update_gt_cputime(struct thread_group_cputimer *cputimer, struct
task_cputime *sum)
+{
+ __update_gt_cputime(>utime, sum->utime);
+ __update_gt_cputime(>stime, sum->stime);
+ __update_gt_cputime(>sum_exec_runtime, sum->sum_exec_runtime);
}
/* Sample thread_group_cputimer values in "cputimer", copy results to "times"
*/
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] sched, timer: Remove usages of ACCESS_ONCE in the scheduler
ACCESS_ONCE doesn't work reliably on non-scalar types. This patch removes
the rest of the existing usages of ACCESS_ONCE in the scheduler, and use
the new READ_ONCE and WRITE_ONCE APIs.
Signed-off-by: Jason Low
---
include/linux/sched.h |4 ++--
kernel/fork.c |2 +-
kernel/sched/auto_group.c |2 +-
kernel/sched/auto_group.h |2 +-
kernel/sched/core.c|4 ++--
kernel/sched/cputime.c |2 +-
kernel/sched/deadline.c|2 +-
kernel/sched/fair.c| 14 +++---
kernel/sched/proc.c|4 ++--
kernel/sched/rt.c |2 +-
kernel/sched/sched.h |2 +-
kernel/sched/wait.c|4 ++--
kernel/time/posix-cpu-timers.c |8
13 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6d77432..379fb3b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -3070,13 +3070,13 @@ static inline void mm_update_next_owner(struct
mm_struct *mm)
static inline unsigned long task_rlimit(const struct task_struct *tsk,
unsigned int limit)
{
- return ACCESS_ONCE(tsk->signal->rlim[limit].rlim_cur);
+ return READ_ONCE(tsk->signal->rlim[limit].rlim_cur);
}
static inline unsigned long task_rlimit_max(const struct task_struct *tsk,
unsigned int limit)
{
- return ACCESS_ONCE(tsk->signal->rlim[limit].rlim_max);
+ return READ_ONCE(tsk->signal->rlim[limit].rlim_max);
}
static inline unsigned long rlimit(unsigned int limit)
diff --git a/kernel/fork.c b/kernel/fork.c
index cf65139..d96a0ca 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1045,7 +1045,7 @@ static void posix_cpu_timers_init_group(struct
signal_struct *sig)
/* Thread group counters. */
thread_group_cputime_init(sig);
- cpu_limit = ACCESS_ONCE(sig->rlim[RLIMIT_CPU].rlim_cur);
+ cpu_limit = READ_ONCE(sig->rlim[RLIMIT_CPU].rlim_cur);
if (cpu_limit != RLIM_INFINITY) {
sig->cputime_expires.prof_exp = secs_to_cputime(cpu_limit);
sig->cputimer.running = 1;
diff --git a/kernel/sched/auto_group.c b/kernel/sched/auto_group.c
index eae160d..a8653c2 100644
--- a/kernel/sched/auto_group.c
+++ b/kernel/sched/auto_group.c
@@ -141,7 +141,7 @@ autogroup_move_group(struct task_struct *p, struct
autogroup *ag)
p->signal->autogroup = autogroup_kref_get(ag);
- if (!ACCESS_ONCE(sysctl_sched_autogroup_enabled))
+ if (!READ_ONCE(sysctl_sched_autogroup_enabled))
goto out;
for_each_thread(p, t)
diff --git a/kernel/sched/auto_group.h b/kernel/sched/auto_group.h
index 8bd0471..890c95f 100644
--- a/kernel/sched/auto_group.h
+++ b/kernel/sched/auto_group.h
@@ -29,7 +29,7 @@ extern bool task_wants_autogroup(struct task_struct *p,
struct task_group *tg);
static inline struct task_group *
autogroup_task_group(struct task_struct *p, struct task_group *tg)
{
- int enabled = ACCESS_ONCE(sysctl_sched_autogroup_enabled);
+ int enabled = READ_ONCE(sysctl_sched_autogroup_enabled);
if (enabled && task_wants_autogroup(p, tg))
return p->signal->autogroup->tg;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index f0f831e..4131c24 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -508,7 +508,7 @@ static bool set_nr_and_not_polling(struct task_struct *p)
static bool set_nr_if_polling(struct task_struct *p)
{
struct thread_info *ti = task_thread_info(p);
- typeof(ti->flags) old, val = ACCESS_ONCE(ti->flags);
+ typeof(ti->flags) old, val = READ_ONCE(ti->flags);
for (;;) {
if (!(val & _TIF_POLLING_NRFLAG))
@@ -2505,7 +2505,7 @@ void scheduler_tick(void)
u64 scheduler_tick_max_deferment(void)
{
struct rq *rq = this_rq();
- unsigned long next, now = ACCESS_ONCE(jiffies);
+ unsigned long next, now = READ_ONCE(jiffies);
next = rq->last_sched_tick + HZ;
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 8394b1e..f5a64ff 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -567,7 +567,7 @@ static void cputime_advance(cputime_t *counter, cputime_t
new)
{
cputime_t old;
- while (new > (old = ACCESS_ONCE(*counter)))
+ while (new > (old = READ_ONCE(*counter)))
cmpxchg_cputime(counter, old, new);
}
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 3fa8fa6..fa43e3f 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -932,7 +932,7 @@ select_task_rq_dl(struct task_struct *p, int cpu, int
sd_flag, int flags)
rq = cpu_rq(cpu);
rcu_read_lock();
- curr = ACCESS_ONCE(rq->curr); /* unlocked access */
+ curr = READ_ONCE(rq->curr); /* unlocked access */
/*
* If we are dealing with a -deadline task, we must
diff --git
[PATCH 0/3] sched, timer: Improve scalability of itimers
This patchset improves the scalability of itimers, thread_group_cputimer and addresses a performance issue we found while running a database workload where more than 30% of total time is spent in the kernel trying to acquire the thread_group_cputimer spinlock. While we're modifying sched and timer, patch 1 also updates all existing usages of ACCESS_ONCE with the new READ_ONCE and WRITE_ONCE APIs in those areas. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] sched, timer: Use atomics for thread_group_cputimer to improve scalability
While running a database workload, we found a scalability issue with itimers.
Much of the problem was caused by the thread_group_cputimer spinlock.
Each time we account for group system/user time, we need to obtain a
thread_group_cputimer's spinlock to update the timers. On larger systems
(such as a 16 socket machine), this caused more than 30% of total time
spent trying to obtain this kernel lock to update these group timer stats.
This patch converts the timers to 64 bit atomic variables and use
atomic add to update them without a lock. With this patch, the percent
of total time spent updating thread group cputimer timers was reduced
from 30% down to less than 1%.
Note: On 32 bit systems using the generic 64 bit atomics, this causes
sample_group_cputimer() to take locks 3 times instead of just 1 time.
However, we tested this patch on a 32 bit system ARM system using the
generic atomics and did not find the overhead to be much of an issue.
An explanation for why this isn't an issue is that 32 bit systems usually
have small numbers of CPUs, and cacheline contention from extra spinlocks
called periodically is not really apparent on smaller systems.
Signed-off-by: Jason Low
---
include/linux/init_task.h |7 +++--
include/linux/sched.h | 10 ++-
kernel/fork.c |3 --
kernel/sched/stats.h | 12 ++---
kernel/time/posix-cpu-timers.c | 48
5 files changed, 34 insertions(+), 46 deletions(-)
diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index 696d223..7b9d8b5 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -50,9 +50,10 @@ extern struct fs_struct init_fs;
.cpu_timers = INIT_CPU_TIMERS(sig.cpu_timers), \
.rlim = INIT_RLIMITS, \
.cputimer = { \
- .cputime = INIT_CPUTIME,\
- .running = 0, \
- .lock = __RAW_SPIN_LOCK_UNLOCKED(sig.cputimer.lock),\
+ .utime= ATOMIC64_INIT(0), \
+ .stime= ATOMIC64_INIT(0), \
+ .sum_exec_runtime = ATOMIC64_INIT(0), \
+ .running = 0 \
}, \
.cred_guard_mutex = \
__MUTEX_INITIALIZER(sig.cred_guard_mutex), \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 379fb3b..a5bb23b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -592,9 +592,10 @@ struct task_cputime {
* used for thread group CPU timer calculations.
*/
struct thread_group_cputimer {
- struct task_cputime cputime;
+ atomic64_t utime;
+ atomic64_t stime;
+ atomic64_t sum_exec_runtime;
int running;
- raw_spinlock_t lock;
};
#include
@@ -2952,11 +2953,6 @@ static __always_inline bool need_resched(void)
void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times);
void thread_group_cputimer(struct task_struct *tsk, struct task_cputime
*times);
-static inline void thread_group_cputime_init(struct signal_struct *sig)
-{
- raw_spin_lock_init(>cputimer.lock);
-}
-
/*
* Reevaluate whether the task has signals pending delivery.
* Wake the task if so.
diff --git a/kernel/fork.c b/kernel/fork.c
index d96a0ca..da8e6dd 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1042,9 +1042,6 @@ static void posix_cpu_timers_init_group(struct
signal_struct *sig)
{
unsigned long cpu_limit;
- /* Thread group counters. */
- thread_group_cputime_init(sig);
-
cpu_limit = READ_ONCE(sig->rlim[RLIMIT_CPU].rlim_cur);
if (cpu_limit != RLIM_INFINITY) {
sig->cputime_expires.prof_exp = secs_to_cputime(cpu_limit);
diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
index 4ab7043..adda94e 100644
--- a/kernel/sched/stats.h
+++ b/kernel/sched/stats.h
@@ -215,9 +215,7 @@ static inline void account_group_user_time(struct
task_struct *tsk,
if (!cputimer_running(tsk))
return;
- raw_spin_lock(>lock);
- cputimer->cputime.utime += cputime;
- raw_spin_unlock(>lock);
+ atomic64_add(cputime, >utime);
}
/**
@@ -238,9 +236,7 @@ static inline void account_group_system_time(struct
task_struct *tsk,
if (!cputimer_running(tsk))
return;
- raw_spin_lock(>lock);
- cputimer->cputime.stime += cputime;
- raw_spin_unlock(>lock);
+ atomic64_add(cputime, >stime);
}
/**
@@ -261,7 +257,5 @@ static inline void account_group_exec_runtime(struct
task_struct *tsk,
if (!cputimer_running(tsk))
[PATCH 6/7] selftests/x86: install tests
Set TEST_PROGS so that the required binaries are installed. Skip the install and test case when ARCH != x86. Signed-off-by: Tyler Baker --- tools/testing/selftests/x86/Makefile | 10 ++ 1 file changed, 10 insertions(+) diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index 7be67a0..1abe3f6 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -24,6 +24,10 @@ all_32: check_build32 $(BINARIES_32) all_64: $(BINARIES_64) +include ../lib.mk + +TEST_PROGS := $(BINARIES_32) $(BINARIES_64) run_x86_tests.sh + $(TARGETS_C_BOTHBITS:%=%_32): %_32: %.c ifeq ($(ARCH),x86) $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl @@ -52,6 +56,12 @@ check_build32: exit 1; \ fi +install: +ifneq ($(ARCH),x86) +echo "Not an x86 target, can't install x86 tests" +override EMIT_TESTS := echo "echo \"selftests: run_x86_tests.sh [SKIP]\"" +endif + run_tests: ./run_x86_tests.sh -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] selftests/x86: fix cross build logic
x86 tests should not be built when ARCH != x86. Reused the logic from breakpoints to determine when it's appropriate to build. Signed-off-by: Tyler Baker --- tools/testing/selftests/x86/Makefile | 35 +++ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index f0a7918..7be67a0 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -7,31 +7,36 @@ BINARIES_64 := $(TARGETS_C_BOTHBITS:%=%_64) CFLAGS := -O2 -g -std=gnu99 -pthread -Wall -UNAME_P := $(shell uname -p) - -# Always build 32-bit tests +# Taken from perf makefile +uname_M := $(shell uname -m 2>/dev/null || echo not) +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/) +ifeq ($(ARCH),i386) +ARCH := x86 all: all_32 - +endif +ifeq ($(ARCH),x86_64) +ARCH := x86 # If we're on a 64-bit host, build 64-bit tests as well -ifeq ($(shell uname -p),x86_64) -all: all_64 +all: all_32 all_64 endif all_32: check_build32 $(BINARIES_32) all_64: $(BINARIES_64) -clean: - $(RM) $(BINARIES_32) $(BINARIES_64) - -run_tests: - ./run_x86_tests.sh - $(TARGETS_C_BOTHBITS:%=%_32): %_32: %.c +ifeq ($(ARCH),x86) $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl +else + echo "Not an x86 target, can't build x86 tests" +endif $(TARGETS_C_BOTHBITS:%=%_64): %_64: %.c +ifeq ($(ARCH),x86) $(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl +else + echo "Not an x86 target, can't build x86 tests" +endif check_build32: @if ! $(CC) -m32 -o /dev/null trivial_32bit_program.c; then \ @@ -46,3 +51,9 @@ check_build32: echo " yum install glibc-devel.*i686"; \ exit 1; \ fi + +run_tests: + ./run_x86_tests.sh + +clean: + $(RM) $(BINARIES_32) $(BINARIES_64) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/5] arm64: qcom: add cpu operations
On 04/14/2015 10:29 AM, Mark Rutland wrote: >> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt >> b/Documentation/devicetree/bindings/arm/cpus.txt >> index 8b9e0a9..35cabe5 100644 >> --- a/Documentation/devicetree/bindings/arm/cpus.txt >> +++ b/Documentation/devicetree/bindings/arm/cpus.txt >> @@ -185,6 +185,8 @@ nodes to be present and contain the properties described >> below. >> be one of: >> "psci" >> "spin-table" > > In the case of these two, there's documentation on what the OS, FW, and > HW are expected to do. There's a PSCI spec, and spin-table is documented > in booting.txt (which is admittedly not fantastic). > [snip...] Perhaps a side topic, but I thought spin-table was being actively discouraged for arm64. Forgive me if I missed the memo, but is that not correct? -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf kmem: Fix compiles on RHEL6/OL6
Em Tue, Apr 14, 2015 at 01:49:33PM -0400, David Ahern escreveu: > 0d68bc92c48 breaks compiles on RHEL6/OL6: > cc1: warnings being treated as errors > builtin-kmem.c: In function ‘search_page_alloc_stat’: > builtin-kmem.c:322: error: declaration of ‘stat’ shadows a global > declaration > node = >rb_left; > /usr/include/sys/stat.h:455: error: shadowed declaration is here > builtin-kmem.c: In function ‘perf_evsel__process_page_alloc_event’: > builtin-kmem.c:378: error: declaration of ‘stat’ shadows a global > declaration > /usr/include/sys/stat.h:455: error: shadowed declaration is here > builtin-kmem.c: In function ‘perf_evsel__process_page_free_event’: > builtin-kmem.c:431: error: declaration of ‘stat’ shadows a global > declaration > /usr/include/sys/stat.h:455: error: shadowed declaration is here > > Rename local variable to pstat to avoid the name conflict. Thanks, applied, fixed the build on Fedora14 as well. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] selftests/exec: do not install subdir as it is already created
Remove subdir from DEPS as it is already created at runtime. Without this, make install fails. Signed-off-by: Tyler Baker --- tools/testing/selftests/exec/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/exec/Makefile b/tools/testing/selftests/exec/Makefile index 4edb7d0..6b76bfd 100644 --- a/tools/testing/selftests/exec/Makefile +++ b/tools/testing/selftests/exec/Makefile @@ -1,6 +1,6 @@ CFLAGS = -Wall BINARIES = execveat -DEPS = execveat.symlink execveat.denatured script subdir +DEPS = execveat.symlink execveat.denatured script all: $(BINARIES) $(DEPS) subdir: -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.)
On Tue, 2015-04-14 at 14:58 +0200, Ingo Molnar wrote: > * Michael Ellerman wrote: > > > On Tue, 2015-04-14 at 10:55 +0200, Ingo Molnar wrote: > > > * Sukadev Bhattiprolu wrote: > > > > > > > This is another attempt to resurrect Andi Kleen's patchset so users > > > > can specify perf events by their event names rather than raw codes. > > > > > > > > This is a rebase of Andi Kleen's patchset from Jul 30, 2014[1] to 4.0. > > > > (I fixed minor and not so minor conflicts). > > > > > > So this series shows some progress, but instead of this limited > > > checkout ability I'd still prefer it if 'perf download' downloaded > > > the latest perf code itself and built it - it shouldn't be limited > > > to just a small subset of the perf source code! > > > > Ingo, can you please stop blocking this? It's getting ridiculous. > > > > We've been waiting over 8 months for this to go in. > > We just merged a patch series that was first sent in 2013. Some things > take time to get right. The first attempt to get symbolic event name support into perf was sent in 2010, that's FIVE years ago [1]. And what complicated feature are we asking for? The ability to map a human readable name to a hex code, it has the complexity of a first year programming assignment. Variations have been submitted by IBM [1], by Facebook [2], now by Intel, and Google have just given up and carry the libpfm4 patch in their perf tool [3]. Can we please just get this merged. If you *then* want to add support for perf auto-updating that's fine, but don't conflate the two. cheers [1]: https://lkml.org/lkml/2010/3/11/146 [2]: http://article.gmane.org/gmane.comp.linux.perfmon2.devel/2912 [3]: https://github.com/David-Levinthal/gooda/blob/master/gooda-analyzer/perf-patches/linux-v3.17/0001-perf-tools-add-support-for-libpfm4.patch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] selftests/ftrace: install test.d
The ftrace test requires the directory test.d and all of it's contents to be present during execution. Use TEST_DIRS to ensure this is copied to the INSTALL_PATH. Signed-off-by: Tyler Baker --- tools/testing/selftests/ftrace/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/ftrace/Makefile b/tools/testing/selftests/ftrace/Makefile index 3467206..0acbeca 100644 --- a/tools/testing/selftests/ftrace/Makefile +++ b/tools/testing/selftests/ftrace/Makefile @@ -1,6 +1,7 @@ all: TEST_PROGS := ftracetest +TEST_DIRS := test.d/ include ../lib.mk -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] selftests: copy TEST_DIRS to INSTALL_PATH
Loop over all TEST_DIRS and recursively copy them to the INSTALL_PATH. Tests such as ftrace require a directory and all of it's contents to execute the test properly, thus these directories and files need to be copied when we perform an install. Signed-off-by: Tyler Baker --- tools/testing/selftests/lib.mk | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk index 2194155..ee412ba 100644 --- a/tools/testing/selftests/lib.mk +++ b/tools/testing/selftests/lib.mk @@ -13,6 +13,9 @@ run_tests: all define INSTALL_RULE mkdir -p $(INSTALL_PATH) + @for TEST_DIR in $(TEST_DIRS); do\ + cp -r $$TEST_DIR $(INSTALL_PATH); \ + done; install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_PROGS_EXTENDED) $(TEST_FILES) endef -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] selftests/breakpoints: emit skip and omit installation when tests are not compiled
The breakpoints test should only should be executed on x86 targets, so lets emit a skip and omit the installation when ARCH != x86. Signed-off-by: Tyler Baker --- tools/testing/selftests/breakpoints/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/breakpoints/Makefile b/tools/testing/selftests/breakpoints/Makefile index 1822356..430b76d 100644 --- a/tools/testing/selftests/breakpoints/Makefile +++ b/tools/testing/selftests/breakpoints/Makefile @@ -8,7 +8,6 @@ ifeq ($(ARCH),x86_64) ARCH := x86 endif - all: ifeq ($(ARCH),x86) gcc breakpoint_test.c -o breakpoint_test @@ -20,5 +19,11 @@ TEST_PROGS := breakpoint_test include ../lib.mk +install: +ifneq ($(ARCH),x86) +echo "Not an x86 target, can't install breakpoints selftests" +override EMIT_TESTS := echo "echo \"selftests: breakpoint_test [SKIP]\"" +endif + clean: rm -fr breakpoint_test -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] selftests/kdbus: install kdbus-test
Set TEST_PROGS so that kdbus-test is installed. Cc: Greg Kroah-Hartman Signed-off-by: Tyler Baker --- tools/testing/selftests/kdbus/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/kdbus/Makefile b/tools/testing/selftests/kdbus/Makefile index e21bf1f..62f8d5a 100644 --- a/tools/testing/selftests/kdbus/Makefile +++ b/tools/testing/selftests/kdbus/Makefile @@ -42,6 +42,8 @@ include ../lib.mk kdbus-test: $(OBJS) $(CC) $(CFLAGS) $^ $(LDLIBS) -o $@ +TEST_PROGS := kdbus-test + run_tests: ./kdbus-test --tap -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] selftests: fixes for installation and cross compilation
This patch set fixes various issues observed when cross building and installing selftests. As I began investigating improving the test output format, I performed an audit of the current tests to ensure all tests were able to execute on various target architectures. I found that some tests did not install their binaries and others required directories to be installed to execute properly. There were also cases in which tests were being installed when they were never built. With this series applied all tests compile when appropriate and install their output properly. I have tested this series by building, installing and deploying all selftests to x86, arm and arm64 targets. This series is based on next-20150414 Tyler Baker (7): selftests: copy TEST_DIRS to INSTALL_PATH selftests/ftrace: install test.d selftests/breakpoints: emit skip and omit installation when tests are not compiled selftests/kdbus: install kdbus-test selftests/x86: fix cross build logic selftests/x86: install tests selftests/exec: do not install subdir as it is already created tools/testing/selftests/breakpoints/Makefile | 7 - tools/testing/selftests/exec/Makefile| 2 +- tools/testing/selftests/ftrace/Makefile | 1 + tools/testing/selftests/kdbus/Makefile | 2 ++ tools/testing/selftests/lib.mk | 3 ++ tools/testing/selftests/x86/Makefile | 41 +--- 6 files changed, 44 insertions(+), 12 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] kdbus for 4.1-rc1
On Tue, 14 Apr 2015, Greg Kroah-Hartman wrote: > I don't understand. You can not like the D-Bus model (and accordingly > the X11 model), I thought that the general hatred level of the X11 "model" and the protocol lead to al the efforts to reimplement this properly ... in userspace (for example Wayland, right?). I don't think anyone was ever seriously suggesting "X11 model is broken, so let's push it to kernel" ... ? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] kdbus for 4.1-rc1
On Tue, 14 Apr 2015, Greg Kroah-Hartman wrote: > Yes, it's an unfortunate design, but one that we are all stuck with > (think of it as having to implement code for horrid hardware that you > have to get to work properly.) Greg, I personally consider this a rather defunct analogy. Broken hardware comes from "outter space" we just have to live with somehow, and eventually try to gradually improve by working with vendors (and you yourself have of course made huge improvements in this very area). Linux userspace is coming, well, from Linux developers. The sole fact that someone wrote a daemon that runs on Linux seems like a very poor justification for sucking the daemon into kernel "because we have to live with it". Userspace has to live with it somehow (and eventually fix itself if necessary), yes. Why should kernel just contribute to this "unfortunate design" if it really isn't, in any way, obliged or forced to do so? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 03:21:17PM +0100, Kumar Gala wrote: [...] > > Looking beyond this set of patches, I can foresee that you won't care > > about the generic arm64 cpuidle driver either, or more precisely the > > separation between cpuidle subsystem+driver and the SoC-specific > > back-end (cpu_operations). > > That's probably true for what I guess are a number of reasons. I'm guessing > the arm64 cpuidle driver expects PSCI. Wrap lines sensibly please. The arm64 cpuidle driver, that is now arm generic cpuidle driver does not expect anything apart from an enable-method (and you pulled part of its back-end implementation for arm32 Qualcomm platforms, FYI). It took years to consolidate it and the main reason was the lack of standard interfaces for power down/up sequences that this patchset of yours wants to promote in arm64 world. The lack of standard power interfaces may not have been an issue for you, who cares about Qualcomm code, it has been a sore issue for people trying to generalize things across ARM platforms in the kernel, which is the only sensible way forward. PSCI is a standard interface (and Qualcomm are already contributing to it, for the records) that can certainly be extended, and you are welcome to contribute to it, but certainly not ignored. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote: > On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: > > For completeness, there is yet another option, which would be to use the > > exact system call table from arm64 and do all the emulation in user space > > rather than the kernel. This would however be the least compatible with > > existing source code, so you probably don't want to do that. > > It would be great if this worked but I think we looked at it before and > it seems nice until you hit the futex stuff and robust lists (I don't > fully remember the details). Some of the structures (siginfo) would no > longer be POSIX compliant and some of them aren't only accessed via libc > to be able to create shadow copies. Well, that may or may not be acceptable. Aarch64-ilp32 mode is a hack to enable a very special class of applications, it's not like anyone would want to run a full system for this and need POSIX compliance. We could definitely be pragmatic and do whatever helps get the job done. That said, it diverges further from what legacy 32-bit applications expect to see, so this approach will likely make an application port harder, not easier. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/5] perf: Fixup hrtimer forward wreckage
On Mon, Apr 13, 2015 at 2:02 PM, Thomas Gleixner wrote:
>
> perf_event_mux_interval_ms_store() tries to apply an updated
> hrtimer_interval to all possible cpus in a completely unsafe way. The
> changelog of the offending commit says:
>
> "In the 5th version, we handle the reprogramming of the hrtimer using
> hrtimer_forward_now(). That way, we sync up to new timer value
> quickly (suggested by Jiri Olsa)."
>
> The hrtimer reprogramming is completely unrelated to
> hrtimer_forward_now(). hrtimer_forward_now() merily forwards the
> expiry time of the hrtimer past now and that's where things get really
> bad in this code:
>
> The forward function is called on enqueued timers. That means the
> update of the expiry time corrupts the ordering of the hrtimer rbtree.
>
> The proper way to update hrtimers on remote cpus is to use a smp
> function call on all online cpus and perform the update locally by
> canceling the timer, forwarding and restarting it.
>
> Fixes: 62b856397927 "perf: Add sysfs entry to adjust multiplexing interval
> per PMU"
> Signed-off-by: Thomas Gleixner
> Cc: Stephane Eranian
> Cc: Jiri Olsa
> Cc: sta...@vger.kernel.org
> Cc: Arnaldo Carvalho de Melo
Thanks for fixing this Thomas!
>
> ---
> kernel/events/core.c | 36
> 1 file changed, 20 insertions(+), 16 deletions(-)
>
> Index: linux/kernel/events/core.c
> ===
> --- linux.orig/kernel/events/core.c
> +++ linux/kernel/events/core.c
> @@ -6827,13 +6827,27 @@ perf_event_mux_interval_ms_show(struct d
> return snprintf(page, PAGE_SIZE-1, "%d\n", pmu->hrtimer_interval_ms);
> }
>
> +static void perf_event_mux_update_interval(void *info)
> +{
> + struct pmu *pmu = info;
> + struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu->pmu_cpu_context);
> + int was_armed = hrtimer_cancel(>hrtimer);
> +
> + /* Update the interval and restart the timer with the new interval */
> + cpuctx->hrtimer_interval = ms_to_ktime(pmu->hrtimer_interval_ms);
> + if (was_armed) {
> + hrtimer_forward_now(>hrtimer,
> cpuctx->hrtimer_interval);
> + hrtimer_start_expires(>hrtimer, HRTIMER_MODE_ABS);
> + }
> +}
> +
> static ssize_t
> perf_event_mux_interval_ms_store(struct device *dev,
> struct device_attribute *attr,
> const char *buf, size_t count)
> {
> struct pmu *pmu = dev_get_drvdata(dev);
> - int timer, cpu, ret;
> + int timer, ret;
>
> ret = kstrtoint(buf, 0, );
> if (ret)
> @@ -6842,22 +6856,12 @@ perf_event_mux_interval_ms_store(struct
> if (timer < 1)
> return -EINVAL;
>
> - /* same value, noting to do */
> - if (timer == pmu->hrtimer_interval_ms)
> - return count;
> -
> - pmu->hrtimer_interval_ms = timer;
> -
> - /* update all cpuctx for this PMU */
> - for_each_possible_cpu(cpu) {
> - struct perf_cpu_context *cpuctx;
> - cpuctx = per_cpu_ptr(pmu->pmu_cpu_context, cpu);
> - cpuctx->hrtimer_interval = ns_to_ktime(NSEC_PER_MSEC * timer);
> -
> - if (hrtimer_active(>hrtimer))
> - hrtimer_forward_now(>hrtimer,
> cpuctx->hrtimer_interval);
> + if (timer != pmu->hrtimer_interval_ms) {
> + get_online_cpus();
> + pmu->hrtimer_interval_ms = timer;
> + on_each_cpu(perf_event_mux_update_interval, pmu, 1);
> + put_online_cpus();
> }
> -
> return count;
> }
> static DEVICE_ATTR_RW(perf_event_mux_interval_ms);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
