[PATCH 1/2] md/raid5: fix typo
bion -> bios Signed-off-by: Yuanhan Liu --- drivers/md/raid5.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 697d77a..2651bda 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -2919,7 +2919,7 @@ schedule_reconstruction(struct stripe_head *sh, struct stripe_head_state *s, } /* - * Each stripe/dev can have one or more bion attached. + * Each stripe/dev can have one or more bios attached. * toread/towrite point to the first in a chain. * The bi_next chain must be in order. */ -- 1.9.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 2/2] md/raid5: trivial coding style fix
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 2651bda..bae3e2c 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -5789,8 +5789,7 @@ static void raid5d(struct md_thread *thread)
if (released)
clear_bit(R5_DID_ALLOC, &conf->cache_state);
- if (
- !list_empty(&conf->bitmap_list)) {
+ if (!list_empty(&conf->bitmap_list)) {
/* Now is a good time to flush some bitmap updates */
conf->seq_flush++;
spin_unlock_irq(&conf->device_lock);
--
1.9.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 v8] extcon-axp288: Add axp288 extcon driver support
Hi Choi,
I think I missed some. I will fix them and submit the v9 patch.
> Hi Ram,
>
> I added some comment.
> If you fix minor issue according to comment, I'll apply it.
>
> On 04/30/2015 10:43 AM, Ramakrishna Pallala wrote:
> > This patch adds the extcon support for AXP288 PMIC which has the BC1.2
> > charger detection capability. Additionally it also adds the USB mux
> > switching support b/w SOC and PMIC based on GPIO control.
> >
> > Signed-off-by: Ramakrishna Pallala
> > ---
> > drivers/extcon/Kconfig |7 +
> > drivers/extcon/Makefile|1 +
> > drivers/extcon/extcon-axp288.c | 386
>
> > include/linux/mfd/axp20x.h |5 +
> > 4 files changed, 399 insertions(+)
> > create mode 100644 drivers/extcon/extcon-axp288.c
>
> [snip]
>
> > +static int axp288_handle_chrg_det_event(struct axp288_extcon_info
> > +*info) {
> > + static bool notify_otg, notify_charger;
> > + static char *cable;
> > + int ret, stat, cfg, pwr_stat;
> > + u8 chrg_type;
> > + bool vbus_attach = false;
> > +
> > + ret = regmap_read(info->regmap, AXP288_PS_STAT_REG, &pwr_stat);
> > + if (ret < 0) {
> > + dev_err(info->dev, "failed to read vbus status\n");
> > + return ret;
> > + }
> > +
> > + vbus_attach = (pwr_stat & PS_STAT_VBUS_PRESENT);
> > + if (!vbus_attach)
> > + goto notify_otg;
> > +
> > + /* Check charger detection completion status */
> > + ret = regmap_read(info->regmap, AXP288_BC_GLOBAL_REG, &cfg);
> > + if (ret < 0)
> > + goto dev_det_ret;
> > + if (cfg & BC_GLOBAL_DET_STAT) {
> > + dev_dbg(info->dev, "can't complete the charger detection\n");
> > + goto dev_det_ret;
> > + }
> > +
> > + ret = regmap_read(info->regmap, AXP288_BC_DET_STAT_REG, &stat);
> > + if (ret < 0)
> > + goto dev_det_ret;
> > + dev_dbg(info->dev, "status:%x, config:%x\n", stat, cfg);
>
> As I said on previous reply, it is not necessary about just register value
> without
> appropriate log message.
Ok...
>
> > +
> > + chrg_type = (stat & DET_STAT_MASK) >> DET_STAT_SHIFT;
> > +
> > + switch (chrg_type) {
> > + case DET_STAT_SDP:
> > + dev_dbg(info->dev, "sdp cable is connecetd\n");
> > + notify_otg = true;
> > + notify_charger = true;
> > + cable = AXP288_EXTCON_SLOW_CHARGER;
> > + break;
> > + case DET_STAT_CDP:
> > + dev_dbg(info->dev, "cdp cable is connecetd\n");
> > + notify_otg = true;
> > + notify_charger = true;
> > + cable = AXP288_EXTCON_DOWNSTREAM_CHARGER;
> > + break;
> > + case DET_STAT_DCP:
> > + dev_dbg(info->dev, "dcp cable is connecetd\n");
> > + notify_charger = true;
> > + cable = AXP288_EXTCON_FAST_CHARGER;
> > + break;
> > + default:
> > + dev_warn(info->dev,
> > + "disconnect or unknown or ID event\n");
> > + }
> > +
> > +notify_otg:
> > + if (notify_otg) {
> > + /*
> > +* If VBUS is absent Connect D+/D- lines to PMIC for BC
> > +* detection. Else connect them to SOC for USB communication.
> > +*/
> > + if (info->pdata->gpio_mux_cntl)
> > + gpiod_set_value(info->pdata->gpio_mux_cntl,
> > + vbus_attach ? EXTCON_GPIO_MUX_SEL_SOC
> > + :
> EXTCON_GPIO_MUX_SEL_PMIC);
> > +
> > + atomic_notifier_call_chain(&info->otg->notifier,
> > + vbus_attach ? USB_EVENT_VBUS : USB_EVENT_NONE,
> NULL);
> > + }
> > +
> > + if (notify_charger)
> > + extcon_set_cable_state(info->edev, cable, vbus_attach);
> > +
> > + /* Clear the flags on disconnect event */
> > + if (!vbus_attach)
> > + notify_otg = notify_charger = false;
> > +
> > + return 0;
> > +
> > +dev_det_ret:
> > + if (ret < 0)
> > + dev_err(info->dev, "BC Mod detection error\n");
>
> "BC Mod detection error\n" -> "failed to detect BC Mod\n"
>
> > +
> > + return ret;
> > +}
> > +
> > +static irqreturn_t axp288_extcon_isr(int irq, void *data) {
> > + struct axp288_extcon_info *info = data;
> > + int ret;
> > +
> > + ret = axp288_handle_chrg_det_event(info);
> > + if (ret < 0)
> > + dev_err(info->dev, "error in PWRSRC INT handling\n");
>
> As I saied on previous reply, you better to modify log message as following:
> "failed to handle the interrupt\n"
Ok.
>
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static void axp288_extcon_enable_irq(struct axp288_extcon_info *info)
> > +{
> > + /* Unmask VBUS interrupt */
> > + regmap_write(info->regmap, AXP288_PWRSRC_IRQ_CFG_REG,
> > + PWRSRC_IRQ_CFG_MASK);
> > + regmap_update_bits(info->regmap, AXP288_BC_GLOBAL_REG,
> > + BC_GLOBAL_RUN, 0);
> > + /* Unmask
[PATCH v3 1/2] ARM: EXYNOS: Get current parent clock for power domain on/off
Using a fixed (by DTS) parent for clocks when turning on the power domain
may introduce issues in other drivers. For example when such driver
changes the parent during runtime and expects that he is the only place
of such change.
Do not rely on DTS providing the fixed parent for such clocks. Instead
before switching domain off, grab a current parent of a clock with
clk_get_parent().
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
Tested-by: Javier Martinez Canillas
---
Changes since v2:
1. Don't store the parent of the clock on driver init but instead mark
it as -EINVAL. This means that on first power up of the domain (when
system is booted with domain being off) the parent won't be set. This
is a special rare condition because all domains are being turned on:
either by reset value or by bootloader. Javier's reviewed by
retained.
2. Add Javier's tags.
Changes since v1:
1. Drop "pclk" bindings entirely as suggested by Andrzej Hajda.
This was significant change so I did not add Javier's
reviewed/tested tags.
---
.../devicetree/bindings/arm/exynos/power_domain.txt | 7 ---
arch/arm/mach-exynos/pm_domains.c| 16 +---
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 5da38c5ed476..e151057d92f0 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -19,9 +19,10 @@ Optional Properties:
domains.
- clock-names: The following clocks can be specified:
- oscclk: Oscillator clock.
- - pclkN, clkN: Pairs of parent of input clock and input clock to the
- devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
- are supported currently.
+ - clkN: Input clocks to the devices in this power domain. These clocks
+ will be reparented to oscclk before swithing power domain off.
+ Their original parent will be brought back after turning on
+ the domain. Maximum of 4 clocks (N = 0 to 3) are supported.
- asbN: Clocks required by asynchronous bridges (ASB) present in
the power domain. These clock should be enabled during power
domain on/off operations.
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index cbe56b35aea0..294fc7e956aa 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -62,6 +62,7 @@ static int exynos_pd_power(struct generic_pm_domain *domain,
bool power_on)
for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd->clk[i]))
break;
+ pd->pclk[i] = clk_get_parent(pd->clk[i]);
if (clk_set_parent(pd->clk[i], pd->oscclk))
pr_err("%s: error setting oscclk as parent to
clock %d\n",
pd->name, i);
@@ -90,6 +91,9 @@ static int exynos_pd_power(struct generic_pm_domain *domain,
bool power_on)
for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd->clk[i]))
break;
+
+ if (IS_ERR(pd->clk[i]))
+ continue; /* Skip on first power up */
if (clk_set_parent(pd->clk[i], pd->pclk[i]))
pr_err("%s: error setting parent to clock%d\n",
pd->name, i);
@@ -161,13 +165,11 @@ static __init int exynos4_pm_init_power_domain(void)
pd->clk[i] = clk_get(dev, clk_name);
if (IS_ERR(pd->clk[i]))
break;
- snprintf(clk_name, sizeof(clk_name), "pclk%d", i);
- pd->pclk[i] = clk_get(dev, clk_name);
- if (IS_ERR(pd->pclk[i])) {
- clk_put(pd->clk[i]);
- pd->clk[i] = ERR_PTR(-EINVAL);
- break;
- }
+ /*
+* Skip setting parent on first power up.
+* The parent at this time may not be useful at all.
+*/
+ pd->pclk[i] = ERR_PTR(-EINVAL);
}
if (IS_ERR(pd->clk[0]))
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] ARM: dts: Use last parent for clocks during power domain on/off
Replace fixed parent with last parent (obtained with clk_get_parent())
of clocks for devices in mfc and disp power domains. This should improve
behavior if such clocks were reparented by the drivers and new parents
are different than those specified in DTS.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
Tested-by: Javier Martinez Canillas
---
Changes since v2:
1. None.
Changes since v1:
1. Add Javier's reviewed/tested tags. Thanks!
---
arch/arm/boot/dts/exynos5420.dtsi | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index f67b23f303c3..2e6c95702ced 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -264,9 +264,8 @@
mfc_pd: power-domain@10044060 {
compatible = "samsung,exynos4210-pd";
reg = <0x10044060 0x20>;
- clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
- <&clock CLK_MOUT_USER_ACLK333>;
- clock-names = "oscclk", "pclk0", "clk0";
+ clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_USER_ACLK333>;
+ clock-names = "oscclk", "clk0";
#power-domain-cells = <0>;
};
@@ -280,16 +279,12 @@
compatible = "samsung,exynos4210-pd";
reg = <0x100440C0 0x20>;
#power-domain-cells = <0>;
- clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK200>,
+ clocks = <&clock CLK_FIN_PLL>,
<&clock CLK_MOUT_USER_ACLK200_DISP1>,
-<&clock CLK_MOUT_SW_ACLK300>,
<&clock CLK_MOUT_USER_ACLK300_DISP1>,
-<&clock CLK_MOUT_SW_ACLK400>,
<&clock CLK_MOUT_USER_ACLK400_DISP1>,
<&clock CLK_FIMD1>, <&clock CLK_MIXER>;
- clock-names = "oscclk", "pclk0", "clk0",
- "pclk1", "clk1", "pclk2", "clk2",
- "asb0", "asb1";
+ clock-names = "oscclk", "clk0", "clk1", "clk2", "asb0", "asb1";
};
pinctrl_0: pinctrl@1340 {
--
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 v9] extcon-axp288: Add axp288 extcon driver support
This patch adds the extcon support for AXP288 PMIC which
has the BC1.2 charger detection capability. Additionally
it also adds the USB mux switching support b/w SOC and PMIC
based on GPIO control.
Signed-off-by: Ramakrishna Pallala
Acked-by: Lee Jones
---
drivers/extcon/Kconfig |7 +
drivers/extcon/Makefile|1 +
drivers/extcon/extcon-axp288.c | 385
include/linux/mfd/axp20x.h |5 +
4 files changed, 398 insertions(+)
create mode 100644 drivers/extcon/extcon-axp288.c
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index fdc0bf0..2305edc 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -28,6 +28,13 @@ config EXTCON_ARIZONA
with Wolfson Arizona devices. These are audio CODECs with
advanced audio accessory detection support.
+config EXTCON_AXP288
+ tristate "X-Power AXP288 EXTCON support"
+ depends on MFD_AXP20X && USB_PHY
+ help
+ Say Y here to enable support for USB peripheral detection
+ and USB MUX switching by X-Power AXP288 PMIC.
+
config EXTCON_GPIO
tristate "GPIO extcon support"
depends on GPIOLIB
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 9204114..ba787d0 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_EXTCON) += extcon.o
obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
+obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
new file mode 100644
index 000..16ed288
--- /dev/null
+++ b/drivers/extcon/extcon-axp288.c
@@ -0,0 +1,385 @@
+/*
+ * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ * Author: Ramakrishna Pallala
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Power source status register */
+#define PS_STAT_VBUS_TRIGGER BIT(0)
+#define PS_STAT_BAT_CHRG_DIR BIT(2)
+#define PS_STAT_VBUS_ABOVE_VHOLD BIT(3)
+#define PS_STAT_VBUS_VALID BIT(4)
+#define PS_STAT_VBUS_PRESENT BIT(5)
+
+/* BC module global register */
+#define BC_GLOBAL_RUN BIT(0)
+#define BC_GLOBAL_DET_STAT BIT(2)
+#define BC_GLOBAL_DBP_TOUT BIT(3)
+#define BC_GLOBAL_VLGC_COM_SEL BIT(4)
+#define BC_GLOBAL_DCD_TOUT_MASK(BIT(6)|BIT(5))
+#define BC_GLOBAL_DCD_TOUT_300MS 0
+#define BC_GLOBAL_DCD_TOUT_100MS 1
+#define BC_GLOBAL_DCD_TOUT_500MS 2
+#define BC_GLOBAL_DCD_TOUT_900MS 3
+#define BC_GLOBAL_DCD_DET_SEL BIT(7)
+
+/* BC module vbus control and status register */
+#define VBUS_CNTL_DPDM_PD_EN BIT(4)
+#define VBUS_CNTL_DPDM_FD_EN BIT(5)
+#define VBUS_CNTL_FIRST_PO_STATBIT(6)
+
+/* BC USB status register */
+#define USB_STAT_BUS_STAT_MASK (BIT(3)|BIT(2)|BIT(1)|BIT(0))
+#define USB_STAT_BUS_STAT_SHIFT0
+#define USB_STAT_BUS_STAT_ATHD 0
+#define USB_STAT_BUS_STAT_CONN 1
+#define USB_STAT_BUS_STAT_SUSP 2
+#define USB_STAT_BUS_STAT_CONF 3
+#define USB_STAT_USB_SS_MODE BIT(4)
+#define USB_STAT_DEAD_BAT_DET BIT(6)
+#define USB_STAT_DBP_UNCFG BIT(7)
+
+/* BC detect status register */
+#define DET_STAT_MASK (BIT(7)|BIT(6)|BIT(5))
+#define DET_STAT_SHIFT 5
+#define DET_STAT_SDP 1
+#define DET_STAT_CDP 2
+#define DET_STAT_DCP 3
+
+/* IRQ enable-1 register */
+#define PWRSRC_IRQ_CFG_MASK(BIT(4)|BIT(3)|BIT(2))
+
+/* IRQ enable-6 register */
+#define BC12_IRQ_CFG_MASK BIT(1)
+
+#define AXP288_EXTCON_SLOW_CHARGER "SLOW-CHARGER"
+#define AXP288_EXTCON_DOWNSTREAM_CHARGER "CHARGE-DOWNSTREAM"
+#define AXP288_EXTCON_FAST_CHARGER "FAST-CHARGER"
+
+enum axp288_extcon_reg {
+ AXP288_PS_STAT_REG = 0x00,
+ AXP288_PS_BOOT_REASON_REG = 0x02,
+ AXP288_BC_GLOBAL_REG= 0x2c,
+ AXP288_BC_VBUS_CNTL_REG = 0x2d,
+ AXP288_BC_USB_STAT_REG
Re: [PATCH kernel v9 28/32] powerpc/mmu: Add userspace-to-physical addresses translation cache
On Sat, Apr 25, 2015 at 10:14:52PM +1000, Alexey Kardashevskiy wrote:
> We are adding support for DMA memory pre-registration to be used in
> conjunction with VFIO. The idea is that the userspace which is going to
> run a guest may want to pre-register a user space memory region so
> it all gets pinned once and never goes away. Having this done,
> a hypervisor will not have to pin/unpin pages on every DMA map/unmap
> request. This is going to help with multiple pinning of the same memory
> and in-kernel acceleration of DMA requests.
>
> This adds a list of memory regions to mm_context_t. Each region consists
> of a header and a list of physical addresses. This adds API to:
> 1. register/unregister memory regions;
> 2. do final cleanup (which puts all pre-registered pages);
> 3. do userspace to physical address translation;
> 4. manage a mapped pages counter; when it is zero, it is safe to
> unregister the region.
>
> Multiple registration of the same region is allowed, kref is used to
> track the number of registrations.
[snip]
> +long mm_iommu_alloc(unsigned long ua, unsigned long entries,
> + struct mm_iommu_table_group_mem_t **pmem)
> +{
> + struct mm_iommu_table_group_mem_t *mem;
> + long i, j;
> + struct page *page = NULL;
> +
> + list_for_each_entry_rcu(mem, ¤t->mm->context.iommu_group_mem_list,
> + next) {
> + if ((mem->ua == ua) && (mem->entries == entries))
> + return -EBUSY;
> +
> + /* Overlap? */
> + if ((mem->ua < (ua + (entries << PAGE_SHIFT))) &&
> + (ua < (mem->ua + (mem->entries << PAGE_SHIFT
> + return -EINVAL;
> + }
> +
> + mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> + if (!mem)
> + return -ENOMEM;
> +
> + mem->hpas = vzalloc(entries * sizeof(mem->hpas[0]));
> + if (!mem->hpas) {
> + kfree(mem);
> + return -ENOMEM;
> + }
So, I've thought more about this and I'm really confused as to what
this is supposed to be accomplishing.
I see that you need to keep track of what regions are registered, so
you don't double lock or unlock, but I don't see what the point of
actualy storing the translations in hpas is.
I had assumed it was so that you could later on get to the
translations in real mode when you do in-kernel acceleration. But
that doesn't make sense, because the array is vmalloc()ed, so can't be
accessed in real mode anyway.
I can't think of a circumstance in which you can use hpas where you
couldn't just walk the page tables anyway.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgp3Mex2oI7fG.pgp
Description: PGP signature
Re: [PATCH kernel v9 29/32] vfio: powerpc/spapr: Register memory and define IOMMU v2
On Sat, Apr 25, 2015 at 10:14:53PM +1000, Alexey Kardashevskiy wrote: > The existing implementation accounts the whole DMA window in > the locked_vm counter. This is going to be worse with multiple > containers and huge DMA windows. Also, real-time accounting would requite > additional tracking of accounted pages due to the page size difference - > IOMMU uses 4K pages and system uses 4K or 64K pages. > > Another issue is that actual pages pinning/unpinning happens on every > DMA map/unmap request. This does not affect the performance much now as > we spend way too much time now on switching context between > guest/userspace/host but this will start to matter when we add in-kernel > DMA map/unmap acceleration. > > This introduces a new IOMMU type for SPAPR - VFIO_SPAPR_TCE_v2_IOMMU. > New IOMMU deprecates VFIO_IOMMU_ENABLE/VFIO_IOMMU_DISABLE and introduces > 2 new ioctls to register/unregister DMA memory - > VFIO_IOMMU_SPAPR_REGISTER_MEMORY and VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY - > which receive user space address and size of a memory region which > needs to be pinned/unpinned and counted in locked_vm. > New IOMMU splits physical pages pinning and TCE table update into 2 different > operations. It requires 1) guest pages to be registered first 2) consequent > map/unmap requests to work only with pre-registered memory. > For the default single window case this means that the entire guest > (instead of 2GB) needs to be pinned before using VFIO. > When a huge DMA window is added, no additional pinning will be > required, otherwise it would be guest RAM + 2GB. > > The new memory registration ioctls are not supported by > VFIO_SPAPR_TCE_IOMMU. Dynamic DMA window and in-kernel acceleration > will require memory to be preregistered in order to work. > > The accounting is done per the user process. > > This advertises v2 SPAPR TCE IOMMU and restricts what the userspace > can do with v1 or v2 IOMMUs. > > Signed-off-by: Alexey Kardashevskiy > [aw: for the vfio related changes] > Acked-by: Alex Williamson > --- > Changes: > v9: > * s/tce_get_hva_cached/tce_iommu_use_page_v2/ > > v7: > * now memory is registered per mm (i.e. process) > * moved memory registration code to powerpc/mmu > * merged "vfio: powerpc/spapr: Define v2 IOMMU" into this > * limited new ioctls to v2 IOMMU > * updated doc > * unsupported ioclts return -ENOTTY instead of -EPERM > > v6: > * tce_get_hva_cached() returns hva via a pointer > > v4: > * updated docs > * s/kzmalloc/vzalloc/ > * in tce_pin_pages()/tce_unpin_pages() removed @vaddr, @size and > replaced offset with index > * renamed vfio_iommu_type_register_memory to vfio_iommu_spapr_register_memory > and removed duplicating vfio_iommu_spapr_register_memory > --- > Documentation/vfio.txt | 23 > drivers/vfio/vfio_iommu_spapr_tce.c | 230 > +++- > include/uapi/linux/vfio.h | 27 + > 3 files changed, 274 insertions(+), 6 deletions(-) > > diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt > index 96978ec..94328c8 100644 > --- a/Documentation/vfio.txt > +++ b/Documentation/vfio.txt > @@ -427,6 +427,29 @@ The code flow from the example above should be slightly > changed: > > > > +5) There is v2 of SPAPR TCE IOMMU. It deprecates VFIO_IOMMU_ENABLE/ > +VFIO_IOMMU_DISABLE and implements 2 new ioctls: > +VFIO_IOMMU_SPAPR_REGISTER_MEMORY and VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY > +(which are unsupported in v1 IOMMU). A summary of the semantic differeces between v1 and v2 would be nice. At this point it's not really clear to me if there's a case for creating v2, or if this could just be done by adding (optional) functionality to v1. > +PPC64 paravirtualized guests generate a lot of map/unmap requests, > +and the handling of those includes pinning/unpinning pages and updating > +mm::locked_vm counter to make sure we do not exceed the rlimit. > +The v2 IOMMU splits accounting and pinning into separate operations: > + > +- VFIO_IOMMU_SPAPR_REGISTER_MEMORY/VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY ioctls > +receive a user space address and size of the block to be pinned. > +Bisecting is not supported and VFIO_IOMMU_UNREGISTER_MEMORY is expected to > +be called with the exact address and size used for registering > +the memory block. The userspace is not expected to call these often. > +The ranges are stored in a linked list in a VFIO container. > + > +- VFIO_IOMMU_MAP_DMA/VFIO_IOMMU_UNMAP_DMA ioctls only update the actual > +IOMMU table and do not do pinning; instead these check that the userspace > +address is from pre-registered range. > + > +This separation helps in optimizing DMA for guests. > + > > --- > > [1] VFIO was originally an acronym for "Virtual Function I/O" in its > diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c > b/drivers/vfio/vfio_iommu_spapr_tce.c > index 892a584..4cfc2c1 100644 > --- a/drivers/vfio/vfio_iommu
Re: [PATCH kernel v9 30/32] vfio: powerpc/spapr: Use 32bit DMA window properties from table_group
On Sat, Apr 25, 2015 at 10:14:54PM +1000, Alexey Kardashevskiy wrote: > A table group might not have a table but it always has the default 32bit > window parameters so use these. > > No change in behavior is expected. > > Signed-off-by: Alexey Kardashevskiy It would be easier to review if you took this and the parts of the earlier patch which add the tce32_* fields to table_group and roll them up on their own. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpJAXALIrdm2.pgp Description: PGP signature
Re: [PATCH v3 1/2] PM / sleep: Let devices force direct_complete
On 20 April 2015 at 16:12, Alan Stern wrote: > On Mon, 20 Apr 2015, Tomeu Vizoso wrote: > >> On 17 April 2015 at 19:30, Alan Stern wrote: >> > On Fri, 17 Apr 2015, Laurent Pinchart wrote: >> > >> >> Hi Tomeu, >> >> >> >> Thank you for the patch. >> >> >> >> On Friday 17 April 2015 17:24:49 Tomeu Vizoso wrote: >> >> > Introduce a new per-device flag power.force_direct_complete that will >> >> > instruct the PM core to ignore the runtime PM status of its descendants >> >> > when deciding whether to let this device remain in runtime suspend when >> >> > the system goes into a sleep power state. >> >> > >> >> > This is needed because otherwise it would be needed to get dozens of >> >> > drivers to implement the prepare() callback and be runtime PM active >> >> > even if they don't have a 1-to-1 relationship with a piece of HW. >> >> >> >> I'll let PM experts comment on the approach, but I believe the new flag >> >> would >> >> benefit from being documented (likely in Documentation/power/devices.txt) >> >> :-) >> > >> > Documentation/power/runtime_pm.txt is the right place. >> > >> > However, I'm not sure that this is the sort of thing Rafael meant when >> > he suggested adding a new flag. I thought he meant the PM core would >> > look at the new flag only if there was no ->prepare method at all. >> > Then if the new flag was set, the PM core would act as though ->prepare >> > had returned 1. That way there would be no need to add silly little >> > one-line *_prepare() routines all over the place. >> > >> > Maybe he had something else in mind, though... >> >> Yeah, I also interpreted it like that, but when I started looking at >> how it would work, I found that it would be awkward if the uvcvideo >> driver had to track all the devices that get attached below its >> devices in order to set that flag to them. >> >> When thinking about it, it occurred to me that it may make more sense >> if we model this as a property of the device bound to the uvcvideo >> driver, as what's happening here is that the uvcvideo driver knows >> that it's safe to remain in runtime suspend when the system goes to >> sleep, and that all its descendant devices can be ignored in that >> regard. > > What you're proposing makes sense, but it is a significant change to > the runtime PM core. It should be submitted separately, not as part of > an update to the UVC driver, and it should be discussed at length. > > Basically, you want to mark certain devices to say that they will > _always_ use direct-suspend. This means that all descendant devices > will be forced to use direct-suspend also, and therefore any driver > bound to one of these descendant devices will be unable to communicate > with it during a system sleep transition. This is a non-trivial > restriction. > > Among other things, it means that wakeup settings can't be altered > during a sleep transition. Therefore this should be allowed only for > devices that are not wakeup-capable. > I hesitated to send this reply, since it might add confusion. If that's the case, please ignore it. I have a long term vision to fully enable support for a runtime PM centric configuration for drivers/subsystems. The idea is, that such driver/subsystem should get system PM for "free". The main goal is to simplify PM implementation for these drivers/subsystems. They should need to implement the runtime PM callbacks only and not the system PM ones. During system PM suspend, the requirement is that the corresponding devices should be guaranteed to be "runtime PM suspended". Somehow that then needs to be managed by the PM core. I am not sure it's doable, but I wanted to bring it up within the context of $subject patch, since it proposes yet another optimization path for runtime PM during system PM. Kind regards Uffe -- 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/7] ARM: at91/dt: at91-kizbox: sanitize file
On 29/04/2015 01:34, Alexandre Belloni wrote: On 21/04/2015 at 14:05:13 +0200, Gaël PORTAY wrote : Consists in: * sorting nodes by address as possible or alphabetically, * adding myself as new maintainer and * update license. Signed-off-by: Gaël PORTAY --- arch/arm/boot/dts/at91-kizbox.dts | 67 +++ 1 file changed, 32 insertions(+), 35 deletions(-) diff --git a/arch/arm/boot/dts/at91-kizbox.dts b/arch/arm/boot/dts/at91-kizbox.dts index e83e4f9..00c86c1 100644 --- a/arch/arm/boot/dts/at91-kizbox.dts +++ b/arch/arm/boot/dts/at91-kizbox.dts @@ -1,16 +1,16 @@ /* - * kizbox.dts - Device Tree file for Overkiz Kizbox board + * at91-kizbox.dts - Device Tree file for Overkiz Kizbox board * My guess is that this should be part of the previous patch Indeed... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] md/raid5: fix typo
On Thu, 30 Apr 2015 15:01:16 +0800 Yuanhan Liu wrote: > bion -> bios > > Signed-off-by: Yuanhan Liu > --- > drivers/md/raid5.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c > index 697d77a..2651bda 100644 > --- a/drivers/md/raid5.c > +++ b/drivers/md/raid5.c > @@ -2919,7 +2919,7 @@ schedule_reconstruction(struct stripe_head *sh, struct > stripe_head_state *s, > } > > /* > - * Each stripe/dev can have one or more bion attached. > + * Each stripe/dev can have one or more bios attached. > * toread/towrite point to the first in a chain. > * The bi_next chain must be in order. > */ That was intentional. "bios" as a plural looks too much like "BIOS" which is in the ROM of computers. Children and oxen are plurals with an 'n' at the end. So I used 'bion'. Private joke? I'd rather leave it as it is. Thanks, NeilBrown pgpaylIgnkTjU.pgp Description: OpenPGP digital signature
[v4 2/3] x86, irq: Implement irq_set_vcpu_affinity for pci_msi_ir_controller
Implement irq_set_vcpu_affinity for pci_msi_ir_controller.
Signed-off-by: Feng Wu
Reviewed-by: Jiang Liu
---
arch/x86/kernel/apic/msi.c | 1 +
include/linux/irq.h| 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 58fde66..d2d95e2 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -152,6 +152,7 @@ static struct irq_chip pci_msi_ir_controller = {
.irq_mask = pci_msi_mask_irq,
.irq_ack= irq_chip_ack_parent,
.irq_retrigger = irq_chip_retrigger_hierarchy,
+ .irq_set_vcpu_affinity = irq_chip_set_vcpu_affinity_parent,
.flags = IRQCHIP_SKIP_SET_WAKE,
};
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 684c35d..cb688fb 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -471,6 +471,8 @@ extern int irq_chip_set_affinity_parent(struct irq_data
*data,
const struct cpumask *dest,
bool force);
extern int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on);
+extern int irq_chip_set_vcpu_affinity_parent(struct irq_data *data,
+void *vcpu_info);
#endif
/* Handling of unhandled and spurious interrupts: */
--
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/
[v4 1/3] genirq: Introduce irq_set_vcpu_affinity() to target an interrupt to a VCPU
With Posted-Interrupts support in Intel CPU and IOMMU, an external
interrupt from assigned-devices could be directly delivered to a
virtual CPU in a virtual machine. Instead of hacking KVM and Intel
IOMMU drivers, we propose a platform independent interface to target
an interrupt to a specific virtual CPU in a virtual machine, or set
virtual CPU affinity for an interrupt.
By adopting this new interface and the hierarchy irqdomain, we could
easily support posted-interrupts on Intel platforms, and also provide
flexible enough interfaces for other platforms to support similar
features.
Here is the usage scenario for this interface:
Guest update MSI/MSI-X interrupt configuration
-->QEMU and KVM handle this
-->KVM call this interface (passing posted interrupts descriptor
and guest vector)
-->irq core will transfer the control to IOMMU
-->IOMMU will do the real work of updating IRTE (IRTE has new
format for VT-d Posted-Interrupts)
Signed-off-by: Jiang Liu
Signed-off-by: Feng Wu
---
include/linux/irq.h | 4
kernel/irq/chip.c | 14 ++
kernel/irq/manage.c | 20
3 files changed, 38 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 62c6901..684c35d 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -327,6 +327,7 @@ static inline irq_hw_number_t irqd_to_hwirq(struct irq_data
*d)
* @irq_write_msi_msg: optional to write message content for MSI
* @irq_get_irqchip_state: return the internal state of an interrupt
* @irq_set_irqchip_state: set the internal state of a interrupt
+ * @irq_set_vcpu_affinity: optional to target a virtual CPU in a virtual
* @flags: chip specific flags
*/
struct irq_chip {
@@ -369,6 +370,8 @@ struct irq_chip {
int (*irq_get_irqchip_state)(struct irq_data *data, enum
irqchip_irq_state which, bool *state);
int (*irq_set_irqchip_state)(struct irq_data *data, enum
irqchip_irq_state which, bool state);
+ int (*irq_set_vcpu_affinity)(struct irq_data *data, void
*vcpu_info);
+
unsigned long flags;
};
@@ -422,6 +425,7 @@ extern void irq_cpu_online(void);
extern void irq_cpu_offline(void);
extern int irq_set_affinity_locked(struct irq_data *data,
const struct cpumask *cpumask, bool force);
+extern int irq_set_vcpu_affinity(unsigned int irq, void *vcpu_info);
#if defined(CONFIG_SMP) && defined(CONFIG_GENERIC_PENDING_IRQ)
void irq_move_irq(struct irq_data *data);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index eb9a4ea..55016b2 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -950,6 +950,20 @@ int irq_chip_retrigger_hierarchy(struct irq_data *data)
}
/**
+ * irq_chip_set_vcpu_affinity_parent - Set vcpu affinity on the parent
interrupt
+ * @data: Pointer to interrupt specific data
+ * @dest: The vcpu affinity information
+ */
+int irq_chip_set_vcpu_affinity_parent(struct irq_data *data, void *vcpu_info)
+{
+ data = data->parent_data;
+ if (data->chip->irq_set_vcpu_affinity)
+ return data->chip->irq_set_vcpu_affinity(data, vcpu_info);
+
+ return -ENOSYS;
+}
+
+/**
* irq_chip_set_wake_parent - Set/reset wake-up on the parent interrupt
* @data: Pointer to interrupt specific data
* @on:Whether to set or reset the wake-up capability of this
irq
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index e68932b..5e09bc2 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -256,6 +256,26 @@ int irq_set_affinity_hint(unsigned int irq, const struct
cpumask *m)
}
EXPORT_SYMBOL_GPL(irq_set_affinity_hint);
+int irq_set_vcpu_affinity(unsigned int irq, void *vcpu_info)
+{
+ struct irq_desc *desc = irq_to_desc(irq);
+ struct irq_chip *chip;
+ unsigned long flags;
+ int ret = -ENOSYS;
+
+ if (!desc)
+ return -EINVAL;
+
+ raw_spin_lock_irqsave(&desc->lock, flags);
+ chip = desc->irq_data.chip;
+ if (chip && chip->irq_set_vcpu_affinity)
+ ret = chip->irq_set_vcpu_affinity(irq_desc_get_irq_data(desc),
+ vcpu_info);
+ raw_spin_unlock_irqrestore(&desc->lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(irq_set_vcpu_affinity);
+
static void irq_affinity_notify(struct work_struct *work)
{
struct irq_affinity_notify *notify =
--
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/
[v4 0/3] prerequisite changes for VT-d posted-interrupts
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt. With VT-d Posted-Interrupts enabled, external interrupts from direct-assigned devices can be delivered to guests without VMM intervention when guest is running in non-root mode. You can find the VT-d Posted-Interrtups Spec. in the following URL: http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html This series implement some prerequisite parts for VT-d posted-interrupts. It was part of http://thread.gmane.org/gmane.linux.kernel.iommu/7708. To make things clear, I will divide the whole series which contain multiple components into three parts: - prerequisite changes (included in this series) - IOMMU part (v4 was reviewed, some comments need to be addressed) - KVM and VFIO parts (will send out this part once the first two parts are accepted) This series is rebased on the x86-apic branch of tip tree. Feng Wu (3): genirq: Introduce irq_set_vcpu_affinity() to target an interrupt to a VCPU x86, irq: Implement irq_set_vcpu_affinity for pci_msi_ir_controller x86, irq: Define a global vector for VT-d Posted-Interrupts arch/x86/include/asm/entry_arch.h | 2 ++ arch/x86/include/asm/hardirq.h | 1 + arch/x86/include/asm/hw_irq.h | 2 ++ arch/x86/include/asm/irq_vectors.h | 1 + arch/x86/kernel/apic/msi.c | 1 + arch/x86/kernel/entry_64.S | 2 ++ arch/x86/kernel/irq.c | 27 +++ arch/x86/kernel/irqinit.c | 2 ++ include/linux/irq.h| 6 ++ kernel/irq/chip.c | 14 ++ kernel/irq/manage.c| 20 11 files changed, 78 insertions(+) -- 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/
[v4 3/3] x86, irq: Define a global vector for VT-d Posted-Interrupts
Currently, we use a global vector as the Posted-Interrupts
Notification Event for all the vCPUs in the system. We need
to introduce another global vector for VT-d Posted-Interrtups,
which will be used to wakeup the sleep vCPU when an external
interrupt from a direct-assigned device happens for that vCPU.
Signed-off-by: Feng Wu
Suggested-by: Yang Zhang
Acked-by: H. Peter Anvin
---
arch/x86/include/asm/entry_arch.h | 2 ++
arch/x86/include/asm/hardirq.h | 1 +
arch/x86/include/asm/hw_irq.h | 2 ++
arch/x86/include/asm/irq_vectors.h | 1 +
arch/x86/kernel/entry_64.S | 2 ++
arch/x86/kernel/irq.c | 27 +++
arch/x86/kernel/irqinit.c | 2 ++
7 files changed, 37 insertions(+)
diff --git a/arch/x86/include/asm/entry_arch.h
b/arch/x86/include/asm/entry_arch.h
index dc5fa66..27ca0af 100644
--- a/arch/x86/include/asm/entry_arch.h
+++ b/arch/x86/include/asm/entry_arch.h
@@ -23,6 +23,8 @@ BUILD_INTERRUPT(x86_platform_ipi, X86_PLATFORM_IPI_VECTOR)
#ifdef CONFIG_HAVE_KVM
BUILD_INTERRUPT3(kvm_posted_intr_ipi, POSTED_INTR_VECTOR,
smp_kvm_posted_intr_ipi)
+BUILD_INTERRUPT3(kvm_posted_intr_wakeup_ipi, POSTED_INTR_WAKEUP_VECTOR,
+smp_kvm_posted_intr_wakeup_ipi)
#endif
/*
diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
index 0f5fb6b..9866065 100644
--- a/arch/x86/include/asm/hardirq.h
+++ b/arch/x86/include/asm/hardirq.h
@@ -14,6 +14,7 @@ typedef struct {
#endif
#ifdef CONFIG_HAVE_KVM
unsigned int kvm_posted_intr_ipis;
+ unsigned int kvm_posted_intr_wakeup_ipis;
#endif
unsigned int x86_platform_ipis; /* arch dependent */
unsigned int apic_perf_irqs;
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 1f88e71..6ffc847 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -29,6 +29,7 @@
extern asmlinkage void apic_timer_interrupt(void);
extern asmlinkage void x86_platform_ipi(void);
extern asmlinkage void kvm_posted_intr_ipi(void);
+extern asmlinkage void kvm_posted_intr_wakeup_ipi(void);
extern asmlinkage void error_interrupt(void);
extern asmlinkage void irq_work_interrupt(void);
@@ -92,6 +93,7 @@ extern void trace_call_function_single_interrupt(void);
#define trace_irq_move_cleanup_interrupt irq_move_cleanup_interrupt
#define trace_reboot_interrupt reboot_interrupt
#define trace_kvm_posted_intr_ipi kvm_posted_intr_ipi
+#define trace_kvm_posted_intr_wakeup_ipi kvm_posted_intr_wakeup_ipi
#endif /* CONFIG_TRACING */
#ifdef CONFIG_X86_LOCAL_APIC
diff --git a/arch/x86/include/asm/irq_vectors.h
b/arch/x86/include/asm/irq_vectors.h
index b26cb12..dca94f2 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -105,6 +105,7 @@
/* Vector for KVM to deliver posted interrupt IPI */
#ifdef CONFIG_HAVE_KVM
#define POSTED_INTR_VECTOR 0xf2
+#define POSTED_INTR_WAKEUP_VECTOR 0xf1
#endif
/*
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index c7b2384..177feec 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -919,6 +919,8 @@ apicinterrupt X86_PLATFORM_IPI_VECTOR \
#ifdef CONFIG_HAVE_KVM
apicinterrupt3 POSTED_INTR_VECTOR \
kvm_posted_intr_ipi smp_kvm_posted_intr_ipi
+apicinterrupt3 POSTED_INTR_WAKEUP_VECTOR \
+ kvm_posted_intr_wakeup_ipi smp_kvm_posted_intr_wakeup_ipi
#endif
#ifdef CONFIG_X86_MCE_THRESHOLD
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index e5952c2..81b6bf8 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -237,6 +237,9 @@ __visible void smp_x86_platform_ipi(struct pt_regs *regs)
}
#ifdef CONFIG_HAVE_KVM
+void (*wakeup_handler_callback)(void);
+EXPORT_SYMBOL_GPL(wakeup_handler_callback);
+
/*
* Handler for POSTED_INTERRUPT_VECTOR.
*/
@@ -256,6 +259,30 @@ __visible void smp_kvm_posted_intr_ipi(struct pt_regs
*regs)
set_irq_regs(old_regs);
}
+
+/*
+ * Handler for POSTED_INTERRUPT_WAKEUP_VECTOR.
+ */
+__visible void smp_kvm_posted_intr_wakeup_ipi(struct pt_regs *regs)
+{
+ struct pt_regs *old_regs = set_irq_regs(regs);
+
+ ack_APIC_irq();
+
+ irq_enter();
+
+ exit_idle();
+
+ inc_irq_stat(kvm_posted_intr_wakeup_ipis);
+
+ if (wakeup_handler_callback)
+ wakeup_handler_callback();
+
+ irq_exit();
+
+ set_irq_regs(old_regs);
+}
+
#endif
__visible void smp_trace_x86_platform_ipi(struct pt_regs *regs)
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index cd10a64..895941d 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -144,6 +144,8 @@ static void __init apic_intr_init(void)
#ifdef CONFIG_HAVE_KVM
/* IPI for KVM to deliver posted interrupt */
alloc_intr_gate(POSTED_INTR_VECTOR, kvm_posted_intr_ipi);
+ /* IPI for KVM to deliver interrupt to wake up tasks */
+ alloc_intr_gate(PO
Re: [PATCH 2/2] md/raid5: trivial coding style fix
On Thu, 30 Apr 2015 15:01:17 +0800 Yuanhan Liu
wrote:
> Signed-off-by: Yuanhan Liu
> ---
> drivers/md/raid5.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 2651bda..bae3e2c 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -5789,8 +5789,7 @@ static void raid5d(struct md_thread *thread)
> if (released)
> clear_bit(R5_DID_ALLOC, &conf->cache_state);
>
> - if (
> - !list_empty(&conf->bitmap_list)) {
> + if (!list_empty(&conf->bitmap_list)) {
> /* Now is a good time to flush some bitmap updates */
> conf->seq_flush++;
> spin_unlock_irq(&conf->device_lock);
I'm happy for these sorts of changes when you are fixing up nearby code, or
if the change significantly improves readability.
But I'd rather not bother is one-off trivial fixes like this.
Thanks anyway,
NeilBrown
pgpP_X3tGMOpR.pgp
Description: OpenPGP digital signature
Re: [PATCH 3/8] drivers/mfd: Add lookup table for Panel Control as GPIO signal
On 04/29/2015 07:57 PM, Lee Jones wrote:
> On Wed, 29 Apr 2015, Shobhit Kumar wrote:
>
>> On some Intel SoC platforms, the panel enable/disable signals are
>> controlled by CRC PMIC. Add those control as a new GPIO in a lookup
>> table for gpio-crystalcove chip during CRC driver load
>>
>> v2: Make the lookup table static (Thierry)
>> Remove the lookup table during driver remove (Thierry)
>>
>> CC: Samuel Ortiz
>> Cc: Linus Walleij
>> Cc: Alexandre Courbot
>> Cc: Thierry Reding
>> Signed-off-by: Shobhit Kumar
>> ---
>> drivers/mfd/intel_soc_pmic_core.c | 17 +
>> 1 file changed, 17 insertions(+)
>
> I have no idea what this stuff is, but it looks plausible.
The CRC PMIC controls the panel enable/disable signal using one of GPIO
like lines. It was agreed by Linus Walleij to go this way. The matching
crystalcove gpio changes are already merged in Linux next as -
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=e189ca56d91bbf1d3fe2f88ab6858bf919d42adf
This just adds a consumer lookup table for the gpio. Since we do not
have a DT or board files, and since this was part of CRC driver, just
added the lookup table during CRC driver load itself. Same is done for
PWM in a later patch.
Regards
Shobhit
>
> For my own reference:
> Acked-by: Lee Jones
>
>> diff --git a/drivers/mfd/intel_soc_pmic_core.c
>> b/drivers/mfd/intel_soc_pmic_core.c
>> index 7b50b6b..f3d918e 100644
>> --- a/drivers/mfd/intel_soc_pmic_core.c
>> +++ b/drivers/mfd/intel_soc_pmic_core.c
>> @@ -24,8 +24,19 @@
>> #include
>> #include
>> #include
>> +#include
>> #include "intel_soc_pmic_core.h"
>>
>> +/* Lookup table for the Panel Enable/Disable line as GPIO signals */
>> +static struct gpiod_lookup_table panel_gpio_table = {
>> +/* Intel GFX is consumer */
>> +.dev_id = ":00:02.0",
>> +.table = {
>> +/* Panel EN/DISABLE */
>> +GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
>> +},
>> +};
>> +
>> static int intel_soc_pmic_find_gpio_irq(struct device *dev)
>> {
>> struct gpio_desc *desc;
>> @@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
>> if (ret)
>> dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);
>>
>> +/* Add lookup table binding for Panel Control to the GPIO Chip */
>> +gpiod_add_lookup_table(&panel_gpio_table);
>> +
>> ret = mfd_add_devices(dev, -1, config->cell_dev,
>>config->n_cell_devs, NULL, 0,
>>regmap_irq_get_domain(pmic->irq_chip_data));
>> @@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client
>> *i2c)
>>
>> regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
>>
>> +/* Remove lookup table for Panel Control from the GPIO Chip */
>> +gpiod_remove_lookup_table(&panel_gpio_table);
>> +
>> mfd_remove_devices(&i2c->dev);
>>
>> return 0;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] coresight: replicator: Add Qualcomm CoreSight Replicator driver
On Wed, 2015-04-29 at 10:28 -0600, Mathieu Poirier wrote: > On 29 April 2015 at 06:19, Ivan T. Ivanov iva...@linaro.org> wrote: > > - "arm,coresight-etm4x", "arm,primecell"; > > + - "qcom,coresight-replicator", "arm,primecell"; > > Is there some sort of versioning information we can add like it was > done for the "coresight-etmXY" bindings? It makes things a lot > cleaner when a new (and possibly not backward compatible) version gets > released. > >From what I can see, it is version 1. I could add it to compatible string, but suldn't we use amba_id for this reason. > > * reg: physical base address and length of the register > > set(s) of the component. > > diff --git a/drivers/hwtracing/coresight/Kconfig > > b/drivers/hwtracing/coresight/Kconfig > > index 6b331d4..165b681 100644 > > --- a/drivers/hwtracing/coresight/Kconfig > > +++ b/drivers/hwtracing/coresight/Kconfig > > @@ -68,4 +68,13 @@ config CORESIGHT_SOURCE_ETM4X > > instructions that a processor is executing. This is primarily > > useful > > for instruction level tracing. Depending on the implemented > > version > > data tracing may also be available. > > + > > +config CORESIGHT_QCOM_REPLICATOR > > + bool "Qualcomm CoreSight Replicator driver" > > + help > > + This enables support for CoreSight link and sink driver that are > > + responsible for transporting and collecting the trace data > > + respectively. Link and sinks are dynamically aggregated with a > > trace > > + entity at run time to form a complete trace path. > > The replicator is only a link entity. It is only transporting trace > data information rather than collecting it. Please review the > comment. True, sorry. copy and paste from CORESIGHT_LINKS_AND_SINKS. > Also, can this specific version run on both V7 and V8 > architecture. If not the proper "depends" should be added. > Same driver/device on both architectures. Will fix rest of the comments and will resend. Thank you, Ivan -- 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] md/raid5: trivial coding style fix
On Thu, Apr 30, 2015 at 05:16:50PM +1000, NeilBrown wrote:
> On Thu, 30 Apr 2015 15:01:17 +0800 Yuanhan Liu
> wrote:
>
> > Signed-off-by: Yuanhan Liu
> > ---
> > drivers/md/raid5.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> > index 2651bda..bae3e2c 100644
> > --- a/drivers/md/raid5.c
> > +++ b/drivers/md/raid5.c
> > @@ -5789,8 +5789,7 @@ static void raid5d(struct md_thread *thread)
> > if (released)
> > clear_bit(R5_DID_ALLOC, &conf->cache_state);
> >
> > - if (
> > - !list_empty(&conf->bitmap_list)) {
> > + if (!list_empty(&conf->bitmap_list)) {
> > /* Now is a good time to flush some bitmap updates */
> > conf->seq_flush++;
> > spin_unlock_irq(&conf->device_lock);
>
>
> I'm happy for these sorts of changes when you are fixing up nearby code, or
> if the change significantly improves readability.
> But I'd rather not bother is one-off trivial fixes like this.
Got it.
--yliu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] md/raid5: fix typo
On Thu, Apr 30, 2015 at 05:14:26PM +1000, NeilBrown wrote: > On Thu, 30 Apr 2015 15:01:16 +0800 Yuanhan Liu > wrote: > > > bion -> bios > > > > Signed-off-by: Yuanhan Liu > > --- > > drivers/md/raid5.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c > > index 697d77a..2651bda 100644 > > --- a/drivers/md/raid5.c > > +++ b/drivers/md/raid5.c > > @@ -2919,7 +2919,7 @@ schedule_reconstruction(struct stripe_head *sh, > > struct stripe_head_state *s, > > } > > > > /* > > - * Each stripe/dev can have one or more bion attached. > > + * Each stripe/dev can have one or more bios attached. > > * toread/towrite point to the first in a chain. > > * The bi_next chain must be in order. > > */ > > That was intentional. "bios" as a plural looks too much like "BIOS" which is > in the ROM of computers. > > Children and oxen are plurals with an 'n' at the end. So I used 'bion'. > Private joke? Interesting. > > I'd rather leave it as it is. Okay, and sorry for the noise. --yliu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm64: dts: qcom: Add msm8916 CoreSight components
On Wed, 2015-04-29 at 10:49 -0600, Mathieu Poirier wrote: > On 29 April 2015 at 06:20, Ivan T. Ivanov iva...@linaro.org> wrote: > > Add initial set of CoreSight components found on Qualcomm's 8x16 chipset. > > > Please add a comment indicating what the other ports are connected to. > Thank you. Will fix and resend. Ivan -- 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] xen: vcpu_info reinit error after 'xl save -c' & 'xl restore' on PVOPS VM which has multi-cpu
On 2015.4.29 5:31, Boris Ostrovsky wrote:
> On 04/28/2015 08:30 AM, Ouyang Zhaowei (Charles) wrote:
>>
>> On 2015.4.26 7:31, Boris Ostrovsky wrote:
>>> On 04/24/2015 05:30 AM, Ouyang Zhaowei (Charles) wrote:
If a PVOPS VM has multi-cpu the vcpu_info of cpu0 is the member of the
structure HYPERVISOR_shared_info,
and the others is not, but after 'xl save -c/restore' the vcpu_info will
be reinitialized,
the vcpu_info of all the vcpus will be considered as the member of
HYPERVISOR_shared_info.
This will cause the cpu1 and other cpu keep receiving interrupts, and the
cpu0 is waiting them to
finish the job.
So we do not reinit the vcpu_info when PVOPS vm is doing 'xl save
-c/restore'.
Signed-off-by: Charles Ouyang
---
arch/x86/xen/suspend.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index d949769..b2bed45 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -32,7 +32,8 @@ static void xen_hvm_post_suspend(int suspend_cancelled)
{
#ifdef CONFIG_XEN_PVHVM
int cpu;
- xen_hvm_init_shared_info();
+ if (!suspend_cancelled)
+ xen_hvm_init_shared_info();
xen_callback_vector();
xen_unplug_emulated_devices();
if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
>>> Do we need to call other routines if suspend is canceled?
>>>
>>> Also, if suspend is canceled then we don't do xen_irq_resume() if that's
>>> what you meant by "vcpu_info will be reinitialized". Were you referring
>>> some other re-initialization?
>>>
>> Hi Boris,
>>
>> Sorry I didn't make myself clear.
>>
>> About the "vcpu_info reinitialize", I mean in the function
>> "xen_hvm_init_shared_info()" the pointer "xen_vcpu" will be reset and all
>> point to HYPERVISOR_shared_info->vcpu_info[cpu].
>>
>> void __ref xen_hvm_init_shared_info(void)
>>
>> 1702 * When xen_hvm_init_shared_info is run at boot time only vcpu
>> 0 is
>> 1703 * online but xen_hvm_init_shared_info is run at resume time
>> too and
>> 1704 * in that case multiple vcpus might be online. */
>> 1705 for_each_online_cpu(cpu) {
>> 1706 /* Leave it to be NULL. */
>> 1707 if (cpu >= MAX_VIRT_CPUS)
>> 1708 continue;
>> 1709 per_cpu(xen_vcpu, cpu) =
>> &HYPERVISOR_shared_info->vcpu_info[cpu];
>> 1710 }
>> 1711 }
>>
>>
>> But on Xen boot the init function "xen_start_kernel" only set the cpu0 to
>> point to HYPERVISOR_shared_info->vcpu_info[0]
>>
>> asmlinkage __visible void __init xen_start_kernel(void)
>
>
> We are talking about HVM guests here and xen_start_kernel is only called for
> PV. But even if it was, xen_vcpu pointers for other VCPUs are set in
> xen_vcpu_setup(), which is called when non-boot VCPUs are coming up.
>
> And I wonder whether the actual problem is that we don't call
> xen_vcpu_setup() on canceled suspend (as we don't need to, really) and
> therefore if we call xen_hvm_init_shared_info() then per_cpu(xen_vcpu,cpu)
> for *non-boot* cpus is will become wrong.
>
Yes, you are right, in xen_vcpu_setup() non-boot VCPUs is set to point to
xen_vcpu_info
static void xen_vcpu_setup(int cpu)
208 vcpup = &per_cpu(xen_vcpu_info, cpu);
...
227 /* This cpu is using the registered vcpu info, even if
228later ones fail to. */
229 per_cpu(xen_vcpu, cpu) = vcpup;
But on canceled suspend if we call xen_hvm_init_shared_info(), the non-boot
VCPUS will be reset to point to HYPERVISOR_shared_info->vcpu_info[cpu] which is
a wrong address.
So I suggest we don't call xen_hvm_init_shared_info() when suspend is canceled.
> -boris
>
>>
>> 1563 /* Don't do the full vcpu_info placement stuff until we have a
>> 1564possible map and a non-dummy shared_info. */
>> 1565 per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
>> 1566
>> 1567 local_irq_disable();
>>
>> Other cpus are set to point to "xen_vcpu_info" in function xen_vcpu_setup().
>>
>> So after xl save -c/restore, the pointer xen_vcpu will be reset in function
>> "xen_hvm_init_shared_info" and point to a wrong place.
>> This may cause all the cpus cannot handle irqs except cpu0, so IMHO it's not
>> necessary to call xen_hvm_init_shared_info again if
>> suspend is canceled.
>>
>>> (The patch itself looks like the right thing to do though).
>>>
>>> -boris
>>>
>>> .
>>>
>
>
> .
>
--
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 v7 04/23] IB/Verbs: Reform IB-core cm
On 04/29/2015 05:48 PM, Or Gerlitz wrote: [snip] > >> >> I think the CC list is not that big for a patch set covered such a wide >> range, isn't it :-P > > Maybe it's a matter of taste, but for me it look way way too big. If > you really want to have such > a huge listing, do it in the early patches of the series where you > introduce the new concepts, and later,on downstream patches, when you > use it, put one person if they happen to be the author or maintainthat > area (e.g Sean <-- CM/CMA, Doug/Erez <-- IPoIB Ira, Hal <-- MAD, Steve > <-- IW_CM, etc) Thanks for the suggestion, I can't callback correctly who participated on which part of the review accurately... my bad, will take care next time :-) and will stop add new CC from now on. BTW, as now folks already familiar with the cap_XX stuff, may be the last version to be applied could merge all the cap_XX into one, after all, it's more focus on the description rather than logical, separate cap_XX won't help easier the review anyway. Regards, Michael Wang > > Or. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection
On 16/04/15 11:26, Chanwoo Choi wrote:
> On 04/16/2015 05:01 PM, Peter Chen wrote:
>> On Thu, Apr 16, 2015 at 04:59:31PM +0900, Chanwoo Choi wrote:
>>> On 04/16/2015 04:13 PM, Ivan T. Ivanov wrote:
Hi,
On Thu, 2015-04-16 at 16:00 +0900, Chanwoo Choi wrote:
> Hi Peter,
>
> On 04/16/2015 10:59 AM, Peter Chen wrote:
>>
>> Ok, from USB point, external id/vbus value can't decide
>> which role the controller will be, the controller driver
>> will decide role according to many things, eg, user configurations,
>> id/vbus value, OTG HNP, etc.
>>
>> So, from USB controller/phy driver, it doesn't care which cable is
>> inserted, it cares about id/vbus value. Eg, it can get id/vbus value
>> and it will be notified when the id/vbus value has changed.
>
> OK, I change the notifier name and add notifier events as following:
>
> - extcon_{register|unregister}_usb_notifier(struct extcon_dev *edev,
> struct notifier_block *nb);
> - list of notifier events
> #define EXTCON_USB_ID_L_VBUS_L0 /* ID low and VBUS low */
> #define EXTCON_USB_ID_L_VBUS_H1 /* ID low and VBUS high */
> #define EXTCON_USB_ID_H_VBUS_L2 /* ID high and VBUS low */
> #define EXTCON_USB_ID_H_VBUS_H3 /* ID high and VBUS high */
I am still confused, why we mix ID and VBUS events into one?
Those are two lines and they are not necessarily handled by
the same extcon_dev.
>>>
>>> IMO, if some usb driver check both id and vbus pin at the same time,
>>> the usb driver can know the both id and vbus pin state through only one
>>> notifier event.
>>>
>>> Also,
>>> If some usb driver want to know the state of id pin except of vbus state,
>>> when receiving following events, id pin is low.
>>> #define EXTCON_USB_ID_L_VBUS_L0
>>> #define EXTCON_USB_ID_L_VBUS_H1
>>> when receiving following events, id pin is high.
>>> #define EXTCON_USB_ID_H_VBUS_L2
>>> #define EXTCON_USB_ID_H_VBUS_H3
>>> Also, some usb driver would catch the vbus pin state with same method.
>>>
>>> But, it is just my opinion. We may use following notifier events for each
>>> pin.
>>> We need to discuss it.
>>> #define EXTCON_USB_ID_LOW
>>> #define EXTCON_USB_ID_HIGH
>>> #define EXTCON_USB_VBUS_LOW
>>> #define EXTCON_USB_VBUS_HIGH
>>>
>>
>> I agree with above definition.
>>
>
> OK. I understand.
>
>
Chanwoo, Robert,
Do we have an agreement on a common solution then?
IMO the above mentioned 4 notifier events should meet all our USB needs.
cheers,
-roger
--
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/7] ARM: at91/dt: at91-kizbox: leds related changes
This:
* moves to pwm-leds using tcb-pwm driver and
* renames leds to pwm::.
Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
---
arch/arm/boot/dts/at91-kizbox.dts | 53 +--
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/at91-kizbox.dts
b/arch/arm/boot/dts/at91-kizbox.dts
index 73e4559..b19f568 100644
--- a/arch/arm/boot/dts/at91-kizbox.dts
+++ b/arch/arm/boot/dts/at91-kizbox.dts
@@ -8,6 +8,7 @@
*/
/dts-v1/;
#include "at91sam9g20.dtsi"
+#include
/ {
model = "Overkiz Kizbox";
@@ -112,32 +113,46 @@
};
};
- leds {
- compatible = "gpio-leds";
+ pwm_leds {
+ compatible = "pwm-leds";
- led1g {
- label = "led1:green";
- gpios = <&pioB 0 GPIO_ACTIVE_LOW>;
- linux,default-trigger = "none";
+ network_green {
+ label = "pwm:green:network";
+ pwms = <&tcb_pwm 2 1000 PWM_POLARITY_INVERTED>;
+ max-brightness = <255>;
+ linux,default-trigger = "default-on";
};
- led1r {
- label = "led1:red";
- gpios = <&pioB 1 GPIO_ACTIVE_LOW>;
- linux,default-trigger = "none";
+ network_red {
+ label = "pwm:red:network";
+ pwms = <&tcb_pwm 3 1000 PWM_POLARITY_INVERTED>;
+ max-brightness = <255>;
+ linux,default-trigger = "default-on";
};
- led2g {
- label = "led2:green";
- gpios = <&pioB 2 GPIO_ACTIVE_LOW>;
- linux,default-trigger = "none";
- default-state = "on";
+ user_green {
+ label = "pwm:green:user";
+ pwms = <&tcb_pwm 0 1000 PWM_POLARITY_INVERTED>;
+ max-brightness = <255>;
+ linux,default-trigger = "default-on";
};
- led2r {
- label = "led2:red";
- gpios = <&pioB 3 GPIO_ACTIVE_LOW>;
- linux,default-trigger = "none";
+ user_red {
+ label = "pwm:red:user";
+ pwms = <&tcb_pwm 1 1000 PWM_POLARITY_INVERTED>;
+ max-brightness = <255>;
+ linux,default-trigger = "default-on";
};
};
+
+ tcb_pwm: pwm {
+ compatible = "atmel,tcb-pwm";
+ #pwm-cells = <3>;
+ tc-block = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tcb1_tioa0
+&pinctrl_tcb1_tioa1
+&pinctrl_tcb1_tioa2
+&pinctrl_tcb1_tiob0>;
+ };
};
--
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 v3 4/7] ARM: at91/dt: at91-kizbox: gpio-keys related changes
This:
* fixes active level of GPIO (active high) and
* renames buttons:
- reset (PB_RST), and
- mode to user (PB_USER).
Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
---
arch/arm/boot/dts/at91-kizbox.dts | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/at91-kizbox.dts
b/arch/arm/boot/dts/at91-kizbox.dts
index 72d5de80..73e4559 100644
--- a/arch/arm/boot/dts/at91-kizbox.dts
+++ b/arch/arm/boot/dts/at91-kizbox.dts
@@ -89,15 +89,15 @@
#size-cells = <0>;
reset {
- label = "reset";
- gpios = <&pioB 30 GPIO_ACTIVE_LOW>;
+ label = "PB_RST";
+ gpios = <&pioB 30 GPIO_ACTIVE_HIGH>;
linux,code = <0x100>;
gpio-key,wakeup;
};
- mode {
- label = "mode";
- gpios = <&pioB 31 GPIO_ACTIVE_LOW>;
+ user {
+ label = "PB_USER";
+ gpios = <&pioB 31 GPIO_ACTIVE_HIGH>;
linux,code = <0x101>;
gpio-key,wakeup;
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9] extcon-axp288: Add axp288 extcon driver support
Hi Ram, This patch has still one minor issue on below comment. But I fix it and will apply it on extcon-next branch after discussing how to apply this patch with Lee Jones (MFD maintainer). Dear Lee, Do you want to send pull request after I make the immutable branch for this patch? or apply this patch on extcon git without any pull request? Thanks, Chanwoo Choi On 05/01/2015 12:14 AM, Ramakrishna Pallala wrote: > This patch adds the extcon support for AXP288 PMIC which > has the BC1.2 charger detection capability. Additionally > it also adds the USB mux switching support b/w SOC and PMIC > based on GPIO control. > > Signed-off-by: Ramakrishna Pallala > Acked-by: Lee Jones > --- > drivers/extcon/Kconfig |7 + > drivers/extcon/Makefile|1 + > drivers/extcon/extcon-axp288.c | 385 > > include/linux/mfd/axp20x.h |5 + > 4 files changed, 398 insertions(+) > create mode 100644 drivers/extcon/extcon-axp288.c > [snip] > + vbus_attach ? EXTCON_GPIO_MUX_SEL_SOC > + : EXTCON_GPIO_MUX_SEL_PMIC); > + > + atomic_notifier_call_chain(&info->otg->notifier, > + vbus_attach ? USB_EVENT_VBUS : USB_EVENT_NONE, NULL); > + } > + > + if (notify_charger) > + extcon_set_cable_state(info->edev, cable, vbus_attach); > + > + /* Clear the flags on disconnect event */ > + if (!vbus_attach) > + notify_otg = notify_charger = false; > + > + return 0; > + > +dev_det_ret: > + if (ret < 0) > + dev_err(info->dev, "BC Mod detection error\n"); You miss the fix about following comment. "BC Mod detection error\n" -> "failed to detect BC Mod\n" [snip] -- 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 0/7] ARM: at91/dt: kizbox: update and rename to at91-kizbox
On 30/04/2015 at 09:33:31 +0200, Gaël PORTAY wrote : > Hi, > > This patchset renames the kizbox board into at91-kizbox to match AT91 naming > convention, sanitize and sorts nodes by address when possible (or > alphabetically if not applicable). > > It also updates the following features: > - uses proper serial uart (only USART3 is accessible), > - fixes gpio-keys active level and rename, > - moves leds to pwm support (using tcb-pwm driver) and rename as well, > - re-sizes nand mtd partitions and > - updates chosen-node (bootargs + set linux stdout path to DBGU), > The whole series is Acked-by: Alexandre Belloni -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] cpufreq: mediatek: Add MT8173 cpufreq driver
On Mon, Apr 20, 2015 at 05:27:26PM +0800, pi-cheng.chen wrote:
> This patch implements MT8173 specific cpufreq driver with OPP table defined
> in the driver code.
>
> Signed-off-by: pi-cheng.chen
> ---
> drivers/cpufreq/Kconfig.arm | 6 +
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/mt8173-cpufreq.c | 509
> +++
> 3 files changed, 516 insertions(+)
> create mode 100644 drivers/cpufreq/mt8173-cpufreq.c
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 1b06fc4..25643c7 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> +
> +static int mt8173_cpufreq_dvfs_init(struct cpu_dvfs_info *info)
> +{
> + struct device *cpu_dev;
> + struct regulator *proc_reg, *sram_reg;
> + struct clk *cpu_clk, *inter_pll;
> + unsigned long rate;
> + int cpu, ret;
> +
> + cpu = cpumask_first(&info->cpus);
> +
> +try_next_cpu:
> + cpu_dev = get_cpu_device(cpu);
> + proc_reg = regulator_get_exclusive(cpu_dev, "proc");
> + sram_reg = regulator_get_exclusive(cpu_dev, "sram");
> + cpu_clk = clk_get(cpu_dev, "cpu");
> + inter_pll = clk_get(cpu_dev, "intermediate");
> +
> + if (IS_ERR_OR_NULL(proc_reg) || IS_ERR_OR_NULL(cpu_clk) ||
> + IS_ERR_OR_NULL(inter_pll)) {
> + cpu = cpumask_next(cpu, &info->cpus);
> + if (cpu >= nr_cpu_ids)
> + return -ENODEV;
> +
> + goto try_next_cpu;
> + }
Please keep an eye on the error pathes. This one is quite broken. You
get references to resources here which you never release. Also
-EPROBE_DEFER is a valid return value from regulator_get which is not
handled here.
Also IS_ERR_OR_NULL() is most probably wrong here. Should be IS_ERR().
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 v9] extcon-axp288: Add axp288 extcon driver support
> Hi Ram, > > This patch has still one minor issue on below comment. > But I fix it and will apply it on extcon-next branch after discussing how to > apply > this patch with Lee Jones (MFD maintainer). Ok. Thanks. > Dear Lee, > Do you want to send pull request after I make the immutable branch for this > patch? or apply this patch on extcon git without any pull request? > > Thanks, > Chanwoo Choi > > On 05/01/2015 12:14 AM, Ramakrishna Pallala wrote: > > This patch adds the extcon support for AXP288 PMIC which has the BC1.2 > > charger detection capability. Additionally it also adds the USB mux > > switching support b/w SOC and PMIC based on GPIO control. > > > > Signed-off-by: Ramakrishna Pallala > > Acked-by: Lee Jones > > --- > > drivers/extcon/Kconfig |7 + > > drivers/extcon/Makefile|1 + > > drivers/extcon/extcon-axp288.c | 385 > > > include/linux/mfd/axp20x.h |5 + > > 4 files changed, 398 insertions(+) > > create mode 100644 drivers/extcon/extcon-axp288.c > > > > [snip] > > > + vbus_attach ? EXTCON_GPIO_MUX_SEL_SOC > > + : > EXTCON_GPIO_MUX_SEL_PMIC); > > + > > + atomic_notifier_call_chain(&info->otg->notifier, > > + vbus_attach ? USB_EVENT_VBUS : USB_EVENT_NONE, > NULL); > > + } > > + > > + if (notify_charger) > > + extcon_set_cable_state(info->edev, cable, vbus_attach); > > + > > + /* Clear the flags on disconnect event */ > > + if (!vbus_attach) > > + notify_otg = notify_charger = false; > > + > > + return 0; > > + > > +dev_det_ret: > > + if (ret < 0) > > + dev_err(info->dev, "BC Mod detection error\n"); > > You miss the fix about following comment. > "BC Mod detection error\n" -> "failed to detect BC Mod\n" Thanks, Ram -- 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/7] ARM: at91/dt: kizbox: update and rename to at91-kizbox
Hi, This patchset renames the kizbox board into at91-kizbox to match AT91 naming convention, sanitize and sorts nodes by address when possible (or alphabetically if not applicable). It also updates the following features: - uses proper serial uart (only USART3 is accessible), - fixes gpio-keys active level and rename, - moves leds to pwm support (using tcb-pwm driver) and rename as well, - re-sizes nand mtd partitions and - updates chosen-node (bootargs + set linux stdout path to DBGU), Regards, Gaël PORTAY Changes since v1: - Split into patches for review Changes since v2: - Rebase onto v4.0.1 - Change board-name in comments at rename (patch 1) Gaël PORTAY (7): ARM: at91/dt: kizbox: rename to at91-kizbox ARM: at91/dt: at91-kizbox: sanitize file ARM: at91/dt: at91-kizbox: user proper serial uart ARM: at91/dt: at91-kizbox: gpio-keys related changes ARM: at91/dt: at91-kizbox: leds related changes ARM: at91/dt: at91-kizbox: re-size nand partitions ARM: at91/dt: at91-kizbox: update chosen node arch/arm/boot/dts/Makefile| 2 +- arch/arm/boot/dts/at91-kizbox.dts | 159 ++ arch/arm/boot/dts/kizbox.dts | 150 --- 3 files changed, 160 insertions(+), 151 deletions(-) create mode 100644 arch/arm/boot/dts/at91-kizbox.dts delete mode 100644 arch/arm/boot/dts/kizbox.dts -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles
On Tue, Apr 28, 2015 at 04:32:35PM +0200, Peter Zijlstra wrote:
> On Sat, Apr 25, 2015 at 12:56:03PM -0700, Paul E. McKenney wrote:
> > smp: Make control dependencies work on Alpha, improve documentation
> >
> > The current formulation of control dependencies fails on DEC Alpha,
> > which
> > does not respect dependencies of any kind unless an explicit memory is
>
> + barrier ?
Good catch, fixed!
> > provided. This means that the current fomulation of control
> > dependencies
> > fails on Alpha. This commit therefore creates a READ_ONCE_CTRL() that
> > has the same overhead on non-Alpha systems, but causes Alpha to produce
> > the needed ordering. This commit also applies READ_ONCE_CTRL() to the
> > one known use of control dependencies.
> >
> > Use of READ_ONCE_CTRL() also has the beneficial effect of adding a bit
> > of self-documentation to control dependencies.
> >
> > Signed-off-by: Paul E. McKenney
>
> Acked-by: Peter Zijlstra (Intel)
Applied, thank you!
Thanx, Paul
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index 1b45e4a0519b..a57eacde2b84 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linux/compiler.h
> > @@ -264,6 +264,22 @@ static __always_inline void __write_once_size(volatile
> > void *p, void *res, int s
> > #define WRITE_ONCE(x, val) \
> > ({ typeof(x) __val = (val); __write_once_size(&(x), &__val,
> > sizeof(__val)); __val; })
> >
> > +/**
> > + * READ_ONCE_CTRL - Read a value heading a control dependency
> > + * @x: The value to be read, heading the control dependency
> > + *
> > + * Control dependencies are tricky. See Documentation/memory-barriers.txt
> > + * for important information on how to use them. Note that in many cases,
> > + * use of smp_load_acquire() will be much simpler. Control dependencies
> > + * should be avoided except on the hottest of hotpaths.
> > + */
> > +#define READ_ONCE_CTRL(x) \
> > +({ \
> > + typeof(x) __val = READ_ONCE(x); \
> > + smp_read_barrier_depends(); /* Enforce control dependency. */ \
> > + __val; \
> > +})
> > +
> > #endif /* __KERNEL__ */
> >
> > #endif /* __ASSEMBLY__ */
>
> We mostly try and align the \ for multi-line macros.
>
> > diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> > index eadb95ce7aac..67548d5de4cb 100644
> > --- a/kernel/events/ring_buffer.c
> > +++ b/kernel/events/ring_buffer.c
> > @@ -141,7 +141,7 @@ int perf_output_begin(struct perf_output_handle *handle,
> > perf_output_get_handle(handle);
> >
> > do {
> > - tail = ACCESS_ONCE(rb->user_page->data_tail);
> > + tail = READ_ONCE_CTRL(rb->user_page->data_tail);
> > offset = head = local_read(&rb->head);
> > if (!rb->overwrite &&
> > unlikely(CIRC_SPACE(head, tail, perf_data_size(rb)) < size))
>
> Right. I could not remember any other current usage.
>
--
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 00/12] On-demand device registration
Am 29.04.2015 um 11:46 schrieb Alexander Holler: Am 29.04.2015 um 08:58 schrieb Tomeu Vizoso: On 28 April 2015 at 20:17, Alexander Holler wrote: Am 28.04.2015 um 14:49 schrieb Tomeu Vizoso: On 25 April 2015 at 01:15, Alexander Holler wrote: Am 24.04.2015 um 16:47 schrieb Tomeu Vizoso: Hi, while reading the thread [0] that Alexander Holler started with his series to make probing order deterministic, it occurred to me that it should be possible to achieve the same by probing devices as they are referenced by other devices. This basically reuses the information that is already embedded in the probe() implementations, saving us from refactoring existing drivers or adding information to DTBs. The main issue I see is that the registration code path in some subsystems may not be reentrant, so some refactoring of the locking will be needed. In my testing I have found this problem with regulators, as the supply of a regulator might end up being registered during the registration of the first one. Something I'm not completely happy with is that I have had to move the population of the device tree after all platform drivers have been registered. Otherwise I don't see how I could register drivers on demand as we don't have yet each driver's compatible strings. I have done my testing on a Tegra124-based Chromebook, and these patches were enough to eliminate all the deferred probes. First you have to solve a problem which is totally unrelated to DT or ACPI or x86 or ARM: I think as long as drivers don't register themself whithout any side effect, this problem isn't solvable. In order to make an ordered list of drivers to start, you need to know which drivers are actually available. Yeah, I kind of side-stepped that issue by waiting until all drivers have been registered before registering devices. I think someone suggested doing so in your thread (maybe Grant?). That doesn't work. As said above, several drivers doing a lot more than just registering in their initcall. They might even crash if some prerequisits aren't given. And several of these prerequisits (init orders) are hardcoded by various means. But aren't those dependencies being taken care currently by the initcall level the driver is placed in? That remains the same in this approach. In short, no. There are various very ugly things done in several drivers to enforce some order. To explain it a bit more: The case with the regulator you've described above is just one of these ugly things done on some driver initcalls. That's why I've decided to introduce a new initcall level which only contains drivers which don't have any side effect but just registering themself. Ideally all drivers would end up in that level, and thus the special level would not be necessary at all. Because this means that several drivers have to change, which is a lot of work, an intermediate workaround is to make a whitelist. That's easier than a blacklist which would mean you have to examine every driver. And that whitelist is exactly what I did by introducing those "well done" drivers. And just in case of, I haven't looked at your patches at all. I've just read the introductory mail and the subjects of the patches and then concluded what I've written. That means if you've a special use case in mind, your solution might work. But as an overall solution the problem with identifying drivers (mapping initcalls to drivers) has to be solved (which I've tried with those "well done" driver list). Regards, Alexander Holler -- 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] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Thursday 30 April 2015 14:06:27 Alex Hung wrote: > Method ABRT is to be used by driver to disable BIOS handling of radio > button. So the changes in behaviours observed by Gabriele is expected. > I have seen other systems behave the same way. > Right, that after that ARBT call operating system get full control over radio devices and ACPI/BIOS will not automatically enable/disable them. I think this is OK. But for that we need also support for manually enable/disable radio devices and code for this support is missing. Or do DELLABCE/RBTN acpi devices somehow support enabling/disabling it via system/kernel request? > I do also see firmware only sends Notify(RBTN, 0x80) and no hard block > whether ABRT(1) is called or not. Thus keycode are the only option on > those machines. > Key is ok, but we *must* have ability to hard block it via some ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should be able to enable/disable their radio devices (bluetooth for powersave) > The idea to have an option (kernel parameter) for calling ABRT is > great. I can help verify on more machines. Is Gabriele's patch above a > final version that I should test? > No, I do not think so. This looks like hack or pure design. Kernel option could be there, but just for buggy BIOSes (and future changed design). But now it looks like for correct work is specifying that param required -- which is bad. Alex, can you ask Dell people how should system turn off e.g bluetooth or wifi device if ARTB(1) is called and system/kernel (instead ACPI) is expected to turn off/on blueooth (and wifi) devices? I think that without this information (and working driver for it) we should not enable ARTB(1) or including this driver into kernel tree as it will break some existing machines... Darren, I do not know what is better, but it looks like that some dell machines working fine now and some not (since begining). And after loading this driver some machines are fixed, but some which worked are broken... What do you think as maintainer? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel v9 31/32] vfio: powerpc/spapr: Support multiple groups in one container if possible
On Sat, Apr 25, 2015 at 10:14:55PM +1000, Alexey Kardashevskiy wrote:
> At the moment only one group per container is supported.
> POWER8 CPUs have more flexible design and allows naving 2 TCE tables per
> IOMMU group so we can relax this limitation and support multiple groups
> per container.
It's not obvious why allowing multiple TCE tables per PE has any
pearing on allowing multiple groups per container.
> This adds TCE table descriptors to a container and uses iommu_table_group_ops
> to create/set DMA windows on IOMMU groups so the same TCE tables will be
> shared between several IOMMU groups.
>
> Signed-off-by: Alexey Kardashevskiy
> [aw: for the vfio related changes]
> Acked-by: Alex Williamson
> ---
> Changes:
> v7:
> * updated doc
> ---
> Documentation/vfio.txt | 8 +-
> drivers/vfio/vfio_iommu_spapr_tce.c | 268
> ++--
> 2 files changed, 199 insertions(+), 77 deletions(-)
>
> diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
> index 94328c8..7dcf2b5 100644
> --- a/Documentation/vfio.txt
> +++ b/Documentation/vfio.txt
> @@ -289,10 +289,12 @@ PPC64 sPAPR implementation note
>
> This implementation has some specifics:
>
> -1) Only one IOMMU group per container is supported as an IOMMU group
> -represents the minimal entity which isolation can be guaranteed for and
> -groups are allocated statically, one per a Partitionable Endpoint (PE)
> +1) On older systems (POWER7 with P5IOC2/IODA1) only one IOMMU group per
> +container is supported as an IOMMU table is allocated at the boot time,
> +one table per a IOMMU group which is a Partitionable Endpoint (PE)
> (PE is often a PCI domain but not always).
I thought the more fundamental problem was that different PEs tended
to use disjoint bus address ranges, so even by duplicating put_tce
across PEs you couldn't have a common address space.
> +Newer systems (POWER8 with IODA2) have improved hardware design which allows
> +to remove this limitation and have multiple IOMMU groups per a VFIO
> container.
>
> 2) The hardware supports so called DMA windows - the PCI address range
> within which DMA transfer is allowed, any attempt to access address space
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
> b/drivers/vfio/vfio_iommu_spapr_tce.c
> index a7d6729..970e3a2 100644
> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -82,6 +82,11 @@ static void decrement_locked_vm(long npages)
> * into DMA'ble space using the IOMMU
> */
>
> +struct tce_iommu_group {
> + struct list_head next;
> + struct iommu_group *grp;
> +};
> +
> /*
> * The container descriptor supports only a single group per container.
> * Required by the API as the container is not supplied with the IOMMU group
> @@ -89,10 +94,11 @@ static void decrement_locked_vm(long npages)
> */
> struct tce_container {
> struct mutex lock;
> - struct iommu_group *grp;
> bool enabled;
> unsigned long locked_pages;
> bool v2;
> + struct iommu_table tables[IOMMU_TABLE_GROUP_MAX_TABLES];
Hrm, so here we have more copies of the full iommu_table structures,
which again muddies the lifetime. The table_group pointer is
presumably meaningless in these copies, which seems dangerously
confusing.
> + struct list_head group_list;
> };
>
> static long tce_unregister_pages(struct tce_container *container,
> @@ -154,20 +160,20 @@ static bool tce_page_is_contained(struct page *page,
> unsigned page_shift)
> return (PAGE_SHIFT + compound_order(compound_head(page))) >= page_shift;
> }
>
> +static inline bool tce_groups_attached(struct tce_container *container)
> +{
> + return !list_empty(&container->group_list);
> +}
> +
> static struct iommu_table *spapr_tce_find_table(
> struct tce_container *container,
> phys_addr_t ioba)
> {
> long i;
> struct iommu_table *ret = NULL;
> - struct iommu_table_group *table_group;
> -
> - table_group = iommu_group_get_iommudata(container->grp);
> - if (!table_group)
> - return NULL;
>
> for (i = 0; i < IOMMU_TABLE_GROUP_MAX_TABLES; ++i) {
> - struct iommu_table *tbl = &table_group->tables[i];
> + struct iommu_table *tbl = &container->tables[i];
> unsigned long entry = ioba >> tbl->it_page_shift;
> unsigned long start = tbl->it_offset;
> unsigned long end = start + tbl->it_size;
> @@ -186,9 +192,7 @@ static int tce_iommu_enable(struct tce_container
> *container)
> int ret = 0;
> unsigned long locked;
> struct iommu_table_group *table_group;
> -
> - if (!container->grp)
> - return -ENXIO;
> + struct tce_iommu_group *tcegrp;
>
> if (!current->mm)
> return -ESRCH; /* process exited */
> @@ -225,7 +229,12 @@ static int tce_iommu_enable(struct tce_container
> *container)
>* as there is no way to know
Re: [PATCH v7 00/23] IB/Verbs: IB Management Helpers
On 04/29/2015 06:28 PM, Doug Ledford wrote: > On Tue, 2015-04-28 at 17:10 +0200, Michael Wang wrote: >> Since v6: >> * Thanks to Ira, Devesh for the review and testing :-) >> * Thanks for the comments from Sean, Tom, Jason, Doug, Devesh, Ira, >> Liran :-) Please remind me if anything missed :-P >> * Use query_protocol() and enum protocol type in 1# >> * Use rdma_protocol_XX() in 2# >> * Drop cma_set_legacy_transport() >> * Reserve rdma_ib_or_iboe() and rdma_node_get_transport() >> * Updated github repository to v7 > > I've taken your patchset and threw it into a for-4.2 branch in my repo. > This will get it 0day testing. I've also pulled it into my test cluster > and done minimal testing (bootup, finds devices, gets IP address via > dhcp). Here are the hardware types it passed on: > > mthca (yes, I still have these...only just barely, but I do) > mlx4 (IB/RoCE, in both standalone and SRIOV usage) > mlx5 (IB only, I don't have the Eth capable mlx5 hardware yet) > cxgb3 > cxgb4 > qib > ocrdma My appreciation :-) Please let me know if there are anything broken. Regards, Michael Wang > -- 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] Bluetooth: Add tty HCI driver
tty_hci driver exposes a /dev/hci_tty character device node, that intends
to emulate a generic /dev/ttyX device that would be used by the user-space
Bluetooth stacks to send/receive data to/from the WL combo-connectivity
chipsets.
The device driver has no internal logic of its own to intrepret data & all
such logic is handled by the user-space stack.
Signed-off-by: Pavan Savoy
[Fixed checkpatch warnings]
Signed-off-by: Vishal Mahaveer
[Fixed checkpatch --strict warnings]
Signed-off-by: Eyal Reizer
---
drivers/misc/ti-st/Kconfig |8 +
drivers/misc/ti-st/Makefile |1 +
drivers/misc/ti-st/tty_hci.c | 538 ++
3 files changed, 547 insertions(+)
create mode 100644 drivers/misc/ti-st/tty_hci.c
diff --git a/drivers/misc/ti-st/Kconfig b/drivers/misc/ti-st/Kconfig
index f34dcc5..f2df2c7 100644
--- a/drivers/misc/ti-st/Kconfig
+++ b/drivers/misc/ti-st/Kconfig
@@ -14,4 +14,12 @@ config TI_ST
are returned to relevant protocol drivers based on their
packet types.
+config ST_HCI
+ tristate "HCI TTY emulation driver for Bluetooth"
+ depends on TI_ST
+ help
+ This enables the TTY device like emulation for HCI used by
+ user-space Bluetooth stacks.
+ It will provide a character device for user space Bluetooth stack to
+ send/receive data over shared transport.
endmenu
diff --git a/drivers/misc/ti-st/Makefile b/drivers/misc/ti-st/Makefile
index 78d7ebb..4546219 100644
--- a/drivers/misc/ti-st/Makefile
+++ b/drivers/misc/ti-st/Makefile
@@ -4,3 +4,4 @@
#
obj-$(CONFIG_TI_ST)+= st_drv.o
st_drv-objs:= st_core.o st_kim.o st_ll.o
+obj-$(CONFIG_ST_HCI) += tty_hci.o
diff --git a/drivers/misc/ti-st/tty_hci.c b/drivers/misc/ti-st/tty_hci.c
new file mode 100644
index 000..7a6669f
--- /dev/null
+++ b/drivers/misc/ti-st/tty_hci.c
@@ -0,0 +1,538 @@
+/*
+ * TTY emulation for user-space Bluetooth stacks over HCI-H4
+ * Copyright (C) 2011-2012 Texas Instruments
+ * Author: Pavan Savoy
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/** define one of the following for debugging
+#define DEBUG
+#define VERBOSE
+*/
+
+#define pr_fmt(fmt) "(hci_tty): " fmt
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* Number of seconds to wait for registration completion
+ * when ST returns PENDING status.
+ */
+#define BT_REGISTER_TIMEOUT 6000 /* 6 sec */
+
+/**
+ * struct ti_st - driver operation structure
+ * @hdev: hci device pointer which binds to bt driver
+ * @reg_status: ST registration callback status
+ * @st_write: write function provided by the ST driver
+ * to be used by the driver during send_frame.
+ * @wait_reg_completion - completion sync between ti_st_open
+ * and st_reg_completion_cb.
+ */
+struct ti_st {
+ struct hci_dev *hdev;
+ char reg_status;
+ long (*st_write)(struct sk_buff *);
+ struct completion wait_reg_completion;
+ wait_queue_head_t data_q;
+ struct sk_buff_head rx_list;
+};
+
+#define DEVICE_NAME "hci_tty"
+
+/***Functions called from ST driver**/
+/* Called by Shared Transport layer when receive data is
+ * available */
+static long st_receive(void *priv_data, struct sk_buff *skb)
+{
+ struct ti_st*hst = (void *)priv_data;
+
+ pr_debug("@ %s", __func__);
+#ifdef VERBOSE
+ print_hex_dump(KERN_INFO, ">rx>", DUMP_PREFIX_NONE,
+ 16, 1, skb->data, skb->len, 0);
+#endif
+ skb_queue_tail(&hst->rx_list, skb);
+ wake_up_interruptible(&hst->data_q);
+ return 0;
+}
+
+/* Called by ST layer to indicate protocol registration completion
+ * status.ti_st_open() function will wait for signal from this
+ * API when st_register() function returns ST_PENDING.
+ */
+static void st_reg_completion_cb(void *priv_data, char data)
+{
+ struct ti_st*lhst = (void *)priv_data;
+
+ pr_info("@ %s\n", __func__);
+ /* Save registration status for use in ti_st_open() */
+ lhst->reg_status = data;
+ /* complete the wait in ti_st_open() */
+ complete(&lhst->wait_reg_completion);
+}
+
+/* protocol structure registered with shared transport */
+#define MAX_BT_CHNL_IDS 3
+static struct st_proto_s ti_st_proto[MAX_BT_CHNL_IDS] = {
+ {
+ .chnl_id = 0x04, /* HCI Events */
+ .hdr_len = 2,
+ .offset_len_in_hdr = 1,
+
Re: [PATCH v3 0/7] ARM: at91/dt: kizbox: update and rename to at91-kizbox
On 30/04/2015 09:42, Alexandre Belloni wrote: On 30/04/2015 at 09:33:31 +0200, Gaël PORTAY wrote : Hi, This patchset renames the kizbox board into at91-kizbox to match AT91 naming convention, sanitize and sorts nodes by address when possible (or alphabetically if not applicable). It also updates the following features: - uses proper serial uart (only USART3 is accessible), - fixes gpio-keys active level and rename, - moves leds to pwm support (using tcb-pwm driver) and rename as well, - re-sizes nand mtd partitions and - updates chosen-node (bootargs + set linux stdout path to DBGU), The whole series is Acked-by: Alexandre Belloni 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/
[PATCH v3 7/7] ARM: at91/dt: at91-kizbox: update chosen node
Simplify the bootargs since the platform is booting from an initramfs and
set the kernel stdout path to DBGU.
Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
---
arch/arm/boot/dts/at91-kizbox.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91-kizbox.dts
b/arch/arm/boot/dts/at91-kizbox.dts
index e739104..b567b5f 100644
--- a/arch/arm/boot/dts/at91-kizbox.dts
+++ b/arch/arm/boot/dts/at91-kizbox.dts
@@ -15,7 +15,8 @@
compatible = "overkiz,kizbox", "atmel,at91sam9g20", "atmel,at91sam9";
chosen {
- bootargs = "panic=5 ubi.mtd=1 rootfstype=ubifs root=ubi0:root";
+ bootargs = "ubi.mtd=ubi";
+ linux,stdout-path = &dbgu;
};
memory {
--
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 v3 6/7] ARM: at91/dt: at91-kizbox: re-size nand partitions
Re-size NAND partitions since the bootstrap is able to read volumes from an
UBI image.
Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
---
arch/arm/boot/dts/at91-kizbox.dts | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/at91-kizbox.dts
b/arch/arm/boot/dts/at91-kizbox.dts
index b19f568..e739104 100644
--- a/arch/arm/boot/dts/at91-kizbox.dts
+++ b/arch/arm/boot/dts/at91-kizbox.dts
@@ -72,14 +72,14 @@
nand-ecc-mode = "soft";
status = "okay";
- bootloaderkernel@0 {
- label = "bootloader-kernel";
- reg = <0x0 0xc>;
+ bootstrap@0 {
+ label = "bootstrap";
+ reg = <0x0 0x2>;
};
- ubi@c {
+ ubi@2 {
label = "ubi";
- reg = <0xc 0x7f4>;
+ reg = <0x2 0x7fe>;
};
};
};
--
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 v3 3/7] ARM: at91/dt: at91-kizbox: user proper serial uart
USART3 is the only serial UART accessible.
Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
---
arch/arm/boot/dts/at91-kizbox.dts | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/at91-kizbox.dts
b/arch/arm/boot/dts/at91-kizbox.dts
index 00c86c1..72d5de80 100644
--- a/arch/arm/boot/dts/at91-kizbox.dts
+++ b/arch/arm/boot/dts/at91-kizbox.dts
@@ -38,14 +38,6 @@
ahb {
apb {
- usart0: serial@fffb {
- status = "okay";
- };
-
- usart1: serial@fffb4000 {
- status = "okay";
- };
-
macb0: ethernet@fffc4000 {
phy-mode = "mii";
pinctrl-0 = <&pinctrl_macb_rmii
@@ -53,6 +45,10 @@
status = "okay";
};
+ usart3: serial@fffd {
+ status = "okay";
+ };
+
dbgu: serial@f200 {
status = "okay";
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] power_supply: Add support for Richtek rt9455 battery charger
2015-04-30 5:13 GMT+09:00 Anda-Maria Nicolae :
> Based on the datasheet found here:
> http://www.richtek.com/download_ds.jsp?p=RT9455
>
> Updates from the previous version:
> - replaced license GPLv2 with GPL
> - replaced vendor prefix rt with richtek
> - replaced uppercase properties names from devicetree with lowercase
> separated by dash properties names
> - replaced I/O read/write API with regmap_read/write and
> regmap_field_read/write
> - used kernel multiline comment
> - used DELAYED_WORK and scheduled the works in system_power_efficient_wq. It
> is high probability that the device is in suspend state while charging (i.e.
> the user leaves the device to charge during night) and it is needed that the
> scheduled works to be executed as planned.
I think when device is suspended (e.g. to RAM) no work will ever be
executed. The timers (for delayed work) will not wake up the device...
RTC could wake but this is different story. My proposal of deferred
timers is affected by idle CPU time. Are you sure that you want to
wake up from the system suspend?
> - replaced struct power_supply_desc rt9455_charger_desc with static const
> struct power_supply_desc rt9455_charger_desc
> - replaced if (IS_ERR_OR_NULL(info->charger)) with if (IS_ERR(info->charger))
> - replaced {"RTK9455", 0} with { "RTK9455", 0 }
> - removed .owner = THIS_MODULE
>
> Signed-off-by: Anda-Maria Nicolae
You missed some of my comments. I mentioned wrong error paths around
put_usb_phy in probe. They do not seem to be fixed...
Just one hint - mostly new bindings are posted in separate patches at
the beginning of the patchset. I actually don't mind. but separating
them will probably give you higher chance of review from DT people.
This is also mentioned in:
Documentation/devicetree/bindings/submitting-patches.txt
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 v3 2/4] extcon: usb-gpio: add support for VBUS detection
On 04/30/2015 04:32 PM, Roger Quadros wrote:
> On 16/04/15 11:26, Chanwoo Choi wrote:
>> On 04/16/2015 05:01 PM, Peter Chen wrote:
>>> On Thu, Apr 16, 2015 at 04:59:31PM +0900, Chanwoo Choi wrote:
On 04/16/2015 04:13 PM, Ivan T. Ivanov wrote:
> Hi,
>
> On Thu, 2015-04-16 at 16:00 +0900, Chanwoo Choi wrote:
>> Hi Peter,
>>
>> On 04/16/2015 10:59 AM, Peter Chen wrote:
>>>
>
>>> Ok, from USB point, external id/vbus value can't decide
>>> which role the controller will be, the controller driver
>>> will decide role according to many things, eg, user configurations,
>>> id/vbus value, OTG HNP, etc.
>>>
>>> So, from USB controller/phy driver, it doesn't care which cable is
>>> inserted, it cares about id/vbus value. Eg, it can get id/vbus value
>>> and it will be notified when the id/vbus value has changed.
>>
>> OK, I change the notifier name and add notifier events as following:
>>
>> - extcon_{register|unregister}_usb_notifier(struct extcon_dev *edev,
>> struct notifier_block *nb);
>> - list of notifier events
>> #define EXTCON_USB_ID_L_VBUS_L0 /* ID low and VBUS low */
>> #define EXTCON_USB_ID_L_VBUS_H1 /* ID low and VBUS high */
>> #define EXTCON_USB_ID_H_VBUS_L2 /* ID high and VBUS low */
>> #define EXTCON_USB_ID_H_VBUS_H3 /* ID high and VBUS high */
>
> I am still confused, why we mix ID and VBUS events into one?
> Those are two lines and they are not necessarily handled by
> the same extcon_dev.
IMO, if some usb driver check both id and vbus pin at the same time,
the usb driver can know the both id and vbus pin state through only one
notifier event.
Also,
If some usb driver want to know the state of id pin except of vbus state,
when receiving following events, id pin is low.
#define EXTCON_USB_ID_L_VBUS_L0
#define EXTCON_USB_ID_L_VBUS_H1
when receiving following events, id pin is high.
#define EXTCON_USB_ID_H_VBUS_L2
#define EXTCON_USB_ID_H_VBUS_H3
Also, some usb driver would catch the vbus pin state with same method.
But, it is just my opinion. We may use following notifier events for each
pin.
We need to discuss it.
#define EXTCON_USB_ID_LOW
#define EXTCON_USB_ID_HIGH
#define EXTCON_USB_VBUS_LOW
#define EXTCON_USB_VBUS_HIGH
>>>
>>> I agree with above definition.
>>>
>>
>> OK. I understand.
>>
>>
> Chanwoo, Robert,
>
Hi Roger,
> Do we have an agreement on a common solution then?
Yes.
> IMO the above mentioned 4 notifier events should meet all our USB needs.
I'll support usb notifier chain which includes 4 notifier events.
Thanks,
Chanwoo Choi
--
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/1 linux-next] exofs: convert simple_str to kstr
On 04/29/2015 08:58 PM, Fabian Frederick wrote:
> replace obsolete function.
>
> Signed-off-by: Fabian Frederick
Thanks.
ACK-by: Boaz Harrosh
Are you pushing all these through some tree, or
You need that I push it? Maybe push all these changes
through some central place, like Andrew's tree?
Boaz
> ---
> This is untested.
>
> fs/exofs/super.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/fs/exofs/super.c b/fs/exofs/super.c
> index b795c56..b667f73 100644
> --- a/fs/exofs/super.c
> +++ b/fs/exofs/super.c
> @@ -108,9 +108,14 @@ static int parse_options(char *options, struct
> exofs_mountopt *opts)
> opts->is_osdname = true;
> break;
> case Opt_pid:
> + {
> + int rc;
> +
> if (0 == match_strlcpy(str, &args[0], sizeof(str)))
> return -EINVAL;
> - opts->pid = simple_strtoull(str, NULL, 0);
> + rc = kstrtoull(str, 0, &opts->pid);
> + if (rc)
> + return rc;
> if (opts->pid < EXOFS_MIN_PID) {
> EXOFS_ERR("Partition ID must be >= %u",
> EXOFS_MIN_PID);
> @@ -118,6 +123,7 @@ static int parse_options(char *options, struct
> exofs_mountopt *opts)
> }
> s_pid = 1;
> break;
> + }
> case Opt_to:
> if (match_int(&args[0], &option))
> return -EINVAL;
>
--
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] scatterlist: enable sg chaining for all architectures
On Tue, 2015-04-28 at 19:15 -0700, James Bottomley wrote: > On Wed, 2015-04-29 at 09:34 +0900, Akinobu Mita wrote: > > 2015-04-29 7:16 GMT+09:00 James Bottomley > > : > > > On Tue, 2015-04-28 at 14:27 -0700, Andrew Morton wrote: > > >> On Sat, 25 Apr 2015 23:56:16 +0900 Akinobu Mita > > >> wrote: > > >> > > >> > Some architectures enable sg chaining option while others do not. > > >> > > > >> > The requirement to enable sg chaining is that pages must be aligned > > >> > at a 32-bit boundary in order to overload the LSB of the pointer. > > >> > Regardless of whether ARCH_HAS_SG_CHAIN is defined or not, the above > > >> > requirement is always chacked by BUG_ON() in sg_assign_page. So > > >> > all architectures can enable sg chaining. > > >> > > > >> > As you can see from the changes in drivers/target/target_core_rd.c, > > >> > enabling SG chaining for all architectures allows us to allocate > > >> > discontiguous scatterlist tables which can be traversed throughout > > >> > by sg_next() without a special handling for some architectures. > > >> > > >> Thanks, I'll grab this. If anyone has concerns, speak now or hold both > > >> pieces! > > > > > > It breaks a host of architectures doesn't it? I can specifically speak > > > for PARISC: The problem is the way our iommus are consuming > > > scatterlists. They're assuming we can dereference the scatterlist as an > > > array (like this code in ccio-dma.c): > > > > > > static int > > > ccio_map_sg(struct device *dev, struct scatterlist *sglist, int nents, > > > enum dma_data_direction direction) > > > [...] > > > for(i = 0; i < nents; i++) > > > prev_len += sglist[i].length; > > > > > > If you turn on sg chaining on our architecture, we'll run off the end of > > > that array dereference and crash. > > > > > > This can all be fixed by making our architecture dma mapping code use > > > iterators instead of array lists, but that needs more code than this > > > patch provides. I assume there are similar issues on a lot of other > > > architectures, so before you can contemplate a patch like this, surely > > > all the architecture consumers have to be converted to iterator instead > > > of array format? > > > > > > The first place to start would be a survey of who's still using the > > > array format. > > > > Agreed. I could find similar issues in arch/m68k/kernel/dma.c. > > (git grep '[^a-z]sg++' shows that there are a lot of similar issues) > > OK, so the original idea of the chained SG lists was that most of the > older architectures have fixed length lists for their IOMMUs, or simply > wouldn't see a benefit with IO lengths > 0.5MB (which was the default > before chaining) so there wasn't much point converting them to chaining > if they wouldn't see any benefit from it. > > ARCH_HAS_SG_CHAIN is supposed to be completely transparent to all driver > side consumers, so there was never thought to be much point removing it. > It looks like there's some sort of cockup going on in the target driver > but otherwise, your removal patch is pretty empty, confirming this. > > Perhaps the best thing to do is just fix target and call it quits? > So the ARCH_HAS_SG_CHAIN usage in target_core_rd.c was recently added so target DIF emulation could use standard SGL iterators and correctly handle boundaries across T10-PI metadata SGL tables in the ramdisk backend. The SGLs in question are never actually mapped to a HW IOMMU, and Akinobu's current changes in mainline do support both arch cases and make common sbc_dif_copy_prot() code a bit simpler too. That said, I'd rather to keep the hack around for now so that both ARCH_HAS_SG_CHAIN types can still work, short of a full arch conversion of course.. Thanks, --nab -- 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 0/7] ARM: at91/dt: kizbox: update and rename to at91-kizbox
Le 30/04/2015 09:33, Gaël PORTAY a écrit : > Hi, > > This patchset renames the kizbox board into at91-kizbox to match AT91 naming > convention, sanitize and sorts nodes by address when possible (or > alphabetically if not applicable). > > It also updates the following features: > - uses proper serial uart (only USART3 is accessible), > - fixes gpio-keys active level and rename, > - moves leds to pwm support (using tcb-pwm driver) and rename as well, > - re-sizes nand mtd partitions and > - updates chosen-node (bootargs + set linux stdout path to DBGU), > > Regards, > Gaël PORTAY > > Changes since v1: > - Split into patches for review > > Changes since v2: > - Rebase onto v4.0.1 > - Change board-name in comments at rename (patch 1) > > Gaël PORTAY (7): > ARM: at91/dt: kizbox: rename to at91-kizbox > ARM: at91/dt: at91-kizbox: sanitize file > ARM: at91/dt: at91-kizbox: user proper serial uart > ARM: at91/dt: at91-kizbox: gpio-keys related changes > ARM: at91/dt: at91-kizbox: leds related changes > ARM: at91/dt: at91-kizbox: re-size nand partitions > ARM: at91/dt: at91-kizbox: update chosen node On the whole series: Acked-by: Nicolas Ferre Stacked on at91-4.2-dt (should also appear shortly in linux-next). Thanks Gaël, bye. > arch/arm/boot/dts/Makefile| 2 +- > arch/arm/boot/dts/at91-kizbox.dts | 159 > ++ > arch/arm/boot/dts/kizbox.dts | 150 --- > 3 files changed, 160 insertions(+), 151 deletions(-) > create mode 100644 arch/arm/boot/dts/at91-kizbox.dts > delete mode 100644 arch/arm/boot/dts/kizbox.dts > -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection
On 30/04/15 10:55, Chanwoo Choi wrote:
> On 04/30/2015 04:32 PM, Roger Quadros wrote:
>> On 16/04/15 11:26, Chanwoo Choi wrote:
>>> On 04/16/2015 05:01 PM, Peter Chen wrote:
On Thu, Apr 16, 2015 at 04:59:31PM +0900, Chanwoo Choi wrote:
> On 04/16/2015 04:13 PM, Ivan T. Ivanov wrote:
>> Hi,
>>
>> On Thu, 2015-04-16 at 16:00 +0900, Chanwoo Choi wrote:
>>> Hi Peter,
>>>
>>> On 04/16/2015 10:59 AM, Peter Chen wrote:
>>
Ok, from USB point, external id/vbus value can't decide
which role the controller will be, the controller driver
will decide role according to many things, eg, user configurations,
id/vbus value, OTG HNP, etc.
So, from USB controller/phy driver, it doesn't care which cable is
inserted, it cares about id/vbus value. Eg, it can get id/vbus value
and it will be notified when the id/vbus value has changed.
>>>
>>> OK, I change the notifier name and add notifier events as following:
>>>
>>> - extcon_{register|unregister}_usb_notifier(struct extcon_dev *edev,
>>> struct notifier_block *nb);
>>> - list of notifier events
>>> #define EXTCON_USB_ID_L_VBUS_L0 /* ID low and VBUS low */
>>> #define EXTCON_USB_ID_L_VBUS_H1 /* ID low and VBUS high
>>> */
>>> #define EXTCON_USB_ID_H_VBUS_L2 /* ID high and VBUS low */
>>> #define EXTCON_USB_ID_H_VBUS_H3 /* ID high and VBUS high
>>> */
>>
>> I am still confused, why we mix ID and VBUS events into one?
>> Those are two lines and they are not necessarily handled by
>> the same extcon_dev.
>
> IMO, if some usb driver check both id and vbus pin at the same time,
> the usb driver can know the both id and vbus pin state through only one
> notifier event.
>
> Also,
> If some usb driver want to know the state of id pin except of vbus state,
> when receiving following events, id pin is low.
> #define EXTCON_USB_ID_L_VBUS_L0
> #define EXTCON_USB_ID_L_VBUS_H1
> when receiving following events, id pin is high.
> #define EXTCON_USB_ID_H_VBUS_L2
> #define EXTCON_USB_ID_H_VBUS_H3
> Also, some usb driver would catch the vbus pin state with same method.
>
> But, it is just my opinion. We may use following notifier events for each
> pin.
> We need to discuss it.
> #define EXTCON_USB_ID_LOW
> #define EXTCON_USB_ID_HIGH
> #define EXTCON_USB_VBUS_LOW
> #define EXTCON_USB_VBUS_HIGH
>
I agree with above definition.
>>>
>>> OK. I understand.
>>>
>>>
>> Chanwoo, Robert,
>>
>
> Hi Roger,
>
>> Do we have an agreement on a common solution then?
>
> Yes.
>
>> IMO the above mentioned 4 notifier events should meet all our USB needs.
>
> I'll support usb notifier chain which includes 4 notifier events.
Great, then Robert can base his patches on that. Thanks.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
Hi, > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Wednesday, April 29, 2015 4:14 PM > Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader > > On Wed, Apr 29, 2015 at 12:49:59AM +, Zheng, Lv wrote: > > > > We absolutely want to use atomic_add_unless() because we get to save us > > > > the expensive > > > > > > > > LOCK; CMPXCHG > > > > > > > > if the value was already 1. Which is exactly what this patch is trying > > > > to avoid - a thundering herd of cores CMPXCHGing a global variable. > > > > > > IMO, on most architectures, the "cmp" part should work just like what > > > you've done with "if". > > > And on some architectures, if the "xchg" doesn't happen, the "cmp" part > > > even won't cause a pipe line hazard. > > Even if CMPXCHG is being split into several microops, they all still > need to flow down the pipe and require resources and tracking. And you > only know at retire time what the CMP result is and can "discard" the > XCHG part. Provided the uarch is smart enough to do that. > > This is probably why CMPXCHG needs 5,6,7,10,22,... cycles depending on > uarch and vendor, if I can trust Agner Fog's tables. And I bet those > numbers are best-case only and in real-life they probably tend to fall > out even worse. > > CMP needs only 1. On almost every uarch and vendor. And even that cycle > probably gets hidden with a good branch predictor. Are there any such data around the SC and LL (MIPS)? > > > If you man the LOCK prefix, I understand now. > > And that makes several times worse: 22, 40, 80, ... cycles. I'm OK if the code still keeps the readability then. Thanks and best regards -Lv > > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. > --
[PATCH v2 01/15] linux/time64.h:Introduce the 'struct itimerspec64' for 64bit
This patch introduces the 'struct itimerspec64' for 64bit to replace itimerspec,
and also introduces the conversion methods: itimerspec64_to_itimerspec() and
itimerspec_to_itimerspec64(), that makes itimerspec ready for 2038 year.
Signed-off-by: Baolin Wang
---
include/linux/time64.h | 35 +++
1 file changed, 35 insertions(+)
diff --git a/include/linux/time64.h b/include/linux/time64.h
index a383147..61dc4cb 100644
--- a/include/linux/time64.h
+++ b/include/linux/time64.h
@@ -11,11 +11,18 @@ typedef __s64 time64_t;
*/
#if __BITS_PER_LONG == 64
# define timespec64 timespec
+#define itimerspec64 itimerspec
#else
struct timespec64 {
time64_ttv_sec; /* seconds */
longtv_nsec;/* nanoseconds */
};
+
+struct itimerspec64 {
+ struct timespec64 it_interval; /* timer period */
+ struct timespec64 it_value; /* timer expiration */
+};
+
#endif
/* Parameters used to convert the timespec values: */
@@ -43,6 +50,16 @@ static inline struct timespec64 timespec_to_timespec64(const
struct timespec ts)
return ts;
}
+static inline struct itimerspec itimerspec64_to_itimerspec(struct itimerspec64
*its64)
+{
+ return *its64;
+}
+
+static inline struct itimerspec64 itimerspec_to_itimerspec64(struct itimerspec
*its)
+{
+ return *its;
+}
+
# define timespec64_equal timespec_equal
# define timespec64_comparetimespec_compare
# define set_normalized_timespec64 set_normalized_timespec
@@ -75,6 +92,24 @@ static inline struct timespec64 timespec_to_timespec64(const
struct timespec ts)
return ret;
}
+static inline struct itimerspec itimerspec64_to_itimerspec(struct itimerspec64
*its64)
+{
+ struct itimerspec ret;
+
+ ret.it_interval = timespec64_to_timespec(its64->it_interval);
+ ret.it_value = timespec64_to_timespec(its64->it_value);
+ return ret;
+}
+
+static inline struct itimerspec64 itimerspec_to_itimerspec64(struct itimerspec
*its)
+{
+ struct itimerspec64 ret;
+
+ ret.it_interval = timespec_to_timespec64(its->it_interval);
+ ret.it_value = timespec_to_timespec64(its->it_value);
+ return ret;
+}
+
static inline int timespec64_equal(const struct timespec64 *a,
const struct timespec64 *b)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/15] Convert the posix_clock_operations and k_clock structure to ready for 2038
This patch series changes the 32-bit time type (timespec/itimerspec) to the 64-bit one (timespec64/itimerspec64), since 32-bit time types will break in the year 2038. This patch series introduces new methods with timespec64/itimerspec64 type, and removes the old ones with timespec/itimerspec type for posix_clock_operations and k_clock structure. Also introduces some new functions with timespec64/itimerspec64 type, like current_kernel_time64(), hrtimer_get_res64(), cputime_to_timespec64() and timespec64_to_cputime(). Changes since V1: -Split some patch into small patch. -Change the methods for converting the syscall and add some default function for new 64bit methods for syscall function. -Introduce the new function do_sys_settimeofday64() and move do_sys_settimeofday() function to head file. -Modify the EXPORT_SYMPOL issue. -Add new 64bit methods in cputime_nsecs.h file. -Modify some patch logs. Baolin Wang (15): linux/time64.h:Introduce the 'struct itimerspec64' for 64bit timekeeping:Introduce the current_kernel_time64() function with timespec64 type time/hrtimer:Introduce hrtimer_get_res64() with timespec64 type for getting the timer resolution posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure posix-timers:Split out the guts of the syscall and change the implementation posix-timers:Convert to the 64bit methods for the syscall function time:Introduce the do_sys_settimeofday64() function with timespec64 type time/posix-timers:Convert to the 64bit methods for k_clock callback functions char/mmtimer:Convert to the 64bit methods for k_clock callback function time/alarmtimer:Convert to the new methods for k_clock structure time/posix-clock:Convert to the 64bit methods for k_clock and posix_clock_operations structure time/time:Introduce the timespec64_to_jiffies/jiffies_to_timespec64 function cputime:Introduce the cputime_to_timespec64/timespec64_to_cputime function time/posix-cpu-timers:Convert to the 64bit methods for k_clock structure k_clock:Remove the 32bit methods with timespec/itimerspec type arch/powerpc/include/asm/cputime.h|6 +- arch/s390/include/asm/cputime.h |8 +- drivers/char/mmtimer.c| 36 +++-- drivers/ptp/ptp_clock.c | 26 +--- include/asm-generic/cputime_jiffies.h | 10 +- include/asm-generic/cputime_nsecs.h |4 +- include/linux/cputime.h | 15 ++ include/linux/hrtimer.h | 12 +- include/linux/jiffies.h | 21 ++- include/linux/posix-clock.h | 10 +- include/linux/posix-timers.h | 18 +-- include/linux/time64.h| 35 + include/linux/timekeeping.h | 26 +++- kernel/time/alarmtimer.c | 43 +++--- kernel/time/hrtimer.c | 10 +- kernel/time/posix-clock.c | 20 +-- kernel/time/posix-cpu-timers.c| 83 +- kernel/time/posix-timers.c| 269 ++--- kernel/time/time.c| 22 +-- kernel/time/timekeeping.c |6 +- kernel/time/timekeeping.h |2 +- 21 files changed, 428 insertions(+), 254 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/3] ARM: pxa: pxa_cplds: add lubbock and mainstone IO
On Thursday 30 April 2015 00:04:31 Robert Jarzmik wrote: > Robert Jarzmik writes: > > Hi Arnd, > > I'm intending to queue that in pxa/fixes and then request pulling. > As you've been involved in the review from the beginning, can I have a > "Reviewed-by" ? The code is in an area that I'm not too familiar with, so I'm not claiming I did a full review. But everything I can see looks reasonable to me, so feel free to add Acked-by: Arnd Bergmann Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 02/15] timekeeping:Introduce the current_kernel_time64() function with timespec64 type
This patch adds current_kernel_time64() function with timespec64 type,
and makes current_kernel_time() 'static inline' and moves it to timekeeping.h
file.
It is convenient for user to get the current kernel time with timespec64 type,
and delete the current_kernel_time() function easily in timekeeping.h file. That
is ready for 2038 when get the current time.
Signed-off-by: Baolin Wang
---
include/linux/timekeeping.h | 10 +-
kernel/time/timekeeping.c |6 +++---
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 3eaae47..c6d5ae9 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -18,10 +18,18 @@ extern int do_sys_settimeofday(const struct timespec *tv,
* Kernel time accessors
*/
unsigned long get_seconds(void);
-struct timespec current_kernel_time(void);
+struct timespec64 current_kernel_time64(void);
/* does not take xtime_lock */
struct timespec __current_kernel_time(void);
+static inline struct timespec current_kernel_time(void)
+{
+ struct timespec64 now;
+
+ now = current_kernel_time64();
+ return timespec64_to_timespec(now);
+}
+
/*
* timespec based interfaces
*/
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 91db941..8ccc02c 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1721,7 +1721,7 @@ struct timespec __current_kernel_time(void)
return timespec64_to_timespec(tk_xtime(tk));
}
-struct timespec current_kernel_time(void)
+struct timespec64 current_kernel_time64(void)
{
struct timekeeper *tk = &tk_core.timekeeper;
struct timespec64 now;
@@ -1733,9 +1733,9 @@ struct timespec current_kernel_time(void)
now = tk_xtime(tk);
} while (read_seqcount_retry(&tk_core.seq, seq));
- return timespec64_to_timespec(now);
+ return now;
}
-EXPORT_SYMBOL(current_kernel_time);
+EXPORT_SYMBOL(current_kernel_time64);
struct timespec64 get_monotonic_coarse64(void)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/15] time/hrtimer:Introduce hrtimer_get_res64() with timespec64 type for getting the timer resolution
This patch introduces hrtimer_get_res64() function to get the timer resolution
with timespec64 type, and moves the hrtimer_get_res() function into
include/linux/hrtimer.h as a 'static inline' helper that just calls
hrtimer_get_res64.
It is ready for 2038 year when getting the timer resolution by
hrtimer_get_res64() function
with timespec64 type, and it is convenient to delete the old hrtimer_get_res()
function
in hrtimer.h file.
Signed-off-by: Baolin Wang
---
include/linux/hrtimer.h | 12 +++-
kernel/time/hrtimer.c | 10 +-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 05f6df1..ee8ed44 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -383,7 +383,17 @@ static inline int hrtimer_restart(struct hrtimer *timer)
/* Query timers: */
extern ktime_t hrtimer_get_remaining(const struct hrtimer *timer);
-extern int hrtimer_get_res(const clockid_t which_clock, struct timespec *tp);
+extern int hrtimer_get_res64(const clockid_t which_clock,
+struct timespec64 *tp);
+
+static inline int hrtimer_get_res(const clockid_t which_clock,
+ struct timespec *tp)
+{
+ struct timespec64 *ts64;
+
+ *ts64 = timespec_to_timespec64(*tp);
+ return hrtimer_get_res64(which_clock, ts64);
+}
extern ktime_t hrtimer_get_next_event(void);
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index bee0c1f..508d936 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1175,24 +1175,24 @@ void hrtimer_init(struct hrtimer *timer, clockid_t
clock_id,
EXPORT_SYMBOL_GPL(hrtimer_init);
/**
- * hrtimer_get_res - get the timer resolution for a clock
+ * hrtimer_get_res64 - get the timer resolution for a clock
* @which_clock: which clock to query
- * @tp: pointer to timespec variable to store the resolution
+ * @tp: pointer to timespec64 variable to store the resolution
*
* Store the resolution of the clock selected by @which_clock in the
* variable pointed to by @tp.
*/
-int hrtimer_get_res(const clockid_t which_clock, struct timespec *tp)
+int hrtimer_get_res64(const clockid_t which_clock, struct timespec64 *tp)
{
struct hrtimer_cpu_base *cpu_base;
int base = hrtimer_clockid_to_base(which_clock);
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- *tp = ktime_to_timespec(cpu_base->clock_base[base].resolution);
+ *tp = ktime_to_timespec64(cpu_base->clock_base[base].resolution);
return 0;
}
-EXPORT_SYMBOL_GPL(hrtimer_get_res);
+EXPORT_SYMBOL_GPL(hrtimer_get_res64);
static void __run_hrtimer(struct hrtimer *timer, ktime_t *now)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 04/15] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure
This patch introduces the new methods with timespec64/itimerspec64 type for
k_clcok
structure,converts the timepsec type to timespec64 type in k_clock structure and
converts the itimerspec type to itimerspec64 type to ready for 2038 issue.
Signed-off-by: Baolin Wang
---
include/linux/posix-timers.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/posix-timers.h b/include/linux/posix-timers.h
index 907f3fd..35786c5 100644
--- a/include/linux/posix-timers.h
+++ b/include/linux/posix-timers.h
@@ -98,9 +98,13 @@ struct k_itimer {
struct k_clock {
int (*clock_getres) (const clockid_t which_clock, struct timespec *tp);
+ int (*clock_getres64) (const clockid_t which_clock, struct timespec64
*tp);
int (*clock_set) (const clockid_t which_clock,
const struct timespec *tp);
+ int (*clock_set64) (const clockid_t which_clock,
+ const struct timespec64 *tp);
int (*clock_get) (const clockid_t which_clock, struct timespec * tp);
+ int (*clock_get64) (const clockid_t which_clock, struct timespec64 *tp);
int (*clock_adj) (const clockid_t which_clock, struct timex *tx);
int (*timer_create) (struct k_itimer *timer);
int (*nsleep) (const clockid_t which_clock, int flags,
@@ -109,10 +113,15 @@ struct k_clock {
int (*timer_set) (struct k_itimer * timr, int flags,
struct itimerspec * new_setting,
struct itimerspec * old_setting);
+ int (*timer_set64) (struct k_itimer *timr, int flags,
+ struct itimerspec64 *new_setting,
+ struct itimerspec64 *old_setting);
int (*timer_del) (struct k_itimer * timr);
#define TIMER_RETRY 1
void (*timer_get) (struct k_itimer * timr,
struct itimerspec * cur_setting);
+ void (*timer_get64) (struct k_itimer *timr,
+struct itimerspec64 *cur_setting);
};
extern struct k_clock clock_posix_cpu;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 05/15] posix-timers:Split out the guts of the syscall and change the implementation
This patch splits out the guts of the syscall and changes the syscall
implementation to prepare the converting to 64bit methods for the syscall
function in posix-timers.c file. And next patch will convert the syscall
to 64bit methods with timespec64/itimerspec64 type.
Signed-off-by: Baolin Wang
---
kernel/time/posix-timers.c | 107 +---
1 file changed, 71 insertions(+), 36 deletions(-)
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 31ea01f..0db7f02 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -766,11 +766,8 @@ common_timer_get(struct k_itimer *timr, struct itimerspec
*cur_setting)
cur_setting->it_value = ktime_to_timespec(remaining);
}
-/* Get the time remaining on a POSIX.1b interval timer. */
-SYSCALL_DEFINE2(timer_gettime, timer_t, timer_id,
- struct itimerspec __user *, setting)
+static int __timer_gettime(timer_t timer_id, struct itimerspec *cur_setting)
{
- struct itimerspec cur_setting;
struct k_itimer *timr;
struct k_clock *kc;
unsigned long flags;
@@ -784,9 +781,18 @@ SYSCALL_DEFINE2(timer_gettime, timer_t, timer_id,
if (WARN_ON_ONCE(!kc || !kc->timer_get))
ret = -EINVAL;
else
- kc->timer_get(timr, &cur_setting);
+ kc->timer_get(timr, cur_setting);
unlock_timer(timr, flags);
+ return ret;
+}
+
+/* Get the time remaining on a POSIX.1b interval timer. */
+SYSCALL_DEFINE2(timer_gettime, timer_t, timer_id,
+ struct itimerspec __user *, setting)
+{
+ struct itimerspec cur_setting;
+ int ret = __timer_gettime(timer_id, &cur_setting);
if (!ret && copy_to_user(setting, &cur_setting, sizeof (cur_setting)))
return -EFAULT;
@@ -870,27 +876,14 @@ common_timer_set(struct k_itimer *timr, int flags,
return 0;
}
-/* Set a POSIX.1b interval timer */
-SYSCALL_DEFINE4(timer_settime, timer_t, timer_id, int, flags,
- const struct itimerspec __user *, new_setting,
- struct itimerspec __user *, old_setting)
+static int __timer_settime(timer_t timer_id, int flags, struct itimerspec
*new_spec,
+ struct itimerspec *old_spec)
{
struct k_itimer *timr;
- struct itimerspec new_spec, old_spec;
int error = 0;
unsigned long flag;
- struct itimerspec *rtn = old_setting ? &old_spec : NULL;
struct k_clock *kc;
- if (!new_setting)
- return -EINVAL;
-
- if (copy_from_user(&new_spec, new_setting, sizeof (new_spec)))
- return -EFAULT;
-
- if (!timespec_valid(&new_spec.it_interval) ||
- !timespec_valid(&new_spec.it_value))
- return -EINVAL;
retry:
timr = lock_timer(timer_id, &flag);
if (!timr)
@@ -900,14 +893,38 @@ retry:
if (WARN_ON_ONCE(!kc || !kc->timer_set))
error = -EINVAL;
else
- error = kc->timer_set(timr, flags, &new_spec, rtn);
+ error = kc->timer_set(timr, flags, new_spec, old_spec);
unlock_timer(timr, flag);
if (error == TIMER_RETRY) {
- rtn = NULL; // We already got the old time...
+ old_spec = NULL; // We already got the old time...
goto retry;
}
+ return error;
+}
+
+/* Set a POSIX.1b interval timer */
+SYSCALL_DEFINE4(timer_settime, timer_t, timer_id, int, flags,
+ const struct itimerspec __user *, new_setting,
+ struct itimerspec __user *, old_setting)
+{
+ struct itimerspec new_spec, old_spec;
+ int error = 0;
+ struct itimerspec *rtn = old_setting ? &old_spec : NULL;
+
+ if (!new_setting)
+ return -EINVAL;
+
+ if (copy_from_user(&new_spec, new_setting, sizeof (new_spec)))
+ return -EFAULT;
+
+ if (!timespec_valid(&new_spec.it_interval) ||
+ !timespec_valid(&new_spec.it_value))
+ return -EINVAL;
+
+ error = __timer_settime(timer_id, flags, &new_spec, rtn);
+
if (old_setting && !error &&
copy_to_user(old_setting, &old_spec, sizeof (old_spec)))
error = -EFAULT;
@@ -1002,32 +1019,44 @@ void exit_itimers(struct signal_struct *sig)
}
}
-SYSCALL_DEFINE2(clock_settime, const clockid_t, which_clock,
- const struct timespec __user *, tp)
+static int __clock_settime(clockid_t which_clock, struct timespec *ts)
{
struct k_clock *kc = clockid_to_kclock(which_clock);
- struct timespec new_tp;
if (!kc || !kc->clock_set)
return -EINVAL;
+ return kc->clock_set(which_clock, ts);
+}
+
+SYSCALL_DEFINE2(clock_settime, const clockid_t, which_clock,
+ const struct timespec __user *, tp)
+{
+ struct timespec new_tp;
+
if (copy_from_user(&new_tp, tp, sizeof (*t
[PATCH v2 06/15] posix-timers:Convert to the 64bit methods for the syscall function
This patch converts to the 64bit methods with timespec64/itimerspec64 type
for the syscall function, and changes the syscall implementation according to
the CONFIG_64BIT macro.
Also introduces some default functions with timespec64/itimerspec64 type
for the 64bit methods.
Signed-off-by: Baolin Wang
---
kernel/time/posix-timers.c | 166 +---
1 file changed, 141 insertions(+), 25 deletions(-)
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 0db7f02..4c7c7d3 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -140,6 +140,7 @@ static int common_timer_del(struct k_itimer *timer);
static enum hrtimer_restart posix_timer_fn(struct hrtimer *data);
static struct k_itimer *__lock_timer(timer_t timer_id, unsigned long *flags);
+static struct k_clock *clockid_to_kclock(const clockid_t id);
#define lock_timer(tid, flags)\
({ struct k_itimer *__timr; \
@@ -513,6 +514,57 @@ static struct pid *good_sigevent(sigevent_t * event)
return task_pid(rtn);
}
+static int default_timer_get64(struct k_itimer *timr,
+ struct itimerspec64 *cur_setting64)
+{
+ struct itimerspec cur_setting;
+ struct k_clock *kc = clockid_to_kclock(timr->it_clock);
+
+ kc->timer_get(timr, &cur_setting);
+ return 0;
+}
+
+static int default_timer_set64(struct k_itimer *timr, int flags,
+ struct itimerspec64 *new_setting64,
+ struct itimerspec64 *old_setting64)
+{
+ struct k_clock *kc = clockid_to_kclock(timr->it_clock);
+ struct itimerspec new_setting, old_setting;
+
+ kc->timer_set(timr, flags, &new_setting, &old_setting);
+ return 0;
+}
+
+static int default_clock_set64(const clockid_t which_clock,
+ const struct timespec64 *tp64)
+{
+ struct k_clock *kc = clockid_to_kclock(which_clock);
+ struct timespec tp;
+
+ kc->clock_set(which_clock, &tp);
+ return 0;
+}
+
+static int default_clock_get64(const clockid_t which_clock,
+ struct timespec64 *tp64)
+{
+ struct k_clock *kc = clockid_to_kclock(which_clock);
+ struct timespec tp;
+
+ kc->clock_get(which_clock, &tp);
+ return 0;
+}
+
+static int default_clock_getres64(const clockid_t which_clock,
+ struct timespec64 *tp64)
+{
+ struct k_clock *kc = clockid_to_kclock(which_clock);
+ struct timespec tp;
+
+ kc->clock_getres(which_clock, &tp);
+ return 0;
+}
+
void posix_timers_register_clock(const clockid_t clock_id,
struct k_clock *new_clock)
{
@@ -522,17 +574,28 @@ void posix_timers_register_clock(const clockid_t clock_id,
return;
}
- if (!new_clock->clock_get) {
- printk(KERN_WARNING "POSIX clock id %d lacks clock_get()\n",
+ if (!new_clock->clock_get && !new_clock->clock_get64) {
+ printk(KERN_WARNING "POSIX clock id %d lacks clock_get() and
clock_get64()\n",
clock_id);
return;
}
- if (!new_clock->clock_getres) {
- printk(KERN_WARNING "POSIX clock id %d lacks clock_getres()\n",
+ if (!new_clock->clock_getres && !new_clock->clock_getres64) {
+ printk(KERN_WARNING "POSIX clock id %d lacks clock_getres() and
clock_getres64()\n",
clock_id);
return;
}
+ if (new_clock->timer_get && !new_clock->timer_get64)
+ new_clock->timer_get64 = default_timer_get64;
+ if (new_clock->timer_set && !new_clock->timer_set64)
+ new_clock->timer_set64 = default_timer_set64;
+ if (new_clock->clock_set && !new_clock->clock_set64)
+ new_clock->clock_set64 = default_clock_set64;
+ if (new_clock->clock_get && !new_clock->clock_get64)
+ new_clock->clock_get64 = default_clock_get64;
+ if (new_clock->clock_getres && !new_clock->clock_getres64)
+ new_clock->clock_getres64 = default_clock_getres64;
+
posix_clocks[clock_id] = *new_clock;
}
EXPORT_SYMBOL_GPL(posix_timers_register_clock);
@@ -579,7 +642,8 @@ static struct k_clock *clockid_to_kclock(const clockid_t id)
return (id & CLOCKFD_MASK) == CLOCKFD ?
&clock_posix_dynamic : &clock_posix_cpu;
- if (id >= MAX_CLOCKS || !posix_clocks[id].clock_getres)
+ if (id >= MAX_CLOCKS || (!posix_clocks[id].clock_getres
+ && !posix_clocks[id].clock_getres64))
return NULL;
return &posix_clocks[id];
}
@@ -766,7 +830,7 @@ common_timer_get(struct k_itimer *timr, struct itimerspec
*cur_setting)
cur_setting->it_value = ktime_to_timespec(remaining);
}
-static int __t
[PATCH v3 1/7] ARM: at91/dt: kizbox: rename to at91-kizbox
Rename to match AT91 naming convention.
Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
---
arch/arm/boot/dts/Makefile| 2 +-
arch/arm/boot/dts/{kizbox.dts => at91-kizbox.dts} | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/boot/dts/{kizbox.dts => at91-kizbox.dts} (97%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a1c776b..21726fd 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -18,9 +18,9 @@ dtb-$(CONFIG_SOC_SAM_V4_V5) += \
tny_a9263.dtb \
usb_a9263.dtb \
at91-foxg20.dtb \
+ at91-kizbox.dtb \
at91sam9g20ek.dtb \
at91sam9g20ek_2mmc.dtb \
- kizbox.dtb \
tny_a9g20.dtb \
usb_a9g20.dtb \
usb_a9g20_lpw.dtb \
diff --git a/arch/arm/boot/dts/kizbox.dts b/arch/arm/boot/dts/at91-kizbox.dts
similarity index 97%
rename from arch/arm/boot/dts/kizbox.dts
rename to arch/arm/boot/dts/at91-kizbox.dts
index e83e4f9..e07afae 100644
--- a/arch/arm/boot/dts/kizbox.dts
+++ b/arch/arm/boot/dts/at91-kizbox.dts
@@ -1,5 +1,5 @@
/*
- * kizbox.dts - Device Tree file for Overkiz Kizbox board
+ * at91-kizbox.dts - Device Tree file for Overkiz Kizbox board
*
* Copyright (C) 2012 Boris BREZILLON
*
--
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 v3 2/7] ARM: at91/dt: at91-kizbox: sanitize file
Consists in:
* sorting nodes by address as possible or alphabetically,
* adding myself as new maintainer and
* update license.
Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
---
arch/arm/boot/dts/at91-kizbox.dts | 65 +++
1 file changed, 31 insertions(+), 34 deletions(-)
diff --git a/arch/arm/boot/dts/at91-kizbox.dts
b/arch/arm/boot/dts/at91-kizbox.dts
index e07afae..00c86c1 100644
--- a/arch/arm/boot/dts/at91-kizbox.dts
+++ b/arch/arm/boot/dts/at91-kizbox.dts
@@ -1,16 +1,16 @@
/*
* at91-kizbox.dts - Device Tree file for Overkiz Kizbox board
*
- * Copyright (C) 2012 Boris BREZILLON
+ * Copyright (C) 2012-2014 Boris BREZILLON
+ * 2014-2015 Gaël PORTAY
*
- * Licensed under GPLv2.
+ * Licensed under GPLv2 or later.
*/
/dts-v1/;
#include "at91sam9g20.dtsi"
/ {
-
- model = "Overkiz kizbox";
+ model = "Overkiz Kizbox";
compatible = "overkiz,kizbox", "atmel,at91sam9g20", "atmel,at91sam9";
chosen {
@@ -38,10 +38,6 @@
ahb {
apb {
- dbgu: serial@f200 {
- status = "okay";
- };
-
usart0: serial@fffb {
status = "okay";
};
@@ -57,6 +53,10 @@
status = "okay";
};
+ dbgu: serial@f200 {
+ status = "okay";
+ };
+
watchdog@fd40 {
timeout-sec = <15>;
atmel,max-heartbeat-sec = <16>;
@@ -65,6 +65,11 @@
};
};
+ usb0: ohci@0050 {
+ num-ports = <1>;
+ status = "okay";
+ };
+
nand0: nand@4000 {
nand-bus-width = <8>;
nand-ecc-mode = "soft";
@@ -79,24 +84,36 @@
label = "ubi";
reg = <0xc 0x7f4>;
};
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reset {
+ label = "reset";
+ gpios = <&pioB 30 GPIO_ACTIVE_LOW>;
+ linux,code = <0x100>;
+ gpio-key,wakeup;
};
- usb0: ohci@0050 {
- num-ports = <1>;
- status = "okay";
+ mode {
+ label = "mode";
+ gpios = <&pioB 31 GPIO_ACTIVE_LOW>;
+ linux,code = <0x101>;
+ gpio-key,wakeup;
};
};
i2c@0 {
status = "okay";
- pcf8563@51 {
- /* nxp pcf8563 rtc */
+ rtc: pcf8563@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
};
-
};
leds {
@@ -127,24 +144,4 @@
linux,default-trigger = "none";
};
};
-
- gpio_keys {
- compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
-
- reset {
- label = "reset";
- gpios = <&pioB 30 GPIO_ACTIVE_LOW>;
- linux,code = <0x100>;
- gpio-key,wakeup;
- };
-
- mode {
- label = "mode";
- gpios = <&pioB 31 GPIO_ACTIVE_LOW>;
- linux,code = <0x101>;
- gpio-key,wakeup;
- };
- };
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 07/15] time:Introduce the do_sys_settimeofday64() function with timespec64 type
This patch introduces the do_sys_settimeofday64() function with timespec64
type, that makes this function ready for 2038 issue when setting the time of
day.
And moves the do_sys_settimeofday() function to the timekeeping.h file.
Signed-off-by: Baolin Wang
---
include/linux/timekeeping.h | 12 ++--
kernel/time/time.c | 10 ++
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index c6d5ae9..89beb62 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -11,8 +11,16 @@ extern int timekeeping_suspended;
*/
extern void do_gettimeofday(struct timeval *tv);
extern int do_settimeofday64(const struct timespec64 *ts);
-extern int do_sys_settimeofday(const struct timespec *tv,
- const struct timezone *tz);
+extern int do_sys_settimeofday64(const struct timespec64 *tv,
+const struct timezone *tz);
+static inline int do_sys_settimeofday(const struct timespec *tv,
+ const struct timezone *tz)
+{
+ struct timespec64 ts64;
+
+ ts64 = timespec_to_timespec64(*tv);
+ return do_sys_settimeofday64(&ts64, tz);
+}
/*
* Kernel time accessors
diff --git a/kernel/time/time.c b/kernel/time/time.c
index 2c85b77..f43011b 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -160,15 +160,17 @@ static inline void warp_clock(void)
* various programs will get confused when the clock gets warped.
*/
-int do_sys_settimeofday(const struct timespec *tv, const struct timezone *tz)
+int do_sys_settimeofday64(const struct timespec64 *tv, const struct timezone
*tz)
{
static int firsttime = 1;
int error = 0;
+ struct timespec ts;
- if (tv && !timespec_valid(tv))
+ if (tv && !timespec64_valid(tv))
return -EINVAL;
- error = security_settime(tv, tz);
+ ts = timespec64_to_timespec(*tv);
+ error = security_settime(&ts, tz);
if (error)
return error;
@@ -182,7 +184,7 @@ int do_sys_settimeofday(const struct timespec *tv, const
struct timezone *tz)
}
}
if (tv)
- return do_settimeofday(tv);
+ return do_settimeofday64(tv);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 08/15] time/posix-timers:Convert to the 64bit methods for k_clock callback functions
This patch converts the timepsec type to timespec64 type, and converts the
itimerspec type to itimerspec64 type for the k_clock callback functions.
This patch also converts the timespec type to timespec64 type for
timekeeping_clocktai()
function which is used only in the posix-timers.c file.
Signed-off-by: Baolin Wang
---
include/linux/timekeeping.h |4 +-
kernel/time/posix-timers.c | 96 +--
kernel/time/timekeeping.h |2 +-
3 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 89beb62..c3345d5 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -250,9 +250,9 @@ static inline void get_monotonic_boottime64(struct
timespec64 *ts)
*ts = ktime_to_timespec64(ktime_get_boottime());
}
-static inline void timekeeping_clocktai(struct timespec *ts)
+static inline void timekeeping_clocktai(struct timespec64 *ts)
{
- *ts = ktime_to_timespec(ktime_get_clocktai());
+ *ts = ktime_to_timespec64(ktime_get_clocktai());
}
/*
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 4c7c7d3..8ced634 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -132,9 +132,9 @@ static struct k_clock posix_clocks[MAX_CLOCKS];
static int common_nsleep(const clockid_t, int flags, struct timespec *t,
struct timespec __user *rmtp);
static int common_timer_create(struct k_itimer *new_timer);
-static void common_timer_get(struct k_itimer *, struct itimerspec *);
+static void common_timer_get(struct k_itimer *, struct itimerspec64 *);
static int common_timer_set(struct k_itimer *, int,
- struct itimerspec *, struct itimerspec *);
+ struct itimerspec64 *, struct itimerspec64 *);
static int common_timer_del(struct k_itimer *timer);
static enum hrtimer_restart posix_timer_fn(struct hrtimer *data);
@@ -204,17 +204,17 @@ static inline void unlock_timer(struct k_itimer *timr,
unsigned long flags)
}
/* Get clock_realtime */
-static int posix_clock_realtime_get(clockid_t which_clock, struct timespec *tp)
+static int posix_clock_realtime_get(clockid_t which_clock, struct timespec64
*tp)
{
- ktime_get_real_ts(tp);
+ ktime_get_real_ts64(tp);
return 0;
}
/* Set clock_realtime */
static int posix_clock_realtime_set(const clockid_t which_clock,
- const struct timespec *tp)
+ const struct timespec64 *tp)
{
- return do_sys_settimeofday(tp, NULL);
+ return do_sys_settimeofday64(tp, NULL);
}
static int posix_clock_realtime_adj(const clockid_t which_clock,
@@ -226,48 +226,48 @@ static int posix_clock_realtime_adj(const clockid_t
which_clock,
/*
* Get monotonic time for posix timers
*/
-static int posix_ktime_get_ts(clockid_t which_clock, struct timespec *tp)
+static int posix_ktime_get_ts(clockid_t which_clock, struct timespec64 *tp)
{
- ktime_get_ts(tp);
+ ktime_get_ts64(tp);
return 0;
}
/*
* Get monotonic-raw time for posix timers
*/
-static int posix_get_monotonic_raw(clockid_t which_clock, struct timespec *tp)
+static int posix_get_monotonic_raw(clockid_t which_clock, struct timespec64
*tp)
{
- getrawmonotonic(tp);
+ getrawmonotonic64(tp);
return 0;
}
-static int posix_get_realtime_coarse(clockid_t which_clock, struct timespec
*tp)
+static int posix_get_realtime_coarse(clockid_t which_clock, struct timespec64
*tp)
{
- *tp = current_kernel_time();
+ *tp = current_kernel_time64();
return 0;
}
static int posix_get_monotonic_coarse(clockid_t which_clock,
- struct timespec *tp)
+ struct timespec64 *tp)
{
- *tp = get_monotonic_coarse();
+ *tp = get_monotonic_coarse64();
return 0;
}
-static int posix_get_coarse_res(const clockid_t which_clock, struct timespec
*tp)
+static int posix_get_coarse_res(const clockid_t which_clock, struct timespec64
*tp)
{
- *tp = ktime_to_timespec(KTIME_LOW_RES);
+ *tp = ktime_to_timespec64(KTIME_LOW_RES);
return 0;
}
-static int posix_get_boottime(const clockid_t which_clock, struct timespec *tp)
+static int posix_get_boottime(const clockid_t which_clock, struct timespec64
*tp)
{
- get_monotonic_boottime(tp);
+ get_monotonic_boottime64(tp);
return 0;
}
-static int posix_get_tai(clockid_t which_clock, struct timespec *tp)
+static int posix_get_tai(clockid_t which_clock, struct timespec64 *tp)
{
timekeeping_clocktai(tp);
return 0;
@@ -279,57 +279,57 @@ static int posix_get_tai(clockid_t which_clock, struct
timespec *tp)
static __init int init_posix_timers(void)
{
struct k_clock clock_realtime = {
- .clock_getres = hrtimer_g
[PATCH v2 09/15] char/mmtimer:Convert to the 64bit methods for k_clock callback function
This patch converts to the 64bit methods for k_clock callback
function, that converts the timespec type to timespec64 type and
converts the itimerspec type to itimerspec64 type.
Signed-off-by: Baolin Wang
---
drivers/char/mmtimer.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/char/mmtimer.c b/drivers/char/mmtimer.c
index 3d6c067..213d0bb 100644
--- a/drivers/char/mmtimer.c
+++ b/drivers/char/mmtimer.c
@@ -478,18 +478,18 @@ static int sgi_clock_period;
static struct timespec sgi_clock_offset;
static int sgi_clock_period;
-static int sgi_clock_get(clockid_t clockid, struct timespec *tp)
+static int sgi_clock_get(clockid_t clockid, struct timespec64 *tp)
{
u64 nsec;
nsec = rtc_time() * sgi_clock_period
+ sgi_clock_offset.tv_nsec;
- *tp = ns_to_timespec(nsec);
+ *tp = ns_to_timespec64(nsec);
tp->tv_sec += sgi_clock_offset.tv_sec;
return 0;
};
-static int sgi_clock_set(const clockid_t clockid, const struct timespec *tp)
+static int sgi_clock_set(const clockid_t clockid, const struct timespec64 *tp)
{
u64 nsec;
@@ -657,7 +657,7 @@ static int sgi_timer_del(struct k_itimer *timr)
}
/* Assumption: it_lock is already held with irq's disabled */
-static void sgi_timer_get(struct k_itimer *timr, struct itimerspec
*cur_setting)
+static void sgi_timer_get(struct k_itimer *timr, struct itimerspec64
*cur_setting)
{
if (timr->it.mmtimer.clock == TIMER_OFF) {
@@ -668,14 +668,14 @@ static void sgi_timer_get(struct k_itimer *timr, struct
itimerspec *cur_setting)
return;
}
- cur_setting->it_interval = ns_to_timespec(timr->it.mmtimer.incr *
sgi_clock_period);
- cur_setting->it_value = ns_to_timespec((timr->it.mmtimer.expires -
rtc_time()) * sgi_clock_period);
+ cur_setting->it_interval = ns_to_timespec64(timr->it.mmtimer.incr *
sgi_clock_period);
+ cur_setting->it_value = ns_to_timespec64((timr->it.mmtimer.expires -
rtc_time()) * sgi_clock_period);
}
static int sgi_timer_set(struct k_itimer *timr, int flags,
- struct itimerspec * new_setting,
- struct itimerspec * old_setting)
+ struct itimerspec64 *new_setting,
+ struct itimerspec64 *old_setting)
{
unsigned long when, period, irqflags;
int err = 0;
@@ -687,8 +687,8 @@ static int sgi_timer_set(struct k_itimer *timr, int flags,
sgi_timer_get(timr, old_setting);
sgi_timer_del(timr);
- when = timespec_to_ns(&new_setting->it_value);
- period = timespec_to_ns(&new_setting->it_interval);
+ when = timespec64_to_ns(&new_setting->it_value);
+ period = timespec64_to_ns(&new_setting->it_interval);
if (when == 0)
/* Clear timer */
@@ -699,11 +699,9 @@ static int sgi_timer_set(struct k_itimer *timr, int flags,
return -ENOMEM;
if (flags & TIMER_ABSTIME) {
- struct timespec n;
unsigned long now;
- getnstimeofday(&n);
- now = timespec_to_ns(&n);
+ now = ktime_get_real_ns();
if (when > now)
when -= now;
else
@@ -765,7 +763,7 @@ static int sgi_timer_set(struct k_itimer *timr, int flags,
return err;
}
-static int sgi_clock_getres(const clockid_t which_clock, struct timespec *tp)
+static int sgi_clock_getres(const clockid_t which_clock, struct timespec64 *tp)
{
tp->tv_sec = 0;
tp->tv_nsec = sgi_clock_period;
@@ -773,13 +771,13 @@ static int sgi_clock_getres(const clockid_t which_clock,
struct timespec *tp)
}
static struct k_clock sgi_clock = {
- .clock_set = sgi_clock_set,
- .clock_get = sgi_clock_get,
- .clock_getres = sgi_clock_getres,
+ .clock_set64= sgi_clock_set,
+ .clock_get64= sgi_clock_get,
+ .clock_getres64 = sgi_clock_getres,
.timer_create = sgi_timer_create,
- .timer_set = sgi_timer_set,
+ .timer_set64= sgi_timer_set,
.timer_del = sgi_timer_del,
- .timer_get = sgi_timer_get
+ .timer_get64= sgi_timer_get
};
/**
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 10/15] time/alarmtimer:Convert to the new methods for k_clock structure
This patch changes to the new methods with timespec64/itimerspec64
type of k_clock structure, and converts the timespec/itimerspec type to
timespec64/itimerspec64 typein alarmtimer.c file.
Signed-off-by: Baolin Wang
---
kernel/time/alarmtimer.c | 43 ++-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 1b001ed..68186e1 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -489,35 +489,36 @@ static enum alarmtimer_restart alarm_handle_timer(struct
alarm *alarm,
/**
* alarm_clock_getres - posix getres interface
* @which_clock: clockid
- * @tp: timespec to fill
+ * @tp: timespec64 to fill
*
* Returns the granularity of underlying alarm base clock
*/
-static int alarm_clock_getres(const clockid_t which_clock, struct timespec *tp)
+static int alarm_clock_getres(const clockid_t which_clock,
+ struct timespec64 *tp)
{
clockid_t baseid = alarm_bases[clock2alarm(which_clock)].base_clockid;
if (!alarmtimer_get_rtcdev())
return -EINVAL;
- return hrtimer_get_res(baseid, tp);
+ return hrtimer_get_res64(baseid, tp);
}
/**
* alarm_clock_get - posix clock_get interface
* @which_clock: clockid
- * @tp: timespec to fill.
+ * @tp: timespec64 to fill.
*
* Provides the underlying alarm base time.
*/
-static int alarm_clock_get(clockid_t which_clock, struct timespec *tp)
+static int alarm_clock_get(clockid_t which_clock, struct timespec64 *tp)
{
struct alarm_base *base = &alarm_bases[clock2alarm(which_clock)];
if (!alarmtimer_get_rtcdev())
return -EINVAL;
- *tp = ktime_to_timespec(base->gettime());
+ *tp = ktime_to_timespec64(base->gettime());
return 0;
}
@@ -547,24 +548,24 @@ static int alarm_timer_create(struct k_itimer *new_timer)
/**
* alarm_timer_get - posix timer_get interface
* @new_timer: k_itimer pointer
- * @cur_setting: itimerspec data to fill
+ * @cur_setting: itimerspec64 data to fill
*
* Copies out the current itimerspec data
*/
static void alarm_timer_get(struct k_itimer *timr,
- struct itimerspec *cur_setting)
+ struct itimerspec64 *cur_setting)
{
ktime_t relative_expiry_time =
alarm_expires_remaining(&(timr->it.alarm.alarmtimer));
if (ktime_to_ns(relative_expiry_time) > 0) {
- cur_setting->it_value = ktime_to_timespec(relative_expiry_time);
+ cur_setting->it_value =
ktime_to_timespec64(relative_expiry_time);
} else {
cur_setting->it_value.tv_sec = 0;
cur_setting->it_value.tv_nsec = 0;
}
- cur_setting->it_interval = ktime_to_timespec(timr->it.alarm.interval);
+ cur_setting->it_interval = ktime_to_timespec64(timr->it.alarm.interval);
}
/**
@@ -588,14 +589,14 @@ static int alarm_timer_del(struct k_itimer *timr)
* alarm_timer_set - posix timer_set interface
* @timr: k_itimer pointer to be deleted
* @flags: timer flags
- * @new_setting: itimerspec to be used
- * @old_setting: itimerspec being replaced
+ * @new_setting: itimerspec64 to be used
+ * @old_setting: itimerspec64 being replaced
*
* Sets the timer to new_setting, and starts the timer.
*/
static int alarm_timer_set(struct k_itimer *timr, int flags,
- struct itimerspec *new_setting,
- struct itimerspec *old_setting)
+ struct itimerspec64 *new_setting,
+ struct itimerspec64 *old_setting)
{
ktime_t exp;
@@ -613,8 +614,8 @@ static int alarm_timer_set(struct k_itimer *timr, int flags,
return TIMER_RETRY;
/* start the timer */
- timr->it.alarm.interval = timespec_to_ktime(new_setting->it_interval);
- exp = timespec_to_ktime(new_setting->it_value);
+ timr->it.alarm.interval = timespec64_to_ktime(new_setting->it_interval);
+ exp = timespec64_to_ktime(new_setting->it_value);
/* Convert (if necessary) to absolute time */
if (flags != TIMER_ABSTIME) {
ktime_t now;
@@ -670,7 +671,7 @@ static int alarmtimer_do_nsleep(struct alarm *alarm,
ktime_t absexp)
/**
- * update_rmtp - Update remaining timespec value
+ * update_rmtp - Update remaining timespec64 value
* @exp: expiration time
* @type: timer type
* @rmtp: user pointer to remaining timepsec value
@@ -824,12 +825,12 @@ static int __init alarmtimer_init(void)
int error = 0;
int i;
struct k_clock alarm_clock = {
- .clock_getres = alarm_clock_getres,
- .clock_get = alarm_clock_get,
+ .clock_getres64 = alarm_clock_getres,
+ .clock_get64= alarm_clock_get,
.timer_create = alarm_timer_create,
[PATCH v2 11/15] time/posix-clock:Convert to the 64bit methods for k_clock and posix_clock_operations structure
This patch converts the posix clock operations over to the new methods with
timespec64/itimerspec64 type to making them ready for 2038, and it is based on
the ptp patch series.
And also changes to the 64bit methods for k_clock structure, that
converts the timespec/itimerspec type to timespec64/itimerspec64 type.
Signed-off-by: Baolin Wang
---
drivers/ptp/ptp_clock.c | 26 --
include/linux/posix-clock.h | 10 +-
kernel/time/posix-clock.c | 20 ++--
3 files changed, 23 insertions(+), 33 deletions(-)
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index bee8270..8c086e7 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -97,32 +97,24 @@ static s32 scaled_ppm_to_ppb(long ppm)
/* posix clock implementation */
-static int ptp_clock_getres(struct posix_clock *pc, struct timespec *tp)
+static int ptp_clock_getres(struct posix_clock *pc, struct timespec64 *tp)
{
tp->tv_sec = 0;
tp->tv_nsec = 1;
return 0;
}
-static int ptp_clock_settime(struct posix_clock *pc, const struct timespec *tp)
+static int ptp_clock_settime(struct posix_clock *pc,
+ const struct timespec64 *tp)
{
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
- struct timespec64 ts = timespec_to_timespec64(*tp);
-
- return ptp->info->settime64(ptp->info, &ts);
+ return ptp->info->settime64(ptp->info, tp);
}
-static int ptp_clock_gettime(struct posix_clock *pc, struct timespec *tp)
+static int ptp_clock_gettime(struct posix_clock *pc, struct timespec64 *tp)
{
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
- struct timespec64 ts;
- int err;
-
- err = ptp->info->gettime64(ptp->info, &ts);
- if (!err)
- *tp = timespec64_to_timespec(ts);
-
- return err;
+ return ptp->info->gettime64(ptp->info, tp);
}
static int ptp_clock_adjtime(struct posix_clock *pc, struct timex *tx)
@@ -134,8 +126,7 @@ static int ptp_clock_adjtime(struct posix_clock *pc, struct
timex *tx)
ops = ptp->info;
if (tx->modes & ADJ_SETOFFSET) {
- struct timespec ts;
- ktime_t kt;
+ struct timespec64 ts;
s64 delta;
ts.tv_sec = tx->time.tv_sec;
@@ -147,8 +138,7 @@ static int ptp_clock_adjtime(struct posix_clock *pc, struct
timex *tx)
if ((unsigned long) ts.tv_nsec >= NSEC_PER_SEC)
return -EINVAL;
- kt = timespec_to_ktime(ts);
- delta = ktime_to_ns(kt);
+ delta = timespec64_to_ns(&ts);
err = ops->adjtime(ops, delta);
} else if (tx->modes & ADJ_FREQUENCY) {
s32 ppb = scaled_ppm_to_ppb(tx->freq);
diff --git a/include/linux/posix-clock.h b/include/linux/posix-clock.h
index 34c4498..fd7e22c 100644
--- a/include/linux/posix-clock.h
+++ b/include/linux/posix-clock.h
@@ -59,23 +59,23 @@ struct posix_clock_operations {
int (*clock_adjtime)(struct posix_clock *pc, struct timex *tx);
- int (*clock_gettime)(struct posix_clock *pc, struct timespec *ts);
+ int (*clock_gettime)(struct posix_clock *pc, struct timespec64 *ts);
- int (*clock_getres) (struct posix_clock *pc, struct timespec *ts);
+ int (*clock_getres)(struct posix_clock *pc, struct timespec64 *ts);
int (*clock_settime)(struct posix_clock *pc,
- const struct timespec *ts);
+ const struct timespec64 *ts);
int (*timer_create) (struct posix_clock *pc, struct k_itimer *kit);
int (*timer_delete) (struct posix_clock *pc, struct k_itimer *kit);
void (*timer_gettime)(struct posix_clock *pc,
- struct k_itimer *kit, struct itimerspec *tsp);
+ struct k_itimer *kit, struct itimerspec64 *tsp);
int (*timer_settime)(struct posix_clock *pc,
struct k_itimer *kit, int flags,
- struct itimerspec *tsp, struct itimerspec *old);
+ struct itimerspec64 *tsp, struct itimerspec64
*old);
/*
* Optional character device methods:
*/
diff --git a/kernel/time/posix-clock.c b/kernel/time/posix-clock.c
index ce033c7..e21e4c1 100644
--- a/kernel/time/posix-clock.c
+++ b/kernel/time/posix-clock.c
@@ -297,7 +297,7 @@ out:
return err;
}
-static int pc_clock_gettime(clockid_t id, struct timespec *ts)
+static int pc_clock_gettime(clockid_t id, struct timespec64 *ts)
{
struct posix_clock_desc cd;
int err;
@@ -316,7 +316,7 @@ static int pc_clock_gettime(clockid_t id, struct timespec
*ts)
return err;
}
-static int pc_clock_getres(clockid_t id, struct timespec *ts)
+static int pc_clock_getres(clockid_t id, struct timespec64 *ts)
{
[PATCH v2 12/15] time/time:Introduce the timespec64_to_jiffies/jiffies_to_timespec64 function
This patch introduces the timespec64_to_jiffies() and jiffies_to_timespec64()
functions, that implement the conversion between cputime and timespec64. And
remove the old functions timespec64_to_jiffies()/jiffies_to_timespec64() to
jiffies.h file.
Signed-off-by: Baolin Wang
---
include/linux/jiffies.h | 21 ++---
kernel/time/time.c | 12 ++--
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index c367cbd..16a30c1 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -290,9 +290,24 @@ static inline u64 jiffies_to_nsecs(const unsigned long j)
extern unsigned long msecs_to_jiffies(const unsigned int m);
extern unsigned long usecs_to_jiffies(const unsigned int u);
-extern unsigned long timespec_to_jiffies(const struct timespec *value);
-extern void jiffies_to_timespec(const unsigned long jiffies,
- struct timespec *value);
+extern unsigned long __timespec_to_jiffies(unsigned long sec, long nsec);
+extern unsigned long timespec64_to_jiffies(const struct timespec64 *value);
+extern void jiffies_to_timespec64(const unsigned long jiffies,
+ struct timespec64 *value);
+static inline unsigned long timespec_to_jiffies(const struct timespec *value)
+{
+ return __timespec_to_jiffies(value->tv_sec, value->tv_nsec);
+}
+
+static inline void jiffies_to_timespec(const unsigned long jiffies,
+ struct timespec *value)
+{
+ struct timespec64 *ts;
+
+ *ts = timespec_to_timespec64(*value);
+ jiffies_to_timespec64(jiffies, ts);
+}
+
extern unsigned long timeval_to_jiffies(const struct timeval *value);
extern void jiffies_to_timeval(const unsigned long jiffies,
struct timeval *value);
diff --git a/kernel/time/time.c b/kernel/time/time.c
index f43011b..3aba16f 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -571,7 +571,7 @@ EXPORT_SYMBOL(usecs_to_jiffies);
* The >> (NSEC_JIFFIE_SC - SEC_JIFFIE_SC) converts the scaled nsec
* value to a scaled second value.
*/
-static unsigned long
+unsigned long
__timespec_to_jiffies(unsigned long sec, long nsec)
{
nsec = nsec + TICK_NSEC - 1;
@@ -585,17 +585,17 @@ __timespec_to_jiffies(unsigned long sec, long nsec)
(NSEC_JIFFIE_SC - SEC_JIFFIE_SC))) >> SEC_JIFFIE_SC;
}
+EXPORT_SYMBOL(__timespec_to_jiffies);
unsigned long
-timespec_to_jiffies(const struct timespec *value)
+timespec64_to_jiffies(const struct timespec64 *value)
{
return __timespec_to_jiffies(value->tv_sec, value->tv_nsec);
}
-
-EXPORT_SYMBOL(timespec_to_jiffies);
+EXPORT_SYMBOL(timespec64_to_jiffies);
void
-jiffies_to_timespec(const unsigned long jiffies, struct timespec *value)
+jiffies_to_timespec64(const unsigned long jiffies, struct timespec64 *value)
{
/*
* Convert jiffies to nanoseconds and separate with
@@ -606,7 +606,7 @@ jiffies_to_timespec(const unsigned long jiffies, struct
timespec *value)
NSEC_PER_SEC, &rem);
value->tv_nsec = rem;
}
-EXPORT_SYMBOL(jiffies_to_timespec);
+EXPORT_SYMBOL(jiffies_to_timespec64);
/*
* We could use a similar algorithm to timespec_to_jiffies (with a
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 1/4] fs: Add generic file system event notifications
Hi,
On 04/29/2015 05:55 PM, Greg KH wrote:
> On Wed, Apr 29, 2015 at 05:48:14PM +0200, Beata Michalska wrote:
>> On 04/29/2015 03:45 PM, Greg KH wrote:
>>> On Wed, Apr 29, 2015 at 01:10:34PM +0200, Beata Michalska wrote:
>>> It needs to be done internally by the app but is doable.
>>> The app knows what it is watching, so it can maintain the mappings.
>>> So prior to activating the notifications it can call 'stat' on the
>>> mount point.
>>> Stat struct gives the 'st_dev' which is the device id. Same will be
>>> reported
>>> within the message payload (through major:minor numbers). So having
>>> this,
>>> the app is able to get any other information it needs.
>>> Note that the events refer to the file system as a whole and they may
>>> not
>>> necessarily have anything to do with the actual block device.
>
> How are you going to show an event for a filesystem that is made up of
> multiple block devices?
AFAIK, for such filesystems there will be similar case with the anonymous
major:minor numbers - at least the btrfs is doing so. Not sure we can
differentiate here the actual block device. So in this case such events
serves merely as a hint for the userspace.
>>>
>>> "hint" seems like this isn't really going to work well.
>>>
>>> Do you have userspace code that can properly map this back to the "real"
>>> device that is causing problems? Without that, this doesn't seem all
>>> that useful as no one would be able to use those events.
>>
>> I'm not sure we are on the same page here.
>> This is about watching the file system rather than the 'real' device.
>> Like the threshold notifications: you would like to know when you
>> will be approaching certain level of available space for the tmpfs
>> mounted on /tmp. You do know you are watching the /tmp
>> and you know that the dev numbers for this are 0:20 (or so).
>> (either through calling stat on /tmp or through reading the
>> /proc/$$/mountinfo)
>> With this interface you can setup threshold levels
>> for /tmp. Then, once the limit is reached the event will be
>> sent with those anonymous major:minor numbers.
>>
>> I can provide a sample code which will demonstrate how this
>> can be achieved.
>
> Yes, example code would be helpful to understand this, thanks.
>
> greg k-h
>
Below is an absolutely *simplified* sample application.
Hope this will be helpful.
---
#include
#include
#include
#include
#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))
#define LOG(args...) fprintf(stderr, args)
#define BUFF_SIZE 256
struct list_node {
struct list_node *next;
struct list_node *prev;
};
#define MBITS 20
#define MAKE_DEV(major, minor) \
((major) << MBITS | ((minor) & ((1U << MBITS) -1)))
struct mount_data {
struct list_node link;
dev_t dev;
char *dname;
};
static struct list_node mount_list = {&mount_list, &mount_list};
static void list_add(struct list_node *new_node, struct list_node *head)
{
struct list_node *node;
node = head->next;
head->next = new_node;
new_node->prev = head;
new_node->next = node;
node->prev = new_node;
}
static struct mount_data *find_mount(struct list_node *mlist, dev_t dev)
{
struct list_node *node;
struct mount_data *mdata;
for (node = mlist->prev; node != mlist; node = node->prev) {
mdata = (char*)node - ((size_t) &((struct mount_data*)0)->link);
if (mdata->dev == dev)
return mdata;
}
return NULL;
}
static void create_mount_base(struct list_node *mlist)
{
FILE *f;
char entry[BUFF_SIZE];
regex_t re;
if (!(f = fopen("/proc/self/mountinfo", "r")))
return;
if (regcomp(&re, "[0-9]*:[0-9]*", REG_EXTENDED))
goto leave;
while (fgets(entry, BUFF_SIZE, f)) {
regmatch_t pmatch;
int dev_major, dev_minor;
char *s;
if (regexec(&re, entry, 1, &pmatch, 0))
continue;
if (pmatch.rm_so == -1)
continue;
sscanf(entry + pmatch.rm_so, "%d:%d",
&dev_major, &dev_minor);
s = entry + pmatch.rm_eo;
s = strtok(++s, " ");
if (!s)
continue;
if (s = strtok(NULL, " ")) {
struct mount_data *data = malloc(sizeof(*data));
if (!data)
continue;
data->dev = MAKE_DEV(dev_major, dev_minor);
data->dname = strdup(s);
list_add(&data->link, mlist);
}
}
regfree(&re);
leave:
close(f);
return;
}
static int parse_event(struct nl_cache
[TIMEKEEPING/JIFFIES-PROBLEM] [tick_handover_do_timer strictly tied to hotplug]
Hi,
Linux version 3.10.17
Problem Statement: The timekeeping/do_timer seems to be stopped and
the core (in this case it is core0) which is aborting is stuck in the
loop which relies on jiffies.
The root cause/Reason:
we have tickless kernel, so cpu goes to deep idle state, and stop
sched tick. tick_nohz_stop_sched_tick
tick_sched_do_timer should then take the job and whichever cpu is
running transfer jiffies incrementing job to itself. which is
tick_sched_do_timer
but when say core0 has raised BUG, ipi_cpu_stop will amek other cpu to
go to stop. and clcokevents_notify/tick_notify/hrtimer_notifiy
eventually seem to be conencted through cpu_chain.
but this code belong to hotplug where cpu_down happen and then it can
successfully call tick_handover_do_timer which will take over the duty
from dying cpu and assign it to the one which is online.
static void tick_handover_do_timer(int *cpup) { if (*cpup ==
tick_do_timer_cpu) { int cpu = cpumask_first(cpu_online_mask);
tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu : TICK_DO_TIMER_NONE; } }
but since cpu_down is not getting called, this handover is not happening.
and the last status of the variable tick_do_timer_cpu is always
pointing to DEAD cpu (1,2 or 3).
and core0 waits forever (where if the code relies on the increment of jiffies).
what is the right way to approach this problem, at first it looks like
kernel should take care of handing over the jiffies job to other
online core indepedent of hotplug.
Regards,
Oza.
--
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] bitmap: remove explicit newline handling using scnprintf format string
On 29/04/15 23:48, Andrew Morton wrote: On Tue, 28 Apr 2015 16:36:41 +0100 Sudeep Holla wrote: bitmap_print_to_pagebuf uses scnprintf to copy the cpumask/list to page buffer. It handles the newline and trailing null character explicitly. bitmap_print_to_pagebuf() is horrid :( That automagic "assume caller passed us an offset into a PAGE_SIZE area". Agreed. It's unnecessary and also partially duplicated as scnprintf already adds trailing null character. The newline can be passed through format string to scnprintf. This patch does that simplification. However theoritically there's one behavior difference: when the buffer is too small, the original code would still output '\n' at the end while the new code(with this patch) would just continue to print the formatted string. Since this function is dealing with only page buffers, it's highly unlikely to hit that corner case. This patch will help in auditing the users of bitmap_print_to_pagebuf to verify that the buffer passed is large enough and get rid of it completely by replacing them with direct scnprintf() Yes, bitmap_print_to_pagebuf() should be eliminated. Make the callers keep track of how much room they have in their buffer. Yes that's what Tejun also mentioned in earlier mail. This patch is just to audit all the callers and check if something breaks before we replace this with scnprintf() at the call sites. --- a/lib/bitmap.c +++ b/lib/bitmap.c @@ -462,19 +462,18 @@ EXPORT_SYMBOL(bitmap_parse_user); * Output format is a comma-separated list of decimal numbers and * ranges if list is specified or hex digits grouped into comma-separated * sets of 8 digits/set. Returns the number of characters written to buf. + * It is assumed that the buffer passed is atleast PAGE_SIZE and easily + * accommodate nmaskbits. Well kind-of. How does this look? Looks good to me. Regards, Sudeep --- a/lib/bitmap.c~bitmap-remove-explicit-newline-handling-using-scnprintf-format-string-fix +++ a/lib/bitmap.c @@ -462,8 +462,10 @@ EXPORT_SYMBOL(bitmap_parse_user); * Output format is a comma-separated list of decimal numbers and * ranges if list is specified or hex digits grouped into comma-separated * sets of 8 digits/set. Returns the number of characters written to buf. - * It is assumed that the buffer passed is atleast PAGE_SIZE and easily - * accommodate nmaskbits. + * + * It is assumed that @buf is a pointer into a PAGE_SIZE area and that + * sufficient storage remains at @buf to accommodate the + * bitmap_print_to_pagebuf() output. */ int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp, int nmaskbits) -- 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 13/15] cputime:Introduce the cputime_to_timespec64/timespec64_to_cputime function
This patch introduces some functions for converting cputime to timespec64 and
back,
that repalce the timespec type with timespec64 type, as well as for arch/s390
and
arch/powerpc architecture.
And these new methods will replace the old
cputime_to_timespec/timespec_to_cputime
function to ready for 2038 issue. The cputime_to_timespec/timespec_to_cputime
functions
are moved to include/linux/cputime.h file for removing conveniently.
Signed-off-by: Baolin Wang
---
arch/powerpc/include/asm/cputime.h|6 +++---
arch/s390/include/asm/cputime.h |8
include/asm-generic/cputime_jiffies.h | 10 +-
include/asm-generic/cputime_nsecs.h |4 ++--
include/linux/cputime.h | 15 +++
5 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/cputime.h
b/arch/powerpc/include/asm/cputime.h
index e245255..5dda5c0 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -154,9 +154,9 @@ static inline cputime_t secs_to_cputime(const unsigned long
sec)
}
/*
- * Convert cputime <-> timespec
+ * Convert cputime <-> timespec64
*/
-static inline void cputime_to_timespec(const cputime_t ct, struct timespec *p)
+static inline void cputime_to_timespec64(const cputime_t ct, struct timespec64
*p)
{
u64 x = (__force u64) ct;
unsigned int frac;
@@ -168,7 +168,7 @@ static inline void cputime_to_timespec(const cputime_t ct,
struct timespec *p)
p->tv_nsec = x;
}
-static inline cputime_t timespec_to_cputime(const struct timespec *p)
+static inline cputime_t timespec64_to_cputime(const struct timespec64 *p)
{
u64 ct;
diff --git a/arch/s390/include/asm/cputime.h b/arch/s390/include/asm/cputime.h
index b91e960..1266697 100644
--- a/arch/s390/include/asm/cputime.h
+++ b/arch/s390/include/asm/cputime.h
@@ -89,16 +89,16 @@ static inline cputime_t secs_to_cputime(const unsigned int
s)
}
/*
- * Convert cputime to timespec and back.
+ * Convert cputime to timespec64 and back.
*/
-static inline cputime_t timespec_to_cputime(const struct timespec *value)
+static inline cputime_t timespec64_to_cputime(const struct timespec64 *value)
{
unsigned long long ret = value->tv_sec * CPUTIME_PER_SEC;
return (__force cputime_t)(ret + __div(value->tv_nsec *
CPUTIME_PER_USEC, NSEC_PER_USEC));
}
-static inline void cputime_to_timespec(const cputime_t cputime,
- struct timespec *value)
+static inline void cputime_to_timespec64(const cputime_t cputime,
+ struct timespec64 *value)
{
unsigned long long __cputime = (__force unsigned long long) cputime;
#ifndef CONFIG_64BIT
diff --git a/include/asm-generic/cputime_jiffies.h
b/include/asm-generic/cputime_jiffies.h
index fe386fc..54e034c 100644
--- a/include/asm-generic/cputime_jiffies.h
+++ b/include/asm-generic/cputime_jiffies.h
@@ -44,12 +44,12 @@ typedef u64 __nocast cputime64_t;
#define secs_to_cputime(sec) jiffies_to_cputime((sec) * HZ)
/*
- * Convert cputime to timespec and back.
+ * Convert cputime to timespec64 and back.
*/
-#define timespec_to_cputime(__val) \
- jiffies_to_cputime(timespec_to_jiffies(__val))
-#define cputime_to_timespec(__ct,__val)\
- jiffies_to_timespec(cputime_to_jiffies(__ct),__val)
+#define timespec64_to_cputime(__val) \
+ jiffies_to_cputime(timespec64_to_jiffies(__val))
+#define cputime_to_timespec64(__ct,__val) \
+ jiffies_to_timespec64(cputime_to_jiffies(__ct),__val)
/*
* Convert cputime to timeval and back.
diff --git a/include/asm-generic/cputime_nsecs.h
b/include/asm-generic/cputime_nsecs.h
index 0419485..65c875b 100644
--- a/include/asm-generic/cputime_nsecs.h
+++ b/include/asm-generic/cputime_nsecs.h
@@ -73,12 +73,12 @@ typedef u64 __nocast cputime64_t;
/*
* Convert cputime <-> timespec (nsec)
*/
-static inline cputime_t timespec_to_cputime(const struct timespec *val)
+static inline cputime_t timespec64_to_cputime(const struct timespec64 *val)
{
u64 ret = val->tv_sec * NSEC_PER_SEC + val->tv_nsec;
return (__force cputime_t) ret;
}
-static inline void cputime_to_timespec(const cputime_t ct, struct timespec
*val)
+static inline void cputime_to_timespec64(const cputime_t ct, struct timespec64
*val)
{
u32 rem;
diff --git a/include/linux/cputime.h b/include/linux/cputime.h
index f2eb2ee..f01896f 100644
--- a/include/linux/cputime.h
+++ b/include/linux/cputime.h
@@ -13,4 +13,19 @@
usecs_to_cputime((__nsecs) / NSEC_PER_USEC)
#endif
+static inline cputime_t timespec_to_cputime(const struct timespec *ts)
+{
+ struct timespec64 ts64 = timespec_to_timespec64(*ts);
+ return timespec64_to_cputime(&ts64);
+}
+
+static inline void cputime_to_timespec(const cputime_t cputime,
+ struct timespec *value)
+{
+ struct timespec64 *ts64;
+
+ *
Re: [Linaro-acpi] [PATCH 2/2] ACPI / scan: Parse _CCA and setup device coherency
On Wednesday 29 April 2015 16:53:10 Suravee Suthikulpanit wrote:
> On 4/29/15 11:25, Arnd Bergmann wrote:
> > On Wednesday 29 April 2015 08:44:09 Suravee Suthikulpanit wrote:
> >> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> >> index 4bf7559..a4db208 100644
> >> --- a/drivers/acpi/acpi_platform.c
> >> +++ b/drivers/acpi/acpi_platform.c
> >> @@ -108,9 +108,12 @@ struct platform_device
> >> *acpi_create_platform_device(struct acpi_device *adev)
> >> if (IS_ERR(pdev))
> >> dev_err(&adev->dev, "platform device creation failed:
> >> %ld\n",
> >> PTR_ERR(pdev));
> >> - else
> >> + else {
> >> + arch_setup_dma_ops(&pdev->dev, 0, 0, NULL,
> >> + adev->flags.is_coherent);
> >> dev_dbg(&adev->dev, "created platform device %s\n",
> >> dev_name(&pdev->dev));
> >> + }
> >>
> >> kfree(resources);
> >>
> >
> > Looking at this code in more detail, it seems that it unconditionally
> > sets pdevinfo.dma_mask = DMA_BIT_MASK(32), before calling
> > arch_setup_dma_ops().
>
> I think that's just the default legacy value assigned when it first
> create the platform_device from acpi_device.
Understood. And on x86 there is no way to find out if a device supports
DMA or not, so it has to do this I guess.
> > This assignment should really done inside of arch_setup_dma_ops()
> > instead, which means we should implement that
> > function on all architectures that support ACPI.
>
>
> > For the case where _CCA is missing (or coherency disabled, if you ask
> > me), we would not call that function.
>
> Actually, I agree for the case of missing _CCA when needed, ACPI driver
> probably should not make assumption and leave the decision for the
> default underlying arch-specific default. Basically, it should not be
> calling arch_setup_dma_ops().
Ok.
> As for the case where _CCA=0, I think the ACPI driver should essentially
> communicate the information as HW is non-coherent as described in the
> spec, and should be calling arch_setup_dma_ops(dev, false). It is true
> that this in probably less-likely for the ARM64 server platforms.
> However, I would think that the ACPI driver should not be making such
> assumption.
Can you add a description to the ACPI spec then to describe in detail what
"non-coherent" is supposed to mean, and which action the OS is supposed to
take when accessing data from device or CPU?
As I explained, the way we handle it by default on ARM64 is what embedded
systems typically do, but that might be completely different on the imagined
server chips that are not coherent for some reason. Just saying a device
is not coherent is like saying the CPU has known bugs but not saying how
to prevent it from crashing.
Is there some AML method that the OS can call to synchronize the cache
controller for all DMA to/from a particular device?
> > On a related note, I'm not sure how to handle different DMA masks here.
> > arch_setup_dma_ops() gets passed a size (and offset) argument, which should
> > match the DMA mask, but I don't know if there is a way to find out the
> > size from ACPI. Should we assume it's always 64-bit DMA capable?
>
> Looking at the ACPI spec, it does have the _DMA object. IIUC, this can
> be used to describe DMA properties of a particular bus.
>
> Method(_DMA, ResourceTemplate()
> {
> QWORDMemory(
> ResourceConsumer,
> PosDecode, // _DEC
> MinFixed, // _MIF
> MaxFixed, // _MAF
> Prefetchable, // _MEM
> ReadWrite, // _RW
> 0, // _GRA
> 0, // _MIN
> 0x1fff, // _MAX
> 0x2, // _TRA
> 0x2000, // _LEN
> , , ,
> )
> }
>
> I am not sure if this is an appropriate use for this object, but this
> seems to be similar to the dma-ranges property for OF, and probably can
> be used to specify baseaddr and size information when calling
> arch_setup_dma_ops().
Yes, that seems like a good idea. What is the expected behavior when that
object is absent? Do we assume that the parent device is not DMA capable?
Is this sufficient to describe the case where a device can only do DMA
to a specific address range that is not at bus address zero but that maps
to the beginning of physical RAM?
> > For legacy reasons, the default mask is probably best left at 32-bit,
> > but drivers are expected to call dma_set_mask() if they can do 64-bit DMA,
> > and that should fail based on the information provided by the platform
> > if the bus is not capable of doing that.
> >
>
> However, on ARM64 the dma_base and size parameter for
> arch_setup_dma_ops() is currently not used, and only coherent flag is
> used.
We can hope that we won't need the dma_base setting here, but it's
good to have the option to pass it down if we need it.
Not passing the size is a bug that needs to be fixed ASAP, I believe
a number of folks have
[PATCH v2 14/15] time/posix-cpu-timers:Convert to the 64bit methods for k_clock structure
This patch changes to the new methods of k_clock structure with timespec64
type, converts the timespec/itimerspec type to timespec64/itimerspec64 type
for the callback function in posix-cpu-timers.c file.
Signed-off-by: Baolin Wang
---
kernel/time/posix-cpu-timers.c | 83 +---
1 file changed, 44 insertions(+), 39 deletions(-)
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 0075da7..a4651cd 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -52,7 +52,7 @@ static int check_clock(const clockid_t which_clock)
}
static inline unsigned long long
-timespec_to_sample(const clockid_t which_clock, const struct timespec *tp)
+timespec64_to_sample(const clockid_t which_clock, const struct timespec64 *tp)
{
unsigned long long ret;
@@ -60,19 +60,19 @@ timespec_to_sample(const clockid_t which_clock, const
struct timespec *tp)
if (CPUCLOCK_WHICH(which_clock) == CPUCLOCK_SCHED) {
ret = (unsigned long long)tp->tv_sec * NSEC_PER_SEC +
tp->tv_nsec;
} else {
- ret = cputime_to_expires(timespec_to_cputime(tp));
+ ret = cputime_to_expires(timespec64_to_cputime(tp));
}
return ret;
}
-static void sample_to_timespec(const clockid_t which_clock,
+static void sample_to_timespec64(const clockid_t which_clock,
unsigned long long expires,
- struct timespec *tp)
+ struct timespec64 *tp)
{
if (CPUCLOCK_WHICH(which_clock) == CPUCLOCK_SCHED)
- *tp = ns_to_timespec(expires);
+ *tp = ns_to_timespec64(expires);
else
- cputime_to_timespec((__force cputime_t)expires, tp);
+ cputime_to_timespec64((__force cputime_t)expires, tp);
}
/*
@@ -141,7 +141,7 @@ static inline unsigned long long virt_ticks(struct
task_struct *p)
}
static int
-posix_cpu_clock_getres(const clockid_t which_clock, struct timespec *tp)
+posix_cpu_clock_getres(const clockid_t which_clock, struct timespec64 *tp)
{
int error = check_clock(which_clock);
if (!error) {
@@ -160,7 +160,7 @@ posix_cpu_clock_getres(const clockid_t which_clock, struct
timespec *tp)
}
static int
-posix_cpu_clock_set(const clockid_t which_clock, const struct timespec *tp)
+posix_cpu_clock_set(const clockid_t which_clock, const struct timespec64 *tp)
{
/*
* You can never reset a CPU clock, but we check for other errors
@@ -263,7 +263,7 @@ static int cpu_clock_sample_group(const clockid_t
which_clock,
static int posix_cpu_clock_get_task(struct task_struct *tsk,
const clockid_t which_clock,
- struct timespec *tp)
+ struct timespec64 *tp)
{
int err = -EINVAL;
unsigned long long rtn;
@@ -277,13 +277,14 @@ static int posix_cpu_clock_get_task(struct task_struct
*tsk,
}
if (!err)
- sample_to_timespec(which_clock, rtn, tp);
+ sample_to_timespec64(which_clock, rtn, tp);
return err;
}
-static int posix_cpu_clock_get(const clockid_t which_clock, struct timespec
*tp)
+static int posix_cpu_clock_get(const clockid_t which_clock,
+ struct timespec64 *tp)
{
const pid_t pid = CPUCLOCK_PID(which_clock);
int err = -EINVAL;
@@ -598,7 +599,7 @@ static inline void posix_cpu_timer_kick_nohz(void) { }
* and try again. (This happens when the timer is in the middle of firing.)
*/
static int posix_cpu_timer_set(struct k_itimer *timer, int timer_flags,
- struct itimerspec *new, struct itimerspec *old)
+ struct itimerspec64 *new, struct itimerspec64
*old)
{
unsigned long flags;
struct sighand_struct *sighand;
@@ -608,7 +609,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int
timer_flags,
WARN_ON_ONCE(p == NULL);
- new_expires = timespec_to_sample(timer->it_clock, &new->it_value);
+ new_expires = timespec64_to_sample(timer->it_clock, &new->it_value);
/*
* Protect against sighand release/switch in exit/exec and p->cpu_timers
@@ -669,7 +670,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int
timer_flags,
bump_cpu_timer(timer, val);
if (val < timer->it.cpu.expires) {
old_expires = timer->it.cpu.expires - val;
- sample_to_timespec(timer->it_clock,
+ sample_to_timespec64(timer->it_clock,
old_expires,
&old->it_value);
} else {
@@ -709,7 +710,7 @@ static int posix_cpu_timer_set(struct k_itimer *t
[PATCH v2 15/15] k_clock:Remove the 32bit methods with timespec/itimerspec type
All of the k_clock users have been converted to the new methods. This patch
removes the older methods with timepsec/itimerspec type. As a result, the
k_clock
structure is ready for the year 2038.
Signed-off-by: Baolin Wang
---
include/linux/posix-timers.h |9 -
kernel/time/posix-timers.c | 74 +++---
2 files changed, 5 insertions(+), 78 deletions(-)
diff --git a/include/linux/posix-timers.h b/include/linux/posix-timers.h
index 35786c5..7c3dae2 100644
--- a/include/linux/posix-timers.h
+++ b/include/linux/posix-timers.h
@@ -97,29 +97,20 @@ struct k_itimer {
};
struct k_clock {
- int (*clock_getres) (const clockid_t which_clock, struct timespec *tp);
int (*clock_getres64) (const clockid_t which_clock, struct timespec64
*tp);
- int (*clock_set) (const clockid_t which_clock,
- const struct timespec *tp);
int (*clock_set64) (const clockid_t which_clock,
const struct timespec64 *tp);
- int (*clock_get) (const clockid_t which_clock, struct timespec * tp);
int (*clock_get64) (const clockid_t which_clock, struct timespec64 *tp);
int (*clock_adj) (const clockid_t which_clock, struct timex *tx);
int (*timer_create) (struct k_itimer *timer);
int (*nsleep) (const clockid_t which_clock, int flags,
struct timespec *, struct timespec __user *);
long (*nsleep_restart) (struct restart_block *restart_block);
- int (*timer_set) (struct k_itimer * timr, int flags,
- struct itimerspec * new_setting,
- struct itimerspec * old_setting);
int (*timer_set64) (struct k_itimer *timr, int flags,
struct itimerspec64 *new_setting,
struct itimerspec64 *old_setting);
int (*timer_del) (struct k_itimer * timr);
#define TIMER_RETRY 1
- void (*timer_get) (struct k_itimer * timr,
- struct itimerspec * cur_setting);
void (*timer_get64) (struct k_itimer *timr,
struct itimerspec64 *cur_setting);
};
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 8ced634..ba95172 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -140,7 +140,6 @@ static int common_timer_del(struct k_itimer *timer);
static enum hrtimer_restart posix_timer_fn(struct hrtimer *data);
static struct k_itimer *__lock_timer(timer_t timer_id, unsigned long *flags);
-static struct k_clock *clockid_to_kclock(const clockid_t id);
#define lock_timer(tid, flags)\
({ struct k_itimer *__timr; \
@@ -514,57 +513,6 @@ static struct pid *good_sigevent(sigevent_t * event)
return task_pid(rtn);
}
-static int default_timer_get64(struct k_itimer *timr,
- struct itimerspec64 *cur_setting64)
-{
- struct itimerspec cur_setting;
- struct k_clock *kc = clockid_to_kclock(timr->it_clock);
-
- kc->timer_get(timr, &cur_setting);
- return 0;
-}
-
-static int default_timer_set64(struct k_itimer *timr, int flags,
- struct itimerspec64 *new_setting64,
- struct itimerspec64 *old_setting64)
-{
- struct k_clock *kc = clockid_to_kclock(timr->it_clock);
- struct itimerspec new_setting, old_setting;
-
- kc->timer_set(timr, flags, &new_setting, &old_setting);
- return 0;
-}
-
-static int default_clock_set64(const clockid_t which_clock,
- const struct timespec64 *tp64)
-{
- struct k_clock *kc = clockid_to_kclock(which_clock);
- struct timespec tp;
-
- kc->clock_set(which_clock, &tp);
- return 0;
-}
-
-static int default_clock_get64(const clockid_t which_clock,
- struct timespec64 *tp64)
-{
- struct k_clock *kc = clockid_to_kclock(which_clock);
- struct timespec tp;
-
- kc->clock_get(which_clock, &tp);
- return 0;
-}
-
-static int default_clock_getres64(const clockid_t which_clock,
- struct timespec64 *tp64)
-{
- struct k_clock *kc = clockid_to_kclock(which_clock);
- struct timespec tp;
-
- kc->clock_getres(which_clock, &tp);
- return 0;
-}
-
void posix_timers_register_clock(const clockid_t clock_id,
struct k_clock *new_clock)
{
@@ -574,28 +522,17 @@ void posix_timers_register_clock(const clockid_t clock_id,
return;
}
- if (!new_clock->clock_get && !new_clock->clock_get64) {
- printk(KERN_WARNING "POSIX clock id %d lacks clock_get() and
clock_get64()\n",
+ if (!new_clock->clock_get64) {
+ printk(KERN_WARNING "POSIX clock id %d lacks clock_get64()\n",
clock_id
Re: [PATCH v3 3/3] proc: add kpageidle file
On Wed, Apr 29, 2015 at 12:12:48PM +0300, Vladimir Davydov wrote:
> On Wed, Apr 29, 2015 at 01:35:36PM +0900, Minchan Kim wrote:
> > On Tue, Apr 28, 2015 at 03:24:42PM +0300, Vladimir Davydov wrote:
> > > diff --git a/fs/proc/page.c b/fs/proc/page.c
> > > index 70d23245dd43..cfc55ba7fee6 100644
> > > --- a/fs/proc/page.c
> > > +++ b/fs/proc/page.c
> > > @@ -275,6 +275,156 @@ static const struct file_operations
> > > proc_kpagecgroup_operations = {
> > > };
> > > #endif /* CONFIG_MEMCG */
> > >
> > > +#ifdef CONFIG_IDLE_PAGE_TRACKING
> > > +static struct page *kpageidle_get_page(unsigned long pfn)
> > > +{
> > > + struct page *page;
> > > +
> > > + if (!pfn_valid(pfn))
> > > + return NULL;
> > > + page = pfn_to_page(pfn);
> > > + /*
> > > + * We are only interested in user memory pages, i.e. pages that are
> > > + * allocated and on an LRU list.
> > > + */
> > > + if (!page || page_count(page) == 0 || !PageLRU(page))
> >
> > Why do you check (page_count == 0) even if we check it with
> > get_page_unless_zero
> > below?
>
> I intended to avoid overhead of cmpxchg in case page_count is 0, but
> diving deeper into get_page_unless_zero, I see that it already handles
> such a scenario, so this check is useless. I'll remove it.
>
> >
> > > + return NULL;
> > > + if (!get_page_unless_zero(page))
> > > + return NULL;
> > > + if (unlikely(!PageLRU(page))) {
> >
> > What lock protect the check PageLRU?
> > If it is racing ClearPageLRU, what happens?
>
> If we hold a reference to a page and see that it's on an LRU list, it
> will surely remain a user memory page at least until we release the
> reference to it, so it must be safe to play with idle/young flags. If we
The problem is that you pass the page in rmap reverse logic(ie, page_referenced)
once you judge it's LRU page so if it is false-positive, what happens?
A question is SetPageLRU, PageLRU, ClearPageLRU keeps memory ordering?
IOW, all of fields from struct page rmap can acccess should be set up completely
before LRU checking. Otherwise, something will be broken.
Thanks.
> race with isolate_lru_page, or any similar function temporarily clearing
> PG_lru, we will silently skip the page w/o touching its idle/young
> flags. We could consider isolated pages too, but that would increase the
> cost of this function.
>
> If you find this explanation OK, I'll add it to the comment to this
> function.
>
> >
> > > + put_page(page);
> > > + return NULL;
> > > + }
> > > + return page;
> > > +}
> > > +
> > > +static void kpageidle_clear_refs(struct page *page)
> > > +{
> > > + unsigned long dummy;
> > > +
> > > + if (page_referenced(page, 0, NULL, &dummy))
> > > + /*
> > > + * This page was referenced. To avoid interference with the
> > > + * reclaimer, mark it young so that the next call will also
> >
> > next what call?
> >
> > It just works with mapped page so kpageidle_clear_pte_refs as function name
> > is more clear.
> >
> > One more, kpageidle_clear_refs removes PG_idle via page_referenced which
> > is important feature for the function. Please document it so we could
> > understand why we need double check for PG_idle after calling
> > kpageidle_clear_refs for pte access bit.
>
> Sounds reasonable, will do.
>
> > > diff --git a/mm/rmap.c b/mm/rmap.c
> > > index 24dd3f9fee27..12e73b758d9e 100644
> > > --- a/mm/rmap.c
> > > +++ b/mm/rmap.c
> > > @@ -784,6 +784,13 @@ static int page_referenced_one(struct page *page,
> > > struct vm_area_struct *vma,
> > > if (referenced) {
> > > pra->referenced++;
> > > pra->vm_flags |= vma->vm_flags;
> > > + if (page_is_idle(page))
> > > + clear_page_idle(page);
> > > + }
> > > +
> > > + if (page_is_young(page)) {
> > > + clear_page_young(page);
> > > + pra->referenced++;
> >
> > If a page was page_is_young and referenced recenlty,
> > pra->referenced is increased doubly and it changes current
> > behavior for file-backed page promotion. Look at page_check_references.
>
> Yeah, you're quite right, I missed that. Something like this should get
> rid of this extra reference:
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 24dd3f9fee27..eca7416f55d7 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -781,6 +781,14 @@ static int page_referenced_one(struct page *page, struct
> vm_area_struct *vma,
> pte_unmap_unlock(pte, ptl);
> }
>
> + if (referenced && page_is_idle(page))
> + clear_page_idle(page);
> +
> + if (page_is_young(page)) {
> + clear_page_young(page);
> + referenced++;
> + }
> +
> if (referenced) {
> pra->referenced++;
> pra->vm_flags |= vma->vm_flags;
>
> Thanks,
> Vladimir
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http
[RFC PATCH 2/3] powerpc/thp: Remove _PAGE_SPLITTING and related code
With the new thp refcounting we don't need to mark the PMD splitting.
Drop the code to handle this.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s_64.h | 6 -
arch/powerpc/include/asm/pgtable-ppc64.h | 27 ---
arch/powerpc/mm/hugepage-hash64.c| 3 ---
arch/powerpc/mm/hugetlbpage.c| 2 +-
arch/powerpc/mm/pgtable_64.c | 38 +---
mm/gup.c | 2 +-
6 files changed, 12 insertions(+), 66 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h
b/arch/powerpc/include/asm/kvm_book3s_64.h
index 2d81e202bdcc..9a96fe3caa48 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -298,12 +298,6 @@ static inline pte_t kvmppc_read_update_linux_pte(pte_t
*ptep, int writing,
cpu_relax();
continue;
}
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- /* If hugepage and is trans splitting return None */
- if (unlikely(hugepage &&
-pmd_trans_splitting(pte_pmd(old_pte
- return __pte(0);
-#endif
/* If pte is not present return None */
if (unlikely(!(old_pte & _PAGE_PRESENT)))
return __pte(0);
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index 843cb35e6add..ff275443a040 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -361,11 +361,6 @@ void pgtable_cache_init(void);
#endif /* __ASSEMBLY__ */
/*
- * THP pages can't be special. So use the _PAGE_SPECIAL
- */
-#define _PAGE_SPLITTING _PAGE_SPECIAL
-
-/*
* We need to differentiate between explicit huge page and THP huge
* page, since THP huge page also need to track real subpage details
*/
@@ -375,8 +370,7 @@ void pgtable_cache_init(void);
* set of bits not changed in pmd_modify.
*/
#define _HPAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | \
-_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_SPLITTING | \
-_PAGE_THP_HUGE)
+_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_THP_HUGE)
#ifndef __ASSEMBLY__
/*
@@ -458,13 +452,6 @@ static inline int pmd_trans_huge(pmd_t pmd)
return (pmd_val(pmd) & 0x3) && (pmd_val(pmd) & _PAGE_THP_HUGE);
}
-static inline int pmd_trans_splitting(pmd_t pmd)
-{
- if (pmd_trans_huge(pmd))
- return pmd_val(pmd) & _PAGE_SPLITTING;
- return 0;
-}
-
extern int has_transparent_hugepage(void);
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
@@ -517,12 +504,6 @@ static inline pmd_t pmd_mknotpresent(pmd_t pmd)
return pmd;
}
-static inline pmd_t pmd_mksplitting(pmd_t pmd)
-{
- pmd_val(pmd) |= _PAGE_SPLITTING;
- return pmd;
-}
-
#define __HAVE_ARCH_PMD_SAME
static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
{
@@ -577,9 +558,9 @@ static inline void pmdp_set_wrprotect(struct mm_struct *mm,
unsigned long addr,
pmd_hugepage_update(mm, addr, pmdp, _PAGE_RW, 0);
}
-#define __HAVE_ARCH_PMDP_SPLITTING_FLUSH
-extern void pmdp_splitting_flush(struct vm_area_struct *vma,
-unsigned long address, pmd_t *pmdp);
+#define __HAVE_ARCH_PMDP_SPLITTING_FLUSH_NOTIFY
+extern void pmdp_splitting_flush_notify(struct vm_area_struct *vma,
+ unsigned long address, pmd_t *pmdp);
#define __HAVE_ARCH_PGTABLE_DEPOSIT
extern void pgtable_trans_huge_deposit(struct mm_struct *mm, pmd_t *pmdp,
diff --git a/arch/powerpc/mm/hugepage-hash64.c
b/arch/powerpc/mm/hugepage-hash64.c
index 86686514ae13..078f7207afd2 100644
--- a/arch/powerpc/mm/hugepage-hash64.c
+++ b/arch/powerpc/mm/hugepage-hash64.c
@@ -39,9 +39,6 @@ int __hash_page_thp(unsigned long ea, unsigned long access,
unsigned long vsid,
/* If PMD busy, retry the access */
if (unlikely(old_pmd & _PAGE_BUSY))
return 0;
- /* If PMD is trans splitting retry the access */
- if (unlikely(old_pmd & _PAGE_SPLITTING))
- return 0;
/* If PMD permissions don't match, take page fault */
if (unlikely(access & ~old_pmd))
return 1;
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index f30ae0f7f570..dfd7db0cfbee 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -1008,7 +1008,7 @@ pte_t *find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned
long ea, unsigned *shift
* hpte invalidate
*
*/
- if (pmd_none(pmd) || pmd_trans_splitting(pmd))
+ if (pmd_none(pmd))
return NULL;
Re: [PATCH kernel v9 28/32] powerpc/mmu: Add userspace-to-physical addresses translation cache
On Thu, Apr 30, 2015 at 04:34:55PM +1000, David Gibson wrote:
> On Sat, Apr 25, 2015 at 10:14:52PM +1000, Alexey Kardashevskiy wrote:
> > We are adding support for DMA memory pre-registration to be used in
> > conjunction with VFIO. The idea is that the userspace which is going to
> > run a guest may want to pre-register a user space memory region so
> > it all gets pinned once and never goes away. Having this done,
> > a hypervisor will not have to pin/unpin pages on every DMA map/unmap
> > request. This is going to help with multiple pinning of the same memory
> > and in-kernel acceleration of DMA requests.
> >
> > This adds a list of memory regions to mm_context_t. Each region consists
> > of a header and a list of physical addresses. This adds API to:
> > 1. register/unregister memory regions;
> > 2. do final cleanup (which puts all pre-registered pages);
> > 3. do userspace to physical address translation;
> > 4. manage a mapped pages counter; when it is zero, it is safe to
> > unregister the region.
> >
> > Multiple registration of the same region is allowed, kref is used to
> > track the number of registrations.
>
> [snip]
> > +long mm_iommu_alloc(unsigned long ua, unsigned long entries,
> > + struct mm_iommu_table_group_mem_t **pmem)
> > +{
> > + struct mm_iommu_table_group_mem_t *mem;
> > + long i, j;
> > + struct page *page = NULL;
> > +
> > + list_for_each_entry_rcu(mem, ¤t->mm->context.iommu_group_mem_list,
> > + next) {
> > + if ((mem->ua == ua) && (mem->entries == entries))
> > + return -EBUSY;
> > +
> > + /* Overlap? */
> > + if ((mem->ua < (ua + (entries << PAGE_SHIFT))) &&
> > + (ua < (mem->ua + (mem->entries << PAGE_SHIFT
> > + return -EINVAL;
> > + }
> > +
> > + mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> > + if (!mem)
> > + return -ENOMEM;
> > +
> > + mem->hpas = vzalloc(entries * sizeof(mem->hpas[0]));
> > + if (!mem->hpas) {
> > + kfree(mem);
> > + return -ENOMEM;
> > + }
>
> So, I've thought more about this and I'm really confused as to what
> this is supposed to be accomplishing.
>
> I see that you need to keep track of what regions are registered, so
> you don't double lock or unlock, but I don't see what the point of
> actualy storing the translations in hpas is.
>
> I had assumed it was so that you could later on get to the
> translations in real mode when you do in-kernel acceleration. But
> that doesn't make sense, because the array is vmalloc()ed, so can't be
> accessed in real mode anyway.
We can access vmalloc'd arrays in real mode using real_vmalloc_addr().
> I can't think of a circumstance in which you can use hpas where you
> couldn't just walk the page tables anyway.
The problem with walking the page tables is that there is no guarantee
that the page you find that way is the page that was returned by the
gup_fast() we did earlier. Storing the hpas means that we know for
sure that the page we're doing DMA to is one that we have an elevated
page count on.
Also, there are various points where a Linux PTE is made temporarily
invalid for a short time. If we happened to do a H_PUT_TCE on one cpu
while another cpu was doing that, we'd get a spurious failure returned
by the H_PUT_TCE.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] PCI: designware: use iATU0 for cfg and IO, iATU1 for MEM
Most transactions' type are cfg0 and MEM, so the Current iATU usage is not
balanced, iATU0 is hot while iATU1 is rarely used. This patch refactors
the iATU usage: iATU0 for cfg and IO, iATU1 for MEM. This allocation
ideas comes from Minghuan Lian :
http://www.spinics.net/lists/linux-pci/msg40440.html
Signed-off-by: Jisheng Zhang
---
drivers/pci/host/pcie-designware.c | 81 +-
1 file changed, 45 insertions(+), 36 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 1da1446..40a0db1 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -508,6 +508,11 @@ int dw_pcie_host_init(struct pcie_port *pp)
if (pp->ops->host_init)
pp->ops->host_init(pp);
+ if (!pp->ops->rd_other_conf)
+ dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
+ PCIE_ATU_TYPE_MEM, pp->mem_mod_base,
+ pp->mem_bus_addr, pp->mem_size);
+
dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0);
/* program correct class for RC */
@@ -533,66 +538,70 @@ int dw_pcie_host_init(struct pcie_port *pp)
static int dw_pcie_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
u32 devfn, int where, int size, u32 *val)
{
- int ret = PCIBIOS_SUCCESSFUL;
- u32 address, busdev;
+ int ret, type;
+ u32 address, busdev, cfg_size;
+ u64 cpu_addr;
+ void __iomem *va_cfg_base;
busdev = PCIE_ATU_BUS(bus->number) | PCIE_ATU_DEV(PCI_SLOT(devfn)) |
PCIE_ATU_FUNC(PCI_FUNC(devfn));
address = where & ~0x3;
if (bus->parent->number == pp->root_bus_nr) {
- dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
- PCIE_ATU_TYPE_CFG0, pp->cfg0_mod_base,
- busdev, pp->cfg0_size);
- ret = dw_pcie_cfg_read(pp->va_cfg0_base + address, where, size,
- val);
- dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
- PCIE_ATU_TYPE_MEM, pp->mem_mod_base,
- pp->mem_bus_addr, pp->mem_size);
+ type = PCIE_ATU_TYPE_CFG0;
+ cpu_addr = pp->cfg0_mod_base;
+ cfg_size = pp->cfg0_size;
+ va_cfg_base = pp->va_cfg0_base;
} else {
- dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
- PCIE_ATU_TYPE_CFG1, pp->cfg1_mod_base,
- busdev, pp->cfg1_size);
- ret = dw_pcie_cfg_read(pp->va_cfg1_base + address, where, size,
- val);
- dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
- PCIE_ATU_TYPE_IO, pp->io_mod_base,
- pp->io_bus_addr, pp->io_size);
+ type = PCIE_ATU_TYPE_CFG1;
+ cpu_addr = pp->cfg1_mod_base;
+ cfg_size = pp->cfg1_size;
+ va_cfg_base = pp->va_cfg1_base;
}
+ dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
+ type, cpu_addr,
+ busdev, cfg_size);
+ ret = dw_pcie_cfg_read(va_cfg_base + address, where, size, val);
+ dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
+ PCIE_ATU_TYPE_IO, pp->io_mod_base,
+ pp->io_bus_addr, pp->io_size);
+
return ret;
}
static int dw_pcie_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
u32 devfn, int where, int size, u32 val)
{
- int ret = PCIBIOS_SUCCESSFUL;
- u32 address, busdev;
+ int ret, type;
+ u32 address, busdev, cfg_size;
+ u64 cpu_addr;
+ void __iomem *va_cfg_base;
busdev = PCIE_ATU_BUS(bus->number) | PCIE_ATU_DEV(PCI_SLOT(devfn)) |
PCIE_ATU_FUNC(PCI_FUNC(devfn));
address = where & ~0x3;
if (bus->parent->number == pp->root_bus_nr) {
- dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
- PCIE_ATU_TYPE_CFG0, pp->cfg0_mod_base,
- busdev, pp->cfg0_size);
- ret = dw_pcie_cfg_write(pp->va_cfg0_base + address, where, size,
- val);
- dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
- PCIE_ATU_TYPE_MEM, pp->mem_mod_base,
- pp->mem_bus_addr, pp->mem_size);
+ type = PCIE_ATU_TYPE_CFG0;
+ cpu_addr = pp->cfg0_mod_base;
+ cfg_size = pp->cfg0_size;
+ va_cfg_bas
[RFC PATCH 3/3] mm/thp: Add new function to clear pmd on collapse
Some arch may need an explicit IPI when clearing pmd
on collapse. Add new function which arch can override.
After this pmdp_clear_flush is used only for THP case
to invalidate a huge page pte.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/pgtable-ppc64.h | 4 ++
arch/powerpc/mm/pgtable_64.c | 77
include/asm-generic/pgtable.h| 9
mm/huge_memory.c | 2 +-
4 files changed, 53 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index ff275443a040..655dde8e9683 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -562,6 +562,10 @@ static inline void pmdp_set_wrprotect(struct mm_struct
*mm, unsigned long addr,
extern void pmdp_splitting_flush_notify(struct vm_area_struct *vma,
unsigned long address, pmd_t *pmdp);
+#define __HAVE_ARCH_PMDP_COLLAPSE_FLUSH
+extern pmd_t pmdp_collapse_flush(struct vm_area_struct *vma,
+unsigned long address, pmd_t *pmdp);
+
#define __HAVE_ARCH_PGTABLE_DEPOSIT
extern void pgtable_trans_huge_deposit(struct mm_struct *mm, pmd_t *pmdp,
pgtable_t pgtable);
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 89b356250be3..fa49e2ff042b 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -558,45 +558,9 @@ unsigned long pmd_hugepage_update(struct mm_struct *mm,
unsigned long addr,
pmd_t pmdp_clear_flush(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp)
{
- pmd_t pmd;
-
VM_BUG_ON(address & ~HPAGE_PMD_MASK);
- if (pmd_trans_huge(*pmdp)) {
- pmd = pmdp_get_and_clear(vma->vm_mm, address, pmdp);
- } else {
- /*
-* khugepaged calls this for normal pmd
-*/
- pmd = *pmdp;
- pmd_clear(pmdp);
- /*
-* Wait for all pending hash_page to finish. This is needed
-* in case of subpage collapse. When we collapse normal pages
-* to hugepage, we first clear the pmd, then invalidate all
-* the PTE entries. The assumption here is that any low level
-* page fault will see a none pmd and take the slow path that
-* will wait on mmap_sem. But we could very well be in a
-* hash_page with local ptep pointer value. Such a hash page
-* can result in adding new HPTE entries for normal subpages.
-* That means we could be modifying the page content as we
-* copy them to a huge page. So wait for parallel hash_page
-* to finish before invalidating HPTE entries. We can do this
-* by sending an IPI to all the cpus and executing a dummy
-* function there.
-*/
- kick_all_cpus_sync();
- /*
-* Now invalidate the hpte entries in the range
-* covered by pmd. This make sure we take a
-* fault and will find the pmd as none, which will
-* result in a major fault which takes mmap_sem and
-* hence wait for collapse to complete. Without this
-* the __collapse_huge_page_copy can result in copying
-* the old content.
-*/
- flush_tlb_pmd_range(vma->vm_mm, &pmd, address);
- }
- return pmd;
+ VM_BUG_ON(!pmd_trans_huge(*pmdp));
+ return pmdp_get_and_clear(vma->vm_mm, address, pmdp);
}
int pmdp_test_and_clear_young(struct vm_area_struct *vma,
@@ -641,6 +605,43 @@ void pmdp_splitting_flush_notify(struct vm_area_struct
*vma,
kick_all_cpus_sync();
}
+pmd_t pmdp_collapse_flush(struct vm_area_struct *vma, unsigned long address,
+ pmd_t *pmdp)
+{
+ pmd_t pmd;
+
+ VM_BUG_ON(address & ~HPAGE_PMD_MASK);
+ pmd = *pmdp;
+ pmd_clear(pmdp);
+ /*
+* Wait for all pending hash_page to finish. This is needed
+* in case of subpage collapse. When we collapse normal pages
+* to hugepage, we first clear the pmd, then invalidate all
+* the PTE entries. The assumption here is that any low level
+* page fault will see a none pmd and take the slow path that
+* will wait on mmap_sem. But we could very well be in a
+* hash_page with local ptep pointer value. Such a hash page
+* can result in adding new HPTE entries for normal subpages.
+* That means we could be modifying the page content as we
+* copy them to a huge page. So wait for parallel hash_page
+* to finish before invalidating HPTE entries. We can do this
+* by sending an IPI
[PATCH v2 1/2] PCI: designware: consolidate outbound iATU programming functions
Currently, the outbound iATU programming functions are similar, the only
difference is index, type, addr and size. This patch tries to consolidate
these functions into one. One side effect is it saves around 1700 bytes in
text:
textdata bss dec hex filename
9276 204 49484250c pcie-designware.o-before
7532 204 477401e3c pcie-designware.o
Signed-off-by: Jisheng Zhang
---
drivers/pci/host/pcie-designware.c | 109 +
1 file changed, 39 insertions(+), 70 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 2e9f84f..1da1446 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -150,6 +150,21 @@ static int dw_pcie_wr_own_conf(struct pcie_port *pp, int
where, int size,
return ret;
}
+static void dw_pcie_prog_outbound_atu(struct pcie_port *pp, int index,
+ int type, u64 cpu_addr, u64 pci_addr, u32 size)
+{
+ dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | index,
+ PCIE_ATU_VIEWPORT);
+ dw_pcie_writel_rc(pp, lower_32_bits(cpu_addr), PCIE_ATU_LOWER_BASE);
+ dw_pcie_writel_rc(pp, upper_32_bits(cpu_addr), PCIE_ATU_UPPER_BASE);
+ dw_pcie_writel_rc(pp, lower_32_bits(cpu_addr + size - 1),
+ PCIE_ATU_LIMIT);
+ dw_pcie_writel_rc(pp, lower_32_bits(pci_addr), PCIE_ATU_LOWER_TARGET);
+ dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
+ dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
+ dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
+}
+
static struct irq_chip dw_msi_irq_chip = {
.name = "PCI-MSI",
.irq_enable = pci_msi_unmask_irq,
@@ -515,68 +530,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
return 0;
}
-static void dw_pcie_prog_viewport_cfg0(struct pcie_port *pp, u32 busdev)
-{
- /* Program viewport 0 : OUTBOUND : CFG0 */
- dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0,
- PCIE_ATU_VIEWPORT);
- dw_pcie_writel_rc(pp, pp->cfg0_mod_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp->cfg0_mod_base >> 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp->cfg0_mod_base + pp->cfg0_size - 1,
- PCIE_ATU_LIMIT);
- dw_pcie_writel_rc(pp, busdev, PCIE_ATU_LOWER_TARGET);
- dw_pcie_writel_rc(pp, 0, PCIE_ATU_UPPER_TARGET);
- dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_CFG0, PCIE_ATU_CR1);
- dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
-}
-
-static void dw_pcie_prog_viewport_cfg1(struct pcie_port *pp, u32 busdev)
-{
- /* Program viewport 1 : OUTBOUND : CFG1 */
- dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX1,
- PCIE_ATU_VIEWPORT);
- dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_CFG1, PCIE_ATU_CR1);
- dw_pcie_writel_rc(pp, pp->cfg1_mod_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp->cfg1_mod_base >> 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp->cfg1_mod_base + pp->cfg1_size - 1,
- PCIE_ATU_LIMIT);
- dw_pcie_writel_rc(pp, busdev, PCIE_ATU_LOWER_TARGET);
- dw_pcie_writel_rc(pp, 0, PCIE_ATU_UPPER_TARGET);
- dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
-}
-
-static void dw_pcie_prog_viewport_mem_outbound(struct pcie_port *pp)
-{
- /* Program viewport 0 : OUTBOUND : MEM */
- dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0,
- PCIE_ATU_VIEWPORT);
- dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_MEM, PCIE_ATU_CR1);
- dw_pcie_writel_rc(pp, pp->mem_mod_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp->mem_mod_base >> 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp->mem_mod_base + pp->mem_size - 1,
- PCIE_ATU_LIMIT);
- dw_pcie_writel_rc(pp, pp->mem_bus_addr, PCIE_ATU_LOWER_TARGET);
- dw_pcie_writel_rc(pp, upper_32_bits(pp->mem_bus_addr),
- PCIE_ATU_UPPER_TARGET);
- dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
-}
-
-static void dw_pcie_prog_viewport_io_outbound(struct pcie_port *pp)
-{
- /* Program viewport 1 : OUTBOUND : IO */
- dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX1,
- PCIE_ATU_VIEWPORT);
- dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_IO, PCIE_ATU_CR1);
- dw_pcie_writel_rc(pp, pp->io_mod_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp->io_mod_base >> 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp->io_mod_base + pp->io_size - 1,
- PCIE_ATU_LIMIT);
- dw_pcie_writel_rc(pp, pp->io_bus_addr, PCIE_ATU_LOWER_TARGET);
- dw_pcie_writel_rc(pp, upper_32_bits(pp->io_bus_addr),
- PCIE_ATU_UPPER_TARGET);
- dw_pcie
[PATCH v2 0/2] PCI: designware: improve iATU programming and usage
The outbound iATU programming functions are similar, so PATCH1 consolidates
them into one.
Most transactions' type are cfg0 and MEM, so current iATU usage is not
balanced. PATCH2 adopts idea from Minghuan Lian :
http://www.spinics.net/lists/linux-pci/msg40440.html
to change the iATU allocation: iATU0 for cfg and IO, iATU1 for MEM.
Changes since v1:
- remove outbound iATU programming for IO in dw_pcie_host_init, since it can
be done by berlin_pcie_{rd|wr}_other_conf() latter.
- only do outbound iATU programming for MEM if pp->ops->rd_other_conf is not
set. Thank Fabrice Gasnier to point out "some platforms doesn't have support
for ATU"
Jisheng Zhang (2):
PCI: designware: consolidate outbound iATU programming functions
PCI: designware: use iATU0 for cfg and IO, iATU1 for MEM
drivers/pci/host/pcie-designware.c | 142 -
1 file changed, 60 insertions(+), 82 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/
Re: [PATCH 01/23] gpio: sysfs: fix memory leaks and device hotplug
On Wed, Apr 29, 2015 at 11:44:18PM +0200, Linus Walleij wrote:
> On Tue, Apr 21, 2015 at 5:42 PM, Johan Hovold wrote:
>
> > Unregister GPIOs requested through sysfs at chip remove to avoid leaking
> > the associated memory and sysfs entries.
> >
> > The stale sysfs entries prevented the gpio numbers from being exported
> > when the gpio range was later reused (e.g. at device reconnect).
> >
> > This also fixes the related module-reference leak.
> >
> > Note that kernfs makes sure that any on-going sysfs operations finish
> > before the class devices are unregistered and that further accesses
> > fail.
> >
> > The chip exported flag is used to prevent gpiod exports during removal.
> > This also makes it harder to trigger, but does not fix, the related race
> > between gpiochip_remove and export_store, which is really a race with
> > gpiod_request that needs to be addressed separately.
> >
> > Also note that this would prevent the crashes (e.g. NULL-dereferences)
> > at reconnect that affects pre-3.18 kernels, as well as use-after-free on
> > operations on open attribute files on pre-3.14 kernels (prior to
> > kernfs).
> >
> > Fixes: d8f388d8dc8d ("gpio: sysfs interface")
> > Cc: stable # v2.6.27: 01cca93a9491
> > Signed-off-by: Johan Hovold
>
> Patch applied for fixes.
>
> I worry a bit about what userspaces do out there, but they
> cannot reasonably have behaviours tied to in-flight removal
> of GPIO chips, that would be bizarre.
You shouldn't worry too much; even before this patch userspace would see
an -ENODEV when accessing an open sysfs attribute file of a disconnected
device as kernfs would orphan the file -- only now without the associated
leaks and crashes. ;)
Johan
--
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/
[RFC PATCH 0/3] Remove _PAGE_SPLITTING from ppc64
The changes are on top of what is posted at http://mid.gmane.org/1429823043-157133-1-git-send-email-kirill.shute...@linux.intel.com git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git thp/refcounting/v5 Aneesh Kumar K.V (3): mm/thp: Use pmdp_splitting_flush_notify to clear pmd on splitting powerpc/thp: Remove _PAGE_SPLITTING and related code mm/thp: Add new function to clear pmd on collapse arch/powerpc/include/asm/kvm_book3s_64.h | 6 -- arch/powerpc/include/asm/pgtable-ppc64.h | 29 ++-- arch/powerpc/mm/hugepage-hash64.c| 3 - arch/powerpc/mm/hugetlbpage.c| 2 +- arch/powerpc/mm/pgtable_64.c | 111 --- include/asm-generic/pgtable.h| 14 mm/gup.c | 2 +- mm/huge_memory.c | 9 +-- mm/pgtable-generic.c | 11 +++ 9 files changed, 82 insertions(+), 105 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/
[RFC PATCH 1/3] mm/thp: Use pmdp_splitting_flush_notify to clear pmd on splitting
Some arch may require an explicit IPI before a THP PMD split. This
ensures that a local_irq_disable can prevent a parallel THP PMD split.
So use new function which arch can override
Signed-off-by: Aneesh Kumar K.V
---
include/asm-generic/pgtable.h | 5 +
mm/huge_memory.c | 7 ---
mm/pgtable-generic.c | 11 +++
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index fe617b7e4be6..d091a666f5b1 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -184,6 +184,11 @@ static inline void pmdp_set_wrprotect(struct mm_struct *mm,
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
#endif
+#ifndef __HAVE_ARCH_PMDP_SPLITTING_FLUSH_NOTIFY
+extern void pmdp_splitting_flush_notify(struct vm_area_struct *vma,
+ unsigned long address, pmd_t *pmdp);
+#endif
+
#ifndef __HAVE_ARCH_PGTABLE_DEPOSIT
extern void pgtable_trans_huge_deposit(struct mm_struct *mm, pmd_t *pmdp,
pgtable_t pgtable);
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index cce4604c192f..81e9578bf43a 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2606,9 +2606,10 @@ static void __split_huge_pmd_locked(struct
vm_area_struct *vma, pmd_t *pmd,
write = pmd_write(*pmd);
young = pmd_young(*pmd);
-
- /* leave pmd empty until pte is filled */
- pmdp_clear_flush_notify(vma, haddr, pmd);
+ /*
+* leave pmd empty until pte is filled.
+*/
+ pmdp_splitting_flush_notify(vma, haddr, pmd);
pgtable = pgtable_trans_huge_withdraw(mm, pmd);
pmd_populate(mm, &_pmd, pgtable);
diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
index 2fe699cedd4d..0fc1f5a06979 100644
--- a/mm/pgtable-generic.c
+++ b/mm/pgtable-generic.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
@@ -184,3 +185,13 @@ void pmdp_invalidate(struct vm_area_struct *vma, unsigned
long address,
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
#endif
+
+#ifndef __HAVE_ARCH_PMDP_SPLITTING_FLUSH_NOTIFY
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+void pmdp_splitting_flush_notify(struct vm_area_struct *vma,
+unsigned long address, pmd_t *pmdp)
+{
+ pmdp_clear_flush_notify(vma, address, pmdp);
+}
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+#endif
--
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/
Re: [PATCH v5 0/9] Add sd/emmc support for stih407 family silicon
Hi Ulf, On 04/10/2015 01:06 PM, Ulf Hansson wrote: On 10 April 2015 at 11:40, Peter Griffin wrote: Hi, This series adds sd/emmc support to the sdhci-st.c driver for stih407 family silicon. The changes mainly involve configuring some extra glue registers in the flashSS which configure the Arasan controller. This series also adds support for UHS modes for eMMC. To allow UHS HS200/SD104 modes to function correctly, due to the tight timing constriants, support for delay management is also added. Two types of delay management are supported, static delay management and dynamic delay management, this delay management is only available on eMMC pads on stih410 and later silicon. This series has been tested with stih410-b2120 revd on eMMC and sd, at various clock speeds. As part of this testing a bug was also found in the upstream flexgen clock set_rate implementation (now fixed upstream). max-frequency = 200Mhz /dev/mmcblk0p1: Timing buffered disk reads: 270 MB in 3.02 seconds = 89.54 MB/sec max-frequency = 100Mhz root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 /dev/mmcblk0p1: Timing buffered disk reads: 210 MB in 3.00 seconds = 70.00 MB/sec max-frequency = 50Mhz root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 /dev/mmcblk0p1: Timing buffered disk reads: 118 MB in 3.00 seconds = 39.28 MB/sec It has also been tested on stih416-b2020 to ensure we have caused no regressions. Finally the dt documentation has been updated to reflect the changes in the driver code. Intrestingly it seems we are the first upstream platform to be using some of the uhs bindings such as sd-uhs-sdr104. Changes since v4: - Fixup typo (Pete) Changes since v3: - Rebased on Ulf's mmc next branch (rc5 based) (Ulf) Changes since v2: - Some whitespace fixups (Max) - if (!ioaddr) suggestion (Max) - Add stih418-b2199 suport (Max) - Stih410 to STiH410 fixes (Max) - rebased on v4.0-rc6 (Pete) Changes since v1: - Partition the changes into smaller patches to aid review process (Ulf) Peter Griffin (9): mmc: sdhci-st: Add macros for register offsets and bitfields for mmcss glue regs mmc: sdhci-st: Add support for de-asserting reset signal and top regs resource mmc: sdhci-st: Add delay management functions for top registers (eMMC). mmc: sdhci-st: Add st_mmcss_cconfig function to configure mmcss glue registers. mmc: sdhci-st: Add sdhci_st_set_uhs_signaling function. mmc: sdhci-st: Update the quirks for this controller. mmc: sdhci-st: Update ST SDHCI binding documentation. ARM: STi: DT: STiH407: Add dt nodes for sdhci and emmc. ARM: STi: DT: STiH418: Add dt nodes for sdhci and emmc. Documentation/devicetree/bindings/mmc/sdhci-st.txt | 100 +- arch/arm/boot/dts/stih407-family.dtsi | 30 ++ arch/arm/boot/dts/stih410-b2120.dts| 10 + arch/arm/boot/dts/stih418-b2199.dts| 12 + arch/arm/boot/dts/stihxxx-b2120.dtsi | 8 + drivers/mmc/host/sdhci-st.c| 354 - 6 files changed, 500 insertions(+), 14 deletions(-) -- 1.9.1 Thanks! Applied. Do you confirm you didn't applied the DT patches? Thanks, Maxime Kind regards Uffe -- 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/
[LKP] [genirq] d5b2eacdbc2: BUG: unable to handle kernel NULL pointer dereference at (null)
FYI, we noticed the below changes on
https://github.com/jiangliu/linux.git test/irq_common_data_v2
commit d5b2eacdbc280da7c6dfbe0f52bb293ef227d349 ("genirq: Introduce struct
irq_common_data to host shared irq data")
+-+++
| | 39fb394021 |
d5b2eacdbc |
+-+++
| boot_successes | 0 | 0
|
| boot_failures | 22 | 20
|
| PM:Hibernation_image_not_present_or_could_not_be_loaded | 22 |
|
| BUG:unable_to_handle_kernel | 0 | 20
|
| Oops| 0 | 20
|
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0 | 20
|
| backtrace:__pci_register_driver | 0 | 6
|
| backtrace:e1000_init_module | 0 | 6
|
| backtrace:kernel_init_freeable | 0 | 6
|
| backtrace:ata_sff_pio_task | 0 | 14
|
+-+++
[1.351055] ata2.01: NODEV after polling detection
[1.352179] ata2.00: ATAPI: QEMU DVD-ROM, 2.1.2, max UDMA/100
[1.353501] ata2.00: configured for MWDMA2
[1.354423] BUG: unable to handle kernel NULL pointer dereference at
(null)
[1.356074] IP: [< (null)>] (null)
[1.356074] PGD 0
[1.356074] Oops: 0010 [#1] SMP
[1.356074] Modules linked in:
[1.356074] CPU: 0 PID: 584 Comm: kworker/0:1 Not tainted
4.1.0-rc1-wl-ath-00905-geb3b9ec #1
[1.356074] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
[1.356074] Workqueue: ata_sff ata_sff_pio_task
[1.356074] task: 880011c2af30 ti: 8800123bc000 task.ti:
8800123bc000
[1.356074] RIP: 0010:[<>] [< (null)>]
(null)
[1.356074] RSP: :880013803ee0 EFLAGS: 00010046
[1.356074] RAX: 8222b2c0 RBX: 88001349fc80 RCX: 0009
[1.356074] RDX: 88001348f400 RSI: ffc0 RDI: 88001349fc80
[1.356074] RBP: 880013803ef8 R08: R09: 0013
[1.356074] R10: 0006 R11: R12: 88001348f400
[1.356074] R13: 000f R14: 8800123bfc78 R15:
[1.356074] FS: () GS:88001380()
knlGS:
[1.356074] CS: 0010 DS: ES: CR0: 8005003b
[1.356074] CR2: CR3: 0220b000 CR4: 06f0
[1.356074] Stack:
[1.356074] 8113aa96 88001349fc80 88001348f458
880013803f18
[1.356074] 8106bc49 8222b2c0 88001348f400
880013803f28
[1.356074] 81138421 880013803f48 811380db
000f
[1.356074] Call Trace:
[1.356074]
[1.356074] [] ? irq_move_irq+0x34/0x50
[1.356074] [] apic_ack_edge+0x23/0x3b
[1.356074] [] irq_chip_ack_parent+0x14/0x16
[1.356074] [] handle_edge_irq+0xa5/0x110
[1.356074] [] handle_irq+0x27/0x2d
[1.356074] [] do_IRQ+0x4c/0xcf
[1.356074] [] common_interrupt+0x73/0x73
[1.356074]
[1.356074] [] ? __ata_qc_complete+0xe1/0xe9
[1.356074] [] ? _raw_spin_unlock_irqrestore+0x32/0x42
[1.356074] [] ata_sff_hsm_move+0x258/0x66a
[1.356074] [] ata_sff_pio_task+0x140/0x15e
[1.356074] [] process_one_work+0x1c6/0x37b
[1.356074] [] worker_thread+0x2ad/0x3b6
[1.356074] [] ? rescuer_thread+0x318/0x318
[1.356074] [] kthread+0xf8/0x100
[1.356074] [] ? kthread_create_on_node+0x184/0x184
[1.356074] [] ret_from_fork+0x42/0x70
[1.356074] [] ? kthread_create_on_node+0x184/0x184
[1.356074] Code: Bad RIP value.
[1.356074] RIP [< (null)>] (null)
[1.356074] RSP
[1.356074] CR2:
[1.356074] ---[ end trace d37ae2366ce94eef ]---
[1.356074] Kernel panic - not syncing: Fatal exception in interrupt
Thanks,
lkp
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.0.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENE
Re: [PATCH stable] block: discard bdi_unregister() in favour of bdi_destroy()
On Thu, Apr 30, 2015 at 10:32:33AM +1000, NeilBrown wrote:
>
> bdi_unregister() now contains very little functionality.
>
> It contains a "WARN_ON" if bdi->dev is NULL. This warning is of no
> real consequence as bdi->dev isn't needed by anything else in the function,
> and it triggers if
>blk_cleanup_queue() -> bdi_destroy()
> is called before bdi_unregister, which a subsequent patch will make happen.
> So this isn't wanted.
>
> It also calls bdi_set_min_ratio(). This needs to be called after
> writes through the bdi have all been flushed, and before the bdi is destroyed.
> Calling it early is better than calling it late as it frees up a global
> resource.
>
> Calling it immediately after bdi_wb_shutdown() in bdi_destroy()
> perfectly fits these requirements.
>
> So bdi_unregister can be discarded with the important content moved to
> bdi_destroy, as can the
> writeback_bdi_unregister
> event which is already not used.
>
> This is tagged for 'stable' as it is a pre-requisite for a subsequent
> patch which moves calls to blk_cleanup_queue() before calls to
> del_gendisk(). The commit identified as 'Fixes' removed a lot of
> other functionality from bdi_unregister(), and made a change which
> necessitated moving the blk_cleanup_queue() calls.
>
> Reported-by: Mike Snitzer
> Cc: Christoph Hellwig
> Cc: Peter Zijlstra
> Cc: sta...@vger.kernel.org (v4.0)
> Fixes: c4db59d31e39ea067c32163ac961e9c80198fd37
Fixes: c4db59d31e39 ("fs: don't reassign dirty inodes to
default_backing_dev_info")
> Signed-off-by: NeilBrown
Acked-by: Peter Zijlstra (Intel)
--
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 07/13] mm: meminit: Initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set
On Wed, Apr 29, 2015 at 02:19:01PM -0700, Andrew Morton wrote:
> On Tue, 28 Apr 2015 15:37:04 +0100 Mel Gorman wrote:
>
> > +/*
> > + * Deferred struct page initialisation requires some early init functions
> > that
> > + * are removed before kswapd is up and running. The feature depends on
> > memory
> > + * hotplug so put the data and code required by deferred initialisation
> > into
> > + * the __meminit section where they are preserved.
> > + */
> > +#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
> > +#define __defermem_init __meminit
> > +#define __defer_init__meminit
> > +#else
> > +#define __defermem_init
> > +#define __defer_init __init
> > +#endif
>
> I still don't get it :(
>
This version was sent out at roughly the same minute you asked the time
before so the comment was not updated. I suggested this as a possible
alternative.
/*
* Deferred struct page initialisation requires init functions that are freed
* before kswapd is available. Reuse the memory hotplug section annotation
* to mark the required code.
*
* __defermem_init is code that always exists but is annotated __meminit * to
* avoid section warnings.
* __defer_init code gets marked __meminit when deferring struct page
* initialistion but is otherwise in the init section.
*/
Suggestions on better names are welcome.
> __defermem_init:
>
> if (CONFIG_DEFERRED_STRUCT_PAGE_INIT) {
> if (CONFIG_MEMORY_HOTPLUG)
> retain
> } else {
> retain
> }
>
> but CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on
> CONFIG_MEMORY_HOTPLUG, so this becomes
>
> if (CONFIG_DEFERRED_STRUCT_PAGE_INIT) {
> retain
> } else {
> retain
> }
>
> which becomes
>
> retain
>
> so why does __defermem_init exist?
>
It suppresses section warnings. Another possibility is that I get rid of
it entirely and use __refok but I feared that it might hide a real problem
in the future.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/5] ata: add Broadcom AHCI SATA3 driver for STB chips
On Monday 27 April 2015 14:55:41 Brian Norris wrote:
> On Fri, Apr 24, 2015 at 09:46:01AM +0200, Arnd Bergmann wrote:
> > On Thursday 23 April 2015 09:46:11 Brian Norris wrote:
> > > On Thu, Apr 23, 2015 at 09:43:55AM +0200, Arnd Bergmann wrote:
> > > > On Wednesday 22 April 2015 19:59:08 Brian Norris wrote:
>
> [snip]
> > > So we have a PHY driver, but it doesn't cover everything. Did you want
> > > me to write a second PHY driver?? I'm not sure how that'd work...
> >
> > I think this is all fine, I mainly wanted to make sure that it had been
> > considered and that a decision was made after comparing the options.
> > What I'd really like to see is that you put this summary into the
> > patch description, because any reviewer will wonder about this.
> > You can use a 'Link: https://lkml.org/lkml/2015/3/18/940' tag behind
> > your signed-off-by to reference the earlier discussion, in addition to
> > the summary.
>
> I summarized most of the conclusions in the cover letter, but I suppose
> a plain link to the original thread could do the job too.
Ok. I missed the description in the cover letter, that was my mistake.
Having more information in the part before the "---" line in the
patch description would be good here.
> > If you can configure the endianess of the AHCI core through software,
> > it would be best to always set it to little-endian unconditionally,
> > so you can just use readl() or readl_relaxed() all the time.
>
> We're already doing this in the driver as written, at least for the
> three configurations that have been tested (MIPS LE, MIPS BE, ARM LE).
> IIUC, you're focusing on ARM BE? This is not in any support plan for
> these chips.
I don't care if you want to provide official support for that configuration,
this is just about not writing code that is obviously broken in
configurations that are otherwise valid.
> But to straighten out what you're saying (correct me if I'm wrong), it
> seems like you're saying that on a (theoretical) BCM7xxx ARM in BE mode,
> the chip will come up in LE as normal, all busing will be configured for
> LE mode, and the BE kernel would only later change CPU endianness.
Correct, this is how all ARMv7 SoCs work.
> This would mean that AHCI should be left as it was -- in LE mode -- whereas
> this driver submission would actually configure AHCI to do its own
> internal swapping, effectively making it BE mode again. And that would
> be wrong.
Yes. I wasn't sure how the register for the swapping is defined though,
whether you set it to 'LE' vs 'BE', or to 'swap' vs 'noswap'.
> Now I think this has a few problems:
>
> 1. ARM BE is not (and won't be) supported on these chips. There has been
> no plan and no testing, and I'm sure we'd run into more problems than
> those you're suggesting here.
There are usually three problems that happen when someone first tries
out a BE kernel on a new ARM platform:
a) secondary CPUs need to be switched into big-endian mode when they initially
come out of reset:
diff --git a/arch/arm/mach-bcm/headsmp-brcmstb.S
b/arch/arm/mach-bcm/headsmp-brcmstb.S
index 199c1ea58248..d7fe25502f54 100644
--- a/arch/arm/mach-bcm/headsmp-brcmstb.S
+++ b/arch/arm/mach-bcm/headsmp-brcmstb.S
@@ -26,6 +26,7 @@ ENTRY(brcmstb_secondary_startup)
* Ensure CPU is in a sane state by disabling all IRQs and switching
* into SVC mode.
*/
+ARM_BE8(setend be)
setmodePSR_I_BIT | PSR_F_BIT | SVC_MODE, r0
bl v7_invalidate_l1
b) drivers that use __raw_readl() instead readl_relaxed()
We already have an army of people that hunt down these drivers to convert them
to use readl_relaxed(). In your case, doing that would have the side-effect
of breaking the MIPS parts, so please do everyone and yourself a favor and
write the driver to work correctly from the start, so we don't need to write
that patch.
c) DMA descriptors that have gone wrong: As the endianess of a DMA master
device is fixed, you have to make sure that any data that is read by the
device is stored in device endianess, usually by defining the DMA
descriptors like
struct ahci_cmd_hdr {
__le32 opts;
__le32 status;
__le32 tbl_addr;
__le32 tbl_addr_hi;
__le32 reserved[4];
};
and then using cpu_to_le32 (or cpu_to_be32 for big-endian devices) to store
the descriptor data in memory. Most drivers get this right, and we have
tools available to help you there. Doing a byte swap on the bus does not
work for DMA in general, because that would swap both the descriptors
and the data you want to transfer, which has to remain in address order
as a byte stream.
> 2. To get ARM BE working properly, I'm not confident we'd do (only)
> runtime 'setend' endianness switching. We're more likely to get a
> bus-level endianness switch and be back with a native-endian driver
> again. But then, I'm only speculating (as you are).
W
Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
On Thu, Apr 30, 2015 at 08:05:12AM +, Zheng, Lv wrote: > Are there any such data around the SC and LL (MIPS)? What, you can't search the internet yourself? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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] usb: core: add usb3 lpm sysfs
On Wed, Apr 29, 2015 at 09:57:33PM +0200, Greg KH wrote: > On Thu, Apr 30, 2015 at 12:21:32AM +0800, Zhuang Jin Can wrote: > > On Wed, Apr 29, 2015 at 01:06:22PM +0200, Greg KH wrote: > > > On Wed, Apr 29, 2015 at 06:57:30PM +0800, Zhuang Jin Can wrote: > > > > On Wed, Apr 29, 2015 at 11:01:48AM +0200, Greg KH wrote: > > > > > On Wed, Apr 29, 2015 at 03:20:04PM +0800, Zhuang Jin Can wrote: > > > > > > On Tue, Apr 28, 2015 at 11:11:10PM +0200, Greg KH wrote: > > > > > > > On Wed, Apr 29, 2015 at 12:51:27AM +0800, Zhuang Jin Can wrote: > > > > > > > > Hi Greg KH, > > > > > > > > > > > > > > > > On Tue, Apr 28, 2015 at 12:42:24PM +0200, Greg KH wrote: > > > > > > > > > On Sun, Apr 19, 2015 at 11:46:12AM +0800, Zhuang Jin Can > > > > > > > > > wrote: > > > > > > > > > > Some usb3 devices may not support usb3 lpm well. > > > > > > > > > > The patch adds a sysfs to enable/disable u1 or u2 of the > > > > > > > > > > port.The > > > > > > > > > > settings apply to both before and after device enumeration. > > > > > > > > > > Supported values are "0" - u1 and u2 are disabled, "u1" - > > > > > > > > > > only u1 is > > > > > > > > > > enabled, "u2" - only u2 is enabled, "u1_u2" - u1 and u2 are > > > > > > > > > > enabled. > > > > > > > > > > > > > > > > > > > > The interface is useful for testing some USB3 devices during > > > > > > > > > > development, and provides a way to disable usb3 lpm if the > > > > > > > > > > issues can > > > > > > > > > > not be fixed in final products. > > > > > > > > > > > > > > > > > > How is a user supposed to "know" to make this setting for a > > > > > > > > > device? Why > > > > > > > > > can't the kernel automatically set this value properly? Why > > > > > > > > > does it > > > > > > > > > need to be a kernel issue at all? > > > > > > > > > > > > > > > > > By default kernel enables u1 u2 of all USB3 devices. This > > > > > > > > interface > > > > > > > > provides the user to change this policy. User may set the policy > > > > > > > > according to PID/VID of uevent or according to the platform > > > > > > > > information > > > > > > > > known by userspace. > > > > > > > > > > > > > > And why would they ever want to do that? > > > > > > > > > > > > > > > It's not a kernel issue, as u1 u2 is mandatory by USB3 > > > > > > > > compliance. But > > > > > > > > for some internal hardwired USB3 connection, e.g. SSIC, passing > > > > > > > > USB3 > > > > > > > > compliance is not mandatory. So the interface provides a way > > > > > > > > for vendor > > > > > > > > to ship with u1 or u2 broken products. Of course, this is not > > > > > > > > encouraged :). > > > > > > > > > > > > > > If the state is broken for those devices, we can't require the > > > > > > > user to > > > > > > > fix it for us, the kernel should do it automatically. > > > > > > > > > > > > > > > > And when you are doing development of broken devices, the > > > > > > > > > kernel doesn't > > > > > > > > > have to support you, you can run with debugging patches of > > > > > > > > > your own > > > > > > > > > until you fix your firmware :) > > > > > > > > > > > > > > > > > Understood. But I think other vendor or developer may face the > > > > > > > > same > > > > > > > > issue in final product shipment or during development. > > > > > > > > Moreover, the > > > > > > > > interface provide the flexibility for developer to separately > > > > > > > > disable/enable u1 or u2, e.g. If they're debugging an u2 issue, > > > > > > > > they > > > > > > > > can disable u1 to simplify the situtation. > > > > > > > > > > > > > > For debugging only, perhaps, but for a "normal" user, please let's > > > > > > > handle this automatically and don't create a switch that never > > > > > > > gets used > > > > > > > by anyone or anything. > > > > > > > > > > > > > Thanks Greg. Since so far the patch has no interesting value to the > > > > > > community, I'll drop the patch. > > > > > > > > > > I didn't say that, I said it needed some more work to be accepted. > > > > Sorry for misunderstanding. Let me explain more why we need this > > > > interface. > > > > > > > > We have a modem USB3 device (in stepping C) hardwired to one specific > > > > port of xHCI. > > > > The device was expected to work with u1 u2, however, due to a HW issue, > > > > it doesn't > > > > work stably. To workaround the issue, we let the init.rc script disable > > > > u1 u2 for > > > > this specific port. > > > > > > Modern Linux systems don't have init.rc scripts anymore :) > > > > > In Android, the init process still reads an init.rc where vendor can > > define their own policies. Vendors normally provides a whole reference > > design (including HW, FW, Kernel, BSP, AOSP) to OEMs. BSP contains > > vendor specific configurations including its own init.rc. > > And that's generally not a good idea for companies to do, as they > shouldn't need special hardware workarounds in an init script, but I > understand :( > > You are also going to be g
Re: [PATCH 1/4] mailbox: add support for System Control and Power Interface(SCPI) protocol
On Wed, 2015-04-29 at 13:25 +0100, Jon Medhurst (Tixy) wrote:
> diff --git a/drivers/mailbox/scpi_protocol.c
> b/drivers/mailbox/scpi_protocol.c
> index c74575b..5818d9b 100644
> --- a/drivers/mailbox/scpi_protocol.c
> +++ b/drivers/mailbox/scpi_protocol.c
> @@ -286,14 +286,23 @@ static void scpi_tx_prepare(struct mbox_client
> *c, void *msg)
> struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
> struct scpi_shared_mem *mem = (struct scpi_shared_mem
> *)ch->tx_payload;
>
> - mem->command = cpu_to_le32(t->cmd);
> if (t->tx_buf)
> memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
> if (t->rx_buf) {
> + int token;
> spin_lock_irqsave(&ch->rx_lock, flags);
> + /*
> +* Presumably we can do this token setting outside
> +* spinlock and still be safe from concurrency?
> +*/
To answer my own question, yes, the four lines below can be moved up
above the spin_lock_irqsave. Because we had better be safe from
concurrency here as we are also writing to the channel's shared memory
area.
> + do
> + token = (++ch->token) & CMD_TOKEN_ID_MASK;
> + while(!token);
> + t->cmd |= token << CMD_TOKEN_ID_SHIFT;
> list_add_tail(&t->node, &ch->rx_pending);
> spin_unlock_irqrestore(&ch->rx_lock, flags);
> }
> + mem->command = cpu_to_le32(t->cmd);
> }
>
> static struct scpi_xfer *get_scpi_xfer(struct scpi_chan *ch)
--
Tixy
--
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] x86, perf: Add an aperfmperf driver
On Wed, Apr 29, 2015 at 06:17:05PM -0700, Andy Lutomirski wrote: > >> > + /* no sampling */ > >> > + if (event->hw.sample_period) > >> > + return -EINVAL; > >> > >> You could have set pmu::capabilities = > >> PERF_PMU_CAP_NO_INTERRUPT which would also have killed that dead. > > > > > > That checks attr.sample_period. I'm a bit confused about the > > relationship between event->hw and event->attr. Do I not need to > > check hw.sample_period? event->attr is the perf_event_attr used to instantiate the event. event->hw is the hardware/working state of the event. You'll notice that attr::sample_period is part of a union and when !attr::freq will be used as the actual hw::sample_period. However when attr::freq we'll compute hw::sample_period based on actual event rates such that we'll approx attr::sample_freq. Setting pmu::capabilities = PERF_PMU_CAP_NO_INTERRUPT would be the best solution here. > > Before I submit v2, do you think this is actually worth doing? I can > > see it being useful for answering questions like "did this workload > > end up running at full speed". > > > > To clarify, this is partially redundant with "cpu-cycles" and > "ref-cycles". That being said, these are simpler, actually documented > as being appropriate for measuring cpu performance states, and don't > have any scheduling constraints. On the whole useful question; I dunno. It seems like something worth providing for the reasons you state. But I don't really get around to doing much userspace these days so I might not be the best to answer this. Also, you could extend this with IA32_PPERF (Skylake and later, see SDM-201501 book 3 section 14.4.5.1). > Also, is perf stat able to count while idle? perf stat -a -e > cpu-cycles sleep 1 reports very small numbers. Yes, perf stat -a (iow cpu events) should count while idle, note however that not all events count during halt, so its very much event dependent. -- 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 0/9] Add sd/emmc support for stih407 family silicon
On 30 April 2015 at 10:28, Maxime Coquelin wrote: > Hi Ulf, > > > On 04/10/2015 01:06 PM, Ulf Hansson wrote: >> >> On 10 April 2015 at 11:40, Peter Griffin wrote: >>> >>> Hi, >>> >>> This series adds sd/emmc support to the sdhci-st.c driver for stih407 >>> family silicon. The changes mainly involve configuring some extra glue >>> registers in the flashSS which configure the Arasan controller. >>> >>> This series also adds support for UHS modes for eMMC. To allow >>> UHS HS200/SD104 modes to function correctly, due to the >>> tight timing constriants, support for delay management is also added. >>> Two types of delay management are supported, static delay management and >>> dynamic delay management, this delay management is only available >>> on eMMC pads on stih410 and later silicon. >>> >>> This series has been tested with stih410-b2120 revd on eMMC and sd, at >>> various clock speeds. As part of this testing a bug was also found in the >>> upstream flexgen clock set_rate implementation (now fixed upstream). >>> >>> max-frequency = 200Mhz >>> /dev/mmcblk0p1: >>> Timing buffered disk reads: 270 MB in 3.02 seconds = 89.54 MB/sec >>> >>> max-frequency = 100Mhz >>> root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 >>> /dev/mmcblk0p1: >>> Timing buffered disk reads: 210 MB in 3.00 seconds = 70.00 MB/sec >>> >>> max-frequency = 50Mhz >>> root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 >>> /dev/mmcblk0p1: >>> Timing buffered disk reads: 118 MB in 3.00 seconds = 39.28 MB/sec >>> >>> It has also been tested on stih416-b2020 to ensure we have caused no >>> regressions. Finally the dt documentation has been updated to reflect >>> the changes in the driver code. Intrestingly it seems we are the first >>> upstream platform to be using some of the uhs bindings such as >>> sd-uhs-sdr104. >>> >>> Changes since v4: >>> - Fixup typo (Pete) >>> >>> Changes since v3: >>> - Rebased on Ulf's mmc next branch (rc5 based) (Ulf) >>> >>> Changes since v2: >>> - Some whitespace fixups (Max) >>> - if (!ioaddr) suggestion (Max) >>> - Add stih418-b2199 suport (Max) >>> - Stih410 to STiH410 fixes (Max) >>> - rebased on v4.0-rc6 (Pete) >>> >>> Changes since v1: >>> - Partition the changes into smaller patches to aid review process >>> (Ulf) >>> >>> Peter Griffin (9): >>>mmc: sdhci-st: Add macros for register offsets and bitfields for mmcss >>> glue regs >>>mmc: sdhci-st: Add support for de-asserting reset signal and top regs >>> resource >>>mmc: sdhci-st: Add delay management functions for top registers >>> (eMMC). >>>mmc: sdhci-st: Add st_mmcss_cconfig function to configure mmcss glue >>> registers. >>>mmc: sdhci-st: Add sdhci_st_set_uhs_signaling function. >>>mmc: sdhci-st: Update the quirks for this controller. >>>mmc: sdhci-st: Update ST SDHCI binding documentation. >>>ARM: STi: DT: STiH407: Add dt nodes for sdhci and emmc. >>>ARM: STi: DT: STiH418: Add dt nodes for sdhci and emmc. >>> >>> Documentation/devicetree/bindings/mmc/sdhci-st.txt | 100 +- >>> arch/arm/boot/dts/stih407-family.dtsi | 30 ++ >>> arch/arm/boot/dts/stih410-b2120.dts| 10 + >>> arch/arm/boot/dts/stih418-b2199.dts| 12 + >>> arch/arm/boot/dts/stihxxx-b2120.dtsi | 8 + >>> drivers/mmc/host/sdhci-st.c| 354 >>> - >>> 6 files changed, 500 insertions(+), 14 deletions(-) >>> >>> -- >>> 1.9.1 >>> >> Thanks! Applied. > > Do you confirm you didn't applied the DT patches? > Correct. Sorry if that was unclear. Kind regards Uffe -- 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] ARM: dts: imx5: Add dts files for USB armory.
On Wed, Apr 29, 2015 at 11:22:11PM -0300, Fabio Estevam wrote: > Hi Peter, > > On Tue, Apr 28, 2015 at 5:20 AM, Peter Chen wrote: > > > Current chipidea usb driver supports role switch function well, if you > > have a gpio or id pin for it. > > On mx6 we are able to perform OTG role-switch funtion as they have the > OTG_ID pins. > > We are talking about mx53 here, which does not have such OTG_ID pins, > so not sure how they can perform role-switch in run-time? > Using gpio as extcon, lvan is working on patch for that http://www.spinics.net/lists/linux-usb/msg123903.html -- Best Regards, Peter Chen -- 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 0/9] Add sd/emmc support for stih407 family silicon
On 04/30/2015 10:51 AM, Ulf Hansson wrote: On 30 April 2015 at 10:28, Maxime Coquelin wrote: Hi Ulf, On 04/10/2015 01:06 PM, Ulf Hansson wrote: On 10 April 2015 at 11:40, Peter Griffin wrote: Hi, This series adds sd/emmc support to the sdhci-st.c driver for stih407 family silicon. The changes mainly involve configuring some extra glue registers in the flashSS which configure the Arasan controller. This series also adds support for UHS modes for eMMC. To allow UHS HS200/SD104 modes to function correctly, due to the tight timing constriants, support for delay management is also added. Two types of delay management are supported, static delay management and dynamic delay management, this delay management is only available on eMMC pads on stih410 and later silicon. This series has been tested with stih410-b2120 revd on eMMC and sd, at various clock speeds. As part of this testing a bug was also found in the upstream flexgen clock set_rate implementation (now fixed upstream). max-frequency = 200Mhz /dev/mmcblk0p1: Timing buffered disk reads: 270 MB in 3.02 seconds = 89.54 MB/sec max-frequency = 100Mhz root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 /dev/mmcblk0p1: Timing buffered disk reads: 210 MB in 3.00 seconds = 70.00 MB/sec max-frequency = 50Mhz root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 /dev/mmcblk0p1: Timing buffered disk reads: 118 MB in 3.00 seconds = 39.28 MB/sec It has also been tested on stih416-b2020 to ensure we have caused no regressions. Finally the dt documentation has been updated to reflect the changes in the driver code. Intrestingly it seems we are the first upstream platform to be using some of the uhs bindings such as sd-uhs-sdr104. Changes since v4: - Fixup typo (Pete) Changes since v3: - Rebased on Ulf's mmc next branch (rc5 based) (Ulf) Changes since v2: - Some whitespace fixups (Max) - if (!ioaddr) suggestion (Max) - Add stih418-b2199 suport (Max) - Stih410 to STiH410 fixes (Max) - rebased on v4.0-rc6 (Pete) Changes since v1: - Partition the changes into smaller patches to aid review process (Ulf) Peter Griffin (9): mmc: sdhci-st: Add macros for register offsets and bitfields for mmcss glue regs mmc: sdhci-st: Add support for de-asserting reset signal and top regs resource mmc: sdhci-st: Add delay management functions for top registers (eMMC). mmc: sdhci-st: Add st_mmcss_cconfig function to configure mmcss glue registers. mmc: sdhci-st: Add sdhci_st_set_uhs_signaling function. mmc: sdhci-st: Update the quirks for this controller. mmc: sdhci-st: Update ST SDHCI binding documentation. ARM: STi: DT: STiH407: Add dt nodes for sdhci and emmc. ARM: STi: DT: STiH418: Add dt nodes for sdhci and emmc. Documentation/devicetree/bindings/mmc/sdhci-st.txt | 100 +- arch/arm/boot/dts/stih407-family.dtsi | 30 ++ arch/arm/boot/dts/stih410-b2120.dts| 10 + arch/arm/boot/dts/stih418-b2199.dts| 12 + arch/arm/boot/dts/stihxxx-b2120.dtsi | 8 + drivers/mmc/host/sdhci-st.c| 354 - 6 files changed, 500 insertions(+), 14 deletions(-) -- 1.9.1 Thanks! Applied. Do you confirm you didn't applied the DT patches? Correct. Sorry if that was unclear. No problem, thanks for the clarification. Best regards, Maxime Kind regards Uffe -- 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 0/9] Add sd/emmc support for stih407 family silicon
On 04/10/2015 11:40 AM, Peter Griffin wrote: Hi, This series adds sd/emmc support to the sdhci-st.c driver for stih407 family silicon. The changes mainly involve configuring some extra glue registers in the flashSS which configure the Arasan controller. This series also adds support for UHS modes for eMMC. To allow UHS HS200/SD104 modes to function correctly, due to the tight timing constriants, support for delay management is also added. Two types of delay management are supported, static delay management and dynamic delay management, this delay management is only available on eMMC pads on stih410 and later silicon. This series has been tested with stih410-b2120 revd on eMMC and sd, at various clock speeds. As part of this testing a bug was also found in the upstream flexgen clock set_rate implementation (now fixed upstream). max-frequency = 200Mhz /dev/mmcblk0p1: Timing buffered disk reads: 270 MB in 3.02 seconds = 89.54 MB/sec max-frequency = 100Mhz root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 /dev/mmcblk0p1: Timing buffered disk reads: 210 MB in 3.00 seconds = 70.00 MB/sec max-frequency = 50Mhz root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 /dev/mmcblk0p1: Timing buffered disk reads: 118 MB in 3.00 seconds = 39.28 MB/sec It has also been tested on stih416-b2020 to ensure we have caused no regressions. Finally the dt documentation has been updated to reflect the changes in the driver code. Intrestingly it seems we are the first upstream platform to be using some of the uhs bindings such as sd-uhs-sdr104. Changes since v4: - Fixup typo (Pete) Changes since v3: - Rebased on Ulf's mmc next branch (rc5 based) (Ulf) Changes since v2: - Some whitespace fixups (Max) - if (!ioaddr) suggestion (Max) - Add stih418-b2199 suport (Max) - Stih410 to STiH410 fixes (Max) - rebased on v4.0-rc6 (Pete) Changes since v1: - Partition the changes into smaller patches to aid review process (Ulf) Peter Griffin (9): mmc: sdhci-st: Add macros for register offsets and bitfields for mmcss glue regs mmc: sdhci-st: Add support for de-asserting reset signal and top regs resource mmc: sdhci-st: Add delay management functions for top registers (eMMC). mmc: sdhci-st: Add st_mmcss_cconfig function to configure mmcss glue registers. mmc: sdhci-st: Add sdhci_st_set_uhs_signaling function. mmc: sdhci-st: Update the quirks for this controller. mmc: sdhci-st: Update ST SDHCI binding documentation. ARM: STi: DT: STiH407: Add dt nodes for sdhci and emmc. ARM: STi: DT: STiH418: Add dt nodes for sdhci and emmc. Documentation/devicetree/bindings/mmc/sdhci-st.txt | 100 +- arch/arm/boot/dts/stih407-family.dtsi | 30 ++ arch/arm/boot/dts/stih410-b2120.dts| 10 + arch/arm/boot/dts/stih418-b2199.dts| 12 + arch/arm/boot/dts/stihxxx-b2120.dtsi | 8 + drivers/mmc/host/sdhci-st.c| 354 - 6 files changed, 500 insertions(+), 14 deletions(-) Patches 8 & 9 applied to STi DT branch. Thanks, Maxime -- 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] arm64: perf: Fix callchain parse error with kernel tracepoint events
On Thu, Apr 30, 2015 at 02:50:05AM +0100, Hou Pengyang wrote:
> On 2015/4/29 18:12, Will Deacon wrote:
> > On Tue, Apr 28, 2015 at 02:20:48PM +0100, Hou Pengyang wrote:
> >> diff --git a/arch/arm64/include/asm/perf_event.h
> >> b/arch/arm64/include/asm/perf_event.h
> >> index d26d1d5..16a074f 100644
> >> --- a/arch/arm64/include/asm/perf_event.h
> >> +++ b/arch/arm64/include/asm/perf_event.h
> >> @@ -24,4 +24,20 @@ extern unsigned long perf_misc_flags(struct pt_regs
> >> *regs);
> >> #define perf_misc_flags(regs)perf_misc_flags(regs)
> >> #endif
> >>
> >> +#define perf_arch_fetch_caller_regs(regs, __ip) { \
> >> + unsigned long sp; \
> >> + __asm__ ("mov %[sp], sp\n" : [sp] "=r" (sp)); \
> >> + (regs)->pc = (__ip);\
> >> + __asm__ ( \
> >> + "str %[sp], %[_arm64_sp] \n\t"\
> >> + "str x29, %[_arm64_fp] \n\t"\
> >> + "mrs %[_arm64_cpsr], spsr_el1 \n\t" \
> >> + : [_arm64_sp] "=m" (regs->sp), \
> >> + [_arm64_fp] "=m" (regs->regs[29]), \
> >> + [_arm64_cpsr] "=r" (regs->pstate) \
> >
> > Does this really all need to be in assembly code? Ideally we'd use something
> > like __builtin_stack_pointer and __builtin_frame_pointer. That just leaves
> > the CPSR, but given that it's (a) only used for user_mode_regs tests and (b)
> > this macro is only used by ftrace, then we just set it to a static value
> > indicating that we're at EL1.
> >
> > So I *think* we should be able to write this as three lines of C.
> >
> Hi, will, as you said, we can get fp by __builtin_frame_address() and
> pstate by setting it to a static value. However, for sp, there isn't a
> gcc builtin fuction like __builtin_stack_pointer, so assembly code is
> needed. What's more, if CONFIG_FRAME_POINTER is close, can fp be got by
> __builtin_frame_address()?
Ah yes, I forgot the history of __builtin_stack_pointer (I think the LLVM
guys proposed it and it was rejected by GCC). Anyway, we can use
current_stack_pointer() instead.
I don't think CONFIG_FRAME_POINTER is relevant here; if you don't have
frame pointers then you won't be able to backtrace. The same issue happens
with your proposed patch.
Will
--
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: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?)
Am Donnerstag, 30. April 2015, 10:20:08 schrieb Dave Chinner: > On Wed, Apr 29, 2015 at 09:05:26PM +0200, Mike Galbraith wrote: > > Here's something that _might_ interest xfs folks. > > > > cd git (source repository of git itself) > > make clean > > echo 3 > /proc/sys/vm/drop_caches > > time make -j8 test > > > > ext42m20.721s > > xfs 6m41.887s <-- ick > > btrfs 1m32.038s > > tux31m30.262s > > > > Testing by Aunt Tilly: mkfs, no fancy switches, mount the thing, test. > > TL;DR: Results are *very different* on a 256GB Samsung 840 EVO SSD > with slightly slower CPUs (E5-4620 @ 2.20GHz)i, all filesystems > using defaults: > > realusersys > xfs 3m16.138s 7m8.341s14m32.462s > ext4 3m18.045s 7m7.840s14m32.994s > btrfs 3m45.149s 7m10.184s 16m30.498s > > What you are seeing is physical seek distances impacting read > performance. XFS does not optimise for minimal physical seek > distance, and hence is slower than filesytsems that do optimise for > minimal seek distance. This shows up especially well on slow single > spindles. > > XFS is *adequate* for the use on slow single drives, but it is > really designed for best performance on storage hardware that is not > seek distance sensitive. > > IOWS, XFS just hates your disk. Spend $50 and buy a cheap SSD and > the problem goes away. :) I am quite surprised that a traditional filesystem that was created in the age of rotating media does not like this kind of media and even seems to excel on BTRFS on the new non rotating media available. But… > > > And now in more detail. > > It's easy to be fast on empty filesystems. XFS does not aim to be > fast in such situations - it aims to have consistent performance > across the life of the filesystem. … this is a quite important addition. > Thing is, once you've abused those filesytsems for a couple of > months, the files in ext4, btrfs and tux3 are not going to be laid > out perfectly on the outer edge of the disk. They'll be spread all > over the place and so all the filesystems will be seeing large seeks > on read. The thing is, XFS will have roughly the same performance as > when the filesystem is empty because the spreading of the allocation > allows it to maintain better locality and separation and hence > doesn't fragment free space nearly as badly as the oher filesystems. > Free space fragmentation is what leads to performance degradation in > filesystems, and all the other filesystem will have degraded to be > *much worse* than XFS. I even still see hungs on what I tend to see as freespace fragmentation in BTRFS. My /home on a Dual (!) BTRFS SSD setup can basically stall to a halt when it has reserved all space of the device for chunks. So this merkaba:~> btrfs fi sh /home Label: 'home' uuid: […] Total devices 2 FS bytes used 129.48GiB devid1 size 170.00GiB used 146.03GiB path /dev/mapper/msata- home devid2 size 170.00GiB used 146.03GiB path /dev/mapper/sata- home Btrfs v3.18 merkaba:~> btrfs fi df /home Data, RAID1: total=142.00GiB, used=126.72GiB System, RAID1: total=32.00MiB, used=48.00KiB Metadata, RAID1: total=4.00GiB, used=2.76GiB GlobalReserve, single: total=512.00MiB, used=0.00B is safe, but one I have size 170 GiB user 170 GiB, even if inside the chunks there is enough free space to allocate from, enough as in 30-40 GiB, it can happen that writes are stalled up to the point that applications on the desktop freeze and I see hung task messages in kernel log. This is the case upto kernel 4.0. I have seen Chris Mason fixing some write stalls for big facebook setups, maybe it will help here, but unless this issue is fixed, I think BTRFS is not yet fully production ready, unless you leave *huge* amount of free space, as in for 200 GiB of data you want to write make a 400 GiB volume. > Put simply: empty filesystem benchmarking does not show the real > performance of the filesystem under sustained production workloads. > Hence benchmarks like this - while interesting from a theoretical > point of view and are widely used for bragging about whose got the > fastest - are mostly irrelevant to determining how the filesystem > will perform in production environments. > > We can also look at this algorithm in a different way: take a large > filesystem (say a few hundred TB) across a few tens of disks in a > linear concat. ext4, btrfs and tux3 will only hit the first disk in > the concat, and so go no faster because they are still bound by > physical seek times. XFS, however, will spread the load across many > (if not all) of the disks, and so effectively reduce the average > seek time by the number of disks doing concurrent IO. Then you'll > see that application level IO concurrency becomes the performance > limitation, not the physical seek time of the hardware. That are the allocation groups. I always wondered how it can be beneficial to spread the allocation
Re: [GIT PULL] kdbus for 4.1-rc1
It was <2015-04-29 śro 17:21>, when Austin S Hemmelgarn wrote: > On 2015-04-29 11:03, Theodore Ts'o wrote: >> On Wed, Apr 29, 2015 at 04:53:53PM +0200, Harald Hoyer wrote: >>> Sure, I can write one binary to rule them all, pull out all the code from >>> all >>> tools I need, but for me an IPC mechanism sounds a lot better. And it >>> should be >>> _one_ common IPC mechanism and not a plethora of them. It should feel like >>> an >>> operating system and not like a bunch of thrown together software, which is >>> glued together with some magic shell scripts. >> >> And so requiring wireshark (and X?) in initramfs to debug problems >> once dbus is introduced is better? >> >> I would think shell scripts are *easier* to debug when things go >> wrong, [...] > I keep hearing from people that shell scripting is hard, it really > isn't compared to a number of other scripting languages, you just need > to actually learn to do it right (which is getting more and more > difficult these days cause fewer and fewer CS schools are teaching > Unix). My 2/100 of a currency of your choice. As much as I like(ed) shell scripts as a boot up tool and disliked obscure boot-up procedures of some operating system, I can't help but notice that GNU/Linux distributions have become very sophisticated/complcated (cross out if not applicable). Personally I feel that this degree of coplexity can't be supported by shell scripts piping data around. It does not scale. I am not 100% sure a new IPC is the answer, simply because I do not have experience to be so. It definitely can be and the problem, as I see it, is real. (The alternative answer is PowerShells capability to pipe objects. I don't like it and I thik it's not a full answer.) Regardless, of initrd issues I feel there is a need of a local IPC that is more capable than UDS. Linus Torvalds is probably right that dbus-daemon is everything but effictient. I disagree, however, that it can be optimised and therefore solve *all* issues kdbus is trying to address. dbus-deamon, by design, can't some things. It can't transmitt large payloads without copying them. It can't be made race-free. Kind regards, -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics signature.asc Description: PGP signature
Re: [PATCH 03/23] gpio: sysfs: drop redundant lock-as-irq
On Wed, Apr 29, 2015 at 11:48:57PM +0200, Linus Walleij wrote: > On Tue, Apr 21, 2015 at 5:42 PM, Johan Hovold wrote: > > > Drop redundant lock-as-irq in gpio_setup_irq, which has already been > > handled when requesting and releasing the irq (i.e. in the irq chip > > irq_request_resources and irq_release_resources callbacks). > > Well we would hope they all do that. And I hope for the vast majority > that is true, but there is a TODO to go over all gpiochip drivers > (some which are elsewhere in the kernel than drivers/gpio) and > make sure they actually do so. > > Right now it's a bit arbitrary if so happens, and in not marked by > the driver as IRQ then this kicks in and provides an additional > protection. > > But maybe that's overzealous, what do people say? No, you're right. The drivers that fail to do this needs to be fixed, but the "redundant" lock-as-irq in the sysfs interface should not be removed before that. I'll respin the series and add it back with a comment explaining why gpiochip_lock_as_irq is currently called twice. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] usb: gadget: add usb_gadget_activate/deactivate functions
On 04/29/2015 05:30 PM, Felipe Balbi wrote:
> On Wed, Apr 29, 2015 at 11:08:06AM +0200, Robert Baldyga wrote:
>> Hi Felipe,
>>
>> On 04/28/2015 06:40 PM, Felipe Balbi wrote:
>>> On Tue, Apr 07, 2015 at 10:31:52AM +0200, Robert Baldyga wrote:
These functions allows to deactivate gadget to make it not visible to
host and make it active again when gadget driver is finally ready.
They are needed to fix usb_function_activate() and
usb_function_deactivate()
functions which currently are not working as usb_gadget_connect() is
called immediately after function bind regardless to previous calls of
usb_gadget_disconnect() function.
>>>
>>> and that's what needs to be fixed, a long time ago I wrote the patch
>>> below which I never got to finishing:
>>>
>>> commit a23800e2463ae1f4eafa7c0a15bb44afee75994f
>>> Author: Felipe Balbi
>>> Date: Thu Jul 26 14:23:44 2012 +0300
>>>
>>> usb: gadget: let gadgets control pullup on their own
>>>
>>> This is useful on gadgets that depend on userland
>>> daemons to function properly. We can delay connection
>>> to the host until userland is ready.
>>>
>>> Signed-off-by: Felipe Balbi
>>>
>>> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
>>> index 7c821de8ce3d..790ccf29f2ee 100644
>>> --- a/drivers/usb/gadget/composite.c
>>> +++ b/drivers/usb/gadget/composite.c
>>> @@ -1784,8 +1784,9 @@ int usb_composite_probe(struct usb_composite_driver
>>> *driver)
>>> driver->name = "composite";
>>>
>>> driver->gadget_driver = composite_driver_template;
>>> - gadget_driver = &driver->gadget_driver;
>>>
>>> + gadget_driver = &driver->gadget_driver;
>>> + gadget_driver->controls_pullups = driver->controls_pullups;
>>> gadget_driver->function = (char *) driver->name;
>>> gadget_driver->driver.name = driver->name;
>>> gadget_driver->max_speed = driver->max_speed;
>>> diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
>>> index 8a1eeb24ae6a..c0f4fca9384b 100644
>>> --- a/drivers/usb/gadget/udc-core.c
>>> +++ b/drivers/usb/gadget/udc-core.c
>>> @@ -235,7 +235,18 @@ static void usb_gadget_remove_driver(struct usb_udc
>>> *udc)
>>>
>>> kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
>>>
>>> - usb_gadget_disconnect(udc->gadget);
>>> + /*
>>> +* NOTICE: if gadget driver wants to control
>>> +* pullup, it needs to make sure that when
>>> +* user tries to rmmod the gadget driver, it
>>> +* will disconnect the pullups before returning
>>> +* from its ->unbind() method.
>>> +*
>>> +* We are truly trusting the gadget driver here.
>>> +*/
>>> + if (!udc->driver->controls_pullups)
>>> + usb_gadget_disconnect(udc->gadget);
>>> +
>>> udc->driver->disconnect(udc->gadget);
>>> udc->driver->unbind(udc->gadget);
>>> usb_gadget_udc_stop(udc->gadget, udc->driver);
>>> @@ -300,7 +311,18 @@ static int udc_bind_to_driver(struct usb_udc *udc,
>>> struct usb_gadget_driver *dri
>>> driver->unbind(udc->gadget);
>>> goto err1;
>>> }
>>> - usb_gadget_connect(udc->gadget);
>>> +
>>> + /*
>>> +* NOTICE: if gadget driver wants to control
>>> +* pullups, it needs to make sure its calls
>>> +* to usb_function_activate() and
>>> +* usb_function_deactivate() are balanced,
>>> +* otherwise gadget_driver will never enumerate.
>>> +*
>>> +* We are truly trusting the gadget driver here.
>>> +*/
>>> + if (!driver->controls_pullups)
>>> + usb_gadget_connect(udc->gadget);
>>>
>>> kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
>>> return 0;
>>> diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
>>> index 3c671c1b37f6..7ae797c85cb9 100644
>>> --- a/include/linux/usb/composite.h
>>> +++ b/include/linux/usb/composite.h
>>> @@ -157,6 +157,7 @@ struct usb_function {
>>> int (*get_status)(struct usb_function *);
>>> int (*func_suspend)(struct usb_function *,
>>> u8 suspend_opt);
>>> +
>>> /* private: */
>>> /* internals */
>>> struct list_headlist;
>>> @@ -279,6 +280,8 @@ enum {
>>> * @max_speed: Highest speed the driver supports.
>>> * @needs_serial: set to 1 if the gadget needs userspace to provide
>>> * a serial number. If one is not provided, warning will be
>>> printed.
>>> + * @controls_pullups: this driver will control pullup and udc-core
>>> shouldn't
>>> + * enable it by default
>>> * @bind: (REQUIRED) Used to allocate resources that are shared across the
>>> * whole device, such as string IDs, and add its configurations using
>>> * @usb_add_config(). This may fail by returning a negative errno
>>> @@ -308,6 +311,7 @@ struct usb_composite_driver {
>>> struct usb_gadget_strings **strings;
>>> enum usb_device_speed max_speed;
