* Re: [Qemu-devel] [PATCH qemu v2] vfio/spapr: Allow backing bigger guest IOMMU pages with smaller physical pages
From: Alexey Kardashevskiy @ 2018-07-24 3:56 UTC (permalink / raw)
To: David Gibson; +Cc: qemu-devel, qemu-ppc, Alex Williamson
In-Reply-To: <20180723031142.GA6830@umbus.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 5377 bytes --]
On 23/07/2018 13:11, David Gibson wrote:
> On Wed, Jun 20, 2018 at 07:10:12PM +1000, Alexey Kardashevskiy wrote:
>> At the moment the PPC64/pseries guest only supports 4K/64K/16M IOMMU
>> pages and POWER8 CPU supports the exact same set of page size so
>> so far things worked fine.
>>
>> However POWER9 supports different set of sizes - 4K/64K/2M/1G and
>> the last two - 2M and 1G - are not even allowed in the paravirt interface
>> (RTAS DDW) so we always end up using 64K IOMMU pages, although we could
>> back guest's 16MB IOMMU pages with 2MB pages on the host.
>>
>> This stores the supported host IOMMU page sizes in VFIOContainer and uses
>> this later when creating a new DMA window. This uses the system page size
>> (64k normally, 2M/16M/1G if hugepages used) as the upper limit of
>> the IOMMU pagesize.
>>
>> This changes the type of @pagesize to uint64_t as this is what
>> memory_region_iommu_get_min_page_size() returns and clz64() takes.
>>
>> There should be no behavioral changes on platforms other than pseries.
>> The guest will keep using the IOMMU page size selected by the PHB pagesize
>> property as this only changes the underlying hardware TCE table
>> granularity.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v2:
>> * fixed biggest but smaller page size calculation
>> * limit IOMMU pagesize to the system pagesize
>
> Sorry, this fell of my radar for a bit.
>
> I've now applied it to ppc-for-3.1.
Alex might object that as it does not have his "rb" ;)
>
>> ---
>> include/hw/vfio/vfio-common.h | 1 +
>> hw/vfio/common.c | 3 +++
>> hw/vfio/spapr.c | 21 ++++++++++++++++++++-
>> 3 files changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
>> index a903692..c20524d 100644
>> --- a/include/hw/vfio/vfio-common.h
>> +++ b/include/hw/vfio/vfio-common.h
>> @@ -73,6 +73,7 @@ typedef struct VFIOContainer {
>> unsigned iommu_type;
>> int error;
>> bool initialized;
>> + unsigned long pgsizes;
>> /*
>> * This assumes the host IOMMU can support only a single
>> * contiguous IOVA window. We may need to generalize that in
>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>> index fb396cf..40f0356 100644
>> --- a/hw/vfio/common.c
>> +++ b/hw/vfio/common.c
>> @@ -1108,6 +1108,7 @@ static int vfio_connect_container(VFIOGroup *group, AddressSpace *as,
>> info.iova_pgsizes = 4096;
>> }
>> vfio_host_win_add(container, 0, (hwaddr)-1, info.iova_pgsizes);
>> + container->pgsizes = info.iova_pgsizes;
>> } else if (ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_SPAPR_TCE_IOMMU) ||
>> ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_SPAPR_TCE_v2_IOMMU)) {
>> struct vfio_iommu_spapr_tce_info info;
>> @@ -1172,6 +1173,7 @@ static int vfio_connect_container(VFIOGroup *group, AddressSpace *as,
>> }
>>
>> if (v2) {
>> + container->pgsizes = info.ddw.pgsizes;
>> /*
>> * There is a default window in just created container.
>> * To make region_add/del simpler, we better remove this
>> @@ -1186,6 +1188,7 @@ static int vfio_connect_container(VFIOGroup *group, AddressSpace *as,
>> }
>> } else {
>> /* The default table uses 4K pages */
>> + container->pgsizes = 0x1000;
>> vfio_host_win_add(container, info.dma32_window_start,
>> info.dma32_window_start +
>> info.dma32_window_size - 1,
>> diff --git a/hw/vfio/spapr.c b/hw/vfio/spapr.c
>> index 259397c..becf71a 100644
>> --- a/hw/vfio/spapr.c
>> +++ b/hw/vfio/spapr.c
>> @@ -15,6 +15,7 @@
>>
>> #include "hw/vfio/vfio-common.h"
>> #include "hw/hw.h"
>> +#include "exec/ram_addr.h"
>> #include "qemu/error-report.h"
>> #include "trace.h"
>>
>> @@ -144,9 +145,27 @@ int vfio_spapr_create_window(VFIOContainer *container,
>> {
>> int ret;
>> IOMMUMemoryRegion *iommu_mr = IOMMU_MEMORY_REGION(section->mr);
>> - unsigned pagesize = memory_region_iommu_get_min_page_size(iommu_mr);
>> + uint64_t pagesize = memory_region_iommu_get_min_page_size(iommu_mr);
>> unsigned entries, pages;
>> struct vfio_iommu_spapr_tce_create create = { .argsz = sizeof(create) };
>> + long systempagesize = qemu_getrampagesize();
>> +
>> + /*
>> + * The host might not support the guest supported IOMMU page size,
>> + * so we will use smaller physical IOMMU pages to back them.
>> + */
>> + if (pagesize > systempagesize) {
>> + pagesize = systempagesize;
>> + }
>> + pagesize = 1ULL << (63 - clz64(container->pgsizes &
>> + (pagesize | (pagesize - 1))));
>> + if (!pagesize) {
>> + error_report("Host doesn't support page size 0x%"PRIx64
>> + ", the supported mask is 0x%lx",
>> + memory_region_iommu_get_min_page_size(iommu_mr),
>> + container->pgsizes);
>> + return -EINVAL;
>> + }
>>
>> /*
>> * FIXME: For VFIO iommu types which have KVM acceleration to
>
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] phy: Add driver for Cadence MHDP DisplayPort SD0801 PHY
From: Kishon Vijay Abraham I @ 2018-07-24 3:56 UTC (permalink / raw)
To: Scott Telford, linux-kernel, linux-arm-kernel, dkos
In-Reply-To: <1532090477-15559-1-git-send-email-stelford@cadence.com>
Hi,
On Friday 20 July 2018 06:11 PM, Scott Telford wrote:
> Add driver for the Cadence SD0801 "Torrent" PHY used with the Cadence MHDP
> DisplayPort Tx controller.
>
> Integration with the MHDP driver will be the subject of another commit.
>
> Signed-off-by: Scott Telford <stelford@cadence.com>
> ---
> .../devicetree/bindings/phy/phy-cadence-dp.txt | 28 ++
> drivers/phy/Kconfig | 1 +
> drivers/phy/Makefile | 1 +
> drivers/phy/cadence/Kconfig | 10 +
> drivers/phy/cadence/Makefile | 1 +
> drivers/phy/cadence/phy-cadence-dp.c | 436 +++++++++++++++++++++
> drivers/phy/cadence/phy-cadence-dp.h | 117 ++++++
> 7 files changed, 594 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
> create mode 100644 drivers/phy/cadence/Kconfig
> create mode 100644 drivers/phy/cadence/Makefile
> create mode 100644 drivers/phy/cadence/phy-cadence-dp.c
> create mode 100644 drivers/phy/cadence/phy-cadence-dp.h
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-dp.txt b/Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
> new file mode 100644
> index 0000000..8de0526
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
> @@ -0,0 +1,28 @@
> +Cadence MHDP DisplayPort SD0801 PHY binding
> +===========================================
> +
> +This binding describes the Cadence SD0801 PHY hardware included with
> +the Cadence MHDP DisplayPort controller.
> +
> +-------------------------------------------------------------------------------
> +Required properties (controller (parent) node):
> +- compatible : Should be "cdns,dp-phy"
> +- reg : Defines the following sets of registers in the parent
> + mhdp device:
> + - Offset of the DPTX PHY configuration registers
> + - Offset of the SD0801 PHY configuration registers
> +- num_lanes : Number of DisplayPort lanes to use (1, 2 or 4)
> +- max_bit_rate : Maximum DisplayPort link bit rate to use, in Mbps (2160,
> + 2430, 2700, 3240, 4320, 5400 or 8100)
> +- #phy-cells : from the generic PHY bindings, must be 0.
> +-------------------------------------------------------------------------------
> +
> +Example:
> + dp_phy: phy@f0fb030a00 {
> + compatible = "cdns,dp-phy";
> + reg = <0xf0 0xfb030a00 0x0 0x00000040>,
> + <0xf0 0xfb500000 0x0 0x00100000>;
> + num_lanes = <4>;
> + max_bit_rate = <8100>;
> + #phy-cells = <0>;
> + };
dt bindings should be a separate patch
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 5c8d452..cc47f85 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -43,6 +43,7 @@ config PHY_XGENE
> source "drivers/phy/allwinner/Kconfig"
> source "drivers/phy/amlogic/Kconfig"
> source "drivers/phy/broadcom/Kconfig"
> +source "drivers/phy/cadence/Kconfig"
> source "drivers/phy/hisilicon/Kconfig"
> source "drivers/phy/lantiq/Kconfig"
> source "drivers/phy/marvell/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 84e3bd9..ba48acd 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_RENESAS) += renesas/
> obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-y += broadcom/ \
> + cadence/ \
> hisilicon/ \
> marvell/ \
> motorola/ \
> diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
> new file mode 100644
> index 0000000..57fff7d
> --- /dev/null
> +++ b/drivers/phy/cadence/Kconfig
> @@ -0,0 +1,10 @@
> +#
> +# Phy driver for Cadence MHDP DisplayPort controller
> +#
> +config PHY_CADENCE_DP
> + tristate "Cadence MHDP DisplayPort PHY driver"
> + depends on OF
> + depends on HAS_IOMEM
> + select GENERIC_PHY
> + help
> + Support for Cadence MHDP DisplayPort PHY.
> diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
> new file mode 100644
> index 0000000..e5b0a11
> --- /dev/null
> +++ b/drivers/phy/cadence/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_PHY_CADENCE_DP) += phy-cadence-dp.o
> diff --git a/drivers/phy/cadence/phy-cadence-dp.c b/drivers/phy/cadence/phy-cadence-dp.c
> new file mode 100644
> index 0000000..c1cf89b
> --- /dev/null
> +++ b/drivers/phy/cadence/phy-cadence-dp.c
> @@ -0,0 +1,436 @@
> +/*
> + * Cadence MHDP DisplayPort SD0801 PHY driver.
> + *
> + * Copyright 2018 Cadence Design Systems, Inc.
> + *
> + * SPDX-License-Identifier: GPL-2.0-only
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/phy/phy.h>
> +#include "phy-cadence-dp.h"
If phy-cadence-dp.h is not going to be used in multiple files, then all the
definitions should be added here and the .h can removed.
> +
> +
> +static const struct phy_ops cdns_dp_phy_ops = {
> + .init = cdns_dp_phy_init,
> + .owner = THIS_MODULE,
> +};
> +
> +static const struct of_device_id cdns_dp_phy_of_match[] = {
> + {
> + .compatible = "cdns,dp-phy"
> + },
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(of, cdns_dp_phy_of_match);
> +
> +static int cdns_dp_phy_probe(struct platform_device *pdev)
The file organization is slightly different. Can we follow what other drivers
do by having the probe in the bottom of the file and other functions above that?
> +{
> + struct resource *regs;
> + struct cdns_dp_phy *cdns_phy;
> + struct device *dev = &pdev->dev;
> + struct phy_provider *phy_provider;
> + struct phy *phy;
> + int err;
> +
> + cdns_phy = devm_kzalloc(dev, sizeof(*cdns_phy), GFP_KERNEL);
> + if (!cdns_phy)
> + return -ENOMEM;
> +
> + cdns_phy->dev = &pdev->dev;
> +
> + phy = devm_phy_create(dev, NULL, &cdns_dp_phy_ops);
> + if (IS_ERR(phy)) {
> + dev_err(dev, "failed to create DisplayPort PHY\n");
> + return PTR_ERR(phy);
> + }
> +
> + regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + cdns_phy->base = devm_ioremap_resource(&pdev->dev, regs);
> + if (IS_ERR(cdns_phy->base))
> + return PTR_ERR(cdns_phy->base);
> +
> + regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + cdns_phy->sd_base = devm_ioremap_resource(&pdev->dev, regs);
> + if (IS_ERR(cdns_phy->sd_base))
> + return PTR_ERR(cdns_phy->sd_base);
> +
> + err = device_property_read_u32(dev, "num_lanes",
> + &(cdns_phy->num_lanes));
> + if (err)
> + cdns_phy->num_lanes = DEFAULT_NUM_LANES;
> +
> + switch (cdns_phy->num_lanes) {
> + case 1:
> + case 2:
> + case 4:
> + /* valid number of lanes */
> + break;
> + default:
> + dev_err(dev, "unsupported number of lanes: %d\n",
> + cdns_phy->num_lanes);
> + return -EINVAL;
> + }
> +
> + err = device_property_read_u32(dev, "max_bit_rate",
> + &(cdns_phy->max_bit_rate));
> + if (err)
> + cdns_phy->max_bit_rate = DEFAULT_MAX_BIT_RATE;
> +
> + switch (cdns_phy->max_bit_rate) {
> + case 2160:
> + case 2430:
> + case 2700:
> + case 3240:
> + case 4320:
> + case 5400:
> + case 8100:
> + /* valid bit rate */
> + break;
> + default:
> + dev_err(dev, "unsupported max bit rate: %dMbps\n",
> + cdns_phy->max_bit_rate);
> + return -EINVAL;
> + }
> +
> + phy_set_drvdata(phy, cdns_phy);
> +
> + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> +
> + dev_info(dev, "%d lanes, max bit rate %d.%03d Gbps\n",
> + cdns_phy->num_lanes,
> + cdns_phy->max_bit_rate / 1000,
> + cdns_phy->max_bit_rate % 1000);
> +
> + return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +
> +static int cdns_dp_phy_init(struct phy *phy)
> +{
> + unsigned char lane_bits;
> +
> + struct cdns_dp_phy *cdns_phy = phy_get_drvdata(phy);
> +
> + writel(0x0003, cdns_phy->base + PHY_AUX_CTRL); /* enable AUX */
> +
> + /* PHY PMA registers configuration function */
> + cdns_dp_phy_pma_cfg(cdns_phy);
> +
> + /* Set lines power state to A0
> + * Set lines pll clk enable to 0
> + */
> +
> + cdns_dp_phy_write_field(cdns_phy, PHY_PMA_XCVR_POWER_STATE_REQ,
> + PHY_POWER_STATE_LN_0, 6, 0x0000);
> +
> + if (cdns_phy->num_lanes >= 2) {
> + cdns_dp_phy_write_field(cdns_phy,
> + PHY_PMA_XCVR_POWER_STATE_REQ,
> + PHY_POWER_STATE_LN_1, 6, 0x0000);
> +
> + if (cdns_phy->num_lanes == 4) {
> + cdns_dp_phy_write_field(cdns_phy,
> + PHY_PMA_XCVR_POWER_STATE_REQ,
> + PHY_POWER_STATE_LN_2, 6, 0);
> + cdns_dp_phy_write_field(cdns_phy,
> + PHY_PMA_XCVR_POWER_STATE_REQ,
> + PHY_POWER_STATE_LN_3, 6, 0);
> + }
> + }
> +
> + cdns_dp_phy_write_field(cdns_phy, PHY_PMA_XCVR_PLLCLK_EN,
> + 0, 1, 0x0000);
> +
> + if (cdns_phy->num_lanes >= 2) {
> + cdns_dp_phy_write_field(cdns_phy, PHY_PMA_XCVR_PLLCLK_EN,
> + 1, 1, 0x0000);
> + if (cdns_phy->num_lanes == 4) {
> + cdns_dp_phy_write_field(cdns_phy,
> + PHY_PMA_XCVR_PLLCLK_EN,
> + 2, 1, 0x0000);
> + cdns_dp_phy_write_field(cdns_phy,
> + PHY_PMA_XCVR_PLLCLK_EN,
> + 3, 1, 0x0000);
> + }
> + }
> +
> + /* release phy_l0*_reset_n and pma_tx_elec_idle_ln_* based on
> + * used lanes
> + */
> + lane_bits = (1 << cdns_phy->num_lanes) - 1;
> + writel(((0xF & ~lane_bits) << 4) | (0xF & lane_bits),
> + cdns_phy->base + PHY_RESET);
> +
> + /* release pma_xcvr_pllclk_en_ln_*, only for the master lane */
> + writel(0x0001, cdns_phy->base + PHY_PMA_XCVR_PLLCLK_EN);
> +
> + /* PHY PMA registers configuration functions */
> + cdns_dp_phy_pma_cmn_vco_cfg_25mhz(cdns_phy);
> + cdns_dp_phy_pma_cmn_rate(cdns_phy);
> +
> + /* take out of reset */
> + cdns_dp_phy_write_field(cdns_phy, PHY_RESET, 8, 1, 1);
> + cdns_dp_phy_wait_pma_cmn_ready(cdns_phy);
> + cdns_dp_phy_run(cdns_phy);
> +
> + return 0;
> +}
> +
> +static void cdns_dp_phy_wait_pma_cmn_ready(struct cdns_dp_phy *cdns_phy)
> +{
> + unsigned int reg;
> + int ret;
> +
> + ret = readl_poll_timeout(cdns_phy->base + PHY_PMA_CMN_READY, reg,
> + reg & 1, 0, 500);
> + if (ret == -ETIMEDOUT)
> + dev_err(cdns_phy->dev,
> + "timeout waiting for PMA common ready\n");
> +}
> +
> +static void cdns_dp_phy_pma_cfg(struct cdns_dp_phy *cdns_phy)
> +{
> + unsigned int i;
> +
> + /* PMA common configuration */
> + cdns_dp_phy_pma_cmn_cfg_25mhz(cdns_phy);
> +
> + /* PMA lane configuration to deal with multi-link operation */
> + for (i = 0; i < cdns_phy->num_lanes; i++)
> + cdns_dp_phy_pma_lane_cfg(cdns_phy, i);
> +}
> +
> +static void cdns_dp_phy_pma_cmn_cfg_25mhz(struct cdns_dp_phy *cdns_phy)
> +{
> + /* refclock registers - assumes 25 MHz refclock */
> + writel(0x0019, cdns_phy->sd_base + CMN_SSM_BIAS_TMR);
> + writel(0x0032, cdns_phy->sd_base + CMN_PLLSM0_PLLPRE_TMR);
> + writel(0x00D1, cdns_phy->sd_base + CMN_PLLSM0_PLLLOCK_TMR);
> + writel(0x0032, cdns_phy->sd_base + CMN_PLLSM1_PLLPRE_TMR);
> + writel(0x00D1, cdns_phy->sd_base + CMN_PLLSM1_PLLLOCK_TMR);
> + writel(0x007D, cdns_phy->sd_base + CMN_BGCAL_INIT_TMR);
> + writel(0x007D, cdns_phy->sd_base + CMN_BGCAL_ITER_TMR);
> + writel(0x0019, cdns_phy->sd_base + CMN_IBCAL_INIT_TMR);
> + writel(0x001E, cdns_phy->sd_base + CMN_TXPUCAL_INIT_TMR);
> + writel(0x0006, cdns_phy->sd_base + CMN_TXPUCAL_ITER_TMR);
> + writel(0x001E, cdns_phy->sd_base + CMN_TXPDCAL_INIT_TMR);
> + writel(0x0006, cdns_phy->sd_base + CMN_TXPDCAL_ITER_TMR);
> + writel(0x02EE, cdns_phy->sd_base + CMN_RXCAL_INIT_TMR);
> + writel(0x0006, cdns_phy->sd_base + CMN_RXCAL_ITER_TMR);
> + writel(0x0002, cdns_phy->sd_base + CMN_SD_CAL_INIT_TMR);
> + writel(0x0002, cdns_phy->sd_base + CMN_SD_CAL_ITER_TMR);
> + writel(0x000E, cdns_phy->sd_base + CMN_SD_CAL_REFTIM_START);
> + writel(0x012B, cdns_phy->sd_base + CMN_SD_CAL_PLLCNT_START);
> + /* PLL registers */
> + writel(0x0409, cdns_phy->sd_base + CMN_PDIAG_PLL0_CP_PADJ_M0);
> + writel(0x1001, cdns_phy->sd_base + CMN_PDIAG_PLL0_CP_IADJ_M0);
> + writel(0x0F08, cdns_phy->sd_base + CMN_PDIAG_PLL0_FILT_PADJ_M0);
> + writel(0x0004, cdns_phy->sd_base + CMN_PLL0_DSM_DIAG_M0);
> + writel(0x00FA, cdns_phy->sd_base + CMN_PLL0_VCOCAL_INIT_TMR);
> + writel(0x0004, cdns_phy->sd_base + CMN_PLL0_VCOCAL_ITER_TMR);
> + writel(0x00FA, cdns_phy->sd_base + CMN_PLL1_VCOCAL_INIT_TMR);
> + writel(0x0004, cdns_phy->sd_base + CMN_PLL1_VCOCAL_ITER_TMR);
> + writel(0x0318, cdns_phy->sd_base + CMN_PLL0_VCOCAL_REFTIM_START);
Are these values that are written just calibration data or are they bitfields
for a specific setting. If they are not calibration data, then macros should be
added.
> +}
> +
> +static void cdns_dp_phy_pma_cmn_vco_cfg_25mhz(struct cdns_dp_phy *cdns_phy)
> +{
> + /* Assumes 25 MHz refclock */
> + switch (cdns_phy->max_bit_rate) {
> + /* Setting VCO for 10.8GHz */
> + case 2700:
> + case 5400:
> + writel(0x01B0, cdns_phy->sd_base + CMN_PLL0_INTDIV_M0);
> + writel(0x0000, cdns_phy->sd_base + CMN_PLL0_FRACDIVL_M0);
> + writel(0x0002, cdns_phy->sd_base + CMN_PLL0_FRACDIVH_M0);
> + writel(0x0120, cdns_phy->sd_base + CMN_PLL0_HIGH_THR_M0);
> + break;
> + /* Setting VCO for 9.72GHz */
> + case 2430:
> + case 3240:
> + writel(0x0184, cdns_phy->sd_base + CMN_PLL0_INTDIV_M0);
> + writel(0xCCCD, cdns_phy->sd_base + CMN_PLL0_FRACDIVL_M0);
> + writel(0x0002, cdns_phy->sd_base + CMN_PLL0_FRACDIVH_M0);
> + writel(0x0104, cdns_phy->sd_base + CMN_PLL0_HIGH_THR_M0);
> + break;
> + /* Setting VCO for 8.64GHz */
> + case 2160:
> + case 4320:
> + writel(0x0159, cdns_phy->sd_base + CMN_PLL0_INTDIV_M0);
> + writel(0x999A, cdns_phy->sd_base + CMN_PLL0_FRACDIVL_M0);
> + writel(0x0002, cdns_phy->sd_base + CMN_PLL0_FRACDIVH_M0);
> + writel(0x00E7, cdns_phy->sd_base + CMN_PLL0_HIGH_THR_M0);
> + break;
> + /* Setting VCO for 8.1GHz */
> + case 8100:
> + writel(0x0144, cdns_phy->sd_base + CMN_PLL0_INTDIV_M0);
> + writel(0x0000, cdns_phy->sd_base + CMN_PLL0_FRACDIVL_M0);
> + writel(0x0002, cdns_phy->sd_base + CMN_PLL0_FRACDIVH_M0);
> + writel(0x00D8, cdns_phy->sd_base + CMN_PLL0_HIGH_THR_M0);
> + break;
> + }
> +
> + writel(0x0002, cdns_phy->sd_base + CMN_PDIAG_PLL0_CTRL_M0);
> + writel(0x0318, cdns_phy->sd_base + CMN_PLL0_VCOCAL_PLLCNT_START);
same for this function also.
> +}
> +
> +static void cdns_dp_phy_pma_cmn_rate(struct cdns_dp_phy *cdns_phy)
> +{
> + unsigned int clk_sel_val = 0;
> + unsigned int hsclk_div_val = 0;
> + unsigned int i;
> +
> + /* 16'h0000 for single DP link configuration */
> + writel(0x0000, cdns_phy->sd_base + PHY_PLL_CFG);
> +
> + switch (cdns_phy->max_bit_rate) {
> + case 1620:
> + clk_sel_val = 0x0f01;
> + hsclk_div_val = 2;
> + break;
> + case 2160:
> + case 2430:
> + case 2700:
> + clk_sel_val = 0x0701;
> + hsclk_div_val = 1;
> + break;
> + case 3240:
> + clk_sel_val = 0x0b00;
> + hsclk_div_val = 2;
> + break;
> + case 4320:
> + case 5400:
> + clk_sel_val = 0x0301;
> + hsclk_div_val = 0;
> + break;
> + case 8100:
> + clk_sel_val = 0x0200;
> + hsclk_div_val = 0;
> + break;
> + }
> +
> + writel(clk_sel_val, cdns_phy->sd_base + CMN_PDIAG_PLL0_CLK_SEL_M0);
> +
> + /* PMA lane configuration to deal with multi-link operation */
> + for (i = 0; i < cdns_phy->num_lanes; i++) {
> + writel(hsclk_div_val,
> + cdns_phy->sd_base + (XCVR_DIAG_HSCLK_DIV | (i<<11)));
> + }
> +}
> +
> +static void cdns_dp_phy_pma_lane_cfg(struct cdns_dp_phy *cdns_phy,
> + unsigned int lane)
> +{
> + unsigned int i;
> +
> + i = 0x0007 & lane;
macro for mask has to be added.
Thanks
Kishon
^ permalink raw reply
* [PATCH v2] phy: Add driver for Cadence MHDP DisplayPort SD0801 PHY
From: Kishon Vijay Abraham I @ 2018-07-24 3:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1532090477-15559-1-git-send-email-stelford@cadence.com>
Hi,
On Friday 20 July 2018 06:11 PM, Scott Telford wrote:
> Add driver for the Cadence SD0801 "Torrent" PHY used with the Cadence MHDP
> DisplayPort Tx controller.
>
> Integration with the MHDP driver will be the subject of another commit.
>
> Signed-off-by: Scott Telford <stelford@cadence.com>
> ---
> .../devicetree/bindings/phy/phy-cadence-dp.txt | 28 ++
> drivers/phy/Kconfig | 1 +
> drivers/phy/Makefile | 1 +
> drivers/phy/cadence/Kconfig | 10 +
> drivers/phy/cadence/Makefile | 1 +
> drivers/phy/cadence/phy-cadence-dp.c | 436 +++++++++++++++++++++
> drivers/phy/cadence/phy-cadence-dp.h | 117 ++++++
> 7 files changed, 594 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
> create mode 100644 drivers/phy/cadence/Kconfig
> create mode 100644 drivers/phy/cadence/Makefile
> create mode 100644 drivers/phy/cadence/phy-cadence-dp.c
> create mode 100644 drivers/phy/cadence/phy-cadence-dp.h
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-dp.txt b/Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
> new file mode 100644
> index 0000000..8de0526
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
> @@ -0,0 +1,28 @@
> +Cadence MHDP DisplayPort SD0801 PHY binding
> +===========================================
> +
> +This binding describes the Cadence SD0801 PHY hardware included with
> +the Cadence MHDP DisplayPort controller.
> +
> +-------------------------------------------------------------------------------
> +Required properties (controller (parent) node):
> +- compatible : Should be "cdns,dp-phy"
> +- reg : Defines the following sets of registers in the parent
> + mhdp device:
> + - Offset of the DPTX PHY configuration registers
> + - Offset of the SD0801 PHY configuration registers
> +- num_lanes : Number of DisplayPort lanes to use (1, 2 or 4)
> +- max_bit_rate : Maximum DisplayPort link bit rate to use, in Mbps (2160,
> + 2430, 2700, 3240, 4320, 5400 or 8100)
> +- #phy-cells : from the generic PHY bindings, must be 0.
> +-------------------------------------------------------------------------------
> +
> +Example:
> + dp_phy: phy at f0fb030a00 {
> + compatible = "cdns,dp-phy";
> + reg = <0xf0 0xfb030a00 0x0 0x00000040>,
> + <0xf0 0xfb500000 0x0 0x00100000>;
> + num_lanes = <4>;
> + max_bit_rate = <8100>;
> + #phy-cells = <0>;
> + };
dt bindings should be a separate patch
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 5c8d452..cc47f85 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -43,6 +43,7 @@ config PHY_XGENE
> source "drivers/phy/allwinner/Kconfig"
> source "drivers/phy/amlogic/Kconfig"
> source "drivers/phy/broadcom/Kconfig"
> +source "drivers/phy/cadence/Kconfig"
> source "drivers/phy/hisilicon/Kconfig"
> source "drivers/phy/lantiq/Kconfig"
> source "drivers/phy/marvell/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 84e3bd9..ba48acd 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_RENESAS) += renesas/
> obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-y += broadcom/ \
> + cadence/ \
> hisilicon/ \
> marvell/ \
> motorola/ \
> diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
> new file mode 100644
> index 0000000..57fff7d
> --- /dev/null
> +++ b/drivers/phy/cadence/Kconfig
> @@ -0,0 +1,10 @@
> +#
> +# Phy driver for Cadence MHDP DisplayPort controller
> +#
> +config PHY_CADENCE_DP
> + tristate "Cadence MHDP DisplayPort PHY driver"
> + depends on OF
> + depends on HAS_IOMEM
> + select GENERIC_PHY
> + help
> + Support for Cadence MHDP DisplayPort PHY.
> diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
> new file mode 100644
> index 0000000..e5b0a11
> --- /dev/null
> +++ b/drivers/phy/cadence/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_PHY_CADENCE_DP) += phy-cadence-dp.o
> diff --git a/drivers/phy/cadence/phy-cadence-dp.c b/drivers/phy/cadence/phy-cadence-dp.c
> new file mode 100644
> index 0000000..c1cf89b
> --- /dev/null
> +++ b/drivers/phy/cadence/phy-cadence-dp.c
> @@ -0,0 +1,436 @@
> +/*
> + * Cadence MHDP DisplayPort SD0801 PHY driver.
> + *
> + * Copyright 2018 Cadence Design Systems, Inc.
> + *
> + * SPDX-License-Identifier: GPL-2.0-only
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/phy/phy.h>
> +#include "phy-cadence-dp.h"
If phy-cadence-dp.h is not going to be used in multiple files, then all the
definitions should be added here and the .h can removed.
> +
> +
> +static const struct phy_ops cdns_dp_phy_ops = {
> + .init = cdns_dp_phy_init,
> + .owner = THIS_MODULE,
> +};
> +
> +static const struct of_device_id cdns_dp_phy_of_match[] = {
> + {
> + .compatible = "cdns,dp-phy"
> + },
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(of, cdns_dp_phy_of_match);
> +
> +static int cdns_dp_phy_probe(struct platform_device *pdev)
The file organization is slightly different. Can we follow what other drivers
do by having the probe in the bottom of the file and other functions above that?
> +{
> + struct resource *regs;
> + struct cdns_dp_phy *cdns_phy;
> + struct device *dev = &pdev->dev;
> + struct phy_provider *phy_provider;
> + struct phy *phy;
> + int err;
> +
> + cdns_phy = devm_kzalloc(dev, sizeof(*cdns_phy), GFP_KERNEL);
> + if (!cdns_phy)
> + return -ENOMEM;
> +
> + cdns_phy->dev = &pdev->dev;
> +
> + phy = devm_phy_create(dev, NULL, &cdns_dp_phy_ops);
> + if (IS_ERR(phy)) {
> + dev_err(dev, "failed to create DisplayPort PHY\n");
> + return PTR_ERR(phy);
> + }
> +
> + regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + cdns_phy->base = devm_ioremap_resource(&pdev->dev, regs);
> + if (IS_ERR(cdns_phy->base))
> + return PTR_ERR(cdns_phy->base);
> +
> + regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + cdns_phy->sd_base = devm_ioremap_resource(&pdev->dev, regs);
> + if (IS_ERR(cdns_phy->sd_base))
> + return PTR_ERR(cdns_phy->sd_base);
> +
> + err = device_property_read_u32(dev, "num_lanes",
> + &(cdns_phy->num_lanes));
> + if (err)
> + cdns_phy->num_lanes = DEFAULT_NUM_LANES;
> +
> + switch (cdns_phy->num_lanes) {
> + case 1:
> + case 2:
> + case 4:
> + /* valid number of lanes */
> + break;
> + default:
> + dev_err(dev, "unsupported number of lanes: %d\n",
> + cdns_phy->num_lanes);
> + return -EINVAL;
> + }
> +
> + err = device_property_read_u32(dev, "max_bit_rate",
> + &(cdns_phy->max_bit_rate));
> + if (err)
> + cdns_phy->max_bit_rate = DEFAULT_MAX_BIT_RATE;
> +
> + switch (cdns_phy->max_bit_rate) {
> + case 2160:
> + case 2430:
> + case 2700:
> + case 3240:
> + case 4320:
> + case 5400:
> + case 8100:
> + /* valid bit rate */
> + break;
> + default:
> + dev_err(dev, "unsupported max bit rate: %dMbps\n",
> + cdns_phy->max_bit_rate);
> + return -EINVAL;
> + }
> +
> + phy_set_drvdata(phy, cdns_phy);
> +
> + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> +
> + dev_info(dev, "%d lanes, max bit rate %d.%03d Gbps\n",
> + cdns_phy->num_lanes,
> + cdns_phy->max_bit_rate / 1000,
> + cdns_phy->max_bit_rate % 1000);
> +
> + return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +
> +static int cdns_dp_phy_init(struct phy *phy)
> +{
> + unsigned char lane_bits;
> +
> + struct cdns_dp_phy *cdns_phy = phy_get_drvdata(phy);
> +
> + writel(0x0003, cdns_phy->base + PHY_AUX_CTRL); /* enable AUX */
> +
> + /* PHY PMA registers configuration function */
> + cdns_dp_phy_pma_cfg(cdns_phy);
> +
> + /* Set lines power state to A0
> + * Set lines pll clk enable to 0
> + */
> +
> + cdns_dp_phy_write_field(cdns_phy, PHY_PMA_XCVR_POWER_STATE_REQ,
> + PHY_POWER_STATE_LN_0, 6, 0x0000);
> +
> + if (cdns_phy->num_lanes >= 2) {
> + cdns_dp_phy_write_field(cdns_phy,
> + PHY_PMA_XCVR_POWER_STATE_REQ,
> + PHY_POWER_STATE_LN_1, 6, 0x0000);
> +
> + if (cdns_phy->num_lanes == 4) {
> + cdns_dp_phy_write_field(cdns_phy,
> + PHY_PMA_XCVR_POWER_STATE_REQ,
> + PHY_POWER_STATE_LN_2, 6, 0);
> + cdns_dp_phy_write_field(cdns_phy,
> + PHY_PMA_XCVR_POWER_STATE_REQ,
> + PHY_POWER_STATE_LN_3, 6, 0);
> + }
> + }
> +
> + cdns_dp_phy_write_field(cdns_phy, PHY_PMA_XCVR_PLLCLK_EN,
> + 0, 1, 0x0000);
> +
> + if (cdns_phy->num_lanes >= 2) {
> + cdns_dp_phy_write_field(cdns_phy, PHY_PMA_XCVR_PLLCLK_EN,
> + 1, 1, 0x0000);
> + if (cdns_phy->num_lanes == 4) {
> + cdns_dp_phy_write_field(cdns_phy,
> + PHY_PMA_XCVR_PLLCLK_EN,
> + 2, 1, 0x0000);
> + cdns_dp_phy_write_field(cdns_phy,
> + PHY_PMA_XCVR_PLLCLK_EN,
> + 3, 1, 0x0000);
> + }
> + }
> +
> + /* release phy_l0*_reset_n and pma_tx_elec_idle_ln_* based on
> + * used lanes
> + */
> + lane_bits = (1 << cdns_phy->num_lanes) - 1;
> + writel(((0xF & ~lane_bits) << 4) | (0xF & lane_bits),
> + cdns_phy->base + PHY_RESET);
> +
> + /* release pma_xcvr_pllclk_en_ln_*, only for the master lane */
> + writel(0x0001, cdns_phy->base + PHY_PMA_XCVR_PLLCLK_EN);
> +
> + /* PHY PMA registers configuration functions */
> + cdns_dp_phy_pma_cmn_vco_cfg_25mhz(cdns_phy);
> + cdns_dp_phy_pma_cmn_rate(cdns_phy);
> +
> + /* take out of reset */
> + cdns_dp_phy_write_field(cdns_phy, PHY_RESET, 8, 1, 1);
> + cdns_dp_phy_wait_pma_cmn_ready(cdns_phy);
> + cdns_dp_phy_run(cdns_phy);
> +
> + return 0;
> +}
> +
> +static void cdns_dp_phy_wait_pma_cmn_ready(struct cdns_dp_phy *cdns_phy)
> +{
> + unsigned int reg;
> + int ret;
> +
> + ret = readl_poll_timeout(cdns_phy->base + PHY_PMA_CMN_READY, reg,
> + reg & 1, 0, 500);
> + if (ret == -ETIMEDOUT)
> + dev_err(cdns_phy->dev,
> + "timeout waiting for PMA common ready\n");
> +}
> +
> +static void cdns_dp_phy_pma_cfg(struct cdns_dp_phy *cdns_phy)
> +{
> + unsigned int i;
> +
> + /* PMA common configuration */
> + cdns_dp_phy_pma_cmn_cfg_25mhz(cdns_phy);
> +
> + /* PMA lane configuration to deal with multi-link operation */
> + for (i = 0; i < cdns_phy->num_lanes; i++)
> + cdns_dp_phy_pma_lane_cfg(cdns_phy, i);
> +}
> +
> +static void cdns_dp_phy_pma_cmn_cfg_25mhz(struct cdns_dp_phy *cdns_phy)
> +{
> + /* refclock registers - assumes 25 MHz refclock */
> + writel(0x0019, cdns_phy->sd_base + CMN_SSM_BIAS_TMR);
> + writel(0x0032, cdns_phy->sd_base + CMN_PLLSM0_PLLPRE_TMR);
> + writel(0x00D1, cdns_phy->sd_base + CMN_PLLSM0_PLLLOCK_TMR);
> + writel(0x0032, cdns_phy->sd_base + CMN_PLLSM1_PLLPRE_TMR);
> + writel(0x00D1, cdns_phy->sd_base + CMN_PLLSM1_PLLLOCK_TMR);
> + writel(0x007D, cdns_phy->sd_base + CMN_BGCAL_INIT_TMR);
> + writel(0x007D, cdns_phy->sd_base + CMN_BGCAL_ITER_TMR);
> + writel(0x0019, cdns_phy->sd_base + CMN_IBCAL_INIT_TMR);
> + writel(0x001E, cdns_phy->sd_base + CMN_TXPUCAL_INIT_TMR);
> + writel(0x0006, cdns_phy->sd_base + CMN_TXPUCAL_ITER_TMR);
> + writel(0x001E, cdns_phy->sd_base + CMN_TXPDCAL_INIT_TMR);
> + writel(0x0006, cdns_phy->sd_base + CMN_TXPDCAL_ITER_TMR);
> + writel(0x02EE, cdns_phy->sd_base + CMN_RXCAL_INIT_TMR);
> + writel(0x0006, cdns_phy->sd_base + CMN_RXCAL_ITER_TMR);
> + writel(0x0002, cdns_phy->sd_base + CMN_SD_CAL_INIT_TMR);
> + writel(0x0002, cdns_phy->sd_base + CMN_SD_CAL_ITER_TMR);
> + writel(0x000E, cdns_phy->sd_base + CMN_SD_CAL_REFTIM_START);
> + writel(0x012B, cdns_phy->sd_base + CMN_SD_CAL_PLLCNT_START);
> + /* PLL registers */
> + writel(0x0409, cdns_phy->sd_base + CMN_PDIAG_PLL0_CP_PADJ_M0);
> + writel(0x1001, cdns_phy->sd_base + CMN_PDIAG_PLL0_CP_IADJ_M0);
> + writel(0x0F08, cdns_phy->sd_base + CMN_PDIAG_PLL0_FILT_PADJ_M0);
> + writel(0x0004, cdns_phy->sd_base + CMN_PLL0_DSM_DIAG_M0);
> + writel(0x00FA, cdns_phy->sd_base + CMN_PLL0_VCOCAL_INIT_TMR);
> + writel(0x0004, cdns_phy->sd_base + CMN_PLL0_VCOCAL_ITER_TMR);
> + writel(0x00FA, cdns_phy->sd_base + CMN_PLL1_VCOCAL_INIT_TMR);
> + writel(0x0004, cdns_phy->sd_base + CMN_PLL1_VCOCAL_ITER_TMR);
> + writel(0x0318, cdns_phy->sd_base + CMN_PLL0_VCOCAL_REFTIM_START);
Are these values that are written just calibration data or are they bitfields
for a specific setting. If they are not calibration data, then macros should be
added.
> +}
> +
> +static void cdns_dp_phy_pma_cmn_vco_cfg_25mhz(struct cdns_dp_phy *cdns_phy)
> +{
> + /* Assumes 25 MHz refclock */
> + switch (cdns_phy->max_bit_rate) {
> + /* Setting VCO for 10.8GHz */
> + case 2700:
> + case 5400:
> + writel(0x01B0, cdns_phy->sd_base + CMN_PLL0_INTDIV_M0);
> + writel(0x0000, cdns_phy->sd_base + CMN_PLL0_FRACDIVL_M0);
> + writel(0x0002, cdns_phy->sd_base + CMN_PLL0_FRACDIVH_M0);
> + writel(0x0120, cdns_phy->sd_base + CMN_PLL0_HIGH_THR_M0);
> + break;
> + /* Setting VCO for 9.72GHz */
> + case 2430:
> + case 3240:
> + writel(0x0184, cdns_phy->sd_base + CMN_PLL0_INTDIV_M0);
> + writel(0xCCCD, cdns_phy->sd_base + CMN_PLL0_FRACDIVL_M0);
> + writel(0x0002, cdns_phy->sd_base + CMN_PLL0_FRACDIVH_M0);
> + writel(0x0104, cdns_phy->sd_base + CMN_PLL0_HIGH_THR_M0);
> + break;
> + /* Setting VCO for 8.64GHz */
> + case 2160:
> + case 4320:
> + writel(0x0159, cdns_phy->sd_base + CMN_PLL0_INTDIV_M0);
> + writel(0x999A, cdns_phy->sd_base + CMN_PLL0_FRACDIVL_M0);
> + writel(0x0002, cdns_phy->sd_base + CMN_PLL0_FRACDIVH_M0);
> + writel(0x00E7, cdns_phy->sd_base + CMN_PLL0_HIGH_THR_M0);
> + break;
> + /* Setting VCO for 8.1GHz */
> + case 8100:
> + writel(0x0144, cdns_phy->sd_base + CMN_PLL0_INTDIV_M0);
> + writel(0x0000, cdns_phy->sd_base + CMN_PLL0_FRACDIVL_M0);
> + writel(0x0002, cdns_phy->sd_base + CMN_PLL0_FRACDIVH_M0);
> + writel(0x00D8, cdns_phy->sd_base + CMN_PLL0_HIGH_THR_M0);
> + break;
> + }
> +
> + writel(0x0002, cdns_phy->sd_base + CMN_PDIAG_PLL0_CTRL_M0);
> + writel(0x0318, cdns_phy->sd_base + CMN_PLL0_VCOCAL_PLLCNT_START);
same for this function also.
> +}
> +
> +static void cdns_dp_phy_pma_cmn_rate(struct cdns_dp_phy *cdns_phy)
> +{
> + unsigned int clk_sel_val = 0;
> + unsigned int hsclk_div_val = 0;
> + unsigned int i;
> +
> + /* 16'h0000 for single DP link configuration */
> + writel(0x0000, cdns_phy->sd_base + PHY_PLL_CFG);
> +
> + switch (cdns_phy->max_bit_rate) {
> + case 1620:
> + clk_sel_val = 0x0f01;
> + hsclk_div_val = 2;
> + break;
> + case 2160:
> + case 2430:
> + case 2700:
> + clk_sel_val = 0x0701;
> + hsclk_div_val = 1;
> + break;
> + case 3240:
> + clk_sel_val = 0x0b00;
> + hsclk_div_val = 2;
> + break;
> + case 4320:
> + case 5400:
> + clk_sel_val = 0x0301;
> + hsclk_div_val = 0;
> + break;
> + case 8100:
> + clk_sel_val = 0x0200;
> + hsclk_div_val = 0;
> + break;
> + }
> +
> + writel(clk_sel_val, cdns_phy->sd_base + CMN_PDIAG_PLL0_CLK_SEL_M0);
> +
> + /* PMA lane configuration to deal with multi-link operation */
> + for (i = 0; i < cdns_phy->num_lanes; i++) {
> + writel(hsclk_div_val,
> + cdns_phy->sd_base + (XCVR_DIAG_HSCLK_DIV | (i<<11)));
> + }
> +}
> +
> +static void cdns_dp_phy_pma_lane_cfg(struct cdns_dp_phy *cdns_phy,
> + unsigned int lane)
> +{
> + unsigned int i;
> +
> + i = 0x0007 & lane;
macro for mask has to be added.
Thanks
Kishon
^ permalink raw reply
* [PATCH 2/2 V3] xfs_repair: clear_dinode should simply clear, not check contents
From: Eric Sandeen @ 2018-07-24 2:50 UTC (permalink / raw)
To: Eric Sandeen, linux-xfs
In-Reply-To: <b6f745ab-3016-9a95-3085-8584f7200b64@redhat.com>
Today clear_inode performs 2 separate tasks - it clears a disk inode
when the calling code detects an inconsistency, and it also validates
free inodes to some extent by checking each field before zeroing it
out. This leads to unnecessary checks in the former case where we
just want to zap the inode, and duplicates some of the existing
verifier checks in the latter case.
Now that we're using xfs_dinode_verify to validate free inodes,
there's no reason to repeat all the checks inside clear_inode_core.
Drop them all and simply clear it when told to do so.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
diff --git a/repair/dinode.c b/repair/dinode.c
index c0db15a..5b9fd9a 100644
--- a/repair/dinode.c
+++ b/repair/dinode.c
@@ -117,137 +117,24 @@ _("would have cleared inode %" PRIu64 " attributes\n"), ino_num);
return(1);
}
-static int
+static void
clear_dinode_core(struct xfs_mount *mp, xfs_dinode_t *dinoc, xfs_ino_t ino_num)
{
- int dirty = 0;
- int i;
-
-#define __dirty_no_modify_ret(dirty) \
- ({ (dirty) = 1; if (no_modify) return 1; })
-
- if (be16_to_cpu(dinoc->di_magic) != XFS_DINODE_MAGIC) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_magic = cpu_to_be16(XFS_DINODE_MAGIC);
- }
-
- if (!libxfs_dinode_good_version(mp, dinoc->di_version)) {
- __dirty_no_modify_ret(dirty);
- if (xfs_sb_version_hascrc(&mp->m_sb))
- dinoc->di_version = 3;
- else
- dinoc->di_version = 2;
- }
-
- if (be16_to_cpu(dinoc->di_mode) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_mode = 0;
- }
-
- if (be16_to_cpu(dinoc->di_flags) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_flags = 0;
- }
-
- if (be32_to_cpu(dinoc->di_dmevmask) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_dmevmask = 0;
- }
-
- if (dinoc->di_forkoff != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_forkoff = 0;
- }
-
- if (dinoc->di_format != XFS_DINODE_FMT_EXTENTS) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_format = XFS_DINODE_FMT_EXTENTS;
- }
-
- if (dinoc->di_aformat != XFS_DINODE_FMT_EXTENTS) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_aformat = XFS_DINODE_FMT_EXTENTS;
- }
-
- if (be64_to_cpu(dinoc->di_size) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_size = 0;
- }
-
- if (be64_to_cpu(dinoc->di_nblocks) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_nblocks = 0;
- }
-
- if (be16_to_cpu(dinoc->di_onlink) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_onlink = 0;
- }
-
- if (be32_to_cpu(dinoc->di_nextents) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_nextents = 0;
- }
-
- if (be16_to_cpu(dinoc->di_anextents) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_anextents = 0;
- }
-
- if (be32_to_cpu(dinoc->di_extsize) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_extsize = 0;
- }
-
- if (dinoc->di_version > 1 &&
- be32_to_cpu(dinoc->di_nlink) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_nlink = 0;
- }
-
+ memset(dinoc, 0, sizeof(*dinoc));
+ dinoc->di_magic = cpu_to_be16(XFS_DINODE_MAGIC);
+ if (xfs_sb_version_hascrc(&mp->m_sb))
+ dinoc->di_version = 3;
+ else
+ dinoc->di_version = 2;
+ dinoc->di_gen = cpu_to_be32(random());
+ dinoc->di_format = XFS_DINODE_FMT_EXTENTS;
+ dinoc->di_aformat = XFS_DINODE_FMT_EXTENTS;
/* we are done for version 1/2 inodes */
if (dinoc->di_version < 3)
- return dirty;
-
- if (be64_to_cpu(dinoc->di_ino) != ino_num) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_ino = cpu_to_be64(ino_num);
- }
-
- if (platform_uuid_compare(&dinoc->di_uuid, &mp->m_sb.sb_meta_uuid)) {
- __dirty_no_modify_ret(dirty);
- platform_uuid_copy(&dinoc->di_uuid, &mp->m_sb.sb_meta_uuid);
- }
-
- for (i = 0; i < sizeof(dinoc->di_pad2)/sizeof(dinoc->di_pad2[0]); i++) {
- if (dinoc->di_pad2[i] != 0) {
- __dirty_no_modify_ret(dirty);
- memset(dinoc->di_pad2, 0, sizeof(dinoc->di_pad2));
- break;
- }
- }
-
- if (be64_to_cpu(dinoc->di_flags2) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_flags2 = 0;
- }
-
- if (be64_to_cpu(dinoc->di_lsn) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_lsn = 0;
- }
-
- if (be64_to_cpu(dinoc->di_changecount) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_changecount = 0;
- }
-
- if (be32_to_cpu(dinoc->di_cowextsize) != 0) {
- __dirty_no_modify_ret(dirty);
- dinoc->di_cowextsize = 0;
- }
-
- return dirty;
+ return;
+ dinoc->di_ino = cpu_to_be64(ino_num);
+ platform_uuid_copy(&dinoc->di_uuid, &mp->m_sb.sb_meta_uuid);
+ return;
}
static int
@@ -268,21 +155,15 @@ clear_dinode_unlinked(xfs_mount_t *mp, xfs_dinode_t *dino)
* until after the agi unlinked lists are walked in phase 3.
* returns > zero if the inode has been altered while being cleared
*/
-static int
+static void
clear_dinode(xfs_mount_t *mp, xfs_dinode_t *dino, xfs_ino_t ino_num)
{
- int dirty;
-
- dirty = clear_dinode_core(mp, dino, ino_num);
- dirty += clear_dinode_unlinked(mp, dino);
+ clear_dinode_core(mp, dino, ino_num);
+ clear_dinode_unlinked(mp, dino);
/* and clear the forks */
-
- if (dirty && !no_modify)
- memset(XFS_DFORK_DPTR(dino), 0,
- XFS_LITINO(mp, dino->di_version));
-
- return(dirty);
+ memset(XFS_DFORK_DPTR(dino), 0, XFS_LITINO(mp, dino->di_version));
+ return;
}
@@ -2140,8 +2021,8 @@ process_inode_data_fork(
if (err) {
do_warn(_("bad data fork in inode %" PRIu64 "\n"), lino);
if (!no_modify) {
- *dirty += clear_dinode(mp, dino, lino);
- ASSERT(*dirty > 0);
+ clear_dinode(mp, dino, lino);
+ *dirty += 1;
}
return 1;
}
@@ -2551,7 +2432,7 @@ _("bad (negative) size %" PRId64 " on inode %" PRIu64 "\n"),
}
/*
- * if not in verify mode, check to sii if the inode and imap
+ * if not in verify mode, check to see if the inode and imap
* agree that the inode is free
*/
if (!verify_mode && di_mode == 0) {
@@ -2568,8 +2449,9 @@ _("bad (negative) size %" PRId64 " on inode %" PRIu64 "\n"),
do_warn(
_("free inode %" PRIu64 " contains errors, "), lino);
if (!no_modify) {
- *dirty += clear_dinode(mp, dino, lino);
+ clear_dinode(mp, dino, lino);
do_warn(_("corrected\n"));
+ *dirty += 1;
} else {
do_warn(_("would correct\n"));
}
@@ -2586,7 +2468,8 @@ _("bad (negative) size %" PRId64 " on inode %" PRIu64 "\n"),
_("imap claims a free inode %" PRIu64 " is in use, "), lino);
if (!no_modify) {
do_warn(_("correcting imap and clearing inode\n"));
- *dirty += clear_dinode(mp, dino, lino);
+ clear_dinode(mp, dino, lino);
+ *dirty += 1;
retval = 1;
} else
do_warn(_("would correct imap and clear inode\n"));
@@ -2804,8 +2687,10 @@ _("bad (negative) size %" PRId64 " on inode %" PRIu64 "\n"),
* we're going to find. check_dups is set to 1 only during
* phase 4. Ugly.
*/
- if (check_dups && !no_modify)
- *dirty += clear_dinode_unlinked(mp, dino);
+ if (check_dups && !no_modify) {
+ clear_dinode_unlinked(mp, dino);
+ *dirty += 1;
+ }
/* set type and map type info */
@@ -3024,8 +2909,8 @@ _("Cannot have CoW extent size of zero on cowextsize inode %" PRIu64 ", "),
clear_bad_out:
if (!no_modify) {
- *dirty += clear_dinode(mp, dino, lino);
- ASSERT(*dirty > 0);
+ clear_dinode(mp, dino, lino);
+ *dirty += 1;
}
bad_out:
*used = is_free;
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge
From: Benjamin Herrenschmidt @ 2018-07-24 3:49 UTC (permalink / raw)
To: David Gibson
Cc: Cédric Le Goater, qemu-ppc, qemu-devel, Marcel Apfelbaum,
Andrea Bolognani, Michael S. Tsirkin
In-Reply-To: <20180724021456.GF6830@umbus.fritz.box>
On Tue, 2018-07-24 at 12:14 +1000, David Gibson wrote:
> > I don't know, is there much shared logic ? And the shared bits are the
> > subclassing, that's handled that way...
> >
> > This is really a different piece of HW, a separate ICS implementation,
> > that has its own quirks, is configured via different registers, does
> > EOI differently etc...
> >
> > Even the resend stuff is done differently, the resend bitmap is
> > actually SW visible via an IODA table.
> >
> > I mean, we could (maybe we do these days not sure) have an ICS
> > superclass wrapper on the actual icp_irq() but that's really all there
> > is to it I think.
>
> Hm, yeah, fair enough. I realized what I was suggesting would
> actually need another layer of qirqs than we have, so it's not a good
> idea after all. Ok, I'm happy proceeding with exposing icp_irq().
The only idea I have if you want to keep icp_* private is to put a
'helper' in the ICS superclass that the subclass uses to encapsulate
the ICP call, but at this point it's just churn.
But yeah you really don't want a layer of qirqs, it wouldn't work any
way, it's really an ICS, it will send messages to the ICP with a XIRR
value in them etc... just like an ICS, it's not somethign you want
qirq's for .
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 6/8] xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info
From: Toshiaki Makita @ 2018-07-24 2:43 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Toshiaki Makita, netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <20180723182247.494ccb07@cakuba.netronome.com>
On 2018/07/24 10:22, Jakub Kicinski wrote:
> On Mon, 23 Jul 2018 00:13:06 +0900, Toshiaki Makita wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> We need some mechanism to disable napi_direct on calling
>> xdp_return_frame_rx_napi() from some context.
>> When veth gets support of XDP_REDIRECT, it will redirects packets which
>> are redirected from other devices. On redirection veth will reuse
>> xdp_mem_info of the redirection source device to make return_frame work.
>> But in this case .ndo_xdp_xmit() called from veth redirection uses
>> xdp_mem_info which is not guarded by NAPI, because the .ndo_xdp_xmit is
>> not called directly from the rxq which owns the xdp_mem_info.
>>
>> This approach introduces a flag in xdp_mem_info to indicate that
>> napi_direct should be disabled even when _rx_napi variant is used.
>>
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> To be clear - you will modify flags of the original source device if it
> ever redirected a frame to a software device like veth? Seems a bit
> heavy handed. The xdp_return_frame_rx_napi() is only really used on
> error paths, but still.. Also as you note the original NAPI can run
> concurrently with your veth dest one, but also with NAPIs of other veth
> devices, so the non-atomic xdp.rxq->mem.flags |= XDP_MEM_RF_NO_DIRECT;
> makes me worried.
xdp_mem_info is copied in xdp_frame in convert_to_xdp_frame() so the
field is local to the frame. Changing flags affects only the frame.
xdp.rxq is local to NAPI thread, so no worries about atomicity.
> Would you mind elaborating why not handle the RX completely in the NAPI
> context of the original device?
Originally it was difficult to implement .ndo_xdp_xmit() and
.ndo_xdp_flush() model without creating NAPI in veth. Now it is changed
so I'm not sure how difficult it is at this point.
But in any case I want to avoid stack inflation by veth NAPI. (Imagine
some misconfiguration like calling XDP_TX on both side of veth...)
>
>> diff --git a/include/net/xdp.h b/include/net/xdp.h
>> index fcb033f51d8c..1d1bc6553ff2 100644
>> --- a/include/net/xdp.h
>> +++ b/include/net/xdp.h
>> @@ -41,6 +41,9 @@ enum xdp_mem_type {
>> MEM_TYPE_MAX,
>> };
>>
>> +/* XDP flags for xdp_mem_info */
>> +#define XDP_MEM_RF_NO_DIRECT BIT(0) /* don't use napi_direct */
>> +
>> /* XDP flags for ndo_xdp_xmit */
>> #define XDP_XMIT_FLUSH (1U << 0) /* doorbell signal consumer */
>> #define XDP_XMIT_FLAGS_MASK XDP_XMIT_FLUSH
>> @@ -48,6 +51,7 @@ enum xdp_mem_type {
>> struct xdp_mem_info {
>> u32 type; /* enum xdp_mem_type, but known size type */
>> u32 id;
>> + u32 flags;
>> };
>>
>> struct page_pool;
>> diff --git a/net/core/xdp.c b/net/core/xdp.c
>> index 57285383ed00..1426c608fd75 100644
>> --- a/net/core/xdp.c
>> +++ b/net/core/xdp.c
>> @@ -330,10 +330,12 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
>> /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
>> xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
>> page = virt_to_head_page(data);
>> - if (xa)
>> + if (xa) {
>> + napi_direct &= !(mem->flags & XDP_MEM_RF_NO_DIRECT);
>> page_pool_put_page(xa->page_pool, page, napi_direct);
>> - else
>> + } else {
>> put_page(page);
>> + }
>> rcu_read_unlock();
>> break;
>> case MEM_TYPE_PAGE_SHARED:
>
>
>
--
Toshiaki Makita
^ permalink raw reply
* [PATCH] app/testpmd: fix commands to config some offload
From: Wei Dai @ 2018-07-24 3:45 UTC (permalink / raw)
To: jingjing.wu, wenzhuo.lu, dev; +Cc: Wei Dai, stable
Without this patch, testpmd command to config Rx offload keep_crc
would fail and report "Bad argument".
This patch aslo fix the command to config the Tx offload mbuf_fast_free.
Fixes: 70815c9ecadd ("ethdev: add new offload flag to keep CRC")
Fixes: c73a9071877a ("app/testpmd: add commands to test new offload API")
Cc: stable@dpdk.org
Signed-off-by: Wei Dai <wei.dai@intel.com>
---
app/test-pmd/cmdline.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 5885289..a0ed3a0 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -16665,7 +16665,7 @@ struct cmd_config_per_port_rx_offload_result {
offload, "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
"qinq_strip#outer_ipv4_cksum#macsec_strip#"
"header_split#vlan_filter#vlan_extend#jumbo_frame#"
- "crc_strip#scatter#timestamp#security");
+ "crc_strip#scatter#timestamp#security#keep_crc");
cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
@@ -16744,7 +16744,7 @@ struct cmd_config_per_port_rx_offload_result {
.help_str = "port config <port_id> rx_offload vlan_strip|ipv4_cksum|"
"udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
"macsec_strip|header_split|vlan_filter|vlan_extend|"
- "jumbo_frame|crc_strip|scatter|timestamp|security "
+ "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
"on|off",
.tokens = {
(void *)&cmd_config_per_port_rx_offload_result_port,
@@ -16794,7 +16794,7 @@ struct cmd_config_per_queue_rx_offload_result {
offload, "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
"qinq_strip#outer_ipv4_cksum#macsec_strip#"
"header_split#vlan_filter#vlan_extend#jumbo_frame#"
- "crc_strip#scatter#timestamp#security");
+ "crc_strip#scatter#timestamp#security#keep_crc");
cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
@@ -16846,7 +16846,7 @@ struct cmd_config_per_queue_rx_offload_result {
"vlan_strip|ipv4_cksum|"
"udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
"macsec_strip|header_split|vlan_filter|vlan_extend|"
- "jumbo_frame|crc_strip|scatter|timestamp|security "
+ "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
"on|off",
.tokens = {
(void *)&cmd_config_per_queue_rx_offload_result_port,
@@ -17063,7 +17063,7 @@ struct cmd_config_per_port_tx_offload_result {
"sctp_cksum#tcp_tso#udp_tso#outer_ipv4_cksum#"
"qinq_insert#vxlan_tnl_tso#gre_tnl_tso#"
"ipip_tnl_tso#geneve_tnl_tso#macsec_insert#"
- "mt_lockfree#multi_segs#fast_free#security");
+ "mt_lockfree#multi_segs#mbuf_fast_free#security");
cmdline_parse_token_string_t cmd_config_per_port_tx_offload_result_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_tx_offload_result,
@@ -17144,7 +17144,7 @@ struct cmd_config_per_port_tx_offload_result {
"sctp_cksum|tcp_tso|udp_tso|outer_ipv4_cksum|"
"qinq_insert|vxlan_tnl_tso|gre_tnl_tso|"
"ipip_tnl_tso|geneve_tnl_tso|macsec_insert|"
- "mt_lockfree|multi_segs|fast_free|security "
+ "mt_lockfree|multi_segs|mbuf_fast_free|security "
"on|off",
.tokens = {
(void *)&cmd_config_per_port_tx_offload_result_port,
@@ -17195,7 +17195,7 @@ struct cmd_config_per_queue_tx_offload_result {
"sctp_cksum#tcp_tso#udp_tso#outer_ipv4_cksum#"
"qinq_insert#vxlan_tnl_tso#gre_tnl_tso#"
"ipip_tnl_tso#geneve_tnl_tso#macsec_insert#"
- "mt_lockfree#multi_segs#fast_free#security");
+ "mt_lockfree#multi_segs#mbuf_fast_free#security");
cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
@@ -17248,7 +17248,7 @@ struct cmd_config_per_queue_tx_offload_result {
"sctp_cksum|tcp_tso|udp_tso|outer_ipv4_cksum|"
"qinq_insert|vxlan_tnl_tso|gre_tnl_tso|"
"ipip_tnl_tso|geneve_tnl_tso|macsec_insert|"
- "mt_lockfree|multi_segs|fast_free|security "
+ "mt_lockfree|multi_segs|mbuf_fast_free|security "
"on|off",
.tokens = {
(void *)&cmd_config_per_queue_tx_offload_result_port,
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 5/7] x86/vdso: Add vDSO functions for direct store instructions
From: Fenghua Yu @ 2018-07-24 3:42 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Fenghua Yu, Thomas Gleixner, Ingo Molnar, H Peter Anvin,
Ashok Raj, Alan Cox, Ravi V Shankar, linux-kernel, x86
In-Reply-To: <10870309-993a-0abc-635a-92c05bbad140@kernel.org>
On Mon, Jul 23, 2018 at 06:48:00PM -0700, Andy Lutomirski wrote:
> On 07/23/2018 05:55 AM, Fenghua Yu wrote:
> >The instructions can be implemented in intrinsic functions in future
> >GCC. But the vDSO interfaces are available to user without the
> I'm not convinced that any of this belongs in the vDSO at all. You could
> just add AT_HWCAP (or AT_HWCAP2) flags for the new instructions. Or user
Thomas asked to use vDSO. Please see the discussion thread:
https://lkml.org/lkml/2018/6/19/316
> code could use CPUID just like for any other new instruction. But, if there
> really is some compelling reason to add this to the vDSO, then see below:
> >+notrace bool __vdso_movdiri_supported(void)
> >+{
> >+ return _vdso_funcs_data->movdiri_supported;
> return static_cpu_has(X86_FEATURE_MOVDIRI);
But boot_cpu_data (used in static_cpu_has) cannot be accessed by user
unless mapped in VVAR. So this change cannot be compiled.
> And all the VVAR stuff can be removed.
The VVAR stuff needs to map the kernel data _vdso_funcs_data to user
space before user can access it.
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH] cpufreq: qcom-kryo: add NULL entry to the end of_device_id array
From: Viresh Kumar @ 2018-07-24 3:43 UTC (permalink / raw)
To: YueHaibing; +Cc: ilia.lin, rjw, linux-kernel, linux-pm
In-Reply-To: <20180723123429.20040-1-yuehaibing@huawei.com>
On 23-07-18, 20:34, YueHaibing wrote:
> Make sure of_device_id tables are NULL terminated
> Found by coccinelle spatch "misc/of_table.cocci"
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c
> index 29389ac..efc9a7a 100644
> --- a/drivers/cpufreq/qcom-cpufreq-kryo.c
> +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
> @@ -183,6 +183,7 @@ static struct platform_driver qcom_cpufreq_kryo_driver = {
> static const struct of_device_id qcom_cpufreq_kryo_match_list[] __initconst = {
> { .compatible = "qcom,apq8096", },
> { .compatible = "qcom,msm8996", },
> + {}
> };
>
> /*
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge
From: David Gibson @ 2018-07-24 2:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Cédric Le Goater, qemu-ppc, qemu-devel, Marcel Apfelbaum,
Andrea Bolognani, Michael S. Tsirkin
In-Reply-To: <3692f644f72a1af49b7d5988d6b8482ea2f1e271.camel@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]
On Tue, Jul 24, 2018 at 09:55:53AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2018-07-23 at 14:16 +1000, David Gibson wrote:
> > >
> > > Now, this is an ICS subclass, so why shouldn't it directly poke at the
> > > target ICP ?
> >
> > That's ok in theory, but causing it to expose the icp interface to a
> > new module isn't great.
> >
> > > It's an alternate to the normal ICS since it behaves a bit
> > > differently (PQ bits & all).
> >
> > AFAICT the PQ bits are effectively another filtering layer on top of
> > the same ICS logic as elsewhere. I think it's better if we can share
> > that shared logic, rather than replicating it.
>
> I don't know, is there much shared logic ? And the shared bits are the
> subclassing, that's handled that way...
>
> This is really a different piece of HW, a separate ICS implementation,
> that has its own quirks, is configured via different registers, does
> EOI differently etc...
>
> Even the resend stuff is done differently, the resend bitmap is
> actually SW visible via an IODA table.
>
> I mean, we could (maybe we do these days not sure) have an ICS
> superclass wrapper on the actual icp_irq() but that's really all there
> is to it I think.
Hm, yeah, fair enough. I realized what I was suggesting would
actually need another layer of qirqs than we have, so it's not a good
idea after all. Ok, I'm happy proceeding with exposing icp_irq().
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v6 3/4] net: vhost: factor out busy polling logic to vhost_net_busy_poll()
From: Toshiaki Makita @ 2018-07-24 3:41 UTC (permalink / raw)
To: Tonghao Zhang
Cc: Linux Kernel Network Developers, toshiaki.makita1, virtualization,
mst
In-Reply-To: <CAMDZJNVVJs35kuvktTxn+mmDz7db+1K-kfuOoMUn9Z=WoayUVw@mail.gmail.com>
On 2018/07/24 12:28, Tonghao Zhang wrote:
> On Tue, Jul 24, 2018 at 10:53 AM Toshiaki Makita
> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>
>> On 2018/07/24 2:31, Tonghao Zhang wrote:
>>> On Mon, Jul 23, 2018 at 10:20 PM Toshiaki Makita
>>> <toshiaki.makita1@gmail.com> wrote:
>>>>
>>>> On 18/07/23 (月) 21:43, Tonghao Zhang wrote:
>>>>> On Mon, Jul 23, 2018 at 5:58 PM Toshiaki Makita
>>>>> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>>>>>
>>>>>> On 2018/07/22 3:04, xiangxia.m.yue@gmail.com wrote:
>>>>>>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>>>>>
>>>>>>> Factor out generic busy polling logic and will be
>>>>>>> used for in tx path in the next patch. And with the patch,
>>>>>>> qemu can set differently the busyloop_timeout for rx queue.
>>>>>>>
>>>>>>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>>>>> ---
>>>>>> ...
>>>>>>> +static void vhost_net_busy_poll_vq_check(struct vhost_net *net,
>>>>>>> + struct vhost_virtqueue *rvq,
>>>>>>> + struct vhost_virtqueue *tvq,
>>>>>>> + bool rx)
>>>>>>> +{
>>>>>>> + struct socket *sock = rvq->private_data;
>>>>>>> +
>>>>>>> + if (rx) {
>>>>>>> + if (!vhost_vq_avail_empty(&net->dev, tvq)) {
>>>>>>> + vhost_poll_queue(&tvq->poll);
>>>>>>> + } else if (unlikely(vhost_enable_notify(&net->dev, tvq))) {
>>>>>>> + vhost_disable_notify(&net->dev, tvq);
>>>>>>> + vhost_poll_queue(&tvq->poll);
>>>>>>> + }
>>>>>>> + } else if ((sock && sk_has_rx_data(sock->sk)) &&
>>>>>>> + !vhost_vq_avail_empty(&net->dev, rvq)) {
>>>>>>> + vhost_poll_queue(&rvq->poll);
>>>>>>
>>>>>> Now we wait for vq_avail for rx as well, I think you cannot skip
>>>>>> vhost_enable_notify() on tx. Probably you might want to do:
>>>>> I think vhost_enable_notify is needed.
>>>>>
>>>>>> } else if (sock && sk_has_rx_data(sock->sk)) {
>>>>>> if (!vhost_vq_avail_empty(&net->dev, rvq)) {
>>>>>> vhost_poll_queue(&rvq->poll);
>>>>>> } else if (unlikely(vhost_enable_notify(&net->dev, rvq))) {
>>>>>> vhost_disable_notify(&net->dev, rvq);
>>>>>> vhost_poll_queue(&rvq->poll);
>>>>>> }
>>>>>> }
>>>>> As Jason review as before, we only want rx kick when packet is pending at
>>>>> socket but we're out of available buffers. So we just enable notify,
>>>>> but not poll it ?
>>>>>
>>>>> } else if ((sock && sk_has_rx_data(sock->sk)) &&
>>>>> !vhost_vq_avail_empty(&net->dev, rvq)) {
>>>>> vhost_poll_queue(&rvq->poll);
>>>>> else {
>>>>> vhost_enable_notify(&net->dev, rvq);
>>>>> }
>>>>
>>>> When vhost_enable_notify() returns true the avail becomes non-empty
>>>> while we are enabling notify. We may delay the rx process if we don't
>>>> check the return value of vhost_enable_notify().
>>> I got it thanks.
>>>>>> Also it's better to care vhost_net_disable_vq()/vhost_net_enable_vq() on tx?
>>>>> I cant find why it is better, if necessary, we can do it.
>>>>
>>>> The reason is pretty simple... we are busypolling the socket so we don't
>>>> need rx wakeups during it?
>>> OK, but one question, how about rx? do we use the
>>> vhost_net_disable_vq/vhost_net_ensable_vq on rx ?
>>
>> If we are busypolling the sock tx buf? I'm not sure if polling it
>> improves the performance.
> Not the sock tx buff, when we are busypolling in handle_rx, we will
> check the tx vring via vhost_vq_avail_empty.
> So, should we the disable tvq, e.g. vhost_net_disable_vq(net, tvq)?> --
When you want to stop vq kicks from the guest you should call
vhost_disable_notify() and when you want to stop vq wakeups from the
socket you should call vhost_net_disable_vq().
You are polling vq_avail so you want to stop vq kicks thus
vhost_disable_notify() is needed and it is already called.
--
Toshiaki Makita
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: btf: fix inconsistent IS_ERR and PTR_ERR
From: Jakub Kicinski @ 2018-07-24 3:40 UTC (permalink / raw)
To: YueHaibing
Cc: ast, daniel, quentin.monnet, bhole_prashant_q7, osk, linux-kernel,
netdev, davem
In-Reply-To: <20180724025524.22012-1-yuehaibing@huawei.com>
On Tue, 24 Jul 2018 10:55:24 +0800, YueHaibing wrote:
> Fix inconsistent IS_ERR and PTR_ERR in get_btf,
> the proper pointer to be passed as argument is '*btf'
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
FWIW:
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Thanks!
^ permalink raw reply
* Re: [PATCH v6 3/6] Uprobes: Support SDT markers having reference count (semaphore)
From: Ravi Bangoria @ 2018-07-24 3:34 UTC (permalink / raw)
To: Oleg Nesterov
Cc: srikar, rostedt, mhiramat, peterz, mingo, acme,
alexander.shishkin, jolsa, namhyung, linux-kernel, ananth,
alexis.berlemont, naveen.n.rao, linux-arm-kernel, linux-mips,
linux, ralf, paul.burton, Ravi Bangoria
In-Reply-To: <20180723162629.GA8584@redhat.com>
Hi Oleg,
On 07/23/2018 09:56 PM, Oleg Nesterov wrote:
> I have a mixed feeling about this series... I'll try to summarise my thinking
> tomorrow, but I do not see any obvious problem so far. Although I have some
> concerns about 5/6, I need to re-read it after sleep.
Sure.
>
>
> On 07/16, Ravi Bangoria wrote:
>>
>> +static int delayed_uprobe_install(struct vm_area_struct *vma)
>> +{
>> + struct list_head *pos, *q;
>> + struct delayed_uprobe *du;
>> + unsigned long vaddr;
>> + int ret = 0, err = 0;
>> +
>> + mutex_lock(&delayed_uprobe_lock);
>> + list_for_each_safe(pos, q, &delayed_uprobe_list) {
>> + du = list_entry(pos, struct delayed_uprobe, list);
>> +
>> + if (!du->uprobe->ref_ctr_offset ||
>
> Is it possible to see ->ref_ctr_offset == 0 in delayed_uprobe_list?
I'll remove this check.
>
>> @@ -1072,7 +1282,13 @@ int uprobe_mmap(struct vm_area_struct *vma)
>> struct uprobe *uprobe, *u;
>> struct inode *inode;
>>
>> - if (no_uprobe_events() || !valid_vma(vma, true))
>> + if (no_uprobe_events())
>> + return 0;
>> +
>> + if (vma->vm_flags & VM_WRITE)
>> + delayed_uprobe_install(vma);
>
> Obviously not nice performance-wise... OK, I do not know if it will actually
> hurt in practice and probably we can use the better data structures if necessary.
> But can't we check MMF_HAS_UPROBES at least? I mean,
>
> if (vma->vm_flags & VM_WRITE && test_bit(MMF_HAS_UPROBES, &vma->vm_mm->flags))
> delayed_uprobe_install(vma);
>
> ?
Yes.
>
>
> Perhaps we can even add another flag later, MMF_HAS_DELAYED_UPROBES set by
> delayed_uprobe_add().
Yes, good idea.
Thanks for the review,
Ravi
^ permalink raw reply
* [GIT PULL] dts changes to use ti-sysc driver for omap4 l4
From: Tony Lindgren @ 2018-07-24 3:40 UTC (permalink / raw)
To: linux-arm-kernel
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 91f6278bfa3966529c61808bd3cb8f05d7ed5dc6:
ARM: dts: am335x: add am335x-sancloud-bbe board support (2018-07-17 01:05:37 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.19/dt-pt3-signed
for you to fetch changes up to ab8b1fdd012f41b27f85a6bb271389fd7ff349ea:
Merge branch 'omap-for-v4.19/dt-sysc-v2' into omap-for-v4.19/dt (2018-07-20 22:22:08 -0700)
----------------------------------------------------------------
Start using ti-sysc with device tree data for omap4 l4 devices
With ti-sysc driver working for most use cases, we can start converting
the omap variant SoCs to use device tree data for the interconnect target
modules instead of the legacy hwmod platform data.
We start with omap4 l4 devices excluding the ones that still depend on
a reset controller driver like DSP MMU. And we don't yet convert the l4
ABE instance as that needs a bit more work.
We also add a proper interconnect hierarchy for the devices while at it
to make further work on genpd easier and to avoid most deferred probe
issues.
At this point we are not dropping any platform data, and we initially
still use it to validate the dts data. Then in later merge cycles we
can start dropping the related platform data.
----------------------------------------------------------------
Tony Lindgren (6):
dt-bindings: Update omap l4 binding for optional registers
ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data
ARM: dts: omap4: Probe watchdog 3 with ti-sysc
ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc
ARM: dts: omap4: Add l4 ranges for 4460
Merge branch 'omap-for-v4.19/dt-sysc-v2' into omap-for-v4.19/dt
Documentation/devicetree/bindings/arm/omap/l4.txt | 15 +-
arch/arm/boot/dts/omap4-l4.dtsi | 2444 +++++++++++++++++++++
arch/arm/boot/dts/omap4-panda-es.dts | 2 +-
arch/arm/boot/dts/omap4.dtsi | 812 +------
arch/arm/boot/dts/omap4460.dtsi | 36 +
5 files changed, 2526 insertions(+), 783 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-l4.dtsi
^ permalink raw reply
* [GIT PULL] dts changes to use ti-sysc driver for omap4 l4
From: Tony Lindgren @ 2018-07-24 3:40 UTC (permalink / raw)
To: arm; +Cc: Tony Lindgren, linux-omap, linux-arm-kernel
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 91f6278bfa3966529c61808bd3cb8f05d7ed5dc6:
ARM: dts: am335x: add am335x-sancloud-bbe board support (2018-07-17 01:05:37 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.19/dt-pt3-signed
for you to fetch changes up to ab8b1fdd012f41b27f85a6bb271389fd7ff349ea:
Merge branch 'omap-for-v4.19/dt-sysc-v2' into omap-for-v4.19/dt (2018-07-20 22:22:08 -0700)
----------------------------------------------------------------
Start using ti-sysc with device tree data for omap4 l4 devices
With ti-sysc driver working for most use cases, we can start converting
the omap variant SoCs to use device tree data for the interconnect target
modules instead of the legacy hwmod platform data.
We start with omap4 l4 devices excluding the ones that still depend on
a reset controller driver like DSP MMU. And we don't yet convert the l4
ABE instance as that needs a bit more work.
We also add a proper interconnect hierarchy for the devices while at it
to make further work on genpd easier and to avoid most deferred probe
issues.
At this point we are not dropping any platform data, and we initially
still use it to validate the dts data. Then in later merge cycles we
can start dropping the related platform data.
----------------------------------------------------------------
Tony Lindgren (6):
dt-bindings: Update omap l4 binding for optional registers
ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data
ARM: dts: omap4: Probe watchdog 3 with ti-sysc
ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc
ARM: dts: omap4: Add l4 ranges for 4460
Merge branch 'omap-for-v4.19/dt-sysc-v2' into omap-for-v4.19/dt
Documentation/devicetree/bindings/arm/omap/l4.txt | 15 +-
arch/arm/boot/dts/omap4-l4.dtsi | 2444 +++++++++++++++++++++
arch/arm/boot/dts/omap4-panda-es.dts | 2 +-
arch/arm/boot/dts/omap4.dtsi | 812 +------
arch/arm/boot/dts/omap4460.dtsi | 36 +
5 files changed, 2526 insertions(+), 783 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-l4.dtsi
^ permalink raw reply
* Re: [PATCH v5 net-next 0/6] net: ethernet: ti: cpsw: add MQPRIO and CBS Qdisc offload
From: David Miller @ 2018-07-24 3:38 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: grygorii.strashko, corbet, akpm, netdev, linux-doc, linux-kernel,
linux-omap, vinicius.gomes, henrik, jesus.sanchez-palencia,
ilias.apalodimas, p-varis, spatton, francois.ozog, yogeshs,
nsekhar, andrew
In-Reply-To: <20180723212634.3219-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 24 Jul 2018 00:26:28 +0300
> This series adds MQPRIO and CBS Qdisc offload for TI cpsw driver.
> It potentially can be used in audio video bridging (AVB) and time
> sensitive networking (TSN).
>
> Patchset was tested on AM572x EVM and BBB boards. Last patch from this
> series adds detailed description of configuration with examples. For
> consistency reasons, in role of talker and listener, tools from
> patchset "TSN: Add qdisc based config interface for CBS" were used and
> can be seen here: https://www.spinics.net/lists/netdev/msg460869.html
>
> Based on net-next/master
Series applied, thanks Ivan.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 net-next 0/6] net: ethernet: ti: cpsw: add MQPRIO and CBS Qdisc offload
From: David Miller @ 2018-07-24 3:38 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: grygorii.strashko, corbet, akpm, netdev, linux-doc, linux-kernel,
linux-omap, vinicius.gomes, henrik, jesus.sanchez-palencia,
ilias.apalodimas, p-varis, spatton, francois.ozog, yogeshs,
nsekhar, andrew
In-Reply-To: <20180723212634.3219-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 24 Jul 2018 00:26:28 +0300
> This series adds MQPRIO and CBS Qdisc offload for TI cpsw driver.
> It potentially can be used in audio video bridging (AVB) and time
> sensitive networking (TSN).
>
> Patchset was tested on AM572x EVM and BBB boards. Last patch from this
> series adds detailed description of configuration with examples. For
> consistency reasons, in role of talker and listener, tools from
> patchset "TSN: Add qdisc based config interface for CBS" were used and
> can be seen here: https://www.spinics.net/lists/netdev/msg460869.html
>
> Based on net-next/master
Series applied, thanks Ivan.
^ permalink raw reply
* [PATCH 1/2 V3] xfs_repair: notify user if free inodes contain errors
From: Eric Sandeen @ 2018-07-24 2:34 UTC (permalink / raw)
To: Eric Sandeen, linux-xfs
In-Reply-To: <b6f745ab-3016-9a95-3085-8584f7200b64@redhat.com>
xfs_repair checks allocated but unused (free) inodes in on-disk clusters,
and up until now silently repairs any errors, and as a result does not
alter exit status if errors are found.
The in-kernel verifiers will be noisy about these errors and instruct
the user to run repair, so it's best if repair is explicit about any
fixes it makes as a result.
To ensure we catch anything the kernel would complain about, re-use
xfs_dinode_verify to determine whether we must clear a free inode.
Note, however, that the verifier contains only a subset of the checks
currently in clear_dinode. This should be ok; if it's not, the checks
should be added to the verifier in any case.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
diff --git a/libxfs/libxfs_api_defs.h b/libxfs/libxfs_api_defs.h
index a98483b..05c06a7 100644
--- a/libxfs/libxfs_api_defs.h
+++ b/libxfs/libxfs_api_defs.h
@@ -134,6 +134,7 @@
#define xfs_symlink_hdr_ok libxfs_symlink_hdr_ok
#define xfs_verify_cksum libxfs_verify_cksum
+#define xfs_dinode_verify libxfs_dinode_verify
#define xfs_alloc_ag_max_usable libxfs_alloc_ag_max_usable
#define xfs_allocbt_maxrecs libxfs_allocbt_maxrecs
diff --git a/repair/dinode.c b/repair/dinode.c
index d36338f..c0db15a 100644
--- a/repair/dinode.c
+++ b/repair/dinode.c
@@ -2560,12 +2560,20 @@ _("bad (negative) size %" PRId64 " on inode %" PRIu64 "\n"),
*/
if (was_free) {
/*
- * easy case, inode free -- inode and map agree, clear
+ * easy case, inode free -- inode and map agree, check
* it just in case to ensure that format, etc. are
* set correctly
*/
- if (!no_modify)
- *dirty += clear_dinode(mp, dino, lino);
+ if (libxfs_dinode_verify(mp, lino, dino) != NULL) {
+ do_warn(
+ _("free inode %" PRIu64 " contains errors, "), lino);
+ if (!no_modify) {
+ *dirty += clear_dinode(mp, dino, lino);
+ do_warn(_("corrected\n"));
+ } else {
+ do_warn(_("would correct\n"));
+ }
+ }
*used = is_free;
return 0;
}
^ permalink raw reply related
* WARNING in port_delete
From: Dae R. Jeong @ 2018-07-24 3:36 UTC (permalink / raw)
To: perex, tiwai, colin.king
Cc: alsa-devel, linux-kernel, lifeasageek, kt0755, bammanag
Reporting the crash: WARNING in port_delete
This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
version of Syzkaller), which we descrbie more at the end of this
report. Our analysis shows that the race occurs when invoking two close
syscalls concurrently.
The executed program is as follows:
r0 = open("/dev/snd/seq", 0x0, 0x0)
ioctl(r0, SNDRV_SEQ_IOCTL_CREATE_PORT, {{0x80}, "706f72943000000000000000000000000000000000000000000000000000000000233f770800000000000000000000000000000000000000001000", 0xffffffffffffffff, 0xfffffffffffffbff})
r1 = openat(AT_FDCWD, "/dev/sequencer2", 0x8402, 0x0)
close(r0)
close(r1)
and two threads executed the program as follows:
Thread0 Thread1
open("/dev/snd/seq")
ioctl(r0, SNDRV_SEQ_IOCTL_CREATE_PORT)
openat("/dev/sequencer2")
close(r0) close(r1)
(Note that two close() syscalls were exeuted after openat() syscall, and
two close() syscalls were executed concurrently.)
Crash log:
==================================================================
WARNING: CPU: 1 PID: 32519 at /home/daeryong/workspace/race-fuzzer/kernels_repo/kernel_v4.18-rc3/sound/core/seq/seq_ports.c:275 port_delete+0xde/0xf0 sound/core/seq/seq_ports.c:275
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 32519 Comm: syz-executor0 Not tainted 4.18.0-rc3 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x16e/0x22c lib/dump_stack.c:113
panic+0x1a8/0x3a7 kernel/panic.c:184
__warn+0x191/0x1a0 kernel/panic.c:536
report_bug+0x132/0x1b0 lib/bug.c:186
fixup_bug.part.10+0x28/0x50 arch/x86/kernel/traps.c:178
fixup_bug arch/x86/kernel/traps.c:247 [inline]
do_error_trap+0x284/0x2c0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:port_delete+0xde/0xf0 sound/core/seq/seq_ports.c:275
Code: 00 00 e8 b5 68 d2 fd 8b 83 58 01 00 00 85 c0 75 1d e8 86 5c ae fd 48 89 df e8 3e 52 d2 fd 31 c0 5b 41 5c 5d c3 e8 72 5c ae fd <0f> 0b eb c8 e8 69 5c ae fd 0f 0b eb da 0f 1f 44 00 00 55 48 89 e5
RSP: 0018:ffff8801d635f900 EFLAGS: 00010216
RAX: 0000000000040000 RBX: ffff8801da196900 RCX: ffffffff839b86ee
RDX: 0000000000005e94 RSI: ffffc90002640000 RDI: ffff8801da196978
RBP: ffff8801d635f910 R08: 0000000000000098 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff839ba820
R13: ffff8801da196950 R14: ffff8801ed5bc080 R15: ffff8801da196958
snd_seq_delete_port+0x2b0/0x2d0 sound/core/seq/seq_ports.c:303
snd_seq_ioctl_delete_port+0x5b/0xa0 sound/core/seq/seq_clientmgr.c:1325
snd_seq_kernel_client_ctl+0xd4/0xf0 sound/core/seq/seq_clientmgr.c:2361
snd_seq_event_port_detach+0xcb/0x120 sound/core/seq/seq_ports.c:705
delete_port+0x3a/0x70 sound/core/seq/oss/seq_oss_init.c:354
snd_seq_oss_release+0x7c/0x90 sound/core/seq/oss/seq_oss_init.c:433
odev_release+0x40/0x60 sound/core/seq/oss/seq_oss.c:153
__fput+0x234/0x470 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x15a/0x1c0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:192 [inline]
exit_to_usermode_loop+0x2a3/0x2b0 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x485/0x4b0 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x456469
Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fe9a8936b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 000000000072bfa0 RCX: 0000000000456469
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000014
RBP: 0000000000000054 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe9a89376d4
R13: 00000000ffffffff R14: 00000000006f5880 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
= About RaceFuzzer
RaceFuzzer is a customized version of Syzkaller, specifically tailored
to find race condition bugs in the Linux kernel. While we leverage
many different technique, the notable feature of RaceFuzzer is in
leveraging a custom hypervisor (QEMU/KVM) to interleave the
scheduling. In particular, we modified the hypervisor to intentionally
stall a per-core execution, which is similar to supporting per-core
breakpoint functionality. This allows RaceFuzzer to force the kernel
to deterministically trigger racy condition (which may rarely happen
in practice due to randomness in scheduling).
RaceFuzzer's C repro always pinpoints two racy syscalls. Since C
repro's scheduling synchronization should be performed at the user
space, its reproducibility is limited (reproduction may take from 1
second to 10 minutes (or even more), depending on a bug). This is
because, while RaceFuzzer precisely interleaves the scheduling at the
kernel's instruction level when finding this bug, C repro cannot fully
utilize such a feature. Please disregard all code related to
"should_hypercall" in the C repro, as this is only for our debugging
purposes using our own hypervisor.
^ permalink raw reply
* [PATCH v6 3/6] Uprobes: Support SDT markers having reference count (semaphore)
From: Ravi Bangoria @ 2018-07-24 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723162629.GA8584@redhat.com>
Hi Oleg,
On 07/23/2018 09:56 PM, Oleg Nesterov wrote:
> I have a mixed feeling about this series... I'll try to summarise my thinking
> tomorrow, but I do not see any obvious problem so far. Although I have some
> concerns about 5/6, I need to re-read it after sleep.
Sure.
>
>
> On 07/16, Ravi Bangoria wrote:
>>
>> +static int delayed_uprobe_install(struct vm_area_struct *vma)
>> +{
>> + struct list_head *pos, *q;
>> + struct delayed_uprobe *du;
>> + unsigned long vaddr;
>> + int ret = 0, err = 0;
>> +
>> + mutex_lock(&delayed_uprobe_lock);
>> + list_for_each_safe(pos, q, &delayed_uprobe_list) {
>> + du = list_entry(pos, struct delayed_uprobe, list);
>> +
>> + if (!du->uprobe->ref_ctr_offset ||
>
> Is it possible to see ->ref_ctr_offset == 0 in delayed_uprobe_list?
I'll remove this check.
>
>> @@ -1072,7 +1282,13 @@ int uprobe_mmap(struct vm_area_struct *vma)
>> struct uprobe *uprobe, *u;
>> struct inode *inode;
>>
>> - if (no_uprobe_events() || !valid_vma(vma, true))
>> + if (no_uprobe_events())
>> + return 0;
>> +
>> + if (vma->vm_flags & VM_WRITE)
>> + delayed_uprobe_install(vma);
>
> Obviously not nice performance-wise... OK, I do not know if it will actually
> hurt in practice and probably we can use the better data structures if necessary.
> But can't we check MMF_HAS_UPROBES at least? I mean,
>
> if (vma->vm_flags & VM_WRITE && test_bit(MMF_HAS_UPROBES, &vma->vm_mm->flags))
> delayed_uprobe_install(vma);
>
> ?
Yes.
>
>
> Perhaps we can even add another flag later, MMF_HAS_DELAYED_UPROBES set by
> delayed_uprobe_add().
Yes, good idea.
Thanks for the review,
Ravi
^ permalink raw reply
* Re: [PATCH v1 4/9] scsi: ufs: add option to change default UFS power management level
From: Asutosh Das (asd) @ 2018-07-24 3:34 UTC (permalink / raw)
To: Rob Herring
Cc: Subhash Jadavani, Can Guo, Vivek Gautam, Rajendra Nayak,
Vinayak Holikatti, James E.J. Bottomley, Martin K. Petersen,
linux-scsi, linux-arm-msm, Venkat Gopalakrishnan, Mark Rutland,
Mathieu Malaterre, devicetree, linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqLXUvUj8n=1Xv-_ssqB6rayMvxOTnGzeN1vS9yx4-jqOQ@mail.gmail.com>
On 7/23/2018 8:06 PM, Rob Herring wrote:
> On Sun, Jul 22, 2018 at 9:20 PM Asutosh Das (asd)
> <asutoshd@codeaurora.org> wrote:
>>
>> On 7/12/2018 2:03 AM, Rob Herring wrote:
>>> On Fri, Jul 06, 2018 at 06:00:31PM +0530, Asutosh Das wrote:
>>>> From: Subhash Jadavani <subhashj@codeaurora.org>
>>>>
>>>> UFS device and link can be put in multiple different low power modes hence
>>>> UFS driver supports multiple different low power modes. By default UFS
>>>> driver selects the default (optimal) low power mode (which gives moderate
>>>> power savings and have relatively less enter and exit latencies) but
>>>> we might have to tune this default power mode for different chipset
>>>> platforms to meet the low power requirements/goals. Hence this patch
>>>> adds option to change default UFS low power mode (level).
>>>>
>>>> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
>>>> Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
>>>> Signed-off-by: Can Guo <cang@codeaurora.org>
>>>> Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
>>>> ---
>>>> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 11 ++++++++
>>>> drivers/scsi/ufs/ufshcd-pltfrm.c | 14 +++++++++++
>>>> drivers/scsi/ufs/ufshcd.c | 29 +++++++++++++++-------
>>>> drivers/scsi/ufs/ufshcd.h | 4 +--
>>>> 4 files changed, 47 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>>> index c39dfef..f564d9a 100644
>>>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>>> @@ -38,6 +38,15 @@ Optional properties:
>>>> defined or a value in the array is "0" then it is assumed
>>>> that the frequency is set by the parent clock or a
>>>> fixed rate clock source.
>>>> +- rpm-level : UFS Runtime power management level. Following PM levels are supported:
>>>> + 0 - Both UFS device and Link in active state (Highest power consumption)
>>>> + 1 - UFS device in active state but Link in Hibern8 state
>>>> + 2 - UFS device in Sleep state but Link in active state
>>>> + 3 - UFS device in Sleep state and Link in hibern8 state (default PM level)
>>>> + 4 - UFS device in Power-down state and Link in Hibern8 state
>>>> + 5 - UFS device in Power-down state and Link in OFF state (Lowest power consumption)
>>>> +- spm-level : UFS System power management level. Allowed PM levels are same as rpm-level.
>>>
>>> What's the default?
>>>
>>> I assume these are minimums? The OS can pick higher power states. This
>>> seems to be a bit Linux specific (as 'runtime PM' could be considered
>>> Linux specific). For every other device, we don't put this type of
>>> information in DT, but is user controlled.
>> I didn't completely understand your comment.
>> Do you not want these properties to be in DT file?
>
> Right, not if it is a user decision.
>
>> When you say user-controlled, do you mean control it through sysfs entries?
>
> Yes.
>
>>> So really, wouldn't 1
>>> property be sufficient for cases where a mode doesn't work due to
>>> some h/w limitation. Otherwise, it is an OS or user decision.
>> I didn't completely understand this. Could you please elaborate on your
>> intent here?
>
> The case that makes sense for this to be in DT is if there are h/w
> limitations that prevent some low power modes. In such a case, that
> limit is not likely specific to runtime PM or system suspend.
>
>>>> -lanes-per-direction : number of lanes available per direction - either 1 or 2.
>>>> Note that it is assume same number of lanes is used both
>>>> directions at once. If not specified, default is 2 lanes per direction.
>>>> @@ -66,4 +75,6 @@ Example:
>>>> freq-table-hz = <100000000 200000000>, <0 0>, <0 0>;
>>>> phys = <&ufsphy1>;
>>>> phy-names = "ufsphy";
>>>> + rpm-level = <3>;
>>>
>>> Why specified if 3 is the default?
>> Ah yes - that should be removed.
>> I'll remove it in v2.
>>
>>>
>>>> + spm-level = <5>;
>>>
>>> These seem like sane defaults. When and why would you use some
>>> different?
>> I think each of the deeper sleep modes are associated with an increasing
>> wakeup latency. For e.g. '0' would have the highest power-consumption
>> and no resume latency at all as compared to '5'.
>> So depending on use-cases other modes may be chosen.
>
> The use-case can change in a running system. For example if you are
> plugged in, then you probably don't want to enter a lower power mode.
>
> Rob
>
Ok - Thanks.
I'm gonna make the following changes in v2:
1. Remove these entries from DT
2. Add support for these entries in sysfs.
3. Keep 3 as the default value for [rpm/spm]-levels
-asd
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [Fuego] [PATCH] busybox: add support for command head/hexdump/hostname/id/ifconfig/install
From: Wang, Mingyu @ 2018-07-24 3:33 UTC (permalink / raw)
To: Tim.Bird@sony.com, fuego@lists.linuxfoundation.org
In-Reply-To: <ECADFF3FD767C149AD96A924E7EA6EAF7C1B5810@USCULXMSG01.am.sony.com>
Hi Tim,
The test script for command id and install have been modified.
Other comments are also confirmed and fixed.
Please check the new patch.
by Wangmy
-----Original Message-----
From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
Sent: Tuesday, July 24, 2018 7:35 AM
To: Wang, Mingyu/王 鸣瑜 <wangmy@cn.fujitsu.com>; fuego@lists.linuxfoundation.org
Subject: RE: [Fuego] [PATCH] busybox: add support for command head/hexdump/hostname/id/ifconfig/install
See comments inline below.
> -----Original Message-----
> From: Wang Mingyu
>
> Signed-off-by: Wang Mingyu <wangmy@cn.fujitsu.com>
> ---
> .../tests/Functional.busybox/tests/busybox_head.sh | 22
> ++++++++++++++++++++++
> .../Functional.busybox/tests/busybox_hexdump.sh | 19
> +++++++++++++++++++
> .../Functional.busybox/tests/busybox_hostname.sh | 13 +++++++++++++
> .../tests/Functional.busybox/tests/busybox_id.sh | 13 +++++++++++++
> .../Functional.busybox/tests/busybox_ifconfig.sh | 13 +++++++++++++
> .../Functional.busybox/tests/busybox_install.sh | 17 +++++++++++++++++
> 6 files changed, 97 insertions(+)
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_head.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_hostname.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_id.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_install.sh
>
> diff --git a/engine/tests/Functional.busybox/tests/busybox_head.sh
> b/engine/tests/Functional.busybox/tests/busybox_head.sh
> new file mode 100644
> index 0000000..be0269e
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_head.sh
> @@ -0,0 +1,22 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command head #
> +1) Option -n
> +
> +test="head"
> +
> +mkdir test_dir
> +touch test_dir/test1
This is not needed (the 'touch')
> +echo "This is the 1st line.">test_dir/test1 echo "This is the 2nd
> +line.">>test_dir/test1 echo "This is the 3rd line.">>test_dir/test1
> +busybox head -n 2 test_dir/test1 > log
Please use a space before the redirection operator.
> +
> +if [ "$(busybox head -n 1 log)" = "This is the 1st line." ] && [ "$(tail -n 1 log)"
> = "This is the 2nd line." ]
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> +rm log
> +rm -rf test_dir
> diff --git a/engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> b/engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> new file mode 100644
> index 0000000..d598c72
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> @@ -0,0 +1,19 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command hexdump
> +# 1) Option: -c
> +
> +test="hexdump"
> +
> +mkdir test_dir
> +touch test_dir/test1
> +echo "HELLO WORLD">test_dir/test1
> +busybox hexdump -c test_dir/test1 > log
> +if head -n 1 log | grep "0000000 H E L L O W O R L D \\\n" && [
> "$(tail -n 1 log)" = "000000c" ]
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> +rm log
> +rm -rf test_dir
> diff --git a/engine/tests/Functional.busybox/tests/busybox_hostname.sh
> b/engine/tests/Functional.busybox/tests/busybox_hostname.sh
> new file mode 100644
> index 0000000..f854515
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_hostname.sh
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command hostname
> +# 1) Option none
> +
> +test="hostname"
> +
> +if [ $(busybox hostname) = $(hostname) ]
On a busybox-based system, this just tests the program against itself.
Maybe compare with $(cat /etc/hostname)?
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> diff --git a/engine/tests/Functional.busybox/tests/busybox_id.sh
> b/engine/tests/Functional.busybox/tests/busybox_id.sh
> new file mode 100644
> index 0000000..9f53fcc
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_id.sh
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command id
> +# 1) Option none
> +
> +test="id"
> +
> +if [ "$(busybox id)" = "$(id)" ]
Same issue here. If busybox is the main tool for a board, then
'id' will just be a symlink to busybox, and this test just verifies
that the same command produces the same output.
This one I'm not sure what to do with this one. Maybe
see if there's a shell variable that has the UID?
Or, check that 'id' is not 'busybox id'?
Let me know what you think.
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> diff --git a/engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> b/engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> new file mode 100644
> index 0000000..31b07d2
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command ifconfig
> +# 1) Option none
> +
> +test="ifconfig"
> +
> +if busybox ifconfig
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> diff --git a/engine/tests/Functional.busybox/tests/busybox_install.sh
> b/engine/tests/Functional.busybox/tests/busybox_install.sh
> new file mode 100644
> index 0000000..a8cba56
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_install.sh
> @@ -0,0 +1,17 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command install
> +# 1) Option none
> +
> +test="install"
> +
> +mkdir test_dir test_install_dir
> +echo "ls test_install_dir">test_dir/test1
I'm not sure what's going on here.
test1 should have the contents: 'ls test_install_dir'.
It's not clear to me that this is executable.
> +busybox install test_dir/test1 test_install_dir
> +if [ $(./test_install_dir/test1) = test1 ]
Are you trying to execute the script?
I'm confused.
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> +rm -rf test_dir test_install_dir;
> --
> 1.8.3.1
Thanks for the patch.
Please address my feedback and re-submit.
(Note: Sorry - but I will be out-of-the-office the rest of this week,
so my responses will be delayed until next week.)
Regards,
-- Tim
^ permalink raw reply
* Re: [Fuego] [PATCH] busybox: modify the code of option g+x in chmod1 test
From: Wang, Mingyu @ 2018-07-24 3:33 UTC (permalink / raw)
To: Tim.Bird@sony.com, fuego@lists.linuxfoundation.org
In-Reply-To: <ECADFF3FD767C149AD96A924E7EA6EAF7C1B57F3@USCULXMSG01.am.sony.com>
Hi Tim,
I didn't find out where the problem was. Maybe because my mail client is in Chinese.
I have changed it to the English version and revised the patch and sent it again.
by Wangmy
-----Original Message-----
From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
Sent: Tuesday, July 24, 2018 7:25 AM
To: Wang, Mingyu/王 鸣瑜 <wangmy@cn.fujitsu.com>; fuego@lists.linuxfoundation.org
Subject: RE: [Fuego] [PATCH] busybox: modify the code of option g+x in chmod1 test
OK - this is applied and pushed. But it was a bit harder to apply than anticipated because your mailer decided to put the message body in base64 encoding.
You other patches don't have this issue. I'm not sure what happened on this one. The only thing I can think of is maybe there was a non-8-bit-ASCII character somewhere in the patch? The only "strange" characters are the quotes (maybe in the patch message) - maybe one of those got turned into a Unicode char or some other extended character-set character.
If you can, please check this.
-- Tim
> -----Original Message-----
> From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-
> bounces@lists.linuxfoundation.org] On Behalf Of Wang Mingyu
> Sent: Sunday, July 22, 2018 10:35 PM
> To: fuego@lists.linuxfoundation.org
> Subject: [Fuego] [PATCH] busybox: modify the code of option g+x in
> chmod1 test
>
> Change the cut to retrieve the group permission bytes, to check that
> they are 'execute' ('x').
>
> Signed-off-by: Wang Mingyu <wangmy@cn.fujitsu.com>
> ---
> engine/tests/Functional.busybox/tests/busybox_chmod1.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> b/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> index cdc7d18..2eef95a 100644
> --- a/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> +++ b/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> @@ -21,7 +21,7 @@ else
> fi;
>
> busybox chmod g+x ./test_dir/test1
> -if [ "$(busybox ls -l ./test_dir | grep -v "total" | cut -b 1-3)" =
> "-rw" ]
> +if [ "$(busybox ls -l ./test_dir | grep -v "total" | cut -b 5-7)" =
> +"r-x" ]
> then
> echo " -> $test: Changed file permissions verification#2 succeeded."
> else
> --
> 1.8.3.1
>
>
>
> _______________________________________________
> Fuego mailing list
> Fuego@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/fuego
^ permalink raw reply
* [PATCH 0/2 V3] xfs_repair: rework inode clearing and free inode validation
From: Eric Sandeen @ 2018-07-24 2:27 UTC (permalink / raw)
To: linux-xfs
Warn the user if any free inodes contain errors, and set exit code
in the process. Do this by running the existing dinode verifier and
clearing / warning if it fails.
2nd patch separates out the inode validation from the clearing function
There is a functional change here which I'm on the fence about; free
inodes are now only cleared if they won't pass the dinode verifier,
which is the only thing the kernel would squawk about. But that's
a subset of the clear_inode checks.
The old clear_dinode function checked a lot of things that the
verifier simply doesn't care about, but I think it's ok for
those tests to go away; if the kernel does care about, say, extent
count on a free inode, the verifier should test it.
^ permalink raw reply
* Re: [PATCH v2 2/2] clk: qcom: Add qspi (Quad SPI) clocks for sdm845
From: Doug Anderson @ 2018-07-24 3:30 UTC (permalink / raw)
To: Taniya Das
Cc: Stephen Boyd, Andy Gross, grahamr, Girish Mahadevan, Amit Nischal,
Bjorn Andersson, Michael Turquette, linux-arm-msm, LKML,
David Brown, open list:ARM/QUALCOMM SUPPORT, linux-clk
In-Reply-To: <f4f92dcd-7a63-f9de-a7a0-c403672d5c6c@codeaurora.org>
Hi,
On Mon, Jul 23, 2018 at 7:22 PM, Taniya Das <tdas@codeaurora.org> wrote:
>
>
> On 7/24/2018 3:24 AM, Douglas Anderson wrote:
>>
>> Add both the interface and core clock.
>>
>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>> ---
>>
>> Changes in v2:
>> - Only 19.2, 100, 150, and 300 MHz now.
>> - All clocks come from MAIN rather than EVEN.
>> - Use parent map 0 instead of new parent map 9.
>>
>> drivers/clk/qcom/gcc-sdm845.c | 63 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 63 insertions(+)
>>
>> diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
>> index 0f694ed4238a..5bca634e277a 100644
>> --- a/drivers/clk/qcom/gcc-sdm845.c
>> +++ b/drivers/clk/qcom/gcc-sdm845.c
>> @@ -162,6 +162,13 @@ static const char * const gcc_parent_names_10[] = {
>> "core_bi_pll_test_se",
>> };
>> +static const char * const gcc_parent_names_9[] = {
>> + "bi_tcxo",
>> + "gpll0",
>> + "gpll0_out_even",
>> + "core_pi_sleep_clk",
>> +};
>> +
>
>
> Please remove this.
Oops, that's embarrassing. Please stay tuned for v3.
-Doug
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.