Re: [GIT PULL 00/20] phy: for 4.1 merge window
Hi Greg, On Friday 03 April 2015 09:56 PM, Kishon Vijay Abraham I wrote: Hi Greg, Please find the pull request for 4.1 merge window. This includes two new PHY driver, bug fixes and few cleanups. A patch to add MAINTAINER for miphy PHY drivers has also been included. There is also a patch that modifies stih416.dtsi to use the generic phy type constants for which I have got Acked by from the st device tree maintainer (Maxime Coquelin) and there shouldn't be conflicts when it gets merged to linus tree. Let me know if you want me to change something. Cheers Kishon The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git tags/for-4.1 Can you take this for the next merge window? Thanks Kishon for you to fetch changes up to e95cf393d2097a7744f98de1c7936fcbde0843e3: MAINTAINERS: Add phy-miphy28lp.c and phy-miphy365x.c to ARCH/STI architecture (2015-04-03 18:16:22 +0530) New Features *) Add driver for USB PHYs on sun9i *) Add driver for USB PHY on dm816x *) Modified exynos5-usbdrd driver to add support for Exynos5433 SoC Fixes = *) Fix power_on/power_off failure paths in some drivers *) Make miphy365x use generic PHY type constants *) Fix build errors due to missing export symbols in qcom-ufs driver *) Make all the functions return proper error values Cleanups *) use PTR_ERR_OR_ZERO to simplify code *) use devm_kcalloc instead of devm_kzalloc with multiply *) remove un-necessary ifdef CONFIG_OF Axel Lin (15): phy: berlin-usb: Use PTR_ERR_OR_ZERO phy: xgene: Use PTR_ERR_OR_ZERO phy: berlin-sata: Use devm_kcalloc at appropriate place phy: miphy28lp: Use PTR_ERR_OR_ZERO phy: omap-control: Remove unneeded ifdef CONFIG_OF guard and of_match_ptr phy: omap-usb2: Remove unneeded ifdef CONFIG_OF guard and of_match_ptr phy: ti-pipe3: Remove unneeded ifdef CONFIG_OF guard and of_match_ptr phy: berlin-usb: Set drvdata for phy and use it phy: stih41x-usb: Fixup stih41x_usb_phy_power_on failure path phy: qcom-ufs: Catch devm_phy_create failure in ufs_qcom_phy_generic_probe phy: samsung_usb2: Fixup samsung_usb2_phy_power_on/off paths phy: qcom-ufs: Fix build error due to missing export symbols phy: samsung_usb2: Fixup samsung_usb2_phy_power_on/off paths phy: qcom-ufs: Fix build error due to missing export symbols phy: qcom-ufs: Don't return error if fail to get optional resource phy: spear1310-miphy: Return proper error for spear1310_miphy_xlate phy: spear1340-miphy: Return proper error for spear1340_miphy_xlate Chen-Yu Tsai (1): phy: Add driver to support individual USB PHYs on sun9i Jaewon Kim (1): phy: exynos5-usbdrd: Add to support for Exynos5433 SoC Peter Griffin (2): phy: miphy365x: Use the generic phy type constants in dt-bindings/phy/phy.h MAINTAINERS: Add phy-miphy28lp.c and phy-miphy365x.c to ARCH/STI architecture Tony Lindgren (1): phy: Add a driver for dm816x USB PHY .../devicetree/bindings/phy/dm816x-phy.txt | 24 ++ .../devicetree/bindings/phy/phy-miphy365x.txt |8 +- .../devicetree/bindings/phy/samsung-phy.txt|3 +- .../devicetree/bindings/phy/sun9i-usb-phy.txt | 38 +++ MAINTAINERS|2 + arch/arm/boot/dts/stih416.dtsi |4 +- drivers/phy/Kconfig| 18 ++ drivers/phy/Makefile |2 + drivers/phy/phy-berlin-sata.c |2 +- drivers/phy/phy-berlin-usb.c | 19 +- drivers/phy/phy-dm816x-usb.c | 290 drivers/phy/phy-exynos5-usbdrd.c | 10 + drivers/phy/phy-miphy28lp.c|5 +- drivers/phy/phy-miphy365x.c| 14 +- drivers/phy/phy-omap-control.c | 10 +- drivers/phy/phy-omap-usb2.c|6 +- drivers/phy/phy-qcom-ufs.c | 33 +-- drivers/phy/phy-samsung-usb2.c | 10 +- drivers/phy/phy-spear1310-miphy.c |4 +- drivers/phy/phy-spear1340-miphy.c |4 +- drivers/phy/phy-stih41x-usb.c |8 +- drivers/phy/phy-sun9i-usb.c| 202 ++ drivers/phy/phy-ti-pipe3.c |9 +- drivers/phy/phy-xgene.c| 23 +- include/dt-bindings/phy/phy-miphy365x.h| 14 - include/linux/mfd/syscon/exynos5-pmu.h |3 + 26
[PATCH -next] xtensa: Fix fix linker script transformation for .text / .text.fixup
Commit 779c88c94c34 ("ARM: 8321/1: asm-generic: introduce .text.fixup
input section") introduced a new .text.fixup section which is merged
with .text at link time. This causes xtensa builds to fail with lots
of error messages similar to the following.
lib/lib.a(kobject.o): In function `kobject_create':
(.text+0x498): dangerous relocation: l32r: literal placed after use:
(.literal+0x150)
Linker script transformation needs to be updated to detect and handle
the new section.
Fixes: 779c88c94c34 ("ARM: 8321/1: asm-generic: introduce .text.fixup
input section")
Cc: Ard Biesheuvel
Cc: Arnd Bergmann
Signed-off-by: Guenter Roeck
---
arch/xtensa/kernel/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/xtensa/kernel/Makefile b/arch/xtensa/kernel/Makefile
index 18d962a..d3a0f0f 100644
--- a/arch/xtensa/kernel/Makefile
+++ b/arch/xtensa/kernel/Makefile
@@ -29,6 +29,7 @@ AFLAGS_head.o += -mtext-section-literals
sed-y = -e 's/\*(\(\.[a-z]*it\|\.ref\|\)\.text)/*(\1.literal \1.text)/g' \
-e 's/\.text\.unlikely/.literal.unlikely .text.unlikely/g' \
+ -e 's/\*(\(\.text .*\))/*(.literal \1)/g'\
-e 's/\*(\(\.text\.[a-z]*\))/*(\1.literal \1)/g'
quiet_cmd__cpp_lds_S = LDS $@
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugfix v3] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716
On 2015/4/7 8:28, Rafael J. Wysocki wrote:
> On Friday, April 03, 2015 10:04:11 PM Bjorn Helgaas wrote:
>> Hi Jiang,
>>> Currently acpi_dev_filter_resource_type() is only used by ACPI pci
>>> host bridge and IOAPIC driver, so it shouldn't affect other drivers.
>>
>> We should assume it will eventually be used for all ACPI devices,
>> shouldn't we?
>
> I'm not sure about that, really. In fact, I'd restrict its use to devices
> types that actually can "produce" resources (ie. do not require the resources
> to be provided by their ancestors or to be available from a global pool).
>
> Otherwise we're pretty much guaranteed to get into trouble.
>
> And all of the above rules need to be documented in the kernel source tree
> or people will get confused.
Hi Rafael,
How about following comments for acpi_dev_filter_resource_type()?
Thanks!
Gerry
/**
* According to ACPI specifications, Consumer/Producer flag in ACPI resource
* descriptor means:
* 1(CONSUMER): This device consumes this resource
* 0(PRODUCER): This device produces and consumes this resource
* But for ACPI PCI host bridge, it is interpreted in another way:
* 1(CONSUMER): PCI host bridge itself consumes the resource, such as
* IOPORT 0xCF8-0xCFF to access PCI configuraiton space.
* 0(PRODUCER): PCI host bridge provides this resource to its child
* bus and devices.
*
* So this is a specially designed helper function to support ACPI PCI host
* bridge and ACPI IOAPIC, and its usage should be limited to those specific
* scenarioso only. It filters ACPI resource descriptors as below:
* 1) If flag IORESOURCE_WINDOW is not specified, it's querying resources
*consumed by device. That is to return:
* a) ACPI resources without producer_consumer flag
* b) ACPI resources with producer_consumer flag setting to CONSUMER.
* 2) If flag IORESOURCE_WINDOW is specified, it's querying resources
provided
*by device. That is to return:
* a) ACPI resources with producer_consumer flag setting to PRODUCER.
* 3) But there's an exception. Some platforms, such as PC Engines APU.1C,
*report PCI host bridge resource provision by Memory32Fixed().
*Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=94221
*So a special flag IORESOURCE_MEM_8AND16BIT is used to work around this
*BIOS issue.
*/
>
>>> Another possible fix is to only ignore IO resource consumed by host
>>> bridge and keep IOMEM resource consumed by host bridge, please refer to:
>>> http://www.spinics.net/lists/linux-pci/msg39706.html
>>>
>>> Sample ACPI table are archived at:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=94221
>>>
>>> V2->V3:
>>> Refine function acpi_dev_match_producer_consumer() as suggested by Rafael
>>>
>>> Fixes: 63f1789ec716("Ignore resources consumed by host bridge itself")
>>> Reported-and-Tested-by: Bernhard Thaler
>>> Signed-off-by: Jiang Liu
>>> ---
>>> arch/x86/pci/acpi.c |5 ++---
>>> drivers/acpi/resource.c | 33 +
>>> 2 files changed, 31 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
>>> index e4695985f9de..8c4b1201f340 100644
>>> --- a/arch/x86/pci/acpi.c
>>> +++ b/arch/x86/pci/acpi.c
>>> @@ -337,7 +337,7 @@ static void probe_pci_root_info(struct pci_root_info
>>> *info,
>>> info->bridge = device;
>>> ret = acpi_dev_get_resources(device, list,
>>> acpi_dev_filter_resource_type_cb,
>>> -(void *)(IORESOURCE_IO | IORESOURCE_MEM));
>>> +(void *)(IORESOURCE_IO | IORESOURCE_MEM |
>>> IORESOURCE_WINDOW));
>>> if (ret < 0)
>>> dev_warn(>dev,
>>> "failed to parse _CRS method, error code %d\n", ret);
>>> @@ -346,8 +346,7 @@ static void probe_pci_root_info(struct pci_root_info
>>> *info,
>>> "no IO and memory resources present in _CRS\n");
>>> else
>>> resource_list_for_each_entry_safe(entry, tmp, list) {
>>> - if ((entry->res->flags & IORESOURCE_WINDOW) == 0 ||
>>> - (entry->res->flags & IORESOURCE_DISABLED))
>>> + if (entry->res->flags & IORESOURCE_DISABLED)
>>> resource_list_destroy_entry(entry);
>>> else
>>> entry->res->name = info->name;
>>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>>> index 5589a6e2a023..e761a868bdba 100644
>>> --- a/drivers/acpi/resource.c
>>> +++ b/drivers/acpi/resource.c
>>> @@ -567,6 +567,12 @@ int acpi_dev_get_resources(struct acpi_device *adev,
>>> struct list_head *list,
>>> }
>>> EXPORT_SYMBOL_GPL(acpi_dev_get_resources);
>>>
>>> +static bool acpi_dev_match_producer_consumer(unsigned long types, int
>>> producer)
>>> +{
>>> + return
Re: [PATCH 00/20] mpt3sas: driver update
Hi Chris, There are no corresponding mpt2sas driver's patches, The last phase for mpt2sas drivers is Phase20 and this phase driver is already exits in the upstream kernel. Also mpt2sas driver is completely in maintains mode and there won't be any new features. Whereas mpt3sas is at its initial baseline with a healthy road map ahead and also we are planning to use same mpt3sas driver for next upcoming Avago IT HBA's. So merging mpt2sas driver with mpt3sas driver may break mpt2sas driver functionality in future, also it will be over head of the maintainer to always check for the backward compatibility of merged driver with the mpt2sas driver. Regards, Sreekanth On Sun, Apr 5, 2015 at 9:39 PM, Christoph Hellwig wrote: > This seems to be missing the corresponding mpt2 updates. Nak to > anything that gets these drivers further out of sync. > > Btw, I still need a second ACK for > http://www.spinics.net/lists/linux-scsi/msg82027.html > as well, so we can start getting rid of this duplication mess. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] if_link: Add VF multicast promiscuous control
From: Hiroshi Shimamoto
Add netlink directives and ndo entry to allow VF multicast promiscuous mode.
This controls the permission to enter VF multicast promiscuous mode.
The administrator will dedicatedly allow multicast promiscuous per VF.
When the VF is under multicast promiscuous mode, all multicast packets are
sent to the VF.
Don't allow VF multicast promiscuous if the VM isn't fully trusted.
Signed-off-by: Hiroshi Shimamoto
Reviewed-by: Hayato Momma
CC: Choi, Sy Jong
---
include/linux/if_link.h | 1 +
include/linux/netdevice.h| 3 +++
include/uapi/linux/if_link.h | 6 ++
net/core/rtnetlink.c | 19 +--
4 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index da49299..df212f4 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -15,5 +15,6 @@ struct ifla_vf_info {
__u32 min_tx_rate;
__u32 max_tx_rate;
__u32 rss_query_en;
+ __u32 mc_promisc;
};
#endif /* _LINUX_IF_LINK_H */
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index fc4da22..a444e1d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -873,6 +873,7 @@ typedef u16 (*select_queue_fallback_t)(struct net_device
*dev,
* int (*ndo_set_vf_rate)(struct net_device *dev, int vf, int min_tx_rate,
* int max_tx_rate);
* int (*ndo_set_vf_spoofchk)(struct net_device *dev, int vf, bool setting);
+ * int (*ndo_set_vf_mc_promisc)(struct net_device *dev, int vf, bool setting);
* int (*ndo_get_vf_config)(struct net_device *dev,
* int vf, struct ifla_vf_info *ivf);
* int (*ndo_set_vf_link_state)(struct net_device *dev, int vf, int
link_state);
@@ -1094,6 +1095,8 @@ struct net_device_ops {
int max_tx_rate);
int (*ndo_set_vf_spoofchk)(struct net_device *dev,
int vf, bool setting);
+ int (*ndo_set_vf_mc_promisc)(struct net_device *dev,
+int vf, bool setting);
int (*ndo_get_vf_config)(struct net_device *dev,
int vf,
struct ifla_vf_info *ivf);
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index d9cd192..44c3bbe 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -468,6 +468,7 @@ enum {
IFLA_VF_RSS_QUERY_EN, /* RSS Redirection Table and Hash Key query
* on/off switch
*/
+ IFLA_VF_MC_PROMISC, /* Multicast Promiscuous allow/disallow */
__IFLA_VF_MAX,
};
@@ -517,6 +518,11 @@ struct ifla_vf_rss_query_en {
__u32 setting;
};
+struct ifla_vf_mc_promisc {
+ __u32 vf;
+ __u32 setting;
+};
+
/* VF ports management section
*
* Nested layout of set/get msg is:
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 74431d6..f247bf2 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -819,7 +819,8 @@ static inline int rtnl_vfinfo_size(const struct net_device
*dev,
nla_total_size(sizeof(struct ifla_vf_spoofchk)) +
nla_total_size(sizeof(struct ifla_vf_rate)) +
nla_total_size(sizeof(struct ifla_vf_link_state)) +
-nla_total_size(sizeof(struct ifla_vf_rss_query_en)));
+nla_total_size(sizeof(struct ifla_vf_rss_query_en)) +
+nla_total_size(sizeof(struct ifla_vf_mc_promisc)));
return size;
} else
return 0;
@@ -1134,6 +1135,7 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct
net_device *dev,
struct ifla_vf_spoofchk vf_spoofchk;
struct ifla_vf_link_state vf_linkstate;
struct ifla_vf_rss_query_en vf_rss_query_en;
+ struct ifla_vf_mc_promisc vf_mc_promisc;
/*
* Not all SR-IOV capable drivers support the
@@ -1143,6 +1145,7 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct
net_device *dev,
*/
ivi.spoofchk = -1;
ivi.rss_query_en = -1;
+ ivi.mc_promisc = -1;
memset(ivi.mac, 0, sizeof(ivi.mac));
/* The default value for VF link state is "auto"
* IFLA_VF_LINK_STATE_AUTO which equals zero
@@ -1156,7 +1159,8 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct
net_device *dev,
vf_tx_rate.vf =
vf_spoofchk.vf =
[PATCH v3 3/3] ixgbe: Add new ndo to allow VF multicast promiscuous mode
From: Hiroshi Shimamoto
Implements the new netdev op to allow VF multicast promiscuous mode.
The multicast promiscuous mode is not allowed for all VFs by default.
The administrator can allow to VF multicast promiscuous mode for only
trusted VM. After allowing multicast promiscuous mode from the host,
we can use over 30 IPv6 addresses on VM.
# ip link set dev eth0 vf 1 mc_promisc on
When disallowing multicast promiscuous mode, ixgbevf can only handle 30
IPv6 addresses at most.
# ip link set dev eth0 vf 1 mc_promisc off
Signed-off-by: Hiroshi Shimamoto
Reviewed-by: Hayato Momma
CC: Choi, Sy Jong
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 32 --
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 2 ++
4 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 08e65b6..4a9f74d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -153,6 +153,7 @@ struct vf_data_storage {
u16 vlan_count;
u8 spoofchk_enabled;
bool rss_query_enabled;
+ u8 mc_promisc_allowed;
unsigned int vf_api;
};
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2f41403..c0e07c5 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -3663,6 +3663,12 @@ static void ixgbe_configure_virtualization(struct
ixgbe_adapter *adapter)
ixgbe_ndo_set_vf_rss_query_en(adapter->netdev, i,
adapter->vfinfo[i].rss_query_enabled);
}
+
+ /* Reconfigure multicast promiscuous mode */
+ for (i = 0; i < adapter->num_vfs; i++) {
+ ixgbe_ndo_set_vf_mc_promisc(adapter->netdev, i,
+ adapter->vfinfo[i].mc_promisc_allowed);
+ }
}
static void ixgbe_set_rx_buffer_len(struct ixgbe_adapter *adapter)
@@ -8165,6 +8171,7 @@ static const struct net_device_ops ixgbe_netdev_ops = {
.ndo_set_vf_rate= ixgbe_ndo_set_vf_bw,
.ndo_set_vf_spoofchk= ixgbe_ndo_set_vf_spoofchk,
.ndo_set_vf_rss_query_en = ixgbe_ndo_set_vf_rss_query_en,
+ .ndo_set_vf_mc_promisc = ixgbe_ndo_set_vf_mc_promisc,
.ndo_get_vf_config = ixgbe_ndo_get_vf_config,
.ndo_get_stats64= ixgbe_get_stats64,
#ifdef CONFIG_IXGBE_DCB
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 615f651..42b24a0 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -117,8 +117,11 @@ static int __ixgbe_enable_sriov(struct ixgbe_adapter
*adapter)
*/
adapter->vfinfo[i].rss_query_enabled = 0;
- /* Turn multicast promiscuous mode off for all VFs */
+ /* Disallow VF multicast promiscuous capability
+* and turn it off for all VFs
+*/
adapter->vfinfo[i].mc_promisc = false;
+ adapter->vfinfo[i].mc_promisc_allowed = false;
}
return 0;
@@ -1068,7 +1071,7 @@ static int ixgbe_set_vf_mc_promisc(struct ixgbe_adapter
*adapter,
adapter->vfinfo[vf].mc_promisc = enable;
- if (enable)
+ if (enable && adapter->vfinfo[vf].mc_promisc_allowed)
return ixgbe_enable_vf_mc_promisc(adapter, vf);
else
return ixgbe_disable_vf_mc_promisc(adapter, vf);
@@ -1492,6 +1495,30 @@ int ixgbe_ndo_set_vf_rss_query_en(struct net_device
*netdev, int vf,
return 0;
}
+int ixgbe_ndo_set_vf_mc_promisc(struct net_device *netdev, int vf, bool
setting)
+{
+ struct ixgbe_adapter *adapter = netdev_priv(netdev);
+
+ if (vf >= adapter->num_vfs)
+ return -EINVAL;
+
+ /* nothing to do */
+ if (adapter->vfinfo[vf].mc_promisc_allowed == setting)
+ return 0;
+
+ adapter->vfinfo[vf].mc_promisc_allowed = setting;
+
+ /* if VF requests multicast promiscuous */
+ if (adapter->vfinfo[vf].mc_promisc) {
+ if (setting)
+ ixgbe_enable_vf_mc_promisc(adapter, vf);
+ else
+ ixgbe_disable_vf_mc_promisc(adapter, vf);
+ }
+
+ return 0;
+}
+
int ixgbe_ndo_get_vf_config(struct net_device *netdev,
int vf, struct ifla_vf_info *ivi)
{
@@ -1506,5 +1533,6 @@ int ixgbe_ndo_get_vf_config(struct net_device *netdev,
ivi->qos = adapter->vfinfo[vf].pf_qos;
ivi->spoofchk = adapter->vfinfo[vf].spoofchk_enabled;
ivi->rss_query_en =
[PATCH v3 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
From: Hiroshi Shimamoto
The limitation of the number of multicast address for VF is not enough
for the large scale server with SR-IOV feature.
IPv6 requires the multicast MAC address for each IP address to handle
the Neighbor Solicitation message.
We couldn't assign over 30 IPv6 addresses to a single VF interface.
The easy way to solve this is enabling multicast promiscuous mode.
It is good to have a functionality to enable multicast promiscuous mode
for each VF from VF driver.
This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to
enable/disable multicast promiscuous mode in VF. If multicast
promiscuous mode is enabled the VF can receive all multicast packets.
With this patch, the ixgbevf driver automatically enable multicast
promiscuous mode when the number of multicast addresses is over than 30
if possible.
Signed-off-by: Hiroshi Shimamoto
Reviewed-by: Hayato Momma
CC: Choi, Sy Jong
---
This adds new mbox API, but doesn't change the version because
v1.3 was newly added in the current dev-queue.
Is that okay, or shall I increment the version?
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c| 76 +++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 3 +
drivers/net/ethernet/intel/ixgbevf/mbx.h | 2 +
drivers/net/ethernet/intel/ixgbevf/vf.c | 27 +++-
drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
7 files changed, 111 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 636f9e3..08e65b6 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -146,6 +146,7 @@ struct vf_data_storage {
u16 vlans_enabled;
bool clear_to_send;
bool pf_set_mac;
+ bool mc_promisc;
u16 pf_vlan; /* When set, guest VLAN config not allowed. */
u16 pf_qos;
u16 tx_rate;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
index b1e4703..dd623ca 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
@@ -102,6 +102,8 @@ enum ixgbe_pfvf_api_rev {
#define IXGBE_VF_GET_RETA 0x0a/* VF request for RETA */
#define IXGBE_VF_GET_RSS_KEY 0x0b/* get RSS key */
+#define IXGBE_VF_SET_MC_PROMISC0x0c/* VF requests PF to set MC
promiscuous */
+
/* length of permanent address message returned from PF */
#define IXGBE_VF_PERMADDR_MSG_LEN 4
/* word in permanent address message with the current multicast type */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 1d17b58..615f651 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -116,6 +116,9 @@ static int __ixgbe_enable_sriov(struct ixgbe_adapter
*adapter)
* we want to disable the querying by default.
*/
adapter->vfinfo[i].rss_query_enabled = 0;
+
+ /* Turn multicast promiscuous mode off for all VFs */
+ adapter->vfinfo[i].mc_promisc = false;
}
return 0;
@@ -318,6 +321,40 @@ int ixgbe_pci_sriov_configure(struct pci_dev *dev, int
num_vfs)
return ixgbe_pci_sriov_enable(dev, num_vfs);
}
+static int ixgbe_enable_vf_mc_promisc(struct ixgbe_adapter *adapter, u32 vf)
+{
+ struct ixgbe_hw *hw;
+ u32 vmolr;
+
+ hw = >hw;
+ vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+
+ e_info(drv, "VF %u: enabling multicast promiscuous\n", vf);
+
+ vmolr |= IXGBE_VMOLR_MPE;
+
+ IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
+
+ return 0;
+}
+
+static int ixgbe_disable_vf_mc_promisc(struct ixgbe_adapter *adapter, u32 vf)
+{
+ struct ixgbe_hw *hw;
+ u32 vmolr;
+
+ hw = >hw;
+ vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+
+ e_info(drv, "VF %u: disabling multicast promiscuous\n", vf);
+
+ vmolr &= ~IXGBE_VMOLR_MPE;
+
+ IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
+
+ return 0;
+}
+
static int ixgbe_set_vf_multicasts(struct ixgbe_adapter *adapter,
u32 *msgbuf, u32 vf)
{
@@ -332,6 +369,12 @@ static int ixgbe_set_vf_multicasts(struct ixgbe_adapter
*adapter,
u32 mta_reg;
u32 vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+ /* Disable multicast promiscuous first */
+ if (adapter->vfinfo[vf].mc_promisc) {
+ ixgbe_disable_vf_mc_promisc(adapter, vf);
+ adapter->vfinfo[vf].mc_promisc = false;
+ }
+
/* only so many hash values supported */
entries = min(entries, IXGBE_MAX_VF_MC_ENTRIES);
@@ -718,6 +761,12 @@ static int
Re: [PATCH] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in of parsing
On Tue, Apr 7, 2015 at 8:49 PM, Benjamin Herrenschmidt wrote: > On Tue, 2015-04-07 at 17:24 -0700, Yinghai Lu wrote: >> For device resource PREF bit setting under bridge 64-bit pref resource, >> we need to make sure only set PREF for 64bit resource, so set >> IORESOUCE_MEM_64 >> for 64bit resource during of device resource flags parsing. > >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241 > > These patches (from the above BZ) aren't right for one thing: You > shouldn't set the IORESOURCE_PREFETCH in the resource itself. This > *will* break stuff. > > You can put the resource in a prefetchable region indeed, if you > are on a PCIe-only path (though we should have some arch flag > to check that the host bridge indeed doesn't do any prefetch, > on powerpc we are good there). The patch is at: http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=for-linus=1a3ec5e7b00dcd9cac24efe3d65bfccf82597ce5 and we limit to set pref bit for pcie end devices mmio 64bit resource. > > But you can't set the "prefetch" bit on the resource because that would > be losing the indication that this resource has side effects. This bit > is used in some cases to enable store gathering when mmap'ing via sysfs > and can be used for similar uses by drivers. Any pointer for that? > > It's one thing to say "you can put non-prefetch BARs in prefetch windows > on that path", it's another one to completely make the BAR looks like > it's prefetchable when it's not. Too hard for me to tell the difference. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hello Tomasz, On 04/07/2015 11:28 PM, Tomasz Figa wrote: > > Looks good to me. You can consider this Acked-by, as long as Sylwester > is not opposed to this approach. > Thanks a lot, I've posted it as a proper patch now. > Best regards, > Tomasz > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Btrfs: show subvol= and subvolid= in /proc/mounts
Currently, userspace has no way to know which subvolume is mounted. But,
now that we're guaranteed to have a meaningful root dentry, we can just
export and use seq_dentry() in btrfs_show_options(). The subvolume ID is
easy to get, so put that in there, too.
Signed-off-by: Omar Sandoval
---
fs/btrfs/super.c | 4
fs/seq_file.c| 1 +
2 files changed, 5 insertions(+)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 5ab9801..5e14bb6 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1193,6 +1193,10 @@ static int btrfs_show_options(struct seq_file *seq,
struct dentry *dentry)
seq_puts(seq, ",fatal_errors=panic");
if (info->commit_interval != BTRFS_DEFAULT_COMMIT_INTERVAL)
seq_printf(seq, ",commit=%d", info->commit_interval);
+ seq_puts(seq, ",subvol=");
+ seq_dentry(seq, dentry, " \t\n\\");
+ seq_printf(seq, ",subvolid=%llu",
+ BTRFS_I(d_inode(dentry))->root->root_key.objectid);
return 0;
}
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 555f821..52b4927 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -538,6 +538,7 @@ int seq_dentry(struct seq_file *m, struct dentry *dentry,
const char *esc)
return res;
}
+EXPORT_SYMBOL(seq_dentry);
static void *single_start(struct seq_file *p, loff_t *pos)
{
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Btrfs: show subvolume name and ID in /proc/mounts
So this is something that has bothered me as a Btrfs user for some time
and that came up in discussing a separate bug here:
https://lkml.org/lkml/2015/4/2/447.
It turns out that getting the name of a subvolume reliably is a bit
trickier than it would seem because of how mounting subvolumes by ID is
implemented. In particular, in that case, the dentry we get for the root
of the mount is not necessarily attached to the dentry tree, which means
that the obvious solution of just dumping the dentry does not work. The
solution I put together makes the tradeoff of churning a bit more code
in order to avoid implementing this with weird hacks.
Patch 1 is a bug fix that I came across during testing. Because it would
conflict with merging patch 2, I'm including it here.
Patch 2 is the big one: it makes mounts by subvolid work the same way as
mounts by subvol name by looking up the name for a subvolid from the
root backrefs and inode refs. It comes with the added benefit of making
subvolume mounts share the same codepath regardless of the method.
Patch 3 is really simple thanks to patch 2: the obvious change to
btrfs_show_options() works now.
This series applies to v4.0-rc7. I've tested it manually and with the
script below. Thank you!
Omar Sandoval (3):
Btrfs: lock superblock before remounting for rw subvol
Btrfs: unify subvol= and subvolid= mounting
Btrfs: show subvol= and subvolid= in /proc/mounts
fs/btrfs/super.c | 353 ---
fs/seq_file.c| 1 +
2 files changed, 232 insertions(+), 122 deletions(-)
Testing script:
#!/bin/sh
set -e
check_subvol () {
NAME="$1"
ID="$2"
# Mount by name.
mount -osubvol="$NAME" /dev/vdb /mnt
if ! grep vdb /proc/mounts | grep ",subvol=$NAME,subvolid=$ID"; then
echo "Failed $NAME" >&2
exit 1
fi
umount /mnt
# Mount by ID.
mount -osubvolid="$ID" /dev/vdb /mnt
if ! grep vdb /proc/mounts | grep ",subvol=$NAME,subvolid=$ID"; then
echo "Failed $ID" >&2
exit 1
fi
umount /mnt
}
check_default_subvol () {
NAME="$1"
ID="$2"
mount /dev/vdb /mnt
if ! grep vdb /proc/mounts | grep ",subvol=$NAME,subvolid=$ID"; then
echo "Failed default" >&2
exit 1
fi
umount /mnt
}
mkfs.btrfs -f /dev/vdb
mount /dev/vdb /mnt
btrfs subvolume create /mnt/vol
btrfs subvolume create /mnt/vol/nestedvol
mkdir /mnt/dir
btrfs subvolume create /mnt/dir/dirvol
btrfs subvolume create /mnt/dir/dirvol/nesteddirvol
mkdir /mnt/vol/voldir
btrfs subvolume create /mnt/vol/voldir/voldirvol
btrfs subvolume list /mnt
umount /mnt
check_subvol /vol 257
check_subvol /vol/nestedvol 258
check_subvol /dir/dirvol 259
check_subvol /dir/dirvol/nesteddirvol 260
check_subvol /vol/voldir/voldirvol 261
check_default_subvol / 5
mount /dev/vdb /mnt
btrfs subvolume set-default 257 /mnt
umount /mnt
check_default_subvol /vol 257
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] clk: exynos5420: Restore GATE_BUS_TOP on suspend
Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this in turn makes its parent clock aclk266_g2d to
be gated. But the clock needs to be ungated prior suspend to allow the
system to be suspend and resumed correctly.
Add GATE_BUS_TOP register to the list of registers to be restored when
the system enters into a suspend state so aclk266_g2d will be ungated.
Thanks to Abhilash Kesavan for figuring out that this was the issue.
Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management
support v12")
Signed-off-by: Javier Martinez Canillas
Tested-by: Kevin Hilman
Tested-by: Abhilash Kesavan
Acked-by: Tomasz Figa
---
drivers/clk/samsung/clk-exynos5420.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 07d666cc6a29..bea4a173eef5 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump
exynos5420_set_clksrc[] = {
{ .offset = SRC_MASK_PERIC0,.value = 0x1110, },
{ .offset = SRC_MASK_PERIC1,.value = 0x1100, },
{ .offset = SRC_MASK_ISP, .value = 0x1000, },
+ { .offset = GATE_BUS_TOP, .value = 0x, },
{ .offset = GATE_BUS_DISP1, .value = 0x, },
{ .offset = GATE_IP_PERIC, .value = 0x, },
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Btrfs: lock superblock before remounting for rw subvol
Since commit 0723a0473fb4 ("btrfs: allow mounting btrfs subvolumes with
different ro/rw options"), when mounting a subvolume read/write when
another subvolume has previously been mounted read-only, we first do a
remount. However, this should be done with the superblock locked, as per
sync_filesystem():
/*
* We need to be protected against the filesystem going from
* r/o to r/w or vice versa.
*/
WARN_ON(!rwsem_is_locked(>s_umount));
This WARN_ON can easily be hit with:
mkfs.btrfs -f /dev/vdb
mount /dev/vdb /mnt
btrfs subvol create /mnt/vol1
btrfs subvol create /mnt/vol2
umount /mnt
mount -oro,subvol=/vol1 /dev/vdb /mnt
mount -orw,subvol=/vol2 /dev/vdb /mnt2
Fixes: 0723a0473fb4
Signed-off-by: Omar Sandoval
---
fs/btrfs/super.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 05fef19..d38be09 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1205,7 +1205,9 @@ static struct dentry *mount_subvol(const char
*subvol_name, int flags,
return ERR_CAST(mnt);
}
+ down_write(>mnt_sb->s_umount);
r = btrfs_remount(mnt->mnt_sb, , NULL);
+ up_write(>mnt_sb->s_umount);
if (r < 0) {
/* FIXME: release vfsmount mnt ??*/
kfree(newargs);
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
Currently, mounting a subvolume with subvolid= takes a different code
path than mounting with subvol=. This isn't really a big deal except for
the fact that mounts done with subvolid= or the default subvolume don't
have a dentry that's connected to the dentry tree like in the subvol=
case. To unify the code paths, when given subvolid= or using the default
subvolume ID, translate it into a subvolume name by walking
ROOT_BACKREFs in the root tree and INODE_REFs in the filesystem trees.
Signed-off-by: Omar Sandoval
---
fs/btrfs/super.c | 347 ---
1 file changed, 225 insertions(+), 122 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index d38be09..5ab9801 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -841,33 +841,153 @@ out:
return error;
}
-static struct dentry *get_default_root(struct super_block *sb,
- u64 subvol_objectid)
+static char *get_subvol_name_from_objectid(struct btrfs_fs_info *fs_info,
+ u64 subvol_objectid)
{
- struct btrfs_fs_info *fs_info = btrfs_sb(sb);
struct btrfs_root *root = fs_info->tree_root;
- struct btrfs_root *new_root;
- struct btrfs_dir_item *di;
- struct btrfs_path *path;
- struct btrfs_key location;
- struct inode *inode;
- u64 dir_id;
- int new = 0;
+ struct btrfs_root *fs_root;
+ struct btrfs_root_ref *root_ref;
+ struct btrfs_inode_ref *inode_ref;
+ struct btrfs_key key;
+ struct btrfs_path *path = NULL;
+ char *name = NULL, *ptr;
+ u64 dirid;
+ int len;
+ int ret;
+
+ path = btrfs_alloc_path();
+ if (!path) {
+ ret = -ENOMEM;
+ goto err;
+ }
+ path->leave_spinning = 1;
+
+ name = kmalloc(PATH_MAX, GFP_NOFS);
+ if (!name) {
+ ret = -ENOMEM;
+ goto err;
+ }
+ ptr = name + PATH_MAX - 1;
+ ptr[0] = '\0';
/*
-* We have a specific subvol we want to mount, just setup location and
-* go look up the root.
+* Walk up the subvolume trees in the tree of tree roots by root
+* backrefs until we hit the top-level subvolume.
*/
- if (subvol_objectid) {
- location.objectid = subvol_objectid;
- location.type = BTRFS_ROOT_ITEM_KEY;
- location.offset = (u64)-1;
- goto find_root;
+ while (subvol_objectid != BTRFS_FS_TREE_OBJECTID) {
+ key.objectid = subvol_objectid;
+ key.type = BTRFS_ROOT_BACKREF_KEY;
+ key.offset = (u64)-1;
+
+ ret = btrfs_search_slot(NULL, root, , path, 0, 0);
+ if (ret < 0) {
+ goto err;
+ } else if (ret > 0) {
+ ret = btrfs_previous_item(root, path, subvol_objectid,
+ BTRFS_ROOT_BACKREF_KEY);
+ if (ret < 0) {
+ goto err;
+ } else if (ret > 0) {
+ ret = -ENOENT;
+ goto err;
+ }
+ }
+
+ btrfs_item_key_to_cpu(path->nodes[0], , path->slots[0]);
+ subvol_objectid = key.offset;
+
+ root_ref = btrfs_item_ptr(path->nodes[0], path->slots[0],
+ struct btrfs_root_ref);
+ len = btrfs_root_ref_name_len(path->nodes[0], root_ref);
+ ptr -= len + 1;
+ if (ptr < name) {
+ ret = -ENAMETOOLONG;
+ goto err;
+ }
+ read_extent_buffer(path->nodes[0], ptr + 1,
+ (unsigned long)(root_ref + 1), len);
+ ptr[0] = '/';
+ dirid = btrfs_root_ref_dirid(path->nodes[0], root_ref);
+ btrfs_release_path(path);
+
+ key.objectid = subvol_objectid;
+ key.type = BTRFS_ROOT_ITEM_KEY;
+ key.offset = (u64)-1;
+ fs_root = btrfs_read_fs_root_no_name(fs_info, );
+ if (IS_ERR(fs_root)) {
+ ret = PTR_ERR(fs_root);
+ goto err;
+ }
+
+ /*
+* Walk up the filesystem tree by inode refs until we hit the
+* root directory.
+*/
+ while (dirid != BTRFS_FIRST_FREE_OBJECTID) {
+ key.objectid = dirid;
+ key.type = BTRFS_INODE_REF_KEY;
+ key.offset = (u64)-1;
+
+ ret = btrfs_search_slot(NULL, fs_root, , path, 0,
0);
+ if (ret < 0) {
+ goto err;
+ } else if (ret > 0) {
+
RE: [PATCH V2 2/6] i2c: qup: Add V2 tags support
Hi Andy,
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Andy Gross
> Sent: Tuesday, April 07, 2015 10:37 AM
> To: Sricharan R
> Cc: srich...@qti.qualcomm.com; devicet...@vger.kernel.org; linux-arm-
> m...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> i...@vger.kernel.org; iiva...@mm-sol.com; ga...@codeaurora.org;
> dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH V2 2/6] i2c: qup: Add V2 tags support
>
> On Tue, Apr 07, 2015 at 12:01:03AM +0530, Sricharan R wrote:
>
>
>
> > +static u32 qup_i2c_send_data(struct qup_i2c_dev *qup, int tlen, u8
*tbuf,
> > +int dlen, u8 *dbuf)
> > +{
> > + u32 val = 0, idx = 0, pos = 0, i = 0, t;
> > + int len = tlen + dlen;
> > + u8 *buf = tbuf;
> > +
> > + while (len > 0) {
> > + if (qup_i2c_wait_ready(qup, QUP_OUT_FULL, 0, 4)) {
>
> Instead of 0 and 4 can we use some #defines? This applies for all of the
> i2c_wait_ready calls
>
>
>
Ok, will change this with some macro.
Regards,
Sricharan
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum, a Linux Foundation Collaborative Project
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] clk: Provide support for always-on clocks
On 04/07, Lee Jones wrote: > Lots of platforms contain clocks which if turned off would prove fatal. > The only way to recover from these catastrophic failures is to restart > the board(s). Now, when a clock provider is registered with the > framework it is possible for a list of always-on clocks to be supplied > which must be kept ungated. Each clock mentioned in the newly > introduced 'clock-always-on' will be clk_prepare_enable()d where the > normal references will be taken. This will prevent the common clk > framework from attempting to gate them during the clk_disable_unused() > and disable_clock() procedures. Ah I see now. The disable_clock() part is from the PM core not the common clock framework. This paragraph could be the commit text for the binding patch. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/ACPI: Fix regression caused by 16ee7b3dcc56
On 2015/4/8 0:49, Jim Bos wrote:
> On 04/07/2015 04:34 PM, Jiang Liu wrote:
>> Hi Jim,
>> Could you please help to test this patch against v4.0-rc6?
>> Thanks!
>> Gerry
>>
>> Signed-off-by: Jiang Liu
>> ---
>> arch/x86/kernel/acpi/boot.c | 10 +++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>> index 803b684676ff..f7f1fe7cd1b0 100644
>> --- a/arch/x86/kernel/acpi/boot.c
>> +++ b/arch/x86/kernel/acpi/boot.c
>> @@ -403,10 +403,14 @@ static int mp_config_acpi_gsi(struct device *dev, u32
>> gsi, int trigger,
>> static int mp_register_gsi(struct device *dev, u32 gsi, int trigger,
>> int polarity)
>> {
>> -int irq, node;
>> +int i, irq, node;
>>
>> -if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC)
>> -return gsi;
>> +if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC) {
>> +for (i = 0; i < nr_legacy_irqs(); i++)
>> +if (isa_irq_to_gsi[i] == gsi)
>> +return i;
>> +return -1;
>> +}
>>
>> trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1;
>> polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1;
>>
>
> Jiang,
>
> It definitely seems to be an improvement, using Virtualbox guest with
> your patch applied acpi-events work for all combinations (smp/nosmp
> with/without I/O APIC assigned to the guest).
>
> However, on the Dell laptop it still doesn't work. To be sure I built a
> 3.16 kernel on this laptop and acpi_event power-button lid close/open
> are working just fine.
>
> Attached config + dmesg + cat /proc/interrupt for the working 3.16 case
> and still not working 4.0-rc6+patch case.
Hi Jim,
According to the attached files, you are building a UP kernel
with IOAPIC enabled. This configuration works well on my HP laptop.
And according to file IRQs from 4.0-rc6, it shows:
9: 1XT-PIC acpi
That means kernel has received one ACPI SCI interrupt, but no
following-on ACPI SCI interrupts, I can't figure out the root cause yet.
So could you please help to dump ACPI tables from your dell laptop by
using acpidump utility?
Thanks!
Gerry
>
> Thanks,
> Jim
>
>
>
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 4/4] clk: dt: Introduce binding for always-on clock support
On 04/07, Lee Jones wrote:
> Signed-off-by: Lee Jones
> ---
Can you please add some commit text here? Why did we make this
change?
> .../devicetree/bindings/clock/clock-bindings.txt | 38
> ++
> 1 file changed, 38 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> index 06fc6d5..daf3323 100644
> --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> @@ -44,6 +44,44 @@ For example:
>clocks by index. The names should reflect the clock output signal
>names for the device.
>
> +clock-always-on:Some hardware contains bunches of clocks which must
> never be
> + turned off. If drivers a) fail to obtain a reference to any
> + of these or b) give up a previously obtained reference
> + during suspend, the common clk framework will attempt to
> + disable them and a platform can fail irrecoverably as a
> + result. Usually the only way to recover from these failures
> + is to reboot.
Should we even be talking about "the common clk framework" in
this document? Ideally this document/binding isn't Linux
specific. Plus, the framework doesn't disable clocks during
suspend, it disables clocks during late init as long as the clock
isn't enabled by software.
Maybe we can drop this first paragraph and replace the second
with this single sentence:
Clocks which should never be disabled.
> +
> + To avoid either of these two scenarios from catastrophically
> + disabling an otherwise perfectly healthy running system,
> + clocks can be identified as always-on using this property
> + from inside a clocksource's node.
s/clocksource/clock provider/
> +
> + This property is not to be abused. It is only to be used to
> + protect platforms from being crippled by gated clocks, not
> + as a convenience function to avoid using the framework
> + correctly inside device drivers.
> +
> + Expected values are hardware clock indices. If the
> + clock-indices property (see below) is used, then supplied
> + values must correspond to one of the listed identifiers.
> + Using the clock-indices example below, hardware clock <2>
> + is missing, therefore it is considered invalid to then
> + list clock <2> as an always-on clock.
> +
> +For example:
> +
> +oscillator {
> +#clock-cells = <1>;
> +clock-output-names = "ckil", "ckih";
> +clock-always-on = <0>, <1>;
> +};
> +
> +- this node defines a device with two clock outputs, just as in the
> + example above. The only difference being that 'ckil' and 'ckih'
> + are now identified as an always-on clocks, so the framework will
s/an//
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 3/4] clk: Provide always-on clock support
On 04/07, Lee Jones wrote:
> Lots of platforms contain clocks which if turned off would prove fatal.
> The only way to recover from these catastrophic failures is to restart
> the board(s). Now, when a clock provider is registered with the
> framework it is possible for a list of always-on clocks to be supplied
> which must be kept ungated. Each clock mentioned in the newly
> introduced 'clock-always-on' will be clk_prepare_enable()d where the
> normal references will be taken. This will prevent the common clk
> framework from attempting to gate them during the clk_disable_unused()
> and disable_clock() procedures.
>
> Signed-off-by: Lee Jones
> ---
> drivers/clk/clk-conf.c | 43 ++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-conf.c b/drivers/clk/clk-conf.c
> index aad4796..a07aced 100644
> --- a/drivers/clk/clk-conf.c
> +++ b/drivers/clk/clk-conf.c
> @@ -116,6 +116,43 @@ static int __set_clk_rates(struct device_node *node,
> bool clk_supplier)
> return 0;
> }
>
> +static int __set_clk_always_on(struct device_node *node, bool clk_supplier)
> +{
> + struct of_phandle_args clkspec;
> + struct clk *clk;
> + struct property *prop;
> + const __be32 *cur;
> + uint32_t index;
u32 please
> + int ret;
> +
> + if (!clk_supplier)
> + return 0;
> +
> + of_property_for_each_u32(node, "clock-always-on", prop, cur, index) {
> + clkspec.np = node;
> + clkspec.args_count = 1;
> + clkspec.args[0] = index;
> +
> + clk = of_clk_get_from_provider();
> + if (IS_ERR(clk)) {
> + pr_err("clk: couldn't get clock %u for %s\n",
> + index, node->full_name);
> + return PTR_ERR(clk);
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret) {
> + pr_err("Failed to enable clock %u for %s: %d\n",
> +index, node->full_name, ret);
> + return ret;
> + }
I guess we don't have a clk_put() here because we want to keep the
refcount high forever? We should at least put a comment here
explaining why we left out clk_put() if so.
> +
> + pr_debug("Setting clock as always-on %pC\n", clk);
> + }
> +
> + return 0;
> +}
> +
> /**
> * of_clk_set_defaults() - parse and set assigned clocks configuration
> * @node: device node to apply clock settings for
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the tip tree
Hi all,
On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann wrote:
>
> On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> > On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> >> [ Cc'ing Dave, fyi ]
> >>
> >> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> >>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
> >>> wrote:
> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> > * Stephen Rothwell wrote:
> >
> >> After merging the tip tree, today's linux-next build (powerpc
> >> ppc64_defconfig) failed like this:
> >>
> >> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> >> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
> >> member named 'prog_type'
> >> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> >> ^
> >>
> >> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> >> attached to kprobes").
> >
> > Note, this must be some (rarely triggered) aspect of the ppc64
> > defconfig that neither x86 randconfigs nor most other arch defconfigs
> > expose?
>
> Note, this is a merge conflict with the work that went via net-next
> tree,
> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
>
> You should be able to resolve it in linux-next by changing the test to:
>
> if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
> >>>
> >>> Thanks Daniel, I will do that tomorrow. Someone will have to remember
> >>> to tell Linus.
> >>
> >> Yes, indeed, depending which tree is merged first.
> >
> > Daniel analysis is correct, but the fix for kernel/events/core.c
> > should be:
> > - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> > instead of 'prog->prog_type'
>
> Yes, absolutely, thanks!
So I have applied that as a merge fix patch.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpy_2PAnEAWy.pgp
Description: OpenPGP digital signature
[PATCH 1/2] perf data: Show error message when ctf setup failed
Show message when errors occurred during ctf conversion setup.
Before this patch:
$ ./perf data convert --to-ctf=ctf
$ echo $?
255
After this patch:
$ ./perf data convert --to-ctf=ctf
Error during CTF convert setup.
Signed-off-by: He Kuang
---
tools/perf/util/data-convert-bt.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/data-convert-bt.c
b/tools/perf/util/data-convert-bt.c
index dd17c9a..a5b89b9 100644
--- a/tools/perf/util/data-convert-bt.c
+++ b/tools/perf/util/data-convert-bt.c
@@ -847,11 +847,15 @@ int bt_convert__perf2ctf(const char *input, const char
*path, bool force)
(double) c.events_size / 1024.0 / 1024.0,
c.events_count);
- /* its all good */
-free_session:
perf_session__delete(session);
+ ctf_writer__cleanup(cw);
+
+ return err;
+free_session:
+ perf_session__delete(session);
free_writer:
ctf_writer__cleanup(cw);
+ pr_err("Error during CTF convert setup.\n");
return err;
}
--
2.3.3.220.g9ab698f
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] perf data: Fix ctf_writer setupenv failure
Due to babeltrace commit:
7f800dc7c2a1 ("ir: make trace environment use bt_object")
The trace->frozen flag is set in bt_ctf_trace_create_stream(), this flag
is checked before adding environment field to trace, and causes
ctf_writer__setup_env() failed. Fix this by setting all environment
fields before bt_ctf_trace_create_stream().
Before this patch:
$ perf data convert --to-ctf=ctf
Error during CTF convert setup.
After this patch:
$ perf data convert --to-ctf=ctf
[ perf data convert: Converted 'perf.data' into CTF data 'ctf' ]
[ perf data convert: Converted and wrote 0.023 MB (596 samples) ]
Signed-off-by: He Kuang
---
tools/perf/util/data-convert-bt.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/data-convert-bt.c
b/tools/perf/util/data-convert-bt.c
index a5b89b9..718dc8a 100644
--- a/tools/perf/util/data-convert-bt.c
+++ b/tools/perf/util/data-convert-bt.c
@@ -604,6 +604,22 @@ static int setup_events(struct ctf_writer *cw, struct
perf_session *session)
return 0;
}
+static int ctf_writer__setup_stream(struct ctf_writer *cw)
+{
+ struct bt_ctf_stream*stream;
+
+ /* CTF stream instance */
+ stream = bt_ctf_writer_create_stream(cw->writer, cw->stream_class);
+ if (!stream) {
+ pr("Failed to create CTF stream.\n");
+ return -1;
+ }
+
+ cw->stream = stream;
+
+ return 0;
+}
+
static int ctf_writer__setup_env(struct ctf_writer *cw,
struct perf_session *session)
{
@@ -725,7 +741,6 @@ static int ctf_writer__init(struct ctf_writer *cw, const
char *path)
{
struct bt_ctf_writer*writer;
struct bt_ctf_stream_class *stream_class;
- struct bt_ctf_stream*stream;
struct bt_ctf_clock *clock;
/* CTF writer */
@@ -767,15 +782,6 @@ static int ctf_writer__init(struct ctf_writer *cw, const
char *path)
if (ctf_writer__init_data(cw))
goto err_cleanup;
- /* CTF stream instance */
- stream = bt_ctf_writer_create_stream(writer, stream_class);
- if (!stream) {
- pr("Failed to create CTF stream.\n");
- goto err_cleanup;
- }
-
- cw->stream = stream;
-
/* CTF clock writer setup */
if (bt_ctf_writer_add_clock(writer, clock)) {
pr("Failed to assign CTF clock to writer.\n");
@@ -830,6 +836,10 @@ int bt_convert__perf2ctf(const char *input, const char
*path, bool force)
if (ctf_writer__setup_env(cw, session))
goto free_session;
+ /* CTF writer trace stream setup */
+ if (ctf_writer__setup_stream(cw))
+ goto free_session;
+
/* CTF events setup */
if (setup_events(cw, session))
goto free_session;
--
2.3.3.220.g9ab698f
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] irq: Remove unnecessary warning with affinity_hint
Hi, If you turn off a PCI device whose driver has set affinity_hint, you will get warning message which does _not_ explain the reason why it appeared from the user's point of view. # echo 0 > /sys/bus/pci/slots/65/power Apr 28 20:29:39 localhost kernel: [ cut here ] Apr 28 20:29:39 localhost kernel: WARNING: at kernel/irq/manage.c:1002 __free_irq+0x22d/0x250() (Tainted: P --- ) (snip) Users will misunderstand some problem has happened even though he or she succeeded to turn off the device. I suppose this warning was originally for a debug purpose for driver developers and has incidentally been left. Just remove the warning is good and enough. Signed-off-by: Seiichi Ikarashi --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1335,7 +1335,7 @@ static struct irqaction *__free_irq(unsi #ifdef CONFIG_SMP /* make sure affinity_hint is cleaned up */ - if (WARN_ON_ONCE(desc->affinity_hint)) + if (desc->affinity_hint) desc->affinity_hint = NULL; #endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] x86, selftests: Add sigreturn selftest
On Tue, Apr 7, 2015 at 8:42 PM, Michael Ellerman wrote: > On Mon, 2015-04-06 at 23:11 -0700, Andy Lutomirski wrote: >> On Mon, Apr 6, 2015 at 8:39 PM, Michael Ellerman wrote: >> > On Mon, 2015-04-06 at 19:01 -0700, Andy Lutomirski wrote: >> >> This is my sigreturn test, added mostly unchanged from its old home. >> >> It exercises the sigreturn(2) syscall, specifically focusing on its >> >> interactions with various IRET corner cases. It tests for correct >> >> behavior in several areas that were historically dangerously buggy. >> >> For example, it exercises espfix on kernels of both bitnesses under >> >> various conditions, and it contains exploits for several now-fixed >> >> bugs in IRET error handling. >> >> >> >> If you run it on older kernels, your system will crash. It probably >> >> won't eat your data in the process. >> >> >> >> There is no released kernel on which the sigreturn_64 test will >> >> pass, but it passes on tip:x86/asm. >> >> >> >> IMO it's unfortunate that I need to provide a special script to run >> >> tests. I'd rather just list my targets. >> > >> > If you use lib.mk you can. >> > >> > >> > https://git.kernel.org/cgit/linux/kernel/git/shuah/linux-kselftest.git/log/?h=next >> > >> > See for example: >> > >> > >> > https://git.kernel.org/cgit/linux/kernel/git/shuah/linux-kselftest.git/commit/?h=next=5744de542dd4b963c2975e6f70844ce2899864e4 >> >> Will do for 4.2. In the mean time, there's no base on which lib.mk >> exists and the test works. > > OK. > > Shua seems to have already sent a pull request for 4.1, which is rather early > to say the least, but suggests you've missed 4.1 anyway - unless you want it > to > go via some other tree. The plan is to go in via tip:x86/asm, I think. That's where the fix that the test depends on lives. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: rtl8188eu: Replaced kzalloc and memcpy combination with kmemdup
On Tue, Apr 07, 2015 at 02:25:39PM +, Dhere, Chaitanya (C.) wrote: > This change was detected with the help of coccinelle tool. > It performs the same function as kzalloc amd memcpy. > > Signed-off-by: Chaitanya Dhere your From: name and this name does not match. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] selftest: Add futex functional tests
On Tue, Mar 31, 2015 at 10:37:51AM -0600, Shuah Khan wrote: > On 03/31/2015 10:24 AM, Darren Hart wrote: > > On 3/31/15, 8:32 AM, "Shuah Khan" wrote: > > > >> Hi Daren, > >> > >> On 03/27/2015 04:17 PM, Darren Hart wrote: > >>> Hi Shuah, > >>> > >>> This series begins the process of migrating my futextest tests into > >>> kselftest. > >>> I've started with only the functional tests, as the performance and > >>> stress may > >>> not be appropriate for kselftest as they stand. > >>> > >>> I cleaned up various complaints from checkpatch, but I ignored others > >>> that would > >>> require significant rework of the testcases, such as not using volatile > >>> and not > >>> creating new typedefs. > >>> > >>> The patches will follow, but I'm providing a pull request for your > >>> convenience > >>> as well. > >> > >> Thanks for acting on this so quickly after we talked about it at ELC. > >> Just a quick note that I am going to get to this soon once I get the > >> 4.1 content wrapped up. We can plan upon getting these into 4.2. > > > > OK. Michael E. provided some feedback which I can either incorporate and > > respin, or I can send as a follow-on to your -next after you merge these. > > Which do you prefer? > > ... > You can wait to re-do patches. I am planning to review the > patch set later on this week. That way you can avoid re-spin > just in case, I have other comments. Hi Shuah, Did you have any additional comments for the futex tests? Thanks, -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Add me on list of Dell laptop drivers
On Sun, Apr 05, 2015 at 11:11:49PM +0200, Pali Rohár wrote: > On Thursday 02 April 2015 07:10:27 Darren Hart wrote: > > On Sun, Mar 29, 2015 at 03:38:50PM +0200, Pali Rohár wrote: > > > > Please include why. No empty commit messages please. > > > > For example, you've written nearly a third of the dell-wmi.c > > driver, and all the dell-smo8800.c driver. > > > > Ok. If you need description include this: > > === > MAINTAINERS: Add me on list of Dell laptop drivers > > I have written more parts of dell laptop drivers dell-laptop.c, > dell-wmi.c and dell-smo8800.c > === > > > Dell Laptop is still pending the keyboard backlight patches > > though I believe (have I missed them?), so you don't > > currently have code ownership there. I agree you should be on > > the MAINTAINERS list, but it would be good to get your > > keyboard backlight changes in first. > > > > ok. > > > Gosh... sure seems like we should have merged that already... > > am I missing something? The last thing I see in master, > > testing, and next is the revert from Jan 21 > > > > backlight support was merged for 3.19, but has small problem with > ALS settings. And then you decided to revert it for 3.19. After > that problem was fixed and last (2015-03-06) you wrote that you > queued patch again for 4.1 release. Right you are, and I appear to have dropped that ball. Found it, and it's now in my testing branch, and will run through the 0day testing, then into my next tomorrow, still on track for 4.1. > > > Also, Matthew, you're the listed maintainer for these, do you > > agree to adding Pali? I'm accepted silence as acceptance :-) -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] kselftests: timers: Make set-timer-lat fail more gracefully for !CAP_WAKE_ALARM
On Thu, 2015-04-02 at 11:02 -0700, John Stultz wrote: > On Thu, Apr 2, 2015 at 3:18 AM, Prarit Bhargava wrote: > > On 03/26/2015 01:33 PM, Tyler Baker wrote: > >> I realize this may be a good amount of work, so I'd like to help out. > >> Perhaps working John to convert his timer tests to use TAP output > >> would be a good starting point? > > > > John, I could probably do that for you. I'm always willing to give it a > > shot. > > I took a quick look into it, since I'm definitely interested in > improving output formatting, but man, TAP is a fairly ugly output > format if you ask me. > > It only has binary "ok" or "not ok" (why not "fail", or something else > that's exclusively grep-able, I don't know). So I'm not sure if cases > where functionality is unsupported should be a pass or fail. > > Most problematically: It seems to want enumeration in the test output > (so test 2 needs to print: "ok 2 Test complete") which means either > there needs to be a wrapper that does the TAP output knowing which > test of N its currently running, or the test number needs to be > submitted as an runtime argument to the test, and the test then has to > add it to its output line. Yeah TAP is horrible, for the reasons you describe. I *think* in practice most tools will handle just "ok" / "not ok" without the tests being numbered, but I don't know that for sure. For the powerpc tests I'm using "subunit v1" [1], which is basically just: - "^success: " - "^failure: " See: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/powerpc/subunit.h So I can do eg: $ cd tools/testing/selftests/powerpc $ make run_tests 2>&1 | subunit-1to2 | subunit-stats --no-passthrough Total tests: 35 Passed tests: 31 Failed tests: 0 Skipped tests: 4 Seen tags: git_version:v4.0-rc7-0-gf22e6e8 But unfortunately TAP has a lot more traction with tools. It wouldn't be too hard to convert the subunit stream into TAP I think, but for some reason no one seems to have written that. Maybe we should, I just haven't had time to do it. cheers [1]: https://github.com/testing-cabal/subunit/blob/master/README#L343 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf record: Conditionally define CLOCK_MONOTONIC_RAW for older OSes
Commit 31a9883106cc ("perf record: Add clockid parameter") used
CLOCK_MONOTONIC_RAW in the struct clockid_map clockids[], but the
CLOCK_MONOTONIC_RAW macro is not defined in older releases (e.g., SLES
11 SP2), thus there is a building error when making perf:
builtin-record.c:738: error: ‘CLOCK_MONOTONIC_RAW’ undeclared here (not in a
function)
make[2]: *** [builtin-record.o] Error 1
make[2]: *** Waiting for unfinished jobs
LD bench/perf-in.o
LD tests/perf-in.o
make[1]: *** [perf-in.o] Error 2
make: *** [all] Error 2
So define this macro if it is not defined.
Signed-off-by: Yunlong Song
---
tools/perf/builtin-record.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index cfdff50..5b0962a 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -731,6 +731,9 @@ struct clockid_map {
#ifndef CLOCK_TAI
#define CLOCK_TAI 11
#endif
+#ifndef CLOCK_MONOTONIC_RAW
+#define CLOCK_MONOTONIC_RAW 4
+#endif
static const struct clockid_map clockids[] = {
/* available for all events, NMI safe */
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] perf: report/annotate: fix segfault problem.
perf report and perf annotate are easy to trigger segfault if trace data
contain kernel module information like this:
# perf report -D -i ./perf.data
...
0 0 0x188 [0x50]: PERF_RECORD_MMAP -1/0: [0xffbff1018000(0xf068000) @ 0]:
x [test_module]
...
# perf report -i ./perf.data --objdump=/path/to/objdump
--kallsyms=/path/to/kallsyms
perf: Segmentation fault
backtrace
/path/to/perf[0x503478]
/lib64/libc.so.6(+0x3545f)[0x7fb201f3745f]
/path/to/perf[0x499b56]
/path/to/perf(dso__load_kallsyms+0x13c)[0x49b56c]
/path/to/perf(dso__load+0x72e)[0x49c21e]
/path/to/perf(map__load+0x6e)[0x4ae9ee]
/path/to/perf(thread__find_addr_map+0x24c)[0x47deec]
/path/to/perf(perf_event__preprocess_sample+0x88)[0x47e238]
/path/to/perf[0x43ad02]
/path/to/perf[0x4b55bc]
/path/to/perf(ordered_events__flush+0xca)[0x4b57ea]
/path/to/perf[0x4b1a01]
/path/to/perf(perf_session__process_events+0x3be)[0x4b428e]
/path/to/perf(cmd_report+0xf11)[0x43bfc1]
/path/to/perf[0x474702]
/path/to/perf(main+0x5f5)[0x42de95]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x7fb201f23bd4]
/path/to/perf[0x42dfc4]
This is because __kmod_path__parse regard '[' leading name as kernel
instead of kernel module. The DSO will then be passed to
dso__load_kernel_sym() then dso__load_kcore() because of --kallsyms
argument. The segfault is triggered because the kmap structure is not
initialized.
Although in --vmlinux case such segfault can be avoided, the symbols in
the kernel module are unable to be retrived since the attribute of DSO
is incorrect.
This patch fixes __kmod_path__parse, make it regard names like
'[test_module]' as kernel module.
According to suggestion from Arnaldo Carvalho de Melo (
https://lkml.org/lkml/2015/4/6/90), appends cpumode argument to
__kmod_path__parse() to ensure the passed path is a kernel mmap.
kmod-path.c is also update to reflect the above changes.
Signed-off-by: Wang Nan
---
Different from v3:
Don't warn if cpumode is unknown.
---
tools/perf/tests/kmod-path.c | 43 +++
tools/perf/util/dso.c| 54 +++-
tools/perf/util/dso.h| 12 ++
tools/perf/util/header.c | 2 +-
tools/perf/util/machine.c| 4 +++-
5 files changed, 98 insertions(+), 17 deletions(-)
diff --git a/tools/perf/tests/kmod-path.c b/tools/perf/tests/kmod-path.c
index e8d7cbb..5d57df6 100644
--- a/tools/perf/tests/kmod-path.c
+++ b/tools/perf/tests/kmod-path.c
@@ -4,14 +4,14 @@
#include "debug.h"
static int test(const char *path, bool alloc_name, bool alloc_ext,
- bool kmod, bool comp, const char *name, const char *ext)
+ bool kmod, bool comp, const char *name, const char *ext, int
cpumode)
{
struct kmod_path m;
memset(, 0x0, sizeof(m));
TEST_ASSERT_VAL("kmod_path__parse",
- !__kmod_path__parse(, path, alloc_name, alloc_ext));
+ !__kmod_path__parse(, path, cpumode, alloc_name,
alloc_ext));
pr_debug("%s - alloc name %d, alloc ext %d, kmod %d, comp %d, name
'%s', ext '%s'\n",
path, alloc_name, alloc_ext, m.kmod, m.comp, m.name, m.ext);
@@ -34,8 +34,14 @@ static int test(const char *path, bool alloc_name, bool
alloc_ext,
return 0;
}
-#define T(path, an, ae, k, c, n, e) \
- TEST_ASSERT_VAL("failed", !test(path, an, ae, k, c, n, e))
+
+#define _T(path, an, ae, k, c, n, e, m) \
+ TEST_ASSERT_VAL("failed", !test(path, an, ae, k, c, n, e, m))
+
+#define T(path, an, ae, k, c, n, e) _T(path, an, ae, k, c, n, e, \
+ PERF_RECORD_MISC_CPUMODE_UNKNOWN)
+#define TU(path, an, ae, k, c, n, e) _T(path, an, ae, k, c, n, e, \
+ PERF_RECORD_MISC_USER)
int test__kmod_path__parse(void)
{
@@ -69,5 +75,34 @@ int test__kmod_path__parse(void)
T("x.ko.gz", true , false, true, true, "[x]", NULL);
T("x.ko.gz", false , false, true, true, NULL , NULL);
+ /* path alloc_namealloc_ext kmod comp name ext
*/
+ T("[test_module]", true , true, true, false, "[test_module]" ,
NULL);
+ T("[test_module]", false , true, true, false, NULL,
NULL);
+ T("[test_module]", true , false , true, false, "[test_module]" ,
NULL);
+ T("[test_module]", false , false , true, false, NULL,
NULL);
+
+ /* path alloc_namealloc_ext kmod comp name ext
*/
+ T("[test.module]", true , true, true, false, "[test.module]" ,
NULL);
+ T("[test.module]", false , true, true, false, NULL,
NULL);
+ T("[test.module]", true , false , true, false, "[test.module]" ,
NULL);
+ T("[test.module]", false , false , true, false, NULL,
NULL);
+
+ /* path alloc_name alloc_ext kmod comp name ext */
+ TU("[vdso]", true , true, false, false, "[vdso]" ,
Re: [PATCH v3 0/3] toshiba_acpi: Fix USB Sleep & Charge mode and documentation updates
On Thu, Apr 02, 2015 at 07:26:19PM -0600, Azael Avalos wrote: > This patch fixes the USB Sleep & Charge charging mode on certain > models, fixes pr_* messages and also adds the missing entries in the > documentation file. > > Changes since v2: > - Check for TOS_SUCCESS to initialize and flag as supported on first > patch > > Changes since v1: > - Set the default supported value of sleep and charge to zero in case > of an error and added comments. > - Updated the title and commit message of second patch to better > reflect what the patch is doing. > > Azael Avalos (3): > toshiba_acpi: Update and fix USB Sleep and Charge modes > toshiba_acpi: Fix pr_* messages from USB Sleep Functions > Documentation/ABI: Update sysfs-driver-toshiba_acpi entry > > .../ABI/testing/sysfs-driver-toshiba_acpi | 93 > +++--- > drivers/platform/x86/toshiba_acpi.c| 87 > 2 files changed, 150 insertions(+), 30 deletions(-) Queued the series, thanks Azael. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] perf: report/annotate: fix segfault problem.
On 2015/4/7 23:13, Arnaldo Carvalho de Melo wrote:
> Em Tue, Apr 07, 2015 at 08:22:46AM +, Wang Nan escreveu:
>> perf report and perf annotate are easy to trigger segfault if trace data
>> contain kernel module information like this:
>>
>> # perf report -D -i ./perf.data
>> ...
>> 0 0 0x188 [0x50]: PERF_RECORD_MMAP -1/0: [0xffbff1018000(0xf068000) @
>> 0]: x [test_module]
>> ...
>>
>> # perf report -i ./perf.data --objdump=/path/to/objdump
>> --kallsyms=/path/to/kallsyms
>>
>> perf: Segmentation fault
>> backtrace
>> /path/to/perf[0x503478]
>> /lib64/libc.so.6(+0x3545f)[0x7fb201f3745f]
>> /path/to/perf[0x499b56]
>
> So, with this patch applied I am seeing this:
>
> [root@ssdandy ~]# perf sched record -a
> Kmod (modules.order) and cpumode (0) inconsistent
> Kmod (modules.builtin) and cpumode (0) inconsistent
> Kmod (modules.dep) and cpumode (0) inconsistent
> Kmod (modules.dep.bin) and cpumode (0) inconsistent
> Kmod (modules.alias) and cpumode (0) inconsistent
> Kmod (modules.alias.bin) and cpumode (0) inconsistent
> Kmod (modules.softdep) and cpumode (0) inconsistent
> Kmod (modules.symbols) and cpumode (0) inconsistent
> Kmod (modules.symbols.bin) and cpumode (0) inconsistent
> Kmod (modules.builtin.bin) and cpumode (0) inconsistent
> Kmod (modules.devname) and cpumode (0) inconsistent
> ^C[ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.465 MB perf.data (1595 samples) ]
>
> [root@ssdandy ~]#o
>
> Can you please check this?
>
> Why do we get these warning for these files?
>
This is because in map_groups__set_modules_path_dir() we enumerate over each
file
in /lib/modules/`uname -a`/ and use kmod_path__parse_name() to parse their
names.
In this v3 patch, I update __kmod_path__parse() to check consistency between
m.kmod and
cpumode. It will warn if one passes a kernel module name with user
space cpumode, or passes kernel space cpumode with a non-kmodule name.
I'll post a patch v4 to avoid such warning if passed cpumode is not explicitly
set to
user or kernel.
Difference from v3:
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index fb1ed7d..875f7c9 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -215,7 +215,7 @@ int __kmod_path__parse(struct kmod_path *m, const char
*path,
const char *name = strrchr(path, '/');
const char *ext = strrchr(path, '.');
bool is_simple_name = false;
- bool cpu_mode_kernel, is_kernel = false;
+ bool cpu_mode_kernel, cpu_mode_unknown = false, is_kernel = false;
/* treat PERF_RECORD_MISC_CPUMODE_UNKNOWN as kernel. */
switch (cpumode & PERF_RECORD_MISC_CPUMODE_MASK) {
@@ -224,6 +224,9 @@ int __kmod_path__parse(struct kmod_path *m, const char
*path,
case PERF_RECORD_MISC_GUEST_USER:
cpu_mode_kernel = false;
break;
+ case PERF_RECORD_MISC_CPUMODE_UNKNOWN:
+ cpu_mode_unknown = true;
+ /* fall through */
default:
cpu_mode_kernel = true;
}
@@ -288,10 +291,12 @@ int __kmod_path__parse(struct kmod_path *m, const char
*path,
}
}
out:
- if ((m->kmod && !cpu_mode_kernel) ||
- (cpu_mode_kernel && !m->kmod && !is_kernel))
- pr_warning("Kmod (%s) and cpumode (%d) inconsistent\n",
- path, cpumode);
+ if (!cpu_mode_unknown) {
+ if ((m->kmod && !cpu_mode_kernel) ||
+ (cpu_mode_kernel && !m->kmod && !is_kernel))
+ pr_warning("Kmod (%s) and cpumode (%d) inconsistent\n",
+ path, cpumode);
+ }
return 0;
}
>
> Applied the other patch:
>
> -> 28 T 04/07 Wang Nan (8,8K) [PATCH v3 1/2] perf: kmaps: enforce usage of
> kmaps to protect futher bugs.
>
>
> - Arnaldo
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] x86, selftests: Add sigreturn selftest
On Mon, 2015-04-06 at 23:11 -0700, Andy Lutomirski wrote: > On Mon, Apr 6, 2015 at 8:39 PM, Michael Ellerman wrote: > > On Mon, 2015-04-06 at 19:01 -0700, Andy Lutomirski wrote: > >> This is my sigreturn test, added mostly unchanged from its old home. > >> It exercises the sigreturn(2) syscall, specifically focusing on its > >> interactions with various IRET corner cases. It tests for correct > >> behavior in several areas that were historically dangerously buggy. > >> For example, it exercises espfix on kernels of both bitnesses under > >> various conditions, and it contains exploits for several now-fixed > >> bugs in IRET error handling. > >> > >> If you run it on older kernels, your system will crash. It probably > >> won't eat your data in the process. > >> > >> There is no released kernel on which the sigreturn_64 test will > >> pass, but it passes on tip:x86/asm. > >> > >> IMO it's unfortunate that I need to provide a special script to run > >> tests. I'd rather just list my targets. > > > > If you use lib.mk you can. > > > > > > https://git.kernel.org/cgit/linux/kernel/git/shuah/linux-kselftest.git/log/?h=next > > > > See for example: > > > > > > https://git.kernel.org/cgit/linux/kernel/git/shuah/linux-kselftest.git/commit/?h=next=5744de542dd4b963c2975e6f70844ce2899864e4 > > Will do for 4.2. In the mean time, there's no base on which lib.mk > exists and the test works. OK. Shua seems to have already sent a pull request for 4.1, which is rather early to say the least, but suggests you've missed 4.1 anyway - unless you want it to go via some other tree. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On 04/07/15 at 05:55pm, Li, ZhenHua wrote: > On 04/07/2015 05:08 PM, Dave Young wrote: > >On 04/07/15 at 11:46am, Dave Young wrote: > >>On 04/05/15 at 09:54am, Baoquan He wrote: > >>>On 04/03/15 at 05:21pm, Dave Young wrote: > On 04/03/15 at 05:01pm, Li, ZhenHua wrote: > >Hi Dave, > > > >There may be some possibilities that the old iommu data is corrupted by > >some other modules. Currently we do not have a better solution for the > >dmar faults. > > > >But I think when this happens, we need to fix the module that corrupted > >the old iommu data. I once met a similar problem in normal kernel, the > >queue used by the qi_* functions was written again by another module. > >The fix was in that module, not in iommu module. > > It is too late, there will be no chance to save vmcore then. > > Also if it is possible to continue corrupt other area of oldmem because > of using old iommu tables then it will cause more problems. > > So I think the tables at least need some verifycation before being used. > > >>> > >>>Yes, it's a good thinking anout this and verification is also an > >>>interesting idea. kexec/kdump do a sha256 calculation on loaded kernel > >>>and then verify this again when panic happens in purgatory. This checks > >>>whether any code stomps into region reserved for kexec/kernel and corrupt > >>>the loaded kernel. > >>> > >>>If this is decided to do it should be an enhancement to current > >>>patchset but not a approach change. Since this patchset is going very > >>>close to point as maintainers expected maybe this can be merged firstly, > >>>then think about enhancement. After all without this patchset vt-d often > >>>raised error message, hung. > >> > >>It does not convince me, we should do it right at the beginning instead of > >>introduce something wrong. > >> > >>I wonder why the old dma can not be remap to a specific page in kdump kernel > >>so that it will not corrupt more memory. But I may missed something, I will > >>looking for old threads and catch up. > > > >I have read the old discussion, above way was dropped because it could > >corrupt > >filesystem. Apologize about late commenting. > > > >But current solution sounds bad to me because of using old memory which is > >not > >reliable. > > > >Thanks > >Dave > > > Seems we do not have a better solution for the dmar faults. But I believe > we can find out how to verify the iommu data which is located in old memory. That will be great, thanks. So there's two things: 1) make sure old pg tables are right, this is what we were talking about. 2) avoid writing old memory, I suppose only dma read could corrupt filesystem, right? So how about for any dma writes just create a scratch page in 2nd kernel memory. Only using old page table for dma read. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[watchdog] WARNING: CPU: 0 PID: 1 at mm/memblock.c:1151 memblock_virt_alloc_internal()
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master commit e164ade07b215cc33da6831734140f0aa0615d0a Author: Chris Metcalf AuthorDate: Thu Apr 2 13:25:32 2015 -0400 Commit: Chris Metcalf CommitDate: Mon Apr 6 12:35:02 2015 -0400 watchdog: add watchdog_exclude sysctl to assist nohz Change the default behavior of watchdog so it only runs on the housekeeping cores when nohz_full is enabled at build and boot time. Allow modifying the set of cores the watchdog is currently running on with a new kernel.watchdog_exclude sysctl. Signed-off-by: Chris Metcalf +--+++---+ | | a578fc8f8d | e164ade07b | next-20150407 | +--+++---+ | boot_successes | 0 | 0 | 0 | | boot_failures| 80 | 20 | 12| | WARNING:at_lib/debugobjects.c:#__debug_object_init() | 80 | | | | page_allocation_failure:order:#,mode | 80 | | | | Out_of_memory:Kill_process | 33 | | | | backtrace:__debug_object_init| 80 | | | | backtrace:warn_slowpath_null | 80 | | | | backtrace:debug_object_init | 80 | | | | backtrace:__init_work| 80 | | | | backtrace:rhashtable_init| 80 | | | | backtrace:test_rht_init | 80 | | | | backtrace:kernel_init_freeable | 80 | 20 | 12| | backtrace:btrfs_test_extent_io | 80 | | | | backtrace:init_btrfs_fs | 80 | | | | WARNING:at_mm/memblock.c:#memblock_virt_alloc_internal() | 0 | 20 | 12| | BUG:KASan:user-memory-access_on_address(null)| 0 | 20 | 12| | BUG:unable_to_handle_kernel | 0 | 20 | 12| | Oops | 0 | 20 | 12| | RIP:__bitmap_empty | 0 | 20 | | | Kernel_panic-not_syncing:Fatal_exception | 0 | 20 | 12| | backtrace:alloc_bootmem_cpumask_var | 0 | 20 | 12| | backtrace:lockup_detector_init | 0 | 20 | 12| | backtrace:__bitmap_empty | 0 | 20 | | | RIP:find_first_bit | 0 | 0 | 12| | backtrace:find_first_bit | 0 | 0 | 12| +--+++---+ [0.177042] smpboot: CPU0: Intel Common KVM processor (fam: 0f, model: 06, stepping: 01) [0.179108] Performance Events: unsupported Netburst CPU model 6 no PMU driver, software events only. [0.187261] [ cut here ] [0.188011] WARNING: CPU: 0 PID: 1 at mm/memblock.c:1151 memblock_virt_alloc_internal+0x7e/0x149() [0.189008] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1-00012-ge164ade #11 [0.190005] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [0.191005] 82459271 88000db9fd98 81ff9f0e 8000 [0.193004] 88000db9fde8 8112a2b8 fbfff04e2930 [0.195004] 82a3ba79 88000db9fdd8 0400 [0.197004] Call Trace: [0.198011] [] dump_stack+0x4f/0x7b [0.199009] [] warn_slowpath_common+0xba/0xd8 [0.29] [] ? memblock_virt_alloc_internal+0x7e/0x149 [0.201008] [] warn_slowpath_null+0x1a/0x1c [0.202008] [] memblock_virt_alloc_internal+0x7e/0x149 [0.203008] [] memblock_virt_alloc_try_nid+0x5f/0x9c [0.204009] [] alloc_bootmem_cpumask_var+0x1e/0x31 [0.205008] [] lockup_detector_init+0x2e/0xf8
Re: powerpc32: fix warning from include/linux/mm.h
On Fri, 2015-03-20 at 18:52 -0500, Scott Wood wrote: > On Fri, Dec 05, 2014 at 12:20:20PM +0100, LEROY Christophe wrote: > > include/linux/mm.h: In function 'is_vmalloc_addr': > > include/linux/mm.h:367:14: warning: comparison between signed and unsigned > > integer expressions [-Wsign-compare] > > return addr >= VMALLOC_START && addr < VMALLOC_END; > > ^ > > > > Signed-off-by: Christophe Leroy > > --- > > arch/powerpc/include/asm/pgtable-ppc32.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > That warning doesn't appear to be enabled. What config are you seeing > this with? > > I'm also not clear on why this was assigned to me in patchwork. Because it's from Christophe. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the vfs tree with the ext4 tree
On Tue, Apr 07, 2015 at 09:02:14AM +0200, Christoph Hellwig wrote: > FYI, the ext4 tree seems to have the crypto support, which I don't think is > ready for 4.1 with all the implications of it.. What sort of implications are you concerned about? We're no longer exposing anything via the xattr interface, and all of the changes are not contained strictly within the ext4 tree. There are still are some cleanups which I'm still in the process of applying, but I considered it more likely than not something that was ready for 4.1, so that's why I let it go into the ext4 dev branch for testing in linux-next. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: about the flood of trivial patches and the Code of Conduct (was: Re: [PATCH 19/25] sched: Use bool function return values of true/false not 1/0)
On Tue, Apr 07, 2015 at 01:32:12PM +0200, Peter Zijlstra wrote: > > I propose to send all this stuff though the trivial tree such that > > maintainers > > of other subsystems have less workload and newbies (which are supposed > > to send such patches) know which tree they have to work against. > > Let's have to well defined and ordered. :-) > > As per the other branch of this tree; an emphatic NO to that. The > trivial tree is not a backdoor to bypass maintainers. Actual code > changes do not get to go through any tree but the maintainer tree unless > explicitly ACKed. Agreed, I don't want trivial patches to ext4 either (a) polluting my inbox, or (b) sneaking in behind my back in the trivial tree. Joe, please just stop the madness. Thanks, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel v7 26/31] powerpc/iommu: Add userspace view of TCE table
On 04/03/2015 07:50 AM, Alex Williamson wrote:
Should have sent this with the other comments, but found it hiding on my
desktop...
On Sat, 2015-03-28 at 01:55 +1100, Alexey Kardashevskiy wrote:
In order to support memory pre-registration, we need a way to track
the use of every registered memory region and only allow unregistration
if a region is not in use anymore. So we need a way to tell from what
region the just cleared TCE was from.
This adds a userspace view of the TCE table into iommu_table struct.
It contains userspace address, one per TCE entry. The table is only
allocated when the ownership over an IOMMU group is taken which means
it is only used from outside of the powernv code (such as VFIO).
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h | 6 ++
arch/powerpc/kernel/iommu.c | 7 +++
arch/powerpc/platforms/powernv/pci-ioda.c | 23 ++-
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 2c08c91..a768a4d 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -106,9 +106,15 @@ struct iommu_table {
unsigned long *it_map; /* A simple allocation bitmap for now */
unsigned long it_page_shift;/* table iommu page size */
struct iommu_table_group *it_group;
+ unsigned long *it_userspace; /* userspace view of the table */
struct iommu_table_ops *it_ops;
};
+#define IOMMU_TABLE_USERSPACE_ENTRY(tbl, entry) \
+ ((tbl)->it_userspace ? \
+ &((tbl)->it_userspace[(entry) - (tbl)->it_offset]) : \
+ NULL)
+
/* Pure 2^n version of get_order */
static inline __attribute_const__
int get_iommu_order(unsigned long size, struct iommu_table *tbl)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 0bcd988..82102d1 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1069,6 +1070,9 @@ static int iommu_table_take_ownership(struct iommu_table
*tbl)
spin_unlock(>pools[i].lock);
spin_unlock_irqrestore(>large_pool.lock, flags);
+ BUG_ON(tbl->it_userspace);
+ tbl->it_userspace = vzalloc(sizeof(*tbl->it_userspace) * tbl->it_size);
+
-ENOMEM?
return 0;
}
@@ -1102,6 +1106,9 @@ static void iommu_table_release_ownership(struct
iommu_table *tbl)
{
unsigned long flags, i, sz = (tbl->it_size + 7) >> 3;
+ vfree(tbl->it_userspace);
+ tbl->it_userspace = NULL;
+
spin_lock_irqsave(>large_pool.lock, flags);
for (i = 0; i < tbl->nr_pools; i++)
spin_lock(>pools[i].lock);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index bc36cf1..036f3c1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1469,6 +1470,9 @@ static void pnv_pci_free_table(struct iommu_table *tbl)
if (!tbl->it_size)
return;
+ if (tbl->it_userspace)
Not necessary
Out of curiosity - why? Is every single implementation is known for
checking the argument?
+ vfree(tbl->it_userspace);
+
Why no NULL setting this time?
iommu_reset_table() (2 lines below) will do memset(0) on the entire struct.
pnv_free_tce_table(tbl->it_base, size, tbl->it_indirect_levels);
iommu_reset_table(tbl, "ioda2");
}
@@ -1656,9 +1660,26 @@ static void pnv_ioda2_set_ownership(struct
iommu_table_group *table_group,
pnv_pci_ioda2_set_bypass(pe, !enable);
}
+static long pnv_pci_ioda2_create_table_with_uas(
+ struct iommu_table_group *table_group,
+ int num, __u32 page_shift, __u64 window_size, __u32 levels,
+ struct iommu_table *tbl)
+{
+ long ret = pnv_pci_ioda2_create_table(table_group, num,
+ page_shift, window_size, levels, tbl);
+
+ if (ret)
+ return ret;
+
+ BUG_ON(tbl->it_userspace);
+ tbl->it_userspace = vzalloc(sizeof(*tbl->it_userspace) * tbl->it_size);
-ENOMEM
+
+ return 0;
+}
+
static struct iommu_table_group_ops pnv_pci_ioda2_ops = {
.set_ownership = pnv_ioda2_set_ownership,
- .create_table = pnv_pci_ioda2_create_table,
+ .create_table = pnv_pci_ioda2_create_table_with_uas,
.set_window = pnv_pci_ioda2_set_window,
.unset_window = pnv_pci_ioda2_unset_window,
};
Thanks for the review! What is overall resume? Another respin?
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: blk-mq : blk_mq_map_swqueue maybe
nimisolo,
在 4/8/2015 10:10 AM, nimisolo 写道:
Hi Jens,
In blk_mq_map_swqueue(), all the blk_mq_hw_ctx's nr_ctx are set
to zero, and then each blk_mq_ctx's index_hw is set to nr_ctx.
I think the index_hw means the index of the hardware queue that map
to this software queue, so maybe index_hw should be set to
blk_mq_hw_ctx's queue_num.
Multiple sw queues may be dispatched to one hw queue.
So index_hw here means the index of the sw queue in corresponding hw queue.
--yc
I'm a student and I probably have misunderstood this code, please help
me to resolve this confusion. Thank you.
static void blk_mq_map_swqueue(struct request_queue *q)
{
.
queue_for_each_hw_ctx(q, hctx, i) {
.
hctx->nr_ctx = 0;
}
.
queue_for_each_ctx(q, ctx, i) {
.
ctx->index_hw = hctx->nr_ctx;
.
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf trace: Fix segmentfault on perf trace
Hi, Arnaldo
On 2015/4/7 20:36, Arnaldo Carvalho de Melo wrote:
Em Tue, Apr 07, 2015 at 05:31:11PM +0800, He Kuang escreveu:
After perf_evlist__filter_pollfd() filters out fds and releases
perf_mmap by using perf_evlist__mmap_put(), refcnt of perf_mmap hits 1
then perf_evlist__mmap_consume() will do the final unmap. In this
condition, perf_evlist__mmap_read() will crash by referencing invalid
mmap. Put refcnt check before use.
Can be reproduced as following:
After applying 1/2 in this series and trying to reproduce I couldn't, it
works, looking at the code...
Let me get my head around this, idea was that after all fds associated
with a mmap would be closed, i.e. the perf_mmap->refcnt hits zero, then
we would have to drain whatever was left in the mmap, but looking again
that doesn't look like that is what is doing, becaue in filter_pollfd we
will munmap it before being able to "drain" it, as all mmaps were
closed, thus filter_pollfd returned zero...
In function __perf_evlist__mmap(), refcnt is initialized to 2, see commit:
823969860329 ("perf evlist: Refcount mmaps")
After filter_pollfd, perf_mmap->refcnt is 1 not 0.
perf_evlist__filter_pollfd() -- refcnt=1
draining = true
if (perf_evlist__mmap_read() != NULL)
perf_evlist__mmap_consume()-- unmap, refcnt = 0
perf_evlist__mmap_read()-- segfault
else
exit
I noticed that this issue also exists in builtin-record.c, but it
checks before mmap_read():
if (rec->evlist->mmap[i].base) {
if (record__mmap_read(rec, i, draining) != 0) {
So we can either do the check outside
builtin-trace.c:perf_evlist__mmap_read() like what
builtin-record.c do or inside. What's your opinion?
Reading on, thanks for the patch!
- Arnaldo
$ perf trace --duration 1.0 ls
...
perf: Segmentation fault
Obtained 14 stack frames.
./perf(dump_stack+0x2e) [0x503c2d]
./perf(sighandler_dump_stack+0x2e)
[0x503d0c]
/lib64/libc.so.6(+0x34df0) [0x7f5fd9a4adf0]
./perf() [0x4a8fda]
./perf(perf_evlist__mmap_read+0x56)
[0x4aae93]
./perf() [0x470b28]
./perf(cmd_trace+0xada) [0x4727bd]
./perf() [0x49c4f4]
./perf() [0x49c74d]
./perf() [0x49c899]
./perf(main+0x23b)
[0x49cbfa]
/lib64/libc.so.6(__libc_start_main+0xf5)
[0x7f5fd9a377b5]
./perf() [0x434ea5]
[(nil)]
Signed-off-by: He Kuang
---
tools/perf/util/evlist.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 76ef7ee..9d36433 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -634,11 +634,18 @@ static struct perf_evsel *perf_evlist__event2evsel(struct
perf_evlist *evlist,
union perf_event *perf_evlist__mmap_read(struct perf_evlist *evlist, int idx)
{
struct perf_mmap *md = >mmap[idx];
- unsigned int head = perf_mmap__read_head(md);
- unsigned int old = md->prev;
- unsigned char *data = md->base + page_size;
+ unsigned int head;
+ unsigned int old;
+ unsigned char *data;
union perf_event *event = NULL;
+ if (md == NULL || md->refcnt == 0)
+ return NULL;
+
+ head = perf_mmap__read_head(md);
+ old = md->prev;
+ data = md->base + page_size;
+
if (evlist->overwrite) {
/*
* If we're further behind than half the buffer, there's a
chance
--
2.3.3.220.g9ab698f
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] md: fix md io stats accounting broken
On Fri, 3 Apr 2015 08:44:47 +0800 Gu Zheng wrote:
> Simon reported the md io stats accounting issue:
> "
> I'm seeing "iostat -x -k 1" print this after a RAID1 rebuild on 4.0-rc5.
> It's not abnormal other than it's 3-disk, with one being SSD (sdc) and
> the other two being write-mostly:
>
> Device: rrqm/s wrqm/s r/s w/srkB/swkB/s avgrq-sz
> avgqu-sz await r_await w_await svctm %util
> sda 0.00 0.000.000.00 0.00 0.00 0.00
> 0.000.000.000.00 0.00 0.00
> sdb 0.00 0.000.000.00 0.00 0.00 0.00
> 0.000.000.000.00 0.00 0.00
> sdc 0.00 0.000.000.00 0.00 0.00 0.00
> 0.000.000.000.00 0.00 0.00
> md0 0.00 0.000.000.00 0.00 0.00 0.00
> 345.000.000.000.00 0.00 100.00
> md2 0.00 0.000.000.00 0.00 0.00 0.00
> 58779.000.000.000.00 0.00 100.00
> md1 0.00 0.000.000.00 0.00 0.00 0.00
> 12.000.000.000.00 0.00 100.00
> "
> The cause is commit "18c0b223cf9901727ef3b02da6711ac930b4e5d4" uses the
> generic_start_io_acct to account the disk stats rather than the open code,
> but it also introduced the increase to .in_flight[rw] which is needless to
> md. So we re-use the open code here to fix it.
>
> Reported-by: Simon Kirby
> Cc: 3.19
> Signed-off-by: Gu Zheng
> ---
> drivers/md/md.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 717daad..e617878 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -249,6 +249,7 @@ static void md_make_request(struct request_queue *q,
> struct bio *bio)
> const int rw = bio_data_dir(bio);
> struct mddev *mddev = q->queuedata;
> unsigned int sectors;
> + int cpu;
>
> if (mddev == NULL || mddev->pers == NULL
> || !mddev->ready) {
> @@ -284,7 +285,10 @@ static void md_make_request(struct request_queue *q,
> struct bio *bio)
> sectors = bio_sectors(bio);
> mddev->pers->make_request(mddev, bio);
>
> - generic_start_io_acct(rw, sectors, >gendisk->part0);
> + cpu = part_stat_lock();
> + part_stat_inc(cpu, >gendisk->part0, ios[rw]);
> + part_stat_add(cpu, >gendisk->part0, sectors[rw], sectors);
> + part_stat_unlock();
>
> if (atomic_dec_and_test(>active_io) && mddev->suspended)
> wake_up(>sb_wait);
Applied, thanks.
Will push to Linus in a day or 2.
NeilBrown
pgpavESYjSKE1.pgp
Description: OpenPGP digital signature
Re: [PATCH V2] x86/numa: kernel stack corruption fix
On 04/08/15 at 10:41am, Xishi Qiu wrote: > On 2015/4/8 10:18, Baoquan He wrote: > > > On 04/08/15 at 09:59am, Xishi Qiu wrote: > >> On 2015/4/8 9:46, Dave Young wrote: > >> > > > > - /* Mark all kernel nodes. */ > > + /* > > +* Mark all kernel nodes. > > +* > > +* In case booting with mem=nn[kMG] or in kdump kernel, > > numa_meminfo > > Hi Dave, > > It should both set mem=xx and numa=off, then numa_meminfo may not > include all > the memblock.reserved memory, right? > >>> > >>> Yasuaki Ishimatsu suggests to remove numa=off in comment because in > >>> theory there's such > >>> possiblity that it may happen even without numa=off. Just consider the > >>> non-snb board.. > >>> > >>> Thanks > >>> Dave > >>> > >> > >> Hi Dave, > >> > >> I made a mistake, when numa is on, numa_meminfo is from SRAT, but it will > >> be cut > >> in numa_cleanup_meminfo(), so the bug is not related to numa on/off. Your > >> comment > >> is right. > > > > Hi Xishi, > > > >>From code flow it's exact as you said. And if remove numa=off bug should > > be reproduced alwasy. I talked to Dave, he said error didn't occur when > > he remove numa=off. That is too weird. > > > > Hi Baoquan, > > May be it wrote over end of numa mask bitmap, but the stack can still run, > so there is no Call Trace. > How about add some printk to see if it has written over? Oops, Redhat kdump always add numa=off in 2nd kernel commandline, but I did not notice I removed it during test. So yes, the issue does not depend on numa=off. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] x86/numa: kernel stack corruption fix
On 2015/4/8 10:18, Baoquan He wrote: > On 04/08/15 at 09:59am, Xishi Qiu wrote: >> On 2015/4/8 9:46, Dave Young wrote: >> > > - /* Mark all kernel nodes. */ > + /* > + * Mark all kernel nodes. > + * > + * In case booting with mem=nn[kMG] or in kdump kernel, numa_meminfo Hi Dave, It should both set mem=xx and numa=off, then numa_meminfo may not include all the memblock.reserved memory, right? >>> >>> Yasuaki Ishimatsu suggests to remove numa=off in comment because in theory >>> there's such >>> possiblity that it may happen even without numa=off. Just consider the >>> non-snb board.. >>> >>> Thanks >>> Dave >>> >> >> Hi Dave, >> >> I made a mistake, when numa is on, numa_meminfo is from SRAT, but it will be >> cut >> in numa_cleanup_meminfo(), so the bug is not related to numa on/off. Your >> comment >> is right. > > Hi Xishi, > >>From code flow it's exact as you said. And if remove numa=off bug should > be reproduced alwasy. I talked to Dave, he said error didn't occur when > he remove numa=off. That is too weird. > Hi Baoquan, May be it wrote over end of numa mask bitmap, but the stack can still run, so there is no Call Trace. How about add some printk to see if it has written over? Thanks, Xishi Qiu > Thanks > Baoquan > >> >>> . >>> >> >> >> > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ext4 mballoc: fix tail allocation
On Mon, Apr 06, 2015 at 01:31:41PM -0600, Jun He wrote:
> This patch addresses the tail allocation problem found at paper "Reducing
> File System Tail Latencies with Chopper".
> https://www.usenix.org/system/files/conference/fast15/fast15-paper-he.pdf .
> The paper refers the tail allocation problem as the Special End problem.
Hi Jun He,
Kernel patches should have the commit body line-wrapped at 72 columns
(more or less). The idea is that the commit should be easily readable
on an 80 column screen, with some extra space left for identation (git
log will ident the commit body by 4 characters).
> A tail extent is the last extent of a file. The last block of the
> tail extent corresponds to the last logical block of the file. When
> a file is closed and the tail extent is being allocated, ext4 marks
> the allocation request with the hint EXT4_MB_HINT_NOPREALLOC. The
> intention is to avoid preallocation when we know the file is final
> (it won't change until the next open.). But the implementation leads
> to some problems. The following program attacks the problem.
I think you mean "the following program _demonstrates_ the problem".
> EXT4_MB_HINT_NOPREALLOC is not the right hint for special end. If we
> remove current check for tail in ext4_mb_group_or_file() , 1, 3, 4
> will be satisfied. Now, we only need to handle the tail of large
> file (2) by checking tail when normalizing. If it is a tail of large
> file, we simply do not normalize it.
The problem with skipping the normalization is this also by passes the
goal block optimizations based on pleft, pright, lleft, and lright.
In the case of a small file, it's not always true that you want to
allocate from a LG preallocation. If there is free space immediately
adjacent to file, we want to use that in preference to the LG
preallocation --- since that would result in a contiguous file.
> +
> + /* don't normalize tail of large files */
> + if ((size == isize) &&
> + !ext4_fs_is_busy(sbi) &&
> + (atomic_read(>ac_inode->i_writecount) == 0)) {
> + return;
> + }
The comment is a bit misleading; it's not checking for large files at
all. It also looks like that you copied the ext4_fs_is_busy(sbi) from
the original check.
Perhaps it would be helpful to explain the design goal of the original
code. As originally conceived, the problem we were trying to fix was
that in the case of unpacking a tar file with a large number of small
files, we wanted to make sure all of the files would be packed
togehter, without extra space reserved (caused by the normalization).
This was achieved by disabing the use of the locality group. The
problem is that if there are a large number of processes writing into
the same block group, this would cause contention, and so in the case
where we had contention, we would use the locality group (since the
whole point was to eliminate the need to constantly take the block
group lock while allocaitng out of the block group; that's why the
locality groups are per-cpu). That's what the ext4_fs_is_busy() is
all about. We try to measure contention and disable the optimization
if that was the case.
I suspect we may want to take a step back and what's the best way of
handling all of the high level goals, and refomulate a better strategy:
1) If the file doesn't have any blocks allocated yet, and it is closed
by the time we need to allocate all of its blocks (thanks to delayed
allocation), we should allocate exactly the number of blocks needed,
and try to avoid fragmenting free space.
2) In the case where we are doing any tails at all, it's a different
optimization altogether, and the main goal should be to make sure the
tail is connected the previous blocks if at all possible. To the
extent that we have per-CPU LG groups, this can be... problematic.
3) The primary goal of the per-group locality group is to avoid lock
contention when multiple CPU's are trying to access the blocks at the
same time. Depending on why we are doing block allocation, this may
not be an issue. We should probably into account why it is we re
doing block allocation at particular moment:
*) In the case of delayed allocation w/o fsync(2), the writeback
will be taking place from the writeback daemon. In that case,
all of allocations will be issued from a writeback thread, so
contention is much less of an issue. In addition, in the case
where the entire file has been written within 30 seconds, we
will be allocating the entire file at once, as described in (1).
This is a fairly common case, so we should optimize for it.
*) In the case of block allocations resulting from an fallocate(2),
we should assume userspace knew what it was doing, and we
shouldn't try to do any kind of size normalization. Also,
fallocate() calls generally don't happen with high frequency, so
worrying about CPU scalability is probalby not a major issue.
*) In the case of
Re: [PATCH 3/8] x86/asm/entry: Zero EXTRA_REGS for stub32_execve[at] too
On Tue, Apr 7, 2015 at 4:43 PM, Denys Vlasenko wrote: > The change which affected how execve clears EXTRA_REGS missed > 32-bit execve syscalls. > > Fix this by using 64-bit execve stub epilogue for them too. > > Run-tested. > > Signed-off-by: Denys Vlasenko > CC: Linus Torvalds > CC: Steven Rostedt > CC: Ingo Molnar > CC: Borislav Petkov > CC: "H. Peter Anvin" > CC: Andy Lutomirski > CC: Oleg Nesterov > CC: Frederic Weisbecker > CC: Alexei Starovoitov > CC: Will Drewry > CC: Kees Cook > CC: x...@kernel.org > CC: linux-kernel@vger.kernel.org > --- > arch/x86/ia32/ia32entry.S | 2 -- > arch/x86/kernel/entry_64.S | 15 +++ > 2 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S > index 5d8f987..a821b1c 100644 > --- a/arch/x86/ia32/ia32entry.S > +++ b/arch/x86/ia32/ia32entry.S > @@ -571,8 +571,6 @@ GLOBAL(\label) > > PTREGSCALL stub32_rt_sigreturn, sys32_rt_sigreturn > PTREGSCALL stub32_sigreturn, sys32_sigreturn > - PTREGSCALL stub32_execve, compat_sys_execve > - PTREGSCALL stub32_execveat, compat_sys_execveat > PTREGSCALL stub32_fork, sys_fork > PTREGSCALL stub32_vfork, sys_vfork > > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S > index 1b0793c..8e3ba38 100644 > --- a/arch/x86/kernel/entry_64.S > +++ b/arch/x86/kernel/entry_64.S > @@ -461,6 +461,21 @@ ENTRY(stub_x32_execveat) > END(stub_x32_execveat) > #endif > > +#ifdef CONFIG_IA32_EMULATION > +ENTRY(stub32_execve) > + CFI_STARTPROC > + callcompat_sys_execve > + jmp return_from_execve > + CFI_ENDPROC > +END(stub32_execve) > +ENTRY(stub32_execveat) > + CFI_STARTPROC > + callcompat_sys_execveat > + jmp return_from_execve > + CFI_ENDPROC > +END(stub32_execveat) > +#endif > + > /* > * sigreturn is special because it needs to restore all registers on return. > * This cannot be done with SYSRET, so use the IRET return path instead. The X32 and IA32 stubs are now identical and should be merged. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -tip] perf probe: fix ARM 32 building error.
(2015/04/08 11:14), Wang Nan wrote:
> Commit 9b118acae310f57baee770b5db402500d8695e50 ("perf probe: Fix to
> handle aliased symbols in glibc") uses an absolute format '%lx' to
> print u64 argument, which causes compiling error on ARM 32.
>
> This patch replaces it with PRIx64.
Good catch! :)
Acked-by: Masami Hiramatsu
Thanks!
>
> Signed-off-by: Wang Nan
> ---
> tools/perf/util/probe-event.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 8feac07..3dacec9 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -320,7 +320,8 @@ static int find_alternative_probe_point(struct debuginfo
> *dinfo,
> ret = -ENOENT;
> goto out;
> }
> - pr_debug("Symbol %s address found : %lx\n", pp->function, address);
> + pr_debug("Symbol %s address found : %" PRIx64 "\n",
> + pp->function, address);
>
> ret = debuginfo__find_probe_point(dinfo, (unsigned long)address,
> result);
>
--
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: add core audio driver for Broadcom Cygnus SOC.
On 15-04-06 09:19 AM, Mark Brown wrote: On Thu, Apr 02, 2015 at 11:47:18AM -0700, Lori Hikichi wrote: On 15-03-30 11:42 PM, Mark Brown wrote: +config SND_SOC_CYGNUS + tristate "SoC platform audio for Broadcom Cygnus chips" + depends on ARCH_BCM_CYGNUS || COMPILE_TEST + default ARCH_BCM_CYGNUS Okay. You don't need to reply to every single comment, the general assumption will be that if there's no other followup all review comments will be addressed. It's better to just reply to things where there's something more detailed to say, if you explicitly reply to everything then that makes it easier for actual replies to be missed since there's a lot of there's a lot of the mail that's just going to be skipped through. +static void ringbuf_inc(void __iomem *audio_io, bool is_playback, + const struct ringbuf_regs *p_rbuf) So it looks like we're getting an interrupt per period and we have to manually advance to the next one? Yes. OK, so that seems fragile - what happens if we're slightly late processing an interrupt or miss one entirely? Most hardware has some way to read back the current position which tends to be more reliable, is that not an option here? The hardware updates a read pointer (rdaddr) which we feed to ALSA via the ".pointer" hook. So yes, the hardware does have a register that tells us its progress. This routine (ringbuf_inc) actually updates a write pointer (wraddr) which is a misnomer. The write pointer doesn’t actually tell us where we are writing to – ALSA keeps track of that. The wraddr only prevents the hardware from reading past it. We just use it, along with a low water mark configuration register, to keep the periodic interrupts firing. The hardware is tracking the distance between rdaddr and wraddr and comparing that to the low water mark. Being late processing the interrupt is okay since there are more samples to read. That is, it was only a low water mark interrupt and we have one period of valid data still (we configure low water to be one period). Missing an interrupt is okay since the hardware will just stop reading from the ring buffer when rdaddr has hit wraddr. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Cygnus Audio Driver
On 15-04-06 02:58 AM, Mark Brown wrote: On Fri, Apr 03, 2015 at 12:33:12PM -0700, Scott Branden wrote: On 15-03-30 11:43 PM, Mark Brown wrote: On Mon, Mar 30, 2015 at 08:16:22PM -0700, Scott Branden wrote: The audio PLL is embedded in the audio block and only used by the audio block. The audio PLL registers are also in the middle of the audio register map. When you say it's only used by the audio block do you mean to say that the audio block exposes no clock signals other than the bit and frame clocks? The audio block exposes the MCLK in addition to the bit and frame clock. OK, then it's going to need to be a clock provider at some point - the clock will be going into external devices which are going to need to be able to interact with the clock (for example, to get the rate). Currently, the ASoC machine driver is responsible for requesting a certain frequency of MCLK be generated from our driver and then also sending the frequency information along to the external device (codec). This is done via the snd_soc_dai_set_sysclk. That is the only clock interaction we have needed for the core part of the driver. For enhanced features, we also have the need to make minor adjustments (tweaks) to the PLL. The tweaks are used to make the PLLs output frequency match as closely as possible to a true reference frequency. As such, we would like to provide the finest adjustment resolution as possible. The clocking framework only seems to allow for a 1 Hz adjustment. This limitation and the fact that no other device seems to need to interact directly will the PLL are why we have not put it in the clocking framework. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] x86/numa: kernel stack corruption fix
On 04/08/15 at 09:59am, Xishi Qiu wrote: > On 2015/4/8 9:46, Dave Young wrote: > > >>> > >>> - /* Mark all kernel nodes. */ > >>> + /* > >>> + * Mark all kernel nodes. > >>> + * > >>> + * In case booting with mem=nn[kMG] or in kdump kernel, numa_meminfo > >> > >> Hi Dave, > >> > >> It should both set mem=xx and numa=off, then numa_meminfo may not include > >> all > >> the memblock.reserved memory, right? > > > > Yasuaki Ishimatsu suggests to remove numa=off in comment because in theory > > there's such > > possiblity that it may happen even without numa=off. Just consider the > > non-snb board.. > > > > Thanks > > Dave > > > > Hi Dave, > > I made a mistake, when numa is on, numa_meminfo is from SRAT, but it will be > cut > in numa_cleanup_meminfo(), so the bug is not related to numa on/off. Your > comment > is right. Hi Xishi, >From code flow it's exact as you said. And if remove numa=off bug should be reproduced alwasy. I talked to Dave, he said error didn't occur when he remove numa=off. That is too weird. Thanks Baoquan > > > > . > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -tip] perf probe: fix ARM 32 building error.
Commit 9b118acae310f57baee770b5db402500d8695e50 ("perf probe: Fix to
handle aliased symbols in glibc") uses an absolute format '%lx' to
print u64 argument, which causes compiling error on ARM 32.
This patch replaces it with PRIx64.
Signed-off-by: Wang Nan
---
tools/perf/util/probe-event.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 8feac07..3dacec9 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -320,7 +320,8 @@ static int find_alternative_probe_point(struct debuginfo
*dinfo,
ret = -ENOENT;
goto out;
}
- pr_debug("Symbol %s address found : %lx\n", pp->function, address);
+ pr_debug("Symbol %s address found : %" PRIx64 "\n",
+ pp->function, address);
ret = debuginfo__find_probe_point(dinfo, (unsigned long)address,
result);
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
blk-mq : blk_mq_map_swqueue maybe
Hi Jens,
In blk_mq_map_swqueue(), all the blk_mq_hw_ctx's nr_ctx are set
to zero, and then each blk_mq_ctx's index_hw is set to nr_ctx.
I think the index_hw means the index of the hardware queue that map
to this software queue, so maybe index_hw should be set to
blk_mq_hw_ctx's queue_num.
I'm a student and I probably have misunderstood this code, please help
me to resolve this confusion. Thank you.
static void blk_mq_map_swqueue(struct request_queue *q)
{
.
queue_for_each_hw_ctx(q, hctx, i) {
.
hctx->nr_ctx = 0;
}
.
queue_for_each_ctx(q, ctx, i) {
.
ctx->index_hw = hctx->nr_ctx;
.
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] x86/numa: kernel stack corruption fix
On 2015/4/8 9:46, Dave Young wrote: >>> >>> - /* Mark all kernel nodes. */ >>> + /* >>> +* Mark all kernel nodes. >>> +* >>> +* In case booting with mem=nn[kMG] or in kdump kernel, numa_meminfo >> >> Hi Dave, >> >> It should both set mem=xx and numa=off, then numa_meminfo may not include all >> the memblock.reserved memory, right? > > Yasuaki Ishimatsu suggests to remove numa=off in comment because in theory > there's such > possiblity that it may happen even without numa=off. Just consider the > non-snb board.. > > Thanks > Dave > Hi Dave, I made a mistake, when numa is on, numa_meminfo is from SRAT, but it will be cut in numa_cleanup_meminfo(), so the bug is not related to numa on/off. Your comment is right. Reviewed-by: Xishi Qiu > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] (xen) stable/for-jens-4.1
On 04/07/2015 08:56 AM, Konrad Rzeszutek Wilk wrote: Hey Jens, Please git pull the following tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.1 which is based on your for-4.1/drivers branch. Specifically commit de9ad6d4edb63e0ba5d5aae365fb3565064fc00d "nbd: Return error pointer directly". This pull has one fix and an cleanup. Note that David Vrabel in the xen/tip.git tree has other changes for the Xen block drivers that are related to his grant work - and they do not conflict with this git pull. Thanks Konrad, pulled. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: Add support for PM8916 GPIO's and MPP's
On Tue, Mar 31, 2015 at 2:37 AM, Ivan T. Ivanov wrote: > Add compatible string definitions and supported pin functions. > > Signed-off-by: Ivan T. Ivanov > --- [..] > diff --git a/include/dt-bindings/pinctrl/qcom,pmic-gpio.h > b/include/dt-bindings/pinctrl/qcom,pmic-gpio.h [..] > > +#define PM8916_GPIO1_BAT_ALRM_OUT PMIC_GPIO_FUNC_FUNC1 > +#define PM8916_GPIO1_KEYP_DRV PMIC_GPIO_FUNC_FUNC2 > +#define PM8916_GPIO2_DIV_CLK PMIC_GPIO_FUNC_FUNC1 > +#define PM8916_GPIO2_SLEEP_CLK PMIC_GPIO_FUNC_FUNC2 > +#define PM8916_GPIO3_KEYP_DRV PMIC_GPIO_FUNC_FUNC1 > +#define PM8916_GPIO4_KEYP_DRV PMIC_GPIO_FUNC_FUNC2 > + The documentation I have for the PM8916 is vague, but lists slightly different functions. Andy, could you help out with verifying the functions of the gpios on this pmic? For the rest of the patch: Acked-by: Bjorn Andersson Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: show free pages per each migrate type
show detailed free pages per each migrate type in show_free_areas.
Signed-off-by: Neil Zhang
---
mm/internal.h |2 ++
mm/page_alloc.c | 55 ++-
mm/vmstat.c | 13 -
3 files changed, 28 insertions(+), 42 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index a96da5b..5cb3079 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -14,6 +14,8 @@
#include
#include
+extern char * const migratetype_names[MIGRATE_TYPES];
+
void free_pgtables(struct mmu_gather *tlb, struct vm_area_struct *start_vma,
unsigned long floor, unsigned long ceiling);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 40e2942..2d70892 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3170,32 +3170,18 @@ out:
#define K(x) ((x) << (PAGE_SHIFT-10))
-static void show_migration_types(unsigned char type)
-{
- static const char types[MIGRATE_TYPES] = {
- [MIGRATE_UNMOVABLE] = 'U',
- [MIGRATE_RECLAIMABLE] = 'E',
- [MIGRATE_MOVABLE] = 'M',
- [MIGRATE_RESERVE] = 'R',
+char * const migratetype_names[MIGRATE_TYPES] = {
+ "Unmovable",
+ "Reclaimable",
+ "Movable",
+ "Reserve",
#ifdef CONFIG_CMA
- [MIGRATE_CMA] = 'C',
+ "CMA",
#endif
#ifdef CONFIG_MEMORY_ISOLATION
- [MIGRATE_ISOLATE] = 'I',
+ "Isolate",
#endif
- };
- char tmp[MIGRATE_TYPES + 1];
- char *p = tmp;
- int i;
-
- for (i = 0; i < MIGRATE_TYPES; i++) {
- if (type & (1 << i))
- *p++ = types[i];
- }
-
- *p = '\0';
- printk("(%s) ", tmp);
-}
+};
/*
* Show free area list (used inside shift_scroll-lock stuff)
@@ -3327,7 +3313,7 @@ void show_free_areas(unsigned int filter)
for_each_populated_zone(zone) {
unsigned long nr[MAX_ORDER], flags, order, total = 0;
- unsigned char types[MAX_ORDER];
+ unsigned long nr_free[MAX_ORDER][MIGRATE_TYPES], mtype;
if (skip_free_areas_node(filter, zone_to_nid(zone)))
continue;
@@ -3337,24 +3323,35 @@ void show_free_areas(unsigned int filter)
spin_lock_irqsave(>lock, flags);
for (order = 0; order < MAX_ORDER; order++) {
struct free_area *area = >free_area[order];
+ struct list_head *curr;
int type;
nr[order] = area->nr_free;
total += nr[order] << order;
- types[order] = 0;
for (type = 0; type < MIGRATE_TYPES; type++) {
+ nr_free[order][type] = 0;
if (!list_empty(>free_list[type]))
- types[order] |= 1 << type;
+ list_for_each(curr,
>free_list[type])
+ nr_free[order][type]++;
}
}
spin_unlock_irqrestore(>lock, flags);
- for (order = 0; order < MAX_ORDER; order++) {
+ for (order = 0; order < MAX_ORDER; order++)
printk("%lu*%lukB ", nr[order], K(1UL) << order);
- if (nr[order])
- show_migration_types(types[order]);
- }
printk("= %lukB\n", K(total));
+
+ printk("%12s: ", "orders");
+ for (order = 0; order < MAX_ORDER; order++)
+ printk("%6lu ", order);
+ printk("\n");
+
+ for (mtype = 0; mtype < MIGRATE_TYPES; mtype++) {
+ printk("%12s: ", migratetype_names[mtype]);
+ for (order = 0; order < MAX_ORDER; order++)
+ printk("%6lu ", nr_free[order][mtype]);
+ printk("\n");
+ }
}
hugetlb_show_meminfo();
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 4f5cd97..699eeb3 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -897,19 +897,6 @@ static void walk_zones_in_node(struct seq_file *m,
pg_data_t *pgdat,
#endif
#ifdef CONFIG_PROC_FS
-static char * const migratetype_names[MIGRATE_TYPES] = {
- "Unmovable",
- "Reclaimable",
- "Movable",
- "Reserve",
-#ifdef CONFIG_CMA
- "CMA",
-#endif
-#ifdef CONFIG_MEMORY_ISOLATION
- "Isolate",
-#endif
-};
-
static void frag_show_print(struct seq_file *m, pg_data_t *pgdat,
struct zone *zone)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [RFC PATCH v3 1/2] memory-failure: export page_type and action result
On Tue, Apr 07, 2015 at 07:05:30PM +0800, Xie XiuQi wrote:
> Export 'outcome' and 'page_type' to mm.h, so we could use this emnus
> outside.
>
> This patch is preparation for adding trace events for memory-failure
> recovery action.
>
> Signed-off-by: Xie XiuQi
I made some update on mm/memory-failure.c, so some more rebasing is needed.
Please see
mm-memory-failurec-define-page-types-for-action_result-in-one-place-v3
in latest linux-mmotm.
Other than that, this patch looks good to me.
Thanks,
Naoya Horiguchi
> ---
> include/linux/mm.h | 34 +++
> mm/memory-failure.c | 163
> +---
> 2 files changed, 99 insertions(+), 98 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 4a3a385..5d812b0 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2114,6 +2114,40 @@ extern void shake_page(struct page *p, int access);
> extern atomic_long_t num_poisoned_pages;
> extern int soft_offline_page(struct page *page, int flags);
>
> +
> +/*
> + * Error handlers for various types of pages.
> + */
> +enum mf_outcome {
> + MF_IGNORED, /* Error: cannot be handled */
> + MF_FAILED, /* Error: handling failed */
> + MF_DELAYED, /* Will be handled later */
> + MF_RECOVERED, /* Successfully recovered */
> +};
> +
> +enum mf_page_type {
> + MF_KERNEL,
> + MF_KERNEL_HIGH_ORDER,
> + MF_SLAB,
> + MF_DIFFERENT_COMPOUND,
> + MF_POISONED_HUGE,
> + MF_HUGE,
> + MF_FREE_HUGE,
> + MF_UNMAP_FAILED,
> + MF_DIRTY_SWAPCACHE,
> + MF_CLEAN_SWAPCACHE,
> + MF_DIRTY_MLOCKED_LRU,
> + MF_CLEAN_MLOCKED_LRU,
> + MF_DIRTY_UNEVICTABLE_LRU,
> + MF_CLEAN_UNEVICTABLE_LRU,
> + MF_DIRTY_LRU,
> + MF_CLEAN_LRU,
> + MF_TRUNCATED_LRU,
> + MF_BUDDY,
> + MF_BUDDY_2ND,
> + MF_UNKNOWN,
> +};
> +
> #if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLBFS)
> extern void clear_huge_page(struct page *page,
> unsigned long addr,
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 5074998..34e9c65 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -56,6 +56,7 @@
> #include
> #include
> #include "internal.h"
> +#include "ras/ras_event.h"
>
> int sysctl_memory_failure_early_kill __read_mostly = 0;
>
> @@ -503,68 +504,34 @@ static void collect_procs(struct page *page, struct
> list_head *tokill,
> kfree(tk);
> }
>
> -/*
> - * Error handlers for various types of pages.
> - */
> -
> -enum outcome {
> - IGNORED,/* Error: cannot be handled */
> - FAILED, /* Error: handling failed */
> - DELAYED,/* Will be handled later */
> - RECOVERED, /* Successfully recovered */
> -};
> -
> static const char *action_name[] = {
> - [IGNORED] = "Ignored",
> - [FAILED] = "Failed",
> - [DELAYED] = "Delayed",
> - [RECOVERED] = "Recovered",
> -};
> -
> -enum page_type {
> - KERNEL,
> - KERNEL_HIGH_ORDER,
> - SLAB,
> - DIFFERENT_COMPOUND,
> - POISONED_HUGE,
> - HUGE,
> - FREE_HUGE,
> - UNMAP_FAILED,
> - DIRTY_SWAPCACHE,
> - CLEAN_SWAPCACHE,
> - DIRTY_MLOCKED_LRU,
> - CLEAN_MLOCKED_LRU,
> - DIRTY_UNEVICTABLE_LRU,
> - CLEAN_UNEVICTABLE_LRU,
> - DIRTY_LRU,
> - CLEAN_LRU,
> - TRUNCATED_LRU,
> - BUDDY,
> - BUDDY_2ND,
> - UNKNOWN,
> + [MF_IGNORED] = "Ignored",
> + [MF_FAILED] = "Failed",
> + [MF_DELAYED] = "Delayed",
> + [MF_RECOVERED] = "Recovered",
> };
>
> static const char *action_page_type[] = {
> - [KERNEL]= "reserved kernel page",
> - [KERNEL_HIGH_ORDER] = "high-order kernel page",
> - [SLAB] = "kernel slab page",
> - [DIFFERENT_COMPOUND]= "different compound page after locking",
> - [POISONED_HUGE] = "huge page already hardware poisoned",
> - [HUGE] = "huge page",
> - [FREE_HUGE] = "free huge page",
> - [UNMAP_FAILED] = "unmapping failed page",
> - [DIRTY_SWAPCACHE] = "dirty swapcache page",
> - [CLEAN_SWAPCACHE] = "clean swapcache page",
> - [DIRTY_MLOCKED_LRU] = "dirty mlocked LRU page",
> - [CLEAN_MLOCKED_LRU] = "clean mlocked LRU page",
> - [DIRTY_UNEVICTABLE_LRU] = "dirty unevictable LRU page",
> - [CLEAN_UNEVICTABLE_LRU] = "clean unevictable LRU page",
> - [DIRTY_LRU] = "dirty LRU page",
> - [CLEAN_LRU] = "clean LRU page",
> - [TRUNCATED_LRU] = "already truncated LRU page",
> - [BUDDY] = "free buddy page",
> - [BUDDY_2ND] = "free buddy page (2nd try)",
> - [UNKNOWN] = "unknown page",
> + [MF_KERNEL] = "reserved kernel page",
> + [MF_KERNEL_HIGH_ORDER] = "high-order kernel page",
> + [MF_SLAB] = "kernel slab
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hi Javier,
On Tue, Apr 7, 2015 at 8:30 PM, Javier Martinez Canillas
wrote:
> Hello Abhilash,
>
> On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:
>>>
>>> [0]
>>> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
>>> From: Javier Martinez Canillas
>>> Date: Tue, 7 Apr 2015 15:53:27 +0200
>>> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>>>
>>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>>> Management support v12") added pm support for the pl330 dma driver but
>>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>>> during suspend and this in turn makes its parent clock aclk266_g2d to
>>> be gated. But the clock needs to be ungated prior suspend to allow the
>>> system to be suspend and resumed correctly.
>>>
>>> Add GATE_BUS_TOP register to the list of registers to be restored when
>>> the system enters into a suspend state so aclk266_g2d will be ungated.
>>>
>>> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>>>
>>> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>>> Management support v12")
>>> Signed-off-by: Javier Martinez Canillas
>>> ---
>>> drivers/clk/samsung/clk-exynos5420.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>>> b/drivers/clk/samsung/clk-exynos5420.c
>>> index 07d666cc6a29..bea4a173eef5 100644
>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump
>>> exynos5420_set_clksrc[] = {
>>> { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
>>> { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
>>> { .offset = SRC_MASK_ISP, .value = 0x1000, },
>>> + { .offset = GATE_BUS_TOP, .value = 0x, },
>>> { .offset = GATE_BUS_DISP1, .value = 0x, },
>>> { .offset = GATE_IP_PERIC, .value = 0x, },
>>> };
>>
>> While there could be a concern that we are ungating all the clocks in
>
> Yes, I mentioned that but OTOH it will be even more dangerous to gate
> clocks that should remain enabled so I used the register default values.
>
>> BUS_TOP, this looks like the least intrusive fix for the issue. Tested
>> this on Peach Pi, S2R works fine.
>>
>
> Thanks a lot for testing, does it mean I can add your Tested-by then when
> posting it as a proper patch? I'll wait for Tomasz to comment before though.
Tested-by: Abhilash Kesavan .
Abhilash
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] x86/numa: kernel stack corruption fix
> > > > - /* Mark all kernel nodes. */ > > + /* > > +* Mark all kernel nodes. > > +* > > +* In case booting with mem=nn[kMG] or in kdump kernel, numa_meminfo > > Hi Dave, > > It should both set mem=xx and numa=off, then numa_meminfo may not include all > the memblock.reserved memory, right? Yasuaki Ishimatsu suggests to remove numa=off in comment because in theory there's such possiblity that it may happen even without numa=off. Just consider the non-snb board.. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/2] tracing: add trace event for memory-failure
On Tue, Apr 07, 2015 at 07:05:31PM +0800, Xie XiuQi wrote:
> RAS user space tools like rasdaemon which base on trace event, could
> receive mce error event, but no memory recovery result event. So, I
> want to add this event to make this scenario complete.
>
> This patch add a event at ras group for memory-failure.
>
> The output like below:
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 2/2 #P:24
> #
> # _-=> irqs-off
> # / _=> need-resched
> # | / _---=> hardirq/softirq
> # || / _--=> preempt-depth
> # ||| / delay
> #TASK-PID CPU# TIMESTAMP FUNCTION
> # | | | | |
>mce-inject-13150 [001] 277.019359: memory_failure_event: pfn
> 0x19869: recovery action for free buddy page: Delayed
>
>
> Cc: Tony Luck
> Cc: Steven Rostedt
> Signed-off-by: Xie XiuQi
> ---
> include/ras/ras_event.h | 83
> +
> kernel/trace/trace.c| 2 +-
> mm/memory-failure.c | 2 ++
> 3 files changed, 86 insertions(+), 1 deletion(-)
>
> diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
> index 79abb9c..52c75f2 100644
> --- a/include/ras/ras_event.h
> +++ b/include/ras/ras_event.h
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * MCE Extended Error Log trace event
> @@ -232,6 +233,88 @@ TRACE_EVENT(aer_event,
> __print_flags(__entry->status, "|", aer_uncorrectable_errors))
> );
>
> +/*
> + * memory-failure recovery action result event
> + *
> + * unsigned long pfn - Page Number of the corrupted page
Hi XiuQi,
I think "Page Frame Number" is better.
And embracing these definition code with #ifdef CONFIG_MEMORY_FAILURE might
be helpful if it reduces binary size for !CONFIG_MEMORY_FAILURE build?
Thanks,
Naoya Horiguchi
> + * int type - Page types of the corrupted page
> + * int result- Result of recovery action
> + */
> +
> +#define MF_ACTION_RESULT \
> + EM ( MF_IGNORED, "Ignord" ) \
> + EM ( MF_FAILED, "Failed" ) \
> + EM ( MF_DELAYED, "Delayed" )\
> + EMe ( MF_RECOVERED, "Recovered" )
> +
> +#define MF_PAGE_TYPE \
> + EM ( MF_KERNEL, "reserved kernel page" )\
> + EM ( MF_KERNEL_HIGH_ORDER, "high-order kernel page" ) \
> + EM ( MF_SLAB, "kernel slab page" ) \
> + EM ( MF_DIFFERENT_COMPOUND, "different compound page after locking" ) \
> + EM ( MF_POISONED_HUGE, "huge page already hardware poisoned" ) \
> + EM ( MF_HUGE, "huge page" ) \
> + EM ( MF_FREE_HUGE, "free huge page" ) \
> + EM ( MF_UNMAP_FAILED, "unmapping failed page" ) \
> + EM ( MF_DIRTY_SWAPCACHE, "dirty swapcache page" ) \
> + EM ( MF_CLEAN_SWAPCACHE, "clean swapcache page" ) \
> + EM ( MF_DIRTY_MLOCKED_LRU, "dirty mlocked LRU page" ) \
> + EM ( MF_CLEAN_MLOCKED_LRU, "clean mlocked LRU page" ) \
> + EM ( MF_DIRTY_UNEVICTABLE_LRU, "dirty unevictable LRU page" ) \
> + EM ( MF_CLEAN_UNEVICTABLE_LRU, "clean unevictable LRU page" ) \
> + EM ( MF_DIRTY_LRU, "dirty LRU page" ) \
> + EM ( MF_CLEAN_LRU, "clean LRU page" ) \
> + EM ( MF_TRUNCATED_LRU, "already truncated LRU page" ) \
> + EM ( MF_BUDDY, "free buddy page" ) \
> + EM ( MF_BUDDY_2ND, "free buddy page (2nd try)" )\
> + EMe ( MF_UNKNOWN, "unknown page" )
> +
> +/*
> + * First define the enums in MM_ACTION_RESULT to be exported to userspace
> + * via TRACE_DEFINE_ENUM().
> + */
> +#undef EM
> +#undef EMe
> +#define EM(a,b) TRACE_DEFINE_ENUM(a);
> +#define EMe(a,b) TRACE_DEFINE_ENUM(a);
> +
> +MF_ACTION_RESULT
> +MF_PAGE_TYPE
> +
> +/*
> + * Now redefine the EM() and EMe() macros to map the enums to the strings
> + * that will be printed in the output.
> + */
> +#undef EM
> +#undef EMe
> +#define EM(a,b) { a, b },
> +#define EMe(a,b) { a, b }
> +
> +TRACE_EVENT(memory_failure_event,
> + TP_PROTO(unsigned long pfn,
> + int type,
> + int result),
> +
> + TP_ARGS(pfn, type, result),
> +
> + TP_STRUCT__entry(
> + __field(unsigned long, pfn)
> + __field(int, type)
> + __field(int, result)
> + ),
> +
> + TP_fast_assign(
> + __entry->pfn= pfn;
> + __entry->type = type;
> + __entry->result = result;
> + ),
> +
> + TP_printk("pfn %#lx: recovery action for %s: %s",
> + __entry->pfn,
> + __print_symbolic(__entry->type, MF_PAGE_TYPE),
> +
Re: [PATCH V2] x86/numa: kernel stack corruption fix
On 2015/4/7 21:41, Dave Young wrote: > I got below kernel panic during kdump test on Thinkpad T420 laptop: > > [0.00] No NUMA configuration found > > [0.00] Faking a node at [mem 0x-0x37ba4fff] > > [0.00] Kernel panic - not syncing: stack-protector: Kernel stack is > cor > upted in: 81d21910 > r > [0.00] > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0-rc6+ #44 > > [0.00] Hardware name: LENOVO 4236NUC/4236NUC, BIOS 83ET76WW (1.46 ) > 07/ > 5/2013 > 0 > [0.00] c70296ddd809e4f6 81b67ce8 > 817c > a26 > 2 > [0.00] 81a61c90 81b67d68 > 817b > 8d2 > c > [0.00] 0010 81b67d78 81b67d18 > c70296ddd809 > 4f6 > e > [0.00] Call Trace: > > [0.00] [] dump_stack+0x45/0x57 > > [0.00] [] panic+0xd0/0x204 > > [0.00] [] ? > numa_clear_kernel_node_hotplug+0xe6/0xf2 > [0.00] [] __stack_chk_fail+0x1b/0x20 > > [0.00] [] numa_clear_kernel_node_hotplug+0xe6/0xf2 > > [0.00] [] numa_init+0x1a5/0x520 > > [0.00] [] x86_numa_init+0x19/0x3d > > [0.00] [] initmem_init+0x9/0xb > > [0.00] [] setup_arch+0x94f/0xc82 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] ? printk+0x55/0x6b > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] start_kernel+0xe8/0x4d6 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] x86_64_start_reservations+0x2a/0x2c > > [0.00] [] x86_64_start_kernel+0x161/0x184 > > [0.00] ---[ end Kernel panic - not syncing: stack-protector: Kernel > sta > k is corrupted in: 81d21910 > c > [0.00] > > PANIC: early exception 0d rip 10:8105d2a6 error 7eb cr2 > 8800371dd00 > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0-rc6+ #44 > 0 > [0.00] Hardware name: LENOVO 4236NUC/4236NUC, BIOS 83ET76WW (1.46 ) > 07/ > 5/2013 > 0 > [0.00] c70296ddd809e4f6 81b67c60 > 817c > a26 > 2 > [0.00] 0096 81a61c90 81b67d68 > fff0 > 084 0a0d 0a00 > 0 > [0.00] Call Trace: > > [0.00] [] dump_stack+0x45/0x57 > > [0.00] [] early_idt_handler+0x90/0xb7 > > [0.00] [] ? native_irq_enable+0x6/0x10 > > [0.00] [] ? panic+0x1c3/0x204 > > [0.00] [] ? > numa_clear_kernel_node_hotplug+0xe6/0xf2 > [0.00] [] __stack_chk_fail+0x1b/0x20 > > [0.00] [] numa_clear_kernel_node_hotplug+0xe6/0xf2 > > [0.00] [] numa_init+0x1a5/0x520 > > [0.00] [] x86_numa_init+0x19/0x3d > > [0.00] [] initmem_init+0x9/0xb > > [0.00] [] setup_arch+0x94f/0xc82 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] ? printk+0x55/0x6b > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] start_kernel+0xe8/0x4d6 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] x86_64_start_reservations+0x2a/0x2c > > [0.00] [] x86_64_start_kernel+0x161/0x184 > > [0.00] RIP 0x46 > > > This is caused by writing
Re: [PATCH] [PATCH v3] mtd:spi-nor: Add Altera Quad SPI Driver
Hi Brian,
Can you help me to review this patch of mine?
Thanks,
Nga
On Mon, Mar 16, 2015 at 4:16 PM, wrote:
> From: VIET NGA DAO
>
> Altera Quad SPI Controller is a soft IP which enables access to Altera EPCQ
> and
> EPCS flash chips. This patch adds driver for these devices.
>
> Signed-off-by: VIET NGA DAO
>
> ---
> v3:
> - Change altera_epcq driver name to altera_quadspi for more generic name
> - Implement flash name searching in altera_quadspi.c instead of spi-nor
> - Edit the altra quadspi info table in spi-nor
> - Remove wait_til_ready in all read,write, erase, lock, unlock functions
> - Merge .h and .c into 1 file
>
> v2:
> - Change to spi_nor structure
> - Add lock and unlock functions for spi_nor
> - Simplify the altera_epcq_lock function
> - Replace reg by compatible in device tree
> ---
> .../devicetree/bindings/mtd/altera_quadspi.txt | 45 ++
> drivers/mtd/spi-nor/Kconfig| 8 +
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/altera_quadspi.c | 608
> +
> drivers/mtd/spi-nor/spi-nor.c | 11 +
> 5 files changed, 673 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/altera_quadspi.txt
> create mode 100644 drivers/mtd/spi-nor/altera_quadspi.c
>
> diff --git a/Documentation/devicetree/bindings/mtd/altera_quadspi.txt
> b/Documentation/devicetree/bindings/mtd/altera_quadspi.txt
> new file mode 100644
> index 000..f5bdd35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/altera_quadspi.txt
> @@ -0,0 +1,45 @@
> +* MTD Altera QUADSPI driver
> +
> +Required properties:
> +- compatible: Should be "altr,quadspi-1.0"
> +- reg: Address and length of the register set for the device. It contains
> + the information of registers in the same order as described by reg-names
> +- reg-names: Should contain the reg names
> + "csr_base": Should contain the register configuration base address
> + "data_base": Should contain the data base address
> +- is-epcs: boolean type.
> + If present, the device contains EPCS flashes.
> + Otherwise, it contains EPCQ flashes.
> +- #address-cells: Must be <1>.
> +- #size-cells: Must be <0>.
> +- flash device tree subnode, there must be a node with the following fields:
> + - compatible: Should contain the flash name
> + - #address-cells: please refer to /mtd/partition.txt
> + - #size-cells: please refer to /mtd/partition.txt
> + For partitions inside each flash, please refer to /mtd/partition.txt
> +
> +Example:
> +
> + quadspi_controller_0: quadspi@0x0 {
> + compatible = "altr,quadspi-1.0";
> + reg = <0x0001 0x 0x0020>,
> + <0x 0x 0x0200>;
> + reg-names = "csr_base", "data_base";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + flash0: epcq256@0 {
> + compatible = "epcq256-nonjedec";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + /* 16 MB for raw data. */
> + label = "EPCQ Flash 0 raw
> data";
> + reg = <0x0 0x100>;
> + };
> + partition@100 {
> + /* 16 MB for jffs2 data. */
> + label = "EPCQ Flash 0 JFFS 2";
> + reg = <0x100 0x100>;
> + };
> + };
> + }; //end quadspi@0x0 (quadspi_controller_0)
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 64a4f0e..b9eed6d 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -28,4 +28,12 @@ config SPI_FSL_QUADSPI
> This enables support for the Quad SPI controller in master mode.
> We only connect the NOR to this controller now.
>
> +config SPI_ALTERA_QUADSPI
> + tristate "Support Altera EPCQ/EPCS Flash chips"
> + depends on OF
> + help
> + This enables access to Altera EPCQ/EPCS flash chips, used for data
> + storage. See the driver source for the current list,
> + or to add other chips.
> +
> endif # MTD_SPI_NOR
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 6a7ce14..1a36a72 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++
Re: [PATCH] fix platform_no_drv_owner.cocci warnings
On Tue, Apr 07, 2015 at 03:09:46PM +0200, Linus Walleij wrote: > On Mon, Mar 30, 2015 at 3:05 PM, Thierry Reding wrote: > > On Sun, Mar 29, 2015 at 03:49:20PM +0800, kbuild test robot wrote: > >> drivers/pinctrl/pinctrl-max77620.c:472:3-8: No need to set .owner here. > >> The core will do it. > >> > >> Remove .owner field if calls are used which set it automatically > >> > >> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci > >> > >> CC: Alexandre Courbot > >> Signed-off-by: Fengguang Wu > >> --- > >> > >> pinctrl-max77620.c |1 - > >> 1 file changed, 1 deletion(-) > > > > Hi Linus, > > > > please ignore this. It's from a staging tree and against a driver that > > doesn't exist upstream yet. I have for now removed these branches from > > my github tree completely until we can figure out a way to keep the 0- > > day builder from generating these patches. > > Bah no big deal, I think I managed to fire off a similar thing on > a PWM driver down your path :P > > Fengguang said he'd fixed it though IIRC. Yes sorry for the noise! I've listed Thierry's tree as private report tree (the black list way). Perhaps would be better to make the logic white list based -- then it will be completely noise free. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 06/30] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
>> +/*
>> + * If support CONFIG_PCI_DOMAINS_GENERIC, use
>> + * pci_host_assign_domain_nr() to update domain
>> + * number.
>> + */
>> +host->domain = domain;
>> +pci_host_assign_domain_nr(host);
>
> I think it's a bit confusing that there's another "host->domain ="
> assignment buried inside pci_host_assign_domain_nr(), so the first
> assignment is overwritten when CONFIG_PCI_DOMAINS_GENERIC is set.
>
> Can you do something like this instead:
>
> int pci_host_assign_domain_nr(struct pci_host_bridge *host, int domain)
> {
> #ifdef CONFIG_PCI_DOMAINS_GENERIC
> host->domain = pci_assign_domain_nr(host->dev.parent);
> #else
> host->domain = domain;
> #endif
> }
>
> Then the alternatives (CONFIG_PCI_DOMAINS_GENERIC=y and
> CONFIG_PCI_DOMAINS_GENERIC being unset) are close together and right at the
> #ifdef CONFIG_PCI_DOMAINS_GENERIC, so no extra comments are needed.
OK, I would use #ifdef to update pci_host_assign_domain_nr(), and I would drop
the
last patch [PATCH v9 30/30] PCI: Clean up CONFIG_PCI_DOMAINS_GENERIC.
Thanks!
Yijing.
>
> Bjorn
>
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS)
Hajime Tazaki writes: > is it the following ? it's really cool stuff ! > > https://github.com/rustyrussell/pettycoin/blob/master/test/mockup.sh Yep. It's ugly, but it Works For Me(TM). Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hang on large copy_from_user with PREEMPT_NONE
Linus Torvalds writes: > Alternatively, we could just limit module loading size to some (fairly > arbitrary) big number. Yeah, we used to do that because vmalloc would BUG rather than returning NULL. But you're already CAP_SYS_MODULE in this path, which kind of makes it hard to care very much about it being slow under virtualization. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Audio Jack Out does not work
Yes; reverting the patch does fix the problem.
On Wed, 2015-04-08 at 01:56 +0300, Dan Carpenter wrote:
> So it's 03ad6a8c93b6df2 ('ALSA: hda - Fix "PCM" name being used on > one
> DAC when there are two DACs') which causes the problem? Have you
> tried
> to just revert that patch?
>
> git show 03ad6a8c93b6df2d65c305b5b5f9474068b45bfb | patch -p1 -R
>
> regards,
> dan carpenter
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
On Tue, Apr 07, 2015 at 03:56:35PM +0100, Russell King - ARM Linux wrote: > On Mon, Apr 06, 2015 at 01:24:13PM -0700, Stephen Boyd wrote: > > Writes to /sys/.../cpuX/online fail if we determine the platform > > doesn't support hotplug for that CPU. Furthermore, if the cpu_die > > op isn't specified the system hangs when we try to offline a CPU > > and it comes right back online unexpectedly. Let's figure this > > stuff out before we make the sysfs nodes so that the online file > > doesn't even exist if it isn't (at least sometimes) possible to > > hotplug the CPU. > > > > Add a new 'cpu_can_disable' op and repoint all 'cpu_disable' > > implementations at it because all implementers use the op to > > indicate if a CPU can be hotplugged or not in a static fashion. > > With PSCI we may need to add a 'cpu_disable' op so that the > > secure OS can be migrated off the CPU we're trying to hotplug. > > In this case, the 'cpu_can_disable' op will indicate that all > > CPUs are hotpluggable by returning true, but the 'cpu_disable' op > > will make a PSCI migration call and occasionally fail, denying > > the hotplug of a CPU. This shouldn't be any worse than x86 where > > we may indicate that all CPUs are hotpluggable but occasionally > > we can't offline a CPU due to check_irq_vectors_for_cpu_disable() > > failing to find a CPU to move vectors to. > > > > Cc: Mark Rutland > > Cc: Nicolas Pitre > > Cc: Dave Martin > > Cc: Simon Horman > > Cc: Magnus Damm > > Cc: > > Cc: Tyler Baker > > Cc: Geert Uytterhoeven > > Signed-off-by: Stephen Boyd > > I think this is fine, but I'd like to see some acks for it. As it's > mostly core ARM stuff, it should be merged through my tree unless there > is a known conflict with arm-soc. Thanks. I'm happy with the shmobile portions and have verified that they don't conflict with anything I have queued up for v4.1. So in the context of that release, for the shmobile portion: Acked-by: Simon Horman I also tested, and the effected shmobile boards still seem to boot with this patch applied. Tested-by: Simon Horman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why not build kernel with -O3
Could you please provide some examples that I can investigate? Thanks! 2015-04-08 2:05 GMT+08:00 Austin S Hemmelgarn : > On 2015-04-07 06:09, Mike Galbraith wrote: >> On Tue, 2015-04-07 at 15:56 +0800, Pengfei Yuan wrote: >>> I am trying legacy GCC versions. >>> But I am not able to try different architectures. >> >> The point of my reply wasn't to get you to actually test the world ;-) >> >> I was indirectly pointing out that "works for me" is not good enough >> justification. Much checking for safety/benefit required. >> > Safety especially, -O3 is known to cause perfectly standards-compliant > code to break in weird ways in user-space. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997!
On 04/06/2015 07:59 PM, Steven Rostedt wrote:
>
Thanks for the comments.
> Hmm, why is it not allowed?
>
> If we just let it boost it, it will cut down on the code changes and
> checks that add to the hot paths.
>
There is a WARN_ON() at line 3150 in sched/core.c to warn against
boosting idle_task priority.
In this case we are not actually boosting the idle_task priority, which
should be OK. But the warning could be very overwhelming on some
platforms. TO keep the warning, I decided not to boots priority. Please
let me know if you have any suggestion.
>> rt_mutex_enqueue_pi(owner, waiter);
>> -
>
> I don't think this whitespace change needs to be done. The space does
> split up the dequeue and enqueue from the rest.
>
Will restore it.
>> +/* Might sleep, should not be called in interrupt context. */
>> +BUG_ON(in_interrupt());
>
> You're right it shouldn't. But that's why might_sleep() will give us a
> nice big warning if it is. Don't add the BUG_ON().
>
Will remove it.
>> -static void noinline __sched rt_spin_lock_slowunlock_hirq(struct rt_mutex
>> *lock)
>> +static inline void rt_spin_lock_fastunlock_in_irq(struct rt_mutex *lock,
>
> Why the name change?
>
Instead of adding a new task_struct *caller parameter to
rt_spin_lock_fastUnlock() and make all other invocations of it to supply
the additional parameter, a simpler change would be to add a new
function rt_spin_lock_fastunlock_in_irq(), similar to the original
rt_spin_lock_slowunlock_hirq(), but first do fast mutex acquire attempt
with idle_task as owner and attempt the slow path if required and leave
the rt_spin_lock_fast_unlock() as it is.
>> +void (*slowfn)(struct rt_mutex *lock, struct task_struct *task))
>> {
>> int ret;
>> +struct task_struct *intr_owner = current;
>>
>> +if (unlikely(in_irq()))
>
> Why unlikely? This should only be called in interrupt context.
>
> In fact, perhaps we should have a:
>
> WARN_ON(!in_irq());
>
> Then we don't need this test at all, and just assign the owner the idle
> task.
>
You are right. Sorry I guess I did not pay enough attention here. Will
do that.
>> +intr_owner = idle_task(smp_processor_id());
>
> Also, never butt a single if statement up against another if statement.
> Add a space, otherwise it gives the impression of being an
> if () else if ()
>
OK thanks.
>> +if (likely(rt_mutex_cmpxchg(lock, intr_owner, NULL))) {
>> +rt_mutex_deadlock_account_unlock(intr_owner);
>> +return;
>> +}
>
> And add a space here. Don't butt conditionals together unless they are
> related (if else if, etc)
>
Will do.
>> do {
>> ret = raw_spin_trylock(>wait_lock);
>> } while (!ret);
>
> I know this isn't part of the patch, but that do loop needs a comment
> (this is more toward Sebastian, and not you). It looks buggy, and I
> think we do it this way just so that lockdep doesn't complain. We need
> a comment here that states something like:
>
> /*
>* To get this rt_mutex from interrupt context, we had to have
>* taken the wait_lock once before. Thus, nothing can deadlock
>* us now. The wait_lock is internal to the rt_mutex, and
>* anything that may have it now, will soon release it, because
>* we own the rt_mutex but do not hold anything that the owner
>* of the wait_lock would need to grab.
>*
>* The do { } while() is to keep lockdep from complaining.
>*/
>
Will do.
> I wonder if there's another way to just take the wait_lock and tell
> lockdep not to complain?
>
> Peter?
>
>>
>> -__rt_spin_lock_slowunlock(lock);
>> +slowfn(lock, intr_owner);
>> }
>>
>> void __lockfunc rt_spin_lock(spinlock_t *lock)
>> @@ -1118,7 +1136,7 @@ void __lockfunc
>> rt_spin_unlock_after_trylock_in_irq(spinlock_t *lock)
>> {
>> /* NOTE: we always pass in '1' for nested, for simplicity */
>> spin_release(>dep_map, 1, _RET_IP_);
>> -rt_spin_lock_fastunlock(>lock, rt_spin_lock_slowunlock_hirq);
>> +rt_spin_lock_fastunlock_in_irq(>lock, __rt_spin_lock_slowunlock);
>> }
>>
>> void __lockfunc __rt_spin_unlock(struct rt_mutex *lock)
>> @@ -1146,8 +1164,12 @@ int __lockfunc __rt_spin_trylock(struct rt_mutex
>> *lock)
>>
>> int __lockfunc rt_spin_trylock(spinlock_t *lock)
>
> We really should have a rt_spin_trylock_in_irq() and not have the
> below if conditional.
>
> The paths that will be executed in hard irq context are static. They
> should be labeled as such.
>
Are you talking about having a new function spin_trylock_in_irq() that
is turned into rt_spin-trylock_in_irq() that is called only in the
interrupt context?
That was part of my originally changes. But that also require change in
kernel/timer.c and include/linux/spinlock_rt.h. Since it involves
changes in 2 additional files, I backed out. BTW, with that we could
also add a WAR_ON(in_irq()) in rt_spin_trylock().
[PATCH] virtio_ring: Update weak barriers to use dma_wmb/rmb
This change makes it so that instead of using smp_wmb/rmb which varies
depending on the kernel configuration we can can use dma_wmb/rmb which for
most architectures should be equal to or slightly more strict than
smp_wmb/rmb.
The advantage to this is that these barriers are available to uniprocessor
builds as well so the performance should improve under such a
configuration.
Signed-off-by: Alexander Duyck
---
include/linux/virtio_ring.h | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index 67e06fe18c03..8e50888a6d59 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -21,19 +21,20 @@
* actually quite cheap.
*/
-#ifdef CONFIG_SMP
static inline void virtio_mb(bool weak_barriers)
{
+#ifdef CONFIG_SMP
if (weak_barriers)
smp_mb();
else
+#endif
mb();
}
static inline void virtio_rmb(bool weak_barriers)
{
if (weak_barriers)
- smp_rmb();
+ dma_rmb();
else
rmb();
}
@@ -41,26 +42,10 @@ static inline void virtio_rmb(bool weak_barriers)
static inline void virtio_wmb(bool weak_barriers)
{
if (weak_barriers)
- smp_wmb();
+ dma_wmb();
else
wmb();
}
-#else
-static inline void virtio_mb(bool weak_barriers)
-{
- mb();
-}
-
-static inline void virtio_rmb(bool weak_barriers)
-{
- rmb();
-}
-
-static inline void virtio_wmb(bool weak_barriers)
-{
- wmb();
-}
-#endif
struct virtio_device;
struct virtqueue;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] Revert "staging: board: disable as it breaks the build"
On Tue, Apr 07, 2015 at 03:16:54PM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 6, 2015 at 2:40 AM, Simon Horman wrote:
> > On Fri, Apr 03, 2015 at 02:41:58PM +0200, Geert Uytterhoeven wrote:
> >> This reverts commit d13778d537a0ed6115d2a79a942af999cfb8eec6.
> >>
> >> Commit 13c11072536f2613 ("staging:board: remove unnecessary function")
> >> fixed the build of drivers/staging/board/board.c.
> >>
> >> Signed-off-by: Geert Uytterhoeven
> >
> > Signed-off-by: Simon Horman
>
> Acked-by? Reviewed-by? Tested-by? Rejected-by?
To be honest I was flipping between Signed-off-by and Acked-by.
But it seems you don't think either of those would be appropriate.
So how about:
Reviewed-by: Simon Horman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] perf: Add a flags parameter to pmu txn interfaces
Currently, the PMU interface allows reading only one counter at a time.
But some PMUs like the 24x7 counters in Power, support reading several
counters at once. To leveage this functionality, extend the transaction
interface to support a "transaction type".
The first type, PERF_PMU_TXN_ADD, refers to the existing transactions,
i.e. used to _schedule_ all the events on the PMU as a group.
A second transaction type, PERF_PMU_TXN_READ, will be used in a follow
on patch, by the 24x7 counters to read several counters at once.
For now, extend the transaction interfaces to the PMU to accept a
'flags' parameter and use this parameter to ignore any transactions
that are not of type PERF_PMU_TXN_ADD.
Note: For now we add the 'flags' parameter to all three txn functions
(start, commit, cancel). We could add the parameter to only the
->start interface and have the PMUs cache the transaction type.
But that would need slightly more intrusive changes in all PMUs
to support a second transaction type.
Thanks to Peter Zijlstra for his input.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/perf/core-book3s.c | 16 +---
arch/s390/kernel/perf_cpum_cf.c | 15 ---
arch/sparc/kernel/perf_event.c | 15 ---
arch/x86/kernel/cpu/perf_event.c | 15 ---
include/linux/perf_event.h | 13 ++---
kernel/events/core.c | 26 +++---
6 files changed, 74 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 7c4f669..9cb8008 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1573,10 +1573,13 @@ static void power_pmu_stop(struct perf_event *event,
int ef_flags)
* Set the flag to make pmu::enable() not perform the
* schedulability test, it will be performed at commit time
*/
-static void power_pmu_start_txn(struct pmu *pmu)
+static void power_pmu_start_txn(struct pmu *pmu, int flags)
{
struct cpu_hw_events *cpuhw = this_cpu_ptr(_hw_events);
+ if (flags & ~PERF_PMU_TXN_ADD)
+ return;
+
perf_pmu_disable(pmu);
cpuhw->group_flag |= PERF_EVENT_TXN;
cpuhw->n_txn_start = cpuhw->n_events;
@@ -1587,10 +1590,13 @@ static void power_pmu_start_txn(struct pmu *pmu)
* Clear the flag and pmu::enable() will perform the
* schedulability test.
*/
-static void power_pmu_cancel_txn(struct pmu *pmu)
+static void power_pmu_cancel_txn(struct pmu *pmu, int flags)
{
struct cpu_hw_events *cpuhw = this_cpu_ptr(_hw_events);
+ if (flags & ~PERF_PMU_TXN_ADD)
+ return;
+
cpuhw->group_flag &= ~PERF_EVENT_TXN;
perf_pmu_enable(pmu);
}
@@ -1600,13 +1606,17 @@ static void power_pmu_cancel_txn(struct pmu *pmu)
* Perform the group schedulability test as a whole
* Return 0 if success
*/
-static int power_pmu_commit_txn(struct pmu *pmu)
+static int power_pmu_commit_txn(struct pmu *pmu, int flags)
{
struct cpu_hw_events *cpuhw;
long i, n;
if (!ppmu)
return -EAGAIN;
+
+ if (flags & ~PERF_PMU_TXN_ADD)
+ return -EINVAL;
+
cpuhw = this_cpu_ptr(_hw_events);
n = cpuhw->n_events;
if (check_excludes(cpuhw->event, cpuhw->flags, 0, n))
diff --git a/arch/s390/kernel/perf_cpum_cf.c b/arch/s390/kernel/perf_cpum_cf.c
index 56fdad4..7fa742e 100644
--- a/arch/s390/kernel/perf_cpum_cf.c
+++ b/arch/s390/kernel/perf_cpum_cf.c
@@ -573,10 +573,13 @@ static void cpumf_pmu_del(struct perf_event *event, int
flags)
* Start group events scheduling transaction.
* Set flags to perform a single test at commit time.
*/
-static void cpumf_pmu_start_txn(struct pmu *pmu)
+static void cpumf_pmu_start_txn(struct pmu *pmu, int flags)
{
struct cpu_hw_events *cpuhw = this_cpu_ptr(_hw_events);
+ if (flags & ~PERF_PMU_TXN_ADD)
+ return;
+
perf_pmu_disable(pmu);
cpuhw->flags |= PERF_EVENT_TXN;
cpuhw->tx_state = cpuhw->state;
@@ -587,12 +590,15 @@ static void cpumf_pmu_start_txn(struct pmu *pmu)
* Assumes cpumf_pmu_del() is called for each successful added
* cpumf_pmu_add() during the transaction.
*/
-static void cpumf_pmu_cancel_txn(struct pmu *pmu)
+static void cpumf_pmu_cancel_txn(struct pmu *pmu, int flags)
{
struct cpu_hw_events *cpuhw = this_cpu_ptr(_hw_events);
WARN_ON(cpuhw->tx_state != cpuhw->state);
+ if (flags & ~PERF_PMU_TXN_ADD)
+ return;
+
cpuhw->flags &= ~PERF_EVENT_TXN;
perf_pmu_enable(pmu);
}
@@ -602,11 +608,14 @@ static void cpumf_pmu_cancel_txn(struct pmu *pmu)
* transaction is closed. On error, the transaction is kept open
* until cpumf_pmu_cancel_txn() is called.
*/
-static int cpumf_pmu_commit_txn(struct pmu *pmu)
+static int cpumf_pmu_commit_txn(struct pmu *pmu, int flags)
{
struct cpu_hw_events *cpuhw =
[PATCH v2 4/5] perf: Define PMU_TXN_READ interface
Define a new PERF_PMU_TXN_READ interface to read a group of counters
at once. Note that we use this interface with all PMUs.
PMUs that implement this interface will queue the counters to be read
in ->read() and read them all at once in ->commit_txn().
PMUs that don't implement PERF_PMU_TXN_READ will continue to read one
counter at a time and ignore the ->start_txn() and ->commit_txn().
Thanks to input from Peter Zijlstra.
Signed-off-by: Sukadev Bhattiprolu
---
include/linux/perf_event.h |1 +
kernel/events/core.c | 33 +++--
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index e684c6b..3e46a07 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -244,6 +244,7 @@ struct pmu {
* Optional.
*/
#define PERF_PMU_TXN_ADD 0x1 /* txn to add/schedule event on PMU */
+#define PERF_PMU_TXN_READ 0x2 /* txn to read event group from PMU */
void (*start_txn) (struct pmu *pmu, int flags);
/*
* If ->start_txn() disabled the ->add() schedulability test
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 1ac99d1..a001582 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3644,6 +3644,33 @@ static void orphans_remove_work(struct work_struct *work)
put_ctx(ctx);
}
+/*
+ * Use the transaction interface to read the group of events in @leader.
+ * PMUs like the 24x7 counters in Power, can use this to queue the events
+ * in the ->read() operation and perform the actual read in ->commit_txn.
+ *
+ * Other PMUs can ignore the ->start_txn and ->commit_txn and read each
+ * PMU directly in the ->read() operation.
+ */
+static int perf_event_read_txn(struct perf_event *leader)
+{
+ int ret;
+ struct perf_event *sub;
+ struct pmu *pmu;
+
+ pmu = leader->pmu;
+
+ pmu->start_txn(pmu, PERF_PMU_TXN_READ);
+
+ perf_event_read(leader);
+ list_for_each_entry(sub, >sibling_list, group_entry)
+ perf_event_read(sub);
+
+ ret = pmu->commit_txn(pmu, PERF_PMU_TXN_READ);
+
+ return ret;
+}
+
u64 perf_event_compute_values(struct perf_event *event, u64 *enabled,
u64 *running)
{
@@ -3685,7 +3712,10 @@ static int perf_event_read_group(struct perf_event
*event,
lockdep_assert_held(>mutex);
- perf_event_read(leader);
+ ret = perf_event_read_txn(leader);
+ if (ret)
+ return ret;
+
count = perf_event_compute_values(leader, , );
values[n++] = 1 + leader->nr_siblings;
@@ -3707,7 +3737,6 @@ static int perf_event_read_group(struct perf_event *event,
list_for_each_entry(sub, >sibling_list, group_entry) {
n = 0;
- perf_event_read(sub);
values[n++] = perf_event_compute_values(sub, ,
);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] mailbox: add ACPI support for mailbox framework
Please disregard this, I messed up on the indexing. Will resubmit after fixing.
On Tue, Apr 7, 2015 at 4:34 PM, Feng Kan wrote:
> This will add support for ACPI parsing of the mboxes attribute
> when booting with ACPI table. The client will have a attribute
> mimic the dts call "mboxes". In the ACPI case, the client will
> mark "mboxes" with the ACPI reference of the mbox it wishes to
> use.
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package (2) {"mboxes", "^^MBOXREF"},
> }
> })
>
> Signed-off-by: Feng Kan
> ---
> V2 CHANGE:
> - change to use ACPI reference rather than use ACPI HID directly.
> - consolidate to use one single xlate function
>
>
> drivers/mailbox/mailbox.c | 105
> ++---
> include/linux/mailbox_controller.h | 6 +--
> 2 files changed, 76 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> index 19b491d..8359f2e 100644
> --- a/drivers/mailbox/mailbox.c
> +++ b/drivers/mailbox/mailbox.c
> @@ -9,6 +9,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include
> #include
> #include
> @@ -278,6 +279,70 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
> }
> EXPORT_SYMBOL_GPL(mbox_send_message);
>
> +#ifdef CONFIG_ACPI
> +static struct mbox_chan *mbox_acpi_parse_chan(struct device *dev, int index)
> +{
> + struct acpi_device *acpi_dev;
> + struct mbox_controller *mbox;
> + struct mbox_chan *chan;
> + int status;
> + struct acpi_reference_args args;
> +
> + status = acpi_dev_get_property_reference(ACPI_COMPANION(dev),
> "mboxes",
> +0, );
> + if (ACPI_FAILURE(status)) {
> + dev_dbg(dev, "mbox: no matching mbox found in ACPI table\n");
> + return ERR_PTR(-ENODEV);
> + }
> + acpi_dev = args.adev;
> +
> + chan = NULL;
> + list_for_each_entry(mbox, _cons, node)
> + if (ACPI_COMPANION(mbox->dev) == acpi_dev) {
> + chan = mbox->chan_xlate(mbox, index);
> + break;
> + }
> +
> + return chan;
> +}
> +#endif
> +
> +static struct mbox_chan *mbox_of_parse_chan(struct device *dev, int index)
> +{
> + struct of_phandle_args spec;
> + struct mbox_controller *mbox;
> + struct mbox_chan *chan;
> +
> + if (of_parse_phandle_with_args(dev->of_node, "mboxes",
> + "#mbox-cells", index, )) {
> + dev_dbg(dev, "%s: can't parse \"mboxes\" property\n",
> __func__);
> + return ERR_PTR(-ENODEV);
> + }
> +
> + chan = NULL;
> + list_for_each_entry(mbox, _cons, node)
> + if (mbox->dev->of_node == spec.np) {
> + chan = mbox->chan_xlate(mbox, spec.args[0]);
> + break;
> + }
> +
> + of_node_put(spec.np);
> + return chan;
> +}
> +
> +static struct mbox_chan *mbox_parse_chan(struct device *dev, int index)
> +{
> + if (!dev)
> + return ERR_PTR(-ENODEV);
> +
> + if (dev->of_node)
> + return mbox_of_parse_chan(dev, index);
> +#ifdef CONFIG_ACPI
> + else
> + return mbox_acpi_parse_chan(dev, index);
> +#endif
> +}
> +
> /**
> * mbox_request_channel - Request a mailbox channel.
> * @cl: Identity of the client requesting the channel.
> @@ -298,36 +363,15 @@ EXPORT_SYMBOL_GPL(mbox_send_message);
> struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
> {
> struct device *dev = cl->dev;
> - struct mbox_controller *mbox;
> - struct of_phandle_args spec;
> struct mbox_chan *chan;
> unsigned long flags;
> int ret;
>
> - if (!dev || !dev->of_node) {
> - pr_debug("%s: No owner device node\n", __func__);
> - return ERR_PTR(-ENODEV);
> - }
> -
> mutex_lock(_mutex);
> + chan = mbox_parse_chan(dev, index);
>
> - if (of_parse_phandle_with_args(dev->of_node, "mboxes",
> - "#mbox-cells", index, )) {
> - dev_dbg(dev, "%s: can't parse \"mboxes\" property\n",
> __func__);
> - mutex_unlock(_mutex);
> - return ERR_PTR(-ENODEV);
> - }
> -
> - chan = NULL;
> - list_for_each_entry(mbox, _cons, node)
> - if (mbox->dev->of_node == spec.np) {
> - chan = mbox->of_xlate(mbox, );
> - break;
> - }
> -
> - of_node_put(spec.np);
> -
> - if (!chan || chan->cl || !try_module_get(mbox->dev->driver->owner)) {
> + if (!chan || chan->cl ||
> + !try_module_get(chan->mbox->dev->driver->owner))
[PATCH v2 5/5] powerpc/perf/hv-24x7: Use PMU_TXN_READ interface
The 24x7 counters in Powerpc allow monitoring a large number of counters
simultaneously. They also allow reading several counters in a single
HCALL so we can get a more consistent snapshot of the system.
Use the PMU's transaction interface to monitor and read several event
counters at once. The idea is that users can group several 24x7 events
into a single group of events. We use the following logic to submit
the group of events to the PMU and read the values:
pmu->start_txn()// Initialize before first event
for each event in group
pmu->read(event); // Queue each event to be read
pmu->commit_txn() // Read/update all queued counters
The ->commit_txn() also updates event counts in the respective perf_event
objects. The perf subsystem can then directly get the event counts from
the perf_event and can avoid submitting a new ->read() request to the PMU.
Thanks to input from Peter Zijlstra.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/perf/hv-24x7.c | 165 +++
1 file changed, 165 insertions(+)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index b107efd..6d4ff82 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -142,6 +142,13 @@ static struct attribute_group event_long_desc_group = {
static struct kmem_cache *hv_page_cache;
+struct h_24x7_hw {
+ int flags;
+ int in_txn;
+ int txn_err;
+ struct perf_event *events[255];
+};
+
/*
* request_buffer and result_buffer are not required to be 4k aligned,
* but are not allowed to cross any 4k boundary. Aligning them to 4k is
@@ -150,6 +157,7 @@ static struct kmem_cache *hv_page_cache;
#define H24x7_DATA_BUFFER_SIZE 4096
DEFINE_PER_CPU(char, hv_24x7_reqb[H24x7_DATA_BUFFER_SIZE]) __aligned(4096);
DEFINE_PER_CPU(char, hv_24x7_resb[H24x7_DATA_BUFFER_SIZE]) __aligned(4096);
+DEFINE_PER_CPU(struct h_24x7_hw, h_24x7_hw);
static char *event_name(struct hv_24x7_event_data *ev, int *len)
{
@@ -1213,9 +1221,47 @@ static void update_event_count(struct perf_event *event,
u64 now)
static void h_24x7_event_read(struct perf_event *event)
{
u64 now;
+ struct h_24x7_hw *h24x7hw;
+ struct hv_24x7_request_buffer *request_buffer;
+
+ /*
+* If in a READ transaction, add this counter to the list of
+* counters to read during the next HCALL (i.e commit_txn()).
+* If not in a READ transaction, go ahead and make the HCALL
+* to read this counter by itself.
+*/
+ h24x7hw = _cpu_var(h_24x7_hw);
+ if (h24x7hw->txn_err)
+ goto out;
+
+ if (h24x7hw->in_txn) {
+ int i;
+ int ret;
+
+ request_buffer = (void *)get_cpu_var(hv_24x7_reqb);
+
+ ret = add_event_to_24x7_request(event, request_buffer);
+ if (ret) {
+ h24x7hw->txn_err = ret;
+ } else {
+ /*
+* Assoicate the event with the HCALL request index,
+* so we can quickly find/update the count in
+* ->commit_txn().
+*/
+ i = request_buffer->num_requests - 1;
+ h24x7hw->events[i] = event;
+ }
+
+ put_cpu_var(hv_24x7_reqb);
+ goto out;
+ }
now = h_24x7_get_value(event);
update_event_count(event, now);
+
+out:
+ put_cpu_var(h_24x7_hw);
}
static void h_24x7_event_start(struct perf_event *event, int flags)
@@ -1237,6 +1283,122 @@ static int h_24x7_event_add(struct perf_event *event,
int flags)
return 0;
}
+static void h_24x7_event_start_txn(struct pmu *pmu, int flags)
+{
+ struct hv_24x7_request_buffer *request_buffer;
+ struct hv_24x7_data_result_buffer *result_buffer;
+ struct h_24x7_hw *h24x7hw;
+
+ /*
+* 24x7 counters only support READ transactions. They are
+* always counting and dont need/support ADD transactions.
+*/
+ if (flags & ~PERF_PMU_TXN_READ)
+ return;
+
+ h24x7hw = _cpu_var(h_24x7_hw);
+ request_buffer = (void *)get_cpu_var(hv_24x7_reqb);
+ result_buffer = (void *)get_cpu_var(hv_24x7_resb);
+
+ /* We should not be called if we are already in a txn */
+ WARN_ON_ONCE(h24x7hw->in_txn);
+
+ init_24x7_request(request_buffer, result_buffer);
+ h24x7hw->in_txn = 1;
+
+ put_cpu_var(hv_24x7_resb);
+ put_cpu_var(hv_24x7_reqb);
+ put_cpu_var(h_24x7_hw);
+}
+
+static void reset_txn(struct h_24x7_hw *h24x7hw)
+{
+ /* Clean up transaction */
+ h24x7hw->in_txn = 0;
+ h24x7hw->txn_err = 0;
+ h24x7hw->flags = 0;
+
+ /*
+* request_buffer and result_buffer will be initialized
+* during the next read/txn.
+*/
+}
[PATCH v2 3/5] perf: Rename perf_event_read_value
perf_event_read_value() is mostly computing the event count and enabled/
running times. Move the perf_event_read() into caller and rename
perf_event_read_value() to perf_event_compute_values().
Changelog[v2]
Export symbol perf_event_read() since x86/kvm needs it now.
Signed-off-by: Sukadev Bhattiprolu
---
arch/x86/kvm/pmu.c |6 --
include/linux/perf_event.h |3 ++-
kernel/events/core.c | 18 +++---
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 8e6b7d8..5896cb1 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -144,9 +144,11 @@ static u64 read_pmc(struct kvm_pmc *pmc)
counter = pmc->counter;
- if (pmc->perf_event)
- counter += perf_event_read_value(pmc->perf_event,
+ if (pmc->perf_event) {
+ perf_event_read(pmc->perf_event);
+ counter += perf_event_compute_values(pmc->perf_event,
, );
+ }
/* FIXME: Scaling needed? */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 4dc3d70..e684c6b 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -578,8 +578,9 @@ perf_event_create_kernel_counter(struct perf_event_attr
*attr,
void *context);
extern void perf_pmu_migrate_context(struct pmu *pmu,
int src_cpu, int dst_cpu);
-extern u64 perf_event_read_value(struct perf_event *event,
+extern u64 perf_event_compute_values(struct perf_event *event,
u64 *enabled, u64 *running);
+extern void perf_event_read(struct perf_event *event);
struct perf_sample_data {
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0a3d7c1..1ac99d1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3223,7 +3223,7 @@ static inline u64 perf_event_count(struct perf_event
*event)
return local64_read(>count) + atomic64_read(>child_count);
}
-static void perf_event_read(struct perf_event *event)
+void perf_event_read(struct perf_event *event)
{
/*
* If event is enabled and currently active on a CPU, update the
@@ -3250,6 +3250,7 @@ static void perf_event_read(struct perf_event *event)
raw_spin_unlock_irqrestore(>lock, flags);
}
}
+EXPORT_SYMBOL_GPL(perf_event_read);
/*
* Initialize the perf_event context in a task_struct:
@@ -3643,7 +3644,8 @@ static void orphans_remove_work(struct work_struct *work)
put_ctx(ctx);
}
-u64 perf_event_read_value(struct perf_event *event, u64 *enabled, u64 *running)
+u64 perf_event_compute_values(struct perf_event *event, u64 *enabled,
+ u64 *running)
{
struct perf_event *child;
u64 total = 0;
@@ -3653,7 +3655,6 @@ u64 perf_event_read_value(struct perf_event *event, u64
*enabled, u64 *running)
mutex_lock(>child_mutex);
- perf_event_read(event);
total += perf_event_count(event);
*enabled += event->total_time_enabled +
@@ -3671,7 +3672,7 @@ u64 perf_event_read_value(struct perf_event *event, u64
*enabled, u64 *running)
return total;
}
-EXPORT_SYMBOL_GPL(perf_event_read_value);
+EXPORT_SYMBOL_GPL(perf_event_compute_values);
static int perf_event_read_group(struct perf_event *event,
u64 read_format, char __user *buf)
@@ -3684,7 +3685,8 @@ static int perf_event_read_group(struct perf_event *event,
lockdep_assert_held(>mutex);
- count = perf_event_read_value(leader, , );
+ perf_event_read(leader);
+ count = perf_event_compute_values(leader, , );
values[n++] = 1 + leader->nr_siblings;
if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED)
@@ -3705,7 +3707,8 @@ static int perf_event_read_group(struct perf_event *event,
list_for_each_entry(sub, >sibling_list, group_entry) {
n = 0;
- values[n++] = perf_event_read_value(sub, , );
+ perf_event_read(sub);
+ values[n++] = perf_event_compute_values(sub, ,
);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
@@ -3728,7 +3731,8 @@ static int perf_event_read_one(struct perf_event *event,
u64 values[4];
int n = 0;
- values[n++] = perf_event_read_value(event, , );
+ perf_event_read(event);
+ values[n++] = perf_event_compute_values(event, , );
if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED)
values[n++] = enabled;
if (read_format & PERF_FORMAT_TOTAL_TIME_RUNNING)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] perf: Implement event group read using txn interface
Unlike normal hardware PMCs, the 24x7 counters[1] in Power8 are stored in memory and accessed via a hypervisor call (HCALL). A major aspect of the HCALL is that it allows retireving _SEVERAL_ counters at once (unlike regular PMCs, which are read one at a time). By reading several counters at once, we can get a more consistent snapshot of the system. This patchset extends the transaction interface to accomplish submitting several events to the PMU and have the PMU read them all at once. User is expected to submit the set of events they want to read as an "event group". In the kernel, we submit each event to the PMU using the following logic (from Peter Zijlstra). pmu->start_txn(pmu, PMU_TXN_READ); leader->read(); for_each_sibling() sibling->read(); pmu->commit_txn(); where: - the ->read()s queue events to be submitted to the hypervisor, and, - the ->commit_txn() issues the HCALL, retrieves the result and updates the event count. Architectures/PMUs that don't need/implement PMU_TXN_READ type of transactions, simply ignore the ->start_txn() and ->commit_txn() and continue to read the counters one at a time in the ->read() call. Compile/touch tested on x86. Need help testing on s390 and Sparc. Thanks to Peter Zijlstra for his input. Changelog [v2] - Use the transaction interface unconditionally to avoid special-case code. Architectures/PMUs that don't need the READ transaction types simply ignore the ->start_txn() and ->commit_txn() calls. Sukadev Bhattiprolu (5): perf: Add a flags parameter to pmu txn interfaces perf: Split perf_event_read() and perf_event_count() perf: Rename perf_event_read_value to perf_event_compute_values perf: Define PMU_TXN_READ interface powerpc/perf/hv-24x7: Use PMU_TXN_READ interface arch/powerpc/perf/core-book3s.c | 16 +++- arch/powerpc/perf/hv-24x7.c | 165 ++ arch/s390/kernel/perf_cpum_cf.c | 15 +++- arch/sparc/kernel/perf_event.c | 15 +++- arch/x86/kernel/cpu/perf_event.c | 15 +++- arch/x86/kvm/pmu.c |6 +- include/linux/perf_event.h | 17 +++- kernel/events/core.c | 83 ++- 8 files changed, 292 insertions(+), 40 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] perf: Split perf_event_read() and perf_event_count()
perf_event_read() does two things:
- call the PMU to read/update the counter value
- and compute the total count of the event and its children
perf_event_reset() needs the first piece but doesn't need the second.
Similarly, when we implement the ability to read a group of events
using the transaction interface, we would sometimes need one but
not both.
Break up perf_event_read() and have it just read/update the counter
and have the callers compute the total count if necessary.
Signed-off-by: Sukadev Bhattiprolu
---
kernel/events/core.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 97516d3..0a3d7c1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3223,7 +3223,7 @@ static inline u64 perf_event_count(struct perf_event
*event)
return local64_read(>count) + atomic64_read(>child_count);
}
-static u64 perf_event_read(struct perf_event *event)
+static void perf_event_read(struct perf_event *event)
{
/*
* If event is enabled and currently active on a CPU, update the
@@ -3249,8 +3249,6 @@ static u64 perf_event_read(struct perf_event *event)
update_event_times(event);
raw_spin_unlock_irqrestore(>lock, flags);
}
-
- return perf_event_count(event);
}
/*
@@ -3654,14 +3652,18 @@ u64 perf_event_read_value(struct perf_event *event, u64
*enabled, u64 *running)
*running = 0;
mutex_lock(>child_mutex);
- total += perf_event_read(event);
+
+ perf_event_read(event);
+ total += perf_event_count(event);
+
*enabled += event->total_time_enabled +
atomic64_read(>child_total_time_enabled);
*running += event->total_time_running +
atomic64_read(>child_total_time_running);
list_for_each_entry(child, >child_list, child_list) {
- total += perf_event_read(child);
+ perf_event_read(child);
+ total += perf_event_count(child);
*enabled += child->total_time_enabled;
*running += child->total_time_running;
}
@@ -3821,7 +3823,7 @@ static unsigned int perf_poll(struct file *file,
poll_table *wait)
static void _perf_event_reset(struct perf_event *event)
{
- (void)perf_event_read(event);
+ perf_event_read(event);
local64_set(>count, 0);
perf_event_update_userpage(event);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Input: atmel_mxt_ts - add support for Google Pixel 2
This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
Google Pixel 2 (2015).
While newer version of ACPI standard allow use of device-tree-like
properties in device descriptions, the version of ACPI implemented in
Google BIOS does not support them, and we have to resort to DMI data to
specify exact characteristics of the devices (touchpad vs. touchscreen,
GPIO to button mapping, etc).
Pixel 1 continues to use i2c devices and platform data created by
chromeos-laptop driver, since ACPI does not enumerate them.
Signed-off-by: Dmitry Torokhov
---
drivers/input/touchscreen/atmel_mxt_ts.c | 149 +++
1 file changed, 134 insertions(+), 15 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 2875ddf..dfc7309 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -14,6 +14,8 @@
*
*/
+#include
+#include
#include
#include
#include
@@ -724,15 +726,15 @@ static void mxt_input_button(struct mxt_data *data, u8
*message)
{
struct input_dev *input = data->input_dev;
const struct mxt_platform_data *pdata = data->pdata;
- bool button;
int i;
- /* Active-low switch */
for (i = 0; i < pdata->t19_num_keys; i++) {
if (pdata->t19_keymap[i] == KEY_RESERVED)
continue;
- button = !(message[1] & (1 << i));
- input_report_key(input, pdata->t19_keymap[i], button);
+
+ /* Active-low switch */
+ input_report_key(input, pdata->t19_keymap[i],
+!(message[1] & BIT(i)));
}
}
@@ -2371,7 +2373,7 @@ static void mxt_input_close(struct input_dev *dev)
}
#ifdef CONFIG_OF
-static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
+static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
{
struct mxt_platform_data *pdata;
u32 *keymap;
@@ -2379,7 +2381,7 @@ static struct mxt_platform_data *mxt_parse_dt(struct
i2c_client *client)
int proplen, i, ret;
if (!client->dev.of_node)
- return ERR_PTR(-ENODEV);
+ return ERR_PTR(-ENOENT);
pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -2410,25 +2412,132 @@ static struct mxt_platform_data *mxt_parse_dt(struct
i2c_client *client)
return pdata;
}
#else
-static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
+static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
{
- dev_dbg(>dev, "No platform data specified\n");
- return ERR_PTR(-EINVAL);
+ return ERR_PTR(-ENOENT);
}
#endif
+#ifdef CONFIG_ACPI
+
+struct mxt_acpi_platform_data {
+ const char *hid;
+ struct mxt_platform_data pdata;
+};
+
+static unsigned int samus_touchpad_buttons[] = {
+ KEY_RESERVED,
+ KEY_RESERVED,
+ KEY_RESERVED,
+ BTN_LEFT
+};
+
+static struct mxt_acpi_platform_data samus_platform_data[] = {
+ {
+ /* Touchpad */
+ .hid= "ATML",
+ .pdata = {
+ .t19_num_keys = ARRAY_SIZE(samus_touchpad_buttons),
+ .t19_keymap = samus_touchpad_buttons,
+ },
+ },
+ {
+ /* Touchscreen */
+ .hid= "ATML0001",
+ },
+ { }
+};
+
+static const struct dmi_system_id mxt_dmi_table[] = {
+ {
+ /* 2015 Google Pixel */
+ .ident = "Chromebook Pixel 2",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Samus"),
+ },
+ .driver_data = samus_platform_data,
+ },
+ { }
+};
+
+static const struct mxt_platform_data *mxt_parse_acpi(struct i2c_client
*client)
+{
+ struct acpi_device *adev;
+ const struct dmi_system_id *system_id;
+ const struct mxt_acpi_platform_data *acpi_pdata;
+
+ /*
+* Ignore ACPI devices representing bootloader mode.
+*
+* This is a bit of a hack: Google Chromebook BIOS creates ACPI
+* devices for both application and bootloader modes, but we are
+* interested in application mode only (if device is in bootloader
+* mode we'll end up switching into application anyway). So far
+* application mode addresses were all above 0x40, so we'll use it
+* as a threshold.
+*/
+ if (client->addr < 0x40)
+ return ERR_PTR(-ENXIO);
+
+ adev = ACPI_COMPANION(>dev);
+ if (!adev)
+ return ERR_PTR(-ENOENT);
+
+ system_id = dmi_first_match(mxt_dmi_table);
+ if (!system_id)
+ return ERR_PTR(-ENOENT);
+
+ acpi_pdata = system_id->driver_data;
+ if (!acpi_pdata)
+
[PATCH 2/2] Input: atmel_mxt_ts - allow specifying device-specific configs
Atmel controolers are very flexible and to function optimally require
device-specific configuration to be loaded. While the configuration is
stored in NVRAM and is normally persistent, sometimes it gets corrupted
and needs to be reloaded.
Instead of using the same name, maxtouch.cfg, for all systems and all
devices, let's allow platform data to specify the name of configuration
file that should be loaded. This is especially useful for systems that
use Atmel controllers for both touchscren and touchpad, since their
configurations will surely differ.
Signed-off-by: Dmitry Torokhov
---
.../devicetree/bindings/input/atmel,maxtouch.txt | 6 ++
drivers/input/touchscreen/atmel_mxt_ts.c | 18 +-
include/linux/i2c/atmel_mxt_ts.h | 1 +
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
index 1852906..fd2344d 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
@@ -9,6 +9,12 @@ Required properties:
- interrupts: The sink for the touchpad's IRQ output
See ../interrupt-controller/interrupts.txt
+Optional properties:
+
+- linux,config-name: name of configuration file that should be loaded
+into device for optimal functioning. If not specified "maxtouch.cfg"
+will be used.
+
Optional properties for main touchpad device:
- linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index dfc7309..0dcd455 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -2035,7 +2035,8 @@ static int mxt_initialize(struct mxt_data *data)
if (error)
goto err_free_object_table;
- error = request_firmware_nowait(THIS_MODULE, true, MXT_CFG_NAME,
+ error = request_firmware_nowait(THIS_MODULE, true,
+ data->pdata->cfg_name ?: MXT_CFG_NAME,
>dev, GFP_KERNEL, data,
mxt_config_cb);
if (error) {
@@ -2375,20 +2376,21 @@ static void mxt_input_close(struct input_dev *dev)
#ifdef CONFIG_OF
static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
{
+ struct device_node *np;
struct mxt_platform_data *pdata;
u32 *keymap;
u32 keycode;
int proplen, i, ret;
- if (!client->dev.of_node)
+ np = client->dev.of_node;
+ if (!np)
return ERR_PTR(-ENOENT);
pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return ERR_PTR(-ENOMEM);
- if (of_find_property(client->dev.of_node, "linux,gpio-keymap",
-)) {
+ if (of_find_property(np, "linux,gpio-keymap", )) {
pdata->t19_num_keys = proplen / sizeof(u32);
keymap = devm_kzalloc(>dev,
@@ -2398,7 +2400,7 @@ static const struct mxt_platform_data
*mxt_parse_dt(struct i2c_client *client)
return ERR_PTR(-ENOMEM);
for (i = 0; i < pdata->t19_num_keys; i++) {
- ret = of_property_read_u32_index(client->dev.of_node,
+ ret = of_property_read_u32_index(np,
"linux,gpio-keymap", i, );
if (ret)
keycode = KEY_RESERVED;
@@ -2409,6 +2411,8 @@ static const struct mxt_platform_data
*mxt_parse_dt(struct i2c_client *client)
pdata->t19_keymap = keymap;
}
+ of_property_read_string(np, "linux,config-name", >cfg_name);
+
return pdata;
}
#else
@@ -2439,11 +2443,15 @@ static struct mxt_acpi_platform_data
samus_platform_data[] = {
.pdata = {
.t19_num_keys = ARRAY_SIZE(samus_touchpad_buttons),
.t19_keymap = samus_touchpad_buttons,
+ .cfg_name = "samus-337t.raw",
},
},
{
/* Touchscreen */
.hid= "ATML0001",
+ .pdata = {
+ .cfg_name = "samus-2954t2.raw",
+ },
},
{ }
};
diff --git a/include/linux/i2c/atmel_mxt_ts.h b/include/linux/i2c/atmel_mxt_ts.h
index 02bf6ea..aeb8c9a 100644
--- a/include/linux/i2c/atmel_mxt_ts.h
+++ b/include/linux/i2c/atmel_mxt_ts.h
@@ -20,6 +20,7 @@ struct mxt_platform_data {
unsigned long irqflags;
u8 t19_num_keys;
const unsigned int *t19_keymap;
+ const char *cfg_name;
};
#endif /* __LINUX_ATMEL_MXT_TS_H */
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3
Andrew Morton writes: > On Tue, 07 Apr 2015 16:27:44 -0700 Kevin Hilman wrote: > >> >> > It should all be there today? >> >> >> >> Nope. >> > >> > huh, I swear I did an mmotm yesterday. >> >> Well, based on the timestamp of the mmotm dir on ozlabs, it appears you >> did. That's why I was confused why the gcc-473 patches from mmots aren't >> there. > > Things look a bit better now. Yup, I can confirm all 4 patches are there now. Things should be in good shape for the next -next. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched: Improve load balancing in the presence of idle CPUs
On Tue, 2015-04-07 at 16:28 -0700, Jason Low wrote:
> Okay, so perhaps we can also try continuing nohz load balancing if we
> find that there are overloaded CPUs in the system.
Something like the following.
---
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fdae26e..d636bf7 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7620,6 +7620,16 @@ out:
}
#ifdef CONFIG_NO_HZ_COMMON
+static inline bool nohz_kick_needed(struct rq *rq);
+
+static inline void pass_nohz_balance(struct rq *this_rq, int this_cpu)
+{
+ clear_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu));
+ nohz.next_balance = jiffies;
+ if (nohz_kick_needed(this_rq))
+ nohz_balancer_kick();
+}
+
/*
* In CONFIG_NO_HZ_COMMON case, the idle balance kickee will do the
* rebalancing for all the cpus for whom scheduler ticks are stopped.
@@ -7631,8 +7641,10 @@ static void nohz_idle_balance(struct rq *this_rq, enum
cpu_idle_type idle)
int balance_cpu;
if (idle != CPU_IDLE ||
- !test_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu)))
- goto end;
+ !test_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu))) {
+ pass_nohz_balance(this_rq, this_cpu);
+ return;
+ }
for_each_cpu(balance_cpu, nohz.idle_cpus_mask) {
if (balance_cpu == this_cpu || !idle_cpu(balance_cpu))
@@ -7643,8 +7655,10 @@ static void nohz_idle_balance(struct rq *this_rq, enum
cpu_idle_type idle)
* work being done for other cpus. Next load
* balancing owner will pick it up.
*/
- if (need_resched())
- break;
+ if (need_resched()) {
+ pass_nohz_balance(this_rq, this_cpu);
+ return;
+ }
rq = cpu_rq(balance_cpu);
@@ -7664,7 +7678,6 @@ static void nohz_idle_balance(struct rq *this_rq, enum
cpu_idle_type idle)
this_rq->next_balance = rq->next_balance;
}
nohz.next_balance = this_rq->next_balance;
-end:
clear_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu));
}
@@ -7687,7 +7700,7 @@ static inline bool nohz_kick_needed(struct rq *rq)
int nr_busy, cpu = rq->cpu;
bool kick = false;
- if (unlikely(rq->idle_balance))
+ if (unlikely(idle_cpu(cpu)))
return false;
/*
@@ -7707,7 +7720,7 @@ static inline bool nohz_kick_needed(struct rq *rq)
if (time_before(now, nohz.next_balance))
return false;
- if (rq->nr_running >= 2)
+ if (rq->nr_running >= 2 || rq->rd->overload)
return true;
rcu_read_lock();
@@ -7757,16 +7770,14 @@ static void run_rebalance_domains(struct softirq_action
*h)
enum cpu_idle_type idle = this_rq->idle_balance ?
CPU_IDLE : CPU_NOT_IDLE;
+ rebalance_domains(this_rq, idle);
+
/*
* If this cpu has a pending nohz_balance_kick, then do the
* balancing on behalf of the other idle cpus whose ticks are
-* stopped. Do nohz_idle_balance *before* rebalance_domains to
-* give the idle cpus a chance to load balance. Else we may
-* load balance only within the local sched_domain hierarchy
-* and abort nohz_idle_balance altogether if we pull some load.
+* stopped.
*/
nohz_idle_balance(this_rq, idle);
- rebalance_domains(this_rq, idle);
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] perf tools: Add MIPS userspace DWARF callchains.
This is a refresh of a David Daney's patch set to implement MIPS support for perf. It has been posted before but not received any comments or (N)Acks. This series depends on http://patchwork.linux-mips.org/patch/5246/ which currently is pending for 4.1 in the MIPS tree so I'd like to upstream these two patches through the MIPS tree as well. David's original patches are archived at: http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips=1368817238-11548-1-git-send-email-ddaney.cavm%40gmail.com http://patchwork.linux-mips.org/patch/5249/ http://patchwork.linux-mips.org/patch/5250/ Cheers, Ralf David Daney (2): perf tools: Add support for MIPS userspace DWARF callchains. perf tools: Hook up MIPS unwind and dwarf-regs in the Makefile tools/perf/Makefile | 3 ++ tools/perf/arch/mips/Makefile| 7 +++ tools/perf/arch/mips/include/perf_regs.h | 84 tools/perf/arch/mips/util/dwarf-regs.c | 37 ++ tools/perf/arch/mips/util/unwind.c | 20 tools/perf/config/Makefile | 10 6 files changed, 161 insertions(+) create mode 100644 tools/perf/arch/mips/Makefile create mode 100644 tools/perf/arch/mips/include/perf_regs.h create mode 100644 tools/perf/arch/mips/util/dwarf-regs.c create mode 100644 tools/perf/arch/mips/util/unwind.c -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] perf tools: Hook up MIPS unwind and dwarf-regs in the Makefile
From: David Daney Define a new symbol (ARCH_SUPPORTS_LIBUNWIND) in config/Makefile. Use this from x86 and MIPS to gate testing of libunwind. Signed-off-by: David Daney Cc: linux-m...@linux-mips.org Cc: Jiri Olsa Cc: linux-kernel@vger.kernel.org Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Patchwork: https://patchwork.linux-mips.org/patch/5250/ Signed-off-by: Ralf Baechle --- tools/perf/config/Makefile | 10 ++ 1 file changed, 10 insertions(+) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index cc22408..0d0595e 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -27,19 +27,29 @@ ifeq ($(ARCH),x86) else LIBUNWIND_LIBS = -lunwind -lunwind-x86 endif + ARCH_SUPPORTS_LIBUNWIND := 1 NO_PERF_REGS := 0 endif ifeq ($(ARCH),arm) NO_PERF_REGS := 0 + ARCH_SUPPORTS_LIBUNWIND := 1 LIBUNWIND_LIBS = -lunwind -lunwind-arm endif ifeq ($(ARCH),arm64) NO_PERF_REGS := 0 + ARCH_SUPPORTS_LIBUNWIND := 1 LIBUNWIND_LIBS = -lunwind -lunwind-aarch64 endif +# Additional ARCH settings for MIPS +ifeq ($(ARCH),mips) + ARCH_SUPPORTS_LIBUNWIND := 1 + NO_PERF_REGS := 0 + LIBUNWIND_LIBS = -lunwind -lunwind-mips +endif + # So far there's only x86 and arm libdw unwind support merged in perf. # Disable it on all other architectures in case libdw unwind # support is detected in system. Add supported architectures -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] perf tools: Add support for MIPS userspace DWARF callchains.
From: David Daney
Hack up the Makefile and add support code for mips unwinding
and dwarf-regs.
Signed-off-by: David Daney
Cc: linux-m...@linux-mips.org
Cc: Jiri Olsa
Cc: linux-kernel@vger.kernel.org
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Patchwork: https://patchwork.linux-mips.org/patch/5249/
Signed-off-by: Ralf Baechle
---
tools/perf/Makefile | 3 ++
tools/perf/arch/mips/Makefile| 7 +++
tools/perf/arch/mips/include/perf_regs.h | 84
tools/perf/arch/mips/util/dwarf-regs.c | 37 ++
tools/perf/arch/mips/util/unwind.c | 20
5 files changed, 151 insertions(+)
create mode 100644 tools/perf/arch/mips/Makefile
create mode 100644 tools/perf/arch/mips/include/perf_regs.h
create mode 100644 tools/perf/arch/mips/util/dwarf-regs.c
create mode 100644 tools/perf/arch/mips/util/unwind.c
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index cb2e586..c2a089a 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -28,6 +28,9 @@ ifeq ($(JOBS),)
ifeq ($(JOBS),)
JOBS := 1
endif
+ ifeq ($(ARCH),mips)
+LIB_H += arch/mips/include/perf_regs.h
+ endif
endif
#
diff --git a/tools/perf/arch/mips/Makefile b/tools/perf/arch/mips/Makefile
new file mode 100644
index 000..fe9b61e
--- /dev/null
+++ b/tools/perf/arch/mips/Makefile
@@ -0,0 +1,7 @@
+ifndef NO_DWARF
+PERF_HAVE_DWARF_REGS := 1
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
+endif
+ifndef NO_LIBUNWIND
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind.o
+endif
diff --git a/tools/perf/arch/mips/include/perf_regs.h
b/tools/perf/arch/mips/include/perf_regs.h
new file mode 100644
index 000..a91b904
--- /dev/null
+++ b/tools/perf/arch/mips/include/perf_regs.h
@@ -0,0 +1,84 @@
+#ifndef ARCH_PERF_REGS_H
+#define ARCH_PERF_REGS_H
+
+#include
+#include "../../util/types.h"
+#include
+
+#define PERF_REG_IP PERF_REG_MIPS_PC
+#define PERF_REG_SP PERF_REG_MIPS_R29
+
+#define PERF_REGS_MASK ((1ULL << PERF_REG_MIPS_MAX) - 1)
+
+static inline const char *perf_reg_name(int id)
+{
+ switch (id) {
+ case PERF_REG_MIPS_PC:
+ return "PC";
+ case PERF_REG_MIPS_R1:
+ return "$1";
+ case PERF_REG_MIPS_R2:
+ return "$2";
+ case PERF_REG_MIPS_R3:
+ return "$3";
+ case PERF_REG_MIPS_R4:
+ return "$4";
+ case PERF_REG_MIPS_R5:
+ return "$5";
+ case PERF_REG_MIPS_R6:
+ return "$6";
+ case PERF_REG_MIPS_R7:
+ return "$7";
+ case PERF_REG_MIPS_R8:
+ return "$8";
+ case PERF_REG_MIPS_R9:
+ return "$9";
+ case PERF_REG_MIPS_R10:
+ return "$10";
+ case PERF_REG_MIPS_R11:
+ return "$11";
+ case PERF_REG_MIPS_R12:
+ return "$12";
+ case PERF_REG_MIPS_R13:
+ return "$13";
+ case PERF_REG_MIPS_R14:
+ return "$14";
+ case PERF_REG_MIPS_R15:
+ return "$15";
+ case PERF_REG_MIPS_R16:
+ return "$16";
+ case PERF_REG_MIPS_R17:
+ return "$17";
+ case PERF_REG_MIPS_R18:
+ return "$18";
+ case PERF_REG_MIPS_R19:
+ return "$19";
+ case PERF_REG_MIPS_R20:
+ return "$20";
+ case PERF_REG_MIPS_R21:
+ return "$21";
+ case PERF_REG_MIPS_R22:
+ return "$22";
+ case PERF_REG_MIPS_R23:
+ return "$23";
+ case PERF_REG_MIPS_R24:
+ return "$24";
+ case PERF_REG_MIPS_R25:
+ return "$25";
+
+ case PERF_REG_MIPS_R28:
+ return "$28";
+ case PERF_REG_MIPS_R29:
+ return "$29";
+ case PERF_REG_MIPS_R30:
+ return "$30";
+ case PERF_REG_MIPS_R31:
+ return "$31";
+ default:
+ break;
+ }
+ return NULL;
+}
+
+
+#endif /* ARCH_PERF_REGS_H */
diff --git a/tools/perf/arch/mips/util/dwarf-regs.c
b/tools/perf/arch/mips/util/dwarf-regs.c
new file mode 100644
index 000..165e017
--- /dev/null
+++ b/tools/perf/arch/mips/util/dwarf-regs.c
@@ -0,0 +1,37 @@
+/*
+ * dwarf-regs.c : Mapping of DWARF debug register numbers into register names.
+ *
+ * Copyright (C) 2013 Cavium, Inc.
+ *
+ * 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
+
+static
Re: [BUG REPORT] kernel panic in tcp_sendpage() on null pointer dereference
On Tue, 2015-04-07 at 16:33 -0700, Eric Dumazet wrote: > On Tue, 2015-04-07 at 15:57 -0700, Tuan Bui wrote: > > Hi all, > > > > I am consistently seeing this kernel panic on a 16 sockets machine > > running Spark PageRank workload using Docker. I am running RHEL 7.0 > > stock kernel which is 3.10.0-123.el7.x86_64. > > Have you tried a recent upstream kernel ? > Yes I have tried an upstream v4.0-rc4 kernel. I was still getting the same kernel panic. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] perf script segfault
On 4/7/15 5:41 PM, David Ahern wrote: what happened to this patch? not in your core or urgent branches and perf-script is still bombing d'oh. never mind; user error. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 009/156] KVM: emulate: fix CMPXCHG8B on 32-bit hosts
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let me know. -- From: Paolo Bonzini commit 4ff6f8e61eb7f96d3ca535c6d240f863ccd6fb7d upstream. This has been broken for a long time: it broke first in 2.6.35, then was almost fixed in 2.6.36 but this one-liner slipped through the cracks. The bug shows up as an infinite loop in Windows 7 (and newer) boot on 32-bit hosts without EPT. Windows uses CMPXCHG8B to write to page tables, which causes a page fault if running without EPT; the emulator is then called from kvm_mmu_page_fault. The loop then happens if the higher 4 bytes are not 0; the common case for this is that the NX bit (bit 63) is 1. Fixes: 6550e1f165f384f3a46b60a1be9aba4bc3c2adad Fixes: 16518d5ada690643453eb0aef3cc7841d3623c2d Reported-by: Erik Rull Tested-by: Erik Rull Signed-off-by: Paolo Bonzini Signed-off-by: Kamal Mostafa --- arch/x86/kvm/emulate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index 9c35870..477e61e 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -4708,7 +4708,8 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt) if (rc != X86EMUL_CONTINUE) goto done; } - ctxt->dst.orig_val = ctxt->dst.val; + /* Copy full 64-bit value for CMPXCHG8B. */ + ctxt->dst.orig_val64 = ctxt->dst.val64; special_insn: -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 010/156] xhci: Allocate correct amount of scratchpad buffers
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let
me know.
--
From: Mathias Nyman
commit 6596a926b0b6c80b730a1dd2fa91908e0a539c37 upstream.
Include the high order bit fields for Max scratchpad buffers when
calculating how many scratchpad buffers are needed.
I'm suprised this hasn't caused more issues, we never allocated more than
32 buffers even if xhci needed more. Either we got lucky and xhci never
really used past that area, or then we got enough zeroed dma memory anyway.
Should be backported as far back as possible
Reported-by: Tim Chen
Tested-by: Tim Chen
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
---
drivers/usb/host/xhci.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index e9765fd..bc94810 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -88,9 +88,10 @@ struct xhci_cap_regs {
#define HCS_IST(p) (((p) >> 0) & 0xf)
/* bits 4:7, max number of Event Ring segments */
#define HCS_ERST_MAX(p)(((p) >> 4) & 0xf)
+/* bits 21:25 Hi 5 bits of Scratchpad buffers SW must allocate for the HW */
/* bit 26 Scratchpad restore - for save/restore HW state - not used yet */
-/* bits 27:31 number of Scratchpad buffers SW must allocate for the HW */
-#define HCS_MAX_SCRATCHPAD(p) (((p) >> 27) & 0x1f)
+/* bits 27:31 Lo 5 bits of Scratchpad buffers SW must allocate for the HW */
+#define HCS_MAX_SCRATCHPAD(p) p) >> 16) & 0x3e0) | (((p) >> 27) & 0x1f))
/* HCSPARAMS3 - hcs_params3 - bitmasks */
/* bits 0:7, Max U1 to U0 latency for the roothub ports */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 004/156] iio: mxs-lradc: only update the buffer when its conversions have finished
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let
me know.
--
From: =?UTF-8?q?Kristina=20Mart=C5=A1enko?=
commit 89bb35e200bee745c539a9e0792301ca40f1 upstream.
Using the touchscreen while running buffered capture results in the
buffer reporting lots of wrong values, often just zeros. This is because
we push readings to the buffer every time a touchscreen interrupt
arrives, including when the buffer's own conversions have not yet
finished. So let's only push to the buffer when its conversions are
ready.
Signed-off-by: Kristina Martšenko
Reviewed-by: Marek Vasut
Signed-off-by: Jonathan Cameron
[ kamal: backport to 3.13-stable: context ]
Signed-off-by: Kamal Mostafa
---
drivers/staging/iio/adc/mxs-lradc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 49d00d6..0b4877a 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -913,10 +913,12 @@ static irqreturn_t mxs_lradc_handle_irq(int irq, void
*data)
LRADC_CTRL1_LRADC_IRQ(TOUCHSCREEN_VCHANNEL2));
}
- if (iio_buffer_enabled(iio))
- iio_trigger_poll(iio->trig, iio_get_time_ns());
- else if (reg & LRADC_CTRL1_LRADC_IRQ(0))
+ if (iio_buffer_enabled(iio)) {
+ if (reg & lradc->buffer_vchans)
+ iio_trigger_poll(iio->trig, iio_get_time_ns());
+ } else if (reg & LRADC_CTRL1_LRADC_IRQ(0)) {
complete(>completion);
+ }
mxs_lradc_reg_clear(lradc, reg & clr_irq, LRADC_CTRL1);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 007/156] iio: ad5686: fix optional reference voltage declaration
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let
me know.
--
From: =?UTF-8?q?Urs=20F=C3=A4ssler?=
commit da019f59cb16570e78feaf10380ac65a3a06861e upstream.
When not using the "_optional" function, a dummy regulator is returned
and the driver fails to initialize.
Signed-off-by: Urs Fässler
Acked-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Signed-off-by: Kamal Mostafa
---
drivers/iio/dac/ad5686.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
index 30e506e..c0dc0f0 100644
--- a/drivers/iio/dac/ad5686.c
+++ b/drivers/iio/dac/ad5686.c
@@ -317,7 +317,7 @@ static int ad5686_probe(struct spi_device *spi)
st = iio_priv(indio_dev);
spi_set_drvdata(spi, indio_dev);
- st->reg = devm_regulator_get(>dev, "vcc");
+ st->reg = devm_regulator_get_optional(>dev, "vcc");
if (!IS_ERR(st->reg)) {
ret = regulator_enable(st->reg);
if (ret)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 005/156] iio: imu: adis16400: Fix sign extension
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let me know. -- From: Rasmus Villemoes commit 19e353f2b344ad86cea6ebbc0002e5f903480a90 upstream. The intention is obviously to sign-extend a 12 bit quantity. But because of C's promotion rules, the assignment is equivalent to "val16 &= 0xfff;". Use the proper API for this. Signed-off-by: Rasmus Villemoes Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Kamal Mostafa --- drivers/iio/imu/adis16400_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iio/imu/adis16400_core.c b/drivers/iio/imu/adis16400_core.c index 7c582f7..70753bf 100644 --- a/drivers/iio/imu/adis16400_core.c +++ b/drivers/iio/imu/adis16400_core.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include @@ -447,7 +448,7 @@ static int adis16400_read_raw(struct iio_dev *indio_dev, mutex_unlock(_dev->mlock); if (ret) return ret; - val16 = ((val16 & 0xFFF) << 4) >> 4; + val16 = sign_extend32(val16, 11); *val = val16; return IIO_VAL_INT; case IIO_CHAN_INFO_OFFSET: -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 008/156] usb: dwc3: dwc3-omap: Fix disable IRQ
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let
me know.
--
From: George Cherian
commit 96e5d31244c5542f5b2ea81d76f14ba4b8a7d440 upstream.
In the wrapper the IRQ disable should be done by writing 1's to the
IRQ*_CLR register. Existing code is broken because it instead writes
zeros to IRQ*_SET register.
Fix this by adding functions dwc3_omap_write_irqmisc_clr() and
dwc3_omap_write_irq0_clr() which do the right thing.
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: George Cherian
Signed-off-by: Felipe Balbi
Signed-off-by: Kamal Mostafa
---
drivers/usb/dwc3/dwc3-omap.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 2a0422b..662441b 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -215,6 +215,18 @@ static void dwc3_omap_write_irq0_set(struct dwc3_omap
*omap, u32 value)
omap->irq0_offset, value);
}
+static void dwc3_omap_write_irqmisc_clr(struct dwc3_omap *omap, u32 value)
+{
+ dwc3_omap_writel(omap->base, USBOTGSS_IRQENABLE_CLR_MISC +
+ omap->irqmisc_offset, value);
+}
+
+static void dwc3_omap_write_irq0_clr(struct dwc3_omap *omap, u32 value)
+{
+ dwc3_omap_writel(omap->base, USBOTGSS_IRQENABLE_CLR_0 -
+ omap->irq0_offset, value);
+}
+
static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
enum omap_dwc3_vbus_id_status status)
{
@@ -359,9 +371,23 @@ static void dwc3_omap_enable_irqs(struct dwc3_omap *omap)
static void dwc3_omap_disable_irqs(struct dwc3_omap *omap)
{
+ u32 reg;
+
/* disable all IRQs */
- dwc3_omap_write_irqmisc_set(omap, 0x00);
- dwc3_omap_write_irq0_set(omap, 0x00);
+ reg = USBOTGSS_IRQO_COREIRQ_ST;
+ dwc3_omap_write_irq0_clr(omap, reg);
+
+ reg = (USBOTGSS_IRQMISC_OEVT |
+ USBOTGSS_IRQMISC_DRVVBUS_RISE |
+ USBOTGSS_IRQMISC_CHRGVBUS_RISE |
+ USBOTGSS_IRQMISC_DISCHRGVBUS_RISE |
+ USBOTGSS_IRQMISC_IDPULLUP_RISE |
+ USBOTGSS_IRQMISC_DRVVBUS_FALL |
+ USBOTGSS_IRQMISC_CHRGVBUS_FALL |
+ USBOTGSS_IRQMISC_DISCHRGVBUS_FALL |
+ USBOTGSS_IRQMISC_IDPULLUP_FALL);
+
+ dwc3_omap_write_irqmisc_clr(omap, reg);
}
static u64 dwc3_omap_dma_mask = DMA_BIT_MASK(32);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 001/156] iio: mxs-lradc: separate touchscreen and buffer virtual channels
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let
me know.
--
From: =?UTF-8?q?Kristina=20Mart=C5=A1enko?=
commit f81197b8a31b8fb287ae57f597b5b6841e1ece92 upstream.
The touchscreen was initially designed [1] to map all of its physical
channels to one virtual channel, leaving buffered capture to use the
remaining 7 virtual channels. When the touchscreen was reimplemented
[2], it was made to use four virtual channels, which overlap and
conflict with the channels the buffer uses.
As a result, when the buffer is enabled, the touchscreen's virtual
channels are remapped to whichever physical channels the buffer was
configured with, causing the touchscreen to read those instead of the
touch measurement channels. Effectively the touchscreen stops working.
So here we separate the channels again, giving the touchscreen 2 virtual
channels and the buffer 6. We can't give the touchscreen just 1 channel
as before, as the current pressure calculation requires 2 channels to be
read at the same time.
This makes the touchscreen continue to work during buffered capture. It
has been tested on i.MX28, but not on i.MX23.
[1] 06ddd353f5c8 ("iio: mxs: Implement support for touchscreen")
[2] dee05308f602 ("Staging/iio/adc/touchscreen/MXS: add interrupt driven
touch detection")
Signed-off-by: Kristina Martšenko
Reviewed-by: Marek Vasut
Signed-off-by: Jonathan Cameron
Signed-off-by: Kamal Mostafa
---
drivers/staging/iio/adc/mxs-lradc.c | 165
1 file changed, 75 insertions(+), 90 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index da4f0b1..eccd12c 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -156,11 +156,14 @@ struct mxs_lradc {
struct completion completion;
/*
-* Touchscreen LRADC channels receives a private slot in the CTRL4
-* register, the slot #7. Therefore only 7 slots instead of 8 in the
-* CTRL4 register can be mapped to LRADC channels when using the
-* touchscreen.
-*
+* When the touchscreen is enabled, we give it two private virtual
+* channels: #6 and #7. This means that only 6 virtual channels (instead
+* of 8) will be available for buffered capture.
+*/
+#define TOUCHSCREEN_VCHANNEL1 7
+#define TOUCHSCREEN_VCHANNEL2 6
+
+ /*
* Furthermore, certain LRADC channels are shared between touchscreen
* and/or touch-buttons and generic LRADC block. Therefore when using
* either of these, these channels are not available for the regular
@@ -283,6 +286,9 @@ struct mxs_lradc {
#defineLRADC_CTRL4 0x140
#defineLRADC_CTRL4_LRADCSELECT_MASK(n) (0xf << ((n) * 4))
#defineLRADC_CTRL4_LRADCSELECT_OFFSET(n) ((n) * 4)
+#defineLRADC_CTRL4_LRADCSELECT(n, x) \
+ (((x) << LRADC_CTRL4_LRADCSELECT_OFFSET(n)) & \
+ LRADC_CTRL4_LRADCSELECT_MASK(n))
#define LRADC_RESOLUTION 12
#define LRADC_SINGLE_SAMPLE_MASK ((1 << LRADC_RESOLUTION) - 1)
@@ -364,6 +370,14 @@ static bool mxs_lradc_check_touch_event(struct mxs_lradc
*lradc)
LRADC_STATUS_TOUCH_DETECT_RAW);
}
+static void mxs_lradc_map_channel(struct mxs_lradc *lradc, unsigned vch,
+ unsigned ch)
+{
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL4_LRADCSELECT_MASK(vch),
+ LRADC_CTRL4);
+ mxs_lradc_reg_set(lradc, LRADC_CTRL4_LRADCSELECT(vch, ch), LRADC_CTRL4);
+}
+
static void mxs_lradc_setup_ts_channel(struct mxs_lradc *lradc, unsigned ch)
{
/*
@@ -391,12 +405,8 @@ static void mxs_lradc_setup_ts_channel(struct mxs_lradc
*lradc, unsigned ch)
LRADC_DELAY_DELAY(lradc->over_sample_delay - 1),
LRADC_DELAY(3));
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(2) |
- LRADC_CTRL1_LRADC_IRQ(3) | LRADC_CTRL1_LRADC_IRQ(4) |
- LRADC_CTRL1_LRADC_IRQ(5), LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(ch), LRADC_CTRL1);
- /* wake us again, when the complete conversion is done */
- mxs_lradc_reg_set(lradc, LRADC_CTRL1_LRADC_IRQ_EN(ch), LRADC_CTRL1);
/*
* after changing the touchscreen plates setting
* the signals need some initial time to settle. Start the
@@ -449,12 +459,8 @@ static void mxs_lradc_setup_ts_pressure(struct mxs_lradc
*lradc, unsigned ch1,
LRADC_DELAY_DELAY(lradc->over_sample_delay - 1),
LRADC_DELAY(3));
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(2) |
- LRADC_CTRL1_LRADC_IRQ(3) | LRADC_CTRL1_LRADC_IRQ(4) |
-
[PATCH 3.13.y-ckt 011/156] USB: usbfs: don't leak kernel data in siginfo
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let
me know.
--
From: Alan Stern
commit f0c2b68198589249afd2b1f2c4e8de8c03e19c16 upstream.
When a signal is delivered, the information in the siginfo structure
is copied to userspace. Good security practice dicatates that the
unused fields in this structure should be initialized to 0 so that
random kernel stack data isn't exposed to the user. This patch adds
such an initialization to the two places where usbfs raises signals.
Signed-off-by: Alan Stern
Reported-by: Dave Mielke
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
---
drivers/usb/core/devio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 74185cc..4c2c65b 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -501,6 +501,7 @@ static void async_completed(struct urb *urb)
as->status = urb->status;
signr = as->signr;
if (signr) {
+ memset(, 0, sizeof(sinfo));
sinfo.si_signo = as->signr;
sinfo.si_errno = as->status;
sinfo.si_code = SI_ASYNCIO;
@@ -2227,6 +2228,7 @@ static void usbdev_remove(struct usb_device *udev)
wake_up_all(>wait);
list_del_init(>list);
if (ps->discsignr) {
+ memset(, 0, sizeof(sinfo));
sinfo.si_signo = ps->discsignr;
sinfo.si_errno = EPIPE;
sinfo.si_code = SI_ASYNCIO;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] perf script segfault
what happened to this patch? not in your core or urgent branches and
perf-script is still bombing
On 3/31/15 7:36 AM, David Ahern wrote:
On 3/31/15 6:59 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, Mar 30, 2015 at 08:45:33PM -0300, Arnaldo Carvalho de Melo
escreveu:
Em Mon, Mar 30, 2015 at 04:51:34PM -0600, David Ahern escreveu:
tool was moved to ordered_events and is not initialized for pipe
mode. I
don't have time to look into it more than that before PTO on Wednesday.
I guess this one is enough, no? Checking with your example...
So the following is better, can you give it a try, please?
- Arnaldo
From fbd7d154f01c47db71a3d8b0546911872aa1de54 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo
Date: Tue, 31 Mar 2015 09:53:50 -0300
Subject: [PATCH 1/1] perf session: Always initialize ordered_events
Even when it is not used to actually reorder events, some of its fields
are used, like session->ordered_events->tool, to shorten function
signatures where tool, for instance, was being passed, as the tool is
needed for the ordered_events code, we need it there and might as well
use it for other perf_session needs.
This fixes a problem where 'perf script' had some condition that made
session->ordered_events not to be initialized even with its
script->tool ordered_events related flags asking for it to be, which
looks like another bug and needs to be investigated further.
Always initializing session->ordered_events at least leaves the current
assumptions in place, so do it now.
Reported-by: David Ahern
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/n/tip-b1xxk0rwkz2a0gip1uufm...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/session.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index adf0740c563b..89c66797abe4 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -110,6 +110,8 @@ struct perf_session *perf_session__new(struct
perf_data_file *file,
session->repipe = repipe;
machines__init(>machines);
+ordered_events__init(>ordered_events, >machines,
+ session->evlist, tool, ordered_events__deliver_event);
if (file) {
if (perf_data_file__open(file))
@@ -139,9 +141,6 @@ struct perf_session *perf_session__new(struct
perf_data_file *file,
tool->ordered_events &&
!perf_evlist__sample_id_all(session->evlist)) {
dump_printf("WARNING: No sample_id_all support, falling back
to unordered processing\n");
tool->ordered_events = false;
-} else {
-ordered_events__init(>ordered_events,
>machines,
- session->evlist, tool,
ordered_events__deliver_event);
}
return session;
Works for me. Reviewed-and-Tested-by: David Ahern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 012/156] efi/libstub: Fix boundary checking in efi_high_alloc()
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let me know. -- From: Yinghai Lu commit 7ed620bb343f434f8a85f830020c04988df2a140 upstream. While adding support loading kernel and initrd above 4G to grub2 in legacy mode, I was referring to efi_high_alloc(). That will allocate buffer for kernel and then initrd, and initrd will use kernel buffer start as limit. During testing found two buffers will be overlapped when initrd size is very big like 400M. It turns out efi_high_alloc() boundary checking is not right. end - size will be the new start, and should not compare new start with max, we need to make sure end is smaller than max. [ Basically, with the current efi_high_alloc() code it's possible to allocate memory above 'max', because efi_high_alloc() doesn't check that the tail of the allocation is below 'max'. If you have an EFI memory map with a single entry that looks like so, [0xc000-0xc0004000] And want to allocate 0x3000 bytes below 0xc0003000 the current code will allocate [0xc0001000-0xc0004000], not [0xc000-0xc0003000] like you would expect. - Matt ] Signed-off-by: Yinghai Lu Reviewed-by: Ard Biesheuvel Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Matt Fleming [ luis: backported to 3.16: - file rename: drivers/firmware/efi/libstub/efi-stub-helper.c -> drivers/firmware/efi/efi-stub-helper.c ] Signed-off-by: Luis Henriques Signed-off-by: Kamal Mostafa --- drivers/firmware/efi/efi-stub-helper.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/firmware/efi/efi-stub-helper.c b/drivers/firmware/efi/efi-stub-helper.c index b6bffbf..a7bd9d3 100644 --- a/drivers/firmware/efi/efi-stub-helper.c +++ b/drivers/firmware/efi/efi-stub-helper.c @@ -133,12 +133,12 @@ again: start = desc->phys_addr; end = start + desc->num_pages * (1UL << EFI_PAGE_SHIFT); - if ((start + size) > end || (start + size) > max) - continue; - - if (end - size > max) + if (end > max) end = max; + if ((start + size) > end) + continue; + if (round_down(end - size, align) < start) continue; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 013/156] USB: ftdi_sio: add PIDs for Actisense USB devices
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let
me know.
--
From: Mark Glover
commit f6950344d3cf4a1e231b5828b50c4ac168db3886 upstream.
These product identifiers (PID) all deal with marine NMEA format data
used on motor boats and yachts. We supply the programmed devices to
Chetco, for use inside their equipment. The PIDs are a direct copy of
our Windows device drivers (FTDI drivers with altered PIDs).
Signed-off-by: Mark Glover
[johan: edit commit message slightly ]
Signed-off-by: Johan Hovold
Signed-off-by: Kamal Mostafa
---
drivers/usb/serial/ftdi_sio.c | 17 +
drivers/usb/serial/ftdi_sio_ids.h | 20
2 files changed, 37 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 0274262..38a26cf 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -992,6 +992,23 @@ static struct usb_device_id id_table_combined [] = {
{ USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_PID, 1) },
/* GE Healthcare devices */
{ USB_DEVICE(GE_HEALTHCARE_VID, GE_HEALTHCARE_NEMO_TRACKER_PID) },
+ /* Active Research (Actisense) devices */
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NDC_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_USG_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NGT_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NGW_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AC_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AD_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AE_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AF_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEAGAUGE_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASWITCH_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_NMEA2000_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ETHERNET_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_WIFI_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_DISPLAY_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_LITE_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ANALOG_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index e52409c9..4d3da89 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1438,3 +1438,23 @@
*/
#define GE_HEALTHCARE_VID 0x1901
#define GE_HEALTHCARE_NEMO_TRACKER_PID 0x0015
+
+/*
+ * Active Research (Actisense) devices
+ */
+#define ACTISENSE_NDC_PID 0xD9A8 /* NDC USB Serial Adapter */
+#define ACTISENSE_USG_PID 0xD9A9 /* USG USB Serial Adapter */
+#define ACTISENSE_NGT_PID 0xD9AA /* NGT NMEA2000 Interface */
+#define ACTISENSE_NGW_PID 0xD9AB /* NGW NMEA2000 Gateway */
+#define ACTISENSE_D9AC_PID 0xD9AC /* Actisense Reserved */
+#define ACTISENSE_D9AD_PID 0xD9AD /* Actisense Reserved */
+#define ACTISENSE_D9AE_PID 0xD9AE /* Actisense Reserved */
+#define ACTISENSE_D9AF_PID 0xD9AF /* Actisense Reserved */
+#define CHETCO_SEAGAUGE_PID0xA548 /* SeaGauge USB Adapter */
+#define CHETCO_SEASWITCH_PID 0xA549 /* SeaSwitch USB Adapter */
+#define CHETCO_SEASMART_NMEA2000_PID 0xA54A /* SeaSmart NMEA2000 Gateway */
+#define CHETCO_SEASMART_ETHERNET_PID 0xA54B /* SeaSmart Ethernet Gateway */
+#define CHETCO_SEASMART_WIFI_PID 0xA5AC /* SeaSmart Wifi Gateway */
+#define CHETCO_SEASMART_DISPLAY_PID0xA5AD /* SeaSmart NMEA2000 Display */
+#define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter */
+#define CHETCO_SEASMART_ANALOG_PID 0xA5AF /* SeaSmart Analog Adapter */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 014/156] USB: serial: fix potential use-after-free after failed probe
3.13.11-ckt19 -stable review patch. If anyone has any objections, please let
me know.
--
From: Johan Hovold
commit 07fdfc5e9f1c966be8722e8fa927e5ea140df5ce upstream.
Fix return value in probe error path, which could end up returning
success (0) on errors. This could in turn lead to use-after-free or
double free (e.g. in port_remove) when the port device is removed.
Fixes: c706ebdfc895 ("USB: usb-serial: call port_probe and port_remove
at the right times")
Signed-off-by: Johan Hovold
Acked-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
---
drivers/usb/serial/bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/bus.c b/drivers/usb/serial/bus.c
index 6335490..e506c5b 100644
--- a/drivers/usb/serial/bus.c
+++ b/drivers/usb/serial/bus.c
@@ -75,7 +75,7 @@ static int usb_serial_device_probe(struct device *dev)
retval = device_create_file(dev, _attr_port_number);
if (retval) {
if (driver->port_remove)
- retval = driver->port_remove(port);
+ driver->port_remove(port);
goto exit_with_autopm;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
