All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 3/3] iommu/arm-smmu: Error out only if not enough context interrupts
From: Vivek Gautam @ 2018-07-24  9:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180724083633.GA19324@arm.com>

Hi Will,


On 7/24/2018 2:06 PM, Will Deacon wrote:
> On Thu, Jul 19, 2018 at 11:23:56PM +0530, Vivek Gautam wrote:
>> Currently we check if the number of context banks is not equal to
>> num_context_interrupts. However, there are booloaders such as, one
>> on sdm845 that reserves few context banks and thus kernel views
>> less than the total available context banks.
>> So, although the hardware definition in device tree would mention
>> the correct number of context interrupts, this number can be
>> greater than the number of context banks visible to smmu in kernel.
>> We should therefore error out only when the number of context banks
>> is greater than the available number of context interrupts.
>>
>> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
>> Suggested-by: Tomasz Figa <tfiga@chromium.org>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> ---
>>   drivers/iommu/arm-smmu.c | 19 +++++++++++++------
>>   1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 7c69736a30f8..4cb53bf4f423 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -2229,12 +2229,19 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>>   	if (err)
>>   		return err;
>>   
>> -	if (smmu->version == ARM_SMMU_V2 &&
>> -	    smmu->num_context_banks != smmu->num_context_irqs) {
>> -		dev_err(dev,
>> -			"found only %d context interrupt(s) but %d required\n",
>> -			smmu->num_context_irqs, smmu->num_context_banks);
>> -		return -ENODEV;
>> +	if (smmu->version == ARM_SMMU_V2) {
>> +		if (smmu->num_context_banks > smmu->num_context_irqs) {
>> +			dev_err(dev,
>> +			      "found only %d context irq(s) but %d required\n",
>> +			      smmu->num_context_irqs, smmu->num_context_banks);
>> +			return -ENODEV;
>> +		} else if (smmu->num_context_banks < smmu->num_context_irqs) {
>> +			/* loose extra context interrupts */
>> +			dev_notice(dev,
>> +			      "found %d context irq(s) but only %d required\n",
>> +			      smmu->num_context_irqs, smmu->num_context_banks);
>> +			smmu->num_context_irqs = smmu->num_context_banks;
>> +		}
> I don't see the utility in the new message. Can you simplify with the patch
> below on top? It's a bit weird that we only decide to ignore the extra irqs
> after calling platform_get_irq() on them, but that seems to be harmless.

Thanks. I will modify as suggested below and respin.

Best regards
Vivek

>
> Will
>
> --->8
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index aa46c1ed5bf9..5349e22b5c78 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2109,13 +2109,10 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>   			      "found only %d context irq(s) but %d required\n",
>   			      smmu->num_context_irqs, smmu->num_context_banks);
>   			return -ENODEV;
> -		} else if (smmu->num_context_banks < smmu->num_context_irqs) {
> -			/* loose extra context interrupts */
> -			dev_notice(dev,
> -			      "found %d context irq(s) but only %d required\n",
> -			      smmu->num_context_irqs, smmu->num_context_banks);
> -			smmu->num_context_irqs = smmu->num_context_banks;
>   		}
> +
> +		/* Ignore superfluous interrupts */
> +		smmu->num_context_irqs = smmu->num_context_banks;
>   	}
>   
>   	for (i = 0; i < smmu->num_global_irqs; ++i) {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 3/3] iommu/arm-smmu: Error out only if not enough context interrupts
From: Vivek Gautam @ 2018-07-24  9:39 UTC (permalink / raw)
  To: Will Deacon
  Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-soc-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	david.brown-QSEj5FYQhm4dnm+yROfE0A,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	andy.gross-QSEj5FYQhm4dnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20180724083633.GA19324-5wv7dgnIgG8@public.gmane.org>

Hi Will,


