linux-next: Tree for Dec 18
Hi all, Changes since 20151217: News: The arm defconfig build is fixed again. The arm-soc tree lost its build failure. The i2c tree still had its build failure for which I applied a patch. The clockevents tree still had its build failure so I used the version from next-20151216. The pinctrl tree gained a build failure so I used the version from next-20151217. The gpio tree still had its build failure so I used the version from next-20151215. The rtc tree lost its build failure. The akpm-current tree gained conflicts against Linus', the kvm and the powerpc trees and a build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 6222 6718 files changed, 247636 insertions(+), 106741 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (73796d8bf273 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (25cb62b76430 Linux 4.3-rc5) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (575a9d4e2c09 ARC: smp: Rename platform hook @init_cpu_smp -> @init_per_cpu) Merging arm-current/fixes (34bfbae33ae8 ARM: 8475/1: SWP emulation: Restore original *data when failed) Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (98da62b716a3 powerpc/powernv: pr_warn_once on unsupported OPAL_MSG type) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (2c302e7e4105 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging net/master (ac5cc977991d net: check both type and procotol for tcp sockets) Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless unnitialized variable warnings) Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups on boot) Merging mac80211/master (cf1e05c63642 mac80211: handle width changes from opmode notification IE in beacon) Merging sound-current/for-linus (b6903c0ed9f0 ALSA: hda - Add a fixup for Thinkpad X1 Carbon 2nd) Merging pci-current/for-linus (1dbe162d53e1 PCI: hisi: Fix hisi_pcie_cfg_read() 32-bit reads) Merging driver-core.current/driver-core-linus (31ade3b83e18 Linux 4.4-rc3) Merging tty.current/tty-linus (9ce119f318ba tty: Fix GPF in flush_to_ldisc()) Merging usb.current/usb-linus (9f9499ae8e64 Linux 4.4-rc5) Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no DMA controller set) Merging usb-serial-fixes/usb-linus (9f9499ae8e64 Linux 4.4-rc5) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL dereference) Merging staging.current/staging-linus (9f9499ae8e64 Linux 4.4-rc5) Merging char-misc.current/char-misc-linus (9f9499ae8e64 Linux 4.4-rc5) Merging input-current/for-linus (3eab4588c958 Input: elan_i2c - set input device's vendor and product IDs) Merging crypto-current/master (70d906bc1750 crypto: skcipher - Copy iv from desc even for 0-len walks) Merging ide/master (1b1050cdc5cd Merge git:/
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
pseries_le_defconfig) failed like this:
mm/huge_memory.c: In function 'insert_pfn_pmd':
mm/huge_memory.c:970:21: error: implicit declaration of func
tion 'pfn_t_pmd' [-Werror=implicit-function-declaration]
entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
^
Caused by commit
e6cf6e9a2686 ("mm, dax: convert vmf_insert_pfn_pmd() to pfn_t")
I added this patch for today:
From: Stephen Rothwell
Date: Fri, 18 Dec 2015 17:37:30 +1100
Subject: [PATCH] mm, dax: convert vmf_insert_pfn_pmd() to pfn_t fix
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 03c1a5a21c0c..835fb5ec1de1 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -186,6 +186,7 @@ void pgtable_cache_init(void);
struct page *realmode_pfn_to_page(unsigned long pfn);
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#define pfn_pmd pfn_pmd
extern pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot);
extern pmd_t mk_pmd(struct page *page, pgprot_t pgprot);
extern pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot);
--
2.6.2
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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] usb: gadget: forbid queuing request to a disabled ep
From: "Du, Changbin"
Queue a request to disabled ep doesn't make sense, and induce caller
make mistakes.
Here is a example for the android mtp gadget function driver. A mem
corruption can happen on below senario.
1) On disconnect, mtp driver disable its EPs,
2) During send_file_work and receive_file_work, mtp queues a request
to ep. (The mtp driver need improve its synchronization logic!)
3) mtp_function_unbind is invoked and all mtp requests are freed.
4) when udc process the request queued on step 2, will cause kernel
NULL pointer dereference exception.
Signed-off-by: Du, Changbin
---
change from v3: fix v3's error.
change from v2: igonre ep0 as it always enabled during usb session.
change from v1: add WARN_ON_ONCE message.
---
include/linux/usb/gadget.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3d583a1..fc78687 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -402,6 +402,9 @@ static inline void usb_ep_free_request(struct usb_ep *ep,
static inline int usb_ep_queue(struct usb_ep *ep,
struct usb_request *req, gfp_t gfp_flags)
{
+ if (WARN_ON_ONCE(!ep->enabled && ep->address))
+ return -ESHUTDOWN;
+
return ep->ops->queue(ep, req, gfp_flags);
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] pci: Update VPD size with correct length
On 12/17/2015 06:13 PM, Alexander Duyck wrote:
On Wed, Dec 16, 2015 at 11:59 PM, Hannes Reinecke wrote:
PCI-2.2 VPD entries have a maximum size of 32k, but might actually
be smaller than that. To figure out the actual size one has to read
the VPD area until the 'end marker' is reached.
Trying to read VPD data beyond that marker results in 'interesting'
effects, from simple read errors to crashing the card. And to make
matters worse not every PCI card implements this properly, leaving
us with no 'end' marker or even completely invalid data.
This path modifies the size of the VPD attribute to the available
size, and disables the VPD attribute altogether if no valid data
could be read.
Cc: Alexander Duyck
Cc: Bjorn Helgaas
Signed-off-by: Hannes Reinecke
---
drivers/pci/access.c | 57
1 file changed, 57 insertions(+)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 59ac36f..0a647b1 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -475,6 +475,56 @@ static const struct pci_vpd_ops pci_vpd_f0_ops = {
.release = pci_vpd_pci22_release,
};
+/**
+ * pci_vpd_size - determine actual size of Vital Product Data
+ * @dev: pci device struct
+ * @old_size: current assumed size, also maximum allowed size
+ *
"old_siz"e was dropped so you can remove this line.
+ */
+static size_t
+pci_vpd_pci22_size(struct pci_dev *dev)
+{
+ size_t off = 0;
+ unsigned char header[1+2]; /* 1 byte tag, 2 bytes length */
+
+ while (off < PCI_VPD_PCI22_SIZE &&
+ pci_read_vpd(dev, off, 1, header) == 1) {
+ unsigned char tag;
+
The offset comparison is probably redundant. There is already a check
in pci_vpd_pci22_read that will check the offset and return -EINVAL if
we have exceeded vpd->base.len. As such you can probably just do the
pci_read_vpd comparison and drop the offset length entirely.
Indeed it does. Will be doing so.
+ if (header[0] & PCI_VPD_LRDT) {
+ /* Large Resource Data Type Tag */
+ tag = pci_vpd_lrdt_tag(header);
+ /* Only read length from known tag items */
+ if ((tag == PCI_VPD_LTIN_ID_STRING) ||
+ (tag == PCI_VPD_LTIN_RO_DATA) ||
+ (tag == PCI_VPD_LTIN_RW_DATA)) {
+ if (pci_read_vpd(dev, off+1, 2,
+[1]) != 2)
+ return off + 1;
+ off += PCI_VPD_LRDT_TAG_SIZE +
+ pci_vpd_lrdt_size(header);
+ }
+ } else {
+ /* Short Resource Data Type Tag */
+ off += PCI_VPD_SRDT_TAG_SIZE +
+ pci_vpd_srdt_size(header);
+ tag = pci_vpd_srdt_tag(header);
+ }
+ if (tag == PCI_VPD_STIN_END)/* End tag descriptor */
+ return off;
+ if ((tag != PCI_VPD_LTIN_ID_STRING) &&
+ (tag != PCI_VPD_LTIN_RO_DATA) &&
+ (tag != PCI_VPD_LTIN_RW_DATA)) {
+ dev_dbg(>dev,
+ "invalid %s vpd tag %02x at offset %zu.",
+ (header[0] & PCI_VPD_LRDT) ? "large" : "short",
+ tag, off);
+ break;
+ }
+ }
+ return 0;
+}
+
int pci_vpd_pci22_init(struct pci_dev *dev)
{
struct pci_vpd_pci22 *vpd;
@@ -497,6 +547,13 @@ int pci_vpd_pci22_init(struct pci_dev *dev)
vpd->cap = cap;
vpd->busy = false;
dev->vpd = >base;
+ vpd->base.len = pci_vpd_pci22_size(dev);
+ if (vpd->base.len == 0) {
+ dev_dbg(>dev, "Disabling VPD access.");
+ dev->vpd = NULL;
+ kfree(vpd);
+ return -ENXIO;
+ }
return 0;
}
It looks like this still doesn't address the VPD_REF_F0 issue I
mentioned earlier. We don't need to compute the length for each
function we only need to do it once. I would recommend modifying
things so that you set vpd->base.len to 0 if the VPD_REF_F0 flag is
set.
But that would effectively inhibit access to the VPD on those
devices, rendering the entire 'f0_ops' thingie quite pointless, right?
I think it's better to directly retrieve the VPD length from the
base pci device, that would give us the correct length _and_ save
duplicate calculations.
Also I wouldn't delete the vpd configuration if the length is not
correct as that will likely break several quirks that already exist
that are setting the length. Also there is no need to return an
error, the fact is the part has VPD but we cannot determine the length
as such the correct solution is to leave it at 0. We can leave
[PATCH 4/4] drm/fsl-dcu: add TCON driver
Add driver for the TCON (timing controller) module. The TCON module
is a separate module attached after the DCU (display controller
unit). Each DCU instance has its own, directly connected TCON
instance. The DCU's RGB and timing signals are passing through
the TCON module. TCON can provide timing signals for raw TFT panels
or operate in a bypass mode which leaves all signals unaltered.
The driver currently only supports the bypass mode.
Signed-off-by: Stefan Agner
---
.../devicetree/bindings/display/fsl,dcu.txt| 4 +
.../devicetree/bindings/display/fsl,tcon.txt | 18 +++
drivers/gpu/drm/fsl-dcu/Makefile | 3 +-
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 1 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 11 ++
drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 134 +
drivers/gpu/drm/fsl-dcu/fsl_tcon.h | 37 ++
8 files changed, 213 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/display/fsl,tcon.txt
create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_tcon.c
create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_tcon.h
diff --git a/Documentation/devicetree/bindings/display/fsl,dcu.txt
b/Documentation/devicetree/bindings/display/fsl,dcu.txt
index ebf1be9..8153c9a 100644
--- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
+++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
@@ -11,6 +11,9 @@ Required properties:
- big-endian Boolean property, LS1021A DCU registers are big-endian.
- fsl,panel: The phandle to panel node.
+Optional properties:
+- fsl,tcon:The phandle to the timing controller node.
+
Examples:
dcu: dcu@2ce {
compatible = "fsl,ls1021a-dcu";
@@ -19,4 +22,5 @@ dcu: dcu@2ce {
clock-names = "dcu";
big-endian;
fsl,panel = <>;
+ fsl,tcon = <>;
};
diff --git a/Documentation/devicetree/bindings/display/fsl,tcon.txt
b/Documentation/devicetree/bindings/display/fsl,tcon.txt
new file mode 100644
index 000..2e1015e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/fsl,tcon.txt
@@ -0,0 +1,18 @@
+Device Tree bindings for Freescale TCON Driver
+
+Required properties:
+- compatible: Should be one of
+ * "fsl,vf610-tcon".
+
+- reg: Address and length of the register set for dcu.
+- clocks: From common clock binding: handle to tcon ipg clock.
+- clock-names: From common clock binding: Shall be "ipg".
+
+Examples:
+timing-controller@4003d000 {
+ compatible = "fsl,vf610-tcon";
+ reg = <0x4003d000 0x1000>;
+ clocks = < VF610_CLK_TCON0>;
+ clock-names = "ipg";
+ status = "okay";
+};
diff --git a/drivers/gpu/drm/fsl-dcu/Makefile b/drivers/gpu/drm/fsl-dcu/Makefile
index 6ea1523..b35a292 100644
--- a/drivers/gpu/drm/fsl-dcu/Makefile
+++ b/drivers/gpu/drm/fsl-dcu/Makefile
@@ -3,5 +3,6 @@ fsl-dcu-drm-y := fsl_dcu_drm_drv.o \
fsl_dcu_drm_rgb.o \
fsl_dcu_drm_plane.o \
fsl_dcu_drm_crtc.o \
-fsl_dcu_drm_fbdev.o
+fsl_dcu_drm_fbdev.o \
+fsl_tcon.o
obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu-drm.o
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index e01c813..679cde8 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -27,6 +27,7 @@
#include "fsl_dcu_drm_crtc.h"
#include "fsl_dcu_drm_drv.h"
+#include "fsl_tcon.h"
static bool fsl_dcu_drm_is_volatile_reg(struct device *dev, unsigned int reg)
{
@@ -218,6 +219,7 @@ static int fsl_dcu_drm_pm_suspend(struct device *dev)
drm_kms_helper_poll_disable(fsl_dev->drm);
regcache_cache_only(fsl_dev->regmap, true);
regcache_mark_dirty(fsl_dev->regmap);
+ fsl_tcon_suspend(fsl_dev->tcon);
clk_disable(fsl_dev->clk);
clk_unprepare(fsl_dev->clk);
@@ -244,6 +246,8 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
return ret;
}
+ fsl_tcon_resume(fsl_dev->tcon);
+
drm_kms_helper_poll_enable(fsl_dev->drm);
regcache_cache_only(fsl_dev->regmap, false);
regcache_sync(fsl_dev->regmap);
@@ -338,6 +342,8 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
return PTR_ERR(fsl_dev->regmap);
}
+ fsl_dev->tcon = fsl_tcon_init(dev);
+
id = of_match_node(fsl_dcu_of_match, pdev->dev.of_node);
if (!id)
return -ENODEV;
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
index 2a724f3..a8919f6 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
@@ -183,6 +183,7 @@ struct fsl_dcu_drm_device {
struct regmap *regmap;
int irq;
struct
[PATCH 1/4] ARM: dts: vf610: add display nodes
Add the dcu and tcon nodes to enable the Display Controller Unit
and Timing Controller in Vybrid's SoC level device-tree file.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vfxxx.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 6736bae..8972c1c 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -232,6 +232,14 @@
<2000>;
};
+ tcon0: timing-controller@4003d000 {
+ compatible = "fsl,vf610-tcon";
+ reg = <0x4003d000 0x1000>;
+ clocks = < VF610_CLK_TCON0>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
wdoga5: wdog@4003e000 {
compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
reg = <0x4003e000 0x1000>;
@@ -337,6 +345,16 @@
status = "disabled";
};
+ dcu0: dcu@40058000 {
+ compatible = "fsl,vf610-dcu";
+ reg = <0x40058000 0x1200>;
+ interrupts = <30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < VF610_CLK_DCU0>;
+ clock-names = "dcu";
+ fsl,tcon = <>;
+ status = "disabled";
+ };
+
i2c0: i2c@40066000 {
#address-cells = <1>;
#size-cells = <0>;
--
2.6.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 3/4] ARM: clk: vf610: add TCON ipg clock
Add the ipg (bus) clock for the TCON modules (Timing Controller). This
module is required by the new DCU DRM driver, since the display signals
pass through TCON.
Signed-off-by: Stefan Agner
---
drivers/clk/imx/clk-vf610.c | 3 +++
include/dt-bindings/clock/vf610-clock.h | 4 +++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
index d1b1c95..cb86245 100644
--- a/drivers/clk/imx/clk-vf610.c
+++ b/drivers/clk/imx/clk-vf610.c
@@ -327,6 +327,9 @@ static void __init vf610_clocks_init(struct device_node
*ccm_node)
clk[VF610_CLK_DCU1_DIV] = imx_clk_divider("dcu1_div", "dcu1_en",
CCM_CSCDR3, 20, 3);
clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "dcu1_div", CCM_CCGR9,
CCM_CCGRx_CGn(8));
+ clk[VF610_CLK_TCON0] = imx_clk_gate2("tcon0", "platform_bus",
CCM_CCGR1, CCM_CCGRx_CGn(13));
+ clk[VF610_CLK_TCON1] = imx_clk_gate2("tcon1", "platform_bus",
CCM_CCGR7, CCM_CCGRx_CGn(13));
+
clk[VF610_CLK_ESAI_SEL] = imx_clk_mux("esai_sel", CCM_CSCMR1, 20, 2,
esai_sels, 4);
clk[VF610_CLK_ESAI_EN] = imx_clk_gate("esai_en", "esai_sel",
CCM_CSCDR2, 30);
clk[VF610_CLK_ESAI_DIV] = imx_clk_divider("esai_div", "esai_en",
CCM_CSCDR2, 24, 4);
diff --git a/include/dt-bindings/clock/vf610-clock.h
b/include/dt-bindings/clock/vf610-clock.h
index 56c16aa..fbe17cc 100644
--- a/include/dt-bindings/clock/vf610-clock.h
+++ b/include/dt-bindings/clock/vf610-clock.h
@@ -195,6 +195,8 @@
#define VF610_CLK_SNVS 182
#define VF610_CLK_DAP 183
#define VF610_CLK_OCOTP 184
-#define VF610_CLK_END 185
+#define VF610_CLK_TCON0185
+#define VF610_CLK_TCON1186
+#define VF610_CLK_END 187
#endif /* __DT_BINDINGS_CLOCK_VF610_H */
--
2.6.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 0/4] drm/fsl-dcu: add TCON and Vybrid support
This patchset adds the missing pieces to make the Freescale DCU DRM driver work on Freescale Vybrid. Foremost, it adds support for the timing controller (TCON) module. The module is between the Display Controller and the actual output pins. It allows to alter the timings for RAW TFT displays, but can also operate in a bypass mode. This change has only support for the bypass mode. Earlier variants of the DCU DRM driver configured the TCON module in bypass mode, however this has been removed and postponed. The last variant with the TCON code was v9: https://lkml.org/lkml/2015/7/13/242 This change is an attempt to implement a proper driver. Ideas have been taken from the sun4i Tcon driver: https://lkml.org/lkml/2015/10/30/369 The patchset depends on my fsl-dcu fixes patchset: https://lkml.org/lkml/2015/11/18/953 Stefan Agner (4): ARM: dts: vf610: add display nodes ARM: dts: vf610-colibri: enable display controller ARM: clk: vf610: add TCON ipg clock drm/fsl-dcu: add TCON driver .../devicetree/bindings/display/fsl,dcu.txt| 4 + .../devicetree/bindings/display/fsl,tcon.txt | 18 +++ arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 16 +++ arch/arm/boot/dts/vf-colibri.dtsi | 33 + arch/arm/boot/dts/vfxxx.dtsi | 18 +++ drivers/clk/imx/clk-vf610.c| 3 + drivers/gpu/drm/fsl-dcu/Makefile | 3 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 1 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 11 ++ drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 134 + drivers/gpu/drm/fsl-dcu/fsl_tcon.h | 37 ++ include/dt-bindings/clock/vf610-clock.h| 4 +- 13 files changed, 286 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/fsl,tcon.txt create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_tcon.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_tcon.h -- 2.6.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 2/4] ARM: dts: vf610-colibri: enable display controller
Enable dcu node which is used by the DCU DRM driver. Assign the 5.7"
EDT panel with VGA resolution which Toradex sells often with the
evaluation board.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 16 +++
arch/arm/boot/dts/vf-colibri.dtsi | 33 +++
2 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index ed65e0f..f5d4c78 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -18,6 +18,11 @@
clock-frequency = <1600>;
};
+ panel: panel {
+ compatible = "edt,et057090dhu";
+ backlight = <>;
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -53,6 +58,13 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_dcu0_1>;
+ fsl,panel = <>;
+ status = "okay";
+};
+
{
status = "okay";
@@ -100,6 +112,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
b/arch/arm/boot/dts/vf-colibri.dtsi
index e5949b9..c1afb4e 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -133,6 +133,39 @@
>;
};
+ pinctrl_dcu0_1: dcu0grp_1 {
+ fsl,pins = <
+ VF610_PAD_PTE0__DCU0_HSYNC 0x1902
+ VF610_PAD_PTE1__DCU0_VSYNC 0x1902
+ VF610_PAD_PTE2__DCU0_PCLK 0x1902
+ VF610_PAD_PTE4__DCU0_DE 0x1902
+ VF610_PAD_PTE5__DCU0_R0 0x1902
+ VF610_PAD_PTE6__DCU0_R1 0x1902
+ VF610_PAD_PTE7__DCU0_R2 0x1902
+ VF610_PAD_PTE8__DCU0_R3 0x1902
+ VF610_PAD_PTE9__DCU0_R4 0x1902
+ VF610_PAD_PTE10__DCU0_R50x1902
+ VF610_PAD_PTE11__DCU0_R60x1902
+ VF610_PAD_PTE12__DCU0_R70x1902
+ VF610_PAD_PTE13__DCU0_G00x1902
+ VF610_PAD_PTE14__DCU0_G10x1902
+ VF610_PAD_PTE15__DCU0_G20x1902
+ VF610_PAD_PTE16__DCU0_G30x1902
+ VF610_PAD_PTE17__DCU0_G40x1902
+ VF610_PAD_PTE18__DCU0_G50x1902
+ VF610_PAD_PTE19__DCU0_G60x1902
+ VF610_PAD_PTE20__DCU0_G70x1902
+ VF610_PAD_PTE21__DCU0_B00x1902
+ VF610_PAD_PTE22__DCU0_B10x1902
+ VF610_PAD_PTE23__DCU0_B20x1902
+ VF610_PAD_PTE24__DCU0_B30x1902
+ VF610_PAD_PTE25__DCU0_B40x1902
+ VF610_PAD_PTE26__DCU0_B50x1902
+ VF610_PAD_PTE27__DCU0_B60x1902
+ VF610_PAD_PTE28__DCU0_B70x1902
+ >;
+ };
+
pinctrl_dspi1: dspi1grp {
fsl,pins = <
VF610_PAD_PTD5__DSPI1_CS0 0x33e2
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3] usb: gadget: forbid queuing request to a disabled ep
> >
> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> > index 3d583a1..0c5d9ea 100644
> > --- a/include/linux/usb/gadget.h
> > +++ b/include/linux/usb/gadget.h
> > @@ -402,6 +402,9 @@ static inline void usb_ep_free_request(struct
> usb_ep *ep,
> > static inline int usb_ep_queue(struct usb_ep *ep,
> >struct usb_request *req, gfp_t gfp_flags)
> > {
> > + if (WARN_ON_ONCE(!ep->enabled && !ep->address))
>
> this will only trigger for a disabled ep0. Are you testing any of your
> patches at all ?
>
> --
> balbi
Oops, I sent a wrong patch. I will send right patch again as v4, very sorry for
this.
The right patch has been verified on 3.14 by back-porting related 1 patch.
--
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: [RESEND PATCH] regulator: mt6311: Use REGCACHE_RBTREE
Thanks to the patch.
On Fri, 2015-12-18 at 15:11 +0800, Daniel Kurtz wrote:
> This regulator is on a slow i2c bus. Register accesses are very simple,
> they all either enable/disable a regulator channel, or select a new
> voltage level. Thus, reading registers from the device will always
> return what was last written.
>
> Therefore we can save a lot of time when reading registers by using a
> regmap_cache. Since the register map is relatively large, but we only
> ever access a few of them, we use an RBTREE cache.
>
> Signed-off-by: Daniel Kurtz
Acked-by: Henry Chen
> ---
> I used the wrong commit message subject in the first attempt.
> Maybe this time someone will review it ;-).
> ---
> drivers/regulator/mt6311-regulator.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/regulator/mt6311-regulator.c
> b/drivers/regulator/mt6311-regulator.c
> index 02c4e5f..0495716 100644
> --- a/drivers/regulator/mt6311-regulator.c
> +++ b/drivers/regulator/mt6311-regulator.c
> @@ -30,6 +30,7 @@ static const struct regmap_config mt6311_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> .max_register = MT6311_FQMTR_CON4,
> + .cache_type = REGCACHE_RBTREE,
> };
>
> /* Default limits measured in millivolts and milliamps */
--
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] irqchip/gic: Identify and report any reserved SGI IDs
On Thu, 17 Dec 2015 19:26:10 +
Daniel Thompson wrote:
> On Wed, Dec 16, 2015 at 05:47:09PM +, Marc Zyngier wrote:
> > Hi Daniel,
>
> Hi Marc
>
> Thanks for the review.
>
>
> > On 16/12/15 17:08, Daniel Thompson wrote:
> > > It is possible for the secure world to reserve certain SGI IDs for itself.
> > > Currently we have limited visibility of which IDs are safe to use for
> > > IPIs.
> > >
> > > Modify the GIC initialization code to actively search for reserved SGI IDs
> > > and report if any are found. Warn even more loudly if the reserved SGIs
> > > overlap with the normal IPI range.
> > >
> > > When run on an Inforce IFC6410 (Snapdragon 600) this code produces the
> > > following messages:
> > > ~~~ cut here ~~~
> > > CPU0: Detected reserved SGI IDs: 14-15
> > > CPU1: Detected reserved SGI IDs: 15
> > > CPU2: Detected reserved SGI IDs: 15
> > > CPU3: Detected reserved SGI IDs: 15
> > > ~~~ cut here ~~~
> > >
> > > Signed-off-by: Daniel Thompson
>
> BTW you *didn't* say "this code is pointless and I hate it"...
Well, this was obviously used to detect another issue (patch #1), so I
can't see any harm in trying to sanitize things, as long as it doesn't
break anything else. I imagine this patch will also trigger on my
sunxi platforms, which use a SGI to implement PSCI in secure mode.
> Does that mean I should be looking at adding similar code for GICv3+? I
> wanted to guage reactions to this sort of diagnostics before getting
> carried away!
Could be useful as well.
>
>
> > > +
> > > + /*
> > > + * Fiddle with the SGI set/clear registers to try identify
> > > + * any IPIs that are reserved for secure world.
> > > + */
> > > + bitmap_fill(sgi_mask, 16);
> > > +
> > > + for (i = 0; i < 16; i++) {
> > > + void __iomem *set_reg =
> > > + dist_base + GIC_DIST_SGI_PENDING_SET + (i & ~3);
> > > + void __iomem *clear_reg =
> > > + dist_base + GIC_DIST_SGI_PENDING_CLEAR + (i & ~3);
> > > + unsigned long mask = cpu_mask << (8*(i%4));
> > > + unsigned long flags, pending, after_clear, after_set;
> >
> > Please make these u32, as unsigned long is 64bit on arm64. Another thing
> > to note is that GICD_CPEND{S,C}SGIRn are byte accessible, so you can
> > save yourself some this hassle shifting things around and just write a
> > single byte. You're already writing 16 times anyway...
>
> Will do both.
>
>
> > Another thing to consider is that these locations are only defined on
> > GICv2 and not GICv1, so this patch is likely to cause trouble on older HW.
>
> As presented the code relies on the RAZ/WI property of reserved
> registers to avoid issues on GICv1; it does not report anything if there
> appear to be know working SGIs on the assumption we are actually running
> on a GICv1.
>
> You'd prefer an explicit version check?
I'd rather be cautious and check for the architecture version,
specially if you settle for the byte access mentioned above (a GICv1
may not support byte access and explode unexpectedly). ICPIDR2.ArchRev
should be the right thing to check.
>
>
> > > +
> > > + local_irq_save(flags);
> >
> > Why do you need to do this? The CPU interface is not enabled yet, so I
> > can't see how you could get an interrupt on this CPU.
>
> Agreed. Can get rid of these.
>
>
> > > +
> > > + /* record original value */
> > > + pending = readl_relaxed(set_reg);
> > > +
> > > + /* clear, test, set, and test again */
> > > + writel_relaxed(mask, clear_reg);
> > > + after_clear = readl_relaxed(set_reg);
> > > + writel_relaxed(mask, set_reg);
> > > + after_set = readl_relaxed(set_reg);
> >
> > It should be enough to write to the SET register, and read back, as the
> > bit is RAZ/WI when the interrupt is Group-0.
>
> Good point. Will simplify.
I'd also suggest moving the whole thing to a separate function that'd
get called from gic_cpu_init().
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
--
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: [RESEND][PATCH v2] dmaengine: bcm2835: Add slave dma support
> On 18.12.2015, at 07:05, Vinod Koul wrote:
>
> On Thu, Dec 17, 2015 at 07:11:48PM +0100, Martin Sperl wrote:
>
>> +
>> +/* Setup addresses */
>> +if (d->dir == DMA_DEV_TO_MEM) {
>> +control_block->info = BCM2835_DMA_D_INC |
>> + BCM2835_DMA_D_WIDTH |
>> + BCM2835_DMA_S_DREQ;
>> +control_block->src = dev_addr;
>> +control_block->dst = addr + (dma_addr_t)j;
>> +} else {
>> +control_block->info = BCM2835_DMA_S_INC |
>> + BCM2835_DMA_S_WIDTH |
>> + BCM2835_DMA_D_DREQ;
>> +control_block->src = addr + (dma_addr_t)j;
>> +control_block->dst = dev_addr;
>> +}
>> +
>> +/* Common part */
>> +control_block->info |=
>> +BCM2835_DMA_WAITS(BCM2835_DMA_WAIT_CYCLES);
>> +control_block->info |= BCM2835_DMA_WAIT_RESP;
>> +
>> +/* Enable */
>> +if (i == sg_len - 1 && len - j <= max_size)
>> +control_block->info |= BCM2835_DMA_INT_EN;
>> +
>> +/* Setup synchronization */
>> +if (sync_type)
>> +control_block->info |= sync_type;
>> +
>> +/* Setup DREQ channel */
>> +if (c->dreq)
>> +control_block->info |=
>> +BCM2835_DMA_PER_MAP(c->dreq);
>> +
>> +/* Length of a frame */
>> +control_block->length = min(len - j, max_size);
>> +d->size += control_block->length;
>> +
>> +if (i < sg_len - 1 || len - j > max_size) {
>> +/* Next block is the next frame. */
>> +control_block->next =
>> +d->control_block_base_phys +
>> +sizeof(struct bcm2835_dma_cb) *
>> +(i + split_cnt + 1);
>> +} else {
>> +/* Next block is empty. */
>> +control_block->next = 0;
>> +}
>> +
>> +if (len - j > max_size)
>> +split_cnt++;
>
> Most of this part is common with the cyclic and seems copy paste. Can we
> use common routine to do common work please
I agree - can have a look - the big question is: how would I document the
individual changes by Gellert Weisz and myself correctly?
* just a single patch with an attribution tag (which?) or just a commit message?
* Patchset with 2 patches: the original by Gellert Weisz (this)
plus the modification to consolidate the code above?
Thanks,
Martin--
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 08/10] bpf samples: Add utils.[ch] for using BPF
On 2015/12/18 15:04, Wangnan (F) wrote: On 2015/12/18 14:19, Alexei Starovoitov wrote: On Fri, Dec 18, 2015 at 09:47:11AM +0800, Wangnan (F) wrote: This is a limitation in tools/lib/bpf/libbpf.h, which has a #include in its header. libbpf.h requires this include because its API uses ERR_PTR() to encode error code. For example, when calling bpf_object__open(), caller should use IS_ERR() to check its return value instead of compare with NULL, and use PTR_ERR() to retrive error number. However, linux/err.h is not a part of uapi. To make libbpf work, one has to create its own err.h. [SNIP] What about moving them into include/uapi/linux/filter.h ? Then normal user programs like those in samples/bpf can access them easier. we don't want to add these macros to uapi. Why not to add it to tools/include/linux/filter.h instead? What I want to do in this patchset is not only removing original libbpf.c and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public available library for other userspace tools (tc for example). Switching samples/bpf into libbpf is the first step of this goal. From doing this I found and fixed some limitation, like those missed BPF map operations. Making libbpf.h and bpf.h available for normal userspace programs is also important. Having the above goal, I think you can understand why improving tools/include is not a good idea. You don't want to force a normal userspace program setup a similar header environment for using libbpf. It is relatively a small library. So it would be good if bpf.h and libbpf.h only depend on what can be found in uapi. I suddenly realized that only linux/err.h causes problem. Those macros from filter.h are never accessed by libbpf. So we can drop those filter.h by making samples/bpf include from tools/include. However we still need a wrapper in libbpf to avoid including linux/err.h. Thank you. -- 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/3] NTB: Add AMD PCI-Express NTB driver
> From: Allen Hubbe [mailto:alle...@gmail.com]
> Sent: Friday, December 18, 2015 12:46 AM
> To: Yu, Xiangliang
> Cc: jdma...@kudzu.us; dave.ji...@intel.com; linux-...@googlegroups.com;
> linux-kernel@vger.kernel.org; SPG_Linux_Kernel
> Subject: Re: [PATCH 1/3] NTB: Add AMD PCI-Express NTB driver
>
> On Thu, Dec 17, 2015 at 3:17 AM, Xiangliang Yu
> wrote:
> > AMD NTB support following main features:
> > (1) Three memory windows;
> > (2) Sixteen 32-bit scratch pad;
> > (3) Two 16-bit doorbell interrupt;
> > (4) Five event interrupts;
> > (5) One system can wake up opposite system of NTB;
> > (6) Flush previous request to the opposite system;
> > (7) There are reset and PME_TO mechanisms between two systems;
> >
> > Signed-off-by: Xiangliang Yu
>
> Is hardware available on which this can be tested?
No yet. Right now, verified the driver on emulator.
>
> > +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
>
> > +static u64 amd_ntb_db_read(struct ntb_dev *ntb) {
> > + struct amd_ntb_dev *ndev = ntb_ndev(ntb);
> > +
> > + return (u64)NTB_READ_REG(DBSTAT); }
>
> DBSTAT hides the use of ndev, or ndev is unused. The code should be more
> clear, here, and in other places where NTB_READ_REG and NTB_WRITE_REG
> are used with a macro argument.
Got it, I will add ndev into macro arguments.
>
> > +static void amd_ack_SMU(struct amd_ntb_dev *ndev, u32 bit) {
> > + int reg;
> > +
> > + reg = NTB_READ_REG(SMUACK);
> > + reg |= bit;
> > + NTB_WRITE_REG(reg, SMUACK);
> > +
> > + ndev->peer_sta |= bit;
> > +}
> > +
> > +/*
> > + * flush the requests to peer side
> > + */
> > +static int amd_flush_peer_requests(struct amd_ntb_dev *ndev) {
> > + u32 reg;
> > +
> > + if (!amd_link_is_up(ndev)) {
> > + dev_err(ndev_dev(ndev), "link is down.\n");
> > + return -EINVAL;
> > + }
> > +
>
> Add reinit_completion, or this may already be "complete" from a previous
> flush.
Ok.
>
> > + reg = NTB_READ_REG(FLUSHTRIG);
> > + reg |= 0x1;
> > + NTB_WRITE_REG(reg, FLUSHTRIG);
> > +
> > + wait_for_completion(>flush_cmpl);
>
> Because of wait_for_completion, that this can only be called in a thread
> context. This is unlike other functions of ntb.h, so there should at least
> be a
> note in the api documentation.
Ok.
>
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * wake up the peer side
> > + */
> > +static int amd_wakeup_peer_side(struct amd_ntb_dev *ndev) {
> > + u32 reg;
> > +
> > + if (!amd_link_is_up(ndev)) {
> > + dev_warn(ndev_dev(ndev), "link is down.\n");
> > + return -EINVAL;
> > + }
> > +
>
> See previous comment.
>
> > + NTB_READ_REG(PMSGTRIG);
> > + reg |= 0x1;
> > + NTB_WRITE_REG(reg, PMSGTRIG);
> > +
> > + wait_for_completion(>wakeup_cmpl);
> > +
> > + return 0;
> > +}
>
>
> > +static void amd_handle_event(struct amd_ntb_dev *ndev, int vec) {
> > + u32 status;
> > +
> > + status = NTB_READ_REG(INTSTAT);
> > + if (!(status & AMD_EVENT_INTMASK))
> > + return;
> > +
> > + dev_dbg(ndev_dev(ndev), "status = 0x%x and vec = %d\n",
> > + status, vec);
> > +
> > + status &= AMD_EVENT_INTMASK;
> > + switch (status) {
> > + case AMD_PEER_FLUSH_EVENT:
> > + complete(>flush_cmpl);
> > + break;
> > + case AMD_PEER_RESET_EVENT:
> > + amd_ack_SMU(ndev, AMD_PEER_RESET_EVENT);
> > +
> > + /* link down first */
> > + ntb_link_event(>ntb);
> > + /* polling peer status */
> > + schedule_delayed_work(>hb_timer,
> > + AMD_LINK_HB_TIMEOUT);
> > +
> > + break;
> > + case AMD_PEER_D3_EVENT:
> > + case AMD_PEER_PMETO_EVENT:
> > + amd_ack_SMU(ndev, status);
> > +
> > + /* link down */
> > + ntb_link_event(>ntb);
> > +
> > + break;
> > + case AMD_PEER_D0_EVENT:
> > + status = NTB_READ_PEER_REG(PMESTAT);
> > + /* check if this is WAKEUP event */
> > + if (status & 0x1)
> > + complete(>wakeup_cmpl);
> > +
> > + amd_ack_SMU(ndev, AMD_PEER_D0_EVENT);
> > +
> > + if (amd_link_is_up(ndev))
> > + ntb_link_event(>ntb);
> > + else
> > + schedule_delayed_work(>hb_timer,
> > + AMD_LINK_HB_TIMEOUT);
> > + break;
> > + default:
> > + pr_err("Unsupported interrupt.\n");
> > + break;
> > + }
> > +}
> > +
> > +static irqreturn_t ndev_interrupt(struct amd_ntb_dev *ndev, int vec)
> > +{
> > + dev_dbg(ndev_dev(ndev), "vec %d\n", vec);
> > +
> > + if (vec > 20) {
>
> This duplicates the "default" case of amd_handle_event.
Ok, I'll refine the code.
>
> > +
Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller
On Thu, Dec 17, 2015 at 11:23:31AM -0800, Eduardo Valentin wrote:
> On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> > On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer
> > wrote:
> > > This adds the device tree binding documentation for the mediatek thermal
> > > controller found on Mediatek MT8173 and other SoCs.
> > >
> > > Signed-off-by: Sascha Hauer
> > > Reviewed-by: Daniel Kurtz
> > > Acked-by: Rob Herring
> > > ---
> > > .../bindings/thermal/mediatek-thermal.txt | 43
> > > ++
> > > 1 file changed, 43 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > > b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > > new file mode 100644
> > > index 000..81f9a51
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> > > @@ -0,0 +1,43 @@
> > > +* Mediatek Thermal
> > > +
> > > +This describes the device tree binding for the Mediatek thermal
> > > controller
> > > +which measures the on-SoC temperatures. This device does not have its
> > > own ADC,
> > > +instead it directly controls the AUXADC via AHB bus accesses. For this
> > > reason
> > > +this device needs phandles to the AUXADC. Also it controls a mux in the
> > > +apmixedsys register space via AHB bus accesses, so a phandle to the
> > > APMIXEDSYS
> > > +is also needed.
> > > +
> > > +Required properties:
> > > +- compatible: "mediatek,mt8173-thermal"
> > > +- reg: Address range of the thermal controller
> > > +- interrupts: IRQ for the thermal controller
> > > +- clocks, clock-names: Clocks needed for the thermal controller. required
> > > + clocks are:
> > > + "therm": Main clock needed for register access
> > > + "auxadc": The AUXADC clock
> > > +- resets: Reference to the reset controller controlling the thermal
> > > controller.
> > > +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller
> > > uses
> > > +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
> > > +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a
> > > description.
> > > +
> > > +Optional properties:
> > > +- nvmem-cells: A phandle to the calibration data provided by a nvmem
> > > device. If
> > > + unspecified default values shall be used.
> > > +- nvmem-cell-names: Should be "calibration-data"
> > > +
> > > +Example:
> > > +
> > > + thermal: thermal@1100b000 {
> > > + #thermal-sensor-cells = <1>;
> >
> > Tiny nit: this should now be:
> >
> > #thermal-sensor-cells = <0>;
>
>
> This is actually not so tiny'shy. Why does this driver masks out all
> sensors available? Why don't we expose all of them and use id property
> to expose and identify each of them?
This has been the case until v9 of this series. It was requested by
Mediatek that the CPU frequency regulation works better when the maximum
of all sensors is taken instead of only single sensors. We decided to
expose the maximum of all sensors in the device tree. IN the end it will
be easier to add additional sensors should we need them later than it is
to get rid of sensors we don't need.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] regulator: mt6311: Use REGCACHE_RBTREE
This regulator is on a slow i2c bus. Register accesses are very simple,
they all either enable/disable a regulator channel, or select a new
voltage level. Thus, reading registers from the device will always
return what was last written.
Therefore we can save a lot of time when reading registers by using a
regmap_cache. Since the register map is relatively large, but we only
ever access a few of them, we use an RBTREE cache.
Signed-off-by: Daniel Kurtz
---
I used the wrong commit message subject in the first attempt.
Maybe this time someone will review it ;-).
---
drivers/regulator/mt6311-regulator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/mt6311-regulator.c
b/drivers/regulator/mt6311-regulator.c
index 02c4e5f..0495716 100644
--- a/drivers/regulator/mt6311-regulator.c
+++ b/drivers/regulator/mt6311-regulator.c
@@ -30,6 +30,7 @@ static const struct regmap_config mt6311_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = MT6311_FQMTR_CON4,
+ .cache_type = REGCACHE_RBTREE,
};
/* Default limits measured in millivolts and milliamps */
--
2.6.0.rc2.230.g3dd15c0
--
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 08/10] bpf samples: Add utils.[ch] for using BPF
On 2015/12/18 14:19, Alexei Starovoitov wrote:
On Fri, Dec 18, 2015 at 09:47:11AM +0800, Wangnan (F) wrote:
This is a limitation in tools/lib/bpf/libbpf.h, which has a #include
in its header.
libbpf.h requires this include because its API uses ERR_PTR() to encode
error code.
For example, when calling bpf_object__open(), caller should use IS_ERR() to
check its
return value instead of compare with NULL, and use PTR_ERR() to retrive
error number.
However, linux/err.h is not a part of uapi. To make libbpf work, one has to
create its
own err.h.
Why tools/include/linux/err.h is not suitable for everyone?
Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(), in libbpf itself.
seems odd. we already have user space err.h in tools/include.
Currently samples/bpf doesn't have an -I$(srctree)/tools/include.
I tried to add it into CFLAGS of samples/bpf. It causes other problems,
This is what I get:
In file included from
/home/w00229757/kernel-hydrogen/samples/bpf/sock_example.c:27:0:
/usr/include/linux/ip.h:101:2: error: unknown type name ‘__sum16’
__sum16 check;
^
make[3]: *** [samples/bpf/sock_example.o] Error 1
make[2]: *** [samples/bpf/] Error 2
make[1]: *** [sub-make] Error 2
make: *** [__sub-make] Error 2
And after fixing __sum16 in linux/types.h:
HOSTCC samples/bpf/tracex4_user.o
HOSTLD samples/bpf/tracex4
HOSTCC samples/bpf/tracex5_user.o
/kernel/samples/bpf/tracex5_user.c: In function
‘install_accept_all_seccomp’:
/kernel/samples/bpf/tracex5_user.c:15:21: error: array type has
incomplete element type
struct sock_filter filter[] = {
^
/kernel/samples/bpf/tracex5_user.c:16:3: warning: implicit declaration
of function ‘BPF_STMT’ [-Wimplicit-function-declaration]
BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW),
^
/kernel/samples/bpf/tracex5_user.c:18:9: error: variable ‘prog’ has
initializer but incomplete type
struct sock_fprog prog = {
^
Finally we need to add sock_filter, sock_fprog, BPF_STMT into
tools/include/linux/filter.h.
It is okay, but different from what I really want to do. I'll discuss
this later.
And I don't touch the setsockopt in all patches.
ok, but where is the bit that does attach to perf_event to make trace_output
work?
I didn't change this test_bpf_perf_event() function (only the function
name).
It creates a bpf-output perf event. This event is inserted into a
BPF_MAP_TYPE_PERF_EVENT_ARRAY by bpf_map_update_elem().
static void test_bpf_perf_event(int map_fd)
{
struct perf_event_attr attr = {
.sample_type = PERF_SAMPLE_RAW,
.type = PERF_TYPE_SOFTWARE,
.config = PERF_COUNT_SW_BPF_OUTPUT,
};
int key = 0;
pmu_fd = perf_event_open(, -1/*pid*/, 0/*cpu*/,
-1/*group_fd*/, 0);
assert(pmu_fd >= 0);
assert(bpf_map_update_elem(map_fd, , _fd, BPF_ANY) == 0);
ioctl(pmu_fd, PERF_EVENT_IOC_ENABLE, 0);
}
And you read from this pmu_fd, get results. The logical is unchanged.
Orignally they are macros defined in linux/filter.h.
no. they were never part of offical filter.h. Only in my earlier versions
of bpf patches, but we decided to drop them before they got into net-next.
What about moving them into include/uapi/linux/filter.h ? Then
normal user programs like those in samples/bpf can access
them easier.
we don't want to add these macros to uapi.
Why not to add it to
tools/include/linux/filter.h
instead?
What I want to do in this patchset is not only removing original libbpf.c
and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
available library for other userspace tools (tc for example). Switching
samples/bpf into libbpf is the first step of this goal. From doing this
I found and fixed some limitation, like those missed BPF map operations.
Making libbpf.h and bpf.h available for normal userspace programs is also
important.
Having the above goal, I think you can understand why improving
tools/include
is not a good idea. You don't want to force a normal userspace program setup
a similar header environment for using libbpf. It is relatively a small
library. So it would be good if bpf.h and libbpf.h only depend on what can
be found in uapi.
Thank you.
--
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] megaraid:Make various functions static in megaraid_sas_fusion.c
> -Original Message- > From: Nicholas Krause [mailto:xerofo...@gmail.com] > Sent: Monday, July 06, 2015 10:06 PM > To: kashyap.de...@avagotech.com > Cc: sumit.sax...@avagotech.com; uday.ling...@avagotech.com; > jbottom...@odin.com; megaraidlinux@avagotech.com; linux- > s...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [PATCH] megaraid:Make various functions static in > megaraid_sas_fusion.c > > This makes various functions that have no external callers outside of their > definition/declaration in the file megaraid_sas_fusion.c to be properly > declared as static functions now. > > Signed-off-by: Nicholas Krause Nicholas - You posted patch with subject line "megaraid:Make the function megasas_alloc_cmd_fusion static" for similar code changes. Let's have consolidated patch for this and Avago can post it with next change set (to keep git commit clean without any failure) Just to be clear - You can send us patch and we can add with Submitted by your name as signature. For now NACK. ` Kashyap -- 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] mm: Introduce kernelcore=mirror option
>Hmm...like this ? > sysctl.vm.fallback_mirror_memory = 0 // never fallback # default. > sysctl.vm.fallback_mirror_memory = 1 // the user memory may be > allocated from mirrored zone. > sysctl.vm.fallback_mirror_memory = 2 // usually kernel allocates > memory from mirrored zone before OOM. > sysctl.vm.fallback_mirror_memory = 3 // 1+2 Should option 2 say: // allow kernel to allocate from non-mirror zone to avoid OOM > However I believe my customer's choice is always 0, above implementation can > be done in a clean way. > (adding a flag to zones (mirrored or not) and controlling fallback zonelist > walk.) Modes allow us to make all of the people happy (I hope). > BTW, we need this Taku's patch to make a progress. I think other devs should > be done in another > development cycle. What does he need to get your Acks ? The concept is great. It's even "Tested-by: Tony Luck ". I need to read the code more carefully before Acked-by. -Tony -- 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] megaraid:Make the function megasas_alloc_cmd_fusion static
> -int
> +static int
> megasas_alloc_cmds_fusion(struct megasas_instance *instance) {
> int i, j, count;
Good catch. Let's not include patch to avoid further confusion on series
of acked patch which are not making significant functional difference.
NACK as not making any functional difference. We can make many more such
changes in one shot and let's address those later as we have few patches
ready to send in few days.
> --
> 2.5.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: linux-next: rebase of the drm-panel tree
On Fri, Dec 18, 2015 at 09:17:29AM +1100, Stephen Rothwell wrote: > Hi Thierry, > > I noticed that you have rebased the drm-panel tree today. Unfortunately, > Dave merged the previous version of your tree :-( And I had hoped to have been fast enough. Sorry for the mess. > So, now in linux-next today, we are going to have 2 copies of all theose > patches, plus at least 2 of the patches have beenm changed in you new > version so there will probably be conflicts. Yes, there were two changes (in two patches) which moved device tree bindings from a deprecated location to the new one. > Please either go back to the old version, or just rebase what you have > now on top of Dave's drm tree. I'll revert to the old version and apply the changes as a separate patch on top. Again, sorry for the inconvenience. Thierry signature.asc Description: PGP signature
Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
On December 17, 2015 9:29:21 PM PST, Andy Lutomirski wrote: >On Dec 17, 2015 6:53 PM, "Dave Hansen" >wrote: >> >> On 12/17/2015 06:32 PM, Andy Lutomirski wrote: >> > On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen > wrote: >> >> But what about the register state when delivering a signal? Don't >we >> >> set the registers to the init state? Do we need to preserve PKRU >state >> >> instead of init'ing it? The init state _is_ nice here because it >is >> >> permissive allows us to do something useful no matter what PKRU >gets set to. >> > >> > I think we leave the extended regs alone. Don't we? >> > >> > I think that, for most signals, we want to leave PKRU as is, >> > especially for things that aren't SIGSEGV. For SIGSEGV, maybe we >want >> > an option to reset PKRU on delivery (and then set the flag to >restore >> > on return?). >> >> Is there some precedent for doing the state differently for different >> signals? > >Yes, to a very limited extent: SA_ONSTACK. > >> >> >> Well, the signal handler isn't necessarily going to clobber it, >but the >> >> delivery code already clobbers it when going to the init state. >> > >> > Can you point to that code? >> >> handle_signal() -> fpu__clear() >> >> The comment around it says: >> >> "Ensure the signal handler starts with the new fpu state." >> > >You win this round :) > >So maybe we should have a mask of xfeatures that aren't cleared on >signal delivery (e.g. PKRU, perhaps) and that are, by default, >preserved across signal returns. > >> >>> We have _fpx_sw_bytes.xfeatures and _xstate._header.xfeatures. >They >> >>> appear to do more or less the same thing. >> >> >> >> I thought the _fpx_sw_bytes were only for 32-bit (or >FXSAVE/FXRSTOR?). >> > >> > I thought they were everywhere. fpu/signal.c looks that way to me. > I >> > could be missing something -- this code isn't the most >straightforward >> > in the world. >> >> I think there's some extra space on the ia32 frame for this stuff, >but >> some clarity from someone who knows the history would be appreciated. >> >> >> Not a huge deal, but something we want to think about, especially >as it >> >> pertains to the init/modified optimizations. >> > >> > Fair point. FWIW, I don't think that sigreturn performance matters >> > all that much, so if we inadvertently lose some of the >optimizations, >> > it may not be the end of the world. >> >> Once we lose the init optimization, we're sunk for good. We never >get >> it back until we restore the init state again. Having it in the init >> state can save writing the state at XSAVE time, which can now save up >to >> ~2k of writes at each context switch. >> >> I'm sure we can preserve it, we just need to be _careful_. > >Right. > >How much does XSAVEOPT help here? IOW if we're careful to save to the >same place we restored from and we don't modify the state in the mean >time, how much of the time do we save? In the best case, I guess we >save the memory writes but not the reads? > >--Andy I find the notion of PKRU not being initialized at the entry to a signal handler a bit odd. Saving/restoring it seems like the right thing to me. What am I missing? -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting. -- 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] HID: Use multitouch driver for Type Covers
> The search, share, connect(?), and settings keys I tested the patch again with xev and found that those "charm" keys don't respond both on hid-microsoft and hid-multitouch, while other keys respond. I'll have a further look. Anyway, keys working with hid-microsoft also work with hid-multitouch, so It's ready for merging, I think. On 12/15/2015 01:39 AM, Donavan Lance wrote: > On Mon, Dec 14, 2015 at 8:22 AM, Bastien Nocera > wrote: >> On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote: >>> Use multitouch driver instead of microsoft one for Microsoft >>> Surface Type Covers. >>> >>> By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as >>> well as the multitouch pads do. >> >> I've discussed this a couple of weeks back with Benjamin >> Tissoires, and this patch would break the special keys (mute, >> brightness up/down, keyboard backlight up/down and play/pause). >> >> The recommended way to fix this was to move multi-touch >> processing into the Microsoft driver, so that it would handle the >> trackpad's multi- touch events. >> >> You should be able to do this by carefully picking up the >> handling code from hid-multitouch, or do something similar to >> what's done in hid- wacom, which has the same problem as the Type >> Cover handling. >> >> Can you confirm that this does indeed break those special keys? >> If it does, it's a NAK from my side. > > For what it's worth the special keys on my keyboard work fine when > using this patch. I'm using a Surface Pro 3, Type Cover 3, running > GNOME and Fedora 23. The search, share, connect(?), and settings > keys are the only ones not mapped to anything out of the box, but > they are recognized by xev. > -- 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/
rhashtable: Kill harmless RCU warning in rhashtable_walk_init
On Fri, Dec 18, 2015 at 01:34:16PM +0800, Herbert Xu wrote:
> On Fri, Dec 18, 2015 at 09:39:22AM +0800, kernel test robot wrote:
> > FYI, we noticed the below changes on
> >
> > https://github.com/0day-ci/linux
> > Herbert-Xu/rhashtable-Fix-walker-list-corruption/20151216-164833
> > commit f9f51b8070be3e829100614a7372b219723b864f ("rhashtable: Fix walker
> > list corruption")
> >
> > [8.933376] ===
> > [8.933376] ===
> > [8.934629] [ INFO: suspicious RCU usage. ]
> > [8.934629] [ INFO: suspicious RCU usage. ]
> > [8.935941] 4.4.0-rc3-00995-gf9f51b8 #2 Not tainted
> > [8.935941] 4.4.0-rc3-00995-gf9f51b8 #2 Not tainted
> > [8.937494] ---
> > [8.937494] ---
> > [8.938818] lib/rhashtable.c:504 suspicious rcu_dereference_protected()
> > usage!
> > [8.938818] lib/rhashtable.c:504 suspicious rcu_dereference_protected()
> > usage!
>
> This is actually a false positive because the new spin lock that
> we hold prevents ht->tbl from disappearing under us. So here is
> a patch to kill the warning with a comment.
Resent with a proper patch subject and reported-by.
---8<---
The commit f9f51b8070be3e829100614a7372b219723b864f ("rhashtable:
Fix walker list corruption") causes a suspicious RCU usage warning
because we no longer hold ht->mutex when we dereference ht->tbl.
However, this is a false positive because we now hold ht->lock
which also guarantees that ht->tbl won't disppear from under us.
This patch kills the warning by using rcu_dereference_raw and
adding a comment.
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index eb9240c..3404b06 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -519,7 +519,11 @@ int rhashtable_walk_init(struct rhashtable *ht, struct
rhashtable_iter *iter)
return -ENOMEM;
spin_lock(>lock);
- iter->walker->tbl = rht_dereference(ht->tbl, ht);
+ /* We do not need RCU protection because we hold ht->lock
+* which guarantees that if we see ht->tbl then it won't
+* die on us.
+*/
+ iter->walker->tbl = rcu_dereference_raw(ht->tbl);
list_add(>walker->list, >walker->tbl->walkers);
spin_unlock(>lock);
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 4/6] bpf: hash: convert per-hashtable lock into per-bucket bit spinlock
On Wed, Dec 16, 2015 at 02:58:08PM +0800, Ming Lei wrote: > On Wed, Dec 16, 2015 at 1:01 PM, Yang Shi wrote: > > > > > I recalled Steven confirmed raw_spin_lock has the lockdep benefit too in the > > patch review for changing to raw lock. > > > > Please check this thread out > > http://lists.openwall.net/netdev/2015/10/31/7 > > OK, looks I was wrong about the lockdep benifit, :-( > > But for this lock, I think lockdep isn't such important, because it is the > intermost lock, and it can be used just for protecting the bucket list > and nothing else need to be covered. I still think that overhead of normal spinlock per bucket is acceptable. Makes the whole thing much easier to read. -- 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 08/10] bpf samples: Add utils.[ch] for using BPF
On Fri, Dec 18, 2015 at 09:47:11AM +0800, Wangnan (F) wrote:
>
> This is a limitation in tools/lib/bpf/libbpf.h, which has a #include
>
> in its header.
>
> libbpf.h requires this include because its API uses ERR_PTR() to encode
> error code.
> For example, when calling bpf_object__open(), caller should use IS_ERR() to
> check its
> return value instead of compare with NULL, and use PTR_ERR() to retrive
> error number.
>
> However, linux/err.h is not a part of uapi. To make libbpf work, one has to
> create its
> own err.h.
Why tools/include/linux/err.h is not suitable for everyone?
> Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(), in libbpf itself.
seems odd. we already have user space err.h in tools/include.
> And I don't touch the setsockopt in all patches.
ok, but where is the bit that does attach to perf_event to make trace_output
work?
> Orignally they are macros defined in linux/filter.h.
no. they were never part of offical filter.h. Only in my earlier versions
of bpf patches, but we decided to drop them before they got into net-next.
> What about moving them into include/uapi/linux/filter.h ? Then
> normal user programs like those in samples/bpf can access
> them easier.
we don't want to add these macros to uapi.
Why not to add it to
tools/include/linux/filter.h
instead?
--
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 pinctrl tree
Hi Stephen, The issue I pointed out is the relevant and is fully related to the statement- " After merging the pinctrl tree, today's linux-next build (arm multi_v7_defconfig) failed like this:" Even I tried the build for config "arm multi_v7_defconfig" it was compile failed. After fixing this I see compilation successful. I don't think we see any more issue after this fix. Please let me know in case I should try any more compilation. Regards, Pramod > -Original Message- > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > Sent: 18 December 2015 11:28 > To: Pramod Kumar > Cc: Linus Walleij; linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; > Ray > Jui; Scott Branden > Subject: Re: linux-next: build failure after merge of the pinctrl tree > > Hi Pramod, > > On Fri, 18 Dec 2015 05:34:58 + Pramod Kumar > wrote: > > > > Hi Stephen/Linus, > > > > Please suggest us how could we fix this issue. > > I think you issue is different from what I reported, What I reported was > caused > by the addition of the dependency on COMPILE_TEST which allowed the driver > to be built on architectures/platforms that do not have the needed > definitions. > > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dma-mapping: Just allocate one chunk at a time
On Fri, Dec 18, 2015 at 7:31 AM, Doug Anderson wrote: > Hi, > > On Thu, Dec 17, 2015 at 12:30 PM, Douglas Anderson > wrote: >> The __iommu_alloc_buffer() is expected to be called to allocate pretty >> sizeable buffers. Upon simple tests of video I saw it trying to >> allocate 4,194,304 bytes. The function tries to be efficient about this >> by starting out allocating large chunks and then moving to smaller and >> smaller chunk sizes until it succeeds. >> >> The current function is very, very slow. >> >> One problem is the way it keeps trying and trying to allocate big >> chunks. Imagine a very fragmented memory that has 4M free but no >> contiguous pages at all. Further imagine allocating 4M (1024 pages). >> We'll do the following memory allocations: >> - For page 1: >> - Try to allocate order 10 (no retry) >> - Try to allocate order 9 (no retry) >> - ... >> - Try to allocate order 0 (with retry, but not needed) >> - For page 2: >> - Try to allocate order 9 (no retry) >> - Try to allocate order 8 (no retry) >> - ... >> - Try to allocate order 0 (with retry, but not needed) >> - ... >> - ... >> >> Total number of calls to alloc() calls for this case is: >> sum(int(math.log(i, 2)) + 1 for i in range(1, 1025)) >> => 9228 >> >> The above is obviously worse case, but given how slow alloc can be we >> really want to try to avoid even somewhat bad cases. I timed the old >> code with a device under memory pressure and it wasn't hard to see it >> take more than 24 seconds to allocate 4 megs of memory (!!). >> >> A second problem (and maybe even more important) is that allocating big >> chunks when we don't need them is just not a good idea anyway. The >> first thing we do with these big chunks is break them into smaller >> chunks! If we allocate small chunks: >> - The memory manager doesn't need to work so hard to give us big chunks. >> - We can save the big chunks for those that really need them and this >> code can make great use of all the small chunks sitting around. >> >> Let's simplify by just allocating one page at a time. We may make more >> total allocate calls but it works way better. In real world tests that >> used to sometimes see a 24 second allocation call I can now see at most >> 250 ms. > > Off-list I talked to Dmitry about this a little bit and he pointed out > that contiguous chunks actually give a benefit to the IOMMU. I don't > think the benefit outweighs the cost in this case, but I'm happy to > hear what others have to say. Yeah, I'd like to see some discussion about the effect of allocating bigger chunks on IOMMU performance. Dmitry (on CC), could you elaborate a bit on what Doug mentioned? As for my own understanding, some IOMMUs can map memory using big pages, which should improve TLB efficiency and so look-up speed. However AFAICT current implementation of allocating function doesn't allocate the chunks properly, because there is no guarantee that particular chunks are aligned on big page boundary. For example, it might happen that we allocate first chunk of order 0, then second chunk of order 4 (64KiB - typical big page), then we won't be able to map the second chunk using a big page, because the IOVA at that point will not be aligned properly. Is there any other case when bigger physically contiguous chunks can help the IOMMU? Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: uniphier: select PINCTRL
Please let me gently ping in case the maintainers might be away from keyboard during the Christmas days. I want this trivial one for the next merge window. Thanks! 2015-11-05 15:47 GMT+09:00 Masahiro Yamada : > The UniPhier SoCs support pinctrl drivers. > > Signed-off-by: Masahiro Yamada > --- > > arch/arm/mach-uniphier/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig > index b640458..82dddee 100644 > --- a/arch/arm/mach-uniphier/Kconfig > +++ b/arch/arm/mach-uniphier/Kconfig > @@ -6,6 +6,7 @@ config ARCH_UNIPHIER > select ARM_GIC > select HAVE_ARM_SCU > select HAVE_ARM_TWD if SMP > + select PINCTRL > help > Support for UniPhier SoC family developed by Socionext Inc. > (formerly, System LSI Business Division of Panasonic Corporation) > -- -- Best Regards Masahiro Yamada -- 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: [RESEND][PATCH v2] dmaengine: bcm2835: Add slave dma support
On Thu, Dec 17, 2015 at 07:11:48PM +0100, Martin Sperl wrote:
> +
> + /* Setup addresses */
> + if (d->dir == DMA_DEV_TO_MEM) {
> + control_block->info = BCM2835_DMA_D_INC |
> + BCM2835_DMA_D_WIDTH |
> + BCM2835_DMA_S_DREQ;
> + control_block->src = dev_addr;
> + control_block->dst = addr + (dma_addr_t)j;
> + } else {
> + control_block->info = BCM2835_DMA_S_INC |
> + BCM2835_DMA_S_WIDTH |
> + BCM2835_DMA_D_DREQ;
> + control_block->src = addr + (dma_addr_t)j;
> + control_block->dst = dev_addr;
> + }
> +
> + /* Common part */
> + control_block->info |=
> + BCM2835_DMA_WAITS(BCM2835_DMA_WAIT_CYCLES);
> + control_block->info |= BCM2835_DMA_WAIT_RESP;
> +
> + /* Enable */
> + if (i == sg_len - 1 && len - j <= max_size)
> + control_block->info |= BCM2835_DMA_INT_EN;
> +
> + /* Setup synchronization */
> + if (sync_type)
> + control_block->info |= sync_type;
> +
> + /* Setup DREQ channel */
> + if (c->dreq)
> + control_block->info |=
> + BCM2835_DMA_PER_MAP(c->dreq);
> +
> + /* Length of a frame */
> + control_block->length = min(len - j, max_size);
> + d->size += control_block->length;
> +
> + if (i < sg_len - 1 || len - j > max_size) {
> + /* Next block is the next frame. */
> + control_block->next =
> + d->control_block_base_phys +
> + sizeof(struct bcm2835_dma_cb) *
> + (i + split_cnt + 1);
> + } else {
> + /* Next block is empty. */
> + control_block->next = 0;
> + }
> +
> + if (len - j > max_size)
> + split_cnt++;
Most of this part is common with the cyclic and seems copy paste. Can we
use common routine to do common work please
--
~Vinod
--
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 pinctrl tree
Hi Pramod, On Fri, 18 Dec 2015 05:34:58 + Pramod Kumar wrote: > > Hi Stephen/Linus, > > Please suggest us how could we fix this issue. I think you issue is different from what I reported, What I reported was caused by the addition of the dependency on COMPILE_TEST which allowed the driver to be built on architectures/platforms that do not have the needed definitions. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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 3/3] powercap, intel_rapl, Add ignore_max_window_check module parameter for broken BIOSes
On 2015-12-15 22:02, Prarit Bhargava wrote: > Some systems erroneously set the maximum time window field of > MSR_PKG_POWER_INFO register to 0. This results in a user not being able > to set the time windows for the package. In some cases, however, RAPL > will still continue to work with a small window (albeit through some > trial and error). This patch adds a ignore_max_window_check module > parameter to avoid the maximum time window check in set_time_window(). > > Cc: "Rafael J. Wysocki" > Cc: Prarit Bhargava > Cc: Radivoje Jovanovic > Cc: Seiichi Ikarashi > Cc: Mathias Krause > Cc: Ajay Thomas > Signed-off-by: Prarit Bhargava > --- > drivers/powercap/intel_rapl.c | 15 ++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c > index 14753e5..3cdb8ee 100644 > --- a/drivers/powercap/intel_rapl.c > +++ b/drivers/powercap/intel_rapl.c > @@ -508,10 +508,22 @@ static int get_max_time_window(struct powercap_zone > *power_zone, int id, > else > *data = val; > > + if (val == 0) If rapl_read_data_raw() fails, "val" becomes indefinite. So this check and warn should be performed only if rapl_read_data_raw() succeeds. > + pr_warn_once(FW_BUG "intel_rapl: Maximum Time Window is zero. > This is a BIOS bug that should be reported to your hardware or BIOS vendor. > The value of zero may prevent Intel RAPL from functioning properly. Most > bugs can be avoided by setting the ignore_max_window_check module > parameter.\n"); > + > put_online_cpus(); > return ret; > } > > +/* Some BIOSes incorrectly program the maximum time window in the > + * MSR_PKG_POWER_INFO register. Some of these systems still have functional > + * RAPL registers, etc., so give the user the option of disabling the maximum > + * time window check. > + */ > +static int ignore_max_window_check; > +module_param(ignore_max_window_check, int, 0444); > +MODULE_PARM_DESC(ignore_max_window_check, "Ignore maximum window check. A > bug should be reported to your hardware or BIOS vendor if this parameter is > used."); Don't you need to use "time_window" instead of just "window" in these names? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: DRA7: add entry for qspi mmap region
On 12/18/2015 12:15 AM, Tony Lindgren wrote: > * Rob Herring [151211 07:10]: >> On Fri, Dec 11, 2015 at 09:39:59AM +0530, Vignesh R wrote: >>> Add qspi memory mapped region entries for DRA7xx based SoCs. Also, >>> update the binding documents for the controller to document this change. >>> >>> Signed-off-by: Vignesh R >> >> Acked-by: Rob Herring > > Vignes, are patches 4 and 5 safe to apply separately already or > do things break if we do that? Yes, 4 and 5 can be applied separately w/o driver changes. -- Regards Vignesh -- 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] tools build: Add BPF feature check to test-all
Existing test-all.c doesn't check BPF related features. For environment
with all other features enabled, BPF would be considered enabled
without doing real feature check.
This patch adds test-bpf.c into test-all.c.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Namhyung Kim
Cc: Jiri Olsa
---
tools/build/feature/test-all.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/build/feature/test-all.c b/tools/build/feature/test-all.c
index 33cf6f2..81025ca 100644
--- a/tools/build/feature/test-all.c
+++ b/tools/build/feature/test-all.c
@@ -125,6 +125,10 @@
# include "test-get_cpuid.c"
#undef main
+#define main main_test_bpf
+# include "test-bpf.c"
+#undef main
+
int main(int argc, char *argv[])
{
main_test_libpython();
@@ -153,6 +157,7 @@ int main(int argc, char *argv[])
main_test_pthread_attr_setaffinity_np();
main_test_lzma();
main_test_get_cpuid();
+ main_test_bpf();
return 0;
}
--
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/
Re: [PATCH V03 0/5] dmaengine: New 'universal' API for requesting channel
On Mon, Dec 14, 2015 at 10:47:37PM +0200, Peter Ujfalusi wrote: > Hi, > > As it has been discussed in the following thread: > http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487 > > With this series I have taken a path which would result two new API, which can > be used to convert most of the current users already and with some work all > users might be able to move to this set. > With this set the filter_fn used for legacy (non DT/ACPI) channel request is > no > longer needed to be exported to client drivers since the selection of the > correct filter_fn will be done in the core. Applied now, Thanks for this rework, much appreciated :-) -- ~Vinod -- 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] dmaengine: mdc: Correct terminate_all handling
On Thu, Dec 10, 2015 at 03:07:23PM +, Damien Horsley wrote: > From: "Damien.Horsley" > > Use of the CANCEL bit in mdc_terminate_all creates an > additional 'command done' to appear in the registers (in > addition to an interrupt). > > In addition, there is a potential race between > mdc_terminate_all and the irq handler if a transfer > completes at the same time as the terminate all (presently > this results in an inappropriate warning). > > To handle these issues, any outstanding 'command done' > events are cleared during mdc_terminate_all and the irq > handler takes no action when there are no new 'command done' > events. Applied, thanks -- ~Vinod -- 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 pinctrl tree
Hi Stephen/Linus,
The patch " [PATCH v2 5/7] gpio: Rename func/macro/var to IP-block,iproc"
(https://lkml.org/lkml/2015/11/18/1004) in "for-next" and "devel" of pinctrl
tree ( http://git.linaro.org/people/linus.walleij/linux-pinctrl.git ) has
little rebase issue.
Original patch has:
-static void cygnus_gpio_unregister_pinconf(struct cygnus_gpio *chip)
+static void iproc_gpio_unregister_pinconf(struct iproc_gpio *chip)
while "for-next" and "devel" branch of pinctrl tree has:
-static void cygnus_gpio_unregister_pinconf(struct cygnus_gpio *chip)
+static void iproc_gpio_unregister_pinconf(struct cygnus_gpio *chip)
Please suggest us how could we fix this issue.
Regards,
Pramod
> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: 18 December 2015 09:15
> To: Linus Walleij
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Pramod Kumar;
> Ray Jui; Scott Branden
> Subject: linux-next: build failure after merge of the pinctrl tree
>
> Hi Linus,
>
> After merging the pinctrl tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/pinctrl/bcm/pinctrl-iproc-gpio.c: In function
> 'iproc_gpio_unregister_pinconf':
> drivers/pinctrl/bcm/pinctrl-iproc-gpio.c:642:25: error: dereferencing pointer
> to
> incomplete type 'struct cygnus_gpio'
> pinctrl_unregister(chip->pctl);
> ^
> drivers/pinctrl/bcm/pinctrl-iproc-gpio.c: In function 'iproc_gpio_probe':
> drivers/pinctrl/bcm/pinctrl-iproc-gpio.c:738:32: warning: passing argument 1
> of
> 'iproc_gpio_unregister_pinconf' from incompatible pointer type [-
> Wincompatible-pointer-types]
> iproc_gpio_unregister_pinconf(chip);
> ^
> drivers/pinctrl/bcm/pinctrl-iproc-gpio.c:640:13: note: expected 'struct
> cygnus_gpio *' but argument is of type 'struct iproc_gpio *'
> static void iproc_gpio_unregister_pinconf(struct cygnus_gpio *chip)
> ^
>
> Caused by commit
>
> 616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
>
> I have used the pinctrl tree from next-20151217 for today.
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
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: [lkp] [rhashtable] f9f51b8070: INFO: suspicious RCU usage. ]
On Fri, Dec 18, 2015 at 09:39:22AM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
>
> https://github.com/0day-ci/linux
> Herbert-Xu/rhashtable-Fix-walker-list-corruption/20151216-164833
> commit f9f51b8070be3e829100614a7372b219723b864f ("rhashtable: Fix walker list
> corruption")
>
>
> [8.933376] ===
> [8.933376] ===
> [8.934629] [ INFO: suspicious RCU usage. ]
> [8.934629] [ INFO: suspicious RCU usage. ]
> [8.935941] 4.4.0-rc3-00995-gf9f51b8 #2 Not tainted
> [8.935941] 4.4.0-rc3-00995-gf9f51b8 #2 Not tainted
> [8.937494] ---
> [8.937494] ---
> [8.938818] lib/rhashtable.c:504 suspicious rcu_dereference_protected()
> usage!
> [8.938818] lib/rhashtable.c:504 suspicious rcu_dereference_protected()
> usage!
This is actually a false positive because the new spin lock that
we hold prevents ht->tbl from disappearing under us. So here is
a patch to kill the warning with a comment.
---8<---
The commit f9f51b8070be3e829100614a7372b219723b864f ("rhashtable:
Fix walker list corruption") causes a suspicious RCU usage warning
because we no longer hold ht->mutex when we dereference ht->tbl.
However, this is a false positive because we now hold ht->lock
which also guarantees that ht->tbl won't disppear from under us.
This patch kills the warning by using rcu_dereference_raw and
adding a comment.
Signed-off-by: Herbert Xu
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index eb9240c..3404b06 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -519,7 +519,11 @@ int rhashtable_walk_init(struct rhashtable *ht, struct
rhashtable_iter *iter)
return -ENOMEM;
spin_lock(>lock);
- iter->walker->tbl = rht_dereference(ht->tbl, ht);
+ /* We do not need RCU protection because we hold ht->lock
+* which guarantees that if we see ht->tbl then it won't
+* die on us.
+*/
+ iter->walker->tbl = rcu_dereference_raw(ht->tbl);
list_add(>walker->list, >walker->tbl->walkers);
spin_unlock(>lock);
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/
linux-next: manual merge of the akpm-current tree with the powerpc tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/include/asm/pgtable.h
between commit:
ee4889c7bc2a ("powerpc/mm: Don't have generic headers introduce functions
touching pte bits")
from the powerpc tree and commit:
e0e8474c0d55 ("mm, dax, gpu: convert vm_insert_mixed to pfn_t")
from the akpm-current tree.
I fixed it up (the code being changed was moved from this file - I added
the fix up patch below) and can carry the fix as necessary (no action
is required).
From: Stephen Rothwell
Date: Fri, 18 Dec 2015 16:30:47 +1100
Subject: [PATCH] mm, dax, gpu: merge fix for convert vm_insert_mixed to pfn_t
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 1 +
arch/powerpc/include/asm/book3s/64/hash.h| 1 +
arch/powerpc/include/asm/nohash/pgtable.h| 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
b/arch/powerpc/include/asm/book3s/32/pgtable.h
index 38b33dcfcc9d..3ed3303c1295 100644
--- a/arch/powerpc/include/asm/book3s/32/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
@@ -313,6 +313,7 @@ static inline int pte_present(pte_t pte)
* Even if PTEs can be unsigned long long, a PFN is always an unsigned
* long for now.
*/
+#define pfn_pte pfn_pte
static inline pte_t pfn_pte(unsigned long pfn, pgprot_t pgprot)
{
return __pte(((pte_basic_t)(pfn) << PTE_RPN_SHIFT) |
diff --git a/arch/powerpc/include/asm/book3s/64/hash.h
b/arch/powerpc/include/asm/book3s/64/hash.h
index 9e861b4378bd..6ab967d0da00 100644
--- a/arch/powerpc/include/asm/book3s/64/hash.h
+++ b/arch/powerpc/include/asm/book3s/64/hash.h
@@ -410,6 +410,7 @@ static inline int pte_present(pte_t pte)
* Even if PTEs can be unsigned long long, a PFN is always an unsigned
* long for now.
*/
+#define pfn_pte pfn_pte
static inline pte_t pfn_pte(unsigned long pfn, pgprot_t pgprot)
{
return __pte(((pte_basic_t)(pfn) << PTE_RPN_SHIFT) |
diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
b/arch/powerpc/include/asm/nohash/pgtable.h
index 1263c22d60d8..11e3767216c0 100644
--- a/arch/powerpc/include/asm/nohash/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/pgtable.h
@@ -49,6 +49,7 @@ static inline int pte_present(pte_t pte)
* Even if PTEs can be unsigned long long, a PFN is always an unsigned
* long for now.
*/
+#define pfn_pte pfn_pte
static inline pte_t pfn_pte(unsigned long pfn, pgprot_t pgprot) {
return __pte(((pte_basic_t)(pfn) << PTE_RPN_SHIFT) |
pgprot_val(pgprot)); }
--
2.6.2
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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] dmaengine: edma: Add probe callback to edma_tptc_driver
On Wed, Dec 16, 2015 at 03:19:05PM +0200, Peter Ujfalusi wrote: > Due to changes in device and platform code drivers w/o probe will fail to > load. This means that the devices for eDMA TPTCs are goign to be without > driver and omap hwmod code will turn them off after the kernel finished > loading: > [3.015900] platform 4980.tptc: omap_device_late_idle: enabled but no > driver. Idling > [3.024671] platform 49a0.tptc: omap_device_late_idle: enabled but no > driver. Idling > > This will prevent eDMA to work since the TPTCs are not enabled. Applied, thanks -- ~Vinod -- 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: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
On Dec 17, 2015 6:53 PM, "Dave Hansen" wrote: > > On 12/17/2015 06:32 PM, Andy Lutomirski wrote: > > On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen > > wrote: > >> But what about the register state when delivering a signal? Don't we > >> set the registers to the init state? Do we need to preserve PKRU state > >> instead of init'ing it? The init state _is_ nice here because it is > >> permissive allows us to do something useful no matter what PKRU gets set > >> to. > > > > I think we leave the extended regs alone. Don't we? > > > > I think that, for most signals, we want to leave PKRU as is, > > especially for things that aren't SIGSEGV. For SIGSEGV, maybe we want > > an option to reset PKRU on delivery (and then set the flag to restore > > on return?). > > Is there some precedent for doing the state differently for different > signals? Yes, to a very limited extent: SA_ONSTACK. > > >> Well, the signal handler isn't necessarily going to clobber it, but the > >> delivery code already clobbers it when going to the init state. > > > > Can you point to that code? > > handle_signal() -> fpu__clear() > > The comment around it says: > > "Ensure the signal handler starts with the new fpu state." > You win this round :) So maybe we should have a mask of xfeatures that aren't cleared on signal delivery (e.g. PKRU, perhaps) and that are, by default, preserved across signal returns. > >>> We have _fpx_sw_bytes.xfeatures and _xstate._header.xfeatures. They > >>> appear to do more or less the same thing. > >> > >> I thought the _fpx_sw_bytes were only for 32-bit (or FXSAVE/FXRSTOR?). > > > > I thought they were everywhere. fpu/signal.c looks that way to me. I > > could be missing something -- this code isn't the most straightforward > > in the world. > > I think there's some extra space on the ia32 frame for this stuff, but > some clarity from someone who knows the history would be appreciated. > > >> Not a huge deal, but something we want to think about, especially as it > >> pertains to the init/modified optimizations. > > > > Fair point. FWIW, I don't think that sigreturn performance matters > > all that much, so if we inadvertently lose some of the optimizations, > > it may not be the end of the world. > > Once we lose the init optimization, we're sunk for good. We never get > it back until we restore the init state again. Having it in the init > state can save writing the state at XSAVE time, which can now save up to > ~2k of writes at each context switch. > > I'm sure we can preserve it, we just need to be _careful_. Right. How much does XSAVEOPT help here? IOW if we're careful to save to the same place we restored from and we don't modify the state in the mean time, how much of the time do we save? In the best case, I guess we save the memory writes but not the reads? --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/
linux-next: manual merge of the akpm-current tree with the kvm tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/x86/kvm/mmu.c
between commits:
7ee0e5b29d27 ("KVM: x86: MMU: Remove unused parameter of __direct_map()")
029499b47738 ("KVM: x86: MMU: Make mmu_set_spte() return emulate value")
from the kvm tree and commit:
7fd3f3e7c320 ("kvm: rename pfn_t to kvm_pfn_t")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/kvm/mmu.c
index a1a3d1907fdc,2dd83650d867..
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@@ -2546,9 -2564,10 +2546,9 @@@ done
return ret;
}
-static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
- unsigned pte_access, int write_fault, int *emulate,
- int level, gfn_t gfn, kvm_pfn_t pfn, bool speculative,
- bool host_writable)
+static bool mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep, unsigned
pte_access,
-int write_fault, int level, gfn_t gfn, pfn_t pfn,
++ int write_fault, int level, gfn_t gfn, kvm_pfn_t pfn,
+ bool speculative, bool host_writable)
{
int was_rmapped = 0;
int rmap_count;
@@@ -2606,11 -2624,9 +2606,11 @@@
}
kvm_release_pfn_clean(pfn);
+
+ return emulate;
}
- static pfn_t pte_prefetch_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn,
+ static kvm_pfn_t pte_prefetch_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn,
bool no_dirty_log)
{
struct kvm_memory_slot *slot;
@@@ -2691,8 -2708,9 +2691,8 @@@ static void direct_pte_prefetch(struct
__direct_pte_prefetch(vcpu, sp, sptep);
}
-static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v, int write,
- int map_writable, int level, gfn_t gfn, kvm_pfn_t pfn,
- bool prefault)
+static int __direct_map(struct kvm_vcpu *vcpu, int write, int map_writable,
- int level, gfn_t gfn, pfn_t pfn, bool prefault)
++ int level, gfn_t gfn, kvm_pfn_t pfn, bool prefault)
{
struct kvm_shadow_walk_iterator iterator;
struct kvm_mmu_page *sp;
--
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] dmaengine: dw: fix potential memory leak in dw_dma_parse_dt()
On Thu, Dec 17, 2015 at 11:30:57PM +, Mans Rullgard wrote: > If the "dma-channels" DT property is missing, the dw_dma_parse_dt() > function return NULL, but not before allocating memory for a struct > dw_dma_platform_data through devres. If the device supports parameter > detection, the probe still succeeds and the allocated memory is not > released until the device is removed. > > Fix this by deferring the allocation until after checking the > "dma-channels" property. Applied, thanks -- ~Vinod -- 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 v02 0/2] ARM: DTS: am33xx/am437x: Use the new eDMA bindings
On Thu, Dec 17, 2015 at 09:48:44AM -0800, Tony Lindgren wrote: > * Peter Ujfalusi [151217 05:33]: > > Hi, > > > > Changes since v1: > > - Updated to use the non 16bit arrays [1] > > - send the two patch as a series > > > > [1] > > As it has been discussed earlier: > > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html > > > > the DT bindings has been changes compared to what we had in 4.4-rc1: the > > arrays > > now don't have the 16bit type. > > The changes are now merged to mainline and Vinod provided us a branch: > > > > git://git.infradead.org/users/vkoul/slave-dma.git fix/edma > > > > Which is based on 4.4-rc1 and only contains the two patch for changing the > > eDMA > > bindings. > > Great, I'll merge the fix/edma also into omap-for-v4.5/dt and apply > your two patches. FWIW, fix/edma is in Linu's tree now and should be in -rc6 Thanks -- ~Vinod -- 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/
4.4-rc5 crash (af_unix)
Still something with af_unix and/or wake code on rc5 : [34971.300210] Unable to handle kernel paging request at virtual address 56ac56ac [34971.307455] pgd = a8c3 [34971.310164] [56ac56ac] *pgd= [34971.313761] Internal error: Oops: 8005 [#1] PREEMPT SMP ARM [34971.319683] Modules linked in: btwilink st_drv [34971.324174] CPU: 1 PID: 333 Comm: compositor Not tainted 4.4.0-rc5 #1 [34971.330620] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [34971.337152] task: a8c71c80 ti: a8aea000 task.ti: a8aea000 [34971.342554] PC is at 0x56ac56ac [34971.345710] LR is at __wake_up_common+0x4c/0x80 [34971.350246] pc : [<56ac56ac>]lr : [<800585e4>]psr: 200f0093 [34971.350246] sp : a8aebd20 ip : a8ea56bc fp : 0001 [34971.361725] r10: 0001 r9 : 0001 r8 : 0304 [34971.366952] r7 : a8ea5744 r6 : 8023a9e4 r5 : 56ac56ac r4 : a8c95d28 [34971.373480] r3 : 0304 r2 : 0001 r1 : 0001 r0 : a8ea56bc [34971.380010] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [34971.387234] Control: 10c5387d Table: 38c3004a DAC: 0055 [34971.392982] Process compositor (pid: 333, stack limit = 0xa8aea210) [34971.399250] Stack: (0xa8aebd20 to 0xa8aec000) [34971.403612] bd20: 0001 a8ea5740 0001 0304 0001 a00f0013 0098 a8aebe4c [34971.411793] bd40: 80058bc8 0304 a8aebe78 a8db42c0 a8db42c0 a8db4000 0f68 [34971.419974] bd60: a8db4084 805bd7c0 a8db4394 805196d8 a9e37600 a8db4000 805bd270 [34971.428155] bd80: a8aebd94 a9e37600 8051a810 [34971.436336] bda0: a9e37600 8051a970 a9e37600 8051aa44 a9e37600 805be498 7ec113e8 8025f2e4 [34971.444517] bdc0: a8f35044 0098 a8db420c 0098 a653e780 0001 [34971.452697] bde0: a8db41e4 a8aebdf8 a8aea000 800e4928 [34971.460878] be00: 7ec115a8 80264d8c a8aebe78 a8aebe24 [34971.469059] be20: 00a5cda4 80513658 a8aebf6c 4040 7ec115b8 7ec115d4 a8aebeb8 a653e780 [34971.477240] be40: 00c50388 805be604 00c87240 805bd130 a653e780 a8aebf6c 1000 [34971.485420] be60: 4040 00c50388 8051515c 00c506fc 0c8c [34971.493601] be80: 00c50388 0374 014d 0004 0320 00a70664 00983dcc [34971.501782] bea0: 758ce8e0 00983dcc 758ce8e0 758ce8ec 00a70664 758ce8ec 80513a8c [34971.509963] bec0: a8b6df8c a8aebf10 a8b6df8c a8aebf10 7ec116d8 8011da50 00a70664 [34971.518143] bee0: 0001 600f0013 a8aebefc 8004559c a8c07500 600f0013 a8c07534 806de1a0 [34971.526324] bf00: a8c07534 806de414 8011df1c a8aebf10 a8aebf10 a8aebf2c 0020 [34971.534505] bf20: a895ccc0 800fd364 a8aebf68 a8aebf64 4040 0129 a653e780 7ec115b8 [34971.542686] bf40: 4040 0129 8000f6a4 a8aea000 80515eb0 [34971.550867] bf60: 0020 0001 fff7 0098 0f68 [34971.559047] bf80: a8aebe78 0002 7ec115d4 007c 4000 0040 001c [34971.567227] bfa0: 7ec115b8 8000f500 0040 001c 001c 7ec115b8 4040 [34971.575409] bfc0: 0040 001c 7ec115b8 0129 0006 7ec115b8 76145d68 00c50388 [34971.583589] bfe0: 7ec11588 73d6f4c0 75bef794 800f0010 001c 3bf5e861 3bf5ec61 [34971.591782] [<800585e4>] (__wake_up_common) from [<80058bc8>] (__wake_up_sync_key+0x44/0x60) [34971.600235] [<80058bc8>] (__wake_up_sync_key) from [<805bd7c0>] (unix_write_space+0x58/0x88) [34971.608686] [<805bd7c0>] (unix_write_space) from [<805196d8>] (sock_wfree+0x78/0x80) [34971.616437] [<805196d8>] (sock_wfree) from [<805bd270>] (unix_destruct_scm+0x64/0x6c) [34971.624276] [<805bd270>] (unix_destruct_scm) from [<8051a810>] (skb_release_head_state+0x84/0xec) [34971.633154] [<8051a810>] (skb_release_head_state) from [<8051a970>] (skb_release_all+0xc/0x24) [34971.641772] [<8051a970>] (skb_release_all) from [<8051aa44>] (consume_skb+0x24/0x60) [34971.649523] [<8051aa44>] (consume_skb) from [<805be498>] (unix_stream_read_generic+0x71c/0x7d0) [34971.658228] [<805be498>] (unix_stream_read_generic) from [<805be604>] (unix_stream_recvmsg+0x38/0x40) [34971.667453] [<805be604>] (unix_stream_recvmsg) from [<8051515c>] (___sys_recvmsg+0x94/0x12c) [34971.675897] [<8051515c>] (___sys_recvmsg) from [<80515eb0>] (__sys_recvmsg+0x3c/0x6c) [34971.683738] [<80515eb0>] (__sys_recvmsg) from [<8000f500>] (ret_fast_syscall+0x0/0x34) [34971.691659] Code: bad PC value [34971.694718] ---[ end trace b54a6d4b7a89f212 ]--- [34971.699339] Kernel panic - not syncing: Fatal exception [34971.704572] CPU2: stopping [34971.707292] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 4.4.0-rc5 #1 [34971.714691] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [34971.721240] [<80016be4>] (unwind_backtrace) from [<80012b68>] (show_stack+0x10/0x14) [34971.728997] [<80012b68>]
linux-next: manual merge of the akpm-current tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arm/mm/dma-mapping.c
drivers/iommu/intel-iommu.c
drivers/staging/android/ion/ion_chunk_heap.c
between commit:
3e6110fd5480 ("Revert "scatterlist: use sg_phys()"")
from Linus' tree and commit:
0504b8687491 ("scatterlist: fix sg_phys() masking")
from the akpm-current tree.
I fixed it up (I use the Linus' tree version for now, effectively removing
the whole of the akpm-current tree patch) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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 v1 0/8] x86/init: Linux linker tables
On 12/17/15 20:25, H. Peter Anvin wrote:
>
> /* DECLARE_LINKTABLE_RO */
> extern const struct foo tablename[], tablename__end[];
>
> /* DEFINE_LINKTABLE_RO */
> DECLARE_LINKTABLE_RO(struct foo, tablename);
>
> const struct
> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
>
> const struct
> foo__attribute__((used,section(".rodata.tbl.tablename.999")))
> tablename__end[0];
>
> /* LINKTABLE_RO */
> static const __typeof__(tablename)
> __attribute__((used,section(".rodata.tbl.tablename.50")))
> __tbl_tablename_12345
>
> /* LINKTABLE_SIZE */
> ((tablename__end) - (tablename))
>
> ... and so on for all the possible sections where we may want tables.
>
Come to think of it, we could even eliminate the need for a DEFINE
entirely if we made the start and end symbols static. However, this
would generate an awful lot of identical-but-local symbols which
probably would make the linker slower and definitely would bloat the
debug data.
-hpa
--
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 0/3] VFIO: capability chains
On 12/18/2015 01:38 PM, Alex Williamson wrote: On Fri, 2015-12-18 at 13:05 +1100, Alexey Kardashevskiy wrote: On 11/24/2015 07:43 AM, Alex Williamson wrote: Please see the commit log and comments in patch 1 for a general explanation of the problems that this series tries to address. The general problem is that we have several cases where we want to expose variable sized information to the user, whether it's sparse mmaps for a region, as implemented here, or DMA mapping ranges of an IOMMU, or reserved MSI mapping ranges, etc. Extending data structures is hard; extending them to report variable sized data is really hard. After considering several options, I think the best approach is to copy how PCI does capabilities. This allows the ioctl to only expose the capabilities that are relevant for them, avoids data structures that are too complicated to parse, and avoids creating a new ioctl each time we think of something else that we'd like to report. This method also doesn't preclude extensions to the fixed structure since the offset of these capabilities is entirely dynamic. Comments welcome, I'll also follow-up to the QEMU and KVM lists with an RFC making use of this for mmaps skipping over the MSI-X table. Thanks, Out of curiosity - could this information be exposed to the userspace via /sys/bus/pci/devices/:xx:xx:x/vfio_? It seems not to change after vfio_pci driver is bound to a device. For what purpose? vfio doesn't have a sysfs interface, why start one? Thanks, well, it could simplify debugging a bit if this information was available from the userspace without programming a test tool doing some ioctl()'s. Not a big deal though... -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] samsung: pmu: split up SoC specific PMU data
On 18.12.2015 12:32, Pankaj Dubey wrote: > In this series I am splitting up SoC specific PMU configuration data into > mach-exynos folder itself, before moving all of them under > drivers/soc/samsung/. Also instead of making all changes in single patch it > has been broken into SoC specific patches to avoid large size of patch. > With this approach there will not be unwanted big churns just after > adding exynos-pmu under drivers/soc/samsung. > > All these patches are just refactoring to keep minimal changes while moving > exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can > be added on top of it, in such a manner that for ARM64 build, ARM related > SoC's PMU will not get compiled and thus unnecessary increasing kernel image > size. > > This series have been prepared on top of Krzysztof Kozlowski's > next/stuff-late-not-split-per-branch branch, and it's just a rebase compared > to > V6 posted and reviewed here [1]. > > [1]: https://lkml.org/lkml/2015/11/17/15 > > For testing entire patchset on Peach-Pi (Exynos5880) based chromebook for boot > and S2R functionality. > > Tested-by: Pankaj Dubey > > For testing entire patchset on on Trats2 (Exynos4412, S2R, reboot, poweroff) > and Odroid XU3 (Exynos5422, reboot, poweroff). > > Tested-by: Krzysztof Kozlowski > > Changes since v6: > - Rebasing on top of branch provided by Krzysztof, after resolving conflicts >caused due to Alim's patches for adoptation of generic syscon for > poweroff, reboot. > - Included Tested-by tags on individual patches as per applicability. > - Dropped patches v6 [1/9], v6 [2/9] as these are already present in above > mentioned branch. > - Dropped patch v6 [8/9] as after Alim's patch this patch no more required. > Patchset applied cleanly with: 1. Removal of blank lines at end of two files (they appeared in v7). 2. Removal of your tested-by. The author does not provide such tag because it is assumed that he tested it before sending. However I left the information about testing platform near your signed-off-by. You can find the patches on the same branch: https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch I hope I will be able to push it out to arm-soc soon... Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v1 0/8] x86/init: Linux linker tables
On 12/17/15 15:46, Luis R. Rodriguez wrote:
>
> I explain why I do that there but the gist of it is that on Linux we may also
> want stronger semantics for specific linker table solutions, and solutions
> such
> as those devised on the IOMMU init stuff do memmove() for sorting depending on
> semantics defined (in the simplest case here so far dependency between init
> sequences), this makes each set of sequences very subsystem specific. An issue
> with *one* subsystem could make things really bad for others. I thought about
> this quite a bit and figured its best left to the subsystem maintainers to
> decide.
>
A table that needs sorting or other runtime handling is just a
read-write table for the purpose of the linker table construct. It
presents to C as an array of initialized data.
> Perhaps a new sections.h file (you tell me) which documents the different
> section components:
>
> /* document this *really* well */
> #define SECTION_RODATA".rodata"
> #define SECTION_INIT ".init"
> #define SECTION_INIT_RODATA ".init_rodata"
> #define SECTION_READ_MOSTLY ".read_mostly"
>
> Then on tables.h we add the section components support:
Yes, something like that. How to macroize it cleanly is another matter;
we may want to use slightly different conventions that iPXE to match our
own codebase.
> #define __table(component, type, name) (component, type, name)
>
> #define __table_component(table) __table_extract_component table
>
> #define __table_extract_component(component, type, name) component
>
> #define __table_type(table) __table_extract_type table
>
> #define __table_extract_type(component, type, name) type
>
> #define __table_name(table) __table_extract_name table
>
> #define __table_extract_name(component, type, name) name
>
> #define __table_str(x) #x
>
> #define __table_section(table, idx) \
>
> "." __table_component (table) ".tbl." __table_name (table) "."
> __table_str (idx)
>
> #define __table_entry(table, idx) \
>
> __attribute__ ((__section__(__table_section(table, idx)), \
>
> __aligned__(__table_alignment(table
>
> A user could then be something as follows:
>
> #define X86_INIT_FNS __table(SECTION_INIT, struct x86_init_fn,
> "x86_init_fns")
> #define __x86_init_fn(order_level) __table_entry(X86_INIT_FNS, order_level)
Yes, but in particular the common case of function initialization tables
should be generic.
I'm kind of thinking a syntax like this:
DECLARE_LINKTABLE_RO(struct foo, tablename);
DEFINE_LINKTABLE_RO(struct foo, tablename);
LINKTABLE_RO(tablename,level) = /* contents */;
LINKTABLE_SIZE(tablename)
... which would turn into something like this once it goes through all
the preprocessing phases
/* DECLARE_LINKTABLE_RO */
extern const struct foo tablename[], tablename__end[];
/* DEFINE_LINKTABLE_RO */
DECLARE_LINKTABLE_RO(struct foo, tablename);
const struct
foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
const struct
foo__attribute__((used,section(".rodata.tbl.tablename.999")))
tablename__end[0];
/* LINKTABLE_RO */
static const __typeof__(tablename)
__attribute__((used,section(".rodata.tbl.tablename.50")))
__tbl_tablename_12345
/* LINKTABLE_SIZE */
((tablename__end) - (tablename))
... and so on for all the possible sections where we may want tables.
Note: I used 0 and 999 above since they sort before and after all
possible 2-digit decimal numbers, but that's just cosmetic.
> If that's what you mean?
>
> I'm a bit wary about having the linker sort any of the above SECTION_*'s, but
> if we're happy to do that perhaps a simple first step might be to see if 0-day
> but would be happy with just the sort without any consequences to any
> architecture. Thoughts?
I don't see what is dangerous about it. The section names are such that
a lexographical sort will do the right thing, and we can simply use
SORT(.rodata.tbl.*) in the linker script, for example.
>> The other thing is to take a
>> clue from the implementation in iPXE, which uses priority levels 00 and
>> 99 (or we could use non-integers which sort appropriately instead of
>> using "real" levels) to contain the start and end symbols, which
>> eliminates any need for linker script modifications to add new tables.
>
> This solution uses that as well. The only need for adding custom sections
> is when they have a requirement for a custom run time sort, and also to
> ensure they don't cause regressions on other subsystems if they have a buggy
> sort. The run time sorting is all subsystem specific and up to their own
> semantics.
Again, from a linker table POV this is nothing other than a read-write
table; there is a runtime function that then operates on that read-write
table.
-hpa
--
To
[PATCH] pinctrl: mediatek: convert to arch_initcall
Move pinctrl initialization earlier in boot so that real devices can find
their pctldev without probe deferring.
Signed-off-by: Daniel Kurtz
---
drivers/pinctrl/mediatek/pinctrl-mt6397.c | 2 +-
drivers/pinctrl/mediatek/pinctrl-mt8127.c | 2 +-
drivers/pinctrl/mediatek/pinctrl-mt8135.c | 2 +-
drivers/pinctrl/mediatek/pinctrl-mt8173.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6397.c
b/drivers/pinctrl/mediatek/pinctrl-mt6397.c
index f9751ae..a3780d4 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt6397.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6397.c
@@ -70,7 +70,7 @@ static int __init mtk_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
-module_init(mtk_pinctrl_init);
+arch_initcall(mtk_pinctrl_init);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("MediaTek MT6397 Pinctrl Driver");
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8127.c
b/drivers/pinctrl/mediatek/pinctrl-mt8127.c
index b317b0b..98e0beb 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8127.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8127.c
@@ -351,7 +351,7 @@ static int __init mtk_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
-module_init(mtk_pinctrl_init);
+arch_initcall(mtk_pinctrl_init);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("MediaTek MT8127 Pinctrl Driver");
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8135.c
b/drivers/pinctrl/mediatek/pinctrl-mt8135.c
index 404f117..1c153b8 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8135.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8135.c
@@ -366,7 +366,7 @@ static int __init mtk_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
-module_init(mtk_pinctrl_init);
+arch_initcall(mtk_pinctrl_init);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("MediaTek Pinctrl Driver");
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8173.c
b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
index ad27184..a62514e 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8173.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
@@ -394,7 +394,7 @@ static int __init mtk_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
-module_init(mtk_pinctrl_init);
+arch_initcall(mtk_pinctrl_init);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("MediaTek Pinctrl Driver");
--
2.6.0.rc2.230.g3dd15c0
--
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: -next regression: "driver cohandle -EPROBE_DEFER from bus_type.match()"
On Fri, 18 Dec 2015 03:46:41 +0900,
Russell King - ARM Linux wrote:
>
> On Thu, Dec 17, 2015 at 07:51:14AM -0800, Dan Williams wrote:
> > The commit below causes the libnvdimm sub-system to stop loading.
> > This is due to the fact that nvdimm_bus_match() returns the result of
> > test_bit() which may be negative. If there are any other bus match
> > functions using test_bit they may be similarly impacted.
> >
> > Can we queue a fixup like the following to libnvdimm, and maybe
> > others, ahead of this driver core change?
>
> This is rather annoying. Have we uncovered a latent bug in other
> architectures? Well, looking through the test_bit() implementations,
> it looks like it.
>
> I'll drop the patch set for the time being, we can't go around breaking
> stuff like this. However, I think the test_bit() result should be
> regularised across different architectures - it _looks_ to me like most
> implementations return 0/1 values, but there may be some that don't
> (maybe the assembly versions?)
>
> Here's the list I've pulled out so far from the "easy" cases, which all
> look like they're returning 0/1 values.
>
> asm-generic: 0/1
>
> /**
> * test_bit - Determine whether a bit is set
> * @nr: bit number to test
> * @addr: Address to start counting from
> */
> static inline int test_bit(int nr, const volatile unsigned long *addr)
> {
> return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
> }
>
> alpha: 0/1
>
> static inline int
> test_bit(int nr, const volatile void * addr)
> {
> return (1UL & (((const int *) addr)[nr >> 5] >> (nr & 31))) != 0UL;
> }
>
> arm: 0/1
>
> test_bit(unsigned int nr, const volatile unsigned long *addr)
> {
> unsigned long mask;
>
> addr += nr >> 5;
>
> mask = 1UL << (nr & 0x1f);
>
> return ((mask & *addr) != 0);
> }
>
> blackfin: 0/1
>
> static inline int test_bit(int nr, const volatile unsigned long *addr)
> {
> volatile const unsigned long *a = addr + (nr >> 5);
> return __raw_bit_test_asm(a, nr & 0x1f) != 0;
> }
>
> frv: 0/1
>
> static inline int
> __constant_test_bit(unsigned long nr, const volatile void *addr)
> {
> return ((1UL << (nr & 31)) & (((const volatile unsigned int *)
> addr)[nr >> 5])) != 0;
> }
> (and similar for __test_bit)
>
> h8300 uses assembly... no idea
0/1
I think same return of other architecture.
> hexagon uses assembly as well... no idea
>
> ia64: 0/1
>
> static __inline__ int
> test_bit (int nr, const volatile void *addr)
> {
> return 1 & (((const volatile __u32 *) addr)[nr >> 5] >> (nr & 31));
> }
>
> m68k: 0/1
>
> static inline int test_bit(int nr, const unsigned long *vaddr)
> {
> return (vaddr[nr >> 5] & (1UL << (nr & 31))) != 0;
> }
>
> mn10300: 0/1
>
> static inline int test_bit(unsigned long nr, const volatile void *addr)
> {
> return 1UL & (((const volatile unsigned int *) addr)[nr >> 5] >> (nr
> & 31));
> }
>
> s390: 0/1
>
> static inline int test_bit(unsigned long nr, const volatile unsigned long
> *ptr)
> {
> const volatile unsigned char *addr;
>
> addr = ((const volatile unsigned char *)ptr);
> addr += (nr ^ (BITS_PER_LONG - 8)) >> 3;
> return (*addr >> (nr & 7)) & 1;
> }
>
> x86: 0/1 for constant, ? for variable
>
> static __always_inline int constant_test_bit(long nr, const volatile unsigned
> long *addr)
> {
> return ((1UL << (nr & (BITS_PER_LONG-1))) &
> (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
> }
> (presumably variable_test_bit is the same, but I don't know)
>
> --
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> --
> 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/
--
Yoshinori Sato
--
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/
linux-next: build failure after merge of the pinctrl tree
Hi Linus,
After merging the pinctrl tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c: In function
'iproc_gpio_unregister_pinconf':
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c:642:25: error: dereferencing pointer
to incomplete type 'struct cygnus_gpio'
pinctrl_unregister(chip->pctl);
^
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c: In function 'iproc_gpio_probe':
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c:738:32: warning: passing argument 1 of
'iproc_gpio_unregister_pinconf' from incompatible pointer type
[-Wincompatible-pointer-types]
iproc_gpio_unregister_pinconf(chip);
^
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c:640:13: note: expected 'struct
cygnus_gpio *' but argument is of type 'struct iproc_gpio *'
static void iproc_gpio_unregister_pinconf(struct cygnus_gpio *chip)
^
Caused by commit
616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
I have used the pinctrl tree from next-20151217 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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/9] samsung: pmu: split up SoC specific PMU data
Hi Krzysztof, On Thursday 17 December 2015 11:01 AM, Krzysztof Kozlowski wrote: > On 17.11.2015 15:05, Pankaj Dubey wrote: >> In this series I am splitting up SoC specific PMU configuration data into >> mach-exynos folder itself, before moving all of them under >> drivers/soc/samsung/. Also instead of making all changes in single patch it >> has been broken into SoC specific patches to avoid large size of patch. >> With this approach there will not be unwanted big churns just after >> adding exynos-pmu under drivers/soc/samsung. >> >> All these patches are just refactoring to keep minimal changes while moving >> exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can >> be added on top of it, in such a manner that for ARM64 build, ARM related >> SoC's PMU will not get compiled and thus unnecessary increasing kernel image >> size. >> >> These patches have been prepared on top of Kukjin Kim's for-next merged with >> driver-samsung and on top of >> cherry-picked change from [1]. >> >> 1: ARM: EXYNOS: Constify local exynos_pmu_data structure >>https://lkml.org/lkml/2015/10/28/917 >> >> For testing entire patchset on Peach-Pi (Exynos5880) based chromebook for >> boot >> and S2R functionality. >> >> Tested-by: Pankaj Dubey >> >> For testing entire patchset on on Trats2 (Exynos4412, S2R, reboot, poweroff) >> and Odroid XU3 (Exynos5422, reboot, poweroff). >> >> Tested-by: Krzysztof Kozlowski >> >> Changes since v5: >> - Removed extra blank line from patch 5/9 and 6/9. >> - Modified soc/samsung/Kconfig for config EXNOS_PMU. Added depends on ARM. >> >> Changes since v4: >> - In v3 I missed to give -M flag to detect rename, which made patches hard >>to review, so resubmitting patches with rename detector flag. >> - Addressed review comments from Krzysztof. >> >> Changes since v3: >> - Keeping intact copyright dates in existing header files. >> - Addressed review comments from Krzysztof for v3. >> - Removing static inline function from exynos-pmu.h and >>keeping them in PMU driver. >> - Added new patch (2/9) for fixing potential null pointer reference in >>exynos_sys_powerdown_conf. >> - Added new patch (8/9) for rearranging static and non-static function for >>better readability. >> >> Changes since v2: >> - Removed Amit's Samsung id as it's no more valid. >> - Rebased on latest kgene tree. >> - Removed redundant code from regs-pmu.h >> >> Pankaj Dubey (9): >> ARM: EXYNOS: removing redundant code from regs-pmu.h >> ARM: EXYNOS: Fix potential NULL pointer access in >> exynos_sys_powerdown_conf >> ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung" >> ARM: EXYNOS: split up exynos3250 SoC specific PMU data >> ARM: EXYNOS: split up exynos4 SoC specific PMU data >> ARM: EXYNOS: split up exynos5250 SoC specific PMU data >> ARM: EXYNOS: split up exynos5420 SoC specific PMU data >> ARM: EXYNOS: rearrange static and non-static functions of PMU driver >> drivers: soc: Add support for Exynos PMU driver >> > > I tried to apply this to my branch: > next/stuff-late-not-split-per-branch > https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch > > Unfortunately it fails on: > error: patch failed: arch/arm/mach-exynos/pmu.c:17 > error: arch/arm/mach-exynos/pmu.c: patch does not apply > Patch failed at 0001 ARM: EXYNOS: Move pmu specific headers under > "linux/soc/samsung" > > because of syscon-reboot handlers (Alim's work). > > I think I have all the dependencies already in my > "next/stuff-late-not-split-per-branch". > If you want to proceed now, can you rebase on top of it? Otherwise we > could wait and rebase later (after v4.5-rc1). > > Thanks for looking into this. I have just posted v7 of this series after rebasing on "next/stuff-late-not-split-per-branch". Please have a look and if all OK, include v7 in your branch, and lets try to get this in for v4.5. For some reason if does not go, I am OK to wait for next cycle. Thanks, Pankaj Dubey > P.S. Please note that "next/stuff-late-not-split-per-branch" is not > included in linux-next because I am not sure if I will be able to push > it out soon. > > > Best regards, > Krzysztof > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG, linux-next] do_IRQ: No irq handler for vector
all, I just started getting these "No irq handler for vector" messages after upgrading to linux-next 20151217+. (from the first boot) ... [2.282652] [drm] Initialized drm 1.1.0 20060810 [2.318806] AVX version of gcm_enc/dec engaged. [2.318810] AES CTR mode by8 optimization enabled [2.324446] do_IRQ: 0.35 No irq handler for vector [2.366146] iTCO_vendor_support: vendor-support=0 [2.372762] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 ... [9.249887] wlan0: associate with 2c:5d:93:09:50:48 (try 1/3) [9.265206] wlan0: RX AssocResp from 2c:5d:93:09:50:48 (capab=0x421 status=0 aid=8) [9.284088] wlan0: associated [ 10.453048] do_IRQ: 0.35 No irq handler for vector [ 10.457923] do_IRQ: 0.35 No irq handler for vector [ 10.457932] do_IRQ: 0.35 No irq handler for vector [ 10.501026] do_IRQ: 0.35 No irq handler for vector [ 10.501033] do_IRQ: 0.35 No irq handler for vector [ 10.513951] do_IRQ: 0.35 No irq handler for vector ... (second boot, and after a resume) ... [10527.998694] PM: noirq resume of devices complete after 21.488 msecs [10527.999578] PM: early resume of devices complete after 0.850 msecs [10528.000525] rtc_cmos 00:02: System wakeup disabled by ACPI [10528.005265] do_IRQ: 0.84 No irq handler for vector [10528.005450] sd 0:0:0:0: [sda] Starting disk [10528.021257] tpm_tis 00:05: TPM is disabled/deactivated (0x6) ... [10530.005541] PM: resume of devices complete after 2005.925 msecs [10530.005690] usb 3-1.4:1.0: rebind failed: -517 [10530.005696] usb 3-1.4:1.1: rebind failed: -517 [10530.006575] Restarting tasks ... [10530.008347] do_IRQ: 0.84 No irq handler for vector [10530.021258] done. [10530.042883] Bluetooth: hci0: BCM: chip id 63 ... [10559.005603] mei_me :00:16.0: timer: init clients timeout hbm_state = 1. [10559.005612] mei_me :00:16.0: unexpected reset: dev_state = INIT_CLIENTS fw status = 1E000245 6106 [10559.009508] do_IRQ: 0.84 No irq handler for vector [10561.005639] mei_me :00:16.0: wait hw ready failed [10561.005644] mei_me :00:16.0: hw_start failed ret = -62 ... I can test patches if anyone has any ideas :-) -- - Jeremiah Mahler -- 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: [RESEND PATCH v5 0/8] Add support for Exynos SROM Controller driver
Hi Krzysztof, On Thursday 17 December 2015 10:44 AM, Krzysztof Kozlowski wrote: > On 12.12.2015 16:43, Pankaj Dubey wrote: >> THIS IS A RESEND OF ONCE MERGED INTO kgene/for-next AND LOST PATCHES >> >> Series v5 got merged in kgene/for-next but due to last moment change before >> pull >> these patches were not accepted during 4.3 merge window.After that >> kgene/for-next >> got rebased over 4.4-rc1 these patches got dropped into another branch and >> till >> date not included to for-next. >> >> Since then due to minor change in "drivers/soc/", patches are not getting >> applied >> cleanly so rebasing on current for-next and resending all these with fix in >> memory >> mapping included. >> >> >> This patch set adds support for Exynos SROM controller DT based driver. >> Currently SROM register sets are used only during S2R, so driver >> basically added for taking care of S2R. It will help us in removing >> static mapping from exynos.c and other extra code handline during S2R. >> >> This patch set also updated exynos4 and exynos5 dtsi files for with device >> node for srom, and added binding documentation for the same. >> >> First two patches are some minor cleanup in mach-exynos. >> >> Patchset v1 was posted here[1] >> [1]: https://lkml.org/lkml/2015/4/29/98 >> Patchset v2 was posted here[2] >> [2]: https://lkml.org/lkml/2015/8/24/125 >> Patchset v3 was posted here[3] >> [3]: https://lkml.org/lkml/2015/10/13/392 >> Patchset v3 was posted here[4] >> [4]: https://lkml.org/lkml/2015/10/19/278 >> >> This patchset, I have tested on Peach-Pi (Exynos5880) based chromebook for >> boot >> and S2R functionality. > > Let me share the plan/status: Thanks for sharing status on this. > 1. Currently Kukjin Kim is on out of office (he told me he will be back > on Christmas). > 2. I asked arm-soc people to pull my requests. > > 3. I applied this patchset to my branch: > next/stuff-late-not-split-per-branch > https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch > > 4. This branch is not pushed to linux-next. I will sort it out if my > previous pull requests get in. I will be out of office for Christmas so > depending on the timing of arm-soc/Christmas/Kukjin this may or may not > go into v4.5 (yay...). > I am fine in either way. But prefer if it goes in v4.5, just to save time in rebasing. > 5. If it does not get into v4.5, I will rebase it and proceed further > for v4.6. > > If you have any questions, please let me know. > > Best regards, > Krzysztof > > Thanks, Pankaj Dubey -- 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 v7 4/6] ARM: EXYNOS: split up exynos5250 SoC specific PMU data
This patch splits up mach-exynos/pmu.c file, and moves exynos5250,
PMU configuration data and functions handing data into exynos5250
SoC specific PMU file mach-exynos/exynos5250-pmu.c.
Signed-off-by: Pankaj Dubey
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/Makefile | 4 +-
arch/arm/mach-exynos/exynos-pmu.h | 1 +
arch/arm/mach-exynos/exynos5250-pmu.c | 196 ++
arch/arm/mach-exynos/pmu.c| 180 ---
4 files changed, 200 insertions(+), 181 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos5250-pmu.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 8969683..bfb23a5 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,7 +9,9 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
-I$(srctree)/$(src)/include -I$(srctree)
# Core
-obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o
exynos3250-pmu.o exynos4-pmu.o
+obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o \
+ exynos3250-pmu.o exynos4-pmu.o \
+ exynos5250-pmu.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
index 3d21aad..85c858d 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -36,6 +36,7 @@ extern const struct exynos_pmu_data exynos3250_pmu_data;
extern const struct exynos_pmu_data exynos4210_pmu_data;
extern const struct exynos_pmu_data exynos4212_pmu_data;
extern const struct exynos_pmu_data exynos4412_pmu_data;
+extern const struct exynos_pmu_data exynos5250_pmu_data;
extern void pmu_raw_writel(u32 val, u32 offset);
extern u32 pmu_raw_readl(u32 offset);
diff --git a/arch/arm/mach-exynos/exynos5250-pmu.c
b/arch/arm/mach-exynos/exynos5250-pmu.c
new file mode 100644
index 000..a6d4188
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos5250-pmu.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS5250 - CPU PMU (Power Management Unit) support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "exynos-pmu.h"
+
+static const struct exynos_pmu_conf exynos5250_pmu_config[] = {
+ /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+ { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_FSYS_ARM_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_FSYS_ARM_CENTRAL_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+ { EXYNOS5_ISP_ARM_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_ARM_COMMON_SYS_PWR_REG, { 0x0, 0x0, 0x2} },
+ { EXYNOS5_ARM_L2_SYS_PWR_REG, { 0x3, 0x3, 0x3} },
+ { EXYNOS5_ARM_L2_OPTION,{ 0x10, 0x10, 0x0 } },
+ { EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
+ { EXYNOS5_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
+ { EXYNOS5_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
+ { EXYNOS5_CMU_ACLKSTOP_SYSMEM_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
+ { EXYNOS5_CMU_SCLKSTOP_SYSMEM_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
+ { EXYNOS5_CMU_RESET_SYSMEM_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+ { EXYNOS5_DRAM_FREQ_DOWN_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+ { EXYNOS5_DDRPHY_DLLOFF_SYS_PWR_REG,{ 0x1, 0x1, 0x1} },
+ { EXYNOS5_DDRPHY_DLLLOCK_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+ { EXYNOS5_APLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_MPLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_VPLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_EPLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+ { EXYNOS5_BPLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_CPLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_MPLLUSER_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_BPLLUSER_SYSCLK_SYS_PWR_REG,
[PATCH v7 2/6] ARM: EXYNOS: split up exynos3250 SoC specific PMU data
This patch splits up mach-exynos/pmu.c file, and moves exynos3250 PMU
configuration data and functions handing those data into exynos3250
SoC specific PMU file mach-exynos/exynos3250-pmu.c.
Signed-off-by: Pankaj Dubey
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/Makefile | 2 +-
arch/arm/mach-exynos/exynos-pmu.h | 39 +++
arch/arm/mach-exynos/exynos.c | 2 -
arch/arm/mach-exynos/exynos3250-pmu.c | 175
arch/arm/mach-exynos/pmu.c| 184 +-
5 files changed, 219 insertions(+), 183 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
create mode 100644 arch/arm/mach-exynos/exynos3250-pmu.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 2f30676..e869f86 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,7 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
-I$(srctree)/$(src)/include -I$(srctree)
# Core
-obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o
+obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o
exynos3250-pmu.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..5d09fa3
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __EXYNOS_PMU_H
+#define __EXYNOS_PMU_H
+
+#include
+
+#define PMU_TABLE_END (-1U)
+
+struct exynos_pmu_conf {
+ unsigned int offset;
+ u8 val[NUM_SYS_POWERDOWN];
+};
+
+struct exynos_pmu_data {
+ const struct exynos_pmu_conf *pmu_config;
+ const struct exynos_pmu_conf *pmu_config_extra;
+
+ void (*pmu_init)(void);
+ void (*powerdown_conf)(enum sys_powerdown);
+ void (*powerdown_conf_extra)(enum sys_powerdown);
+};
+
+extern void __iomem *pmu_base_addr;
+/* list of all exported SoC specific data */
+extern const struct exynos_pmu_data exynos3250_pmu_data;
+
+extern void pmu_raw_writel(u32 val, u32 offset);
+extern u32 pmu_raw_readl(u32 offset);
+#endif /* __EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 5d68ce8..ce368c8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -33,8 +33,6 @@
#include "common.h"
#include "mfc.h"
-void __iomem *pmu_base_addr;
-
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S5P_VA_CMU,
diff --git a/arch/arm/mach-exynos/exynos3250-pmu.c
b/arch/arm/mach-exynos/exynos3250-pmu.c
new file mode 100644
index 000..20b3ab8
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos3250-pmu.c
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS3250 - CPU PMU (Power Management Unit) support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "exynos-pmu.h"
+
+static struct exynos_pmu_conf exynos3250_pmu_config[] = {
+ /* { .offset = offset, .val = { AFTR, W-AFTR, SLEEP } */
+ { EXYNOS3_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+ { EXYNOS3_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS3_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS3_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+ { EXYNOS3_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS3_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS3_ISP_ARM_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS3_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS3_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS3_ARM_COMMON_SYS_PWR_REG, { 0x0, 0x0, 0x2} },
+ { EXYNOS3_ARM_L2_SYS_PWR_REG, { 0x0, 0x0, 0x3} },
+ { EXYNOS3_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+ { EXYNOS3_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+ { EXYNOS3_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
+ { EXYNOS3_DRAM_FREQ_DOWN_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+ { EXYNOS3_DDRPHY_DLLOFF_SYS_PWR_REG,{ 0x1, 0x1, 0x1} },
+ { EXYNOS3_LPDDR_PHY_DLL_LOCK_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+
[PATCH v7 6/6] drivers: soc: Add support for Exynos PMU driver
This patch moves Exynos PMU driver implementation from "arm/mach-exynos"
to "drivers/soc/samsung". This driver is mainly used for setting misc
bits of register from PMU IP of Exynos SoC which will be required to
configure before Suspend/Resume. Currently all these settings are done
in "arch/arm/mach-exynos/pmu.c" but moving ahead for ARM64 based SoC
support, there is a need of this PMU driver in driver/* folder.
This driver uses existing DT binding information and there should
be no functionality change in the supported platforms.
Signed-off-by: Amit Daniel Kachhap
Signed-off-by: Pankaj Dubey
Reviewed-by: Krzysztof Kozlowski
[for testing on Trats2 (Exynos4412) and Odroid XU3 (Exynos5422)]
Tested-by: Krzysztof Kozlowski
[for testing on Peach-Pi (Exynos5880)]
Tested-by: Pankaj Dubey
---
arch/arm/mach-exynos/Kconfig | 1 +
arch/arm/mach-exynos/Makefile | 4 +---
drivers/soc/samsung/Kconfig| 4
drivers/soc/samsung/Makefile | 2 ++
arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c | 0
{arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h | 0
{arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c | 0
{arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c| 0
{arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c | 0
{arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c | 0
10 files changed, 8 insertions(+), 3 deletions(-)
rename arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c (100%)
rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h (100%)
rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c (100%)
rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c (100%)
rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c (100%)
rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c (100%)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 782ed7d..57f0ba8 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,6 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
+ select EXYNOS_PMU
select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 2d58063..34d29df 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,9 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
-I$(srctree)/$(src)/include -I$(srctree)
# Core
-obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o \
- exynos3250-pmu.o exynos4-pmu.o \
- exynos5250-pmu.o exynos5420-pmu.o
+obj-$(CONFIG_ARCH_EXYNOS) += exynos.o exynos-smc.o firmware.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index ea4bc2a..895f169 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -10,4 +10,8 @@ config EXYNOS_SROM
bool
depends on ARM && ARCH_EXYNOS
+config EXYNOS_PMU
+ bool
+ depends on ARM && ARCH_EXYNOS
+
endmenu
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 9c554d5..cef7970 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -1 +1,3 @@
obj-$(CONFIG_EXYNOS_SROM) += exynos-srom.o
+obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o exynos3250-pmu.o exynos4-pmu.o \
+ exynos5250-pmu.o exynos5420-pmu.o
diff --git a/arch/arm/mach-exynos/pmu.c b/drivers/soc/samsung/exynos-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/pmu.c
rename to drivers/soc/samsung/exynos-pmu.c
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/drivers/soc/samsung/exynos-pmu.h
similarity index 100%
rename from arch/arm/mach-exynos/exynos-pmu.h
rename to drivers/soc/samsung/exynos-pmu.h
diff --git a/arch/arm/mach-exynos/exynos3250-pmu.c
b/drivers/soc/samsung/exynos3250-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos3250-pmu.c
rename to drivers/soc/samsung/exynos3250-pmu.c
diff --git a/arch/arm/mach-exynos/exynos4-pmu.c
b/drivers/soc/samsung/exynos4-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos4-pmu.c
rename to drivers/soc/samsung/exynos4-pmu.c
diff --git a/arch/arm/mach-exynos/exynos5250-pmu.c
b/drivers/soc/samsung/exynos5250-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos5250-pmu.c
rename to drivers/soc/samsung/exynos5250-pmu.c
diff --git a/arch/arm/mach-exynos/exynos5420-pmu.c
b/drivers/soc/samsung/exynos5420-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos5420-pmu.c
[PATCH v7 5/6] ARM: EXYNOS: split up exynos5420 SoC specific PMU data
This patch splits up mach-exynos/pmu.c file, and moves exynos5420,
PMU configuration data and functions handing data into exynos5420
SoC specific PMU file mach-exynos/exynos5420-pmu.c.
Signed-off-by: Pankaj Dubey
Reviewed-by: Krzysztof Kozlowski
[for testing on Peach-Pi (Exynos5880)]
Tested-by: Pankaj Dubey
---
arch/arm/mach-exynos/Makefile | 2 +-
arch/arm/mach-exynos/exynos-pmu.h | 1 +
arch/arm/mach-exynos/exynos5420-pmu.c | 280 ++
arch/arm/mach-exynos/pmu.c| 263 ---
4 files changed, 282 insertions(+), 264 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos5420-pmu.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index bfb23a5..2d58063 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -11,7 +11,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
-I$(srctree)/$(src)/include -I$(srctree)
obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o \
exynos3250-pmu.o exynos4-pmu.o \
- exynos5250-pmu.o
+ exynos5250-pmu.o exynos5420-pmu.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
index 85c858d..a469e36 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -37,6 +37,7 @@ extern const struct exynos_pmu_data exynos4210_pmu_data;
extern const struct exynos_pmu_data exynos4212_pmu_data;
extern const struct exynos_pmu_data exynos4412_pmu_data;
extern const struct exynos_pmu_data exynos5250_pmu_data;
+extern const struct exynos_pmu_data exynos5420_pmu_data;
extern void pmu_raw_writel(u32 val, u32 offset);
extern u32 pmu_raw_readl(u32 offset);
diff --git a/arch/arm/mach-exynos/exynos5420-pmu.c
b/arch/arm/mach-exynos/exynos5420-pmu.c
new file mode 100644
index 000..b962fb6
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos5420-pmu.c
@@ -0,0 +1,280 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS5420 - CPU PMU (Power Management Unit) support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "exynos-pmu.h"
+
+static struct exynos_pmu_conf exynos5420_pmu_config[] = {
+ /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+ { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_ARM_CORE2_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_ARM_CORE3_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE0_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE1_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE2_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE3_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_ISP_ARM_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x1, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5420_ARM_COMMON_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_COMMON_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5_ARM_L2_SYS_PWR_REG,
[PATCH v7 3/6] ARM: EXYNOS: split up exynos4 SoC specific PMU data
This patch splits up mach-exynos/pmu.c file, and moves exynos4210,
exynos4412 and exynos4212 PMU configuration data and functions handing
data into a common exynos4 SoC specific PMU file mach-exynos/exynos4-pmu.c.
Signed-off-by: Pankaj Dubey
Reviewed-by: Krzysztof Kozlowski
[for testing on Trats2 (Exynos4412, S2R, reboot, poweroff)]
Tested-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/Makefile | 2 +-
arch/arm/mach-exynos/exynos-pmu.h | 3 +
arch/arm/mach-exynos/exynos4-pmu.c | 223 +
arch/arm/mach-exynos/pmu.c | 207 --
4 files changed, 227 insertions(+), 208 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos4-pmu.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index e869f86..8969683 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,7 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
-I$(srctree)/$(src)/include -I$(srctree)
# Core
-obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o
exynos3250-pmu.o
+obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o
exynos3250-pmu.o exynos4-pmu.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
index 5d09fa3..3d21aad 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -33,6 +33,9 @@ struct exynos_pmu_data {
extern void __iomem *pmu_base_addr;
/* list of all exported SoC specific data */
extern const struct exynos_pmu_data exynos3250_pmu_data;
+extern const struct exynos_pmu_data exynos4210_pmu_data;
+extern const struct exynos_pmu_data exynos4212_pmu_data;
+extern const struct exynos_pmu_data exynos4412_pmu_data;
extern void pmu_raw_writel(u32 val, u32 offset);
extern u32 pmu_raw_readl(u32 offset);
diff --git a/arch/arm/mach-exynos/exynos4-pmu.c
b/arch/arm/mach-exynos/exynos4-pmu.c
new file mode 100644
index 000..4b0a79e
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos4-pmu.c
@@ -0,0 +1,223 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS4 - CPU PMU(Power Management Unit) support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "exynos-pmu.h"
+
+static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
+ /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+ { S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
+ { S5P_DIS_IRQ_CORE0,{ 0x0, 0x0, 0x0 } },
+ { S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
+ { S5P_ARM_CORE1_LOWPWR, { 0x0, 0x0, 0x2 } },
+ { S5P_DIS_IRQ_CORE1,{ 0x0, 0x0, 0x0 } },
+ { S5P_DIS_IRQ_CENTRAL1, { 0x0, 0x0, 0x0 } },
+ { S5P_ARM_COMMON_LOWPWR,{ 0x0, 0x0, 0x2 } },
+ { S5P_L2_0_LOWPWR, { 0x2, 0x2, 0x3 } },
+ { S5P_L2_1_LOWPWR, { 0x2, 0x2, 0x3 } },
+ { S5P_CMU_ACLKSTOP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_SCLKSTOP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_APLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_MPLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_VPLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_EPLL_SYSCLK_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_GPS_ALIVE_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_GPSALIVE_LOWPWR,{ 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_CAM_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_TV_LOWPWR,{ 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_MFC_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_G3D_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_LCD0_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_LCD1_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_MAUDIO_LOWPWR,{ 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_GPS_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_CAM_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_TV_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_MFC_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_G3D_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_LCD0_LOWPWR,{ 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_LCD1_LOWPWR,{ 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_MAUDIO_LOWPWR, { 0x1, 0x1, 0x0 } },
+ {
[PATCH v7 0/6] samsung: pmu: split up SoC specific PMU data
In this series I am splitting up SoC specific PMU configuration data into
mach-exynos folder itself, before moving all of them under
drivers/soc/samsung/. Also instead of making all changes in single patch it
has been broken into SoC specific patches to avoid large size of patch.
With this approach there will not be unwanted big churns just after
adding exynos-pmu under drivers/soc/samsung.
All these patches are just refactoring to keep minimal changes while moving
exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can
be added on top of it, in such a manner that for ARM64 build, ARM related
SoC's PMU will not get compiled and thus unnecessary increasing kernel image
size.
This series have been prepared on top of Krzysztof Kozlowski's
next/stuff-late-not-split-per-branch branch, and it's just a rebase compared to
V6 posted and reviewed here [1].
[1]: https://lkml.org/lkml/2015/11/17/15
For testing entire patchset on Peach-Pi (Exynos5880) based chromebook for boot
and S2R functionality.
Tested-by: Pankaj Dubey
For testing entire patchset on on Trats2 (Exynos4412, S2R, reboot, poweroff)
and Odroid XU3 (Exynos5422, reboot, poweroff).
Tested-by: Krzysztof Kozlowski
Changes since v6:
- Rebasing on top of branch provided by Krzysztof, after resolving conflicts
caused due to Alim's patches for adoptation of generic syscon for poweroff,
reboot.
- Included Tested-by tags on individual patches as per applicability.
- Dropped patches v6 [1/9], v6 [2/9] as these are already present in above
mentioned branch.
- Dropped patch v6 [8/9] as after Alim's patch this patch no more required.
Changes since v5:
- Removed extra blank line from patch 5/9 and 6/9.
- Modified soc/samsung/Kconfig for config EXNOS_PMU. Added depends on ARM.
Changes since v4:
- In v3 I missed to give -M flag to detect rename, which made patches hard
to review, so resubmitting patches with rename detector flag.
- Addressed review comments from Krzysztof.
Changes since v3:
- Keeping intact copyright dates in existing header files.
- Addressed review comments from Krzysztof for v3.
- Removing static inline function from exynos-pmu.h and
keeping them in PMU driver.
- Added new patch (2/9) for fixing potential null pointer reference in
exynos_sys_powerdown_conf.
- Added new patch (8/9) for rearranging static and non-static function for
better readability.
Changes since v2:
- Removed Amit's Samsung id as it's no more valid.
- Rebased on latest kgene tree.
- Removed redundant code from regs-pmu.h
Pankaj Dubey (6):
ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"
ARM: EXYNOS: split up exynos3250 SoC specific PMU data
ARM: EXYNOS: split up exynos4 SoC specific PMU data
ARM: EXYNOS: split up exynos5250 SoC specific PMU data
ARM: EXYNOS: split up exynos5420 SoC specific PMU data
drivers: soc: Add support for Exynos PMU driver
arch/arm/mach-exynos/Kconfig | 1 +
arch/arm/mach-exynos/Makefile | 2 +-
arch/arm/mach-exynos/exynos.c | 4 +-
arch/arm/mach-exynos/mcpm-exynos.c | 2 +-
arch/arm/mach-exynos/platsmp.c | 2 +-
arch/arm/mach-exynos/pm.c | 4 +-
arch/arm/mach-exynos/pmu.c | 967 -
arch/arm/mach-exynos/suspend.c | 4 +-
drivers/soc/samsung/Kconfig| 4 +
drivers/soc/samsung/Makefile | 2 +
drivers/soc/samsung/exynos-pmu.c | 141 +++
drivers/soc/samsung/exynos-pmu.h | 44 +
drivers/soc/samsung/exynos3250-pmu.c | 175
drivers/soc/samsung/exynos4-pmu.c | 223 +
drivers/soc/samsung/exynos5250-pmu.c | 196 +
drivers/soc/samsung/exynos5420-pmu.c | 280 ++
.../linux/soc/samsung}/exynos-pmu.h| 6 +-
.../linux/soc/samsung/exynos-regs-pmu.h| 6 +-
18 files changed, 1080 insertions(+), 983 deletions(-)
delete mode 100644 arch/arm/mach-exynos/pmu.c
create mode 100644 drivers/soc/samsung/exynos-pmu.c
create mode 100644 drivers/soc/samsung/exynos-pmu.h
create mode 100644 drivers/soc/samsung/exynos3250-pmu.c
create mode 100644 drivers/soc/samsung/exynos4-pmu.c
create mode 100644 drivers/soc/samsung/exynos5250-pmu.c
create mode 100644 drivers/soc/samsung/exynos5420-pmu.c
rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (81%)
rename arch/arm/mach-exynos/regs-pmu.h =>
include/linux/soc/samsung/exynos-regs-pmu.h (99%)
--
2.4.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 v7 1/6] ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"
Moving Exynos PMU specific header file into "include/linux/soc/samsung"
thus updated affected files under "mach-exynos" to use new location of
these header files.
Signed-off-by: Amit Daniel Kachhap
Signed-off-by: Pankaj Dubey
Reviewed-by: Krzysztof Kozlowski
[for testing on Trats2 (Exynos4412) and Odroid XU3 (Exynos5422)]
Tested-by: Krzysztof Kozlowski
[for testing on Peach-Pi (Exynos5880)]
Tested-by: Pankaj Dubey
---
arch/arm/mach-exynos/exynos.c | 2 +-
arch/arm/mach-exynos/mcpm-exynos.c | 2 +-
arch/arm/mach-exynos/platsmp.c | 2 +-
arch/arm/mach-exynos/pm.c | 4 ++--
arch/arm/mach-exynos/pmu.c | 6 +++---
arch/arm/mach-exynos/suspend.c | 4 ++--
{arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h| 6 +++---
.../regs-pmu.h => include/linux/soc/samsung/exynos-regs-pmu.h | 6 +++---
8 files changed, 16 insertions(+), 16 deletions(-)
rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (81%)
rename arch/arm/mach-exynos/regs-pmu.h =>
include/linux/soc/samsung/exynos-regs-pmu.h (99%)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 4ffb90e..5d68ce8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -31,7 +32,6 @@
#include "common.h"
#include "mfc.h"
-#include "regs-pmu.h"
void __iomem *pmu_base_addr;
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 5697819..f086bf6 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -16,13 +16,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-#include "regs-pmu.h"
#include "common.h"
#define EXYNOS5420_CPUS_PER_CLUSTER4
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 98a2c0c..d5caf30 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -30,7 +31,6 @@
#include
#include "common.h"
-#include "regs-pmu.h"
extern void exynos4_secondary_startup(void);
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 9c1506b..b9b9186 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -29,8 +31,6 @@
#include
#include "common.h"
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
static inline void __iomem *exynos_boot_vector_addr(void)
{
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index dbf9fe9..2ff1956 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -15,10 +15,10 @@
#include
#include
-#include
+#include
+#include
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
+#include
#define PMU_TABLE_END (-1U)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 237653e..f216909 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -37,8 +39,6 @@
#include
#include "common.h"
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
#define REG_TABLE_END (-1U)
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/include/linux/soc/samsung/exynos-pmu.h
similarity index 81%
rename from arch/arm/mach-exynos/exynos-pmu.h
rename to include/linux/soc/samsung/exynos-pmu.h
index a2ab0d5..e2e9de1 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/include/linux/soc/samsung/exynos-pmu.h
@@ -9,8 +9,8 @@
* published by the Free Software Foundation.
*/
-#ifndef __EXYNOS_PMU_H
-#define __EXYNOS_PMU_H
+#ifndef __LINUX_SOC_EXYNOS_PMU_H
+#define __LINUX_SOC_EXYNOS_PMU_H
enum sys_powerdown {
SYS_AFTR,
@@ -21,4 +21,4 @@ enum sys_powerdown {
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
-#endif /* __EXYNOS_PMU_H */
+#endif /* __LINUX_SOC_EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/regs-pmu.h
b/include/linux/soc/samsung/exynos-regs-pmu.h
similarity index 99%
rename from arch/arm/mach-exynos/regs-pmu.h
rename to include/linux/soc/samsung/exynos-regs-pmu.h
index 5e4f4c2..d30186e 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -9,8 +9,8 @@
* published by the Free Software Foundation.
*/
-#ifndef __ASM_ARCH_REGS_PMU_H
-#define __ASM_ARCH_REGS_PMU_H __FILE__
+#ifndef __LINUX_SOC_EXYNOS_REGS_PMU_H
+#define __LINUX_SOC_EXYNOS_REGS_PMU_H __FILE__
#define S5P_CENTRAL_SEQ_CONFIGURATION 0x0200
@@ -690,4 +690,4 @@
Re: [PATCH 00/10] bpf samples: Uses libbpf in tools/lib to do BPF operations
On 2015/12/17 21:46, Daniel Wagner wrote: On 12/17/2015 11:09 AM, Wangnan (F) wrote: On 2015/12/17 16:29, Daniel Wagner wrote: On 12/17/2015 08:03 AM, Daniel Wagner wrote: Patch number 2 didn't apply cleanly. Because I have another patch in my local tree which also modifis bpf Makefile: http://lkml.kernel.org/g/1450316632-152513-1-git-send-email-wangn...@huawei.com sorry. Ah, that explains it this problem. After fixing this manually I was able to continue to the build step: $ make samples/bpf/ CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh make -C /home/wagi/src/linux/tools/lib/bpf O=/home/wagi/src/linux/samples/bpf/libbpf CFLAGS= LDFLAGS= V=1 /home/wagi/src/linux/samples/bpf/libbpf/libbpf.a No libelf found Makefile:203: recipe for target 'elfdep' failed make[2]: *** [elfdep] Error 255 samples/bpf/Makefile:10: recipe for target 'samples/bpf/libbpf/libbpf.a' failed make[1]: *** [samples/bpf/libbpf/libbpf.a] Error 2 Makefile:1550: recipe for target 'samples/bpf/' failed make: *** [samples/bpf/] Error 2 When you see this, could you please have a look at: /home/wagi/src/linux/samples/bpf/libbpf/feature/test-*.make.output ? test-libpython.c:1:20: fatal error: Python.h: No such file or directory So it is the content in test-all.make.output ? Then it is not a problem. It is only a fastpath which tries to check all features by one test. On most platform it would fail. BPF related feature check is not in test-all. It is a potential bug, but I don't think it causes your problem. Another problem is you didn't see this in the first failure: Auto-detecting system features: ...libelf: [ on ] ... bpf: [ on ] This only happen when you already have a FEATURE-DUMP.libbpf in that directory and it is same as the feature check result. Could you please remove samples/bpf in your building tree and try again? After you see the failure, what's the content of /home/wagi/src/linux/samples/bpf/libbpf/FEATURE-* ? Thank you. -- 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] CHROMIUM: Input: elants_i2c: fixed wake-on-touch issue
From: "james.chen"
Something wrong in suspend/resume of kernel v3.14 for the function of
wake-on-touch. The function of device_may_wakeup will return true if
the device supports wake-on-touch (for example, kitty and buddy).
So, modify the code from "if (device_may_wakeup(dev))" to
"if (!device_may_wakeup(dev))". And adjust the condition check of
keep_power_in_suspend (designed for minnie).
Signed-off-by: James Chen
---
drivers/input/touchscreen/elants_i2c.c | 37 +-
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/input/touchscreen/elants_i2c.c
b/drivers/input/touchscreen/elants_i2c.c
index 17cc20e..06ee814 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -1307,7 +1307,7 @@ static int __maybe_unused elants_i2c_suspend(struct
device *dev)
struct i2c_client *client = to_i2c_client(dev);
struct elants_data *ts = i2c_get_clientdata(client);
const u8 set_sleep_cmd[] = { 0x54, 0x50, 0x00, 0x01 };
- int retry_cnt;
+ int retry;
int error;
/* Command not support in IAP recovery mode */
@@ -1316,24 +1316,25 @@ static int __maybe_unused elants_i2c_suspend(struct
device *dev)
disable_irq(client->irq);
- if (device_may_wakeup(dev) || ts->keep_power_in_suspend) {
- for (retry_cnt = 0; retry_cnt < MAX_RETRIES; retry_cnt++) {
+ if (device_may_wakeup(dev)) {
+ /*
+* The device will automatically enter idle mode
+* that has reduced power consumption.
+*/
+ ts->wake_irq_enabled = (enable_irq_wake(client->irq) == 0);
+ } else if (ts->keep_power_in_suspend) {
+ for (retry = 0; retry < MAX_RETRIES; retry++) {
error = elants_i2c_send(client, set_sleep_cmd,
- sizeof(set_sleep_cmd));
+ sizeof(set_sleep_cmd));
if (!error)
break;
dev_err(>dev,
"suspend command failed: %d\n", error);
}
-
- if (device_may_wakeup(dev))
- ts->wake_irq_enabled =
- (enable_irq_wake(client->irq) == 0);
} else {
- elants_i2c_power_off(ts);
+ elants_i2c_power_off(ts);
}
-
return 0;
}
@@ -1342,16 +1343,17 @@ static int __maybe_unused elants_i2c_resume(struct
device *dev)
struct i2c_client *client = to_i2c_client(dev);
struct elants_data *ts = i2c_get_clientdata(client);
const u8 set_active_cmd[] = { 0x54, 0x58, 0x00, 0x01 };
- int retry_cnt;
+ int retry;
int error;
- if (device_may_wakeup(dev) && ts->wake_irq_enabled)
- disable_irq_wake(client->irq);
-
- if (ts->keep_power_in_suspend) {
- for (retry_cnt = 0; retry_cnt < MAX_RETRIES; retry_cnt++) {
+ if (device_may_wakeup(dev)) {
+ if (ts->wake_irq_enabled)
+ disable_irq_wake(client->irq);
+ elants_i2c_sw_reset(client);
+ } else if (ts->keep_power_in_suspend) {
+ for (retry = 0; retry < MAX_RETRIES; retry++) {
error = elants_i2c_send(client, set_active_cmd,
- sizeof(set_active_cmd));
+ sizeof(set_active_cmd));
if (!error)
break;
@@ -1362,7 +1364,6 @@ static int __maybe_unused elants_i2c_resume(struct device
*dev)
elants_i2c_power_on(ts);
elants_i2c_initialize(ts);
}
-
ts->state = ELAN_STATE_NORMAL;
enable_irq(client->irq);
--
1.8.3.2
--
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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?
On Thu, Dec 17, 2015 at 6:50 PM, Pandruvada, Srinivas
wrote:
> On Thu, 2015-12-17 at 18:33 -0800, Nish Aravamudan wrote:
>> On Thu, Dec 17, 2015 at 5:11 PM, Pandruvada, Srinivas
>> wrote:
>> > On Thu, 2015-12-17 at 17:08 -0800, Nish Aravamudan wrote:
>> > > On Thu, Dec 17, 2015 at 5:00 PM, Pandruvada, Srinivas
>> > > wrote:
>> > > > Hi Andy,
>> > > >
>> > > > As per Nish these patches are impacting sensors on Yoga.
>> > > > https://lkml.org/lkml/2015/11/30/441
>> > >
>> > > To be clear, without that series, the touchpad and touchscreen on
>> > > the
>> > > Yoga 900 don't work at all. So they are necessary for
>> > > functioning. I
>> > > don't know (I will test it now), if removing the series makes the
>> > > IIO
>> > > sensors work properly in /dev/.
>> > This is important to know before we take Andy's time.
>>
>> It seems like Andy's patches are not the problem. That is, with stock
>> 4.4-rc5, the accelerommeter /dev files still do not update.
>>
> Can you not use raw values by polling from user space? Send me
> report description. It should be in
> /sys/kernel/debug/hid/ "your device id" /redesc.
The underlying issue is that iio-sensor-proxy relies on values from
the corresponding /dev nodes to automatically rotate the screen, etc.
in the desktop environment.
Attached due to its size.
> Also device id ("your device id") above.
0018:048D:8396.0002
-Nish
rdesc
Description: Binary data
[RESEND PATCH] mtd: mtk-nor: adjust sequence of trigger function and assignment function
Move write data register before excute command to avoid
missing first byte write to nor flash
Signed-off-by: Bayi Cheng
---
the previous patch didn't drop the Change-Id
---
drivers/mtd/spi-nor/mtk-quadspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index dd269650..04da971 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -272,10 +272,10 @@ static int mt8173_nor_write_single_byte(struct mt8173_nor
*mt8173_nor,
mt8173_nor_set_addr(mt8173_nor, addr);
for (i = 0; i < length; i++) {
+ writeb(*data++, mt8173_nor->base + MTK_NOR_WDATA_REG);
ret = mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_PIO_WR_CMD);
if (ret < 0)
return ret;
- writeb(*data++, mt8173_nor->base + MTK_NOR_WDATA_REG);
}
return 0;
}
--
1.8.1.1.dirty
--
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: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
On 12/17/2015 06:32 PM, Andy Lutomirski wrote: > On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen > wrote: >> But what about the register state when delivering a signal? Don't we >> set the registers to the init state? Do we need to preserve PKRU state >> instead of init'ing it? The init state _is_ nice here because it is >> permissive allows us to do something useful no matter what PKRU gets set to. > > I think we leave the extended regs alone. Don't we? > > I think that, for most signals, we want to leave PKRU as is, > especially for things that aren't SIGSEGV. For SIGSEGV, maybe we want > an option to reset PKRU on delivery (and then set the flag to restore > on return?). Is there some precedent for doing the state differently for different signals? >> Well, the signal handler isn't necessarily going to clobber it, but the >> delivery code already clobbers it when going to the init state. > > Can you point to that code? handle_signal() -> fpu__clear() The comment around it says: "Ensure the signal handler starts with the new fpu state." >>> We have _fpx_sw_bytes.xfeatures and _xstate._header.xfeatures. They >>> appear to do more or less the same thing. >> >> I thought the _fpx_sw_bytes were only for 32-bit (or FXSAVE/FXRSTOR?). > > I thought they were everywhere. fpu/signal.c looks that way to me. I > could be missing something -- this code isn't the most straightforward > in the world. I think there's some extra space on the ia32 frame for this stuff, but some clarity from someone who knows the history would be appreciated. >> Not a huge deal, but something we want to think about, especially as it >> pertains to the init/modified optimizations. > > Fair point. FWIW, I don't think that sigreturn performance matters > all that much, so if we inadvertently lose some of the optimizations, > it may not be the end of the world. Once we lose the init optimization, we're sunk for good. We never get it back until we restore the init state again. Having it in the init state can save writing the state at XSAVE time, which can now save up to ~2k of writes at each context switch. I'm sure we can preserve it, we just need to be _careful_. -- 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 7/7] Documentation: cgroup: add memory.swap.{current,max} description
On 2015/12/17 21:30, Vladimir Davydov wrote: > The rationale of separate swap counter is given by Johannes Weiner. > > Signed-off-by: Vladimir Davydov > --- > Changes in v2: > - Add rationale of separate swap counter provided by Johannes. > > Documentation/cgroup.txt | 33 + > 1 file changed, 33 insertions(+) > > diff --git a/Documentation/cgroup.txt b/Documentation/cgroup.txt > index 31d1f7bf12a1..f441564023e1 100644 > --- a/Documentation/cgroup.txt > +++ b/Documentation/cgroup.txt > @@ -819,6 +819,22 @@ PAGE_SIZE multiple when read back. > the cgroup. This may not exactly match the number of > processes killed but should generally be close. > > + memory.swap.current > + > + A read-only single value file which exists on non-root > + cgroups. > + > + The total amount of swap currently being used by the cgroup > + and its descendants. > + > + memory.swap.max > + > + A read-write single value file which exists on non-root > + cgroups. The default is "max". > + > + Swap usage hard limit. If a cgroup's swap usage reaches this > + limit, anonymous meomry of the cgroup will not be swapped out. > + > > 5-2-2. General Usage > > @@ -1291,3 +1307,20 @@ allocation from the slack available in other groups or > the rest of the > system than killing the group. Otherwise, memory.max is there to > limit this type of spillover and ultimately contain buggy or even > malicious applications. > + > +The combined memory+swap accounting and limiting is replaced by real > +control over swap space. > + > +The main argument for a combined memory+swap facility in the original > +cgroup design was that global or parental pressure would always be > +able to swap all anonymous memory of a child group, regardless of the > +child's own (possibly untrusted) configuration. However, untrusted > +groups can sabotage swapping by other means - such as referencing its > +anonymous memory in a tight loop - and an admin can not assume full > +swappability when overcommitting untrusted jobs. > + > +For trusted jobs, on the other hand, a combined counter is not an > +intuitive userspace interface, and it flies in the face of the idea > +that cgroup controllers should account and limit specific physical > +resources. Swap space is a resource like all others in the system, > +and that's why unified hierarchy allows distributing it separately. > Could you give here a hint how to calculate amount of swapcache, counted both in memory.current and swap.current ? Thanks, -Kame -- 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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?
On Thu, 2015-12-17 at 18:33 -0800, Nish Aravamudan wrote:
> On Thu, Dec 17, 2015 at 5:11 PM, Pandruvada, Srinivas
> wrote:
> > On Thu, 2015-12-17 at 17:08 -0800, Nish Aravamudan wrote:
> > > On Thu, Dec 17, 2015 at 5:00 PM, Pandruvada, Srinivas
> > > wrote:
> > > > Hi Andy,
> > > >
> > > > As per Nish these patches are impacting sensors on Yoga.
> > > > https://lkml.org/lkml/2015/11/30/441
> > >
> > > To be clear, without that series, the touchpad and touchscreen on
> > > the
> > > Yoga 900 don't work at all. So they are necessary for
> > > functioning. I
> > > don't know (I will test it now), if removing the series makes the
> > > IIO
> > > sensors work properly in /dev/.
> > This is important to know before we take Andy's time.
>
> It seems like Andy's patches are not the problem. That is, with stock
> 4.4-rc5, the accelerommeter /dev files still do not update.
>
Can you not use raw values by polling from user space? Send me
report description. It should be in
/sys/kernel/debug/hid/ "your device id" /redesc.
Also device id ("your device id") above.
Thanks,
Srinivas
> -Nish
Re: sched : performance regression 24% between 4.4rc4 and 4.3 kernel
On Thu, 2015-12-17 at 16:43 +0100, Jirka Hladky wrote: > Hi Peter, > > I'm not sure how to do the bisecting and avoid landing at: > > [2a595721a1fa6b684c1c818f379bef834ac3d65e] sched/numa: Convert > sched_numa_balancing to a static_branch > > I have redone the bisecting but I have landed again at this commit. > Can you please help me to identify the commit which has fixed for > 2a595721a1fa6b684c1c818f379bef834ac3d65e ? I think I will need to > start the bisecting from there. One way... Put b52da86e0ad58f096710977fcda856fd84da9233 in quilt queue, try to quilt push before each build, ignoring whether it applies or not. If it does apply, quilt pop before saying git bisect [good/bad] lest git refuse to play due to you mucking about with its source its source. -Mike -- 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/8] hugetlb: make mm and fs code explicitly non-modular
On Thu, 17 Dec 2015, Paul Gortmaker wrote: The Kconfig currently controlling compilation of this code is: config HUGETLBFS bool "HugeTLB file system support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering gets moved to earlier levels when we use the more appropriate initcalls here. Originally I had the fs part and the mm part as separate commits, just by happenstance of the nature of how I detected these non-modular use cases. But that can possibly introduce regressions if the patch merge ordering puts the fs part 1st -- as the 0-day testing reported a splat at mount time. Investigating with "initcall_debug" showed that the delta was init_hugetlbfs_fs being called _before_ hugetlb_init instead of after. So both the fs change and the mm change are here together. In addition, it worked before due to luck of link order, since they were both in the same initcall category. So we now have the fs part using fs_initcall, and the mm part using subsys_initcall, which puts it one bucket earlier. It now passes the basic sanity test that failed in earlier 0-day testing. We delete the MODULE_LICENSE tag and capture that information at the top of the file alongside author comments, etc. We don't replace module.h with init.h since the file already has that. Also note that MODULE_ALIAS is a no-op for non-modular code. Cc: Nadia Yvette Chambers Cc: Alexander Viro Cc: Andrew Morton Cc: Naoya Horiguchi Cc: Mike Kravetz Cc: David Rientjes Cc: Hillf Danton Cc: Davidlohr Bueso Cc: linux...@kvack.org Cc: linux-fsde...@vger.kernel.org Reported-by: kernel test robot Signed-off-by: Paul Gortmaker Acked-by: Davidlohr Bueso -- 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/
[GIT PULL] MTD update for 4.4-rc6
Hi Linus, I was holding out on this pull request for a bit, since there are a few other small issues being discussed that look like 4.4-rc regressions. Hopefully I can get those stabilized soon, but these are ready at any rate. The following changes since commit 1ddaa021b000220b5f2ad023e4f15ed44990974b: MAINTAINERS: brcmnand: Add co-maintainer for Broadcom SoCs (2015-11-18 13:16:58 -0800) are available in the git repository at: git://git.infradead.org/linux-mtd.git tags/for-linus-20151217 for you to fetch changes up to e488ca9f8d4f62c2dc36bfa5c32f68e7f05ab381: doc: dt: mtd: partitions: add compatible property to "partitions" node (2015-12-08 17:10:20 -0800) MTD update for 4.4-rc6: A little bit of a last-minute change for the device tree "fixed partition" binding. This is needed because we might want to reuse the 'partitions' subnode for other sorts of partitioning descriptions -- e.g., for describing which on-flash partition format(s) might be used on the system. Also tone down a warning message, since it is probably going to show up on a lot of systems where it should just be ignored. Brian Norris (2): mtd: ofpart: don't complain about missing 'partitions' node too loudly doc: dt: mtd: partitions: add compatible property to "partitions" node Documentation/devicetree/bindings/mtd/partition.txt | 7 ++- drivers/mtd/ofpart.c| 12 ++-- 2 files changed, 16 insertions(+), 3 deletions(-) -- 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 0/3] VFIO: capability chains
On Fri, 2015-12-18 at 13:05 +1100, Alexey Kardashevskiy wrote: > On 11/24/2015 07:43 AM, Alex Williamson wrote: > > Please see the commit log and comments in patch 1 for a general > > explanation of the problems that this series tries to address. The > > general problem is that we have several cases where we want to > > expose > > variable sized information to the user, whether it's sparse mmaps > > for > > a region, as implemented here, or DMA mapping ranges of an IOMMU, > > or > > reserved MSI mapping ranges, etc. Extending data structures is > > hard; > > extending them to report variable sized data is really hard. After > > considering several options, I think the best approach is to copy > > how > > PCI does capabilities. This allows the ioctl to only expose the > > capabilities that are relevant for them, avoids data structures > > that > > are too complicated to parse, and avoids creating a new ioctl each > > time we think of something else that we'd like to report. This > > method > > also doesn't preclude extensions to the fixed structure since the > > offset of these capabilities is entirely dynamic. > > > > Comments welcome, I'll also follow-up to the QEMU and KVM lists > > with > > an RFC making use of this for mmaps skipping over the MSI-X table. > > Thanks, > > Out of curiosity - could this information be exposed to the userspace > via > /sys/bus/pci/devices/:xx:xx:x/vfio_? It seems not to change > after > vfio_pci driver is bound to a device. For what purpose? vfio doesn't have a sysfs interface, why start one? Thanks, Alex -- 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] mtd: mtk-nor: adjust sequence of trigger function and assignment function
move write data register before excute command to avoid
missing first byte write to nor flash
Change-Id: Ie9d7ae30f9de1f3e976d2e1de5d8ee28837598c8
Signed-off-by: Bayi Cheng
---
drivers/mtd/spi-nor/mtk-quadspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index dd269650..04da971 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -272,10 +272,10 @@ static int mt8173_nor_write_single_byte(struct mt8173_nor
*mt8173_nor,
mt8173_nor_set_addr(mt8173_nor, addr);
for (i = 0; i < length; i++) {
+ writeb(*data++, mt8173_nor->base + MTK_NOR_WDATA_REG);
ret = mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_PIO_WR_CMD);
if (ret < 0)
return ret;
- writeb(*data++, mt8173_nor->base + MTK_NOR_WDATA_REG);
}
return 0;
}
--
1.8.1.1.dirty
--
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] cgroup: put controller Kconfig options in meaningful order
On 2015/12/18 6:19, Johannes Weiner wrote: To make it easier to quickly find what's needed list the basic resource controllers of cgroup2 first - io, memory, cpu - while pushing the more exotic and/or legacy controllers to the bottom. Signed-off-by: Johannes Weiner Acked-by: Zefan Li --- init/Kconfig | 214 +-- 1 file changed, 107 insertions(+), 107 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index ed324f5..fdb5ecb 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -957,64 +957,6 @@ menuconfig CGROUPS ... +config CGROUP_PERF + bool "Perf controller" + depends on PERF_EVENTS && CGROUPS While you are at it, remove "&& CGROUPS" ? + help + This option extends the perf per-cpu mode to restrict monitoring + to threads which belong to the cgroup specified and run on the + designated cpu. + + Say N if unsure. + +config CGROUP_DEBUG + bool "Example controller" default n - ---help--- - Enable some debugging help. Currently it exports additional stat - files in a cgroup which can be useful for debugging. + help + This option enables a simple controller that exports + debugging information about the cgroups framework. -config CGROUP_WRITEBACK - bool - depends on MEMCG && BLK_CGROUP - default y + Say N. endif # CGROUPS -- 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/
[no subject]
Are you in need of private or business loans for various purposes? if yes,apply now -- 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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?
On Thu, Dec 17, 2015 at 5:11 PM, Pandruvada, Srinivas wrote: > On Thu, 2015-12-17 at 17:08 -0800, Nish Aravamudan wrote: >> On Thu, Dec 17, 2015 at 5:00 PM, Pandruvada, Srinivas >> wrote: >> > Hi Andy, >> > >> > As per Nish these patches are impacting sensors on Yoga. >> > https://lkml.org/lkml/2015/11/30/441 >> >> To be clear, without that series, the touchpad and touchscreen on the >> Yoga 900 don't work at all. So they are necessary for functioning. I >> don't know (I will test it now), if removing the series makes the IIO >> sensors work properly in /dev/. > This is important to know before we take Andy's time. It seems like Andy's patches are not the problem. That is, with stock 4.4-rc5, the accelerommeter /dev files still do not update. -Nish -- 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: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen wrote: > On 12/17/2015 05:48 PM, Andy Lutomirski wrote: >> I think that, for PKRU in particular, we want the default signal >> handling behavior to be a bit unusual. >> >> When a signal is delivered, I think we should save the entire xstate >> including PKRU. I see no reason to do anything other than that. > > Yep, agreed. > > But what about the register state when delivering a signal? Don't we > set the registers to the init state? Do we need to preserve PKRU state > instead of init'ing it? The init state _is_ nice here because it is > permissive allows us to do something useful no matter what PKRU gets set to. I think we leave the extended regs alone. Don't we? I think that, for most signals, we want to leave PKRU as is, especially for things that aren't SIGSEGV. For SIGSEGV, maybe we want an option to reset PKRU on delivery (and then set the flag to restore on return?). In any case, I think there are a decent number of programs out there that use siglongjmp and therefore never actually hit sigreturn. They probably won't restore PKRU, so we shouldn't zero it out when delivering most signals, I think. > > But, if we leave the init state in place when entering a delivering a > signal, we _can't_ decide to (by default at least) preserve the > in-signal state. > >> When a signal returns (sigreturn is called), though, I think we should >> *not* restore PKRU. To me, PKRU seems like a global per-thread state, >> not something that signal handlers are likely to clobber and should >> therefore have restored. It's also unusual in that it doesn't fit >> into the usual xstate feature model of being a bunch of registers that >> are mostly caller-saved. >> >> Does this make sense? Should we do this? > > Well, the signal handler isn't necessarily going to clobber it, but the > delivery code already clobbers it when going to the init state. Can you point to that code? > >> We have _fpx_sw_bytes.xfeatures and _xstate._header.xfeatures. They >> appear to do more or less the same thing. > > I thought the _fpx_sw_bytes were only for 32-bit (or FXSAVE/FXRSTOR?). I thought they were everywhere. fpu/signal.c looks that way to me. I could be missing something -- this code isn't the most straightforward in the world. > >> Could we say that, for >> certain new features (e.g. PKRU), if they're not in >> _fpx_sw_bytes.xfeatures, then sigreturn will preserve the old content >> rather than copying it? User code that wants to change it on >> sigreturn would manually or the feature in to xfeatures, which would >> cause the feature to go to its init state if it's not in >> _header.xfeatures or to go into the saved state if it is in >> _header.xfeatures? > > I think we first need to decide on the state upon signal delivery. > Agreed. > A practial problem at the moment is that we always call XRSTOR (aka > copy_user_to_xregs()) with RFBM (aka 'mask') with all of the supported > xfeatures. So RFBM[i]=1 for each state, effectively. A state with > XSTATE_BV[i]=0 (aka header.xfeatures) and RFBM[i]=1 will init the state. > > We'd need to rig up the copy_user_to_xregs() to first read in > header.xfeatures and then or RFBM with it. Indeed. > > Not a huge deal, but something we want to think about, especially as it > pertains to the init/modified optimizations. Fair point. FWIW, I don't think that sigreturn performance matters all that much, so if we inadvertently lose some of the optimizations, it may not be the end of the world. I do wonder: are there any modern CPUs on which copy_user_to_xregs (as opposed to first copying to the task_struct buffer and then copy_kernel_to_xregs) is ever a win? It avoids clobbering a few cachelines and saves some memory bandwidth, but that may come at the cost of disabling the init/modified optimizations when the subsequent save on context switch hits a different VA/PA than the copy_user_to_xregs used. --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: rhashtable: Prevent spurious EBUSY errors on insertion
On Fri, Dec 18, 2015 at 12:07:08AM +0800, Xin Long wrote: > > I'm just wondering, why do not we handle the genuine double rehash > issue inside rhashtable? i mean it's just a temporary error that a > simple retry may fix it. Because a double rehash means that someone has cracked your hash function and there is no point in trying anymore. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] cgroup: clean up the kernel configuration menu nomenclature
On 2015/12/18 6:19, Johannes Weiner wrote: The config options for the different cgroup controllers use various terms: resource controller, cgroup subsystem, etc. Simplify this to "controller", which is clear enough in the cgroup context. Signed-off-by: Johannes Weiner --- init/Kconfig | 65 1 file changed, 26 insertions(+), 39 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 16840b4..ed324f5 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -958,23 +958,22 @@ menuconfig CGROUPS if CGROUPS config CGROUP_DEBUG - bool "Example debug cgroup subsystem" + bool "Example controller" But not all cgroup subsystems are controllers, which are debug, perf and cpuacct. I'm fine the other changes. -- 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 linux-next 2/5] mtd: spi-nor: fix Quad SPI mode support for Spansion, Micron and Macronix
On Mon, Dec 07, 2015 at 03:09:11PM +0100, Cyrille Pitchen wrote: > This patch reworks the support of Quad and Dual SPI protocols for Micron, > Spansion and Macronix Quad/Dual capable memories. Indeed, in the best > case, only Spansion memories are correctly supported by the current > spi-nor framework. ^^ Ah, so this is what I was struggling with at first. I agree that Micron looks broken. Quite possibly Macronix too. Unfortunately, I haven't had great test hardware for some of the quad modes. Especially not anything that supports generic SPI, and not completely on mainline. > 1 - Micron: > When their Quad SPI mode is enabled, Micron spi-nor memories expect all > commands to use the SPI 4-4-4 protocol. Also when the Dual SPI mode is > enabled, all commands must use the SPI 2-2-2 protocol. > > Before this patch, the spi-nor framework used to always enable the Quad > mode when the mode argument of spi_nor_scan() took the value SPI_NOR_QUAD. > That was not suited with drivers only supporting SPI 1-x-4 protocols but > not the 4-4-4 (e.g. the m25p80 driver). Also the SPI controller was not > notified about which SPI protocol to use to transfert command. We cannot > rely only on the op code: in Extended SPI mode the 0x6b command must use > the SPI 1-1-4 protocol whereas in Quad SPi mode the SPI 4-4-4 protocol > must be use instead. > > After this patch, the spi-nor framework uses the result of the > spi_nor_read_id() function to choose the right SPI protocol to be used. > If the reg_proto was set to SPI_PROTO_4_4_4, we already know that the Quad > SPI mode is already enabled and that the SPI controller supports the SPI > 4-4-4 protocol (otherwise it would have fail to read the JEDEC ID with the > 0xaf op code). For the very same reason, if the reg_proto was set to > SPI_PROTO_2_2_2, we already know that the Dual mode is already enabled and > that the SPI controller supports the SPI 2-2-2 protocol. > Otherwise we switch back to the Extended SPI protocol, which supports at > least the Fast Read commands: > - 1-1-1 (0x0b) > - Dual Output 1-1-2 (0x3b) > - Quad Output 1-1-4 (0x6b) > > We also safely set the number of dummy cycles to 8 for Fast Read commands > through the Volatile Configuration Register (VCR): some drivers (m25p80) > or SPI controllers only support a number of dummy cycles multiple of 8. > This number may have previouly been set to an unsupported value by an > early bootloader or at reset thanks to the Non-Volatile Configuration > Register. It's not clear to me how you're being safe with the dummy cycles at all. It seems like you're introducing new values that may be incompatible with drivers. That can be OK, but you have to give drivers a chance to opt-out... Maybe some kind of "host capability" flags? > Finally the XIP bit is always set in the VCR to disable the Continuous > Read mode as we don't want to care about mode cycles. > > 2 - Macronix: > When the QPI mode is enabled, all commands must use the SPI 4-4-4 protocol > and only the 0xeb op code is supported for Fast Read commands. > Before this patch, the spi-nor framework used to force the QPI mode but > used the 0x6b op code for Fast Read commands when the SPI controller > claims to support Quad SPI mode. > This patch uses the result of spi_nor_read_id() to guess whether the QPI > mode is both enable and supported by the SPI controller (otherwise it > would have failed to read the JEDEC ID with the 0xaf op code). > When the QPI mode is disabled, Macronix memories still support the > following Fast Read commands: > - 1-1-1 (0x0b) > - Dual Output 1-1-2 (0x3b) > - Quad Output 1-1-4 (0x6b) > So if the QPI mode has not already been enabled, there is not need to > enable it. We also avoid the 0xbb (Dual I/O 1-2-2) and 0xeb (Quad I/O > 1-4-4) op codes on purpose as we don't want to care about the value to set > in mode cycles not to enter the Continuous Read (Performance Enhance) > mode. > > As for Micron memories, the spi-nor framework now safely sets the number > of dummy cycles to 8 thanks to 2 volatile bits inside the Configuration > Register. > > 3 - Spansion: > As for Macronix, we avoid the 0xbb (Dual I/O 1-2-2) and 0xeb (Quad I/O > 1-4-4) op codes on purpose as we don't want to care about the value to set > in mode cycles not to enter in the Continuous Read mode. > > Besides, we only care about the Quad Enable bit inside the Configuration > Register (CR) when using Quad operations. In such a case, we first check > its state before trying to set it. Now we also notify the user about the > update of this non-volatile bit. > > We also check the Latency Code (LC) in CR to know the exact number of > dummy cycles to use when performing a Fast Read operation. Currently only > the 0x0b, 0x3b and 0x6b op codes are used to perform Fast Read operation > so the number of dummy cycles is always either 0 or 8. Hence no regression > should be introduced. > > Signed-off-by: Cyrille Pitchen > --- > drivers/mtd/spi-nor/spi-nor.c | 783 >
Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
On 12/17/2015 05:48 PM, Andy Lutomirski wrote: > I think that, for PKRU in particular, we want the default signal > handling behavior to be a bit unusual. > > When a signal is delivered, I think we should save the entire xstate > including PKRU. I see no reason to do anything other than that. Yep, agreed. But what about the register state when delivering a signal? Don't we set the registers to the init state? Do we need to preserve PKRU state instead of init'ing it? The init state _is_ nice here because it is permissive allows us to do something useful no matter what PKRU gets set to. But, if we leave the init state in place when entering a delivering a signal, we _can't_ decide to (by default at least) preserve the in-signal state. > When a signal returns (sigreturn is called), though, I think we should > *not* restore PKRU. To me, PKRU seems like a global per-thread state, > not something that signal handlers are likely to clobber and should > therefore have restored. It's also unusual in that it doesn't fit > into the usual xstate feature model of being a bunch of registers that > are mostly caller-saved. > > Does this make sense? Should we do this? Well, the signal handler isn't necessarily going to clobber it, but the delivery code already clobbers it when going to the init state. > We have _fpx_sw_bytes.xfeatures and _xstate._header.xfeatures. They > appear to do more or less the same thing. I thought the _fpx_sw_bytes were only for 32-bit (or FXSAVE/FXRSTOR?). > Could we say that, for > certain new features (e.g. PKRU), if they're not in > _fpx_sw_bytes.xfeatures, then sigreturn will preserve the old content > rather than copying it? User code that wants to change it on > sigreturn would manually or the feature in to xfeatures, which would > cause the feature to go to its init state if it's not in > _header.xfeatures or to go into the saved state if it is in > _header.xfeatures? I think we first need to decide on the state upon signal delivery. A practial problem at the moment is that we always call XRSTOR (aka copy_user_to_xregs()) with RFBM (aka 'mask') with all of the supported xfeatures. So RFBM[i]=1 for each state, effectively. A state with XSTATE_BV[i]=0 (aka header.xfeatures) and RFBM[i]=1 will init the state. We'd need to rig up the copy_user_to_xregs() to first read in header.xfeatures and then or RFBM with it. Not a huge deal, but something we want to think about, especially as it pertains to the init/modified optimizations. -- 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] mm: Introduce kernelcore=mirror option
On 2015/12/18 3:43, Luck, Tony wrote:
As Tony requested, we may need a knob to stop a fallback in "movable->normal",
later.
If the mirrored memory is small and the other is large,
I think we can both enable "non-mirrored -> normal" and "normal ->
non-mirrored".
Size of mirrored memory can be configured by software(EFI var).
So, having both is just overkill and normal->non-mirroed fallback is
meaningless considering
what the feature want to guarantee.
In the original removable usage we wanted to guarantee that Linux did not
allocate any
kernel objects in removable memory - because that would prevent later removal
of that
memory.
Mirror case is the same - we don't want to allocate kernel structures in
non-mirrored memory
because an uncorrectable error in one of them would crash the system.
But I think some users might like some flexibility here. If the system doesn't
have enough
memory for the kernel (non-movable or mirrored), then it seems odd to end up
crashing
the system at the point of memory exhaustion (a likely result ... the kernel
can try to reclaim
some pages from SLAB, but that might only return a few pages, if the shortage
continues
the system will perform poorly and eventually fail).
The whole point of removable memory or mirrored memory is to provide better
availability.
I'd vote for a mode where running out of memory for kernel results in a
warn_on_once("Ran out of mirrored/non-removable memory for kernel - now
allocating from all zones\n")
because I think most people would like the system to stay up rather than worry
about some future problem that may never happen.
Hmm...like this ?
sysctl.vm.fallback_mirror_memory = 0 // never fallback # default.
sysctl.vm.fallback_mirror_memory = 1 // the user memory may be allocated
from mirrored zone.
sysctl.vm.fallback_mirror_memory = 2 // usually kernel allocates memory
from mirrored zone before OOM.
sysctl.vm.fallback_mirror_memory = 3 // 1+2
However I believe my customer's choice is always 0, above implementation can be
done in a clean way.
(adding a flag to zones (mirrored or not) and controlling fallback zonelist
walk.)
BTW, we need this Taku's patch to make a progress. I think other devs should be
done in another
development cycle. What does he need to get your Acks ?
Thanks,
-Kame
--
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 linux-next 1/5] mtd: spi-nor: properly detect the memory when it boots in Quad or Dual mode
(Hit send too early; a few more comments)
On Mon, Dec 07, 2015 at 03:09:10PM +0100, Cyrille Pitchen wrote:
> drivers/mtd/spi-nor/spi-nor.c | 52
> +++
> include/linux/mtd/spi-nor.h | 23 +--
> 2 files changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 3b2460efc019..bf17736750c1 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -73,6 +73,11 @@ struct flash_info {
>
> #define JEDEC_MFR(info) ((info)->id[0])
>
> +struct read_id_config {
> + enum read_mode mode;
> + enum spi_protocol proto;
> +};
> +
> static const struct flash_info *spi_nor_match_id(const char *name);
>
> /*
> @@ -867,11 +872,16 @@ static const struct flash_info spi_nor_ids[] = {
> { },
> };
>
> -static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
> +static const struct flash_info *spi_nor_read_id(struct spi_nor *nor,
> + enum read_mode mode)
> {
> - int tmp;
> + int i, tmp;
> u8 id[SPI_NOR_MAX_ID_LEN];
> const struct flash_info *info;
> + static const struct read_id_config configs[] = {
> + {SPI_NOR_QUAD, SPI_PROTO_4_4_4},
> + {SPI_NOR_DUAL, SPI_PROTO_2_2_2}
> + };
>
> tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
> if (tmp < 0) {
> @@ -879,6 +889,34 @@ static const struct flash_info *spi_nor_read_id(struct
> spi_nor *nor)
> return ERR_PTR(tmp);
> }
>
> + /* Special case for Micron/Macronix qspi nor. */
> + if ((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) ||
> + (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00))
Is this specified anywhere, or is this just a heuristic, to guess
whether we're getting valid IDs? Do we know anything about what opcodes
look like ...
> + for (i = 0; i < ARRAY_SIZE(configs); ++i) {
> + if (configs[i].mode != mode)
> + continue;
> +
> + /* Set this protocol for all commands. */
> + nor->reg_proto = configs[i].proto;
> + nor->read_proto = configs[i].proto;
> + nor->write_proto = configs[i].proto;
> + nor->erase_proto = configs[i].proto;
> +
> + /*
> + * Multiple I/O Read ID only returns the Manufacturer ID
> + * (1 byte) and the Device ID (2 bytes). So we reset the
> + * remaining bytes.
> + */
Ugh, does that mean we get different IDs returned via the different
modes? That sounds like a disaster. What about all the flash that we
need 5+ bytes to differentiate? Just be glad we haven't come across any
Micron or Macronix like that yet?
> + memset(id, 0, sizeof(id));
> + tmp = nor->read_reg(nor, SPINOR_OP_MIO_RDID, id, 3);
Hmm, so you're passing implicit configuration data via the
nor->reg_proto field. So, spi-nor drivers now have to read that field
during every read_reg() invocation? Seems like either this should be:
(a) a driver hook/callback, so we can just reconfigure a handful of
times or
(b) part of a parameter that gets passed as part of the function
signature
> + if (tmp < 0) {
> + dev_dbg(nor->dev,
> + "error %d reading JEDEC ID Multi I/O\n",
> + tmp);
> + return ERR_PTR(tmp);
> + }
> + }
> +
> for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
> info = _nor_ids[tmp];
> if (info->id_len) {
[...]
Brian
--
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 0/3] VFIO: capability chains
On 11/24/2015 07:43 AM, Alex Williamson wrote: Please see the commit log and comments in patch 1 for a general explanation of the problems that this series tries to address. The general problem is that we have several cases where we want to expose variable sized information to the user, whether it's sparse mmaps for a region, as implemented here, or DMA mapping ranges of an IOMMU, or reserved MSI mapping ranges, etc. Extending data structures is hard; extending them to report variable sized data is really hard. After considering several options, I think the best approach is to copy how PCI does capabilities. This allows the ioctl to only expose the capabilities that are relevant for them, avoids data structures that are too complicated to parse, and avoids creating a new ioctl each time we think of something else that we'd like to report. This method also doesn't preclude extensions to the fixed structure since the offset of these capabilities is entirely dynamic. Comments welcome, I'll also follow-up to the QEMU and KVM lists with an RFC making use of this for mmaps skipping over the MSI-X table. Thanks, Out of curiosity - could this information be exposed to the userspace via /sys/bus/pci/devices/:xx:xx:x/vfio_? It seems not to change after vfio_pci driver is bound to a device. Alex --- Alex Williamson (3): vfio: Define capability chains vfio: Define sparse mmap capability for regions vfio/pci: Include sparse mmap capability for MSI-X table regions drivers/vfio/pci/vfio_pci.c | 101 +++ include/uapi/linux/vfio.h | 53 ++- 2 files changed, 152 insertions(+), 2 deletions(-) -- 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/ -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] x86: test early command-line code
Hi Dave,
[auto build test ERROR on v4.4-rc5]
[also build test ERROR on next-20151217]
[cannot apply to tip/x86/core]
url:
https://github.com/0day-ci/linux/commits/Dave-Hansen/x86-pass-in-size-to-early-cmdline-parsing/20151218-060427
config: i386-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
arch/x86/kernel/check.c: In function 'test_early_cmdline':
>> arch/x86/kernel/check.c:170:19: error: storage class specified for parameter
>> '__initcall_test_early_cmdline7'
late_initcall(test_early_cmdline);
^
arch/x86/kernel/check.c:170:1: error: parameter
'__initcall_test_early_cmdline7' is initialized
late_initcall(test_early_cmdline);
^
arch/x86/kernel/check.c:170:1: warning: '__used__' attribute ignored
[-Wattributes]
>> arch/x86/kernel/check.c:170:19: error: section attribute not allowed for
>> '__initcall_test_early_cmdline7'
late_initcall(test_early_cmdline);
^
arch/x86/kernel/check.c:170:152: error: expected declaration specifiers
before ';' token
arch/x86/kernel/check.c:169:5: error: old-style parameter declarations in
prototyped function definition
int test_early_cmdline(void)
^
arch/x86/kernel/check.c:170:152: error: expected '{' at end of input
arch/x86/kernel/check.c:170:152: warning: control reaches end of non-void
function [-Wreturn-type]
vim +/__initcall_test_early_cmdline7 +170 arch/x86/kernel/check.c
164 return 0;
165 }
166 device_initcall(start_periodic_check_for_corruption);
167
168 #ifdef CONFIG_X86_TEST_EARLY_CMDLINE
169 int test_early_cmdline(void)
> 170 late_initcall(test_early_cmdline);
171 #endif /* CONFIG_X86_TEST_EARLY_CMDLINE */
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?
On Thu, Dec 17, 2015 at 5:16 PM, Srinivas Pandruvada wrote: > On Thu, 2015-12-17 at 17:07 -0800, Nish Aravamudan wrote: >> On Thu, Dec 17, 2015 at 4:51 PM, Srinivas Pandruvada >> wrote: >> > On Thu, 2015-12-17 at 15:38 -0800, Nish Aravamudan wrote: >> > > [Starting a new thread from https://lkml.org/lkml/2015/12/15/663, >> > > as >> > > now my laptop is displaying values in the sysfs *raw* files.] >> > > >> > > So I'm trying to understand exactly how the hid-sensor-accel-3d >> > > driver works. >> > > >> > > If I turn up debugging, when I `cat >> > > /sys/bus/iio/devices/device*/*raw*`, I see "iio iio:device3: >> > > accel_3d_proc_event" and I think that means that >> > > hid_sensor_push_data() is getting called. >> > > >> > > But read()'s on /dev/iio:device3 never produces anything, which >> > > is >> > > what iio-sensor-proxy uses to translate events to dbus. >> > > >> > > Is it expected that the dev-node is "silent"? Just trying to >> > > understand if an extension to the driver to support a chardev >> > > based >> > > output is appropriate, or if iio-sensor-proxy needs to be changed >> > > to >> > > handle this device. >> > >> > You are saying there is some regression. This used to work and now >> > it >> > doesn't work. Is raw values are displayed correctly, when you do >> > "cat"? >> > If cat of raw values is working then power on of sensors is >> > working. >> >> Sorry, I was unclear. I don't know if this is a regression. I can try >> going back to an older kernel to see if the /dev/iio:device* files >> produced any output. >> >> Yes, the *raw* files in sysfs are producing output, that is changing >> as I move the laptop around. But the /dev/ nodes seem to produce no >> output (I'm still reading through the driver code to understand where >> that data should be coming from. >> >> > Turn on HID debug prints. If it is regression we can do git bisect. >> > Any ACPI or PM changes can break this. Usually there will be GPIOs >> > which will be involved in power on, where ACPI comes into play. >> > This >> > will be done by i2c-hid. There are some prints in i2c-hid which can >> > be >> > enabled also. >> >> Ok, I will try this, as well. >> > > Try increasing in_accel_sampling_frequency > echo 100 > in_accel_sampling_frequency > Adjust hysteresis to a low value > echo 0 > in_accel_hysteresis > These values are very vendor specific. Adjusting the values in this way didn't seem to make any difference. Also, `cat in_accel_hysteresis` gave EINVAL, but I was able to echo 0 to it. -Nish -- 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] dmaengine: dw: fix potential memory leak in dw_dma_parse_dt()
On 17-12-15, 23:30, Mans Rullgard wrote: > If the "dma-channels" DT property is missing, the dw_dma_parse_dt() > function return NULL, but not before allocating memory for a struct > dw_dma_platform_data through devres. If the device supports parameter > detection, the probe still succeeds and the allocated memory is not > released until the device is removed. > > Fix this by deferring the allocation until after checking the > "dma-channels" property. > > Signed-off-by: Mans Rullgard > --- > This has only been compile-tested as I have no suitable hardware. > --- > drivers/dma/dw/platform.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) Acked-by: Viresh Kumar -- viresh -- 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 v10 1/4] dt-binding:Documents of the mbigen bindings
Hi Mark:
在 2015/12/17 21:52, Mark Rutland 写道:
> On Thu, Dec 17, 2015 at 07:56:34PM +0800, MaJun wrote:
>> From: Ma Jun
[...]
>> +- compatible: Should be "hisilicon,mbigen-v2"
>> +
>> +- reg: Specifies the base physical address and size of the Mbigen
>> + registers.
>> +
>> +- interrupt controller: Identifies the node as an interrupt controller
>> +
>> +- msi-parent: Specifies the MSI controller this mbigen use.
>> + For more detail information,please refer to the generic msi-parent
>> binding in
>> + Documentation/devicetree/bindings/interrupt-controller/msi.txt.
>> +
>> +- num-msis:Specifies the total number of interrupt this device has.
>
> Is this the number of pins implemented? Or the number of pins that are
> in use?
>
> The latter feels like something we can derive.
num-msis means the total number of pins implemented.
>
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> + interrupt source. The value must be 2.
>> +
>> + The 1st cell is hardware pin number of the interrupt.This number is local
>> to
>> + each mbigen chip and in the range from 0 to the maximum interrupts number
>> + of the mbigen.
>
> Just to check: 0 - 63 represent the "reserved" pins, yes?
Yes, you are right.
>
> Other than those questions, this looks good to me.
Do i need to post a new patch to update these two questions?
Thanks!
MaJun
>
> Thanks,
> Mark.
>
>> +
>> + The 2nd cell is the interrupt trigger type.
>> +The value of this cell should be:
>> +1: rising edge triggered
>> +or
>> +4: high level triggered
>> +
>> +Examples:
>> +
>> +mbigen_device_gmac:intc {
>> +compatible = "hisilicon,mbigen-v2";
>> +reg = <0x0 0xc008 0x0 0x1>;
>> +interrupt-controller;
>> +msi-parent = <_dsa 0x40b1c>;
>> +num-msis = <9>;
>> +#interrupt-cells = <2>;
>> +};
>> +
>> +Devices connect to mbigen required properties:
>> +
>> +-interrupt-parent: Specifies the mbigen device node which device connected.
>> +
>> +-interrupts:Specifies the interrupt source.
>> + For the specific information of each cell in this property,please refer to
>> + the "interrupt-cells" description mentioned above.
>> +
>> +Examples:
>> +gmac0: ethernet@c208 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +reg = <0 0xc208 0 0x2>,
>> + <0 0xc000 0 0x1000>;
>> +interrupt-parent = <_device_gmac>;
>> +interrupts =<656 1>,
>> +<657 1>;
>> +};
>> +
>> --
>> 1.7.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: Add top down metrics to perf stat v2
Thanks for testing. On Thu, Dec 17, 2015 at 03:31:30PM -0800, Stephane Eranian wrote: > I would not add a --topdown option but instead a --metric option with > arguments > such that other metrics could be added later: > >$ perf stat --metrics topdown -I 1000 -a sleep 100 > > If you do this, you do not need the --metric-only option The --metric-only option is useful with other metrics too. For example to get concise (and plottable) IPC or TSX abort statistics. See the examples in the original commit. However could make --topdown default to --metric-only and add an option to turn it off. Yes that's probably a better default for more people, although some people could be annoyed by the wide output. > The double --topdown is confusing. Ok. I was thinking of changing it and adding an extra argument for the "ignore threshold" behavior. That would also make it more extensible if we ever add Level 2. > > Why force --per-core when HT is on. I know you you need to aggregate > per core, but > you could still display globally. And then if user requests > --per-core, then display per core. Global TopDown doesn't make much sense. Suppose you have two programs running on different cores, one frontend bound and one backend bound. What would the union of the two mean? And you may well end up with sums of ratios which are >100%. The only exception where it's useful is for the single threaded case (like the toplev --single-thread) option. However it is something ugly and difficult because the user would need to ensure that there is nothing active on the sibling thread. So I left it out. > Same if user specifies --per-socket. I know this requires some more > plumbing inside perf > but it would be clearer and simpler to interpret to users. Same problem as above. > > One bug I found when testing is that if you do with HT-on: > > $ perf stat -a --topdown -I 1000 --metric-only sleep 100 > Then you get data for frontend and backend but nothing for retiring or > bad speculation. You see all the columns, but no data in some? That's intended: the percentage is only printed when it crosses a threshold. That's part of the top down specificatio. > I suspect it is because you expect --metric-only to be used only when > you have the > double --topdown. That's why I think this double topdown is confusing. If you > do > as I suggest, it will be much simpler. It works fine with single topdown as far as I can tell. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- 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 linux-next 1/5] mtd: spi-nor: properly detect the memory when it boots in Quad or Dual mode
Hi Cyrille,
On Mon, Dec 07, 2015 at 03:09:10PM +0100, Cyrille Pitchen wrote:
> The quad (or dual) mode of a spi-nor memory may be enabled at boot time by
> non-volatile bits in some setting register. Also such a mode may have
> already been enabled at early stage by some boot loader.
>
> Hence, we should not guess the spi-nor memory is always configured for the
> regular SPI 1-1-1 protocol.
>
> Micron and Macronix memories, once their Quad (or dual for Micron) mode
> enabled, no longer process the regular JEDEC Read ID (0x9f) command but
> instead reply to a new command: JEDEC Read ID Multiple I/O (0xaf).
> Besides, in Quad mode both memory manufacturers expect ALL commands to
> use the SPI 4-4-4 protocol. For Micron memories, enabling their Dual mode
> implies to use the SPI 2-2-2 protocol for ALL commands.
>
> Signed-off-by: Cyrille Pitchen
> ---
> drivers/mtd/spi-nor/spi-nor.c | 52
> +++
> include/linux/mtd/spi-nor.h | 23 +--
> 2 files changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 3b2460efc019..bf17736750c1 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -73,6 +73,11 @@ struct flash_info {
>
> #define JEDEC_MFR(info) ((info)->id[0])
>
> +struct read_id_config {
> + enum read_mode mode;
> + enum spi_protocol proto;
> +};
> +
> static const struct flash_info *spi_nor_match_id(const char *name);
>
> /*
> @@ -867,11 +872,16 @@ static const struct flash_info spi_nor_ids[] = {
> { },
> };
>
> -static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
> +static const struct flash_info *spi_nor_read_id(struct spi_nor *nor,
> + enum read_mode mode)
It's unclear what you're trying to do with the 'read_mode' enum now.
(Admittedly it may not be clear in the current code either, given the
confusion we already have over Micron support.)
Would you care to document it better?
> {
> - int tmp;
> + int i, tmp;
> u8 id[SPI_NOR_MAX_ID_LEN];
> const struct flash_info *info;
> + static const struct read_id_config configs[] = {
> + {SPI_NOR_QUAD, SPI_PROTO_4_4_4},
> + {SPI_NOR_DUAL, SPI_PROTO_2_2_2}
> + };
>
> tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
> if (tmp < 0) {
> @@ -879,6 +889,34 @@ static const struct flash_info *spi_nor_read_id(struct
> spi_nor *nor)
> return ERR_PTR(tmp);
> }
>
> + /* Special case for Micron/Macronix qspi nor. */
> + if ((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) ||
> + (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00))
> + for (i = 0; i < ARRAY_SIZE(configs); ++i) {
> + if (configs[i].mode != mode)
> + continue;
> +
> + /* Set this protocol for all commands. */
> + nor->reg_proto = configs[i].proto;
> + nor->read_proto = configs[i].proto;
> + nor->write_proto = configs[i].proto;
> + nor->erase_proto = configs[i].proto;
Are these all fully independent? Do we really need 4 fields for this?
> +
> + /*
> + * Multiple I/O Read ID only returns the Manufacturer ID
> + * (1 byte) and the Device ID (2 bytes). So we reset the
> + * remaining bytes.
> + */
> + memset(id, 0, sizeof(id));
> + tmp = nor->read_reg(nor, SPINOR_OP_MIO_RDID, id, 3);
> + if (tmp < 0) {
> + dev_dbg(nor->dev,
> + "error %d reading JEDEC ID Multi I/O\n",
> + tmp);
> + return ERR_PTR(tmp);
> + }
> + }
> +
> for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
> info = _nor_ids[tmp];
> if (info->id_len) {
> @@ -1178,11 +1216,17 @@ int spi_nor_scan(struct spi_nor *nor, const char
> *name, enum read_mode mode)
> if (ret)
> return ret;
>
> + /* Reset SPI protocol for all commands */
> + nor->erase_proto = SPI_PROTO_1_1_1;
> + nor->read_proto = SPI_PROTO_1_1_1;
> + nor->write_proto = SPI_PROTO_1_1_1;
> + nor->reg_proto = SPI_PROTO_1_1_1;
> +
> if (name)
> info = spi_nor_match_id(name);
> /* Try to auto-detect if chip name wasn't specified or not found */
> if (!info)
> - info = spi_nor_read_id(nor);
> + info = spi_nor_read_id(nor, mode);
> if (IS_ERR_OR_NULL(info))
> return -ENOENT;
>
> @@ -1193,7 +1237,7 @@ int
Re: [PATCH v2] PM / OPP: Fix parsing of opp-microvolt and opp-microamp properties
On 17-12-15, 19:04, Bartlomiej Zolnierkiewicz wrote:
> Commit 01fb4d3c39d3 ("PM / OPP: Parse 'opp--'
> bindings") broke support for parsing standard opp-microvolt and
> opp-microamp properties. Fix it by setting 'name' string to
> proper value for !prop cases.
>
> Cc: Viresh Kumar
> Cc: Lee Jones
> Cc: Rafael J. Wysocki
> Fixes: 01fb4d3c39d3 ("PM / OPP: Parse 'opp-- 'bindings")
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> v2:
> - rework the changes as requested by Viresh
Acked-by: Viresh Kumar
--
viresh
--
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/
Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
Hi all- I think that, for PKRU in particular, we want the default signal handling behavior to be a bit unusual. When a signal is delivered, I think we should save the entire xstate including PKRU. I see no reason to do anything other than that. When a signal returns (sigreturn is called), though, I think we should *not* restore PKRU. To me, PKRU seems like a global per-thread state, not something that signal handlers are likely to clobber and should therefore have restored. It's also unusual in that it doesn't fit into the usual xstate feature model of being a bunch of registers that are mostly caller-saved. Does this make sense? Should we do this? We have _fpx_sw_bytes.xfeatures and _xstate._header.xfeatures. They appear to do more or less the same thing. Could we say that, for certain new features (e.g. PKRU), if they're not in _fpx_sw_bytes.xfeatures, then sigreturn will preserve the old content rather than copying it? User code that wants to change it on sigreturn would manually or the feature in to xfeatures, which would cause the feature to go to its init state if it's not in _header.xfeatures or to go into the saved state if it is in _header.xfeatures? Other means of signaling this could work, too. It's not all that much code, I think. --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 08/10] bpf samples: Add utils.[ch] for using BPF
On 2015/12/18 7:11, Alexei Starovoitov wrote:
On Thu, Dec 17, 2015 at 05:23:12AM +, Wang Nan wrote:
We are going to uses libbpf to replace old libbpf.[ch] and
bpf_load.[ch]. This is the first patch of this work. In this patch,
several macros and helpers in libbpf.[ch] and bpf_load.[ch] are
merged into utils.[ch]. utils.[ch] utilizes libbpf in tools/lib to
deal with BPF related things. They would be compiled after Makefile
changes.
Signed-off-by: Wang Nan
...
+#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
+
+static inline void * __must_check ERR_PTR(long error_)
+{
+ return (void *) error_;
+}
+
+static inline long __must_check PTR_ERR(__force const void *ptr)
+{
+ return (long) ptr;
+}
+
+static inline bool __must_check IS_ERR(__force const void *ptr)
+{
+ return IS_ERR_VALUE((unsigned long)ptr);
+}
why copy paste this? I don't see the code that uses that.
This is a limitation in tools/lib/bpf/libbpf.h, which has a #include
in its header.
libbpf.h requires this include because its API uses ERR_PTR() to encode
error code.
For example, when calling bpf_object__open(), caller should use IS_ERR()
to check its
return value instead of compare with NULL, and use PTR_ERR() to retrive
error number.
However, linux/err.h is not a part of uapi. To make libbpf work, one has
to create its
own err.h.
Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(), in libbpf itself.
+ bpf_object__for_each_program(prog, obj) {
+ const char *event = bpf_program__title(prog, false);
+ int fd, err;
+
+ LIBBPF_PTR_ASSERT(event, goto errout);
+ __LIBBPF_ASSERT(fd = bpf_program__nth_fd(prog, 0),
+ >= 0,
+ goto errout);
+
+ if (strncmp(event, "kprobe/", 7) == 0)
+ err = create_kprobes(fd, event + 7, true);
+ else if (strncmp(event, "kretprobe/", 10) == 0)
+ err = create_kprobes(fd, event + 10, false);
I have a feeling that all bpf+socket, tcbpf1_kernc and trace_output_*.c
are broken, since I don't see a code that attaches programs to sockets
and to perf_event.
How did you test it?
I tested all samples (except tcbpf1_kern, because it is loaded by tc but tc
has not switched to libbpf) in my environment. They are okay for me. There's
no socket attaching code in this patchset because they are in sockex?_user.c
like this:
obj = load_bpf_file(filename);
if (!obj)
return 1;
...
prog_fd = get_prog_fd(obj, 0);
...
sock = open_raw_sock("lo");
assert(setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, _fd,
sizeof(prog_fd)) == 0);
And I don't touch the setsockopt in all patches.
diff --git a/samples/bpf/utils.h b/samples/bpf/utils.h
new file mode 100644
index 000..5962a68
--- /dev/null
+++ b/samples/bpf/utils.h
@@ -0,0 +1,217 @@
+#ifndef __SAMPELS_UTILS_H
+#define __SAMPELS_UTILS_H
+
+#include
+#include
+
+/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
+
+#define BPF_ALU64_REG(OP, DST, SRC)\
+ ((struct bpf_insn) {\
+ .code = BPF_ALU64 | BPF_OP(OP) | BPF_X,\
+ .dst_reg = DST, \
+ .src_reg = SRC, \
+ .off = 0, \
+ .imm = 0 })
this probably belongs in tools/lib/bpf/bpf.h instead of samples.
Orignally they are macros defined in linux/filter.h. We have 3
filter.h in kernel tree:
include/linux/filter.h
include/uapi/linux/filter.h
tools/include/linux/filter.h
These macros belong to include/linux/filter.h, not part of uapi,
so we have to do things like what we have done for
tools/include/linux/filter.h.
What about moving them into include/uapi/linux/filter.h ? Then
normal user programs like those in samples/bpf can access
them easier.
The whole set depends on changes in perf/core tree, but
in net-next we have extra commit 30b50aa612018, so I don't see an easy way
to route this patch without creating across-tree merge conflicts during
merge window.
I'd suggest to apply all required work to tools/lib/bpf/ into perf/core
and leave samples/bpf/ after merge window.
Good suggestion.
I'll resend them after the PowerPC building breakage fixing is
collected.
Thank you.
--
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] netconsole: Initialize after all core networking drivers
On Thursday 12/17 at 17:08 -0800, Eric Dumazet wrote: > On Thu, 2015-12-17 at 15:52 -0800, Calvin Owens wrote: > > With built-in netconsole and IXGBE, configuring netconsole via the kernel > > cmdline results in the following panic at boot: > > > > netpoll: netconsole: device eth0 not up yet, forcing it > > usb 2-1: new high-speed USB device number 2 using ehci-pci > > ixgbe :03:00.0: registered PHC device on eth0 > > BUG: unable to handle kernel NULL pointer dereference at > > 0810 > > > > Call Trace: > > [] ? vxlan_get_rx_port+0x41/0xa0 > > [] ixgbe_open+0x4e8/0x540 > > [] __dev_open+0xac/0x120 > > [] dev_open+0x36/0x70 > > [] netpoll_setup+0x23c/0x300 > > [] ? netpoll_parse_options+0x19a/0x200 > > [] ? option_setup+0x1f/0x1f > > [] init_netconsole+0xda/0x262 > > [] ? option_setup+0x1f/0x1f > > [] do_one_initcall+0x88/0x1b0 > > [] kernel_init_freeable+0x14a/0x1e3 > > [] ? do_early_param+0x8c/0x8c > > [] ? rest_init+0x80/0x80 > > [] kernel_init+0xe/0xe0 > > [] ret_from_fork+0x3f/0x70 > > [] ? rest_init+0x80/0x80 > > > > This happens because IXGBE assumes that vxlan has already been initialized. > > The cleanest way to fix this is to just initialize netconsole after all the > > other core networking stuff has completed. > > > > Signed-off-by: Calvin Owens > > --- > > drivers/net/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/net/Makefile b/drivers/net/Makefile > > index 900b0c5..31557d0 100644 > > --- a/drivers/net/Makefile > > +++ b/drivers/net/Makefile > > @@ -15,7 +15,6 @@ obj-$(CONFIG_MACVTAP) += macvtap.o > > obj-$(CONFIG_MII) += mii.o > > obj-$(CONFIG_MDIO) += mdio.o > > obj-$(CONFIG_NET) += Space.o loopback.o > > -obj-$(CONFIG_NETCONSOLE) += netconsole.o > > obj-$(CONFIG_PHYLIB) += phy/ > > obj-$(CONFIG_RIONET) += rionet.o > > obj-$(CONFIG_NET_TEAM) += team/ > > @@ -26,6 +25,7 @@ obj-$(CONFIG_VXLAN) += vxlan.o > > obj-$(CONFIG_GENEVE) += geneve.o > > obj-$(CONFIG_NLMON) += nlmon.o > > obj-$(CONFIG_NET_VRF) += vrf.o > > +obj-$(CONFIG_NETCONSOLE) += netconsole.o > > > > # > > # Networking Drivers > > > Looks odd to rely on link order, but we might already rely on this... > > Have you considered using device_initcall() instead of late_initcall() > in vxlan ? I'll look. As-is though, I think a similar problem would happen if you tried to use a virtio_net device with netconsole= cmdline (although that is admittedly a bizarre use case). The Makefile patch seemed like the best way to ensure this can't recur elsewhere. > In any case, a comment would really be good to avoid future mistakes. Good point, I'll add something. -- 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] netconsole: Initialize after all core networking drivers
On Thursday 12/17 at 17:10 -0800, Stephen Hemminger wrote: > On Thu, 17 Dec 2015 15:52:39 -0800 > Calvin Owens wrote: > > > With built-in netconsole and IXGBE, configuring netconsole via the kernel > > cmdline results in the following panic at boot: > > > > netpoll: netconsole: device eth0 not up yet, forcing it > > usb 2-1: new high-speed USB device number 2 using ehci-pci > > ixgbe :03:00.0: registered PHC device on eth0 > > BUG: unable to handle kernel NULL pointer dereference at > > 0810 > > > > Call Trace: > > [] ? vxlan_get_rx_port+0x41/0xa0 > > [] ixgbe_open+0x4e8/0x540 > > [] __dev_open+0xac/0x120 > > [] dev_open+0x36/0x70 > > [] netpoll_setup+0x23c/0x300 > > [] ? netpoll_parse_options+0x19a/0x200 > > [] ? option_setup+0x1f/0x1f > > [] init_netconsole+0xda/0x262 > > [] ? option_setup+0x1f/0x1f > > [] do_one_initcall+0x88/0x1b0 > > [] kernel_init_freeable+0x14a/0x1e3 > > [] ? do_early_param+0x8c/0x8c > > [] ? rest_init+0x80/0x80 > > [] kernel_init+0xe/0xe0 > > [] ret_from_fork+0x3f/0x70 > > [] ? rest_init+0x80/0x80 > > > > This happens because IXGBE assumes that vxlan has already been initialized. > > The cleanest way to fix this is to just initialize netconsole after all the > > other core networking stuff has completed. > > > > Signed-off-by: Calvin Owens > > Fixing this by changing Makefile order is too fragile. > You are depending on the fact that Makefile order determines link order > and that determines initialization order. Down that path demons lie. Hmm, include/linux/init.h explicitly states that "Ordering inside the subsections is determined by link order", and has since before the beginning of the history in Git. I agree it seems magic/scary, but as Eric says I would imagine this behavior is relied upon in other places. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[lkp] [rhashtable] f9f51b8070: INFO: suspicious RCU usage. ]
FYI, we noticed the below changes on
https://github.com/0day-ci/linux
Herbert-Xu/rhashtable-Fix-walker-list-corruption/20151216-164833
commit f9f51b8070be3e829100614a7372b219723b864f ("rhashtable: Fix walker list
corruption")
[8.933376] ===
[8.933376] ===
[8.934629] [ INFO: suspicious RCU usage. ]
[8.934629] [ INFO: suspicious RCU usage. ]
[8.935941] 4.4.0-rc3-00995-gf9f51b8 #2 Not tainted
[8.935941] 4.4.0-rc3-00995-gf9f51b8 #2 Not tainted
[8.937494] ---
[8.937494] ---
[8.938818] lib/rhashtable.c:504 suspicious rcu_dereference_protected()
usage!
[8.938818] lib/rhashtable.c:504 suspicious rcu_dereference_protected()
usage!
[8.941705]
[8.941705] other info that might help us debug this:
[8.941705]
[8.941705]
[8.941705] other info that might help us debug this:
[8.941705]
[8.944161]
[8.944161] rcu_scheduler_active = 1, debug_locks = 0
[8.944161]
[8.944161] rcu_scheduler_active = 1, debug_locks = 0
[8.946244] 1 lock held by swapper/0/1:
[8.946244] 1 lock held by swapper/0/1:
[8.947463] #0:
[8.947463] #0: (
(&(>lock)->rlock&(>lock)->rlock){+.+...}){+.+...}, at: , at:
[] rhashtable_walk_init+0x70/0x150
[] rhashtable_walk_init+0x70/0x150
[8.950428]
[8.950428] stack backtrace:
[8.950428]
[8.950428] stack backtrace:
[8.951770] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.4.0-rc3-00995-gf9f51b8 #2
[8.951770] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.4.0-rc3-00995-gf9f51b8 #2
[8.954245] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[8.954245] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[8.956973] 0001
[8.956973] 0001 880078393d30 880078393d30
81493238 81493238 88007838c040 88007838c040
[8.959333] 880078393d60
[8.959333] 880078393d60 8112cb9f 8112cb9f
880078393da0 880078393da0 83e9d6c0 83e9d6c0
[8.961684] 83e9d7f0
[8.961684] 83e9d7f0 880061720e00 880061720e00
880078393d90 880078393d90 814b89c8 814b89c8
[8.964148] Call Trace:
[8.964148] Call Trace:
[8.964955] [] dump_stack+0x7c/0xb4
[8.964955] [] dump_stack+0x7c/0xb4
[8.966728] [] lockdep_rcu_suspicious+0x14f/0x1c0
[8.966728] [] lockdep_rcu_suspicious+0x14f/0x1c0
[8.968753] [] rhashtable_walk_init+0x138/0x150
[8.968753] [] rhashtable_walk_init+0x138/0x150
[8.970567] [] test_bucket_stats+0x22/0x17d
[8.970567] [] test_bucket_stats+0x22/0x17d
[8.972682] [] test_rhashtable+0xe0/0x12ac
[8.972682] [] test_rhashtable+0xe0/0x12ac
[8.974746] [] ? get_random_bytes+0x2b/0x40
[8.974746] [] ? get_random_bytes+0x2b/0x40
[8.976467] [] ? bucket_table_alloc+0x173/0x280
[8.976467] [] ? bucket_table_alloc+0x173/0x280
[8.978548] [] test_rht_init+0x10f/0x523
[8.978548] [] test_rht_init+0x10f/0x523
[8.980179] [] ? test_rhashtable+0x12ac/0x12ac
[8.980179] [] ? test_rhashtable+0x12ac/0x12ac
[8.982424] [] do_one_initcall+0x16b/0x248
[8.982424] [] do_one_initcall+0x16b/0x248
[8.984208] [] kernel_init_freeable+0x1c4/0x2b8
[8.984208] [] kernel_init_freeable+0x1c4/0x2b8
[8.986165] [] ? rest_init+0x200/0x200
[8.986165] [] ? rest_init+0x200/0x200
[8.987925] [] kernel_init+0x11/0x190
[8.987925] [] kernel_init+0x11/0x190
[8.989608] [] ret_from_fork+0x3f/0x70
[8.989608] [] ret_from_fork+0x3f/0x70
[8.991270] [] ? rest_init+0x200/0x200
[8.991270] [] ? rest_init+0x200/0x200
Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.4.0-rc3 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/17/2015 8:06 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 3:53 PM, Måns Rullgård wrote:
Julian Margetson writes:
> On 12/17/2015 2:51 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 1:59 PM, Måns Rullgård wrote:
Julian Margetson writes:
> I have been running my machine mostly configured for pciex1 thus with
> the sata_dwc disabled.
> The changes to sata_dwc-460ex do cause an oops.
> I will try to give more detailed info over this weekend .
The driver as is upstream would do that since it unconditionally
dereferences a null pointer in the probe function. My patch fixes that
as a side-effect.
>>> patching file drivers/ata/Kconfig
>>>
>>> Hunk #1 FAILED at 296.
>> [...]
>>
>>> root@julian-VirtualBox:/usr/src/linux-3.18.25#
>> The patch is against 4.4-rc5.
>>
>CC drivers/ata/sata_dwc_460ex.o
>
> drivers/ata/sata_dwc_460ex.c:198:15: error: variable
> ‘sata_dwc_dma_dws’ has initializer but incomplete type
>
>static struct dw_dma_slave sata_dwc_dma_dws = {
> ^
It builds, albeit with an unrelated warning, using the attached config.
Maybe there's a missing config dependency somewhere.
>>> I am attempting to cross compile under Ubuntu 14.04 X86 in Virtualbox
>>> with your .config.
>>> 4.4.0-rc5 builds ok with no patches applied .
>>> Once your patch is applied it fails to build .
>>>
>>> CC drivers/ata/sata_dwc_460ex.o
>>> drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’ has
>>> initializer but incomplete type
>>> static struct dw_dma_slave sata_dwc_dma_dws = {
>>> ^
>> Bizarre. This is what it looks like here:
>>
>> mru@unicorn:/tmp/linux-sata$ git status
>> On branch sata-dwc
>> nothing to commit, working directory clean
>> mru@unicorn:/tmp/linux-sata$ git describe
>> v4.4-rc5
>> mru@unicorn:/tmp/linux-sata$ sha1sum
>> /tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
>> e300971aa483390f82de2e9120dc16e460e74feb
>> /tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
>> mru@unicorn:/tmp/linux-sata$ git am
>> /tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
>> Applying: ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
>> mru@unicorn:/tmp/linux-sata$ sha1sum .config
>> 4e7615b8d2fa9a1c4b4ae9ffc363aefcaf3789ca .config
>> mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
>> CROSS_COMPILE=powerpc64-none-linux-gnu- oldconfig
>>HOSTCC scripts/basic/fixdep
>>HOSTCC scripts/kconfig/conf.o
>>SHIPPED scripts/kconfig/zconf.tab.c
>>SHIPPED scripts/kconfig/zconf.lex.c
>>SHIPPED scripts/kconfig/zconf.hash.c
>>HOSTCC scripts/kconfig/zconf.tab.o
>>HOSTLD scripts/kconfig/conf
>> scripts/kconfig/conf --oldconfig Kconfig
>> #
>> # configuration written to .config
>> #
>> mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
>> CROSS_COMPILE=powerpc64-none-linux-gnu- drivers/ata/sata_dwc_460ex.o
>> scripts/kconfig/conf --silentoldconfig Kconfig
[...]
>>CC drivers/ata/sata_dwc_460ex.o
>> drivers/ata/sata_dwc_460ex.c: In function 'dma_dwc_xfer_setup':
>> drivers/ata/sata_dwc_460ex.c:383:20: warning: cast from pointer to integer
>> of different size [-Wpointer-to-int-cast]
>>dma_addr_t addr = (dma_addr_t)>sata_dwc_regs->dmadr;
>> ^
>> mru@unicorn:/tmp/linux-sata$
>>
>> Patch file and .config attached.
>>
>> Looking into that warning, I doubt it works as is, but that's not caused
>> by my patch. I can try to come up with a fix, but again, I can't test it.
>>
> I am using
>
> make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
Shouldn't matter since the compiler flags include -m32, and I only had a
powerpc64 toolchain built. Anyhow, I built a 32-bit toolchain and it
still builds.
Just to make sure you applied the patch correctly:
mru@unicorn:/tmp/linux-sata$ sha1sum drivers/ata/sata_dwc_460ex.c
c8a7927840aade75ac62b04a2c9acc8335a34d6f drivers/ata/sata_dwc_460ex.c
Digging deeper into that warning, it is clearly a bug which has always
been there. The reason it ever worked appears to be that the 460EX has
a dedicated DMA unit hard-wired to the SATA controller ignoring that
address. The situation is similar on my hardware.
--
Måns Rullgård
--
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/
