Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac
On Thu, Aug 04, 2016 at 11:39:14PM +, york sun wrote: > I will rename it if I respin this patch for any reason. Otherwise, I > will send out another patch to rename it after merging. Feel free to send an updated one as a reply to this thread. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
Re: [PATCH v2] powerpc/32: fix csum_partial_copy_generic()
Alessio Igor Bogani writes:
> On 4 August 2016 at 05:53, Scott Wood wrote:
>> On Tue, 2016-08-02 at 10:07 +0200, Christophe Leroy wrote:
>>> commit 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
>>> based on copy_tofrom_user()") introduced a bug when destination
>>> address is odd and initial csum is not null
>>>
>>> In that (rare) case the initial csum value has to be rotated one byte
>>> as well as the resulting value is
>>>
>>> This patch also fixes related comments
>>>
>>> Fixes: 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
>>> based on copy_tofrom_user()")
>>> Cc: sta...@vger.kernel.org
>>>
>>> Signed-off-by: Christophe Leroy
>>> ---
>>> v2: updated comments as suggested by Segher
>>>
>>> arch/powerpc/lib/checksum_32.S | 7 ---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> Alessio, can you confirm whether this fixes the problem you reported?
>
> No unfortunately.
Thanks for testing.
I've dropped the patch for now, send me a new one that works.
cheers
RE: [RFC PATCH v3 1/2] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation
Hi Rob,
Thanks for the review...
> > +XILINX GMIITORGMII Converter Driver Device Tree Bindings
> > +
> > +
> > +The Gigabit Media Independent Interface (GMII) to Reduced Gigabit
> > +Media Independent Interface (RGMII) core provides the RGMII between
> > +RGMII-compliant Ethernet physical media devices (PHY) and the Gigabit
> Ethernet controller.
> > +This core can be used in all three modes of operation(10/100/1000 Mb/s).
> > +The Management Data Input/Output (MDIO) interface is used to
> > +configure the Speed of operation. This core can switch dynamically
> > +between the three Different speed modes by configuring the conveter
> register through mdio write.
> > +
> > +The MDIO is a bus to which the PHY devices are connected. For each
> > +device that exists on this bus, a child node should be created. See
> > +the definition of the PHY node in booting-without-of.txt for an
> > +example of how to define a PHY.
> > +
> > +Required properties:
> > + - compatible : Should be "xilinx,gmiitorgmii"
>
> Perhaps xilinx,gmii-to-rgmii.
Sure...
>
> This needs some sort of version information in the compatible string.
Sure will fix in the next version...
>
> > + - reg : The ID number for the phy, usually a small integer
> > +
> > +Example:
> > + mdio {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > + ethernet-phy@0 {
> > + ..
> > + };
> > +gmii_to_rgmii: gmii_to_rgmii@8 {
>
> Don't use underscores in node names.
Ok will fix in the next version...
Regards,
Kedar.
RE: [PATCH] mpt3sas: Don't spam logs if logging level is 0
Hi, Please consider this patch as Acked-by: Chaitra P B Thanks, Chaitra -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Johannes Thumshirn Sent: Wednesday, August 03, 2016 6:30 PM To: Martin K . Petersen; James Bottomley Cc: Linux SCSI Mailinglist; Linux Kernel Mailinglist; Sreekanth Reddy; Johannes Thumshirn Subject: [PATCH] mpt3sas: Don't spam logs if logging level is 0 In _scsih_io_done() we test if the ioc->logging_level does _not_ have the MPT_DEBUG_REPLY bit set and if it hasn't we print the debug messages. This unfortunately is the wrong way around. Note, the actual bug is older than af0094115 but this commit removed the CONFIG_SCSI_MPT3SAS_LOGGING Kconfig option which hid the bug. Fixes: af0094115 'mpt2sas, mpt3sas: Remove SCSI_MPTXSAS_LOGGING entry from Kconfig' Signed-off-by: Johannes Thumshirn --- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c index 4a1cc85..a138690 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -4693,7 +4693,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply) le16_to_cpu(mpi_reply->DevHandle)); mpt3sas_trigger_scsi(ioc, data.skey, data.asc, data.ascq); - if (!(ioc->logging_level & MPT_DEBUG_REPLY) && + if ((ioc->logging_level & MPT_DEBUG_REPLY) && ((scmd->sense_buffer[2] == UNIT_ATTENTION) || (scmd->sense_buffer[2] == MEDIUM_ERROR) || (scmd->sense_buffer[2] == HARDWARE_ERROR))) -- 1.8.5.6 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] net: phy: micrel: Add specific suspend
Disable all interrupts when suspend, they will be enabled
when resume. Otherwise, the suspend/resume process will be
blocked occasionally.
Signed-off-by: Wenyou Yang
Acked-by: Nicolas Ferre
---
Changes in v2:
- Use fairly generic phydrv->config_intr() with
PHY_INTERRUPT_DISABLED, then call genphy_suspend().
- Modify kszphy_resume() with PHY_INTERRUPT_ENABLED accordingly.
- Add static attribute for kszphy_suspend().
drivers/net/phy/micrel.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 5a8fefc..b598d46 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -647,17 +647,28 @@ static void kszphy_get_stats(struct phy_device *phydev,
data[i] = kszphy_get_stat(phydev, i);
}
-static int kszphy_resume(struct phy_device *phydev)
+static int kszphy_suspend(struct phy_device *phydev)
{
- int value;
+ /* Disable PHY Interrupts */
+ if (phy_interrupt_is_valid(phydev)) {
+ phydev->interrupts = PHY_INTERRUPT_DISABLED;
+ if (phydev->drv->config_intr)
+ phydev->drv->config_intr(phydev);
+ }
- mutex_lock(&phydev->lock);
+ return genphy_suspend(phydev);
+}
- value = phy_read(phydev, MII_BMCR);
- phy_write(phydev, MII_BMCR, value & ~BMCR_PDOWN);
+static int kszphy_resume(struct phy_device *phydev)
+{
+ genphy_resume(phydev);
- kszphy_config_intr(phydev);
- mutex_unlock(&phydev->lock);
+ /* Enable PHY Interrupts */
+ if (phy_interrupt_is_valid(phydev)) {
+ phydev->interrupts = PHY_INTERRUPT_ENABLED;
+ if (phydev->drv->config_intr)
+ phydev->drv->config_intr(phydev);
+ }
return 0;
}
@@ -870,7 +881,7 @@ static struct phy_driver ksphy_driver[] = {
.get_sset_count = kszphy_get_sset_count,
.get_strings= kszphy_get_strings,
.get_stats = kszphy_get_stats,
- .suspend= genphy_suspend,
+ .suspend= kszphy_suspend,
.resume = kszphy_resume,
}, {
.phy_id = PHY_ID_KSZ8061,
--
2.7.4
RE: [PATCH] mpt3sas: Ensure the connector_name string is NUL-terminated
Hi,
Please consider this patch as Acked-by: Chaitra P B
Thanks,
Chaitra
-Original Message-
From: Calvin Owens [mailto:calvinow...@fb.com]
Sent: Thursday, July 28, 2016 10:16 AM
To: Sathya Prakash; Chaitra P B; Suganath Prabu Subramani; James E.J.
Bottomley; Martin K. Petersen
Cc: mpt-fusionlinux@broadcom.com; linux-s...@vger.kernel.org;
linux-kernel@vger.kernel.org; kernel-t...@fb.com; Calvin Owens
Subject: [PATCH] mpt3sas: Ensure the connector_name string is
NUL-terminated
We blindly trust the hardware to give us NUL-terminated strings, which is
a bad idea because it doesn't always do that. For example:
[ 481.184784] mpt3sas_cm0: enclosure level(0x), connector name(
\x3)
In this case, connector_name is four spaces. We got lucky here because the
2nd byte beyond our character array happens to be a NUL. Fix this by
explicitly writing '\0' to the end of the string to ensure we don't run
off the edge of the world in printk().
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 10 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 892c9be..eb7f5b0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -478,7 +478,7 @@ struct _sas_device {
u8 pfa_led_on;
u8 pend_sas_rphy_add;
u8 enclosure_level;
- u8 connector_name[4];
+ u8 connector_name[5];
struct kref refcount;
};
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index cd91a68..acabe48 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -5380,8 +5380,9 @@ _scsih_check_device(struct MPT3SAS_ADAPTER *ioc,
MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
le16_to_cpu(sas_device_pg0.EnclosureLevel);
- memcpy(&sas_device->connector_name[0],
- &sas_device_pg0.ConnectorName[0], 4);
+ memcpy(sas_device->connector_name,
+ sas_device_pg0.ConnectorName, 4);
+ sas_device->connector_name[4] = '\0';
} else {
sas_device->enclosure_level = 0;
sas_device->connector_name[0] = '\0'; @@ -5508,8
+5509,9 @@ _scsih_add_device(struct MPT3SAS_ADAPTER *ioc, u16 handle, u8
phy_num,
if (sas_device_pg0.Flags &
MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
le16_to_cpu(sas_device_pg0.EnclosureLevel);
- memcpy(&sas_device->connector_name[0],
- &sas_device_pg0.ConnectorName[0], 4);
+ memcpy(sas_device->connector_name,
+ sas_device_pg0.ConnectorName, 4);
+ sas_device->connector_name[4] = '\0';
} else {
sas_device->enclosure_level = 0;
sas_device->connector_name[0] = '\0';
--
2.8.0.rc2
RE: [RFC PATCH v3 2/2] net: phy: Add gmiitorgmii converter support
Hi zhuyj,
Thanks for the review...
>
> + switch (phydev->speed) {
> + case SPEED_1000:
> + val |= BMCR_SPEED1000;
> + case SPEED_100:
> + val |= BMCR_SPEED100;
> + }
>
> Are there only 2 kinds of speed?
Converter supports 3 different speeds will fix in the next version...
Thanks,
Kedar.
>
>
> On Thu, Aug 4, 2016 at 8:13 PM, Kedareswara rao Appana
> wrote:
> > This patch adds support for gmiitorgmii converter.
> >
> > The GMII to RGMII IP core provides the Reduced Gigabit Media
> > Independent Interface (RGMII) between Ethernet physical media Devices
> > and the Gigabit Ethernet controller. This core can Switch dynamically
> > between the three different speed modes of Operation by configuring
> > the converter register through mdio write.
> >
> > MDIO interface is used to set operating speed of Ethernet MAC.
> >
> > Signed-off-by: Kedareswara rao Appana
> > ---
> > Thanks a lot Andrew for your inputs.
> > Changes for v3:
> > --> Updated the driver as suggested by Andrew.
> > Changes for v2:
> > --> Passed struct xphy pointer directly to the fix_mac_speed
> > API as suggested by the Florian.
> > --> Added checks for the phy-node fail case as suggested
> > by the Florian
> >
> > drivers/net/phy/Kconfig | 8 +++
> > drivers/net/phy/Makefile| 1 +
> > drivers/net/phy/xilinx_gmii2rgmii.c | 121
> >
> > 3 files changed, 130 insertions(+)
> > create mode 100644 drivers/net/phy/xilinx_gmii2rgmii.c
> >
> > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index
> > 6dad9a9..eec31a3 100644
> > --- a/drivers/net/phy/Kconfig
> > +++ b/drivers/net/phy/Kconfig
> > @@ -271,6 +271,14 @@ config MDIO_BCM_IPROC
> > This module provides a driver for the MDIO busses found in the
> > Broadcom iProc SoC's.
> >
> > +config XILINX_GMII2RGMII
> > + tristate "Xilinx GMII2RGMII converter driver"
> > + default y
> > + ---help---
> > + This driver support xilinx GMII to RGMII IP core it provides
> > + the Reduced Gigabit Media Independent Interface(RGMII) between
> > + Ethernet physical media devices and the Gigabit Ethernet
> > controller.
> > +
> > endif # PHYLIB
> >
> > config MICREL_KS8995MA
> > diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile index
> > fcdbb92..8650067 100644
> > --- a/drivers/net/phy/Makefile
> > +++ b/drivers/net/phy/Makefile
> > @@ -44,3 +44,4 @@ obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
> > obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
> > obj-$(CONFIG_MICROCHIP_PHY)+= microchip.o
> > obj-$(CONFIG_MDIO_BCM_IPROC) += mdio-bcm-iproc.o
> > +obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
> > diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c
> > b/drivers/net/phy/xilinx_gmii2rgmii.c
> > new file mode 100644
> > index 000..56a655a9
> > --- /dev/null
> > +++ b/drivers/net/phy/xilinx_gmii2rgmii.c
> > @@ -0,0 +1,121 @@
> > +/* Xilinx GMII2RGMII Converter driver
> > + *
> > + * Copyright (C) 2016 Xilinx, Inc.
> > + *
> > + * Author: Kedareswara rao Appana
> > + *
> > + * Description:
> > + * This driver is developed for Xilinx GMII2RGMII Converter
> > + *
> > + * This program is free software: you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License as published
> > +by
> > + * the Free Software Foundation, either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define XILINX_GMII2RGMII_REG 0x10
> > +
> > +struct gmii2rgmii {
> > + struct phy_device *phy_dev;
> > + struct phy_driver *phy_drv;
> > + struct phy_driver conv_phy_drv;
> > + int addr;
> > +};
> > +
> > +static int xgmiitorgmii_read_status(struct phy_device *phydev) {
> > + struct gmii2rgmii *priv = (struct gmii2rgmii *)phydev->priv;
> > + u16 val = 0;
> > +
> > + priv->phy_drv->read_status(phydev);
> > +
> > + val = mdiobus_read(phydev->mdio.bus, priv->addr,
> > + XILINX_GMII2RGMII_REG);
> > +
> > + switch (phydev->speed) {
> > + case SPEED_1000:
> > + val |= BMCR_SPEED1000;
> > + case SPEED_100:
> > + val |= BMCR_SPEED100;
> > + }
> > +
> > + mdiobus_write(phydev->mdio.bus, priv->addr,
> > + XILINX_GMII2RGMII_REG, val);
> > +
> > + return 0;
> > +}
> > +
> > +int xgmiitorgmii_probe(struct mdio_device *mdiodev) {
> > + struct device *dev = &mdiodev->dev;
> > + struct device_node *np = dev->of_node, *phy_node;
> > + struct gm
Re: [RFC PATCH v3 2/2] net: phy: Add gmiitorgmii converter support
+ switch (phydev->speed) {
+ case SPEED_1000:
+ val |= BMCR_SPEED1000;
+ case SPEED_100:
+ val |= BMCR_SPEED100;
+ }
Are there only 2 kinds of speed?
On Thu, Aug 4, 2016 at 8:13 PM, Kedareswara rao Appana
wrote:
> This patch adds support for gmiitorgmii converter.
>
> The GMII to RGMII IP core provides the Reduced Gigabit Media
> Independent Interface (RGMII) between Ethernet physical media
> Devices and the Gigabit Ethernet controller. This core can
> Switch dynamically between the three different speed modes of
> Operation by configuring the converter register through mdio write.
>
> MDIO interface is used to set operating speed of Ethernet MAC.
>
> Signed-off-by: Kedareswara rao Appana
> ---
> Thanks a lot Andrew for your inputs.
> Changes for v3:
> --> Updated the driver as suggested by Andrew.
> Changes for v2:
> --> Passed struct xphy pointer directly to the fix_mac_speed
> API as suggested by the Florian.
> --> Added checks for the phy-node fail case as suggested
> by the Florian
>
> drivers/net/phy/Kconfig | 8 +++
> drivers/net/phy/Makefile| 1 +
> drivers/net/phy/xilinx_gmii2rgmii.c | 121
>
> 3 files changed, 130 insertions(+)
> create mode 100644 drivers/net/phy/xilinx_gmii2rgmii.c
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 6dad9a9..eec31a3 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -271,6 +271,14 @@ config MDIO_BCM_IPROC
> This module provides a driver for the MDIO busses found in the
> Broadcom iProc SoC's.
>
> +config XILINX_GMII2RGMII
> + tristate "Xilinx GMII2RGMII converter driver"
> + default y
> + ---help---
> + This driver support xilinx GMII to RGMII IP core it provides
> + the Reduced Gigabit Media Independent Interface(RGMII) between
> + Ethernet physical media devices and the Gigabit Ethernet controller.
> +
> endif # PHYLIB
>
> config MICREL_KS8995MA
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index fcdbb92..8650067 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -44,3 +44,4 @@ obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
> obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
> obj-$(CONFIG_MICROCHIP_PHY)+= microchip.o
> obj-$(CONFIG_MDIO_BCM_IPROC) += mdio-bcm-iproc.o
> +obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
> diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c
> b/drivers/net/phy/xilinx_gmii2rgmii.c
> new file mode 100644
> index 000..56a655a9
> --- /dev/null
> +++ b/drivers/net/phy/xilinx_gmii2rgmii.c
> @@ -0,0 +1,121 @@
> +/* Xilinx GMII2RGMII Converter driver
> + *
> + * Copyright (C) 2016 Xilinx, Inc.
> + *
> + * Author: Kedareswara rao Appana
> + *
> + * Description:
> + * This driver is developed for Xilinx GMII2RGMII Converter
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define XILINX_GMII2RGMII_REG 0x10
> +
> +struct gmii2rgmii {
> + struct phy_device *phy_dev;
> + struct phy_driver *phy_drv;
> + struct phy_driver conv_phy_drv;
> + int addr;
> +};
> +
> +static int xgmiitorgmii_read_status(struct phy_device *phydev)
> +{
> + struct gmii2rgmii *priv = (struct gmii2rgmii *)phydev->priv;
> + u16 val = 0;
> +
> + priv->phy_drv->read_status(phydev);
> +
> + val = mdiobus_read(phydev->mdio.bus, priv->addr,
> XILINX_GMII2RGMII_REG);
> +
> + switch (phydev->speed) {
> + case SPEED_1000:
> + val |= BMCR_SPEED1000;
> + case SPEED_100:
> + val |= BMCR_SPEED100;
> + }
> +
> + mdiobus_write(phydev->mdio.bus, priv->addr, XILINX_GMII2RGMII_REG,
> val);
> +
> + return 0;
> +}
> +
> +int xgmiitorgmii_probe(struct mdio_device *mdiodev)
> +{
> + struct device *dev = &mdiodev->dev;
> + struct device_node *np = dev->of_node, *phy_node;
> + struct gmii2rgmii *priv;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + phy_node = of_parse_phandle(np, "phy-handle", 0);
> + if (IS_ERR(phy_node)) {
> + dev_err(dev, "Couldn't parse phy-handle\n");
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + priv->phy_de
[PATCH] mfd: altera-a10sr: Make altr_a10sr_regmap_config static const
It's only used in this driver and never get modified, make it static const.
Signed-off-by: Axel Lin
---
drivers/mfd/altera-a10sr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
index c05aa4f..40ed65e 100644
--- a/drivers/mfd/altera-a10sr.c
+++ b/drivers/mfd/altera-a10sr.c
@@ -94,7 +94,7 @@ static bool altr_a10sr_reg_volatile(struct device *dev,
unsigned int reg)
}
}
-const struct regmap_config altr_a10sr_regmap_config = {
+static const struct regmap_config altr_a10sr_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
--
2.7.4
Re: [PATCH v2 2/2] hotplug: Prevent alloc/free of irq descriptors during cpu up/down (again)
On 03/08/16 19:22, Boris Ostrovsky wrote:
> Now that Xen no longer allocates irqs in _cpu_up() we can restore
> commit a89941816726 ("hotplug: Prevent alloc/free of irq descriptors
> during cpu up/down")
>
> Signed-off-by: Boris Ostrovsky
> Acked-by: Thomas Gleixner
Reviewed-by: Juergen Gross
Juergen
Re: [PATCH v2 1/2] xen/x86: Move irq allocation from Xen smp_op.cpu_up()
On 03/08/16 19:22, Boris Ostrovsky wrote:
> Commit ce0d3c0a6fb1 ("genirq: Revert sparse irq locking around
> __cpu_up() and move it to x86 for now") reverted irq locking
> introduced by commit a89941816726 ("hotplug: Prevent alloc/free
> of irq descriptors during cpu up/down") because of Xen allocating
> irqs in both of its cpu_up ops.
>
> We can move those allocations into CPU notifiers so that original
> patch can be reinstated.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Juergen
Re: [PATCH v6 09/10] drm/mediatek: add support for Mediatek SoC MT2701
Hi, YT:
On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
>
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6 ++
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c|6 ++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 17 +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |7 ++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 29 +
> drivers/gpu/drm/mediatek/mtk_dsi.c |1 +
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 31
> ++-
> 8 files changed, 97 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index eb5c05e..1da0a71 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -286,11 +286,17 @@ static int mtk_disp_ovl_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct mtk_ddp_comp_driver_data mt2701_ovl_driver_data = {
> + .ovl = {0x0040, 1 << 12, 0}
> +};
> +
> static const struct mtk_ddp_comp_driver_data mt8173_ovl_driver_data = {
> .ovl = {0x0f40, 0, 1 << 12}
> };
>
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-ovl",
> + .data = &mt2701_ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = &mt8173_ovl_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index fb0db50..506a353 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -225,11 +225,17 @@ static int mtk_disp_rdma_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct mtk_ddp_comp_driver_data mt2701_rdma_driver_data = {
> + .rdma_fifo_pseudo_size = SZ_4K,
> +};
> +
> static const struct mtk_ddp_comp_driver_data mt8173_rdma_driver_data = {
> .rdma_fifo_pseudo_size = SZ_8K,
> };
>
> static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-rdma",
> + .data = &mt2701_rdma_driver_data},
> { .compatible = "mediatek,mt8173-disp-rdma",
> .data = &mt8173_rdma_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index a9b209c..8130f3d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -60,6 +60,13 @@
> #define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
> #define MT8173_MUTEX_MOD_DISP_OD BIT(25)
>
> +#define MT2701_MUTEX_MOD_DISP_OVLBIT(3)
> +#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
> +#define MT2701_MUTEX_MOD_DISP_COLOR BIT(7)
> +#define MT2701_MUTEX_MOD_DISP_BLSBIT(9)
> +#define MT2701_MUTEX_MOD_DISP_RDMA0 BIT(10)
> +#define MT2701_MUTEX_MOD_DISP_RDMA1 BIT(12)
> +
> #define MUTEX_SOF_SINGLE_MODE0
> #define MUTEX_SOF_DSI0 1
> #define MUTEX_SOF_DSI1 2
> @@ -92,6 +99,15 @@ struct mtk_ddp {
> const unsigned int *mutex_mod;
> };
>
> +static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
> + [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
> + [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
> + [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> +};
> +
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -390,6 +406,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
> }
>
> static const struct of_device_id ddp_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> {},
> };
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 4b4e449..465819b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -112,6 +112,7 @@ struct mtk_ddp_comp_match {
>
> static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX]
> = {
> [DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, NULL },
> + [DDP_COMPONENT_BLS] = { MTK_DISP_PWM, 0, NULL },
> [DDP_COMPONENT_COLOR0] = { MTK_DISP_
[PATCH] sched/fair: refine maximum periods for decay_load
In current code, decay_load() will consider to set load value to zero after passing 32*64 ms. So this means max_load * (0.5^64) ~= 0. Kernel can support maximum number of processes and threads to 2^29 and set task with highest priority with nice=-20 (weight = 88761). So in worst case, one CPU may have maximum load value is: max_load = 2^29 * 88761 < 2^46 In theory after pass 46 periods we can ensure load value will be decayed to zero. So this patch is to change maximum periods from 64 to 48. Signed-off-by: Leo Yan --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e342159..55cb134 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2622,7 +2622,7 @@ static __always_inline u64 decay_load(u64 val, u64 n) if (!n) return val; - else if (unlikely(n > LOAD_AVG_PERIOD * 63)) + else if (unlikely(n > LOAD_AVG_PERIOD * 47)) return 0; /* after bounds checking we can collapse to 32-bit */ -- 1.9.1
Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback
Lars-Peter Clausen writes:
> On 08/04/2016 06:08 PM, Sinan Kaya wrote:
> [...]
>> The other way is I can feed this information to what Dave just introduced
>> as part of the callback mechanism and not touch this.
>
> Use the callback mechanism. It is a lot easier to implement correctly than
> the tx_status() mechanism.
>
>> The main discussion here is that
>>
>> "tx_status does not indicate whether the final transaction is successful or
>> not" whether the driver has the capability to determine error or not.
>
> tx_status() is supposed to be able to indicate whether a transfer failed or
> not. But in my opinion this feature is broken by design and implementing it
> correctly is very difficult without creating memory leaks. Which is probably
> why so few drivers actually implement it.
I think you can implement the error reporting by remembering the "last" cookie
where an error occurred such as in :
- e093bf60ca49 ("dmaengine: pxa: handle bus errors")
=> see the part of the commit beginning with "As dma_cookie_status() ..."
The point about error reporting was already discussed with Vinod in here:
https://lkml.org/lkml/2016/4/13/471
=> Vinod and I were seeing the reporting can be improved
Yet the description made by Russell of the DMA API semantics can be implemented
and used to find whether a specific tx failed or not, it's rather the "in
progress" part I find misleading.
Cheers.
--
Robert
Re: [PATCH v2 1/2] Limit dump_pipe program's permission to init for container
On Tue, Aug 2, 2016 at 2:08 AM, Zhao Lei wrote:
> Currently when we set core_pattern to a pipe, the pipe program is
> forked by kthread running with root's permission, and write dumpfile
> into host's filesystem.
> Same thing happened for container, the dumper and dumpfile are also
> in host(not in container).
>
> It have following program:
> 1: Not consistent with file_type core_pattern
>When we set core_pattern to a file, the container will write dump
>into container's filesystem instead of host.
> 2: Not safe for privileged container
>In a privileged container, user can destroy host system by following
>command:
># # In a container
># echo "|/bin/dd of=/boot/vmlinuz" >/proc/sys/kernel/core_pattern
># make_dump
>
> This patch switch dumper program's environment to init task, so, for
> container, dumper program have same environment with init task in
> container, which make dumper program put in container's filesystem, and
> write coredump into container's filesystem.
> The dumper's permission is also limited into subset of container's init
> process.
Does it change the current behavior? A pid namespace may be used for
sandboxes. For example, chrome uses it. In this case, we probably want
to collect core dumps from a root pid namespace.
If we are going to virtualize core_pattern relative to the pid
namespace, maybe it's better to make it optional for a pid namespace.
I mean it core_pattern is not set for the current pid namespace, we
can check a parent pid namespace and so on. A helper will be executed
in a pid namespace, where core_pattern is set.
After reading these patches, I think it may be a good idea to add one
more mode to handle core files, when a core file is sent to an
existing process instead of executing a usermode helpers. This mode
will cover of use-cases where the pipe mode is used now. And it looks
more secure, because in this case we control namespaces and credential
for the abort daemon (a process which handles core files).u
How it can be done. An abort daemon creates an abstract listening unix
socket and writes its name into /proc/sys/kernel/core_pattern. The
kernel saves this name and the network namespace. Then when any
process is crashed, the kernel creates a new unix socket and connect
it to the socket of the abort daemon and streams a core file into this
socket.
>
> Suggested-by: Eric W. Biederman
> Suggested-by: KOSAKI Motohiro
>
> Signed-off-by: Zhao Lei
> ---
> fs/coredump.c | 87
> -
> include/linux/binfmts.h | 1 +
> 2 files changed, 87 insertions(+), 1 deletion(-)
>
> diff --git a/fs/coredump.c b/fs/coredump.c
> index 281b768..8511267 100644
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -516,6 +516,8 @@ static int umh_pipe_setup(struct subprocess_info *info,
> struct cred *new)
> {
> struct file *files[2];
> struct coredump_params *cp = (struct coredump_params *)info->data;
> + struct task_struct *base_task;
> +
> int err = create_pipe_files(files, 0);
> if (err)
> return err;
> @@ -524,10 +526,79 @@ static int umh_pipe_setup(struct subprocess_info *info,
> struct cred *new)
>
> err = replace_fd(0, files[0], 0);
> fput(files[0]);
> + if (err)
> + return err;
> +
> /* and disallow core files too */
> current->signal->rlim[RLIMIT_CORE] = (struct rlimit){1, 1};
>
> - return err;
> + base_task = cp->base_task;
> + if (base_task) {
> + const struct cred *base_cred;
> +
> + /* Set fs_root to base_task */
> + spin_lock(&base_task->fs->lock);
> + set_fs_root(current->fs, &base_task->fs->root);
> + spin_unlock(&base_task->fs->lock);
> +
> + /* Set namespaces to base_task */
> + get_nsproxy(base_task->nsproxy);
> + switch_task_namespaces(current, base_task->nsproxy);
This task will continue running in the current pid namespace, because
switch_task_namespaces doesn't change a pid for the task. Ussualy, we
need to make setns+fork to switch a pid namespace.
> +
> + /* Set cgroup to base_task */
> + current->flags &= ~PF_NO_SETAFFINITY;
> + err = cgroup_attach_task_all(base_task, current);
> + if (err < 0)
> + return err;
> +
> + /* Set cred to base_task */
> + base_cred = get_task_cred(base_task);
> +
I think you can use prepare_kernel_cred here
> + new->uid = base_cred->uid;
> + new->gid = base_cred->gid;
> + new->suid = base_cred->suid;
> + new->sgid = base_cred->sgid;
> + new->euid = base_cred->euid;
> + new->egid = base_cred->egid;
> + new->fsuid = base_cred->fsuid;
> + new->fsgid = base_cred->fsgid;
> +
> + new
[PATCH] sched/core: fix one typo
Fix one minor typo in the comment: s/targer/target/. Signed-off-by: Leo Yan --- kernel/sched/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 5c883fe..4cb3547 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1264,7 +1264,7 @@ static void __migrate_swap_task(struct task_struct *p, int cpu) /* * Task isn't running anymore; make it appear like we migrated * it before it went to sleep. This means on wakeup we make the -* previous cpu our targer instead of where it really is. +* previous cpu our target instead of where it really is. */ p->wake_cpu = cpu; } -- 1.9.1
[PATCH] sched/fair: polish function update_next_balance()
Function update_next_balance() is only used by idle balance, so its
parameter 'cpu_busy' is redundant and always be passed with 0.
This patch is to polish update_next_balance() to remove parameter
'cpu_busy'.
Signed-off-by: Leo Yan
---
kernel/sched/fair.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4088eed..e342159 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7704,11 +7704,12 @@ get_sd_balance_interval(struct sched_domain *sd, int
cpu_busy)
}
static inline void
-update_next_balance(struct sched_domain *sd, int cpu_busy, unsigned long
*next_balance)
+update_next_balance(struct sched_domain *sd, unsigned long *next_balance)
{
unsigned long interval, next;
- interval = get_sd_balance_interval(sd, cpu_busy);
+ /* used by idle balance, so cpu_busy = 0 */
+ interval = get_sd_balance_interval(sd, 0);
next = sd->last_balance + interval;
if (time_after(*next_balance, next))
@@ -7738,7 +7739,7 @@ static int idle_balance(struct rq *this_rq)
rcu_read_lock();
sd = rcu_dereference_check_sched_domain(this_rq->sd);
if (sd)
- update_next_balance(sd, 0, &next_balance);
+ update_next_balance(sd, &next_balance);
rcu_read_unlock();
goto out;
@@ -7756,7 +7757,7 @@ static int idle_balance(struct rq *this_rq)
continue;
if (this_rq->avg_idle < curr_cost + sd->max_newidle_lb_cost) {
- update_next_balance(sd, 0, &next_balance);
+ update_next_balance(sd, &next_balance);
break;
}
@@ -7774,7 +7775,7 @@ static int idle_balance(struct rq *this_rq)
curr_cost += domain_cost;
}
- update_next_balance(sd, 0, &next_balance);
+ update_next_balance(sd, &next_balance);
/*
* Stop searching for tasks to pull if there are
--
1.9.1
Re: [PATCH v6 10/10] arm: dts: mt2701: Add display subsystem related nodes for MT2701
Hi, YT:
On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> This patch adds the device nodes for the DISP function blocks for MT2701
>
> Signed-off-by: YT Shen
> ---
> arch/arm/boot/dts/mt2701.dtsi | 86
> +
> 1 file changed, 86 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index f3136bd..8f35a0d 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -24,6 +24,11 @@
> compatible = "mediatek,mt2701";
> interrupt-parent = <&sysirq>;
>
> + aliases {
> + rdma0 = &rdma0;
> + rdma1 = &rdma1;
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -171,6 +176,16 @@
> power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
> };
>
> + mipi_tx0: mipi-dphy@1001 {
> + compatible = "mediatek,mt2701-mipi-tx";
> + reg = <0 0x1001 0 0x90>;
> + clocks = <&clk26m>;
> + clock-output-names = "mipi_tx0_pll";
> + #clock-cells = <0>;
> + #phy-cells = <0>;
> + status = "disabled";
> + };
> +
> sysirq: interrupt-controller@10200100 {
> compatible = "mediatek,mt2701-sysirq",
>"mediatek,mt6577-sysirq";
> @@ -255,6 +270,68 @@
> status = "disabled";
> };
>
> + ovl@14007000 {
> + compatible = "mediatek,mt2701-disp-ovl";
> + reg = <0 0x14007000 0 0x1000>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_DISP_OVL>;
> + iommus = <&iommu MT2701_M4U_PORT_DISP_OVL_0>;
> + mediatek,larb = <&larb0>;
> + };
> +
> + rdma0: rdma@14008000 {
> + compatible = "mediatek,mt2701-disp-rdma";
> + reg = <0 0x14008000 0 0x1000>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_DISP_RDMA>;
> + iommus = <&iommu MT2701_M4U_PORT_DISP_RDMA>;
> + mediatek,larb = <&larb0>;
> + };
> +
> + wdma@14009000 {
> + compatible = "mediatek,mt2701-disp-wdma";
> + reg = <0 0x14009000 0 0x1000>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_DISP_WDMA>;
> + iommus = <&iommu MT2701_M4U_PORT_DISP_WDMA>;
> + mediatek,larb = <&larb0>;
> + };
> +
> + bls@1400a000 {
> + compatible = "mediatek,mt2701-disp-pwm";
> + reg = <0 0x1400a000 0 0x1000>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_DISP_BLS>;
> + };
You depends on [1], but that series include [2] which also add a
disp_bls node which has the same compatible string
"mediatek,mt2701-disp-pwm". If these two node are the same, just add it
in one patch. If they are different, do not use the same compatible
string.
[1] https://patchwork.kernel.org/patch/9222997/ ("dt-bindings: pwm: Add
MediaTek display PWM bindings")
[2] https://patchwork.kernel.org/patch/9223005/
> +
> + color@1400b000 {
> + compatible = "mediatek,mt2701-disp-color";
> + reg = <0 0x1400b000 0 0x1000>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_DISP_COLOR>;
> + };
> +
> + dsi0: dsi@1400c000 {
> + compatible = "mediatek,mt2701-dsi";
> + reg = <0 0x1400c000 0 0x1000>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_DSI_ENGINE>, <&mmsys CLK_MM_DSI_DIG>,
> + <&mipi_tx0>;
> + clock-names = "engine", "digital", "hs";
> + mediatek,syscon-dsi = <&mmsys 0x138>;
> + mediatek,ssc-range = <5>;
> + phys = <&mipi_tx0>;
> + phy-names = "dphy";
> + status = "disabled";
> + };
> +
> + mutex: mutex@1400e000 {
> + compatible = "mediatek,mt2701-disp-mutex";
> + reg = <0 0x1400e000 0 0x1000>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_MUTEX_32K>;
> + };
> +
> larb0: larb@1401 {
> compatible = "mediatek,mt2701-smi-larb";
> reg = <0 0x1401 0 0x1000>;
> @@ -266,6 +343,15 @@
> power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
> };
>
> + rdma1: rdma@14012000 {
> + compatible = "mediatek,mt2701-disp-rdma";
> + reg = <0 0x14012000 0 0x1000>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_DISP_RDMA1>;
> + iommus = <&iommu MT2701_M4U_PORT_DISP_RDMA1>;
> + mediatek,larb = <&larb0>;
> + };
> +
> imgsys: syscon@1500 {
> compatible = "mediatek,mt2701-imgsys", "syscon";
> reg = <0 0x1500 0 0x1000>;
Regards,
CK
RE: [PATCH v1] net: phy: micrel: Add specific suspend
Hi Florian,
> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: 2016年8月4日 11:33
> To: Wenyou Yang
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Alexandre Belloni electrons.com>; Nicolas Ferre ; Andrew Lunn
>
> Subject: Re: [PATCH v1] net: phy: micrel: Add specific suspend
>
> On 03/08/2016 17:21, Wenyou Yang wrote:
> > Disable all interrupts when suspend, they will be enabled when resume.
> > Otherwise, the suspend/resume process will be blocked occasionally.
>
> This seems like something fairly generic actually, we could imagine having the
> core library do something like this:
>
> - if interrupts are valid and enabled for the PHY, call
> phydrv->config_intr() with PHY_INTERRUPT_DISABLED
> - call genphy_suspend
Accepted. I will send a new version.
>
> Of course if none of this fits the generic model, the PHY driver can still
> provide a
> suspend callback. Might be worth auditing other drivers for that pattern and
> look at
> those that need specific handling like keeping specific interrupt sources
> active for
> e.g: wake-on-LAN.
>
> >
> > Signed-off-by: Wenyou Yang
> > Acked-by: Nicolas Ferre
> > ---
> >
> > drivers/net/phy/micrel.c | 19 ++-
> > 1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c index
> > 5a8fefc..8cb778a 100644
> > --- a/drivers/net/phy/micrel.c
> > +++ b/drivers/net/phy/micrel.c
> > @@ -647,6 +647,23 @@ static void kszphy_get_stats(struct phy_device
> *phydev,
> > data[i] = kszphy_get_stat(phydev, i); }
> >
> > +int kszphy_suspend(struct phy_device *phydev) {
> > + int value;
> > +
> > + mutex_lock(&phydev->lock);
> > +
> > + /* disable interrupts */
> > + phy_write(phydev, MII_KSZPHY_INTCS, 0x0);
> > +
> > + value = phy_read(phydev, MII_BMCR);
> > + phy_write(phydev, MII_BMCR, value | BMCR_PDOWN);
> > +
> > + mutex_unlock(&phydev->lock);
> > +
> > + return 0;
> > +}
> > +
> > static int kszphy_resume(struct phy_device *phydev) {
> > int value;
> > @@ -870,7 +887,7 @@ static struct phy_driver ksphy_driver[] = {
> > .get_sset_count = kszphy_get_sset_count,
> > .get_strings= kszphy_get_strings,
> > .get_stats = kszphy_get_stats,
> > - .suspend= genphy_suspend,
> > + .suspend= kszphy_suspend,
> > .resume = kszphy_resume,
> > }, {
> > .phy_id = PHY_ID_KSZ8061,
> >
Best Regards,
Wenyou Yang
[PATCH 2/2] powerpc/pseries: Dynamically increase RMA size
>From ddce2a5f439111f08969d66ccc0c7b4d9196b69d Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Thu, 4 Aug 2016 23:13:37 -0400
Subject: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size
When booting a very large system with a large initrd we run out of space
for the flattened device tree (FDT). To fix this we must increase the
space allocated for the RMA region.
The RMA size is hard-coded in the 'ibm_architecture_vec[]' and increasing
the size there will apply to all systems, large and small, so we want to
increase the RMA region only when necessary.
When we run out of room for the FDT, set a new OF property, 'ibm,new-rma-size'
to the new RMA size (512MB) and issue a client-architecture-support (CAS)
call to the firmware. This will initiate a system reboot. Upon reboot we
notice the new property and update the RMA size accordingly.
The CAS call we issue would end up being a second CAS call in the boot
sequence. Use a static variable, 'fixup_nr_cores_done', to detect this
second CAS and avoid fixing up nr_cores or hitting the WARNING again.
Fix suggested by Michael Ellerman.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/kernel/prom_init.c | 86 -
1 file changed, 85 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index f612a99..407cbb9 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -679,6 +679,7 @@ unsigned char ibm_architecture_vec[] = {
W(0x), /* virt_base */
W(0x), /* virt_size */
W(0x), /* load_base */
+#define IBM_ARCH_VEC_MIN_RMA_OFFSET108
W(256), /* 256MB min RMA */
W(0x), /* full client load */
0, /* min RMA percentage of total RAM */
@@ -867,6 +868,10 @@ static void fixup_nr_cores(void)
{
u32 cores;
unsigned char *ptcores;
+ static bool fixup_nr_cores_done = false;
+
+ if (fixup_nr_cores_done)
+ return;
/* We need to tell the FW about the number of cores we support.
*
@@ -898,6 +903,41 @@ static void fixup_nr_cores(void)
ptcores[1] = (cores >> 16) & 0xff;
ptcores[2] = (cores >> 8) & 0xff;
ptcores[3] = cores & 0xff;
+ fixup_nr_cores_done = true;
+ }
+}
+
+static void __init fixup_rma_size(void)
+{
+ int rc;
+ u64 size;
+ unsigned char *min_rmap;
+ phandle optnode;
+ char str[64];
+
+ optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
+ if (!PHANDLE_VALID(optnode))
+ prom_panic("Cannot find /options");
+
+ /*
+* If a prior boot specified a new RMA size, use that size in
+* ibm_architecture_vec[]. See also increase_rma_size().
+*/
+ size = 0ULL;
+ memset(str, 0, sizeof(str));
+ rc = prom_getprop(optnode, "ibm,new-rma-size", &str, sizeof(str));
+ if (rc <= 0)
+ return;
+
+ size = prom_strtoul(str, NULL);
+ min_rmap = &ibm_architecture_vec[IBM_ARCH_VEC_MIN_RMA_OFFSET];
+
+ if (size) {
+ prom_printf("Using RMA size %lu from ibm,new-rma-size.\n",
size);
+ min_rmap[0] = (size >> 24) & 0xff;
+ min_rmap[1] = (size >> 16) & 0xff;
+ min_rmap[2] = (size >> 8) & 0xff;
+ min_rmap[3] = size & 0xff;
}
}
@@ -911,6 +951,8 @@ static void __init prom_send_capabilities(void)
fixup_nr_cores();
+ fixup_rma_size();
+
/* try calling the ibm,client-architecture-support method */
prom_printf("Calling ibm,client-architecture-support...");
if (call_prom_ret("call-method", 3, 2, &ret,
@@ -946,6 +988,46 @@ static void __init prom_send_capabilities(void)
}
#endif /* __BIG_ENDIAN__ */
}
+
+static void __init increase_rma_size(void)
+{
+ int rc;
+ u64 size;
+ char str[64];
+ phandle optnode;
+
+ optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
+ if (!PHANDLE_VALID(optnode))
+ prom_panic("Cannot find /options");
+
+ /*
+* If we already increased the RMA size, return.
+*/
+ size = 0ULL;
+ memset(str, 0, sizeof(str));
+ rc = prom_getprop(optnode, "ibm,new-rma-size", &str, sizeof(str));
+
+ size = prom_strtoul(str, NULL);
+ if (size == 512ULL) {
+ prom_printf("RMA size already at %lu.\n", size);
+ return;
+ }
+ /*
+* Otherwise, set the ibm,new-rma-size property and initiate a CAS
+* reboot so the RMA size can take effect. See also init_rma_size().
+*/
+ memset(str, 0, 4);
+ memcpy(str, "512", 3);
+ prom_printf("Setting ibm,new-rma-
[PATCH 1/2] powerpc/pseries: Use a helper to fixup nr_cores
>From d49b597623ac58fa1ab61ce0157470b6390e9a67 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Fri, 5 Aug 2016 00:01:54 -0400
Subject: [PATCH 1/2] powerpc/pseries: Use a helper to fixup nr_cores.
We have to fixup RMA size also, so using helpers will make it cleaner
and consistent.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/kernel/prom_init.c | 70 ++---
1 file changed, 38 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 6ee4b72..f612a99 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -863,47 +863,53 @@ static int __init prom_count_smt_threads(void)
}
+static void fixup_nr_cores(void)
+{
+ u32 cores;
+ unsigned char *ptcores;
+
+ /* We need to tell the FW about the number of cores we support.
+*
+* To do that, we count the number of threads on the first core
+* (we assume this is the same for all cores) and use it to
+* divide NR_CPUS.
+*/
+
+ /* The core value may start at an odd address. If such a word
+* access is made at a cache line boundary, this leads to an
+* exception which may not be handled at this time.
+* Forcing a per byte access to avoid exception.
+*/
+ ptcores = &ibm_architecture_vec[IBM_ARCH_VEC_NRCORES_OFFSET];
+ cores = 0;
+ cores |= ptcores[0] << 24;
+ cores |= ptcores[1] << 16;
+ cores |= ptcores[2] << 8;
+ cores |= ptcores[3];
+ if (cores != NR_CPUS) {
+ prom_printf("WARNING ! "
+ "ibm_architecture_vec structure inconsistent:
%lu!\n",
+ cores);
+ } else {
+ cores = DIV_ROUND_UP(NR_CPUS, prom_count_smt_threads());
+ prom_printf("Max number of cores passed to firmware: %lu
(NR_CPUS = %lu)\n",
+ cores, NR_CPUS);
+ ptcores[0] = (cores >> 24) & 0xff;
+ ptcores[1] = (cores >> 16) & 0xff;
+ ptcores[2] = (cores >> 8) & 0xff;
+ ptcores[3] = cores & 0xff;
+ }
+}
static void __init prom_send_capabilities(void)
{
ihandle root;
prom_arg_t ret;
- u32 cores;
- unsigned char *ptcores;
root = call_prom("open", 1, 1, ADDR("/"));
if (root != 0) {
- /* We need to tell the FW about the number of cores we support.
-*
-* To do that, we count the number of threads on the first core
-* (we assume this is the same for all cores) and use it to
-* divide NR_CPUS.
-*/
- /* The core value may start at an odd address. If such a word
-* access is made at a cache line boundary, this leads to an
-* exception which may not be handled at this time.
-* Forcing a per byte access to avoid exception.
-*/
- ptcores = &ibm_architecture_vec[IBM_ARCH_VEC_NRCORES_OFFSET];
- cores = 0;
- cores |= ptcores[0] << 24;
- cores |= ptcores[1] << 16;
- cores |= ptcores[2] << 8;
- cores |= ptcores[3];
- if (cores != NR_CPUS) {
- prom_printf("WARNING ! "
- "ibm_architecture_vec structure
inconsistent: %lu!\n",
- cores);
- } else {
- cores = DIV_ROUND_UP(NR_CPUS, prom_count_smt_threads());
- prom_printf("Max number of cores passed to firmware:
%lu (NR_CPUS = %lu)\n",
- cores, NR_CPUS);
- ptcores[0] = (cores >> 24) & 0xff;
- ptcores[1] = (cores >> 16) & 0xff;
- ptcores[2] = (cores >> 8) & 0xff;
- ptcores[3] = cores & 0xff;
- }
+ fixup_nr_cores();
/* try calling the ibm,client-architecture-support method */
prom_printf("Calling ibm,client-architecture-support...");
--
1.8.3.1
Re: [PATCH 1/2] mac80211/wlcore: Add ieee80211_hw variable to get_expected_throughput
On Thu, Aug 4, 2016 at 10:40 PM, Johannes Berg wrote: > On Thu, 2016-08-04 at 14:31 -0700, John Stultz wrote: >> On Thu, Aug 4, 2016 at 5:43 AM, Maxim Altshul >> wrote: >> > - The variable is added to allow the driver an easy access >> > to it's own hw->priv when the op is invoked. >> > >> > - Change wlcore op accordingly. >> > >> > Signed-off-by: Maxim Altshul >> >> These two patches solve the regression I was seeing with pre-v4.8-rc1 >> kernels on HiKey. >> > > Interesting, what was the regression? Was the station pointer there not > valid? Yea, a null pointer deference: https://lkml.org/lkml/2016/7/27/712 thanks -john
[PATCH] perf probe: support signedness casting
Perf-probe detects a variable's type and use the detected type to add new
probe. Then, kprobes prints its variable in hexadecimal format if the
variable is unsigned and prints in decimal if it is signed.
We sometimes want to see unsigned variable in decimal format (e.g.
sector_t or size_t). In that case, we need to investigate variable's
size manually to specify just signedness.
This patch add signedness casting support. By specifying "s" or "u" as a
type, perf-probe will investigate variable size as usual and use
the specified signedness.
Signed-off-by: Naohiro Aota
---
tools/perf/util/probe-finder.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index f2d9ff0..5c290c6 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -297,10 +297,13 @@ static int convert_variable_type(Dwarf_Die *vr_die,
char sbuf[STRERR_BUFSIZE];
int bsize, boffs, total;
int ret;
+ char sign;
/* TODO: check all types */
- if (cast && strcmp(cast, "string") != 0) {
+ if (cast && strcmp(cast, "string") != 0 &&
+ strcmp(cast, "s") != 0 && strcmp(cast, "u") != 0) {
/* Non string type is OK */
+ /* and respect signedness cast */
tvar->type = strdup(cast);
return (tvar->type == NULL) ? -ENOMEM : 0;
}
@@ -361,6 +364,13 @@ static int convert_variable_type(Dwarf_Die *vr_die,
return (tvar->type == NULL) ? -ENOMEM : 0;
}
+ if (cast && (strcmp(cast, "u") == 0))
+ sign = 'u';
+ else if (cast && (strcmp(cast, "s") == 0))
+ sign = 's';
+ else
+ sign = die_is_signed_type(&type) ? 's' : 'u';
+
ret = dwarf_bytesize(&type);
if (ret <= 0)
/* No size ... try to use default type */
@@ -373,8 +383,7 @@ static int convert_variable_type(Dwarf_Die *vr_die,
dwarf_diename(&type), MAX_BASIC_TYPE_BITS);
ret = MAX_BASIC_TYPE_BITS;
}
- ret = snprintf(buf, 16, "%c%d",
- die_is_signed_type(&type) ? 's' : 'u', ret);
+ ret = snprintf(buf, 16, "%c%d", sign, ret);
formatted:
if (ret < 0 || ret >= 16) {
--
2.7.3
Western Digital Corporation (and its subsidiaries) E-mail Confidentiality
Notice & Disclaimer:
This e-mail and any files transmitted with it may contain confidential or
legally privileged information of WDC and/or its affiliates, and are intended
solely for the use of the individual or entity to which they are addressed. If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited. If
you have received this e-mail in error, please notify the sender immediately
and delete the e-mail in its entirety from your system.
Re: [PATCH 1/2] mac80211/wlcore: Add ieee80211_hw variable to get_expected_throughput
On Thu, 2016-08-04 at 14:31 -0700, John Stultz wrote: > On Thu, Aug 4, 2016 at 5:43 AM, Maxim Altshul > wrote: > > - The variable is added to allow the driver an easy access > > to it's own hw->priv when the op is invoked. > > > > - Change wlcore op accordingly. > > > > Signed-off-by: Maxim Altshul > > These two patches solve the regression I was seeing with pre-v4.8-rc1 > kernels on HiKey. > Interesting, what was the regression? Was the station pointer there not valid? johannes
Re: [PATCH] sched: fix the intention to re-evalute tick dependency for offline cpu
Cc Frederic,
2016-08-04 17:51 GMT+08:00 Wanpeng Li :
> From: Wanpeng Li
>
> The dl task will be replenished after dl task timer fire and start a new
> period. It will be enqueued and to re-evaluate its dependency on the tick
> in order to restart it. However, if cpu is hot-unplug, irq_work_queue will
> splash since the target cpu is offline.
>
> As a result:
>
> WARNING: CPU: 2 PID: 0 at kernel/irq_work.c:69 irq_work_queue_on+0xad/0xe0
> Call Trace:
> dump_stack+0x99/0xd0
> __warn+0xd1/0xf0
> warn_slowpath_null+0x1d/0x20
> irq_work_queue_on+0xad/0xe0
> tick_nohz_full_kick_cpu+0x44/0x50
> tick_nohz_dep_set_cpu+0x74/0xb0
> enqueue_task_dl+0x226/0x480
> activate_task+0x5c/0xa0
> dl_task_timer+0x19b/0x2c0
> ? push_dl_task.part.31+0x190/0x190
>
> This can be triggered by hot-unplug the full dynticks cpu which dl task
> is running on.
>
> Actually we don't need to restart the tick since the target cpu is offline
> and nothing need scheduler tick. This patch fix it by not intend to
> re-evaluate
> tick dependency if the cpu is offline.
>
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Juri Lelli
> Cc: Luca Abeni
> Signed-off-by: Wanpeng Li
> ---
> kernel/sched/core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 7f2cae4..43b494f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -628,6 +628,9 @@ bool sched_can_stop_tick(struct rq *rq)
> {
> int fifo_nr_running;
>
> + if (unlikely(!rq->online))
> + return true;
> +
> /* Deadline tasks, even if single, need the tick */
> if (rq->dl.dl_nr_running)
> return false;
> --
> 1.9.1
>
--
Regards,
Wanpeng Li
RE: [PATCH] Add file permission mode helpers ( [PATCH xxxx/1285] Replace numeric parameter like 0444 with macro)
Resend the below mail just to You, make sure all list members can receive it. Thanks! Baole -Original Message- From: Ni, BaoleX Sent: Thursday, August 04, 2016 5:41 PM To: 'Steven Rostedt'; 'Sergei Shtylyov'; 'Ville Syrjälä'; 'Hans-Christian Noren Egtvedt'; 'Lino Sanfilippo'; 'Borislav Petkov'; 'Jiri Benc'; 'Leon Romanovsky'; 'Jani Nikula'; 'Juergen Gross'; 'Edward Cree'; 'Jes Sorensen'; 'Mauro Carvalho Chehab'; 'Felipe Balbi'; Pavel Machek; 'Ingo Tuchscherer'; 'Corey Minyard'; 'Ricardo Ribalda Delgado'; Weiny, Ira; 'David Laight'; 'Joe Perches'; 'Krzysztof Kozlowski'; 'Mike Nazarewicz'; 'Lee Jones'; 'Michal Kubecek'; 'Rusty Russell'; Koul, Vinod; 'Theodore Ts'o'; 'rjwyso...@gmail.com'; 'Steve Cotton'; 'Olof Johansson'; 'Arend van Spriel'; 'Tejun Heo'; 'Dave Kleikamp'; 'Jan Engelhardt'; 'Kalle Valo'; 'Dmitry Torokhov'; 'Henrique de Moraes Holschuh'; 'Dmitry Torokhov'; 'Jiri Slaby'; 'Ismael Luceno'; 'Geoff Levand'; 'RSD @ SFI'; 'Peter Meerwald-Stadler'; 'keesc...@google.com'; 'Shanker Wang'; 'Heiko Carstens'; 'Deucher, Alexander'; 'Bart Van Assche'; 'Randy Dunlap'; 'Sagi Grimberg'; 'Andrew F. Davis'; 'Larry Finger'; 'Eric W. Biederman'; 'James Bottomley'; 'Mark Brown'; 'Steve Wise'; 'Austin S. Hemmelgarn'; 'Cornelia Huck'; 'Christian Borntraeger'; 'Marcel Holtmann'; 'Alan Stern'; 'Jean Delvare'; 'Allen Hubbe'; 'Ralf Baechle'; 'Sven Eckelmann'; 'matwey.korni...@gmail.com'; 'Takashi Sakamoto'; 'Sagi Grimberg'; 'Takashi Sakamoto'; 'Peter Ujfalusi'; 'Radim Krcmár'; 'Guenter Roeck'; 'matwey.korni...@gmail.com'; 'One Thousand Gnomes'; 'Roger Pau Monné'; 'Conor O'Gorman'; 'Laurence Oberman'; 'Wei Liu'; 'Ricardo Ribalda Delgado' Cc: 'Ingo Molnar'; Linus Torvalds; 'Al Viro'; Greg Kroah-Hartman; Heiko Carstens; Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org; Linux Kernel Mailing List; Liu, Chuansheng; 'Marcel Holtmann'; 'Willy Tarreau'; 'Oliver Neukum'; 'Richard Weinberger'; 'Konstantin Khlebnikov'; 'Rob Landley'; 'Bart Van Assche'; 'Jarod Wilson'; 'Segher Boessenkool'; 'David Miller'; 'Doug Ledford'; 'Steve Wise'; 'Masami Hiramatsu'; 'Rich Felker'; 'Lukas Wunner'; 'Daniel Vetter'; 'Jiri Kosina'; Nikolova, Tatyana E; Luick, Dean; Hefty, Sean; 'Thomas Hellstrom'; Koul, Vinod; 'inki@samsung.com'; Kirsher, Jeffrey T; Hunter, Adrian; 'Liu [EP], Bin' Subject: RE: [PATCH] Add file permission mode helpers ( [PATCH /1285] Replace numeric parameter like 0444 with macro) Dear All, Thanks a lot for your kind response and great advice. 1. I made this a series of patches by coccinelle. 2. As a new comer, I indeed made some mistakes on producing and submitting patches. As some of you kindly pointed out, I didn't give specific subjects for each patch, and I also shouldn't send out 1285 patches in one thread, in addition, some of the macros I chose weren't the most compact ones, etc. 3. After I sent out my patches, Ingo Molnar introduced another set of symbolic helpers which is easier to read for the octal permission numbers. He quickly gave a patch for his nice idea, you can see it in this mail. 4.So I need to resolve my problems firstly with a sane thought, then maybe I will try again. I'm awfully sorry to bother you. Thank you again! Baole -Original Message- From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo Molnar Sent: Wednesday, August 03, 2016 4:12 PM To: Linus Torvalds Cc: Pavel Machek; Greg Kroah-Hartman; Heiko Carstens; Ni, BaoleX; Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org; Linux Kernel Mailing List; Liu, Chuansheng Subject: [PATCH] Add file permission mode helpers * Linus Torvalds wrote: > [ So I answered similarly to another patch, but I'll just re-iterate > and change the subject line so that it stands out a bit from the > millions of actual patches ] > > On Tue, Aug 2, 2016 at 1:42 PM, Pavel Machek wrote: > > > > Everyone knows what 0644 is, but noone can read S_IRUSR | S_IWUSR | > > S_IRCRP | S_IROTH (*). Please don't do this. > > Absolutely. It's *much* easier to parse and understand the octal > numbers, while the symbolic macro names are just random line noise and > hard as hell to understand. You really have to think about it. > > So we should rather go the other way: convert existing bad symbolic > permission bit macro use to just use the octal numbers. In addition to that I'd love to have something even easier to read, a few common variants of the permissions field of 'ls -l' pre-defined. I did some quick grepping, and collected the main variants that are in use: PERM_r 0400 PERM_r__r_ 0440 PERM_r__r__r__ 0444 PERM_rw___ 0600 PERM_rw_r_ 0640 PERM_rw_r__r__ 0644 PERM_rw_rw_r__ 0664 PERM_rw_rw_rw_ 0666 PERM__w___ 0200 PERM__w__w 0220 PERM__w__
Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling
On Thu, Aug 04, 2016 at 09:13:16PM -0700, Brendan Gregg wrote: > On Thu, Aug 4, 2016 at 6:43 PM, Alexei Starovoitov > wrote: > > On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote: > >> On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: > >> > >> > As for pmu tracepoints: if I were to instrument it (although I wasn't > >> > planning to), I'd put a tracepoint in perf_event_overflow() called > >> > "perf:perf_overflow", with the same arguments. That could then be used > >> > for all PMU overflow events, without needing to add specific > >> > tracepoints. > >> > >> Could we not teach BPF to replace event->overflow_handler and inject > >> itself there? > >> > >> We don't currently have nice interfaces for doing that, but it should be > >> possible to do I think. We already have the indirect function call, so > >> injecting ourself there has 0 overhead. > > Sounds like a good idea, especially for things like struct > file_operations so that we can statically instrument file system > read/writes with zero non-enabled overhead, and not worry about high > frequency workloads (>10M events/sec). > > These perf probes aren't high frequency, though, and the code is not > normally in use, so overhead should be much less of a concern. > Sampling at 999 Hertz * CPUs is as frequent as I'd go. And if the > tracepoint code is still adding a mem read, conditional, and branch, > then that's not many instructions, especially considering the normal > use case of these perf functions: creating records and writing to a > perf ring buffer, then picking that up in user space by perf, then > either processing it live or writing to perf.data, back to the file > system, etc. It would be hard to benchmark the effect of adding a few > instructions to that path (and any results may be more sensitive to > cache line placement than the instructions). tracepoints are actually zero overhead already via static-key mechanism. I don't think Peter's objection for the tracepoint was due to overhead. > The perf:perf_hrtimer probe point is also reading state mid-way > through a function, so it's not quite as simple as wrapping the > function pointer. I do like that idea, though, but for things like > struct file_operations. > > > > > you're right. All makes sense. I guess I was too lazy to look into > > how to do it properly. Adding a tracepoint looked like quick and > > easy way to achieve the same. > > As far as api goes probably existing IOC_SET_BPF ioctl will do too. > > Currently overflow_handler is set at event alloc time. If we start > > changing it on the fly with atomic xchg(), afaik things shouldn't > > break, since each overflow_handler is run to completion and doesn't > > change global state, right? > > > > How would it be implemented? I was thinking of adding explicit wrappers, eg: instead of adding a tracepoint to perf_swevent_hrtimer we can replace overflow_handler for that particular event with some form of bpf wrapper. (probably new bpf program type). Then not only periodic events will be triggering bpf prog, but pmu events as well. So instead of normal __perf_event_output() writing into ringbuffer, a bpf prog will be called that can optionally write into different rb via bpf_perf_event_output. The question is what to pass into the program to make the most use out of it. 'struct pt_regs' is done deal. but perf_sample_data we cannot pass as-is, since it's kernel internal. Probably something similar to __sk_buff mirror would be needed. Another nice benefit of doing via overflow_handler instead of tracepoint is that exclude_idle, exclude_user, exclude_kernel flags of the perf event will all magically work and program will be event specific. So two parallel 'perf record'-like sampling won't conflict.
[PATCH] net: macb: Correct CAPS mask
USRIO and JUMBO CAPS have the same mask.
Fix the same.
Fixes: ce721a702197 ("net: ethernet: cadence-macb: Add disabled usrio caps")
Cc: sta...@vger.kernel.org # v4.5+
Signed-off-by: Harini Katakam
Acked-by: Nicolas Ferre
---
drivers/net/ethernet/cadence/macb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 36893d8..b6fcf10 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -403,11 +403,11 @@
#define MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII0x0004
#define MACB_CAPS_NO_GIGABIT_HALF 0x0008
#define MACB_CAPS_USRIO_DISABLED 0x0010
+#define MACB_CAPS_JUMBO0x0020
#define MACB_CAPS_FIFO_MODE0x1000
#define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000
#define MACB_CAPS_SG_DISABLED 0x4000
#define MACB_CAPS_MACB_IS_GEM 0x8000
-#define MACB_CAPS_JUMBO0x0010
/* Bit manipulation macros */
#define MACB_BIT(name) \
--
2.7.4
[linux-mm] Drastic increase in application memory usage with Kernel version upgrade
Hi All, For one of our ARM embedded product, we recently updated the Kernel version from 3.4 to 3.18 and we noticed that the same application memory usage (PSS value) gone up by ~10% and for some cases it even crossed ~50%. There is no change in platform part. All platform component was built with ARM 32-bit toolchain. However, the Kernel is changed from 32-bit to 64-bit. Is upgrading Kernel version and moving from 32-bit to 64-bit is such a risk ? After the upgrade, what can we do further to reduce the application memory usage ? Is there any other factor that will help us to improve without major modifications in platform ? As a proof, we did a small experiment on our Ubuntu-32 bit machine. We upgraded Ubuntu Kernel version from 3.13 to 4.01 and we observed the following: - |UBUNTU-32 bit |Kernel 3.13|Kernel 4.03|DIFF | |CALCULATOR PSS |6057 KB|6466 KB|409 KB | - So, just by upgrading the Kernel version: PSS value for calculator is increased by 409KB. If anybody knows any in-sight about it please point out more details about the root cause. Thank You! Regards, Pintu
WARNING: CPU: 0 PID: 1271 at drivers/mmc/core/core.c:991 mmc_release_host+0xa0/0xa8
Hey Ulf, Since moving my HiKey branch to pre-v4.8-rc1 (linus's HEAD), I've been seeing the following warning occasionally. Usually after seeing it, the system will refuse to reboot (system does the "Emergency remount complete" but then just sits there, and if I ctrl-c I can use the shell fine but many commands will get me stuck). Anyway, if you have any ideas... thanks -john [ 24.154245] [ cut here ] [ 24.158903] WARNING: CPU: 2 PID: 1273 at drivers/mmc/core/core.c:991 mmc_release_host+0xa0/0xa8 [ 24.167605] [ 24.169104] CPU: 2 PID: 1273 Comm: mmcqd/0 Not tainted 4.7.0-11945-gb30f1d6-dirty #706 [ 24.177024] Hardware name: HiKey Development Board (DT) [ 24.182253] task: ffc0793d8c80 task.stack: ffc078c48000 [ 24.188178] PC is at mmc_release_host+0xa0/0xa8 [ 24.192725] LR is at mmc_put_card+0x18/0x3c [ 24.196917] pc : [] lr : [] pstate: 8145 [ 24.204317] sp : ffc078c4bd20 [ 24.207636] x29: ffc078c4bd20 x28: [ 24.212975] x27: x26: ffc077903420 [ 24.216220] x25: ffc078788028 x24: ffc0787e8800 [ 24.216232] x23: ffc078788000 x22: [ 24.216243] x21: x20: ffc078788018 [ 24.216254] x19: ffc0787e8800 x18: [ 24.216265] x17: x16: [ 24.216276] x15: x14: ffc078789430 [ 24.216288] x13: 002f x12: b853 [ 24.216299] x11: ffc077903420 x10: 0860 [ 24.216310] x9 : ffc078c48000 x8 : ffc0793d9540 [ 24.216322] x7 : 00d3f8c7 x6 : 2bd0 [ 24.216333] x5 : 021458fa x4 : 00ff [ 24.216344] x3 : d055 x2 : ffc078c4bd5c [ 24.216355] x1 : x0 : [ 24.216366] [ 24.216372] ---[ end trace 74dade4766b71d8d ]--- [ 24.216377] Call trace: [ 24.216386] Exception stack(0xffc078c4bb50 to 0xffc078c4bc80) [ 24.216394] bb40: ffc0787e8800 0080 [ 24.216403] bb60: ffc078c4bd20 ff80086c2550 ff8008ca6000 ffc0784fb200 [ 24.216411] bb80: ffc07bf4b7e8 0008 ffc0793d8d00 ff8008c82780 [ 24.216420] bba0: ffc078c4bbe0 ff800843576c ffc078c4bbf0 ff800843576c [ 24.216429] bbc0: ffc078c4bcc0 ffc078c4bc78 ffc078c4bc10 ff800843576c [ 24.216437] bbe0: ffc078c4bce0 ffc078c4bc98 [ 24.216445] bc00: ffc078c4bd5c d055 00ff 021458fa [ 24.216452] bc20: 2bd0 00d3f8c7 ffc0793d9540 ffc078c48000 [ 24.216460] bc40: 0860 ffc077903420 b853 002f [ 24.216467] bc60: ffc078789430 [ 24.216479] [] mmc_release_host+0xa0/0xa8 [ 24.216486] [] mmc_put_card+0x18/0x3c [ 24.216497] [] mmc_blk_issue_rq+0x11c/0x4a4 [ 24.216506] [] mmc_queue_thread+0x98/0x158 [ 24.216517] [] kthread+0xd0/0xe4 [ 24.216527] [] ret_from_fork+0x10/0x40
Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling
On Thu, Aug 4, 2016 at 6:43 PM, Alexei Starovoitov
wrote:
> On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote:
>> On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote:
>>
>> > As for pmu tracepoints: if I were to instrument it (although I wasn't
>> > planning to), I'd put a tracepoint in perf_event_overflow() called
>> > "perf:perf_overflow", with the same arguments. That could then be used
>> > for all PMU overflow events, without needing to add specific
>> > tracepoints.
>>
>> Could we not teach BPF to replace event->overflow_handler and inject
>> itself there?
>>
>> We don't currently have nice interfaces for doing that, but it should be
>> possible to do I think. We already have the indirect function call, so
>> injecting ourself there has 0 overhead.
Sounds like a good idea, especially for things like struct
file_operations so that we can statically instrument file system
read/writes with zero non-enabled overhead, and not worry about high
frequency workloads (>10M events/sec).
These perf probes aren't high frequency, though, and the code is not
normally in use, so overhead should be much less of a concern.
Sampling at 999 Hertz * CPUs is as frequent as I'd go. And if the
tracepoint code is still adding a mem read, conditional, and branch,
then that's not many instructions, especially considering the normal
use case of these perf functions: creating records and writing to a
perf ring buffer, then picking that up in user space by perf, then
either processing it live or writing to perf.data, back to the file
system, etc. It would be hard to benchmark the effect of adding a few
instructions to that path (and any results may be more sensitive to
cache line placement than the instructions).
The perf:perf_hrtimer probe point is also reading state mid-way
through a function, so it's not quite as simple as wrapping the
function pointer. I do like that idea, though, but for things like
struct file_operations.
>
> you're right. All makes sense. I guess I was too lazy to look into
> how to do it properly. Adding a tracepoint looked like quick and
> easy way to achieve the same.
> As far as api goes probably existing IOC_SET_BPF ioctl will do too.
> Currently overflow_handler is set at event alloc time. If we start
> changing it on the fly with atomic xchg(), afaik things shouldn't
> break, since each overflow_handler is run to completion and doesn't
> change global state, right?
>
How would it be implemented? I was thinking of adding explicit wrappers, eg:
static ssize_t
__ext4_file_write_iter_tracepoint(struct kiocb *iocb, struct iov_iter *from)
{
trace_ext4_write_iter(iocb, from);
ext4_file_write_iter(iocb, from);
}
Then switching in __ext4_file_write_iter_tracepoint() as needed.
I was wondering about doing this dynamically, but wouldn't that then
create another problem of maintenance -- we'd need to decorate such
code with a comment, at least, to say "this function is exposed as a
tracepoint".
If a dynamic approach is still desired, and the goal is zero
non-enabled overhead, then I'd also wonder if we could leverage
kprobes to do this. Imagine walking a file_operations to find the
addresses, and then kprobe-ing the addresses. Not the same (or
probably as efficient) as setting the function pointer, but, using
existing kprobes.
Brendan
linux-next: Tree for Aug 5
Hi all, Please do not add material destined for v4.9 to your linux-next included branches until after v4.8-rc1 has been released. Changes since 20160804: The rdma tree gained conflicts against Linus' tree. The jc_docs tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 1134 1302 files changed, 74324 insertions(+), 13920 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 241 trees (counting Linus' and 35 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (b067c9045af4 Merge branch 'parisc-4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux) Merging fixes/master (77a87824ed67 clocksource/drivers/clps_711x: fixup for "ARM: clps711x:) Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported variables) Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if DW2_UNWIND is disabled) Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 errata initialization) Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs for v4.7-rc2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging powerpc-fixes/fixes (bad60e6f259a Merge tag 'powerpc-4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support is disabled) Merging net/master (7cf210dc2678 Merge branch 'qlcnic-fixes') Merging ipsec/master (6916fb3b10b3 xfrm: Ignore socket policies when rebuilding hash tables) Merging netfilter/master (43dcff349f09 net: qlcnic: avoid superfluous assignement) Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes') Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git) Merging mac80211/master (c37a54ac37e7 mac80211: mesh: flush stations before beacons are stopped) Merging sound-current/for-linus (59ec4b57bcae ALSA: hda - Fix headset mic detection problem for two dell machines) Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC code) Merging driver-core.current/driver-core-linus (523d939ef98f Linux 4.7) Merging tty.current/tty-linus (0e06f5c0deee Merge branch 'akpm' (patches from Andrew)) Merging usb.current/usb-linus (e65805251f2d Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command) Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5) Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: otg-fsm: add license to usb-otg-fsm) Merging staging.current/staging-linus (0e06f5c0deee Merge branch 'akpm' (patches from Andrew)) Merging char-misc.current/char-misc-linus (0e06f5c0deee Merge branch 'akpm' (patches from Andrew)) Merging input-current/for-linus (22fe874f3803 Input: silead - remove some dead code) Merging crypto-current/master (8cf740ae85df crypto: marvell - Don't copy IV vectors from the _process op for ciphers) Merging ide/master (797cee982eef Merge branch 'stable-4.8' of git://git.inf
RE: [PATCH 3/3] mpt3sas: Fix warnings exposed by W=1
Hi,
Please consider this patch as Acked-by: Chaitra P B
Thanks,
Chaitra
-Original Message-
From: mpt-fusionlinux@broadcom.com
[mailto:mpt-fusionlinux@broadcom.com] On Behalf Of Calvin Owens
Sent: Friday, July 29, 2016 10:08 AM
To: Sathya Prakash; Chaitra P B; Suganath Prabu Subramani; James E.J.
Bottomley; Martin K. Petersen
Cc: mpt-fusionlinux@broadcom.com; linux-s...@vger.kernel.org;
linux-kernel@vger.kernel.org; kernel-t...@fb.com; Calvin Owens
Subject: [PATCH 3/3] mpt3sas: Fix warnings exposed by W=1
Trivial non-functional changes for a couple annoying things:
1) Functions local to files are not declared static, which is
frustrating when reading the code because it's non-obvious at first
glance what's actually called from other files.
2) Set-but-unused variables abound, presumably to mask -Wunused-result
errors in the past. None of these are flagged today though (with one
exception noted below), so remove them.
Fixing (2) exposed the fact that we improperly ignore the return value of
scsi_device_reprobe() in _scsih_reprobe_lun(). Fixing the calling code to
deal with the potential error is non-trivial, so for now just WARN().
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 18 +++-
drivers/scsi/mpt3sas/mpt3sas_config.c| 4 +-
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 29 ++---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 70
+++-
drivers/scsi/mpt3sas/mpt3sas_transport.c | 16 ++--
5 files changed, 56 insertions(+), 81 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 0956183..df95d1a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2039,7 +2039,7 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
* mpt3sas_base_unmap_resources - free controller resources
* @ioc: per adapter object
*/
-void
+static void
mpt3sas_base_unmap_resources(struct MPT3SAS_ADAPTER *ioc) {
struct pci_dev *pdev = ioc->pdev;
@@ -3884,7 +3884,6 @@ _base_handshake_req_reply_wait(struct
MPT3SAS_ADAPTER *ioc, int request_bytes,
MPI2DefaultReply_t *default_reply = (MPI2DefaultReply_t *)reply;
int i;
u8 failed;
- u16 dummy;
__le32 *mfp;
/* make sure doorbell is not in use */ @@ -3964,7 +3963,7 @@
_base_handshake_req_reply_wait(struct MPT3SAS_ADAPTER *ioc, int
request_bytes,
return -EFAULT;
}
if (i >= reply_bytes/2) /* overflow case */
- dummy = readl(&ioc->chip->Doorbell);
+ readl(&ioc->chip->Doorbell);
else
reply[i] = le16_to_cpu(readl(&ioc->chip->Doorbell)
& MPI2_DOORBELL_DATA_MASK);
@@ -4009,7 +4008,6 @@ mpt3sas_base_sas_iounit_control(struct
MPT3SAS_ADAPTER *ioc, {
u16 smid;
u32 ioc_state;
- unsigned long timeleft;
bool issue_reset = false;
int rc;
void *request;
@@ -4062,7 +4060,7 @@ mpt3sas_base_sas_iounit_control(struct
MPT3SAS_ADAPTER *ioc,
ioc->ioc_link_reset_in_progress = 1;
init_completion(&ioc->base_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
- timeleft = wait_for_completion_timeout(&ioc->base_cmds.done,
+ wait_for_completion_timeout(&ioc->base_cmds.done,
msecs_to_jiffies(1));
if ((mpi_request->Operation == MPI2_SAS_OP_PHY_HARD_RESET ||
mpi_request->Operation == MPI2_SAS_OP_PHY_LINK_RESET) && @@
-4112,7 +4110,6 @@ mpt3sas_base_scsi_enclosure_processor(struct
MPT3SAS_ADAPTER *ioc, {
u16 smid;
u32 ioc_state;
- unsigned long timeleft;
bool issue_reset = false;
int rc;
void *request;
@@ -4163,7 +4160,7 @@ mpt3sas_base_scsi_enclosure_processor(struct
MPT3SAS_ADAPTER *ioc,
memcpy(request, mpi_request, sizeof(Mpi2SepReply_t));
init_completion(&ioc->base_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
- timeleft = wait_for_completion_timeout(&ioc->base_cmds.done,
+ wait_for_completion_timeout(&ioc->base_cmds.done,
msecs_to_jiffies(1));
if (!(ioc->base_cmds.status & MPT3_CMD_COMPLETE)) {
pr_err(MPT3SAS_FMT "%s: timeout\n",
@@ -4548,7 +4545,6 @@ _base_send_port_enable(struct MPT3SAS_ADAPTER *ioc)
{
Mpi2PortEnableRequest_t *mpi_request;
Mpi2PortEnableReply_t *mpi_reply;
- unsigned long timeleft;
int r = 0;
u16 smid;
u16 ioc_status;
@@ -4576,8 +4572,7 @@ _base_send_port_enable(struct MPT3SAS_ADAPTER *ioc)
init_completion(&ioc->port_enable_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
- timeleft =
wait_for_completion_timeout(&ioc->port_enable_cmds.done,
- 300*HZ);
+ wait_for_completion_timeout(&ioc->port_enable_cmds.done, 300*HZ);
if (
RE: [PATCH 2/3] mpt3sas: Eliminate dead sleep_flag code
Hi,
Please consider this patch as Acked-by: Chaitra P B
Thanks,
Chaitra
-Original Message-
From: Calvin Owens [mailto:calvinow...@fb.com]
Sent: Friday, July 29, 2016 10:08 AM
To: Sathya Prakash; Chaitra P B; Suganath Prabu Subramani; James E.J.
Bottomley; Martin K. Petersen
Cc: mpt-fusionlinux@broadcom.com; linux-s...@vger.kernel.org;
linux-kernel@vger.kernel.org; kernel-t...@fb.com; Calvin Owens
Subject: [PATCH 2/3] mpt3sas: Eliminate dead sleep_flag code
With the exception of a single call to wait_for_doorbell_int(), all this
conditional sleeping code is dead. So delete it.
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 241
+--
drivers/scsi/mpt3sas/mpt3sas_base.h | 6 +-
drivers/scsi/mpt3sas/mpt3sas_config.c| 3 +-
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 15 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 21 +--
drivers/scsi/mpt3sas/mpt3sas_transport.c | 12 +-
6 files changed, 120 insertions(+), 178 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 751f13e..0956183 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -98,7 +98,7 @@ MODULE_PARM_DESC(mpt3sas_fwfault_debug,
" enable detection of firmware fault and halt firmware -
(default=0)");
static int
-_base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+_base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc);
/**
* _scsih_set_fwfault_debug - global setting of ioc->fwfault_debug.
@@ -218,8 +218,7 @@ _base_fault_reset_work(struct work_struct *work)
ioc->non_operational_loop = 0;
if ((doorbell & MPI2_IOC_STATE_MASK) !=
MPI2_IOC_STATE_OPERATIONAL) {
- rc = mpt3sas_base_hard_reset_handler(ioc, CAN_SLEEP,
- FORCE_BIG_HAMMER);
+ rc = mpt3sas_base_hard_reset_handler(ioc,
FORCE_BIG_HAMMER);
pr_warn(MPT3SAS_FMT "%s: hard reset: %s\n", ioc->name,
__func__, (rc == 0) ? "success" : "failed");
doorbell = mpt3sas_base_get_iocstate(ioc, 0); @@ -2145,7
+2144,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
_base_mask_interrupts(ioc);
- r = _base_get_ioc_facts(ioc, CAN_SLEEP);
+ r = _base_get_ioc_facts(ioc);
if (r)
goto out_fail;
@@ -3172,12 +3171,11 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER
*ioc)
/**
* _base_allocate_memory_pools - allocate start of day memory pools
* @ioc: per adapter object
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
*
* Returns 0 success, anything else error
*/
static int
-_base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc, int sleep_flag)
+_base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
{
struct mpt3sas_facts *facts;
u16 max_sge_elements;
@@ -3647,29 +3645,25 @@ mpt3sas_base_get_iocstate(struct MPT3SAS_ADAPTER
*ioc, int cooked)
* _base_wait_on_iocstate - waiting on a particular ioc state
* @ioc_state: controller state { READY, OPERATIONAL, or RESET }
* @timeout: timeout in second
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
*
* Returns 0 for success, non-zero for failure.
*/
static int
-_base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32 ioc_state, int
timeout,
- int sleep_flag)
+_base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32 ioc_state, int
+timeout)
{
u32 count, cntdn;
u32 current_state;
count = 0;
- cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
+ cntdn = 1000 * timeout;
do {
current_state = mpt3sas_base_get_iocstate(ioc, 1);
if (current_state == ioc_state)
return 0;
if (count && current_state == MPI2_IOC_STATE_FAULT)
break;
- if (sleep_flag == CAN_SLEEP)
- usleep_range(1000, 1500);
- else
- udelay(500);
+
+ usleep_range(1000, 1500);
count++;
} while (--cntdn);
@@ -3681,24 +3675,22 @@ _base_wait_on_iocstate(struct MPT3SAS_ADAPTER
*ioc, u32 ioc_state, int timeout,
* a write to the doorbell)
* @ioc: per adapter object
* @timeout: timeout in second
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
*
* Returns 0 for success, non-zero for failure.
*
* Notes: MPI2_HIS_IOC2SYS_DB_STATUS - set to one when IOC writes to
doorbell.
*/
static int
-_base_diag_reset(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+_base_diag_reset(struct MPT3SAS_ADAPTER *ioc);
static int
-_base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout,
- int sleep_flag)
+_base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout)
{
u32 cntdn, count;
u32 int_status;
count = 0;
- cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
+ cntdn = 1000 * timeout;
do {
RE: [PATCH 1/3] mpt3sas: Eliminate conditional locking in mpt3sas_scsih_issue_tm()
Hi,
Please consider this patch as Acked-by: Chaitra P B
Thanks,
Chaitra
-Original Message-
From: Calvin Owens [mailto:calvinow...@fb.com]
Sent: Friday, July 29, 2016 10:08 AM
To: Sathya Prakash; Chaitra P B; Suganath Prabu Subramani; James E.J.
Bottomley; Martin K. Petersen
Cc: mpt-fusionlinux@broadcom.com; linux-s...@vger.kernel.org;
linux-kernel@vger.kernel.org; kernel-t...@fb.com; Calvin Owens
Subject: [PATCH 1/3] mpt3sas: Eliminate conditional locking in
mpt3sas_scsih_issue_tm()
This flag that conditionally acquires the mutex is confusing and prone to
bugginess: refactor it into two separate function calls, and make the
unlocked one complain if it's called outside the mutex.
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 16 +++--
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 5 ++-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 66
+---
3 files changed, 38 insertions(+), 49 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index eb7f5b0..f0baafd 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -794,16 +794,6 @@ struct reply_post_struct {
dma_addr_t reply_post_free_dma;
};
-/**
- * enum mutex_type - task management mutex type
- * @TM_MUTEX_OFF: mutex is not required becuase calling function is
acquiring it
- * @TM_MUTEX_ON: mutex is required
- */
-enum mutex_type {
- TM_MUTEX_OFF = 0,
- TM_MUTEX_ON = 1,
-};
-
typedef void (*MPT3SAS_FLUSH_RUNNING_CMDS)(struct MPT3SAS_ADAPTER *ioc);
/**
* struct MPT3SAS_ADAPTER - per adapter struct @@ -1291,7 +1281,11 @@
void mpt3sas_scsih_reset_handler(struct MPT3SAS_ADAPTER *ioc, int
reset_phase);
int mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle,
uint channel, uint id, uint lun, u8 type, u16 smid_task,
- ulong timeout, enum mutex_type m_type);
+ ulong timeout);
+int mpt3sas_scsih_issue_locked_tm(struct MPT3SAS_ADAPTER *ioc, u16
handle,
+ uint channel, uint id, uint lun, u8 type, u16 smid_task,
+ ulong timeout);
+
void mpt3sas_scsih_set_tm_flag(struct MPT3SAS_ADAPTER *ioc, u16 handle);
void mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER *ioc, u16 handle);
void mpt3sas_expander_remove(struct MPT3SAS_ADAPTER *ioc, u64
sas_address); diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index 7d00f09..75ae533 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -1001,10 +1001,9 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc,
struct mpt3_ioctl_command karg,
ioc->name,
le16_to_cpu(mpi_request->FunctionDependent1));
mpt3sas_halt_firmware(ioc);
- mpt3sas_scsih_issue_tm(ioc,
+ mpt3sas_scsih_issue_locked_tm(ioc,
le16_to_cpu(mpi_request->FunctionDependent1),
0, 0,
- 0, MPI2_SCSITASKMGMT_TASKTYPE_TARGET_RESET, 0,
30,
- TM_MUTEX_ON);
+ 0, MPI2_SCSITASKMGMT_TASKTYPE_TARGET_RESET, 0,
30);
} else
mpt3sas_base_hard_reset_handler(ioc, CAN_SLEEP,
FORCE_BIG_HAMMER);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index acabe48..c93a7ba 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2201,7 +2201,6 @@ mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER
*ioc, u16 handle)
* @type: MPI2_SCSITASKMGMT_TASKTYPE__XXX (defined in mpi2_init.h)
* @smid_task: smid assigned to the task
* @timeout: timeout in seconds
- * @m_type: TM_MUTEX_ON or TM_MUTEX_OFF
* Context: user
*
* A generic API for sending task management requests to firmware.
@@ -2212,8 +2211,7 @@ mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER
*ioc, u16 handle)
*/
int
mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, uint
channel,
- uint id, uint lun, u8 type, u16 smid_task, ulong timeout,
- enum mutex_type m_type)
+ uint id, uint lun, u8 type, u16 smid_task, ulong timeout)
{
Mpi2SCSITaskManagementRequest_t *mpi_request;
Mpi2SCSITaskManagementReply_t *mpi_reply; @@ -2224,21 +,19 @@
mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, uint
channel,
int rc;
u16 msix_task = 0;
- if (m_type == TM_MUTEX_ON)
- mutex_lock(&ioc->tm_cmds.mutex);
+ lockdep_assert_held(&ioc->tm_cmds.mutex);
+
if (ioc->tm_cmds.status != MPT3_CMD_NOT_USED) {
pr_info(MPT3SAS_FMT "%s: tm_cmd busy!!!\n",
__func__, ioc->name);
- rc = FAILED;
- goto err_out;
+ return FAILED;
}
if (ioc->shost_recovery || ioc->remove_host ||
ioc->pci_error_recover
Re: [RFC PATCH 1/2] net: macb: Correct CAPS mask
On Thu, Aug 4, 2016 at 7:37 PM, Nicolas Ferre wrote:
> Le 01/08/2016 à 09:20, Harini Katakam a écrit :
>> USRIO and JUMBO CAPS have the same mask.
>> Fix the same.
>>
>> Signed-off-by: Harini Katakam
>
> Hi,
> Indeed there's a bug...
>
>
>> ---
>> drivers/net/ethernet/cadence/macb.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb.h
>> b/drivers/net/ethernet/cadence/macb.h
>> index 36893d8..b6fcf10 100644
>> --- a/drivers/net/ethernet/cadence/macb.h
>> +++ b/drivers/net/ethernet/cadence/macb.h
>> @@ -403,11 +403,11 @@
>> #define MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII 0x0004
>> #define MACB_CAPS_NO_GIGABIT_HALF0x0008
>> #define MACB_CAPS_USRIO_DISABLED 0x0010
>> +#define MACB_CAPS_JUMBO 0x0020
>> #define MACB_CAPS_FIFO_MODE 0x1000
>> #define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000
>> #define MACB_CAPS_SG_DISABLED0x4000
>> #define MACB_CAPS_MACB_IS_GEM0x8000
>> -#define MACB_CAPS_JUMBO 0x0010
>
> Acked-by: Nicolas Ferre
>
> Can you please send it independently without the RFC tag in the subject
> and with the following tags in the body as well:
>
> Fixes: ce721a702197 ("net: ethernet: cadence-macb: Add disabled usrio caps")
> Cc: sta...@vger.kernel.org # v4.5+
>
Thanks Nicolas. I'll do that.
Regards,
Harini
>> /* Bit manipulation macros */
>> #define MACB_BIT(name) \
>>
>
> Thanks, bye,
> --
> Nicolas Ferre
Re: [PATCH v0 2/4] i2c: bcm-kona: Use complete() instead of complete_all()
On Wed, Aug 3, 2016 at 5:03 AM, Daniel Wagner wrote: > From: Daniel Wagner > > There is only one waiter for the completion, therefore there > is no need to use complete_all(). Let's make that clear by > using complete() instead of complete_all(). > > The usage pattern of the completion is: > > bcm_kona_send_i2c_cmd() > reinit_completion() > ... > bcm_kona_i2c_send_cmd_to_ctrl() > ... > wait_for_completion_timeout() > > Signed-off-by: Daniel Wagner Reviewed-by: Tim Kryger > --- > drivers/i2c/busses/i2c-bcm-kona.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-bcm-kona.c > b/drivers/i2c/busses/i2c-bcm-kona.c > index ac9f476..f987432 100644 > --- a/drivers/i2c/busses/i2c-bcm-kona.c > +++ b/drivers/i2c/busses/i2c-bcm-kona.c > @@ -229,7 +229,7 @@ static irqreturn_t bcm_kona_i2c_isr(int irq, void *devid) >dev->base + TXFCR_OFFSET); > > writel(status & ~ISR_RESERVED_MASK, dev->base + ISR_OFFSET); > - complete_all(&dev->done); > + complete(&dev->done); > > return IRQ_HANDLED; > } > -- > 2.7.4 > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 2/3] regulator: qcom_smd: Fix voltage ranges for pma8084 ftsmps and pldo
On Thu, Aug 04, 2016 at 05:57:48PM -0700, Stephen Boyd wrote:
> On 07/11, Andy Gross wrote:
> > On Mon, Jul 11, 2016 at 02:50:08PM -0700, Stephen Boyd wrote:
> > > The voltage ranges listed here are wrong. The pma8084 pldo
> > > supports three different overlapping voltage ranges with
> > > differing step sizes and the pma8084 ftsmps supports two. These
> > > ranges can be seen in the "native" spmi regulator driver
> > > (qcom_spmi-regulator.c) at pldo_ranges[] and ftsmps_ranges[]
> > > respectively. Port these ranges over to the RPM SMD regulator
> > > driver so that we list the appropriate set of supported voltages
> > > on these types of regulators.
> > >
> > > Cc: Andy Gross
> > > Cc: Bjorn Andersson
> > > Fixes: ee01d0c91ef1 ("regulator: qcom-smd: Add support for PMA8084")
> > > Signed-off-by: Stephen Boyd
> >
> >
> >
> > > static const struct regulator_desc pma8084_pldo = {
> > > .linear_ranges = (struct regulator_linear_range[]) {
> > > - REGULATOR_LINEAR_RANGE(75, 0, 30, 25000),
> > > - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> > > + REGULATOR_LINEAR_RANGE( 75, 0, 63, 12500),
> >
> > It was my understanding that the PMOS ldos only support 25mV and 50mV
> > incremements.
> >
>
> Unfortunately that isn't true. It also supports 12.5mV steps for
> the lower voltage ranges.
Ok. with that resolved:
Reviewed-by: Andy Gross
Re: [PATCH 1/3] regulator: qcom_smd: Fix voltage ranges for pm8x41
On Thu, Aug 04, 2016 at 05:58:26PM -0700, Stephen Boyd wrote:
> On 07/11, Andy Gross wrote:
> > On Mon, Jul 11, 2016 at 02:50:07PM -0700, Stephen Boyd wrote:
> >
> > > static const struct regulator_desc pm8941_pldo = {
> > > .linear_ranges = (struct regulator_linear_range[]) {
> > > - REGULATOR_LINEAR_RANGE( 75, 0, 30, 25000),
> > > - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> > > + REGULATOR_LINEAR_RANGE( 75, 0, 63, 12500),
> > > + REGULATOR_LINEAR_RANGE(155, 64, 126, 25000),
> > > + REGULATOR_LINEAR_RANGE(310, 127, 163, 5),
> > > },
> > > - .n_linear_ranges = 2,
> > > - .n_voltages = 100,
> > > + .n_linear_ranges = 3,
> > > + .n_voltages = 164,
> > > .ops = &rpm_smps_ldo_ops,
> > > };
> >
> > Still a little confused on if the 12.5mV is allowed on pmos ldo. It seems
> > like the
> > nmos has 1 range of 5mV steps. The PMOS has 2 ranges, using 25mV and 50mV
> >
>
> The values I've put in these patches are the correct ranges.
Ok. As with the other patch:
Reviewed-by: Andy Gross
Re: [RFC V2 PATCH 17/25] net/netpolicy: introduce netpolicy_pick_queue
On Thu, Aug 4, 2016 at 12:36 PM, wrote:
> From: Kan Liang
>
> To achieve better network performance, the key step is to distribute the
> packets to dedicated queues according to policy and system run time
> status.
>
> This patch provides an interface which can return the proper dedicated
> queue for socket/task. Then the packets of the socket/task will be
> redirect to the dedicated queue for better network performance.
>
> For selecting the proper queue, currently it uses round-robin algorithm
> to find the available object from the given policy object list. The
> algorithm is good enough for now. But it could be improved by some
> adaptive algorithm later.
>
Seriously? You want to all of this code so we revert to TX queue
selection by round robin?
> The selected object will be stored in hashtable. So it does not need to
> go through the whole object list every time.
>
> Signed-off-by: Kan Liang
> ---
> include/linux/netpolicy.h | 5 ++
> net/core/netpolicy.c | 136
> ++
> 2 files changed, 141 insertions(+)
>
> diff --git a/include/linux/netpolicy.h b/include/linux/netpolicy.h
> index 5900252..a522015 100644
> --- a/include/linux/netpolicy.h
> +++ b/include/linux/netpolicy.h
> @@ -97,6 +97,7 @@ extern void update_netpolicy_sys_map(void);
> extern int netpolicy_register(struct netpolicy_instance *instance,
> enum netpolicy_name policy);
> extern void netpolicy_unregister(struct netpolicy_instance *instance);
> +extern int netpolicy_pick_queue(struct netpolicy_instance *instance, bool
> is_rx);
> #else
> static inline void update_netpolicy_sys_map(void)
> {
> @@ -111,6 +112,10 @@ static inline void netpolicy_unregister(struct
> netpolicy_instance *instance)
> {
> }
>
> +static inline int netpolicy_pick_queue(struct netpolicy_instance *instance,
> bool is_rx)
> +{
> + return 0;
> +}
> #endif
>
> #endif /*__LINUX_NETPOLICY_H*/
> diff --git a/net/core/netpolicy.c b/net/core/netpolicy.c
> index 3605761..98ca430 100644
> --- a/net/core/netpolicy.c
> +++ b/net/core/netpolicy.c
> @@ -290,6 +290,142 @@ static void netpolicy_record_clear_dev_node(struct
> net_device *dev)
> spin_unlock_bh(&np_hashtable_lock);
> }
>
> +static struct netpolicy_object *get_avail_object(struct net_device *dev,
> +enum netpolicy_name policy,
> +bool is_rx)
> +{
> + int dir = is_rx ? NETPOLICY_RX : NETPOLICY_TX;
> + struct netpolicy_object *tmp, *obj = NULL;
> + int val = -1;
> +
> + /* Check if net policy is supported */
> + if (!dev || !dev->netpolicy)
> + return NULL;
> +
> + /* The system should have queues which support the request policy. */
> + if ((policy != dev->netpolicy->cur_policy) &&
> + (dev->netpolicy->cur_policy != NET_POLICY_MIX))
> + return NULL;
> +
> + spin_lock_bh(&dev->np_ob_list_lock);
> + list_for_each_entry(tmp, &dev->netpolicy->obj_list[dir][policy],
> list) {
> + if ((val > atomic_read(&tmp->refcnt)) ||
> + (val == -1)) {
> + val = atomic_read(&tmp->refcnt);
> + obj = tmp;
> + }
> + }
> +
> + if (WARN_ON(!obj)) {
> + spin_unlock_bh(&dev->np_ob_list_lock);
> + return NULL;
> + }
> + atomic_inc(&obj->refcnt);
> + spin_unlock_bh(&dev->np_ob_list_lock);
> +
> + return obj;
> +}
> +
> +static int get_avail_queue(struct netpolicy_instance *instance, bool is_rx)
> +{
> + struct netpolicy_record *old_record, *new_record;
> + struct net_device *dev = instance->dev;
> + unsigned long ptr_id = (uintptr_t)instance->ptr;
> + int queue = -1;
> +
> + spin_lock_bh(&np_hashtable_lock);
> + old_record = netpolicy_record_search(ptr_id);
> + if (!old_record) {
> + pr_warn("NETPOLICY: doesn't registered. Remove net policy
> settings!\n");
> + instance->policy = NET_POLICY_INVALID;
> + goto err;
> + }
> +
> + if (is_rx && old_record->rx_obj) {
> + queue = old_record->rx_obj->queue;
> + } else if (!is_rx && old_record->tx_obj) {
> + queue = old_record->tx_obj->queue;
> + } else {
> + new_record = kzalloc(sizeof(*new_record), GFP_KERNEL);
> + if (!new_record)
> + goto err;
> + memcpy(new_record, old_record, sizeof(*new_record));
> +
> + if (is_rx) {
> + new_record->rx_obj = get_avail_object(dev,
> new_record->policy, is_rx);
> + if (!new_record->dev)
> + new_record->dev = dev;
> + if (!new_record->rx_obj) {
> + kfree(new_record);
> +
RE: [PATCH v5] usb: ohci-at91: Forcibly suspend ports while USB suspend
Hi Alan,
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 2016年8月4日 23:02
> To: Wenyou Yang
> Cc: Greg Kroah-Hartman ; Nicolas Ferre
> ; Alexandre Belloni electrons.com>; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v5] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
>
> On Thu, 4 Aug 2016, Wenyou Yang wrote:
>
> > The usb controller does not managed correctly the suspend mode for the
> > ehci. In echi mode, there is no way to have utmi_suspend_o_n[1]
> > suspend without any device connected to it. This is why this specific
> > control is added to fix this issue. The suspend mode works in ohci
> > mode.
>
> Why are you talking about EHCI mode? This patch is only for the
> ohci-at91 driver.
Actually I described the issue according to the documents from our IP,
and this specific control is recommended to do in ohci mode.
>
> > This specific control is by setting the SUSPEND_A/B/C fields of
> > SFR_OHCIICR(OHCI Interrupt Configuration Register) in the SFR while
> > OHCI USB suspend.
> >
> > This setting operation must be done before the USB clock disabled,
> > clear them after the USB clock enabled.
> >
> > Signed-off-by: Wenyou Yang
> > Reviewed-by: Alexandre Belloni
> > Acked-by: Nicolas Ferre
>
> I don't know if this is any better than before! See the comments below.
Yes, I think so.
What else advice?
>
> > ---
> >
> > Changes in v5:
> > - Use the USB_PORT_FEAT_SUSPEND subcase of the SetPortFeature case
> >to take care it.
> > - Update the commit log.
> >
> > Changes in v4:
> > - To check whether the SFR node with "atmel,sama5d2-sfr" compatible
> >is present or not to decide if this feature is applied or not
> >when USB OHCI suspend/resume, instead of new compatible.
> > - Drop the compatible "atmel,sama5d2-ohci".
> > - Drop [PATCH 2/2] ARM: at91/dt: sama5d2: Use new compatible for
> >ohci node.
> > - Drop include/soc/at91/at91_sfr.h, move the macro definitions to
> >atmel-sfr.h which already exists.
> > - Change the defines to align the exists.
> >
> > Changes in v3:
> > - Change the compatible description for more precise.
> >
> > Changes in v2:
> > - Add compatible to support forcibly suspend the ports.
> > - Add soc/at91/at91_sfr.h to accommodate the defines.
> > - Add error checking for .sfr_regmap.
> > - Remove unnecessary regmap_read() statement.
>
>
> > @@ -282,6 +301,28 @@ static int ohci_at91_hub_status_data(struct usb_hcd
> *hcd, char *buf)
> > return length;
> > }
> >
> > +static int ohci_at91_port_ctrl(struct regmap *regmap, u16 port, u8
> > +set) {
> > + u32 regval;
> > + int ret;
> > +
> > + if (!regmap)
> > + return 0;
> > +
> > + ret = regmap_read(regmap, AT91_SFR_OHCIICR, ®val);
> > + if (ret)
> > + return ret;
> > +
> > + if (set)
> > + regval |= AT91_OHCIICR_SUSPEND(port);
> > + else
> > + regval &= ~AT91_OHCIICR_SUSPEND(port);
>
> In the earlier versions of this patch, you did not use the port number.
> Why has this changed?
This function is called by ohci_at91_hub_control(), which is invoked on basis
of port number.
So, I think it is more reasonable of adding the port argument.
>
> How many ports does this controller have?
This controller has three ports.
>
> > +
> > + regmap_write(regmap, AT91_SFR_OHCIICR, regval);
> > +
> > + return 0;
> > +}
> > +
> > /*
> > * Look at the control requests to the root hub and see if we need to
> > override.
> > */
> > @@ -289,6 +330,7 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd,
> u16 typeReq, u16 wValue,
> > u16 wIndex, char *buf, u16 wLength) {
> > struct at91_usbh_data *pdata =
> > dev_get_platdata(hcd->self.controller);
> > + struct ohci_at91_priv *ohci_at91 = hcd_to_ohci_at91_priv(hcd);
> > struct usb_hub_descriptor *desc;
> > int ret = -EINVAL;
> > u32 *data = (u32 *)buf;
> > @@ -301,7 +343,8 @@ static int ohci_at91_hub_control(struct usb_hcd
> > *hcd, u16 typeReq, u16 wValue,
> >
> > switch (typeReq) {
> > case SetPortFeature:
> > - if (wValue == USB_PORT_FEAT_POWER) {
> > + switch (wValue) {
> > + case USB_PORT_FEAT_POWER:
> > dev_dbg(hcd->self.controller, "SetPortFeat: POWER\n");
> > if (valid_port(wIndex)) {
> > ohci_at91_usb_set_power(pdata, wIndex, 1); @@
> -309,6 +352,11 @@
> > static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
> > wValue,
> > }
> >
> > goto out;
> > +
> > + case USB_PORT_FEAT_SUSPEND:
> > + dev_dbg(hcd->self.controller, "SetPortFeat: SUSPEND\n");
> > + ohci_at91_port_ctrl(ohci_at91->sfr_regmap, wIndex, 1);
> > + break;
> > }
> > break;
> >
> > @@ -342,6 +3
Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac
York Sun writes:
> Two symbols are missing if mpc85xx_edac driver is compiled as module.
>
> Signed-off-by: York Sun
>
> ---
> Change log
> v3: Change subject tag
> v2: no change
>
> arch/powerpc/kernel/pci-common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/kernel/pci-common.c
> b/arch/powerpc/kernel/pci-common.c
> index 0f7a60f..86bc484 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -226,6 +226,7 @@ struct pci_controller* pci_find_hose_for_OF_device(struct
> device_node* node)
> }
> return NULL;
> }
> +EXPORT_SYMBOL(pci_find_hose_for_OF_device);
>
> /*
> * Reads the interrupt pin to determine if interrupt is use by card.
> @@ -1585,6 +1586,7 @@ int early_find_capability(struct pci_controller *hose,
> int bus, int devfn,
> {
> return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
> }
> +EXPORT_SYMBOL(early_find_capability);
Does the driver really need to use these routines? They're meant for use
early in boot, before PCI is setup.
AFAICS this is just a regular driver, so when it's probed the PCI
devices should have already been scanned. In which case pci_get_device()
could work couldn't it? (I see other edac drivers doing that).
cheers
Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression
On Thu, Jul 28, 2016 at 03:01:36PM +0800, Xin Long wrote:
> On Wed, Jul 27, 2016 at 9:54 AM, kernel test robot
> wrote:
> >
> > FYI, we noticed a -37.2% regression of netperf.Throughput_Mbps due to
> > commit:
> >
> > commit a6c2f792873aff332a4689717c3cd6104f46684c ("sctp: implement prsctp
> > TTL policy")
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> >
> > in testcase: netperf
> > on test machine: 4 threads Ivy Bridge with 8G memory
> > with following parameters:
> >
> > ip: ipv4
> > runtime: 300s
> > nr_threads: 200%
> > cluster: cs-localhost
> > send_size: 10K
> > test: SCTP_STREAM_MANY
> > cpufreq_governor: performance
> >
> >
> >
> > Disclaimer:
> > Results have been estimated based on internal Intel analysis and are
> > provided
> > for informational purposes only. Any difference in system hardware or
> > software
> > design or configuration may affect actual performance.
> >
> It doesn't make much sense to me. the codes I added cannot be
> triggered without enable any pr policies. and I also did the tests in
It seems these pr policies has to be turned on by user space, i.e.
netperf in this case?
I checked netperf's source code, it doesn't seem set any option
related to SCTP PR POLICY but I'm new to network code so I could be
wrong or missing something.
> my local environment, the result looks normal to me compare to
> prior version.
Can you share your number?
We run netperf like this:
netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H 127.0.0.1
The full log of the run is attached for your reference.
>
> Recently the sctp performance is not stable, as during these patches,
> netperf cannot get the result, but return ENOTCONN. which may
> also affect the testing. anyway we've fixed the -ENOTCONN issue
> already in the latest version.
I tested commit 96b585267f55, which is Linus' git tree HEAD on 08/03, I
guess the fix you mentioned should already be in there? But
unfortunately, the throughput of netperf is still at low number(we did
the test 5 times):
$ cat */netperf.json
{
"netperf.Throughput_Mbps": [
2470.69748
]
}{
"netperf.Throughput_Mbps": [
2486.7675
]
}{
"netperf.Throughput_Mbps": [
2478.945
]
}{
"netperf.Throughput_Mbps": [
2429.465
]
}{
"netperf.Throughput_Mbps": [
2476.91504
]
Considering what you have said that the patch shouldn't make a
difference, the performance drop is really confusing. Any idea what
could be the cause? Thanks.
Regards,
Aaron
2016-08-04 16:12:43 netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H
127.0.0.1 &
2016-08-04 16:12:43 netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H
127.0.0.1 &
2016-08-04 16:12:43 netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H
127.0.0.1 &
2016-08-04 16:12:43 netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H
127.0.0.1 &
2016-08-04 16:12:43 netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H
127.0.0.1 &
2016-08-04 16:12:43 netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H
127.0.0.1 &
2016-08-04 16:12:43 netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H
127.0.0.1 &
2016-08-04 16:12:43 netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H
127.0.0.1 &
SCTP 1-TO-MANY STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1
() port 0 AF_INET : demo
Recv SendSend Utilization Service Demand
Socket Socket Message Elapsed Send Recv SendRecv
Size SizeSize Time Throughput localremote local remote
bytes bytes bytessecs.10^6bits/s % S % S us/KB us/KB
212992 212992 10240300.00 2373.19 51.1451.147.061 7.061
SCTP 1-TO-MANY STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1
() port 0 AF_INET : demo
Recv SendSend Utilization Service Demand
Socket Socket Message Elapsed Send Recv SendRecv
Size SizeSize Time Throughput localremote local remote
bytes bytes bytessecs.10^6bits/s % S % S us/KB us/KB
212992 212992 10240300.00 2374.59 51.1451.117.057 7.053
SCTP 1-TO-MANY STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1
() port 0 AF_INET : demo
Recv SendSend Utilization Service Demand
Socket Socket Message Elapsed Send Recv SendRecv
Size SizeSize Time Throughput localremote local remote
bytes bytes bytessecs.10^6bits/s % S % S us/KB us/KB
212992 212992 10240300.00 2633.32 51.1451.116.364 6.360
SCTP 1-TO-MANY STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1
() port 0 AF_INET : demo
Recv SendSend Utilization Service Demand
Socket Socket Message Elapsed Se
Re: [PATCH 1/7] k3dma: Fix hisi burst clipping
On Thu, Aug 04, 2016 at 10:36:32AM -0700, John Stultz wrote: > On Thu, Aug 4, 2016 at 6:08 AM, Vinod Koul wrote: > > On Fri, Jul 29, 2016 at 03:40:46PM -0700, John Stultz wrote: > >> On Sun, Jul 24, 2016 at 12:25 AM, Vinod Koul wrote: > >> > On Wed, Jul 20, 2016 at 08:53:03PM -0700, John Stultz wrote: > >> >> From: Andy Green > >> >> > >> >> Max burst len is a 4-bit field, but at the moment it's clipped with > >> >> a 5-bit constant... reduce it to that which can be expressed > >> > > >> > Maybe we should GENMASK() etc to avoid these errors.. > >> > >> Not sure I follow what you're thinking here... can you clarify a bit? > > > > I am assuming the 4bit field was a mistake by orignal author. Using GENMASK, > > BIT etc macro helps you to avoid those as one would look at datasheet and > > say this is specfied as bit 5 thru 9, so let me say GENMASK(5, 0) rather > > than a typo which missed 5th bit. > > > > But ofcourse if the error was due to some other reason then this one doesnt > > help. > > It was more that in taking the cfg->src/dst_maxburst value and setting > it as a value that can be represented in 4 bits for the hardware: > if ((maxburst == 0) || (maxburst > 16)) > val = 16; > else > val = maxburst - 1; > > However, the logic error is trying to set the value to 16 if maxburst > is larger then 16, when 16 is 5 bits, when 15 is the largest value we > can express in 4 bits. > > So I'm not sure how GENMASK() would be particularly useful (I guess > using val = GENMASK(4,0) instead of val = 15?). But I'm not sure that > makes the code any clearer. Looks like this was latter case, so it doesnt seem to help here -- ~Vinod
Re: [PATCH 1/3] dt/bindings: arm-pl330: add description of arm,pl330-periph-burst
On Fri, Aug 05, 2016 at 10:53:20AM +0800, Shawn Lin wrote: > This patch adds the "arm,pl330-periph-burst" for arm-pl330 to > support busrt mode. why should this be DT property. Only reason I can think of if some hw versions support this and some won't. If all are supporting, please enable it everywhere for obvious reasons. -- ~Vinod
[PATCH] proc: make proc entries inherit ownership from parent
There are certain parameters that belong to net namespace and that are
exported in /proc. They should be controllable by the container's owner,
but are currently owned by global root and thus not available.
Let's change proc code to inherit ownership of parent entry, and when
create per-ns "net" proc entry set it up as owned by container's owner.
Signed-off-by: Dmitry Torokhov
---
fs/proc/generic.c | 2 ++
fs/proc/proc_net.c | 13 +
2 files changed, 15 insertions(+)
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index c633476..bca66d8 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -390,6 +390,8 @@ static struct proc_dir_entry *__proc_create(struct
proc_dir_entry **parent,
atomic_set(&ent->count, 1);
spin_lock_init(&ent->pde_unload_lock);
INIT_LIST_HEAD(&ent->pde_openers);
+ proc_set_user(ent, (*parent)->uid, (*parent)->gid);
+
out:
return ent;
}
diff --git a/fs/proc/proc_net.c b/fs/proc/proc_net.c
index c8bbc68..d701738 100644
--- a/fs/proc/proc_net.c
+++ b/fs/proc/proc_net.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -185,6 +186,8 @@ const struct file_operations proc_net_operations = {
static __net_init int proc_net_ns_init(struct net *net)
{
struct proc_dir_entry *netd, *net_statd;
+ kuid_t uid;
+ kgid_t gid;
int err;
err = -ENOMEM;
@@ -199,6 +202,16 @@ static __net_init int proc_net_ns_init(struct net *net)
netd->parent = &proc_root;
memcpy(netd->name, "net", 4);
+ uid = make_kuid(net->user_ns, 0);
+ if (!uid_valid(uid))
+ uid = GLOBAL_ROOT_UID;
+
+ gid = make_kgid(net->user_ns, 0);
+ if (!gid_valid(gid))
+ gid = GLOBAL_ROOT_GID;
+
+ proc_set_user(netd, uid, gid);
+
err = -EEXIST;
net_statd = proc_net_mkdir(net, "stat", netd);
if (!net_statd)
--
2.8.0.rc3.226.g39d4020
--
Dmitry
Re: mm: Initialise per_cpu_nodestats for all online pgdats at boot
On Thu, Aug 04, 2016 at 10:24:04AM +0100, Mel Gorman wrote: > Paul Mackerras and Reza Arbab reported that machines with memoryless nodes > fails when vmstats are refreshed. Paul reported an oops as follows > > [1.713998] Unable to handle kernel paging request for data at address > 0xff7a1 > [1.714164] Faulting instruction address: 0xc0270cd0 > [1.714304] Oops: Kernel access of bad area, sig: 11 [#1] > [1.714414] SMP NR_CPUS=2048 NUMA PowerNV > [1.714530] Modules linked in: > [1.714647] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-kvm+ #118 > [1.714786] task: c00ff0680010 task.stack: c00ff0704000 > [1.714926] NIP: c0270cd0 LR: c0270ce8 CTR: > > [1.715093] REGS: c00ff0707900 TRAP: 0300 Not tainted (4.7.0-kvm+) > [1.715232] MSR: 900102009033 CR: > 846b6824 XER: 2000 > [1.715748] CFAR: c0008768 DAR: 000ff7a1 DSISR: 4200 > SOFTE: 1 > GPR00: c0270d08 c00ff0707b80 c11fb200 > GPR04: 0800 > GPR08: 000ff7a1 c122aae0 > GPR12: c0a1e440 cfb8 c000c188 > GPR16: > GPR20: c0cecad0 > GPR24: c0d035b8 c0d6cd18 c0d6cd18 c01fffa86300 > GPR28: c01fffa96300 c1230034 c122eb18 > [1.717484] NIP [c0270cd0] refresh_zone_stat_thresholds+0x80/0x240 > [1.717568] LR [c0270ce8] refresh_zone_stat_thresholds+0x98/0x240 > [1.717648] Call Trace: > [1.717687] [c00ff0707b80] [c0270d08] > refresh_zone_stat_thresholds+0xb8/0x240 (unreliable) > > Both supplied potential fixes but one potentially misses checks and another > had redundant initialisations. This version initialises per_cpu_nodestats > on a per-pgdat basis instead of on a per-zone basis. > > Reported-by: Paul Mackerras > Reported-by: Reza Arbab > Signed-off-by: Mel Gorman That works, thanks. Tested-by: Paul Mackerras
Re: [lkp] [shmem] 071904e8df: meminfo.AnonHugePages +553.5% increase
On 08/04, Kirill A. Shutemov wrote:
>On Thu, Aug 04, 2016 at 04:54:09PM +0800, kernel test robot wrote:
>>
>> FYI, we noticed meminfo.AnonHugePages +553.5% increase due to commit:
>>
>> commit 071904e8dfed9525f9da86523caf78b6da5f9e7e ("shmem: get_unmapped_area
>> align huge page")
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>
>> in testcase: vm-scalability
>> on test machine: 128 threads 4 Sockets Haswell-EP with 512G memory
>> with following parameters:
>>
>> path_params: 300s-16G-shm-pread-rand-mt-performance
>> run:
>>
>>
>>
>> Disclaimer:
>> Results have been estimated based on internal Intel analysis and are provided
>> for informational purposes only. Any difference in system hardware or
>> software
>> design or configuration may affect actual performance.
>>
>> Details are as below:
>> -->
>>
>>
>> To reproduce:
>>
>> git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>> cd lkp-tests
>> bin/lkp install job.yaml # job file is attached in this email
>> bin/lkp run job.yaml
>>
>> =
>> compiler/cpufreq_governor/kconfig/rootfs/runtime/size/tbox_group/test/testcase:
>>
>> gcc-6/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/300s/16G/lkp-hsw-4ep1/shm-pread-rand-mt/vm-scalability
>>
>> commit:
>> 6a028aa3ca ("shmem: prepare huge= mount option and sysfs knob")
>> 071904e8df ("shmem: get_unmapped_area align huge page")
>>
>> 6a028aa3ca32379e 071904e8dfed9525f9da86523c
>> --
>> %stddev %change %stddev
>> \ |\
>> 20428 ± 9%+553.5% 133500 ± 7% meminfo.AnonHugePages
>> 42717 ± 4%+261.3% 154340 ± 6% meminfo.AnonPages
>
>Hm. That's strange. I didn't expect this commit change anything for anon
>memory.
>
>Do you see the same effect from the commit in Linus' tree?
Yes, here the comparison between the commit in Linus' tree (c01d5b3007)
and its parent (5a6e75f811 "shmem: prepare huge= mount option and sysfs
knob")
=
compiler/cpufreq_governor/kconfig/rootfs/runtime/size/tbox_group/test/testcase:
gcc-6/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/300s/16G/lkp-hsw-4ep1/shm-pread-rand-mt/vm-scalability
commit:
5a6e75f8110c97e2a5488894d4e922187e6cb343
c01d5b300774d130a24d787825b01eb24e6e20cb
5a6e75f8110c97e2 c01d5b300774d130a24d787825
--
fail:runs %reproductionfail:runs
| | |
%stddev %change %stddev
\ |\
533.92 ± 5% +7.8% 575.31 ± 4% vm-scalability.time.elapsed_time
533.92 ± 5% +7.8% 575.31 ± 4%
vm-scalability.time.elapsed_time.max
1.567e+09 ± 7% +31.0% 2.053e+09 ± 11%
vm-scalability.time.maximum_resident_set_size
7141 ± 5% -7.0% 6638 ± 5%
vm-scalability.time.percent_of_cpu_this_job_got
1708341 ± 29% +48.3%2534068 ± 21%
vm-scalability.time.voluntary_context_switches
5379895 ± 12% +94.3% 10454779 ± 13% meminfo.Active
5351287 ± 12% +94.8% 10425228 ± 13% meminfo.Active(anon)
20673 ± 1%+570.9% 138687 ± 4% meminfo.AnonHugePages
42881 ± 2%+276.2% 161340 ± 4% meminfo.AnonPages
9570950 ± 7% +93.3% 18504763 ± 10% meminfo.Cached
9461500 ± 7% +94.3% 18381777 ± 11% meminfo.Committed_AS
6363833 ± 7% +11.3%7083357 ± 0% meminfo.DirectMap2M
4233226 ± 1% +94.0%8210642 ± 7% meminfo.Inactive
3759914 ± 1%+105.8%7738210 ± 7% meminfo.Inactive(anon)
8500775 ± 8% +72.3% 14648157 ± 12% meminfo.Mapped
546828 ± 2% +11.2% 608309 ± 1% meminfo.SReclaimable
9069484 ± 7% +98.5% 18003233 ± 11% meminfo.Shmem
1.567e+09 ± 7% +31.0% 2.053e+09 ± 11% time.maximum_resident_set_size
1708341 ± 29% +48.3%2534068 ± 21% time.voluntary_context_switches
10225359 ± 7% +87.6% 19185983 ± 10% vmstat.memory.cache
9386 ± 14% +24.7% 11702 ± 10% vmstat.system.cs
4395191 ± 1% +64.1%7210638 ± 16% numa-numastat.node0.local_node
4395191 ± 1% +64.1%7210639 ± 16% numa-numastat.node0.numa_hit
2.33 ± 20% -85.7% 0.33 ±141% numa-numastat.node3.other_node
838804 ± 2% +12.2% 941216 ± 1%
slabinfo.radix_tree_node.active_objs
15101 ± 2% +12.6% 16999 ± 1%
slabinfo.radix_tree_node.active_slabs
845689 ± 2% +12.6% 951997 ± 1% slabinfo.radix_tree_node.num_objs
15101 ± 2% +12.6% 16999 ± 1% slabinfo.radix_tree_node.num_slabs
58.13 ±
Re: [PATCH v3] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder
Hi Hans,
On Thu, 2016-08-04 at 15:00 +0200, Hans Verkuil wrote:
>
> On 08/04/2016 12:08 PM, Tiffany Lin wrote:
> > This patch add g/s_selection support for MT8173 v4l2 encoder
> >
> > Signed-off-by: Tiffany Lin
> > ---
> > v3:
> > - add v4l2_s_selection to check constraint flags
> > - remove visible_height modification in s_fmt_out
>
> Is this selection-related, or is this an unrelated bug fix?
> If it is the latter, then please split it up as a separate patch.
>
> In both cases the commit log should explain a bit more why
> this s_fmt_out change is needed.
>
This is a bug I found when I add g_selection.
It will make visible_height out of coded_height and compliance test will
fail if not include this part of modification.
The original code here is for that user space could get buffer size HW
required by using coded_width * coded_height.
But the original code here adjust visible_height and not returned as
f->fmt.pix_mp.height, it's a bug.
But if it update coded_height here, q_data->coded_height += 32;, it will
fail in s_fmt compliance test that s_fmt(g_fmt) != g_fmt.
So I decided to drop this.
User space should use sizeimage to get buffer size HW required and
coded_width/coded_height just alignment width/height that HW required.
best regards,
Tiffany
> > ---
> > drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 81
> > +---
> > 1 file changed, 71 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > index 3ed3f2d..c4b8e00 100644
> > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > @@ -487,7 +487,6 @@ static int vidioc_venc_s_fmt_out(struct file *file,
> > void *priv,
> > struct mtk_q_data *q_data;
> > int ret, i;
> > struct mtk_video_fmt *fmt;
> > - unsigned int pitch_w_div16;
> > struct v4l2_pix_format_mplane *pix_fmt_mp = &f->fmt.pix_mp;
> >
> > vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
> > @@ -530,15 +529,6 @@ static int vidioc_venc_s_fmt_out(struct file *file,
> > void *priv,
> > q_data->coded_width = f->fmt.pix_mp.width;
> > q_data->coded_height = f->fmt.pix_mp.height;
> >
> > - pitch_w_div16 = DIV_ROUND_UP(q_data->visible_width, 16);
> > - if (pitch_w_div16 % 8 != 0) {
> > - /* Adjust returned width/height, so application could correctly
> > -* allocate hw required memory
> > -*/
> > - q_data->visible_height += 32;
> > - vidioc_try_fmt(f, q_data->fmt);
> > - }
> > -
> > q_data->field = f->fmt.pix_mp.field;
> > ctx->colorspace = f->fmt.pix_mp.colorspace;
> > ctx->ycbcr_enc = f->fmt.pix_mp.ycbcr_enc;
> > @@ -631,6 +621,74 @@ static int vidioc_try_fmt_vid_out_mplane(struct file
> > *file, void *priv,
> > return vidioc_try_fmt(f, fmt);
> > }
> >
> > +static int vidioc_venc_g_selection(struct file *file, void *priv,
> > +struct v4l2_selection *s)
> > +{
> > + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> > + struct mtk_q_data *q_data;
> > +
> > + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)
> > + return -EINVAL;
> > +
> > + q_data = mtk_venc_get_q_data(ctx, s->type);
> > + if (!q_data)
> > + return -EINVAL;
> > +
> > + switch (s->target) {
> > + case V4L2_SEL_TGT_CROP_DEFAULT:
> > + case V4L2_SEL_TGT_CROP_BOUNDS:
> > + s->r.top = 0;
> > + s->r.left = 0;
> > + s->r.width = q_data->coded_width;
> > + s->r.height = q_data->coded_height;
> > + break;
> > + case V4L2_SEL_TGT_CROP:
> > + s->r.top = 0;
> > + s->r.left = 0;
> > + s->r.width = q_data->visible_width;
> > + s->r.height = q_data->visible_height;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int vidioc_venc_s_selection(struct file *file, void *priv,
> > +struct v4l2_selection *s)
> > +{
> > + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> > + struct mtk_q_data *q_data;
> > + struct v4l2_rect r = s->r;
> > + int err;
> > +
> > + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)
> > + return -EINVAL;
> > +
> > + q_data = mtk_venc_get_q_data(ctx, s->type);
> > + if (!q_data)
> > + return -EINVAL;
> > +
> > + switch (s->target) {
> > + case V4L2_SEL_TGT_CROP:
> > + /* Only support crop from (0,0) */
> > + s->r.top = 0;
> > + s->r.left = 0;
> > + r.width = min(r.width, q_data->coded_width);
> > + r.height = min(r.height, q_data->coded_height);
> > + err = v4l2_s_selection(s, &r);
> > + if (err)
> > + return err;
> > + q_data->visible_width = s->r.width;
> > + q_data->visible_height = s->r.height;
> > + brea
[PATCH 3/3] dmaengine: pl330: support transfer unaligned with (burst len * burst size)
Currently pl330 doesn't support transfer which doesn't
align with burst len * burst size. This should be only
for single mode. Let's allow it for busrt mode if available.
e.g. transfers 0x10002 bytes:
First loop 256*16*16=0x1, burst size is 1, burst length is 16.
Then the second loop 2 bytes, burst size is 1, burst length is 1.
f0041000:DMAMOV CCR 0xbc02f1
f0041006:DMAMOV SAR 0xdd6c
f004100c:DMAMOV DAR 0xff1d0400
f0041012:DMALP_0 15
f0041014:DMALP_1 255
f0041016:DMAWFPB 12
f0041018:DMALDA
f0041019:DMASTPB 12
f004101b:DMAFLUSHP 12
f004101d:DMALPENDA_1 bjmpto_7
f004101f:DMALPENDA_0 bjmpto_b
f0041021:DMAMOV CCR 0x800201
f0041027:DMALP_1 1
f0041029:DMAWFPB 12
f004102b:DMALDA
f004102c:DMASTPB 12
f004102e:DMAFLUSHP 12
f0041030:DMALPENDA_1 bjmpto_7
f0041032:DMASEV 0
f0041034:DMAEND
Signed-off-by: Shawn Lin
---
drivers/dma/pl330.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a09bf22..cdb4afc 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -240,6 +240,7 @@ enum pl330_byteswap {
#define BYTE_TO_BURST(b, ccr) ((b) / BRST_SIZE(ccr) / BRST_LEN(ccr))
#define BURST_TO_BYTE(c, ccr) ((c) * BRST_SIZE(ccr) * BRST_LEN(ccr))
+#define BYTE_MOD_BURST_LEN(b, ccr) (((b) / BRST_SIZE(ccr)) % BRST_LEN(ccr))
/*
* With 256 bytes, we can do more than 2.5MB and 5MB xfers per req
@@ -1331,6 +1332,19 @@ static inline int _setup_xfer(struct pl330_dmac *pl330,
/* Setup Loop(s) */
off += _setup_loops(pl330, dry_run, &buf[off], pxs);
+ if (pl330->peripherals_req_type == BURST) {
+ unsigned int ccr = pxs->ccr;
+ unsigned long c = 0;
+
+ c = BYTE_MOD_BURST_LEN(x->bytes, pxs->ccr);
+ if (c) {
+ ccr &= ~(0xf << CC_SRCBRSTLEN_SHFT);
+ ccr &= ~(0xf << CC_DSTBRSTLEN_SHFT);
+ off += _emit_MOV(dry_run, &buf[off], CCR, ccr);
+ off += _loop(pl330, dry_run, &buf[off], &c, pxs);
+ }
+ }
+
return off;
}
@@ -1353,9 +1367,12 @@ static int _setup_req(struct pl330_dmac *pl330, unsigned
dry_run,
off += _emit_MOV(dry_run, &buf[off], CCR, pxs->ccr);
x = &pxs->desc->px;
- /* Error if xfer length is not aligned at burst size */
- if (x->bytes % (BRST_SIZE(pxs->ccr) * BRST_LEN(pxs->ccr)))
- return -EINVAL;
+
+ if (pl330->peripherals_req_type != BURST) {
+ /* Error if xfer length is not aligned at burst size */
+ if (x->bytes % (BRST_SIZE(pxs->ccr) * BRST_LEN(pxs->ccr)))
+ return -EINVAL;
+ }
off += _setup_xfer(pl330, dry_run, &buf[off], pxs);
--
2.3.7
[PATCH 2/3] dmaengine: pl330: enable burst mode by parsing dt
Currently pl330 use single mode defaultly. But burst
mode can improve efficiency of memory accessing. We
couldn't enable it by defalut in case of breaking any
Socs which don't support it.
With burst mode supported, we could see the improvement
significantly when tesing SPI transfer etc.
default single mode
[ 88.292550] spi write 65536*1 cost 32402us speed:2022KB/S
After applied with burst mode(len 16)
[ 17.625296] spi write 65536*1 cost 17830us speed:3675KB/S
Cc: Huibin Hong
Cc: Xing Zheng
Signed-off-by: Shawn Lin
---
drivers/dma/pl330.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 4fc3ffb..a09bf22 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -491,6 +491,8 @@ struct pl330_dmac {
/* Peripheral channels connected to this DMAC */
unsigned int num_peripherals;
struct dma_pl330_chan *peripherals; /* keep at end */
+ /* set peripherals request type according to soc config */
+ enum pl330_cond peripherals_req_type;
int quirks;
};
@@ -1156,12 +1158,7 @@ static inline int _ldst_devtomem(struct pl330_dmac
*pl330, unsigned dry_run,
int cyc)
{
int off = 0;
- enum pl330_cond cond;
-
- if (pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP)
- cond = BURST;
- else
- cond = SINGLE;
+ enum pl330_cond cond = pl330->peripherals_req_type;
while (cyc--) {
off += _emit_WFP(dry_run, &buf[off], cond, pxs->desc->peri);
@@ -1181,12 +1178,7 @@ static inline int _ldst_memtodev(struct pl330_dmac
*pl330,
const struct _xfer_spec *pxs, int cyc)
{
int off = 0;
- enum pl330_cond cond;
-
- if (pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP)
- cond = BURST;
- else
- cond = SINGLE;
+ enum pl330_cond cond = pl330->peripherals_req_type;
while (cyc--) {
off += _emit_WFP(dry_run, &buf[off], cond, pxs->desc->peri);
@@ -2597,7 +2589,12 @@ static struct dma_async_tx_descriptor
*pl330_prep_dma_cyclic(
desc->rqtype = direction;
desc->rqcfg.brst_size = pch->burst_sz;
- desc->rqcfg.brst_len = 1;
+
+ if (pl330->peripherals_req_type == BURST)
+ desc->rqcfg.brst_len = pch->burst_len;
+ else
+ desc->rqcfg.brst_len = 1;
+
desc->bytes_requested = period_len;
fill_px(&desc->px, dst, src, period_len);
@@ -2742,7 +2739,12 @@ pl330_prep_slave_sg(struct dma_chan *chan, struct
scatterlist *sgl,
}
desc->rqcfg.brst_size = pch->burst_sz;
- desc->rqcfg.brst_len = 1;
+
+ if (pch->dmac->peripherals_req_type == BURST)
+ desc->rqcfg.brst_len = pch->burst_len;
+ else
+ desc->rqcfg.brst_len = 1;
+
desc->rqtype = direction;
desc->bytes_requested = sg_dma_len(sg);
}
@@ -2836,6 +2838,11 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
pl330->mcbufsz = pdat ? pdat->mcbuf_sz : 0;
+ if (of_find_property(np, "arm,pl330-periph-burst", NULL))
+ pl330->peripherals_req_type = BURST;
+ else
+ pl330->peripherals_req_type = SINGLE;
+
/* get quirk */
for (i = 0; i < ARRAY_SIZE(of_quirks); i++)
if (of_property_read_bool(np, of_quirks[i].quirk))
--
2.3.7
[PATCH 1/3] dt/bindings: arm-pl330: add description of arm,pl330-periph-burst
This patch adds the "arm,pl330-periph-burst" for arm-pl330 to support busrt mode. Signed-off-by: Shawn Lin --- Documentation/devicetree/bindings/dma/arm-pl330.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt b/Documentation/devicetree/bindings/dma/arm-pl330.txt index db7e226..262e97a 100644 --- a/Documentation/devicetree/bindings/dma/arm-pl330.txt +++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt @@ -16,6 +16,7 @@ Optional properties: - dma-channels: contains the total number of DMA channels supported by the DMAC - dma-requests: contains the total number of DMA requests supported by the DMAC - arm,pl330-broken-no-flushp: quirk for avoiding to execute DMAFLUSHP + - arm,pl330-periph-burst: set peripheral dma request type as burst mode Example: -- 2.3.7
[PATCH 0/3] Support burst request by peripherals
Burst request is supported by pl330 but the original code only support single mode as some Socs didn't implement it. So this feature has been missing for a long time. But it's very important for efficiency. This patchset is gonna support it without the probability of breaking old(other) platforms, so the new optional property is introduced. Also when supporting burst request type, we could be able to deal with unaligned case internally. After applying this patchset, we could see significant improvement when doing mem-2-dev/dev-2-mem/mem-2-mem which I mentioned in the commit msg. I would appreciate it if folks could help review and test it.:) Thanks for any feedback. Shawn Lin (3): dt/bindings: arm-pl330: add description of arm,pl330-periph-burst dmaengine: pl330: enable burst mode by parsing dt dmaengine: pl330: support transfer unaligned with (burst len * burst size) .../devicetree/bindings/dma/arm-pl330.txt | 1 + drivers/dma/pl330.c| 58 +++--- 2 files changed, 42 insertions(+), 17 deletions(-) -- 2.3.7
linux-next: manual merge of the jc_docs tree with Linus' tree
Hi Jon,
Today's linux-next merge of the jc_docs tree got a conflict in:
Documentation/DocBook/Makefile
between commit:
43f71d93a0cb ("doc-rst: Remove the media docbook")
from Linus' tree and commit:
bdf107d87eb8 ("DocBook: use DOCBOOKS="" to ignore DocBooks instead of
IGNORE_DOCBOOKS=1")
from the jc_docs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/DocBook/Makefile
index c481df33ef21,fb32ab85ea3a..
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@@ -16,9 -14,19 +14,17 @@@ DOCBOOKS := z8530book.xml device-driver
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
- tracepoint.xml gpu.xml media_api.xml w1.xml \
+ tracepoint.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
+ ifeq ($(DOCBOOKS),)
+
+ # Skip DocBook build if the user explicitly requested no DOCBOOKS.
+ .DEFAULT:
+ @echo " SKIPDocBook $@ target (DOCBOOKS=\"\" specified)."
+
+ else
+
-include Documentation/DocBook/media/Makefile
-
###
# The build process is as follows (targets):
# (xmldocs) [by docproc]
[PATCH v5 3/5] dma-buf/sync_file: add sync_file_get_fence()
From: Gustavo Padovan
Creates a function that given an sync file descriptor returns a
fence containing all fences in the sync_file.
v2: Comments by Daniel Vetter
- Adapt to new version of fence_collection_init()
- Hold a reference for the fence we return
v3:
- Adapt to use fput() directly
- rename to sync_file_get_fence() as we always return one fence
v4: Adapt to use fence_array
v5: set fence through fence_get()
Signed-off-by: Gustavo Padovan
Reviewed-by: Chris Wilson
Acked-by: Christian König
---
drivers/dma-buf/sync_file.c | 23 +++
include/linux/sync_file.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index ac9c250..2873760 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -116,6 +116,29 @@ err:
return NULL;
}
+/**
+ * sync_file_get_fence - get the fence related to the sync_file fd
+ * @fd:sync_file fd to get the fence from
+ *
+ * Ensures @fd references a valid sync_file and returns a fence that
+ * represents all fence in the sync_file. On error NULL is returned.
+ */
+struct fence *sync_file_get_fence(int fd)
+{
+ struct sync_file *sync_file;
+ struct fence *fence;
+
+ sync_file = sync_file_fdget(fd);
+ if (!sync_file)
+ return NULL;
+
+ fence = fence_get(sync_file->fence);
+ fput(sync_file->file);
+
+ return fence;
+}
+EXPORT_SYMBOL(sync_file_get_fence);
+
static int sync_file_set_fence(struct sync_file *sync_file,
struct fence **fences, int num_fences)
{
diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index 2efc5ec..f7de5a0 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -46,5 +46,6 @@ struct sync_file {
};
struct sync_file *sync_file_create(struct fence *fence);
+struct fence *sync_file_get_fence(int fd);
#endif /* _LINUX_SYNC_H */
--
2.5.5
Re: The timer softirq on the RT kernel
On Thu, 2016-08-04 at 17:36 -0700, yunhong jiang wrote: > Hi,Mike & Steven > On https://lkml.org/lkml/2015/3/24/1178, the patch of "timers: > do not raise softirq unconditionally" is reverted. Thanks for > Steven's > detailed comments, it's quite clear explained. > I remember Mike has a patch trying to fix it but late > abandoned. Do you still have any plan to work on this? Otherwise, I > will have a try. Sebastian converted the lock to raw in -rt, so nohz_full now works without any extra hackery. -Mike
Re: [PATCH] arm64: Add workaround for Cavium erratum 26026
Hi Robert,
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.7 next-20160804]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Robert-Richter/arm64-Add-workaround-for-Cavium-erratum-26026/20160805-083523
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
for-next/core
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> arch/arm64/kernel/cpu_errata.c:99:17: error: 'ARM64_HAS_NO_BCAST_TLBI'
>> undeclared here (not in a function)
.capability = ARM64_HAS_NO_BCAST_TLBI,
^
vim +/ARM64_HAS_NO_BCAST_TLBI +99 arch/arm64/kernel/cpu_errata.c
93 },
94 #endif
95 #ifdef CONFIG_CAVIUM_ERRATUM_26026
96 {
97 /* Cavium ThunderX, pass 1.x */
98 .desc = "Cavium erratum 26026",
> 99 .capability = ARM64_HAS_NO_BCAST_TLBI,
100 MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
101 },
102 #endif
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH] mm/vmalloc: fix align value calculation error
On 08/05/2016 05:24 AM, Andrew Morton wrote:
>>
>> it causes double align requirement for __get_vm_area_node() if parameter
>> size is power of 2 and VM_IOREMAP is set in parameter flags
>>
>> it is fixed by handling the specail case manually due to lack of
>> get_count_order() for long parameter
>>
>> ...
>>
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -1357,11 +1357,16 @@ static struct vm_struct *__get_vm_area_node(unsigned
>> long size,
>> {
>> struct vmap_area *va;
>> struct vm_struct *area;
>> +int ioremap_size_order;
>>
>> BUG_ON(in_interrupt());
>> -if (flags & VM_IOREMAP)
>> -align = 1ul << clamp_t(int, fls_long(size),
>> - PAGE_SHIFT, IOREMAP_MAX_ORDER);
>> +if (flags & VM_IOREMAP) {
>> +ioremap_size_order = fls_long(size);
>> +if (is_power_of_2(size) && size != 1)
>> +ioremap_size_order--;
>> +align = 1ul << clamp_t(int, ioremap_size_order, PAGE_SHIFT,
>> +IOREMAP_MAX_ORDER);
>> +}
>>
>> size = PAGE_ALIGN(size);
>> if (unlikely(!size))
>
> I'm having trouble with this, and a more complete description would
> have helped!
>
> As far as I can tell, the current code will decide the following:
>
> size=0x1: alignment=0x1
> size=0x0f000: alignment=0x8000
>
no, the current code doesn't achieve the above results as shown below
size=0x1 -> fls_long(0x1)=17 -> alignment=0x2
size=0x0f000 -> fls_long(0x0f000)=16 -> alignment=0x1
it is wrong for power of 2 value such as size=0x1
> And your patch will change it so that
>
> size=0x1: alignment=0x8000
> size=0x0f000: alignment=0x8000
>
> Correct?
>
no, my patch will results in the following calculations
size=0x1: alignment=0x1
size=0x0f000: alignment=0x1
> If so, I'm struggling to see the sense in this. Shouldn't we be
> changing things so that
>
> size=0x1: alignment=0x1
> size=0x0f000: alignment=0x1
>
> ?
okay, it is the aim of my patch as explained above
>
>
Re: [PATCH v3 7/7] clk: rockchip: rk3399: Add support frac mode frequencies
Hi Heiko, On 2016年08月05日 03:19, Heiko Stübner wrote: Hi Xing, Am Dienstag, 2. August 2016, 15:22:59 schrieb Xing Zheng: We need to support various display resolutions for external display devices like HDMI/DP, the frac mode can help us to acquire almost any frequencies, and need higher VCOs to reduce clock jitters. Signed-off-by: Xing Zheng why does this need to be a separate rate array and cannot live in the general pll rate array? The plls are general purpose, so we shouldn't limit them arbitarily. Yes, I understand your mean. :-) I currently only see some frequencies (594MHz, 297MHz, 54MHz) that are present in both arrays but have different settings. As your patch description says that these settings reduce clock jitter, wouldn't the general frequencies also profit from merging these new values into the general rate array? and here are some of our ideas: "WIth the frac mode and higher VCO to reduce clock jitters" that suggestion is from IC designer. There are many and various kinds resolution and needed frequencies for external disaplay devices. For example, the DP needs: 3840x2160 533250KHz 3840x2160 297000KHz 3840x2160 296703KHz 2560x1440 241500KHz 1920x1080 148500KHz 1920x1080 148352KHz 1680x1050 146250KHz 1600x900 108000KHz 1280x1024 135000KHz 1280x1024 108000KHz ... and so on There some frequencies must be allocated with frac mode. We separate these frequencies that are only used for display (VPLL) from the general rate table, and put them to be classified into a frac mode table, we can reduce the frequency of the query time, the two rate tables will not interfere with each other. Because other PLLs don't need to assgin these various frequencies with frac mode. Thanks -- - Xing Zheng
[PATCH v5 4/5] Documentation: add doc for sync_file_get_fence()
From: Gustavo Padovan Document the new function added to sync_file.c v2: Adapt to fence_array Signed-off-by: Gustavo Padovan Acked-by: Christian König --- Documentation/sync_file.txt | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/sync_file.txt b/Documentation/sync_file.txt index e8e2eba..ae2dbad1 100644 --- a/Documentation/sync_file.txt +++ b/Documentation/sync_file.txt @@ -64,6 +64,21 @@ The sync_file fd now can be sent to userspace. If the creation process fail, or the sync_file needs to be released by any other reason fput(sync_file->file) should be used. +Receiving Sync Files from Userspace +--- + +When userspace needs to send an in-fence to the driver it pass file descriptor +of the Sync File to the kernel. The kernel then can retrieve the fences +from it. + +Interface: + struct fence *sync_file_get_fence(int fd); + + +The function return a struct fence pointer referencing the fence(s) in the Sync +File. + + References: [1] struct sync_file in include/linux/sync_file.h [2] All interfaces mentioned above defined in include/linux/sync_file.h -- 2.5.5
[PATCH v5 1/5] dma-buf/fence-array: add fence_is_array()
From: Gustavo Padovan
Add helper to check if fence is array.
v2: Comments from Chris Wilson
- remove ternary if from ops comparison
- add EXPORT_SYMBOL(fence_array_ops)
Cc: Chris Wilson
Cc: Christian König
Signed-off-by: Gustavo Padovan
Reviewed-by: Chris Wilson
Reviewed-by: Christian König
---
drivers/dma-buf/fence-array.c | 1 +
include/linux/fence-array.h | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/dma-buf/fence-array.c b/drivers/dma-buf/fence-array.c
index a8731c8..ee50022 100644
--- a/drivers/dma-buf/fence-array.c
+++ b/drivers/dma-buf/fence-array.c
@@ -99,6 +99,7 @@ const struct fence_ops fence_array_ops = {
.wait = fence_default_wait,
.release = fence_array_release,
};
+EXPORT_SYMBOL(fence_array_ops);
/**
* fence_array_create - Create a custom fence array
diff --git a/include/linux/fence-array.h b/include/linux/fence-array.h
index 86baaa4..a44794e 100644
--- a/include/linux/fence-array.h
+++ b/include/linux/fence-array.h
@@ -52,6 +52,16 @@ struct fence_array {
extern const struct fence_ops fence_array_ops;
/**
+ * fence_is_array - check if a fence is from the array subsclass
+ *
+ * Return true if it is a fence_array and false otherwise.
+ */
+static inline bool fence_is_array(struct fence *fence)
+{
+ return fence->ops == &fence_array_ops;
+}
+
+/**
* to_fence_array - cast a fence to a fence_array
* @fence: fence to cast to a fence_array
*
--
2.5.5
[PATCH v5 2/5] dma-buf/sync_file: refactor fence storage in struct sync_file
From: Gustavo Padovan
Create sync_file->fence to abstract the type of fence we are using for
each sync_file. If only one fence is present we use a normal struct fence
but if there is more fences to be added to the sync_file a fence_array
is created.
This change cleans up sync_file a bit. We don't need to have sync_file_cb
array anymore. Instead, as we always have one fence, only one fence
callback is registered per sync_file.
v6: fix case where all fences are signaled.
v5: fixes checkpatch warnings
v4: Comments from Chris Wilson
- use sizeof(*fence) to reallocate array
- fix typo in comments
- protect num_fences sum against overflows
- use array->base instead of casting the to struct fence
v3: Comments from Chris Wilson and Christian König
- struct sync_file lost status member in favor of fence_is_signaled()
- drop use of fence_array_teardown()
- use sizeof(*fence) to allocate only an array on fence pointers
v2: Comments from Chris Wilson and Christian König
- Not using fence_ops anymore
- fence_is_array() was created to differentiate fence from fence_array
- fence_array_teardown() is now exported and used under fence_is_array()
- struct sync_file lost num_fences member
Cc: Chris Wilson
Cc: Christian König
Signed-off-by: Gustavo Padovan
Reviewed-by: Chris Wilson
Acked-by: Christian König
Acked-by: Greg Kroah-Hartman
---
drivers/dma-buf/sync_file.c | 174 +++
drivers/staging/android/sync_debug.c | 12 ++-
include/linux/sync_file.h| 17 +---
3 files changed, 129 insertions(+), 74 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 9aaa608..ac9c250 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -28,11 +28,11 @@
static const struct file_operations sync_file_fops;
-static struct sync_file *sync_file_alloc(int size)
+static struct sync_file *sync_file_alloc(void)
{
struct sync_file *sync_file;
- sync_file = kzalloc(size, GFP_KERNEL);
+ sync_file = kzalloc(sizeof(*sync_file), GFP_KERNEL);
if (!sync_file)
return NULL;
@@ -45,6 +45,8 @@ static struct sync_file *sync_file_alloc(int size)
init_waitqueue_head(&sync_file->wq);
+ INIT_LIST_HEAD(&sync_file->cb.node);
+
return sync_file;
err:
@@ -54,14 +56,11 @@ err:
static void fence_check_cb_func(struct fence *f, struct fence_cb *cb)
{
- struct sync_file_cb *check;
struct sync_file *sync_file;
- check = container_of(cb, struct sync_file_cb, cb);
- sync_file = check->sync_file;
+ sync_file = container_of(cb, struct sync_file, cb);
- if (atomic_dec_and_test(&sync_file->status))
- wake_up_all(&sync_file->wq);
+ wake_up_all(&sync_file->wq);
}
/**
@@ -76,22 +75,18 @@ struct sync_file *sync_file_create(struct fence *fence)
{
struct sync_file *sync_file;
- sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]));
+ sync_file = sync_file_alloc();
if (!sync_file)
return NULL;
- sync_file->num_fences = 1;
- atomic_set(&sync_file->status, 1);
+ sync_file->fence = fence;
+
snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
fence->ops->get_driver_name(fence),
fence->ops->get_timeline_name(fence), fence->context,
fence->seqno);
- sync_file->cbs[0].fence = fence;
- sync_file->cbs[0].sync_file = sync_file;
- if (fence_add_callback(fence, &sync_file->cbs[0].cb,
- fence_check_cb_func))
- atomic_dec(&sync_file->status);
+ fence_add_callback(fence, &sync_file->cb, fence_check_cb_func);
return sync_file;
}
@@ -121,14 +116,49 @@ err:
return NULL;
}
-static void sync_file_add_pt(struct sync_file *sync_file, int *i,
-struct fence *fence)
+static int sync_file_set_fence(struct sync_file *sync_file,
+ struct fence **fences, int num_fences)
{
- sync_file->cbs[*i].fence = fence;
- sync_file->cbs[*i].sync_file = sync_file;
+ struct fence_array *array;
+
+ /*
+* The reference for the fences in the new sync_file and held
+* in add_fence() during the merge procedure, so for num_fences == 1
+* we already own a new reference to the fence. For num_fence > 1
+* we own the reference of the fence_array creation.
+*/
+ if (num_fences == 1) {
+ sync_file->fence = fences[0];
+ } else {
+ array = fence_array_create(num_fences, fences,
+ fence_context_alloc(1), 1, false);
+ if (!array)
+ return -ENOMEM;
+
+ sync_file->fence = &array->base;
+ }
-
[PATCH v5 5/5] dma-buf/sync_file: only enable fence signalling on poll()
From: Gustavo Padovan
Signalling doesn't need to be enabled at sync_file creation, it is only
required if userspace waiting the fence to signal through poll().
Thus we delay fence_add_callback() until poll is called. It only adds the
callback the first time poll() is called. This avoid re-adding the same
callback multiple times.
v2: rebase and update to work with new fence support for sync_file
v3: use atomic operation to set enabled and protect fence_add_callback()
v4: use user bit from fence flags (comment from Chris Wilson)
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/sync_file.c | 22 +-
include/linux/sync_file.h | 2 ++
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 2873760..ec61c50 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -86,8 +86,6 @@ struct sync_file *sync_file_create(struct fence *fence)
fence->ops->get_timeline_name(fence), fence->context,
fence->seqno);
- fence_add_callback(fence, &sync_file->cb, fence_check_cb_func);
-
return sync_file;
}
EXPORT_SYMBOL(sync_file_create);
@@ -274,9 +272,6 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
goto err;
}
- fence_add_callback(sync_file->fence, &sync_file->cb,
- fence_check_cb_func);
-
strlcpy(sync_file->name, name, sizeof(sync_file->name));
return sync_file;
@@ -291,7 +286,8 @@ static void sync_file_free(struct kref *kref)
struct sync_file *sync_file = container_of(kref, struct sync_file,
kref);
- fence_remove_callback(sync_file->fence, &sync_file->cb);
+ if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
+ fence_remove_callback(sync_file->fence, &sync_file->cb);
fence_put(sync_file->fence);
kfree(sync_file);
}
@@ -311,13 +307,21 @@ static unsigned int sync_file_poll(struct file *file,
poll_table *wait)
poll_wait(file, &sync_file->wq, wait);
+ if (!test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
+ if (fence_add_callback(sync_file->fence, &sync_file->cb,
+ fence_check_cb_func) < 0)
+ wake_up_all(&sync_file->wq);
+ }
+
status = fence_is_signaled(sync_file->fence);
- if (status)
- return POLLIN;
+ if (!status)
+ return 0;
+
if (status < 0)
return POLLERR;
- return 0;
+
+ return POLLIN;
}
static long sync_file_ioctl_merge(struct sync_file *sync_file,
diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index f7de5a0..aa17ccf 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -45,6 +45,8 @@ struct sync_file {
struct fence_cb cb;
};
+#define POLL_ENABLED FENCE_FLAG_USER_BITS
+
struct sync_file *sync_file_create(struct fence *fence);
struct fence *sync_file_get_fence(int fd);
--
2.5.5
Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling
On Thu, Aug 04, 2016 at 04:28:53PM +0200, Peter Zijlstra wrote: > On Wed, Aug 03, 2016 at 11:57:05AM -0700, Brendan Gregg wrote: > > > As for pmu tracepoints: if I were to instrument it (although I wasn't > > planning to), I'd put a tracepoint in perf_event_overflow() called > > "perf:perf_overflow", with the same arguments. That could then be used > > for all PMU overflow events, without needing to add specific > > tracepoints. > > Could we not teach BPF to replace event->overflow_handler and inject > itself there? > > We don't currently have nice interfaces for doing that, but it should be > possible to do I think. We already have the indirect function call, so > injecting ourself there has 0 overhead. you're right. All makes sense. I guess I was too lazy to look into how to do it properly. Adding a tracepoint looked like quick and easy way to achieve the same. As far as api goes probably existing IOC_SET_BPF ioctl will do too. Currently overflow_handler is set at event alloc time. If we start changing it on the fly with atomic xchg(), afaik things shouldn't break, since each overflow_handler is run to completion and doesn't change global state, right?
Re: [PATCH] mpt3sas: Ensure the connector_name string is NUL-terminated
> "Calvin" == Calvin Owens writes: Calvin> We blindly trust the hardware to give us NUL-terminated strings, Calvin> which is a bad idea because it doesn't always do that. For Calvin> example: Broadcom folks, please respond to this and other mpt3sas patches in the queue: https://patchwork.kernel.org/project/linux-scsi/list/?q=mpt3sas -- Martin K. Petersen Oracle Linux Engineering
Re: [RFC V2 PATCH 00/25] Kernel NET policy
On Wed, Dec 31, 2014 at 08:38:49PM -0500, kan.li...@intel.com wrote: > > Changes since V1: > - Using work queue to set Rx network flow classification rules and search >available NET policy object asynchronously. > - Using RCU lock to replace read-write lock > - Redo performance test and update performance results. > - Some minor modification for codes and documents. > - Remove i40e related patches which will be submitted in separate thread. Most of the issues brought up in the prior submission were not addressed, so one more NACK from me as well. My objection with this approach is the same as others: such policy doesn't belong in the kernel. > 1. Why userspace tool cannot do the same thing? > A: Kernel is more suitable for NET policy. >- User space code would be far more complicated to get right and > perform > well . It always need to work with out of date state compared to the > latest, because it cannot do any locking with the kernel state. >- User space code is less efficient than kernel code, because of the > additional context switches needed. >- Kernel is in the right position to coordinate requests from multiple > users. and above excuses is the reason to hack flow director rules in the kernel? You can do the same in user space. It's not a kernel job.
RE: acpi: broken suspend to RAM with v4.7-rc1
Hi, Andrey > From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com] > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 > > On 24 Jun, Zheng, Lv wrote: > > Hi, > > > > > From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com] > > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 > > > > > > Hi Lv, > > > > > > On 13 Jun, Zheng, Lv wrote: > > > > > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > > > > > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > > > > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 > > > > > > > > > > On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov wrote: > > > > > > On 10 Jun, Rafael J. Wysocki wrote: > > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken > suspend > > > to RAM. > > > > > > > > Laptop doesn't finish suspend to RAM process (disks are off, > but > > > > > > > > WiFi and Power LEDs are still on). The only way to get it out of > > > > > > > > this state, is to turn the power off. > > > > > > > > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset > > > support > > > > > > > > for acpi_hw_write()]. > > > > > > > > > > > > > > > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to > RAM > > > > > > > > is working again. > > > > > > > > > > > > > > > > The cause of this problem is that after this commit write to > > > PM1A > > > > > > > > Control Block (16-bit register) is done using two 8-bit writes. > > > > > > > > If I force this write to be 16-bit, then all is working as > > > > > > > > before. > > > > > > > > > > > > > > > > To get it working 'access_width' for PM1A Control Block > needs to > > > > > > > > be 2 (16-bit), but it's 1 (8-bit). > > > > [Lv Zheng] > > > > Could you send me the acpidump of the machine? > > > Here it is > > > > https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid > > > ump.bin > > [Lv Zheng] > > I've been trying to download it these days but all failed. > > Could you send an off-list email to me with this attached? > Strange. I've check now. The link above is working, but I see that > part of the link above is moved to the next line. > Anyway I resend you all files off-list. > > > > > > > > > > The root of the problem seems to be not the commit > > > > > 66b1ed5aa8dd25 > > > > > > > > itself, but the ACPI tables in BIOS where wrong access_width > > > > > > > > comes from. I fixed problem in FACP table, put it in initrd to > > > > > > > > override FACP table from BIOS. This fixed the issue, suspend > to > > > > > > > > RAM is working now again. > > > > > > > > > > > > > > > > But I'm not sure whether is this proper fix for this problem. > > > > > > > > Is there any place in the kernel, where such ACPI quirks are > placed? > > > > [Lv Zheng] > > > > My question would be: > > > > Does Windows behave correctly for this table? > > > Yes, suspend to RAM is working under Windows Vista. > > > IIRC it worked under Windows XP too. > > > > > > > However there is a real case showing that there are real tables need > us to > > > correctly support BitWidth/BitOffset. > > > > Here is the information for you to refer: > > > > > http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870 > > > > > > > > > > > > > > > > > > Well, if the commit in question caused a problem to happen for > > > you, > > > > > > > it also might cause similar problems to happen elsewhere. > > > > > > > > > > > > > > It looks like we'll need to revert that commit. > > > > > > Hi, > > > > > > > > > > > > or maybe to reset access_width AnyAcc from FACP table only for > > > PM1A > > > > > > control register or even for all registers? This will fix the issue > > > > > > too. > > > > > > > > > > That's a good idea actually. > > > > > > > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c > > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > > > > > > --- a/drivers/acpi/acpica/tbfadt.c > > > > > > +++ b/drivers/acpi/acpica/tbfadt.c > > > > > > @@ -714,7 +714,14 @@ static void > > > acpi_tb_setup_fadt_registers(void) > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > + /* > > > > > > +* Reset access_width in the GAS for PM1A control register > to > > > > > > +* undefined value. Because in some cases this field > > > > > > contains > > > > > > +* wrong value. > > > > > > +*/ > > > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > > > > > > > > > OK, let's see what Bob and Lv think about that. > > > > [Lv Zheng] > > > > There is a commit in 4.7-rc2: > > > > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id= > > > 7f9bef9d > > > > Have you tried if the problem still exists in 4.7-rc2? > > > I've just tried v4.7-rc3. It c
Re: [PATCH v4 0/3] dma-mapping, powerpc, nvme: introduce the DMA_ATTR_NO_WARN attribute
On Thu, 4 Aug 2016 21:17:27 -0300 Mauricio Faria de Oliveira wrote: > > [snip] An alternative (and more idiomatic) fix would be to > > change the blk_rq_map_sg() interface to permit passing down some > > foo_NOWARN flag and propagating that down the stack into > > ppc_iommu_map_sg(). Was this approach evaluated? I suspect it might > > be messy. > > I see; I haven't evaluated that, but agree with you it might be messy. > > As far as I can see, in order to pass something to blk_rq_map_sg() and > have it eventually make into ppc_iommu_map_sg(), that something should > be present in the scatterlist -- which seems to be what's common/passed > to both blk_rq_map_sg() (the interface point proposed) and dma_map_sg() > (which is the function which reaches ppc_iommu_map_sg() down the chain). > > It seems a bit hidden, and (if I got the suggestion right), it doesn't > seem to be in the scope of scatterlist to contain such a flag. > > One point of the patches is make the attribute visible/explicit; I see > it can be inconvenient sometimes, but it allows for a clear / evident > difference between dma_map_sg() calls which are (not) OK with failures. > > (for example, the 2 calls in nvme_map_data() - they can return either > BLK_MQ_RQ_QUEUE_BUSY or BLK_MQ_RQ_QUEUE_ERROR - so the former is OK.) Of course, the alternative is to just delete the damn warnings from ppc_iommu_map_sg(). Imagine that! Have they ever been of any use to anyone?
linux-next: manual merge of the rdma tree with Linus' tree
Hi Doug,
Today's linux-next merge of the rdma tree got a conflict in:
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
between commit:
8ae7b8a59938 ("net: hns: fix sbm default parameters config error")
from Linus' tree and commit:
c80815c0b214 ("net: hns: Add reset function support for RoCE driver")
from the rdma tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 235f7b1d,750ab4b4d154..
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@@ -796,18 -800,10 +805,22 @@@
#define DSAFV2_SBM_CFG4_RESET_BUF_NUM_NO_PFC_S 9
#define DSAFV2_SBM_CFG4_RESET_BUF_NUM_NO_PFC_M (((1ULL << 9) - 1) << 9)
+#define DSAFV2_SBM_CFG2_ROCEE_SET_BUF_NUM_S 0
+#define DSAFV2_SBM_CFG2_ROCEE_SET_BUF_NUM_M (((1ULL << 8) - 1) << 0)
+#define DSAFV2_SBM_CFG2_ROCEE_RESET_BUF_NUM_S 8
+#define DSAFV2_SBM_CFG2_ROCEE_RESET_BUF_NUM_M (((1ULL << 8) - 1) << 8)
+
+#define DSAFV2_SBM_CFG2_PPE_SET_BUF_NUM_S (0)
+#define DSAFV2_SBM_CFG2_PPE_SET_BUF_NUM_M (((1ULL << 6) - 1) << 0)
+#define DSAFV2_SBM_CFG2_PPE_RESET_BUF_NUM_S (6)
+#define DSAFV2_SBM_CFG2_PPE_RESET_BUF_NUM_M (((1ULL << 6) - 1) << 6)
+#define DSAFV2_SBM_CFG2_PPE_CFG_USEFUL_NUM_S (12)
+#define DSAFV2_SBM_CFG2_PPE_CFG_USEFUL_NUM_M (((1ULL << 6) - 1) << 12)
+
+ #define DSAF_CHNS_MASK0x3f000
+ #define DSAF_SBM_ROCEE_CFG_CRD_EN_B 2
+ #define SRST_TIME_INTERVAL20
+
#define DSAF_TBL_TCAM_ADDR_S 0
#define DSAF_TBL_TCAM_ADDR_M ((1ULL << 9) - 1)
linux-next: manual merge of the rdma tree with Linus' tree
Hi Doug,
Today's linux-next merge of the rdma tree got a conflict in:
drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
between commits:
a24274aa5c23 ("net: hns: add dsaf misc operation method")
f00ef863da2b ("net: hns: implement the miscellaneous operation by asl")
from Linus' tree and commit:
c80815c0b214 ("net: hns: Add reset function support for RoCE driver")
from the rdma tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index 611b67b6f450,da3061cf5070..
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@@ -231,16 -165,43 +231,52 @@@ static void hns_dsaf_xge_core_srst_by_p
dsaf_write_sub(dsaf_dev, reg_addr, reg_val);
}
+ /**
+ * hns_dsaf_srst_chns - reset dsaf channels
+ * @dsaf_dev: dsaf device struct pointer
+ * @msk: xbar channels mask value:
+ * bit0-5 for xge0-5
+ * bit6-11 for ppe0-5
+ * bit12-17 for roce0-5
+ * bit18-19 for com/dfx
+ * @enable: false - request reset , true - drop reset
+ */
+ void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool enable)
+ {
+ u32 reg_addr;
+
+ if (!enable)
+ reg_addr = DSAF_SUB_SC_DSAF_RESET_REQ_REG;
+ else
+ reg_addr = DSAF_SUB_SC_DSAF_RESET_DREQ_REG;
+
+ dsaf_write_sub(dsaf_dev, reg_addr, msk);
+ }
+
+ void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool enable)
+ {
+ if (!enable) {
+ dsaf_write_sub(dsaf_dev, DSAF_SUB_SC_ROCEE_RESET_REQ_REG, 1);
+ } else {
+ dsaf_write_sub(dsaf_dev,
+ DSAF_SUB_SC_ROCEE_CLK_DIS_REG, 1);
+ dsaf_write_sub(dsaf_dev,
+ DSAF_SUB_SC_ROCEE_RESET_DREQ_REG, 1);
+ msleep(20);
+ dsaf_write_sub(dsaf_dev, DSAF_SUB_SC_ROCEE_CLK_EN_REG, 1);
+ }
+ }
+
-void hns_dsaf_ge_srst_by_port(struct dsaf_device *dsaf_dev, u32 port, u32 val)
+static void
+hns_dsaf_xge_core_srst_by_port_acpi(struct dsaf_device *dsaf_dev,
+ u32 port, bool dereset)
+{
+ hns_dsaf_acpi_srst_by_port(dsaf_dev, HNS_OP_RESET_FUNC,
+ HNS_XGE_CORE_RESET_FUNC, port, dereset);
+}
+
+static void hns_dsaf_ge_srst_by_port(struct dsaf_device *dsaf_dev, u32 port,
+ bool dereset)
{
u32 reg_val_1;
u32 reg_val_2;
Re: [PATCH 2/3] regulator: qcom_smd: Fix voltage ranges for pma8084 ftsmps and pldo
On 07/11, Andy Gross wrote:
> On Mon, Jul 11, 2016 at 02:50:08PM -0700, Stephen Boyd wrote:
> > The voltage ranges listed here are wrong. The pma8084 pldo
> > supports three different overlapping voltage ranges with
> > differing step sizes and the pma8084 ftsmps supports two. These
> > ranges can be seen in the "native" spmi regulator driver
> > (qcom_spmi-regulator.c) at pldo_ranges[] and ftsmps_ranges[]
> > respectively. Port these ranges over to the RPM SMD regulator
> > driver so that we list the appropriate set of supported voltages
> > on these types of regulators.
> >
> > Cc: Andy Gross
> > Cc: Bjorn Andersson
> > Fixes: ee01d0c91ef1 ("regulator: qcom-smd: Add support for PMA8084")
> > Signed-off-by: Stephen Boyd
>
>
>
> > static const struct regulator_desc pma8084_pldo = {
> > .linear_ranges = (struct regulator_linear_range[]) {
> > - REGULATOR_LINEAR_RANGE(75, 0, 30, 25000),
> > - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> > + REGULATOR_LINEAR_RANGE( 75, 0, 63, 12500),
>
> It was my understanding that the PMOS ldos only support 25mV and 50mV
> incremements.
>
Unfortunately that isn't true. It also supports 12.5mV steps for
the lower voltage ranges.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 1/3] regulator: qcom_smd: Fix voltage ranges for pm8x41
On 07/11, Andy Gross wrote:
> On Mon, Jul 11, 2016 at 02:50:07PM -0700, Stephen Boyd wrote:
>
> > static const struct regulator_desc pm8941_pldo = {
> > .linear_ranges = (struct regulator_linear_range[]) {
> > - REGULATOR_LINEAR_RANGE( 75, 0, 30, 25000),
> > - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> > + REGULATOR_LINEAR_RANGE( 75, 0, 63, 12500),
> > + REGULATOR_LINEAR_RANGE(155, 64, 126, 25000),
> > + REGULATOR_LINEAR_RANGE(310, 127, 163, 5),
> > },
> > - .n_linear_ranges = 2,
> > - .n_voltages = 100,
> > + .n_linear_ranges = 3,
> > + .n_voltages = 164,
> > .ops = &rpm_smps_ldo_ops,
> > };
>
> Still a little confused on if the 12.5mV is allowed on pmos ldo. It seems
> like the
> nmos has 1 range of 5mV steps. The PMOS has 2 ranges, using 25mV and 50mV
>
The values I've put in these patches are the correct ranges.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
linux-next: manual merge of the rdma tree with Linus' tree
Hi Doug,
Today's linux-next merge of the rdma tree got a conflict in:
MAINTAINERS
between commit:
b30d74e42d78 ("MAINTAINERS: add maintainers for hns driver")
from Linus' tree and commit:
dd778a9920a6 ("MAINTAINERS: Add maintainers for Hisilicon RoCE driver")
from the rdma tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc MAINTAINERS
index 5a8cb5bd1f64,9d97badd2e09..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -5548,15 -5421,14 +5548,23 @@@ F: include/uapi/linux/if_hippi.
F:net/802/hippi.c
F:drivers/net/hippi/
+HISILICON NETWORK SUBSYSTEM DRIVER
+M:Yisen Zhuang
+M:Salil Mehta
+L:net...@vger.kernel.org
+W:http://www.hisilicon.com
+S:Maintained
+F:drivers/net/ethernet/hisilicon/
+F:Documentation/devicetree/bindings/net/hisilicon*.txt
+
+ HISILICON ROCE DRIVER
+ M:Lijun Ou
+ M:Wei Hu(Xavier)
+ L:linux-r...@vger.kernel.org
+ S:Maintained
+ F:drivers/infiniband/hw/hns/
+ F:Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
+
HISILICON SAS Controller
M:John Garry
W:http://www.hisilicon.com
[PATCH v4 5/6] extcon: Add the synchronization extcon APIs to support the notification
This patch adds the synchronization extcon APIs to support the notifications
for both state and property. When extcon_*_sync() functions is called,
the extcon informs the information from extcon provider to extcon client.
The extcon driver may need to change the both state and multiple properties
at the same time. After setting the data of a external connector,
the extcon send the notification to client driver with the extcon_*_sync().
The list of new extcon APIs as following:
- extcon_sync() : Send the notification for each external connector to
synchronize the information between extcon provider driver
and extcon client driver.
- extcon_set_state_sync() : Set the state of external connector with noti.
- extcon_set_property_sync() : Set the property of external connector with noti.
For example,
case 1, change the state of external connector and synchronized the data.
extcon_set_state_sync(edev, EXTCON_USB, 1);
case 2, change both the state and property of external connector
and synchronized the data.
extcon_set_state(edev, EXTCON_USB, 1);
extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS 1);
extcon_sync(edev, EXTCON_USB);
case 3, change the property of external connector and synchronized the data.
extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS, 0);
extcon_sync(edev, EXTCON_USB);
case 4, change the property of external connector and synchronized the data.
extcon_set_property_sync(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS, 0);
Signed-off-by: Chanwoo Choi
Tested-by: Chris Zhong
Tested-by: Guenter Roeck
Reviewed-by: Guenter Roeck
---
drivers/extcon/extcon.c | 210 +++-
include/linux/extcon.h | 30 ++-
2 files changed, 164 insertions(+), 76 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index d66adfd21159..8fde4befaa51 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -279,14 +279,11 @@ static bool is_extcon_attached(struct extcon_dev *edev,
unsigned int index)
return !!(edev->state & BIT(index));
}
-static bool is_extcon_changed(u32 prev, u32 new, int idx, bool *attached)
+static bool is_extcon_changed(struct extcon_dev *edev, int index,
+ bool new_state)
{
- if (((prev >> idx) & 0x1) != ((new >> idx) & 0x1)) {
- *attached = ((new >> idx) & 0x1) ? true : false;
- return true;
- }
-
- return false;
+ int state = !!(edev->state & BIT(index));
+ return (state != new_state);
}
static bool is_extcon_property_supported(unsigned int id, unsigned int prop)
@@ -402,21 +399,13 @@ static ssize_t cable_state_show(struct device *dev,
}
/**
- * extcon_update_state() - Update the cable attach states of the extcon device
- *only for the masked bits.
- * @edev: the extcon device
- * @mask: the bit mask to designate updated bits.
- * @state: new cable attach status for @edev
- *
- * Changing the state sends uevent with environment variable containing
- * the name of extcon device (envp[0]) and the state output (envp[1]).
- * Tizen uses this format for extcon device to get events from ports.
- * Android uses this format as well.
+ * extcon_sync() - Synchronize the states for both the attached/detached
+ * @edev: the extcon device that has the cable.
*
- * Note that the notifier provides which bits are changed in the state
- * variable with the val parameter (second) to the callback.
+ * This function send a notification to synchronize the all states of a
+ * specific external connector
*/
-static int extcon_update_state(struct extcon_dev *edev, u32 mask, u32 state)
+int extcon_sync(struct extcon_dev *edev, unsigned int id)
{
char name_buf[120];
char state_buf[120];
@@ -425,73 +414,58 @@ static int extcon_update_state(struct extcon_dev *edev,
u32 mask, u32 state)
int env_offset = 0;
int length;
int index;
+ int state;
unsigned long flags;
- bool attached;
if (!edev)
return -EINVAL;
+ index = find_cable_index_by_id(edev, id);
+ if (index < 0)
+ return index;
+
spin_lock_irqsave(&edev->lock, flags);
- if (edev->state != ((edev->state & ~mask) | (state & mask))) {
- u32 old_state;
+ state = !!(edev->state & BIT(index));
+ raw_notifier_call_chain(&edev->nh[index], state, edev);
- if (check_mutually_exclusive(edev, (edev->state & ~mask) |
- (state & mask))) {
- spin_unlock_irqrestore(&edev->lock, flags);
- return -EPERM;
- }
+ /* This could be in interrupt handler */
+ prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
+ if (!prop_buf) {
+ /
[PATCH v4 2/6] extcon: Add the support for extcon property according to extcon type
This patch support the extcon property for the external connector
because each external connector might have the property according to
the H/W design and the specific characteristics.
- EXTCON_PROP_USB_[property name]
- EXTCON_PROP_CHG_[property name]
- EXTCON_PROP_JACK_[property name]
- EXTCON_PROP_DISP_[property name]
Add the new extcon APIs to get/set the property value as following:
- int extcon_get_property(struct extcon_dev *edev, unsigned int id,
unsigned int prop,
union extcon_property_value *prop_val)
- int extcon_set_property(struct extcon_dev *edev, unsigned int id,
unsigned int prop,
union extcon_property_value prop_val)
Signed-off-by: Chanwoo Choi
Tested-by: Chris Zhong
Tested-by: Guenter Roeck
Reviewed-by: Guenter Roeck
---
drivers/extcon/extcon.c | 201 +++-
include/linux/extcon.h | 81 +++
2 files changed, 281 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index f209a6959fed..37fa4b51c5a1 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -196,6 +196,11 @@ struct extcon_cable {
struct device_attribute attr_state;
struct attribute *attrs[3]; /* to be fed to attr_g.attrs */
+
+ union extcon_property_value usb_propval[EXTCON_PROP_USB_CNT];
+ union extcon_property_value chg_propval[EXTCON_PROP_CHG_CNT];
+ union extcon_property_value jack_propval[EXTCON_PROP_JACK_CNT];
+ union extcon_property_value disp_propval[EXTCON_PROP_DISP_CNT];
};
static struct class *extcon_class;
@@ -248,6 +253,27 @@ static int find_cable_index_by_id(struct extcon_dev *edev,
const unsigned int id
return -EINVAL;
}
+static int get_extcon_type(unsigned int prop)
+{
+ switch (prop) {
+ case EXTCON_PROP_USB_MIN ... EXTCON_PROP_USB_MAX:
+ return EXTCON_TYPE_USB;
+ case EXTCON_PROP_CHG_MIN ... EXTCON_PROP_CHG_MAX:
+ return EXTCON_TYPE_CHG;
+ case EXTCON_PROP_JACK_MIN ... EXTCON_PROP_JACK_MAX:
+ return EXTCON_TYPE_JACK;
+ case EXTCON_PROP_DISP_MIN ... EXTCON_PROP_DISP_MAX:
+ return EXTCON_TYPE_DISP;
+ default:
+ return -EINVAL;
+ }
+}
+
+static bool is_extcon_attached(struct extcon_dev *edev, unsigned int index)
+{
+ return !!(edev->state & BIT(index));
+}
+
static bool is_extcon_changed(u32 prev, u32 new, int idx, bool *attached)
{
if (((prev >> idx) & 0x1) != ((new >> idx) & 0x1)) {
@@ -258,6 +284,34 @@ static bool is_extcon_changed(u32 prev, u32 new, int idx,
bool *attached)
return false;
}
+static bool is_extcon_property_supported(unsigned int id, unsigned int prop)
+{
+ int type;
+
+ /* Check whether the property is supported or not. */
+ type = get_extcon_type(prop);
+ if (type < 0)
+ return false;
+
+ /* Check whether a specific extcon id supports the property or not. */
+ return !!(extcon_info[id].type & type);
+}
+
+static void init_property(struct extcon_dev *edev, unsigned int id, int index)
+{
+ unsigned int type = extcon_info[id].type;
+ struct extcon_cable *cable = &edev->cables[index];
+
+ if (EXTCON_TYPE_USB & type)
+ memset(cable->usb_propval, 0, sizeof(cable->usb_propval));
+ if (EXTCON_TYPE_CHG & type)
+ memset(cable->chg_propval, 0, sizeof(cable->chg_propval));
+ if (EXTCON_TYPE_JACK & type)
+ memset(cable->jack_propval, 0, sizeof(cable->jack_propval));
+ if (EXTCON_TYPE_DISP & type)
+ memset(cable->disp_propval, 0, sizeof(cable->disp_propval));
+}
+
static ssize_t state_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
@@ -421,7 +475,7 @@ int extcon_get_cable_state_(struct extcon_dev *edev, const
unsigned int id)
if (edev->max_supported && edev->max_supported <= index)
return -EINVAL;
- return !!(edev->state & (1 << index));
+ return is_extcon_attached(edev, index);
}
EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
@@ -449,12 +503,157 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
unsigned int id,
if (edev->max_supported && edev->max_supported <= index)
return -EINVAL;
+ /*
+* Initialize the value of extcon property before setting
+* the detached state for an external connector.
+*/
+ if (!cable_state)
+ init_property(edev, id, index);
+
state = cable_state ? (1 << index) : 0;
return extcon_update_state(edev, 1 << index, state);
}
EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
/**
+ * extcon_get_property() - Get the property value of a specific cable.
+ * @edev: the extcon device that has the cable.
+ * @id:the unique id of
[PATCH v4 0/6] extcon: Add the support for extcon type and property
This patch-set add the support the extcon type, extcon property and the synchronization functions. The each external connector has the common characters. So, the external connectors are able to gather in the specific type. And the each external connectors has the specific H/W desigin to support the multiple features throught h/w lines. There are the requirement to express the each h/w character of each external connector. Lastly, when the state and property are changed, the extcon notify the extcon client driver of the changed information. To support the notification on extcon provider drivers, this patches support the three sync functions. Changes from v3: - Remove the redundant EXTCON_PROP_USB_ID. - Fix the bug of struct __extcon_info for EXTCON_USB_HOST. - Remove the wrong comment in extcon_set_property_capability(). Changes from v2: - Fix minor coding style issue. - Add Tested-by tag of Guenter Roeck for all patches. - Add Reviewed-by tag of Guenter Roeck for all patches Changes from v1: - Expand the size (+1) of the property array for each extcon type. - Use the memset() to initialize the property when connector is detached. - Wrap the data of struct extcon_dev in the lock mechanism. - Don't send the notification if connector state is not changed in extcon_set_state_sync() - Fix the minor issue. - Add Tested-by tag of Chris Zhong for these patches. - Add Signed-off tag of Myungjoo Ham for patch1. - Add Reviewed-by tag of Guenter Roeck for patch6. Depends on: This patch depend on the extcon git repository[2]. (branch : extcon-next) [1] https://en.wikipedia.org/wiki/DisplayPort [2] https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/ [Detailed description of these patches] 1. Add the extcon type to group the each external connector. There are five categories unitl now as following: - EXTCON_TYPE_USB : USB connector - EXTCON_TYPE_CHG : Charger connector - EXTCON_TYPE_JACK : Jack connector - EXTCON_TYPE_DISP : Display connector - EXTCON_TYPE_MISC : Miscellaneous connector 2. Add the extcon property to support the multiple characteristic for the specific H/W design. - EXTCON_PROP_USB_[property name] - EXTCON_PROP_CHG_[property name] - EXTCON_PROP_JACK_[property name] - EXTCON_PROP_DISP_[property name] e.g., EXTCON_PROP_USB_VBUS and EXTCON_PROP_USB_TYPEC_POLARITY The list of the new extcon APIs for the property as following: - int extcon_get_property(struct extcon_dev *edev, unsigned int id, unsigned int prop, union extcon_property_value *prop_val) - int extcon_set_property(struct extcon_dev *edev, unsigned int id, unsigned int prop, union extcon_property_value prop_val) - int extcon_get_property_capability(struct extcon_dev *edev, unsigned int id, unsigned int prop); - int extcon_set_property_capability(struct extcon_dev *edev, unsigned int id, unsigned int prop); 3. Add the sync functions to synchronize the data of each external connector between an extcon provider driver and the extcon client drivers. The list of the new extcon sync APIs as following: - extcon_sync() : Send the notification for each external connector to synchronize the information between and extcon provider driver and the extcon client drivers. - extcon_set_state_sync() : Set the state of external connector with noti. - extcon_set_property_sync() : Set the property of external connector with noti. 4. Add the new external connector definition. The EXTCON_DISP_DP means the Display external connector[1]. The list of new external connector as following: - EXTCON_DISP_DP The list of new property of USB connector as following: - EXTCON_PROP_USB_TYPEC_POLARITY 5. Rename the renames the existing extcon_get/set_cable_state_() to maintain the function naming pattern like as extcon APIs for property. - extcon_set_cable_state_() -> extcon_set_state() - extcon_get_cable_state_() -> extcon_get_state() For example, case 1, change the state of external connector and synchronized the data. extcon_set_state_sync(edev, EXTCON_USB, 1); case 2, change both the state and property of external connector and synchronized the data. extcon_set_state(edev, EXTCON_USB, 0); extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS, 0); extcon_sync(edev, EXTCON_USB); case 3, change the property of external connector and synchronized the data. extcon_set_property(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS, 1); extcon_sync(edev, EXTCON_USB); case 4, change the property of external connector and synchronized the data. extcon_set_property_sync(edev, EXTCON_USB, EXTCON_PROP_USB_VBUS, 0); Chanwoo Choi (5): extcon: Add the extcon_type to gather each connector into five category extcon: Add the support for extcon property according to extcon type extcon: Add the support for the capability of each property
Re: [PATCH v2] mm/slab: Improve performance of gathering slabinfo stats
2016-08-05 4:01 GMT+09:00 Aruna Ramakrishna :
> On large systems, when some slab caches grow to millions of objects (and
> many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds.
> During this time, interrupts are disabled while walking the slab lists
> (slabs_full, slabs_partial, and slabs_free) for each node, and this
> sometimes causes timeouts in other drivers (for instance, Infiniband).
>
> This patch optimizes 'cat /proc/slabinfo' by maintaining a counter for
> total number of allocated slabs per node, per cache. This counter is
> updated when a slab is created or destroyed. This enables us to skip
> traversing the slabs_full list while gathering slabinfo statistics, and
> since slabs_full tends to be the biggest list when the cache is large, it
> results in a dramatic performance improvement. Getting slabinfo statistics
> now only requires walking the slabs_free and slabs_partial lists, and
> those lists are usually much smaller than slabs_full. We tested this after
> growing the dentry cache to 70GB, and the performance improved from 2s to
> 5ms.
>
> Signed-off-by: Aruna Ramakrishna
> Cc: Mike Kravetz
> Cc: Christoph Lameter
> Cc: Pekka Enberg
> Cc: David Rientjes
> Cc: Joonsoo Kim
> Cc: Andrew Morton
> ---
> Note: this has been tested only on x86_64.
>
> mm/slab.c | 25 -
> mm/slab.h | 15 ++-
> mm/slub.c | 19 +--
> 3 files changed, 31 insertions(+), 28 deletions(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 261147b..d683840 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -233,6 +233,7 @@ static void kmem_cache_node_init(struct kmem_cache_node
> *parent)
> spin_lock_init(&parent->list_lock);
> parent->free_objects = 0;
> parent->free_touched = 0;
> + atomic_long_set(&parent->nr_slabs, 0);
> }
>
> #define MAKE_LIST(cachep, listp, slab, nodeid) \
> @@ -2333,6 +2334,7 @@ static int drain_freelist(struct kmem_cache *cache,
> n->free_objects -= cache->num;
> spin_unlock_irq(&n->list_lock);
> slab_destroy(cache, page);
> + atomic_long_dec(&n->nr_slabs);
> nr_freed++;
> }
Please decrease counter when a slab is detached from the list.
Otherwise, there would be inconsistent between counter and
number of attached slab on the list.
> out:
> @@ -2736,6 +2738,8 @@ static struct page *cache_grow_begin(struct kmem_cache
> *cachep,
> if (gfpflags_allow_blocking(local_flags))
> local_irq_disable();
>
> + atomic_long_inc(&n->nr_slabs);
> +
> return page;
Please increase counter when a slab is attached to the list
in cache_grow_end().
> opps1:
> @@ -3455,6 +3459,7 @@ static void free_block(struct kmem_cache *cachep, void
> **objpp,
>
> page = list_last_entry(&n->slabs_free, struct page, lru);
> list_move(&page->lru, list);
> + atomic_long_dec(&n->nr_slabs);
> }
> }
>
> @@ -4111,6 +4116,8 @@ void get_slabinfo(struct kmem_cache *cachep, struct
> slabinfo *sinfo)
> unsigned long num_objs;
> unsigned long active_slabs = 0;
> unsigned long num_slabs, free_objects = 0, shared_avail = 0;
> + unsigned long num_slabs_partial = 0, num_slabs_free = 0;
> + unsigned long num_slabs_full = 0;
> const char *name;
> char *error = NULL;
> int node;
> @@ -4120,36 +4127,36 @@ void get_slabinfo(struct kmem_cache *cachep, struct
> slabinfo *sinfo)
> num_slabs = 0;
> for_each_kmem_cache_node(cachep, node, n) {
>
> + num_slabs += node_nr_slabs(n);
> check_irq_on();
> spin_lock_irq(&n->list_lock);
>
> - list_for_each_entry(page, &n->slabs_full, lru) {
> - if (page->active != cachep->num && !error)
> - error = "slabs_full accounting error";
> - active_objs += cachep->num;
> - active_slabs++;
> - }
> list_for_each_entry(page, &n->slabs_partial, lru) {
> if (page->active == cachep->num && !error)
> error = "slabs_partial accounting error";
> if (!page->active && !error)
> error = "slabs_partial accounting error";
> active_objs += page->active;
> - active_slabs++;
> + num_slabs_partial++;
> }
> +
> list_for_each_entry(page, &n->slabs_free, lru) {
> if (page->active && !error)
> error = "slabs_free accounting error";
> - num_slabs++;
> + num_slabs_free++;
> }
> +
> free_objects += n->free_objects;
> if (n->shared
[PATCH v4 3/6] extcon: Add the support for the capability of each property
This patch adds the support of the property capability setting. This function
decides the supported properties of each external connector on extcon provider
driver.
Ths list of new extcon APIs to get/set the capability of property as following:
- int extcon_get_property_capability(struct extcon_dev *edev,
unsigned int id, unsigned int prop);
- int extcon_set_property_capability(struct extcon_dev *edev,
unsigned int id, unsigned int prop);
Signed-off-by: Chanwoo Choi
Tested-by: Chris Zhong
Tested-by: Guenter Roeck
Reviewed-by: Guenter Roeck
---
drivers/extcon/extcon.c | 140
include/linux/extcon.h | 22
2 files changed, 162 insertions(+)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 37fa4b51c5a1..599fc377a965 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -201,6 +201,11 @@ struct extcon_cable {
union extcon_property_value chg_propval[EXTCON_PROP_CHG_CNT];
union extcon_property_value jack_propval[EXTCON_PROP_JACK_CNT];
union extcon_property_value disp_propval[EXTCON_PROP_DISP_CNT];
+
+ unsigned long usb_bits[BITS_TO_LONGS(EXTCON_PROP_USB_CNT)];
+ unsigned long chg_bits[BITS_TO_LONGS(EXTCON_PROP_CHG_CNT)];
+ unsigned long jack_bits[BITS_TO_LONGS(EXTCON_PROP_JACK_CNT)];
+ unsigned long disp_bits[BITS_TO_LONGS(EXTCON_PROP_DISP_CNT)];
};
static struct class *extcon_class;
@@ -297,6 +302,39 @@ static bool is_extcon_property_supported(unsigned int id,
unsigned int prop)
return !!(extcon_info[id].type & type);
}
+static int is_extcon_property_capability(struct extcon_dev *edev,
+ unsigned int id, int index,unsigned int prop)
+{
+ struct extcon_cable *cable;
+ int type, ret;
+
+ /* Check whether the property is supported or not. */
+ type = get_extcon_type(prop);
+ if (type < 0)
+ return type;
+
+ cable = &edev->cables[index];
+
+ switch (type) {
+ case EXTCON_TYPE_USB:
+ ret = test_bit(prop - EXTCON_PROP_USB_MIN, cable->usb_bits);
+ break;
+ case EXTCON_TYPE_CHG:
+ ret = test_bit(prop - EXTCON_PROP_CHG_MIN, cable->chg_bits);
+ break;
+ case EXTCON_TYPE_JACK:
+ ret = test_bit(prop - EXTCON_PROP_JACK_MIN, cable->jack_bits);
+ break;
+ case EXTCON_TYPE_DISP:
+ ret = test_bit(prop - EXTCON_PROP_DISP_MIN, cable->disp_bits);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
static void init_property(struct extcon_dev *edev, unsigned int id, int index)
{
unsigned int type = extcon_info[id].type;
@@ -554,6 +592,12 @@ int extcon_get_property(struct extcon_dev *edev, unsigned
int id,
spin_lock_irqsave(&edev->lock, flags);
+ /* Check whether the property is available or not. */
+ if (!is_extcon_property_capability(edev, id, index, prop)) {
+ spin_unlock_irqrestore(&edev->lock, flags);
+ return -EPERM;
+ }
+
/*
* Check whether the external connector is attached.
* If external connector is detached, the user can not
@@ -626,6 +670,12 @@ int extcon_set_property(struct extcon_dev *edev, unsigned
int id,
spin_lock_irqsave(&edev->lock, flags);
+ /* Check whether the property is available or not. */
+ if (!is_extcon_property_capability(edev, id, index, prop)) {
+ spin_unlock_irqrestore(&edev->lock, flags);
+ return -EPERM;
+ }
+
cable = &edev->cables[index];
/* Set the property value according to extcon type */
@@ -654,6 +704,96 @@ int extcon_set_property(struct extcon_dev *edev, unsigned
int id,
EXPORT_SYMBOL_GPL(extcon_set_property);
/**
+ * extcon_get_property_capability() - Get the capability of property
+ * of an external connector.
+ * @edev: the extcon device that has the cable.
+ * @id:the unique id of each external connector
+ * in extcon enumeration.
+ * @prop: the property id among enum extcon_property.
+ *
+ * Returns 1 if the property is available or 0 if not available.
+ */
+int extcon_get_property_capability(struct extcon_dev *edev, unsigned int id,
+ unsigned int prop)
+{
+ int index;
+
+ if (!edev)
+ return -EINVAL;
+
+ /* Check whether the property is supported or not */
+ if (!is_extcon_property_supported(id, prop))
+ return -EINVAL;
+
+ /* Find the cable index of external connector by using id */
+ index = find_cable_index_by_id(edev, id);
+ if (index < 0)
+ return index;
+
+ return is_extcon_property_capability
[PATCH v4 4/6] extcon: Rename the extcon_set/get_state() to maintain the function naming pattern
This patch just renames the existing extcon_get/set_cable_state_()
as following because of maintaining the function naming pattern
like as extcon APIs for property.
- extcon_set_cable_state_() -> extcon_set_state()
- extcon_get_cable_state_() -> extcon_get_state()
But, this patch remains the old extcon_set/get_cable_state_() functions
to prevent the build break. After altering new APIs, remove the old APIs.
Signed-off-by: Chanwoo Choi
Tested-by: Chris Zhong
Tested-by: Guenter Roeck
Reviewed-by: Guenter Roeck
---
drivers/extcon/extcon.c | 28 +---
include/linux/extcon.h | 25 ++---
2 files changed, 31 insertions(+), 22 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 599fc377a965..d66adfd21159 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -398,8 +398,7 @@ static ssize_t cable_state_show(struct device *dev,
int i = cable->cable_index;
return sprintf(buf, "%d\n",
- extcon_get_cable_state_(cable->edev,
-
cable->edev->supported_cable[i]));
+ extcon_get_state(cable->edev, cable->edev->supported_cable[i]));
}
/**
@@ -495,13 +494,14 @@ static int extcon_update_state(struct extcon_dev *edev,
u32 mask, u32 state)
}
/**
- * extcon_get_cable_state_() - Get the status of a specific cable.
+ * extcon_get_state() - Get the state of a external connector.
* @edev: the extcon device that has the cable.
* @id:the unique id of each external connector in extcon
enumeration.
*/
-int extcon_get_cable_state_(struct extcon_dev *edev, const unsigned int id)
+int extcon_get_state(struct extcon_dev *edev, const unsigned int id)
{
- int index;
+ int index, state;
+ unsigned long flags;
if (!edev)
return -EINVAL;
@@ -510,22 +510,23 @@ int extcon_get_cable_state_(struct extcon_dev *edev,
const unsigned int id)
if (index < 0)
return index;
- if (edev->max_supported && edev->max_supported <= index)
- return -EINVAL;
+ spin_lock_irqsave(&edev->lock, flags);
+ state = is_extcon_attached(edev, index);
+ spin_unlock_irqrestore(&edev->lock, flags);
- return is_extcon_attached(edev, index);
+ return state;
}
-EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
+EXPORT_SYMBOL_GPL(extcon_get_state);
/**
- * extcon_set_cable_state_() - Set the status of a specific cable.
+ * extcon_set_state() - Set the state of a external connector.
* @edev: the extcon device that has the cable.
* @id:the unique id of each external connector
* in extcon enumeration.
* @state: the new cable status. The default semantics is
* true: attached / false: detached.
*/
-int extcon_set_cable_state_(struct extcon_dev *edev, unsigned int id,
+int extcon_set_state(struct extcon_dev *edev, unsigned int id,
bool cable_state)
{
u32 state;
@@ -538,9 +539,6 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
unsigned int id,
if (index < 0)
return index;
- if (edev->max_supported && edev->max_supported <= index)
- return -EINVAL;
-
/*
* Initialize the value of extcon property before setting
* the detached state for an external connector.
@@ -551,7 +549,7 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
unsigned int id,
state = cable_state ? (1 << index) : 0;
return extcon_update_state(edev, 1 << index, state);
}
-EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
+EXPORT_SYMBOL_GPL(extcon_set_state);
/**
* extcon_get_property() - Get the property value of a specific cable.
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index f08469089f74..4fa37385c97a 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -216,11 +216,11 @@ extern struct extcon_dev *devm_extcon_dev_allocate(struct
device *dev,
extern void devm_extcon_dev_free(struct device *dev, struct extcon_dev *edev);
/*
- * get/set_cable_state access each bit of the 32b encoded state value.
+ * get/set_state access each bit of the 32b encoded state value.
* They are used to access the status of each cable based on the cable id.
*/
-extern int extcon_get_cable_state_(struct extcon_dev *edev, unsigned int id);
-extern int extcon_set_cable_state_(struct extcon_dev *edev, unsigned int id,
+extern int extcon_get_state(struct extcon_dev *edev, unsigned int id);
+extern int extcon_set_state(struct extcon_dev *edev, unsigned int id,
bool cable_state);
/*
@@ -305,14 +305,14 @@ static inline struct extcon_dev
*devm_extcon_dev_allocate(struct device *dev,
static inline void devm_extcon_dev_free(struct extcon_dev *edev) { }
-static inline int extcon_get_cable_state
[PATCH v4 1/6] extcon: Add the extcon_type to gather each connector into five category
This patch adds the new extcon type to group the each connecotr
into following five category. This type would be used to handle
the connectors as a group unit instead of a connector unit.
- EXTCON_TYPE_USB : USB connector
- EXTCON_TYPE_CHG : Charger connector
- EXTCON_TYPE_JACK : Jack connector
- EXTCON_TYPE_DISP : Display connector
- EXTCON_TYPE_MISC : Miscellaneous connector
Also, each external connector is possible to belong to one more extcon type.
In caes of EXTCON_CHG_USB_SDP, it have the EXTCON_TYPE_CHG and EXTCON_TYPE_USB.
Signed-off-by: Chanwoo Choi
Tested-by: Chris Zhong
Tested-by: Guenter Roeck
Signed-off-by: MyungJoo Ham
Reviewed-by: Guenter Roeck
---
drivers/extcon/extcon.c | 159 +++-
include/linux/extcon.h | 9 +++
2 files changed, 139 insertions(+), 29 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 9a266e5c7e10..f209a6959fed 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -38,43 +38,144 @@
#define SUPPORTED_CABLE_MAX32
#define CABLE_NAME_MAX 30
-static const char *extcon_name[] = {
- [EXTCON_NONE] = "NONE",
+struct __extcon_info {
+ unsigned int type;
+ unsigned int id;
+ const char *name;
+
+} extcon_info[] = {
+ [EXTCON_NONE] = {
+ .type = EXTCON_TYPE_MISC,
+ .id = EXTCON_NONE,
+ .name = "NONE",
+ },
/* USB external connector */
- [EXTCON_USB]= "USB",
- [EXTCON_USB_HOST] = "USB-HOST",
+ [EXTCON_USB] = {
+ .type = EXTCON_TYPE_USB,
+ .id = EXTCON_USB,
+ .name = "USB",
+ },
+ [EXTCON_USB_HOST] = {
+ .type = EXTCON_TYPE_USB,
+ .id = EXTCON_USB_HOST,
+ .name = "USB_HOST",
+ },
/* Charging external connector */
- [EXTCON_CHG_USB_SDP]= "SDP",
- [EXTCON_CHG_USB_DCP]= "DCP",
- [EXTCON_CHG_USB_CDP]= "CDP",
- [EXTCON_CHG_USB_ACA]= "ACA",
- [EXTCON_CHG_USB_FAST] = "FAST-CHARGER",
- [EXTCON_CHG_USB_SLOW] = "SLOW-CHARGER",
+ [EXTCON_CHG_USB_SDP] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_SDP,
+ .name = "SDP",
+ },
+ [EXTCON_CHG_USB_DCP] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_DCP,
+ .name = "DCP",
+ },
+ [EXTCON_CHG_USB_CDP] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_CDP,
+ .name = "CDP",
+ },
+ [EXTCON_CHG_USB_ACA] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_ACA,
+ .name = "ACA",
+ },
+ [EXTCON_CHG_USB_FAST] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_FAST,
+ .name = "FAST-CHARGER",
+ },
+ [EXTCON_CHG_USB_SLOW] = {
+ .type = EXTCON_TYPE_CHG | EXTCON_TYPE_USB,
+ .id = EXTCON_CHG_USB_SLOW,
+ .name = "SLOW-CHARGER",
+ },
/* Jack external connector */
- [EXTCON_JACK_MICROPHONE]= "MICROPHONE",
- [EXTCON_JACK_HEADPHONE] = "HEADPHONE",
- [EXTCON_JACK_LINE_IN] = "LINE-IN",
- [EXTCON_JACK_LINE_OUT] = "LINE-OUT",
- [EXTCON_JACK_VIDEO_IN] = "VIDEO-IN",
- [EXTCON_JACK_VIDEO_OUT] = "VIDEO-OUT",
- [EXTCON_JACK_SPDIF_IN] = "SPDIF-IN",
- [EXTCON_JACK_SPDIF_OUT] = "SPDIF-OUT",
+ [EXTCON_JACK_MICROPHONE] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_MICROPHONE,
+ .name = "MICROPHONE",
+ },
+ [EXTCON_JACK_HEADPHONE] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_HEADPHONE,
+ .name = "HEADPHONE",
+ },
+ [EXTCON_JACK_LINE_IN] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_LINE_IN,
+ .name = "LINE-IN",
+ },
+ [EXTCON_JACK_LINE_OUT] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_LINE_OUT,
+ .name = "LINE-OUT",
+ },
+ [EXTCON_JACK_VIDEO_IN] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_VIDEO_IN,
+ .name = "VIDEO-IN",
+ },
+ [EXTCON_JACK_VIDEO_OUT] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_VIDEO_OUT,
+ .name = "VIDEO-OUT",
+ },
+ [EXTCON_JACK_SPDIF_IN] = {
+ .type = EXTCON_TYPE_JACK,
+ .id = EXTCON_JACK_SPDIF_IN,
+ .name = "SPDIF-IN",
+
[PATCH v4 6/6] extcon: Add EXTCON_DISP_DP and the property for USB Type-C
From: Chris Zhong
Add EXTCON_DISP_DP for the Display external connector. For Type-C
connector the DisplayPort can work as an Alternate Mode(VESA DisplayPort
Alt Mode on USB Type-C Standard). The Type-C support both normal
and flipped orientation, so add a property to extcon.
Signed-off-by: Chris Zhong
Signed-off-by: Chanwoo Choi
Tested-by: Chris Zhong
Tested-by: Guenter Roeck
Reviewed-by: Guenter Roeck
---
drivers/extcon/extcon.c | 5 +
include/linux/extcon.h | 8 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 8fde4befaa51..a0a1eea18727 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -157,6 +157,11 @@ struct __extcon_info {
.id = EXTCON_DISP_VGA,
.name = "VGA",
},
+ [EXTCON_DISP_DP] = {
+ .type = EXTCON_TYPE_DISP | EXTCON_TYPE_USB,
+ .id = EXTCON_DISP_DP,
+ .name = "DP",
+ },
/* Miscellaneous external connector */
[EXTCON_DOCK] = {
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 162c46a42bac..ad7a1606a7f3 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -69,6 +69,7 @@
#define EXTCON_DISP_MHL41 /* Mobile High-Definition Link
*/
#define EXTCON_DISP_DVI42 /* Digital Visual Interface */
#define EXTCON_DISP_VGA43 /* Video Graphics Array */
+#define EXTCON_DISP_DP 44 /* Display Port */
/* Miscellaneous external connector */
#define EXTCON_DOCK60
@@ -102,11 +103,16 @@
* @type: integer (intval)
* @value: 0 (low) or 1 (high)
* @default: 0 (low)
+ * - EXTCON_PROP_USB_TYPEC_POLARITY
+ * @type: integer (intval)
+ * @value: 0 (normal) or 1 (flip)
+ * @default: 0 (normal)
*/
#define EXTCON_PROP_USB_VBUS 0
+#define EXTCON_PROP_USB_TYPEC_POLARITY 1
#define EXTCON_PROP_USB_MIN0
-#define EXTCON_PROP_USB_MAX0
+#define EXTCON_PROP_USB_MAX1
#define EXTCON_PROP_USB_CNT(EXTCON_PROP_USB_MAX - EXTCON_PROP_USB_MIN + 1)
/* Properties of EXTCON_TYPE_CHG. */
--
1.9.1
Re: [PATCH v3 2/6] extcon: Add the support for extcon property according to extcon type
Hi Guenter, On 2016년 08월 04일 23:47, Guenter Roeck wrote: > On Thu, Aug 4, 2016 at 3:57 AM, Chanwoo Choi wrote: >> Hi Guenter and Roger, >> >> On 2016년 08월 04일 17:49, Roger Quadros wrote: >>> On 04/08/16 07:09, Guenter Roeck wrote: On Wed, Aug 3, 2016 at 5:42 PM, Chanwoo Choi wrote: > Hi Roger, > > On 2016년 08월 03일 18:46, Roger Quadros wrote: >> Hi Chanwoo, >> [ ... ] > + /* > + * Check whether the external connector is attached. > + * If external connector is detached, the user can not > + * get the property value. > + */ How will this work for USB case? We need to know VBUS and ID states even if the USB cable is detached. >>> >>> When USB is detached, extcon_get_property return the default value >>> without any operation. >>> The default value of supported property are 0 (zero). If new property >>> need the differnt default >>> value, I'll support it. >> >> Is the property a property of the connector or of the cable? >> >> In my opinion, ID and VBUS are properties of the USB connector and not of >> the USB cable. So extcon must provide valid status for those properties >> even if USB cable or USB_HOST cable is detached. > > I don't understand about that if USB and USB_HOST are detached, > how can the USB be operating? As you mentioned that, extcon must > provide the valid status for both state and properties. > Correct. No cable means that the polarity is unknown, and VBUS must not be active (for USB_HOST), or it can not be active (for USB). >>> >>> OK. >>> Only question might be EXTCON_PROP_USB_ID; I am not sure I understand what it is supposed to return. Maybe it would be worthwhile to document it ? >>> >>> Agreed. It seems redundant as ID can be easily inferred from USB_HOST cable >>> state. >>> i.e. if USB_HOST is attached ID is 0. If USB_HOST is detached ID is 1. >> >> Do you mean the EXTCON_PROP_USB_ID is un-needed? >> I'll remove the EXTCON_PROP_USB_ID property on next version. >> > > If ID reflects host vs. device state, yes, it is not needed. Or, > alternatively, one of USB and USB_HOST would not be needed if ID is > present. Since that is not feasible because it would modify the ABI to > user space, dropping ID makes sense. OK. I'll drop the EXTCON_PROP_USB_ID. Thanks. Regards, Chanwoo Choi > > Thanks, > Guenter > >>> > So, I already mentioned, When USB and USB_HOST are detached, > extcon return the default value instead of error value. > I think that it is reasonable. Why is it not a valid? > I agree; I don't know what else could be returned if no cable is attached, even if we wanted to. >>> OK. >>> >>> I understood now that if kernel USB driver can interpret EXTCON_USB, >>> EXTCON_USB_HOST >>> and VBUS property, it sufficiently captures ID and VBUS information. >>> >> >> Regards, >> Chanwoo Choi >> > > >
The timer softirq on the RT kernel
Hi,Mike & Steven On https://lkml.org/lkml/2015/3/24/1178, the patch of "timers: do not raise softirq unconditionally" is reverted. Thanks for Steven's detailed comments, it's quite clear explained. I remember Mike has a patch trying to fix it but late abandoned. Do you still have any plan to work on this? Otherwise, I will have a try. Thanks --jyh
[Patch v3 07/11] driver/edac/fsl_ddr: Add DDR4 type
Signed-off-by: York Sun --- Change log v3: no change v2: no change drivers/edac/fsl_ddr_edac.c | 12 ++-- drivers/edac/fsl_ddr_edac.h | 1 + 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/edac/fsl_ddr_edac.c b/drivers/edac/fsl_ddr_edac.c index 60761c0..88ecf7d 100644 --- a/drivers/edac/fsl_ddr_edac.c +++ b/drivers/edac/fsl_ddr_edac.c @@ -376,6 +376,9 @@ static void fsl_ddr_init_csrows(struct mem_ctl_info *mci) case DSC_SDTYPE_DDR3: mtype = MEM_RDDR3; break; + case DSC_SDTYPE_DDR4: + mtype = MEM_RDDR4; + break; default: mtype = MEM_UNKNOWN; break; @@ -391,6 +394,9 @@ static void fsl_ddr_init_csrows(struct mem_ctl_info *mci) case DSC_SDTYPE_DDR3: mtype = MEM_DDR3; break; + case DSC_SDTYPE_DDR4: + mtype = MEM_DDR4; + break; default: mtype = MEM_UNKNOWN; break; @@ -495,8 +501,10 @@ int fsl_ddr_mc_err_probe(struct platform_device *op) } edac_dbg(3, "init mci\n"); - mci->mtype_cap = MEM_FLAG_RDDR | MEM_FLAG_RDDR2 | - MEM_FLAG_DDR | MEM_FLAG_DDR2; + mci->mtype_cap = MEM_FLAG_DDR | MEM_FLAG_RDDR | +MEM_FLAG_DDR2 | MEM_FLAG_RDDR2 | +MEM_FLAG_DDR3 | MEM_FLAG_RDDR3 | +MEM_FLAG_DDR4 | MEM_FLAG_RDDR4; mci->edac_ctl_cap = EDAC_FLAG_NONE | EDAC_FLAG_SECDED; mci->edac_cap = EDAC_FLAG_SECDED; mci->mod_name = EDAC_MOD_STR; diff --git a/drivers/edac/fsl_ddr_edac.h b/drivers/edac/fsl_ddr_edac.h index 556bac5..c7b7dbf 100644 --- a/drivers/edac/fsl_ddr_edac.h +++ b/drivers/edac/fsl_ddr_edac.h @@ -50,6 +50,7 @@ #define DSC_SDTYPE_DDR 0x0200 #define DSC_SDTYPE_DDR20x0300 #define DSC_SDTYPE_DDR30x0700 +#define DSC_SDTYPE_DDR40x0500 #define DSC_X32_EN 0x0020 /* Err_Int_En */ -- 2.7.4
[PATCH] arm64: Add workaround for Cavium erratum 26026
The patch below is on top of Matthias' patch series:
arm64: Implement IPI based TLB invalidation
The series is used to enable a workaround for Cavium ThunderX pass 1.x
systems.
-Robert
>From abb99ee83473d9ecffb4fdaae9c69435ca670bc8 Mon Sep 17 00:00:00 2001
From: Robert Richter
Date: Fri, 29 Jul 2016 09:40:04 +0200
Subject: [PATCH] arm64: Add workaround for Cavium erratum 26026
STX may return a wrong status value if the store was successful.
This may happen on ThunderX T88 pass 1.x cpus if a broadcast TLBI is
executed on another cpu in parallel to an STX. As a result atomic or
non-blocking implementations can behave incorrectly. Use IPIs that
call local TLBIs on other cpus to avoid this.
Applies to ThunderX T88 pass 1.x cpus.
Signed-off-by: Robert Richter
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 14 ++
arch/arm64/kernel/cpu_errata.c | 8
3 files changed, 23 insertions(+)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/silicon-errata.txt
index 4da60b463995..0d870d934528 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -58,5 +58,6 @@ stable kernels.
| Cavium | ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375
|
| Cavium | ThunderX ITS| #23144 | CAVIUM_ERRATUM_23144
|
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154
|
+| Cavium | ThunderX Core | #26026 | CAVIUM_ERRATUM_26026
|
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456
|
| Cavium | ThunderX SMMUv2 | #27704 | N/A|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5a0a691d4220..8cbd9043ec6f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -457,6 +457,20 @@ config CAVIUM_ERRATUM_23154
If unsure, say Y.
+config CAVIUM_ERRATUM_26026
+ bool "Cavium erratum 26026: STX may return wrong status value"
+ default y
+ help
+ STX may return a wrong status value if the store was
+ successful. This may happen on ThunderX T88 pass 1.x cpus if
+ a broadcast TLBI is executed on another cpu in parallel to
+ an STX. As a result atomic or non-blocking implementations
+ can behave incorrectly. Use IPIs that call local TLBIs on
+ other cpus to avoid this.
+ Applies to ThunderX T88 pass 1.x cpus.
+
+ If unsure, say Y.
+
config CAVIUM_ERRATUM_27456
bool "Cavium erratum 27456: Broadcast TLBI instructions may cause
icache corruption"
default y
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index af716b65110d..1e1753a6408e 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -90,6 +90,14 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
},
#endif
+#ifdef CONFIG_CAVIUM_ERRATUM_26026
+ {
+ /* Cavium ThunderX, pass 1.x */
+ .desc = "Cavium erratum 26026",
+ .capability = ARM64_HAS_NO_BCAST_TLBI,
+ MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
+ },
+#endif
#ifdef CONFIG_CAVIUM_ERRATUM_27456
{
/* Cavium ThunderX, T88 pass 1.x - 2.1 */
--
2.7.0.rc3
Re: [PATCH v13 06/30] powerpc/ptrace: Adapt gpr32_get, gpr32_set functions for transaction
Michael Ellerman writes: >> Is there a nice simple fix we could deploy to squash this warning, or >> will we just live with it? > > This series has been nothing but pain. Given we're already at v13, and people > really want this support to go in, I'm going to leave it in the tree. > > Once it's in we can refactor the implementation, which is a bit of a mess, and > hopefully in the process fix the warnings. OK, I'll push this onto my stack to look at again in a couple of months. Regards, Daniel signature.asc Description: PGP signature
[no subject]
-- Shougang Group Co., Ltd. 11th Floor, Huaxingge, Donghua Building, Jiangmen, GuangDong, China. www.shougang.com.cn Greetings, This is an official request for Professional/consultants who will stand as our regional representative to run logistics on behalf of Shougang Group.We are looking for a payment collection agent in USA, Canada, Mexico and Europe. Salary is 10% of every payment you receive from our customers. Get back to us for more details if interested. Kindly send us the following informations for further proceedings (1)Your Full names: (2)Your Complete Address: a. City: b. State: c. Zip code: d. Country: (3)Tele/cell numbers: (4)Occupation: (5)Gender: (6)Age: (7)Email: Respectfully Mr Sun Xiao Lan (Human Resources) Shougang Group
Re: [PATCH] net: ethernet: ti: cpsw: split common driver data and slaves data
Hi Ivan,
[auto build test ERROR on net/master]
[also build test ERROR on next-20160804]
[cannot apply to net-next/master v4.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ivan-Khoronzhuk/net-ethernet-ti-cpsw-split-common-driver-data-and-slaves-data/20160805-052837
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
>> drivers/net/ethernet/ti/cpsw.c:403:8: error: expected ';', identifier or '('
>> before 'struct'
static struct cpsw_common *cpsw;
^
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_tx_poll':
>> drivers/net/ethernet/ti/cpsw.c:788:27: error: implicit declaration of
>> function 'napi_to_priv' [-Werror=implicit-function-declaration]
struct cpsw_priv *priv = napi_to_priv(napi_tx);
^
>> drivers/net/ethernet/ti/cpsw.c:788:27: warning: initialization makes pointer
>> from integer without a cast [-Wint-conversion]
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_rx_poll':
drivers/net/ethernet/ti/cpsw.c:809:27: warning: initialization makes pointer
from integer without a cast [-Wint-conversion]
struct cpsw_priv *priv = napi_to_priv(napi_rx);
^
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_ndo_open':
>> drivers/net/ethernet/ti/cpsw.c:1259:12: error: 'struct cpsw_priv' has no
>> member named 'version'
reg = priv->version;
^
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_probe_dual_emac':
>> drivers/net/ethernet/ti/cpsw.c:2148:15: warning: unused variable 'i'
>> [-Wunused-variable]
int ret = 0, i;
^
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_probe':
>> drivers/net/ethernet/ti/cpsw.c:2434:6: error: 'struct cpsw_common' has no
>> member named 'irq'
cpsw->irq = platform_get_irq(pdev, 1);
^
drivers/net/ethernet/ti/cpsw.c:2435:10: error: 'struct cpsw_common' has no
member named 'irq'
if (cpsw->irq < 0) {
^
drivers/net/ethernet/ti/cpsw.c:2437:13: error: 'struct cpsw_common' has no
member named 'irq'
ret = cpsw->irq;
^
cc1: some warnings being treated as errors
vim +403 drivers/net/ethernet/ti/cpsw.c
397 /* snapshot of IRQ numbers */
398 u32 irqs_table[4];
399 u32 num_irqs;
400 struct cpts *cpts;
401 }
402
> 403 static struct cpsw_common *cpsw;
404
405 struct cpsw_stats {
406 char stat_string[ETH_GSTRING_LEN];
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v4 0/3] dma-mapping, powerpc, nvme: introduce the DMA_ATTR_NO_WARN attribute
Andrew, On 08/04/2016 07:01 PM, Andrew Morton wrote: It would help to have seen an example of the error message - please always quote such things when fixing bugs. Indeed; okay. The error messages are several blocks like this one: ppc_iommu_map_sg: 11784 callbacks suppressed nvme 0001:01:00.0: iommu_alloc failed, tbl c1965c5ca400 vaddr c18faa7b npages 16 nvme 0001:01:00.0: iommu_alloc failed, tbl c1965c5ca400 vaddr c18faa9b npages 16 I assume the warnings are coming via nvme_map_data()'s call to blk_rq_map_sg()? [snip] If I understand the point in the question correctly -- actually not, the warnings are coming via: nvme_map_data() -> dma_map_sg[_attrs]() -> dma_map_ops.map_sg() (dma_map_ops = dma_iommu_ops @ arch/powerpc/kernel/iommu.c) -> dma_iommu_map_sg() -> ppc_iommu_map_sg() /* as seen above */ And from what I could observe, the blk_rq_map_sg() path doesn't end up in there. [snip] An alternative (and more idiomatic) fix would be to change the blk_rq_map_sg() interface to permit passing down some foo_NOWARN flag and propagating that down the stack into ppc_iommu_map_sg(). Was this approach evaluated? I suspect it might be messy. I see; I haven't evaluated that, but agree with you it might be messy. As far as I can see, in order to pass something to blk_rq_map_sg() and have it eventually make into ppc_iommu_map_sg(), that something should be present in the scatterlist -- which seems to be what's common/passed to both blk_rq_map_sg() (the interface point proposed) and dma_map_sg() (which is the function which reaches ppc_iommu_map_sg() down the chain). It seems a bit hidden, and (if I got the suggestion right), it doesn't seem to be in the scope of scatterlist to contain such a flag. One point of the patches is make the attribute visible/explicit; I see it can be inconvenient sometimes, but it allows for a clear / evident difference between dma_map_sg() calls which are (not) OK with failures. (for example, the 2 calls in nvme_map_data() - they can return either BLK_MQ_RQ_QUEUE_BUSY or BLK_MQ_RQ_QUEUE_ERROR - so the former is OK.) Does that make sense? Thanks for the review. -- Mauricio Faria de Oliveira IBM Linux Technology Center
Re: [RFC V2 PATCH 17/25] net/netpolicy: introduce netpolicy_pick_queue
On 08/05/2016 12:54 AM, Andi Kleen wrote: +1, I tried to bring this up here [1] in the last spin. I think only very few changes would be needed, f.e. on eBPF side to add a queue setting helper function which is probably straight forward ~10loc patch; and with regards to actually picking it up after clsact egress, we'd need to adapt __netdev_pick_tx() slightly when CONFIG_XPS so it doesn't override it. You're proposing to rewrite the whole net policy manager as EBPF and run it in a crappy JITer? Is that a serious proposal? It just sounds crazy to me. Especially since we already have a perfectly good compiler and programming language to write system code in. EBPF is ok for temporal instrumentation (if you somehow can accept its security challenges), but using it to replace core kernel functionality (which network policy IMHO is) with some bizarre JITed setup and multiple languages doesn't really make any sense. Especially it doesn't make sense for anything with shared state, which is the core part of network policy: it negotiates with multiple users. After all we're writing Linux here and not some research toy. From what I read I guess you didn't really bother to look any deeper into this bizarre "research toy" to double check some of your claims. One of the things it's often deployed for by the way is defining policy. And the suggestion here was merely to explore existing infrastructure around things like tc and whether it already resolves at least a part of your net policy manager's requirements (like queue selection) or whether existing infrastructure can be extended with fewer complexity this way (as was mentioned with a new cls module as one option).
Re: [RFC PATCH] sunrpc: do not allow process to freeze within RPC state machine
On Wed, Aug 03, 2016 at 08:54:50PM +0400, Stanislav Kinsburskiy wrote: > Otherwise freezer cgroup state might never become "FROZEN". > > Here is a deadlock scheme for 2 processes in one freezer cgroup, which is > freezing: > > CPU 0 CPU 1 > > do_last > inode_lock(dir->d_inode) > vfs_create > nfs_create > ... > __rpc_execute > rpc_wait_bit_killable > __refrigerator > do_last > inode_lock(dir->d_inode) > > So, the problem is that one process takes directory inode mutex, executes > creation request and goes to refrigerator. > Another one waits till directory lock is released, remains "thawed" and thus > freezer cgroup state never becomes "FROZEN". > > Notes: > 1) Interesting, that this is not a pure deadlock: one can thaw cgroup and then > freeze it again. > 2) The issue was introduced by commit > d310310cbff18ec385c6ab4d58f33b100192a96a. > 3) This patch is not aimed to fix the issue, but to show the problem root. > Look like this problem moght be applicable to other hunks from the commit, > mentioned above. > > Signed-off-by: Stanislav Kinsburskiy I think it's worth adding backtrace as well --- === pid: 708987 === (file_read) [] __refrigerator+0x5b/0x190 [] rpc_wait_bit_killable+0x66/0x80 [sunrpc] [] __rpc_execute+0x154/0x420 [sunrpc] [] rpc_execute+0x5e/0xa0 [sunrpc] [] rpc_run_task+0x70/0x90 [sunrpc] [] rpc_call_sync+0x50/0xc0 [sunrpc] [] nfs3_rpc_wrapper.constprop.10+0x6b/0xb0 [nfsv3] [] nfs3_proc_setattr+0xbf/0x140 [nfsv3] [] nfs3_proc_create+0x1a3/0x220 [nfsv3] [] nfs_create+0x83/0x150 [nfs] [] vfs_create+0x8c/0x110 [] do_last+0xc0d/0x11d0 [] path_openat+0xc2/0x460 [] do_filp_open+0x4b/0xb0 [] do_sys_open+0xf3/0x1f0 [] SyS_open+0x1e/0x20 [] system_call_fastpath+0x16/0x1b [] 0x === pid: 708988 === (file_read) [] do_last+0x283/0x11d0 [] path_openat+0xc2/0x460 [] do_filp_open+0x4b/0xb0 [] do_sys_open+0xf3/0x1f0 [] SyS_open+0x1e/0x20 [] system_call_fastpath+0x16/0x1b [] 0x
Re: [RFC V2 PATCH 00/25] Kernel NET policy
On Wed, 31 Dec 2014 20:38:49 -0500 kan.li...@intel.com wrote: > 5. Why disable IRQ balance? > A: Disabling IRQ balance is a common way (recommend way for some devices) > to >tune network performance. I appreciate that network tuning is hard, most people get it wrong, and nobody agrees on the right answer. So rather than fixing existing tools or writing new userspace tools to do network tuning, you want to hard code one policy manager in kernel with a /proc interface. Why not make a good userspace tool (like powertop). There are also several IRQ balancing programs, but since irqbalance was championed by one vendor others seem to follow like sheep. I agree that this a real concern but the implementation of this leaves much to be desired and discussed. Why can't this be done outside of the kernel.
Re: [PATCH 0215/1285] Replace numeric parameter like 0444 with macro
Reviewed-by: Sinclair Yeh On Tue, Aug 02, 2016 at 06:50:25PM +0800, Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro, > and that using macro can improve the robustness and readability of the code, > thus, I suggest replacing the numeric parameter with the macro. > > Signed-off-by: Chuansheng Liu > Signed-off-by: Baole Ni > --- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > index 9fcd820..b8e5d3d 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > @@ -240,15 +240,15 @@ static int vmwgfx_pm_notifier(struct notifier_block > *nb, unsigned long val, > void *ptr); > > MODULE_PARM_DESC(enable_fbdev, "Enable vmwgfx fbdev"); > -module_param_named(enable_fbdev, enable_fbdev, int, 0600); > +module_param_named(enable_fbdev, enable_fbdev, int, S_IRUSR | S_IWUSR); > MODULE_PARM_DESC(force_dma_api, "Force using the DMA API for TTM pages"); > -module_param_named(force_dma_api, vmw_force_iommu, int, 0600); > +module_param_named(force_dma_api, vmw_force_iommu, int, S_IRUSR | S_IWUSR); > MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages"); > -module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600); > +module_param_named(restrict_iommu, vmw_restrict_iommu, int, S_IRUSR | > S_IWUSR); > MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages"); > -module_param_named(force_coherent, vmw_force_coherent, int, 0600); > +module_param_named(force_coherent, vmw_force_coherent, int, S_IRUSR | > S_IWUSR); > MODULE_PARM_DESC(restrict_dma_mask, "Restrict DMA mask to 44 bits with > IOMMU"); > -module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, 0600); > +module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, S_IRUSR | > S_IWUSR); > > > static void vmw_print_capabilities(uint32_t capabilities) > -- > 2.9.2 >
RE: [PATCH 13/32] Documentation, x86: Documentation for Intel resource allocation user interface
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Tuesday, July 19, 2016 5:32 AM > On Thu, 14 Jul 2016, Luck, Tony wrote: > > So the core part of __intel_rdt_sched_in() will look like: > > > > rdtgrp = root_rdtgroup; > That can be done simpler. The default cpu_rdtgroup should be > root_rdtgroup. So you spare one conditional. > > Thanks > > tglx Hi, Thomas et al, Do we need to consider using generic schemas format instead of the current architecture specific schemas format? Currently we use CBM (Cache Bit Mask) in the "schemas". This is architecture specific format. A feedback I got is this may not be expanded to hypothetical future other architecture(s), user/sysadmin may not have knowledge of CBM, and difficult VM migration b/w different machines which have different length of CBM. Our current answer to the feedback is user tool/knowledge is needed to set up schemas. Kernel only does CBM or architecture level schemas. User management tools can be designed to hide all kernel CBM details and allow users to allocate cache with high level knowledge (e.g. % of cache or size of cache etc). I believe user level tool can handle this and kernel only needs to handle minimal CBM level. This is how we have been designing this user interface. But on the other hand, we can handle high level schemas info in kernel user interface as well. We can introduce allocation policies to user interface. User specifies an allocation policy during resctrl file system mount time. Each policy has its own driver in kernel. Default policy is to use current CBM schemas that is implemented in this patch set. We can implement other drivers and schemas format may be different in each driver. For example, % policy driver which specifies % of L3 allocation in the schemas. Another example, size policy driver which specifies size of L3 in the schemas. And people can write other creative policies in the future. Each driver has its own CONFIG. If doing this, this updated user interface can address the above concerns in kernel level plus it can handle cases (example??) that user tool cannot handle in user space. Should we update the current user interface to do this? Code and document changes should be about 50 lines more on top of current patch set. Just raise the question for open discussion. Thanks. -Fenghua
Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data
On Thu, Aug 04, 2016 at 03:21:13PM -0700, Matt Ranostay wrote:
> On Thu, Aug 4, 2016 at 8:35 AM, Alison Schofield wrote:
> > On Wed, Aug 03, 2016 at 10:50:54PM -0700, Matt Ranostay wrote:
> >> On Wed, Aug 3, 2016 at 10:19 PM, Peter Meerwald-Stadler
> >> wrote:
> >>
> >> >
> >> > > > Replace the i2c_smbus_read_byte commmands used to retrieve the sensor
> >> > > > data with an i2c_master_recv command.
> >> > > >
> >> > > > The smbus read byte method fails because the device does not expect a
> >> > > > stop condition after sending the first byte. When we issue the second
> >> > > > read, we are getting the first byte again. Net effect is that of the
> >> > > > 14
> >> > > > bits used for the measurement, the 8 most significant bits are
> >> > > > correct,
> >> > > > the lower 6 are not.
> >> > > >
> >> > > > None of the smbus read protocols follow the pattern this device
> >> > requires
> >> > > > (S Addr Rd [A] Data [A] Data NA P), hence the switch to an i2c
> >> > > > receive
> >> > > > transaction.
> >> > > >
> >> > > > Signed-off-by: Alison Schofield
> >> > > > Cc: Daniel Baluta
> >> > > > ---
> >> > > > drivers/iio/humidity/hdc100x.c | 27 +++
> >> > > > 1 file changed, 7 insertions(+), 20 deletions(-)
> >> > > >
> >> > > > diff --git a/drivers/iio/humidity/hdc100x.c
> >> > b/drivers/iio/humidity/hdc100x.c
> >> > > > index a03832a..643a42d 100644
> >> > > > --- a/drivers/iio/humidity/hdc100x.c
> >> > > > +++ b/drivers/iio/humidity/hdc100x.c
> >> > > > @@ -142,7 +142,7 @@ static int hdc100x_get_measurement(struct
> >> > hdc100x_data *data,
> >> > > > struct i2c_client *client = data->client;
> >> > > > int delay = data->adc_int_us[chan->address];
> >> > > > int ret;
> >> > > > - int val;
> >> > > > + u8 buf[2];
> >> >
> >> > __le16 val;
> >> >
> >> > > >
> >> > > > /* start measurement */
> >> > > > ret = i2c_smbus_write_byte(client, chan->address);
> >> > > > @@ -154,26 +154,13 @@ static int hdc100x_get_measurement(struct
> >> > hdc100x_data *data,
> >> > > > /* wait for integration time to pass */
> >> > > > usleep_range(delay, delay + 1000);
> >> > > >
> >> > > > - /*
> >> > > > -* i2c_smbus_read_word_data cannot() be used here due to the
> >> > command
> >> > > > -* value not being understood and causes NAKs preventing any
> >> > reading
> >> > > > -* from being accessed.
> >> > > > -*/
> >> > > > - ret = i2c_smbus_read_byte(client);
> >> > > > + /* read the 2 byte measurement */
> >> > > > + ret = i2c_master_recv(data->client, buf, 2);
> >> > > > if (ret < 0) {
> >> > > > - dev_err(&client->dev, "cannot read high byte
> >> > measurement");
> >> > > > + dev_err(&client->dev, "cannot read sensor data\n");
> >> > > > return ret;
> >> > > > }
> >> > > > - val = ret << 8;
> >> > > > -
> >> > > > - ret = i2c_smbus_read_byte(client);
> >> > > > - if (ret < 0) {
> >> > > > - dev_err(&client->dev, "cannot read low byte
> >> > measurement");
> >> > > > - return ret;
> >> > > > - }
> >> > > > - val |= ret;
> >> > > > -
> >> > > > - return val;
> >> > > > + return (int)(buf[0] << 8 | buf[1]);
> >> > >
> >> > > Pretty sure you don't need to cast to int type here.
> >> >
> >> > return le16_to_cpu(val);
> >> >
> >> >
> >> You mean le16_to_cpu(&buf) I assume?
> >>
> >>
> >> > >
> >> > > > }
> >> > > >
> >> > > > static int hdc100x_get_heater_status(struct hdc100x_data *data)
> >> > > > @@ -272,8 +259,8 @@ static int hdc100x_probe(struct i2c_client
> >> > > > *client,
> >> > > > struct iio_dev *indio_dev;
> >> > > > struct hdc100x_data *data;
> >> > > >
> >> > > > - if (!i2c_check_functionality(client->adapter,
> >> > > > - I2C_FUNC_SMBUS_WORD_DATA |
> >> > I2C_FUNC_SMBUS_BYTE))
> >> > > > + if (!i2c_check_functionality(client->adapter,
> >> > I2C_FUNC_SMBUS_WORD_DATA |
> >> > > > +I2C_FUNC_SMBUS_BYTE |
> >> > I2C_FUNC_I2C))
> >> > >
> >> > > Not sure we want to kill smbus support for this device... iwe should
> >> > > have two read methods for i2c and smbus (see the PulsedLight LIDAR
> >> > > driver) in this case.
> >> > >
> >> > > Ideally I wouldn't have written it with only smbus in mind, but can
> >> > > kill backwards compatibility unless we have a good reason.
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Matt
> >
> > Thanks for the reviews. Let me clarify:
> >
> > This is a fix for a bug in the current driver. See the changelog.
> >
> > The relationship between this patch and my triggered-buffer work
> > is that I found this bug while trying to do just what you say above.
> > I tried to have 2 methods for reading data - smbus and plain i2c.
> > That's the point where I found that smbus reads do not work, never did.
> >
> > I know we
Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac
On 05/08/16 08:58, York Sun wrote:
Two symbols are missing if mpc85xx_edac driver is compiled as module.
Signed-off-by: York Sun
Good catch! One comment below.
Reviewed-by: Andrew Donnellan
/*
* Reads the interrupt pin to determine if interrupt is use by card.
@@ -1585,6 +1586,7 @@ int early_find_capability(struct pci_controller *hose,
int bus, int devfn,
{
return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
}
+EXPORT_SYMBOL(early_find_capability);
It'd be nicer for this to be renamed as "pci_early_find_capability" or
something like that with a "namespace", I think.
Andrew
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com IBM Australia Limited
[Patch v3 08/11] driver/edac/fsl_ddr: Add support of little endian
Get endianness from device tree. Both big endian and little endian
are supported. Default to big endian for backward compatibility to
MPC85xx.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: Separated from "Add support for ARM-based SoCs" patch
.../fsl/ddr.txt} | 6 ++
drivers/edac/fsl_ddr_edac.c| 83 ++
2 files changed, 58 insertions(+), 31 deletions(-)
rename Documentation/devicetree/bindings/{powerpc/fsl/mem-ctrlr.txt =>
memory-controllers/fsl/ddr.txt} (74%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt
b/Documentation/devicetree/bindings/memory-controllers/fsl/ddr.txt
similarity index 74%
rename from Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt
rename to Documentation/devicetree/bindings/memory-controllers/fsl/ddr.txt
index f87856f..62623f9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ddr.txt
@@ -7,6 +7,10 @@ Properties:
"fsl,qoriq-memory-controller".
- reg : Address and size of DDR controller registers
- interrupts : Error interrupt of DDR controller
+- little-endian: Specifies little-endian access to registers
+- big-endian : Specifies big-endian access to registers
+
+If both little-endian and big-endian are omitted, big-endian will be used.
Example 1:
@@ -14,6 +18,7 @@ Example 1:
compatible = "fsl,bsc9132-memory-controller";
reg = <0x2000 0x1000>;
interrupts = <16 2 1 8>;
+ big-endian;
};
@@ -24,4 +29,5 @@ Example 2:
"fsl,qoriq-memory-controller";
reg = <0x8000 0x1000>;
interrupts = <16 2 1 23>;
+ big-endian;
};
diff --git a/drivers/edac/fsl_ddr_edac.c b/drivers/edac/fsl_ddr_edac.c
index 88ecf7d..b1b7924 100644
--- a/drivers/edac/fsl_ddr_edac.c
+++ b/drivers/edac/fsl_ddr_edac.c
@@ -9,7 +9,6 @@
* the terms of the GNU General Public License version 2. This program
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
- *
*/
#include
#include
@@ -33,6 +32,20 @@ static int edac_mc_idx;
static u32 orig_ddr_err_disable;
static u32 orig_ddr_err_sbe;
+static bool little_endian;
+
+static inline u32 ddr_in32(void __iomem *addr)
+{
+ return little_endian ? ioread32(addr) : ioread32be(addr);
+}
+
+static inline void ddr_out32(void __iomem *addr, u32 value)
+{
+ if (little_endian)
+ iowrite32(value, addr);
+ else
+ iowrite32be(value, addr);
+}
/ MC SYSFS parts ***/
@@ -45,7 +58,7 @@ static ssize_t fsl_ddr_mc_inject_data_hi_show(struct device
*dev,
struct mem_ctl_info *mci = to_mci(dev);
struct fsl_ddr_mc_pdata *pdata = mci->pvt_info;
return sprintf(data, "0x%08x",
- in_be32(pdata->mc_vbase +
+ ddr_in32(pdata->mc_vbase +
MC_DATA_ERR_INJECT_HI));
}
@@ -56,7 +69,7 @@ static ssize_t fsl_ddr_mc_inject_data_lo_show(struct device
*dev,
struct mem_ctl_info *mci = to_mci(dev);
struct fsl_ddr_mc_pdata *pdata = mci->pvt_info;
return sprintf(data, "0x%08x",
- in_be32(pdata->mc_vbase +
+ ddr_in32(pdata->mc_vbase +
MC_DATA_ERR_INJECT_LO));
}
@@ -67,7 +80,7 @@ static ssize_t fsl_ddr_mc_inject_ctrl_show(struct device *dev,
struct mem_ctl_info *mci = to_mci(dev);
struct fsl_ddr_mc_pdata *pdata = mci->pvt_info;
return sprintf(data, "0x%08x",
- in_be32(pdata->mc_vbase + MC_ECC_ERR_INJECT));
+ ddr_in32(pdata->mc_vbase + MC_ECC_ERR_INJECT));
}
static ssize_t fsl_ddr_mc_inject_data_hi_store(struct device *dev,
@@ -77,7 +90,7 @@ static ssize_t fsl_ddr_mc_inject_data_hi_store(struct device
*dev,
struct mem_ctl_info *mci = to_mci(dev);
struct fsl_ddr_mc_pdata *pdata = mci->pvt_info;
if (isdigit(*data)) {
- out_be32(pdata->mc_vbase + MC_DATA_ERR_INJECT_HI,
+ ddr_out32(pdata->mc_vbase + MC_DATA_ERR_INJECT_HI,
simple_strtoul(data, NULL, 0));
return count;
}
@@ -91,7 +104,7 @@ static ssize_t fsl_ddr_mc_inject_data_lo_store(struct device
*dev,
struct mem_ctl_info *mci = to_mci(dev);
struct fsl_ddr_mc_pdata *pdata = mci->pvt_info;
if (isdigit(*data)) {
- out_be32(pdata->mc_vbase + MC_DATA_ERR_INJECT_LO,
+ ddr_out32(pdata->mc_vbase + MC_DATA_ERR_INJECT_LO,
simple_strtoul(data, NULL, 0));
return count;
}
@@ -105,7 +118,7 @@ static ssize_t fsl_ddr_mc_inject_ctrl_store(struct device
*dev,
[Patch v3 10/11] driver/edac/layerscape_edac: Add Layerscape EDAC support
Add DDR EDAC for ARM-based compatible controllers. Both big-endian
and little-endian are supported.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: Create new driver using shared DDR object
arch/arm64/Kconfig.platforms | 1 +
arch/{arm => arm64}/include/asm/edac.h | 21 +--
arch/arm64/include/asm/irq.h | 4 ++
drivers/edac/Kconfig | 7
drivers/edac/Makefile | 3 ++
drivers/edac/fsl_ddr_edac.c| 1 +
drivers/edac/layerscape_edac.c | 67 ++
7 files changed, 92 insertions(+), 12 deletions(-)
copy arch/{arm => arm64}/include/asm/edac.h (79%)
create mode 100644 drivers/edac/layerscape_edac.c
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 7ef1d05..185a215 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -41,6 +41,7 @@ config ARCH_EXYNOS
config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
+ select EDAC_SUPPORT
help
This enables support for the Freescale Layerscape SoC family.
diff --git a/arch/arm/include/asm/edac.h b/arch/arm64/include/asm/edac.h
similarity index 79%
copy from arch/arm/include/asm/edac.h
copy to arch/arm64/include/asm/edac.h
index 5189fa8..36a226c 100644
--- a/arch/arm/include/asm/edac.h
+++ b/arch/arm64/include/asm/edac.h
@@ -18,16 +18,15 @@
#define ASM_EDAC_H
/*
* ECC atomic, DMA, SMP and interrupt safe scrub function.
- * Implements the per arch edac_atomic_scrub() that EDAC use for software
+ * Implements the per arch atomic_scrub() that EDAC use for software
* ECC scrubbing. It reads memory and then writes back the original
* value, allowing the hardware to detect and correct memory errors.
*/
-
-static inline void edac_atomic_scrub(void *va, u32 size)
+static inline void atomic_scrub(void *va, u32 size)
{
-#if __LINUX_ARM_ARCH__ >= 6
- unsigned int *virt_addr = va;
- unsigned int temp, temp2;
+ unsigned long *virt_addr = va;
+ unsigned long temp;
+ unsigned int temp2;
unsigned int i;
for (i = 0; i < size / sizeof(*virt_addr); i++, virt_addr++) {
@@ -35,15 +34,13 @@ static inline void edac_atomic_scrub(void *va, u32 size)
* so we are interrupt, DMA and SMP safe.
*/
__asm__ __volatile__("\n"
- "1: ldrex %0, [%2]\n"
- " strex %1, %0, [%2]\n"
- " teq %1, #0\n"
- " bne 1b\n"
+ "1: ldxr%0, [%2]\n"
+ " stxr%w1, %0, [%2]\n"
+ " cbnz%w1, 1b\n"
: "=&r"(temp), "=&r"(temp2)
: "r"(virt_addr)
- : "cc");
+ : "memory");
}
-#endif
}
#endif
diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index b77197d..d09c008 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -11,6 +11,10 @@
#include
#include
+#ifndef NO_IRQ
+#define NO_IRQ ((unsigned int)(-1))
+#endif
+
struct pt_regs;
DECLARE_PER_CPU(unsigned long [IRQ_STACK_SIZE/sizeof(long)], irq_stack);
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 6ca7474..f1ac4e2 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -258,6 +258,13 @@ config EDAC_MPC85XX
Support for error detection and correction on the Freescale
MPC8349, MPC8560, MPC8540, MPC8548, T4240
+config EDAC_LAYERSCAPE
+ tristate "Freescale Layerscape DDR"
+ depends on EDAC_MM_EDAC && ARCH_LAYERSCAPE
+ help
+ Support for error detection and correction on Freescale memory
+ controllers on Layerscape SoCs.
+
config EDAC_MV64X60
tristate "Marvell MV64x60"
depends on EDAC_MM_EDAC && MV64X60
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index ee047a4..910dc83 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -54,6 +54,9 @@ obj-$(CONFIG_EDAC_PASEMI) += pasemi_edac.o
mpc85xx_edac_mod-y := fsl_ddr_edac.o mpc85xx_edac.o
obj-$(CONFIG_EDAC_MPC85XX) += mpc85xx_edac_mod.o
+layerscape_edac_mod-y := fsl_ddr_edac.o layerscape_edac.o
+obj-$(CONFIG_EDAC_LAYERSCAPE) += layerscape_edac_mod.o
+
obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o
obj-$(CONFIG_EDAC_CELL)+= cell_edac.o
obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o
diff --git a/drivers/edac/fsl_ddr_edac.c b/drivers/edac/fsl_ddr_edac.c
index a3fc8fe..d4b910d 100644
--- a/drivers/edac/fsl_ddr_edac.c
+++ b/drivers/edac/fsl_ddr_edac.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include "edac_module.h"
#include "edac_core.h"
#include "fsl_ddr_edac.h"
diff --git a/drivers/
[Patch v3 04/11] driver/edac/mpc85xx_edac: Replace printk with proper pr_* format
Replace printk with more preferred pr_err/pr_warn/pr_info format.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: Reordered patch. Change more printk statement than v1 patch.
drivers/edac/mpc85xx_edac.c | 72 ++---
1 file changed, 35 insertions(+), 37 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index fdc3d9b..c0b0951 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -157,18 +157,18 @@ static void mpc85xx_pci_check(struct edac_pci_ctl_info
*pci)
return;
}
- printk(KERN_ERR "PCI error(s) detected\n");
- printk(KERN_ERR "PCI/X ERR_DR register: %#08x\n", err_detect);
+ pr_err("PCI error(s) detected\n");
+ pr_err("PCI/X ERR_DR register: %#08x\n", err_detect);
- printk(KERN_ERR "PCI/X ERR_ATTRIB register: %#08x\n",
+ pr_err("PCI/X ERR_ATTRIB register: %#08x\n",
in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_ATTRIB));
- printk(KERN_ERR "PCI/X ERR_ADDR register: %#08x\n",
+ pr_err("PCI/X ERR_ADDR register: %#08x\n",
in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_ADDR));
- printk(KERN_ERR "PCI/X ERR_EXT_ADDR register: %#08x\n",
+ pr_err("PCI/X ERR_EXT_ADDR register: %#08x\n",
in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EXT_ADDR));
- printk(KERN_ERR "PCI/X ERR_DL register: %#08x\n",
+ pr_err("PCI/X ERR_DL register: %#08x\n",
in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DL));
- printk(KERN_ERR "PCI/X ERR_DH register: %#08x\n",
+ pr_err("PCI/X ERR_DH register: %#08x\n",
in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DH));
/* clear error bits */
@@ -294,7 +294,7 @@ static int mpc85xx_pci_err_probe(struct platform_device *op)
res = of_address_to_resource(of_node, 0, &r);
if (res) {
- printk(KERN_ERR "%s: Unable to get resource for "
+ pr_err("%s: Unable to get resource for "
"PCI err regs\n", __func__);
goto err;
}
@@ -304,7 +304,7 @@ static int mpc85xx_pci_err_probe(struct platform_device *op)
if (!devm_request_mem_region(&op->dev, r.start, resource_size(&r),
pdata->name)) {
- printk(KERN_ERR "%s: Error while requesting mem region\n",
+ pr_err("%s: Error while requesting mem region\n",
__func__);
res = -EBUSY;
goto err;
@@ -312,7 +312,7 @@ static int mpc85xx_pci_err_probe(struct platform_device *op)
pdata->pci_vbase = devm_ioremap(&op->dev, r.start, resource_size(&r));
if (!pdata->pci_vbase) {
- printk(KERN_ERR "%s: Unable to setup PCI err regs\n", __func__);
+ pr_err("%s: Unable to setup PCI err regs\n", __func__);
res = -ENOMEM;
goto err;
}
@@ -353,15 +353,14 @@ static int mpc85xx_pci_err_probe(struct platform_device
*op)
IRQF_SHARED,
"[EDAC] PCI err", pci);
if (res < 0) {
- printk(KERN_ERR
- "%s: Unable to request irq %d for "
+ pr_err("%s: Unable to request irq %d for "
"MPC85xx PCI err\n", __func__, pdata->irq);
irq_dispose_mapping(pdata->irq);
res = -ENODEV;
goto err2;
}
- printk(KERN_INFO EDAC_MOD_STR " acquired irq %d for PCI Err\n",
+ pr_info(EDAC_MOD_STR " acquired irq %d for PCI Err\n",
pdata->irq);
}
@@ -383,7 +382,7 @@ static int mpc85xx_pci_err_probe(struct platform_device *op)
devres_remove_group(&op->dev, mpc85xx_pci_err_probe);
edac_dbg(3, "success\n");
- printk(KERN_INFO EDAC_MOD_STR " PCI err registered\n");
+ pr_info(EDAC_MOD_STR " PCI err registered\n");
return 0;
@@ -526,17 +525,17 @@ static void mpc85xx_l2_check(struct edac_device_ctl_info
*edac_dev)
if (!(err_detect & L2_EDE_MASK))
return;
- printk(KERN_ERR "ECC Error in CPU L2 cache\n");
- printk(KERN_ERR "L2 Error Detect Register: 0x%08x\n", err_detect);
- printk(KERN_ERR "L2 Error Capture Data High Register: 0x%08x\n",
+ pr_err("ECC Error in CPU L2 cache\n");
+ pr_err("L2 Error Detect Register: 0x%08x\n", err_detect);
+ pr_err("L2 Error Capture Data High Register: 0x%08x\n",
in_be32(pdata->l2_vbase + MPC85XX_L2_CAPTDATAHI));
- printk(KERN_ERR "L2 Error Capture Data Lo Register: 0x%08x\n",
+ pr_err("L2 Error Capture Data Lo Register: 0x%08x\n",
in_be32(pdata->l2_vbase + MPC85XX_L2_CAPTDATALO));
- printk(KERN_ERR "L2 Error Syndrome Register:
[Patch v3 09/11] driver/edac/fsl_ddr: Fix kernel warning when module is removed
When compiled as a module, removing this module causes kernel
warnings when irq_dispose_mapping() is called. Instead of calling
irq_of_parse_and_map(), using platform_get_irq() to acquire the
IRQ number.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: no change
drivers/edac/fsl_ddr_edac.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/edac/fsl_ddr_edac.c b/drivers/edac/fsl_ddr_edac.c
index b1b7924..a3fc8fe 100644
--- a/drivers/edac/fsl_ddr_edac.c
+++ b/drivers/edac/fsl_ddr_edac.c
@@ -563,7 +563,7 @@ int fsl_ddr_mc_err_probe(struct platform_device *op)
ddr_out32(pdata->mc_vbase + MC_ERR_SBE, 0x1);
/* register interrupts */
- pdata->irq = irq_of_parse_and_map(op->dev.of_node, 0);
+ pdata->irq = platform_get_irq(op, 0);
res = devm_request_irq(&op->dev, pdata->irq,
fsl_ddr_mc_isr,
IRQF_SHARED,
@@ -571,7 +571,6 @@ int fsl_ddr_mc_err_probe(struct platform_device *op)
if (res < 0) {
pr_err("%s: Unable to request irq %d for FSL DDR DRAM
ERR\n",
__func__, pdata->irq);
- irq_dispose_mapping(pdata->irq);
res = -ENODEV;
goto err2;
}
@@ -603,7 +602,6 @@ int fsl_ddr_mc_err_remove(struct platform_device *op)
edac_dbg(0, "\n");
if (edac_op_state == EDAC_OPSTATE_INT) {
- irq_dispose_mapping(pdata->irq);
ddr_out32(pdata->mc_vbase + MC_ERR_INT_EN, 0);
}
--
2.7.4