On 7/24/2018 2:06 PM, Will Deacon wrote:
> On Thu, Jul 19, 2018 at 11:23:56PM +0530, Vivek Gautam wrote:
>> Currently we check if the number of context banks is not equal to
>> num_context_interrupts. However, there are booloaders such as, one
>> on sdm845 that reserves few context banks and thus kernel views
>> less than the total available context banks.
>> So, although the hardware definition in device tree would mention
>> the correct number of context interrupts, this number can be
>> greater than the number of context banks visible to smmu in kernel.
>> We should therefore error out only when the number of context banks
>> is greater than the available number of context interrupts.
>>
>> Signed-off-by: Vivek Gautam <vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Suggested-by: Tomasz Figa <tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> Cc: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>> Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
>> ---
>>   drivers/iommu/arm-smmu.c | 19 +++++++++++++------
>>   1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 7c69736a30f8..4cb53bf4f423 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -2229,12 +2229,19 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>>   	if (err)
>>   		return err;
>>   
>> -	if (smmu->version == ARM_SMMU_V2 &&
>> -	    smmu->num_context_banks != smmu->num_context_irqs) {
>> -		dev_err(dev,
>> -			"found only %d context interrupt(s) but %d required\n",
>> -			smmu->num_context_irqs, smmu->num_context_banks);
>> -		return -ENODEV;
>> +	if (smmu->version == ARM_SMMU_V2) {
>> +		if (smmu->num_context_banks > smmu->num_context_irqs) {
>> +			dev_err(dev,
>> +			      "found only %d context irq(s) but %d required\n",
>> +			      smmu->num_context_irqs, smmu->num_context_banks);
>> +			return -ENODEV;
>> +		} else if (smmu->num_context_banks < smmu->num_context_irqs) {
>> +			/* loose extra context interrupts */
>> +			dev_notice(dev,
>> +			      "found %d context irq(s) but only %d required\n",
>> +			      smmu->num_context_irqs, smmu->num_context_banks);
>> +			smmu->num_context_irqs = smmu->num_context_banks;
>> +		}
> I don't see the utility in the new message. Can you simplify with the patch
> below on top? It's a bit weird that we only decide to ignore the extra irqs
> after calling platform_get_irq() on them, but that seems to be harmless.

Thanks. I will modify as suggested below and respin.

Best regards
Vivek

>
> Will
>
> --->8
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index aa46c1ed5bf9..5349e22b5c78 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2109,13 +2109,10 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>   			      "found only %d context irq(s) but %d required\n",
>   			      smmu->num_context_irqs, smmu->num_context_banks);
>   			return -ENODEV;
> -		} else if (smmu->num_context_banks < smmu->num_context_irqs) {
> -			/* loose extra context interrupts */
> -			dev_notice(dev,
> -			      "found %d context irq(s) but only %d required\n",
> -			      smmu->num_context_irqs, smmu->num_context_banks);
> -			smmu->num_context_irqs = smmu->num_context_banks;
>   		}
> +
> +		/* Ignore superfluous interrupts */
> +		smmu->num_context_irqs = smmu->num_context_banks;
>   	}
>   
>   	for (i = 0; i < smmu->num_global_irqs; ++i) {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [U-Boot] [PATCH v2 6/6] mmc: arm_pl180_mmci: Add "cd_inverted" DT property read
From: Patrice Chotard @ 2018-07-24  9:39 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <1532425165-29027-1-git-send-email-patrice.chotard@st.com>

Add missing read of "cd_inverted" property in DT.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
---

Changes in v2: None

 drivers/mmc/arm_pl180_mmci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 1cd780b3eec0..75d1a367ceb6 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -440,6 +440,7 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
 			    SDI_CLKCR_HWFC_EN;
 	host->clock_in = clk_get_rate(&clk);
 	host->version2 = dev_get_driver_data(dev);
+	host->cd_inverted = dev_read_bool(dev, "cd-inverted");
 
 	cfg->name = dev->name;
 	cfg->voltages = VOLTAGE_WINDOW_SD;
-- 
1.9.1

^ permalink raw reply related

* [U-Boot] [PATCH v2 5/6] mmc: arm_pl180_mmci: Add missing clk_free
From: Patrice Chotard @ 2018-07-24  9:39 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <1532425165-29027-1-git-send-email-patrice.chotard@st.com>

Add missing clk_free() call in case of failure
when enabling the clock.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
---

Changes in v2: None

 drivers/mmc/arm_pl180_mmci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index c4d94d102cc1..1cd780b3eec0 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -430,6 +430,7 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
 
 	ret = clk_enable(&clk);
 	if (ret) {
+		clk_free(&clk);
 		dev_err(dev, "failed to enable clock\n");
 		return ret;
 	}
-- 
1.9.1

^ permalink raw reply related

* [U-Boot] [PATCH v2 4/6] mmc: arm_pl180_mmci: Update to support CONFIG_BLK
From: Patrice Chotard @ 2018-07-24  9:39 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <1532425165-29027-1-git-send-email-patrice.chotard@st.com>

Config flag CONFIG_BLK becomes mandatory, update arm_pl180_mmci
to support this config.

This driver is used by STM32Fx and by Vexpress platforms.
Only STM32Fx are DM ready. No DM code is isolated and will be
removed easily when wexpress will be converted to DM.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
---

Changes in v2:
 - replace devfdt_get_addr() by dev_read_addr()
 - re-introduce arm_pl180_mmc_ofdata_to_platdata()

 drivers/mmc/arm_pl180_mmci.c | 67 ++++++++++++++++++++++++++------------------
 1 file changed, 40 insertions(+), 27 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index e267cd782e8b..c4d94d102cc1 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -357,13 +357,13 @@ static const struct mmc_ops arm_pl180_mmci_ops = {
 	.set_ios = host_set_ios,
 	.init = mmc_host_reset,
 };
-#endif
 
 /*
  * mmc_host_init - initialize the mmc controller.
  * Set initial clock and power for mmc slot.
  * Initialize mmc struct and register with mmc framework.
  */
+
 int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc)
 {
 	u32 sdi_u32;
@@ -377,9 +377,8 @@ int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc)
 	writel(sdi_u32, &host->base->mask0);
 
 	host->cfg.name = host->name;
-#ifndef CONFIG_DM_MMC
 	host->cfg.ops = &arm_pl180_mmci_ops;
-#endif
+
 	/* TODO remove the duplicates */
 	host->cfg.host_caps = host->caps;
 	host->cfg.voltages = host->voltages;
@@ -393,20 +392,34 @@ int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc)
 	*mmc = mmc_create(&host->cfg, host);
 	if (!*mmc)
 		return -1;
-
 	debug("registered mmc interface number is:%d\n",
 	      (*mmc)->block_dev.devnum);
 
 	return 0;
 }
+#endif
 
 #ifdef CONFIG_DM_MMC
+static void arm_pl180_mmc_init(struct pl180_mmc_host *host)
+{
+	u32 sdi_u32;
+
+	writel(host->pwr_init, &host->base->power);
+	writel(host->clkdiv_init, &host->base->clock);
+	udelay(CLK_CHANGE_DELAY);
+
+	/* Disable mmc interrupts */
+	sdi_u32 = readl(&host->base->mask0) & ~SDI_MASK0_MASK;
+	writel(sdi_u32, &host->base->mask0);
+}
+
 static int arm_pl180_mmc_probe(struct udevice *dev)
 {
 	struct arm_pl180_mmc_plat *pdata = dev_get_platdata(dev);
 	struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
 	struct mmc *mmc = &pdata->mmc;
-	struct pl180_mmc_host *host = mmc->priv;
+	struct pl180_mmc_host *host = dev->priv;
+	struct mmc_config *cfg = &pdata->cfg;
 	struct clk clk;
 	u32 bus_width;
 	int ret;
@@ -421,27 +434,28 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
 		return ret;
 	}
 
-	strcpy(host->name, "MMC");
 	host->pwr_init = INIT_PWR;
 	host->clkdiv_init = SDI_CLKCR_CLKDIV_INIT_V1 | SDI_CLKCR_CLKEN |
 			    SDI_CLKCR_HWFC_EN;
-	host->voltages = VOLTAGE_WINDOW_SD;
-	host->caps = 0;
 	host->clock_in = clk_get_rate(&clk);
-	host->clock_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
-	host->clock_max = dev_read_u32_default(dev, "max-frequency",
-					       MMC_CLOCK_MAX);
 	host->version2 = dev_get_driver_data(dev);
 
+	cfg->name = dev->name;
+	cfg->voltages = VOLTAGE_WINDOW_SD;
+	cfg->host_caps = 0;
+	cfg->f_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
+	cfg->f_max = dev_read_u32_default(dev, "max-frequency", MMC_CLOCK_MAX);
+	cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
+
 	gpio_request_by_name(dev, "cd-gpios", 0, &host->cd_gpio, GPIOD_IS_IN);
 
 	bus_width = dev_read_u32_default(dev, "bus-width", 1);
 	switch (bus_width) {
 	case 8:
-		host->caps |= MMC_MODE_8BIT;
+		cfg->host_caps |= MMC_MODE_8BIT;
 		/* Hosts capable of 8-bit transfers can also do 4 bits */
 	case 4:
-		host->caps |= MMC_MODE_4BIT;
+		cfg->host_caps |= MMC_MODE_4BIT;
 		break;
 	case 1:
 		break;
@@ -449,19 +463,21 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
 		dev_err(dev, "Invalid bus-width value %u\n", bus_width);
 	}
 
-	ret = arm_pl180_mmci_init(host, &mmc);
-	if (ret) {
-		dev_err(dev, "arm_pl180_mmci init failed\n");
-		return ret;
-	}
-
+	arm_pl180_mmc_init(host);
+	mmc->priv = host;
 	mmc->dev = dev;
-	dev->priv = host;
 	upriv->mmc = mmc;
 
 	return 0;
 }
 
