Re: [PATCH] x86: vdso32/syscall.S: do not load __USER32_DS to %ss
On 03/25/2015 10:28 AM, Ingo Molnar wrote: * Andy Lutomirski l...@amacapital.net wrote: Now we can do a fun hack on top. On Intel, we have sysenter/sysexitl and, on AMD, we have syscall/sysretl. But, if I read the docs right, Intel has sysretl, too. So we can ditch sysexit entirely, since this mechanism no longer has any need to keep the entry and exit conventions matching. So this only affects 32-bit vdsos, because on 64-bit both Intel and AMD have and use SYSCALL/SYSRET. So my question would be: what's the performance difference between INT80 and sysenter entries on 32-bit, on modern CPUs? If it's not too horrible (say below 100 cycles) then we could say that we start out the simplification and robustification by switching Intel over to INT80 + SYSRET on 32-bit, and once we know the 32-bit SYSRET and all the other simplifications work fine we implement the SYSENTER-hack on top of that? int 0x80 is about 250 cycles slower than syscall/sysenter. (I mean, the instruction per se, not the full round-trip). This looks too horrible to ignore :( Is there any user-space code that relies on being able to execute an open coded SYSENTER, or are we shielded via the vDSO? Userspace can't use open-coded sysenter. It will return to a different address. Userspace _can_ do this: my_sysenter: push %ecx push %edx push %ebp movl %esp,%ebp sysenter /* end of my_sysenter() */ ... ... ... call my_sysenter but this depends on matching stack layout with one used by vDSO. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, entry: Check for syscall exit work with IRQs disabled
On Wed, Mar 25, 2015 at 5:21 AM, Ingo Molnar mi...@kernel.org wrote: * Andy Lutomirski l...@amacapital.net wrote: On Tue, Mar 24, 2015 at 1:08 PM, Ingo Molnar mi...@kernel.org wrote: * Andy Lutomirski l...@kernel.org wrote: We currently have a race: if we're preempted during syscall exit, we can fail to process syscall return work that is queued up while we're preempted in ret_from_sys_call after checking ti.flags. Fix it by disabling interrupts before checking ti.flags. Fixes: 96b6352c1271 x86_64, entry: Remove the syscall exit audit and schedule optimizations Reported-by: Stefan Seyfried stefan.seyfr...@googlemail.com Reported-by: Takashi Iwai ti...@suse.de Signed-off-by: Andy Lutomirski l...@kernel.org --- Ingo, I don't understand the LOCKDEP_SYS_EXIT stuff. Can you take a quick look to confirm that it's okay to call it more than once? So the essence is that it wants to print this warning if we are holding a lock after a syscall: printk([ BUG: lock held when returning to user space! ]\n); it manipulates no state and is not sensitive to whether it's called before or after return-work processing. arch/x86/kernel/entry_64.S | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 1d74d161687c..2babb393915e 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -364,12 +364,21 @@ system_call_fastpath: * Has incomplete stack frame and undefined top of stack. */ ret_from_sys_call: - testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) - jnz int_ret_from_sys_call_fixup /* Go the the slow path */ - LOCKDEP_SYS_EXIT DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF + + /* + * We must check ti flags with interrupts (or at least preemption) + * off because we must *never* return to userspace without + * processing exit work that is enqueued if we're preempted here. + * In particular, returning to userspace with any of the one-shot + * flags (TIF_NOTIFY_RESUME, TIF_USER_RETURN_NOTIFY, etc) set is + * very bad. + */ + testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) + jnz int_ret_from_sys_call_fixup /* Go the the slow path */ Should be safe to call it once again after user-work processing has been finished. I've picked up your fix for tip:x86/urgent. FWIW, the tentative merge here: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=tmp.tmpid=a77dd1607ad88a601259a74ba4d646fa68b7cd9a looks funny. Why aren't you jumping to int_ret_from_sys_call_irqs_off? Indeed - the orphaned label should have told me that. The mismerge is functionally harmless (causes extra overhead in the slowpath), that's why it passed testing. Does: 06ab9c1ba6a1 Merge branch 'x86/urgent' into x86/asm, to resolve conflict look better to you? Yes, looks good. Thanks. -- 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] zsmalloc: micro-optimize zs_object_copy()
On Wed, Mar 25, 2015 at 12:24:47AM +0900, Sergey Senozhatsky wrote: A micro-optimization. Avoid additional branching and reduce (a bit) registry pressure (f.e. s_off += size; d_off += size; may be calculated twise: first for = PAGE_SIZE check and later for offset update in else clause). /scripts/bloat-o-meter shows some improvement add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-10 (-10) function old new delta zs_object_copy550 540 -10 Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com Acked-by: Minchan Kim minc...@kernel.org Thanks. -- Kind regards, Minchan Kim -- 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 5/7] btrfs: add support for write stream IDs
Both buffered and O_DIRECT.
Signed-off-by: Jens Axboe ax...@fb.com
---
fs/btrfs/extent_io.c | 1 +
fs/btrfs/inode.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index d688cfe5d496..2845fae054b6 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2838,6 +2838,7 @@ static int submit_extent_page(int rw, struct
extent_io_tree *tree,
bio_add_page(bio, page, page_size, offset);
bio-bi_end_io = end_io_func;
bio-bi_private = tree;
+ bio_set_streamid(bio, inode_streamid(page-mapping-host));
if (bio_ret)
*bio_ret = bio;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index d2e732d7af52..804fd6768109 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8046,6 +8046,7 @@ static void btrfs_submit_direct(int rw, struct bio
*dio_bio,
atomic_set(dip-pending_bios, 0);
btrfs_bio = btrfs_io_bio(io_bio);
btrfs_bio-logical = file_offset;
+ bio_set_streamid(io_bio, inode_streamid(inode));
if (write) {
io_bio-bi_end_io = btrfs_endio_direct_write;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] xfs: add support for buffered writeback stream ID
Signed-off-by: Jens Axboe ax...@fb.com --- fs/xfs/xfs_aops.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index 3a9b7a1b8704..ee49e57bfd53 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -377,6 +377,7 @@ xfs_submit_ioend_bio( atomic_inc(ioend-io_remaining); bio-bi_private = ioend; bio-bi_end_io = xfs_end_bio; + bio_set_streamid(bio, ioend-io_inode-i_streamid); submit_bio(wbc-sync_mode == WB_SYNC_ALL ? WRITE_SYNC : WRITE, bio); } -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2] Support for write stream IDs
One of the things that exacerbates write amplification on flash based devices is that fact that data with different lifetimes get grouped together on media. Currently we have no interface that applications can use to separate different types of writes. This patch set adds support for that. The kernel has no knowledge of what stream ID is what. The idea is that writes with identical stream IDs have similar life times, not that stream ID 'X' has a shorter lifetime than stream ID 'X+1'. There are basically two interfaces that could be used for this. One is fcntl, the other is fadvise. This patchset uses fadvise, with a new POSIX_FADV_STREAMID hint. The 'offset' field is used to pass the relevant stream ID. Switching to fcntl (with a SET/GET_STREAMID) would be trivial. The patchset wires up the block parts, adds buffered and O_DIRECT support, and modifies btrfs/xfs too. It should be trivial to extend this to all other file systems, I just used xfs and btrfs for testing. No block drivers are wired up yet. Patches are against current -git. Changes since v1: - Don't add streamid to struct writeback_control, always use the one in the inode for buffered writeback - Add file_streamid() helper. Returns file streamid, if set, otherwise it returns the inode streamid. - Update btrfs/xfs for wbc-streamid change. - Add streamid to ext4. - Bump stream bits from 3 to 8, 255 streams are now supported. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2 RESEND] IB/Verbs: Use helpers to check IBoE technology
This patch will introduce rdma_tech_is_iboe() and use it to save some code.
Cc: Ira Weiny ira.we...@intel.com
Cc: Sean Hefty sean.he...@intel.com
Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
drivers/infiniband/core/cma.c | 6 ++
include/rdma/ib_verbs.h | 6 ++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 668e955..d354857 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -375,8 +375,7 @@ static int cma_acquire_dev(struct rdma_id_private *id_priv,
listen_id_priv-id.port_num) == dev_ll) {
cma_dev = listen_id_priv-cma_dev;
port = listen_id_priv-id.port_num;
-if (rdma_transport_is_ib(cma_dev-device)
-rdma_port_ll_is_eth(cma_dev-device, port))
+if (rdma_tech_is_iboe(cma_dev-device, port))
ret = ib_find_cached_gid(cma_dev-device, iboe_gid,
found_port, NULL);
else
@@ -395,8 +394,7 @@ static int cma_acquire_dev(struct rdma_id_private *id_priv,
listen_id_priv-id.port_num == port)
continue;
if (rdma_port_get_link_layer(cma_dev-device, port) == dev_ll) {
-if (rdma_transport_is_ib(cma_dev-device)
-rdma_port_ll_is_eth(cma_dev-device, port))
+if (rdma_tech_is_iboe(cma_dev-device, port))
ret = ib_find_cached_gid(cma_dev-device, iboe_gid,
found_port, NULL);
else
ret = ib_find_cached_gid(cma_dev-device, gid,
found_port, NULL);
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 2bf9094..9a811f8 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1767,6 +1767,12 @@ static inline int rdma_port_ll_is_eth(struct ib_device
*device, u8 port_num)
== IB_LINK_LAYER_ETHERNET;
}
+static inline int rdma_tech_is_iboe(struct ib_device *device, u8 port_num)
+{
+return rdma_transport_is_ib(device)
+rdma_port_ll_is_eth(device, port_num);
+}
+
int ib_query_gid(struct ib_device *device,
u8 port_num, int index, union ib_gid *gid);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [V5 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching
On 3/24/15 15:20, Rafael J. Wysocki wrote:
On Tuesday, March 24, 2015 04:43:46 PM Mika Westerberg wrote:
On Tue, Mar 24, 2015 at 09:23:47AM -0500, Suravee Suthikulpanit wrote:
On 3/9/15 10:20, Mika Westerberg wrote:
[]
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index e530533..9a42522 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -189,6 +189,7 @@ struct css_device_id {
struct acpi_device_id {
__u8 id[ACPI_ID_LEN];
kernel_ulong_t driver_data;
+ __u32 cls;
It would be nice if we could change ordering here but I understand that
it breaks quite many drivers. Perhaps we should consider creating
ACPI_DEVICE() macro and convert existing drivers to that at some point.
Yes, a roughly grep in the drivers directory showing about 112 files at the
moment. If you think this is the right approach going forward, we can work
on cleaning this up on a separate patch series. Please let me know what you
think.
I think having ACPI_DEVICE() macro would be pretty useful and it avoids
things like this if we need to add new fields in the future. Rafael has
the last word, though :-)
I agree.
Okay, how should I organize this big change? Can we do this as a
separate patch series?
Thanks,
Suravee
--
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/7] direct-io: add support for write stream IDs
Get the streamid from the file, if any, and set it on the bio.
Signed-off-by: Jens Axboe ax...@fb.com
---
fs/direct-io.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/direct-io.c b/fs/direct-io.c
index e181b6b2e297..3ec57abb524f 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -77,6 +77,7 @@ struct dio_submit {
int reap_counter; /* rate limit reaping */
sector_t final_block_in_request;/* doesn't change */
int boundary; /* prev block is at a boundary */
+ int streamid; /* Write stream ID */
get_block_t *get_block; /* block mapping function */
dio_submit_t *submit_io;/* IO submition function */
@@ -372,6 +373,8 @@ dio_bio_alloc(struct dio *dio, struct dio_submit *sdio,
sdio-bio = bio;
sdio-logical_offset_in_bio = sdio-cur_page_fs_offset;
+
+ bio_set_streamid(bio, sdio-streamid);
}
/*
@@ -1205,6 +1208,7 @@ do_blockdev_direct_IO(int rw, struct kiocb *iocb, struct
inode *inode,
sdio.blkbits = blkbits;
sdio.blkfactor = i_blkbits - blkbits;
sdio.block_in_file = offset blkbits;
+ sdio.streamid = file_streamid(iocb-ki_filp);
sdio.get_block = get_block;
dio-end_io = end_io;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2 RESEND] IB/Verbs: Use helpers to check transport and link layer
We have so many places to check transport type and link layer type, it's now
make sense to introduce some helpers in order to refine the lengthy code.
This patch will introduce helpers:
rdma_transport_is_ib()
rdma_transport_is_iwarp()
rdma_port_ll_is_ib()
rdma_port_ll_is_eth()
and use them to save some code for us.
Cc: Ira Weiny ira.we...@intel.com
Cc: Sean Hefty sean.he...@intel.com
Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
drivers/infiniband/core/agent.c | 2 +-
drivers/infiniband/core/cm.c | 2 +-
drivers/infiniband/core/cma.c | 27 ---
drivers/infiniband/core/mad.c | 6 +++---
drivers/infiniband/core/multicast.c | 11 ---
drivers/infiniband/core/sa_query.c| 14 +++---
drivers/infiniband/core/ucm.c | 3 +--
drivers/infiniband/core/user_mad.c| 2 +-
drivers/infiniband/core/verbs.c | 5 ++---
drivers/infiniband/hw/mlx4/ah.c | 2 +-
drivers/infiniband/hw/mlx4/cq.c | 4 +---
drivers/infiniband/hw/mlx4/mad.c | 14 --
drivers/infiniband/hw/mlx4/main.c | 8 +++-
drivers/infiniband/hw/mlx4/mlx4_ib.h | 2 +-
drivers/infiniband/hw/mlx4/qp.c | 21 +++--
drivers/infiniband/hw/mlx4/sysfs.c| 6 ++
drivers/infiniband/ulp/ipoib/ipoib_main.c | 6 +++---
include/rdma/ib_verbs.h | 24
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 3 +--
19 files changed, 79 insertions(+), 83 deletions(-)
diff --git a/drivers/infiniband/core/agent.c b/drivers/infiniband/core/agent.c
index f6d2961..27f1bec 100644
--- a/drivers/infiniband/core/agent.c
+++ b/drivers/infiniband/core/agent.c
@@ -156,7 +156,7 @@ int ib_agent_port_open(struct ib_device *device, int
port_num)
goto error1;
}
-if (rdma_port_get_link_layer(device, port_num) ==
IB_LINK_LAYER_INFINIBAND) {
+if (rdma_port_ll_is_ib(device, port_num)) {
/* Obtain send only MAD agent for SMI QP */
port_priv-agent[0] = ib_register_mad_agent(device, port_num,
IB_QPT_SMI, NULL, 0,
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index e28a494..2c72e9e 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -3762,7 +3762,7 @@ static void cm_add_one(struct ib_device *ib_device)
int ret;
u8 i;
-if (rdma_node_get_transport(ib_device-node_type) != RDMA_TRANSPORT_IB)
+if (!rdma_transport_is_ib(ib_device))
return;
cm_dev = kzalloc(sizeof(*cm_dev) + sizeof(*port) *
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index d570030..668e955 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -375,8 +375,8 @@ static int cma_acquire_dev(struct rdma_id_private *id_priv,
listen_id_priv-id.port_num) == dev_ll) {
cma_dev = listen_id_priv-cma_dev;
port = listen_id_priv-id.port_num;
-if (rdma_node_get_transport(cma_dev-device-node_type) ==
RDMA_TRANSPORT_IB
-rdma_port_get_link_layer(cma_dev-device, port) ==
IB_LINK_LAYER_ETHERNET)
+if (rdma_transport_is_ib(cma_dev-device)
+rdma_port_ll_is_eth(cma_dev-device, port))
ret = ib_find_cached_gid(cma_dev-device, iboe_gid,
found_port, NULL);
else
@@ -395,8 +395,8 @@ static int cma_acquire_dev(struct rdma_id_private *id_priv,
listen_id_priv-id.port_num == port)
continue;
if (rdma_port_get_link_layer(cma_dev-device, port) == dev_ll) {
-if (rdma_node_get_transport(cma_dev-device-node_type) ==
RDMA_TRANSPORT_IB
-rdma_port_get_link_layer(cma_dev-device, port) ==
IB_LINK_LAYER_ETHERNET)
+if (rdma_transport_is_ib(cma_dev-device)
+rdma_port_ll_is_eth(cma_dev-device, port))
ret = ib_find_cached_gid(cma_dev-device, iboe_gid,
found_port, NULL);
else
ret = ib_find_cached_gid(cma_dev-device, gid,
found_port, NULL);
@@ -435,7 +435,7 @@ static int cma_resolve_ib_dev(struct rdma_id_private
*id_priv)
pkey = ntohs(addr-sib_pkey);
list_for_each_entry(cur_dev, dev_list, list) {
-if (rdma_node_get_transport(cur_dev-device-node_type) !=
RDMA_TRANSPORT_IB)
+if (!rdma_transport_is_ib(cur_dev-device))
continue;
for (p = 1; p = cur_dev-device-phys_port_cnt; ++p) {
@@ -633,10 +633,8 @@ static int cma_modify_qp_rtr(struct rdma_id_private
*id_priv,
if (ret)
goto out;
-if (rdma_node_get_transport(id_priv-cma_dev-device-node_type)
-== RDMA_TRANSPORT_IB
-rdma_port_get_link_layer(id_priv-id.device, id_priv-id.port_num)
-== IB_LINK_LAYER_ETHERNET) {
+if
Re: [V5 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching
On 3/24/15 15:20, Rafael J. Wysocki wrote:
On Tuesday, March 24, 2015 04:43:46 PM Mika Westerberg wrote:
On Tue, Mar 24, 2015 at 09:23:47AM -0500, Suravee Suthikulpanit wrote:
On 3/9/15 10:20, Mika Westerberg wrote:
[]
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index e530533..9a42522 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -189,6 +189,7 @@ struct css_device_id {
struct acpi_device_id {
__u8 id[ACPI_ID_LEN];
kernel_ulong_t driver_data;
+ __u32 cls;
It would be nice if we could change ordering here but I understand that
it breaks quite many drivers. Perhaps we should consider creating
ACPI_DEVICE() macro and convert existing drivers to that at some point.
Yes, a roughly grep in the drivers directory showing about 112 files at the
moment. If you think this is the right approach going forward, we can work
on cleaning this up on a separate patch series. Please let me know what you
think.
I think having ACPI_DEVICE() macro would be pretty useful and it avoids
things like this if we need to add new fields in the future. Rafael has
the last word, though :-)
I agree.
Okay, how should I organize this big change? Can we do this as a
separate patch series?
Thanks,
Suravee
--
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: [Intel-gfx] [git pull] drm fixes
On Wed, 25 Mar 2015, Xi Ruoyao xry...@outlook.com wrote: It's annoying to see my code caused so much trouble. I didn't test my code with a HDMI device or I should've found this trouble before commiting. I apologize for that again. Don't worry about it. It's our fail, not yours. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] kconfig: move DEBUG_FS out of compilation options
On Wed, Mar 25, 2015 at 07:56:53AM -0700, Dave Hansen wrote: On 03/25/2015 07:22 AM, Thadeu Lima de Souza Cascardo wrote: Since 6dfc06651b3d29aa07ed99b8075e5d324f7a953a (consolidate compilation option configs), DEBUG_FS has been hidden under the Compile-time checks and compiler options. Move it out of that menu. Signed-off-by: Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com Cc: Dave Hansen dave.han...@linux.intel.com Looks fine to me. Feel free to add my ack. Looks like PAGE_OWNER got merged in to the wrong spot it probably needs to get moved over to Memory Debugging. Sorry I did not copy you on that one, but I sent a second patch with that change as well. Thanks. Cascardo. -- 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 v11 19/23] XEN / ACPI: Make XEN ACPI depend on X86
On Wed, 25 Mar 2015, Will Deacon wrote: Hi Stefano, On Tue, Mar 24, 2015 at 05:24:53PM +, Stefano Stabellini wrote: On Tue, 24 Mar 2015, Boris Ostrovsky wrote: On 03/24/2015 10:02 AM, Hanjun Guo wrote: When ACPI is enabled on ARM64, XEN ACPI will also compiled into the kernel, but XEN ACPI is x86 dependent, so introduce CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is functional on ARM64. CC: 'Stefano Stabellini' stefano.stabell...@eu.citrix.com CC: Julien Grall julien.gr...@linaro.org CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com CC: Boris Ostrovsky boris.ostrov...@oracle.com CC: David Vrabel david.vra...@citrix.com Signed-off-by: Hanjun Guo hanjun@linaro.org --- drivers/xen/Kconfig | 4 drivers/xen/Makefile | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index b812462..a31cd29 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -253,4 +253,8 @@ config XEN_EFI def_bool y depends on X86_64 EFI +config XEN_ACPI + def_bool y + depends on X86 ACPI + I think XEN_DOM0 (in arch/x86/xen/Kconfig) should select this option. Otherwise, if it is set to 'n', we won't be able to build enlighten.c (xen_start_kernel() - xen_acpi_sleep_register() refers to xen_acpi_notify_hypervisor_sleep()). I don't think that it is necessary: XEN_ACPI gets automatically enabled anyway. In which case, can I have your Ack on this please? Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] ACPI: move arm64 GSI IRQ model to generic GSI IRQ layer
On Wed, Mar 25, 2015 at 01:20:44PM +, Marc Zyngier wrote: On 24/03/15 17:58, Lorenzo Pieralisi wrote: The code deployed to implement GSI linux IRQ numbers mapping on arm64 turns out to be generic enough so that it can be moved to ACPI core code along with its respective config option ACPI_GENERIC_GSI selectable on architectures that can reuse the same code. Current ACPI IRQ mapping code is not integrated in the kernel IRQ domain infrastructure, in particular there is no way to look-up the IRQ domain associated with a particular interrupt controller, so this first version of GSI generic code carries out the GSI-IRQ mapping relying on the IRQ default domain which is supposed to be always set on a specific architecture in case the domain structure passed to irq_create/find_mapping() functions is missing. This patch moves the arm64 acpi functions that implement the gsi mappings: acpi_gsi_to_irq() acpi_register_gsi() acpi_unregister_gsi() to ACPI core code. Since the generic GSI-domain mapping is based on IRQ domains, it can be extended as soon as a way to map an interrupt controller to an IRQ domain is implemented for ACPI in the IRQ domain layer. x86 and ia64 code for GSI mappings cannot rely on the generic GSI layer at present for legacy reasons, so they do not select the ACPI_GENERIC_GSI config options and keep relying on their arch specific GSI mapping layer. This looks like the right thing to do. I definitely like the sanity checking that has been added here. FWIW: Acked-by: Marc Zyngier marc.zyng...@arm.com Thank you, I think it makes it easier to add stacked IRQ domains support later (ie sooner) and by code inspection I suspect x86 can make some use of this code too with a bit of refactoring. Lorenzo -- 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: [PATCHSET 1/3 v2 block/for-4.1/core] writeback: cgroup writeback support
On Mon, Mar 23, 2015 at 12:54:11AM -0400, Tejun Heo wrote: How to test --- * Boot with kernel option cgroup__DEVEL__legacy_files_on_dfl. * umount /sys/fs/cgroup/memory umount /sys/fs/cgroup/blkio mkdir /sys/fs/cgroup/unified mount -t cgroup -o __DEVEL__sane_behavior cgroup /sys/fs/cgroup/unified echo +blkio /sys/fs/cgroup/unified/cgroup.subtree_control * Build the cgroup hierarchy (don't forget to enable blkio using subtree_control) and put processes in cgroups and run tests on ext2 filesystems and blkio.throttle.* knobs. [..] This patchset is on top of block/for-4.1/core bfd343aa1718 (blk-mq: don't wait in blk_mq_queue_enter() if __GFP_WAIT isn't set) + [1] [PATCH] writeback: fix possible underflow in write bandwidth calculation and available in the following git branch. git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-cgroup-writeback-20150322 Hi Tejun, Great Work. I tried to do some basic testing and it seems to work. I used review-cgroup-writeback-switch-20150322 branch for my testing. I have 32G of RAM on my system and I setup a write bandwidth of 1MB/s on the disk and allowed a dd to run. That dd quickly consumed 5G of page cache before it reached to a steady state. Sounds like too much of cache consumption which will be drained at a speed of 1MB/s. Not sure if this is expected or bdi back-pressure is not being applied soon enough. Thanks Vivek -- 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/1] nfsd: incorrect check for debugfs returns
On Wed, 25 Mar 2015 11:08:56 -0400
J. Bruce Fields bfie...@fieldses.org wrote:
On Tue, Mar 24, 2015 at 06:44:20AM -0400, Jeff Layton wrote:
On Mon, 23 Mar 2015 22:58:05 -0400
Chengyu Song cson...@gatech.edu wrote:
debugfs_create_dir and debugfs_create_file may return -ENODEV when debugfs
is not configured, so the return value should be checked against
ERROR_VALUE
as well, otherwise the later dereference of the dentry pointer would crash
the kernel.
Signed-off-by: Chengyu Song cson...@gatech.edu
---
fs/nfsd/fault_inject.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/fs/nfsd/fault_inject.c b/fs/nfsd/fault_inject.c
index c16bf5a..621d065 100644
--- a/fs/nfsd/fault_inject.c
+++ b/fs/nfsd/fault_inject.c
@@ -132,19 +132,23 @@ int nfsd_fault_inject_init(void)
unsigned int i;
struct nfsd_fault_inject_op *op;
umode_t mode = S_IFREG | S_IRUSR | S_IWUSR;
+ struct dentry *dent;
- debug_dir = debugfs_create_dir(nfsd, NULL);
- if (!debug_dir)
+ dent = debugfs_create_dir(nfsd, NULL);
+ if (IS_ERR_OR_NULL(dent))
goto fail;
+ debug_dir = dent;
for (i = 0; i NUM_INJECT_OPS; i++) {
op = inject_ops[i];
- if (!debugfs_create_file(op-file, mode, debug_dir, op,
fops_nfsd))
+ dent = debugfs_create_file(op-file, mode, debug_dir, op,
fops_nfsd);
+ if (IS_ERR_OR_NULL(dent))
goto fail;
+
}
return 0;
fail:
nfsd_fault_inject_cleanup();
- return -ENOMEM;
+ return dent ? PTR_ERR(dent) : -ENOMEM;
}
No objection to taking this patch in the near term if it helps, but we
had discussed over the summer just removing the NFS fault injection
framework.
Bruce, any objections to making that happen for v4.1?
I was prepared to, but I think Redhat QA people told me that they do use
it--which means other people may too, so I'm sort of reluctant to tear
it out even if it's imperfect.
--b.
Fair enough then. I'll leave it be...
--
Jeff Layton jeff.lay...@primarydata.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm fixes
On Wed, Mar 25, 2015 at 09:56:28AM +0100, Daniel Vetter wrote: I've started seeing this one too as of rc5. Along with.. Yeah we're freeing memory too early with these bugs. To get up to the current debug state can you please cherry-pick commit f55548b5af87ebfc586ca75748947f1c1b1a4a52 Author: Damien Lespiau damien.lesp...@intel.com Date: Thu Feb 5 18:30:20 2015 + drm/i915: Don't try to reference the fb in get_initial_plane_config() and commit fb9981aa675eb7b398849915364916fd98833cfa Author: Damien Lespiau damien.lesp...@intel.com Date: Thu Feb 5 19:24:25 2015 + drm/i915: Fix atomic state when reusing the firmware fb from linux-next and then check what's left? I'm probably not going to get time to look at this again until the weekend. If things are still awry in rc6, I'll holler. Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.16.y-ckt 067/165] mei: make device disabled on stop unconditionally
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me know. -- From: Alexander Usyskin alexander.usys...@intel.com commit 6c15a8516b8118eb19a59fd0bd22df41b9101c32 upstream. Set the internal device state to to disabled after hardware reset in stop flow. This will cover cases when driver was not brought to disabled state because of an error and in stop flow we wish not to retry the reset. Signed-off-by: Alexander Usyskin alexander.usys...@intel.com Signed-off-by: Tomas Winkler tomas.wink...@intel.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: Luis Henriques luis.henriq...@canonical.com --- drivers/misc/mei/init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c index 006929222481..cf83ce10bcee 100644 --- a/drivers/misc/mei/init.c +++ b/drivers/misc/mei/init.c @@ -300,6 +300,8 @@ void mei_stop(struct mei_device *dev) dev-dev_state = MEI_DEV_POWER_DOWN; mei_reset(dev); + /* move device to disabled state unconditionally */ + dev-dev_state = MEI_DEV_DISABLED; mutex_unlock(dev-device_lock); -- 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] zsmalloc: remove unnecessary insertion/removal of zspage in compaction
I was missing mailing lists.
Ping again with correction.
On Mon, Mar 09, 2015 at 09:10:40AM +0900, Minchan Kim wrote:
In putback_zspage, we don't need to insert a zspage into list of zspage
in size_class again to just fix fullness group. We could do directly
without reinsertion so we could save some instuctions.
Reported-by: Heesub Shin heesub.s...@samsung.com
Signed-off-by: Minchan Kim minc...@kernel.org
---
mm/zsmalloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 71e4ef496918..e73a78cd340a 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1707,14 +1707,14 @@ static struct page *alloc_target_page(struct
size_class *class)
static void putback_zspage(struct zs_pool *pool, struct size_class *class,
struct page *first_page)
{
- int class_idx;
enum fullness_group fullness;
BUG_ON(!is_first_page(first_page));
- get_zspage_mapping(first_page, class_idx, fullness);
+ fullness = get_fullness_group(first_page);
insert_zspage(first_page, class, fullness);
- fullness = fix_fullness_group(class, first_page);
+ set_zspage_mapping(first_page, class-index, fullness);
+
if (fullness == ZS_EMPTY) {
zs_stat_dec(class, OBJ_ALLOCATED, get_maxobj_per_zspage(
class-size, class-pages_per_zspage));
--
1.9.1
--
Kind regards,
Minchan Kim
--
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.16.y-ckt 006/165] ipvs: add missing ip_vs_pe_put in sync code
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me know. -- From: Julian Anastasov j...@ssi.bg commit 528c943f3bb919aef75ab2fff4f00176f09a4019 upstream. ip_vs_conn_fill_param_sync() gets in param.pe a module reference for persistence engine from __ip_vs_pe_getbyname() but forgets to put it. Problem occurs in backup for sync protocol v1 (2.6.39). Also, pe_data usually comes in sync messages for connection templates and ip_vs_conn_new() copies the pointer only in this case. Make sure pe_data is not leaked if it comes unexpectedly for normal connections. Leak can happen only if bogus messages are sent to backup server. Fixes: fe5e7a1efb66 (IPVS: Backup, Adding Version 1 receive capability) Signed-off-by: Julian Anastasov j...@ssi.bg Signed-off-by: Simon Horman ho...@verge.net.au Signed-off-by: Luis Henriques luis.henriq...@canonical.com --- net/netfilter/ipvs/ip_vs_sync.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c index db801263ee9f..a8027e73b6a2 100644 --- a/net/netfilter/ipvs/ip_vs_sync.c +++ b/net/netfilter/ipvs/ip_vs_sync.c @@ -891,6 +891,8 @@ static void ip_vs_proc_conn(struct net *net, struct ip_vs_conn_param *param, IP_VS_DBG(2, BACKUP, add new conn. failed\n); return; } + if (!(flags IP_VS_CONN_F_TEMPLATE)) + kfree(param-pe_data); } if (opt) @@ -1164,6 +1166,7 @@ static inline int ip_vs_proc_sync_conn(struct net *net, __u8 *p, __u8 *msg_end) (opt_flags IPVS_OPT_F_SEQ_DATA ? opt : NULL) ); #endif + ip_vs_pe_put(param.pe); return 0; /* Error exit */ out: -- 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] rculist: Fix list_entry_rcu to read ptr with rcu_dereference_raw
On 03/25/2015 03:30 PM, Paul E. McKenney wrote:
On Tue, Mar 24, 2015 at 11:31:38AM +0100, Patrick Marlier wrote:
Change to read effectively ptr with rcu_dereference_raw and not the
__ptr variable on the stack.
Signed-off-by: Patrick Marlier patrick.marl...@gmail.com
Avoiding an extra load could be worthwhile in a number of situations,
agreed.
Not only a load. It adds a store and a load on the stack and I think
this creates a dependency in the processor pipeline.
However, won't this change cause sparse to complain if invoked on a
non-RCU-protected pointer? The ability to use list-RCU API
members on both RCU and non-RCU pointers was one of the points
of the previous commit, right?
Probably we can put back the cast but I am not familiar enough with the
RCU API.
Also, the problem here is that you probably want ACCESS_ONCE to happen
on the content of 'ptr' and not on the stack variable '__ptr'.
(you have to follow this chain: rcu_dereference_raw -
rcu_dereference_check - __rcu_dereference_check - lockless_dereference
- ACCESS_ONCE)
#define lockless_dereference(p) \
({ \
typeof(p) _p1 = ACCESS_ONCE(p); \
smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
(_p1); \
})
#define __ACCESS_ONCE(x) ({ \
__maybe_unused typeof(x) __var = (__force typeof(x)) 0; \
(volatile typeof(x) *)(x); })
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
Note that ACCESS_ONCE is doing on x.
IMHO, I would prefer saving some useless instructions for better
performance rather than giving too much flexibility on the API (also
pretty sure the cast can be still done).
--
Patrick Marlier
--
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.16.y-ckt 005/165] netfilter: xt_socket: fix a stack corruption bug
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me
know.
--
From: Eric Dumazet eduma...@google.com
commit 78296c97ca1fd3b104f12e1f1fbc06c46635990b upstream.
As soon as extract_icmp6_fields() returns, its local storage (automatic
variables) is deallocated and can be overwritten.
Lets add an additional parameter to make sure storage is valid long
enough.
While we are at it, adds some const qualifiers.
Signed-off-by: Eric Dumazet eduma...@google.com
Fixes: b64c9256a9b76 (tproxy: added IPv6 support to the socket match)
Signed-off-by: Pablo Neira Ayuso pa...@netfilter.org
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
net/netfilter/xt_socket.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 1ba67931eb1b..13332dbf291d 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -243,12 +243,13 @@ static int
extract_icmp6_fields(const struct sk_buff *skb,
unsigned int outside_hdrlen,
int *protocol,
-struct in6_addr **raddr,
-struct in6_addr **laddr,
+const struct in6_addr **raddr,
+const struct in6_addr **laddr,
__be16 *rport,
-__be16 *lport)
+__be16 *lport,
+struct ipv6hdr *ipv6_var)
{
- struct ipv6hdr *inside_iph, _inside_iph;
+ const struct ipv6hdr *inside_iph;
struct icmp6hdr *icmph, _icmph;
__be16 *ports, _ports[2];
u8 inside_nexthdr;
@@ -263,12 +264,14 @@ extract_icmp6_fields(const struct sk_buff *skb,
if (icmph-icmp6_type ICMPV6_INFOMSG_MASK)
return 1;
- inside_iph = skb_header_pointer(skb, outside_hdrlen + sizeof(_icmph),
sizeof(_inside_iph), _inside_iph);
+ inside_iph = skb_header_pointer(skb, outside_hdrlen + sizeof(_icmph),
+ sizeof(*ipv6_var), ipv6_var);
if (inside_iph == NULL)
return 1;
inside_nexthdr = inside_iph-nexthdr;
- inside_hdrlen = ipv6_skip_exthdr(skb, outside_hdrlen + sizeof(_icmph) +
sizeof(_inside_iph),
+ inside_hdrlen = ipv6_skip_exthdr(skb, outside_hdrlen + sizeof(_icmph) +
+ sizeof(*ipv6_var),
inside_nexthdr, inside_fragoff);
if (inside_hdrlen 0)
return 1; /* hjm: Packet has no/incomplete transport layer
headers. */
@@ -315,10 +318,10 @@ xt_socket_get_sock_v6(struct net *net, const u8 protocol,
static bool
socket_mt6_v1_v2(const struct sk_buff *skb, struct xt_action_param *par)
{
- struct ipv6hdr *iph = ipv6_hdr(skb);
+ struct ipv6hdr ipv6_var, *iph = ipv6_hdr(skb);
struct udphdr _hdr, *hp = NULL;
struct sock *sk = skb-sk;
- struct in6_addr *daddr = NULL, *saddr = NULL;
+ const struct in6_addr *daddr = NULL, *saddr = NULL;
__be16 uninitialized_var(dport), uninitialized_var(sport);
int thoff = 0, uninitialized_var(tproto);
const struct xt_socket_mtinfo1 *info = (struct xt_socket_mtinfo1 *)
par-matchinfo;
@@ -342,7 +345,7 @@ socket_mt6_v1_v2(const struct sk_buff *skb, struct
xt_action_param *par)
} else if (tproto == IPPROTO_ICMPV6) {
if (extract_icmp6_fields(skb, thoff, tproto, saddr, daddr,
-sport, dport))
+sport, dport, ipv6_var))
return false;
} else {
return false;
--
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.16.y-ckt 012/165] rtnetlink: call -dellink on failure when -newlink exists
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me
know.
--
From: WANG Cong xiyou.wangc...@gmail.com
commit 7afb8886a05be68e376655539a064ec672de8a8e upstream.
Ignacy reported that when eth0 is down and add a vlan device
on top of it like:
ip link add link eth0 name eth0.1 up type vlan id 1
We will get a refcount leak:
unregister_netdevice: waiting for eth0.1 to become free. Usage count = 2
The problem is when rtnl_configure_link() fails in rtnl_newlink(),
we simply call unregister_device(), but for stacked device like vlan,
we almost do nothing when we unregister the upper device, more work
is done when we unregister the lower device, so call its -dellink().
Reported-by: Ignacy Gawedzki ignacy.gawed...@green-communications.fr
Signed-off-by: Cong Wang xiyou.wangc...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
[ luis: backported to 3.16: based on davem's backport to 3.14 ]
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
net/core/rtnetlink.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 888136a75454..b1e79ca03fa0 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2069,8 +2069,16 @@ replay:
}
}
err = rtnl_configure_link(dev, ifm);
- if (err 0)
- unregister_netdevice(dev);
+ if (err 0) {
+ if (ops-newlink) {
+ LIST_HEAD(list_kill);
+
+ ops-dellink(dev, list_kill);
+ unregister_netdevice_many(list_kill);
+ } else {
+ unregister_netdevice(dev);
+ }
+ }
out:
put_net(dest_net);
return err;
--
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.16.y-ckt 003/165] ipvs: rerouting to local clients is not needed anymore
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me
know.
--
From: Julian Anastasov j...@ssi.bg
commit 579eb62ac35845686a7c4286c0a820b4eb1f96aa upstream.
commit f5a41847acc5 (ipvs: move ip_route_me_harder for ICMP)
from 2.6.37 introduced ip_route_me_harder() call for responses to
local clients, so that we can provide valid rt_src after SNAT.
It was used by TCP to provide valid daddr for ip_send_reply().
After commit 0a5ebb8000c5 (ipv4: Pass explicit daddr arg to
ip_send_reply(). from 3.0 this rerouting is not needed anymore
and should be avoided, especially in LOCAL_IN.
Fixes 3.12.33 crash in xfrm reported by Florian Wiessner:
3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
Reported-by: Smart Weblications GmbH - Florian Wiessner
f.wiess...@smart-weblications.de
Tested-by: Smart Weblications GmbH - Florian Wiessner
f.wiess...@smart-weblications.de
Signed-off-by: Julian Anastasov j...@ssi.bg
Signed-off-by: Simon Horman ho...@verge.net.au
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
net/netfilter/ipvs/ip_vs_core.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 5c34e8d42e01..74de7655faf8 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -658,16 +658,24 @@ static inline int ip_vs_gather_frags(struct sk_buff *skb,
u_int32_t user)
return err;
}
-static int ip_vs_route_me_harder(int af, struct sk_buff *skb)
+static int ip_vs_route_me_harder(int af, struct sk_buff *skb,
+unsigned int hooknum)
{
+ if (!sysctl_snat_reroute(skb))
+ return 0;
+ /* Reroute replies only to remote clients (FORWARD and LOCAL_OUT) */
+ if (NF_INET_LOCAL_IN == hooknum)
+ return 0;
#ifdef CONFIG_IP_VS_IPV6
if (af == AF_INET6) {
- if (sysctl_snat_reroute(skb) ip6_route_me_harder(skb) != 0)
+ struct dst_entry *dst = skb_dst(skb);
+
+ if (dst-dev !(dst-dev-flags IFF_LOOPBACK)
+ ip6_route_me_harder(skb) != 0)
return 1;
} else
#endif
- if ((sysctl_snat_reroute(skb) ||
-skb_rtable(skb)-rt_flags RTCF_LOCAL)
+ if (!(skb_rtable(skb)-rt_flags RTCF_LOCAL)
ip_route_me_harder(skb, RTN_LOCAL) != 0)
return 1;
@@ -790,7 +798,8 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
union nf_inet_addr *snet,
__u8 protocol, struct ip_vs_conn *cp,
struct ip_vs_protocol *pp,
- unsigned int offset, unsigned int ihl)
+ unsigned int offset, unsigned int ihl,
+ unsigned int hooknum)
{
unsigned int verdict = NF_DROP;
@@ -820,7 +829,7 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
#endif
ip_vs_nat_icmp(skb, pp, cp, 1);
- if (ip_vs_route_me_harder(af, skb))
+ if (ip_vs_route_me_harder(af, skb, hooknum))
goto out;
/* do the statistics and put it back */
@@ -915,7 +924,7 @@ static int ip_vs_out_icmp(struct sk_buff *skb, int *related,
snet.ip = iph-saddr;
return handle_response_icmp(AF_INET, skb, snet, cih-protocol, cp,
- pp, ciph.len, ihl);
+ pp, ciph.len, ihl, hooknum);
}
#ifdef CONFIG_IP_VS_IPV6
@@ -980,7 +989,8 @@ static int ip_vs_out_icmp_v6(struct sk_buff *skb, int
*related,
snet.in6 = ciph.saddr.in6;
writable = ciph.len;
return handle_response_icmp(AF_INET6, skb, snet, ciph.protocol, cp,
- pp, writable, sizeof(struct ipv6hdr));
+ pp, writable, sizeof(struct ipv6hdr),
+ hooknum);
}
#endif
@@ -1039,7 +1049,8 @@ static inline bool is_new_conn(const struct sk_buff *skb,
*/
static unsigned int
handle_response(int af, struct sk_buff *skb, struct ip_vs_proto_data *pd,
- struct ip_vs_conn *cp, struct ip_vs_iphdr *iph)
+ struct ip_vs_conn *cp, struct ip_vs_iphdr *iph,
+ unsigned int hooknum)
{
struct ip_vs_protocol *pp = pd-pp;
@@ -1077,7 +1088,7 @@ handle_response(int af, struct sk_buff *skb, struct
ip_vs_proto_data *pd,
* if it came from this machine itself. So re-compute
* the routing information.
*/
- if (ip_vs_route_me_harder(af, skb))
+ if (ip_vs_route_me_harder(af, skb, hooknum))
goto drop;
IP_VS_DBG_PKT(10, af, pp, skb, 0, After SNAT);
@@ -1180,7 +1191,7 @@ ip_vs_out(unsigned int hooknum, struct sk_buff *skb, int
af)
cp =
[PATCH 3.16.y-ckt 007/165] flowcache: Fix kernel panic in flow_cache_flush_task
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me
know.
--
From: Miroslav Urbanek m...@miroslavurbanek.com
commit 233c96fc077d310772375d47522fb444ff546905 upstream.
flow_cache_flush_task references a structure member flow_cache_gc_work
where it should reference flow_cache_flush_task instead.
Kernel panic occurs on kernels using IPsec during XFRM garbage
collection. The garbage collection interval can be shortened using the
following sysctl settings:
net.ipv4.xfrm4_gc_thresh=4
net.ipv6.xfrm6_gc_thresh=4
With the default settings, our productions servers crash approximately
once a week. With the settings above, they crash immediately.
Fixes: ca925cf1534e (flowcache: Make flow cache name space aware)
Reported-by: Tomáš Charvát t...@excello.cz
Tested-by: Jan Hejl j...@excello.cz
Signed-off-by: Miroslav Urbanek m...@miroslavurbanek.com
Acked-by: Eric Dumazet eduma...@google.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
net/core/flow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/flow.c b/net/core/flow.c
index a0348fde1fdf..1033725be40b 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -379,7 +379,7 @@ done:
static void flow_cache_flush_task(struct work_struct *work)
{
struct netns_xfrm *xfrm = container_of(work, struct netns_xfrm,
- flow_cache_gc_work);
+ flow_cache_flush_work);
struct net *net = container_of(xfrm, struct net, xfrm);
flow_cache_flush(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/
[PATCH 3.16.y-ckt 011/165] ipv6: fix ipv6_cow_metrics for non DST_HOST case
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me
know.
--
From: Martin KaFai Lau ka...@fb.com
commit 3b4711757d7903ab6fa88a9e7ab8901b8227da60 upstream.
ipv6_cow_metrics() currently assumes only DST_HOST routes require
dynamic metrics allocation from inetpeer. The assumption breaks
when ndisc discovered router with RTAX_MTU and RTAX_HOPLIMIT metric.
Refer to ndisc_router_discovery() in ndisc.c and note that dst_metric_set()
is called after the route is created.
This patch creates the metrics array (by calling dst_cow_metrics_generic) in
ipv6_cow_metrics().
Test:
radvd.conf:
interface qemubr0
{
AdvLinkMTU 1300;
AdvCurHopLimit 30;
prefix fd00:face:face:face::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
Before:
[root@qemu1 ~]# ip -6 r show | egrep -v unreachable
fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires
27sec
After:
[root@qemu1 ~]# ip -6 r show | egrep -v unreachable
fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec mtu
1300
fe80::/64 dev eth0 proto kernel metric 256 mtu 1300
default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires
27sec mtu 1300 hoplimit 30
Fixes: 8e2ec639173f325 (ipv6: don't use inetpeer to store metrics for routes.)
Signed-off-by: Martin KaFai Lau ka...@fb.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
net/ipv6/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 920616d05758..07b1eee067b1 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -141,7 +141,7 @@ static u32 *ipv6_cow_metrics(struct dst_entry *dst,
unsigned long old)
u32 *p = NULL;
if (!(rt-dst.flags DST_HOST))
- return NULL;
+ return dst_cow_metrics_generic(dst, old);
peer = rt6_get_peer_create(rt);
if (peer) {
--
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.16.y-ckt 009/165] rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me
know.
--
From: Daniel Borkmann dan...@iogearbox.net
commit 364d5716a7adb91b731a35765d369602d68d2881 upstream.
ifla_vf_policy[] is wrong in advertising its individual member types as
NLA_BINARY since .type = NLA_BINARY in combination with .len declares the
len member as *max* attribute length [0, len].
The issue is that when do_setvfinfo() is being called to set up a VF
through ndo handler, we could set corrupted data if the attribute length
is less than the size of the related structure itself.
The intent is exactly the opposite, namely to make sure to pass at least
data of minimum size of len.
Fixes: ebc08a6f47ee (rtnetlink: Add VF config code to rtnetlink)
Cc: Mitch Williams mitch.a.willi...@intel.com
Cc: Jeff Kirsher jeffrey.t.kirs...@intel.com
Signed-off-by: Daniel Borkmann dan...@iogearbox.net
Acked-by: Thomas Graf tg...@suug.ch
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
net/core/rtnetlink.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 2128423f8a7c..888136a75454 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1207,18 +1207,12 @@ static const struct nla_policy
ifla_vfinfo_policy[IFLA_VF_INFO_MAX+1] = {
};
static const struct nla_policy ifla_vf_policy[IFLA_VF_MAX+1] = {
- [IFLA_VF_MAC] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_mac) },
- [IFLA_VF_VLAN] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_vlan) },
- [IFLA_VF_TX_RATE] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_tx_rate) },
- [IFLA_VF_SPOOFCHK] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_spoofchk) },
- [IFLA_VF_RATE] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_rate) },
- [IFLA_VF_LINK_STATE]= { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_link_state) },
+ [IFLA_VF_MAC] = { .len = sizeof(struct ifla_vf_mac) },
+ [IFLA_VF_VLAN] = { .len = sizeof(struct ifla_vf_vlan) },
+ [IFLA_VF_TX_RATE] = { .len = sizeof(struct ifla_vf_tx_rate) },
+ [IFLA_VF_SPOOFCHK] = { .len = sizeof(struct ifla_vf_spoofchk) },
+ [IFLA_VF_RATE] = { .len = sizeof(struct ifla_vf_rate) },
+ [IFLA_VF_LINK_STATE]= { .len = sizeof(struct ifla_vf_link_state) },
};
static const struct nla_policy ifla_port_policy[IFLA_PORT_MAX+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: [RFC][PATCH 0/4] Another go at ktime_get_raw_fast_ns()
On Tue, Mar 24, 2015 at 02:02:55PM -0700, John Stultz wrote: On Tue, Mar 24, 2015 at 9:00 AM, John Stultz john.stu...@linaro.org wrote: Yea, this looks much better! I'll queue it up for testing and if that goes well include it for 4.1. Just fyi, didn't see any issues w/ x86_64, i386 and arm. Looks good. I've taken these to mean: Acked-by: John Stultz john.stu...@linaro.org If not, please holler. -- 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.16.y-ckt 008/165] pktgen: fix UDP checksum computation
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me
know.
--
From: Sabrina Dubroca s...@queasysnail.net
commit 7744b5f3693cc06695cb9d6667671c790282730f upstream.
This patch fixes two issues in UDP checksum computation in pktgen.
First, the pseudo-header uses the source and destination IP
addresses. Currently, the ports are used for IPv4.
Second, the UDP checksum covers both header and data. So we need to
generate the data earlier (move pktgen_finalize_skb up), and compute
the checksum for UDP header + data.
Fixes: c26bf4a51308c (pktgen: Add UDPCSUM flag to support UDP checksums)
Signed-off-by: Sabrina Dubroca s...@queasysnail.net
Acked-by: Thomas Graf tg...@suug.ch
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
net/core/pktgen.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index fc17a9d309ac..5901a1187cd2 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2814,25 +2814,25 @@ static struct sk_buff *fill_packet_ipv4(struct
net_device *odev,
skb-dev = odev;
skb-pkt_type = PACKET_HOST;
+ pktgen_finalize_skb(pkt_dev, skb, datalen);
+
if (!(pkt_dev-flags F_UDPCSUM)) {
skb-ip_summed = CHECKSUM_NONE;
} else if (odev-features NETIF_F_V4_CSUM) {
skb-ip_summed = CHECKSUM_PARTIAL;
skb-csum = 0;
- udp4_hwcsum(skb, udph-source, udph-dest);
+ udp4_hwcsum(skb, iph-saddr, iph-daddr);
} else {
- __wsum csum = udp_csum(skb);
+ __wsum csum = skb_checksum(skb, skb_transport_offset(skb),
datalen + 8, 0);
/* add protocol-dependent pseudo-header */
- udph-check = csum_tcpudp_magic(udph-source, udph-dest,
+ udph-check = csum_tcpudp_magic(iph-saddr, iph-daddr,
datalen + 8, IPPROTO_UDP, csum);
if (udph-check == 0)
udph-check = CSUM_MANGLED_0;
}
- pktgen_finalize_skb(pkt_dev, skb, datalen);
-
#ifdef CONFIG_XFRM
if (!process_ipsec(pkt_dev, skb, protocol))
return NULL;
@@ -2948,6 +2948,8 @@ static struct sk_buff *fill_packet_ipv6(struct net_device
*odev,
skb-dev = odev;
skb-pkt_type = PACKET_HOST;
+ pktgen_finalize_skb(pkt_dev, skb, datalen);
+
if (!(pkt_dev-flags F_UDPCSUM)) {
skb-ip_summed = CHECKSUM_NONE;
} else if (odev-features NETIF_F_V6_CSUM) {
@@ -2956,7 +2958,7 @@ static struct sk_buff *fill_packet_ipv6(struct net_device
*odev,
skb-csum_offset = offsetof(struct udphdr, check);
udph-check = ~csum_ipv6_magic(iph-saddr, iph-daddr,
udplen, IPPROTO_UDP, 0);
} else {
- __wsum csum = udp_csum(skb);
+ __wsum csum = skb_checksum(skb, skb_transport_offset(skb),
udplen, 0);
/* add protocol-dependent pseudo-header */
udph-check = csum_ipv6_magic(iph-saddr, iph-daddr, udplen,
IPPROTO_UDP, csum);
@@ -2965,8 +2967,6 @@ static struct sk_buff *fill_packet_ipv6(struct net_device
*odev,
udph-check = CSUM_MANGLED_0;
}
- pktgen_finalize_skb(pkt_dev, skb, datalen);
-
return skb;
}
--
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/1] nfsd: incorrect check for debugfs returns
On Mon, Mar 23, 2015 at 10:58:05PM -0400, Chengyu Song wrote:
debugfs_create_dir and debugfs_create_file may return -ENODEV when debugfs
is not configured, so the return value should be checked against ERROR_VALUE
as well, otherwise the later dereference of the dentry pointer would crash
the kernel.
Thanks for spotting this. But it looks like this will cause nfsd
startup to fail when debugfs isn't configured. I'd rather we didn't, it
just isn't that important.
So I'd rather just make nfsd_fault_inject_init() a void return--just do
a dprintk as a warning in the fail case, and otherwise let normal
startup continue (and check that doesn't lead to other unsafe
dereferences of debug_dir). Could you try that?
--b.
Signed-off-by: Chengyu Song cson...@gatech.edu
---
fs/nfsd/fault_inject.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/fs/nfsd/fault_inject.c b/fs/nfsd/fault_inject.c
index c16bf5a..621d065 100644
--- a/fs/nfsd/fault_inject.c
+++ b/fs/nfsd/fault_inject.c
@@ -132,19 +132,23 @@ int nfsd_fault_inject_init(void)
unsigned int i;
struct nfsd_fault_inject_op *op;
umode_t mode = S_IFREG | S_IRUSR | S_IWUSR;
+ struct dentry *dent;
- debug_dir = debugfs_create_dir(nfsd, NULL);
- if (!debug_dir)
+ dent = debugfs_create_dir(nfsd, NULL);
+ if (IS_ERR_OR_NULL(dent))
goto fail;
+ debug_dir = dent;
for (i = 0; i NUM_INJECT_OPS; i++) {
op = inject_ops[i];
- if (!debugfs_create_file(op-file, mode, debug_dir, op,
fops_nfsd))
+ dent = debugfs_create_file(op-file, mode, debug_dir, op,
fops_nfsd);
+ if (IS_ERR_OR_NULL(dent))
goto fail;
+
}
return 0;
fail:
nfsd_fault_inject_cleanup();
- return -ENOMEM;
+ return dent ? PTR_ERR(dent) : -ENOMEM;
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL v2] of: Add of-graph helpers to loop over endpoints and find ports by id
On Wed, Mar 25, 2015 at 4:15 AM, Philipp Zabel p.za...@pengutronix.de wrote: Hi Rob, Am Dienstag, den 24.03.2015, 23:42 -0500 schrieb Rob Herring: On Tue, Mar 24, 2015 at 4:15 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Mar 23, 2015 at 05:29:02PM +0100, Heiko Stuebner wrote: Hi Rob, Philipp, Am Mittwoch, 11. März 2015, 09:51:21 schrieb Philipp Zabel: Am Dienstag, den 10.03.2015, 14:05 -0500 schrieb Rob Herring: I've only been copied on this latest pull request and a version from March of last year which Grant nak'ed. This series did not go to devicetree list either. I'll take a look at the series. My bad, I should have copied you, too. Thanks for having a look now. any news on this? Because it looks like I'll need the of_graph_get_port_by_id functionality in the short term, it'll be nice to not having to opencode this :-) Oh hell, you mean this still hasn't been merged for the next merge window? What's going on, Grant? Andrew, can you please take this if we send you the individual patches? If not, I'll merge it into my tree, and send it to Linus myself. If Grant wakes up, we can address any comments he has at that time by additional patches. (I'll give Grant an extra few days to reply to this mail...) I've merged this for 4.1. It is in my for-next branch[1]. Rob [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git Thank you. Can I have your ok to merge the same into a pull requests going out to the drm subsystem tree? Sure. Rob -- 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] kdbus: move all kdbus headers to include/linux/kdbus
Hi, First of all, I'm sorry for this no-subject covering letter. Accidents never happen only in a perfect world. On Wed, 25 Mar 2015, David Herrmann wrote: I'd prefer if we only move the required structure definitions into a separate header. There is no reason to export all internal entry points. You're right, this would definitely look nicer. Anyway, this is a technicality that actually depends on the implemented LSM hooks. So I'd prefer if we discuss that in combination with the actual LSM patches. I'm not entirely sure which parts are needed. For testing-purposes, we can always use -I./ipc/kdbus/, right? Yes we can, which makes whole this patch a bit premature. However, we can't predict whether someone may want to use kdbus headers for any other purpose. As for now, I don't see immediate need for this apart from implementing LSM callbacks. Thanks, Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Input: cros_ec_keyb - Clear keyboard state only when it hasn't been a wake source
As the comment right before explains, the keyboard state is to be cleared only if the EC wasn't a wakeup source in the last suspend. Without this commit, there's an unneeded delay when resuming from suspend and we also lose the key that was pressed while suspended. Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com --- Sorry, v1 included an unintended change. Thanks, Tomeu --- drivers/input/keyboard/cros_ec_keyb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c index 769f8f7..b50c5b8 100644 --- a/drivers/input/keyboard/cros_ec_keyb.c +++ b/drivers/input/keyboard/cros_ec_keyb.c @@ -341,7 +341,7 @@ static int cros_ec_keyb_resume(struct device *dev) * wake source (e.g. the lid is open and the user might press a key to * wake) then the key scan buffer should be preserved. */ - if (ckdev-ec-was_wake_device) + if (!ckdev-ec-was_wake_device) cros_ec_keyb_clear_keyboard(ckdev); return 0; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: pcm512x: use DIV_ROUND_CLOSEST_ULL() from kernel.h
On Wed, Mar 25, 2015 at 11:29:44AM +, Javi Merino wrote: Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal implementation and use the kernel one. Acked-by: Mark Brown broo...@kernel.org signature.asc Description: Digital signature
[PATCH v4 6/6] ARM: dts: vf-colibri: enable NAND flash controller
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/boot/dts/vf-colibri.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
b/arch/arm/boot/dts/vf-colibri.dtsi
index 5c2b732..76139d7 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -46,6 +46,19 @@
pinctrl-0 = pinctrl_i2c0;
};
+nfc {
+ assigned-clocks = clks VF610_CLK_NFC;
+ assigned-clock-rates = 3300;
+ nand-bus-width = 8;
+ nand-ecc-mode = hw;
+ nand-on-flash-bbt;
+ nand-ecc-strength = 32;
+ nand-ecc-step-size = 2048;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_nfc_1;
+ status = okay;
+};
+
pwm0 {
pinctrl-names = default;
pinctrl-0 = pinctrl_pwm0;
@@ -141,6 +154,25 @@
;
};
+ pinctrl_nfc_1: nfcgrp_1 {
+ fsl,pins =
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ ;
+ };
+
pinctrl_pwm0: pwm0grp {
fsl,pins =
VF610_PAD_PTB0__FTM0_CH00x1182
--
2.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/6] mtd: nand: vf610_nfc: Freescale NFC for VF610
This adds support for Freescale NAND flash controller (NFC) found on various devices such as Vybrid (VF610), MPC5125, MCF54418 (ColdFire) and Kinetis K70. The patchset is based on the patchset by Bill Pringlemeir, see: http://thread.gmane.org/gmane.linux.ports.arm.kernel/295419 A variant of this driver is in upstream U-Boot now. During this process, various points have been discussed and changed. Those changes are also incorporated in this patchset, including the change to the name vf610_nfc (discussion in first patchset). http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/192465 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/193142 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/193351 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/195441 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/195513 MTD tests worked, except mtd_nandecctest.ko: The test stopped already after changing the first bit. I guess this is due to not properly working raw page read/write implementation. However, implementing those functions is not feasible since ECC is always done on-the-fly. Performance keypoints (slightly less for page write/reads): mtd_speedtest: testing eraseblock write speed mtd_speedtest: eraseblock write speed is 3531 KiB/s mtd_speedtest: testing eraseblock read speed mtd_speedtest: eraseblock read speed is 12953 KiB/s Changes since v3: - Make the driver selectable when COMPILE_TEST is set - Fix compile error due to superfluous ECC_STATUS configuration in initial patch (without ECC correction ECC_STATUS does not need to be configured) - Remove custom BBT pattern and switch to in-band BBT in the initial patch - Include two bug fixes, for details see the corresponding U-Boot patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802 Changes since v2: - Updated binding documentation Changes since v1: - Nest nfc_config struct within the main nfc struct - Use assigned clock binding to specify NFC clock - Rebased ontop of MSCM IR patchset (driver parts have been merged) - Split out arch Kconfig in a separate config - Fix module license - Updated MAINTAINERS Changes since RFC (Bill Pringlemeir): - Renamed driver from fsl_nfc to vf610_nfc - Use readl/writel for all register in accessor functions - Optimized field accessor functions - Implemented PM (suspend/resume) functions - Implemented basic support for ECC strength/ECC step size from dt - Improved performance of count_written_bits by using hweight32 - Support ECC with 60-bytes to correct up to 32 bit errors - Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes which uses up to 60 bytes on 64 byte OOB - Removed custom (downstream) BBT pattern since BBT table won't be compatible anyway (due to the change above) Stefan Agner (6): mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others mtd: nand: vf610_nfc: add hardware BCH-ECC support mtd: nand: vf610_nfc: add device tree bindings ARM: vf610: enable NAND Flash Controller ARM: dts: vf610: add NAND flash controller peripherial ARM: dts: vf-colibri: enable NAND flash controller .../devicetree/bindings/mtd/vf610-nfc.txt | 45 ++ MAINTAINERS| 6 + arch/arm/boot/dts/vf-colibri.dtsi | 32 + arch/arm/boot/dts/vf610-twr.dts| 44 ++ arch/arm/boot/dts/vfxxx.dtsi | 8 + arch/arm/mach-imx/Kconfig | 1 + drivers/mtd/nand/Kconfig | 14 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/vf610_nfc.c | 859 + 9 files changed, 1010 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt create mode 100644 drivers/mtd/nand/vf610_nfc.c -- 2.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 5/6] ARM: dts: vf610: add NAND flash controller peripherial
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.
Signed-off-by: Bill Pringlemeir bpringlem...@nbsps.com
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/boot/dts/vf610-twr.dts | 44 +
arch/arm/boot/dts/vfxxx.dtsi| 8
2 files changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index f64fddc..f42d155 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -287,6 +287,50 @@
status = okay;
};
+iomuxc {
+ vf610-twr {
+ pinctrl_nfc_1: nfcgrp_1 {
+ fsl,pins =
+ VF610_PAD_PTD31__NF_IO150x28df
+ VF610_PAD_PTD30__NF_IO140x28df
+ VF610_PAD_PTD29__NF_IO130x28df
+ VF610_PAD_PTD28__NF_IO120x28df
+ VF610_PAD_PTD27__NF_IO110x28df
+ VF610_PAD_PTD26__NF_IO100x28df
+ VF610_PAD_PTD25__NF_IO9 0x28df
+ VF610_PAD_PTD24__NF_IO8 0x28df
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ ;
+ };
+ };
+};
+
+nfc {
+ assigned-clocks = clks VF610_CLK_NFC;
+ assigned-clock-rates = 3300;
+ nand-bus-width = 16;
+ nand-ecc-mode = hw;
+ nand-on-flash-bbt;
+ nand-ecc-strength = 24;
+ nand-ecc-step-size = 2048;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_nfc_1;
+ status = okay;
+};
+
uart1 {
pinctrl-names = default;
pinctrl-0 = pinctrl_uart1;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 32de809..8c85972 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -507,6 +507,14 @@
status = disabled;
};
+ nfc: nand@400e {
+ compatible = fsl,vf610-nfc;
+ reg = 0x400e 0x4000;
+ interrupts = 83 IRQ_TYPE_LEVEL_HIGH;
+ clocks = clks VF610_CLK_NFC;
+ clock-names = nfc;
+ status = disabled;
+ };
};
};
};
--
2.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] another pmem variant
On Wed, Mar 25, 2015 at 9:04 AM, Christoph Hellwig h...@lst.de wrote: Here is another version of the same trivial pmem driver, because two obviously aren't enough. Welcome to the party! :-) The first patch is the same pmem driver that Ross posted a short time ago, just modified to use platform_devices to find the persistant memory region instead of hardconding it in the Kconfig. This allows to keep pmem.c separate from any discovery mechanism, but still allow auto-discovery. This is mostly ok and does not collide too much with the upcoming ACPI mechanism for this stuff. I do worry that the new memmap=nn[KMG]!ss[KMG] kernel command line option will only be relevant for at most one kernel cycle given the imminent publication of the spec that unblocks our release. Our planned solution to the legacy pmem problem is to have a userspace utility craft a list of address ranges in the form that ACPI expects and attach that to a platform device (one time setup). It only requires that the memory be marked reserved, not necessarily marked type-12. The other two patches are a heavily rewritten version of the code that Intel gave to various storage vendors to discover the type 12 (and earlier type 6) nvdimms, which I massaged into a form that is hopefully suitable for mainline. I'd prefer E820_PMEM over E820_PROTECTED_KERN, I don't know why I chose that name initially, but to each his own bike shed. -- 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 v8 23/30] PCI/mvebu: Use pci_common_init_dev() to simplify code
Dear Yijing Wang, On Wed, 25 Mar 2015 16:55:02 +0800, Yijing Wang wrote: Do you have any comment for this patch ? In this series, pci_bus_add_devices() has been ripped out from pci_scan_root_bus(), so I think the pci_scan_root_bus() is almost the same as pci_create_root_bus + pci_scan_child_bus(). And in this series, we try to unexport pci_create_root_bus(). It's even better if you could help test this changes. I'm away this week for ELC, but I promise to test you patch series on mvebu hardware next week. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] hfs: incorrect return values
On Tue, 2015-03-24 at 20:37 -0400, Chengyu Song wrote: In case of memory allocation error, the return should be -ENOMEM, instead of -ENOSPC. To be honest, I am not fully sure that such fix makes sense. Of course, it is possible to exchange -ENOSPC on -ENOMEM. But principally it is not critical to use as -ENOSPC as -ENOMEM in such situation, from my point of view. Anyway, it is possible to change error code here. Thanks, Vyacheslav Dubeyko. -- 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/12] mm: page_alloc: wait for OOM killer progress before retrying
On 03/25/2015 03:15 PM, Tetsuo Handa wrote: Johannes Weiner wrote: diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 5cfda39b3268..e066ac7353a4 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -711,12 +711,15 @@ bool out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask, killed = 1; } out: + if (test_thread_flag(TIF_MEMDIE)) + return true; /* -* Give the killed threads a good chance of exiting before trying to -* allocate memory again. +* Wait for any outstanding OOM victims to die. In rare cases +* victims can get stuck behind the allocating tasks, so the +* wait needs to be bounded. It's crude alright, but cheaper +* than keeping a global dependency tree between all tasks. */ - if (killed) - schedule_timeout_killable(1); + wait_event_timeout(oom_victims_wait, !atomic_read(oom_victims), HZ); return true; } out_of_memory() returning true with bounded wait effectively means that wait forever without choosing subsequent OOM victims when first OOM victim failed to die. The system will lock up, won't it? And after patch 12, does this mean that you may not be waiting long enough for the victim to die, before you fail the allocation, prematurely? I can imagine there would be situations where the victim is not deadlocked, but still take more than HZ to finish, no? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] x86/asm/entry/64: better label name, fix comments
A named label ret_from_sys_call implies that there are jumps to this location from elsewhere, as happens with many other labels in this file. But this label is used only by the JMP a few insns above. To make that obvious, use local numeric label instead. Improve comments: and return regs-ax isn't too informative. We always return regs-ax. The comment suggesting that it'd be cool to use rip relative addressing for CALL is deleted. It's unclear why that would be an improvement - we aren't striving to use position-independent code here. PIC code here would require something like LEA sys_call_table(%rip),reg + CALL *(reg,%rax*8)... iret frame is also incomplete is no longer true, fix that too. Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/kernel/entry_64.S | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index bf9afad..40f7760 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -258,16 +258,15 @@ system_call_fastpath: andl $__SYSCALL_MASK,%eax cmpl $__NR_syscall_max,%eax #endif - ja ret_from_sys_call /* and return regs-ax */ + ja 1f /* return -ENOSYS (already in pt_regs-ax) */ movq %r10,%rcx - call *sys_call_table(,%rax,8) # XXX:rip relative + call *sys_call_table(,%rax,8) movq %rax,RAX(%rsp) +1: /* - * Syscall return path ending with SYSRET (fast path) - * Has incompletely filled pt_regs, iret frame is also incomplete. + * Syscall return path ending with SYSRET (fast path). + * Has incompletely filled pt_regs. */ -ret_from_sys_call: - LOCKDEP_SYS_EXIT DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/2] MIPS: smp: Make stop_this_cpu() actually stop the CPU
Since cpu_wait() enables interrupts upon return, CPUs which have
entered stop_this_cpu() may still end up handling interrupts.
This can lead to the softlockup detector firing on a panic or
restart/poweroff/halt. Just disable interrupts and spin to ensure
nothing else runs on the CPU once it has entered stop_this_cpu().
Signed-off-by: Andrew Bresticker abres...@chromium.org
Cc: James Hogan james.ho...@imgtec.com
Cc: Maciej W. Rozycki ma...@linux-mips.org
---
New for v2.
---
arch/mips/kernel/smp.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
index 1c0d8c5..5b020bd 100644
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -176,10 +176,8 @@ static void stop_this_cpu(void *dummy)
* Remove this CPU:
*/
set_cpu_online(smp_processor_id(), false);
- for (;;) {
- if (cpu_wait)
- (*cpu_wait)(); /* Wait if available. */
- }
+ local_irq_disable();
+ while (1);
}
void smp_send_stop(void)
--
2.2.0.rc0.207.ga3a616c
--
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: [Intel-gfx] [git pull] drm fixes
On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer jwbo...@fedoraproject.org
wrote:
On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter dan...@ffwll.ch
wrote:
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau damien.lesp...@intel.com
Date: Thu Feb 5 18:30:20 2015 +
drm/i915: Don't try to reference the fb in
get_initial_plane_config()
From linux-next?
Yes, building now. Will let you know as soon as I test it on
both machines.
OK, with that commit applied I no longer get the kref.h splat and
the
NUC machine boots headless. I still see the backtrace below on
both
the NUC and the macbook. I have a copy of it with drm.debug=0xff
from
the NUC here:
https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
Getting better at least :).
On top of what you currently have please also cherry-pick
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau damien.lesp...@intel.com
Date: Thu Feb 5 19:24:25 2015 +
drm/i915: Fix atomic state when reusing the firmware fb
from -next. Let's hope this terminates eventually ;-)
Hm. That one doesn't apply cleanly. I think because it needs:
From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
From: Damien Lespiau damien.lesp...@intel.com
Date: Thu, 5 Feb 2015 17:22:18 +
Subject: drm/i915: Store the initial framebuffer in
initial_plane_config
first. Do you want me to grab both, or should I try and figure out
how to backport fb9981aa67 without it?
Oops missed that. The active ingredient is setting
crtc-primary-state-crtc like this:
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1c12262029fb..bfc14a6046ea 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc-base.primary-state-crtc =
intel_crtc-base;
update_state_fb(intel_crtc-base.primary);
return;
}
@@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
drm_framebuffer_reference(c-primary-fb);
intel_crtc-base.primary-fb = c-primary-fb;
+ intel_crtc-base.primary-state-crtc =
intel_crtc-base;
obj-frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
break;
}
Hm. So I used your patch above. The macbook boots fine and all the
oops/WARNS are gone except the audio one that was unrelated and
present before all of this.
However, the NUC is back to not booting without HDMI plugged in. I
did the drm.debug=0xff+blacklist/insmod trick again and put the
results up here:
https://jwboyer.fedorapeople.org/pub/vetters.txt
The frontbuffer splat is back now.
I confirmed multiple times that the NUC boots fine with the kernel
that doesn't include the above patch but has the other two included
(albeit with the drm_atomic WARN still).
Not sure what to make of this one.
Yeah that fail looks like we're freeing an fb that's still in use.
Hilarity happens and since that happens under console_lock at boot-up your
machine dies.
Does that machine die the same way in drm-intel-nightly/linux-next?
I'll try that a bit later today. Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build. The theory is
that we're picking up a bunch of other changes right in that range of
commits, why not try one more. I'll let you know if that fixes
anything. Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.
The drm-intel-nightly build finished first. It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel. Confused. Full log here:
https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
I don't have much hope for my other build.
Yeah that's at least good news for the theory I've been cooking meanwhile.
Can you try the below diff (on top of next/nightly)? For the current
cherry-pick pile on top of
[PATCH] i2c: i2c-mux-gpio: Change log level to debug for probe deferrals
Probe deferral is not an error case. It happens only when
the necessary dependencies are not there yet.
The driver core is already printing a message when a driver
requests probe deferral, so this can be traced in the logs
without these error prints.
This patch changes the error messages from these deferral cases
to debug messages.
Signed-off-by: Ionut Nicu ioan.nicu@nokia.com
---
drivers/i2c/muxes/i2c-mux-gpio.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
index f5798eb..9f1cfca 100644
--- a/drivers/i2c/muxes/i2c-mux-gpio.c
+++ b/drivers/i2c/muxes/i2c-mux-gpio.c
@@ -77,7 +77,7 @@ static int i2c_mux_gpio_probe_dt(struct gpiomux *mux,
}
adapter = of_find_i2c_adapter_by_node(adapter_np);
if (!adapter) {
- dev_err(pdev-dev, Cannot find parent bus\n);
+ dev_dbg(pdev-dev, Cannot find parent bus\n);
return -EPROBE_DEFER;
}
mux-data.parent = i2c_adapter_id(adapter);
@@ -178,7 +178,7 @@ static int i2c_mux_gpio_probe(struct platform_device *pdev)
parent = i2c_get_adapter(mux-data.parent);
if (!parent) {
- dev_err(pdev-dev, Parent adapter (%d) not found\n,
+ dev_dbg(pdev-dev, Parent adapter (%d) not found\n,
mux-data.parent);
return -EPROBE_DEFER;
}
--
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: [PATCH 0/4] toshiba_bluetooth: Clean up driver plus a bugfix
On Wed, Mar 18, 2015 at 01:12:54PM -0600, Azael Avalos wrote: These patches introduce three new functions, cleaning up the driver code, checking for errors and returning accordingly, and also fixes bug 93911. Azael Avalos (4): toshiba_bluetooth: Add three new functions to the driver toshiba_bluetooth: Clean up *_add function and disable BT device at removal toshiba_bluetooth: Clean toshiba_bluetooth_enable function These look good. toshiba_bluetooth: Remove BT enable code from *_notify function Questions on this one separately. drivers/platform/x86/toshiba_bluetooth.c | 133 ++- 1 file changed, 97 insertions(+), 36 deletions(-) -- 2.2.2 -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] toshiba_bluetooth: Remove BT enable code from *_notify function
On Wed, Mar 18, 2015 at 01:12:59PM -0600, Azael Avalos wrote:
Bug 93911 reported a broken handling of the BT device, causing the
driver to get stuck in a loop enabling/disabling the device whenever
the device is deactivated by the kill switch as follows:
1. The user activated the kill switch, causing the system to generate
a 0x90 (status change) event and disabling the BT device.
2. The driver catches the event and re-enables the BT device.
It does? The toshiba_bluetooth_enable() call is supposed to exit silently if
BTST is not on. Is this check not working on some systems?
3. The system detects the device being activated, but since the kill
switch is activated, disables the BT device (again) and generates
a 0x90 event (again).
4. Repeat from 2.
This patch removes the toshiba_bluetooth_enable call from the
toshiba_bluetooth_notify function, as we do not always need to
re-activate the device everytime we receive an event, we need to act
depending on the status of the BT device.
For now, we simply print the event received and the status of the BT
device, so we can later add code to handle special circumstances
depending on the status of the device.
Signed-off-by: Azael Avalos coproscef...@gmail.com
---
drivers/platform/x86/toshiba_bluetooth.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/toshiba_bluetooth.c
b/drivers/platform/x86/toshiba_bluetooth.c
index 0343d20..07edded 100644
--- a/drivers/platform/x86/toshiba_bluetooth.c
+++ b/drivers/platform/x86/toshiba_bluetooth.c
@@ -2,6 +2,7 @@
* Toshiba Bluetooth Enable Driver
*
* Copyright (C) 2009 Jes Sorensen jes.soren...@gmail.com
+ * Copyright (C) 2015 Azael Avalos coproscef...@gmail.com
*
* Thanks to Matthew Garrett for background info on ACPI innards which
* normal people aren't meant to understand :-)
@@ -25,6 +26,10 @@
#include linux/types.h
#include linux/acpi.h
+#define BT_KILLSWITCH_MASK 0x01
+#define BT_PLUGGED_MASK 0x40
+#define BT_POWER_MASK0x80
+
MODULE_AUTHOR(Jes Sorensen jes.soren...@gmail.com);
MODULE_DESCRIPTION(Toshiba Laptop ACPI Bluetooth Enable Driver);
MODULE_LICENSE(GPL);
@@ -135,7 +140,20 @@ static int toshiba_bluetooth_disable(acpi_handle handle)
static void toshiba_bt_rfkill_notify(struct acpi_device *device, u32 event)
{
- toshiba_bluetooth_enable(device-handle);
+ int status;
+
+ pr_info(Received event %x\n, event);
+
+ /* Query the status of the Bluetooth device */
+ status = toshiba_bluetooth_status(device-handle);
+ if (status 0)
+ return;
+
+ pr_info(Switch status %x\n, status BT_KILLSWITCH_MASK);
+ pr_info(Power status %x\n, status BT_POWER_MASK);
+ pr_info(Plug status %x\n, status BT_PLUGGED_MASK);
This seems a bit noisy for the info level as this information seems more aimed
at a developer working to complete the TODO below... debug seems more
appropriate.
+
+ /* TODO: Add event handling here depending on Bluetooth status */
Before if the RFKILL was disabled, this would have called
toshiba_bluetooth_enable() which would have checked BTST, found it on, and
enabled the device. In addition to killing the call to
toshiba_bluetooth_enable() when RFKILL is on, this also removes the call when
it's switched off.
I think I'm missing a path. Where does enable occur when the user turns the
radio back on now?
}
#ifdef CONFIG_PM_SLEEP
--
2.2.2
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] x86/asm/entry/64: do not TRACE_IRQS fast SYSRET64 path
* Denys Vlasenko dvlas...@redhat.com wrote: On 03/25/2015 06:29 PM, Ingo Molnar wrote: * Denys Vlasenko dvlas...@redhat.com wrote: SYSRET code path has a small irq-off block. On this code path, TRACE_IRQS_ON can't be called right before interrupts are enabled for real, we can't clobber registers there. So current code does it earlier, in a safe place. But with this, TRACE_IRQS_OFF/ON frames just two fast instructions, which is ridiculous: now most of irq-off block is _outside_ of the framing. Do the same thing that we do on SYSCALL entry: do not track this irq-off block, it is very small to ever cause noticeable irq latency. Be careful: make sure that jnz int_ret_from_sys_call_irqs_off now does invoke TRACE_IRQS_OFF - move int_ret_from_sys_call_irqs_off label before TRACE_IRQS_OFF. @@ -345,8 +346,8 @@ tracesys_phase2: */ GLOBAL(int_ret_from_sys_call) DISABLE_INTERRUPTS(CLBR_NONE) - TRACE_IRQS_OFF int_ret_from_sys_call_irqs_off: + TRACE_IRQS_OFF movl $_TIF_ALLWORK_MASK,%edi /* edi: mask to check */ This latter trick absolutely needs a comment, to keep future lockdep developers from wondering about the mismatch and the weird label placement ... Unsure how to format it. How about: DISABLE_INTERRUPTS(CLBR_NONE) int_ret_from_sys_call_irqs_off: /* jumps come here with irqs off */ TRACE_IRQS_OFF Why not something like 'jumps come here from the irqs-off SYSRET path'? (In truth, there is only one jump as of now, but using pliral jumps if that would change) I'd also put a comment to the actual sysret IRQ-disablement that we are skipping with the annotation. Explain that it's an optimization for a visible irqs-off path that needs no annotation - and that the moment something complex is done in that path, this optimization loses its validity. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] mfd: intel_quark_i2c_gpio: don't crash if !DMI
dmi_get_system_info() may return NULL either when CONFIG_DMI is not set or when
board has an old firmware. The patch prevents a crash and changes the default
frequency to be in align with older board.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/mfd/intel_quark_i2c_gpio.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index 006f2a1..35291c2 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -70,6 +70,9 @@ static const struct i2c_mode_info platform_i2c_mode_info[] = {
.name = GalileoGen2,
.i2c_scl_freq = 40,
},
+ {
+ /* Sentinel */
+ }
};
static struct resource intel_quark_i2c_res[] = {
@@ -153,10 +156,10 @@ static void intel_quark_unregister_i2c_clk(struct pci_dev
*pdev)
static int intel_quark_i2c_setup(struct pci_dev *pdev, struct mfd_cell *cell)
{
const char *board_name = dmi_get_system_info(DMI_BOARD_NAME);
+ const struct i2c_mode_info *info;
struct dw_i2c_platform_data *pdata;
struct resource *res = (struct resource *)cell-resources;
struct device *dev = pdev-dev;
- unsigned int i;
res[INTEL_QUARK_IORES_MEM].start =
pci_resource_start(pdev, MFD_I2C_BAR);
@@ -170,13 +173,17 @@ static int intel_quark_i2c_setup(struct pci_dev *pdev,
struct mfd_cell *cell)
if (!pdata)
return -ENOMEM;
- /* Fast mode by default */
- pdata-i2c_scl_freq = 40;
-
- for (i = 0; i ARRAY_SIZE(platform_i2c_mode_info); i++)
- if (!strcmp(board_name, platform_i2c_mode_info[i].name))
- pdata-i2c_scl_freq
- = platform_i2c_mode_info[i].i2c_scl_freq;
+ /* Normal mode by default */
+ pdata-i2c_scl_freq = 10;
+
+ if (board_name) {
+ for (info = platform_i2c_mode_info; info-name; info++) {
+ if (!strcmp(board_name, info-name)) {
+ pdata-i2c_scl_freq = info-i2c_scl_freq;
+ break;
+ }
+ }
+ }
cell-platform_data = pdata;
cell-pdata_size = sizeof(*pdata);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] hfsplus: incorrect return value
On Tue, 2015-03-24 at 20:44 -0400, Chengyu Song wrote: In case of memory allocation error, the return should be -ENOMEM, instead of -ENOSPC. To be honest, I am not fully sure that such fix makes sense. Of course, it is possible to exchange -ENOSPC on -ENOMEM. But principally it is not critical to use as -ENOSPC as -ENOMEM in such situation, from my point of view. Anyway, it is possible to change error code here. Thanks, Vyacheslav Dubeyko. -- 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-nvdimm] another pmem variant
On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig h...@lst.de wrote: On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote: This is mostly ok and does not collide too much with the upcoming ACPI mechanism for this stuff. I do worry that the new memmap=nn[KMG]!ss[KMG] kernel command line option will only be relevant for at most one kernel cycle given the imminent publication of the spec that unblocks our release. I don't think we can just get rid of it as legacy systems won't be upgraded to the new discovery mechanism. Or do you mean you plan to introduce a better override on the command line? In that case speak up now! The kernel command line would simply be the standard/existing memmap= to reserve a memory range. Then, when the platform device loads, it does a request_firmware() to inject a binary table that further carves memory into ranges to which the pmem driver attaches. No need for the legacy system BIOS to be upgraded to the new way. Our planned solution to the legacy pmem problem is to have a userspace utility craft a list of address ranges in the form that ACPI expects and attach that to a platform device (one time setup). It only requires that the memory be marked reserved, not necessarily marked type-12. I can't see any benefit of that over just doign the right thing in kernel space. It does do the right thing in kernel space. The userspace utility creates the binary table (once) that can be compiled into the platform device driver or auto-loaded by an initrd. The problem with a new memmap= is that it is too coarse. For example you can't do things like specify a pmem range per-NUMA node. -- 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] input: synaptics: min_max quirk for Thinkpad E440
On Wed, Mar 25, 2015 at 09:57:51AM -0300, Ramiro Morales wrote: On Wed, Mar 25, 2015 at 6:04 AM, Daniel Martin consume.no...@gmail.com wrote: On 25 March 2015 at 02:20, Filip Ayazi filipay...@gmail.com wrote: Sets min_max_quirk values for LEN2006 touchpad found in Lenovo Thinkpad E440 (board_id=2691). Dmitry already applied a patch for the E440: http://www.spinics.net/lists/linux-input/msg37497.html There are two great things about this second submission from Filip. First, it confirms the values sent by the hardware in a second laptop as reported by touchpad-edge-detector. Second, it reveals I made a stupid mistake transcribing the y_max value to the quirks able. The correct value is 4832 and my patch wrongly contains 4632. I'm very sorry for this. I see my patch has already been pushed to the 'for-linus' branch and I don't know which process should we follow to fix the issue. My 'for-linus' branch is stable so we need a fixup on top on the incorrect patch, the same way as if it was already in mainline. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rts5208: Remove TRACE_RET and TRACE_GOTO macros
On Tue, 2015-03-24 at 21:28 -0700, Joe Perches wrote: Remove these flow hiding macros. Apologies, this won't compile properly as I neglected to git add trace.c prior to the git commit. I'll resend later. -- 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/1] cifs: potential missing check for posix_lock_file_wait
On Mar 24, 2015, at 10:29 PM, Steve French smfre...@gmail.com wrote: On Tue, Mar 24, 2015 at 7:18 PM, Chengyu Song cson...@gatech.edu wrote: posix_lock_file_wait may fail under certain circumstances, and its result is usually checked/returned. But given the complexity of cifs, I'm not sure if the result is intentially left unchecked and always expected to succeed. Signed-off-by: Chengyu Song cson...@gatech.edu --- fs/cifs/file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/cifs/file.c b/fs/cifs/file.c index a94b3e6..beef67b 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -1553,8 +1553,8 @@ cifs_setlk(struct file *file, struct file_lock *flock, __u32 type, rc = server-ops-mand_unlock_range(cfile, flock, xid); out: - if (flock-fl_flags FL_POSIX) - posix_lock_file_wait(file, flock); + if (flock-fl_flags FL_POSIX !rc) + rc = posix_lock_file_wait(file, flock); return rc; } This is interesting. Useful comparisons include For network file systems you could - enforce byte range locks only at the server - enforce locks only on the client, and don't send to the server - do both Since cifs byte range locks are often emulated (except when Unix Extensions are enabled, e.g. on mounts to Samba), we do the latter by default, as does fs/9p (although they do it in a different order, trying to grab the local byte range lock first). But another interesting comparison point is nfs, where the code for v3 vs. v4 looks different. Take a look at nfsv3 (see fs/nfs/file.c) where the choice is made to either do the posix_lock_file_wait (if 'local' locking only) or if sending locks to the server then don't call to set the local lock. Alternatively nfs4proc.c handles it differently. There may not be a perfect answer on this one but was wondering if you have experimented with what happens when you mount with nobrl (which is the cifs mount option which causes locks not to be sent to the server, and thus only evaulted locally). My suspicion is that you can demonstrate a failure if you mount with nobrl (without your patch). Maybe it's better to provide more context. We're developing a static checker that cross check different implementations of filesystems, and this is a warning we get from that tool as it is the only place where the return value of posix_lock_file_wait is not checked/forwarded. So I have not experimented with mounting options. And I guess another thing is, for the path of posix_lock == false, posix_lock_file_wait is never invoked if any error happens. But for CIFSSMBPosixLock, its return value is never checked and posix_lock_file_wait is always invoked. Thanks, Chengyu-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/2] MIPS: Provide fallback reboot/poweroff/halt implementations
If a machine-specific hook is not implemented for restart, poweroff,
or halt, fall back to halting secondary CPUs, disabling interrupts,
and spinning. In the case of restart, attempt to restart the system
via do_kernel_restart() (which will call any registered restart
handlers) before halting.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Cc: James Hogan james.ho...@imgtec.com
Cc: Maciej W. Rozycki ma...@linux-mips.org
---
Changes from v1:
- disable preemption before calling smp_send_stop()
- add a 1s delay after do_kernel_restart()
---
arch/mips/kernel/reset.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 07fc524..7c746d3 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -11,6 +11,7 @@
#include linux/pm.h
#include linux/types.h
#include linux/reboot.h
+#include linux/delay.h
#include asm/reboot.h
@@ -29,16 +30,40 @@ void machine_restart(char *command)
{
if (_machine_restart)
_machine_restart(command);
+
+#ifdef CONFIG_SMP
+ preempt_disable();
+ smp_send_stop();
+#endif
+ do_kernel_restart(command);
+ mdelay(1000);
+ pr_emerg(Reboot failed -- System halted\n);
+ local_irq_disable();
+ while (1);
}
void machine_halt(void)
{
if (_machine_halt)
_machine_halt();
+
+#ifdef CONFIG_SMP
+ preempt_disable();
+ smp_send_stop();
+#endif
+ local_irq_disable();
+ while (1);
}
void machine_power_off(void)
{
if (pm_power_off)
pm_power_off();
+
+#ifdef CONFIG_SMP
+ preempt_disable();
+ smp_send_stop();
+#endif
+ local_irq_disable();
+ while (1);
}
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/wmi: delete unused wmi_data_lock mutex causing gcc warning
On Mon, Mar 23, 2015 at 02:01:37PM -0400, Paul Gortmaker wrote: In commit bff431e49ff531a343fbb2b4426e313000844f32 (ACPI: WMI: Add ACPI-WMI mapping driver) this mutex was added, but the rest of the final commit never actually made use of it, resulting in: In file included from include/linux/mutex.h:29:0, from include/linux/kernfs.h:13, from include/linux/sysfs.h:15, from include/linux/kobject.h:21, from include/linux/device.h:17, from drivers/platform/x86/wmi.c:35: drivers/platform/x86/wmi.c:48:21: warning: ‘wmi_data_lock’ defined but not used [-Wunused-variable] static DEFINE_MUTEX(wmi_data_lock); ^ A git grep shows no other instances/references to the wmi_data_lock. Delete it, assuming that the mutex addition was just a leftover from an earlier work in progress version of the change, since the original dates from 2008. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com Queued, thank you Paul. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Transakce /
Mám vzájemn#283; vyplácena podnik pro nás oba. pokud máte zájem, m#367;ete mi dostat na e-mailovou adresu a podrobnosti vysv#283;tlil po telefonu. E-mail: jg.ch...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] another pmem variant
On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote: The kernel command line would simply be the standard/existing memmap= to reserve a memory range. Then, when the platform device loads, it does a request_firmware() to inject a binary table that further carves memory into ranges to which the pmem driver attaches. No need for the legacy system BIOS to be upgraded to the new way. Ewww... It does do the right thing in kernel space. The userspace utility creates the binary table (once) that can be compiled into the platform device driver or auto-loaded by an initrd. The problem with a new memmap= is that it is too coarse. For example you can't do things like specify a pmem range per-NUMA node. Sure you can as long as you know the layout. memmap= can be specified multiple times. Again, I see absolutely zero benefit of doing crap like request_firmware() to convert interface, and I'm also tired of having this talk about code that will eventually be released and should be superior (and from all that I can guess so far will actually be far worse). -- 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 4/4] x86/asm/entry/64: fix typo in comment
Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/kernel/entry_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 23aa43e..47e126b 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -1407,7 +1407,7 @@ ENTRY(nmi) * NMI. */ - /* Use %rdx as out temp variable throughout */ + /* Use %rdx as our temp variable throughout */ pushq_cfi %rdx CFI_REL_OFFSET rdx, 0 -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] x86/asm/entry/64: do not TRACE_IRQS fast SYSRET64 path
SYSRET code path has a small irq-off block. On this code path, TRACE_IRQS_ON can't be called right before interrupts are enabled for real, we can't clobber registers there. So current code does it earlier, in a safe place. But with this, TRACE_IRQS_OFF/ON frames just two fast instructions, which is ridiculous: now most of irq-off block is _outside_ of the framing. Do the same thing that we do on SYSCALL entry: do not track this irq-off block, it is very small to ever cause noticeable irq latency. Be careful: make sure that jnz int_ret_from_sys_call_irqs_off now does invoke TRACE_IRQS_OFF - move int_ret_from_sys_call_irqs_off label before TRACE_IRQS_OFF. Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/kernel/entry_64.S | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 40f7760..11b7339 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -268,8 +268,11 @@ system_call_fastpath: * Has incompletely filled pt_regs. */ LOCKDEP_SYS_EXIT + /* +* We do not frame this tiny irq-off block with TRACE_IRQS_OFF/ON, +* it is too small to ever cause noticeable irq latency. +*/ DISABLE_INTERRUPTS(CLBR_NONE) - TRACE_IRQS_OFF /* * We must check ti flags with interrupts (or at least preemption) @@ -283,10 +286,7 @@ system_call_fastpath: jnz int_ret_from_sys_call_irqs_off /* Go to the slow path */ CFI_REMEMBER_STATE - /* -* sysretq will re-enable interrupts: -*/ - TRACE_IRQS_ON + RESTORE_C_REGS_EXCEPT_RCX_R11 movqRIP(%rsp),%rcx CFI_REGISTERrip,rcx @@ -297,6 +297,7 @@ system_call_fastpath: * 64bit SYSRET restores rip from rcx, * rflags from r11 (but RF and VM bits are forced to 0), * cs and ss are loaded from MSRs. +* Restoration of rflags re-enables interrupts. */ USERGS_SYSRET64 @@ -345,8 +346,8 @@ tracesys_phase2: */ GLOBAL(int_ret_from_sys_call) DISABLE_INTERRUPTS(CLBR_NONE) - TRACE_IRQS_OFF int_ret_from_sys_call_irqs_off: + TRACE_IRQS_OFF movl $_TIF_ALLWORK_MASK,%edi /* edi: mask to check */ GLOBAL(int_with_check) -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] x86/asm/entry/64: use smaller insns
The $AUDIT_ARCH_X86_64 parameter to syscall_trace_enter_phase1/2 is a 32-bit constant, loading it with 32-bit MOV produces 5-byte insn instead of 10-byte one. Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/kernel/entry_64.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 11b7339..23aa43e 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -306,7 +306,7 @@ system_call_fastpath: /* Do syscall entry tracing */ tracesys: movq %rsp, %rdi - movq $AUDIT_ARCH_X86_64, %rsi + movl $AUDIT_ARCH_X86_64, %esi call syscall_trace_enter_phase1 test %rax, %rax jnz tracesys_phase2 /* if needed, run the slow path */ @@ -317,7 +317,7 @@ tracesys: tracesys_phase2: SAVE_EXTRA_REGS movq %rsp, %rdi - movq $AUDIT_ARCH_X86_64, %rsi + movl $AUDIT_ARCH_X86_64, %esi movq %rax,%rdx call syscall_trace_enter_phase2 -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Request for additional arm64 branch in linux-next
Hi Stephen, We've got a series of patches introducing ACPI support for arm64 that are tentatively targetting the 4.1 merge window. Whilst there are face-to-face discussions set to happen in the next day or so around this topic, could you please pull this into linux-next under the assumption that we decide to go ahead for mainline inclusion? git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/acpi I've kept the series separate from the usual arm64 branch (for-next/core) but they merge without conflicts. Merging with today's next, I see two trivial Kconfig conflicts (resolution below). I'll let you know when the branch is no longer needed. Thanks, Will ---8 diff --cc arch/arm64/Kconfig index 4085df18e558,0659db374731..0eae06cdac27 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@@ -1,7 -1,9 +1,9 @@@ config ARM64 def_bool y + select ACPI_GENERIC_GSI if ACPI + select ACPI_REDUCED_HARDWARE_ONLY if ACPI - select ARCH_BINFMT_ELF_RANDOMIZE_PIE select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE + select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_GCOV_PROFILE_ALL select ARCH_HAS_SG_CHAIN select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST diff --cc drivers/xen/Kconfig index afc39ca5cc4f,a31cd29b68a8..31347cd8c046 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@@ -253,10 -253,8 +253,14 @@@ config XEN_EF def_bool y depends on X86_64 EFI +config XEN_AUTO_XLATE + def_bool y + depends on ARM || ARM64 || XEN_PVHVM + help +Support for auto-translated physmap guests. + + config XEN_ACPI + def_bool y + depends on X86 ACPI + endmenu -- 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] ftracetest: replace usleep by sleep
'usleep' seems to be a distro-specific utility and may not be
available:
[5] event tracing - enable/disable with event level files [FAIL]
execute:
/home/miguel/linux/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
+ .
/home/miguel/linux/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
+ [ ! -f set_event -o ! -d events/sched ]
+ reset_tracer
+ echo nop
+ do_reset
+ echo
+ clear_trace
+ echo
+ echo sched:sched_switch
+ usleep 1
./ftracetest: 24:
/home/miguel/linux/tools/testing/selftests/ftrace/test.d/event/event-enable.tc:
usleep: not found
Replace it with the more standard sleep.
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
tools/testing/selftests/ftrace/test.d/event/event-enable.tc | 6 +++---
tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
index 668616d9bb03..abafc0c3605c 100644
--- a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
@@ -21,7 +21,7 @@ reset_tracer
do_reset
echo 'sched:sched_switch' set_event
-usleep 1
+sleep 0.001
count=`cat trace | grep sched_switch | wc -l`
if [ $count -eq 0 ]; then
@@ -31,7 +31,7 @@ fi
do_reset
echo 1 events/sched/sched_switch/enable
-usleep 1
+sleep 0.001
count=`cat trace | grep sched_switch | wc -l`
if [ $count -eq 0 ]; then
@@ -41,7 +41,7 @@ fi
do_reset
echo 0 events/sched/sched_switch/enable
-usleep 1
+sleep 0.001
count=`cat trace | grep sched_switch | wc -l`
if [ $count -ne 0 ]; then
diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
index 655c415b6e7f..d1e0f5b770c3 100644
--- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
@@ -21,7 +21,7 @@ reset_tracer
do_reset
echo 'sched:*' set_event
-usleep 1
+sleep 0.001
count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
if [ $count -lt 3 ]; then
@@ -31,7 +31,7 @@ fi
do_reset
echo 1 events/sched/enable
-usleep 1
+sleep 0.001
count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
if [ $count -lt 3 ]; then
@@ -41,7 +41,7 @@ fi
do_reset
echo 0 events/sched/enable
-usleep 1
+sleep 0.001
count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
if [ $count -ne 0 ]; then
--
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/4] x86/asm/entry/64: do not TRACE_IRQS fast SYSRET64 path
On 03/25/2015 06:29 PM, Ingo Molnar wrote: * Denys Vlasenko dvlas...@redhat.com wrote: SYSRET code path has a small irq-off block. On this code path, TRACE_IRQS_ON can't be called right before interrupts are enabled for real, we can't clobber registers there. So current code does it earlier, in a safe place. But with this, TRACE_IRQS_OFF/ON frames just two fast instructions, which is ridiculous: now most of irq-off block is _outside_ of the framing. Do the same thing that we do on SYSCALL entry: do not track this irq-off block, it is very small to ever cause noticeable irq latency. Be careful: make sure that jnz int_ret_from_sys_call_irqs_off now does invoke TRACE_IRQS_OFF - move int_ret_from_sys_call_irqs_off label before TRACE_IRQS_OFF. @@ -345,8 +346,8 @@ tracesys_phase2: */ GLOBAL(int_ret_from_sys_call) DISABLE_INTERRUPTS(CLBR_NONE) -TRACE_IRQS_OFF int_ret_from_sys_call_irqs_off: +TRACE_IRQS_OFF movl $_TIF_ALLWORK_MASK,%edi /* edi: mask to check */ This latter trick absolutely needs a comment, to keep future lockdep developers from wondering about the mismatch and the weird label placement ... Unsure how to format it. How about: DISABLE_INTERRUPTS(CLBR_NONE) int_ret_from_sys_call_irqs_off: /* jumps come here with irqs off */ TRACE_IRQS_OFF (In truth, there is only one jump as of now, but using pliral jumps if that would change) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2 1/1] X86: hyperv: Enable MSR based APIC access
-Original Message- From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo Molnar Sent: Wednesday, March 25, 2015 5:15 AM To: KY Srinivasan Cc: x...@kernel.org; gre...@linuxfoundation.org; linux- ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; t...@linutronix.de; h...@zytor.com Subject: Re: [PATCH V2 1/1] X86: hyperv: Enable MSR based APIC access * K. Y. Srinivasan k...@microsoft.com wrote: If the hypervisor supports MSR based access to the APIC registers (EOI, TPR and ICR), implement the MSR based access. Signed-off-by: K. Y. Srinivasan k...@microsoft.com --- Changes from V1: Addressed comments from Ingo Molnar mingo.kernel@gmail.com You didn't address my primary feedback: So since we are trying to explain things, wouldn't this comment be more informative if it explained why we are trying to use the x2APIC facilities of Hyper-V? Ingo, I added the code for advertising support for x2APIC since I saw the feature flag in the public documentation of Hyper-V. Subsequently, when I checked with the Hyper-V developers, I learned that Hyper-V does not support x2APIC for guests. So, I got rid of the code that checked for this flag as that would be dead code. I.e. what are the benefits of using the x2apic API towards the hypervisor? please explain the purpose, context and benefits, not just what the patch does - even if the comment from your first patch is now gone. The MSR based access can be a little more efficient than the mmio based access to the select APIC registers. That is the intent of this patch. Do you want me to resubmit the patch with these additional details. Regards, K. Y -- 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: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi, Am 25.03.2015 um 16:21 schrieb Sebastian Reichel s...@kernel.org: Hi, On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote: Am 25.03.2015 um 02:45 schrieb Sebastian Reichel s...@kernel.org: On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote: So you propose that the parent-child relationship is “control”? I.e. some channel which allows to address some bus client (through reg) and control that devices. Makes sense. This is how i2c and spi clients are specified. In the case of our GPS, it receives control over the serial connection from the UART, Ahem - does it? AFAIK the chip simply starts to emit NMEA records if powered on. There is no command going over the serial interface to address it or control it. Right, since GPS basically doesn't need any configuration/control. That’s not true for other UART attached devices, though. Do you have an example? Usually an UART data stream is transparently presented to a /dev/tty - and user-space daemon can configure/control the attached device. In most cases it can mix payload data and control command by some AT command and escape sequences. Yes, but the configuration is minimal. Anyways as you said there *is* some kind of control happening over the UART. Control is happening on a higher network stack level than UART. It control is done through AT commands. also receives control via a GPIO to the on/off pin, and also needs a regulator to power the antenna. So should the parent be the uart, the on/off GPIO, or the regulator? I would much rather there wasn't a parent, and that each of these were listed as ad-hoc attribute assignments. But device-tree says there must be a parent (where possible), and the parent is the thing that is “primarily in control. Well, IMHO the “parent” could also be the root. Representing the whole board. Nevertheless, I doubt your rule that “ability to control” defines the parentchild relation (see below). I think the GPS is “primarily a uart-attached device. But not in the same way as an I2C device. Especially the serial interface is not a bus and not used for signalling and power control. It is payload data (only). Actually many I2C devices are also powered on/off via a GPIO and even use additional GPIOs for sending interrupts. Nevertheless they are normally identified as an I2C device. Because I2C is a bus that can address multiple clients and gpio isn’t a bus and a point-to-point connection. But IMHO it is not because they (can) send payload data over i2c. From my POV it's not because I2C is a bus, but because the primary function is happening via I2C (e.g. configuring sensor, gettings its data). The GPIOs are only needed to compensate some I2C shortcomings (missing irq feature in I2C) or reduce the complexity of the client (power GPIO). The actual system interaction with the I2C chip is going via I2C, though. Yes, but this is in my new understanding irrelevant for proper DT description. Also for non-GPS device the serial connection is used for controlling and configuring the device. This assumes that “controls a device” is the criterion for making a device a subnode. I doubt that. For me the criterion always was accessing the device's registers/configuration/data from the system's point of view (so your video port does not count, since it models a connection between two components without system interaction). So I propose a device-node which describes the GPS, which is a child of the UART, and explicitly identifies the GPIO it uses to power on/off, the regulator it uses to power the antenna, and how it receives on or off status indications from the GPS. The more I think about that, you have given good arguments *not* to use the parent-child relationship for the UART interface of the GPS. Let me give another example. The 3G Modem has 3 (or 4) interfaces: 1. an USB-Interface for AT signalling and payload 2. some GPIOs for power control. 3. a PCM interface for digital voice. 4. it might also have a serial interface as alternate AT command and (GPRS low speed) payload. So which one is the most prominent or most important to make it a child of? If you use “control” you must make it a child of the USB phy and the serial interface which requires multiple inheritance… So I am not sure at all. None is IMHO prominent and unique enough to make it a parentchild relation. Threrefore, I would be happy to see it as multiple children of /. For example a MFD with subnodes. This scenario has already been seen before and can happen for non-UART based devices (e.g. SPI + I2C). So far the decision was to postpone the discussion about this kind of devices until one of them appears. It is arguable that the antenna should be treated as a separate device - a child of the GPS - which controls the regulator and also provides a 'extcon' which
Re: [Linux-nvdimm] another pmem variant
On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote: This is mostly ok and does not collide too much with the upcoming ACPI mechanism for this stuff. I do worry that the new memmap=nn[KMG]!ss[KMG] kernel command line option will only be relevant for at most one kernel cycle given the imminent publication of the spec that unblocks our release. I don't think we can just get rid of it as legacy systems won't be upgraded to the new discovery mechanism. Or do you mean you plan to introduce a better override on the command line? In that case speak up now! Our planned solution to the legacy pmem problem is to have a userspace utility craft a list of address ranges in the form that ACPI expects and attach that to a platform device (one time setup). It only requires that the memory be marked reserved, not necessarily marked type-12. I can't see any benefit of that over just doign the right thing in kernel space. The other two patches are a heavily rewritten version of the code that Intel gave to various storage vendors to discover the type 12 (and earlier type 6) nvdimms, which I massaged into a form that is hopefully suitable for mainline. I'd prefer E820_PMEM over E820_PROTECTED_KERN, I don't know why I chose that name initially, but to each his own bike shed. Sounds fine to me. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] perf tool: Fix ppid for synthesized fork events
363b785f38 added synthesized fork events and set a thread's parent id
to itself. Since we are already processing /proc/pid/status the ppid
can be determined properly. Make it so.
Performance impact measured on a sparc based T5-8 (1024 CPUs):
$ ps -efL | wc -l
20185
Current code:
$ time perf record -o perf-no-ppid.data -e cpu-clock -F 1000 -a -v -BN --
usleep 1
mmap size 532480B
[ perf record: Woken up 0 times to write data ]
failed to write feature 9
[ perf record: Captured and wrote 0.000 MB perf-no-ppid.data ]
real0m26.144s
user0m0.452s
sys 0m25.564s
With PPID patch:
$ time ./perf_ppid record -o perf-ppid.data -e cpu-clock -F 1000 -a -v -BN --
usleep 1
mmap size 532480B
[ perf record: Woken up 0 times to write data ]
failed to write feature 9
[ perf record: Captured and wrote 0.000 MB perf-ppid.data ]
real0m25.743s
user0m0.268s
sys 0m25.368s
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Joe Mario jma...@redhat.com
Cc: Jiri Olsa jo...@redhat.com
---
v2:
- removed loop in place of 1 read and processing a buffer
tools/perf/util/event.c | 178 ++--
1 file changed, 110 insertions(+), 68 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index d5efa5092ce6..e98cbba56033 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -49,70 +49,115 @@ static struct perf_sample synth_sample = {
.period= 1,
};
-static pid_t perf_event__get_comm_tgid(pid_t pid, char *comm, size_t len)
+/*
+ * Assumes that the first 4095 bytes of /proc/pid/stat contains
+ * the comm, tgid and ppid.
+ */
+static int perf_event__get_comm_ids(pid_t pid, char *comm, size_t len,
+ pid_t *tgid, pid_t *ppid)
{
char filename[PATH_MAX];
- char bf[BUFSIZ];
- FILE *fp;
- size_t size = 0;
- pid_t tgid = -1;
+ char bf[4096];
+ int fd;
+ size_t size = 0, n;
+ char *nl, *name, *tgids, *ppids;
+
+ *tgid = -1;
+ *ppid = -1;
snprintf(filename, sizeof(filename), /proc/%d/status, pid);
- fp = fopen(filename, r);
- if (fp == NULL) {
+ fd = open(filename, O_RDONLY);
+ if (fd 0) {
pr_debug(couldn't open %s\n, filename);
- return 0;
+ return -1;
}
- while (!comm[0] || (tgid 0)) {
- if (fgets(bf, sizeof(bf), fp) == NULL) {
- pr_warning(couldn't get COMM and pgid, malformed %s\n,
- filename);
- break;
- }
-
- if (memcmp(bf, Name:, 5) == 0) {
- char *name = bf + 5;
- while (*name isspace(*name))
- ++name;
- size = strlen(name) - 1;
- if (size = len)
- size = len - 1;
- memcpy(comm, name, size);
- comm[size] = '\0';
-
- } else if (memcmp(bf, Tgid:, 5) == 0) {
- char *tgids = bf + 5;
- while (*tgids isspace(*tgids))
- ++tgids;
- tgid = atoi(tgids);
- }
+ n = read(fd, bf, sizeof(bf) - 1);
+ close(fd);
+ if (n = 0) {
+ pr_warning(Couldn't get COMM, tigd and ppid for pid %d\n,
+ pid);
+ return -1;
}
+ bf[n] = '\0';
- fclose(fp);
+ name = strstr(bf, Name:);
+ tgids = strstr(bf, Tgid:);
+ ppids = strstr(bf, PPid:);
+
+ if (name) {
+ name += 5; /* strlen(Name:) */
+
+ while (*name isspace(*name))
+ ++name;
+
+ nl = strchr(name, '\n');
+ if (nl)
+ *nl = '\0';
+
+ size = strlen(name);
+ if (size = len)
+ size = len - 1;
+ memcpy(comm, name, size);
+ comm[size] = '\0';
+ } else
+ pr_debug(Name: string not found for pid %d\n, pid);
+
+ if (tgids) {
+ tgids += 5; /* strlen(Tgid:) */
+ while (*tgids isspace(*tgids))
+ ++tgids;
+
+ nl = strchr(tgids, '\n');
+ if (nl)
+ *nl = '\0';
+
+ *tgid = atoi(tgids);
+
+ } else
+ pr_debug(Tgid: string not found for pid %d\n, pid);
+
+ if (ppids) {
+ ppids += 5; /* strlen(PPid:) */
+
+ while (*ppids isspace(*ppids))
+ ++ppids;
+
+ nl = strchr(ppids, '\n');
+ if (nl)
+ *nl = '\0';
+
+ *ppid = atoi(ppids);
+ } else
+ pr_debug(PPid: string not found for pid %d\n,
Re: [PATCH 1/1] nfsd: incorrect check for debugfs returns
There may be a simpler solution, declare NFSD_FAULT_INJECTION has dependency
on DEBUG_FS, or automatically select DEBUG_FS. I don't think current debugfs
implementation will return any error ptr once it's configured.
I choose to check the return instead, because I was worried the debugfs
interface
may change in the future.
Does this sounds like a solution? If so, I can submit a patch for Kconfig.
Best,
Chengyu
On Mar 25, 2015, at 11:17 AM, J. Bruce Fields bfie...@fieldses.org wrote:
On Mon, Mar 23, 2015 at 10:58:05PM -0400, Chengyu Song wrote:
debugfs_create_dir and debugfs_create_file may return -ENODEV when debugfs
is not configured, so the return value should be checked against ERROR_VALUE
as well, otherwise the later dereference of the dentry pointer would crash
the kernel.
Thanks for spotting this. But it looks like this will cause nfsd
startup to fail when debugfs isn't configured. I'd rather we didn't, it
just isn't that important.
So I'd rather just make nfsd_fault_inject_init() a void return--just do
a dprintk as a warning in the fail case, and otherwise let normal
startup continue (and check that doesn't lead to other unsafe
dereferences of debug_dir). Could you try that?
--b.
Signed-off-by: Chengyu Song cson...@gatech.edu
---
fs/nfsd/fault_inject.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/fs/nfsd/fault_inject.c b/fs/nfsd/fault_inject.c
index c16bf5a..621d065 100644
--- a/fs/nfsd/fault_inject.c
+++ b/fs/nfsd/fault_inject.c
@@ -132,19 +132,23 @@ int nfsd_fault_inject_init(void)
unsigned int i;
struct nfsd_fault_inject_op *op;
umode_t mode = S_IFREG | S_IRUSR | S_IWUSR;
+struct dentry *dent;
-debug_dir = debugfs_create_dir(nfsd, NULL);
-if (!debug_dir)
+dent = debugfs_create_dir(nfsd, NULL);
+if (IS_ERR_OR_NULL(dent))
goto fail;
+debug_dir = dent;
for (i = 0; i NUM_INJECT_OPS; i++) {
op = inject_ops[i];
-if (!debugfs_create_file(op-file, mode, debug_dir, op,
fops_nfsd))
+dent = debugfs_create_file(op-file, mode, debug_dir, op,
fops_nfsd);
+if (IS_ERR_OR_NULL(dent))
goto fail;
+
}
return 0;
fail:
nfsd_fault_inject_cleanup();
-return -ENOMEM;
+return dent ? PTR_ERR(dent) : -ENOMEM;
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf tool: Fix ppid for synthesized fork events
On 3/25/15 6:22 AM, Joe Mario wrote: We ran time perf mem record -a -e cpu/mem-loads,ldlat=50/pp -e cpu/mem-stores/pp sleep 10 on a system that was running SPECjbb2013 in the background. There were about 10,000 java threads with about 500 to 800 in a runnable state at any given time. We ran it on a 4 socket x86 IVB server. We had two perf binaries. One with your patch and one without it. Because the benchmark doesn't always have a constant load, we ran the above perf command in a loop alternating between the patched and unpatched version. The elapsed wall clock times (real field from time) for the perf with your patch was typically = 50% longer than the equivalent unpatched perf. Sent a v2 with performance numbers on my end. Adding -BN to the record removes processing of the events for build-ids. I also chose to use -e cpu-clock -F 1000 with -- usleep 1 to trim what perf-record is doing to *only* reading /proc files and generating COMM and FORK events. David -- 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 V5 1/2] spmi: remove wakeup command before slave probe
According to spmi spec a slave powers up into startup state and then transitions into active state. Thus, the wakeup command is not required before calling the slave's probe. The wakeup command is only needed for slaves that are in sleep state after receiving the sleep command. Cc: ga...@codeaurora.org Reviewed-by: Stephen Boyd sb...@codeaurora.org Reviewed-by: Sagar Dharia sdha...@codeaurora.org Acked-by: Josh Cartwright jo...@eso.teric.us Signed-off-by: Gilad Avidov gavi...@codeaurora.org --- drivers/spmi/spmi.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/spmi/spmi.c b/drivers/spmi/spmi.c index 1d92f51..9493843 100644 --- a/drivers/spmi/spmi.c +++ b/drivers/spmi/spmi.c @@ -1,4 +1,5 @@ -/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved. +/* + * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 and @@ -316,11 +317,6 @@ static int spmi_drv_probe(struct device *dev) struct spmi_device *sdev = to_spmi_device(dev); int err; - /* Ensure the slave is in ACTIVE state */ - err = spmi_command_wakeup(sdev); - if (err) - goto fail_wakeup; - pm_runtime_get_noresume(dev); pm_runtime_set_active(dev); pm_runtime_enable(dev); @@ -335,7 +331,6 @@ fail_probe: pm_runtime_disable(dev); pm_runtime_set_suspended(dev); pm_runtime_put_noidle(dev); -fail_wakeup: return err; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 V5 2/2] spmi: pmic_arb: add support for hw version 2
Qualcomm PMIC Arbiter version-2 changes from version-1 are:
- Some different register offsets.
- New channel register space, one per PMIC peripheral (ppid).
All tx traffic uses these channels.
- New observer register space. All rx trafic uses this space.
- Different command format for spmi command registers.
Reviewed-by: Sagar Dharia sdha...@codeaurora.org
Signed-off-by: Gilad Avidov gavi...@codeaurora.org
---
.../bindings/spmi/qcom,spmi-pmic-arb.txt | 6 +-
drivers/spmi/spmi-pmic-arb.c | 319 +
2 files changed, 265 insertions(+), 60 deletions(-)
diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
index 715d099..e16b9b5 100644
--- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
+++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
@@ -1,6 +1,6 @@
Qualcomm SPMI Controller (PMIC Arbiter)
-The SPMI PMIC Arbiter is found on the Snapdragon 800 Series. It is an SPMI
+The SPMI PMIC Arbiter is found on Snapdragon chipsets. It is an SPMI
controller with wrapping arbitration logic to allow for multiple on-chip
devices to control a single SPMI master.
@@ -19,6 +19,10 @@ Required properties:
core - core registers
intr - interrupt controller registers
cnfg - configuration registers
+ Registers used only for V2 PMIC Arbiter:
+ chnls - tx-channel per virtual slave registers.
+ obsrvr - rx-channel (called observer) per virtual slave registers.
+
- reg : address + size pairs describing the PMIC arb register sets; order must
correspond with the order of entries in reg-names
- #address-cells : must be set to 2
diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
index 20559ab..d7119db 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -1,4 +1,5 @@
-/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+/*
+ * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -25,22 +26,18 @@
/* PMIC Arbiter configuration registers */
#define PMIC_ARB_VERSION 0x
+#define PMIC_ARB_VERSION_V2_MIN0x2001
#define PMIC_ARB_INT_EN0x0004
-/* PMIC Arbiter channel registers */
-#define PMIC_ARB_CMD(N)(0x0800 + (0x80 * (N)))
-#define PMIC_ARB_CONFIG(N) (0x0804 + (0x80 * (N)))
-#define PMIC_ARB_STATUS(N) (0x0808 + (0x80 * (N)))
-#define PMIC_ARB_WDATA0(N) (0x0810 + (0x80 * (N)))
-#define PMIC_ARB_WDATA1(N) (0x0814 + (0x80 * (N)))
-#define PMIC_ARB_RDATA0(N) (0x0818 + (0x80 * (N)))
-#define PMIC_ARB_RDATA1(N) (0x081C + (0x80 * (N)))
-
-/* Interrupt Controller */
-#define SPMI_PIC_OWNER_ACC_STATUS(M, N)(0x + ((32 * (M)) + (4 *
(N
-#define SPMI_PIC_ACC_ENABLE(N) (0x0200 + (4 * (N)))
-#define SPMI_PIC_IRQ_STATUS(N) (0x0600 + (4 * (N)))
-#define SPMI_PIC_IRQ_CLEAR(N) (0x0A00 + (4 * (N)))
+/* PMIC Arbiter channel registers offsets */
+#define PMIC_ARB_CMD 0x00
+#define PMIC_ARB_CONFIG0x04
+#define PMIC_ARB_STATUS0x08
+#define PMIC_ARB_WDATA00x10
+#define PMIC_ARB_WDATA10x14
+#define PMIC_ARB_RDATA00x18
+#define PMIC_ARB_RDATA10x1C
+#define PMIC_ARB_REG_CHNL(N) (0x800 + 0x4 * (N))
/* Mapping Table */
#define SPMI_MAPPING_TABLE_REG(N) (0x0B00 + (4 * (N)))
@@ -52,6 +49,7 @@
#define SPMI_MAPPING_TABLE_LEN 255
#define SPMI_MAPPING_TABLE_TREE_DEPTH 16 /* Maximum of 16-bits */
+#define PPID_TO_CHAN_TABLE_SZ BIT(12) /* PPID is 12bit chan is 1byte*/
/* Ownership Table */
#define SPMI_OWNERSHIP_TABLE_REG(N)(0x0700 + (4 * (N)))
@@ -88,6 +86,7 @@ enum pmic_arb_cmd_op_code {
/* Maximum number of support PMIC peripherals */
#define PMIC_ARB_MAX_PERIPHS 256
+#define PMIC_ARB_MAX_CHNL 128
#define PMIC_ARB_PERIPH_ID_VALID (1 15)
#define PMIC_ARB_TIMEOUT_US100
#define PMIC_ARB_MAX_TRANS_BYTES (8)
@@ -98,14 +97,17 @@ enum pmic_arb_cmd_op_code {
/* interrupt enable bit */
#define SPMI_PIC_ACC_ENABLE_BITBIT(0)
+struct pmic_arb_ver_ops;
+
/**
* spmi_pmic_arb_dev - SPMI PMIC Arbiter object
*
- * @base: address of the PMIC Arbiter core registers.
+ * @rd_base: on v1 core, on v2 observer register base off DT.
+ * @wr_base: on v1 core, on v2 chnlsregister base off DT.
* @intr: address of the SPMI interrupt control registers.
* @cnfg: address of the PMIC Arbiter
[PATCH V5 0/2] add support for pmic_arb v2 and correct framework
pmic_arb v2 has no support for spmi non-data commands and thus returns -EOPNOTSUPP on .cmd callback. This causes a failure in spmi_drv_probe() which sends a wakeup command to the slave before probing its driver. This patchset removes the wakeup from spmi_drv_probe() since the spmi spec stipulates that a slaves default state is active and doesn't need a wakeup. Changes from v3 to v4: * Remove the claim that this is a bug fix off the commit text * Unmap the core register space as soon as we know that it will not be used * Assign the core reg space to a local until we know if it appropriate to use it to configure the controller fields (on v1) or unmap it (on v2). Changes from v4 to v5: * remove the unmap added in v4 since it is used again and the mapping is managed. * correct printf formatting for 64bit compilers. * correct base address for reading the channel table. Gilad Avidov (2): spmi: remove wakeup command before slave probe spmi: pmic_arb: add support for hw version 2 .../bindings/spmi/qcom,spmi-pmic-arb.txt | 6 +- drivers/spmi/spmi-pmic-arb.c | 319 + drivers/spmi/spmi.c| 9 +- 3 files changed, 267 insertions(+), 67 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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/
String literals in __init functions
Hello everyone,
AFAIU, functions only used at system init are tagged __init to have
the linker store them in a separate .init.text section, so memory can
be reclaimed once initialization is complete. Is that correct?
The corresponding tag for data is __initdata (section .init.data)
I started wondering if the string literals used in an __init functions
were automatically marked __initdata.
Looking at the objdump output, I see that the string literals are,
in fact, stored in the .rodata section. I suppose that .rodata is NOT
reclaimed after init?
This way seems to work:
static char XyZa[] __initdata = KERN_ALERT foo;
static const char XyZb[] __initconst = KERN_ALERT bar;
void __init XyZc(void) { printk(XyZa); printk(XyZb); }
$ arm-linux-gnueabihf-objdump -xd arch/arm/mach-tangox/time.o | grep XyZ
l O .init.data 0006 XyZa
l O .init.rodata 0006 XyZb
g F .init.text 0028 XyZc
XyZc:
$ arm-linux-gnueabihf-objdump -xd vmlinux | grep XyZ
c021e360 l O .init.data 0006 XyZa
c0220090 l O .init.data 0006 XyZb
c020d928 g F .init.text 0028 XyZc
c020d928 XyZc:
c020d928 XyZc:
c020d928: e1a0c00dmov ip, sp
c020d92c: e92dd800push{fp, ip, lr, pc}
c020d930: e24cb004sub fp, ip, #4
c020d934: e30e0360movwr0, #58208 ; 0xe360
c020d938: e34c0021movtr0, #49185 ; 0xc021
c020d93c: ebfe00c9bl c018dc68 printk
c020d940: e390movwr0, #144; 0x90
c020d944: e34c0022movtr0, #49186 ; 0xc022
c020d948: ebfe00c6bl c018dc68 printk
c020d94c: e89da800ldm sp, {fp, sp, pc}
Did I miss something in init.h?
Or should it be done like above to reclaim string literals?
Regards.
--
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: String literals in __init functions
On Wed, 2015-03-25 at 18:56 +0100, Mason wrote:
Hello everyone,
AFAIU, functions only used at system init are tagged __init to have
the linker store them in a separate .init.text section, so memory can
be reclaimed once initialization is complete. Is that correct?
The corresponding tag for data is __initdata (section .init.data)
I started wondering if the string literals used in an __init functions
were automatically marked __initdata.
Looking at the objdump output, I see that the string literals are,
in fact, stored in the .rodata section. I suppose that .rodata is NOT
reclaimed after init?
This way seems to work:
static char XyZa[] __initdata = KERN_ALERT foo;
static const char XyZb[] __initconst = KERN_ALERT bar;
void __init XyZc(void) { printk(XyZa); printk(XyZb); }
$ arm-linux-gnueabihf-objdump -xd arch/arm/mach-tangox/time.o | grep XyZ
l O .init.data 0006 XyZa
l O .init.rodata 0006 XyZb
g F .init.text 0028 XyZc
XyZc:
$ arm-linux-gnueabihf-objdump -xd vmlinux | grep XyZ
c021e360 l O .init.data 0006 XyZa
c0220090 l O .init.data 0006 XyZb
c020d928 g F .init.text 0028 XyZc
c020d928 XyZc:
c020d928 XyZc:
c020d928: e1a0c00dmov ip, sp
c020d92c: e92dd800push{fp, ip, lr, pc}
c020d930: e24cb004sub fp, ip, #4
c020d934: e30e0360movwr0, #58208 ; 0xe360
c020d938: e34c0021movtr0, #49185 ; 0xc021
c020d93c: ebfe00c9bl c018dc68 printk
c020d940: e390movwr0, #144; 0x90
c020d944: e34c0022movtr0, #49186 ; 0xc022
c020d948: ebfe00c6bl c018dc68 printk
c020d94c: e89da800ldm sp, {fp, sp, pc}
Did I miss something in init.h?
Or should it be done like above to reclaim string literals?
No, you didn't miss anything.
One proposal:
https://lkml.org/lkml/2014/8/21/255
Regards.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] Drivers: hv: hv_balloon: do not online pages in offline blocks
Patch 1/1 is rather a hackaround. The root cause of the issue is the fact that we're adding not fully backed memory blocks and allow to online them. It is relatively easy to forbid that and add only fully backed 128Mb regions. The whole driver code will be much simpler: hv_bring_pgs_online() and hv_online_page() will go away, ha_region_mutex won't probably be required,... Please let me know if you think I should follow this way. Vitaly Kuznetsov (1): Drivers: hv: hv_balloon: do not online pages in offline blocks drivers/hv/hv_balloon.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv3 PATCH 33/48] sched: Energy-aware wake-up task placement
Hi Peter,
On 24/03/15 16:35, Peter Zijlstra wrote:
On Wed, Feb 04, 2015 at 06:31:10PM +, Morten Rasmussen wrote:
+static int energy_aware_wake_cpu(struct task_struct *p)
+{
+struct sched_domain *sd;
+struct sched_group *sg, *sg_target;
+int target_max_cap = SCHED_CAPACITY_SCALE;
+int target_cpu = task_cpu(p);
+int i;
+
+sd = rcu_dereference(per_cpu(sd_ea, task_cpu(p)));
+
+if (!sd)
+return -1;
+
+sg = sd-groups;
+sg_target = sg;
+/* Find group with sufficient capacity */
+do {
+int sg_max_capacity = group_max_capacity(sg);
+
+if (sg_max_capacity = task_utilization(p)
+sg_max_capacity = target_max_cap) {
+sg_target = sg;
+target_max_cap = sg_max_capacity;
+}
+} while (sg = sg-next, sg != sd-groups);
+
+/* Find cpu with sufficient capacity */
+for_each_cpu_and(i, tsk_cpus_allowed(p), sched_group_cpus(sg_target)) {
+int new_usage = get_cpu_usage(i) + task_utilization(p);
+
+if (new_usage capacity_orig_of(i))
+continue;
+
+if (new_usage capacity_curr_of(i)) {
+target_cpu = i;
+if (!cpu_rq(i)-nr_running)
+break;
+}
+
+/* cpu has capacity at higher OPP, keep it as fallback */
+if (target_cpu == task_cpu(p))
+target_cpu = i;
+}
+
+if (target_cpu != task_cpu(p)) {
+struct energy_env eenv = {
+.usage_delta= task_utilization(p),
+.src_cpu= task_cpu(p),
+.dst_cpu= target_cpu,
+};
+
+/* Not enough spare capacity on previous cpu */
+if (cpu_overutilized(task_cpu(p), sd))
+return target_cpu;
+
+if (energy_diff(eenv) = 0)
+return task_cpu(p);
+}
+
+return target_cpu;
+}
Mike kept working on this since last LPC discussion, and I could
spend some cycles on this thing too lately, reviewing/discussing
wip with him. So, I guess I'll jump into this :).
So while you have some cpufreq - sched coupling (the capacity_curr
thing) this would be the site where you could provide sched - cpufreq
coupling, right?
Yes and no, IMHO. It makes perfect sense to trigger cpufreq on the
target_cpu's freq domain, as we know that we are going to add p's
utilization there. Anyway, I was thinking that we could just
rely on triggering points in {en,de}queue_task_fair and task_tick_fair.
We end up calling one of them every time we wake-up a task, perform
a load balancing decision or just while running the task itself
(we have to react to tasks phase changes). This way we should be
able to reduce the number of triggering points and be more general
at the same time.
So does it make sense to at least put in the right hooks now? I realize
we'll likely take cpufreq out back and feed it to the bears but
something managing P states will be there whatever we'll call the new
fangled thing and this would be the place to hook it still.
We should be able to clean up and post something along this line
fairly soon.
Best,
- Juri
--
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] TTY: use class_find_device to find port in uart_suspend/resume.
Hi Neil,
On 03/18/2015 01:58 AM, NeilBrown wrote:
uart_{suspend,resume}_port seach the children of a uart device
to find a particular tty device.
This requires all the ttys to be direct children of the uart.
A future patch will allow a 'tty_slave' to intervene between
the port and the uart, voiding this requirement.
So change to use class_find_device. This is made possibly by
exporting a tty_find_device from tty_io.c
Comments below.
Signed-off-by: NeilBrown n...@brown.name
---
drivers/tty/serial/serial_core.c | 21 -
drivers/tty/tty_io.c |6 ++
include/linux/tty.h |1 +
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c
b/drivers/tty/serial/serial_core.c
index 6a1055ae3437..7abb7474870a 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1960,26 +1960,19 @@ struct uart_match {
struct uart_driver *driver;
};
-static int serial_match_port(struct device *dev, void *data)
-{
- struct uart_match *match = data;
- struct tty_driver *tty_drv = match-driver-tty_driver;
- dev_t devt = MKDEV(tty_drv-major, tty_drv-minor_start) +
- match-port-line;
-
- return dev-devt == devt; /* Actually, only one tty per port */
-}
int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
{
struct uart_state *state = drv-state + uport-line;
struct tty_port *port = state-port;
struct device *tty_dev;
- struct uart_match match = {uport, drv};
+ dev_t devt = MKDEV(drv-tty_driver-major,
+drv-tty_driver-minor_start) +
+ uport-line;
mutex_lock(port-mutex);
- tty_dev = device_find_child(uport-dev, match, serial_match_port);
+ tty_dev = tty_find_device(devt);
if (device_may_wakeup(tty_dev)) {
if (!enable_irq_wake(uport-irq))
uport-irq_wake = 1;
@@ -2039,12 +2032,14 @@ int uart_resume_port(struct uart_driver *drv, struct
uart_port *uport)
struct uart_state *state = drv-state + uport-line;
struct tty_port *port = state-port;
struct device *tty_dev;
- struct uart_match match = {uport, drv};
struct ktermios termios;
+ dev_t devt = MKDEV(drv-tty_driver-major,
+drv-tty_driver-minor_start) +
+ uport-line;
mutex_lock(port-mutex);
- tty_dev = device_find_child(uport-dev, match, serial_match_port);
+ tty_dev = tty_find_device(devt);
if (!uport-suspended device_may_wakeup(tty_dev)) {
if (uport-irq_wake) {
disable_irq_wake(uport-irq);
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 51f066aa375e..27632ad17d6f 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3077,6 +3077,12 @@ static struct device *tty_get_device(struct tty_struct
*tty)
return class_find_device(tty_class, NULL, devt, dev_match_devt);
}
+struct device *tty_find_device(dev_t devt)
+{
+ return class_find_device(tty_class, NULL, devt, dev_match_devt);
+}
+EXPORT_SYMBOL(tty_find_device);
+
Would you please replace tty_get_device() usage with tty_find_device()
(and keep the function comment from tty_get_device())?
Regards,
Peter Hurley
/**
* alloc_tty_struct
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 358a337af598..04d5f1213700 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -461,6 +461,7 @@ extern void tty_vhangup(struct tty_struct *tty);
extern int tty_hung_up_p(struct file *filp);
extern void do_SAK(struct tty_struct *tty);
extern void __do_SAK(struct tty_struct *tty);
+extern struct device *tty_find_device(dev_t devt);
extern void no_tty(void);
extern void tty_flush_to_ldisc(struct tty_struct *tty);
extern void tty_buffer_free_all(struct tty_port *port);
--
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 5/9] eeprom: Add bindings for simple eeprom framework
On Wed, Mar 25, 2015 at 08:10:06AM +0100, Sascha Hauer wrote:
On Tue, Mar 24, 2015 at 10:30:30PM +, Srinivas Kandagatla wrote:
This patch adds bindings for simple eeprom framework which allows eeprom
consumers to talk to eeprom providers to get access to eeprom cell data.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
.../devicetree/bindings/eeprom/eeprom.txt | 70
++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
new file mode 100644
index 000..8348d18
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -0,0 +1,70 @@
+= EEPROM Data Device Tree Bindings =
+
+This binding is intended to represent the location of hardware
+configuration data stored in EEPROMs.
+
+On a significant proportion of boards, the manufacturer has stored
+some data on an EEPROM-like device, for the OS to be able to retrieve
+these information and act upon it. Obviously, the OS has to know
+about where to retrieve these data from, and where they are stored on
+the storage device.
+
+This document is here to document this.
+
+= Data providers =
+Contains bindings specific to provider drivers and data cells as children
+to this node.
+
+= Data cells =
+These are the child nodes of the provider which contain data cell
+information like offset and size in eeprom provider.
+
+Required properties:
+reg: specifies the offset in byte within that storage device, and
the length
+ in bytes of the data we care about.
+ There could be more then one offset-length pairs in this property.
+
+Optional properties:
+As required by specific data parsers/interpreters.
+
+For example:
+
+ /* Provider */
+ qfprom: qfprom@0070 {
+ compatible = qcom,qfprom;
+ reg = 0x0070 0x1000;
+ ...
+
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = 0x404 0x10;
+ };
+
+ serial_number: sn {
+ reg = 0x104 0x4, 0x204 0x4, 0x30c 0x4;
+
+ };
+ ...
+ };
+
+= Data consumers =
+Are device nodes which consume eeprom data cells.
+
+Required properties:
+
+eeproms: List of phandle and data cell the device might be interested in.
+
+Optional properties:
+
+eeprom-names: List of data cell name strings sorted in the same order
+ as the eeproms property. Consumers drivers will use
+ eeprom-names to differentiate between multiple cells,
+ and hence being able to know what these cells are for.
+
+For example:
+
+ tsens {
+ ...
+ eeproms = tsens_calibration;
+ eeprom-names = calibration;
+ };
This is somewhat complicated. Also having 'eeprom' in the binding is not
nice since it could be FRAM or something else. How about:
tsens {
calibration = tsens_calibration;
};
A similar property was suggested the first time we discussed it, and
it turned out eventually that the construct you commented about was
actually preferred.
I guess we can always change the property name to something more
generic though.
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[PATCH 0/3] Add configfs support for software triggers in IIO
This patchset adds initial support for configfs in IIO. It is structured in the following way: * patch 1 - adds configfs infrastructure creating an iio configfs subystem + an initial triggers group. * patch 2 - adds the first real trigger type - hrtimer. * patch 3 - adds Documentation Daniel Baluta (3): iio: configfs: Add configfs support to IIO iio: trigger: Add support for highres timer trigger iio: Documentation: Add initial documentaton for IIO Documentation/iio/iio_configfs.txt | 74 drivers/iio/Kconfig | 8 + drivers/iio/Makefile | 1 + drivers/iio/industrialio-configfs.c | 301 +++ drivers/iio/trigger/Kconfig | 8 + drivers/iio/trigger/Makefile | 2 + drivers/iio/trigger/iio-trig-hrtimer.c | 146 +++ include/linux/iio/iio_configfs_trigger.h | 49 + 8 files changed, 589 insertions(+) create mode 100644 Documentation/iio/iio_configfs.txt create mode 100644 drivers/iio/industrialio-configfs.c create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c create mode 100644 include/linux/iio/iio_configfs_trigger.h -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] iio: configfs: Add configfs support to IIO
This creates an IIO configfs subsystem named iio, which has one default
group named triggers. This allows us to easily create/destroy software
triggers. One must create a driver which implements iio_configfs_trigger.h
interface and then add its trigger type to IIO configfs core.
See Documentation/iio/iio_configfs.txt for more details on how configfs
support for IIO works.
Signed-off-by: Daniel Baluta daniel.bal...@intel.com
---
drivers/iio/Kconfig | 8 +
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-configfs.c | 297 +++
include/linux/iio/iio_configfs_trigger.h | 48 +
4 files changed, 354 insertions(+)
create mode 100644 drivers/iio/industrialio-configfs.c
create mode 100644 include/linux/iio/iio_configfs_trigger.h
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4132935..39f1b69 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -18,6 +18,14 @@ config IIO_BUFFER
Provide core support for various buffer based data
acquisition methods.
+config IIO_CONFIGFS
+ tristate Enable IIO configuration via configfs
+ select CONFIGFS_FS
+ help
+ This allows configuring various IIO bits through configfs
+ (e.g software trigger creation / destruction). For more info
+ see Documentation/iio/iio_configfs.txt.
+
if IIO_BUFFER
config IIO_BUFFER_CB
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..90cc407 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_IIO) += industrialio.o
industrialio-y := industrialio-core.o industrialio-event.o inkern.o
industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
+industrialio-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
new file mode 100644
index 000..4d2133a
--- /dev/null
+++ b/drivers/iio/industrialio-configfs.c
@@ -0,0 +1,297 @@
+/*
+ * Industrial I/O configfs bits
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * 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 linux/configfs.h
+#include linux/module.h
+#include linux/slab.h
+
+#include linux/iio/iio_configfs_trigger.h
+
+static const char *trigger_types[] =
+{
+ none,
+};
+
+struct iio_configfs_ops iio_none_ops = {
+ .get_freq = iio_none_get_freq,
+ .set_freq = iio_none_set_freq,
+ .probe = iio_none_probe,
+ .remove = iio_none_remove,
+};
+
+struct iio_trigger_item {
+ struct config_item item;
+ struct iio_configfs_trigger_info *trigger_info;
+};
+
+static
+inline struct iio_trigger_item *to_iio_trigger_item(struct config_item *item)
+{
+ if (!item)
+ return NULL;
+ return container_of(item, struct iio_trigger_item, item);
+}
+
+static unsigned int iio_trigger_get_type(const char *type_str)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(trigger_types); i++) {
+ if (!strncmp(trigger_types[i], type_str,
+ strlen(trigger_types[i])))
+ return i;
+ }
+ return -EINVAL;
+}
+
+static
+void iio_trigger_set_configfs_ops(struct iio_configfs_trigger_info *trig_info,
+ unsigned int type)
+{
+ switch (type) {
+ case IIO_TRIGGER_TYPE_NONE:
+ trig_info-configfs_ops = iio_none_ops;
+ break;
+ default:
+ pr_err(Setting configfs ops failed! Unknown type %d\n, type);
+ break;
+ }
+}
+
+CONFIGFS_ATTR_STRUCT(iio_trigger_item);
+
+#define IIO_TRIGGER_ITEM_ATTR(_name, _mode, _show, _store) \
+struct iio_trigger_item_attribute iio_trigger_item_attr_##_name = \
+ __CONFIGFS_ATTR(_name, _mode, _show, _store)
+
+static ssize_t iio_trigger_item_type_read(struct iio_trigger_item *item,
+ char *page)
+{
+ return sprintf(page, %s\n, trigger_types[item-trigger_info-type]);
+}
+
+static ssize_t iio_trigger_item_type_write(struct iio_trigger_item *item,
+ const char *page, size_t count)
+{
+ int type;
+
+ if (item-trigger_info-active)
+ return -EBUSY;
+
+ type = iio_trigger_get_type(page);
+ if (type 0)
+ return -EINVAL;
+
+ item-trigger_info-type = type;
+
+ iio_trigger_set_configfs_ops(item-trigger_info, type);
+
+ return count;
+}
+
+static ssize_t iio_trigger_item_activate_read(struct iio_trigger_item *item,
+ char *page)
+{
+ return sprintf(page, %d\n,
[PATCH 3/3] iio: Documentation: Add initial documentaton for IIO
This file wants to be a starting point document for anyone wanting to use IIO configfs support or adding new IIO configfs functionality. Signed-off-by: Daniel Baluta daniel.bal...@intel.com --- Documentation/iio/iio_configfs.txt | 74 ++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/iio/iio_configfs.txt diff --git a/Documentation/iio/iio_configfs.txt b/Documentation/iio/iio_configfs.txt new file mode 100644 index 000..494f4ff --- /dev/null +++ b/Documentation/iio/iio_configfs.txt @@ -0,0 +1,74 @@ +Industrial IIO configfs support + +1. Overview + +Configfs is a filesystem-based manager of kernel objects. IIO uses some +objects that could be easily configured using configfs (e.g: devices, +triggers). + +See Documentation/filesystems/configfs/configfs.txt for more information about +how configfs works. + +2. Usage + +In order to use configfs support in IIO we need to select it at compile time +via CONFIG_IIO_CONFIGFS config option. + +Then, mount the configfs filesystem (usually under /config directory): + +$ mkdir /config +$ mount -t configfs none /config + +At this point, all default IIO groups will be creatd and can be accessed under +/config/iio. Next chapters will describe available IIO configurable objects. + +2.1. Software triggers creation and destruction + +One of the IIO default configfs groups is the triggers groups. It is +automagically accessible when the configfs is mounted and can be found under +/config/iio/triggers. + +2.1.1. Trigger creation + +As simply as: + +$ mkdir /config/triggers/my_trigger + +This will create a directory associated with a trigger. To understand how this +works we first need to see my_triggers's attributes: + +$ ls /config/triggers/my_trigger +activatesampling_frequency type + +Available types for triggers are: + * none, this is a default dummy trigger that does nothing. + * hrtimer, this is trigger based on high resolution timer. + +Order of operations in order to create a hrtimer trigger: + +$ echo hrtimer /config/triggers/my_trigger/type +$ echo 1 /config/triggers/my_trigger/activate +$ echo 100 /config/triggers/my_trigger/sampling_frequency + +At this point the trigger can be used by an IIO device. + +2.1.2 Trigger destruction + +$ echo 1 /config/triggers/my_trigger/activate + +3. Misc + +In order to add a new trigger type, one need to implement a driver that creates +an instance of struct iio_configfs_ops (see iio_configfs_trigger.h header file +in include/linux/iio) and then support it in iio_trigger_set_configfs_ops +function from industrialiio-configfs.c file. + +These are the existing drivers implementing new trigger types: + * hrtimer = iio/trigger/iio-trig-hrtimer.c + +4. Further work + +* IIO dummy device creation +* Mappings to 'soft' in kernel users such as iio_input and iio_hwmon +* IIO on IIO drivers + -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [git pull] drm fixes
On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer jwbo...@fedoraproject.org
wrote:
On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau damien.lesp...@intel.com
Date: Thu Feb 5 18:30:20 2015 +
drm/i915: Don't try to reference the fb in
get_initial_plane_config()
From linux-next?
Yes, building now. Will let you know as soon as I test it on
both machines.
OK, with that commit applied I no longer get the kref.h splat and
the
NUC machine boots headless. I still see the backtrace below on both
the NUC and the macbook. I have a copy of it with drm.debug=0xff
from
the NUC here:
https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
Getting better at least :).
On top of what you currently have please also cherry-pick
commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau damien.lesp...@intel.com
Date: Thu Feb 5 19:24:25 2015 +
drm/i915: Fix atomic state when reusing the firmware fb
from -next. Let's hope this terminates eventually ;-)
Hm. That one doesn't apply cleanly. I think because it needs:
From 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 Mon Sep 17 00:00:00 2001
From: Damien Lespiau damien.lesp...@intel.com
Date: Thu, 5 Feb 2015 17:22:18 +
Subject: drm/i915: Store the initial framebuffer in
initial_plane_config
first. Do you want me to grab both, or should I try and figure out
how to backport fb9981aa67 without it?
Oops missed that. The active ingredient is setting
crtc-primary-state-crtc like this:
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1c12262029fb..bfc14a6046ea 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc-base.primary-state-crtc =
intel_crtc-base;
update_state_fb(intel_crtc-base.primary);
return;
}
@@ -2469,6 +2470,7 @@ intel_find_plane_obj(struct intel_crtc
*intel_crtc,
drm_framebuffer_reference(c-primary-fb);
intel_crtc-base.primary-fb = c-primary-fb;
+ intel_crtc-base.primary-state-crtc =
intel_crtc-base;
obj-frontbuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
break;
}
Hm. So I used your patch above. The macbook boots fine and all the
oops/WARNS are gone except the audio one that was unrelated and
present before all of this.
However, the NUC is back to not booting without HDMI plugged in. I
did the drm.debug=0xff+blacklist/insmod trick again and put the
results up here:
https://jwboyer.fedorapeople.org/pub/vetters.txt
The frontbuffer splat is back now.
I confirmed multiple times that the NUC boots fine with the kernel
that doesn't include the above patch but has the other two included
(albeit with the drm_atomic WARN still).
Not sure what to make of this one.
Yeah that fail looks like we're freeing an fb that's still in use.
Hilarity happens and since that happens under console_lock at boot-up your
machine dies.
Does that machine die the same way in drm-intel-nightly/linux-next?
I'll try that a bit later today. Out of sheer curiosity, I folded
commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
update) into the patch above and kicked off a build. The theory is
that we're picking up a bunch of other changes right in that range of
commits, why not try one more. I'll let you know if that fixes
anything. Otherwise, I'll try building drm-intel-nightly and/or
linux-next after that.
The drm-intel-nightly build finished first. It boots without HDMI
plugged in, but it has pretty much the same splats as the previous
kernel. Confused. Full log here:
https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
I don't have much hope for my other build.
Yeah that's at least good news for the theory I've been cooking meanwhile.
Can you try the below diff (on top of next/nightly)? For the current
cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc-base.
to primary-...
Thanks, Daniel
diff
Re: [PATCH 3/3] iio: Documentation: Add initial documentaton for IIO
On Wed, 25 Mar 2015, Daniel Baluta wrote: This file wants to be a starting point document for anyone wanting to use IIO configfs support or adding new IIO configfs functionality. typos below; I'm just trying to understand what's going on... Signed-off-by: Daniel Baluta daniel.bal...@intel.com --- Documentation/iio/iio_configfs.txt | 74 ++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/iio/iio_configfs.txt diff --git a/Documentation/iio/iio_configfs.txt b/Documentation/iio/iio_configfs.txt new file mode 100644 index 000..494f4ff --- /dev/null +++ b/Documentation/iio/iio_configfs.txt @@ -0,0 +1,74 @@ +Industrial IIO configfs support + +1. Overview + +Configfs is a filesystem-based manager of kernel objects. IIO uses some +objects that could be easily configured using configfs (e.g: devices, e.g. +triggers). + +See Documentation/filesystems/configfs/configfs.txt for more information about +how configfs works. + +2. Usage + +In order to use configfs support in IIO we need to select it at compile time +via CONFIG_IIO_CONFIGFS config option. + +Then, mount the configfs filesystem (usually under /config directory): + +$ mkdir /config +$ mount -t configfs none /config + +At this point, all default IIO groups will be creatd and can be accessed under created +/config/iio. Next chapters will describe available IIO configurable objects. IIO configuration objects? + +2.1. Software triggers creation and destruction trigger + +One of the IIO default configfs groups is the triggers groups. It is +automagically accessible when the configfs is mounted and can be found under +/config/iio/triggers. + +2.1.1. Trigger creation + +As simply as: + +$ mkdir /config/triggers/my_trigger + +This will create a directory associated with a trigger. To understand how this +works we first need to see my_triggers's attributes: + +$ ls /config/triggers/my_trigger should be config/iio/triggers? here and elsewhere? +activatesampling_frequency type + +Available types for triggers are: + * none, this is a default dummy trigger that does nothing. + * hrtimer, this is trigger based on high resolution timer. + +Order of operations in order to create a hrtimer trigger: Sequence of operations, or just 'operations' + +$ echo hrtimer /config/triggers/my_trigger/type +$ echo 1 /config/triggers/my_trigger/activate +$ echo 100 /config/triggers/my_trigger/sampling_frequency + +At this point the trigger can be used by an IIO device. + +2.1.2 Trigger destruction + +$ echo 1 /config/triggers/my_trigger/activate echo 0 probably + +3. Misc + +In order to add a new trigger type, one need to implement a driver that creates needs +an instance of struct iio_configfs_ops (see iio_configfs_trigger.h header file +in include/linux/iio) and then support it in iio_trigger_set_configfs_ops +function from industrialiio-configfs.c file. + +These are the existing drivers implementing new trigger types: + * hrtimer = iio/trigger/iio-trig-hrtimer.c + +4. Further work + +* IIO dummy device creation +* Mappings to 'soft' in kernel users such as iio_input and iio_hwmon in-kernel +* IIO on IIO drivers ?? + -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/14] Add kdbus implementation
Hi On Tue, Mar 24, 2015 at 12:24 AM, Andy Lutomirski l...@amacapital.net wrote: On Mon, Mar 23, 2015 at 8:28 AM, David Herrmann dh.herrm...@gmail.com wrote: On Thu, Mar 19, 2015 at 4:48 PM, Andy Lutomirski l...@amacapital.net wrote: On Thu, Mar 19, 2015 at 4:26 AM, David Herrmann dh.herrm...@gmail.com wrote: metadata handling is local to the connection that sends the message. It does not affect the overall performance of other bus operations in parallel. Sure it does if it writes to shared cachelines. Given that you're incrementing refcounts, I'm reasonable sure that you're touching lots of shared cachelines. Ok, sure, but it's still mostly local to the sending task. We take locks and ref-counts on the task-struct and mm, which is for most parts local to the CPU the task runs on. But this is inherent to accessing this kind of data, which is the fundamental difference in our views here, as seen below.. You're also refcounting the struct cred No? We do ref-count the group-info, but that is actually redundant as we just copy the IDs. We should drop this, since group-info of 'current' can be accessed right away. I noted it down. and there's no good reason for that to be local. (It might be a bit more local than intended because of the absurd things that the key subsystem does to struct cred, but IMO users should turn that off or the kernel should fix it.) Even more globally, I think you're touching init_user_ns's refcount in most scenarios. That's about as global as it gets. get_user_ns() in metadata.c is a workaround (as the comment there explains). With better export-helpers for caps, we can simply drop it. It's conditional on KDBUS_ATTACH_CAPS, anyway. (Also, is there an easy benchmark to see how much time it takes to send and receive metadata? I tried to get the kdbus test to do this, and I failed. I probably did it wrong.) patch for out-of-tree kdbus: https://gist.github.com/dvdhrm/3ac4339bf94fadc13b98 Update it to pass _KDBUS_ATTACH_ALL for both arguments of kdbus_conn_update_attach_flags(). Furthermore, it's way faster than collecting the same data via /proc, so I don't think it slows down the overall transaction at all. If a receiver doesn't want metadata, it should not request it (by setting the receiver-metadata-mask). If a sender doesn't like the overhead, it should not send the metadata (by setting the sender-metadata-mask). Only if both peers set the metadata mask, it will be transmitted. But you're comparing to the wrong thing, IMO. Of course it's much faster than /proc hackery, but it's probably much slower to do the metadata operation once per message than to do it when you connect to the endpoint. (Gah! It's a bus that could easily have tons of users but a single endpoint. I'm still not used to it.) Yes, of course your assumption is right if you compare against per-connection caches, instead of per-message metadata. But we do support _both_ use-cases, so we don't impose any policy. We still believe live-metadata is a crucial feature of kdbus, despite the known performance penalties. [...] This is even more true if this feature is *inconsistent* with legacy userspace (i.e. userspace dbus). Live metadata is already supported on UDS via SCM_CREDENTIALS, we just extend it to other metadata items. It's not a new invention by us. Debian code-search on SO_PASSCRED and SCM_CREDENTIALS gives lots of results. Netlink, as a major example of an existing bus API, already uses SCM_CREDENTIALS as primary way to transmit metadata. I could be wrong about the lack of use cases. If so, please enlighten me. We have several dbus APIs that allow clients to register as a special handler/controller/etc. (eg., see systemd-logind TakeControl()). The API provider checks the privileges of a client on registration and then just tracks the client ID. This way, the client can be privileged when asking for special access, then drop privileges and still use the interface. You cannot re-connect in between, as the API provider tracks your bus ID. Without message-metadata, all your (other) calls on this bus would always be treated as privileged. We *really* want to avoid this. Another example is logging, where we want exact data at the time a message is logged. Otherwise, the data is useless. With message-metadata, you can figure out the exact situation a process was in when a specific message was logged. Furthermore, it is impossible to read such data from /proc, as the process might already be dead. Which is a _real_ problem right now! Similarly, system monitoring wants message-metadata for the same reasons. And it needs to be reliable, you don't want malicious sandboxes to mess with your logs. kdbus is a _bus_, not a p2p channel. Thus, a peer may talk to multiple destinations, and it may want to look different to each of them. DBus method-calls allow 'syscall'-ish behavior when calling into other processes. We *want* to be able to drop privileges
Re: [PATCH] PM / sleep: Don't unset parent's direct_complete
On Wed, 25 Mar 2015, Tomeu Vizoso wrote: If a device isn't going to be fully-suspended because there isn't an implementation of the suspend callback, there's no need to make sure that its parent is going to be fully-suspended as well. What do you mean by fully-suspended? What if the parent has several children? Maybe some of them have implementations of the suspend callback and the others don't. Will your patch do the right thing then? Without this change, USB interface devices will always prevent the proper USB device to stay in runtime suspension when the system suspends. For USB it doesn't matter; everything gets resumed when the system wakes up. Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com --- Hi, I'm not sure if this is the right fix, What are you trying to fix? Is something currently wrong? because I don't see why the USB interface devices are in the dpm_list in the first place, so any comments will be welcome. _Every_ device is in the dpm_list, including USB interfaces. If your goal is to prevent USB devices from being resumed when the system wakes up, then the correct approach is to make usb_dev_prepare() return 1 rather than 0 under the appropriate conditions, and to add a dev_pm_ops to the usb_if_device_type structure with a prepare callback that returns 1. Alan Stern -- 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 v8 10/30] PCI: Introduce pci_host_bridge_list to manage host bridges
On 24.03.2015 04:34, Yijing Wang wrote:
Introduce pci_host_bridge_list to manage pci host
bridges in system, this make us have the ability
to check whether the new host would conflict with
existing one. Then we could remove bus alreay exist
check in __pci_create_root_bus().
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/pci/host-bridge.c | 41 -
drivers/pci/probe.c |9 +
include/linux/pci.h |1 +
3 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 1a9834b..8af6d51 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -8,6 +8,9 @@
#include pci.h
+static LIST_HEAD(pci_host_bridge_list);
+static DEFINE_MUTEX(pci_host_mutex);
+
static void pci_release_host_bridge_dev(struct device *dev)
{
struct pci_host_bridge *bridge = to_pci_host_bridge(dev);
@@ -41,12 +44,29 @@ static void pci_host_update_busn_res(
pci_add_resource(resources, host-busn_res);
}
+static bool pci_host_busn_res_overlap(
+ struct pci_host_bridge *new, struct pci_host_bridge *old)
+{
+ struct resource_entry *entry;
+ struct resource *res1 = NULL, *res2 = NULL;
+
+ resource_list_for_each_entry(entry, old-windows)
+ if (entry-res-flags IORESOURCE_BUS)
+ res1 = entry-res;
+
+ resource_list_for_each_entry(entry, new-windows)
+ if (entry-res-flags IORESOURCE_BUS)
+ res2 = entry-res;
+
+ return resource_overlaps(res1, res2);
+}
+
struct pci_host_bridge *pci_create_host_bridge(
struct device *parent, int domain, int bus,
struct list_head *resources)
{
int error;
- struct pci_host_bridge *host;
+ struct pci_host_bridge *host, *tmp;
struct resource_entry *window, *n;
host = kzalloc(sizeof(*host), GFP_KERNEL);
@@ -65,6 +85,21 @@ struct pci_host_bridge *pci_create_host_bridge(
*/
host-domain = domain;
pci_host_assign_domain_nr(host);
+ mutex_lock(pci_host_mutex);
+ list_for_each_entry(tmp, pci_host_bridge_list, list) {
+ if (tmp-domain != host-domain
+ || pci_host_busn_res_overlap(host, tmp)) {
I think you should construct condition this way:
+ if (tmp-domain == host-domain
+ pci_host_busn_res_overlap(host, tmp)) {
Regards,
Tomasz
+ pr_warn(pci host bridge pci%04x:%02x exist\n,
+ host-domain, bus);
+ mutex_unlock(pci_host_mutex);
+ pci_free_resource_list(host-windows);
+ kfree(host);
+ return NULL;
+ }
+ }
+ list_add_tail(host-list, pci_host_bridge_list);
+ mutex_unlock(pci_host_mutex);
+
host-dev.release = pci_release_host_bridge_dev;
dev_set_name(host-dev, pci%04x:%02x,
host-domain, bus);
@@ -80,6 +115,10 @@ struct pci_host_bridge *pci_create_host_bridge(
void pci_free_host_bridge(struct pci_host_bridge *host)
{
+ mutex_lock(pci_host_mutex);
+ list_del(host-list);
+ mutex_unlock(pci_host_mutex);
+
device_unregister(host-dev);
}
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 25ac741..8517d1b 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1869,7 +1869,7 @@ static struct pci_bus *__pci_create_root_bus(
void *sysdata)
{
int error;
- struct pci_bus *b, *b2;
+ struct pci_bus *b;
struct resource_entry *window;
struct device *parent;
struct resource *res;
@@ -1887,12 +1887,6 @@ static struct pci_bus *__pci_create_root_bus(
b-number = b-busn_res.start =
pci_host_first_busnr(bridge);
pci_bus_assign_domain_nr(b, parent);
- b2 = pci_find_bus(pci_domain_nr(b), b-number);
- if (b2) {
- /* If we already got to this bus through a different bridge,
ignore it */
- dev_dbg(b2-dev, bus already known\n);
- goto err_out;
- }
bridge-bus = b;
b-bridge = get_device(bridge-dev);
@@ -1952,7 +1946,6 @@ static struct pci_bus *__pci_create_root_bus(
put_dev:
put_device(bridge-dev);
-err_out:
kfree(b);
return NULL;
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index f189dfb..91cba01 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -407,6 +407,7 @@ struct pci_host_bridge {
/* we use default bus resource if no bus resource provided */
struct resource busn_res;
struct list_head windows; /* resource_entry */
+ struct list_head list;
void (*release_fn)(struct pci_host_bridge *);
void *release_data;
};
--
To unsubscribe from
[PATCH 2/3] iio: trigger: Add support for highres timer trigger
This patch adds an IIO trigger driver which uses a high resolution
timer to provide a frequency based trigger.
Signed-off-by: Marten Svanfeldt mar...@intuitiveaerial.com
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: Daniel Baluta daniel.bal...@intel.com
---
drivers/iio/industrialio-configfs.c | 4 +
drivers/iio/trigger/Kconfig | 8 ++
drivers/iio/trigger/Makefile | 2 +
drivers/iio/trigger/iio-trig-hrtimer.c | 146 +++
include/linux/iio/iio_configfs_trigger.h | 1 +
5 files changed, 161 insertions(+)
create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
index 4d2133a..22740c0 100644
--- a/drivers/iio/industrialio-configfs.c
+++ b/drivers/iio/industrialio-configfs.c
@@ -17,6 +17,7 @@
static const char *trigger_types[] =
{
none,
+ hrtimer,
};
struct iio_configfs_ops iio_none_ops = {
@@ -59,6 +60,9 @@ void iio_trigger_set_configfs_ops(struct
iio_configfs_trigger_info *trig_info,
case IIO_TRIGGER_TYPE_NONE:
trig_info-configfs_ops = iio_none_ops;
break;
+ case IIO_TRIGGER_TYPE_HRTIMER:
+ trig_info-configfs_ops = iio_hrtimer_ops;
+ break;
default:
pr_err(Setting configfs ops failed! Unknown type %d\n, type);
break;
diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
index 7999612..c856664 100644
--- a/drivers/iio/trigger/Kconfig
+++ b/drivers/iio/trigger/Kconfig
@@ -5,6 +5,14 @@
menu Triggers - standalone
+config IIO_TRIGGER_HRTIMER
+ tristate High resolution timer trigger
+ help
+ Provides a frequency based IIO trigger using hrtimers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-trig-hrtimer.
+
config IIO_INTERRUPT_TRIGGER
tristate Generic interrupt trigger
help
diff --git a/drivers/iio/trigger/Makefile b/drivers/iio/trigger/Makefile
index 0694dae..3d289f6 100644
--- a/drivers/iio/trigger/Makefile
+++ b/drivers/iio/trigger/Makefile
@@ -3,5 +3,7 @@
#
# When adding new entries keep the list in alphabetical order
+
+obj-$(CONFIG_IIO_TRIGGER_HRTIMER) += iio-trig-hrtimer.o
obj-$(CONFIG_IIO_INTERRUPT_TRIGGER) += iio-trig-interrupt.o
obj-$(CONFIG_IIO_SYSFS_TRIGGER) += iio-trig-sysfs.o
diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c
b/drivers/iio/trigger/iio-trig-hrtimer.c
new file mode 100644
index 000..1a8beaf
--- /dev/null
+++ b/drivers/iio/trigger/iio-trig-hrtimer.c
@@ -0,0 +1,146 @@
+/**
+ * The industrial I/O periodic hrtimer trigger driver
+ *
+ * Copyright (C) Intuitive Aerial AB
+ * Written by Marten Svanfeldt, mar...@intuitiveaerial.com
+ * Copyright (C) 2012, Analog Device Inc.
+ * Author: Lars-Peter Clausen l...@metafoo.de
+ *
+ * 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 linux/platform_device.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/hrtimer.h
+#include linux/iio/iio.h
+#include linux/iio/trigger.h
+
+#include linux/iio/iio_configfs_trigger.h
+
+struct iio_hrtimer_trig_info {
+ struct iio_configfs_trigger_info *configfs_info;
+ unsigned int frequency;
+ struct hrtimer timer;
+ ktime_t period;
+};
+
+static enum hrtimer_restart iio_trig_hrtimer_trig(struct hrtimer *timer)
+{
+ struct iio_hrtimer_trig_info *trig_info;
+
+ trig_info = container_of(timer, struct iio_hrtimer_trig_info, timer);
+
+ hrtimer_forward_now(timer, trig_info-period);
+ iio_trigger_poll(trig_info-configfs_info-trigger);
+
+ return HRTIMER_RESTART;
+}
+
+static int iio_trig_hrtimer_set_state(struct iio_trigger *trig, bool state)
+{
+ struct iio_hrtimer_trig_info *trig_info;
+
+ trig_info = iio_trigger_get_drvdata(trig);
+
+ if (trig_info-frequency == 0)
+ return -EINVAL;
+
+ if (state) {
+ hrtimer_start(trig_info-timer, trig_info-period,
+ HRTIMER_MODE_REL);
+ } else {
+ hrtimer_cancel(trig_info-timer);
+ }
+
+ return 0;
+}
+
+int iio_trig_hrtimer_read_freq(struct iio_configfs_trigger_info *cinfo)
+{
+ struct iio_hrtimer_trig_info *trig_info;
+
+ trig_info = iio_trigger_get_drvdata(cinfo-trigger);
+ return trig_info-frequency;
+}
+
+int iio_trig_hrtimer_write_freq(struct iio_configfs_trigger_info *cinfo,
+ unsigned long freq)
+{
+ struct iio_hrtimer_trig_info *trig_info;
+
+ trig_info = iio_trigger_get_drvdata(cinfo-trigger);
+
+ if (freq NSEC_PER_SEC)
+ return -EINVAL;
+
+ if (freq != 0)
+ trig_info-period = ktime_set(0, NSEC_PER_SEC / freq);
+
Re: [PATCH] Add virtio gpu driver.
On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote: Hi, BTW can we teach virtio-gpu to look for framebuffer using virtio pci caps? The virtio-gpu driver doesn't matter much here, it doesn't use it anyway. Or are there limitations such as only using IO port BARs, or compatibility with BIOS code etc that limit us to specific BARs anyway? Yes, vgabios code needs to know. Currently it has bar #2 for the vga framebuffer bar hardcoded. It's 16bit code. I don't feel like making the probing more complicated ... cheers, Gerd OK - you are saying all VGA cards use bar #2 for this functionality, so we are just following established practice here? -- MST -- 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 15/25] MIPS: BMIPS: Flush the readahead cache after DMA
On Wed, Mar 25, 2015 at 2:23 AM, Ralf Baechle r...@linux-mips.org wrote:
On Thu, Dec 25, 2014 at 09:49:10AM -0800, Kevin Cernekee wrote:
BMIPS 3300/435x/438x CPUs have a readahead cache that is separate from
the L1/L2. During a DMA operation, accesses adjacent to a DMA buffer
may cause parts of the DMA buffer to be prefetched into the RAC. To
avoid possible coherency problems, flush the RAC upon DMA completion.
Signed-off-by: Kevin Cernekee cerne...@gmail.com
Signed-off-by: Jaedon Shin jaedon.s...@gmail.com
---
arch/mips/mm/dma-default.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index af5f046..38ee47a 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -18,6 +18,7 @@
#include linux/highmem.h
#include linux/dma-contiguous.h
+#include asm/bmips.h
#include asm/cache.h
#include asm/cpu-type.h
#include asm/io.h
Aside of platform-specific headers having no business of getting
included directly in a generic arch file
asm/bmips.h covers all BMIPS CPUs across multiple platforms.
The intention was to add code needed to support BMIPS CPUs into a
central place, rather than duplicating it in the platform code for
each of the BMIPS-based systems: arch/mips/{bcm63xx,bmips,brcmstb}.
this also breaks the build
of many platforms:
CC arch/mips/mm/dma-default.o
In file included from arch/mips/mm/dma-default.c:21:0:
./arch/mips/include/asm/bmips.h: In function ‘bmips_read_zscm_reg’:
./arch/mips/include/asm/bmips.h:97:160: error: cast to pointer from integer
of different size [-Werror=int-to-pointer-cast]
cache_op(Index_Load_Tag_S, ZSCM_REG_BASE + offset);
^
./arch/mips/include/asm/bmips.h: In function ‘bmips_write_zscm_reg’:
./arch/mips/include/asm/bmips.h:118:160: error: cast to pointer from integer
of different size [-Werror=int-to-pointer-cast]
cache_op(Index_Store_Tag_S, ZSCM_REG_BASE + offset);
I think the broken platforms are all the 64 bit platforms.
Hmm, looks like I might need to use 0x9700UL for ZSCM_REG_BASE.
If this fixes the build should I resubmit, or do you really want the
BMIPS flush code moved into another file?
--
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] gpio: gpio-tb10x: remove incorrect __exit markup
On Wed, Mar 25, 2015 at 04:32:13PM +0100, Linus Walleij wrote: On Wed, Mar 18, 2015 at 5:55 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Tue, Mar 17, 2015 at 01:30:15PM +0100, Linus Walleij wrote: On Mon, Mar 9, 2015 at 7:04 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com I prefer to have this fixed by setting .suppress_bind_attrs = true in the struct device_driver .drv portion of the device driver, so the driver cannot be removed from sysfs. So platform_driver_probe() isn't really the only exception, there is a way to do the same supression on ordinary drivers if we know we won't fiddle with them from sysfs. Yes, you are right, setting suppress_bind_attrs will work too. Can you make a patch as per above (alternatively tell me how wrong I am...) Unfortunately I won't be able to do that as I can't provide justification for such change (i.e. I do not know why you want to disable unbinding while still keeping the remove() implementation. You are right, I want a patch deleting the remove() implementation and setting the .suppress_bind_attrs = true at the same time. For a bool driver of this type (typically compiled in and probed at boot) that makes most sense to me. Hmm, I do not think this is a good justification for disabling unbinding. However, as far as I can see, removing gpiochip will succeed even though there are users of gpios in the system and that might justify the change. But does this mean that we give up on making gpiochip clean up properly and we should schedule gpiochip_remove() and the rest of gpio cleanup infrastructure for removal and declare that gpio drivers can not ever be made modules? Seems like wrong direction to move to... Thanks. -- Dmitry -- 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-nvdimm] another pmem variant
On Wed, Mar 25, 2015 at 10:04 AM, Christoph Hellwig h...@lst.de wrote: On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote: The kernel command line would simply be the standard/existing memmap= to reserve a memory range. Then, when the platform device loads, it does a request_firmware() to inject a binary table that further carves memory into ranges to which the pmem driver attaches. No need for the legacy system BIOS to be upgraded to the new way. Ewww... It does do the right thing in kernel space. The userspace utility creates the binary table (once) that can be compiled into the platform device driver or auto-loaded by an initrd. The problem with a new memmap= is that it is too coarse. For example you can't do things like specify a pmem range per-NUMA node. Sure you can as long as you know the layout. memmap= can be specified multiple times. Again, I see absolutely zero benefit of doing crap like request_firmware() to convert interface, and I'm also tired of having this talk about code that will eventually be released and should be superior (and from all that I can guess so far will actually be far worse). You and me both... -- 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] iio: configfs: Add configfs support to IIO
This creates an IIO configfs subsystem named iio, which has one default
group named triggers. This allows us to easily create/destroy software
triggers. One must create a driver which implements iio_configfs_trigger.h
interface and then add its trigger type to IIO configfs core.
some minor things noted below... I'm just trying to understand what this
is about :)
See Documentation/iio/iio_configfs.txt for more details on how configfs
support for IIO works.
Signed-off-by: Daniel Baluta daniel.bal...@intel.com
---
drivers/iio/Kconfig | 8 +
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-configfs.c | 297
+++
include/linux/iio/iio_configfs_trigger.h | 48 +
4 files changed, 354 insertions(+)
create mode 100644 drivers/iio/industrialio-configfs.c
create mode 100644 include/linux/iio/iio_configfs_trigger.h
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4132935..39f1b69 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -18,6 +18,14 @@ config IIO_BUFFER
Provide core support for various buffer based data
acquisition methods.
+config IIO_CONFIGFS
+ tristate Enable IIO configuration via configfs
+ select CONFIGFS_FS
+ help
+ This allows configuring various IIO bits through configfs
+ (e.g software trigger creation / destruction). For more info
+ see Documentation/iio/iio_configfs.txt.
+
if IIO_BUFFER
config IIO_BUFFER_CB
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..90cc407 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_IIO) += industrialio.o
industrialio-y := industrialio-core.o industrialio-event.o inkern.o
industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
+industrialio-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
new file mode 100644
index 000..4d2133a
--- /dev/null
+++ b/drivers/iio/industrialio-configfs.c
@@ -0,0 +1,297 @@
+/*
+ * Industrial I/O configfs bits
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * 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 linux/configfs.h
+#include linux/module.h
+#include linux/slab.h
+
+#include linux/iio/iio_configfs_trigger.h
+
+static const char *trigger_types[] =
+{
+ none,
+};
+
+struct iio_configfs_ops iio_none_ops = {
+ .get_freq = iio_none_get_freq,
+ .set_freq = iio_none_set_freq,
+ .probe = iio_none_probe,
+ .remove = iio_none_remove,
+};
+
+struct iio_trigger_item {
+ struct config_item item;
+ struct iio_configfs_trigger_info *trigger_info;
+};
+
+static
+inline struct iio_trigger_item *to_iio_trigger_item(struct config_item *item)
+{
+ if (!item)
+ return NULL;
+ return container_of(item, struct iio_trigger_item, item);
+}
+
+static unsigned int iio_trigger_get_type(const char *type_str)
+{
+ int i;
unsigned
the function returns an index, not a type; probably get_type_index()?
+
+ for (i = 0; i ARRAY_SIZE(trigger_types); i++) {
+ if (!strncmp(trigger_types[i], type_str,
+ strlen(trigger_types[i])))
+ return i;
+ }
+ return -EINVAL;
+}
+
+static
+void iio_trigger_set_configfs_ops(struct iio_configfs_trigger_info
*trig_info,
+ unsigned int type)
+{
+ switch (type) {
+ case IIO_TRIGGER_TYPE_NONE:
+ trig_info-configfs_ops = iio_none_ops;
+ break;
+ default:
+ pr_err(Setting configfs ops failed! Unknown type %d\n, type);
%u
+ break;
+ }
+}
+
+CONFIGFS_ATTR_STRUCT(iio_trigger_item);
+
+#define IIO_TRIGGER_ITEM_ATTR(_name, _mode, _show, _store) \
+struct iio_trigger_item_attribute iio_trigger_item_attr_##_name = \
+ __CONFIGFS_ATTR(_name, _mode, _show, _store)
+
+static ssize_t iio_trigger_item_type_read(struct iio_trigger_item *item,
+ char *page)
+{
+ return sprintf(page, %s\n, trigger_types[item-trigger_info-type]);
+}
+
+static ssize_t iio_trigger_item_type_write(struct iio_trigger_item *item,
+const char *page, size_t count)
+{
+ int type;
+
+ if (item-trigger_info-active)
+ return -EBUSY;
+
+ type = iio_trigger_get_type(page);
+ if (type 0)
+ return -EINVAL;
+
+ item-trigger_info-type = type;
+
+
Re: [PATCH 2/4] x86/asm/entry/64: do not TRACE_IRQS fast SYSRET64 path
* Denys Vlasenko dvlas...@redhat.com wrote: SYSRET code path has a small irq-off block. On this code path, TRACE_IRQS_ON can't be called right before interrupts are enabled for real, we can't clobber registers there. So current code does it earlier, in a safe place. But with this, TRACE_IRQS_OFF/ON frames just two fast instructions, which is ridiculous: now most of irq-off block is _outside_ of the framing. Do the same thing that we do on SYSCALL entry: do not track this irq-off block, it is very small to ever cause noticeable irq latency. Be careful: make sure that jnz int_ret_from_sys_call_irqs_off now does invoke TRACE_IRQS_OFF - move int_ret_from_sys_call_irqs_off label before TRACE_IRQS_OFF. @@ -345,8 +346,8 @@ tracesys_phase2: */ GLOBAL(int_ret_from_sys_call) DISABLE_INTERRUPTS(CLBR_NONE) - TRACE_IRQS_OFF int_ret_from_sys_call_irqs_off: + TRACE_IRQS_OFF movl $_TIF_ALLWORK_MASK,%edi /* edi: mask to check */ This latter trick absolutely needs a comment, to keep future lockdep developers from wondering about the mismatch and the weird label placement ... Thanks, Ingo -- 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: Request for additional arm64 branch in linux-next
On Wed, Mar 25, 2015 at 05:20:03PM +, Will Deacon wrote: Hi Stephen, We've got a series of patches introducing ACPI support for arm64 that Oh dear ARM comrades-in-arms, I was hearing rumours and was secretly hoping that you would stay sane and not do the colossal mistake x86 did. My condolences. Perhaps not all is lost after all... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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 0/3] toshiba_acpi: Hotkey handling and keymap updates
On Fri, Mar 20, 2015 at 04:55:15PM -0600, Azael Avalos wrote: These patches add support to a new function that queries the supported Hotkey Event Type, making the use of the DMI matching unnecessary and also fixes the Special Functions mode on some laptops. Queued, thank you Azael. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Drivers: hv: hv_balloon: do not online pages in offline blocks
Currently we add memory in 128Mb blocks but the request from host can be aligned differently. In such case we add a partially backed block and when this block goes online we skip onlining pages which are not backed (hv_online_page() callback serves this purpose). When we receive next request for the same host add region we online pages which were not backed before with hv_bring_pgs_online(). However, we don't check if the the block in question was onlined and online this tail unconditionally. This is bad as we avoid all online_pages() logic: these pages are not accounted, we don't send notifications (and hv_balloon is not the only receiver of them),... And, first of all, nobody asked as to online these pages. Solve the issue by checking if the last previously backed page was onlined and onlining the tail only in case it was. Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com --- drivers/hv/hv_balloon.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index 014256a..99afef9 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -778,7 +778,17 @@ static unsigned long handle_pg_range(unsigned long pg_start, pgs_ol = has-ha_end_pfn - start_pfn; if (pgs_ol pfn_cnt) pgs_ol = pfn_cnt; - hv_bring_pgs_online(start_pfn, pgs_ol); + + /* +* Check if the corresponding memory block is already +* online by checking its last previously backed page. +* In case it is we need to bring rest (which was not +* backed previously) online too. +*/ + if (start_pfn has-start_pfn + !PageReserved(pfn_to_page(start_pfn - 1))) + hv_bring_pgs_online(start_pfn, pgs_ol); + has-covered_end_pfn += pgs_ol; pfn_cnt -= pgs_ol; } -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] x86/asm/entry/64: use smaller insns
On Wed, Mar 25, 2015 at 10:18 AM, Denys Vlasenko dvlas...@redhat.com wrote: The $AUDIT_ARCH_X86_64 parameter to syscall_trace_enter_phase1/2 is a 32-bit constant, loading it with 32-bit MOV produces 5-byte insn instead of 10-byte one. Acked-by: Andy Lutomirski l...@kernel.org Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/kernel/entry_64.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 11b7339..23aa43e 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -306,7 +306,7 @@ system_call_fastpath: /* Do syscall entry tracing */ tracesys: movq %rsp, %rdi - movq $AUDIT_ARCH_X86_64, %rsi + movl $AUDIT_ARCH_X86_64, %esi call syscall_trace_enter_phase1 test %rax, %rax jnz tracesys_phase2 /* if needed, run the slow path */ @@ -317,7 +317,7 @@ tracesys: tracesys_phase2: SAVE_EXTRA_REGS movq %rsp, %rdi - movq $AUDIT_ARCH_X86_64, %rsi + movl $AUDIT_ARCH_X86_64, %esi movq %rax,%rdx call syscall_trace_enter_phase2 -- 1.8.1.4 -- Andy Lutomirski AMA Capital Management, LLC -- 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] PM / sleep: Don't unset parent's direct_complete
On Wed, 25 Mar 2015, Alan Stern wrote: On Wed, 25 Mar 2015, Tomeu Vizoso wrote: If a device isn't going to be fully-suspended because there isn't an implementation of the suspend callback, there's no need to make sure that its parent is going to be fully-suspended as well. What do you mean by fully-suspended? What if the parent has several children? Maybe some of them have implementations of the suspend callback and the others don't. Will your patch do the right thing then? After thinking about it some more, I realized this won't be a problem. But what if the device has a child that _does_ have a suspend callback? In that case the child will need to be resumed, so the device's parent cannot be allowed to remain in runtime suspend when the system wakes up. Hence the parent's direct_complete must be cleared. Alan Stern -- 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/
