linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/entry/entry_64_compat.S
between commit:
cd88ec231701 ("x86: fix error handling for 32-bit compat out-of-range system
call numbers")
from Linus' tree and commit:
c73e36b775a7 ("x86/asm/entry/32: Replace RESTORE_RSI_RDI with open-coded
32-bit reads")
from the tip tree.
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 arch/x86/entry/entry_64_compat.S
index a7e257d9cb90,8997383ba170..
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@@ -140,8 -140,8 +140,9 @@@ sysexit_from_sys_call
*/
andl$~TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS)
movlRIP(%rsp), %ecx /* User %eip */
+ movqRAX(%rsp), %rax
- RESTORE_RSI_RDI
+ movlRSI(%rsp), %esi
+ movlRDI(%rsp), %edi
xorl%edx, %edx /* Do not leak kernel information */
xorq%r8, %r8
xorq%r9, %r9
@@@ -365,10 -366,11 +366,12 @@@ cstar_dispatch
sysretl_from_sys_call:
andl$~TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS)
- RESTORE_RSI_RDI_RDX
+ movlRDX(%rsp), %edx
+ movlRSI(%rsp), %esi
+ movlRDI(%rsp), %edi
movlRIP(%rsp), %ecx
movlEFLAGS(%rsp), %r11d
+ movqRAX(%rsp), %rax
xorq%r10, %r10
xorq%r9, %r9
xorq%r8, %r8
--
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] book3s_hv_rmhandlers:Pass the correct trap argument to kvmhv_commence_exit
Hi Sam, On Fri, Aug 14, 2015 at 03:07:28PM +1000, Sam Bobroff wrote: > On Thu, May 21, 2015 at 01:57:04PM +0530, Gautham R. Shenoy wrote: > > In guest_exit_cont we call kvmhv_commence_exit which expects the trap > > number as the argument. However r3 doesn't contain the trap number at > > this point and as a result we would be calling the function with a > > spurious trap number. > > > > Fix this by copying r12 into r3 before calling kvmhv_commence_exit as > > r12 contains the trap number > > > > Signed-off-by: Gautham R. Shenoy > > Hi Gautham, > > I agree with your logic: r3 is quite clearly corrupted in that path. So: > > Reviewed-by: Sam Bobroff > > Just one comment: Do you have a case of this causing some visible problem due > to the corrupted trap number? (I'll test the patch if you do.) > Actually no! I found this bug while reviewing the code for some other issue. > Cheers, > Sam. -- Thanks and Regards gautham. -- 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] mmc: dw_mmc: simplify the SDMMC_CLKEN_LOW_PWR logic
Hello,
On 17 August 2015 at 03:55, Jaehoon Chung wrote:
> Hi, Michal.
>
> On 08/12/2015 09:23 PM, Michal Suchanek wrote:
>> The driver has open-coded test for SDIO cards. Use the mmc core provided
>> MMC_QUIRK_BROKEN_CLK_GATING flag instead.
>
> Did you use the clock-gating for SDIO cards?
> Doesn't MMC_CAP_SDIO_IRQ bit set? Which case is broken?
> Could you explain to me more?
The core flag for disabling power saving is MMC_QUIRK_BROKEN_CLK_GATING.
It may coincide with MMC_CAP_SDIO_IRQ but that's different flag for
different purpose.
MMC_QUIRK_BROKEN_CLK_GATING is currently set for all SDIO cards except
for cards on a whitelist.
I don't know any particular SDIO card that has problems when the clock
is off and does not use an IRQ.
Thanks
Michal
>
> Best Regards,
> Jaehoon Chung
>
>>
>> As a bonus this may enable clock gating on SDIO cards that are known to
>> work with it.
>>
>> Signed-off-by: Michal Suchanek
>> ---
>> drivers/mmc/host/dw_mmc.c | 33 +++--
>> 1 file changed, 15 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 40e9d8e..3bc9fd7 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1335,27 +1335,24 @@ static void dw_mci_init_card(struct mmc_host *mmc,
>> struct mmc_card *card)
>>* description of the CLKENA register we should disable low power mode
>>* for SDIO cards if we need SDIO interrupts to work.
>>*/
>> - if (mmc->caps & MMC_CAP_SDIO_IRQ) {
>> - const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
>> - u32 clk_en_a_old;
>> - u32 clk_en_a;
>> + const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
>> + u32 clk_en_a_old;
>> + u32 clk_en_a;
>>
>> - clk_en_a_old = mci_readl(host, CLKENA);
>> + clk_en_a_old = mci_readl(host, CLKENA);
>>
>> - if (card->type == MMC_TYPE_SDIO ||
>> - card->type == MMC_TYPE_SD_COMBO) {
>> - set_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
>> - clk_en_a = clk_en_a_old & ~clken_low_pwr;
>> - } else {
>> - clear_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
>> - clk_en_a = clk_en_a_old | clken_low_pwr;
>> - }
>> + if (card->quirks & MMC_QUIRK_BROKEN_CLK_GATING) {
>> + set_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
>> + clk_en_a = clk_en_a_old & ~clken_low_pwr;
>> + } else {
>> + clear_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
>> + clk_en_a = clk_en_a_old | clken_low_pwr;
>> + }
>>
>> - if (clk_en_a != clk_en_a_old) {
>> - mci_writel(host, CLKENA, clk_en_a);
>> - mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
>> - SDMMC_CMD_PRV_DAT_WAIT, 0);
>> - }
>> + if (clk_en_a != clk_en_a_old) {
>> + mci_writel(host, CLKENA, clk_en_a);
>> + mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
>> + SDMMC_CMD_PRV_DAT_WAIT, 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: linux-next: build failure after merge of the drm-exynos tree
Hi Inki,
On Mon, 17 Aug 2015 13:53:42 +1000 Stephen Rothwell
wrote:
>
> On Mon, 17 Aug 2015 13:51:30 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the drm-exynos tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > drivers/gpu/drm/exynos/exynos_mixer.c: In function 'vp_video_buffer':
> > drivers/gpu/drm/exynos/exynos_mixer.c:395:15: error: 'struct
> > exynos_drm_plane' has no member named 'pixel_format'
> > switch (plane->pixel_format) {
> >^
> > In file included from drivers/gpu/drm/exynos/exynos_mixer.c:17:0:
> > drivers/gpu/drm/exynos/exynos_mixer.c:404:10: error: 'struct
> > exynos_drm_plane' has no member named 'pixel_format'
> > plane->pixel_format);
> > ^
> > include/drm/drmP.h:164:17: note: in definition of macro 'DRM_ERROR'
> > drm_err(fmt, ##__VA_ARGS__)
> > ^
> > drivers/gpu/drm/exynos/exynos_mixer.c:411:11: error: 'struct
> > exynos_drm_plane' has no member named 'scan_flag'
> > if (plane->scan_flag & DRM_MODE_FLAG_INTERLACE) {
> >^
> > drivers/gpu/drm/exynos/exynos_mixer.c:417:39: error: 'struct
> > exynos_drm_plane' has no member named 'pitch'
> > luma_addr[1] = luma_addr[0] + plane->pitch;
> >^
> > drivers/gpu/drm/exynos/exynos_mixer.c:418:43: error: 'struct
> > exynos_drm_plane' has no member named 'pitch'
> > chroma_addr[1] = chroma_addr[0] + plane->pitch;
> >^
> > In file included from drivers/gpu/drm/exynos/exynos_mixer.c:20:0:
> > drivers/gpu/drm/exynos/exynos_mixer.c:439:53: error: 'struct
> > exynos_drm_plane' has no member named 'pitch'
> > vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(plane->pitch) |
> > ^
> > drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
> > 'VP_MASK_VAL'
> > (((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
> > ^
> > drivers/gpu/drm/exynos/exynos_mixer.c:439:35: note: in expansion of macro
> > 'VP_IMG_HSIZE'
> > vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(plane->pitch) |
> >^
> > drivers/gpu/drm/exynos/exynos_mixer.c:440:21: error: 'struct
> > exynos_drm_plane' has no member named 'fb_height'
> >VP_IMG_VSIZE(plane->fb_height));
> > ^
> > drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
> > 'VP_MASK_VAL'
> > (((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
> > ^
> > drivers/gpu/drm/exynos/exynos_mixer.c:440:3: note: in expansion of macro
> > 'VP_IMG_VSIZE'
> >VP_IMG_VSIZE(plane->fb_height));
> >^
> > drivers/gpu/drm/exynos/exynos_mixer.c:442:53: error: 'struct
> > exynos_drm_plane' has no member named 'pitch'
> > vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(plane->pitch) |
> > ^
> > drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
> > 'VP_MASK_VAL'
> > (((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
> > ^
> > drivers/gpu/drm/exynos/exynos_mixer.c:442:35: note: in expansion of macro
> > 'VP_IMG_HSIZE'
> > vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(plane->pitch) |
> >^
> > drivers/gpu/drm/exynos/exynos_mixer.c:443:21: error: 'struct
> > exynos_drm_plane' has no member named 'fb_height'
> >VP_IMG_VSIZE(plane->fb_height / 2));
> > ^
> > drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
> > 'VP_MASK_VAL'
> > (((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
> > ^
> > drivers/gpu/drm/exynos/exynos_mixer.c:443:3: note: in expansion of macro
> > 'VP_IMG_VSIZE'
> >VP_IMG_VSIZE(plane->fb_height / 2));
> >^
> > drivers/gpu/drm/exynos/exynos_mixer.c:445:39: error: 'struct
> > exynos_drm_plane' has no member named 'src_width'
> > vp_reg_write(res, VP_SRC_WIDTH, plane->src_width);
> >^
> > drivers/gpu/drm/exynos/exynos_mixer.c:446:40: error: 'struct
> > exynos_drm_plane' has no member named 'src_height'
> > vp_reg_write(res, VP_SRC_HEIGHT, plane->src_height);
> > ^
> > drivers/gpu/drm/exynos/exynos_mixer.c:451:39: error: 'struct
> > exynos_drm_plane' has no member named 'crtc_width'
> > vp_reg_write(res, VP_DST_WIDTH, plane->crtc_width);
> >^
> > drivers/gpu/drm/exynos/exynos_mixer.c:454:41: error: 'struct
> > exynos_drm_plane' has no member named 'crtc_height'
> >vp_reg_write(res, VP_DST_HEIGHT, plane->crtc_height / 2);
> > ^
> > drivers/gpu/drm/exynos/exynos_mixer.c:457:41: error: 'struct
> > exynos_drm_plane' has no member named 'crtc_height'
> >vp_reg_write(res, VP_DST_HEIGHT, plane->crtc_height);
> > ^
> > drivers/gpu/drm/exynos/exynos_mixer.c:472:27: error: 'struct
> >
Re: [PATCH v7 4/5] clk: Provide critical clock support
2015-07-22 21:04 GMT+08:00 Lee Jones :
> Lots of platforms contain clocks which if turned off would prove fatal.
> The only way to recover from these catastrophic failures is to restart
> the board(s). Now, when a clock provider is registered with the
> framework it is possible for a list of critical clocks to be supplied
> which must be kept ungated. Each clock mentioned in the newly
> introduced 'critical-clock' property will be clk_prepare_enable()d
> where the normal references will be taken. This will prevent the
> common clk framework from attempting to gate them during the normal
> clk_disable_unused() and disable_clock() procedures.
>
> Note that it will still be possible for knowledgeable drivers to turn
> these clocks off using clk_{enable,disable}_critical() calls.
>
> Signed-off-by: Lee Jones
hi Lee,
i have another email about this. i am wondering whether
CLK_IGNORE_UNUSE is still useful after your patch. another solution
for your patch might be extending the current CLK_IGNORE_UNUSE to
runtime?
copy the mail here:
currently we can set a CLK_IGNORE_UNUSE flag to a clock to stop
clk_disable_unused() from disabling it at the boot stage:
static void clk_disable_unused_subtree(struct clk_core *core)
{
...
if (core->flags & CLK_IGNORE_UNUSED)
goto unlock_out;
}
static int clk_disable_unused(void)
{
...
clk_unprepare_unused_subtree(core);
...
return 0;
}
late_initcall_sync(clk_disable_unused);
so if there are two clocks A and B, A is the parent of B, and A is
marked as CLK_IGNORE_UNUSED.
in boot stage if there is nobody using A and B, Linux will disable B
due to clk_disable_unused() , but keep A being enabled since A has
CLK_IGNORE_UNUSED.
but in Linux runtime, we might frequently disable /enable B in runtime
power management, this will cause A disabled since Linux will not
check CLK_IGNORE_UNUSED for runtime disabling clk .
so this makes CLK_IGNORE_UNUSE only work if we don't disable its
sub-clock at runtime. this looks making no sense.
i am thinking whether we should do some changes to make it have side
affect for runtime clk disable. otherwise, why do we want to stop it
from being disabled during boot stage?
I am not sure whether i missed something in clk core level support.
-barry
> ---
> drivers/clk/clk-conf.c | 45 -
> 1 file changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-conf.c b/drivers/clk/clk-conf.c
> index aad4796..f83c1c2 100644
> --- a/drivers/clk/clk-conf.c
> +++ b/drivers/clk/clk-conf.c
> @@ -116,6 +116,45 @@ static int __set_clk_rates(struct device_node *node,
> bool clk_supplier)
> return 0;
> }
>
> +static int __set_critical_clocks(struct device_node *node, bool clk_supplier)
> +{
> + struct of_phandle_args clkspec;
> + struct clk *clk;
> + struct property *prop;
> + const __be32 *cur;
> + uint32_t index;
> + int ret;
> +
> + if (!clk_supplier)
> + return 0;
> +
> + of_property_for_each_u32(node, "critical-clock", prop, cur, index) {
> + clkspec.np = node;
> + clkspec.args_count = 1;
> + clkspec.args[0] = index;
> +
> + clk = of_clk_get_from_provider();
> + if (IS_ERR(clk)) {
> + pr_err("clk: couldn't get clock %u for %s\n",
> + index, node->full_name);
> + return PTR_ERR(clk);
> + }
> +
> + clk_init_critical(clk);
> +
> + ret = clk_prepare_enable(clk);
> + if (ret) {
> + pr_err("Failed to enable clock %u for %s: %d\n",
> + index, node->full_name, ret);
> + return ret;
> + }
> +
> + pr_debug("Setting clock as critical %pC\n", clk);
> + }
> +
> + return 0;
> +}
> +
> /**
> * of_clk_set_defaults() - parse and set assigned clocks configuration
> * @node: device node to apply clock settings for
> @@ -139,6 +178,10 @@ int of_clk_set_defaults(struct device_node *node, bool
> clk_supplier)
> if (rc < 0)
> return rc;
>
> - return __set_clk_rates(node, clk_supplier);
> + rc = __set_clk_rates(node, clk_supplier);
> + if (rc < 0)
> + return rc;
> +
> + return __set_critical_clocks(node, clk_supplier);
> }
> EXPORT_SYMBOL_GPL(of_clk_set_defaults);
> --
> 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/
LOAN OFFERS AT LOW INTEREST
We give out loans at low 3% interest rate and We are always ready to cater to your loan need no matter your credit background.I will offer you loan as you requested, be you inform that we only attend to serious individuals, if you are applying this loan i will want you to be serious about it, i will also want you to know that getting a loan from my company is 3% assured, so it all depend on you, i will want you to fill the borrower's information below and return back to me as soon as possible so that we can proceed further. BORROWERS INFORMATION Your names. ...Your country..Your address ...Your occupation ..Your marital status ...Current Status at place of work..Phone number..Monthly Income. ...Loan AmountLoan Duration.. Regard, CITY FINANCIAL LENDER. -- 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 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs
Hi,
On Friday 07 August 2015 06:00 PM, Chunfeng Yun wrote:
> support usb3.0 phy of mt65xx SoCs
>
> Signed-off-by: Chunfeng Yun
change $subject to phy:
> ---
> drivers/phy/Kconfig | 9 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-mt65xx-usb3.c | 467
> ++
> 3 files changed, 477 insertions(+)
> create mode 100644 drivers/phy/phy-mt65xx-usb3.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index c0e6ede..019cf8b 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -193,6 +193,15 @@ config PHY_HIX5HD2_SATA
> help
> Support for SATA PHY on Hisilicon hix5hd2 Soc.
>
> +config PHY_MT65XX_USB3
> + tristate "Mediatek USB3.0 PHY Driver"
> + depends on ARCH_MEDIATEK && OF
> + select GENERIC_PHY
> + help
> + Say 'Y' here to add support for Mediatek USB3.0 PHY driver
> + for mt65xx SoCs. it supports two usb2.0 ports and
> + one usb3.0 port.
> +
> config PHY_SUN4I_USB
> tristate "Allwinner sunxi SoC USB PHY driver"
> depends on ARCH_SUNXI && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index f344e1b..3ceff2a 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_TI_PIPE3) +=
> phy-ti-pipe3.o
> obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
> obj-$(CONFIG_PHY_EXYNOS5250_SATA)+= phy-exynos5250-sata.o
> obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
> +obj-$(CONFIG_PHY_MT65XX_USB3)+= phy-mt65xx-usb3.o
> obj-$(CONFIG_PHY_SUN4I_USB) += phy-sun4i-usb.o
> obj-$(CONFIG_PHY_SUN9I_USB) += phy-sun9i-usb.o
> obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> new file mode 100644
> index 000..6835bff
> --- /dev/null
> +++ b/drivers/phy/phy-mt65xx-usb3.c
.
.
.
.
> +static struct phy *mt65xx_phy_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct mt65xx_u3phy *u3phy = dev_get_drvdata(dev);
> + struct mt65xx_phy_instance *instance = NULL;
> + struct device_node *phy_np = args->np;
> + struct resource res;
> + int index;
> + int ret;
> +
> + if (args->args_count != 1) {
> + dev_err(dev, "invalid number of cells in 'phy' property\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + for (index = 0; index < u3phy->nphys; index++)
> + if (phy_np == u3phy->phys[index]->phy->dev.of_node) {
> + instance = u3phy->phys[index];
> + break;
> + }
> +
> + if (!instance) {
> + dev_err(dev, "failed to find appropriate phy\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + instance->type = args->args[0];
> +
> + if (!(instance->type == PHY_TYPE_USB2 ||
> + instance->type == PHY_TYPE_USB3)) {
> + dev_err(dev, "unsupported device type: %d\n", instance->type);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + ret = of_address_to_resource(phy_np, 0, );
> + if (ret) {
> + dev_err(dev, "failed to get address resource, err-%d
> (index-%d)\n",
> + ret, instance->index);
> + return ERR_PTR(-EINVAL);
> + }
This should be done in probe itself.
> +
> + instance->port_base = devm_ioremap_resource(>phy->dev, );
> + if (IS_ERR(instance->port_base)) {
> + dev_err(dev, "failed to remap sif regs\n");
> + return instance->port_base;
> + }
This too should be done in probe.
> +
> + return instance->phy;
> +}
> +
> +static struct phy_ops mt65xx_u3phy_ops = {
> + .init = mt65xx_phy_init,
> + .power_on = mt65xx_phy_power_on,
> + .power_off = mt65xx_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int mt65xx_u3phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *child_np;
> + struct phy_provider *phy_provider;
> + struct resource *sif_res;
> + struct mt65xx_u3phy *u3phy;
> + int port;
> +
> + u3phy = devm_kzalloc(dev, sizeof(*u3phy), GFP_KERNEL);
> + if (!u3phy)
> + return -ENOMEM;
> +
> + u3phy->nphys = of_get_child_count(np);
> + u3phy->phys = devm_kcalloc(dev, u3phy->nphys,
> +sizeof(*u3phy->phys), GFP_KERNEL);
> + if (!u3phy->phys)
> + return -ENOMEM;
> +
> + u3phy->dev = dev;
> + platform_set_drvdata(pdev, u3phy);
> +
> + sif_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + u3phy->sif_base = devm_ioremap_resource(dev, sif_res);
> + if (IS_ERR(u3phy->sif_base)) {
> + dev_err(dev, "failed to remap sif regs\n");
>
linux-next: build failure after merge of the security tree
Hi James,
After merging the security tree, today's linux-next build (x86_64
allmodconfig) failed like this:
scripts/extract-cert.c:23:25: fatal error: openssl/bio.h: No such file or
directory
#include
^
compilation terminated.
scripts/sign-file.c:20:25: fatal error: openssl/bio.h: No such file or directory
#include
^
Caused by commits:
1329e8cc69b9 ("modsign: Extract signing cert from CONFIG_MODULE_SIG_KEY if
needed")
bc1c373dd2a5 ("MODSIGN: Provide a utility to append a PKCS#7 signature to a
module")
After a bit of digging, I installed libssl-dev on my Debian build
machines.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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] mm/hwpoison: fix race between soft_offline_page and unpoison_memory
On 8/17/15 12:32 PM, Naoya Horiguchi wrote: > [...] > OK, so I wrote the next version against mmotm-2015-08-13-15-29 (replied to > this email.) It moves PageSetHWPoison part into migration code, which should > close up the reported race window and minimize the another revived race window > of reusing offlined pages, so I feel that it's a good compromise between two > races. > > My testing shows no kernel panic with these patches (same testing easily > caused > panics for bare mmotm-2015-08-13-15-29,) so they should work. But I'm > appreciated > if you help double checking. This patchset looks good to me after some stress testing. Andrew, Could we pick it in order to catch up upcoming merge window? :-) Regards, Wanpeng Li -- 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 v2 4/4] arm64: ftrace: add a stack frame for exception handler
On 08/11/2015 11:57 PM, Jungseok Lee wrote:
On Aug 4, 2015, at 4:44 PM, AKASHI Takahiro wrote:
Hi Akashi,
On arm64, an exception handler use the same stack as in non-exception
contexts, but doesn't create a stack frame for elx_xx entry, only updating
sp register. This behavior results in save_stace_trace() missing a function
that is the one when an exception happens.
This patch creates a stack frame for this case, and puts an additional
entry for the function in a stack trace list.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/kernel/entry.S |4
arch/arm64/kernel/stacktrace.c | 17 +
2 files changed, 21 insertions(+)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index f860bfd..aacb6c6 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -107,6 +107,8 @@
str x21, [sp, #S_SYSCALLNO]
.endif
+ /* create a stack frame for stack tracer */
+ mov x29, sp
/*
* Registers that may be useful after this macro is invoked:
*
@@ -737,3 +739,5 @@ ENTRY(sys_rt_sigreturn_wrapper)
mov x0, sp
b sys_rt_sigreturn
ENDPROC(sys_rt_sigreturn_wrapper)
+
+ENTRY(end_of_vectors)
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index d1790eb..22ce7c9 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -25,6 +25,10 @@
#include
#define S_FRAME_SIZE sizeof(struct pt_regs) /* asm-offsets.h */
+#define S_FP offsetof(struct pt_regs, regs[29])
+#define S_LR offsetof(struct pt_regs, regs[30])
+
+extern unsigned int *vectors, *end_of_vectors;
/*
* AArch64 PCS assigns the frame pointer to x29.
@@ -50,6 +54,19 @@ int notrace unwind_frame(struct stackframe *frame)
if (fp < low || fp > high - 0x18 || fp & 0xf)
return -EINVAL;
+ if ((frame->pc >= (unsigned long)) &&
+ (frame->pc < (unsigned long)_of_vectors)) {
+ /*
+* Expection handler does not use a normal format of
+* stack frame, but allocates struct pt_regs.
+*/
+ frame->sp = frame->sp + S_FRAME_SIZE;
+ frame->fp = *(unsigned long *)(fp + S_FP);
+ frame->pc = *(unsigned long *)(fp + S_LR);
Not frame->pc = *(unsigned long *)(fp + S_PC)? Don't we need to look up elr_el1
since this is an exception?
You are right. Will fix it if I submit the next version.
+
+ return 0;
+ }
+
frame->sp = fp + 0x10;
I'm just curious about this constant, 0x10. Do you have an idea on this value?
As reviewing objdump of vmlinux, it looks needed to analyze the first store-pair
instruction of each function.
Please correct me if I'm wrong.
I don't know Catalin's intention here, but fp always points to saved pair of
and so, in general, "fp + 0x10" is the address of succeeding local
variables
in callee function. (Remember my acsii art :)
This can be the easily-approximated (but not accurate) stack pointer of caller
unless
we decode function prologues.
Thanks,
-Takahiro AKASHI
Best Regards
Jungseok Lee
--
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 v2 0/4] arm64: ftrace: fix incorrect output from stack tracer
Hi On 08/11/2015 11:52 PM, Jungseok Lee wrote: On Aug 4, 2015, at 4:44 PM, AKASHI Takahiro wrote: Hi Akashi, See the following threads [1],[2] for the background. With this patch series, I'm trying to fix several problems I noticed with stack tracer on arm64. But it is rather experimental, and there still remained are several issues. Patch #1 modifies ftrace framework so that we can provide arm64-specific stack tracer later. (Well, I know there is some room for further refactoring, but this is just a prototype code.) Patch #2 implements this arch_check_stack() using unwind_stackframe() to traverse stack frames and identify a stack index for each traced function. Patch #3 addresses an issue that stack tracer doesn't work well in conjuction with function graph tracer. Patch #4 addresses an issue that unwind_stackframe() misses a function that is the one when an exception happens by setting up a stack frame for exception handler. See below for the result with those patches. Issues include: a) Size of gic_handle_irq() is 48 (#13), but should be 64. b) We cannot identify a location of function which is being returned and hooked temporarily by return_to_handler() (#18) c) A meaningless entry (#62) as well as a bogus size for the first function, el0_svc (#61) d) Size doesn't contain a function's "dynamically allocated local variables," if any, but instead is sumed up in child's size. (See details in [3].) I'm afraid that we cannot fix issue b) unless we can do *atomically* push/pop a return adress in current->ret_stack[], increment/decrement current->curr_ret_stack and restore lr register. We will be able to fix issue d) once we know all the locations in the list, including b). [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354126.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355920.html [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358034.html I hope I'm not too late.. I was on vacation last week. This series looks written on top of the hunk in the end of this reply. I've strongly agreed with your opinion as digging out this issue. We need to analyse the first instruction of each function, "stp x29, x30, [sp, #val]!", in order to solve this problem clearly. As far as I notice, the following is not the only prologue: stp x29,x30, [sp,#-xx]! mov x29,sp but some functions may have another one like: sub sp, sp, #xx stp x29,x30, [sp, #16] add x29,sp, #16 Even worse, I see some variant, for example in trace_graph_entry(), adrp x2, 0x... stp x29,x30,[sp,#-xx]! add x4, x2, #.. mov x29,x30 So parsing the function prologue perfectly is a bit more complicated than imagined. I'm now asking some gcc guy for more information. Thanks, -Takahiro AKASHI How about decoding the store-pair instruction? If so, we could record a correct position into stack_dump_index. That is, in your ascii art, top-sp0 and top-sp1 are written into stack_dump_index[i+1] and stack_dump_index[i] respectively. sp2 +---+ <- func-2's stackframe | | | | fp2 +---+ | fp1 | +---+ <-- p1 (*p1 == stack_dump_trace[i] == lr1) | lr1 | +---+ | | | func-2's local variables | | sp1 +---+ <- func-1(lr1)'s stackframe | | (stack_dump_index[i] = top - p1) | func-1's dynamic local variables | | fp1 +---+ | fp0 | +---+ <-- p0 (*p0 == stack_dump_trace[i+1] == lr0) | lr0 | +---+ | | | func-1's local variables | | sp0 +---+ <- func-0(lr0)'s stackframe | | (stack_dump_index[i+1] = top - p0) | | *---+ top Best Regards Jungseok Lee 8< diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h index c5534fa..2b43e20 100644 --- a/arch/arm64/include/asm/ftrace.h +++ b/arch/arm64/include/asm/ftrace.h @@ -13,8 +13,9 @@ #include -#define MCOUNT_ADDR((unsigned long)_mcount) -#define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE +#define MCOUNT_ADDR((unsigned long)_mcount) +#define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE +#define FTRACE_STACK_FRAME_OFFSET AARCH64_INSN_SIZE #ifndef __ASSEMBLY__ #include diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c index 407991b..9ab67af 100644 --- a/arch/arm64/kernel/stacktrace.c +++ b/arch/arm64/kernel/stacktrace.c @@ -20,6 +20,7 @@ #include #include +#include #include /* @@ -52,7 +53,7 @@ int notrace unwind_frame(struct stackframe *frame) * -4 here because we care about the PC at time of bl, * not where the return will go. */ - frame->pc = *(unsigned long *)(fp + 8) - 4; + frame->pc = *(unsigned
linux-next: manual merge of the md tree with the block tree
Hi Neil,
Today's linux-next merge of the md tree got a conflict in:
drivers/md/raid5.c
between commit:
4246a0b63bd8 ("block: add a bi_error field to struct bio")
8ae126660fdd ("block: kill merge_bvec_fn() completely")
from the block tree and commit:
1722781be955 ("md/raid5: switch to use conf->chunk_sectors in place of
mddev->chunk_sectors where possible")
4273c3f9d668 ("md/raid5: use bio_list for the list of bios to return.")
from the md tree.
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 drivers/md/raid5.c
index b29e89cb815b,4195064460d0..
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@@ -233,8 -230,7 +230,7 @@@ static void return_io(struct bio_list *
bi->bi_iter.bi_size = 0;
trace_block_bio_complete(bdev_get_queue(bi->bi_bdev),
bi, 0);
- bio_endio(bi, 0);
+ bio_endio(bi);
- bi = return_bi;
}
}
@@@ -3110,12 -3107,10 +3105,11 @@@ handle_failed_stripe(struct r5conf *con
while (bi && bi->bi_iter.bi_sector <
sh->dev[i].sector + STRIPE_SECTORS) {
struct bio *nextbi = r5_next_bio(bi, sh->dev[i].sector);
- clear_bit(BIO_UPTODATE, >bi_flags);
+
+ bi->bi_error = -EIO;
if (!raid5_dec_bi_active_stripes(bi)) {
md_write_end(conf->mddev);
- bi->bi_next = *return_bi;
- *return_bi = bi;
+ bio_list_add(return_bi, bi);
}
bi = nextbi;
}
@@@ -3135,12 -3130,10 +3129,11 @@@
while (bi && bi->bi_iter.bi_sector <
sh->dev[i].sector + STRIPE_SECTORS) {
struct bio *bi2 = r5_next_bio(bi, sh->dev[i].sector);
- clear_bit(BIO_UPTODATE, >bi_flags);
+
+ bi->bi_error = -EIO;
if (!raid5_dec_bi_active_stripes(bi)) {
md_write_end(conf->mddev);
- bi->bi_next = *return_bi;
- *return_bi = bi;
+ bio_list_add(return_bi, bi);
}
bi = bi2;
}
@@@ -3161,12 -3154,9 +3154,10 @@@
sh->dev[i].sector + STRIPE_SECTORS) {
struct bio *nextbi =
r5_next_bio(bi, sh->dev[i].sector);
- clear_bit(BIO_UPTODATE, >bi_flags);
+
+ bi->bi_error = -EIO;
- if (!raid5_dec_bi_active_stripes(bi)) {
- bi->bi_next = *return_bi;
- *return_bi = bi;
- }
+ if (!raid5_dec_bi_active_stripes(bi))
+ bio_list_add(return_bi, bi);
bi = nextbi;
}
}
@@@ -4670,14 -4667,43 +4668,14 @@@ static int raid5_congested(struct mdde
return 0;
}
-/* We want read requests to align with chunks where possible,
- * but write requests don't need to.
- */
-static int raid5_mergeable_bvec(struct mddev *mddev,
- struct bvec_merge_data *bvm,
- struct bio_vec *biovec)
-{
- struct r5conf *conf = mddev->private;
- sector_t sector = bvm->bi_sector + get_start_sect(bvm->bi_bdev);
- int max;
- unsigned int chunk_sectors;
- unsigned int bio_sectors = bvm->bi_size >> 9;
-
- /*
- * always allow writes to be mergeable, read as well if array
- * is degraded as we'll go through stripe cache anyway.
- */
- if ((bvm->bi_rw & 1) == WRITE || mddev->degraded)
- return biovec->bv_len;
-
- chunk_sectors = min(conf->chunk_sectors, conf->prev_chunk_sectors);
- max = (chunk_sectors - ((sector & (chunk_sectors - 1)) + bio_sectors))
<< 9;
- if (max < 0) max = 0;
- if (max <= biovec->bv_len && bio_sectors == 0)
- return biovec->bv_len;
- else
- return max;
-}
-
static int in_chunk_boundary(struct mddev *mddev, struct bio *bio)
{
+ struct r5conf *conf = mddev->private;
sector_t sector = bio->bi_iter.bi_sector + get_start_sect(bio->bi_bdev);
- unsigned int chunk_sectors = mddev->chunk_sectors;
+ unsigned int chunk_sectors;
unsigned int bio_sectors = bio_sectors(bio);
- if (mddev->new_chunk_sectors < mddev->chunk_sectors)
-
linux-next: manual merge of the md tree with the block tree
Hi Neil,
Today's linux-next merge of the md tree got a conflict in:
drivers/md/raid10.c
between commit:
4246a0b63bd8 ("block: add a bi_error field to struct bio")
from the block tree and commit:
90421c7cfde6 ("md/raid10: ensure device failure recorded before write request
returns.")
from the md tree.
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 drivers/md/raid10.c
index b0fce2ebf7ad,a14c304aa751..
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@@ -2633,7 -2750,9 +2635,8 @@@ static void handle_write_completed(stru
r10_bio->devs[m].addr,
r10_bio->sectors, 0);
rdev_dec_pending(rdev, conf->mddev);
- } else if (bio != NULL &&
- !test_bit(BIO_UPTODATE, >bi_flags)) {
+ } else if (bio != NULL && bio->bi_error) {
+ fail = true;
if (!narrow_write_error(r10_bio, m)) {
md_error(conf->mddev, rdev);
set_bit(R10BIO_Degraded,
--
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 md tree with the block tree
Hi Neil,
Today's linux-next merge of the md tree got a conflict in:
drivers/md/raid0.c
between commit:
8ae126660fdd ("block: kill merge_bvec_fn() completely")
from the block tree and commit:
927d881980b7 ("md/raid0: update queue parameter in a safer location.")
from the md tree.
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 drivers/md/raid0.c
index 59cda501a224,4a13c3cb940b..
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@@ -188,10 -203,9 +203,6 @@@ static int create_strip_zones(struct md
}
dev[j] = rdev1;
- if (mddev->queue)
- disk_stack_limits(mddev->gendisk, rdev1->bdev,
- rdev1->data_offset << 9);
- if (rdev1->bdev->bd_disk->queue->merge_bvec_fn)
- conf->has_merge_bvec = 1;
--
if (!smallest || (rdev1->sectors < smallest->sectors))
smallest = rdev1;
cnt++;
--
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: [BUG/RFC] perf test fails on AMD CPUs
On Mon, Aug 17, 2015 at 12:29:56AM +0200, Jiri Olsa wrote: > hi, > 'perf test 18' is failing on systems with AMD processor. Hmm, still using that b0rked test box? :-) Also, which kernel? There have been substantial changes to the entry code recently. Although I don't see anything being done differently on AMD there except X86_BUG_SYSRET_SS_ATTRS but that should be unrelated. > The only reason I could find is that AMD does not set 'resume flag' > in RFLAGS register the way the Intel CPU does. > > (simplified) test scenario: > > - create breakpoint (on test_function) perf event with SIGIO signal > to be delivered any time the breakpoint is hit > - run test_function > > > expected course of actions is: > 1) CPU hits 'test_function' > 2) DB exception is triggered, with RFLAGS.RF=0 > 3) DB exception handler sets regs->RFLAGS.RF=1 and perf handler > triggers irq_work pending work > 4) DB exception executes iretd > 5) irq_work interrupt is triggered, with RFLAGS.RF=1 > 6) irq_work interrupt calls kill_fasync with SIGIO signal > 7) irq_work interrupt on return to userspace calls prepare_exit_to_usermode > which actually delivers the SIGIO signal > 8) sigreturn syscall prepare registers to return to the > instruction from step 1) and sets RFLAGS.RF to the its original > value from step 5) (RFLAGS.RF=1) > 9) CPU hits 'test_function' and DB exception is NOT triggered > due to RFLAGS.RF=1 > > this is how I see it works on Intel > > But AMD gives me RFLAGS.RF=0 on step 5, which makes the step 9 to > trigger the DB exception once again and makes the test fail. Adding Andy, he might have an idea. Leaving in the rest for reference. > I'm not sure this test ever worked on AMD CPUs, anyway is there > anything I'm missing or is this some AMD/Intel quirk? > > thanks, > jirka > > > > AMD description of RF flag (SDM 3.1.6): > === > Resume Flag (RF) Bit. Bit 16. The RF bit allows an instruction to be > restarted following an > instruction breakpoint resulting in a debug exception (#DB). This bit > prevents multiple debug > exceptions from occurring on the same instruction. > The processor clears the RF bit after every instruction is successfully > executed, except when the > instruction is: > • > • > An IRET that sets the RF bit. > JMP, CALL, or INTn through a task gate. > In both of the above cases, RF is not cleared to 0 until the next instruction > successfully executes. > When an exception occurs (or when a string instruction is interrupted), the > processor normally sets > RF=1 in the RFLAGS image saved on the interrupt stack. However, when a #DB > exception occurs as a > result of an instruction breakpoint, the processor clears the RF bit to 0 in > the interrupt-stack RFLAGS > image. > For instruction restart to work properly following an instruction breakpoint, > the #DB exception > handler must set RF to 1 in the interrupt-stack RFLAGS image. When an IRET is > later executed to > return to the instruction that caused the instruction-breakpoint #DB > exception, the set RF bit (RF=1) is > loaded from the interrupt-stack RFLAGS image. RF is not cleared by the > processor until the > instruction causing the #DB exception successfully executes. > > Intel description of RF flag (SDM 17.3.1.1): > > Because the debug exception for an instruction breakpoint is generated before > the instruction is executed, if the > instruction breakpoint is not removed by the exception handler; the processor > will detect the instruction breakpoint > again when the instruction is restarted and generate another debug exception. > To prevent looping on an instruction > breakpoint, the Intel 64 and IA-32 architectures provide the RF flag (resume > flag) in the EFLAGS register (see > Section 2.3, “System Flags and Fields in the EFLAGS Register,” in the Intel® > 64 and IA-32 Architectures Software > Developer’s Manual, Volume 3A). When the RF flag is set, the processor > ignores instruction breakpoints. > All Intel 64 and IA-32 processors manage the RF flag as follows. The RF Flag > is cleared at the start of the instruction > after the check for code breakpoint, CS limit violation and FP exceptions. > Task Switches and IRETD/IRETQ instruc- > tions transfer the RF image from the TSS/stack to the EFLAGS register. > When calling an event handler, Intel 64 and IA-32 processors establish the > value of the RF flag in the EFLAGS image > pushed on the stack: > • For any fault-class exception except a debug exception generated in > response to an instruction breakpoint, the > value pushed for RF is 1. > • For any interrupt arriving after any iteration of a repeated string > instruction but the last iteration, the value > pushed for RF is 1. > • For any trap-class exception generated by any iteration of a repeated > string instruction but the last iteration, > the value pushed for RF is
[PATCH v2 3/3] mm/hwpoison: don't try to unpoison containment-failed pages
memory_failure() can be called at any page at any time, which means that we
can't eliminate the possibility of containment failure. In such case the best
option is to leak the page intentionally (and never touch it later.)
We have an unpoison function for testing, and it cannot handle such
containment-failed pages, which results in kernel panic (visible with various
calltraces.) So this patch suggests that we limit the unpoisonable pages to
properly contained pages and ignore any other ones.
Testers are recommended to keep in mind that there're un-unpoisonable pages
when writing test programs.
Signed-off-by: Naoya Horiguchi
---
mm/memory-failure.c | 16
1 file changed, 16 insertions(+)
diff --git mmotm-2015-08-13-15-29.orig/mm/memory-failure.c
mmotm-2015-08-13-15-29/mm/memory-failure.c
index 7986db56e240..613389e9e5a8 100644
--- mmotm-2015-08-13-15-29.orig/mm/memory-failure.c
+++ mmotm-2015-08-13-15-29/mm/memory-failure.c
@@ -1433,6 +1433,22 @@ int unpoison_memory(unsigned long pfn)
return 0;
}
+ if (page_count(page) > 1) {
+ pr_info("MCE: Someone grabs the hwpoison page %#lx\n", pfn);
+ return 0;
+ }
+
+ if (page_mapped(page)) {
+ pr_info("MCE: Someone maps the hwpoison page %#lx\n", pfn);
+ return 0;
+ }
+
+ if (page_mapping(page)) {
+ pr_info("MCE: the hwpoison page has non-NULL mapping %#lx\n",
+ pfn);
+ return 0;
+ }
+
/*
* unpoison_memory() can encounter thp only when the thp is being
* worked by memory_failure() and the page lock is not held yet.
--
2.4.3
--
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 1/3] mm/hwpoison: introduce num_poisoned_pages wrappers
num_poisoned_pages counter will be changed outside mm/memory-failure.c by a
subsequent patch, so this patch prepares wrappers to manipulate it.
Signed-off-by: Naoya Horiguchi
---
include/linux/swapops.h | 23 +++
mm/memory-failure.c | 30 ++
2 files changed, 37 insertions(+), 16 deletions(-)
diff --git mmotm-2015-08-13-15-29.orig/include/linux/swapops.h
mmotm-2015-08-13-15-29/include/linux/swapops.h
index cedf3d3c373f..ec04669f2a3b 100644
--- mmotm-2015-08-13-15-29.orig/include/linux/swapops.h
+++ mmotm-2015-08-13-15-29/include/linux/swapops.h
@@ -164,6 +164,9 @@ static inline int is_write_migration_entry(swp_entry_t
entry)
#endif
#ifdef CONFIG_MEMORY_FAILURE
+
+extern atomic_long_t num_poisoned_pages __read_mostly;
+
/*
* Support for hardware poisoned pages
*/
@@ -177,6 +180,26 @@ static inline int is_hwpoison_entry(swp_entry_t entry)
{
return swp_type(entry) == SWP_HWPOISON;
}
+
+static inline void num_poisoned_pages_inc(void)
+{
+ atomic_long_inc(_poisoned_pages);
+}
+
+static inline void num_poisoned_pages_dec(void)
+{
+ atomic_long_dec(_poisoned_pages);
+}
+
+static inline void num_poisoned_pages_add(long num)
+{
+ atomic_long_add(num, _poisoned_pages);
+}
+
+static inline void num_poisoned_pages_sub(long num)
+{
+ atomic_long_sub(num, _poisoned_pages);
+}
#else
static inline swp_entry_t make_hwpoison_entry(struct page *page)
diff --git mmotm-2015-08-13-15-29.orig/mm/memory-failure.c
mmotm-2015-08-13-15-29/mm/memory-failure.c
index a3d9c3946b36..ac3056c6fe9f 100644
--- mmotm-2015-08-13-15-29.orig/mm/memory-failure.c
+++ mmotm-2015-08-13-15-29/mm/memory-failure.c
@@ -1109,7 +1109,7 @@ int memory_failure(unsigned long pfn, int trapno, int
flags)
nr_pages = 1 << compound_order(hpage);
else /* normal page or thp */
nr_pages = 1;
- atomic_long_add(nr_pages, _poisoned_pages);
+ num_poisoned_pages_add(nr_pages);
/*
* We need/can do nothing about count=0 pages.
@@ -1137,7 +1137,7 @@ int memory_failure(unsigned long pfn, int trapno, int
flags)
if (PageHWPoison(hpage)) {
if ((hwpoison_filter(p) &&
TestClearPageHWPoison(p))
|| (p != hpage &&
TestSetPageHWPoison(hpage))) {
- atomic_long_sub(nr_pages,
_poisoned_pages);
+ num_poisoned_pages_sub(nr_pages);
unlock_page(hpage);
return 0;
}
@@ -1161,7 +1161,7 @@ int memory_failure(unsigned long pfn, int trapno, int
flags)
else
pr_err("MCE: %#lx: thp split failed\n", pfn);
if (TestClearPageHWPoison(p))
- atomic_long_sub(nr_pages, _poisoned_pages);
+ num_poisoned_pages_sub(nr_pages);
put_hwpoison_page(p);
return -EBUSY;
}
@@ -1221,14 +1221,14 @@ int memory_failure(unsigned long pfn, int trapno, int
flags)
*/
if (!PageHWPoison(p)) {
printk(KERN_ERR "MCE %#lx: just unpoisoned\n", pfn);
- atomic_long_sub(nr_pages, _poisoned_pages);
+ num_poisoned_pages_sub(nr_pages);
unlock_page(hpage);
put_hwpoison_page(hpage);
return 0;
}
if (hwpoison_filter(p)) {
if (TestClearPageHWPoison(p))
- atomic_long_sub(nr_pages, _poisoned_pages);
+ num_poisoned_pages_sub(nr_pages);
unlock_page(hpage);
put_hwpoison_page(hpage);
return 0;
@@ -1457,7 +1457,7 @@ int unpoison_memory(unsigned long pfn)
return 0;
}
if (TestClearPageHWPoison(p))
- atomic_long_dec(_poisoned_pages);
+ num_poisoned_pages_dec();
pr_info("MCE: Software-unpoisoned free page %#lx\n", pfn);
return 0;
}
@@ -1471,7 +1471,7 @@ int unpoison_memory(unsigned long pfn)
*/
if (TestClearPageHWPoison(page)) {
pr_info("MCE: Software-unpoisoned page %#lx\n", pfn);
- atomic_long_sub(nr_pages, _poisoned_pages);
+ num_poisoned_pages_sub(nr_pages);
freeit = 1;
if (PageHuge(page))
clear_page_hwpoison_huge_page(page);
@@ -1607,11 +1607,10 @@ static int soft_offline_huge_page(struct page *page,
int flags)
if (PageHuge(page)) {
set_page_hwpoison_huge_page(hpage);
dequeue_hwpoisoned_huge_page(hpage);
- atomic_long_add(1 <<
[PATCH v2 2/3] mm/hwpoison: fix race between soft_offline_page and unpoison_memory
From: Wanpeng Li
Wanpeng Li reported a race between soft_offline_page() and unpoison_memory(),
which causes the following kernel panic:
[ 61.572584] BUG: Bad page state in process bash pfn:97000
[ 61.578106] page:ea00025c count:0 mapcount:1 mapping:
(null) index:0x7f4fdbe00
[ 61.586803] flags: 0x1f80080048(uptodate|active|swapbacked)
[ 61.592809] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
[ 61.599250] bad because of flags:
[ 61.602567] flags: 0x40(active)
[ 61.605746] Modules linked in: snd_hda_codec_hdmi i915 rpcsec_gss_krb5
nfsv4 dns_resolver bnep rfcomm nfsd bluetooth auth_rpcgss nfs_acl nfs rfkill
lockd grace sunrpc i2c_algo_bit drm_kms_helper snd_hda_codec_realtek
snd_hda_codec_generic drm snd_hda_intel fscache snd_hda_codec
x86_pkg_temp_thermal coretemp kvm_intel snd_hda_core snd_hwdep kvm snd_pcm
snd_seq_dummy snd_seq_oss crct10dif_pclmul snd_seq_midi crc32_pclmul
snd_seq_midi_event ghash_clmulni_intel snd_rawmidi aesni_intel lrw gf128mul
snd_seq glue_helper ablk_helper snd_seq_device cryptd fuse snd_timer dcdbas
serio_raw mei_me parport_pc snd mei ppdev i2c_core video lp soundcore parport
lpc_ich shpchp mfd_core ext4 mbcache jbd2 sd_mod e1000e ahci ptp libahci
crc32c_intel libata pps_core
[ 61.605827] CPU: 3 PID: 2211 Comm: bash Not tainted 4.2.0-rc5-mm1+ #45
[ 61.605829] Hardware name: Dell Inc. OptiPlex 7020/0F5C5X, BIOS A03
01/08/2015
[ 61.605832] 818b3be8 8800da373ad8 8165ceb4
01313ce1
[ 61.605837] ea00025c 8800da373b08 8117bdd6
88021edd4b00
[ 61.605842] 0001 001f80080048
8800da373b88
[ 61.605847] Call Trace:
[ 61.605858] [] dump_stack+0x48/0x5c
[ 61.605865] [] bad_page+0xe6/0x140
[ 61.605870] [] free_pages_prepare+0x2f9/0x320
[ 61.605876] [] ? uncharge_list+0xdd/0x100
[ 61.605882] [] free_hot_cold_page+0x40/0x170
[ 61.605888] [] __put_single_page+0x20/0x30
[ 61.605892] [] put_page+0x25/0x40
[ 61.605897] [] unmap_and_move+0x1a6/0x1f0
[ 61.605908] [] migrate_pages+0x100/0x1d0
[ 61.605914] [] ? kill_procs+0x100/0x100
[ 61.605918] [] ? unlock_page+0x6f/0x90
[ 61.605923] [] __soft_offline_page+0x127/0x2a0
[ 61.605928] [] soft_offline_page+0xa6/0x200
This race is explained like below:
CPU0CPU1
soft_offline_page
__soft_offline_page
TestSetPageHWPoison
unpoison_memory
PageHWPoison check (true)
TestClearPageHWPoison
put_page-> release refcount held by
get_hwpoison_page in unpoison_memory
put_page-> release refcount held by
isolate_lru_page in __soft_offline_page
migrate_pages
The second put_page() releases refcount held by isolate_lru_page() which
will lead to unmap_and_move() releases the last refcount of page and w/
mapcount still 1 since try_to_unmap() is not called if there is only
one user map the page. Anyway, the page refcount and mapcount will
still mess if the page is mapped by multiple users.
This race was introduced by commit 4491f71260 ("mm/memory-failure: set
PageHWPoison before migrate_pages()"), which focuses on preventing the reuse
of successfully migrated page. Before this commit we prevent the reuse by
changing the migratetype to MIGRATE_ISOLATE during soft offlining, which has
the following problems, so simply reverting the commit is not a best option:
1) it doesn't eliminate the reuse completely, because
set_migratetype_isolate()
can fail to set MIGRATE_ISOLATE to the target page if the pageblock of
the page contains one or more unmovable pages (i.e. has_unmovable_pages()
returns true).
2) the original code changes migratetype to MIGRATE_ISOLATE forcibly,
and sets it to MIGRATE_MOVABLE forcibly after soft offline, regardless
of the original migratetype state, which could impact other subsystems
like memory hotplug or compaction.
This patch moves PageSetHWPoison just after put_page() in unmap_and_move(),
which closes up the reported race window and minimizes another race window b/w
SetPageHWPoison and reallocation (which causes the reuse of soft-offlined page.)
The latter race window still exists but it's acceptable, because it's rare and
effectively the same as ordinary "containment failure" case even if it happens,
so keep the window open is acceptable.
Fixes: 4491f71260 ("mm/memory-failure: set PageHWPoison before migrate_pages()")
Reported-by: Wanpeng Li
Signed-off-by: Wanpeng Li
Signed-off-by: Naoya Horiguchi
---
include/linux/swapops.h | 14 ++
mm/memory-failure.c | 4
mm/migrate.c| 9 +
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git mmotm-2015-08-13-15-29.orig/include/linux/swapops.h
mmotm-2015-08-13-15-29/include/linux/swapops.h
index
Re: [PATCH] mm/hwpoison: fix race between soft_offline_page and unpoison_memory
On Fri, Aug 14, 2015 at 05:01:34PM +0800, Wanpeng Li wrote: > On 8/14/15 4:38 PM, Naoya Horiguchi wrote: > > On Fri, Aug 14, 2015 at 03:59:21PM +0800, Wanpeng Li wrote: > >> On 8/14/15 3:54 PM, Wanpeng Li wrote: > >>> [...] > OK, then I rethink of handling the race in unpoison_memory(). > > Currently properly contained/hwpoisoned pages should have page refcount 1 > (when the memory error hits LRU pages or hugetlb pages) or refcount 0 > (when the memory error hits the buddy page.) And current > unpoison_memory() > implicitly assumes this because otherwise the unpoisoned page has no > place > to go and it's just leaked. > So to avoid the kernel panic, adding prechecks of refcount and mapcount > to limit the page to unpoison for only unpoisonable pages looks OK to me. > The page under soft offlining always has refcount >=2 and/or mapcount > > 0, > so such pages should be filtered out. > > Here's a patch. In my testing (run soft offline stress testing then > repeat > unpoisoning in background,) the reported (or similar) bug doesn't happen. > Can I have your comments? > >>> As page_action() prints out page maybe still referenced by some users, > >>> however, PageHWPoison has already set. So you will leak many poison pages. > >>> > >> Anyway, the bug is still there. > >> > >> [ 944.387559] BUG: Bad page state in process expr pfn:591e3 > >> [ 944.393053] page:ea00016478c0 count:-1 mapcount:0 mapping: > >> (null) index:0x2 > >> [ 944.401147] flags: 0x1f8000() > >> [ 944.404819] page dumped because: nonzero _count > > Hmm, no luck :( > > > > To investigate more, I'd like to test the exactly same kernel as yours, so > > could you share the kernel info (.config and base kernel and what patches > > you applied)? or pushing your tree somewhere like github? > > # if you like, sending to me privately is fine. > > > > I think that I tested v4.2-rc6 + + > > "mm/hwpoison: fix race between soft_offline_page and unpoison_memory", > > but I experienced some conflict in applying your patches for some reason, > > so it might happen that we are testing on different kernels. > > I don't have special config and tree, the latest mmotm has already > merged my recent 8 hwpoison patches, you can test based on it. OK, so I wrote the next version against mmotm-2015-08-13-15-29 (replied to this email.) It moves PageSetHWPoison part into migration code, which should close up the reported race window and minimize the another revived race window of reusing offlined pages, so I feel that it's a good compromise between two races. My testing shows no kernel panic with these patches (same testing easily caused panics for bare mmotm-2015-08-13-15-29,) so they should work. But I'm appreciated if you help double checking. Thanks, Naoya Horiguchi-- 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 v6] arm64: dts: Add spi bus dts
On Mon, Aug 17, 2015 at 11:29 AM, Leilk Liu wrote:
>
> This patch adds MT8173 spi bus controllers into device tree.
>
> Signed-off-by: Leilk Liu
Reviewed-by: Daniel Kurtz
> ---
> Change in this patch:
> pinctl and pad-select fields are board specific, so move to
> mt8173-evb.dtsi, and status = "okay".
> ---
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi| 12
> 2 files changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index 4be66ca..811cb76 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -387,6 +387,24 @@
> };
> };
>
> + {
> + spi_pins_a: spi0 {
> + pins_spi {
> + pinmux = ,
> + ,
> + ,
> + ;
> + };
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + mediatek,pad-select = <0>;
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index d18ee42..3dfb6ed 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -365,6 +365,18 @@
> status = "disabled";
> };
>
> + spi: spi@1100a000 {
> + compatible = "mediatek,mt8173-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0 0x1100a000 0 0x1000>;
> + interrupts = ;
> + clocks = < CLK_TOP_SPI_SEL>,
> +< CLK_TOP_SYSPLL3_D2>;
> + clock-names = "spi-clk", "parent-clk";
> + status = "disabled";
> + };
> +
> i2c3: i2c3@1101 {
> compatible = "mediatek,mt8173-i2c";
> reg = <0 0x1101 0 0x70>,
> --
> 1.8.1.1.dirty
>
> --
> 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/
--
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/
Announcing simple-pt -- a simple Processor Trace implementation for Linux
Modern Intel Core CPUs (5th and 6th generation) have a Intel Processor Trace (PT) feature to trace branch execution with low overhead. This is useful for performance analysis and debugging. simple-pt is a simple standalone driver and decoder tool to implement PT on Linux. Starting with Linux 4.1 Linux has an integrated PT implementation in perf (see https://lwn.net/Articles/648154/). simple-pt is an alternative implementation. It has many disadvantages over the perf PT implementation, such as: - needs to run as root - no long term tracing or sampling with interrupts - no support for interactive debugging (use gdb 7.10 on perf for that) - no support for histograms - somewhat experimental - not as well supported as perf On the positive side simple-pt is: - simple - standalone. No kernel changes needed. Could be ported to older kernels or other operating systems - easy to modify and experiment with - more ftrace like decoding tool - support for kprobes based triggers - modular “unix style” design with simple tools that do only one thing each - BSD licensed Example output: % sptcmd -c tcall taskset -c 0 ./tcall cpu 0 offset 1027688, 1003 KB, writing to ptout.0 ... Wrote sideband to ptout.sideband % sptdecode --sideband ptout.sideband --pt ptout.0 | less TIME DELTA INSNs OPERATION frequency 32 0[+0] [+ 1] _dl_aux_init+436 [+ 6] __libc_start_main+455 -> _dl_discover_osversion ... [+ 13] __libc_start_main+446 -> main [+ 9] main+22 -> f1 [+ 4] f1+9 -> f2 [+ 2] f1+19 -> f2 [+ 5] main+22 -> f1 [+ 4] f1+9 -> f2 [+ 2] f1+19 -> f2 [+ 5] main+22 -> f1 ... Available from https://github.com/andikleen/simple-pt -- a...@linux.intel.com -- Speaking for myself only. -- 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 / Domains: Make pm_genpd_init() available to modules
On 08/13/2015 11:41 PM, Stephen Boyd wrote: On 08/13, Rajendra Nayak wrote: Export symbol pm_genpd_init so it can be used in loadable kernel modules Signed-off-by: Rajendra Nayak Reported-by: Stephen Rothwell --- I'd like to take this through the clk tree somehow so that we can merge the rest of the GDSC series this coming cycle. Ulf/Rafael, if you don't have any issues with the patch, and are fine with Stephen taking this through the clk tree, would you be able to ack this please? thanks. regards, Rajendra -- 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] copy_from{to}_user question
On Mon, Aug 17, 2015 at 11:27:01AM +0800, yalin wang wrote:
> i just want the x86 copy_from{to,in}_user() function have
> the same behaviour as other platforms.
Back to the original question from 2 mails ago:
How else would we be able to use the same function in copy_to and
copy_from variants?
> and can disclose potential BUGs in kernel, if do like this.
Back to my other question:
Do you have any real life examples where you can trigger such bugs or is
this only "potential"?
IOW, what I *think* you're trying to do sounds to me like unnecessary
complication with no apparent gain *at* *all*. So show me why you want
to do it: code it up, trigger a bug and show me why your version is
better. No "but but it might be a good idea", no "potentially maybe",
none of that maybe stuff. Write it, send it with instructions how
someone else can apply it and trigger the issue. Ok?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
--
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][v2] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment property
Add snps,quirk-frame-length-adjustment property which provides value for post silicon frame length adjustment Signed-off-by: Nikhil Badola --- Changes for v2 - changed quirk name as well description Documentation/devicetree/bindings/usb/dwc3.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 0815eac..8c7d585 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -40,6 +40,9 @@ Optional properties: - snps,hird-threshold: HIRD threshold - snps,hsphy_interface: High-Speed PHY interface selection between "utmi" for UTMI+ and "ulpi" for ULPI when the DWC_USB3_HSPHY_INTERFACE has value 3. + - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ + register for post-silicon frame length adjustment when the + fladj_30mhz_sdbnd signal is invalid or incorrect. This is usually a subnode to DWC3 glue to which it is connected. -- 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: [PATCH v2 1/4] scripts/kernel-doc: Adding cross-reference links to html documentation.
On Tue, 28 Jul 2015 16:45:15 -0300 Danilo Cesar Lemes de Paula wrote: > Functions, Structs and Parameters definitions on kernel documentation > are pure cosmetic, it only highlights the element. > > To ease the navigation in the documentation we should use inside > those tags so readers can easily jump between methods directly. > > This was discussed in 2014[1] and is implemented by getting a list > of from the DocBook XML to generate a database. Then it looks > for , and tags that matches the ones in > the database. As it only links existent references, no broken links are > added. So I had some airplane time today and was able to mess with this some. I can't make it break anymore, and it clearly improves the resulting documentation, so I've applied it to the docs tree for 4.3. I want to look at the rest of the stuff a bit more and play with it, but it's hard to imagine why we wouldn't want that as well. I'm a bit more leery just because it adds another dependency to the build, even if it's an optional dependency. My thinking at the moment is to apply it shortly after the merge window so it can have a long soak in linux-next before a 4.4 merge; hope that sounds good. Thanks for doing this work, jon -- 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 v2] memory-barriers: remove smp_mb__after_unlock_lock()
On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote: > On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote: > > Hello Paul, > > > > On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote: > > > On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote: > > > > On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote: > > > > > > > commit 695c05d4b9666c50b40a1c022678b5f6e2e3e771 > > > > > > > Author: Paul E. McKenney > > > > > > > Date: Tue Jul 14 18:35:23 2015 -0700 > > > > > > > > > > > > > > rcu,locking: Privatize smp_mb__after_unlock_lock() > > > > > > > > > > > > > > RCU is the only thing that uses smp_mb__after_unlock_lock(), > > > > > > > and is > > > > > > > likely the only thing that ever will use it, so this commit > > > > > > > makes this > > > > > > > macro private to RCU. > > > > > > > > > > > > > > Signed-off-by: Paul E. McKenney > > > > > > > Cc: Will Deacon > > > > > > > Cc: Peter Zijlstra > > > > > > > Cc: Benjamin Herrenschmidt > > > > > > > Cc: "linux-a...@vger.kernel.org" > > > > > > > > Are you planning to queue this somewhere? I think it makes sense > > > > regardless > > > > of whether we change PowerPc or not and ideally it would be merged > > > > around > > > > the same time as my relaxed atomics series. > > > > > > I have is in -rcu. By default, I will push it to the 4.4 merge window. > > > Please let me know if you need it sooner. > > > > The generic relaxed atomics are now queued in -tip, so it would be really > > good to see this Documentation update land in 4.3 if at all possible. I > > appreciate it's late in the cycle, but it's always worth asking. > > Can't hurt to give it a try. I have set -rcu's rcu/next branch to this > commit, and if it passes a few day's worth of testing, I will see what > Ingo has to say about a pull request. > > This commit also privatizes smp_mb__after_unlock_lock() as well as > updating documentation. Looks like we need to strengthen powerpc's > locking primitives, then get rid of smp_mb__after_unlock_lock() entirely. > Or did that already happen and I just missed it? No it didn't. I thought the end result of this thread was that we didn't *need* to change the powerpc lock semantics? Or did I read it wrong? ie. the docs now say that RELEASE+ACQUIRE is not a full barrier, which is consistent with our current implementation. cheers -- 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 block tree with Linus' tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
drivers/md/dm.c
between commit:
bd4aaf8f9b85 ("dm: fix dm_merge_bvec regression on 32 bit systems")
from Linus' tree and commit:
8ae126660fdd ("block: kill merge_bvec_fn() completely")
from the block tree.
I fixed it up (the latter removed the code updated by the former) and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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/3][v2] arm: dts: ls1021a: Add quirk for Erratum A009116
Add "snps,quirk-frame-length-adjustment" property to USB3 node for erratum A009116. This property provides value of GFLADJ_30MHZ for post silicon frame length adjustment. Signed-off-by: Nikhil Badola --- Changes for v2 : - updated property name arch/arm/boot/dts/ls1021a.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi index c70bb27..50ac0d4 100644 --- a/arch/arm/boot/dts/ls1021a.dtsi +++ b/arch/arm/boot/dts/ls1021a.dtsi @@ -404,6 +404,7 @@ reg = <0x0 0x310 0x0 0x1>; interrupts = ; dr_mode = "host"; + snps,quirk-frame-length-adjustment = <0x20>; }; }; }; -- 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: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support
On Sat, Aug 15, 2015 at 7:48 AM, pku.leo < pku@gmail.com > wrote: > On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan wrote: > > Hi Leo, > > > > Thanks for your review. > > About those two methods for DMA suspend that you have mentioned. We > have a lot of the discussions in other DMA driver like DMA for Freescale > PowerPC. > > > > Finally, we think the device which used the DMA transmission service should > cancel the transmission service in its suspend. > > So DMA in suspend should be idle. > > If that's the case you should clearly state this in the commit message and in > code, although I don't know if it is safe to make such assumption. There > could > be user of the DMA that doesn't track the completion of transfers. I think it should be safe. In my opinion, even some client(the user of the DMA) forget to cancel its DMA transmission, It will just lead to PM failed but no other system and data risk. Although we should first fix the behavior of the client. Once you are no need the DMA transmission, why not stop it? Is it right? > > > > Once the DMA in late_suspend is not be idle, we think some driver haven't > canceled the DMA transmission. So maybe something is error when other > driver in suspend. > > > > In the case, we should return failed to stop PM. DMA should not make a > choice for other drivers(which used DMA) to force stop DMA transmission. > > The suspend entrance should be terminated by wakeup events and only critical > issues. I don't think we should just terminate the suspend entrance just > because having on-going I/O without even try to stop it. The graceful behavior would be to for client to PAUSE or terminate and then suspend followed by DMA suspend. We need to rely on client doing the right thing here. The DMA should not make a decision instead of client. If the DMA is not idle in DMA suspend, it should be the client's issue. We don't know what the client really want to do, so just return the non-success value. I'm not sure my description is clear. So we may refer the discussion about the DMA PM support before. Such as "DMA: Freescale: add suspend resume functions for DMA driver" Like:https://lkml.org/lkml/2014/5/21/1 > > > > Thanks. > > > > Best Regards, > > Yuan Yao > > > >> -Original Message- > >> From: pku@gmail.com [mailto:pku@gmail.com] On Behalf Of Li > >> Yang > >> Sent: Friday, August 14, 2015 4:58 AM > >> To: Yuan Yao-B46683 > >> Cc: Vinod Koul; ste...@agner.ch; Arnd Bergmann; Dan Williams; > >> dmaeng...@vger.kernel.org; lkml; > >> linux-arm-ker...@lists.infradead.org; linux- p...@vger.kernel.org > >> Subject: Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume > >> support > >> > >> On Tue, Jul 21, 2015 at 3:56 AM, Yuan Yao wrote: > >> > This add power management suspend/resume support for the fsl-edma > >> > driver. > >> > > >> > eDMA acted as a basic function used by others. What it needs to do > >> > is the two steps below to support power management. > >> > > >> > In fsl_edma_suspend_late: > >> > Check whether the DMA chan is idle and if it is not idle, stop PM > >> > operation. > >> > >> You should try to quiesce the device on suspend instead of depending > >> on itself to be happen in idle and failing if it is not. > >> > >> Regards, > >> Leo > > > > -- > - Leo
[PATCH 2/3][v2] drivers: usb: dwc3: Add frame length adjustment quirk
Add adjust_frame_length_quirk for writing to fladj register
which adjusts (micro)frame length to value provided by
"snps,quirk-frame-length-adjustment" property thus avoiding
USB 2.0 devices to time-out over a longer run
Signed-off-by: Nikhil Badola
---
changes for v2 :
- updated quirk's name
- added separate function for frame length adjustment
- added frame length adjustment for pdata users
- removed unnecessary flag from struct dwc3
drivers/usb/dwc3/core.c | 37 +
drivers/usb/dwc3/core.h | 5 +
drivers/usb/dwc3/platform_data.h | 2 ++
3 files changed, 44 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 064123e..f3beb2e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -143,6 +143,34 @@ static int dwc3_soft_reset(struct dwc3 *dwc)
return 0;
}
+/*
+ * dwc3_frame_length_adjustment - Adjusts frame length if required
+ * @dwc3: Pointer to our controller context structure
+ * @fladj: Value of GFLADJ_30MHZ to adjust frame length
+ */
+static void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj)
+{
+ if (dwc->revision < DWC3_REVISION_250A)
+ return;
+
+ if (fladj == 0)
+ return;
+
+ if (fladj) {
+ u32 reg;
+ u32 dft;
+
+ reg = dwc3_readl(dwc->regs, DWC3_GFLADJ);
+ dft = reg & DWC3_GFLADJ_30MHZ_MASK;
+ if (!dev_WARN_ONCE(dwc->dev, dft == fladj,
+ "request value same as default, ignoring\n")) {
+ reg &= ~DWC3_GFLADJ_30MHZ_MASK;
+ reg |= DWC3_GFLADJ_30MHZ_SDBND_SEL | fladj;
+ dwc3_writel(dwc->regs, DWC3_GFLADJ, reg);
+ }
+ }
+}
+
/**
* dwc3_free_one_event_buffer - Frees one event buffer
* @dwc: Pointer to our controller context structure
@@ -779,6 +807,7 @@ static int dwc3_probe(struct platform_device *pdev)
u8 lpm_nyet_threshold;
u8 tx_de_emphasis;
u8 hird_threshold;
+ u32 fladj = 0;
int ret;
@@ -886,6 +915,9 @@ static int dwc3_probe(struct platform_device *pdev)
_de_emphasis);
of_property_read_string(node, "snps,hsphy_interface",
>hsphy_interface);
+ of_property_read_u32(node,
+"snps,quirk-frame-length-adjustment",
+);
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
dwc->has_lpm_erratum = pdata->has_lpm_erratum;
@@ -915,6 +947,7 @@ static int dwc3_probe(struct platform_device *pdev)
tx_de_emphasis = pdata->tx_de_emphasis;
dwc->hsphy_interface = pdata->hsphy_interface;
+ fladj = pdata->fladj_value;
}
/* default to superspeed if no maximum_speed passed */
@@ -957,6 +990,7 @@ static int dwc3_probe(struct platform_device *pdev)
goto err1;
}
+
if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
dwc->dr_mode = USB_DR_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
@@ -971,6 +1005,9 @@ static int dwc3_probe(struct platform_device *pdev)
goto err1;
}
+ /* Adjust Frame Length */
+ dwc3_frame_length_adjustment(dwc, fladj);
+
usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
ret = phy_power_on(dwc->usb2_generic_phy);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 0447788..9188745 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -124,6 +124,7 @@
#define DWC3_GEVNTCOUNT(n) (0xc40c + (n * 0x10))
#define DWC3_GHWPARAMS80xc600
+#define DWC3_GFLADJ0xc630
/* Device Registers */
#define DWC3_DCFG 0xc700
@@ -234,6 +235,10 @@
/* Global HWPARAMS6 Register */
#define DWC3_GHWPARAMS6_EN_FPGA(1 << 7)
+/* Global Frame Length Adjustment Register */
+#define DWC3_GFLADJ_30MHZ_SDBND_SEL(1 << 7)
+#define DWC3_GFLADJ_30MHZ_MASK 0x3f
+
/* Device Configuration Register */
#define DWC3_DCFG_DEVADDR(addr)((addr) << 3)
#define DWC3_DCFG_DEVADDR_MASK DWC3_DCFG_DEVADDR(0x7f)
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index d3614ec..400b197 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -46,5 +46,7 @@ struct dwc3_platform_data {
unsigned tx_de_emphasis_quirk:1;
unsigned tx_de_emphasis:2;
+ u32 fladj_value;
+
const char *hsphy_interface;
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe
Re: linux-next: build failure after merge of the drm-exynos tree
Hi Inki,
On Mon, 17 Aug 2015 13:51:30 +1000 Stephen Rothwell
wrote:
>
> After merging the drm-exynos tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/drm/exynos/exynos_mixer.c: In function 'vp_video_buffer':
> drivers/gpu/drm/exynos/exynos_mixer.c:395:15: error: 'struct
> exynos_drm_plane' has no member named 'pixel_format'
> switch (plane->pixel_format) {
>^
> In file included from drivers/gpu/drm/exynos/exynos_mixer.c:17:0:
> drivers/gpu/drm/exynos/exynos_mixer.c:404:10: error: 'struct
> exynos_drm_plane' has no member named 'pixel_format'
> plane->pixel_format);
> ^
> include/drm/drmP.h:164:17: note: in definition of macro 'DRM_ERROR'
> drm_err(fmt, ##__VA_ARGS__)
> ^
> drivers/gpu/drm/exynos/exynos_mixer.c:411:11: error: 'struct
> exynos_drm_plane' has no member named 'scan_flag'
> if (plane->scan_flag & DRM_MODE_FLAG_INTERLACE) {
>^
> drivers/gpu/drm/exynos/exynos_mixer.c:417:39: error: 'struct
> exynos_drm_plane' has no member named 'pitch'
> luma_addr[1] = luma_addr[0] + plane->pitch;
>^
> drivers/gpu/drm/exynos/exynos_mixer.c:418:43: error: 'struct
> exynos_drm_plane' has no member named 'pitch'
> chroma_addr[1] = chroma_addr[0] + plane->pitch;
>^
> In file included from drivers/gpu/drm/exynos/exynos_mixer.c:20:0:
> drivers/gpu/drm/exynos/exynos_mixer.c:439:53: error: 'struct
> exynos_drm_plane' has no member named 'pitch'
> vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(plane->pitch) |
> ^
> drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
> 'VP_MASK_VAL'
> (((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
> ^
> drivers/gpu/drm/exynos/exynos_mixer.c:439:35: note: in expansion of macro
> 'VP_IMG_HSIZE'
> vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(plane->pitch) |
>^
> drivers/gpu/drm/exynos/exynos_mixer.c:440:21: error: 'struct
> exynos_drm_plane' has no member named 'fb_height'
>VP_IMG_VSIZE(plane->fb_height));
> ^
> drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
> 'VP_MASK_VAL'
> (((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
> ^
> drivers/gpu/drm/exynos/exynos_mixer.c:440:3: note: in expansion of macro
> 'VP_IMG_VSIZE'
>VP_IMG_VSIZE(plane->fb_height));
>^
> drivers/gpu/drm/exynos/exynos_mixer.c:442:53: error: 'struct
> exynos_drm_plane' has no member named 'pitch'
> vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(plane->pitch) |
> ^
> drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
> 'VP_MASK_VAL'
> (((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
> ^
> drivers/gpu/drm/exynos/exynos_mixer.c:442:35: note: in expansion of macro
> 'VP_IMG_HSIZE'
> vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(plane->pitch) |
>^
> drivers/gpu/drm/exynos/exynos_mixer.c:443:21: error: 'struct
> exynos_drm_plane' has no member named 'fb_height'
>VP_IMG_VSIZE(plane->fb_height / 2));
> ^
> drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
> 'VP_MASK_VAL'
> (((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
> ^
> drivers/gpu/drm/exynos/exynos_mixer.c:443:3: note: in expansion of macro
> 'VP_IMG_VSIZE'
>VP_IMG_VSIZE(plane->fb_height / 2));
>^
> drivers/gpu/drm/exynos/exynos_mixer.c:445:39: error: 'struct
> exynos_drm_plane' has no member named 'src_width'
> vp_reg_write(res, VP_SRC_WIDTH, plane->src_width);
>^
> drivers/gpu/drm/exynos/exynos_mixer.c:446:40: error: 'struct
> exynos_drm_plane' has no member named 'src_height'
> vp_reg_write(res, VP_SRC_HEIGHT, plane->src_height);
> ^
> drivers/gpu/drm/exynos/exynos_mixer.c:451:39: error: 'struct
> exynos_drm_plane' has no member named 'crtc_width'
> vp_reg_write(res, VP_DST_WIDTH, plane->crtc_width);
>^
> drivers/gpu/drm/exynos/exynos_mixer.c:454:41: error: 'struct
> exynos_drm_plane' has no member named 'crtc_height'
>vp_reg_write(res, VP_DST_HEIGHT, plane->crtc_height / 2);
> ^
> drivers/gpu/drm/exynos/exynos_mixer.c:457:41: error: 'struct
> exynos_drm_plane' has no member named 'crtc_height'
>vp_reg_write(res, VP_DST_HEIGHT, plane->crtc_height);
> ^
> drivers/gpu/drm/exynos/exynos_mixer.c:472:27: error: 'struct
> exynos_drm_plane' has no member named 'mode_height'
> mixer_cfg_scan(ctx, plane->mode_height);
>^
> drivers/gpu/drm/exynos/exynos_mixer.c:473:30: error: 'struct
> exynos_drm_plane' has no member named 'mode_height'
>
[PATCH v2] spi: bitbang: Replace spinlock by mutex
chipselect (in the case of spi-gpio: spi_gpio_chipselect, which
calls gpiod_set_raw_value_cansleep) can sleep, so we should not
hold a spinlock while calling it from spi_bitbang_setup.
This issue was introduced by this commit, which converted spi-gpio
to cansleep variants:
d9dda5a191 "spi: spi-gpio: Use 'cansleep' variants to access GPIO"
Replacing the lock variable by a mutex fixes the issue: This is
safe as all instances where the lock is used are called from
contexts that can sleep.
Finally, update spi-ppc4xx and and spi-s3c24xx to use mutex
functions, as they directly hold the lock for similar purpose.
Signed-off-by: Nicolas Boichat
---
Going the "safer" way and just replacing the spinlock by a
mutex.
Applies on top of broonie-sound/for-next, and compile-tested on
x86-64/arm (allyesconfig) and ppc44x (defconfig+SPI driver),
and runtime-tested on an arm platform.
Thanks!
drivers/spi/spi-bitbang.c | 17 +++--
drivers/spi/spi-ppc4xx.c| 4 ++--
drivers/spi/spi-s3c24xx.c | 4 ++--
include/linux/spi/spi_bitbang.h | 2 +-
4 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/spi-bitbang.c b/drivers/spi/spi-bitbang.c
index 840a498..ef43ef5 100644
--- a/drivers/spi/spi-bitbang.c
+++ b/drivers/spi/spi-bitbang.c
@@ -180,7 +180,6 @@ int spi_bitbang_setup(struct spi_device *spi)
{
struct spi_bitbang_cs *cs = spi->controller_state;
struct spi_bitbang *bitbang;
- unsigned long flags;
bitbang = spi_master_get_devdata(spi->master);
@@ -210,12 +209,12 @@ int spi_bitbang_setup(struct spi_device *spi)
*/
/* deselect chip (low or high) */
- spin_lock_irqsave(>lock, flags);
+ mutex_lock(>lock);
if (!bitbang->busy) {
bitbang->chipselect(spi, BITBANG_CS_INACTIVE);
ndelay(cs->nsecs);
}
- spin_unlock_irqrestore(>lock, flags);
+ mutex_unlock(>lock);
return 0;
}
@@ -255,13 +254,12 @@ static int spi_bitbang_bufs(struct spi_device *spi,
struct spi_transfer *t)
static int spi_bitbang_prepare_hardware(struct spi_master *spi)
{
struct spi_bitbang *bitbang;
- unsigned long flags;
bitbang = spi_master_get_devdata(spi);
- spin_lock_irqsave(>lock, flags);
+ mutex_lock(>lock);
bitbang->busy = 1;
- spin_unlock_irqrestore(>lock, flags);
+ mutex_unlock(>lock);
return 0;
}
@@ -378,13 +376,12 @@ static int spi_bitbang_transfer_one(struct spi_master
*master,
static int spi_bitbang_unprepare_hardware(struct spi_master *spi)
{
struct spi_bitbang *bitbang;
- unsigned long flags;
bitbang = spi_master_get_devdata(spi);
- spin_lock_irqsave(>lock, flags);
+ mutex_lock(>lock);
bitbang->busy = 0;
- spin_unlock_irqrestore(>lock, flags);
+ mutex_unlock(>lock);
return 0;
}
@@ -427,7 +424,7 @@ int spi_bitbang_start(struct spi_bitbang *bitbang)
if (!master || !bitbang->chipselect)
return -EINVAL;
- spin_lock_init(>lock);
+ mutex_init(>lock);
if (!master->mode_bits)
master->mode_bits = SPI_CPOL | SPI_CPHA | bitbang->flags;
diff --git a/drivers/spi/spi-ppc4xx.c b/drivers/spi/spi-ppc4xx.c
index 54fb984..dd3d0a2 100644
--- a/drivers/spi/spi-ppc4xx.c
+++ b/drivers/spi/spi-ppc4xx.c
@@ -210,12 +210,12 @@ static int spi_ppc4xx_setupxfer(struct spi_device *spi,
struct spi_transfer *t)
if (in_8(>regs->cdm) != cdm)
out_8(>regs->cdm, cdm);
- spin_lock(>bitbang.lock);
+ mutex_lock(>bitbang.lock);
if (!hw->bitbang.busy) {
hw->bitbang.chipselect(spi, BITBANG_CS_INACTIVE);
/* Need to ndelay here? */
}
- spin_unlock(>bitbang.lock);
+ mutex_unlock(>bitbang.lock);
return 0;
}
diff --git a/drivers/spi/spi-s3c24xx.c b/drivers/spi/spi-s3c24xx.c
index f36bc32..4e7d1bf 100644
--- a/drivers/spi/spi-s3c24xx.c
+++ b/drivers/spi/spi-s3c24xx.c
@@ -198,12 +198,12 @@ static int s3c24xx_spi_setup(struct spi_device *spi)
if (ret)
return ret;
- spin_lock(>bitbang.lock);
+ mutex_lock(>bitbang.lock);
if (!hw->bitbang.busy) {
hw->bitbang.chipselect(spi, BITBANG_CS_INACTIVE);
/* need to ndelay for 0.5 clocktick ? */
}
- spin_unlock(>bitbang.lock);
+ mutex_unlock(>bitbang.lock);
return 0;
}
diff --git a/include/linux/spi/spi_bitbang.h b/include/linux/spi/spi_bitbang.h
index 85578d4..154788e 100644
--- a/include/linux/spi/spi_bitbang.h
+++ b/include/linux/spi/spi_bitbang.h
@@ -4,7 +4,7 @@
#include
struct spi_bitbang {
- spinlock_t lock;
+ struct mutexlock;
u8 busy;
u8 use_dma;
u8 flags; /* extra
Re: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register
On 17.08.2015 11:28, Joonyoung Shim wrote:
> On 08/17/2015 11:00 AM, Krzysztof Kozlowski wrote:
>> On 17.08.2015 10:47, Joonyoung Shim wrote:
>>> Hi,
>>>
>>> On 08/13/2015 07:02 PM, Krzysztof Kozlowski wrote:
W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
> According to datasheet, the S2MPS13X and S2MPS14X should update write
> buffer via setting WUDR bit to high after ctrl register is updated.
Hi,
I cannot find this information in S2MPS14 datasheet. On which page is it?
>>>
>>> I got below information from S2MPS14_Data Sheet_REV0.1 document.
>>>
>>> 5.2.2.3 RTC_UPDATE
>>> ...
>>>
>>> NOTE:
>>> 1. For write Time Registers (0x00, 0x04~0x0A) & Alarm 0&1 Registers
>>> (0x0B~0x18), set WUDR bit to high.
>>
>> Right, I have too but it does not say anything about control register.
>> It mentions only time, alarm 0 and alarm 1 registers, not control.
>>
>
> Address 0x00 is RTC_CTRL, so i don't know what you say.
Ah, I see now!
You're right, the datasheet mentions control register as time register.
In this case before reading the RUDR should be set high (for all
S2MPS1[134]).
BR,
Krzysztof
>
>>>
>
> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
> tools/testing/selftests/timers/rtctest.c test program and hour format is
> used to 12 hour mode in Odroid-XU3 board.
Two questions here:
1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
S2MP14)? There are some minor differences between them so I would not be
surprised if only some of them required this action.
>>>
>>> I'm not sure about that because i don't have S2MPS11 datasheet. I just
>>> got the information that S2MPS11 also use S2MPS14 rtc from sec-core mfd
>>> driver,
>>
>> Yeah, I added it. But these RTC modules are slightly different,
>> especially S2MPS14, so you cannot assume that they are the same after
>> looking at mainline code.
>>
>
> OK, could you check this issue from different things?
>
> Thanks.
>
>>>
>>> static const struct mfd_cell s2mps11_devs[] = {
>>>
>>> {
>>>
>>> .name = "s2mps11-pmic",
>>>
>>> }, {
>>>
>>> .name = "s2mps14-rtc",
>>>
>>> }, {
>>>
>>> .name = "s2mps11-clk",
>>>
>>> .of_compatible = "samsung,s2mps11-clk",
>>>
>>> }
>>>
>>> };
>>>
2. The driver operates in 24-hour omode. Actually it sets the 24-hour
mode just before your new regmap_update_bits() call. What do you mean by
12-hour mode?
>>>
>>> RTC_CTRL register value is 0 until write buffer is updated, so it is
>>> used to 12-hour mode.
>>
>> I mean what do you have in mind by saying:
>> "... and hour format is used to 12 hour mode in Odroid-XU3 board."
>> The hour format is set by driver to 24h mode.
>>
>>
>>>
> Signed-off-by: Joonyoung Shim
> Cc:
Thanks for putting a cc-stable tag. How far this should be ported? If
this is needed only for S2MPS11 then v4.1. If all of them then probably
for earlier version?
>>>
>>> If find exact version, i think it will be a version after below commit
>>> was applied.
>>>
>>> The commit 0c5deb1ea92f("rtc: s5m: add support for S2MPS14 RTC")
>>>
>>> $ git name-rev 0c5deb1ea92f
>>> 0c5deb1ea92f tags/v3.16-rc1~53^2~1
>>
>> Hmmm... I am not against the patch (especially that it matches source
>> code of SM-G900H with S2MPS11) but I have doubts about affected
>> chipsets. My Odroid (probably because of bootloader), S2MPS13 and
>> S2MPS14 do not need it. This confuses me...
>>
>> Best regards,
>> Krzysztof
>>
>>>
>>> Thanks.
>>>
Best regards,
Krzysztof
> ---
> drivers/rtc/rtc-s5m.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
> index 8c70d78..03828bb 100644
> --- a/drivers/rtc/rtc-s5m.c
> +++ b/drivers/rtc/rtc-s5m.c
> @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info
> *info)
> case S2MPS13X:
> data[0] = (0 <<
linux-next: build failure after merge of the drm-exynos tree
Hi Inki,
After merging the drm-exynos tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/exynos/exynos_mixer.c: In function 'vp_video_buffer':
drivers/gpu/drm/exynos/exynos_mixer.c:395:15: error: 'struct exynos_drm_plane'
has no member named 'pixel_format'
switch (plane->pixel_format) {
^
In file included from drivers/gpu/drm/exynos/exynos_mixer.c:17:0:
drivers/gpu/drm/exynos/exynos_mixer.c:404:10: error: 'struct exynos_drm_plane'
has no member named 'pixel_format'
plane->pixel_format);
^
include/drm/drmP.h:164:17: note: in definition of macro 'DRM_ERROR'
drm_err(fmt, ##__VA_ARGS__)
^
drivers/gpu/drm/exynos/exynos_mixer.c:411:11: error: 'struct exynos_drm_plane'
has no member named 'scan_flag'
if (plane->scan_flag & DRM_MODE_FLAG_INTERLACE) {
^
drivers/gpu/drm/exynos/exynos_mixer.c:417:39: error: 'struct exynos_drm_plane'
has no member named 'pitch'
luma_addr[1] = luma_addr[0] + plane->pitch;
^
drivers/gpu/drm/exynos/exynos_mixer.c:418:43: error: 'struct exynos_drm_plane'
has no member named 'pitch'
chroma_addr[1] = chroma_addr[0] + plane->pitch;
^
In file included from drivers/gpu/drm/exynos/exynos_mixer.c:20:0:
drivers/gpu/drm/exynos/exynos_mixer.c:439:53: error: 'struct exynos_drm_plane'
has no member named 'pitch'
vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(plane->pitch) |
^
drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
'VP_MASK_VAL'
(((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
^
drivers/gpu/drm/exynos/exynos_mixer.c:439:35: note: in expansion of macro
'VP_IMG_HSIZE'
vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(plane->pitch) |
^
drivers/gpu/drm/exynos/exynos_mixer.c:440:21: error: 'struct exynos_drm_plane'
has no member named 'fb_height'
VP_IMG_VSIZE(plane->fb_height));
^
drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
'VP_MASK_VAL'
(((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
^
drivers/gpu/drm/exynos/exynos_mixer.c:440:3: note: in expansion of macro
'VP_IMG_VSIZE'
VP_IMG_VSIZE(plane->fb_height));
^
drivers/gpu/drm/exynos/exynos_mixer.c:442:53: error: 'struct exynos_drm_plane'
has no member named 'pitch'
vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(plane->pitch) |
^
drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
'VP_MASK_VAL'
(((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
^
drivers/gpu/drm/exynos/exynos_mixer.c:442:35: note: in expansion of macro
'VP_IMG_HSIZE'
vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(plane->pitch) |
^
drivers/gpu/drm/exynos/exynos_mixer.c:443:21: error: 'struct exynos_drm_plane'
has no member named 'fb_height'
VP_IMG_VSIZE(plane->fb_height / 2));
^
drivers/gpu/drm/exynos/regs-vp.h:59:5: note: in definition of macro
'VP_MASK_VAL'
(((val) << (low_bit)) & VP_MASK(high_bit, low_bit))
^
drivers/gpu/drm/exynos/exynos_mixer.c:443:3: note: in expansion of macro
'VP_IMG_VSIZE'
VP_IMG_VSIZE(plane->fb_height / 2));
^
drivers/gpu/drm/exynos/exynos_mixer.c:445:39: error: 'struct exynos_drm_plane'
has no member named 'src_width'
vp_reg_write(res, VP_SRC_WIDTH, plane->src_width);
^
drivers/gpu/drm/exynos/exynos_mixer.c:446:40: error: 'struct exynos_drm_plane'
has no member named 'src_height'
vp_reg_write(res, VP_SRC_HEIGHT, plane->src_height);
^
drivers/gpu/drm/exynos/exynos_mixer.c:451:39: error: 'struct exynos_drm_plane'
has no member named 'crtc_width'
vp_reg_write(res, VP_DST_WIDTH, plane->crtc_width);
^
drivers/gpu/drm/exynos/exynos_mixer.c:454:41: error: 'struct exynos_drm_plane'
has no member named 'crtc_height'
vp_reg_write(res, VP_DST_HEIGHT, plane->crtc_height / 2);
^
drivers/gpu/drm/exynos/exynos_mixer.c:457:41: error: 'struct exynos_drm_plane'
has no member named 'crtc_height'
vp_reg_write(res, VP_DST_HEIGHT, plane->crtc_height);
^
drivers/gpu/drm/exynos/exynos_mixer.c:472:27: error: 'struct exynos_drm_plane'
has no member named 'mode_height'
mixer_cfg_scan(ctx, plane->mode_height);
^
drivers/gpu/drm/exynos/exynos_mixer.c:473:30: error: 'struct exynos_drm_plane'
has no member named 'mode_height'
mixer_cfg_rgb_fmt(ctx, plane->mode_height);
^
drivers/gpu/drm/exynos/exynos_mixer.c: In function 'mixer_setup_scale':
drivers/gpu/drm/exynos/exynos_mixer.c:494:11: error: 'const struct
exynos_drm_plane' has no member named 'crtc_width
--
Cheers,
Stephen
Re: [PATCH] gpio:Fix build warning about void to integer cast in the function mmio_74xx_gpio_probe
On Fri, Aug 14, 2015 at 2:45 AM, nick wrote: > > > On 2015-07-16 08:00 AM, Linus Walleij wrote: >> On Sat, Jul 4, 2015 at 10:34 PM, Nicholas Krause wrote: >> >>> This fixes the build warning , warning: cast from pointer to integer >>> of different size when building this file on a x86 allmodconfig >>> configuration. In order for me to fix this build warning I changed >>> the cast in the function mmio_74xx_gpio_probe from casting the >>> variable data of the stucture pointer of_id to uintptr_t rather >>> then unsigned when assigning to the variable flag of the structure >>> pointer priv of the structure type mmio_74xx_gpio_priv. >>> >>> >>> Signed-off-by: Nicholas Krause >> >> Patch applied with some tweaks to the long subject line. >> >> Yours, >> Linus Walleij >> > > Linus, > After searching through your git tree for gpio subsystem I haven't found this > patch merged > yet. Is there any reason for that or should I just resend. I can see this patch in both Linus' for-next branch (git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next), and linux-next. Always check linux-next first. -- 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] ARM: configs: Add Freescale LS1021A defconfig
Hi, Fabio,
Based on the analysis and discussion, we prefer to use
ls1021a_defconfig and remove LS1021A from imx_v6_v7_defconfig.
Thanks.
Best Regards,
Alison Wang
> On Fri, Aug 14, 2015 at 2:06 PM, Horia Geantă
> wrote:
>
> > Another thing:
> > Commit 385c0fb0e2c4 ("ARM: imx_v6_v7_defconfig: Select LS1021A")
> added
> > CONFIG_SOC_LS1021A in imx_v6_v7_defconfig.
> >
> > Besides this, booting a LS1021 AQDS board (Rev2) using
> > imx_v6_v7_defconfig did not work (stuck at "Starting kernel").
>
> What would be the recommended approach?
>
> - Fix imx_v6_v7_defconfig so that it can make LS1021A to boot
>
> or
>
> - Use this proposed ls1021a_defconfig and remove LS1021A from
> imx_v6_v7_defconfig?
>
> Regards,
>
> Fabio Estevam
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] mmc/sdhci-acpi: enable sdhci-acpi device to suspend/resume asynchronously
Hi, Any comments are welcome. Thanks, Zhonghui On 2015/8/3 21:10, Fu, Zhonghui wrote: > Enable sdhci-acpi device to suspend/resume asynchronously. > This can improve system suspend/resume speed. > > Signed-off-by: Zhonghui Fu > --- > drivers/mmc/host/sdhci-acpi.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c > index 22d929f..67e6263 100644 > --- a/drivers/mmc/host/sdhci-acpi.c > +++ b/drivers/mmc/host/sdhci-acpi.c > @@ -379,6 +379,8 @@ static int sdhci_acpi_probe(struct platform_device *pdev) > pm_runtime_enable(dev); > } > > + device_enable_async_suspend(dev); > + > return 0; > > err_free: > -- 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] spi: Mediatek: fix endian warnings
On Sun, Aug 16, 2015 at 03:06:39PM +0100, Russell King - ARM Linux wrote: > All writel() implementations take a CPU number and write it in little > endian format. Hence, writel() almost always uses cpu_to_le32() > internally. I think the reason this keeps coming up is that people aren't expecting writel() to be doing endianness conversion, it's easy to get caught out by it. signature.asc Description: Digital signature
Re: [PATCH] mmc: enable mmc host device to suspend/resume asynchronously
Hi,
Any comments are welcome.
Thanks,
Zhonghui
On 2015/8/3 20:39, Fu, Zhonghui wrote:
> Enable mmc host device to suspend/resume asynchronously.
> This can improve system suspend/resume speed.
>
> Signed-off-by: Zhonghui Fu
> ---
> drivers/mmc/core/host.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 99a9c90..85f2bbb 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -577,6 +577,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device
> *dev)
> host->class_dev.parent = dev;
> host->class_dev.class = _host_class;
> device_initialize(>class_dev);
> + device_enable_async_suspend(>class_dev);
>
> if (mmc_gpio_alloc(host)) {
> put_device(>class_dev);
> -- 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: [3/4] ARM: dts: Add UART2 dt node for Exynos3250 SoC
Hi Chanwoo,
Similar patch was posted here[1].
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/291023.html
Thanks,
Pankaj Dubey
On Tuesday 11 August 2015 09:16 AM, Chanwoo Choi wrote:
This patch add the uart2 devicetree node for Exynos3250 SoC.
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 7 +++
arch/arm/boot/dts/exynos3250.dtsi | 12
2 files changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
index 5ab81c39e2c9..eac1d21c10d4 100644
--- a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -120,6 +120,13 @@
samsung,pin-drv = <0>;
};
+ uart2_data: uart2-data {
+ samsung,pins = "gpa1-0", "gpa1-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
i2c3_bus: i2c3-bus {
samsung,pins = "gpa1-2", "gpa1-3";
samsung,pin-function = <3>;
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 2db99433e17f..02f3250766c9 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -42,6 +42,7 @@
i2c7 = _7;
serial0 = _0;
serial1 = _1;
+ serial2 = _2;
};
cpus {
@@ -435,6 +436,17 @@
status = "disabled";
};
+ serial_2: serial@1382 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x1382 0x100>;
+ interrupts = <0 111 0>;
+ clocks = < CLK_UART2>, < CLK_SCLK_UART2>;
+ clock-names = "uart", "clk_uart_baud0";
+ pinctrl-names = "default";
+ pinctrl-0 = <_data>;
+ status = "disabled";
+ };
+
i2c_0: i2c@1386 {
#address-cells = <1>;
#size-cells = <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 v6] arm64: dts: Add spi bus dts
This patch adds MT8173 spi bus controllers into device tree.
Signed-off-by: Leilk Liu
---
Change in this patch:
pinctl and pad-select fields are board specific, so move to
mt8173-evb.dtsi, and status = "okay".
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 12
2 files changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 4be66ca..811cb76 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -387,6 +387,24 @@
};
};
+ {
+ spi_pins_a: spi0 {
+ pins_spi {
+ pinmux = ,
+ ,
+ ,
+ ;
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..3dfb6ed 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -365,6 +365,18 @@
status = "disabled";
};
+ spi: spi@1100a000 {
+ compatible = "mediatek,mt8173-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x1100a000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_TOP_SPI_SEL>,
+< CLK_TOP_SYSPLL3_D2>;
+ clock-names = "spi-clk", "parent-clk";
+ status = "disabled";
+ };
+
i2c3: i2c3@1101 {
compatible = "mediatek,mt8173-i2c";
reg = <0 0x1101 0 0x70>,
--
1.8.1.1.dirty
--
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: [1/4] clk: samsung: exynos3250: Add UART2 clock
Hi Chanwoo,
Thanks for this patch. Similar patch[1] was posted long back, and there
were some concern from your side, if you think those concerns are fixed,
then my patch [1] are still valid and can be taken. If it needs to be
rebase I am happy to do that.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/291239.html
Thanks,
Pankaj Dubey
On Tuesday 11 August 2015 09:16 AM, Chanwoo Choi wrote:
This patch add the UART2 clocks (mux, divider, gate) of Exynos3250 SoC.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
drivers/clk/samsung/clk-exynos3250.c | 6 ++
include/dt-bindings/clock/exynos3250.h | 6 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index 538de66a759e..2105863a3ace 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -307,6 +307,7 @@ static struct samsung_mux_clock mux_clks[] __initdata = {
MUX(CLK_MOUT_MMC0, "mout_mmc0", group_sclk_p, SRC_FSYS, 0, 4),
/* SRC_PERIL0 */
+ MUX(CLK_MOUT_UART2, "mout_uart2", group_sclk_p, SRC_PERIL0, 8, 4),
MUX(CLK_MOUT_UART1, "mout_uart1", group_sclk_p, SRC_PERIL0, 4, 4),
MUX(CLK_MOUT_UART0, "mout_uart0", group_sclk_p, SRC_PERIL0, 0, 4),
@@ -389,6 +390,7 @@ static struct samsung_div_clock div_clks[] __initdata = {
DIV(CLK_DIV_MMC0, "div_mmc0", "mout_mmc0", DIV_FSYS1, 0, 4),
/* DIV_PERIL0 */
+ DIV(CLK_DIV_UART2, "div_uart2", "mout_uart2", DIV_PERIL0, 8, 4),
DIV(CLK_DIV_UART1, "div_uart1", "mout_uart1", DIV_PERIL0, 4, 4),
DIV(CLK_DIV_UART0, "div_uart0", "mout_uart0", DIV_PERIL0, 0, 4),
@@ -551,6 +553,9 @@ static struct samsung_gate_clock gate_clks[] __initdata = {
GATE_SCLK_PERIL, 7, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_SPI0, "sclk_spi0", "div_spi0_pre",
GATE_SCLK_PERIL, 6, CLK_SET_RATE_PARENT, 0),
+
+ GATE(CLK_SCLK_UART2, "sclk_uart2", "div_uart2",
+ GATE_SCLK_PERIL, 2, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART1, "sclk_uart1", "div_uart1",
GATE_SCLK_PERIL, 1, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART0, "sclk_uart0", "div_uart0",
@@ -648,6 +653,7 @@ static struct samsung_gate_clock gate_clks[] __initdata = {
GATE(CLK_I2C2, "i2c2", "div_aclk_100", GATE_IP_PERIL, 8, 0, 0),
GATE(CLK_I2C1, "i2c1", "div_aclk_100", GATE_IP_PERIL, 7, 0, 0),
GATE(CLK_I2C0, "i2c0", "div_aclk_100", GATE_IP_PERIL, 6, 0, 0),
+ GATE(CLK_UART2, "uart2", "div_aclk_100", GATE_IP_PERIL, 2, 0, 0),
GATE(CLK_UART1, "uart1", "div_aclk_100", GATE_IP_PERIL, 1, 0, 0),
GATE(CLK_UART0, "uart0", "div_aclk_100", GATE_IP_PERIL, 0, 0, 0),
};
diff --git a/include/dt-bindings/clock/exynos3250.h
b/include/dt-bindings/clock/exynos3250.h
index aab088d30199..89a7d97b002c 100644
--- a/include/dt-bindings/clock/exynos3250.h
+++ b/include/dt-bindings/clock/exynos3250.h
@@ -78,6 +78,7 @@
#define CLK_MOUT_CORE 58
#define CLK_MOUT_APLL 59
#define CLK_MOUT_ACLK_266_SUB 60
+#define CLK_MOUT_UART2 61
/* Dividers */
#define CLK_DIV_GPL 64
@@ -126,6 +127,7 @@
#define CLK_DIV_CORE 107
#define CLK_DIV_HPM 108
#define CLK_DIV_COPY 109
+#define CLK_DIV_UART2 110
/* Gates */
#define CLK_ASYNC_G3D 128
@@ -222,6 +224,7 @@
#define CLK_BLOCK_MFC 219
#define CLK_BLOCK_CAM 220
#define CLK_SMIES 221
+#define CLK_UART2 222
/* Special clocks */
#define CLK_SCLK_JPEG 224
@@ -248,12 +251,13 @@
#define CLK_SCLK_SPI0 245
#define CLK_SCLK_UART1246
#define CLK_SCLK_UART0247
+#define CLK_SCLK_UART2 248
/*
* Total number of clocks of main CMU.
* NOTE: Must be equal to last clock ID increased by one.
*/
-#define CLK_NR_CLKS248
+#define CLK_NR_CLKS249
/*
* CMU DMC
--
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 1/6] genirq: fix irq_chip_retrigger_hierarchy
On 2015/8/14 20:20, Grygorii Strashko wrote:
> Now irq_chip_retrigger_hierarchy() returns -ENOSYS if it
> was not able to find at least one .irq_retrigger() callback
> implemented in IRQ domain hierarchy. As result, IRQ
> re-triggering is not working now on ARM (TI OMAP) where
> ARM GIC is not implemented this callback.
> The .irq_retrigger() is optional (see check_irq_resend())
> and there are no reasons to fail if it was not found, hence
> lets return 0 in this case.
>
> In case of TI OMAP DRA7 the following IRQ hierarchy is defined:
> ARM GIC <- OMAP wakeupgen <- TI CBAR
>
> Failure is reproduced during resume from suspend to RAM:
> - wakeup by IRQx
> - suspend_enter
> + arch_suspend_enable_irqs
> + handle_fasteoi_irq
> + irq_may_run
> + irq_pm_check_wakeup
> + irq_disable(IRQx)
> + dpm_resume_noirq()
> + resume_device_irqs
> + resume_irqs
> + resume_irq
> + __enable_irq <== IRQx is not re-triggered
>
> Cc: Sudeep Holla
> Cc: Jiang Liu
> Fixes: 85f08c17de26 ('genirq: Introduce helper functions...')
> Reviewed-by: Marc Zyngier
> Signed-off-by: Grygorii Strashko
> ---
> kernel/irq/chip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 27f4332..6de638b 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -997,7 +997,7 @@ int irq_chip_retrigger_hierarchy(struct irq_data *data)
> if (data->chip && data->chip->irq_retrigger)
> return data->chip->irq_retrigger(data);
>
> - return -ENOSYS;
> + return 0;
> }
>
> /**
Hi Grygorii,
Thanks for fixing this regression:)
Reviewed-by: Jiang Liu
--
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-panel tree with the tegra tree
Hi Thierry,
Today's linux-next merge of the drm-panel tree got a conflict in:
arch/arm/configs/multi_v7_defconfig
between commit:
258d9bc5e77f ("ARM: tegra: Update multi_v7_defconfig")
from the tegra tree and commit:
330b48bd700d ("drm/bridge: Add vendor prefixes")
from the drm-panel tree.
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 arch/arm/configs/multi_v7_defconfig
index 019e1396925e,48b0362a0f0e..
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@@ -440,11 -430,8 +440,11 @@@ CONFIG_VIDEO_RENESAS_VSP1=
CONFIG_VIDEO_ADV7180=m
CONFIG_VIDEO_ML86V7667=m
CONFIG_DRM=y
+# CONFIG_DRM_I2C_CH7006 is not set
+# CONFIG_DRM_I2C_SIL164 is not set
- CONFIG_DRM_PTN3460=m
- CONFIG_DRM_PS8622=m
+ CONFIG_DRM_NXP_PTN3460=m
+ CONFIG_DRM_PARADE_PS8622=m
+CONFIG_DRM_NOUVEAU=m
CONFIG_DRM_EXYNOS=m
CONFIG_DRM_EXYNOS_DSI=y
CONFIG_DRM_EXYNOS_FIMD=y
--
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] copy_from{to}_user question
> On Aug 14, 2015, at 00:43, Borislav Petkov wrote:
>
> On Thu, Aug 13, 2015 at 06:04:54PM +0800, yalin wang wrote:
>> we store type into one fix register, for example r12 ,
>> then in fix up code, we can know the exception is caused by copy_from
>> copy_to or copy_in user function by check r12 value(0 , 1 ,2 value), then if
>> it is copy_from, we only allow read fault, if the exception is write fault,
>> panic() .
>>
>> the same rules also apply to copy_to / copy_in function .
>>
>> is it possible to change it like this ?
>
> ... and we'll do all that jumping through hoops to fix what actual,
> real-life problem exactly?
i just want the x86 copy_from{to,in}_user() function have
the same behaviour as other platforms.
and can disclose potential BUGs in kernel, if do like this.
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] MMC/SDIO: enable SDIO device to suspend/resume asynchronously
Hi, Any comments are welcome. Thanks, Zhonghui On 2015/7/30 15:40, Fu, Zhonghui wrote: > Enable SDIO card and function device to suspend/resume asynchronously. > This can improve system suspend/resume speed. > > Signed-off-by: Zhonghui Fu > --- > drivers/mmc/core/sdio.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c > index b91abed..6719b77 100644 > --- a/drivers/mmc/core/sdio.c > +++ b/drivers/mmc/core/sdio.c > @@ -1106,6 +1106,8 @@ int mmc_attach_sdio(struct mmc_host *host) > pm_runtime_enable(>dev); > } > > + device_enable_async_suspend(>dev); > + > /* >* The number of functions on the card is encoded inside >* the ocr. > @@ -1126,6 +1128,8 @@ int mmc_attach_sdio(struct mmc_host *host) >*/ > if (host->caps & MMC_CAP_POWER_OFF_CARD) > pm_runtime_enable(>sdio_func[i]->dev); > + > + device_enable_async_suspend(>sdio_func[i]->dev); > } > > /* > -- 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/
[PATCH] arm64: dts: Juno: fix the wrong memory map sizes for the I2C/EHCI/OHCI
>From the "Juno ARM Development Platform Soc Techinical Reference
>Mannual(r1p0)",
we get the following memory map sizes (3-25):
I2C : 0x7ffa 0x7ffa00ff (256B)
USB OHCI : 0x7ffb 0x7ffb0fff (4KB)
USB EHCI : 0x7ffc 0x7ffc0fff (4KB)
This patch fixes the wrong memory map sizes for them.
Signed-off-by: Huang Shijie
---
There is something wrong with my email account, so try to send it out again.
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi
b/arch/arm64/boot/dts/arm/juno-base.dtsi
index e3ee960..7b2715f 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -74,7 +74,7 @@
i2c@7ffa {
compatible = "snps,designware-i2c";
- reg = <0x0 0x7ffa 0x0 0x1000>;
+ reg = <0x0 0x7ffa 0x0 0x100>;
#address-cells = <1>;
#size-cells = <0>;
interrupts = ;
@@ -95,14 +95,14 @@
ohci@7ffb {
compatible = "generic-ohci";
- reg = <0x0 0x7ffb 0x0 0x1>;
+ reg = <0x0 0x7ffb 0x0 0x1000>;
interrupts = ;
clocks = <_usb48mhz>;
};
ehci@7ffc {
compatible = "generic-ehci";
- reg = <0x0 0x7ffc 0x0 0x1>;
+ reg = <0x0 0x7ffc 0x0 0x1000>;
interrupts = ;
clocks = <_usb48mhz>;
};
--
2.1.4
--
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 drm-intel-fixes tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/intel_atomic.c
drivers/gpu/drm/i915/intel_display.c
between commits:
f0fdc55db0c6 ("drm/i915: calculate primary visibility changes instead of
calling from set_config")
d2944cf21305 ("drm/i915: Commit planes on each crtc separately.")
from the drm-intel-fixes tree and commit:
74c090b1bdc5 ("drm/i915: Use full atomic modeset.")
and maybe others from the drm tree.
I fixed it up (both these former commits are based on commits in the
latter tree, so I just used the latter tree versions) and can carry the
fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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 V3 1/9] x86, NUMA, ACPI: Online node earlier when doing CPU hot-addition
With typical CPU hot-addition flow on x86, PCI host bridges embedded in physical processor are always associated with NOMA_NO_NODE, which may cause sub-optimal performance. 1) Handle CPU hot-addition notification acpi_processor_add() acpi_processor_get_info() acpi_processor_hotadd_init() acpi_map_lsapic() 1.a)acpi_map_cpu2node() 2) Handle PCI host bridge hot-addition notification acpi_pci_root_add() pci_acpi_scan_root() 2.a)if (node != NUMA_NO_NODE && !node_online(node)) node = NUMA_NO_NODE; 3) Handle memory hot-addition notification acpi_memory_device_add() acpi_memory_enable_device() add_memory() 3.a)node_set_online(); 4) Online CPUs through sysfs interfaces cpu_subsys_online() cpu_up() try_online_node() 4.a)node_set_online(); So associated node is always in offline state because it is onlined until step 3.a or 4.a. We could improve performance by online node at step 1.a. This change also makes the code symmetric. Nodes are always created when handling CPU/memory hot-addition events instead of handling user requests from sysfs interfaces, and are destroyed when handling CPU/memory hot-removal events. It also close a race window caused by kmalloc_node(cpu_to_node(cpu)), which may cause system panic as below. [ 3663.324476] BUG: unable to handle kernel paging request at 1f08 [ 3663.332348] IP: [] __alloc_pages_nodemask+0xb9/0x2d0 [ 3663.339719] PGD 82fe10067 PUD 82ebef067 PMD 0 [ 3663.344773] Oops: [#1] SMP [ 3663.348455] Modules linked in: shpchp gpio_ich x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd microcode joydev sb_edac edac_core lpc_ich ipmi_si tpm_tis ipmi_msghandler ioatdma wmi acpi_pad mac_hid lp parport ixgbe isci mpt2sas dca ahci ptp libsas libahci raid_class pps_core scsi_transport_sas mdio hid_generic usbhid hid [ 3663.394393] CPU: 61 PID: 2416 Comm: cron Tainted: GW3.14.0-rc5+ #21 [ 3663.402643] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIN1.86B.0047.F03.1403031049 03/03/2014 [ 3663.414299] task: 88082fe54b00 ti: 880845fba000 task.ti: 880845fba000 [ 3663.422741] RIP: 0010:[] [] __alloc_pages_nodemask+0xb9/0x2d0 [ 3663.432857] RSP: 0018:880845fbbcd0 EFLAGS: 00010246 [ 3663.439265] RAX: 1f00 RBX: RCX: [ 3663.447291] RDX: RSI: 0a8d RDI: 81a8d950 [ 3663.455318] RBP: 880845fbbd58 R08: 880823293400 R09: 0001 [ 3663.463345] R10: 0001 R11: R12: 002052d0 [ 3663.471363] R13: 880854c07600 R14: 0002 R15: [ 3663.479389] FS: 7f2e8b99e800() GS:88105a40() knlGS: [ 3663.488514] CS: 0010 DS: ES: CR0: 80050033 [ 3663.495018] CR2: 1f08 CR3: 0008237b1000 CR4: 001407e0 [ 3663.503476] Stack: [ 3663.505757] 811bd74d 880854c01d98 880854c01df0 880854c01dd0 [ 3663.514167] 0003208ca420 00075a5d84d0 88082fe54b00 811bb35f [ 3663.522567] 880854c07600 0003 1f00 880845fbbd48 [ 3663.530976] Call Trace: [ 3663.533753] [] ? deactivate_slab+0x41d/0x4f0 [ 3663.540421] [] ? new_slab+0x3f/0x2d0 [ 3663.546307] [] new_slab+0xa5/0x2d0 [ 3663.552001] [] __slab_alloc+0x35d/0x54a [ 3663.558185] [] ? local_clock+0x25/0x30 [ 3663.564686] [] ? __do_page_fault+0x4ec/0x5e0 [ 3663.571356] [] ? alloc_fair_sched_group+0xc4/0x190 [ 3663.578609] [] ? __raw_spin_lock_init+0x21/0x60 [ 3663.585570] [] kmem_cache_alloc_node_trace+0xa6/0x1d0 [ 3663.593112] [] ? alloc_fair_sched_group+0xc4/0x190 [ 3663.600363] [] alloc_fair_sched_group+0xc4/0x190 [ 3663.607423] [] sched_create_group+0x3f/0x80 [ 3663.613994] [] sched_autogroup_create_attach+0x3f/0x1b0 [ 3663.621732] [] sys_setsid+0xea/0x110 [ 3663.628020] [] system_call_fastpath+0x1a/0x1f [ 3663.634780] Code: 00 44 89 e7 e8 b9 f8 f4 ff 41 f6 c4 10 74 18 31 d2 be 8d 0a 00 00 48 c7 c7 50 d9 a8 81 e8 70 6a f2 ff e8 db dd 5f 00 48 8b 45 c8 <48> 83 78 08 00 0f 84 b5 01 00 00 48 83 c0 08 44 89 75 c0 4d 89 [ 3663.657032] RIP [] __alloc_pages_nodemask+0xb9/0x2d0 [ 3663.664491] RSP [ 3663.668429] CR2: 1f08 [ 3663.672659] ---[ end trace df13f08ed9de18ad ]--- Signed-off-by: Jiang Liu --- arch/x86/kernel/acpi/boot.c |5 + 1 file changed, 5 insertions(+) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index e49ee24da85e..07930e1d2fe9 100644 --- a/arch/x86/kernel/acpi/boot.c +++
[Patch V3 6/9] i40evf: Use numa_mem_id() to better support memoryless node
Function i40e_clean_rx_irq() tries to reuse memory pages allocated from the nearest node. To better support memoryless node, use numa_mem_id() instead of numa_node_id() to get the nearest node with memory. This change should only affect performance. Signed-off-by: Jiang Liu --- drivers/net/ethernet/intel/i40evf/i40e_txrx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c index 395f32f226c0..19ca96d8bd97 100644 --- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c @@ -1003,7 +1003,7 @@ static int i40e_clean_rx_irq_ps(struct i40e_ring *rx_ring, int budget) unsigned int total_rx_bytes = 0, total_rx_packets = 0; u16 rx_packet_len, rx_header_len, rx_sph, rx_hbo; u16 cleaned_count = I40E_DESC_UNUSED(rx_ring); - const int current_node = numa_node_id(); + const int current_node = numa_mem_id(); struct i40e_vsi *vsi = rx_ring->vsi; u16 i = rx_ring->next_to_clean; union i40e_rx_desc *rx_desc; -- 1.7.10.4 -- 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 V3 2/9] kernel/profile.c: Replace cpu_to_mem() with cpu_to_node()
Function profile_cpu_callback() allocates memory without specifying
__GFP_THISNODE flag, so replace cpu_to_mem() with cpu_to_node()
because cpu_to_mem() may cause suboptimal memory allocation if
there's no free memory on the node returned by cpu_to_mem().
It's safe to use cpu_to_mem() because build_all_zonelists() also
builds suitable fallback zonelist for memoryless node.
Signed-off-by: Jiang Liu
---
kernel/profile.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/profile.c b/kernel/profile.c
index a7bcd28d6e9f..d14805bdcc4c 100644
--- a/kernel/profile.c
+++ b/kernel/profile.c
@@ -336,7 +336,7 @@ static int profile_cpu_callback(struct notifier_block *info,
switch (action) {
case CPU_UP_PREPARE:
case CPU_UP_PREPARE_FROZEN:
- node = cpu_to_mem(cpu);
+ node = cpu_to_node(cpu);
per_cpu(cpu_profile_flip, cpu) = 0;
if (!per_cpu(cpu_profile_hits, cpu)[1]) {
page = alloc_pages_exact_node(node,
--
1.7.10.4
--
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 V3 4/9] openvswitch: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
Function ovs_flow_stats_update() allocates memory with __GFP_THISNODE
flag set, which may cause permanent memory allocation failure on
memoryless node. So replace cpu_to_node() with cpu_to_mem() to better
support memoryless node. For node with memory, cpu_to_mem() is the same
as cpu_to_node().
This change only affects performance and shouldn't affect functionality.
Signed-off-by: Jiang Liu
---
net/openvswitch/flow.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index bc7b0aba994a..e50a5681d0c2 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -69,7 +69,7 @@ void ovs_flow_stats_update(struct sw_flow *flow, __be16
tcp_flags,
const struct sk_buff *skb)
{
struct flow_stats *stats;
- int node = numa_node_id();
+ int node = numa_mem_id();
int len = skb->len + (skb_vlan_tag_present(skb) ? VLAN_HLEN : 0);
stats = rcu_dereference(flow->stats[node]);
--
1.7.10.4
--
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 V3 8/9] mm: Update _mem_id_[] for every possible CPU when memory configuration changes
Current kernel only updates _mem_id_[cpu] for onlined CPUs when memory configuration changes. So kernel may allocate memory from remote node for a CPU if the CPU is still in absent or offline state even if the node associated with the CPU has already been onlined. This patch tries to improve performance by updating _mem_id_[cpu] for each possible CPU when memory configuration changes, thus kernel could always allocate from local node once the node is onlined. We check node_online(cpu_to_node(cpu)) because: 1) local_memory_node(nid) needs to access NODE_DATA(nid) 2) try_offline_node(nid) just zeroes out NODE_DATA(nid) instead of free it Signed-off-by: Jiang Liu --- mm/page_alloc.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index beda41710802..bcfd66e66820 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4334,13 +4334,13 @@ static int __build_all_zonelists(void *data) /* * We now know the "local memory node" for each node-- * i.e., the node of the first zone in the generic zonelist. -* Set up numa_mem percpu variable for on-line cpus. During -* boot, only the boot cpu should be on-line; we'll init the -* secondary cpus' numa_mem as they come on-line. During -* node/memory hotplug, we'll fixup all on-line cpus. +* Set up numa_mem percpu variable for all possible cpus +* if associated node has been onlined. */ - if (cpu_online(cpu)) + if (node_online(cpu_to_node(cpu))) set_cpu_numa_mem(cpu, local_memory_node(cpu_to_node(cpu))); + else + set_cpu_numa_mem(cpu, NUMA_NO_NODE); #endif } -- 1.7.10.4 -- 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 V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
Function i40e_clean_rx_irq() tries to reuse memory pages allocated from the nearest node. To better support memoryless node, use numa_mem_id() instead of numa_node_id() to get the nearest node with memory. This change should only affect performance. Signed-off-by: Jiang Liu --- drivers/net/ethernet/intel/i40e/i40e_txrx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c index 9a4f2bc70cd2..a8f618cb8eb0 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c @@ -1516,7 +1516,7 @@ static int i40e_clean_rx_irq_ps(struct i40e_ring *rx_ring, int budget) unsigned int total_rx_bytes = 0, total_rx_packets = 0; u16 rx_packet_len, rx_header_len, rx_sph, rx_hbo; u16 cleaned_count = I40E_DESC_UNUSED(rx_ring); - const int current_node = numa_node_id(); + const int current_node = numa_mem_id(); struct i40e_vsi *vsi = rx_ring->vsi; u16 i = rx_ring->next_to_clean; union i40e_rx_desc *rx_desc; -- 1.7.10.4 -- 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 V3 9/9] mm, x86: Enable memoryless node support to better support CPU/memory hotplug
With current implementation, all CPUs within a NUMA node will be
assocaited with another NUMA node if the node has no memory installed.
For example, on a four-node system, CPUs on node 2 and 3 are associated
with node 0 when are no memory install on node 2 and 3, which may
confuse users.
root@bkd01sdp:~# numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
66 67 68 69 70 71 72 73 74 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104
105 106 107 108 109 110 111 112 113 114 115 116 117 118 119
node 0 size: 15602 MB
node 0 free: 15014 MB
node 1 cpus: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 75 76 77 78 79 80 81
82 83 84 85 86 87 88 89
node 1 size: 15985 MB
node 1 free: 15686 MB
node distances:
node 0 1
0: 10 21
1: 21 10
To be worse, the CPU affinity relationship won't get fixed even after
memory has been added to those nodes. After memory hot-addition to
node 2, CPUs on node 2 are still associated with node 0. This may cause
sub-optimal performance.
root@bkd01sdp:/sys/devices/system/node/node2# numactl --hardware
available: 3 nodes (0-2)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
66 67 68 69 70 71 72 73 74 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104
105 106 107 108 109 110 111 112 113 114 115 116 117 118 119
node 0 size: 15602 MB
node 0 free: 14743 MB
node 1 cpus: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 75 76 77 78 79 80 81
82 83 84 85 86 87 88 89
node 1 size: 15985 MB
node 1 free: 15715 MB
node 2 cpus:
node 2 size: 128 MB
node 2 free: 128 MB
node distances:
node 0 1 2
0: 10 21 21
1: 21 10 21
2: 21 21 10
With support of memoryless node enabled, it will correctly report system
hardware topology for nodes without memory installed.
root@bkd01sdp:~# numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 60 61 62 63 64 65 66 67 68 69
70 71 72 73 74
node 0 size: 15725 MB
node 0 free: 15129 MB
node 1 cpus: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 75 76 77 78 79 80 81
82 83 84 85 86 87 88 89
node 1 size: 15862 MB
node 1 free: 15627 MB
node 2 cpus: 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 90 91 92 93 94 95 96
97 98 99 100 101 102 103 104
node 2 size: 0 MB
node 2 free: 0 MB
node 3 cpus: 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 105 106 107 108 109
110 111 112 113 114 115 116 117 118 119
node 3 size: 0 MB
node 3 free: 0 MB
node distances:
node 0 1 2 3
0: 10 21 21 21
1: 21 10 21 21
2: 21 21 10 21
3: 21 21 21 10
With memoryless node enabled, CPUs are correctly associated with node 2
after memory hot-addition to node 2.
root@bkd01sdp:/sys/devices/system/node/node2# numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 60 61 62 63 64 65 66 67 68 69
70 71 72 73 74
node 0 size: 15725 MB
node 0 free: 14872 MB
node 1 cpus: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 75 76 77 78 79 80 81
82 83 84 85 86 87 88 89
node 1 size: 15862 MB
node 1 free: 15641 MB
node 2 cpus: 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 90 91 92 93 94 95 96
97 98 99 100 101 102 103 104
node 2 size: 128 MB
node 2 free: 127 MB
node 3 cpus: 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 105 106 107 108 109
110 111 112 113 114 115 116 117 118 119
node 3 size: 0 MB
node 3 free: 0 MB
node distances:
node 0 1 2 3
0: 10 21 21 21
1: 21 10 21 21
2: 21 21 10 21
3: 21 21 21 10
Signed-off-by: Jiang Liu
---
arch/x86/Kconfig|3 +++
arch/x86/kernel/acpi/boot.c |4 +++-
arch/x86/kernel/smpboot.c |2 ++
arch/x86/mm/numa.c | 49 +++
4 files changed, 44 insertions(+), 14 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b3a1a5d77d92..5d7ad70ace0d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2069,6 +2069,9 @@ config USE_PERCPU_NUMA_NODE_ID
def_bool y
depends on NUMA
+config HAVE_MEMORYLESS_NODES
+ def_bool NUMA
+
config ARCH_ENABLE_SPLIT_PMD_PTLOCK
def_bool y
depends on X86_64 || X86_PAE
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 07930e1d2fe9..3403f1f0f28d 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -711,6 +711,7 @@ static void acpi_map_cpu2node(acpi_handle handle, int cpu,
int physid)
}
set_apicid_to_node(physid, nid);
numa_set_node(cpu, nid);
+ set_cpu_numa_mem(cpu, local_memory_node(nid));
}
#endif
}
@@ -743,9 +744,10 @@ int acpi_unmap_cpu(int cpu)
{
#ifdef CONFIG_ACPI_NUMA
set_apicid_to_node(per_cpu(x86_cpu_to_apicid, cpu), NUMA_NO_NODE);
+ set_cpu_numa_mem(cpu, NUMA_NO_NODE);
#endif
-
[Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
Function xpc_create_gru_mq_uv() allocates memory with __GFP_THISNODE flag set, which may cause permanent memory allocation failure on memoryless node. So replace cpu_to_node() with cpu_to_mem() to better support memoryless node. For node with memory, cpu_to_mem() is the same as cpu_to_node(). Signed-off-by: Jiang Liu --- drivers/misc/sgi-xp/xpc_uv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/sgi-xp/xpc_uv.c b/drivers/misc/sgi-xp/xpc_uv.c index 95c894482fdd..9210981c0d5b 100644 --- a/drivers/misc/sgi-xp/xpc_uv.c +++ b/drivers/misc/sgi-xp/xpc_uv.c @@ -238,7 +238,7 @@ xpc_create_gru_mq_uv(unsigned int mq_size, int cpu, char *irq_name, mq->mmr_blade = uv_cpu_to_blade_id(cpu); - nid = cpu_to_node(cpu); + nid = cpu_to_mem(cpu); page = alloc_pages_exact_node(nid, GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE, pg_order); -- 1.7.10.4 -- 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 V3 0/9] Enable memoryless node support for x86
This is the third version to enable memoryless node support on x86 platforms. The previous version (https://lkml.org/lkml/2014/7/11/75) blindly replaces numa_node_id()/cpu_to_node() with numa_mem_id()/ cpu_to_mem(). That's not the right solution as pointed out by Tejun and Peter due to: 1) We shouldn't shift the burden to normal slab users. 2) Details of memoryless node should be hidden in arch and mm code as much as possible. After digging into more code and documentation, we found the rules to deal with memoryless node should be: 1) Arch code should online corresponding NUMA node before onlining any CPU or memory, otherwise it may cause invalid memory access when accessing NODE_DATA(nid). 2) For normal memory allocations without __GFP_THISNODE setting in the gfp_flags, we should prefer numa_node_id()/cpu_to_node() instead of numa_mem_id()/cpu_to_mem() because the latter loses hardware topology information as pointed out by Tejun: A - B - X - C - D Where X is the memless node. numa_mem_id() on X would return either B or C, right? If B or C can't satisfy the allocation, the allocator would fallback to A from B and D for C, both of which aren't optimal. It should first fall back to C or B respectively, which the allocator can't do anymoe because the information is lost when the caller side performs numa_mem_id(). 3) For memory allocation with __GFP_THISNODE setting in gfp_flags, numa_node_id()/cpu_to_node() should be used if caller only wants to allocate from local memory, otherwise numa_mem_id()/cpu_to_mem() should be used if caller wants to allocate from the nearest node with memory. 4) numa_mem_id()/cpu_to_mem() should be used if caller wants to check whether a page is allocated from the nearest node. Based on above rules, this patch set 1) Patch 1 is a bugfix to resolve a crash caused by socket hot-addition 2) Patch 2 replaces numa_mem_id() with numa_node_id() when __GFP_THISNODE isn't set in gfp_flags. 3) Patch 3-6 replaces numa_node_id()/cpu_to_node() with numa_mem_id()/ cpu_to_mem() if caller wants to allocate from local node only. 4) Patch 7-9 enables support of memoryless node on x86. With this patch set applied, on a system with two sockets enabled at boot, one with memory and the other without memory, we got following numa topology after boot: root@bkd04sdp:~# numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 node 0 size: 15940 MB node 0 free: 15397 MB node 1 cpus: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 node 1 size: 0 MB node 1 free: 0 MB node distances: node 0 1 0: 10 21 1: 21 10 After hot-adding the third socket without memory, we got: root@bkd04sdp:~# numactl --hardware available: 3 nodes (0-2) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 node 0 size: 15940 MB node 0 free: 15142 MB node 1 cpus: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 node 1 size: 0 MB node 1 free: 0 MB node 2 cpus: node 2 size: 0 MB node 2 free: 0 MB node distances: node 0 1 2 0: 10 21 21 1: 21 10 21 2: 21 21 10 Jiang Liu (9): x86, NUMA, ACPI: Online node earlier when doing CPU hot-addition kernel/profile.c: Replace cpu_to_mem() with cpu_to_node() sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node openvswitch: Replace cpu_to_node() with cpu_to_mem() to support memoryless node i40e: Use numa_mem_id() to better support memoryless node i40evf: Use numa_mem_id() to better support memoryless node x86, numa: Kill useless code to improve code readability mm: Update _mem_id_[] for every possible CPU when memory configuration changes mm, x86: Enable memoryless node support to better support CPU/memory hotplug arch/x86/Kconfig |3 ++ arch/x86/kernel/acpi/boot.c |9 +++- arch/x86/kernel/smpboot.c |2 + arch/x86/mm/numa.c| 59 +++-- drivers/misc/sgi-xp/xpc_uv.c |2 +- drivers/net/ethernet/intel/i40e/i40e_txrx.c |2 +- drivers/net/ethernet/intel/i40evf/i40e_txrx.c |2 +- kernel/profile.c |2 +- mm/page_alloc.c | 10 ++--- net/openvswitch/flow.c|2 +- 10 files changed, 59 insertions(+), 34 deletions(-) -- 1.7.10.4 -- 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 V3 7/9] x86, numa: Kill useless code to improve code readability
According to x86 boot sequence, early_cpu_to_node() always returns
NUMA_NO_NODE when called from numa_init(). So kill useless code
to improve code readability.
Related code sequence as below:
x86_cpu_to_node_map is set until step 2, so it is still the default
value (NUMA_NO_NODE) when accessed at step 1.
start_kernel()
setup_arch()
initmem_init()
x86_numa_init()
numa_init()
early_cpu_to_node()
1) return
early_per_cpu_ptr(x86_cpu_to_node_map)[cpu];
acpi_boot_init();
sfi_init()
x86_dtb_init()
generic_processor_info()
early_per_cpu(x86_cpu_to_apicid, cpu) = apicid;
init_cpu_to_node()
numa_set_node(cpu, node);
2) per_cpu(x86_cpu_to_node_map, cpu) = node;
rest_init()
kernel_init()
smp_init()
native_cpu_up()
start_secondary()
numa_set_node()
per_cpu(x86_cpu_to_node_map, cpu) = node;
Signed-off-by: Jiang Liu
---
arch/x86/mm/numa.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 4053bb58bf92..08860bdf5744 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -591,8 +591,6 @@ static void __init numa_init_array(void)
rr = first_node(node_online_map);
for (i = 0; i < nr_cpu_ids; i++) {
- if (early_cpu_to_node(i) != NUMA_NO_NODE)
- continue;
numa_set_node(i, rr);
rr = next_node(rr, node_online_map);
if (rr == MAX_NUMNODES)
@@ -644,14 +642,6 @@ static int __init numa_init(int (*init_func)(void))
if (ret < 0)
return ret;
- for (i = 0; i < nr_cpu_ids; i++) {
- int nid = early_cpu_to_node(i);
-
- if (nid == NUMA_NO_NODE)
- continue;
- if (!node_online(nid))
- numa_clear_node(i);
- }
numa_init_array();
return 0;
--
1.7.10.4
--
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] Revert "drm/nouveau/fifo/gk104: kick channels when deactivating them"
Patch has landed in -rc7, thanks David! On Fri, Aug 14, 2015 at 12:49 PM, Alexandre Courbot wrote: > On Wed, Aug 12, 2015 at 6:59 PM, Afzal Mohammed > wrote: >> Hi, >> >> On Wed, Aug 12, 2015 at 04:40:57PM +0900, Alexandre Courbot wrote: >> >>> Great, thanks. Are you also on an optimus configuration with the >>> NVIDIA card being the secondary GPU? >> >> Spec says graphic processor is NVIDIA GeForce NV14P-GV2 GT40M, system >> is Lenovo E431 laptop. >> >> I am a stranger here, started Kernel journey towards north and reached >> south since the system wasn't booting :), don't know how to find it is >> an optimus configuration, if above details aren't enough, let me know >> how to find out. > > Thanks for the details! > > An optimus configuration means that display and basic acceleration is > provided by an integrated Intel graphics, and the NVIDIA GPU can be > switched on/off dynamically to provide more power when needed. > > According to your laptop reference, this seems to be the kind of > configuration you have. It is relevant because this issue seems to > happen when the NVIDIA GPU is switched off during boot. -- 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 v2 2/3] gadget: Introduce the usb charger framework
On 14 August 2015 at 23:27, Greg KH wrote:
> On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote:
>> This patch introduces the usb charger driver based on usb gadget that
>> makes an enhancement to a power driver. It works well in practice but
>> that requires a system with suitable hardware.
>>
>> The basic conception of the usb charger is that, when one usb charger
>> is added or removed by reporting from the usb gadget state change or
>> the extcon device state change, the usb charger will report to power
>> user to set the current limitation.
>>
>> The usb charger will register notifiees on the usb gadget or the extcon
>> device to get notified the usb charger state.
>>
>> Power user will register a notifiee on the usb charger to get notified
>> by status changes from the usb charger. It will report to power user
>> to set the current limitation when detecting the usb charger is added
>> or removed from extcon device state or usb gadget state.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> drivers/usb/gadget/Kconfig |7 +
>> drivers/usb/gadget/Makefile |1 +
>> drivers/usb/gadget/charger.c| 561
>> +++
>> include/linux/usb/usb_charger.h | 145 ++
>> 4 files changed, 714 insertions(+)
>> create mode 100644 drivers/usb/gadget/charger.c
>> create mode 100644 include/linux/usb/usb_charger.h
>>
>> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
>> index bcf83c0..3d2b959 100644
>> --- a/drivers/usb/gadget/Kconfig
>> +++ b/drivers/usb/gadget/Kconfig
>> @@ -127,6 +127,13 @@ config USB_GADGET_STORAGE_NUM_BUFFERS
>> a module parameter as well.
>> If unsure, say 2.
>>
>> +config USB_CHARGER
>> + bool "USB charger support"
>> + help
>> + The usb charger driver based on the usb gadget that makes an
>> + enhancement to a power driver which can set the current limitation
>> + when the usb charger is added or removed.
>> +
>> source "drivers/usb/gadget/udc/Kconfig"
>>
>> #
>> diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
>> index 598a67d..1e421c1 100644
>> --- a/drivers/usb/gadget/Makefile
>> +++ b/drivers/usb/gadget/Makefile
>> @@ -10,3 +10,4 @@ libcomposite-y := usbstring.o
>> config.o epautoconf.o
>> libcomposite-y += composite.o functions.o configfs.o
>> u_f.o
>>
>> obj-$(CONFIG_USB_GADGET) += udc/ function/ legacy/
>> +obj-$(CONFIG_USB_CHARGER)+= charger.o
>> diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
>> new file mode 100644
>> index 000..f24f7b7
>> --- /dev/null
>> +++ b/drivers/usb/gadget/charger.c
>> @@ -0,0 +1,561 @@
>> +/*
>> + * usb charger.c -- USB charger driver
>
> I think your company also wants a copyright line here. Not that it
> means anything at all, but some lawyers love cargo-cult text blobs.
>
Hi Greg,
Thanks for your reviewing and comments. I'll add it in next patch.
>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>
> I have to ask, do you really mean "any later version"?
>
I think I did not get your point, could you explain it detailedly?
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DEFAULT_CUR_PROTECT (50)
>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_DCP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_CDP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_ACA_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +
>> +static DEFINE_IDA(usb_charger_ida);
>> +static struct bus_type usb_charger_subsys = {
>> + .name = "usb-charger",
>> + .dev_name = "usb-charger",
>> +};
>> +
>> +static struct usb_charger *dev_to_uchger(struct device *udev)
>> +{
>> + return container_of(udev, struct usb_charger, dev);
>> +}
>> +
>> +static ssize_t usb_charger_cur_show(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct usb_charger *uchger = dev_to_uchger(dev);
>> +
>> + return scnprintf(buf, PAGE_SIZE, "%d %d %d %d\n",
>> + uchger->cur_limit.sdp_cur_limit,
>> + uchger->cur_limit.dcp_cur_limit,
>> + uchger->cur_limit.cdp_cur_limit,
>> + uchger->cur_limit.aca_cur_limit);
>> +}
>> +
>> +static ssize_t usb_charger_cur_store(struct device *dev,
>> + struct device_attribute *attr,
>> +
[PATCH V3] regulator: core: Define regulator_set_voltage_triplet()
Voltage tolerance isn't necessarily same on both sides of the target
voltage and regulator_set_voltage_tol() wouldn't be suitable in such
cases.
Add another routine regulator_set_voltage_triplet(), which accepts
target, min and max voltages as arguments.
This first tries to set the voltage between the target voltage and the
upper limit, then fall back on the full range. The idea behind this is
to set regulator's voltage as close to the target voltage, as possible.
Based on regulator_set_voltage_tol().
Signed-off-by: Viresh Kumar
---
V2->V3:
- Improve commit log, with how its useful at regulator API level.
- Compare regulator_set_voltage() == 0, instead of
!regulator_set_voltage().
V1->V2:
- Change the order of arguments to regulator_set_voltage_triplet() to
min/target/max instead of target/min/max.
include/linux/regulator/consumer.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/regulator/consumer.h
b/include/linux/regulator/consumer.h
index f8a689ed62a5..e325d4606b62 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -552,6 +552,16 @@ static inline int regulator_count_voltages(struct
regulator *regulator)
}
#endif
+static inline int regulator_set_voltage_triplet(struct regulator *regulator,
+ int min_uV, int target_uV,
+ int max_uV)
+{
+ if (regulator_set_voltage(regulator, target_uV, max_uV) == 0)
+ return 0;
+
+ return regulator_set_voltage(regulator, min_uV, max_uV);
+}
+
static inline int regulator_set_voltage_tol(struct regulator *regulator,
int new_uV, int tol_uV)
{
--
2.4.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 v4] serial: 8250: Fix autoconfig_irq() to avoid race conditions
The following race conditions can happen when a serial port is used as console. Case1: CPU_B is used to detect an interrupt from a serial port, but it can have interrupts disabled during the waiting time. Case2: CPU_B clears UART_IER just after CPU_A sets UART_IER and then a serial port may not make an interrupt. Case3: CPU_A sets UART_IER just after CPU_B clears UART_IER. This is an unexpected behavior for serial8250_console_write(). CPU_A [autoconfig_irq] | CPU_B [serial8250_console_write] |--- | probe_irq_on() | spin_lock_irqsave(>lock,) serial_outp(,UART_IER,0x0f) | serial_out(,UART_IER,0) udelay(20); | uart_console_write() probe_irq_off() | | spin_unlock_irqrestore(>lock,) Case1 and 2 can make autoconfig_irq() failed. In these cases, the console doesn't work in interrupt mode and "input overrun" (which can make operation mistakes) can happen on some systems. Especially in the Case1, It is known that the problem happens with high rate every boot once it occurs because the boot sequence is always almost same. port mutex makes sure that the autoconfig operation is exclusive of any other concurrent HW access except by the console operation. console lock is required in autoconfig_irq(). Signed-off-by: Taichi Kageyama Cc: Naoya Horiguchi Reviewed-by: Peter Hurley --- Changes in v4: - Rebased on the top of tty-next - The file name was changed from 8250_core.c to 8250_port.c Changes in v3: - Removed RFC tag Changes in v2: - Updated commit log - Rebased on v4.2-rc4 drivers/tty/serial/8250/8250_port.c | 6 ++ 1 file changed, 6 insertions(+) diff --git tty-next.org/drivers/tty/serial/8250/8250_port.c tty-next.work/drivers/tty/serial/8250/8250_port.c index 54e6c8d..9300b59 100644 --- tty-next.org/drivers/tty/serial/8250/8250_port.c +++ tty-next.work/drivers/tty/serial/8250/8250_port.c @@ -1238,6 +1238,9 @@ static void autoconfig_irq(struct uart_8250_port *up) inb_p(ICP); } + if (uart_console(port)) + console_lock(); + /* forget possible initially masked and pending IRQ */ probe_irq_off(probe_irq_on()); save_mcr = serial_in(up, UART_MCR); @@ -1269,6 +1272,9 @@ static void autoconfig_irq(struct uart_8250_port *up) if (port->flags & UPF_FOURPORT) outb_p(save_ICP, ICP); + if (uart_console(port)) + console_unlock(); + port->irq = (irq > 0) ? irq : 0; } -- 2.4.6 -- 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 v2 0/3] Introduce usb charger framework to deal with the usb gadget power negotation
On Fri, Aug 14, 2015 at 07:04:56PM +0800, Baolin Wang wrote: > On 14 August 2015 at 16:55, Li Jun wrote: > > Hi Baolin, > > > > On Fri, Aug 14, 2015 at 05:47:43PM +0800, Baolin Wang wrote: > >> Currently the Linux kernel does not provide any standard integration of > >> this > >> feature that integrates the USB subsystem with the system power regulation > >> provided by PMICs meaning that either vendors must add this in their > >> kernels > >> or USB gadget devices based on Linux (such as mobile phones) may not behave > >> as they should. > >> > >> Providing a standard framework for doing this in the kernel. > >> > > > > Why not add power supply class support into this? > > > > Hi Jun, > > We don't need the power supply class support into the usb charger, I suppose usb charger is also a power supply for the system, we can use power supply class framework for notify mechanism and get/set many attributes(maybe also the current limit), I see those usb charger drivers under ./driver/power/ are designed with power supply supported. Li Jun > just introduce the notify mechanism for power to set the current limit > when notifying some events from usb charger. Maybe I misunderstand > your meanings, please describe it detailedly. Thanks for your > comments. > > > Li Jun > > > > > > -- > Baolin.wang > Best Regards -- 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 v10 1/6] fs: direct-io: don't dirtying pages for ITER_BVEC/ITER_KVEC direct read
When direct read IO is submitted from kernel, it is often
unnecessary to dirty pages, for example of loop, dirtying pages
have been considered in the upper filesystem(over loop) side
already, and they don't need to be dirtied again.
So this patch doesn't dirtying pages for ITER_BVEC/ITER_KVEC
direct read, and loop should be the 1st case to use ITER_BVEC/ITER_KVEC
for direct read I/O.
The patch is based on previous Dave's patch.
Reviewed-by: Dave Kleikamp
Reviewed-by: Christoph Hellwig
Signed-off-by: Ming Lei
---
fs/direct-io.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/direct-io.c b/fs/direct-io.c
index 818c647..cd75b4a 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -120,6 +120,7 @@ struct dio {
int page_errors;/* errno from get_user_pages() */
int is_async; /* is IO async ? */
bool defer_completion; /* defer AIO completion to workqueue? */
+ bool should_dirty; /* if pages should be dirtied */
int io_error; /* IO error in completion path */
unsigned long refcount; /* direct_io_worker() and bios */
struct bio *bio_list; /* singly linked via bi_private */
@@ -393,7 +394,7 @@ static inline void dio_bio_submit(struct dio *dio, struct
dio_submit *sdio)
dio->refcount++;
spin_unlock_irqrestore(>bio_lock, flags);
- if (dio->is_async && dio->rw == READ)
+ if (dio->is_async && dio->rw == READ && dio->should_dirty)
bio_set_pages_dirty(bio);
if (sdio->submit_io)
@@ -464,14 +465,15 @@ static int dio_bio_complete(struct dio *dio, struct bio
*bio)
if (bio->bi_error)
dio->io_error = -EIO;
- if (dio->is_async && dio->rw == READ) {
+ if (dio->is_async && dio->rw == READ && dio->should_dirty) {
bio_check_pages_dirty(bio); /* transfers ownership */
err = bio->bi_error;
} else {
bio_for_each_segment_all(bvec, bio, i) {
struct page *page = bvec->bv_page;
- if (dio->rw == READ && !PageCompound(page))
+ if (dio->rw == READ && !PageCompound(page) &&
+ dio->should_dirty)
set_page_dirty_lock(page);
page_cache_release(page);
}
@@ -1219,6 +1221,7 @@ do_blockdev_direct_IO(struct kiocb *iocb, struct inode
*inode,
spin_lock_init(>bio_lock);
dio->refcount = 1;
+ dio->should_dirty = (iter->type == ITER_IOVEC);
sdio.iter = iter;
sdio.final_block_in_request =
(offset + iov_iter_count(iter)) >> blkbits;
--
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 v10 5/6] block: loop: introduce ioctl command of LOOP_SET_DIRECT_IO
If loop block is mounted via 'mount -o loop', it isn't easy
to pass file descriptor opened as O_DIRECT, so this patch
introduces a new command to support direct IO for this case.
Cc: linux-...@vger.kernel.org
Signed-off-by: Ming Lei
---
drivers/block/loop.c | 19 +++
include/uapi/linux/loop.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 06cad7e..75db3b9 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1228,6 +1228,20 @@ static int loop_set_capacity(struct loop_device *lo,
struct block_device *bdev)
return figure_loop_size(lo, lo->lo_offset, lo->lo_sizelimit);
}
+static int loop_set_dio(struct loop_device *lo, unsigned long arg)
+{
+ int error = -ENXIO;
+ if (lo->lo_state != Lo_bound)
+ goto out;
+
+ __loop_update_dio(lo, !!arg);
+ if (lo->use_dio == !!arg)
+ return 0;
+ error = -EINVAL;
+ out:
+ return error;
+}
+
static int lo_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
{
@@ -1271,6 +1285,11 @@ static int lo_ioctl(struct block_device *bdev, fmode_t
mode,
if ((mode & FMODE_WRITE) || capable(CAP_SYS_ADMIN))
err = loop_set_capacity(lo, bdev);
break;
+ case LOOP_SET_DIRECT_IO:
+ err = -EPERM;
+ if ((mode & FMODE_WRITE) || capable(CAP_SYS_ADMIN))
+ err = loop_set_dio(lo, arg);
+ break;
default:
err = lo->ioctl ? lo->ioctl(lo, cmd, arg) : -EINVAL;
}
diff --git a/include/uapi/linux/loop.h b/include/uapi/linux/loop.h
index 949851c..c8125ec 100644
--- a/include/uapi/linux/loop.h
+++ b/include/uapi/linux/loop.h
@@ -87,6 +87,7 @@ struct loop_info64 {
#define LOOP_GET_STATUS64 0x4C05
#define LOOP_CHANGE_FD 0x4C06
#define LOOP_SET_CAPACITY 0x4C07
+#define LOOP_SET_DIRECT_IO 0x4C08
/* /dev/loop-control interface */
#define LOOP_CTL_ADD 0x4C80
--
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 v10 3/6] block: loop: use kthread_work
The following patch will use dio/aio to submit IO to backing file,
then it needn't to schedule IO concurrently from work, so
use kthread_work for decreasing context switch cost a lot.
For non-AIO case, single thread has been used for long long time,
and it was just converted to work in v4.0, which has caused performance
regression for fedora live booting already. In discussion[1], even
though submitting I/O via work concurrently can improve random read IO
throughput, meantime it might hurt sequential read IO performance, so
better to restore to single thread behaviour.
For the following AIO support, it is better to use multi hw-queue
with per-hwq kthread than current work approach suppose there is so
high performance requirement for loop.
[1] http://marc.info/?t=14308267842=1=2
Signed-off-by: Ming Lei
---
drivers/block/loop.c | 79
drivers/block/loop.h | 10 +++
2 files changed, 28 insertions(+), 61 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index eee7510..1875aad 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -688,6 +688,23 @@ static void loop_config_discard(struct loop_device *lo)
queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, q);
}
+static void loop_unprepare_queue(struct loop_device *lo)
+{
+ flush_kthread_worker(>worker);
+ kthread_stop(lo->worker_task);
+}
+
+static int loop_prepare_queue(struct loop_device *lo)
+{
+ init_kthread_worker(>worker);
+ lo->worker_task = kthread_run(kthread_worker_fn,
+ >worker, "loop%d", lo->lo_number);
+ if (IS_ERR(lo->worker_task))
+ return -ENOMEM;
+ set_user_nice(lo->worker_task, MIN_NICE);
+ return 0;
+}
+
static int loop_set_fd(struct loop_device *lo, fmode_t mode,
struct block_device *bdev, unsigned int arg)
{
@@ -745,11 +762,8 @@ static int loop_set_fd(struct loop_device *lo, fmode_t
mode,
size = get_loop_size(lo, file);
if ((loff_t)(sector_t)size != size)
goto out_putf;
- error = -ENOMEM;
- lo->wq = alloc_workqueue("kloopd%d",
- WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 16,
- lo->lo_number);
- if (!lo->wq)
+ error = loop_prepare_queue(lo);
+ if (error)
goto out_putf;
error = 0;
@@ -903,8 +917,7 @@ static int loop_clr_fd(struct loop_device *lo)
lo->lo_flags = 0;
if (!part_shift)
lo->lo_disk->flags |= GENHD_FL_NO_PART_SCAN;
- destroy_workqueue(lo->wq);
- lo->wq = NULL;
+ loop_unprepare_queue(lo);
mutex_unlock(>lo_ctl_mutex);
/*
* Need not hold lo_ctl_mutex to fput backing file.
@@ -1461,23 +1474,7 @@ static int loop_queue_rq(struct blk_mq_hw_ctx *hctx,
if (lo->lo_state != Lo_bound)
return -EIO;
- if (cmd->rq->cmd_flags & REQ_WRITE) {
- struct loop_device *lo = cmd->rq->q->queuedata;
- bool need_sched = true;
-
- spin_lock_irq(>lo_lock);
- if (lo->write_started)
- need_sched = false;
- else
- lo->write_started = true;
- list_add_tail(>list, >write_cmd_head);
- spin_unlock_irq(>lo_lock);
-
- if (need_sched)
- queue_work(lo->wq, >write_work);
- } else {
- queue_work(lo->wq, >read_work);
- }
+ queue_kthread_work(>worker, >work);
return BLK_MQ_RQ_QUEUE_OK;
}
@@ -1499,35 +1496,10 @@ static void loop_handle_cmd(struct loop_cmd *cmd)
blk_mq_complete_request(cmd->rq);
}
-static void loop_queue_write_work(struct work_struct *work)
-{
- struct loop_device *lo =
- container_of(work, struct loop_device, write_work);
- LIST_HEAD(cmd_list);
-
- spin_lock_irq(>lo_lock);
- repeat:
- list_splice_init(>write_cmd_head, _list);
- spin_unlock_irq(>lo_lock);
-
- while (!list_empty(_list)) {
- struct loop_cmd *cmd = list_first_entry(_list,
- struct loop_cmd, list);
- list_del_init(>list);
- loop_handle_cmd(cmd);
- }
-
- spin_lock_irq(>lo_lock);
- if (!list_empty(>write_cmd_head))
- goto repeat;
- lo->write_started = false;
- spin_unlock_irq(>lo_lock);
-}
-
-static void loop_queue_read_work(struct work_struct *work)
+static void loop_queue_work(struct kthread_work *work)
{
struct loop_cmd *cmd =
- container_of(work, struct loop_cmd, read_work);
+ container_of(work, struct loop_cmd, work);
loop_handle_cmd(cmd);
}
@@ -1539,7 +1511,7 @@ static int loop_init_request(void *data, struct request
*rq,
struct loop_cmd *cmd = blk_mq_rq_to_pdu(rq);
cmd->rq = rq;
-
[PATCH v10 2/6] block: loop: set QUEUE_FLAG_NOMERGES for request queue of loop
It doesn't make sense to enable merge because the I/O submitted to backing file is handled page by page. Signed-off-by: Ming Lei --- drivers/block/loop.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index f9889b6..eee7510 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1595,6 +1595,12 @@ static int loop_add(struct loop_device **l, int i) } lo->lo_queue->queuedata = lo; + /* +* It doesn't make sense to enable merge because the I/O +* submitted to backing file is handled page by page. +*/ + queue_flag_set_unlocked(QUEUE_FLAG_NOMERGES, lo->lo_queue); + INIT_LIST_HEAD(>write_cmd_head); INIT_WORK(>write_work, loop_queue_write_work); -- 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 v10 0/6] block: loop: improve loop with AIO
Hi Guys, There are about 3 advantages to use direct I/O and AIO on read/write loop's backing file: 1) double cache can be avoided, then memory usage gets decreased a lot 2) not like user space direct I/O, there isn't cost of pinning pages 3) avoid context switch for obtaining good throughput - in buffered file read, random I/O throughput is often obtained only if they are submitted concurrently from lots of tasks; but for sequential I/O, most of times they can be hit from page cache, so concurrent submissions often introduce unnecessary context switch and can't improve throughput much. There was such discussion[1] to use non-blocking I/O to improve the problem for application. - with direct I/O and AIO, concurrent submissions can be avoided and random read throughput can't be affected meantime So this patchset trys to improve loop via AIO, and about 45% memory usage can be decreased, see detailed data in commit log of patch6, also IO throughput gets a bit improved too. Following losetup changes for supporting loop dio/aio: - losetup git tree: http://kernel.ubuntu.com/git/ming/util-linux.git/log/?h=loop-dio-v7 - how to set direct io losetup --direct-io 1 /dev/loopN - how to clear direct io losetup --direct-io 0 /dev/loopN - how to show if direct io is used for accessing backing file losetup -l V10: - only 4/6 and 6/6 updated - don't switch to direct I/O runtime as required by Christoph Hellwig - move check of ->transfer into loop settup from I/O path - check aligment using backing device's logical block size instead of min I/O size - run tests against 4.2-rc6-next-20150814 - run xfstests over loop/ext4 with direct I/O, and passed V9: - only 4/6 and 5/6 updated - update __loop_update_dio() - serialize direct I/O with buffered I/O for avoiding possible race V8: - only 4/6 and 5/6 updated - support direct io when backing device's sector size is 512, 1024, 2048 and 4096(only 512-byte sector was supported in V7) V7: - only 4/6 and 5/6 updated - update direct io after lo->offset is changed(4/6) - fix updating LO_FLAGS_DIRECT_IO in __loop_update_dio()(4/6) - introduce ioctl cmd of LOOP_SET_DIRECT_IO(5/6) for case of 'mount -o loop' V6: - only patch 4 and patch 5 get updated - check lo->lo_offset to decide if direct IO can be supported(4/5) - introduce one flag for userspace(losetup) to keep updated if using direct I/O to access backing file(4/5) - implement patches for util-linux(losetup) so that losetup can enable direct I/O feature:(4/5) http://kernel.ubuntu.com/git/ming/util-linux.git/log/?h=losetup-dio - remove the direct IO control interface from sysfs(4/5) - handle partial read in case of direct read (5/5) - add more comments for direct IO (5/5) V5: - don't introduce IOCB_DONT_DIRTY_PAGE and bypass dirtying for ITER_KVEC and ITER_BVEC direct IO(read), as required by Christoph V4: - add detailed commit log for 'use kthread_work' - allow userspace(sysfs, losetup) to decide if dio/aio is used as suggested by Christoph and Dave Chinner - only use dio if the backing block device's min io size is 512 as pointed by Dave Chinner & Christoph V3: - based on Al's iov_iter work and Christoph's kiocb changes - use kthread_work - introduce IOCB_DONT_DIRTY_PAGE flag - set QUEUE_FLAG_NOMERGES for loop's request queue V2: - remove 'extra' parameter to aio_kernel_alloc() - try to avoid memory allcation inside queue req callback - introduce 'use_mq' sysfs file for enabling kernel aio or disabling it V1: - link: http://marc.info/?t=14080315774=1=2 - improve failure path in aio_kernel_submit() drivers/block/loop.c | 275 - drivers/block/loop.h | 13 +-- fs/direct-io.c| 9 +- include/uapi/linux/loop.h | 2 + 4 files changed, 234 insertions(+), 65 deletions(-) Thanks, Ming -- 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 v10 4/6] block: loop: prepare for supporing direct IO
This patches provides one interface for enabling direct IO
from user space:
- userspace(such as losetup) can pass 'file' which is
opened/fcntl as O_DIRECT
Also __loop_update_dio() is introduced to check if direct I/O
can be used on current loop setting.
The last big change is to introduce LO_FLAGS_DIRECT_IO flag
for userspace to know if direct IO is used to access backing
file.
Cc: linux-...@vger.kernel.org
Signed-off-by: Ming Lei
---
drivers/block/loop.c | 77 +++
drivers/block/loop.h | 1 +
include/uapi/linux/loop.h | 1 +
3 files changed, 79 insertions(+)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 1875aad..06cad7e 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -164,6 +164,62 @@ static loff_t get_loop_size(struct loop_device *lo, struct
file *file)
return get_size(lo->lo_offset, lo->lo_sizelimit, file);
}
+static void __loop_update_dio(struct loop_device *lo, bool dio)
+{
+ struct file *file = lo->lo_backing_file;
+ struct address_space *mapping = file->f_mapping;
+ struct inode *inode = mapping->host;
+ unsigned short sb_bsize = 0;
+ unsigned dio_align = 0;
+ bool use_dio;
+
+ if (inode->i_sb->s_bdev) {
+ sb_bsize = bdev_logical_block_size(inode->i_sb->s_bdev);
+ dio_align = sb_bsize - 1;
+ }
+
+ /*
+* We support direct I/O only if lo_offset is aligned with the
+* logical I/O size of backing device, and the logical block
+* size of loop is bigger than the backing device's and the loop
+* needn't transform transfer.
+*
+* TODO: the above condition may be loosed in the future, and
+* direct I/O may be switched runtime at that time because most
+* of requests in sane appplications should be PAGE_SIZE algined
+*/
+ if (dio) {
+ if (queue_logical_block_size(lo->lo_queue) >= sb_bsize &&
+ !(lo->lo_offset & dio_align) &&
+ mapping->a_ops->direct_IO &&
+ !lo->transfer)
+ use_dio = true;
+ else
+ use_dio = false;
+ } else {
+ use_dio = false;
+ }
+
+ if (lo->use_dio == use_dio)
+ return;
+
+ /* flush dirty pages before changing direct IO */
+ vfs_fsync(file, 0);
+
+ /*
+* The flag of LO_FLAGS_DIRECT_IO is handled similarly with
+* LO_FLAGS_READ_ONLY, both are set from kernel, and losetup
+* will get updated by ioctl(LOOP_GET_STATUS)
+*/
+ blk_mq_freeze_queue(lo->lo_queue);
+ lo->use_dio = use_dio;
+ if (use_dio)
+ lo->lo_flags |= LO_FLAGS_DIRECT_IO;
+ else
+ lo->lo_flags &= ~LO_FLAGS_DIRECT_IO;
+ blk_mq_unfreeze_queue(lo->lo_queue);
+}
+
static int
figure_loop_size(struct loop_device *lo, loff_t offset, loff_t sizelimit)
{
@@ -421,6 +477,12 @@ struct switch_request {
struct completion wait;
};
+static inline void loop_update_dio(struct loop_device *lo)
+{
+ __loop_update_dio(lo, io_is_direct(lo->lo_backing_file) |
+ lo->use_dio);
+}
+
/*
* Do the actual switch; called from the BIO completion routine
*/
@@ -441,6 +503,7 @@ static void do_loop_switch(struct loop_device *lo, struct
switch_request *p)
mapping->host->i_bdev->bd_block_size : PAGE_SIZE;
lo->old_gfp_mask = mapping_gfp_mask(mapping);
mapping_set_gfp_mask(mapping, lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS));
+ loop_update_dio(lo);
}
/*
@@ -627,11 +690,19 @@ static ssize_t loop_attr_partscan_show(struct loop_device
*lo, char *buf)
return sprintf(buf, "%s\n", partscan ? "1" : "0");
}
+static ssize_t loop_attr_dio_show(struct loop_device *lo, char *buf)
+{
+ int dio = (lo->lo_flags & LO_FLAGS_DIRECT_IO);
+
+ return sprintf(buf, "%s\n", dio ? "1" : "0");
+}
+
LOOP_ATTR_RO(backing_file);
LOOP_ATTR_RO(offset);
LOOP_ATTR_RO(sizelimit);
LOOP_ATTR_RO(autoclear);
LOOP_ATTR_RO(partscan);
+LOOP_ATTR_RO(dio);
static struct attribute *loop_attrs[] = {
_attr_backing_file.attr,
@@ -639,6 +710,7 @@ static struct attribute *loop_attrs[] = {
_attr_sizelimit.attr,
_attr_autoclear.attr,
_attr_partscan.attr,
+ _attr_dio.attr,
NULL,
};
@@ -770,6 +842,7 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode,
set_device_ro(bdev, (lo_flags & LO_FLAGS_READ_ONLY) != 0);
+ lo->use_dio = false;
lo->lo_blocksize = lo_blocksize;
lo->lo_device = bdev;
lo->lo_flags = lo_flags;
@@ -783,6 +856,7 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode,
if (!(lo_flags & LO_FLAGS_READ_ONLY) && file->f_op->fsync)
blk_queue_flush(lo->lo_queue, REQ_FLUSH);
[PATCH v10 6/6] block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-
test cases |randread |read |randwrite |write |
-
base|8015 |113811 |67442 |106978
-
base+loop aio |8136 |125040 |67811 |111376
-
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-
| Buffers | Cached
-
base | > 760MB | ~950MB
-
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei
---
drivers/block/loop.c | 98 ++--
drivers/block/loop.h | 2 ++
2 files changed, 97 insertions(+), 3 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 75db3b9..2337608 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -445,6 +445,90 @@ static int lo_req_flush(struct loop_device *lo, struct
request *rq)
return ret;
}
+static inline void handle_partial_read(struct loop_cmd *cmd, long bytes)
+{
+ if (bytes < 0 || (cmd->rq->cmd_flags & REQ_WRITE))
+ return;
+
+ if (unlikely(bytes < blk_rq_bytes(cmd->rq))) {
+ struct bio *bio = cmd->rq->bio;
+
+ bio_advance(bio, bytes);
+ zero_fill_bio(bio);
+ }
+}
+
+static void lo_rw_aio_complete(struct kiocb *iocb, long ret, long ret2)
+{
+ struct loop_cmd *cmd = container_of(iocb, struct loop_cmd, iocb);
+ struct request *rq = cmd->rq;
+
+ handle_partial_read(cmd, ret);
+
+ if (ret > 0)
+ ret = 0;
+ else if (ret < 0)
+ ret = -EIO;
+
+ rq->errors = ret;
+ blk_mq_complete_request(rq);
+}
+
+static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd,
+loff_t pos, bool rw)
+{
+ struct iov_iter iter;
+ struct bio_vec *bvec;
+ struct bio *bio = cmd->rq->bio;
+ struct file *file = lo->lo_backing_file;
+ int ret;
+
+ /* nomerge for loop request queue */
+ WARN_ON(cmd->rq->bio != cmd->rq->biotail);
+
+ bvec = __bvec_iter_bvec(bio->bi_io_vec, bio->bi_iter);
+ iov_iter_bvec(, ITER_BVEC | rw, bvec,
+ bio_segments(bio), blk_rq_bytes(cmd->rq));
+
+ cmd->iocb.ki_pos = pos;
+ cmd->iocb.ki_filp = file;
+ cmd->iocb.ki_complete = lo_rw_aio_complete;
+ cmd->iocb.ki_flags = IOCB_DIRECT;
+
+ if (rw == WRITE)
+ ret = file->f_op->write_iter(>iocb, );
+ else
+ ret = file->f_op->read_iter(>iocb, );
+
+ if (ret != -EIOCBQUEUED)
+ cmd->iocb.ki_complete(>iocb, ret, 0);
+ return 0;
Re: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register
On 08/17/2015 11:00 AM, Krzysztof Kozlowski wrote:
> On 17.08.2015 10:47, Joonyoung Shim wrote:
>> Hi,
>>
>> On 08/13/2015 07:02 PM, Krzysztof Kozlowski wrote:
>>> W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
According to datasheet, the S2MPS13X and S2MPS14X should update write
buffer via setting WUDR bit to high after ctrl register is updated.
>>>
>>> Hi,
>>>
>>> I cannot find this information in S2MPS14 datasheet. On which page is it?
>>>
>>
>> I got below information from S2MPS14_Data Sheet_REV0.1 document.
>>
>> 5.2.2.3 RTC_UPDATE
>> ...
>>
>> NOTE:
>> 1. For write Time Registers (0x00, 0x04~0x0A) & Alarm 0&1 Registers
>> (0x0B~0x18), set WUDR bit to high.
>
> Right, I have too but it does not say anything about control register.
> It mentions only time, alarm 0 and alarm 1 registers, not control.
>
Address 0x00 is RTC_CTRL, so i don't know what you say.
>>
>>>
If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
tools/testing/selftests/timers/rtctest.c test program and hour format is
used to 12 hour mode in Odroid-XU3 board.
>>>
>>> Two questions here:
>>> 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
>>> Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
>>> S2MP14)? There are some minor differences between them so I would not be
>>> surprised if only some of them required this action.
>>>
>>
>> I'm not sure about that because i don't have S2MPS11 datasheet. I just
>> got the information that S2MPS11 also use S2MPS14 rtc from sec-core mfd
>> driver,
>
> Yeah, I added it. But these RTC modules are slightly different,
> especially S2MPS14, so you cannot assume that they are the same after
> looking at mainline code.
>
OK, could you check this issue from different things?
Thanks.
>>
>> static const struct mfd_cell s2mps11_devs[] = {
>>
>> {
>>
>> .name = "s2mps11-pmic",
>>
>> }, {
>>
>> .name = "s2mps14-rtc",
>>
>> }, {
>>
>> .name = "s2mps11-clk",
>>
>> .of_compatible = "samsung,s2mps11-clk",
>>
>> }
>>
>> };
>>
>>> 2. The driver operates in 24-hour omode. Actually it sets the 24-hour
>>> mode just before your new regmap_update_bits() call. What do you mean by
>>> 12-hour mode?
>>>
>>
>> RTC_CTRL register value is 0 until write buffer is updated, so it is
>> used to 12-hour mode.
>
> I mean what do you have in mind by saying:
> "... and hour format is used to 12 hour mode in Odroid-XU3 board."
> The hour format is set by driver to 24h mode.
>
>
>>
Signed-off-by: Joonyoung Shim
Cc:
>>>
>>> Thanks for putting a cc-stable tag. How far this should be ported? If
>>> this is needed only for S2MPS11 then v4.1. If all of them then probably
>>> for earlier version?
>>>
>>
>> If find exact version, i think it will be a version after below commit
>> was applied.
>>
>> The commit 0c5deb1ea92f("rtc: s5m: add support for S2MPS14 RTC")
>>
>> $ git name-rev 0c5deb1ea92f
>> 0c5deb1ea92f tags/v3.16-rc1~53^2~1
>
> Hmmm... I am not against the patch (especially that it matches source
> code of SM-G900H with S2MPS11) but I have doubts about affected
> chipsets. My Odroid (probably because of bootloader), S2MPS13 and
> S2MPS14 do not need it. This confuses me...
>
> Best regards,
> Krzysztof
>
>>
>> Thanks.
>>
>>> Best regards,
>>> Krzysztof
>>>
---
drivers/rtc/rtc-s5m.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 8c70d78..03828bb 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info
*info)
case S2MPS13X:
data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
+ if (ret < 0)
+ break;
+
+ ret = regmap_update_bits(info->regmap,
+ info->regs->rtc_udr_update,
+ info->regs->rtc_udr_mask,
+
Re: linux-next: manual merge of the thermal-soc tree with the arm tree
On 17-08-15, 12:17, Stephen Rothwell wrote:
> Hi Eduardo,
>
> Today's linux-next merge of the thermal-soc tree got a conflict in:
>
> drivers/thermal/cpu_cooling.c
>
> between commit:
>
> df6f527755a5 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")
>
> from the arm tree and commits:
>
> 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")
> a24af233a1fd ("thermal/cpu_cooling: convert 'switch' block to 'if' block in
> notifier")
>
> from the thermal-soc tree.
>
> I fixed it up (the first two look like two versions of the same patch,
> so I used the version from the thermal-soc tree) and can carry the fix
> as necessary (no action is required).
Right the version from the thermal tree is the updated version and
should be picked.
> Russell: that commit in your tree has no Signed-off-by :-(
No. It does have a SOB, but that followed a bit of rant/history on why
Russell carried this patch :)
Russell should be dropping that patch soon, AFAIU.
--
viresh
--
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] regulator: core: Define regulator_set_voltage_triplet()
On 15-08-15, 07:08, Mark Brown wrote:
> On Sat, Aug 15, 2015 at 08:41:49AM +0530, Viresh Kumar wrote:
>
> > Hopefully below version looks better ?
>
> Please don't bury patches at the end of replies to messages in the
> middle of threads, send them in a form where they can be applied
> directly.
Okay. I thought its fine to send patches like this and this can be
applied directly with the --scissors option to git am or with
mailinfo.scissors option set in configuration file.
But will surely send patches separately to you.
> > Subject: [PATCH] regulator: core: Define regulator_set_voltage_triplet()
> >
> > The OPP (Operating performance points) v2 bindings allows regulator
> > voltage to be supplied as a triplet of voltages.
> >
> > Add regulator_set_voltage_triplet() API in regulator core to support
> > that.
>
> This should explain why this is useful at a regulator API level, not
> explain that some user decided to do something.
Okay.
> > +static inline int regulator_set_voltage_triplet(struct regulator
> > *regulator,
> > + int min_uV, int target_uV,
> > + int max_uV)
> > +{
> > + if (!regulator_set_voltage(regulator, target_uV, max_uV))
>
> Make this a check for == 0 which is what you mean here, this isn't a
> boolean function.
Okay.
--
viresh
--
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 v2 3/3] power: wm831x_power: Support USB charger current limit management
On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote:
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
>
> Signed-off-by: Mark Brown
> Signed-off-by: Baolin Wang
> ---
> drivers/power/wm831x_power.c | 69
> ++
> include/linux/mfd/wm831x/pdata.h |3 ++
> 2 files changed, 72 insertions(+)
>
> diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
> index db11ae6..72c661f 100644
> --- a/drivers/power/wm831x_power.c
> +++ b/drivers/power/wm831x_power.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -31,6 +32,8 @@ struct wm831x_power {
> char usb_name[20];
> char battery_name[20];
> bool have_battery;
> + struct usb_charger *usb_charger;
> + struct notifier_block usb_notify;
> };
>
> static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> @@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
> POWER_SUPPLY_PROP_VOLTAGE_NOW,
> };
>
> +/* In miliamps */
> +static unsigned int wm831x_usb_limits[] = {
> + 0,
> + 2,
> + 100,
> + 500,
> + 900,
> + 1500,
> + 1800,
> + 550,
> +};
Why 550 is the last, but not 1800?
> +
> +static int wm831x_usb_limit_change(struct notifier_block *nb,
> +unsigned long limit, void *data)
> +{
> + struct wm831x_power *wm831x_power = container_of(nb,
> + struct wm831x_power,
> + usb_notify);
> + int i, best;
> +
> + /* Find the highest supported limit */
> + best = 0;
> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
> + if (limit < wm831x_usb_limits[i] &&
> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
> + best = i;
> + }
> +
> + dev_dbg(wm831x_power->wm831x->dev,
> + "Limiting USB current to %dmA", wm831x_usb_limits[best]);
> +
> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
> + WM831X_USB_ILIM_MASK, best);
> +
> + return 0;
> +}
> +
> /*
> * Battery properties
> */
> @@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device
> *pdev)
> }
> }
>
> + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
Where the wm831x_pdata->usb_gadget is initialized?
> + power->usb_charger =
> + usb_charger_find_by_name(wm831x_pdata->usb_gadget);
> + if (IS_ERR(power->usb_charger)) {
> + ret = PTR_ERR(power->usb_charger);
> + dev_err(>dev,
> + "Failed to find USB gadget: %d\n", ret);
> + goto err_bat_irq;
> + }
> +
> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
> +
> + ret = usb_charger_register_notify(power->usb_charger,
> + >usb_notify);
> + if (ret != 0) {
> + dev_err(>dev,
> + "Failed to register notifier: %d\n", ret);
> + goto err_usb_charger;
> + }
> + }
> +
> return ret;
>
> +err_usb_charger:
> + usb_charger_put(power->usb_charger);
> err_bat_irq:
> --i;
> for (; i >= 0; i--) {
> @@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device
> *pdev)
> struct wm831x *wm831x = wm831x_power->wm831x;
> int irq, i;
>
> + if (wm831x_power->usb_charger) {
> + usb_charger_unregister_notify(wm831x_power->usb_charger,
> + _power->usb_notify);
> + usb_charger_put(wm831x_power->usb_charger);
> + }
> +
> for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
> irq = wm831x_irq(wm831x,
>platform_get_irq_byname(pdev,
> diff --git a/include/linux/mfd/wm831x/pdata.h
> b/include/linux/mfd/wm831x/pdata.h
> index dcc9631..5af8399 100644
> --- a/include/linux/mfd/wm831x/pdata.h
> +++ b/include/linux/mfd/wm831x/pdata.h
> @@ -126,6 +126,9 @@ struct wm831x_pdata {
> /** The driver should initiate a power off sequence during shutdown */
> bool soft_shutdown;
>
> + /** dev_name of USB charger gadget to integrate with */
> + const char *usb_gadget;
> +
> int irq_base;
> int gpio_base;
> int gpio_defaults[WM831X_GPIO_NUM];
> --
> 1.7.9.5
>
linux-next: manual merge of the thermal-soc tree with the arm tree
Hi Eduardo,
Today's linux-next merge of the thermal-soc tree got a conflict in:
drivers/thermal/cpu_cooling.c
between commit:
df6f527755a5 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")
from the arm tree and commits:
02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")
a24af233a1fd ("thermal/cpu_cooling: convert 'switch' block to 'if' block in
notifier")
from the thermal-soc tree.
I fixed it up (the first two look like two versions of the same patch,
so I used the version from the thermal-soc tree) and can carry the fix
as necessary (no action is required).
Russell: that commit in your tree has no Signed-off-by :-(
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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 4/4] ARM: dts: Add MSHC2 dt node for Exynos3250 SoC
On 11.08.2015 12:46, Chanwoo Choi wrote: > This patch add the MSHC2 (Mobile Storage Host Controller) devicetree node for > Exynos3250 SoC. s/add/adds/ s/devicetree/Device Tree/ > > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 35 > +++ > arch/arm/boot/dts/exynos3250.dtsi | 13 > 2 files changed, 48 insertions(+) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 3/4] ARM: dts: Add UART2 dt node for Exynos3250 SoC
On 11.08.2015 12:46, Chanwoo Choi wrote: > This patch add the uart2 devicetree node for Exynos3250 SoC. "This patch adds the UART2 Device Tree node..." > > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 7 +++ > arch/arm/boot/dts/exynos3250.dtsi | 12 > 2 files changed, 19 insertions(+) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 v2 1/3] gadget: Support for the usb charger framework
On 17 August 2015 at 08:40, Peter Chen wrote:
> On Fri, Aug 14, 2015 at 05:47:44PM +0800, Baolin Wang wrote:
>> The usb charger framework is based on usb gadget, and each usb gadget
>> can be one usb charger to set the current limitation.
>>
>> This patch adds a notifier mechanism for usb charger to report to usb
>> charger when the usb gadget state is changed.
>>
>> Also we introduce a callback 'get_charger_type' which will implemented
>> by user for usb gadget operations to get the usb charger type.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> drivers/usb/gadget/udc/udc-core.c | 38
>> +
>> include/linux/usb/gadget.h| 20 +++
>> 2 files changed, 58 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/udc/udc-core.c
>> b/drivers/usb/gadget/udc/udc-core.c
>> index f660afb..47b231c 100644
>> --- a/drivers/usb/gadget/udc/udc-core.c
>> +++ b/drivers/usb/gadget/udc/udc-core.c
>> @@ -28,6 +28,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /**
>> * struct usb_udc - describes one usb device controller
>> @@ -129,6 +130,32 @@ void usb_gadget_giveback_request(struct usb_ep *ep,
>> }
>> EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
>>
>> +int usb_gadget_register_notify(struct usb_gadget *gadget,
>> +struct notifier_block *nb)
>> +{
>> + int ret;
>> +
>> + mutex_lock(>lock);
>> + ret = raw_notifier_chain_register(>nh, nb);
>> + mutex_unlock(>lock);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_gadget_register_notify);
>> +
>> +int usb_gadget_unregister_notify(struct usb_gadget *gadget,
>> + struct notifier_block *nb)
>> +{
>> + int ret;
>> +
>> + mutex_lock(>lock);
>> + ret = raw_notifier_chain_unregister(>nh, nb);
>> + mutex_unlock(>lock);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_gadget_unregister_notify);
>> +
>> /*
>> - */
>>
>> /**
>> @@ -226,6 +253,10 @@ static void usb_gadget_state_work(struct work_struct
>> *work)
>> struct usb_gadget *gadget = work_to_gadget(work);
>> struct usb_udc *udc = gadget->udc;
>>
>> + mutex_lock(>lock);
>> + raw_notifier_call_chain(>nh, gadget->state, gadget);
>> + mutex_unlock(>lock);
>> +
>> if (udc)
>> sysfs_notify(>dev.kobj, NULL, "state");
>> }
>> @@ -364,6 +395,8 @@ int usb_add_gadget_udc_release(struct device *parent,
>> struct usb_gadget *gadget,
>>
>> dev_set_name(>dev, "gadget");
>> INIT_WORK(>work, usb_gadget_state_work);
>> + RAW_INIT_NOTIFIER_HEAD(>nh);
>> + mutex_init(>lock);
>> gadget->dev.parent = parent;
>>
>> #ifdef CONFIG_HAS_DMA
>> @@ -405,6 +438,10 @@ int usb_add_gadget_udc_release(struct device *parent,
>> struct usb_gadget *gadget,
>>
>> mutex_unlock(_lock);
>>
>> + ret = usb_charger_init(gadget);
>> + if (ret)
>> + goto err4;
>> +
>
> If the charger's initialization fails, you may need to
> call device_del(>dev).
>
Yes, I missed that. Thanks for your comments.
> Peter
>
>> return 0;
>>
>> err4:
>> @@ -481,6 +518,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
>> kobject_uevent(>dev.kobj, KOBJ_REMOVE);
>> flush_work(>work);
>> device_unregister(>dev);
>> + usb_charger_exit(gadget);
>> device_unregister(>dev);
>> }
>> EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
>> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> index c14a69b..78cc862 100644
>> --- a/include/linux/usb/gadget.h
>> +++ b/include/linux/usb/gadget.h
>> @@ -537,6 +537,7 @@ struct usb_gadget_ops {
>> struct usb_ep *(*match_ep)(struct usb_gadget *,
>> struct usb_endpoint_descriptor *,
>> struct usb_ss_ep_comp_descriptor *);
>> + enum usb_charger_type (*get_charger_type)(struct usb_gadget *);
>> };
>>
>> /**
>> @@ -609,6 +610,9 @@ struct usb_gadget {
>> unsignedout_epnum;
>> unsignedin_epnum;
>> struct usb_otg_caps *otg_caps;
>> + struct raw_notifier_headnh;
>> + struct usb_charger *uchger;
>> + struct mutexlock;
>>
>> unsignedsg_supported:1;
>> unsignedis_otg:1;
>> @@ -1183,6 +1187,22 @@ extern void usb_gadget_unmap_request(struct
>> usb_gadget *gadget,
>>
>>
>> /*-*/
>>
>> +/**
>> + * Register a notifiee to get notified by any attach status changes from
>> + * the usb gadget
>> + */
>> +int usb_gadget_register_notify(struct usb_gadget *gadget,
>> +struct notifier_block *nb);
>> +
>> +/*-*/
>> +
>> +
>> +/* Unregister a notifiee from
Re: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register
On 17.08.2015 10:47, Joonyoung Shim wrote:
> Hi,
>
> On 08/13/2015 07:02 PM, Krzysztof Kozlowski wrote:
>> W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
>>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>>> buffer via setting WUDR bit to high after ctrl register is updated.
>>
>> Hi,
>>
>> I cannot find this information in S2MPS14 datasheet. On which page is it?
>>
>
> I got below information from S2MPS14_Data Sheet_REV0.1 document.
>
> 5.2.2.3 RTC_UPDATE
> ...
>
> NOTE:
> 1. For write Time Registers (0x00, 0x04~0x0A) & Alarm 0&1 Registers
> (0x0B~0x18), set WUDR bit to high.
Right, I have too but it does not say anything about control register.
It mentions only time, alarm 0 and alarm 1 registers, not control.
>
>>
>>>
>>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>>> used to 12 hour mode in Odroid-XU3 board.
>>
>> Two questions here:
>> 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
>> Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
>> S2MP14)? There are some minor differences between them so I would not be
>> surprised if only some of them required this action.
>>
>
> I'm not sure about that because i don't have S2MPS11 datasheet. I just
> got the information that S2MPS11 also use S2MPS14 rtc from sec-core mfd
> driver,
Yeah, I added it. But these RTC modules are slightly different,
especially S2MPS14, so you cannot assume that they are the same after
looking at mainline code.
>
> static const struct mfd_cell s2mps11_devs[] = {
>
> {
>
> .name = "s2mps11-pmic",
>
> }, {
>
> .name = "s2mps14-rtc",
>
> }, {
>
> .name = "s2mps11-clk",
>
> .of_compatible = "samsung,s2mps11-clk",
>
> }
>
> };
>
>> 2. The driver operates in 24-hour omode. Actually it sets the 24-hour
>> mode just before your new regmap_update_bits() call. What do you mean by
>> 12-hour mode?
>>
>
> RTC_CTRL register value is 0 until write buffer is updated, so it is
> used to 12-hour mode.
I mean what do you have in mind by saying:
"... and hour format is used to 12 hour mode in Odroid-XU3 board."
The hour format is set by driver to 24h mode.
>
>>> Signed-off-by: Joonyoung Shim
>>> Cc:
>>
>> Thanks for putting a cc-stable tag. How far this should be ported? If
>> this is needed only for S2MPS11 then v4.1. If all of them then probably
>> for earlier version?
>>
>
> If find exact version, i think it will be a version after below commit
> was applied.
>
> The commit 0c5deb1ea92f("rtc: s5m: add support for S2MPS14 RTC")
>
> $ git name-rev 0c5deb1ea92f
> 0c5deb1ea92f tags/v3.16-rc1~53^2~1
Hmmm... I am not against the patch (especially that it matches source
code of SM-G900H with S2MPS11) but I have doubts about affected
chipsets. My Odroid (probably because of bootloader), S2MPS13 and
S2MPS14 do not need it. This confuses me...
Best regards,
Krzysztof
>
> Thanks.
>
>> Best regards,
>> Krzysztof
>>
>>> ---
>>> drivers/rtc/rtc-s5m.c | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
>>> index 8c70d78..03828bb 100644
>>> --- a/drivers/rtc/rtc-s5m.c
>>> +++ b/drivers/rtc/rtc-s5m.c
>>> @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info
>>> *info)
>>> case S2MPS13X:
>>> data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
>>> ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
>>> + if (ret < 0)
>>> + break;
>>> +
>>> + ret = regmap_update_bits(info->regmap,
>>> + info->regs->rtc_udr_update,
>>> + info->regs->rtc_udr_mask,
>>> + info->regs->rtc_udr_mask);
>>> + if (ret < 0)
>>> + break;
>>> +
>>> + ret = s5m8767_wait_for_udr_update(info);
>>> +
>>> break;
>>>
>>> default:
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH 2/3] mmc: dw_mmc: simplify the SDMMC_CLKEN_LOW_PWR logic
Hi, Michal.
On 08/12/2015 09:23 PM, Michal Suchanek wrote:
> The driver has open-coded test for SDIO cards. Use the mmc core provided
> MMC_QUIRK_BROKEN_CLK_GATING flag instead.
Did you use the clock-gating for SDIO cards?
Doesn't MMC_CAP_SDIO_IRQ bit set? Which case is broken?
Could you explain to me more?
Best Regards,
Jaehoon Chung
>
> As a bonus this may enable clock gating on SDIO cards that are known to
> work with it.
>
> Signed-off-by: Michal Suchanek
> ---
> drivers/mmc/host/dw_mmc.c | 33 +++--
> 1 file changed, 15 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 40e9d8e..3bc9fd7 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1335,27 +1335,24 @@ static void dw_mci_init_card(struct mmc_host *mmc,
> struct mmc_card *card)
>* description of the CLKENA register we should disable low power mode
>* for SDIO cards if we need SDIO interrupts to work.
>*/
> - if (mmc->caps & MMC_CAP_SDIO_IRQ) {
> - const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
> - u32 clk_en_a_old;
> - u32 clk_en_a;
> + const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
> + u32 clk_en_a_old;
> + u32 clk_en_a;
>
> - clk_en_a_old = mci_readl(host, CLKENA);
> + clk_en_a_old = mci_readl(host, CLKENA);
>
> - if (card->type == MMC_TYPE_SDIO ||
> - card->type == MMC_TYPE_SD_COMBO) {
> - set_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
> - clk_en_a = clk_en_a_old & ~clken_low_pwr;
> - } else {
> - clear_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
> - clk_en_a = clk_en_a_old | clken_low_pwr;
> - }
> + if (card->quirks & MMC_QUIRK_BROKEN_CLK_GATING) {
> + set_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
> + clk_en_a = clk_en_a_old & ~clken_low_pwr;
> + } else {
> + clear_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
> + clk_en_a = clk_en_a_old | clken_low_pwr;
> + }
>
> - if (clk_en_a != clk_en_a_old) {
> - mci_writel(host, CLKENA, clk_en_a);
> - mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
> - SDMMC_CMD_PRV_DAT_WAIT, 0);
> - }
> + if (clk_en_a != clk_en_a_old) {
> + mci_writel(host, CLKENA, clk_en_a);
> + mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
> + SDMMC_CMD_PRV_DAT_WAIT, 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 v2 1/3] gadget: Support for the usb charger framework
On Fri, Aug 14, 2015 at 05:47:44PM +0800, Baolin Wang wrote:
> The usb charger framework is based on usb gadget, and each usb gadget
> can be one usb charger to set the current limitation.
>
> This patch adds a notifier mechanism for usb charger to report to usb
> charger when the usb gadget state is changed.
>
> Also we introduce a callback 'get_charger_type' which will implemented
> by user for usb gadget operations to get the usb charger type.
>
> Signed-off-by: Baolin Wang
> ---
> drivers/usb/gadget/udc/udc-core.c | 38
> +
> include/linux/usb/gadget.h| 20 +++
> 2 files changed, 58 insertions(+)
>
> diff --git a/drivers/usb/gadget/udc/udc-core.c
> b/drivers/usb/gadget/udc/udc-core.c
> index f660afb..47b231c 100644
> --- a/drivers/usb/gadget/udc/udc-core.c
> +++ b/drivers/usb/gadget/udc/udc-core.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * struct usb_udc - describes one usb device controller
> @@ -129,6 +130,32 @@ void usb_gadget_giveback_request(struct usb_ep *ep,
> }
> EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
>
> +int usb_gadget_register_notify(struct usb_gadget *gadget,
> +struct notifier_block *nb)
> +{
> + int ret;
> +
> + mutex_lock(>lock);
> + ret = raw_notifier_chain_register(>nh, nb);
> + mutex_unlock(>lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(usb_gadget_register_notify);
> +
> +int usb_gadget_unregister_notify(struct usb_gadget *gadget,
> + struct notifier_block *nb)
> +{
> + int ret;
> +
> + mutex_lock(>lock);
> + ret = raw_notifier_chain_unregister(>nh, nb);
> + mutex_unlock(>lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(usb_gadget_unregister_notify);
> +
> /* -
> */
>
> /**
> @@ -226,6 +253,10 @@ static void usb_gadget_state_work(struct work_struct
> *work)
> struct usb_gadget *gadget = work_to_gadget(work);
> struct usb_udc *udc = gadget->udc;
>
> + mutex_lock(>lock);
> + raw_notifier_call_chain(>nh, gadget->state, gadget);
> + mutex_unlock(>lock);
> +
> if (udc)
> sysfs_notify(>dev.kobj, NULL, "state");
> }
> @@ -364,6 +395,8 @@ int usb_add_gadget_udc_release(struct device *parent,
> struct usb_gadget *gadget,
>
> dev_set_name(>dev, "gadget");
> INIT_WORK(>work, usb_gadget_state_work);
> + RAW_INIT_NOTIFIER_HEAD(>nh);
> + mutex_init(>lock);
> gadget->dev.parent = parent;
>
> #ifdef CONFIG_HAS_DMA
> @@ -405,6 +438,10 @@ int usb_add_gadget_udc_release(struct device *parent,
> struct usb_gadget *gadget,
>
> mutex_unlock(_lock);
>
> + ret = usb_charger_init(gadget);
> + if (ret)
> + goto err4;
> +
If the charger's initialization fails, you may need to
call device_del(>dev).
Peter
> return 0;
>
> err4:
> @@ -481,6 +518,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
> kobject_uevent(>dev.kobj, KOBJ_REMOVE);
> flush_work(>work);
> device_unregister(>dev);
> + usb_charger_exit(gadget);
> device_unregister(>dev);
> }
> EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index c14a69b..78cc862 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -537,6 +537,7 @@ struct usb_gadget_ops {
> struct usb_ep *(*match_ep)(struct usb_gadget *,
> struct usb_endpoint_descriptor *,
> struct usb_ss_ep_comp_descriptor *);
> + enum usb_charger_type (*get_charger_type)(struct usb_gadget *);
> };
>
> /**
> @@ -609,6 +610,9 @@ struct usb_gadget {
> unsignedout_epnum;
> unsignedin_epnum;
> struct usb_otg_caps *otg_caps;
> + struct raw_notifier_headnh;
> + struct usb_charger *uchger;
> + struct mutexlock;
>
> unsignedsg_supported:1;
> unsignedis_otg:1;
> @@ -1183,6 +1187,22 @@ extern void usb_gadget_unmap_request(struct usb_gadget
> *gadget,
>
> /*-*/
>
> +/**
> + * Register a notifiee to get notified by any attach status changes from
> + * the usb gadget
> + */
> +int usb_gadget_register_notify(struct usb_gadget *gadget,
> +struct notifier_block *nb);
> +
> +/*-*/
> +
> +
> +/* Unregister a notifiee from the usb gadget */
> +int usb_gadget_unregister_notify(struct usb_gadget *gadget,
> + struct notifier_block *nb);
> +
>
Re: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register
Hi,
On 08/13/2015 07:02 PM, Krzysztof Kozlowski wrote:
> W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>> buffer via setting WUDR bit to high after ctrl register is updated.
>
> Hi,
>
> I cannot find this information in S2MPS14 datasheet. On which page is it?
>
I got below information from S2MPS14_Data Sheet_REV0.1 document.
5.2.2.3 RTC_UPDATE
...
NOTE:
1. For write Time Registers (0x00, 0x04~0x0A) & Alarm 0&1 Registers
(0x0B~0x18), set WUDR bit to high.
>
>>
>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>> used to 12 hour mode in Odroid-XU3 board.
>
> Two questions here:
> 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
> Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
> S2MP14)? There are some minor differences between them so I would not be
> surprised if only some of them required this action.
>
I'm not sure about that because i don't have S2MPS11 datasheet. I just
got the information that S2MPS11 also use S2MPS14 rtc from sec-core mfd
driver,
static const struct mfd_cell s2mps11_devs[] = {
{
.name = "s2mps11-pmic",
}, {
.name = "s2mps14-rtc",
}, {
.name = "s2mps11-clk",
.of_compatible = "samsung,s2mps11-clk",
}
};
> 2. The driver operates in 24-hour omode. Actually it sets the 24-hour
> mode just before your new regmap_update_bits() call. What do you mean by
> 12-hour mode?
>
RTC_CTRL register value is 0 until write buffer is updated, so it is
used to 12-hour mode.
>> Signed-off-by: Joonyoung Shim
>> Cc:
>
> Thanks for putting a cc-stable tag. How far this should be ported? If
> this is needed only for S2MPS11 then v4.1. If all of them then probably
> for earlier version?
>
If find exact version, i think it will be a version after below commit
was applied.
The commit 0c5deb1ea92f("rtc: s5m: add support for S2MPS14 RTC")
$ git name-rev 0c5deb1ea92f
0c5deb1ea92f tags/v3.16-rc1~53^2~1
Thanks.
> Best regards,
> Krzysztof
>
>> ---
>> drivers/rtc/rtc-s5m.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
>> index 8c70d78..03828bb 100644
>> --- a/drivers/rtc/rtc-s5m.c
>> +++ b/drivers/rtc/rtc-s5m.c
>> @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info
>> *info)
>> case S2MPS13X:
>> data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
>> ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
>> +if (ret < 0)
>> +break;
>> +
>> +ret = regmap_update_bits(info->regmap,
>> +info->regs->rtc_udr_update,
>> +info->regs->rtc_udr_mask,
>> +info->regs->rtc_udr_mask);
>> +if (ret < 0)
>> +break;
>> +
>> +ret = s5m8767_wait_for_udr_update(info);
>> +
>> break;
>>
>> default:
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> 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: [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously
On 2015/7/30 13:55, Emmanuel Grumbach wrote: > On Thu, Jul 30, 2015 at 8:18 AM, Fu, Zhonghui > wrote: >> Enable wiphy device to suspend/resume asynchronously. This can improve >> system suspend/resume speed. >> > How will that impact the timing with respect to the suspend call > coming from the bus? > I think that a few drivers rely on the suspend call of the wiphy > device happening before the suspend call to the bus device. > Not sure though. Sorry for late reply. The suspend/resume timing of wiphy device and related devices will be ensured by their parent/child relationship. So, enabling wiphy device to suspend/resume asynchronously does not change any dependency. It can only take advantage of multicore and improve system suspend/resume speed. Thanks, Zhonghui > >> Signed-off-by: Zhonghui Fu >> --- >> net/wireless/core.c |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/net/wireless/core.c b/net/wireless/core.c >> index 2a0bbd2..bc5e68f 100644 >> --- a/net/wireless/core.c >> +++ b/net/wireless/core.c >> @@ -416,6 +416,7 @@ use_default_name: >> device_initialize(>wiphy.dev); >> rdev->wiphy.dev.class = _class; >> rdev->wiphy.dev.platform_data = rdev; >> + device_enable_async_suspend(>wiphy.dev); >> >> INIT_LIST_HEAD(>destroy_list); >> spin_lock_init(>destroy_list_lock); >> -- 1.7.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 netdev" 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: [PATCH 2/4] clk: samsung: exynos3250: Add MMC2 clock
On 11.08.2015 12:46, Chanwoo Choi wrote: > This patch add the MMC2 clocks (mux, divider, gate) of Exynos3250 SoC. > > Cc: Sylwester Nawrocki > Cc: Tomasz Figa > Signed-off-by: Chanwoo Choi > --- > drivers/clk/samsung/clk-exynos3250.c | 9 + > include/dt-bindings/clock/exynos3250.h | 7 ++- > 2 files changed, 15 insertions(+), 1 deletion(-) Assuming that numbers/addresses are good (reserved in my datasheet) the code itself looks good: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register
On 08/13/2015 07:42 PM, Krzysztof Kozlowski wrote: > W dniu 13.08.2015 o 19:02, Krzysztof Kozlowski pisze: >> W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze: >>> According to datasheet, the S2MPS13X and S2MPS14X should update write >>> buffer via setting WUDR bit to high after ctrl register is updated. >> >> Hi, >> >> I cannot find this information in S2MPS14 datasheet. On which page is it? >> >> >>> >>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use >>> tools/testing/selftests/timers/rtctest.c test program and hour format is >>> used to 12 hour mode in Odroid-XU3 board. >> >> Two questions here: >> 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11. >> Are you sure that this applies to all of them (S2MPS11, S2MPS13 and >> S2MP14)? There are some minor differences between them so I would not be >> surprised if only some of them required this action. >> >> 2. The driver operates in 24-hour omode. Actually it sets the 24-hour >> mode just before your new regmap_update_bits() call. What do you mean by >> 12-hour mode? >> >>> Signed-off-by: Joonyoung Shim >>> Cc: >> >> Thanks for putting a cc-stable tag. How far this should be ported? If >> this is needed only for S2MPS11 then v4.1. If all of them then probably >> for earlier version? >> >> Best regards, >> Krzysztof > > One more doubt. On my Odroid XU3 first and consecutive executions > (including first) of rtctest run fine. They pass. Can you describe > exactly observable issue and how to reproduce it? This is also important > as a reason for stable backport. I just tested it on next-20150810 with Odroid-XU3 board. First rtctest execution is blocked, # ./rtctest RTC Driver Test Example. Counting 5 update (1/sec) interrupts from reading /dev/rtc0: Any no progress. > > I tested it on next-20150729 on board with Hardkernel bootloader. Maybe > the bootloader sets 12-hour mode which cannot be switched to 24-hour? > My bootloader doesn't touch any registers of s5m-rtc. 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] mm: make compound_head() robust
On Thu, 13 Aug 2015, Kirill A. Shutemov wrote:
> Hugh has pointed that compound_head() call can be unsafe in some
> context. There's one example:
>
> CPU0CPU1
>
> isolate_migratepages_block()
> page_count()
> compound_head()
> !!PageTail() == true
> put_page()
> tail->first_page = NULL
> head = tail->first_page
> alloc_pages(__GFP_COMP)
> prep_compound_page()
>tail->first_page = head
>__SetPageTail(p);
> !!PageTail() == true
>
>
> The race is pure theoretical. I don't it's possible to trigger it in
> practice. But who knows.
>
> We can fix the race by chaging how encode PageTail() and compound_head()
> within struct page to be able to update them in one shot.
>
> The patch introduces page->compound_head into union with
> page->mem_cgroup.
>
> Set bit 0 of page->compound_head means that the page is tail. If the bit
> set, rest of the page->compound_head is pointer to head page. Otherwise,
> the field is NULL or pointer to memory cgroup.
>
> page->mem_cgroup currenly only used for small or head pages, so there
> shouldn't be any conflicts.
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Hugh Dickins
> Cc: David Rientjes
> Cc: Vlastimil Babka
> Cc: Johannes Weiner
> Cc: Michal Hocko
> ---
> Documentation/vm/split_page_table_lock | 4 +-
> arch/xtensa/configs/iss_defconfig | 1 -
> include/linux/mm.h | 53 ++
> include/linux/mm_types.h | 15 ---
> include/linux/page-flags.h | 80
> --
> mm/Kconfig | 12 -
> mm/debug.c | 7 ---
> mm/hugetlb.c | 8 +---
> mm/internal.h | 4 +-
> mm/memory-failure.c| 7 ---
> mm/page_alloc.c| 36 +++
> mm/swap.c | 4 +-
> 12 files changed, 56 insertions(+), 175 deletions(-)
Mostly I like this: especially those deletions,
and removing the unloved CONFIG_PAGEFLAGS_EXTENDED.
But I do disagree with:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 0038ac7466fd..e0c4c0a8ec3d 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -172,13 +172,17 @@ struct page {
> #endif
> #endif
> struct kmem_cache *slab_cache; /* SL[AU]B: Pointer to slab */
> - struct page *first_page;/* Compound tail pages */
> };
>
> -#ifdef CONFIG_MEMCG
> - struct mem_cgroup *mem_cgroup;
> -#endif
> + union {
> + /* Bit zero of the word encode PageTail() */
> + struct mem_cgroup *mem_cgroup; /* If bit zero is clear */
> + unsigned long compound_head;/* If bit zero is set */
> + };
On 32-bit, I think the addition of that mem_cgroup pointer enlarged
struct page from 32 bytes to 36 (SLAB or SLOB) or 40 (SLUB) bytes.
I can well imagine people wanting to cut that bloat by turning off
CONFIG_MEMCG, but now you would be thwarting them. (I can also
imagine memcg people might want to add flag bits of their own to it.)
My own preference (Andrew might disagree) would be to give up on
compound_page_dtor *compound_dtor: in all the years it's been there,
it has only been assigned two possibilities, and I think you'd do
well to hard code those in the one or two places they're needed -
moving PageHuge to be a second bit alongside your PageTail (but of
course it could only be set in the first tail page, not the head).
But as far as fixing the isolate_migratepages_block() bug you
discovered, I think your original atomic_read(>_count) fix
was good enough, or a page_count_raw(page) if Andrew prefers -
though I'm not so keen on dressing these things up myself, such
raw scans are exceptional and face very special problems, I like
to see exactly what's going on in them.
And even when a race between PageTail and first_page is resolved
by your READ_ONCE, it still leaves races of whether the head page
still agrees with the tail. Safer races now because first_page is
reliably a recent first_page pointer: which might be all that's needed
to make your refcounting patches' wider use of compound_head() safe -
this patch does look like a good step for those.
Hugh
--
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] perf: bugzilla 100781
Hi, I tried myself at solving the bugzilla report 100781 that can be found here: https://bugzilla.kernel.org/show_bug.cgi?id=100781 You'll find in the following email the patch I did for that. I welcome any advice or remarks (or insults, but please be gentle, I'm still a newbie!) to make that patch better in hope that it could be used upstream and thus close that bug report! Thanks, Raphaël Raphaël Beamonte (1): perf: fix confusing messages when not able to read trace events files tools/perf/util/parse-events.c | 14 +++--- tools/perf/util/parse-options.c | 6 ++ 2 files changed, 17 insertions(+), 3 deletions(-) -- 2.1.4 -- 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] perf: fix confusing messages when not able to read trace events files
If a non-root user tries to specify a trace event and the tracefs
files can't be read, it will tell about it in a somewhat cryptic
way and as well say that the tracepoint is unknown, which is
obvious, since the tracefs files were not read.
This patch changes this behavior by using the debugfs__strerror_open
function to report the access error in a more elegant way, as well as
provide a hint like the one provided by the perf trace tool.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100781
Signed-off-by: Raphaël Beamonte
---
tools/perf/util/parse-events.c | 14 +++---
tools/perf/util/parse-options.c | 6 ++
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 09f8d23..17f787c 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -398,6 +398,7 @@ static int add_tracepoint_multi_event(struct list_head
*list, int *idx,
char *sys_name, char *evt_name)
{
char evt_path[MAXPATHLEN];
+ char errbuf[BUFSIZ];
struct dirent *evt_ent;
DIR *evt_dir;
int ret = 0;
@@ -405,7 +406,10 @@ static int add_tracepoint_multi_event(struct list_head
*list, int *idx,
snprintf(evt_path, MAXPATHLEN, "%s/%s", tracing_events_path, sys_name);
evt_dir = opendir(evt_path);
if (!evt_dir) {
- perror("Can't open event dir");
+ debugfs__strerror_open(
+ errno, errbuf, sizeof(errbuf),
+ evt_path + strlen(debugfs_mountpoint) + 1);
+ fprintf(stderr, "%s\n", errbuf);
return -1;
}
@@ -437,13 +441,17 @@ static int add_tracepoint_event(struct list_head *list,
int *idx,
static int add_tracepoint_multi_sys(struct list_head *list, int *idx,
char *sys_name, char *evt_name)
{
+ char errbuf[BUFSIZ];
struct dirent *events_ent;
DIR *events_dir;
int ret = 0;
events_dir = opendir(tracing_events_path);
if (!events_dir) {
- perror("Can't open event dir");
+ debugfs__strerror_open(
+ errno, errbuf, sizeof(errbuf),
+ tracing_events_path + strlen(debugfs_mountpoint) + 1);
+ fprintf(stderr, "%s\n", errbuf);
return -1;
}
@@ -1156,7 +1164,7 @@ int parse_events_option(const struct option *opt, const
char *str,
struct parse_events_error err = { .idx = 0, };
int ret = parse_events(evlist, str, );
- if (ret)
+ if (ret && errno != EACCES)
parse_events_print_error(, str);
return ret;
diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index 01626be..55319d9 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -400,6 +400,12 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
return usage_with_options_internal(usagestr,
options, 0);
switch (parse_short_opt(ctx, options)) {
case -1:
+ /* If the error is an access error, we should
already have
+* taken care of it, and the usage information
will provide
+* no help to the user.
+*/
+ if (errno == EACCES)
+ return -1;
return parse_options_usage(usagestr, options,
arg, 1);
case -2:
goto unknown;
--
2.1.4
--
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 pm tree with the samsung tree
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in:
drivers/cpufreq/exynos-cpufreq.c
between commit:
966f2a71a92d ("cpufreq: exynos: remove Exynos4x12 specific cpufreq driver
support")
from the samsung tree and commit:
62c3f2fddd43 ("cpufreq: exynos: Fix for memory leak in case SoC name does not
match")
from the pm tree.
I fixed it up (I just removed the file) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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 v5 1/9] mmc: dw_mmc: Add external dma interface support
在 2015/8/15 6:13, Heiko Stübner 写道:
Hi Shawn,
Am Freitag, 14. August 2015, 16:34:35 schrieb Shawn Lin:
DesignWare MMC Controller can supports two types of DMA
mode: external dma and internal dma. We get a RK312x platform
integrated dw_mmc and ARM pl330 dma controller. This patch add
edmac ops to support these platforms. I've tested it on RK312x
platform with edmac mode and RK3288 platform with idmac mode.
Signed-off-by: Shawn Lin
judging by your "from", I guess you're running this on some older Rockchip soc
without the idma? Because I tried testing this on a Radxa Rock, but only got
failures, from the start (failed to read card status register). In PIO mode
everything works again.
I guess I overlooked just some tiny detail, but to me the dma channel ids seem
correct after all. Maybe you have any hints what I'm doing wrong?
Thanks, HeiKo.
yes, I'm running a quite older low-end Rockchip soc w/o idma.
Hmm... from your failure to read CSR, I think generic DMA of Radxa Rock
was not runing properly. Your dma channel ids is correct, but it
certainly work on my platform。 I will try to find a Radxa Rock to
re-test my patch ASAP.
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index 4497d28..92d7156 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -217,6 +217,8 @@
interrupts = ;
clocks = < HCLK_SDMMC>, < SCLK_SDMMC>;
clock-names = "biu", "ciu";
+ dmas = < 1>;
+ dma-names = "rx-tx";
fifo-depth = <256>;
status = "disabled";
};
@@ -227,6 +229,8 @@
interrupts = ;
clocks = < HCLK_SDIO>, < SCLK_SDIO>;
clock-names = "biu", "ciu";
+ dmas = < 3>;
+ dma-names = "rx-tx";
fifo-depth = <256>;
status = "disabled";
};
@@ -237,6 +241,8 @@
interrupts = ;
clocks = < HCLK_EMMC>, < SCLK_EMMC>;
clock-names = "biu", "ciu";
+ dmas = < 4>;
+ dma-names = "rx-tx";
fifo-depth = <256>;
status = "disabled";
};
[...]
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index fcbf552..e01ead3 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2517,8 +2642,23 @@ static void dw_mci_cleanup_slot(struct dw_mci_slot
*slot, unsigned int id) static void dw_mci_init_dma(struct dw_mci *host)
{
int addr_config;
+ int trans_mode;
+ struct device *dev = host->dev;
+ struct device_node *np = dev->of_node;
+
+ /* Check tansfer mode */
+ trans_mode = SDMMC_GET_TRANS_MODE(mci_readl(host, HCON));
+ if (trans_mode == 0) {
+ trans_mode = TRANS_MODE_IDMAC;
+ } else if (trans_mode == 1 || trans_mode == 2) {
+ trans_mode = TRANS_MODE_EDMAC;
+ } else {
+ trans_mode = TRANS_MODE_PIO;
+ goto no_dma;
+ }
+
/* Check ADDR_CONFIG bit in HCON to find IDMAC address bus width */
- addr_config = (mci_readl(host, HCON) >> 27) & 0x01;
+ addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));
if (addr_config == 1) {
/* host supports IDMAC in 64-bit address mode */
I guess the idmac address size checking block
/* Check ADDR_CONFIG bit in HCON to find IDMAC address bus width */
addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));
if (addr_config == 1) {
/* host supports IDMAC in 64-bit address mode */
host->dma_64bit_address = 1;
dev_info(host->dev, "IDMAC supports 64-bit address mode.\n");
if (!dma_set_mask(host->dev, DMA_BIT_MASK(64)))
dma_set_coherent_mask(host->dev, DMA_BIT_MASK(64));
} else {
/* host supports IDMAC in 32-bit address mode */
host->dma_64bit_address = 0;
dev_info(host->dev, "IDMAC supports 32-bit address mode.\n");
}
could either live inside the trans_mode == 0 conditional above or get its own
if (trans_mode == 0) conditional. Either way I guess it should not talk about
idmac when either pio or extdmac are used.
Thanks
Heiko
--
Shawn Lin
--
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 pci tree with the arm-soc tree
Hi Bjorn,
Today's linux-next merge of the pci tree got a conflict in:
drivers/pci/host/Kconfig
between commit:
70d334ca71b0 ("PCI: iproc: Fix BCMA dependency in Kconfig")
from the arm-soc tree and commit:
05aa7d6a72c1 ("PCI: iproc: Allow BCMA bus driver to be built as module")
from the pci tree.
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 drivers/pci/host/Kconfig
index 48b5b3058d9d,e339a8c42f76..
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@@ -135,8 -135,8 +135,8 @@@ config PCIE_IPROC_PLATFOR
through the generic platform bus interface
config PCIE_IPROC_BCMA
- bool "Broadcom iProc PCIe BCMA bus driver"
+ tristate "Broadcom iProc PCIe BCMA bus driver"
- depends on ARCH_BCM_IPROC || (ARM && COMPILE_TEST)
+ depends on ARM && (ARCH_BCM_IPROC || COMPILE_TEST)
select PCIE_IPROC
select BCMA
select PCI_DOMAINS
--
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] ceph: remove redundant test of head->safe and silence static analysis warnings
ceph: remove redundant test of head->safe and silence static analysis
warnings
Signed-off-by: Brad Hubbard
---
fs/ceph/mds_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
index 6aa07af..6e196ee 100644
--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -2411,7 +2411,7 @@ static void handle_reply(struct ceph_mds_session
*session, struct ceph_msg *msg)
mutex_unlock(>mutex);
goto out;
}
- if (req->r_got_safe && !head->safe) {
+ if (req->r_got_safe) {
pr_warn("got unsafe after safe on %llu from mds%d\n",
tid, mds);
mutex_unlock(>mutex);
--
--
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/4] clk: samsung: exynos3250: Add UART2 clock
On 11.08.2015 12:46, Chanwoo Choi wrote:
> This patch add the UART2 clocks (mux, divider, gate) of Exynos3250 SoC.
I could not confirm the exact numbers used ("reserved" in my datasheet)
but the patch itself looks correct.
Assuming that numbers/addresses are good:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
>
> Cc: Sylwester Nawrocki
> Cc: Tomasz Figa
> Signed-off-by: Chanwoo Choi
> ---
> drivers/clk/samsung/clk-exynos3250.c | 6 ++
> include/dt-bindings/clock/exynos3250.h | 6 +-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
--
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 v2] extcon next for 4.3
Dear Greg, This is extcon-next full request for v4.3. I add detailed description of this pull request on below. Please pull extcon with following updates. Changes from v1: - Fix the merge conflict of extcon-palmas.c driver on linux-next.git (Stephen Rothwell). Best Regards, Chanwoo Choi The following changes since commit f7644cbfcdf03528f0f450f3940c4985b2291f49: Linux 4.2-rc6 (2015-08-09 15:54:30 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-4.3 for you to fetch changes up to ac22a1d3386e195c57e299da3bfad97a061b9616: extcon: palmas: Fix build break due to devm_gpiod_get_optional API change (2015-08-13 20:56:18 +0900) Update extcon for v4.3 This patchset include the function update of extcon drivers without critical update and fix minor issue of extcon drivers. Detailed description for patchset: 1. Update the extcon drivers: - Update the logic of microphone detection for extcon-arizona driver - Support GPIO based USB ID detection of extcon-palmas driver 2. Fix minor issues: - Clean code and remove the opitonal print_state() function pointer from extcon core driver - Clear interrupt bit state before requesting irq on extcon-max778433 driver - Fix signedness bugs of extcon core driver Chanwoo Choi (5): extcon: Remove duplicate header file in extcon.h extcon: Remove optional print_state() function pointer of struct extcon_dev extcon: palmas: Remove the mutually_exclusive array extcon: Add exception handling to prevent the NULL pointer access extcon: palmas: Fix build break due to devm_gpiod_get_optional API change Charles Keepax (6): extcon: arizona: Update to use the new device properties API extcon: arizona: Add basic microphone detection DT/ACPI bindings extcon: arizona: Use gpiod inteface to handle micd_pol_gpio gpio extcon: arizona: Ensure variables are set for headphone detection extcon: arizona: Declare 3-pole jack if we detect open circuit on mic extcon: arizona: Simplify pdata symantics for micd_dbtime Dan Carpenter (1): extcon: Fix signedness bugs about break error handling Jaewon Kim (1): extcon: max77843: Clear IRQ bits state before request IRQ Krzysztof Kozlowski (1): extcon: Drop owner assignment from i2c_driver Roger Quadros (1): extcon: palmas: Support GPIO based USB ID detection .../devicetree/bindings/extcon/extcon-palmas.txt | 5 +- drivers/extcon/extcon-arizona.c| 101 +--- drivers/extcon/extcon-gpio.c | 18 --- drivers/extcon/extcon-max77843.c | 9 ++ drivers/extcon/extcon-palmas.c | 134 ++--- drivers/extcon/extcon-rt8973a.c| 1 - drivers/extcon/extcon-sm5502.c | 1 - drivers/extcon/extcon-usb-gpio.c | 1 + drivers/extcon/extcon.c| 48 ++-- include/linux/extcon.h | 7 -- include/linux/mfd/palmas.h | 7 ++ 11 files changed, 255 insertions(+), 77 deletions(-) -- 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/4] ARM: dts: exynos3250: Add UART2 and MMC2 dt node with related clocks
On 17.08.2015 09:36, Chanwoo Choi wrote: > On 08/17/2015 09:33 AM, Krzysztof Kozlowski wrote: >> 2015-08-11 12:46 GMT+09:00 Chanwoo Choi : >>> This patch add the UART2 / MMC2 devicetree node for Exynos3250 SoC and add >>> the related clocks (mux, divider, gate) of UART2 / MMC2 device. >> >> What is the benefit of adding them? Why they are needed? > > UART2 /MMC2 are used on Exynos3250-based ARTIK-5 board[1]. > [1] https://www.artik.io/hardware/artik-5 Thanks for explaining this. The patchset missed that information - the purpose. I'll start reviewing it. Best regards, Krzysztof > > Thanks, > Chanwoo Choi > >> >> Best regards, >> Krzysztof >> >> >>> >>> Chanwoo Choi (4): >>> clk: samsung: exynos3250: Add UART2 clock >>> clk: samsung: exynos3250: Add MMC2 clock >>> ARM: dts: Add UART2 dt node for Exynos3250 SoC >>> ARM: dts: Add MSHC2 dt node for Exynos3250 SoC >>> >>> arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 42 >>> +++ >>> arch/arm/boot/dts/exynos3250.dtsi | 25 ++ >>> drivers/clk/samsung/clk-exynos3250.c | 15 +++ >>> include/dt-bindings/clock/exynos3250.h| 11 +++- >>> 4 files changed, 92 insertions(+), 1 deletion(-) >>> >>> -- >>> 1.8.5.5 >>> >>> >>> ___ >>> linux-arm-kernel mailing list >>> linux-arm-ker...@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" >> 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: [PATCH 0/4] ARM: dts: exynos3250: Add UART2 and MMC2 dt node with related clocks
On 08/17/2015 09:33 AM, Krzysztof Kozlowski wrote: > 2015-08-11 12:46 GMT+09:00 Chanwoo Choi : >> This patch add the UART2 / MMC2 devicetree node for Exynos3250 SoC and add >> the related clocks (mux, divider, gate) of UART2 / MMC2 device. > > What is the benefit of adding them? Why they are needed? UART2 /MMC2 are used on Exynos3250-based ARTIK-5 board[1]. [1] https://www.artik.io/hardware/artik-5 Thanks, Chanwoo Choi > > Best regards, > Krzysztof > > >> >> Chanwoo Choi (4): >> clk: samsung: exynos3250: Add UART2 clock >> clk: samsung: exynos3250: Add MMC2 clock >> ARM: dts: Add UART2 dt node for Exynos3250 SoC >> ARM: dts: Add MSHC2 dt node for Exynos3250 SoC >> >> arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 42 >> +++ >> arch/arm/boot/dts/exynos3250.dtsi | 25 ++ >> drivers/clk/samsung/clk-exynos3250.c | 15 +++ >> include/dt-bindings/clock/exynos3250.h| 11 +++- >> 4 files changed, 92 insertions(+), 1 deletion(-) >> >> -- >> 1.8.5.5 >> >> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > 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: [PATCH stable] md/bitmap: return an error when bitmap superblock is corrupt.
On Fri, 14 Aug 2015 10:23:51 -0700 Greg KH wrote:
> On Fri, Aug 14, 2015 at 05:04:21PM +1000, NeilBrown wrote:
> >
> > commit b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49 upstream
> > Use separate bitmaps for each nodes in the cluster
> >
> > bitmap_read_sb() validates the bitmap superblock that it reads in.
> > If it finds an inconsistency like a bad magic number or out-of-range
> > version number, it prints an error and returns, but it incorrectly
> > returns zero, so the array is still assembled with the (invalid) bitmap.
> >
> > This means it could try to use a bitmap with a new version number which
> > it therefore does not understand.
> >
> > This bug was introduced in 3.5 and fix as part of a larger patch in 4.1.
> > So the patch is suitable for any -stable kernel in that range.
> >
> > Fixes: 27581e5ae01f ("md/bitmap: centralise allocation of bitmap file
> > pages.")
> > Cc: sta...@vger.kernel.org (v3.5..v4.1)
>
> b97e92574c0 is in 4.1, so do you mean (v3.5..v4.0) here?
>
Yes, I did. Thanks!
v3.5..v4.0.
NeilBrown
--
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/4] ARM: dts: exynos3250: Add UART2 and MMC2 dt node with related clocks
2015-08-11 12:46 GMT+09:00 Chanwoo Choi : > This patch add the UART2 / MMC2 devicetree node for Exynos3250 SoC and add > the related clocks (mux, divider, gate) of UART2 / MMC2 device. What is the benefit of adding them? Why they are needed? Best regards, Krzysztof > > Chanwoo Choi (4): > clk: samsung: exynos3250: Add UART2 clock > clk: samsung: exynos3250: Add MMC2 clock > ARM: dts: Add UART2 dt node for Exynos3250 SoC > ARM: dts: Add MSHC2 dt node for Exynos3250 SoC > > arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 42 > +++ > arch/arm/boot/dts/exynos3250.dtsi | 25 ++ > drivers/clk/samsung/clk-exynos3250.c | 15 +++ > include/dt-bindings/clock/exynos3250.h| 11 +++- > 4 files changed, 92 insertions(+), 1 deletion(-) > > -- > 1.8.5.5 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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] serial: 8250: Fix autoconfig_irq() to avoid race conditions
Hi Greg, On 2015/08/15 9:10, gre...@linuxfoundation.org wrote: > On Mon, Aug 10, 2015 at 12:15:40AM +, Taichi Kageyama wrote: >> The following race conditions can happen when a serial port is used >> as console. >> >> Case1: CPU_B is used to detect an interrupt from a serial port, >>but it can have interrupts disabled during the waiting time. >> Case2: CPU_B clears UART_IER just after CPU_A sets UART_IER and then >>a serial port may not make an interrupt. >> Case3: CPU_A sets UART_IER just after CPU_B clears UART_IER. >>This is an unexpected behavior for serial8250_console_write(). >> >> CPU_A [autoconfig_irq] | CPU_B [serial8250_console_write] >> |--- >> | >> probe_irq_on() | spin_lock_irqsave(>lock,) >> serial_outp(,UART_IER,0x0f) | serial_out(,UART_IER,0) >> udelay(20); | uart_console_write() >> probe_irq_off() | >> | spin_unlock_irqrestore(>lock,) >> >> Case1 and 2 can make autoconfig_irq() failed. >> In these cases, the console doesn't work in interrupt mode and >> "input overrun" (which can make operation mistakes) can happen >> on some systems. Especially in the Case1, It is known that the >> problem happens with high rate every boot once it occurs >> because the boot sequence is always almost same. >> >> port mutex makes sure that the autoconfig operation is exclusive of >> any other concurrent HW access except by the console operation. >> console lock is required in autoconfig_irq(). >> >> Signed-off-by: Taichi Kageyama >> Cc: Naoya Horiguchi >> Reviewed-by: Peter Hurley >> --- >> drivers/tty/serial/8250/8250_core.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git v4.2-rc4.org/drivers/tty/serial/8250/8250_core.c >> v4.2-rc4.work/drivers/tty/serial/8250/8250_core.c >> index 37fff12..ed1e23e 100644 >> --- v4.2-rc4.org/drivers/tty/serial/8250/8250_core.c >> +++ v4.2-rc4.work/drivers/tty/serial/8250/8250_core.c >> @@ -1303,6 +1303,9 @@ static void autoconfig_irq(struct uart_8250_port *up) >> inb_p(ICP); >> } >> >> +if (uart_console(port)) >> +console_lock(); >> + >> /* forget possible initially masked and pending IRQ */ >> probe_irq_off(probe_irq_on()); >> save_mcr = serial_in(up, UART_MCR); >> @@ -1334,6 +1337,9 @@ static void autoconfig_irq(struct uart_8250_port *up) >> if (port->flags & UPF_FOURPORT) >> outb_p(save_ICP, ICP); >> >> +if (uart_console(port)) >> +console_unlock(); >> + >> port->irq = (irq > 0) ? irq : 0; >> } > > This doesn't apply to my tty-next tree at all. Can you please rebase it > and resend? Oh, I didn't know the file name was changed in tty-next. I'll rebase it. Thanks, Taichi -- 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 4.2-rc7
Hi all, On Sun, 16 Aug 2015 16:49:27 -0700 Linus Torvalds wrote: > > So a release next week is definitely still possible. Which means that all new work for v4.3 should already be in linux-next included trees and maintainers should just be tidying up their trees for merging ... -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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/