+int arm_pl180_mmc_bind(struct udevice *dev)
+{
+	struct arm_pl180_mmc_plat *plat = dev_get_platdata(dev);
+
+	return mmc_bind(dev, &plat->mmc, &plat->cfg);
+}
+
 static int dm_host_request(struct udevice *dev, struct mmc_cmd *cmd,
 			   struct mmc_data *data)
 {
@@ -479,9 +495,7 @@ static int dm_host_set_ios(struct udevice *dev)
 
 static int dm_mmc_getcd(struct udevice *dev)
 {
-	struct arm_pl180_mmc_plat *pdata = dev_get_platdata(dev);
-	struct mmc *mmc = &pdata->mmc;
-	struct pl180_mmc_host *host = mmc->priv;
+	struct pl180_mmc_host *host = dev->priv;
 	int value = 1;
 
 	if (dm_gpio_is_valid(&host->cd_gpio)) {
@@ -501,12 +515,10 @@ static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = {
 
 static int arm_pl180_mmc_ofdata_to_platdata(struct udevice *dev)
 {
-	struct arm_pl180_mmc_plat *pdata = dev_get_platdata(dev);
-	struct mmc *mmc = &pdata->mmc;
-	struct pl180_mmc_host *host = mmc->priv;
+	struct pl180_mmc_host *host = dev->priv;
 	fdt_addr_t addr;
 
-	addr = devfdt_get_addr(dev);
+	addr = dev_read_addr(dev);
 	if (addr == FDT_ADDR_T_NONE)
 		return -EINVAL;
 
@@ -527,6 +539,7 @@ U_BOOT_DRIVER(arm_pl180_mmc) = {
 	.ops = &arm_pl180_dm_mmc_ops,
 	.probe = arm_pl180_mmc_probe,
 	.ofdata_to_platdata = arm_pl180_mmc_ofdata_to_platdata,
+	.bind = arm_pl180_mmc_bind,
 	.priv_auto_alloc_size = sizeof(struct pl180_mmc_host),
 	.platdata_auto_alloc_size = sizeof(struct arm_pl180_mmc_plat),
 };
-- 
1.9.1

^ permalink raw reply related

* [U-Boot] [PATCH v2 3/6] configs: stm32f469-disco: Enable CONFIG_BLK
From: Patrice Chotard @ 2018-07-24  9:39 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <1532425165-29027-1-git-send-email-patrice.chotard@st.com>

CONFIG_BLK config flag becomes mandatory, enable it.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
---

Changes in v2: None

 configs/stm32f469-discovery_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/stm32f469-discovery_defconfig b/configs/stm32f469-discovery_defconfig
index 4de03edcc2ca..a55476f2f323 100644
--- a/configs/stm32f469-discovery_defconfig
+++ b/configs/stm32f469-discovery_defconfig
@@ -26,7 +26,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
-# CONFIG_BLK is not set
 CONFIG_DM_MMC=y
 CONFIG_ARM_PL180_MMCI=y
 CONFIG_MTD_NOR_FLASH=y
-- 
1.9.1

^ permalink raw reply related

* [U-Boot] [PATCH v2 2/6] configs: stm32f746-disco: Enable CONFIG_BLK
From: Patrice Chotard @ 2018-07-24  9:39 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <1532425165-29027-1-git-send-email-patrice.chotard@st.com>

CONFIG_BLK config flag becomes mandatory, enable it.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
---

Changes in v2: None

 configs/stm32f746-disco_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/stm32f746-disco_defconfig b/configs/stm32f746-disco_defconfig
index aa7403f3c516..6f07ff155862 100644
--- a/configs/stm32f746-disco_defconfig
+++ b/configs/stm32f746-disco_defconfig
@@ -40,7 +40,6 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_NETCONSOLE=y
-# CONFIG_BLK is not set
 CONFIG_DM_MMC=y
 # CONFIG_SPL_DM_MMC is not set
 CONFIG_ARM_PL180_MMCI=y
-- 
1.9.1

^ permalink raw reply related

* [U-Boot] [PATCH v2 1/6] configs: stm32f429-evaluation: Enable CONFIG_BLK
From: Patrice Chotard @ 2018-07-24  9:39 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <1532425165-29027-1-git-send-email-patrice.chotard@st.com>

CONFIG_BLK config flag becomes mandatory, enable it.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
---

Changes in v2: None

 configs/stm32f429-evaluation_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/stm32f429-evaluation_defconfig b/configs/stm32f429-evaluation_defconfig
index 1b14a4964067..3ddd5c50fb1d 100644
--- a/configs/stm32f429-evaluation_defconfig
+++ b/configs/stm32f429-evaluation_defconfig
@@ -26,7 +26,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
-# CONFIG_BLK is not set
 CONFIG_DM_MMC=y
 CONFIG_ARM_PL180_MMCI=y
 CONFIG_MTD_NOR_FLASH=y
-- 
1.9.1

^ permalink raw reply related

* [U-Boot] [PATCH v2 0/6] Add support of CONFIG_BLK for STM32Fx platforms
From: Patrice Chotard @ 2018-07-24  9:39 UTC (permalink / raw)
  To: u-boot


This series :
  _ adds support of CONFIG_BLK flag to STM32Fx platforms
  _ enables CONFIG_BLK flag for STM32Fx based boards
  _ adds missing clk_free() call in error path
  _ adds read of "cd_inverted" DT property

Changes in v2:
 - replace devfdt_get_addr() by dev_read_addr()
 - re-introduce arm_pl180_mmc_ofdata_to_platdata()

Patrice Chotard (6):
  configs: stm32f429-evaluation: Enable CONFIG_BLK
  configs: stm32f746-disco: Enable CONFIG_BLK
  configs: stm32f469-disco: Enable CONFIG_BLK
  mmc: arm_pl180_mmci: Update to support CONFIG_BLK
  mmc: arm_pl180_mmci: Add missing clk_free
  mmc: arm_pl180_mmci: Add "cd_inverted" DT property read

 configs/stm32f429-evaluation_defconfig |  1 -
 configs/stm32f469-discovery_defconfig  |  1 -
 configs/stm32f746-disco_defconfig      |  1 -
 drivers/mmc/arm_pl180_mmci.c           | 69 +++++++++++++++++++++-------------
 4 files changed, 42 insertions(+), 30 deletions(-)

-- 
1.9.1

^ permalink raw reply

* [meta-oe][PATCH] librelp: Upgrade to 1.2.16
From: mingli.yu @ 2018-07-24  9:38 UTC (permalink / raw)
  To: openembedded-devel

From: Mingli Yu <mingli.yu@windriver.com>

Add 0001-src-tcp.c-fix-jump-misses-init-error.patch
to fix -Werror=jump-misses-init error

Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
 ...src-tcp.c-fix-jump-misses-init-error.patch | 71 +++++++++++++++++++
 .../{librelp_1.2.14.bb => librelp_1.2.16.bb}  |  6 +-
 2 files changed, 75 insertions(+), 2 deletions(-)
 create mode 100644 meta-oe/recipes-extended/rsyslog/librelp/0001-src-tcp.c-fix-jump-misses-init-error.patch
 rename meta-oe/recipes-extended/rsyslog/{librelp_1.2.14.bb => librelp_1.2.16.bb} (59%)

diff --git a/meta-oe/recipes-extended/rsyslog/librelp/0001-src-tcp.c-fix-jump-misses-init-error.patch b/meta-oe/recipes-extended/rsyslog/librelp/0001-src-tcp.c-fix-jump-misses-init-error.patch
new file mode 100644
index 000000000..68b686346
--- /dev/null
+++ b/meta-oe/recipes-extended/rsyslog/librelp/0001-src-tcp.c-fix-jump-misses-init-error.patch
@@ -0,0 +1,71 @@
+From 3e5a0cb440c788e2383e40ab23ac1cf01d96961b Mon Sep 17 00:00:00 2001
+From: Mingli Yu <mingli.yu@windriver.com>
+Date: Tue, 24 Jul 2018 01:30:25 -0700
+Subject: [PATCH] src/tcp.c: fix jump-misses-init error
+
+Fix below jump-misses-init error
+
+| In file included from ../../git/src/tcp.c:51:
+| ../../git/src/tcp.c: In function 'relpTcpConnect':
+| ../../git/src/relp.h:220:3: error: jump skips variable initialization [-Werror=jump-misses-init]
+|    goto finalize_it;  \
+|    ^~~~
+| ../../git/src/tcp.c:1951:3: note: in expansion of macro 'ABORT_FINALIZE'
+|    ABORT_FINALIZE(RELP_RET_IO_ERR);
+|    ^~~~~~~~~~~~~~
+| ../../git/src/tcp.c:2005:1: note: label 'finalize_it' defined here
+|  finalize_it:
+|  ^~~~~~~~~~~
+| ../../git/src/tcp.c:1991:6: note: 'r' declared here
+|   int r = getsockopt(pThis->sock, SOL_SOCKET, SO_ERROR, &so_error, &len);
+|       ^
+| In file included from ../../git/src/tcp.c:51:
+| ../../git/src/relp.h:220:3: error: jump skips variable initialization [-Werror=jump-misses-init]
+|    goto finalize_it;  \
+|    ^~~~
+| ../../git/src/tcp.c:1951:3: note: in expansion of macro 'ABORT_FINALIZE'
+|    ABORT_FINALIZE(RELP_RET_IO_ERR);
+|    ^~~~~~~~~~~~~~
+| ../../git/src/tcp.c:2005:1: note: label 'finalize_it' defined here
+|  finalize_it:
+|  ^~~~~~~~~~~
+| ../../git/src/tcp.c:1989:12: note: 'len' declared here
+|   socklen_t len = sizeof so_error;
+|             ^~~
+
+Upstream-Status: Submitted[https://github.com/rsyslog/librelp/pull/117]
+
+Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
+---
+ src/tcp.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/src/tcp.c b/src/tcp.c
+index f35eb84..fb34dc7 100644
+--- a/src/tcp.c
++++ b/src/tcp.c
+@@ -1936,6 +1936,9 @@ relpTcpConnect(relpTcp_t *const pThis,
+ 	struct addrinfo hints;
+ 	struct addrinfo *reslocal = NULL;
+ 	struct pollfd pfd;
++	int so_error;
++	socklen_t len = sizeof so_error;
++	int r;
+ 
+ 	ENTER_RELPFUNC;
+ 	RELPOBJ_assert(pThis, Tcp);
+@@ -1985,10 +1988,8 @@ relpTcpConnect(relpTcp_t *const pThis,
+ 		ABORT_FINALIZE(RELP_RET_TIMED_OUT);
+ 	}
+ 
+-	int so_error;
+-	socklen_t len = sizeof so_error;
+ 
+-	int r = getsockopt(pThis->sock, SOL_SOCKET, SO_ERROR, &so_error, &len);
++	r = getsockopt(pThis->sock, SOL_SOCKET, SO_ERROR, &so_error, &len);
+ 	if (r == -1 || so_error != 0) {
+ 		pThis->pEngine->dbgprint("socket has an error %d\n", so_error);
+ 		ABORT_FINALIZE(RELP_RET_IO_ERR);
+-- 
+2.17.1
+
diff --git a/meta-oe/recipes-extended/rsyslog/librelp_1.2.14.bb b/meta-oe/recipes-extended/rsyslog/librelp_1.2.16.bb
similarity index 59%
rename from meta-oe/recipes-extended/rsyslog/librelp_1.2.14.bb
rename to meta-oe/recipes-extended/rsyslog/librelp_1.2.16.bb
index 28047eb54..6c68f6040 100644
--- a/meta-oe/recipes-extended/rsyslog/librelp_1.2.14.bb
+++ b/meta-oe/recipes-extended/rsyslog/librelp_1.2.16.bb
@@ -6,9 +6,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=1fb9c10ed9fd6826757615455ca893a9"
 
 DEPENDS = "gmp nettle libidn zlib gnutls"
 
-SRC_URI = "git://github.com/rsyslog/librelp.git;protocol=https"
+SRC_URI = "git://github.com/rsyslog/librelp.git;protocol=https \
+           file://0001-src-tcp.c-fix-jump-misses-init-error.patch \
+"
 
-SRCREV = "fc512e337bfc7c92770246dbff5f482b879498b9"
+SRCREV = "5e849ff060be0c7dce972e194c54fdacfee0adc2"
 
 S = "${WORKDIR}/git"
 
-- 
2.17.1



^ permalink raw reply related

* Re: [Minios-devel] automation: Creating a patchwork instance to improve pre-commit build testing
From: Lars Kurth @ 2018-07-24  9:38 UTC (permalink / raw)
  To: Wei Liu, Doug Goldstein
  Cc: Lars Kurth, Iurii Artemenko, Minios-devel, Committers,
	'Jan Beulich', xen-devel, Matt Spencer
In-Reply-To: <20180724092430.puacbfkbimdm5anz@citrix.com>


[-- Attachment #1.1: Type: text/plain, Size: 2058 bytes --]



> On 24 Jul 2018, at 10:24, Wei Liu <wei.liu2@citrix.com> wrote:
> 
> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
>>>>> On 23.07.18 at 18:40, <lars.kurth@citrix.com> wrote:
>>> # How does this impact me?
>>> The contribution workflow is *not* impacted by this change, but once up and 
>>> running the following will happen once you post a patch or patch series to 
>>> xen-devel:
>>> * Patchwork will take patch series from the mailing list and applies it
>>> * CI/DC testing is triggered
>>> * A test report will be sent as a mail to the patch or the series (aka the 00 patch of the series)
>>> 
>>> This does mean though that series which do not build or show other issues, 
>>> will likely not be reviewed until the tests pass. This would lessen the 
>>> burden on reviewers, as they will know whether the code submitted builds on a 
>>> wide array of environments. 
>> 
>> So how are dependencies between series intended to be dealt with? It
>> is not uncommon for someone to say "applies only on top of xyz". The
>> implication of "will likely not be reviewed until the tests pass" seems
>> unsuitable to me in such a case.
>> 
> 
> We have been asking everyone to rebase to staging before posting a new
> version for a long time.  It is natural for the bot to assume that
> everything should apply on top of staging. That would provide most value
> to the community.
> 
> For special cases like you just mention, we should aim to provide
> mechanisms to manually appoint a branch to be tested.

Wei, Doug: I have another question, which is mainly for my own understanding. 

Right now we allow posting of patches to Linux, Qemu, xen.git, OSSTEST, ... to xen-devel. The planned CI infrastructure only applies to xen.git. Have you thought about how to handle such cases? 

We probably don't want to spam Linux and Qemu lists with results from a test bot. 
And we want to minimise false positives. Some patches may be identifiable through subject lines (e.g. OSSTEST in subject lines)

Lars



[-- Attachment #1.2: Type: text/html, Size: 9409 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply

* [PATCH] ASoC: meson: axg-spdifout: select SND_PCM_IEC958
From: Arnd Bergmann @ 2018-07-24  9:36 UTC (permalink / raw)
  To: Mark Brown
  Cc: Arnd Bergmann, Liam Girdwood, Carlo Caione, Kevin Hilman,
	Jerome Brunet, alsa-devel, linux-arm-kernel, linux-amlogic,
	linux-kernel

When CONFIG_SND_PCM_IEC958 is disabled, we get a link error for the
new driver:

sound/soc/meson/axg-spdifout.o: In function `axg_spdifout_hw_params':
axg-spdifout.c:(.text+0x650): undefined reference to `snd_pcm_create_iec958_consumer_hw_params'

The other users use 'select', so we should do the same here.

Fixes: 53eb4b7aaa04 ("ASoC: meson: add axg spdif output")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 sound/soc/meson/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/meson/Kconfig b/sound/soc/meson/Kconfig
index 4cf93c05a982..8af8bc358a90 100644
--- a/sound/soc/meson/Kconfig
+++ b/sound/soc/meson/Kconfig
@@ -56,6 +56,7 @@ config SND_MESON_AXG_SOUND_CARD
 
 config SND_MESON_AXG_SPDIFOUT
 	tristate "Amlogic AXG SPDIF Output Support"
+	select SND_PCM_IEC958
 	imply SND_SOC_SPDIF
 	help
 	  Select Y or M to add support for SPDIF output serializer embedded
-- 
2.18.0


^ permalink raw reply related

* [PATCH] arm64: fix ACPI dependencies
From: Rafael J. Wysocki @ 2018-07-24  9:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180724093345.1575921-1-arnd@arndb.de>

On Tue, Jul 24, 2018 at 11:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> Kconfig reports a warning on x86 builds after the ARM64 dependency
> was added.
>
> drivers/acpi/Kconfig:6:error: recursive dependency detected!
> drivers/acpi/Kconfig:6:       symbol ACPI depends on EFI
>
> This rephrases the dependency to keep the ARM64 details out of the
> shared Kconfig file, so Kconfig no longer gets confused by it.
>
> Fixes: 5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm64/Kconfig   | 1 +
>  drivers/acpi/Kconfig | 5 ++++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index cdcaa6a798b2..2f987a938405 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1267,6 +1267,7 @@ config EFI
>         bool "UEFI runtime support"
>         depends on OF && !CPU_BIG_ENDIAN
>         depends on KERNEL_MODE_NEON
> +       select ARCH_SUPPORTS_ACPI
>         select LIBFDT
>         select UCS2_STRING
>         select EFI_PARAMS_FROM_FDT
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index a8da730fabc6..0cda51c5d433 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -6,7 +6,7 @@
>  menuconfig ACPI
>         bool "ACPI (Advanced Configuration and Power Interface) Support"
>         depends on !IA64_HP_SIM
> -       depends on IA64 || X86 || (ARM64 && EFI)
> +       depends on IA64 || X86 || ARCH_SUPPORTS_ACPI

That doesn't look particularly consistent to me.

It should be either "depends on ARCH_SUPPORTS_ACPI" alone or mention
ARM64 somehow IMO

>         depends on PCI
>         select PNP
>         default y if (IA64 || X86)
> @@ -41,6 +41,9 @@ menuconfig ACPI
>           <http://www.acpi.info>
>           <http://www.uefi.org/acpi/specs>
>
> +config ARCH_SUPPORTS_ACPI
> +       bool
> +
>  if ACPI
>
>  config ACPI_LEGACY_TABLES_LOOKUP
> --

^ permalink raw reply

* Re: [PATCH] arm64: fix ACPI dependencies
From: Rafael J. Wysocki @ 2018-07-24  9:37 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Catalin Marinas, Will Deacon, Rafael J. Wysocki, Len Brown,
	AKASHI Takahiro, Ard Biesheuvel, Mark Rutland, Marc Zyngier,
	Linux ARM, Linux Kernel Mailing List, ACPI Devel Maling List
In-Reply-To: <20180724093345.1575921-1-arnd@arndb.de>

On Tue, Jul 24, 2018 at 11:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> Kconfig reports a warning on x86 builds after the ARM64 dependency
> was added.
>
> drivers/acpi/Kconfig:6:error: recursive dependency detected!
> drivers/acpi/Kconfig:6:       symbol ACPI depends on EFI
>
> This rephrases the dependency to keep the ARM64 details out of the
> shared Kconfig file, so Kconfig no longer gets confused by it.
>
> Fixes: 5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm64/Kconfig   | 1 +
>  drivers/acpi/Kconfig | 5 ++++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index cdcaa6a798b2..2f987a938405 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1267,6 +1267,7 @@ config EFI
>         bool "UEFI runtime support"
>         depends on OF && !CPU_BIG_ENDIAN
>         depends on KERNEL_MODE_NEON
> +       select ARCH_SUPPORTS_ACPI
>         select LIBFDT
>         select UCS2_STRING
>         select EFI_PARAMS_FROM_FDT
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index a8da730fabc6..0cda51c5d433 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -6,7 +6,7 @@
>  menuconfig ACPI
>         bool "ACPI (Advanced Configuration and Power Interface) Support"
>         depends on !IA64_HP_SIM
> -       depends on IA64 || X86 || (ARM64 && EFI)
> +       depends on IA64 || X86 || ARCH_SUPPORTS_ACPI

That doesn't look particularly consistent to me.

It should be either "depends on ARCH_SUPPORTS_ACPI" alone or mention
ARM64 somehow IMO

>         depends on PCI
>         select PNP
>         default y if (IA64 || X86)
> @@ -41,6 +41,9 @@ menuconfig ACPI
>           <http://www.acpi.info>
>           <http://www.uefi.org/acpi/specs>
>
> +config ARCH_SUPPORTS_ACPI
> +       bool
> +
>  if ACPI
>
>  config ACPI_LEGACY_TABLES_LOOKUP
> --

^ permalink raw reply

* [PATCH] ASoC: meson: axg-spdifout: select SND_PCM_IEC958
From: Arnd Bergmann @ 2018-07-24  9:36 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, Arnd Bergmann, Kevin Hilman, Liam Girdwood,
	linux-kernel, Carlo Caione, linux-amlogic, linux-arm-kernel,
	Jerome Brunet

When CONFIG_SND_PCM_IEC958 is disabled, we get a link error for the
new driver:

sound/soc/meson/axg-spdifout.o: In function `axg_spdifout_hw_params':
axg-spdifout.c:(.text+0x650): undefined reference to `snd_pcm_create_iec958_consumer_hw_params'

The other users use 'select', so we should do the same here.

Fixes: 53eb4b7aaa04 ("ASoC: meson: add axg spdif output")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 sound/soc/meson/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/meson/Kconfig b/sound/soc/meson/Kconfig
index 4cf93c05a982..8af8bc358a90 100644
--- a/sound/soc/meson/Kconfig
+++ b/sound/soc/meson/Kconfig
@@ -56,6 +56,7 @@ config SND_MESON_AXG_SOUND_CARD
 
 config SND_MESON_AXG_SPDIFOUT
 	tristate "Amlogic AXG SPDIF Output Support"
+	select SND_PCM_IEC958
 	imply SND_SOC_SPDIF
 	help
 	  Select Y or M to add support for SPDIF output serializer embedded
-- 
2.18.0

^ permalink raw reply related

* Re: [PATCH v2] f2fs: clear victim_secmap when section has full valid blocks
From: Chao Yu @ 2018-07-24  9:36 UTC (permalink / raw)
  To: Yunlong Song, jaegeuk, chao, yunlong.song
  Cc: miaoxie, bintian.wang, shengyong1, heyunlei, linux-f2fs-devel,
	linux-kernel
In-Reply-To: <1532424442-9867-1-git-send-email-yunlong.song@huawei.com>

On 2018/7/24 17:27, Yunlong Song wrote:
> Without this patch, f2fs only clears victim_secmap when it finds out
> that the section has no valid blocks at all, but forgets to clear the
> victim_secmap when the whole section has full valid blocks.

Look this patch again, I have a question, why bggc selected section can
get back to full state?

Thanks,

> 
> Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
> ---
>  fs/f2fs/segment.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index cfff7cf..0a79554 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -776,7 +776,8 @@ static void __remove_dirty_segment(struct f2fs_sb_info *sbi, unsigned int segno,
>  		if (test_and_clear_bit(segno, dirty_i->dirty_segmap[t]))
>  			dirty_i->nr_dirty[t]--;
>  
> -		if (get_valid_blocks(sbi, segno, true) == 0)
> +		if (get_valid_blocks(sbi, segno, true) == 0 ||
> +			get_valid_blocks(sbi, segno, true) == BLKS_PER_SEC(sbi))
>  			clear_bit(GET_SEC_FROM_SEG(sbi, segno),
>  						dirty_i->victim_secmap);
>  	}
> 


^ permalink raw reply

* [PATCH] ASoC: meson: axg-spdifout: select SND_PCM_IEC958
From: Arnd Bergmann @ 2018-07-24  9:36 UTC (permalink / raw)
  To: linux-arm-kernel

When CONFIG_SND_PCM_IEC958 is disabled, we get a link error for the
new driver:

sound/soc/meson/axg-spdifout.o: In function `axg_spdifout_hw_params':
axg-spdifout.c:(.text+0x650): undefined reference to `snd_pcm_create_iec958_consumer_hw_params'

The other users use 'select', so we should do the same here.

Fixes: 53eb4b7aaa04 ("ASoC: meson: add axg spdif output")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 sound/soc/meson/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/meson/Kconfig b/sound/soc/meson/Kconfig
index 4cf93c05a982..8af8bc358a90 100644
--- a/sound/soc/meson/Kconfig
+++ b/sound/soc/meson/Kconfig
@@ -56,6 +56,7 @@ config SND_MESON_AXG_SOUND_CARD
 
 config SND_MESON_AXG_SPDIFOUT
 	tristate "Amlogic AXG SPDIF Output Support"
+	select SND_PCM_IEC958
 	imply SND_SOC_SPDIF
 	help
 	  Select Y or M to add support for SPDIF output serializer embedded
-- 
2.18.0

^ permalink raw reply related

* [PATCH] ASoC: meson: axg-spdifout: select SND_PCM_IEC958
From: Arnd Bergmann @ 2018-07-24  9:36 UTC (permalink / raw)
  To: linus-amlogic

When CONFIG_SND_PCM_IEC958 is disabled, we get a link error for the
new driver:

sound/soc/meson/axg-spdifout.o: In function `axg_spdifout_hw_params':
axg-spdifout.c:(.text+0x650): undefined reference to `snd_pcm_create_iec958_consumer_hw_params'

The other users use 'select', so we should do the same here.

Fixes: 53eb4b7aaa04 ("ASoC: meson: add axg spdif output")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 sound/soc/meson/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/meson/Kconfig b/sound/soc/meson/Kconfig
index 4cf93c05a982..8af8bc358a90 100644
--- a/sound/soc/meson/Kconfig
+++ b/sound/soc/meson/Kconfig
@@ -56,6 +56,7 @@ config SND_MESON_AXG_SOUND_CARD
 
 config SND_MESON_AXG_SPDIFOUT
 	tristate "Amlogic AXG SPDIF Output Support"
+	select SND_PCM_IEC958
 	imply SND_SOC_SPDIF
 	help
 	  Select Y or M to add support for SPDIF output serializer embedded
-- 
2.18.0

^ permalink raw reply related

* Re: [PATCH v2] f2fs: clear victim_secmap when section has full valid blocks
From: Chao Yu @ 2018-07-24  9:36 UTC (permalink / raw)
  To: Yunlong Song, jaegeuk, chao, yunlong.song
  Cc: miaoxie, bintian.wang, shengyong1, heyunlei, linux-f2fs-devel,
	linux-kernel
In-Reply-To: <1532424442-9867-1-git-send-email-yunlong.song@huawei.com>

On 2018/7/24 17:27, Yunlong Song wrote:
> Without this patch, f2fs only clears victim_secmap when it finds out
> that the section has no valid blocks at all, but forgets to clear the
> victim_secmap when the whole section has full valid blocks.

Look this patch again, I have a question, why bggc selected section can
get back to full state?

Thanks,

> 
> Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
> ---
>  fs/f2fs/segment.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index cfff7cf..0a79554 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -776,7 +776,8 @@ static void __remove_dirty_segment(struct f2fs_sb_info *sbi, unsigned int segno,
>  		if (test_and_clear_bit(segno, dirty_i->dirty_segmap[t]))
>  			dirty_i->nr_dirty[t]--;
>  
> -		if (get_valid_blocks(sbi, segno, true) == 0)
> +		if (get_valid_blocks(sbi, segno, true) == 0 ||
> +			get_valid_blocks(sbi, segno, true) == BLKS_PER_SEC(sbi))
>  			clear_bit(GET_SEC_FROM_SEG(sbi, segno),
>  						dirty_i->victim_secmap);
>  	}
> 

^ permalink raw reply

* [LTP] [PATCH v2 1/1] tst_test.sh: Add test cmd helper tst_test_cmds()
From: Cyril Hrubis @ 2018-07-24  9:35 UTC (permalink / raw)
  To: ltp
In-Reply-To: <20180423091706.24154-1-pvorel@suse.cz>

Hi!
> + tst_cmd_available()
> 
> tst_test_cmds() is meant to be a check just for a particular test.
> Works like tst_check_cmds(), but instead of tst_brk() calls tst_res().

Hmm looking at this after a while I would expect the tst_test_cmds() to
exit the test while tst_check_cmds() to return a value, the question is
if this is worth of the work of renaming the current uses...

> tst_cmd_available() helper can handle cases when command shell builtin
> is not available (e.g. Busybox).
>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> Hi,
> 
> if you don't like using which or testing with 127 exit code in
> tst_cmd_available() (or if you don't like tst_cmd_available()), I
> can remove it.

This looks fine to me.

>  Locating kernel modules
>  +++++++++++++++++++++++
>  
> diff --git a/testcases/lib/tst_test.sh b/testcases/lib/tst_test.sh
> index 8d49d34b6..b3e803e05 100644
> --- a/testcases/lib/tst_test.sh
> +++ b/testcases/lib/tst_test.sh
> @@ -201,12 +201,37 @@ tst_mkfs()
>  	ROD_SILENT mkfs.$fs_type $fs_opts $device
>  }
>  
> +tst_cmd_available()
> +{
> +	if type command > /dev/null 2>&1; then
> +		command -v $1 > /dev/null 2>&1 || return 1
> +	else
> +		which $1 > /dev/null 2>&1
> +		if [ $? -eq 0 ]; then
> +			return 0
> +		elif [ $? -eq 127 ]; then
> +			tst_brk TCONF "missing which command"
> +		else
> +			return 1
> +		fi
> +	fi
> +}
> +
>  tst_check_cmds()
>  {
>  	local cmd
>  	for cmd in $*; do

	BTW you can just write 'for cmd; do' here since the default
	array to loop over are the parameters passed to a function.

> -		if ! command -v $cmd > /dev/null 2>&1; then
> -			tst_brk TCONF "'$cmd' not found"
> +		tst_cmd_available $cmd || tst_brk TCONF "'$cmd' not found"
> +	done
> +}
> +
> +tst_test_cmds()
> +{
> +	local cmd
> +	for cmd in $*; do
> +		if ! tst_cmd_available $cmd; then
> +			tst_res TCONF "'$cmd' not found"
> +			return 1
>  		fi
>  	done

Can we add explicit return 0 here?

Other than that it's fine.

>  }
> -- 
> 2.16.3
> 

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply

* [PATCH] f2fs: fix 32-bit format string warning
From: Arnd Bergmann @ 2018-07-24  9:34 UTC (permalink / raw)
  To: Jaegeuk Kim, Chao Yu
  Cc: Arnd Bergmann, Eric Biggers, Yunlei He, linux-f2fs-devel,
	linux-kernel

On 32-bit targets, size_t is often 'unsigned int', so printing it as %lu
causes a warning:

fs/f2fs/inode.c: In function 'sanity_check_inode':
fs/f2fs/inode.c:247:4: error: format '%lu' expects argument of type 'long unsigned int', but argument 7 has type 'unsigned int' [-Werror=format=]

The correct format string is %zu.

Fixes: ba3a252d3367 ("f2fs: fix to do sanity check with i_extra_isize")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 fs/f2fs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 3fe63b0c7325..4fd339fd3ff2 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -245,7 +245,7 @@ static bool sanity_check_inode(struct inode *inode, struct page *node_page)
 		set_sbi_flag(sbi, SBI_NEED_FSCK);
 		f2fs_msg(sbi->sb, KERN_WARNING,
 			"%s: inode (ino=%lx) has corrupted i_extra_isize: %d, "
-			"max: %lu",
+			"max: %zu",
 			__func__, inode->i_ino, fi->i_extra_isize,
 			F2FS_TOTAL_EXTRA_ATTR_SIZE);
 		return false;
-- 
2.18.0


^ permalink raw reply related

* [PATCH] f2fs: fix 32-bit format string warning
From: Arnd Bergmann @ 2018-07-24  9:34 UTC (permalink / raw)
  To: Jaegeuk Kim, Chao Yu
  Cc: linux-f2fs-devel, linux-kernel, Arnd Bergmann, Eric Biggers

On 32-bit targets, size_t is often 'unsigned int', so printing it as %lu
causes a warning:

fs/f2fs/inode.c: In function 'sanity_check_inode':
fs/f2fs/inode.c:247:4: error: format '%lu' expects argument of type 'long unsigned int', but argument 7 has type 'unsigned int' [-Werror=format=]

The correct format string is %zu.

Fixes: ba3a252d3367 ("f2fs: fix to do sanity check with i_extra_isize")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 fs/f2fs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 3fe63b0c7325..4fd339fd3ff2 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -245,7 +245,7 @@ static bool sanity_check_inode(struct inode *inode, struct page *node_page)
 		set_sbi_flag(sbi, SBI_NEED_FSCK);
 		f2fs_msg(sbi->sb, KERN_WARNING,
 			"%s: inode (ino=%lx) has corrupted i_extra_isize: %d, "
-			"max: %lu",
+			"max: %zu",
 			__func__, inode->i_ino, fi->i_extra_isize,
 			F2FS_TOTAL_EXTRA_ATTR_SIZE);
 		return false;
-- 
2.18.0


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

^ permalink raw reply related

* Re: automation: Creating a patchwork instance to improve pre-commit build testing
From: Jan Beulich @ 2018-07-24  9:34 UTC (permalink / raw)
  To: Wei Liu
  Cc: Lars Kurth, Iurii Artemenko, Doug Goldstein, Minios-devel,
	committers, xen-devel, Matt Spencer
In-Reply-To: <20180724092430.puacbfkbimdm5anz@citrix.com>

>>> On 24.07.18 at 11:24, <wei.liu2@citrix.com> wrote:
> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
>> >>> On 23.07.18 at 18:40, <lars.kurth@citrix.com> wrote:
>> > # How does this impact me?
>> > The contribution workflow is *not* impacted by this change, but once up and 
> 
>> > running the following will happen once you post a patch or patch series to 
>> > xen-devel:
>> > * Patchwork will take patch series from the mailing list and applies it
>> > * CI/DC testing is triggered
>> > * A test report will be sent as a mail to the patch or the series (aka the 00 patch of the series)
>> > 
>> > This does mean though that series which do not build or show other issues, 
>> > will likely not be reviewed until the tests pass. This would lessen the 
>> > burden on reviewers, as they will know whether the code submitted builds on a 
>> > wide array of environments. 
>> 
>> So how are dependencies between series intended to be dealt with? It
>> is not uncommon for someone to say "applies only on top of xyz". The
>> implication of "will likely not be reviewed until the tests pass" seems
>> unsuitable to me in such a case.
>> 
> 
> We have been asking everyone to rebase to staging before posting a new
> version for a long time.  It is natural for the bot to assume that
> everything should apply on top of staging. That would provide most value
> to the community.
> 
> For special cases like you just mention, we should aim to provide
> mechanisms to manually appoint a branch to be tested.

I'm afraid I disagree again: Tools used should not be dictated. I'm
using quilt, not git for my work, and hence I don't maintain any
branches anywhere.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply

* next-20180723 build: 2 failures 11 warnings (next-20180723)
From: Matt Hart @ 2018-07-24  9:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAH+k93GQRKO8s+0qkSH+d_2GkapMAp8C776Q4bZZnL37M5MBCw@mail.gmail.com>

On 24 July 2018 at 10:32, Matt Hart <matthew.hart@linaro.org> wrote:
>
>
>
> On 24 July 2018 at 10:16, Will Deacon <will.deacon@arm.com> wrote:
>>
>> On Mon, Jul 23, 2018 at 07:11:50PM +0100, Mark Brown wrote:
>> > On Mon, Jul 23, 2018 at 05:59:12PM +0100, Build bot for Mark Brown wrote:
>> >
>> > Today's -next fails to build an arm64 allmodconfig with:
>> >
>> > >     arm64-allmodconfig
>> > > ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
>> >
>> > using
>> >
>> >    aarch64-linux-gnu-gcc (Linaro GCC 5.3-2016.05) 5.3.1 20160412
>> >
>> > however it builds perfectly fine with
>> >
>> >    aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>> >
>> > which honestly seems like a sensible and worthwhile upgrade at this
>> > point anyway given that it's a year and a half old so I'm going to do
>> > that for my builder (perhaps even jump on a newer version) but it seemed
>> > worth highlighting in case this is considered undesirable.  A similar
>> > issue is hitting on KernelCI, we should probably look at upgrading the
>> > toolchain there too.
>>
>> Hmm, it looks to me like this comes about because xen/privcmd.c is being
>> built as a module, but contains a call to set_pte_at() with a special pte:
>>
>>         pte_t pte = pte_mkspecial(pfn_pte(page_to_pfn(page), r->prot));
>>
>>         set_pte_at(r->mm, addr, ptep, pte);
>>
>> which on arm64 contains:
>>
>>         if (pte_present(pte) && pte_user_exec(pte) && !pte_special(pte))
>>                 __sync_icache_dcache(pte);
>>
>> so GCC 6 can optimise away the call to the non-exported symbol, but GCC 5
>> has trouble.
>>
>> What I don't understand is why this suddenly cropped up. Did GCC 5 build
>> linux-next arm64 allmodconfig last week?
>
>
> KernelCI uses GCC5 for ARM64 and xen-privcmd.ko has been broken in linux-next (and mainline) allmodconfig for a long time

Bloody gmail and it's HTML mean't this didn't get delivered to
linux-arm-kernel list. Resent.

>
>>
>>
>> Cheers,
>>
>> Will
>
>

^ permalink raw reply

* Re: next-20180723 build: 2 failures 11 warnings (next-20180723)
From: Matt Hart @ 2018-07-24  9:34 UTC (permalink / raw)
  To: Will Deacon
  Cc: linaro-kernel, Kernel Build Reports Mailman List, Catalin Marinas,
	Kevin Hilman, Mark Brown, linux-next, linux-arm-kernel
In-Reply-To: <CAH+k93GQRKO8s+0qkSH+d_2GkapMAp8C776Q4bZZnL37M5MBCw@mail.gmail.com>

On 24 July 2018 at 10:32, Matt Hart <matthew.hart@linaro.org> wrote:
>
>
>
> On 24 July 2018 at 10:16, Will Deacon <will.deacon@arm.com> wrote:
>>
>> On Mon, Jul 23, 2018 at 07:11:50PM +0100, Mark Brown wrote:
>> > On Mon, Jul 23, 2018 at 05:59:12PM +0100, Build bot for Mark Brown wrote:
>> >
>> > Today's -next fails to build an arm64 allmodconfig with:
>> >
>> > >     arm64-allmodconfig
>> > > ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
>> >
>> > using
>> >
>> >    aarch64-linux-gnu-gcc (Linaro GCC 5.3-2016.05) 5.3.1 20160412
>> >
>> > however it builds perfectly fine with
>> >
>> >    aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>> >
>> > which honestly seems like a sensible and worthwhile upgrade at this
>> > point anyway given that it's a year and a half old so I'm going to do
>> > that for my builder (perhaps even jump on a newer version) but it seemed
>> > worth highlighting in case this is considered undesirable.  A similar
>> > issue is hitting on KernelCI, we should probably look at upgrading the
>> > toolchain there too.
>>
>> Hmm, it looks to me like this comes about because xen/privcmd.c is being
>> built as a module, but contains a call to set_pte_at() with a special pte:
>>
>>         pte_t pte = pte_mkspecial(pfn_pte(page_to_pfn(page), r->prot));
>>
>>         set_pte_at(r->mm, addr, ptep, pte);
>>
>> which on arm64 contains:
>>
>>         if (pte_present(pte) && pte_user_exec(pte) && !pte_special(pte))
>>                 __sync_icache_dcache(pte);
>>
>> so GCC 6 can optimise away the call to the non-exported symbol, but GCC 5
>> has trouble.
>>
>> What I don't understand is why this suddenly cropped up. Did GCC 5 build
>> linux-next arm64 allmodconfig last week?
>
>
> KernelCI uses GCC5 for ARM64 and xen-privcmd.ko has been broken in linux-next (and mainline) allmodconfig for a long time

Bloody gmail and it's HTML mean't this didn't get delivered to
linux-arm-kernel list. Resent.

>
>>
>>
>> Cheers,
>>
>> Will
>
>

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.